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]

Thanks for your reply Harold.
VRF A exports subnet X with a rt 2:2 ; VRF B imports the rt 2:2 and therefore imports subnet X.
VRF B establishes an iBGP session with VRF C (logically they are the same VRFs), then VRF C also contains subnet X.
VRF C exports its routes with a rt 3:3. So far so good.
What surprised me is the following:
When VRF D imports the rt 3:3, VRF D also imports subnet X, why? Normally it should not import this subnet because this subnet belongs to VRF A.

I hope I have made myself clear.
What I am looking for is to understand why the VRF D could import the subnet X with a rt that does not correspond to it.

Regards,

[Harold Ritter]

Hi @TelesEC ,

> When VRF D imports the rt 3:3, VRF D also imports subnet X, why? Normally it should not import this subnet because this > subnet belongs to VRF A.

I am not sure I am following you. If VRF C exports RT 3:3 and VRF D imports RT 3:3 then it is completely normal for VRF D to import subnet X.

Can you please explain why you think it should not import this subnet?

Regards,

[TelesEC]

Hi @Harold Ritter 

VRF A acceptes subnet X from CE1 and VRF A export the subnet X with rt 2:2.

VRF B import rt 2:2 therefore imports the subnet X.

VRF A and VRF B are configured in PE1 (attached picture).

VRF B announce the prefixes via iBGP (ipv4) to VRF C.

VRF C export the subnets with a rt 3:3.

VRF D import the rt 3:3. -> through this configuration VRF D also import subnet X.

VRF C and VRF D are configured in PE2. 

CE2 recevies the subnet X from PE2 (VRF D) with a rt ext comm 3:3

Why was VRF D able to import the subnet of VRF A via VRF C? Normally you can't import a prefix that was already imported from another VRF, right?

If VRF D could import subnet X using the rt 3:3, why can't VRF E import it? VRF E is configured in PE3

I hope I have been clear & Thanks!!!

[MHM Cisco World]

Why was VRF D able to import the subnet of VRF A via VRF C? Normally you can't import a prefix that was already imported from another VRF, right?

NOT from VRF-C it from MP-BGP RR.

If VRF D could import subnet X using the rt 3:3, why can't VRF E import it? VRF E is configured in PE3

check RD in VRF-E is it same VRF-B
check if MP-BGP is OK between PE3 and RR

[TelesEC]

Hello @MHM Cisco World !

The RDs for this simulation are different for each VRF.
I now better understand the outputs of the simulation:

• First it was clear to me that VRF D could import subnet X from VRF C because VRF C received it via iBGP from VRF B , I.e. VRF C did not directly import the subnet X from VRF A.
• VRF E cannot import the route from VRF C because VRF C receives it in iBGP and cannot announce it back in MP-iBGP to the RR.

Thanks for your time!!!

[MHM Cisco World]

Point two confuse me, VRF-E can not import from VRC-C but it can learn it from VRF-B ??? both export same RT 3:3??
can you try do following 
disable iBGP between VRF-B and VRF-C and check again VRF-E

[Harold Ritter]

VHi @MHM Cisco World  ,

VRF B will not export the route to vpnv4 as this route has been imported fron VRF A

Regards,

[MHM Cisco World]

Man you Are always our Leader,
but can I ask something 
why VRF-C show RT 3:3 if it learn from iBGP not MP-BGP?

[MHM Cisco World]

you share the below

show ip bgp vpnv4 all 
PE2
#show bgp vrf C 172.16.0.0
Origin IGP, metric 0, localpref 100, valid, internal, best

Extended Community: RT:3:3 <<- RT appear only between VPNv4 not between IPv4.

[TelesEC]

Hi @MHM Cisco World ,

On router PE1 I see that the subnet X maintains rt 2:2 of VRF A, however, on PE2, the subnet X maintains rt 3:3 of VRF C.
Note 1: To perform a test modify the rt exp of VRF B to 33:33. All BGP sessions has the command

neighbor send-community both

configured.

Here the subnet X (172.16.0.0/16) received from CE1 in PE1-VRF :

