mpls vpn... watch out's...

as i posted earlier in the week, the first thing i did was to build the leviathan's interfaces, verify connectivity and save... let's take a moment and look at stretch's good advice..

from: http://packetlife.net/blog/2011/may/16/creating-mpls-vpn/

• P (provider) routers are ISP core routers which don't connect to customer routers and typically run only MPLS
• PE (provider edge) routers connect to customer sites and form the edge of a VPN
• CE (customer edge) routers exist at the edge of a customer site; they have no VPN awareness
• an IGP running among all P and PE routers is used to support LDP and BGP adjacencies within the provider network
• MP-BGP is run only among PE routers
• an IGP (typically) is run between each CE router and its upstream PE router

There are five core tasks we need to accomplish to get an MPLS VPN up and running:

1. Enable MPLS on the provider backbone.
2. Create VRFs and assign routed interfaces to them.
3. Configure MP-BGP between the PE routers.
4. Configure OSPF between each PE router and its attached CE routers.
5. Enable route redistribution between the customer sites and the backbone.

in the above topology we know that the isp core routers are r4, r5, r6 and r7, these connect to the pe routers, or r2 and r9, which connect to the four customer routers r1, r3, r8 and r10...

my big mistake number 1... when i read that the loopbacks needed to be /32's, i took that to heart, and as above i made each customer router loopback a /32... my suggestions here  are not gospel, merely what i learned while attempting to put this thing together so take all of this with a grain of salt, or appeal to a higher authority for definitive confirmation... but remember, mine works... that said, before launching ospf and mpls,  make loopbacks on all the routers, or manually make router-id's for each and every router... this will prevent the router id from latching on to a hardware  interface in the topology... i prefer loopbacks, as always... after struggling with this for some time, i eventually made loopbacks for every router on a separate network, ie:

r2#sh run int lo0
Building configuration...

Current configuration : 64 bytes
!
interface Loopback0
 ip address 10.0.0.2 255.255.255.255

r9#sh run int lo0
Building configuration...

Current configuration : 64 bytes
!
interface Loopback0
 ip address 10.0.0.9 255.255.255.255

note my insanity of making the addresses correspond with the router number... your insanity will be different, but i prefer my insanity...

DO THIS BEFORE LAUNCHING OSPF, if not, you will have to reload ospf on each router to get the router id off of the hardware interface it assigned to it, and onto the loopback... also add the loopback to the ospf network... i didn't test that mpls requires each loopback to be /32's, but i read it enough times to simply trust and avoid that...

did i mention make loopbacks on all the routers and make them /32's...

launch ospf and check connectivity of the entire network... if you use my numbering scheme you will end up with a very pretty ospf table... if you feel you must use /30's and public address space for a more realistic look, have at it...

i then enabled ip cef on every router... i stress every router, that includes the customer routers...  mpls ip is only needed on the connected core and pe router interfaces, it is not needed on the interfaces of the customer routers, nor on the pe interfaces connecting  to the ce's... in other words, do not put mpls ip on the interfaces connecting the 172.16 and 192.168 networks...

r1#sh mpls inter
no MPLS apps enabled or MPLS not enabled on any interfaces

r2#sh mpls int
Interface              IP            Tunnel   BGP Static Operational
FastEthernet1/0        Yes (ldp)     No       No  No     Yes       
FastEthernet1/1        Yes (ldp)     No       No  No     Yes 

again, note r2 (pe1) has mpls only on interfaces connecting to the core isp...

this is all about you (and me in the future) making mistakes that can be avoided...

nothing more will need to be done with the customer routers... they will be acted upon by the pe's...

vrf's...

i am not going to explain vrf's... if you need to know more about them, go here:
http://insearchofthecert.blogspot.com/2012/05/vrf-road-to-mpls.html

i used stretch's model... http://packetlife.net/blog/2011/may/16/creating-mpls-vpn/

on pe1 and pe2 (r2, r9) in global configuration mode add:

ip vrf cust_a

this puts you in vrf configuration mode for customer A, or whatever you want to call it...

rd 65000:1

is the route distinguisher, these numbers may be substituted...

route-target both 65000:1

route-target both precludes you from typing import and export separately...

do the same for cust_b but change the route distinguisher to:

rd 65000:2

add ip vrf forwarding cust_a to the interface that connects the pe's to the ce's (r2 to r1 in this case) do the same for cust_b (r2 to r3), and do this for pe2  on each ce connected interface... it is going to disable the ip address... simply retype the ip address back into the interface after...

