November 2011 - Test - lists.nanog.org

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

08 Nov '11

Thx David, PR587266 seems to be related to "maximum-packet-lenght" command that is not present in my config. Biggest problem in this case are dropped packet on interface: Physical interface: xe-10/0/1, Enabled, Physical link is Up Interface index: 363, SNMP ifIndex: 645, Generation: 483 Description: No Description Link-level type: Ethernet, MTU: 1514, LAN-PHY mode, Speed: 10Gbps, Loopback: None, Source filtering: Disabled, Flow control: Enabled Device flags : Present Running Interface flags: SNMP-Traps Internal: 0x4000 Link flags : None CoS queues : 8 supported, 8 maximum usable queues Hold-times : Up 0 ms, Down 0 ms Current address: 00:24:dc:49:be:73, Hardware address: 00:24:dc:49:be:73 Last flapped : 2011-10-27 03:11:07 UTC (1w5d 12:18 ago) Statistics last cleared: 2011-11-08 13:15:03 UTC (02:14:38 ago) Traffic statistics: Input bytes : 4674308593808 5182909688 bps Output bytes : 6092283580895 6656998280 bps Input packets: 8393093736 1149495 pps Output packets: 6971170539 941600 pps IPv6 transit statistics: Input bytes : 23569859 Output bytes : 0 Input packets: 197870 Output packets: 0 Dropped traffic statistics due to STP State: Input bytes : 0 Output bytes : 0 Input packets: 0 Output packets: 0 Input errors: Errors: 0, Drops: 0, Framing errors: 0, Runts: 0, Policed discards: 0, L3 incompletes: 0, L2 channel errors: 0, L2 mismatch timeouts: 0, FIFO errors: 0, Resource errors: 0 Output errors: Carrier transitions: 0, Errors: 0, Drops: 0, Collisions: 0, Aged packets: 0, FIFO errors: 0, HS link CRC errors: 0, MTU errors: 0, Resource errors: 0 Egress queues: 8 supported, 8 in use Queue counters: Queued packets Transmitted packets Dropped packets 0 be 6973872756 6887958719 85914037 1 ef 25695717 25695717 0 2 ef1 2062122 2062122 0 3 ef2 21430966 21430966 0 4 af 2605818 2605818 0 5 af1 1577987 1577987 0 6 nc 5928647 5928647 0 7 nc1 24705296 24705296 0 I'm wondering if is something related to CoS that is managed in different way from the two type of linecard. Regards Antonio Ferretti Network Engineer Telecom Italia Sparkle TIS.AD.NDO.O Backbone IP&Data Operations Seabone 2nd Level Support Via di Macchia Palocco, 223 00125 Roma, Italia -----Messaggio originale----- Da: david.roy(a)orange.com [mailto:david.roy@orange.com] Inviato: martedì 8 novembre 2011 16.13 A: Ferretti Antonio; nanog(a)nanog.org Oggetto: RE: Juniper MX960 Mqchip packet lenght error Hi, See the PR587266. Maybe you have Syslog/log statement in a FW filter term. Regards David David Roy Orange - IP Domestic Backbone - TAC Tel. +33(0)299876472 Mob. +33(0)685522213 Email. david.roy(a)orange.com Skype : davidroy.35 JNCIE-SP #703 Guest Haiku : IS-IS screams, BGP peers are flapping: I want my mommy! -----Message d'origine----- De : Ferretti Antonio [mailto:antonio.ferretti@telecomitalia.it] Envoyé : mardi 8 novembre 2011 15:35 À : nanog(a)nanog.org Objet : Juniper MX960 Mqchip packet lenght error 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. ******************************************************************************** IMPORTANT.Les informations contenues dans ce message electronique y compris les fichiers attaches sont strictement confidentielles et peuvent etre protegees par la loi. Ce message electronique est destine exclusivement au(x) destinataire(s) mentionne(s) ci-dessus. Si vous avez recu ce message par erreur ou s il ne vous est pas destine, veuillez immediatement le signaler a l expediteur et effacer ce message et tous les fichiers eventuellement attaches. Toute lecture, exploitation ou transmission des informations contenues dans ce message est interdite. Tout message electronique est susceptible d alteration. A ce titre, le Groupe France Telecom decline toute responsabilite notamment s il a ete altere, deforme ou falsifie. De meme, il appartient au destinataire de s assurer de l absence de tout virus. IMPORTANT.This e-mail message and any attachments are strictly confidential and may be protected by law. This message is intended only for the named recipient(s) above. If you have received this message in error, or are not the named recipient(s), please immediately notify the sender and delete this e-mail message. Any unauthorized view, usage or disclosure ofthis message is prohibited. Since e-mail messages may not be reliable, France Telecom Group shall not be liable for any message if modified, changed or falsified. Additionally the recipient should ensure they are actually virus free. ******************************************************************************** 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.

1 0

XO blocking individual IP's
by clayton＠haydel.org 08 Nov '11

08 Nov '11

I'm hoping someone has had the same experiences, and is further toward a resolution on this than I am. About 6 months ago, we noticed that XO was blackholing one specific IP out of a /24. Traces to that IP stopped on XO's network, traces to anything else out of the block went through fine. XO finally admitted that they had a new security system that identifies suspicious traffic and automatically blocks the IP for 30 minutes. We had to get the IP in question "whitelisted" by their security guys. The traffic was all legit, it was just on a high port # that they considered suspicious. There have several more cases like this, and XO has not been forthcoming with information. We're either looking to be exempted from this filtering or at least get a detailed description of how the system works. I'm not sure how they think this is acceptable from a major transit provider. Anybody else had similar problems? Clayton Haydel

5 6

IPv6World:Asia - Deployment Experience with IPv6
by Joly MacFie 08 Nov '11

08 Nov '11

For any of you who are working late, we are just about to start (2am-4am EST) a live webcast of a "Deployment Experience with IPv6" event from Hong Kong. Fred Baker is the keynote speaker. Webcast: http://www.livestream.com/internetsocietychapters/ More info: http://isoc-ny.org/p2/?p=2630 -- --------------------------------------------------------------- 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

Re: [outages] Time Warner Cable outage
by Jay Ashworth 07 Nov '11

07 Nov '11

----- Original Message ----- > From: "Dustin Rhodes" <DRhodes(a)fiberutilities.com> > Sounded like someone was broadcasting a BGP route with an invalid > attribute and caused BGP session restarts or Core Dumps/crashes on any > Juniper router running version 10.4 Well, it *is* getting on towards Christmas... Cheers, -- jr '*really*, Juniper?' a -- 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

RE: Cell-based OOB management devices
by ebarrios＠gobarrios.com 07 Nov '11

07 Nov '11

1 0

Re: Cell-based OOB management devices
by Edward Salonia 07 Nov '11

07 Nov '11

I would look into Uplogix. I've seen them demo their products at Cisco Live a couple of times and they seem very good. - You can connect a cellular modem to them. - They can store backup device configs. - They can store IOS images. - They can even xmodem an image to a device if it gets stuck in ROMMON. - Some of this can even be automated by their device. ------Original Message------ From: David Hubbard To: nanog(a)nanog.org Subject: Cell-based OOB management devices Sent: Nov 7, 2011 1:14 AM Hi all, I am looking at cellular-based devices as a higher speed alternative to dial-up backup access methods for out of band management during emergencies. I was wondering if anyone had experiences with such devices they could share? Devices I've found include Sierra Wireless AirLink Raven X, Digi's ConnectWAN 3G or 4G and Opengear's ACM5004-G. I have no experience with any but they all appear to support the Sprint network which I assume would be ideal due to not having usage caps on data (currently). The Opengear device runs linux and has four serial ports, a usb port for additional storage and ethernet, so it seems to have some small advantages over the others since it could double as an emergency self-contained management station you can SSH into and run diagnostics from. All appear to have VPN/gateway support. What none of them are clear on is how you would connect to it over cellular since I assume you're just paying for a typical data plan and it will randomly obtain IP addresses. Maybe some type of dynamic dns service so you can easily figure out your device's current IP? How stable is the access to the device? Any idea if any of them can do ipv6? Thanks! David

1 0

IPv6 beta support for Android phones
by Cameron Byrne 07 Nov '11

07 Nov '11

FYI. T-Mobile USA now has opt-in beta support for an Android phone on IPv6, more info here https://sites.google.com/site/tmoipv6/lg-mytouch As far as i know, this is the first Android phone that support IPv6 on the GSM/UMTS mobile interface. Previous version of Android phones supported IPv6 on WiFi and LTE. Cameron

8 9

TATA problems?
by Todd Snyder 07 Nov '11

07 Nov '11

We seem to be having some problems with our tata links - first seen in EU about 45 minutes ago, now we're seeing problems in NA. I'm focused on DNS, so I'm seeing a lot of timeouts/servfails, but our networking folks are talking about links dropping. Anyone else seeing oddness on the NA Internet right now? http://downrightnow.com/ confirms - something is up. cheers, t.

17 27

mtu question. more should be better, right?
by Deric Kwok 07 Nov '11

07 Nov '11

Hi all When I setup the server mtu as 9100. why I have to configure the switch mtu 9300 to make it working? What this extra 200 bytes is for what purpose? ls it standard? What is disadvantage of setting our all internal networks (host / equipment) mtu more than 1500? Thank you for your advice.

3 2

Router and interface naming convention survey
by Joseph Chabarek 07 Nov '11

07 Nov '11

I am doing a survey to see what naming conventions are used for routers and router interfaces as part of a measurement study that I am conducting as a student at the University of Wisconsin Madison. If you are interested in participating please fill out my form at: https://docs.google.com/spreadsheet/viewform?formkey=dE1OYmVGcjlxV1YtZjB1Qm… I am aware that this issue has been discussed extensively on nanog (and other lists). The purpose of this survey is to see in a structured manner which networks use which conventions, and get an idea for how automated the process of PTR record generation is across different providers. I am happy to provide high level results from the survey to anyone that is interested. Thanks for any feedback! -Joe http://www.cs.wisc.edu/~jpchaba

2 1