You might think that EIGRP being around for so long is not getting any attention from
Cisco, not true. EIGRP is still being developed and in later releases you can run what
is called named configuration. Doing this you can put all EIGRP config under one named
instance, even v6 which is different from the old syntax. If you are on Twitter you should
follow Donnie Savage @diivious. He works for Cisco and is usually present at Cisco Live
presenting on the development of EIGRP.
We start out with the following topology.
So we start out by defining our instance and calling it corp
R2#conf t Enter configuration commands, one per line. End with CNTL/Z. R2(config)#router eigrp corp
From there we have the following options:
R2(config-router)#? Router configuration commands: address-family Enter Address Family command mode default Set a command to its defaults exit Exit from routing protocol configuration mode no Negate a command or set its defaults service-family Enter Service Family command mode shutdown Shutdown this instance of EIGRP
From here we can shutdown the process or configure different address families.
We start by setting up IPv4 in the global table.
R2(config-router)#address-family ipv4 autonomous-system 12 R2(config-router-af)#? Address Family configuration commands: af-interface Enter Address Family interface configuration default Set a command to its defaults eigrp EIGRP Address Family specific commands exit-address-family Exit Address Family configuration mode help Description of the interactive help system maximum-prefix Maximum number of prefixes acceptable in aggregate metric Modify metrics and parameters for address advertisement neighbor Specify an IPv4 neighbor router network Enable routing on an IP network no Negate a command or set its defaults shutdown Shutdown address family timers Adjust peering based timers topology Topology configuration mode R2(config-router-af)#network 126.96.36.199 255.255.255.0
From here we define networks, setup static neighbors and configure EIGRP parameters.
We will use regular syntax on R2 for setting up EIGRP.
R2(config-if)#router eigrp 12 R2(config-router)#no auto R2(config-router)#net 188.8.131.52 0.0.0.255
The session comes up.
%DUAL-5-NBRCHANGE: EIGRP-IPv4 12: Neighbor 184.108.40.206 (FastEthernet1/0) is up: new adjacency
R2 is announcing it’s loopback. Lets see if we receive that.
R1#sh ip route eigrp | be Gateway Gateway of last resort is not set 220.127.116.11/32 is subnetted, 1 subnets D 18.104.22.168 [90/2662400] via 22.214.171.124, 00:00:23, FastEthernet1/0
What more can we configure under the address-family?
R1(config-router-af)#af-interface f1/0 R1(config-router-af-interface)#? Address Family Interfaces configuration commands: authentication authentication subcommands bandwidth-percent Set percentage of bandwidth percentage limit bfd Enable Bidirectional Forwarding Detection dampening-change Percent interface metric must change to cause update dampening-interval Time in seconds to check interface metrics default Set a command to its defaults exit-af-interface Exit from Address Family Interface configuration mode hello-interval Configures hello interval hold-time Configures hold time next-hop-self Configures EIGRP next-hop-self no Negate a command or set its defaults passive-interface Suppress address updates on an interface shutdown Disable Address-Family on interface split-horizon Perform split horizon summary-address Perform address summarization
We configure all EIGRP interface commands under the af-interface. We can setup
authentication of the peering.
R1(config-router-af)#af-interface f1/0 R1(config-router-af-interface)#authentication mode ? hmac-sha-256 HMAC-SHA-256 Authentication md5 Keyed message digest R1(config-router-af-interface)#authentication mode md5 R1(config-router-af-interface)#authentication key-chain EIGRP %DUAL-5-NBRCHANGE: EIGRP-IPv4 12: Neighbor 126.96.36.199 (FastEthernet1/0) is down: authentication mode changed %DUAL-5-NBRCHANGE: EIGRP-IPv4 12: Neighbor 188.8.131.52 (FastEthernet1/0) is up: new adjacency
What’s new here is that sha-256 is now also supported. From this af-interface mode
we can configure timers and BFD as well.
Now we will configure IPv4 in a VRF called 13.
R1(config)#vrf definition 13 R1(config-vrf)#rd 13:13 R1(config-vrf)#int f1/1 R1(config-if)#no sh R1(config-if)#vrf forwarding 13 R1(config-if)#ip add 184.108.40.206 255.255.255.0 R1(config-router)#address-family ipv4 vrf 13 autonomous-system 13 R1(config-router-af)#net 220.127.116.11 0.0.0.255 %DUAL-5-NBRCHANGE: EIGRP-IPv4 13: Neighbor 18.104.22.168 (FastEthernet1/1) is up: new adjacency
Do we receive any prefixes?
R1#sh ip route vrf 13 | be Gate Gateway of last resort is not set 22.214.171.124/32 is subnetted, 1 subnets D 126.96.36.199 [90/2662400] via 188.8.131.52, 00:00:31, FastEthernet1/1 184.108.40.206/8 is variably subnetted, 2 subnets, 2 masks C 220.127.116.11/24 is directly connected, FastEthernet1/1 L 18.104.22.168/32 is directly connected, FastEthernet1/1
Which we do. Nothing strange here, just a new syntax for defining VRFs compared
to the old ip vrf syntax.
Finally we will configure IPv6 peering as well. Because EIGRP sends packets from
link local address we don’t even need to configure a global IPv6 address.
R1(config-router)#int f2/0 R1(config-if)#ipv6 enable R1(config-if)#no sh R1(config-if)#router eigrp corp R1(config-router)#address-family ipv6 autonomous-system 14 R1(config-router-af)#af-interface default R1(config-router-af-interface)#no shut
Only difference here is that instead of defining network we use the interface command
instead to enable it on all active IPv6 interfaces.
R1#sh ipv6 route eigrp IPv6 Routing Table - default - 2 entries Codes: C - Connected, L - Local, S - Static, U - Per-user Static route B - BGP, R - RIP, H - NHRP, I1 - ISIS L1 I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary, D - EIGRP EX - EIGRP external, ND - ND Default, NDp - ND Prefix, DCE - Destination NDr - Redirect, O - OSPF Intra, OI - OSPF Inter, OE1 - OSPF ext 1 OE2 - OSPF ext 2, ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2, l - LISP D 2001::/64 [90/2662400] via FE80::C803:82FF:FE80:1C, FastEthernet2/0
And that’s about it. Named configuration is made to unify configuration under
one instance and remove the commands that we used to type under the interface
like authentication and such. It’s now all done under the address-family.
In future posts I will look at Multi Topology Routing (MTR).
This post is inspired by a discussion at Twitter with Ivan Pepelnjak and
Nicolas Michel. Nicolas asked what happens when there is the same route from two
different OSPF processes. Which one will be selected? Ivan explained how
to use the distance command. First before I show how it works and why we
need to get some few basic concepts explained.
LSDB – Link State Database – All OSPF LSAs populate the LSDB
RIB – Routing Information Base – The best routes from every protocol
compete to get installed to the RIB
FIB – Forwarding Information Base – Routes are copied from the RIB
and used for forwarding (CEF)
CEF – Cisco Express Forwarding – The algorithm that Cisco uses for
the forwarding (FIB)
If we have for example OSPF, this is how a route gets selected to the RIB(global).
The routers exchange LSAs with each other. Within an area every router has the same
view of the network. These LSAs populate the LSDB. If there are multiple paths to
a destination they will compete with each other unless they are of same type and equal
cost. Intra area is preferred first, then inter and finally external routes. There is no
way of modifying this behaviour. The best route then goes to the OSPF RIB, could be several
if they are equal. From there this route will compete with other routing protocols and the
AD will decide which one is installed. If the OSPF one is best then that one goes to the global
RIB. Then finally the RIB populates FIB with this information and forwarding can ensue.
This is a picture I made that describes the process.
We start out with a very basic topology looking like this.
R1 and R3 will announce the same network 22.214.171.124/32. R2 will use two different OSPF processes.
We start out with the basic configuration:
R1(config)#int f1/0 R1(config-if)#ip add 126.96.36.199 255.255.255.0 R1(config-if)#no sh R1(config-if)#ip ospf 1 area 0 R1(config-if)#int lo0 R1(config-if)#ip add 188.8.131.52 255.255.255.255 R1(config-if)#ip ospf 1 area 0
R2(config)#int f1/0 R2(config-if)#ip add 184.108.40.206 255.255.255.0 R2(config-if)#no sh R2(config-if)#ip ospf 1 area 0 R2(config-if)#int f1/1 R2(config-if)#ip add 220.127.116.11 255.255.255.0 R2(config-if)#no sh R2(config-if)#ip ospf 3 area 0 %OSPF-5-ADJCHG: Process 1, Nbr 18.104.22.168 on FastEthernet1/0 from LOADING to FULL, Loading Done
We see the session coming up immediately. Now lets bring up R3 as well.
R3(config)#int f1/0 R3(config-if)#ip add 22.214.171.124 255.255.255.0 R3(config-if)#no sh R3(config-if)#ip ospf 3 area 0 R3(config-if)#int lo0 R3(config-if)#ip add 126.96.36.199 255.255.255.255 R3(config-if)#ip ospf 3 area 0 %OSPF-5-ADJCHG: Process 3, Nbr 188.8.131.52 on FastEthernet1/0 from LOADING to FULL, Loading Done
Both OSPF peerings are up. Now lets follow the steps that was shown in
the picture above starting by looking at the database.
R2#sh ip ospf data router 184.108.40.206 OSPF Router with ID (220.127.116.11) (Process ID 3) OSPF Router with ID (18.104.22.168) (Process ID 1) Router Link States (Area 0) LS age: 184 Options: (No TOS-capability, DC) LS Type: Router Links Link State ID: 22.214.171.124 Advertising Router: 126.96.36.199 LS Seq Number: 80000003 Checksum: 0xF78 Length: 48 Number of Links: 2 Link connected to: a Stub Network (Link ID) Network/subnet number: 188.8.131.52 (Link Data) Network Mask: 255.255.255.255 Number of MTID metrics: 0 TOS 0 Metrics: 1 Link connected to: a Transit Network (Link ID) Designated Router address: 184.108.40.206 (Link Data) Router Interface address: 220.127.116.11 Number of MTID metrics: 0 TOS 0 Metrics: 1
We see that R1 is announcing 18.104.22.168/32 and we have a metric of 2 to it.
Do we see R3 announcing that as well?
R2#sh ip ospf data router 22.214.171.124 OSPF Router with ID (126.96.36.199) (Process ID 3) Router Link States (Area 0) LS age: 148 Options: (No TOS-capability, DC) LS Type: Router Links Link State ID: 188.8.131.52 Advertising Router: 184.108.40.206 LS Seq Number: 80000003 Checksum: 0x54A7 Length: 48 Number of Links: 2 Link connected to: a Stub Network (Link ID) Network/subnet number: 220.127.116.11 (Link Data) Network Mask: 255.255.255.255 Number of MTID metrics: 0 TOS 0 Metrics: 1 Link connected to: a Transit Network (Link ID) Designated Router address: 18.104.22.168 (Link Data) Router Interface address: 22.214.171.124 Number of MTID metrics: 0 TOS 0 Metrics: 1
Yes, it’s there. Now we take a look at the OSPF RIB. Which ones do we see there?
R2#sh ip ospf rib OSPF Router with ID (126.96.36.199) (Process ID 3) Base Topology (MTID 0) OSPF local RIB Codes: * - Best, > - Installed in global RIB * 188.8.131.52/32, Intra, cost 2, area 0 via 184.108.40.206, FastEthernet1/1 * 220.127.116.11/24, Intra, cost 1, area 0, Connected via 18.104.22.168, FastEthernet1/1 OSPF Router with ID (22.214.171.124) (Process ID 1) Base Topology (MTID 0) OSPF local RIB Codes: * - Best, > - Installed in global RIB *> 126.96.36.199/32, Intra, cost 2, area 0 via 188.8.131.52, FastEthernet1/0 * 184.108.40.206/24, Intra, cost 1, area 0, Connected via 220.127.116.11, FastEthernet1/0
The greater than sign indicates that the one from OSPF process 1 was selected.
Why? When running multiple OSPF processes the one that first installs to the
RIB will be selected to the global RIB. Now we confirm by looking in the
R2# show ip route ospf 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 18.104.22.168/32 is subnetted, 1 subnets O 22.214.171.124 [110/2] via 126.96.36.199, 00:06:35, FastEthernet1/0
Yes, that looks correct. Final step is to verify that FIB is also updated.
R2#sh ip cef 188.8.131.52/32 184.108.40.206/32 nexthop 220.127.116.11 FastEthernet1/0
So the one that first writes to the global RIB wins. Now lets bring down the
process that is currently winning.
R2(config)#int f1/0 R2(config-if)#sh R2(config-if)#
The OSPF RIB and global RIB should now be updated.
R2#show ip ospf rib OSPF Router with ID (18.104.22.168) (Process ID 3) Base Topology (MTID 0) OSPF local RIB Codes: * - Best, > - Installed in global RIB *> 22.214.171.124/32, Intra, cost 2, area 0 via 126.96.36.199, FastEthernet1/1 * 188.8.131.52/24, Intra, cost 1, area 0, Connected via 184.108.40.206, FastEthernet1/1 OSPF Router with ID (220.127.116.11) (Process ID 1) Base Topology (MTID 0) OSPF local RIB Codes: * - Best, > - Installed in global RIB
R2#show ip route ospf 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 18.104.22.168/32 is subnetted, 1 subnets O 22.214.171.124 [110/2] via 126.96.36.199, 00:00:42, FastEthernet1/1
Now if we bring back OSPF process 1, what will happen? Process 3 should still be
winning since it installed to global RIB first.
R2(config)#int f1/0 R2(config-if)#no sh
R2#sh ip ospf rib OSPF Router with ID (188.8.131.52) (Process ID 11) Base Topology (MTID 0) OSPF local RIB Codes: * - Best, > - Installed in global RIB OSPF Router with ID (184.108.40.206) (Process ID 3) Base Topology (MTID 0) OSPF local RIB Codes: * - Best, > - Installed in global RIB * 220.127.116.11/32, Intra, cost 2, area 0 via 18.104.22.168, FastEthernet1/1 * 22.214.171.124/24, Intra, cost 1, area 0, Connected via 126.96.36.199, FastEthernet1/1 OSPF Router with ID (188.8.131.52) (Process ID 1) Base Topology (MTID 0) OSPF local RIB Codes: * - Best, > - Installed in global RIB *> 184.108.40.206/32, Intra, cost 2, area 0 via 220.127.116.11, FastEthernet1/0 * 18.104.22.168/24, Intra, cost 1, area 0, Connected via 22.214.171.124, FastEthernet1/0
Now process 1 is winning, which is odd. Lets debug ip routing to see what is
really happening. We shutdown interface in process 1.
*Mar 14 23:26:36.555: RT: del 126.96.36.199 via 188.8.131.52, ospf metric [110/2] *Mar 14 23:26:36.559: RT: delete subnet route to 184.108.40.206/32 *Mar 14 23:26:36.579: RT: updating ospf 220.127.116.11/32 (0x0): via 18.104.22.168 Fa1/1 *Mar 14 23:26:36.583: RT: add 22.214.171.124/32 via 126.96.36.199, ospf metric [110/2]
Now we bring back process 1.
*Mar 14 23:29:04.163: RT: updating ospf 188.8.131.52/32 (0x0): via 184.108.40.206 Fa1/0 *Mar 14 23:29:04.171: RT: closer admin distance for 220.127.116.11, flushing 1 routes *Mar 14 23:29:04.175: RT: add 18.104.22.168/32 via 22.214.171.124, ospf metric [110/2]
We can see that IOS is claiming that distance is lower which it is clearly not.
What happens if we change process 1 to process 11 and we shutdown the interface
in process 3?
R2(config)#int f1/1 R2(config-if)#sh R2(config-if)#int f1/0 R2(config-if)#ip ospf 11 area 0
Now we look at the output from the debug.
*Mar 14 23:33:27.615: RT: updating ospf 126.96.36.199/32 (0x0): via 188.8.131.52 Fa1/0 *Mar 14 23:33:27.619: RT: add 184.108.40.206/32 via 220.127.116.11, ospf metric [110/2] *Mar 14 23:33:39.927: RT: updating connected 18.104.22.168/24 (0x0): via 0.0.0.0 Fa1/1 *Mar 14 23:33:39.931: RT: add 22.214.171.124/24 via 0.0.0.0, connected metric [0/0] *Mar 14 23:33:39.939: RT: interface FastEthernet1/1 added to routing table *Mar 14 23:33:39.947: RT: updating connected 126.96.36.199/32 (0x0): via 0.0.0.0 Fa1/1 *Mar 14 23:33:39.951: RT: network 188.8.131.52 is now variably masked *Mar 14 23:33:39.951: RT: add 184.108.40.206/32 via 0.0.0.0, connected metric [0/0] *Mar 14 23:33:55.447: RT: updating ospf 220.127.116.11/32 (0x0): via 18.104.22.168 Fa1/1 *Mar 14 23:33:55.455: RT: closer admin distance for 22.214.171.124, flushing 1 routes *Mar 14 23:33:55.455: RT: add 126.96.36.199/32 via 188.8.131.52, ospf metric [110/2]
We can see that first process 11 is the only option available so the 184.108.40.206/32
route is installed via f1/0. Then f1/1 comes back up and now 220.127.116.11/32 is reachable
via f1/1 and is chosen because of “closer admin distance” which is not true. This must
mean that the OSPF process number is the tie breaker.
We take a look at the OSPF RIB and global RIB to verify once more.
R2#sh ip ospf rib OSPF Router with ID (18.104.22.168) (Process ID 11) Base Topology (MTID 0) OSPF local RIB Codes: * - Best, > - Installed in global RIB * 22.214.171.124/32, Intra, cost 2, area 0 via 126.96.36.199, FastEthernet1/0 * 188.8.131.52/24, Intra, cost 1, area 0, Connected via 184.108.40.206, FastEthernet1/0 OSPF Router with ID (220.127.116.11) (Process ID 3) Base Topology (MTID 0) OSPF local RIB Codes: * - Best, > - Installed in global RIB *> 18.104.22.168/32, Intra, cost 2, area 0 via 22.214.171.124, FastEthernet1/1 * 126.96.36.199/24, Intra, cost 1, area 0, Connected via 188.8.131.52, FastEthernet1/1 OSPF Router with ID (184.108.40.206) (Process ID 1) Base Topology (MTID 0) OSPF local RIB Codes: * - Best, > - Installed in global RIB R2#sh ip route ospf 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 220.127.116.11/32 is subnetted, 1 subnets O 18.104.22.168 [110/2] via 22.214.171.124, 00:09:02, FastEthernet1/1
What if we change the AD of process 11?
R2(config)#router ospf 11 R2(config-router)#distance ospf intra-area 100
*Mar 14 23:43:31.315: RT: updating ospf 126.96.36.199/32 (0x0): via 188.8.131.52 Fa1/0 *Mar 14 23:43:31.319: RT: closer admin distance for 184.108.40.206, flushing 1 routes *Mar 14 23:43:31.323: RT: add 220.127.116.11/32 via 18.104.22.168, ospf metric [100/2]
That makes process 11 win again. So these tests seems to indicate that if everything
is the same then the tiebreaker is the lowest process number. For EIGRP it is the
lowest AS number so maybe Cisco chose to make it comparable.
Also take a look at what Ivan is saying at IOS hints
This post is about route redistribution and the different filtering techniques
we have available in our toolbelt. This post requires that you have a basic
understanding of route redistribution. For some good posts look at Petr
Lapukhovs posts at INE.
First lets define what is route redistribution? Generally we will use route
redistribution when multiple routing protocols are running in the network or
multiple instances of the same routing protocol is running. This can be due
to mergers, acquisitions or a fork lift upgrade. Maybe network is running
OSPF but is migrating to EIGRP or vice versa. We can also have redistribution
of connected and static routes.
What are some of the issues we can run into with route redistribution? We can
have routing loops in the network. These may not always be visible right away.
We can see them when doing a traceroute or when using debug ip routing.
We can also have issues with route feedback. Route feedback is when a redistributed
route gets redistributed back into the same protocol from which it originated. This
can lead to suboptimal routing or routing loops.
How do we define how “believable” a prefix is? First we must know that only the
same prefixes will be compared. 22.214.171.124/24 and 126.96.36.199/25 are not the same
prefixes. Longer match always wins! If we are comparing the two same prefixes
from different routing protocols then the AD will determine which one is the
best. Lower AD wins. If the AD for some reason is the same then the default AD
is the tie breaker.
Routes that are external should be less trusted than internal routes. EIGRP does
this by default by setting AD to 170 for external routes but 90 for internal. If
the other protocols did the same then we would not have issues with routing loops
at all. OSPF uses the same AD for internal and external prefixes (110) but we
can modify the AD for external routes if we want to. RIP does not have this
Routing loops generally occur when we have redistribution between a protocol with
higher AD to a protocol with lower AD. This means that RIP is most often involved
in loops since it has the highest AD and we can’t define an external AD.
Lets look at a topology where loops can occur. This image is hand drawn and something
I do when doing labs to try to spot potential issues. I use a different color for
different protocols and draw arrows where redistribution occurs.
We are doing mutual redistribution on R1 and R2. The issue here is that we will
have suboptimal routing. You can download topology and configs here.
Look at the show ip route and traceroute from R1 to R2′s loopback.
R1 is going the whole way round even though it has a direct route via RIP to
R2. This is of course due to RIP having a higher AD than OSPF. Lets look at
a few different ways of fixing this. If this was the CCIE lab you would do nothing
unless it was asked of you to provide optimal routing. We don’t have a loop so it’s
not really a big issue at the moment. The issue here is that OSPF is not setting
a higher AD on it’s external prefixes. So we will have to do this manually.
So we set the AD to something higher than RIP, 121 in this case. Now we take
the direct path. Remember that AD is a local setting so this would have to be done
on all routers choosing suboptimal path.
We could also lower the AD of RIP. Either we do it for all routes or for a selection
of routes. Here we will select the routes with an ACL. We can set the distance for
all route sources or for a specific one based on the IP. Here we only have one so
we don’t really care, we will match on 0.0.0.0 255.255.255.255.
So now the AD is 109 for the RIP route which beats OSPF of 110. This would of course
also be have to be done on all routers with suboptimal path.
This is another way of doing it. We are setting a distance of 255 for the RIP routes
when they are entering as OSPF routes. 255 is not a valid distance for installing to
RIB so RIP routes will be preferred.
We can also use a distribute-list to control what routes get installed via OSPF.
Since OSPF is a link state protocl the LSA will of course propagate to other
As you can see the route is still present in the OSPF database but it does not
get installed into the RIB.
There is also a more fancy way of using distribute-lists. We can tie them to
a routing-protocol and define what is allowed to go out from that protocol
into the routing protocol that we are currently configuring. We will configure
R2 so that RIP routes are not allowed to be redistributed into OSPF. This will
kill any redundancy in the network.
So we go to the config mode of the routing protocol we are redistributing into.
Then we define with the distribute-list what is allowed to go out from other
protocols into the one we are now configuring. This is an effective way of
filtering when we have a lot of redistribution going on. In a small scenario
like this it does not make much sense but it’s very handy in large scenarios.
There is still one tool left and that is the route-map. The route-map is the
most flexible and scalable solution of all. We can choose what prefixes get
redistributed with an access-list or prefix-list. Lets try that first.
Here we matched prefixes with a prefix-list. The prefix-list has a deny for the
loopback of R2 and permits anything else. The route-map only has a permit statement,
deny in prefix-list and permit in route-map means that the prefix does not match
and moves to the next statement which is an implicit deny. The permit matches the
permit of the route-map and allows anything else.
This is an example of route feedback.
R5 is the only redistribution point. The issue here is that the routes that R3
learns from R1 and R2 via RIP will arrive at R5. R5 then redistributes into
OSPF. R3 will receive these LSA’s and find that this path is better due to a
lower AD. R3 will then install this route. R3 stops announcing that route via
RIP. R5 looses its route via RIP and can’t redistribute it into OSPF, so it
stops announcing it via OSPF. R3 installs the RIP route again and the fun
has just begun. Debug ip routing will show this procedure repeat over and over.
For our final tool we need a more complicated scenario to make full use of it.
First lets take a look at the topology. Download configs and topology here.
We have mutual redistribution on R3 and R5. The issue here is that we are
redistributing into RIP with a seed metric of 1. R3 sees R1′s loopback via
RIP with a metric of 2. R3 redistributes this information into OSPF. R5 learns
this information via OSPF and then redistributes into RIP with a metric of 1.
R3 now has two possible paths to R1 loopback. One with a metric of 1 and one
with a metric of two. Of course the lower metric wins. This means that R5
points towards R3 via R4 and R3 points to R5. Ladies and gentlemen, we have
a routing loop. There is definately a risk of loops when doing mutual redistribution.
When I redistribute something into RIP I usually set a quite high seed metric like 7.
This lowers the risk of loops because the RIP metric internally should be lower unless
it’s a very large network.
The probably best way to filter redistribution is to use route tagging. We set
a tag in a route-map and then base our filters on this. Sometimes it can be difficult
knowing where a route originated and from which protocol it came. If we set good tags
we can see both just by looking at the tag. I usually set a tag like 390, that means
that router 3 originated the route and it came from EIGRP. A tag of 4120 would mean
that it was a RIP route from R4 to begin with. Now lets try this technique as well.
We will set a tag of 3120 on R3 and also deny routes with a tag of 5110 on R3. This
is used to prevent R3 from taking OSPF routes from R5 received over RIP and then
redistributing them back into OSPF.
This is what the filtering looks like on R5.
Here we deny routes with a tag of 3120 and set our own tag of 5110.
Note that there is a risk that the loop still remains. R3 is announcing
routes via RIP natively to R5. We have a chicken and egg problem here.
This is the scenario before tagging. R3 redistributes RIP into OSPF. R5 receives
the routes and install them via OSPF since AD is lower than RIP. R5 then redistributes
these back into RIP. R3 sees the lower metric via R5 and installs this route in the
RIB. We now have a loop.
We start implementing tagging. R3 tags RIP routes going into OSPF
and denies any prefixes that R5 has already redistributed from OSPF to RIP.
R5 denies routes from R3 with a tag of 3120 from going back into RIP and sets
its own tag of 5110. There is a risk that R5 sees the best path via RIP to R3
and then announces an OSPF route which R3 installs. We need to make sure that
R5 sees the best path via OSPF to have a stable network. This can be done by
clearing routing table and shutting down links. To make sure this does not
happen we should also tag RIP routes going into OSPF on R5.
So you see that redistribution can be very complicated and there are a lot of
tools available. Try to check what routes are native to which routing protocol
and make sure that these are preferred in that domain. You can use distance
or other tools to make sure this happens.
In the real lab there could be hidden bombs that you need to detect to have a stable
topology. Probably you won’t be that restricted what you could do but there could
be some restrictions. So it’s good to have as many tools as possible. If all else
fails, do what it takes to get connectivity. Use distribute-lists or whatever
to have a stable topology. Yes, you will loose points but you can definately
not finish the lab if you don’t have a stable topology.
I hope this post has been informative and if you want to give med feedback
post in the comments section.
Finished OSPF Vol1 tonight. I should know pretty much everything about OSPF by now. Here are some advice that I think is good when handling OSPF.
show ip ospf data self-originate – Will show what LSAs the local router is generating
show ip ospf data summary 188.8.131.52 adv-router 184.108.40.206 – Will show the Type3 inter-area summary as advertised by the router 220.127.116.11 (Router-ID)
show ip ospf border-routers – Shows the cost of reaching ABR and ASBR, a nice shortcut for finding the forward metric when you are looking at external routes. You can find this out yourself by checking costs of the links to reach the advertising router but this is a nice shortcut.
show ip ospf data | be Type-7 – Will start the OSPF database output for the NSSA external prefixes, change Type to whatever you want to look at.
These are some of my favourites, what commands do you use yourselves? Post in comments.
RIP timers are the most basic thing in the world right? Even the command to set them is named timers basic… However in some documentation it is not really clear what the difference is between the invalid and holddown timer. The default timers are 30 for updates, 180 for invalid, 180 for holddown and 240 for flush. I have heard and seen described in official documentation that when a route is in holddown it will not accept routes with a worse metric but routes with a better metric. This is however not true. First lets describe the different timers.
Updates – Updates are sent every 30 seconds by default to the address 18.104.22.168.
Invalid – If there has not been any updates for 180 seconds about the prefix it is consider invalid and the route will be poisoned (route advertised with a metric of 16).
Holddown – The timer for holddown will be activated when the route goes into an invalid state. This is set to 180 by default.
Flush – This timer is set to 240 seconds, when a routes is 240 seconds old it is flushed from the routing table.
So the holddown timer is used to stabilize the topology, even better routes will be suppressed which is not what some documentation says. Here is how I tested it.
I created a topology with 3 routers connecting to each other and both the routers announced 22.214.171.124/32 to the middle router. I created an ACL on the middle router to filter all traffic so that the best route will become invalid. On the third router I used an offset-list to make the route worse. After the route became invalid I stopped sending the route with a worse metric and sent it with a better metric. However the route is still not installed until the holddown timer has expired. If you manipulate the timers it is easier to see. I used 5 seconds for updates, 30 for invalid, 30 for holddown and flush of 240. You will see that it takes 60s before the route gets installed.
If you use the standard timers the holddown timer will not expire before the route is flushed since the 180 seconds start counting after 180s by default and then there is only 60s left until the route is flushed. Try this out for yourself and see if you get the same results as I.
Here is a good link describing the timers.
I did Vol1 RIP labs yesterday and I wanted to show you some cool stuff. How to do conditional default routing, this is lab stuff but some of it is definetely useful for real life deployments as well. I will be demonstrating RIP but the concepts are the same for other IGPs as well. I will show how to do it in two different ways. Lets start out with the topology.
This network has two exit paths to the Internet which is simulated by two routers with a loopback of 126.96.36.199. R2 has a static default route to ISP B which is the secondary exit. This route has an AD of 130 so it will only be used when the primary exit via RIP to ISP A is down. I have preconfigured the routers with addresses and the static route on R2 for ISP B. You can download the .net file and initial configs here.
Lets start by enabling RIP on R1 and R2. No routes will be learned since we only have a local link between them. We will now configure R1 to advertise a default route.
Let’s check R2 if we can see the route.
Yes it is there. This is not a very dynamic setup however. R1 will announce the route even if it looses the link to ISP A. Remember that RIP does not need to have a default route in its own RIB for it to announce it to neighbors. We will prove this by shutting down link to ISP A.
Interface has been shutdown. Is route still available at R2?
Yes it is. We now have a blackhole. Traffic will reach R1 and then it will be blackholed. Lets look at a way of solving this.
We can create a route-map and tie this to the advertisement of the default route. The route-map will wheck that the ISP A link (188.8.131.52/24) is in the routing table before advertising the default to R2. If the link to ISP A goes down the default should disappear, lets try this out.
We then shutdown the interface on R1.
We check R2, before and after shutdown of interface to ISP A.
If we debug RIP on R1 we can see that it poisions the route and sends it to R2 (hop count 16).
Now we have a way of doing a conditional default if the interface goes down. How can we solve a situation where we have issues but the interface stays up? Maybe we are connected via a fibre converter, not an optimal solution but sometimes we don’t get to decide.
Time to get funky, IP SLA is our friend. The basic idea is still the same. We will create a dummy route in R1 routing table. This dummy route will only be installed as long as R1 can ping ISP A IP address. If it can’t it will remove the dummy route and stop announcing the default route. We start by configuring R1.
We have a prefix-list that matches the dummy route. We use IP SLA to ping the other side, this is more reliable than relying on link down on the interface. Then we have the dummy route that is tied to track 1. Track 1 tracks the status of the SLA ping. We then have a route-map that looks for the dummy route prefix. If this prefix is missing we will stop announcing the default route. Lets look at R1 to see that the SLA is succeeding and that the dummy route is installed.
The reason we see some failures is because I had the interface shutdown when I brought the SLA probe online. Lets check that R2 still has a default route.
Indeed it does. Now lets see what happens when R1 can’t ping ISP A. I will temporary remove the IP on ISP A so that the interface still stays up but R1 won’t be able to ping any longer. We will run a debug of track to see what happens.
R1 can’t ping ISP A any longer so it stops announcing the deafult route as we can see on R2.
So now we have a more dynamic way of sending a conditional default. You can create even more exciting scenarios than this I am sure. If you want to lab it up just download the files from the beginning of this post.
Found out an interesting thing while doing a Vol3 lab. We all know that EIGRP will not form an adjacency over a non common subnet unless special circumstances. What about OSPF? I had a lab task where I need to form an adjacency over an ip unnumbered link. To my surprise this works just fine. If you debug you will get a message like this:
*Mar 1 00:15:14.155: OSPF: Rcv pkt from 184.108.40.206, FastEthernet0/0, area 0.0.0.0 : src not on the same network
However the database is correct and routes are installed. If you want to try this yourself use two routers with a serial link between them and then do ip unnumbered from an Ethernet interface and enable OSPF as usual. Watch what happens. Does anyone have a good description of this behavior? I tried looking in the RFC but all I could find is this:
“All routers connected to a common network must agree on certain
parameters (Network mask, HelloInterval and RouterDeadInterval).
These parameters are included in Hello packets, so that differences
can inhibit the forming of neighbor relationships.”
“An adjacency is bound to the network that the two routers have
in common. If two routers have multiple networks in common,
they may have multiple adjacencies between them.”
At first I had some trouble understanding route redistribution. I’ve tried getting better at it and now I have a solid understanding of it. Darren did some labs on his blog and I decided to give it a go as well. It is really good practice to create a lab of your own. Surprisingly it is more difficult than one would expect to create tricky scenarios, this is my go at it.
This is the topology.
The goal of the lab is to achieve full reachability and provide optimum routing. Since all links have the same bandwidth the fewer number of hops the better the route (try staying inside the routing domain if possible).
Follow these steps in order:
- Configure mutual redistribution between RIP and EIGRP on R5
- Configure mutual redistribution between OSPF and EIGRP on R3
- Configure mutual redistribution between OSPF and EIGRP on R2
- Configure mutual redistribution between RIP and OSPF on R7
- Configure mutual redistribution between RIP and OSPF on R8
All interfaces have been preconfigured with IP-adresses.
Download the topology and initial config here. Post your findings in the comments section.
Yesterday I did a vol3 lab and one of the tasks was to enable EIGRP on a couple
of the switches. I had enabled EIGRP, however I was not getting any routes
installed in the routing table. Look at the output below.
This should have rung an alarm bell right here. Default gateway is not set.
When not using ip routing on switches we use ip default-gateway to set a gateway
for management traffic etc. I thought there was an issue with EIGRP so I looked
in the topology table.
We have plenty of successors, so there are potential routes in EIGRP.
Remember that a successor in EIGRP is the best path to a prefix.
Now I started thinking about if there was a possibility that I had
these routes installed via another routing protocol but then I
finally realized that I had forgot to turn on ip routing.
The routes are now getting installed.
When configuring routing on switches remember that even though we
are allowed to configure the routing protocols, no routes will be
installed if we don’t have ip routing configured.
Sorry for the lack of updates lately but I spent the whole last week skiing and recharging my
batteries and now I’m back fully motivated to continue my path to the lab.
This time we will be talking about Integrated Routing and Bridging (IRB). Before studying for
the lab I had never used this feature. I’m not sure why we would use this feature in a
production network, maybe because we need to bridge two networks instead of routing
them due to some badly written application. If you have used it in real networks please post
in the comments. It is fair game for the lab so we need to know about it.
IRB is a feature used on routers that lets us bridge between a bridged domain and a
routed domain. Remember that in order for a VLAN to span a router the router must
be able to forward frames from one interface to another while maintaining the VLAN
header. If a network protocol is configured on a router interface (IP) it will terminate
the VLAN. This means that the VLAN header will not be maintained. When configuring
IRB we will be using a Bridged Virtual Interface (BVI), this can be compared to a SVI
on a switch. A BVI gives the bridged interfaces a connection to the routed world.
When IRB is configured and traffic comes in on a routed interface (IP address configured)
that is destined for a host in the bridge group the traffic will first be routed to the BVI.
The packet will then be forwarded to the bridging engine which forwards it through a
bridged interface, the forwarding is based on the destination MAC address. If a packet
comes in on a bridged interface destined for a host in a routed network the traffic will
first go to the BVI and then be sent to the routing engine before it sends it out the
routed interface. If bridging between two interfaces with no routed protocols the traffic
will not pass the BVI interface. Think of the bridge-group as an external switch and
the BVI lets us connect this external switch to the router.
The image below describes the scenario. R1 and R3 are in different VLANs but in
the same subnet, we need communication between the two routers. Between the
routers we have a couple of switches.
The configuration on R1 and R3 is straightforward. They have physical interfaces
with an IP address.
R1 is connected to SW1 and R3 to SW3. The switch configuration is just a basic access port.
Router R6 is connected to SW2 and it needs a trunk port.
Now we need to configure R6 to bridge between the two different VLANs. We start by activating IRB.
Then we need to tie the interfaces to the bridge-group.
Now we create a BVI interface in the subnet.
Lastly we need to activate spanning-tree and activate routing for the bridged interfaces.
So using IRB we can both bridge and route between interfaces on a
router, something that is not possible otherwise.
Finally, these are some useful commands to show what is going on when using IRB.