Pages

Saturday, 13 May 2023

Enhanced Object Tracking

Overview

Enhanced Object tracking allows you to track specific objects on the device, such as the interface line protocol state, IP routing, route reachability, and to take action when the tracked object's state changes. This feature allows you to increase the availability of the network and shorten recovery time if an object state goes down.

The enhanced object tracking feature provides complete separation between the objects to be tracked and the action to be taken by a client when a tracked object changes. Thus, several clients such as HSRP, VRRP, or GLBP can register their interest with the tracking process; several clients can register to track the state of the same object. Each client is notified when the tracking object changes state, and each can take different action when the object state changes. Each tracked object is identified by a unique number that is specified in the configuration of the tracking object. Client processes use this number to track a specific object.

The tracking process periodically polls the tracked objects and notes any change in value. The changes in the tracked object are communicated to registered client processes, either immediately or after a specified delay. The object values are reported as being either up or down

An object monitors the statistics and state of the IP SLA instance and performs an action based on the status of the probe. This can be used by HSRP, VRRP to change priority levels.

You can configure a combination of tracked objects in a list and a flexible method for combining objects using boolean logic. This functionality includes the following capabilities:

  • Threshold: The tracked list can be configured to use a weight or percentage threshold to measure the state of the list. Each object in a tracked list can be assigned a threshold weight. The state of the tracked list is determined by whether the threshold has been met.
  • Boolean "and" function: When a tracked list has been assigned a boolean "and" function, each object defined within a subset must be in an up state so that the tracked object can become up.
  • Boolean "or" function: When the tracked list has been assigned a boolean "or" function, at least one object defined within a subset must be in an up state so that the tracked object can become up.

Enhanced Tracking Object (ETO) can be used to track a variety of objects including:

  • Interface line-protocol state
  • IP address
  • MAC address
  • Hostname
  • SNMP OID

ETO can be used to improve the performance and reliability of a variety of Cisco IOS features, including:

  • HSRP
  • VRRP
  • GLBP
  • PIM
  • OSPF
  • BGP

IP SLA Tracking

Enhanced Object Tracking can be used to track the status of an IP SLA; state or reachability.

To configure a tracking object:
  1. Create an IP SLA probe:

    R1(config)#ip sla 100
    R1(config-ip-sla)#icmp-echo 192.168.12.2
    R1(config-ip-sla-echo)#frequency 10
    R1(config-ip-sla-echo)#exit
    R1(config)#ip sla schedule 100 start-time now life forever

    Read more on details of the creation of IP SLA.

  2. Set up a tracking object based on that probe:
    1. Reference the IP SLA that will be tracked by the tracking object using the command track <obj-num> ip sla <sla-num> [state | reachability]. When configuring a tracking object, a boolean operation AND or OR can be specified where the results of a series of tracking objects can be compared.

      R1(config)#track 100 ip sla 100 reachability

    2. Configure a delay on the object to regulate the flapping of the object using the command delay [down <seconds> | up <seconds>].

      R1(config-track)#delay down 3 up 3

  3. Associate the tracking object with a client process: IP SLA tracking can be leveraged to improve the efficiency and reliability of static routing, dynamic routing using OSPF, BGP.

    In the following subsections, the tracking object is associated with:

    • Static routes
    • Interface state
    • IP reachability

Static Route Tracking

IP SLAs can be used in combination with static routes where the IP SLA is used to install or remove a static route from the Routing Information Base (RIB) only if certain conditions are met. A tracking object needs to be defined to track the results of the probe and implement an action.

Note: When installing a tracked static route, install the tracked static route after configuring the non-tracked static route.

R1(config)#track 100 ip sla 100
R1(config-track)#delay down 3 up 0
R1(config-track)#exit
R1(config)#ip route 4.4.4.4 255.255.255.255 192.168.13.2 10
R1(config)#ip route 4.4.4.4 255.255.255.255 192.168.12.2 track 100

Verification

show track <obj-num>

Verify a tracked object.

R1#show track
Track 100
  IP SLA 100 reachability
  Reachability is Down
    4 changes, last change 00:00:19
  Delay up 3 secs, down 3 secs
  Latest operation return code: Timeout
  Tracked by:
    STATIC-IP-ROUTING 0

show ip route

A tracked static route can be verified using the command show ip route.

R1#
*May 13 05:44:11.479: %TRACKING-5-STATE: 100 ip sla 100 reachability Up->Down
R1#show 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, H - NHRP, l - LISP
       + - replicated route, % - next hop override                    
                                                                      
Gateway of last resort is 192.168.13.2 to network 0.0.0.0              
                                                                      
S*    0.0.0.0/0 [10/0] via 192.168.13.2                                
      192.168.12.0/24 is variably subnetted, 2 subnets, 2 masks        
C        192.168.12.0/30 is directly connected, GigabitEthernet0/0    
L        192.168.12.1/32 is directly connected, GigabitEthernet0/0    
      192.168.13.0/24 is variably subnetted, 2 subnets, 2 masks        
C        192.168.13.0/30 is directly connected, GigabitEthernet1/0    
L        192.168.13.1/32 is directly connected, GigabitEthernet1/0    
      192.168.24.0/30 is subnetted, 1 subnets                          
D        192.168.24.0 [90/3328] via 192.168.13.2, 00:00:19, GigabitEthernet1/0
      192.168.34.0/30 is subnetted, 1 subnets                          
D        192.168.34.0 [90/3072] via 192.168.13.2, 00:12:18, GigabitEthernet1/0
*May 13 05:45:33.479: Track: 100 Up change delayed for 3 secs          
R1#                                                                    
*May 13 05:45:36.479: Track: 100 Up change delay expired              
*May 13 05:45:36.479: Track: 100 Change #5 ip sla 100, reachability Down->Up
R1#                                                                    
*May 13 05:45:36.483: %TRACKING-5-STATE: 100 ip sla 100 reachability Down->Up
R1#show 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, H - NHRP, l - LISP
       + - replicated route, % - next hop override                    
                                                                      
Gateway of last resort is 192.168.12.2 to network 0.0.0.0              
                                                                      
S*    0.0.0.0/0 [1/0] via 192.168.12.2                                
      192.168.12.0/24 is variably subnetted, 2 subnets, 2 masks        
C        192.168.12.0/30 is directly connected, GigabitEthernet0/0    
L        192.168.12.1/32 is directly connected, GigabitEthernet0/0    
      192.168.13.0/24 is variably subnetted, 2 subnets, 2 masks        
C        192.168.13.0/30 is directly connected, GigabitEthernet1/0    
L        192.168.13.1/32 is directly connected, GigabitEthernet1/0    
      192.168.24.0/30 is subnetted, 1 subnets                          
