Quick notes on IP CEF and the Adjancency Table for exam day!

No Topology needed for this one, just wanted to jot some quick notes from a video I’m reviewing on the subject.

Before getting into what CEF and AT is all about, I feel its important this is required to be on and working for uRPF (Unicast Reverse Path Forwarding).

CEF is derived from the IP Route table, is also named FIB, and runs at the “Data Plane” while the IP Route table runs at the “Control Plane”.

One way two keep the two differentiated, is to remember the 3 letter acronym is the L3 information (CEF/FIB) and the L2 information has a 2 letter acronym (AT) Adjacency table.

“sh ip int …” to view CEF info for an interface, in fact adding the “ip” part to interface gives you basically the services statistics or information running on the interface.

“sh ip cef” to see the prefix-list for CEF

“sh adj” to view the adjacency table, “sh adj det” for more details

Like the CEF table is derived from the IP Route Table, the Adjacency Table is derived from ARP

If you see (incomplete) within the AT, you have an ARP issue somewhere in the network.

If you narrow down CEF to a single route, like “sh ip cef 172.12.123.1” and see the term invalid cached adjacency that is also an indication of a Layer 2 ARP issue.

Process Switching = Router looks at every packet to determine how to forward it.

Fast Switching = Router keeps a destination cache for packets, inspects the first packet that matches a destination, then allows the flow through without inspecting all packets.

Thats all I got for that, just a little nugget of straight to the point info, enjoy! ūüôā

 

Netflow : Heavier ROUTE config on top half, light weight config for real world at the bottom, some comparison of v5 to v9!

OSPF_Base_Topology

I want to first say the top half of this will be the heavy duty CCNP ROUTE details needed for the exam, I’ll try to fill in the differences as much as I can in the middle, and at the bottom is a real world way for actual network admins to configure and view Netflow on the fly so seriously check it out if your job is working on routers!

Netflow is a tool that can be used to view traffic statistics within the network, for the reasons of seeing “top talkers” consuming bandwidth / reviewing available bandwidth for future planning / getting a general idea of your network bandwidth usage.

Netflow is comprised of three components:

  • The “Monitor” – The Ingress interface (LAN interface) of your router with Netflow configurations on it, which watches the data and caches it for a short period of time, until it is Exported to a network management server
  • The “Exporter” – Configuration on the router that exports the collected Data on UDP port 9996 to a Network Management Server that contains software to collect it
  • The “Collector” – An NMS running special software to capture the Netflow data put it into graphical output that is more readable than the CLI for quick views of the info

I don’t actually have an NMS server setup, but I’ll show the configurations of what to do if we did, I’ll point it at R4 to see if there is any way to pull the export info off there:

R1(config)#flow exporter EXPORT1
R1(config-flow-exporter)#?
  default          Set a command to its defaults
  description      Provide a description for this Flow Exporter
  destination      Export destination configuration
  dscp             Optional DSCP
  exit             Exit from Flow Exporter configuration mode
  export-protocol  Export protocol version
  no               Negate a command or set its defaults
  option           Select an option for exporting
  output-features  Send export packets via IOS output feature path
  source           Originating interface
  template         Flow Exporter template configuration
  transport        Transport protocol
  ttl              Optional TTL or hop limit

R1(config-flow-exporter)#export-protocol ?
  netflow-v5  NetFlow Version 5
  netflow-v9  NetFlow Version 9

R1(config-flow-exporter)#export-protocol netflow-v9
R1(config-flow-exporter)#destination ?
  Hostname or A.B.C.D  Destination IPv4 address or hostname

R1(config-flow-exporter)#destination 172.12.34.4 ?
  vrf  Optional VRF label
  <cr>

R1(config-flow-exporter)#destination 172.12.34.4
R1(config-flow-exporter)#transport ?
  udp  UDP transport protocol

R1(config-flow-exporter)#transport udp ?
  <1-65535>  Port value

R1(config-flow-exporter)#transport udp 9996

R1(config-flow-exporter)#source fa0/1 ?
  <cr>

R1(config-flow-exporter)#source fa0/1
R1(config-flow-exporter)#exit
R1(config)#

So going from the top down, I’ve highlighted the 4 configs in the “netflow exporter (word)” command, which I will do the highlights bullet point style:

  • “export-protocol” – Shows you can configure it for either v5 or v9
  • “destination” – IP address where Netflow info is being sent to
  • “transport” to set the protocol (UDP only option) and port #
  • “source” the interface you are collecting data from

To verify your Netflow configuration:

R1(config)#do sh flow exporter EXPORT1
Flow Exporter EXPORT1:
  Description:              User defined
  Export protocol:          NetFlow Version 9
  Transport Configuration:
    Destination IP address: 172.12.34.4
    Source IP address:      172.12.15.1
    Source Interface:       FastEthernet0/1
    Transport Protocol:     UDP
    Destination Port:       9996
    Source Port:            56438
    DSCP:                   0x0
    TTL:                    255
    Output Features:        Not Used

R1(config)#

However the configuration is not complete, as we need to define the traffic we want to collect and export to the collector:

Flow Monitor – Defining the traffic to capture

R1(config)#flow monitor MONITOR1
R1(config-flow-monitor)#?
  cache        Configure Flow Cache parameters
  default      Set a command to its defaults
  description  Provide a description for this Flow Monitor
  exit         Exit from Flow Monitor configuration mode
  exporter     Add an Exporter to use to export records
  no           Negate a command or set its defaults
  record       Specify Flow Record to use to define Cache
  statistics   Collect statistics

R1(config-flow-monitor)#record ?
  netflow           Traditional NetFlow collection schemes
  netflow-original  Traditional IPv4 input NetFlow with origin ASs

R1(config-flow-monitor)#record netflow ?
  ipv4  Traditional IPv4 NetFlow collection schemes
  ipv6  Traditional IPv6 NetFlow collection schemes

R1(config-flow-monitor)#record netflow ipv4 ?
  as                      AS aggregation schemes
  as-tos                  AS and TOS aggregation schemes
  bgp-nexthop-tos         BGP next-hop and TOS aggregation schemes
  destination-prefix      Destination Prefix aggregation schemes
  destination-prefix-tos  Destination Prefix and TOS aggregation schemes
  original-input          Traditional IPv4 input NetFlow with ASs
  original-output         Traditional IPv4 output NetFlow with ASs
  prefix                  Source and Destination Prefixes aggregation schemes
  prefix-port             Prefixes and Ports aggregation scheme
  prefix-tos              Prefixes and TOS aggregation schemes
  protocol-port           Protocol and Ports aggregation scheme
  protocol-port-tos       Protocol, Ports and TOS aggregation scheme
  source-prefix           Source AS and Prefix aggregation schemes
  source-prefix-tos       Source Prefix and TOS aggregation schemes

R1(config-flow-monitor)#record netflow ipv4 original-input ?
  peer  Traditional IPv4 input NetFlow with peer ASs
  <cr>

R1(config-flow-monitor)#record netflow ipv4 original-input

So looking at that, I think we could have gotten away with just using “record netflow-traditional”, however I took the long way around doing that. I also noticed your choice between IPv4 and IPv6 traffic collection, and I am assuming that will be a difference between v5 and v9 but have not verified just yet!

Flow Monitor – Defining what “exporter” configuration to use to send data
R1(config-flow-monitor)#exporter EXPORT1
R1(config-flow-monitor)#exit
R1(config)#

To verify the monitor as well, the command is a bit long winded for my liking:

R1(config)#do sh flow monitor name MONITOR1
Flow Monitor MONITOR1:
  Description:       User defined
  Flow Record:       netflow ipv4 original-input
  Flow Exporter:     EXPORT1 (inactive)
  Cache:
    Type:              normal
    Status:            not allocated
    Size:              4096 entries / 0 bytes
    Inactive Timeout:  15 secs
    Active Timeout:    1800 secs
    Update Timeout:    1800 secs

R1(config)#

Now to put all this configuration together, we must lastly apply the Monitor to the interface being well… monitored:

R1(config)#int fa0/1
R1(config-if)#ip flow monitor MONITOR1 input
R1(config-if)#exit
R1(config)#

So now it should be actively capturing traffic, so I’ll make some from R5 with a continuous ping somewhere and see what we get with the CLI output of the cache:

R1(config)#do sh flow monitor name MONITOR1 cache
  Cache type:                               Normal
  Cache size:                                 4096
  Current entries:                               2
  High Watermark:                                2

  Flows added:                                   2
  Flows aged:                                    0
    РActive timeout      (  1800 secs)          0
    РInactive timeout    (    15 secs)          0
    РEvent aged                                 0
    РWatermark aged                             0
    РEmergency aged                             0

IPV4 SOURCE ADDRESS:       172.12.15.5
IPV4 DESTINATION ADDRESS:  224.0.0.5
TRNS SOURCE PORT:          0
TRNS DESTINATION PORT:     0
INTERFACE INPUT:           Fa0/1
FLOW SAMPLER ID:           0
IP TOS:                    0xC0
IP PROTOCOL:               89
ip source as:              0
ip destination as:         0
ipv4 next hop address:     0.0.0.0
ipv4 source mask:          /24
ipv4 destination mask:     /0
tcp flags:                 0x00
interface output:          Null
counter bytes:             1760
counter packets:           22
timestamp first:           04:07:03.643
timestamp last:            04:10:33.695

IPV4 SOURCE ADDRESS:       172.12.15.5
IPV4 DESTINATION ADDRESS:  172.12.23.100
TRNS SOURCE PORT:          0
TRNS DESTINATION PORT:     2048
INTERFACE INPUT:           Fa0/1
FLOW SAMPLER ID:           0
IP TOS:                    0x00
IP PROTOCOL:               1
ip source as:              0
ip destination as:         0
ipv4 next hop address:     172.12.123.3
ipv4 source mask:          /24
ipv4 destination mask:     /24
tcp flags:                 0x00
interface output:          Se0/0/0
counter bytes:             87900
counter packets:           879
timestamp first:           04:09:34.515
timestamp last:            04:10:36.799

R1(config)#

In this we can see both R5’s Multicast Traffic for OSPF to the “All OSPF routers” address of 224.0.0.5, and then our ping count going way up with the packets, which is what makes this a nice feature to check out directly on the CLI to identify top talkers in your network.

Now with Source or Destinations ports maybe be Publicly routable addresses being NAT’d, along with a well known port like 80 as the Source, but a random destination # from the host who sent it to get back to the LAN device.

Differences between v5 and v9

  • When configuring netflow on an interface, v5 only uses “ip flow ingress” on both ingress and egress interfaces, whereas v9 uses “ip flow ingress” on the igress interface and “ip flow egress” on the egress interface
  • A major difference (or not) between v5 and v9 is the flow-export is you can configure v5 settings while using v9 as the exporter version

 

Configuring a quicker, lighter version of Netflow to see on the CLI

This type of configuration is more real world for me, it is quickly configured and gives you a fast overview of network traffic, rather than exporting them to be made into a wonderful chart on some Network Mgmt Server somewhere.

The configuration goes like this:

R1(config-if)#ip flow ingress
R1(config-if)#ip route-cache flow
R1(config-if)#int s0/0/0
R1(config-if)#ip flow ingress
R1(config-if)#exit

Then you can see immediate results with this show command:

R1#sh ip cache flow
IP packet size distribution (9741 total packets):
   1-32   64   96  128  160  192  224  256  288  320  352  384  416  448  480
   .000 .000 .005 .994 .000 .000 .000 .000 .000 .000 .000 .000 .000 .000 .000

    512  544  576 1024 1536 2048 2560 3072 3584 4096 4608
   .000 .000 .000 .000 .000 .000 .000 .000 .000 .000 .000

IP Flow Switching Cache, 278544 bytes
  4 active, 4092 inactive, 23 added
  1308 ager polls, 0 flow alloc failures
  Active flows timeout in 30 minutes
  Inactive flows timeout in 15 seconds
IP Sub Flow Cache, 34056 bytes
  0 active, 1024 inactive, 0 added, 0 added to flow
  0 alloc failures, 0 force free
  1 chunk, 1 chunk added
  last clearing of statistics never
Protocol         Total    Flows   Packets Bytes  Packets Active(Sec) Idle(Sec)
——–¬†¬†¬†¬†¬†¬†¬†¬† Flows¬†¬†¬†¬† /Sec¬†¬†¬†¬† /Flow¬† /Pkt¬†¬†¬†¬† /Sec¬†¬†¬†¬† /Flow¬†¬†¬†¬† /Flow
IP-other            19      0.0         1    80      0.0       0.0      15.2
Total:              19      0.0         1    80      0.0       0.0      15.2

SrcIf         SrcIPaddress    DstIf         DstIPaddress    Pr SrcP DstP  Pkts
SrcIf         SrcIPaddress    DstIf         DstIPaddress    Pr SrcP DstP  Pkts
Fa0/1         172.12.15.5     Se0/0/0       172.12.23.100   01 0000 0800  5277
Se0/0/0       172.12.23.100   Fa0/1         172.12.15.5     01 0000 0000  4410
Se0/0/0       172.12.123.2    Local         172.12.123.1    59 0000 0000     1
Fa0/1         172.12.15.5     Null          224.0.0.5       59 0000 0000    35
R1#

When you have a customer yelling at you about why their LAN is going so dag nab slow, or the internet in general running these commands can immediately tell you who the “top talkers” are in the network.

I find this information so important it bears repeating:

  • “ip flow ingress”
  • “ip route-cache flow”
  • “sh ip cache flow”

And that’s it, you have an immediate view of every IP address of every node on the network transmitting data through this router, and can immediately identify if one of them is blasting out packets (an employee watching HD movies or a server doing a middle of the day backup), and immediately know where your problem is.

So it is nice if you have an enterprise Network with a Syslog / Mgmt Server to collect network information and make pretty charts, but for real network admins / engineers who need information RIGHT NOW on the fly there is the bottom configuration that works fantastic for pin-pointing “network slowness” issues immediately!

That is all the time I can put in tonight, I think that pretty sufficiently covers Netflow, I may post up one more thing regarding SNMP to commit it to memory and then I will be doing rapid BGP review and labbing that I will not be posting at all I do not believe.

