March 2014 - Test - lists.nanog.org

None
by rwebb＠ropeguru.com 27 Mar '14

27 Mar '14

So I certainly admit I am a basic networking guy and in the past have not had to get into the nitty gritty of port statistics. I am trying to understand some statistics off a switch port in a Nexus 4001i. All TX and RX counters look normal except on the TX side, I am showing 1107597 input discards. Last clearing of show counters is 1d8h ago. I have it in my mind that this particular counter is dropping packets coming in from another port inside the switch that are to be transmitted out to the end server. So lets say the interface I am looking at is port 2 on the switch. So server 1 sends a packet to port 1 on the switch. That packet then traverses to backplane, or inside the same ASIC, to port 2 on the switch. It is then dropped and not transmitted out to server 2. Is the scenario I just presented correct? Not looking for the reason in this email, just that my logical understanding is correct. Robert Sent from my Verizon Wireless 4G LTE smartphone

2 2

RE: Switchport Counters
by rwebb＠ropeguru.com 27 Mar '14

27 Mar '14

Sent from my Verizon Wireless 4G LTE smartphone -------- Original message -------- From: rwebb(a)ropeguru.com Date:03/27/2014 11:52 AM (GMT-05:00) To: nanog(a)nanog.org Subject:

1 0

RE: [mailop] IPv6 DNSBL
by David Hofstee 27 Mar '14

27 Mar '14

I suggest reputation on the reply-to domain also (if authenticated of course). No more running to other IPs / ESPs if you are a bad boy. You can integrate it in browsers and show it there too (watch out; don't enter your email address here because they will spam you or have spam evading practices [if no authentication takes place]). Show the reputation in the email client if possible. And I would like fine-grained complaining possible (so everyone can filter like the big boys can, one might need the 'ham' numbers too). But you want to be sure such numbers are authentic. David Hofstee Deliverability Management MailPlus B.V. Netherlands (ESP) -----Oorspronkelijk bericht----- Van: mailop [mailto:mailop-bounces@mailop.org] Namens Michael Peddemors Verzonden: Thursday, March 27, 2014 1:06 AM Aan: mailop(a)mailop.org Onderwerp: Re: [mailop] IPv6 DNSBL On 14-03-26 04:42 PM, John Levine wrote: > As a reliable rule of thumb, any list that's large enough to be > interesting is also large enough to be compromised. > > I know people who have run whitelists at Returnpath, and I was in > charge of the never very successful Spamhaus whitelist. The ones at > Returnpath always said that much of the job was dealing with bullshit > and deception from people trying to sneak into the whitelist. At > Spamhaus, the main problem was that nearly all of the people willing > to go to the effort to be whitelisted didn't qualify, which wasn't > surprising, since people with good mail behavior rarely have trouble > getting their mail delivered. > > R's, > John Here Here.. (For instance, we recommend that people running filtering turn those off right away, eg SA..) But we do see a lot of people discussing this here, and at the risk of making even more noise on this list on this subject, and maybe we should kill the thread there.. It would be interesting to get a poll of sorts.. hands please.. (You can reply off-list) Options: 1) Only allow IPv4 to be used for MTA's 2) Create a Registry of Operators/IPs for MTA's on IPv6 3) Allow all IPv6 to be used for MTA's, and use blacklists 4) Other (Suggestions) And if you believe in item 2, (personally I am happy with 1 or 2 and open to 4) what would you expect such a registry to look like? -- "Catch the Magic of Linux..." ------------------------------------------------------------------------ Michael Peddemors, President/CEO LinuxMagic Inc. Visit us at http://www.linuxmagic.com @linuxmagic ------------------------------------------------------------------------ A Wizard IT Company - For More Info http://www.wizard.ca "LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd. ------------------------------------------------------------------------ 604-682-0300 Beautiful British Columbia, Canada This email and any electronic data contained are confidential and intended solely for the use of the individual or entity to which they are addressed. Please note that any views or opinions presented in this email are solely those of the author and are not intended to represent those of the company. _______________________________________________ mailop mailing list mailop(a)mailop.org http://chilli.nosignal.org/mailman/listinfo/mailop

3 3

Re: Level 3 blames Internet slowdowns on Technica
by Larry Sheldon 27 Mar '14

27 Mar '14

On 3/20/2014 10:47 PM, David Miller wrote: > Unless I am reading the tea leaves wrong "competition" will require > "regulation". "regulation" prevents "competition". That is why people want regulation. Look at this thread at the people who do not want to be competed-with at L1, for example. -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker)

