Hi Bryan,
Briljant!
R2#sh ip cef 150.100.100.5 detail
150.100.100.5/32, version 64, epoch 0, connected, cached adjacency
150.100.100.5
0 packets, 0 bytes
via 150.100.100.5, Serial2/0.25, 0 dependencies
next hop 150.100.100.5, Serial2/0.25
valid cached adjacency
R2#sh ip cef 150.100.100.6 detail
150.100.100.6/32, version 32, epoch 0, cached adjacency 150.100.100.6
0 packets, 0 bytes
via 150.100.100.6, Serial2/0.26, 0 dependencies
next hop 150.100.100.6, Serial2/0.26
valid cached adjacency
So the CEF table is not only build by using the only RIB, but also it
takes details from the FR config into account.
To continue the experiment:
R2#ping 150.100.100.5
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 150.100.100.5, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 56/56/60 ms
R2#ping 150.100.100.6
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 150.100.100.6, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 56/57/60 ms
R2#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R2(config)#no ip cef
R2(config)#end
R2#ping 150.100.100.5
*Mar 2 20:09:25.987: %SYS-5-CONFIG_I: Configured from console by console
R2#ping 150.100.100.5
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 150.100.100.5, timeout is 2 seconds:
.!.!.
Success rate is 40 percent (2/5), round-trip min/avg/max = 56/56/56 ms
R2#ping 150.100.100.6
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 150.100.100.6, timeout is 2 seconds:
.!.!.
Success rate is 40 percent (2/5), round-trip min/avg/max = 56/56/56 ms
R2#
Without CEF, the routing table is consulted for next hop determination,
and it has two identical routes for 150.100.100.0/24, so with per packet
load balancing; half of the pings is lost!
Regards,
Frank
Bryan Bartik schreef:
> Frank,
>
> This is a function of CEF, which actually performs the forwarding.
> Look at the CEF entries for the next hop and you will see adjacencies
> for each interface. Turn off CEF and then test some more :)
>
> On Thu, Apr 8, 2010 at 12:43 PM, Frank <[email protected]
> <mailto:[email protected]>> wrote:
>
>
> All,
>
> I'm still struggling with some of the frame-relay concept. In the
> DSG two multipoint sub-interfaces are used with the same IP subnet:
>
> interface Serial2/0.25 multipoint
> ip address 150.100.100.2 255.255.255.0
> ip rip authentication mode md5
> ip rip authentication key-chain R2R5
> frame-relay map ip 150.100.100.5 205 broadcast
> !
> interface Serial2/0.26 multipoint
> ip address 150.100.100.2 255.255.255.0
> ip rip authentication mode md5
> ip rip authentication key-chain R2R6
> frame-relay map ip 150.100.100.6 206 broadcast
>
>
> But, when we look at the routing table:
>
> R2#sh ip route 150.100.100.5
> Routing entry for 150.100.100.0/24 <http://150.100.100.0/24>
> Known via "connected", distance 0, metric 0 (connected, via
> interface)
> Redistributing via rip
> Advertised by rip
> Routing Descriptor Blocks:
> * directly connected, via Serial2/0.26
> Route metric is 0, traffic share count is 1
> directly connected, via Serial2/0.25
> Route metric is 0, traffic share count is 1
>
> R2#sh ip route 150.100.100.6
> Routing entry for 150.100.100.0/24 <http://150.100.100.0/24>
> Known via "connected", distance 0, metric 0 (connected, via
> interface)
> Redistributing via rip
> Advertised by rip
> Routing Descriptor Blocks:
> * directly connected, via Serial2/0.26
> Route metric is 0, traffic share count is 1
> directly connected, via Serial2/0.25
> Route metric is 0, traffic share count is 1
>
> two identical routes exist towards a next hop.
>
> The thing that I still can't grasp is the relation between the IP
> routing table and the frame-relay map.
> From the routing table point of view there are two identical paths
> towards the next hop, yet always the correct path seems to be
> picked. How?
>
> Regards,
>
> Frank
>
>
>
>
> _______________________________________________
> For more information regarding industry leading CCIE Lab training,
> please visit www.ipexpert.com <http://www.ipexpert.com>
>
>
>
>
> --
> Bryan Bartik
> CCIE #23707 (R&S, SP), CCNP
> Sr. Support Engineer - IPexpert, Inc.
> URL: http://www.IPexpert.com
_______________________________________________
For more information regarding industry leading CCIE Lab training, please visit
www.ipexpert.com