So this wraps it up for today, I wanted to squeeze SNMP in, but that will have to wait for tomorrow then BGP blitz til exam day in about 5 days from today ūüôā

PPPoE: PPP Layer 2 Encapsulation Over Ethernet, Phases of connection setup explained, along with Terminology!

SLA_Topology_New

If needed I’ll just use the IP SLA Topology I configured for an demonstration purposes, but wanted to touch on maybe some CCNA topics of encapsulation of Ethernet interfaces, as well as PPPoE as the exam will ask some questions about it.

One interesting thing that I found when looking at my interfaces, the default and ONLY encapsulation type for an Ethernet interface shows as ARPA, while the default encapsulation type for my serial interface which gives me an option to change it is my Serial interface as seen below:

Serial Interface

R1#sh int s0/0/0
Serial0/0/0 is administratively down, line protocol is down
  Hardware is GT96K Serial
  MTU 1500 bytes, BW 1544 Kbit/sec, DLY 20000 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation HDLC, loopback not set

R1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R1(config)#int s0/0/0
R1(config-if)#encap ?
  frame-relay  Frame Relay networks
  hdlc         Serial HDLC synchronous
  lapb         LAPB (X.25 Level 2)
  ppp          Point-to-Point protocol
  smds         Switched Megabit Data Service (SMDS)
  x25          X.25

FastEthernet Interface

R1#sh int fa0/1
FastEthernet0/1 is up, line protocol is up
  Hardware is Gt96k FE, address is 001e.f797.f14b (bia 001e.f797.f14b)
  Internet address is 172.12.15.1/24
  MTU 1500 bytes, BW 100000 Kbit/sec, DLY 100 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation ARPA, loopback not set

R1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R1(config)#int fa0/1
R1(config-if)#encap ?
% Unrecognized command
R1(config-if)#encap

So I never actually knew that before, it’s very odd that I don’t see an encapsulation command being recognized on the FastEthernet interface as PPPoE is a combination of PPP and Ethernet.

Before we get into the mix, lets first review PPP quick

On an interface to change the encapsulation type to PPP, which comes in either PAP or CHAP, which are different in the ways that PAP is a much more passive authentication protocol that does not challenge other routers credentials whereas CHAP does.

Aside from the differences in PAP or CHAP, PPP encapsulation itself has some nice error detection AND error recovery features, which is a plus no matter which you use.

PAP does not challenge remote routers but simply authenticates the password which is sent in plain text, and once it authenticates everything is good to go.

CHAP will actively challenge another router for its username / password, requiring a matching username and password that is stored on both routers local username / password databases, and will authenticate after the challenge / response is ACK’d.

To configure CHAP, you need to configure a local username and password with the command “username something password something”, and issue the command “ppp auth chap” on the interface and it will begin running CHAP (As long as PPP is the encap type of course).

PPPoE connection establishment and Terminology

PPPoE is a protocol used primarily by ISP’s over a broadband connection, allowing PPP to be encapsulated inside Ethernet frames, and being transmitted over Ethernet interfaces.

Now the setup of the connection to the ISP is done in phases, and here is a list of those phases:

  1. “Active Discovery” phase, where the “PPPoE Client” is looking for (and finds) a “PPPoE Server” for Authentication, and once its successful it move onto the next phase of connection setup
  2. “Session Phase” where authentication and negotiation take place, it can be PAP or CHAP, but I have never personally seen a network using PAP for their PPPoE connection to their ISP
  3. Once the authentication and negotiation takes place and completes, the layer 2 encapsulation is now complete and data can be transmitted over the link.

So that is how PPPoE combines both PPP with Ethernet, to give us PPPoE connections!

IP SLA configuration, verification, “object tracking” configured and explained, quite an extensive subject and read so brace yourself!

SLA_Topology_New

IP SLA explanation and examples of when to use it

An IP SLA (Service Level Agreement) is an agreement between the Service Provider and (you) the customer, that you will get an agreed upon level of uptime / bandwidth for your money, and IP SLA configuration on a router is a mechanism to measure and verify that the service being provided by the carrier is within the agreed upon SLA.

This tracking can include both the uptime of service, and the bandwidth speed measured by the delay, when sending a packet to a destination and receiving a reply back.

It can be sent back to some sort of third party Syslog server to display in a nice graphical format for “Accounting” purposes to keep your ISP honest, however it is also used by other features at Layer 3 on the CLI that we as ROUTE candidates are interested in!

For example, and this is from the SWITCH Exam material, but HSRP (Hot Standby Routing Protocol) which runs on the LAN between a fail-over pair of Routers, that have identical configurations and remain in an Active / Standby role in case the Active router goes down it can fail over to the Standby.

As HSRP runs on the LAN side (making it a SWITCH topic), you can tie it back to IP SLA configurations, so if the Active router stops getting responses back from pings sent out its ISP gateway HSRP can tell the Standby router to make itself the Active router.

On a more ROUTE topic, you can also tie it into PBR, as Policy Routing does no kind of polling to verify the next hop you configured is alive / reachable – This is where IP SLA can be configured and tied into the PBR configuration to verify the configured next hop.

IP SLA configuration concepts and IP SLA Terminology (what things are called)

The most common use for IP SLA is to generate traffic originating from the local router in the form of a ping to another IP address, to confirm its reachable, you can measure much more detailed information such as Delay and Jitter but for the ROUTE we will keep it to tracking some pings.

Also you can configure multiple “SLA Operations” to multiple different destinations, that generate different types of traffic, to track completely different types of data statistics at the same time.

When configuring an “Operation” of IP SLA, the local router sending the traffic is called the “Sender”, and the destination device is called the “Receiver” and can be a router or a host depending on what kind of traffic you are sending / requesting back.

For example if an “Operation” is configured as a simple ping / response, the “Receiver” could be a laptop on a¬† remote network, as that device could respond back to the ping.

If you want more details like timestamps / delay it took to respond on the remote device / etc, you will need a “Receiver” like a Cisco router, that is capable of generating that “Operations” request as a regular web server or laptop may not be able to send the requested data (also things like looking at Jitter / Delay / other values).

Here is a quick list for exam day purposes of what types of traffic can be configured:

  • ICMP – Pings, jitter
  • RTP – VOIP traffic
  • TCP – Established Connections
  • UDP – Pings, jitter
  • DNS
  • HTTP
  • FTP

Although for detailed data (anything outside a ping response), you would need to configure the remote router to respond to the “Operation” configuration correctly.

However for ROUTE exam and really from what I’ve seen, the most common “Operation” to configure and troubleshoot is for pings / internet connectivity to the ISP, so that is what I will be configuring.

Enough theory and definitions, lets get configuring:

R1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R1(config)#ip sla ?
  <1-2147483647>          Entry Number
  auto                    IP SLAs Auto Configuration
  enable                  Enable Event Notifications
  ethernet-monitor        IP SLAs Auto Ethernet Configuration
  group                   Group Configuration or Group Scheduling
  key-chain               Use MD5 Authentication for IP SLAs Control Messages
  logging                 Enable Syslog
  low-memory              Configure Low Water Memory Mark
  reaction-configuration  IP SLAs Reaction-Configuration
  reaction-trigger        IP SLAs Trigger Assignment
  reset                   IP SLAs Reset
  responder               Enable IP SLAs Responder
  restart                 Restart An Active Entry
  schedule                IP SLAs Entry Scheduling

R1(config)#ip sla 1 ?
  <cr>

R1(config)#ip sla 1
R1(config-ip-sla)#

To start just from Global configuration mode, type “ip sla #”, and it will drop you into SLA configuration mode to configure the “operation”. I will break this up into different segments of ? output as there is quite a bit:

First looking at “Operation” options

R1(config-ip-sla)#?
IP SLAs entry configuration commands:
  dhcp         DHCP Operation
  dns          DNS Query Operation
  ethernet     Ethernet Operations
  exit         Exit Operation Configuration
  ftp          FTP Operation
  http         HTTP Operation
  icmp-echo    ICMP Echo Operation
  icmp-jitter  ICMP Jitter Operation
  path-echo    Path Discovered ICMP Echo Operation
  path-jitter  Path Discovered ICMP Jitter Operation
  tcp-connect  TCP Connect Operation
  udp-echo     UDP Echo Operation
  udp-jitter   UDP Jitter Operation
  voip         Voice Over IP Operation

R1(config-ip-sla)#icmp-echo ?
  Hostname or A.B.C.D  Destination IP address or hostname, broadcast disallowed

R1(config-ip-sla)#icmp-echo 5.5.5.5 ?
  source-interface  Source Interface (ingress icmp packet interface)
  source-ip         Source Address
  <cr>

R1(config-ip-sla)#icmp-echo 5.5.5.5 source-ip 1.1.1.1 ?
  <cr>

R1(config-ip-sla)#icmp-echo 5.5.5.5 source-ip 1.1.1.1
R1(config-ip-sla-echo)#

I could have ended it at a destination address, but for the heck of it I configured R1’s loopback to be a source-ip for the operation, so if either loopback goes down I assume the operation bites the dust.

Also note it dropped me into “echo” configuration mode highlighted in red, so I will look at my options using ? again and go from there.

Configuration of the icmp-echo “Operation”:

R1(config-ip-sla-echo)#?
IP SLAs Icmp Echo Configuration Commands:
  default            Set a command to its defaults
  exit               Exit operation configuration
  frequency          Frequency of an operation
  history            History and Distribution Data
  no                 Negate a command or set its defaults
  owner              Owner of Entry
  request-data-size  Request data size
  tag                User defined tag
  threshold          Operation threshold in milliseconds
  timeout            Timeout of an operation
  tos                Type Of Service
  verify-data        Verify data
  vrf                Configure IP SLAs for a VPN Routing/Forwarding instance

R1(config-ip-sla-echo)#frequency ?
  <1-604800>  Frequency in seconds (default 60)

R1(config-ip-sla-echo)#frequency 10 ?
  <cr>

R1(config-ip-sla-echo)#frequency 10
R1(config-ip-sla-echo)#

So I set IP SLA operation # 1 to do an ICMP echo sorced from 1.1.1.1 to remote destination 5.5.5.5 with a frequency of every 10 seconds, now to apply it and get this party started:

R1(config-ip-sla-echo)#exit
R1(config)#ip sla schedule 1 ?
  ageout      How long to keep this Entry when inactive
  life        Length of time to execute in seconds
  recurring   Probe to be scheduled automatically every day
  start-time  When to start this entry
  <cr>

R1(config)#ip sla schedule 1 life ?
  <0-2147483647>  Life seconds (default 3600)
  forever         continue running forever

R1(config)#ip sla schedule 1 life forever ?
  ageout      How long to keep this Entry when inactive
  recurring   Probe to be scheduled automatically every day
  start-time  When to start this entry
  <cr>

R1(config)#ip sla schedule 1 life forever start-time ?
  after     Start after a certain amount of time from now
  hh:mm     Start time (hh:mm)
  hh:mm:ss  Start time (hh:mm:ss)
  now       Start now
  pending   Start pending

R1(config)#ip sla schedule 1 life forever start-time now ?
  ageout     How long to keep this Entry when inactive
  recurring  Probe to be scheduled automatically every day
  <cr>

R1(config)#ip sla schedule 1 life forever start-time now
R1(config)#
ASR#5
[Resuming connection 5 to r5 … ]
[OK]

R5#debug ip packet
IP packet debugging is on

Lets see some IP SLA traffic! :
R5#
May 21 23:02:50.965: IP: tableid=0, s=1.1.1.1 (FastEthernet0/1), d=5.5.5.5 (Loopback5), routed via RIB
May 21 23:02:50.965: IP: s=1.1.1.1 (FastEthernet0/1), d=5.5.5.5, len 64, rcvd 4
May 21 23:02:50.965: IP: tableid=0, s=5.5.5.5 (local), d=1.1.1.1 (FastEthernet0/1), routed via FIB
May 21 23:02:50.965: IP: s=5.5.5.5 (local), d=1.1.1.1 (FastEthernet0/1), len 64, sending
R5#
May 21 23:03:00.963: IP: tableid=0, s=1.1.1.1 (FastEthernet0/1), d=5.5.5.5 (Loopback5), routed via RIB
May 21 23:03:00.967: IP: s=1.1.1.1 (FastEthernet0/1), d=5.5.5.5, len 64, rcvd 4
May 21 23:03:00.967: IP: tableid=0, s=5.5.5.5 (local), d=1.1.1.1 (FastEthernet0/1), routed via FIB
May 21 23:03:00.967: IP: s=5.5.5.5 (local), d=1.1.1.1 (FastEthernet0/1), len 64, sending
R5#
May 21 23:03:10.965: IP: tableid=0, s=1.1.1.1 (FastEthernet0/1), d=5.5.5.5 (Loopback5), routed via RIB
May 21 23:03:10.965: IP: s=1.1.1.1 (FastEthernet0/1), d=5.5.5.5, len 64, rcvd 4
May 21 23:03:10.965: IP: tableid=0, s=5.5.5.5 (local), d=1.1.1.1 (FastEthernet0/1), routed via FIB
May 21 23:03:10.965: IP: s=5.5.5.5 (local), d=1.1.1.1 (FastEthernet0/1), len 64, sending
R5#u all
All possible debugging has been turned off
R5#

As can be seen at the very top, if you exit once from all the way into SLA configuration, it drops you back into Global configuration mode.

From there “ip sla schedule # …” is the command to start the operation and defining for how long / often it should run, I gave mine a “life” of “forever” so it continuously runs forever and a start-time of “now” to turn it on immediately – Though there are options as to how long it runs and when to start it!

As can be seen I hopped over to R5 quick and ran a “debug ip packet” and sure enough we are now seeing a ping sourced from 1.1.1.1 hitting 5.5.5.5 every 10 seconds on the dot!

There are two verification commands, that give two very different outputs

“show ip sla statistics”

R1#sh ip sla stat
IPSLAs Latest Operation Statistics

IPSLA operation id: 1
        Latest RTT: 1 milliseconds
Latest operation start time: 23:12:51.010 UTC Sun May 21 2017
Latest operation return code: OK
Number of successes: 63
Number of failures: 0
Operation time to live: Forever

