Subject: Re: [44net] Strange Broadcasts... From: Bryan Fields Bryan@bryanfields.net Date: 06/13/2015 09:40 AM
To: AMPRNet working group 44net@hamradio.ucsd.edu
I agree, however the configuration of a single gateway announcing 44/8 without the ability to reach more specific networks is_broken_ routing. Let me say this again:
_The UCSD Gateway has BROKEN ROUTING affecting the REACHABILITY of IPIP users._
If BGP users announce a subnet that 99.99999% of the internet can see, but IPIP users behind the UCSD gateway can't reach it, it's not BGP users that have broken routing, it's the silly UCSD gateway.
This is INCORRECT, it is actually your own system that is broken. When you put up a system that announces a BGP route on Internet, you should also make that system part of the IPIP mesh for the same subnet that you advertise on BGP.
Then, those that want to reach you on IPIP do not need to go via the UCSD gateway but can directly reach you on IPIP. Remember IPIP is a mesh, there is no "central gateway" other than that it has the largest subnet and attracts all traffic that is not otherwise routed.
Routing the IPIP traffic is your own responsibility, don't shift it to UCSD or Brian.
Rob
Rob Janssen wrote:
When you put up a system that announces a BGP route on Internet, you should also make that system part of the IPIP mesh for the same subnet that you advertise on BGP.
... with a tunnel endpoint address that is OUTSIDE network 44.0.0.0/8
Rob
Rob,
Thank you for making my point. The reason you can’t use a 44/8 address for a tunnel endpoint is because routing is broken.
Nigel
On Jun 13, 2015, at 12:24, Rob Janssen pe1chl@amsat.org wrote:
(Please trim inclusions from previous messages) _______________________________________________ Rob Janssen wrote:
When you put up a system that announces a BGP route on Internet, you should also make that system part of the IPIP mesh for the same subnet that you advertise on BGP.
... with a tunnel endpoint address that is OUTSIDE network 44.0.0.0/8
Rob
Alright, let's take this a different route.
What would it take to make IPIP mesh more robust?
If BGP capable nodes were to announce and route for IPIP endpoints within it's endpoint, that would remove the SPOF at UCSD. IPIP would also get the benefit of possibly routing EIGRP between IPIP mesh sites so that if one BGP route were to have catastrophic failure, another BGP announced route would already be announced and EIGRP would route to that end point. Would mean a bit more traffic over RF reliant upstream networks but I think we have the technology for that.
The software package tinc does a fine job of creating dynamic self polling mesh vpn networks (example: CCC ChaosNET). If you were to employ the quagga suite on top of that, you could preference out your routes among the tinc endpoints. BGP would announce that the end point is available at whatever depending on the highest quality of the EIGRP link.
http://blog.ine.com/2009/05/01/understanding-unequal-cost-load-balancing/
On Sat, Jun 13, 2015 at 12:30 PM, Nigel Vander Houwen nigel@k7nvh.com wrote:
(Please trim inclusions from previous messages) _______________________________________________ Rob,
Thank you for making my point. The reason you can’t use a 44/8 address for a tunnel endpoint is because routing is broken.
Nigel
On Jun 13, 2015, at 12:24, Rob Janssen pe1chl@amsat.org wrote:
(Please trim inclusions from previous messages) _______________________________________________ Rob Janssen wrote:
When you put up a system that announces a BGP route on Internet, you
should also make
that system part of the IPIP mesh for the same subnet that you
advertise on BGP.
... with a tunnel endpoint address that is OUTSIDE network 44.0.0.0/8
Rob
The IPIP mesh doesn't have a single point of failure. Sites on the mesh can talk to each other quite happily without UCSD. Only access from non-44 internet addresses and from those who like to play at being an ISP is lost, and I'm quite happy without either.
But then I'm a radio ham first and foremost, not someone trying to show how clever I am at IP networking.
73, John G8BPQ
-----Original Message----- From: 44net-bounces+john.wiseman=cantab.net@hamradio.ucsd.edu [mailto:44net-bounces+john.wiseman=cantab.net@hamradio.ucsd.edu] On Behalf Of Don Fanning Sent: 13 June 2015 21:06 To: AMPRNet working group Subject: Re: [44net] Strange Broadcasts...
(Please trim inclusions from previous messages) _______________________________________________ Alright, let's take this a different route.
What would it take to make IPIP mesh more robust?
If BGP capable nodes were to announce and route for IPIP endpoints within it's endpoint, that would remove the SPOF at UCSD. IPIP would also get the benefit of possibly routing EIGRP between IPIP mesh sites so that if one BGP route were to have catastrophic failure, another BGP announced route would already be announced and EIGRP would route to that end point. Would mean a bit more traffic over RF reliant upstream networks but I think we have the technology for that.
The software package tinc does a fine job of creating dynamic self polling mesh vpn networks (example: CCC ChaosNET). If you were to employ the quagga suite on top of that, you could preference out your routes among the tinc endpoints. BGP would announce that the end point is available at whatever depending on the highest quality of the EIGRP link.
http://blog.ine.com/2009/05/01/understanding-unequal-cost-load-balancing/
On Sat, Jun 13, 2015 at 12:30 PM, Nigel Vander Houwen nigel@k7nvh.com wrote:
(Please trim inclusions from previous messages) _______________________________________________ Rob,
Thank you for making my point. The reason you can't use a 44/8 address for a tunnel endpoint is because routing is broken.
Nigel
On Jun 13, 2015, at 12:24, Rob Janssen pe1chl@amsat.org wrote:
(Please trim inclusions from previous messages) _______________________________________________ Rob Janssen wrote:
When you put up a system that announces a BGP route on Internet, you
should also make
that system part of the IPIP mesh for the same subnet that you
advertise on BGP.
... with a tunnel endpoint address that is OUTSIDE network 44.0.0.0/8
Rob
Makes complete sense. EIGRP would work well then in having multiple non-44net end points for 44-net traffic. It's costing by the lowest latency. So if for some reason the path to one BGP gateway is higher, it would automatically route to a lower latency BGP gateway. How you route between other IPIP endpoints would be entirely up to you.
On Sat, Jun 13, 2015 at 1:19 PM, John Wiseman john.wiseman@cantab.net wrote:
(Please trim inclusions from previous messages) _______________________________________________ The IPIP mesh doesn't have a single point of failure. Sites on the mesh can talk to each other quite happily without UCSD. Only access from non-44 internet addresses and from those who like to play at being an ISP is lost, and I'm quite happy without either.
But then I'm a radio ham first and foremost, not someone trying to show how clever I am at IP networking.
73, John G8BPQ
-----Original Message----- From: 44net-bounces+john.wiseman=cantab.net@hamradio.ucsd.edu [mailto:44net-bounces+john.wiseman=cantab.net@hamradio.ucsd.edu] On Behalf Of Don Fanning Sent: 13 June 2015 21:06 To: AMPRNet working group Subject: Re: [44net] Strange Broadcasts...
(Please trim inclusions from previous messages) _______________________________________________ Alright, let's take this a different route.
What would it take to make IPIP mesh more robust?
If BGP capable nodes were to announce and route for IPIP endpoints within it's endpoint, that would remove the SPOF at UCSD. IPIP would also get the benefit of possibly routing EIGRP between IPIP mesh sites so that if one BGP route were to have catastrophic failure, another BGP announced route would already be announced and EIGRP would route to that end point. Would mean a bit more traffic over RF reliant upstream networks but I think we have the technology for that.
The software package tinc does a fine job of creating dynamic self polling mesh vpn networks (example: CCC ChaosNET). If you were to employ the quagga suite on top of that, you could preference out your routes among the tinc endpoints. BGP would announce that the end point is available at whatever depending on the highest quality of the EIGRP link.
http://blog.ine.com/2009/05/01/understanding-unequal-cost-load-balancing/
On Sat, Jun 13, 2015 at 12:30 PM, Nigel Vander Houwen nigel@k7nvh.com wrote:
(Please trim inclusions from previous messages) _______________________________________________ Rob,
Thank you for making my point. The reason you can't use a 44/8 address
for
a tunnel endpoint is because routing is broken.
Nigel
On Jun 13, 2015, at 12:24, Rob Janssen pe1chl@amsat.org wrote:
(Please trim inclusions from previous messages) _______________________________________________ Rob Janssen wrote:
When you put up a system that announces a BGP route on Internet, you
should also make
that system part of the IPIP mesh for the same subnet that you
advertise on BGP.
... with a tunnel endpoint address that is OUTSIDE network 44.0.0.0/8
Rob
Also by using EIGRP, non-44net traffic wouldn't incur routing loops for traffic coming in.
On Sat, Jun 13, 2015 at 1:27 PM, Don Fanning don@00100100.net wrote:
Makes complete sense. EIGRP would work well then in having multiple non-44net end points for 44-net traffic. It's costing by the lowest latency. So if for some reason the path to one BGP gateway is higher, it would automatically route to a lower latency BGP gateway. How you route between other IPIP endpoints would be entirely up to you.
On Sat, Jun 13, 2015 at 1:19 PM, John Wiseman john.wiseman@cantab.net wrote:
(Please trim inclusions from previous messages) _______________________________________________ The IPIP mesh doesn't have a single point of failure. Sites on the mesh can talk to each other quite happily without UCSD. Only access from non-44 internet addresses and from those who like to play at being an ISP is lost, and I'm quite happy without either.
But then I'm a radio ham first and foremost, not someone trying to show how clever I am at IP networking.
If you were to have an IPIP link that for some reason the route between ISP-A and ISP-B were terrible/dead, you could delete that route from ripd (or set a higher cost on it) and it would go to the default route, into EIGRP and find a better way to route to that subnet.
On Sat, Jun 13, 2015 at 1:31 PM, Don Fanning don@00100100.net wrote:
Also by using EIGRP, non-44net traffic wouldn't incur routing loops for traffic coming in.
On Sat, Jun 13, 2015 at 1:27 PM, Don Fanning don@00100100.net wrote:
Makes complete sense. EIGRP would work well then in having multiple non-44net end points for 44-net traffic. It's costing by the lowest latency. So if for some reason the path to one BGP gateway is higher, it would automatically route to a lower latency BGP gateway. How you route between other IPIP endpoints would be entirely up to you.
On Sat, Jun 13, 2015 at 1:19 PM, John Wiseman john.wiseman@cantab.net wrote:
(Please trim inclusions from previous messages) _______________________________________________ The IPIP mesh doesn't have a single point of failure. Sites on the mesh can talk to each other quite happily without UCSD. Only access from non-44 internet addresses and from those who like to play at being an ISP is lost, and I'm quite happy without either.
But then I'm a radio ham first and foremost, not someone trying to show how clever I am at IP networking.
I have such a setup using a direct L2TP to DL and a PPtP to LX, running BGP over it (with private AS numbers). If this primary link fails, traffic switches to IPIP automatically. This was set up as a proof of concept and remained that way.
Anyone available to set up a triangle IPIP with BGP over it to check the concept?
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 Don Fanning Sent: Saturday, June 13, 2015 23:27 To: AMPRNet working group Subject: Re: [44net] Strange Broadcasts...
(Please trim inclusions from previous messages) _______________________________________________ Makes complete sense. EIGRP would work well then in having multiple non-44net end points for 44-net traffic. It's costing by the lowest latency. So if for some reason the path to one BGP gateway is higher, it would automatically route to a lower latency BGP gateway. How you route between other IPIP endpoints would be entirely up to you.
How does DL and LX figure out which is the better route for your traffic? BGP just says your there and to send me traffic.
EIGRP could talk between DL and LX and say, "I'm a faster route for YO2LOJ, make me the preference for traffic coming in."
It would also allow you to load balance your traffic between DL and LX rather than having a fail over route and the time incurred by everyone sending BGP announcements during the shuffle of routes.
On Sat, Jun 13, 2015 at 1:50 PM, Marius Petrescu marius@yo2loj.ro wrote:
(Please trim inclusions from previous messages) _______________________________________________ I have such a setup using a direct L2TP to DL and a PPtP to LX, running BGP over it (with private AS numbers). If this primary link fails, traffic switches to IPIP automatically. This was set up as a proof of concept and remained that way.
Anyone available to set up a triangle IPIP with BGP over it to check the concept?
Marius, YO2LOJ
Since the 2 tunnels are actually similar in speed and latency with the IPIP link, there is no route selection. If the VPNs are up, traffic will go that way. If the interface fails, IPIP is used as a fallback solution. That's all, no EIGRP involved. Just a small step...
-----Original Message----- From: 44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu [mailto:44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu] On Behalf Of Don Fanning Sent: Sunday, June 14, 2015 00:13 To: AMPRNet working group Subject: Re: [44net] Strange Broadcasts...
(Please trim inclusions from previous messages) _______________________________________________ How does DL and LX figure out which is the better route for your traffic? BGP just says your there and to send me traffic.
EIGRP could talk between DL and LX and say, "I'm a faster route for YO2LOJ, make me the preference for traffic coming in."
It would also allow you to load balance your traffic between DL and LX rather than having a fail over route and the time incurred by everyone sending BGP announcements during the shuffle of routes.
On Sat, Jun 13, 2015 at 1:50 PM, Marius Petrescu marius@yo2loj.ro wrote:
(Please trim inclusions from previous messages) _______________________________________________ I have such a setup using a direct L2TP to DL and a PPtP to LX, running
BGP
over it (with private AS numbers). If this primary link fails, traffic switches to IPIP automatically. This was set up as a proof of concept and remained that way.
...
So what you've done is replace IPIP with VPN (pptp/l2tp) as the primary circuits with IPIP as the fall back.
You still have dropped packets while DL and LX converge their routing tables should one of those sites go down. If both sites go down, then you'll fail back to IPIP. Worse case scenario, sure. But not the most efficient or elegant solution. You would then lose traffic during that BGP convergence coming between non-44 and 44net. If you're doing repeater linking over 44net, those are lost conversations.
On Sat, Jun 13, 2015 at 2:20 PM, Marius Petrescu marius@yo2loj.ro wrote:
(Please trim inclusions from previous messages) _______________________________________________ Since the 2 tunnels are actually similar in speed and latency with the IPIP link, there is no route selection. If the VPNs are up, traffic will go that way. If the interface fails, IPIP is used as a fallback solution. That's all, no EIGRP involved. Just a small step...
On 6/13/15 4:05 PM, Don Fanning wrote:
IPIP would also get the benefit of possibly routing EIGRP between IPIP mesh sites so that if one BGP route were to have catastrophic failure, another BGP announced route would already be announced and EIGRP would route to that end point.
This is a joke, correct?
You're proposing fixing broken routing using a non-standard protocol. IIRC EIGRP uses IP multicast for announcements (same as OSPF) so you'd need to run it over some sort of tunnel (gre) interface anyways.
Just use BGP with a private AS up to the edge Internet connected BGP nodes if you're building tunnels.
Tim Osburn and myself (and others) had proposed standards based way to move the IPIP tunnels to a redundant gateway design a few years back. It's not hard, but there is no movement from ARDC to actually move forward with it. I'd be happy with a study of proposed ideas, at least it's forward movement.
On Sat, Jun 13, 2015 at 2:59 PM, Bryan Fields Bryan@bryanfields.net wrote:
This is a joke, correct?
For someone who's on the ARDC technical committee, you seem to be pretty apt at shooting down solutions rather than implementing them.
You're proposing fixing broken routing using a non-standard protocol. IIRC EIGRP uses IP multicast for announcements (same as OSPF) so you'd need to run it over some sort of tunnel (gre) interface anyways.
Yes. And you're also not the boss of my subnet either. How else do you proposed routing non-44net traffic into 44net without creating routing loops and without breaking the current infrastructure on a global scale?
Just use BGP with a private AS up to the edge Internet connected BGP nodes if you're building tunnels.
People already have tunnels. I'm talking about delivering traffic.
Tim Osburn and myself (and others) had proposed standards based way to move the IPIP tunnels to a redundant gateway design a few years back. It's not hard, but there is no movement from ARDC to actually move forward with it. I'd be happy with a study of proposed ideas, at least it's forward movement.
Code or it didn't happen. Oh wait, spec isn't code.
On 6/13/15 6:09 PM, Don Fanning wrote:
For someone who's on the ARDC technical committee, you seem to be pretty apt at shooting down solutions rather than implementing them.
If they are good ideas I'm open to consider them. EIGRP ties you to one vendor (cisco), and frankly they suck :)
I'm not going to argue well established policies/BCPs.
You're proposing fixing broken routing using a non-standard protocol. IIRC EIGRP uses IP multicast for announcements (same as OSPF) so you'd need to run it over some sort of tunnel (gre) interface anyways.
Yes. And you're also not the boss of my subnet either. How else do you proposed routing non-44net traffic into 44net without creating routing loops and without breaking the current infrastructure on a global scale?
You're subnet is your business. We are talking about the UCSD gw not being able to reach anyone using BGP to announce their subnet to the global routing table.
Tim Osburn and myself (and others) had proposed standards based way to move the IPIP tunnels to a redundant gateway design a few years back. It's not hard, but there is no movement from ARDC to actually move forward with it. I'd be happy with a study of proposed ideas, at least it's forward movement.
Code or it didn't happen. Oh wait, spec isn't code.
Now you're just being a jerk.
Spec is all that's needed. Code means we're developing something that's non-standard, and means no router vendor will support it.
When I get a feature implemented in TiMOS there needs to be a business case for it. Every vendor is like this, and unfortunately AMPRnet users have no pull to get a protocol implemented.
73's W9CR
On Sat, Jun 13, 2015 at 3:29 PM, Bryan Fields Bryan@bryanfields.net wrote:
(Please trim inclusions from previous messages) _______________________________________________ On 6/13/15 6:09 PM, Don Fanning wrote:
For someone who's on the ARDC technical committee, you seem to be pretty apt at shooting down solutions rather than implementing them.
If they are good ideas I'm open to consider them. EIGRP ties you to one vendor (cisco), and frankly they suck :)
https://github.com/janovic/Quagga-EIGRP - you were saying?
I'm not going to argue well established policies/BCPs.
At least you'd be able to explain your position rather than be a lid about it all.
You're proposing fixing broken routing using a non-standard
protocol. IIRC
EIGRP uses IP multicast for announcements (same as OSPF) so you'd
need to
run it over some sort of tunnel (gre) interface anyways.
Yes. And you're also not the boss of my subnet either. How else do you proposed routing non-44net traffic into 44net without creating routing loops and without breaking the current infrastructure on a global scale?
You're subnet is your business. We are talking about the UCSD gw not being able to reach anyone using BGP to announce their subnet to the global routing table.
And a solution for it. If you got a better one, by all means speak.
Tim Osburn and myself (and others) had proposed standards based way
to move
the IPIP tunnels to a redundant gateway design a few years back.
It's not
hard, but there is no movement from ARDC to actually move forward
with it.
I'd be happy with a study of proposed ideas, at least it's forward movement.
Code or it didn't happen. Oh wait, spec isn't code.
Now you're just being a jerk.
You first.
Spec is all that's needed. Code means we're developing something that's non-standard, and means no router vendor will support it.
Yeah, and spec never stopped a developer from not following it or doing their own thing. Don't believe me? Ask Microsoft, Google or any other company. I don't have to cater to your chosen network vendor, I can create my own. Standards make sure that there is interoperability within guidelines. And as I recall, EIGRP is a standard.
When I get a feature implemented in TiMOS there needs to be a business case for it. Every vendor is like this, and unfortunately AMPRnet users have no pull to get a protocol implemented.
Which is why developers and system engineers every day develop around network issues. Just because you have good pipes, doesn't mean that you won't end up with shit on you. Websockets is a perfect example of getting around limitations of the network. P2P mesh was the invention of creating ad-hoc networks without centralized end points. Just because you don't have vendor support doesn't mean you should abandon something. It just means your original enough to build a solution for your needs.
On 6/13/15 6:43 PM, Don Fanning wrote:
If they are good ideas I'm open to consider them. EIGRP ties you to one vendor (cisco), and frankly they suck :)
https://github.com/janovic/Quagga-EIGRP - you were saying?
That's not a router vendor.
We are talking about the UCSD gw not being able to reach anyone using BGP to announce their subnet to the global routing table.
And a solution for it. If you got a better one, by all means speak.
I have, but one must be willing to listen. The problem with the UCSD gateway routing not working with more specific announcements.
Spec is all that's needed. Code means we're developing something that's non-standard, and means no router vendor will support it.
Yeah, and spec never stopped a developer from not following it or doing their own thing. Don't believe me? Ask Microsoft, Google or any other company. I don't have to cater to your chosen network vendor, I can create my own. Standards make sure that there is interoperability within guidelines. And as I recall, EIGRP is a standard.
Are we really arguing about EIRGP being an open standard?
No it's not a standard. It's an informational draft, not an standards track RFC. The draft is dead at the IETF. Cisco retains full control over it, and the patents surrounding DUAL. Secondly its not a full implementation of EIGRP, stub areas are not documented.
https://www.ietf.org/archive/id/draft-savage-eigrp-02.txt
I have on good authority the companies you cited are not re-inventing the wheel. They may develop standards and then ask that we (network vendors) support them, but they don't make their own one off protocols. Case in point, segment routing.
When I get a feature implemented in TiMOS there needs to be a business case for it. Every vendor is like this, and unfortunately AMPRnet users have no pull to get a protocol implemented.
Which is why developers and system engineers every day develop around network issues.
*plonk* I'm out.
On Sat, Jun 13, 2015 at 4:07 PM, Bryan Fields Bryan@bryanfields.net wrote:
(Please trim inclusions from previous messages) _______________________________________________ On 6/13/15 6:43 PM, Don Fanning wrote:
If they are good ideas I'm open to consider them. EIGRP ties you to one vendor (cisco), and frankly they suck :)
https://github.com/janovic/Quagga-EIGRP - you were saying?
That's not a router vendor.
I'm not trying to buy a vendor. I'm trying to route packets. Leave your CFP's in my work email.
We are talking about the UCSD gw not being able to reach anyone using BGP to announce their subnet to the global routing table.
And a solution for it. If you got a better one, by all means speak.
I have, but one must be willing to listen. The problem with the UCSD gateway routing not working with more specific announcements.
If BGP announced subnets were to IGP between each other announcements from one another and UCSD, I don't see how there would be a problem.
Spec is all that's needed. Code means we're developing something that's non-standard, and means no router vendor will support it.
Yeah, and spec never stopped a developer from not following it or doing their own thing. Don't believe me? Ask Microsoft, Google or any other company. I don't have to cater to your chosen network vendor, I can
create
my own. Standards make sure that there is interoperability within guidelines. And as I recall, EIGRP is a standard.
Are we really arguing about EIRGP being an open standard?
No it's not a standard. It's an informational draft, not an standards track RFC. The draft is dead at the IETF. Cisco retains full control over it, and the patents surrounding DUAL. Secondly its not a full implementation of EIGRP, stub areas are not documented.
The protocol was designed by Cisco Systems https://en.wikipedia.org/wiki/Cisco_Systems as a proprietary protocol, available only on Cisco routers, but Cisco converted it to an open standard in 2013. https://en.wikipedia.org/wiki/Enhanced_Interior_Gateway_Routing_Protocol
I won't fault you for having out of date knowledge... it's only been 2 years.
Use OSPF for stubs. It's much more suited and better documented.
I have on good authority the companies you cited are not re-inventing the wheel. They may develop standards and then ask that we (network vendors) support them, but they don't make their own one off protocols. Case in point, segment routing.
Segment routing is a fix for a network management problem. Not an application or systems problem.
Again, people can always just stick with IPIP and leave you out of the loop. Or just choose not to peer to your IGP and not have you announce their subnets.
On 14 Jun 2015, at 12:29 AM, Bryan Fields Bryan@bryanfields.net wrote:
Spec is all that's needed. Code means we're developing something that's non-standard, and means no router vendor will support it.
When I get a feature implemented in TiMOS there needs to be a business case for it. Every vendor is like this, and unfortunately AMPRnet users have no pull to get a protocol implemented.
Yes, this is how it was for >20 years but it seems to be changing rapidly. By separating the routing logic from the device intended to forward the packets, we can (re-)invent protocols and use OpenFlow to make it work with existing equipment. You can't hack a custom AMPRNet protocol into Mikrotik RouterOS? No problem... it does OpenFlow switching too.
I would say that in future the situation will be reversed - vendors will *only* support the protocols once they are proven to work by "rough consensus and running code" (probably by incorporating that very same code into their products). It is an exciting time for networking, and seems like something hams should pounce on...
On 13 Jun 2015, at 11:59 PM, Bryan Fields bryan@bryanfields.net wrote:
Tim Osburn and myself (and others) had proposed standards based way to move the IPIP tunnels to a redundant gateway design a few years back. It's not hard, but there is no movement from ARDC to actually move forward with it. I'd be happy with a study of proposed ideas, at least it's forward movement.
Did you consider a /24 allocated for the purpose of anycast tunnel endpoints? Each BGP gateway could announce it alongside the 44/8 routes.
This is how 6to4 (IPv6 Internet-overlay tunnelling) works...
Simeon,
This exactly what the HamWAN project has done, but it still runs into issues for users that have a 44/8 default route to UCSD, and it can’t be routed to us even though it’s not in the encap.
Nigel
On Jun 13, 2015, at 15:20, Simeon Miteff simeon.miteff@gmail.com wrote:
(Please trim inclusions from previous messages) _______________________________________________
On 13 Jun 2015, at 11:59 PM, Bryan Fields bryan@bryanfields.net wrote:
Tim Osburn and myself (and others) had proposed standards based way to move the IPIP tunnels to a redundant gateway design a few years back. It's not hard, but there is no movement from ARDC to actually move forward with it. I'd be happy with a study of proposed ideas, at least it's forward movement.
Did you consider a /24 allocated for the purpose of anycast tunnel endpoints? Each BGP gateway could announce it alongside the 44/8 routes.
This is how 6to4 (IPv6 Internet-overlay tunnelling) works...
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
On 14 Jun 2015, at 12:27 AM, Nigel Vander Houwen nigel@k7nvh.com wrote:
This exactly what the HamWAN project has done, but it still runs into issues for users that have a 44/8 default route to UCSD, and it can’t be routed to us even though it’s not in the encap.
Ah-hah!
Thanks to your hint, I've just found this: https://www.hamwan.org/t/AMPRNet?structure=HamWAN
I note the first red block... for a newbie trying to understand the current flame wa^H^H^H^H^H^H^H^Hlively discussion, this adds some context :-)
No, because you can not have the tunnel endpoint inside its own IP subnet, which is not accessible yet because the route does not exist yet.
You can actually have the endpoint on a BGP announced subnet which is not in the IPIP tunnel list AND not inside the subnet you want to reach AND accepts IPIP connections from non-44 addresses.
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: Saturday, June 13, 2015 22:30 To: AMPRNet working group Subject: Re: [44net] Strange Broadcasts...
(Please trim inclusions from previous messages) _______________________________________________ Rob,
Thank you for making my point. The reason you can't use a 44/8 address for a tunnel endpoint is because routing is broken.
Nigel
On Jun 13, 2015, at 12:24, Rob Janssen pe1chl@amsat.org wrote:
... with a tunnel endpoint address that is OUTSIDE network 44.0.0.0/8
Rob
-
Bryan Fields -
Don Fanning -
John Wiseman -
Marius Petrescu -
Nigel Vander Houwen -
Rob Janssen -
Simeon Miteff