September 2015 - Test - lists.nanog.org

Re: NetFlow - path from Routers to Collector
by Scott Weeks 01 Sep '15

01 Sep '15

--- rdobbins(a)arbor.net wrote: Again, to clarify - I count VLANs/VRFs as being sufficiently out-of-band to handle flow telemetry on a reasonable basis without mixing it in with customer traffic. --------------------------------------- Glad you clarified that. Now, I understand your stance. Like the others are saying, in 18 years of netgeeking I never had OOB with <whatever>flow. It has always been in a VLAN or VRF. --- freedman(a)freedman.net wrote: We see well under 20% doing logical separation but definitely folks doing it... -------------------------------------- Now that's a scary number. VLANS/VRFs are too easy not to do that. scott

1 0

Re: NetFlow - path from Routers to Collector
by freedman＠freedman.net 01 Sep '15

01 Sep '15

(Said Roland:) > Again, to clarify - I count VLANs/VRFs as being sufficiently out-of-band > to handle flow telemetry on a reasonable basis without mixing it in with > customer traffic. > > That changes the ratio. <snip> > I agree with you, Avi, and others that a dedicated OOB network *just for > flow telemetry* doesn't make economic sense in most (any?) scenarios. > > What I'm saying is that it oughtn't to be mixed in with customer > data-plane traffic. Ideally, all management-plane traffic would > traverse a separate physical infrastructure. Since we don't live in an > ideal world, virtual separation is generally Good Enough. We see well under 20% doing logical separation but definitely folks doing it... For the definition of OOB as "separate routers and switches", we don't see anyone really sending flow over that kind of OOB network. > ----------------------------------- > Roland Dobbins <rdobbins(a)arbor.net> Avi Freedman CEO, Kentik avi at kentik dot com

2 1

Re: NetFlow - path from Routers to Collector
by freedman＠freedman.net 01 Sep '15

01 Sep '15

Looking at probably 100 networks' flow paths over the last year, I'd say 1 or 2 have OOB for flow. Maybe another 10-20 have interest in taking simpler time series data of top talkers over their OOB networks, but not the flow itself. Agree w Roland that it can cause problems with telemetry if there are big network misconfigs. But for folks seeing DDoS, we implement rate-limiting of the flows/sec via local proxies to avoid overwhelming network capacity with the flow data... Avi > I think the key here is that Roland isn't often constrained by > these financial considerations. > > I would respectfully disagree with Roland here and agree with > Job, Niels, etc. > > A few networks have robust out of band networks, but most > I've seen have an interesting mixture of things and inband is usually > the best method. > > Those that do have "seperate" networks may actually be CoC > services from another deparment in the same company riding the same > P/PE devices (sometimes routers). > > I've seen oob networks on DSL, datacenter wifi or cable swaps > through the fence to an adjacent rack. > > An oob network need not be high bandwidth enough to do netflow > sampling, this is well regarded as a waste of money by many as the costs > for these can often be orders of magnitude more compared to a pure-IP > or internet service. > > I'll say this ranks up there with people who think > MPLS VPN == Encryption. It's not unless you think a few byte > label is going to confuse people. > > - Jared

2 1

FTTP Advice, Michigan and other areas
by Jared Mauch 01 Sep '15

01 Sep '15

I’m looking for some advice/input from people either public or private about woes building fiber to reach people outside the footprints of the existing incumbents. There is a group of people looking to organize private fiber to reach areas that are unserved. There’s been recent local people doing this like Lightspeed (Lansing) and the Vergennes Broadband folks. When it come to private right of way, public right of way use, swaps, pole attach and other things, any best practices people can share either in public or private? TL;DR background for those interested: Many wireless ISPs are finding it harder to locate equipment or utilize frequencies based on interference or congestion. Advanced encodings like 16-QAM that are seen in 802.11ac hardware also introduce latencies that are not ideal. The FCC is also making it harder for equipment to be qualified in this space, in some cases rightly so due to out of band emissions or just adjacent frequency noise. The revisions of rules in 5Ghz are helpful, but the cellular industry is also looking to exploit these frequencies to solve indoor coverage. There are two groups I’m trying to assist, a local cooperative which is trying to just own the fiber and let providers gain access and some WISPs that are looking to improve service due to increase customer demand. Getting service on the fiber is “easy” once it’s there, but gaining access or building it is the part I’m looking for insights in. - Jared

3 3

Zero rating implentation strategies
by Jean-Francois Mezei 01 Sep '15

01 Sep '15

Last year, one large mobile operator in Canada started to zero-rate its own mobile TV offering. It appears that routers kept counting all the data, but that the company then subtracted usage generated by its video servers to come up with billable Gigabytes for each user. (This was quashed by the regulator in Canada) In the last week, another mobile operator announced it was zero rating approved music streaming services (Spotify, Google Play and a few others). If you are dealing with "foreign" content that comes from servers you don't control, what are the "best practices" to zero-rate content from multiple outside sources ? To make matters more interesting, the FAQ for that service indicates that if you listen to a music stream that exceeds 128kbps, you MAY be charged for the data, and that you will be charged to listen to videos that could be offered by that service, and for non streaming data such as album covers, list of songs etc. Would this point to specific IPs (streaming servers for low quality 128kbps sound) ? How scalable is this when you start to have a whole bunch of source IPs whose traffic is to be zero rated ? Or would another way of doing this to setup private routes into the ISP's network for each approved service, so the data would enter through a different interface and be counted separately ? Or, and this is my most important question: Is it possible with current networking software to zero rate any data flow that is less than a certain value (eg: 128kbs) ? Or would current software require network operator to get 5 minute usage for each user and only bill if average data rate during last 5 minutes exceeded 128kbps ? (which means that your music is billed if you also listen to netflix at same time since total data flows are greater than 128kbps) Of note: not all customers get this treatment, only those with higher end packages. Those with lower end packages are charged for usage by those very same services. And for the record, this isn't to setup a similar system, it is to better understand the issue for a regulatory challenge.

3 6

Re: DDoS appliances reviews needed
by Ramy Hashish 01 Sep '15

01 Sep '15

And at the end of the day it's commercial, vendors pay, I don't trust much. I am looking for hands-on experience.... Ramy > > Message: 8 > Date: Thu, 27 Aug 2015 16:00:10 +0000 > From: Steve Mikulasik <Steve.Mikulasik(a)civeo.com> > To: "nanog(a)nanog.org" <nanog(a)nanog.org> > Subject: RE: DDoS appliances reviews needed > Message-ID: > < > BY1PR0701MB1781D116ED99F67358E79877FA6F0(a)BY1PR0701MB1781.namprd07.prod.outlook.com > > > > Content-Type: text/plain; charset=UTF-8 > > I assume they don't list their testing methodology right? It always feels > like they just read vendor spec sheets. > > Steve Mikulasik > > -----Original Message----- > From: NANOG [mailto:nanog-bounces@nanog.org] On Behalf Of Joe Chisolm > Sent: Thursday, August 27, 2015 9:53 AM > To: nanog(a)nanog.org > Subject: Re: DDoS appliances reviews needed > > Gartner did a report about a year ago. Not free. > https://www.gartner.com/doc/2910217/ddos-comparison-defense-approaches > > On 08/26/2015 07:40 AM, Ramy Hashish wrote: > > Good day all, > > > > Anybody here has experienced a PoC for any anti DDoS appliance, or > > already using a anti DDoS appliance in production and able to share > > his user experience/review? > > > > We need to collect good reviews from people whom got their hands dirty > > with the configuration/attack mitigation, real experience. > > > > Thanks, > > > > Ramy > > > > -- > Joe Chisolm > Computer Translations, Inc. > Network and Datacenter Consulting > Marble Falls, Tx. > 830-265-8018 > > Public Key Available at http://www.sks-keyservers.net > > > >

1 0

PMTUD for IPv4 Multicast - How?
by Chris Marget 31 Aug '15

31 Aug '15

I recently discovered that my routers weren't generating ICMP Type 3 Code 4 (unreachable, DF-bit) messages in response to too-big IPv4 multicast packets with DF=1. At first, I thought this was a bug, but then learned that RFCs 1112, 1122 and 1812 all specify that ICMP unreachables not be sent in response to multicast packets. RFC1981 (PMTUD for IPv6), on the other hand, is explicit that PMTUD works for multicast flows, that the path MTU for a multicast flow is the smallest MTU available anywhere in the distribution tree, and that a single multicast packet may provoke many ICMP unreachables from routers along the tree. Further complicating matters, the default Linux behavior (ip_no_pmtu_disc = 0) sets the DF bit on all packets unless the application is explicit (setsockopt()) that DF be cleared. This behavior strikes me as a troublesome assumption (that the application will interpret unreachables) in the case of unicast UDP sockets, and downright broken (because traffic will be dropped silently) in the case of multicast UDP sockets. I'm struggling to grok the rationale behind not sending unreachables in response to multicast packets. It seems to me that our networks put IPv4 multicast speakers in a position where it's impossible for them to do the right thing. Does anybody understand why PMTUD for IPv4 multicast flows is disabled in routers? Is there a secret lever to enable it in Cisco IOS? What should a responsible IPv4 multicast application do when receivers are flung far and wide with un-knowable MTUs in the transit path? Thanks, /chris

6 14