August 2010 - 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

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

(cisco, or any) acl *reducers* out there?
by George Michaelson 01 Oct '10

01 Oct '10

I have been looking at acl management s/w in the freecode space and I can find lots of tools which manage/distribute and test ACLs in routers. I'm wondering if anyone has written a parser which can construct rule-trees and get rid of the cruft, unusable, order-misorder and other issues in a large ACL pool? Its possible this is NP in the wider sense, but even a partial improvement would be useful something which can take a couple of hundred basic and extended ACLs and tell you these <ten> don't work these <twenty> conflict the remaining <x> have a sequence and can reduce to this basic <x-y> set (we've got the usual "acquisition of rule by accretion" problem across 4 edge/core routers with a mix of public facing, internal, WiFi, guest rules, and I hate to think this is either start from scratch, or intractable. The evidence is that its FRAGILE) -G

8 13

ISP port blocking practice
by Zhiyun Qian 13 Sep '10

13 Sep '10

Hi all, What is the common practice for enforcing port blocking policy (or what is the common practice for you and your ISP)? More specifically, when ISPs try to block certain outgoing port (port 25 for instance), they could do two rules: 1). For any outgoing traffic, if the destination port is 25, then drop the packets. 2). For any incoming traffic, if the source port is 25, then drop the packets. Note that either of the rule would be able to block outgoing port 25 traffic since each rule essentially represent one direction in a TCP flow. Of course, they could apply both rules. However, based on our measurement study, it looks like most of the ISPs are only using rule 1). Is there any particular reason why rule 1) instead of rule 2)? Or maybe both? Also, is it common that the rules are based on tcp flags (e.g. SYN, SYN-ACK)? One would think block SYN packet is good enough. Regards. -Zhiyun

52 121

Comcast enables 6to4 relays
by John Jason Brzozowski 02 Sep '10

02 Sep '10

FYI - thought this would be of interest to some of you, there will be more news on this front shortly. http://www.comcast6.net/ 6to4 Relays Activated Tuesday, August 17, 2010 As we started our IPv6 trials, we began to observe an increase in 6to4 relay traffic. 6to4 is a transition mechanism built into some operating systems and home gateways. While it is not a transition technology that Comcast planned to invest in due to limitations related to performance, we did observe poor performance when 6to4 was used by our customers. In many cases, these customers were not even aware that 6to4 was enabled by default or that their device or operating system was attempting to use 6to4 to communicate with IPv6 resources on the Internet. In most cases, we observed that 6to4-enabled operating systems and devices were attempting to use a 6to4 relay infrastructure hosted by a midwestern university. In order to improve the Internet experience for Comcast customers who are using 6to4, whether knowingly or not, we have decided to operate 6to4 relays on a temporary, trial basis. Comcast has decided to deploy 6to4 relays in five locations around our network to improve performance and predictability, as compared to operating relays from a single location. These 6to4 relays are available via the standard 6to4 Anycast IP address, according to RFC 3068, which is 192.88.99.1. Devices attempting to use 6to4 within our network should automatically discover and utilize these new 6to4 relays, without end user intervention or configuration. The first pair of these relays was activated today. We plan to activate the remaining three within the next seven to ten days. We plan to monitor the performance of the 6to4 relays, to measure any beneficial effects resulting from adding these elements to our network. As our IPv6 trials evolve and we develop our plans for 2011 and beyond, we will assess our plans to support 6to4 moving forward. John ========================================= John Jason Brzozowski Comcast Cable e) mailto:john_brzozowski@cable.comcast.com w) http://www.comcast6.net =========================================

20 52

Complain to your vendors (was Re: Did your BGP crash today?)
by Adrian Chadd 01 Sep '10

01 Sep '10

Guys/girls/furry-creatures-from-!Earth, Complaining on nanog-ml is likely to only achieve personal stress relief. This is something you should bring up with your vendor. Say that you'll move vendors if they don't start making "better" BGP implementations and adding the features you guys want. Make the list of "better" features open, public, and actively solicit alternatives. Follow up on your threat. This is your business bottom line after all. Don't just use it as a reason to get lower prices from your current vendor and then continue complaining when dumb crap like this occurs. It would be great if vendor(s) participated in a public interoperability test suite where researchers could test their stuff against it before unleashing it on the public internet. I'd love to see something public -and- cross institutional, -and- include access to things like CRS-level equipment. Go on, I dare you. :) 2c, Adrian

3 2