Cisconinja’s Blog

Archive for the ‘Static Routing’ Category

Some Strange Static Routing Issues

Posted by Andy on April 8, 2009

In this post we will look at two static routing issues that I have yet to find an explanation for.  R1 and R2 are connected by 3 serial interfaces, one using a subnet of a class A network, one a class B, and one a class C:

static-routing-topology2

R1:
interface Serial0/0
 ip address 10.0.12.1 255.255.255.252
interface Serial0/1
 ip address 172.16.12.1 255.255.255.252
interface Serial0/2
 ip address 192.168.12.1 255.255.255.252

R2:
interface Serial0/0
 ip address 10.0.12.2 255.255.255.252
interface Serial0/1
 ip address 172.16.12.2 255.255.255.252
interface Serial0/2
 ip address 192.168.12.2 255.255.255.252

The first issue occurs when all of the following are true:

 

  • The static route is configured with a next-hop address

 

  • At least 1 subnet of the major network specified by the next-hop address in the static route statement is present in the routing table, but no subnets that match the specific IP address

 

  • The best match for the IP address specified in the static route is the default route

 

  • The default route is configured with an exit interface

 

Static routes matching all of these conditions are not entered in the routing table even though there is a match for the next-hop address using the default route.  If no subnets of the major network exist in the routing table, or if the best match is anything but the default route and is configured with an exit interface, the static route will be installed.  Let’s look at a few examples.  First we will add the default route using an exit interface:

R1:
ip route 0.0.0.0 0.0.0.0 Serial0/0

1-show-ip-route

Next we will add a couple static routes with random next-hop addresses:

R1:
ip route 1.0.0.0 255.0.0.0 21.1.1.1
ip route 2.0.0.0 255.0.0.0 22.1.1.1

The next-hop for both routes resolves to the default route.  No subnets of 21.0.0.0/8 or 22.0.0.0/8 exist in the routing table.  Both routes are installed:

R1#debug ip routing
Mar 1 00:25:16.899: RT: SET_LAST_RDB for 1.0.0.0/8
NEW rdb: via 21.1.1.1
Mar 1 00:25:16.899: RT: add 1.0.0.0/8 via 21.1.1.1, static metric [1/0]
Mar 1 00:25:16.903: RT: NET-RED 1.0.0.0/8
Mar 1 00:25:19.275: RT: SET_LAST_RDB for 2.0.0.0/8
NEW rdb: via 22.1.1.1
Mar 1 00:25:19.275: RT: add 2.0.0.0/8 via 22.1.1.1, static metric [1/0]
Mar 1 00:25:19.275: RT: NET-RED 2.0.0.0/8

Next we will try to add static routes with next-hop addresses in the same major networks as the directly connected subnets used on the serial links:

R1:
ip route 3.0.0.0 255.0.0.0 10.255.255.50
ip route 4.0.0.0 255.0.0.0 172.16.255.50
ip route 5.0.0.0 255.0.0.0 192.168.12.50

One subnet of each classful network exists, but none of them match the next-hop address.  The best match on all 3 next-hop addresses should be the default route.  However, none of these 3 routes are installed in the routing table:

2-show-ip-route

If we add a static route to 21.21.21.0/24 with a next-hop of another random address, the route is added just like the first 2 routes because no subnets of the major network exist.  However, this also causes the 1.0.0.0 network to be removed after several seconds when the router realizes it now has a subnet of 21.0.0.0/8, but no specific subnet of the classful network to reach 21.1.1.1 – the next-hop for 1.0.0.0:

R1:
ip route 21.21.21.0 255.255.255.0 23.1.1.1

R1#debug ip routing
Mar 1 00:38:03.331: RT: SET_LAST_RDB for 21.21.21.0/24
NEW rdb: via 23.1.1.1
Mar 1 00:38:03.331: RT: add 21.21.21.0/24 via 23.1.1.1, static metric [1/0]
Mar 1 00:38:03.335: RT: NET-RED 21.21.21.0/24
Mar 1 00:38:55.619: RT: del 1.0.0.0 via 21.1.1.1, static metric [1/0]
Mar 1 00:38:55.619: RT: delete network route to 1.0.0.0
Mar 1 00:38:55.619: RT: NET-RED 1.0.0.0/8
Mar 1 00:38:55.623: RT: NET-RED 0.0.0.0/0

