Preface: The EIGRP routing protocol just got more interesting with the addition of Cisco’s Over the Top feature. Here’s how it works plus its pros and cons.
Cisco Systems has been hoisting the EIGRP (Enhanced Interior Gateway Routing Protocol- with all the hoopla surrounding software-defined networking, overlays and network virtualization) flag up high of late. And yet Cisco is clearly committed to EIGRP.First of all, much of EIGRP has moved from proprietary status to open. Open EIGRP was announced earlier this year, when Cisco released significant portions of the EIGRP specification to the open source community in the form of an IETF draft, which demonstrates Cisco’s desire to see EIGRP used even more broadly in the industry. With the widespread acceptance of the OSPF routing protocol, some might wonder what the point is, but EIGRP fans can attest to its flexibility and scalability–EIGRP really stands up.
Cisco is giving EIGRP users an interesting feature, which was announced in June at Cisco Live. EIGRP Over the Top (OTP) allows EIGRP routers to peer across a service provider infrastructure without the SP’s involvement. In fact, with OTP, the provider won’t see customer routes at all. EIGRP OTP acts as a provider-independent overlay that transports customer data between the customer’s routers.
To the customer, the EIGRP domain is contiguous. A customer’s EIGRP router sits at the edge of the provider cloud and peers with another EIGRP router a different location across the cloud. Learned routes feature a next hop of the customer router–not the provider. Good news for service providers is that customers can deploy EIGRP OTP with their involvement.
OTP is a genuinely new feature that Cisco has created for EIGRP, so let’s peek under the hood at the key elements:
•Neighbors are discovered statically. There’s no auto-discovery mechanism here. OTP does not require a mesh of peering relationships to support a full mesh topology.
• An OTP mesh scales by use of a route reflector (RR). When designing the EIGRP OTP overlay, a customer selects a router to be a RR. When additional customer routers are added to the OTP overlay, EIGRP is configured on that new router to peer with the RR. The RR takes route advertisements in, and reflects them out to all other EIGRP customer routers in the OTP overlay. This means that the RR is not going to be the hub of a hub and spoke forwarding topology. Instead, a full forwarding mesh is formed.
For example, let’s say we’ve got three routers: R1, R2 and R3. R1 is the RR. R1 is peered with R2 and R3. When R2 advertises a route, let’s say 10.2.2.0/24, to R1, R1 reflects 10.2.2.0/24 to R3, preserving R2 as the next hop of that route. When R3 needs to talk to 10.2.2.0/24, it’ll connect directly to R2, and not through R1, which reflected the route to it.
•Metrics are preserved across the service provider cloud. Therefore with OTP, a customer ends up with a contiguous EIGRP domain across the SP cloud. That eliminates a common scenario of isolated EIGRP domains at each customer office being redistributed into the SP cloud, and then redistributed again from the SP cloud into remote office EIGRP domains. OTP also eliminates the scenario of multipoint GRE tunnels (for example, with DMVPN and NHRP) being nailed up as a manually created overlay that runs EIGRP across it. An OTP configuration is comparatively simple to code in IOS.
You may ask how the EIGRP customer Cisco routers can push traffic for remote subnets across the SP cloud, if the customer routers are not advertising those subnets to the SP? The answer is that traffic between the customer EIGRP routers is encapsulated in LISP packets. The SP will know this by virtue of the directly connected routes used to uplink the customer routers to the SP cloud; therefore, all the SP needs to know is how to get from customer router to customer router to carry the LISP packets flowing between them.
It’s worth pointing out that LISP is only used as a data plane transport; Cisco is not saying that EIGRP OTP has a dependency on LISP. Instead, Cisco just happens to be using LISP as the encapsulation format to smuggle traffic across the SP cloud between customer routers.
A consideration for secure environments is data privacy across the SP cloud, and LISP has no native encryption function. However, OTP can be configured to work with GET VPN to encrypt the LISP traffic flowing between the customer EIGRP routers.My first thought here is that OTP simply gives network designers a new, useful tool in their toolbox. LISP introduces packet overhead, therefore, the packet maximum transmission unit (MTU) size must be considered. However, as the interfaces carrying the encapsulated traffic are SP-facing, this might not be a huge concern. In reality, it could be a bit of a challenge to accomplish this with your service provider.
Alternatively, a designer might need to implement path MTU discovery or rewrite TCP maximum segment size (MSS) to avoid fragmentation issues at the customer router sitting at the edge of the SP cloud.
Another concern that popped in my head is that the EIGRP OTP route reflector appears to be a single point of failure, but documentation is scant on OTP thus far so I don’t know for sure. As the RR is such a key component of the OTP design as well as a critical component for scaling the solution, my gut feeling is that there’s probably a mechanism for RR redundancy. I just didn’t happen to see any evidence of such a thing in the material I reviewed.
Besides, to scale to very high throughput requirements, encapsulation and decapsulation operations should be performed in hardware. Customers evaluating EIGRP OTP will need to consider whether the combination of hardware and software they want to run OTP on will support the data rates they require. It’s not yet clear to me which of Cisco’s myriad platforms will eventually support OTP, and of those platforms, which of them could support LISP encapsulation in hardware.
That’s not to say that OTP is a non-starter if the encapsulation operation is punted to the device CPU on a given platform. If there’s enough CPU in the device to handle the required throughput without impacting the device negatively, then that’s a valid solution.
Cisco is shipping OTP now on IOS XE on the ASR 1K platform. In November, Cisco expects to ship OTP on classic IOS in the Catalyst 3K, 4K and 6K products. I have no information on shipping OTP for the ISR router platform, but my best guess is that it will be a Cisco priority, as many customers position the ISR platform as a WAN edge router.
Speculating again, I suspect adding this feature to NX-OS is a somewhat lower priority for Cisco, as Nexus hardware is less likely to be positioned at the WAN edge. However, there are use cases I can conceive of for OTP on Nexus, and interestingly, there’s at least one Nexus 7000 series line card that can handle LISP in hardware.
The original material is from:
More Cisco news and info. of Cisco trends at: