cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1132
Views
0
Helpful
7
Replies

RIP oddity or cisco feature?

larrybelan
Level 1
Level 1

Gang,

I've been trying to debug an odd issue with RIP routing, and I've really stumbled onto a can of worms.

What I'm seeing is TWO different tables being advertised.  One table via Multicast, and a different one via Unicast to a neighbor.

Router is a 2901 running c2900-universalk9-mz.SPA.151-3.T.bin

Here's the relavant code:

------

router rip

version 2

redistribute static route-map NODFGW

redistribute eigrp 1001 metric 3

passive-interface GigabitEthernet0/0.100

network 192.168.21.0

neighbor 192.168.21.10

default-metric 2

no auto-summary

access-list 13 deny   0.0.0.0

access-list 13 permit any

route-map NODFGW permit 100

match ip address 13

------

With these settings:

I'm filtering OUT the advertisement of the static route to 0.0.0.0 0.0.0.0

The multicast advertisment delivers ONLY the local subnets on this router with ONE static route that points to the local router.  The other statics, and the eigrp redistribution is NOT there.

The unicast advertisement contains ALL the eigrp routes, statics, and local subnets to the router.

I'm looking at the packets via Wireshark...using a mirrored port on a switch.

I'm NOT a cisco expert, but I figure that I'm not limiting WHAT to send where with this config.  Is there some explanation for this odd behavior?  I figure RIP would just send the same table via multicast and unicast?

7 Replies 7

ck.chaminda
Level 1
Level 1

With my route-maps I use extended access-lists of the following format:

ip access-list extended XXX

   permit ip host 0.0.0.0 host 0.0.0.0

I haven't seen any issues so far, though I haven't used the normal access-lists. Looking at your access-list it might the issue as you have a deny any statement followed by a permit any. So try using a extended access-list?

barnesp
Level 1
Level 1

Can you provide some more information.

Ideally I would like to see the interface configuration associated with network 192.168.21.0. Also how many routers are running RIP on this network. If you remove the neighbour statement under RIP do multicast updates work correctly. In most cases you would run multicast unless you have some very specific reasons not to. For example securing updates so that only a small number devices can see updates. Also you make the outgoing interface used for the neighborship passive. The RIP process doesn't disable multicast when you configure unicast neighbours.

Sent from Cisco Technical Support iPad App

There are only two routers running RIP, one because it doesn't do eigrp.

Because of that, I would prefer to just run the unicast rip, to the neighbor.  It's a one-way transaction,  the 2901 feeds the other rip router/firewall a list of all of our internal networks.

I stumbled over this issue because I'm having RIP problems with the receiving router.  Look around for other posts by me to see what it is.  I turned on the multicast (by removing passive-interface g0/0.20) to see the rip traffic without port mirroring...and here I am.

The 2901 interface has two vlans:  20 and 100.  It carries three subnets:  192.168.x.0/24 & 172.16.x.x/28 on vlan 20 and 10.0.x.0/24 on vlan 100 (voip).   The internal network has a number of other similar subnets in the same arrangment.  I'm just trying to funnel all of these subnets into the firewall, so it knows our internal nets exist and can route our Inet traffic properly back  into our internal network.

The 2901 also has a static 0.0.0.0 0.0.0.0 route to the firewall, but that will change in the future.  I'm using the route-map to make sure that I don't send that static route back to the firewall.

OK so you used Wireshark to capture the traffic.

Instead can you provide the following output from the Cisco side -

show ip route

show ip rip database

debug ip rip

For the last command run this for a few minutes, so that we can see what is going on. Please post the output.

Also can you try your configuration without unicast RIP by removing the neighbor statement. I would like to see the debug from RIP in this case.

I haven't had a chance to check for bugs yet!

Sent from Cisco Technical Support iPad App

larrybelan
Level 1
Level 1

It's a live network, and I don't want routes dropping out and folks getting upset with me.

sho ip route

-----------------

Gateway of last resort is 192.168.21.10 to network 0.0.0.0

S*    0.0.0.0/0 [1/0] via 192.168.21.10

       10.0.0.0/8 is variably subnetted, 6 subnets, 2 masks

C        10.0.21.0/24 is directly connected, GigabitEthernet0/0.100

S        10.0.21.253/32 is directly connected, ISM0/0

L        10.0.21.254/32 is directly connected, GigabitEthernet0/0.100

