Re: 10 Do's + Don'ts for Visiting Québec + Register Now for N85!

[Stephen Fulton]

I will add that card cloning is common enough in Canada that one should 
take precautions, particularly if just using the magnetic strip instead 
of tapping or chip/code.  Don't hand your card to anyone to allow them 
to swipe either, no matter how nicely they offer.


If you are not from Canada and do not speak French but have an English 
accent that could be from another part of Canada, you may get an 
atittude from some service workers.. just explain that you're not from 
Canada and the attitude will clear right up.


It's a wonderful city, just use your head.





On 2022-05-08 08:11, jim deleskie wrote:
Having lived in and continue to spend as much time in Montreal as I 
can.  This list made be laugh, especially for a group where most of us 
do a lot of travel.


Other then no right on red.  Montreal like any other city.  Don't be an 
ass and enjoy yourself.




On Thu, May 5, 2022, 9:56 AM Nanog News > wrote:


*10 Do's + Don'ts for Visiting Québec*
/NANOG 85 Meeting Will Take Place Jun. 6 - 8 in Montréal/

We are delighted to cross international borders in our mission to
grow, inspire + profoundly build the Internet of tomorrow!

Montréal is Canada's second-largest city and is known for its
melting pot of diverse culture, established universities,
enthralling art, food, history + festivals. It has been called one
of the world's "happiest locations" as an estimated 45,000
immigrants relocate to the city every year.

For those who don't call Québec home, we have prepared a list of
cultural "Do's and Don'ts" to help you quickly acclimate + thrive in
this foreign destination.

*READ MORE
*

*Register for NANOG 85 Today!*

Join us in person or virtually for NANOG 85. Don't miss your chance
to experience hours of ground-breaking industry talks, a legendary
keynote speaker, opportunities for networking + more.

*REGISTER NOW *

Re: netflow in the core used for surveillance

[Stephen Fulton]

Randy,

It is quite possible that some are simply the victim of their own 
ignorance.  I know of an ISP where one of their last-mile hardware 
vendors was pushing hard to get junior technical staff and senior 
non-technical staff to agree to share netflow data.  When senior 
technical staff found out, they told the vendor that they would not 
share the data and to stop.  The vendor persisted.  After probing to 
find out what vendor was used in the core & peering parts of the ISP's 
network, one of the vendor's staff kindly provided netflow configuration 
to the junior technical staff, along with specific instructions to apply 
it to their transit/peering ports.  The destination of the flows was a 
server under the complete control of the vendor, not the ISP.  This was 
brought to the attention of senior technical staff and you can guess 
what happened.


The vendor is not one of the majors, they are still relatively young.  I 
won't share the name on the list.


-- Stephen







On 2021-08-25 17:13, Randy Bush wrote:

https://www.vice.com/en/article/jg84yy/data-brokers-netflow-data-team-cymru

used to get dissidents, activists, and journos killed

at, comcast, ... zayo, please tell us you do not do this.

randy

Re: Amazon Contact?

[Stephen Fulton]

I'll try and beat Mike to this:

  http://thebrotherswisp.com/index.php/geo-and-vpn/

The above has contact info for a number of orgs to resolve geolocation & 
VPN problems, including Amazon.  Work in progress.


-- Stephen

On 2021-08-25 15:55, Chris Cappuccio wrote:

