BGP PE-CE Routing Protocol Overview In MPLS VPNs-Part II

Introduction:

In previous document we have seen implementation of MPLS VPN BGP PE-CE routing protocol in which customer was using different AS number between their sites. In this document we will see BGP PE-CE sites implementation using same AS numbers.

If customer use the same AS number between his sites, the BGP loop prevention mechanism disallows customer sites having identical AS numbers to be linked by another AS number. In other words, routing updates from one site would be dropped when the other site receives them; therefore, connectivity cannot be established between the sites without additional configuration on the Service provider PE routers.

Topology Diagram:

This configuration scenario demonstrates BGP PE-CE routing for VPN sites using same BGP AS numbers. The above topology shows Customer A is using BGP AS 65001 for Site-1 and 65001 at Sites 2.

BGP loop prevention Mechanism:

When CE1 send its routing information update Over BGP VPNv4 and reached to CE2 via PE2, CE2 checks the update and finds AS 65001 in the AS-PATH ; therefore due to BGP loop prevention mechanism CE2-B rejects the 192.168.2.0/24 update from PE2 because it finds its own AS in the update.

BGP AS Override feature:

To overcome above problem you can use BGP AS Override functionality on PE routers. The AS Override function causes all leading occurrences of the AS number of the receiving BGP router to be replaced with the AS number of the sending BGP router.

When you use BGP AS Override functionality, PE2 router will replace AS 65001 in the AS-PATH with its own AS number, which is 1 and send it to CE2 as shown below in diagram:

Configuration Overview:

Basic Configuration:

PE1 Router:	PE2 Router:	P Router	CE1 Router	CE2 Router
hostname PE1 ip cef ! interface Loopback0 ip address 172.16.1.1 255.255.255.255 ! interface FastEthernet0/0 ip address 192.168.1.1 255.255.255.252 duplex auto speed auto ! interface FastEthernet1/0 ip address 10.1.1.1 255.255.255.252 speed 100 full-duplex mpls ip ! router ospf 100 log-adjacency-changes network 10.1.1.1 0.0.0.0 area 0 network 172.16.1.1 0.0.0.0 area 0 ! router bgp 1 no synchronization bgp log-neighbor-changes neighbor 172.16.1.2 remote-as 1 no auto-summary ! address-family vpnv4   neighbor 172.16.1.2 activate   neighbor 172.16.1.2 send-community extended exit-address-family ! mpls ldp router-id Loopback0	hostname PE2 ip cef ! interface Loopback0 ip address 172.16.1.2 255.255.255.255 ! interface FastEthernet0/0 ip address 192.168.1.5 255.255.255.252 duplex auto speed auto ! interface FastEthernet1/0 ip address 10.1.1.6 255.255.255.252 speed 100 full-duplex mpls ip ! router ospf 100 log-adjacency-changes network 10.1.1.6 0.0.0.0 area 0 network 172.16.1.2 0.0.0.0 area 0 ! router bgp 1 no synchronization bgp log-neighbor-changes neighbor 172.16.1.1 remote-as 1 neighbor 172.16.1.1 update-source Loopback0 no auto-summary ! address-family vpnv4   neighbor 172.16.1.1 activate   neighbor 172.16.1.1 send-community extended exit-address-family ! mpls ldp router-id Loopback0	hostname P ip cef ! interface FastEthernet0/0 ip address 10.1.1.2 255.255.255.252 mpls ip ! interface FastEthernet0/1 ip address 10.1.1.5 255.255.255.252 mpls ip ! router ospf 100 log-adjacency-changes network 10.1.1.0 0.0.0.7 area 0	hostname CE1 ip cef ! interface FastEthernet0/0 ip address 192.168.1.2 255.255.255.252 ! interface FastEthernet0/1 ip address 192.168.2.1 255.255.255.0 ! router bgp 65001 no synchronization bgp log-neighbor-changes network 192.168.2.0 mask 255.255.255.0 neighbor 192.168.1.1 remote-as 1 no auto-summary	hostname CE2 ip cef ! interface FastEthernet0/0 ip address 192.168.1.6 255.255.255.252 ! interface FastEthernet0/1 ip address 192.168.3.1 255.255.255.0 ! router bgp 65001 no synchronization bgp log-neighbor-changes network 192.168.3.0 mask 255.255.255.0 neighbor 192.168.1.5 remote-as 1 no auto-summary

