November 2016 - Test - lists.nanog.org

BRAS/BNG Suggestion
by Lorenzo Mainardi 03 Dec '16

03 Dec '16

Good morning, Could you suggest some vendors of BRAS/BNG for PPPoE termination? We have more than 20.000 users. In my short list there are already Juniper, Cisco and NOKIA/ALU. Do you have any other honorable brand or good experiences? Regards digitel Via della Fortezza 6 - 50129 Firenze www.digitelitalia.com<http://www.digitelitalia.com/> - 800 901 669 Ing. Lorenzo Mainardi Tel +39 055 4624933 Fax +39 055 4624 947 lom(a)digitelitalia.com<mailto:lom@digitelitalia.com>

9 10

Re: Death of the Internet, Film at 11
by Ronald F. Guilmette 02 Dec '16

02 Dec '16

Laszlo Hanyecz wrote: >What does BCP38 have to do with this? Your're right. That's not specifically related to *this* attack. Nobody needs to spoof anything when you've got a zillion fire hoses just lying around where any 13 year old can command them from the TRS 80 in his mom's basement. (I've seen different estimates today. One said there's about a half million of these things, but I think I saw where Dyn itself put the number of unique IPs in the attack at something like ten million.) I just threw out BCP 38 as an example of something *very* minimal that the collective Internet, if it had any brains, would have made de rigueur for everyone ten+ years ago. BCP 38 is something that I personally view as a "no brainer", that is already widely accepted as being necessary, and yet is a critical security step that some (many?) are still resisting. So, it's like "Well, if the Internet-at-large can't even do *this* simple and relatively non-controversial thing, then we haven't got a prayer in hell of ever seeing a world-wide determined push to find and neutralize all of these bloody damn stupid CCTV things. And when the day comes when somebody figures out how to remotely pop a default config Windoze XP box... boy oh boy, will *that* be a fun day... NOT! Because we're not ready. Nobody's ready. Except maybe DoD, and I'm not even taking bets on that one." I didn't intend to focus on BCP 38. Everybody knows that's only one thing, designed to deal with just one part of the overall problem. The overall problem, in my view, is the whole mindset which says "Oh, we just connect the wires. Everything else is somebody else's problem." Ok, so this mailing list is a list of network operators. Swell. Every network operator who can do so, please raise your hand if you have *recently* scanned you own network and if you can -honestly- attest that you have taken all necessary steps to insure that none of the numerous specific types of CCVT thingies that Krebs and others identified weeks or months ago as being fundamentally insecure can emit a single packet out onto the public Internet. And, cue the crickets... Recent events, like the Krebs DDoS and the even bigger OVH DDoS, and today's events make it perfectly clear to even the most blithering of blithering idiots that network operators, en mass, have to start scanning their own networks for insecurities. And you'd all better get on that, not next fiscal year or even next quarter, but right effing now, because the next major event is right around the corner. And remember, *you* may not be scanning your networks for easily pop'able boxes, but as we should all be crystal clear on by now, that *does not* mean that nobody else is doing so. Regards, rfg P.S. The old saying is that idle hands are the devil's playground. In the context of the various post-invasion insurgancies, etc., in Iraq, is is often mentioned that it was a somewhat less than a brilliant move for the U.S. to have disbanded the Iraq army, thereby leaving large numbers of trained young men on the streets with no jobs and nothing to do. To all of the network operators who think that (or argue that) it will be too expensive to hire professionals to come in an do the work to scan your networks for known vulnerabilities, I have a simple suggestion. Go down to your local high school, find the schmuck who teaches the kids about computers, and ask him for the name of his most clever student. Then hire that student and put him to work, scanning your network. As in Iraq, it will be *much* better to have capable young men inside the tent, pissing out, rather than the other way around.

55 165

10G switch drops traffic for a split second
by TJ Trout 01 Dec '16

01 Dec '16

I recently upgraded my core network from 1G to 10G and after the upgrade I have noticed that my 10G switch during peak traffic (1500mbps, 100,000pps) seems to be dropping traffic for a split second across all ports and all vlans. I immediately replaced the switch with a different brand/model and the problem persists. Sometimes traffic drops to zero, others it drops to 50%, problem is very random but seems to occur with much more frequency during high PPS (pushing high traffic / iperf does not induce problem) Could this be MTU? I've tried flow control, hard code duplex, stp on/off etc I'm at a loss any ideas? TJ Trout Volt Broadband

9 13

Brocade MLXe Selective FIB Population
by Graham Johnston 30 Nov '16

30 Nov '16

Does anybody have information on how to selective populate the IPv4 FIB on a Brocade MLXe? Graham Johnston Network Planner Westman Communications Group 204.717.2829 johnstong(a)westmancom.com<mailto:johnstong@westmancom.com> P think green; don't print this email.

2 1

BFD on back-to-back connected BGP-speakers
by Hugo Slabbert 29 Nov '16

29 Nov '16

Good morning, nanog, Is there any/sufficient benefit in adding BFD onto BGP sessions between directly-connected routers? If we have intermediate L2 devices such that we can't reliably detect link failures BFD can help us quickly detect peers going away even when link remains up, but what about sessions with: - eBGP with peering to interface addresses (not loopback) - no multi-hop - direct back-to-back connections (no intermediate devices except patch panels) Possible failure scenarios where I could see this helping would be fat fingering (filters implemented on one or the other side drops traffic from the peer) or e.g. something catastrophic that causes the control plane to go away without any last gasp to the peer. Or is adding BFD into the mix in this type of setup getting into increasing effort/complexity (an additional protocol) for dimishing returns? -- Hugo Slabbert | email, xmpp/jabber: hugo(a)slabnet.com pgp key: B178313E | also on Signal

4 3

Re: 10G switch drops traffic for a split second
by John Kristoff 29 Nov '16

29 Nov '16

On Tue, 29 Nov 2016 09:06:00 +0000 TJ Trout <tj(a)pcguys.us> wrote: > Could this be MTU? I've tried flow control, hard code duplex, stp on/off etc > I'm at a loss any ideas? This sounds like a common problem that certain data center environments run into with 10 Gb/s and higher loads. In a nutshell, a simple throw money at it solution to the problem is to use a switch with larger buffers. Nonetheless, there are plenty of good sources of material about the phenomenon, such as: <http://fasterdata.es.net/network-tuning/router-switch-buffer-size-issues/> <https://people.ucsc.edu/~warner/buffer.html> John

1 0

Accepting a Virtualized Functions (VNFs) into Corporate IT
by Kasper Adel 29 Nov '16

29 Nov '16

Hi, Vendor X wants you to run their VNF (Router, Firewall or Whatever) and they refuse to give you root access, or any means necessary to do 'maintenance' kind of work, whether its applying security updates, or any other similar type of task that is needed for you to integrate the Linux VM into your IT eco-system. Would this be an acceptable offering in today's IT from different type of Enterprises (Minux the Googles, Facebooks...etc) ? Thanks

9 10

Softlayer abuse contact
by Brian Ellwood 28 Nov '16

28 Nov '16

Could someone with Softlayer abuse contact me off list? I have a netblock that cannot communicate with your network - emailed abuse@ about 2 weeks ago and didn't hear back. Thank you.

2 1

IPv6 dumps on Oregon route views
by Anurag Bhatia 28 Nov '16

28 Nov '16

Hello everyone Was wondering if anyone is aware of mrt dump link for IPv6 dumps of Oregon route views? I see on the website it links to http://archive.routeviews.org/ipv6/ which gives a list of various collectors except for Oregon. The default "bgpdata" directory inside has dumps which are empty. On the Oregon route-views route-views.routeviews.org CLI: route-views> sh bgp ipv6 unicast summary BGP router identifier 128.223.51.103, local AS number 6447 BGP table version is 46628425, main routing table version 46628425 36322 network entries using 9879584 bytes of memory 700439 path entries using 100863216 bytes of memory 331618/17259 BGP path/bestpath attribute entries using 82241264 bytes of memory 3607348 BGP AS-PATH entries using 175182046 bytes of memory 111346 BGP community entries using 11638354 bytes of memory 793 BGP extended community entries using 34044 bytes of memory 0 BGP route-map cache entries using 0 bytes of memory 0 BGP filter-list cache entries using 0 bytes of memory BGP using 379838508 total bytes of memory BGP activity 8323321/7623230 prefixes, 545522618/517975111 paths, scan interval 60 secs Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 2001:388:1::13 4 7575 0 0 1 0 0 never Active 2001:388:1::16 4 7575 57344 1861 46628302 0 0 14:12:16 34047 2001:418:0:1000::F016 4 2914 148129 7618 46628302 0 0 2d10h 32871 2001:470:0:1A::1 4 6939 14390766 202805 46628302 0 0 18w2d 32990 2001:590::451F:6FF4 4 4436 0 0 1 0 0 never Active 2001:668:0:3:FFFF:0:ADCD:39EA 4 53364 1255881 57104 46628302 0 0 5w1d 33142 2001:918:0:5::1 4 3303 61123 3849 46628302 0 0 2d10h 32994 and much more. I am trying to look for mrt dump of this specific collector. Thanks. -- Anurag Bhatia anuragbhatia.com

2 2

Voice channels (FTTH, DOCSIS, VoLTE)
by Jean-Francois Mezei 28 Nov '16

28 Nov '16

I need to verify some claims made by incumbents in Canada that VoLTE data travels on a totally separate channel between the phone and the antenna. Does anyone have links to relevant VoLTE documentation that would provide how VoLTE is provisioned ? I was under the impression that it was more of an "app" on the phone that used the same IP address given for access to Internet. Does the phone get a separate IP and possibly separate VLAN with dedicated bandwidth to ensure voice call quality? Or are all the performance tricks done on land beyond the antenna once the packets are identified as VoLTE, but the phone itself just treats them as a normal app ? I know that for FTTH, there is a separate "channel" where the "POTS" emulation can be provided with its own dedicated IP and bandwidth. Would DOCSIS be the same as FTTH, with the cableco voice service riding isnide the same DOCSIS bandwidth but with pre-allocated bandwidth, or do they allocate separate NTSC channels with a totally separate data pipe ? (in which case, in systems with only 42mhz of uplink frequencies, the voice would have its own NTSC channel on uplink?

7 11