Category: Network Technologies

Cisco 2600: How many IPv4 prefixes can fit in BGP table

Today I wanted to try and see how many IPv4 prefixes can a Cisco 2600 accommodate in BGP table both global and in VRF table. I have lying around a Cisco 2621XM with 64MB of RAM, so I said to stress it a bit like in the old days when it was productive.

I did use the bgp_simple tool to test with the latest full Internet prefixes table (dated 2013.03.09). For those of you not familiar with bgp_simple, it’s a script capable of BGP peering and route injection. I would recommend to check the script webpage as it’s an awesome tool.

First, I did use the Global table to store all BGP prefixes. The router issued a %SYS-2-MALLOCFAIL error after receiving 44791 prefixes and few seconds later it dropped the BGP neighborship peering.

BB1#sh ip bgp sum | b Nei
Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
192.168.182.1   4 65000 1194845      95  1181910  360    0 00:10:57    44791
 
BB1#
*Feb 10 21:22:49.383: %SYS-2-MALLOCFAIL: Memory allocation of 65536 bytes failed from 0x8006A11C, alignment 0 
Pool: Processor  Free: 64176  Cause: Not enough free memory 
Alternate Pool: None  Free: 0  Cause: No Alternate pool 
 -Process= "BGP Router", ipl= 0, pid= 32 -Traceback= 0x8119EA40 0x80057D14 0x80059F18 0x8005A75C 0x8006A120 0x8006AE9C 0x8192D52C 0x80DFDD34 0x80DFE708 0x80DFF60C 0x82BA5A60 0x80DFF6E4 0x80DD8694 0x802435AC 0x80246CB0
*Feb 10 21:23:00.395: %BGP-5-ADJCHANGE: neighbor 192.168.182.1 Down No memory
*Feb 10 21:23:00.515: %BGP-3-NOTIFICATION: sent to neighbor 192.168.182.1 3/1 (update malformed) 0 bytes 
BB1# FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF 0037 0200 0000 1C40 0101 0040 020E 0206 FDE8 9465 12EC 1D31 00D1 5821 4003 04C0 A8B6 0117 433F E0

For second test I did create VRF A and the BGP neighborship was established over an interface in that VRF, so all prefixes injected by bgp_simple arrived in the VRF table. This time it took only 33321 prefixes for the router to spit an error and drop the BGP connection.

BB1#sh ip bgp vpnv4 vrf A sum | b Nei
Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
192.168.182.1   4 65000  439682      31   323732  534    0 00:09:24    33321
 
*Feb 10 21:37:22.323: %SYS-2-MALLOCFAIL: Memory allocation of 2920 bytes failed from 0x8006A11C, alignment 0 
Pool: Processor  Free: 8584  Cause: Memory fragmentation 
Alternate Pool: None  Free: 0  Cause: No Alternate pool 
 -Process= "BGP Router", ipl= 0, pid= 32 -Traceback= 0x8119EA40 0x80057D14 0x80059F18 0x8005A75C 0x8006A120 0x8006AE9C 0x80DEB7B0 0x80DCC800 0x80E3DCC8 0x80E3B62C 0x80E2A244 0x80E2AE30 0x80DD0B14 0x80DD7F08 0x802435AC
*Feb 10 21:37:31.011: %BGP-5-ADJCHANGE: neighbor 192.168.182.1 vpn vrf A Down No memory
*Feb 10 21:37:31.251: %BGP-3-NOTIFICATION: sent to neighbor 192.168.182.1 3/1 (update malformed) 0 bytes 
BB1#sh ip bgp vpnv4 vrf A sum | b Nei FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF 0052 0200 0000 3740 0101 0040 020A 0204 FDE8 2236 1AAE 18B7 4003 04C0 A8B6 01C0 081C 18B7 03E9 18B7 A028 1AAE 3E80 1AAE 3F6A 1AAE 59D9 1AAE 89EA 2236 1AAE 1440 3B90

For those of you curious about why it took less prefixes to exhaust memory in VRF vs non-VRF, the reason is that in VRF you have more memory consumption per IPv4 prefix. Ivan Pepelnjak explained it very well in his blog post about running Internet in VRF.

I’ll check what other old Cisco routers I have around to see their BGP table limit.


Overlay MPLS over provider backbone

