Hi there
I understand that two ways optional to send RIP info
1) multicast (what now is operative)
2) direct transfer
The multicast require that both interfaces AMPRGW and the ham gateway will have same netmask (in our case /8)
is it the same with the direct transmit ?
If yes why the multicast way was chosen ? what is the benefit ?
Thanks for any info on the subject
Ronen - 4Z4ZQ
Ronen,
I'm not sure the concerns about multicast, and I'm not sure about "direct transfer". That description sound like FTP of Encap. If you are in the Portal, the machine receives and processes the exact same packets. The issue for me is HOW the Kernel processes the packets (and others).
In your case, it seems you can't receive the RIP44 packets if the interface isn't on the same subnet. That seems like a setting limitation of the Router OS. On my machine, assigning a 44/8 to an interface on my device is invalid for proper operation of my subnet. I didn't have your exact issue.
On my device the following happened:
- In multicast mode, ampr-ripd and/or rip44d listen on udp/520 like a normal server, the packets must come through tunl0 first - In raw mode, ampr-ripd listens on IPENCAP (IP Protocol No. 4) and 'inspects' packets, seeking ones from 44.0.0.1 520/udp to 224.0.0.9 520/udp
I would assume using -r argument would turn on this mode, and "multicast" in the way you describe MIGHT be disabled. This is not a concern for me, in both modes, the route is made. I have various issues in raw mode, and simply prefer to have my device listen on the LAN side of my tunnel. Multicast mode solves all my issues experienced in raw mode.
73,
- Lynwood KB3VWG
All
I wasnt clear enough
Im referring to Rip transfer using MikroTik ... Not a Linux system
I add part of Marius Explain why the /8 needed in multicast but is it same with direct transfer ?
if not why not using this way ?
enclosed is Marius explain pay attention to the Unicast part of the explain
"Now for classic RIP, there are 2 ways to receive routes. One way is to have unicast transmissions, where the RIP source sends the data from its own IP to a specific destination IP. The second way is to have multicasts, where the source sends its routes to IP 224.0.0.9. This is what ampr-gw is using.
Now, for a RIP multicast to be accepted, the local IP AND the source IP have to be in the same subnet, otherwise multicasts are dropped. So, for any 44 address to be in the same subnet with 44.0.0.1 (the multicast source), the interface has to use 44.x.x.x/8 (meaning subnet 44.0.0.0-44.255.255.255). Otherwise, no RIP data is received by the mikrotik's ucsd tunnel interface."
________________________________
I'm not sure the concerns about multicast, and I'm not sure about "direct transfer".
- Lynwood KB3VWG
_________________________________________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
Ronen,
using MikroTik
You cannot use RIPv2 packaged by MicroTik, you must run RIP44.
**
Now for classic RIP, there are 2 ways to receive routes.
*AMPRNet does NOT run classic RIP.*
As Marius and I both noted, that's a limitation of Microtik and the use of RIPv2 instead of RIP44. rip44d and ampr-ripd don't care about the subnet mask of the source and destination IP addresses.
That seems like a setting limitation of the Router OS.
But these restrictions only apply to using a standard RIP client like quagga or RouterOS RIP agent.
You should probably use a RIP44-compatiable routing daemon such as rip44d or ampr-ripd.
73,
- Lynwood KB3VWG
So, for any 44 address to be in the same subnet with 44.0.0.1 (the multicast source), the interface has to use 44.x.x.x/8 (meaning subnet 44.0.0.0-44.255.255.255). Otherwise, no RIP data is received by the mikrotik's ucsd tunnel interface."
As Marius and I both noted, that's a limitation of Microtik and the > use of RIPv2 instead of RIP44. rip44d and ampr-ripd don't care about the subnet mask of the source and destination IP addresses.
That's actually a limitation on how multicast works. In usual circumstances, a router does not listen to multicasts not originating from the subnet its interface is connected to. Ad it applies to broadcasts, too, with some exceptions like DHCP servers. And this is a IMHO normal behavior. In this way, one can share a physical connection for multiple subnets without interference between them, and avoid reception of unwanted data that could interfere with proper network functionalities.
Regarding the mandatory use of 44net clients: Any RIPv2 client can receive the ampr multicasts which do conform to the RIPv2 standard (except IGMP subscription for 224.0.0.9, which is no problem). The issue is that a standard RIPv2 client will interpret those routes as all needing to go via 44.0.0.1 (the originator of the RIP packet). So the RIP multicasts are standard RIPv2, we just want to use the data in a different way, and here the daemons and the router scripts come into play.
So, for ANY RIPv2 capable router the following apply: If you can receive RIPv2 and put them in a separate VRF/routing table out of the way of the main routing table, you can use those routes to construct by scripting a list of tunnel interfaces and correct routes via thos interfaces and place them into the main routing table, thus having a working full mesh on your router. So this should be the starting point for possible Cisco IOS/ Juniper JunOs/Ubiquiti EdgeOS implementations.
Marius, YO2LOJ
Not really :-)
First, standard RIPv2 protocol uses multicast as a reserved target address (224.0.0.9). This allows a single RIP message to reach all interested parties on that network. A second option is to have something called non broadcasting neighbors. These ones can not be reached via multicasts, and needs to be directly addressed using an unicast target address.
Second, there is no need to have the same netmask on both networks. It is only needed to have the RIPv2 sender IP in our own subnet.
e.g. if the sender is 44.0.0.1, for the 44.0.1.1 host, a netmask of /23 should be OK. But the use of /8 will cover all configurations.
But these restrictions only apply to using a standard RIP client like quagga or RouterOS RIP agent. Ampr-ripd and amprd will work happily with any netmask.
Marius, YO2LOJ
(Please trim inclusions from previous messages) _______________________________________________ Hi there
I understand that two ways optional to send RIP info
multicast (what now is operative)
direct transfer
The multicast require that both interfaces AMPRGW and the ham gateway will have same netmask (in our case /8)
is it the same with the direct transmit ?
If yes why the multicast way was chosen ? what is the benefit ?
Thanks for any info on the subject
Ronen - 4Z4ZQ
-
lleachii＠aol.com -
Marius Petrescu -
marius＠yo2loj.ro
-
R P