- NANOG - lists.nanog.org

An area for operations growth - Storage Area Nets in MANS
by Gordon Cook 19 May '03

19 May '03

Roxane Googin is usually ahead of the competition in spotting trends in data net use. here is what has has to say about enterprise use of MANs. COOK Report: Where are the metro area networks going? Googin: Probably the killer application for the MAN is grid computing and storage area networks. A lot of people think the driver for broadband access to the home is going to be multi-media. People, when they think about next generation networks, think home use. But this is never where the money has been. And no phone company is ever going to build the infrastructure. Although these new real time applica tions will clearly send more data over the network, the real killer application is going to be remote storage and synchronous storage. Synchronous storage means that you have two large servers doing the exact same thing at the exact same time in two different locations. COOK Report: Like a decentralized disk array? Googin: Yes. The backbone has to be incredibly fast because you cannot complete a transaction until you have acknowledgments from both disk drives. This will happen. Probably this year. What they are already doing is taking fiber channel and putting that on a Cienna Core Director optical switch port. Half of the ports being sold on the Core Director now are fiber channel. They aren't even Ethernet. And this is used for storage area nets (SANs). These are corporate MANs and will have nothing to do with sales to service providers. They are bypass business services where the storage arrays may not be more than a kilometer or two apart. These SANs are backing up continuously terabytes of data. We are talking huge applications that will use every bit of access to every bit of capacity they can get. COOK Report: Is 9/11 a motivation for this? Googin: Partly. Not only that but the whole paradigm of the real time organization will drive it. It used to be that your server had its own storage. It was a "stove pipe" connected to the CPU. Now as soon as you decouple that "stove pipe," you can put it anywhere. What they are finding is that if they have two of them that are mirrored in real time and place remotely that they do not have to do as much management of resources. COOK Report: Then forget the disaster back up and recovery operations? Those are the next to be marked for extinction? Googin: Oh yes. It is so elegant. The new architecture cannot be supported on direct attached storage. It must move off the server and it is doing so. If you have to go through a server to get to the storage, it simply doesn't work. Storage can't become just a utility until you move it off the server. The MAN will be backing up terabytes of data regularly and in real time. Disaster recovery, in real time, comes for "free". For more detail please see Fiber & Wireless as First Mile Technology - Fiber Business Models & Architecture http://cookreport.com/12.04-06.shtml -- ============================================================= The COOK Report on Internet, 431 Greenway Ave, Ewing, NJ 08618 USA 609 882-2572 (PSTN) 703 738-6031 (Vonage) cook(a)cookreport.com Subscription info & prices at http://cookreport.com/subscriptions.shtml Fiber & Wireless as First Mile Technology - Fiber Business Models & Architecture, July- September 2003, 130 pages available at http://cookreport.com/12.04-06.shtml =============================================================

4 5

BGP Path Filtering
by Mark Radabaugh 18 May '03

18 May '03

I'm having a hard time finding best practices for filtering outbound bgp announcements when providing transit to bgp-speaking customers. While we currently multi-home to several providers it appears we will soon need to provide transit for customers with their own AS's. I find lots of references (and understand) the basic ip as-path access-list 3 permit ^$ and it would seem that should we wish to provide transit for a bgp customer AS12345 we would use: ip as-path access-list 3 permit ^12345$ but I think this breaks if AS12345 prepends their advertisement. Next up is: ip as-path access-list 3 permit ^12345_[0-9]$* Which seems correct to me. Is this still best practice (or even correct)? Mark Radabaugh Amplex (419) 720-3635

14 29

List of martians appeared during the week May 6-12 2003
by Sean Donelan 17 May '03

17 May '03

http://www.ris.ripe.net/weekly-report/reports/20030506-20030512.html List of martians appeared during the week. Prefix Origin AS 10.0.0.0/8 18298 Chungnam National University Computer Center 10.1.1.1/32 5413 GX Networks (Formerly XO UK, CNCX, Xara Networks) 172.16.0.0/16 18298 Chungnam National University Computer Center 172.16.1.0/24 24587 Internet Online BV 172.16.2.0/24 24587 Internet Online BV 192.168.1.0/24 18298 Chungnam National University Computer Center 192.168.2.0/24 18298 Chungnam National University Computer Center 192.168.3.0/24 18298 Chungnam National University Computer Center 192.168.4.0/24 18298 21166 SatGate Stockholm Sweden 192.168.5.0/24 18298 Chungnam National University Computer Center 192.168.6.0/24 18298 Chungnam National University Computer Center 192.168.7.0/24 18298 Chungnam National University Computer Center 192.168.8.0/24 18298 Chungnam National University Computer Center 192.168.9.0/24 18298 Chungnam National University Computer Center 192.168.16.0/24 18298 Chungnam National University Computer Center 192.168.30.0/24 18298 Chungnam National University Computer Center 192.168.38.0/24 18298 Chungnam National University Computer Center 192.168.40.0/24 18298 Chungnam National University Computer Center 192.168.50.0/24 18298 Chungnam National University Computer Center 192.168.54.0/24 18298 Chungnam National University Computer Center 192.168.60.0/24 18298 Chungnam National University Computer Center 192.168.64.0/24 18298 Chungnam National University Computer Center 192.168.100.0/24 18298 Chungnam National University Computer Center 192.168.101.0/24 18298 Chungnam National University Computer Center

1 0

RE: Communities BCP [was: RE: BGP Path Filtering]
by Ejay Hire 17 May '03

17 May '03

