MPLS Layer 3 VPN Configuration

[lagapidis (Lazarus Agapidis)]

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

[bilel.salem.official (Bilel SALEM)]

Yes Got it thank you

[reyoda1167 (Gino Rox)]

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.

[lagapidis (Lazarus Agapidis)]

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:
  1. Global BGP configuration (iBGP peering)
  2. 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?

1. Are these PE routers or one acting as CE?
2. 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

[reyoda1167 (Gino Rox)]

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.

[lagapidis (Lazarus Agapidis)]

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

[pc_evans (Patrick Evans)]

Hello Rene,

Love your site. I teach CCNP at a local college. My students have access to all Cisco Press content for free via Oreilly Media and I still tell them that its worth paying for your subscription.

Can you explain why MPLS doesn’t work if the loopback is a /24? Attached is a screen capture with PE2 using the loopback of 4.4.4.4/24.

[lagapidis (Lazarus Agapidis)]

Hello Patrick

It’s great to hear that you enjoy the content on our site! Teaching CCNP-level stuff is very satisfying. I hope you’re enjoying your time. And thanks for recommending the site to your students!

@pc_evans

Can you explain why MPLS doesn’t work if the loopback is a /24? Attached is a screen capture with PE2 using the loopback of 4.4.4.4/24.

Yep, this is an interesting one. MPLS doesn’t work properly when the loopback is configured as /24 because of a mismatch between how OSPF advertises the loopback prefix versus how LDP expects to see it.

OSPF automatically advertises loopback interfaces as /32 host routes, regardless of the actual subnet mask configured on the interface. This is defined in RFC 2328 section 12.4.1, where it states that:

If the state of the interface is Loopback… …the Link ID should be set to the IP interface address, the Link Data set to the mask 0xffffffff (indicating a host route), and the cost set to 0.

The mask of 0xffffffff is equivalent to a mask of /32. So, by definition of OSPF, loopbacks will always report a /32 host address regardless of the configured interface.

Now LDP advertises prefixes using the actual configured subnet mask on the interface. So if you configure 4.4.4.4/24, LDP will advertise it as 4.4.4.0/24.

So when PE2 has a loopback of 4.4.4.4/24, OSPF advertises it as 4.4.4.4/32 and LDP advertises it as 4.4.4.0/24. This creates a disparity where other routers learn different prefixes via the IGP versus LDP, causing label bindings to fail and breaking the MPLS forwarding plane.

So when you use OSPF, you should either use /32 subnets on your loopbacks, or you can issue the ip ospf network point-to-point command on the loopback interface. This tells the router that this network is no longer a loopback but should be treated as a point-to-point. This will allow OSPF to advertise the /24 subnet mask.

However, using /32 is recommended because it’s the simplest approach and avoids configuration complexity. Most production MPLS networks use /32 loopbacks. Similar considerations must be taken into account if you use other underlay IGPs such as IS-IS. The default behavior there may vary.

In any case, this is indeed an interesting behavior, and it’s useful to examine and understand how it works!

I hope this has been helpful!

Laz