EIGRP Fundamentals / Advanced in a can

I’ve integrated Chris Bryant’s ROUTE book on kindle into my study, as it follows the video series perfectly, and decided to go over the EIGRP section while doing the OSPF videos just to re-cover the topics, which made realize how much important information I did not post here. So this will be bullet points of the important facts of EIGRP (May follow with a similar OSPF in a can post):

  • EIGRP must agree on Autonomous System (AS) numbers and K Values (Metric Weights) to form a neighbor relationship, Hello / Hold timers and Subnet Mask are not considered, must also receive Hello’s from neighbor to keep adjacency up
  • Auto-summarization is on by default, this will summarize discontiguous networks at classful network boundary when being advertised by an interface that is not part of the network being summarized – “no auto” in router config to turn off
  • When entering a network into router config, no mask is needed, however if a mask is used it MUST be a wildcard mask
  • Hello packets are multicast to 224.0.0.10 to maintain neighbor relationships, every 5 seconds on fast links (Ethernet, T1, ISDN PRI, point-to point Frame-Relay and ATM links, etc, and every 60 seconds on slower links such as Serial links, Frame-Relay multipoint interfaces, ATM SVI’s, ISDN BRI’s, and link speeds under T1
  • Hold timers will be 3 times the Hello value by default (15 for fast link, 180 on slow links), when a Hello is recv’d it refreshes the Hold time to it’s maximum value, if no Hello is recv’d before the Hold time expires the neighbor is considered down, if a Hold timer misses its expected Hello (showing Hold time under 10 seconds on Ethernet segment) something is wrong, can view Hold time with “show ip eigrp nei” and Hello time with “show ip proto” and debug this (and most EIGRP issues) with “debug eigrp packet”
  • By Default, EIGRP uses Bandwidth and Delay (K Values) to calculate metrics
  • EIGRP uses Successor and Feasible Successor routes, Successors are best routes (Metric wise) to a destination, while a Feasible Successor is a loop-free backup route
  • Feasible Distance is the total metric to a network from the local router, Advertised / Reported Distance is the metric to that destination from the next hop router
  • EIGRP uses 3 tables for routes and neighbor info: Route, Topology, and Neighbor
  • Route table (“show ip route eigrp”) populated with Successor Routes to networks, shown in the format of Admin Distance / Metric (Feasible Distance): [90/2297856]
  • Topology table (“show ip eigrp top”) holds Successor and Feasible Successor routes, so if the Successor route becomes unavailable, the Feasible Successor (route with higher metric than the Successor but is loop-free; see Feasibility Condition below) can be injected to the Route table immediately for rapid convergence, shown in format of Feasible Distance / Advertised (or Reported) Distance: [22997856/128256]
  • Neighbor table (“show ip eigrp nei”) to view neighbor details such as local interface receiving hello’s, timer info, peer IP address, and other values for troubleshooting
  • Feasibility Condition at its simplest: If a route’s Advertised Distance (or RD) is less than the Successor Routes Feasible Distance, that route is considered a valid and loop-free Feasible Successor and is placed in the Topology table
  • EIGRP will perform equal-cost load balancing up to 4 paths by default, with a maximum of 16 paths, if the FD is the same for each path to the destination network (Variance command is used for Unequal-Cost load balancing), “maximum-paths 1” command in router configuration mode to turn of equal-cost load balancing
  • Routes must meet Feasibility Condition to participate in Unequal-Cost load balancing or to be placed in the Topology table at all
  • To perform Unequal-Cost load balancing, use command “variance x” in router configuration, where x is an ‘invisible’ multiplier of acceptable routes to be put in the Route table to a destination, so “variance 2” will allow Feasible Successors with up to twice the Successors Metric or FD into the route table to perform Unequal-Cost LB, the impact being ‘invisible’ because the route brought in will retain its metric, and the only way to confirm the FS should be in the route table is “show ip proto” and check the Variance #, the # used is also very important to keep unwanted Feasible Successors out of the Route Table  ***IMPORTANT CONCEPT***
  • Variance will change Feasible Successors to Successors in Topology table, but will show as a secondary route in the EIGRP Route table to a destination network, and is ‘all or none’ in that it will bring in all qualified FS routes when configured, to disable Variance set “variance 1” in router configuration
  • ***Traffic generated by a router is NOT load balanced, only pass-thru traffic***
  • “traffic-share min across-interfaces” command in router configuration will force EIGRP to send data only over a single best path (minimum metric)
  • In the Topology table, there are two main states, Active and Passive, Passive=Good
  • If a Successor route is lost and no Feasible Successor exists in the Topology table, it is put into ‘Active’ while DUAL runs, sending Query packets on 224.0.0.10 via RTP to all EIGRP neighbors requesting a new loop-free route to the network, if no neighbors have a route they all ask their neighbors, and the process continues until a neighbor replies with a route or there are no more neighbors left to ask
  • A ‘Passive’ route in the Topology table means the route is stable, and good to go
  • ‘Stuck in Active’ (SIA) is a state a route will be put in if a replacement route is not found through Query’s before the active timer expires (Active Timer is 3 minutes by default), can be changed in router config with “timers active-timers #” set in minutes for #, must cannot set minute value to 0 to disable, must use “timers active-timers disabled” to turn off Active Timer entirely
  • Four main reason a route will become SIA: Link is Unidirectional so the Query cannot be answered, the Queried router is unavailable due to resources (High CPU Utilization), the Queried routers memory is corrupt and is unable to answer the Query, Link is low speed and just good enough to keep adjacency up but not respond to Query requests from upstream routers
  • EIGRP uses Reliable Transport Protocol (RTP) sends packets “reliably” to neighbors, which sounds like TCP, but it does not work like TCP (not all packets are reliable), the 5 packet types sent are as follows:
  • ‘Hello Packets’ are used to discover new neighbors, keep relationships alive, multicast to 224.0.0.10
  • ‘Acknowledgement’ packets are ‘Hello’ packets containing no data
  • Neither Hello’s or Ack’s use RTP – And are therefor considered unreliable
  • ‘Update’ packets are sent to new neighbors to allow the neighbor to build an accurate Route and Topology table, and when existing neighbors detect network changes – ‘Update packets exchanged between new neighbors are Unicast, while updates sent to existing neighbors upon detecting a route network change are multicast to 224.0.0.10 – ***Unicast Updates between new neighbors important point***
  • ‘Query’ packets are sent when a router loses a Successor with no FS route
  • ‘Reply’ packets are sent in response to a Query packet when a new route is found
  • Update, Query, and Reply packets use RTP and are there considered reliable
  • “show ip eigrp traffic” to see the statistics of all EIGRP packet types, if Query / Reply / Update packets are incrementing regularly you have a network problem
  • Neighbor forming process: R1 sends Hello – R2 responds with (Unicast) EIGRP Update packet if AS # and K Values are agreed upon – R1 responds to R2’s Update packet with an EIGRP Ack and Update Packet (Unicast) – R2 responds with a final EIGRP Ack packet and the neighbor relationship is formed
  • “ip [hello / hold] eigrp (AS) #” on the interface level to change Hello and Hold timers
  • K Values (Metric) 1-5: Bandwidth, Load, Delay, Reliability, Reliability Modifier
  • “metric weights 0 1 0 1 0 0″ in router config is used to modify the K Values used to calculate metric, with the bold/underline 0 being an odd ToS config that is required in the command and can only be 0, the exmaple 5 k values of 10100 are the default K Values for EIGRP (BandWidth and Delay)
  • Neighbor table values under the specified columns, from left to right:
  • H = Order in which neighbor was discovered
  • Address = The IP Address of the neighbor
  • Interface = Local interface receiving neighbor Hello’s
  • Hold = Time router will wait until declaring a neighbor adjacency dead (counts down)
  • Uptime = Amount of time since neighbor relationship was first formed
  • SRTT = Smooth Round Trip Time, amount of milliseconds it takes to send a packet to the neighbor and receive an Ack back
  • RTO = Retransmission TimeOut, time until retransmitting a packet to a neighbor
  • Q Cnt = Queue Count, # of EIGRP packets waiting to be sent
  • Seq Num = Seqence # of the last update / reply / query packet from neighbor
  • To debug neighbor adjacencies, use “debug eigrp nei”, or for a single neighbor “debug ip eigrp (AS) (Neighbor IP address)” (Only debug for a specific neighbors uses ‘ip’ after debug in its command *** VERY IMPORTANT TO NOTE***
  • Neighbors can be formed using an interfaces ‘Secondary IP Address’, by entering the secondary address in router config, though the neighbor relationship will still use that interfaces Primary IP address
  • “ip address 23.23.23.1 255.255.255.0 secondary” on interface to configure Secondary IP Address, then “network 23.23.23.0 0.0.0.255” in router config to add network
  • EIGRP has 3 Administrative Distances: EIGRP Internal route [90], EIGRP external route [170], and EIGRP Summary route [5]
  • Internal routes are learned via configuring in router configuration with “network” command and advertised to neighbors
  • External routes are learned via Redistribution of connected or static routes, as well as routes from other protocols, set in router configuration with command “redistribute connected” or “redistribute …” to redistribute other route types
  • To change Admin Distances for EIGRP routes on the local router, use “distance eigrp # #” where the first # is for Internal EIGRP route admin distance, the second # is for external routes – Must configure both but can enter the same value as default AD to retain the original AD of either route type
  • Manual Route Summarization begins with writing out all networks to be summarized in binary, then work from left to right and identify the common network bits, and any bits that are not common among all networks to be summarized will make up the Summary Route network mask, ex: Networks 100.1.0.0/16 – 100.7.0.0/16 written out in binary and Summarized will result in 100.0.0.0/13 **IMPORTANT CONCEPT**
  • First enter the networks into router configuration mode with “network …” command, then on the interface to advertise the summary route, use the command “ip summary-address eigrp (AS) 100.0.0.0 255.248.0.0”, this will drop neighbor relationships, when they come back up they will contain summary routes
  • On the router with the summary route, the summary route will show in the Route table is seen as a route to Null0, so if a packet comes in that doesn’t match one of the more specific network numbers it is discarded, as the router doing manual summarization will still have the more specific routes in it’s table – Route to Null0 will only be seen on the router performing manual summarization
  • The AD 5 will be seen only with “show ip route 100.0.0.0 255.248.0.0” or “show run” on the router doing summarization, remote routers will show “… is a summary route” in their route table where the Admin Distance should be
  • The best point is EIGRP networks to configure Manual Summarization is on ASBR (Autonomous System Boarder Routers) routers to be most efficient
  • Adjusting bandwidth on different interface types:
  • Single physical interface: Add all VC’s bandwidth together, and set “bandwidth x” where x is the total bandwidth across all VC’s connecting to that single interface
  • Point-to-Point Sub-Interfaces: Set Bandwidth on each indivudual sub-interface
  • Multipoint Sub-Interface: Add all VC’s bandwidth up and set the total bandwidth on the multipoint sub-interface
  • By default, EIGRP traffic will only use 50% of an interfaces set bandwidth, can be adjusted directly on the interface by issuing “ip bandwidth-percent eigrp (AS) (BW %)” – The percentage can be set above 100% in case the physical interface BW exceeds what it is logically set to
  • Stub Routing for EIGRP is done by configuring ‘Stub Routers’ by using the “eigrp stub” command in router configuration mode, unlike OSPF that uses different types of ‘Stub Areas’, it is configured on the ‘end of line’ routers, or routers that otherwise have no upstream neighbors to Query for routes via DUAL, so there is no need for it to receive Query requests, hence it being a ‘Stub’
  • By Default, only connected and Summary routes are advertised by a Stub Router, though route types to be advertised can be adjusted in router configuration with “eigrp stub …” command
  • Passive interfaces are used when you do not want an Interface sending any EIGRP related traffic, it does this by preventing that interface from sending Hello’s which means no adjacencies will form over that interface, therefor no other EIGRP traffic will be sent through the Passive interface (Updates, Query’s, etc.) There are two different options to configure passive interfaces:
  • Option 1: “passive-interface default” in router configuration makes all EIGRP enabled interfaces on the router passive, then use “no passive-interface s0/1” to disable for a single interface, “no passive-interface default” to disable globally
  • Option 2: “passive-interface s0/1” in router configuration mode to make a single EIGRP enabled interface passive while leaving all others non-passive
  • To Redistribute a static route via EIGRP, must create the static route with “ip route 0.0.0.0 0.0.0.0 s0/1” command and then “redistribute static …” in router configuration to advertise the default-gateway to EIGRP neighbors – Note that default information-originate is for OSPF, not available in EIGRP
  • “network 0.0.0.0” in router configuration will also propagate a default route to downstream routers with an EIGRP Admin Distance of 90 for an Internal route rather than 170 for an External / Redistributed route
  • “ip default-network 10.0.0.0” is another way to redistribute a non-zero (all zeros) default gateway address to EIGRP neighbors, configured in global config NOT router config, MUST have the network being advertised in route table as well as router configs via the network command (<- Need to verify route needs to be config’d in EIGRP), IOS 15.x+ will continue to show “No gateway of last resort set”, the command has several known bugs discussed in Cisco forums
  • Authentication between EIGRP niehgbors prevents undesired / rogue routers from becoming an EIGRP neighbor
  • EIGRP uses either clear text or MD5 Encryption, only encrypts passwords to authenticate neighbors but not traffic sent by EIGRP, the commands “key chain” and “key-chain” are both used in the configuration – “key chain” is used in the actual key chain configuration, “key-chain” is used when applying it to the interface – Know the difference of where those two are at!
  • Authentication configs below ***IMPORTANT REFERENCE***
  • R1(config)”key chain (name)” in global config to assign key chain name and start configuration of the keys for this key chain
  • R1(config-keychain)”key #” in keychain config to set the key # to configure
  • R1(config-keychain-key)”key-string (Password)” in key config to set password used by neighbors to authenticate to eachother
  • “ip authentication mode eigrp (AS) md5” on interface config of the interface that needs to be configured to authenticate with it’s peer(s)
  • “ip authentication key-chain eigrp (AS) (key chain name)” on interface config, **NOTE** that the key chain name is the name of the key chain itself and not the password that is set on specific keys, this is because different keys can be or ‘accepted’ at different times with the commands as follow
  • R1(config-keychain-key)”accept-lifetime 00:00:00 Jan 1 2016 infinite”
  • R1(config-keychain-key)”send-lifetime 00:00:00 Jan 1 2016 infinite” Are examples of the commands in the actual key configuration to set when a neighbor will send or accept authentication using a particular key on the key chain it is sub-configured under

 

AND THAT IS ALL THERE IS TO EIGRP (for now), PIECE OF CAKE!

(That compilation of accurate information was a LOT of freegin work)

Finished OSPF Fundamentals, onto Advanced Concepts

The last couple of videos were actually really quick, and to this point, really easy to digest after going through a condensed version of all the CCNA material.

The bandwidth command issued on the interface, is another way of adjusting in my mind basically the OSPF Cost, only it isn’t specific to OSPF so it will cause other mechanisms like QoS or other routing protocols to crash and burn if configured incorrectly.

OSPF Cost is calculated by [Reference Bandwidth/Interface Bandwidth], with the default Reference Bandwidth being 100, which works fine for calculating cost until you get above a FastEthernet interface like for example a GigEthernet interface.

The reason being for FastEthernet it would be calculated as 100/100 giving you an interface cost of 1, but being GigEthernet would be calculated as 100/1000 by default, it should give you 0.1 as an interface Cost – But OSPF does not do decimals with interface Cost!

So if you set the Reference Bandwidth in router configuration with the command “auto-cost reference-bandwidth (#)” then you will change the first value in the equation, which can help make the Cost more affective so you are not load balancing traffic over a FastEthernet and a GigEthernet interface. So if you enter “auto-cost reference-bandwidth 1000” the equations change, respectively to 1000/100 (Cost 10) for FastEthernet and 1000/1000 (Cost 1) for GigEthernet. One important note on using this method of changing cost is to be consistent with changing it on every OSPF router to match, or you may cause some bells and whistles to start alarming pretty rapidly.

Method two is to change the Interface Bandwidth, or the second value in that equation, which again is done directly on the interface with the command “bandwidth #” (in kbps), which will dynamically change the cost shown with “show ip ospf int S0/0” for example.

These are fine and good for knowledge sake, given the third option will override any changing of the cost on a specific interface I believe it is the best option, but for exam purposes of course all 3 need to be known. It is simply “ip ospf cost #” on the interface, and that is it.

One last thing to touch on before taking the night off is 4 routers on a broadcast OSPF enabled segment, and the odd behavior it causes, but only odd if you are not prepared for it! The 4 routers will go through the election process, two will become DR / BDR, the other two will become DROthers. Now when you do a “show ip eigrp nei” from either of the DROthers, you will find that their State stops at 2-way with the other DROther. This is because no two DROthers will form full adjacencies with eachother, unless the DR or BDR goes down, however they will continue to send Hello’s and their Dead timers should not drop below 30 seconds (on an Ethernet segment).

This doesn’t seem like a huge point to drive home, but there is a thing called “Stuck in 2-way” that exists with OSPF, and the above situation IS NOT STUCK IN 2-WAY <- That is very important to know. This is an expected behavior between DROther routers on any broadcast network with 4+ routers in the OSPF domain, and is not an issue.

With that I will be starting on Advanced topics such as Stub Area’s, LSA types, and all the other magic of OSPF!

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*