- Test - lists.nanog.org

Encrypted RPC and firewalling
by Lasse Birnbaum Jensen 10 Nov '11

10 Nov '11

hi all I would like to know how you guys handle encypted rpc across firewalls. We utilize an ASA platform and the DCERPC inspection cant handle encrypted RPC (which is standard in most windows 2008 and default in all communication in exchange 2010). Ciscos says: disable encryption or create "allow any" rules. Do you limit the RPC port range on the windows systems and make "holes" in the firewall for these or do you disable RPC encryption ? Please share your knowledge in this area. Best regards Lasse Birnbaum Jensen Network administrator, IT-Service University of Southern Denmark Email: lasse(a)sdu.dk

3 2

Anyone seen this kind of problem? SIP traffic not getting to destination but traceroute does
by Jay Nakamura 10 Nov '11

10 Nov '11

We ran into a strange situation yesterday that I am still trying to figure out. We have many VoIP customers but yesterday suddenly select few of them couldn't reach the SIP provider's network from our network. I could traceroute to the SIP providers server from the affected clients' IP just fine. I confirmed that the SIP traffic was leaving our network out the interface to the upstream provider and the SIP provider says they couldn't see the SIP traffic come into their border router. SIP traffic coming from SIP provider to the affected customer came through fine. It's just Us -> SIP server was a problem. I thought there may be some strange BGP issue going on but we had other customers within the same /24 as the affected customers and they were connecting fine. The traffic at the time traversed Our network -> Qwest/century link -> Level 3 -> SIP provider I changed the routing around so it would go through our other upstream, AT&T, and it started working. With AT&T, the route was Our network -> AT&T -> Level 3 -> SIP provider So my questions is, is it possible there is some kind of filter at Qwest or Level 3 that is dropping traffic only for udp 5060 for select few IPs? That's the only explanation I can come up with other than the whole Juniper BGP issue 2 days ago left something in between in a strange state? I read the post about XO doing filtering on transit traffic, I haven't seen anyone say Level 3 or Qwest is doing the same.

10 12

Performance Issues - PTR Records
by Matt Chung 09 Nov '11

09 Nov '11

I work for a regional ISP and very recently there has been an influx of calls reporting "slowness" when accessing certain websites (i.e google.com/voice/b) via HTTP. After performing a tcpdump and analyzing the session, I have been able to pinpoint the latency at the application layer. After the tcp session has been established, it takes up to 15-20 seconds before the application begins sending data. The root of the problem was that the PTR record for our customer(s) address does not exist. As soon as the record is created, latency from the application is eliminated. This is analogous to latency when accessing a server over SSH when no PTR is available. A seperate packet capture from another customer exhibiting similar performance behavior showed many TCP retransmissions. At first glance, I assumed this was network related however this correlates with the application not responding and inducing retransmissions at the TCP layer (different symptoms, same problem). Historically, there was no compelling reason to create PTR records for our CPE however more and more applications seem to be dependent on it. Although we will be assigning a record for each address, my question is why is the application (specifically HTTP) dependent on a reverse record ? What is the purpose? Hope this is helpful as well -- -Matt Chung

26 39

Logs Bank
by joshua.klubi＠gmail.com 09 Nov '11

09 Nov '11

Hi, If I may ask, is there any OSS that can serve as a log bank or log server, where it aggregate logs from different sources , and the logs can be accessed using the web from any location on the network and can do graphical presentations based on.the frequency or content os the logs. Thank you Joshua -- Sent from my Nokia N9

9 9

where was my white knight....
by bmanning＠vacation.karoshi.com 09 Nov '11

09 Nov '11

how would a sidr-enabled routing infrastructure have fared in yesterdays routing circus? /bill

11 25

comments due 2dec2011
by bmanning＠vacation.karoshi.com 08 Nov '11

08 Nov '11

http://www.nist.gov/itl/cloud/index.cfm /bill

1 0

Re: where was my white knight....
by Christopher Morrow 08 Nov '11

08 Nov '11

On Tue, Nov 8, 2011 at 1:14 PM, <bmanning(a)vacation.karoshi.com> wrote: > > that was/is kindof orthoginal to the question... would the sidr plan > for routing security have been a help in this event? nice to know > unsecured IPv6 took some of the load when the unsecured IPv4 path > failed. > if all routing goes boom, would secure routing have saved you? no... all routing went boom. > the answer seems to be NO, it would not have helped and would have actually > contributed to network instability with large numbers of validation requests > sent to the sidr/ca nodes. I think actually it wouldn't have caused more validation requests, the routers have (in some form of the plan) a cache from their local cache, they use this for origin validation... there's not a requirement to refresh up the entire chain. (I think). -chris > > /bill > > On Tue, Nov 08, 2011 at 10:01:04AM -0800, Mike Leber wrote: >> >> We saw an increase in IPv6 traffic which correlated time wise with the >> onset of this IPv4 incident. >> >> Happy eyeballs in action, automatically shifting what it could. >> >> Mike. >> >> On 11/8/11 2:56 AM, bmanning(a)vacation.karoshi.com wrote: >> >how would a sidr-enabled routing infrastructure have fared in yesterdays >> >routing circus? >> > >> >/bill >> > > >

4 4

OT: Ars: Cicso v Adekeye
by Jay Ashworth 08 Nov '11

08 Nov '11

http://arstechnica.com/tech-policy/news/2011/07/a-pound-of-flesh-how-ciscos… -- Jay R. Ashworth Baylink jra(a)baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274

1 0

[NANOG-announce] Call for Communications Committee (CC) Volunteers
by Sylvie LaPerriere 08 Nov '11

08 Nov '11

NANOGers: The NANOG Communications Committee<http://www.nanog.org/governance/communications/>, as defined by the NANOG Bylaws, is a committee that is responsible for the NANOG mailing list, and other forms of electronic communication among the NANOG community as agreed with the Board of Directors. The Communications Committee is responsible for the administration and minimal moderation of the NANOG list, nanog(a)nanog.org, Also, the committee is responsible for the administration of other mailing lists and other forms of electronic communications among the NANOG community. The NANOG Board is seeking volunteers who are, or willing to become, members and are willing to serve on the Communications Committee. Please submit your name and interest statement to Board(a)nanog.org Thanks! Sylvie LaPerriere NANOG Chair - www.nanog.org _______________________________________________ NANOG-announce mailing list NANOG-announce(a)nanog.org https://mailman.nanog.org/mailman/listinfo/nanog-announce

1 0

Juniper MX960 Mqchip packet lenght error
by Ferretti Antonio 08 Nov '11

08 Nov '11

Hi all, After upgrading Juniper MX960 from 4x10Gbe DPCE to 16x10Gbe MPC, I see strange log messages like this: Fpc10 MQCHIP(0) LI Packet length error, pt entry 22 Seems to be only a "cosmetic" message, but today my team found some traffic dropped on interface on this card (before we only request check about log message). Has anyone the same problem? My software release is Junos 10.3R3.7. Thanks in advance. Antonio Ferretti Network Engineer Telecom Italia Sparkle Backbone IP&Data Operations Seabone 2nd Level Support Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie. This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks. [cid:00000000000000000000000000000001@TI.Disclaimer]Rispetta l'ambiente. Non stampare questa mail se non ? necessario.

2 1