Hi!

I´m configuring a mikrotik router to receive the routes for VoIP using RIP. This is how they configure their routers they deliver to subscribers.I set it up in v2 passive, as they do, on the interface for that service, and I see that I receive the RIP routes correctly, but they are not being added to the mikrotik router.

I captured traffic and I see that they sent the routes, but they don´t fill the next hop.

User Datagram Protocol, Src Port: 520, Dst Port: 520
Routing Information Protocol
Command: Response (2)
Version: RIPv2 (2)
IP Address: 10.31.255.128, Metric: 3
Address Family: IP (2)
Route Tag: 0
IP Address: 10.31.255.128
Netmask: 255.255.255.224
Next Hop: 0.0.0.0
Metric: 3

Is the traffic they are not sending correct? is there any way to tell mikrotik to use the source ip address of the packet to assume the next hop in case of missing next hop?

Thanks!

JL

Routers send RIP updates with a next hop of 0.0.0.0 to tell the neighbour to use the source address of the update packet as the next hop. The only time it is not set to 0.0.0.0 is when the advertising router knows of a closer router to the destination on the same subnet.

Hi

Thanks for the answer, then I'd like to know why the router is not "learning/installing" the routes provided? I see that at IP level, the src addres is correct address for the router and the dst address is the multicast group for RIPv2 224.0.0.9.

Thanks in advance

For ROS to install a RIP route via multicast, the source address of the RIP packets need to be inside the subnet of the interface they are received on.
e.g.
Interface: 192.168.1.0/24
from 192.168.1.5: 10.1.2.0/255.255.255.0 will install the route
but
from 192.168.2.5: 10.1.2.0/255.255.255.0 will not work.

Hi
Thanks, but that is the case, the interface receiving the RIP is has address:
IP:10.29.42.2/19
Network: 10.29.32.0

The source of the RIP packages is:
Internet Protocol Version 4, Src: 10.29.32.1, Dst: 224.0.0.9

So the first ip of the range. Any reason why this should not be working?

Have you tried disabling the passive setting? I think passive instructs RIP not to learn routes....

Hi

Not an expert in dynamic routing, but, active means it will actively query the neighbors configured by requesting routes, instead of listening only. I activated it and saw for the first time requests being sent by the router.

Anyone knows why the router in not learning the RIP routes?

JL

