Showing posts with label OSPF. Show all posts
Showing posts with label OSPF. Show all posts

Unnumbered OSPF Interfaces in Quagga (and Cumulus)

Carlos Mendioroz sent me an interesting question about unnumbered interfaces in Cumulus Linux and some of the claims they make in their documentation.

TL&DR: Finally someone got it! Kudos for realizing how to use an ancient trick to make data center fabrics easier to deploy (and, BTW, the claims are exaggerated).

Combining DMVPN with Existing MPLS/VPN Network

One of the Expert Express sessions focused on an MPLS/VPN-based WAN network using OSPF as the routing protocol. The customer wanted to add DMVPN-based backup links and planned to retain OSPF as the routing protocol. Not surprisingly, the initial design had all sorts of unexpectedly complex kludges (see the case study for more details).

Having a really smart engineer on the other end of the WebEx call, I had to ask a single question: “Why don’t you use BGP everywhere” and after a short pause got back the expected reply “wow ... now it all makes sense.”

Routing Protocols on NSX Edge Services Router

VMware gave me early access to NSX hands-on lab a few days prior to VMworld 2013. The lab was meant to demonstrate the basics of NSX, from VXLAN encapsulation to cross-subnet flooding, but I quickly veered off the beaten path and started playing with routing protocols in NSX Edge appliances.

Implementing Control-Plane Protocols with OpenFlow

The true OpenFlow zealots would love you to believe that you can drop whatever you’ve been doing before and replace it with a clean-slate solution using dumbest (and cheapest) possible switches and OpenFlow controllers.

In real world, your shiny new network has to communicate with the outside world … or you could take the approach most controller vendors did, decide to pretend STP is irrelevant, and ask people to configure static LAGs because you’re also not supporting LACP.

Inter-Process OSPF Route Selection Rules

Nicolas Michel left an interesting comment (quoting Cisco’s documentation) on my OSPF Route Selection Rules blog post:

… The OSPF route selection rule is that intra-area routes are preferred over inter-area routes, which are preferred over external routes. However, this rule should apply to routes learned via the same process …

Let’s see what’s going on behind the scenes.

WAN Routing in Data Centers with Layer-2 DCI

A while ago I got an interesting question:

Let's say that due to circumstances outside of your control, you must have stretched data center subnets... What is the best method to get these subnets into OSPF? Should they share a common area at each data center or should each data center utilize a separate area for the same subnet?

Assuming someone hasn’t sprinkled the application willy-nilly across the two data centers, it’s best if the data center edge routers advertise subnets used by the applications as type-2 external routes, ensuring one data center is always the primary entry point for a specific subnet. Getting the same results with BGP routing in Internet is a much tougher challenge.

Change in OSPF Designated Router creates extra network LSAs

When testing the OSPF graceful shutdown feature, I've encountered an interesting OSPF feature: if you force a change in LAN DR router (other than rebooting the current DR), you'll end up with two network LSAs describing the same LAN.

This blog has been sitting in my Draft folder for years, so Cisco IOS behavior might have changed in the meantime, or it might have been a transient and/or race condition. Nonetheless, I still find it interesting.

Prefix-Independent Convergence (PIC): Fixing the FIB bottleneck

Did you rush to try OSPF Loop Free Alternate on a Cisco 7200 after reading my LFA blog post ... and disappointedly discovered that it only works on Cisco 7600? The reason is simple: while LFA does add feasible-successor-like behavior to OSPF, its primary mission is to improve RIB-to-FIB convergence time.

Loop-Free Alternate: OSPF meets EIGRP

Assume we have a simple triangular network:

Now imagine the A-to-C link fails. How will OSPF react to the link failure as compared to EIGRP? Which one will converge faster? Try to answer the questions before pressing the Read more link ;)

Redundant DMVPN designs, Part 1 (The Basics)

Most of the DMVPN-related questions I get are a variant of the “how many tunnels/hubs/interfaces/areas do I need for a redundant DMVPN design?” As always, the right answer is “it depends” (and I can always help you with your design if you’d like to get a second opinion), but here’s what I’ve learned so far.

LDP-IGP synchronization in MPLS networks

