Inter VRF Route Leaking with iBGP as PE to CE Routing Protocol

Available Languages

Download Options

  • PDF     (218.3 KB)
    View with Adobe Reader on a variety of devices
  • ePub     (101.7 KB)
    View in various apps on iPhone, iPad, Android, Sony Reader, or Windows Phone
  • Mobi (Kindle)     (103.9 KB)
    View on Kindle device or Kindle app on multiple devices
Updated:December 29, 2015
Document ID:200310

Bias-Free Language

The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.

Introduction

This document discusses inter VRF route leaking when customer edge (CE) and provider edge (PE) are running internal BGP (iBGP) protocol. It discusses current limitation with route-leaking and a workaround for it as well.

Prerequisites

Requirements

Cisco recommends that you have basic knowledge of BGP.

Components Used

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Configure

The support for iBGP as PE to CE protocol was not supported earlier. However , this has been incorporated now and iBGP also can be considered as a potential candidate for PE to CE routing. This feature allows customers to have one single autonomous system across all sites. To achieve this a new attribute ATTR_SET has been introduced that carries the VPN BGP attributes across service provider network in a transparent manner. Also, it requires to make the PE as route-reflector for iBGP session with CE router. Newly introduced command " neighbor x.x.x.x internal vpn-client" helps achieve this. When this single command is configured, it automatically configures "neighbor x.x.x.x route-reflector-client" and "neighbor x.x.x.x next-hop-self".

Network Diagram

Configurations

CE1


interface Loopback10
ip address 10.10.0.1 255.255.255.0

interface Ethernet0/0
 ip address 10.0.12.1 255.255.255.0

router bgp 100
 bgp router-id 10.1.1.1
 bgp log-neighbor-changes
 neighbor 10.0.12.2 remote-as 100
 !        
 address-family ipv4
  network 10.10.0.0 mask 255.255.255.0
  neighbor 10.0.12.2 activate
 exit-address-family

CE2

interface Loopback10
 ip address 10.20.0.1 255.255.255.0

interface Ethernet0/1
 ip address 10.0.45.5 255.255.255.0

router bgp 100
 bgp router-id 10.5.5.5
 bgp log-neighbor-changes
 neighbor 10.0.45.4 remote-as 100
 !
 address-family ipv4
  network 10.20.0.0 mask 255.255.255.0
  neighbor 10.0.45.4 activate
 exit-address-family

PE1

vrf definition A
 rd 10:10
 route-target export 100:100
 route-target import 100:100

!
 address-family ipv4
 exit-address-family
!
vrf definition B
 rd 20:20
 !
 address-family ipv4
  route-target import 50:50
  route-target import 100:100
 exit-address-family

interface Loopback0
 ip address 10.2.2.2 255.255.255.255
 ip ospf 100 area 0
!
interface Ethernet0/0
 vrf forwarding A
 ip address 10.0.12.2 255.255.255.0
!
interface Ethernet0/1
 ip address 10.0.23.2 255.255.255.0
 mpls ip

router bgp 100
 bgp router-id 10.2.2.2
 bgp log-neighbor-changes
 neighbor 10.4.4.4 remote-as 100
 neighbor 10.4.4.4 update-source Loopback0
 !
 address-family vpnv4
  neighbor 10.4.4.4 activate
  neighbor 10.4.4.4 send-community extended
 exit-address-family
 !
 address-family ipv4 vrf A
  neighbor 10.0.12.1 remote-as 100
  neighbor 10.0.12.1 activate

  neighbor 10.0.12.1 internal-vpn-client // needed to exchange routes between PEs
  neighbor 10.0.12.1 next-hop-self
 exit-address-family
 !
 address-family ipv4 vrf B
 exit-address-family

PE2

vrf definition A
 rd 10:10
 route-target export 100:100
 route-target import 100:100

!
 address-family ipv4
 exit-address-family

interface Loopback0
 ip address 10.4.4.4 255.255.255.255
 ip ospf 100 area 0
!
interface Ethernet0/0
 ip address 10.0.34.4 255.255.255.0
 mpls ip
!
interface Ethernet0/1
 vrf forwarding A
 ip address 10.0.45.4 255.255.255.0

router bgp 100
 bgp router-id 10.4.4.4
 bgp log-neighbor-changes
 neighbor 10.2.2.2 remote-as 100
 neighbor 10.2.2.2 update-source Loopback0
 !
 address-family vpnv4
  neighbor 10.2.2.2 activate
  neighbor 10.2.2.2 send-community extended
 exit-address-family
 !
 address-family ipv4 vrf A
  neighbor 10.0.45.5 remote-as 100
  neighbor 10.0.45.5 activate
  neighbor 10.0.45.5 internal-vpn-client //needed to exchange routes between PEs
  neighbor 10.0.45.5 route-reflector-client
  neighbor 10.0.45.5 next-hop-self
 exit-address-family

Verify

Case 1: Accepting and exchanging customer routes over MP-BGP

As discussed earlier, iBGP as PE to CE requires configuration of BGP peering with customer inside VRF with command "neighbor x.x.x.x internal vpn-client". In the absence of this command, local PE accepts the routes from local CE in VRF, however these customer routes are not shared via MP-BGP with other PR routers. Below outputs have been taken with "neighbor x.x.x.x internal vpn-client" pre-configured.

Below output shows routes in vrf A on PE1 and PE2.

PE1#show ip route vrf A

Routing Table: A
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
       a - application route
       + - replicated route, % - next hop override

Gateway of last resort is not set

      10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks
C        10.0.12.0/24 is directly connected, Ethernet0/0
L        10.0.12.2/32 is directly connected, Ethernet0/0
B        10.10.0.0/24 [200/0] via 10.0.12.1, 00:35:23
B        10.20.0.0/24 [200/0] via 10.4.4.4, 00:40:55