Looking to see if I can get someone at Amazon to help. Amazon Video is starting 
to think our CGN exit range is a VPN service (It isn't)

Chris

Re: COVID-19 vs. our Networks

[Stephen Fulton]

In $dayjob I constantly see the lack of understanding of the difference 
between what the Internet is and what a path engineered private circuit 
is (eg. pseudowire, wave, whatever).  The latest fight is over SD-WAN 
and those who think it will replace MPLS entirely and they won't need 
those expensive routers anymore.  But I digress.


Mark's comment and others like it are the correct approach Mike.  If 
your private WAN is most critical, then invest in and manage user 
complaints about poor Internet service.  ISP's, IXP's and CDN's are not 
going to twist themselves into knots to solve your problems, even if 
someone calls it an emergency.  Sorry.


Stephen


On 2020-03-15 02:01, Mark Tinka wrote:



On 14/Mar/20 19:14, Mike Bolitho wrote:


/
/

I work for a hospital, we ran into some issues last week due to 
congestion that was totally outside of our control that was off of our 
WAN (Thanks Call Of Duty). Now, the issue we ran into was not mission 
critical at the time but it was still disruptive. As more and more 
people are driven home during this time, more and more people will be 
using bandwidth intensive streaming and online gaming products. If 
more and more TSP coded entities are running into issues, ISPs, IXPs, 
and CDNs will be forced to act.


Hmmh, if that level of priority is required, I'd probably build my own 
network, and not rely on public infrastructure like the Internet.


Mark.

Re: COVID-19 vs. our Networks

[Stephen Fulton]

Mike,

For those nets with a higher peak in the evenings, the graphs will 
flatten out.  If you're struggling any given weekday evening, you'll be 
in trouble from the start.  Major events and software releases are what 
will use up available buffers.


IMO the Disney+ surprise was a good thing.  It forced networks to 
realize they needed more capacity.  Disney+ streaming isn't what it was 
but if you've been adding capacity as a result of it, you're in better 
shape to weather the latest network surges.


-- Stephen


On 2020-03-12 19:02, Mike Hammett wrote:
Just imagine all of those people streaming Netflix and playing COD all 
day instead of only a few hours at night.




-
Mike Hammett
Intelligent Computing Solutions 

Midwest Internet Exchange 

The Brothers WISP 


*From: *"g...@1337.io" 
*To: *nanog@nanog.org
*Sent: *Thursday, March 12, 2020 12:22:17 PM
*Subject: *COVID-19 vs. our Networks

With talk of there being an involuntary statewide (WA) and then national 
quarantines (house arrest) for multiple weeks, has anyone put thought 
into the impacts of this on your networks if/when this comes to fruition?


We're already pushing the limits with telecommuters / those that are 
WFH, but I can only imagine what things will look like with everyone 
stuck at home for any duration of time.

Re: google cloud console is slow

[Stephen Fulton]

Hi Izzy,

Perhaps this is a better discussion for the outages discussion list? 
You should probably also provide more technical details (obfuscated 
src/dst etc).


Stephen

On 2020-02-07 10:38, Izzy Goldstein - TeleGo wrote:

from the US East Cost on Verizon FiOS
google cloud console is extremely slow

--

Izzy Goldstein

Chief Technology Officer

Main: (212) 477-1000 x 2085 

Direct: (929) 477-2085 

Website:www.telego.com 





Confidentiality Notice: This e-mail may contain confidential and/or 
privileged information. If you are not the intended recipient or have 
received this e-mail in error please notify us immediately by email 
reply and destroy this e-mail. Any unauthorized copying, disclosure or 
distribution of the material in this e-mail is strictly forbidden. Any 
views or opinions presented in this email are solely those of the author 
and do not necessarily represent those of TeleGo (T). Employees of 
TeleGo are expressly required not to make defamatory statements and not 
to infringe or authorize any infringement of copyright or any other 
legal right by email communications. Any such communication is contrary 
to TeleGo policy and outside the scope of the employment of the 
individual concerned. TeleGo will not accept any liability in respect of 
such communication, and the employee responsible will be personally 
liable for any damages or other liability arising.



TeleGo Hosted PBX 

Re: Mx204 alternative

[Stephen Fulton]

On 2019-08-10 02:29, Saku Ytti wrote:

> On Sat, 10 Aug 2019 at 00:22, Brandon Martin  wrote:
> 
>> Yes, yes they will.  I've seen some distributor pricing and, while not
>> officially under NDA, I will not mention it directly.  Suffice to say
>> you should demand at least 40-50% off list from your vendor to start with.
> 
> You get better price from newegg for CSCO gear.
> 

I've found that if Cisco is presented with competing quotes for
comparable equipment (eg. MX204 versus ASR9901) then they have inventive
to price their products competitively.  That said, a lot of SP's in the
Canadian market are moving to the MX204 because of the pricing and Cisco
was late to ingest that fact internally.

-- S

Re: AS16509 (Amazon) peering contact

[Stephen Fulton]

Hi Kody,

Please don't share a person's e-mail account on a mailing list.  Role
accounts are one thing, but not this.  If you want to, send it privately. 

Cheers,

Stephen

On 2019-06-27 17:47, Kody Vicknair wrote:
> I've always worked with Tim Bates. They were exceptionally quick with 
> standing up my session. like same day quick...
>
> x...@amazon.com
>
>
>
>
>
> Kody Vicknair
> Network Engineer
>
> Tel:985.536.1214
> Fax:985.536.0300
> Email:  kvickn...@reservetele.com
>
> Reserve Telecommunications
> 100 RTC Dr
> Reserve, LA 70084
>
> _
>
> Disclaimer:
> The information transmitted, including attachments, is intended only for the 
> person(s) or entity to which it is addressed and may contain confidential 
> and/or privileged material which should not disseminate, distribute or be 
> copied. Please notify Kody Vicknair immediately by e-mail if you have 
> received this e-mail by mistake and delete this e-mail from your system. 
> E-mail transmission cannot be guaranteed to be secure or error-free as 
> information could be intercepted, corrupted, lost, destroyed, arrive late or 
> incomplete, or contain viruses. Kody Vicknair therefore does not accept 
> liability for any errors or omissions in the contents of this message, which 
> arise as a result of e-mail transmission. .
>
> -Original Message-
> From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Hansen, Christoffer
> Sent: Thursday, June 27, 2019 2:45 PM
> To: nanog@nanog.org
> Subject: Re: AS16509 (Amazon) peering contact
>
>
> On 27/06/2019 20:55, Andras Toth wrote:
>> Including at least an ASN in the peering request usually helps to
>> expedite the process :)
> & keeping your peeringdb entry up-to-date is usually helpful, too.
> Depending on who you want to peer with(!)
>
> Some networks require you to have up-to-date peeringdb information for your 
> network. Including which facilities and/or internet exchanges you are either 
> connected to and/or present on/in.
> This will often be the case if $peering_partner have either partial or fully 
> automated peering configuration management.
>
> /Christoffer

