07-27-2009 05:44 AM - edited 03-04-2019 05:33 AM
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.
07-27-2009 06:12 AM
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
07-29-2009 04:26 AM
Hi Jerry,
There are 4 networks under this network 192.168.254.0.
Kindly let me know what kind of "show" outputs you want further.
Thanks & Regards,
Rama.
07-29-2009 05:02 AM
Hi Rama,
Can you post the show ip int brief, and the configuration of the route-map and access-list if there are any.
Regards,
jerry
07-30-2009 02:46 AM
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.
07-30-2009 05:17 AM
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
08-03-2009 04:32 AM
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.
08-03-2009 01:09 PM
Hi Rama,
Configuring this will not result RIP to reset.
Also, from your description, looks like the RIP DB stuck somehow.
Regards,
jerry
08-03-2009 01:25 PM
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
08-03-2009 01:58 PM
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
07-29-2009 04:31 AM
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
07-29-2009 05:00 AM
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
07-29-2009 05:22 AM
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
07-29-2009 01:59 PM
Hi Peter,
You are absolute right on this piece.
As a general practice, I usually put the metric along with the redistribution command, and it is not going to hurt. =)
Regards,
jerry
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