On Jun 14, 2011, at 11:00 AM, Ray Soucy wrote: > I think that's a market problem rather than a routing problem. In the > long term, If we had separation of L2 and L3 service providers there > would be very, very few who need L3 redundancy; and that amount would > be fine using BGP. > ROFLMAO... You're joking, right? Oh, you're serious... OK... I encourage my competitors to try that.
> Metro Ethernet services are making it a bit easier to accomplish this; > but every ISP wants you to use them for everything so it's still a > challenge. > I would still want L3 redundancy and I can't imagine any of my clients choosing to go with diverse L2 paths to the same L3 provider as a valid complete solution for redundancy. > I would really like to see L2 optical services being treated as a > public utility; and you just purchase your L3 from any provider you > want. Prices would go down because we wouldn't be wasting money on > building identical fiber paths, and bandwidth would go up. Have a > problem with your current ISP? The switch to a different one can be > done with a phone call; you don't even need to have a technician sent > out. > Agreed, but, that doesn't change the fact that L3 redundancy is still a requirement for a growing (not shrinking) number of organizations. That's not a market issue, that _IS_ a routing issue. The good news on that front, however, is that if we get from o(10+) prefixes per organization to o(2) prefixes per organization, we get a dramatically smaller routing table with iPv6 fully deployed and can accommodate a pretty hefty number of additional organizations in IPv6. > Maine recently started the ground work for that by making a new class > of Public Utility for Dark Fiber, but it doesn't allow them to light > it up. > It's been done in Sweden and is being done in AU as well. I've been advocating an independent monopoly LMI non-profit available to all higher tier service providers on an equal basis for years. Glad to see it's starting to finally catch on in a couple of places. Owen > On Tue, Jun 14, 2011 at 1:48 PM, Owen DeLong <o...@delong.com> wrote: >> Actually, a vastly inferior solution, but, it does have the attraction of >> being able to continue to ignore the need for scalable routing for several >> more years. >> >> In reality, we need to solve the scalable routing problem at some point >> and having everyone jump into the IPv6 BGP world for multihoming >> would be sustainable long enough for that problem to get solved if >> resources were focused on it. >> >> Owen >> >> On Jun 14, 2011, at 10:04 AM, Ray Soucy wrote: >> >>> Today you're probably correct. If you want to have more than one >>> provider reliably you pretty much need to be doing BGP; or have some >>> sort of primary-backup setup to fail over from one to the other; or >>> give each host a global address from each provider (really not >>> desirable in the majority of networks). >>> >>> I think in the long term telling everyone to jump into the BGP table >>> is not sustainable; and not operationally consistent with the majority >>> of SMB networks. >>> >>> A better solution; and the one I think that will be adopted in the >>> long term as soon as vendors come into the fold, is to swap out >>> RFC1918 with ULA addressing, and swap out PAT with NPT; then use >>> policy routing to handle load balancing and failover the way most >>> "dual WAN" multifunction firewalls do today. >>> >>> Example: >>> >>> Each provider provides a 48-bit prefix; >>> >>> Internally you use a ULA prefix; and setup prefix translation so that >>> the prefix gets swapped appropriately for each uplink interface. This >>> provides the benefits of "NAT" used today; without the drawback of >>> having to do funky port rewriting and restricting incoming traffic to >>> mapped assignments or UPnP. >>> >>> The firewall keeps track of if a connection is up or down and keeps >>> policy routing up to date; >>> >>> You can choose to set it up to either load balance per-flow or as a >>> primary and backup interface. >>> >>> You can handle DNS by using RFC 2136 updates for a sub-domain with a >>> short TTL on a hosted server to keep names up to date in the event of >>> a link drop. >>> >>> This doesn't require cooperation from the provider; it doesn't require >>> knowledge of routing protocols; and it is easy to understand for >>> people used to the "NAT" environment. >>> >>> Last time I checked, Linux still needs some work to handle ECMP >>> routing for IPv6, but once that is in place; combined with patches for >>> Network Prefix Translation (NPT), it should be trivial to implement. >>> >>> My guess is within the next year we'll see something pop up that does this. >>> >>> Ray >>> >>> On Mon, Jun 13, 2011 at 8:48 PM, Owen DeLong <o...@delong.com> wrote: >>>> The vastly better option is to obtain a prefix and ASN from ARIN and >>>> merely trade BGP with your >>>> upstream providers. >>>> >>>> Prefix translation comes with all the same disabilities that are present >>>> when you do this in IPv4. >>>> >>>> In IPv4, everyone's software expects you to have a broken network (NAT) >>>> and there is lots of extra >>>> code in all of the applications to work around this. >>>> >>>> In iPv6, it is not unlikely that this code will eventually get removed and >>>> you will then have a high >>>> level of application problems in your "prefix-translated" environment. >>>> >>>> Owen >>>> >>>> On Jun 12, 2011, at 11:46 AM, Randy Carpenter wrote: >>>> >>>>> Prefix translation looks to be exactly what we need to do here. Thanks >>>>> for all of the replies. >>>>> >>>>> >>>>> -Randy >>>>> >>>>> On Jun 12, 2011, at 2:42, Seth Mos <seth....@dds.nl> wrote: >>>>> >>>>>> >>>>>> Op 12 jun 2011, om 03:50 heeft Randy Carpenter het volgende geschreven: >>>>>> >>>>>>> >>>>>>> I have an interesting situation at a business that I am working on. We >>>>>>> currently have the office set up with redundant connections for their >>>>>>> mission critical servers and such, and also have a (cheap) cable modem >>>>>>> for general browsing on client machines. >>>>>> >>>>>> So basically policy routing? >>>>>> >>>>>>> The interesting part is that the client machines need to access some >>>>>>> customer networks via the main redundant network, so we have a firewall >>>>>>> set up to route those connections via the redundant connections, and >>>>>>> everything else via the cheaper, faster cable modem. NAT is used on >>>>>>> both outbound connections. >>>>>> >>>>>> Yep that sounds like policy routing. >>>>>> >>>>>>> With IPv6, we are having some trouble coming up with a way to do this. >>>>>>> Since there is no NAT, does anyone have any ideas as to how this could >>>>>>> be accomplished? >>>>>> >>>>>> Sure there is NAT, you can use prefix translation to translate your >>>>>> Global Address Range from the redundant ISP to the Cable ISP Global >>>>>> address range when leaving that interface. I've run a similar setup with >>>>>> 3 independent ISPs with IPv6 netblocks. >>>>>> >>>>>> Whichever connection the traffic went out it got the right GUA mapped >>>>>> onto it. Note that this is 1:1 NAT and not N:1. >>>>>> >>>>>> In my case there was no primary GUA range, I used a ULA on the LAN side >>>>>> of things, and mapped the corresponding GUA onto it when leaving the >>>>>> network. I had 3 rules, 1 for each WAN and mapped the ULA/56 to the >>>>>> GUA/56. >>>>>> >>>>>> In your case you already have a primary connection of sorts, so I'd >>>>>> suggest using that on the LAN side and only map the other GUA onto it >>>>>> when it leaves the other interfaces. >>>>>> >>>>>> The policy routing rules on your firewall can make all the routing >>>>>> decissions for you. >>>>>> >>>>>> If you search google for "IPv6 network prefix translation" there will be >>>>>> a firewall listed that can do this somewhere in the middle of the page. >>>>>> >>>>>> Cheers, >>>>>> >>>>>> Seth >>>>>> >>>> >>>> >>>> >>> >>> >>> >>> -- >>> Ray Soucy >>> >>> Epic Communications Specialist >>> >>> Phone: +1 (207) 561-3526 >>> >>> Networkmaine, a Unit of the University of Maine System >>> http://www.networkmaine.net/ >> >> > > > > -- > Ray Soucy > > Epic Communications Specialist > > Phone: +1 (207) 561-3526 > > Networkmaine, a Unit of the University of Maine System > http://www.networkmaine.net/
