LDP Extended Discovery

Label Distribution Protocol (LDP) is a protocol used within MPLS for exchanging label bindings with other MPLS routers within the AS. These labels are then used to negotiate LSP’s throughout the network.

LDP uses an adjacency discovery technique by sending an LDP discovery packet, UDP 646, to the all-routers multicast address of Once an adjacency is discovered, one of the LSRs will take the active roll and the other takes the passive roll. The passive LSR waiting for the active to initiate the connection. This is done via the comparison of unsigned integers but I’m not going to get into the granulars behind that, you’re welcome to read RFC3036 if you’re interested.

If the routers are not directly connected, as with TE tunnels sometimes spanning discontiguous LSRs within the MPLS domain, there is the ability to utilize the LDP Extended Discovery mechanism that is defined within RFC3036. This will allow the LSR to produce a Targeted Hello message toward a defined target LSR. Instead of using the all-routers ( address, the router will send a unicast discovery packet to the target LSR.

As the RFC states, the basic LDP discovery process is symmetrical, with both LSRs discovering each other and negotiating their role of in the establishment of the LDP session. With LDP Extended Discovery, the process is asymmetrical with one LSR initiating the connection and the targeted LSR deciding whether or not it wants to respond or ignore the request to establish an LDP session. Should the targeted LSR decide it wants to respond, it will do so by sending periodic Targeted Hellos in return.

We’ll start with the following topology :


Routers PE1 and PE2 are not directly connected, therefore they will not establish an LDP adjacency, as seen here in the show mpls ldp neighbors output from PE1.


PE1 has successfully established LDP adjacencies with P1 and P2, but not with PE2. If we were to want to establish LDP adjacency with these two LSRs, the following process would have to be followed :

First, we would need to define a targeted neighbor within the LDP process on one of the PE routers. For this example, we’ll go ahead and define PE1 as the active LSR by issuing the mpls ldp neighbor neighbor-ID targeted ldp command :


By enabling the debug mpls ldp targeted-neighbors, we can see the LDP process kick up and start to attempt to discovery the defined target LSR, on PE1 :


Once PE1 has been setup to target PE2, we can then configure PE2 to accept targeted LDP messages by issuing the mpls ldp discovery targeted-hello accept command :


Once PE2 has been configured to respond to the targeted hellos it is receiving, we can see the adjacency establish through the same debugs :


We can also verify the adjacency by issuing the show mpls ldp neighbor command again – and here we see that is now listed as a valid adjacency :


Service Provider Community

Earlier today I had asked on twitter if anyone knew of any SP specific podcasts, or communities. I was meet with a fair amount of information pertaining to the fact that there isn’t any such defined community out there, or at least it isn’t main stream enough for me to find it.

Speaking with a few people on the twitters, I was pointed to a few mailing lists to subscribe to for industry happenings from the Service Provider world. I’ll make this quick and list them below, and credit the individuals who provided them.

In no particular order these are the individuals that helped provide me information to compile this list :

Marko Milivojevic (@icemarkom)

Jeff Pazahanick (@jeffpaz)

Darren O’Connor (@mellowdrifter)

Scott (@visitorlnx)

Nick Buraglio (@buraglio)

And the list of mailing lists to subscribe to are as follows :

J-NSP (Juniper for Network Service Providers) – https://puck.nether.net/mailman/options/juniper-nsp/

C-NSP (Cisco for Network Service Providers) – http://puck.nether.net/mailman/listinfo/cisco-nsp

F-NFP (Foundry for Network Service Providers) – http://puck.nether.net/mailman/listinfo/foundry-nsp

Cisco-BBA (Cisco Broadband Aggregation) – http://puck.nether.net/mailman/listinfo/cisco-bba

North American Network Operator’s Group (NANOG) – http://mailman.nanog.org/mailman/listinfo/nanog

This is, albeit, a smaller list – but sometimes not drinking from a fire hose is nice, also.

Along with the mailing lists – I had asked if there were any podcasts dedicated to the SP industry. Ethan Banks (@ecbanks) of the Packet Pushers podcast pointed me in the direction of a newer podcast, The Class-C Block from CJ Infantino (@cjinfantino) and Matt Stone (@bigmstone) in which they’ve discussed some provider level technologies in the podcasts that they’ve recorded. I’ve listened to their second episode in which they discuss MPLS with Ivan Pepelnjak (@ioshints) as a guest. So far, I like what I’ve heard and I look forward to their further productions.

All in all, I’m a little surprised at the lack of a Service Provider level community as they’re really what makes the Internet world go round, but I look forward to the possibility of contributing to growing something along those lines.

If anyone else knows of any other popular mailing lists to follow, please feel free to leave a comment with the information and I will incorporate it into the post.

Edit : I had accidentally listed the Cisco-Broadband Aggregation link under the Cisco-Network Service Providers link. This is fixed and the Cisco-BBA link has been added to the list. Sorry for the confusion!

MPLS TTL Propagation

Working through my MPLS labs for my IE studies I came across this little tidbit of information. I like to keep track of these one liners(or generally small sections of information) in all of the documentation that I read, because they seem to be incredibly helpful once committed to memory.

This particular nugget has to do with TTL propagation within an MPLS cloud, from a provider’s perspective. I trust anyone with enough interest in reading this post has experience with the TTL field and how the traceroute command utilizes this header information within a network.

We’ll start with how MPLS handles TTL propagation for the traffic being forwarded within the MPLS cloud. MPLS needs a loop prevention mechanism as does any other forwarding protocol. And instead of having to modify the IP header of every packet that passes through an interface on an LSR within the cloud, it copies the IP packet’s TTL header information into a new label being pushed onto the IP packet as it enters the MPLS cloud. Thus preventing having to touch the IP header information on the ingress packets.

As the packet traverses the MPLS cloud, each LSR will decrement the TTL within the MPLS header, just like in a typical IP network. As the packet reaches the egress E-LSR, the E-LSR will pop the label on that packet, subtract the cost of one interface(the egress interface) from the current TTL value, and then apply that value to the header of the IP packet that will be forwarded on.

That being said, Service Providers are usually providing some sort of L3 WAN services, and their customers sit outside of their MPLS network. The result of the traceroute command with MPLS’s default configuration allows for customers to see every LSP in the path that one of their packets traverses. This can cause some headache for them, as they don’t need to know what the provider’s topology consists of, but it also poses potential security issues for the SP themselves.

The output below shows what it looks like for a customer to run the traceroute command with the default TTL copy behavior of MPLS.

1 44 msec 12 msec 24 msec

2 [MPLS: Labels 16/16 Exp 0] 80 msec 496 msec 88 msec

3 [MPLS: Label 16 Exp 0] 48 msec 60 msec 48 msec

4 56 msec 60 msec *

As you can see, the LSP’s are present in the output. Again, it may be that the SP doesn’t want to customer to have that type of insight into their network, or the customer doesn’t want to see the LSP’s while attempting to troubleshoot issues.

Thankfully, Cisco grants us the ability to surpress the TTL propagation functions of traffic within the MPLS network. We can use the no mpls ip propagate-ttl [local forwaded] command to surpress the copying of the TTL from the IP packet’s header. When this command is issued, the ingress E-LSR will assign a generic TTL value of 255 to the label, instead of copying the IP packet’s current TTL.

As a result, the entire MPLS network will look as though it is just a single hop to the customer. As seen below :

1 28 msec 36 msec 16 msec

2 108 msec 108 msec *

Now, let’s step back to the command again for a minute. I referenced the options at the end of the command to local or forwarded. What this means is, is that the TTL propagation can be disabled either from ingress customer traffic, or locally originated traffic from the LSR’s within the MPLS cloud. The local option references traffic originated by the LSR itself. Such as when a SP engineer logs into a router and issues the traceroute command, this would allow the SP engineer insight into the LSR’s within the MPLS cloud. Whereas the forwarded option pertains to traffic that is originated external to the MPLS cloud, usually within the customer sites.

Extra LSA from change in DR

So, I was intrigued by Ivan’s post on Extra LSAs within the LSDB here : http://blog.ioshints.info/2012/12/change-in-ospf-designated-router.html

And I decided to do a little digging of my own.

I have confirmed Ivan’s work through his blog. Essentially, when issuing the “ip ospf priority 0” command to allow for a graceful shutdown of a DR on a segment, it is leaving an extra LSA in the LSDB of other routers in the segment.

It seems, as is described in the comments on Ivan’s blog, the extra LSA is kept within the LSDB for 60 seconds. Once that 60 seconds passes, the LSA is MaxAged out. As seen below.


*Jan 2 15:07:23.023: OSPF: Reset old DR on FastEthernet0/0
*Jan 2 15:07:23.055: OSPF: Rcv LS UPD from on FastEthernet0/0 length 76 LSA count 1
*Jan 2 15:07:23.851: OSPF: service_maxage: Trying to delete MAXAGE LSA

It would seem that, on what was the old BDR, now the DR – it is remembering the old DR on the segment that the interface is connected to. And not until this old DR is reset on the interface does it MaxAge the LSA. You can see below the debug output where it remembers the old DR :


*Jan 2 15:04:17.019: OSPF: Remember old DR (id)

As I’ve stated in Ivan’s blog, in a comment, I’ve done some light digging as to why this is happening, but I can’t think of a timer, or combination of timers, that is causing this to happen so methodically.

Anyone have any insight? Otherwise, I’ll keep digging until I find something.

Update :

After more digging it would seem there is a 180 second delay between the forced step down of the DR and the MaxAging of the corresponding LSA. Not 60 seconds as I’d previously witnessed.