January 2011 - Test - lists.nanog.org

Blocking private AS
by Thomas Magill 27 Nov '13

27 Nov '13

I am thinking about implementing a filter to block all traffic with private AS numbers in the path. I see quite a few in my table though so I am concerned I might block some legitimate traffic. In some cases, these are just prefixes with the private appended to the end but a few have the private as a transit. Is this a good idea or would I likely be blocking too much legitimate traffic? The filter I am using currently shows the following: BGP table version is 5462394, local router ID is 209.112.253.4 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path * i58.68.109.0/24 x.x.x.x 0 100 0 6130 9498 10201 65534 i *> y.y.y.y 0 6130 9498 10201 65534 i * i68.115.224.0/24 x.x.x.x 0 100 0 6130 19151 20115 65011 i *> y.y.y.y 0 6130 19151 20115 65011 i * 85.112.22.0/24 y.y.y.y 0 6130 6939 23148 64532 64532 64532 64532 64532 64532 64532 64532 64532 i *> 93.189.194.0/24 y.y.y.y 0 6130 3549 39386 39386 39386 25233 65000 47146 i * i x.x.x.x 0 100 0 6130 3549 39386 39386 39386 25233 65000 47146 i *> 96.60.243.0/24 y.y.y.y 0 6130 2828 4181 65528 i * i x.x.x.x 0 100 0 6130 2828 4181 65528 i * i96.61.232.0/24 x.x.x.x 0 100 0 6130 2828 4181 65527 i *> y.y.y.y 0 6130 2828 4181 65527 i * i96.61.233.0/24 x.x.x.x 0 100 0 6130 2828 4181 65527 i *> y.y.y.y 0 6130 2828 4181 65527 i * i96.61.234.0/24 x.x.x.x 0 100 0 6130 2828 4181 65527 i *> y.y.y.y 0 6130 2828 4181 65527 i *> 148.207.2.0/24 y.y.y.y 0 6130 2828 3257 16531 13579 65090 i * i x.x.x.x 0 100 0 6130 2828 3257 16531 13579 65090 i *> 148.207.40.0/24 y.y.y.y 0 6130 2828 3257 16531 13579 65090 i * i x.x.x.x 0 100 0 6130 2828 3257 16531 13579 65090 i *> 148.207.97.0/24 y.y.y.y 0 6130 2828 3257 16531 13579 65090 i * i x.x.x.x 0 100 0 6130 2828 3257 16531 13579 65090 i * 170.34.100.0/24 y.y.y.y 0 6130 19151 20115 65011 ? * 170.34.104.0/24 y.y.y.y 0 6130 19151 20115 65011 ? * 170.34.113.0/24 y.y.y.y 0 6130 19151 20115 65011 ? * i174.35.1.0/24 x.x.x.x 0 100 0 6130 16467 64565 i * i174.47.199.0/24 x.x.x.x 0 100 0 6130 2828 4323 15065 65123 i *> y.y.y.y 0 6130 2828 4323 15065 65123 i * i192.109.61.0 x.x.x.x 0 100 0 6130 19151 20115 65011 i *> y.y.y.y 0 6130 19151 20115 65011 i *> 196.216.249.0 y.y.y.y 0 6130 2828 3257 8513 8513 8513 36881 65000 36896 37062 i * i x.x.x.x 0 100 0 6130 2828 3257 8513 8513 8513 36881 65000 36896 37062 i Network Next Hop Metric LocPrf Weight Path *> 209.172.69.128/30 y.y.y.y 0 6130 16467 64565 i * i x.x.x.x 0 100 0 6130 16467 64565 i *> 213.146.161.0 y.y.y.y 0 6130 2828 174 64679 48493 i * i x.x.x.x 0 100 0 6130 2828 174 64679 48493 i Thomas Magill Network Engineer Office: (858) 909-3777 Cell: (858) 869-9685 mailto:tmagill@providecommerce.com <mailto:tmagill@providecommerce.com> provide-commerce 4840 Eastgate Mall San Diego, CA 92121 ProFlowers <http://www.proflowers.com/> | redENVELOPE <http://www.redenvelope.com/> | Cherry Moon Farms <http://www.cherrymoonfarms.com/> | Shari's Berries <http://www.berries.com/>

3 2

Network topology
by Colin Alston 15 Nov '13

15 Nov '13

Hi all I'm considering trying to come up with some means to automatically detect a networks topology and draw pretty pictures. This is somewhat boring though if a network isn't well arranged with VLANs and q-tag trunk routers and so on (It will just look like a big cloud of junk connected off an assumed switch). Is there any kind of cunning trick to detect standard layer2 switches along a path without stuff like STP?

9 12

Inventory and workflow management systems
by vijay gill 26 May '13

26 May '13

What software solution do people use for inventory management for things like riser/conduit drawdown, fiber inventory, physical topology store, CLR/DLR, x-connect, contracts, port inventory, etc. Any experiences in integrating workflow into those packages for work orders, modeling, drawdown levels, etc. /vijay

10 13

Re: Over a decade of DDOS--any progress yet?
by alvaro.sanchez＠adinet.com.uy 04 Oct '11

04 Oct '11

