Routes from AS17299 via AS24246
I would be much obliged of folks (peers of AS24246 -- InterNAP Hong Kong -- in particular) would adjust their filters to accept 216.239.98.0/24 and 216.231.203.0/24 announced from AS17299 via AS24246. You should also see those routes from AS17819 but it is the 24246 path that causing me hardship. Thanks g (yeah, I'll get them in a routing registry next week if that will help)
Re: Routes from AS17299 via AS24246
Because it is being announced by the ASN that is owned by the same company that owns the address block. Look up the originating ASN, look up the IP block. You don't have to take MY word for it but I am employed by that company. That's why. On Sat, Sep 21, 2013 at 8:23 PM, Christopher Morrow morrowc.li...@gmail.com wrote: On Sat, Sep 21, 2013 at 10:41 PM, George B. geor...@gmail.com wrote: 216.231.203.0/24 you don't appear to be on the whois list for that block nor asn... so, why would someone accept this block on your say-so? Are you asking as a customer of the ASN or as the ASN owner/operator?
Re: Routes from AS17299 via AS24246
And yeah, I am still associated with my former employer, I'm not on the new employer's stuff yet. G On Sat, Sep 21, 2013 at 8:23 PM, Christopher Morrow morrowc.li...@gmail.com wrote: On Sat, Sep 21, 2013 at 10:41 PM, George B. geor...@gmail.com wrote: 216.231.203.0/24 you don't appear to be on the whois list for that block nor asn... so, why would someone accept this block on your say-so? Are you asking as a customer of the ASN or as the ASN owner/operator?
Re: Routes from AS17299 via AS24246
Sorry if I a bit testy. Have a typhoon bearing down on the region and the primary connectivity for a site is apparently useless as the routes are not propagating from them and I have only one single connection to the alternate provider. I'm trying to make the site as resilient as possible under the circumstances. InterNAP claims peers are filtering the routes so I am asking for a favor. Thanks. G ASN ASNumber: 17299 ASName: IPASS-4 ASHandle: AS17299 RegDate:2006-03-27 Updated:2012-07-24 Ref:http://whois.arin.net/rest/asn/AS17299 OrgName:iPass Incorporated OrgId: IPAS Address:3800 Bridge Parkway City: Redwood Shores StateProv: CA Address block 1: NetRange: 216.239.96.0 - 216.239.111.255 CIDR: 216.239.96.0/20 OriginAS: NetName:IPASS-1BLK NetHandle: NET-216-239-96-0-1 Parent: NET-216-0-0-0-0 NetType:Direct Allocation Comment:ADDRESSES WITHIN THIS BLOCK ARE NON-PORTABLE RegDate:2000-11-29 Updated:2012-07-24 Ref:http://whois.arin.net/rest/net/NET-216-239-96-0-1 OrgName:iPass Incorporated OrgId: IPAS Address:3800 Bridge Parkway City: Redwood Shores StateProv: CA PostalCode: 94065 Country:US Second block: NetRange: 216.231.192.0 - 216.231.207.255 CIDR: 216.231.192.0/20 OriginAS: AS17398, AS32199, AS22665, AS17299 NetName:NET-216-231-192-0-1 NetHandle: NET-216-231-192-0-1 Parent: NET-216-0-0-0-0 NetType:Direct Assignment RegDate:1999-06-29 Updated:2012-07-24 Ref:http://whois.arin.net/rest/net/NET-216-231-192-0-1 OrgName:iPass Incorporated OrgId: IPAS Address:3800 Bridge Parkway City: Redwood Shores StateProv: CA On Sat, Sep 21, 2013 at 8:48 PM, Christopher Morrow morrowc.li...@gmail.com wrote: $ whois AS17299 | grep -i bos $ $ whois 216.239.98.0 | grep -i bos $ don't see you on either of the whois contact sets... which was what prompted my question originally. $ whois -h whois.cymru.com 216.239.98.0 AS | IP | AS Name 17299 | 216.239.98.0 | IPASS-4 - iPass Incorporated that seems kosher though. On Sat, Sep 21, 2013 at 11:41 PM, George B. geor...@gmail.com wrote: And yeah, I am still associated with my former employer, I'm not on the new employer's stuff yet. G On Sat, Sep 21, 2013 at 8:23 PM, Christopher Morrow morrowc.li...@gmail.com wrote: On Sat, Sep 21, 2013 at 10:41 PM, George B. geor...@gmail.com wrote: 216.231.203.0/24 you don't appear to be on the whois list for that block nor asn... so, why would someone accept this block on your say-so? Are you asking as a customer of the ASN or as the ASN owner/operator?
Re: Quad-A records in Network Solutions ?
On Thu, Mar 29, 2012 at 4:32 AM, Matt Ryanczak ryanc...@gmail.com wrote: I too had with nesol years ago. It required special phone calls to special people to update. Customer support never knew what was going on regarding or IPvWhat?. I suspect all of the people there that know about these types of things have moved on. Netsol has been leaking people since their sale to web.com last year, from actual layoffs and fear of the same. ~matt How long did it take them? We have had a request in for records for a domain for over a week now, and nothing in whois yet.
Re: Charter regional(nationwide?) flapping/multi outages
On Tue, Apr 3, 2012 at 1:27 AM, jamie rishaw wrote: Three thoughts come to mind. 1) Tech says Charter (according to internal talk) has no v6 deploy plans until 2013. Someone stop me from pulling out my hair on this -- Does 3q '13 align with others' plans for v6 deployment ? I have one upstream with no plans to deploy v6 until 2013. I have production operations in one of their facilities in Europe and a customer there screaming for v6 support and due to legal issues can't serve that customer from the US. This is one reason (among a few others) we have decided to migrate away from this provider. Our US operations have other v6 capable carriers and we have deployed v6 for most of our production operations in the US.
Re: Cogent depeers ESnet
internet connectivity, and that much $ is at stake, you're stupid if you don't have some redundancy. Nothing works all the time forever. I can't consider Cogent even a redundant link, since I need two other upstreams to reach the Internet redundantly. -cjp Well, they aren't someone you can take a default route from (either ipv4 or ipv6), that's for sure. So yeah, could use them if taking full routes.
Re: Cogent depeers ESnet
On Sat, Jun 18, 2011 at 5:26 PM, Nick Hilliard wrote: Slightly old news, but it looks like Cogent depeered ESnet last week: http://www.es.net/news-and-publications/esnet-news/2011/important-status-announcement-regarding-cogent-connectivity/ Current traceroutes indicate that ESnet is reaching Cogent via 6939_1299. In other news, automatically dropping interconnects at around the time of your HQ's close of business while your peering co-ordinator is on vacation seems to be the new gold standard. Nick I suppose the moral of the story is: never single-home to Cogent
Re: Cogent depeers ESnet
On Sun, Jun 19, 2011 at 2:47 PM, valdis.kletni...@vt.edu wrote: On Sun, 19 Jun 2011 03:15:09 CDT, Robert Bonomi said: Anybody got draft language for a SLA clause that requires routing 'at least one hop _past_ the provider's network edge' for every AS visible at major public peering points and/or LookingGlass sites? *every* ASN? Oh my. ;) I would qualify that a bit to say every ASN available at every peering point at which the provider appears. So if the provider appears at an Equinix peering point, there is no excuse for not providing connectivity to every other ASN also at that same peering point by some means. Cogent seems to want to play a game where they not only don't want to peer directly with a number of networks, they also don't want to use any transit to reach those with which it doesn't peer, forcing the other side to use transit to reach them. Interesting gamble but probably not providing the intended result. It just ends up selling transit to the competition as people multi-home instead of being single-homed to Cogent. Cogent probably is the single largest seller of competitors' services.
Re: ICANN to allow commercial gTLDs
On Fri, Jun 17, 2011 at 2:04 PM, Jay Ashworth j...@baylink.com wrote: Aw, Jeezus. No. Just, no. I think I will get .payme and make sure coke.payme, pepsi.payme, comcast.payme, etc. all get registered at the low-low price of $10/year. All I would need is 100,000 registrations to provide me with a million dollar a year income stream for the rest of my life. Wonder if the people who make DirtDevil vacuums will get .sucks and I wonder how much subdomains of that TLD will bring. Hey, this is a money fountain of unlimited potential. Basically it has the potential to be large scale extortion done with lots if micropayments. Chaos!
Re: IPv6 day non-participants
IMHO, it's worse than that. Most sites only added a record for their website, and frequently didn't for their DNS server. So they weren't *really* doing a complete IPv6 test, IMHO. There is a reason for that. First of all, we (my employer) took this as a brief test to simply see how much IPv6 traffic there really was, and who and what would actually attempt to reach us by IPv6. The idea here being to attempt to identify IPv6 native networks. We had to do this in a way that did not break our existing IPv4 services. We run some services that we do not consider breakable and our user profile is much different than a web site is. We might have millions of clients on a network that are, for the most part, identically configured. So for example, if one users device believes it has IPv6 but doesn't *really* have IPv6 (as a link local IP so it believes it has IPv6 or has IPv6 inside its network but not clean to the Internet), then there are probably tens of thousands of identically configured devices in that customer's network. So we don't face the some small fraction of one percent are broken problem, we face a if one is broken, then a significant portion of and possibly all of that customer's devices are broken. If we put IPv6 DNS records in place that caused 100,000 clients to break, we would have some serious explaining to do. In this case, a very safe approach was to place an IPv6 address for our web site in DNS. None of our business traffic goes to our website. In the course of IPv6 day for the roughly 18 hours it was operating, we might have had 200 hits on IPv6 compared to thousands of transactions per second on our business protocols. The test did, however, expose a bug in a piece of vendor gear that was catastrophic to the business service. The entire piece of gear blew up that handles the business traffic in addition to the web traffic. It rebooted itself but apparently did not boot cleanly. This was bad enough but it was rather quickly placed back into service (manual kick) and happened at the slowest traffic time of the day and few/no clients would have noticed. Had we also experienced customer complaints of slow/poor/no service during the time of the test, it would have been pretty bad. So enabling IPv6 DNS had the potential to cause global problems and not limited to a single data center, it could have had global impact to the domain. Placing a single IPv6 DNS glue record and DNS server in service would have also potentially resulted in local DNS servers from around the globe that might prefer IPv6 attempting to reach that one DNS server. In other words, it would have created a potential single point of failure and possibly degraded performance. So the IPv6 DNS infrastructure is being rolled out in a planned, methodical fashion. Dropping an record for the web site was an easy thing to do that was considered very low risk (as we assumed all of our other gear could simply pass IPv6 packets without exploding) and offered some participation with the community. George (speaking for himself)
Re: IPv6 day non-participants
Was participating until we hit a rather nasty load balancer bug that took out the entire unit if clients with a short MTU connected and it needed to fragment packets (Citrix Netscaler running latest code). No fix is available for it yet, so we had to shut it down. Ran for about 9 hours before the magic client that blew it up connected. So if you are using a Netscaler with SLB-PT (IPv6 VIP balancing to IPv4 servers), the entire LB is subject to stop working until they get this fixed.
Re: IPv6 day fun is beginning!
On Wed, Jun 8, 2011 at 12:48 PM, Joly MacFie j...@punkcast.com wrote: What seems evident, looking at http://asert.arbornetworks.com/2011/06/monitoring-world-ipv6-day/ is that a lot of folks switched it on - and then switched it off again pretty damn quick! Or ... folks switched it on and then it switched itself off again pretty damn fast when their hardware blew up. Either way would, though, match my experience.
Re: IPv6 day non-participants
On Wed, Jun 8, 2011 at 4:31 PM, Jorge Amodio jmamo...@gmail.com wrote: So if you are using a Netscaler with SLB-PT (IPv6 VIP balancing to IPv4 servers), the entire LB is subject to stop working until they get this fixed. And this is EXACTLY why we needed World IPv6 Day. Agreed, right on the money !! Traffic stats may not say a lot yet due to tunnels and lack of native IPv6 connectivity but finding this type of bugs is a major reason to do live tests, even if the test fails. Well, we are still attempting to recreate the problem. It isn't something as simple as someone coming in over a tunnel with a small MTU with a larger advertised MSS. There is some magic that must happen to actually put the unit in this state. We ran for 9 hours before and 9 hours after the hiccup without any problems. So it is going to take a while before we are ready to test this again live. The sooner I can recreate the problem, the better, though.
Re: Ipv6 for the content provider
On Fri, Jan 28, 2011 at 8:04 PM, Owen DeLong o...@delong.com wrote: The IPv6 geo databases actually tend to be about on par with the IPv4 ones from what I have seen so far (which is admittedly limited as I don't really use geolocation services). However, I still think it is important for people considering deploying something as you described to be aware of the additional things that may break and factor that into their decision about how and what to deploy. Owen That isn't going to be the case going forward, I don't believe because our allocation from ARIN will likely be used globally and others are likely to come to the same conclusion. While I had initially considered obtaining regional allocations for operations in that region, the overhead of dealing with multiple registries, differing policies, multiple fees, etc. didn't seem worth the trouble. The ARIN allocation will likely be used in EU and APAC regions in addition to NA.
