debug ip rip

[bellocarico]

I've got a problem with my network.

Without posting the long configs, I'll try to summarize here.

There is a trunk between 2x 3550 running over an etherchannel made by 3x 100Mb links.

It's a layer 2 etherchannel ,and it's correctly moving data back and forth.

On the vtp server (switch 1) I've created VLAN 738 and on each switch I've created an SVI for vlan 783 with different ip addresses under the same subnet.

I can successfully ping each other.

Between the 2 SVI ip addresses I'm running RIP v2.

The first switch is running also OSPF and fully redistributing from/to RIP.

Now, Switch 1 can see the routes from Switch 2, but Switch 2 doesn't receive routes from Switch 1.

I've run the debug ip rip on Switch 2 and this is the result:

....

132.1.0.0 via 0.0.0.0 in 17 hops (inaccessible)

....

Basically all the routes in ingress have a hop count higher than 16, even if the sending router is 1 hope away.

Running the same debug on Switch 1 I can see that it sends the route with a metric of 1.

Where am I loosing 16 hops??

Also, why is the sender refering to metric wher the receiver refers to hopw count?

I know they are the same thing for rip, but just to understand.

Last thing, why is the "via" metioning 0.0.0.0 and not the correct ip of the senting interface? (this on both switches)

Anything I'd better checking?

Thanks!

[Richard Burts]

Stefano

Lets do the easy part first: why is the "via" metioning 0.0.0.0 and not the correct ip? If RIP is advertising the route as unreachable then it puts in 0.0.0.0 because there is no viable next hop for an inaccessible route.

then: why is the sender refering to metric wher the receiver refers to hopw count? I can think of two possible explanations. Perhaps the switches are running different versions of code and the wording changed between versions. Or (perhaps more likely) the router refers to metric for routes that are reachable and uses hop count when referring to routes that are not accessible.

More difficult: why are routes from switch 1 marked as not accessible. My guess is that this is the result of split horizon. You have not given any information about the topology of the network but I am guessing that switch 2 has routes to advertise to switch 1 (which you apparently see) but that switch 1 does know any routes other than what it learned from switch 2. When switch 1 learns routes from switch 2 then split horizon says that switch 1 should advertise those routes to switch 2 as inaccessible (hop count greater than 16).

Perhaps if you told us a bit more about the topology of the network we would understand this situation better. If you post the output of show ip route from switch 1 and from switch 2 then we could see whether my guess is correct.

HTH

Rick

[bellocarico]

Rick, thank you very much for your interest. Very useful (as usual)

Not sure about the 0.0.0.0 as, looking in Internet I cans see many other similar output refering as 0.0.0.0 as source but having hop counts betwee 1-16 (so reachable I'd say).

My guess is that this is the way RIP identifies a shared broadcast domain.

Spot on. I think you're right on the metric., it seems just a different output for different situation.

I tried the no ip split-horizon on the SVI interface, but with no luck. ASAIK RIP is advertising out as unreachable only routes received from the neighbor (poison reverse).

This means to me that if Switch2 sends 2 routes to Switch 1 on port SVI-783, RIP will still be able to send out valid routes to Switch2 as long as they are not the same learned from Switch2 (the one learned from OSPF in this case)

About the topology:

---R1----Switch1------Switch2----

-R1 is an OSPF ABR. Area 0 on the left and area 17 on the right.

-Switch1 is running both OSPF and RIPv2, redistributing mutually (OSPF with the subnet paramenter)

-Switch2 is running RIPv2 only and it's connected to Switch1 with a trunk ISL over an etherchannel (3xfastethernet) link.

-Switch2 is also advertising in RIP a stub network connected on a different VLAN (8)

I've manually created the vlan 783 on Switch1 (as this is the vtp server) + both switches have an SVI vlan interface 783 with IP addresses in the same subnet. They also can ping successfully each other.

Thanks!!

[bellocarico]

Another thing:

Comparing the bebug output on the 2 switches, I can see that Switch 2 is sending updates wit hthe correct ip source:

00:12:19: RIP: sending v2 update to 224.0.0.9 via Vlan783 (204.12.1.8)

00:12:19: RIP: build update entries

00:12:19: 132.1.8.0/24 via 0.0.0.0, metric 1, tag 0

Where switch1 is sending from a source of 0.0.0.0 instead, and this with or without split-horizon:

00:16:04: RIP: sending v2 update to 224.0.0.9 via Loopback0 (150.1.7.7)

00:16:04: RIP: build update entries

00:16:04: 30.0.0.0/16 via 0.0.0.0, metric 2, tag 0

Notice that for some reason Switch1 is sending uopdates from a loopback interface (??)

No sure why and how to modify this.

Thanks again!

[bellocarico]

Ok, I've thing I've sorted out the main problem. There was an offset-list inbound on Switch2...

I still would like to identify the "from 0.0.0.0" thing

[Richard Burts]

Stefano

The inbound offset list would certainly explain the main symptom.

Now that you have provided some output from the debug I think that we can get closer to an explanation of the 0.0.0.0. The first thing I would like to do is to be clear what the first line of the debug output is telling us:

00:12:19: RIP: sending v2 update to 224.0.0.9 via Vlan783 (204.12.1.8)

The first field tells that RIPv2 sends routing updates to multicast address 224.0.0.9 and that should be pretty obvious. "via vlan 783" is indicating the interface through which it is sending this update. And 204.12.1.8 should be the IP address of that interface. Is this correct?

Having established what the fields in the message tell us, now lets look at the second set of debug messages:

00:16:04: RIP: sending v2 update to 224.0.0.9 via Loopback0 (150.1.7.7)

RIPv2 is sending an update to the multicast address and the interface through which it is sending the update is loopback 0. Note that this is to the loopback of the same router not to an external neighbor. Am I correct in assuming that the address of the loopback is 150.1.7.7?

I believe that 0.0.0.0 is used as the next hop because the router knows that there is no neighbor on this interface who will be forwarding packets. If you look into the router config you should find that there is a network statement under router rip that matches the address of the loopback interface. So RIP includes the loopback and is sending routing updates to the included interface. But what is the purpose of sending RIP updates to your own loopback? If you want to suppress these updates to loopback 0 you can use this command under rouer rip:

passive-interface loopback0

HTH

Rick

[bellocarico]

Very useful! (as usual)

Thanks a lot!!!