Press J to jump to the feed. Press question mark to learn the rest of the keyboard shortcuts
8

Redundant OSPF Neighborships?

Quick question I couldn't find any resources on online. If an OSPF neighborship is established between two routers on one subnet, and again on another subnet, is there any problem with that? Or is it just added redundancy if one link fails?

10 comments
91% Upvoted
What are your thoughts? Log in or Sign uplog insign up
level 1

It's just another route to whatever is on either side of those routers. It will also load balance across those redundant links depending on configuration.

level 1

Yes, and no.

If you have multiple physical paths (i.e. two ethernet links between routers), then yes, they should both be running your IGP. In the case of EIGRP or OSPF MTR, you could weight them differently for different traffic. In regular OSPF you can either have them be equal cost or not.

In the case of multiple vlans on a single 802.1q trunk, yes, that is a problem. Because there's really no reason you'd need to fail between vlans on the same link (I suppose if you shut an SVI, but that's your own stupid fault if that's what happens), running an OSPF adjacency over the same link will be wasteful of resources at best. At worst, if you had two physical pathways of same cost, one with a single adjacency, one with multiple, the one with multiple would be seen by ECMP as independent pathways and thus get a disproportionate share of traffic.

As an aside, you should generally never pair via a vlan between switches, only routed interfaces. An exception would be if either a) you used a different vlan for each adjacency, or b) you used NBMA/P2MP, or EIGRP static neighbors.

+------+       +-------+       +-------+
|      |       |       |       |       |
|  R1  |       |  R2   |       |   R3  |
|      |       |       |       |       |
+----+-+       +---+---+       +---+---+
     |             |               |
     |             |               |
     |             |               |
     |             |               |
     |      +------+--------+      |
     |      |               |      |
     +------+    SW1 (L3)   +------+
            |               |
            |               |
            +---------------+

Imagine this where all routers have a full adjacency on the SAME vlan/subnet.

In this case, R1 thinks that it is only a single hop from R2 and R3. That's not true, it's two. Also, SW1 may be able to detect that R3 went down by way of monitoring the physical port it peers on. R1 can't do that. If they were all peered to SW1 ONLY, SW1 would see R3 drop and then immediately alert R1 and R2. In this case, that won't happen and you can end up in some cases even having R1 advertise reachability back out to R2 and SW1. These problems become even worse with BGP with no traditional split-horizon type rules, and long hold times.

If you have to do something like this (or if SW1 was L2 only), run BFD between the routers to quickly detect and respond to a failure.

level 2

In the case of multiple vlans on a single 802.1q trunk, yes, that is a problem.

I think there is a situation here you aren't taking into account... That is two routers, separated by multiple switches running MST(or another multiple STP) that results in multiple paths through the switched network.

This would actually be an acceptable use of multiple ospf neighboudships over a single VLAN trunk. Another acceptable use would be when using a VPLS or similar layer two technology that has redundant paths defined by VLAN. Not super common but a possibility.

In this case, R1 thinks that it is only a single hop from R2 and R3. That's not true, it's two.

Sorry, incorrect, it is still only one routed hop if it is on the same VLAN for all devices, the SVI won't matter for reachability behind any of the other routers as there will still be reachability if the SVI goes down but the VLAN as a whole remains up.

You are correct about interface monitoring however.

level 3

I think there is a situation here you aren't taking into account... That is two routers, separated by multiple switches running MST(or another multiple STP) that results in multiple paths through the switched network.

This would actually be an acceptable use of multiple ospf neighboudships over a single VLAN trunk.

If your saying that you would singly home a router to a switch, and then dual connect that switch to another switch (or several), and then singly home another router to the second switch, I suppose that might possibly be some reason why you would want to run two different adjacencies. But only then if you're using a DV protocol, OSPF MTR, or perhaps OSPF with MA/multiple processes. This would be an incredible corner case, and I have a real tough time trying to come up with a scenario why you would have two routers peering with each other through a myriad of layer 2 switches running MST (or PVST/RSTP setup for diverse paths) that is not misdesigned. There's just a ton that is potentially wrong here.