D EX     10.0.22.0/24

            [170/2585856] via 192.168.21.1, 2d18h, GigabitEthernet0/0.20

D EX     10.0.23.0/24

            [170/2585856] via 192.168.21.1, 2d18h, GigabitEthernet0/0.20

D EX     10.0.24.0/24

            [170/2585856] via 192.168.21.1, 2d18h, GigabitEthernet0/0.20

       172.16.0.0/16 is variably subnetted, 5 subnets, 2 masks

C        172.16.1.240/28 is directly connected, GigabitEthernet0/0.20

L        172.16.1.245/32 is directly connected, GigabitEthernet0/0.20

D EX     172.16.2.48/28

            [170/2585856] via 192.168.21.1, 2d18h, GigabitEthernet0/0.20

D EX     172.16.2.112/28

            [170/2585856] via 192.168.21.1, 2d18h, GigabitEthernet0/0.20

D EX     172.16.2.192/28

            [170/2585856] via 192.168.21.1, 2d18h, GigabitEthernet0/0.20

       192.168.20.0/32 is subnetted, 4 subnets

C        192.168.20.1 is directly connected, Loopback1

D EX     192.168.20.2

            [170/2585856] via 192.168.21.1, 2d18h, GigabitEthernet0/0.20

D EX     192.168.20.3

            [170/2585856] via 192.168.21.1, 2d18h, GigabitEthernet0/0.20

D EX     192.168.20.4

            [170/2585856] via 192.168.21.1, 2d18h, GigabitEthernet0/0.20

       192.168.21.0/24 is variably subnetted, 2 subnets, 2 masks

C        192.168.21.0/24 is directly connected, GigabitEthernet0/0.20

L        192.168.21.254/32 is directly connected, GigabitEthernet0/0.20

D EX  192.168.22.0/24

            [170/2585856] via 192.168.21.1, 2d18h, GigabitEthernet0/0.20

D EX  192.168.23.0/24

            [170/2585856] via 192.168.21.1, 2d18h, GigabitEthernet0/0.20

D EX  192.168.24.0/24

            [170/2585856] via 192.168.21.1, 2d18h, GigabitEthernet0/0.20

sho ip rip database

----------------------------

10.0.0.0/8    auto-summary

10.0.21.0/24    directly connected, GigabitEthernet0/0.100

10.0.22.0/24    redistributed

     [2] via 192.168.21.1,

10.0.23.0/24    redistributed

     [2] via 192.168.21.1,

10.0.24.0/24    redistributed

     [2] via 192.168.21.1,

172.16.0.0/16    auto-summary

172.16.1.240/28    directly connected, GigabitEthernet0/0.20

172.16.2.48/28    redistributed

     [2] via 192.168.21.1,

172.16.2.112/28    redistributed

     [2] via 192.168.21.1,

172.16.2.192/28    redistributed

     [2] via 192.168.21.1,

192.168.20.0/24    auto-summary

192.168.20.1/32    redistributed

     [2] via 0.0.0.0,

192.168.20.2/32    redistributed

     [2] via 192.168.21.1,

192.168.20.3/32    redistributed

     [2] via 192.168.21.1,

192.168.20.4/32    redistributed

     [2] via 192.168.21.1,

192.168.21.0/24    auto-summary

192.168.21.0/24    directly connected, GigabitEthernet0/0.20

192.168.22.0/24    auto-summary

192.168.22.0/24    redistributed

     [2] via 192.168.21.1,

192.168.23.0/24    auto-summary

192.168.23.0/24    redistributed

     [2] via 192.168.21.1,

192.168.24.0/24    auto-summary

192.168.24.0/24    redistributed

     [2] via 192.168.21.1,

----------------

deb ip rip

-----------------

(this series just repeats every 30 sec)

Mar  8 12:49:00.644 EST: RIP: sending v2 update to 224.0.0.9 via GigabitEthernet0/0.20 (192.168.21.254)

Mar  8 12:49:00.644 EST: RIP: build update entries

Mar  8 12:49:00.644 EST:        10.0.21.0/24 via 0.0.0.0, metric 2, tag 0

Mar  8 12:49:00.644 EST:        10.0.21.253/32 via 0.0.0.0, metric 1, tag 0

Mar  8 12:49:00.644 EST:        192.168.20.1/32 via 0.0.0.0, metric 2, tag 0