Re: AS3266: BitCanal hijack factory, courtesy of Cogent, GTT, and Level3

[Stephen Fulton]

Job,

Unless of course they are not actually on an IXP listed.  Bitcanal is 
not a member of TorIX and as far as I recall, never has been.  The IP 
they list in PeeringDB was never assigned to them at any point and in 
fact was used by an AS112 instance which was run by TorIX directly on 
the fabric for a time.  I sent in a note to PeeringDB several years ago 
about Bitcanal claiming to be a peer when they were not and never heard 
back.. I'll resend.


-- Stephen (ops, TorIX)



On 2018-06-26 1:01 AM, Job Snijders wrote:

On Mon, 25 Jun 2018 at 22:49, Ronald F. Guilmette 
wrote:


Without the generous support of Cogent, GTT, and Level3 this dumbass
lowlife IP address space thief would be largely if not entirely toast.
So what are they waiting for?  Why don't their turf this jackass?  Are
they waiting for an engraved invitation or what?

As I always ask, retorically, in cases like this:  Where are the grownups?




You could ask the same about the IXPs that facilitate the reach and impact
of Bitcanal’s BGP hijacks by allowing that network on their platform:
https://bgp.he.net/AS197426#_ix

Kind regards,

Job

Re: 100G - Whitebox

[Stephen Fulton]

Mike,

Whether it becomes a practical problem depends on the use case and by
that I mean buffers can cut both ways.  If buffers are too small,
traffic can be dropped and even worse, other traffic could be affected
depending on factors like ASIC design an HOLB.  Too large, latency or
order sensitive traffic can be adversely affected.

We're still dealing with the same limitations of switching which were
identified 30+ years ago as the technology was developed.  Sure we have
better chips, the options of better buffers and years ago experience to
help minimize those limitations, but those still exist and likely always
will with switching.

Honestly at this point it comes down to understanding what the use case
it and understanding the nuances that each vendor's offerings provide
and determining where things line up.  Then test test test.

-- Stephen