PE2#show ip route vrf A

Routing Table: A
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
       a - application route
       + - replicated route, % - next hop override

Gateway of last resort is not set

      10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks
C        10.0.45.0/24 is directly connected, Ethernet0/1
L        10.0.45.4/32 is directly connected, Ethernet0/1
B        10.10.0.0/24 [200/0] via 10.2.2.2, 00:00:08
B        10.20.0.0/24 [200/0] via 10.0.45.5, 00:41:55



CE1#show ip route bgp
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
       a - application route
       + - replicated route, % - next hop override

Gateway of last resort is not set

      10.0.0.0/8 is variably subnetted, 5 subnets, 2 masks
B        10.20.0.0/24 [200/0] via 10.0.12.2, 00:03:56


CE2#show ip route bgp
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
       a - application route
       + - replicated route, % - next hop override

Gateway of last resort is not set

      10.0.0.0/8 is variably subnetted, 5 subnets, 2 masks
B        10.10.0.0/24 [200/0] via 10.0.45.4, 00:04:21

Case 2: Leaking routes from one VRF to another.

Case 1, successfully demonstrated exchange of routes between CE1 and CE2. Now consider another vrf B that needs to install routes in vrf A into itself. Regular method is to use export-map value in VRF A and import same value in VRF B as shown below.

! 
vrf definition A
 rd 10:10
 route-target export 100:100
 route-target import 100:100
 !
 address-family ipv4
 exit-address-family
!
vrf definition B
 rd 20:20

!
 address-family ipv4
  route-target import 100:100
 exit-address-family
!

When above configuration is done, VRF B fails to install any of the BGP route that was received from local CE. However, routes received from other PEs via MP-BGP are successfully installed as show below in output. 10.20.0.0/24 belongs to CE and that is successfully received in VRF A and is also exported to VRF B. But 10.10.0.0/24 received locally from CE1 fails to enter VRF B.

PE1#show ip route vrf A bgp
Routing Table: A
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
       a - application route
       + - replicated route, % - next hop override

Gateway of last resort is not set

      10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks
B        10.10.0.0/24 [200/0] via 10.0.12.1, 00:12:35
B        10.20.0.0/24 [200/0] via 10.4.4.4, 00:54:22


PE1#show ip route vrf B

Routing Table: B
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
       a - application route
       + - replicated route, % - next hop override

Gateway of last resort is not set

      10.0.0.0/24 is subnetted, 1 subnets
B        10.20.0.0 [200/0] via 10.4.4.4, 00:46:38

This problem of VRF route leaking of local CE route from VRF A to B is seen only till the point "neighbor x.x.x.x internal vpn-client" is configured. As soon as this command is removed from PE1, VRF B is able to successfully see local CE1 route 10.10.0.0/24 as well as shown below.

!
router bgp 100
 address-family ipv4 vrf A
 no  neighbor 10.0.12.1 internal-vpn-client
!

PE1#show ip route vrf B bgp

Routing Table: B
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
       a - application route
       + - replicated route, % - next hop override

Gateway of last resort is not set

      10.0.0.0/24 is subnetted, 2 subnets
B        10.10.0.0 [200/0] via 10.0.12.1 (A), 00:00:11
B        10.20.0.0 [200/0] via 10.4.4.4, 00:58:33

And remote site B, stops receiving site A's routes (as neighbor x.x.x.x internal vpn-client has been removed).

PE2#show ip route vrf A bgp

Routing Table: A
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area 
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
       a - application route
       + - replicated route, % - next hop override

Gateway of last resort is not set

      10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
B        10.20.0.0/24 [200/0] via 10.0.45.5, 01:04:21           // 10.10.0.0/24 is missing.

This is a limitation and an enhancement bug CSCuw43489 has already been filed to fix this problem.

Workaround

There is a workaround that is available to check above discussed problem. This workaround does allow to import routes from VRF A to VRF B in the presence of command "neighbor x.x.x.x internal vpn-client". This workaround requires to set a dummy community (50:50 done in example below) when importing routes from customer. Import this dummy extended community into vrf B.

!
route-map TEST, permit, sequence 10
  Match clauses:
  Set clauses:
    extended community RT:50:50
  Policy routing matches: 0 packets, 0 bytes
!
vrf definition B
 rd 20:20
 address-family ipv4
  route-target import 100:100
  route-target import 50:50                         // match dummy community
!
router bgp 100
 address-family ipv4 vrf A
  neighbor 10.0.12.1 route-map TEST in             // Set dummy community
!

PE1#show bgp vpnv4 uni vrf B 10.10.0.0
BGP routing table entry for 20:20:10.10.0.0/24, version 4
Paths: (1 available, best #1, table B)
  Not advertised to any peer
  Refresh Epoch 1
  Local, (Received from ibgp-pece RR-client), imported path from 10:10:10.10.0.0/24 (A)
    10.0.12.1 (via vrf A) (via A) from 10.0.12.1 (10.1.1.1)
      Origin IGP, metric 0, localpref 100, valid, internal, best
      Extended Community: RT:50:50
      rx pathid: 0, tx pathid: 0x0


PE1#show ip route vrf B

Routing Table: B
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
       a - application route
       + - replicated route, % - next hop override

Gateway of last resort is not set

      10.0.0.0/24 is subnetted, 2 subnets
B        10.10.0.0 [200/0] via 10.0.12.1 (A), 00:00:25
B        10.20.0.0 [200/0] via 10.4.4.4, 00:00:25

As shown above, this workaround makes route 10.10.0.0/24 present in VRF A install in VRF B.

TAC Authored

Contributed by Cisco Engineers

  • Amandeep Singh
    Cisco TAC Engineer

Was this Document Helpful?

FeedbackFeedback

Contact Cisco