18 42

Re: IPv6 isn't SMTP
by Larry Sheldon 27 Mar '14

27 Mar '14

On 3/25/2014 10:31 PM, Cutler James R wrote: > Wow, what a lot of NANOG traffic about IPv6 readiness for SMTP! > > Please explain my misunderstanding on the following: > > 1. IPv6 is a Routing Layer Protocol (with some associated helpers, like RA, ND, DHCP-PD, and the like). > > 2. SMTP is an Application Layer Protocol, supposedly independent of Routing and lower layers of the protocol stack. Various communities have added connection initiation requirements that sometimes impinge upon layer 3 by requiring name/address correlations in DNS and none of which depend directly on technical aspects of layer 3 addressing. [ignoring obsolescent MTA implementations] > > 3. Arguing about IPv6 in the context of requirements upon SMTP connections is playing that uncomfortable game with one’s own combat boots. And not particularly productive. > > I look forward to furthering my education. [applause] -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker)

3 2

Looking for 2M service in CA
by Edison Smith-Stubbs 26 Mar '14

26 Mar '14

Hi all, Apologies if this is the incorrect forum for this request, first time posting to the group! I work for an ISP in Australia and we have a requirement to deliver a service to a client site in CA. I'm not familiar with the American market but I'd be interested in chatting with providers who can deliver 2M tails between the following locations: A End: Washington Avenue, San Leandro CA B End: Equinix San Jose *OR *Coresite San Jose. Response off list to esmithstubbs(a)gmail.com would be appreciated. Thanks in advance! Ed

1 0

Re: why IPv6 isn't ready for prime time, SMTP edition
by Larry Sheldon 26 Mar '14

26 Mar '14

On 3/26/2014 2:16 PM, Paul Ferguson wrote: to a > paid service (e.g. "If you are not paying for a service, you are the > product."). That needs to be engraved in the glass screens of every device, like the "G.O.A.L" at the bottom of the rear-view mirror of some semi-truck tractors. -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker)

1 0

A little silly for IPv6
by Larry Sheldon 26 Mar '14

26 Mar '14

According to the Ace of Spades HQ blog: > IPv6 would allow every atom on the surface of the earth to have its > own IP address, with enough spare to do Earth 100+ times. -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker)

7 7

Cisco Security Advisory: Cisco IOS Software Crafted IPv6 Packet Denial of Service Vulnerability
by Cisco Systems Product Security Incident Response Team 26 Mar '14

26 Mar '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Cisco IOS Software Crafted IPv6 Packet Denial of Service Vulnerability Advisory ID: cisco-sa-20140326-ipv6 Revision 1.0 For Public Release 2014 March 26 16:00 UTC (GMT) Summary ======= A vulnerability in the implementation of the IP version 6 (IPv6) protocol stack in Cisco IOS Software and Cisco IOS XE Software could allow an unauthenticated, remote attacker to cause I/O memory depletion on an affected device that has IPv6 enabled. The vulnerability is triggered when an affected device processes a malformed IPv6 packet. Cisco has released free software updates that address this vulnerability. There are no workarounds to mitigate this vulnerability. This advisory is available at the following link: http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-… Note: The March 26, 2014, Cisco IOS Software Security Advisory bundled publication includes six Cisco Security Advisories. All advisories address vulnerabilities in Cisco IOS Software. Each Cisco IOS Software Security Advisory lists the Cisco IOS Software releases that correct the vulnerability or vulnerabilities detailed in the advisory as well as the Cisco IOS Software releases that correct all Cisco IOS Software vulnerabilities in the March 2014 bundled publication. Individual publication links are in Cisco Event Response: Semiannual Cisco IOS Software Security Advisory Bundled Publication at the following link: http://www.cisco.com/web/about/security/intelligence/Cisco_ERP_mar14.html -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org iQIcBAEBAgAGBQJTMeUtAAoJEIpI1I6i1Mx35GAP/jkk82q87zMnC9n9e2t9u1DD 7OHUYo7fuXu2L85+zDGgtE7LJ5c9mjZou12A87cjgx4v1B6xvDoemjtoIEmqWKQR LsSoI6oQL6E3PAqeDn70Lrr++kAV/4dCSzoFuiDWa5NLWO2NA1pxoRsF8f/KTENj PvPng8UPlF2WBDqNdTnjR2upDMqn1/jQOMxSSRmkMAOQ0Q3j+g9Pd+rb8ocqTJmg wCj5vXfB52E0HoGddT0UxjkxL1+CR9Jo262LeuRRtMGQsEpK94+L9d4kC/AhhclU RodAJztNC42KdFR4iE1jDHUA8HwhgnkdzuXlA12GIXeHB9EBQR5Te1hyzuAnxq5X x3IeqZnaufO2DmxAVpl3lfEDyKeyAipfCPDtFhEmDF/l12zBRlbMudEwA1Buwriq ayH4798ASI0bBumUiaMiiOyYKbqFL33ONdFMiQZv2lYam1QlYU0Ps3IMiZhD5YHX 9nOKcuWU1Uym+VjHiIKLg5/qQpndg9h+E6mNzZrQSXrpU1nYtwBCZiShBhR5+f4J WYLOVZu5LDpW6mQAhYyKC7ehugeqJZRaZQQX5oi94hlBxz1+4zin8GRVLn/Ibrtq GaeMGODALQjpolszEAt7a4QA5884m++h7Z4Crszr4s4E4j4bUdCEgDc9ynInmO80 OvU1rCkvg7QWSv3HfxI2 =nr53 -----END PGP SIGNATURE-----

