27 Jul
2013
27 Jul
'13
5:25 p.m.
Is it possible to get the IPIP routes delivered by conventional routing
protocols (RIP, OSPF, etc) rather than running a custom daemon ?
Just curious.
-Neil
--
Neil Johnson -N0SFH
http://erudicon.com
27 Jul
27 Jul
7:49 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Is it possible to get the IPIP routes delivered by
conventional
routing protocols (RIP, OSPF, etc) rather than running a custom
daemon ?
Yes there is and there is some documentation here:
http://wiki.ampr.org/index.php/Rip44d
73 de Marc, LX1DUC
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJR9GqCAAoJEHFIN1T8ZA8vUQEP/3DzyRu8cLq/8RS+ZyEgzq7W
WFnojLehmNmfmK6288cmzib5QuLmP1Y5mmERTtU2gfvVBf3Fryj1uEtWhW4ta9YS
1Bj+VAgwXnsIf/hWWfvNrAPes9l31Nevfif0RqVFA4FoCP1T+7LEjnQXQD4W3dK5
AcK4hoT8yaCFT1FqbCsQQdron/cObsbwjVDK22fYDM8s6SouiXq2Xjk6HOFAJXix
0PCEkLK5lr9ouRwrSfj6A8Zrwcrr/iik0nmatfS/8qsFq33aa9Y3XTQIbjtYnG02
cLEB3+n0hrkTr51H+AB/wOX/P6tndJhWeXNWxsj+DLoUQcAZvlwAUZ24V4hEYZTV
P3b+c6//Y5KPM4GoLcz8XVAax/YpQhjFQKHGVAOsFveFzkKpOEBpVG0n4y+Xx8iU
MeKcb/pI13g+t7lOD+0Vzkgk56ih5vC7YJRdzxEeneCdDQgjKWaJGyHZYfxVh6mh
0Q1iX9oUXvlJ4ryqJCJTR76srguTrXx3/Hgn/DvSt5HDa83LAgIWlMWbqJgDcpkW
V9qUeZf/f7EjkBKjX/XxlyH6QtVrjUvpxsSF9Vf+XzFMtwLX3/JRh7ibkPIgv0NU
6qw7snD5zEMziVxn+gld+Kf6F0KEzmzJwkIbDkY72eKhUlItg6kFpTANlLqQQuHz
VUKhKQiOZD4uUpTQ2hfR
=LvLI
-----END PGP SIGNATURE-----
11:07 p.m.
On Sat, Jul 27, 2013 at 05:25:28PM -0500, Neil Johnson wrote:
Is it possible to get the IPIP routes delivered by
conventional routing
protocols (RIP, OSPF, etc) rather than running a custom daemon ?
Well, they are being delivered by RIP, but because it's supplying
tunnel routes over a tunnel, it has to be handled in a special way,
thus RIP44d. You don't want the tunnel routes to be seen by your
normal RIP listener because the routes aren't to local next-hop
addresses, they're to tunnel endpoints.
- Brian
28 Jul
28 Jul
1:54 a.m.
On Sat, Jul 27, 2013 at 9:07 PM, Brian Kantor <Brian(a)ucsd.edu> wrote:
(Please trim inclusions from previous messages)
_______________________________________________
On Sat, Jul 27, 2013 at 05:25:28PM -0500, Neil Johnson wrote:
Why does the interface upon which the rip packets arrive matter to a
standard ripd daeon? Does the tunnel encapsulation type matter? (would it
matter or depend upon if this was l2tp/ipip/pptp/openvpn/gre/etc?) How is
a rip packet that arrives on interface tun0 fundamentally different from
one that arrives on eth0?
Thanks,
Eric
AF6EP
Is it possible to get the IPIP routes delivered
by conventional routing
protocols (RIP, OSPF, etc) rather than running a custom daemon ?
Well, they are being delivered by RIP, but because it's supplying
tunnel routes over a tunnel, it has to be handled in a special way,
thus RIP44d. You don't want the tunnel routes to be seen by your
normal RIP listener because the routes aren't to local next-hop
addresses, they're to tunnel endpoints.
- Brian
6:41 p.m.
On Sat, 27 Jul 2013, Eric Fort wrote:
Why does the interface upon which the rip packets
arrive matter to a
standard ripd daeon? Does the tunnel encapsulation type matter? (would it
matter or depend upon if this was l2tp/ipip/pptp/openvpn/gre/etc?) How is
a rip packet that arrives on interface tun0 fundamentally different from
one that arrives on eth0?
It's treated differently because the introduced route will reference a
next-hop based on the tunnel destination address of the gateway associated
with that route, not on the interface the announcement was received on or
the address of the neighbor that sent the announcement. Other than BGP
multi-hop and DMVPN, most common routing protocols use a next-hop based on
the latter. You may get the full routing table but they wont use a full
mesh of links.
On the other hand, if having a full mesh of tunnels is not so important,
you can run standard routing protocols with cooperating tunnels/gateways.
Antonio Querubin
e-mail: tony(a)lavanauts.org
xmpp: antonioquerubin(a)gmail.com
3:33 a.m.
Hi Neil,
It is possible to recive them, but the conventional daemons use them in
wrong way.
Each RIP entry contains a IP/mask, a gateway and a distance metric.
Clasic RIP daemons use this information to create a route entry to that
subnet using the IP of the incoming interface as the gateway for the route.
The IPIP tunnel interface needs the enstated route to use the gateway
provided by the RIP entry instead of the IP of the incoming interface.
And this is what rip44d does.
An additional custom protocol to quagga could be a solution...
Marius
-----Original Message-----
From: 44net-bounces+marius=yo2loj.ro(a)hamradio.ucsd.edu
[mailto:44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu] On Behalf Of Neil
Johnson
Sent: Sunday, July 28, 2013 01:25
To: AMPRNet working group
Subject: [44net] Receiving routes with conventional RIP
(Please trim inclusions from previous messages)
_______________________________________________
Is it possible to get the IPIP routes delivered by conventional routing
protocols (RIP, OSPF, etc) rather than running a custom daemon ?
Just curious.
-Neil
--
Neil Johnson -N0SFH
http://erudicon.com
3:51 a.m.
Just a small correction. Classic RIP uses the rip senders address as the
gateway...
To clarify it by example:
Let's take my own RIP entry coming via interface tun0 which has IP address
44.182.21.1:
IP address: 44.182.21.0 netmask: 255.255.255.0 nexthop: 89.122.215.236
metric: 1
Sender is 44.0.0.1
the convetional processing will give:
44.182.21.0/24 via 44.0.0.1 dev tun0 proto zebra metric 20
rip44d will create the following entry:
44.182.21.0/24 via 89.122.215.236 dev tun0 window 840
Marius, YO2LOJ
-----Original Message-----
From: 44net-bounces+marius=yo2loj.ro(a)hamradio.ucsd.edu
[mailto:44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu] On Behalf Of
Marius Petrescu
Sent: Sunday, July 28, 2013 11:34
To: 'AMPRNet working group'
Subject: Re: [44net] Receiving routes with conventional RIP
It is possible to recive them, but the conventional daemons use them in
wrong way.
---
6:40 a.m.
On Sun, Jul 28, 2013 at 1:51 AM, Marius Petrescu <marius(a)yo2loj.ro> wrote:
(Please trim inclusions from previous messages)
_______________________________________________
Just a small correction. Classic RIP uses the rip senders address as the
gateway...
To clarify it by example:
Let's take my own RIP entry coming via interface tun0 which has IP address
44.182.21.1:
IP address: 44.182.21.0 netmask: 255.255.255.0 nexthop: 89.122.215.236
metric: 1
Sender is 44.0.0.1
the convetional processing will give:
44.182.21.0/24 via 44.0.0.1 dev tun0 proto zebra metric 20
rip44d will create the following entry:
44.182.21.0/24 via 89.122.215.236 dev tun0 window 840
Marius, YO2LOJ
If the true next hop is known then why does ripd not use it? what is the
rfc compliant and thus proper behavior for how and where packets are sent
on to when using rip?
Eric
11:19 a.m.
You are right, the true next hop is known.
But for the receiving system, in classic RIP the correct next hop is the
sender of the RIP message since the sender adverises its routes via the
sending interface as a gateway for those routes.
The "previous next hop" is used for optimisations/loop avoidance and other
internal stuff.
-----Original Message-----
From: 44net-bounces+marius=yo2loj.ro(a)hamradio.ucsd.edu
[mailto:44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu] On Behalf Of Eric
Fort
Sent: Sunday, July 28, 2013 14:41
To: AMPRNet working group
Subject: Re: [44net] Receiving routes with conventional RIP
If the true next hop is known then why does ripd not use it? what is the
rfc compliant and thus proper behavior for how and where packets are sent on
to when using rip?
Eric
_________________________________________
44Net mailing list
44Net(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net
http://www.ampr.org/donate.html
4136
days inactive
4137
days old
8 comments
6 participants
participants (6)
-
Antonio Querubin -
Brian Kantor -
Eric Fort -
Marc, LX1DUC -
Marius Petrescu -
Neil Johnson