We have BGP vpnv4 neighbors hip up between PE1 and PE2 can be verify as shown below:

PE1#sh ip bgp vpnv4 all summary | beg Nei

Neighbor       V   AS MsgRcvd MsgSent   TblVer InQ OutQ Up/Down State/PfxRcd

172.16.1.2     4     1     11     11       1    0   0 00:08:43       0

PE2#sh ip bgp vpnv4 all summary | beg Nei

Neighbor       V   AS MsgRcvd MsgSent   TblVer InQ OutQ Up/Down State/PfxRcd

172.16.1.1     4     1     11     11       1   0   0 00:08:21       0

Configuration Steps for BGP PE-CE routing:

Step 1:Define VRF Cust_A on PE Routers PE1 and PE2:

Define VRF Cust_A on PE Routers PE1 and PE2 and apply on VRF on Physical interface facing customer.

PE1#conf t

PE1(config)#ip vrf Cust_A

PE1(config-vrf)#description Customer-A

PE1(config-vrf)# rd 1:100

PE1config-vrf)# route-target both 1:100

PE1(config)#int fa0/0

PE1(config-if)#ip vrf forwarding Cust_A

PE1(config-if)#ip add 192.168.1.1 255.255.255.252

PE1(config-if)#exit

PE2#conf t

PE2(config)#ip vrf Cust_A

PE2(config-vrf)#description Customer-A

PE2(config-vrf)# rd 1:100

PE2config-vrf)# route-target both 1:100

PE2(config-vrf)#exit

PE2(config)#int fa0/0

PE2(config-if)#ip vrf forwarding Cust_A

PE2(config-if)#ip add 192.168.1.5 255.255.255.252

PE2(config-if)#exit

Step 2:Configure per VRF BGP routing context on PE routers; Define & Activate BGP CE neighbors:

Configure per VRF BGP routing for Cust_A under the BGP routing process on PE1 and PE2 and under the BGP VRF routing context mention the remote BGP CE neighbors and activated as shown below.

PE1#conf t

Enter configuration commands, one per line. End with CNTL/Z.

PE1(config)#router bgp 1

PE1(config-router)#address-family ipv4 vrf Cust_A

PE1(config-router-af)#neighbor 192.168.1.2 remote-as 65001

PE1(config-router-af)#neighbor 192.168.1.2 activate

PE1(config-router-af)#exit

PE2#conf t

Enter configuration commands, one per line. End with CNTL/Z.

PE2(config)#router bgp 1

PE2(config-router)#address-family ipv4 vrf Cust_A

PE2(config-router-af)#nei 192.168.1.6 remote-as 65001

PE2(config-router-af)#nei 192.168.1.6 activate

PE2(config-router-af)#exit

Step 3:Configure BGP AS Override command on PE1 and PE2 under BGP VRF address family:

PE1#conf t

Enter configuration commands, one per line. End with CNTL/Z.

PE1(config)#router bgp 1

PE1(config-router)#address-family ipv4 vrf Cust_A

PE1(config-router-af)#neighbor 192.168.1.2 as-override

PE1(config-router-af)#exit

PE2#conf t

Enter configuration commands, one per line. End with CNTL/Z.

PE2(config)#router bgp 1

PE2(config-router)#address-family ipv4 vrf Cust_A

PE2(config-router-af)#neighbor 192.168.1.6 as-override

PE2(config-router-af)#exit

Verification of BGP PE-CE Routing Implemention:

