Category Archives: Uncategorized

Keith Bogarts (INE) Comparison chart of how Distribute-List’s work between different protocols!

Distribute-List

One again with Keith Bogarts permission he allowed me to post this up for other who do not have his course (which you should go grab a copy of), to demonstrate the differences of Distribute-List’s behaviors between protocols.

The list speaks for itself, and if you’ve learned these and forgotten exactly which protocol does what, this list is a perfect visual reminder. The one thing Keith did mention is that under BGP, the only thing not to know for CCNP ROUTE exam day is the last information under the BGP column – You won’t see that level of detail on the exam… I hope.

So wanted to just get this graphic up as Keith said it was cool for me to throw it up for others to review, again he teaches this exhaustively and very well in his course, so I’d advise buying it via the GNS3 store as you get 50% off the CCNP R/S bundle through there apparently.

Just google GNS3 store and purchase right through there, and it will redirect you to INE’s website with the coupon code already applied, and for $200 for Keiths training its a steal!

NTP: Demonstrated between 2 routers running IOS 15.x to demonstrate NTPv4 Authentication and other concepts! (Edited with more content 5/20/17)

NTPAs I only have two routers in my lab running IOS 15.x, and 12.x is not NTPv4 capable, I’ve decided to review it between just these two routers to demonstrate new features brought by 15.x code that I couldn’t in my previous lab involving the whole WAN Topology.

To start there are a quite a few things we require a network with synchronized time for:

  • Phone Systems absolutely require synchronized time across the network
  • Debugging output and logging files to compare to current “sh clock” time
  • Network Mgmt Protocols (Like SNMP)

Just to name a few, beyond just logs and such, it is absolutely necessary for phone systems to have as accurate a time as it can have without be hooked directly to an Atomic Clock.

Also, if you’ve ever pulled logs with the completely wrong time set, and had to do “sh clock” and try to piece the logs to the current time like a puzzle it quickly turns into a very frustrating waste of time when you’re busy.

That being said, all routers have a built in “System Clock” which is usually battery driven, so if you power cycle the router it will retain the correct time (not all, but most routers).

When a router is pulled out of the box, it has a default time that is probably very different from the current time, and needs to be configured in one of the following ways:

  • Manual Configuration – Configuring the time directly on the device
  • NTP (Network Time Protocol) – Getting Time from a Time Source
  • SNTP (Simple Network Time Protocol) – Receive only protocol for Time

Given that NTP can both receive and send network time to other devices, we will not discuss SNTP at all, but wanted to mention it because it is a thing (though I’ve never seen it in production networks).

The two major versions in use of NTP are Version 3 and Version 4, and the ROUTE exam will expect you to know some differences between them, in terms of what was introduced in NTPv4 (which is why I’m using 15.x routers only).

So lets get to the differences between the two versions right up front:

Version 3

  • Only worked with IPv4, not IPv6
  • Does not do Authentication
  • Both use UDP Port 123 for source and destination

Version 4

  • Introduces NTP Authentication
  • Works with IPv4 and IPv6
  • Again both uses UDP Port 123 as source and destination

NTP devices, aside from manually configuring a Master / Server source in your network, obtains their time from a reliable source. This can be an Atomic Clock (unlikely unless you have access to Military grade Atomic Clocks), NTP Servers available via ntp.org, or other network devices like a manually configured device.

NTP is 100% Client / Server model protocol, where the client polls the Server for time about every minute, and the Server (considered to be the Authortive Source for time) provides time to that Client.

The Authority that a Time Server has is based on something called Stratum, which is a measurement of hops away from an Atomic Clock, so a device directly connected to an Atomic Clock is a Stratum 1, another device 1 hop away from a Stratum 1 device is a Stratum 2.

So as can be seen, the Stratum increments based on where you get your time from, for example if my router gets it’s time from a Stratum 3 clock then it is Stratum 4.

When configuring a router manually to be an NTP server, it’s default stratum level if not defined, is Stratum 8 with no real explanation as to why – So you’ll want to set it to a lower value.

There are 4 different modes of NTP devices

  • NTP Server (Also referred to as a Master)
  • NTP Client
  • NTP Peers (Called Symmetric mode, two or more NTP servers that exchange information)
  • NTP Broadcast / Multicast mode (Can be configured on the Server or Client as a “push” or poll of time in either Broadcast or Multicast format of transmission)

So, all that being said, first lets look at how to manually configure our NTP Server:

R1#clock set ?
  hh:mm:ss  Current Time

R1#clock set 18:34:00 ?
  <1-31>  Day of the month
  MONTH   Month of the year

R1#clock set 18:34:00 May ?
  <1-31>  Day of the month

R1#clock set 18:34:00 May 19 ?
  <1993-2035>  Year

R1#clock set 18:34:00 May 19 2017 ?
  <cr>

R1#clock set 18:34:00 May 19 2017
R1#
*May 19 18:34:00.000: %SYS-6-CLOCKUPDATE: System clock has been updated from 00:29:07 UTC Sat May 20 2017 to 18:34:00 UTC Fri May 19 2017, configured from console by console.
R1#

As you can see, Cisco has predicated at the time of the making of this router, our species will either not make it past the year 2035, or figured the device would be antiquated by then. I agree with both theories.

So now that a network device has the correct time, we should make that the Server for the network, and assign it a proper Stratum:

R1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R1(config)#ntp master ?
  <1-15>  Stratum number
  <cr>

R1(config)#ntp master 1
R1(config)#

As can be seen this is done in Global Configuration mode, which also has a couple of optional commands that can be entered here as well:

R1(config)#ntp peer 172.12.14.4 ?
  burst        Send a burst when peer is reachable
  iburst       Send a burst when peer is unreachable
  key          Configure peer authentication key
  maxpoll      Maximum poll interval
  minpoll      Minimum poll interval
  normal-sync  Disable rapid sync at startup
  prefer       Prefer this peer when possible
  source       Interface for source address
  version      Configure NTP version
  <cr>

R1(config)#ntp peer 172.12.14.4
R1(config)#int fa0/1
R1(config-if)#ntp ?
  broadcast  Configure NTP broadcast service
  disable    Disable NTP traffic (both IP and IPv6)
  multicast  Configure NTP multicast service

R1(config-if)#

So as shown the “ntp peer” command is entered now on the global config level, and I did go into the interface level to show the broadcast / multicast command, but did not issue it.

So now that R1 is saying its an NTP Peer with R4, lets issue that on R4 and see if it synchronizes:

R4#debug ntp events
NTP events debugging is on
R4#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R4(config)#ntp peer 172.12.14.1
R4(config)#
*May 19 23:40:26.315: %NTP : Drift Read : FFFFFFFF.FFFFD70D
*May 19 23:40:26.315: NTP: Initialized interface FastEthernet0/0
*May 19 23:40:26.315: NTP: Initialized interface FastEthernet0/1
*May 19 23:40:26.315: NTP: Initialized interface Loopback4
*May 19 23:40:26.315: NTP: Initialized interface VoIP-Null0
R4(config)#do sh clock
*23:40:35.299 UTC Fri May 19 2017
R4(config)#

This can be configured between NTP Servers, or between Server / Client, depending on whether you who you want to keep on the same page of what Time it is. Now lets try the interface level Broadcast command facing R4:

R4(config)#no ntp peer 172.12.14.1
R4(config)#
ASR#1
[Resuming connection 1 to r1 … ]

R1(config)#no ntp peer 172.12.14.4
R1(config)#int fa0/1
R1(config-if)#ntp broadcast
R1(config-if)#
ASR#4
[Resuming connection 4 to r4 … ]

.May 19 18:59:54.540: NTP: Uninitialized interface FastEthernet0/0
.May 19 18:59:54.540: NTP: Uninitialized interface FastEthernet0/1
.May 19 18:59:54.540: NTP: Uninitialized interface Loopback4
.May 19 18:59:54.540: NTP: Uninitialized interface VoIP-Null0
R4(config)#do sh clock
.19:00:35.060 UTC Fri May 19 2017
R4(config)#

Again without any Authentication or anything set, the Server broadcasts its time at a non-server (client) and it immediately syncs its time with the Server.

Remember, Peer and Broadcast are completely optional!

So I’ve removed all those settings, and we are back to the R4 having no Time Source information configured but R1 is our Stratum 1 NTP Server, lets look at the client configuration.

There are two ways to really go about requesting time from the Server:

  • “ntp server (master IP)”
  • “ntp broadcast client”

My IOS doesn’t seem to support the second command (dag nab it), so lets look at the first:

