RIP route advertised through WAN link not populating on LAN

[anthony.marsh]

Our NY site has added a route for a client 206.13.128.0/17 which is advertised to us over our T1 multilink and is seen in the routing table.

However, it's not being populated to our Core routers.

Core routers send V1 and receive V1 & 2

Edge routers send and receive V2

Did a debug on RIP and saw the advertised route on both edge routers, so I cannot understand why it's not forwarding the route to Core router.

Jun 2 10:12:15 EST: 206.13.128.0/17 via 0.0.0.0 in 5 hops

Show ip route 206.13.128.0 displays the following

ny-tortr01#sh ip route 206.13.128.0

Routing entry for 206.13.128.0/17, supernet

Known via "rip", distance 120, metric 1

Redistributing via rip

Last update from 192.168.13.29 on Multilink1, 00:00:09 ago

Routing Descriptor Blocks:

* 192.168.13.29, from 192.168.13.29, 00:00:09 ago, via Multilink1

Route metric is 1, traffic share count is 1

I don't understand why this one route isn't being advertised to the LAN with the other routes from the edge router, can someone share some insight please!

[thisisshanky]

Is version 2 command enabled under the RIP process of the both core and edge routers ?

[anthony.marsh]

Version 1 is enabled on both by default, but the Multilink interface is sending and receiving V2.

As listed below!

Edge routers

===============

Default version control: send version 1, receive any version

Interface Send Recv Triggered RIP Key-chain

Multilink1 2 2

Automatic network summarization is not in effect

Core routers

================

Default version control: send version 1, receive any version

Interface Send Recv Triggered RIP Key-chain

Fa0/0 1 1 2

[Richard Burts]

Anthony

I am not positive but I believe that this section quoted from FRC 2453 may explain the behavior that you are seeing:

On an interface where a RIP-1 router may hear and operate on the information in a RIP-2 routing entry the following rules apply: ... supernet routes (routes with a netmask less specific than the"natural" network mask) must not be advertised where they could be misinterpreted by RIP-1 routers.

HTH

Rick

[anthony.marsh]

Thanks very much for pointing this out to me, the RFC was actually correct. Once redistributing the route in its natural network mask, the problem was solved!

Thanks again.