3-show-ip-route

This classful behavior only occurs when the best match is the default route.  If we add two /1 networks to cover the entire range covered by the default route and configure them with exit interfaces just like the default route, all of the static routes we configured match one of the two /1 static routes and are added to the routing table:

R1:
ip route 0.0.0.0 128.0.0.0 Serial0/0
ip route 128.0.0.0 128.0.0.0 Serial0/0

4-show-ip-route

 

 

 

 

The second issue occurs when all of the following things are true:

 

  • The static route is configured with a next-hop address

 

  • The best match for the IP address specified in the static route is another static route configured with a next-hop address or a route learned from a routing protocol

 

  • The best match route uses a less specific mask than the route being configured

 

  • The range of the best match route includes the range of the route being configured

 

Static routes meeting all of these conditions are not installed in the routing table, even though the next-hop address may resolve to a valid route.  Let’s look at a couple examples of this.  First we will remove all of the static route statements from the previous example:

R1:
no ip route 0.0.0.0 0.0.0.0 Serial0/0
no ip route 0.0.0.0 128.0.0.0 Serial0/0
no ip route 1.0.0.0 255.0.0.0 21.1.1.1
no ip route 2.0.0.0 255.0.0.0 22.1.1.1
no ip route 3.0.0.0 255.0.0.0 10.255.255.50
no ip route 4.0.0.0 255.0.0.0 172.16.255.50
no ip route 5.0.0.0 255.0.0.0 192.168.12.50
no ip route 21.21.21.0 255.255.255.0 23.1.1.1
no ip route 128.0.0.0 128.0.0.0 Serial0/0

We will enable RIP between R1 and R2 on S0/0 and create a loopback interface on R2 to be advertised with RIP. We will also create a static route with a next-hop of R2’s S0/0 interface IP address:

R1:
router rip
 network 10.0.0.0
!
ip route 4.0.0.0 255.0.0.0 10.0.12.2

R2:
interface Loopback0
 ip address 2.2.2.2 255.0.0.0
!
router rip
 network 2.0.0.0
 network 10.0.0.0

R1 adds both routes with a next-hop of 10.0.12.2:

5-show-ip-route

Next we will create some static routes with next-hop addresses that match these 2 routes:

R1:
ip route 2.0.0.0 254.0.0.0 2.255.255.1
ip route 2.0.0.0 255.128.0.0 2.255.255.1
ip route 4.0.0.0 254.0.0.0 4.255.255.1
ip route 4.0.0.0 255.128.0.0 4.255.255.1
ip route 4.0.0.0 255.128.0.0 4.1.1.1

Only the 1st and 3rd routes are installed in the routing table.  These two routes both use a less specific mask than the best match for their next-hop addresses:

6-show-ip-route

The three /9 routes, which use a more specific mask than the best match for their next-hop, are not installed.  There is the risk that a route could be self-recursive if, after being installed, the best route to it’s next hop is itself.  We can see that this is true for the 4.0.0.0/9 route with a next-hop of 4.1.1.1.  If installed, the best route to it’s next-hop address would be itself.  However the other two /9 routes do not have this problem since their next-hop addresses are both outside of their own range.  If installed, their next-hop would resolve to the two /8 routes, both of which are valid. 

This issue only occurs when the matching route uses a next-hop address.  If we change 4.0.0.0/8 to use an exit interface rather than a next-hop address, R1 installs the route to 4.0.0.0/9 via 4.255.255.1 several seconds later after it’s next scan of the routing table.  The other, self-recursive route to 4.0.0.0/9 via 4.1.1.1 remains uninstalled, as it should:

R1:
no ip route 4.0.0.0 255.0.0.0 10.0.12.2
ip route 4.0.0.0 255.0.0.0 Serial0/0

