-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hello,
while analyzing the routing table on my Mikrotik router, I noticed that there are 2 gateways for 44.136.0.0/21:
114.198.116.219 203.5.58.162
The encap file has both as well:
route addprivate 44.136/21 encap 203.5.58.162 route addprivate 44.136/21 encap 114.198.116.219
I have tried to create 2 routes for some of my networks via the portal, but the portal complains with the words "The network overlaps an existing entry".
I'm now interested to know, if these 2 routes are intended to co-exist? If yes, how can one create those entries via the portal. If no, which one is correct and why are there 2 entries?
73 de Marc, LX1DUC
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
On 15 Aug 2013, at 10:31, "Marc, LX1DUC" lx1duc@rlx.lu wrote:
(Please trim inclusions from previous messages) _______________________________________________ -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hello,
while analyzing the routing table on my Mikrotik router, I noticed that there are 2 gateways for 44.136.0.0/21:
114.198.116.219 203.5.58.162
The encap file has both as well:
route addprivate 44.136/21 encap 203.5.58.162 route addprivate 44.136/21 encap 114.198.116.219
I have tried to create 2 routes for some of my networks via the portal, but the portal complains with the words "The network overlaps an existing entry".
I'm now interested to know, if these 2 routes are intended to co-exist? If yes, how can one create those entries via the portal. If no, which one is correct and why are there 2 entries?
73 de Marc, LX1DUC
http://lx1duc.mcs.tel -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJSDJ/oAAoJEHFIN1T8ZA8v8EoP/0HHZn+S4SB0EiqJKjZR8gJG GL7imNQ0sTZUBE6QMQzXs5+Dr6D++jEYyO36AlqgR0Z2SABs/HFhbuHYV+9Bvb+n m01m8eKDFJam3uqXGQjsvV5gH/nC8nVJ0hgdsMolatu8B8WBUR02QQDkgq2u11pP GLwffzANg4/FPLLShYZKk2IL6unh0GFqvW2bePQUZ+8OQv2X1UyDR2jWg4gi7sOO 6imU3CVfKfc53SfPox2De7nLGxsKZsk2O/RCxHEom0MKYCdWtNmoszOTDpxNmkPd cVJfEZ7zOIBHW+ZYFtsCy1GfoanDlel0jOMm5zNe4WkxeCjPtvD/46vxpPOAh2xk 84lDA3oWY2LYKny6c6YD7zFEcHcX84gR+6gdFFvuaiKU99RizFK0XORJxdVqU4tT TSBCCt+oW6sPCAJe2vuorA9TyqLMwc6RDg98ZdoEEAYQJke7/CgTBkP+A6EY/U15 HCWk6cXIvHsu2j33K4HoqoaJa74yZMctTnumMu+E4x2Kw+OtCFJfsNt3dTAqeWkr uuKpeqnjWqPAnT6l3uQOTknwfara79Cw9zWfaG2nnRS8gcIki+Voe+gWAOdiObbF m0dcmsCBqcyFaRtBHyR0N4BuQC/o5H6rQBgzNFDW54EKraRPLokuM9fW6PF1YJ1l +TItkIm+J2u9xwlSJbXq =invI -----END PGP SIGNATURE----- _________________________________________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net http://www.ampr.org/donate.html
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
On 15 Aug 2013, at 10:31, "Marc, LX1DUC" lx1duc@rlx.lu wrote:
(Please trim inclusions from previous messages) _______________________________________________ -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hello,
while analyzing the routing table on my Mikrotik router, I noticed that there are 2 gateways for 44.136.0.0/21:
114.198.116.219 203.5.58.162
The encap file has both as well:
route addprivate 44.136/21 encap 203.5.58.162 route addprivate 44.136/21 encap 114.198.116.219
I have tried to create 2 routes for some of my networks via the portal, but the portal complains with the words "The network overlaps an existing entry".
I'm now interested to know, if these 2 routes are intended to co-exist? If yes, how can one create those entries via the portal. If no, which one is correct and why are there 2 entries?
73 de Marc, LX1DUC
http://lx1duc.mcs.tel -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJSDJ/oAAoJEHFIN1T8ZA8v8EoP/0HHZn+S4SB0EiqJKjZR8gJG GL7imNQ0sTZUBE6QMQzXs5+Dr6D++jEYyO36AlqgR0Z2SABs/HFhbuHYV+9Bvb+n m01m8eKDFJam3uqXGQjsvV5gH/nC8nVJ0hgdsMolatu8B8WBUR02QQDkgq2u11pP GLwffzANg4/FPLLShYZKk2IL6unh0GFqvW2bePQUZ+8OQv2X1UyDR2jWg4gi7sOO 6imU3CVfKfc53SfPox2De7nLGxsKZsk2O/RCxHEom0MKYCdWtNmoszOTDpxNmkPd cVJfEZ7zOIBHW+ZYFtsCy1GfoanDlel0jOMm5zNe4WkxeCjPtvD/46vxpPOAh2xk 84lDA3oWY2LYKny6c6YD7zFEcHcX84gR+6gdFFvuaiKU99RizFK0XORJxdVqU4tT TSBCCt+oW6sPCAJe2vuorA9TyqLMwc6RDg98ZdoEEAYQJke7/CgTBkP+A6EY/U15 HCWk6cXIvHsu2j33K4HoqoaJa74yZMctTnumMu+E4x2Kw+OtCFJfsNt3dTAqeWkr uuKpeqnjWqPAnT6l3uQOTknwfara79Cw9zWfaG2nnRS8gcIki+Voe+gWAOdiObbF m0dcmsCBqcyFaRtBHyR0N4BuQC/o5H6rQBgzNFDW54EKraRPLokuM9fW6PF1YJ1l +TItkIm+J2u9xwlSJbXq =invI -----END PGP SIGNATURE----- _________________________________________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net http://www.ampr.org/donate.html
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net http://www.ampr.org/donate.html
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
No least cost path routing for IP like MX records?
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.
On Thu, Aug 15, 2013 at 10:59:55AM -0400, Charles Hargrove wrote:
No least cost path routing for IP like MX records?
No, because of a fundamental difference. The SMTP protocol is a higher-level one which uses TCP connections which of course have a status of succeeded or not, so if a connection specified by an MX record does not succeed (is refused, etc) the mailer can try an alternate.
IP is much lower level and has no such status: packets are not acknowledged at the IP level so there may be no notification that a packet has not reached its destination. There is no way at the IP level to tell that a particular route isn't working and to therefore try another.
There are proposed mechanisms to allow a choice of routes (RSPF, OSPF, etc), but none of them have been implemented on AMPRNet and the existing encap scheme doesn't allow for them (yet). - Brian
Is there a workaround to this, that would allow a remote site to access net44 directly via it's Internet connection, but fall back on a Microwave link if its Internet failed?
The only solution that I've been able to think of that would work in a timely manner is using an OpenVPN server to handle all my net44 routing. This allows me to use OpenVPN's routing mechanisms to create more advanced networks, but requires a colo machine with costs me about $15 a month.
So far I've been able to get net44 routed into my colo machine (44.4.36.1) and connect up my iPhone and MacBook Pro to that subnet as VPN clients. Routing between those three machines and out to the rest of net44 seems to be working (mostly). I'm a bit stalled out right now until I get my microwave gear in the mail.
Any cheaper solutions out there??
Blaine
Sent from my iPhone
On Aug 15, 2013, at 9:02 AM, Brian Kantor Brian@ucsd.edu wrote:
(Please trim inclusions from previous messages) _______________________________________________ On Thu, Aug 15, 2013 at 10:59:55AM -0400, Charles Hargrove wrote:
No least cost path routing for IP like MX records?
No, because of a fundamental difference. The SMTP protocol is a higher-level one which uses TCP connections which of course have a status of succeeded or not, so if a connection specified by an MX record does not succeed (is refused, etc) the mailer can try an alternate.
IP is much lower level and has no such status: packets are not acknowledged at the IP level so there may be no notification that a packet has not reached its destination. There is no way at the IP level to tell that a particular route isn't working and to therefore try another.
There are proposed mechanisms to allow a choice of routes (RSPF, OSPF, etc), but none of them have been implemented on AMPRNet and the existing encap scheme doesn't allow for them (yet).
- Brian
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net http://www.ampr.org/donate.html
As far as I'm aware, only through BGP. If you have access to a core cisco router, you can do something like
sh ip bgp 1.2.3.4
and see the multiple routes for an address (if they have some).
Regards, Bob
"Charles Hargrove n2nov@n2nov.net says:"
(Please trim inclusions from previous messages) _______________________________________________ No least cost path routing for IP like MX records?
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.
-- Charles J. Hargrove - N2NOV NYC ARECS/RACES Citywide Radio Officer/Skywarn Coord.
You can also use a BGP LookingGlass server via the web and there are MANY of them out there:
http://www.bgp4.as/looking-glasses
I personally find Hurricane Electric's UI the easiest to use, it supports IPv6, etc.
--David
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
-
Blaine Forbort -
Bob Brose -
Bob＠qbjnet.com -
Brian Kantor -
Charles Hargrove -
David Ranch -
Eric Fort -
G1FEF -
Marc, LX1DUC