Archive for the ‘hello’ tag
OSPF Notes – Neighbor States
My prediction about covering network types was wrong. I’m going to puke out some information about neighbor states for now. As is always the case, corrections are welcome.
Down : No hellos have been received from this router.
Attempt : This state only applies to manually-configured neighbors on an NBMA network. In this state, a router has sent unicast hellos to the neighbor but has not received any back from it.
Init : The router has received hellos, but none of the hellos have the router’s RID included as a known neighbor.
2way : The router has received hellos with its RID included. This means the other router has received the hellos from this router, so they now have 2-way communication going. The DR and BRD is elected at the end of this stage.
ExStart: When a router grows up and starts to have feelings for other routers, it enters the ExStart state to have further relations with a neighbor. This is where the master/slave relationship and the initial sequence numbers are established.
Exchange : Once we know who wears the pants in this relationship, the master sends over a DBD with it’s LSAs listed. In response, the slave does the same so that both routers have all the LSA headers they both know.
Loading : This is where the LSRs and LSUs flow. If a router need the full LSA from the neighbor, it sends an LSR, and the neighbor should send an LSU in response.
Full : After the LSR/LSU exchange, the routers should both be in sync, so they each send an LSAck to the other to confirm.
As a bonus, here’s a nifty little animation showing neighbor states.
OSPF Notes – LSA Types
Yes, it is inevitable that I cover these. I’m sure network types will be next. Per my usual request, please correct my stupidity.
Type 1 – Router : This LSA type lists all the routers by RID as well as the networks to which that router connects.
Type 2 – Network : These LSAs represent broadcast network where more than one OSPF router may live. Think Ethernet or multipoint segment. These LSAs are flooded by the DR for that segment.
Type 3 – Net Summary : An area border routers take the type 1s and 2s from one area and floods them as type 3s into another, so all of these LSAs are from other areas. No topology information is included in these LSAs; it’s basically an advertisement from the ABR saying the route is through him.
Type 4 – ASBR Summary : These LSAs make sure that all routers in all areas have a path to an ASBR that’s flooding type 5 LSAs. Those routes in the area with the ASBR won’t see these.
Type 5 – AS External : These are flooded by an autonomous system boundary router and are routes redistributed into OSPF from another routing process like EIGRP or BGP. Since these routes come from a different source, there’s no way to discover the topology past the ASBR, so we just have to trust the rumor that the network exists that way. E1 routes gets the OSPF path cost added as it crosses the network, while E2 routes (the default) have a static cost.
Type 6 – Group Membership : This is for Multicast OSPF and not supported by IOS
Type 7 – NSSA External : An ABSR in an NSSA floods routes to the external routing process through type 7 LSAs. ABRs will translate these to type 5s when flooding other areas.
Type 8 – External Attributes : Back in the day, OSPFv2 had plans to overthrow iBGP. Type 8 LSAs would have been used to carry BGP attributes while the routes themselves would be of type 5. Type 8s aren’t supported in IOS.
Type 9,10,11 – Opaque : Something…something…traffic engineering…blah, blah, blah.
OSPF Notes – Message Types
I have had my nose deep in several books in preparation for my CCIE R&S written exam, so I haven’t been blogging much at all. Now that I’ve made it to the more familiar topics, I’m hoping to get some notes posted. I’ll start with OSPF message types.
As always, please feel free to correct me here. I’m learning just like the rest of us.
Hello : These messages are used to establish neighbors and serve as keepalives among other things.
Destination: 224.0.0.5 Important Fields: Hello interval Dead interval Router priority (for DR election) Known DR Known BDR Active neighbors
Database Descriptor (DBD or DD) : These messages send summaries of a router’s known LSAs to a new neighbor. Receiving routers can use this information to compare to their database and ask for more details if needed.
Destination: Unicast IP of the new neighbor Important Fields: LSA header
Link State Request (LSR) : Once a router has received a DBD, it parses through the info in it to see if the message is either more up-to-date or if it has some new info in it (like a new network). If the router needs an update, it asks for the full LSA through an LSR.
Destination: Unicast IP of the router that sent the DBD Important Fields: LSA type LSA requested
Link State Update (LSU) : When a router receives an LSR, it responds with an LSU that contains the details information for the requested LSA. It also sends an unsolicited LSU whenever it learns of new LSAs such as when you turn up a new interface.
Destination: Unicast IP of the requesting router, 224.0.0.5, or 224.0.0.6 depending on who's updating whom Important Fields: LS age LS sequence number Full LSA
Link State Acknowledgement (LSAck) : If a router receives an LSU, it responds with an LSAck to acknowledge it was received.
Destination: 224.0.0.5 Important Fields: LS sequence number