Imagine that you have two or more sites which you want to connect together using MPLS technology. You cannot afford dark fiber and your Service Provider cannot offer you L2 connections of any kind. The only thing your SP can offer is L3 transport. Still, you want to build your own MPLS environment and there is no way to convince your SP to enable CsC.

I will use the following topology to demonstrate one of the possibilities to build an overlay MPLS over SP backbone.

Overlay MPLS over SP

The provider has already his MPLS backbone configured (P1, PE1, PE2 and PE3) and it’s offering you, as customer, IP transport over it’s backbone. Usually, from customer perspective, you don’t get to see the SP backbone, but just for reference, it is using ISIS for IGP, MP-BGP and MPLS VPN to transport our prefixes.

From IP prefixes allocation I’m using “xy” in the third octet (x – lower router number, y – higher router number) and “z” in the last octet (router number) with a /24 mask.

We have three locations named CPE1, CPE2 and CPE3. Currently between my CPE and provider PE I have enabled BGP, but you can use any protocol (even static) if your SP is able to route your IP prefixes over its backbone. On each CPE device I have a Loopback interface and its IP address will be the only prefix you announce (through BGP in this demonstration) to SP.

Let’s establish the BGP connection from our CPE to SP PE. As I’m playing the role of customer here, only the CPE exhibits will be shown:

CPE5

interface Loopback0
 ip address 5.5.5.5 255.255.255.255
!
router bgp 65001
 bgp router-id 5.5.5.5
 bgp log-neighbor-changes
 neighbor 10.0.35.3 remote-as 65000
 neighbor 10.0.35.3 description R3PE3
 neighbor 10.0.35.3 timers 5 20
 !
 address-family ipv4
  neighbor 10.0.35.3 activate
  no auto-summary
  no synchronization
  network 5.5.5.5 mask 255.255.255.255
 exit-address-family

CPE6

interface Loopback0
 ip address 6.6.6.6 255.255.255.255
!
router bgp 65001
 bgp router-id 6.6.6.6
 bgp log-neighbor-changes
 neighbor 10.0.26.2 remote-as 65000
 neighbor 10.0.26.2 description R2PE2
 neighbor 10.0.26.2 timers 5 20
 !
 address-family ipv4
  neighbor 10.0.26.2 activate
  no auto-summary
  no synchronization
  network 6.6.6.6 mask 255.255.255.255
 exit-address-family

CPE7

interface Loopback0
 ip address 7.7.7.7 255.255.255.255
!
router bgp 65001
 bgp router-id 7.7.7.7
 bgp log-neighbor-changes
 neighbor 10.0.47.4 remote-as 65000
 neighbor 10.0.47.4 description R4PE4
 neighbor 10.0.47.4 timers 5 20
 !
 address-family ipv4
  neighbor 10.0.47.4 activate
  no auto-summary
  no synchronization
  network 7.7.7.7 mask 255.255.255.255
 exit-address-family

BGP neighborship suppose to be up now and on each CPE I should receive the Loopback prefixes of the other two CPE devices.

R5CPE5#sh ip bgp sum | b Nei
Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.0.35.3       4 65000     126     125        2    0    0 00:10:04        0
!
R6CPE6#sh ip bgp sum | b Nei
Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.0.26.2       4 65000     136     135        2    0    0 00:10:50        0
!
R7CPE7#sh ip bgp sum | b Nei
Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.0.47.4       4 65000     134     134        4    0    0 00:10:46        0

BGP neighborship is up alright, but where are my prefixes? State/PfxRcd is 0, when it should show 2.
I did that on purpose.

Notice that we are using the same AS number on all our sites. I think you already know that the rule in BGP is that if our own ASN is seen in the AS-Path of a particular IP prefix, BGP will not install that prefix in BGP table. This is fixable:
1. We ask our provider to have a little “as-override” command in its BGP configuration for our neighbor
2. We use different ASN on each site (assuming that we are using private ASN)
3. We configure “allowas-in” on BGP neighborship with SP

Basically you may use any of the three methods (or other if you can think of any other), but in my case I don’t want to ask the SP nor I want to change my ASN scheme. I’ll go with the third option and be careful not run into loop issues (consider this is an Enterprise environment I think it’s doable).

CPE5

router bgp 65001
  neighbor 10.0.35.3 allowas-in

CPE6

router bgp 65001
  neighbor 10.0.26.2 allowas-in

CPE7

router bgp 65001
  neighbor 10.0.47.4 allowas-in

