Re: BGP in a containers

[Scott Whyte]

On 6/14/18 11:56 AM, james jones wrote:

I am working on an personal experiment and was wondering what is the best
option for running BGP in a docker base container. I have seen a lot blogs
and docs referencing Quagga. I just want to make sure I am not over looking
any other options before I dive in. Any thoughts or suggestions?


https://docs.cumulusnetworks.com/display/HOSTPACK/Configuring+FRRouting+on+the+Host



-James

Re: Segment Routing

[Scott Whyte]

On 5/22/18 7:04 AM, steve ulrich wrote:

fwiw - there's a potentially significant loss of visibility w/SR from a
traffic management perspective depending on how it's deployed.  though, i
doubt the OP is really driving at this point.

the data plane behavior on LDP is swap oriented, while the data plane on SR
is pop oriented.  depending on the hardware capabilities in use this may
have (subtle) traffic engineering or diagnostic implications at a minimum.
folks will likely have to build tooling to address this.

we're pushing the bubble of complexity around.


Moving the complexity to where it scales better is a win all by itself.



On Tue, May 22, 2018 at 8:47 AM Saku Ytti  wrote:


On 22 May 2018 at 11:19, Matt Geary  wrote:


really seeing the value of SR to replace LDP on my backbone. With some
scripting and lots of software tools I can make it just like LDP, but

why?

So break the ease of LDP just to get label switching on my hub core not
really seeing it, unless someone has done it and they are seeing the

value.

Can you elaborate what scripting and software tools are needed? If you'd
talk
about RSVP particularly AutoBW and SR, then yeah, but SR on itself should
be less of a chore than LDP.

SR is what MPLS was intended to be day1, it just wasn't very marketable
idea
to sell MPLS and sell need for changing all the IGPs as well.
LDP is added state, added signalling, added complexity with reduced
visibility.
SR is like full-mesh LDP (everyone has everyone's label POV), while also
removing one protocol entirely.

--
   ++ytti

Re: Network traffic simulator

[Scott Whyte]

On 5/24/16 05:17, Mitchell Lewis wrote:

Hi,I am looking to validate the performance specs of a core router. I am 
looking for a network traffic simulator which can simulate 40 gbps of traffic. 
I am looking for a simulator with sfp+ ports.
I am interested in any input as to brands to look at, build one myself etc.


If you want DYI check out http://osnt.org/


Thanks,Mitchell

Re: NIST NTP servers

[Scott Whyte]

On 5/10/16 21:05, Joe Klein wrote:

Is this group aware of the incident with tock.usno.navy.mil &
tick.usno.navy.mil on November 19. 2012 2107 UTC, when the systems lost 12
years for the period of one hour, then return?

The reasons were not fully explained, but the impact was global. Routers,
switches, power grids, phone systems, certificates, encryption, Kerberos,
logging and any tightly coupled transaction systems were impacted.

So I began doing 'security research' on the topic (don't confuse me with
joe hacker), and discovered both interesting and terrifying issues, which I
will not disclose on an open forum.

Needless to say, my suggestions are:
1. Configure a trusted time source and good time stratum architecture for
your organization.
2. When identifying your source of time, the majority of the technologies
can be DDOS'ed, spoofed or MITM, so consider using redundant sources and
authentication.
3. For distribution of time information inside your organization, ensure
your critical systems (Encryption, PKI, transactions, etc) are using your
redundant sources and authentication.
4. Operating systems, programming languages, libraries, and applications
are sensitive to time changes and can fail in unexpected ways. Test them
before it's too late.
5. Disallow internal system to seek NTP from other sources beyond your edge
routers.
I believe this will become a stronger need over time, and apply to more 
than NTP: 
http://arstechnica.com/security/2016/02/using-ipv6-with-linux-youve-likely-been-visited-by-shodan-and-other-scanners/

6. All core time systems should be monitored by your security team or SOC.

One question, is this a topic anyone would find interested at a future
NANOG? Something like "Hacking and Defending time?".


Joe Klein
"Inveniam viam aut faciam"

PGP Fingerprint: 295E 2691 F377 C87D 2841 00C1 4174 FEDF 8ECF 0CC8

On Tue, May 10, 2016 at 9:59 PM, Mel Beckman  wrote:


I don't pretend to know all the ways a hacker can find out what nap
servers a company uses, but I can envision a virus that could do that once
behind a firewall. Every ntp response lists the current reference ntp
server in the next higher stratum. There are many ways that process could
harvest all ntp servers over time, and then pass the public IP back to a
mother ship controller. It could be going on right now.

My point is, when the fix is so cheap, why put up with this risk at all?

  -mel beckman


On May 10, 2016, at 5:18 PM, Chris Adams  wrote:

Once upon a time, Mel Beckman  said:

Boss: So how did a hacker get in and crash our accounting server, break

our VPNs, and kill our network performance?

IT guy: He changed our clocks.

So, this has been repeated several times (with how bad things will go if
your clocks get changed by years).  It isn't that easy.

First, out of the box, if you use the public pool servers (default
config), you'll typically get 4 random (more or less) servers from the
pool.  There are a bunch, so Joe Random Hacker isn't going to have a
high chance of guessing the servers your system is using.

Second, he'd have to guess at least three to "win".

Third, at best, he'd only be able to change your clocks a little; the
common software won't step the clock more than IIRC 15 minutes.  Yes,
that can cause problems, but not the catastrophes of years in the future
or Jan 1, 1970 mentioned in this thread.

Is it possible to cause problems?  Yes.  Is it a practical attack?  I'm
not so sure, and I haven't seen proof to the contrary.
--
Chris Adams 

Re: ICYMI: FBI looking into LA fiber cuts, Super Bowl

[Scott Whyte]

On 1/20/16 08:25, Naslund, Steve wrote:

Helicopters near the Super Bowl are cleared to be there and are flown by vetted 
professional pilots.  A human pilot in a helicopter presumably has some kind of 
qualification to be there while a drone (although I don't like that word) could be flown 
by any moron with a couple hundred bucks.  I also think the government is going 
completely overboard with the "drone threat" but in the case of the Super Bowl, 
there should definitely be a reasonable restriction on drone flights, ANY flight for that 
matter.  I think reasonable drone pilots would agree with that.
Can't wait for autonomous drones in the $50 range.  And the autonomous 
counter-drones.


Steven Naslund
Chicago IL
  


-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of 
valdis.kletni...@vt.edu
Sent: Wednesday, January 20, 2016 9:46 AM
To: Rafael Possamai
Cc: nanog@nanog.org
Subject: Re: ICYMI: FBI looking into LA fiber cuts, Super Bowl

On Tue, 19 Jan 2016 15:41:31 -0600, Rafael Possamai said:

I fail to see how drones relate to fiber cuts and the superbowl. Did
the article author just throw that in there? The news helicopter
getting aerial footage also poses a risk, so not sure what's special about 
drones.

Drones don't cost $200 per hour to keep in the air, and they're not as obvious 
as a helicopter.  So it becomes a lot easier to get in there and grab some 
unauthorized video

Re: Drops in Core

[Scott Whyte]

On 8/15/15 09:47, Glen Kent wrote:

Hi,

Is it fair to say that most traffic drops happen in the access layers, or
the first and the last miles, and the % of packet drops in the core are
minimal? So, if the packet has made it past the first mile and has
entered the core then chances are high that the packet will safely get
across till the exit in the core. Sure once it gets off the core, then all
bets are off on whether it will get dropped or not. However, the key point
is that the core usually does not drop too many packets - the probability
of drops are highest in the access side.


What do these terms mean in a world where my EC2 VM talks to my GCE VM? 
 It doesn't seem unreasonable that the DC bandwidth on either end 
dwarfs the core capacity between the two.




Is this correct?

Glen

Re: ARIN just subdivided their last /17, /18, /19, /20, /21 and /22. Down to only /23s and /24s now. : ipv6

[Scott Whyte]

On 6/29/15 20:17, Johnny Eriksson wrote:

Javier Henderson jav...@kjsl.org wrote:


Or XNS.  On the other hand, people did have a nice career with

SNA...but they weren't trying to push packets over the

LAT


.daytime
Monday 29-Jun-2015 20:10:46

.pjob
Job 3 at ODEN   User BYGG   [10,335]   TTY4

.where tty4
LAT PC78(LATD for FreeBSD) TTY4

Is there anyting wrong with LAT?


err, its been awhile.  Doesn't LAT have a 1 sec timeout that's not 
configurable?





-jav


--Johnny

Re: Youtube / IPv6 / Netherlands

[Scott Whyte]

On 6/25/15 07:49, Jared Mauch wrote:



On Jun 25, 2015, at 10:08 AM, Phil Rosenthal p...@isprime.com wrote:



On Jun 25, 2015, at 9:32 AM, Christopher Morrow morrowc.li...@gmail.com wrote:

geolocation is hard :(


If you would like to see how Google has your geolocation set, check:
curl http://redirector.c.youtube.com/report_mapping

You might want to force it both IPv4 and IPv6 to see if there is any difference.



And run it a few times, because it may think your IP in asia is in Amsterdam, 
etc..

[jared@eng0 ~]$ curl -4 http://redirector.c.youtube.com/report_mapping
203.105.73.114 = ams09x03 : superx_isp_number: 8 (203.105.64.0/20) [s]
[jared@eng0 ~]$ curl -4 http://redirector.c.youtube.com/report_mapping
203.105.73.114 = sjc07x04 : superx_isp_number: 1 (203.105.64.0/20) [u]


Maybe its actually telling you where youtube is serving videos from for 
that IP address, in realtime, based on a large number of variables only 
one of which is where on the Earth that IP might be located.




- Jared

Re: Android (lack of) support for DHCPv6

[Scott Whyte]

On 6/10/15 08:36, Jeff McAdams wrote:

There is no
other rational way to interpret your statement than to be a statement
of Google's position.



False dichotomies suck.

Re: A Canonical answer requested (AS41231)

[Scott Whyte]

Would a prototypical neteng suffice?

On 5/18/15 13:48, Christopher Morrow wrote:

if there's a canonical neteng/ops person around it'd be handy to get a
contact off-list :) I have a question to ask... about bgp and paths
and fun stuff such as that!

(probably a traceroute or 'show ip bgp' would suffice from their perspective)

-chris

Re: link avoidance

[Scott Whyte]

On 5/6/15 15:56, Randy Bush wrote:

a fellow researcher wants

  to make the case that in some scenarios it is very important for a
  network operator to be able to specify that traffic should *not*
  traverse a certain switch/link/group of switches/group of links
  (that's true right?). Could you give some examples? Perhaps point
  me to relevant references?

if so, why? security?  congestion?  other?  but is it common?  and, if
so, how do you do it?


My experience has been with MPLS overlays.

Availability: During maintenance windows, moving high-value traffic away 
from potential outages while keeping the tunnels full of BE; manually 
manipulating MPLS tunnel affinities (though this could be automated 
fairly easily).


Congestion: Whenever traffic load spikes past a threshold; 
diffserv-aware TE to prevent certain classes of traffic from routing 
over links with limited bandwidth, handled automatically via auto-bw.


Preventing non-optimal tunnel paths.  No transoceanic trombones, 
please; MPLS link affinities designed into the network.


-Scott

Re: Peering and Network Cost

[Scott Whyte]

On 4/15/15 07:28, Rod Beck wrote:

Hi,


As you all know, transit costs in the wholesale market today a few
percent of what it did in 2000. I assume that most of that decline is
due to a modified version of Moore's Law (I don't believe optics
costs decline 50% every 18 months) and the advent of maverick players
like Cogent that broker cozy oligopoly pricing.


But I also wondering whether the advent of widespread peering
(promiscuous?) among the Tier 2 players (buy transit and peer) has
played a role. In 2000 peering was still an exclusive club and in
contrast today Tier 2 players often have hundreds of peers. Peering
should reduce costs and also demand in the wholesale IP market.
Supply increases and demand falls.


You might find 
https://www.nanog.org/meetings/nanog53/presentations/Tuesday/valancius.pdf 
and the concomitant 
http://conferences.sigcomm.org/sigcomm/2011/papers/sigcomm/p194.pdf 
interesting.


-Scot




I thank you in advance for any insights.


Regards,


- R.


Roderick Beck Sales Director/Europe and the Americas Hibernia
Networks

This e-mail and any attachments thereto is intended only for use by
the addressee(s) named herein and may be proprietary and/or legally
privileged. If you are not the intended recipient of this e-mail, you
are hereby notified that any dissemination, distribution or copying
of this email, and any attachments thereto, without the prior written
permission of the sender is strictly prohibited. If you receive this
e-mail in error, please immediately telephone or e-mail the sender
and permanently delete the original copy and any copy of this e-mail,
and any printout thereof. All documents, contracts or agreements
referred or attached to this e-mail are SUBJECT TO CONTRACT. The
contents of an attachment to this e-mail may contain software viruses
that could damage your own computer system. While Hibernia Networks
has taken every reasonable precaution to minimize this risk, we
cannot accept liability for any damage that you sustain as a result
of software viruses. You should carry out your own virus checks
before opening any attachment.

What happened to Schprokits?

[Scott Whyte]

Schprokits was mentioned at NANOG63 but http://www.schprokits.com/ 
doesn't look too good.


What happened?

Re: scaling linux-based router hardware recommendations

[Scott Whyte]

On 1/26/15 14:53, micah anderson wrote:

Hi,

I know that specially programmed ASICs on dedicated hardware like Cisco,
Juniper, etc. are going to always outperform a general purpose server
running gnu/linux, *bsd... but I find the idea of trying to use
proprietary, NSA-backdoored devices difficult to accept, especially when
I don't have the budget for it.

I've noticed that even with a relatively modern system (supermicro with
a 4 core 1265LV2 CPU, with a 9MB cache, Intel E1G44HTBLK Server
adapters, and 16gig of ram, you still tend to get high percentage of
time working on softirqs on all the CPUs when pps reaches somewhere
around 60-70k, and the traffic approaching 600-900mbit/sec (during a
DDoS, such hardware cannot typically cope).

It seems like finding hardware more optimized for very high packet per
second counts would be a good thing to do. I just have no idea what is
out there that could meet these goals. I'm unsure if faster CPUs, or
more CPUs is really the problem, or networking cards, or just plain old
fashioned tuning.

Any ideas or suggestions would be welcome!


DPDK is your friend here.

-Scott


micah

Re: Google's QUIC

[Scott Whyte]

On Fri, Jun 28, 2013 at 1:23 PM, Michael Thomas m...@mtcc.com wrote:

 On 06/28/2013 01:16 PM, Josh Hoppes wrote:

 My first question is, how are they going to keep themselves from
 congesting links?


 The FAQ claims they're paying attention to that, but I haven't read the
 details. I sure hope they grok that not understanding Van Jacobson dooms
 you to repeat it.


Van is at Google.  Much grokking is going on.

-Scott



 https://docs.google.com/**document/d/**1lmL9EF6qKrk7gbazY8bIdvq3Pno2X**
 j_l_YShP40GLQE/preview?sle=**true#heading=h.h3jsxme7rovmhttps://docs.google.com/document/d/1lmL9EF6qKrk7gbazY8bIdvq3Pno2Xj_l_YShP40GLQE/preview?sle=true#heading=h.h3jsxme7rovm

 Mike



 On Fri, Jun 28, 2013 at 3:09 PM, Michael Thomas m...@mtcc.com wrote:

 http://arstechnica.com/**information-technology/2013/**
 06/google-making-the-web-**faster-with-protocol-that-**
 reduces-round-trips/?comments=**1http://arstechnica.com/information-technology/2013/06/google-making-the-web-faster-with-protocol-that-reduces-round-trips/?comments=1

 Sorry if this is a little more on the dev side, and less on the ops side
 but
 since
 it's Google, it will almost certainly affect the ops side eventually.

 My first reaction to this was why not SCTP, but apparently they think
 that
 middle
 boxen/firewalls make it problematic. That may be, but UDP based port
 filtering is
 probably not far behind on the flaky front.

 The second justification was TLS layering inefficiencies. That definitely
 has my
 sympathies as TLS (especially cert exchange) is bloated and the way that
 it
 was
 grafted onto TCP wasn't exactly the most elegant. Interestingly enough,
 their
 main justification wasn't a security concern so much as helpful middle
 boxen
 getting their filthy mitts on the traffic and screwing it up.

 The last thing that occurs to me reading their FAQ is that they are
 seemingly trying
 to send data with 0 round trips. That is, SYN, data, data, data... That
 really makes me
 wonder about security/dos considerations. As in, it sounds too good to be
 true. But
 maybe that's just the security cruft? But what about SYN cookies/dos?
 Hmmm.

 Other comments or clue?

 Mike

Re: Google/Youtube problems

[Scott Whyte]

On Mon, Nov 19, 2012 at 11:10 AM, Nick Olsen n...@flhsi.com wrote:
 I think this would be true if they offered some form of paid peering.

 Google want's a good fast route to your customers, And your customers want
 a good fast route to Google.

 IF Google ran its transit at or near congestion. This could degrade your
 customers performance. After so long, You'd contact Google and attempt to
 troubleshoot. And they would say if you want good peering with them, You
 should pay them to peer. Where you could control just how much traffic was
 on your port and expand it if needed. Pretty sure this was Comcast and
 level3/Netflix did. But Comcast had the winning leverage (more eyeballs) in
 the discussion.

 But, I don't think Google does this. My knowledge on AS15169 is limited.
 But I recall them having a very strict peering policy.

Strict?  Really?
https://peering.google.com/about/peering_policy.html


 Nick Olsen
 Network Operations (855) FLSPEED  x106

 
  From: Joly MacFie j...@punkcast.com
 Sent: Monday, November 19, 2012 1:21 PM
 To: joel jaeggli joe...@bogus.com
 Subject: Re: Google/Youtube problems

 WIth my limited understanding of such topics I've long been confused by
 something I read a couple of years back - in an Arbor report perhaps - to
 the effect that by being the originator of so much traffic, and as they
 built out their own network, Google were making money on transit.

 Can anyone elaborate or refute?

 On Mon, Nov 19, 2012 at 11:55 AM, joel jaeggli joe...@bogus.com wrote:

 On 11/19/12 5:59 AM, Saku Ytti wrote:

 What I'm trying to say, I can't see youtube generating anywhere nearly
 enough revenue who shift 10% (or more) of Internet. And to explain this
 conundrum to myself, I've speculated accounting magic (which I'd frown
 upon) and leveraging market position to get free capacity (which is ok,
 I'd
 do the same, had I the leverage)

 Or there's a simpler explanation. Which is that it makes money either
 directly or as part of a salubrious interaction with other google
 properties.

 They had about 2.5Billion left over for their trouble in the quarter
 ending 9/30 which isn't too shabby on a gross of 14 billion.



 --
 ---
 Joly MacFie  218 565 9365 Skype:punkcast
 WWWhatsup NYC - http://wwwhatsup.com
 http://pinstand.com - http://punkcast.com
 VP (Admin) - ISOC-NY - http://isoc-ny.org
 --
 -

Re: Manage an enterprise network? Please fill out my survey - for Science! :-)

[Scott Whyte]

On 10/31/11 19:33 , Justine Sherry wrote:

:) I should've guessed that you guys, of all people, would notice the
discrepancy.

I used to be at the UW; I registered for this list using my UW email
address. Rather than re-register in order to be able to post to the
list, I just sent from my old email address.

The survey is linked from my homepage and the UW affiliation is mentioned:
http://www.eecs.berkeley.edu/~justine/


I've met Justine and can vouch for her serious, laser-focused interest 
in middlebox research, and that if she's not really attending Cal then 
she's bamboozled a whole heap of CS profs over there.


But seriously, if you can help her ascertain real middlebox use cases 
she wants to help improve that segment of networking via useful 
research, nothing more or less.


-Scott



Justine

On Mon, Oct 31, 2011 at 19:23, Adefisayo Adegokeafis...@gmail.com  wrote:

Hello Justine,

I find it interesting, to say the least, that all of the communication
that you have about a Berkeley research program while your email came
from washington.edu?

Thanks,

'Ayo

. Success is getting what you want, happiness is wanting what you
get - Ingrid Bergman

... the sky is too low to be my limit Sent from my iPhone

On Oct 31, 2011, at 6:48 PM, Justine Sherryjust...@cs.washington.edu  wrote:


Hello! My name is Justine and I am a graduate student at UC Berkeley
(http://cs.berkeley.edu/~justine).

I'm doing a research project on middlebox appliances such as proxies,
WAN optimizers, and firewalls. Middlebox appliances are any
networking-related hardware other than routers and switches. I'd like
to learn a little bit about how middleboxes are used in real world
deployments in enterprises. Vendors often engage in surveys of this
type - but the research community knows less than we'd like to about
typical concerns in an enterprise network.

If you work on network management in an enterprise, I'd love to hear
about your experiences through this survey:
https://docs.google.com/spreadsheet/viewform?hl=en_USformkey=dHo1NGZ3eU04SlBaSnNsSlBYZGNYSlE6MQ#gid=0

Some promises:
(1) If you give me your email address, I will not give it to anyone
else, nor will I add you to any annoying mailing lists.
(2) If you mention the name of your organization, I will not share it
with anyone else.
(3) If I publish any data from this, statistics will be reported in aggregate.
(4) I will not share the raw data from this survey with anyone other
than my advisor, Professor Sylvia Ratnasamy
(syl...@eecs.berkeley.edu).

Feel free to skip questions and please provide approximate answers if
you have them.

Finally, to thank you for your time, we'll enter you in to a lottery
for a $100 Amazon gift card; we'll select two people to win and
contact them on November 16. Thank you!

If you have any questions or concerns, please contact me.

Justine

PS: The survey is here! Don't miss it!
https://docs.google.com/spreadsheet/viewform?hl=en_USformkey=dHo1NGZ3eU04SlBaSnNsSlBYZGNYSlE6MQ#gid=0

Re: vyatta for bgp

[Scott Whyte]

On 9/22/11 11:38 , Charles N Wyble wrote:

On 09/22/2011 05:37 AM, Pierce Lynch wrote:

Andreas Echavez [mailto:andr...@livejournalinc.com] originally wrote:

Ultimately, the network is as reliable as you build it. With
software, it's much cheaper to divide and scale horizontally.
Hardware devices are expensive and usually horizontal
scalability never happens. So in reality, an enterprise blows 100k on
two routers, they both flop because of some firmware bug, and
you're down.

With this in mind, I am keen to understand how many implementations of
packages such as Quagga and Zebra that the group use. With the likes
of Vyatta being discussed, I am keen to see if products such as Quagga
as still regularly used as it used to be.


I think that the original/upstream versions are out of date as compared
to the one maintained by Vyatta. Or Google (for their MPLS processing
needs). See
http://www.nanog.org/meetings/nanog50/abstracts.php?pt=MTYzNSZuYW5vZzUwnm=nanog50
http://www.nanog.org/meetings/nanog50/abstracts.php?pt=MTYzNSZuYW5vZzUwnm=nanog50


We are actively supporting Quagga.  We currently have a git repo at 
code.google.com with some BGP multipath updates, and are working with 
ISC to provide SQA on that branch.  Hopefully more features will be 
forthcoming.  Search quagga-dev if you're interested in more details.


Vyatta has done a lot of great work on Quagga, as have many others.  It 
would be nice to see all the various useful branches merged into a 
cherry-picked mainline that would simplify the Quagga development 
community's lives considerably.


-Scott

Re: Yahoo and IPv6

[Scott Whyte]

On Wed, May 11, 2011 at 23:10, Franck Martin fmar...@linkedin.com wrote:
 I think the yahoo test should just differentiate between no IPv6 and IPv6
 is slow (test between 3s and 10s). Like:

 We have detected that you have IPv6 and will be able to access our site on
 IPv6 day, but your user experience may not be as good as with IPv4, you
 may consider disabling IPv6.


Measurements during the experiment won't be directly comparable to
those before/after, at least as far as I can see.  So they will be
informative, but its the slope of the brokenness line before/after
that will determine when IPv6 is not an impediment to itself.

-Scott

Re: Yahoo and IPv6

[Scott Whyte]

On Tue, May 10, 2011 at 13:58, Iljitsch van Beijnum iljit...@muada.com wrote:
 On 10 mei 2011, at 22:31, Warren Kumari wrote:

 :: I applaud the first step, but I'm bothered by the fact that no second 
 step is planned.

 Igor is right on both counts here -- 0.05% is definitely noticeable at these 
 sorts of scale,

 Ok, removed my infamatory reply. But tell me how 0.05% is visible in the 
 up/down motions of traffic as it starts raining, there is something 
 especially good/bad on TV, people have to reboot because of a Windows update 
 or whatever.

Its the delta between v4 and v6 that is visible and significant.  If
some machine's addresses are all down hard, that is no problem in this
scenario.

-Scott