RIP Problems on 3120 and 3448

[buckaroo]

I'm building a network with about 20 3120s and a couple of 3448s. Each router is connected on the "public" interface to a Charter Layer 2 WAN port, and the "private" interface is connected to the branch's local LAN. The WAN network has its own subnet, 192.168.250/24, and each router's public interface has an address on that network. Each branch LAN private interface has its own 192.168.x/24 subnet. Firewall is disabled on all of these routers.

If I set up routes statically, everything works fine. However, with RIPv1 enabled, no routers are getting routes from any other. If I do "debug ip rip", I see the following:

2013.08.29 10:00:39 IP.RIP EVENTS RIP: sending v1 update to 192.168.032.255 via vlan 1 (192.168.032.001)

2013.08.29 10:00:39 IP.RIP EVENTS RIP: v1 update suppressed.

I'm assuming that "v1 update suppressed" is the problem, but I can't seem to find out what's suppressing it. I have no interfaces listed in the web interface as passive.

My config:

!

!

! ADTRAN OS version 18.01.01.00.E

! Boot ROM version 17.01.01.00

! Platform: NetVanta 3120, part number 1700601G2

! Serial number LBADTN1********

!

!

hostname "b32-router"

enable password **********

!

clock timezone -6-Central-Time

!

ip subnet-zero

ip classless

ip default-gateway 192.168.250.16 <-- Corporate HQ and internet drain

ip routing

ip domain-name "*******.org"

ip domain-proxy

ip name-server ********** ********

!

!

no auto-config

!

event-history on

no logging forwarding

logging forwarding priority-level info

no logging email

!

no service password-encryption

!

username "admin" password "*********"

!

!

no ip firewall alg msn

no ip firewall alg mszone

no ip firewall alg h323

!

!

no dot11ap access-point-control

!

!

vlan 1

  name "Default"

!

!

interface eth 0/1

  description Charter WAN

  ip address  192.168.250.32  255.255.255.0

  no shutdown

!

!

interface switchport 0/1

  no shutdown

!

interface switchport 0/2

  no shutdown

!

interface switchport 0/3

  no shutdown

!

interface switchport 0/4

  no shutdown

!

!

!

interface vlan 1

  description B32 LAN

  ip address  192.168.32.1  255.255.255.0

  no shutdown

!

!

router rip

  network 192.168.32.0 255.255.255.0

!

!

ip access-list standard wizard-ics

  remark Internet Connection Sharing

  permit any

!

!

ip access-list extended self

  remark Traffic to UNIT

  permit ip any  any     log

!

!

!

ip policy-class Private

  allow list self self

  nat source list wizard-ics interface eth 0/1 overload

!

ip policy-class Public

  ! Implicit discard

!

!

ip route 0.0.0.0 0.0.0.0 192.168.250.16

!

no tftp server

no tftp server overwrite

ip http server

ip http secure-server

ip snmp agent

no ip ftp server

ip ftp server default-filesystem flash

no ip scp server

no ip sntp server

!

!

snmp-server contact "*********"

snmp-server contact email "*********"

snmp-server community ******** RO

!

!

!

!

ip sip udp 5060

ip sip tcp 5060

!

!

line con 0

  no login

!

line telnet 0 4

  login local-userlist

  password password

  no shutdown

line ssh 0 4

  login local-userlist

  no shutdown

!

!

ntp server 192.168.0.1 version 3

!

!

end

[buckaroo]

I may have answered my own question. Apparently AOS ignores the "redistribute connected" checkbox. If I manually add the both subnets, the local LAN and the Charter WAN, to the list of routes to be advertized, it works perfectly. Even those are listed as "connected" in the route table, it ignores them with "redistribute connected".

[Anonymous · Accepted solution]

:

Thank you for asking this question in the support community.  I tried to recreate the problem you described in the web interface on current firmware, but was unable to.  When I checked the "Redistribute Connected" checkbox and then clicked the "Apply" button, it added it to the configuration.  If for some reason, you are unable to do this, then I suggest you add the command in the command line interface (CLI), or upgrade the firmware of the unit.

Furthermore, based on what you've said and your original problem.  You will need to have the WAN network enabled in the configuration.  I think your RIP configuration should look like the following (the "redistribute connected" command is optional):

!

router rip

  network 192.168.32.0 255.255.255.0

  network 192.168.250.0 255.255.255.0

!

Also, have you considered using RIPv2 instead of RIPv1?  There are distinct advantages of version two over version one.  Please do not hesitate to reply to this post with any additional information or questions.  I will be happy to help in any way I can.

Levi

[jayh]

Your WAN interface isn't participating in RIP.

Add:

router rip

  network 192.168.32.0 255.255.255.0

  network 192.168.250.0 255.255.255.0

And, unless you have LAN devices that are participating in RIP, also add

  passive-interface vlan 1

to cut down on chatter and possible rogue advertisements.

In my opinion, RIP v1 has outlived its usefulness.  At a minimum go to RIP v2, better yet OSPF.

[jayh · Accepted solution]

buckaroo wrote:

I may have answered my own question. Apparently AOS ignores the "redistribute connected" checkbox. If I manually add the both subnets, the local LAN and the Charter WAN, to the list of routes to be advertized, it works perfectly. Even those are listed as "connected" in the route table, it ignores them with "redistribute connected".

The problem isn't redistribute connected, it's that the Charter WAN subnet isn't identified with a network statement.  As the WAN is where you want to advertise your LAN, it needs the network statement to participate in RIP.

You could do as I suggested, have both subnets participate in RIP and make the LAN passive, or just put the Charter WAN in RIP and redistribute connected.

In any case, the rest of the WAN link needs to learn about your local routes, so the WAN needs the RIP network statement.  The LAN doesn't need it if you redistribute the connected LAN.  There are subtle differences in how a redistributed network is treated vs. a RIP native subnet but either should work in your case.

[Anonymous]

-

I went ahead and flagged the "Correct Answer" on this post to make it more visible and help other members of the community find solutions more easily. If you don't feel like the answer I marked was correct, feel free to come back to this post to unmark it and select another in its place with the applicable buttons.  If you have any additional information on this that others may benefit from, please come back to this post to provide an update.  If you still need assistance, we would be more than happy to continue working with you on this - just let us know in a reply.

Thanks,

Noor