A very common action is to blackhole ddos traffic upstream by sending a bgp route to the next AS with a preestablished community indicating the traffic must be sent to Null0. The route may be very specific, in order to impact as less as possible. This needs previous coordination between providers. Regards. >----Mensaje original---- >De: rdobbins(a)arbor.net >Fecha: 08/12/2010 10:53 >Para: "North American Operators' Group"<nanog(a)nanog.org> >Asunto: Re: Over a decade of DDOS--any progress yet? > > >On Dec 8, 2010, at 7:28 PM, Arturo Servin wrote: > >> One big problem (IMHO) of DDoS is that sources (the host of botnets) may be completely unaware that they are part of a DDoS. I do not mean the bot machine, I mean the ISP connecting those. > >The technology exists to detect and classify this attack traffic, and is deployed in production networks today. > >And of course, the legitimate owners of the botted hosts are generally unaware that their machine is being used for nefarious purposes. > >> In the other hand the target of a DDoS cannot do anything to stop to attack besides adding more BW or contacting one by one the whole path of providers to try to minimize the effect. > >Actually, there're lots of things they can do. > >> I know that this has many security concerns, but would it be good a signalling protocol between ISPs to inform the sources of a DDoS attack in order to take semiautomatic actions to rate-limit the traffic as close as the source? Of course that this is more complex that these three or two lines, but I wonder if this has been considerer in the past. > >It already exists. > >----------------------------------------------------------------------- >Roland Dobbins <rdobbins(a)arbor.net> // <http://www.arbornetworks.com> > > Sell your computer and buy a guitar. > > > > > >

18 46

OSPFv3 Authentication
by Manav Bhatia 12 Mar '11

12 Mar '11

Hi, I am doing a survey and was interested in knowing if network operators are using OSPFv3 with authentication [RFC 4552] turned on? I know that most providers turn on authentication with OSPFv2, but given that OSPFv3 needs IPsec integration and can thus get little cumbersome to configure, wanted to understand if a similar % of folks also turn on authentication for OSPFv3? You can unicast me your responses (if you dont wish to share it on the list) and i will collate all data and post a summary on the list. Cheers, Manav

3 4

quietly....
by bill manning 02 Mar '11

02 Mar '11

039/8 APNIC 2011-01 whois.apnic.net ALLOCATED 106/8 APNIC 2011-01 whois.apnic.net ALLOCATED ... whimper ...

87 383

IPv6 consumer perception
by Zed Usser 21 Feb '11

21 Feb '11

With marketing campaigns like these, no consumer will want to use IPv6, if it becomes associated with privacy problems. http://torrentfreak.com/huge-security-flaw-makes-vpns-useless-for-bittorren… It is, of course, totally irrelevant whether the reporting is factually correct or even based on real IPv6 issues or not, this is how public opinion is formed. The only takeaway from this to a non-technical user is that IPv6 is bad and the correct solution is to turn it off. - Zed

19 45

Re: ipv6 transit over tunneled connection
by Franck Martin 20 Feb '11

20 Feb '11

----- Original Message ----- From: "Christopher Morrow" <morrowc.lists(a)gmail.com> To: "Michael Ulitskiy" <mulitskiy(a)acedsl.com> Cc: nanog(a)nanog.org Sent: Thursday, 13 May, 2010 6:39:28 PM Subject: Re: ipv6 transit over tunneled connection On Thu, May 13, 2010 at 6:18 PM, Michael Ulitskiy <mulitskiy(a)acedsl.com> wrote: > Hello, > > We're in the early stage of planning ipv6 deployment - > learning/labbing/experimenting/etc. We've got to the point when we're > also planning to request initial ipv6 allocation from ARIN. > So I wonder what ipv6 transit options I have if my upstreams do not > support native ipv6 connectivity? > I see Hurricane Electric tunnel broker BGP tunnel. Is there anything > else? Either free or commercial? 1) see gblx/ntt/sprint/twt/vzb for transit-v6 2) tunnel inside your domain (your control, your MTU issues, your alternate pathing of tunnels vs pipe) 3) don't tunnel beyond your borders, really just don't tunnels are bad, always. -chris I see so many times, that tunnels are bad for IPv6, but this is the way IPv6 has been designed to work when you cannot get direct IPv6. So I would not say tunnels are bad, but direct IPv6 is better (OECD document on IPv6 states the use of tunnels). If the issue with tunnel is MTU, then a non-negligible part of IPv4 does not work well with MTU different of 1500. With IPv6 we bring the concept of jumbo packets, with large MTU. If we cannot work with non standard MTUs in IPv6 tunnels, how will we work with jumbo packets?

11 13

BGP (in)security makes the AP wire
by Steven Bellovin 18 Feb '11

18 Feb '11

http://www.nytimes.com/aponline/2010/05/08/business/AP-US-TEC-Fragile-Inter… It's a pretty reasonable article, too, though I don't know that I agree about the "simplicity of the routing system".... --Steve Bellovin, http://www.cs.columbia.edu/~smb

12 19

Strange L2 failure
by Jack Bates 10 Feb '11

10 Feb '11

Has anyone seen issues with IOS where certain MACs fail? 54:52:00 (kvm) fails out an old 10mbit port on a 7206 running 12.2 SRE. I've never seen anything like this. DHCP worked, ARP worked, and arp debugging showed responses for arp to the MAC, however, tcpdump on the host system showed no unicast or arp responses coming from the router, while the switch management ip and other stuff on the local segment communicated fine with the vm. This broke for IPv6 as well. I changed the vm's MAC to 54:51:00, 50:52:00 and still failed. Changed it to 40:52:00 and it works for both v4 and v6. Was there a change which would cause certain hardware to not accept a MAC starting with 50: or higher? Jack

4 5