D        192.168.24.0 [90/3072] via 192.168.12.2, 00:23:48, GigabitEthernet0/0
      192.168.34.0/30 is subnetted, 1 subnets                          
D        192.168.34.0 [90/3072] via 192.168.13.2, 00:23:44, GigabitEthernet1/0

debug track <all>

R1#debug track
Track debugging is on
R1#
*May 13 05:45:33.479: Track: 100 Up change delayed for 3 secs
R1#
*May 13 05:45:36.479: Track: 100 Up change delay expired
*May 13 05:45:36.479: Track: 100 Change #5 ip sla 100, reachability Down->Up
R1#
*May 13 05:45:36.483: %TRACKING-5-STATE: 100 ip sla 100 reachability Down->Up

Interface State Tracking

Enhanced tracking objects can be used to monitor the state of an interface. This is implemented using the command track interface ip routing. This enables the tracking of the following states on an interface:

  • line protocol
  • IP address
  • IP routing: ability of an interface to route packets
If the line protocols is down, interface has no IP address, or IP routing is disabled, then the tracking object will consider the interface state to be down. The enhanced object track supports the assignment of an IP address to an interface through any of the following methods:
  • PPP/IPCP
  • DHCP
  • Conventional IP address configuration
  • Unnumbered interface

Enhanced object tracking of the state of an interface can be enabled by the following steps:

  1. Create a tracking list to track the state of the interface:
    • line-protocol: using the command track <obj-num> interface <interface-id> line-protocol.

      R4(config)#track 200 interface gigabitethernet1/0 line-protocol

    • ip routing: tracks an IP route in the routing table and the ability of an interface to route IP packets. track <obj-num> interface <interface-id> ip routing.
  2. Configure the delay period using command delay up <1-180> down <1-180>. The delay value is in seconds.

    R4(config-track)#delay down 0 up 3

  3. (Optional) Let the tracking object consider the carrier delay timer when tracking the interface status: carrier delay.
  4. (Optional) Configure the interval in which the tracking process polls the tracked object using the command track timer interface [<seconds > | msec <milliseconds>] . The default interval is 1 second. The msec keyword sets the interval down to milliseconds.

Tracking IP Route Reachability

Tracks the reachability of an IP route. A tracked object is considered up when a routing table entry exists for the route and the route is accessible.

  1. Configure the tracking object: track <obj-num> ip route <ip-address/prefix-length> reachability.
  2. Specify the delay values delay up <seconds> down <seconds>
  3. (Optional) Specify the VRF: ip vrf <vrf>.

Verification

show ip route track-table

Displays information about the IP route track table.

R1#show ip route track-table
  ip route 0.0.0.0 0.0.0.0 192.168.12.2 track 100 state is [up]
R1#

show track [object-number ]

Displays information about the all tracking lists or the specified list.

R4#show track 200
Track 200
  Interface GigabitEthernet1/0 line-protocol
  Line protocol is Up
    3 changes, last change 00:00:05
  Delay up 3 secs
  Tracked by:
    STATIC-IP-ROUTING 0

show track brief

Displays a single line of tracking information output.

R1#show track brief
Track   Object                           Parameter        Value Last Change
100     ip sla      100                  reachability     Up    00:31:10  
R1#

show track interface [brief]

Displays information about tracked interface objects.

R4#show track interface brief
Track   Object                           Parameter        Value Last Change
200     interface   GigabitEthernet1/0   line-protocol    Down  00:00:24
R4#show track interface
Track 200      
  Interface GigabitEthernet1/0 line-protocol
  Line protocol is Down (hw admin-down)
    2 changes, last change 00:00:29
  Delay up 3 secs
  Tracked by:  
    STATIC-IP-ROUTING 0 R4#

show track ip [object-number ] [brief ] route

Displays information about tracked IP-route objects.

show track resolution

Displays the resolution of tracked parameters.

R1#sho track resolution
Route type     Metric Resolution
static         10  
EIGRP          2560
OSPF           1  
ISIS           10  
BGP            2560

show track timers

Displays tracked polling interval timers.

R1#show track timers
Object type   Poll Interval Time to next poll
interface     1             expired
ip route      15            expired
ip sla        5             3.716  
application   5             expired
list          1             expired
stub          1             expired

Monday, 21 February 2022

Understanding Administrative Distance

Understanding Administrative Distance

Administrative Distance (AD) is a ranking of believability or trustworthiness of a routing information source. A router uses the routing information base (RIB) also, known as routing table, to determine the path to route traffic to destination networks. Routing information sources inform the router about paths to various networks. These routing information sources include: static routes, connected routes, routing protocols such as RIP, OSPF, BGP, EIGRP. Administrative distance is the first criterion that a router uses when making a path selection decision if two or more routing information sources provide route information for the same destination. It is important to note that before considering the AD in path selection criteria, a router always selects the most specific path to forward traffic regardless of the routing information source.

If a router learns about the path to a prefix from more than one source such as: OSPF, EIGRP, BGP, static routes, routers use AD assigned to each of those sources to to rank the routes and decide which routes should be installed into the routing table and therefore used for routing traffic. The AD is a value that ranges from 0 to 255. The lower the AD of a route source, the more believable its routing information and more likely that its offered routes will be installed into the routing table. Routes with an AD of 255 are not installed in the routing table as they are considered unbelievable. The router will install into the routing table the route from the source with the lowest AD. Each path installed in the routing table has an Administrative Distance. The AD of a route in the RIB indicates that the route was installed from a given source.

In many networks, only one routing protocol is operational. Some scenarios exist where two or more dynamic routing protocols are operational in a network simultaneously such as during a routing protocol migration where one routing protocol is being replaced by another. This results in routing devices in the network receiving routing information from various sources.

AD is a locally significant value. A router does not advertise the AD of its sources to its peers.

Default Administrative Distance

Cisco IOS assigns different ADs to all supported routing information sources. The default AD of the various routing information sources is shown in the following table:

The default administrative distances of different information sources
Route SourceDefault Administrative Distance
Connected interface 0
Static route 1
Enhanced Interior Gateway Routing Protocol (EIGRP) summary route 5
External Border Gateway Protocol (eBGP) 20
Internal EIGRP 90
IGRP 100
OSPF 110
Intermediate System-to-Intermediate System (IS-IS) 115
Routing Information Protocol (RIP) 120
Exterior Gateway Protocol (EGP) 140
On Demand Routing (ODR) 160
External EIGRP 170
Internal BGP (iBGP) 200
Unknown* 255

