July 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

Web expert on his 'catastrophe' key for the internet
by andrew.wallace 13 Aug '10

13 Aug '10

A British computer expert has been entrusted with part of a digital key, to help restart the internet in the event of a major catastrophe. Paul Kane talked to Eddie Mair on Radio 4's PM programme about what he might be called upon to do in the event of an international online emergency. http://www.bbc.co.uk/news/uk-10781240

21 36

I went so you don't have to -- ICANN Bruxelles pour les nuls
by Eric Brunner-Williams 11 Aug '10

11 Aug '10

There are a few people who have some passing interest in ICANN so I will inflict upon the list my few paragraph summary of things that matter. All the past large dragons appear to have been killed or reduced to largish lizards. The Four Over Arching Issues, of which only one was real, protection of trademark holders, are sufficiently solved. On the other hand, biting off fingers as usual, are two new shiny objects for the jays and daws to chase: vertical integration of registries and registrars (VI, like, you know, the visual mode of ex, not the evil EMACS cult) and morality and decency (MoDo). How big a thrill MoDo is going to be is still TBD. Content regulation via names. Whoopie! VI is going to be put to bed one way or another by Labor Day. About VI, which has consumed my every waking hour since ... the Nairobi meeting. Prior to Nairobi the rules reflected the NetSol/VGRS breakup, and allowed registries to own approximately 15% of a registrar, and registrars to own registries. Afilias (.info) and NeuLevel (.biz) were formed under these equity restrictions. At Nairobi the Board voted that there be no cross ownership in new gTLD registries, and just prior to the Brussels meeting last week, ICANN released the 4th version of the Draft Applicant Guide, which put the cross-ownership limit at 2%. The VI activity is an attempt to articulate an alternate to the 0%, now 2%, and still fluid rule the Board may adopt prior to starting the next application round. The broad choices (and venomous camps) are: 1. things pretty much stay the same, the 15% rule with some change continues, for .com-like and .coop-like registries, insiders rule, 2. things pretty much change, with 100% cross-ownership allowed, with various proposals for the prevention of abuse by the integrated entity, for .com-like and .coop-like registries, hurray for the revolution, and 3. who cares about 1 and 2? corporations and TLD consultants want lots (like hundreds) of brands in the root, now. The VI Working Group is about as fun as USENET, though the face-to-face meetings in Brussels were surprisingly civil. Of interest to some here is covert wiggling of a subscriber-type TLD through the semi-mythical loophole for "brand" TLDs. There are walled garden serpents working the issue towards ".my-walled-garden". The ISPSG (that's the ISP -- Internet.Service.Providers Stakeholders Group) continued to drift into senility and decay with ISPs still staffing ICANN issue advocacy out of their IP (Intellectual Property) in-house counsels rather than their IP (4&6&BGP&tone&stuff) operational sides, so wakeful behavior remains confined to the ASO input to ICANN, and limited to the last v4 /8s known to LGBT and other persons. Those are the big ticket items. The Board approved adding the Han Script labels requested by .cn (China), .tw (Taiwan) and .hk (Hong Kong), which made a lot of people, me included, feel good. This is the continuation of the approvals (and awkward delegations) of Arabic Script labels and Cyrillic Script labels made earlier. The security weenies continue to whine that all the new registries should be armored up to prevent abuses that overwhelmingly occur in .com, and surprise steer well clear of treading on Verisign's toes, so in vast areas of policy life in the playpen is quite surreal. The next meeting is in December, so I finally get a Halloween at home, in Cartagena, Columbia. The usual self-and-corporate-promotion-as-news is going on over CircleID, which everyone is free to read or avoid, and if you read today's CIDR and BGP reports with more than a passing interest, and this "pour les nuls", remember the first is reality based and the second is not. And no, there still is no firm date for ICANN to start the public announcement and four months later, start accepting applications and $185,000 checks. This sentence appears to age well, I've used it without sending it out for cleaning since the Paris meeting, six meetings in a row. This exchange: > On 2 Jul 2010, at 13:34, Bret Clark wrote: > >> 28.8k Modem users... > > AT&T iPhone users... the new 14.4 modem of the internet. Had me laughing! Have a nice weekend everyone! Eric

8 17

NOC Best Practices
by Kasper Adel 09 Aug '10

09 Aug '10

Hello Everyone, I am currently working on building a NOC so i'm looking for materials/pointers to Best Practices documented out there. On the top of my head are things like: 1) Documenting Incidents and handling them 2) Documenting Syslog messages 3) Documenting Vendor Software Bugs 4) Shift to Shift Hand over procedures 5) Commonly used scripts for monitoring 6) Frequently testing High Availability 7) Capturing config changes. ....etc I can see that this is years of experience but i am wondering if any of this was captured some where. Thanks, Kim

6 7