VPNV4 label allocation

[dfauluchi]

Hi!

I have a question about label allocation. I can't figure out how can I controll this behavior.

I have a few PEs, all of them ASR9010.

There's one that allocates a new local label for each vpnv4 prefix it receives from RR, even if label mode per-vrf is configured. Right now it has assigned 540K labels, there are no labels available for FRT.

sh mpls label table summary
Thu May 13 18:09:23.996 GMT
Application Count
---------------------------- -------
LSD(A) 4
BGP-VPNv4(A):bgp-default 540117
LDP(S) 937
L2VPN(A) 1492
LDP(A) 978
BGP-VPNv4(S):bgp-default 540117
---------------------------- -------
TOTAL 542140

- Why would assign local labels for prefixes it's not advertising?
- Why label mode per-vrf does not change this behavior.

There’s another PE with FRT (823K prefixes, 1.7M paths) and it’s using ~1.5k labels.
This second one does not assign one label for each vpnv4 prefix it receives from RR.

sh mpls label table summary
Thu May 13 18:11:30.656 GMT
Application Count
---------------------------- -------
LSD(A) 4
LDP(A) 186
BGP-VPNv4(A):bgp-default 1291
LDP(S) 44
BGP-VPNv4(S):bgp-default 1291
---------------------------- -------
TOTAL 1469

The question is which conditions make these 2 routers to behave differently?

In my LAB I found that in some routers, using next-hop-self in vpnv4 session with RR will demand labels. Removing it frees label space.
In other routers that initially demanded label allocation, removing next-hop-self in vpnv4 session doesn’t free label space.
Other guess is that being an inline-RR may affect this behavior.

Thanks!!!

[Harold Ritter]

Hi @dfauluchi ,

VPNv4 label allocation occurs on the egress PE, not on the ingress PE. The PE receiving the VPNv4 prefixes from the RR will not allocate local labels for those prefixes.

When per-VRF allocation mode is configured on a given PE, that PE will allocate 1 aggregate label per locally attached VRF.

Regards,

[dfauluchi]

Hi Harold,

Thanks for your answer.

I agree with you, about label allocation, but it's happening. So there must be certain conditions in which it occours.

One thing I found in my lab is that label allocation for thore prefixes is done when we have next-hop-self in the vpnv4 session to the RR. But removing next-hop-self does not always remove those labels. So I think there are more conditions.

This PE is also an inline RR, perhaps it's another condition.

This is a fragment of my mpls forwarding table i've taken from my PE, where 20.10.10.9 emulates an IGW and 20.10.10.9:3200 is the RD of my emulated FRT.

IGW is advertising one label per vrf: 24047, and this PE allocates one label for each vpnv4 prefix:

24277 24047 20.10.10.9:3200:100.64.228.0/24 \
20.10.10.9 0
24278 24047 20.10.10.9:3200:100.64.229.0/24 \
20.10.10.9 0
24279 24047 20.10.10.9:3200:100.64.230.0/24 \
20.10.10.9 0
24280 24047 20.10.10.9:3200:100.64.231.0/24 \
20.10.10.9 0
24281 24047 20.10.10.9:3200:100.64.232.0/24 \
20.10.10.9 0
24282 24047 20.10.10.9:3200:100.64.233.0/24 \
20.10.10.9 0
24283 24047 20.10.10.9:3200:100.64.234.0/24 \
20.10.10.9 0
24284 24047 20.10.10.9:3200:100.64.235.0/24 \

So label table gets full before I can reveive FRT.

Any idea why is it happening?

Thanks in advance!

Diego

[Harold Ritter]

Thanks for the additional info @dfauluchi ,

It would definitely help to get the configuration of this PE. Also, could you please tell me what you mean by FRT?

Regards,

[dfauluchi]

Hi Harold,

I'm sorry I didn't explain this earlier. FRT is the internet routing table.

HL3 are upstream routers which act as inline RR. In my lab they are also Internet Gateways.

HL5 are ipv4 LU and vpnv4 RR clients. This PE is an inline RR too.

vrf INT
address-family ipv4 unicast
import route-target
65000:3204
!
export route-target
65000:3203
!
!