Did you add a network to RIP which covers the interface where you want to receive RIP routes?
(I'm actually a greenhorn with RIP, but these are the things I would try if messing around with it)

Hi

Thanks, but I´m afraid those are the routes that would get sent to your rip neighbours. I´ve already tried to add the remote router as a known neighbour, but no luck neither, ignores the routes receives.

Anyone? If not, should I open a bug or something?

I've gotten RIP working on RouterOS before and don't recall it being anything difficult at all. It "just worked" - so I'm about to set it up in GNS3 just to see if anything is difficult or unusual...

Thanks, but I´m afraid those are the routes that would get sent to your rip neighbours. I´ve already tried to add the remote router as a known neighbour, but no luck neither, ignores the routes receives.

Okay - after playing around with RIP a bit, I can say with a little more confidence that I think your understanding of RIP is incorrect. (and I had one detail wrong as well)

My mistake was thinking that passive = "advertise-only" (similar to OSPF). It actually means "listen only"

The network statement is required in order to activate an interface with RIP. It works like OSPF's network list, NOT like BGP's network list.
In other words, interfaces whose IP addresses fall within a network=x.x.x.x/m range will become active in RIP. Just because you're seeing RIP packets in the packet captures doesn't mean that your router is actually passing them up to the RIP process. Until you activate an interface by issuing a network=x.x.x.x/m statement to cover the interface's IP address, it is NOT an active RIP interface. The interfaces list is simply a place where you set the RIP characteristics of activated interfaces.

In fact, in my lab, I only had to issue one command to start learning RIP routes from the Cisco router:
/routing rip network add network=10.1.3.0/24
(the interface between my Cisco and Mikrotik routers was 10.1.3.x/24)
As soon as I did this, the Mikrotik learned all routes from the Cisco.
Furthermore, as soon as I added other interfaces to the Mikrotik's RIP database, the Mikrotik advertised those other routes to the Cisco: as soon as I added network=10.10.10.0/24, the Cisco received 10.10.10.2/32 from the Mikrotik.
When I added the passive=yes interface command, the Mikrotik stopped sending routes to the Cisco, but continued to learn routes FROM the Cisco.

So passive means: listen for routes, but don't send anything (in addition to any other behaviors this may influence)
And the network statement is required to activate interfaces in the RIP protocol.

Final Mikrotik config:

Hi

Thank you very much for the detailed explanation. Indeed I manually added the network of the vlan where the packets are being recived to the rip networks and it started working.
In this(my) setup there´s an extra layer of complexity, the ip address of that interface (and the network), is obtained via DHCP, I see no option to add the network received to the rip in the DHCP client options.
I assume the way forward is to have an script on the DHCP client?

JL

I would say it's not 'normal' to have a DHCP client add itself to a dynamic routing protocol. Though as you know which subnet the router will be connecting to (even if the address is by DHCP) then you can add a manual entry to the RIP config for that subnet. When the router gets its address from DHCP, RIP should then start woking automatically. Otherwise it may be your only option to use a script.

All IGPs use the principle of turning on the protocol on specific interfaces by using a matching network statement. In this way, you can have different protocols running on different interfaces without them bleeding across each other (unless you redistribute). For protocols that must first from neighbours (OSPF, ISIS, EIGRP) the passive option tells the router to enable the protocol on the matching interface (so that it will advertise the connected subnet), but not to form a neighbour on that port. As RIP does not form a neighbour relationship, the passive keyword is indeed different. It allows a RIP enabled interface to receive updates but it does not send them on that interface.

Hi

Well, this is how the ISP sets it up for Spain . For voice VLAN they assign the IP via DHCP, and then they publish the routes via RIPv2 to their sip server (which has been advertised via the DHCP option).

But I am afraid you were not accurate in one point, the router does not accept the packages because he hasn't join to the the multicast address for RIP v2. 224.0.0.9, you can add any route to RIP, and then it will work, I added 0.0.0.0/0, and then he reports his membership via IGMPv3 to that multicast address, all the subsequent packets to that address is processed correctly (you can try). Also about passive is more about the comms pattern,even in passive if you add a neighbour it will constantly send the local address, but it does not behave in a query-reply pattern (that is active). It's more like a periodic timer when passive.

Issue comes now how movistar routers behave. If I start the interface and I don't subscribe to that address the RIP packages don't stop reaching, but after I subscribe, it stop sending them after few minutes (WTF??).

Interesting.

JL

If it's just going to be the one interface, and you're only expected to receive routes (not transmit them) then it's going to be really safe to just do this:
interface=all passive=yes listen=v2
network=0.0.0.0/0

done.

Of course your router will now listen for RIP on all interfaces, but you could easily augment this with an input chain filter rule which blocks RIP on in-interface= !wan

That would allow for any IP address learned dynamically, w/o scripting, w/o sending routes to the ISP, and w/o learning anything on any other interface.

But I am afraid you were not accurate in one point, the router does not accept the packages because he hasn't join to the the multicast address for RIP v2. 224.0.0.9, you can add any route to RIP, and then it will work, I added 0.0.0.0/0, and then he reports his membership via IGMPv3 to that multicast address, all the subsequent packets to that address is processed correctly (you can try). Also about passive is more about the comms pattern,even in passive if you add a neighbour it will constantly send the local address, but it does not behave in a query-reply pattern (that is active). It's more like a periodic timer when passive.

I would say that the IGMP join is simply the evidence that the Mikrotik is now listening for RIP. If it's not listening, then it's not going to join the group.

I managed to get it working, but had to do a workaround.

Add route 0.0.0.0/0 so it listens to the mcast ip.
Deny all IGMP traffic outgoing from that interface (so the other end does not sees me and stops sending packets)

Regards!

I think you've finally cracked it, but reading your previous post I just wanted to make sure you were clear on why it started working.

When you add the network statement network=0.0.0.0/0, it doesn't simply enable the multicast group. What you are telling the router to do is to find all interfaces that match the network statement - in this case every IP matches - and enable RIP on those interfaces. Enabling RIP automatically causes those interfaces to join the multicast group 224.0.0.9. Let me put this another way.

Lets say you have two interfaces on the router with IPs eth1=10.1.1.1/24 and eth2=172.16.1.1/24. If I enable RIP and use network=10.0.0.0/8, what happens is eth1 joins the RIP multicast group and starts sending RIP updates out of that interface. However, eth2 does not join the multicast group, because it's IP address was not matched by the network statement. No RIP updates are sent nor received on eth2.

Denying IGMP won't have much of an effect because RIP routers will send updates to the multicast group, and unless you are using IGMP snooping on intermediate switches, will be broadcasted to all connected routers. Denying IGMP will not stop the router interface from listening on the multicast address. If you want to stop the other end from receiving RIP updates from your router, place it into passive mode (listen but don't send). If blocking outbound IGMP caused this behaviour, you wouldn't be able to receive routes.

Thanks for clearing up my explanation, Airbanduk.

It's threads like this which lead to my writing the haiku in my signature line.

Hi

In this case denying IGMP is crucial due to movistar implementation. Once you sent the memebership report, they will stop sending the routes to my interface, which make the routes expire and never work again. By deniying the outbound traffic, the rip engine does not realize it has not reached the destination and the ISP router keeps on sending the RIP routes, so the mikrotik learns them.

JL

The network statement is required in order to activate an interface with RIP. It works like OSPF's network list, NOT like BGP's network list.
In other words, interfaces whose IP addresses fall within a network=x.x.x.x/m range will become active in RIP. Just because you're seeing RIP packets in the packet captures doesn't mean that your router is actually passing them up to the RIP process. Until you activate an interface by issuing a network=x.x.x.x/m statement to cover the interface's IP address, it is NOT an active RIP interface. The interfaces list is simply a place where you set the RIP characteristics of activated interfaces.

Or if you declare the peer in neighbors. This sends unicast instead of multicast and you can block multicast on all other interfaces:

[*************] > /routing rip network print
Flags: X - disabled
# NETWORK
0 10.61.1.128/25
[*************] > /routing rip neighbor print
Flags: X - disabled
# ADDRESS
0 10.250.1.10
[*************] > /routing rip interface print
Flags: I - invalid, X - disabled, P - passive
# INTERFACE SEND RECEIVE AUTHENTICATION AUTHENTICATION-KEY
0 P all v1-2 v1-2 none
1 OVPN v2 v2 none
[*************] > /ip address print
Flags: X - disabled, I - invalid, D - dynamic
# ADDRESS NETWORK INTERFACE
0 10.61.1.161/25 10.61.1.128 LAN
7 D 10.91.61.1/32 10.250.1.10 OVPN