Tag Archives: GNS3

GNS-3 Lab: 4-byte Autonomous System Number – interactions between 32 and 16 bit speaking BGP routers

Posted on by Pier Carlo Chiodi
1 Comment

Such as IPv4 addresses, 2-byte pool of Autonomous System (AS) Numbers is going to be exhausted soon. By the time I’m writing, it seems Internet will run out of 16-bit AS Number on 26-Sep-2012. To prevent this situation, IANA extended the AS Number field to 32 bits and, on 2007, RIRs started assigning them… or, at least, to offer them!
Of course, in order to let 4-byte ASN to work properly, a little adjustement was needed in the BGP protocol. Enter RFC 4893, BGP Support for Four-octet AS Number Space.

4-byte ASN - Lab topologyIn this post I don’t want to cover the mechanisms of this protocol extension, if you want to understand them I please you to follow some links in the References section; I prefer to show some interactions between OLD 2-byte ASN and NEW 4-byte ASN BGP speakers. I built a little GNS3/Dynamips lab using a couple of 7200s with IOS 12.2(33)SRE as NEW speakers, and a couple of 3640s as OLD peers.

In the topology every router announces any subnet to the others; BGP peering sessions follow the physical topology. Green ASs support 4-byte AS, while gray do not.
For the sake of readibility I’ll use asdot notation in this post, with the exception of some configuration blocks where I’ll use asplain just to show both notation usage.

I also uploaded two packet captures on PacketLife.net: they show BGP UPDATES with and without the NEW_AS_PATH attributes. They are 4-byte_AS_numbers_Full_Support.cap and 4-byte_AS_numbers_Mixed_Scenario.cap.

Partial 4-byte ASN support: A-B routers

Router A is on AS 10.1 / 655361 (asdot / asplain notation):

A#sh run | sec bgp
router bgp 655361
 no synchronization
 bgp log-neighbor-changes
 network 10.0.0.0
 neighbor 172.16.3.2 remote-as 2
 no auto-summary
B#sh run | sec bgp
router bgp 2
 no synchronization
 bgp log-neighbor-changes
 network 20.0.0.0
 neighbor 172.16.3.1 remote-as 23456
 no auto-summary

As you can see, on router B neighbor statement we can’t use the real ASN to peer with A, so we have to use the AS_TRANS (23456). Let’s wait until our sessions come up, then show BGP neighbors and tables:

A#sh ip bgp neighbors 172.16.3.2
BGP neighbor is 172.16.3.2,  remote AS 2, external link
  BGP version 4, remote router ID 20.0.0.1
  BGP state = Established, up for 00:00:27
  Last read 00:00:27, last write 00:00:27, hold time is 180, keepalive interval is 60 seconds
  Neighbor sessions:
    1 active, is not multisession capable
  Neighbor capabilities:
    Route refresh: advertised and received(new)
    Four-octets ASN Capability: advertised
    Address family IPv4 Unicast: advertised and received
    Multisession Capability: advertised
...

Please note the Four-octets ASN Capability: advertised line: A advertised this capability but did not receive it back from B.

A#sh ip bgp | beg Network
   Network          Next Hop            Metric LocPrf Weight Path
*> 10.0.0.0         0.0.0.0                  0         32768 i
*> 20.0.0.0         172.16.3.2               0             0 2 i

As expected, A receives the B‘s route but…

B#sh ip bgp | beg Network
   Network          Next Hop            Metric LocPrf Weight Path
*> 10.0.0.0         172.16.3.1               0             0 23456 i
*> 20.0.0.0         0.0.0.0                  0         32768 i

… B only sees A‘s subnet as from AS_TRANS (23456).

This is because B does not support 4-byte ASN, and router A knows this (capabilities exchange during session setup), so it just sends AS_PATH attributes containing the 16-bit AS_TRANS in place of the real 32-bit AS number.

You can find a similar UPDATE on the first capture I sent on PacketLife.net (4-byte_AS_numbers_Mixed_Scenario.cap), packet number 2.

Full 4-byte ASN support: A-D routers

Let’s setup the BGP session between routers A and D; they both support 4-byte ASN.

A#sh run | sec bgp
router bgp 655361
 no synchronization
 bgp log-neighbor-changes
 network 10.0.0.0
 neighbor 172.16.1.2 remote-as 2621441
 neighbor 172.16.3.2 remote-as 2
 no auto-summary
