July 2015 - Test - lists.nanog.org

RE: [outages] CenturyLink fiber cut between Modesto, CA and San Jose, CA this AM.. Start time 4:26AM PST
by Keith Medcalf 02 Jul '15

02 Jul '15

Have they asked No-Such-Agency? No-Such-Agency typically taps communication lines by "back-hoe accident" of some sort on the path they are interested in tapping. That way they can install a tap "over yonder" while the victim telecom is attempting to repair the original damage. I guess this time is taking longer than expected so they FBI has been recruited to prevent the victim from completing repairs to quickly. Then again, maybe my tinfoil hat is too tight. > -----Original Message----- > From: Outages [mailto:outages-bounces@outages.org] On Behalf Of Hugo > Slabbert via Outages > Sent: Tuesday, 30 June, 2015 16:57 > To: Peter Kranz via Outages; Peter Kranz > Subject: Re: [outages] CenturyLink fiber cut between Modesto, CA and San > Jose, CA this AM.. Start time 4:26AM PST > > Related? > > http://arstechnica.com/tech-policy/2015/06/fbi-baffled-over-wave-of- > nighttime-fiber-optic-cable-vandalism/ > > -- > Hugo > > > > ---- Peter Kranz via Outages wrote ---- > > > This appears to be part of a larger act of intentional sabotage: > > "We have just been advised that crews have been removed from the area > while > law enforcement investigates the damage, which was caused by vandalism. > Three enclosures were damaged impacting three different carriers. There is > no time given for when they will be allowed to begin work again, > subsequently, there is still no ETR. > " > > > _______________________________________________ > Outages mailing list > Outages(a)outages.org > https://puck.nether.net/mailman/listinfo/outages

3 2

in-cabinet PDU safety regs?
by William Herrin 02 Jul '15

02 Jul '15

Hi Folks, Do you know of any regulations, standards or publications covering the safe installation and use of the little 1U and 2U PDUs in rack cabinets? My google fu is failing me. All I've found is OSHA 1926.403(i)(1)(i) (https://www.osha.gov/pls/oshaweb/owadisp.show_document?p_table=STANDARDS&p_…) and I'm not 100% sure it applies. Thanks in advance, Bill Herrin -- William Herrin ................ herrin(a)dirtside.com bill(a)herrin.us Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/>

3 2

suggestion for DSCP codepoint for "less than best effort" (scavanger class) traffic
by Mikael Abrahamsson 02 Jul '15

02 Jul '15

Hi, in the IETF transport area there are discussions on DSCP interconnection between networks. It's quite common that operators clear (bleach) the DSCP codepoints when receiving packets from other operators, turning everything into BE (best effort) traffic. Historically CS1 has been proposed as less-than-best-effort (for instance bittorrent traffic), but my opinion is that this is ill suited as I think it's not incrementally deployable. Some networks might use CS1 as something that has higher priority and it would be hard for them to change this incrementally. I have proposed a DSCP codepoint that I believe is incrementally deployable and that is 000010, which I think is deployable because it maps to CS0, PRECEDENCE 0, so any kind of equipment that today takes these bits and imposes it into 802.1p, MPLS TC (former EXP) etc, will just map this to regular BE. If explicitly configured, one can match on 000010 and put this in a different queue, for instance that doesn't have much bandwidth guarantees at all. Since this proposal just comes from my personal experience with equipment in the MPLS/L2/IP world, I'd like to hear wider view/opinion on this and I'll bring it to the TSVWG at the upcoming IETF in Prague July 20-25. It would be great if there could be an operational document as well, giving recommendations on how to configure the above, and it would be great if it could be done with lots of operator input into the matter. ---------- Forwarded message ---------- Date: Thu, 2 Jul 2015 00:32:40 +0000 From: "Black, David" <david.black(a)emc.com> To: "Ruediger.Geib(a)telekom.de" <Ruediger.Geib(a)telekom.de>, "swmike(a)swm.pp.se" <swmike(a)swm.pp.se> Cc: "tsvwg(a)ietf.org" <tsvwg(a)ietf.org> Subject: RE: [tsvwg] draft diffserv-intercon: Handling of a scavenger class / CS1 <WG chair hat OFF> > - work on a scavenger class standard needs to be done in a > separate draft. And here's what that draft might encompass ... Beyond that, I'd support a (hopefully short) draft that - updates RFC 3662 to change the recommended DSCP for the LE PHB from CS1 to 000010, - recognizes and allows for continued use of CS1 where deployed, and - updates other RFCs (e.g., 4592, 5127) accordingly as needed. As Brian pointed out, this would need to be a standards track draft with a downref to RFC 3662 in order to allocate that DSCP. Writing the draft is straightforward by comparison to figuring out whether this is what we should do, as indicated by the other messages in this thread on operator/operational considerations. This item is on the draft tsvwg agenda for Prague as a discussion topic - I plan to bring slides and only write the -00 draft after I've survived that discussion ;-). </WG chair hat OFF> Thanks, --David > -----Original Message----- > From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of > Ruediger.Geib(a)telekom.de > Sent: Monday, June 29, 2015 4:51 AM > To: swmike(a)swm.pp.se > Cc: tsvwg(a)ietf.org > Subject: Re: [tsvwg] draft diffserv-intercon: Handling of a scavenger class / > CS1 > > Hi Mikael, > > ok, understood, I'm relaxed. > > The relation of Diffserv intercon to scavenger is > > - if there is a scavenger class, how should Diffserv intercon handle it > (will add text about a 000 xx0 DSCP)? Otherwise Diffserv Intercon > says, bleaching may occur for any unexpected DSCP. > > - work on a scavenger class standard needs to be done in a > separate draft. That's WG consensus and Gorry Fairhurst said during > the last meeting: > "Scavenger support document been discussed before, if there is > renewed interest, then we should take it up again. > As an individual contributor, I would be interested. > If you are also interested in this topic, please talk to the > WG chairs." > > - operational issues may be relevant for a bleaching discussion. > A bleaching standard is out of scope of Diffserv Intercon (thats > WG consensus). I think to recall interest in work on bleaching > by others too. > > Then I'm happy to meet you in Prague. > > Regards, > > Ruediger > > -----Ursprüngliche Nachricht----- > Von: Mikael Abrahamsson [mailto:swmike@swm.pp.se] > Gesendet: Montag, 29. Juni 2015 09:38 > An: Geib, Rüdiger > Cc: tsvwg(a)ietf.org > Betreff: Re: AW: AW: AW: [tsvwg] draft diffserv-intercon: Handling of a > scavenger class / CS1 > > On Mon, 29 Jun 2015, Ruediger.Geib(a)telekom.de wrote: > >> I repeat that I've talked with my RIPE/NANOG colleagues to get >> feedback >> - they came back only with one or two names with whom to discuss QoS >> interconnection. And I never got any useful response (positive or >> negative) from those. > > This is the problem, that's not how to do this, the way to do this is to > announce an idea on the nanog mailing list and see who might be interested. > > As far as I read your document, it has nothing in it about how to > incrementally get an Internet-wide scavenger class operationally deployed over > time. To me it reads more like a document for business VPN Carriers-Carrier > services style interconnect/interworking. It has no operational advice at all > in it on how to deal with DDoS, how to configure access equipment, how to set > up queuing strategies on different kinds of equipment, listing what equipment > might do what, etc. > > I suggested how to actually make this incrementally and widely deployable > across the world, and that is to aim for a 000xxx style scavenger class. > This seems to not work for some reason that is unclear to me, your document > doesn't seem to be operational at all, it doesn't propose something that is > operationally deployable on the wider Internet, so that's why I think we would > need another document for this purpose. If that is not a goal we can agree on, > then there is no need to write one. > > So just to sum up: I'm sure your document is fine for what it intends to do, > it just doesn't answer any of the concerns an IP network engineer/architect > might have about implementing this on an Internet peering link where there is > little or no control over what traffic will pass or what this traffic might do > to the rest of their network. It suggests a way to do something with no > operational analysis or risk mitigation at all. > > The first thing that will pop into any good IP architects head nowadays will > be "oh, what happens to my network when I get 200 gigabits/s of 64 byte > packets marked EF from that 5 million strong DDoS-drone network all across the > world, aimed for my customer base?" > > The answer to that is "I'll bleach DSCP it because that's the only way to > handle it". So in order to get a scavenger class actually deployable, you have > to come up with something that means they can relax the bleaching a little bit > by some operators, but their infrastructure would still treat the traffic the > same. You also have to take into account that a lot of core IP network > equipment can't do DSCP mapping very well. This kind of functionality makes > equipment more expensive and thus less likely to exist widely. > > -- > Mikael Abrahamsson email: swmike(a)swm.pp.se

2 1

Inexpensive software bgp router that supports route tags?
by David H 02 Jul '15

02 Jul '15

Hi all, I was wondering if anyone can recommend a software (preferable), or hardware-based router with an API, that supports BGP with tags on advertised routes? I want to use it for a RTBH feed and having it in software would make certain things easier to automate. I tried Quagga/Zebra but it doesn't support tags. I see Mikrotik hardware routers have an API, but I can't tell if the API supports adding BGP networks, so I need to investigate that further. I can go hardware if I have to, with some ssh/expect scripts, but thought there may be other options that are easier. Thanks, David

8 10

REMINDER: LEAP SECOND
by Jay Ashworth 02 Jul '15

02 Jul '15

The IERS will be adding a second to time again on my birthday; 2015-06-30T23:59:59 2015-06-30T23:59:60 2015-07-01T00:00:00 Have fun, everyone. :-) Cheers, -- jra -- Jay R. Ashworth Baylink jra(a)baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274

34 87

leap second outage
by frnkblk＠iname.com 02 Jul '15

02 Jul '15

We experienced our first leap second outage -- our SHE (super head end) is using (old) Motorola encoders and we lost those video channels. They restarted all those encoders to restore service. Frank

10 13

Re: leap second outage
by Dovid Bender 01 Jul '15

01 Jul '15

I read that and that at midnight local time since that's when you have the extra second. I know a large carrier in Israel is down. Waiting for conf. If it's leep second related. ------Original Message------ From: Stefan Sender: NANOG To: frnkblk(a)iname.com Cc: nanog(a)nanog.org Subject: Re: leap second outage Sent: Jun 30, 2015 23:30 This was supposed to have happened @midnight UTC, right? Meaning that we are past that event. Under which scenarios should people be concerned about midnight local time? Lots of confusing messages flying all over... On Jun 30, 2015 10:13 PM, <frnkblk(a)iname.com> wrote: > We experienced our first leap second outage -- our SHE (super head end) is > using (old) Motorola encoders and we lost those video channels. They > restarted all those encoders to restore service. > > Frank > > Regards, Dovid

3 3

Re: GRE performance over the Internet - DDoS cloud mitigation
by Kenneth McRae 01 Jul '15

01 Jul '15

How stable can GRE transports and BGP sessions be when under load? I typically protect the BGP session by policing all traffic being delivered to the remote end except for BGP. Using this posture, my BGP session over GRE are stable; even under attack. Kenneth On Jun 30, 2015, at 01:37 PM, Dennis B <infinityape(a)gmail.com> wrote: Roland, Agreed, Ramy's scenario was not truly spot on, but his question still remains. Perf implications when cloud security providers time to detect/mitigate is X minutes. How stable can GRE transports and BGP sessions be when under load? In my technical opinion, this is a valid argument, which deems wide opinion. Specifically, use-cases about how to apply defense in depth logically in the DC vs Hybrid vs Pure Cloud. Good topic, already some back-chatter personal opinions from Nanog lurkers! Regards, Dennis B. On Tue, Jun 30, 2015 at 2:45 PM, Roland Dobbins <rdobbins(a)arbor.net> wrote: On 1 Jul 2015, at 1:37, Dennis B wrote: Would you like to learn more? lol I'm quite conversant with all these considerations, thanks. OP asserted that BGP sessions for diversion into any cloud DDoS mitigation service ran from the endpoint network through GRE tunnels to the cloud-based mitigation provider. I was explaining that in most cloud mitigation scenarios, GRE tunnels are used for re-injection of 'clean' traffic to the endpoint networks. ----------------------------------- Roland Dobbins <rdobbins(a)arbor.net>

2 1

Leap Second Folo/After Action
by Jay Ashworth 01 Jul '15

01 Jul '15

Here's LWN's piece on the then-upcoming event from last week, presumably with comments trailing into today. http://lwn.net/Articles/648313/ How'd it go for everyone? Did the world end? Cheers, -- jra -- Jay R. Ashworth Baylink jra(a)baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274

2 1

Re: Leap Second Folo/After Action
by Scott Weeks 01 Jul '15

01 Jul '15

--- jra(a)baylink.com wrote: From: Jay Ashworth <jra(a)baylink.com> Here's LWN's piece on the then-upcoming event from last week, presumably with comments trailing into today. http://lwn.net/Articles/648313/ How'd it go for everyone? Did the world end? ----------------------------------------------- Not one single problem. Yay! :-) <me: gives thanks to $deity/$deities) - Ku, Kane, Lono and Kanaloa in Hawaiian> scott

1 0