- Test - lists.nanog.org

BGP Community Attribute Support: Summary
by Joe Abley 02 Apr '01

02 Apr '01

The other week, I asked: On Sat, Mar 24, 2001 at 10:25:35PM -0500, Joe Abley wrote: > Quick poll: does any operator here currently use a router which does > not support setting BGP community attributes, does not permit community > attributes to be matched exactly when doing ingress/egress route > filtering, or does not permit wildcard matches on the last two octets > (e.g. "permit 1234:*")? These were pretty targeted questions, and what I have largely heard is silence. Hence either these three capabilities have widespread support, or people just didn't find the question interesting enough to reply to. I guess I shouldn't start designing surveys for a living :) Anyway, a couple of people said there was interest in a results summary, so here are the main points: + gated 3.6 public doesn't support setting community attributes but will pass them on unscathed, as you'd hope; + "Extreme networks equipment" does not support the wildcard community match, although the person who told me that had only limited experience with the product range; I also happened to ask a few people about specific platforms, and found out: + the Nortel shasta and bay RS platforms support those three capabilities + zebra supports all three capabilities (the wildcard match function is in version 0.91a, based on a patch by Rick Payne) I was already confident I could do all three things on juniper and cisco boxes, although I didn't bother to analyse which IOS/JUNOS versions would definitely support all three. One correspondant (working for a vendor) lamented the lack of clear guidelines on what base functionality should be supported by bgp speakers at all in relation to manipulating community attributes, and suggested a more general poll might be useful for that reason. The reason for asking about those three particular capabilities was to search for platforms that would have trouble doing this: http://www.automagic.org/~jabley/draft-jabley-edge-policy-propagation-contr… Thanks, Joe

1 0

outages in Toronto Canada (other places?)
by Jim Mercer 02 Apr '01

02 Apr '01

i am seeing some serious unreachables using uunet.ca, @home (ontario), sprint (canada) and others. all at the same time. a traceroute from @home (ontario) to www.ibm.com dies someplace in the states. is there some major outage near the core/tier1? -- [ Jim Mercer jim(a)pneumonoultramicroscopicsilicovolcanoconiosis.ca ] [ Reptilian Research -- Longer Life through Colder Blood ] [ aka jim(a)reptiles.org +1 416 410-5633 ]

3 2

RE: California PUC orders outage notification
by Roeland Meyer 01 Apr '01

01 Apr '01

> From: Bora Akyol [mailto:akyol@akyol.org] > Sent: Friday, March 30, 2001 10:07 PM > I don't understand why they don't go to planned blackouts instead of > unplanned blackouts. This may actually drive the demand down > and price > with it. Plus maybe the population would decline with people > migrating > to South Dakota and all (for those of you that are not living > in the SF > Bay Area, S.D. has been advertising extensively on the radio > as a good > place to do business with ample energy). The argument against such planned blackouts are, Crypts, Bloods, F-troop, et al. (gangs/looters, for those whom aren't familiar) IOW, physical security. Numerous blackouts have proven that social predators take advantage of situations where no one can see them, the power is out, and the police are otherwise occupied.

2 1

Re: Using other provider's ASN (was Re: Sprint and peering points)
by smd＠clock.org 01 Apr '01

01 Apr '01

Sean Donelan writes: | If Sprint isn't pre-pending its routes with Sprint's ASN, who is? Who cares? Maybe more interesting is how is this done? Curious minds want to know. | It is generally considered ill-mannered to use someone else's ASN w | without their permission. Sez who? AS_PATH is a mostly-simple attribute which is used for loop avoidance. Using it as a trail of breadcrumbs is a convenience, but in reality, the only important thing is that eBGP-speakers check "that the autonomous system number of the local system does not appear in the AS path" without discarding the route, although the current draft does point out that eBGP talkers may be configured to use such routes but such a router's "Operations ... are outside the scope of this document". (I would have said "sane analysis", but...) The loops that are avoided are ROUTING ANNOUNCEMENT loops, not forwarding loops. The AS_PATH need have no relation to the way actual traffic will flow when a BGP-speaker selects that route. | Traditionally, pre-pending is done with the pre-pender's own ASN. So, if tradition is so important, why aren't you runing rcp_routed for IDR? | If nothing else, to help track down the party when evil things happen. Sorry, all you can glean from an AS_PATH alone is that your neighbour wants to avoid having the route seen by the things in that AS_PATH. Attributes like AGGREGATOR exist to track parties down, since the AS_PATH cannot be, in some cases. What's your worry here? That someone can stuff your AS into an AS_PATH (personally I'd do it by forming an AS_SET), and thus you can't see a given route? Didn't you follow the ptomaine discussion where exactly that was done to an aggregate? Sean.

