Wednesday, November 26, 2014

EIGRP OTP - Looking closer part 1

So I'm going to break my closer look at EIGRP Over the Top into a couple smaller posts. Maybe I'll tie it together with a video when I'm done... maybe lol.


So today I thought I'd answer the most basic question of OTP, how the hell does it work?! In my previous post I covered a quick setup of OTP, and talked a little bit about the need to have connectivity between nodes. To reiterate that, the only way I could get OTP to work was to have a static route on each CE device pointing to my MPLS cloud for all other CEs (their MPLS facing interfaces only). That sounds confusing so here's a picture!


Now that you have a visual, all I did so my CEs could reach one another was add a static route 10.255.254.0 255.255.255.0 10.255.254.y where 'y' is the PE for each host. The reason I take time to point this out, again, is because OTP is advertised as an overlay so you don't have to do any dynamic routing with your provider. What it's not is an overlay where you don't have to do ANY routing with your provider, you CEs have to be able to be able to reach one another. Ok, now that I've touched on that fairly obvious topic let's get into some packet captures. What traffic is your provider going to see when you're running OTP?


EIGRP: Your provide CAN see EIGRP packets, again a lot of documentation talks about LISP encapsulation, and it's definitely there... just not for your actual EIGRP traffic. This is may or may not be of concern, but I wanted to throw it out there. I ran a wireshark capture on the PE facing CE3, and here you can clearly seeing that we're sending EIGRP packets without LISP encapsulation.



Also a quick note of on the topic of EIGRP packets, remember in the last post that your EIGRP RR clients need to have a maximum hop count specified for their static neighbor command? You don't remember that?! That's fine, here's what the syntax looks like:

router eigrp OTP
 !
 address-family ipv4 unicast autonomous-system 300
  !
  [...]
  neighbor 10.255.254.2 Ethernet0/0 remote 10 lisp-encap

I used '10' as the maximum hop count. Well, you can actually see that in the capture as CE3 -> CE1's TTL value in the IPv4 header. I know that's pretty basic, but I love seeing evidence that something is working as expected.




LISP: Ok so you might be wondering... where does LISP come into play? Well, let's look at the routing table on CE3, specifically at EIGRP learned routes.


CE3#show ip route eigrp | b ^Gateway
Gateway of last resort is not set
      192.168.1.0/32 is subnetted, 1 subnets
D        192.168.1.1 [90/3584640] via 10.255.254.2, 00:09:08, LISP0
      192.168.2.0/32 is subnetted, 1 subnets
D        192.168.2.2 [90/3584640] via 10.255.254.6, 00:09:08, LISP0
CE3#
There's your answer! Any traffic destine to those EIGRP learned prefixes, will be LISP encapsulated. Which brings up a fine point... what does LISP encapsulation actually look like? Well, Cisco's current documentation notes that user data will be encapsulated udp/4341 (ref:here). However I did not find this in practice. For a test I initiated a telnet from CE3 to the loopback address of CE1. Check out the wireshark.



So data is actually being encapsulated udp/4343. Just for fun, let's decode this capture as LISP. If you're not familiar with that function within wireshark (works on ALL kinds of protocols), what I'm doing is going to Analyze > Decode As...>LISP Data. 


Check it out! There's all my decoded traffic, as you can see I sent some pings before firing off my telnet session. I know what you're thinking... I can sense it even now. You're wondering if I can follow that TCP stream (that was encapsulated LISP) and read the telnet output aren't you? Yes dear friend, yes we can.







So that's it ladies and gents, part 1 of my closer look at OTP. Not sure what part 2 will be about... but I'm thinking I might combine OTP with GETVPN, then maybe look at VRF support. 

No comments:

Post a Comment