I run JNOS 2.0i with Ubuntu Linux 12.04. I am set up to receive RIP
broadcasts and they are working fine. Along with the encapsulated RIP
broadcast is coming non encapsulated data and JNOS is responding Unreachable
Port Returned. Is this non encapsulated data something that I asked for in
AmperNet registration or does it just come along or have to come along with
the encap data?
Jerry, N0MR
Folks:
Apologies for the note, but I am trying to get in touch directly with Ronen
Pinchook 4Z4ZQ, who is a member here.
Ronen: do you mind contact me directly at assi(a)kiloxray.com regarding
amprnet business.
Thank folks, over and out.
Assi KK7KX/4X1KX
P.S: Brian, if you want to beat me over the head for this, you know where to
find me :)
I think I have found and fixed a problem which caused rip44d multicast
reception to mysteriously fail on some systems. The workaround is
present in rip44d version 1.4, which is available at:
https://raw.github.com/hessu/rip44d/master/rip44d
I just upgraded the Linux distribution on my gateway, and rip44d
stopped working. After some slight hair-pulling I figured it out. The
same thing will affect the C implementation, and doing the same
workaround will remove the need to use a raw socket instead of the
more optimal multicast socket.
Some distributions/kernels (some of the new ones, and maybe some old
ones too?) enable strict reverse path verification (rp_filter) by
default. Reverse Path filtering looks at the source IP address of
packets coming in on an interface, and checks that an outgoing packet
destined to that same address would be routed out on that same
interface according to your routing table.
That's a nice feature as such - it drops spoofed packets, which is
good for security. If someone on the Internet sends packets to you,
and fakes the source address to be one of your internal addresses, it
could save your day. Or, if a client/user on your network tries to
send packets to the Internet with a fake source address (typically his
computer is infected with a bot, and the bot is taking part in a DDOS
attack), rp_filter will drop those packets with invalid source
addresses.
However, it affects multicast packets too. Our RIP packets come in on
tunl0, with a source address of 44.0.0.1. Before your tunnel routing
table is populated with RIP, there is no route to 44.0.0.1 pointing to
tunl0. The RIP announcements do contain a route for 44.0.0.1, but we
need to have it there to be able to receive any RIP packets.
There are a couple of alternative workarounds to this:
1) Disable rp_filter on the tunl0 interface.
sudo sysctl net.ipv4.conf.tunl0.rp_filter=0
(and put net.ipv4.conf.tunl0.rp_filter=0 in /etc/sysctl.conf)
*or*
2) Set up a dummy route for 44.0.0.1/32 pointing to the tunl0
interface. It'll be replaced by the real one once the first RIP
packets come in.
I opted for option 2, rip44d 1.4 does that when starting up.
If you have an asymmetric routing setup, rp_filter might cause some
other surprises too. Good to keep it in mind.
- Hessu, OH7LZB