On 2017-12-04 2:45 PM, Mike Hammett wrote:
> In terms of 1G - 10G steps, it looks like UCSC has done some of that homework 
> already. 
> 
> 
> https://people.ucsc.edu/~warner/Bufs/summary 
> 
> 
> "Ability to buffer 6 Mbytes is sufficient for a 10 Gb/s sender and a 1 Gb/s 
> receiver." I'd suspect 10x would be appropriate for 100G - 10G (certainly 
> made more accurate by testing). 
> 
> 
> http://people.ucsc.edu/~warner/I2-techs.ppt 
> 
> 
> 
> Looking through their table ( https://people.ucsc.edu/~warner/buffer.html ), 
> it looks like more switches than not in the not-100g realm have just enough 
> buffers to handle one, possibly two mis-matches at a time. Some barely don't 
> have enough and others are woefully inadequate. 
> 
> 
> 
> - 
> Mike Hammett 
> Intelligent Computing Solutions 
> http://www.ics-il.com 
> 
> Midwest-IX 
> http://www.midwest-ix.com 
> 
> - Original Message -
> 
> From: "Nick Hilliard"  
> To: "Mikael Abrahamsson"  
> Cc: "NANOG list"  
> Sent: Monday, August 21, 2017 6:10:17 AM 
> Subject: Re: 100G - Whitebox 
> 
> Mikael Abrahamsson wrote: 
>> On Sun, 20 Aug 2017, Nick Hilliard wrote: 
>>> Mostly you can engineer around this, but it's not as simple as saying 
>>> that small-buffer switches aren't suitable for an IXP. 
>>
>> Could you please elaborate on this? 
>>
>> How do you engineer around having basically no buffers at all, and 
>> especially if these very small buffers are shared between ports. 
> 
> you assess and measure, then choose the appropriate set of tools to deal 
> with your requirements and which is cost appropriate for your 
> financials, i.e. the same as in any engineering situation. 
> 
> At an IXP, it comes down to the maximum size of tcp stream you expect to 
> transport. This will vary depending on the stakeholders at the IXP, 
> which usually depends on the size of the IXP. Larger IXPs will have a 
> wider traffic remit and probably a much larger variance in this regard. 
> Smaller IXPs typically transport content to access network data, which 
> is usually well behaved traffic. 
> 
> Traffic drops on the core need to be kept to the minimum, particularly 
> during normal operation. Eliminating traffic drops is unnecessary and 
> unwanted because of how IP works, so in your core you need to aim for 
> either link overengineering or else enough buffering to ensure that 
> site-to-site latency does not exceed X ms and Y% packet loss. Each 
> option has a cost implication. 
> 
> At the IXP participant edge, there is a different set of constraints 
> which will depend on what's downstream of the participant, where the 
> traffic flows are, what size they are, etc. In general, traffic loss at 
> the IXP handoff will tend only to be a problem if there is a disparity 
> between the bandwidth left available on the egress direction and the 
> maximum link speed downstream of the IXP participant. 
> 
> For example, a content network has servers which inject content at 10G, 
> which connects through a 100G IXP port. The egress IXP port is a 
> mid-loaded 1G link which connects through to 10mbit WISP customers. In 
> this case, the ixp will end up doing negligible buffering because most 
> of the buffering load will be handled on the WISP's internal 
> infrastructure, specifically at the core-to-10mbit handoff. The IXP 
> port might end up dropping a packet or two during the initial tcp burst, 
> but that is likely to be latency specific and won't particularly harm 
> overall performance because of tcp slow start. 
> 
> On the other hand, if it were a mid-loaded 1G link with 500mbit access 
> customers on the other side (e.g. docsis / gpon / ftth), then the IXP 
> would end up being the primary buffering point between the content 
> source and destination and this would cause problems. The remedy here 
> is either for the ixp to move the customer to a buffered port (e.g. 
> different switch), or for the access customer to upgrade their link. 
> 
> If you want to push 50G-80G streams through an IXP, I'd argue that you 
> really shouldn't, not just because of 

Re: Question about Customer Population by ASN for Canada

[Stephen Fulton]

Hi Jack,

As OVH is a data centre, I find that extraordinary if eyeballs were the 
cost.  VPN's may be popular but that seems excessive.  Probably bots of 
some sort, scraping the internet.


-- Stephen

On 2017-10-02 3:57 PM, Jacques Latour wrote:

Hi all!

I'm working on our IPv6 and DNSSEC adoption report for Canada and the data I 
use comes largely from APNIC (https://stats.labs.apnic.net/dnssec/CA) and 
(https://stats.labs.apnic.net/ipv6/CA).

Labs.APNIC has a pretty cool system to measure this kind of stuff by deploying specially 
crafted google ads, see "How Big is that Network?"  
https://labs.apnic.net/?p=526, and APNIC is able to assess the population behind a 
network based on ad placement distribution. See 
https://stats.labs.apnic.net/cgi-bin/aspop?c=CA for Canada.

The question I have is why does OVH come #6 with an estimated population of 
1,480,927 behind its ASN? Remember these are actual placement of ads.  Should I 
count those users as part of my stats?

RankASN AS Name CC  Users (est.)% of country% of Internet   
Samples
1   AS812   ROGERS-CABLE - Rogers Cable Communications Inc. 
CA 5,420,034   16.72   
0.16555,718
2   AS577   BACOM - Bell Canada 
CA 4,474,012   13.8
0.132   458,722
3   AS6327  SHAW - Shaw Communications Inc. 
CA 3,708,414   11.44   
0.109   380,225
4   AS852   ASN852 - TELUS Communications Inc.  
CA 2,914,405   8.99
0.086   298,815
5   AS5769  VIDEOTRON - Videotron Telecom Ltee  
CA 2,189,946   6.76
0.065   224,536
6   AS16276 OVH CA 
1,480,927   4.570.044   151,840
7   AS15290 ALLST-15290 - Allstream Corp.   
CA 1,272,374   3.93
0.038   130,457
8   AS855   CANET-ASN-4 - Bell Aliant Regional Communications, Inc. 
CA 1,211,485   3.74
0.036   124,214
9   AS7992  COGECOWAVE - Cogeco Cable   
CA 1,112,002   3.43
0.033   114,014
10  AS5645  TEKSAVVY - TekSavvy Solutions, Inc. 
CA 967,401 2.980.029   
99,188
11  AS11260 EASTLINK-HSI - EastLink 
CA 695,598 2.150.021   
71,320
12  AS47027 SEASIDE-COMM - Seaside Communications, Inc. 
CA 425,561 1.310.013   
43,633
13  AS803   SASKTEL - Saskatchewan Telecommunications   
CA 392,186 1.210.012   
40,211
14  AS11814 DISTRIBUTEL-AS11814 - DISTRIBUTEL COMMUNICATIONS LTD.   
CA 370,348 1.140.011   
37,972

Jack

Re: Best way to San Jose Fairmont from SFO?

[Stephen Fulton]

Thanks Bob!

-- Stephen

On 2017-09-28 4:47 PM, Bob Evans wrote:

Depending on commute times with traffic - you will most likely travel 101
south.
Uber works well from SFO. You catch an Uber ride on the arrival level.

Rental carGoogle Maps knows several pathways. But it will most likely
take you via 101.
This hotel is popular in downtown San Jose - not hard to find.

Train and Bus travel is not worth considering. However, there are airport
shuttle van services like supershuttle 4-5 passengers being dropped off on
your way south.

Thank You
Bob Evans
CTO





Hi all,

I'm flying in for the conference, landing in San Francisco.  What's the
best way to get from SFO to the conference hotel?

Thanks,

-- Stephen

Best way to San Jose Fairmont from SFO?

[Stephen Fulton]

Hi all,

I'm flying in for the conference, landing in San Francisco.  What's the 
best way to get from SFO to the conference hotel?


Thanks,

-- Stephen

Re: US/Canada International border concerns for routing

[Stephen Fulton]

TR,

MTS Allstream is no longer a combined entity.  MTS was purchased by Bell 
Canada and Allstream was purchased by Zayo.


-- Stephen

On 2017-08-08 8:19 PM, TR Shaw wrote:

Bill,

What does Bell buying MTS do? Does it change your statement or will the MTS 
portion of Bell still peer locally?

Tom


On Aug 8, 2017, at 8:10 PM, Bill Woodcock  wrote:



On Jul 20, 2017, at 7:01 AM, Hiers, David  wrote:
For traffic routing, is anyone constraining cross-border routing between Canada 
and the US?  IOW, if you are routing from Toronto to Montreal, do you have to 
guarantee that the path cannot go through, say, Syracuse, New York?


No.  In fact, Bell Canada / Bell Aliant and Telus guarantee that you _will_ go 
through Chicago, Seattle, New York, or Ashburn, since none of them peer 
anywhere in Canada at all.

Last I checked (November of last year) the best-connected commercial networks 
(i.e. not CANARIE) in Canada were Hurricane Electric, MTS Allstream, Primus, 
and Zip Telecom, all of which peer at three or more Canadian IXes.  So, they’re 
capable of keeping traffic in Canada so long as the other end isn’t on Bell or 
Telus, which only sell U.S. bandwidth to Canadians.

In November, only 27% of intra-Canadian routes stayed within Canada; 64% went 
through the U.S.  That’s way worse than five years ago, when 60% stayed within 
Canada, and 38% went through the U.S.

As has been pointed out, Canada has been building IXPs…  Just not as fast as 
the rest of the world has.  They’re behind the global average growth rate, and 
behind the U.S. growth rate, which is why the problem is getting worse.  
Bandwidth costs are falling faster elsewhere, so they’re importing more foreign 
bandwidth.

-Bill

Re: Google Cloud and IX - Traffic behavior

[Stephen Fulton]

Alain,

When you refer to "normal peering" do you mean Internet transit?  Or are 
these PNI's with Google?  Do the GCLD instance you reach through "normal 
peering" have higher latency than through TorIX?


-- Stephen

On 2017-06-16 6:58 PM, Alain Hebert wrote:

 Hi,

 Anyone aware of different traffic behavior depending if the target 
goes through normal peering than through an exchanges google exists in?


 We're facing a weird issue where the same GCLD Instance can upload 
up to 200Mbps (Ref 1) if the target path goes through, lets say TorIX, 
but cannot get more than 20Mbps on similar hosts (8 of them) sittings on 
our peering links.


 PS; Those sames hosts get up to their link limit ( 1Gbps ) between 
each others and others test points we have;


 PS: Wireshark capture show nothing abnormal;

 PS: Links aren't congested, and so on...

Ref 1 - 200Mbps is on a link rate-limited to 300Mbps.  Its my only test 
point with a TorIX access

Re: Fwd: hotel

[Stephen Fulton]

I tried booking earlier today, had the same issue and called in.  I was 
told they were now full, and only non-block rooms were available (@ > 
$500/night).


-- Stephen

On 2016-05-02 10:26 PM, Randy Bush wrote:

excuse puking on list but the path to nanog admin action seems dead

Date: Sun, 01 May 2016 13:48:10 +0900
From: Randy Bush 
To: action 
Subject: hotel

hi,

sorry to bother, but

fairmont chicago block supposedly good to 22 may.  tried to book just
now, arriving 11th leaving 16th.  got told "No lodging matches your
search criteria. Please change your search options at right and try
again."

thanks

randy

Re: RADb Outage?

[Stephen Fulton]

Same here, whois.radb.net still appears down as of this message.

-- Stephen


On 2016-01-22 5:27 PM, Brian Rak wrote:

whois.radb.net seems to have been down since sometime last night, has
anyone else seen problems with this?

It seems the web interface still works, but that's not very useful for
scripts.

Re: Synful Knock questions...

[Stephen Fulton]

Follow-up to my own post, Fireeye has code on github:

https://github.com/fireeye/synfulknock

On 2015-09-16 10:27 AM, Stephen Fulton wrote:

Interesting, anyone have more details on how to construct the scan using
something like nmap?

-- Stephen

On 2015-09-16 9:20 AM, Royce Williams wrote:

HD Moore just posted the results of a full-Internet ZMap scan.  I didn't
realize that it was remotely detectable.

79 hosts total in 19 countries.

https://zmap.io/synful/

Royce

Re: Synful Knock questions...

[Stephen Fulton]

Interesting, anyone have more details on how to construct the scan using 
something like nmap?


-- Stephen

On 2015-09-16 9:20 AM, Royce Williams wrote:

HD Moore just posted the results of a full-Internet ZMap scan.  I didn't
realize that it was remotely detectable.

79 hosts total in 19 countries.

https://zmap.io/synful/

Royce

Re: Alcatel-Lucent 7750 Service Router (SR)

[Stephen Fulton]

What's the price point of an SR-A4?  Comparable to the MX104 or ASR9001?

-- Stephen

On 2015-05-06 7:13 PM, Craig wrote:

If you know Juniper and Cisco, the learning curve isn't so bad to pick up
the ALU CLI, after working with it for a brief time, you catch on quickly.
Their products are quite impressive, and a # of the carriers, are moving to
them and some have already moved to them and are quite happy with their
decision.


On Wed, May 6, 2015 at 6:24 PM, Colton Conor colton.co...@gmail.com wrote:


I am worried as most tech's know Cisco and Juniper, so going to ALU would
be a learning curve based on replies I am getting off list.

On Wed, May 6, 2015 at 5:22 PM, Dan Snyder sliple...@gmail.com wrote:



They are definitely good for that. We use them in part of our network for
something very similar.

I am not sure why they aren't mentioned that much. I know that they have
been pretty popular in the past couple years.

We are planning on using 7750 SR-a4's in the future but right now we
mainly have 7750SR7/12s.

Sent from my iPhone

On May 6, 2015, at 6:00 PM, Colton Conor colton.co...@gmail.com wrote:

Taking full BGP routes from 4+ carriers on 10G connections. Why is ALU
never mentioned, but Juniper MX and Cisco are all day long?

The new 7750 SR-a4 looks like a Juniper MX80 or MX104 killer.

On Wed, May 6, 2015 at 4:58 PM, Dan Snyder sliple...@gmail.com wrote:


We have been using them for almost 8 years now and have been pretty
happy. What are you looking to use them for?

Sent from my iPhone


On May 6, 2015, at 5:48 PM, Colton Conor colton.co...@gmail.com

wrote:


I was wondering if anyone was using a  Alcatel-Lucent 7750 Service

Router

(SR) in their network? How does this platform compare the the Cisco

ASR,

Brocade MLXe, and Juniper MX line?

Re: Google served from non-google IPs?

[Stephen Fulton]

Local Google caches at QIX?

-- Stephen

On 2015-03-12 3:58 PM, Jason Lixfeld wrote:

So today, I saw this:

BlackBox:~ jlixfeld$ host google.ca 8.8.8.8
Using domain server:
Name: 8.8.8.8
Address: 8.8.8.8#53
Aliases:

google.ca has address 206.126.112.166
google.ca has address 206.126.112.177
google.ca has address 206.126.112.172
google.ca has address 206.126.112.187
google.ca has address 206.126.112.151
google.ca has address 206.126.112.158
google.ca has address 206.126.112.157
google.ca has address 206.126.112.173
google.ca has address 206.126.112.181
google.ca has address 206.126.112.155
google.ca has address 206.126.112.147
google.ca has address 206.126.112.185
google.ca has address 206.126.112.143
google.ca has address 206.126.112.170
google.ca has address 206.126.112.162
google.ca has IPv6 address 2607:f8b0:4006:808::100f
google.ca mail is handled by 50 alt4.aspmx.l.google.com.
google.ca mail is handled by 30 alt2.aspmx.l.google.com.
google.ca mail is handled by 20 alt1.aspmx.l.google.com.
google.ca mail is handled by 10 aspmx.l.google.com.
google.ca mail is handled by 40 alt3.aspmx.l.google.com.
BlackBox:~ jlixfeld$

That is not Google IPv4 address space, and those IPv4 IPs are not being 
announced by 15169.

Am I dumb in thinking that this is weird or is this sort of thing commonplace?

Re: DDOS solution recommendation

[Stephen Fulton]

peeringdb.com is usually quite accurate.

-- Stephen

On 2015-01-11 4:11 PM, Pavel Odintsov wrote:

Hello!

But abuse@ contacts is very-very-very hard way to contacting with ASN
administrator in case of attack. Big amount of requests to #Nanog
about please contact ASN  noc with me offlist confirms this.

I'm got multiple attacks from well known ISP and I spend about 10-20
hours to contacting they in average. It's unacceptable time

We need FAST and RELIABLE way to contacting with noc of attackers
network for effective attack mitigation.

We need something like RTBH for knocking network admin of remote network.

Maybe somebody can create social network for noc's with API ?:)





On Sun, Jan 11, 2015 at 11:55 PM, Owen DeLong o...@delong.com wrote:



On Jan 11, 2015, at 05:07 , Mike Hammett na...@ics-il.net wrote:

Why does it seem like everyone is trying to solve this the wrong way?


Because it’s what we CAN do.



Do other networks' abuse departments just not give a shit? Blackhole all of the 
zombie attackers and notify their abuse departments. Sure, most of the owners 
of the PCs being used in these scenarios have no idea they're being used to 
attack people, but I'd think that if their network's abuse department was 
notified, either they'd contact the customer about it issue or at least have on 
file that they were notified. When the unknowing end-user reached out to 
support over larger and larger parts of the Internet not working, they'd be 
told to clean up their system.

The way to stop this stuff is for those millions of end users to clean up their 
infected PCs.


Agreed… However, let’s look at it from an economics perspective…

The average residential service provider doesn’t have the resources and doesn’t 
charge enough to build the resources to deal with this onslaught. It won’t be 
the service provider that the attacker blames for the initial few 
disconnections, it will be the websites in question.

So, let’s say XYZ.COM http://xyz.com/ is a really popular site with lots of 
end-users. Some of those end-users are also unknowingly attacking XYZ.COM 
http://xyz.com/.

XYZ.COM http://xyz.com/ black holes those customers (along with all the other 
zombies attacking them).

XYZ.COM http://xyz.com/ gets angry calls from those customers and has no 
ability to contact the rest.
The rest don’t call their ISP or XYZ.COM http://xyz.com/ because they don’t know 
that they are unsuccessfully trying to reach XYZ.COM http://xyz.com/, so they don’t 
see the problem.

Depending on hold times, etc., XYZ.COM http://xyz.com/ loses some fraction of 
their customers (who instead of cleaning up their system, move into the second group 
who don’t care about the problem any more.) The rest may clean up their systems.

So, at the cost of some fraction of their customer base and a substantial burden on 
their call center, XYZ.COM http://xyz.com/ has managed to clean up a 
relatively small percentage of systems, but accomplished little else.

I’m all for finding a way to do a better job of this. Personally, I’d like to 
see some sort of centralized clearing house where credible reporters of dDOS 
information could send some form of standardized (automated) report. The 
clearing house would then take care of contacting the responsible ISPs in a 
scaleable and useful manner that the ISPs could handle. Because the clearing 
house would be a known credible source and because they are providing the 
information in a way that the ISP can more efficiently utilize the information, 
it MIGHT allow the ISP to take proactive action such as contacting the user and 
addressing the problem, limiting the user’s ability to send dDOS traffic, etc.

However, this would require lots of cooperation and if such a clearing house 
were to evolve, it would probably have to start as a coalition of residential 
ISPs.

Owen

Re: Buying IP Bandwidth Across a Peering Exchange

[Stephen Fulton]

Hi Clayton,

Putting on my TorIX hat, I'll address what you've brought up:

1. We implemented port security because MAC ACL's were not effectively 
blocking certain types of bad traffic, which was a problem with the 
hardware in place at the time.  As you are certainly aware, getting 
vendors to work on esoteric problems faced by a small number of their 
customers can be frustrating.


2. Port security effectively logs rogue MAC's received on the port, 
which was/is not always the case when certain types of bad or unwanted 
traffic are received.  This has proven invaluable for trouble-shooting 
and is very easy to pass along that info to the peer for further 
investigation without having to begin a separate trouble-shooting 
process with all parties online and aligned, and hoping the problem 
reappears.


3. Since we implemented port security, the stability of TorIX has been 
excellent.  No more sudden outages due to peer human error or bad peer 
architecture.  (some of which is mind blowing).


4. If you think the 60 minute lock-down is excessive, bring it up on 
torix-members and begin a discussion, which we're certainly open to when 
it will not adversely affect the integrity of the IX.


5. If Netflix was at TorIX, I guarantee you would see traffic shoot 
through the roof, and that's why we'd welcome NF and others like FB, 
Edgecast etc. joining TorIX.  We are one of the largest IX'es in terms 
of number of peers in the world after all.


Back onto the original topic, a number of peers sell transit over the 
IX.  TorIX does not offer SLA's, but we do not stop peers from 
maximizing their value of the IX.


-- Stephen (volunteer at TorIX)


On 2014-11-30 6:51 PM, Clayton wrote:

We peer at TorIX and Equinix.  I have to say that despite the fact that
Equnix charges us more for our port, we're getting far more value from it
than TorIX.  Around double the traffic, and they don't have silly punative
measures like locking your port if you leak a MAC address other than the
one you registered with them (Equnix filters the MAC, but doesn't apply a
60 minute port shut down penalty if you leak like TorIX does).

Prefix hijack by AS4761 (was Re: BGPMON Alert Questions)

[Stephen Fulton]

I'm seeing the same hijack of prefixes by multiple networks under my 
watch, at 18:40 UTC and 19:06 UTC.


-- Stephen


On 2014-04-02 2:51 PM, Joseph Jenkins wrote:

So I setup BGPMON for my prefixes and got an alert about someone in
Thailand announcing my prefix.  Everything looks fine to me and I've
checked a bunch of different Looking Glasses and everything announcing
correctly.

I am assuming I should be contacting the provider about their
misconfiguration and announcing my prefixes and get them to fix it.  Any
other recommendations?

Is there a way I can verify what they are announcing just to make sure they
are still doing it?

Here is the alert for reference:

Your prefix:  8.37.93.0/24:

Update time:  2014-04-02 18:26 (UTC)

Detected by #peers:   2

Detected prefix:  8.37.93.0/24

Announced by: AS4761 (INDOSAT-INP-AP INDOSAT Internet Network
Provider,ID)

Upstream AS:  AS4651 (THAI-GATEWAY The Communications Authority of
Thailand(CAT),TH)

ASpath:   18356 9931 4651 4761

Re: level3_bx4-montrealak.net consistently dropping 50% of the packets

[Stephen Fulton]

There are reports of problems in Montreal with several other providers 
over the last several days.  These seem to coincide with the Olympics 
live broadcasts, particularly during the hockey broadcasts.


-- Stephen

On 2014-02-20 10:08 AM, Nick Cameo wrote:

Hello Everyone,

According to mtr command we are consistently seeing
level3_bx4-montrealak.net
dropping 30-50% of packets. Our ISP is Bell Canada. Any ideas on how to get
this resolved are greatly appreciated.


HOST: victoriaLoss%   Snt   Last   Avg  Best  Wrst StDev
   1.|-- 192.168.2.10.0%100.5   0.8   0.4   1.6   0.5
   2.|-- lns2-montrealak_lo0_LNS.n  0.0%106.7   7.6   6.7   8.8   0.7
   3.|-- agg1-montrealak_GE0-2-2_1  0.0%106.4   6.3   5.4   7.6   0.6
   4.|-- bx4-montrealak_so-0-0-0.n  0.0%106.0   5.8   4.9   7.0   0.7
   5.|-- level3_bx4-montrealak.net 50.0%106.5   6.7   5.7   7.9   0.8
   6.|-- ae-11-11.car1.Montreal2.L  0.0%10   92.2  91.7  91.0  92.8   0.7
   7.|-- ae-5-5.ebr2.NewYork1.Leve  0.0%10   90.9  92.0  90.9  92.7   0.6


Kind Regards,

Nick.

Re: iOS 7 update traffic

[Stephen Fulton]

+1

If you do not/cannot have an Akamai cache, connect to an IX that does, 
and make sure you've got the capacity.  My own rule of thumb is have 2x 
the capacity of your average *peak* traffic on an IX.  When big events 
happen, whether it is news, sporting or a major software update, that 
extra capacity will be sorely needed.


At TorIX, most peers traffic jumped by the same percentage that others 
have bandied about on this thread.  One peer jumped almost 100%, but 
they had the right port speed and thus no issues (at least on the Exchange).


Compared to transit in Canada, IX peering is dirt cheap, and pays dividends.

-- Stephen

On 19/09/2013 3:07 PM, Jared Mauch wrote:

The attitude in this email I have encountered elsewhere.  Apple pays for 
bandwidth, customers pay for access. Not sure why their release strategy is so 
highly critiqued. Microsoft and others have their own strategies for 
incremental downloads, caching, etc.. Apple has theirs.

Seems like most consumers want the update and are actively fetching it vs 
having older software live forever and not be updated. Overall I see this as a 
win.

Jared Mauch


On Sep 19, 2013, at 2:11 PM, Warren Bailey 
wbai...@satelliteintelligencegroup.com wrote:

I don't see how operators could tolerate this, honestly. I can't think of a 
single provider who does not oversubscribe their access platform... Which leads 
me to this question :

Why does apple feel it is okay to send every mobile device an update on a 
single day?

Re: iOS 7 update traffic

[Stephen Fulton]

Microsoft Windows 8.1 is due out in October.. don't be so sure :)

-- Stephen

On 19/09/2013 3:11 PM, Warren Bailey wrote:

Patch Tuesday is not 1gb per patch.

On 9/19/13 11:51 AM, valdis.kletni...@vt.edu valdis.kletni...@vt.edu
wrote:


On Thu, 19 Sep 2013 18:11:11 -, Warren Bailey said:


Why does apple feel it is okay to send every mobile device an update on
a single day?


How is Patch Tuesday any different?

Re: common method to count traffic volume on IX

[Stephen Fulton]

 Ding ding ding!  And that's why honest IXPs graph both, to show that
 they have no packet loss on their inter-switch links.

It depends on what is being measured.  At TorIX we'll see deviations 
between in/out on our aggregate graph.  As we combine all peer ports to 
form the aggregate graph, any large deviations are almost always due to 
peers who have reached capacity limits on their port (which is not 
always port speed, btw, always include their transport behind the port). 
 Another common reason is the difference in measurement times across 
all ports.


http://www.torix.ca/stats.php

-- Stephen


On 18/09/2013 6:55 PM, Niels Bakker wrote:

* bickn...@ufp.org (Leo Bicknell) [Wed 18 Sep 2013, 19:23 CEST]:

On Sep 17, 2013, at 3:15 PM, Niels Bakker niels=na...@bakker.net wrote:

I don't know of any IXP that does this.  Industry standard is as you
and others wrote before: the 5-minute counter difference on all
customer-facing ports, publishing both input and output bps and pps.
I guess MRTG is to 'blame' for these values more than anything.


Serious question, at an IXP shouldn't IN = OUT nearly perfectly?


Ding ding ding!  And that's why honest IXPs graph both, to show that
they have no packet loss on their inter-switch links.

(Or, much more likely, measurement errors due to wrong config for the
grapher)


 -- Niels.

E-Bay / Paypal engineer eyeballs required.

[Stephen Fulton]

Apologies to the list for the post, but:

Could an engineer from E-Bay/Paypal contact me off-list, as we're having some 
difficulty reaching your network.


Our ARIN assigned space (66.135.96.0/19) is awfully close to your own, and I 
suspect a typo.  We have no issues reaching the edge of your space via multiple 
carriers.


-- Stephen Fulton