* A route with an administrative distance of 255 will not be installed in the routing table.

The default AD can be modified to implement traffic shaping where traffic follows specific routes according to the design of the network.

Note: AD is used in path selection only if the destination prefix is the same for routes from various routing information sources. In situations where the subnet mask is different, the routing information source with the more specific path will always be used regardless of the AD.

Floating Static Route

A floating static route is a static route whose administrative distance is greater than one (1). Usually, the AD of a floating static is higher than the administrative distance of a similar route that is currently installed in the RIB. The source of the route in the RIB could be a routing protocol such as RIP, EIGRP or another static route. By default, static routes have an administrative distance of 1. In the case of a floating static route, its administrative distance is configured to be higher than the AD of the source of the route to the same destination network in the RIB. This results in the floating static route acting as a backup route to the already existing route in the RIB. The floating static route is not installed in the routing table because its AD is higher than the AD of the current route. It only gets installed in the routing table only when the current route is not present in the routing table.

To configure a floating static route, use the global configuration mode command: ip route <network-address> <subnet-mask> <next-hop-ip> <1-255> where <network-address> is the destination network and <1-255> is the desired AD of the floating static route.

The following topology is used in the configuration of floating static routes.

Given the following EIGRP sourced route in the routing table with an AD of 90:

R2#show ip route 192.168.118.0
Routing entry for 192.168.118.0/24
  Known via "eigrp 1", distance 90, metric 2816, type internal
  Redistributing via eigrp 1
  Last update from 192.168.12.1 on GigabitEthernet0/0, 01:35:10 ago
  Routing Descriptor Blocks:
  * 192.168.12.1, from 192.168.12.1, 01:35:10 ago, via GigabitEthernet0/0
      Route metric is 2816, traffic share count is 1
      Total delay is 12 microseconds, minimum bandwidth is 1000000 Kbit
      Reliability 255/255, minimum MTU 1500 bytes
      Loading 1/255, Hops 1
R2#

To configure a floating static route to the destination network 192.168.118.0/24:

R2(config)#ip route 192.168.118.0 255.255.255.0 192.168.24.2 91

After configuring the following floating static route with an AD of 91, it will be installed in the routing table only if the EIGRP route fails, is removed from the routing table and no alternative EIGRP path to the destination network 192.168.118.0/24 is found with a lower administrative distance. This can be confirmed by viewing the status of static routes using the command: show ip static route

R2#show ip static route
Codes: M - Manual static, A - AAA download, N - IP NAT, D - DHCP,
       G - GPRS, V - Crypto VPN, C - CASA, P - Channel interface processor,
       B - BootP, S - Service selection gateway
       DN - Default Network, T - Tracking object
       L - TL1, E - OER, I - iEdge
       D1 - Dot1x Vlan Network, K - MWAM Route
       PP - PPP default route, MR - MRIPv6, SS - SSLVPN
       H - IPe Host, ID - IPe Domain Broadcast
       U - User GPRS, TE - MPLS Traffic-eng, LI - LIIN
       IR - ICMP Redirect
Codes in []: A - active, N - non-active, B - BFD-tracked, D - Not Tracked, P - permanent

Static local RIB for default

M  192.168.118.0/24 [91/0] via 192.168.24.2 [N]
R2#

The floating static route is displayed as being non-active with the code N

If an interface fails, say gigabitherethernet0/0 on device R2, then the floating static route is added to the routing table. This can be observed from the output of the debug ip routing

.....

*Feb 20 23:24:57.431: RT: add 192.168.115.0/24 via 192.168.24.2, eigrp metric [170/5376]
*Feb 20 23:24:57.431: RT: delete route to 192.168.118.0 via 192.168.12.1, eigrp metric [90/2816]
*Feb 20 23:24:57.431: RT: no routes to 192.168.118.0, delayed flush
*Feb 20 23:24:57.431: RT: delete network route to 192.168.118.0/24
*Feb 20 23:24:57.431: RT: updating eigrp 192.168.118.0/24 (0x0):
    via 192.168.24.2 Gi1/0 1048578

*Feb 20 23:24:57.431: RT: add 192.168.118.0/24 via 192.168.24.2, eigrp metric [170/5376]
R2(config-if)#
*Feb 20 23:24:57.431: RT: delete route to 192.168.112.0 via 192.168.12.1, eigrp metric [90/2816]
*Feb 20 23:24:57.431: RT: no routes to 192.168.112.0, delayed flush
*Feb 20 23:24:57.431: RT: delete network route to 192.168.112.0/24
*Feb 20 23:24:57.431: RT: updating eigrp 192.168.112.0/24 (0x0):
    via 192.168.24.2 Gi1/0 1048578

*Feb 20 23:24:57.431: RT: add 192.168.112.0/24 via 192.168.24.2, eigrp metric [170/5376]
*Feb 20 23:24:57.431: RT: delete route to 192.168.111.0 via 192.168.12.1, eigrp metric [90/2816]
*Feb 20 23:24:57.431: RT: no routes to 192.168.111.0, delayed flush
*Feb 20 23:24:57.431: RT: delete network route to 192.168.111.0/24
*Feb 20 23:24:57.431: RT: updating eigrp 192.168.111.0/24 (0x0):
    via 192.168.24.2 Gi1/0 1048578

*Feb 20 23:24:57.435: RT: add 192.168.111.0/24 via 192.168.24.2, eigrp metric [170/5376]
*Feb 20 23:24:57.435: RT: updating eigrp 192.168.118.0/24 (0x0):
    via 192.168.24.2 Gi1/0 1048578

*Feb 20 23:24:57.443: RT: updating static 192.168.118.0/24 (0x0):
    via 192.168.24.2 1048578

*Feb 20 23:24:57.447: RT: closer admin distance for 192.168.118.0, flushing 1 routes
*Feb 20 23:24:57.447: RT: add 192.168.118.0/24 via 192.168.24.2, static metric [91/0]
*Feb 20 23:24:57.519: RT: updating eigrp 192.168.118.0/24 (0x0):
    via 192.168.24.2 Gi1/0 1048578

*Feb 20 23:24:57.523: RT: rib update return code: 17
*Feb 20 23:24:59.115: %LINK-5-CHANGED: Interface GigabitEthernet0/0, changed state to administratively down
*Feb 20 23:24:59.119: is-up: GigabitEthernet0/0 0 state: 6 sub state: 1 line: 1
*Feb 20 23:25:00.115: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/0, changed state to down
*Feb 20 23:25:00.123: is-up: GigabitEthernet0/0 0 state: 6 sub state: 1 line: 1
R2(config-if)#
.....

