Hello,
We are running RIP v2 between the Customer Edge Router and PE.
PE advertises default information to the CE and CE advertises only two of its connected segments to the PE.
We are happening to see a typical issue, where CE not sending its v2 updates to the PE, whereas it receives the updates from PE.
Post clearing the routing table at CE, we see that the CE sending the RIP update.
CE config:
!
router rip
version 2
redistribute connected route-map CONNECTED (We filter only 2 of the Customer Segments in the Route-map)
network 192.168.254.0
neighbor 192.168.254.181
no auto-summary
!
PE config:
!
router rip
version 2
no auto-summary
!
address-family ipv4 vrf 1008-CustA-Mesh
network 192.168.254.0
neighbor 192.168.254.182
default-information originate
no auto-summary
version 2
exit-address-family
!
PE IOS: flash:c3825-spservicesk9-mz.123-14.T5.bin
CE IOS: flash:c1700-advsecurityk9-mz.123-11.T2.bin
Attached is the debug logs collected at CE.
Regards,
Rama.
Hi,
Without seeing other part of your configuration, I am not sure how many network will your network 192.168.254.0 cover. However, I do see a problem with your redistribution configuration
redistribute connected route-map CONNECTED
where you did not specified the metric for the redistributed routes (connected).
redistribute connected route-map CONNECTED metric 1
HTH,
jerry
Hi Jerry,
Pls find the requested configurations.
!
route-map CONNECTED permit 10
match ip address RIPConnected
!
!
ip access-list extended RIPConnected
permit ip host 172.16.4.9 any
permit ip 192.168.34.32 0.0.0.7 any
!
Interface IP-Address OK? Method Status Protocol
FastEthernet0/0 unassigned YES NVRAM up up
FastEthernet0/0.1 10.12.0.1 YES NVRAM up up
FastEthernet0/0.2 192.168.34.33 YES NVRAM up up
FastEthernet0/0.290 192.168.254.82 YES NVRAM up up
BRI1/0 172.16.5.30 YES TFTP up up
Loopback1 172.16.4.9 YES NVRAM up up
Loopback2 172.16.5.30 YES manual up up
Thanks,
Rama.
Hi Rama,
I see you are using extended ACL to match the connected interface's IP address and redistribute them into RIP.
Personally, I will do the following command instead of the ACL
route-map CONNECTED perm 10
match interface FastEthernet0/0.2 Loopback1
Try this is and post the output of sh ip rip database.
HTH,
jerry
Hi Jerry,
I understand that by doing this we avoid the L3 lookup and directly resolve for L2. But could you clarify if configuring this will reset RIP.
Also for your information, 5 different locations of the same Customer with the similar Configuration, has experienced the same sort of problem. The problem resolved post clearing the ip routes for all these locations.
But we have not found any re-occurrence of the same problem till date in any of these 5 locations.
Thanks,
Rama.
Rama, Jerry,
I have had a series of incidents with the RIP as implemented in Cisco IOS. The RIP seems to be sadly undermaintained and there are several problems or outright bugs that I know about.
My problems with RIP were most often concerned with a single issue - a RIP router configured with the command default-information originate simply stopped advertising the default route or never started to advertise it. The workaround about this bug is quite simple, really - just using the clear ip route * in the privileged EXEC mode. Debugging has shown that this command also causes the RIP database to reinitialize. While we have not identified the precise cause of the problem, we suspect some kind of a race condition to be involved in this.
I would not be surprised if the problem here is another one of those present in the RIP implementation.
Best regards,
Peter
Hi Peter and Rama,
I agree with Peter on this piece. As a general practice, whenever I modified the routing protocol (redis, distribute-list, etc.), I will also do clear ip route * to get the new configuration to kick in.
Regards,
jerry
Hello Jerry,
Just a small remark: Redistributing static or connected routes into a distance vector protocol does not require setting the seed metric - although it is never wrong to set it. However, in RIP, if you redistribute static or directly connected networks, they are automatically redistributed with the metric 1.
Best regards,
Peter
Hi Peter,
Thanks for the reminder. As from the experience, redistributing routes into distance vector protocol (RIP and EIGRP), if metric wasn't defined and there isn't any default metric configured in the routing process, sometime that doens't work as expected.
Regards,
jerry
Hey Jerry,
You're welcome. As I remember it, redistributing networks from other routing protocols into distance vector protocols requires setting a seed metric, otherwise an infinite seed metric will be used and as a result, these networks will not be advertised (or immediately advertised as unreachable, which is basically the same effect here). However, redistributing directly connected or static routes does not make problems, as they actually do not have a metric in the routing table. Just a mnemotechnical way to remember this detail... :)
Best regards,
Peter