Re: AWS Elastic IP architecture
Since your network has IPv6, I fail to see the issue. Nobody is anywhere near being able to go single-stack on IPv6, so AWS is just another network your customers will continue to reach over v4. So what? Heck, if v6 support from a cloud hosting company is so important, I see a great business opportunity in your future. Matthew Kaufman (Sent from my iPhone) On May 31, 2015, at 10:57 AM, Owen DeLong o...@delong.com wrote: Sigh… IPv6 has huge utility. AWS’ implementation of IPv6 is brain-dead and mostly useless for most applications. I think if you will review my track record over the last 5+ years, you will plainly see that I am fully aware of the utility and need for IPv6. http://lmgtfy.com?q=owen+delong+ipv6 http://lmgtfy.com/?q=owen+delong+ipv6 My network (AS1734) is fully dual-stacked, unlike AWS. If AWS is so convinced of the utility of IPv6, why do they continue to refuse to do a real implementation that provides IPv6 capabilities to users of their current architecture. Currently, on AWS, the only IPv6 is via ELB for classic EC2 hosts. You cannot put a native IPv6 address on an AWS virtual server at all (EC2 or VPC). Unless your application is satisfied by running an IPv4-only web server which has an IPv6 VIP proxy in front of it with some extra headers added by the proxy to help you parse out the actual source address of the connection, then your application cannot use IPv6 on AWS. As such, I stand by my statement that there is effectively no meaningful support for IPv6 in AWS, period. AWS may disagree and think that ELB for classic EC2 is somehow meaningful, but their lack of other support for any of their modern architectures and the fact that they are in the process of phasing out classic EC2 makes me think that’s a pretty hard case to make. Owen On May 31, 2015, at 9:01 AM, Blair Trosper blair.tros...@gmail.com wrote: Disagree, and so does AWS. IPv6 has a huge utility: being a universal, inter-region management network (a network that unites traffic between regions on public and private netblocks). Plus, at least the CDN and ELBs should be dual-stack, since more and more ISPs are turning on IPv6. On Sun, May 31, 2015 at 8:40 AM, Owen DeLong o...@delong.com mailto:o...@delong.com wrote: I wasn’t being specific about VPC vs. Classic. The support for IPv6 in Classic is extremely limited and basically useless for 99+% of applications. I would argue that there is, therefore, effectively no meaningful support for IPv6 in AWS, period. What you describe below seems to me that it would only make the situation I described worse, not better in the VPC world. Owen On May 31, 2015, at 4:23 AM, Andras Toth diosbej...@gmail.com mailto:diosbej...@gmail.com wrote: Congratulations for missing the point Matt, when I sent my email (which by the way went for moderation) there wasn't a discussion about Classic vs VPC yet. The discussion was no ipv6 in AWS which is not true as I mentioned in my previous email. I did not state it works everywhere, but it does work. In fact as Owen mentioned the following, I assumed he is talking about Classic because this statement is only true there. In VPC you can define your own IP subnets and it can overlap with other customers, so basically everyone can have their own 10.0.0.0/24 http://10.0.0.0/24 for example. They are known to be running multiple copies of RFC-1918 in disparate localities already. In terms of scale, modulo the nightmare that must make of their management network and the fragility of what happens when company A in datacenter A wants to talk to company A in datacenter B and they both have the same 10-NET addresses Andras On Sun, May 31, 2015 at 7:18 PM, Matt Palmer mpal...@hezmatt.org mailto:mpal...@hezmatt.org wrote: On Sun, May 31, 2015 at 01:38:05AM +1000, Andras Toth wrote: Perhaps if that energy which was spent on raging, instead was spent on a Google search, then all those words would've been unnecessary. Official documentation: http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/elb-internet-facing-load-balancers.html#internet-facing-ip-addresses http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/elb-internet-facing-load-balancers.html#internet-facing-ip-addresses Congratulations, you've managed to find exactly the same info as Owen already covered: Load balancers in a VPC support IPv4 addresses only. and Load balancers in EC2-Classic support both IPv4 and IPv6 addresses. - Matt
Re: AWS Elastic IP architecture
On May 31, 2015, at 11:36 AM, Blair Trosper blair.tros...@gmail.com wrote: AWS built their network first...before IPv6 popped, so you can appreciate the huge task they have of retrofitting all their products to support it. Sure, and if they said “We have a plan, and it will take X amount of time”, I would respect that. If they said “We have a plan and we’re not sure how long it will take”, I would continue to poke them about sooner is better than later and having a target date helps people to plan. “We don’t think IPv6 matters and we aren’t announcing any plans to get it implemented or any date by which it will be available”, on the other hand, being what they have actually repeatedly said to me until very recently, not so much. Now, they’re saying (essentially) “We think IPv6 might matter, but we aren’t announcing any plans to get it implemented or any date by which it will be available” . To me, this is still a problematic situation for their customers. Especially when you look at the impact it has on the rest of the internet. Review Lee Howard’s Denver ION presentation about per-user-per-year costs of delivering IPv4 over the next several years and it rapidly becomes clear that the failure of Amazon to make dual stack available is actually one of the major factors preventing eyeball carriers from being able to make plans for IPv6 monastic on any reasonable timeframe and a major factor in their CGN costs. I don't envy the task, but they have said publicly and privately that it's a priority. But it's also a massive undertaking, and you can't expect them to snap their fingers and turn it out over a weekend, man… They haven’t, really, exactly said that. They’ve sort of hinted that they might be working on it in some places. They’ve sort-a-kind-a paid it some lip service. They haven’t announced plans, dates, or any firm commitment in any form. The prize of being first cuts both ways when newer technologies at lower network levels start taking off and you don't have support built in to something proprietary. I started talking to folks at Amazon about this issue more than 5 years ago. At the time, they told me flat out that it was not a priority. I gave them half a decade to figure out it was a priority and do something about it while remaining relatively quite about it publicly. At this point, things have reached a point where the damage that occurs as a result of applications being deployed on such a dead-end service and the limitations that service imposes on those applications can no longer be tolerated. Would it be great if they had it faster? Obviously yes. Agreed. Are they working on it as a priority? Yes. Do you have any evidence to support this claim? Can they go any faster? Probably. Isn’t that answer alone a sign that perhaps it isn’t so much of a priority to them? Are there other choices for cloud providers that are full dual stack if this really is a live or die issue for you? Yes. This represents one of the most common fallacies in people’s thinking about IPv6. Your failure to implement IPv6 doesn’t just impact you and your customers. Especially when you’re something like AWS. It impacts the customers of your customers and their service providers, too. If Amazon and Skype were IPv6 capable, you would actually find a relatively significant fraction of traffic that is likely to get CGN’d today would be delivered over IPv6 instead. That’s a HUGE win and a HUGE cost savings to lots of eyeball ISPs out there. None of them are likely AWS customers. None of them are likely to be perceived by AWS as “demand” for IPv6, yet, they are in fact the source of the majority of the demand. Access to dual-stack isn't a fundamental human right. If you don't like what AWS is doing, then use someone else who has dualstack. Again, you are ignoring the larger consequences of their failure. You can rest assured that I am not purchasing service from AWS due to their failed policies toward IPv6. However, that doesn’t fully mitigate the impact to me from those bad decisions. So, in an effort to both further mitigate those impacts and to help others avoid them, I have started vocally encouraging people to take a serious look at AWS’ lack of IPv6 and consider alternatives when selecting a cloud hosting provider. I don't get the outrage...and it's so irrational, that you've caused me to actually *defend* AWS. I hope I have explained the reasons for my position a bit better so that you no longer feel the need to do so. I am not outraged by AWS’ actions. They are free to do what they wish. However, I want to make sure that application developers are aware of the impact this has on their application, should they choose to deploy it in AWS and I want to encourage current users of AWS to consider IPv6-capable alternatives for the good of the internet. Owen bt On Sun, May 31, 2015 at 1:29 PM, Matthew Kaufman
Re: AWS Elastic IP architecture
Disagree, and so does AWS. IPv6 has a huge utility: being a universal, inter-region management network (a network that unites traffic between regions on public and private netblocks). Plus, at least the CDN and ELBs should be dual-stack, since more and more ISPs are turning on IPv6. On Sun, May 31, 2015 at 8:40 AM, Owen DeLong o...@delong.com wrote: I wasn’t being specific about VPC vs. Classic. The support for IPv6 in Classic is extremely limited and basically useless for 99+% of applications. I would argue that there is, therefore, effectively no meaningful support for IPv6 in AWS, period. What you describe below seems to me that it would only make the situation I described worse, not better in the VPC world. Owen On May 31, 2015, at 4:23 AM, Andras Toth diosbej...@gmail.com wrote: Congratulations for missing the point Matt, when I sent my email (which by the way went for moderation) there wasn't a discussion about Classic vs VPC yet. The discussion was no ipv6 in AWS which is not true as I mentioned in my previous email. I did not state it works everywhere, but it does work. In fact as Owen mentioned the following, I assumed he is talking about Classic because this statement is only true there. In VPC you can define your own IP subnets and it can overlap with other customers, so basically everyone can have their own 10.0.0.0/24 for example. They are known to be running multiple copies of RFC-1918 in disparate localities already. In terms of scale, modulo the nightmare that must make of their management network and the fragility of what happens when company A in datacenter A wants to talk to company A in datacenter B and they both have the same 10-NET addresses Andras On Sun, May 31, 2015 at 7:18 PM, Matt Palmer mpal...@hezmatt.org wrote: On Sun, May 31, 2015 at 01:38:05AM +1000, Andras Toth wrote: Perhaps if that energy which was spent on raging, instead was spent on a Google search, then all those words would've been unnecessary. Official documentation: http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/elb-internet-facing-load-balancers.html#internet-facing-ip-addresses Congratulations, you've managed to find exactly the same info as Owen already covered: Load balancers in a VPC support IPv4 addresses only. and Load balancers in EC2-Classic support both IPv4 and IPv6 addresses. - Matt
Re: BGP Multihoming 2 providers full or partial?
If your traffic is small, you could setup a VyOS box. You can still get redundancy by having two switches, each one connected to an upstream provider receiving a default route. Then hookup your VyOS router to each switch and receive full routes to that. You will need a /29 subnet from your providers to pull this off. If your VyOS box goes down for whatever reason, you will failover to using one or the other switch. Announce your prefixes using the BGP session on each switch so that your inbound traffic doesn't hit the VyOS box. -- Jason Canady Unlimited Net, LLC Responsive, Reliable, Secure www.unlimitednet.us ja...@unlimitednet.us twitter: @unlimitednet On 5/29/15 4:36 AM, Maqbool Hashim wrote: Hi, We are an enterprise that are eBGP multihoming to two ISPs. We wish to load balance in inbound and outbound traffic thereby using our capacity as efficiently as possible. My current feeling is that it would be crazy for us to take a full Internet routing table from either ISP. I have read this document from NANOG presentations: https://www.google.com/url?sa=trct=jq=esrc=ssource=webcd=1cad=rjauact=8ved=0CCoQFjAAurl=https%3A%2F%2Fwww.nanog.org%2Fmeetings%2Fnanog41%2Fpresentations%2FBGPMultihoming.pdfei=cyRnVb--FeWY7gbq4oHoAQusg=AFQjCNFsMx3NZ0Vn4bJ5zJpzFz3senbaqgbvm=bv.93990622,d.ZGU The above document reenforces my opinion that we do not need full routing tables. However I was seeking some clarity as there are other documents which suggest taking a full routing table would be optimal. I guess it depends on our criteria and requirements for load balancing: - Just care about roughly balancing link utilisation - Be nice to make some cost savings We have PI space and two Internet routers one for each ISP. Either of our links is sufficient to carry all our traffic, but we want to try and balance utilisation to remain within our commits if possible. I am thinking a rough approach for us would be: - Take partial (customer) routes from both providers - Take defaults from both and pref one Maybe we can refine the above a bit more, any suggestions would be most welcome! Many Thanks
Re: Multiple vendors' IPv6 issues
On 27/05/2015 20:35, Brian Rak wrote: You don't need full promisc mode, just the (poorly documented) allmulticast option (ip link set dev $macvtap allmulticast on) ...And poorly supported on some real hardware (notably Wi-Fi adapters), where the hash filter on each NIC's MAC is not guaranteed to support ALLMULTI. It's a prerequisite for software multicast forwarding, and, it might be argued, a good litmus test for IPv6 readiness.
Re: AWS Elastic IP architecture
On May 31, 2015, at 11:29 AM, Matthew Kaufman matt...@matthew.at wrote: Since your network has IPv6, I fail to see the issue. Nobody is anywhere near being able to go single-stack on IPv6, so AWS is just another network your customers will continue to reach over v4. So what? Sigh… The point is that all of the services and applications being built on and delivered over AWS are stuck in the IPv4 mud until such time as they can get IPv6 from AWS or move to a different cloud provider. Heck, if v6 support from a cloud hosting company is so important, I see a great business opportunity in your future. There are already several cloud hosting companies that provide full dual-stack support. I already mentioned several of them earlier in the thread, so this is a rather silly conclusion to draw from the thread as a whole. Remember where this all started… Someone asked if the internal Amazon structure was using LISP for encapsulation. I made the semi-sarcastic comment that if they were using LISP, they probably wouldn’t have so much difficulty supporting IPv6, therefore they probably aren’t using LISP. My statement was taken all sorts of other ways by various people. Nonetheless, the bottom line remains the same: AWS can’t do IPv6 outside of a very tiny limited space which provides a solution only for one particular application (pretending to provide IPv6 web services from an IPv4-only web server through a proxy). People who are building applications and considering hosting their applications in the cloud should seriously consider whether this limitation in AWS matters to them. IMHO, forward-thinking application developers will eschew AWS in favor of clouds that have dual-stack support and build dual-stack capable applications. YMMV. Owen Matthew Kaufman (Sent from my iPhone) On May 31, 2015, at 10:57 AM, Owen DeLong o...@delong.com wrote: Sigh… IPv6 has huge utility. AWS’ implementation of IPv6 is brain-dead and mostly useless for most applications. I think if you will review my track record over the last 5+ years, you will plainly see that I am fully aware of the utility and need for IPv6. http://lmgtfy.com?q=owen+delong+ipv6 http://lmgtfy.com/?q=owen+delong+ipv6 My network (AS1734) is fully dual-stacked, unlike AWS. If AWS is so convinced of the utility of IPv6, why do they continue to refuse to do a real implementation that provides IPv6 capabilities to users of their current architecture. Currently, on AWS, the only IPv6 is via ELB for classic EC2 hosts. You cannot put a native IPv6 address on an AWS virtual server at all (EC2 or VPC). Unless your application is satisfied by running an IPv4-only web server which has an IPv6 VIP proxy in front of it with some extra headers added by the proxy to help you parse out the actual source address of the connection, then your application cannot use IPv6 on AWS. As such, I stand by my statement that there is effectively no meaningful support for IPv6 in AWS, period. AWS may disagree and think that ELB for classic EC2 is somehow meaningful, but their lack of other support for any of their modern architectures and the fact that they are in the process of phasing out classic EC2 makes me think that’s a pretty hard case to make. Owen On May 31, 2015, at 9:01 AM, Blair Trosper blair.tros...@gmail.com wrote: Disagree, and so does AWS. IPv6 has a huge utility: being a universal, inter-region management network (a network that unites traffic between regions on public and private netblocks). Plus, at least the CDN and ELBs should be dual-stack, since more and more ISPs are turning on IPv6. On Sun, May 31, 2015 at 8:40 AM, Owen DeLong o...@delong.com mailto:o...@delong.com wrote: I wasn’t being specific about VPC vs. Classic. The support for IPv6 in Classic is extremely limited and basically useless for 99+% of applications. I would argue that there is, therefore, effectively no meaningful support for IPv6 in AWS, period. What you describe below seems to me that it would only make the situation I described worse, not better in the VPC world. Owen On May 31, 2015, at 4:23 AM, Andras Toth diosbej...@gmail.com mailto:diosbej...@gmail.com wrote: Congratulations for missing the point Matt, when I sent my email (which by the way went for moderation) there wasn't a discussion about Classic vs VPC yet. The discussion was no ipv6 in AWS which is not true as I mentioned in my previous email. I did not state it works everywhere, but it does work. In fact as Owen mentioned the following, I assumed he is talking about Classic because this statement is only true there. In VPC you can define your own IP subnets and it can overlap with other customers, so basically everyone can have their own 10.0.0.0/24 http://10.0.0.0/24 for example. They are known to be running multiple copies of RFC-1918 in disparate localities already. In terms
Re: BGP Multihoming 2 providers full or partial?
Well, we´re using 2x Cisco 3560X switches for simple inbound/outbound load sharing with our provider for years (http://wiki.nil.com/EBGP_load_sharing). There´s no need for us going full routes... Regards, Michael
Re: AWS Elastic IP architecture
Sigh… IPv6 has huge utility. AWS’ implementation of IPv6 is brain-dead and mostly useless for most applications. I think if you will review my track record over the last 5+ years, you will plainly see that I am fully aware of the utility and need for IPv6. http://lmgtfy.com?q=owen+delong+ipv6 http://lmgtfy.com/?q=owen+delong+ipv6 My network (AS1734) is fully dual-stacked, unlike AWS. If AWS is so convinced of the utility of IPv6, why do they continue to refuse to do a real implementation that provides IPv6 capabilities to users of their current architecture. Currently, on AWS, the only IPv6 is via ELB for classic EC2 hosts. You cannot put a native IPv6 address on an AWS virtual server at all (EC2 or VPC). Unless your application is satisfied by running an IPv4-only web server which has an IPv6 VIP proxy in front of it with some extra headers added by the proxy to help you parse out the actual source address of the connection, then your application cannot use IPv6 on AWS. As such, I stand by my statement that there is effectively no meaningful support for IPv6 in AWS, period. AWS may disagree and think that ELB for classic EC2 is somehow meaningful, but their lack of other support for any of their modern architectures and the fact that they are in the process of phasing out classic EC2 makes me think that’s a pretty hard case to make. Owen On May 31, 2015, at 9:01 AM, Blair Trosper blair.tros...@gmail.com wrote: Disagree, and so does AWS. IPv6 has a huge utility: being a universal, inter-region management network (a network that unites traffic between regions on public and private netblocks). Plus, at least the CDN and ELBs should be dual-stack, since more and more ISPs are turning on IPv6. On Sun, May 31, 2015 at 8:40 AM, Owen DeLong o...@delong.com mailto:o...@delong.com wrote: I wasn’t being specific about VPC vs. Classic. The support for IPv6 in Classic is extremely limited and basically useless for 99+% of applications. I would argue that there is, therefore, effectively no meaningful support for IPv6 in AWS, period. What you describe below seems to me that it would only make the situation I described worse, not better in the VPC world. Owen On May 31, 2015, at 4:23 AM, Andras Toth diosbej...@gmail.com mailto:diosbej...@gmail.com wrote: Congratulations for missing the point Matt, when I sent my email (which by the way went for moderation) there wasn't a discussion about Classic vs VPC yet. The discussion was no ipv6 in AWS which is not true as I mentioned in my previous email. I did not state it works everywhere, but it does work. In fact as Owen mentioned the following, I assumed he is talking about Classic because this statement is only true there. In VPC you can define your own IP subnets and it can overlap with other customers, so basically everyone can have their own 10.0.0.0/24 http://10.0.0.0/24 for example. They are known to be running multiple copies of RFC-1918 in disparate localities already. In terms of scale, modulo the nightmare that must make of their management network and the fragility of what happens when company A in datacenter A wants to talk to company A in datacenter B and they both have the same 10-NET addresses Andras On Sun, May 31, 2015 at 7:18 PM, Matt Palmer mpal...@hezmatt.org mailto:mpal...@hezmatt.org wrote: On Sun, May 31, 2015 at 01:38:05AM +1000, Andras Toth wrote: Perhaps if that energy which was spent on raging, instead was spent on a Google search, then all those words would've been unnecessary. Official documentation: http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/elb-internet-facing-load-balancers.html#internet-facing-ip-addresses http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/elb-internet-facing-load-balancers.html#internet-facing-ip-addresses Congratulations, you've managed to find exactly the same info as Owen already covered: Load balancers in a VPC support IPv4 addresses only. and Load balancers in EC2-Classic support both IPv4 and IPv6 addresses. - Matt
Re: BGP Multihoming 2 providers full or partial?
Remember this: 1) for inbound traffic there will be no difference at all. 2) routers will ignore a static route if the link is down. If you can get BFD from the providers then even better. So you can emulate 99% of what you get with full routes by loading in static routes. A simple example would be adding a 0.0.0.0/1 route to one provider and 128.0.0.0/1 route to the other and get approximately 50% load sharing. You will still get redundancy as the route will ignored if the link is down and traffic will follow the default route to the other transit provider. If you find an offline source for IP ranges originated by each provider and their peers, you can add routes for that to improve routing. Taking in partial routes is also good if this provides you with a route count that your routers can handle. BGP shortest AS length routing is really not very good to begin with. If you want the best routes, you need to analyse your traffic, sort by volume or other metric and figure out which way is best for your top x AS destinations. It may be more work, but you will get better routing compared to investing in expensive routers to take in full routes and then hope BGP magic takes cares for the rest automatically. Regards, Baldur
Re: AWS Elastic IP architecture
AWS built their network first...before IPv6 popped, so you can appreciate the huge task they have of retrofitting all their products to support it. I don't envy the task, but they have said publicly and privately that it's a priority. But it's also a massive undertaking, and you can't expect them to snap their fingers and turn it out over a weekend, man... The prize of being first cuts both ways when newer technologies at lower network levels start taking off and you don't have support built in to something proprietary. Would it be great if they had it faster? Obviously yes. Are they working on it as a priority? Yes. Can they go any faster? Probably. Are there other choices for cloud providers that are full dual stack if this really is a live or die issue for you? Yes. Access to dual-stack isn't a fundamental human right. If you don't like what AWS is doing, then use someone else who has dualstack. I don't get the outrage...and it's so irrational, that you've caused me to actually *defend* AWS. bt On Sun, May 31, 2015 at 1:29 PM, Matthew Kaufman matt...@matthew.at wrote: Since your network has IPv6, I fail to see the issue. Nobody is anywhere near being able to go single-stack on IPv6, so AWS is just another network your customers will continue to reach over v4. So what? Heck, if v6 support from a cloud hosting company is so important, I see a great business opportunity in your future. Matthew Kaufman (Sent from my iPhone) On May 31, 2015, at 10:57 AM, Owen DeLong o...@delong.com wrote: Sigh… IPv6 has huge utility. AWS’ implementation of IPv6 is brain-dead and mostly useless for most applications. I think if you will review my track record over the last 5+ years, you will plainly see that I am fully aware of the utility and need for IPv6. http://lmgtfy.com?q=owen+delong+ipv6 http://lmgtfy.com/?q=owen+delong+ipv6 My network (AS1734) is fully dual-stacked, unlike AWS. If AWS is so convinced of the utility of IPv6, why do they continue to refuse to do a real implementation that provides IPv6 capabilities to users of their current architecture. Currently, on AWS, the only IPv6 is via ELB for classic EC2 hosts. You cannot put a native IPv6 address on an AWS virtual server at all (EC2 or VPC). Unless your application is satisfied by running an IPv4-only web server which has an IPv6 VIP proxy in front of it with some extra headers added by the proxy to help you parse out the actual source address of the connection, then your application cannot use IPv6 on AWS. As such, I stand by my statement that there is effectively no meaningful support for IPv6 in AWS, period. AWS may disagree and think that ELB for classic EC2 is somehow meaningful, but their lack of other support for any of their modern architectures and the fact that they are in the process of phasing out classic EC2 makes me think that’s a pretty hard case to make. Owen On May 31, 2015, at 9:01 AM, Blair Trosper blair.tros...@gmail.com wrote: Disagree, and so does AWS. IPv6 has a huge utility: being a universal, inter-region management network (a network that unites traffic between regions on public and private netblocks). Plus, at least the CDN and ELBs should be dual-stack, since more and more ISPs are turning on IPv6. On Sun, May 31, 2015 at 8:40 AM, Owen DeLong o...@delong.com mailto: o...@delong.com wrote: I wasn’t being specific about VPC vs. Classic. The support for IPv6 in Classic is extremely limited and basically useless for 99+% of applications. I would argue that there is, therefore, effectively no meaningful support for IPv6 in AWS, period. What you describe below seems to me that it would only make the situation I described worse, not better in the VPC world. Owen On May 31, 2015, at 4:23 AM, Andras Toth diosbej...@gmail.com mailto:diosbej...@gmail.com wrote: Congratulations for missing the point Matt, when I sent my email (which by the way went for moderation) there wasn't a discussion about Classic vs VPC yet. The discussion was no ipv6 in AWS which is not true as I mentioned in my previous email. I did not state it works everywhere, but it does work. In fact as Owen mentioned the following, I assumed he is talking about Classic because this statement is only true there. In VPC you can define your own IP subnets and it can overlap with other customers, so basically everyone can have their own 10.0.0.0/24 http://10.0.0.0/24 for example. They are known to be running multiple copies of RFC-1918 in disparate localities already. In terms of scale, modulo the nightmare that must make of their management network and the fragility of what happens when company A in datacenter A wants to talk to company A in datacenter B and they both have the same 10-NET addresses Andras On Sun, May 31, 2015 at 7:18 PM, Matt Palmer mpal...@hezmatt.org mailto:mpal...@hezmatt.org wrote:
RE: WiFi courses/vendors recommendation
I don't have a vendor-agnostic answer for you on #1, but as far as a vendor - Ruckus Wireless. We are a partner who sells and deploys and the stuff is quite awesome for what you're looking for. I'd be happy to introduce you to relevant people over there for guidance. Regards, James Laszko Mythos Technology Inc jam...@mythostech.com -Original Message- From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Abdullah Medhat Sent: Sunday, May 31, 2015 3:07 AM To: nanog@nanog.org Subject: WiFi courses/vendors recommendation Good day all, We are looking forward to establish MetroWifi network as a new business line in our company, in addition to small/medium events Wifi coverage. I have two questions: 1. What are the required resources/material/training curriculum to let our engineers start educating in this? We are looking for the vendor-agnostic materials that will give our engineers the WiFi essentials/fundamentals to start building a good foundation before evolving to the professional level. 2. What vendors do you recommend? We need to find a cost-effective yet competent option with good pre/post sales service. Thanks, -- Abdullah Medhat
Re: AWS Elastic IP architecture
On 5/31/15, 3:11 PM, Owen DeLong o...@delong.com wrote: if they said “We have a plan, and it will take X amount of time”, I would respect that. If they said “We have a plan and we’re not sure how long it will take”, I would continue to poke them about sooner is better than later and having a target date helps people to plan. “We don’t think IPv6 matters and we aren’t announcing any plans to get it implemented or any date by which it will be available”, on the other hand, being what they have actually repeatedly said to me until very recently, not so much. Now, they’re saying (essentially) “We think IPv6 might matter, but we aren’t announcing any plans to get it implemented or any date by which it will be available” . To me, this is still a problematic situation for their customers. At the risk of feeding the troll... This isn't just an AWS problem. All Compute Engine networks use the IPv4 protocol. Compute Engine currently does not support IPv6. However, Google is a major advocate of IPv6 and it is an important future direction. https://cloud.google.com/compute/docs/networking The foundational work to enable IPv6 in the Azure environment is well underway. However, we are unable to share a date when IPv6 support will be generally available at this time. http://azure.microsoft.com/en-us/pricing/faq/ This is only marginally better, as it acknowledges that it's important, but still has no actual committed timeline and doesn't even reference any available ELB hacks. Anyone else want to either name and shame, or highlight cloud providers that actually *support* IPv6 as an alternative to these so that one might be able to vote with one's wallet? This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.
Re: AWS Elastic IP architecture
On 5/31/2015 11:57 AM, Owen DeLong wrote: People who are building applications and considering hosting their applications in the cloud should seriously consider whether this limitation in AWS matters to them. It doesn't, because everyone on the Internet can reach IPv4-hosted services. IMHO, forward-thinking application developers will eschew AWS in favor of clouds that have dual-stack support and build dual-stack capable applications. Forward-thinking developers are using big clouds that have the resources to enable IPv6 long before having IPv6 actually matters. Matthew Kaufman
Re: AWS Elastic IP architecture
As I said before: Host Virtual (vr.org http://vr.org/) Softlayer (softlayer.com http://softlayer.com/) Linode (Linode.com http://linode.com/) All have full dual-stack support. I’m sure there are others. Owen On May 31, 2015, at 2:49 PM, George, Wes wesley.geo...@twcable.com wrote: On 5/31/15, 3:11 PM, Owen DeLong o...@delong.com wrote: if they said “We have a plan, and it will take X amount of time”, I would respect that. If they said “We have a plan and we’re not sure how long it will take”, I would continue to poke them about sooner is better than later and having a target date helps people to plan. “We don’t think IPv6 matters and we aren’t announcing any plans to get it implemented or any date by which it will be available”, on the other hand, being what they have actually repeatedly said to me until very recently, not so much. Now, they’re saying (essentially) “We think IPv6 might matter, but we aren’t announcing any plans to get it implemented or any date by which it will be available” . To me, this is still a problematic situation for their customers. At the risk of feeding the troll... This isn't just an AWS problem. All Compute Engine networks use the IPv4 protocol. Compute Engine currently does not support IPv6. However, Google is a major advocate of IPv6 and it is an important future direction. https://cloud.google.com/compute/docs/networking The foundational work to enable IPv6 in the Azure environment is well underway. However, we are unable to share a date when IPv6 support will be generally available at this time. http://azure.microsoft.com/en-us/pricing/faq/ This is only marginally better, as it acknowledges that it's important, but still has no actual committed timeline and doesn't even reference any available ELB hacks. Anyone else want to either name and shame, or highlight cloud providers that actually *support* IPv6 as an alternative to these so that one might be able to vote with one's wallet? This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.
Re: AWS Elastic IP architecture
On Sun, May 31, 2015 at 9:07 PM, Owen DeLong o...@delong.com wrote: As I said before: Host Virtual (vr.org http://vr.org/) Softlayer (softlayer.com http://softlayer.com/) Linode (Linode.com http://linode.com/) All have full dual-stack support. snip At the risk of feeding the troll... This isn't just an AWS problem. So... ok. What does it mean, for a customer of a cloud service, to be ipv6 enabled? What really matters for a cloud service user? What information could be surfaced to the cloud providers in order to get the most important ipv6 'stuff' done 'now'? o Is it most important to be able to address ever VM you create with an ipv6 address? o Is it most important to be able to talk to backend services (perhaps at your prem) over ipv6? o Is it most important that administrative interfaces to the VM systems (either REST/etc interfaces for managing vms or 'ssh'/etc) be ipv6 reachable? o Is it most important to be able to terminate ipv6 connections (or datagrams) on a VM service for the public to use? I don't see, especially if the vm networking is unique to each customer, that 'ipv6 address on vm' is hugely important as a first/important goal. I DO see that landing publicly available services on an ipv6 endpoint is super helpful. Would AWS (or any other cloud provider that's not currently up on the v6 bandwagon) enabling a loadbalanced ipv6 vip for your public service (perhaps not just http/s services even?) be enough to relieve some of the pressure on other parties and move the ball forward meaningfully enough for the cloud providers and their customers? -chris
WiFi courses/vendors recommendation
Good day all, We are looking forward to establish MetroWifi network as a new business line in our company, in addition to small/medium events Wifi coverage. I have two questions: 1. What are the required resources/material/training curriculum to let our engineers start educating in this? We are looking for the vendor-agnostic materials that will give our engineers the WiFi essentials/fundamentals to start building a good foundation before evolving to the professional level. 2. What vendors do you recommend? We need to find a cost-effective yet competent option with good pre/post sales service. Thanks, -- Abdullah Medhat
Re: WiFi courses/vendors recommendation
You may want to check out iBwave. They do training as well. Ilissa Miller On May 31, 2015, at 3:27 PM, Abdullah Medhat abdullah.medhat.sa...@gmail.com wrote: Good day all, We are looking forward to establish MetroWifi network as a new business line in our company, in addition to small/medium events Wifi coverage. I have two questions: 1. What are the required resources/material/training curriculum to let our engineers start educating in this? We are looking for the vendor-agnostic materials that will give our engineers the WiFi essentials/fundamentals to start building a good foundation before evolving to the professional level. 2. What vendors do you recommend? We need to find a cost-effective yet competent option with good pre/post sales service. Thanks, -- Abdullah Medhat
Re: WiFi courses/vendors recommendation
On Sun, May 31, 2015 at 3:28 PM, James Laszko jam...@mythostech.com wrote: I don't have a vendor-agnostic answer for you on #1, but as far as a vendor - Ruckus Wireless. We are a partner who sells and deploys and the stuff is quite awesome for what you're looking for. I'd be happy to introduce you to relevant people over there for guidance. 1) I have long thought about developing such course materials or working with the author (dave lang) of the wonderful scale2012 report to do so. If you find any good materials pre-existing please let me know also. I once gave a good intro talk on wifi subjects... ( https://www.youtube.com/watch?v=Wksh2DPHCDI ) As for 2) There are many vendors in the enterprise wifi space - cisco, ubnt, aruba, and meraki, to name a few more. Of these the only ones publicly acknowledging doing something about their wifi bufferbloat are cisco and meraki. (I realize you have plenty of other issues/features to look for, it's fixing that one happens to be my number #1 requirement these days) Regards, James Laszko Mythos Technology Inc jam...@mythostech.com -Original Message- From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Abdullah Medhat Sent: Sunday, May 31, 2015 3:07 AM To: nanog@nanog.org Subject: WiFi courses/vendors recommendation Good day all, We are looking forward to establish MetroWifi network as a new business line in our company, in addition to small/medium events Wifi coverage. I have two questions: 1. What are the required resources/material/training curriculum to let our engineers start educating in this? We are looking for the vendor-agnostic materials that will give our engineers the WiFi essentials/fundamentals to start building a good foundation before evolving to the professional level. 2. What vendors do you recommend? We need to find a cost-effective yet competent option with good pre/post sales service. Thanks, -- Abdullah Medhat -- Dave Täht What will it take to vastly improve wifi for everyone? https://plus.google.com/u/0/explore/makewififast
RE: WiFi courses/vendors recommendation
Ubiquiti Networks. Its cheap and it works great. Support sucks though. I use Ubuquiti gear for my wireless ISP and i use their UniFi APs for when i do events. If you need high density wireless, check out Xirrus Wireless access points, they are awesome. -Mike On May 31, 2015 3:30 PM, James Laszko jam...@mythostech.com wrote: I don't have a vendor-agnostic answer for you on #1, but as far as a vendor - Ruckus Wireless. We are a partner who sells and deploys and the stuff is quite awesome for what you're looking for. I'd be happy to introduce you to relevant people over there for guidance. Regards, James Laszko Mythos Technology Inc jam...@mythostech.com -Original Message- From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Abdullah Medhat Sent: Sunday, May 31, 2015 3:07 AM To: nanog@nanog.org Subject: WiFi courses/vendors recommendation Good day all, We are looking forward to establish MetroWifi network as a new business line in our company, in addition to small/medium events Wifi coverage. I have two questions: 1. What are the required resources/material/training curriculum to let our engineers start educating in this? We are looking for the vendor-agnostic materials that will give our engineers the WiFi essentials/fundamentals to start building a good foundation before evolving to the professional level. 2. What vendors do you recommend? We need to find a cost-effective yet competent option with good pre/post sales service. Thanks, -- Abdullah Medhat
Re: AWS Elastic IP architecture
On Sun, May 31, 2015 at 10:46:02PM -0400, Christopher Morrow wrote: So... ok. What does it mean, for a customer of a cloud service, to be ipv6 enabled? IPv6 feature-parity with IPv4. My must-haves, sorted in order of importance (most to least): o Is it most important to be able to terminate ipv6 connections (or datagrams) on a VM service for the public to use? o Is it most important to be able to address ever VM you create with an ipv6 address? o Is it most important to be able to talk to backend services (perhaps at your prem) over ipv6? If, by backend services, you mean things like RDS, S3, etc, this is in the right place. o Is it most important that administrative interfaces to the VM systems (either REST/etc interfaces for managing vms or 'ssh'/etc) be ipv6 reachable? I don't see, especially if the vm networking is unique to each customer, that 'ipv6 address on vm' is hugely important as a first/important goal. I DO see that landing publicly available services on an ipv6 endpoint is super helpful. Being able to address VMs over IPv6 (and have VMs talk to the outside world over IPv6) is *really* useful. Takes away the need to NAT anything. Would AWS (or any other cloud provider that's not currently up on the v6 bandwagon) enabling a loadbalanced ipv6 vip for your public service (perhaps not just http/s services even?) be enough to relieve some of the pressure on other parties and move the ball forward meaningfully enough for the cloud providers and their customers? No. I'm currently building an infrastructure which is entirely v6-native internally; the only parts which are IPv4 are public-facing incoming service endpoints, and outgoing connections to other parts of the Internet, which are proxied. Everything else is talking amongst themselves entirely over IPv6. - Matt -- After years of studying math and encountering surprising and counterintuitive results, I came to accept that math is always reasonable, by my intuition of what is reasonably is not always reasonable. -- Steve VanDevender, ASR
Re: AWS Elastic IP architecture
Perhaps if that energy which was spent on raging, instead was spent on a Google search, then all those words would've been unnecessary. As it turns out that IPv6 is already available on ELBs since 2011: https://aws.amazon.com/blogs/aws/elastic-load-balancing-ipv6-zone-apex-support-additional-security/ Official documentation: http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/elb-internet-facing-load-balancers.html#internet-facing-ip-addresses Netflix is using it already as per their techblog since 2012: http://techblog.netflix.com/2012/07/enabling-support-for-ipv6.html Regards, Andras On Sat, May 30, 2015 at 11:04 AM, Owen DeLong o...@delong.com wrote: On May 29, 2015, at 8:23 AM, Christopher Morrow morrowc.li...@gmail.com wrote: On Fri, May 29, 2015 at 3:45 AM, Owen DeLong o...@delong.com wrote: Yeah, if it were LISP, they could probably handle IPv6. why can't they do v6 with any other encap? That’s not my point. the encap really doesn't matter at all to the underlying ip protocol used, or shouldn't... you decide at the entrance to the 'virtual network' that 'thingy is in virtual-network-5 and encap the packet... regardless of ip version of the thing you are encapsulating. Whatever encapsulation or other system they are using, clearly they can’t do IPv6 for some reason because they outright refuse to even offer so much as a verification that IPv6 is on any sort of roadmap or is at all likely to be considered for deployment any time in the foreseeable future. So, my point wasn’t that LISP is the only encapsulation that supports IPv6. Indeed, I didn’t even say that. What I said was that their apparent complete inability to do IPv6 makes it unlikely that they are using an IPv6-capable encapsulation system. Thus, it is unlikely they are using LISP. I only referenced LISP because it was specifically mentioned by the poster to whom I was responding. Please try to avoid putting words in my mouth in the future. Owen
BGP Multihoming 2 providers full or partial?
Hi, We are an enterprise that are eBGP multihoming to two ISPs. We wish to load balance in inbound and outbound traffic thereby using our capacity as efficiently as possible. My current feeling is that it would be crazy for us to take a full Internet routing table from either ISP. I have read this document from NANOG presentations: https://www.google.com/url?sa=trct=jq=esrc=ssource=webcd=1cad=rjauact=8ved=0CCoQFjAAurl=https%3A%2F%2Fwww.nanog.org%2Fmeetings%2Fnanog41%2Fpresentations%2FBGPMultihoming.pdfei=cyRnVb--FeWY7gbq4oHoAQusg=AFQjCNFsMx3NZ0Vn4bJ5zJpzFz3senbaqgbvm=bv.93990622,d.ZGU The above document reenforces my opinion that we do not need full routing tables. However I was seeking some clarity as there are other documents which suggest taking a full routing table would be optimal. I guess it depends on our criteria and requirements for load balancing: - Just care about roughly balancing link utilisation - Be nice to make some cost savings We have PI space and two Internet routers one for each ISP. Either of our links is sufficient to carry all our traffic, but we want to try and balance utilisation to remain within our commits if possible. I am thinking a rough approach for us would be: - Take partial (customer) routes from both providers - Take defaults from both and pref one Maybe we can refine the above a bit more, any suggestions would be most welcome! Many Thanks
Re: AWS Elastic IP architecture
On Sun, May 31, 2015 at 01:38:05AM +1000, Andras Toth wrote: Perhaps if that energy which was spent on raging, instead was spent on a Google search, then all those words would've been unnecessary. Official documentation: http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/elb-internet-facing-load-balancers.html#internet-facing-ip-addresses Congratulations, you've managed to find exactly the same info as Owen already covered: Load balancers in a VPC support IPv4 addresses only. and Load balancers in EC2-Classic support both IPv4 and IPv6 addresses. - Matt
Re: AWS Elastic IP architecture
Congratulations for missing the point Matt, when I sent my email (which by the way went for moderation) there wasn't a discussion about Classic vs VPC yet. The discussion was no ipv6 in AWS which is not true as I mentioned in my previous email. I did not state it works everywhere, but it does work. In fact as Owen mentioned the following, I assumed he is talking about Classic because this statement is only true there. In VPC you can define your own IP subnets and it can overlap with other customers, so basically everyone can have their own 10.0.0.0/24 for example. They are known to be running multiple copies of RFC-1918 in disparate localities already. In terms of scale, modulo the nightmare that must make of their management network and the fragility of what happens when company A in datacenter A wants to talk to company A in datacenter B and they both have the same 10-NET addresses Andras On Sun, May 31, 2015 at 7:18 PM, Matt Palmer mpal...@hezmatt.org wrote: On Sun, May 31, 2015 at 01:38:05AM +1000, Andras Toth wrote: Perhaps if that energy which was spent on raging, instead was spent on a Google search, then all those words would've been unnecessary. Official documentation: http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/elb-internet-facing-load-balancers.html#internet-facing-ip-addresses Congratulations, you've managed to find exactly the same info as Owen already covered: Load balancers in a VPC support IPv4 addresses only. and Load balancers in EC2-Classic support both IPv4 and IPv6 addresses. - Matt
Re: BGP Multihoming 2 providers full or partial?
If you wish to do outbound traffic engineering, and want to take advantage of best paths to different networks (outbound), then you have to take full routes. Or putting it another way Taking full routes offers the most flexibility, anything else would be a compromise (an acceptable compromise) to overcome some existing resource limitations... Regards. Faisal Imtiaz Snappy Internet Telecom 7266 SW 48 Street Miami, FL 33155 Tel: 305 663 5518 x 232 Help-desk: (305)663-5518 Option 2 or Email: supp...@snappytelecom.net - Original Message - From: Maqbool Hashim maqb...@madbull.info To: nanog@nanog.org Sent: Friday, May 29, 2015 4:36:34 AM Subject: BGP Multihoming 2 providers full or partial? Hi, We are an enterprise that are eBGP multihoming to two ISPs. We wish to load balance in inbound and outbound traffic thereby using our capacity as efficiently as possible. My current feeling is that it would be crazy for us to take a full Internet routing table from either ISP. I have read this document from NANOG presentations: https://www.google.com/url?sa=trct=jq=esrc=ssource=webcd=1cad=rjauact=8ved=0CCoQFjAAurl=https%3A%2F%2Fwww.nanog.org%2Fmeetings%2Fnanog41%2Fpresentations%2FBGPMultihoming.pdfei=cyRnVb--FeWY7gbq4oHoAQusg=AFQjCNFsMx3NZ0Vn4bJ5zJpzFz3senbaqgbvm=bv.93990622,d.ZGU The above document reenforces my opinion that we do not need full routing tables. However I was seeking some clarity as there are other documents which suggest taking a full routing table would be optimal. I guess it depends on our criteria and requirements for load balancing: - Just care about roughly balancing link utilisation - Be nice to make some cost savings We have PI space and two Internet routers one for each ISP. Either of our links is sufficient to carry all our traffic, but we want to try and balance utilisation to remain within our commits if possible. I am thinking a rough approach for us would be: - Take partial (customer) routes from both providers - Take defaults from both and pref one Maybe we can refine the above a bit more, any suggestions would be most welcome! Many Thanks
Re: AWS Elastic IP architecture
Point of clarification: AWS customer IP subnets can overlap, but customer VPCs that encompass overlapping subnets cannot peer with each other. In other words, the standard arguments in favor of address uniqueness still apply. TV On May 31, 2015 7:23:37 AM EDT, Andras Toth diosbej...@gmail.com wrote: Congratulations for missing the point Matt, when I sent my email (which by the way went for moderation) there wasn't a discussion about Classic vs VPC yet. The discussion was no ipv6 in AWS which is not true as I mentioned in my previous email. I did not state it works everywhere, but it does work. In fact as Owen mentioned the following, I assumed he is talking about Classic because this statement is only true there. In VPC you can define your own IP subnets and it can overlap with other customers, so basically everyone can have their own 10.0.0.0/24 for example. They are known to be running multiple copies of RFC-1918 in disparate localities already. In terms of scale, modulo the nightmare that must make of their management network and the fragility of what happens when company A in datacenter A wants to talk to company A in datacenter B and they both have the same 10-NET addresses Andras On Sun, May 31, 2015 at 7:18 PM, Matt Palmer mpal...@hezmatt.org wrote: On Sun, May 31, 2015 at 01:38:05AM +1000, Andras Toth wrote: Perhaps if that energy which was spent on raging, instead was spent on a Google search, then all those words would've been unnecessary. Official documentation: http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/elb-internet-facing-load-balancers.html#internet-facing-ip-addresses Congratulations, you've managed to find exactly the same info as Owen already covered: Load balancers in a VPC support IPv4 addresses only. and Load balancers in EC2-Classic support both IPv4 and IPv6 addresses. - Matt -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: BGP Multihoming 2 providers full or partial?
BGP traffic engineering is kind of like Soda Prefer. that folks have Some like Pepsi, some Like Coke, some don't care as long as it is Cold and fizzy. Depending on who your two providers are, you may be happy with just taking full routes, and doing some creative routing (i.e. setting up static routes for outbound for specific prefixes, not the most elegant solution). Remember, BGP allows for Asymmetric routing, as such with default routes, you will have traffic coming in from both providers (by default) and traffic going out via one of them (by default). At the end of the day you are most likely to make a decision based on what is your cost for having a more powerful router, and how much 'creative routing' you want to / need to do. (My Personal opinion, is that it is a 50/50 decision to upgrade hardware just to take full routing tables.. however if there are other reasons or needs, that can sway the decision in one direction or the other). :) Faisal Imtiaz Snappy Internet Telecom - Original Message - From: Maqbool Hashim maqb...@madbull.info To: Joseph Jackson jjack...@aninetworks.net, nanog@nanog.org Sent: Sunday, May 31, 2015 8:09:02 AM Subject: RE: BGP Multihoming 2 providers full or partial? Hi, No the current devices can't support full table (well not from both providers) we would need to upgrade. Really in terms of cost saving just want to make sure to not get charged overages because we utilise too much of one link and not enough of another. I don't think the shortest AS path will be of that much concern or noticeable for most destinations. We do however have a set of remote sites which communicate over the Internet to our central sites where the transit providers are. Just general Internet at the remote sites- but traffic from remote sites to central sites would be the most important. I am just not sure of exactly how to define the partial routing table criteria to our two providers. Should we just take routes for each provider and their peers and a default from both? The main reason for not taking a full routing table is the cost/inconvenience of upgrading existing hardware. Thanks -Original Message- From: Joseph Jackson [mailto:jjack...@aninetworks.net] Sent: 31 May 2015 12:41 To: Maqbool Hashim; nanog@nanog.org Subject: RE: BGP Multihoming 2 providers full or partial? Can your devices support a full table? You can load balance outbound traffic easily with out doing a full table. THo that won't be the shortest AS path. In regards to cost savings how were you thinking of doing so? Does one provider charge more? Just use the cheaper provider. -Original Message- From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Maqbool Hashim Sent: Friday, May 29, 2015 3:37 AM To: nanog@nanog.org Subject: BGP Multihoming 2 providers full or partial? Hi, We are an enterprise that are eBGP multihoming to two ISPs. We wish to load balance in inbound and outbound traffic thereby using our capacity as efficiently as possible. My current feeling is that it would be crazy for us to take a full Internet routing table from either ISP. I have read this document from NANOG presentations: https://www.google.com/url?sa=trct=jq=esrc=ssource=webcd=1cad=rjauact=8ved=0CCoQFjAAurl=https%3A%2F%2Fwww.nanog.org%2Fmeetings%2Fnanog41%2Fpresentations%2FBGPMultihoming.pdfei=cyRnVb--FeWY7gbq4oHoAQusg=AFQjCNFsMx3NZ0Vn4bJ5zJpzFz3senbaqgbvm=bv.93990622,d.ZGU The above document reenforces my opinion that we do not need full routing tables. However I was seeking some clarity as there are other documents which suggest taking a full routing table would be optimal. I guess it depends on our criteria and requirements for load balancing: - Just care about roughly balancing link utilisation - Be nice to make some cost savings We have PI space and two Internet routers one for each ISP. Either of our links is sufficient to carry all our traffic, but we want to try and balance utilisation to remain within our commits if possible. I am thinking a rough approach for us would be: - Take partial (customer) routes from both providers - Take defaults from both and pref one Maybe we can refine the above a bit more, any suggestions would be most welcome! Many Thanks
Re: AWS Elastic IP architecture
I wasn’t being specific about VPC vs. Classic. The support for IPv6 in Classic is extremely limited and basically useless for 99+% of applications. I would argue that there is, therefore, effectively no meaningful support for IPv6 in AWS, period. What you describe below seems to me that it would only make the situation I described worse, not better in the VPC world. Owen On May 31, 2015, at 4:23 AM, Andras Toth diosbej...@gmail.com wrote: Congratulations for missing the point Matt, when I sent my email (which by the way went for moderation) there wasn't a discussion about Classic vs VPC yet. The discussion was no ipv6 in AWS which is not true as I mentioned in my previous email. I did not state it works everywhere, but it does work. In fact as Owen mentioned the following, I assumed he is talking about Classic because this statement is only true there. In VPC you can define your own IP subnets and it can overlap with other customers, so basically everyone can have their own 10.0.0.0/24 for example. They are known to be running multiple copies of RFC-1918 in disparate localities already. In terms of scale, modulo the nightmare that must make of their management network and the fragility of what happens when company A in datacenter A wants to talk to company A in datacenter B and they both have the same 10-NET addresses Andras On Sun, May 31, 2015 at 7:18 PM, Matt Palmer mpal...@hezmatt.org wrote: On Sun, May 31, 2015 at 01:38:05AM +1000, Andras Toth wrote: Perhaps if that energy which was spent on raging, instead was spent on a Google search, then all those words would've been unnecessary. Official documentation: http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/elb-internet-facing-load-balancers.html#internet-facing-ip-addresses Congratulations, you've managed to find exactly the same info as Owen already covered: Load balancers in a VPC support IPv4 addresses only. and Load balancers in EC2-Classic support both IPv4 and IPv6 addresses. - Matt
RE: BGP Multihoming 2 providers full or partial?
Can your devices support a full table? You can load balance outbound traffic easily with out doing a full table. THo that won't be the shortest AS path. In regards to cost savings how were you thinking of doing so? Does one provider charge more? Just use the cheaper provider. -Original Message- From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Maqbool Hashim Sent: Friday, May 29, 2015 3:37 AM To: nanog@nanog.org Subject: BGP Multihoming 2 providers full or partial? Hi, We are an enterprise that are eBGP multihoming to two ISPs. We wish to load balance in inbound and outbound traffic thereby using our capacity as efficiently as possible. My current feeling is that it would be crazy for us to take a full Internet routing table from either ISP. I have read this document from NANOG presentations: https://www.google.com/url?sa=trct=jq=esrc=ssource=webcd=1cad=rjauact=8ved=0CCoQFjAAurl=https%3A%2F%2Fwww.nanog.org%2Fmeetings%2Fnanog41%2Fpresentations%2FBGPMultihoming.pdfei=cyRnVb--FeWY7gbq4oHoAQusg=AFQjCNFsMx3NZ0Vn4bJ5zJpzFz3senbaqgbvm=bv.93990622,d.ZGU The above document reenforces my opinion that we do not need full routing tables. However I was seeking some clarity as there are other documents which suggest taking a full routing table would be optimal. I guess it depends on our criteria and requirements for load balancing: - Just care about roughly balancing link utilisation - Be nice to make some cost savings We have PI space and two Internet routers one for each ISP. Either of our links is sufficient to carry all our traffic, but we want to try and balance utilisation to remain within our commits if possible. I am thinking a rough approach for us would be: - Take partial (customer) routes from both providers - Take defaults from both and pref one Maybe we can refine the above a bit more, any suggestions would be most welcome! Many Thanks
RE: BGP Multihoming 2 providers full or partial?
Hi, No the current devices can't support full table (well not from both providers) we would need to upgrade. Really in terms of cost saving just want to make sure to not get charged overages because we utilise too much of one link and not enough of another. I don't think the shortest AS path will be of that much concern or noticeable for most destinations. We do however have a set of remote sites which communicate over the Internet to our central sites where the transit providers are. Just general Internet at the remote sites- but traffic from remote sites to central sites would be the most important. I am just not sure of exactly how to define the partial routing table criteria to our two providers. Should we just take routes for each provider and their peers and a default from both? The main reason for not taking a full routing table is the cost/inconvenience of upgrading existing hardware. Thanks -Original Message- From: Joseph Jackson [mailto:jjack...@aninetworks.net] Sent: 31 May 2015 12:41 To: Maqbool Hashim; nanog@nanog.org Subject: RE: BGP Multihoming 2 providers full or partial? Can your devices support a full table? You can load balance outbound traffic easily with out doing a full table. THo that won't be the shortest AS path. In regards to cost savings how were you thinking of doing so? Does one provider charge more? Just use the cheaper provider. -Original Message- From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Maqbool Hashim Sent: Friday, May 29, 2015 3:37 AM To: nanog@nanog.org Subject: BGP Multihoming 2 providers full or partial? Hi, We are an enterprise that are eBGP multihoming to two ISPs. We wish to load balance in inbound and outbound traffic thereby using our capacity as efficiently as possible. My current feeling is that it would be crazy for us to take a full Internet routing table from either ISP. I have read this document from NANOG presentations: https://www.google.com/url?sa=trct=jq=esrc=ssource=webcd=1cad=rjauact=8ved=0CCoQFjAAurl=https%3A%2F%2Fwww.nanog.org%2Fmeetings%2Fnanog41%2Fpresentations%2FBGPMultihoming.pdfei=cyRnVb--FeWY7gbq4oHoAQusg=AFQjCNFsMx3NZ0Vn4bJ5zJpzFz3senbaqgbvm=bv.93990622,d.ZGU The above document reenforces my opinion that we do not need full routing tables. However I was seeking some clarity as there are other documents which suggest taking a full routing table would be optimal. I guess it depends on our criteria and requirements for load balancing: - Just care about roughly balancing link utilisation - Be nice to make some cost savings We have PI space and two Internet routers one for each ISP. Either of our links is sufficient to carry all our traffic, but we want to try and balance utilisation to remain within our commits if possible. I am thinking a rough approach for us would be: - Take partial (customer) routes from both providers - Take defaults from both and pref one Maybe we can refine the above a bit more, any suggestions would be most welcome! Many Thanks
RE: BGP Multihoming 2 providers full or partial?
Thanks, So we just need to take a decision on whether we want to pay the price for a full routing table, whether it gives us enough value for the expenditure. -Original Message- From: Faisal Imtiaz [mailto:fai...@snappytelecom.net] Sent: 31 May 2015 13:06 To: Maqbool Hashim Cc: nanog@nanog.org Subject: Re: BGP Multihoming 2 providers full or partial? If you wish to do outbound traffic engineering, and want to take advantage of best paths to different networks (outbound), then you have to take full routes. Or putting it another way Taking full routes offers the most flexibility, anything else would be a compromise (an acceptable compromise) to overcome some existing resource limitations... Regards. Faisal Imtiaz Snappy Internet Telecom 7266 SW 48 Street Miami, FL 33155 Tel: 305 663 5518 x 232 Help-desk: (305)663-5518 Option 2 or Email: supp...@snappytelecom.net - Original Message - From: Maqbool Hashim maqb...@madbull.info To: nanog@nanog.org Sent: Friday, May 29, 2015 4:36:34 AM Subject: BGP Multihoming 2 providers full or partial? Hi, We are an enterprise that are eBGP multihoming to two ISPs. We wish to load balance in inbound and outbound traffic thereby using our capacity as efficiently as possible. My current feeling is that it would be crazy for us to take a full Internet routing table from either ISP. I have read this document from NANOG presentations: https://www.google.com/url?sa=trct=jq=esrc=ssource=webcd=1cad=rj auact=8ved=0CCoQFjAAurl=https%3A%2F%2Fwww.nanog.org%2Fmeetings%2Fna nog41%2Fpresentations%2FBGPMultihoming.pdfei=cyRnVb--FeWY7gbq4oHoAQu sg=AFQjCNFsMx3NZ0Vn4bJ5zJpzFz3senbaqgbvm=bv.93990622,d.ZGU The above document reenforces my opinion that we do not need full routing tables. However I was seeking some clarity as there are other documents which suggest taking a full routing table would be optimal. I guess it depends on our criteria and requirements for load balancing: - Just care about roughly balancing link utilisation - Be nice to make some cost savings We have PI space and two Internet routers one for each ISP. Either of our links is sufficient to carry all our traffic, but we want to try and balance utilisation to remain within our commits if possible. I am thinking a rough approach for us would be: - Take partial (customer) routes from both providers - Take defaults from both and pref one Maybe we can refine the above a bit more, any suggestions would be most welcome! Many Thanks
Re: BGP Multihoming 2 providers full or partial?
Interesting... is the cost associated with full tables just for the Hardware or is the service provider charging extra for the full table. Faisal Imtiaz Snappy Internet Telecom 7266 SW 48 Street Miami, FL 33155 Tel: 305 663 5518 x 232 Help-desk: (305)663-5518 Option 2 or Email: supp...@snappytelecom.net - Original Message - From: Maqbool Hashim maqb...@madbull.info To: Faisal Imtiaz fai...@snappytelecom.net Cc: nanog@nanog.org Sent: Sunday, May 31, 2015 8:10:51 AM Subject: RE: BGP Multihoming 2 providers full or partial? Thanks, So we just need to take a decision on whether we want to pay the price for a full routing table, whether it gives us enough value for the expenditure. -Original Message- From: Faisal Imtiaz [mailto:fai...@snappytelecom.net] Sent: 31 May 2015 13:06 To: Maqbool Hashim Cc: nanog@nanog.org Subject: Re: BGP Multihoming 2 providers full or partial? If you wish to do outbound traffic engineering, and want to take advantage of best paths to different networks (outbound), then you have to take full routes. Or putting it another way Taking full routes offers the most flexibility, anything else would be a compromise (an acceptable compromise) to overcome some existing resource limitations... Regards. Faisal Imtiaz Snappy Internet Telecom 7266 SW 48 Street Miami, FL 33155 Tel: 305 663 5518 x 232 Help-desk: (305)663-5518 Option 2 or Email: supp...@snappytelecom.net - Original Message - From: Maqbool Hashim maqb...@madbull.info To: nanog@nanog.org Sent: Friday, May 29, 2015 4:36:34 AM Subject: BGP Multihoming 2 providers full or partial? Hi, We are an enterprise that are eBGP multihoming to two ISPs. We wish to load balance in inbound and outbound traffic thereby using our capacity as efficiently as possible. My current feeling is that it would be crazy for us to take a full Internet routing table from either ISP. I have read this document from NANOG presentations: https://www.google.com/url?sa=trct=jq=esrc=ssource=webcd=1cad=rj auact=8ved=0CCoQFjAAurl=https%3A%2F%2Fwww.nanog.org%2Fmeetings%2Fna nog41%2Fpresentations%2FBGPMultihoming.pdfei=cyRnVb--FeWY7gbq4oHoAQu sg=AFQjCNFsMx3NZ0Vn4bJ5zJpzFz3senbaqgbvm=bv.93990622,d.ZGU The above document reenforces my opinion that we do not need full routing tables. However I was seeking some clarity as there are other documents which suggest taking a full routing table would be optimal. I guess it depends on our criteria and requirements for load balancing: - Just care about roughly balancing link utilisation - Be nice to make some cost savings We have PI space and two Internet routers one for each ISP. Either of our links is sufficient to carry all our traffic, but we want to try and balance utilisation to remain within our commits if possible. I am thinking a rough approach for us would be: - Take partial (customer) routes from both providers - Take defaults from both and pref one Maybe we can refine the above a bit more, any suggestions would be most welcome! Many Thanks
RE: BGP Multihoming 2 providers full or partial?
Just for the hardware and the planning required for migrating to new hardware human resource etc. -Original Message- From: Faisal Imtiaz [mailto:fai...@snappytelecom.net] Sent: 31 May 2015 14:01 To: Maqbool Hashim Cc: nanog@nanog.org Subject: Re: BGP Multihoming 2 providers full or partial? Interesting... is the cost associated with full tables just for the Hardware or is the service provider charging extra for the full table. Faisal Imtiaz Snappy Internet Telecom 7266 SW 48 Street Miami, FL 33155 Tel: 305 663 5518 x 232 Help-desk: (305)663-5518 Option 2 or Email: supp...@snappytelecom.net - Original Message - From: Maqbool Hashim maqb...@madbull.info To: Faisal Imtiaz fai...@snappytelecom.net Cc: nanog@nanog.org Sent: Sunday, May 31, 2015 8:10:51 AM Subject: RE: BGP Multihoming 2 providers full or partial? Thanks, So we just need to take a decision on whether we want to pay the price for a full routing table, whether it gives us enough value for the expenditure. -Original Message- From: Faisal Imtiaz [mailto:fai...@snappytelecom.net] Sent: 31 May 2015 13:06 To: Maqbool Hashim Cc: nanog@nanog.org Subject: Re: BGP Multihoming 2 providers full or partial? If you wish to do outbound traffic engineering, and want to take advantage of best paths to different networks (outbound), then you have to take full routes. Or putting it another way Taking full routes offers the most flexibility, anything else would be a compromise (an acceptable compromise) to overcome some existing resource limitations... Regards. Faisal Imtiaz Snappy Internet Telecom 7266 SW 48 Street Miami, FL 33155 Tel: 305 663 5518 x 232 Help-desk: (305)663-5518 Option 2 or Email: supp...@snappytelecom.net - Original Message - From: Maqbool Hashim maqb...@madbull.info To: nanog@nanog.org Sent: Friday, May 29, 2015 4:36:34 AM Subject: BGP Multihoming 2 providers full or partial? Hi, We are an enterprise that are eBGP multihoming to two ISPs. We wish to load balance in inbound and outbound traffic thereby using our capacity as efficiently as possible. My current feeling is that it would be crazy for us to take a full Internet routing table from either ISP. I have read this document from NANOG presentations: https://www.google.com/url?sa=trct=jq=esrc=ssource=webcd=1cad= rj auact=8ved=0CCoQFjAAurl=https%3A%2F%2Fwww.nanog.org%2Fmeetings%2F na nog41%2Fpresentations%2FBGPMultihoming.pdfei=cyRnVb--FeWY7gbq4oHoAQ u sg=AFQjCNFsMx3NZ0Vn4bJ5zJpzFz3senbaqgbvm=bv.93990622,d.ZGU The above document reenforces my opinion that we do not need full routing tables. However I was seeking some clarity as there are other documents which suggest taking a full routing table would be optimal. I guess it depends on our criteria and requirements for load balancing: - Just care about roughly balancing link utilisation - Be nice to make some cost savings We have PI space and two Internet routers one for each ISP. Either of our links is sufficient to carry all our traffic, but we want to try and balance utilisation to remain within our commits if possible. I am thinking a rough approach for us would be: - Take partial (customer) routes from both providers - Take defaults from both and pref one Maybe we can refine the above a bit more, any suggestions would be most welcome! Many Thanks
Re: BGP Multihoming 2 providers full or partial?
On 31/May/15 14:09, Maqbool Hashim wrote: I am just not sure of exactly how to define the partial routing table criteria to our two providers. Should we just take routes for each provider and their peers and a default from both? Since you can't take a full feed from either upstream, partial routes will mean taking your upstream's own routes + their directly-connected customers + default. You may make it more flexible by asking for their peering routes also, but if these are large global transit providers, that could be the full BGP table anyway (or 90% of it). Mark.
Re: BGP Multihoming 2 providers full or partial?
On Fri, May 29, 2015 at 4:36 AM, Maqbool Hashim maqb...@madbull.info wrote: We are an enterprise that are eBGP multihoming to two ISPs. We wish to load balance in inbound and outbound traffic thereby using our capacity as efficiently as possible. My current feeling is that it would be crazy for us to take a full Internet routing table from either ISP. I have read this document from NANOG presentations: Hello, Without a full table you are not protected from partitions. Partitions are when a particular destination is reachable via one of your ISPs but not via the other. Without receiving the route, you have no idea which ISP can reach it. Partitions happen fairly often but rarely last long (on the order of minutes). The worst cases tend to be when two backbones get into a peering dispute. Those have been known to last a week or more. See: Cogent v. everybody else. Think of it this way: a partial table is like an unsigned SSL certificate. Better than static routes but not fully protected. Regards, Bill Herrin -- William Herrin her...@dirtside.com b...@herrin.us Owner, Dirtside Systems . Web: http://www.dirtside.com/
