CCIE Home Lab, what to do when your router has too little Flash space for IOS

I already explained in an older post my home lab for CCIE preparation. My BB1-BB3 routers are Cisco 2600 series and the rest of R1-R6 are emulated with Dynamips. The only problem is that one of the C2600 has too little Flash space to hold the required IOS. Memory is sufficient, but Flash not.

The only workaround I have is to load the IOS image from a TFTP server. I will explain here my procedure, maybe it’s useful for somebody else out there.

First, I recently upgrade to Ubuntu 12.04 and for some reason the TFTPD (default tftp server) was not working properly. I found TFTPD-HPA to be a good alernative, so I did install it:

sudo apt-get install tftpd-hpa

After installation you may want to check /etc/default/tftpd-hpa. On my system it looks like this:

# /etc/default/tftpd-hpa
 
TFTP_USERNAME="tftp"
TFTP_DIRECTORY="/var/lib/tftpboot"
TFTP_ADDRESS="0.0.0.0:69"
TFTP_OPTIONS="--secure"

Next step is to get a IOS image and copy it under /var/lib/tftpboot. If you need a hint, I’m using c2600-adventerprisek9-mz.124-25d.bin which needs only a small amount of memory to be installed on the Cisco 2600 platform and it’s enough for testing.

Now we need to get the IOS image on the C2600 using TFTP. Depending on your topology used for CCIE exam practice, this can be done in different ways.

Currently I’m using the workbooks from Micronicstraining (Narbik’s workbooks, if this sounds more familiar). Previously I used the ones from Internetwork Expert. The idea is that topology is pretty similar and it looks something like this:

MicronicsTraining
Narbik’s workbook topology

My problematic router is the BB3. Somehow I need that BB3 is communicating with my Ubuntu server, as simple as possible, without changing ethernet cables all the time.
You noticed int the above diagram that BB3 has an interface on the SW1 (Fa0/13) and SW1 has F0/1 connected to my Ubuntu server as explained in this post. What I need is to have Fa0/13 and Fa0/1 on the SW1 on the same VLAN for proper communication. Usually I just default the interface and then everything is fine.

On the Ubuntu box, I can have an IP address on the physical card (this will not influence in any way the Dynamips emulated router attached to this interface):

eth1      Link encap:Ethernet  HWaddr 00:e0:b6:06:a6:3b
          inet addr:192.168.182.1  Bcast:192.168.182.255  Mask:255.255.255.0
          inet6 addr: fe80::2e0:b6ff:fe06:a63b/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:64 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:14100 (14.1 KB)

By default on the BB3 router I have an IOS image that can fit the Flash size (c2600-i-mz.123-26.bin) and in case that for some reasons the TFTP Server is not reachable, it will boot that image.

The BB3 startup-configuration looks like this:

interface FastEthernet0/0
 ip address 192.168.182.13 255.255.255.0
!
boot system tftp c2600-adventerprisek9-mz.124-25d.bin 192.168.182.1

What you have to remember:
1. Start your TFTP server and assure that it has the correct IP address on the interface where you will server IOS files
2. Start your switch (if you have one in between Cisco router and the TFTP server) and be sure that the interfaces are able to exchange packet (same VLAN, etc)
3. Start your Router

In case you did miss any of the above steps, you’ll see something like this:

%SYS-4-CONFIG_NEWER: Configuration from version 12.4 may not be correctly understood
 Slot is empty or does not support clock participate
 WIC slot is empty or does not support clock participate
%SYS-6-READ_BOOTFILE_FAIL: tftp://192.168.182.1/c2600-adventerprisek9-mz.124-25d.bin File read failed -- Timed out.
 
 Hello from IFS_TYPE_ROM successful type-check
 
%SYS-6-BOOT_MESSAGES: Messages above this line are from the boot loader.
boot of "tftp:c2600-adventerprisek9-mz.124-25d.bin 192.168.182.1" using boot helper "flash:c2600-i-mz.123-26.bin" failed
error returned: File read failed -- Timed out
loadprog: error - on file open
boot: cannot load "tftp:c2600-adventerprisek9-mz.124-25d.bin 192.168.182.1"

and the router will boot your image stored locally on Flash.

Instead of doing all this work, which may generate some headache, I could just buy another router with enough Flash (and Memory). Currently I don’t want to make this investment, so I’ll stick with the above scenario.


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.


vCSA Web Management Network error

A few days ago I installed two additional NICs in my server that handle the virtual machine for vCenter Server Appliance (vCSA).

After the NICs installation, the Management web interface for vCSA was showing some strange error (see image below).

Safari:

vCenter Server Appliance

Firefox:

vCenter Server Appliance

I added two images to show you that the error is almost the same and not browser related.

Next I went online and tried to find a way to fix this issue. Among other stuff I also updated the vCSA, but unfortunately nothing helped.

Finally after a lot of research I found the trouble to be caused not by the VMware code, but something in SUSE Linux OS (on which vCSA is built on). Apparently I had to manually add the new NICs configuration in SUSE:

vi /etc/sysconfig/networking/devices/ifcfg-eth2

Add the follwing lines:

DEVICE=eth2
BOOTPROTO='static'
STARTMODE='auto'
TYPE=Ethernet
USERCONTROL='no'
IPADDR='10.0.0.35'
NETMASK='255.255.255.0'
BROADCAST='10.0.0.255'

Then add a symbolic link in the right place:

ln -s /etc/sysconfig/networking/devices/ifcfg-eth2 /etc/sysconfig/network/ifcfg-eth2

You need this configuration for each one of your NICs. Of course you need to adapt the configuration for your NICs (eth1, eth2…)

It looks better now:

vCenter Server Appliance

There may be an easier way to fix this problem, but for me, the above solution worked just fine. If you encounter this error and fix it in another way, please feel free to let me know.

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.