R1#debug ip routing
Mar 1 01:24:57.171: RT: SET_LAST_RDB for 4.0.0.0/8
NEW rdb: is directly connected
Mar 1 01:24:57.171: RT: add 4.0.0.0/8 via 0.0.0.0, static metric [1/0]
Mar 1 01:24:57.171: RT: NET-RED 4.0.0.0/8
Mar 1 01:25:34.571: RT: network 4.0.0.0 is now variably masked
Mar 1 01:25:34.571: RT: SET_LAST_RDB for 4.0.0.0/9
NEW rdb: via 4.255.255.1
Mar 1 01:25:34.575: RT: add 4.0.0.0/9 via 4.255.255.1, static metric [1/0]
Mar 1 01:25:34.575: RT: NET-RED 4.0.0.0/9

7-show-ip-route

Advertisements

Posted in Static Routing | Leave a Comment »

Static Routing – differences between specifying an exit interface, an IP address, and both

Posted by Andy on April 5, 2009

In this post we will look at some of the differences between configuring static routes with an exit interface, an IP address, and both an exit interface and an IP address.  The topology and initial configurations are shown below:

static-routing-topology

R1:
ipv6 unicast-routing
!
interface FastEthernet0/0
 mac-address 0000.0000.0001
 ip address 10.0.13.1 255.255.255.0
 ipv6 address 2001:DB8:0:13::1/64
 ipv6 address FE80::1 link-local
!
interface Serial0/0
 ip address 10.0.12.1 255.255.255.0
 ipv6 address 2001:DB8:0:12::1/64
 ipv6 address FE80::1 link-local

R2:
ipv6 unicast-routing
!
interface Serial0/0
 ip address 10.0.12.2 255.255.255.0
 ipv6 address 2001:DB8:0:12::2/64
 ipv6 address FE80::2 link-local
!
interface Serial0/1
 ip address 10.0.23.2 255.255.255.0
 ipv6 address 2001:DB8:0:23::2/64
 ipv6 address FE80::2 link-local

R3:
ipv6 unicast-routing
!
interface FastEthernet0/0
 mac-address 0000.0000.0003
 ip address 10.0.13.3 255.255.255.0
 ipv6 address 2001:DB8:0:13::3/64
 ipv6 address FE80::3 link-local
!
interface Serial0/0
 ip address 10.0.23.3 255.255.255.0
 ipv6 address 2001:DB8:0:23::3/64
 ipv6 address FE80::3 link-local
!
interface Loopback0
 ip address 3.3.3.3 255.255.255.0
 ipv6 address 2001:DB8:0:3::3/64
 ipv6 address FE80::3 link-local

First we will configure a static route to R3’s loopback on R1 by specifying an outgoing interface:

R1:
ip route 3.3.3.0 255.255.255.0 FastEthernet0/0
ipv6 route 2001:DB8:0:3::/64 FastEthernet0/0

R1#debug ip routing
R1#debug ipv6 routing

Mar 1 00:08:07.339: RT: SET_LAST_RDB for 3.3.3.0/24
NEW rdb: is directly connected

Mar 1 00:08:07.343: RT: add 3.3.3.0/24 via 0.0.0.0, static metric [1/0]
Mar 1 00:08:07.343: RT: NET-RED 3.3.3.0/24

Mar 1 00:08:55.963: IPv6RT0: static, Route add 2001:DB8:0:3::/64 [new]
Mar 1 00:08:55.963: IPv6RT0: static, Add 2001:DB8:0:3::/64 to table
Mar 1 00:08:55.967: IPv6RT0: static, Adding next-hop :: over FastEthernet0/0 for 2001:DB8:0:3::/64, [1/0]
Mar 1 00:08:55.967: IPv6RT0: Event: 2001:DB8:0:3::/64, Add, owner static, previous None

The IPv4 route shows up in the routing table as directly connected to F0/0:

1-r1-show-ip-route

Some sources say that the default AD for IPv4 static routes with only an exit interface specified is 0, but as shown below the AD is 1, so this may have been changed at some point in IOS:

1-r1-show-ip-route-3

The IPv6 route is listed in the routing table as pointing to an unspecified address with an exit interface of F0/0:

1-r1-show-ipv6-route

IPv4 static routes configured with only an exit interface on a broadcast network rely on proxy-ARP to determine the next hop.  If we attempt to send traffic to 5 different addresses on the 3.3.3.0/24 subnet, R1 sends an ARP for each of them and R3 replies using proxy-ARP:

R1#ping 3.3.3.1
R1#ping 3.3.3.2
R1#ping 3.3.3.3
R1#ping 3.3.3.4
R1#ping 3.3.3.5

1-r1-show-arp

This could result in a large amount of broadcast traffic and a large ARP cache on R1, especially if the static route was a default route used for internet traffic.

IPv6 uses NDP for address resolution, which does not have a similar function to proxy-ARP for answering requests on behalf of other nodes.  Therefore, R3 does not reply to neighbor solicitations sent by R1 for addresses on the 2001:db8:0:3::/64 subnet.  Even if the NS is for 2001:db8:0:3::3 (R3’s loopback address), R3 does not send an NA because NDP messages are link-local in scope and the NS arrives on the wrong interface:

R1#ping 2001:db8:0:3::3
. . . . .

If we add a static neighbor cache entry on R1 for the address, R1 does not need to send an NS to determine the layer-2 address and R3’s loopback is now reachable:

R1:
ipv6 neighbor 2001:DB8:0:3::3 FastEthernet0/0 0000.0000.0003

1-r1-show-neighbor

R1#ping 2001:db8:0:3::3
!!!!!

Obviously this is not scalable as it would require a static neighbor cache entry using R3’s layer-2 address for every IPv6 address that could potentially be reached by the static route on R1.

If F0/0 goes down on R1, both static routes are removed from the routing table:

R1:
interface FastEthernet0/0
 shutdown

Mar 1 00:25:01.907: IPv6RT0: connected, Delete 2001:DB8:0:13::1/128 from table
Mar 1 00:25:01.911: IPv6RT0: connected, Delete 2001:DB8:0:13::/64 from table
Mar 1 00:25:01.915: IPv6RT0: static, Delete 2001:DB8:0:3::/64 from table
Mar 1 00:25:01.919: RT: is_up: FastEthernet0/0 0 state: 6 sub state: 1 line: 1 has_route: True
Mar 1 00:25:01.923: RT: interface FastEthernet0/0 removed from routing table
Mar 1 00:25:01.923: RT: del 10.0.13.0/24 via 0.0.0.0, connected metric [0/0]
Mar 1 00:25:01.923: RT: delete subnet route to 10.0.13.0/24
Mar 1 00:25:01.927: RT: NET-RED 10.0.13.0/24
Mar 1 00:25:01.927: RT: Pruning routes for FastEthernet0/0 (1)
Mar 1 00:25:01.959: RT: delete route to 3.3.3.0 via 0.0.0.0, FastEthernet0/0
Mar 1 00:25:01.959: RT: no routes to 3.3.3.0, flushing
Mar 1 00:25:01.959: RT: NET-RED 3.3.3.0/24
Mar 1 00:25:01.963: RT: delete network route to 3.0.0.0
Mar 1 00:25:01.963: RT: NET-RED 3.0.0.0/8
Mar 1 00:25:01.967: IPv6RT0: Event: 2001:DB8:0:13::1/128, Del, owner connected, previous None
Mar 1 00:25:01.967: IPv6RT0: Event: 2001:DB8:0:13::/64, Del, owner connected, previous None
Mar 1 00:25:01.967: IPv6RT0: Event: 2001:DB8:0:3::/64, Del, owner static, previous None

2-r1-show-ip-route

2-r1-show-ipv6-route

 

Next we will change the static route statements to use a next-hop address instead of an exit interface:

R1:
interface FastEthernet0/0
 no shutdown
!
no ip route 3.3.3.0 255.255.255.0 FastEthernet0/0
no ipv6 route 2001:DB8:0:3::/64 FastEthernet0/0
ip route 3.3.3.0 255.255.255.0 10.0.13.3
ipv6 route 2001:DB8:0:3::/64 2001:DB8:0:13::3