On the subject of communities, these are some I have seen regularly implemented for controlling routes advertised to peers. (code snippet follows) Where xxxx is the peer ASN: xxxx:80 Set LocalPref to 80 xxxx:90 Set LocalPref to 80 xxxx:100 Set LocalPref to 80 xxxx:110 Set LocalPref to 80 xxxx:1 Prepend xxxx 1 time in the AS Path xxxx:2 Prepend xxxx 2 times in the AS Path xxxx:3 Prepend xxxx 3 times in the AS Path xxxx:no-export Well known community that requests the advertisement not leave the AS. xxxx:666 BlackHole. I've implemented this community for clueful downstream peers that suffered frequent DOS attacks. They advertise a single or small block of their IPs to me and I will blackhole traffic destined for their IP. I've considered echoing this advertisement up to my upstreams (if they support it), but have not done so. The config bits that follow are from memory, so no guarantees of syntax accuracy. If anyone knows how I can have an Item matched multiple times in the route-map I would appreciate a reply. I.e. if a customer wanted to send xxxx:100 and xxxx:1, currently I would match on the xxxx:1 and the localpref change would not be applied. Thanks in advance to whoever comes up with this gem. Code Snippet: (Again, this may not be 100% correct on syntax, I'm doing it from memory.) Prefix-list customerxyz-in permit 200.200.0.0/16 le 24 Prefix-list customerxyz-bh-in permit 200.200.0.0/16 le 32 ip community-list 66 permit xxxx:666 ip community-list 10 permit xxxx:1 ip community-list 11 permit xxxx:2 ip community-list 12 permit xxxx:3 ip community-list 13 permit xxxx:80 ip community-list 14 permit xxxx:90 ip community-list 15 permit xxxx:100 ip community-list 16 permit xxxx:110 route-map customerxyz-in permit 10 match community 66 match ip address prefix-list customerxyz-bh-in (this uses the ...-bh-in list allowing prefix lengths up to /32) set community no-export additive set next-hop null0 route-map customerxyz-in permit 20 match community 10 match ip address prefix-list customerxyz-in (this uses the regular customer prefix list allowing lengths up to /24) set as-path prepend xxxx ... 30 and 40 similar, for community lists 11 and 12 route-map customerxyz-in permit 50 match community 13 match ip address prefix-list customerxyz-in set localpref 80 ... 60,70,80, and 90 similar, for community lists 14-17 Ejay Hire ISDN-NET Network Engineer -----Original Message----- From: Jay Ford [mailto:jay-ford@uiowa.edu] Sent: Friday, May 16, 2003 2:27 PM To: Joe Abley Cc: deepak(a)ai.net; Mark Radabaugh; nanog(a)merit.edu Subject: Re: Communities BCP [was: RE: BGP Path Filtering] On Fri, 16 May 2003, Joe Abley wrote: > Examples of characteristics I have seen in the wild are: > > + I was learnt from a peer > + I was learnt from a transit provider > + I was learnt from a customer > + I was learnt over an exchange point > + I was learnt over a private peering connection > > These are all markers to be used in setting internal policy, so the > choice of numbers really doesn't matter. You can add or remove > characteristics from your list when necessary without having to > renumber anything. You can (and probably should) strip all these > attributes before sending routes to EBGP peers, so nobody else has to > see them. You can & definitely should strip those community values on announcements you receive from EBGP peers. Interesting things happen if you let others turn your routing policy knobs when you think they can't reach them. ________________________________________________________________________ Jay Ford, Network Engineering Group, Information Technology Services University of Iowa, Iowa City, IA 52242 email: jay-ford(a)uiowa.edu, phone: 319-335-5555, fax: 319-335-2951

2 2

LFT - Layer Four Traceroute?
by Russ Haynal 16 May '03

16 May '03

hello, I have read about the LFT Tool at the following web page: http://www.mainnerve.com/lft/ It looks like this traceroute might succeed where traditional UDP Traceroutes fail. Does anybody know of any publicly accessible traceroute servers which are running LFT in the background? Thanks Russ Here are some other interesting online tools: AS Trace between any two starting points: http://www.fixedorbit.com/trace.htm AS Path Visualization: http://lab.verat.net/Jaspvi/ GASP - Graphical AS path: http://mogwai.frnog.org/sysctl/gasp/ (offline at the moment) _________________________________________________________________ Russ Haynal - Internet Instructor, Speaker and Paradigm Shaker "Helping organizations gain the most benefit from the Internet" russ(a)navigators.com http://navigators.com 703-729-1757

3 2

Re: Clocking Sources (was NTp sources that work in a datacenter (was Re: Is latency equivalentto RTT?))
by N. Richard Solis 16 May '03

16 May '03

You are correct with one notable exception. The presence of a cesium clock is considered a de facto timing source. I've never seen a BITS system that actively disciplines a Cesium Source. What they will do is take many Cesium (or Primary Reference Sources, PRS) and verify them against each other. The output from that mathematical function is then used to discipline a Rubidium or Ovenized Crystal Oscillator. The output from THAT is then used to drive BITS feeds to telecom equipment. The desire for everyone to have a timing source that is tracable to a Cesium clock comes from the SONET standard. If you tie two SONET networks together, if they both don't have timing that's tracable to a Stratum 1 (PRS) source, they'll drift at the points where they interconnect and PSE (Positive Stuff Event) and NSE (Negative Stuff Event) errors will be the result. This is BAD BAD BAD for the voice networks that are provisioned over SONET. Spinka, Kristofer wrote: > > The actual clock source, the time pulses, produced by BITS (Building > Integrated Timing Systems) are not usually just a "re-feed" of the GPS > source. Instead, contained within the clock system, BITS device, is some > sort of highly resolvable, measurable, predictable, stable, oscillator > such as Cesium, Rubidium or Quartz, depending on your budget. > > The GPS signal, being transmitted from orbiting Cesium clocks, is used > to "discipline" or prevent your local oscillator drift from degrading your > time code. This basically means that if the oscillator installed in > the unit is supposed to oscillate exactly 10,255,432 times per > second, and an interal or external condition has now caused it to > oscillate at 10,255,434 times per second, your pulse generator will > account for this and keep your time code stable. These GPS satellites > have Cesium oscillators that drift also, and are in turn disciplined > themselves against the "USNO Master Clock", which is an average time code > calculated from a slew of cesium atomic and hydrogen maser clocks. > > So, why can't an entire bulding share the same GPS discipline source? > It would save some roof space and money. If you are worried about someone > kicking the antenna over, just make sure that your oscillator is > reasonable enough to maintain your necessary accuracy without external > discipline while they glue the antenna back on. For most applications a > high quality, stable quartz based oscillator will be more than sufficient > and is the least expensive. If you need to get fancy, and depending on > your internal and external condition variables, the general rule is: > Quartz < Rubidium < Cesium. > > /kristofer > >

2 1

RE: BGP Path Filtering
by Ejay Hire 16 May '03

16 May '03

I would suggest filtering at the customer interface and then tagging the route with a community that indicates "I have accepted this route as a customer route and will transport it to and through the edge of my network". Here is some example code. Let me know if you need more help with this. ON the ISPEdge router (facing the customer) router bgp nnnn neighbor x.x.x.x remote-as y neighbor x.x.x.x Description customerxyz neighbor x.x.x.x route-map customerxyz-in in neighbor n.n.n.n remote-as nnnn neighbor n.n.n.n Description IBGP connection to ISPCore neighbor n.n.n.n route-map ibgp-out out neighbor n.n.n.n send-community ip prefix-list customerxyz-in permit y.y.y.y/20 le 24 ip prefix-list customerxyz-in permit z.z.z.z/22 le 24 route-map customerxyz-in permit 10 match ip address prefix-list customerxyz-in set community nnnn:999 (Implicit deny any for Items not matching the route-map) ip community-list 1 permit nnnn:999 route-map ibgp-out permit 10 match community 1 route-map ibgp-out permit 20 Statements To match and transport your non-customer ibgp routes go here Ejay Hire Network Engineer -----Original Message----- From: Mark Radabaugh [mailto:mark@amplex.net] Sent: Thursday, May 15, 2003 9:29 PM To: nanog(a)merit.edu Subject: BGP Path Filtering I'm having a hard time finding best practices for filtering outbound bgp announcements when providing transit to bgp-speaking customers. While we currently multi-home to several providers it appears we will soon need to provide transit for customers with their own AS's. I find lots of references (and understand) the basic ip as-path access-list 3 permit ^$ and it would seem that should we wish to provide transit for a bgp customer AS12345 we would use: ip as-path access-list 3 permit ^12345$ but I think this breaks if AS12345 prepends their advertisement. Next up is: ip as-path access-list 3 permit ^12345_[0-9]$* Which seems correct to me. Is this still best practice (or even correct)? Mark Radabaugh Amplex (419) 720-3635

1 0

Draft NANOG agenda
by Susan Harris 16 May '03

16 May '03

Here's the schedule for Salt Lake City (June 1-3), with times subject to change. See you soon! ---------------- SUNDAY TUTORIALS ---------------- 1:30 - 3:00 p.m. "BGP Multihoming Techniques" Philip Smith, Cisco 1:30 - 3:00 p.m. "Deploying Interdomain IP Multicast" Mike McBride, Cisco 3:00 - 3:30 p.m. BREAK 3:30 - 5:00 p.m. "Introduction to MPLS" Joseph M. Soricelli, Juniper 3:30 - 5:00 p.m. "BGP Multihoming" (cont'd.) -------------- Monday, June 2 -------------- 9:00 a.m. Welcome, Introductions Pete Kruckenberg, Utah Education Network Susan Harris, Merit 9:15 a.m. "Lawful Interception: Should There Be Standards?" Jeff Schiller, MIT 10:15 a.m. BREAK 10:45 a.m. "The National Infrastructure Assurance Council (NIAC) Vulnerability Disclosure Framework and What It Might Mean to the ISP Community" Jim Duncan, Cisco; Paul Vixie, ISC 11:00 a.m. "NRIC Best Practices for ISP Security" Ross Callon, Juniper 11:30 a.m. "@Home Cable Backbone Deployment Experiences" Cathy Wittbrodt 12:00 p.m. LUNCH 1:30 p.m. "IPv4/IPv6 Dual-Stack on Abilene" Grover Browning, Indiana University 2:00 p.m. "Panel: XML Router Configs - Progress and Predictions" Randy Bush, IIJ, moderator 3:00 p.m. BREAK 3:30 p.m. Tutorial Breakouts - "ISP Security: Deploying and Using Sinkholes" Barry Raveendran Greene, Cisco Danny McPherson, Arbor - "Issues in IPv6 Deployment" Jeff Doyle, Juniper -------------------------------- Monday Evening BOFs & Key Signing --------------------------------- 7:30 - 9:00 p.m. ISP Security BOF III Barry Raveendran Greene, Cisco 7:30 - 9:00 p.m. XML-based Network Management Tools Robb Enns, Juniper 9:00 p.m. PGP Key Signing Joe Abley, ISC --------------- Tuesday, June 3 --------------- 9:00 a.m. "BGP Vulnerability Testing: Separating Fact from FUD" Sean Convery and Matthew Franz, Cisco 9:30 a.m. "BGP Attack Trees - Real World Examples" Sue Hares, NextHop; Vijay Gill, AOL Time Warner Mike Hughes, RouteScience 10:45 a.m. BREAK 10:45 a.m. "SBGP/SOBGP Panel: What Do we Really Need and How Do we Architect a Compromise to Get It?" Randy Bush, IIJ, moderator 12:00 p.m. LUNCH 1:30 p.m. "MPLS-Based Synchronous Traffic Shunt" Yehuda Afek, Riverhead; Roy Brooks, Cisco 2:00 p.m. "Bidirectional Forwarding Plane Deadness Detection" Dave Ward, Cisco; Dave Katz, Juniper 2:45 p.m. "BGP AS Number Exhaustion" K Claffy, CAIDA, presenter; Geoff Huston, Telstra, author 3:15 p.m. "Implementation of ARIN's Lame DNS Delegation Policy" Ed Lewis, ARIN 3:45 p.m. Research Forum - "Inter-provider Coordination for Real-Time Tracebacks" (Kathleen Moriarty, MIT) - "Achieving Record Speed Trans-Atlantic End-to-end TCP Throughput" (Les Cottrell, Stanford University) 4:30 p.m. Adjourn

1 0

identity theft != spam
by Randy Bush 16 May '03

16 May '03

what is wrong with this picture? From: "NewsScan" <newsscan(a)newsscan.com> NewsScan Daily, 15 May 2003 ("Above The Fold") *********************************************************** NewsScan Daily is underwritten by RLG, a world-class organization making significant and sustained contributions to the effective management and appropriate use of information technology. NSD is written by John Gehl and Suzanne Douglas, editors(a)NewsScan.com. *********************************************************** 'BUFFALO SPAMMER' COULD GET UP TO SEVEN YEARS Howard Carmack, the so-called "Buffalo Spammer," has become the first person in New York state to be charged under the state's identity theft laws. If convicted, he could be sentenced to 2-1/2 to 7 years in prison for identity theft, forgery, criminal possession of forgery devices (in the form of software used to create phony return addresses), and falsifying business records. According to the indictment, Carmack "stole the identities of innocent New Yorkers to spam millions of consumers throughout New York and the nation." He is charged with using 343 stolen identities to send his unsolicited bulk mailings through Earthlink accounts. An Earthlink executive said the main impact of the arrest would be to demonstrate to others the "very high cost of doing business" in spam. (New York Newsday 14 May 2003) http://www.nynewsday.com/business/ny-biz-spammer0514,0,2414486.story?coll=n… this exemplifies the corporate and legislative attempt to confuse spam == uce with forgery. if they can make the latter the issue, this leaves the way completely clear for unsolicited commercial email from the corporate sector which now fills our post boxes with ground trees. randy

12 15

RE: BGP Path Filtering
by Niaz, Wajahat 16 May '03

16 May '03

You should start using communities if you want to provide transit to downstream bgp customers. Use the right tool for the right job. Ali, DSL.net, Inc. -----Original Message----- From: Mark Radabaugh [mailto:mark@amplex.net] Sent: Thursday, May 15, 2003 10:29 PM To: nanog(a)merit.edu Subject: BGP Path Filtering I'm having a hard time finding best practices for filtering outbound bgp announcements when providing transit to bgp-speaking customers. While we currently multi-home to several providers it appears we will soon need to provide transit for customers with their own AS's. I find lots of references (and understand) the basic ip as-path access-list 3 permit ^$ and it would seem that should we wish to provide transit for a bgp customer AS12345 we would use: ip as-path access-list 3 permit ^12345$ but I think this breaks if AS12345 prepends their advertisement. Next up is: ip as-path access-list 3 permit ^12345_[0-9]$* Which seems correct to me. Is this still best practice (or even correct)? Mark Radabaugh Amplex (419) 720-3635

2 1