Archive

Archive for the ‘Routing’ Category

EIGRP named configuration

March 15, 2013 6 comments

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.

EIGRP_named_1

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 12.12.12.0 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 12.12.12.0 0.0.0.255

The session comes up.

%DUAL-5-NBRCHANGE: EIGRP-IPv4 12: Neighbor 12.12.12.2 (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

      2.0.0.0/32 is subnetted, 1 subnets
D        2.2.2.2 [90/2662400] via 12.12.12.2, 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 12.12.12.2 (FastEthernet1/0) is down: authentication mode changed
%DUAL-5-NBRCHANGE: EIGRP-IPv4 12: Neighbor 12.12.12.2 (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 13.13.13.1 255.255.255.0
R1(config-router)#address-family ipv4 vrf 13 autonomous-system 13
R1(config-router-af)#net 13.13.13.0 0.0.0.255
%DUAL-5-NBRCHANGE: EIGRP-IPv4 13: Neighbor 13.13.13.3 (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

      3.0.0.0/32 is subnetted, 1 subnets
D        3.3.3.3 [90/2662400] via 13.13.13.3, 00:00:31, FastEthernet1/1
      13.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C        13.13.13.0/24 is directly connected, FastEthernet1/1
L        13.13.13.1/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).

Tiebreakers with routes from different OSPF processes

March 15, 2013 17 comments

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.

Route_selection

We start out with a very basic topology looking like this.

Multiple_OSPF_1

R1 and R3 will announce the same network 1.1.1.1/32. R2 will use two different OSPF processes.
We start out with the basic configuration:

R1

R1(config)#int f1/0
R1(config-if)#ip add 12.12.12.1 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 1.1.1.1 255.255.255.255
R1(config-if)#ip ospf 1 area 0

R2

R2(config)#int f1/0
R2(config-if)#ip add 12.12.12.2 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 23.23.23.2 255.255.255.0
R2(config-if)#no sh
R2(config-if)#ip ospf 3 area 0
%OSPF-5-ADJCHG: Process 1, Nbr 12.12.12.1 on FastEthernet1/0 from LOADING to FULL, Loading Done

We see the session coming up immediately. Now lets bring up R3 as well.

R3

R3(config)#int f1/0
R3(config-if)#ip add 23.23.23.3 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 1.1.1.1 255.255.255.255
R3(config-if)#ip ospf 3 area 0
%OSPF-5-ADJCHG: Process 3, Nbr 23.23.23.2 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 12.12.12.1

            OSPF Router with ID (23.23.23.2) (Process ID 3)

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

                Router Link States (Area 0)

  LS age: 184
  Options: (No TOS-capability, DC)
  LS Type: Router Links
  Link State ID: 12.12.12.1
  Advertising Router: 12.12.12.1
  LS Seq Number: 80000003
  Checksum: 0xF78
  Length: 48
  Number of Links: 2

    Link connected to: a Stub Network
     (Link ID) Network/subnet number: 1.1.1.1
     (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: 12.12.12.1
     (Link Data) Router Interface address: 12.12.12.1
      Number of MTID metrics: 0
       TOS 0 Metrics: 1

We see that R1 is announcing 1.1.1.1/32 and we have a metric of 2 to it.
Do we see R3 announcing that as well?

R2#sh ip ospf data router 23.23.23.3

            OSPF Router with ID (23.23.23.2) (Process ID 3)

                Router Link States (Area 0)

  LS age: 148
  Options: (No TOS-capability, DC)
  LS Type: Router Links
  Link State ID: 23.23.23.3
  Advertising Router: 23.23.23.3
  LS Seq Number: 80000003
  Checksum: 0x54A7
  Length: 48
  Number of Links: 2

    Link connected to: a Stub Network
     (Link ID) Network/subnet number: 1.1.1.1
     (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: 23.23.23.2
     (Link Data) Router Interface address: 23.23.23.3
      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 (23.23.23.2) (Process ID 3)


                Base Topology (MTID 0)

OSPF local RIB
Codes: * - Best, > - Installed in global RIB

*   1.1.1.1/32, Intra, cost 2, area 0
      via 23.23.23.3, FastEthernet1/1
*   23.23.23.0/24, Intra, cost 1, area 0, Connected
      via 23.23.23.2, FastEthernet1/1

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


                Base Topology (MTID 0)

OSPF local RIB
Codes: * - Best, > - Installed in global RIB

*>  1.1.1.1/32, Intra, cost 2, area 0
      via 12.12.12.1, FastEthernet1/0
*   12.12.12.0/24, Intra, cost 1, area 0, Connected
      via 12.12.12.2, 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
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

      1.0.0.0/32 is subnetted, 1 subnets
O        1.1.1.1 [110/2] via 12.12.12.1, 00:06:35, FastEthernet1/0

Yes, that looks correct. Final step is to verify that FIB is also updated.

R2#sh ip cef 1.1.1.1/32
1.1.1.1/32
  nexthop 12.12.12.1 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 (23.23.23.2) (Process ID 3)


                Base Topology (MTID 0)

OSPF local RIB
Codes: * - Best, > - Installed in global RIB

*>  1.1.1.1/32, Intra, cost 2, area 0
      via 23.23.23.3, FastEthernet1/1
*   23.23.23.0/24, Intra, cost 1, area 0, Connected
      via 23.23.23.2, FastEthernet1/1

            OSPF Router with ID (12.12.12.2) (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

      1.0.0.0/32 is subnetted, 1 subnets
O        1.1.1.1 [110/2] via 23.23.23.3, 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 (2.2.2.2) (Process ID 11)


                Base Topology (MTID 0)

OSPF local RIB
Codes: * - Best, > - Installed in global RIB


            OSPF Router with ID (23.23.23.2) (Process ID 3)


                Base Topology (MTID 0)

OSPF local RIB
Codes: * - Best, > - Installed in global RIB

*   1.1.1.1/32, Intra, cost 2, area 0
      via 23.23.23.3, FastEthernet1/1
*   23.23.23.0/24, Intra, cost 1, area 0, Connected
      via 23.23.23.2, FastEthernet1/1

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


                Base Topology (MTID 0)

OSPF local RIB
Codes: * - Best, > - Installed in global RIB

*>  1.1.1.1/32, Intra, cost 2, area 0
      via 12.12.12.1, FastEthernet1/0
*   12.12.12.0/24, Intra, cost 1, area 0, Connected
      via 12.12.12.2, 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 1.1.1.1 via 12.12.12.1, ospf metric [110/2]
*Mar 14 23:26:36.559: RT: delete subnet route to 1.1.1.1/32
*Mar 14 23:26:36.579: RT: updating ospf 1.1.1.1/32 (0x0):
    via 23.23.23.3 Fa1/1
*Mar 14 23:26:36.583: RT: add 1.1.1.1/32 via 23.23.23.3, ospf metric [110/2]

Now we bring back process 1.

*Mar 14 23:29:04.163: RT: updating ospf 1.1.1.1/32 (0x0):
    via 12.12.12.1 Fa1/0
*Mar 14 23:29:04.171: RT: closer admin distance for 1.1.1.1, flushing 1 routes
*Mar 14 23:29:04.175: RT: add 1.1.1.1/32 via 12.12.12.1, 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 1.1.1.1/32 (0x0):
    via 12.12.12.1 Fa1/0

*Mar 14 23:33:27.619: RT: add 1.1.1.1/32 via 12.12.12.1, ospf metric [110/2]
*Mar 14 23:33:39.927: RT: updating connected 23.23.23.0/24 (0x0):
    via 0.0.0.0 Fa1/1
*Mar 14 23:33:39.931: RT: add 23.23.23.0/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 23.23.23.2/32 (0x0):
    via 0.0.0.0 Fa1/1
*Mar 14 23:33:39.951: RT: network 23.0.0.0 is now variably masked
*Mar 14 23:33:39.951: RT: add 23.23.23.2/32 via 0.0.0.0, connected metric [0/0]
*Mar 14 23:33:55.447: RT: updating ospf 1.1.1.1/32 (0x0):
    via 23.23.23.3 Fa1/1
*Mar 14 23:33:55.455: RT: closer admin distance for 1.1.1.1, flushing 1 routes
*Mar 14 23:33:55.455: RT: add 1.1.1.1/32 via 23.23.23.3, ospf metric [110/2]

We can see that first process 11 is the only option available so the 1.1.1.1/32
route is installed via f1/0. Then f1/1 comes back up and now 1.1.1.1/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 (22.22.22.22) (Process ID 11)


                Base Topology (MTID 0)

OSPF local RIB
Codes: * - Best, > - Installed in global RIB

*   1.1.1.1/32, Intra, cost 2, area 0
      via 12.12.12.1, FastEthernet1/0
*   12.12.12.0/24, Intra, cost 1, area 0, Connected
      via 12.12.12.2, FastEthernet1/0

            OSPF Router with ID (23.23.23.2) (Process ID 3)


                Base Topology (MTID 0)

OSPF local RIB
Codes: * - Best, > - Installed in global RIB

*>  1.1.1.1/32, Intra, cost 2, area 0
      via 23.23.23.3, FastEthernet1/1
*   23.23.23.0/24, Intra, cost 1, area 0, Connected
      via 23.23.23.2, FastEthernet1/1

            OSPF Router with ID (12.12.12.2) (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

      1.0.0.0/32 is subnetted, 1 subnets
O        1.1.1.1 [110/2] via 23.23.23.3, 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 1.1.1.1/32 (0x0):
    via 12.12.12.1 Fa1/0

*Mar 14 23:43:31.319: RT: closer admin distance for 1.1.1.1, flushing 1 routes
*Mar 14 23:43:31.323: RT: add 1.1.1.1/32 via 12.12.12.1, 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

Categories: OSPF, Routing Tags: , , , ,

Route redistribution – filtering and mitigating loops

January 30, 2012 6 comments

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. 162.14.1.0/24 and 162.14.1.0/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
possibility.

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
routers.

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.

OSPF Vol1 finished

November 7, 2011 4 comments

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 150.3.0.0 adv-router 150.8.4.4 – Will show the Type3 inter-area summary as advertised by the router 150.8.4.4 (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.

Categories: CCIE, OSPF, Routing Tags: , , ,

RIP timers

October 15, 2011 4 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 224.0.0.9.

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 1.1.1.1/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.

Categories: CCIE, RIP, Routing Tags: , , , ,

Conditional default route – RIP

October 13, 2011 2 comments

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 1.1.1.1. 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 (150.1.11.0/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.

OSPF adjacency over non common subnet

August 2, 2011 7 comments

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 155.1.15.2, 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.”