03-08-2012 06:12 AM - edited 03-04-2019 03:35 PM
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?
03-08-2012 06:26 AM
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?
03-08-2012 06:56 AM
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
03-08-2012 08:04 AM
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.
03-08-2012 09:04 AM
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
03-08-2012 09:56 AM
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
03-09-2012 02:15 PM
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
03-12-2012 05:55 AM
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?
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide