cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1227
Views
5
Helpful
13
Replies

RIP V2 (send) updates missing at CE

ramakccie
Level 1
Level 1

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.

13 Replies 13

Jerry Ye
Cisco Employee
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

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.

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

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.

Hi Rama,

Configuring this will not result RIP to reset.

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

Regards,

jerry

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

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

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: