OSPF Adjacencies / OSPF Database

Lessons Learned:

OSPF initial configs – Routers R1 – R3 will be in Area 0.

router ospf 1234

log-adjacency-changes

network 192.168.12.0 0.0.0.255 area 0

network 192.168.13.0 0.0.0.255 area 0

!

Note: you can use an all zero’s network to advertise every interface into OSPF but that will limit the control you have over the networks.

EX:

Router ospf 0.0.0.0 255.255.255.255 are 0

Basically any Interface that has an IP Address assigned, ospf will be running on it

R1#sh ip protocols

Routing Protocol is "ospf 1234"

  Outgoing update filter list for all interfaces is not set

  Incoming update filter list for all interfaces is not set

  Router ID 192.168.13.1

  Number of areas in this router is 1. 1 normal 0 stub 0 nssa

  Maximum path: 4

  Routing for Networks:

    192.168.12.0 0.0.0.255 area 0

    192.168.13.0 0.0.0.255 area 0

Reference bandwidth unit is 100 mbps

  Routing Information Sources:

    Gateway         Distance      Last Update

  Distance: (default is 110)

Area 0 is going to be the backbone area for OSPF that all the other non- backbone areas are going to have to transit through to reach other. If you have more than one area you will need an Area 0.

Technically you can run all routers in Area 1 – but to transit to another area you would need to have and area 0 in the environment.

Once enabled we can issue a – “sh ip ospf” – This will show the basic information about the process       

R1#sh ip ospf

Routing Process "ospf 1234" with ID 192.168.13.1 -- > Says we’re running process # 1234. The router ID is 192.168.13.1

Start time: 00:14:01.904, Time elapsed: 00:09:13.688

Supports only single TOS(TOS0) routes

Supports opaque LSA  -- optional Capabilities

Supports Link-local Signaling (LLS) – Traffic engineering or NSF

Supports area transit capability  -- has to do with Virtual links

Router is not originating router-LSAs with maximum metric  -- Used for Stub router advertisement feature

Initial SPF schedule delay 5000 msecs – Default timers

Minimum hold time between two consecutive SPFs 10000 msecs  – Default timers

Maximum wait time between two consecutive SPFs 10000 msecs – Default timers  - this is a delay incase the process is rerun – gives a delay for changes in the network.

Incremental-SPF disabled

Minimum LSA interval 5 secs

Minimum LSA arrival 1000 msecs

LSA group pacing timer 240 secs

Interface flood pacing timer 33 msecs

Retransmission pacing timer 66 msecs

Number of external LSA 0. Checksum Sum 0x000000

Number of opaque AS LSA 0. Checksum Sum 0x000000

Number of DCbitless external and opaque AS LSA 0

Number of DoNotAge external and opaque AS LSA 0

Number of areas in this router is 1. 1 normal 0 stub 0 nssa

Number of areas transit capable is 0

External flood list length 0

    Area BACKBONE(0)  –This says the router currently two interfaces in the area 0

        Number of interfaces in this area is 2  - Number of interfaces

        Area has no authentication

        SPF algorithm last executed 00:00:02.308 ago

        SPF algorithm executed 4 times

        Area ranges are

        Number of LSA 3. Checksum Sum 0x00E639

        Number of opaque link LSA 0. Checksum Sum 0x000000

        Number of DCbitless LSA 0

        Number of indication LSA 0

        Number of DoNotAge LSA 0

        Flood list length 0

R1#

Basically the main verifications you’ll want to see form there is, what’s the process ID number. And whats the Router-ID.

Next:

We would want to look at the #SH IP OSPF Interfaces

FastEthernet0/0 is up, line protocol is up

  Internet Address 192.168.12.2/24, Area 0   --- The Interface Address and the Area

  Process ID 1234, Router ID 192.168.23.2, Network Type BROADCAST, Cost: 1 – Process ID (1234) and the Router ID and the network type (Broadcast) – The Cost value which is “1” which is derived from the interfaces bandwidth – the higher the bandwidth, the lower the cost value.

  Transmit Delay is 1 sec, State DR, Priority 1

  Designated Router (ID) 192.168.23.2, Interface address 192.168.12.2

  Backup Designated router (ID) 192.168.13.1, Interface address 192.168.12.1

  Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5  -- Timers

    oob-resync timeout 40

    Hello due in 00:00:06

  Supports Link-local Signaling (LLS)

  Index 1/1, flood queue length 0

  Next 0x0(0)/0x0(0)

  Last flood scan length is 1, maximum is 1

  Last flood scan time is 4 msec, maximum is 4 msec

  Neighbor Count is 1, Adjacent neighbor count is 1  -- We have one neighbor and one adjacency. Technically there can be a difference between the neighbor count and the adjacency.

    Adjacent with neighbor 192.168.13.1  (Backup Designated Router)  -- Here is the Address of the neighbor that we’re adjacent with.

  Suppress hello for 0 neighbor(s)

This will show all the detail about the link level attributes of OSPF. Details of the interface

If we want ot just see an overall summary about the links we’re running OSPF on. We can issue the command –

# Sh IP ospf brief

R2#sh ip ospf interface brief

Interface    PID   Area            IP Address/Mask    Cost  State Nbrs F/C

Fa0/1        1234  0               192.168.23.2/24    1     BDR   1/1

Fa0/0        1234  0               192.168.12.2/24    1     DR    1/1

R2#              

Here we see there are two interfaces running OSPF. All in process 1234, all in area 0, the addresses of the interfaces. The Cost values. Then the “state” of the adjacency. In this example, the local router is the DR and there is one neighbor on the link.

If there was any problems with the adjacency – Example – mismatched Timers.

I’ll change the hello-timers on the interface between R2 and R3

Then run the debug command:

R2#debug ip ospf adj

We lose the neighbor right away.

*Mar  1 00:25:56.015: %OSPF-5-ADJCHG: Process 1234, Nbr 192.168.23.3 on FastEthernet0/1 from FULL to DOWN, Neighbor Down: Dead timer expired

#Sh ip ospf Neighbors

