Hello,
How can we use “show bgp vpnv4 unicast vrf CUSTOMER summary” to check bgp neighbor with CE, it shouldn’t be “show bgp ipv4…”???
Thank you
Hello Bilel
What you suggest makes perfect sense. If you’re issuing a show bgp command with the VPNv4 address family in the PE, you would assume that nothing would show up for the peering with the CE router since the CE router is oblivious to VPNv4 information correct? But we do see the CE peer.
Let’s take a look at why we see the CE neighbor in this output:
Remember, on a PE router, there are two “planes” of BGP in this topology: the VPNv4 AF (Address Family), used between PEs in the MPLS core, and IPv4 unicast AF inside a VRF, used between PE and CE.
In Cisco IOS, when you run show bgp vpnv4 unicast vrf CUSTOMER summary, what you’re doing is asking for the VPNv4 address family, but within the specific CUSTOMER VRF. The CE–PE neighbors appear in the output of the command because their routes are what populate the VRF, and those VRF routes are exported into the VPNv4 AF. So no matter what AFI/SAFI that VRF is carrying, the output will show the neighbors within that VRF.
Since the only BGP session in the CUSTOMER VRF is PE1 ↔ CE1 (AS 1), IOS reports that neighbor under the vpnv4 display context. In other words, the CLI output is slightly misleading. It uses the vpnv4 keyword as an entry point to VRF-aware BGP, but the neighbor it’s showing is really in the IPv4 unicast AF for that VRF.
If you run show bgp ipv4 unicast vrf CUSTOMER summary, you should see the same CE1 neighbor with the same counters. If you issue the show bgp vpnv4 unicast all summary command, it would show your PE–PE MP-BGP sessions (if configured).
So the reason you see CE1 is the vpnv4 ... vrf command, IOS displays per-VRF BGP neighbors, which in this case include CE1. It doesn’t mean CE1 is participating in VPNv4 MP-BGP, it just happens that CE1 is the VRF’s only neighbor, so it shows up there. Make sense?
I hope this has been helpful!
Laz
1 Like
Yes Got it thank you
Hi Rene and team, i’ve a question but first i explain my scenario.
I’ve 2 router in the same AS and I have one interface vlan on each router that i’ve put in a VRF (the same VRF for each router). The two routers have established adjacency both in the BGP global configuration and within the address family corresponding to the VRF. However, when I type the command sh bgp vpnv4 unicast vrf XXX the output returns an idle state. However, pinging between the advertised networks works. Is this normal behavior since adjacency occurs both in the global configuration and on the VRF address family?
Thanks a lot.
Hello Gino
I believe that I have understood your question, and I will do my best to respond. If I have understood your topology, this is actually expected behavior, and I’ll explain why.
Based on your description, you have:
- 2 PE routers in the same AS
- VRF instances configured on both routers
- BGP peering established in two places:
- Global BGP configuration (iBGP peering)
- Within the VRF address-family
So in essence, you’re running two separate BGP sessions. The first is the VPNv4 BGP session. This is the standard MPLS L3VPN approach where BGP peers are configured under the global BGP process, the VPNv4 address-family is activated between PE routers, where RDs and RTs are used, and where routes are exchanged with MPLS labels.
The second is the IPv4 BGP session. This is what you configured under the VRF address-family, resulting in a BGP peering directly between interfaces in the VRF. This exchanges standard IPv4 unicast routes, and no VPNv4 encapsulation needed.
So why does the show bgp vpnv4 unicast vrf XXX show Idle?
The command show bgp vpnv4 unicast vrf XXX displays the VPNv4 BGP session status, which should show your global iBGP peering between the PE routers, NOT the VRF-specific BGP session.
If it shows “idle,” this typically means that no VPNv4 neighbor is configured for this VRF in the global BGP, or that the VPNv4 session isn’t established properly.
Some clarifications may be in order. Could you tell us more about the following?
- Are these PE routers or one acting as CE?
- What’s your end goal - learning MPLS L3VPN or solving a specific requirement?
If you let us know the above, we can help us to provide more targeted guidance.
I hope this has been helpful!
Laz
Hey Laz, thanks so much for your reply.
I’ll try to give you more details.
First, I’ll answer your questions. Both are PE routers, and the ultimate goal is to understand how neighborship works in VRFs within the same autonomous system.
Keep in mind that the lab configuration I’m using is based on EVE-NG with iOS XE.
I’m attaching screenshots of the two configurations and the output from the “sh bpg vpnv4 unicast vrf BLUE summary” command.
Between the two PEs, I have a P that doesn’t participate in any routing process other than OSPF.
Yet ping within vrf BLUE networks works… Perhaps just as you say, because adjacency also occurs in the global configuration?
Thank you again for your time.
Hello Gino
Thanks for the details and the clarification! Indeed, it looks like the reason for this behavior is the fact that the adjacency occurs not in the VRF context, but in the global routing context.
I hope this has been helpful!
Laz
1 Like