D#sh run | sec bgp
router bgp 2621441
 no synchronization
 bgp log-neighbor-changes
 network 40.0.0.0
 neighbor 172.16.1.1 remote-as 655361
 no auto-summary

When sessions come up…

A#sh ip bgp neighbors 172.16.1.2
BGP neighbor is 172.16.1.2,  remote AS 40.1, external link
  BGP version 4, remote router ID 40.0.0.1
  BGP state = Established, up for 00:04:04
  Last read 00:00:46, last write 00:00:53, hold time is 180, keepalive interval is 60 seconds
  Neighbor sessions:
    1 active, is multisession capable
  Neighbor capabilities:
    Route refresh: advertised and received(new)
    Four-octets ASN Capability: advertised and received
    Address family IPv4 Unicast: advertised and received
    Multisession Capability: advertised and received
...

Here A both sent and received the 4-byte ASN capability to/by B, because it supports this feature.

A#sh ip bgp | beg Network
   Network          Next Hop            Metric LocPrf Weight Path
*> 10.0.0.0         0.0.0.0                  0         32768 i
*> 20.0.0.0         172.16.3.2               0             0 2 i
*> 40.0.0.0         172.16.1.2               0             0 2621441 i
D#sh ip bgp | beg Network
   Network          Next Hop            Metric LocPrf Weight Path
*> 10.0.0.0         172.16.1.1               0             0 655361 i
*> 20.0.0.0         172.16.1.1                             0 655361 2 i
*> 40.0.0.0         0.0.0.0                  0         32768 i

Both A and D have subnets with the full 32-bit AS number.

You can see the capture on the file 4-byte_AS_numbers_Full_Support.cap on PacketLife.net.

As I already said, let’s switch to asdot notation now, just to improve readibility:

D#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
D(config)#router bgp 40.1
D(config-router)#bgp asnotation dot
D(config-router)#do show ip bgp | beg Network
   Network          Next Hop            Metric LocPrf Weight Path
*> 10.0.0.0         172.16.1.1               0             0 10.1 i
*> 20.0.0.0         172.16.1.1                             0 10.1 2 i
*> 40.0.0.0         0.0.0.0                  0         32768 i
A#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
A(config)#router bgp 10.1
A(config-router)#bgp asnotation dot

Ok, 10.1 is better than 655361, and 40.1 than 2621441!! 🙂

Mixed scenario: D-B routers

Let’s have more fun now and bring D-B session up!

D(config-router)#neighbor 172.16.2.1 remote-as 2
B(config-router)#neighbor 172.16.2.2 remote-as 23456

As we already saw, B doesn’t support 4-byte ASN, so we have to use AS_TRANS to peer with D.

D#show ip bgp | beg Network
   Network          Next Hop            Metric LocPrf Weight Path
*  10.0.0.0         172.16.2.1                             0 2 10.1 i
*>                  172.16.1.1               0             0 10.1 i
*> 20.0.0.0         172.16.2.1               0             0 2 i
*                   172.16.1.1                             0 10.1 2 i
*> 40.0.0.0         0.0.0.0                  0         32768 i

The interesting thing we can see now on D is the presence of A‘s subnet (10.0.0.0) advertised by B: even if B does not support 4-octect ASN, D receives it with the real 32-bit path. When A advertises the subnet to B it makes the AS_PATH attribute up using AS_TRANS, but it also adds the transitive attribute NEW_AS_PATH, containing the full 32-bit AS numbers; when B advertises the subnet to D it adds this attribute and so D can rebuild the real 32-bit path.

As before, you can find a similar UPDATE on the capture I sent on PacketLife.net; the file is 4-byte_AS_numbers_Mixed_Scenario.cap, packet number 3.

Another interesting aspect of 4-byte AS lack of support can be seen in the following table:

B#sh ip bgp | beg Network
   Network          Next Hop            Metric LocPrf Weight Path
*  10.0.0.0         172.16.2.2                             0 23456 23456 i
*>                  172.16.3.1               0             0 23456 i
*> 20.0.0.0         0.0.0.0                  0         32768 i
*> 40.0.0.0         172.16.2.2               0             0 23456 i
*                   172.16.3.1                             0 23456 23456 i

Here B has two entries for the 10.0.0.0 subnet: they both seem to be originated from the same AS, but that’s not true: the first comes from D (AS 40.1), while the second (the selected one) comes directly from A.

