February 2009 - Test - lists.nanog.org

Re: Charter.net email routing issues
by John Martinez 24 Feb '09

24 Feb '09

Yup, I knew that, sorry. Ryan Rawdon wrote: > You may want to try the mailop mailing list, which was created to try > and shift mail operations traffic volume from NANOG: http://www.mailop.org/ > > Good luck with your issue, > Ryan > > John Martinez wrote: >> Is anyone else seeing a high rejection rate from charter.net email >> clients? >> >> >> >

4 4

Re: FW: Ctrl+Shift+6 then X
by Tom Storey 23 Feb '09

23 Feb '09

Erm, what does that have to do with DNS lookups? :-) > line con 0 > transport preferred none > line vty 0 15 > transport preferred none > > Nick >

3 2

Re: FW: Ctrl+Shift+6 then X
by Tom Storey 23 Feb '09

23 Feb '09

> 'No ip domain lookup' will solve your problem instance below. Eg dns True, but only really useful until you configure the device and it can reach a DNS server, at which point you lose the ability to resolve any hostname, but would be very handy in a lab where DNS is never likely to exist I must say. I might include that into my lab template. :-)

1 0

RE: FW: Ctrl+Shift+6 then X
by Tom Storey 23 Feb '09

23 Feb '09

FWIW Ive rarely had a problem breaking out of ping/traceroute/etc on a Cisco. I have found that Shift-Ctrl, then a very very small delay and 6 (while still holding down Shift-Ctrl) works like a charm every time. Maybe the terminals I use are just more friendly towards that sort of key sequence than others. :-) Though the only thing it doesnt seem to help with is when you have no DNS servers configured and mistype "configt", or some other command that doesnt exist and it tries to resolve it through broadcast several times. Ive found its futile to try and get out of that. Tom > Ye, exact same things happens for me, then after it decides to execute it > you have a nice long line of 6x6x66x6x666x66666, tried the Ctrl+6 no such > luck... > > -----Original Message----- > From: Shon Elliott [mailto:shon@unwiredbb.com] > Sent: Monday, February 23, 2009 10:48 AM > To: nanog(a)nanog.org >> nanog > Subject: Re: FW: Ctrl+Shift+6 then X > > Bruce, > > I have that problem using any terminal program (I use SecureCRT).. I have > to > bang the command like 10-20 times for the device to recognize it. Kind of > wished > CTRL-C or something worked better and actually worked well. > > > Shon Elliott > Senior Network Engineer > unWired Broadband, Inc. > > > > Bruce Grobler wrote: >> Hi Guys, >> >> >> >> If anyone can tell me how to resolve this issue there's a strong > possibility >> of a fedex'd beer. >> >> >> >> Using Putty or any other ssh/telnet terminal I find that Ctrl+Shift+6 >> then > X >> (on a cisco) works only sometimes after beating your keyboard multiple > times >> with a hammer, has anyone else come across or had a solution to this > problem >> ? >> >> >> >> Regards, >> >> >> >> Bruce Grobler >> >> Yo!Africa - Network Engineer >> >> Landline: +263-4-701300, Cellphone: +263-91-2364532 >> >> Skype ID: bruce.grobler >> >> >> >> > > >

3 2

NANOG in the news
by neal rauhauser 23 Feb '09

23 Feb '09

http://www.thecuttingedgenews.com/index.php?article=11111&pageid=28&pagenam… -- mailto:Neal@layer3arts.com // GoogleTalk: nrauhauser(a)gmail.com IM: nealrauhauser

2 2

external L2 ethernet connections
by Joe Maimon 23 Feb '09

23 Feb '09

Does anyone have a best practice list of things to disable/filter/turn off on ethernet ports l2 connected to other AS's cdp stp switchport negotiate vtp if trunking, limit vlans, no vlan1 So on so forth. Switches do so many darn things all by themselves, as any packet capture shows. Thanks, Joe

6 7

FW: Ctrl+Shift+6 then X
by Bruce Grobler 23 Feb '09

23 Feb '09

Hi Guys, If anyone can tell me how to resolve this issue there's a strong possibility of a fedex'd beer. Using Putty or any other ssh/telnet terminal I find that Ctrl+Shift+6 then X (on a cisco) works only sometimes after beating your keyboard multiple times with a hammer, has anyone else come across or had a solution to this problem ? Regards, Bruce Grobler Yo!Africa - Network Engineer Landline: +263-4-701300, Cellphone: +263-91-2364532 Skype ID: bruce.grobler

7 8

Great outage of 1997 - Does anyone recall?
by neal rauhauser 23 Feb '09

23 Feb '09

