22 Jun

MPLS workshop #3 – CE-PE connection using BGP

Our network is now able to carry vpnv4 prefixes, so it’s now time to receive them from customers. As mentioned before vpnv4 prefix consist of route distinguisher (RD) and IPv4 prefix. But that’s not all. We have to have set of tools to differ one customer from another and control propagation of prefixes. Those tools are VRFs, RDs and RTs.

Virtual Routing/Forwarding (VRF) is an routing instance we set on PE router for each customer. It’s a dedicated routing table for particular customer, separated VRF CEF and associated routing protocols. Interface on PE router can belong only to one VRF.

As mentioned in previous post RD is an identifier to distinguish same prefix from different customers and is used to create vpnv4 prefix. RD is 64-bit long. One RD must be define for each VRF but does not identify the VRF – in complex VPN scenarios more than one RD and appropriate policies could to be used. RD usually have format ASN:nn where nn is a number.

RDs are nice but not enough to provide flexible policy, especially to create extranets. Route targets (RT) are controlling communication between sites. It’s an extended BGP community that indicates which routes should be imported from MP-BGP into the VRF. There are two operations connected with RDs. Exporting means that extended community is attached to vpnv4 prefix as configured in VRF. Importing means that extended community attached to prefix received from MP-BGP is checked for matching RT. If the match is positive then prefix is inserted into particular VRF routing table. For fully isolated VPN import and export RT must be same as defined RD for this VRF.

This configuration have to be done only on PE routers that have customers using articular VPN. Let’s focus on VRF_B customer – his CE routers are connected to R3 adn R8 PE routers. Therefor our third PE router, R5, does not need any information about this VPN. The configuration on PE routers is as simple.

R3

ip vrf VRF_B
 rd 65001:1
 route-target export 65001:1
 route-target import 65001:1

R8

ip vrf VRF_B
 rd 65001:1
 route-target export 65001:1
 route-target import 65001:1

We used same RD for both PE routers. Can we use different? Yes, but more complex RT policies have to be then defined. But using different RDs is a way to filter prefixes between sites.

Next step is configuration of interfaces facing CE routers to belong to particular VRF

R3

interface Ethernet1/3
 ip vrf forwarding VRF_B
 ip address 10.0.13.3 255.255.255.0

R8

interface Ethernet1/3
 ip vrf forwarding VRF_B
 ip address 10.0.68.8 255.255.255.0

To test communication we have to issue commands using particular VRF routing table

R8#ping vrf VRF_B 10.0.68.6

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

There are few ways to distribute prefixes between PE and CE routers including static routes. In this scenario we use BGP. CE router is not MPLS-aware. This simplifies things because our customers don’t have to have any knowledge about MPLS. From CE side it’s just BGP that have to be configured. We use the following configuration.

R1

router bgp 65001
 no synchronization
 bgp log-neighbor-changes
 network 10.0.0.1 mask 255.255.255.255
 neighbor 10.0.13.3 remote-as 65111
 neighbor 10.0.13.3 allowas-in
 neighbor 10.0.13.3 soft-reconfiguration inbound
 no auto-summary

R6

router bgp 65001
 no synchronization
 bgp log-neighbor-changes
 network 10.0.0.6 mask 255.255.255.255
 neighbor 10.0.68.8 remote-as 65111
 neighbor 10.0.68.8 allowas-in
 neighbor 10.0.68.8 soft-reconfiguration inbound
 no auto-summary

We are going to advertise loopback interfaces of CE routers. All other configuration is pretty simple except maybe one thing. We used same AS number for R1 and R6. So R1 will send it’s loopback prefix 10.0.0.1/32 with AS_PATH of 65001. This prefix will be advertised by R8 to R6 with AS_PATH of 65111 65001. By default R6 will drop this prefix because it’s own AS number is already in AS_PATH so it suspects loop. There are two solutions of this problem. First is to use different AS number for each CE router. Some administrators do this but in my opinion is not really flexible especially in large networks with many customers. Second option is to use allowas-in option. This let BGP accept prefixes with own AS number in AS_PATH on eBGP session. As a parameter maximum occurrence of own AS number can be set.

Now lets focus on PE routers. To connect session with particular VRF we have to put in under appropriate address-family. All other configuration is same as for global table.

R3

router bgp 65111
 no bgp default ipv4-unicast
 bgp log-neighbor-changes
 neighbor 10.0.13.1 remote-as 65001
 !        
 address-family ipv4 vrf VRF_B
  no synchronization
  neighbor 10.0.13.1 remote-as 65001
  neighbor 10.0.13.1 activate
  neighbor 10.0.13.1 send-community both
  neighbor 10.0.13.1 soft-reconfiguration inbound
 exit-address-family

R8

router bgp 65111
 no bgp default ipv4-unicast
 bgp log-neighbor-changes
 neighbor 10.0.68.6 remote-as 65001
 !
 address-family ipv4 vrf VRF_B
  no synchronization
  neighbor 10.0.68.6 remote-as 65001
  neighbor 10.0.68.6 activate
  neighbor 10.0.68.6 send-community both
  neighbor 10.0.68.6 soft-reconfiguration inbound
 exit-address-family

We can verify now if prefixes are correctly distributed on PE and CE routers

R8

R8#show ip bgp vpnv4 vrf VRF_B
BGP table version is 10, local router ID is 10.0.0.8
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
Route Distinguisher: 65001:1 (default for vrf VRF_B)
*>i10.0.0.1/32      10.0.0.3                 0    100      0 65001 i
*> 10.0.0.6/32      10.0.68.6                0             0 65001 i

R6

R6#sh ip bgp
BGP table version is 3, local router ID is 10.0.0.6
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 10.0.0.1/32      10.0.68.8                              0 65111 65001 i
*> 10.0.0.6/32      0.0.0.0                  0         32768 i

We can also troubleshoot path from R6 do R1 using traceroute command. This also gives us additional information how labels changes between routers.

R6#traceroute 10.0.0.1 source loopback 0

Type escape sequence to abort.
Tracing the route to 10.0.0.1

  1 10.0.68.8 0 msec 0 msec 0 msec
  2 10.0.89.9 [MPLS: Labels 21/26 Exp 0] 0 msec 0 msec 0 msec
  3 10.0.49.4 [MPLS: Labels 16/26 Exp 0] 0 msec 0 msec 0 msec
  4 10.0.13.3 [MPLS: Labels 0/26 Exp 0] 0 msec 0 msec 0 msec
  5 10.0.13.1 4 msec *  0 msec

More troubleshooting in future.

6 thoughts on “MPLS workshop #3 – CE-PE connection using BGP

  1. You have another option is to use BGP as-override on the PEs instead of allowas-in on CEs. And with BGP as the PE-CE protocol you can have the case where there is a backdoor link on CE Side, so to prevent from looping or suboptimal routing you can use the BGP SOO extended community.

  2. Pingback: Mpls Connection Definition | MPLS

Leave a Reply

%d bloggers like this: