- NANOG - lists.nanog.org

BGP advertise-best-external on RR
by Mohamed Kamal 02 Sep '15

02 Sep '15

Hi, I have a classic network design with 3 gateways, each receive a default route from different upstream provider. Each gateway has a BGP session with a route-reflector, which in turns reflects the best BGP route to the other PE routers in the network. The route-reflectors are running the SRE train (12.2(33)SRE1) and here exist the problem. I need to leak all the default routes (3 default routes) from the gateways into the PE routers. I have done this via bgp advertise-best-external on the gateways. So far, the default routes exist on the route-reflector, however it's suppressed as the RR will only send the best path. I have configured bgp advertise-best-external also on the RR but it didn't work, because the RR didn't see that the different default routes received are of "external" type. Cisco didn't state that clearly and it only stated that bgp best external feature won't work on the RR unless you get an ASR loaded with an IOS-XE 3.4 or later! Anyhow, do anyone here has a suggestion of how to get this done without replacing my RR sticking to this classical network design? Thanks. -- Mohamed Kamal Core Network Sr. Engineer

6 8

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

02 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 02 Sep '15

02 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 01 Sep '15

01 Sep '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

Production-scale NAT64
by Jawaid Shell2 29 Aug '15

29 Aug '15

Who out there is using production-scale NAT64? What solution are you using? Thanks, Jawaid

15 33

BGP Update Report
by cidr-report＠potaroo.net 28 Aug '15

28 Aug '15

BGP Update Report Interval: 20-Aug-15 -to- 27-Aug-15 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS9829 285802 7.0% 221.9 -- BSNL-NIB National Internet Backbone,IN 2 - AS38197 166147 4.0% 131.5 -- SUNHK-DATA-AS-AP Sun Network (Hong Kong) Limited,HK 3 - AS22059 116439 2.8% 58219.5 -- -Reserved AS-,ZZ 4 - AS26210 80874 2.0% 569.5 -- AXS Bolivia S. A.,BO 5 - AS3709 57253 1.4% 2120.5 -- NET-CITY-SA - City of San Antonio,US 6 - AS22773 52705 1.3% 566.7 -- ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US 7 - AS28024 46358 1.1% 29.5 -- Nuevatel PCS de Bolivia S.A.,BO 8 - AS131090 37063 0.9% 134.3 -- CAT-IDC-4BYTENET-AS-AP CAT TELECOM Public Company Ltd,CAT ,TH 9 - AS13188 36755 0.9% 47.4 -- BANKINFORM-AS CONTENT DELIVERY NETWORK LTD,UA 10 - AS8001 34076 0.8% 173.9 -- NET-ACCESS-CORP - Net Access Corporation,US 11 - AS8402 31499 0.8% 106.4 -- CORBINA-AS OJSC "Vimpelcom",RU 12 - AS56636 29589 0.7% 29589.0 -- ASVEDARU VEDA Ltd.,RU 13 - AS30295 29540 0.7% 9846.7 -- 2ICSYSTEMSINC - 2iC Systems Inc.,CA 14 - AS25563 29032 0.7% 9677.3 -- WEBLAND-AS Webland AG,CH 15 - AS199367 23140 0.6% 23140.0 -- AS_GBP Globe Business Publishing Limited,GB 16 - AS13999 22212 0.5% 52.6 -- Mega Cable, S.A. de C.V.,MX 17 - AS1505 20201 0.5% 2525.1 -- DNIC-AS-01505 - Headquarters, USAISC,US 18 - AS22047 19138 0.5% 63.0 -- VTR BANDA ANCHA S.A.,CL 19 - AS6849 19087 0.5% 15.8 -- UKRTELNET JSC UKRTELECOM,UA 20 - AS200671 17998 0.4% 17998.0 -- SKOK-JAWORZNO SKOK Jaworzno,PL TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS22059 116439 2.8% 58219.5 -- -Reserved AS-,ZZ 2 - AS56636 29589 0.7% 29589.0 -- ASVEDARU VEDA Ltd.,RU 3 - AS199367 23140 0.6% 23140.0 -- AS_GBP Globe Business Publishing Limited,GB 4 - AS200671 17998 0.4% 17998.0 -- SKOK-JAWORZNO SKOK Jaworzno,PL 5 - AS200008 14778 0.4% 14778.0 -- PIRUM-AS Pirum Systems Limited,GB 6 - AS30295 29540 0.7% 9846.7 -- 2ICSYSTEMSINC - 2iC Systems Inc.,CA 7 - AS25563 29032 0.7% 9677.3 -- WEBLAND-AS Webland AG,CH 8 - AS37590 9254 0.2% 9254.0 -- BCA-ASN,AO 9 - AS40493 7840 0.2% 7840.0 -- FACILITYSOURCEINC - FacilitySource,US 10 - AS393588 7061 0.2% 7061.0 -- MUBEA-FLO - Mubea,US 11 - AS31357 14599 0.4% 4866.3 -- TOMICA-AS Tomsk Information and Consulting Agency,RU 12 - AS21973 4473 0.1% 4473.0 -- XPONET - Xponet,US 13 - AS327786 17399 0.4% 4349.8 -- TELECOM-4G,SS 14 - AS197068 16094 0.4% 4023.5 -- QRATOR HLL LLC,RU 15 - AS55741 3614 0.1% 3614.0 -- WBSDC-NET-IN West Bengal Electronics Industry Development,IN 16 - AS28773 6580 0.2% 3290.0 -- MASTER-SERVICE-AS Global Technology Ukraine Ltd,UA 17 - AS51428 7804 0.2% 2601.3 -- ASIRONNET IRONNET Ltd.,CZ 18 - AS38000 5147 0.1% 2573.5 -- CRISIL-AS [CRISIL Limited.Autonomous System],IN 19 - AS1505 20201 0.5% 2525.1 -- DNIC-AS-01505 - Headquarters, USAISC,US 20 - AS45606 12600 0.3% 2520.0 -- TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 64.34.125.0/24 58586 1.4% AS22059 -- -Reserved AS-,ZZ 2 - 76.191.107.0/24 57853 1.4% AS22059 -- -Reserved AS-,ZZ 3 - 192.40.244.0/24 51955 1.2% AS22773 -- ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US 4 - 61.7.155.0/24 35196 0.8% AS131090 -- CAT-IDC-4BYTENET-AS-AP CAT TELECOM Public Company Ltd,CAT ,TH 5 - 192.135.223.0/24 33877 0.8% AS8001 -- NET-ACCESS-CORP - Net Access Corporation,US 6 - 195.128.159.0/24 29589 0.7% AS56636 -- ASVEDARU VEDA Ltd.,RU 7 - 185.19.144.0/22 23140 0.5% AS199367 -- AS_GBP Globe Business Publishing Limited,GB 8 - 155.133.79.0/24 17998 0.4% AS200671 -- SKOK-JAWORZNO SKOK Jaworzno,PL 9 - 185.65.148.0/24 16091 0.4% AS197068 -- QRATOR HLL LLC,RU 10 - 185.38.132.0/24 14778 0.3% AS200008 -- PIRUM-AS Pirum Systems Limited,GB 11 - 78.140.0.0/18 14590 0.3% AS31357 -- TOMICA-AS Tomsk Information and Consulting Agency,RU 12 - 187.244.68.0/22 13302 0.3% AS13999 -- Mega Cable, S.A. de C.V.,MX 13 - 199.60.234.0/23 10150 0.2% AS30295 -- 2ICSYSTEMSINC - 2iC Systems Inc.,CA 14 - 199.60.236.0/24 9942 0.2% AS30295 -- 2ICSYSTEMSINC - 2iC Systems Inc.,CA 15 - 92.43.216.0/21 9916 0.2% AS25563 -- WEBLAND-AS Webland AG,CH 16 - 185.84.192.0/22 9588 0.2% AS25563 -- WEBLAND-AS Webland AG,CH 17 - 178.174.96.0/19 9528 0.2% AS25563 -- WEBLAND-AS Webland AG,CH 18 - 199.60.233.0/24 9448 0.2% AS30295 -- 2ICSYSTEMSINC - 2iC Systems Inc.,CA 19 - 196.6.255.0/24 9254 0.2% AS37590 -- BCA-ASN,AO 20 - 94.73.56.0/21 7903 0.2% AS42081 -- SPEEDY-NET-AS Speedy net AD,BG Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog(a)nanog.org eof-list(a)ripe.net apops(a)apops.net routing-wg(a)ripe.net afnog(a)afnog.org

1 0