May 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

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

Re: [mailop] Virbl: The First IPv6 enabled dnsbl?
by Tammy A. Wisdom 29 Jun '10

29 Jun '10

----- "Mark Schouten" <marks(a)bit.nl> wrote: > Hi, > > FYI: > > http://virbl.bit.nl/index.php#ipv6 > > Comments on the listing method are appreciated. > > Regards, > wow bind? thats gonna get slower and slower and slower. I hope you have a TON of ram for that box. for example if we loaded the current contents of the ahbl from rbldnsd to bind it would take up a TON of ram. bind would take forever to load and and would be screaming for its dear life. --Tammy Tammy A Wisdom The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org ****************************************************************************** Disclaimer: This e-mail may contain trade secrets or privileged, undisclosed or otherwise confidential information. If you have received this e-mail in error, you are hereby notified that any review, copying or distribution of it is strictly prohibited. Please inform us immediately and destroy the original transmittal. Thank you for your cooperation. ******************************************************************************

3 2

Reputable VPS provider with Dutch static IPs
by Jeroen van Aart 24 Jun '10

24 Jun '10

Does anyone know a reputable virtual private server provider in the Netherlands, which provides static IPs that are located in the Netherlands according to those pesky geoIP checkers. It also should provide Debian stable (Lenny right now) and not cost more than ~$30 a month. Of course the company should not have problems dealing with international customers (Dutch organisations can be a bit anal sometimes :-). Thank you, Jeroen -- http://goldmark.org/jeff/stupid-disclaimers/

1 1

Upstream BGP community support
by Andy B. 04 Jun '10

04 Jun '10

Hi, Quick question: Would you buy transit from someone who does not support BGP communities? Here is the story: My company is pushing several GBit/s through various upstream providers. We have reached the point where we rely on BGP communitiy support, especially communities that can be sent to the upstream to change the way he announces our prefixes to his peers/transits. While most decent upstream providers support this kind of traffic engineering, one of them refuses to send and accept BGP communities. I tried to contact my upstream several times through different channels to get some background as to why they would not be able to provide us this service, but all we get is tickets that get closed without an answer. Management itself does not seem to bother either. Is this normal or is it too much to ask for BGP communities from an upstream who has points of presence in the US, Europe and Asia? Andy

27 58

wanted: your old NAT home router
by Lars Eggert 02 Jun '10

02 Jun '10

Hi, for a measurement study done together with Markku Kojo's team at the University of Helsinki, we're looking to collect as many different NAT home routers as possible. If you have an old clunker lying around somewhere, please contact me off-list. I'll cover shipping via DHL. Feel free to forward this email as you see fit. The boxes will find a permanent home at the University of Helsinki. Study results will be published openly. The intent is that this collection become a resource for the community to be shared for future studies. Caveat: The boxes should NAT between Ethernet interfaces - we don't have DSL or cable access equipment in the lab setup at the moment. Thanks, Lars

2 3