Re: Brocade Fabric Help

[Fred Hollis]

Hello Mike,

Running a few larger Brocade VDX fabrics here...

In case of that message, there is no other option not to reset that 
specific new switch and then re-join the device. I had that a few times, 
too.


It happens when you already did some configuration changes on the new 
switch and the older fabric members weren't aware of that.


On 30.06.2016 at 21:41 Mike Hammett wrote:

I asked on the Brocade forum, but it's largely been crickets there. I hoped 
someone here would have an idea.

One switch says: 23 Te 12/0/24 Up ISL segmented,(ESC mismatch, Distributed 
Config DB)(Trunk Primary)
The other switch says: 23 Te 54/0/24 Up ISL segmented,(ESC mismatch, 
Distributed Config DB)(Trunk Primary)

I saw that means, "The DCM Configuration DB is different on both the ends of 
ISL," but I have no idea how to resolve that.


VDX-6720s running 4.1.3b.




-
Mike Hammett
Intelligent Computing Solutions
http://www.ics-il.com



Midwest Internet Exchange
http://www.midwest-ix.com

Re: Looking for a Level 3 Routing Registry contact

[Fred Hollis]

same...

On 23.06.2016 at 18:42 Theodore Baschak wrote:

Curious if you had any luck with this task, I've tried via several avenues
and had very little luck getting old cruft removed. :-(

Theodore


On Fri, Jun 17, 2016 at 4:16 PM, Delacruz, Anthony B <
anthony.delac...@centurylink.com> wrote:


Please contact me off list if you can help me get in touch with an actual
person that can clear out old entries in the Level 3 routing registry. I
can't do jack with the automated and the contacts that put them in are non
responsive for clearing out their years old mess. Thanks.

This communication is the property of CenturyLink and may contain
confidential or privileged information. Unauthorized use of this
communication is strictly prohibited and may be unlawful. If you have
received this communication in error, please immediately notify the sender
by reply e-mail and destroy all copies of the communication and any
attachments.

Re: Cogent <=> Google Peering issue

[Fred Hollis]

Yes, it's a global Cogent problem. We are in contact with them as well 
and were told that they're aware of that but can't do anything about it 
on their own.



Dear Cogent Customer,

Cogent NOC team has been working with Verizon as well as Google to assist with 
resolving the issue. After further investigation there is no issue on the 
Cogent network which is causing the issue that you are seeing. Currently we 
have asked for  Google and Verizon to work together to assist with resolving 
the issue which has been isolated to their end of the spectrum.

As you can see, this issue is beyond Cogent control nevertheless, we continue 
pushing to get it resolve. We will provide you with further updates as they 
arise.


I am getting a "Destination unreachable" from their closest router. We 
did rerouting through a different carrier, so not a big problem for us, 
but still annoying.



# ping6 ipv6.google.com
PING ipv6.google.com(dfw06s47-in-x0e.1e100.net) 56 data bytes
   From te0-0-0-1.rcr12.sea03.atlas.cogentco.com icmp_seq=1 Destination
unreachable: No route




On 18.02.2016 at 07:01 Damien Burke wrote:

I am currently having a issue with cogent and google over ipv6. My traceroute 
seems to hit cogent, Verizon, and then just dies.

I have a case open with both and each tells me the other is working on it.

-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Max Tulyev
Sent: Wednesday, February 17, 2016 1:35 PM
To: nanog@nanog.org
Subject: Re: Cogent <=> Google Peering issue

If my telepathy still works fine and I understood your question well - then the answer is 
"NO, that is not a global well-known issue" ;)

On 17.02.16 18:15, Fred Hollis wrote:

Anyone else aware of it?

Cogent <=> Google Peering issue

[Fred Hollis]

Anyone else aware of it?

Re: Internap route optimization

[Fred Hollis]

Border6 offers such an option based on prependings and bgp communities. 
But honestly, I didn't test that feature yet. And I'm not that sure how 
much sense it makes since it probably requires quite a lot global BGP 
updates... makes routers even more busy than they are currently.


On 05.11.2015 at 14:56 Sebastian Spies wrote:

Hey Mike,

do you know route optimizers that actually do optimize inbound traffic?
We, at datapath.io, are currently working on this and could not find
another one that does it.

Best,
Sebastian

Am 05.11.2015 um 14:21 schrieb Mike Hammett:

Keep in mind that most do not optimize inbound traffic, only outbound.




