cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2302
Views
20
Helpful
12
Replies

MP-BGP / MPLS Redistribution of Leaked Routes

johnstack8
Level 1
Level 1

I am working in a MPLS network with a fairly standard model. I have VRFs created for different clients and need to leak bidirectionally into a common service area. I have two sites and two routers at each site in my lab environment, one at the core and a second hosting edge services including the service area that I need to share with the client networks. The core router at each site is acting as a route reflector and each edge service router is connected to both cores for redundancy. Client networks are directly connected to the core routers and are visible across all devices. All BGP neighbourships are established between loopback addresses in the global table with address-family vpnv4 active. OSPF is used to distribute the loopback networks between the different network participants. MPLS is enabled on all interface; traffic can be sent between different routers perfectly.

 

With this base in place I am now attempting to leak routes from the service area into the client network. This works perfectly on the service router that has the connected network and I can see the route in my client network. In this output 10.1.1.1 and 10.2.1.1 are directly in the client network with one subnet on each core router. The 100.64.0.0/30 network is leaked in with a route-target import from the exported network in the services VRF:

 

s8dc1-rou1#sh ip route vrf client1
[...]
10.0.0.0/32 is subnetted, 2 subnets
B 10.1.1.1 [200/0] via 1.0.1.252, 01:33:04
B 10.2.1.1 [200/0] via 1.0.2.252, 01:33:04
100.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
B 100.64.0.0/30 is directly connected, 01:33:01, Loopback520
L 100.64.0.1/32 is directly connected, Loopback520

I was surprised to see that these routes are not visible on the other devices in the network. If I put the same route-target import/export configuration in place on another router then the routes become visible their as well. I do not want to replicate the leaking configuration to all devices on the network however, I would like to have these routes announced inside the client VRF. There are two logical places to do this in my view, either on the edge router that is announcing the service subnet or on the two core routers.

 

How can I centralize this redistribution? I thought I might be able to leverage the redistribute vrf or redistribute commands inside the "address-family ipv4 vrf client1" BGP stanza but I'm told that I can't redistribute bgp into bgp; I created an OSPF process in the services VRF but I'm unable to redistribute ospf into bgp as well.

 

Here's my redistribution configuration, it was necessary to include the subnets learned from the core in the import map or they don't appear in the VRF on the service router.

 

ip prefix-list client1-import seq 50 permit 10.1.1.1/32
ip prefix-list client1-import seq 60 permit 10.2.1.1/32
ip prefix-list client1-import seq 100 permit 100.64.0.0/30

route-map client1-import permit 10
match ip address prefix-list client1-import

ip vrf client1
rd 65051:50
import map client1-import
route-target export 65051:50
route-target import 65051:50
route-target import 65051:52
ip vrf services
rd 65051:52
route-target export 65051:52
route-target import 65051:52
1 Accepted Solution

Accepted Solutions

Francesco Molino
VIP Alumni
VIP Alumni

Hi @johnstack8 

 

Hope I understood your question correctly.

Let me summarize it:

- You want to leak prefixes from vrf services from your dc-service routers into client vrfs and you want to be able to get them in all your routers that are using these client vrfs.

- You want to do it at 1 place (dc-service routers) and not doing this in all your routers.

 

Am I correct?

 

If yes, below a workaround you can do to achieve this requirement.

 

On your dc1-service router where you did the vrf leaking, you can create a route-map to match these services prefixes and rewrite rt to make sure all your neighbours are getting these routes. 

A quick example based on your snippet configs shared:

In my config example, Core1 loopback has IP 192.168.255.3 and Core2 loopback has IP 192.168.255.4.

For the test purpose, I only applied the new route-map to Core1 neighbour and not to Core2 so we can see the difference.

 

!
ip prefix-list client1-import seq 100 permit 100.64.0.0/30
!
ip extcommunity-list 1 permit rt 65051:52
!
route-map RMAP_EXPORT_CLT1 permit 10
 match ip address prefix-list client1-import
 set extcomm-list 1 delete
 set extcommunity rt 65051:50
route-map RMAP_EXPORT_CLT1 permit 20
!
router bgp 65000
 address-family vpnv4
  neighbor 192.168.255.3 activate
  neighbor 192.168.255.3 send-community both
  neighbor 192.168.255.3 route-map RMAP_EXPORT_CLT1 out
  neighbor 192.168.255.4 activate
  neighbor 192.168.255.4 send-community both
