OSPF Adjacency / Neighbor formation states

This is a completely not fun, dry, and hard to remember list of how two routers become neighbors / form an adjacency in order of what happens. I am typing it here purely for future reference, so if you are looking for an intriguing perspective on something, probably want to look read another post:

  1. Init – First Hello received from remote router
  2. 2-Way – Each router has received a Hello containing it’s own RID, indicating bi-directional communication, getting it’s own RID from the remote router as a sort of receipt that a Hello was received by the remote router from the local
  3. Exstart – Following the DR / BDR election, the router with the highest RID will begin the exchange of the initial sequence number and increment during this stage
  4. Exchange – Database Descriptor (DBD) packets are exchanged, which contain LSA headers only to describe the senders LS Database, so the sequence number can be compared to the local sequence number, and updated by the DR if necessary
  5. Loading – Routers send Link State Requests (LSR) packets to the now almost neighbors
  6. Full – Routers are synched, adjacency is formed

These states can be found with “show ip ospf nei”, the ‘State’ being the first value in the brackets, the second being the ‘Role’ of the router. Here are a listing of the roles:

DR – Designated Router via the initial election process of OSPF speaking routers, once elected it stays DR until a reload is done or ‘clear ip ospf process’, acts as the “Master” of OSPF updates in terms of maintaining the most current sequence number / LS Database and updating other OSPF enabled routers via Multicast to 224.0.0.5 (All OSPF routers address) if it receives an update with a higher sequence number than it currently has, elected via highest RID which is takes precedence in the follow order: “router-id” command, highest IP Addy on loopback interface, highest IP addy on physical interface – DOES NOT NEED TO BE OSPF ENABLED INTERFACE FOR IP TO BE USED AS RID FOR OSPF ELECTION.

BDR – Backup Designated Router, keeps an up to date routing table, does not perform any functions of the DR but does listen on the “All Designated Routers” multicast address of 224.0.0.6 for LS Database updates. Only the DR and BDR listen to this IP for Link State updates.

DROther – Non-DR / BDR routers

**Interface priority will win the DR / BDR election before IP addy’s are considered, so raising this priority can ‘rig’ election to either ensure a router is elected, or if it is changed to priority 0 the router will not participate in election.**

I will need to add or edit this, or include some more details in an upcoming post on OSPF fundamentals, but wanted to get this posted now so I can move onto new topics in my next post. Writing a conclusive article on the basics of OSPF that is under 30 pages seems like it may be a difficult task, so I’ll probably just pick the more important topics that will be needed for test time, as I’d rather be able to answer questions on theory than burn it into my brain, and save the brain for labbing and understanding configuration and troubleshooting 🙂

OSPF Virtual-Links, Cabling

Really quick post tonight just to re-hash some of the material I already covered but haven’t posted about, and finally got my virtual link in Area 34 which is an Ethernet segment off the Fa0/0 of both R3 and R4 off the usual Hub-and-Spoke NBMA network. This is achieved by going into the Router Configuration mode, and enter “area 34 virtual-link x.x.x.x” where x.x.x.x is the remote routers RID.

Also, the router that you are creating the virtual link towards to bring it’s network into the ‘backbone area / grouping’ must not have an interface in Area 0, again this cannot be a Backbone router (that I have been made aware of yet) – This may be an important point to keep in mind.

The virtual link is a way of including a network on a non-backbone router (non Area-0) into the backbone router grouping (not sure if that is the correct word), and allow it to propagate it’s network to the rest of the OSPF routers.

Kind of odd that the router does not treat virtual-links as for example a Loopback interface, as I keep getting muddled typing ‘show ip int …’ which does not show virtual links, the actual command is “show ip ospf virtual-links” from User Exec mode.

Another odd but logical behavior that it appears as a second Adjacency / Neighbor when running ‘show ip ospf nei’:

R4#show ip ospf nei

Neighbor ID     Pri   State           Dead Time   Address         Interface
3.3.3.3           0   FULL/  –           –        172.12.34.3     OSPF_VL2
3.3.3.3           1   FULL/BDR        00:00:31    172.12.34.3     FastEthernet0/0

One final thought, I tripped on this so hard and its eaten up so much time, but I learned the hard way that an interface that shows the following output can be a bad / incorrect cable: FastEthernet0/0 is up, line protocol is down

I pulled the cable from another working link I originally was using, but of course in my wisdom I didn’t check the cable before plugging it in (or did and just honestly didn’t see it was incorrect), and I thought if there was a complete mismatch of a cable type it would have shown down / down. This really put my study on the back burner for a couple days there as I only try to study on work days and take weekends off, so I found this today, and moving forward I will keep in mind this is in fact a physical lab with physical issues.