Let’s check again and do some testing. I will use CPE5

R5CPE5#sh ip route bgp
     6.0.0.0/32 is subnetted, 1 subnets
B       6.6.6.6 [20/0] via 10.0.35.3, 00:04:02
     7.0.0.0/32 is subnetted, 1 subnets
B       7.7.7.7 [20/0] via 10.0.35.3, 00:04:02
!
R5CPE5#ping 6.6.6.6 source 5.5.5.5
 
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 6.6.6.6, timeout is 2 seconds:
Packet sent with a source address of 5.5.5.5 
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 32/44/64 ms
 
R5CPE5#ping 7.7.7.7 source 5.5.5.5
 
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 7.7.7.7, timeout is 2 seconds:
Packet sent with a source address of 5.5.5.5 
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 28/52/96 ms

Next part involves the creation of Tunnels interfaces, to have a full mesh connection between the three sites, enable of IGP / MPLS and creation of a second Loopback interface which we will use later for the iBGP configuration. I did chose IS-IS for IGP and LDP for MPLS. The new Loopback interface will be routed using the IS-IS protocol.

A note from my side. Since I had limited number of routers, my CPE devices will be kind of P / PE / CE router in my overlay MPLS demonstration.

CPE5

int Tun56
tunnel source lo0
tunnel destination 6.6.6.6
ip address 192.168.56.5 255.255.255.0
mpls ip
ip router isis
!
int Tun57
tunnel source lo0
tunnel destination 7.7.7.7
ip address 192.168.57.5 255.255.255.0
mpls ip
ip router isis
!
int Lo1
ip address 55.55.55.55 255.255.255.255
!
router isis
net 47.0005.0005.0005.0005.00
passive-interface lo1
is-type level-2-only

CPE6

int Tun56
tunnel source lo0
tunnel destination 5.5.5.5
ip address 192.168.56.6 255.255.255.0
mpls ip
ip router isis
!
int Tun67
tunnel source lo0
tunnel destination 7.7.7.7
ip address 192.168.67.6 255.255.255.0
mpls ip
ip router isis
!
int Lo1
ip address 66.66.66.66 255.255.255.255
!
router isis
net 47.0006.0006.0006.0006.00
passive-interface lo1
is-type level-2-only

CPE7

int Tun57
tunnel source lo0
tunnel destination 5.5.5.5
ip address 192.168.57.7 255.255.255.0
mpls ip
ip router isis
!
int Tun67
tunnel source lo0
tunnel destination 6.6.6.6
ip address 192.168.67.7 255.255.255.0
mpls ip
ip router isis
!
int Lo1
ip address 77.77.77.77 255.255.255.255
!
router isis
net 47.0007.0007.0007.0007.00
is-type level-2-only
passive-interface lo1

I will use CPE5 for some show commands output and to check that everything is running fine:

R5CPE5#ping 192.168.56.6
 
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.56.6, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 44/48/52 ms
 
R5CPE5#ping 192.168.57.7
 
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.57.7, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 32/40/52 ms
 
!
R5CPE5#sh isis topology
 
IS-IS paths to level-2 routers
System Id            Metric     Next-Hop             Interface   SNPA
R5CPE5               --
R6CPE6               10         R6CPE6               Tu56        *Tunnel*       
R7CPE7               10         R7CPE7               Tu57        *Tunnel* 
!
R5CPE5#show mpls interfaces 
Interface              IP            Tunnel   Operational
Tunnel56               Yes (ldp)     No       Yes         
Tunnel57               Yes (ldp)     No       Yes 
!
R5CPE5#show mpls ldp neighbor 
    Peer LDP Ident: 6.6.6.6:0; Local LDP Ident 5.5.5.5:0
	TCP connection: 6.6.6.6.64820 - 5.5.5.5.646
	State: Oper; Msgs sent/rcvd: 16/16; Downstream
	Up time: 00:07:47
	LDP discovery sources:
	  Tunnel56, Src IP addr: 192.168.56.6
        Addresses bound to peer LDP Ident:
          10.0.26.6       6.6.6.6         192.168.56.6    192.168.67.6    
    Peer LDP Ident: 7.7.7.7:0; Local LDP Ident 5.5.5.5:0
	TCP connection: 7.7.7.7.11545 - 5.5.5.5.646
	State: Oper; Msgs sent/rcvd: 16/16; Downstream
	Up time: 00:07:26
	LDP discovery sources:
	  Tunnel57, Src IP addr: 192.168.57.7
        Addresses bound to peer LDP Ident:
          10.0.47.7       7.7.7.7         192.168.57.7    192.168.67.7

I will create now two VRF instances as I want to separate Financial department traffic from the Technical one.

On all three CPE devices:

ip vrf FIN
rd 65001:1
route-target import 65001:1
route-target export 65001:1
!
ip vrf TEK
rd 65001:2
route-target import 65001:2
route-target export 65001:2

Configuration of iBGP depends on the previous Loopback1 interfaces, so be sure that you have that interfaces reachable through IS-IS. Because it’s an iBGP and I don’t want to type the same command over and over, I will use peer-groups.

CPE5

router bgp 65001
!
neighbor OM peer-group
neighbor OM remote-as 65001
neighbor OM timers 5 20
neighbor OM description Overlay-MPLS
neighbor OM update-source lo0
!
address-family vpnv4
neighbor 66.66.66.66 peer-group OM
neighbor 77.77.77.77 peer-group OM

CPE6

router bgp 65001
neighbor OM peer-group
neighbor OM remote-as 65001
neighbor OM timers 5 20
neighbor OM description Overlay-MPLS
neighbor OM update-source lo1
!
address-family vpnv4
neighbor 55.55.55.55 peer-group OM
neighbor 77.77.77.77 peer-group OM

CPE7

router bgp 65001
neighbor OM peer-group
neighbor OM remote-as 65001
neighbor OM timers 5 20
neighbor OM description Overlay-MPLS
neighbor OM update-source lo1
!
address-family vpnv4
neighbor 55.55.55.55 peer-group OM
neighbor 66.66.66.66 peer-group OM

We should check that everything is up. I will use again CPE5:

R5CPE5#show ip bgp vpnv4 all sum | b Nei
Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
66.66.66.66     4 65001      46      46        1    0    0 00:03:30        0
77.77.77.77     4 65001      31      31        1    0    0 00:02:18        0

Finally we are getting somewhere. In real world you will have the CPE routers connected to downstream devices, using subinterfaces in particular VRF and so on. I’m short on devices, so I will use some additional Loopback interfaces and add them to VRF FIN and TEK for testing.

CPE5

int Lo51
ip vrf forwarding FIN
ip address 10.51.51.51 255.255.255.255
!
int Lo52
ip vrf forwarding TEK
ip address 10.52.52.52 255.255.255.255
!
router bgp 65001
!
address-family ipv4 vrf FIN
network 10.51.51.51 mask 255.255.255.255
!
address-family ipv4 vrf TEK
network 10.52.52.52 mask 255.255.255.255

CPE6

int Lo61
ip vrf forwarding FIN
ip address 10.61.61.61 255.255.255.255
!
int Lo62
ip vrf forwarding TEK
ip address 10.62.62.62 255.255.255.255
!
router bgp 65001
!
address-family ipv4 vrf FIN
network 10.61.61.61 mask 255.255.255.255
!
address-family ipv4 vrf TEK
network 10.62.62.62 mask 255.255.255.255

CPE7

int Lo71
ip vrf forwarding FIN
ip address 10.71.71.71 255.255.255.255
!
int Lo72
ip vrf forwarding TEK
ip address 10.72.72.72 255.255.255.255
!
router bgp 65001
!
address-family ipv4 vrf FIN
network 10.71.71.71 mask 255.255.255.255
!
address-family ipv4 vrf TEK
network 10.72.72.72 mask 255.255.255.255

To check if everything is working fine, I will use CPE5 for some tests:

R5CPE5#sh ip route vrf FIN | b Ga
Gateway of last resort is not set
 
     10.0.0.0/32 is subnetted, 3 subnets
B       10.61.61.61 [200/0] via 66.66.66.66, 00:04:42
C       10.51.51.51 is directly connected, Loopback51
B       10.71.71.71 [200/0] via 77.77.77.77, 00:02:46
!
R5CPE5#sh ip route vrf TEK | b Ga
Gateway of last resort is not set
 
     10.0.0.0/32 is subnetted, 3 subnets