!

Core1 router output:

 

CORE1#sh ip route vrf client1

Routing Table: client1
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
C        10.1.1.0/24 is directly connected, Loopback100
L        10.1.1.1/32 is directly connected, Loopback100
B        10.2.1.0/24 [200/0] via 192.168.255.4, 00:35:36
      100.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
B        100.64.0.0/30 [200/0] via 192.168.255.1, 00:13:11
CORE1#sh ip bgp vpnv4 vrf
CORE1#sh ip bgp vpnv4 vrf client1 100.64.0.0/30
BGP routing table entry for 65051:50:100.64.0.0/30, version 19
Paths: (1 available, best #1, table client1)
  Not advertised to any peer
  Refresh Epoch 1
  Local, (Received from a RR-client), imported safety path from 65051:52:100.64.0.0/30 (services)
    192.168.255.1 (metric 11) (via default) from 192.168.255.1 (192.168.255.1)
      Origin IGP, metric 0, localpref 100, valid, internal, best
      Extended Community: RT:65051:50
      mpls labels in/out nolabel/21
      rx pathid: 0, tx pathid: 0x0
CORE1#

Core2 router output:

 

CORE2#sh ip route vrf client1

Routing Table: client1
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.1.1.0/24 [200/0] via 192.168.255.3, 00:40:38
C        10.2.1.0/24 is directly connected, Loopback100
L        10.2.1.1/32 is directly connected, Loopback100
CORE2#

 

If I misunderstood your request, can you please detail a little more your design/configs and tell us the end goal I didn't get.

 


Thanks
Francesco
PS: Please don't forget to rate and select as validated answer if this answered your question

View solution in original post

12 Replies 12

Giuseppe Larosa
Hall of Fame
Hall of Fame

Hello @johnstack8 ,

>> I was surprised to see that these routes are not visible on the other devices in the network. If I put the same route-target import/export configuration in place on another router then the routes become visible their as well. I do not want to replicate the leaking configuration to all devices on the network however,

 

What you see is normal a VRF is not authorized to send back to the backbone (= export) the result of an import.

This is the way it works with MPLS L3 VPN all remote site PE nodes should add the appropriate import/export route targets for the service area.

 

This is part of the distributed model of MPLS L3 VPN signaling.

Also OSPF uses the DN down bit to understand routes coming from backbone and avoid to re-inject them in the backbone.

 

Hope to help

Giuseppe

 

 

Thanks for that guidance Giuseppe, I appreciate it.

 

I know that with OSPF you can use capabiltiy vrf-lite to override this type of behaviour. Is there a way I could redistribute the desired routes into BGP? Right now all four routers are effectively combined P/PE routers and I would much prefer to avoid needing to create per client VRF connections from the service routers to the core.

...

Thank you very much for taking the time to create a diagram, this is a more accurate reflection of the topology: There are direct or indirect physical connections between the devices as shown by the blue lines between them; these connections support BGP adjacency between the two core routers and from each service router to both cores. Each core reflects routes to each service router but they do not reflect to each other.

 

BGP Lab Design.png

Thank for clarification,
Screen Shot 2020-11-28 at 1.30.23 AM.png

Screen Shot 2020-11-28 at 1.30.26 AM.png
there is something called route-replaction, this solve the VRF in Core and for the service router we will config link between Core and Service with VRF "Service" as example show above and we will config OSPF and make redistribute between service and red and green VRF's as show above.
VRF red and green represent the client VRF that CORE have.

hope this the answer for your question.

This looks very promising @MHM Cisco World , however it seems to require creating an OSPF process per VRF with with bi-directional redistribution in order to achieve my goals.

I can easily get the routes to appear using route-replicate however when I try to redistribute directly inside the BGP process I see:

s8dc1-rou1(config-router-af)#router bgp 65001
s8dc1-rou1(config-router)#address-family ipv4 vrf client1
s8dc1-rou1(config-router-af)#redistribute vrf services connected
% Inter-VRF redistribution is not supported by 'bgp'

I could create an OSPF process for the services VRF and the client VRF (possibly only the client); with the route in OSPF inside the client1 vrf I could then redistribute it from the OSPF process into BGP but it's quite convoluted; is there no way to do it more directly?

OK, 
I don't try but I have idea here
Service R-Core R
instead of connect two R via BGP address family ipv4
we will connect it via eBGP i.e. global

and then under each VRF in CoreR we config 
ip vrf client 1
rd 1:100
import ipv4 unicast map <- from global "this is for Service prefix"
export ipv4 unicast map <-to global  "this is for client prefix"

here we sure that the Service R get prefix via global BGP.

check this solution.

I think this approach could work as well but it places the routes in the global table; I don't want to have them present there in this network; at least, via leaking. Thanks very much for your help MHM Cisco World on this challenging routing question.

...

I'm not entirely sure that I understand you answer, but the client networks and the service networks are on the same devices. It sounds like you are talking about a more traditional model with CE routers inside the client VRFS. I don't have this in this design nor do I want to add it.

Francesco Molino
VIP Alumni
VIP Alumni

Hi @johnstack8 

 

Hope I understood your question correctly.

Let me summarize it:

- You want to leak prefixes from vrf services from your dc-service routers into client vrfs and you want to be able to get them in all your routers that are using these client vrfs.

- You want to do it at 1 place (dc-service routers) and not doing this in all your routers.

 

Am I correct?

 

If yes, below a workaround you can do to achieve this requirement.

 

On your dc1-service router where you did the vrf leaking, you can create a route-map to match these services prefixes and rewrite rt to make sure all your neighbours are getting these routes. 

A quick example based on your snippet configs shared:

In my config example, Core1 loopback has IP 192.168.255.3 and Core2 loopback has IP 192.168.255.4.

For the test purpose, I only applied the new route-map to Core1 neighbour and not to Core2 so we can see the difference.

 

!
ip prefix-list client1-import seq 100 permit 100.64.0.0/30
!
ip extcommunity-list 1 permit rt 65051:52
!
route-map RMAP_EXPORT_CLT1 permit 10
 match ip address prefix-list client1-import
 set extcomm-list 1 delete
 set extcommunity rt 65051:50
route-map RMAP_EXPORT_CLT1 permit 20
!
router bgp 65000
 address-family vpnv4
  neighbor 192.168.255.3 activate
  neighbor 192.168.255.3 send-community both
  neighbor 192.168.255.3 route-map RMAP_EXPORT_CLT1 out
  neighbor 192.168.255.4 activate
  neighbor 192.168.255.4 send-community both
!

Core1 router output:

 

CORE1#sh ip route vrf client1

Routing Table: client1
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
C        10.1.1.0/24 is directly connected, Loopback100
L        10.1.1.1/32 is directly connected, Loopback100
B        10.2.1.0/24 [200/0] via 192.168.255.4, 00:35:36
      100.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
B        100.64.0.0/30 [200/0] via 192.168.255.1, 00:13:11
CORE1#sh ip bgp vpnv4 vrf
CORE1#sh ip bgp vpnv4 vrf client1 100.64.0.0/30
BGP routing table entry for 65051:50:100.64.0.0/30, version 19
Paths: (1 available, best #1, table client1)
  Not advertised to any peer
  Refresh Epoch 1
  Local, (Received from a RR-client), imported safety path from 65051:52:100.64.0.0/30 (services)
    192.168.255.1 (metric 11) (via default) from 192.168.255.1 (192.168.255.1)
      Origin IGP, metric 0, localpref 100, valid, internal, best
      Extended Community: RT:65051:50
      mpls labels in/out nolabel/21
      rx pathid: 0, tx pathid: 0x0
CORE1#

Core2 router output:

 

CORE2#sh ip route vrf client1

Routing Table: client1
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.1.1.0/24 [200/0] via 192.168.255.3, 00:40:38
C        10.2.1.0/24 is directly connected, Loopback100
L        10.2.1.1/32 is directly connected, Loopback100
CORE2#

 

If I misunderstood your request, can you please detail a little more your design/configs and tell us the end goal I didn't get.

 


Thanks
Francesco
PS: Please don't forget to rate and select as validated answer if this answered your question

Thanks for this interesting solution Francesco, I've tested it and it does work properly.

 

In order to make it work in a multi-tenant environment I'll need to create one rule per tenant on each of the services routers to strip the local tags and apply new ones. I'm not certain if I'll do this, which does centralize the configuration, or instead import from services to the client on the core and from the client to services on the service routers. Using this traditional approach will have the configuration more distributed with imports present in four locations but it will also be quite a bit simpler for people to understand.

 

Thanks again for your help!

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Innovations in Cisco Full Stack Observability - A new webinar from Cisco