Archive

Posts Tagged ‘routing’

IPv6 operation and best practices – documents to read

March 22, 2013 3 comments

Unfortunately I don’t get to do much v6 at my job yet but I still like to stay updated on
what is happening. Do you run any v6 in your network? If so, do you run it native or tunneled
or something like 6PE?

Here are some interesting sources for operation of v6.

draft-matthews-v6ops-design-guidelines-01

This document discusses if IPv4 and IPv6 traffic
should be mixed on the same interface or should different interfaces be used? Should
link local or global addressing be used for routing? Should v6 routes be transferred
over v4 in BGP sessions?

draft-ietf-v6ops-enterprise-incremental-ipv6-01

This document is for deploying v6 in an enterprise network. Things like security policy,
addressing plan and IPv6 myths are brought up.

draft-ietf-opsec-lla-only-01

This document is purely about the advantages and disadvantages of only running link local
addresses.

Also, don’t miss out on information that is freely available at Cisco Live. Here are
some interesting sessions on IPv6 from Melbourne.

BRKRST-2301 – Enterprise IPv6 Deployment (2013 Melbourne)
BRKRST-1069 – Understanding IPv6 (2013 Melbourne)
ITMGEN-1313 – Preparing for IPv6 in the Enterprise (2013 Melbourne)
BRKRST-2311 – IPv6 Planning, Deployment and Troubleshooting (2013 Melbourne)
BRKSEC-2003 – IPv6 Security Threats and Mitigations (2013 Melbourne)
COCRST-2464 – Inside Cisco IT: Making The Leap To IPv6 (2013 Melbourne)

As you can see. IPv6 is a pretty big deal these days at Cisco Live. Then you also have
books, configuration guides etc but this should give you a good start to see what challenges
and considerations you should have when deploying IPv6.

Categories: IPv6 Tags: , , ,

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: , , , ,

OSPF – Use of forwarding address

August 6, 2012 29 comments

In OSPF and other routing protocols we have something called forwarding address.
This can be used to route traffic in another direction than to the router that
originated the LSA. We start with the following topology.

It’s a basic OSPF setup where area 1 is a NSSA area. As you can see we have
two ABRs. Remember that in NSSA area, redistributed routes will be seen as N
internally but as E outside the area. To make this happen the ABR must translate
the type 7 LSA to type 5 LSA. If we have multiple ABRs, which one is responsible
for this task? The ABR with the highest RID will do the translation.

If we look at the LSA at R1, this is what it looks like.

R1#sh ip ospf data ex 10.10.4.0

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

                Type-5 AS External Link States

  Routing Bit Set on this LSA
  LS age: 1373
  Options: (No TOS-capability, DC)
  LS Type: AS External Link
  Link State ID: 10.10.4.0 (External Network Number )
  Advertising Router: 3.3.3.3
  LS Seq Number: 80000001
  Checksum: 0x7306
  Length: 36
  Network Mask: /24
        Metric Type: 2 (Larger than any link state path)
        TOS: 0
        Metric: 20
        Forward Address: 10.10.234.4
        External Route Tag: 0

So R3 is the ABR doing the translation but the forward address is set to
10.10.234.4 which is the address of R4. This means that traffic doesn’t need
to pass through R3 to reach the R4 network. The router will lookup the
10.10.234.0/24 prefix and use the routing information to reach the
10.10.4.0 network. This is proven by a traceroute.

R1#traceroute 10.10.4.4

Type escape sequence to abort.
Tracing the route to 10.10.4.4

  1 10.10.12.2 44 msec 44 msec 20 msec
  2 10.10.234.4 60 msec *  72 msec

What happens if the forwarding address network is not advertised? We will
do some filtering on R2.

R2(config-router)#area 1 range 10.10.234.0 255.255.255.0 not-advertise
R3(config-router)#area 1 range 10.10.234.0 255.255.255.0 not-advertise

R1#sh ip route 10.10.4.0
% Subnet not in table

There is no reachability for the network any longer? How can we resolve
this without removing the filtering?

We can tell R3 to suppress the FA in the LSA.

R3(config-router)#area 1 nssa translate type7 suppress-fa

The network is back and we have reachability but now traffic must pass
through R3 since the FA is not set.

R1#sh ip route 10.10.4.0
Routing entry for 10.10.4.0/24
  Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 2
  Last update from 10.10.12.2 on FastEthernet0/0, 00:00:07 ago
  Routing Descriptor Blocks:
  * 10.10.12.2, from 3.3.3.3, 00:00:07 ago, via FastEthernet0/0
      Route metric is 20, traffic share count is 1

R1#traceroute 10.10.4.4

Type escape sequence to abort.
Tracing the route to 10.10.4.4

  1 10.10.12.2 52 msec 76 msec 48 msec
  2 10.10.23.3 36 msec 48 msec 40 msec
  3 10.10.234.4 72 msec *  72 msec

So by setting the FA we achieve more effecient routing. The reason to have
a forwarding address is to reduce the number of LSAs needed. If all ABRs were
doing type 7 to type 5 translation then there would be more LSAs than what is
optimal.

Lets take a look at the LSA now. Note that the FA will be set to 0.0.0.0.

R1#sh ip ospf data ex 10.10.4.0

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

                Type-5 AS External Link States

  Routing Bit Set on this LSA
  LS age: 212
  Options: (No TOS-capability, DC)
  LS Type: AS External Link
  Link State ID: 10.10.4.0 (External Network Number )
  Advertising Router: 3.3.3.3
  LS Seq Number: 80000003
  Checksum: 0x6218
  Length: 36
  Network Mask: /24
        Metric Type: 2 (Larger than any link state path)
        TOS: 0
        Metric: 20
        Forward Address: 0.0.0.0
        External Route Tag: 0

By default the FA is always set when using NSSA areas. Now we take a look
at another use case where we have another routing protocol involved and
redistribution is done between the routing domains.

This is our example topology. Very similar to before. We just changed from
OSPF to RIP on the lefthand side.

R3 will be the router doing mutual redistribution between RIP and OSPF.
We will see that the FA will be set to 0.0.0.0. We check the route on R1.

R1#sh ip route 10.10.4.0
Routing entry for 10.10.4.0/24
  Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 2
  Last update from 10.10.12.2 on FastEthernet0/0, 00:01:07 ago
  Routing Descriptor Blocks:
  * 10.10.12.2, from 3.3.3.3, 00:01:07 ago, via FastEthernet0/0
      Route metric is 20, traffic share count is 1

R1#sh ip ospf data ex 10.10.4.0

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

                Type-5 AS External Link States

  Routing Bit Set on this LSA
  LS age: 79
  Options: (No TOS-capability, DC)
  LS Type: AS External Link
  Link State ID: 10.10.4.0 (External Network Number )
  Advertising Router: 3.3.3.3
  LS Seq Number: 80000001
  Checksum: 0x6616
  Length: 36
  Network Mask: /24
        Metric Type: 2 (Larger than any link state path)
        TOS: 0
        Metric: 20
        Forward Address: 0.0.0.0
        External Route Tag: 0

As expected the FA is set to 0.0.0.0. This means that traffic must traverse
R3. We confirm with a traceroute.

R1#traceroute 10.10.4.4

Type escape sequence to abort.
Tracing the route to 10.10.4.4

  1 10.10.12.2 64 msec 28 msec 24 msec
  2 10.10.23.3 68 msec 40 msec 40 msec
  3 10.10.234.4 96 msec *  76 msec

Now what happens if we enable OSPF on R3 interface towards R4?

R3(config-if)#ip ospf 1 area 0

R1#traceroute 10.10.4.4

Type escape sequence to abort.
Tracing the route to 10.10.4.4

  1 10.10.12.2 56 msec 32 msec 24 msec
  2 10.10.234.4 60 msec *  72 msec

Traceroute is now takinig the shorter path. How did this happen? Take a
look at the LSA on R1.

R1#sh ip ospf data ex 10.10.4.0

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

                Type-5 AS External Link States

  Routing Bit Set on this LSA
  LS age: 59
  Options: (No TOS-capability, DC)
  LS Type: AS External Link
  Link State ID: 10.10.4.0 (External Network Number )
  Advertising Router: 3.3.3.3
  LS Seq Number: 80000002
  Checksum: 0x7107
  Length: 36
  Network Mask: /24
        Metric Type: 2 (Larger than any link state path)
        TOS: 0
        Metric: 20
        Forward Address: 10.10.234.4
        External Route Tag: 0

The FA has now been set. How did this happen? The FA will be set for
external routes if we meet the following conditions.

  • OSPF is enabled on the ASBR’s next hop interface AND
  • ASBR’s next hop interface is non-passive under OSPF AND
  • ASBR’s next hop interface is not point-to-point AND
  • ASBR’s next hop interface is not point-to-multipoint AND
  • ASBR’s next hop interface address falls under the network range specified in the router ospf command.

 

So we have met all the conditions needed to set the FA. I hope that
you know have a better understanding of the forwarding address and
as usual always poste questions/feedback in the comments field.

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.