R4(config)#ntp server 172.12.14.1
R4(config)#
.May 19 19:08:12.908: %NTP : Drift Read : FFFFFFFF.FFFFD70D
.May 19 19:08:12.912: NTP: Initialized interface FastEthernet0/0
.May 19 19:08:12.912: NTP: Initialized interface FastEthernet0/1
.May 19 19:08:12.912: NTP: Initialized interface Loopback4
.May 19 19:08:12.912: NTP: Initialized interface VoIP-Null0
R4(config)#

R4 is of course still running “debug ntp events”, and if I remove the command:

R4(config)#no ntp server 172.12.14.1
R4(config)#
.May 19 19:08:26.472: NTP: Uninitialized interface FastEthernet0/0
.May 19 19:08:26.472: NTP: Uninitialized interface FastEthernet0/1
.May 19 19:08:26.472: NTP: Uninitialized interface Loopback4
.May 19 19:08:26.472: NTP: Uninitialized interface VoIP-Null0
R4(config)#

So from this output we gather Initialized = Good, Uninitialized = Bad with NTP.

The two verification commands for NTP as I’ve covered before will be:

  • “sh ntp status”
  • “sh ntp assoc”

So I’ll re-apply the server command to R4 pointing it to R1 again, and lets see what the output looks like on R4:

R4(config)#do sh ntp status
Clock is unsynchronized, stratum 16, no reference clock
nominal freq is 250.0000 Hz, actual freq is 250.0006 Hz, precision is 2**24
reference time is 00000000.00000000 (00:00:00.000 UTC Mon Jan 1 1900)
clock offset is 0.0000 msec, root delay is 0.00 msec
root dispersion is 0.10 msec, peer dispersion is 0.00 msec
loopfilter state is ‘FSET’ (Drift set from file), drift is -0.000002440 s/s
system poll interval is 64, never updated.
R4(config)#
R4(config)#
R4(config)#
R4(config)#do sh ntp assoc

  address         ref clock       st   when   poll reach  delay  offset   disp
 ~172.12.14.1     .INIT.          16      –     64     0  0.000   0.000 16000.
 * sys.peer, # selected, + candidate, – outlyer, x falseticker, ~ configured
R4(config)#exit

Wooooah, too soon?

R4#sh ntp status
Clock is synchronized, stratum 2, reference is 172.12.14.1
nominal freq is 250.0000 Hz, actual freq is 250.0006 Hz, precision is 2**24
reference time is DCC9C244.9328C9C9 (19:13:08.574 UTC Fri May 19 2017)
clock offset is 5.0405 msec, root delay is 1.83 msec
root dispersion is 5.83 msec, peer dispersion is 0.05 msec
loopfilter state is ‘CTRL’ (Normal Controlled Loop), drift is -0.000002435 s/s
system poll interval is 64, last update was 25 sec ago.
R4#

Yup, too soon, took about 30 seconds or so to synchronize. Lets look at “sh ntp assoc”:

R4#sh ntp assoc

  address         ref clock       st   when   poll reach  delay  offset   disp
*~172.12.14.1     .LOCL.           1     27     64     7  1.839   5.040  1.678
 * sys.peer, # selected, + candidate, – outlyer, x falseticker, ~ configured
R4#

That is what we want to see, not just the asterisk, but the wavy line (whatever that is) along with the asterisk which indicates it is synched with Server. Also note it is 1 hop away from the Stratum 1 server, so the client is Stratum 2.

So to go through the fields in the “sh ntp assoc” I’ll do it bullet point style here:

  • address = IP of the server this device is getting its time from
  • ref clock = Where that server is getting its time from (LOCL means manually configured)
  • st = Stratum of that server, in this case Stratum 1

Beyond that the fields are beyond the scope of CCNP and I don’t want to open that can of worms, but that is how to interpret those 3 fields.

Now I only have two routers so I cannot demonstrate this, but if there is a client one hop downstream from another client, they can share information with each other once the original client is synchronized with the Server.

You can simply type “ntp server 172.12.14.4” lets say if R5 was behind R4, and R4 would supply it time like a Server would.

Now for methods of Authentication or just NTP Server Protection, you can use Access-Lists to limit who can receive NTP from it, or configure Authentication

NTP Authentication uses MD5 Hash configured by Authentication Keys.

Multiple Keys can be configured for different peers, so you can configure a key per peer.

To configure this on the Server, this is how we do that in global configuration mode:

R1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R1(config)#ntp authentication-key 1 md5 CCNP
R1(config)#ntp trusted-key 1
R1(config)#ntp authenticate
R1(config)#

The server will not start actually using authentication until you use the last command entered “ntp authenticate”.

Now on the client, the commands are exactly the same, with one additional command at the end:

R4#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R4(config)#ntp authentication-key 1 md5 CCNP
R4(config)#ntp trusted-key 1
R4(config)#ntp authenticate
R4(config)#ntp server 172.12.14.1 key 1
R4(config)#

And that is how it is done, that is all for now, later!

EDIT:

Had to cut that short due to company and actually enjoying my Friday, but back to it, and I wanted to first edit this with some output of what it looks like when Authentication is failing.

I wanted to demonstrate a couple of things after I stripped NTP completely off R4, and manually did a “clock set …” on it. I wanted to see if NTP will take precedence over a local manual configuration when you enable NTP, and also what the debug looks like when Authentication fails:

So first we strip the commands, reset the clock manually as it hangs onto its last known time even if you remove NTP (so it still had the same time as R1), so lets get to it quick:

Removal

R4(config)#do sh ntp assoc
R4(config)#do sh ntp stat
%NTP is not enabled.
R4(config)#do sh clock
.00:19:17.447 UTC Sun May 21 2017
R4(config)#exit

“clock set …” and “debug ntp events” started
R4#clock set 02:45:00 feb 27 2000
R4#
.Feb 27 02:45:00.000: %SYS-6-CLOCKUPDATE: System clock has been updated from 00:20:05 UTC Sun May 21 2017 to 02:45:00 UTC Sun Feb 27 2000, configured from console by console.
R4#debug ntp ?
  adjust    NTP clock adjustments
  all       NTP all debugging on
  core      NTP core messages
  events    NTP events
  packet    NTP packet debugging
  refclock  NTP refclock messages

R4#debug ntp events
NTP events debugging is on

Giving it a try with just “ntp server …”

R4#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R4(config)#ntp server 172.12.14.1
R4(config)#
.Feb 27 02:55:41.571: %NTP : Drift Read : FFFFFFFF.FFFFD70D
.Feb 27 02:55:41.571: NTP: Initialized interface FastEthernet0/0
.Feb 27 02:55:41.571: NTP: Initialized interface FastEthernet0/1
.Feb 27 02:55:41.571: NTP: Initialized interface Loopback4
.Feb 27 02:55:41.571: NTP: Initialized interface VoIP-Null0

………… still waiting…
R4(config)#do sh ntp assoc

  address         ref clock       st   when   poll reach  delay  offset   disp
 ~172.12.14.1     .INIT.          16      –     64     0  0.000   0.000 16000.
 * sys.peer, # selected, + candidate, – outlyer, x falseticker, ~ configured
R4(config)#do sh ntp stat
Clock is unsynchronized, stratum 16, no reference clock
nominal freq is 250.0000 Hz, actual freq is 250.0006 Hz, precision is 2**24
reference time is 00000000.00000000 (00:00:00.000 UTC Mon Jan 1 1900)
clock offset is 0.0000 msec, root delay is 0.00 msec
root dispersion is 0.17 msec, peer dispersion is 0.00 msec
loopfilter state is ‘CTRL’ (Normal Controlled Loop), drift is -0.000002440 s/s
system poll interval is 64, never updated.

Getting impatient, time to “debug ntp all”
R4(config)#do debug ntp all
NTP events debugging is on
NTP core messages debugging is on
NTP clock adjustments debugging is on
NTP reference clocks debugging is on
NTP packets debugging is on
R4(config)#
May 21 00:32:41.241: NTP message sent to 172.12.14.1, from interface ‘FastEthernet0/1’ (172.12.14.4).
May 21 00:32:41.241: NTP message received from 172.12.14.1 on interface ‘FastEthernet0/1’ (172.12.14.4).
May 21 00:32:41.241: NTP Core(DEBUG): ntp_receive: message received
May 21 00:32:41.241: NTP Core(DEBUG): ntp_receive: peer is 0x67444C00, next action is 1.
May 21 00:32:41.241: NTP Core(DEBUG): receive: packet given to process_packet

Something finally happened, lets check out what!
R4(config)#do sh clock
00:33:12.941 UTC Sun May 21 2017
R4(config)#do sh ntp assoc

  address         ref clock       st   when   poll reach  delay  offset   disp
