CCIE Topic: 1.4a OSPF Adjacencies

hey everyone charles judd here we're moving into the next section of the ccie blueprints covering ospf and the first thing to examine is the 1.4a topic of ospf adjacencies i'll cover the different ospf states and i'll use wireshark to capture our ospf traffic in a lab and take a look at those packets more closely when performing an ospf adjacency ospf goes through several state changes which we'll look at with wireshark in just a bit but first let's describe all of those states the first one is the down state this means that we've configured ospf on a router but no hello packets have been received from a neighbor but a router in the downstate can still send hello packets out to a neighbor if we have a full adjacency and we stop receiving ospf packets to the point where our dead interval reaches zero then ospf will move back to this down state next is a special state only valid for manually configured nbma neighbors called the attempt state here a router will send unicast hello packets to a manually configured neighbor when no hello messages have been received within the dead interval the next state is the init state which is the state when a router has received a hello packet from a neighbor but our own router id was not included in that packet the reason we're looking for our own router id in that packet is that it indicates we have bi-directional communication when a router receives a hello packet from a neighbor the router will take the sending router's router id and add that into its own hello packet as an acknowledgement once the router does start seeing its own router id in those neighbor hello packets that means that we have bi-directional communication between our routers and so ospf moves into the two-way state this means our routers are seeing each other's hello packets and they're acknowledging that by echoing back the neighbor router's router id at this point the dr and bdr election also takes place the designated router and the backup designated router once these are elected we move to the x start state this is where ospf routers establish a master slave relationship with a router with the highest router id will become the master device this is established on a per-neighbor basis and by the way this relationship has nothing to do with the dr and bdr election this is a completely separate process serving a completely separate purpose it's entirely possible that the bdr could play the role of the master this mechanism is essentially used as an acknowledgment system where the master is used to set an initial sequence number and the master is also responsible for incrementing the sequence number after this we move to the exchange state where our ospf routers exchange dbd packets database descriptor packets these contain lsa headers and they describe the contents of the entire link state database so they are essentially a summary of our link state database each of these dvd packets has a sequence number and that's set and incremented again by the master as we just discussed the contents of the dvd are compared to the information the router already knows about in its local link state database and it does that in order to determine if more current link state information is available next we have the loading state this is where the actual exchange of link state information occurs based on the information found in the dvd packets routers will send link state request packets to appear any outdated or missing lsas would be requested through these link state request packets the neighbor will respond with link state update packets providing the requested information also all of our links state requests and update packets are required to be acknowledged by the neighbor as well and finally we have the full state where routers have formed a full adjacency with each other once all of the lsas are exchanged between the peers and everything is acknowledged then our databases are synchronized and this is the state that we want to see if we see a router stuck in any other state this is an indication that we're having trouble forming a full adjacency so let's take a look at this in a topology and we'll use wireshark to see our different ospf states i have a couple of routers interconnected here i've already got ip addressing configured and i have wireshark running filtering the capture output to only show ospf packets on the gig 0 0 interface of router 1. i did that just to keep things a little more clear as we're examining our wireshark capture so let's configure ospf let's start on router one and let's say router ospf one let's say router hyphen id i'll make that 1.1.1.1 i'll say network 10.1.1.0 area 0. and as soon as i do that you're going to notice that we see a hello packet come into our wireshark capture and you'll see that these are going to be happening at roughly every 10 seconds they're happening at 10 second intervals 10 seconds of course being our default hello interval in ospf you can see the destination of 224.0.0.5 which is the multicast address used with ospf to send and receive hello packets so at the moment we are in the down state i'll just expand our ospf packet at the bottom you can see the source ospf router id 1.1.1.1 you can see that this is a hello packet and from here you can also see the hello interval of 10 seconds and our dead interval of 40 seconds both default values so let's go over now to router 2. let's configure ospf on that side as well let's say router ospf 1 router hyphen id 2.2.2.2 network 10.1.1.0 area 0 and we're going to see our adjacency form we'll see that happen in our console as well as in our wireshark capture so we'll give that just a moment for that to happen see that happen let's break out let's say show ipospf neighbor and you can see that we are in the full state exactly what we'd want to see so i'm going to go ahead and stop my wireshark capture just so that we don't continue to have packets come in there and we'll take a look at what we've captured now now one interesting thing i'll point out right off the bat is if we look in our show ipospf output you'll see that we have a full adjacency with router 1 and we're told in this output that router 1 is the designated router it's the dr if you're familiar with dr and bdr election you'll realize that with the default priority values in place those are all the same and based on the router ids that i've configured r2 has the higher router id and that should actually be the dr why is this the case that router 1 has determined it's the dr well it's because of the time that i took to configure r2 r1 was waiting and waiting and eventually it elected itself as the dr ospf dr election is what we call non-preemptive this means that even if we change the priorities or the router ids so that other routers have better preference the current dr is not going to change this is opposed to a protocol such as spanning tree which is preemptive and it will make changes to elected bridges we can correct this by clearing our ospf process so let's do that let's jump over to router one let's say clear ip ospf process say yes to reset those we're going to see our adjacency reset see that loading is done so now if we say show ip ospf neighbor this time from router 1 we have again a full adjacency but we're told that now router 2 is the designated router as we would expect and r1 has become the bdr so this is just an interesting situation that you might run across so i did want to explain that and i wanted to explain the non-preemptive condition that you might potentially see i'll also point out that point-to-point ospf networks do not require a dr and a bdr so even though we have a couple of devices connected point-to-point here i'm using ethernet and the default network type for that in ospf is broadcast and broadcast will elect a dr and a bdr we'll talk about this a little bit more in the next video when we look at ospf network types let's jump over and look at our packet capture now so if we go to let's scroll back up to the top and we go to the very last hello packet that we sent before we started receiving hellos from r2 we see that here packet number 85 we see the source of 10.1.1.1 going out to our multicast destination if we look inside that packet again we see our source ospf router id 1.1.1.1 which is router 1. we see we're in area 0 listed as a backbone area we see our network mask our hello interval of 10 seconds the dead interval of 40 seconds and we see that we have made ourselves the dr at that point and there's no backup designated router listed in there the very next packet number 86 if we look at that we can see that the source of this packet is 10.1.1.2 so at this point we've configured r2 for ospf we have moved into the init state we've received a hello packet from router 2. but if you look inside that we see a lot of the same things here we see the source of 2.2.2.2 but we don't have router 1's id listed inside this packet we see our source id again we see our area all the things we would expect to see but this packet does not have r1's router id inside that's what indicates that we are in the init state we see that router 2 also doesn't know anything about the dr or bdr election just yet so again router 1's information is not in this packet so after router 1 receives this hello packet it's going to have awareness of a neighbor it's going to have awareness of router 2 and then it's going to start embedding the neighbor's router id within its own hello packet and in fact if we go down to our very next hello packet sourced from 10.1.1.1 you'll see that we now have a new field an active neighbor listing and it's listed that id as 2.2.2.2 which is of course router 2. so now we've moved into the two-way state and we've established bi-directional communication you might notice the very next packet is a db description a database description packet that we've received from our neighbor receiving one of these will also cause a router in the init state to transition to the two-way state as well if we go down to the very next hello packet we see that r2 is doing the same thing as r1 we see that r2 now also has the active neighbor field and it knows about router 1 at 1.1.1.1 and we see both the designated router and the backup designated router listed here the election of the dr and the bdr means we are now in the x start state this state is where we are establishing our master slave relationship and establishing an initial sequence number for acknowledgements initially both routers are going to believe that they should be the master in fact if we go to this first database description packet from r2 and we expand some of these sections to take a look inside we can scroll down and you can see listed here r2 has a flag set saying yes i am the master device i think i'm the master device and just below that r2 has chosen 44.93 as the initial sequence number this is what router 2 wants to set the initial sequence number to for acknowledgement if we go to the db description packet below that coming from r1 we see that it also has a flag set saying i think i'm the master device and it has chosen a different sequence number 2712 that's what r1 wants to set the initial sequence number to so who's going to win well again the highest router id is going to win so you might be tempted to think that the dr will always be the master device but that's not necessarily true remember dr and bdr election takes into account our priority values while this acknowledgment mechanism does not so if we look at the very next dvd packet this is coming from r1 this time it has the flag set to no so this time it has submitted to router 2 and it's allowing router 2 to be the master device and r1 is echoing back the suggested starting sequence number 4493 if we go back to the previous db description packet from r2 you'll see the sequence number is 44.93 once r1 agrees that it is not the master device notice it sends back the same sequence number letting it know okay this is the sequence number that we're going to start with r2 will follow that up with a second db descriptor packet and notice that it is incremented to 44.94 now so now that the initial sequence number is set and we know which router is responsible for incrementing that sequence we move to the exchange state we're exchanging dvd packets and these contain our lsa headers in order to determine if more current link state information is available now we're moving into the loading state this is where the routers are exchanging link state information we see a link state request here from r1 if we go down we see a link state update sent out from r2 which is a response to the request from r1 and we see that happening in the opposite direction as well we see r2 sending out a link state request r1 providing an update once all of those lsas are exchanged and our databases are synced then we of course move into the full state we'll see some more of this syncing happening back and forth we see some acknowledgments as well and then we begin sending those hello packets again to ensure that we keep our adjacency up and of course we will still receive any necessary link state updates from our peers and we will continue to acknowledge those as well so that's a look at ospf adjacencies i hope you found this content useful and i want to thank you sincerely for watching

Channel: Charles Judd

Views: 1,344

Keywords: cisco, ccie, cisco enarsi, ccie enterprise infrastructure, cisco enarsi 300-410, cisco encor 350-401, ccie lab, my ccie journey, ccie training, ccie blueprint, section 1.4, 1.4 ospf, 1.4a ospf adjacencies, down state, init state, 2-way state, exstart state, exchange state, loading state, full state, dbd database description packets, link-state advertisement, link-state database, LSA, LSDB, wireshark

Id: 96_FQN754e8

Length: 15min 32sec (932 seconds)

Published: Mon Oct 12 2020