cancel
Showing results forĀ 
Search instead forĀ 
Did you mean:Ā 
cancel
3657
Views
5
Helpful
5
Replies

IOS XR-ASR9000 / MPLS Label Advertise vs Label Allocate

Hello,

I'm looking for guidance about what would be the best practice and configuration validation in order to disable the use of labels for just a couple of prefixes while maintaining the normal MPLS label allocation and advertising behavior for the rest of the prefixes. The use-case is for CGN in the ASR9000 using the VSM-500 which doesn't accept MPLS labeled incoming packets.

I see two options: Label Advertise (Outbound Label Filtering) or Label Allocation. I'm leaning on the second option (Label Allocation) because it not only would prevent that labels are advertised for prefixes that shouldn't be labeled, but also it would save some resources in the system since those label wouldn't be generated as in the case of Label Advertising Filtering.

Option 1: Label Advertise:

In the configuration guides and the command reference examples I found cases to advertise some prefixes to selected LDP peers but nothing about how to filter out some prefixes from the advertising. So I have a couple of ideas of how to do this, it would be great if somebody can confirm that they work and what would be the preferred or optimum in terms of performance and resource usage.

Option 1a: Label Advertise without "disable" command using "deny" statements in the ACL:

I'm wondering if a "deny" statement in the prefix access-list without using the disable option would do the trick (like the oldstyle configuration if you are familiar with IOS). Since I'm not disabling the regular label advertising I just deny the undesired prefixes in MPLS to all LDP Peers. For example:

ipv4 access-list Deny_CGN_Private

   deny 100.64.1.0

   deny 100.64.2.0

 

mpls ldp

ā€‹   label advertise

      for Deny_CGN_Private

 

Option 1b: Label Advertise with "disable" command using "deny" statements and "permit any" in the ACL

Very similar to Option 1a, but since I will be disabling normal label advertising, I would need to add a permit any at the end of the ACL:

ipv4 access-list Deny_CGN_Private

   deny 100.64.1.0

   deny 100.64.2.0

ā€‹   permit any

 

mpls ldp

ā€‹   label advertise

ā€‹      disable

      for Deny_CGN_Private

 

ā€‹Option 1c: Label Advertise without "disable" command using a "dummy" LDP Neighbor to advertise the undesired prefixes in MPLS:

If a deny statement won't do the job in either of the previous cases, one option would be to advertise the undesired prefixes to an inexistent or "dummy" LDP peer. Because regular label advertising is not disabled all other prefixes will get their labels advertised to all LDP peers with the exception of those advertised only to the "dummy" LDP Peer. For example:

ipv4 access-list CGN_Private

   permit 100.64.1.0

   permit 100.64.2.0

 

ipv4 access-list Dummy_LDP_Peer

   permit 1.1.1.1

ā€‹ā€‹

mpls ldp

   label advertise

ā€‹      for CGN_Private to Dummy_LDP_Peer

 

ā€‹Option 2: Label Allocate

ā€‹As in the case of label advertising, I'm not finding and example to filter out some prefixes from the regular label allocation, so I would like to know if the following configuration would result in the desired behavior which is prevent the label advertising of the CGN prefixes:

ipv4 access-list Deny_CGN_Private

   deny 100.64.1.0

   deny 100.64.2.0

ā€‹   permit any

ā€‹ā€‹

mpls ldp

ā€‹   label allocate for Deny_CGN_Private

 

Please let me know your thoughts and suggestions

Best Regards

Jacobo Schneider

CCIE-SP #24940

2 Accepted Solutions

Accepted Solutions

xthuijs
Cisco Employee
Cisco Employee

hi jacobo,

either approach is fine really. as long as the upstream peer sends plain ip for the vsm prefixes you'll be fine.

I think option 2 is easiest to use since it is easy to expand if the pool ranges increase for which you dont want to allocate labels for and it is also the simplest config.

regards

xander

View solution in original post

hi hector,