From the output of the command debug ip route, initially, the alternate external EIGRP route with an administrative distance of 170 is installed for the lost path to the destination network 192.168.118.0/24. However, this path is deleted and replaced with the path from the floating static route because of its lower administrative distance of 91. The floating static route can be confirmed to have been installed in the routing table using the commands: show ip static route and show ip route 192.168.118.0 as shown below:

R2#show ip static route
Codes: M - Manual static, A - AAA download, N - IP NAT, D - DHCP,
       G - GPRS, V - Crypto VPN, C - CASA, P - Channel interface processor,
       B - BootP, S - Service selection gateway
       DN - Default Network, T - Tracking object
       L - TL1, E - OER, I - iEdge
       D1 - Dot1x Vlan Network, K - MWAM Route
       PP - PPP default route, MR - MRIPv6, SS - SSLVPN
       H - IPe Host, ID - IPe Domain Broadcast
       U - User GPRS, TE - MPLS Traffic-eng, LI - LIIN
       IR - ICMP Redirect
Codes in []: A - active, N - non-active, B - BFD-tracked, D - Not Tracked, P - permanent

Static local RIB for default

M  192.168.118.0/24 [91/0] via 192.168.24.2 [A]

R2#show ip route 192.168.118.0
Routing entry for 192.168.118.0/24
  Known via "static", distance 91, metric 0
  Routing Descriptor Blocks:
  * 192.168.24.2
      Route metric is 0, traffic share count is 1

Modification of Administrative Distance

Modification of the administrative distance of a routing protocol is usually not recommended when optimizing network traffic flows. Scenarios, however, exist that require the modification of the default AD of one routing source resulting in the paths advertised by that routing source being installed in the routing table such as complex redistribution particularly in large networks.

Usually modification of the AD of a routing information source results in the instantaneous ranking of the paths from the different sources. However, this depends of the speed of convergence of the routing information sources. With IGPs this takes place almost instantly. However, BGP is slow to converge and therefore if the AD of BGP is the lowest, the BGP learned route will take a while before it is installed into the RIB.

BGP

By default, iBGP has an AD of 200 and eBGP has an AD of 20.

In many networks running BGP, an IGP is usually configured to support routing in the internal network. BGP is usually used to share prefixes between external networks. The low AD of eBGP reflects this preference for eBGP routes to be preferred to IGP routes for external prefixes and IGP paths to be preferred for internal prefixes.

AD of eBGP and iBGP Routes

The AD of iBGP routes can be modified using the BGP address-family command: distance <ebgp-distance> <ibgp-distance>. In the following configuration, the eBGP AD is set to 15 and iBGP AD is set to 121.

R1(config)#router bgp 65000
R1(config-router)#address-family ipv4 unicast
R1(config-router-af)#distance ?
   <1-255> Administrative distance
  bgp      BGP distance
  mbgp     MBGP distance
R1(config-router-af)#distance bgp 15 121

AD of Specific BGP Routes

The AD of specific BGP routes can be modified using the command: distance <1-255> <network-address> <wildcard-mask>. In the following configuration, the AD for the route 192.168.1.0 with a subnet mask of 255.255.255.0 is set to 89.

R1(config)#router bgp 65000
R1(config-router)#address-family ipv4 unicast
R1(config-router-af)#distance 89 192.168.1.0 0.0.0.255

NOTE: After modifying the AD of BGP, take note that BGP is a little slow to converge so the configurations will take a while to take effect.

EIGRP

By default, the Administrative Distance for EIGRP internal routes is 90, external routes (routes redistributed into EIGRP) is 170 and EIGRP summary routes is 5. The default administrative distance in EIGRP can be modified for routes that are internal, external or per route. If the AD of a route is modified, EIGRP's Diffusing Update ALgorith (DUAL) is run due to the route configuration.

Modifying the AD of Internal and External Routes

The EIGRP default administrative distance for internal and external routes can be modified using the distance <internal> <external> command:

For EIGRP classic mode, the AD for internal routes is modified to 70 and external routes to 105.

R4(config)#router eigrp 1
R4(config-router)#distance eigrp 70 105

For EIGRP named mode, the AD modifications are implemented under address-family topology configuration mode:

R1(config)#router eigrp EIGRP-NAMED
R1(config-router)#address-family ipv4 unicast autonomous-system 1
R1(config-router-af)#topology base
R1(config-router-af-topology)#distance eigrp 70 105

Modifying AD for Individual Routes

The AD for individual routes can be modified using the command: distance <1-255> <network-address> <wildcard-mask>

R1(config)#router eigrp EIGRP-NAMED
R1(config-router)#address-family ipv4 unicast autonomous-system 1
R1(config-router-af)#topology base
R1(config-router-af-topology)#distance 60 192.168.12.0 0.0.0.3

Floating Summary Route

A floating summary route is created by configuring a default route and an administrative distance at the interface level or address family interface level. It is configured using the classical EIGRP interface command ip summary-address eigrp or EIGRP named mode af-interface command summary-address.

The configuration of a default summary route on an upstream router blocks the advertisement of more specific routes to downstream routers by intermediate routers. This problem can be resolved by configration of a floating summary route. On the upstream router that advertised the default summary route, an AD greater than the default EIGRP AD is added to the floating summary route.

R4(config)#interface g1/0
R4(config-if)#ip summary-address eigrp 1 0.0.0.0 0.0.0.0 252

On some IOS versions, adding the AD to a ip summary-address eigrp command is deprecated. The EIGRP router-mode command summary-metric is instead used:

R4(config)#interface g1/0
R4(config-if)#ip summary-address eigrp 1 0.0.0.0 0.0.0.0 252
%EIGRP: summary-address accepted but distance option deprecated; use summary-metric command for distance.
R4(config-if)#router eigrp 1
R4(config-router)#summary-metric 0.0.0.0 0.0.0.0 distance 252

OSPF

Given a routing table, EIGRP topology table and OSPF database table below, the modification of the OSPF AD affects what routes get populated in the RIB.

R1#show ip route | ex Connected
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, H - NHRP, l - LISP
       + - replicated route, % - next hop override

Gateway of last resort is not set
      
      192.168.12.0/24 is variably subnetted, 2 subnets, 2 masks
C        192.168.12.0/30 is directly connected, GigabitEthernet0/0
L        192.168.12.1/32 is directly connected, GigabitEthernet0/0
      192.168.13.0/24 is variably subnetted, 2 subnets, 2 masks
C        192.168.13.0/30 is directly connected, GigabitEthernet1/0
L        192.168.13.1/32 is directly connected, GigabitEthernet1/0
      192.168.24.0/30 is subnetted, 1 subnets