r2#sh run int f0/0
Building configuration...

Current configuration : 139 bytes
!
interface FastEthernet0/0
 ip vrf forwarding cust_a
 ip address 172.16.1.1 255.255.255.0

r2#sh run int f0/1
Building configuration...

Current configuration : 140 bytes
!
interface FastEthernet0/1
 ip vrf forwarding cust_b
 ip address 192.168.1.1 255.255.255.0

r2#sh ip vrf inter
Interface              IP-Address      VRF                              Protocol
Fa0/0                  172.16.1.1      cust_a                           up     
Fa0/1                  192.168.1.1     cust_b                           up     

r9#sh ip vrf inte
Interface              IP-Address      VRF                              Protocol
Fa0/0                  172.16.2.1      cust_a                           up     
Fa0/1                  192.168.2.1     cust_b                           up     

here is where the router id starts to haunt you... on the pe's i used bgp 65000, ala stretch... you can use different numbers, just follow through properly... where i could make it easy, i made it easy...

r2#sh run | sec router bgp
router bgp 65000
 bgp log-neighbor-changes
 neighbor 10.0.0.9 remote-as 65000
 neighbor 10.0.0.9 update-source Loopback0
 !
 address-family vpnv4
  neighbor 10.0.0.9 activate

r9#sh run | section router bgp
router bgp 65000
 bgp log-neighbor-changes
 neighbor 10.0.0.2 remote-as 65000
 neighbor 10.0.0.2 update-source Loopback0
 !
 address-family vpnv4
  neighbor 10.0.0.2 activate

when you have performed this correctly, you should now see these additions on both pe's...

r2#sh run | sec router bgp
router bgp 65000
 bgp log-neighbor-changes
 neighbor 10.0.0.9 remote-as 65000
 neighbor 10.0.0.9 update-source Loopback0
 !
 address-family vpnv4
  neighbor 10.0.0.9 activate
  neighbor 10.0.0.9 send-community extended
 exit-address-family
 !
 address-family ipv4 vrf cust_a
  exit-address-family
 !
 address-family ipv4 vrf cust_b
  exit-address-family

with this, you have successfully created an mp-bgp link between the pe's...

note the router id...

with the configuration in it's original ospf state, i created process id's of 1 throughout in area 0... with the vrf's now in place, separate ospf processes need to be assigned for each vrf...

r2#sh run | section router ospf 2
router ospf 2 vrf cust_a
 router-id 172.16.1.1


WARNING... notice the router-id for process 2 is the interface ip for the pe connected to customer A...  when i tried to use the router-id assigned to process 1:

r2#sh ip ospf
 Routing Process "ospf 1" with ID 10.0.0.2

it would complain that the id was assigned to process 1... makes sense..

r2#sh run | section router ospf 3
router ospf 3 vrf cust_b
 router-id 192.168.1.1

do the same for the other pe...

r9#sh run | sec router ospf 2
router ospf 2 vrf cust_a
 router-id 172.16.2.1

r9#sh run | sec router ospf 3
router ospf 3 vrf cust_b
 router-id 192.168.2.1

verify each vrf route from the pe's with:

sh ip route vrf cust_a

sh ip vrf route cust_b

payoff time... redistribution... for each ospf process into bgp...

router bgp 65000
address-family ipv4 vrf cust_a
  redistribute ospf 2
 address-family ipv4 vrf cust_b
  redistribute ospf 3

and for bgp into each ospf process...

r2#sh run | sec router ospf 2
router ospf 2 vrf cust_a
 router-id 172.16.1.1
 redistribute bgp 65000 subnets

r2#sh run | sec router ospf 3
router ospf 3 vrf cust_b
 router-id 192.168.1.1
 redistribute bgp 65000 subnets

the finished bgp product on each pe:

r9#sh run | section router bgp 65000
router bgp 65000
 bgp log-neighbor-changes
 neighbor 10.0.0.2 remote-as 65000
 neighbor 10.0.0.2 update-source Loopback0
 !
 address-family vpnv4
  neighbor 10.0.0.2 activate
  neighbor 10.0.0.2 send-community extended
 exit-address-family
 !
 address-family ipv4 vrf cust_a
  redistribute ospf 2
 exit-address-family
 !
 address-family ipv4 vrf cust_b
  redistribute ospf 3
 exit-address-family

