Junos Versus Cisco IOS: MPLS and LDP

The comments igp2bgp and Tiziano Tofoni made to my LDP-IGP Synchronization in MPLS Networks post prompted me to look deeper into basic Junos MPLS configuration and LDP behavior. As expected, there are some significant differences between Cisco’s and Juniper’s LDP implementations (and, as is usually the case, they’re both strictly conformant with RFC 5036).

Configuration Details

When you configure mpls ip on an interface in a Cisco router, you implicitly start LDP. In Junos, you have to start LDP explicitly by creating protocols ldp and list all interfaces on which LDP should run with interface commands within protocol ldp. Even that’s not enough; you have to enable MPLS family on each interface listed in the protocols ldp section.

Cisco IOS configuration

interface GigabitEthernet0/0/2
 mpls ip
interface GigabitEthernet0/0/3
 mpls ip
interface GigabitEthernet0/0/4
 mpls ip
interface GigabitEthernet0/0/5
 mpls ip

Equivalent Junos configuration

interfaces {
    ge-0/0/2 {
        unit 0 {
            family mpls;
        }
    }
    ge-0/0/3 {
        unit 0 {
            family mpls;
        }
    }
    ge-0/0/4 {
        unit 0 {
            family mpls;
        }
    }
    ge-0/0/5 {
        unit 0 {
            family mpls;
        }
    }
}
protocols {
    ldp {
        interface ge-0/0/2.0;
        interface ge-0/0/3.0;
        interface ge-0/0/4.0;
        interface ge-0/0/5.0;
    }
}

I am positive Junos approach has its benefits (and a very apparent verbosity drawback) and I’m not even trying to say which one is better – both CLIs are facts of life. And you don’t have to remind me there are commit scripts that can sync both parts of Junos configuration.

For whatever reason, during some of my tests LDP failed to start till I configured protocol ldp transport-address router-id. Reload might have helped ;)

Label Distribution Control Mode

Cisco IOS uses independent label distribution control – every LSR advertises a label for every IP prefix in its routing table that matches its label allocation policy (see also Label Allocation Rules below).

Junos uses ordered label distribution controlLSR allocates and advertises labels for prefixes configured with egress policy (see Label Allocation Rules below) and for prefixes in its IP routing table for which it’s already received a label mapping from the next-hop LSR.

In both cases, you can’t configure the label distribution control mode (more about whether that matters in a follow-up post).

Label Allocation Rules

Cisco IOS allocates an MPLS label for every non-BGP IP prefix in the IP routing table. You can change that behavior with allocate global prefix-list | host-routes global configuration command (introduced in 12.2SRC). You can also filter labels sent to LDP neighbors with the mpls ldp advertise-label global configuration command.

Junos allocates labels only for loopback interfaces. You can change the set of prefixes for which the local labels are allocated with the protocol ldp egress-policy (and outbound filters with the export policy).

Any IP prefix matched by the LDP egress policy will get a locally-originated label that will not be stitched with the label allocated by downstream LSR. Effectively, a Junos router becomes tail-end LSR for every prefix matched by the egress-policy.

To emulate Cisco IOS label allocation behavior on Junos, use the following configuration:

protocols {
    ldp {
        egress-policy connected;
        interface ge-0/0/2.0;
        interface ge-0/0/3.0;
        interface ge-0/0/4.0;
    }
}
policy-options {
    policy-statement connected {
        from protocol direct;
        then accept;
    }
}

FEC Aggregation

Cisco IOS allocates a different label to every IP prefix that deserves to get a label (see Label Allocation Rules).

Junos allocates a single label to all IP prefixes that have (A) the same IP next hop and (B) the same label advertised by the next-hop LSR. You can change that behavior with protocol ldp deaggregate command.

Does it matter?

In most well-designed networks, the differences between Cisco IOS and Junos are not significant (exception: in a BGP-free ISP core with external BGP next hops you have to allocate labels to external subnets).

Junos is way more conservative in its label allocation policy and will thus (with the default settings) generate fewer labels and consume fewer resources than Cisco IOS.

You can change most LDP parameters (apart from the label distribution control mode) and make Cisco IOS behave almost like Junos or vice versa.

So why does it matter? The only real reason is troubleshooting: you have to understand why you’re seeing fewer (or more) labels than you’d expect to see and why you don’t see a label for a prefix that should have one (hint: ordered label distribution control).

Disclosure

This post would never have been written without a gentle nudge from Tiziano and igp2bgp who’d tickled my curiosity. Thank you!

I did all the tests in Junosphere environment kindly provided by Juniper (thanks to @abnerg) ... but I never promised anyone I would write anything about Junosphere or Junos (and of course they knew I couldn’t possibly resist the temptation). For more details read the full disclosure (or more precise ones by Tony Bourke or Matt Simmons).

20 comments:

  1. As a matter of fact, in my J-series routers (and also with Olive, JUNOS 10.4R1.9) I am able to start LDP session without specifying any interfaces under the [protocols mpls] stanza, even if in all JUNOS documents you find that you have to enable interfaces inside [protocols mpls] also.
    What I find is that if you wanto to setup an MPLS-TE VC you need to enable interfaces under [protocols mpls] (and under [protocols rsvp] also !), but not for LDP (at least in real J-series routers, and Olive) .
    Frankly, from a conceptual point of view, I do not understand the need to specify interfaces under [protocols mpls] also when you want to enable LDP. LDP Hello messages start as soon as you commit configuration after enabling interfaces under [protocols ldp], and that is enough to start LDP sessions. I do not whether I am missing some points, but so far all LDP related configurations I made work fine.

    ReplyDelete
  2. I have a kind request to all people partecipating to this blog. I am surely an old-fashioned guy so I do not have any Facebook or Twitter accounts (I prefer climbing mountains instead of wasting my free time in front a "cold" PC).

    Could you please avoid to use Twitter to post your interesting comments ? Thanks a lot.

    ReplyDelete
  3. I got LDP/MPLS up and running without listing the interfaces in [protocols mpls], but had to specify "family mpls" under [interfaces]. Not sure whether that's connected with the need to specify "transport-address" within [protocols ldp] or not.

    ReplyDelete
  4. No, the "family mpls" under [edit interfaces name-interface.unit] is needed since Juniper touters interfaces by default accept IPv4 packets only. Adding "family mpls" instructs the router to accept packet from other protocols also. For instance, if you want an interface accept IPv6 packets you must add "family inet6", for IS-IS messages you must include "family iso", and so forth.
    But for whatever reason, if you forget to enable "family mpls" on an interface, on that interface you cannot have any LDP sessions, even if an LDP session does not require to be set up any MPLS packet. Probably the idea is that if you set up an LDP session on an interfacce, sometime in the future that interface will receive MPLS packets.
    Concerning "transport-address" you have to be very careful, since by default JUNOS uses as RID for every protocols (OSPF, BGP, LDP) the IP address configured under [routing-options] stanza. While for BGP and OSPF this address may be arbitrary (even unreachable, or totally invented) for LDP it must be L3-reachable since it is used by default for the TCP connection. So the best-practice I use is to define the router-id equal to the loopback interface address.
    This is different from IOS, where you can define different RID for each protocol. As a matter of fact, I use the same best prectice in Cisco IOS also. I usually define the RID of each protocol equal to the IP address of the Loopback 0 interface (and of course I advertise this interface in IGP !)

    ReplyDelete
  5. JunOS doesn't tie MPLS to LDP like Cisco does. RSVP is given equal footing in their label distribution protocols.

    ReplyDelete
  6. | Reload might have helped ;)

    You're just begging for the JunOS fanboy trolls to come in, aren't you? :)

    On a more serious note, thank you for clearing up some of the issues I was having.. expecting IOS behavior out of a Juniper router is hardly normal, but I had my own concerns with getting things functioning 100/100.

    ReplyDelete
  7. Actually, I managed to totally confuse Junos (or shall I say JunOS to feed the trolls ;) ) a few times during the last days. A perfectly legal configuration that I couldn't possibly make to work ... until after a reload.

    I'm positive it's just me, the negative energy I'm emitting, and my grumpy attitude.

    ReplyDelete
  8. Is that what the configuration on a Junos router looks like?

    I think I've just been sold on never even considering Junos switches and routers.

    ReplyDelete
  9. I think you made a wrong decision :-P

    ReplyDelete
  10. Like this fanboy!?

    "commit full" <-- 'full' is hidden keyword, but it forces complete rebuild of config internal to routing-engine... fixes things sometimes.

    ReplyDelete
  11. Also... Ivan, you should be using 10.4R7... seriously.

    ReplyDelete
  12. The family xxxx statement under the interface units is telling the router to listen for certain ethertypes...

    ReplyDelete
  13. Thank you: I like fanboys that help us newbies ;)

    ReplyDelete
  14. Not available in Junosphere. Either 10.3 or 11.4 (experimental and "somewhat" buggy)

    ReplyDelete
  15. No? Prefer the old crappy dinosaur way of IOS?

    ReplyDelete
  16. The Junos way makes a lot more sense. LDP is a protocol and should therefore be under protocols. Just like with OSPF - configuring OSPF information on the interface like newer-IOS makes no sense... it's not an interface configuration, its a protocol.

    ReplyDelete
  17. Feed the trolls? Are you saying I'm a troll for saying people should capitalize a trademark correctly?

    ReplyDelete
  18. Just wanted to point out that they don't listen for IPv4 by default either. You have to specify family inet for that to happen.

    ReplyDelete
  19. @will -Common misconception - that's just the display mode - you don't type or manage the curly braces - just type single-line commands in what soon becomes very familiar fashion with auto-complete, inline help, etc. System organizes for display (and is XML under the covers). Also the basis for our scripting capability.

    ReplyDelete
  20. Hi. Can anyone predict, that numbers of NextHop will be diffrent in "Box Uplinks" compare to "Butterfly Uplinks", with LDP+TE/FRR enabled on juniper boxes?

    ReplyDelete

You don't have to log in to post a comment, but please do provide your real name/URL. Anonymous comments might get deleted.

Ivan Pepelnjak, CCIE#1354, is the chief technology advisor for NIL Data Communications. He has been designing and implementing large-scale data communications networks as well as teaching and writing books about advanced technologies since 1990. See his full profile, contact him or follow @ioshints on Twitter.