Re: Google to offer fiber to end users
David Hubbard wrote: > Residential computers with enough bandwidth to DoS > hosting providers; that should be fun. Maybe it will > encourage the incumbant ISP's to start offering users > meaningful bgp communities since they won't be able > to keep up with the abuse reports. Residential customers already have enough bandwidth to DOS hosting providers. > David >
Re: 192.255.103.x
On Thu, Feb 11, 2010 at 07:27:38PM -0800, Hector Herrera wrote: > On Thu, Feb 11, 2010 at 6:08 PM, Matthew Palmer wrote: > > On Thu, Feb 11, 2010 at 05:30:11PM -0800, Hector Herrera wrote: > >> I'm trying to diagnose an issue with 192.255.103.x > >> > >> As far as I can tell from IANA, the block 192/8 is allocated to ARIN. > >> ARIN does not have a record of 192.255.103 being allocated to anybody. > >> > >> Here is the issue ... the customer insists that is the correct IP and > >> for a few hours yesterday, it was actually working. ?Their satellite > >> phone can reach it, but we can't see it advertised today from any > >> networks. > > > > Smells to me like their satphone provider could be doing something dodgy. > > More info would be handy: what your customer's relationship to that IP block > > is, and what they think should be available at that IP block. > > According to the customer the IP is at their home network. They are > in town for a certain large event *cough*fiverings*cough* and they > keep insisting (and their home IT department indicates the IP is > valid). > > The customer is now claiming this IP is part of a "hidden" and > "secret" block of IPs ... How can you have hidden IPs? Pfft, that's just code for "we picked a block at random". See also: 1/8. > I think I'm just going to chalk this one up to a made up IP block that > is probably statically routed by their satphone provider. Indeed. - Matt
Re: 192.255.103.x
On Thu, Feb 11, 2010 at 8:27 PM, Hector Herrera wrote: > On Thu, Feb 11, 2010 at 6:08 PM, Matthew Palmer wrote: >> On Thu, Feb 11, 2010 at 05:30:11PM -0800, Hector Herrera wrote: >>> I'm trying to diagnose an issue with 192.255.103.x >>> >>> As far as I can tell from IANA, the block 192/8 is allocated to ARIN. >>> ARIN does not have a record of 192.255.103 being allocated to anybody. >>> >>> Here is the issue ... the customer insists that is the correct IP and >>> for a few hours yesterday, it was actually working. Their satellite >>> phone can reach it, but we can't see it advertised today from any >>> networks. >> >> Smells to me like their satphone provider could be doing something dodgy. >> More info would be handy: what your customer's relationship to that IP block >> is, and what they think should be available at that IP block. >> >> - Matt > > According to the customer the IP is at their home network. They are > in town for a certain large event *cough*fiverings*cough* and they > keep insisting (and their home IT department indicates the IP is > valid). > > The customer is now claiming this IP is part of a "hidden" and > "secret" block of IPs ... How can you have hidden IPs? > > Are IANA/ARIN/RIPE allowing certain agencies to receive allocations > without disclosing them in whois? > > Reverse DNS shows nothing as well. > > I think I'm just going to chalk this one up to a made up IP block that > is probably statically routed by their satphone provider. > > Thank you all. What it sounds like is one of the following: 1) They got confused with 192.168.xxx.xxx networks when setting it up. 2) They got 192.255.xx.xx from some group that said they could have it when they couldn't 3) They grabbed it a long time ago and don't remember they did so. 4) Some combination of the above. In any of the cases, its their local network which is foo-bared one way or another. Their local routers must have had a route to it and no longer does.. getting a traceroute from them or something to show where their router thinks it should go (or if they have an old one to show where it was.) > -- > Hector Herrera > President > Pier Programming Services Ltd. > > -- Stephen J Smoogen. Ah, but a man's reach should exceed his grasp. Or what's a heaven for? -- Robert Browning
Re: Linux Router distro's with dual stack capability
Also IIRC you can tune the hash cache / tree algorithm - ie if your traffic is mostly a few addresses then the default prefix search is fine (with the caching) but for more sparse traffic as you'd see at an edge, disabling the cache and using the other algo proved a lot faster. There's a paper on this I saw a few years ago, will forward if I find it. -Jack Carrozzo On Thu, Feb 11, 2010 at 7:41 PM, Richard A Steenbergen wrote: > On Thu, Feb 11, 2010 at 03:46:13PM -0800, Kevin Oberman wrote: >> Polling is excellent for low speed lines, but for Gig and faster, most >> newer interfaces support interrupt coalescing. This easily resolves the >> issue in hardware as interrupts are only issued when needed but limited >> to a reasonable rate, Polling does not use interrupts, but consumes >> system resources regardless of traffic. >> >> FreeBSD has supported polling for a long time (V6?) and interrupt >> coalescing since some release of V7. (Latest release is V8.) > > I'm pretty sure it's been around for a lot longer than that. I seem to > recall playing with both back in 4.x. Of course interrupt coalescing is > mostly a function of the NIC (though some driver involvement is required > to take advantage of it), so the quality of the implementations have > varied significantly over the years. The first generation GE NICs which > offered it didn't do a particularly good job with it though, so for > example it was still possible to cripple a box with high interrupt > rates while the same box would be perfectly fine with polling. > > That said, I think your use case for polling is backwards. As you say, > "normally" the NIC fires off an interrupt every time a packet is > received, and the kernel stops what it is doing to process the new > packet. On a low speed (or at least low traffic) interface this isn't a > problem, but as the packet/sec rate increases the amount of time wasted > as interrupt processing "overhead" becomes significant. For example, > even a GE interface is capable of doing 1.488 million packets/sec. > > By switching to a polling based model, you switch off the interrupt > generation completely and simply check the NIC for new packets a set > rate (for example, 1000 times/sec). This gives you a predictable and > consistent CPU use, so even if you had 1.488M/s interrupts coming in you > would still only be checking 1000 times/sec. If you did less than > 1000pps it would be a net increase in CPU, but if you do more (or ever > risk doing more, such as during a DoS attack) it could be a net benefit. > This is makes the most sense for people doing a lot of traffic > regardless. > > Of course the downside is higher latency, since you're delaying the > processing of the packet by some amount of time after it comes in. In > the 1000 times/sec example above, you could be delaying processing of > your packet by up to 1ms. For most applications this isn't enough to > cause any harm, but it's something to keep in mind. Interrupt coalescing > works around the problem of large interrupt rates by simply having the > NIC limit the number of interrupts it generates under load, giving you > the benefits of low-latency processing and low-interrupt rate under high > load. I haven't played with this stuff in many many years, so I'm sure > modern interrupt coalescing is much better than it used to be, and the > extra work of configuring polling and dealing with the potential > latency/jitter implications isn't worth the benefits for most people. :) > > -- > Richard A Steenbergen http://www.e-gerbil.net/ras > GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) > >
Re: 192.255.103.x
On Thu, Feb 11, 2010 at 6:08 PM, Matthew Palmer wrote: > On Thu, Feb 11, 2010 at 05:30:11PM -0800, Hector Herrera wrote: >> I'm trying to diagnose an issue with 192.255.103.x >> >> As far as I can tell from IANA, the block 192/8 is allocated to ARIN. >> ARIN does not have a record of 192.255.103 being allocated to anybody. >> >> Here is the issue ... the customer insists that is the correct IP and >> for a few hours yesterday, it was actually working. Their satellite >> phone can reach it, but we can't see it advertised today from any >> networks. > > Smells to me like their satphone provider could be doing something dodgy. > More info would be handy: what your customer's relationship to that IP block > is, and what they think should be available at that IP block. > > - Matt According to the customer the IP is at their home network. They are in town for a certain large event *cough*fiverings*cough* and they keep insisting (and their home IT department indicates the IP is valid). The customer is now claiming this IP is part of a "hidden" and "secret" block of IPs ... How can you have hidden IPs? Are IANA/ARIN/RIPE allowing certain agencies to receive allocations without disclosing them in whois? Reverse DNS shows nothing as well. I think I'm just going to chalk this one up to a made up IP block that is probably statically routed by their satphone provider. Thank you all. -- Hector Herrera President Pier Programming Services Ltd.
Re: 192.255.103.x
On Thu, Feb 11, 2010 at 9:12 PM, James Hess wrote: > On Thu, Feb 11, 2010 at 7:30 PM, Hector Herrera > wrote: >> As far as I can tell from IANA, the block 192/8 is allocated to ARIN. >> ARIN does not have a record of 192.255.103 being allocated to anybody. > > I can infer very strongly that the block has probably not been > allocated, or if it was, has not been properly listed in the directory > as allocated yet. > > Look at the DNS delegation of the reverse DNS. Y.arin.net > replies NXDOMAIN for the 192.255.103.in-addr.arpa zone with 103.255.192.in-addr.arpa. (though Y still gives back NXdomain, and points NS at chia.arin.net, for 192.in-addr.arpa.) -chris
Re: 192.255.103.x
On Thu, Feb 11, 2010 at 7:30 PM, Hector Herrera wrote: > As far as I can tell from IANA, the block 192/8 is allocated to ARIN. > ARIN does not have a record of 192.255.103 being allocated to anybody. I can infer very strongly that the block has probably not been allocated, or if it was, has not been properly listed in the directory as allocated yet. Look at the DNS delegation of the reverse DNS. Y.arin.net replies NXDOMAIN for the 192.255.103.in-addr.arpa zone with authority, indicating no rDNS delegation. ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 16598 ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 The RADB and RIS are good sources to query also. http://www.ris.ripe.net/mt/prefixdashboard.html?prefix=192.255.103.0 "This prefix does not appear to be announced. It was not seen by RIS in the last 3 months. See below for related prefixes. Related (overlapping) prefixes seen by RIS in the last 30 days No prefixes found. This prefix has 0 visibility. " -- -J
Re: 192.255.103.x
On Thu, Feb 11, 2010 at 05:30:11PM -0800, Hector Herrera wrote: > I'm trying to diagnose an issue with 192.255.103.x > > As far as I can tell from IANA, the block 192/8 is allocated to ARIN. > ARIN does not have a record of 192.255.103 being allocated to anybody. > > Here is the issue ... the customer insists that is the correct IP and > for a few hours yesterday, it was actually working. Their satellite > phone can reach it, but we can't see it advertised today from any > networks. Smells to me like their satphone provider could be doing something dodgy. More info would be handy: what your customer's relationship to that IP block is, and what they think should be available at that IP block. - Matt
Re: Yahoo abuse
On Thu, Feb 11, 2010 at 1:41 PM, J.D. Falk wrote: > Some types of conversations simply don't take well to automation. > However, automatically indexing/archiving such conversations for future reference can be useful (and can assist participants to the conversation in looking up past similar conversations), and it is easier to archive and maintain accurate auditing of structured language than to implement natural language parsers. That said, XML makes a terrible data interchange format for communications where humans are supposed to understand the message, using standard software (such as a legacy e-mail client). YAML, or similar would be a more appropriate choice, and since it can be presented as plain text, many humans can understand the output simply by looking at it. -- -J
192.255.103.x
I'm trying to diagnose an issue with 192.255.103.x As far as I can tell from IANA, the block 192/8 is allocated to ARIN. ARIN does not have a record of 192.255.103 being allocated to anybody. Here is the issue ... the customer insists that is the correct IP and for a few hours yesterday, it was actually working. Their satellite phone can reach it, but we can't see it advertised today from any networks. The ip block 192.255.0.0/16 is allocated to "VARIOUS RIRs" under a text file I found at potaroo.net I tried a few looking glass sites, but I still can't find a route to the advertising router. So ... any ideas how to go about finding out the source of the routing block? -- Hector Herrera
Re: Linux Router distro's with dual stack capability
On Thu, Feb 11, 2010 at 03:46:13PM -0800, Kevin Oberman wrote: > Polling is excellent for low speed lines, but for Gig and faster, most > newer interfaces support interrupt coalescing. This easily resolves the > issue in hardware as interrupts are only issued when needed but limited > to a reasonable rate, Polling does not use interrupts, but consumes > system resources regardless of traffic. > > FreeBSD has supported polling for a long time (V6?) and interrupt > coalescing since some release of V7. (Latest release is V8.) I'm pretty sure it's been around for a lot longer than that. I seem to recall playing with both back in 4.x. Of course interrupt coalescing is mostly a function of the NIC (though some driver involvement is required to take advantage of it), so the quality of the implementations have varied significantly over the years. The first generation GE NICs which offered it didn't do a particularly good job with it though, so for example it was still possible to cripple a box with high interrupt rates while the same box would be perfectly fine with polling. That said, I think your use case for polling is backwards. As you say, "normally" the NIC fires off an interrupt every time a packet is received, and the kernel stops what it is doing to process the new packet. On a low speed (or at least low traffic) interface this isn't a problem, but as the packet/sec rate increases the amount of time wasted as interrupt processing "overhead" becomes significant. For example, even a GE interface is capable of doing 1.488 million packets/sec. By switching to a polling based model, you switch off the interrupt generation completely and simply check the NIC for new packets a set rate (for example, 1000 times/sec). This gives you a predictable and consistent CPU use, so even if you had 1.488M/s interrupts coming in you would still only be checking 1000 times/sec. If you did less than 1000pps it would be a net increase in CPU, but if you do more (or ever risk doing more, such as during a DoS attack) it could be a net benefit. This is makes the most sense for people doing a lot of traffic regardless. Of course the downside is higher latency, since you're delaying the processing of the packet by some amount of time after it comes in. In the 1000 times/sec example above, you could be delaying processing of your packet by up to 1ms. For most applications this isn't enough to cause any harm, but it's something to keep in mind. Interrupt coalescing works around the problem of large interrupt rates by simply having the NIC limit the number of interrupts it generates under load, giving you the benefits of low-latency processing and low-interrupt rate under high load. I haven't played with this stuff in many many years, so I'm sure modern interrupt coalescing is much better than it used to be, and the extra work of configuring polling and dealing with the potential latency/jitter implications isn't worth the benefits for most people. :) -- Richard A Steenbergenhttp://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: Linux Router distro's with dual stack capability
> Date: Thu, 11 Feb 2010 18:20:13 -0500 > From: Chuck Anderson > > On Thu, Feb 11, 2010 at 04:12:03PM -0600, William Pitcock wrote: > > On Thu, 2010-02-11 at 13:05 -0500, Jack Carrozzo wrote: > > > Lots of people roll FreeBSD with Quagga/pf/ipfw for dual stack. See > > > the freebsd-isp list. > > > > FreeBSD's network stack chokes up in DDoS attacks due to interrupt > > flooding. We used to use FreeBSD for firewalling and basic routing, but > > when noticing that we had horizontal scalability (e.g. a Celeron 667mhz > > performed nearly as well as a dual dual-core Xeon system when DDoS > > attacks happened), we switched to Vyatta, and generally have not looked > > back. > > Have you tried using FreeBSD's polling mode instead of interrupt mode? > > No experience with it myself, but it sounds cool: > > http://info.iet.unipi.it/~luigi/polling/ > Polling is excellent for low speed lines, but for Gig and faster, most newer interfaces support interrupt coalescing. This easily resolves the issue in hardware as interrupts are only issued when needed but limited to a reasonable rate, Polling does not use interrupts, but consumes system resources regardless of traffic. FreeBSD has supported polling for a long time (V6?) and interrupt coalescing since some release of V7. (Latest release is V8.) -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
Re: Linux Router distro's with dual stack capability
William Pitcock wrote: > FreeBSD's network stack chokes up in DDoS attacks due to interrupt > flooding. We used to use FreeBSD for firewalling and basic routing, but > when noticing that we had horizontal scalability (e.g. a Celeron 667mhz > performed nearly as well as a dual dual-core Xeon system when DDoS > attacks happened), we switched to Vyatta, and generally have not looked > back. > > William > > Which version of FreeBSD and how much traffic/pps? I believe that there has been significant improvements to the networking stack in recent versions of FreeBSD, plus there are also a lot of sysctl tunables which can significantly improve networking performance. I have a hard time believing that the networking performance of recent versions of FreeBSD would not be competitive in comparison to other unixes. -M
Re: Linux Router distro's with dual stack capability
On Thu, Feb 11, 2010 at 04:12:03PM -0600, William Pitcock wrote: > On Thu, 2010-02-11 at 13:05 -0500, Jack Carrozzo wrote: > > Lots of people roll FreeBSD with Quagga/pf/ipfw for dual stack. See > > the freebsd-isp list. > > FreeBSD's network stack chokes up in DDoS attacks due to interrupt > flooding. We used to use FreeBSD for firewalling and basic routing, but > when noticing that we had horizontal scalability (e.g. a Celeron 667mhz > performed nearly as well as a dual dual-core Xeon system when DDoS > attacks happened), we switched to Vyatta, and generally have not looked > back. Have you tried using FreeBSD's polling mode instead of interrupt mode? No experience with it myself, but it sounds cool: http://info.iet.unipi.it/~luigi/polling/
Re: Linux Router distro's with dual stack capability
Hi, On Thu, 2010-02-11 at 13:05 -0500, Jack Carrozzo wrote: > Lots of people roll FreeBSD with Quagga/pf/ipfw for dual stack. See > the freebsd-isp list. FreeBSD's network stack chokes up in DDoS attacks due to interrupt flooding. We used to use FreeBSD for firewalling and basic routing, but when noticing that we had horizontal scalability (e.g. a Celeron 667mhz performed nearly as well as a dual dual-core Xeon system when DDoS attacks happened), we switched to Vyatta, and generally have not looked back. William
Re: Denic (.de) blocking 6to4 nameservers (since begin feb 2010)
In message , Igor Ybema writes: > Hi, > > We are using 6to4 on our fallback site because the provider there is > not able to provide us native IPv6 yet. We have also installed a > fallback nameserver over there using a 6to4 address. > > This works good and no complains what so ever in the past. > > However, last week Denic (registry for .de) changed their policy (or > their checks). They don't allow a nameserver for a .de domain anymore > which contains a 6to4 address. The policy is "it should be a global > unicast AND the block should be assigned to a RIR for suballocation > purpose". > The 6to4 range is Global Unicast > (http://www.iana.org/assignments/ipv6-unicast-address-assignments/) > but it is not assigned to a RIR because it is a special block. This > fails their policy and their checks (resulting in a ERROR: 105 All > IPv6 Addresses must be Global Unicast). > > Ok, policy is policy and we should not complain. However, I'm asking > your opinions about this policy. I find this really stupid because > this completely brakes use for 6to4 in Germany and their is no good > reason to block it. > > We know we should push our provider to support native IPv6, and we do. > But this should not stop us using IPv6 6to4. > > regards, Igor Ybema If you can't get native IPv6 then use a tunneled service like Hurricane Electric's (HE.NET). It is qualitatively better than 6to4 as it doesn't require random nodes on the net to be performing translation services for you which you can't track down the administrators of. You can get /48's from HE. I use HE.NET and have for the last 7 or so years for my home network. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Latest Cisco for small dual homed ASN
On 2/11/2010 1:53 PM, James Smallacombe wrote: I have a customer that is looking at using BGP for their network; one connection over a few bonded T1s, the other over a Comcast Enterprise connection (which supposedly will do BGP now). When I was dual homed a few years ago, a 7204VXR with 256MB was more than adequate. With routing tables growing the way they are, what's a good Cisco based solution on the lower end of the price spectrum that should handle this fine for a few years? Somebody else is suggesting a Vyatta (Linux based) solution, which makes me a little nervous. Then again, Linux has improved dramatically from a security and stability P.O.V, so maybe it's worth a look if there's no hard drive involved. I've been running vyatta, here, for a year now. Its running VPN's and its routing on a TimeWarner Fiber on a modest dual core supermicro server. Its never had to be restarted. Its only dropped its tunnel a few times, but a cronjob checks it and restarts if it goes away. Version :VC5.0.2 Copyright:2006-2009 Vyatta, Inc. Built by :r...@vyatta.com Built on :Fri Feb 27 03:18:16 UTC 2009 Build ID :2009-02-26-2347-3bb1a83 Boot via :disk Uptime :15:10:39 up 225 days, 22:31, 1 user, load average: 0.00, 0.00, 0.00 Cheers, Curtis
Re: Yahoo abuse
On Feb 9, 2010, at 10:21 PM, Mikael Abrahamsson wrote: > On Wed, 10 Feb 2010, Suresh Ramasubramanian wrote: > >> That's IODEF, if and when it picks up enough steam to get widely deployed. > > That looks over-engineered, but at least someone can create a web service > where the user can fill in fields and use drop-down menus to create the XML > and the cut/paste this into an email and send. Question is how an end user > should handle the reply they get, it'll be pretty much unreadable to the > untrained eye. Some types of conversations simply don't take well to automation. -- J.D. Falk Return Path Inc
RE: Latest Cisco for small dual homed ASN
You can squeeze by with 512MB, but 1GB of ram would be better. A 7204VXR with 1GB of ram will work fine. You can also squeeze by with a 2951 Matthew Huff | One Manhattanville Rd OTA Management LLC | Purchase, NY 10577 http://www.ox.com | Phone: 914-460-4039 aim: matthewbhuff | Fax: 914-460-4139 > -Original Message- > From: James Smallacombe [mailto:u...@3.am] > Sent: Thursday, February 11, 2010 1:53 PM > To: nanog@nanog.org > Subject: Latest Cisco for small dual homed ASN > > > I have a customer that is looking at using BGP for their network; one > connection over a few bonded T1s, the other over a Comcast Enterprise > connection (which supposedly will do BGP now). > > When I was dual homed a few years ago, a 7204VXR with 256MB was more than > adequate. With routing tables growing the way they are, what's a good > Cisco based solution on the lower end of the price spectrum that should > handle this fine for a few years? > > Somebody else is suggesting a Vyatta (Linux based) solution, which makes > me a little nervous. Then again, Linux has improved dramatically from a > security and stability P.O.V, so maybe it's worth a look if there's no > hard drive involved. > > TIA, > > James Smallacombe PlantageNet, Inc. CEO and Janitor > u...@3.am http://3.am > = <>
Re: Latest Cisco for small dual homed ASN
On 2/11/2010 10:53, James Smallacombe wrote: > > I have a customer that is looking at using BGP for their network; one > connection over a few bonded T1s, the other over a Comcast Enterprise > connection (which supposedly will do BGP now). > > When I was dual homed a few years ago, a 7204VXR with 256MB was more > than adequate. With routing tables growing the way they are, what's a > good Cisco based solution on the lower end of the price spectrum that > should handle this fine for a few years? > Any 2800/3800 ISR (except the 2801) will handle this just fine with at least 512MB RAM if you want to stick with Cisco. You'll get more performance for the price out of Vyatta if that's more important. ~Seth
Latest Cisco for small dual homed ASN
I have a customer that is looking at using BGP for their network; one connection over a few bonded T1s, the other over a Comcast Enterprise connection (which supposedly will do BGP now). When I was dual homed a few years ago, a 7204VXR with 256MB was more than adequate. With routing tables growing the way they are, what's a good Cisco based solution on the lower end of the price spectrum that should handle this fine for a few years? Somebody else is suggesting a Vyatta (Linux based) solution, which makes me a little nervous. Then again, Linux has improved dramatically from a security and stability P.O.V, so maybe it's worth a look if there's no hard drive involved. TIA, James Smallacombe PlantageNet, Inc. CEO and Janitor u...@3.am http://3.am =
Re: AT&T Mind Boggles...
Mark Tinka wrote: AT&T, what gives? You need the proper perspective on these things. Rent and watch this classic movie from 1967, then you'll understand. http://www.imdb.com/title/tt0062153/ -- Jay Hennigan - CCIE #7880 - Network Engineering - j...@impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV
AT&T Mind Boggles...
So I send an online request for Wholesale IP Transit to AT&T via their web site, and several days later, I get an e-mail from one of their staff directing me to another link where I should fill up my information (again). Suffice it to say her e-mail to me already included my information, but anyway... So I hit the link, fill in my data, hit "Submit" and bam! "Page not found". I send an e-mail back to the lady who asked me to follow that link and ask her for help on how to proceed. She writes back to say, in many words, "Sorry, that link is the only way you can get your query answered. Oh by the way, here's a toll-free number you can call, it's not the actual department, but they should be able to direct you". Several more e-mails go back and forth arguing why this is such rocket science - meanwhile, I'm thinking, "She is staff, she can put me in touch since it's their web site that's flaky". The final option I was given was to have a friend in the States help me call AT&T on the toll-free number given. I live outside the States, toll-free numbers don't work for me (yes, they are free on Skype, but that's beside the point). The whole experience was robotic and efficient; efficient at me thinking, "There goes my business". AT&T, what gives? Mark. signature.asc Description: This is a digitally signed message part.
Re: Linux Router distro's with dual stack capability
Lots of people roll FreeBSD with Quagga/pf/ipfw for dual stack. See the freebsd-isp list. -Jack Carrozzo On Thu, Feb 11, 2010 at 3:23 AM, William Pitcock wrote: > On Wed, 2010-02-10 at 17:12 -0700, Blake Pfankuch wrote: >> Anyone have some insight on a good dual stack Linux (or BSD) router distro? >> Currently using IPCop but it lacks ipv6 support. I've used SmoothWall >> Express but not in some time and not sure how well it works with IPv6. Not >> looking for something huge, just something for the equivalent of a small >> branch office. Site to Site VPN support and NAT translation capability for >> a few public IP addresses to private addresses are the only requirements. >> Public or private responses are welcome! > > We are having moderate success with IPv6 on Vyatta, but we have seen > neighbour discovery glitches in the current production images. > > The prerelease subscription code crashes on our vyatta appliances, so we > haven't tested that yet. > > William > > >
Re: Denic (.de) blocking 6to4 nameservers (since begin feb 2010)
On Feb 11, 2010, at 8:15 AM, Nick Hilliard wrote:
> On 11/02/2010 12:26, Igor Ybema wrote:
>> Ok, policy is policy and we should not complain. However, I'm asking
>> your opinions about this policy. I find this really stupid because
>> this completely brakes use for 6to4 in Germany and their is no good
>> reason to block it.
>
> Someone once asked Angela Merkel what she liked most about Germany. She
> replied "Ich denke an dichte Fenster! Kein anderes Land kann so dichte und
> so schöne Fenster bauen"
>
> ("I think ... thick windows. No other country can build windows which are
> as thick or as nice.")
Actually, the translation is: "I think about airtight windows. No other
country can build widows that are this airtight and this beautiful."
dicht = airtight, dick = thick.
>
> This might just be a cultural thing. While lots of countries have a love
> affair with doing things badly, Germany realises the value of quality
> infrastructure.
>
> 6to4 is ghetto. DE-NIC doesn't like it. Putting a DNS server on a 6to4
> address serves no other purpose than to say: "There! I fixed it!"
>
> ob-url: http://thereifixedit.com/
>
> Nick
>
Re: dark fiber
On Thu, Feb 11, 2010 at 08:21, Jess Cohen wrote: > GOOGLE: Dark fiber is optical fiber infrastructure (cabling and repeaters) > that is currently in place but is not being used. Optical fiber conveys > information in the form of light pulses so the "dark" means no light pulses > are being sent. For example, some electric utilities have installed optical > fiber cable where they already have power lines installed in the expectation > that they can lease the infrastructure to telephone or cable TV companies or > use it to interconnect their own offices. To the extent that these > installations are unused, they are described as dark. > That is better than the link I was going to reference - reason I was going there was the recent announcement of the Google fiber to the community beta test. Are we seeing the beginnings of another move? Android phone OS, Google voice, Nexus One with the ability to make all calls voip... I heard Google made some major concessions [charging tax on internet purchases of the Nexus One] and is still being blocked on the "cannot be a phone company" end. Maybe if you can show you own a certain amount of infrastructure you automatically qualify as a phone company? I have no idea, I just see lots of little pieces coming together right now... --steve -- steve pirk refiamerica.org "father... the sleeper has awakened..." paul atreides - dune kexp.org member august '09
RE: dark fiber
GOOGLE: Dark fiber is optical fiber infrastructure (cabling and repeaters) that is currently in place but is not being used. Optical fiber conveys information in the form of light pulses so the "dark" means no light pulses are being sent. For example, some electric utilities have installed optical fiber cable where they already have power lines installed in the expectation that they can lease the infrastructure to telephone or cable TV companies or use it to interconnect their own offices. To the extent that these installations are unused, they are described as dark. -Original Message- From: Deric Kwok [mailto:deric.kwok2...@gmail.com] Sent: Thursday, February 11, 2010 10:14 AM To: James Jones Cc: nanog@nanog.org Subject: Re: dark fiber Can I have question? What is dark fiber? Thank you On Wed, Feb 10, 2010 at 5:08 PM, James Jones wrote: > I am doing some researchis there a way to find out where there is dark > fiber and who own's it? > >
Re: dark fiber
http://en.wikipedia.org/wiki/Dark_fibre On Thu, Feb 11, 2010 at 11:13 AM, Deric Kwok wrote: > Can I have question? > > What is dark fiber? > > Thank you > > > > On Wed, Feb 10, 2010 at 5:08 PM, James Jones > wrote: > > I am doing some researchis there a way to find out where there is > dark > > fiber and who own's it? > > > > > >
Re: Denic (.de) blocking 6to4 nameservers (since begin feb 2010)
On 11/02/2010 12:26, Igor Ybema wrote:
> Ok, policy is policy and we should not complain. However, I'm asking
> your opinions about this policy. I find this really stupid because
> this completely brakes use for 6to4 in Germany and their is no good
> reason to block it.
Someone once asked Angela Merkel what she liked most about Germany. She
replied "Ich denke an dichte Fenster! Kein anderes Land kann so dichte und
so schöne Fenster bauen"
("I think ... thick windows. No other country can build windows which are
as thick or as nice.")
This might just be a cultural thing. While lots of countries have a love
affair with doing things badly, Germany realises the value of quality
infrastructure.
6to4 is ghetto. DE-NIC doesn't like it. Putting a DNS server on a 6to4
address serves no other purpose than to say: "There! I fixed it!"
ob-url: http://thereifixedit.com/
Nick
Re: dark fiber
Can I have question? What is dark fiber? Thank you On Wed, Feb 10, 2010 at 5:08 PM, James Jones wrote: > I am doing some researchis there a way to find out where there is dark > fiber and who own's it? > >
Policy feedback - was Re: Denic (.de) blocking 6to4
At 13:26 +0100 2/11/10, Igor Ybema wrote: Ok, policy is policy and we should not complain. No, really, policies should be examined and questioned. Having been in policy meetings, unless the operations crowd openly questions and gives feed back, the meetings are just wastes of time. However, I'm asking your opinions about this policy. That's the right first step. (Note: no commentary on 6to4 in this, I'm not familiar enough with it.) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStarYou can leave a voice message at +1-571-434-5468 As with IPv6, the problem with the deployment of frictionless surfaces is that they're not getting traction.
Denic (.de) blocking 6to4 nameservers (since begin feb 2010)
Hi, We are using 6to4 on our fallback site because the provider there is not able to provide us native IPv6 yet. We have also installed a fallback nameserver over there using a 6to4 address. This works good and no complains what so ever in the past. However, last week Denic (registry for .de) changed their policy (or their checks). They don't allow a nameserver for a .de domain anymore which contains a 6to4 address. The policy is "it should be a global unicast AND the block should be assigned to a RIR for suballocation purpose". The 6to4 range is Global Unicast (http://www.iana.org/assignments/ipv6-unicast-address-assignments/) but it is not assigned to a RIR because it is a special block. This fails their policy and their checks (resulting in a ERROR: 105 All IPv6 Addresses must be Global Unicast). Ok, policy is policy and we should not complain. However, I'm asking your opinions about this policy. I find this really stupid because this completely brakes use for 6to4 in Germany and their is no good reason to block it. We know we should push our provider to support native IPv6, and we do. But this should not stop us using IPv6 6to4. regards, Igor Ybema
Re: Linux Router distro's with dual stack capability
On Wed, 2010-02-10 at 17:12 -0700, Blake Pfankuch wrote: > Anyone have some insight on a good dual stack Linux (or BSD) router distro? > Currently using IPCop but it lacks ipv6 support. I've used SmoothWall > Express but not in some time and not sure how well it works with IPv6. Not > looking for something huge, just something for the equivalent of a small > branch office. Site to Site VPN support and NAT translation capability for a > few public IP addresses to private addresses are the only requirements. > Public or private responses are welcome! We are having moderate success with IPv6 on Vyatta, but we have seen neighbour discovery glitches in the current production images. The prerelease subscription code crashes on our vyatta appliances, so we haven't tested that yet. William
Re: Linux Router distro's with dual stack capability
On Wed, 10 Feb 2010, Bryan Irvine wrote: > would pfsense work for you? pfSense has ipv6, since it's essentially just a freebsd kernel with a layer on top. However, ipv6 support in the GUI is fairly minimal to non-existant, and I wouldn't recommend it if you really want to use ipv6. Mind you, I'm a fan of pfSense, it's just too bad it's not ipv6-friendly :) -- Peter van Arkel T: +31 623988844 | p.vanar...@gmail.com RIPE: PvA63-RIPE | PGP: 0xA0991D6B