Similar behaviour is for the 40.0.0.0 subnet. Of course, this is not a really big problem, but may lead to false assumptions and compromise traffic patterns analysis.

16-bit stub router

Just to complete all the possible scenarios, here is C configuration:

B#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
B(config)#router bgp 2
B(config-router)#neighbor 172.16.4.2 remote-as 3
C#sh run | sec bgp
router bgp 3
 no synchronization
 bgp log-neighbor-changes
 network 30.0.0.0
 neighbor 172.16.4.1 remote-as 2
 no auto-summary
C#sh ip bgp | beg Network
   Network          Next Hop            Metric LocPrf Weight Path
*> 10.0.0.0         172.16.4.1                             0 2 23456 i
*> 20.0.0.0         172.16.4.1               0             0 2 i
*> 30.0.0.0         0.0.0.0                  0         32768 i
*> 40.0.0.0         172.16.4.1                             0 2 23456 i

It has no idea of what 4-byte ASN are, so it sees both 10.0.0.0 and 40.0.0.0 subnets as originated from the same AS.

Thanks

I have to say thanks to Marco Rizzi for his kind support on helping me to build this lab! 😉 And, of course, I suggest you to visit his blog: Marco Rizzi Blog – networking with passion!!!

Download the lab

To download the lab and configuration files click here.

References

Report on consumption of AS Numbers: http://www.potaroo.net/tools/asns/

BGP Support for Four-octet AS Number Space: RFC 4893

APRICOT 2007: 4-Byte AS Numbers (PDF)

Cisco.com: Migration Guide for Explaining 4-Byte Autonomous System

Cisco.com: Cisco IOS BGP 4-Byte ASN Support

Cisco.com: Explaining 4-Byte Autonomous System (AS) ASPLAIN and ASDOT Notation for Cisco IOS

Categories: Networking, Networking Labs | Tags: , , , , , , , ,

GNS3 Lab: Any Transport over MPLS (AToM) basic configuration for Ethernet 802.1q and Frame-relay

Posted on by Pier Carlo Chiodi
10 Comments

AToM stands for Any Transport over MPLS, a quite reassuring technology which, provided you have a MPLS enabled network and some good gears, let you set up L2 circuits across your IP backbone.

This lab offers a very simple topology with 2 AToM links; an ethernet with an 802.1q trunk and a frame-relay link.

Core

Core (P) routers configuration is pretty simple; we only enable MPLS switching on interfaces toward PE routers and setup LDP for labels exchange. A good core doesn’t care about what kind of traffic it switches!

P1:

mpls label protocol ldp
!
interface Loopback0
 ip address 1.1.1.1 255.255.255.255
!
interface FastEthernet0/0
 description PE1 facing interface
 mpls ip
!
interface FastEthernet1/0
 description P2 facing interface
 mpls ip
!
mpls ldp router-id Loopback0 force

PE routers

The hard work is done on PE routers. PE routers face CE routers, which they receive L2 traffic from, and network core P routers, which they have to send MPLS encapsulated traffic to.
In order to build up a L2 circuit, PE routers have to setup a pseudowire connection between them, so they know how to switch traffic. Each pseudowire uses a virtual-circuit ID (VC ID), which is locally significant on each PE pair and is used to identify the pseudowire itself and to bind it to a specific MPLS label.

First off, they must be MPLS aware:

PE2

mpls label protocol ldp
!
interface Loopback0
 ip address 1.1.2.2 255.255.255.255
!
interface FastEthernet0/1
 description P2 facing interface
 mpls ip
!
mpls ldp router-id Loopback0

Now, we have to set up pseudowires between PE and L2 connections with CEs.

Let’s start with the Ethernet 802.1q trunk.

Port mode Ethernet over MPLS (EoMPLS)

In port mode EoMPLS every frame received on a PE interface is forwarded to the other PE almost unchanged (just preamble and FCS are removed).

Basic configuration is very simple:

PE2

interface FastEthernet0/0
 description CE_Switch2 facing interface
 no ip address
 duplex auto
 speed auto
 xconnect 1.1.2.1 10 encapsulation mpls

The xconnect command does all the work! This command tells the PE router to encapsulate every frame in a MPLS packet and to forward it to the peer 1.1.2.1 using VC ID 10.
It also allow Label Distribution Protocol (LDP) to exchange informations about the pseudowire circuit between PEs (VC ID / label mapping, VC type, MTU).

