Eric, Today, the list of tunnels, whether distributed by the encaps file or via RIP, are really just a list of whatever is configured in the portal. Even though they may be distributed by RIP, RIP is being used merely as a distribution mechanism. The existence of an entry in the list tells you nothing about whether that tunnel is actually up or not -- only that it has been configured in the portal. So, even if there were multiple RIP speakers, you'd get the same info except for the main gateway/default route.
What I think you're describing is more like a route reflector such as are used in Internet BGP networks. The clients would identify themselves to the main gateway, and the main gateway would reflect that info back to all other clients. That would provide the dynamic routing that would be helpful. And, if the clients could announce additional routes to the server, we could have dynamic alternate routes. Couple that with regional reflectors and the option to listen to more than one reflector so you can get dynamic default route, and I think we've got something.
The code for BGP route reflectors is public domain, so I wonder if it makes sense to adapt it to RIP.
Michael N6MEF
Sent from my Verizon Wireless 4G LTE smartphone
-------- Original message -------- From: Eric Fort eric.fort@gmail.com Date: 08/27/2013 1:33 AM (GMT-08:00) To: AMPRNet working group 44net@hamradio.ucsd.edu Subject: Re: [44net] Multiple gateways for same route
(Please trim inclusions from previous messages) _______________________________________________ ok, multiple static routes to the same place I can see why not. We do have dynamic routing available to us though via RIP. Would RIP or another routing protocol not handle this in the case of the route being unreliable and drop that route? Why must routes be persistent rather than dynamic? In a larger sense and I realize we're not there yet it would seem that rather than having to know the routes to all other 44net hosts from boot it would be much easier to have each area (for instance each /16 or maybe in some cases each /24) to have a designated router (say at .1) or possibly use multicast to discover one's local router. thus the initial config is simplified as it has a single route to the 44net gateway for it's area from which it may discover via dynamic routing other routes. no more need to manually distribute and update a routing table. This seems to be something to work towards.
On Thu, Aug 15, 2013 at 7:55 AM, Bob@qbjnet.com wrote:
(Please trim inclusions from previous messages) _______________________________________________ No they shouldn't both be allowed. There isn't a way to dynamically choose the route based on whether one or the other connection is up. Packets sent to the down route are simply lost.
Regards, Bob
"Eric Fort eric.fort@gmail.com says:"
(Please trim inclusions from previous messages) _______________________________________________ are these 2 entries for a single route or 2 separate routes to a single destination? It seems to me they are actually separate redundant routes
to
the same /21. should redundant routes not be allowed? It would seem
quite
the reverse that redundancy being useful and importaint these ought to be allowed to stand so long as they are valid routes to the specified /21.
Eric AF6EP
On Thu, Aug 15, 2013 at 2:54 AM, G1FEF chris@g1fef.co.uk wrote:
(Please trim inclusions from previous messages) _______________________________________________ Hi Marc,
No, there should not be two entries for one route and the portal should not allow this to happen, so I will look into how it occurred and
amend the
code as necessary.
Thanks, Chris
-- /~\ The ASCII | Bob Brose N0QBJ \ / Ribbon Campaign | http://www.qbjnet.com/ X Help cure | mailto:bob@qbjnet.com / \ HTML Email | public key at http://www.qbjnet.com/key.html
There are only 10 types of people in the world: Those who understand binary, and those who don't _________________________________________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net http://www.ampr.org/donate.html
The idea of route servers/route reflectors isn't bad at all.
However as some host might connect from dynamic IP addresses you will need to come up with something additional to authenticate the remote gateways.
73 de Marc
Quoting Michael E Fox - N6MEF n6mef@mefox.org:
(Please trim inclusions from previous messages) _______________________________________________ Eric, Today, the list of tunnels, whether distributed by the encaps file or via RIP, are really just a list of whatever is configured in the portal. Even though they may be distributed by RIP, RIP is being used merely as a distribution mechanism. The existence of an entry in the list tells you nothing about whether that tunnel is actually up or not -- only that it has been configured in the portal. So, even if there were multiple RIP speakers, you'd get the same info except for the main gateway/default route.
What I think you're describing is more like a route reflector such as are used in Internet BGP networks. The clients would identify themselves to the main gateway, and the main gateway would reflect that info back to all other clients. That would provide the dynamic routing that would be helpful. And, if the clients could announce additional routes to the server, we could have dynamic alternate routes. Couple that with regional reflectors and the option to listen to more than one reflector so you can get dynamic default route, and I think we've got something.
The code for BGP route reflectors is public domain, so I wonder if it makes sense to adapt it to RIP.
Michael N6MEF
Sent from my Verizon Wireless 4G LTE smartphone
-------- Original message -------- From: Eric Fort eric.fort@gmail.com Date: 08/27/2013 1:33 AM (GMT-08:00) To: AMPRNet working group 44net@hamradio.ucsd.edu Subject: Re: [44net] Multiple gateways for same route
(Please trim inclusions from previous messages) _______________________________________________ ok, multiple static routes to the same place I can see why not. We do have dynamic routing available to us though via RIP. Would RIP or another routing protocol not handle this in the case of the route being unreliable and drop that route? Why must routes be persistent rather than dynamic? In a larger sense and I realize we're not there yet it would seem that rather than having to know the routes to all other 44net hosts from boot it would be much easier to have each area (for instance each /16 or maybe in some cases each /24) to have a designated router (say at .1) or possibly use multicast to discover one's local router. thus the initial config is simplified as it has a single route to the 44net gateway for it's area from which it may discover via dynamic routing other routes. no more need to manually distribute and update a routing table. This seems to be something to work towards.
On Thu, Aug 15, 2013 at 7:55 AM, Bob@qbjnet.com wrote:
(Please trim inclusions from previous messages) _______________________________________________ No they shouldn't both be allowed. There isn't a way to dynamically choose the route based on whether one or the other connection is up. Packets sent to the down route are simply lost.
Regards, Bob
"Eric Fort eric.fort@gmail.com says:"
(Please trim inclusions from previous messages) _______________________________________________ are these 2 entries for a single route or 2 separate routes to a single destination? It seems to me they are actually separate redundant routes
to
the same /21. should redundant routes not be allowed? It would seem
quite
the reverse that redundancy being useful and importaint these ought to be allowed to stand so long as they are valid routes to the specified /21.
Eric AF6EP
On Thu, Aug 15, 2013 at 2:54 AM, G1FEF chris@g1fef.co.uk wrote:
(Please trim inclusions from previous messages) _______________________________________________ Hi Marc,
No, there should not be two entries for one route and the portal should not allow this to happen, so I will look into how it occurred and
amend the
code as necessary.
Thanks, Chris
-- /~\ The ASCII | Bob Brose N0QBJ \ / Ribbon Campaign | http://www.qbjnet.com/ X Help cure | mailto:bob@qbjnet.com / \ HTML Email | public key at http://www.qbjnet.com/key.html
There are only 10 types of people in the world: Those who understand binary, and those who don't _________________________________________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net http://www.ampr.org/donate.html
authenticate the remote gateways by using a tunnel type that includes authentication such as open vpn.
Eric
On Tue, Aug 27, 2013 at 3:17 AM, Marc, LX1DUC lx1duc@rlx.lu wrote:
(Please trim inclusions from previous messages) ______________________________**_________________ The idea of route servers/route reflectors isn't bad at all.
However as some host might connect from dynamic IP addresses you will need to come up with something additional to authenticate the remote gateways.
73 de Marc
Quoting Michael E Fox - N6MEF n6mef@mefox.org:
(Please trim inclusions from previous messages)
______________________________**_________________ Eric, Today, the list of tunnels, whether distributed by the encaps file or via RIP, are really just a list of whatever is configured in the portal. Even though they may be distributed by RIP, RIP is being used merely as a distribution mechanism. The existence of an entry in the list tells you nothing about whether that tunnel is actually up or not -- only that it has been configured in the portal. So, even if there were multiple RIP speakers, you'd get the same info except for the main gateway/default route.
What I think you're describing is more like a route reflector such as are used in Internet BGP networks. The clients would identify themselves to the main gateway, and the main gateway would reflect that info back to all other clients. That would provide the dynamic routing that would be helpful. And, if the clients could announce additional routes to the server, we could have dynamic alternate routes. Couple that with regional reflectors and the option to listen to more than one reflector so you can get dynamic default route, and I think we've got something.
The code for BGP route reflectors is public domain, so I wonder if it makes sense to adapt it to RIP.
Michael N6MEF
Sent from my Verizon Wireless 4G LTE smartphone
-------- Original message -------- From: Eric Fort eric.fort@gmail.com Date: 08/27/2013 1:33 AM (GMT-08:00) To: AMPRNet working group 44net@hamradio.ucsd.edu Subject: Re: [44net] Multiple gateways for same route
(Please trim inclusions from previous messages) ______________________________**_________________ ok, multiple static routes to the same place I can see why not. We do have dynamic routing available to us though via RIP. Would RIP or another routing protocol not handle this in the case of the route being unreliable and drop that route? Why must routes be persistent rather than dynamic? In a larger sense and I realize we're not there yet it would seem that rather than having to know the routes to all other 44net hosts from boot it would be much easier to have each area (for instance each /16 or maybe in some cases each /24) to have a designated router (say at .1) or possibly use multicast to discover one's local router. thus the initial config is simplified as it has a single route to the 44net gateway for it's area from which it may discover via dynamic routing other routes. no more need to manually distribute and update a routing table. This seems to be something to work towards.
On Thu, Aug 15, 2013 at 7:55 AM, Bob@qbjnet.com wrote:
(Please trim inclusions from previous messages)
______________________________**_________________ No they shouldn't both be allowed. There isn't a way to dynamically choose the route based on whether one or the other connection is up. Packets sent to the down route are simply lost.
Regards, Bob
"Eric Fort eric.fort@gmail.com says:"
(Please trim inclusions from previous messages) ______________________________**_________________ are these 2 entries for a single route or 2 separate routes to a single destination? It seems to me they are actually separate redundant
routes to
the same /21. should redundant routes not be allowed? It would seem
quite
the reverse that redundancy being useful and importaint these ought to
be
allowed to stand so long as they are valid routes to the specified /21.
Eric AF6EP
On Thu, Aug 15, 2013 at 2:54 AM, G1FEF chris@g1fef.co.uk wrote:
(Please trim inclusions from previous messages) ______________________________**_________________ Hi Marc,
No, there should not be two entries for one route and the portal
should
not allow this to happen, so I will look into how it occurred and
amend the
code as necessary.
Thanks, Chris
-- /~\ The ASCII | Bob Brose N0QBJ \ / Ribbon Campaign | http://www.qbjnet.com/ X Help cure | mailto:bob@qbjnet.com / \ HTML Email | public key at http://www.qbjnet.com/key.html
There are only 10 types of people in the world: Those who understand binary, and those who don't ______________________________**___________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/**mailman/listinfo/44nethttp://hamradio.ucsd.edu/mailman/listinfo/44net http://www.ampr.org/donate.**html http://www.ampr.org/donate.html
Right. But surely something in the BGP routing authentication mechanisms could also be modified to suite our purposes.
In general, I understand Eric's frustration and I also abhor the use of non-standard/custom stuff. I also understand that amateur radio is about experimentation. But it's amateur "radio", not amateur "internet protocol development". In my mind, exploring and experimenting with how to use standard Internet protocols in new and interesting ways to support radio comms is as far as we should go.
That said, it may be that a standard protocols just don't exist for what we need to do. One thing that creates a problem for us is the "amateur" part. In other words, I am reticent to place too much faith in the next up-stream BBS operator since it's not a business, there are no service level contracts, he/she probably doesn't have an IT staff, and he/she eventually goes on vacation, gets sick, loses interest, has a hot date that night, or whatever. So methods and procedures that work very well in the commercial world don't necessarily work at all in our world.
I know several folks here have expended many more brain cells than I have in order to figure out where to go next. I just hope they keep the focus on amateur *radio* and resist with every fiber of their being the desire to develop additional non-standard protocols. And if it just can't be done any other way, then I would urge a strategy of using existing standard functionality (like the logic and behavior of a BGP route reflector -- if not most of the actual source code) and "porting" it, with as little change as possible. But I do how we actually go somewhere and we're not here on this list 6 months from now having the same conversation again.
Michael N6MEF
-----Original Message----- From: 44net-bounces+n6mef=mefox.org@hamradio.ucsd.edu [mailto:44net-bounces+n6mef=mefox.org@hamradio.ucsd.edu] On Behalf Of Marc, LX1DUC Sent: Tuesday, August 27, 2013 3:17 AM To: 44net@hamradio.ucsd.edu Subject: Re: [44net] Multiple gateways for same route
(Please trim inclusions from previous messages) _______________________________________________ The idea of route servers/route reflectors isn't bad at all.
However as some host might connect from dynamic IP addresses you will need to come up with something additional to authenticate the remote gateways.
73 de Marc
-
Eric Fort -
Marc, LX1DUC -
Michael E Fox - N6MEF -
Michael E. Fox - N6MEF