Now I only have one neighbor on R3 instead of two.

Neighbor ID     Pri   State           Dead Time   Address         Interface

192.168.13.1      0   FULL/  -        00:00:31    192.168.13.1    Serial0/0

R3#

I can also verify the timer and neighbor adjacency with the debug command:

R3#debug ip ospf hello

OSPF hello events debugging is on

R3#

*Mar  1 00:29:59.659: OSPF: Send hello to 224.0.0.5 area 0 on FastEthernet0/0 from 192.168.23.3

*Mar  1 00:30:00.495: OSPF: Rcv hello from 192.168.23.2 area 0 from FastEthernet0/0 192.168.23.2

*Mar  1 00:30:00.499: OSPF: Mismatched hello parameters from 192.168.23.2

*Mar  1 00:30:00.499: OSPF: Dead R 40 C 20, Hello R 10 C 5  Mask R 255.255.255.0 C 255.255.255.0  -- Says – My dead interval received is 40, my local configured is 20.

Also – if the configured MTU is different we will not be able to form a full adjacency.

Example under the serial interface we change the MTU to 100. Then run the debug ip ospf command –

*Mar  1 00:30:55.251: OSPF: Retransmitting DBD to 192.168.23.3 on Serial0/0 [4]

*Mar  1 00:30:55.283: OSPF: Rcv DBD from 192.168.23.3 on Serial0/0 seq 0x11B8 opt 0x52 flag 0x7 len 32  mtu 1492 state EXSTART

*Mar  1 00:30:55.287: OSPF: Nbr 192.168.23.3 has larger interface MTU

R1#

We will be unable to form ADJ until this is corrected. Eventually after too many retransmissions the neighbors will time themselves out.

*Mar  1 00:34:04.387: OSPF: Retransmitting DBD to 192.168.23.3 on Serial0/0 [2]

*Mar  1 00:34:04.387: OSPF: Rcv DBD from 192.168.23.3 on Serial0/0 seq 0x1775 opt 0x52 flag 0x7 len 32  mtu 1500 state EXSTART – here is where we start to exchange copies of the database. Basic first exchange of LSA’s.

*Mar  1 00:34:04.387: OSPF: NBR Negotiation Done. We are the SLAVE

*Mar  1 00:34:04.387: OSPF: Send DBD to 192.168.23.3 on Serial0/0 seq 0x1775 opt 0x52 flag 0x2 len 172

*Mar  1 00:34:04.395: OSPF: Rcv DBD from 192.168.23.3 on Serial0/0 seq 0x1776 opt 0x52 flag 0x3 len 172  mtu 1500 state EXCHANGE

*Mar  1 00:34:04.395: OSPF: Send DBD to 192.168.23.3 on Serial0/0 seq 0x1776 opt 0x52 flag 0x0 len 32

*Mar  1 00:34:04.407: OSPF: Rcv DBD from 192.168.23.3 on Serial0/0 seq 0x1777 opt 0x52 flag 0x1 len 32  mtu 1500 state EXCHANGE

*Mar  1 00:34:04.407: OSPF: Exchange Done with 192.168.23.3 on Serial0/0

*Mar  1 00:34:04.407: OSPF: Synchronized with 192.168.23.3 on Serial0/0, state FULL

*Mar  1 00:34:04.407: %OSPF-5-ADJCHG: Process 1234, Nbr 192.168.23.3 on Serial0/0 from LOADING to FULL, Loading Done

*Mar  1 00:34:04.407: OSPF: Send DBD to 192.168.23.3 on Serial0/0 seq 0x1777 opt 0x52 flag 0x0 len 32

*Mar  1 00:34:04.891: OSPF: Rcv LS UPD from 192.168.23.3 on Serial0/0 length 88 LSA count 1

*Mar  1 00:34:04.947: OSPF: Build router LSA for area 0, router ID 192.168.13.1, seq 0x80000007

*Mar  1 00:34:04.959: OSPF: Rcv LS UPD from 192.168.23.2 on FastEthernet0/0 length 88 LSA count 1

R1#

OSPF Hello packets:

Example:

R1 sends a hello to R2.

R1 send a hello with its own Router-ID ex: a.b.c.d

R2 then sends a hello to R1 with tis router-ID ex: e.f.g.h AND the Router ID a.b.c.d

SH IP OSPF NEIGBORS:

R2#sh ip ospf neighbor

Neighbor ID     Pri   State           Dead Time   Address         Interface

3.3.3.3           1   FULL/DROTHER    00:00:35    192.168.23.3    FastEthernet0/1

10.45.4.4         1   FULL/BDR        00:00:34    192.168.23.4    FastEthernet0/1

1.1.1.1           1   FULL/BDR        00:00:35    192.168.12.1    FastEthernet0/0

I have 3 routers on this segment. The neighbor ID is the router-ID of the neighbor. One is the DR, one the BDR and the other is a DROTHER.  The table also lists the remaining Dead Time – the address of the neighbor and the interface it was learned over.

SH IP OSPF DATABSE:

If we show the database from any router in the topology, we should see that everyone has the identical information. For who are all the routers in the topology, and what are the connected links that they are advertising.

This is what you will see in the router LSA – LSA type 1

Additionally for any segments what are running the DR and BDR election –

The Designated Router will be generating the “Network LSA”.  The Network LSA is an optimization basically of the search function of the SPF algorithm. It’s used to cut down on the amount of flooding of LSA’s but it also simpliflies the look-up.

In a single area topology we should only see two LSA types in the database.

LSA Type 1 – which is the router LSA

LSA Type 2 – which is generated by the DR or Designated routers.

R2#sh ip ospf database

            OSPF Router with ID (192.168.23.2) (Process ID 1234)

                Router Link States (Area 0)

LSA – TYPE 1 – Router LSA

Link ID         ADV Router      Age         Seq#                Checksum Link count

1.1.1.1         1.1.1.1              111             0x80000003   0x005B30       4

3.3.3.3         3.3.3.3              104              0x80000003    0x00F986     3

192.168.23.2    192.168.23.2    161      0x80000004   0x00E83E      2

                Net Link States (Area 0)

LSA – TYPE 2  - Network

Link ID         ADV Router      Age         Seq#       Checksum

192.168.12.2    192.168.23.2    161         0x80000002 0x003A7E

192.168.23.2    192.168.23.2    161         0x80000003 0x002140

We can see there are 3 routers in the Topology – the TYPE 1 or Router LSA

We can also see there are 2 different Link States. LSA type 2 will tell everyone else in the network, how many links each router has – (Link count under LSA 1 section) and what are the properties of them. Ex: what are the cost values, the other router ADJ.

OSPF will use this information to build a graph of the topology, once all routers have synchronized the database and know what the topology looks like. OSPF will then use this information to SPF algorithm and output the shortest path tree.

The Key – on any link state protocol like OSPF and IS-IS. Is the database has to be identical on everyone in the area. Otherwise we would end up with different calculations for the Shortest path tree.

NOTE: Only between Area’s can routers have different views of the topology.

To see the details of what each router is advertising, for example link 1.1.1.1

We would issue the command:

R2#sh ip ospf database router 1.1.1.1

R2#sh ip ospf database router 1.1.1.1

            OSPF Router with ID (192.168.23.2) (Process ID 1234)

                Router Link States (Area 0)

  Routing Bit Set on this LSA

  LS age: 1005

  Options: (No TOS-capability, DC)

  LS Type: Router Links

  Link State ID: 1.1.1.1

  Advertising Router: 1.1.1.1  -- This is the advertising router and the router ID of Router 1

  LS Seq Number: 80000003

  Checksum: 0x5B30

  Length: 72

  AS Boundary Router

  Number of Links: 4  -- Router 1 says it has 4 different links that its advertising.

    Link connected to: a Stub Network  -- Says one of the networks is a stub network – this is the loopback of R1

     (Link ID) Network/subnet number: 1.1.1.1

     (Link Data) Network Mask: 255.255.255.255 

      Number of TOS metrics: 0

       TOS 0 Metrics: 1  -- This is the OSPF Cost value

Note: by default Loopback interfaces in OSPF are treated as Stub networks in database. Which means they are advertised with a / 32 mask.

    Link connected to: another Router (point-to-point)

     (Link ID) Neighboring Router ID: 3.3.3.3

     (Link Data) Router Interface address: 192.168.13.1

      Number of TOS metrics: 0

       TOS 0 Metrics: 64  (Cisco’s implementation of OSPF does not allow for TOS routing)

    Link connected to: a Stub Network

     (Link ID) Network/subnet number: 192.168.13.0

     (Link Data) Network Mask: 255.255.255.0

      Number of TOS metrics: 0

       TOS 0 Metrics: 64

    Link connected to: a Transit Network

     (Link ID) Designated Router address: 192.168.12.2  - Designated router on the segment.

     (Link Data) Router Interface address: 192.168.12.1  - Router 1 Address

      Number of TOS metrics: 0

       TOS 0 Metrics: 1

The rest of the output describes all the links as seen by R1 in the database.

Note: A transit network is a link that has adjacencies that go to the Designated Router.  Now all other routes in the toplopgy know that Router 1 has an ADJ to the DR

Network LSA type 2 – Is used to build the rest of the graph and find ADJ that the DR has. We need to ask the DR who are the other routers on the segment – The function of LSA type 2. Internally once the other routers see that R1 is connected to a DR. Then they will need to know what are the details about the DR’s advertisements.

From the output above we know the DR’s IP address is. (192.168.12.2 )  

R2#sh ip ospf database network 192.168.12.2

            OSPF Router with ID (192.168.23.2) (Process ID 1234)

                Net Link States (Area 0)

Note: Says this is a network link State in Area 0.

  Routing Bit Set on this LSA

  LS age: 912

  Options: (No TOS-capability, DC)

  LS Type: Network Links

  Link State ID: 192.168.12.2 (address of Designated Router)

  Advertising Router: 192.168.23.2  --

  LS Seq Number: 80000003

  Checksum: 0x387F

  Length: 32

  Network Mask: /24

        Attached Router: 192.168.23.2

        Attached Router: 1.1.1.1

Note: These are the routers that are connected to the DR. Now everyone else in the graph that the DR is connected to 192.168.23.2  and 1.1.1.1

The OSPF search function will continue to find all routers that are in the area and all ADJ, Ex who are Point-to-point, transit link etc.

 If it sees a links that is a transit link then we need to figure out who is the DR and who is it adjacent with. Once everyone has completed this search they now know what the overall topology looks like. They also know are all the cost values so they can calculate what is the best path to reach any destination.

The database can be used to find out why a particular router is forwarding in a certain destination.

Review –

From a # sh ip ospf database.

The first portion are the Router LSA’s. This is everyone in the area describing what they have directly connected. They will either have stub networks directly connected – like a loopback – or a a LAN segment that goes to no routers. Or they will have point to point or Transit adj.

PPP ADJ will be over like a PPP link and transit will be over an Ethernet or multipoint frame link

Verifying OSPF:

Once we know all the lookups are compete –

We can simply do a # sh ip route

OSPF Overview

Lessons learned:

OSPF –

Open standards Based

-RFC -23238 “OSPF Version 2”

Classless Link-State protocol

-Uses the Dijkstra SPF algorithm

-Maintains active adjacencies

-Supports VLSM

-Support both topology and NLRI summarization

============================================

OSPF is a Core topic in the CCIE R&S Exam.

OSPF Is open standards protocol – the RFC will explain all , packet formats, path selection, etc.

OSPF is a link state as well as a classless protocol, this can have effects on your implementation – as compared to RIP and EIGRP – OSPF forms active adjacencies and runs the SPF Algorithm. There is limitation as to the type of filtering and the logic of the path selection. Some things are set in stone based on how the RFC says the protocol works.

Since OSPF is a classless protocol by default there’s no such thing as auto-summary like in RIP and EIGRP.

It supports topology summarization and network layer reach-ability – NLRI.

NLRI summarization is most like how RIP and EIGRP summarizes, where we take multiple subnets and combine them in an aggregate. EX – multiple /24 routed and combining them into a /23 or /22.

Topology summarization has to do with the logic of how OSPF does intra-area look-ups different that inter-area look-ups, and external look-ups.

Note: the SPF is only used to do lookups on Intra-area destinations.

Enabling OSPF:

Enable the global process

-router ospf (process id)

-- process-id is locally significant

-Must be and up/up interface running IP

Note: Within in OSPF you can have multiple processes within the global routing table, determined by the process number. Technically you can have multiple OSPF processes that are unrelated running on the same router.

Typically you use the same ospf process # throughout the domain. The process # is not included in the any of the hello packets or LSA information.

Enable the interface process

-network (address) (wildcard ) area (area)

- ip ospf (process-id) area (Area)

Note: Once you initialize the process you must have at least one interface that is in the UP/UP state. This will be the interface that is used to generate the OSPF Router ID.

By Default the OSPF Router ID will prefer the highest loopback address – If there are no up loopback interfaces is the up state, it will prefer the next highest IP interfaces. Physical or logical interface OSPF will always prefer the loopback first.

OSPF Router-ID must be unique – it will be used throughout the domain and in the LSA’s. If there is duplicate Router-ID’s there will be issues when flooding the domain and eventually running the SPF process.

Once you define the global OSPF process, then you’ll need to choose what interfaces you want the process to run on and what their area identifies will be.

With the OSPF Area’s – that will be the boundary of the flooding domain, also where SPF will be run.

From a database perspective devices in Area 0 would not run the SPF for devices in Area 2, etc. Area 1 would also be separate from area 2 and other non-backbone areas.

You can issue the process under the interface or process level. They’re essentially going to have the same affect.

The command under the process is easier to read in the config.

OSPF Network Statement:

Enables OSPF on the interface

--wildcard mask does not relate to the subnet mask.

Most specific match wins.

Network 0.0.0. 255.255.255.255 are 0

Network 1.0.0.0 0.255.255.255 area 1

Network 1.2.0.0 0.0.255.255 area 2

Network 1.2.3.0. 0.0.0.255 area 3

Network 1.2.3.4 0.0.0.0 area 4

This config would actually work

Note: the network statement in EIGRP differs from OSPF because OSPF can have multiple network statements that overlap with each other. When the overlapping process does occur the – the network statement with the most specific match towards an interfaces IP address, will ultimately determine what area that link will run in.

Also, like EIGRP – the network statement does not relate to the subnet mask of the link. It’s simply used to match the address that is assigned to the interface.

The only time there would be a different between using the process or interface level command is if the link was unnumbered or not have an address at all.

We can verify OSPF is enabled:

-sh ip ospf

-ship ospf interface (brief)

Neighbor and topology discovery:

Like EIGRP, OSPF uses “hello” packets to discover neighbors

-transport via ip protocol 89 (OSPF)

-sent as multicast to 224.0.0.5 or 224.0.0.6, or unicast.

Hello packets contain attributes that neighbors must agree on to from adjacency

Once adjacency is negotiated, LSDB is exchanged. (link state database)

Once neighbors discover each other, they can form adjacencies.

Neighbors that are adjacent should exchange the link state database. Which means they can use it as an input to the SPF algorithm and come out with the SPF.

In certain cases, not all neighbors actually form an adjacency under normal configurations. Also under mis-configurations. This will ultimately mean that we cannot exchange the link state database and cannot use

The prefix’s for routing.

Negotiating OSPF adjacencies.

Neighbors must agree on attributes to form adjacency

-not all OSPF neighbors actually form adjacency

-most OSPF configuration problems happen at this stage.

Unique attributes include……

-local Router-ID  - used to identify inside the LSA database.

The SPF algorithm builds a graph of the network,  where the routers are considered the nodes. And the links are the growth of the network – the links that are connecting the nodes. The router id is used to identify the nodes.

-Local interface IP address

Common Attributes include….

-interface area-ID  -- Defines the flooding domain for OSPF> ex: All routers in Area 0 are in the same flooding domain.

-Hello interval & dead interval  -- Timers that determine how often we’re sending hello’s and how long to wait to declare a remote neighbor down. This is the opposite of EIGRP – where EIGRP’s Hellos’ timer tells the remote neighbor how long to wait before declaring the local neighbor down. For OSPF they are locally significant – how long does the local routers wait to declare a neighbor down. Not the neighbor telling the local router.

-interface network address –  Basically the subnet. Has to be on the same local subnet.

-Interface MTU --  This is a protection against problems in the data plane. EX: if the local MTU is 1000 and the remote is 1200 – all devices should be sharing the same MTU on the same segment

-Network Type – This is going to control how OSPF updates are sent across the link. How the next-hop value is calculated. Also what particular LSA’s are in the database do a calculation about the graph of the network. Doesn't necessarily have to match but it must be a compatible value. Basically mean that it is possible for LSA with the type Broadcast to form with non-broadcast LSA’s.

-Authentication –  OSPF supports Null, Clear text and MD5 auth. Null or type 0 is the default.

-Stub Flags –  Controls what LSA types the router will accept in the database for the particular area. Ex: If area 1 is a Stub area – all routers in that area need to agree on that flag. Same for a NSSA Area.

-Other optional capabilities

- Opaque LSA’s – used for extensiblity of other applications, for example MPLS traffic; Traffic engineering.

- NSF ex: Graceful restart – Normally for SUP redundancy example on a 6500 with Dual SUP’s

Once OSPF is establishes:

We need to go through a basic verification –

Is OSPF enabled on the interfaces and is it in the correct areas.

Verificaiton:

#sh ip ospf

# sh ip ospf interface

#Sh ip ospf interface brief  - Quick verification that the routers is running the right process, OSPF is enabled on the correct interfaces, and interfaces, and the correct area –ID.

Once we know that OSPF is running we can verify the adjacencies.

Verifications:

# Sh ip ospf neighbors  - if there’s issues between neighbors.