PE1#show bgp vrf A 172.16.0.0
BGP routing table entry for 2:2:172.16.0.0/16, version 2
Paths: (1 available, best #1, table A)
Advertised to update-groups:
3
Refresh Epoch 1
5
192.168.5.2 (via vrf A) from 192.168.5.2 (172.16.1.1)
Origin IGP, metric 0, localpref 100, valid, external, best
Extended Community: RT:2:2
mpls labels in/out 22/nolabel
rx pathid: 0, tx pathid: 0x0

PE1#show bgp vrf B 172.16.0.0
BGP routing table entry for 7:7:172.16.0.0/16, version 5
Paths: (1 available, best #1, table B)
Advertised to update-groups:
1
Refresh Epoch 1
5, imported path from 2:2:172.16.0.0/16 (A)
192.168.5.2 (via vrf A) (via A) from 192.168.5.2 (172.16.1.1)
Origin IGP, metric 0, localpref 100, valid, external, best
Extended Community: RT:2:2
rx pathid: 0, tx pathid: 0x0

PE2

PE2#show bgp vrf C 172.16.0.0
BGP routing table entry for 3:3:172.16.0.0/16, version 6
Paths: (1 available, best #1, table C)
Not advertised to any peer
Refresh Epoch 2
5
11.11.11.11 (via vrf C) from 11.11.11.11 (1.1.1.1)
Origin IGP, metric 0, localpref 100, valid, internal, best
Extended Community: RT:3:3
mpls labels in/out 24/nolabel
rx pathid: 0, tx pathid: 0x0

PE2#show bgp vrf D 172.16.0.0
BGP routing table entry for 4:4:172.16.0.0/16, version 7
Paths: (1 available, best #1, table D)
Advertised to update-groups:
2
Refresh Epoch 1
5, imported path from 3:3:172.16.0.0/16 (C)
11.11.11.11 (via vrf C) (via C) from 11.11.11.11 (1.1.1.1)
Origin IGP, metric 0, localpref 100, valid, internal, best
Extended Community: RT:3:3
rx pathid: 0, tx pathid: 0x0

PE2#show bgp all
For address family: IPv4 Unicast

For address family: VPNv4 Unicast
BGP table version is 7, local router ID is 2.2.2.2
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: 3:3 (default for vrf C)
*> 6.0.0.0 192.168.6.2 0 0 6 i
*> 14.5.19.86/32 0.0.0.0 0 32768 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
*> 14.5.19.86/32 0.0.0.0 0 32768 i
*>i 172.16.0.0 11.11.11.11 0 100 0 5 i

For address family: IPv4 Multicast
For address family: L2VPN E-VPN
For address family: VPNv4 Multicast
For address family: MVPNv4 Unicast

An important point, VRF B and VRF C establish an iBGP session but they do not import/export each other and in the following 'output' we see that the route learned in iBGP keeps the rt 33:33 that belongs to VRF B, but the route is generated by VRF C.

PE1#show bgp vrf B 14.5.19.86
BGP routing table entry for 7:7:14.5.19.86/32, version 4
Paths: (1 available, best #1, table B)
Not advertised to any peer
Refresh Epoch 2
Local
22.22.22.22 (via vrf B) from 22.22.22.22 (2.2.2.2)
Origin IGP, metric 0, localpref 100, valid, internal, best
Extended Community: RT:33:33
mpls labels in/out 24/nolabel
rx pathid: 0, tx pathid: 0x0

PE-1

vrf definition B
rd 7:7
route-target export 33:33
route-target import 2:2 -> VRF A
!
address-family ipv4
exit-address-family

PE-2

vrf definition C
rd 3:3
route-target export 3:3
route-target import 4:4 -> VRF D

ip route vrf C 14.5.19.86 255.255.255.255 Null0

PE2#show bgp vrf C 14.5.19.86
BGP routing table entry for 3:3:14.5.19.86/32, version 2
Paths: (1 available, best #1, table C)
Advertised to update-groups:
1 3
Refresh Epoch 1
Local
0.0.0.0 (via default) from 0.0.0.0 (2.2.2.2)
Origin IGP, metric 0, localpref 100, weight 32768, valid, sourced, local, best
Extended Community: RT:3:3
mpls labels in/out 22/nolabel
rx pathid: 0, tx pathid: 0x0

Regards

[MHM Cisco World]

NOW it 100% clear for point "1"
thanks @Harold Ritter @TelesEC 

for point "2"
is 100% clear after read @Harold Ritter  comment.
thanks.

[Harold Ritter]

Hi @MHM Cisco World ,

Next-hop-self is the default behavior for prefixes advertised over vpnv4. 

Regards,

[MHM Cisco World]

...

[TelesEC]

Thanks for the advice.
If I understand the configuration correctly, the PEs will access subnet X without going through the security infrastructure.
The security infrastructure is between VRF B and VRF C.
VRF A : VRF from an external client.
VRF B : VRF of a security infrastructure dedicated to a category of external customers.
VRF C : security infrastructure accessible from the internal network.
VRF D : an internal block, e.g. DC (internal network).
VRF E: another internal block, e.g. LAN (internal network).
The design is still under construction, but while simulating I found a behavior that I think is strange.
Given the configuration made (and shared) why the VRF D can import a prefix of the VRF A via the VRF C ? I don't understand.
If VRF D can import that prefix, why can't VRF E?

Thank you for taking the time to answer my question!

[Harold Ritter]

Hi @TelesEC ,

> Why was VRF D able to import the subnet of VRF A via VRF C? Normally you can't import a prefix that was already imported > from another VRF, right?

VRF C does not import the route, but rather receives it via iBGP. This makes a big difference. This is why VRF C can export the route and VRF D can import it.

> If VRF D could import subnet X using the rt 3:3, why can't VRF E import it? VRF E is configured in PE3

It looks like VRF C should be able to export the route to VPNv4, as it was not imported from another VRF as I mentioned before. Please check if the route makes it to the RR and to PE3. This might tell you why it does make it to CE3.

Regards,