B       10.62.62.62 [200/0] via 66.66.66.66, 00:04:59
C       10.52.52.52 is directly connected, Loopback52
B       10.72.72.72 [200/0] via 77.77.77.77, 00:03:04
!
R5CPE5#ping vrf FIN 10.71.71.71 source 10.51.51.51
 
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.71.71.71, timeout is 2 seconds:
Packet sent with a source address of 10.51.51.51 
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 40/44/48 ms
!
R5CPE5#ping vrf TEK 10.62.62.62 source 10.52.52.52
 
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.62.62.62, timeout is 2 seconds:
Packet sent with a source address of 10.52.52.52 
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 40/47/52 ms
!
R5CPE5#show mpls forwarding-table 
Local  Outgoing    Prefix            Bytes tag  Outgoing   Next Hop    
tag    tag or VC   or Tunnel Id      switched   interface              
16     Pop tag     192.168.67.0/24   0          Tu57       point2point  
       Pop tag     192.168.67.0/24   0          Tu56       point2point  
17     Pop tag     66.66.66.66/32    0          Tu56       point2point  
18     Pop tag     77.77.77.77/32    0          Tu57       point2point  
19     Aggregate   10.51.51.51/32[V] 1040                               
20     Aggregate   10.52.52.52/32[V] 520

You may wonder why somebody would put together such a complex configuration. There may be multiple reasons, beyond the scope of this example, but I would like to add MPLS TE, Encrypted Site-to-Site traffic with route manipulation, independent configuration from the SP, learning purposes and many more.

Can we encounter problems with this configuration? Well, yes.
If the provider has a very low MTU size support, you may get a lot of fragmentation. Also maintenance and operation of Tunnels may be tricky for a very large environment, but there are solutions to limit the number of tunnels. Still the benefits exit.

To enumerate one benefit from real world. Applying this configuration in Enterprise environment, you have the possibility to change your SP without too much of a dazzle as long as your new provider can transport the IP address of your primary Loopback interface. The rest, stays the same.

Please let me know if you have questions or if something in my explanation is wrong.


Cisco: IPv6 over IPv4 MPLS (6PE)

Let’s assume that you have an IPv4 core backbone on which you did enable MPLS. Your customers are connected to your PE routers and they need to have IPv6 reachability between their sites. To have things more clear, please have a look to the following network topology:
IPv6 transport over IPv4 MPLS

As you can see in the above image, customers have the IPv6 addresses 2001::1/128 and 2001::2/128. Actually in this topology, “my customers” are two Loopback addresses (Lo200) configured under PE routers, to minimize the used resources (routers).

We have a typical MPLS (LDP) construction with following characteristics:
– OSPF is used for IGP
– each router has a L0 interface advertised into IGP
– L0 of each router is configured as MPLS LDP router-id
– PE routers have an additional L100 interface advertised into IGP
– iBGP on the PE routers is configured using L100 interface as neighbour peer points

You can find below some output of iBGP and MPLS configuration:

PE1

router bgp 65300
 no bgp default ipv4-unicast
 bgp log-neighbor-changes
 neighbor 22.22.22.22 remote-as 65300
 neighbor 22.22.22.22 update-source Loopback0
 neighbor 22.22.22.22 timers 1 4
 !
 address-family vpnv4
  neighbor 22.22.22.22 activate
  neighbor 22.22.22.22 send-community extended
 exit-address-family
!
!
PE1#sh bgp vpnv4 unicast all sum | i 65300
BGP router identifier 11.11.11.11, local AS number 65300
22.22.22.22     4 65300    7374    7376       19    0    0 00:04:11        1
!
!
PE1#show mpls forwarding-table 
Local  Outgoing    Prefix            Bytes tag  Outgoing   Next Hop    
tag    tag or VC   or Tunnel Id      switched   interface              
16     16          22.22.22.22/32    0          Fa0/0      10.10.11.1   
17     18          10.10.22.0/24     0          Fa0/0      10.10.11.1   
18     Pop tag     10.10.12.0/24     0          Fa0/0      10.10.11.1    
20     Pop tag     1.1.1.1/32        0          Fa0/0      10.10.11.1   
21     19          2.2.2.2/32        0          Fa0/0      10.10.11.1

PE2

router bgp 65300
 no bgp default ipv4-unicast
 bgp log-neighbor-changes
 neighbor 11.11.11.11 remote-as 65300
 neighbor 11.11.11.11 update-source Loopback0
 neighbor 11.11.11.11 timers 1 4
 !
 address-family vpnv4
  neighbor 11.11.11.11 activate
  neighbor 11.11.11.11 send-community extended
 exit-address-family