#debug ip ospf adj  -- shows actual hello exchange to help TS neighbors.

Once ADJ is established –

# sh ip ospf database  - The database from any devices in the area – Shows how anyone’s path selection in the network should occur because devices in the same area should have identical copies of the database.

Other EIGRP Features:

Lessons Learned:

Miscellaneous EIGRP Features:

--next hop self

--Maximum prefix

--Bandwidth pacing

--Default Metric

--Neighbor Logging

--Metric holddown

--Maximum ops

==========================

Command Reference

http://www.cisco.com/c/en/us/td/docs/ios/12_2/iproute/command/reference/fiprrp_r/1rfeigrp.html

Next hop self

command can be used on a mulitpoint interface – much like a Frame Relay hub and spoke or DMVPN Network. Where a route is advertised from the spoke up to the hub, when the Hub contiues to pass the route on it can set the next hop to itself.

Interface level command.

# Ip eigrp (AS) next-hop self

Bandwidth pacing –

Will limmit the amount of eigrp control plane bandwidth that can be used on a per link basis. By defualt with EIGRP the amount is 50% of the link bandwidth. This will really only matter on very low speed links. Channelized T1.

Maximum hops –

Maximum number of hops that you can have in the topology. This would be used to prevent the count to infinity problem like RIP has. Usually DUAL will corret this bacsed of the feasibitly condition. You can however limit the size of the EIGRP domain by using the number of hops, etc. 

EIGRP Router-ID

Lessons Learned:

Used for external Loop Prevention

-Don’t accept self-originated external routes

-Duplicate router-id’s can result in traffic black holes

Can be manually specified with

# eigrp router-id (address) under the process.

==========================================

It is important to have the router-id unique throughout the routing domain.

The EIRGP router-ID is only used in our external Routes for loop prevention.

It’s used to make sure a route that the local router is redistributing, does not get learned back in through EIGRP and then get installed in the topology or the routing table.

The idea is that if for some reason external EIGRP has a lower administrative distance then the protocol were redistributing from, then there could potentially be a loop.

Really unless you manually change the External EIGRP Distance to be a lower value. The default External EIGRP value is 170 – which is higher than all the other IGP’s.

Topology.

On R1 I added a loopback with the IP of 10.1.1.1 and redistributed connected under EIGRP.

This route will now show by default as an external route on all the other routers, example:

D EX    10.1.1.0 [170/156160] via 192.168.14.1, 00:03:29, FastEthernet1/0

D    192.168.23.0/24 [90/30720] via 192.168.34.3, 00:17:43, FastEthernet0/0

                     [90/30720] via 192.168.24.2, 00:17:43, FastEthernet0/1

C    192.168.34.0/24 is directly connected, FastEthernet0/0

R4#

R1#sh ip eigrp topology 10.1.1.0 255.255.255.0

IP-EIGRP (AS 300): Topology entry for 10.1.1.0/24

  State is Passive, Query origin flag is 1, 1 Successor(s), FD is 128256

  Routing Descriptor Blocks:

  0.0.0.0, from Rconnected, Send flag is 0x0 – From Redistributed connected

      Composite metric is (128256/0), Route is External

      Vector metric:

        Minimum bandwidth is 10000000 Kbit

        Total delay is 5000 microseconds

        Reliability is 255/255

        Load is 1/255

        Minimum MTU is 1514

        Hop count is 0

      External data:

        Originating router is 192.168.14.1 (this system) – This is my router Id and I am the local originator of this route.

        AS number of route is 0

        External protocol is Connected, external metric is 0

        Administrator tag is 0 (0x00000000)

What this will prevent is the route going from R1 – to R2 – then R3 and back to R1. With internal routes you wouldn't have to worry about this because of the DUAL algorithm and the feasibility condition.

In the case of the eternal routing information, we lose visibility about the original loop prevention mechanism of the source protocol. Meaning either from OSPF or BGP when sending the route into BGP.  

EIGRP will add an additional error check that says, if I receive an external route in that has my local ROUTER-ID in the external field. Do not accept the route.

This can be an issue if there’s duplicate router ID in the network, this means they would not accept each other’s external route information. Can be hard to troubleshoot if you’re not familiar with the Router-ID and its purpose.

Example:

Let’s look at R4 and its route to 10.1.1.0 /24

R4#sh ip route 10.1.1.1

Routing entry for 10.1.1.0/24

  Known via "eigrp 300", distance 170, metric 156160, type external

  Redistributing via eigrp 300

  Last update from 192.168.14.1 on FastEthernet1/0, 00:18:58 ago

  Routing Descriptor Blocks:

  * 192.168.14.1, from 192.168.14.1, 00:18:58 ago, via FastEthernet1/0

      Route metric is 156160, traffic share count is 1

      Total delay is 5100 microseconds, minimum bandwidth is 100000 Kbit

      Reliability 255/255, minimum MTU 1500 bytes

      Loading 1/255, Hops 1

R4#

  192.168.24.2 (FastEthernet0/1), from 192.168.24.2, Send flag is 0x0

      Composite metric is (158720/156160), Route is External

      Vector metric:

        Minimum bandwidth is 100000 Kbit

        Total delay is 5200 microseconds

        Reliability is 255/255

        Load is 1/255

        Minimum MTU is 1500

        Hop count is 2

      External data:

        Originating router is 192.168.14.1  - Route is originated form this router.

        AS number of route is 0

        External protocol is Connected, external metric is 0

        Administrator tag is 0 (0x00000000)

R4#

Now on R4 under the EIGRP Process – if I change the router ID to match that or the originating router - 192.168.14.1   - I will not be able to install the route now in the routing table.

Now if I look at the topology again – the route is not in the routing table.

R4#sh ip eigrp topology 10.1.1.0/24

% IP-EIGRP (AS 300): Route not in topology table

R4#

Although the other neighbors still have the route.

R3#sh ip route 10.1.1.0

Routing entry for 10.1.1.0/24

  Known via "eigrp 300", distance 170, metric 158720, type external

  Redistributing via eigrp 300

  Last update from 192.168.23.2 on FastEthernet1/0, 00:02:48 ago

  Routing Descriptor Blocks:

  * 192.168.23.2, from 192.168.23.2, 00:02:48 ago, via FastEthernet1/0

      Route metric is 158720, traffic share count is 1

      Total delay is 5200 microseconds, minimum bandwidth is 100000 Kbit

      Reliability 255/255, minimum MTU 1500 bytes

      Loading 1/255, Hops 2

R3#

We can easily prevent this by making sure all router ID’s are unique. It’s also best practice to manually specify the router ID on all routers. 

EIGRP Route Filtering

Lessons Learned:

EIGRP Route Filtering:

Eigrp inbound route filtering 

Distribute-list

--standard access list

--extended acess-list 

Source is route source, destination is prefix

Offset-List

Distance

-255=infinite 

-can be per neighbor 

route-map

-metric filter

-route tag filter 

--------------------------------  

Topology:

Filtering in EIGRP is similar to RIP, we can use standard or extended ACL to filter was we receive IN an interface or what we send OUT.

The extended ACL will not only match the route but the source of the route. 

We can see the source of a route the following way. 

R2#sh ip route 192.168.14.0 

Routing entry for 192.168.14.0/24

  Known via "eigrp 500", distance 90, metric 30720, type internal

  Redistributing via eigrp 500

  Last update from 192.168.24.4 on FastEthernet0/0, 00:06:45 ago

  Routing Descriptor Blocks:

    192.168.24.4, from 192.168.24.4, 00:06:45 ago, via FastEthernet0/0

      Route metric is 30720, traffic share count is 1

      Total delay is 200 microseconds, minimum bandwidth is 100000 Kbit

      Reliability 255/255, minimum MTU 1500 bytes

      Loading 1/255, Hops 1

  * 192.168.12.1, from 192.168.12.1, 00:06:45 ago, via FastEthernet0/1

      Route metric is 30720, traffic share count is 1

      Total delay is 200 microseconds, minimum bandwidth is 100000 Kbit

      Reliability 255/255, minimum MTU 1500 bytes

      Loading 1/255, Hops 1

Here we see the route 192.168.14.0 is learned from two neighbors.

from 192.168.24.4

from 192.168.12.1 

These are the interface IP addresses of the neighbors that we're learning the route from. 

Whatever shows up in the FROM field in the output is going to be the ROUTE SOURCE

As a filtering example we can say we only learn the route from the first router listed in the output - 192.168.24.4

To do this - on the router where we want to filter the routes. We need to create and extended ACL. 

Example:

access-list 100 deny ip host 192.168.12.1 host 192.168.14.0

access-list 100 permit ip any any

!

This basically says to deny the route source of 192.168.12.1 from sending us the prefix for the network192.168.14.0 

Then permit any any. 

Then under the EIGRP process - 

R2(config-router)#distribute-list 100 in 

Note: 

After we apply the list the routers should recalculate the topology:

*Mar  1 00:43:38.463: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 500: Neighbor 192.168.12.1 (FastEthernet0/1) is resync: route configuration changed

*Mar  1 00:43:38.463: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 500: Neighbor 192.168.24.4 (FastEthernet0/0) is resync: route configuration changed

*Mar  1 00:43:38.467: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 500: Neighbor 192.168.23.3 (FastEthernet1/0) is resync: route configuration changed

R2#

We now see that we're only learning the route from 192.168.24.4 and not 192.168.12.1 any longer. 

R2#sh ip route 192.168.14.0

Routing entry for 192.168.14.0/24

  Known via "eigrp 500", distance 90, metric 30720, type internal

  Redistributing via eigrp 500

  Last update from 192.168.24.4 on FastEthernet0/0, 00:01:03 ago

  Routing Descriptor Blocks:

  * 192.168.24.4, from 192.168.24.4, 00:01:03 ago, via FastEthernet0/0

      Route metric is 30720, traffic share count is 1

      Total delay is 200 microseconds, minimum bandwidth is 100000 Kbit

      Reliability 255/255, minimum MTU 1500 bytes

      Loading 1/255, Hops 1

If we look at the access list we can see that we're filtering out the route. 

Extended IP access list 100

    10 deny ip host 192.168.12.1 host 192.168.14.0 (1 match)

    20 permit ip any any (8 matches)

Reminder: The ACL says Filter all traffic coming from 192.168.12.1 for prefix 192.168.14.0 

Note: the limitation with doing this is , both the standard ACL and the Extended ACL can match on the route but not on the prefix length or subnet mask. 

The best implementation for filtering would be the Prefix-list because it is designed to match routing information. 

We can also use an "Offset-List" to increase the route value to larger that the the infinite value of 255 or another value so the route is not preferred. 

Examples:

R2(config-router)#offset-list 0 in  ?

  <0-2147483647>  Offset

Note: 2147483647 - this is the max value, a route with this value will never be installed in the routing table. 

Note: if we use offset list "0" - this means "all" networks. 

We can then say in our out an interface after the offset-list number or just apply globally to the process. 

Another Filter the ONLY EIGRP supports is filtering through a Route-map directly through a distribute list. 

We can control what prefix's are redistributed / exchanged between other protocols by using a route-map. EX: EIGRP to BGP, OSPF to EIGRP, etc. 

However with normal IGP implementations - there's no way to apply the route-map to a neighbor or to the process itself. Filtering with route-maps is normally reserved for BGP where you would apply it on a per neighbor basis, to control what prefix's we want to advertise or receive from the neighbors. Also to modify the attributes. 

With EIGRP we can use this for a metric based filter or a filter based on route tag information. 

Example: 

From the topology, I'm going to create a new loopback on R4 ( 10.4.4.4/24) and advertise it into eigrp. Then I'll assign a TAG value "5" to that route.  Then on R2 deny the route based on the TAG value on 5 

R4(config-if)#ip address 10.4.4.4 255.255.255.0

router eigrp 500

 redistribute connected route-map TAG

Note: redistributing the connected route will account for the Loopback. 

route-map TAG permit 10

 set metric 1 1 1 1 1 (random metric value)

 set tag 5  (tag the route with a value of 5) 

So now if i look at the routing table on any other router in my topology i should see the tag for the 10.4.4.4 route as "5".

R3#sh ip route 10.4.4.0

Routing entry for 10.4.4.0/24

  Known via "eigrp 500", distance 170, metric 2560002816

  Tag 5, type external       -- Shows as an external router with a tag of 5. 

  Redistributing via eigrp 500

  Last update from 192.168.34.4 on FastEthernet0/1, 00:06:54 ago

  Routing Descriptor Blocks:

  * 192.168.34.4, from 192.168.34.4, 00:06:54 ago, via FastEthernet0/1

      Route metric is 2560002816, traffic share count is 1

      Total delay is 110 microseconds, minimum bandwidth is 1 Kbit

      Reliability 1/255, minimum MTU 1 bytes

      Loading 1/255, Hops 1

      Route tag 5

Now lets filter the route with another route-map on the upstream router R2:

First we need to verify that the route show in the table as expected. 

R2#sh ip route 10.4.4.0

Routing entry for 10.4.4.0/24

  Known via "eigrp 500", distance 170, metric 2560002816

  Tag 5, type external

  Redistributing via eigrp 500

  Last update from 192.168.24.4 on FastEthernet0/0, 00:13:41 ago

  Routing Descriptor Blocks:

  * 192.168.24.4, from 192.168.24.4, 00:13:41 ago, via FastEthernet0/0

      Route metric is 2560002816, traffic share count is 1

      Total delay is 110 microseconds, minimum bandwidth is 1 Kbit

      Reliability 1/255, minimum MTU 1 bytes

      Loading 1/255, Hops 1

      Route tag 5

route-map TAG_FILTER deny 10

 match tag 5

route-map TAG_FILTER permit 1000

Now - here's where EIGRP differs from other IGP's. To aply this to R2, under the EIGRP process we need to apply the route map based on a distribute list. 

Example:

R2(config)#router eigrp 500

R2(config-router)#distribute-list route-map TAG_FILTER in fastEthernet 0/0

*Mar  1 01:53:10.155: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 500: Neighbor 192.168.24.4 (FastEthernet0/0) is resync: route configuration changed

Routing entry for 10.4.4.0/24

  Known via "eigrp 500", distance 170, metric 2560005376

  Tag 5, type external

  Redistributing via eigrp 500

  Last update from 192.168.12.1 on FastEthernet0/1, 00:05:57 ago

  Routing Descriptor Blocks:

  * 192.168.23.3, from 192.168.23.3, 00:05:57 ago, via FastEthernet1/0

      Route metric is 2560005376, traffic share count is 1

      Total delay is 210 microseconds, minimum bandwidth is 1 Kbit

      Reliability 1/255, minimum MTU 1 bytes

      Loading 1/255, Hops 2

      Route tag 5

    192.168.12.1, from 192.168.12.1, 00:05:57 ago, via FastEthernet0/1

      Route metric is 2560005376, traffic share count is 1

      Total delay is 210 microseconds, minimum bandwidth is 1 Kbit

      Reliability 1/255, minimum MTU 1 bytes

      Loading 1/255, Hops 2

      Route tag 5

R2#

We now see the routes are still learned but because we filtered it based on TAG value and called out the interface we're no longer see the route from the original source. 

EIGRP Default Routing

Lessons Learned:

EIGRP Default Routing

EIGRP supports default routing in two ways

Candidate default network

--IP default-network (network)

Native advertisement of a 0.0.0.0/0 prefix

Default-information command in EIGRP does not behave the same as other protocols

The default information command in EIGRP simply controls whether the route will accept a default route to whether it can continue to propagate a default route on….

Example:

Under the EIGRP process if you specify “no default-information”, it means the router will not accept an advertisement of a default route.

If we say “no default-information out”  it means that if the router learns a default route from someone else, you will not continue to propagate it on.

IP Default-Network

Originally came from IGRP

Candidate default network is backwards compatible with IGRP

-IGRP does not support the advertisement of 0.0.0.0/0

Default network must be…

-Dynamically learned through EIGRP -Not directly connected

-Classful Network

Limited application due to these restrictions.

Topology:

We can send a default route in via redistribution

EX: on the  BB1 router – let’s been RIP with it and the Edge rtr.

BB1 Router:

router rip

 version 2

 network 11.0.0.0

 network 20.0.0.0

 network 30.0.0.0

 network 192.168.1.0

 no auto-summary

EDGE RTR

router eigrp 500

 network 192.168.1.0

 network 192.168.2.0

 no auto-summary

!

router rip

 version 2

 network 192.168.1.0

 no auto-summary

!

Now on the edge router we would need to do mutual redistribution:

EDGE-RTR(config)#router rip

EDGE-RTR(config-router)#redistribute eigrp 1 metric 1

EDGE-RTR(config-router)#exit

EDGE-RTR(config)#router eigrp 500

EDGE-RTR(config-router)#redistribute rip

EDGE-RTR(config-router)#redistribute rip metric 1 1 1 1 1

Now if we sh ip route on the edge router we have the learned RIP routes.

EDGE-RTR#sh ip route rip

     20.0.0.0/24 is subnetted, 1 subnets

R       20.20.20.0 [120/1] via 192.168.1.10, 00:00:23, FastEthernet0/0

     11.0.0.0/24 is subnetted, 1 subnets

R       11.11.11.0 [120/1] via 192.168.1.10, 00:00:23, FastEthernet0/0

     30.0.0.0/24 is subnetted, 1 subnets

R       30.30.30.0 [120/1] via 192.168.1.10, 00:00:23, FastEthernet0/0

EDGE-RTR#

I can now Tag one of these route as the default route

 (config)#ip default-network 30.30.30.0

This will have the same effect as a default route to the done stream neighbors.

This is the same as advertising a Zero route in EIGRP

So in the BB1 router :

(config)#ip default-network 30.30.30.0