*~172.12.14.1     .LOCL.           1     46     64     3  1.929   0.140 3937.9
 * sys.peer, # selected, + candidate, – outlyer, x falseticker, ~ configured
R4(config)#

What???

I am guessing this is another bug I ran into last time I was NTP labbing, but in hopes that it isn’t I reloaded R4 t give it a chance.

Essentially the bug is that it will allow the commands to be entered for NTPv4, but Authentication is not doing anything between them, like its running NTPv3 (and I don’t see an “ntp …” option to set NTPv4.

So after the reload I re-manually set the clock, confirmed it retained the ntp server command, and did a debug all:

R4#sh clock
00:44:53.522 UTC Sun May 21 2017
R4#clock set 02:00:00 jan 15 2000
R4#
.Jan 15 02:00:00.000: %SYS-6-CLOCKUPDATE: System clock has been updated from 00:45:23 UTC Sun May 21 2017 to 02:00:00 UTC Sat Jan 15 2000, configured from console by console.

R4#debug ntp all
NTP events debugging is on
NTP core messages debugging is on
NTP clock adjustments debugging is on
NTP reference clocks debugging is on
NTP packets debugging is on
R4#sh run | i ntp
ntp server 172.12.14.1
R4#
.Jan 15 02:00:39.051: NTP message sent to 172.12.14.1, from interface ‘FastEthernet0/1’ (172.12.14.4).
.Jan 15 02:00:39.051: NTP message received from 172.12.14.1 on interface ‘FastEthernet0/1’ (172.12.14.4).
.Jan 15 02:00:39.051: NTP Core(DEBUG): ntp_receive: message received
.Jan 15 02:00:39.051: NTP Core(DEBUG): ntp_receive: peer is 0x6743C8A0, next action is 1.
.Jan 15 02:00:39.051: NTP Core(DEBUG): receive: packet given to process_packet
.Jan 15 02:00:39.051: NTP Core(DEBUG): Peer becomes reachable, poll set to 6.

.Jan 15 02:00:39.051: NTP Core(INFO): peer 172.12.14.1 event ‘event_reach’ (0x84) status ‘unreach, conf, 3 events, event_reach’ (0x8034)
R4#
.Jan 15 02:00:39.051: NTP Core(INFO): synchronized to 172.12.14.1, stratum 1

Unbelievable, even with IOS code 15 I run into a bug.

Well that was my attempt to show more detail, just remember the commands AND DIFFERENCES between NTPv3 and NTPv4 for exam day 🙂

OSPF: Database Exchange Process including messages, neighbor states, and all things neighbor forming related!

OSPF_Base_Topology

Sticking with this Topology in case I need to lab something for demonstration, it is clear what routers are where.

To begin, every router within any given Area should have an identical copy of the LSDB, and that only Type 1 and Type 2 LSA’s are flooded only within the Area they originated.

The Database exchange uses several messages and process to build a neighbor relationship, and only after it has made it through the correct amount of processes, are then LSA’s flooded to that neighbor.

There are 5 types of OSPF messages that will come from an OSPF enabled router:

  • Hello
  • DBD (Database Descriptor)
  • Link-State Request
  • Link-State Update
  • Link-State Acknowledgement

Hello packets are what begin to form the neighbor relationship, it “triggers” the formation, and the exchange of DBD’s is what is crucial because it contains all of the parameters that must be agreed upon and met to actually form a neighbor relationship.

Once a neighbor relationship can be formed, Link-State Request / Updates / Acks are exchanged by neighbors to make sure they have accurate matching LSDB’s.

Now to go through the stages of forming a neighbor relationship, starting from the beginning:

Down – This is technically a state, but you will never see a neighbor as “Down” in “sh ip ospf nei”, but you will see it in console messages and logs

Attempt – This state is seen when “static” OSPF neighbors are configured on a Non-Broadcast Multi-Access network type, Attempt means “I statically configured you and am trying to say Hello to you, but have not heard anything back yet”

**To note the ATTEMPT / DROTHER state is always present on my OSPF NBMA because it is Hub and Spoke, and there is no need for a DR / BDR election across it, so I configure the routers with Priority 0 to suppress their attempts to participate in said election**

Init – This means the local router has received a Hello packet from it’s potential neighbor, that contains the links of the other neighbors it knows about, except for you. This indicates that you share common neighbors but are not yet formally acquainted!

2way – The opposite of an “Init” is a Hello packet the DOES include the local routers link, like an acknowledgement to the Init sent, like a receipt that it got the initial Hello. This state also determines who the DR and BDR will be if a neighborship is formed in their segment, if that type of segment allows for DR’s and BDR’s.

Unless you are a DR, or a BDR, routers do not get past this 2way state (which explains the behavior of 4 OSPF routers on a segment where the DROTHERS saw each other as 2way/DROTHER). Only the DR or BDR will see these neighbors as FULL, but any DROTHER router will see another DROTHER router in 2way and their neighborship only forms to the point of knowing each other but not flooding LSA’s to each other.

ExStart – This is the state that comes after a DR / BDR is agreed upon, or agreed that no DR / BDR can exist in this type of connection, and attempt to exchange what are called either DBD’s or DD’s (Database Descriptors) – I have seen the same thing used with both acronyms.

This state exchanges an empty (of Data) DBD with your IP and RID, and exchanges those with the neighbor to come up with who will be the Slave and Master of the neighborship. Once this is determined, the Master will set the sequence number of exchanging information, and begin the exchange (much alike TCP).

Exchange – The state after a Slave / Master is elected, the neighbors now multicast DBD’s that are now populated with LSA Headers, and finding out what LSA’s are missing from each others LSDB.

Loading – This is the state where all those missing LSA’s are requesting by the neighbor in the form of a Link-State Request packet, to which the neighbor response with s Link-State Update (LSU) packet, and finally the original neighbor sends back a Link-State Acknowledgement packet.

Full – When you and your neighbor are fully synchronized and all Link State packets have been exchanged and received.

Now that the Database is fully populated from our new Neighbors, SPF steps in to calculate the best paths it has to each network in the LSDB, both and all OSPF routers do this.

The DR and BDR’s Perspective

Communication to these is multicast to the 224.0.0.6 address, and the full range of states is gone through with both the DR and BDR, but not to any other DROTHER’s if you are a DROTHER router type.

DROTHERS stay in a state of 2way, and are only “FULL” from the DR / BDR’s perspective because those are the only routers it has gotten to the Full OSPF State with.

DR and BDR’s multicast updates back to DROTHERS on 224.0.0.5, the same address they communicate to each other on.

LSA Flooding information

OSPF re-floods each LSA every 30 minutes based on it’s variable age in the LSDB, which counts up from 0 (starting when it was created), and if no changes occur to the LSA when it hits the age of 30 minutes the originating router increments the sequence number / re-floods the LSA / changes the timer back to 0.

This is the Periodic Flooding OSPF does.

To verify, use the “sh ip ospf database” command and you can see these timers and sequence numbers in action:

R1#sh ip ospf data

            OSPF Router with ID (1.1.1.1) (Process ID 1)

                Router Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum Link count
1.1.1.1         1.1.1.1         398         0x8000000A 0x00CCAA 1
2.2.2.2         2.2.2.2         745         0x8000000E 0x0086E3 1
3.3.3.3         3.3.3.3         492         0x8000000A 0x005015 1

                Net Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum
172.12.123.1    1.1.1.1         398         0x8000000A 0x0017C4

                Summary Net Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum
1.1.1.1         1.1.1.1         657         0x80000009 0x0037F4
2.2.2.2         2.2.2.2         257         0x8000000C 0x00E43C
3.3.3.3         3.3.3.3         492         0x80000009 0x009E7D
172.12.15.0     1.1.1.1         1888        0x8000000A 0x0068FE
172.12.34.0     3.3.3.3         492         0x8000000D 0x0054F4
 –More–

I had actually wondered what on Earth those were, so that is good new OSPF material that I will forget in precisely 2 weeks (after passing the exam).

When the router needs to remove an LSA from the LSDB or “Poison” it, it sets the MaxAge to 3600.

That will complete this section of OSPF with LSA types and all of that sort, I’ve spent my time digging through these, if you are reading this to learn more I highly recommend reading the sticky post with my collection of links of the 3 Part deep dive into LSA types and OSPF Router types!

OSPF: Creating OSPF from the interface, playing with Hello / Dead timers, intro to Hello-Multiplier and other good review!

OSPF_Base_Topology

This will be our topology for most of Review, though I am currently leaving Area 34 and Area 15 out of the equation since we aren’t really worried about those for review.

  • You can create a process and an Area by configuring OSPF directly on an interface, rather than making the process and adding the network statement, by issuing the command: “ip ospf (proc ID #) area (area #)” as such:

R1(config)#
R1(config)#int s0/0/0
R1(config-if)#ip ospf 1 area 0
R1(config-if)#exit
R1(config)#do sh ip proto
*** IP Routing is NSF aware ***

Routing Protocol is “ospf 1”
  Outgoing update filter list for all interfaces is not set
  Incoming update filter list for all interfaces is not set
  Router ID 100.100.100.2
  Number of areas in this router is 1. 1 normal 0 stub 0 nssa
  Maximum path: 4
  Routing for Networks:
  Routing on Interfaces Configured Explicitly (Area 0):
    Serial0/0/0
  Routing Information Sources:
    Gateway         Distance      Last Update
  Distance: (default is 110)

So it has created the OSPF Process 1, created an Area 0 and put that S0/0/0 interface in it, so anything off this interface with the same Parameters will form a neighbor relationship.

So lets go one step further and quickly config the spokes, which you’ll see me set the OSPF interface priority to 0 as needed on any Spoke in an OSPF Hub and Spoke network so they don’t become the BDR or DR, because all their communication has to go through the Hub:

R2(config)#
R2(config)#int s0/0
R2(config-if)#ip ospf pri 0
R2(config-if)#router ospf 1
R2(config-router)#network 172.12.123.0 0.0.0.255 area 0
R2(config-router)#
ASR#3
[Resuming connection 3 to r3 … ]
R3(config)#int s0/2
R3(config-if)#ip ospf pri 0
R3(config-if)#router ospf 1
R3(config-router)#network 172.12.123.0 0.0.0.255 area 0
R3(config-router)#

Back on R1 we still have not seen any adjacencies over these incredibly slow links, which even though they’re slow, it should have formed by now so something is up and that something is the static neighbor statements required for this network type:

R1(config)#router ospf 1
R1(config-router)#neighbor 172.12.123.2
R1(config-router)#neighbor 172.12.123.3
R1(config-router)#
*May 16 18:34:28.875: %OSPF-5-ADJCHG: Process 1, Nbr 2.2.2.2 on Serial0/0/0 from LOADING to FULL, Loading Done
*May 16 18:34:28.895: %OSPF-5-ADJCHG: Process 1, Nbr 3.3.3.3 on Serial0/0/0 from LOADING to FULL, Loading Done

So that was the long way of saying, if you configure OSPF directly on an interface, it will create the Process # and Area # you define and put that interface in it.

  • The interface participating cannot be Passive, as just like with EIGRP, it will not send Hello packets, and discard incoming Hello packets received
  • Has two neighborship classes: 2-way and Fully Adjacent Neighbors
  • ATTEMPT is a state for NBMA Spoke routers, as they don’t participate in the DR/BDR election, but will form functioning neighbor relationships
  • Configured directly on the interface with OSPF interface commands or added to OSPF via “network” which will detect the interface

Now for routers to form full Adjacencies, the following Criteria must match in their Hello packets to each other:

  • Area #
  • Hello/Dead timer values
  • Subnet Mask
  • Stub Area Flag
  • Authentication

Which the last two are only applicable if you have them set, otherwise the top 3 bullet points are required to match on a regular no frills added OSPF network.

The dead interval is basically telling the protocol how many Hello’s it can miss from a neighbor before it is considered down, and dynamically changes if the Hello interval is increased or decreased to be 4 x the value of the Hello value.

  • One thing to consider when changing Hello intervals, they must be changed between all neighbors or the Adjacency will drop

I am not a fan of the next piece of knowledge in relation to the CCNP because it seems so obscure, but just so you know it, you can set your Hello intervals to parts of a second by using the command:

  • “ip ospf dead-interval minimal hello-multiplier multiplier”

That is a mouthful, lets take a look at what that does on R1 I have standing by to test such odd commands as this:

R1(config-router)#int s0/0/0
R1(config-if)#ip ospf dead-interval minimal ?
  hello-multiplier  Set multiplier for Hellos

R1(config-if)#ip ospf dead-interval minimal hello-multiplier ?
  <3-20>  Number of Hellos sent within 1 second

R1(config-if)#ip ospf dead-interval minimal hello-multiplier 4 ?
  <cr>

R1(config-if)#ip ospf dead-interval minimal hello-multiplier 4

Which means the OSPF Dead Interval “minimal” of 1 second, is then divided by the numerical value after the key command modifier “hello-multiplier” which I set to 4, so this should respectively have its Hello / Dead timers set to 250ms/1s:

R1(config-if)#do sh ip ospf int s0/0/0
Serial0/0/0 is up, line protocol is up
  Internet Address 172.12.123.1/24, Area 0
  Process ID 1, Router ID 100.100.100.2, Network Type NON_BROADCAST, Cost: 64
  Topology-MTID    Cost    Disabled    Shutdown      Topology Name
        0           64        no          no            Base
  Enabled by interface config, including secondary ip addresses
  Transmit Delay is 1 sec, State DR, Priority 1
  Designated Router (ID) 100.100.100.2, Interface address 172.12.123.1
  No backup designated router on this network
  Timer intervals configured, Hello 250 msec, Dead 1, Wait 1, Retransmit 5
    oob-resync timeout 40
    Hello due in 208 msec

So if just remember, if you see an interface command with dead-interval minimal and something about hello-multiplier you are sending Hellos in increments determined by the division of the # value configured.

Also “sh ip proto” will not be a verification command to see timers, you must look at the interface to see what its timers are, as their defaults fluctuate per interface type (and whats configured on that specific interface) – So use “sh ip ospf int s0/0/0” or whatever your interface your checking is.

Also in case this is on the exam, this is what my “sh ip ospf nei” looked like after issuing the command:

R1(config-if)#do sh ip ospf nei

Neighbor ID     Pri   State           Dead Time   Address         Interface
2.2.2.2           0   FULL/DROTHER    38208 msec    172.12.123.2    Serial0/0/0
3.3.3.3           0   FULL/DROTHER    36368 msec    172.12.123.3    Serial0/0/0
R1(config-if)#

Which they of course eventually dropped over the slow serial links once they got a Hello from each neighbor with different timers set on them.

Given the whole Hello-Multiplier command, I think it’s important also to discuss that the Hello timer will not dynamically adjust if you change the Dead timer as demonstrated:

Before changing Dead Timer

R1(config-if)#do sh ip ospf int s0/0/0
Serial0/0/0 is up, line protocol is up
  Internet Address 172.12.123.1/24, Area 0
  Process ID 1, Router ID 100.100.100.2, Network Type NON_BROADCAST, Cost: 64
  Topology-MTID    Cost    Disabled    Shutdown      Topology Name
        0           64        no          no            Base
  Enabled by interface config, including secondary ip addresses
  Transmit Delay is 1 sec, State DR, Priority 1
  Designated Router (ID) 100.100.100.2, Interface address 172.12.123.1
  No backup designated router on this network
  Timer intervals configured, Hello 30, Dead 120, Wait 120, Retransmit 5

After changing Dead Timer

R1(config-if)#ip ospf dead-interval 20
R1(config-if)#do sh ip ospf int s0/0/0
Serial0/0/0 is up, line protocol is up
  Internet Address 172.12.123.1/24, Area 0
  Process ID 1, Router ID 100.100.100.2, Network Type NON_BROADCAST, Cost: 64
  Topology-MTID    Cost    Disabled    Shutdown      Topology Name
        0           64        no          no            Base
  Enabled by interface config, including secondary ip addresses
  Transmit Delay is 1 sec, State DR, Priority 1
  Designated Router (ID) 100.100.100.2, Interface address 172.12.123.1
  No backup designated router on this network
  Timer intervals configured, Hello 30, Dead 20, Wait 20, Retransmit 5

So keep that in mind, only the Dead Timer dynamically changes, but the Hello timer needs to be adjusted by either a hello-interval change or the hello-multiplier command.

So the “hello-interval” option will get your Hellos down to 1 second, but to get into sub-seconds you need to use the “dead-interval minimal hello-multiplier #” command.

Since that seems quite possible to see on exam day, its good to know that front to back, not to beat a dead horse on that one.

EIGRP: Propagating a default route in EIGRP, the 3 different ways it can be configured, and why / when to use them!

EIGRP_New_Topology

Before we dive into the CCNP material, just a real world note, I see most customers have edge devices with two static routes (one floating for failover with a slightly higher AD) and all corporate traffic has VPN tunnels configured back to the main office servers.

So to tie this now back to CCNP related materials, that is where you would configure this type of route, on the spokes / edge routers of a network, that don’t need to have all the main office networks Prefixes but just a general “send all your traffic to me” statement.

It’s basically the same places you’d make into stub networks, but Stubs have certain default behaviors you might not want impacting traffic, so a simple default route for EIGRP traffic would be all it needs.

That being said, if I were to configure this entire network I’d make R4 and R5 stubs, configure a default route on R1 to send down to its spokes, but since I’m not discussing Stub routers (covered in very previous post) I will discuss the 3 different ways of propagating a default-route through EIGRP now that we know the how and why!

 

First method: Using a static route with the “network” command and Redistribution

 

One really good to know thing about this, and I don’t know how I have not known about this previously, but you can configure a static route to Null0 to advertise the route, however with this type of default route means that anything not matched in the route table is going to be discarded per that default route on R1 – In the real world this would typically be your internet traffics ISP Gateway for the next hop (but in our lab its Null0):

R1(config)#ip route 0.0.0.0 0.0.0.0 null0
R1(config)#

This can be configured in EIGRP, but on R1 it will still show up in the IP route table as a Static route on R1 because it is considered directly connected so it has an Administrative Distance of 1, although to neighbors it will show as an EIGRP route with an AD of 90:

R1

R1(config)#router eigrp 100
R1(config-router)#network 0.0.0.0 0.0.0.0
R1(config-router)#exit
R1(config)#do sh ip route

Gateway of last resort is 0.0.0.0 to network 0.0.0.0

S*    0.0.0.0/0 is directly connected, Null0
      1.0.0.0/32 is subnetted, 1 subnets
C        1.1.1.1 is directly connected, Loopback1
      2.0.0.0/32 is subnetted, 1 subnets
D        2.2.2.2 [90/2297856] via 172.12.123.2, 00:11:23, Serial0/0/0
      3.0.0.0/32 is subnetted, 1 subnets
D        3.3.3.3 [90/2297856] via 172.12.123.3, 00:11:23, Serial0/0/0
      172.12.0.0/16 is variably subnetted, 3 subnets, 2 masks
D        172.12.23.0/24 [90/2173416] via 172.12.123.3, 00:11:23, Serial0/0/0
                        [90/2173416] via 172.12.123.2, 00:11:23, Serial0/0/0
C        172.12.123.0/24 is directly connected, Serial0/0/0
L        172.12.123.1/32 is directly connected, Serial0/0/0
R1(config)#

R2

R2#sh ip route

Gateway of last resort is 172.12.123.1 to network 0.0.0.0

     1.0.0.0/32 is subnetted, 1 subnets
D       1.1.1.1 [90/2297856] via 172.12.123.1, 00:00:26, Serial0/0
     2.0.0.0/32 is subnetted, 1 subnets
C       2.2.2.2 is directly connected, Loopback2
     3.0.0.0/32 is subnetted, 1 subnets
D       3.3.3.3 [90/156160] via 172.12.23.3, 00:24:36, FastEthernet0/0
     172.12.0.0/24 is subnetted, 2 subnets
C       172.12.23.0 is directly connected, FastEthernet0/0
C       172.12.123.0 is directly connected, Serial0/0
D*   0.0.0.0/0 [90/2169856] via 172.12.123.1, 00:00:27, Serial0/0
R2#

As can be seen it does what it needs to do, which is one of the ways a default route can be propagated, by using Null0 if there isn’t a specific next hop you want to use (Like an ISP Gateway as mentioned above).

Fun fact, you can also create a Null0 logical interface by type “int null0” and configure it, but it’d of course still send all traffic to a logical interface / logical trash can for traffic.

Also, you can also use a static route to propagate the default route simply by redistributing it into EIGRP:

R1(config)#router eigrp 100
R1(config-router)#redistribute static connected ?
% Unrecognized command
R1(config-router)#redistribute static ?
metric     Metric for redistributed routes
route-map  Route map reference
<cr>

R1(config-router)#redistribute static
R1(config-router)#

I left that error in there to demonstrate that in EIGRP, even if you use the other two commands it will not allow “subnets” to be be included on the command. So lets have a look at how it’s seen around the network now by none R1 routers (R1 see’s it the same):

R2#sh ip route

Gateway of last resort is 172.12.123.1 to network 0.0.0.0

     2.0.0.0/32 is subnetted, 1 subnets
C       2.2.2.2 is directly connected, Loopback2
     3.0.0.0/32 is subnetted, 1 subnets
D       3.3.3.3 [90/156160] via 172.12.23.3, 00:47:10, FastEthernet0/0
     172.12.0.0/24 is subnetted, 2 subnets
C       172.12.23.0 is directly connected, FastEthernet0/0
C       172.12.123.0 is directly connected, Serial0/0
D*EX 0.0.0.0/0 [170/2169856] via 172.12.123.1, 00:01:39, Serial0/0
R2#

So this is much less efficient for two reasons, the first being that it’s AD when from 90 to now 170 as it’s an External (Redistributed) EIGRP route to all neighbor routers, but also on R1 when a new Static route is added it will also be Redistribute as show here:

R1(config)#ip route 172.12.34.0 255.255.255.0 172.12.123.3
R1(config)#
ASR#2
[Resuming connection 2 to r2 … ]

R2#sh ip route eigrp
     3.0.0.0/32 is subnetted, 1 subnets
D       3.3.3.3 [90/156160] via 172.12.23.3, 00:52:04, FastEthernet0/0
     172.12.0.0/24 is subnetted, 3 subnets
D EX    172.12.34.0 [170/2681856] via 172.12.123.1, 00:00:13, Serial0/0
D*EX 0.0.0.0/0 [170/2169856] via 172.12.123.1, 00:06:34, Serial0/0
R2#

So needless to say this is not ideal, unless your objective is to redistribute all static routes on exam day, but in the real world you probably don’t want new IP route statements accidentally being propagated throughout the EIGRP network.

Using the “network” command to propagate it is looking like the best way so far with static routes, as the AD of 170 as well leaves some room for another default route entered via “network” with an AD of 90 somewhere else could take it’s place as the default route for R2 (as well as redistributing all future static routes).

 

Using “ip default-network” command (Second way to propagate default routes)

 

This command can only be used in conjunction with a “Classful” network as the default route,  so the best way to manipulate a classful network on the router sending out default routes, is to create a loopback interface with a classful network on it.

The very important things to note about this command:

  • The network MUST be Classful for this command to work
  • The network must be in your IP route table, whether its directly connected or added with the “ip route …” statement
  • The command “ip default-network …” is NOT configured in EIGRP itself

So lets look at how it works on the equipment:

R1(config)#no ip route 0.0.0.0 0.0.0.0 null0
R1(config)#do clear ip route *
R1(config)#do sh ip route

Codes: L – local, C – connected, S – static, R – RIP, M – mobile, B – BGP
D – EIGRP, EX – EIGRP external, O – OSPF, IA – OSPF inter area
N1 – OSPF NSSA external type 1, N2 – OSPF NSSA external type 2
E1 – OSPF external type 1, E2 – OSPF external type 2
i – IS-IS, su – IS-IS summary, L1 – IS-IS level-1, L2 – IS-IS level-2
ia – IS-IS inter area, * – candidate default, U – per-user static route
o – ODR, P – periodic downloaded static route, + – replicated route

Gateway of last resort is not set

1.0.0.0/32 is subnetted, 1 subnets
C        1.1.1.1 is directly connected, Loopback1
2.0.0.0/32 is subnetted, 1 subnets
D        2.2.2.2 [90/2297856] via 172.12.123.2, 00:00:08, Serial0/0/0
3.0.0.0/32 is subnetted, 1 subnets
D        3.3.3.3 [90/2297856] via 172.12.123.3, 00:00:08, Serial0/0/0
*    11.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C*       11.0.0.0/8 is directly connected, Loopback11
L        11.0.0.1/32 is directly connected, Loopback11
172.12.0.0/16 is variably subnetted, 3 subnets, 2 masks
D        172.12.23.0/24 [90/2173416] via 172.12.123.3, 00:00:08, Serial0/0/0
[90/2173416] via 172.12.123.2, 00:00:08, Serial0/0/0
C        172.12.123.0/24 is directly connected, Serial0/0/0
L        172.12.123.1/32 is directly connected, Serial0/0/0

R1(config)#

So I left the code table in specifically to show that the new interface 11.0.0.0/8 is being flagged as a default candidate route, even though R1 does not have it in its own IP route table as a default route, also using a Class A network is ok in lab / exam environments but I’m sure its better to use a Class C as to avoid overlapping future addresses.

Now it is showing on here that it is our marked candidate default route, however for it to be transmitted to EIGRP neighbors, the network must also be added to EIGRP, no Wildcard mask needed as the network needs to be classful:

R2#sh ip route

Gateway of last resort is 172.12.123.1 to network 11.0.0.0

     2.0.0.0/32 is subnetted, 1 subnets
C       2.2.2.2 is directly connected, Loopback2
     3.0.0.0/32 is subnetted, 1 subnets
D       3.3.3.3 [90/156160] via 172.12.23.3, 00:20:16, FastEthernet0/0
     172.12.0.0/24 is subnetted, 2 subnets
C       172.12.23.0 is directly connected, FastEthernet0/0
C       172.12.123.0 is directly connected, Serial0/0
D*   11.0.0.0/8 [90/2297856] via 172.12.123.1, 00:00:09, Serial0/0
R2#

So now on R1 we can set an actual default route on the router advertising itself as a default route to all EIGRP neighbors, while being able to broadcast our router as the default route for neighbors, and here is a demonstration of this using a loopback interface as our ISP’s gateway address:

R1

R1(config)#int lo100
*May 15 03:48:33.147: %LINEPROTO-5-UPDOWN: Line protocol on Interface Loopback100, changed state to up
R1(config-if)#ip add 100.100.100.2 255.255.255.0
R1(config-if)#exit
R1(config)#do sh ip route
Codes: L – local, C – connected, S – static, R – RIP, M – mobile, B – BGP
       D – EIGRP, EX – EIGRP external, O – OSPF, IA – OSPF inter area
       N1 – OSPF NSSA external type 1, N2 – OSPF NSSA external type 2
       E1 – OSPF external type 1, E2 – OSPF external type 2
       i – IS-IS, su – IS-IS summary, L1 – IS-IS level-1, L2 – IS-IS level-2
       ia – IS-IS inter area, * – candidate default, U – per-user static route
       o – ODR, P – periodic downloaded static route, + – replicated route

Gateway of last resort is not set

      1.0.0.0/32 is subnetted, 1 subnets
C        1.1.1.1 is directly connected, Loopback1
      2.0.0.0/32 is subnetted, 1 subnets
D        2.2.2.2 [90/2297856] via 172.12.123.2, 00:31:36, Serial0/0/0
      3.0.0.0/32 is subnetted, 1 subnets
D        3.3.3.3 [90/2297856] via 172.12.123.3, 00:31:36, Serial0/0/0
 *    11.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C*       11.0.0.0/8 is directly connected, Loopback11
L        11.0.0.1/32 is directly connected, Loopback11
      100.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C        100.100.100.0/24 is directly connected, Loopback100
L        100.100.100.2/32 is directly connected, Loopback100
      172.12.0.0/16 is variably subnetted, 3 subnets, 2 masks
D        172.12.23.0/24 [90/2173416] via 172.12.123.3, 00:31:36, Serial0/0/0
                        [90/2173416] via 172.12.123.2, 00:31:36, Serial0/0/0
C        172.12.123.0/24 is directly connected, Serial0/0/0
L        172.12.123.1/32 is directly connected, Serial0/0/0
R1(config)#

Note that 2.2.2.2 is learned via EIGRP, however our “ISP Gateway” loopback is a directly connected route not being advertised to R2.

R2

R2#sh ip route

Gateway of last resort is 172.12.123.1 to network 11.0.0.0

     2.0.0.0/32 is subnetted, 1 subnets
C       2.2.2.2 is directly connected, Loopback2
     3.0.0.0/32 is subnetted, 1 subnets
D       3.3.3.3 [90/156160] via 172.12.23.3, 00:44:00, FastEthernet0/0
     172.12.0.0/24 is subnetted, 2 subnets
C       172.12.23.0 is directly connected, FastEthernet0/0
C       172.12.123.0 is directly connected, Serial0/0
D*   11.0.0.0/8 [90/2297856] via 172.12.123.1, 00:23:53, Serial0/0

R2#ping 100.100.100.2 source 2.2.2.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 100.100.100.2, timeout is 2 seconds:
Packet sent with a source address of 2.2.2.2
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 64/65/68 ms
R2#

So as can be seen, even though R2 has no idea what the internet address is that it is pinging to, it is able to establish 2-way Layer 3 communication to it because it has a default route to R1 that then has the connected “ISP Gateway” as it’s own default route, which on exam day might be another router address.

I hope it was clear that I defined the EIGRP discovered IP of 2.2.2.2 on R1 when pinging from R2, as the 172.12.123.0/24 network shows as directly connected on R1/R2/R3, however the loopbacks are only known via EIGRP.

So this for practical purposes is the best way to do it, as someone has to have a gateway to the internet, it can’t all be EIGRP networks and some networks have a single point of exit / entry for internet data (usually where heavy duty edge devices are to filter internet traffic).

So I am wondering, if this will pass along to R4, lets join it to EIGRP quick and see if R3 will continue to propagate on to the next neighbor:

Bringing up Adjacency and reviewing route tables:

R3:

R3(config)#router eigrp 100
R3(config-router)#network 172.12.34.0 0.0.0.255
R3(config-router)#
*Mar 31 22:59:17.586: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 172.12.34.4 (FastEthernet0/1) is up: new adjacency
R3(config-router)#

R4

*May 15 02:58:00.791: %DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 172.12.34.3 (FastEthernet0/1) is up: new adjacency
R4(config-router)#do sh ip route

Gateway of last resort is not set

      2.0.0.0/32 is subnetted, 1 subnets
D        2.2.2.2 [90/158720] via 172.12.34.3, 00:00:12, FastEthernet0/1
      3.0.0.0/32 is subnetted, 1 subnets
D        3.3.3.3 [90/156160] via 172.12.34.3, 00:00:12, FastEthernet0/1
      4.0.0.0/32 is subnetted, 1 subnets
C        4.4.4.4 is directly connected, Loopback4
D*    11.0.0.0/8 [90/2300416] via 172.12.34.3, 00:00:12, FastEthernet0/1
      172.12.0.0/16 is variably subnetted, 4 subnets, 2 masks
D        172.12.23.0/24 [90/30720] via 172.12.34.3, 00:00:12, FastEthernet0/1
C        172.12.34.0/24 is directly connected, FastEthernet0/1
L        172.12.34.4/32 is directly connected, FastEthernet0/1
D        172.12.123.0/24
           [90/2172416] via 172.12.34.3, 00:00:12, FastEthernet0/1
R4(config-router)#

Back to R3 to confirm it has the same route but a default gateway:

R3(config-router)#do sh ip route

Gateway of last resort is 172.12.123.1 to network 11.0.0.0

     2.0.0.0/32 is subnetted, 1 subnets
D       2.2.2.2 [90/156160] via 172.12.23.2, 02:05:01, FastEthernet0/0
     3.0.0.0/32 is subnetted, 1 subnets
C       3.3.3.3 is directly connected, Loopback3
     172.12.0.0/24 is subnetted, 3 subnets
C       172.12.34.0 is directly connected, FastEthernet0/1
C       172.12.23.0 is directly connected, FastEthernet0/0
C       172.12.123.0 is directly connected, Serial0/2
D*   11.0.0.0/8 [90/2297856] via 172.12.123.1, 00:41:48, Serial0/2
R3(config-router)#

Back to R4 to confirm connectivity to our default route is toast:

R4(config-router)#do ping 100.100.100.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 100.100.100.2, timeout is 2 seconds:
…..
Success rate is 0 percent (0/5)
R4(config-router)#

This actually also happened to Keith Bogart on his video lesson for this, which was kind of funny as he wasn’t expecting this behavior and became a bit flustered with Cisco for having this kind of behavior happen, so I know it is not just my lab.

So even though this is the better join, keep in mind this is only good for routers one hop away, like Query packets being sent from an EIGRP router with advertising Summary routes, it will only actually set the Default Gateway of routers 1 hop away and after that EIGRP routers will just know about the route but not set their default gateway.

That is a very important concept to understand for exam day!

 

Using a Summary-Address (the third and final way to propagate a default route)

 

The configuration for this is the exact same syntax to set a Summary-Address on an interface if you were doing Summarization with a bunch of sequential Prefixes, lets walk through how different routers see this:

R1(config)#int s0/0/0
R1(config-if)#ip summary-address eigrp 100 0.0.0.0 0.0.0.0
R1(config-if)#
*May 15 04:33:06.235: %DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 172.12.123.2 (Serial0/0/0) is resync: summary configured
*May 15 04:33:06.235: %DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 172.12.123.3 (Serial0/0/0) is resync: summary configured
R1(config-if)#do sh ip route

Gateway of last resort is 0.0.0.0 to network 0.0.0.0

D*    0.0.0.0/0 is a summary, 00:00:47, Null0
      1.0.0.0/32 is subnetted, 1 subnets
C        1.1.1.1 is directly connected, Loopback1
      2.0.0.0/32 is subnetted, 1 subnets
D        2.2.2.2 [90/2297856] via 172.12.123.2, 01:15:33, Serial0/0/0
      3.0.0.0/32 is subnetted, 1 subnets
D        3.3.3.3 [90/2297856] via 172.12.123.3, 01:15:33, Serial0/0/0
      100.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C        100.100.100.0/30 is directly connected, Loopback100
L        100.100.100.2/32 is directly connected, Loopback100
      172.12.0.0/16 is variably subnetted, 4 subnets, 2 masks
D        172.12.23.0/24 [90/2173416] via 172.12.123.3, 01:15:33, Serial0/0/0
                        [90/2173416] via 172.12.123.2, 01:15:33, Serial0/0/0
D        172.12.34.0/24 [90/2172416] via 172.12.123.3, 00:27:19, Serial0/0/0
C        172.12.123.0/24 is directly connected, Serial0/0/0
L        172.12.123.1/32 is directly connected, Serial0/0/0
R1(config-if)#
ASR#3
[Resuming connection 3 to r3 … ]

*Mar 31 23:25:50.317: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 172.12.123.1 (Serial0/2) is resync: peer graceful-restart
R3(config-router)#do sh ip route

Gateway of last resort is 172.12.123.1 to network 0.0.0.0

     2.0.0.0/32 is subnetted, 1 subnets
D       2.2.2.2 [90/156160] via 172.12.23.2, 02:31:09, FastEthernet0/0
     3.0.0.0/32 is subnetted, 1 subnets
C       3.3.3.3 is directly connected, Loopback3
     172.12.0.0/24 is subnetted, 3 subnets
C       172.12.34.0 is directly connected, FastEthernet0/1
C       172.12.23.0 is directly connected, FastEthernet0/0
C       172.12.123.0 is directly connected, Serial0/2
D*   0.0.0.0/0 [90/2681856] via 172.12.123.1, 00:01:10, Serial0/2
R3(config-router)#
ASR#4
[Resuming connection 4 to r4 … ]

R4(config-router)#do sh ip route

Gateway of last resort is 172.12.34.3 to network 0.0.0.0

D*    0.0.0.0/0 [90/2684416] via 172.12.34.3, 00:01:43, FastEthernet0/1
      2.0.0.0/32 is subnetted, 1 subnets
D        2.2.2.2 [90/158720] via 172.12.34.3, 00:28:14, FastEthernet0/1
      3.0.0.0/32 is subnetted, 1 subnets
D        3.3.3.3 [90/156160] via 172.12.34.3, 00:28:14, FastEthernet0/1
      4.0.0.0/32 is subnetted, 1 subnets
C        4.4.4.4 is directly connected, Loopback4
      172.12.0.0/16 is variably subnetted, 4 subnets, 2 masks
D        172.12.23.0/24 [90/30720] via 172.12.34.3, 00:28:14, FastEthernet0/1
C        172.12.34.0/24 is directly connected, FastEthernet0/1
L        172.12.34.4/32 is directly connected, FastEthernet0/1
D        172.12.123.0/24
           [90/2172416] via 172.12.34.3, 00:28:14, FastEthernet0/1
R4(config-router)#

There is a lot to note and I’m getting mentally exhaust, so I will bullet point style what I’d like to point out from the above output

  • The command is “ip summary-address eigrp (AS #) 0.0.0.0 0.0.0.0”
  • It creates a default route on the router it is issued on
  • This will “eat up” and Prefixes that were being advertised, almost turning the downstream router receiving this default route into a Stub
  • R4 did get and set the default route to its next hop R3, who then has a default route to R1 who is advertising this, so it propagates all the way through the network

So, I also highlighted in red that R3 only knows of 2.2.2.2 via the Ethernet segment, which I am betting is where R4 is getting all its route as well, so I will shut down that interface to see if R3 and R4 are only left with default routes leading back to R1:

R3(config-router)#int fa0/0
R3(config-if)#shut
R3(config-if)#
*Mar 31 23:35:29.386: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 172.12.23.2 (FastEthernet0/0) is down: interface down
R3(config-if)#
*Mar 31 23:35:31.377: %LINK-5-CHANGED: Interface FastEthernet0/0, changed state to administratively down
*Mar 31 23:35:32.379: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/0, changed state to down
R3(config-if)#do sh ip route

Gateway of last resort is 172.12.123.1 to network 0.0.0.0

     3.0.0.0/32 is subnetted, 1 subnets
C       3.3.3.3 is directly connected, Loopback3
     172.12.0.0/24 is subnetted, 2 subnets
C       172.12.34.0 is directly connected, FastEthernet0/1
C       172.12.123.0 is directly connected, Serial0/2
D*   0.0.0.0/0 [90/2681856] via 172.12.123.1, 00:00:14, Serial0/2
R3(config-if)#
ASR#4
[Resuming connection 4 to r4 … ]

R4(config-router)#do sh ip route

Gateway of last resort is 172.12.34.3 to network 0.0.0.0

D*    0.0.0.0/0 [90/2684416] via 172.12.34.3, 00:00:23, FastEthernet0/1
      3.0.0.0/32 is subnetted, 1 subnets
D        3.3.3.3 [90/156160] via 172.12.34.3, 00:36:33, FastEthernet0/1
      4.0.0.0/32 is subnetted, 1 subnets
C        4.4.4.4 is directly connected, Loopback4
      172.12.0.0/16 is variably subnetted, 3 subnets, 2 masks
C        172.12.34.0/24 is directly connected, FastEthernet0/1
L        172.12.34.4/32 is directly connected, FastEthernet0/1
D        172.12.123.0/24
           [90/2172416] via 172.12.34.3, 00:36:33, FastEthernet0/1
R4(config-router)#

So that demonstrates that if you set a Summary-Address as the default route, any downstream routers (without another way to learn routes like R3’s Ethernet segment) will have their routes Summarized into a default route, essentially making all EIGRP routes off that interfaces like Stub Routers as they will only learn 0.0.0.0/0 via EIGRP.

However one important thing to note, in the Topology table they don’t have the Summary-Address AD of 5, they have an Internal Route AD of 90, as also seen here:

R4(config-router)#do sh ip route 0.0.0.0
Routing entry for 0.0.0.0/0, supernet
  Known via “eigrp 100”, distance 90, metric 2684416, candidate default path, type internal
  Redistributing via eigrp 100
  Last update from 172.12.34.3 on FastEthernet0/1, 00:07:23 ago
  Routing Descriptor Blocks:
  * 172.12.34.3, from 172.12.34.3, 00:07:23 ago, via FastEthernet0/1
      Route metric is 2684416, traffic share count is 1
      Total delay is 40100 microseconds, minimum bandwidth is 1544 Kbit
      Reliability 255/255, minimum MTU 1500 bytes
      Loading 1/255, Hops 2
R4(config-router)#

That is a very important note for exam day, that Default Summary-Addresses in EIGRP have an AD of 90, while an actual Summary of Prefixes advertised the same way will have an AD of 5 on downstream routers!

To verify default routes you can either view “sh ip route” and look for the * in the route table indicating the candidate default route, or “sh ip route eigrp 0.0.0.0/0” or whatever prefix is the default route being advertised.

So that will do it for tonight, I just wanted to be as clear as possible the behaviors of how the different methods propagate static routes, so that the correct method can be chosen on exam day and on the job when the network calls for an EIGRP default route.

EIGRP: Using Route-Maps to filter EIGRP routes to finish that discussion, excellent example of Prefix-List logic, test your knowledge!!

EIGRP_New_Topology

It is very late / early however upon working on the physical lab I realized I completely forgot to cover EIGRP route filtering using Route-Maps to filter EIGRP routes, and I am about half asleep (as usual) so please excuse any typos within 🙂

So to filter routes in EIGRP, we are always going to use a distribute-list, it’s just a matter of using ACL’s / Prefix-Lists / Route-Maps to do it. We’ve seen Prefix-Lists and ACL’s configured and their behaviors, however Route-Maps are just a bit different but use the exact same logic.

I’m going to jump on the gear quick for a demonstration, this article assumes you understand configuring a Prefix-List and a Route-Map, and if not you are going to learn to right now!

So here’s how we configure a Route-Map to use a Prefix-List within a Distribute-List to filter EIGRP Routes (boy is that a mouth full):

The original “sh ip route eigrp” before any configuration

R1(config)#do sh ip route eigrp

Gateway of last resort is not set

      2.0.0.0/32 is subnetted, 1 subnets
D        2.2.2.2 [90/2297856] via 172.12.123.2, 00:16:15, Serial0/0/0
      3.0.0.0/32 is subnetted, 1 subnets
D        3.3.3.3 [90/2297856] via 172.12.123.3, 00:16:15, Serial0/0/0
      172.12.0.0/16 is variably subnetted, 3 subnets, 2 masks
D        172.12.23.0/24 [90/2173416] via 172.12.123.3, 00:16:15, Serial0/0/0
                        [90/2173416] via 172.12.123.2, 00:16:15, Serial0/0/0

The Prefix-list

R1(config)#ip prefix-list TEST seq 10 permit 0.0.0.0/0 ge 32 le 32
R1(config)#

The Route-Map

R1(config)#route-map DENIED deny 10
R1(config-route-map)#match ip add ?
  <1-199>      IP access-list number
  <1300-2699>  IP access-list number (expanded range)
  WORD         IP access-list name
  prefix-list  Match entries of prefix-lists

R1(config-route-map)#match ip add prefix-list TEST
R1(config-route-map)#route-map DENIED permit 20

The Distribute-List

R1(config-route-map)#router eigrp 100
R1(config-router)#distribute-list route-map DENIED in
R1(config-router)#

I like this example, because it really tests what you know about Prefix-Lists, as we’ve already beat distribute-list logic to death – But what will that Prefix-list filter? Everything? Nothing? Some of them? Do you know why it does what?

Now I am going to put the answer waaaay the heck down the screen so you can look over the routes before the configuration, what was configured, and the results might surprise you or catch you off guard which is what Cisco is looking to do on the ROUTE exam! 🙂

 

 

……… Go back up and review it the routes being filtered, and the what the Prefix-List is filtering.

 

 

 

……… Might want to take one last look, I even got it wrong what I predicted the first time.

 

 

 

 

 

 

………. Ok lets take a look at the results below.

 

 

 

 

 

 

 

 

Lets take a look at what this distribute-list has accomplished:

R1(config)#do sh ip route eigrp

Gateway of last resort is not set

      172.12.0.0/16 is variably subnetted, 3 subnets, 2 masks
D        172.12.23.0/24 [90/2173416] via 172.12.123.3, 00:00:07, Serial0/0/0
                        [90/2173416] via 172.12.123.2, 00:00:07, Serial0/0/0

You read that correctly! When configuring the prefix-list you ‘permit’ the line (s), then use a ‘deny’ on your route-map sequence to do the filtering. This configuration only blocks all host routes because it includes the “gr 32 le 32” on the end of it, meaning it permits all host routes, but does not match on any Prefix/Length (networks).

It filtered the 2.2.2.2 and 3.3.3.3 because they are host routes, but it allowed the Prefix of 172.12.23.0/24 through because if we wanted to filter prefixes, we need to use 0.0.0.0/0 without the “gr 32 le 32” on the end of it – Then we would have a reversal of what was filtered and what was allowed.

The sequence 20 on the Route-Map is the usual catch-all clause to allow all other traffic to go about it’s business as usual, with no parameters set, as usual.

So that is the last way in which EIGRP routes can be filtered with Distribute-Lists in EIGRP, however I hope I’ve really driven the point home on the Prefix-List ‘default-route’ logic as well, because that is BEGGING for a question on exam day that we need to be ready to nail to the wall immediately and move on while the clock is ticking!

TGIF. Bed time for me, see ya!

 

ROUTE Blueprint “Network Principles” section topics all covered within this post (briefly, but covered)!

Directly from Cisco’s website:

1.1 Identify Cisco Express Forwarding concepts

  • 1.1.a FIB – Forwarding Information Base, “sh ip cef” to view, used to determine next hop IP addresses, performs Layer 3 “Packet Switching” or Packet forwarding
  • 1.1.b Adjacency table – Correlates with FIB to find corresponding MAC addresses for Packet Switching / Forwarding
  • Both these exist on the “Data Plane” where actual forwarding occurs, and populates the IP Route Table (RIB) which exists on the “Control Plane”

1.2 Explain general network challenges

  • 1.2.a Unicast – “Unknown Unicasts” are generated when a Destination MAC is unknown, switches will flood these packets to all members within the VLAN, possibly causing a “Traffic Storm” which can impact network performance
  • 1.2.b Out-of-order packets – Each Packet is forwarded by the best metric to its destination, so this can happen if metrics change during transmission. TCP solves this issue with Ack and Seq numbers to re-order packets when they arrive
  • 1.2.c Asymmetric routing – This occurs when traffic takes a different return path then the traffic was sent on, specifically this is an issue with Firewalls and NAT. For example the devices will keep track of the connection states, SYN is sent through a router to a server, but servers Default Gateway is through a different device (Firewall), that device will have no “State Record” of the connection and drop the packets ACK it is trying to send back.

1.3 Describe IP operations

  • 1.3.a ICMP Unreachable and Redirects – Redirects are found when debugging ICMP packets, sent back to the source when a better route is found to the Destination by Gateways only (NOT hosts). Unreachable responses come in the form of (U.U.U) meaning the upstream router has no route to the destination network
  • 1.3.b IPv4 and IPv6 fragmentation – IPv4 Fragmentation happens when an IP Datagram is passing through a device with a smaller MTU (Maximum Transmission Unit) than the original Sender, and the receiver must reassemble the fragments based upon the flags in the Fragment Offset field in the IPv4 Header. IPv6 does not have a “Fragmentation” field in it’s IPv6 Header, so it must be inserted into the IP Packet “Extension” field by the sender if its determined Fragmentation is needed before transmission rather than during transmission.
  • 1.3.c TTL -Time To Live is a value in the Header of an IPv4 Packet, that is decremented (decreased) in value by 1 for each hop or router it passes through, until it hits the value of 0, at which point it is discarded.

1.4 Explain TCP operations

  • 1.4.a IPv4 and IPv6 (P)MTU – MTU refers to the Maximum Transmission Unit size that can be sent to a host. IPv4 “may” use Path MTU Discovery to avoid packet framentation along the way, IPv6 “must” use Path MTU Discovery so it can set the Fragmentation in its IPv6 Headers “Extension” field. So (P)MTU = Path MTU.
  • 1.4.b MSS – “Maximum Segment Size” is an optional field in the TCP SYN Packet, which can adjust the MTU of a router, generally used for PPPoE (PPP over Ethernet), as the default size of MTU’s is 1500, and PPPoE only supports up to 1492 MTU Size – So it will discard any packets (most default ones) if not adjusted in the MSS
  • 1.4.c Latency – The time it takes for a packet to travel from its Source to its Destination, and used by some routing protocols (EIGRP) to determine its metric, and if packets are dropped TCP will request re-transmission of discarded packets
  • 1.4.d Windowing – The amount of TCP segments that a Receiver can successfully have transmitted, acknowledged with an ACK back to the Sender. Sliding-Window is a type of Windowing where the segments sent increases until the Receiver can no longer Ack the amount of segments, and the Sender then slows down transmission of segments being sent until Ack’s are again received
  • 1.4.e Bandwidth-delay product – The maximum amount of bits that can be on a segment at any given time
  • 1.4.f Global synchronization – Also known as TCP Synchronization, is when a routers interface output queue fills to capacity and it must start discarding TCP packets, taking longer for TCP transmissions to go through and ACK’s to be sent. One way to prevent this condition is Weighted Random Early Detection (WRED) that can randomly drop packets from the queue if it gets near capacity.

1.5 Describe UDP operations

  • 1.5.a Starvation – When “Connectionless” UDP Packets flood the interface or “starve” the line of bandwidth, causing TCP connections to drop excessive packets, and slow down the transmission of them
  • 1.5.b Latency – Any packets discarded will not be re-transmitted as UDP is connectionless, QoS solves this issue between a source and destination

1.6 Recognize proposed changes to the network

  • 1.6.a Changes to routing protocol parameters – Understand network wide impact on routing behaviors, plan phases of the protocol behaviors, and have an action plan to migrate back to the initial parameters to minimize downtime
  • 1.6.b Migrate parts of the network to IPv6 – Check and confirm LAN nodes are IPv6 compatible, run IPv4 and IPv6 concurrently (Dual-Stack) to confirm compatibility, user IPv6-over-IPv4 tunnels for IPv6 LAN’s to be able to communicate over IPv4 tunnels between sites, and also using NAT64 which converts IPv6 Address to IPv4 addresses entering the LAN
  • 1.6.c Routing protocol migration – One method for migration would be to run both protocols concurrently, so if one fails the other can continue to run, another method would be route redistribution one network segment at a time to see how it reacts to the migration