9 Jan
2015
9 Jan
'15
7:52 p.m.
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
9 Jan
9 Jan
10:31 p.m.
Lynwood;
On Fri, 2015-01-09 at 19:52 -0500, lleachii(a)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(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.
10 Jan
10 Jan
1:53 a.m.
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(a)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(a)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(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
2:06 a.m.
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(a)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
4:16 a.m.
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
--
Jann Traschewski, Faber-Castell-Str. 9, D-90522 Oberasbach, Germany
Tel.: +49-911-99946898, Mobile: +49-170-1045937, E-Mail: jann(a)gmx.de
Ham: DG8NGN / DB0VOX, http://www.qsl.net/dg8ngn
5:01 a.m.
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(a)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
9:15 a.m.
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(a)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(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net
--
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:18 a.m.
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
11:32 a.m.
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.
11:37 a.m.
Lynwood;
On Sat, 2015-01-10 at 11:18 -0500, lleachii(a)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.
--
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.
1:06 p.m.
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(a)hamradio.ucsd.edu
[mailto:44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu] On Behalf Of
lleachii(a)aol.com
Sent: Saturday, January 10, 2015 18:19
To: 44net(a)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?
12 Jan
12 Jan
8:07 a.m.
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(a)vk4aa.com.au
73's
Sam
VK4AA
Land down Under
3601
days inactive
3603
days old
11 comments
5 participants
participants (5)
-
Brian -
Jann Traschewski -
lleachii＠aol.com -
Marius Petrescu -
Samantha S