I was going to go over some material I’ve already covered such as cost, adding ethernet (broadcast) segments, etc, but I will wait until I cover the bandwidth video and hopefully actually tank to the end of OSPF Fundamentals and prepare to crack into the Advanced OSPF videos – Cannot wait 🙂

Finishing EIGRP (for now), Starting OSPF

So after such a long break from studying, I am finding I am way out of practice, and trying to stretch my studying across too many materials is slowing things down to a complete stop – So I decided I am going to put the ROUTE Simplified book down for now, and go through it in it’s entirety after going through the Chris Bryant video series – I just absolutely love that guys dry sense of humor. I’ve tried INE’s CCNP course for a video, and I cannot get into the instructors teaching style at all, which is a shame cause I thought Mark Snow did an excellent job with his CCNA Voice course he offered free on INE.

Anyhow, I was working with default route redistribution, and found myself getting brick walled working with the “ip default network” command. I was adjusting ip route statements, adding and removing the default route to be redistributed in router configuration, and it just was not propagating to my two spoke routers – I even turned on R4 for this that connects off R1’s Serial0/1 interface. So I’ve had no problem using the “redistribute static …” in router configuration to propagate default routes to the spokes, but I just couldn’t crack the ip default network command. After spending enough times reading Cisco documentation on it and looking at forums, it seemed like there were too many reports of it working weird or buggy in certain IOS versions (some version of 15.x code I believe?), and I’m running mostly variations of 12.4 code on my routers. So admittedly the buggy behavior may not be affecting my IOS versions, but it was just stopped forward progress with studying so I skipped over it and moved on to the final parts of EIGRP – Stub configurations / Interface Authentication.

Stub networks I felt was just glossed over in my video series, so I am hoping the ROUTE Simplified goes more in depth with this topic, because I can configure it (I believe) correctly and maintain all adjacencies to EIGRP neighbors but I fail to really grasp why you would even bother making an EIGRP router a stub. I moved from this topic after configuring it and understanding theoretically why one would use Stub routing, but I fail to see why you wouldn’t just set a default route back to the Hub router and call it a day for more practical purposes? I feel like I may not be really digging into that topic as much as I should, but it was covered so briefly I am not sure how much that mattered, so I just continued on to authentication.

When I was configuring key chain Authentication on my lab Friday I wasn’t even looking at notes as to which debugs to run to see what was going on, or looking back to see the syntax for the interface level “ip authentication mode… ” and “ip authentication key-chain …” commands, which reaffirms covering the CCNA material over the winter did pay off… somewhat. I actually had trouble getting the neighbors to drop the adjacency as expected when a key was mismatched or not present on that interface, this was my one hang up, but I pretty quickly found that I had just skipped over the above mentioned “ip authentication mode …” command that is also required on the interface to ‘activate’ the authentication.

I’ve already gone over, and heavily noted, the base theories of OSPF in my video course. Particularly things like how DR / BDR elections use the highest interface Priority first to elect a DR / BDR, followed by the highest loopback, then physical interface, unless you enter the “router-id x.x.x.x” command in router configuration mode to manually set the RID which will take precedence over Loopback and Physical interface IP’s (but DOES NOT override interface Priority in election process).

Though some finer points in the theory and operation of elections and updates for example is that topology changes are multicast to 224.0.0.6 that only the DR and BDR listen by the router detecting the change, they run the SPF algorithm against their OSPF database, then another update multicast of LSU’s containing the LSA are sent to 224.0.0.5 which is an “All OSPF” listening address by the DR while the BDR just updates itself hoping to some day get promoted to that DR Role (though we don’t want that)! Another thing I had either forgotten or was not covered, is that the DROther (non-DR / BDR OSPF routers) send back an LSAck (LSAcknowledge) back to the DR as a receipt or confirmation that the update was received.

Now to get to backing up those running configs, resetting the routers, and then I am done with CCNP related things for the night! Time to get some OSPF going on and I will no longer have to work with sub-interfaces to avoid split horizon hampering my propagation, I don’t know what I’m going to do with myself working with .1 / .2 / .3 again for my WAN IP addresses!

Big update there, I admittedly don’t get on here the day of studying like I am going to try as I venture into murkier waters of BGP, Redistribution, and IPv6, but I shall be back to keep this party train moving forward to finally earn that CCNP I set out to earn years ago!

ROUTE Simplified – Overview stuff, ODR

Instead of labbing my remaining topics for EIGRP from my Chris Bryant video series, as I am too mentally tired to lab into all hours of the night, so instead I started reading Chapter 1 of ROUTE Simplified. I must say, given the size and weight of this book, it has to be by far the most ironic Cisco based book ever created (Its about the size and weight of a cinder block).

So I plan to finish labbing Stub routing / static route redist / Key Chain authentication between EIGRP routers, but before moving onto OSPF videos, I think I am going to read through the EIGRP section of this book to see how it compares to the video content.

