Nuances of OSPF over NBMA (F.R.)

MrBrian

Okay, I'm just gonna admit, running OSPF over NBMA networks such as F.R. is kicking my a** lol. So much so, that that's all I've been practicing this week, and that's a good 5 hrs+/day. I've been messing around with it in so many ways that my heads spinning. It's even caused me to order some used F.R. book off amazon for .50cents.. wow, what a deal!! (I wanted to know more about how lmi works). However, I am glad to say I've reached a point where I can do basic configs with all the modes pretty easily now, but there's still some things that seem fishy to me, and I guess that's why I just won't leave it alone lol. I mean, just seeing the way it responds to various things is driving me bonkers. I've been trying practically every combination of subint and ospf network type to see what works and what doesn't. Maybe I'm reading way too much into all this, but it's making me so damn curious at the same time. So I'm not sure if this is a question I have, or just something I'd like more info on if anyone wants to throw some knowledge at me lol.

Here's the rundown: Let's say we have a basic hub/spoke topology, and we don't want the spokes to be able to reach each other. For this scenario, assume all IP's are assigned correctly. For the hub, I have a multipoint sub-int, with network type point-to-multipoint... Now on R2(a spoke), let's say I create a point-to-point subint, and all is fine, I can communicate with the hub, but not the other spoke. But now, let's say I want the spokes to be able to reach each other. So under the point-to-point subint I do a "ip ospf network point-to-multipoint." Now, the output of "sho ip ospf int" does show that the subint is of point-to-multipoint ospf network type with hello/dead intervals of 30/120 (where p2p is 10/40). However, it will not let you create frame-relay mapping statements, when you try you get "Only the frame-relay interface-dlci command should be used on point-to-point interfaces not frame-relay map." So even though it's p2m ospf type in the output, I guess as far as the frame-relay logic goes, it's point-to-point (because I created the subint that way). So I'd have to delete the subint and recreate it as a multipoint if I wanted that.

So then if I delete the subint, and create it as a multipoint subint, I can now do an "ip ospf network point-to-multipoint" (since the default ospf net type for a multipoint subint is non-broadcast), and it will obviously allow me to create my static frame-relay mapping statements. Also, say I decide now to make it a p2p ospf network type again. I can go do an "ip ospf network point-to-point" and it will take on the p2p ospf characteristics (hello/dead=10/40, etc), but now it will allow me to make static mappings, even with the int being in p2p mode.

So is it right to conclude that with subint's, the only thing dictating whether I can do static frame-relay mapping commands is the way the subint was created (i.e. multipoint or point-to-point)? And that the "ip ospf network type" does not affect my ability to do static mappings.. So if I create the subint as point-to-point I kind of pigeonhole myself if I want to later add static mappings for another spoke because now I'd need to delete the subint and recreate it as multipoint. Whereas if I create the subint as multipoint, I can then move around using p2p or p2m ospf network types and just change the hello's to match the hub with what it's using..

Wow, sorry if I rambled a bit! I guess I was trying to think out loud a little. And describing all these network types gets a little cumbersome. If anyone wants to pitch in whatever they want, please feel free because I'm deep in this stuff, and I'd love to read it. Keep in mind, as a college student, I've never dealt with this in a real world scenario, and I'd have to imagine that it usually doesn't get all too crazy. That you just make a design that will allow adjacency's and pass routes..

For the most part, I think I've gotten all the basics. This is because I can think of various needs companies would have, namely reachability, and I can do basic configs to provide a solution for that. So maybe basic configs are all that's needed in the real world, but maybe not. I guess I just need to figure out how deep I want to get into this for the ROUTE exam, because it seems that it could get a whole lot crazier and be an exam in and of itself. But then again I guess every exam topic can be. I guess it's the whole "the more you know, the more you don't know" thing..

Turgon

Fantastic. Do yourself a favour and go on amazon and buy one of the best books written about this subject. Bridges Routers and Switches for CCIEs by Bruce Caslow Second Edition. You will pick it up for the price of a Happy Meal.

No one reads this book anymore because people simply grab whatever certification books are current. A good book is a good book even if it is 12 years old

MrBrian

Turgon wrote: »