Once we have applied this configuration to both PE routers (on PE1 we have to change the xconnect peer address!), we can verify if LDP did its work and if pseudowire is up:

PE2#show mpls l2transport vc 10 detail
Local interface: Fa0/0 up, line protocol up, Ethernet up
  Destination address: 1.1.2.1, VC ID: 10, VC status: up
    Output interface: Fa0/1, imposed label stack {18 16}
    Preferred path: not configured
    Default path: active
    Next hop: 172.16.2.0
  Create time: 01:16:07, last status change time: 01:15:44
  Signaling protocol: LDP, peer 1.1.2.1:0 up
    MPLS VC labels: local 16, remote 16
    Group ID: local 0, remote 0
    MTU: local 1500, remote 1500
    Remote interface description:
  Sequencing: receive disabled, send disabled
  VC statistics:
    [cut]

Now, setup and test VLAN connectivity on customer side:

Net1_H1#sh run int fa0/0 | beg interface
interface FastEthernet0/0
 ip address 192.168.1.1 255.255.255.0
 duplex auto
 speed auto
end
Net1_H2#sh run int fa0/0 | beg interface
interface FastEthernet0/0
 ip address 192.168.1.2 255.255.255.0
 duplex auto
 speed auto
end
Net1_H1#ping 192.168.1.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 148/168/192 ms

Frame-relay over MPLS, DLCI-to-DLCI mode

Frame-relay over MPLS requires a few more lines of configuration, but the pseudowire setup is the same as EoMPLS.

We have to enable frame-relay switching on the PE router, configure the Serial interface as DCE and setup the switching path for the DLCI:

PE2

frame-relay switching
!
interface Serial1/0
 no ip address
 encapsulation frame-relay IETF
 frame-relay intf-type dce
!
connect FR2-FR1 Serial1/0 201 l2transport
 xconnect 1.1.2.1 20 encapsulation mpls

PE1

frame-relay switching
!
interface Serial1/0
 no ip address
 encapsulation frame-relay IETF
 frame-relay intf-type dce
!
connect FR1-FR2 Serial1/0 102 l2transport
 xconnect 1.1.2.2 20 encapsulation mpls

Let’s verify everything is ok:

PE2#show mpls l2transport vc 20

Local intf     Local circuit              Dest address    VC ID      Status
-------------  -------------------------- --------------- ---------- ----------
Se1/0          FR DLCI 201                1.1.2.1         20         UP

With this configuration we have DLCI 102 for FR1-to-FR2 traffic, and DLCI 201 for FR2-to-FR1 traffic.

Customer side configuration:

FR1

interface Serial0/0
 no ip address
 encapsulation frame-relay IETF
!
interface Serial0/0.1 point-to-point
 ip address 172.16.0.1 255.255.255.252
 frame-relay interface-dlci 102

Similar configuration on FR2:

interface Serial0/0.1 point-to-point
 ip address 172.16.0.2 255.255.255.252
 frame-relay interface-dlci 201

Some tests…

FR1#show frame-relay lmi

LMI Statistics for interface Serial0/0 (Frame Relay DTE) LMI TYPE = CISCO
  Invalid Unnumbered info 0             Invalid Prot Disc 0
  Invalid dummy Call Ref 0              Invalid Msg Type 0
  Invalid Status Message 0              Invalid Lock Shift 0
  Invalid Information ID 0              Invalid Report IE Len 0
  Invalid Report Request 0              Invalid Keep IE Len 0
  Num Status Enq. Sent 615              Num Status msgs Rcvd 573
  Num Update Status Rcvd 0              Num Status Timeouts 42
  Last Full Status Req 00:00:24         Last Full Status Rcvd 00:00:24
FR1#
FR1#show frame-relay pvc

PVC Statistics for interface Serial0/0 (Frame Relay DTE)

              Active     Inactive      Deleted       Static
  Local          1            0            0            0
  Switched       0            0            0            0
  Unused         0            0            0            0

DLCI = 102, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0.1

  input pkts 115           output pkts 120          in bytes 32266
  out bytes 33844          dropped pkts 0           in pkts dropped 0
  out pkts dropped 0                out bytes dropped 0
  in FECN pkts 0           in BECN pkts 0           out FECN pkts 0
  out BECN pkts 0          in DE pkts 0             out DE pkts 0
  out bcast pkts 100       out bcast bytes 31764
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
  pvc create time 01:43:39, last time pvc status changed 01:10:26