I am fried so a couple main points I took away from Chapter 1, which just overviews the coming chapters / concepts, which made me want to skip over it due to my lack of mental capacity recently after work – But I found some gems of just basics I wanted to document quick:

  • Administrative Distance determines what route to a network will be put into the route table if it receives multiple paths from different protocols, route Prefix length selects the best route from the table to that network based on how far the prefix length matches
  • Hierarchical routing consists of routers in logical groupings that can exchange information, making it more scalable with less administrative overhead (OSPF, EIGRP, etc)
  • Flat routing consists of generally routers all physically connected to eachother, network changes can impact all sides of the network, and is not scalable
  • Route Summarization has a very low AD of 5, being extremely dependable, because all more specific routes from the summary all need to be flapping for the route to flap / fail
  • ODR (On Demand Routing) is what I thought was the Layer 3 equivalent to a Frame-Relay SVC, where traffic can be routed as needed by a 3rd party, but will be charged

And On Demand Routing is actually where my brain fried and I had to bookmark it, but before I blew the fuse I got into some interesting details. It is basically an enhanced equivalent to CDP (Cisco Discovery Protocol), that operates at Layer 2, and will advertise the connected subnet on a Spoke router back to the Hub AS LONG AS NO DYNAMIC ROUTING PROTOCOL IS CONFIGURED ON THE SPOKE!!! (VERY Important note!)

However, the Hub router can run dynamic protocols in conjunction with using ODR, so it can redistribute routes learned via ODR into routing protocols such as OSPF and EIGRP. This can be particularly useful (info probably outdated) for low-speed WAN links, where updates and hellos are considerable data overhead, whereas ODR updates are considerably smaller but can still share route(s?) back to the Hub.

This is where I had to stop, as I was starting to barely write out my notes, which means I’ve hit my mental limit and I want to be fresh to wrap my head around this concept as I have a hub and spoke lab setup right now for EIGRP over Frame-Relay.

So I will try to lab the above mentioned EIGRP topics over the weekend and hammer out any ‘gotchas’ I find, then I will be back onto reading on ODR and deeper into ROUTE simplified.

EIGRP Basics to Advanced overview

 

FrameRelay_EIGRP_Topology

 

Above is a rough drawing in paint of my current topology I have worked through the Advanced EIGRP section with, Frame-Relay NBMA Hub-and-Spoke WAN, and Fast Ethernet LAN segment to make things… more interesting to troubleshoot.

It does not of course show all the configurations changes, summary routes, and things that have been broken then fixed then broken again on it 🙂

I am just starting this now at the tail end of my Advanced EIGRP section of Chris Bryants video series, so unfortunately I can’t re-live my daily struggles on the live equipment I have been dealing with, but it has been an uphill battle.

I’ve put together a bare bones config for my routers and switch for the LAN segment of my network in saved notepad docs for a quick startup which was fairly easy, then when putting in the EIGRP configs on top of that, I didn’t realize the battle I was about to wage with understanding Hub-And-Spoke NBMA networks and how they do not like interfaces forming LAN adjacencies while also trying to to have the Serial interfaces of the spokes form an Adjaceny back to the Hub configured with S0/0 as two sub interfaces so Split Horizon isn’t blocking route advertisement.

I will save the trials and tribulations, debugs and show output here, but somewhere on a message board there is miles of output from this issue – It was ugly.

I had forgot some very core principles of EIGRP during configs, one major one being that subnet masks do not need to match to form an adjacency, but if for an example a point-to-point sub-interface is 172.12.123.5 255.255.255.252, the downstream mask can be a /24 but it’s IP address better be in the same subnet as the upstream interface (172.12.123.6 255.255.255.0) or they are not going to be neighborinos.

When I had first configured my topology which is a little hazy prior to all the troubleshooting, I did not sub-interface the Hub, yet routes were still propagating which I believe was happening over the LAN as Split Horizon would have been preventing it on my “WAN.” I believe that is where a lot of the confusion came in, is once I configured the hub with the sub-interfaces, it immediately started causing problems on the spokes and dropping the adjacency from R3 up to R1.

I did have a 3560 as my switch LAN when all these problems started, and was unsure if some default behavior was causing the issues, so I put in the 2950 Layer 2 switch which sort of introduced a new set of issues which are now resolved. So my next step before launching into OSPF Basics and Advanced concepts is to put the 3560 back in and see what problems that possibly reintroduces, and put away some of the EIGRP material in my ROUTE Simplified book to get a better understanding of what mechanisms were causing the adjacencies to drop in different parts of the network.

Now that I am off work and figured that out I am about ready to fall over brain dead, so I shall update on the struggle (if any) with putting the 3560 back into the mix, and my thoughts of any important details I may want to have on here to relive some day.

*thump*

Tech notes for Tech folks!