On 4/24/14, 6:54 PM, K7VE - John wrote:
I think the better model is BGP "nodes" which provide VPN to subnets. The BGP node admins would provide the VPN authentication to know what subnets were attaching and BGP would provide Internet connectivity (including subnets).
+1
I trust my VPN users and announce via BGP to the global routing table. If you want to trust my routes cool, if not that's cool too.
I think everyone is over-thinking this. It does no good if the majority of traffic over 44net allocations is ping and traceroute. Let shit flow and see what happens.
IF some one starts abusing it, shut it down and fix it. It's like a repeater when there is a jammer. Once you're aware of it, you shut it down till they go away and you're not liable for it.
I'm of the opinion that it should be kept the simplest possible and let people deal with their own networks. Give the people the basics needed to create a connection and get the routes. Then if they want to block people, they can add a static route dropping them or a firewall rule.
I feel BGP over GRE or DMVPN is overkill as beyond the extra functionality of GRE being able to do multicast and other kinds of traffic, there is no added value to what we already have with IPIP and RIP44d/encap. Within 44net, it's a different story - go RIP/OSPF and IPSec for all I care. But setting up tunnels should be kept simplistic.
You wouldn't do BGP over tunnels. BGP is for the "border" nodes, e.g. those nodes which connect the pieces of 44 into the Internet. If you want to use IPIP behind the BGP, or GRE, L2TP, within your subnets, nobody should care -- but this every node has an "encap.txt" file is, IMHO, crazy.
BGP node provides endpoint for tunnels (VPN, IPIP, etc.) subnet nodes connect to the BGP node via tunnel, the BGP node routes to the rest of 44.x.x.x and the Internet.
Then the simple node is easy.
Who is my BGP border node? How do I VPN to it? Set up VPN (or Tunnel) to it. Done.
________________________________ John D. Hays K7VE PO Box 1223, Edmonds, WA 98020-1223
On Thu, Apr 24, 2014 at 4:24 PM, Don Fanning don@00100100.net wrote:
(Please trim inclusions from previous messages) _______________________________________________ I'm of the opinion that it should be kept the simplest possible and let people deal with their own networks. Give the people the basics needed to create a connection and get the routes. Then if they want to block people, they can add a static route dropping them or a firewall rule.
I feel BGP over GRE or DMVPN is overkill as beyond the extra functionality of GRE being able to do multicast and other kinds of traffic, there is no added value to what we already have with IPIP and RIP44d/encap. Within 44net, it's a different story - go RIP/OSPF and IPSec for all I care. But setting up tunnels should be kept simplistic.
BGP is for the "border" nodes, e.g. those nodes which connect the pieces of 44 into the Internet. If you want to use IPIP behind the BGP, or GRE, L2TP, within your subnets, nobody should care -- but this every node has an "encap.txt" file is, IMHO, crazy.
ONTH - it provides a layer of robustness and redundancy...
BGP node provides endpoint for tunnels (VPN, IPIP, etc.) subnet nodes connect to the BGP node via tunnel, the BGP node routes to the rest of 44.x.x.x and the Internet.
Then the simple node is easy.
Who is my BGP border node? How do I VPN to it? Set up VPN (or Tunnel) to it. Done.
If the BGP border node is gone - then what is the back up process????
It would be good to take the IPIP scheme to the next layer with some local RIP announcements by node-gateways. That would make things more dynamic than the static encap file.
Bill, WA7NWP
You would still need to have at least one "master" tunnel to be able to get the VPN information to form tunnels. All DMVPN connections have one dedicated link to a "hub" router. Which means having to keep a fleet of machines (assuming you don't want a SPOF) that will act as the "master" routers serving all the "spoke" routers.
On Thu, Apr 24, 2014 at 4:32 PM, K7VE - John k7ve@k7ve.org wrote:
(Please trim inclusions from previous messages) _______________________________________________ You wouldn't do BGP over tunnels. BGP is for the "border" nodes, e.g. those nodes which connect the pieces of 44 into the Internet. If you want to use IPIP behind the BGP, or GRE, L2TP, within your subnets, nobody should care -- but this every node has an "encap.txt" file is, IMHO, crazy.
BGP node provides endpoint for tunnels (VPN, IPIP, etc.) subnet nodes connect to the BGP node via tunnel, the BGP node routes to the rest of 44.x.x.x and the Internet.
Then the simple node is easy.
Who is my BGP border node? How do I VPN to it? Set up VPN (or Tunnel) to it. Done.
John D. Hays K7VE PO Box 1223, Edmonds, WA 98020-1223
On Thu, Apr 24, 2014 at 4:24 PM, Don Fanning don@00100100.net wrote:
(Please trim inclusions from previous messages) _______________________________________________ I'm of the opinion that it should be kept the simplest possible and let people deal with their own networks. Give the people the basics needed
to
create a connection and get the routes. Then if they want to block
people,
they can add a static route dropping them or a firewall rule.
I feel BGP over GRE or DMVPN is overkill as beyond the extra
functionality
of GRE being able to do multicast and other kinds of traffic, there is no added value to what we already have with IPIP and RIP44d/encap. Within 44net, it's a different story - go RIP/OSPF and IPSec for all I care.
But
setting up tunnels should be kept simplistic.
Why would you add the complexity of BGP over GRE? I guess you could if you wanted to but the 2 protocols have extremely different uses. Use BGP to connect with one or more network service providers where you then bring your own address space. Use GRE to build tunnels into those networks. once BGP peered to the internet cloud, let the cloud do the routing and delivery between networks for you. Obviously if you have a direct point to point route between these networks (over radio) that may be preferable, but then again if you have such a link then maybe it's a good idea for those networks to peer based upon a common agreed upon roting policy.
Eric AF6EP
On Thu, Apr 24, 2014 at 4:24 PM, Don Fanning don@00100100.net wrote:
(Please trim inclusions from previous messages) _______________________________________________ I'm of the opinion that it should be kept the simplest possible and let people deal with their own networks. Give the people the basics needed to create a connection and get the routes. Then if they want to block people, they can add a static route dropping them or a firewall rule.
I feel BGP over GRE or DMVPN is overkill as beyond the extra functionality of GRE being able to do multicast and other kinds of traffic, there is no added value to what we already have with IPIP and RIP44d/encap. Within 44net, it's a different story - go RIP/OSPF and IPSec for all I care. But setting up tunnels should be kept simplistic.
On Thu, Apr 24, 2014 at 5:25 PM, Eric Fort eric.fort@gmail.com wrote:
(Please trim inclusions from previous messages) _______________________________________________ Why would you add the complexity of BGP over GRE?
It allows flexible routing... but I still stand by BGP being overkill for 44net and adds additional hassles of AS numbers to manage and keep track of along with hard limits of AS numbers unless you start doing 4-byte ASN's... which increases more information to keep track of and manage. We're having enough issues keeping DNS managed in a global sense as it is...
I guess you could if you wanted to but the 2 protocols have extremely different uses. Use BGP to connect with one or more network service providers where you then bring your own address space. Use GRE to build tunnels into those networks.
once BGP peered to the internet cloud, let the cloud do the routing and
delivery between networks for you.
I think John means this would be a private BGP and AS and not something requiring something from IANA/RIR's. You would still need a tunnel back to a master hub to get GRE tunnel information via NHRP as that information isn't obtain by BGP magic.
Obviously if you have a direct point to point route between these networks (over radio) that may be preferable, but then again if you have such a link then maybe it's a good idea for those networks to peer based upon a common agreed upon roting policy.
With most any routing protocol... BGP for instance it would advertise that your network is available via AS numbers. But most routing protocols do exactly the same thing. BGP just adds alot of extra options like a luxury car so that you can tune your traffic as you'd like (for instance you can advertise that you want most of your ingress traffic to come over RF unless the link is over 80% utilization in which case you can have them come over another network connection.
On Thu, Apr 24, 2014 at 6:51 PM, Don Fanning don@00100100.net wrote:
I guess you could if you wanted to but the 2 protocols have extremely different uses. Use BGP to connect with one or more network service providers where you then bring your own address space. Use GRE to build tunnels into those networks.
once BGP peered to the internet cloud, let the cloud do the routing and
delivery between networks for you.
I think John means this would be a private BGP and AS and not something requiring something from IANA/RIR's. You would still need a tunnel back to a master hub to get GRE tunnel information via NHRP as that information isn't obtain by BGP magic.
No, I mean BGP out to the Internet, not to private peer relationships. Once a 44.x.x.x subnet is routable to the Internet, it is routable to all other 44.x.x.x subnets that also have access to the Internet.
There really would only need to be a few BGP (border) nodes and they would most likely be routers, like CIscos or Mikrotiks (higher end units). Those routers would provide tunnels whether IPIP or VPN out to subnets in the 44.x.x.x space and route traffic for those subnets both to other 44.x.x.x subnets or the Internet in general.
For example this router http://routerboard.com/CCR1009-8G-1S has a level 6 license, which means it has no license limit on the number of VPNs/Tunnels it supports. Depending on traffic and ingress/egress bandwidth it could probably support many /16 vpns. In turn, a local network would be able to run a modest router, e.g. http://routerboard.com/RB750GL and in turn route to upto 200 smaller VPNs/Tunnels. For reliability the border nodes might multi-home their subnets at 2 or more data centers.
44.x.x.x is part of the Internet's addressable space. If we don't use it in that way, we may as well turn it back and just use 10.x.x.x
On Thu, 24 Apr 2014 20:02:26 -0700, K7VE - John k7ve@k7ve.org wrote:
44.x.x.x is part of the Internet's addressable space. If we don't use it in that way, we may as well turn it back and just use 10.x.x.x
The same rationale would and should apply to companies like GE. They have 3.x.x.x/8 and they use them internally, not just the Internet facing hosts, but every host in their system. Then they pile VLANs on top of the same hardware and run 10.x's all over for "security" or "legacy" purposes.It makes no sense to me to see them using net 3 for hosts that are behind firewalls and proxies or which are never intended to be reachable from anywhere outside their systems.
Exactly how do big corporations interconnect their islands of facilities? Isn't their topology exactly like the one we face?
On Thu, Apr 24, 2014 at 10:29 PM, Geoff Joy geoff@windowmeister.com wrote:
Exactly how do big corporations interconnect their islands of facilities? Isn't their topology exactly like the one we face?
You'd be surprised how quickly a 10/8 can get eaten up. Between cassandra clusters, redis nodes, memcache machines, application servers, infrastructure servers, relational databases, webservers, end users and management systems, at the mega-corps that I've worked for, a 10/8 may cover a couple data center not including different trust zones which may also have different subnets and vlans or the public/private ingress/egress addresses. Most modern shops use virtualization and blade technology extensively to shrink the footprint and build applications that work on scaling for better availability.
The current debate revolves mostly around WAN linking at a technical level, Public/Private ingress/egress and Authentication. I don't think routing is much of a concern as once they can figure out the WAN portion, usually routing isn't an issue.. unless it touches on one of the three I previously mentioned.
In corporations, someone with a high enough position and budget says 'make it happen' and hundreds of minions beneath make 'it' happen.
But this is a "public" network where no one trust one another (being that IP addressing doesn't identify someone) there needs to be some basic framework of communications between islands and the right allowances to interconnect to the larger Internet. Then let those islands figure out all the politics of encrypting authentication or global/private routing between themselves as long as it's opt-in not opt-out.
On Thu, Apr 24, 2014 at 8:02 PM, K7VE - John k7ve@k7ve.org wrote:
No, I mean BGP out to the Internet, not to private peer relationships. Once a 44.x.x.x subnet is routable to the Internet, it is routable to all other 44.x.x.x subnets that also have access to the Internet.
Most people wouldn't be able to take advantage of this sort of connection because most people aren't running datacenters in their houses or have that level of connectivity at their fingertips.
There really would only need to be a few BGP (border) nodes and they would most likely be routers, like CIscos or Mikrotiks (higher end units). Those routers would provide tunnels whether IPIP or VPN out to subnets in the 44.x.x.x space and route traffic for those subnets both to other 44.x.x.x subnets or the Internet in general.
In this configuration, all these BGP routers would not only have to take in the load for the entire network and figure out between them where the traffic goes, but also pump out the traffic. Since many places charge for bandwidth, it becomes a network system running at a financial loss to those operators instead of a cost neutral basis which it is now. I'm willing to bet that the FCC is going to walk away from net neutrality therefore it's only a matter of time before traffic is metered on both ends.
Additionally, this configuration would also have no mitigation against DoS attacks as likely the target is within the network so should you try and blacklist the target or shun at a peer upstream, the DoS traffic will just redirect to one of the BGP routers that states it is accepting traffic for it that you don't control and the same thing happens. Larger groups of people are affected instead of smaller islands.
But if you're saying we should just consolidate 44net into a bank of geographically located routers owned and managed and billed by ARDC, then maybe it should be brought up to the directors as discussed in last week's thread. Personally, this may be the better way of going as getting more than two people to agree on here seems almost impossible...
For example this router http://routerboard.com/CCR1009-8G-1S has a level 6 license, which means it has no license limit on the number of VPNs/Tunnels it supports. Depending on traffic and ingress/egress bandwidth it could probably support many /16 vpns. In turn, a local network would be able to run a modest router, e.g. http://routerboard.com/RB750GL and in turn route to upto 200 smaller VPNs/Tunnels. For reliability the border nodes might multi-home their subnets at 2 or more data centers.
In a DMVPN configuration, you can get away with having smaller numbers of VPN's as they're dynamically built and disconnected. But these routers don't support DMVPN or GRE. One would be better off with a RaspberryPi and a custom linux build vs buying one of these devices.
We should always keep in mind that there are many of us that aren't as well connected as others and may not have access to data centers.
Having a simpler network lowers the bar of entry so that everyone who doesn't have access to a colocation or a willing ISP that can broadcast BGP announcements can at least participate at a peer level without someone getting stuck for the check at the end of the day or being subject to gatekeepers.
44.x.x.x is part of the Internet's addressable space. If we don't use
it in that way, we may as well turn it back and just use 10.x.x.x
Except for when you are already using 10/8 as it's private non-routable space. The whole point is that it should be routable to all. Not just select network segments who can afford it.
Don,
You are missing the whole point - Not everyone needs to run BGP, or have a datacenter, they just need to find a border node who does and VPN/Tunnel to it. It's called cooperation.
Those who can provide a BGP border node, can 'advertise' through this list or portal.ampr.org that fact and how to get setup to tunnel/VPN to them. Like I said some of these routers have 'unlimited' support for VPN/Tunnel clients. You can also tier this architecture. A single border router might be supporting 20 /16 VPNs/Tunnels to tier 2 routers, those routers might support 30 smaller subnets and so on ---
There are some peering points that are relatively inexpensive (or free) and some individuals are in a position to be generous. This is no different than the FM repeater operator who pays for a site, equipment, and power costs to benefit a community of users, who may or may not make donations to that cost.
Right now the total traffic on 44net could probably ride on a single home broadband connection.
http://wiki.mikrotik.com/wiki/Manual:Interface/Gre
The VPNs can be full up using available protocols MikroTik runs a variety of VPN protocols PPTP, L2TP, IPIP, ... Cisco has DMVPN -- you just have to find a common one between two routers.
I run my personal /24 (non-44net) over a VPN 24x7 and have several hosts, including D-STAR gateways running over it.
http://www.seattleix.net/rules.htm ________________________________ John D. Hays K7VE PO Box 1223, Edmonds, WA 98020-1223
On 2014-04-24 23:07, K7VE - John wrote:
...
Right now the total traffic on 44net could probably ride on a single home broadband connection.
Don't be too sure; some of the German sites are running webcams refreshed every ten minutes ... and yes, I've viewing them.
On Thu, Apr 24, 2014 at 11:07 PM, K7VE - John k7ve@k7ve.org wrote:
(Please trim inclusions from previous messages) _______________________________________________ Don,
John,
You are missing the whole point
Not at all.
- Not everyone needs to run BGP, or
have a datacenter, they just need to find a border node who does and VPN/Tunnel to it. It's called cooperation.
Actually, unless this is agreed upon by everyone, this is just an idea. Not cooperation. Cooperation requires that all parties are willing to accept to the terms and conditions which many have been against.
Those who can provide a BGP border node,
This alone raises the bar for many people beyond those of normal radio operators.
can 'advertise' through this
list or portal.ampr.org that fact
and how to get setup to tunnel/VPN
to them.
Isn't that encap.txt? :)
I digress... it still requires a sharing of configurations, secrets and certificates depending on type of tunnel being built. We were talking about DMVPN earlier so that was the example I used.
Like I said some of these routers have 'unlimited' support for VPN/Tunnel clients. You can also tier this architecture. A single border router might be supporting 20 /16 VPNs/Tunnels to tier 2 routers, those routers might support 30 smaller subnets and so on ---
You don't need to sell me... I'm covered for networking gear. Maybe the next startup I ride into the ground will net me a Cisco Nexus. ;)
There are some peering points that are relatively inexpensive (or free) and some individuals are in a position to be generous.
Yes. But I was speaking of others in other parts of the world not here on the west coast where it's not the case. We shouldn't be so myopic in our world view to not consider those cases.
This is no different than the FM repeater operator who pays for a site, equipment, and power costs to benefit a community of users, who may or may not make donations to that cost.
Granted. But usually the repeater is operated by a club or group. And if you feel aligned with them or at least willing to smile to their jokes, by all means, sign up. However, the ones that aren't joiners should still get access to the same spectrum at the same level. After all, "nobody owns a frequency", even if you are trying to raise the bar to where it becomes a game of the biggest wallet.
Right now the total traffic on 44net could probably ride on a single home broadband connection.
Until you require everyone to go through your bottleneck... then it no longer is that. And like you mention, the goal is to make it completely available onto the internet.
I run my personal /24 (non-44net) over a VPN 24x7 and have several hosts, including D-STAR gateways running over it.
I got one of those setups as well personally not to mention what I do professionally.
But what I'm suggesting is that we shouldn't turn 44net into a class system of haves and have nots. The ones who have the ability to advertise their subnets are the haves and the ones who are forced to go through a gateway are the have nots. The network should just be how it is.... chaotic. The only improvement I would recommend is GRE instead of IPIP. Beyond that, leave it as it is.
People will want to interconnect or they won't. But it shouldn't be contingent upon anyone but themselves.
On Thu, Apr 24, 2014 at 11:07:32PM -0700, K7VE - John wrote:
Right now the total traffic on 44net could probably ride on a single home broadband connection.
The ham-related two-way traffic, perhaps. The probes and backscatter amount to quite a bit more traffic than that. - Brian
Yes -- there is a lot of noise eating bandwidth :)
My point is about real amateur applications and yes it could be dozens of megabytes in the aggregate.
________________________________ John D. Hays K7VE PO Box 1223, Edmonds, WA 98020-1223
On Fri, Apr 25, 2014 at 12:06 AM, Brian Kantor Brian@ucsd.edu wrote:
(Please trim inclusions from previous messages) _______________________________________________ On Thu, Apr 24, 2014 at 11:07:32PM -0700, K7VE - John wrote:
Right now the total traffic on 44net could probably ride on a single home broadband connection.
The ham-related two-way traffic, perhaps. The probes and backscatter amount to quite a bit more traffic than that. - Brian _________________________________________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
On 25.4.2014 5:02, K7VE - John wrote:
44.x.x.x is part of the Internet's addressable space. If we don't use it in that way, we may as well turn it back and just use 10.x.x.x
Actually there is a big difference. Within 44.x.x.x you have safe IP addressing. It is impossible to have address conflicts with any other network if you interconnect.
10.x.x.x is reused all over the planet, whenever someone needs addresses for private network. Conflicts are inevitable.
Pedja YT9TP
--- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com
On 2014-04-24 23:35, YT9TP Pedja wrote:
... Actually there is a big difference. Within 44.x.x.x you have safe IP addressing. It is impossible to have address conflicts with any other network if you interconnect.
This reminds me of a company I worked for many years ago, which chose 128.x.x.x as its internal IP address space.
Yes, there were certain external sites they could not visit.
Yes, they went out of business (in 2002).
The University of Iowa being one of them (128.255.0.0/16) :-). It's where I work.
On Fri, Apr 25, 2014 at 1:44 AM, Dean Gibson AE7Q ampr@ae7q.com wrote:
(Please trim inclusions from previous messages) _______________________________________________
On 2014-04-24 23:35, YT9TP Pedja wrote:
...
Actually there is a big difference. Within 44.x.x.x you have safe IP addressing. It is impossible to have address conflicts with any other network if you interconnect.
This reminds me of a company I worked for many years ago, which chose 128.x.x.x as its internal IP address space.
Yes, there were certain external sites they could not visit.
Yes, they went out of business (in 2002).
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
Why all this talk about BGP? Real men and women network engineers should use IS-IS :-)
Seriously though, I agree with those who are on the side of making 44-net MORE accessible and beneficial to average Amateur Radio Operators. Requiring CCNA/CCIE level networking knowledge is not the way to go. The IP-IP/RIP44 tunnel system is complicated enough, but at least it can be done with easily available hardware and Linux. I also agree that most ISP's are not going to want to advertise chunks of 44-net without someone paying for it.
I would like to see a backup to the UCSD gateway, but understand that would be complicated for a variety of reasons.
-Neil
On Fri, Apr 25, 2014 at 9:47 AM, Neil Johnson neil.johnson@erudicon.com wrote:
The University of Iowa being one of them (128.255.0.0/16) :-). It's where I work.
On Fri, Apr 25, 2014 at 1:44 AM, Dean Gibson AE7Q ampr@ae7q.com wrote:
(Please trim inclusions from previous messages) _______________________________________________
On 2014-04-24 23:35, YT9TP Pedja wrote:
...
Actually there is a big difference. Within 44.x.x.x you have safe IP addressing. It is impossible to have address conflicts with any other network if you interconnect.
This reminds me of a company I worked for many years ago, which chose 128.x.x.x as its internal IP address space.
Yes, there were certain external sites they could not visit.
Yes, they went out of business (in 2002).
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
-- Neil Johnson http://erudicon.com
+1
I have just joined the list and received my new 44 ip again, about 17 years I left my old one.
We can not define our network having to trust ISP to announce parts of the 44 network for free.
I think that most we could do may be asking universities and so to route those kind of 44 address blocks, maybe per country (or bigger blocks if possible)... and then try to route the traffic tunneling (GRE probed to be a good solution some years ago with the open wireless free network projects) or via radio if the distance allow us to do it.
Of course, asking one individual to arrange with his DSL provider one /32 or a /24 announced ... is not realistic. At least in Spain, EA.
Jaime, EA4TV El 25/04/2014 17:09, "Neil Johnson" neil.johnson@erudicon.com escribió:
(Please trim inclusions from previous messages) _______________________________________________ Why all this talk about BGP? Real men and women network engineers should use IS-IS :-)
Seriously though, I agree with those who are on the side of making 44-net MORE accessible and beneficial to average Amateur Radio Operators. Requiring CCNA/CCIE level networking knowledge is not the way to go. The IP-IP/RIP44 tunnel system is complicated enough, but at least it can be done with easily available hardware and Linux. I also agree that most ISP's are not going to want to advertise chunks of 44-net without someone paying for it.
I would like to see a backup to the UCSD gateway, but understand that would be complicated for a variety of reasons.
-Neil
On Fri, Apr 25, 2014 at 9:47 AM, Neil Johnson neil.johnson@erudicon.com wrote:
The University of Iowa being one of them (128.255.0.0/16) :-). It's where I work.
On Fri, Apr 25, 2014 at 1:44 AM, Dean Gibson AE7Q ampr@ae7q.com wrote:
(Please trim inclusions from previous messages) _______________________________________________
On 2014-04-24 23:35, YT9TP Pedja wrote:
...
Actually there is a big difference. Within 44.x.x.x you have safe IP addressing. It is impossible to have address conflicts with any other network if you interconnect.
This reminds me of a company I worked for many years ago, which chose 128.x.x.x as its internal IP address space.
Yes, there were certain external sites they could not visit.
Yes, they went out of business (in 2002).
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
-- Neil Johnson http://erudicon.com
-- Neil Johnson http://erudicon.com _________________________________________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
I don't agree to the GRE approach for a serie of reasons:
1. It is the only widely PtP protocol that allows point to multipoint using a single connection (at least on linux hosts). Using a tunnel interface for each peer is a pain in the proverbial behind. 2. It allows dynamic adding or removing of tunnels via simple route commands. On others one needs to manage and create tunnels for each endpoint. 3. Usually IPIP is not blocked by ISPs. Some ISP (e.g. Vodafone) charge extra for VPN connections, which include PPtP and L2TP but not IPIP. 4. IPIP carries traffic only if there is real traffic available. No keep alive and other connection maintainance traffic. Like dial on demand.
Disadvantages in my opinion: 1. No native support on Windows or Mac (PPtP and L2TP is supported). 2. Not supported in P2MP on routers (And this is the biggest disadvantage). 3. No stateful connections 4. No encryption (not very relevant IMHO, since the interest for interception/spoofing is minimal - there is no money to make here)
73s de Marius, YO2LOJ
I don't agree to the GRE approach for a serie of reasons:
Using a tunnel interface for each peer is a pain in the proverbialbehind.
Yes but... If we group subnets, we can reduce the number of peers and group subnets though tunnels.
Then running ospf inside the subnets and bgp between big 44 islands. :-)
For our uses 10/8 could be managed the same way 44/8 is with no duplication in our network. Simply replace 44 with 10. The only difference being global routability and no requirement for NAT to connect to the larger internet. Either we are connected and routed to the larger internet or we are not. Carrying this to it's extreme - The FCC allows me to dial the local autopatch and order pizza on my way home, would it be any different if I did this from an amprnet node via the pizzahut website?
Eric AF6EP
On Thu, Apr 24, 2014 at 11:35 PM, YT9TP Pedja yt9tp@uzice.net wrote:
(Please trim inclusions from previous messages) _______________________________________________ On 25.4.2014 5:02, K7VE - John wrote:
44.x.x.x is part of the Internet's addressable space. If we don't use it in that way, we may as well turn it back and just use 10.x.x.x
Actually there is a big difference. Within 44.x.x.x you have safe IP addressing. It is impossible to have address conflicts with any other network if you interconnect.
10.x.x.x is reused all over the planet, whenever someone needs addresses for private network. Conflicts are inevitable.
Pedja YT9TP
This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
On 25.4.2014 8:45, Eric Fort wrote:
(Please trim inclusions from previous messages) _______________________________________________ For our uses 10/8 could be managed the same way 44/8 is with no duplication in our network. Simply replace 44 with 10. The only difference being global routability and no requirement for NAT to connect to the larger internet. Either we are connected and routed to the larger internet or we are not.
It's not that simple. It might work if amateurs are only one to use it, but they are not.
I have 10.* in my home.
I have 10.* in my company, actually 10.* in each company's office.
I have 10.* in our city wireless community.
I have 10.* in our national wireless network that connects all local wireless communities.
I have 10.* in most private lans of my clients that I connect to via VPN.
It is really hard to avoid conflicts there.
44/8 is blessing.
--- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com
On Fri, Apr 25, 2014 at 12:03 AM, YT9TP Pedja yt9tp@uzice.net wrote:
I have 10.* in my home.
I have 10.* in my company, actually 10.* in each company's office.
I have 10.* in our city wireless community.
I have 10.* in our national wireless network that connects all local wireless communities.
I have 10.* in most private lans of my clients that I connect to via VPN.
It is really hard to avoid conflicts there.
44/8 is blessing.
Amen to that.
It's not just hard to avoid conflicts -- It's impossible to avoid conflicts.
So, can we finally dispense with the 10.x discussion? I think we've had to endure that silliness long enough.
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 Don Fanning Sent: Friday, April 25, 2014 12:07 AM To: AMPRNet working group Subject: Re: [44net] What is 44net?
(Please trim inclusions from previous messages) _______________________________________________ On Fri, Apr 25, 2014 at 12:03 AM, YT9TP Pedja yt9tp@uzice.net wrote:
I have 10.* in my home.
I have 10.* in my company, actually 10.* in each company's office.
I have 10.* in our city wireless community.
I have 10.* in our national wireless network that connects all local wireless communities.
I have 10.* in most private lans of my clients that I connect to via VPN.
It is really hard to avoid conflicts there.
44/8 is blessing.
Amen to that.
I was using 10.x.x.x for illustration. The point being non-routable vs routable address space.
I have never understood people who use 10.x.x.x/8 in a home network or in a rack at a data center. There is a class B space 172.16.x.x if you have more than 256 hosts, and there are 256 class C networks... but that's just me.
________________________________ John D. Hays K7VE PO Box 1223, Edmonds, WA 98020-1223
On Fri, Apr 25, 2014 at 12:06 AM, Don Fanning don@00100100.net wrote:
(Please trim inclusions from previous messages) _______________________________________________ On Fri, Apr 25, 2014 at 12:03 AM, YT9TP Pedja yt9tp@uzice.net wrote:
I have 10.* in my home.
I have 10.* in my company, actually 10.* in each company's office.
I have 10.* in our city wireless community.
I have 10.* in our national wireless network that connects all local wireless communities.
I have 10.* in most private lans of my clients that I connect to via VPN.
It is really hard to avoid conflicts there.
44/8 is blessing.
Amen to that.
Let me just make this clear as I can. Using BGP to bring islands of net-44 into the Internet --
Does not mean end users need BGP Does not mean end users need BGP Does not mean end users need BGP Does not mean end users need BGP Does not mean end users need BGP Does not mean end users need BGP
A few, maybe as little as 10, border nodes might run BGP and *provide VPN/Tunnel services to everyone else* and not everyone needs to run the same VPN/Tunnel protocol. Routing takes care of getting from point A to point B. The idea is to have a fully connected address space using the Internet/BGP to interconnect.
There can be multi-homing and tiers to minimize single points of failure. How many of you can say your 'home' ampr-lan doesn't have a single point of failure?
Encap/IPIP and RIP tables could theoretically have 16 million entries for Net-44, why not use aggregation and a tiered network instead?
As I see it, the end user would use a router (a cheap Mikrotik or RasPi) with one or more upstream VPN connections to a border node or sub-tier router and would route all non-local 44net traffic over that connection/those connections. All the user needs is a VPN/Tunnel configuration and credentials provided by the border node/tier router operator. So much simpler.
Think big net, not personal net.
------------------------------ 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 25.04.14. 19:26, K7VE - John wrote:
Encap/IPIP and RIP tables could theoretically have 16 million entries for Net-44, why not use aggregation and a tiered network instead?
With this configuration where everyone has IPIP connection to everyone, each network pays itćs own internet traffic.
If aggregation is introduced than traffic will go through aggregate routes thus spending someone else's internet traffic.
I am not much knowledgeable about BGP. Is it possible to assign whole 44/8 to one ASN and then advertize subnets with their own gateways using that one ASN? I mean, like ASN is assigned with number of smaller IP networks.
Pedja YT9TP
--- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com
On Fri, Apr 25, 2014 at 11:29 AM, YT9TP - Pedja yt9tp@uzice.net wrote:
(Please trim inclusions from previous messages)
I am not much knowledgeable about BGP. Is it possible to assign whole 44/8 to one ASN and then advertize subnets with their own gateways using that one ASN? I mean, like ASN is assigned with number of smaller IP networks.
Pedja YT9TP
Yes.
------------------------------ 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
Traffic between IP-IP mesh nodes will keep flowing even if the UCSD gateway disappears, the mesh just won't be able to reach/or be reachable from the Internet until the gateway is rebuilt.
It is my understanding that the UCSD gateway also blocks traffic coming into the IP-IP mesh unless the destination address has an entry in the ampr.org or reverse 44-net DNS.
I would like to see a backup to the UCSD gateway, but finding someone to swallow a /8 of traffic for free is, again, a problem.
-Neil
On Fri, Apr 25, 2014 at 1:31 PM, K7VE - John k7ve@k7ve.org wrote:
(Please trim inclusions from previous messages) _______________________________________________ On Fri, Apr 25, 2014 at 11:29 AM, YT9TP - Pedja yt9tp@uzice.net wrote:
(Please trim inclusions from previous messages)
I am not much knowledgeable about BGP. Is it possible to assign whole 44/8 to one ASN and then advertize subnets with their own gateways using that one ASN? I mean, like ASN is assigned with number of smaller IP networks.
Pedja YT9TP
Yes.
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 25.4.2014 20:31, K7VE - John wrote:
I am not much knowledgeable about BGP. Is it possible to assign whole 44/8 to one ASN and then advertize subnets with their own gateways using that one ASN? I mean, like ASN is assigned with number of smaller IP networks.
Yes.
Does that mean we can use single ASN and advertize all routes using that one, and subnets do not even need to use BGP, just simple default gateway through their internet links?
Pedja YT9TP
--- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com
Take a look at https://www.youtube.com/watch?v=PMI9YSM0mzY (Start at minute 9)
________________________________ John D. Hays K7VE PO Box 1223, Edmonds, WA 98020-1223
On Fri, Apr 25, 2014 at 12:11 PM, YT9TP Pedja yt9tp@uzice.net wrote:
(Please trim inclusions from previous messages) _______________________________________________
On 25.4.2014 20:31, K7VE - John wrote:
I am not much knowledgeable about BGP. Is it possible to assign whole 44/8 to one ASN and then advertize subnets with their own gateways using that one ASN? I mean, like ASN is assigned with number of smaller IP networks.
Yes.
Does that mean we can use single ASN and advertize all routes using that one, and subnets do not even need to use BGP, just simple default gateway through their internet links?
Pedja YT9TP
This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
On Fri, Apr 25, 2014 at 8:29 PM, YT9TP - Pedja yt9tp@uzice.net wrote:
I am not much knowledgeable about BGP. Is it possible to assign whole 44/8 to one ASN and then advertize subnets with their own gateways using that one ASN? I mean, like ASN is assigned with number of smaller IP networks.
This is already happening:
44/8 gets announced by UCSD then there are a few smaller networks that get announced. Like 44.144/16 in Belgium, 44.140/16 in Sweden, a 44.x /16 in italy, and a few /24's of individual hams here and there who probably have BGP at their work.
Routing will always prefer the smaller subnet, meaning that traffic for 44.144 will be send to the BGP gateway in belgium while the USCD gateway also covers this network with 44/8 If someone starts announcing eg 44.144.124.0/24 on another BGP gateway, the traffic will go to that gateway even though there is also a 44.144/16 gateway and a 44/8 gateway.
73s Robbie ON4SAX
On Fri, Apr 25, 2014 at 10:26 AM, K7VE - John k7ve@k7ve.org wrote:
(Please trim inclusions from previous messages) _______________________________________________
A few, maybe as little as 10, border nodes might run BGP and *provide VPN/Tunnel services to everyone else* and not everyone needs to run the same VPN/Tunnel protocol. Routing takes care of getting from point A to point B.
As others have already mentioned, some ISP's charge extra for VPN traffic. And again, you create bottlenecks placing all your eggs into one basket. This is getting circular.
The idea is to have a fully connected address space using the Internet/BGP to interconnect.
Why does every IP need to be internet accessible directly?
Lemme tell you a story: Back in the early days of the 1990's, a Colonel heard about this "Internet" thing and commanded that all of their military machines be placed upon said Internet even though their base had their own network space and communicated to other bases via tunnels and p-t-p links. Back then firewalls were few and far between back then and many machines weren't audited. Didn't matter to said Colonel and thus all the machines were placed onto the Internet. It didn't take long before hackers were able to probe the network and penetrate some machines that weren't meant for public access. Once it was discovered that hackers got into his network, an audit report came out that was as thick as the Manhattan phone book of all the flaws in their network.
Let's fast forward this to today: We have network radio hardware that cannot be tightly secured (node and the like), a constant and persistent threat of software vulnerabilities and hacking attempts trying to get more and more machines onto the internet to act as part of botnets or phishing schemes - not to mention regulation and financial burdens. And you want to put every machine on the Internet? It's not that simple.
There can be multi-homing and tiers to minimize single points of failure. How many of you can say your 'home' ampr-lan doesn't have a single point of failure?
I can, but I've already said I'm a special case. However I don't have any machine directly connected to the internet that is behoven to a single network gateway or provider.
What you're asking is for people around the world to connect to your group of routers (which will likely be US based - increasing latency for those outside of north america) just so that they can talk to one another or receive public traffic if they're not able to afford the $1000 or more for AS registration + RIR membership + ISP announcement costs + maintenance costs. Again, I think you are proposing a big mistake and a class system.
Encap/IPIP and RIP tables could theoretically have 16 million entries for Net-44, why not use aggregation and a tiered network instead?
Because it causes bottlenecks and SPOF's. Unless you can contractually provide me a TOS with 5 9's of reliability under heavy penalties, people are better off being responsible for their own traffic. If you are willing to offer that, then I'll be glad to sign up.
As I see it, the end user would use a router (a cheap Mikrotik or RasPi) with one or more upstream VPN connections to a border node or sub-tier router and would route all non-local 44net traffic over that connection/those connections. All the user needs is a VPN/Tunnel configuration and credentials provided by the border node/tier router operator. So much simpler.
Multiple VPN's not connecting to the same gateway causing routing issues. It's one thing to bond to a single gateway endpoint. But routing between two different gateway devices announcing your subnet would cause havoc and alot of inter-router latency as packets get slung between both gateways.
Think big net, not personal net.
Think networks (plural) and not singular net.
On Fri, Apr 25, 2014 at 11:36 AM, Don Fanning don@00100100.net wrote:
(Please trim inclusions from previous messages) _______________________________________________ On Fri, Apr 25, 2014 at 10:26 AM, K7VE - John k7ve@k7ve.org wrote:
(Please trim inclusions from previous messages) _______________________________________________
A few, maybe as little as 10, border nodes might run BGP and *provide VPN/Tunnel services to everyone else* and not everyone needs to run the same VPN/Tunnel protocol. Routing takes care of getting from point A to point B.
As others have already mentioned, some ISP's charge extra for VPN traffic. And again, you create bottlenecks placing all your eggs into one basket. This is getting circular.
So how do you do it now? You use an IPIP tunnel (another type of VPN), nothing changes for the end user except, his tables get much smaller, she routes local 44.x.x.x traffic locally and uses an IPIP tunnel to a tier or border router.
I'm not talking about one basket, but even if I was, it probably would have greater overall reliability than the 386 JNOS machine with hundreds of IPIP rules.
The idea is to have a fully connected address space using the Internet/BGP to interconnect.
Why does every IP need to be internet accessible directly?
It doesn't, but that should be a choice left to the endpoints.
There can be multi-homing and tiers to minimize single points of failure. How many of you can say your 'home' ampr-lan doesn't have a single point of failure?
I can, but I've already said I'm a special case. However I don't have any machine directly connected to the internet that is behoven to a single network gateway or provider.
What you're asking is for people around the world to connect to your group of routers (which will likely be US based - increasing latency for those outside of north america) just so that they can talk to one another or receive public traffic if they're not able to afford the $1000 or more for AS registration + RIR membership + ISP announcement costs + maintenance costs. Again, I think you are proposing a big mistake and a class system.
As already stated there are such routers already in place in Sweden, Belgium, Germany, US, Canada, and other locations. The people that run them have arrangements to do so, and the "masses" don't have to worry about that.
Encap/IPIP and RIP tables could theoretically have 16 million entries for Net-44, why not use aggregation and a tiered network instead?
Because it causes bottlenecks and SPOF's. Unless you can contractually provide me a TOS with 5 9's of reliability under heavy penalties, people are better off being responsible for their own traffic. If you are willing to offer that, then I'll be glad to sign up.
If you want a TOS of 5 9's you aren't talking amateur radio. Don't overlay business/government network requirements to what is essentially an experimenter's network, that may have some need for reliable services which can be addressed in data centers and by replication and other methods.
Data center resources are getting uber-cheap -- check out http://www.cloudatcost.com
________________________________ John D. Hays K7VE PO Box 1223, Edmonds, WA 98020-1223
On Fri, Apr 25, 2014 at 1:14 PM, K7VE - John k7ve@k7ve.org wrote:
A few, maybe as little as 10, border nodes might run BGP and *provide VPN/Tunnel services to everyone else* and not everyone needs to run the same VPN/Tunnel protocol. Routing takes care of getting from point A
to
point B.
As others have already mentioned, some ISP's charge extra for VPN
traffic.
And again, you create bottlenecks placing all your eggs into one basket. This is getting circular.
So how do you do it now? You use an IPIP tunnel (another type of VPN),
IPIP is encapsulation - VPN implies privacy. Big difference.
nothing changes for the end user except, his tables get much smaller, she routes local 44.x.x.x traffic locally and uses an IPIP tunnel to a tier or border router.
Everything changes as now all my traffic to 44/8 end up going through your gateway instead of individual p-t-p links.
I'm not talking about one basket, but even if I was, it probably would have greater overall reliability than the 386 JNOS machine with hundreds of IPIP rules.
All you are doing is taking the "hundreds" of rules and bringing them up one level. The complexity still exists, except that now if you fat finger a change, it impacts everyone until enough people complain to you about your mistake. Until then, everyone is affected instead of individual nodes.
What you're asking is for people around the world to connect to your
group
of routers (which will likely be US based - increasing latency for those outside of north america) just so that they can talk to one another or receive public traffic if they're not able to afford the $1000 or more
for
AS registration + RIR membership + ISP announcement costs + maintenance costs. Again, I think you are proposing a big mistake and a class
system.
As already stated there are such routers already in place in Sweden, Belgium, Germany, US, Canada, and other locations. The people that run them have arrangements to do so, and the "masses" don't have to worry about that.
Have you asked them if they're willing to take on the extra traffic or are willing to let you make routing changes to their routers?
What if your Ukranian and you're being told that you're forced to use a gateway run by Russians for whom you may have issues with? What if you're in China and you're unable to VPN out due to country firewalls? Or Turkey? Or Saudi Arabia? At least IPIP doesn't immediately say "tunneled private traffic". And my DoS example still stands because now you have individual groups advertising routes for the entire /8 for which are not under a singular control or a singular Point of Contact for mitigating the network.
Again, by keeping it simple for basic connectivity allows everyone to participate at a common level instead of the network becoming a place where you're either a rich system operator or poor end user.
Encap/IPIP and RIP tables could theoretically have 16 million entries
for
Net-44, why not use aggregation and a tiered network instead?
Because it causes bottlenecks and SPOF's. Unless you can contractually provide me a TOS with 5 9's of reliability under heavy penalties, people are better off being responsible for their own traffic. If you are
willing
to offer that, then I'll be glad to sign up.
If you want a TOS of 5 9's you aren't talking amateur radio.
Until you ask a EMCOMM person. Then it's the only thing that matters.
Don't overlay business/government network requirements to what is essentially an experimenter's network,
Overgeneralization and inaccurate but ok.
that may have some need for reliable services which can be addressed in data centers and by replication and other methods.
It's IP addressing and routing... not colocation. You keep trying to make 44net an ISP when it's not.
-----Original Message-----
So how do you do it now? You use an IPIP tunnel (another type of VPN), nothing changes for the end user except, his tables get much smaller, she routes local 44.x.x.x traffic locally and uses an IPIP tunnel to a tier or border router.
So you're creating multiple new single points of failure. With your plan, I can get to a few other local gateways. Anything else has to go through this new single point of failure locally, plus, presumably, and another single point of failure near my destination. So most worldwide connectivity would now have to traverse two single points of failure that currently don't exist. This is good because ...?
Michael N6MEF
Most failures are localized and temporary.
------------------------------ 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 Fri, Apr 25, 2014 at 3:41 PM, Michael E Fox - N6MEF n6mef@mefox.orgwrote:
(Please trim inclusions from previous messages) _______________________________________________
-----Original Message-----
So how do you do it now? You use an IPIP tunnel (another type of VPN), nothing changes for the end user except, his tables get much smaller, she routes local 44.x.x.x traffic locally and uses an IPIP tunnel to a tier or border router.
So you're creating multiple new single points of failure. With your plan, I can get to a few other local gateways. Anything else has to go through this new single point of failure locally, plus, presumably, and another single point of failure near my destination. So most worldwide connectivity would now have to traverse two single points of failure that currently don't exist. This is good because ...?
Michael N6MEF
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
In the IPIP tunnels, on both ends, you have a single point of failure since you cannot multihome (as discussed 25 MAR "Can't add redundant AMPR gateway to portal").
I know that the network I'm building as well as a few other BGP announced networks are multihomed -- no single point of failure to the internet. In fact, we have planned for one of the BGP announcements and peering to take place at one of our RF point of presences.
Another advantage is latency... having traffic travel from Memphis to San Diego and back just to get from my cellphone to a 44net-connected server in the same room is disappointing.
On Fri, Apr 25, 2014 at 6:01 PM, K7VE - John k7ve@k7ve.org wrote:
(Please trim inclusions from previous messages) _______________________________________________ Most failures are localized and temporary.
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 Fri, Apr 25, 2014 at 3:41 PM, Michael E Fox - N6MEF <n6mef@mefox.org
wrote:
(Please trim inclusions from previous messages) _______________________________________________
-----Original Message-----
So how do you do it now? You use an IPIP tunnel (another type of VPN), nothing changes for the end user except, his tables get much smaller, she routes local 44.x.x.x traffic locally and uses an IPIP tunnel to a tier or border router.
So you're creating multiple new single points of failure. With your
plan,
I can get to a few other local gateways. Anything else has to go through this new single point of failure locally, plus, presumably, and another single point of failure near my destination. So most worldwide connectivity
would
now have to traverse two single points of failure that currently don't exist. This is good because ...?
Michael N6MEF
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
I have no problem with IPIP tunnels. I just don't think it is the best architecture to have every node maintaining IPIP routes to every other node, a tiered network and one or two neighbors for each node is easier to setup and maintain. My goal is to get more people using 44net.
BTW, if anyone has in their EMComm plan that 44net will give them connectivity, "When all else fails..." it is a delusion. Even if you have IPIP tunnels, you have to have Internet connectivity to get to the other end of the tunnel. If you have IPIP connectivity, you have Internet connectivity and can pass the traffic over standard channels.
In a real Emcomm (less than 1% of network utilization), you just have to get traffic to a relay point. Your RF network may or may not get you there, but your IPIP tunnel doesn't give you any advantage over the ISP you are connected to.
------------------------------ 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 Fri, Apr 25, 2014 at 4:08 PM, Ryan Elliott Turner ryan.e.t@gmail.comwrote:
(Please trim inclusions from previous messages) _______________________________________________ In the IPIP tunnels, on both ends, you have a single point of failure since you cannot multihome (as discussed 25 MAR "Can't add redundant AMPR gateway to portal").
I know that the network I'm building as well as a few other BGP announced networks are multihomed -- no single point of failure to the internet. In fact, we have planned for one of the BGP announcements and peering to take place at one of our RF point of presences.
Another advantage is latency... having traffic travel from Memphis to San Diego and back just to get from my cellphone to a 44net-connected server in the same room is disappointing.
_______________________________________________ In the IPIP tunnels, on both ends, you have a single point of failure since you cannot multihome (as discussed 25 MAR "Can't add redundant AMPR gateway to portal").
N6MEF: Apples and oranges. For my own end-points, I don't have to rely on anyone else if they need attention. The plan that's being discussed would put two additional points of failure between my end points and most other end points and the keeper of those points of failure has no contractual obligation to do anything. If he's away for the summer on vacation or sick or at the movies or out to dinner or ... oh, well.
N6MEF: As for redundant end points, I see nothing in the proposal that fixes that. The proposal merely take one full mesh and breaks it into multiple full meshes, each with the same problem (non-redundant end-points) as before, with the added bonus of two new single points of failure in between.
I know that the network I'm building as well as a few other BGP announced networks are multihomed -- no single point of failure to the internet. In fact, we have planned for one of the BGP announcements and peering to take place at one of our RF point of presences.
N6MEF: Perhaps that's true of the one you're building. I don't see that listed as a requirement in general. And will you have backup sysops? And monitoring? And how will people report problems to you? What happens when you go on vacation or are sick or asleep or on a business trip or ... Today, by the good graces of UCSD, we have a gateway that Brian supports well, when he can. There have been outages, but because of the full-mesh design, they have had ZERO impact on tunnel traffic. So if the volunteer can't work on it right away, only Internet traffic is impacted. And we all have the option to send Internet traffic (NATed) out our own home router. This plan would create intermediaries such that an outage WOULD impact tunnel traffic and we're at the mercy of whoever pushes his way into being that middle man. No thank you.
Another advantage is latency... having traffic travel from Memphis to San Diego and back just to get from my cellphone to a 44net-connected server in the same room is disappointing.
N6MEF: Yes, THAT is a problem worth solving (in addition to allowing alternate endpoint gateways). But we need a solution that doesn't create additional problems. Let's take a step forward, not two steps backward. There is an ENOURMOUS difference between a multi-homed AS, with multiple BGP external gateways (as large corporations would have with multiple sites interconnected by VPN ) and making multiple AS's by inserting BGP gateways in the middle of "internal" (44-to-44) traffic.
Michael N6MEF
On Fri, Apr 25, 2014 at 5:16 PM, Michael E Fox - N6MEF n6mef@mefox.orgwrote:
This plan would create intermediaries such that an outage WOULD impact tunnel traffic and we're at the mercy of whoever pushes his way into being that middle man. No thank you.
You are making a big leap here. Nobody is going to tell you who you are going to have for neighbors or up stream. Find someone you trust, that has the contingency plan you feel comfortable with and connect to them. They don't even have to be in your neighborhood.
Any plan will have the potential for failures. You might control your IPIP tunnel but what if your ISP goes away? Is the device that is running your tunnel on redundant power? Does it have redundant networking with failover and portability of your encapsulating IP address? Does very end point you want to talk to have those capabilities?
At my day job, every dollar that comes into our company arrives on an RJ-45, and it falls into my area of responsibility to make sure it stays up and we have failover and contingency plans. I understand these things. (I use geographically dispersed data centers, multiple carriers, redundant servers, etc. but there is still the potential to go down, at least temporarily, even even with service level agreements.)
I also understand that ham radio is a hobby..
------------------------------ 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
This plan would create intermediaries such that an outage WOULD impact tunnel traffic and we're at the mercy of whoever pushes his way into being that middle man. No thank you.
You are making a big leap here. Nobody is going to tell you who you are going to have for neighbors or up stream. Find someone you trust, that has the contingency plan you feel comfortable with and connect to them. They don't even have to be in your neighborhood.
N6MEF: Then I choose nothing. Currently, when my packets leave my gateway, they travel through commercial carrier networks to reach the destination gateway. Those carriers have service level agreements, redundancy, diversity, 24x7 NOCs, 24x7 technicians, caches of spare equipment, help desks, etc. Your proposal would cause my traffic to ride some of those same carrier networks but then exit to some amateur near me who has none of those capabilities, then back onto the commercial networks, then back off to some other amateur near my destination, then back onto the commercial carrier to the destination. Do you really not see how silly that is? When a problem happens, either one or both of those amateurs may be at work, asleep, away on vacation, out to dinner, away on a business trip, or just not interesting in working on it at the time because he's watching the Star Trek marathon that weekend. Then there's always, "sorry guys, I'm being transferred for work, so I'm going to have to shut down my system." That's a huge step backward in reliability. I mean, seriously, why would anyone choose to add amateur operations into the middle of the existing all commercial/professional forwarding path that our full mesh of tunnels currently traverses?
N6MEF: One of the nice things about AMPRnet over the old BBS network is we don't need to rely on each amateur in the path keeping their system running and configured properly. Anyone with experience in both will tell you there is simply no comparison. The old-style reliance on amateurs in the forwarding path is far, far less reliable. You would have us go backwards to that approach.
Any plan will have the potential for failures. You might control your IPIP tunnel but what if your ISP goes away? Is the device that is running your tunnel on redundant power? Does it have redundant networking with failover and portability of your encapsulating IP address? Does very end point you want to talk to have those capabilities?
N6MEF: Strawman arguments, all. If my ISP goes away, so would my connection to any local BGP hub in your plan. Or, if the remote endpoint dies, so does connectivity to that location, both in the existing mesh and in your plan. So let's not play games. Pointing out existing failure modes does nothing to mask the fact that your proposal has the same failure modes, plus it would add a pile of new ones.
N6MEF: Bottom line, you plan introduces new/additional failure modes which have been pointed out by several people on this list and you've done nothing but dismiss them. I doubt anyone will want their traffic to have to traverse the facilities managed by someone with such a lack of appreciation for the problems that can occur and so little regard for their desire/need for stability and reliability.
At my day job, every dollar that comes into our company arrives on an RJ-45, and it falls into my area of responsibility to make sure it stays up and we have failover and contingency plans. I understand these things. (I use geographically dispersed data centers, multiple carriers, redundant servers, etc. but there is still the potential to go down, at least temporarily, even even with service level agreements.)
N6MEF: Got it. As I suspected, not a commercial/carrier network architect/engineer. Carrier network operations is an entirely different set of issues. Still, I'll bet your company doesn't rely on an amateur, with no service level agreement, no NOC, no backup staff, no 24x7 operations to manage connectivity between your data centers.
I also understand that ham radio is a hobby..
N6MEF: Yes, amateur RADIO is a hobby. So knock yourself out experimenting with radio. But the last thing any of us needs is to have some amateur insert himself into the commercial networking path between gateways.
Michael N6MEF
Eliminating single points of failure has a simple solution.
Keep your IPIP mesh with a higher route metric and add P2P links via another provider and gateway with lower route metrics, managed by a routing protocol.
e.g. I have the classic mesh up via a lower speed provider, and a L2TP tunnel to the german hamnet via a high speed interface, announcing my presence via BGP on that VPN and getting their routes also via BGP. If the L2TP tunnel fails, the BGP routes will disappear and the old mesh network will kick in providing the needed redundancy (another provider, another gateway). BGP is not necessary needed, any routing protocol will do, e.g. OSPF or RIP.
Just as simple as that. No need to drop the mesh, just add VPNs to it. And from the point of view of your partner subnet, you are also multihomed.
On 04/25/2014 03:41 PM, Michael E Fox - N6MEF wrote:
So how do you do it now? You use an IPIP tunnel (another type of VPN), nothing changes for the end user except, his tables get much smaller, she routes local 44.x.x.x traffic locally and uses an IPIP tunnel to a tier or border router.
So you're creating multiple new single points of failure. With your plan, I can get to a few other local gateways. Anything else has to go through this new single point of failure locally, plus, presumably, and another single point of failure near my destination. So most worldwide connectivity would now have to traverse two single points of failure that currently don't exist. This is good because ...?
I'd like to keep the IPIP mesh (perhaps enhanced with other protocols laid on top of each IPIP), since it is the fastest way of getting from network A to network B, where both are non-Internet-BGP'd 44nets.
What I would like to see in addition though are VPN dial-ins (perhaps IPIP based, perhaps not) that provide the Internet transit, not inter-44net transit. This is so 44net users aren't having to spend lots of money arranging Internet BGP peers. A heirarchy of such gateways can be established. For example, Western Washington can run a gateway that serves its populace and announces 44.24/16. This is less-specific than user announcements but more-specific than the UCSD announcement. So it would simultaneously not deprive end-users of Internet BGP, and jump in front of UCSD needing to handle the traffic. Should UCSD fail, the Western Washington gateway stays up and any 44net<->Internet traffic for Western Washington users is unaffected by the UCSD failure. Should the Western Washington gateway fail, UCSD can take over (via its 44/8) and relay packets to users as it gets them. Users would need to hold connections with both gateways.
I think this is how my proposal and John's proposals differ. I'd like to keep the IPIP mesh, not replace it with VPN concentrators. I'd just like to augment the UCSD single point of Internet transit with additional regional Internet transit points.
Lastly, it's also possible for a regional gateway like the Western Washington one, to also announce 44/8 and provide Internet transit for all 44nets. It would then compete (based on a least-hop basis, and some other BGP attributes) with other such gateways (eg: UCSD) for the duty of delivering Internet traffic. This fixes the single point of failure right now @ UCSD. There are some open design questions in the implementation of these 44/8 gateways, but those details can be worked out.
--Bart
On 25.04.14. 19:15, K7VE - John wrote:
I have never understood people who use 10.x.x.x/8 in a home network or in a rack at a data center. There is a class B space 172.16.x.x if you have more than 256 hosts, and there are 256 class C networks... but that's just me.
I am pretty sure no one uses whole 10/8 for home network but some subnet.
By default, home networking devices use 192.168.*.* so it is just an experience not to use that addresses to avoid conflicts, similarly as avoiding 10.10.*.* is wise too as that is also very common.
--- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com
On 2014-04-25 10:15, K7VE - John wrote:
(Please trim inclusions from previous messages) _______________________________________________ I was using 10.x.x.x for illustration. The point being non-routable vs routable address space.
I have never understood people who use 10.x.x.x/8 in a home network or in a rack at a data center. There is a class B space 172.16.x.x if you have more than 256 hosts, and there are 256 class C networks... but that's just me.
Well, what happens is that people get burned with conflicts using 192.168.0.x/24 or 192.168.1.x/24, when they add a new device to their network, and they seek to escape to 10.x.x.x/8, planning to avoid such conflicts, and run straight into VPN issues with everyone else that thinks that way.
It doesn't take much effort or equipment to run a DMZ in a separate private-IP space from your LAN, and then if you have a VPN IP-address conflict in your DMZ, you can change IP addresses (or even network address space) there without affecting your LAN.
Also, just because the 192.168.x.x block is 256 /24 networks, doesn't mean that you have to use it that way (ditto for 172.1x.x.x needing to be 16 /16 networks). I run a DMZ using 192.168.0.x/18, but only one host is in 192.168.0.x/24 (to deal with devices new to the network).
Yes, I know this is all old-hat to most of us, but since the subject came up ...
ps: If anyone ever intends to network with, to, or through D-Star DD-mode nodes, note that those are hard-allocated to the 10.x.x.x/8 block.
On Fri, Apr 25, 2014 at 11:23 AM, Dean Gibson AE7Q ampr@ae7q.com wrote:
ps: If anyone ever intends to network with, to, or through D-Star DD-mode nodes, note that those are hard-allocated to the 10.x.x.x/8 block.
That's just an Icom (V1/G2) implementation. ircDDBGateway doesn't require that and those gateways could easily move to 44.x.x.x
------------------------------ 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
-
Bart Kus -
Bill Vodall -
Brian Kantor -
Bryan Fields -
Dean Gibson AE7Q -
Don Fanning -
Eric Fort -
Geoff Joy -
Jaime Robles -
K7VE - John -
Marius Petrescu -
Michael E Fox - N6MEF -
Neil Johnson -
Robbie De Lise -
Ryan Elliott Turner -
YT9TP - Pedja -
YT9TP Pedja