Step 1:Verify BGP neighbor relationship on PE1 and PE2 with CE1 and CE2 respectively:

Verify the BGP neighbor relationship between PE-CE routers. Below output shows that the BGP neighbor relationship is established between PE1 and CE1 and PE2 with CE2.

PE1#sh bgp vpnv4 unicast vrf Cust_A summary | beg Nei

Neighbor       V   AS MsgRcvd MsgSent   TblVer InQ OutQ Up/Down State/PfxRcd

192.168.1.2     4 65001     16     16       4   0   0 00:11:32       1

PE2#sh bgp vpnv4 unicast vrf Cust_A summary | beg Nei

Neighbor       V   AS MsgRcvd MsgSent   TblVer InQ OutQ Up/Down State/PfxRcd

192.168.1.6     4 65002     13     13      4   0   0 00:08:24       1

Step 2:Verify BGP VPNv4 routing table on PE1 and PE2:

PE1 has two prefixes in the BGP table from the remote PE router, 192.168.2.0 is learn from CE1 and 192.168.3.0 from PE2

PE1#sh bgp vpnv4 unicast vrf Cust_A

BGP table version is 4, local router ID is 172.16.1.1

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: 1:100 (default for vrf Cust_A)

*> 192.168.2.0     192.168.1.2             0             0 65001 i

*>i192.168.3.0     172.16.1.2               0   100     0 65002 i

Similar output is also seen on PE2

PE2#sh bgp vpnv4 unicast vrf Cust_A

BGP table version is 4, local router ID is 172.16.1.2

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: 1:100 (default for vrf Cust_A)

*>i192.168.2.0     172.16.1.1               0   100     0 65001 i

*> 192.168.3.0     192.168.1.6             0             0 65002 i

Step 3:Check the VRF routing table on both PE:

Check the routing table of VRF Cust_A must show routes learn from neigboring PE

PE1#sh ip route vrf Cust_A | beg Gate

Gateway of last resort is not set

     192.168.1.0/30 is subnetted, 1 subnets

C       192.168.1.0 is directly connected, FastEthernet0/0

B   192.168.2.0/24 [20/0] via 192.168.1.2, 00:28:37

B   192.168.3.0/24 [200/0] via 172.16.1.2, 00:24:58

PE2#sh ip route vrf Cust_A | beg Gate

Gateway of last resort is not set

     192.168.1.0/30 is subnetted, 1 subnets

C       192.168.1.4 is directly connected, FastEthernet0/0

B   192.168.2.0/24 [200/0] via 172.16.1.1, 00:28:56

B   192.168.3.0/24 [20/0] via 192.168.1.6, 00:25:31

Step 4:Verify end-to-end connectivity:

Verifying end-to-end connectivity between CE1 and CE2 by issuing a ping from CE1 to network 192.168.3.1/24 on CE2 and vice versa

CE1#ping 192.168.3.1 so 192.168.2.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 192.168.3.1, timeout is 2 seconds:

Packet sent with a source address of 192.168.2.1

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 56/76/104 ms

CE2#ping 192.168.2.1 so 192.168.3.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 192.168.2.1, timeout is 2 seconds:

Packet sent with a source address of 192.168.3.1

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 52/84/104 ms

Inter-AS MPLS VPN Options

I have been going through some Inter-AS MPLS VPN labs over the past couple of days. There are basically 3 different methods to achieve Inter-AS connectivity for MPLS VPNS.

Option 10A – Back to Back VRFs between ASBRs
Option 10B – VPNv4 eBGP between ASBRs
Option 10C – VPNv4 between RRs or PEs using multihop eBGP

I have labbed up all three of these methods along with the some slight variations on the specific configuration options within each of them and will be writing these up in the coming days.

These are described in RFC 2547bis of which an extract is below.

10. Multi-AS Backbones

