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 224.0.0.2. 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 (224.0.0.2) 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 :

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.

fig2

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 :

fig3

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 :

fig4

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 :

fig5

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

fig6

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

fig7

GET VPN TBAR and EEM

I ran into an interesting problem a few months back, but haven’t had a chance to blog about it.

Working with a Cisco GET VPN environment we have deployed, we were notified by our ISP that they would be performing some “circuit grooming”. That phrase always makes me cringe. The usual “this shouldn’t effect your connectivity at all” emails came and went.

Needless to say, the maintenance was performed and all of a sudden all of the GM routers were throwing errors pertaining to anti-replay. And as we all know with anti-replay, that’s a bad thing. That means the tunnels are toast. GET VPN uses a psudo-timer solution to protect against replay attacks, called Time Based Anti-Replay(TBAR). This psuedo-time is handled by the Key Server within the GDOI.

Long story short, no traffic was passing. Entering the “clear crypto gdoi” command took care of this. We did some shallow research and found that there was a particular bug for the version of code that we were running and patched accordingly. A few weeks went by and the problem presented itself again. The same “clear crypto gdoi” command, again, took care of the problem. Checking the GDOI psuedo-time that was negotiated, I noticed a sizable delta between the server time and the time that the branch router was reporting in at.

This gets me to the point of my story. Cisco’s Embedded Event Manager(EEM).

EEM is a fantastic subsystem built into IOS. It allows you to build an “applet” that can respond to certain criteria that you can define as triggers.

Being new to EEM, I wrote a less than complex script to parse the syslog buffer of the remote router, looking for a particular replay error, and issue the ‘clear crypto GDOI’ command.

Something along the lines of such :

event manager applet GDOI_TBAR_RESET
event syslog msg "%CRYPTO-4-PKT_REPLAY_ERR"
action 1.0 cli command "clear crypto gdoi" pattern "confirm"
action 2.0 cli command "yes"
action 3.0 syslog msg "Clear Crypto GDOI command issued due to Anti-Replay Error!"

This doesn’t being to scratch the surface of EEM, but it still taught me a little bit about the structure of it and how it can function. I plan to make an update to it in the near future once I have the time to track down the OID that issues that particular error within IOS.

If anyone has any interesting stories / uses for EEM, feel free to leave a comment below. I’m always up for tips and tricks!

Ubuntu 12.04 and VMWare Workstation 8.0.3

Upon installing Ubuntu 12.04 LTS and attempting to launch VMWare Workstation 8.0.3 I was meet with the following error.

Using my googling skills I was able to find that there is indeed a patch out for VMWare Workstation 8.0.2 which can be found here :

http://communities.vmware.com/message/2030083#2030083

The original patch was made to apply to workstation 8.0.2, but modifying the following settings in the ‘patch-modules_3.2.0.sh’ shell script included in the patch tar will allow us to run this patch on an 8.0.3 installation :

fpatch=vmware3.2.0.patch
vmreqver=8.0.2    <——————- Modify this to 8.0.3
plreqver=4.0.2
 

This will allow the patch to be applied to the installation of workstation 8.0.3 and allow it to function correctly on Ubuntu again.

Have fun and happy virtualizing!

IPv6 Address Formatting

So, I’ve come to the in depth IPv6 studies for my CCNP – I figure I’d take some notes on my blog to help others out who take this path.

I know, I should’ve gotten gotten some exposure to this on my CCNA studies, and I did, but not enough to totally absorb it.

OK, Take a deep breath. I know some people, including myself, were a little intimidated by this – but it CAN be done!

So, let get started :

With IPv6, the standard IPv4 32-bit addressing scheme goes out the window. Now a 128-bit addressing scheme is adopted.

IPv4 provided a total of 4,294,967,296 addresses. Ready for this one? IPv6 now provides this many addresses :

340,282,366,920,938,463,463,374,607,431,768,211,456  –  340 Undecillion addresses.

I’ve read somewhere that this is actually enough addresses to give every atom on the earth’s surface an address, and then 100 Earth’s there-after. You can check me on that, but I am writing this from memory. Seems like we will NEVER run out eh? Well, this brings up one of my favorite XKCD comics – http://xkcd.com/865/

To prevent confusion and over/under/random-use and to help with the public allocations, the RFC states that we will leave 85% of the IPv6 spectrum unused until the standard is revised. When that will be? I don’t think anyone knows, but there was a time when we though IPv4 would provide enough addresses for everything….

As you can see, this would become a bit less than ideal to try and manage. That being said, the powers at be decided to divide the addresses into 8 groups of 4 hexadecimal characters each. The IP address in v6 land no longer consists of 4 octects of 8 bits. Now it consists of 8 groups of 16 bits per character and since it is hexadecimal the bits can be set to values ranging from 0 through F – and if you do the math, this comes out to be 2^128’s combinations of characters. Which adds up to that crazy number listed above.

An example being :

2001:0050:0000:0000:0000:0AB4:1E2B:98AA  –  A far cry from 10.1.1.1, I would say.

Again, to make this all a bit more comprehensive and manageable, the powers at be allowed us some lee-way on how we can write and handle the addresses. You are able to drop the groups of consecutive zero’s. But, here’s the kicker, this can only be done ONCE per address.

If we were to apply this to the address listed above, it would become :

2001:0050::0AB4:1E2B:98AA

Now, still a bit unrly to have to try and type into a cmd prompt to ping something, so there is another rule we can apply. We are allowed to drop leading zeros within the address. Again, if we were to apply this to the address above, it would become :

2001:50::AB4:1E2B:98AA

This brings it down to something, though not exactly EASY to remember or type – but a hell of a lot more manageable than the first number we started with.

That sums up the formatting of the addresses, and is a very high level overview – but I just wanted to point out the 2 rules that can be applied to “short-handing” the address to make it a little less stressful on your brain. As I know I needed.

As always, thoughts and insights are greatly appreciated.

Until next time.