- Test - lists.nanog.org

Re: honoring AS-path prepend from a peer or customer?
by Avi Freedman 19 Feb '99

19 Feb '99

In article <99118.183518.5014(a)avi.netaxs.com> you wrote: : If a peer (or transit customer) prepends their own AS to : their route announcements to you, do you ever strip off : the excessive As'es? That is, do you always honor them : in your announcements to your other customers (or peers)? : I do understand that any operator has full control over : deciding his own outbound policy, regardless of the : AS path. : I want to know what the industry practice is and whether : I should stipulate in my next upstream agreement that : they honor my prepends? : Thanks. Standard practice is to accept them, though you may need to tell the peer or upstream what regexps to allow if they filter by as-path as well as by prefix. (Always a good idea...) My side question is - what shipping routers will let you rewrite AS-Paths by doing anything other than just prepending? Just wondering if any 7007-type horrors are lurking in the wings. I believe Criscos, Bays, and gated boxes can't do this (without BGP->IGP->BGP redistribution). Avi

3 4

Re: honoring AS-path prepend from a peer or customer?
by Danny McPherson 19 Feb '99

19 Feb '99

Sanjay Dani wrote: > >If a peer (or transit customer) prepends their own AS to >their route announcements to you, do you ever strip off >the excessive As'es? That is, do you always honor them >in your announcements to your other customers (or peers)? > >I do understand that any operator has full control over >deciding his own outbound policy, regardless of the >AS path. > >I want to know what the industry practice is and whether >I should stipulate in my next upstream agreement that >they honor my prepends? I don't see why any sane provider wouldn't honor AS prepends, although I'm not sure how one could actually manipulate AS_PATH without proxy-aggregation, "private AS" or the like .. or some hack to BGP source code, although it'd be unlikely to run in any production code... Don't believe anyone would do exactly what you suggest here though.. Of interesting things you should ask your provider to to support when considering your ability downstream to influence "upstream" path slection, the RFC1998 stuff is really nice.. -danny

1 0

RE: honoring AS-path prepend from a peer or customer?
by Martin, Christian 19 Feb '99

19 Feb '99

> Criscos, > Bays, and gated boxes can't do this (without BGP->IGP->BGP > redistribution). > > Avi Agreed. There is no provision to do this directly with BGP, although the RFC does not specifically preclude this, as far as I can tell. It does mention truncating AS-PATH information when dealing with Inter-AS multicast routes, but this is a future provision. Chris

1 0

honoring AS-path prepend from a peer or customer?
by Sanjay Dani 18 Feb '99

18 Feb '99

If a peer (or transit customer) prepends their own AS to their route announcements to you, do you ever strip off the excessive As'es? That is, do you always honor them in your announcements to your other customers (or peers)? I do understand that any operator has full control over deciding his own outbound policy, regardless of the AS path. I want to know what the industry practice is and whether I should stipulate in my next upstream agreement that they honor my prepends? Thanks.

1 0

Re: transit across the ixs
by Sanjay Dani 18 Feb '99

18 Feb '99

>> It sounds like Verio (a) didn't know about CIX's next-hop policy at PAIX >> and (b) is about to ask for it to be changed. > >cix? what's cix? some kind of sugared cereal? Think it is a router that many months ago saw tons of traffic pass between 2914 and 701 :-) Just observing as a recreational shell customer of a 2914 subsidiary. Consequently (a) above may not (should not?) hold.

1 0

Lessons, does anyone ever learn?
by Sean Donelan 17 Feb '99

17 Feb '99

Under the heading, the more things change, the more the stay the same... I found this interesting paragraph in a government sponsored research report. To make it more interesting, I'm not going to tell you the date of the report, or the network the authors were talking about. Since the US Government paid for the work, copyright isn't a concern, now if that ain't a hint, I don't know what is :-) "Among them they noted that while worst case analysis had been done, the particular scenario had not been studied. The also suggest operators did not have all the data they needed to make proper decisions. Particularly notable was that no one could see the big picture across the entire system. The authors suggest that there is substantial improvement needed to the modeling process. For example, models used for planning are different than models used for online monitoring and control. Finally, there are thousands of system components, and as many problems waiting to occur. Based on these observations the authors suggest the following: - Online dynamic security assessment tools, and security indices. - Wide area communication network and system monitoring process. - National standards for operations and engineering. - Improved system planning and risk assessment methods. - Standard system planning and operating data models. - Validated data in simulation models. - Wide area measurement and controls." Since there is currently a $2.8billion budget request pending before Congress to fund critical infrastructure protection, do you sometimes get the feeling some researchers just cut & paste their old analysis into whatever today's hot topic is? -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

3 2

Re: transit across the ixs
by Paul Vixie 17 Feb '99

17 Feb '99

>you might be amused to write a bit of code to see if your ix peers are >giving you next-hops of other provider(s). it is clear that a number of >providers are selling transit across the ixs. not at all cool. Note that CIX does this by default at PAIX and on PB-SMDS. Not that those are major exchanges by Randy's likely definition. The only time we force next-hop-self is if the peer deliberately asks the exchange operator for port filtering, or if we're otherwise explicitly requested by a BGP peer send routes with next-hop-self. -- Paul Vixie <paul(a)vix.com>

5 6

FIBER CUT: CSX shovel S.E. United States
by Sean Donelan 17 Feb '99

17 Feb '99

The cut is between Abrial (??) & Fairfax, SC and was caused by a CSX shovel. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

1 0

Re: SFO Pacbell outage
by Bill Woodcock 17 Feb '99

17 Feb '99

> Pacbell is down or having some serious problems in SF right now... We have several dozen DS1s in San Francisco and aren't seeing any problems. Specifics, please? -Bill Woodcock

2 1

SFO Pacbell outage
by Russell Van Tassell 16 Feb '99

16 Feb '99

Would appear as though Pacbell is down or having some serious problems in SF right now... traffic is really burst/. No details yet. -- Russell M. Van Tassell Commercial Systems Corp. russell(a)cscorp.com http://www.cscorp.com/ Ph: 1-888/COMM-SYS

1 0