router bgp 65000
nsr
bfd minimum-interval 50
bfd multiplier 3
bgp router-id 20.10.10.17
!
bgp graceful-restart
bgp log neighbor changes detail
ibgp policy out enforce-modifications
address-family ipv4 unicast
additional-paths receive
additional-paths send
additional-paths selection route-policy BGP-PIC
network 20.10.10.17/32 route-policy aigp_policy
redistribute connected
allocate-label all
!
address-family vpnv4 unicast
additional-paths receive
additional-paths send
additional-paths selection route-policy BGP-PIC
retain route-target all
!
address-family ipv4 rt-filter
!
neighbor-group HL3
remote-as 65000
bfd fast-detect
advertisement-interval 1 0
update-source Loopback0
address-family ipv4 unicast
!
address-family ipv4 labeled-unicast
aigp
next-hop-self
!
address-family vpnv4 unicast
aigp
next-hop-self
!
!
neighbor-group HL5
remote-as 65000
bfd fast-detect
update-source Loopback1
address-family ipv4 labeled-unicast
aigp
route-reflector-client
capability orf prefix receive
next-hop-self
!
address-family vpnv4 unicast
route-reflector-client
!
address-family ipv4 rt-filter
route-reflector-client
!
!
neighbor 20.10.10.9
use neighbor-group HL3
description ASR9010-1515
!
neighbor 20.10.10.15
use neighbor-group HL3
description HL3-1-POP-2
!
neighbor 20.10.10.25
use neighbor-group HL5
description HuaweiATN910i_15-35-1
!
vrf INT
rd 20.10.10.17:3200
address-family ipv4 unicast
!
!

Kind regards.

[Harold Ritter]

Hi Diego,

The issue is that this PE is configured as a RR (route-reflector-client). It is reflecting the VPNv4 prefixes received from neighbor 20.10.10.9 to neighbor 20.10.10.25. And since you also configured next-hop-self, which makes it an inline RR, the PE allocates a local label for each and every VPNv4 prefix, hence the issue you are seeing.

Can you explain why this PE is configured as a RR for VPNv4 routes?

Removing the route-reflector-client from address-family vpnv4 unicast under neighbor-group HL5 should solve the issue.

Regards,

[dfauluchi]

Hi Harold,

First I'll try to explain why we need this PE as an inline RR.

Downstream routers are not capable of handling large route tables or have small label table (~500). To reduce both, this PE generates a default route per vrf and sits as next hop only for these RR clients and only for the 2 vrfs they use. All other prefixes are filtered. When upstream packets arrive to PE is able to send it to destination.

I understand why it's using labels. Now, what I would like to achieve is to scale. We are just starting and label table is at 55%. And it looks like any new vpnv4 prefix in any point in the network will consume 2 labels in this PE. No mention for full internet table.

I tried using label mode per-vrf (global and per vrf), but still allocates one label per prefix.

There are 2 RR for vpnv4 and 2 dedicated RR for internet table (also vpnv4). I will try to reproduce this in my lab and see if behavior is affeced by next-hop-self.

Thanks for helping me out.

Best regards, Diego.

[Harold Ritter · Accepted solution]

Hi Diego,

Thanks for the additional info. Here are a few observations.

> To reduce both, this PE generates a default route per vrf and sits as next hop only for these RR clients and only for the 2 vrfs they use.

I suppose that you only allow the default route towards the smaller PE?

The next-hop-self is what is causing the issue, but I am not sure why the PE (20.10.10.17) with more resources needs to be inline for traffic going toward the smaller PE (20.10.10.25). I think you could safely remove the next-hop-self. This would solve the issue.

Regards,

[dfauluchi]

Hi Harold,

I will test that in my LAB.

Thanks a lot!

Best regards!

[dfauluchi]

Hi!

We see that having an Inter-AS op B also triggers label allocation for all vpnv4 prefixes. And it does not depend on next-hop-self.

Is there any way to overcome this?

router bgp 65000

neighbor A.B.C.D

  remote-as 65001

  update-source Bundle-Ether600.600

  address-family vpnv4 unicast

   route-policy L3VPN in

   route-policy L3VPN out

   soft-reconfiguration inbound always

Thanks in advance!

Diego.

[Harold Ritter]

Hi Diego,

> We see that having an Inter-AS op B also triggers label allocation for all vpnv4 prefixes.

This is indeed the normal behavior.

> And it does not depend on next-hop-self.

next-hop-self is the default behavior for eBGP, so will behave as next-hop-self without configuring it.

> Is there any way to overcome this?

The only way I can think of would be to move to option C.

Regards,