Re: Jon Postel Re: 202210301538.AYC

[Joel Jaeggli]

some minor observations from the vantage point of a former AD inline.

On 11/2/22 17:48, Donald Eastlake wrote:

On Mon, Oct 31, 2022 at 12:03 PM Vasilenko Eduard
 wrote:

It is believed by many that 2 terms should be the maximum for one position of 
any chair (if it is a democracy).

Although this isn't a written guideline, many people believe that the
first 2 years in an Area Director position are sort of a probationary
period and as long as the AD does adequately, they should normally be
continued for a 2nd term, if they want it. Being continued for a 3rd
or later term should only be for superior performance and in the
absence of an apparently stronger alternative. Note the following


In my observed experience, it pretty much falls to a incumbent AD, to 
recruit alternatives, assuming they are doing a tolerable job of 
addressing the needs of their working groups. having done my 2 terms I 
found the role to be more one of middle management then of leadership, 
with the possible exception  of organizing and promoting new work 
organization around BOFs and working group formation.


ADs are highly dependent on WG chairs and senior individual contributors 
when it comes to advancing any particular activity.



-- Having served in one capacity or another on six Nomcoms over the
30 year history of the Nomcom system and I can assure you that there
are always at least 1 or 2 positions for which the Nomcom, after the
normal nomination period, has only zero or one possibilities to choose
between and it is common for NomCom to have to engage in substantial
recruiting (aka "arm twisting") to get more nominees from which to
choose. I just checked the NomCom pages and right now there are three
positions where, for the 2022-2024 term, the current NomCom has only
one person who has been nominated and agreed to run. So it isn't like
they have a vast pool of willing people to choose between.
-- Most former Area Directors say that there is a substantial
learning curve and it takes about a year before you are fully
effective as an Area Director. So, if ADs were limited to 1 term of 2
years, the IESG would only be 50 to 75% effective. With 2 terms of 2
years, it is more like 75 to 88% effective.


Also, serving as an AD is significantly detrimental to one's  own work 
in the IETF, both from a time perspective and respecting any chair, or 
other positions in one's area that you would give up in the process. As 
a volunteer activity there is a significant community service aspect too 
it. Unless your career goals involve a sympathetic employer and a goal 
of joining and staying in internet governance long term ADship has a 
significant impact on your ability to contribute to the IETF. I did my 4 
years, that was enough.




Furthermore, most Areas of the IETF have two co-ADs who tend to
moderate each other and many decisions are made by the IESG, which
consists of all the ADs, which is a further moderating effect.


It is evidently not the case for IETF - people stay in power for decades. It is 
just a fact that is not possible to dispute.
Yes, Nomcom is the mechanism for AD and above. I do not want to sort out how 
exactly it is performed.

Well, the NomCom system is well documented in a number of RFCs.

The most powerful single position in the IETF is the IETF Chair. As
you can see from the attached image only one person has served as IETF
Chair for as long as 8 years but as soon as the nomcom system was
started, they were replaced. After that, only one other person served
as long as 6 years, which was Russ Housley who I think was a
particularly good IETF Chair. All others have been limited to 2 or 4
years (1 or 2 terms). It would take a lot more work to do a similar
analysis for AD positions but I believe you would find that the length
of time in office for ADs was longer in the early days of the IETF and
is now rarely over 6 years.

In an earlier message, you said something about people retaining
positions due to networking with other people. Well, I would say that
is characteristic of all human organizations (unless you go with
strict Sortition). See my RFC 4144 "How to Gain Prominence and
Influence in Standards Organizations".


The IETF as a whole has activities (Working Groups) whose productivity 
on a given topic is largely driven by a small number of  individual 
contributors, these folks are entirely self-selected (authors, editors, 
collaborators, implentors). While there is not doubt quite a bit of 
survivor bias, networking and well as the capacity to be present (in 
person, remote) are necessary and rather expensive parts of advancing 
given pieces of work.






By the way, WG chairs have been put aside from any election mechanisms.

Yes, there are people who have served as co-Chair of an IETF Working
Group for long periods of time and there is currently no specific term
of office for a WG Chair. But these days most IETF WGs have two
co-Chairs, which has a moderating influence. Furthermore, Area

Carrier Options in Bogota

[Joel Jaeggli]





> On Jul 1, 2022, at 6:50 AM, nanoguser99 via NANOG  wrote:
> 
> Nanog,
> 
> I need good connectivity to local eyeball networks there.  I've explored 
> Cogent, Lumen, and a local clled Telxius and results are all over the map.  
> Is there a provider that's 'well peered' with all the locals?  Hoping this 
> formats correctly but here's the results of ping tests on various looking 
> glasses to prefixes of the various locals.

Telxius is the present manifestation of Telefonica.

Internexa 262589 is the local domestic transit provider and offshoot of the 
Colombian national power company and is relatively well connected locally.

> 
> Local CarriersIP Prefix   Telxius Lumen   Cogent
> COLOMBIA TELECOMUNICACIONES S.A. ESP  152.200.0.0/14  22.025 ms   164ms   
> 115 ms
> Telmex Colombia S.A. (Claro)  190.144.0.0/14  14.319 ms   63ms115 ms
> Empresas Públicas de Medellín E.S.P.  201.220.30.0/23 94.264 ms   126 ms  
> 102 ms
> Movistar Colombia 186.116.14.0/24 38.894 ms   193ms   118 ms
> ETB - Colombia186.154.0.0/16  5.340 ms130ms   2.21 ms
> Columbus Networks Colombia138.121.12.0/24 60.212 ms   99ms89.8 ms
> Metrotel Colombia 190.1.128.0/19  20.989 ms   148ms   90.5 ms
> 
> Any advice?
> 
> -Nanoguser99
> 
> Sent with Proton Mail secure email.

Re: FCC vs FAA Story

[Joel Jaeggli]

On 6/6/22 07:55, John R. Levine wrote:
Five years ago everyone knew that C band was coming.  A reasonable 
response would have been for the FAA to work with the FCC to figure 
out which altimeters might be affected (old cruddy ones, we now know), 
and come up with a plan and schedule to replace them. If the telcos 
had to pay some of the costs, they would have grumbled but done it.  
If the replacement schedule weren't done by now, they could live with 
that, too, so long as there were a clear date when it'd be done.


Instead the FAA stuck their fingers in their ears and said no, nothing 
can ever change, we can't hear you.  Are you surprised the telecom 
industry is fed up?


The US phased out leaded gas for everything but planes by 1996, and you 
still can't get an STC stating you can use an alternative fuel for some 
engines 24 years later.



Regards,
John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for 
Dummies",

Please consider the environment before reading this e-mail. https://jl.ly

Re: are underwater routers a thing?

[Joel Jaeggli]

On 3/17/22 18:42, Michael Thomas wrote:
I was reading an article in the Economist about a new fiber route down 
the Red Sea from Israel and wondered if there were any branches off of 
those lines and where the routers were for them. The route kind of 
made it look like it was completely at sea, but it would kind of make 
sense to leave them at sea if you could put a router there.


There's a limited number of possible branches on a cable and as a result 
you just put the routers on the edges rather than in the middle. What 
you do put in the water is something like:


https://en.wikipedia.org/wiki/Submarine_branching_unit

The more the active electronics are at the ends rather than in the open 
ocean the greater the serviceability is and also over the lifetime of 
the cable the easier it is to upgrade it to higher capacity as the data 
bearing capacity of a given wavelength increases. The FLAG cable has had 
for example has has several capacity increases over it's service life 
which closing in on 25 years at this point.


Amplifiers are still necessary for longer spans but a lot of other logic 
is not. for situations where the distances are manageable passive 
unrepeated systems are greatly prefered because it keeps servicing due 
to electronic faults to a minimum and reduces the cost accordingly. see 
the recent tonga cable fault and repair for a passive system.


The mean depth of the worlds oceans is around ~3700 meters below MSL 
which means most service calls involve deploying to the proximate 
location of the fault, fishing around for a while and then carefully 
re-laying  several kilometers of cable on a splice has been made. which 
typically takes weeks.




Mike

Re: Anycast but for egress

[Joel Jaeggli]

On 7/27/21 10:54, Vimal wrote:
> (Unsure if this is the right forum to ask this question, but here goes:)
>
> From what I understand, IP Anycast can be used to steer traffic into a
> server that's close to the client.
>
> I am curious if anyone here has/encountered a setup where they use
> anycast IP on their gateways... to have a predictable egress IP for
> their traffic, regardless of where they are located?

Stateless outbound load-balancing setups exist.

Example you have two  or more nat44 / nat64 / cgnat boxes behind a
common ecmp path with the same destination IP(s).  this is normally so
that you have more boxes that accumulate state rather than being bound
to a single one.

>
> For example, a search engine crawler could in principle have the same
> IP advertised all over the world, but it looks like they don't...  I
> wonder why?

So this is a somewhat different problem...

There's  no assurance that when you initiate a connection that the
return path will return to the same instance of your anycast
announcement  when the server on the other side  replies.

Effectively the initiating party needs a unicast address or you need
some out of band path to get an errant packet back to the correct host.

> -- 
> Vimal
>

Re: 60 ms cross-continent

[Joel Jaeggli]

Sent from my iPhone

> On Jun 20, 2020, at 9:27 AM, William Herrin  wrote:
> 
> Howdy,
> 
> Why is latency between the east and west coasts so bad? Speed of light
> accounts for about 15ms each direction for a 30ms round trip. Where
> does the other 30ms come from and why haven't we gotten rid of it?
> 
> c = 186,282 miles/second

This is c in a vacuum. Light transmission through a medium is slower. In the 
case of an optical fiber about 31% slower.

My lowest latency transit paths Palo Alto to the ashburn area are around 58ms.  
the great circle route for the two dcs involved is a distance 2408 miles which 
gives you a 39.6ms Lower bound.
 
The path isn’t quite a straight as that, but if you  eliminate the 6 routers in 
the path and count up the oeo regens I’m sure you can account most of the extra 
in the form of distance.

> 2742 miles from Seattle to Washington DC mainly driving I-90
> 
> 2742/186282 ~= 0.015 seconds
> 
> Thanks,
> Bill Herrin
> 
> -- 
> William Herrin
> b...@herrin.us
> https://bill.herrin.us/
> 

Re: Network card with relay in case of power failure

[Joel Jaeggli]

> On Jun 17, 2020, at 13:14, Dovid Bender  wrote:
> 
> Hi,
> 
> I am sorry if this is off topic.I was once demoed a network device that had 
> two interfaces. The traffic would go through the device. If there was a power 
> cut or some other malfunction there would be a relay that would physically 
> bridge the two network interfaces so the traffic would flow as if it was just 
> a network cable. Is anyone aware of such a network card or device?

that kind of device is an ethernet bypass tap.  the device is relay driven and 
closes when it loses power bypassing the in-band device.

there are others which require that they remain powered, but use a heatbeat of 
some flavor to detect failures and switch the path accordingly.

copper tap infrastructure has kind of fallen out of favor as ports have gotten 
faster (vs just spanning on a switch or router or passive optical taps) but it 
still exists.

gigamon / niagra and a number of white-box  tap manufactures make device that 
would be referred to as active bypass taps.

> 
> TIA.
> 
> 

Re: Hi-Rise Building Fiber Suggestions

[Joel Jaeggli]

Sent from my iPhone

> On Feb 25, 2020, at 18:34, Norman Jester  wrote:
> 
> I’m in the process of choosing hardware
> for a 30 story building. If anyone has experience with this I’d appreciate 
> any tips.
> 
> There are two fiber pairs running up the building riser. I need to put a POE 
> switch on each floor using this fiber. 

In my experience with retrofitting existing structures, if you have access to 
the riser at each floor as it sounds like you do, you would typically drop in a 
new duct,  blow micro duct through it with a branch for each floor, have an MDF 
 or two In a utility spaces  and them you have the ability to reconfigure  the 
fiber as necessary to meet your present and future needs. 

You didn’t specify if the existing fiber is single or multi-mode however it is 
unlikely that the was enough slack built into two fiber runs to make 30 
additional splices so that approach seems dubious as a premise.

As you correctly surmise daisy chaining 30 switches is not an advisable network 
design practice.

> The idea is to cut the fiber at each floor and insert a switch and daisy 
> chain the switches together using one pair, and using the other pair as the 
> failover side of the ring going back to the source so if one device fails it 
> doesn’t take the whole string down.
> 
> The problem here is how many switches can be strung together and I would not 
> try more than 3 to 5. This is not something I typically do (stacking 
> switches). I have fears of STP and/or RSTP issue stacking past Ethernet 
> switch to switch limits (if they still exist??)
> 
> Is there a device with a similar protocol as the old 3com (now HP IDF) 
> stacking capability via fiber? 
> 
> I’d like to use something inexpensive as its to power ubiquiti wifi on each 
> floor.  Ideally if you know something I don’t about ubiquiti switches that 
> can do this I’d appreciate knowing.
> 
> Norman
> 
> 

Re: 5G roadblock: labor

[joel jaeggli]

On 1/2/20 06:09, Mike Hammett wrote:
> I know there are a couple companies doing it, but compute at the tower
> isn't going to go anywhere. It makes very little sense to put it at the
> tower when you can put it in one location per metro area.

The bottom of a tower is a fantastically expensive piece of real estate
to collocate something in. If you're financing the development of such
realestate it may sound great, but if you're leasing, it is sort of
outlandish, especially if you want .5KW per ru along with it.

If you set your latency budget artificially at 1ms, at .7 C photons
travel around 210km. If you draw a circle around the base of the tower
at 75KM it's quite feasible to achieve that assuming for the sake of
argument that it's necessary.

> 
> 
> -
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com
> 
> Midwest-IX
> http://www.midwest-ix.com
> 
> 
> *From: *"Brandon Butterworth" 
> *To: *jdambro...@gmail.com
> *Cc: *"North American Network Operators Group" 
> *Sent: *Wednesday, January 1, 2020 9:35:15 AM
> *Subject: *Re: 5G roadblock: labor
> 
> On Wed Jan 01, 2020 at 09:29:20AM -0500, jdambro...@gmail.com wrote:
>> Given the deployment of Wi-Fi into so many different applications
>> - your statement that 5G is to "replace" WiFi seems overly ambitious
> 
> We might think that but it is serious. They want to own it all
> and there is a small cabal of operators owning the spectrum so
> little room for new competitors.
> 
> Here's a project we did exploring some of the ambition
> https://www.bbc.co.uk/rd/blog/2019-02-5g-mobile-augmented-reality-bath
> 
> Previously we avoided the old Telco CDNs by sticking to regular
> Internet CDNs and building our own but edge compute (mobile CDN
> but a better name to compete with AWS) is more insidious as you
> may not be able to get the same result from CDNs out on the net.
> 
> Either the content providers or the external CDNs they use will
> have to pay to use the mobile CDN. How they will scale that at all
> those sites will be interesting to see.
> 
>> Perhaps preventing WiFi from further penetration is a better way
>> to look at it?
> 
> If the mobile companies are providing the WiFi routers they can
> control it (see LTE WiFi attempt) and one day replace it with
> 5G or 6G in all the things. If they make a better job of it than
> everyones devices fighting for 5GHz then they may succeed.
> 
> brandon
> 




signature.asc
Description: OpenPGP digital signature

Re: Wikipedia drops support for old Android smartphones; mandates TLSv1.2 to read

[joel jaeggli]

On 12/31/19 08:25, Seth Mattinen wrote:
> On 12/31/19 8:10 AM, joel jaeggli wrote:
>> Argumentation on the basis of a tu quoque fallacy doesn't really add
>> much to the dicussion. Depreciating potentialy dangerous and definitely
>> obsolete protocols does not make you a hypocrite.
> 
> 
> Then how about privilege?
> 
> If someone is living in a less-privileged situation (oppressive regime,
> state controlled ISP, extreme poverty, whatever) there's also a good
> chance that such people may not able to acquire newer/updated technology
> easily, perhaps not even legally at great risk. I will disagree with
> anyone's assertion that people in such conditions deserve to be
> disenfranchised.

You cite a hypothetical situation that may, but does not in my
experience exist, I work with customers who had populations of impacted
devices, so the consequences and timing of these transitions are
directly consequential to our customers.

Most CDNs turned off tls 1.0 by early to mid-2018. The  mobile devices
that still required it at the time and did not have an alternative were
a vanishingly small portion of the population then in use (for example
legacy docomo i-mode handsets), and the ones that cannot support it now
are still smaller,  Lacking support for SNI was a signification consumer
of address consumption in CDNs and that contributes to accessibility
cost and usability issues for websites  attempts at universal tls
deployment as well so we should be clear that there are plenty of people
who were disenfranchised by or burdened with otherwise unnecessary costs
by the need to support tls 1.0.

Most populations have recourse to application alternatives that can and
did extend their useful service life to tls 1.2 (current firefox
supports back to android 4.1 for example, Opera mini /mobile have much
larger market shares in bandwidth constrained environments and superior
performance on low end devices). tls 1.1 is not really far on the heels
of 1.0. hence you see this now.





signature.asc
Description: OpenPGP digital signature

Re: Wikipedia drops support for old Android smartphones; mandates TLSv1.2 to read

[joel jaeggli]

On 12/31/19 07:10, Seth Mattinen wrote:
> On 12/31/19 12:50 AM, Ryan Hamel wrote:
>> Just let the old platforms ride off into the sunset as originally
>> planned like the SSL implementations in older JRE installs, XP, etc.
>> You shouldn't be holding onto the past.
> 
> 
> Because poor people anywhere on earth that might not have access to the
> newer technology don't deserve access to Wikipedia, right? Gotta make
> sure information is only accessible to those with means to keep "lesser"
> people out.

Argumentation on the basis of a tu quoque fallacy doesn't really add
much to the dicussion. Depreciating potentialy dangerous and definitely
obsolete protocols does not make you a hypocrite.

TLS 1.0 is genuinely hard to support at this point. Doing  so limits the
tooling you can use, It limits the CDNs that you can use. It forces you
to use obsolete codes bases.




signature.asc
Description: OpenPGP digital signature

Re: Traffic visibility tools

[Joel Jaeggli]

On 7/24/19 09:16, Kenny Taylor wrote:
>
> Good morning,
>
>  
>
> I hate to pull away from the 44/8 fire (KJ6BSQ here, and former
> AMPRnet user), but I’d like to get some advice from the community on
> traffic visibility tools..
>
>  
>
> We use a pair of appliances called Exinda for traffic shaping and
> visibility.  The current appliances are end-of-support and the
> replacements are hugely expensive after GFI acquired Exinda.  Traffic
> shaping is less of a concern now, as circuit speeds have caught up
> with our users, but visibility is still a big need.  Those boxes do
> two things very well:  1) identification of FQDNs using SSL cert
> inspection on HTTPS traffic and 2) categorization of the traffic (i.e.
> Netflix, Youtube, etc.).  We have Netflow monitoring using PRTG, but
> seeing something like
> ‘ec2-34-214-76-39.us-west-2.compute.amazonaws.com’ in Netflow logs
> isn’t very useful.
>
tls 1.3 encrypted SNI  or QUIC and then DOH will eventually make https
opaque. Whether this is soon or not I guess is an open question but
passive inspection will probably become less useful over time. it seems
likely to cause industry / monitoring product change as well.
>
> We’re looking for something that could sit either inline or hang off a
> SPAN port, handle 5-10 Gbit of traffic, do the SSL cert FQDN
> identification, and preferably group results by site/subnet/category. 
> What would you guys recommend?
>
>  
>
> Thanks,
>
>  
>
> Kenny Taylor
>
> WAN Engineer
>
> Kern Community College District
>
>  
>


pEpkey.asc
Description: application/pgp-keys

Re: netstat -s

[Joel Jaeggli]

On 7/17/19 17:54, Randy Bush wrote:

> do folk use `netstat -s` to help diagnose on routers/switches?

I suspect there's an unstated question here of should metrics reported
by netstat -s  which includes metrics from the kernel should include
metrics derived from from the asic counters.

I do / have occasionally used netstat or the values exposed to it from
the kernel which are generally also exposed via other metrics methods.

I would find it a little odd for ip counters in netstat for example to
include packets that do not hit the  kernel control plane, though I
could imagine someone wanting that.

> randy
>


pEpkey.asc
Description: application/pgp-keys

Re: Colo in Africa

[Joel Jaeggli]

> On Jul 16, 2019, at 07:33, Ken Gilmour  wrote:
> 
> Hi Folks,
> 
> I work for a Security Analytics org and we're looking to build a small POP in 
> Africa. I am pretty clueless about the region so I was wondering if you could 
> help guide me in the right direction for research?
> 
> The challenges:
> Network needs to be able to receive millions of small PPS (as opposed to 
> serving smaller numbers of larger files).
> Can't be cloud (need bare metal servers / colo). We use the full capacity of 
> each server, all the time.
> Must have good connectivity to most of the rest of Africa
> We can initially only have one POP
> This is not like a normal website that we can just host on "any old 
> provider", the requirements are very different.
> 
> Is there a good location where we could either rent bare metal servers 
> (something like Internap - preferred) or colocate servers within Africa that 
> can serve most of the region?
> 
> "Good" is defined as an area with stable connectivity and power, no legal 
> restrictions on things like encryption, and good latency (sub 100ms) to the 
> rest of Africa.

100ms from most of the rest of Africa is going to be a bit dubious. If you draw 
a line horizontally through Senegal the costal stuff north of it can mostly be 
served in under 100ms from Europe.

While cross border terrestrial fiber exists most networks I’ve been exposed to 
have east west and north south connectivity Via submarine connected networks.  
This make it hard to locate one low latency spot in the middle.

NSRC has a project that can provide some background on terrestrial fiber.

https://afterfibre.nsrc.org/

The next best place to my mind for reach east and west is South Africa where 
you can pick up something of a diversity of transit find decent colo and pick 
up a few out of region peers if you locate near jinx or cinx which are both 
multi building connected exchanges.

> Our two closest POPs are in Singapore and The Netherlands, so I'd like 
> something closer to the middle that can serve the rest of Africa. Middle East 
> will be deployed after Africa.
> 
> I hope this is the right place to ask.
> 
> Thanks!
> 
> Ken

Re: QoS for Office365

[Joel Jaeggli]

> On Jul 9, 2019, at 07:19, Mark Tinka  wrote:
> 
> 
> 
> On 9/Jul/19 16:18, Ross Tajvar wrote:
>> I think the difficulty lies in appropriately marking the traffic. Like
>> Joe said, the IPs are always changing.
> 
> Does anyone know if they are reasonably static in an Express Route scenario?

Express route peering  with 12076 gives you more specific routes then you would 
otherwise see from 8075 (a /13 becomes a bunch of 17s etc) . it also gives you 
control over what region / application is exported to you.

My early experience as a customer with it was that there was on RPF check that 
I found to be a problem as a multihomed network.

> 
> Mark.
> 

Re: ICMPv6 "too-big" packets ignored (filtered ?) by Cloudflare farms

[Joel Jaeggli]

Sent from my iPhone

> On Mar 5, 2019, at 01:31, Saku Ytti  wrote:
> 
>> On Tue, Mar 5, 2019 at 12:26 AM Mark Andrews  wrote:
>> 
>> Then Cloudflare should negotiate MSS’s that don’t generate PTB’s if
>> they have installed broken ECMP devices.  The simplest way to do that
> 
> Out of curiosity does that imply you are aware of non-broken ECMP
> devices, which are able to hash on the embedded original packet?

Parsing the icmp payload was something we considered in  rfc7690 but wasn’t one 
the approaches we pursued (we broadcasted the ptb to all hosts on the 
segment(s) behind the load balancers in our original implementation).

It actually seems like it is becoming feasible to do in an Ethernet switch ASIC 
like tofino if that is what you want to burn real estate on. Being worthwhile 
is another matter.


> 
> -- 
>  ++ytti
> 

Re: ICMPv6 "too-big" packets ignored (filtered ?) by Cloudflare farms

[Joel Jaeggli]

Sent from my iPhone

> On Mar 4, 2019, at 22:26, Mark Andrews  wrote:
> 
> 
> 
>> On 5 Mar 2019, at 5:18 pm, Mark Tinka  wrote:
>> 
>> 
>> 
>>> On 5/Mar/19 00:25, Mark Andrews wrote:
>>> 
>>> 
>>> Then Cloudflare should negotiate MSS’s that don’t generate PTB’s if
>>> they have installed broken ECMP devices.  The simplest way to do that
>>> is to set the interface MTUs to 1280 on all the servers.  Why should
>>> the rest of the world have to put up with their inability to purchase
>>> devices that work with RFC compliant data streams.
>> 
>> I've had this issue with cdnjs.cloudflare.com for the longest time at my
>> house. But as some of you may recall, my little unwanted TCP MSS hack
>> for IPv6 last weekend fixed that issue for me.
>> 
>> Not ideal, and I so wish IPv6 would work as designed, but…
> 
> It does work as designed except when crap middleware is added.  ECMP
> should be using the flow label with IPv6.  It has the advantage that
> it works for non-0-offset fragments as well as 0-offset fragments and
> also works for transports other than TCP and UDP.  This isn’t a protocol
> failure.  It is shitty implementations.

Your mobile carrier’s stateless  tcp accelerator should stop sending  acks with 
a zero flow label so we can actually identify them as part of the same flow...

There a lot of headwind in the real world for using the flow label as a hash 
component.

> 
>> Mark.
> 
> -- 
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org
> 
> 

Re: Network Speed Testing and Monitoring Platform

[Joel Jaeggli]

> On Jan 16, 2019, at 08:52, Colton Conor  wrote:
> 
> As an internet service provider with many small business and residential 
> customers, our most common tech support calls are speed related. Customers 
> complaining on slow speeds, slowdowns, etc.
> 
> We have a SNMP and ping monitoring platform today, but that mainly tells us 
> up-time and if data is flowing across the interface. We can of course see the 
> link speed, but customer call in saying the are not getting that speed. 
> 
> We are looking for a way to remotely test customers internet connections 
> besides telling the customer to go to speedtest.net, or worse sending a tech 
> out with a laptop to do the same thing.

So one of the properties of customer experience of internet performance is that 
their first hop is not going to be exposed in testing from the CPE. This is one 
of the enduring motivations of internet speed tests run inside clients.

Setting aside claims about buffer bloat. Radio interfaces can have dramatic 
impact on the first hop latency that propagate to everything upstream.

> 
> What opensource and commercial options are out there? 
> 

Re: NAT on a Trident/Qumran(/or other?) equipped whitebox?

[joel jaeggli]

On 10/16/18 08:55, Brandon Martin wrote:
> On 10/16/18 10:05 AM, James Bensley wrote:
>> NAT/PAT is an N:1 swapping (map) though so a state/translation table
>> is required to correctly "swap" back the return traffic. MPLS for
>> example is 1:1 mapping/action. NAT/PAT state tables tend to fill
>> quickly so to aid with this we also have timers to time out the
>> translations and free up space in the translation table, and also
>> track e.g. TCP RST or TCP FIN to remove entries from the table, so
>> it's not "just swapping".
> 
> I do wonder, though, if these popular switching ASICs are flexible
> enough in terms of their header matching and manipulation capabilities
> to handle packet mangling and forwarding in hardware for a given NAT
> state entry while punting anything that requires a state change to a CPU
> for inspection and state update.
> 
> You'd need a somewhat more powerful CPU than your typical L3 switch
> might have, but it seems like you'd still be able to offload the vast
> majority of the actual packet processing to hardware.

This is a flow cached router fundamentally. They exist. In that design
you burn your fib on flow entries rather than on nexthop routes. They
tend to explode at forwarding rates far lower than a typical ethernet
switch when their ability to accumulate new state is exercised.
riverstone RS circa 1999-2004 and various cisco products (sup 1a cat6k?)
did follow that model.

> State table size (on a typical "switching" ASIC) might be an issue
> before you could actually fill up a 10Gbps+ link with typical SP
> multi-user traffic flows, I guess, and given that a moderate-spec PC can
> keep up with 10Gbps without much issue these days, maybe it's a
> non-starter.




signature.asc
Description: OpenPGP digital signature

Re: Puerto Rico Internet Exchange

[Joel Jaeggli]

> On Sep 13, 2018, at 1:27 PM, Mehmet Akcin  wrote:
> 
> It has been little over a year and we have been working on launching an 
> internet exchange in puerto rico but of course hurricane and other things got 
> in the way of achieving this.
> 
> We now have identified what we believe the right location (most of the isp’s 
> have presence in this location) backbone/ip transit connectivity, local team 
> to provide onsite support.
> 
> Having said that We have been engaged with several content delivery networks, 
> OTTs but general feedback was that Puerto Rico was not on their radar for 
> 2018 hence delayed launch. Now we are talking to same players about 2019 but 
> general answer seemed like people were satisfied enough to serve Puerto Rico 
> from Miami.
> 
> Perhaps we are talking to really big CDNs, OTTs and we should engage 
> differently however the level of interest is very low and I really don’t want 
> to “build and they will come” again ;-)
> 
> Bottom line is, if there was an IXP in Puerto Rico similar to ones in 
> Florida, I am trying to understand who would actually deploy (just speak to 
> your company only please) because most of my assumptions were proven wrong ;-)
> 
> I guess I want to ask two questions, given its location in caribbean, does 
> Puerto Rico need an internet exchange point? Would you join it?(it will be a 
> membership based IXP where members share cost)

Looking at it in my mind,  the decision point is really about how much traffic 
can be served by being there. It took a long time to recover to pre-hurricane 
levels. I would hope in the longer term that it’s a growth story and makes that 
more compelling, actually having a destination to put equipment in  and reach 
peers helps of course.

Having any anycast service, to me it looks like Puerto Rico has significant 
connectivity landing places other than Miami. Most likely due to America Movil 
MAC and PCCS or other landings in the US/BVI. We we see Puerto Rican networks 
reach us in Atlanta, DC area and even New York.


> 
> Mehmet
> 
> On Sat, Aug 12, 2017 at 4:27 AM Mehmet Akcin  > wrote:
> Hey there!
> 
> ... ok this time I am not going to call it PRIX ;) well name doesn't matter 
> really. Nearly 13 years ago I have attempted to start Puerto rico Internet 
> exchange in San Juan. I have lived there over 5 years and i just wanted to 
> really watch videos faster. The project somewhat died when i moved to LA but 
> now there are few interested party to start an internet exchange in Puerto 
> rico. The jsland historically had one of the slowest broadband/internet 
> services which seemed to have improved in recent years however as of 2017 
> there still is not an IX in Puerto rico.
> 
> We , 3-4 internet engineers (on island and remote) , want to look into 
> relaunch of this IX and hopefully find a way to keep local traffic exchanged 
> at high speeds and low cost. We need expertise, and people who want to help 
> any way they can.
> 
> We are trying to make this IX a not-for-profit one and we are looking at 
> opeeating models to adapt which has worked incredibly well like Seattle IX.
> 
> We are hoping the relaunch to happen sometime in 2018. Thanks in advance hope 
> to share more info and traffic data sometime , soon. Watch this space!
> 
> Mehmet
> --
> Mehmet
> +1-424-298-1903



signature.asc
Description: Message signed with OpenPGP

Re: tcp md5 bgp attacks?

[joel jaeggli]

On 8/14/18 7:27 PM, Randy Bush wrote:
>
> < rathole >
> i am not much worried about a mesh which floods unicast.  can you even
> buy devices which support that any more?  a while back, i had to really
> dig in the closet to find one at 100mbps so i could shark mid-stream.
I'm not actually worried about it because it is rare, and not a feature,
that said, unicast flooding is in fact something we detect on exchanges
with a fair amount of frequency e.g. 2-3 a week across the exchanges
were we are present. That traffic gets discarded on our ingress but you
can count dport 179  packets in there that aren't yours. I certainly
wouldn't build a business model around gaining insight from that
information leakage (and the bulk of the traffic is whatever the
neighbor is exchanging, with someone else, from looking at mac's that
sort of thing tends to be one sided unless for example it's a whole switch).
>> I have thousands of establish connections that last a very long time
>> at public exchange points, so the threat of tcp rsts to sessions is
>> clearly not being realized.

Re: tcp md5 bgp attacks?

[joel jaeggli]

On 8/14/18 2:38 PM, Randy Bush wrote:
> so we started to wonder if, since we started protecting our bgp
> sessions with md5 (in the 1990s), are there still folk trying to
> attack?
To recap for the purpose of my own edification and because hopefully
someone will relieve me of my assumptions.

The purpose of  of rfc 2385 tcp md5 digests is to keep in-window, tcp
segments that are spoofed from being ingested into the tcp stack. At the
time of it's writing (1998) some popular network operating systems did
not check  that the sequence number was in fact inside the window (so
that any tcp packet matching the 4 tupple would be ingested whether it
was in-window or not. Variously this improvement was supplemented with
the checking the TTL (https://tools.ietf.org/html/draft-gill-btsh-02),
checking whether the packet is actually in window, by ACLs that would
limit the impacts of  spoofing from off path attackers (you can't target
my multihop infracture sessions from outside my network for example),
and by filters that would limit the sort of thing you could inject into
bgp (rendering prefix hijacking moot) ).  I see broad evidence that MD5
values are extensively shared between sessions and effectively never
rekeyed (including cases where I've changed employers and the same asn
is using the same values for new peers). given the existance of
effective mitigations for the ibgp case, I've need seen a reason  to
employ it internally or to explore support for rfc 4808 mechnisms since
key rolling is effectively an external coordination problem.

Due to window checking and the ttl hack, the best vantage point for
launching an attack against a single hop ebgp sessions is as an on path
attacker (such that you would be able to identify source port and
window), layer-2 exchanges which flood unicast traffic (a hub I guess or
any public exchange with broken mac learning) would seem particularly
vulnerable since there are many on path neighbors. That is no longer a
normal topology. :/
> we were unable to find bgp mib counters.  there are igp interface
> counters, but that was not our immediate interest.  we did find
> that md5 failures are logged.
I can't quite get there either.

md5 failures I see quite a lot of, as peers that formerly have it
configured fail either temporarily or over longer timescales. md5
failures for unestablished connections aren't very interesting in this
case.

I have thousands of establish connections that last a very long time at
public exchange points, so the threat of tcp rsts to sessions is clearly
not being realized.
>
> looking at my logs for a few years, i find essentially nothing;
> two 'attackers,' one my own ibgp peer, and one that noted evildoer
> rob thomas, bgprs01.ord08.cymru.com.
>
> we would be interested in data from others.
>
> note that we are neither contemplating nor suggesting removing md5
> from [y]our bgp sessions.
>
> randy
>

Re: California fires: smart speakers and emergency alerts

[joel jaeggli]

On Thu, Jul 26, 2018 at 09:51:04AM -0700, Aaron C. de Bruyn via NANOG
wrote:
>
>> Capitalist solution: Build yet another IoT device that just does emergency
>> alerting.
>>
>> Someone with free time should start a kickstarter or something.  I'd
>> totally chip in.
>>
>> -A
It would be helpful if it worked when your celltower was down...

http://www.nws.noaa.gov/nwr/info/nwrsame.html

Re: Proving Gig Speed

[joel jaeggli]

On 7/19/18 1:30 AM, Mark Tinka wrote:
>
> On 18/Jul/18 23:56, Keith Stokes wrote:
>
>> At least in the US, Jane also doesn’t really have a choice of her
>> electricity provider, so she’s not getting bombarded with advertising
>> from vendors selling “Faster WiFi” than the next guy. I don’t get to
>> choose my method of power generation and therefore cost per kWh. I’d
>> love to buy $.04 from the Pacific NW when I’m in the Southern US. 
> And that's why I suspect that 10Gbps to the home will become a reality
> not out of necessity, but out of a race on who can out-market the other.
>
> The problem for us as operators - which is what I was trying to explain
> - was that even though the home will likely not saturate that 10Gbps
> link, never mind even use 1% of it in any sustained fashion, we shall be
> left the burden of proving the "I want to see my 10Gbps that I bought,
> or I'm moving to your competitor" case over and over again.
>
> When are we going to stop feeding the monster we've created (or more
> accurately, that has been created for us)?
There is a point beyond which the network ceases to be a serious
imposition on what you are trying to do.

When it gets there, it fades into the background as a utility function.

The fact that multiple streaming audio / video applications in a
household doesn't have to routinely cheese people off point to the
threshold having been reached for the those applications at least in
fixed networks. For others it will it still be a while. When that 5GB
software update or a new purchased 25GB game takes 20 minutes to 
deliver that's a delay between intent and action that the user or
service operator might seek to minimize. Likewise, Latency or Jitter
associated with network resource contention impacts real-time
applications. When the network is sufficiently scaled / well behaved
that these applications can coexist without imposition that stops being
a point of contention.
> Mark.
>

Re: Time to add 2002::/16 to bogon filters?

[joel jaeggli]

On 6/18/18 6:18 PM, Jared Mauch wrote:
> I don’t believe most providers are intending to offer 6to4 as a global 
> service.  Even the large providers (eg: Comcast) seem to have disabled it ~4+ 
> years ago.  While I know there’s people on the internet that like to hang on 
> to legacy things, this is one that should end.  The networks and devices 
> today no longer require this sort of transition technology, and the networks 
> where it’s left won’t want it as it will be used for various bad things(tm).
At some point it transitions from being a legacy transition tool which
you really shouldn't be using to being an attractive nuisance, or worse
genuinely dangerous either for the sender or the receiver. personally I
think we've crossed that point and we have a responsibility to insure
proper burial.
> - Jared
>

Re: Time to add 2002::/16 to bogon filters?

[joel jaeggli]

I personally would love to see social pressure applied removing this
from the internet.

certain prominent google search results. e.g.
https://getipv6.info/display/IPv6/Linux+or+BSD+6to4+Relays probably also
could use some curation given the appropriateness of reling on a anycast
translator for your transition at this point.

On 6/18/18 2:08 PM, Job Snijders wrote:
> Dear all,
>
> TL;DR: Perhaps it is time to add 2002::/16 to our EBGP bogon filters?
>
> It is kind of strange that in the default-free zone (where we don’t
> announce defaults to each other) - we will propagate what is effectively an
> IPv4 default-route, in the IPv6 DFZ.
>
> IETF has politely abandoned the prefix:
> https://tools.ietf.org/html/rfc7526
>
> Wes George highlighted operational problems from accepting 2002::/16 on the
> data-plane slide 6:
> http://iepg.org/2018-03-18-ietf101/wes.pdf
>
> Is there still really any legit reason left to accept, or propagate,
> 2002::/16 on EBGP sessions in the DFZ?
>
> Kind regards,
>
> Job
>

Re: Curiosity about AS3356 L3/CenturyLink network resiliency (in general)

[joel jaeggli]

On 5/17/18 6:24 AM, Mike Hammett wrote:
> I often question why\how people build networks the way they do. There's some 
> industry hard-on with having a few ginormous routers instead of many smaller 
> ones. I've learned that when building Internet Exchanges, the number of 
> networks that don't have BGP edge routers in major markets where they have a 
> presence is quite a bit larger than one would expect. I heard a podcast once 
> (I forget if it was Packet Pushers or Network Collective) postulating that 
> the reason why everything runs back to a few big ass routers is that someone 
> decided to spend a crap-load of money on big ass routers for bragging rights, 
> so now they have to run everything they can through them to A) "prove" their 
> purchase wasn't foolish and B) because they now can't afford to buy anything 
> else. 
There  seems to be a bit of overstatement with respect to how large
these are...

