Tag Archives: labbing

When is a Connected Route Not Used?

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?

a. The router reboots
b. The network reboots
c. That’s um-possible
d. None of the above

Continue reading When is a Connected Route Not Used?

Random Notes From My Third CPOC

I was lucky enough (volunteering for very challenging work is luck, right? 😁) to finish my third tour through Cisco CPOC last wcpoceek. CPOC is Cisco’s Customer Proof of Concept facility where customer’s can bring their network design, build it in Cisco’s lab, and beat the hell out of it. CPOC has tons of network and compute gear, all the right testing tools and processes, and excellent work areas that cater to collaborative work and information sharing. It’s also staffed by very senior and experienced engineers.

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.

Continue reading Random Notes From My Third CPOC

The Correct Mask for a PE’s Loopback0

As I’ve written about previously (The Importance of BGP NEXT_HOP in L3VPNs), the BGP NEXT_HOP attribute is key to ensuring end to end connectivity in an MPLS L3VPN. In the other article, I examine the different forwarding behavior of the network based on which of the egress PE’s IP addresses is used as the NEXT_HOP. In this article I’ll look at the subnet mask that’s associated with the NEXT_HOP and the differences in forwarding behavior when the mask is configured to different values.

There is a lot of (mis-)information on the web stating that the PE’s loopback address — which, as I explain in the previous article, should always be used as the NEXT_HOP — must have a /32 mask. This is not exactly true. I think this is an example of some information that has been passed around incorrectly, and without proper context, and is now taken as a rule. I’ll explain more about this further on in the article.

Continue reading The Correct Mask for a PE’s Loopback0

The Importance of BGP NEXT_HOP in L3VPNs

In an MPLS network with L3VPNs, it’s very easy for the NEXT_HOP attribute of a VPN route to look absolutely correct but be very wrong at the same time. In a vanilla IP network, the NEXT_HOP can point to any IP address that gets the packets moving in the right direction towards the ultimate destination. In an MPLS network, the NEXT_HOP must get the packets moving in the right direction but it must also point to the exact right address in order for traffic to successfully reach the destination.

Continue reading The Importance of BGP NEXT_HOP in L3VPNs

MPLS “No Label” vs “Pop Label”

I like MPLS. And I don’t necessarily mean as a solution to solve a problem, but as something to configure in the lab. It’s fun to build things that do something when you’re done. Setting up OSPF or EIGRP and being able to traceroute across routers is meh. But configuring MPLS with all the associated technologies — an IGP, LDP, MP-BGP, — and then getting all of them working in unison… when you get the traceroute working, it’s rewarding.

Here’s something to keep an eye out for when you’re troubleshooting MPLS: An LFIB entry (that is, the Label Forwarding Information Base) that states “No Label” versus one that states “Pop Label”. These mean very different things and can be the difference between a working Label Switched Path (LSP) and a non-working LSP. Continue reading MPLS “No Label” vs “Pop Label”

Lab: iBGP and OSPF Traffic Engineering

Click to enlarge
Click to enlarge

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? Continue reading Lab: iBGP and OSPF Traffic Engineering