Thursday, March 16, 2006
Mutual default routes. (Question #42)
Consider two routers connected back-to-back with each other with the following configuration
Router 1
Router 2
There are no other routers in the network. If the following command
were to be issued on Router1, how may times would the ICMP echo request packet bounce between the pair of routers before being dropped?
Router 1
interface Loopback1
ip address 11.11.11.11 255.255.255.255
!
interface Ethernet0
ip address 10.10.10.1 255.255.255.0
no keepalive
!
ip route 0.0.0.0 0.0.0.0 10.10.10.2
Router 2
interface Ethernet0
ip address 10.10.10.2 255.255.255.0
no keepalive
!
ip route 0.0.0.0 0.0.0.0 10.10.10.1
There are no other routers in the network. If the following command
Router1#ping 33.33.33.33 source 11.11.11.11 repeat 1
were to be issued on Router1, how may times would the ICMP echo request packet bounce between the pair of routers before being dropped?
Gateway of Last Resort With EIGRP. (Question #41)
Consider the following two outputs from show ip route on a router that is learning about gateway of last resort information from a neighboring EIGRP router. In both cases the gateway of last resort is 30.30.30.2 but the details are different.
Can you deduce what had to be configured on the neighboring router to get the show ip route output in case#1 and how it was different from what needed to be configured on the neighboring router to get the show ip route output shown in case#2?
Case 1
Case 2
Can you deduce what had to be configured on the neighboring router to get the show ip route output in case#1 and how it was different from what needed to be configured on the neighboring router to get the show ip route output shown in case#2?
Case 1
Gateway of last resort is 30.30.30.2 to network 1.0.0.0
1.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
D 1.1.1.1/32 [90/435200] via 30.30.30.2, 03:37:24, Ethernet0
D*EX 1.0.0.0/8 [170/307200] via 30.30.30.2, 00:00:16, Ethernet0
2.0.0.0/32 is subnetted, 1 subnets
D 2.2.2.2 [90/409600] via 30.30.30.2, 03:37:24, Ethernet0
33.0.0.0/32 is subnetted, 1 subnets
C 33.33.33.33 is directly connected, Loopback1
3.0.0.0/32 is subnetted, 1 subnets
C 3.3.3.3 is directly connected, Loopback0
10.0.0.0/24 is subnetted, 1 subnets
D 10.10.10.0 [90/307200] via 30.30.30.2, 03:37:24, Ethernet0
30.0.0.0/24 is subnetted, 1 subnets
C 30.30.30.0 is directly connected, Ethernet0
Case 2
Gateway of last resort is 30.30.30.2 to network 0.0.0.0
1.0.0.0/32 is subnetted, 1 subnets
D 1.1.1.1 [90/435200] via 30.30.30.2, 03:40:15, Ethernet0
2.0.0.0/32 is subnetted, 1 subnets
D 2.2.2.2 [90/409600] via 30.30.30.2, 03:40:15, Ethernet0
33.0.0.0/32 is subnetted, 1 subnets
C 33.33.33.33 is directly connected, Loopback1
3.0.0.0/32 is subnetted, 1 subnets
C 3.3.3.3 is directly connected, Loopback0
10.0.0.0/24 is subnetted, 1 subnets
D 10.10.10.0 [90/307200] via 30.30.30.2, 03:40:15, Ethernet0
30.0.0.0/24 is subnetted, 1 subnets
C 30.30.30.0 is directly connected, Ethernet0
D*EX 0.0.0.0/0 [170/307200] via 30.30.30.2, 00:00:07, Ethernet0
Bandwidth percent command for EIGRP. (Question #40)
Consider the following output when the help string for the EIGRP bandwidth-percent command is prompted with "?"
R1(config-if)#ip bandwidth-percent eigrp 22 ?
<1-999999> Maximum bandwidth percentage that EIGRP may use
It looks like one can configure percent values greater than 100. Is this a bug? Why would configuring bandwidth percent greater than 100 ever make sense?
R1(config-if)#ip bandwidth-percent eigrp 22 ?
<1-999999> Maximum bandwidth percentage that EIGRP may use
It looks like one can configure percent values greater than 100. Is this a bug? Why would configuring bandwidth percent greater than 100 ever make sense?
The Many Wonders of the Static Route to Null0.
When I first saw a static route to the Null0 interface in some IOS configuration, I most certainly did not appreciate the fact that I was looking at a veritable swiss army knife in the world of networking. My first impression was that this seemed silly at best and possibly wrong. After all, why would pointing packets at a software interface that would simply discard all packets aimed at it be a good idea?
Then over a period of time as I understood the various uses that a static route to Null0 was put to, I learned to look at it with respect. In this post I will try and list some of the scenarios where I have seen a static route to Null0 being gainfully employed.
One common use of this technique is for loop prevention. Assume you have a router performing NAT translating inside local addresses to the address range 192.168.65.193 - 192.168.65.198. Assume further that this router has a default route pointing to the outside as would be common for a router performing NAT at the edge of the network. If an outside device were to try to ping an address (192.168.65.194, say) from the NAT address pool when that address has not yet been assigned to a translation, the packet would end up looping until its TTL gets decremented to zero because of the default route on the NAT router. The way to avoid this would be to code in a static route for the address pool to Null0 as follows
With this static route, any addresses from the NAT pool not assigned to the translation would end up hitting this static route and would be dropped thus avoiding the problem with looping packets.
Another trick very similar to the last one is used in dial-up networks. Assume an access server is assigning an address from an address pool to dial-up clients. If the access server has a default route, packets addressed to any IP addresses in the dial-up address pool not currently assigned would result in packets looping. A static route for addresses in that pool to Null0 will prevent that problem. Note that if a packet comes in destined to an address that is indeed assigned to a dialed in client, it will get routed correctly because the access server will have a host route (/32) to that address and the semantics of the longest match with IP route lookup will ensure that the host route matches rather than the less specific static route to Null0 for that case. It is only packets in the address pool that are not assigned yet that will match the static route to Null0 and get dropped.
Let's take another scenario where the static route to Null0 comes in handy. Assume that you are summarizing prefix advertisements on a router but all subnets included in the summary may not be existing yet. In that case, packets addressed to non-existent subnets of the summary can end up looping if there is a default route on the router. This is avoided by adding a static route to Null0 for the summary address. Again, for subnets that do exist, the more specific route to the subnet will be matched because of the longest-match semantics but for non-existent subnets, the static route to Null0 will be matched and the packets dropped. Protocols like EIGRP will automatically add a static route to Null0 for the summarized prefix when auto summarization is in effect for exactly this loop prevention reason.
Now for a very different application of the static route to Null0. Recall how BGP will not advertise a prefix indicated in the network statement unless there is an exact route to the prefix. However, your router may only have routes to subnets of that prefix. To get BGP to advertise that route all you need to do is to add a static route to Null0 for that exact prefix you wish to advertise. The static route gets added to the routing table and that causes BGP to now advertise that prefix. Again, because of the longest prefix match semantics packets for valid subnets in that prefix will have a more specific entry in the routing table and so will be correctly routed. Packets for subnets of that prefix that do not exist will indeed match the static route to Null0 and get dropped but then that will be the correct behavior.
One very nice application of the static route to Null0 is when one needs to redistribute between RIP and and a classless routing protocol like OSPF where the RIP and OSPF domains share addressing in the same major network but if the masks are different. In such a scenario, if you try to redistribute the OSPF routes into RIP, it will not work. For instance, if the RIP and OSPF domains have addresses in the 172.169.0.0 major network but let's say RIP is using 172.169.5.0/24 addressing while the OSPF domain is using addresses from 172.169.10.128/25. If you simply try to redistribute the OSPF routes into RIP, you will see that RIP will not advertise the routes learned from OSPF. To get this to work, one option might be to change the mask for the OSPF domain to be /24 also but for obvious reasons that is not an easy thing to do. Instead, you could simply configure a static route to Null0 for the 172.169.10.0/24 prefix and redistribute the static route into RIP. As usual, because there will be more specific routes for the valid subnets of 172.169.10/24, packets will be routed properly and routers from the RIP domain will be able to reach routers in the OSPF domain.
I am sure I am only scratching the surface here with the use of the static route to Null0. If you are aware of other nifty uses of this tool, please leave a comment describing the scenario.
Then over a period of time as I understood the various uses that a static route to Null0 was put to, I learned to look at it with respect. In this post I will try and list some of the scenarios where I have seen a static route to Null0 being gainfully employed.
One common use of this technique is for loop prevention. Assume you have a router performing NAT translating inside local addresses to the address range 192.168.65.193 - 192.168.65.198. Assume further that this router has a default route pointing to the outside as would be common for a router performing NAT at the edge of the network. If an outside device were to try to ping an address (192.168.65.194, say) from the NAT address pool when that address has not yet been assigned to a translation, the packet would end up looping until its TTL gets decremented to zero because of the default route on the NAT router. The way to avoid this would be to code in a static route for the address pool to Null0 as follows
ip route 192.168.65.192 255.255.255.248 Null0
With this static route, any addresses from the NAT pool not assigned to the translation would end up hitting this static route and would be dropped thus avoiding the problem with looping packets.
Another trick very similar to the last one is used in dial-up networks. Assume an access server is assigning an address from an address pool to dial-up clients. If the access server has a default route, packets addressed to any IP addresses in the dial-up address pool not currently assigned would result in packets looping. A static route for addresses in that pool to Null0 will prevent that problem. Note that if a packet comes in destined to an address that is indeed assigned to a dialed in client, it will get routed correctly because the access server will have a host route (/32) to that address and the semantics of the longest match with IP route lookup will ensure that the host route matches rather than the less specific static route to Null0 for that case. It is only packets in the address pool that are not assigned yet that will match the static route to Null0 and get dropped.
Let's take another scenario where the static route to Null0 comes in handy. Assume that you are summarizing prefix advertisements on a router but all subnets included in the summary may not be existing yet. In that case, packets addressed to non-existent subnets of the summary can end up looping if there is a default route on the router. This is avoided by adding a static route to Null0 for the summary address. Again, for subnets that do exist, the more specific route to the subnet will be matched because of the longest-match semantics but for non-existent subnets, the static route to Null0 will be matched and the packets dropped. Protocols like EIGRP will automatically add a static route to Null0 for the summarized prefix when auto summarization is in effect for exactly this loop prevention reason.
Now for a very different application of the static route to Null0. Recall how BGP will not advertise a prefix indicated in the network statement unless there is an exact route to the prefix. However, your router may only have routes to subnets of that prefix. To get BGP to advertise that route all you need to do is to add a static route to Null0 for that exact prefix you wish to advertise. The static route gets added to the routing table and that causes BGP to now advertise that prefix. Again, because of the longest prefix match semantics packets for valid subnets in that prefix will have a more specific entry in the routing table and so will be correctly routed. Packets for subnets of that prefix that do not exist will indeed match the static route to Null0 and get dropped but then that will be the correct behavior.
One very nice application of the static route to Null0 is when one needs to redistribute between RIP and and a classless routing protocol like OSPF where the RIP and OSPF domains share addressing in the same major network but if the masks are different. In such a scenario, if you try to redistribute the OSPF routes into RIP, it will not work. For instance, if the RIP and OSPF domains have addresses in the 172.169.0.0 major network but let's say RIP is using 172.169.5.0/24 addressing while the OSPF domain is using addresses from 172.169.10.128/25. If you simply try to redistribute the OSPF routes into RIP, you will see that RIP will not advertise the routes learned from OSPF. To get this to work, one option might be to change the mask for the OSPF domain to be /24 also but for obvious reasons that is not an easy thing to do. Instead, you could simply configure a static route to Null0 for the 172.169.10.0/24 prefix and redistribute the static route into RIP. As usual, because there will be more specific routes for the valid subnets of 172.169.10/24, packets will be routed properly and routers from the RIP domain will be able to reach routers in the OSPF domain.
I am sure I am only scratching the surface here with the use of the static route to Null0. If you are aware of other nifty uses of this tool, please leave a comment describing the scenario.
