Myth : It's been long time since I wanted to talk about this Myth which every CCNA deals with once in a while. It's a very common misconception that If we point two static routes for same destination with one being having next hop address vs other with exit interface; in such case load balancing will not occur. The reason given being is that the static route with exit interface option will show up in local routing table as "connected" and as we all know that connected has AD value of "0" Vs static route pointing towards next hop with AD value of "1". So by that rule the route with exit interface wins over route with next hop and because of that load balancing won't occur.
Let's hop on to command line to verify whats going on. I am going to use two routers connected back to back using two WAN interfaces. We will create 1 loopback on each router as "x.x.x.x/24" where X = Router Number.
After this we will point out one static route toward destination loopback of other router with same prefix length and then we will examine if load balancing is occurring for traffic or not.
Lets Hop on to routers and put the config:
R1(config)#int lo0
R1(config-if)#ip add 1.1.1.1 255.255.255.0
R1(config-if)#exit
R1(config)#int s0/0
R1(config-if)#ip add 12.12.12.1 255.255.255.0
R1(config-if)#no sh
R1(config-if)#exit
R1(config)#int s0/1
R1(config-if)#ip add 112.112.112.1 255.255.255.0
R1(config-if)#no sh
R1(config-if)#exit
R1(config)#ip route 2.2.2.0 255.255.255.0 12.12.12.2
R1(config)#ip route 2.2.2.0 255.255.255.0 serial 0/1
=====================================================
R2(config)#int lo0
R2(config-if)#ip add 2.2.2.2 255.255.255.0
R2(config-if)#no sh
R2(config-if)#exit
R2(config)#int s0/0
R2(config-if)#ip add 12.12.12.2 255.255.255.0
R2(config-if)#no sh
R2(config-if)#exit
R2(config)#int s0/1
R2(config-if)#ip add 112.112.112.2 255.255.255.0
R2(config-if)#no sh
R2(config-if)#exit
R2(config)#ip route 1.1.1.0 255.255.255.0 12.12.12.1
R2(config)#ip route 1.1.1.0 255.255.255.0 s0/1
=====================================================
R1#sh ip ro | b ^G
Gateway of last resort is not set
1.0.0.0/24 is subnetted, 1 subnets
C 1.1.1.0 is directly connected, Loopback0
2.0.0.0/24 is subnetted, 1 subnets
S 2.2.2.0 [1/0] via 12.12.12.2
is directly connected, Serial0/1
112.0.0.0/24 is subnetted, 1 subnets
C 112.112.112.0 is directly connected, Serial0/1
12.0.0.0/24 is subnetted, 1 subnets
C 12.12.12.0 is directly connected, Serial0/0
R2#sh ip ro | b ^G
Gateway of last resort is not set
1.0.0.0/24 is subnetted, 1 subnets
S 1.1.1.0 [1/0] via 12.12.12.1
is directly connected, Serial0/1
2.0.0.0/24 is subnetted, 1 subnets
C 2.2.2.0 is directly connected, Loopback0
112.0.0.0/24 is subnetted, 1 subnets
C 112.112.112.0 is directly connected, Serial0/1
12.0.0.0/24 is subnetted, 1 subnets
C 12.12.12.0 is directly connected, Serial0/0
=====================================================
R1#debug ip packet detail
IP packet debugging is on (detailed)
R1#ping 2.2.2.2 so lo0 r 4
Type escape sequence to abort.
Sending 4, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
Packet sent with a source address of 1.1.1.1
!!!!
Success rate is 100 percent (4/4), round-trip min/avg/max = 4/5/8 ms
R1#
*Mar 1 00:11:24.651: IP: tableid=0, s=1.1.1.1 (local), d=2.2.2.2 (Serial0/0), routed via FIB < Packet 1
*Mar 1 00:11:24.651: IP: s=1.1.1.1 (local), d=2.2.2.2 (Serial0/0), len 100, sending
*Mar 1 00:11:24.651: ICMP type=8, code=0
*Mar 1 00:11:24.655: IP: tableid=0, s=2.2.2.2 (Serial0/0), d=1.1.1.1 (Loopback0), routed via RIB
*Mar 1 00:11:24.655: IP: s=2.2.2.2 (Serial0/0), d=1.1.1.1, len 100, rcvd 4
*Mar 1 00:11:24.655: ICMP type=0, code=0
*Mar 1 00:11:24.655: IP: tableid=0, s=1.1.1.1 (local), d=2.2.2.2 (Serial0/0), routed via FIB < Packet 2
*Mar 1 00:11:24.655: IP: s=1.1.1.1 (local), d=2.2.2.2 (Serial0/0), len 100, sending
*Mar 1 00:11:24.655: ICMP type=8, code=0
*Mar 1 00:11:24.663: IP: tableid=0, s=2.2.2.2 (Serial0/0), d=1.1.1.1 (Loopback0), routed via RIB
*Mar 1 00:11:24.663: IP: s=2.2.2.2 (Serial0/0), d=1.1.1.1, len 100, rcvd 4
*Mar 1 00:11:24.663: ICMP type=0, code=0
*Mar 1 00:11:24.663: IP: tableid=0, s=1.1.1.1 (local), d=2.2.2.2 (Serial0/0), routed via FIB < Packet 3
*Mar 1 00:11:24.663: IP: s=1.1.1.1 (local), d=2.2.2.2 (Serial0/0), len 100, sending
*Mar 1 00:11:24.663: ICMP type=8, code=0
*Mar 1 00:11:24.667: IP: tableid=0, s=2.2.2.2 (Serial0/0), d=1.1.1.1 (Loopback0), routed via RIB
*Mar 1 00:11:24.667: IP: s=2.2.2.2 (Serial0/0), d=1.1.1.1, len 100, rcvd 4
*Mar 1 00:11:24.667: ICMP type=0, code=0
*Mar 1 00:11:24.667: IP: tableid=0, s=1.1.1.1 (local), d=2.2.2.2 (Serial0/0), routed via FIB < Packet 4
*Mar 1 00:11:24.667: IP: s=1.1.1.1 (local), d=2.2.2.2 (Serial0/0), len 100, sending
*Mar 1 00:11:24.667: ICMP type=8, code=0
*Mar 1 00:11:24.671: IP: tableid=0, s=2.2.2.2 (Serial0/0), d=1.1.1.1 (Loopback0), routed via RIB
*Mar 1 00:11:24.671: IP: s=2.2.2.2 (Serial0/0), d=1.1.1.1, len 100, rcvd 4
*Mar 1 00:11:24.671: ICMP type=0, code=0
=====================================================
Umm....Looks like CEF is not happy with us :-P Lets turn it off :-)
R1(config)#no ip cef
R1#ping 2.2.2.2 so lo0 r 4
Type escape sequence to abort.
Sending 4, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
Packet sent with a source address of 1.1.1.1
!!!!
Success rate is 100 percent (4/4), round-trip min/avg/max = 4/5/8 ms
R1#
*Mar 1 00:12:25.703: IP: tableid=0, s=1.1.1.1 (local), d=2.2.2.2 (Serial0/0), routed via RIB< Packet 1
*Mar 1 00:12:25.703: IP: s=1.1.1.1 (local), d=2.2.2.2 (Serial0/0), len 100, sending
*Mar 1 00:12:25.703: ICMP type=8, code=0
*Mar 1 00:12:25.707: IP: tableid=0, s=2.2.2.2 (Serial0/0), d=1.1.1.1 (Loopback0), routed via RIB
*Mar 1 00:12:25.707: IP: s=2.2.2.2 (Serial0/0), d=1.1.1.1, len 100, rcvd 4
*Mar 1 00:12:25.707: ICMP type=0, code=0
*Mar 1 00:12:25.707: IP: tableid=0, s=1.1.1.1 (local), d=2.2.2.2 (Serial0/1), routed via RIB< Packet 2
*Mar 1 00:12:25.707: IP: s=1.1.1.1 (local), d=2.2.2.2 (Serial0/1), len 100, sending
*Mar 1 00:12:25.707: ICMP type=8, code=0
*Mar 1 00:12:25.715: IP: tableid=0, s=2.2.2.2 (Serial0/0), d=1.1.1.1 (Loopback0), routed via RIB
*Mar 1 00:12:25.715: IP: s=2.2.2.2 (Serial0/0), d=1.1.1.1, len 100, rcvd 4
*Mar 1 00:12:25.715: ICMP type=0, code=0
*Mar 1 00:12:25.715: IP: tableid=0, s=1.1.1.1 (local), d=2.2.2.2 (Serial0/0), routed via RIB
*Mar 1 00:12:25.715: IP: s=1.1.1.1 (local), d=2.2.2.2 (Serial0/0), len 100, sending < Packet 3
*Mar 1 00:12:25.715: ICMP type=8, code=0
*Mar 1 00:12:25.719: IP: tableid=0, s=2.2.2.2 (Serial0/0), d=1.1.1.1 (Loopback0), routed via RIB
*Mar 1 00:12:25.719: IP: s=2.2.2.2 (Serial0/0), d=1.1.1.1, len 100, rcvd 4
*Mar 1 00:12:25.719: ICMP type=0, code=0
*Mar 1 00:12:25.723: IP: tableid=0, s=1.1.1.1 (local), d=2.2.2.2 (Serial0/1), routed via RIB
*Mar 1 00:12:25.723: IP: s=1.1.1.1 (local), d=2.2.2.2 (Serial0/1), len 100, sending< Packet 4
*Mar 1 00:12:25.723: ICMP type=8, code=0
*Mar 1 00:12:25.723: IP: tableid=0, s=2.2.2.2 (Serial0/0), d=1.1.1.1 (Loopback0), routed via RIB
*Mar 1 00:12:25.727: IP: s=2.2.2.2 (Serial0/0), d=1.1.1.1, len 100, rcvd 4
*Mar 1 00:12:25.727: ICMP type=0, code=0
Everything seems to be in shape now :-)
R1#sh ip route 2.2.2.0
Routing entry for 2.2.2.0/24
Known via "static", distance 1, metric 0 (connected)
Routing Descriptor Blocks:
* 12.12.12.2
Route metric is 0, traffic share count is 1
directly connected, via Serial0/1
Route metric is 0, traffic share count is 1
so conclusion is that despite of how you configure the static route (Exit Interface Vs Next Hop), the AD is always going to be 1.
Though specifying next hop has some advantages over exit interface option on Multi Access network types. But personally I like to use what I call mix of both in which while adding static route you specify exit interface with next hop address. This way we can make sure that no route-recursion issue will occur. And if you are thinking " Route Recursion issues with Static routing - what the hack is that" ?..ummm....let me save it for my next post for CCNA guys :-)
here is the syntax BTW which I just talked about
R1(config)#ip route 2.2.2.0 255.255.255.0 s0/0 12.12.12.2
R1(config)#ip route 2.2.2.0 255.255.255.0 s0/1 112.112.112.2
Further Readings:
HTH...
Deepak Arora
No comments:
Post a Comment