June 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

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

IP Address Management Tool
by D C 16 Jul '10

16 Jul '10

I am looking for a better way to manage IP addresses. I am currently using an excel spreadsheet, but this is becoming cumbersome as more and more addresses are being added. Does anyone have any recommendations? Thanks, Danielle

22 26

[Bruce Hoffman] Thank-you for your recent participation.
by Robert E. Seastrom 15 Jul '10

15 Jul '10

Amusingly, this was sent to me *after* I replied to abuse@internap complaining about getting spammed. Anyone else getting spam from this joker? Has he been doing nanog mailing list or arin database harvesting? Anyone know who his boss is? -r

7 9

Advice regarding Cisco/Juniper/HP
by James Smith 01 Jul '10

01 Jul '10

I'm looking for a little insight regarding an infrastructure purchase my company is considering. We are a carrier, and we're in the process of building a DR site. Our existing production site is all Cisco equipment with a little Juniper thrown into the mix. I'd like to either get the same Cisco equipment for the DR, or the equivalent Juniper equipment. We have skill sets for both Cisco and Juniper, so neither would be a problem to manage. A business issue has come up since we have a large number of HP servers for Unix and Wintel. With HP's recent acquisition of 3Com they are pressing hard to quote on the networking hardware as well, going as far as offering prices that are way below the equivalent Cisco and Juniper models. In addition they're saying they'll cut us deals on the HP servers for the DR site to help with the decision to go for HP Networking. Obviously to the people writing the cheques this carries a lot of weight. >From a technical point of view, I have never worked in a shop that used HP or 3Com for the infrastructure. Dot-com's, telco's, bank's, hosting companies...I haven't seen any of them using 3com or HP. Additionally, I'm not fond of having to deal with a third set of equipment. I'm not exactly comfortable going with HP, but I'd like some data to help resolve the debate. So my questions to the NANOG community are: Would you recommend HP over Cisco or Juniper? How is HP's functionality and performance compared to Cisco or Juniper? Does anyone have any HP networking experiences they can share, good or bad?

36 49