- Test - lists.nanog.org

udp 500 packets when users are web browsing
by Robert Webb 03 Sep '15

03 Sep '15

We are seeing udp 500 packets being dropped at our firewall from user's browsing sessions. These are users on a 2008 R2 AD setup with Windows 7. Source and destination ports are udp 500 and the the pattern of drops directly correlate to the web browsing activity. We have confirmed this with tcpdump of port 500 and a single host and watching the pattern of traffic as they browse. This also occurs no matter what browser is used. Can anyone shine some light on what may be using udp 500 when web browsing? Robert

4 7

Level 3 (former TW Telecom) Routing Contact
by ï»¿Stephen Amato 02 Sep '15

02 Sep '15

Can someone from Level 3 (former TW Telecom) please contact me off-list regarding a possible routing issue with some 172.0.0.0/8 IP space (non RFC 1918)? Thank you,S.Amato saamato(a)frontiernet.net

1 0

RE: BGP advertise-best-external on RR
by Jakob Heitz (jheitz) 02 Sep '15

02 Sep '15

If your network is such that only a handful of routers supply redundant paths, then you can set up iBGP sessions with those directly without going via route reflectors. You can have most routes going through reflectors and a few through direct BGP sessions. Not everything needs to go through route reflectors. You can even do both: Have a router peer with a reflector as well as directly if you only need the redundant routes in a few places. You will end up with duplicate routes, but that's not a show stopper. You can avoid duplicate routes with route maps. You can have multiple route reflectors with different cluster IDs that carry the redundant routes only. Clients can peer with multiple clusters. Use route maps to avoid duplicate routes. These last things get complicated to manage, so I'd still go for add-path if at all possible. --Jakob > Message: 2 > Date: Tue, 1 Sep 2015 14:51:27 +0200 > From: Mohamed Kamal <mkamal(a)noor.net> > To: Jeff Tantsura <jeff.tantsura(a)ericsson.com>, Diptanshu Singh > <diptanshu.singh(a)gmail.com> > Cc: NANOG <nanog(a)nanog.org> > Subject: Re: BGP advertise-best-external on RR > Message-ID: <55E59F4F.8010704(a)noor.net> > Content-Type: text/plain; charset=windows-1252; format=flowed > > Hi, > > Diverse-path will only send the second best path, and in my case I have > three routes not two. In addition to that, every PE will have to peer > with the RR via a second session (on the same RR, as I will not deploy a > new standalone shadow RR) and this will increase the BGP sessions to the > double. > > Add-path will have a network-wide IOS upgrade for this BGP capability to > be supported which is not viable now. > > So, is there any other recommendation other than the internet VRF with > different RDs solution? > > Regards, > > Mohamed Kamal > Core Network Sr. Engineer > > On 8/25/2015 11:37 AM, Jeff Tantsura wrote: > > Hi, > > > > In your case I?d recommend to use diverse path, due to its simplicity and > > non disruptive deployment characteristics. > > As you know - diverse path requires additional BGP session per additional > > (second, next, etc) path, in most cases not a problem, however mileage > > might vary. > > > > To my memory, in Cisco land - it has only been implemented in IOS, not XR, > > please check. > > > > Cheers, > > Jeff > > > > > > > > > > -----Original Message----- > > From: Diptanshu Singh <diptanshu.singh(a)gmail.com> > > Date: Monday, August 24, 2015 at 10:53 PM > > To: Mohamed Kamal <mkamal(a)noor.net> > > Cc: "nanog(a)nanog.org" <nanog(a)nanog.org> > > Subject: Re: BGP advertise-best-external on RR > > > >> Yes . In the case of diverse path , shadow route reflector will be the > >> one wherever you enable commands to trigger diverse path computation. > >> > >> Good thing with diverse path is that the RR-Clients don't have to have > >> any support but bad thing is that it can only reflect One additional > >> best-path( second best path ) . > >> > >> Sent from my iPhone > >> > >>> On Aug 24, 2015, at 2:31 PM, Mohamed Kamal <mkamal(a)noor.net> wrote: > >>> > >>> It's only supported on the 15.2(4)S and later not the SRE train. I > >>> might consider an upgrade. > >>> > >>> One more question regarding this, can you configure the RR to be the > >>> main and shadow RR? > >>> > >>> Mohamed Kamal > >>> Core Network Sr. Engineer > >>> > >>>> On 8/24/2015 9:16 PM, Diptanshu Singh wrote: > >>>> BGP Add-Path might be your friend . You can look at diverse-path as > >>>> well . > >

1 0

Spotify contact
by Marco Paesani 02 Sep '15

02 Sep '15

Hi, I need a network contact for network issue in Italy. Can you help me ? Thanks ! Regards, -- Marco Paesani MPAE Srl Skype: mpaesani Mobile: +39 348 6019349 Success depends on the right choice ! Email: marco(a)paesani.it

1 0

2nd Call for presentations RIPE 71
by Benno Overeinder 02 Sep '15

02 Sep '15

Colleagues, Please note the approaching deadline of 13 September 2015 for RIPE 71 plenary programme submissions. You can find the CFP for RIPE 71 below, or at https://ripe71.ripe.net/submit-topic/cfp/, for your proposals for plenary session presentations, tutorials, workshops, BoFs (Birds of a Feather sessions) and lightning talks. Please also note that speakers do not receive any extra reduction or funding towards the meeting fee at the RIPE Meetings. Kind regards, Benno Overeinder RIPE PC Chair https://www.ripe.net/participate/meetings/ripe-meetings/pc ---------------------------------------- Call for Presentations A RIPE Meeting is an open event where Internet Service Providers, network operators and other interested parties get together. Although the meeting is mostly technical, it is also a chance for people to meet and network with others in their field. RIPE 71 will take place from 16-20 November 2015 in Bucharest, Romania. The RIPE Programme Committee (PC) is now seeking content proposals from the RIPE community for the plenary sessions, BoFs (Birds of a Feather sessions), panels, workshops, tutorials and lightning talks at RIPE 71. See the full descriptions of the different presentation formats, https://ripe71.ripe.net/submit-topic/presentation-formats/. Proposals for plenary sessions, BoFs, panels, workshops and tutorials must be submitted for full consideration no later than 13 September 2015. Proposals submitted after this date will be considered depending on the remaining available space in the programme. The PC is looking for presentations covering topics of network engineering and operations, including but not limited to: - IPv6 deployment - Managing IPv4 scarcity in operations - Commercial transactions of IPv4 addresses - Data centre technologies - Network and DNS operations - Internet governance and regulatory practices - Network and routing security - Content delivery - Internet peering and mobile data exchange Submissions RIPE Meeting attendees are quite sensitive to keeping presentations non-commercial, and product marketing talks are strongly discouraged. Repeated audience feedback shows that the most successful talks focus on operational experience, research results, or case studies. For example, presenters wishing to describe a commercial solution should focus on the underlying technology and not attempt a product demonstration. Presenters should indicate how much time they will require. In general, the time allocated for the different presentation formats is as follows: - Plenary presentations: 20-25 minutes presentation with 5-10 minutes discussion - Tutorials: up to two hours (Monday morning) - Workshops: one hour (during evening sessions) to two hours (Monday morning) - BoFs: approximately one hour - Lightning talks: 10 minutes The following general requirements apply: - Proposals must be submitted using the meeting submission system, https://ripe71.ripe.net/submit-topic/submission-form/. - Lightning talks should also be submitted using the meeting submission system (https://ripe71.ripe.net/submit-topic/submission-form/) and can be submitted any time up to and including the meeting week. The allocation of lightning talks will be announced on short notice---in some cases on the same day but often one day prior to the time slot allocated. - Presenters who propose a panel or BoF are encouraged to include speakers from several (perhaps even competing) companies and/or a neutral facilitator. - All presentation proposals will only be considered by the PC if they contain at least draft presentation slides (slides may be updated later on). For panels, proposals must contain a clear description, as well as the names of invited panellists, presenters and moderators. - Due to potential technical issues, presenters/panellists should be physically present at the RIPE Meeting. If you have any questions or requests concerning content submissions, please email pc [at] ripe [dot] net. -- Benno J. Overeinder NLnet Labs http://www.nlnetlabs.nl/

1 0

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

02 Sep '15

Agreed, we are as well :) VLAN, VRF, whatever. + optimal tweaks include local flow proxy that can also rate limit / re-sample, and send topk talkers over 'true' OOB. Avi Freedman CEO, Kentik avi at kentik dot com > On 2 Sep 2015, at 7:27, Avi Freedman wrote: > > > We see well under 20% doing logical separation but definitely folks > > doing it... > > ~20% matches our subjective observations, as well. > > We're doing our best to increase that number. > > ----------------------------------- > Roland Dobbins <rdobbins(a)arbor.net>

2 1

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