r2#sh run | sec router bgp 65000
router bgp 65000
 bgp log-neighbor-changes
 neighbor 10.0.0.9 remote-as 65000
 neighbor 10.0.0.9 update-source Loopback0
 !
 address-family vpnv4
  neighbor 10.0.0.9 activate
  neighbor 10.0.0.9 send-community extended
 exit-address-family
 !
 address-family ipv4 vrf cust_a
  redistribute ospf 2
 exit-address-family
 !
 address-family ipv4 vrf cust_b
  redistribute ospf 3
 exit-address-family

and ospf...

r2#sh run | section router ospf
router ospf 2 vrf cust_a
 router-id 172.16.1.1
 redistribute bgp 65000 subnets
router ospf 3 vrf cust_b
 router-id 192.168.1.1
 redistribute bgp 65000 subnets
router ospf 1
 network 10.0.0.2 0.0.0.0 area 0
 network 10.1.1.0 0.0.0.255 area 0
 network 10.1.2.0 0.0.0.255 area 0
 network 172.16.1.0 0.0.0.255 area 0
 network 192.168.1.0 0.0.0.255 area 0


r9#sh run | sect router ospf
router ospf 2 vrf cust_a
 router-id 172.16.2.1
 redistribute bgp 65000 subnets
router ospf 3 vrf cust_b
 router-id 192.168.2.1
 redistribute bgp 65000 subnets
router ospf 1
 network 10.0.0.9 0.0.0.0 area 0
 network 10.1.5.0 0.0.0.255 area 0
 network 10.1.6.0 0.0.0.255 area 0
 network 172.16.2.0 0.0.0.255 area 0
 network 192.168.2.0 0.0.0.255 area 0

IA entries never looked so sweet...

r1#sh ip route | exc L | inc loop
    

Gateway of last resort is not set

      1.0.0.0/32 is subnetted, 1 subnets
C        1.1.1.1 is directly connected, Loopback1
      3.0.0.0/32 is subnetted, 1 subnets
O IA     3.3.3.3 [110/3] via 172.16.1.1, 11:21:31, FastEthernet0/0
      172.16.0.0/16 is variably subnetted, 3 subnets, 2 masks
C        172.16.1.0/24 is directly connected, FastEthernet0/0
O IA     172.16.2.0/24 [110/2] via 172.16.1.1, 11:21:31, FastEthernet0/0

r8#sh ip route | exc L | inc loop
     
Gateway of last resort is not set

      1.0.0.0/32 is subnetted, 1 subnets
O IA     1.1.1.1 [110/3] via 172.16.2.1, 11:21:21, FastEthernet0/0
      3.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C        3.3.3.0/24 is directly connected, Loopback3
      172.16.0.0/16 is variably subnetted, 3 subnets, 2 masks
O IA     172.16.1.0/24 [110/2] via 172.16.2.1, 11:21:21, FastEthernet0/0
C        172.16.2.0/24 is directly connected, FastEthernet0/0

r3#sh ip route | ex L | in loop
   
Gateway of last resort is not set

      2.0.0.0/32 is subnetted, 1 subnets
C        2.2.2.2 is directly connected, Loopback2
      4.0.0.0/32 is subnetted, 1 subnets
O IA     4.4.4.4 [110/3] via 192.168.1.1, 11:22:34, FastEthernet0/1
      192.168.1.0/24 is variably subnetted, 2 subnets, 2 masks
C        192.168.1.0/24 is directly connected, FastEthernet0/1
O IA  192.168.2.0/24 [110/2] via 192.168.1.1, 11:22:34, FastEthernet0/1

r10#sh ip route | ex L | in loop
     
Gateway of last resort is not set

      2.0.0.0/32 is subnetted, 1 subnets
O IA     2.2.2.2 [110/3] via 192.168.2.1, 11:22:24, FastEthernet0/1
      4.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C        4.4.4.0/24 is directly connected, Loopback4
O IA  192.168.1.0/24 [110/2] via 192.168.2.1, 11:22:24, FastEthernet0/1
      192.168.2.0/24 is variably subnetted, 2 subnets, 2 masks
C        192.168.2.0/24 is directly connected, FastEthernet0/1

r1#ping 4.4.4.4
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 4.4.4.4, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
r1#ping 3.3.3.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 12/20/28 ms

thanks stretch, packetlife, and socketready...