- NANOG - lists.nanog.org

Re: BGP Question - how do work around pigheaded ISPs
by Smerdon, John D 13 Feb '01

13 Feb '01

FWIW, the Unisys 129.227 and 192.39 networks are supposed to be advertised as /16s. We recently converted to AGNS and have recently been informed that our /24 advertisements were not being filtered. We have been working with AGNS to correct this and it should be resolved soon. > Look at UNISYS's net 129.227/16 or any of the other examples in > traditional Class B space. -- John D Smerdon Unisys Corporation

1 0

Re: Using unallocated address space
by Sean Donelan 13 Feb '01

13 Feb '01

On Tue, 13 February 2001, Roy wrote: > It would seem to me that ARIN and its counterparts should get together and > provide a "blackhole" BGP feed (the NBL?) where all packets destined for > unallocated, restricted, or private space go bye-bye. This isn't very effective because a longer, more specific prefix wins. It would immediately inflate the route table to its maximum size if the registries announced every possible delegation. It is similar to the problem with people hijacking addresses. Unless you tie it to filters which ignore prefix announcements longer than the "authorized" allocation size. Which brings us back to the start of this thread. If AS1239 and others contributed and used something like the IRR to filter announcements, the problem is simplier.

2 1

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

13 Feb '01

On Sun, 11 February 2001, "Craig A. Huegen" wrote: > The original poster didn't entirely make it clear whether the other > remaining /18's would be used by other sections of the parent company, > but that's not the point. If the space had been allocated from > 206+ or 62/63/64, his announcements would have been accepted. > Just because their parent company has been around for a while means that > some ISP's penalize them. One could guess from his e-mail address that > the parent company is one of the larger global enterprises in the world. Big doesn't mean right. Old doesn't mean wise. The net is full of "big" doing really dumb things, which the rest of us are stuck working around. Net 24 is a "big" example, or Net 12 in Class A space. Look at UNISYS's net 129.227/16 or any of the other examples in traditional Class B space. > Be careful with that answer if you haven't worked in or run a network > for a global enterprise that has multiple Internet access locations. > Global enterprises pay ISP's to deliver Internet traffic LOCALLY; they > don't run Internet backbones, and they have no intention to. Therefore, > they want to assign different addressing to different areas in order to > have the ISP's bring traffic to the region with that addressing. This > differs from the ISP model where traffic arrives at the closest possible > entrypoint into the network, then follows a backbone to its destination. In general, if you look at most global enterprises who don't run Internet backbones, you'll also find they rarely have divergent routing policies. The AS Path is identical for all the locations because global enterprises have global purchase agreements. If you want to divide your /16 up within UUNET, fine. Just pay UUNET to aggregate your block before passing the announcement outside UUNET's network. Why do people forget you can aggregate blocks at points other than the edge of the network. If UNISYS had IBM aggregate 129.227/16, there is no reason why all those /24's need to appear in the global route table outside of IBM's network. UNISYS can pay IBM to get local trafic locally, but there is no reason why the rest of the global Internet needs to see those more specific paths. As you might have figured out, announcing more specifics is a nifty way to get around ISP peering handoffs, which is why some ISPs don't like listening to more specific announcements for the same organization. If I can dump the traffic onto Sony's california network block, why do I want to listen to a more specific announcement from Sony's european offices and carry the traffic on my backbone to europe. > But is there a good reason that a block size of /19 shouldn't be accepted > in this space? Is it not reasonable for an older global enterprise to > want more Internet access locations for their enterprise, and therefore > divide their address space up a bit more? Except that is not what happens, and not really even good reason for dividing up their space. Access location has nothing to do with it. You divide up the space to announce different inter-provider path attributes, e.g. different AS Path, different MED, etc. If you use the same upstreams for all your locations, there is no reason why the rest of the global routing table needs to see your seperate access locations. Whether it is a /32 or a /16, if the global path is identical, then there is no reason for a more specific announcement. We don't need to know you have a 3000 access locations in your network. Yes, in the past there were networks who wanted to announce a seperate network for each dialup POP. Yes, there seems to be a constant influx of new people everyday who believe you must announce a seperate route for each access location in the global route table. > Some ISP's believe that when the registries allocated address space in the > B space prior to CIDR times, that they intended for those companies only > to announce that space as /16's. Okay, I can accept that, given the > landscape at the time. However, the flaw that these ISP's are making in > policy is the belief that all the organizations who received this space in > the past won't use VLSM, and can't be responsible with addressing. Unfortunately, history has shown this is true. As you point out, most ISPs will listen to longer announcements *IF* you can give a good story. The reality is there are few good stories in comparison to the number of flawed attempts. >From what I read of the current big attempt, I haven't heard a good story yet. There are several alternatives, which given my limited knowledge, all seem to work for this situation.

9 9

Access to .com, .net, and .org zone files?
by Deepak Jain 13 Feb '01

13 Feb '01

Now that all of the TLD registries are all in full swing, if one wants to get FTP access to the zone files for .com (et al) who is one supposed to make the request to? (the README in ftp://rs.internic.net/domain says send a request to hostmaster(a)internic.net -- hostmaster(a)internic.net is bouncing) Thanks in advance, Deepak Jain AiNET

5 4

smtp virus traffic
by Dan Hollis 12 Feb '01

12 Feb '01

Ok folks, Virus email traffic has roughly doubled since january, with the 'snow white' virus and its mutations as #1 in virus volume. If it keeps up, virus emails will soon outnumber spam and normal email. -Dan

1 0

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