All,
Happy New Year!
A few months ago, an AMPRNet user requested 44Net allocations. One subnet is announced on the Public Internet using BGP. The other is a standard 44 gateway, with the exception that it's Public IP address is the BGPed 44/8 address.
Since, on the ICANN Internet, 44/8 is one flat network routeed via BGP; and allocations within AMPRNet are often islands gateways with a non-44 IP (since, under ICANN logic, this means both the WAN and LAN interface are on the same network) routed using RIP44; this presented a problem with our current schema.
Using Linux routing, I solved the problem by adding the 44 subnet to a special routing table, and adding the Public-facing gateway address to my Public-facing route table. Hence, these routes and rules ignore the "invalid" RIP44 gateway announcement.
Here's the script: NOTE: make sure the BGPed IPs have a higher priority (lower number) than the standard AMPRNet ip rules.
######################################## ### SPECIAL CASE - FOR THOSE WHO BGP ### AND HAVE SUBNETS BEHIND 44 ADDRESSES
### THIS ADDS THE BGPed IP TO THE MAIN TABLE ip rule add to 44.24.221.1/32 table main priority 42
### THIS ADDS THE ROUTE TO A SPECIAL TABLE ip route add 44.24.240.0/20 via 44.24.221.1 dev tunl0 onlink table 22
### THIS TELLS THE ROUTER TO REFERENCE THE ### SPECIAL TABLE TO ACCESS THIS SUBNET ip rule add to 44.24.240.0/20 table 22 priority 43
73,
-Lynwood KB3VWG
Lynwood;
On Fri, 2015-01-09 at 19:52 -0500, lleachii@aol.com wrote:
This is something I mentioned was needed for us to do a while ago but was flamed for saying such.
Using Linux routing, I solved the problem by adding the 44 subnet to a special routing table, and adding the Public-facing gateway address to my Public-facing route table. Hence, these routes and rules ignore the "invalid" RIP44 gateway announcement.
n The unfortunate part of this is for ALL BGP based 44-net subnets this is required. My suggestion took this a bit further in which the RIP broadcaster might send these BGP based 44-net subnets with a flag ampr-ripd or Hessu's perl can see and add these specialized rules without manual intervention as would be needed now.
The question at hand is whether or not this is possible to do at both the RIP server and rip daemons. For linux admins to have to manually maintain route rules for those subnets, for which routing should be fully automatic, is a major step backward IMHO... especially when this system has worked for us all for decades. I just don't understand how it's "broken" overnight.
I would propose to add another announce type:
Announce bgp gateways with its own gateway set to 0.0.0.0:
So in this case: 44.140.0.1/32 via 0.0.0.0 44.140.0.0/24 via 44.140.0.1
The daemon shall be modified to add routes to addresses which have gw 0.0.0.0 to be routed via default. This will give a functional setup, with 44.140.0.1 reachable direct, and 44.140.0.0/24 IPIP encapsulated and sent to 44.140.0.1.
BTW: Could anyone tell me a IP inside that network, except that gateway, which should be reachable for testing purposes?
Marius, YO2LOJ
-----Original Message----- From: 44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu [mailto:44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu] On Behalf Of Brian Sent: Saturday, January 10, 2015 05:32 To: AMPRNet working group Subject: Re: [44net] 44 Network behind BGPed 44 Address
(Please trim inclusions from previous messages) _______________________________________________ Lynwood;
On Fri, 2015-01-09 at 19:52 -0500, lleachii@aol.com wrote:
This is something I mentioned was needed for us to do a while ago but was flamed for saying such.
Using Linux routing, I solved the problem by adding the 44 subnet to a special routing table, and adding the Public-facing gateway address to my Public-facing route table. Hence, these routes and rules ignore the "invalid" RIP44 gateway announcement.
n The unfortunate part of this is for ALL BGP based 44-net subnets this is required. My suggestion took this a bit further in which the RIP broadcaster might send these BGP based 44-net subnets with a flag ampr-ripd or Hessu's perl can see and add these specialized rules without manual intervention as would be needed now.
The question at hand is whether or not this is possible to do at both the RIP server and rip daemons. For linux admins to have to manually maintain route rules for those subnets, for which routing should be fully automatic, is a major step backward IMHO... especially when this system has worked for us all for decades. I just don't understand how it's "broken" overnight. -- To falter a protocol for the actions of a human is in reality the human failing to take responsibility for their own actions.
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
This will break RIP forwarding to other routers, but is manageable.
But what I don't get is the following: Why isn't 44.140.0.1 announced to use tunneling via its public IP (192.16.126.18 I think)? Or why announce it at all in the RIP if it the whole subnet is is BGPed?
Is it pure ambition just to break existing working things?
-----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: Saturday, January 10, 2015 08:53 To: 'AMPRNet working group' Subject: Re: [44net] 44 Network behind BGPed 44 Address
(Please trim inclusions from previous messages) _______________________________________________ I would propose to add another announce type:
Announce bgp gateways with its own gateway set to 0.0.0.0:
So in this case: 44.140.0.1/32 via 0.0.0.0 44.140.0.0/24 via 44.140.0.1
The daemon shall be modified to add routes to addresses which have gw 0.0.0.0 to be routed via default. This will give a functional setup, with 44.140.0.1 reachable direct, and 44.140.0.0/24 IPIP encapsulated and sent to 44.140.0.1.
BTW: Could anyone tell me a IP inside that network, except that gateway, which should be reachable for testing purposes?
Marius, YO2LOJ
On 10.01.2015 07:53, Marius Petrescu wrote:
I would propose to add another announce type:
Announce bgp gateways with its own gateway set to 0.0.0.0:
So in this case: 44.140.0.1/32 via 0.0.0.0 44.140.0.0/24 via 44.140.0.1
The daemon shall be modified to add routes to addresses which have gw 0.0.0.0 to be routed via default.
Good idea! There is a another gateway which could be fixed this way: 44.24.221.1/32 via 0.0.0.0 44.24.240.0/20 via 44.24.221.1
Currently I need to setup this type of gateway manually on my system...
BTW: Could anyone tell me a IP inside that network, except that gateway, which should be reachable for testing purposes?
ftp://hamradio.ucsd.edu/pub/amprhosts is your friend. I tested 44.140.7.1 successfully from a "non-ham" box. Unfortunately it is not reachable within the IPIP mesh since it seems the gateway 192.16.126.18 doesn't do its job...
73, Jann
That one actually doesn't need fixing and works as it should (at least it works on my system).
44.24.221.1 is not announced in the RIP broadcast, so it goes implicitely to default (and NATed to the local public IP) if the system is correctly configured. In this case the tunnel endpoints are correctly defined, and 44.24.240/24 is sent via IPIP from the local public IP to 44.24.221.1, which, being BGP annonced, is directly reachable on regular internet. The only condition for this to work is NOT to have a default route to 44.0.0.0/8 via tunnel.
The problem with 44.140 is that the gateway is in its own subnet. So we need to instate a higher priroity route for the gateway, to avoid the tunnel, on the local system or on a potential connected router which gets RIP forwarding. And we need a way to differentiate between a misconfigured situation and a legitimate setup.
That is why I proposed the GW 0.0.0.0 approach, meaning no gateway. This will solve the local routing issue on the gateway, but will not work on RIP forwarding, and a manual intervention is still required on any connected router. Because receiving the RIP route for the gateway will cause a routing loop, dropping it will also create another routing loop, since standard RIP sets the gateway for a route to the interface on which it received the routing info. But it could be a first step.
Or just drop the route alltogether, and rely on the fact that the whole subnet is BGP announced, as it happens on ampr-ripd 1.13. This leads to a correct working setup, the only limitation being that the destination system can not differentiate between ampr/non-ampr traffic, since NAT to a public IP is needed.
I think modifying ampr-gw to accept forwarding to such host is out of the question, since it would increase the load on that system. If acceptable, the default route via tunnel for 44.0.0.0/8 destinations would cover this situation, provided that ampr-gw accepts forwarding to BGPed 44net destinations..
Marius, YO2LOJ
-----Original Message----- From: 44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu [mailto:44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu] On Behalf Of Jann Traschewski Sent: Saturday, January 10, 2015 11:17 To: AMPRNet working group Subject: Re: [44net] 44 Network behind BGPed 44 Address
( ...
Good idea! There is a another gateway which could be fixed this way: 44.24.221.1/32 via 0.0.0.0 44.24.240.0/20 via 44.24.221.1
Currently I need to setup this type of gateway manually on my system... ... 73, Jann
Marius;
On Sat, 2015-01-10 at 12:01 +0200, Marius Petrescu wrote:
44.24.221.1 is not announced in the RIP broadcast, so it goes implicitely to default (and NATed to the local public IP) if the system is correctly configured.
Remember this is a four fold process:
1) Rip server uses a flag for announcement - you propose that flag as 0.0.0.0. The flag itself is irrelivant.
2) The subnet is either ignored getting entered into the local amprnet table
3) The subnet has a rule included by the rip listener daemon to either route that subnet using a special non-encap table list (ie: table 2, table bgp, table isp....) and a rule to set routing to that subnet via that matching table via one's internet interface (thus sourcing you as a non-44/non-encapsulated IP)
Contact me off-list Marius if you'd like more specifics.
In this case the tunnel endpoints are correctly defined, and 44.24.240/24 is sent via IPIP from the local public IP to 44.24.221.1, which, being BGP annonced, is directly reachable on regular internet. The only condition for this to work is NOT to have a default route to 44.0.0.0/8 via tunnel.
The problem with 44.140 is that the gateway is in its own subnet. So we need to instate a higher priroity route for the gateway, to avoid the tunnel, on the local system or on a potential connected router which gets RIP forwarding. And we need a way to differentiate between a misconfigured situation and a legitimate setup.
That is why I proposed the GW 0.0.0.0 approach, meaning no gateway. This will solve the local routing issue on the gateway, but will not work on RIP forwarding, and a manual intervention is still required on any connected router. Because receiving the RIP route for the gateway will cause a routing loop, dropping it will also create another routing loop, since standard RIP sets the gateway for a route to the interface on which it received the routing info. But it could be a first step.
Or just drop the route alltogether, and rely on the fact that the whole subnet is BGP announced, as it happens on ampr-ripd 1.13. This leads to a correct working setup, the only limitation being that the destination system can not differentiate between ampr/non-ampr traffic, since NAT to a public IP is needed.
I think modifying ampr-gw to accept forwarding to such host is out of the question, since it would increase the load on that system. If acceptable, the default route via tunnel for 44.0.0.0/8 destinations would cover this situation, provided that ampr-gw accepts forwarding to BGPed 44net destinations..
Marius, YO2LOJ
-----Original Message----- From: 44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu [mailto:44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu] On Behalf Of Jann Traschewski Sent: Saturday, January 10, 2015 11:17 To: AMPRNet working group Subject: Re: [44net] 44 Network behind BGPed 44 Address
( ...
Good idea! There is a another gateway which could be fixed this way: 44.24.221.1/32 via 0.0.0.0 44.24.240.0/20 via 44.24.221.1
Currently I need to setup this type of gateway manually on my system... ... 73, Jann
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
Brian N1URO,
I guess I'll present my thought processes as well. I found the problems to be:
a.) solving the OSI Layer 1 issue: the limitation in RIP44; in that it only permits routing to one (1) interface; or b.) solving the OSI Layer 3 issue: that all 44/8 IPs are not necessarily on AMPRNet, some are on the ICANN Network; or c.) being satisfied with routing packets for any unknown subnet - unencapsulated via ICANN (with masquerade); or using static rules and routing
I've found no dynamic routing solution that solves Problem B on AMPRGW or our 44net routers; except by solving Problem A. So long as the Main AMPRGW uses BGP first, a RIP44v2 could fix it; but present the issues that Marius described. Solutions to Problem C are all workarounds to Problems A and B.
You suggested somehow incorporating interfaces into RIP44 announcements; that requires a rewrite of the RIP44 protocol, which permanently solves the problem at Layer 1.
Perhaps it's time for RIP44v2 to add:
- add other interface flags - provide CLI variables for those flags to specify eth interfaces, in addition to tunl0 - perhaps ability to save the RIP44 announcement to a file - only overwrite the persistent file when a new announcement is received, otherwise refer to the file
The only problem, is that RIP44v2 would not be backwards compatible with RIP44; this requires an upgrade of all AMPRNet routers.
---------------------
Marius,
But what I don't get is the following: Why isn't 44.140.0.1 announced to use tunneling via its public IP (192.16.126.18 I think)? Or why announce it at all in the RIP if it the whole subnet is is BGPed?
To your first question: I would have to reference the mail archive (I recall the user stating the 44 IP is valid; but under ICANN logic applied to AMPRNet, it's not); the solution all 44GWs would be to use a Public IP.
To your second point, the BGPed subnet is NOT announced.
BTW: Could anyone tell me a IP inside that network, except that gateway, which should be reachable for testing purposes?
The BGPed address is 44.24.221.1/32
An IP inside the network that's reachable: 44.24.240.1:
@kb3vwg-001:~$ ping 44.24.240.1 -c 3 PING 44.24.240.1 (44.24.240.1) 56(84) bytes of data. 64 bytes from 44.24.240.1: icmp_seq=1 ttl=60 time=114 ms 64 bytes from 44.24.240.1: icmp_seq=2 ttl=60 time=116 ms 64 bytes from 44.24.240.1: icmp_seq=3 ttl=60 time=109 ms
--- 44.24.240.1 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2003ms rtt min/avg/max/mdev = 109.991/113.715/116.392/2.730 ms
@kb3vwg-001:~$ traceroute 44.24.240.1 traceroute to 44.24.240.1 (44.24.240.1), 30 hops max, 60 byte packets 1 switch.seattle-er1.hamwan.net (44.24.241.97) 84.877 ms 84.962 ms 84.865 ms 2 ether1.queenanne.seattle.hamwan.net (44.24.241.99) 85.174 ms 85.365 ms 85.330 ms 3 wlan1.ptp1-westin.queenanne.hamwan.net (44.24.242.35) 89.324 ms 89.633 ms 89.618 ms 4 ether1.capitolpark.queenanne.hamwan.net (44.24.241.83) 90.055 ms 89.900 ms 89.859 ms 5 ether1.paine.capitolpark.hamwan.net (44.24.240.7) 118.569 ms 118.855 ms 119.233 ms 6 capitolpark-r1.hamwan.net (44.24.240.1) 120.432 ms 93.757 ms 96.728 ms
I thought of one option that doesn't break RIP44 for those who do not upgrade:
Have RIP44d parse the routing table; and if a 44 GW via address is found:
- add to a table for BGPed subnets - add the /32 to the main routing table - add an ip route rule with a higher priority to look for the GW IP on the main table - add a ip route rule with a higher priority to look for the subnet on the BGPed table
Basically, this automates my script.
Lynwood;
On Sat, 2015-01-10 at 11:18 -0500, lleachii@aol.com wrote:
You suggested somehow incorporating interfaces into RIP44 announcements;
No, I did not mention anything of the sort. This would only make it more complicated than it needs to be.
Something parallel to the below would work.
if ampr-route == rip { than ((route -> table 1) && (ruleset = route via encap)); } else { ((route -> table main) && (uleset = route via internet)); };
All we would need for the rip broadcaster is some sort of a flag (ie: host == 0.0.0.0 would work fine) to which the ampr-ripd would ignore adding the BGP hosted route into your encapsulated ruleset. Anthing else is purely overkill.
In your follow-up mail, you suggest using a 44.x.x.x HOST IP as the flag. Any flag works here. You misunderstood my previous mail.
Hello,
The 44.24.240/16 network is functional, alive and kicking.
I was talking about 44.140.0.0/16, The one with the gateway inside its own subnet, that raises the questions. And that one is announced:
The subnet in question is verry announced:
44.140.0.0/16 *[BGP/170] 04:45:48, MED 0, localpref 100 AS path: 2603 1653 2839 8973 I > to 80.81.192.241 via xe-1/1/0.0 [BGP/170] 5w1d 02:52:13, MED 0, localpref 100 AS path: 3257 1299 1299 1299 2603 1653 2839 8973 I > to 213.200.86.101 via xe-1/0/0.0
But with cuurent routing information, no tunnel can be constructed, since on tunnel setup the gateway can not be resolved.
And there is 44.140,7.1 inside, directly reachable.
Have RIP44d parse the routing table; and if a 44 GW via address is found:
- add to a table for BGPed subnets
- add the /32 to the main routing table
- add an ip route rule with a higher priority to look for the GW IP on
the main table
- add a ip route rule with a higher priority to look for the subnet on
the BGPed table
Basically, this automates my script.
Now the good question is, how do you know thode BGPed networks without having access to a global BGP table? That is why I proposed the 0.0.0.0 as gateway to indicate that, and this doesn't need major changes on either side.
Just use 0.0.0.0 for directly announced subnets or individual gateways. This should trigger the instatement of a higher priority route targeting the default local gateway. For subnets, 0.0.0.0 would have the same behavior (direct routing). If tunneling is provided defining the gateway as a /32 with gw 0.0.0.0 and the tunnel with that gateway as usual gateway would give a correct behavior. And it will keep the broadcasts RIPv2 compatible (meaning that at least one can dissect them in wireshark for debuging).
Matius, YO2LOJ
-----Original Message----- From: 44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu [mailto:44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu] On Behalf Of lleachii@aol.com Sent: Saturday, January 10, 2015 18:19 To: 44net@hamradio.ucsd.edu Subject: Re: [44net] 44 Network behind BGPed 44 Address
But what I don't get is the following: Why isn't 44.140.0.1 announced to use tunneling via its public IP (192.16.126.18 I think)? Or why announce it at all in the RIP if it the whole subnet is is BGPed?
Guys
I am using BGP here and it has allowed me to offer other Amateur Radio activities on the IP Space. If anyone has been able to configure JNOS2 with out an encap please send me the config to vk4aa@vk4aa.com.au
73's
Sam VK4AA Land down Under
-
Brian -
Jann Traschewski -
lleachii＠aol.com -
Marius Petrescu -
Samantha S