the advertise disable will disable all advertisement, so you probably dont want to use that, but the previous section for allocate for <acl> is perfect to control that piece you want, you obviously want to allocate a label for all your local interfaces, especially mpls ldp enabled ones and PE loopbacks since VPN/LDP will use that as a peering point and obviously your IGP labels for mpls enabled interfaces.

you can choose to make per node prefix sets for that with acls or you can use the keyword "host-routes" for that to make it more simple across your devics...

cheers!

xander

View solution in original post

5 Replies 5

xthuijs
Cisco Employee
Cisco Employee

hi jacobo,

either approach is fine really. as long as the upstream peer sends plain ip for the vsm prefixes you'll be fine.

I think option 2 is easiest to use since it is easy to expand if the pool ranges increase for which you dont want to allocate labels for and it is also the simplest config.

regards

xander

Hello  Team

I am also using a core mpls to connect the internet users to the CGNAT.

In our case we are planning to use the Core devices in a sort of router on stick: the VRFdefault for the outside (and routing to the internet) and L3 MPLS VPN for the inside users and routing.

I am looking for a solution to assign labels only to the PE loopbacks to prevent resource wasting and separate the ouside and inside as completely as possible. Below is my proposal could you comment ? Do you believe that is over-configured?

ipv4 access-list LDP-Directly-Peers
 10 permit ipv4 host <Loopback Interface for Directly Connected Peers> any
!
ipv4 access-list PE-Loopbacks
 10 permit ipv4 host <IP Address PE Loopback> any
!
mpls ldp
 log
  neighbor
  nsr
  graceful-restart
 !
 nsr
 graceful-restart
 igp sync delay on-session-up 5
 router-id <IP Lo0>
 session protection for LDP-Directly-Peers duration 60
 address-family ipv4
  label
   local
    allocate for PE-Loopbacks
    advertise
     disable
     for PE-Loopbacks to PE-Loopbacks
    !
   !
  !
 !
 interface Type Number
 !
mpls oam
!

Thanks in advance for your attention.

Best regards

Hector L.

hi hector,

the advertise disable will disable all advertisement, so you probably dont want to use that, but the previous section for allocate for <acl> is perfect to control that piece you want, you obviously want to allocate a label for all your local interfaces, especially mpls ldp enabled ones and PE loopbacks since VPN/LDP will use that as a peering point and obviously your IGP labels for mpls enabled interfaces.

you can choose to make per node prefix sets for that with acls or you can use the keyword "host-routes" for that to make it more simple across your devics...

cheers!

xander

Hello Xander

Thank you for your so quick reply and your always valuable help!

I followed the example below.

mpls ldp
 label
  advertise
   disable
   for pfx_acl_1 to peer_acl_1

http://www.cisco.com/c/en/us/td/docs/ios_xr_sw/iosxr_r3-7/mpls/configuration/guide/gc37ldp.html#wp1166908

In the same URL:

label advertise {disable | for prefix-acl [to peer-acl] | interface interface-id}

Configures label advertisement as specified by one of the following arguments:

ā€¢disableā€”Disables label advertisement to all peers for all prefixes (if there are no other conflicting rules).

ā€¢interfaceā€”Specifies an interface for label advertisement of an interface address.

ā€¢for aclist to peer-aclā€”Specifies neighbors that advertise and receive label advertisements.

I understand that the expression after advertise disable:  for aclist to peer-acl should be a conflicting rule and the labels for the prefixes in aclist should be advertised to the peers in the peer-acl.

I would be grateful if you could comment maybe I'am losing some detail.

Best regards

Hector L.

hey hector,

your mind logic is (or actually 'was') good, the thing is that for...*to*... piece is deprecated in xr53.

one of the thought processes was that if we use the 'to ...' piece we could possibly shoot ourselves in the foot if we *do* advertise a PE loopback used in l3 (bgp nexthop) or l2vpn (ldp) over a certain interface, but we dont have a loopback label to that peer (/interface). general good practice is that if allocate a label for a loop that is used for such peering at a service level, it is best to advertise that out of ALL our peers.

if we prefer a path not to be taken/cosnidered, we probably need to consider other solutions such as TE or SR.

cheers!!

xander

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: