Re: [44net] AMPRNet BGP vs non-BGP routing (was: Portal doesn't allow IPIP anycast via 44net)
10 Apr
2014
10 Apr
'14
5:20 p.m.
As far as I know, because of routing restrictions on the amprgw network
connectivity, hosts on BGP-announced subnets of 44/8 will be unable
to communicate with hosts on tunnel-routed subnets of 44/8 unless the
BGP-announced subnet also runs a listed tunnel router gateway with a
non-44/8 gateway address.
This is because the building-level router one hop upstream from amprgw has
a fixed route directing all 44/8 traffic to amprgw. This building-level
router does not speak BGP and so cannot learn about BGP-announced subnets
of 44/8. This is a historical artifact; it predates the availability
of BGP-announced 44/8 subnets by many years.
We hope to change this topology in the future to connectivity with the
border router that DOES speak BGP, but indications are that that change
will not be able to be done soon.
In the meantime, gateway tunnel routers with a non-44 gateway address
(that's all of them, except HamWan's proposed gateway) are the workaround
to this restriction.
I'm sorry for this difficulty but it's what we're stuck with for now.
- Brian
10 Apr
10 Apr
5:44 p.m.
New subject: AMPRNet BGP vs non-BGP routing (was: Portal doesn't allow IPIP anycast via 44net)
On 04/10/2014 11:20 PM, Brian Kantor wrote:
(Please trim inclusions from previous messages)
_______________________________________________
As far as I know, because of routing restrictions on the amprgw network
connectivity, hosts on BGP-announced subnets of 44/8 will be unable
to communicate with hosts on tunnel-routed subnets of 44/8 unless the
BGP-announced subnet also runs a listed tunnel router gateway with a
non-44/8 gateway address.
If I only could get some advice on how to set up such a
listed tunnel
router gateway, I would be interested in doing this between amprgw and
the Swedish subnet 44.140.0.0/16, which is announced via BGP out of
the Swedish University network.
My end of the tunnel would be the gateway having the ip-addresses
44.140.0.1 as well as 192.16.126.18, which is a linux based router.
How would I do this?
Bjorn
5:55 p.m.
New subject: AMPRNet BGP vs non-BGP routing (was: Portal doesn't allow IPIP anycast via 44net)
If I only could get some advice on how to set up such
a listed tunnel
router gateway, I would be interested in doing this between amprgw and
the Swedish subnet 44.140.0.0/16, which is announced via BGP out of the
Swedish University network.
My end of the tunnel would be the gateway having the ip-addresses
44.140.0.1 as well as 192.16.126.18, which is a linux based router.
How would I do this?
Really?
Goto http://portal.ampr.org
Register.
Login.
Click Gateways --> Manage --> Add new gateway
Enter details for gateway with IP 192.16.126.18
Click "Add".
Click Gateways --> Manage, Click onto "Edit" behind the Gateway you just
created.
Under Gateway Subnets enter subnet 44.140.0.0/16 and click "Add Subnet".
Setup your favorite encap.txt parser or one of the many RIP44d flavors
to setup routes via IPIP to the other 44nets.
73 de Marc
6:18 p.m.
New subject: AMPRNet BGP vs non-BGP routing (was: Portal doesn't allow IPIP anycast via 44net)
On 04/10/2014 02:20 PM, Brian Kantor wrote:
As far as I know, because of routing restrictions on
the amprgw network
connectivity, hosts on BGP-announced subnets of 44/8 will be unable
to communicate with hosts on tunnel-routed subnets of 44/8 unless the
BGP-announced subnet also runs a listed tunnel router gateway with a
non-44/8 gateway address.
This is because the building-level router one hop upstream from amprgw has
a fixed route directing all 44/8 traffic to amprgw. This building-level
router does not speak BGP and so cannot learn about BGP-announced subnets
of 44/8. This is a historical artifact; it predates the availability
of BGP-announced 44/8 subnets by many years.
Something doesn't add up here. What kind of router doesn't speak BGP? :)
I suspect the router does indeed speak BGP and OSPF and RIP, it's just
probably not powerful enough to store the entire Internet routing
table. Luckily, to solve this problem, it doesn't need to! UCSD IT can
feed that router with an extremely partial BGP feed. This feed would
only contain 44.0.0.0/8 Internet BGP-announced routes. We have such a
feed right now on our Seattle edge router for HamWAN. Here is the
entirety of the 44net routing table on the Internet:
[eo@Seattle-ER1] /ip route> print where bgp active
Flags: X - disabled, A - active, D - dynamic, C - connect, S - static, r
- rip, b - bgp, o - ospf, m - mme,
B - blackhole, U - unreachable, P - prohibit
# DST-ADDRESS PREF-SRC GATEWAY DISTANCE
0 ADb 0.0.0.0/0 209.189.196.65 20
3 ADb 44.0.0.0/8 209.189.196.65 20
54 ADb 44.16.15.0/24 209.189.196.65 20
55 ADb 44.46.160.0/22 209.189.196.65 20
56 ADb 44.68.52.0/24 209.189.196.65 20
57 ADb 44.74.128.0/24 209.189.196.65 20
58 ADb 44.98.254.0/24 209.189.196.65 20
59 ADb 44.103.0.0/19 209.189.196.65 20
60 ADb 44.127.128.0/24 209.189.196.65 20
61 ADb 44.130.99.0/24 209.189.196.65 20
62 ADb 44.135.120.0/24 209.189.196.65 20
63 ADb 44.136.138.0/24 209.189.196.65 20
64 ADb 44.136.139.0/24 209.189.196.65 20
65 ADb 44.136.150.0/24 209.189.196.65 20
66 ADb 44.136.151.0/24 209.189.196.65 20
67 ADb 44.136.158.0/24 209.189.196.65 20
68 ADb 44.136.224.0/24 209.189.196.65 20
69 ADb 44.136.227.0/24 209.189.196.65 20
70 ADb 44.139.0.0/16 209.189.196.65 20
71 ADb 44.140.0.0/16 209.189.196.65 20
72 ADb 44.144.0.0/16 209.189.196.65 20
73 ADb 44.161.252.0/22 209.189.196.65 20
96 ADb 44.169.48.0/20 209.189.196.65 20
75 ADb 44.208.0.0/16 209.189.196.65 20
[eo@Seattle-ER1] /ip route>
Please use monospace font to see it properly. This is a whopping count of:
[eo@Seattle-ER1] /ip route> print count-only where bgp active
24
24 routes! *Any* router can handle that. In fact, one of the BGP
routes is our default gateway, so in your case it'd only be 23 routes.
44.0.0.0/8 is already there though, so 22 additional routes. Hmmm
actually that's missing all the routes we (HamWAN) announce, so I guess
add 4 to that total. Either way, it's a small number!
To enable this partial-BGP-feed, UCSD IT need only make a 1-line change
to whatever will be BGP-feeding that router:
ip prefix-list HAMWAN-PREFIX-OUT seq 110 permit 44.0.0.0/8 le 24
That's not necessarily the right change for UCSD, but an example of the
right direction. This particular line of config is what feeds our
Seattle edge router with the required routes so we can make routing
decisions between taking the Internet or taking an IPIP tunnel to
deliver packets.
We hope to change this topology in the future to
connectivity with the
border router that DOES speak BGP, but indications are that that change
will not be able to be done soon.
In the meantime, gateway tunnel routers with a non-44 gateway address
(that's all of them, except HamWan's proposed gateway) are the workaround
to this restriction.
I'm sorry for this difficulty but it's what we're stuck with for now.
- Brian
This does introduce a recurring cost for us, in that we'd have to buy a
commercial /24 of IP address space for ham radio purposes. AMPR has
plenty, so it doesn't make much sense. :) I would probably leave the
UCSD communication broken instead, until UCSD fixes the routing issue.
We'd still enjoy the benefits of redundant tunnel termination for every
other AMPRnet.
Can you make the database change to configure 44.24.221.1 as the gateway
for 44.24.240.0/20?
--Bart
6:56 p.m.
New subject: AMPRNet BGP vs non-BGP routing (was: Portal doesn't allow IPIP anycast via 44net)
On 11/04/2014 00:18, Bart Kus wrote:
I suspect the router does indeed speak BGP and OSPF
and RIP, it's just
probably not powerful enough to store the entire Internet routing
table. Luckily, to solve this problem, it doesn't need to! UCSD IT can
feed that router with an extremely partial BGP feed. This feed would
only contain 44.0.0.0/8 Internet BGP-announced routes. We have such a
feed right now on our Seattle edge router for HamWAN. Here is the
entirety of the 44net routing table on the Internet:
Alot of gear at UCSD probably doesn't do anything else than static
routing. You also need to consider that such routers will require
maintenance. The process may crash, hang or whatever (read
https://labs.ripe.net/Members/erik/ripe-ncc-and-duke-university-bgp-experim…)
and will need to be monitored, eventually upgrades will need to be
applied etc. Who will pay for the time spent?
73 de Marc
11 Apr
11 Apr
2:13 a.m.
New subject: AMPRNet BGP vs non-BGP routing (was: Portal doesn't allow IPIP anycast via 44net)
Something doesn't add up here. What kind of
router doesn't speak BGP? :)
I'm pretty sure there are plenty of routers that don't speak BGP.
Can you make the database change to configure
44.24.221.1 as the gateway for
44.24.240.0/20?
Why don't you just use another ipv4 address as the tunnel endpoint ?
You can even use the /30 you are using to BGP with your upstream isp
since those will surely be in a different subnet.
73s
Robbie
2:29 a.m.
New subject: AMPRNet BGP vs non-BGP routing (was: Portal doesn't allow IPIP anycast via 44net)
On 4/10/2014 11:13 PM, Robbie De Lise wrote:
The goal is anycast. My ISP's local subnet is not portable to my other
ISP, and so on.
--Bart
(Please trim inclusions from previous messages)
_______________________________________________
Sure, WRT54Gs with stock firmware. They have no business running a
building @ UCSD though. So this doesn't add up. I'm sure their IT is
running some sort of modern-ish gear, all of which supports BGP.
Something doesn't add up here. What kind of
router doesn't speak BGP? :)
I'm pretty sure there are plenty of routers
that don't speak BGP. Can you make
the database change to configure 44.24.221.1 as the gateway for
44.24.240.0/20?
Why don't you just use another ipv4 address as the tunnel
endpoint ?
You can even use the /30 you are using to BGP with your upstream isp
since those will surely be in a different subnet.
2:36 a.m.
New subject: AMPRNet BGP vs non-BGP routing (was: Portal doesn't allow IPIP anycast via 44net)
Sure, WRT54Gs with stock firmware. They have no
business running a building
@ UCSD though. So this doesn't add up. I'm sure their IT is running some
sort of modern-ish gear, all of which supports BGP.
Well I use Dell PowerConnect 64xx as "coreswitch" in the buildings at
work and they do Layer 3 "switching" (aka routing), are modern-ish,
but they don't speak BGP, only OSPF and RIP. And even they are
configured with static routes between the buildings because it are
only a few routes.
73s
Robbie
11:16 a.m.
New subject: AMPRNet BGP vs non-BGP routing (was: Portal doesn't allow IPIP anycast via 44net)
On Thu, Apr 10, 2014 at 11:29 PM, Bart Kus <me(a)bartk.us> wrote:
The goal is anycast. My ISP's local subnet is not portable to my other
ISP, and so on.
Can you describe what you would accomplish by utilizing anycast in the
44net case? I'm not seeing a viable end goal in this direction.
Can you
make the database change to configure 44.24.221.1 as the gateway
for
44.24.240.0/20?
Why don't you just use another ipv4 address as the tunnel endpoint ?
You can even use the /30 you are using to BGP with your upstream isp
since those will surely be in a different subnet.
11:32 a.m.
New subject: AMPRNet BGP vs non-BGP routing (was: Portal doesn't allow IPIP anycast via 44net)
On 4/11/2014 8:16 AM, Don Fanning wrote:
On Thu, Apr 10, 2014 at 11:29 PM, Bart Kus
<me(a)bartk.us> wrote:
The goal is anycast. My ISP's local subnet is not portable to my other
ISP, and so on.
Can you describe what you would accomplish by utilizing anycast in the
44net case? I'm not seeing a viable end goal in this direction.
It allows our microwave network to remain connected to the rest of
AMPRnet as long as we have at least 1 ISP that isn't dead. The
microwave network peers with the Internet at 2 different points at
present, but more points will come in the future. It's a robustness
improvement in the face of partial failures, like in a natural disaster
when an ISP's fiber gets torn or their building collapses.
--Bart
Can you make the database change to configure
44.24.221.1 as the gateway
for
44.24.240.0/20?
Why don't you just use another ipv4 address as the tunnel endpoint ?
You can even use the /30 you are using to BGP with your upstream isp
since those will surely be in a different subnet.
12:02 p.m.
New subject: AMPRNet BGP vs non-BGP routing (was: Portal doesn't allow IPIP anycast via 44net)
On Fri, Apr 11, 2014 at 8:32 AM, Bart Kus <me(a)bartk.us> wrote:
(Please trim inclusions from previous messages)
_______________________________________________
On 4/11/2014 8:16 AM, Don Fanning wrote:
Right, I can see in Hamwan's case if you were closer to Seattle you would
route through Seattle and if you were closer to Corvallis, you'd route
there. But in the larger scale of things with 44net, are you proposing
that anycast be utilized throughout 44net?
On Thu, Apr 10, 2014 at 11:29 PM, Bart Kus
<me(a)bartk.us> wrote:
Can you make the database change to configure 44.24.221.1 as the gateway
Can you describe what you would accomplish by utilizing anycast in the
44net case? I'm not seeing a viable end goal in this direction.
It allows our microwave network to remain connected to the rest of AMPRnet
as long as we have at least 1 ISP that isn't dead. The microwave network
peers with the Internet at 2 different points at present, but more points
will come in the future. It's a robustness improvement in the face of
partial failures, like in a natural disaster when an ISP's fiber gets torn
or their building collapses.
> for
> 44.24.240.0/20?
>
> Why don't you just use another ipv4 address as the tunnel endpoint ?
You can even use the /30 you are using to BGP with your upstream isp
since those will surely be in a different subnet.
The goal is anycast. My ISP's local subnet is not portable to my other
ISP,
and so on.
3878
days inactive
3879
days old
12 comments
6 participants
participants (6)
-
Bart Kus -
Bjorn Pehrson -
Brian Kantor -
Don Fanning -
Marc, LX1DUC -
Robbie De Lise