Sorry, incorrect, it is still only one routed hop if it is on the same VLAN for all devices, the SVI won't matter for reachability behind any of the other routers as there will still be reachability if the SVI goes down but the VLAN as a whole remains up.

It's not incorrect at all, and you're pointing out most of the problem with it. Referring to the diagram I included, it does indeed appear to the devices that they are all one hop away. The issues is that they are indeed not. The fact that the SVI can operate independently of the layer 2 vlan is immaterial.

Consider a situation where undrawn router R4 has direct connections (layer 3) to the switch and to Router2. It is one hop away from both. R1 would incorrectly perceive that the path through R2 is as short as the path through SW1, but it certainly is not in terms of latency, bandwidth, etc. Additionally as stated above, if R2 were to fail, R1 would not be able to detect that via the physical layer as the switch itself can. The switch could immediately mark R2 as down, the router (absent BFD or similar) could not. It will continue to send half its traffic (or potentially all depending on cost) to R2 which will be rejecting it while the SW1 path remains up.

This is the exact same situation people have run into (including Cisco AS NCE's themselves) with VPC on Nexus. They connect a Layer3 device to the two switches via VPC. In most (older at least) versions of the software, this is simply not supported. In all versions, it's never a good idea to see yourself as a single hop away from a device if your traversing a different one. Why would you ever send traffic up to Switch 2 with the ultimate destination of Switch 1 if you have a functional link to Switch 1? You wouldn't. People just come up with weird designs that are a bad idea. This limitation doesn't apply to VSS or Stackwise since those are both single control plane systems compared to VPC which is dual control plane.

level 4

I think there is a situation here you aren't taking into account... That is two routers, separated by multiple switches running MST(or another multiple STP) that results in multiple paths through the switched network.

This would actually be an acceptable use of multiple ospf neighboudships over a single VLAN trunk.

If your saying that you would singly home a router to a switch, and then dual connect that switch to another switch (or several), and then singly home another router to the second switch, I suppose that might possibly be some reason why you would want to run two different adjacencies. But only then if you're using a DV protocol, OSPF MTR, or perhaps OSPF with MA/multiple processes. This would be an incredible corner case, and I have a real tough time trying to come up with a scenario why you would have two routers peering with each other through a myriad of layer 2 switches running MST (or PVST/RSTP setup for diverse paths) that is not misdesigned. There's just a ton that is potentially wrong here.

There could be a case, where a vlan cannot traverse one link for any number of reasons, but it can traverse another. This would be where I would envision this.

Sorry, incorrect, it is still only one routed hop if it is on the same VLAN for all devices, the SVI won't matter for reachability behind any of the other routers as there will still be reachability if the SVI goes down but the VLAN as a whole remains up.

It's not incorrect at all, and you're pointing out most of the problem with it. Referring to the diagram I included, it does indeed appear to the devices that they are all one hop away. The issues is that they are indeed not. The fact that the SVI can operate independently of the layer 2 vlan is immaterial.

Actually it is very material

Consider a situation where undrawn router R4 has direct connections (layer 3) to the switch and to Router2. It is one hop away from both. R1 would incorrectly perceive that the path through R2 is as short as the path through SW1, but it certainly is not in terms of latency, bandwidth, etc.

No, it still is only one layer 2 hop away from the other device, you need to stop conflating the fact that he switch is acting as an L3 device as well as an L2 device, if you are passing all VLANs.

While physically the path may be closer with SW1, there are other variables that sometimes need to be taken into account when using SVI's. One of them is the actual processing capabilities of the switch itself when acting as a router. Not every switch is created equally.

Additionally as stated above, if R2 were to fail, R1 would not be able to detect that via the physical layer as the switch itself can. The switch could immediately mark R2 as down, the router (absent BFD or similar) could not. It will continue to send half its traffic (or potentially all depending on cost) to R2 which will be rejecting it while the SW1 path remains up.

I am not saying this is a good design, but it is a valid design and there may be any number of reasons for this (for example a switch connected to a single fiber uplink to a MPLS connection, or you are terminating other VLANs on a SVI that is only connected to this switch (or for certain reasons you don't want to connect htem to routers.

This is the exact same situation people have run into (including Cisco AS NCE's themselves) with VPC on Nexus.

No, that is not the problem with OSPF and vPC on a Nexus. The problem with OSPF and vPC on Nexus has to do with the loop prevention mechanism on a Nexus switch. The Nexus won't forward the traffic across the vPC link and then out another link to another device. This has nothing to do with whether it is a good idea to use a routing protocol across the vPC and everything to do with loop avoidance.

They connect a Layer3 device to the two switches via VPC.

You mean this topology, which is fully supported?

In most (older at least) versions of the software, this is simply not supported.

If it is the design as I mentioned above, it is supported. If not, show me the unsupported design.

In all versions, it's never a good idea to see yourself as a single hop away from a device if your traversing a different one.

I have given you instances where there is a valid business case for it (ex: processing power)

I am not saying that this might be a bad design, but to close yourself off to the possibility that it could be the best design for a given circumstance is incredibly short-sighted.

level 5
0 points · 2 months ago · edited 2 months ago

You're conflating a lot of things here, but it really comes down to that you're advocating shitty network design. Don't advocate shitty network designs and corner cases. Don't try to shoehorn some layer 3 switch into also acting as a layer 2 for the express purpose of "incase the L3 SVI is shutdown" and things like that. Otherwise your manufacturer will be sending people like me out to unfuck it somewhere down the road. Whenever it is something like, "it's the best design because we're too broke or cheap to do it correctly", the correct answer is always to not do it and walk away.

And VPC peer link issues very much do prevent routing protocols (depending on hardware and software) from going across the peer link due to loop prevention, just like they do with regards to not receiving over VPC on switch A, going across the PL, then out a fully functional VPC on switch B. Static routes are accepted, IGP's are not (and in practice I can tell you that BGP with loopbacks using static routes to point to the loopbacks work, though is not actually a supported, nor recommended configuration).

Sources: I've personally performed about 100 different test scenarios for Cisco AS regarding various VPC peering, specifically on the 7k.

https://www.cisco.com/c/dam/en/us/td/docs/switches/datacenter/swhttps://www.reddit.com/design/vpc_design/vpc_best_practices_design_guide.pdf Page 75

"Attaching a L3 device (router or firewall configured in routed mode for instance) to vPC domain using a vPC is not a supported design because of vPC loop avoidance rule. To connect a L3 device to vPC domain, simply use L3 links from L3 device to each vPC peer device."

https://www.cisco.com/en/US/docs/switches/datacenter/nexus5000/sw/mkt_ops_guides/513_n1_1/n5k_L3_w_vpc_5500platform.html#wp1015010

https://www.cisco.com/c/en/us/support/docs/ip/ip-routing/118997-technote-nexus-00.html

https://www.netcraftsmen.comhttps://www.reddit.com/designing-vpc-and-routing/

level 6

You're conflating a lot of things here, but it really comes down to that you're advocating shitty network design. Don't advocate shitty network designs and corner cases.

First of all, no I am not. I wasn't the person that added a Nexus into the middle of a conversation where a Nexus didn't exist. Second, the fact that you can't even imagine a case where their might be a call for this (theory) and instead shut down the idea makes you the "shitty designer". While there might be problems with a design similar to this, it is entirely possible that this is the best design. I personally wouldn't recommend this, but this isn't really the place to set aside something outright.

Don't try to shoehorn some layer 3 switch into also acting as a layer 2 for the express purpose of "incase the L3 SVI is shutdown" and things like that.

Well, in what other scenario would you get what you describe in your first post? You wanted a scenario where it might be called for, don't bitch about it when I come up with it.

Otherwise your manufacturer will be sending people like me out to unfuck it somewhere down the road. Whenever it is something like, "it's the best design because we're too broke or cheap to do it correctly", the correct answer is always to not do it and walk away.

Highly unlikely, given that I personally know a Cisco SE, if there was a problem they would probably send the SE that I am friends with.

And VPC peer link issues very much do prevent routing protocols (depending on hardware and software) from going across the peer link due to loop prevention, just like they do with regards to not receiving over VPC on switch A, going across the PL, then out a fully functional VPC on switch B. Static routes are accepted, IGP's are not (and in practice I can tell you that BGP with loopbacks using static routes to point to the loopbacks work, though is not actually a supported, nor recommended configuration).

Did I comment on routing over the peer link? No, I did not, I asked you what topology you were describing because right now you are typing like a mad internet person and not making much sense.

I suggest you look at this for the current supported topologies (it hasn't changed really):

http://bradhedlund.com/2010/12/16/routing-over-nexus-7000-vpc-peer-link-yes-and-no/

This is also a good read, since it is fairly recent:

https://rack.life/2017/01/cisco-nexus-vpc-routing-in-2017/

That said, Nexus switches are special cases and doubtful the OP actually cares about them at this point in their studies, beyond knowing about them.

level 7

Again, you're entire statement can be summed into either incorrect information, poor reading, or just accepting that we should not be discussing poor designs to implement. The fact that I'm not willing to entertain a "this scenario is completely fucked up, we're on an island, and half our shit exploded, what do we do" as a design worth discussing isn't a weakness. If you need a switch to connect a bunch of routers and also run layer 3, and it can't do that, buy a better switch. Unless your market is "doctor's offices and other people who have no money, and want to spend less" then do the right thing, don't lie to yourself about "well it's right for our situation". Emergencies aside, if it's not worth doing right, it's not worth doing.

Your quote:

No, that is not the problem with OSPF and vPC on a Nexus. The problem with OSPF and vPC on Nexus has to do with the loop prevention mechanism on a Nexus switch. The Nexus won't forward the traffic across the vPC link and then out another link to another device. This has nothing to do with whether it is a good idea to use a routing protocol across the vPC and everything to do with loop avoidance.

Diagrams 2 and 3 are the scenarios that I'm talking about, and accordingly are marked, does not work. You clearly said that the peer link. Now you're saying, "well I never said anything about routing across the peer link". Righhhtttt.. Perhaps you can't realize that the topology you showed as "fully supported" is running across the peer link, presuming the only connection is the VPC. Otherwise why post it. It's also a terrible idea with no reason to ever run.

Like I said, I've done this testing, FOR Cisco. I'm quite well aware of the problems you'll get yourself into.

And you really hit the nail on the head. OP doesn't likely give a shit about any of the stuff you started down this path, like why you might want to have a singly homed router connected via Multi Spanning tree across a mesh of layer 2 switches to another singly homed router. Turns out, nobody cares about that.

level 8

I will address the rest tomrrow morning (if I actually give a flying F), however...

Now you're saying, "well I never said anything about routing across the peer link".

Fair, I can see your problem with the statement, however I didn't state whether it was or wasn't possible to route across the vPC link; I did say it isn't possible to route across the vPC to a third device. In context, it is an important distinction.

Again, check out the link of supported topos I posted, which is what I always refer to if I have any questions. I know the supported topos, I was explaining the reason for the unsupported topos was loop avoidance, not just because "routing across vPC is bad, mkay".

level 9

Again, check out the link of supported topos I posted, which is what I always refer to if I have any questions. I know the supported topos, I was explaining the reason for the unsupported topos was loop avoidance, not just because "routing across vPC is bad, mkay".

Perhaps you missed this:

Sources: I've personally performed about 100 different test scenarios for Cisco AS regarding various VPC peering, specifically on the 7k.

Like I said, I've done this testing, FOR Cisco. I'm quite well aware of the problems you'll get yourself into.

You addressing the rest tomorrow morning is not needed.

Community Details

6.2k

Subscribers

64

Online

Create Post
r/ccnp Rules
1.
No posting of illegal materials
2.
No posting of "braindumps"
3.
Be courteous and helpful
Cookies help us deliver our Services. By using our Services or clicking I agree, you agree to our use of cookies. Learn More.