D        192.168.24.0
           [90/15360] via 192.168.12.2, 01:09:44, GigabitEthernet0/0
      192.168.34.0/30 is subnetted, 1 subnets
D        192.168.34.0
           [90/20480] via 192.168.12.2, 01:09:44, GigabitEthernet0/0
D     192.168.41.0/24
           [90/2575360] via 192.168.12.2, 00:14:37, GigabitEthernet0/0
D     192.168.42.0/24
           [90/2575360] via 192.168.12.2, 00:14:23, GigabitEthernet0/0
D     192.168.43.0/24
           [90/2575360] via 192.168.12.2, 00:14:08, GigabitEthernet0/0
D     192.168.44.0/24
           [90/2575360] via 192.168.12.2, 00:13:58, GigabitEthernet0/0
      192.168.45.0/30 is subnetted, 1 subnets
D        192.168.45.0
           [90/20480] via 192.168.12.2, 01:09:44, GigabitEthernet0/0
O IA  192.168.46.0/24 [110/3] via 192.168.13.2, 00:00:46, GigabitEthernet1/0
O IA  192.168.47.0/24 [110/3] via 192.168.13.2, 00:00:56, GigabitEthernet1/0
O IA  192.168.48.0/24 [110/3] via 192.168.13.2, 00:00:56, GigabitEthernet1/0
O IA  192.168.49.0/24 [110/3] via 192.168.13.2, 00:01:35, GigabitEthernet1/0

R1#show ip eigrp topology
EIGRP-IPv4 VR(EIGRP-NAMED) Topology Table for AS(1)/ID(192.168.13.1)
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
        r - reply Status, s - sia Status

P 192.168.24.0/30, 1 successors, FD is 1966080
        via 192.168.12.2 (1966080/1310720), GigabitEthernet0/0
P 192.168.34.0/30, 1 successors, FD is 2621440
        via 192.168.12.2 (2621440/1966080), GigabitEthernet0/0
P 192.168.12.0/30, 1 successors, FD is 1310720
        via Connected, GigabitEthernet0/0
P 192.168.45.0/30, 1 successors, FD is 2621440
        via 192.168.12.2 (2621440/1966080), GigabitEthernet0/0
P 192.168.13.0/30, 1 successors, FD is 1310720
        via Connected, GigabitEthernet1/0
P 192.168.41.0/24, 1 successors, FD is 329646080
        via 192.168.12.2 (329646080/328990720), GigabitEthernet0/0
P 192.168.42.0/24, 1 successors, FD is 329646080
        via 192.168.12.2 (329646080/328990720), GigabitEthernet0/0
P 192.168.44.0/24, 1 successors, FD is 329646080
        via 192.168.12.2 (329646080/328990720), GigabitEthernet0/0
P 192.168.43.0/24, 1 successors, FD is 329646080
        via 192.168.12.2 (329646080/328990720), GigabitEthernet0/0

R1#show ip ospf database

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

                Router Link States (Area 0)

Link ID         ADV Router      Age        Seq#       Checksum Link count
192.168.13.1    192.168.13.1    313        0x80000004 0x00E0EC 2
192.168.34.1    192.168.34.1    2347       0x80000004 0x0045B6 2
192.168.45.1    192.168.45.1    194        0x8000000B 0x002C78 6

                Net Link States (Area 0)

Link ID         ADV Router      Age        Seq#       Checksum
192.168.13.2    192.168.34.1    2347       0x80000002 0x00E44E
192.168.34.2    192.168.45.1    314        0x80000003 0x0023CE

                Summary Net Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum
192.168.46.0    192.168.45.1    230         0x80000001 0x009775
192.168.47.0    192.168.45.1    240         0x80000001 0x008C7F
192.168.48.0    192.168.45.1    240         0x80000001 0x008189
192.168.49.0    192.168.45.1    278         0x80000001 0x007693
R1#
R1#show ip ospf database router 192.168.45.1

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

                Router Link States (Area 0)

  Routing Bit Set on this LSA in topology Base with MTID 0
  LS age: 231
  Options: (No TOS-capability, DC)
  LS Type: Router Links
  Link State ID: 192.168.45.1
  Advertising Router: 192.168.45.1
  LS Seq Number: 8000000B
  Checksum: 0x2C78
  Length: 96
  Area Border Router
  Number of Links: 6
  
    Link connected to: a Stub Network
     (Link ID) Network/subnet number: 192.168.41.0
     (Link Data) Network Mask: 255.255.255.0
      Number of MTID metrics: 0
       TOS 0 Metrics: 1
    
    Link connected to: a Stub Network
     (Link ID) Network/subnet number: 192.168.42.0
     (Link Data) Network Mask: 255.255.255.0
      Number of MTID metrics: 0
       TOS 0 Metrics: 1
    
    Link connected to: a Stub Network
     (Link ID) Network/subnet number: 192.168.43.0
     (Link Data) Network Mask: 255.255.255.0
      Number of MTID metrics: 0
       TOS 0 Metrics: 1
    
    Link connected to: a Stub Network
     (Link ID) Network/subnet number: 192.168.44.0
     (Link Data) Network Mask: 255.255.255.0
      Number of MTID metrics: 0
       TOS 0 Metrics: 1
    
    Link connected to: a Stub Network
     (Link ID) Network/subnet number: 192.168.45.0
     (Link Data) Network Mask: 255.255.255.252
      Number of MTID metrics: 0
       TOS 0 Metrics: 1
    
    Link connected to: a Transit Network
     (Link ID) Designated Router address: 192.168.34.2
     (Link Data) Router Interface address: 192.168.34.2
      Number of MTID metrics: 0
       TOS 0 Metrics: 1
  

OSPF has a default AD of 110 for all OSPF routes: intra-area, inter-area and external (routes redistributed into OSPF). OSPF offers a variety of options for modifying the default administrative distance. The AD of OSPF can be modified for intra-area, inter-area and external routes. Additionally, the AD can be modified for a single route, group of routes, or all routes.

Intra-Area Routes

The OSPF AD of only intra-area routes can be modified using the OSPF router mode command distance ospf intra-area <1-255>:

R1(config)#router ospf 1
R1(config-router)#distance ospf intra-area 89

The routing table installs the OSPF intra-area routes instead of the EIGRP sourced routes because OSPF intra-area routes have an AD of 89 which is lower than the EIGRP AD of 90. Notice that the inter-area routes still have their AD at the default of 110.

Inter-area Routes

The AD of only OSPF inter-area routes can be modified using the OSPF router mode command: distance ospf inter-area <1-255> where distance is the desired AD.

