RIP V2 (send) updates missing at CE

Unanswered Question
Jul 27th, 2009
User Badges:

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.



  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
Jerry Ye Mon, 07/27/2009 - 06:12
User Badges:
  • Cisco Employee,

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

ramakccie Wed, 07/29/2009 - 04:26
User Badges:

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.



Jerry Ye Wed, 07/29/2009 - 05:02
User Badges:
  • Cisco Employee,

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

ramakccie Thu, 07/30/2009 - 02:46
User Badges:

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.

Jerry Ye Thu, 07/30/2009 - 05:17
User Badges:
  • Cisco Employee,

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

ramakccie Mon, 08/03/2009 - 04:32
User Badges:

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.


Jerry Ye Mon, 08/03/2009 - 13:09
User Badges:
  • Cisco Employee,

Hi Rama,


Configuring this will not result RIP to reset.


Also, from your description, looks like the RIP DB stuck somehow.


Regards,

jerry

Peter Paluch Mon, 08/03/2009 - 13:25
User Badges:
  • Cisco Employee,

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


Jerry Ye Mon, 08/03/2009 - 13:58
User Badges:
  • Cisco Employee,

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

Peter Paluch Wed, 07/29/2009 - 04:31
User Badges:
  • Cisco Employee,

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


Jerry Ye Wed, 07/29/2009 - 05:00
User Badges:
  • Cisco Employee,

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

Peter Paluch Wed, 07/29/2009 - 05:22
User Badges:
  • Cisco Employee,

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


Jerry Ye Wed, 07/29/2009 - 13:59
User Badges:
  • Cisco Employee,

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

Actions

This Discussion