R1#

I started to highlight the important parts, but its all important, look at that info!

Operation start time, Operation id #, # of successes / fails, operation life time, this gives you the statistics of the operation at work whereas the second command is more geared towards the configuration itself (as you might guess by the name):

“show ip sla configuration”

R1#sh ip sla config
IP SLAs Infrastructure Engine-III
Entry number: 1
Owner:
Tag:
Operation timeout (milliseconds): 5000
Type of operation to perform: icmp-echo
Target address/Source address: 5.5.5.5/1.1.1.1
Type Of Service parameter: 0x0
Request size (ARR data portion): 28
Verify data: No
Vrf Name:
Schedule:
   Operation frequency (seconds): 10  (not considered if randomly scheduled)
   Next Scheduled Start Time: Start Time already passed
   Group Scheduled : FALSE
   Randomly Scheduled : FALSE
   Life (seconds): Forever
   Entry Ageout (seconds): never
   Recurring (Starting Everyday): FALSE
   Status of entry (SNMP RowStatus): Active
Threshold (milliseconds): 5000
Distribution Statistics:
   Number of statistic hours kept: 2
   Number of statistic distribution buckets kept: 1
   Statistic distribution interval (milliseconds): 20
Enhanced History:
History Statistics:
   Number of history Lives kept: 0
   Number of history Buckets kept: 15
   History Filter Type: None

R1#

This will also show a more complete view of life in terms of age-out time and all other fields I didn’t configure, so this is really the command to verify the configuration of the “Operation” where as “statistics” verification command is to see how the operation is succeeding or failing.

How SLA ties into PBR with something called “Enhanced Object Tracking”

I have created an addition to the Topology, a loopback interface, that will represent another route to the destination of 5.5.5.5:

SLA_Topology_New_2

Enhanced Object Tracking is the configuring of “track objects” that detect when the SLA is starting to slip, for example if it misses a ping it can be configured with a delay value so that it will not report back as unreachable until the delay value hits zero.

Track objects are configured because Cisco IOS does not allow for things like HSRP or PBR to refer directly back to IP SLA, however it can refer to a “track object” that then refers to the SLA that is running.

So first things first, the track object must locally reference the SLA # that PBR is also being performed on, so I will need to remove the configs and set them from R4… so one sec here:

R5#debug ip packet
IP packet debugging is on
R5#
May 22 00:07:19.470: IP: tableid=0, s=4.4.4.4 (FastEthernet0/1), d=5.5.5.5 (Loopback5), routed via RIB
May 22 00:07:19.470: IP: s=4.4.4.4 (FastEthernet0/1), d=5.5.5.5, len 64, rcvd 4
May 22 00:07:19.474: IP: tableid=0, s=5.5.5.5 (local), d=4.4.4.4 (FastEthernet0/1), routed via FIB
May 22 00:07:19.474: IP: s=5.5.5.5 (local), d=4.4.4.4 (FastEthernet0/1), len 64, sending
R5#u all
All possible debugging has been turned off
R5#

So we have the same config sourced from 4.4.4.4 going to 5.5.5.5 now.

So the first task is to set configure a track object:

R4(config)#track ?
  <1-1000>    Tracked object
  resolution  Tracking resolution parameters
  timer       Polling interval timers

R4(config)#track 5 ip sla 1 ?
  reachability  Reachability
  state         Return code state
  <cr>

R4(config)#track 5 ip sla 1 reachability ?
  <cr>

R4(config)#track 5 ip sla 1 reachability

Note here it drops me into configuration mode for this tracking object

R4(config-track)#?
Tracking instance configuration commands:
  default        Set a command to its defaults
  default-state  Default object state
  delay          Tracking delay
  exit           Exit from tracking configuration mode
  no             Negate a command or set its defaults

R4(config-track)#delay ?
  down  Delay down change notification
  up    Delay up change notification

R4(config-track)#delay down ?
  <0-180>  Seconds to delay

R4(config-track)#delay down 30 ?
  up  Delay up change notification
  <cr>

R4(config-track)#delay down 30
R4(config-track)#

So it is polling for reachability every 10 seconds, but it now will have a total of 30 seconds before this track object reports it as Down / Unreachable, and for this example we’ll need to tie this track number to an IP route configured for the destination address:

R4(config)#ip route 5.5.5.5 255.255.255.255 172.12.45.5 ?
  <1-255>    Distance metric for this route
  multicast  multicast route
  name       Specify name of the next hop
  permanent  permanent route
  tag        Set tag for this route
  track      Install route depending on tracked item
  <cr>

R4(config)#ip route 5.5.5.5 255.255.255.255 172.12.45.5 track 5

So now the route to that is being tracked, lets look at what it looks like in a some different scenarios on its own, before we involve PBR at all:

“show tracking” to verify your tracked object

R4(config)#do show track
Track 5
  IP SLA 1 reachability
  Reachability is Up
    1 change, last change 00:07:17
  Delay down 30 secs
  Latest operation return code: OK
  Latest RTT (millisecs) 1
  Tracked by:
    STATIC-IP-ROUTING 0
R4(config)#

So it’s looking pretty good, so lets shut down R5’s loopback and see how this goes:

R4(config)#do sh track
Track 5
  IP SLA 1 reachability
  Reachability is Up, delayed Down (23 secs remaining)
    1 change, last change 00:11:26
  Delay down 30 secs
  Latest operation return code: OK
  Latest RTT (millisecs) 3
  Tracked by:
    STATIC-IP-ROUTING 0
R4(config)#do sh ip sla stat
IPSLAs Latest Operation Statistics

IPSLA operation id: 1
        Latest RTT: NoConnection/Busy/Timeout
Latest operation start time: 00:21:09 UTC Mon May 22 2017
Latest operation return code: Timeout
Number of successes: 82
Number of failures: 3
Operation time to live: Forever

R4(config)#

Before I could get back to routers to issue the command again, I got this console message:

R4(config)#
May 22 00:21:31.104: %TRACKING-5-STATE: 5 ip sla 1 reachability Up->Down
R4(config)#

So lets look at some things to see what this has changed if anything:

IP Route Table:

R4#sh ip route

Gateway of last resort is not set

      1.0.0.0/32 is subnetted, 1 subnets
S        1.1.1.1 [1/0] via 172.12.14.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, 6 subnets, 2 masks
C        172.12.14.0/24 is directly connected, FastEthernet0/1
L        172.12.14.4/32 is directly connected, FastEthernet0/1
C        172.12.45.0/24 is directly connected, FastEthernet0/0
L        172.12.45.4/32 is directly connected, FastEthernet0/0
C        172.12.55.0/24 is directly connected, Loopback55
L        172.12.55.4/32 is directly connected, Loopback55
R4#

I tried to look at the route more detailed with “sh ip route 5.5.5.5” but said no route exists in the routing table, so I checked CEF to see if the route is even being considered at all:

R4#sh ip cef
Prefix               Next Hop             Interface
0.0.0.0/0            no route
0.0.0.0/8            drop
0.0.0.0/32           receive
1.1.1.1/32           172.12.14.1          FastEthernet0/1
4.4.4.4/32           receive              Loopback4
127.0.0.0/8          drop
172.12.14.0/24       attached             FastEthernet0/1
172.12.14.0/32       receive              FastEthernet0/1
172.12.14.1/32       attached             FastEthernet0/1