alcatel/nokia 7750 (L3's newer PE platform) is large but not outlandish
and they've been deployed for a couple years. it's relatively similar in
capacity  or a to to the devices that many of us interconnect with them
using.  Most of their customers probably though not always need less fib
then they need on a PE router.

There is a longer time-scale overhang from the choice to design of MPLS
core networks 15-20 years ago where PE routers have more to do fib wise
then do cores (which may well be larger and simpler, since most of what
they do is label switching), that drives the selection of what hardware
goes in the edge in ways than an IP only carrier might make different
choices (e.g. this big fib/queue/buffer router might have been a large
l3 switch).
> There's no reason why Tampa doesn't have a direct L3 adjacency to Miami, 
> Atlanta, Houston, and Charlotte over diverse infrastructure to all four. 
> Obviously there's room to add\drop from that list, but it gets the point 
> across. 
the number of paths available into and out a market seems somewhat
orthogonal to the number of routers.
>
>
> - 
> Mike Hammett 
> Intelligent Computing Solutions 
> http://www.ics-il.com 
>
> Midwest-IX 
> http://www.midwest-ix.com 
>
> - Original Message -
>
> From: "David Hubbard"  
> To: nanog@nanog.org 
> Sent: Wednesday, May 16, 2018 11:59:42 AM 
> Subject: Curiosity about AS3356 L3/CenturyLink network resiliency (in 
> general) 
>
> I’m curious if anyone who’s used 3356 for transit has found shortcomings in 
> how their peering and redundancy is configured, or what a normal expectation 
> to have is. The Tampa Bay market has been completely down for 3356 IP 
> services twice so far this year, each for what I’d consider an unacceptable 
> period of time (many hours). I’m learning that the entire market is served by 
> just two fiber routes, through cities hundreds of miles away in either 
> direction. So, basically two fiber cuts, potentially 1000+ miles apart, takes 
> the entire region down. The most recent occurrence was a week or so ago when 
> a Miami-area cut and an Orange, Texas cut (1287 driving miles apart) took IP 
> services down for hours. It did not take point to point circuits to out of 
> market locations down, so that suggests they even have the ability to be more 
> redundant and simply choose not to. 
>
> I feel like it’s not unreasonable to expect more redundancy, or a much 
> smaller attack surface given a disgruntled lineman who knows the routes could 
> take an entire region down with a planned cut four states apart. Maybe other 
> regions are better designed? Or are my expectations unreasonable? I carry 
> three peers in that market, so it hasn’t been outage-causing, but I use 3356 
> in other markets too, and have plans for more, but it makes me wonder if I 
> just haven't had the pleasure of similar outages elsewhere yet and I should 
> factor that expectation into the design. It creates a problem for me in one 
> location where I can only get them and Cogent, since Cogent can't be relied 
> on for IPv6 service, which I need. 
>
> Thanks 
>
>
>
>

Re: Hulu Peering

[joel jaeggli]

On 4/23/18 11:14 AM, craig washington wrote:
> Hey all,
>
>
> Just wondering if anyone peers with Hulu at any public exchange.
>
> I don't see anything on them in the peeringdb or anything that stands out 
> from a google search besides it looks like they may be doing something with 
> Equinix.
Hulu's streaming media bits come from a few CDNs.

My current cartoon network bits are coming from verizon digital media
services.
>
> Thanks
>
>
>

Re: Are any of you starting to get AI robocalls?

[joel jaeggli]

On 4/3/18 3:32 PM, William Herrin wrote:
> Howdy.
>
> Have any of you started to get AI robocalls? I've had a couple of
> calls recently where I get the connect silence of a predictive dialer
> followed by a woman speaking with call center background noise. She
> gives her name and asks how I'm doing. The first time it happened it
> seemed off for reasons I can't quite articulate, so I asked: "Are you
> a robot or a person?" She responded "yes" and then launched in to a
> sales pitch. The next time I asked, "where can I direct your call?"
> She responded "that's good" and launched in to her pitch.
They're more in the domain of artificially stupid but yes.

https://www.theverge.com/2018/1/1/16837814/robocall-spam-phone-call-increase-2017-ftc-report

The anti spoofing/spam app I have that screens calls to several DIDs I
have pointed at one phone reports a dozen or so calls per day.

I would generally assume that the current rate will hasten the demise of
the remaining pots services.
> Regards,
> Bill Herrin
>
>

Re: Yet another Quadruple DNS?

[joel jaeggli]

On 3/29/18 10:59 AM, Stephen Satchell wrote:
> In regards to: spoofing DNS to 8.8.8.8 et al
>
> On 03/29/2018 09:26 AM, Baldur Norddahl wrote:
>> Running your own resolver will not work.
>
> Why won't it work?  I run a Linux box with BIND 9 set up as a
> recursive resolver.  Are you saying that the rogues will also capture
> requests to the root DNS servers, as described in the hints file?
All destination port 53 udp packets.

Re: BCP 38 addendum

[joel jaeggli]

On 3/1/18 10:57 AM, Todd Crane wrote:
> Question:
> Since we cannot count on everyone to follow BCP 38 or investigate their 
> abuse@, I was thinking about the feasibility of using filtering to prevent 
> spoofing from peers’ networks.
>
> With the exception of a few edge cases, would it be possible to filter 
> inbound traffic allowing only packets with source addresses matching the 
> peer’s BGP announcement?  Theoretically it should be a two way street to any 
> address I can receive from, thus if I can’t send to it, I shouldn't be 
> receiving from it. I realize this is not currently a feature of any router 
> (to my knowledge), but could it be implemented into some NOSs fairly easily 
> and jerry-rigged into others for the time being.
you can build ACLs from IRR objects  just like you can build prefix
lists. for customers this is just as feasible as controlling what routes
you accept from them.

unlike URPF strict  this will not cause an outage every time a prefix is
withdrawn but traffic continues to flow (which is a normal and healthy
part of doing maintenance).

on the other hand it means your prefix lists will have to be rather up
to date and your peers will likely have to be very up to date with their
customers. since failures for inclusion will cause black holes.

you can't do this on on and MLPE exchange where you export routes unless
you want to cause an outage everytime a new peer is added.

there is also the problem of the number of cam slots these IP acls chew up.

bgpq3 -P AS-FOO
> This would allow us to peer with OVH et al, and not worry as much. 
> Furthermore, whereas BCP 38 is reliant upon everybody, this could 
> significantly reduce amplification attacks with even just a handful of 
> adopters.
The source addresses of attack traffic associated with for example
memcached (and in fact virtually all reflection attacks) are not spoofed.
>
> —Todd
>
>> On Feb 28, 2018, at 6:52 PM, Job Snijders  wrote:
>>
>> On Tue, Feb 27, 2018 at 09:52:54PM +, Chip Marshall wrote:
>>> On 2018-02-27, Ca By  sent:
 Please do take a look at the cloudflare blog specifically as they
 name and shame OVH and Digital Ocean for being the primary sources
 of mega crap traffic

 https://blog.cloudflare.com/memcrashed-major-amplification-attacks-from-port-11211/

 Also, policer all UDP all the time... UDP is unsafe at any speed.
>>> Hi, DigitalOcean here. We've taken steps to mitigate this attack on
>>> our network.
>> NTT too has deployed rate limiters on all external facing interfaces on
>> the GIN backbone - for UDP/11211 traffic - to dampen the negative impact
>> of open memcached instances on peers and customers.
>>
>> The toxic combination of 'one spoofed packet can yield multiple reponse
>> packets' and 'one small packet can yield a very big response' makes the
>> memcached UDP protocol a fine example of double trouble with potential
>> for severe operational impact.
>>
>> Kind regards,
>>
>> Job




signature.asc
Description: OpenPGP digital signature

Re: MTU to CDN's

[joel jaeggli]

On 1/8/18 2:55 PM, Dovid Bender wrote:

> Hi,
>
> N00b here trying to understand why certain CDN's such as Cloudfare have
> issues where my MTU is low. For instance if I am using pptp and the MTU is
> at 1300 it wont work. If I increase to 1478 it may or may not work.
PMTUD has a lot of trouble working reliability when the destination of
the PTB  is a stateless load-balancer.

If your tunnel or host clamps the mss  to the appropriate value it can
support. it is highly likely that connection attempts to the same
destination will work fine.
> TIA.
>

Re: Any experience with FS hardware out there?

[joel jaeggli]

On 1/5/18 10:50 AM, Bryan Holloway wrote:
Fiberstore is rolling out some CRAZY cheap 100Gbps switches, and I'm 
curious if anyone in the community has any thoughts or real-life world 
experience with them.


E.g.: https://www.fs.com/products/69340.html

For the price point, it's almost in the "too good to be true" category.
The COGS on a single ASIC tomahawk switch was is in $5000-7000 range. so 
it's consistent with a low value add reseller of merchant silicon. that 
silicon is getting older (tomahawk 3 was announced in anticipation of 
2018) so we can presume they are getting cheaper. I generally have a 
favorable experience of FS but then I buy optics and cables, not 
switches so your mileage may vary.


Naturally it claims to support an impressive range of features 
including BGP, IS-IS, OSPF, MPLS, VRFs, blah blah blah.
The software stack is Broadcom ICOS. if you're not familiar with that I 
start looking at that. if it meets you needs that's cool. if not you 
might be looking at cumulus or onos. That said Broadcom does enough to 
get their customers (whitebox odms) out the door, not necessarily the 
customers of those odms so your recourse to a developer is kind of 
limited which you get a from a vendor more involved in the software 
stack. A lot of those choices here depend on how responsible you want to 
be for what's running inside the box.
There was an earlier discussion about packet buffer issues, but, 
assuming for a second that it's not an issue, 
It can be avoided, but for people used to running all 10Gb/s cut-through 
trident 2s kind of hot, some of consequences are kind of impressive. 4 
much smaller buffers and the virtual assurance that you'll be doing rate 
conversion eats into the forwarding budget.
can anyone say they've used these and/or the L2/L3 features that they 
purportedly support?


Thanks!
    - bryan

Re: 40G and 100G optics options

[joel jaeggli]

On 12/19/17 10:24, Sabri Berisha wrote:
> - On Dec 18, 2017, at 9:49 AM, Fredrik Korsbäck hu...@nordu.net wrote:
>
>> This is the "failure" of us (the business) choosing QSFP as the de-factor
>> formfactor for 100G, there is not power in
>> that cage to make 10km+ optics in an easy way. If we would have pushed for 
>> CFP4
>> as the "last" formfactor in 100G land we
>> would be much better off.
> How about OSFP? The OSFP MSA has a large number of backers, including 
> Juniper, Arista, Finisar and Google. 
>
> It's the vendors that chose to go for QSFP due to the density options in a 
> single RU chassis.
osfp is potentially 540W in the front panel of a 1ru switch which poses
it's own engineering challenges.
>
> Thanks,
>
> Sabri
>




signature.asc
Description: OpenPGP digital signature

Re: Multi lane optics

[joel jaeggli]

On 12/19/17 08:45, Tyler Conrad wrote:
> This blog has a pretty good runthrough -
> http://fmad.io/blog-100g-ethernet.html
> 
> Scroll down to "100G PROTOCOLS".
> 
> On Tue, Dec 19, 2017 at 8:38 AM, Baldur Norddahl 
> wrote:
> 
>> Hello,
>>
>> Some optics are implemented with multiple lasers such as QSFP+ with 4x 10G
>> = 40G or QSFP28 with 4x 25G = 100G. How is the ethernet traffic load
>> balanced between those lanes? Is it bit by bit or more like LACP (packet by
>> packet)?
>>
>> I need to make sure my solution will handle 10G streams correctly. We have
>> a problem with N x 10G and LACP because our L2VPN MPLS endpoints are
>> lacking the flow label support. If I sell a 10G circuit to a customer and
>> uses a L2VPN to transport his port, everything may go on the same sub
>> channel. LACP will not load balance correctly, because it only sees the
>> outer MAC address for hashing, which is the same for all packets.
>>
>> Now we are worried that multi lane optics might have the exact same
>> problem.

100G frames are striped across the 4 x 25G lanes either with or without
fec. That operates as one link from the vantage point of the ethernet frame.

The fec (reed solomon coding generally) offers protection against bit
errors at the expense of some latency.

>> Regards,
>>
>> Baldur
>>
>>
> 

Re: 40G and 100G optics options

[joel jaeggli]

On 12/18/17 09:01, Baldur Norddahl wrote:
> Hi
>
> What options are available for 40G QSFP+ and 100G QSFP28 for 10+ km
> links?
>
> I see a lot of switches offered with QSFP+ and QSFP28. But I do not
> seem to find the necessary optics to build the links I want.
>
> For example, take a look at the options available at Fiberstore:
>
> https://www.fs.com/c/generic-40g-qsfp-891
>
> Generic Compatible 40GBASE-LR4 and OTU3 QSFP+ 1310nm 10km LC
> Transceiver for SMF
> $340
>
> Generic Compatible 40GBASE-ER4 and OTU3 QSFP+ 1310nm 40km LC
> Transceiver for SMF
> $1500
>
> https://www.fs.com/c/generic-qsfp28-100g-transceivers-2858
>
> Generic Compatible QSFP28 100GBASE-LR4 1310nm 10km Transceiver
> $1999
>
> Generic Compatible QSFP28 100GBASE-ER4 1310nm 40km Transceiver
> $7000
>
> That is it. Four modules and the 40km are prohibitive expensive. The
> situation at other vendors appears to be similar.
>
> I need stronger modules that can do more than 10 km without being
> extremely expensive. Or DWDM modules in the 1550 nm band so I can use
> external amplifiers. Am I looking in the wrong place? Is this expected
> to be available in the near future?
qsfp28 is heavily constrained by power budget. The inability to put a
serdes in the package does also very much constrain the form factor
since it's 4x25 wavelengths.

cfp2-aco is the approach that stops paying for the DSP with every optic
(DCO does that) gets you long haul single wave, DWDM and tunables, but
it's  a bit of an incovenient form-factor for fixed configuration 1ru
switches.
>
> Regards,
>
> Baldur
>




signature.asc
Description: OpenPGP digital signature

Re: Companies using public IP space owned by others for internal routing

[joel jaeggli]

On 12/17/17 14:30, Robert Webb wrote:
> Will anyone comment on the practice of large enterprises using non RFC1918 IP 
> space that other entities are assigned by ARIN for internal routing?
>
> Just curious as to how wide spread this might be. I just heard of this 
> happening with a large ISP and never really thought about it until now.
every time I seen a traceroute with 11/8 22/8 26/8 in it I am duly
impressed.
> Robert
>




signature.asc
Description: OpenPGP digital signature

Re: Arista Layer3

[joel jaeggli]

On 11/30/17 13:00, Ken Chase wrote:
>   >Arista DCS-7280SRA-48C6 is a 1ru box.??
>   >
>   >Has a nominally million route fib, Jericho+ 8GB of packet buffer.
>   >control-plane is 8GB of ram andAMD GX-424CC SOC which is 4 core 2.4ghz.
>   >We do direct fib injection with bird rather than the arista bgpd but the
>   >control-plane is capable of managing quite a few bgp sessions.
>   >
>   >the 1/2ru 7280CR2K-30 and 60 are 2m route fib boxes with still heftier
>   >control planes but they're a different class of box being all 100G and
>   >requiring multi-chip/internal fabrics.
>
> Sounds pretty good - hows your power draw on that thing? Why'd you pick Bird
> in this case?
this a standard sr that's moderately busy but not exactly slammed, I'm
be impressed if you could triple that at full tilt.

#show environment power
Power  Input    Output   Output
Supply  Model    Capacity  Current  Current  Power    Status
---  -   
-
1   PWR-500AC-R   500W    0.35A    5.27A    62.8W Ok
2   PWR-500AC-R   500W    0.32A    4.81A    56.4W Ok
Total   --   1000W   --   --   119.1W --

bird had memory footprint going with it as well as some local
modification and we hacked addpath into it a few years ago. filtering
poilcy is something we programmatically generate and interact with via
agents so a traditional style monolithic config isn't that useful.


> /kc
>
>
>   >> /kc
>   >>
>   >> On Thu, Nov 30, 2017 at 10:45:09AM -0800, Tyler Conrad said:
>   >>   >For Enterprise/DC, it works great. For service provider, they're not 
> 100%
>   >>   >yet. The main issue is going to be around VRFs, as there's no 
> interaction
>   >>   >between them (at least in the code version I'm on, that may have 
> changed
>   >>   >recently or be changing soon). They'll work great as a P-Router, but 
> if you
>   >>   >need a PE with route leaking I'd look at another vendor.
>   >>   >
>   >>   >I use a couple pairs of 7280SRs as edge routers/border leaves. 
> Multiple
>   >>   >full table feeds without any issue.
>   >>   >
>   >>   >On Thu, Nov 30, 2017 at 10:36 AM, Romeo Czumbil 
>    >>   >> wrote:
>   >>   >
>   >>   >> So I've been using Arista as layer2 for quite some time, and I'm 
> pretty
>   >>   >> happy with them.
>   >>   >> Kicking the idea around to turn on some Layer3 features but I've 
> been
>   >>   >> hearing some negative feedback.
>   >>   >> The people that I did hear negative feedback don't use Arista 
> themselves.
>   >>   >> (they just heard)
>   >>   >>
>   >>   >> So do we have any Arista L3 people out here that can share some 
> negatives
>   >>   >> or positives?
>   >>   >>
>   >>   >> Use case: Just some MPLS IPv4/IPv6 routing, l2vpn OSPF/BGP
>   >>   >> Maybe 20k routes (no full internet routes)
>   >>   >> 7050 Series
>   >>   >> 7280 Series
>   >>   >>
>   >>   >> -Romeo
>   >>   >>
>   >>
>   >
>   >
>
>
>
>




signature.asc
Description: OpenPGP digital signature

Re: Arista Layer3

[joel jaeggli]

On 11/30/17 11:17, Ken Chase wrote:
> Back to this discussion! :) Arista as a viable full-table PE router. Was 
> hoping
> for better experience reports since last mention.
>
> To make the Q bit more general, are there any PE routers yet that can handle 
> 3-8
> full feeds and use an amp and 1U or so instead of 5 and 4U? Or we're ito 
> whitebox/
> open routers still for that (bird/openbgp?) or microtiks?

Arista DCS-7280SRA-48C6 is a 1ru box. 

Has a nominally million route fib, Jericho+ 8GB of packet buffer.
control-plane is 8GB of ram andAMD GX-424CC SOC which is 4 core 2.4ghz.
We do direct fib injection with bird rather than the arista bgpd but the
control-plane is capable of managing quite a few bgp sessions.

the 1/2ru 7280CR2K-30 and 60 are 2m route fib boxes with still heftier
control planes but they're a different class of box being all 100G and
requiring multi-chip/internal fabrics.
> /kc
>
> On Thu, Nov 30, 2017 at 10:45:09AM -0800, Tyler Conrad said:
>   >For Enterprise/DC, it works great. For service provider, they're not 100%
>   >yet. The main issue is going to be around VRFs, as there's no interaction
>   >between them (at least in the code version I'm on, that may have changed
>   >recently or be changing soon). They'll work great as a P-Router, but if you
>   >need a PE with route leaking I'd look at another vendor.
>   >
>   >I use a couple pairs of 7280SRs as edge routers/border leaves. Multiple
>   >full table feeds without any issue.
>   >
>   >On Thu, Nov 30, 2017 at 10:36 AM, Romeo Czumbil 
>    >> wrote:
>   >
>   >> So I've been using Arista as layer2 for quite some time, and I'm pretty
>   >> happy with them.
>   >> Kicking the idea around to turn on some Layer3 features but I've been
>   >> hearing some negative feedback.
>   >> The people that I did hear negative feedback don't use Arista themselves.
>   >> (they just heard)
>   >>
>   >> So do we have any Arista L3 people out here that can share some negatives
>   >> or positives?
>   >>
>   >> Use case: Just some MPLS IPv4/IPv6 routing, l2vpn OSPF/BGP
>   >> Maybe 20k routes (no full internet routes)
>   >> 7050 Series
>   >> 7280 Series
>   >>
>   >> -Romeo
>   >>
>




signature.asc
Description: OpenPGP digital signature

Re: Commodity routers/switches

[joel jaeggli]

On 11/19/17 07:36, Mike Hammett wrote:
> Which is sad because I believe there are a ton of people using old gear 
> (lacking modern features and security) because the old gear meets price and 
> performance requirements. Although obviously much smaller networks (and thus 
> potential with each one), it's easy to say there are more 1G\10G ISPs than 
> there are 100G ISPs. 
Feature demand drives per port costs that are not very competitively
achieved on 1Gb/s switches. On the plus side the per-port cost of the
10Gb/s and mixed 10/100Gb/s switches with usefully rich features
continues to slide. Some use of L2 devices for port demux for bigger
iron has been done in the past, I imagine it still works for a number of
use cases (cisco sells fabric extenders under a similar rational).
>
>
>
> - 
> Mike Hammett 
> Intelligent Computing Solutions 
> http://www.ics-il.com 
>
> Midwest-IX 
> http://www.midwest-ix.com 
>
> - Original Message -
>
> From: "Fredrik Korsbäck"  
> To: nanog@nanog.org 
> Sent: Sunday, November 19, 2017 1:46:53 AM 
> Subject: Re: Commodity routers/switches 
>
> On 2017-11-19 02:55, mike.l...@gmail.com wrote: 
>> Howdy! 
>>
>> Looking to replace some edge routers for my small ISP. With all the various 
>> SDN platforms available along with various choices of bare-metal hardware 
>> platforms, im thinking i may go this route instead of going with 
>> Cisco/Juniper/Etc. 
>>
>> I only need a handful of 10G uplinks. The SuperMicro SSE-G3648B and the 
>> Penguin Arctica Network switches appear to fit my needs. 
>>
>> I am eyeing Cumulus Linux to run on these, but that isn’t set in stone. 
>>
>> They’ll likely be getting 2 full tables along with some peers. 
>>
>> Has anyone run SuperMicro or Penguin hardware with Cumulus in this type of 
>> scenario? 
>>
>> What were your experiences? How is BGP convergence time on x86 hardware 
>> these days? 
>>
>> Any insight would be appreciated. 
>>
>> Thank You, 
>> Mike 
>>
> Replacing a edge-router with a switch is nothing new, however make sure you 
> actually replace it with the correct one. 
>
> The Supermicro looks like any generic Helix4-switch and is a ToR-switch for 
> the datacenter. Its not very fitting for 
> edge-routing. It does not have buffers at all and would make your sub-speed 
> connections perform like shit, and also it 
> has a tiny LPM table so you wont be able to fit anywhere near a full table in 
> there 
>
> It seems that you want a cost-effective 1G solution given that you linked 
> SSE-G3648B? 
>
> Merchant-switch silicon and edge-routing isn't very competitive on 1G/10G, 
> both because traditional legacy-routers is 
> somewhat cheap for 1G applications and also that 1G is virtually non-existant 
> in datacenter enviroments these days so 
> its hard to leverage the economy-of-scale from there on these swithces. 
>
> Look at Nokias portfolio for 1G/10G routers, they still care in that segment 
> and is in Europe a very popular choice for 
> broadband buildouts, as is Huaweis smaller NetEngines but that might not fly 
> that well in the US. Juniper MX150 might 
> also work depending on how much 1G you need, but you likely need more. 
>
> If you bump it up a notch to 10G/100G or 100G only the market for 
> routing-merchant-silicon looks much better. I guess 
> the most famous platform is the Arista 7280R that was the first 
> Broadcom-based box that accepted 1M routes, had big 
> buffers and didnt cost the equivalent of a bunch of new cars for a 1Tbit of 
> capacity like J/C/N/H would charge you for a 
> equivalent linecard to their edge-portfolios. 
>
> Cisco quickly released NCS550 productline as an answer, Huawei released 
> CE6870-line (but didnt do the LEM/LPM hack that 
> C/A did for full tables to protect NetEngine BU), Juniper pushes QFX10K which 
> is somewhat equal to a Broadcom 
> Jericho-based box. The only Whitebox-vendor i know off that actually has a 
> Jericho (qumran) based box is Agema with the 
> AGC7648S, not sure which stand-alone NOS that actually supports this box 
> fully. 
>
> Now Jericho+ is also out and Jericho2 is around the corner so i guess we will 
> see alot bigger and even more competetive 
> switch-routers based on these chips. But it doesent really help much if you 
> are operating in 1G/10G space. 
>
>
>
>




signature.asc
Description: OpenPGP digital signature

Re: Commodity routers/switches

[joel jaeggli]

On 11/18/17 17:55, mike.l...@gmail.com wrote:
> Howdy!
>
> Looking to replace some edge routers for my small ISP. With all the various 
> SDN platforms available along with various choices of bare-metal hardware 
> platforms, im thinking i may go this route instead of going with 
> Cisco/Juniper/Etc.
>
> I only need a handful of 10G uplinks. The SuperMicro SSE-G3648B and the 
> Penguin Arctica Network switches appear to fit my needs.
>
> I am eyeing Cumulus Linux to run on these, but that isn’t set in stone.
>
> They’ll likely be getting 2 full tables along with some peers.
afaik if these are consistent with other t2/tomahawk/helix switches
they're roughly 200K alpm routes installed or as few as 16K. if you
install selected routes and otherwise default  or this is a peering only
router, that can get you pretty far but it's not a full table by any means.

https://docs.cumulusnetworks.com/display/DOCS/Routing (cumulous details
on route table size and alpm routes)
> Has anyone run SuperMicro or Penguin hardware with Cumulus in this type of 
> scenario?  
>
> What were your experiences? How is BGP convergence time on x86 hardware these 
> days?

control plane on the switches mentioned about is 2GB of ram and a dual
core atom, so it's fine more or less for a datacenter TOR. It's not
particularly powerful. I find out particular tooling doesn't run that
well in 4GB any more so your milage may vary.

the supermicro should bear a striking  resemblance to the dell 3048 that
was splayed open here

http://eoinpk.blogspot.com/2015/08/under-hood-of-dell-s3048-on.html

>
> Any insight would be appreciated.
>
> Thank You,
> Mike
>




signature.asc
Description: OpenPGP digital signature

Re: IPv6 first hop security on a budget?

[joel jaeggli]

On 11/11/17 09:14, Fernando Gont wrote:
> On 05/05/2017 08:27 PM, Joel Whitehouse wrote:
>> What's a good budget option for switching a small lab or office ipv6
>> with RA Guard, DHCP6 snooping, and ICMP6 snooping?
>>
> 
> If you do deploy this, please take a look at the issues discussed in
> RFC7113. Similar stuff is likely to apply to DHCPv6 snooping et al.

experiences vary, if you're looking to experience them first hand, warts
implementation details and all, juniper ex2300c, cisco 3560cx are both
small variants of both providers lower-end layer2/3 switches and are
relatively inexpensive, fairly feature rich platforms.

https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst2960cx_3650cx/software/release/15-2_3_e/configuration/guide/b_1523e_consolidated_2960cx_3560cx_cg/b_consolidated_152ex_2960-X_cg_chapter_011.pdf

https://www.juniper.net/documentation/en_US/junos/topics/reference/configuration-statement/router-advertisement-guard-edit-fo.html

joel

> Thanks!
> 
> Best regards,
> 

Re: What's the point of prepend communities?

[joel jaeggli]

On 10/26/17 10:58, Jason Lixfeld wrote:
> Hi,
>
> Of all the ISPs that I am familiar with that have a BGP community structure 
> usable by their peering partners and/or downstream customers, among other 
> things, they allow the customer to signal the ISP to prepend their own AS to 
> the as-path of a particular prefix announcement.
>
> What functionality does a provider prepend support that is otherwise lost in 
> the absence of such a feature, but all the while, the customer would be able 
> to prepend their own AS to the same prefix announcement anyway?
It has no effect on the provider itself since they prefer customer
routes anyway.

prepending towards a peer of your provider is to encourage them to
select an alternative (shorter) path.

prepending when it works is preferable to no export since the later
doesn't leave that provider available for fallback.
> Is this a relic from before ISPs allowed for local preference adjustment, or 
> is there actually a use case for this?
local pref and med is um local to your upstream.
> Thanks!
>
>




signature.asc
Description: OpenPGP digital signature

Re: California fires: smart speakers and emergency alerts

[joel jaeggli]

On 10/14/17 22:01, valdis.kletni...@vt.edu wrote:
> On Fri, 13 Oct 2017 18:50:51 -0700, Joe Hamelin said:
>> I would think that Amazon knows where my Echo is since it's the same IP
>> that I order (way too much crap) from.
> 
> It knows the usual delivery address.  That's not necessarily the same thing.

It pairs with your phone via bluetooth, also wifi geolocation (e.g.
skyhook) tends to be fairly accurate in moderately high density
residential environments.

Re: pd table vs 6296

[joel jaeggli]

On 9/21/17 18:59, Randy Bush wrote:
> say i want to use pd to a fairly large aggregation.  the router has to
> hold the pd table.  it sees some routers have limited table size, e.g.
> 1k.  so what's a poor boy to do?  the classic ipv4 solution would be
> 6296 .  are folk doing pd scaling?  how?
>
> randy   
>
This is kind of in the neighborhood of stupid pet tricks, but I've done
it to substantially increase the table size in a non-pd scenario, so
there is that.

In an accommodating switch, program a particular prefix length (say 56
or 48 ending on a byte offset) to be installed and matched in the exact
match table. Voila your PD routes are now host routes, and the table for
VLSM routes is free for other purposes.

1. Isn't this robbing peter to pay paul? - yes

2. Is this some kind of strange classful addressing hetrodoxy? - not
really, masks just happen to be expensive.

3. How does this work with variable length prefix delegation? - all PD
prefixes are the same (maximum) size and you install them in the routing
table accordingly> what the end system asks for and what they do with it
when you route it to them are both their business. A decent (not
necessarily high end) L3 switch will let you partition the CAM  in
several variations that are more or less appropriate for this application.





signature.asc
Description: OpenPGP digital signature

Re: 100G QSFP28 DAC cables - experience

[joel jaeggli]

On 9/6/17 00:17, Jiri Prochazka wrote:
> Hi folks,
>
> I'm wondering if anyone have (either positive or negative) experience
> with 100G QSFP28 DAC cables?
I found the ones we tested to be substantially more finicky particularly
at 5 meter then 10gig dacs, adding 4 x 25 sfp28 breakout on the other
end probably isn't a help. We went with AOCs for the equivalent (3, 5
meter) lengths.
> Is there anyone who is using 100G DAC in large scale and would
> recommend it (which means there are no issues compared to SR4 links)?
>
> I'm thinking about cables with lenght up to 1m, not more.
>
> We have had quite bad experience with 10G DAC in the past - but I do
> not want to be slave of the past.
>
>
10g dacs were less reliable then I would have preferred for  3 5 7 meter
distances but they were tolerable especially if you leave the bundles
alone, 25g was sufficiently less so at least in testing that we didn't
try it in the field, being at the limits at 5m was a sufficient
problemthat it ruled out some adjacent rack arrangements. so we're all
optical for 25/100
>
> Thank you for your thoughts!
>
>
>
> Jiri
> 
>




signature.asc
Description: OpenPGP digital signature

Re: 100G - Whitebox

[Joel Jaeggli]

> On Aug 20, 2017, at 08:45, Mike Hammett  wrote:

> 
> Any particular hardware platforms to go towards or avoid? Broadcom Tomahawk 
> seems to be quite popular with varying control planes. LINX went Edgecore, 
> which was on my list given my experience with other Accton brands. Fiberstore 
> has a switch where they actually publish the pricing vs. a bunch of mystery. 

Tomahawk and tomahawk 2 have precious little in the form of packet packet 
buffer (e.g. As little as 4 x 4MB for original tomahawk) which might be a 
problem in a environment where you need to rate convert 100G attached peers to 
a big bundle of 10s).

White box Broadcom dnx / jericho is somewhat less common but does exist.

That 40s are less popular I think is no surprise. They were / are largely 
consigned to datacenter applications.

> Thoughts? 
> 
> 
> 
> 
> - 
> Mike Hammett 
> Intelligent Computing Solutions 
> http://www.ics-il.com 
> 
> Midwest-IX 
> http://www.midwest-ix.com 
> 

Re: Point 2 point IPs between ASes

[joel jaeggli]

On 6/28/17 15:44, William Herrin wrote:
> On Wed, Jun 28, 2017 at 5:09 PM, Thomas Bellman  wrote:
>
>> On 2017-06-28 17:03, William Herrin wrote:
>>
>>> The common recommendations for IPv6 point to point interface numbering
>> are:
>>> /64
>>> /124
>>> /126
>>> /127
>> I thought the only allowed subnet prefix lengths for IPv6 were /64 and
>> /127.  RFC 4291 states:
>>
>>For all unicast addresses, except those that start with the binary
>>value 000, Interface IDs are required to be 64 bits long and to be
>>constructed in Modified EUI-64 format.
>>
>> (and addresses starting with 000 are only used for special things,
>> like the localhost address ::1).  And then RFC 6164 adds /127 to
>> the allowed prefix lengths.
>>
>> I know that many devices allow you to configure any subnet size,
>> but is there any RFC allowing you to use e.g. /124 or /126?
>>
> Hi Thomas,
>
> AFAICT, the IETF has not caught up with operations practice... 
there's a certain amount of style drift, I think the rfc series actually
captures quite a bit of it.
> and
> operations practice itself is still in flux. I do see some discussion of
> longer-than-/64 prefixes in RFC 7421.
I'm not so sure about that, While operators have a variety of
preferences some of which I fix quixotic; which were formed as much as 2
decades ago. it's been about 6 years since we had a standards track
consensus describing the rational for numbering point-to-point links out
of /127s (6164). Which is long enough for text books to have been
updated, silicon implemntations of tcams to use exact match instead of
longest match lookups for your connected  neighbor on a /127 and so on.
likewise mitigations for ND exhaustion attacks exist even if they are
not universally implemented or perfect so some if not all the motivation
for short prefixes has been ameliorated. one can argue that concern in
rfc3627 (subnet router anycast) is entirely irrelevant for point to
point links (the rfc is now historic for that reason) which was the
major motivation for /126 vs /127 14 years ago.

in other news isps that apparently haven't run out of ipv4 addresses are
still assigning me /30 point-to-point links.
> The difference between theory and practice? In theory, there is no
> difference.
>
> IPv6 overall is designed to support CIDR addressing at any netmask. Correct
> implementations may not assume that any given interface will host a /64.
> Some specific protocols (like SLAAC) intentionally do not work if the
> interface ID is not exactly 64 bits. Others become more difficult than
> necessary if the prefix is not on a nibble boundary (the /CIDR number is
> not evenly divisible by 4).
>
> In the mean time, the options that have come out of OPERATIONS activity for
> point to point connections have converged on the above 4.
>
> Regards,
> Bill Herrin
>
>
>




signature.asc
Description: OpenPGP digital signature

Re: Point 2 point IPs between ASes

[joel jaeggli]

On 6/28/17 18:10, Olivier Benghozi wrote:
> Well, /112 is not a stupid option (and is far smarter than /64): it contains 
> the whole last nibble of an IPv6, that is x:x:x:x:x:x:x:1234.
> You always put 1 or 2 at the end, and if needed you are still able to address 
> additional stuff would the point-to-point link become a LAN.
> And you don't throw away billions of addresses like with /64.
If you were subnetting down from /64 for the purposes of preventing ndp
exhaustion or to protect the control plane  on either yours or your
customers platforms then a /112 is pretty useless because 16 bits is
harmful enough.

https://tools.ietf.org/html/rfc6583

https://tools.ietf.org/html/rfc6164
>> On 29 jun 2017 at 02:32, William Herrin  wrote :
>>
>> On Wed, Jun 28, 2017 at 8:01 PM, Aaron Gould  wrote:
>>
>>> I think this is funny... I have (4) 10 gig internet connections and here's
>>> the maskings for my v6 dual stacking...
>>>
>>> /126 - telia
>>> /64  - att
>>> /112 - cogent
>>> /127 - twc/charter/spectrum
>> 112... Could be worse I suppose. They could have picked 113.
>




signature.asc
Description: OpenPGP digital signature

Re: Reliability of Juniper MIC3-3D-1X100GE-CFP and CFP in general

[Joel Jaeggli]

Sent from my iPhone

> On Jun 22, 2017, at 07:38, Eric Dugas  wrote:
> 
> Hello,
> 
> We're planning to phase out some 10G link-aggregations in favor of 100G
> interfaces. We've been looking at buying MIC3-3D-1X100GE-CFP, MPC3E and
> Fiberstore CFPs.
> 
> I've been told that CFPs (in general) weren't that reliable. They were
> kinda "replaced" almost a year and a half or so after its introduction by
> CFP2 and then by CFP4 and so on. Size and power consumption aside, are the
> MIC3-3D-1X100GE-CFP and CFP modules reliable at all? Are they the SFP-TX of
> the 100GBase?

CFP has been around a while, like 8 years at this point. CFP2 and CFP4 are 
significantly smaller have accordingly lower power budgets and do not include 
the DSP on board (the linecard for cfp/2/4/8 differs significantly respecting 
level of integration components and so forth and also port count).

Apart from the resulting low port density per card, which makes them unsuitable 
for a number applications they're mature products at this point.
> 
> Eric
> 

Re: Internet connectivity in Nigeria

[Joel Jaeggli]

Sent from my iPhone

> On Jun 18, 2017, at 12:29, Sina Owolabi  wrote:
> 
> PCCW? I dont think I've heard of them

Pccw would be sat3 glo1 and wacs maybe others.

http://mediafiles.pccwglobal.com/images/downloads/Inf_map.pdf

Their looking glass can give you some idea into their reach with Nigeria with a 
little experimentation.

http://lookingglass.pccwglobal.com/

That said sat3 and glo1 combined have something like an order of magnitude less 
capacity than wacs so the survival / utility of any of the older systems when 
losing the newest ones is probably less than complete.

> 
> On Sun, Jun 18, 2017 at 8:10 PM, Rod Beck
>  wrote:
>> 
>> PCCW has a strong presence in Africa and they are easy to work with.
>> 
>> 
>> - R.
>> 
>> 
>> From: NANOG  on behalf of Sina Owolabi
>> 
>> Sent: Sunday, June 18, 2017 8:59:41 PM
>> To: nanog@nanog.org list
>> Subject: Internet connectivity in Nigeria
>> 
>> Hi All
>> 
>> Currently having a terrible situation in Nigeria where the GLO1 and
>> MainOne cables appear to be both down.
>> Can anyone suggest a good Nigerian ISP with redundancies enough to
>> overcome at least two of the following dying out?
>> 
>> SAT-3
>> WACS
>> GLO1
>> ACE
>> MainOne
>> 
>> Please dont say MTN or any of the Nigerian telcos, except there are no
>> other options, customer service will leave you trying to commit bodily
>> harm.
> 

Re: BCP38/84 and DDoS ACLs

[joel jaeggli]

On 5/26/17 10:24, Kody Vicknair wrote:
> When I was doing some research in regards to the same subject I ran across 
> this doc. I've found it to be very helpful.
>
> http://nabcop.org/index.php/DDoS-DoS-attack-BCOP
Causally applied RPF checks applied to transit and peer interfaces
especially exchange fabrics have a very high-liklihood of blackholing
traffic you wanted particularly during maintenance if not casually
implemented. A very careful read rfc3704/bcp 84 is a necessary part of
implementing bcp 38 filters.

>
>
> 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-bounces+kvicknair=reservetele@nanog.org] On 
> Behalf Of Roland Dobbins
> Sent: Friday, May 26, 2017 12:20 PM
> To: nanog@nanog.org
> Subject: Re: BCP38/84 and DDoS ACLs
>
>
> On 26 May 2017, at 22:39, Graham Johnston wrote:
>
>> I am looking for information regarding standard ACLs that operators
>> may be using at the internet edge of their network, on peering and
>> transit connections,
> These .pdf presos may be of interest:
>
> 
>
> 
>
> They talk about iACL and tACL design philosophy.
>
> What traffic you should permit/deny on your network is, of course, 
> situationally-specific.  Depends on what kind of network it is, what 
> servers/services/applications/users you have, et. al.  You may need one set 
> of ACLs at the peering/transit edge, and other, more specific ACLs, at the 
> IDC distribution gateway, customer aggregation gateway, et. al.
>
> ---
> Roland Dobbins 
>




signature.asc
Description: OpenPGP digital signature

Re: Carrier classification

[joel jaeggli]

On 5/15/17 10:01 PM, Ken Chase wrote:
> so cogent has no routes to some amount of v6? ie no routes
> to some prefixes?

it's easy enough to test

TestRouter Location Hostname / IP Address   

2607:f8b0:4005:801::200e
Go!
Tue May 16 04:00:27.010 UTC
% Network not in table

http://www.cogentco.com/en/network/looking-glass

They're not the sole provider with a hole in their routing table, nor is
that the only hole. I would probably choose not to single home behind
any nominally SFI carrier, but on the other hand how useful such carrier
is in the first place has a lot to do with can they offload the traffic
you choose to send them, which is a different problem and should be
assessed accordingly.


> /kc
> 
> On Mon, May 15, 2017 at 07:56:14PM -0700, Large Hadron Collider said:
>   >My terminology of tiers are:
>   >
>   >Tier 1 - is in few or no major disputes, has no transit, and is able to
>   >access over three nines percent of the internet
>   >
>   >Tier 2 - as Tier 1, but has transit.
>   >
>   >Cogent is neither on v6, and I have no clue about v4.
>   >
>   >HE is probably Tier 2 on v4, and is Tier 1 on v6.
>   >
>   >
>   >On 15/05/2017 19:27, Ca By wrote:
>   >> On Mon, May 15, 2017 at 6:44 PM Bradley Huffaker  
> wrote:
>   >>
>   >>> On Sun, May 14, 2017 at 09:24:18AM +0200, Mark Tinka wrote:
>    Nowadays, I'm hearing this less and less, but it's not completely gone.
>   >>> Putting aside the question of their importance, there is a small number
>   >>> of ISPs that do no pay for transit. If you don't call them Tier 1, what
>   >>> do you call them? Transit Free Providers (TFPs)?
>   >>
>   >> I think the broader and more relevant question is -- Does it matter who
>   >> pays who ? Why name an irrelevant characteristic?
>   >>
>   >> Cogent may not buy transit but i would not purchase their service since
>   >> they fail to have full internet reach (google and HE)
>   >>
>   >> And xyz incumbent may have a poor network, but they may get free peering 
> or
>   >> may get paid-peering because of their incumbent / monopoly status... that
>   >> is not a reason for me to purchase from them or think they are an elite
>   >> tier 1.
>   >>
>   >> The dynamica of the day are more around reach and quality, not some 
> legacy
>   >> measure of how market-failure facilitate anti-social behavior
>   >>
>   >>
>   >>
>   >>> --
>   >>> the value of a world model is not how accurately it captures reality
>   >>> but how often it leads us to take appropriate action
>   >>>
>   >
> 




signature.asc
Description: OpenPGP digital signature

Re: Covering prefix blackholing traffic to one of its covered prefixes....

[Joel Jaeggli]

Sent from my iPhone

> On Apr 23, 2017, at 08:59, Steven Wallace  wrote:
> 
> We have dual-homed sites that only accept routes from their peers, and 
> default to their transit provider. A site may receive a covering prefix from 
> a peer, but since they are not accepting the full table from their transit 
> provider they don’t see the covered (i.e., more specific). In some cases the 
> peer announcing the covering prefix blackholes traffic to the covered prefix.

If you announce a route in general you should expect to route it.

Assuming this is the intended behavior of both parties announcing the covering 
aggregate and the more specific. The site should either drop the offending peer 
route forcing it to transit, or take full feed from it's transit. And let the 
longest match win.

> Is this accepted behavior, or should a peer announcing a covering prefix 
> always delver packets to its covered routes?

Generally but there are exceptions.

> 
> Does this happen often?
> 
> Thanks!
> 
> Steven Wallace
> Indiana University

Re: google ipv6 routes via cogent

[joel jaeggli]

On 3/2/17 3:42 PM, Jared Mauch wrote:
> Yes. Most providers can send you just their customer routes. If they send you 
> full routes you want to discriminate customer vs peer routes. This is 
> typically done with communities and is worthwhile as most people have 
> capacity on customer links but via peer it may not always be the case. 
>
> As is usual YMMV
It's relatively straight-forward to take a full table feed and accept
into your fib only the routes you want from that table.

I presented on variant of that based on my need for partial fib peering
switches; but other reasons for doing so exist, e.g. defailt +
te-overrides, prefix filters weighted by per prefix utilization and so on.

In general I'd get the full table and the default if you intend to take
the default but need recourse to over-rides (for example if your fib
won't hold full table is an element of the design). if the Rib won't
hold three full tables well that's a different sort of problem, and this
may be the wrong router platform.

joel
> Jared Mauch
>
>> On Mar 2, 2017, at 2:52 PM, Aaron Gould  wrote:
>>
>> Yes, thanks, I am going to do that.  But, is there a middle ground between 
>> being default only and full routes ?  Like is it advantageous for me to ask 
>> for partial routes (like their routes and direct peers and default route) ?  
>> This way I don't have millions of routes but I guess only a few hundred 
>> thousand or less?  Let me know please.
>>
>> -Aaron
>




signature.asc
Description: OpenPGP digital signature

Re: ticketmaster.com 403 Forbidden

[joel jaeggli]

On 2/6/17 8:49 AM, Suresh Ramasubramanian wrote:
> My guess is you have or had sometime in the long distant past a scalper 
> operating on your network, using automated ticket purchase bots.
>
> If you still have that scalper around, you might want to turf him.  If he’s 
> ancient history, saying so might induce them to remove the block.
Note that scalper bots benefit from pools of residential ip addresses to
work with in subverting the anti-bot countermeasures of ticket sale
platforms. so there are the legitimate possibility that subverted hosts
are being used for that sort of thing.
> --srs
>
> On 06/02/17, 8:45 AM, "nanog-boun...@nanog.org on behalf of 
> mike.l...@gmail.com"  mike.l...@gmail.com> wrote:
>
> Yup, i have a /22 that has the same problem. Support is useless...
> 
> > On Feb 6, 2017, at 08:35, Ethan E. Dee  wrote:
> > 
> > It gives me a Forbidden error.
> > It has for over a year.
> > There support says they are not allowed to me why by their policy.
> > it is across an entire /19.
> > I gave up after the fifth time and encourage the customers to call them 
> individually.
> > 
> >> On 02/06/2017 11:09 AM, Niels Bakker wrote:
> >> * charles.man...@charter.com (Manser, Charles J) [Mon 06 Feb 2017, 
> 16:21 CET]:
> >>> It seems that browsing to ticketmaster.com or any of the associated 
> IP addresses results in a 403 Forbidden for our customers today. Is anyone 
> else having this issue?
> >> 
> >> 
> http://help.ticketmaster.com/why-am-i-getting-a-blocked-forbidden-or-403-error-message/
>  
> >> 
> >> 
> >>-- Niels.
> > 
> 
>
>
>




signature.asc
Description: OpenPGP digital signature

Re: IoT security

[joel jaeggli]

On 2/6/17 2:31 PM, William Herrin wrote:
> This afternoon's panel about IoT's lack of security got me thinking...
>
>
> On the issue of ISPs unable to act on insecure devices because they
> can't detect the devices until they're compromised and then only have
> the largest hammer (full account ban) to act...
>
> What about some kind of requirement or convention that upon boot and
> successful attachment to the network (and maybe once a month
> thereafter), any IoT device must _by default_ emit a UDP packet to an
> anycast address reserved for the purpose which identifies the device
> model and software build. The ISP can capture traffic to that anycast
> address, compare the data against a list of devices known to be
> defective and, if desired, respond with a fail message. If the IoT
> device receives the fail message, it must try to report the problem to
> its owner and remove its default route so that it can only communicate
> on the local lan.  The user can override the fail and if desired
> configure the device not to emit the init messages at all. But by
> default the ISP is allowed to disable the device by responding to the
> init message.
self identification is privacy hostile and tantamount to indicating a
willingness to be subverted (this is why we disable lldp on external
interfaces) even if it would otherwise be rather useful. the use of
modified eui64 addresses as part of v6 address selection hash basically
gone away for similar reasons.
> Would have to cryptographically sign the fail message and let the
> device query the signer's reputation or something like that to avoid
> the obvious security issue. Obvious privacy issues to consider.
> Anyway, throwing it out there as a potential discussion starting
> point.
>




signature.asc
Description: OpenPGP digital signature

Re: Akamai and Instagram Ranges

[joel jaeggli]

On 1/28/17 3:22 AM, Shahab Vahabzadeh wrote:
> Hello Hello,
> Can anybody help me to find out IP Address Ranges of Akamai and Instagram?
> I wanna do some optimizations on my cache side?
> Thanks
> 

Instagram should be exclusively https since 2014 or so.



signature.asc
Description: OpenPGP digital signature

Re: Passive Optical Network (PON)

[joel jaeggli]

On 1/21/17 8:44 AM, Kenneth McRae wrote:
> Greeting all,
>
> Is anyone out there using PON in a campus or facility environment?  I am 
> talking to a few vendors who are pushing PON as a replacement for edge 
> switching on the campus and in some cases, ToR switch in the DC.  Opinions on 
> this technology would be greatly appreciated.
The datacenter tor / host evironments I'm exposed to generally consider
10Gb/s or Nx10 to be the performance floor not the ceiling. To my
thinking 100gig lr4 results in a substantial reduction in
fiber/optic/port count which will in the long more than offset the
increased cost something that didn't really happen with 40gig.
> Thanks,
>
> Kenneth
>




signature.asc
Description: OpenPGP digital signature

Re: Questions on IPv6 deployment

[joel jaeggli]

On 1/17/17 1:55 PM, William Herrin wrote:
> On Tue, Jan 17, 2017 at 4:07 PM, Matthew Huff  wrote:
>> The reason for allocating a /64 for a point to point link is due to various 
>> denial of service attack vectors.


if you mean allocating a /127, then... sure.

Neighbor discovery on point to point links could be a problem as is the
poential for looping behavior . There are of course ways other than
allocating a longer prefix to a point to point link to achieve that, 
e.g. disabling it. among other things You have to disable DAD anyway if
you ever plan to loop them up for testing.

these are detailed in

https://tools.ietf.org/html/rfc6164
>> Hi Matthew,
>>
>> I'm always interested in learning something new. Please explain the
>> DOS vectors you're referring to and how they're mitigated by
>> allocating a /64 to the point to point link.
>>
>>
>> Just do it.
> No. But if you offer a good reason, I'll factor your reason in to my
> considerations.
>
> Regards,
> Bill Herrin
>




signature.asc
Description: OpenPGP digital signature

Re: External BGP Controller for L3 Switch BGP routing

[joel jaeggli]

On 1/15/17 11:00 PM, Yucong Sun wrote:
> In my setup, I use an BIRD instance to combine multiple internet full
> tables,  i use some filter to generate some override route to send to my L3
> switch to do routing.  The L3 switch is configured with the default route
> to the main transit provider , if BIRD is down, the route would be
> unoptimized, but everything else remain operable until i fixed that BIRD
> instance.
> 
> I've asked around about why there isn't a L3 switch capable of handling
> full tables, I really don't understand the difference/logic behind it.

In practice there are several merchant silicon implmentations that
support the addition of external tcams. building them accordingly
increases the COGS and and various performance and packaging limitions.

arista 7280r and cisco ncs5500 are broadcom jericho based devices that
are packaged  accordingly.

Ethernet merchant silicon is heavily biased towards doing most if not
all the IO on the same asic, with limitations driven by gate size, die
size, heat dissipation pin count an so on.

There was a recent packet pushers episode with Pradeep Sindhu that
touched on some of these issues:

http://packetpushers.net/podcast/podcasts/show-315-future-networking-pradeep-sindhu/


> On Sun, Jan 15, 2017 at 10:43 PM Tore Anderson  wrote:
> 
>> Hi Saku,
>>

>> https://www.redpill-linpro.com/sysadvent/2016/12/09/slimming-routing-table.html
>>>
>>> ---
>>> As described in a prevous post, we’re testing a HPE Altoline 6920 in
>>> our lab. The Altoline 6920 is, like other switches based on the
>>> Broadcom Trident II chipset, able to handle up to 720 Gbps of
>>> throughput, packing 48x10GbE + 6x40GbE ports in a compact 1RU chassis.
>>> Its price is in all likelihood a single-digit percentage of the price
>>> of a traditional Internet router with a comparable throughput rating.
>>> ---
>>>
>>> This makes it sound like small-FIB router is single-digit percentage
>>> cost of full-FIB.
>>
>> Do you know of any traditional «Internet scale» router that can do ~720
>> Gbps of throughput for less than 10x the price of a Trident II box? Or
>> even <100kUSD? (Disregarding any volume discounts.)
>>
>>> Also having Trident in Internet facing interface may be suspect,
>>> especially if you need to go from fast interface to slow or busy
>>> interface, due to very minor packet buffers. This obviously won't be
>>> much of a problem in inside-DC traffic.
>>
>> Quite the opposite, changing between different interface speeds happens
>> very commonly inside the data centre (and most of the time it's done by
>> shallow-buffered switches using Trident II or similar chips).
>>
>> One ubiquitous configuration has the servers and any external uplinks
>> attached with 10GE to leaf switches which in turn connects to a 40GE
>> spine layer with. In this config server<->server and server<->Internet
>> packets will need to change speed twice:
>>
>> [server]-10GE-(leafX)-40GE-(spine)-40GE-(leafY)-10GE-[server/internet]
>>
>> I suppose you could for example use a couple of MX240s or something as
>> a special-purpose leaf layer for external connectivity.
>> MPC5E-40G10G-IRB or something towards the 40GE spines and any regular
>> 10GE MPC towards the exits. That way you'd only have one
>> shallow-buffered speed conversion remaining. But I'm very sceptical if
>> something like this makes sense after taking the cost/benefit ratio
>> into account.
>>
>> Tore
>>
> 




signature.asc
Description: OpenPGP digital signature

Re: External BGP Controller for L3 Switch BGP routing

[joel jaeggli]

On 1/16/17 6:53 AM, Tore Anderson wrote:
> * Saku Ytti
> 
>> On 16 January 2017 at 14:36, Tore Anderson  wrote:
>>
>>> Put it another way, my «Internet facing» interfaces are typically
>>> 10GEs with a few (kilo)metres of dark fibre that x-connects into my
>>> IP-transit providers' routers sitting in nearby rooms or racks
>>> (worst case somewhere else in the same metro area). Is there any
>>> reason why I should need deep buffers on those interfaces?  
>>
>> Imagine content network having 40Gbps connection, and client having
>> 10Gbps connection, and network between them is lossless and has RTT of
>> 200ms. To achieve 10Gbps rate receiver needs 10Gbps*200ms = 250MB
>> window, in worst case 125MB window could grow into 250MB window,  and
>> sender could send the 125MB at 40Gbps burst.
>> This means the port receiver is attached to, needs to store the 125MB,
>> as it's only serialising it at 10Gbps. If it  cannot store it, window
>> will shrink and receiver cannot get 10Gbps.
>>
>> This is quite pathological example, but you can try with much less
>> pathological numbers, remembering TridentII has 12MB of buffers.
> 
> I totally get why the receiver need bigger buffers if he's going to
> shuffle that data out another interface with a slower speed.
> 
> But when you're a data centre operator you're (usually anyway) mostly
> transmitting data. And you can easily ensure the interface speed facing
> the servers can be the same as the interface speed facing the ISP.

unlikely given that the interfaces facing the server is 1/10/25/50 and
the one facing the isp is n x 10 or n x 100

> So if you consider this typical spine/leaf data centre network topology
> (essentially the same one I posted earlier this morning):
> 
> (Server) --10GE--> (T2 leaf X) --40GE--> (T2 spine) --40GE-->
> (T2 leaf Y) --10GE--> (IP-transit/"the Internet") --10GE--> (Client)
> 
> If I understand you correctly you're saying this is a "suspect" topology
> that cannot achieve 10G transmission rate from server to client (or
> from client to server for that matter) because of small buffers on my
> "T2 leaf Y" switch (i.e., the one which has the Internet-facing
> interface)?

you can externalize the cost of the buffer at the expense of latency
from the t2, e.g. by enabling flow control faciing the host or other
high capacity device, or engaging in packet pacing on the server if the
network is fairly shallow.

If the question is how can I ensure high link utilization rather than
maximum throughput for this one flow, the buffer requirement  may be
substantially lower.

e.g. if you are sizing based on

buffer = (bandwidth delay * desired bandwidth) / sqrt(nr of flows)

http://conferences.sigcomm.org/sigcomm/2004/papers/p277-appenzeller1.pdf

rather than buffer = (bandwidth delay * bandwidth)

> If so would it solve the problem just replacing "T2 leaf Y" with, say,
> a Juniper MX or something else with deeper buffers?

broadcom jericho/ptx/qfx whatever sure it's plausible to have a large
buffer without using the feature rich extremely large fib asic.

> Or would it help to use (4x)10GE instead of 40GE for the links between
> the leaf and spine layers too, so there was no change in interface
> speeds along the path through the data centre towards the handoff to
> the IPT provider?

it can reduce the demand on the buffer, you can however multiplex two
our more flows that might otherwise run at 10Gb/s onto the same lag member.

> Tore
> 




signature.asc
Description: OpenPGP digital signature

Re: IPv6 BGP prefix filters

[joel jaeggli]

On 1/16/17 2:01 PM, Alistair Mackenzie wrote:
> Hi,
> 
> So recently I've come across an issue with a large ISP announcing a /22 and
> /25 of IPv6 space. We are currently filtering <28 and >48 which until now
> has worked fine for us.
> 
> What are others using as their prefix filters in the DFZ?

Currently the shortest prefix delegation to an RIR is a /12,  the
assigned global uni-cast range at present all fits within 2000::/3.

I currently apply   < 20,  > /48 but I also have recourse to default.

> Thanks,
> Alistair
> 




signature.asc
Description: OpenPGP digital signature

Re: Apple Caching Server question

[joel jaeggli]

On 1/13/17 5:43 AM, lane.pow...@swat.coop wrote:
> I saw the apple caching server mentioned on an earlier thread. Is this 
> appropriate/functional/scaleable enough to implement as an ISP? It is an 
> intriguing idea. From the docs I could find, I couldn't tell if it was only 
> geared towards home / small business or if it could scale up to handle ISP 
> level traffic. 

It's a feature of macos server. You do get to register prefix with
apple, but I don't imagine colocating a mac mini is isp level traffic.

That said as714 peers extensively

https://www.peeringdb.com/net/3554

so picking them up works too.

> thanks, 
> Lane 
> 




signature.asc
Description: OpenPGP digital signature

Re: Soliciting your opinions on Internet routing: A survey on BGP convergence

[joel jaeggli]

On 1/9/17 2:56 PM, Laurent Vanbever wrote:
> Hi NANOG,
> 
> We often read that the Internet (i.e. BGP) is "slow to converge". But how slow
> is it really? Do you care anyway? And can we (researchers) do anything about 
> it?
> Please help us out to find out by answering our short anonymous survey 
> (<10 minutes).
> 
> Survey URL: https://goo.gl/forms/JZd2CK0EFpCk0c272 
> 
> 
> 
> ** Background:
> 
> While existing fast-reroute mechanisms enable sub-second convergence upon 
> local outages (planned or not), they do not apply to remote outages happening 
> further away from your AS as their detection and protection mechanisms only 
> work locally.
> 
> Remote outages therefore mandate a "BGP-only" convergence which tends to be
> slow, as long streams of BGP UPDATEs (containing up to 100,000s of them) must
> be propagated router-by-router. Our initial measurements indicate that it can
> take state-of-the-art BGP routers dozens of seconds to process and propagate
> these large streams of BGP UPDATEs. During this time, traffic for important
> destinations can be lost.

One of the phenomena that is relatively easy to observe by withdrawing a
prefix entirely is the convergence towards longer and longer AS paths
until the route disappears entirely. that is providers that are further
away will remain advertising the route and in the interim their
neighbors  will ingest the available path will  until they too process
the withdraw. it can take a comically long time (like 5 minutes)  to see
the prefix ultimately disappear from the internet. When withdrawing a
prefix from a peer with which you have a single adjacency this can
easily happens in miniature.

> 
> ** This survey:
> 
> This survey aims at evaluating the impact of slow BGP convergence on
> operational practices. We expect the findings to increase the understanding of
> the perceived BGP convergence in the Internet, which could then help
> researchers to design better fast-reroute mechanisms.
> 
> We expect the questionnaire to be filled out by network operators whose job 
> relates
> to BGP operations. It has a total of 17 questions and should take less 10 
> minutes
> to answer. The survey and the collected data are anonymous (so please do *not*
> include information that may help to identify you or your organization). 
> All questions are optional, so if you don't like a question or don't know the 
> answer,
> please skip it.
> 
> A summary of the aggregate results will be published as a part of a scientific
> article later this year.
> 
> Thank you so much in advance, and we look forward to read your responses!
> 
> 
> Laurent Vanbever (ETH Zürich, Switzerland)
> 
> 
> PS: It goes without saying that we would be also extremely grateful if you 
> could
> forward this email to any operator you might know who may not read NANOG.
> 




signature.asc
Description: OpenPGP digital signature

Re: Benefits (and Detriments) of Standardizing Network Equipment in a Global Organization

[joel jaeggli]

On 12/29/16 10:22 AM, valdis.kletni...@vt.edu wrote:
> On Thu, 29 Dec 2016 07:44:45 -0800, Leo Bicknell said:
> 
>> But I think the question others are trying to ask is a different
>> hyptothetical.  Say there are two vendors, of of which makes perfectly
>> good edge routers and core routers.  What are the pros to buying all
>> of the edge from one, and all of the core from the other?
> 
> The *original* question, which seems to have gotten lost, was:
> 
> Say you're doing business in 100 countries, with some stated level of
> possible autonomy for each business unit.
> 
> Is it better for upper corporate to say "all 100 national business units
> will use vendor A for edge devices and vendor B for routing", or "all 100
> business units shall choose, based on local conditions such as vendor
> support, a standard set of vendors for their operations"?
> 
> Stated differently, "Which causes more trouble - a mix of Vendor A in
> Denmark talking to Vendor B in Finland, or corporate mandating the use
> of Vendor Q even if Q doesn't have a support office in Kazakhstan while
> vendor F has an office in the building next door"?

ok I'll bite.

imho, repeatable patterns of deployment are a great  economic and
organizational simplification. imho that doesn't mean they are
identical. There may be generational differences even in what otherwise
would be cookie cutter deployments, e.g. because devices go end of sale,
new ones become available, regional vendor preference or vendor
diversification.

If these are centrally organized and operated or coordinated, then the
minimum number of variants possible considering the circumstances where
variation is is desirable. It minimizes the effort and training required
to deploy and operate the system.

If I were to take CDN pops as an example.

Inter-generational variation is necessary as are accommodations for
varying scale. the system is centrally coordinated and common operating
methods are necessary if these systems are to behave a cohesive whole.

Systems where deployment is less centralized, and local autonomy is
therefore necessary as for example occurs when local contractors use
their own equipment may come to different conclusions. e.g. that the
specification of  the minimum necessary common elements becomes the only
feasible approach. For example if you are an Uber driver your minim  IT
requirements are something like

Uber cell phone requirements
iPhone requirements to run the Uber driver app

Must be iPhone 4S, 5, 5C, 5S, 6, 6 Plus, 6S, 6S Plus, SE, 7, or 7 Plus
running iOS 8 or later versions
For best results: Use iPhone 5 or newer

Android requirements to run the Uber driver app

Any smart phone from 2013 or newer, running Android version 4.0 or newer
For best results: The phone should run Android 5.0 or newer




signature.asc
Description: OpenPGP digital signature

Re: BCM5341x

[Joel Jaeggli]

Sent from my iPhone

> On Dec 24, 2016, at 15:51, Mike Hammett  wrote:
> 
> I've asked Broadcom directly, but being as though I don't have an intent to 
> buy tens of thousands of chips (or any at all), I don't expect I'll hear 
> back. I was hoping someone here would have some insight. 
> 
> Do any of you know what functionality is available on those chips? That's the 
> chip that powers the Ubiquiti 10G switches and I figured I would limit my 
> most aggressive feature requests to things they can actually deliver with the 
> platform as is. 
> 
> Other than things you just assume a managed switch has like 802.1p and 
> 802.1q, it mentions an advanced ContentAware™ Engine (which means?), IEEE1588 
> (sync over Ethernet), 802.1ag (OAM stuff), "Enhanced DoS attack statistics 
> gathering" (which means?), "IPv4/IPv6 L3 packet classification" (which 
> means?), etc. 
> 
> I'm sure there's an array of things to ask about, but MLAG and S-Flow are at 
> the top of my list at the moment. 

MCLAG is a control plane function. 

Sflow on devices that don't generate it in a distributed fashion is done but 
punting sampled packets to the control-plane for classification by an sflow 
agent. Sample rate is therefore contingent on adequate CPU and control-plane 
bandwidth.

The greyhound switch SOC may be hampered by the amount of CPU available 
locally, but the 2MB packet buffer also is probably cause for caution.

> https://www.broadcom.com/products/ethernet-connectivity/switch-fabric/bcm5341x/
>  
> 
> 
> 
> 
> - 
> Mike Hammett 
> Intelligent Computing Solutions 
> 
> Midwest Internet Exchange 
> 
> The Brothers WISP 
> 
> 

Re: Recent NTP pool traffic increase

[joel jaeggli]

On 12/15/16 3:07 PM, Dan Drown wrote:
> Quoting Jose Gerardo Perales Soto :
>> We've recently experienced a traffic increase on the NTP queries to
>> NTP pool project (pool.ntp.org) servers. One theory is that some
>> service provider NTP infraestructure failed approximately 2 days ago
>> and traffic is now being redirected to servers belonging to the NTP
>> pool project.
>>
>> Does anyone from the service provider community have any comments?
>
> To add some more numbers to this, I'm seeing 4x the usual NTP traffic
> to my server in pool.ntp.org, starting Dec 13.
>
> Top source ASNs by % of NTP traffic seen by my server (I don't have
> pre-Dec 13 traffic by ASN handy)
>
> sprint 4.0%
> verizon-wireless 3.4%
> tmobile 2.9%
> att-wireless 2.8%
> comcast 2.1%
> orange 1.8%
> sky 1.6%
> twc 1.0%
> att 1.0%
> swisscom 0.9%
> saudinet 0.8%
> virgin 0.6%
> opaltelecom 0.5%
> qwest 0.5%
> eli 0.2%
> verizon 0.2%
>
> Possibly related is the new iOS release.  Does the new iOS generate
> more NTP traffic?  Can anyone measure that?

IOS uses time.appple.com which is widely available.





signature.asc
Description: OpenPGP digital signature

Re: Cogent Router code updates during height of ecommerce season?

[joel jaeggli]

On 12/9/16 11:30 AM, Justin Wilson wrote:
> Are they not doing these during maintenance windows? Anytime we get a notice 
> from Cogent, Level3, Att they are always during a maintenance window at least 
> a week ahead of time.  We have yet to see any maintenance window 
> notifications from Hurricane Electric.  Maybe our circuit has never had to 
> have one in a few years. Or maybe they have so much redundancy it doesn’t 
> matter and we never see the maintenance.  
FWIW I have a few Cogent circuits, The maintenance look normalish and
are all scheduled per their normal process, I aware of at least one
cisco bug related to source mac usage they had that was annoying if not
catastrophic since it was visible on our ports.
>
> Justin Wilson
> j...@mtin.net
>
> ---
> http://www.mtin.net Owner/CEO
> xISP Solutions- Consulting – Data Centers - Bandwidth
>
> http://www.midwest-ix.com  COO/Chairman
> Internet Exchange - Peering - Distributed Fabric
>
>> On Dec 8, 2016, at 11:09 AM, Drew Weaver  wrote:
>>
>> Hello,
>>
>> Over the last several days we have had interruptions at multiple times in 
>> our service with Cogent due to them performing router code updates on 
>> multiple nodes. I know that some companies put these sorts of updates on 
>> hold during the holiday season but I was wondering if anyone has heard of 
>> any unannounced security flaws that only larger companies such as Cogent 
>> would be privy to?
>>
>> I am certain that if you have heard of these flaws you cannot post the 
>> details but a simple yes or no about the existence of such a thing is plenty 
>> for me.
>>
>> Happy Holidays
>>
>> Thanks,
>> -Drew
>>
>




signature.asc
Description: OpenPGP digital signature

Re: Voice channels (FTTH, DOCSIS, VoLTE)

[joel jaeggli]

On 11/21/16 3:12 PM, Jean-Francois Mezei wrote:
> On 2016-11-21 15:18, joel jaeggli wrote:
>
>
>> SRB and URB are the l2 presentation of the tunnels established for user
>> and signaling traffic.
> OK, so wth LTE, if carrier has 10mhz up and down, this represents a
> single chunk of spectrum providing one pipe ? (in fibre terms: a single
> light colour through one strand)
Not really the air interface uses OFDMA coding scheme, so it is both
divided into sub-carriers from 1.4 to 20mhz wide which are then also
scheduled accordingly.
> The "smoke and mirrors" is accomplished by having different tunnels
> inside that one pipe, with some tunnels granted QoS or other
> preferential treatment between the IMS/VoiP servers and the RAN ?
you kinda want you qos policy to apply end-to-end in the carrier
network, not just on the ran.
> When a handset sends a VolTE packet to the "IMS" APN, is there any
> preferential treatment given between the handset and the antenna ?
sure, hence the qos policy template on the radio bearer.
differing numbers of subcarriers and slots can be assigned to UE based
on the services they are using.

>  Or
> does preferential treatment begin at the RAN where the packet is
> recognized as going to "IMS" APN and going on the fast track to it ?
>
> or put another way. If everyone uploads a HD selfie movie at the same
> time, are handset uploads slowled with normal TCP flow control (drop a
> packet, no ack received, handset halves the TCP window size)?
Those flows going to have the best effort policy. but yes it is
reasonable to presume that in the event of congestion the best effort
queue will be preferentially dropped. likewise if you have voice and
data going at the same time they are not strictly speaking competing for
resources, because the volte radio bearer has a resource assigned to it
and the and the ip data bearer has a resource assigned to it.
> In other words, some router near antenna, to prioriotize packets to the
> IMS/VoLTE server, will flow control normal IP traffic to maintain
> sufficient upload capacity for VolTE traffic ?
>
> Or are the tunnels fixed in capacity such that unused capacity in one is
> never used by the other ?
>
>
>
> From a policy point of view, if I propose a net neutrality policy, I
> have to make sure it doesn't prevent normal VoLTE functioning, while
> preventing abuse of the ability for an incumbent to prioritize/zero-rate
> its own services.
> For instance:
>
>
> AT in USA zero rates voice but not video calls over VoLTE.
> Rogers in Canada zero rates both voice and video calls over VoLTE.
>
> So if VoLTE video travels to the same IMS as voice, and not through the
> normal IP APN, that means AT has to count the video traffic separately
> and add it. But if Video goes through the normal IP traffic APN, it gets
> counted fairly, like Skype packets, but Rogers then captures that
> netflow and later deducts it from the total usage.
>
> The issue here is that VoLTE is the new kid on the block with video
> capability and incumbents can use their power to displace competitors
> such as Skype/Facetime and that may constitute undue preference, unless
> the standards are such that they have no choice because that it how it
> has to work. (But AT shows that it can still count video and treat
> video calls fairly compared o skype video calls).
>
>




signature.asc
Description: OpenPGP digital signature

Re: Voice channels (FTTH, DOCSIS, VoLTE)

[joel jaeggli]

On 11/21/16 11:13 AM, Jean-Francois Mezei wrote:
> On 2016-11-21 02:53, Mikael Abrahamsson wrote:
>
>> Typically it travels on another "bearer" compared to Internet traffic.
>>
>> http://blog.3g4g.co.uk/2013/08/volte-bearers.html
>>
>> Think of bearers as "tunnels" between the mobile core network and the 
>> device. 
> Many thanks for the pointer. The fact that VoLTE has its own dedicated
> APN explains things.
>
> I am however a bit confused on the "bearer" term.
>
> Say a carrier has spectrum in 700Mhz  bands A and B  each 5mhz in each
> direction, bonded together as a single 10mhz (each way) channel.
>
> The docunment states:
> "R.92 requires the use of a particular set of radio bearers"

the radio bearers described are are the signaling radio bearers. their
existence is independent of of the link/mac layer configuration. The mac
layer layer (e-utra) exists below the l2 bearers.

https://en.wikipedia.org/wiki/E-UTRA
> Does this mean that a bearer is given specific spectrum within a block
> (such as a dedicated colour on a fibre) or that it is just given
> dedicated capacity on the single data channel formed by LTE compressing
> all of the spectrum into one big channel ?
>
> I though I understood the concept when the name "tunnel" had been
> mentioned because I understand that a handset estabishes a "hopping"
> tunnel with local IP which changes as you move from tower to tower, but
> the tunnel itself maintains a permanent IP connection that remains
> unchanged as you move from tower to tower. In such a concept, I could
> understand each tunnel (one to the data APN, one to the IMS/VoLTE APN)
> having bandwidth allocations.
these are URBs they are terminated between the UE and the P-GW
> But when the text brought up "radio bearer", I got confused again sicne
> radio implies breaking the spectrum apart, which would reduce LTE
> compression efficiency.
SRB and URB are the l2 presentation of the tunnels established for user
and signaling traffic.
>
>
>




signature.asc
Description: OpenPGP digital signature

Re: pay.gov and IPv6

[joel jaeggli]

00:02:02.758900 IP6 2601:647:4201:.60962 >
2605:3100:fffd:100::15.443: Flags [S], seq 2375673666, win 65535,
options [mss 1440,nop,wscale 5,nop,nop,TS val 568401205 ecr
0,sackOK,eol], length 0

00:02:02.811619 IP6 2605:3100:fffd:100::15.443 >
2601:647:4201:.60962: Flags [S.], seq 2570148804, ack 2375673667,
win 4320, options [mss 1440,nop,nop,TS val 2246573166 ecr
568401205,sackOK,eol], length 0

it's happy to do 1440 which is unsprising, as1239 is probably not
therefore the source of the pmtud hole.

On 11/20/16 11:51 PM, JORDI PALET MARTINEZ wrote:
> Tested again from four different networks. Not working for me. > > Same in 
> other web sites hosted by 1&1 (for example
www.legalveritas.es). All their IPv6 web sites are broken, every time I
need to access their web sites, need to disable IPv6, I know how to do
that, but regular folks not. > > tbit from 2001:df0:4:4000::1:115 to
2001:8d8:100f:f000::2d5 > server-mss 1420, result: pmtud-fail > app:
http, url: http://diskmakerx.com/ > [  0.010] TX SYN 64  seq
= 0:0> [  0.286] RX SYN/ACK 64  seq = 0:1   
> [  0.286] TX 60  seq = 1:1> [  0.297]
TX233  seq = 1:1(173)> [  0.573]
RX 60  seq = 1:174  > [  0.799] RX  
1480  seq = 1:174(1420)> [  0.799] RX 73  seq =
1421:174(13)> [  0.799] RX   1480  seq = 1434:174(1420) 
> [  0.799] RX   1480  seq = 2854:174(1420)  > [  0.799] TX
PTB   1280  mtu = 1280 > [  0.799] RX   1480  seq =
4274:174(1420)  > [  0.799] RX   1480  seq = 5694:174(1420) 
> [  0.799] RX   1480  seq = 7114:174(1420)  > [  0.801]
RX   1480  seq = 8534:174(1420)  > [  0.809]
TX 60  seq = 174:1  > [  0.821] RX  
1480  seq = 9954:174(1420)  > [  0.824] RX   1480  seq =
11374:174(1420) > [  1.628] RX   1480  seq = 1:174(1420)   
> [  1.629] TX PTB   1280  mtu = 1280 > [  3.288]
RX   1480  seq = 1:174(1420)> [  3.288] TX PTB  
1280  mtu = 1280 > [  6.612] RX   1480  seq = 1:174(1420)   
> [  6.612] TX PTB   1280  mtu = 1280 > [ 13.252]
RX   1480  seq = 1:174(1420)> > > > Regards, > Jordi > >
> -Mensaje original- > De: Mark Andrews  >
Responder a:  > Fecha: lunes, 21 de noviembre de 2016,
1:26 > Para: Carl Byington  > CC:
,  > Asunto: Re: pay.gov
and IPv6 > > > In message
<1479686835.13553.4.ca...@ns.five-ten-sg.com>, Carl Byington writes:
> On Sun, 2016-11-20 at 10:51 +0100, JORDI PALET MARTINEZ wrote:
> > For example, you will not get this working if you have a lower MTU
> > than 1.500, which is quite normal, not just for tunnels, but also
> > because the PPP/others encapsulation in many access links:
>
> > http://diskmakerx.com/
>
> curl -6 -v http://diskmakerx.com/
>
> That works here via an he.net tunnel. Perhaps 1and1 fixed something.
>
> > And the advertised MSS was what?  On my box I'm seeing 1220 for
> > IPv6 compared with 1460 for IPv4.  1220 shouldn't see PMTU problems.
>
> > 1460 on the other hand will cause problems as more clients are
> > forced behind IPv4 as a service links.
>
> > 11:14:50.056215 IP 172.30.42.121.52280 > 217.160.0.214.80: Flags
> [S], seq 2115844511, win 65535, options [mss 1460,nop,wscale
> 4,nop,nop,TS val 538455715 ecr 0,sackOK,eol], length 0
> > 11:14:50.137770 IP6 2001:470:a001:4:c00d:3d8c:14e7:6de3.52282 >
> 2001:8d8:100f:f000::2d5.80: Flags [S], seq 4181372812, win 65535,
> options [mss 1220,nop,wscale 4,nop,nop,TS val 538455793 ecr
> 0,sackOK,eol], length 0
>
> > Mark
>
> > > > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas
Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742
INTERNET: ma...@isc.org > > > > > >
** > IPv4 is over > Are you
ready for the new Internet ? > http://www.consulintel.es > The IPv6
Company > > This electronic message contains information which may be
privileged or confidential. The information is intended to be for the
use of the individual(s) named above. If you are not the intended
recipient be aware that any disclosure, copying, distribution or use of
the contents of this information, including attached files, is
prohibited. > > >





signature.asc
Description: OpenPGP digital signature

Re: CenturyLink in Advanced Talks to Merge With Level 3 Communications - Interweb is doomed

[joel jaeggli]

On 10/28/16 12:18 PM, Mel Beckman wrote:
> Level3 hasn't even finished migrating its TWTelecom customers to the L3 AS 
> yes, and it's been years. So I don't think you can expect any faster 
> transition for CL. 
3549 still exists...
>  -mel beckman
>
>> On Oct 28, 2016, at 2:16 PM, Timothy Lister  wrote:
>>
>> So if this went through, how would it happen? Does 3356 (L3) absorb 209's
>> (CL) infrastructure and slowly make customers change their peering config
>> to hit 3356 instead?
>>
>> You make a good point, I have at least a couple clients that peer to both
>> providers for redundancy. One of which just recently signed an agreement
>> with CenturyLink for the sole purpose of fail over.
>>
>> -Original Message-
>> Re: CenturyLink in Advanced Talks to Merge With Level 3 Communications -
>> Interweb is doomed
>> From: Jima 
>> To: 
> On 10/27/2016 12:36, Nevin Gonsalves via NANOG wrote:
> :-)
>> http://www.wsj.com/articles/centurylink-in-advanced-talks-to-merge-with-level-3-communications-1477589011
>>
>>
>> This is great! Except for all of their mutual customers who had circuits
>> from both for redundancy. (See also: Level 3's and TWTC's mutual
>> customers, and probably a long list of other M I'm not thinking of
>> off-hand.)
>>
>> OK, I lied about it being great anyway.
>>
>>  Jima
>>
>>
>>
>> -Original Message-
>> Re: CenturyLink in Advanced Talks to Merge With Level 3 Communications -
>> Interweb is doomed
>> From: Jima 
>> To: 





signature.asc
Description: OpenPGP digital signature

Re: Dyn DDoS this AM?

[joel jaeggli]

On 10/21/16 3:21 PM, David Birdsong wrote:
> On Fri, Oct 21, 2016 at 2:58 PM, Randy Bush  wrote:
>
>> anyone who relies on a single dns provider is just asking for stuff such
>> as this.
>>
>> randy
>>
> I'd love to hear how others are handling the overhead of managing two dns
> providers. Every time we brainstorm on it, we see it as blackhole of eng
> effort WRT to keeping them in sync and and then waiting for TTLs to cut an
> entire delegation over.

Not all the ones you might choose based on scale support axfr... That's
a bit of a problem for the most traditional approach to this., of those 
that do it's straight-forward to use one as the master for another, or
use a hidden master. Your own master may have demonstrably lower
availability then one or the other of your providers. getting two well
considered choices to play nice with each other isn't that hard.





signature.asc
Description: OpenPGP digital signature

Re: nested prefixes in Internet

[joel jaeggli]

On 10/10/16 9:04 AM, Roy wrote:
>
>
> The solution proposed allows ISP-B to use both paths at the same time,
> needs ISP-C to minimal changes, and has low impact on the global
> routing tables..  I have successfully used it in the past and my old
> company is still using it today.

Having two parties in control of a prefix announcement is a bit of a
disaster. ISP A becomes partitioned from isp B isp B does not withdraw
the covering aggregate and black-holes the of ISP A that lands on it's 
edge. bummer.

>
> .On 10/9/2016 11:50 PM, Martin T wrote:
>> Florian:
>>
>> as I told in my initial e-mail, ISP-B is multi-homed, i.e connected to
>> ISP-A(who leases the /24 to ISP-B from their /19 block) and also to
>> ISP-C. ISP-B wants to announce this /24 both to ISP-A and ISP-C.
>> That's the reason why either solution 1 or 2 in my initial e-mail is
>> needed.
>>
>> However, I would like to hear from Roy and Mel why do they prefer a
>> third option where ISP A announces the /19 and the /24 while ISP B
>> does just the /24.
>>
>>
>> thanks,
>> Martin
>>
>> On Wed, Oct 5, 2016 at 11:50 PM, Florian Weimer 
>> wrote:
>>> * Martin T.:
>>>
 Florian:

> Are the autonomous systems for the /19 and /24 connected directly?
 Yes they are.
>>> Then deaggregation really isn't necessary at all.
>>>
> (1) can be better from B's perspective because it prevents certain
> routing table optimizations (due to the lack of the covering prefix)
 What kind of routing table optimizations are possible if covering /19
 prefix is also present in global routing table?
>>> The /24 prefix could arguably be dropped and ignored for routing
>>> decisions.
>




signature.asc
Description: OpenPGP digital signature

Re: nexus N3K-C3064PQ vs juniper ex4500 in order to protect against ddos

[joel jaeggli]

On 9/30/16 12:42 PM, Pedro wrote:
> 
> Hello,
> 
> I have some idea to put switch before bgp router in order to terminate
> isp 10G uplinks on switch, not router. Main reason is that could be some
> kind of 1st level of defence against ddos, second reason, less
> important, save cost of router ports, do many port mirrors.

The distinction on cost of ports is somewhat germain when dealing with
things like span ports. maybe strictly speaking if the router platform
can handle line rate forwarding at minimum packet size it is just as
performant as the switch at both forwarding and probably acl application
(there are of course exceptions).  in general these switches has
substantially smaller port buffers then a router or high end l3 switch
platform (qfx10k or ptx for example) would have when spanning ports or
doing some statistical multiplexing. Which can be a liability.

A number of us no doubt use layer2/3 switches as customer aggregation or
indeed peering platforms. and suitability for such may depend on the mix
of hardware  and software features available as well as non-forwarding
attributes such as the amount of memory available. i have boxes for
example that have a full table rib but only default route for
non-customer routes. the prospects for gettting away with that sort of
thing with only 2GB of ram are growing increasingly dire.

So i would say this sort thing does work, and with some familiarity with
the platforms you become more comfortable with their limitations, but
it's not automatically the best route, and the additional bump in the
forwarding path is not free of costs or complexity.

> I think about N3K-C3064PQ or Juniper ex4500 because there are quite
> cheap and a lot of on Ebay.
> 
> I would like on nexus or juniper try use some feature:
> 
> -  limit udp, icmp, bum packets (bandwith,pps) at ingress tagged port or
> vlan
> -  create counters: passed and dropped packets, best way to get this
> counters via snmp oid, sent snmp traps, syslog etc in order to monitor
> or even as a action shut down port
> -  port mirror from many ports/vlans to multiple port (other anty ddos
> solutions)
> -  limited bgp but with flowspec to comunicate with another anty ddos
> devices
> 
> I'm also wondering how this feature above impact on cpu/whole switch. It
> can be some performance degradation ot all of this feature are done in
> hardware, with wirespeeed ? Which model will better to do this ?
> 
> Thanks for any advice,
> Pedro
> 
> ---
> Ta wiadomość została sprawdzona na obecność wirusów przez oprogramowanie
> antywirusowe Avast.
> https://www.avast.com/antivirus
> 
> 




signature.asc
Description: OpenPGP digital signature

Re: Providing transit to unallocated networks

[joel jaeggli]

On 9/27/16 5:46 PM, Alistair Mackenzie wrote:
> Thanks for this, it shows as
>
> apnic|ZZ|ipv4|103.***.***.0|1024|20160927|reserved||e-stats
>
> I expect this still stands with it being reserved?

 I'm not sure why you would bother obscuring it. What purpose does that
serve in furthering the discussion?

If it's not

route-views>show ip bgp 103.6.232.0/22
BGP routing table entry for 103.6.232.0/22, version 87113221
Paths: (1 available, best #1, table default)
  Not advertised to any peer
  Refresh Epoch 1
  3277 39710 20632 31133 58073
195.208.112.161 from 195.208.112.161 (194.85.4.4)
  Origin IGP, localpref 100, valid, external, best
  Community: 3277:39710 20632:65441 65535:65000
  rx pathid: 0, tx pathid: 0x0

What is it?

>
>
> William, it's 100% an apnic range and shows no org and is registered
> to the APNIC Hostmaster. This applies for both the ASN and the address
> space.
>
>
> On 28 September 2016 at 01:28, William Herrin  wrote:
>
>> On Tue, Sep 27, 2016 at 8:18 PM, Alistair Mackenzie  
>> wrote:
>>> I've come across a network which seem to be getting transit yet both the
>>> ASN and IP space is not allocated by the RIR.
>> Hi Alistair,
>>
>> There is still unicast address space that isn't allocated by any RIR?
>>
>> Seriously though, check all your bases. Is not the space unallocated
>> by all RIRs or just the one you expect to hold it?  If you have a
>> transit provider that's not playing by the rules, contact their
>> transit providers to complain and if you still don't get satisfaction,
>> I'd name and shame the lot of them. Failure to filter bad actors is
>> how prefix hijacking happens.
>>
>> Regards,
>> Bill Herrin
>>
>>
>>
>> --
>> William Herrin  her...@dirtside.com  b...@herrin.us
>> Owner, Dirtside Systems . Web: 
>>
>>
> On 28 September 2016 at 01:36, George Michaelson  wrote:
>
>> check if the block is in this file.
>>
>> http://labs.apnic.net/delegated-nro-extended
>>
>> If not, then the block is hijacked or being abused.
>>
>> the file format is a bit obscure: the ipv4 record is base-ip|hostcount
>> but converting that to prefix length is pretty simple.
>>
>> -G
>>
>> On Wed, Sep 28, 2016 at 10:18 AM, Alistair Mackenzie
>>  wrote:
>>> Hi,
>>>
>>> I've come across a network which seem to be getting transit yet both the
>>> ASN and IP space is not allocated by the RIR. It does appear at some
>> point
>>> that it was valid however this is no longer the case.
>>>
>>> The network is single homed and I tried asking the transit provider what
>>> their policy was on this but got no answer.
>>>
>>> Has anyone seen anything like this? What has happened in the past with
>>> things like this?
>>>
>>> Thanks,
>>> Alistair





signature.asc
Description: OpenPGP digital signature

Re: charges for prefix filter updates (was Re: Any ISPs using AS852 for IP Transit?)

[joel jaeggli]

On 9/15/16 11:28 AM, Ken Chase wrote:
> I feel this can be a public topic:
>
> Rogers just charged us that for an update (one update, multiple entries).
> We had to go through their quotation machinery too, took like 4-5 days. 
> Additional
> time was wasted because we contacted their tech dept directly at the start. 
> (which
> is what I do for all my other upstreams...)
>
> Kinda brutal.
Coordination problems are a point of high friction and cost for low
margin products. I generally prefer that my providers be able to
generate prefix filters on the basis of route objects, If it's not part
of their service offering; how costs are assigned for service requests
is going to be part of contract negotiions.

joel

> Cogent and HE nor NAC or Yipes or Tata ever did that to us.
>
> Nickle and diming -- why, cuz transit is a cheap commodity now, gotta make the
> cash somewhere?
>
> That said Cogent offered us a static /26 along side our BGP years ago then 
> warned
> us it'd be $50/mo or something for that # of ips going forward. We didnt need 
> it
> so dispensed with it.
>
> /kc
>
>
> On Thu, Sep 15, 2016 at 02:07:01PM -0400, Jason Lixfeld said:
>   >If there are any ISPs who use TELUS/AS852 for IP Transit over BGP, I???d 
> be interested in hearing from you.
>   >
>   >I???d like to compare notes to see if you are also paying $250 for each 
> BGP prefix filter updated request, or if we???re the only ones???
>   >
>   >Thanks in advance!
>




signature.asc
Description: OpenPGP digital signature

Re: CAIDA selected by FCC for internet performance measurement

[joel jaeggli]

On 8/12/16 1:41 PM, Scott Weeks wrote:
>
> --- s...@donelan.com wrote:
> From: Sean Donelan 
>
> CAIDA has submitted to the FCC its initial proposal for
> measuring internet interconnection point performance 
> metrics as part of the AT/DirecTV merger conditions.
>
> http://transition.fcc.gov/Daily_Releases/Daily_Business/2016/db0812/DA-16-909A1.pdf
> -
>
>
> I don't seem to be able to get the pdf referred to in the 
> above link to open correctly.
>
> https://ecfsapi.fcc.gov/file/108042516812991/MB%20Dkt%2014-90%20AT%20Inc.%20First%20Amended%20IME%20Report%20ECFS.PDF
opens fine in chrome created by Aspose.Pdf for .NET 10.2.0

> Anyone else get it to open?  I want to find out about 
> the methodology.
>
> scott
>
>

Re: akamai abnormal spike

[joel jaeggli]

On 7/18/16 4:57 PM, Mike Hammett wrote:
> Several of my WISP colleagues have noticed this behavior (CDN sending
> way more traffic than the customer's pipe can handle) from (I
> believe) multiple CDNs. Not sure if it is intention on behalf of the
> CDN or an error, but it has been on-going for several months if not
> years.

It's not a healthy tcp flow if the number of packets associated with the
flow stays well in excess of the link capacity for a while... if you
have recourse to to l4 header flags you might find that it was an ack
flood or repeated retramission of the same PDUs. Either way someones
state machine has a bug.

joel

> 
> 
> 
> - Mike Hammett Intelligent Computing Solutions 
> http://www.ics-il.com
> 
> 
> 
> Midwest Internet Exchange http://www.midwest-ix.com
> 
> 
> - Original Message -
> 
> From: "Blake Hudson"  To: nanog@nanog.org Sent:
> Monday, July 18, 2016 8:49:21 AM Subject: Re: akamai abnormal spike
> 
> We noticed that on the 12th-14th we had multiple subscribers on
> ~5Mbps subscription rates that were being sent ~50Mbps of data
> sourced from TCP port 80 (apparently HTTP) from Limelight Networks'
> servers. The data did appear to be user requested, still not sure why
> TCP didn't throttle the data rate appropriately. The 50Mbps was
> distributed across multiple LLNW servers. Makes me wonder if the
> customer was requesting one batch of data and multiple servers were
> responding.
> 
> The issue cleared up on its own and I never was able to perform a
> full packet capture to investigate. I have not noticed the same
> behavior from Akamai servers.
> 
> Clayton Zekelman wrote on 7/18/2016 8:26 AM:
>> 
>> 
>> We noticed on the 12th and 13th there was a significant up tick in
>>  traffic served from our Akamai servers as well.
>> 
>> 
>> At 05:37 PM 13/07/2016, eric c wrote:
>>> Good afternoon,
>>> 
>>> Has anyone notice any abnormal spike in Akamai trafic in the last
>>> 24-48 hours compared to other days. I know it was black tuesday
>>> yesterday but traffic from last month didn't even come close to
>>> what we saw from Akamai.
>>> 
>>> We have some caching servers and even notice a spike to them as
>>> well.
>>> 
>>> Limelight even showed up on our network.
>>> 
>>> thanks eric
>> 
> 
> 




signature.asc
Description: OpenPGP digital signature

Re: Real world power consumption of a 7604-S or 7606-S

[joel jaeggli]

On 6/27/16 5:35 PM, Eric Kuhnke wrote:
> Yes, very much agreed, part of the reason why I'm looking to do the
> watts per linecard calculation is to illustrate how it's not healthy
> except in certain places. As an edge aggregation device in a very
> small city in a rural western US state where the electricity is 6
> cents/kWh, the 24x7 load from a 7604 that eats 950W with supervisors
> and a 6724SFP linecard is not so terrible. In this case the colo
> space for a 42U rack is sometimes literally free.
> 
> In a IX point/datacenter/colocation environment where rack and power
> costs real money, not so much.

2 x ( 4 x 10Gig)  linecards is really as fast as it goes no over-subscribed.

It's been rather a long time or possibly never since that platform was
cutting edge on a PPS/Watt basis.

Today at roughly double the power consumpution per slot you can have
between 16 and 36 hundred gig ports or 48 x 10gig at half the power
consumption.


> 
> On Mon, Jun 27, 2016 at 5:26 PM, Tom Hill 
> wrote:
> 
>> On 28/06/16 00:26, Eric Kuhnke wrote:
>>> Example: 7604S chassis with dual 2700W DC power - chassis and
>>> fans use how much power? 2 x RSP720-3CXL at 310W each WS-X6704
>>> with DFC4 - ???W each
>> 
>> Way too much, is the simple answer.
>> 
>> I did have a 7604 (non-S) with the same PSUs, 1x SUP720-3BXL, 1x 
>> WS-X6724-SFP and 1x WS-X6708-3CXL was drawing near 2kW.
>> 
>> It's not healthy, please consider how much you'll spend in
>> electricity vs. something else. For example, the ASR9001 uses a 5th
>> of the power.
>> 
>> 
>> Cisco do also have a power calculator, too. It's conservative but
>> not overly so:
>> 
>> http://cpc.cloudapps.cisco.com/cpc/launch.jsp
>> 
>> -- Tom
>> 
> 




signature.asc
Description: OpenPGP digital signature

Re: Quick question regarding: Problematic IPv6 Multicast traffic within an IX.

[joel jaeggli]

On 6/24/16 9:27 AM, Bob Evans wrote:
> 
> Is it true that managed Layer2 switches used by IX's can not block IPv6
> multicast ingress port traffic from broadcasting to all ports ?

you can filter multicast destination addresses by acl.

NDP you kinda need since it replaces ARP

RA's you can and should filter (icmp6 type 134)

> ___Yes , seen many IXs with IPv6 multicast continuing yet IPv4 multicast
> is blocked.
> 
> ___No , All should be able to bock IPv6 multicast.
> 
> ___Only a few specific managed switch manufacturers have this issue with
> IPv6 multicast broadcasting.
> 
> You're knowledge on this problem would be helpful.
> 
> Thank You in advance.
> 
> Bob Evans
> CTO
> 
> 
> 
> 
> 
> 




signature.asc
Description: OpenPGP digital signature

Re: 1GE L3 aggregation

[joel jaeggli]

On 6/16/16 12:51 AM, Saku Ytti wrote:
> Hey,
> 
> I've been bit poking around trying to find reasonable option for 1GE
> L3 full BGP table aggregator. It seems vendors are mostly pushing
> Satellite/Fusion for this application.
> 
> I don't really like the added complexity and tight coupling
> Satellite/Fusion forces me. I'd prefer standards based routing
> redundancy to reduce impact of defects.
> 
> ASR9001 and MX104 are not an options, due to control-plane scale. New
> boxes in vendor pipeline are completely ignoring 1GE.
> 
> I've casually talked with other people, and it seems I'm not really
> alone here. My dream box would be 96xSFP + 2xQSFP28, with pretty much
> full edge features (BGP, LDP, ISIS, +1M FIB, +5M RIB, per-interface
> VLANs, ipfix or sflow, at least per-port QoS with shaper, martini
> pseudowires).
> 
> With tinfoil hat tightly fit on my head, I wonder why vendors are
> ignoring 1GE? Are business cases entirely driven now by Amazon,
> Google, Facebook and the likes? Are SP volumes so insignificant in
> comparison it does not make sense to produce boxes for them?
> Heck even 10GE is starting to become problematic, if your application
> is anything else than DC, because you can't choose arbitrary optics.

There's not a lot of innovation going on in lower end 1G chipsets. The
natural consequent of that is that you can build a high-end gig switch
or router around a chipset supporting 10Gb/s ports or feeds and speeds
your cogs are naturally going to be rather similar to the 10Gb/s offering.




signature.asc
Description: OpenPGP digital signature

Re: Link-local v6 and mobile phones

[joel jaeggli]

On 6/15/16 8:56 AM, Willy MANGA wrote:
> Hello,
> 
> a little question :)
> 
> For mobile operators using v6 on their networks, how do you manage
> link-local communication between mobile phones ?

the link local address is bound to eps bearer the other end of which is
the p-gw.

so it's a point-to-point link.

so you say what about the radio bearer?

there are two kinds, the srb where signalling is present, and the user
data which is associated with an eps databearer.

> While I understand it's layer 2 related,  am i able for example to make
> ping sweep and be able to communicate directly with other phone (customer) ?

appart from your nexthop, no.

> 




signature.asc
Description: OpenPGP digital signature

Re: Detecting Attacks

[joel jaeggli]

On 6/10/16 10:39 PM, subashini hariharan wrote:
> Hello,
> 
> I am Subashini, a graduate student. I am interested in doing my project in
> Network Security. I have a doubt related to it.
> 
> The aim is to detect DoS/DDoS attacks using the application. I am going to
> use ELK (ElasticSearch, Logstash, Kibanna) for processing the logs (Log
> Analytics).
> 
> My doubt is regarding how do we generate logs for detecting this attack? As
> I am new to this process, I am not sure about it.

lots of dos simply isn't targeting the application layer or even the
host especially. So, that stuff will rarely bubble up via syslog for
example until machines start to run into trouble. rather it will be
exposed via flow data or the frequent collection of interface counters.

> Also, if it is possible to do any other attacks similar to this, you can
> please give a hint about it.
> 
> Could anyone please help with this, it would be a great help!!
> 




signature.asc
Description: OpenPGP digital signature

Re: Netflix VPN detection - actual engineer needed

[joel jaeggli]

On 6/8/16 9:13 AM, Owen DeLong wrote:
> As of last week, I still wasn’t getting an IPv6 address by default on my 
> iPhone 6S+
> on T-Mobile.

turn off mobile hotspot...

> Just saying.
> 
> Owen
> 
>> On Jun 7, 2016, at 11:00 AM, Ca By  wrote:
>>
>> On Tuesday, June 7, 2016, Cryptographrix  wrote:
>>
>>> Very true - I was being a bit extremist out of frustration, but I think
>>> you're spot on - he.net tunnels and even 6to4 are toys to provide IPv6
>>> support, not actually IPv6 support.
>>>
>>> And I'm quite frustrated because there's so little actual v6 support, and
>>> I *do* actually need it on a daily basis for work.
>>>
>>> Because there's no actual ISP IPv6 support anywhere else (in parts of the
>>> US that *have* multiple ISPs), you can't even make the case to your ISP
>>> that it's a legitimate requirement for you because they know you're not
>>> really going to get v6 elsewhere.
>>>
>>>
>> I think we have different definitions of "no actual isp ipv6 support"
>>
>> Again, a helpful akamai blog
>> https://blogs.akamai.com/2016/06/four-years-since-world-ipv6-launch-entering-the-mainstream.html
>>
>> fixed line: Comcast, AT, TWC, just to name the largest in the nation have
>> meaningful deployments of ipv6. The only thing holding back greater
>> deployment for those networks are legacy CPE that will age out slowly.
>>
>> All 4 of the national mobile operator have ipv6 default on for most
>> new phone models.
>>
>> Yes, many gaps to fill still. But, on "my network" with shy of 70 million
>> users, everything has ipv6 except the iPhone, and that will change RSN. And
>> for users with v6, the majority of their traffic is ipv6 e2e since the
>> whales (google, fb, netflix, increasingly Akamai) are dual stack.
>>
>> CB
>>
>>
>>>
>>>
>>> On Tue, Jun 7, 2016 at 10:22 AM Ca By >> > wrote:
>>>


 On Tuesday, June 7, 2016, Cryptographrix > wrote:

> As I said to Netflix's tech support - if they advocate for people to turn
> off IPv6 on their end, maybe Netflix should stop supporting it on their
> end.
>
> It's in the air whether it's just an HE tunnel issue or an IPv6 issue at
> the moment, and if their tech support is telling people to turn off IPv6,
> maybe they should just instead remove their  records.
>
> (or fail back to ipv4 when v6 looks like a tunnel)
>
>
 I think you need to reset your expectations of a free tunnel service.

 he.net tunnels are a toy for geeks looking to play with v6. In terms of
 Netflix subcriber base, it is amazing insignificant number of users.

 At the end of the day, anonymous tunnels, just like linux, are not
 supported by Netflix. And, he.net tunnel users are hurting ipv6 overall
 just like 6to4 by injecting FUD and other nonesense complexity For a
 toy.

 Move on to a real issue instead of beating this dead horse.

 CB


>
>
> On Tue, Jun 7, 2016 at 9:22 AM Mark Felder  wrote:
>
>>
>>> On Jun 6, 2016, at 22:25, Spencer Ryan  wrote:
>>>
>>> The tunnelbroker service acts exactly like a VPN. It allows you,
> from any
>>> arbitrary location in the world with an IPv4 address, to bring
> traffic
>> out
>>> via one of HE's 4 POP's, while completely masking your actual
> location.
>>>
>>
>> Perhaps Netflix should automatically block any connection that's not
> from
>> a known residential ISP or mobile ISP as anything else could be a
> server
>> someone is proxying through. It's very easy to get these subnets -- the
>> spam filtering folks have these subnets well documented. /s
>>
>> --
>>  Mark Felder
>>  f...@feld.me
>>
>>
>

> 
> 




signature.asc
Description: OpenPGP digital signature

Re: Netflix VPN detection - actual engineer needed

[joel jaeggli]

On 6/7/16 6:55 AM, Cryptographrix wrote:
> As I said to Netflix's tech support - if they advocate for people to turn
> off IPv6 on their end, maybe Netflix should stop supporting it on their end.
> 
> It's in the air whether it's just an HE tunnel issue or an IPv6 issue at
> the moment, and if their tech support is telling people to turn off IPv6,
> maybe they should just instead remove their  records.

it clearly works with prefixes delegated from other isps.
...
http://i.imgur.com/sJUM7tn.png

> (or fail back to ipv4 when v6 looks like a tunnel)
> 
> 
> 
> On Tue, Jun 7, 2016 at 9:22 AM Mark Felder  wrote:
> 
>>
>>> On Jun 6, 2016, at 22:25, Spencer Ryan  wrote:
>>>
>>> The tunnelbroker service acts exactly like a VPN. It allows you, from any
>>> arbitrary location in the world with an IPv4 address, to bring traffic
>> out
>>> via one of HE's 4 POP's, while completely masking your actual location.
>>>
>>
>> Perhaps Netflix should automatically block any connection that's not from
>> a known residential ISP or mobile ISP as anything else could be a server
>> someone is proxying through. It's very easy to get these subnets -- the
>> spam filtering folks have these subnets well documented. /s
>>
>> --
>>   Mark Felder
>>   f...@feld.me
>>
>>
> 




signature.asc
Description: OpenPGP digital signature

Re: Netflix VPN detection - actual engineer needed

[joel jaeggli]

On 6/5/16 6:23 PM, Josh Reynolds wrote:
> Uhm, what? Where do you think ISPs get their transit exactly?

They buy from 2 or more wholesale transit providers and in general they
opportunistically peer, although scale helps a lot there.

> On Jun 5, 2016 8:17 PM, "joel jaeggli" <joe...@bogus.com
> <mailto:joe...@bogus.com>> wrote:
> 
> HE's downstream cone does not include a whole lot of residential ISPs.
> if you further exclude the ones that are multihomed you're left with a
> pretty small subset. that said they (HE) can be and are a valuable peer
> both in v4 and v6.
> 
> Personally I wouldn't single home to anything that looks tier-1ish but
> your mileage may vary the residential operators I look  at tend to be
> fairly diversly connected.
> 
> On 6/3/16 5:46 PM, Josh Reynolds wrote:
> > You might be one of a handful.
> > On Jun 3, 2016 7:35 PM, "Gary E. Miller" <g...@rellim.com
> <mailto:g...@rellim.com>> wrote:
> >
> >> Yo Spencer!
> >>
> >> On Fri, 3 Jun 2016 20:13:03 -0400
> >> Spencer Ryan <sr...@arbor.net <mailto:sr...@arbor.net>> wrote:
> >>
> >>> Yes but HE doesn't serve residential users directly.
> >>
> >> Really?  I am the only one?  Doubtful.
> >>
> >> RGDS
> >> GARY
> >>
> 
> ---
> >> Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
> >> g...@rellim.com <mailto:g...@rellim.com>  Tel:+1 541 382
> 8588 <tel:%2B1%20541%20382%208588>
> >>
> >
> 
> 




signature.asc
Description: OpenPGP digital signature

Re: Netflix VPN detection - actual engineer needed

[joel jaeggli]

HE's downstream cone does not include a whole lot of residential ISPs.
if you further exclude the ones that are multihomed you're left with a
pretty small subset. that said they (HE) can be and are a valuable peer
both in v4 and v6.

Personally I wouldn't single home to anything that looks tier-1ish but
your mileage may vary the residential operators I look  at tend to be
fairly diversly connected.

On 6/3/16 5:46 PM, Josh Reynolds wrote:
> You might be one of a handful.
> On Jun 3, 2016 7:35 PM, "Gary E. Miller"  wrote:
> 
>> Yo Spencer!
>>
>> On Fri, 3 Jun 2016 20:13:03 -0400
>> Spencer Ryan  wrote:
>>
>>> Yes but HE doesn't serve residential users directly.
>>
>> Really?  I am the only one?  Doubtful.
>>
>> RGDS
>> GARY
>> ---
>> Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
>> g...@rellim.com  Tel:+1 541 382 8588
>>
> 




signature.asc
Description: OpenPGP digital signature

Re: Cost-effectivenesss of highly-accurate clocks for NTP

[joel jaeggli]

On 5/15/16 10:05 AM, Eric S. Raymond wrote:
> Mel Beckman :
>> The upshot is that there are many real-world situations where
>> expensive clock discipline is needed. But IT isn't, I don't think,
>> one of them, with the exception of private SONET networks (fast
>> disappearing in the face of metro Ethernet).
> 
> Thank you, that was very interesting information.  I'm not used to thinking
> of IT as a relatively low-challenge environment!
> 
> You're implicitly suggesting there might be a technical case for
> replacing these T1/T3 trunks with some kind of VOIP provisioning less
> dependent on accurate time synch.  Do you think that's true?

APCO  and TETRA trunked radio  are mature systems, they do carry data,
but are somewhat lower bandwidth. Being TDM they are dependent on
accurate clocks.

LTE systems are used or envisioned being used for high bandwidth
applications.

> 




signature.asc
Description: OpenPGP digital signature

Re: Latency, TCP ACKs and upload needs

[joel jaeggli]

On 4/19/16 6:29 PM, Jean-Francois Mezei wrote:
> As part of the ongoing CRTC hearings, the incumbents' claim that
> continued implementation of the current 5/1 standard would make Canada a
> world leader for broadband in the future.
> 
> A satellite company who currently can't even deliver its advertised 5/1
> now brags its next satellite will deliver 25/1.
> 
> So I have a few questions:
> 
> Considering a single download TCP connection. I am aware that modern TCP
> stacks will rationalize ACKs and send 1 ACK for every x packets
> received, thus reducing upload bandwidth requirements. Is this basically
> widespread and assumed that everyone has that ?

with an mss of 1460 the inbound packets for reasonably well packed flow
will be 36.5x larger than the acks which are 40 bytes.

sack rfc 2018 means you don't have to acknowledge all of the inbound
packets.

> Also, as you split available bandwidth between multiple streams, won't
> ack upload requirements increase because ACK rationalisation happens far
> less often sicne each TCP connection has its own context for ACKs?
> 
> When one considers the added latency of satellite links, does 25/1 make
> sense ?  (I need a sanity check to distinguish between marketing spin
> presented to the regulator and real life)

satellite vendors use various forms of tcp acceleration  which may
involve among other things having middle boxes that pre-emptively send
the ack, play with the window size etc.

> I noticed that in the USA, EXEDE Satellite advertises 12/3 plans and
> they are also on a VIA Sat satellite, presumably the same vehicle that
> Xplornet tries to deliver its measly 5/1 on. Would all beams be
> identical on a satellite or can they be configured differently with a
> ISP adjustable rate of upload/download inside the same spectrum ?
> 
> 
> 
> 
> Also, when you establish a TCP connection, do most stacks have a default
> window size that gives the sender enough "patience" to wait long enough
> for the ACK ?

retransmission timeouts are typically measure in seconds...

https://tools.ietf.org/html/rfc6298

and geostationary orbits typically have RTTs under 800ms.

> If sender sends packet 457, doesn't get ACK in time and resends 457,
> doesn't that also result in reduction in window size (the very opposite
> of what would be needed in high latency links) ?
> 
> And when the first ACK finally arrives, won't the sender assume this ACK
> was for the resent 457 ?   Or is satellite latency low enough that
> stacks all have enough default "patience" to wait for ACKs and this is a
> non issue ?
> 
> (Note Xplornet refused to answer questions on whether they operate
> special proxies at their gound stations to manage TCP connections to
> appear "close").

seems likely

> 
> 
> What i am trying to get at here is whether 25/1 on satellite, in real
> life with a few apps exchanging data, would actually be able to make use
> of the 25 download speed or whether the limited 1mbps upload would choke
> the downloads ?
> 




signature.asc
Description: OpenPGP digital signature

Re: Best practices for sending network maintenance notifications

[joel jaeggli]

On 4/6/16 3:56 PM, Dan Mahoney, System Admin wrote:
> All,
> 
> We recently, at $dayjob, had one of our peers (at Symantec)  send out a
> network maint notification, putting 70 addresses in the "To:" field,
> rather than using BCC or the exchange's mailing list.
> 
> Naturally, when you mail 30 addresses, of the forms peering@ and noc@
> various organizations, you're likely to hit at least a few
> autoresponders and ticket systems...
> 
> And at least one or two of those autoresponders are of course brainded
> and configured to reply-all.  (In this case, Verizon's ServiceNow setup
> was such a stupid responder).  And that made things fun in our own
> ticket system, as our RT setup happily created a bunch of tickets.
> 
> My question for the group -- does anyone know if there's a "best
> practices" for sending maint notifications like this?  An RFC sort of
> thing?


In general I'd push for a little automation for the sending of
notifications as reducing the likelihood of mishap.

Targeting bcc is nice, but so does simply generating a message for each
peer precludes this. we store contact information which bgp neighbor
parameters in our config generation.

> While it would define a social protocol, rather than a truly technical
> one, if there's not such a document, it seems like it could useful.  And
> once such a thing exists, exchanges could of course helpfully point
> their members AT it (for both their humans, and ticket systems, to follow).
> 
> -Dan
> 




signature.asc
Description: OpenPGP digital signature

Re: Some doubts on large scale BGP/AS design and black hole routing risk

[joel jaeggli]

On 4/4/16 10:29 AM, magicb...@hotmail.com wrote:
> Hi guys
> 
> thanks  everyone for your replies.
> 
> I'd like to highlight this concept that Christopher gave before:
> 
> ​"different providers, different entrance facilities in the building(s),
> different conduits out of the area... "
> 
> How can we get this in this world where everyone is moving to big Data
> Center / Colo-Hosters.In this kind of colo providers, you usually
> have a Meet-Me-Room or similar (which is a single point of failure) and
> no control on how you're actually connected with your peers

Sometimes you have two or more MMRs sometimes providers are only one one
or another.

The actual discipline here is delivering reliable cost-effective service
with unreliable components...

> Cheers.
> 
> 
> On 04/04/16 15:07, Mark Tinka wrote:
>> nights to fixing the backhaul.
> 
> 




signature.asc
Description: OpenPGP digital signature

Re: Microwave link capacity

[joel jaeggli]

On 4/4/16 2:28 PM, Jean-Francois Mezei wrote:
> 
> In a context of providing rural communities with modern broadband.
> 
> Reading some tells me that Microwave links can be raised to 1gbps. How
> common is that ?

for wireless backhaul of cell-towers, some wisp infrastructure and for
this like inter-building point-to-point connectivity. pretty common.

> I assume that cell phone towers have modern microwave links (when not
> directly on fibre). What sort of capacity would typically be provided ?

an example would be something like

http://www.dragonwaveinc.com/solutions/mobile-backhaul

> And in the case of a remote village/town served by microwave originally
> designed to handle just phone calls, how difficult/expensive is it to
> upgrade to 1gbps or higher capacity ?

well if you're describing at longlines or bell canada C-band microwave
relay networks those were built a time when cost was not the primary
consideration, (e.g. there were not signficant alternatives in the 1950s
to 1970s)

>  Just a change of radio ? or radio
> and antenna, keeping only the tower ?

modern radios are dramatically cheaper. use of unii bands or licensed
spectrum are options, distance  and spectrum choices tends to dominate
the set of considerations that goes into selecting a system.

examples of unlicensed being something like

https://www.ubnt.com/airfiber/airfiber24-hd/

https://www.ubnt.com/airfiber/airfiber5/



> (keeping spectrum acquisition out of discussion as that is a whole other
> ball game).
> 




signature.asc
Description: OpenPGP digital signature

Re: Wireless (WiFi) MOS equivalent?

[joel jaeggli]

On 3/20/16 12:34 PM, Jared Mauch wrote:
> I've seen some conferences do a virtual participant device that joins the 
> wifi and reports back data. 

netbeez is an example of one such device.

https://netbeez.net

> Jared Mauch
> 
>> On Mar 16, 2016, at 1:54 PM, Jim Wininger  wrote:
>>
>> Hello all,
>>
>> Is there a WiFi equivalent to the VoIP MOS score?
>>
>> We are looking for a way to measure performance of a fairly large WiFi 
>> deployment.
>>
>> We have 8000+ access points (All Cisco). WE have the standard Cisco tools 
>> for managing the wireless network (ISE, Prime etc). But we are coming up 
>> short with a way to “score” the network.
>>
>> Does anyone have experience with this that might be able to help? How do 
>> large conferences “measure” wireless service quality etc? We are already 
>> doing end user surveys etc. We have “soft date”, we really need data points.
>>
>> —Jim
> 
> 




signature.asc
Description: OpenPGP digital signature

Re: Cogent - Google - HE Fun

[joel jaeggli]

On 3/13/16 7:31 AM, Dennis Burgess wrote:
> In the end, google has made a choice. I think these kinds of choices will 
> delay IPv6 adoption.  

Given that they publish  records for a great deal of their services
I'm not sure how you would conclude that.

> -Original Message-
> From: Damien Burke [mailto:dam...@supremebytes.com] 
> Sent: Friday, March 11, 2016 2:51 PM
> To: Mark Tinka ; Owen DeLong ; Dennis 
> Burgess 
> Cc: North American Network Operators' Group 
> Subject: RE: Cogent - Google - HE Fun
> 
> Just received an updated statement from cogent support:
> 
> "We appreciate your concerns. This is a known issue that originates with 
> Google as it is up to their discretion as to how they announce routes to us 
> v4 or v6. 
> 
> Once again, apologies for any inconvenience."
> 
> And:
> 
> "The SLA does not cover route transit beyond our network. We cannot route to 
> IPs that are not announced to us by the IP owner, directly or through a 
> network peer."
> 
> 




signature.asc
Description: OpenPGP digital signature

Re: Internet Exchanges supporting jumbo frames?

[joel jaeggli]

On 3/9/16 7:58 AM, Mikael Abrahamsson wrote:
> On Wed, 9 Mar 2016, Nick Hilliard wrote:
> 
>> used.  Some will want 9000, some 9200, others 4470 and some people
> 
> I have a strong opinion for jumboframes=9180bytes (IPv4/IPv6 MTU),
> partly because there are two standards referencing this size (RFC 1209
> and 1626), and also because all major core router vendors support this
> size now that Juniper has decided (after some pushing) to start
> supporting it in more recent software on all their major platforms
> (before that they had too low L2 MTU to be able to support 9180 L3 MTU).
> 
> In order to deploy this to end systems, I however thing we're going to
> need something like
> https://tools.ietf.org/html/draft-van-beijnum-multi-mtu-04 to make this
> work on mixed-MTU LANs. The whole thing about PMTUD blackhole detection
> is also going to be needed, so hosts try lower PMTU in case larger
> packets are dropped because of L2 misconfiguration in networks.
> 
> With IPv6 we have the chance to make PMTUD work properly and also have

The prospects for that seem relatively dire. of course whats being
discussed here is the mixed L2 case, where the device will probably not
sent icmp6 ptb anyway but rather simply discard the packet as a giant.

> PMTU blackhole detection implemented in all hosts. IPv4 is lost cause in
> my opinion (although it's strange how many hosts that seem to get away
> with 1492 (or is it 1496) MTU because they're using PPPoE).

if your adv_mss is set accordingly you can get away with
 a lot.
> 




signature.asc
Description: OpenPGP digital signature

Re: remote serial console (IP to Serial)

[joel jaeggli]

On 3/8/16 10:06 AM, Stephen Satchell wrote:
> On 03/08/2016 07:30 AM, greg whynott wrote:
>>   I'd like to purchase a IP to
>> Serial port device I can use for each location in the event I lock myself
>> out.   The requirement would be an Ethernet port,  a serial port,  and
>> SSH.
> 
> I've used Cisco 2500 routers for this type of service, using the AUX
> port and a roll-over cable to connect to the target device.  I'm talking
> 2501s mostly, not the 2511 or 2508, unless you need to control more than
> one device at a specific location.
> 
> Ethernet, AUX port, SSH, firewall.  Updates are sketchy, but these are
> mature devices.

We use the small opengears for small sites acm5500 for ethernet and serial.

Used to use cisco 25xx 26xx but those are long in the tooth and not
fast. stopped using  avocent because of the value proposition.

I have experimented with raspberry pi for smaller oob server (with
appropriate usb serial breakout ) e.g. digi edgeport box for 8 serials
or ftdi usb serial adapters rather tha stand-alone pc which is what we
use for larger oob/utility server/router. it's considerably smaller than
the rackable equivalent.





signature.asc
Description: OpenPGP digital signature

Re: Sprint Wireless DNS server not resolving ietf.org

[joel jaeggli]

On 2/26/16 5:42 PM, Yang Yu wrote:
> ietf.org and its subdomains such as tools.ietf.org are not accessible
> on Sprint 3G/LTE (DNS timeout). From what I gathered this is affecting
> Sprint wireless customers nationwide. I created a DNS measurement on
> ripe atlas and no signs of other carriers experiencing the same issue.

ietf.org has physically diverse secondaries so it strikes me as unlikely
that this problem is outside sprint

ietf.org.   86400   IN  NS  ns0.amsl.com.
ietf.org.   86400   IN  NS  ns1.ams1.afilias-nst.info.
ietf.org.   86400   IN  NS  ns1.mia1.afilias-nst.info.
ietf.org.   86400   IN  NS  ns1.sea1.afilias-nst.info.
ietf.org.   86400   IN  NS  ns1.hkg1.afilias-nst.info.
ietf.org.   86400   IN  NS  ns1.yyz1.afilias-nst.info.


> Emailed Sprint NOC and opened a ticket via support channel, got no
> update. Is there someone from Sprint Wireless on this list?
> 
> DNS servers
> 68.28.169.132
> 68.28.168.132
> 
> Thanks.
> 
> 
> Yang
> 




signature.asc
Description: OpenPGP digital signature

Re: Dear Windstream engineers

[joel jaeggli]

On 1/30/16 2:29 PM, Matthew D. Hardeman wrote:
> You offer this service to your customers, don’t you?   ;-)

source based RTBH requires urpf, which while generally available may
have practical limitations on implementation.

> Seriously, it’s a good question.  Most IP transit providers offering BGP 
> services do offer RTBH.
> 
>> On Jan 29, 2016, at 10:51 PM, George Skorup  wrote:
>>
>> Why doesn't Windstream have RTBH for their BGP customers? It cannot be 
>> impossible to implement.
> 




signature.asc
Description: OpenPGP digital signature