Mar  8 12:49:00.644 EST: RIP: sending v2 update to 192.168.21.10 via GigabitEthernet0/0.20 (192.168.21.254)

Mar  8 12:49:00.644 EST: RIP: build update entries

Mar  8 12:49:00.644 EST:        10.0.21.0/24 via 0.0.0.0, metric 2, tag 0

Mar  8 12:49:00.644 EST:        10.0.21.253/32 via 0.0.0.0, metric 1, tag 0

Mar  8 12:49:00.644 EST:        10.0.22.0/24 via 192.168.21.1, metric 2, tag 0

Mar  8 12:49:00.644 EST:        10.0.23.0/24 via 192.168.21.1, metric 2, tag 0

Mar  8 12:49:00.644 EST:        10.0.24.0/24 via 192.168.21.1, metric 2, tag 0

Mar  8 12:49:00.644 EST:        172.16.2.48/28 via 192.168.21.1, metric 2, tag 0

Mar  8 12:49:00.644 EST:        172.16.2.112/28 via 192.168.21.1, metric 2, tag 0

Mar  8 12:49:00.644 EST:        172.16.2.192/28 via 192.168.21.1, metric 2, tag 0

Mar  8 12:49:00.644 EST:        192.168.20.1/32 via 0.0.0.0, metric 2, tag 0

Mar  8 12:49:00.644 EST:        192.168.20.2/32 via 192.168.21.1, metric 2, tag 0

Mar  8 12:49:00.644 EST:        192.168.20.3/32 via 192.168.21.1, metric 2, tag 0

Mar  8 12:49:00.644 EST:        192.168.20.4/32 via 192.168.21.1, metric 2, tag 0

Mar  8 12:49:00.644 EST:        192.168.22.0/24 via 192.168.21.1, metric 2, tag 0

Mar  8 12:49:00.644 EST:        192.168.23.0/24 via 192.168.21.1, metric 2, tag 0

Mar  8 12:49:00.644 EST:        192.168.24.0/24 via 192.168.21.1, metric 2, tag 0

Thanks for providing the debug! The debug ip rip confirms what you are seeing in Wireshark. I would have expected the the two types of updates to be the same! We can see what routes would advertised by looking at the rip database. So what's going on?

This is what we have left

- something in the config that you have shared. Can I see the whole config.

- a bug. I can try in GNS3 for you based on the above using 12.4T code. We can look in the bug database based on the software release..

However at the moment you do have a work around i.e. unicast.

Sent from Cisco Technical Support iPad App

Here's the important parts of the config.  I've hacked out a LOT of VoIP settings that should have no bearing on the basic routing.

!

!

no ipv6 cef

no ip source-route

ip cef

!

!

!

!

interface Loopback1

ip address 192.168.20.1 255.255.255.255

!

interface GigabitEthernet0/0

no ip address

duplex auto

speed auto

!

interface GigabitEthernet0/0.20

encapsulation dot1Q 20

ip address 172.16.1.245 255.255.255.240 secondary

ip address 192.168.21.254 255.255.255.0

!

interface GigabitEthernet0/0.100

encapsulation dot1Q 100

ip address 10.0.21.254 255.255.255.0

!

!

router eigrp 1001

default-metric 10000 100 255 1 1500

network 0.0.0.0

network 10.0.0.0

network 172.16.1.240 0.0.0.15

network 192.168.20.0

network 192.168.21.0

redistribute static

passive-interface GigabitEthernet0/0.100

!

router rip

version 2

redistribute static route-map NODFGW

redistribute eigrp 1001 metric 2

passive-interface GigabitEthernet0/0.20

passive-interface GigabitEthernet0/0.100

passive-interface ISM0/0

network 192.168.21.0

neighbor 192.168.21.10

no auto-summary

!

ip forward-protocol nd

!

!

ip route 0.0.0.0 0.0.0.0 192.168.21.10

!

logging esm config

access-list 13 deny   0.0.0.0

access-list 13 permit any

!

!

!

!

route-map NODFGW permit 100

match ip address 13

!

!

control-plane

!

Yes, I have the workaround, which I was using from the start.  Since the RIP updates are OneWay, and to only ONE other router...it's the quietest solution.  This bug ony reared up after I found a RIP bug in the firewall, and turned ON the multicast updates to see the RIP updates.

WHY me?  I find TWO RIP bugs in TWO different Cisco boxes at the same time?

Review Cisco Networking products for a $25 gift card