We have a MPLS network to interconnect our remote offices with our datacenters.
On the remote offices we use C1841 routers with ios c1841-broadband-mz.124-25d.bin.
The lan interface is a dot1q trunk with 3 subinterfaces (and so 3 subnets)
Recently we ran in to routing issues on 2 routers:
We use RIPv2 as routing protocol and redistribute the connected lan subnets.
(we keep a full routing table - no filtering).
When we have the problem, 1 or 2 LAN subnets are no longer advertised via RIP (although the subinterfaces stay up/up).
The other subnet is still advertised.
We have a routing table/rip database with around 260 routes.
To overcome the issue, we configured an inbound distribute-list to only accept the default route and some specific subnets.
Since then the issue is solved, but I would like to know if it is a limitation on the router or something else.
I've also done RIP debugging, but nothing exciting was shown...
herewith the config:
interface FastEthernet0/0 bandwidth 100000 no ip address speed 100 full-duplex ! interface FastEthernet0/0.11 encapsulation dot1Q 11 native ip address 10.72.52.1 255.255.254.0 ip helper-address 10.72.10.51 ip helper-address 10.72.16.51 ip directed-broadcast ! interface FastEthernet0/0.21 encapsulation dot1Q 21 ip address 10.73.52.1 255.255.254.0 ip helper-address 10.72.10.51 ip helper-address 10.72.16.51 ip directed-broadcast !
encapsulation dot1Q 31
ip address 10.73.54.1 255.255.254.0
router rip version 2 redistribute connected network 192.168.100.0 no auto-summary !
So the only change you made is an inbound filter to permit a default and a few more.
It could be split horizon where a few of the local connected subnets were learned on the interface accidentally and hence these were not advertised out, even though the subinterfaces were up. Just a possible theory.
sh ip rip database when the problem occured would help to further dig down.