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
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@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
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...?
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@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@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@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
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.
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@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@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
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.
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@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
On Wed, Nov 12, 2014 at 5:07 AM, Brian n1uro@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
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@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@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@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
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@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@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@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@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
_________________________________________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
-
Brian -
Marius Petrescu -
marius＠yo2loj.ro
-
Nigel Vander Houwen -
Rob Janssen -
Tom Hayward