2014年12月6日 星期六

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.

12.jpg

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.

13.jpg

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:

14.jpg

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

2014年11月30日 星期日

BGP Backdoor

BGP Backdoor

In the diagram below, a link has been added between AS10 and AS30.  It’s a new EIGRP connection that should be used as a primary path when speaking between the 12.12.12.0/30 network and the 45.45.45.0/30 network.  In the event the new EIGRP link fails, the original BGP path via R3 should be used for backup.  When analysing the best path between AS10 & AS30, you should be able to spot that the problem is going to be the admin distance:  eBGP’s AD 20 vs EIGRP’s AD 90 means that eBGP via R3 is more preferred than the EIGRP link.
The way we’re going to fix this is by using the BGP backdoor feature. Firstly, what I’m going to do is advertise the 45.45.45.0/30 network into BGP on R2, and advertise the 12.12.12.0/30 network into BGP on R4.  Sounds weird, but what happens is that it makes the routers advertise these networks as if they are local iBGP routes = AD of 200.  This makes EIGRP link more preferred between AS10 & AS30 because it’s admin distance is now lower. Before changing anything, let’s take a glance at the routing table on R2.
R2#sh ip route | b Gate
Gateway of last resort is not set

     34.0.0.0/30 is subnetted, 1 subnets
B       34.34.34.0 [20/0] via 23.23.23.2, 00:01:12
     23.0.0.0/30 is subnetted, 1 subnets
C       23.23.23.0 is directly connected, FastEthernet0/1
     24.0.0.0/30 is subnetted, 1 subnets
C       24.24.24.0 is directly connected, FastEthernet1/0
     12.0.0.0/30 is subnetted, 1 subnets
C       12.12.12.0 is directly connected, FastEthernet0/0
     45.0.0.0/30 is subnetted, 1 subnets
B       45.45.45.0 [20/0] via 23.23.23.2, 00:00:42
As you can see, the best path to the 45.45.45.0/30 network is via eBGP using an AD of 20, which is taking presidence over our EIGRP route to this network (hence why the EIGRP route isn’t shown in the output above).  Let’s make the fix.
R2(config)#router bgp 10
R2(config-router)#network 45.45.45.0 mask 255.255.255.252

R4(config)#router bgp 30
R4(config-router)#network 12.12.12.0 mask 255.255.255.252

R2#sh ip route | b Gate
Gateway of last resort is not set

     34.0.0.0/30 is subnetted, 1 subnets
B       34.34.34.0 [20/0] via 23.23.23.2, 00:04:11
     23.0.0.0/30 is subnetted, 1 subnets
C       23.23.23.0 is directly connected, FastEthernet0/1
     24.0.0.0/30 is subnetted, 1 subnets
C       24.24.24.0 is directly connected, FastEthernet1/0
     12.0.0.0/30 is subnetted, 1 subnets
C       12.12.12.0 is directly connected, FastEthernet0/0
     45.0.0.0/30 is subnetted, 1 subnets
D       45.45.45.0 [90/30720] via 24.24.24.2, 00:03:42, FastEthernet1/0
Good.  So our local router R2 thinks that the 45.45.45.0/30 network is now an iBGP route rather than an eBGP route, meaning the AD for this network is now 200 (via iBGP).  Obviously the best path is via EIGRP, using an AD of 90.  This makes our EIGRP route more preferred.  All I have to do now to complete the configuration, is fix the problem we just made on R3.  Let’s check out what happened when we made the change.  This is how R3’s BGP table looked before adding the network statements above
R3#sh ip bgp
BGP table version is 5, local router ID is 34.34.34.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
*> 12.12.12.0/30    23.23.23.1               0             0 10 ?
*  23.23.23.0/30    23.23.23.1               0             0 10 i
*>                  0.0.0.0                  0         32768 i
*> 34.34.34.0/30    0.0.0.0                  0         32768 i
*                   34.34.34.2               0             0 30 i
*> 45.45.45.0/30    34.34.34.2                0            0 30 ?
This is how the BGP table looks after we made the change
R3#sh ip bgp
BGP table version is 8, local router ID is 34.34.34.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
*> 12.12.12.0/30    34.34.34.2           30720             0 30 i
*                   23.23.23.1               0             0 10 ?
*  23.23.23.0/30    23.23.23.1               0             0 10 i
*>                  0.0.0.0                  0         32768 i
*  34.34.34.0/30    34.34.34.2               0             0 30 i
*>                  0.0.0.0                  0         32768 i
*> 45.45.45.0/30    23.23.23.1           30720             0 10 i
*                   34.34.34.2               0             0 30 ?

R3#traceroute 45.45.45.2

  1 23.23.23.1 32 msec 40 msec 20 msec
  2 24.24.24.2 40 msec 20 msec 20 msec
  3 45.45.45.2 [AS 10] 48 msec *  60 msec
So we are learning that the two highlighted networks now appear to originate in AS10 as well as AS30, which is incorrect. What’s happened is that R2 is now advertising the 45.45.45.0/30 network to eBGP peers as if he was the originator in AS10. Just as R4 is advertising 12.12.12.0/30 as if he is the originator in AS30.  Which is correct according to the network statement we just configured.  But obviously this is wrong as 45.45.45.0/30 resides in AS30, and 12.12.12.0/30 resides in AS10.  The ORIGIN code is then causing R3 to prefer the path via R2 for the 45.45.45.0/30 prefix in AS10.  It is also causing R3 to prefer the path for the 12.12.12.0/30 prefix via R4, which isn’t what we wanted to do.  We can confirm this by checking out the attributes of the route.
R3#sh ip bgp  45.45.45.0
BGP routing table entry for 45.45.45.0/30, version 8
Paths: (2 available, best #1, table Default-IP-Routing-Table)
  Advertised to update-groups:
     1
  10
    23.23.23.1 from 23.23.23.1 (24.24.24.1)
      Origin IGP, metric 30720, localpref 100, valid, external, best
  30
    34.34.34.2 from 34.34.34.2 (45.45.45.1)
      Origin incomplete, metric 0, localpref 100, valid, external
When I originally configured this behind the scenes, I advertised the 45.45.45.0/30 network on R4 into EIGRP and then used the #redistribute eigrp 1 command under the BGP process.  However, when I just advertised this same network on R2 a moment ago, I used the BGP #network 45.45.45.0 mask 255.255.255.0 command.  This creates a more preferred ORIGIN code via R2 (ORIGIN IGP wins vs ORIGIN incomplete).  What we can do to fix this is use the #network x.x.x.x backdoor command so that we do not advertise any networks that don’t actually reside in our AS to any of our eBGP peers. Lets do that now:
R2(config-router)#network 45.45.45.0 mask 255.255.255.252 backdoor

R4(config-router)#network 12.12.12.0 mask 255.255.255.252 backdoor
Let’s just check that R3 doesn’t receive the 45.45.45.0/30 network via R2, & also doesn’t receive the 12.12.12.0/30 network via R4, then we can confirm this fixed the problem:
R3#sh ip bgp
BGP table version is 5, local router ID is 34.34.34.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
*> 12.12.12.0/30    23.23.23.1               0             0 10 ?
*  23.23.23.0/30    23.23.23.1               0             0 10 i
*>                  0.0.0.0                  0         32768 i
*> 34.34.34.0/30    0.0.0.0                  0         32768 i
*                   34.34.34.2               0             0 30 i
*> 45.45.45.0/30    34.34.34.2               0             0 30 ?
Good problem solved.  R2 is using the EIGRP path to R4 when speaking between the 12.12.12.0/30 network & the 45.45.45.0/30 network.  If the link fails, he will use the BGP path via R3 instead.  R3 is only learning the prefixes by the correct AS’s.


source: http://ccieblog.co.uk/bgp/bgp-backdoor