FR1#
FR1#ping 172.16.0.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.0.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 164/185/220 ms

Please note how the subnet 172.16.0.0/32 on the FR routers does not conflict with 172.16.0.0/31 between P routers; it’s on a totally different L3 domain and it is not routed by the network, but transparently encapsulated in L2 over MPLS packets.

Packet captures

You can find some nice packet captures about this lab at PacketLife.net Captures section, under the MPLS category; they have been taken on P1-P2 link, with inner (pseudowire) and outer MPLS label on top of every packet. They are “LDP_Ethernet_FrameRelay”, which shows how LDP setup the pseudowire circuit, “EoMPLS_802.1q” and “Frame-Relay over MPLS”, which show an ICMP ping encapsulated in Ethernet and Frame-relay respectively.

Anyway, if you don’t know PacketLike.net you must take a tour of that great website, really worth it!

Conclusion and download

This post only shows a little basic configuration of some AToM solutions; there are many more capabilities than which I wrote on this blog. A good starting point is to read documents you can find using links below.

If you want to download this GNS3/Dynamips lab, you can find it here.

References

Cisco.com: MPLS AToM Technical Overview

Cisco.com: Any Transport over MPLS

Categories: Networking, Networking Labs | Tags: , , , , , , , , ,

GNS3 Labs: Source-based Remote Triggered Black Hole (RTBH) Filtering with Unicast Reverse Path Forwarding (uRPF)

Posted on by Pier Carlo Chiodi
5 Comments

This post is part of a series about “ISP Security Tools and Techniques“; in this series I talk about some (I think) useful practices:

1. Remote Triggered Black Holing

2. BGP Customer triggered black holing

3. BGP triggered rate limiting and less-than-best-effort (LBE) with QPPB

4. Source-based RTBH with Unicast Reverse Path Forwarding (uRPF)

Stay tuned! 😉

Today I drew inspiration from a brand new RFC to add a post to this little series: RFC-5635, Remote Triggered Black Hole Filtering with Unicast Reverse Path Forwarding (uRPF).

Especially, I would like to focus on section 4 of this RFC, Source Address RTBH Filtering.

To fully understand this post I would suggest to read my previous post Remote Triggered Black Holing.

Read more …

Categories: Networking, Networking Labs, Security | Tags: , , , , , , , , , , ,

GNS3 Labs: BGP triggered rate limiting and less-than-best-effort (LBE) with QPPB

Posted on by Pier Carlo Chiodi
8 Comments

This post is part of a series about “ISP Security Tools and Techniques“; in this series I talk about some (I think) useful practices:

1. Remote Triggered Black Holing

2. BGP Customer triggered black holing

3. BGP triggered rate limiting and less-than-best-effort (LBE) with QPPB

4. Source-based RTBH with Unicast Reverse Path Forwarding (uRPF)

Stay tuned! 😉

As I already wrote in my previous posts, an ISP can provide their customers some useful tools to mitigate (D)DoS attacks: Remote Triggered Black Holing and its NOC-independent version, Customer triggered black holing are tools that, once identified attacked hosts or networks, let us to stop malicious traffic at the provider’s edge.

Anyway, when we drop traffic toward attacked hosts, we can’t investigate the attack anymore; we would need a tool which allowed us to analyze traffic and, in the meantime, that would avoid wasting network resources. Our (dear) provider could provide it by implementing rate limiting and less-than-best-effort services using QoS Policy Propagation via BGP (QPPB).

Read more …

Categories: Networking, Networking Labs, Security | Tags: , , , , , , , , , , , ,

GNS3 Labs: BGP Customer triggered black holing

Posted on by Pier Carlo Chiodi
12 Comments

This post is part of a series about “ISP Security Tools and Techniques“; in this series I talk about some (I think) useful practices:

1. Remote Triggered Black Holing

2. BGP Customer triggered black holing

3. BGP triggered rate limiting and less-than-best-effort (LBE) with QPPB

4. Source-based RTBH with Unicast Reverse Path Forwarding (uRPF)

Stay tuned! 😉

Remote Triggered Black Holing In this post I’ll show you how to let your customers to trigger black holing for their prefixes. What I will write is based on my previous post GNS3 Lab: Remote Triggered Black Holing: same scenario, same startup config (the final one of that post).

Read more …

Categories: Networking, Networking Labs, Security | Tags: , , , , , , ,