Re: [44net] AMPRNet BGP vs non-BGP routing (was: Portal doesn't allow IPIP anycast via 44net)
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
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
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?
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
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
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-experime...) and will need to be monitored, eventually upgrades will need to be applied etc. Who will pay for the time spent?
73 de Marc
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
On 4/10/2014 11:13 PM, Robbie De Lise wrote:
(Please trim inclusions from previous messages) _______________________________________________
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.
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.
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.
The goal is anycast. My ISP's local subnet is not portable to my other ISP, and so on.
--Bart
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
On Thu, Apr 10, 2014 at 11:29 PM, Bart Kus me@bartk.us wrote:
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.
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.
On 4/11/2014 8:16 AM, Don Fanning wrote:
On Thu, Apr 10, 2014 at 11:29 PM, Bart Kus me@bartk.us wrote:
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.
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
On Fri, Apr 11, 2014 at 8:32 AM, Bart Kus me@bartk.us wrote:
(Please trim inclusions from previous messages) _______________________________________________ On 4/11/2014 8:16 AM, Don Fanning wrote:
On Thu, Apr 10, 2014 at 11:29 PM, Bart Kus me@bartk.us wrote:
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.
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.
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?
-
Bart Kus -
Bjorn Pehrson -
Brian Kantor -
Don Fanning -
Marc, LX1DUC -
Robbie De Lise