Consider for a moment that you have an application running on a server that needs to push some data out to multiple consumers and that every consumer needs the same copy of the data at the same time. The canonical example is live video. Live audio and stock market data are also common examples. At the re:Invent conference in 2019, AWS announced support for multicast routing in AWS Virtual Private Cloud (VPC). This blog post will provide a walkthrough of configuring and verifying multicast routing in a VPC.
Good stuff - LPM rule can be a useful tool if you want to manipulate paths without mucking with metrics, esp if using multiple protocols— Matt Love (@thatmattlove) July 13, 2017
What Matt is saying is that longest prefix match (LPM) is a mechanism that can be used to steer traffic around the network in order to meet a technical or business need. This type of traffic steering is called traffic engineering (TE).
I ran into this situation on a recent project and thought it would make an excellent question on an exam. It could be worded something like this:
What is the behavior of a router or Layer 3 switch when a dynamic route is learned that partially overlaps with a directly connected network?
- The router reboots
- The network reboots
- That's um-possible
- None of the above
It's funny, in my experience, OSPF is the most widely used interior gateway protocol because it "just works" and it's an IETF standard which means it inter-ops between different vendors and platforms. However, if you really start to look at how OSPF works, you realize it's actually a highly complex protocol. So on the one hand you get a protocol that likely works across your whole environment, regardless of vendor/platform, but on the other you're implementing a lot of complexity in your control plane which may not be intuitive to troubleshoot.
This post isn't a judgement about OSPF or link-state protocols in general. Instead it will detail five functional aspects of OSPF in order to reveal-at least in part-how this protocol works, and indirectly, some of the complexity lying under the hood.
So... I'm a little embarrased to admit this but I only very recently found out that there are significant differences in how Virtual Port Channels (vPC) behave on the Nexus 5k vs the Nexus 7k when it comes to forming routing adjacencies over the vPC.
I've read the vPC Best Practice whitepaper and have often referred others to it and also referred back to it myself from time to time. What I failed to realize is that I should've been taking the title of this paper more literally: it is 100% specific to the Nexus 7k. The behaviors the paper describes, particularly around the data plane loop prevention protections for packets crossing the vPC peer-link, are specific to the n7k and are not necessarily repeated on the n5k.
NSF and GR are two features in Layer 3 network elements (NEs) that allows two adjacent elements to work together when one of them undergoes a control plane switchover or control plane restart.
The benefit is that when a control plane switchover/restart occurs, the impact to network traffic is kept to a minimum and in most cases, to zero.
I know it's cliche and I know I'm biased because I have an @cisco.com email address, but I've truthfully never seen anything like CPOC before. And the customer's I've worked with at CPOC haven't either. It's extremely gratifying to take something you built "on paper" and prove that it works; to take it to the next level and work those final kinks out that the paper design just didn't account for.
If you want more information about CPOC, get in touch with me or leave a comment below. Or ask your Cisco SE (and if they don't know, have them get in touch with me).
Anyways, on to the point of this post. When I was building the topology for the customer, I kept notes about random things I ran into that I wanted to remember later or those "oh duh!" moments that I probably should've known the answer to but had forgotten or overlooked at the time. This post is just a tidy-up of those notes, in no particular order.
In this post I'm going to look at the characteristics of OSPF and EIGRP when used in a Dynamic Multipoint VPN (DMVPN). I will do my best not to play favorites and instead stick to the facts (yes, I do have a preference :-). To that end I will back everything up with data from my lab. The focus areas of the comparison will be:
- Scalability of the hub router's control plane
- Overall control plane stability
- Traffic engineering
This post won't go into any background on how DMVPN works. If you're not yet familiar with DMVPN, I recommend watching these introductory videos by Brian McGahan. This post also does not do a deep dive on OSPF or EIGRP. I'm making the assumption that you're already familiar with the different LSA types in OSPF and general functions of EIGRP.
After reading this post you should be able to describe the pros and cons of OSPF and EIGRP in the three areas listed above and incorporate this knowlege into a DMVPN design.
Mohamed Anwar asked the following question on my post "4 Types of Port Channels and When They're Used".
"I need a clarification, where if a member link fails, what will happen to the traffic already sent over that link ? Is there any mechanism to notify the upper layer about the loss and ask it to resend ? How this link failure will be handled for data traffic and control traffic ?"
— Mohamed Anwar
I think his questions are really important because he hits on two really key aspects of a failure event: what happens in the data plane and what happens in the control plane.
A network designer needs to bear both of these aspects in mind as part of their design. Overlooking either aspect will almost always open the network up to additional risk.
I think it's well understood that port channels add resiliency in the data plane (I cover some of that in the previous article). What may not be well understood is that port channels also contribute to a stable control plane! I'll talk about that below. I'll also address Mohamed's question about what happens to traffic on the failed link.
Normally for these FFF articles I've taken to writing about new protocols as a way of introducing others to it and also edumacating myself about it. For this post I get all nostalgic and look at good old Enhanced Interior Gateway Routing Protocol (EIGRP).
Here's the scenario: An enterprise network with an MPLS core and two branch locations connected to their own Provider Edge (PE) router. In addition to the MPLS link, the PEs are also connected via a DMVPN tunnel. The PEs are peering via iBGP (of course) and are also OSPF neighbors on the DMVPN. Both Customer Edge (CE) routers at the branch are OSPF neighbors with their local PE.
Task: Use the high speed MPLS network as the primary path between the CE routers and only use the DMVPN network if the MPLS network becomes unavailable.
Question: Is the solution as simple as adjusting the Admin Distance (AD) so that the iBGP routes are more preferred?
In Cisco IOS packets are forwarded through the router (or Layer 3 switch) by Cisco Express Forwarding (CEF). A data structure called the CEF table contains a list of known IP prefixes and the outgoing interface that packets should be put on in order to get them onwards to their destination. That's well and good. But how do the IP prefixes make it into the CEF table? To answer that question you have to work backwards and understand the order of operations that IOS goes through in order for a prefix to make it into the CEF table.