Routes from AS17299 via AS24246

2013-09-21 Thread George B.
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

2013-09-21 Thread George B.
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

2013-09-21 Thread George B.
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

2013-09-21 Thread George B.
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 ?

2012-04-05 Thread George B.
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

2012-04-03 Thread George B.
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

2011-06-20 Thread George B.

 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

2011-06-19 Thread George B.
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

2011-06-19 Thread George B.
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

2011-06-17 Thread George B.
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

2011-06-09 Thread George B.

 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

2011-06-08 Thread George B.
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!

2011-06-08 Thread George B.
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

2011-06-08 Thread George B.
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

2011-01-29 Thread George B.
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.