Fantastic. Do yourself a favour and go on amazon and buy one of the best books written about this subject. Bridges Routers and Switches for CCIEs by Bruce Caslow Second Edition. You will pick it up for the price of a Happy Meal.

No one reads this book anymore because people simply grab whatever certification books are current. A good book is a good book even if it is 12 years old

Alright Turgon, got it! Thanks so much! Probably the best .80 cent investment I've ever made (Oh wait, plus 4$ shipping, darn haha). Heck, if I can get a technical book that will give me a ton of knowledge for 1/4th the price of the shipping, it's a done deal. I'm sure there are few parts outdated, but probably not too much overall. And like you said, good is good, regardless of time.

I'm finding more and more that the material I'm covering (ccnp ROUTE), is opening up a world of other technologies that I haven't been open to before. So now it's about finding the happy median of what I should learn to pass the exam, or decide how in depth I want to go. Haha, I guess this is the bridge we all have to cross at some point. And I don't want to just be a paper ccnp, so I will heed your advice and take a look at that book.

paage

Yes I was kinda confused myself there.
I beleive the 'ip ospf network' command only refers to how OSPF will behave. While the point-to-point or point-to-multipoint command on the subinterface is only addressing the behaviour of framerelay itself and how it should be configured.

Forsaken_GA

paage wrote: »

Yes I was kinda confused myself there.
I beleive the 'ip ospf network' command only refers to how OSPF will behave. While the point-to-point or point-to-multipoint command on the subinterface is only addressing the behaviour of framerelay itself and how it should be configured.

This is it precisely. The ip ospf network command *only* effects how OSPF treats the interface. The subint isn't limited to only OSPF operation, so it doesn't care what OSPF is doing, it cares what it's been told directly when it was created.

OSPF over Frame Relay is a huge pain in the ass, so spend alot of time with it until you've got it down. Keeping track of which link types require DR/BDR elections, which require neighbor statements to bring up the adjacency, et al is alot to take in, but it's pretty easy once you get it down.

MrBrian

Forsaken_GA wrote: »

This is it precisely. The ip ospf network command *only* effects how OSPF treats the interface. The subint isn't limited to only OSPF operation, so it doesn't care what OSPF is doing, it cares what it's been told directly when it was created.

OSPF over Frame Relay is a huge pain in the ass, so spend alot of time with it until you've got it down.

Gotcha!! Ok, since typing up that whole post and listening to your guys' comments, it all seems clearer. It was hard to close the gap for me to reach this conclusion because I'm only dealing with ospf over frame-relay, nothing else. So in my ignorance, I was relating the multipoint and p2p subint commands directly to the ospf network types... silly me. Appreciate the input guys!

bermovick

Glad to hear I'm not the only one struggling with ospf over frame relay & the 5 network types. I've been stuck on these for a good 3-4 days myself.

In addition to the nuances between the different types, I don't quite get why they're all strictly necessary, like the 2 times you have a broadcast vs non-broadcast variants, where the only difference is whether you add the broadcast argument to the frame-relay map command. Further complicating the examples is them all using the frame-relay map command when I know it's not always required.

I think at some point it's all going to click in place; I'm just waiting for that now haha.

MrBrian

bermovick wrote: »

like the 2 times you have a broadcast vs non-broadcast variants, where the only difference is whether you add the broadcast argument to the frame-relay map command. Further complicating the examples is them all using the frame-relay map command when I know it's not always required.

Glad to see someone else is flapping on this subject a little like me . I'm not actually sure what you mean, but think I have an idea. And thinking out loud will help me in my own understanding as well, so I'll take a shot...

The broadcast keyword on the end of the frame-relay mapping statements allows for pseudo broadcasting, and allows the multicast hello's to be sent over the F.R. cloud (I haven't yet run wireshark on it to see what exactly it sends, but this is my basic understanding). It will send a broadcast style packet for each DLCI/PVC configured with a mapping statement.

For the hub router, you'd want to configure the broadcast keyword for each DLCI/PVC reaching each spoke. However, for the spoke routers, you do not need to append the broadcast keyword for every frame-relay mapping statement, just one of them. This is because the router will generate a pseudo broadcast for each mapping statement, so you'd be sending more than you really need.

