On 7/24/13 1:02 PM, Neil Johnson wrote:
I'm a network engineer at another University in the midwest US and I *might* be able to convince our routing guru to let us be a BGP peer and I could setup another tunnel end point box.
I would need explicit details on how this would work and a the potential risks and plans for their mitigation before I approach him.
We don't have earthquakes, just tornados and floods :-)
No promises however.
We have really two networks here. The internal 44-net and the external internet facing net.
I'd propose to have a few points around the globe where we can peer the whole 44 internet facing net. Each of these locations would announce 44/8 and more specific routes for what's close to them.
Behind this in the 44-net internal the gateway routers would be meshed over GRE tunnels running an IGP (IS-IS). There of course would need to be IBGP sessions between all the BGP speakers, but this would allow end user networks to tunnel to a given 44/net router, and not need to keep a full route table of the 44-net internal space. (I hate end stations needing to do routing, that's why we have routers!)
This would provide full access to the 44/net from outside, easy access from the AMPR users, and full visibility between directly routed netblocks and the rest of 44-net with out having to maintain a full mesh.
I'd imagine the more specific announcements from the peering points would be statically configured, but there is a way to do a limited redistribution from the IGP into the BGP. I think it would be easier to do it manually (and more stable), but given some time in the lab at work I could get this going.
Thoughts?
The existing mesh of tunnel routes is no problem to maintain. Setting up the gateway involves setting up the initial encapsulation tunnel routes. Whether that list contains one tunnel or 2 or 200 or 2000 doesn't really matter. In other words, the number of tunnels does not change the configuration complexity.
I certainly don't think it's a good idea to route every internal connection through some centralized gateway somewhere, even if more than one exists. It puts a failure point between me and my destination and it degrades the performance into and out of that gateway. Yes, it increases physical diversity, but it also depends on iBGP and multiple network managers doing the right thing. So removes some failure modes while introducing others. It also makes troubleshooting more of a problem. Today, if I can't reach another gateway, I talk to the person directly. If everything goes through some other point, there's a third location to test with. That would be impractical.
I DO think it's important to have more than one Internet gateway. However, I'm not sure how well JNOS can handle an alternate route. For example, is it able to discover if one of the tunnels is down and switch to the alternate? Can it deal with two equal cost paths or will we need to cost them differently? Currently, we can't even tell if our tunnel to amprgw is up because it won't respond to pings to 44.0.0.1 from another 44.x address.
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 Bryan Fields Sent: Wednesday, July 24, 2013 11:07 AM To: AMPRNet working group Subject: Re: [44net] Distributed BGP Announce
(Please trim inclusions from previous messages) _______________________________________________ On 7/24/13 1:02 PM, Neil Johnson wrote:
I'm a network engineer at another University in the midwest US and I *might* be able to convince our routing guru to let us be a BGP peer and I could setup another tunnel end point box.
I would need explicit details on how this would work and a the potential risks and plans for their mitigation before I approach him.
We don't have earthquakes, just tornados and floods :-)
No promises however.
We have really two networks here. The internal 44-net and the external internet facing net.
I'd propose to have a few points around the globe where we can peer the whole 44 internet facing net. Each of these locations would announce 44/8 and more specific routes for what's close to them.
Behind this in the 44-net internal the gateway routers would be meshed over GRE tunnels running an IGP (IS-IS). There of course would need to be IBGP sessions between all the BGP speakers, but this would allow end user networks to tunnel to a given 44/net router, and not need to keep a full route table of the 44-net internal space. (I hate end stations needing to do routing, that's why we have routers!)
This would provide full access to the 44/net from outside, easy access from the AMPR users, and full visibility between directly routed netblocks and the rest of 44-net with out having to maintain a full mesh.
I'd imagine the more specific announcements from the peering points would be statically configured, but there is a way to do a limited redistribution from the IGP into the BGP. I think it would be easier to do it manually (and more stable), but given some time in the lab at work I could get this going.
Thoughts?
-- 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 http://www.ampr.org/donate.html
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 24/07/2013 20:44, Michael E. Fox - N6MEF wrote:
I certainly don't think it's a good idea to route every internal connection through some centralized gateway somewhere, even if more than one exists. It puts a failure point between me and my destination and it degrades the performance into and out of that gateway. Yes, it increases physical diversity, but it also depends on iBGP and multiple network managers doing the right thing. So removes some failure modes while introducing others. It also makes troubleshooting more of a problem. Today, if I can't reach another gateway, I talk to the person directly. If everything goes through some other point, there's a third location to test with. That would be impractical.
You are absolutely right. Some networks do have the possibility to run the IPIP fullmesh. However you could still benefit from a "local" BGP gateway in terms of access to/from the Internet. For example the subnets for DL, F, G, PA, ON, LX etc could be announced by a gateway in Europe (and via the 44.0.0.0/8 announce as a backup via all the other gateways) and injected in Europe into the IPIP fullmesh.
OTOH some networks cannot connect using the IPIP fullmesh and need to connect using some other tunnel protocol (PPTP, OpenVPN, etc). You could say that those networks are "assisted" networks and they require a "proxy gateway" to connect them to the existing IPIP fullmesh.
These "proxy gateways", if BGP enabled, could announce the local "assisted" networks via BGP and route traffic from the internet directly to the IPIP endpoint or the assisted network and vice versa route traffic from the 44net to the Internet directly via the local upstream provider. That way the proxy gateway wouldn't have to route the non-44net traffic via UCSD. (Btw not every proxy gateway must have to be a BGP gateway.)
This could bring several possible advantages:
- - multiple gateway from 44net to/from internet, resilience - - bandwidth distribution onto several gateways - - latency and possibly bandwidth increase for intra-continental traffic (no real change for North America, but traffic from/to asian 44net to/from asian internet could benefit from a local asian proxy gateway, the same goes for Africa, South America, Europe, etc).
So this discussion is certainly not about replacing the IPIP fullmesh but more about offering additional ways to participate in the IPIP fullmesh.
73 de Marc, LX1DUC
Marc, LX1DUC wrote: For example the subnets for DL, F, G, PA, ON, LX etc could be announced by a gateway in Europe (and via the 44.0.0.0/8 announce as a backup via all the other gateways) and injected in Europe into the IPIP fullmesh.
Are there such gateways in Europe?
I talked to a friend about this and he mentioned that there is one issue with public routing 44/8 network outside USA - intercontinental routing is allocated in such manner that each continent is allocated its IP space and it is not permitted to route networks outside of continents smaller than /8.
If that is the case, then all public gateways for subnets within 44/8 must be located in North America.
I like drawings.
Is this what I gather the concept is ?
https://dl.dropboxusercontent.com/u/11681146/AMPRnet_Concept_V01.pdf
I hope not. It's missing the tunnel between local gateway 1 and local gateway 2. It would be impractical to bounce all traffic through some 3rd location.
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 Neil Johnson Sent: Wednesday, July 24, 2013 3:28 PM To: AMPRNet working group Subject: Re: [44net] Distributed BGP Announce
(Please trim inclusions from previous messages) _______________________________________________ I like drawings.
Is this what I gather the concept is ?
https://dl.dropboxusercontent.com/u/11681146/AMPRnet_Concept_V01.pdf
-- Neil Johnson -N0SFH http://erudicon.com
Umm -- that is how TCP/IP is designed to work. The IP packet may traverse one intermediate or many, to the endpoints the only difference is transit time.
------------------------------ John D. Hays K7VE PO Box 1223, Edmonds, WA 98020-1223 http://k7ve.org/blog http://twitter.com/#!/john_hays http://www.facebook.com/john.d.hays
On Wed, Jul 24, 2013 at 3:33 PM, Michael E. Fox - N6MEF n6mef@mefox.orgwrote:
I hope not. It's missing the tunnel between local gateway 1 and local gateway 2. It would be impractical to bounce all traffic through some 3rd location.
Michael N6MEF
No. It's not.
Obviously, there are multiple routers between me and any other user gateway. But my tunneled traffic goes direct from me to the other end-point via the most direct path. It is not required to go to some third location first, to then be directed back to the destination. For example, my tunneled traffic between my gateway and someone else's gateway does NOT go through amprgw. Only traffic between my gateway and the Internet goes through amprgw. But the diagram shows everything going to a regional gateway. That just adds a point of failure, more latency, probably more jitter, and certainly more complication when it comes to troubleshooting. So it has multiple costs and no benefit (with the exception of performing a proxy-gateway function for what Marc calls "assisted networks").
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 K7VE - John Sent: Wednesday, July 24, 2013 3:57 PM To: AMPRNet working group Subject: Re: [44net] Distributed BGP Announce
(Please trim inclusions from previous messages) _______________________________________________ Umm -- that is how TCP/IP is designed to work. The IP packet may traverse one intermediate or many, to the endpoints the only difference is transit time.
------------------------------ John D. Hays K7VE PO Box 1223, Edmonds, WA 98020-1223 http://k7ve.org/blog http://twitter.com/#!/john_hays http://www.facebook.com/john.d.hays
On Wed, Jul 24, 2013 at 3:33 PM, Michael E. Fox - N6MEF n6mef@mefox.orgwrote:
I hope not. It's missing the tunnel between local gateway 1 and local gateway 2. It would be impractical to bounce all traffic through some 3rd location.
Michael N6MEF
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 25/07/2013 01:17, Michael E. Fox - N6MEF wrote:
(Please trim inclusions from previous messages) _______________________________________________ No. It's not.
Obviously, there are multiple routers between me and any other user gateway. But my tunneled traffic goes direct from me to the other end-point via the most direct path. It is not required to go to some third location first, to then be directed back to the destination. For example, my tunneled traffic between my gateway and someone else's gateway does NOT go through amprgw. Only traffic between my gateway and the Internet goes through amprgw. But the diagram shows everything going to a regional gateway. That just adds a point of failure, more latency, probably more jitter, and certainly more complication when it comes to troubleshooting. So it has multiple costs and no benefit (with the exception of performing a proxy-gateway function for what Marc calls "assisted networks").
I think Neil's diagram wasn't supposed to be complete in every single detail.
Again, this discussion is NOT about dismantling or discontinuing the current IPIP fullmesh.
73 de Marc, LX1DUC
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 25/07/2013 00:33, Michael E. Fox - N6MEF wrote:
I hope not. It's missing the tunnel between local gateway 1 and local gateway 2. It would be impractical to bounce all traffic through some 3rd location.
You're assuming both Local gateways are able to participate directly in the IPIP fullmesh.
If Local Gateway 1 does support the fullmesh but Local Gateway 2 does not, then the traffic will have to go over some upstream gateway.
If both Local Gateways do support the IPIP fullmesh, they will of course be able to exchange traffic directly.
73 de Marc, LX1DUC
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 25/07/2013 00:28, Neil Johnson wrote:
Is this what I gather the concept is ?
Yes the concept is OK. I would bring the protocols used up to discussion before nailing down a final version of the concept.
73 de Marc, LX1DUC
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 25/07/2013 00:08, YT9TP Pedja wrote:
Are there such gateways in Europe?
No this discussion is about setting up gateways outside of the north american continent.
I talked to a friend about this and he mentioned that there is one issue with public routing 44/8 network outside USA - intercontinental routing is allocated in such manner that each continent is allocated its IP space and it is not permitted to route networks outside of continents smaller than /8.
I would call that a myth or eventually a very old pre CIDR concept, otherwise the DFZ wouldn't carry 500k routes. And ANYCAST would be impossible as well.
If that is the case, then all public gateways for subnets within 44/8 must be located in North America.
It's not the case.
73 de Marc, LX1DUC
O.K. Then I think we're on the same page. I certainly think other parts of the country and world can benefit from additional Internet gateways. Heck, even those of us in California can benefit from an additional gateway when the current amprgw has a problem. But a direct tunnel to each remote end-point within AMPRnet, even if it's in another country, is still the most efficient for intra-amprnet communications.
I don't understand the "assisted network" use case. Can you explain and/or provide an example use case for that scenario?
Thanks, 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: Wednesday, July 24, 2013 3:01 PM To: 44net@hamradio.ucsd.edu Subject: Re: [44net] Distributed BGP Announce
OTOH some networks cannot connect using the IPIP fullmesh and need to connect using some other tunnel protocol (PPTP, OpenVPN, etc). You could say that those networks are "assisted" networks and they require a "proxy gateway" to connect them to the existing IPIP fullmesh.
These "proxy gateways", if BGP enabled, could announce the local "assisted" networks via BGP and route traffic from the internet directly to the IPIP endpoint or the assisted network and vice versa route traffic from the 44net to the Internet directly via the local upstream provider. That way the proxy gateway wouldn't have to route the non-44net traffic via UCSD. (Btw not every proxy gateway must have to be a BGP gateway.)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 25/07/2013 00:33, Michael E. Fox - N6MEF wrote:
I don't understand the "assisted network" use case. Can you explain and/or provide an example use case for that scenario?
Sometimes a local network cannot use IPIP to connect to UCSD and the fullmesh. This has been discussed a few times over here, especially the NAT issues.
In that case the local network would connect using a NAT friendly tunnel protocol towards a "proxy" gateway.
The proxy server would provide access towards the IPIP fullmesh to the local network.
In the encap file the IP of the proxy gateway would be listed for the local network.
So instead of
LOCAL_NET <--fullmesh ipip --> 44net
we would have this for some (not all) networks:
LOCAL_NET <--pptp/openvpn--> proxy_gateway <--fullmesh ipip--> 44net
In that setup the proxy gateway would assist the local network to get access to/from the IPIP fullmesh, hence the usage of "assisted network". However it is merely a term to differ between network directly connected to the IPIP fullmesh and those indirectly connected.
73 de Marc, LX1DUC
I have a working diagram and network in production to accommodate connectivity to others. It works very well and is stable and NAT friendly.
I would like to try OSPF over PPTP if I can get any takers to try it out. Contact me off list if interested.
http://www.hindmarsh.cc/images/wc3xs-ampr44.png
Jesse - WC3XS
Sent from my iPhone
On Jul 24, 2013, at 7:09 PM, "Marc, LX1DUC" lx1duc@rlx.lu wrote:
(Please trim inclusions from previous messages) _______________________________________________ -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 25/07/2013 00:33, Michael E. Fox - N6MEF wrote:
I don't understand the "assisted network" use case. Can you explain and/or provide an example use case for that scenario?
Sometimes a local network cannot use IPIP to connect to UCSD and the fullmesh. This has been discussed a few times over here, especially the NAT issues.
In that case the local network would connect using a NAT friendly tunnel protocol towards a "proxy" gateway.
The proxy server would provide access towards the IPIP fullmesh to the local network.
In the encap file the IP of the proxy gateway would be listed for the local network.
So instead of
LOCAL_NET <--fullmesh ipip --> 44net
we would have this for some (not all) networks:
LOCAL_NET <--pptp/openvpn--> proxy_gateway <--fullmesh ipip--> 44net
In that setup the proxy gateway would assist the local network to get access to/from the IPIP fullmesh, hence the usage of "assisted network". However it is merely a term to differ between network directly connected to the IPIP fullmesh and those indirectly connected.
73 de Marc, LX1DUC -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJR8F6tAAoJEHFIN1T8ZA8vPlIP/ikeyYc5M8GOOCbADchCwu5r pndlJKx8WPGnzyGPYcRfCQsJ904QUE+iA4U4B1qOl1BE/Xl21qYIP8iwMBQ9Rt3s Aah/Q2CqA7ZGLsEoiwAMy+QdiCdLpBxsOr8yCT61N/eh63CoBe8zK5K276dskgz6 UfgaCYgD/S2DM50MUw827OaCnDyqAQF8TtqiQRkZJLGrZyKQubxO4w/1NXo+P9FO 3zd32EKiedV14eCEgd+psFPzfk53l1k1wbjdMqxY36hwCiPpRcePROcHDfn9lkpN LWhGbFIvvhcjq3p9a2HQlIWckPWMmavw+hCsa5I0IQOVJHBK37sy1MlTQvBFG1jG ZLhDRgh+FAIbO+P5SLBwl+J7sFM7oMfT4EWBMOPJENEtIHf2M4oZjnzN95YkLnJT Bfjg2CF7v75dVT/JXCBLMl6e+80QYgt84w8PfIJfuvWCtOGM9wghS6kDuTt2lHe9 DpnCvQICPCsbDhSSfgYVT+F9AgE80bDQFc3Kdtw09TLDSobBC90vvh/ddUu5FXBp SM0axYcA5H3lh7VBmpZb7pw3AGtgdfIGLHN7zDwPB9aEqutQ60xrmPuYYcHiulI3 sB7rmgjv7SKraL0Attdq2vv3NI6AtzIi8Mg+O1+57gVU9BhBaxLmhxfR//sf4Cl2 KaZaDAjP5gUfq2fHSE2d =M39Q -----END PGP SIGNATURE----- _________________________________________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net http://www.ampr.org/donate.html
ON is going to be announced through Belnet and a few commercial transit providers soon from multiple geographical locations which are interlinked with 5ghz wifi (nanobridges etc), we are waiting for our AS number. Thanks to sweden for the example with SUNet which made it easier for me to talk to belnet :)
73s Robbie ON4SAX
On Thu, Jul 25, 2013 at 12:00 AM, Marc, LX1DUC lx1duc@rlx.lu wrote:
(Please trim inclusions from previous messages) _______________________________________________ -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 24/07/2013 20:44, Michael E. Fox - N6MEF wrote:
I certainly don't think it's a good idea to route every internal connection through some centralized gateway somewhere, even if more than one exists. It puts a failure point between me and my destination and it degrades the performance into and out of that gateway. Yes, it increases physical diversity, but it also depends on iBGP and multiple network managers doing the right thing. So removes some failure modes while introducing others. It also makes troubleshooting more of a problem. Today, if I can't reach another gateway, I talk to the person directly. If everything goes through some other point, there's a third location to test with. That would be impractical.
You are absolutely right. Some networks do have the possibility to run the IPIP fullmesh. However you could still benefit from a "local" BGP gateway in terms of access to/from the Internet. For example the subnets for DL, F, G, PA, ON, LX etc could be announced by a gateway in Europe (and via the 44.0.0.0/8 announce as a backup via all the other gateways) and injected in Europe into the IPIP fullmesh.
OTOH some networks cannot connect using the IPIP fullmesh and need to connect using some other tunnel protocol (PPTP, OpenVPN, etc). You could say that those networks are "assisted" networks and they require a "proxy gateway" to connect them to the existing IPIP fullmesh.
These "proxy gateways", if BGP enabled, could announce the local "assisted" networks via BGP and route traffic from the internet directly to the IPIP endpoint or the assisted network and vice versa route traffic from the 44net to the Internet directly via the local upstream provider. That way the proxy gateway wouldn't have to route the non-44net traffic via UCSD. (Btw not every proxy gateway must have to be a BGP gateway.)
This could bring several possible advantages:
- multiple gateway from 44net to/from internet, resilience
- bandwidth distribution onto several gateways
- latency and possibly bandwidth increase for intra-continental
traffic (no real change for North America, but traffic from/to asian 44net to/from asian internet could benefit from a local asian proxy gateway, the same goes for Africa, South America, Europe, etc).
So this discussion is certainly not about replacing the IPIP fullmesh but more about offering additional ways to participate in the IPIP fullmesh.
73 de Marc, LX1DUC
-----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJR8E6SAAoJEHFIN1T8ZA8vgskP/1U7LZI0jx1D3BBDNnNvDKAA McgtXjbYmyDKWXvWYGf0CEOYpq2MdCvqggP0GxXm/ytyr+ct/wfNnPTibTXxLc87 B5d7s7mjBZO5p3sv228x+N1G0Kl4g/z9qjZ33ihox0JvPc1aLjmvdX2a753IJXiY CZ5RXe8mPpnNI6eNsDvsYKiikWlZMP8wB9q5OV2Jc20uJcU1YJKsY4yZtVasGIOB CYBtuzptkP+VWFBL+yG408gAGhq0ZZFpGHK2euBhBV02Z1yZGcEuR7EtOfU2NBUc 9uRkRxiGB/5QSk96l5Iz1QSbQLygFXseLa93SS059xC6CK4fQLwuuJYnP0UV5wDo AXDpP2LEjsWkfDWzy/QT1W5UwH9TICO3qEc/FOlxqVSHweBEIvGfTtMEsArtMfwm dhFPqDV1ZypqfjuiDgk1cSc2AXR6n937Q6nL2x60ZcSJ3HYlp0GNFJYaEAm8ung4 LyhHSu+hBHi3oTKBXJvuWWtqX5yLxC0slrelPg1OkZk1FOdoY3oi95yFTuJTntWe oni3JzYhSKd0jBVZ4M2JQlF+61Dy8RJmLMhQoTIdURKOoSnheA8DQ6RDC+h5hUXb G//arx3liGvavN2DK4sfE+LteIbfK0ZnRSXHrZ37BJk6U++Rdva99oaM0W48URDI woar9kCVK4nnGBOyHkfI =awyj -----END PGP SIGNATURE----- _________________________________________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net http://www.ampr.org/donate.html
How would local gateways connect ? A Tunnel(s) to the global gateways ?
I'm trying to imagine explaining to someone how to configure an IGP (especially IS-IS) :-)
-Neil
On Wed, Jul 24, 2013 at 1:06 PM, Bryan Fields Bryan@bryanfields.net wrote:
(Please trim inclusions from previous messages) _______________________________________________ On 7/24/13 1:02 PM, Neil Johnson wrote:
I'm a network engineer at another University in the midwest US and I *might* be able to convince our routing guru to let us be a BGP peer and
I
could setup another tunnel end point box.
I would need explicit details on how this would work and a the potential risks and plans for their mitigation before I approach him.
We don't have earthquakes, just tornados and floods :-)
No promises however.
We have really two networks here. The internal 44-net and the external internet facing net.
I'd propose to have a few points around the globe where we can peer the whole 44 internet facing net. Each of these locations would announce 44/8 and more specific routes for what's close to them.
Behind this in the 44-net internal the gateway routers would be meshed over GRE tunnels running an IGP (IS-IS). There of course would need to be IBGP sessions between all the BGP speakers, but this would allow end user networks to tunnel to a given 44/net router, and not need to keep a full route table of the 44-net internal space. (I hate end stations needing to do routing, that's why we have routers!)
This would provide full access to the 44/net from outside, easy access from the AMPR users, and full visibility between directly routed netblocks and the rest of 44-net with out having to maintain a full mesh.
I'd imagine the more specific announcements from the peering points would be statically configured, but there is a way to do a limited redistribution from the IGP into the BGP. I think it would be easier to do it manually (and more stable), but given some time in the lab at work I could get this going.
Thoughts?
-- 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 http://www.ampr.org/donate.html
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 24/07/2013 22:33, Neil Johnson wrote:
How would local gateways connect ? A Tunnel(s) to the global gateways ?
IPIP if they are capable to do so, otherwise some other tunneling protocol (e.g. PPTP, OpenVPN, etc)
I'm trying to imagine explaining to someone how to configure an IGP (especially IS-IS) :-)
Why should someone need to do so? This discussion is about a limited number of gateways providing IPIP and other methods to join the 44net to national/regional subnets, and announcing the 44.0.0.0/8 via BGP towards the internet.
(BTW IS-IS probably wouldn't work that well over Layer3 tunnels AFAIK, as it is itself a Layer3 protocol and would need to be transported over a Layer2 link (please correct me if I'm wrong))
73 de Marc, LX1DUC
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 25/07/2013 00:15, Marc, LX1DUC wrote:
(BTW IS-IS probably wouldn't work that well over Layer3 tunnels AFAIK, as it is itself a Layer3 protocol and would need to be transported over a Layer2 link (please correct me if I'm wrong))
Has someone done some experiments with BABEL (RFC6126)?
73 de Marc, LX1DUC
-
Bryan Fields -
Jesse Hindmarsh -
K7VE - John -
Marc, LX1DUC -
Michael E. Fox - N6MEF -
Neil Johnson -
Robbie De Lise -
YT9TP Pedja