08-27-2015 10:16 AM
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
Solved! Go to Solution.
09-02-2015 04:36 AM
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
10-10-2016 06:51 PM
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
09-02-2015 04:36 AM
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
10-10-2016 03:56 PM
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.
10-10-2016 06:51 PM
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
10-10-2016 07:17 PM
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.
10-10-2016 07:25 PM
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
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