-
Mike Hammett
Intelligent Computing Solutions
http://www.ics-il.com

- Original Message -

From: "Paras" 
To: nanog@nanog.org
Sent: Thursday, November 5, 2015 2:03:41 AM
Subject: Internap route optimization

Does anyone know or have any experience with Internap's route
optimization? Is it any good?

I've heard of competing solutions as well, such as the one provided by
Noction.

Thanks for your input,
Paras

Re: Internap route optimization

[Fred Hollis]

Totally right! That's why I wrote

>> For sure traffic engineering/optimization is not a trivial task but 
requires

>> deep thinking and understanding of the whole BGP and routing picture.

;)

On 05.11.2015 at 11:01 Christopher Morrow wrote:

Also, please, if you use one of this sort of device filter your
prefixes toward your customers/peers/transits... Do not be the next
person to leak their internap-box-routes to the world, m'kay? :)

On Thu, Nov 5, 2015 at 8:53 PM, Fred Hollis  wrote:

Hi,

No particular experience with Internaps optimization...however I wouldn't be
that sure if I would use it within our networks, because you always have the
conflict of this not being their core business as they want to sell their
optimized IP transit.

However, some time ago we tried Border6 in an evaluation and then finally
put it into production. Not only the optimization is nice, but the reporting
is so extremely detailed making it very transparent where the transit has
congestion issues and which prefix is routed (in and out) through which
upstream.

For sure traffic engineering/optimization is not a trivial task but requires
deep thinking and understanding of the whole BGP and routing picture.


On 05.11.2015 at 09:03 Paras wrote:


Does anyone know or have any experience with Internap's route
optimization? Is it any good?

I've heard of competing solutions as well, such as the one provided by
Noction.

Thanks for your input,
Paras

Re: Internap route optimization

[Fred Hollis]

Hi,

No particular experience with Internaps optimization...however I 
wouldn't be that sure if I would use it within our networks, because you 
always have the conflict of this not being their core business as they 
want to sell their optimized IP transit.


However, some time ago we tried Border6 in an evaluation and then 
finally put it into production. Not only the optimization is nice, but 
the reporting is so extremely detailed making it very transparent where 
the transit has congestion issues and which prefix is routed (in and 
out) through which upstream.


For sure traffic engineering/optimization is not a trivial task but 
requires deep thinking and understanding of the whole BGP and routing 
picture.


On 05.11.2015 at 09:03 Paras wrote:

Does anyone know or have any experience with Internap's route
optimization? Is it any good?

I've heard of competing solutions as well, such as the one provided by
Noction.

Thanks for your input,
Paras

Re: IP-Echelon Compliance

[Fred Hollis]

At least, we tried contacting you many times, but you ignored all our 
requests.


Still receiving thousands of e-mails not related to our IPs on daily basis.

On 13.10.2015 at 00:04 Seth Arnold wrote:

Hi All,

Please feel free to get in touch with us to request changes.

Expedited processing of your requests is offered through the Notice Recipient 
Management for ISPs section of our website located here:
http://www.ip-echelon.com/isp-notice-management/ 


If you are in the U.S., please also ensure that your change is reflected in the 
records of the US Copyright Office:  http://copyright.gov/onlinesp/list/a_agents.html 



Cheers,
Seth

Re: IP-Echelon Compliance

[Fred Hollis]

Oh, interesting you have the same? We receive thousands of these 
complains on daily basis that are not related to any of our IPs.


Of course we contacted them... but never got a response.

On 09.10.2015 at 22:00 Baldur Norddahl wrote:

Hi

I am sure all of you know of these guys. But what do you do when they keep
spamming your abuse address with reports for illegal downloads from
IP-addresses that are in no way related to our business?

I tried contacting them. And was told repeatedly that I had to update whois
information if I want the reports to be sent to another address. How I do
that for IP-ranges that are not mine is a good question. Besides the whois
information for said IP-ranges already have valid abuse information and it
is not our email address.

Do I just block them for spamming?

Regards,

Baldur

Re: GeoIP information

[Fred Hollis]

> They could purchase sales records from online retailers. Hey guys,
> give us the IP address, city, state and zip code for each sale; we'll
> pay you a nickle each. Then correlate that with BGP announcements that
> show the range of impacted addresses.

After looking more into the geo ip topic, I totally noticed, geo data 
should NOT correlate  with BGP data at all! There are a couple of geo ip 
services that are doing it like you described, but IMO it's wrong.
See big telco's announcing /12's and having these IPs spread all over 
the country.


On 25.09.2015 at 03:51 William Herrin wrote:

On Thu, Sep 24, 2015 at 9:45 PM, Ray Van Dolson  wrote:

I assumed it must be based off of WHOIS.  The IP space I'm working with
is in the midwest (US).  The address associated with it is from our
primary IP block out here in California, which it would have only been
able to gather from WHOIS.  If it had gone off the last hop, presumably
it would have seen that as something a little closer to the real
location rather than *exactly* where our primary environment is. :)


They could also do RDNS lookups and then see what rwhois says about the domain.

They could purchase sales records from online retailers. Hey guys,
give us the IP address, city, state and zip code for each sale; we'll
pay you a nickle each. Then correlate that with BGP announcements that
show the range of impacted addresses.

They could convince folks to install web browser plugins which give
the users rewards in exchange for ceding personal information. Or buy
data from a company which does.

-Bill

Re: GeoIP information

[Fred Hollis]

It is a big pain to do so. We did a couple of times in the past and 
always took us many months.


On 25.09.2015 at 03:48 Ian Clark wrote:

Is there anyone here who has successfully changed their GeoIP data for a
subset of their ARIN allocation?
How do service providers get all the GeoIP companies to have correct
information for their address ranges?  Do they just pay them to update it?
At first I thought it had to do with whois data, but my home Verizon IP
whois lists Ashburn, VA, yet the GeoIP data shows my local city.

We're trying to find a way to correct our GeoIP data for a specific IP
range, but aren't sure what the best practices are for doing so.  Any
advice would be awesome!

Re: High latency/packetloss in nyc/nj for cogent/level3/zayo?

[Fred Hollis]

1.|-- hosted-by-i3d.net 0.0% 10 8.1 17.3 0.3 144.6 45.0
2.|-- 80ge.cr0-br2-br3.smartdc.rtd.i3d.net 0.0% 10 0.3 2.1 0.2 9.4 3.0
3.|-- 40ge.cr1-cr0.smartdc.rtd.i3d.net 0.0% 10 0.3 7.3 0.3 13.3 5.7
4.|-- ae51.edge4.London1.Level3.net 0.0% 10 10.6 14.2 7.6 30.4 7.5
5.|-- 4.69.156.9 90.0% 10 224.7 224.7 224.7 224.7 0.0
6.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
7.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
8.|-- cs20.cs90.v.ewr.nyinternet.net 80.0% 10 169.4 168.8 168.1 169.4 0.9
9.|-- 96.47.77.134.static.nyinternet.net 90.0% 10 167.7 167.7 167.7 
167.7 0.0

10.|-- ftw.nj.nyi.net 90.0% 10 169.4 169.4 169.4 169.4 0.0

Having this to almost every network located in NYC/NJ that is going 
through the said three carrier from many locations.


On 04.09.2015 at 23:24 Jürgen Jaritsch wrote:

Hi,

wer're working with Telia and Hurricane in NYC and we only see some latency 
flaps in the HE network  flapping from 0.3 to ~15ms. Nothing really bad. No 
visible packet loss.


Best regards

Jürgen Jaritsch
Head of Network & Infrastructure

ANEXIA Internetdienstleistungs GmbH

Telefon: +43-5-0556-300
Telefax: +43-5-0556-500

E-Mail: j...@anexia.at
Web: http://www.anexia.at

Anschrift Hauptsitz Klagenfurt: Feldkirchnerstraße 140, 9020 Klagenfurt
Geschäftsführer: Alexander Windbichler
Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601

-Ursprüngliche Nachricht-
Von: NANOG [mailto:nanog-boun...@nanog.org] Im Auftrag von Fred Hollis
Gesendet: Freitag, 04. September 2015 23:18
An: nanog@nanog.org
Betreff: High latency/packetloss in nyc/nj for cogent/level3/zayo?

Hi,

Anyone also experiencing really high lancy and packetloss 80%+ in nyc/nj
area for cogent/level3/zayo?

High latency/packetloss in nyc/nj for cogent/level3/zayo?

[Fred Hollis]

Hi,

Anyone also experiencing really high lancy and packetloss 80%+ in nyc/nj 
area for cogent/level3/zayo?

Looking for IPv6 /48 from allocation that exists 2-3+ yrs

[Fred Hollis]

Hello NANOG,

