- NANOG - lists.nanog.org

Zayo Contact
by Dennis Burgess 26 Aug '15

26 Aug '15

I have a customer with a fiber outage with some Zayo IPs, Zayo is adverting the /24, would love to have someone contact me from zayo; as we need that advertisement turned off so we can get inbound though another provider until the fiber is fixed.:( Thanks, [DennisBurgessSignature] www.linktechs.net<http://www.linktechs.net/> - 314-735-0270 x103 - dmburgess(a)linktechs.net<mailto:dmburgess@linktechs.net>

1 0

BRAS sugestion
by Julian Eble 26 Aug '15

26 Aug '15

Hello Nanog, Our company are constantly growing and we're looking for a 30k+ subscribers BRAS, does the community have a sugestion? Thank you!

15 14

LTE
by Nathan Anderson 26 Aug '15

26 Aug '15

Is there anybody here who is fluent in LTE/3GPP networks and the standards that govern them? I'm not sure where else to look. I have a very specific question about UEs, UICCs, and the security negotiation (integrity & ciphers) that occurs during attachment both on the AS and NAS layers, and so far I have not found our vendor to be very helpful. If there is somebody out there that knows something about this area, and is willing to chat with me about it, feel free to drop me a line off-list. Thanks much, -- Nathan Anderson First Step Internet, LLC nathana(a)fsr.com

3 3

Peering + Transit Circuits
by Tim Durack 25 Aug '15

25 Aug '15

Question: What is the preferred practice for separating peering and transit circuits? 1. Terminate peering and transit on separate routers. 2. Terminate peering and transit circuits in separate VRFs. 3. QoS/QPPB ( https://www.nanog.org/meetings/nanog42/presentations/DavidSmith-PeeringPoli… ) 4. Don't worry about peers stealing transit. 5. What is peering? Your comments are appreciated. -- Tim:>

13 23

Re: [c-nsp] Peering + Transit Circuits
by Mark Tinka 25 Aug '15

25 Aug '15

On 25/Aug/15 14:23, Brian Turnbow wrote: > Or use uRPF with an acl. > You can specify what to block and what not to block and use S/RTBH as well. Even though we're not receiving the full feed on dedicated peering routers, you're talking at least 35% of it. Sometimes more... Mark.

1 0

Re: [c-nsp] Peering + Transit Circuits
by Mark Tinka 25 Aug '15

25 Aug '15

On 25/Aug/15 13:58, Scott Granados wrote: > If you’re not enabling URPF at the peering routers and edges how do you handle things like RTBH? D/RTBH still works fine. S/RTBH would be an issue, but one could enable uRPF temporarily for that. Mark.

1 0

Re: [c-nsp] Peering + Transit Circuits
by Tim Durack 25 Aug '15

25 Aug '15

On Tue, Aug 18, 2015 at 11:25 AM, Scott Granados <scott(a)granados-llc.net> wrote: > So in our case we terminate peering and transit on different routers. > Peering routers have well flow enabled (the one that starts with a J that’s > inline). With NFSEN / NFDUMP we’re able to collect that flow data and look > for anomalous flows or other issues. We pretty much detect and then deal > with peering issues rather than prevent them with whitelists and so forth > but then again we’ve been lucky and not experienced to many issues other > than the occasional leakage of prefixes and such which maxprefix handles > nicely. > > Can I ask why you terminate peering and transit on different routers? (Not suggesting that is bad, just trying to understand the reason.) Tim:>

2 1

Re: [c-nsp] Peering + Transit Circuits
by Tim Durack 25 Aug '15

25 Aug '15

On Tue, Aug 18, 2015 at 8:47 AM, Gert Doering <gert(a)greenie.muc.de> wrote: > Hi, > > On Tue, Aug 18, 2015 at 08:29:31AM -0400, Tim Durack wrote: > > 4. Don't worry about peers stealing transit. > > 5. What is peering? > > I'm afraid that the majority of answers will be 4./5., mixed with > "6. what? how can peers stell my transit?!" > > We're somewhat into the "we'll notice if there is surprisingly high > inbound traffic on peering, and then we'll find the peer, and apply > appropriate measures" camp... (since we're a hosting shop, we have mostly > outgoing traffic, so "significant" amounts of incomnig traffic stick > out). > > But yeah, something more strict might be in order. > Thanks for the response. This is what I was guessing. We currently do "2. Terminate peering and transit circuits in separate VRFs." which works well when everything is a VRF but comes at the cost of higher resource usage (RIB & FIB.) I was thinking a creative solution might be: "7. DSCP mark packets on peering ingress, police on transit egress." Not sure if I really want to get into using DSCP bits for basic IP service though. > (It would be cool if Cisco would understand that hardware forwarding > platforms need useful netflow with MAC-addresses in there... ASR9k at > least got working MAC-accounting, but more fine grained telemetry would > certainly be appreciated. Software IOS can do it, Sup720 cannot do it > due to hardware constraints, Sup2T exports MAC addresses taken from random > caches in the system but not the inbound packets, XR doesn't do it at all, > hrmph) > gert > > -- > USENET is *not* the non-clickable part of WWW! > // > www.muc.de/~gert/ > Gert Doering - Munich, Germany > gert(a)greenie.muc.de > fax: +49-89-35655025 > gert(a)net.informatik.tu-muenchen.de > -- Tim:>

2 1

AfPIF 2015 Livestream
by Joly MacFie 25 Aug '15

25 Aug '15

Just about to start https://livestream.com/internetsociety/afpif2015/ -- --------------------------------------------------------------- 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 -------------------------------------------------------------- -

1 0

Data Center operations mail list?
by Chris Boyd 24 Aug '15

24 Aug '15

Is there a mail list that’s analogous to NANOG, but focused on the data center infrastructure and operations? The shorty.com hosted list is defunct. Thanks, and apologies for the tangential topic. —Chris

28 49