No it isn’t, if CEF doesn’t see you as a route, you are not a route. However of course in the running configuration:

R4#sh run | i 5.5.5.5
ip route 5.5.5.5 255.255.255.255 172.12.45.5 track 5
 icmp-echo 5.5.5.5 source-ip 4.4.4.4
access-list 5 permit 5.5.5.5
R4#

To round off the reaction of tying the SLA to the IP route, and after it went down the route seemed to just disappear from the router other than the running config, IP SLA is still running even though it continues to fail:

R4#sh ip sla stat
IPSLAs Latest Operation Statistics

IPSLA operation id: 1
        Latest RTT: NoConnection/Busy/Timeout
Latest operation start time: 00:45:19 UTC Mon May 22 2017
Latest operation return code: Timeout
Number of successes: 82
Number of failures: 148
Operation time to live: Forever

R4#

Now I did a “no shut” on Lo5 on R5, but the failures continue to increment on the “sh ip sla stat”, and the route is not being brought back into the route table.

I will have to re-visit this, as I’m not finding an answer on the internet very easily to this one, so I will need to research why this happens and revisit this so I can keep moving.

Configuring PBR with the Tracking Object

***One important note about Route-Maps and configuring tracking, if the same sequence has a line allowing the traffic, it will see the verify line and once it sees it cannot verify reachability it will go to the next set command which is “next-hop …” and route traffic there anyways so if you see any more commands within the same sequence that should be a huge red flag on exam day***

So I had to actually completely remove and reconfigure the tracking object, as it would not let go of that Track being “Down”, but once I did I tied it to my Policy Route like this:

R4(config)#access-list 5 permit 5.5.5.5
R4(config)#route-map PBR permit 10
R4(config-route-map)#match ip add 5
R4(config-route-map)#set ip next-hop ?
  A.B.C.D              IP address of next hop
  dynamic              application dynamically sets next hop
  encapsulate          Encapsulation profile for VPN nexthop
  peer-address         Use peer address (for BGP only)
  recursive            Recursive next-hop
  self                 Use self address (for BGP only)
  verify-availability  Verify if nexthop is reachable

R4(config-route-map)#set ip next-hop verify-availability ?
  A.B.C.D  IP address of next hop
  <cr>

R4(config-route-map)#set ip next-hop verify-availability 5.5.5.5 ?
  <1-65535>  Sequence to insert into next-hop list

R4(config-route-map)#set ip next-hop verify-availability 5.5.5.5 10 ?
  track  set the next hop depending on the state of a tracked object

R4(config-route-map)#set ip next-hop verify-availability 5.5.5.5 10 track ?
  <1-1000>  tracked object number

R4(config-route-map)#set ip next-hop verify-availability 5.5.5.5 10 track 5
R4(config-route-map)#route-map PBR permit 20
R4(config-route-map)#exit
R4(config)#

That is a really long command, I am hoping I don’t have to configure that off the top of my head on exam day!

So now I am going to see how THIS reacts to the tracking when the interface is shut down, hopefully it doesn’t just yank the route and not return it again, that was a bit frustrating to not resolve (yet):

R4#sh track
Track 5
  IP SLA 1 state
  State is Up, delayed Down (5 secs remaining)
    1 change, last change 00:11:09
  Delay up 5 secs, down 30 secs
  Latest operation return code: OK
  Latest RTT (millisecs) 1
  Tracked by:
    ROUTE-MAP 0
R4#sh track
May 22 01:40:43.256: %TRACKING-5-STATE: 5 ip sla 1 state Up->Down

After 30 seconds of being down, the tracking set it to down, so lets see if I “no shut” the interface if this will work any different than the static route:

R5(config-if)#no shut
R5(config-if)#
ASR#4
[Resuming connection 4 to r4 … ]

R4#sh ip route

Gateway of last resort is not set

      1.0.0.0/32 is subnetted, 1 subnets
S        1.1.1.1 [1/0] via 172.12.14.1
      4.0.0.0/32 is subnetted, 1 subnets
C        4.4.4.4 is directly connected, Loopback4
      5.0.0.0/32 is subnetted, 1 subnets
S        5.5.5.5 [1/0] via 172.12.45.5
      172.12.0.0/16 is variably subnetted, 6 subnets, 2 masks
C        172.12.14.0/24 is directly connected, FastEthernet0/1
L        172.12.14.4/32 is directly connected, FastEthernet0/1
C        172.12.45.0/24 is directly connected, FastEthernet0/0
L        172.12.45.4/32 is directly connected, FastEthernet0/0
¬†–More–
May 22 01:42:28.256: %TRACKING-5-STATE: 5 ip sla 1 state Down->Up
C        172.12.55.0/24 is directly connected, Loopback55
L        172.12.55.4/32 is directly connected, Loopback55
R4#

So not only was I able to to verify that it didn’t remove the 5.5.5.5 route even when it was unreachable to the SLA operation, and also saw it come back up within what I believe was the 5 second delay time I set on track object as “Up” delay value.

So I’m getting tired of beating this topic to death, so I’ll end it here, but if this were to be applied to an interface and the SLA tracking went to a Down state the PBR would be disabled and normal routing would take over.

My brain is kind of melting at this point and I need to try to get one topic down, so I will update the static routing portion if I find a good answer, cause I actually see that a lot at my work and the fact its just not bringing routes back into the table is odd to me.

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 ūüôā

Policy Based Routing / Local Policy Routing, and Route-Map configuration and explanation, review for exam day!

OSPF_Base_Topology

I will be using this Topology not as an OSPF course, but to perform Policy Based Routing (PBR) to influence how traffic travels from R5 to destination network 172.12.23.0, but first we need to review the basics of PBR:

  • PBR effects packets on the Ingress interface it is configured on, not traffic generated by the router it is configured on, that is called “Local Policy Routing”
  • Packets can be routed by interface, or by “next-hop” via Route-Maps
  • Route-Maps must be used for PBR, so ACL’s must also be configured

Now if using an interface to “set” as an exit, it should be a non-multi access link (Point-to-Point), so the traffic isn’t being put on a Broadcast segment and reaching multiple hosts. If configuring an interface, you can define multiple interfaces in the Route-Map clause, in case the first one goes down it has a backup interface to take if specified.

If using the “set” for a next-hop ip add, you simply define the IP address to set as the next hop, and you can also have multiple next-hop’s in case one route goes down.

When it comes to doing a “match” for incoming data traffic, there are two options with PBR:

  • Match on “match ip add #” where # is an ACL # defining what traffic is going to be impacted by the Route-Map
  • By “match length …” where it actually matches not on Prefix Length, but on Packet length, which is a very special case use like QoS

Before going any further, to touch on this Length value being matched on, it will match on the packets length itself. This is generally used as said for QoS, as VOIP or Video packets are generally relatively small and pre-determined sizes, and the “Length” match is measured in Bytes specifically.

I just “wr er” all my routers thinking I was done with OSPF, blah, let me spin them up again quick to show these values, I’ll be leaving Area 34 completely out of this example:

R1(config-router)#do sh ip 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
      172.12.0.0/16 is variably subnetted, 5 subnets, 2 masks
C        172.12.15.0/24 is directly connected, FastEthernet0/1
L        172.12.15.1/32 is directly connected, FastEthernet0/1
O IA     172.12.23.0/24 [110/65] via 172.12.123.3, 00:00:48, Serial0/0/0
                        [110/65] via 172.12.123.2, 00:00:48, 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-router)#

As can be seen, there is an equal Cost calculated by OSPF via R2 and R3 to the 172.12.23.0 /24 network, so lets run a few traceroutes from R5 to see which path is taken, if either is preferred:

R5#traceroute 172.12.23.100

Type escape sequence to abort.
Tracing the route to 172.12.23.100

  1 172.12.15.1 0 msec 4 msec 0 msec
  2 172.12.123.2 37 msec 32 msec 32 msec
  3 172.12.23.100 32 msec *  36 msec
R5#traceroute 172.12.23.100

Type escape sequence to abort.
Tracing the route to 172.12.23.100

  1 172.12.15.1 0 msec 4 msec 0 msec
  2 172.12.123.2 36 msec 33 msec 32 msec
  3 172.12.23.100 36 msec *  32 msec
R5#traceroute 172.12.23.100

Type escape sequence to abort.
Tracing the route to 172.12.23.100

  1 172.12.15.1 4 msec 0 msec 4 msec
  2 172.12.123.2 32 msec 32 msec 32 msec
  3 172.12.23.100 33 msec *  32 msec
R5#

As can be seen, R2 is the preferred route to the Switch at 172.12.23.100, so first we will configure it to prefer R3 as its next-hop to the Switch but we must first ask ourselves what the source address we want to matched on to incur this Policy.

For this I will use R5’s loopback 5.5.5.5, to confirm the inbound interface will differentiate the traffic coming from R5 as to where it sends it across the network.

So first we test 5.5.5.5 as a source for the traceroute, and get to work on R1’s config:

R5#traceroute 172.12.23.100 source 5.5.5.5

Type escape sequence to abort.
Tracing the route to 172.12.23.100

  1 172.12.15.1 0 msec 4 msec 0 msec
  2 172.12.123.3 36 msec 32 msec 32 msec
  3  *
    172.12.23.100 32 msec *
R5#traceroute 172.12.23.100 source 5.5.5.5

Type escape sequence to abort.
Tracing the route to 172.12.23.100

  1 172.12.15.1 0 msec 4 msec 0 msec
  2 172.12.123.3 36 msec 33 msec 32 msec
  3 172.12.23.100 32 msec *  32 msec

Now this is odd, I ran traceroute with source 5.5.5.5 a lot more times than on screen, but it seems to prefer the path to R3 rather than R2, however we are going to tell R1 to change its mind about that.

Before the configuration, though, I’d like to explain the steps I am about to take in order to accomplish the task of performing Policy Based Routing:

  • Configuring the ACL with the source traffic address (5.5.5.5) or if your doing it by length configuring your Packet Length… however that is done
  • Creating a Route-Map that matches on the ACL for source traffic defined
  • Apply the route map to the Ingress interface with the “ip policy route-map …” command

So lets get some dirt under R1’s fingernails:

R1#
R1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R1(config)#access-list 5 permit 5.5.5.5
R1(config)#route-map PBR permit 10
R1(config-route-map)#match ip add 5
R1(config-route-map)#set ip next-hop 172.12.123.2

R1(config-route-map)#route-map PBR permit 20
R1(config-route-map)#int fa0/1
R1(config-if)#ip policy route-map PBR
R1(config-if)#

I didn’t think I’d get that all in one smooth config with no errors, but there is each step in order, notice I didn’t bother messing with the “permit any” on the ACL, because the Route-Map Sequence 20 is what takes precedence in this configuration, and I ended it with the catch-all clause of “Let all other traffic not matched on flow normally” at the end.

So lets see if our traffic is now hitting that Route-Map at its most basic configuration, and taking R2 as the next hop instead of R3:

R5#traceroute 172.12.23.100 source 5.5.5.5

Type escape sequence to abort.
Tracing the route to 172.12.23.100

  1 172.12.15.1 0 msec 0 msec 4 msec
  2 172.12.123.2 32 msec 32 msec 32 msec
  3 172.12.23.100 33 msec *  33 msec
R5#traceroute 172.12.23.100 source 5.5.5.5

Type escape sequence to abort.
Tracing the route to 172.12.23.100

  1 172.12.15.1 0 msec 4 msec 0 msec
  2 172.12.123.2 36 msec 32 msec 32 msec
  3 172.12.23.100 32 msec *  32 msec

There it is, that simple!

Now I want to look at our options for matching certain criteria, if it has limits, and what those limits are (and I found the verbiage a bit odd as well) so lets check it out:

Packet Length Matches

R1(config)#route-map PBR permit 15
R1(config-route-map)#match length ?
<0-2147483647>  Minimum packet length

R1(config-route-map)#match length 100000 ?
<0-2147483647>  Maximum packet length

R1(config-route-map)#match length 100000 100000 ?
<cr>

So for Packet Length, you get one Primary and one Fallback option, and that’s it. It is not often Cisco puts its foot down on limiting backup criteria in commands, but it is obviously not a fan of matching a ton of Packet Length.

Also a very important note – It does not indicate it matches by the “byte” in the Route-Map ? output, so remember that for exam day, even though I’d really doubt it will come up on the ROUTE exam.

Interface Matches

R1(config-route-map)#match interface ?
(All interface types)

R1(config-route-map)#match interface serial 0/0/0 ?
(All interface types)

R1(config-route-map)#match interface serial 0/0/0 interface s0/0/1 ?
% Unrecognized command
R1(config-route-map)#match interface serial 0/0/0 interface ?
% Unrecognized command
R1(config-route-map)#match interface serial 0/0/0 serial 0/0/1 ?
(All interface types)

I left out the gigantic list of all interface types possible after the ?, but also left in the syntax errors I made, to demonstrate the syntax of this command. I kept going for a third interface but stopped there, so you can have up to 3+ redundant interfaces to “set” that traffic “match”ed by your PBR whereas Packet Length was limited to 2.

Next-Hop Matches

R1(config-route-map)#match ip next-hop 10.10.10.1 ?
<1-99>       IP access-list number
<1300-1999>  IP access-list number (expanded range)
WORD         IP standard access-list name
<cr>

R1(config-route-map)#match ip next-hop 10.10.10.1 10.10.10.2 ?
<1-99>       IP access-list number
<1300-1999>  IP access-list number (expanded range)
WORD         IP standard access-list name
<cr>

R1(config-route-map)#match ip next-hop 10.10.10.1 10.10.10.2 10.10.10.3 ?
<1-99>       IP access-list number
<1300-1999>  IP access-list number (expanded range)
WORD         IP standard access-list name
<cr>

R1(config-route-map)#$xt-hop 10.10.10.1 10.10.10.2 10.10.10.3 10.10.10.4 ?
<1-99>       IP access-list number
<1300-1999>  IP access-list number (expanded range)
WORD         IP standard access-list name
<cr>

