12 Nov
2014
12 Nov
'14
4:16 a.m.
Brian Kantor wrote:
Those are valid gateway entries; those particular
44-net addresses
are directly routed via BGP advertisement.
- Brian
Ok, but then I think those gateway entries should not be distributed via RIP.
When they are directly routable, should we use a tunnel to reach them?
There is a problem because when the destination of the tunnel is within the net-44,
the routing gets in an encapsulation loop.
Rob
12 Nov
12 Nov
5:28 a.m.
New subject: Gateways with external address in net-44
This is not exactly true for 44.24.240/20 with gateway 44.24.221.1
44.24.221.1 is reacheable via BGP and does not have an encap entry.
But in order to reach 44.24.240/20, one needs to IPIP encapsulate the data
and send it to 44.24.221.1, which is the tunnel endpoint.
This should actually work as long as there is no default gateway for 44
addresses via the tunnel.
73s de Marius, YO2LOJ.
(Please trim inclusions from previous messages)
_______________________________________________
Brian Kantor wrote:
Those are valid gateway entries; those particular
44-net addresses
are directly routed via BGP advertisement.
- Brian
Ok, but then I think those gateway entries should not be distributed via
RIP.
When they are directly routable, should we use a tunnel to reach them?
There is a problem because when the destination of the tunnel is within
the net-44,
the routing gets in an encapsulation loop.
Rob
_________________________________________
44Net mailing list
44Net(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net
8:07 a.m.
New subject: Gateways with external address in net-44
On Wed, 2014-11-12 at 10:16 +0100, Rob Janssen wrote:
Ok, but then I think those gateway entries should not
be distributed via RIP.
When they are directly routable, should we use a tunnel to reach them?
That's only half the equasion. The other half is when one is SAFed
(Source Address FilterED) and they policy route 44/8 via their tunnel
interface, and anything else via UCSD... we either need to insure that
we have a separate listing of 44-net IPs using BGP so we can reverse
munge script those IPs.so that they're not trapped being policy routed
via local tunnels, unless amprgate will handle tunnelled routing for
these IPs...?
--
If Microsoft intended Windows to be for ham usage,
they would have incorporated our protocols into their kernel.
73 de Brian Rogers - N1URO
email: <n1uro(a)n1uro.ampr.org>
Web: http://www.n1uro.net/
Ampr1: http://n1uro.ampr.org/
Ampr2: http://nos.n1uro.ampr.org
Linux Amateur Radio Services
axMail-Fax & URONode
AmprNet coordinator for:
Connecticut, Delaware, Maine,
Maryland, Massachusetts,
New Hampshire, Pennsylvania,
Rhode Island, and Vermont.
9:59 a.m.
New subject: Gateways with external address in net-44
I’m a network admin for the 44.24.240.0/20 network using the 44.24.221.1 gateway. Marius
is exactly correct. 44.24.221.1 is NOT in the encap and is directly BGP announced. And the
comments that this will cause problems for those who route all of 44/8 to USCD are
correct. We have decided that for our own best interests (we can announce 44.24.221.1 at
multiple peers, and thus have highly available tunnel endpoints for all who wish to
connect), and in what we believe pushes forward progress for the network as a whole, this
is our best option. A blanket route to UCSD for 44/8 is pretty shortsighted, and ignores
all users (including ourselves) that announce via BGP, and limits what users can do for
highly available gateways.
If a “reverse” list of users who announce via BGP and use 44/net addresses as tunnel
endpoints would help with getting these routing setups better situated so traffic doesn’t
end up lost in the loop, then I would be pleased to assist in it’s creation. Ideally, this
would be put in place at UCSD itself, so that individual users could still route via UCSD,
and UCSD would take care of sending it along to the endpoint. (Us or someone else)
Nigel
K7NVH
On Nov 12, 2014, at 5:07 AM, Brian
<n1uro(a)n1uro.ampr.org> wrote:
(Please trim inclusions from previous messages)
_______________________________________________
On Wed, 2014-11-12 at 10:16 +0100, Rob Janssen wrote:
Ok, but then I think those gateway entries should
not be distributed via RIP.
When they are directly routable, should we use a tunnel to reach them?
That's only half the equasion. The other half is when one is SAFed
(Source Address FilterED) and they policy route 44/8 via their tunnel
interface, and anything else via UCSD... we either need to insure that
we have a separate listing of 44-net IPs using BGP so we can reverse
munge script those IPs.so that they're not trapped being policy routed
via local tunnels, unless amprgate will handle tunnelled routing for
these IPs...?
--
If Microsoft intended Windows to be for ham usage,
they would have incorporated our protocols into their kernel.
73 de Brian Rogers - N1URO
email: <n1uro(a)n1uro.ampr.org>
Web: http://www.n1uro.net/
Ampr1: http://n1uro.ampr.org/
Ampr2: http://nos.n1uro.ampr.org
Linux Amateur Radio Services
axMail-Fax & URONode
AmprNet coordinator for:
Connecticut, Delaware, Maine,
Maryland, Massachusetts,
New Hampshire, Pennsylvania,
Rhode Island, and Vermont.
_________________________________________
44Net mailing list
44Net(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net
10:27 a.m.
New subject: Gateways with external address in net-44
Nigel et al;
On Wed, 2014-11-12 at 06:59 -0800, Nigel Vander Houwen wrote:
If a “reverse” list of users who announce via BGP and
use 44/net addresses as tunnel endpoints would help with getting these routing setups
better situated so traffic doesn’t end up lost in the loop, then I would be pleased to
assist in it’s creation. Ideally, this would be put in place at UCSD itself, so that
individual users could still route via UCSD, and UCSD would take care of sending it along
to the endpoint. (Us or someone else)
Actually, in thinking this over I may have come up with a solution...
A gateway entry would be required in encap.txt/ripv2 in which that
gateway would live at UCSD, and those whom announce their own routes
would naturally see them as an encapped route to UCSD, who in turn can
route non-encapped to those points. This would also solve the multiple
SAFed gateways from having to incorporate individual policy route rules
for those who are BGP announced. They would instead route normally from
their 44-net policy rules.
I could assist with this if needed, and it would cure more than just
your subnet since more are announced. As BGP routes are added, (I'll
assume) Brian would have to enter in these routes into his gateway
within the portal. This shouldn't be too difficult since requests to
allow one's subnet to be announced still requires approval.
--
If Microsoft intended Windows to be for ham usage,
they would have incorporated our protocols into their kernel.
73 de Brian Rogers - N1URO
email: <n1uro(a)n1uro.ampr.org>
Web: http://www.n1uro.net/
Ampr1: http://n1uro.ampr.org/
Ampr2: http://nos.n1uro.ampr.org
Linux Amateur Radio Services
axMail-Fax & URONode
AmprNet coordinator for:
Connecticut, Delaware, Maine,
Maryland, Massachusetts,
New Hampshire, Pennsylvania,
Rhode Island, and Vermont.
11:07 a.m.
New subject: Gateways with external address in net-44
Brian,
I believe the issue stands (and this is hearsay) that the 44/net router at
UCSD assumes that ALL 44/8 traffic goes to them, so they can't route to
externally announced 44/8 addresses. So until that got fixed, I don't
believe your idea would be workable. However, that's not too different (if
I understand you correctly) from what I proposed, that UCSD handles the
routing (if the issue were to be resolved) for entries that aren't in the
encap, and end points/users can still route to specific tunnel entries,
and the rest of 44/8 to UCSD.
If the described issue doesn't exist, or can be resolved, I think that
would be the easiest way for everyone.
Nigel
(Please trim inclusions from previous messages)
_______________________________________________
Nigel et al;
On Wed, 2014-11-12 at 06:59 -0800, Nigel Vander Houwen wrote:
If a âreverseâ list of users who announce via
BGP and use 44/net
addresses as tunnel endpoints would help with getting these routing
setups better situated so traffic doesnât end up lost in the loop,
then I would be pleased to assist in itâs creation. Ideally, this
would be put in place at UCSD itself, so that individual users could
still route via UCSD, and UCSD would take care of sending it along to
the endpoint. (Us or someone else)
Actually, in thinking this over I may have come up with a solution...
A gateway entry would be required in encap.txt/ripv2 in which that
gateway would live at UCSD, and those whom announce their own routes
would naturally see them as an encapped route to UCSD, who in turn can
route non-encapped to those points. This would also solve the multiple
SAFed gateways from having to incorporate individual policy route rules
for those who are BGP announced. They would instead route normally from
their 44-net policy rules.
I could assist with this if needed, and it would cure more than just
your subnet since more are announced. As BGP routes are added, (I'll
assume) Brian would have to enter in these routes into his gateway
within the portal. This shouldn't be too difficult since requests to
allow one's subnet to be announced still requires approval.
--
If Microsoft intended Windows to be for ham usage,
they would have incorporated our protocols into their kernel.
73 de Brian Rogers - N1URO
email: <n1uro(a)n1uro.ampr.org>
Web: http://www.n1uro.net/
Ampr1: http://n1uro.ampr.org/
Ampr2: http://nos.n1uro.ampr.org
Linux Amateur Radio Services
axMail-Fax & URONode
AmprNet coordinator for:
Connecticut, Delaware, Maine,
Maryland, Massachusetts,
New Hampshire, Pennsylvania,
Rhode Island, and Vermont.
_________________________________________
44Net mailing list
44Net(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net
12:08 p.m.
New subject: Gateways with external address in net-44
Nigel;
On Wed, 2014-11-12 at 08:07 -0800, Nigel Vander Houwen wrote:
I believe the issue stands (and this is hearsay) that
the 44/net router at
UCSD assumes that ALL 44/8 traffic goes to them, so they can't route to
externally announced 44/8 addresses.
If you're using BGP, smaller subnet broadcasts take a higher priority
and UCSD shouldn't know about your route, but this shouldn't necessarily
prevent it from routing out to you if an exceptions table
somewhere/somehow is made. Right now as it stands, a 44-net/BGP route
not in encap/rip I wouldn't see and I would default route it to UCSD via
encap based on both route tables (aka: default) and policy route rules
(send 44/8 via tunnel). Any non-BGP amprnet routing would not go via
UCSD, but instead be point-to-point between ends.
So until that got fixed, I don't
believe your idea would be workable. However, that's not too different (if
I understand you correctly) from what I proposed, that UCSD handles the
routing (if the issue were to be resolved) for entries that aren't in the
encap, and end points/users can still route to specific tunnel entries,
and the rest of 44/8 to UCSD.
You're correct that USCD would have to allow outbound routing via encap
to the 44-net IPs broadcast by BGP. My suggestion to accomplish this
would be if some sort of an amprbgp-gw existed to decode the remote
non-BGP 44-net encapsulated frames, and link the routing out. Then
again, it doesn't even have to necessarily be at UCSD either. It could
be anywhere that's not SAFed, and has free 44-net to 44-net routing via
non-encapsulated means. An ideal location would be one of the locations
who is announcing their block via BGP that can put say eth0 on a non-44
Ip and eth1 on their announced 44-net IP, with a tunnel interface to
cover those encapsulated frames coming in.
The commercial IP of eth0 would be the gateway for the tunnel interface
IP, and the outbound route would be via eth1 using the BGP announced
44-net IP. If you have a box that could do something such as this, I'd
be happy to test the theory. If interested, contact me off list.
--
If Microsoft intended Windows to be for ham usage,
they would have incorporated our protocols into their kernel.
73 de Brian Rogers - N1URO
email: <n1uro(a)n1uro.ampr.org>
Web: http://www.n1uro.net/
Ampr1: http://n1uro.ampr.org/
Ampr2: http://nos.n1uro.ampr.org
Linux Amateur Radio Services
axMail-Fax & URONode
AmprNet coordinator for:
Connecticut, Delaware, Maine,
Maryland, Massachusetts,
New Hampshire, Pennsylvania,
Rhode Island, and Vermont.
12:10 p.m.
New subject: Gateways with external address in net-44
Nigel, Brian,
IMHO this is actually a non-issue.
I will take Nigel's setup as an example.
In my setup there is no route pointing to 44.24.221.1. So traffic to it will
be NAT-ed by my router to my public IP, and then sent via internet to
44.24.221.1.
The route to it is completly traceable to 44.24.221.1.
Now the route created by the RIP daemon states:
44.24.240.0/20 via 44.24.221.1 dev ampr0
This means that traffic will be IPIP encapsulated and sent to 44.24.221.1,
apparently originating from 89.122.215.236 (because of NAT).
Nevertheless, it will reach its intended target, and back because its
originating address is my public IP for which IPIP is forwarded to the
gateway.
And this is what I get on gateway itself:
root@server:~# traceroute -I 44.24.221.1
traceroute to 44.24.221.1 (44.24.221.1), 30 hops max, 60 byte packets
1 mikrotik-v4.ext (192.168.74.2) 0.173 ms 0.145 ms 0.165 ms <--
here is where NAT happens
2 89.122.214.254 (89.122.214.254) 14.956 ms 16.982 ms 19.035 ms
...
16 44.24.221.1 (44.24.221.1) 195.174 ms 209.189.202.213 (209.189.202.213)
203.172 ms 204.115 ms
And a trace to a host inside 44.24.240.0/20:
root@server:~# traceroute -I 44.24.241.97
traceroute to 44.24.241.97 (44.24.241.97), 30 hops max, 60 byte packets
1 switch.seattle-er1.hamwan.net (44.24.241.97) 202.845 ms 204.839 ms
206.865 ms
And this is what I get from my desktop computer via LAN (my local IP being
44.182.21.36 for 44net connections):
Tracing route to switch.seattle-er1.hamwan.net [44.24.241.97]
over a maximum of 30 hops:
1 <1 ms <1 ms <1 ms 44.182.21.254 <- router IP
2 <1 ms <1 ms <1 ms 192.168.74.1 <- internal gateway
IP
3 214 ms 219 ms 223 ms switch.seattle-er1.hamwan.net [44.24.241.97]
So it is actually working without any issues.
73s de 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 Nigel
Vander Houwen
Sent: Wednesday, November 12, 2014 18:07
To: AMPRNet working group
Subject: Re: [44net] Gateways with external address in net-44
(Please trim inclusions from previous messages)
_______________________________________________
Brian,
I believe the issue stands (and this is hearsay) that the 44/net router at
UCSD assumes that ALL 44/8 traffic goes to them, so they can't route to
externally announced 44/8 addresses. So until that got fixed, I don't
believe your idea would be workable. However, that's not too different (if
I understand you correctly) from what I proposed, that UCSD handles the
routing (if the issue were to be resolved) for entries that aren't in the
encap, and end points/users can still route to specific tunnel entries,
and the rest of 44/8 to UCSD.
If the described issue doesn't exist, or can be resolved, I think that
would be the easiest way for everyone.
Nigel
12:15 p.m.
New subject: Gateways with external address in net-44
On Wed, Nov 12, 2014 at 5:07 AM, Brian <n1uro(a)n1uro.ampr.org> wrote:
policy route 44/8 via their tunnel interface
I think we're getting a bit ahead of ourselves here proposing new
special announcements.
Here's another idea: don't assume anything spans the whole 44/8.
Instead of policy-routing 44/8, policy route for each of the routes
found in the encap. 44.24.221.0/24 isn't in the encap, so you should
source packets to it from your commercial ISP source IP. UCSD is not
involved.
Tom KD7LXL
12:22 p.m.
New subject: Gateways with external address in net-44
Tom is right.
There is absolutely no reason to policy route any outgoing 44/8 traffic to
UCSD, since it will be dropped anyway, because UCSD doesn't forward it.
The default behavior shoud be to NAT the traffic for which no specific route
exists to the public IP, just like any outgoing traffic not in the 44/8
segment.
This is an oddity that remained in the munge script from times long gone,
which actually makes no sense.
-----Original Message-----
From: 44net-bounces+marius=yo2loj.ro(a)hamradio.ucsd.edu
[mailto:44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu] On Behalf Of Tom
Hayward
Sent: Wednesday, November 12, 2014 19:15
To: AMPRNet working group
Subject: Re: [44net] Gateways with external address in net-44
(Please trim inclusions from previous messages)
_______________________________________________
On Wed, Nov 12, 2014 at 5:07 AM, Brian <n1uro(a)n1uro.ampr.org> wrote:
policy route 44/8 via their tunnel interface
I think we're getting a bit ahead of ourselves here proposing new
special announcements.
Here's another idea: don't assume anything spans the whole 44/8.
Instead of policy-routing 44/8, policy route for each of the routes
found in the encap. 44.24.221.0/24 isn't in the encap, so you should
source packets to it from your commercial ISP source IP. UCSD is not
involved.
Tom KD7LXL
_________________________________________
44Net mailing list
44Net(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net
1:18 p.m.
New subject: Gateways with external address in net-44
That whas a glitch in the matrix.
I meant all traffic for which no defined routes exist in the encap/RIP data.
Sorry for creating a misunderstanding.
-----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: Wednesday, November 12, 2014 19:23
To: 'AMPRNet working group'
Subject: Re: [44net] Gateways with external address in net-44
(Please trim inclusions from previous messages)
_______________________________________________
Tom is right.
There is absolutely no reason to policy route any outgoing 44/8 traffic to
UCSD, since it will be dropped anyway, because UCSD doesn't forward it.
The default behavior shoud be to NAT the traffic for which no specific route
exists to the public IP, just like any outgoing traffic not in the 44/8
segment.
This is an oddity that remained in the munge script from times long gone,
which actually makes no sense.
-----Original Message-----
From: 44net-bounces+marius=yo2loj.ro(a)hamradio.ucsd.edu
[mailto:44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu] On Behalf Of Tom
Hayward
Sent: Wednesday, November 12, 2014 19:15
To: AMPRNet working group
Subject: Re: [44net] Gateways with external address in net-44
(Please trim inclusions from previous messages)
_______________________________________________
On Wed, Nov 12, 2014 at 5:07 AM, Brian <n1uro(a)n1uro.ampr.org> wrote:
policy route 44/8 via their tunnel interface
I think we're getting a bit ahead of ourselves here proposing new
special announcements.
Here's another idea: don't assume anything spans the whole 44/8.
Instead of policy-routing 44/8, policy route for each of the routes
found in the encap. 44.24.221.0/24 isn't in the encap, so you should
source packets to it from your commercial ISP source IP. UCSD is not
involved.
Tom KD7LXL
_________________________________________
44Net mailing list
44Net(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net
_________________________________________
44Net mailing list
44Net(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net
3475
days inactive
3475
days old
10 comments
6 participants
participants (6)
-
Brian -
Marius Petrescu -
marius＠yo2loj.ro
-
Nigel Vander Houwen -
Rob Janssen -
Tom Hayward