A reader of my blog planning to migrate his network from a traditional BGP-everywhere design to a BGP-over-MPLS one wondered about potential unexpected consequences. The MTU implications of introducing MPLS in a running network are usually well understood (even though you could get some very interesting behavior); if you can, increase the MTU size by at least 16 bytes (4 labels) and check whether MTU includes L2 header. Another somewhat more mysterious beast is the interaction between IGP and LDP that can cause traffic disruptions after the physical connectivity has been reestablished.

OSPF-over-DMVPN using two hub routers

One of my readers sent me the following question a few days ago:

Do you have a webinar that covers Dual DMVPN HUB deployment using OSPF? If so which webinar covers it?

I told him that the DMVPN: From Basics to Scalable Networks webinar covers exactly that scenario (and numerous others), describing both Phase 1 DMVPN and Phase 2 DMVPN design and implementation guidelines. Interestingly, he replied that the information on this topic seems to be very scant:

DMVPN as a backup for MPLS/VPN

SK left a long comment to my More OSPF-over-DMVPN Questions post describing a scenario I find quite often in enterprise networks:

  • Primary connectivity is provided by an MPLS/VPN service provider;
  • Backup connectivity should use DMVPN;
  • OSPF is used as the routing protocol;
  • MPLS/VPN provider advertises inter-site routes as external OSPF routes, making it hard to properly design the backup connectivity.

If you’re familiar with the way MPLS/VPN handles OSPF-in-VRF, you’re probably already asking the question “how could the inter-site OSPF routes ever appear as E1/E2 routes?”

More OSPF-over-DMVPN questions

After weeks of waiting, perfect summer weather finally arrived ... and it’s awfully hard to write blog posts that make marginal sense when being dead-tired from day-long mountain biking, so I’ll just recap the conversation I had with Brian a few days ago. He asked “How would I set up a (dual) hub running OSPF with phase 1 spokes and prevent all spoke routes from being seen at other spokes? Think service provider environment.

OSPF and connected networks: to redistribute or not?

A few days ago I was discussing a data center design with a seasoned network architect and during the MPLS discussions he made an offhand remark “there are still some switches running OSPF and using network 0.0.0.0 and redistribute connected.” My first thought was “this can’t be good” but I had no idea how bad it is until I ran a lab test.

The generic dilemma along the lines of “should I make connected interfaces part of my OSPF process (and make them passive) or should I redistribute them into OSPF” has no clear-cut answer (apart from the obvious “it depends”) ... and Google will quickly find you tons of lengthy discussions.

OSPF route selection rules

OSPF implementation in Cisco IOS deviates slightly from OSPF/NSSA standards (RFC 2328 and RFC 3101). These are the OSPF route selection rules as implemented by Cisco IOS release 12.2(33)SRE1 (all recent releases probably behave identically):

Note: Update history is at the end of the post

Configuring OSPF in Phase 2 DMVPN network

Phase 2 DMVPN network should behave like a LAN (if you’re not familiar with DMVPN watch the Phase 2 DMVPN fundamentals first). OSPF configuration is thus quite simple ... unless you forget to set the DR priority on the hub router(s) and one of the spokes becomes the DR. Watch the step-by-step OSPF-over-DMVPN configuration guidelines.

Points to remember:

OSPF configuration in Phase 1 DMVPN network

This is how you configure OSPF in a Phase 1 DMVPN network (read the introductory post and Phase 1 DMVPN fundamentals first):

Remember:

Sometimes you need to step back and change your design

A few days ago I received the following e-mail from one of my readers:

I am trying presently to put in place a DMVPN solution running OSPF. I was wondering if you ever saw a solution with dual hub dual cloud design with OSPF working in practice because since I started I have issue with asymmetric routing because of the OSPF functionality.

Actually, I did ... and exactly the same setup is included in the tested router configurations you get with the DMVPN: from Basics to Scalable Networks webinar (register here). While there are many things that can go wrong with DMVPN, I’ve never heard about asymmetric routing problems, so I started to investigate what’s actually going on.

Can you run OSPF over DMVPN?

Ian sent me a really good OSPF-over-DMVPN question after watching the recording of my DMVPN webinar (register here for a live session):

In the DMVPN webinar you discuss OSPF design and configuration. However, Cisco design guide says you should use a different routing protocol from what you use on your LAN but you seem to suggest it is okay to extend your OSPF network out to the DMVPN edge by continuing to use OSPF albeit in a different area.

The main issue you face when running OSPF over DMVPN is scalability: OSPF does not scale as well as other routing protocols when used over DMVPN.