February 2001 - Test - lists.nanog.org

GigE link between 6500 and GSR
by Michael Kim 12 Feb '01

12 Feb '01

Hi All, I'm trying to bring up GigE link between 6509 and GSR. This is my problem: In the GigE interface on GSR says the interface is UP and line protocol is UP and in the GigE interface on 6500 says "not connected". Anyone have been in same situation? /michael --

3 5

BGP Question followup - packet fragmentation through GRE tunnels
by Roisman, Dani 12 Feb '01

12 Feb '01

I've gotten a few suggestions that included creating a GRE tunnel between sites, but shouldn't I be concerned about packet fragmentation? ---- Dani Roisman droisman(a)station.sony.com > -----Original Message----- > Another alternative would be to build your own backbone -- > but make it a > logical backbone if a physical one is not possible or > desired. You can use > a GRE tunnel to logically connect the two networks.

1 0

non-operational - TACACS+/Cisco Secure ACS case studies
by Jade E. Deane 12 Feb '01

12 Feb '01

Greetings.. I'm wondering if anyone would be willing to share their experiences in creating polices and procedures for a NOC, engineering and architectural group as it relates to TACACS+/privilege levels. Jade Jade E. Deane Network Engineer helloNetwork.com Las Vegas, Nevada Office: +1 (702) 938-9267 Cell: +1 (702) 604-4759 Fax: +1 (702) 456-1471 email: jade.deane(a)helloNetwork.com urgent epage: 7026044759(a)page.nextel.com

1 0

Cisco Flash help needed
by Simon Lockhart 12 Feb '01

12 Feb '01

All, I'm writing some software which will allow me to read and write the PCMCIA flash cards from Ciscos on a linux laptop. I have got reading working fine for Class A (Cisco 7x00 and Cisco 12000) and Class B (Cisco 2600/3600) cards, and am just about to move onto being able to write to the cards. I've worked out the format of the flash filesystem with no problems, and am confident that I'll be able to write new files to the filesystem, apart from one bit - the CRC I've come across 2 CRCs so far - a 32 bit one used on the Class A cards, and a 16 bit one used on the Class B cards. I've tried a standard crc32 routine (stolen from ssh), but it doesn't match the CRC reported by the router. Is there anyone good at understanding CRC routines who can help me reverse-engineer the cisco CRC, or perhaps does someone have some inside information they would like to share? Secondly, I'd like to test my code against a wider range of cisco flash formats. I've got access to 1600/2600/3600/7200/12000/LS1010. If you've got a linux laptop with pcmcia support, and access to a cisco router not in that list, would you mind sending me a dump of your flash card? You can make an image of the flash card thus: $ dd if=/dev/mem0c of=/some/where/ciscoflash.dmp bs=1048576 count=20 $ gzip /some/where/ciscoflash.dmp (replace /dev/mem0c if necessary, and the =20 on the end is the size of the card in MB) If you're not happy with sending me your IOS image, tftp a couple of text files onto a formatted flash card and use that. Please ask me first before emailing, if the gzip'd image is more than a couple of meg! Please don't ask me for the code yet! I'll let the list know when it's available... Many thanks, Simon -- Simon Lockhart | Tel: +44 (0)1737 839676 Internet Engineering Manager | Fax: +44 (0)1737 839516 BBC Internet Services | Email: Simon.Lockhart(a)bbc.co.uk Kingswood Warren,Tadworth,Surrey,UK | URL: http://support.bbc.co.uk/

5 9

RE: Need help with Cisco VLAN bridging....
by Craig Holland 12 Feb '01

12 Feb '01

I'm not sure what I had wrong with my config...but I scratched and started over and this worked. It was also possible to do this using SDE encapsulation on the HSSI interfaces. I received some traceback messages...so decided to opt for the frame-relay solution. Thanks! Everyone for your input! craig > -----Original Message----- > From: Brett Frankenberger [mailto:rbf@rbfnet.com] > Sent: Friday, February 09, 2001 2:48 PM > To: Craig Holland > Subject: Re: Need help with Cisco VLAN bridging.... > > > > > > > > Has anyone had experience bridging multiple VLANs accross a > clear-channel > > DS3? I have 2 3640's populated with 1 FE and 1 HSSI. They are > connected by > > a DS3. I've tried a couple of different configs, including turning one > > router into a frame swich and building a PVC for each VLAN, but > the bridging > > didn't seem to work. I've tried running SDE directly between the HSSI > > ports...and that didn't seem to work. I'm up a against a > deadline here, and > > would greatly appreciate any help you can offer. I've also > tried a couple > > of IRB configs. > > I'm guessing you are running 802.1q (or ISL) on the FE, and you want to > bridge VLAN 1 on the one 3640 to VLAN 1 on the other 3640, and the same > with VLAN 2, and so on. (And the 3640s are connected togethor via the > DS3). Right? > > I've never done this, but I think the following should work. > (Essentially, it's the frame switch thing you mentioned above). > > ROUTER #1 > > frame-relay switching > bridge 1 protocol ieee > bridge 2 protocol ieee > int fast X.1 > enc dot1q 1 > bridge-group 1 > int fast X.2 > enc dot1q 2 > bridge-group 2 > int HSSI X > enc frame-relay > frame-relay intf-type dce > int HSSI X.1 > frame-relay interface-dlci 16 > bridge-group 1 > int HSSI X.2 > frame-relay interface-dlci 17 > bridge-group 2 > > > ROUTER #2 > [[ Same, except leave out "frame-relay switching" and "frame;relay > intf-type dce" ]] > > OBviously the above has no provision for IP addresses for management, > etc., That is left as an exercise for the reader. If you want the > router to route to the VLANs in question as well as bridging them > between the tw 3640s, you need to add something like > bridge irb > bridge 1 route ip > bridge 1 bridge ip > bridge 2 route ip > bridge 2 bridge ip > int bvi1 > ip address ... > int bvi2 > ip address ... > > Or you could have a separate management vlan and do something like > int fast X.3 > enc dot1q 3 > ip address ... > > (And possible a separate management PVC with a new HSSI sub-interface > on each end.) > > -- Brett > >

1 0

The Cidr Report
by Tony Bates 12 Feb '01

12 Feb '01

This is an auto-generated mail on Sun Feb 11 20:37:22 PST 2001 It is not checked before it leaves my workstation. However, hopefully you will find this report interesting and will take the time to look through this to see if you can improve the amount of aggregation you perform. The report is split into sections: 0) General Status List the route table history for the last week, list any possibly bogus routes seen and give some status on ASes. 1) Gains by aggregating at the origin AS level This lists the "Top 30" players who if they decided to aggregate their announced classful prefixes at the origin AS level could make a significant difference in the reduction of the current size of the Internet routing table. This calculation does not take into account the inclusion of holes when forming an aggregate so it is possible even larger reduction should be possible. 2) Weekly Delta A summary of the last weeks changes in terms of withdrawn and added routes. Please note that this is only a snapshot but does give some indication of ASes participating in CIDR. Clearly, it is generally a good thing to see a large amont of withdrawls. 3) Interesting aggregates Interesting here means not an aggregate made as a set of classful routes. Thanks to xara.net for giving me access to their routing tables once a day. Please send any comments about this report directly to me. Check http://www.employees.org/~tbates/cidr-report.html for a daily update of this report. ------------------------------------------------------------------------------ CIDR REPORT for 11Feb01 0) General Status Table History ------------- Date Prefixes 040201 96815 050201 96681 060201 96726 070201 96978 080201 97041 090201 97137 100201 96880 110201 96509 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- *** Bogus 91.16.23.0/24 from AS11770 *** Bogus 103.22.7.0/24 from AS9768 AS Summary ---------- Number of ASes in routing system: 9849 Number of ASes announcing only one prefix: 5760 (3266 cidr, 2494 classful) Largest number of cidr routes: 957 announced by AS701 Largest number of classful routes: 1642 announced by AS701 1) Gains by aggregating at the origin AS level --- 11Feb01 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS1221 1623 1207 416 25.6% Telstra Pty Ltd AS701 1642 1451 191 11.6% UUNET Technologies, Inc. AS271 280 132 148 52.9% University of British Columbia AS7545 196 71 125 63.8% ASNBLK-APNIC-AS-2-BLOCK AS9269 162 46 116 71.6% ASNBLK-APNIC-AS-3-BLOCK AS6429 221 108 113 51.1% RdC Internet AS6595 163 62 101 62.0% DoD Education Activity Network As AS8013 434 336 98 22.6% PSINet Ltd. Canada AS13999 107 10 97 90.7% Mega Cable S.A. de C.V. AS4293 374 281 93 24.9% Cable & Wireless USA AS7496 104 23 81 77.9% ASNBLK-APNIC-AS-2-BLOCK AS4151 250 169 81 32.4% USDA AS705 312 234 78 25.0% UUNET Technologies, Inc. AS4755 209 137 72 34.4% Videsh Sanchar Nigam Ltd. Autonom AS1942 137 65 72 52.6% FR-CICG-GRENOBLE AS7018 615 544 71 11.5% AT&T AS7046 325 255 70 21.5% UUNET Technologies, Inc. AS577 236 167 69 29.2% Bell Advanced Communications Inc. AS174 499 431 68 13.6% PSINet Inc. AS1727 162 94 68 42.0% Commander Naval Surface force US AS9498 88 21 67 76.1% BHARTI BT INTERNET LTD. AS724 219 152 67 30.6% DLA Systems Automation Center AS5106 101 37 64 63.4% Ameritech Advanced Data Services, AS3464 153 92 61 39.9% Alabama SuperComputer Network AS7657 185 125 60 32.4% ASNBLK-APNIC-AS-2-BLOCK AS226 155 95 60 38.7% Los Nettos AS3749 115 57 58 50.4% Tennessee Board of Regents AS16758 63 6 57 90.5% IKON Office Solutions AS6413 67 11 56 83.6% Southern Online Systems, Inc. AS376 131 75 56 42.7% Reseau Interordinateurs Scientiqu For the rest of the previous weeks gain information please see http://www.employees.org:80/~tbates/cidr-report.html 2) Weekly Delta Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report 3) Interesting aggregates Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report

1 0

Re: BGP Question - how do work around pigheaded ISPs
by smd＠clock.org 12 Feb '01

12 Feb '01

WIBNI everyone who announced subnets of an allocated-in-pre-CIDR-times prefix would have to justify, under the usual slow-start rules, the use of any and all of those chunks that exceed a typical initial allocation from a favourite registry (APNIC, ARIN, RIPE)? WIBNI these member-funded registries were instructed by their members that, in order to postpone the day when the vast majority of paying members have to upgrade their routers because of an increase in the number of globally-heard prefixes and/or change swathes of the parts of the Internet they offer service to from classical IPv4 because of address consumption, the registries should monitor the address utilization of pre-CIDR allocations AS IF THEY HAD BEEN ALLOCATED UNDER TODAY'S RULES, and notify the entire membership when pre-CIDR allocations are clearly non-conforming in a way that inflates (even just a little) the size of the global routing tables or the overall visible address consumption. Sean. "Hot Babes Want You to Pay Your Registry to Police the Pre-CIDR Allocations Too!" -- whimsical spam to all real-world routing folks.

1 0

Re:Re: GigE link between 6500 and GSR
by rkuhljr＠uol.com.br 11 Feb '01

11 Feb '01

>> Anyone have been in same situation? > >set port neg X/Y dis When connecting 7500 GEIP/GEIP+ to 6500, what 6500 port options and 7500 port configuration seems to work best, regarding auto-neg and flow-control ? Rubens Kuhl Jr.

1 0

Re: BGP Question - how do work around pigheaded ISPs
by Sean Donelan 11 Feb '01

11 Feb '01

On Fri, 09 February 2001, "Roisman, Dani" wrote: > A parent organization has an unused /16 of address space, for arguments > sake, let's say it's 172.16.0.0/16. It's out of the old "class B" address > range. Two groups within the organization want to bring up independant > Internet datacenters, and need /18 of address space, each. Since the parent > organization owns an unsed /16, the IP registry refuses to give the child > organizations any address space - they insist all address blocks assigned to > the parent organization be used, first. > > ISPph (ph=pigheaded) has a BGP policy that filters out all routes in > 128.0.0.0/2 longer than /16. Return the 172.16.0.0/16 block to the registry (ARIN, APNIC, RIPE or if no one else IANA) and apply for multiple appropriately sized CIDR blocks under the current registry allocation guidelines.

4 6

Re: BGP Question - how do work around pigheaded ISPs
by Sean Donelan 11 Feb '01

11 Feb '01

None of the people you wrote can help you. Follow the directions on this web page or in the mail message you received when signing on to the list. http://www.nanog.org/email.html On Sat, 10 February 2001, Kendra Wright wrote: > > please remove me from this list >

1 0