Routing - Tag - Fryguy's Blog

DMVPN and Routing Protocols – CDP

Fryguy — Sun, 07 Aug 2011 13:39:28 +0000

This post will build off my last one, DMVPN, and here we will discuss the routing protocol options as well as each of their configurations. This is more of a Why? What? Eh? type of post – hence the picture. Here I will show how to use CDP for a routing protocol – yes, CDP.

Right from the Cisco kool-aid website: On-Demand Routing (ODR) is an enhancement to Cisco Discovery Protocol (CDP), a protocol used to discover other Cisco devices on either broadcast or non-broadcast media. With the help of CDP, it is possible to find the device type, the IP address, the Cisco IOS® version running on the neighbor Cisco device, the capabilities of the neighbor device, and so on. In Cisco IOS software release 11.2, ODR was added to CDP to advertise the connected IP prefix of a stub router via CDP. This feature takes an extra five bytes for each network or subnet, four bytes for the IP address, and one byte to advertise the subnet mask along with the IP. ODR is able to carry Variable Length Subnet Mask (VLSM) information.

In order to get this lab to work I had to tweak a few configs on the routers, namely I had to remove the 0/0 route I had pointing to the ISP and make it a more specific – 150.0.0.0/8 pointing to the “ISP” router as the next hop. With ODR only a default route (0/0) is passed from the hub to the spokes, so no other default route can exist.

Quick note: When I am posting the configurations for the sites I will only notate the routing protocol additions. If you need information on DMVPN configuration, see my previous post.

DMVPN and Routing Protocols – EIGRP

Fryguy — Fri, 05 Aug 2011 12:12:03 +0000

This post will build off my last one, DMVPN, and here we will discuss the routing protocol options as well as each of their configurations. I will break out each protocol into a separate post in order to help keep things straight, putting them all together has the potential to get confusing (for both you and me!). The routing protocol options I will document are OSPF, RIPv2, EIGRP, and BGP and each has some unique features and quirks, so I will try and point them out where necessary.
One of the joys of EIGRP in a DMVPN network is Split-Horizon. Just a quick refresher on Split Horizon – it is the rule that prohibits a router from advertising a route through an interface that the router itself uses to reach the destination. This is done in order to prevent loops in the network, but with DMVPN we need to disable this feature via the no split-horizon EIGRP AS# command.
Quick note: When I am posting the configurations for the sites I will only notate the routing protocol additions. If you need information on DMVPN configuration, see my previous post.
Router/Switch Output
Commands
Notes
First up, the DMVPN hub:
First thing we should do is create a loopback interface and address so we have something to see and ping.
Rack1DMVPN(config)# int l0
Rack1DMVPN(config-if)# ip address 100.100.100.100 255.255.255.255

DMVPN and Routing Protocols – OSPF

Fryguy — Thu, 04 Aug 2011 13:43:09 +0000

This post will build off my last one, DMVPN, and here we will discuss the routing protocol options as well as each of their configurations. I will break out each protocol into a separate post in order to help keep things straight, putting them all together has the potential to get confusing (for both you and me!). The routing protocol options I will document are OSPF, RIPv2, EIGRP, and BGP and each has some unique features and quirks, so I will try and point them out where necessary.
Quick note: When I am posting the configurations for the sites I will only notate the routing protocol additions. If you need information on DMVPN configuration, see my previous post.
Router/Switch Output
Commands
Notes
OSPF
What one needs to keep in mind here is that mGRE is a non-broadcast multi-access network (NBMA) how OSPF works. In order for OSPF to operate properly, the DMVPN hub router must be the OSPF DR and all the other routers should not be allowed to be a DR/BDR. The only way you could have a DR/BDR design if this was a multi-hub DMVPN network – and that is beyond the scope of this post (due to hardware limitation in my lab). Also, the mGRE tunnel on the hub router must be set to a OSPF broadcast network via the ip ospf network broadcast command.
So, let’s get on with the configuration – DMVPN Hub first.

LISP – Locator Identifier Separation Protocol (Say what?)

Fryguy — Thu, 07 Apr 2011 14:57:38 +0000

Recently I have been working on a crazy busy project at work as well as preparing for the CCIE SP lab (did not pass). Well now that is all behind me so I figured I would take some personal time and play with some technology that I have read about, talked about, and even sat through presentations at Cisco Live (aka Networkers) in the past. What is this technology that has me so interested you might ask. Well, its LISP – Locator Identifier Separation Protocol (ietf draft can be found here – http://tools.ietf.org/pdf/draft-ietf-lisp-11.pdf). The next question you may have is why does this interest me? To be honest, I have no idea – just thought it was a nifty idea.
So, what is LISP? The easiest way to explain it is to give you a common analogy that we all understand, DNS. When a user wants to access a website – in this case – blog.fryguy.net, they send a DNS query to the configured DNS server. The DNS servers then resolves that DNS name to an IP address – 76.74.254.123 – and sends that back to the client. The client web application then makes a connection to the web server and retrieves the website.

Well, in LISP a very similar thing happens. If a router needs to send a packet to 76.74.254.123, and that route is not in the local routing table – it sends a query to the LISP Map Resolver. The LISP Map Resolver then looks at its database and tells the router that the network can be reached via 4.71.170.2. The router then sends a LISP encapsulated packet to 4.71.170.2 to be then forwarded onto its ultimate destination.

That is a very simple explanation on how it works, and one that I hope most networking folks should be able to understand. Now lets take it a step further – and think about moving a device around, yet keeping the same IP address (think vmotion). If you are registering a device location with a server, you can then move that device around and the mapping server will be able to redirect you to the correct site. There are other things that LISP can do, but I will save the IPv6 one for a future post.
We have host 100.100.100.100/32, called an EID – Endpoint Identifier – that is sitting behind Router A. Router A will register that network, or host in this case, with the LISP Map Server. It will say to get to the EID prefix of 100.100.100.100/32, send the packet to Router A. We also have another EID at 200.200.200.200/32 that is sitting behind Router B. Router B will also register with the LISP Map Server that host 200.200.200.200/32 is reachable via Router B. So if 200.200.200.200/32 wants to talk to 100.100.100.100/32, it will send the packet to Router B – Router B will then ask the LISP Mapping Server how to get to 100.100.100.100/32. The LISP Map server will respond – to get to 100.100.100.100/32, send the packet to Router A. Router B would then in turn send the packet to Router A, who will then process the packet and forward it onto 100.100.100.100/32.
Now what happens if we move 100.100.100.100/32 to Site C? In a normal network, we would have to change the IP address of the host to a network that is reachable via Router C. You typically cannot advertise the same network from two sites and expect things to work correctly. But with LISP, you can move the host around and not change the IP address. Why? Well, the Mapping server is what tells the routers who want to talk to 100.100.100.100/32 how to get to the host.
So lets move 100.100.100.100/32 to a location in Site-C behind Router C. Router C would then register with the LISP Map server that 100.100.100.100/32 is now reachable via Router C. The next time that 200.200.200.200/32 goes to talk to 100.100.100.100/32, Router B will query the LISP Map Server who will then tell it, to get to 100.100.100.100/32, send the packet to Router C for processing.

Another use case could be with a multi-homed site, like the picture below. Typically with BGP you can only “recommend” an ingress point into your network, you have no way of guaranteeing the traffic will only flow into Router B from your upstream ISP. Sure, you can prepend AS numbers; tweak the mutli-exit discriminator (MED), etc – but it is only a suggestion to your upstream ISP. So what can LISP do for us here? Easy, you can set a priority to the mapping on the LISP server. You can say that Router A has a higher priority for ingress traffic then Router B. The LISP server will then return the path with the lowest Priority listed is the preferred route. This will help to make sure that the traffic is flowing inbound the way that you want it to.

So lets list out some of the components of a LISP environment: