OSPF: Peering Basics (IPExpert VoD) - Part I

Ok, it has been a while I don´t post anything, but believe me, it´s not because I don´t want too... I´m really away from everything due to a huge project to implement before christmas, hopefully!

That means... I do have "ocasional"  internet access (like, 1h every 5 days, can you believe that?! Me neither! It´s really difficult for a "Internet Addicted" guy like me)!!!

Anyway... That´s why I´m a bit away from all the news (I can see some exciting news regarding EverythingIE and Dynamips support from IPExpert), also a new online vClass from them, and a new introductory class from Internetwork Expert! Cool! As always, the most they try to be better than the other, we win! :) Wonderful man!

Also, Joe, I saw your email - sorry for taking so long to reply, but I´ll do it soon! Very NICE diagram and observations there! Sorry for taking too long to reply it to you, but I´ll do it soon! :S

So... let´s get a bit more technical, into OSPF, those are some notes, personal understandings and mostly the instructions, tips and advices from IPExpert VoD (awesome material). OSPF is splitted in several parts on those VoD starting with peering basics, which in my opinion, makes sense, why implement other features like security before having full reachability ?! Insane if you ask me! That means, when you get into the OSPF section, don´t worry about authentication, or area type, or things like that! Get the basics peering up and functional! Period!

That means, assign the correct router/interfaces in the correct areas, like area 0, area 1, and forget everything else, like stub, nssa, and others! Take one step at a time!

Look at your diagram and check the issues you could have to peer between the routers using OSPF... For sure the first thing that will cause us problems will be OSPF and Frame-Relay...

Oh yeah... just to remember, the Frame-Relay world has 3 different Frame-Relay interface types: Physical, Multipoint and point-to-point.

Now... as far as OSPF is concerned, we have 5 different network types. Out of that, either Multipoint and Physical Frame-Relay interfaces are both going to default to an OSPF Non-Broadcast Network Type.

On the other hand, the Point-to-Point Frame-Relay subinterface is going to default to a Point-to-Point Network Type in OSPF.

That can lead us to some mismatches, depending on the frame-relay network setup and topology. As Scott likes to say, little things to be looking at, but very important! :)

Match your network and interface types together! First of all, timers may not match if you try to mix different interface types!

There´s also the DR Router! We must take care to make our HUB router the DR! Also, if running over a Non-Broadcast link, don´t forget the broadcast parameter in the frame-relay maps, to have OSPF actually "working" on your network (even better, on your exam!). One piece of advice is, on a point-to-point subinterface this is enabled by default.

There are some tools (AKA debug) that we can use to check this "broadcast"  issue, like debug ip packet, if you get encapsulation failed, that pretty much tells you that there´s something missing (that could be the broadcast parameter in your maps, or some other kind of little thing we usually forget about).

Also, keep in mind the neighbor command! They may forbidden you from changing the network types, and things like that, we can always use the neighbor command to try to achieve neighbor relationship.

You MUST read your exam carefully and understand how it´s worded! It might tell you: don´t change the network type on the spokes, or on the HUB change to a network type other than broadcast! At the VoD Scott suggest us to start looking at the details, looking at the things that match, looking at the things that NEEDS to match in order to perform peer! Start thinking and choosing how you´re going to do stuff! A great advice!

Any interface that is Point-to-Something does NOT elect a DR, keep that in mind! But, Broadcast and Non-Broadcast will!

Broadcast - Elects a DR, and it has what we call fast timers,  10/40 sec (hello/dead) timers.

Non-Broadcast - Elects a DR, but has slow timers, 30/120 sec! It also works in the unicast fashion,  it "must" have the neighbor command! Very important! It MUST have it! In order to actually operate!

But the real question is: Can we mix and match those types?! If our spokes are Non-Broadcast, can we make the HUB Broadcast?! Sure! Absolutely! We´ll have to change timers, they need to match, either fast or slow, doesn´t matter, but they have to be the same at each end.

Also... the neighbor command... where to put it on this situation?! On this "scenario" the neighbor command goes into the spokes, even knowing that we may normally have to put them on the hub! If your HUB is in Broadcast type, the neighbor command is not accepted!

As long as the timers match, and your choices about the DR, we´re good to go!

Point-to-Point and Point-to-Multipoint, same thing, you can mix and match those if I want too, just adjusting timers!

Point-to-Multipoint Non-Broadcast (Cisco Proprietary) It assumes the same type of idea the point-to-multipoint does, uses the same slow timers and stuff, but, it must use unicast packets, that means, it uses the neighbor command ...

Now, in order to form a peering relationshipe, there are a number of things that needs to match!

Timers for example, it needs to match! We can change it! Like the OSPF Hello Timer, if we change the Hello Timer, the Dead Timer automatically changes (by the way, the Dead Timer can also be changed independently, to achieve any weird task if needed)!

Other things that must match:

MTU Size must match!

Area ID must match! That makes sense! We can´t peer an Area 0 guy with an Area 1 guy! :)

Stub Flag must match! Now, this highlights a very important rule in OSPF, one of the OSPF rules is that everybody in an Area must have the same database information! Well... what the Stub flag does?! It says a variaty of things, but it´ll tell your router it can´t have external routes as an example, what about the other router in the area, if it "wants" to have external routes!? Things are not going to work very well in this situation! Everybody MUST agree about the Stub Flag!

The same applies to Netmask! It´s important to know "we´re" all in the same network in there! There are some exceptions with Virtual-Links and Point-to-Point interfaces, don´t need to worry about that part, but, as we go through, all of these things have to match!

One very important thing is missing out of this list! That will be the DR!

Technically you can peer "something" that requires a DR with "something" that doesn´t requires a DR. However, things will be all messed up if we do that! In the DR world, somebody believes they´re in charge, and they´re the ones who can announce the routes officially!

On the non-DR network everybody has the right to announce routes, and that will mess up all of your database and reachability.

So, even knowing the DR is not a poart of the list here, you do have to match and agree to who is or is not the DR!

The neighbor command (we´re talking about it very much, don´t you think?!), is basically used when I can´t use multicast in order to get to the other side!

Technically it´s only necessary in one side of the connection, so, in a Hub and Spoke network I would probably use my Hub to put this. One place, put all the neighbors, keep life simple! But, this is not necessary! You can do it in the spokes if you want! You can do in both if you want! No big deal! But you have to have the neighbor command some place in order to initiate the conversation!

So, in our example, making the HUB Broadcast, and the Spokes Non-Broadcast, the neighbor command HAS to go on the spokes, the broadcast guy (the HUB in this situation) won´t even accept the neighbor command!

Your HUB will be sending out it´s multicast frames, no one will be talking back to it, and them, it gets an unicast from one of the spokes and says "Oh, ok! This is how you wanna talk?! Not a problem" and it´ll respond to that spoke.

Back in our example scenario... the neighbor command MUST be used in every spoke in order to trully operate! Once each of them initiates the unicast conversation the HUB will reply just fine, and everything will be working great! It takes a while, like a couple minutes, but it´ll happen just fine!

And that´s just the neighbor command!

Next post we´ll talk about the other features presented in the VoD, like loopbacks, DR, and MTU... I really gotta go now!

Nice weekend to everybody, and don´t ever give up! Keep going on your studies (check this wonderful post from Ethan Banks about this).

Cheers!