1 0

Using other provider's ASN (was Re: Sprint and peering points)
by Sean Donelan 01 Apr '01

01 Apr '01

On Sat, 31 March 2001, Jeff Loughridge wrote: > Sprint does not prepend its AS at public or private peering points. What > other providers do with the AS Path at their ingress is not under our > control. Providers trying to "steer" traffic through their peers, upstreams, or exchange points is nothing new. However, this caught my attention. If Sprint isn't pre-pending its routes with Sprint's ASN, who is? It is generally considered ill-mannered to use someone else's ASN without their permission. Traditionally, pre-pending is done with the pre-pender's own ASN. If nothing else, to help track down the party when evil things happen.

1 0

Re: Sprint and peering points
by smd＠clock.org 01 Apr '01

01 Apr '01

garlic(a)garlic.com writes: | So by making the change Sprint unilaterally shifts the transit packets from a | public peering point away from themselves. So if a *customer* asks Sprint, either directly, or via a community like 1755:12xx (see whois -h whois.ripe.net AS1755), is this "unilateral" on the part of Sprint? | What would have been nice is for Sprint to tell its customers it was doing | this. Then I would have expected the change in inbound traffic flows and | taken action. If it were a paying customer who indicated that Sprint should prepend, do you feel Sprint should be obliged to inform all customers beforehand? Is your answer different in the case of non-revenue connections ("peers")? How should this be done in the event that "prepend-request" BGP communities are being used by a network connected to Sprint, given that the other network may set or not set the attribute for any given prefix at any given time? | As it was, I opened a trouble report and wasted a lot of time looking | for a problem. Welcome to the Internet, it has routing complexity growth over time! Sean.

2 1

Microwave...
by Rodney Joffe 01 Apr '01

01 Apr '01

I' be interested in hearing about any operational experience the users on this list have had, such as issues and challenges with routing, reliability, etc., with the use of Microwave at DS3 or greater level.... -- Rodney Joffe CenterGate Research Group, LLC. http://www.centergate.com "Technology so advanced, even we don't understand it!"(R)

7 6

Re: California PUC blocks Northpoint shutdown
by owen＠exodus.net 01 Apr '01

01 Apr '01

I'm sorry, Mr. Heart Attack victim, but the PUC has just ruled that you can't die. We have no idea how to keep you alive, but the taxpayers are going to spare no expense in attempting to prolong your agony for the next 30 days in order to prevent less than 1% of them from suffering the difficulties imposed by your not giving them 30 days notice of your impending heart attack. Huh? Owen > http://dailynews.yahoo.com/h/nm/20010330/wr/northpoint_shutdown_dc_2.html > > Wheeee! > > --- > Computers hate being anthropomorphized. > > > >

1 0

POP energy management during power shortages
by Sean Donelan 01 Apr '01

01 Apr '01

California's government has shown a propensity to issue orders during the current power situation which don't always make sense. The power industry points to the presence of large Internet colocation buildings in California as one cause for the current power shortages. The American Society of Heating, Refrigerating and Air-conditioning Engineers has three sessions at this year's annual meeting on the topic. - What Is ASHRAE's Design Role in Times of More Frequent Power Interruptions? - Internet Hotels/Data Centers: Opportunities and Challenges of the New Economy - What Is ASHRAEs Role in the Current Electric Supply Crisis? The Governor has already ordered some businesses to turn off some lights. And even hospitals have been bounced back and forth between rolling blackouts and exemptions. If the state turns its attention towards large colocation buildings, is there any scientific research supporting the energy management practices of these buildings? This summer when the media will be exorting the public to turn their home air conditioners up to 80 degrees F, and some telephone companies keep their POP's at 85F, what is the scientific support for keeping colo's at their existing temperatures? If its a case of "IBM says so," where is the supporting research? I don't think the Internet is at risk due to the power situation. Even daily power interruptions won't affect the typical modern colo building. But if politicians get involved, all bets are off.

2 1

OT financial analysis of telecom sector and debt
by Jerry Scharf 01 Apr '01

01 Apr '01

For those who aren't interested in how money affects our business, you can hit D now. You certainly can't configure your router with this information. For those who would be interested in reading a financial analysts's view of telecom and the issues related to debt, I would recommend you check out http://www.thestreet.com/markets/marketfeatures/1359535.html. I found it very thought provoking and not the normal tunes I hear. This is not something to discuss on NANOG, but I thought it may forshadow serious operational issues if the analysis holds true. jerry

1 0