R1(config-route-map)#$xt-hop 10.10.10.1 10.10.10.2 10.10.10.3 10.10.10.4

And it continues on presumable forever, so you can set backup next-hops until you pass out from exhaustion typing right on the keyboard.

So these are the ways we “set” where our traffic goes, with one interesting command that can prepend each of them, called “default” which immediately makes me think “default route” – Lets take a look:

R1(config-route-map)#set ip ?
address     Specify IP address
default     Set default information
df          Set DF bit
global      global routing table
next-hop    Next hop address
precedence  Set precedence field
qos-group   Set QOS Group ID
tos         Set type of service field
vrf         VRF name

 

R1(config-route-map)#set default ?
interface  Default output interface

Not only are they set in slightly different ways, but they also have nothing to do with a default route, it actually refers to the default behavior of the packets transmission.

If you see “default” in the PBR route-map sequence “set” commands, that means that it is telling the Route-Map to first use the default method of routing the packet (Ask the IP Route Table where to send it) before falling back to the PBR set on the interface to tell the packet how to be routed.

Its a very special use modifier in PBR, because it defeats the purpose of Path Manipulation, but it does exist (and is configured in slightly different syntax forms) that we need to know about.

Now a couple of verification commands to verify Policy Based Routing:

  • show ip policy
  • show route (shows route-maps configured)
  • traceroute (to verify path taken)
  • debug ip policy

So I’ve demonstrated how to use the traceroute command to verify the PBR is working, however lets look at the other examples quick:

R1#sh ip policy
Interface      Route map
Fa0/1          PBR
R1#

This is saying the Fa0/1 has a PBR configuration using Route-Map PBR, so lets look at that:

R1#sh route PBR
route-map PBR, permit, sequence 10
  Match clauses:
    ip address (access-lists): 5
  Set clauses:
    ip next-hop 172.12.123.2
  Policy routing matches: 18 packets, 1080 bytes
route-map PBR, permit, sequence 20
  Match clauses:
  Set clauses:
  Policy routing matches: 0 packets, 0 bytes
R1#

The red is my actual PBR configuration, while the blue is my catch-all clause on the Route-Map to allow all other traffic to route as normal.

As mentioned above, PBR only applies to Ingress traffic, however you can configure locally generated traffic on the router to do “Local Policy Routing”

Local policy routing is used for all practical purposes (at this point in my studies), for if you want to test your PBR assigned to an interface by creating a loopback on the local router, and using the “traceroute x.x.x.x source x.x.x.x” command to simulate traffic coming from that source.

It is configured with the following command in global configuration:

R1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R1(config)#ip local policy route-map PBR
R1(config)#int lo5
R1(config-if)#ip add 5.5.5
*May 19 23:26:26.635: %LINEPROTO-5-UPDOWN: Line protocol on Interface Loopback5, changed state to up
R1(config-if)#ip add 5.5.5.5 255.255.255.255
R1(config-if)#^Z
R1#t
*May 19 23:26:49.287: %SYS-5-CONFIG_I: Configured from console by console
R1#traceroute 172.12.23.100 source 5.5.5.5

Type escape sequence to abort.
Tracing the route to 172.12.23.100

  1 172.12.123.2 32 msec 36 msec 32 msec
  2 172.12.23.100 32 msec *  28 msec
R1#

So that is PBR in all its glory, that is as far as I’ll go into it as I have a LOT more ground to cover, however it is simply a route-map configured to manipulate traffic, then applied to an Ingress interface receiving that traffic.

Next up, NTP, only this time with only 2 routers that are both running 15.x IOS code to get a true idea of the full list of features, as 12.x does not support NTPv4 – See you there!

OSPF: Type 4 LSA’s, who creates them, why they create them, a relatively shorter post for once!

Type4LSA

Apologies for how terrible the Topology is, I took an existing picture and put some purple arrows leading off the ABR’s, indicating that this is actually where Type 4 LSA’s are created.

Now ASBR’s create Type 5 LSA’s which of course are External / Redistributed routes which are shared throughout the entire routing domain across different Area boundaries by ABR’s, however the ASBR does NOT create a Type 4 LSA to go with it, which is the LSA Type that describes how to get back to the ASBR.

Clear as mud? Good. The reason why the ASBR does not send out Type 4 LSA’s is the same concept surround the SPF Tree, that every router worries about its own Area, and let the routers in other Areas make their own dag nab SPF Tree’s.

That being said, when an ASBR is configured to be an ASBR, it flips on a bit in it’s Hello / Update that it is as ASBR with some Type 5 LSA’s, and every router in the Area gets these Type of LSA that is not an ABR will not produce Type 4 LSA’s.

To demonstrate this, I have done “no router ospf 1” on R1 / R2 / R3, and added it back with only the 172.12.123.0 /24 Area 0 network, with R1 doing default-information originate making it an ASBR.

The LSDB from R1 says it all:

R1#sh ip ospf data

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

                Router Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum Link count
2.2.2.2         2.2.2.2         294         0x80000002 0x009BDB 1
3.3.3.3         3.3.3.3         207         0x80000002 0x005D11 1
172.16.11.1     172.16.11.1     861         0x80000003 0x003BB8 1

                Net Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum
172.12.123.1    172.16.11.1     861         0x80000001 0x00E575

                Type-5 AS External Link States

Link ID         ADV Router      Age         Seq#       Checksum Tag
0.0.0.0         172.16.11.1     955         0x80000001 0x005594 1
R1#

Every router in the Area must match this exact table, and I went to R2 and R3 to verify they do have this exact same Database, I found that there is no Type 4 LSA’s because there are no ABR’s.

There is only a single Type 5 LSA and the Advertising router is R1, along with Type 1 and Type 2 LSA’s that also exist within a single Area. There is no LSA describing how to get back to the ASBR, because when R1 became an ASBR it flipped on a bit in it’s Hello / Update that indicated it’s now an ASBR, and all routers in the single Area installed the Type 5 LSA it is advertising with itself as the Advertising router.

If another Area is added to any router in this Area, it will create a Type 4 LSA to flood into that other Area, describing itself as the path back to the ASBR for that Area.

So say we had 5 routers total, this first is the ASBR, and the other 4 go hop by hop downstream to a destination. R1 being the ASBR and R2 being the first ABR in line, R2 will create a Type 4 LSA to flood into the new Area, saying “I am gateway to the ASBR holding X route your looking for.”

So R3 which is the next hop in line creates a Type 4 LSA, which tells the next that he (R3) is the gateway to the ASBR, when all he knows that R2 is saying he is the Gateway to the ASBR.

This goes on and one through different OSPF Areas, and is why ABR’s create the Type 4 LSA, but the ASBR will still have it installed in its Link State Database, because the SPF Tree Algorithm makes sure all OSPF Routers in an Area have matching LSDB’s.

And that, is the mystery unveiled about LSA Type 4’s. Sorry about the crappy Topology example, I figured it was more in the explanation and LSDB once we cleared out all other Areas and made a single Area 0.

I think that might be it for OSPF review, the rest of the material, I think I’ll risk taking a hit on exam day points, as I this stone has got to keep rolling on ūüôā

Tech notes for Tech folks!