Due to problems with some geo ip databases, we are looking for a /48 
from an /32 or /36 allocation that exists for a few years already. 
East-coast preferred, but open to others in north america as well.


Please contact me offlist

Thank you,
Fred

Re: Fixing Google geolocation screwups

[Fred Hollis]

Honestly, I lost patience "the system learning the proper location of 
the IPv6 block". I have a very similar problem to the OP since 4-5 
months, submitted this IP correction form multiple times... nothing changed.

This is *very* annoying.

Yes, my whois/SWIP is perfectly fine, every other geo ip database is 
showing correct location.


On 06.05.2015 at 03:36 Matt Palmer wrote:

On Wed, May 06, 2015 at 10:56:22AM +1000, Mark Andrews wrote:

In message <20150505210746.gh22...@hezmatt.org>, Matt Palmer writes:

On Tue, May 05, 2015 at 12:03:23PM -0400, Luan Nguyen wrote:

There's a form here - https://support.google.com/websearch/contact/ip
But google is pretty smart, its systems will learn the correct geolocation
over time...


That'd be quite a trick, given that the netblock practically can't be used
at all with Google services.


One would expect support.google.com to not be geo blocked just like
postmaster@ should not be filtered.  That said they can always
disable IPv6 temporarially (or just firewall off the IPv6 instance
of support.google.com and have the browser fallback to IPv4) and
reach support.google.com over IPv4 to lodge the complaint.


I was specifically responding to the suggestion that Google would
automagically "learn" the correct location of the netblock, presumably based
on the characteristics of requests coming from the range.  Being explicitly
told that a given netblock is in a given location (as effective, or
otherwise, as that may be) doesn't really fit the description of "systems
[learning] the correct geolocation over time".

- Matt

Re: Fixing Google geolocation screwups

[Fred Hollis]

Thanks for sending this to the list: We have the very same issue as well 
(both IPv4+IPv6). If someone knows the magic button to solve this, 
please contact me as well.


On 08.04.2015 at 00:26 John Levine wrote:

A friend of mine lives in Alabama and has business service from at&t.
But Google thinks he's in France.  We've checked for various
possibilities of VPNs and proxies and such, and it's pretty clear that
the Goog's geolocation for addresses around 99.106.185.0/24 is screwed
up.  Bing and other services correctly find him in Alabama.

Poking around I see lots of advice about how to use Google's
geolocation data, but nothing on how to update it.  Anyone
know the secret?  TIA

Regards,
John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly

Any google network admins out there?

[Fred Hollis]

I need contact to a Google network Admin as well. Having some serious 
issues with our clients reaching Google services.


On 03.04.2015 at 23:53 Matt Palmer wrote:

Or, to answer your question more simply: "No".

- Matt

On Fri, Apr 03, 2015 at 11:39:36AM +0100, Pedro Cavaca wrote:

https://support.google.com/websearch/answer/86640?hl=en

On 3 April 2015 at 04:53, Randy  wrote:


I've started to get some message today from google claiming that my
computer or network was sending automated queries, and they are blocking me.
I'm not sending automated queries, Ive logged all of my outbound traffic
and there is only my browser traffic going to google.

I'm not responsible for any one else on "my network" since it is owned by
my ISP, and solely blocking me based on what some one else with an ip
address close to mine is not an acceptable practice to have for an address
used for personal web browsing.
I would like to know if there is any way to get into contact with google
about this other then by legal means?

Re: Purpose of spoofed packets ???

[Fred Hollis]

Interesting... we had exactly the same an hour ago. That IP was 
definitely nullrouted for >1 week...


Matthew Huff:

We recently got an abuse report of an IP address in our net range. However, 
that IP address isn't in use in our networks and the covering network is null 
routed, so no return traffic is possible. We have external BGP monitoring, so 
unless something very tricky is going on, we don't have part of our prefix 
hijacked.

I assume the source address was spoofed, but this leads to my question. Since 
the person that submitted the report didn't mention a high packet rate (it was 
on ssh port 22), it doesn't look like some sort of SYN attack, but any OS 
fingerprinting or doorknob twisting wouldn't be useful from the attacker if the 
traffic doesn't return to them, so what gives?

BTW, we are in the ARIN region, the report came out of the RIPE region.



Matthew Huff | 1 Manhattanville Rd
Director of Operations   | Purchase, NY 10577
OTA Management LLC   | Phone: 914-460-4039
aim: matthewbhuff| Fax:   914-694-5669