Re: Multiple vendors' IPv6 issues (ping google flash use)
On Tue, 2015-05-26 at 23:59 -0700, Tony Hain wrote: > (...) For fun, project this > http://www.google.com/intl/en/ipv6/statistics.html > (...) Hi, If someone from google is listening it would be really nice to spend a few minutes t oavoid flash for displaying this graph, it doesn't work on my Google Nexus 4 and my flash-less chrome/chromium desktops :). Sincerely, Laurent
Re: gmail.com - 550 error for ipv6/PTR ?
On Tue, 2014-01-14 at 19:06 -0500, Brandon Applegate wrote: > Just saw this in a message tonight. No idea if this is a transient error > or not. Got one too for AS197422 at "Tue, 14 Jan 2014 23:59:01 +0100", resent the mail at "Wed, 15 Jan 2014 00:03:12 +0100" and it worked so probably transient. Laurent host gmail-smtp-in.l.google.com[2a00:1450:400c:c05::1a] said: 550-5.7.1 [2a01:6600:80xxx] Our system has detected that this message 550-5.7.1 does not meet IPv6 sending guidelines regarding PTR records and 550-5.7.1 authentication. Please review 550-5.7.1 https://support.google.com/mail/?p=ipv6_authentication_error for more 550 5.7.1 information. hg12si1854476wib.39 - gsmtp (in reply to end of DATA command) Arrival-Date: Tue, 14 Jan 2014 22:59:01 + (UTC) Date: Tue, 14 Jan 2014 23:59:01 +0100 > --- > host gmail-smtp-in.l.google.com > [gmail-smtp-in.l.google.com][2607:f8b0:4002:c01::1a] >said: 550-5.7.1 [2607:ff70:11::11] Our system has detected that this >message does not 550-5.7.1 meet IPv6 sending guidelines regarding PTR >records and authentication 550-5.7.1 . Please review 550-5.7.1 >https://support.google.com/mail/?p=ipv6_authentication_error > [support.google.com] for more 550 >5.7.1 information. t26si2290895yhl.255 - gsmtp (in reply to end of DATA >command) > --- > That URL's relevant section says: > > Additional guidelines for IPv6 > > The sending IP must have a PTR record (i.e., a reverse DNS of the sending > IP) and it should match the IP obtained via the forward DNS resolution of > the hostname specified in the PTR record. Otherwise, mail will be marked > as spam or possibly rejected. > > The sending domain should pass either SPF check or DKIM check. Otherwise, > mail might be marked as spam. > --- > > I have both of these (PTR's RR has matching , and I have SPF (but not > DKIM)). > > I'm guessing that something on google's side is misinterpreting some data > or other busted logic. I meet all the requirements laid out, and have > been sending mail to gmail addresses (via ipv6) since $forever. > > Off-list replies are fine to minimize noise, and if there is an answer or > any meaningful correlation I will reply on-list. Thanks in advance for > any info/feedback. > > -- > Brandon Applegate - CCIE 10273 > PGP Key fingerprint: > 830B 4802 1DD4 F4F9 63FE B966 C0A7 189E 9EC0 3A74 > "SH1-0151. This is the serial number, of our orbital gun."
Re: The Making of a Router
On Sun, 2013-12-29 at 03:31 +0100, Baldur Norddahl wrote: > (...) > The users each have a unique VLAN (Q-in-Q). The question is, what do I put > on those VLANs, if I do not want to put a full IPv4 subnet on each? > > My own answer to that is to have the users share a larger subnet, for > example I could have a full class C sized subnet shared between 253 > users/VLANs. > > To allow these users to communicate with each other, and so they can > communicate with the default gateway IP, I will need proxy arp. And in a > non-OpenFlow solution, also the associated security functions such as > DHCP-snooping to prevent hijacking of IP addresses. > > Which devices can solve this task? Hi Baldur, Assuming you manage 1.1.1.0/24 and 2001:db8:0::/48 and have a Linux box on both ends you can get rid of IPv4 and v6 interco subnets and arp proxy the following way: 1/ on the gateway ip addr add 1.1.1.0/32 dev lo for all client VLAN "NN" on eth0 : ip -6 addr add fe80::1/64 dev eth0.NN ip -6 route add 2001:db8:0:NN00::/56 via fe80::1:NN dev eth0.NN 2/ on user CPE number "NN" CPE WAN interface being eth0 : ip addr add 1.1.1.NN/32 dev eth0 ip route add 1.1.1.0/32 dev eth0 ip route add default via 1.1.1.0 ip -6 addr add fe80::1:NN/64 dev eth0 ip -6 route add default via fe80::1 dev eth0 # ip -6 addr add 2001:db8:0:NN00::1/56 dev eth0 # optional Note: NN in hex for IPv6 The trick in IPv4 is that linux by default will answer to ARP requests for "1.1.1.0" on all interfaces even if the adress is on the loopback. And in IPv6 use static link local on both ends. You can replace "1.1.1.0" by any IPv4, but since ".0" are rarely assigned to end users it doesn't waste anything and keep traceroute with public IPv4. The nice thing of this setup is that it "virtualizes" the routing from the client point of view: you can split/balance your clients on multiple physical gateways and not change a line to the client configuration while it's being moved, you just have to configure your IGP between gateways to properly distribute internal routes. We (AS197422 / tetaneutral.net) use this for virtual machines too (with "tapNN" interfaces from KVM instead of "eth0.NN"): it allows us to move virtual machines around physical machines without user reconfiguration, not waste any IPv4 and avoid all issues with shared L2 (rogue RA/ARP spoofing/whatever) since there's no shared L2 anymore between user VM. It also allows us to not pre split our IPv4 space in a fixed scheme, we manage only /32 so no waste at all. Of course you still have work to do on PPS tuning. Sincerely, Laurent GUERBY AS197422 http://tetaneutral.net peering http://as197422.net PS: minimum settings on a Linux router echo 1 > /proc/sys/net/ipv4/ip_forward for i in /proc/sys/net/ipv6/conf/*; do for j in autoconf accept_ra; do echo 0 > $i/$j; done;done echo 1 > /proc/sys/net/ipv6/conf/all/forwarding echo 65536 > /proc/sys/net/ipv6/route/max_size for i in /proc/sys/net/ipv4/conf/*/arp_announce; do echo 2 > $i;done PPS: we also like to give /56 to our users in IPv6, it makes a nice /24 IPv4 <=> /48 IPv6 correspondance (256 users).
Re: High throughput bgp links using gentoo + stipped kernel
On Mon, 2013-05-20 at 10:35 +0200, Laurent GUERBY wrote: > On Mon, 2013-05-20 at 11:23 +1200, Ben wrote: > > With regards to security of OpenBSD versus Linux, you shouldn't be exposing > > any > > services to the world with either. And it's more stability/configuration > > that would > > push me to OpenBSD rather than performance. > > > > And with regards to crashing I'd try and figure out what was happening > > there quickly > > before making radical changes. Is it running out of memory, is Quagga > > dying? Is > > there a default route that works when Quagga crashes? One issue I had was > > I found > > Quagga crashing leaving a whole lot of routes lingering in the table, and I > > had a > > script that'd go through and purge them. > > Hi, > > We've been running a small AS with BIRD on Linux(debian) without any > issue in two years of production on two software routers so far: > > http://bird.network.cz/ I forgot to mention that there is now a paying support programme in case you need it: http://bird.network.cz/?support Laurent
Re: High throughput bgp links using gentoo + stipped kernel
On Mon, 2013-05-20 at 11:23 +1200, Ben wrote: > With regards to security of OpenBSD versus Linux, you shouldn't be exposing > any > services to the world with either. And it's more stability/configuration > that would > push me to OpenBSD rather than performance. > > And with regards to crashing I'd try and figure out what was happening there > quickly > before making radical changes. Is it running out of memory, is Quagga dying? > Is > there a default route that works when Quagga crashes? One issue I had was I > found > Quagga crashing leaving a whole lot of routes lingering in the table, and I > had a > script that'd go through and purge them. Hi, We've been running a small AS with BIRD on Linux(debian) without any issue in two years of production on two software routers so far: http://bird.network.cz/ It uses less than 100MB of RAM per IPv4 DFZ, we run around 100 BGP sessions in 350M of RAM (process virtual). Looking glass developper by our members: http://lg.tetaneutral.net/prefix_bgpmap/gw+h3/ipv4?q=meh.net.nz http://lg.tetaneutral.net/summary/gw+h3/ipv4 Sincerely, Laurent http://tetaneutral.net http://as197422.peeringdb.com
Re: The 100 Gbit/s problem in your network
On Fri, 2013-02-08 at 10:50 -0800, joel jaeggli wrote: > On 2/8/13 9:46 AM, fredrik danerklint wrote: > >>> About 40 - 50 Mbit/s. Not bad at all. > >>> > >>> Downloading software does not have to be in real-time, like watching > >>> a movie, does. > >> In both cases it's actually rather convenient if it's as fast as > >> possible, > > > > Yes. What I would like to have is to allow the access switch, which a > > customer for an ISP is connected to, to let the customer have 1 Gbit/s > > of bandwidth if the traffic is to or from the cache servers at their > > ISP. > > > You're positing a situation where a cache infrastructure at scale built > close to the user has a sufficiently high hit rate for rather large > objects to be more cost effective than increasing capacity in the > middle of the network as the bandwidth/price curve declines. My early > career as an http cache dude makes me a bit suspicious. I'm pretty > confident that denser/cheaper/faster silicon is less expensive than > deploying boxes of spinning disks closer to the customer(s) than they > are today (netflix's cache for example isn't that close to the edge > (would support 2-10k simultaneous customers for that one application per > box), it aims to get inside the isp however) when you add > power/cooling/space/lifecycle-maintenance (I'm a datacenter operator) if > it wasn't the CDN's would have pushed even closer to the edge. Of course > if you can limit consumer choice then you can push your hit rate to 100% > but then you're running a VOD service in a walled garden and there are > plenty of those already. > > That said provide compelling numbers and I'll change my mind. The "problem" with increasing capacity is that it opens up captive eyeballs to innovative services from "outside": monopoly operators will prefer to deal with CDN providers & the like and keep control. Sincerely, Laurent
Re: Bird vs Quagga revisited
On Wed, 2012-08-29 at 16:39 +0100, Edward J. Dore wrote: > MikroTik RouterOS is indeed based on Linux, however I believe they rolled > their own MPLS stack. Hi, Does Mikrotik publish their modified Linux kernel source? Might be interesting to look at it. Laurent > Last time I looked, the "mpls-linux" project over at SourceForge was > incomplete and slow - I have no idea if this has changed at all recently > however. > > Edward Dore > Freethought Internet > > - Original Message - > From: "Walter Keen" > To: "Seth Mattinen" > Cc: nanog@nanog.org > Sent: Wednesday, 29 August, 2012 2:00:52 AM > Subject: Re: Bird vs Quagga revisited > > I'm fairly sure that Mikrotik software is based on linux, and supports MPLS. > > Not too sure which package they use, or if they rolled their own MPLS > support... > > > > > - Original Message - > > From: "Seth Mattinen" > To: nanog@nanog.org > Sent: Tuesday, August 28, 2012 4:42:14 PM > Subject: Re: Bird vs Quagga revisited > > > What's the state of MPLS on Linux these days? > > ~Seth > > >
Re: using "reserved" IPv6 space
Hi, On Sat, 2012-07-14 at 17:02 -0700, Owen DeLong wrote: > > Hi, > > > > We use LLA to "virtualize" interconnection to our users: > > their network configuration is always static default via fe80:: > > and we route their /56 prefix to fe80::: where : is > > unique per user - if our user want to do some routing of course. Since > > we don't have GUA interconnections we don't have to manage them inside > > our AS and we can move user stuff around without having them changing > > anything to their static configuration. > > > > We give a /56 IPv6 per /32 IPv4 to our user which does /48 = /24 = 256 > > "IP", it's nice to have more than one /64 around for some uses. > > > > Is there any "mass" hoster around that does provide by default a pefix > > larger than /64 and that does route it to the user? It's quite simple to > > do in IPv6 and we have the address space for it. > Why not just give each end-site a /48? We give a /48 on request, a /56 by default (and we never give a /64). > An end-site with a /24 may only need a single or a few subnets while an > end-site with a /32 may have a host of subnets behind their IPv4 NAT gateway. > Making IPv6 topological assumptions for your end-users based on their IPv4 > presentation makes little sense to me and is likely a disservice to your end > users. The /56 subnets we give are for single machine in a rack, virtual machine in a cluster or home router. http://www.tunnelbroker.net/ gives by default /64 to a home router and /48 on request we just decided to give /56 by default and /48 on request. Sorry if I wasn't clear in my first message. Is there an agreed upon definition of "end site"? Sincerely, Laurent
Re: using "reserved" IPv6 space
On Sat, 2012-07-14 at 09:18 -0700, Owen DeLong wrote: > On Jul 14, 2012, at 9:08 AM, Jérôme Nicolle wrote: > > > Le 13/07/12 16:38, -Hammer- a écrit : > >> In the past, with IPv4, we have used reserved or "non-routable" > > > > I guess "non-routable IPv4" translates well to "non-routable IPv6", thus > > putting Link-Local addresses on top of the list. > > > > Thought you may use th auto-configured addresses for that purpose, you > > also may set LLAs to your liking. I use fe80::zone_ID:interface_ID , and > > set such LLA to every gateways to make routing tables more legible, > > those ID beeing arbitrary 16bit values. > > > > Given that zone_IDs in my environments consist of terms like: > > fxp0 > en0 > eth0 > ge-0/0/0.0 > etc. > > How, exactly, would you turn those into part of an IPv6 address? Hi, We use LLA to "virtualize" interconnection to our users: their network configuration is always static default via fe80:: and we route their /56 prefix to fe80::: where : is unique per user - if our user want to do some routing of course. Since we don't have GUA interconnections we don't have to manage them inside our AS and we can move user stuff around without having them changing anything to their static configuration. We give a /56 IPv6 per /32 IPv4 to our user which does /48 = /24 = 256 "IP", it's nice to have more than one /64 around for some uses. Is there any "mass" hoster around that does provide by default a pefix larger than /64 and that does route it to the user? It's quite simple to do in IPv6 and we have the address space for it. Sincerely, Laurent
Re: Most energy efficient (home) setup
On Sun, 2012-04-15 at 10:52 -0500, Jimmy Hess wrote: > In any given 24 hour period, the probability of at least > one single bit error exceeds 98%.Assuming the memory is good and > functioning correctly; > > It's expected to see on average approximately 3 to 4 1-bit errors > per day. More are frequently seen. > > Now if most of this 16GB of memory is unused, you will never notice > that over 30 days, 120 or so bits have been flipped from their > proper value.. Hi, I've been operating 4 desktop PCs with each the following configuration: 16 GB of RAM (4x4GB Kingston) running Linux about 15 VM (KVM) on DRBD disks using more than 10 GB of RAM for nearly a year now in a room without cooling. Over the year I've got one dead HDD and one dead SSD (both replaced) but no data corruption or host or VM crash. Do you have reference to recent papers with experimental data about non ECC memory errors? It should be fairly easy to do (write and read scan memory in a loop) and given your computations you should get bit errors in less than a day. I remember this paper in 2003 but this was using abnormal heat: http://www.cs.princeton.edu/~sudhakar/papers/memerr-slashdot-commentary.html Thanks in advance, Sincerely, Laurent
Re: IX in France
On Tue, 2012-02-21 at 18:46 +0200, Ido Szargel wrote: > Hi All, > > > > We are currently looking to connect to one of the IX's available in Paris, > > It seems that there are 2 "major" players - FranceIX and Equinix FR, can > anyone share their opinions about those? Hi, We're connected to both (and to a smaller third one named FR-IX), it's not that expensive and adds redundancy to join many peers. Sincerely, Laurent
Re: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer...
On Sat, 2011-02-12 at 09:37 -0800, Cameron Byrne wrote: > Mikael and I both have 3G networks with demonstrated IPv6 > capabilities, perhaps people should request Google drive Android IPv6 > support. Please point your IPv6 interest here > http://code.google.com/p/android/issues/detail?id=3389 and comment and > try and drive the IPv6 support for mobile into Android. Looks like cyanogenmod supports ipv6: http://forum.cyanogenmod.com/topic/1286-ipv6-on-cm-508-ds/ Laurent
Re: Using IPv6 with prefixes shorter than a /64 on a LAN
On Sun, 2011-01-30 at 17:39 +0100, Leen Besselink wrote: > On 01/25/2011 11:06 PM, Owen DeLong wrote: > > If IPv4 is like 640k, then, IPv6 is like having > > 47,223,664,828,696,452,136,959 > > terabytes of RAM. I'd argue that while 640k was short sighted, I think it is > > unlikely we will see machines with much more than a terabyte of RAM > > in the lifetime of IPv6. > > > I would be very careful with such predictions. How about 2 TB of RAM ?: > > "...IBM can cram 1 TB of memory into a 4U chassis or 2 TB in an > eight-socket box in two 4U chassis..." > > http://www.theregister.co.uk/2010/04/01/ibm_xeon_7500_servers/page2.html > http://www.theregister.co.uk/2010/04/01/ibm_xeon_7500_servers/ > > I don't know who will use it or how much they will need to pay for it or > even when they will be available, > but they are talking about it (in this case at the last CEBIT in March). > > People are building some very big systems for example with lots and lots > of virtual machines. On dell.com you can buy a PowerEdge R910 with 1TB RAM for around $80k. Laurent
Re: Some truth about Comcast - WikiLeaks style
On Thu, 2010-12-16 at 09:47 -1000, Paul Graydon wrote: > (...) All we're ending up with is what is mostly hearsay being treated as > facts. One consumer organization in France during the ongoing debate with regulators on network neutrality called for network operator to publish some verifiable information on their bandwidth issues: http://www.arcep.fr/index.php?id=10387 http://www.alain-bazot.fr/index.php/neutralite-du-net-n-oublions-pas-l-interet-du-consommateur/ http://www.pcinpact.com/actu/news/55827-alain-bazot-neutralite-ufc-arcep.htm Alain Bazot, president of "UFC - Que Choisir" a well-known french consumer organization wrote on his blog: << (...) Avant toute intervention, l’opérateur devrait prouver qu’il y a un réel problème sur son réseau, comme une congestion. Alors que les témoignages quant à la réalité de la saturation des réseaux divergent, cette condition me semble essentielle. (...) >> My poor translation: << (...) Before any change the network operator must prove he has a real congestion issue. Since informations on the reality of network saturation are divergent, this condition seems essential to me. (...) >> Regulators and the public need data for proper regulation and future changes in regulation, and the issue is the same everywhere :). Sincerely, Laurent PS: sorry for my miscalculation AMSIX 1.2Tbit/s cost is $2.25 per month per Comcast subscriber assuming 16 millions customers and $30/Mbit/s/month transit but as pointed out by participants of this list for a 10G port at Comcast cost is likely to be closer to $3 Mbit/s so it all cancels out to my original erroneous $0.225 :).
RE: Some truth about Comcast - WikiLeaks style
On Wed, 2010-12-15 at 05:31 -0500, Randy Epstein wrote: > Laurent, > > >If a 10G port for transit is paid by comcast $30/Mbit/s monthly > >that's 0.19 cent/internet customer/month for a new 10G port > >to properly desaturate this particular link. > > >Did I compute something wrong? > > >Laurent > > Yes, now you need to multiply that by the numerous other ports that have the > same conditions and need upgrades. If I look at: http://www.ams-ix.net/statistics/ That's 1.2 Tbit/s peak for European biggest IX so 120 10G ports so about 22 cent/customer/month assuming Comcast alone generates this kind of bandwidth and pays what mom & pop AS pay for transit. It still doesn't compute to me... Laurent
Re: Some truth about Comcast - WikiLeaks style
On Tue, 2010-12-14 at 16:20 -0500, Ricky Beam wrote: > On Tue, 14 Dec 2010 11:24:45 -0500, Craig L Uebringer > wrote: > > Same crap I've seen on loads of provider networks. > > No ISP I've ever worked for or with has ever willingly ran their transit > (or peering) links at capacity. > > (Granted, I've been responsible for saturating links, but I moved user > traffic off of them first.) > > --Ricky > > PS: TATA confirmed Comcast's behavior before anyone found any traffic > graphs. We already knew they were gaming their own customer base. According to: http://en.wikipedia.org/wiki/Comcast "Comcast has 15.930 million high-speed internet customers" If a 10G port for transit is paid by comcast $30/Mbit/s monthly that's 0.19 cent/internet customer/month for a new 10G port to properly desaturate this particular link. Did I compute something wrong? Laurent
Re: peering, derivatives, and big brother
On Sun, 2010-12-12 at 19:36 -0800, George Bonser wrote: > (...) The financial derivatives market isn't, in my opinion, a good analogy of > the peering market. A data packet is "perishable" and must be moved > quickly. The destination network wants the packet in order to keep > their customer happy and the originating network wants to get it to that > customer as quickly and cheaply as possible. The proliferation of these > peering points means that today there is more traffic going directly > from content network to eyeball network. To use a different analogy, it > is almost like the market is going to a series of farmer's markets > rather than supermarkets in the distribution channel. Sure, there are > still the "supermarkets" out there, but increasingly they are selling > their "store brand" by becoming content hosting networks themselves. (...) Hi, The electricity spot market is close to your definition of "perishable": http://en.wikipedia.org/wiki/Electricity_market It has a derivative market, google for "electricity derivatives" will give you some papers and models. I'm pretty sure electricity and bandwidth share some patterns. Now who wants to be the Enron of the bandwidth market? :) Sincerely, Laurent http://guerby.org/blog
