no mpls ldp advertise-labels

no mpls ldp advertise-labels
mpls ldp advertise-labels for 10

 

Hi,

I am configuring an MPLS core of 2x7606 and 4xMX240 - Juniper. On the cisco's I'm playing around with this command and use ACL 10 for the interfaces where MPLS will run plus the loopback for BGP and LDP. I have assigned 2x /24 for the loopback range and also for the core /30 interfaces and just include both those /24's in the ACL.

LDP neighbours are UP.

But I don't really understand this command. Will it cause problems when I run MP-BGP with L3 VPN's? Assume all the VPN prefixes will still be labelled?

Anyone know what the equivalent command in JUNOS might be?

Also, anyone got an opinion on 7606 stable but recent code release. Is T train too risky on 12.4 for a core router? The Junipers are right up to date. Any production caveats people are aware of with MPLS between these devices - interoperability-wise - feel free to chime in.

Cheers,

Chris

 

 

 

 

Comments



  • Re: [CCIE SP] no mpls ldp advertise-labels


    Hi there,



    In a nutshell it gives you a granular way of you choosing which prefixes you want advertised within the forwarding table and each prefix defined via the acl will have an ldp label assigned. By default the router will put everything it receives in however it may not be desirable for your up/downstrean neighbor to have these prefixes.



    Comes in handy for Inter-AS type scenarios where you only want to advertise the next hop addresses from one AS to another and not leak to many routes



    There is also another method using pefix-lists:





    mpls ldp label  

     allocate global prefix-list list1

    !

    Ip Prefix-list 1 permit a.b.c.d/??



    Hope that helps



    James









    On 10/29/08 7:41 PM, "escapeuk" <[email protected]> wrote:



    no mpls ldp advertise-labels

    mpls ldp advertise-labels for 10



     



    Hi,



    I am configuring an MPLS core of 2x7606 and 4xMX240 - Juniper. On the cisco's I'm playing around with this command and use ACL 10 for the interfaces where MPLS will run plus the loopback for BGP and LDP. I have assigned 2x /24 for the loopback range and also for the core /30 interfaces and just include both those /24's in the ACL.



    LDP neighbours are UP.



    But I don't really understand this command. Will it cause problems when I run MP-BGP with L3 VPN's? Assume all the VPN prefixes will still be labelled?



    Anyone know what the equivalent command in JUNOS might be?



    Also, anyone got an opinion on 7606 stable but recent code release. Is T train too risky on 12.4 for a core router? The Junipers are right up to date. Any production caveats people are aware of with MPLS between these devices - interoperability-wise - feel free to chime in.



    Cheers,



    Chris



     



     



     



     









    Internetwork Expert - The Industry Leader in CCIE Preparation

    http://www.internetworkexpert.com



    Subscription information may be found at:

    http://www.ieoc.com/forums/ForumSubscriptions.aspx



  • I am also having some confusion regarding the same.

    Suppose i have the following scnario,

    CUST_A---PE1----PX-------PY--------PZ------PE2---CUST_A

    If i configure on PY router the following,

    no mpls ldp advertise-labels
    mpls ldp advertise-labels for 5

    access-list 5 per "lo0 of PY"

    I need to understand the effect of configuring the above command based on the
    ACL.

    What will be the effect if i donot permit anything in the ACL?
    What if only loopback of the PY is permited in the ACL?


    Can anyone expalin this please?

    So my point to undestand is that i am connected to my LDP neighbors ....what label i MUST allow on my local router for a successful L3-VPN communication bw my customer sites?

    thanks for the help.

     

  • Here is the documentation for this command:

    http://www.cisco.com/en/US/docs/ios/mpls/command/reference/mp_m1.html#wp1015111

    I'm finding it a bit hard to get my head around the rules of using the for and to ACLs.

     

    The documentation says that "A given (prefix acl, peer acl) pair "applies" to a prefix only if the prefix acl "matches" the prefix. A match occurs if the prefix acl permits the prefix." But then it goes on to say that "If a (prefix acl, peer acl) pair applies to the prefix, and if the prefix acl "denies" the prefix, the label is not advertised to any peer."

     

    This confuses me. So to apply you need to permit the prefix, but if it applies and the prefix acl denies the prefix then it's not advertised. It seems a bit paradoxical. To apply it must be a permit, but to not be advertised it must apply and have a deny statement.

     

    Can anyone explain it better? I'm going to lab this a bit and see if I can figure out how it actually behaves.

  • My topology looks like this R1 - R2 - R3. I have OSPF running everywhere and LDP configured on all transit links. R3 has a targeted LDP session with R1.

    So I have loopbacks 150.1.3.3 and 33.33.33.33 on R3. The following command is on R3:


    no mpls ldp advertise-labels
    mpls ldp advertise-labels for DENY_LOOP33 to R2



    ip access-list standard DENY_LOOP33

     deny   33.33.33.33

    ip access-list standard R2

     permit 150.1.2.2

     

    Sorry for the formatting, this Macbook does weird things, I'm not used to it yet.

    So DENY_LOOP33 has explicit deny for the loopback and then an implicit deny. The result of this was no labels advertised from R3 to R1 or R2.

     

    There are no acl matches in the detailed mpls ip bindings table (lib).

     


    Rack1R3#sh mpls ip bind det

    Advertisement spec:

            Prefix acl = DENY_LOOP33; Peer acl = R2

     

      10.1.12.0/24, rev 88

            in label:     16        

            out label:    imp-null  lsr: 150.1.2.2:0      inuse

            out label:    imp-null  lsr: 150.1.1.1:0     

      10.1.23.0/24, rev 89

            in label:     imp-null  

            out label:    imp-null  lsr: 150.1.2.2:0     

            out label:    16        lsr: 150.1.1.1:0     

      10.1.223.0/24, rev 90

            in label:     imp-null  

            out label:    imp-null  lsr: 150.1.2.2:0     

            out label:    17        lsr: 150.1.1.1:0     

      33.33.33.33/32, rev 78

            in label:     imp-null  

            out label:    18        lsr: 150.1.2.2:0     

            out label:    20        lsr: 150.1.1.1:0     

     

    R2 doesn't have labels advertised from R3.


    Rack1R2#sh mpls ip bind 150.1.3.3 32

      150.1.3.3/32 

            in label:     17        

            out label:    19        lsr: 150.1.1.1:0 


    Rack1R2#sh mpls forwarding-table 

    Local  Outgoing      Prefix            Bytes Label   Outgoing   Next Hop    

    Label  Label or VC   or Tunnel Id      Switched      interface              

    16     Pop Label     150.1.1.1/32      54918         Fa0/0.1    10.1.12.1   

    17     No Label      150.1.3.3/32      3496          Fa0/0.2    10.1.23.3   

    18     No Label      33.33.33.33/32    0             Fa0/0.2    10.1.23.3 

     

    Neither does R1.

     

    Now I'll add a permit to the prefix acl.

     


    Rack1R3(config)#ip access-list st DENY_LOOP33

    Rack1R3(config-std-nacl)#permit any

    Rack1R3(config-std-nacl)#end

    Rack1R3#

     

    Now R2 has received implicit-null from R3 for 150.1.3.3 but no label for 33.33.33.33 (this is what we wanted to do).

     


    Rack1R2#sh mpls forwarding-table 

    Local  Outgoing      Prefix            Bytes Label   Outgoing   Next Hop    

    Label  Label or VC   or Tunnel Id      Switched      interface              

    16     Pop Label     150.1.1.1/32      55424         Fa0/0.1    10.1.12.1   

    17     Pop Label     150.1.3.3/32      240           Fa0/0.2    10.1.23.3   

    18     No Label      33.33.33.33/32    0             Fa0/0.2    10.1.23.3 

     

    R3 now shows ACL hits in the detailed ip lib output:

     


    Rack1R3#sh mpls ip bind det

    Advertisement spec:

            Prefix acl = DENY_LOOP33; Peer acl = R2

    ...

      33.33.33.33/32, rev 78

            in label:     imp-null  

            out label:    18        lsr: 150.1.2.2:0     

            out label:    20        lsr: 150.1.1.1:0     

      150.1.1.1/32, rev 97

            in label:     17        

              Advertised to:

              150.1.2.2:0            

            out label:    16        lsr: 150.1.2.2:0      inuse

            out label:    imp-null  lsr: 150.1.1.1:0     

            Advert acl(s): Prefix acl DENY_LOOP33; Peer acl R2

      150.1.2.2/32, rev 98

            in label:     18        

              Advertised to:

              150.1.2.2:0            

            out label:    imp-null  lsr: 150.1.2.2:0      inuse

            out label:    18        lsr: 150.1.1.1:0     

            Advert acl(s): Prefix acl DENY_LOOP33; Peer acl R2

      150.1.3.3/32, rev 99

            in label:     imp-null  

              Advertised to:

              150.1.2.2:0            

            out label:    17        lsr: 150.1.2.2:0     

            out label:    19        lsr: 150.1.1.1:0     

            Advert acl(s): Prefix acl DENY_LOOP33; Peer acl R2

     

    So these are permitted by the permit line but the 33.33.33.33 is not showing a hit on the ACL, which means I guess it falls through to the default "no mpls ldp advertise-labels" command which prevents it being advertised. This seems to answer the idea that you need to have a permit statement to match the prefix ACL for it to take effect.

    Now I'll configure an extra statement that permits 33.33.33.33 to R2.

     

    mpls ldp advertise-labels for PERMIT_LOOP33 to R2


    ip access-list standard PERMIT_LOOP33

     permit 33.33.33.33

     

    Now R2 sees the label for 150.1.3.3 and 33.33.33.33, so it seems like if you have a deny in the prefix acl it falls through to being processed by the next mpls ldp advertise-labels, command. It doesn't deny the prefix being advertised, it processes the next line.

     

    Not adding a to ACL will cause the router to perform the action for all LDP peers. E.g. if you turn off ldp advertisement then permit only one prefix, then this one prefix will have a label advertised to all peers and all other prefixes will be denied.

     

    So what happens with the peer ACL. R1 is implicitly denied by the current peer ACL and it is not seeing any labels from R3 right now. Let's explicitly deny it and see if anything changes.

    No, R1 still doesn't see any labels.

     

    So to get the labels to R1 we need to permit the label in the prefix acl and permit the LDP ID but the prefixes have all hit a prefix acl and they are allowed to only hit one so we'd have to remove some of the rules to allow them to be advertised to R1.

     

    So you need to break up the prefixes into what you want advertised (prefix-acl permits) and to who (peer acl permits). Once it matches a prefix-acl it can no longer be controlled by further statements.

     

    I'm still not sure about rule 3 c, where the prefix "applies" but is "denied"... it seems to only apply if it is permitted....

  • Command with all options is as follows:

     

    mpls ldp advertise-labels [vrf vpn-name] [interface interface | for prefix-access-list [to peer-access-list]] 

    vrf - this keyword is obvious, use this command for MPLS enabled on VRF (CsC?)

    for - access-list with definition of prefixes we want to assign label to; only permit is allowed; 

    eg. access-l 1 permit 10.0.0.0 0.0.0.255

    Labels will be assigned to all prefixes included in 10.0.0.0/24

    to - access-list with definition of IP addresses of LDP neighbors which should receive this particular advertisement

    I don't have any listings to show you, but I remember that it worked fine.

    Cheers,

    Seba

     

  • The hard / important part - as I understand - is the point 3.b of the doku posted bevor (http://www.cisco.com/en/US/docs/ios/mpls/command/reference/mp_m1.html#wp1015111)

    3.b. imageIf none applies, and if the no mpls ldp advertise-labels
    command has been configured, the label for the prefix is not advertised
    to any peer; otherwise, the label is advertised to all peers.

    e.g. the implicit deny any of the access-lists does not apply her or is 'replaced' by no mpls ldp advertise-labels

    Ueli

Sign In or Register to comment.