!
!
PE2#show bgp vpnv4 unicast all summary | i 65300
BGP router identifier 22.22.22.22, local AS number 65300
11.11.11.11     4 65300    7518    7516       19    0    0 00:06:33        1
!
!
PE2#show mpls forwarding-table 
Local  Outgoing    Prefix            Bytes tag  Outgoing   Next Hop    
tag    tag or VC   or Tunnel Id      switched   interface              
16     17          11.11.11.11/32    0          Fa0/0      10.10.22.1   
17     Pop tag     10.10.12.0/24     0          Fa0/0      10.10.22.1   
18     18          10.10.11.0/24     0          Fa0/0      10.10.22.1                                
20     19          1.1.1.1/32        0          Fa0/0      10.10.22.1   
21     Pop tag     2.2.2.2/32        0          Fa0/0      10.10.22.1

At this point we have a functional IPv4 MPLS. Now, let’s use the MPLS to transport IPv6 networks. First, on the PE routers we have to enable IPv6 routing support and CEF:

ipv6 unicast-routing
ipv6 cef

Next, I’ll have the L200 interface configured:

PE1#show ipv6 int lo200
Loopback200 is up, line protocol is up
  IPv6 is enabled, link-local address is FE80::C002:15FF:FE10:0 
  No Virtual link-local address(es):
  Global unicast address(es):
    2001::1, subnet is 2001::1/128 
  Joined group address(es):
    FF02::1
    FF02::2
    FF02::1:FF00:1
    FF02::1:FF10:0
  MTU is 1514 bytes
  ICMP error messages limited to one every 100 milliseconds
  ICMP redirects are enabled
  ICMP unreachables are sent
  ND DAD is not supported
  ND reachable time is 30000 milliseconds
  Hosts use stateless autoconfig for addresses.
PE2#sh ipv6 int lo200
Loopback200 is up, line protocol is up
  IPv6 is enabled, link-local address is FE80::C003:15FF:FE10:0 
  No Virtual link-local address(es):
  Global unicast address(es):
    2001::2, subnet is 2001::2/128 
  Joined group address(es):
    FF02::1
    FF02::2
    FF02::1:FF00:2
    FF02::1:FF10:0
  MTU is 1514 bytes
  ICMP error messages limited to one every 100 milliseconds
  ICMP redirects are enabled
  ICMP unreachables are sent
  ND DAD is not supported
  ND reachable time is 30000 milliseconds
  Hosts use stateless autoconfig for addresses.

Now let’s make the magic and configure the PE routers so that the IPv6 networks are reachable. We will make this by using the 6PE method. This solution include that the Provider edge routers (PE) are IPv6 capable and it enables IPv6 sites to communicate with each other over an MPLS IPv4 core network using MPLS label switched paths (LSPs). To make it clear the Provider routers (P) inside MPLS have not idea about any IPv6 addressing or routing.

The 6PE routers are configured to be dual-stack using IPv4 and IPv6, and use the IPv4 mapped IPv6 address for IPv6 prefix reachability exchange. The 6PE uses multiprotocol internal BGP (MP-iBGP) to distribute IPv6 routes over the MPLS IPv4 core network and to attach an MPLS label to each route.

Let’s enable this. The BGP configuration looks like this:

PE1#
router bgp 65300
 !
 address-family ipv6 
  neighbor 22.22.22.22 activate 
  neighbor 22.22.22.22 send-label 
  network 2001::1/128 
  no synchronization 
 exit-address-family
PE2#
router bgp 65300
 !
 address-family ipv6
  neighbor 11.11.11.11 activate
  neighbor 11.11.11.11 send-label
  network 2001::2/128
  no synchronization
 exit-address-family

I did enable the BGP neighbour under IPv6 address family using the IPv4 addresses. The IPv4 addresses are already know in MPLS using the IPv4 IGP protocol (OSPF). Very important here is the send-label option as it enables binding and advertisement of aggregate labels when advertising IPv6 prefixes in BGP.

Let’s check on the PE routers if we receive properly the IPv6 addresses:

PE1#show bgp ipv6 unicast 2001::2/128
BGP routing table entry for 2001::2/128, version 16
Paths: (1 available, best #1, table Global-IPv6-Table)
  Not advertised to any peer
  Local
    ::FFFF:22.22.22.22 (metric 31) from 22.22.22.22 (22.22.22.22)
      Origin IGP, metric 0, localpref 100, valid, internal, best
      mpls labels in/out nolabel/22
!
!
PE1#show ipv6 route 2001::2/128 | b 2001::2
B   2001::2/128 [200/0]
     via ::FFFF:22.22.22.22, IPv6-mpls
PE2#show bgp ipv6 unicast 2001::1/128
BGP routing table entry for 2001::1/128, version 14
Paths: (1 available, best #1, table Global-IPv6-Table)
  Not advertised to any peer
  Local
    ::FFFF:11.11.11.11 (metric 31) from 11.11.11.11 (11.11.11.11)
      Origin IGP, metric 0, localpref 100, valid, internal, best
      mpls labels in/out nolabel/23
!
!
PE2#show ipv6 route 2001::1/128 | b 2001
B   2001::1/128 [200/0]
     via ::FFFF:11.11.11.11, IPv6-mpls

And the last test:

PE2#ping ipv6 2001::1 source 2001::2
 
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001::1, timeout is 2 seconds:
Packet sent with a source address of 2001::2
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 12/17/24 ms

If you have questions or there is something which is not clear please let me know by using the Comments section below.


MSFC, PFC and DFC on Cisco 6500 series

If you are in routing and switching industry, it’s almost impossible not to hear words like MSFC, PFC and DFC in relation with Cisco Catalyst 6500 series, chassis, supervisor and modules. If you didn’t yet, you’re not almost there, working with large enterprise environments.

Even if I see an increasing use of Nexus switches, C65k are and will still play an important role in next few years. I know that there will be voices out there standing that 6500 series is almost EoL. Nevertheless, this rumors where there also 4-5 years ago. My point is that you should know something about this platform and MSFC, PFC and DFC are playing an important role.

Anyway what are this acronyms?

MSFC (Multilayer Switch Feature Card)

Multilayer Switch Feature Card is the Layer 3 switching engine that sites on the Catalyst Supervisor as a daughter card. The MSFC is an integral part of the Supervisor Engine, providing high performance, multilayer switching and routing intelligence

PFC (Policy Feature Card)

The PFC provides the necessary ASICs to perform hardware-based Layer 3 switching, quality of service (QoS) classification, and access control list (ACL) filtering.

DFC (Distributed Feature Card)

The Distributed Feature Card (DFC) allows fabric-enabled line cards to make L3 forwarding decisions locally without requiring the L3 switching engine located on the Supervisor PFC. The DFC consists of the same components as the PFC located on the Supervisor module, however it does not contain the MSFC routing engine

This is the basic explanation for those three words, but it does not say to much, isn’t it? For more details please see the article of Sunil Khanna on Understanding MSFC, PFC and DFC roles in Catalyst 6500 Series Switch. It’s very short, comprehensive and give you a very good starting point to understand what each component does inside a C6500 series.


Cisco vs Juniper: different eBGP behavior

Last week I had to troubleshoot a problem about eBGP peering with an external provider and I think my findings will be interesting for some of you out there.

Let me start with some background information. I have two locations, same ASN, both connected to the same provider network using eBGP as routing protocol. Due to the looping prevention mechanism, default behavior in eBGP peering between Cisco equipment, is not to accept in BGP table prefixes that have in the AS-Path the same ASN as the local BGP router. You can still accept these prefixes, if you use the “allowas-in” trick on Cisco routers:

neighbor x.x.x.x allowas-in

The above command will tell BGP protocol on Cisco routers to ignore the presence of its own ASN in the AS-Path and to accept the prefixes. If all other attributes are in good standing, the routes to those prefixes will be installed in the routing table.

As a short example, take the following tolopogy:

I have a typical eBGP peering configuration. On one of the edge Cisco routers I have a Lo0 interface with 5.5.5.5/32 IP address which I advertise into BGP. Checking the middle Cisco router (provider) I can see that the BGP table has the 5.5.5.5/32 prefix installed:

sh ip bgp 5.5.5.5
BGP routing table entry for 5.5.5.5/32, version 2
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Flag: 0x820
  Advertised to update-groups:
        1
  65082
    10.10.12.1 from 10.10.12.1 (10.10.12.1)
      Origin IGP, metric 0, localpref 100, valid, external, best

Next I check if the provider router does advertise this prefix to the next neighbor:

sh ip bgp neigh 10.10.13.1 advertised-routes | i 5.5.5.5
*> 5.5.5.5/32       10.10.12.1               0             0 65082 i

From this perspective everything is fine. On the edge Cisco router, I cannot see this prefix in the BGP table, which is normal due to the reasons I explained above:

R6#sh ip bgp 5.5.5.5
% Network not in table

As soon as I add the “allowas-in” configuration on the edge Cisco router, the BGP table will contain the prefix 5.5.5.5/32:

router bgp 65082
 no synchronization
 bgp log-neighbor-changes
 neighbor 10.10.13.2 remote-as 65086
 neighbor 10.10.13.2 allowas-in
 no auto-summary
sh ip bgp 5.5.5.5    
BGP routing table entry for 5.5.5.5/32, version 2
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Flag: 0x820
  Not advertised to any peer
  65086 65082
    10.10.13.2 from 10.10.13.2 (10.10.13.2)
      Origin IGP, localpref 100, valid, external, best

Now let take the example when the provider is using Juniper technology. The eBGP peering is now between Cisco and Juniper devices:

I have configured the eBGP in the same way and I have advertised from one Cisco router the 5.5.5.5/32 prefix. 

On Juniper the BGP configuration looks like this:

yotis@J1# run show configuration protocols        
bgp {
    local-as 65086;
    group TST {
        peer-as 65082;
        neighbor 10.10.12.1;
        neighbor 10.10.13.1;
    }
}

Checking on the Juniper device I can see the prefix in the BGP table and routing table:

yotis@J1# run show route protocol bgp receive-protocol bgp 10.10.12.1    
 
inet.0: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden)
  Prefix		  Nexthop	       MED     Lclpref    AS path
* 5.5.5.5/32              10.10.12.1           0                  65082 I
 
__juniper_private2__.inet.0: 1 destinations, 1 routes (0 active, 0 holddown, 1 hidden)
yotis@J1# run show route 5.5.5.5                                         
 
inet.0: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
 
5.5.5.5/32         *[BGP/170] 01:19:15, MED 0, localpref 100
                      AS path: 65082 I
                    > to 10.10.12.1 via em1.0

On the second Cisco router, I did not change anything. The “allowas-in” command is still there:

router bgp 65082
 no synchronization
 bgp log-neighbor-changes
 neighbor 10.10.13.2 remote-as 65086
 neighbor 10.10.13.2 allowas-in
 no auto-summary

Still the prefix is not in the BGP table:

R6#show ip bgp 5.5.5.5
% Network not in table

Here is a big difference on the way eBGP protocol behave on Cisco vs. Juniper. On Cisco devices, the eBGP will send the prefixes, no matter of the peer ASN and it’s the task of the peer to apply the default policy when its own ASN is present in the AS-Path and deny the prefixes to be installed in the BGP table.

With Juniper, eBGP protocol will not even announce the prefixes if the ASN of its peer is already present in the AS-Path.

According to http://www.juniper.net/techpubs/software/junos/junos94/swconfig-routing/disabling-suppression-of-route-advertisements.html#id-13255463

“The JUNOS software does not advertise the routes learned from one external BGP (EBGP) peer back to the same EBGP peer. In addition, the software does not advertise those routes back to any EBGP peers that are in the same AS as the originating peer, regardless of the routing instance.”

There is a solution to overcome this behavior and it’s pretty simple. You can set this configuration on global basis or per group in Junos BGP configuration:

[edit protocols bgp group TST]
yotis@J1# set advertise-peer-as

Now the BGP configuration looks like this:

yotis@J1# run show configuration protocols        
bgp {
    local-as 65086;
    group TST {
        advertise-peer-as;
        peer-as 65082;
        neighbor 10.10.12.1;
        neighbor 10.10.13.1;
    }
}

If I check now the Cisco BGP table, the 5.5.5.5/32 prefix will be there:

show ip bgp 5.5.5.5
BGP routing table entry for 5.5.5.5/32, version 4
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Flag: 0x820
  Not advertised to any peer
  65086 65082
    10.10.13.2 from 10.10.13.2 (10.10.12.2)
      Origin IGP, localpref 100, valid, external, best

Don’t forget to check my Juniper, first steps after power-on the device if you are new with Juniper products. You may be interested also in my older posts Cisco: BGP path selection for outgoing traffic and Cisco: BGP path selection for inbound traffic if you just start to work with external providers.