06-04-2022 10:57 AM
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,
Solved! Go to Solution.
06-06-2022 09:38 AM - edited 06-06-2022 10:17 AM
Hi @Andreseo90 ,
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,
06-04-2022 11:49 AM - edited 06-06-2022 10:10 AM
..
06-04-2022 12:15 PM
Thank you for your response.
The client route (subnet X) is in VRF A and I export it with a rt2:2.
In VRF B I import that rt and export the routes with a rt 3:3.
In VRF D and VRF E, I import the rt 3:3, the problem is that only in VRF D I get the subnet X of the client CE1 but not in VRF E.
Why could I import the subnet X with the rt 3:3 if its original rt is 2:2? Why was vrf D able to import subnet X from vrf B which had already been imported from VRF A? Normally this is not possible (loop prevention).
Regards
06-04-2022 12:30 PM - edited 06-06-2022 10:10 AM
...
06-04-2022 03:44 PM - edited 06-06-2022 10:10 AM
...
06-04-2022 11:42 PM
Hello,
For AF VPNv4, all PEs are clients of P (RR).
For IPv4 AF, only PE1 is a client of PE2 (RR), it does not make sense here but the architecture is a bit bigger.
Regards
06-04-2022 01:54 PM - edited 06-04-2022 01:54 PM
Hi
i-BGP protocol is not capable of taking VPNv4 prefixes of the customer from one PE to another PE. It worked up down because they are actually iBGP or eBGP neighbor. In the case of P3, you are using MP-iBGP to stablish neighborhood. If you replace all to iBGP only, the SubnetX would make it to get to CE3
06-04-2022 11:40 PM
Hello,
Thanks for your reply, I inferred exactly from the results.
What I found strange is that CE2 receives subnet X with an ext comm rt of 3:3, which indicates that VRF C changed the rt of the route that he learned from VRF A, so if VRF C changed the rt, why VRF E could not import it?
I will try to add some outputs
Regards
06-05-2022 12:23 AM - last edited on 06-06-2022 09:15 PM by Translator
Subnet X : 172.16.0.0/16
PE1#show bgp vrf A 172.16.0.0
Paths: (1 available, best #1, table A)
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
PE1#show bgp vrf B 172.16.0.0
Paths: (1 available, best #1, table B)
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
PE2#show bgp vrf C 172.16.0.0
Origin IGP, metric 0, localpref 100, valid, internal, best
Extended Community: RT:3:3
PE2#show bgp vrf D 172.16.0.0
5, imported path from 3:3:172.16.0.0/16 (C)
Origin IGP, metric 0, localpref 100, valid, internal, best
Extended Community: RT:3:3
06-05-2022 05:15 AM - last edited on 06-06-2022 09:16 PM by Translator
"By default, neighbors that are defined using the
neighbor remote-as
command in router configuration mode exchange only unicast address prefixes. To exchange other address prefix types, such as multicast and VPNv4, neighbors must also be activated using the
neighbor activate
command in address family configuration mode, as shown. "
Did you use neighbor activate between Pe2 and Pe3 ?
06-05-2022 05:35 AM
06-05-2022 07:35 AM
can I see the config of IGP inside the SP core ?
06-05-2022 04:43 PM - edited 06-06-2022 10:11 AM
...
06-05-2022 11:12 PM
Thank you for your response.
Here is a diagram and the configurations of the PE and P routers.
The configuration has been adapted to simplify it as much as possible in order to have an answer to my question.
Regarding your comment:
vrf A needs to import the routes of vrf B (3:3) in order to have traffic in both directions.
vrf B and vrf C have the same rt 3:3 because in theory they are the 'same' vrf (that's why they have an iBGP session through a security infrastructure).
I repeat my big doubt: Why the client CE2 (or the vrf D of PE2) can import the subnet X (172.16.0.0.0/16) with a rt ext comm of 3:3? and why the vrf E of PE3 can't import it?
Regards
06-06-2022 06:37 AM
Hi @Andreseo90 ,
Prefixes imported in a VRF will not be exported to VPNv4. So the path from VPN A --> VPN B --> VPN C --> VPNv4 is not an option. The best way to propagate prefix X to VPN E would be to export RT 3:3 for VRF A, so that VRF E can import it directly.
Regards,
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide