VRF leaking behavior

[TelesEC]

Hello all,

I have several doubts and I hope you can help me, for the moment, everything has been simulated in GNS3 with Cisco IOSv15.7(3)M3 images, in addition, I added a simplified network design so that I can understand better.

Note 1: The design is not too detailed and what I am most interested in is to understand the behavior of the vrf leaking, not to talk about the design.

My external router PE1 interconnects an external client, CE1, on VRF A and learns via eBGP the subnet X, this subnet X is exported and then imported by VRF B which belongs to a security zone. VRF A and VRF B are in the same router PE1.

On the other hand, the internal router PE2 receives the subnet of the client CE1 in VRF C, through an iBGP session established through the security zone.
PE2 exports the routes from VRF C with a RT 3:3 and here comes my curiosity.
An internal client (e.g. campus, dc,..) CE 2 interconnected to router PE2 on VRF D, imports the RT 3:3 and learns the network X from the external client.
How could it learn a network that was imported from another VRF? The curious thing is that subnet X has only the rt extcomm 3:3.
If another CE3 client interconnects on a distant PE, PE3, on the VRF E and imports the rt 3:3, the latter does not learn the subnet X. Why this difference?

Note 2: If in the router PE3-VRF E, I import the rt 2:2 (VRF A), the CE3 will learn the subnet X but will not pass through the security zone.

I hope I have been clear and thanks for your comments.
Regards,

[TelesEC]

Hi @Harold Ritter ,

Thank you for your first answer, it confirms what I inferred from the simulation experience.
So a subnet already imported but received in iBGP (ipv4) can be exported again.

Regarding the second question, the PE3 router does not receive this route from PE2... doesn't it have something to do with the fact that the route was received in iBGP and therefore cannot be re-advertised in MP-iBGP ?

Look what I see in the RR.

P# show bgp vpnv4 unicast all
BGP table version is 3, local router ID is 4.4.4.4
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 2:2 ----------------> (VRF A)
*>i 172.16.0.0 1.1.1.1 0 100 0 5 i
Route Distinguisher: 4:4 ----------------> (VRF D)
*>i 6.0.0.0 2.2.2.2 0 100 0 6 i  

 PE2

PE2# show bgp vpnv4 unicast all
BGP table version is 5, local router ID is 2.2.2.2
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 3:3 (default for vrf C)
*> 6.0.0.0 192.168.6.2 0 0 6 i
*>i 172.16.0.0 11.11.11.11 0 100 0 5 i
Route Distinguisher: 4:4 (default for vrf D)
*> 6.0.0.0 192.168.6.2 0 0 6 i
*>i 172.16.0.0 11.11.11.11 0 100 0 5 i

 In VRF C, I configured a static route 'test'(14.5.19.86/32) and this route is correctly announced to VRF E, see the RR:

P# show bgp vpnv4 unicast all
BGP table version is 4, local router ID is 4.4.4.4
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
t secondary path,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 2:2
*>i 172.16.0.0 1.1.1.1 0 100 0 5 i
Route Distinguisher: 3:3
*>i 14.5.19.86/32 2.2.2.2 0 100 0 i
Route Distinguisher: 4:4
*>i 6.0.0.0 2.2.2.2 0 100 0 6 i

So, will it have something to do that the route received in iBGP cannot be advertised in MP-iBGP? So when the leaking is done locally, there is no problem.

Thanks!!!

[Harold Ritter · Accepted solution]

Hi @TelesEC ,

The issue is that the route will not be advertised to the RR as it has been received via iBGP (AS65000) and you are trying to advertise it to VPNv4 that is also using AS65000. Try to make the BGP session between VRF B and C a eBGP session instead. This will fix the issue.

Regards,

[TelesEC]

Thank you for your answers and your time @Harold Ritter !
Now I understand better what I observed in the simulation  

Regards

[Harold Ritter]

You are very welcome @TelesEC. have a great day

[MHM Cisco World]

...