1 0

Cisco Security Advisory: Cisco IOS Software Network Address Translation Vulnerabilities
by Cisco Systems Product Security Incident Response Team 26 Mar '14

26 Mar '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Cisco IOS Software Network Address Translation Vulnerabilities Advisory ID: cisco-sa-20140326-nat Revision 1.0 For Public Release 2014 March 26 16:00 UTC (GMT) Summary The Cisco IOS Software implementation of the Network Address Translation (NAT) feature contains two vulnerabilities when translating IP packets that could allow an unauthenticated, remote attacker to cause a denial of service condition. Cisco has released free software updates that address these vulnerabilities. There are no workarounds to mitigate these vulnerabilities. This advisory is available at the following link: http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-… Note: The March 26, 2014, Cisco IOS Software Security Advisory bundled publication includes six Cisco Security Advisories. All advisories address vulnerabilities in Cisco IOS Software. Each Cisco IOS Software Security Advisory lists the Cisco IOS Software releases that correct the vulnerability or vulnerabilities detailed in the advisory as well as the Cisco IOS Software releases that correct all Cisco IOS Software vulnerabilities in the March 2014 bundled publication. Individual publication links are in Cisco Event Response: Semiannual Cisco IOS Software Security Advisory Bundled Publication at the following link: http://www.cisco.com/web/about/security/intelligence/Cisco_ERP_mar14.html -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org iQIcBAEBAgAGBQJTMeUuAAoJEIpI1I6i1Mx3WmEQAI3rKhU7UnKxev8CKq4Hfp5I mBnX5uHKz+w5vNqgTPYL6y228XHsicFZKNfR9Z2PiyHjwdFq3ndZACYRiK5iKxme oRO3fLAv3Muhb0F0f4j8p6NvzDoE9uZMqIlvG709+VtFhwKeW6aziV9FPNVNbe33 Jnub4qi3AINnxalKiGixmN52rCkNficlHTgbsmvRscqF0NYVos4L+CEcuukyohOV jr41sRLO9/IvY1cwPtkQ5FHI/YLvD7/P1wzVr13eJkTdS28oD0Jo1yArvQJBf+Ae fvlnhoprtAhkGUSYlyUKF5HOCe8lScYMKvfP5Of56yLr+0RQuJty4X4hCX4+HbPd g3AI2yOUHGixLZAVV8GEsnbBtPnenPjqe7EAapyMT+YZx4ocD2dUPMfQTUcUye1r rOQeQjI+vX8NLzlS1paV0vImuN0rJi1phi4/Ne+XT5qSGic3tMZVGm8rsWiMNB8l qosaCwAXUx75KraBU2g8pe8iwmUSGQPFLZoMNkKjez/oEBKXAsCMgZYzsZpht4tg kiDMU2W7OlVPkMcg6Jym/L6bLSzCUekkSREshd2KxzLm4hRSZOX36RNL5wKGjCxQ 94myZA59h4L53lmLUYpsqH6KJafW7NPL/u+YQOQ6qO9iH8c/m04mVCQ2Y05rtDPX OZnQJUm5po9ws6ylHFKw =7Q5K -----END PGP SIGNATURE-----

1 0