September 2014 - Test - lists.nanog.org

Cisco Security Advisory: Cisco IOS Software RSVP Vulnerability
by Cisco Systems Product Security Incident Response Team 24 Sep '14

24 Sep '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Cisco IOS Software RSVP Vulnerability Advisory ID: cisco-sa-20140924-rsvp Revision 1.0 For Public Release 2014 September 24 16:00 UTC (GMT) Summary +====== A vulnerability in the implementation of the Resource Reservation Protocol (RSVP) in Cisco IOS Software and Cisco IOS XE Software could allow an unauthenticated, remote attacker cause the device to reload. This vulnerability could be exploited repeatedly to cause an extended denial of service (DoS) condition. Cisco has released free software updates that address this vulnerability. A workaround that mitigates this vulnerability is available. This advisory is available at the following link: http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-… Note: The September 24, 2014, Cisco IOS Software Security Advisory bundled publication includes six Cisco Security Advisories. All advisories address vulnerabilities in Cisco IOS Software. 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_sep14.html -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org iQIcBAEBAgAGBQJUIZNfAAoJEIpI1I6i1Mx3qoIP/RnDEwuhG4SEtyEAycEOpJoX cDsmK8C0xRKYkoUeSlmkO1TXzRk42RMnd6aoYAxojgqsYnVt10ZKibSLzCxZxWnX MMKhMPSrUSvWvPNgLDYyOJ4R4B6IOwYwS6wNCABtiwes/rET+p+d0gw4rZ4SLujF hSrWcxE8Fax5zU7Z++ZifOhcg/C7gGvIbsuStf01S6/oZHPx8PXnVj9J4eI0Yxz9 JRhkJQv8FlfJYzZnxbi545YH1fUt+e5FzTTlPOaYayYqi0E/NvrPW64s8QKLURE7 M01EzxIsyItwxIYAXy5pcUHnyAd/bZ21CmEiHvOq4GZVXoZpkkF0pCceos+mC987 4mPYVe+PwNrPJwb0qdG6MKDiXmO+txVFLazNF2JJaGeFYjeN+If57mJSttznVLiE ZPCkdLmr/Y2uDbtwoDdFI6TbrIsFceawIEKLn5lIPQrtt+JiwkWkxKSLMsB6wm0l nmogpIL43jgnozrYRTMizA+hu/mHgg88mOWD/AAFA5O6K+YQIEYYtYjy4Bundrq7 2Rr6uJNUN9fD3amT3ZqP6DE7ETlAkC29sFy0IuXkudpXc+YrcVAkhwrlMekoeepL t6cWl+o8dTaexJe7h4neuADwCPrT15wNBiasHP0Uw/BAUnbPM2aOjL8WZDb1BHvT 5AkSuOMpsSZakqt0vik+ =kL1E -----END PGP SIGNATURE-----

1 0

Google Services Problems?
by Jason Lester 24 Sep '14

24 Sep '14

Is anyone else seeing intermittently down or very slow access to Google services like YouTube and Google Play Store? We have two upstream providers: one peers with XO and Level3, one with Qwest. When our Google traffic is preferring the route through XO, we see things like YouTube videos not loading, Android devices not able to download updates, Google Play Music not streaming, etc. The main source network we are seeing it from is 206.111.9.XXX which is owned by XO according to whois, but seems to be sourcing Google traffic. I assume they are caching or CDN servers of some type for Google that are hosted at XO. The problem started on Friday as far as we can tell. We had a similar problem a few weeks ago with Google Images searching. The search result page showed the same thumbnail (a car crash) for anything you searched for. It was again being sourced from the 206.111.9.XXX network. Clicking on the image showed you the proper image, just the thumbnails were wrong. It cleared up in a couple of hours in that case, but the current problem has been going on for a while. Thanks, Jason

1 0

IPV6 Multicast Listener storm control?
by Richard Holbo 23 Sep '14

23 Sep '14

(originally posted to wispa ipv6 list, and someone there mentioned that folks here might have some suggestions, so apologize if you are a member of both.) I am seeing issues with IPV6 multicast storms in my network that are fairly low volume (1-2mbit), but that are causing service disruptions due to CPU load on the switches and that the network is a Point to MultiPoint wireless network. I have about 500 IPV4 clients on a vlan served by Cisco ME3400, Catalyst 3750 and 3560 switches. These are switched back to a routed interface and IP addresses are assigned by DHCP. We are not using IPV6 at all, and I don't have control of the clients. What I'm seeing is IPV6 Multicast Listener requests from a single client (different clients at different times) going out on the network, the switches manage them in software, so CPU goes up (not a lot, but it seems to impact performance quite a bit), but the larger problem is that all other IPV6 clients respond to the multicast broadcast address generating a 1-2mbit storm of traffic to all ports all the time. This then transits the bandwidth constrained wireless network in a steady state, causing high collisions which causes _significant_ performance degradation in the wireless network. It would appear that this is _generally_ caused by Dell or HP workstations with buggy network interface cards in hibernate mode. http://blog.bimajority.org/2014/09/05/the-network-nightmare-that-ate-my-wee… http://packetpushers.net/good-nics-bad-things-blast-ipv6-multicast-listener… Now it looks like from my reading that CISCO MLD snooping would _help_ with this, though it would not stop the offender from generating the multicast requests, it might keep if from reaching _all_ ports, but it would still affect any ports that had _subscribed_ IPV6 clients, and it would require changing the SDM template and a reload on all the switches. So not a real answer and very painful. Right now, I'm just tracking the source down and shutting it off. Do not really want to get into an argument about switched vs routed, and am working on reducing the size of the broadcast domain now, but this is a new issue, and I need to come up with some kind of plan to resolve with my current equipment/network. Any thoughts?? Ideas? I suspect this will become more of an issue for more folks in the near future. /thanks -- Richard Holbo Southern Oregon Network Support Services richard.holbo(a)sonss.net - 541.890.8067 http://www.sonss.net

4 4

Re: Saying goodnight to my GSR
by Larry Sheldon 22 Sep '14

22 Sep '14

On 9/22/2014 08:35, David Hubbard wrote: > Got you beat by nine weeks with a Foundry 9604. :-) > The system uptime is 3411 days 7 hours 52 minutes 20 seconds > The system started at 01:38:44 Eastern Sat May 21 2005 That's the kind of waving I like to see. -- The unique Characteristics of System Administrators: The fact that they are infallible; and, The fact that they learn from their mistakes. Quis custodiet ipsos custodes

1 0

Re: Saying goodnight to my GSR
by Larry Sheldon 22 Sep '14

22 Sep '14

On 9/22/2014 06:38, Alain Hebert wrote: > Properly configured, it is less a security issue than newer devices. > > Pretty impressive from Matthew to have the patience/skills to not > simply "reload" that fridge over the years. Whew! I was afraid I was the one who thought so anymore. -- The unique Characteristics of System Administrators: The fact that they are infallible; and, The fact that they learn from their mistakes. Quis custodiet ipsos custodes

1 0

Saying goodnight to my GSR
by Matthew Crocker 22 Sep '14

22 Sep '14

Has been running for a while, time to shut ‘er down. She (is a router a she?) used to handle all of my BGP GigE links but over the years has been demoted to OSPF and T1 aggregation. If anyone needs a boat anchor let me know. gsr8-1#show version Cisco Internetwork Operating System Software IOS (tm) GS Software (GSR-P-M), Version 12.0(30)S3, RELEASE SOFTWARE (fc2) Technical Support: http://www.cisco.com/techsupport Copyright (c) 1986-2005 by cisco Systems, Inc. Compiled Thu 30-Jun-05 18:29 by pwade Image text-base: 0x50010E80, data-base: 0x536E8000 ROM: System Bootstrap, Version 11.2(20030108:132517) [jkuzma-112 2.2] RELEASE SOFTWARE gsr8-1 uptime is 9 years, 9 weeks, 2 days, 8 hours, 39 minutes Uptime for this control processor is 9 years, 2 weeks, 2 days, 18 minutes System returned to ROM by Stateful Switchover at 13:46:36 UTC Tue Sep 6 2005 System image file is "slot0:gsr-p-mz.120-30.S3.bin" cisco 12008/GRP (R5000) processor (revision 0x05) with 524288K bytes of memory. R5000 CPU at 200Mhz, Implementation 35, Rev 2.1, 512KB L2 Cache Last reset from power-on 2 Route Processor Cards 2 Clock Scheduler Cards 3 Switch Fabric Cards 2 Single Port Gigabit Ethernet/IEEE 802.3z controllers (2 GigabitEthernet). 1 Three Port Gigabit Ethernet/IEEE 802.3z controller (3 GigabitEthernet). 1 Ethernet/IEEE 802.3 interface(s) 5 GigabitEthernet/IEEE 802.3 interface(s) 507K bytes of non-volatile configuration memory. 20480K bytes of Flash PCMCIA card at slot 0 (Sector size 128K). 8192K bytes of Flash internal SIMM (Sector size 256K). Configuration register is 0x2102 -- Matthew S. Crocker President Crocker Communications, Inc. PO BOX 710 Greenfield, MA 01302-0710 E: matthew(a)crocker.com P: (413) 746-2760 F: (413) 746-3704 W: http://www.crocker.com

19 22

Twitter appears inop
by Jay Ashworth 22 Sep '14

22 Sep '14

I'm getting various 403 messages on tweets about "looks automated", from Tweetcaster and the Web UI, both over Sprint LTE from Tampa; anyone else seeing this? Retrieval seems ok; the web UI loads fine too. Appears internal. I would notify them, but Twitter is down. Cheers, -- jra -- Jay R. Ashworth Baylink jra(a)baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274

1 0

IP Geolocation Issue
by Jose Damian Cantu Davila 22 Sep '14

22 Sep '14

Hi, Im new here, so any advice would be very appreciated. Is someone from Maxmind IP Geolocation available, that I can talk to offline? Its regarding to a block we assigned to a client. The client and its customers are located in Mexico but the IP Geolocation services says they are located in Brazil. Thanks for your help. [damian cantu]

4 4

internet governance, rir policy, and the decline of civilization
by Randy Bush 21 Sep '14

21 Sep '14

http://mailman.apnic.net/mailing-lists/sig-policy/archive/2014/09/msg00049.…

5 10

Bare TLD resolutions
by Jay Ashworth 21 Sep '14

21 Sep '14

Pursuant to https://www.icann.org/resources/pages/name-collision-2013-12-06-en) mentioned in the Scotland thread... it seems there are two major potential points of possible collision: 1) User network uses "fake" TLD which is no longer fake, and local resolver server blows it 2) User network blows it worse, and tries to resolve a monocomponent name off non-local servers. The latter would seem to be avoidable by making sure that *DNS resolution of bare TLDs always returns NXDOMAIN*. Is that a requirement for a TLD? If it isn't, does anyone know of any domains dumb enough to actual return something for a lookup on the bare TLD? Is there actually *any* good reason why a lookup on a bare TLD ("com.") might return a valid record? And what about Naomi? Cheers, -- jra -- Jay R. Ashworth Baylink jra(a)baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274

13 26