R1(config)#router ospf 1
R1(config-router)#distance ospf inter-area 50

External Routes

The AD of routes redistributed into OSPF (external) can be modified using the router OSPF mode command distance ospf external 150.

R1(config)#router ospf 1
R1(config-router)#distance ospf external 150

The following output shows the effect of the previous modifications of the OSPF AD for intra-area, inter-area and external routes:

R1(config-router)#do show 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, H - NHRP, l - LISP
       + - replicated route, % - next hop override

Gateway of last resort is not set

      192.168.5.0/29 is subnetted, 1 subnets
O E2     192.168.5.8 [150/20] via 192.168.13.2, 00:00:10, GigabitEthernet1/0
      192.168.12.0/24 is variably subnetted, 2 subnets, 2 masks
C        192.168.12.0/30 is directly connected, GigabitEthernet0/0
L        192.168.12.1/32 is directly connected, GigabitEthernet0/0
      192.168.13.0/24 is variably subnetted, 2 subnets, 2 masks
C        192.168.13.0/30 is directly connected, GigabitEthernet1/0
L        192.168.13.1/32 is directly connected, GigabitEthernet1/0
      192.168.24.0/30 is subnetted, 1 subnets
D        192.168.24.0
           [90/15360] via 192.168.12.2, 02:13:45, GigabitEthernet0/0
      192.168.34.0/30 is subnetted, 1 subnets
O        192.168.34.0 [89/2] via 192.168.13.2, 00:06:05, GigabitEthernet1/0
O     192.168.41.0/24 [89/3] via 192.168.13.2, 00:06:05, GigabitEthernet1/0
O     192.168.42.0/24 [89/3] via 192.168.13.2, 00:06:05, GigabitEthernet1/0
O     192.168.43.0/24 [89/3] via 192.168.13.2, 00:06:05, GigabitEthernet1/0
O     192.168.44.0/24 [89/3] via 192.168.13.2, 00:06:05, GigabitEthernet1/0
      192.168.45.0/30 is subnetted, 1 subnets
O        192.168.45.0 [89/3] via 192.168.13.2, 00:06:05, GigabitEthernet1/0
O IA  192.168.46.0/24 [50/3] via 192.168.13.2, 00:06:05, GigabitEthernet1/0
O IA  192.168.47.0/24 [50/3] via 192.168.13.2, 00:06:05, GigabitEthernet1/0
O IA  192.168.48.0/24 [50/3] via 192.168.13.2, 00:06:05, GigabitEthernet1/0
O IA  192.168.49.0/24 [50/3] via 192.168.13.2, 00:06:05, GigabitEthernet1/0
R1(config-router)#

OSPF Changing AD of Specific Route

OSPF provides the capability for the AD of a specific route to be modified using the OSPF router mode command: distance <1-255> <network-adress> <wildcard>

R1(config)#router ospf 1
R1(config-router)#distance 21 192.168.44.0 0.0.0.255

OSPF AD for All Routes

To modify the AD for all OSPF routes, use the OSPF route mode command: distance <1-255>

Thursday, 13 May 2021

Linux: Change network interface name



The network interface name, e.g. eth0, is assigned to each hardware in the Linux kernel through the user space configuration mechanism, udev (see Section 3.5.11, “The udev system”), as it is found. The network interface name is referred as physical interface in ifup(8) and interfaces(5).
In order to ensure each network interface to be named persistently for each reboot using MAC address etc., there is a record file "/etc/udev/rules.d/70-persistent-net.rules". This file is automatically generated by the "/lib/udev/write_net_rules" program, probably run by the "persistent-net-generator.rules" rules file. You can modify it to change naming rule.

Caution

When editing the "/etc/udev/rules.d/70-persistent-net.rules" rules file, you must keep each rule on a single line and the MAC address in lowercase. For example, if you find "Firewire device" and "PCI device" in this file, you probably want to name "PCI device" as eth0 and configure it as the primary network interface.

Wednesday, 5 May 2021

Management Plane Security

 SSH

Step 1: Configuration of the hostname is one of the critical elements used to create an RSA key pair.

#hostname name

Step 2: Domain name is one of the elements used to create a key pair.

#ip domain-name domain-name

Step 3: Create local user names, privilege and password;

#username name privilege level secret password

Step 4: Generate RSA Key pair;

#crypto key generate rsa modulus size

Step 5: To enable remote SSH login on VTY terminals;

#line vty 0 4

#transport input ssh

Step 6: Enable authentication on the vty lines;

#login local

Enable

Enable secret gives level 15 privileges on an IOS device configured with #enable secret password.

Enable secret password appears in a router’s running configuration as a SHA-256 has. (4 in the string). Older IOS versions use MD5 (5 in hash).

Line

Line password authenticates a user logging to VTY, console or AUX. It shows up as clear text in running configuration. Encrypt the password using #service password encryption. This uses Type 7 encryption (Vigenere cipher). Cisco recommends the use of username password combination.




OSPF Optimization

 Accelerating OSPF Convergence

Can be done through faster Hellos and BFD (Bi-Directional Forwarding), and segmentation using areas. Use of areas reduces the SPF calculations

Faster Hello Packets

Default timers: 10 seconds, dead-interval; 40 seconds. OSPF should not be used for failure detection. Most lower layer protocols are faster at failure detection. OSPF default timers are often slow. Designers often alter these timers to effect faster converge and faster failure detection. Decreasing default timers will increase network traffic and packet processing demand on the hardware. In Cisco, to implement a one second hold interval with a hello-multiplier e.g. five minutes, send a hello packet every 200 milliseconds.

Bi-Directional Forwarding

BFD is an alternative to fast Hellos. It is not specific to OSPF. It provides a light-weight failure detection and is processed by the line card and not by the CPU. It primarily operates at the data-plane rather than the control-plane. BFD relies on the routing protocol neighborship establishment process to begin working. It doesnot help to lower the time it takes to establish a neighborship.

BFD operates in two modes; asynchronous and demand.

BFD Asynchronous

Systems exchange control packets. If the receipt of these packets stops, the session is dropped and the protocol that is configured with it is notified for example OSPF.

BFD Demand Mode

BFD assumes that another mechanism is being used to verify connectivity. Generally, asynchronous mode is used in normal production.

BFD Echo Function

The Echo function is used is any mode. Using the Echo function, a device is configured to send control packets towards a remote system with the expectation of having them loopback. This verifies the path to the remote system as well as the forwarding path of the remote system. BFD sessions can be configured independently in both directions.

Controlling OSPF LSA Generation and Propagation

Technologies include;

  • LSA Throttling

  • LSA Flood Pacing

  • LSA Group Pacing

  • LSA Retransmission Pacing

LSA Throttling

Limits the regeneration of repeat LSA updates for the same LSA when the topology changes. The ‘same’ LSA refers to common LSA ID, LSA Type, Advertising Router ID.

Normal LSA Update Behaviour

Initial LSA update is sent immediately and then rate-limited and cannot be resent for another five seconds. As updates come in, the message that is going to be sent may be modified but is not sent until the rate limit timer expires. A similar condition happens on received updates from a neighbor. By default, an update is only accepted if it is inter-leaved by at least one second. If it is not, the packet is dropped.

Waiting for the five seconds to expire during the intialization of OSPF and times of network change can sow the propagation of LSAs. OSPF throttling feature can be used to combat this. LSA throttling alters how OSPF handles the generation of OSPF update packets. You can do this through the configuration of three different parameters;

  • LSA start-interval

  • LSA hold-interval

  • LSA max-interval

The initial transmission of an update packet is always sent immediately it is generated. Pending no other features are configured, the generation of the second update packet is governed by the LSA start-interval. If an event occurs and the OSPF device needs to send an additional update packet, it waits until the start-interval expires. At this point, the LSA hold-interval begins. If an event occurs during this hold-interval, the device waits to send the update packet until that interval expires. If an update is required during the hold-interval, the next hold interval doubles. The hold-interval never exceeds the max-interval.

LSA Hold/Max Interval

The max-interval is used as an update packet ceiling in controlling how long the hold-interval could eventually become. This doubling happens every time an additional event occurs within the current hold-interval. When the max-interval is reached, then it is used as the hold-interval to delay LSA update packet generation until it expires. This remains true until no events occur within two hold-intervals or max-intervals depending on the situation. At this point, the process repeats and the start-interval is used if an event occurs.

LSA throttling is a good way to increase convergence times and slow down LSA update generation during instability.

OSPF Update Packet Pacing

Affects the generation of remote OSPF packets. Three different OSPF timers can be modified including; flooding pacing, re-transmission pacing and group pacing.

Flood Pacing

Allows you to control the packet spacing between consecutive update packets in the OSPF transmission queue. On Cisco, by default, if multiple packets exist in the transmission queue, they are sent every 33ms.

Retransmission Pacing

Simlar to flooding pacing but it affects the retransmisison queue. By default, if multiple packets exist in the retransmission queue, they are sent every 66ms.

Group Pacing

Controls how LSAs are refreshed by an OSPF device. Typical LSA refresh rate is 30 minutes. An LSA is refreshed when is age reaches 30 minutes. If each individual LSA works on its own independent timer, then packets would be retransmitted all the time especially in large networks. Group pacing allows LSAs that are expiring within the same general time to be sent simultaneously. By default, it is set to 240 seconds. LSAs expiring in 240 second interfval are held and sent at the same time. This provides efficiency and lowers demand on the network. Pacing timers generally work well and it is advised that they should not be modified. Any modification should be done after thorough testing.

Altering SPF Behaviour

SPF behavior can be altered through SFP throttling and incremental SPF.

SPF throttling operates similarly to LSA throttling. It provides a way to control when SPF is run after an event occurs. SPF uses three parameters; SPF start-interval, SPF hold-interval, SPF max-interval.

SPF Throttling

When an event initially occurs, the start-interval begins. On expiry, SPF is run using the new information and hold-interval begins counting down. If any new event occurs during this hold-interval, then the SPF process is run once it expires and a new hold interval begins but with twice the configured hold interval time (events occurring during the hold-interval waits until expiry). New hold-interval begins with twice the duration). If no event occurs within two hold-intervals, then the process resets and again is governed by the start-interval. The process of doubling the hold-interval when additional events occur continues until the hold interval time reaches the max-interval. Multiple intervals result in hold-interval equalling max-interval. The max-interval acts as a timer ceiling. Once reached, SPF runs every max-interval as long as additional events continue to occur. If events are not received within two max-intervals trigger process reset. Cisco defaults to five second start-interval and ten second hold and max-intervals.

Incremental SPF (iSPF)

ISPF changes how and when SPF is run. LSA Type 1 and 2 changes force SPF to run. Often this isn’t required as the SPT will now change for every device resulting in many nodes needlessly running SPF. ISPF makes the running of SPF conditional based on three conditions;

  • Whether a new leaf-node is being added or removed

  • Whether a change affects the SPT of a device.

  • Whether a change affects a limited part of the SPT.

Addition of a leaf-node does not affect SPT of existing devices hence a full SPF run is unneeded. ISPF prevents a full SPF run on non-local devices. It limits the SPF run on nodes directly associated with the changes. This includes devices where the addtion or removal will not locally modify connectivity.

Failure of a link that is not part of the SPT of a device: iSPF limits SPF run to only affected entries.

Link that is part of SPT Fails but does not affect all SPF devices: iSPF limits the devices that run SPF to those directly affected by the link failure. Only devices that are downstream from a failure will re-run SPF. Use of iSPF should be assessed based on environment.

Reducing the Size of the Link-State Database

To reduce the size of the LSDB implement the following;

  • Stub areas

  • LSA summarization

  • LSA Type 3 filtering

  • Prefix suppression

  • OSPF network types

Stub Areas

Limits the type of allowed LSAs

Most often used with single exit areas.

LSA Summarization

Different types of summarization include area summarization and external summarization.

Area Summarization

Used on ABRs controls how inter-area routes are generated and advertised into an area. Before summarization, routes are advertised with their original mask information. Only intra-area routes are summarised. An ABR must be part of the area where the targeted entries are sourced from. If they are not, it will not see the routes as intra-area and will not summarize them. The metric used for the summary route is based on the lowest existing metric. If this is not desired, configure a static metric.

Area summarization limits the advertisements that are known by devices in other areas (limits inter-area database entries). It provides protection from devices needing to make topology changes as they occur in other areas.

External Summarization

Summarizes external routing information (redistributed routes). During redistribution, limit the number of individual routes being inserted. Summarization is performed on the ASBR. Unstructured (discontiguous) summarization causes problems with route summary configuration. Summarization may introduce inefficient routing in areas with multiple ABRs.

Type 3 LSA Filtering

Controls Type 3 LSAs being advertised into or from an area. Provides granular control over advertisements into different areas. Ensure verification before using in production. Always verify behaviour when using multiple features.

Prefix Suppression

Allows suppression of advertisements of connected prefixes and can be implemented globally or at the inteface.

  • Prefix Suppression Globally: all connected prefixes that are not on loopbacks, passive interfaces or secondary interfaces are suppressed. Individual interfaces can have prefix suppression disabled to allow their addresses to be advertised.

  • Prefix Suppression Locally: all addresses are suppresssed including secondary addresses.