For example, say you have a hub and spoke topology with 3 spokes, and you need each spoke to reach the other, going through the hub. On each spoke, you'd have a frame-relay mapping statement to reach the hub, in addition to a frame-relay map statement to reach the other spokes. However, (let's say this is hub/spoke, not partial mesh here) there is only one DLCI/PVC on every spoke, and that is the PVC going back to the hub... so for each mapping statement you'd use the same DLCI... So, if you were to use the broadcast keyword on all the statements, the router would generate a broadcast style ospf message for each statement, whereas if you use the broadcast keyword on just one of the statements, it will send pseudo broadcasts for all the mappings using that DLCI.. If you do a "debug ip ospf hello" or "debug ip ospf adj" you will see it creating the pseudo broadcast for each statement, whereas having it on only one of the statements will work fine, because the hub will receive the ospf hello/lsu etc.

If someone can explain it better and/or correct anything I've said, please feel free. My understanding is still in its infancy, but is developing, and I'd listen to anything. Also here's another thread that discusses it

https://learningnetwork.cisco.com/thread/23057?tstart=-7859

Turgon

MrBrian wrote: »

Glad to see someone else is flapping on this subject a little like me . I'm not actually sure what you mean, but think I have an idea. And thinking out loud will help me in my own understanding as well, so I'll take a shot...

The broadcast keyword on the end of the frame-relay mapping statements allows for pseudo broadcasting, and allows the multicast hello's to be sent over the F.R. cloud (I haven't yet run wireshark on it to see what exactly it sends, but this is my basic understanding). It will send a broadcast style packet for each DLCI/PVC configured with a mapping statement.

For the hub router, you'd want to configure the broadcast keyword for each DLCI/PVC reaching each spoke. However, for the spoke routers, you do not need to append the broadcast keyword for every frame-relay mapping statement, just one of them. This is because the router will generate a pseudo broadcast for each mapping statement, so you'd be sending more than you really need.

For example, say you have a hub and spoke topology with 3 spokes, and you need each spoke to reach the other, going through the hub. On each spoke, you'd have a frame-relay mapping statement to reach the hub, in addition to a frame-relay map statement to reach the other spokes. However, (let's say this is hub/spoke, not partial mesh here) there is only one DLCI/PVC on every spoke, and that is the PVC going back to the hub... so for each mapping statement you'd use the same DLCI... So, if you were to use the broadcast keyword on all the statements, the router would generate a broadcast style ospf message for each statement, whereas if you use the broadcast keyword on just one of the statements, it will send pseudo broadcasts for all the mappings using that DLCI.. If you do a "debug ip ospf hello" or "debug ip ospf adj" you will see it creating the pseudo broadcast for each statement, whereas having it on only one of the statements will work fine, because the hub will receive the ospf hello/lsu etc.

If someone can explain it better and/or correct anything I've said, please feel free. My understanding is still in its infancy, but is developing, and I'd listen to anything. Also here's another thread that discusses it

https://learningnetwork.cisco.com/thread/23057?tstart=-7859

You are over thinking things. Read Caslows book. The nature of subinterfaces and physical interfaces. Broadcast and non broadcast. Inverse Arp. Hub and spoke. When to frame relay map and when not to map. Split horizon and distance vector routing protocols. Timers and OSPF.

Read all that stuff then build scenarios one at a time with a Cisco router offering a frame relay switch and three others connected to it with one acting as a hub and the other two being spokes. Run debugs at the frame relay level. Try different types physical and subinterface. Try RIP and EIGRP. Try OSPF. Try neighbor statements. Try ip ospf network type statements. Try frame relay map statements with or without the broadcast command. Run OSPF debugs.

Frame Relay's inherent operation provides acute problems with routing protocols in certain situations that you must be aware of so you can counter/overcome them. Understanding how frame relay works, and what routing protocols require to work properly is what is being tested here. This is precisely why Frame Relay remains a core learning topic..

Like I said, no one reads Caslow anymore...

Forsaken_GA

Turgon wrote: »

Like I said, no one reads Caslow anymore...

Turgon speaks truth. Large sections of the old Caslow book are outdated, but it's still got some very good information, and considering how cheaply it can be acquired, everyone should be availing themselves.

MrBrian

Turgon wrote: »

You are over thinking things.

I'll take that as a compliment, haha.

Turgon wrote: »