Gateway of last resort is 192.168.1.10 to network 0.0.0.0

     20.0.0.0/24 is subnetted, 1 subnets

R       20.20.20.0 [120/1] via 192.168.1.10, 00:00:21, FastEthernet0/0

     10.0.0.0/24 is subnetted, 2 subnets

D       10.2.1.0 [90/158720] via 192.168.2.3, 00:11:54, FastEthernet0/1

D       10.1.1.0 [90/158720] via 192.168.2.3, 00:11:54, FastEthernet0/1

     11.0.0.0/24 is subnetted, 1 subnets

R       11.11.11.0 [120/1] via 192.168.1.10, 00:00:21, FastEthernet0/0

C    192.168.1.0/24 is directly connected, FastEthernet0/0

C    192.168.2.0/24 is directly connected, FastEthernet0/1

D    192.168.3.0/24 [90/30720] via 192.168.2.3, 00:11:56, FastEthernet0/1

                    [90/30720] via 192.168.2.2, 00:11:56, FastEthernet0/1

     30.0.0.0/8 is variably subnetted, 2 subnets, 2 masks

R       30.30.30.0/24 [120/1] via 192.168.1.10, 00:00:23, FastEthernet0/0

S       30.0.0.0/8 [1/0] via 30.30.30.0

R*   0.0.0.0/0 [120/1] via 192.168.1.10, 00:00:14, FastEthernet0/0

EDGE-RTR#

This will propagate to all downstream routers, with each router setting its next Hop as the default until it reached the BB1 router.

==============================================

Native Default Advertisement

Native 0.0.0.0/0 network can be advertised via..

Static default route to an interface + network 0.0.0.0 under EIGRP process.

Redistribution from static or another protocol

Summarization

All routers are running EIGRP process 500

All interface are participating in EIGRP

BB1’s interfaces:

BB1#sh ip int brief

FastEthernet0/0            192.168.1.10   

Loopback1                  11.11.11.1     

Loopback2                  20.20.20.1     

Loopback3                  30.30.30.1     

Default route on BB2:

Gateway of last resort is not set

First:

On the EDGE Router let’s configure a static default route and point it to interface fa0/0 towards network 30.30.30.0

Then under the EIGRP process we just need configure need to say redistribute static

Result on BB2:

Gateway of last resort is 192.168.3.3 to network 0.0.0.0

D*EX 0.0.0.0/0 [170/33280] via 192.168.3.3, 00:00:05, FastEthernet0/0

BB2#

The only problem is now the route shows up as and External route.

OR

We can set the default route to a next hop value rather just an interface.

Remove the static: ip route 0.0.0.0 0.0.0.0 FastEthernet0/0 30.30.30.1

Replace with: ip route 0.0.0.0 0.0.0.0 FastEthernet0/0  - Just the interface.

Also remove the redistributed route under the process and then advertise the network 0.0.0.0 into EIGRP.

This should advertise a default network to all downstream routers out the FA0/0 interface of the Edge RTR1.

Ex:

router eigrp 500

  network 0.0.0.0

 no auto-summary

Now because we’re not redistributing the route still shows as the candidate default but it’s now an internal route.

Gateway of last resort is 192.168.3.3 to network 0.0.0.0

D*   0.0.0.0/0 [90/33280] via 192.168.3.3, 00:01:15, FastEthernet0/0

BB2#

The only time this will really matter is if you have multiple default routes. One that is an internal route and one that is an external route.  you would always prefer the internal route based on the AD.

EIGRP Stub Router Advertising:

Lessons Learned:

EIGRP Stub router advertisements

Reduces size of eigrp query domain

-Stub routers do not receive query messages

Process level (eigrp stub (arguments)

-arguments controls what router advertises

-defaults to connected routes and summary routes

------------------------------------------------------------------------------

Stub routes in the topology are normally routes that have only upstream reachability and do not have reachability to any other destinations. Basically the edge of the routing topology.

Normally the Stub routers only have reachability to their own local networks. In case there’s a failure in the topology, the query messages that are not bound to a summary will have to be flooded throughout the topology. So if the network has 1000 routers the query will need to be send to 1000 routers.

For Stub routers – they do not need to receive query message for routes that they cannot possibly reach through any other manner. If the upstream routers loses one of its routes it will send the query message out all hops. This is where the EIGRP stub router comes in.

The idea behind the eigrp Stub router advertisement is when we for adjacency with the remote peers we advertise ourselves as an EIGRP Stub router. This will prevent the upstream neighbors for sending us query messages for prefix’s that are coming from other portions of the topology.

So during the initial adjacency establishment the Stub router will advertise itself as a Stub.

Configuration:

Before we configure the Stub routers we need to run on some debugs for the before and after.

R1#debug eigrp packets query reply

This will show queries from upstream neighbor when a route goes away. The Stub router should never be receiving these anyway.

To correct this we need to configure the edge router as a stub:

EX:

R2(config-router)#eigrp stub

We can now verify from the upstream router’s perspective with the following command.

R1#sh ip eigrp neighbors detail

IP-EIGRP neighbors for process 500

H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq

                                            (sec)         (ms)       Cnt Num

1   192.168.12.2            Fa0/0             13 00:01:32   34   204  0  17

   Version 12.4/1.2, Retrans: 0, Retries: 0, Prefixes: 1

   Stub Peer Advertising ( CONNECTED SUMMARY ) Routes à it is advertising itself as a stub router and connected routes that it is locally generating

   Suppressing queries

This means the if there are other routed coming from downstream below the Stub router, they will not be able to be advertised upstream form the Stub.  

Typically there should not be any routers past the stub router.

You can tell the Stub router to leak prefixes

With the default options this is now possible – the arguments by default are connected and summary. Means we can advertise our local routes and a summary route.

If we do a SH IP ROUTE form the upstream neighbor, we will still see the routes that are forwarded from Stub. This just now means the Stub router can no longer be used for transit.

We could also create a static route on the stub router and then redistribute the static in Eigrp in the stub.

It should then show up as an EIGRP internal route upstream.