Prefix suppression is very handy on large networks to reduce the size of the LSDB. However, it can complicate troubleshooting.

OSPF Network Types

Some OSPF network types utilize additional LSAs than others. It is agood idea to assess whether the default options are the best. Ethernet is multi-access and OSPF defaults to broadcast network type requiring Type 2 LSA. It also requires a master/slave election causing a little delay in the neighborship formation process. If an Ethernet interface connects to another OSPF peer device, better to configure the interface as point to point network type. Here, the designated router (DR) is not required and Type 1 LSAs only are used.

Reducing the Effects of Restarts on OSPF

Graceful restart is covered in RFC 3623. it allows the restarting of a device without affecting the forwarding of traffic. This will require tweaks to normal OSPF operation. Device restart methods include; using power switch (hard) and using software (soft).

  • Hard Restart: all adjacencies are dropped. This type is generally not recommended.

  • Soft Restart: OSPF notifies peers of an impending restart by flushing all LSAs and sends empty Hello packets resulting in the dropping of all neighborships. Neighbors know immediately that a peer is going to become unavailable and make appropriate adjustments to their LSDB and routing.

Regardless of restart method, traffic flow is interrupted through re-routing or black-holing). Some platforms handle data-plane functions on the line-cards and control-plane and management functions by CPU.

With graceful restart, devices must separate data and control-plane functions. The devices must modify OSPF behaviour when a restart occurs. OSPF normally notifies peers of impending restrat by advertising LSAs originated by the device with a max LSA age. This brings down neighborships causing peers to run SPF to re-route traffic. Normal OSPF behaviour affects traffic. In graceful restart, devices alert peers of a restart. Neighbors lock the neighborship (assuming this feature is supported) maintaining the appearance of a full adjacency. Neighbors continue to send traffic to the device as normal. They, however, do not receive normal OSPF messages. The restarting device uses a graceful LSA to communicate with its neighbors. This is sent on all OSPF interfces with a link-local scope triggering neighbors to prepare for a restart. This LSA includes an expected grace period which is the duration of the assumed full neighborship.

Grace LSA

Are sent continually until they are acknowledged. If not acknowledged, normal restart commences (no graceful restart). The restarting device does not originate or flush LSAs and continues to use its pre-start routing tables until all neighborships return to normal operation. Neighborship establishment, after graceful restart, is the same as normal restart. The data path through the device remains uninterrupted. Grace LSAs are flushed by, restarting device, once neighborships are re-established runs through the normal OSPF process and re-originates its LSAs.

Graceful Restart Modes

Graceful restart defines two modes of operation; one for the restarting device and another for helper peer devices. The mode for peers is referred to as helper mode. Many more devices support helper mode than graceful restart mode. On Cisco, graceful restart is referred to as NSF (Non-Stop Forwarding). Full support is referred to as NSF capable. Helper support is referred to as NSF-aware.





Cisco: Troubleshooting EIGRP

 To verify layer 3 reachability, use the ping command.

To view EIGRP peers/neighbors and the interfaces that they are reachable through;

#show ip eigrp topology

#debug eigrp packets <terse>

watch out for stub configurations, passive interfaces, K-value mismatches summarization (IPv4, IPv6)

EIGRP issues are usually;

  • Neighbor adjacency issues

  • Routing issues

Neighbor Issues

  • Are interfaces operational

  • Does EIGRP AS match

  • Are interfaces enabled for EIGRP

  • Is there an interface that is configured as passive?

  • Authentication

  • Interface is down: The interface must be up/up.

  • Mismatched autonomous system numbers: Both routers need to be using the same autonomous system number.

  • Incorrect network statement: The network statement must identify the IP address of the interface you want to include in the EIGRP process.

  • Mismatched K values: Both routers must be using exactly the same K values.

  • Passive interface: The passive interface feature suppresses the sending and receiving of hello packets while still allowing the interface’s network to be advertised.

  • Different subnets: The exchange of hello packets must be done on the same subnet; if it isn’t, the hello packets are ignored.

  • Authentication: If authentication is being used, the key ID and key string must match, and the key must be valid (if valid times have been configured).

  • ACLs: An access control list (ACL) may be denying packets to the EIGRP multicast address 224.0.0.10.

  • Timers: Timers do not have to match; however, if they are not configured correctly, neighbor adjacencies could flap.

Verification of Neighbor Issues

#show ip eigrp neighbors <detail>

To identify whether the physical and data-link layers are operational;

#show ip interface brief

#show ip eigrp interface <detail>

  • AS: the AS specified in the router command

  • Interface: the interfaces over which EIGRP is configured

  • Peers: number of directly connected EIGRP neighbors on the interface

  • Xmit: Queue Unreliable and Reliable: The number of packets remaining in the unreliable and reliable queues

  • Mean SRTT: the average Smooth Round Trip Time (SRTT) interval in milliseconds, for all neighbors on the interface.

  • Pacing Time Unreliable and Reliable: number of milliseconds to wait after transmitting unreliable and reliable packets.

  • Multicast Flow Timers: number of milliseconds to wait for an acknowledgement of a multicast packet by all the neighbors before transmitting the next multicast packet.

  • Pending Routes: number of routes in the packets in the transmit queue that are waiting to be sent.

#show ip protocols

Routing Issues

  • Are networks being advertised?

  • Is ACL blocking advertisements?

  • Is there a discontiguous network issue?

  • Redistribution

  • Summarization

  • Bad or missing network command: The network command enables the EIGRP process on an interface and injects the prefix of the network the interface is part of into the EIGRP process.

  • Better source of information: If exactly the same network prefix is learned from a more reliable source, it is used instead of the EIGRP learned information.

  • Route filtering: A filter might be preventing a network prefix from being advertised or learned.

  • Stub configuration: If the wrong setting is chosen during the stub router configuration, or if the wrong router is chosen as the stub router, it might prevent a network prefix from being advertised.

  • Interface is shut down: The EIGRP-enabled interface must be up/up for the network associated with the interface to be advertised.

  • Split horizon: Split horizon is a loop-prevention feature that prevents a router from advertising routes out the same interface on which they were learned.

Verification of Routing Issues

#show ip interface brief

#show ip route eigrp

#show ip protocols

#show access-list

Troubleshooting Stub

#show ip protocols

#show ip eigrp neighbor detail

Troubleshooting Summarization

Discontiguous Subnets

Poorly summarized supernets; show ip route

Summarization requires at least one subnet in the RIB for summary to be advertised.