Read all that stuff then build scenarios one at a time with a Cisco router offering a frame relay switch and three others connected to it with one acting as a hub and the other two being spokes. Run debugs at the frame relay level. Try different types physical and subinterface. Try RIP and EIGRP. Try OSPF. Try neighbor statements. Try ip ospf network type statements. Try frame relay map statements with or without the broadcast command. Run OSPF debugs.

These are all the things I'm doing now. It's all been happening so fast, all within this past week, so I think as time goes by it will all sink in because I'm messing around with it for hours on end. I ordered the Caslow book. It has shipped and everything, so I'm looking forward to that. It will be another avenue for me to learn the material. I appreciate the advice you gave me. It's awesome to be able to interact with such great networking minds and get advice seeming that you guys are probably in the place I'd like to be in the future..

bermovick

I think I generally understand it all; I tend to try to figure out why in order to make sure the knowledge sinks in to the point where I can apply it. And here's where I get stuck. Some of the types I'm not sure why you would ever want. I can understand that sometimes DR elections would be useful, and sometimes undesired, but I don't see why you would specifically choose not to use automatic neighbor discovery for example.

Yesterday was a minor A-Ha moment though, so I think that's the last piece of the puzzle.

Forsaken_GA

bermovick wrote: »

I think I generally understand it all; I tend to try to figure out why in order to make sure the knowledge sinks in to the point where I can apply it. And here's where I get stuck. Some of the types I'm not sure why you would ever want. I can understand that sometimes DR elections would be useful, and sometimes undesired, but I don't see why you would specifically choose not to use automatic neighbor discovery for example.

Yesterday was a minor A-Ha moment though, so I think that's the last piece of the puzzle.

Well, once upon a time, you may not have had an option. If you needed WAN links, and the only thing available was NBMA frame relay, you didn't have much of a choice as to how it was configured. In this day and age of everything ethernet, NBMA environments are a dying relic of the past, but Cisco still wants you to know how to do it.

johnwest43

+1 on the Frame relay and ospf confusion. I am just getting to this part of the flg. I took Turgons advise and bought the Bridges Routers and Switches for CCIEs. I forgot about 95 percent of the Frame Relay Information from the CCNA. I had to go back and read my ICND2 books before i even started reading about EIGRP over Frame Relay.

Quick question how many of you in this forum have ever used Frame Relay? Just my thinking but it seems that all I ever see for multiple site connectivity is VPN. Im just wondering if FR still has a place anywhere in the world these days?

Forsaken_GA

johnwest43 wrote: »

Quick question how many of you in this forum have ever used Frame Relay? Just my thinking but it seems that all I ever see for multiple site connectivity is VPN. Im just wondering if FR still has a place anywhere in the world these days?

I've worked on them on a couple contract jobs, but they're a dying breed. The ones that are still around are pretty much just waiting on their contracts to run out (WAN circuit contracts tend to be long, 10 to 20 year contracts are not uncommon). A number of providers are refusing to renew contracts for frame-relay circuits. MPLS has displaced Frame-Relay as the WAN interconnection of choice.

wave

Good thread! I hit OSPF network types a few days ago and I think it's pretty much sunk in now, but the trick will be remembering all of the combinations of how each mode behaves.

What I found interesting is if you have two routers and one is configured with a point-to-point sub interface and the other has a multipoint subinterface. If I then configure one side with ip ospf network point-to-multipoint and the other side with ip ospf network point-to-multipoint non-broadcast...I don't configure any neighbor statements on the router with point-to-multipoint non-broadcast mode BUT the two routers still become Neighbors.

I turn on debugging and sure enough, both routers are sending and receiving Hellos. Weird! I thought it took two to tango!

If I then configure both routers to point-to-multipoint non-broadcast mode and don't configure the neighbor statement - No Hellos as expected. As soon as I enter the neighbor statement on both routers, boom, they become Neighbors as expect.ed

wave

Here are some blog posts on OSPF network modes that I found helpful:

OSPF over Frame-Relay Non-Broadcast
OSPF over Frame-Relay Broadcast
OSPF over Frame-Relay – Part 3: Point-To-Point
OSPF over Frame-Relay – Part 4: Point-To-Multipoint
OSPF over Frame-Relay – Part 5: Point-To-Multipoint Nonbroadcast
OSPF over Frame-Relay Troubleshooting