LDP Inbound Label Advertisement Filtering

Load isis.cfg

#IOS-XE
config replace flash:isis.cfg

#IOS-XR
configure
load bootflash:isis.cfg
commit replace
y

• Configure LDP using LDP autoconfig under ISIS

• Configure inbound label filtering on R1 and XR2 to filter out label bindings received from their LDP neighbors for all transit prefixes

Answer

#R1-6
router isis
 mpls ldp autoconfig

#R1
ip access-list standard LDP_FILTER_IN
 deny 10.0.0.0 0.255.255.255
 permit host 20.20.20.20
 deny 20.0.0.0 0.255.255.255
 permit any
!
mpls ldp neighbor 2.2.2.2 labels accept LDP_FILTER_IN

#XR1, XR2
router isis 1
 add ipv4
  mpls ldp auto-config
!
mpls ldp

#XR2
ipv4 access-list LDP_FILTER_IN
 10 deny ipv4 10.0.0.0/8 any
 20 permit ipv4 host 20.20.20.20 any
 30 deny ipv4 20.0.0.0/8 any
 40 permit ipv4 any any
!
mpls ldp
 address-family ipv4
  label
   remote
    accept
     from 19.19.19.19:0 for LDP_FILTER_IN

Explanation

Inbound LDP advertisement filtering is much easier to configure than outbound advertisement filtering. In both IOS-XE and IOS-XR, we must apply an ACL on a per-neighbor basis to filter incoming LDP bindings.

On IOS-XE, we use the following command:

#IOS-XE
mpls ldp neighbor RID labels accept ACL

On IOS-XR, we use the following command:

#IOS-XR
mpls ldp
 address-family ipv4
  label
   remote
    accept
     from RID:0 for ACL

Verification

On R1, since R2 is the only LDP peer, we can look at the LDP bindings summary for a quick check that the inbound filtering is working. Before implementing the filter, we see that we have one remote binding for every prefix:

After implementing the filter, we should only see a remote binding for the /32 loopbacks, due to our standard ACL we are applying for R2:

Likewise, on XR2, we can use the same command. First we verify that we are receiving one remote label (from XR1) for every prefix:

Next, we apply the inbound filter and verify that XR2 has discarded XR1’s bindings for non-loopback prefixes: