From: Scott Vermillion (scott_ccie_list@it-ag.com)
Date: Sun Dec 23 2007 - 18:01:49 ART
Hey Dane,
In my collection of Dynamips lab topologies, I just happened to have a
three-router hub-and-spoke FR configuration. Only difference is that mine
is R1, R2, and R3. I configured loopbacks 1.0.0.0/8, 2.0.0.0/8, and
3.0.0.0/8 so I could do some packet capture and post a RIP advertisement
from one of the spokes to the hub (R1). I too used the 10.0.0.0 network for
the FR cloud. Check this out from R2 towards R1:
No. Time Source Destination Protocol
Info
8 22.280000 10.0.0.2 224.0.0.9 RIPv2
Response
Frame 8 (116 bytes on wire, 116 bytes captured)
Frame Relay
Internet Protocol, Src: 10.0.0.2 (10.0.0.2), Dst: 224.0.0.9 (224.0.0.9)
User Datagram Protocol, Src Port: router (520), Dst Port: router (520)
Routing Information Protocol
Command: Response (2)
Version: RIPv2 (2)
Routing Domain: 0
IP Address: 1.0.0.0, Metric: 1
Address Family: IP (2)
Route Tag: 0
IP Address: 1.0.0.0 (1.0.0.0)
Netmask: 255.0.0.0 (255.0.0.0)
Next Hop: 0.0.0.0 (0.0.0.0)
Metric: 1
IP Address: 2.0.0.0, Metric: 1
Address Family: IP (2)
Route Tag: 0
IP Address: 2.0.0.0 (2.0.0.0)
Netmask: 255.0.0.0 (255.0.0.0)
Next Hop: 0.0.0.0 (0.0.0.0)
Metric: 1
IP Address: 3.0.0.0, Metric: 1
Address Family: IP (2)
Route Tag: 0
IP Address: 3.0.0.0 (3.0.0.0)
Netmask: 255.0.0.0 (255.0.0.0)
Next Hop: 0.0.0.0 (0.0.0.0)
Metric: 1
IP Address: 10.0.0.0, Metric: 1
Address Family: IP (2)
Route Tag: 0
IP Address: 10.0.0.0 (10.0.0.0)
Netmask: 255.0.0.0 (255.0.0.0)
Next Hop: 0.0.0.0 (0.0.0.0)
Metric: 1
Note that R2 is advertising 3.0.0.0/8 with a metric of 1 towards R1!
Likewise, R3 advertises 2.0.0.0/8 towards R1 with a metric of just 1. You
can actually see that in your debug below. Note also the "Next Hop" field
is not populated, which in RIPv2 vernacular means "send traffic to this
destination towards me." Your inability to ping just meant that you were
cached to one of two possible routes to reach the given network, and it was
the wrong one of those two that was cached. When you disable auto-summary
under rip, the updates change as follows:
No. Time Source Destination Protocol
Info
209 552.200000 10.0.0.2 224.0.0.9 RIPv2
Response
Frame 209 (116 bytes on wire, 116 bytes captured)
Frame Relay
Internet Protocol, Src: 10.0.0.2 (10.0.0.2), Dst: 224.0.0.9 (224.0.0.9)
User Datagram Protocol, Src Port: router (520), Dst Port: router (520)
Routing Information Protocol
Command: Response (2)
Version: RIPv2 (2)
Routing Domain: 0
IP Address: 1.0.0.0, Metric: 2
Address Family: IP (2)
Route Tag: 0
IP Address: 1.0.0.0 (1.0.0.0)
Netmask: 255.0.0.0 (255.0.0.0)
Next Hop: 10.0.0.1 (10.0.0.1)
Metric: 2
IP Address: 2.0.0.0, Metric: 1
Address Family: IP (2)
Route Tag: 0
IP Address: 2.0.0.0 (2.0.0.0)
Netmask: 255.0.0.0 (255.0.0.0)
Next Hop: 0.0.0.0 (0.0.0.0)
Metric: 1
IP Address: 3.0.0.0, Metric: 3
Address Family: IP (2)
Route Tag: 0
IP Address: 3.0.0.0 (3.0.0.0)
Netmask: 255.0.0.0 (255.0.0.0)
Next Hop: 10.0.0.3 (10.0.0.3)
Metric: 3
IP Address: 10.0.0.0, Metric: 1
Address Family: IP (2)
Route Tag: 0
IP Address: 10.0.0.0 (10.0.0.0)
Netmask: 255.0.0.0 (255.0.0.0)
Next Hop: 0.0.0.0 (0.0.0.0)
Metric: 1
Note that split horizon is disabled by default on physical NBMA interfaces,
which is how you did your spokes. So you can see R2 in this case
advertising 3.0.0.0/8 back out the interface it learned it from, but now
it's populating Next Hop and it's incrementing the metric properly. Another
way to fix this problem is to manually enable split horizon on the spokes.
Regards,
Scott
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of Dane
Newman
Sent: Sunday, December 23, 2007 8:22 AM
To: ccielab@groupstudy.com
Subject: Re: why is rip acting like this? am I going nuts?
Ok yeah so playing around with it a bit more I did no auto on all the
routers to not summarize and the redundant routes go away and everything
works I guess this is an eye opener how rip behaves. I didnt think we
needed no auto for this lab because all the routes are in there classful
boundary's
On 12/23/07, Dane Newman <dnewman@datasc.com> wrote:
>
> Hello Experts,
>
> I am doing an Internetwork expert lab for rip in workbook 1 and rip is
> acting very odd
>
>
>
> I have a hub and spoke topolgy with R1 being the hub and then R4 and R5
> being the spokes.
>
> R1 has a network 1.0.0.1 advertised into rip
> R4 has network 4.0.0.4 advertised into rip
> R5 has network 5.0.0.5 advetised into rip
> The 10.0.0.0 network connects all the spokes to the hub via frame relay
>
> There are two odd things that I feel are wrong that I cant explain
>
>
> 1. Below is the output of show ip route on R1 and it is load balancing
> the traffic to the spokes which it should NOT be. It should be saying to
> get to 4.0.0.0/8 via 10.0.0.4 only and NOT having load balancing with
> 10.0.0.5. I debugged ip rip and found that R5 was advertising the
> 4.0.0.0/8 network with 1 hop but I don't know why because it only has
> reachability to it via the hub.
>
> 2. when I ping one spoke from another spoke such as
>
>
> R5#ping 4.0.0.4
>
> Type escape sequence to abort.
> Sending 5, 100-byte ICMP Echos to 4.0.0.4, timeout is 2 seconds:
> .....
> Success rate is 0 percent (0/5)
>
>
>
> It does not go through. Can anyone explain why this is happening even if
> its load balancing half of them should go through correct?
>
>
> 1#show ip route
> Codes: 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
>
> Gateway of last resort is not set
>
> C 1.0.0.0/8 is directly connected, FastEthernet0/0
> R 4.0.0.0/8 [120/1] via 10.0.0.5, 00:00:00, Serial0/0.1
> [120/1] via 10.0.0.4, 00:00:00, Serial0/0.1
> R 5.0.0.0/8 [120/1] via 10.0.0.5, 00:00:00, Serial0/0.1
> [120/1] via 10.0.0.4, 00:00:00, Serial0/0.1
> C 10.0.0.0/8 is directly connected, Serial0/0.1
>
>
> Here is my config
>
> R1:
>
> interface FastEthernet0/0
> ip address 1.0.0.1 255.0.0.0
> duplex auto
> speed auto
> !
> interface Serial0/0
> no ip address
> encapsulation frame-relay
> no frame-relay inverse-arp
> !
> interface Serial0/0.1 multipoint
> ip address 10.0.0.1 255.0.0.0
> no ip split-horizon
> frame-relay map ip 10.0.0.4 104 broadcast
> frame-relay map ip 10.0.0.5 105 broadcast
> !
> interface Serial0/1
> no ip address
> shutdown
> !
> router rip
> version 2
> network 1.0.0.0
> network 10.0.0.0
>
> R4:
>
> interface Ethernet0/0
> ip address 4.0.0.4 255.0.0.0
> half-duplex
> !
> interface Serial0/0
> ip address 10.0.0.4 255.0.0.0
> encapsulation frame-relay
> frame-relay map ip 10.0.0.1 401 broadcast
> frame-relay map ip 10.0.0.5 401
> no frame-relay inverse-arp
> !
> router rip
> version 2
> network 4.0.0.0
> network 10.0.0
>
>
> R5:
> interface Ethernet0/0
> ip address 5.0.0.5 255.0.0.0
> half-duplex
> !
> interface Serial0/0
> ip address 10.0.0.5 255.0.0.0
> encapsulation frame-relay
> frame-relay map ip 10.0.0.1 501 broadcast
> frame-relay map ip 10.0.0.4 501
> no frame-relay inverse-arp
> !
> interface Ethernet0/1
> no ip address
> shutdown
> half-duplex
> !
> interface Serial0/1
> no ip address
> shutdown
> !
> router rip
> version 2
> network 5.0.0.0
> network 10.0.0.0
>
>
>
> R1:
> R1#debug ip rip
> RIP protocol debugging is on
> R1#
> *Oct 25 05:27:41.792: RIP: received v2 update from 10.0.0.5 on Serial0/0.1
> *Oct 25 05:27:41.792: 1.0.0.0/8 via 0.0.0.0 in 1 hops
> *Oct 25 05:27:41.796: 4.0.0.0/8 via 0.0.0.0 in 1 hops
> *Oct 25 05:27:41.796: 5.0.0.0/8 via 0.0.0.0 in 1 hops
> *Oct 25 05:27:41.796: 10.0.0.0/8 via 0.0.0.0 in 1 hops
> *Oct 25 05:27:43.090: RIP: sending v2 update to 224.0.0.9 via
> FastEthernet0/0 (1.0.0.1)
> *Oct 25 05:27:43.090: RIP: build update entries
> *Oct 25 05:27:43.090: 4.0.0.0/8 via 0.0.0.0, metric 1, tag 0
> *Oct 25 05:27:43.090: 5.0.0.0/8 via 0.0.0.0, metric 1, tag 0
> *Oct 25 05:27:43.090: 10.0.0.0/8 via 0.0.0.0, metric 1, tag 0
> *Oct 25 05:27:45.386: RIP: sending v2 update to 224.0.0.9 via Serial0/0.1
> (10.0.0.1)
> *Oct 25 05:27:45.386: RIP: build update entries
> *Oct 25 05:27:45.386: 1.0.0.0/8 via 0.0.0.0, metric 1, tag 0
> *Oct 25 05:27:45.386: 4.0.0.0/8 via 0.0.0.0, metric 1, tag 0
> *Oct 25 05:27:45.386: 5.0.0.0/8 via 0.0.0.0, metric 1, tag 0
> *Oct 25 05:27:45.386 : 10.0.0.0/8 via 0.0.0.0, metric 1, tag 0
> *Oct 25 05:27:59.125: RIP: ignored v2 update from bad source 5.0.0.5 on
> FastEthernet0/0
> *Oct 25 05:28:07.078: RIP: received v2 update from 10.0.0.4 on Serial0/0.1
> *Oct 25 05:28:07.082: 1.0.0.0/8 via 0.0.0.0 in 1 hops
> *Oct 25 05:28:07.082: 4.0.0.0/8 via 0.0.0.0 in 1 hops
> *Oct 25 05:28:07.082: 5.0.0.0/8 via 0.0.0.0 in 1 hops
> *Oct 25 05:28:07.082: 10.0.0.0/8 via 0.0.0.0 in 1 hops
> *Oct 25 05:28:07.791: RIP: received v2 update from 10.0.0.5 on Serial0/0.1
> *Oct 25 05:28:07.795: 1.0.0.0/8 via 0.0.0.0 in 1 hops
> *Oct 25 05:28:07.795: 4.0.0.0/8 via 0.0.0.0 in 1 hops
> *Oct 25 05:28:07.795: 5.0.0.0/8 via 0.0.0.0 in 1 hops
> *Oct 25 05:28:07.795: 10.0.0.0/8 via 0.0.0.0 in 1 hops
> *Oct 25 05:28:09.942: RIP: sending v2 update to 224.0.0.9 via
> FastEthernet0/0 (1.0.0.1)
> *Oct 25 05:28: 09.942: RIP: build update entries
> *Oct 25 05:28:09.942: 4.0.0.0/8 via 0.0.0.0, metric 1, tag 0
> *Oct 25 05:28:09.942: 5.0.0.0/8 via 0.0.0.0, metric 1, tag 0
> *Oct 25 05:28:09.942: 10.0.0.0/8 via 0.0.0.0, metric 1, tag 0
> *Oct 25 05:28:13.993: RIP: sending v2 update to 224.0.0.9 via Serial0/0.1
> (10.0.0.1)
> *Oct 25 05:28:13.993: RIP: build update entries
> *Oct 25 05:28:13.993: 1.0.0.0/8 via 0.0.0.0, metric 1, tag 0
> *Oct 25 05:28:13.993: 4.0.0.0/8 via 0.0.0.0, metric 1, tag 0
> *Oct 25 05:28:13.993: 5.0.0.0/8 via 0.0.0.0, metric 1, tag 0
> *Oct 25 05:28:13.993: 10.0.0.0/8 via 0.0.0.0, metric 1, tag 0
>
>
> R4:
> R4#debug ip rip
> RIP protocol debugging is on
> R4#
> *Mar 3 05:54:46.291: RIP: sending v2 update to 224.0.0.9 via Ethernet0/0
> (4.0.0.4)
> *Mar 3 05:54: 46.291: RIP: build update entries
> *Mar 3 05:54:46.291: 1.0.0.0/8 via 0.0.0.0, metric 1, tag 0
> *Mar 3 05:54:46.291: 5.0.0.0/8 via 0.0.0.0, metric 1, tag 0
> *Mar 3 05:54:46.291: 10.0.0.0/8 via 0.0.0.0, metric 1, tag 0
> *Mar 3 05:55:08.907: RIP: sending v2 update to 224.0.0.9 via Serial0/0 (
> 10.0.0.4)
> *Mar 3 05:55:08.907: RIP: build update entries
> *Mar 3 05:55:08.907: 1.0.0.0/8 via 0.0.0.0, metric 1, tag 0
> *Mar 3 05:55:08.907: 4.0.0.0/8 via 0.0.0.0, metric 1, tag 0
> *Mar 3 05:55:08.907: 5.0.0.0/8 via 0.0.0.0, metric 1, tag 0
> *Mar 3 05:55:08.907: 10.0.0.0/8 via 0.0.0.0, metric 1, tag 0
> *Mar 3 05:55:10.131: RIP: received v2 update from 10.0.0.1 on Serial0/0
> *Mar 3 05:55:10.131: 1.0.0.0/8 via 0.0.0.0 in 1 hops
> *Mar 3 05:55:10.131: 4.0.0.0/8 via 0.0.0.0 in 1 hops
> *Mar 3 05:55:10.131: 5.0.0.0/8 via 0.0.0.0 in 1 hops
> *Mar 3 05:55:10.131: 10.0.0.0/8 via 0.0.0.0 in 1 hops
> *Mar 3 05:55:15.015: RIP: sending v2 update to 224.0.0.9 via Ethernet0/0
> (4.0.0.4)
> *Mar 3 05:55: 15.015: RIP: build update entries
> *Mar 3 05:55:15.015: 1.0.0.0/8 via 0.0.0.0, metric 1, tag 0
> *Mar 3 05:55:15.015: 5.0.0.0/8 via 0.0.0.0, metric 1, tag 0
> *Mar 3 05:55:15.015: 10.0.0.0/8 via 0.0.0.0, metric 1, tag 0
>
>
>
>
> R5:
> Output from debug ip rip
> *Mar 1 05:34:06.947: RIP: sending v2 update to 224.0.0.9 via Ethernet0/0
> (5.0.0.5)
> *Mar 1 05:34:06.947: RIP: build update entries
> *Mar 1 05:34:06.947 : 1.0.0.0/8 via 0.0.0.0, metric 1, tag 0
> *Mar 1 05:34:06.947: 4.0.0.0/8 via 0.0.0.0, metric 1, tag 0
> *Mar 1 05:34:06.947: 10.0.0.0/8 via 0.0.0.0, metric 1, tag 0
> R5#
> *Mar 1 05:34:14.395: RIP: ignored v2 update from bad source 1.0.0.1 on
> Ethernet0/0
> *Mar 1 05:34:14.727: RIP: sending v2 update to 224.0.0.9 via Serial0/0 (
> 10.0.0.5)
> *Mar 1 05:34:14.727: RIP: build update entries
> *Mar 1 05:34:14.727: 1.0.0.0/8 via 0.0.0.0, metric 1, tag 0
> *Mar 1 05:34:14.727: 4.0.0.0/8 via 0.0.0.0, metric 1, tag 0
> *Mar 1 05:34:14.727: 5.0.0.0/8 via 0.0.0.0, metric 1, tag 0
> *Mar 1 05:34:14.727: 10.0.0.0/8 via 0.0.0.0, metric 1, tag 0
> *Mar 1 05:34:22.387: RIP: received v2 update from 10.0.0.1 on Serial0/0
> *Mar 1 05:34:22.387: 1.0.0.0/8 via 0.0.0.0 in 1 hops
> *Mar 1 05:34:22.387: 4.0.0.0/8 via 0.0.0.0 in 1 hops
> *Mar 1 05:34:22.387: 5.0.0.0/8 via 0.0.0.0 in 1 hops
> *Mar 1 05:34:22.387: 10.0.0.0/8 via 0.0.0.0 in 1 hops
> R5#
> *Mar 1 05:34:35.079: RIP: sending v2 update to 224.0.0.9 via Ethernet0/0
> (5.0.0.5)
> *Mar 1 05:34:35.079: RIP: build update entries
> *Mar 1 05:34:35.079: 1.0.0.0/8 via 0.0.0.0, metric 1, tag 0
> *Mar 1 05:34:35.079: 4.0.0.0/8 via 0.0.0.0, metric 1, tag 0
> *Mar 1 05:34:35.079: 10.0.0.0/8 via 0.0.0.0, metric 1, tag 0
>
>
>
>
>
> --
> Dane Newman
> MCSE: Messaging, CCNP, CCEA
>
-- Dane Newman MCSE: Messaging, CCNP, CCEA
This archive was generated by hypermail 2.1.4 : Tue Jan 01 2008 - 12:04:31 ARST