23 May
2017
23 May
'17
4:01 a.m.
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
23 May
23 May
5:40 a.m.
New subject: RIP transmission question
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
7:39 a.m.
New subject: RIP transmission question
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(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net
11:49 a.m.
New subject: RIP transmission question
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."
12:19 p.m.
New subject: RIP transmission question
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
5:42 a.m.
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
>
> 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
>
>
2742
days inactive
2742
days old
5 comments
4 participants
participants (4)
-
lleachii＠aol.com -
Marius Petrescu -
marius＠yo2loj.ro
-
R P