On 1/3/15, 11:45 AM, Brian wrote:
On Sat, 2015-01-03 at 08:35 -0800, Eric Fort wrote:
how about eliminating this issue perminantly from ever happening and moving to voluntary peering between gateways. Know thy neighbor and be responsible foryourpeers androutesseems to work really well for everyone else yet amprnet still relies upon route distribution from a single source.
Are you suggesting something such as a possible BGPv2 that all gateways or designated regional gateways could perhaps tunnel broadcast between themselves? This would be interesting and may help with other route issues between those using RIPv2 <-> BGP amprnet sites.
Why tunnel at the gateway level?, let the other gateways run BGP. Problem solved.
How you get to the gateway could be IPIP, GRE, IPSEC, or you can run BGP yourself. Or even if you have a friendly peering location that lets you put a dish on the roof.
Treating this like is some kinda special VPN really holds amprnet back.
73's W9CR
I agree with Brian on his statement.
"Treating this like is some kinda special VPN really holds amprnet back.
73's W9CR" --
When i friday tried to get my nodes activated, the portal.ampr.org was down. A real detriment to someone new at this.
73s. Leo, N5JEP On Jan 3, 2015 10:52 AM, "Bryan Fields" Bryan@bryanfields.net wrote:
(Please trim inclusions from previous messages) _______________________________________________ On 1/3/15, 11:45 AM, Brian wrote:
On Sat, 2015-01-03 at 08:35 -0800, Eric Fort wrote:
how about eliminating this issue perminantly from ever happening and moving to voluntary peering between gateways. Know thy neighbor and be responsible foryourpeers androutesseems to work really well for everyone else yet amprnet still relies upon route distribution from a single source.
Are you suggesting something such as a possible BGPv2 that all gateways or designated regional gateways could perhaps tunnel broadcast between themselves? This would be interesting and may help with other route issues between those using RIPv2 <-> BGP amprnet sites.
Why tunnel at the gateway level?, let the other gateways run BGP. Problem solved.
How you get to the gateway could be IPIP, GRE, IPSEC, or you can run BGP yourself. Or even if you have a friendly peering location that lets you put a dish on the roof.
Treating this like is some kinda special VPN really holds amprnet back.
73's W9CR
Bryan Fields
727-409-1194 - Voice 727-214-2508 - Fax http://bryanfields.net _________________________________________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
Hello Bryan;
On Sat, 2015-01-03 at 11:51 -0500, Bryan Fields wrote:
Why tunnel at the gateway level?, let the other gateways run BGP. Problem solved.
Not true. Up here in the NorthEast, for legal reasons, there is not one ISP who will let you broadcast via BGP peer a 44-net block unless UCSD is to relinquish ownership of the block to you and you can provide proof of this. Being a CTO for a few ISPs up here, I know the mentality of corporate lawyers quite well in this regard.
44-net is still viewed upon by many ISPs here to be an experimental network and is considered a liabilty to directly route on their own networks. Unfortunately in a commercial world, the dollar will always win.
This may not be as much an issue in your region so it would be easy to keep blinded to this scenario.
On Sat, 3 Jan 2015, Brian wrote:
On Sat, 2015-01-03 at 11:51 -0500, Bryan Fields wrote:
Why tunnel at the gateway level?, let the other gateways run BGP. Problem solved.
Not true. Up here in the NorthEast, for legal reasons, there is not one ISP who will let you broadcast via BGP peer a 44-net block unless UCSD is to relinquish ownership of the block to you and you can provide proof of this. Being a CTO for a few ISPs up here, I know the mentality of corporate lawyers quite well in this regard.
That's a case for not being allowed to run BGP with your upstream. It doesn't prevent gateway nodes from running BGP between themselves to overcome the inherent static routing limitations of the current 'mesh'.
Regardless, if one wanted to announce a net-44 block to their upstream, the mechanism to do so exists. UCSD (or rather AMPRNet) doesn't relinquish 'ownership' any more than would say ARIN to one of its members. And yet ARIN members and their customers and customers of those customers peer with each other all the time.
Antonio Querubin e-mail: tony@lavanauts.org xmpp: antonioquerubin@gmail.com
-
Antonio Querubin -
Brian -
Bryan Fields -
Rosalio Salas