What if two sites of a VPN are connected to different Autonomous Systems (e.g., because the sites are connected to different SPs)? The PE routers attached to that VPN will then not be able to maintain IBGP connections with each other, or with a common route reflector. Rather, there needs to be some way to use EBGP to distribute VPN-IPv4 addresses.

There are a number of different ways of handling this case, which we present in order of increasing scalability.

a) VRF-to-VRF connections at the AS (Autonomous System) border routers.

In this procedure, a PE router in one AS attaches directly to a PE router in another. The two PE routers will be attached by multiple sub-interfaces, at least one for each of the VPNs whose routes need to be passed from AS to AS. Each PE will treat the other as if it were a CE router. That is, the PEs associate each such sub-interface with a VRF, and use EBGP to distribute unlabeled IPv4 addresses to each other.

This is a procedure that “just works”, and that does not require MPLS at the border between ASes. However, it does not scale as well as the other procedures discussed below.

b) EBGP redistribution of labeled VPN-IPv4 routes from AS to neighboring AS.

In this procedure, the PE routers use IBGP to redistribute labeled VPN-IPv4 routes either to an Autonomous System Border Router (ASBR), or to a route reflector of which an ASBR is a client. The ASBR then uses EBGP to redistribute those labeled VPN-IPv4 routes to an ASBR in another AS, which in turn distributes them to the PE routers in that AS, or perhaps to another ASBR which in turn distributes them …

When using this procedure, VPN-IPv4 routes should only be accepted on EBGP connections at private peering points, as part of a trusted arrangement between SPs. VPN-IPv4 routes should neither be distributed to nor accepted from the public Internet, or from any BGP peers which are not trusted. An ASBR should never accept a labeled packet from an EBGP peer unless it has actually distributed the top label to that peer.

If there are many VPNs having sites attached to different Autonomous Systems, there does not need to be a single ASBR between those two ASes which holds all the routes for all the VPNs; there can be multiple ASBRs, each of which holds only the routes for a particular subset of the VPNs.

This procedure requires that there be a label switched path leading from a packet’s ingress PE to its egress PE. Hence the appropriate trust relationships must exist between and among the set of ASes along the path. Also, there must be agreement among the set of SPs as to which border routers need to receive routes with which Route Targets.

c) Multihop EBGP redistribution of labeled VPN-IPv4 routes between source and destination ASes, with EBGP redistribution of labeled IPv4 routes from AS to neighboring AS.

In this procedure, VPN-IPv4 routes are neither maintained nor distributed by the ASBRs. An ASBR must maintain labeled IPv4 /32 routes to the PE routers within its AS. It uses EBGP to distribute these routes to other ASes. ASBRs in any transit ASes will also have to use EBGP to pass along the labeled /32 routes. This results in the creation of a label switched path from the ingress PE router to the egress PE router. Now PE routers in different ASes can establish multi-hop EBGP
connections to each other, and can exchange VPN-IPv4 routes over those connections.

If the /32 routes for the PE routers are made known to the P routers of each AS, everything works normally. If the /32 routes for the PE routers are NOT made known to the P routers (other than the ASBRs), then this procedure requires a packet’s ingress PE to put a three label stack on it. The bottom label is assigned by the egress PE, corresponding to the packet’s destination address in a particular VRF. The middle label is assigned by the ASBR, corresponding to the /32 route to the
egress PE. The top label is assigned by the ingress PE’s IGP Next Hop, corresponding to the /32 route to the ASBR.

To improve scalability, one can have the multi-hop EBGP connections exist only between a route reflector in one AS and a route reflector in another. (However, when the route reflectors distribute routes over this connection, they do not modify the BGP next hop attribute of the routes.) The actual PE routers would then only have IBGP connections to the route reflectors in their own AS.

This procedure is very similar to the “Carrier’s Carrier” procedures described in section 9. Like the previous procedure, it requires that there be a label switched path leading from a packet’s ingress PE to its egress PE.

Source: http://ccielab.wordpress.com/2009/09/12/inter-as-mpls-vpn-options/