I recall a marvelous eighteen hour long global internet outage which I believe occurred in 1997, but this was before I'd ever touched BGP. Does anyone have the full story on this? I'm writing on article on the recent troubles with Supro and my silly editor wants fact checking and all sorts of stuff like that ... -- mailto:Neal@layer3arts.com // GoogleTalk: nrauhauser(a)gmail.com IM: nealrauhauser

9 12

Global Crossing announcing prefixes they do not own
by Kurt Erik Lindqvist 22 Feb '09

22 Feb '09

Can someone from Global Crossing that actually reads and responds to email (as opposed to their NOC and contacts listed in their ASN object) and care that they are announcing prefixes that are not theirs - please contact me off-list... Best regards, - kurtis -

1 0

Re: Comprehensive community Guideline and Policies for an AS
by Richard A Steenbergen 22 Feb '09

22 Feb '09

> nLayer's does look fairly comprehensive. > > A few nitpick that lead me to hesitate to adopt it. > > The informational tags comprised of > > 4436:TCRPP > > T The type of relationship that the route was learned through > C The continent where the route was learned > R The region where the route was learned > PP The POP location (city code) > > Type of routes have a maximum of 6 possible types. That could be > limiting. nLayer lists 1-5 types already, granted those are the > typical relationships and should cover most needs. Designing a community system requires coming up with creative ways to stuff as much data as possible into a fairly limited amount of space, which obviously means you're going to have to make some compromises from what might be ideal. I addressed a lot of these design considerations in my NANOG presentation on the subject: http://www.nanog.org/meetings/nanog40/presentations/BGPcommunities.pdf Since the underlying field is only 16 bits, the maximum possible value is 65535. If each character is going to be used as a "field", then obviously you either have to limit the first digit to 6 and the second digit to 5, or the first digit to 5 to allow a full range of values in the second digit. Since there were really only 5 relationship types which I ever need to express, but more than 5 potential continents to cover, I decided to go with the system above. If you have different considerations in your network, it only makes sense to design this differently. > Pop location code has a maximum of 99. nLayer is already up to 30. > > What are they going to do when they reach 100? Suppose instead of > cities you wanted to number pops? Quite conceivable to have multiple > pops in the same city. Again, this was part of the design consideration. Given the limited amount of space and all the data we wanted to include, the decision was made to limit city codes to 99. Given our plans for network expansion, which don't involve becoming a telco and going into a massive number of cities, this was a reasonable compromise. One possible way to encode more data is to split things into multiple community tags, each one defining a specific type of information. The reason we didn't go this route was that it makes it harder for end users to match on combinations of information, since they would have to do AND type matching with multiple regexp statements. If this is less of a consideration for you than you can certainly fit more and bigger data using multiple communities, but we decided we were happy enough with what we had and wanted it keep it user friendly. > Using other ASN's as part of your communities policy raises two > issues: > > - Is it a good idea without drawback (sprint does this also but only > with private ASNs)? > > - How will this scale to 4byte ASN's? > > Anyways, the point I am working from is that there are too many > divergent approaches and all networks cant be that different and there > should be one general approach that will work for all. I also talked about this point in my presentation. Our motiviation for using the real target ASN in the first half of the community was to implement script-based automatic support for communities targetting all eBGP neighbors rather than just a limited handful. This causes several other areas of "increased difficulty" as well, but I personally think it is valuable enough to make it worth the effort. Another way we considered but decided against was the use of private ASNs on the left side to control actions, and the data side on the right half to select a target, for example: 64512:1239 (apply some action 64512 to neighbors AS1239) But we decided against this due to the extreme limitations this would place on the action fields. The private ASN range of 64512-65535 only supports 2 characters with a full range, and just shifts the potential community conflicts into the private ASN space anyways. As far as 4 byte ASN support goes, in order to provide any real support for them we're all going to have to switch to extended communities, which will probably be far trickier than the actual AS4 implementation itself. The format for 4 byte ASN support is: http://tools.ietf.org/id/draft-rekhter-as4octet-ext-community-03.txt Which defines: 16 bits of Type and Subtype values 32 bits of Global Administrator value (i.e. the ASN) 16 bits of actual user-defined data One very nice thing this brings to the table is the addition of the type and subtype fields. Just in the two basic type definitions which are a part of the RFC we already have a very useful innovation, the use of "origin" (i.e. informational communities set by the specified ASN) and "target" (i.e. action communities to be applied to the specified ASN) communities. Unfortunately vendor support is very basic right now, and nobody seems to have given much thought to how we're all going to successfully transition to them. I personally think the only reasonable way to do it is to add a policy mechanism for converting between types on network borders, but nobody seems to have gone this route so far. I think people are assuming vendors are more prepared than they actually are, not understanding that most of the functionality and testing is for little more than l3vpn support. Try rewriting your policies to support both regular and extended communities and see how easy it is. :) -- Richard A Steenbergen <ras(a)e-gerbil.net> http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)

1 0