The IPv4 and IPv6 routes are both listed in the routing table with a next-hop address only.  In order to find the outgoing interface, a recursive lookup is performed on the next-hop address:

3-r1-show-ip-route

3-r1-show-ipv6-route1

If we send traffic to 5 different addresses on the 3.3.3.0/24 subnet again, R3 only needs to send an ARP request for the first one to determine the layer-2 address for the specified next-hop, 10.0.13.3:

R1#ping 3.3.3.1
R1#ping 3.3.3.2
R1#ping 3.3.3.3
R1#ping 3.3.3.4
R1#ping 3.3.3.5

3-r1-show-arp

Likewise, if we send traffic to 5 different addresses on the 2001:db8:0:3::/64 subnet, R1 only needs to determine the L2 address for the specified next-hop, 2001:db8:0:3::3:

R1#ping 2001:db8:0:3::1
R1#ping 2001:db8:0:3::2
R1#ping 2001:db8:0:3::3
R1#ping 2001:db8:0:3::4
R1#ping 2001:db8:0:3::5

3-r1-show-neighbor

The static routes remain in the routing table as long as the next-hop can be resolved to a valid route in the routing table.  In this case, if F0/0 goes down on R1, the directly connected routes to 10.0.13.0/24 and 2001:db8:0:13::/64 are removed.  Since these are the only routes that can be used to resolve the next hop addresses, the static routes are also removed:

R1:
interface FastEthernet0/0
 shutdown

4-r1-show-ip-route2

4-r1-show-ipv6-route4

However, consider what would happen instead if RIP were being used on the 2 serial links and the fast ethernet link.  We will enable RIP and RIPng for each of these links on each router:

R1:
router rip
 network 10.0.0.0
!
ipv6 router rip test
!
interface FastEthernet0/0
 ipv6 rip test enable
!
interface Serial0/0
 ipv6 rip test enable

R2:
router rip
 network 10.0.0.0
!
ipv6 router rip test
!
interface Serial0/0
 ipv6 rip test enable
!
interface Serial0/1
 ipv6 rip test enable

R3:
router rip
 network 10.0.0.0
!
ipv6 router rip test
!
interface FastEthernet0/0
 ipv6 rip test enable
!
interface Serial0/0
 ipv6 rip test enable

Now we will shut down R1’s F0/0 again:

R1:
interface FastEthernet0/0
 shutdown

R1 deletes the routing table entries for 3.3.3.0/24 and 2001:db8:0:3::/64 like before:

R1#debug ip routing
R1#debug ipv6 routing

Mar 1 01:02:07.947: IPv6RT0: connected, Delete 2001:DB8:0:13::1/128 from table
Mar 1 01:02:07.951: IPv6RT0: static, Route add 2001:DB8:0:3::/64 [owner]
Mar 1 01:02:07.951: IPv6RT0: connected, Delete 2001:DB8:0:13::/64 from table
Mar 1 01:02:07.951: IPv6RT0: rip test, Backup call for 2001:DB8:0:13::/64
Mar 1 01:02:07.955: IPv6RT0: rip test, Route add 2001:DB8:0:13::/64 [new]
Mar 1 01:02:07.955: IPv6RT0: rip test, Add 2001:DB8:0:13::/64 to table
Mar 1 01:02:07.955: IPv6RT0: rip test, Adding next-hop FE80::3 over FastEthernet0/0 for 2001:DB8:0:13::/64, [120/2]
Mar 1 01:02:07.963: IPv6RT0: rip test, Delete 2001:DB8:0:13::/64 from table
Mar 1 01:02:07.963: IPv6RT0: Delete next-hop FE80::3/FastEthernet0/0 for 2001:DB8:0:23::/64
Mar 1 01:02:07.963: IPv6RT0: static, Delete 2001:DB8:0:3::/64 from table
Mar 1 01:02:07.971: RT: is_up: FastEthernet0/0 0 state: 6 sub state: 1 line: 1 has_route: True
Mar 1 01:02:07.971: RT: del 10.0.23.0/24 via 10.0.13.3, rip metric [120/1]
Mar 1 01:02:07.975: RT: NET-RED 10.0.23.0/24
Mar 1 01:02:07.975: RT: interface FastEthernet0/0 removed from routing table
Mar 1 01:02:07.975: RT: del 10.0.13.0/24 via 0.0.0.0, connected metric [0/0]
Mar 1 01:02:07.979: RT: delete subnet route to 10.0.13.0/24
Mar 1 01:02:07.979: RT: NET-RED 10.0.13.0/24
Mar 1 01:02:07.983: IPv6RT0: Event: 2001:DB8:0:13::1/128, Del, owner connected, previous None
Mar 1 01:02:07.983: IPv6RT0: Event: 2001:DB8:0:13::/64, Del, owner connected, previous None
Mar 1 01:02:07.983: IPv6RT0: Event: 2001:DB8:0:23::/64, Path, owner rip, previous None
Mar 1 01:02:07.987: IPv6RT0: Event: 2001:DB8:0:3::/64, Del, owner static, previous None
Mar 1 01:02:08.607: %SYS-5-CONFIG_I: Configured from console by console
Mar 1 01:02:08.979: RT: del 3.3.3.0/24 via 10.0.13.3, static metric [1/0]
Mar 1 01:02:08.979: RT: delete subnet route to 3.3.3.0/24
Mar 1 01:02:08.983: RT: NET-RED 3.3.3.0/24
Mar 1 01:02:08.983: RT: delete network route to 3.0.0.0
Mar 1 01:02:08.983: RT: NET-RED 3.0.0.0/8
Mar 1 01:02:09.943: %LINK-5-CHANGED: Interface FastEthernet0/0, changed state to administratively down
Mar 1 01:02:09.947: RT: is_up: FastEthernet0/0 0 state: 6 sub state: 1 line: 1 has_route: False
Mar 1 01:02:10.943: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/0, changed state to down
Mar 1 01:02:10.947: RT: is_up: FastEthernet0/0 0 state: 6 sub state: 1 line: 1 has_route: False

A few seconds later, R1 receives a RIPng update from R2 which includes a route to 2001:db8:0:13::/64 from R3. R1 also receives a RIP update from R2 which includes a route to 10.0.13.0/24 that was learned from R3. R1 adds these routes to it’s routing table:


Mar 1 01:02:19.919: IPv6RT0: rip test, Route add 2001:DB8:0:13::/64 [new]
Mar 1 01:02:19.919: IPv6RT0: rip test, Add 2001:DB8:0:13::/64 to table
Mar 1 01:02:19.919: IPv6RT0: rip test, Adding next-hop FE80::2 over Serial0/0 for 2001:DB8:0:13::/64, [120/3]
Mar 1 01:02:19.919: IPv6RT0: Event: 2001:DB8:0:13::/64, Add, owner rip, previous None

Mar 1 01:02:24.587: RT: SET_LAST_RDB for 10.0.13.0/24
NEW rdb: via 10.0.12.2

Mar 1 01:02:24.591: RT: add 10.0.13.0/24 via 10.0.12.2, rip metric [120/2]
Mar 1 01:02:24.591: RT: NET-RED 10.0.13.0/24

A few seconds later, R1 realizes that it now has a valid route to the next hop for each of it’s static routes and adds both routes to the routing table:

Mar 1 01:02:56.135: RT: SET_LAST_RDB for 3.3.3.0/24
NEW rdb: via 10.0.13.3

Mar 1 01:02:56.135: RT: add 3.3.3.0/24 via 10.0.13.3, static metric [1/0]
Mar 1 01:02:56.139: RT: NET-RED 3.3.3.0/24

Mar 1 01:03:00.223: IPv6RT0: static, Route add 2001:DB8:0:3::/64 [new]
Mar 1 01:03:00.223: IPv6RT0: static, Add 2001:DB8:0:3::/64 to table
Mar 1 01:03:00.223: IPv6RT0: static, Adding next-hop 2001:DB8:0:13::3 over Null for 2001:DB8:0:3::/64, [1/0]
Mar 1 01:03:00.227: IPv6RT0: Event: 2001:DB8:0:3::/64, Add, owner static, previous None

5-r1-show-ip-route

5-r1-show-ipv6-route1

R2 does not have a route to 3.3.3.0/24 or 2001:db8:0:3::/64 so traffic to these subnets from R1 will fail.  Even if R2 did have a route, it may be undesirable for these routes to be installed on R1 in the event that F0/0 on R1 goes down because traffic must traverse 2 slow serial links to reach it’s destination.  Another example of a situation that could occur is if R1 had a default route pointing out of a different interface to an ISP and F0/0 went down, the next-hop for the static route would resolve to the default route and R1 would keep the static routes in the routing table and send traffic destined for R3’s subnet out the interface connected to the ISP.

 

By specifying both an exit interface and a next-hop address, this behavior can be changed.  We will remove both static routes on R1 and add new static routes specifying both:

R1:
interface FastEthernet0/0
 no shutdown
!
no ip route 3.3.3.0 255.255.255.0 10.0.13.3
no ipv6 route 2001:DB8:0:3::/64 2001:DB8:0:13::3
ip route 3.3.3.0 255.255.255.0 FastEthernet0/0 10.0.13.3
ipv6 route 2001:DB8:0:3::/64 FastEthernet0/0 2001:DB8:0:13::3

The IPv4 and IPv6 static routes are listed in the routing table with both their outgoing interface and next-hop address:

6-r1-show-ip-route

6-r1-show-ipv6-route1

Using this method avoids the problems that we saw occur when specifying only the exit interface on a broadcast network.  It also will only keep the static routes in the routing table if the exit interface is up (which may or may not be desirable, depending on the situation).  If we shutdown F0/0 on R1 again, R1 learns the routes to 10.0.13.0/24 and 2001:db8:0:13::/64 again via RIP and RIPng.  However, R1 does not install the static routes even though their next-hop addresses resolve to known routes because F0/0 is down:

R1:
interface FastEthernet0/0
 shutdown

7-r1-show-ip-route

7-r1-show-ipv6-route

Having reachability to the next-hop address does not actually have anything to do with the static routes being installed or not when both an exit interface and an IP address are used.  We will bring F0/0 back up on R1 and then change the static routes to use a next-hop that is known out of a different interface:

R1:
interface FastEthernet0/0
 no shutdown
!
no ip route 3.3.3.0 255.255.255.0 FastEthernet0/0 10.0.13.3
no ipv6 route 2001:DB8:0:3::/64 FastEthernet0/0 2001:DB8:0:13::3
ip route 3.3.3.0 255.255.255.0 FastEthernet0/0 10.0.12.2
ipv6 route 2001:DB8:0:3::/64 FastEthernet0/0 2001:DB8:0:12::2

The IP address in the static route statements points to a directly connected network known out of S0/0.  Nevertheless, both routes are installed in the routing table and traffic matching the route will use F0/0:

8-r1-show-ip-route

8-r1-show-ipv6-route

Even if the next-hop is an address for which R1 has no matching route, the static route is still installed in the routing table:

R1:
no ip route 3.3.3.0 255.255.255.0 FastEthernet0/0 10.0.12.2
no ipv6 route 2001:DB8:0:3::/64 FastEthernet0/0 2001:DB8:0:12::2
ip route 3.3.3.0 255.255.255.0 FastEthernet0/0 5.5.5.5
ipv6 route 2001:DB8:0:3::/64 FastEthernet0/0 5555:5555:5555:5555::5

9-r1-show-ip-route

9-r1-show-ipv6-route

Traffic to these static routes will fail since R1 attempts to use ARP/NDP to perform address resolution on the invalid next-hop address out of the configured exit interface, but if the exit interface were instead a point-to-point interface, the configuration would work even though the next-hop address is incorrect.

Posted in IPv6, Static Routing | Leave a Comment »