Re: BGP route flap damping
Do this, configure and use blackhole routing with your upstream, this is how you stop an attack How to detect it, use netflow. On 1/16/06, Patrick W. Gilmore [EMAIL PROTECTED] wrote: On Jan 16, 2006, at 8:48 AM, Gustavo Rodrigues Ramos wrote: Patrick W. Gilmore wrote: Not much you can do about this in general.In your specific case, since we don't know why your sessions died, we don't know what to suggest to stop it.Perhaps change the timers with your upstream? My BGP connections (and annoucements) with/to my ISPs are all fine. The problem takes place five or six AS far from me... Where I can't do much. I still can't reach some prefixes announced by large ISPs. At the first time, I thought an e-mail to the NOC of the network I can't reach can solve the problem, but it was a waste of time... I'm a little confused.Are you saying you dampened the prefixes of some other network?Ifso, it sounds like this is 100% in your control.If the BGP sessions between you and your upstreams / peers never flapped, no one should have dampened you.(I can see it possiblyhappening if someone else in the path between you and $OtherNetworkis attacked and therefore flaps your routes, but that would affect alot of networks, not just you.) --TTFN,patrick
Agenda topics for Dallas
Greetings - here are the talks we've lined up so far for Dallas. Stay tuned - we'll be adding new topics often. SUNDAY ACTIVITIES - Newcomer's Orientation and Reception 3:30 - 5:00 p.m. Steering Committee Community Meeting 5:00 - 7:00 p.m. Welcome Reception, (fabulous) location TBA 6:30 - 11:00 p.m. GENERAL SESSION (Monday, Tuesday, Wednesday morning) - Searching for DNS Cache Poisoners Duane Wessels, Measurement Factory/CAIDA - How Prevalent is Prefix Hijacking on the Internet? Peter Boothe and James Hiebert, Univ. of Oregon; Randy Bush, IIJ - Hurricane Katrina: Telecom Infrastructure Impacts, Solutions, and Opportunities Paula Rhea, Verizon - Flamingo: An Internet Traffic Exploration Tool Manish Karir, Merit - NVisionIP and VisFlowConnect-IP: Two Tools for Visualizing NetFlows for Security Bill Yurcik, NCSA - Panel: Time for the Transition or Just More GOSIP? Dan Golding, Burton Group, moderator - IRR Power Tools: a Utility for Managing Internet Routing Registry Filters Richard Steenbergen, nLayer Communications - Flooding Attacks by Exploiting Persistent Forwarding Loops Jianhong Xia, Lixin Gao and Teng Fei, University of Massachusetts - Clear and Present Increase of Queries Tsuyoshi Toyono, Keisuke Ishibashi, Katsuyasu Toyama, NTT Labs = v6fix: Fighting Against an IPv6 Pandemic Kenjiro Cho, WIDE Project/IIJ, Ruri Hiromi, WIDE Project/Intec NetCore RESEARCH FORUM -- - An Inter-domain Consistency Management Layer Nate Kushman, MIT TUTORIALS (Monday/Tuesday afternoon) - Troubleshooting BGP Level: Introductory Philip Smith, Cisco - Overview of QoS for Packet-based IP and MPLS Networks Level: Introductory/Intermediate Paresh Shah, Utpal Mukhopadhyaya, and Arun Sathiamurthi, Cisco BOFS (Monday/Tuesday afternoon) - Tools BOF Todd Underwood, Renesys, Moderator - ISP Security and NSP-SEC BOF XI Danny McPherson, Arbor, Moderator - Peering BOF XI William B. Norton, Equinix, Moderator Abstracts are linked off this page: http://www.nanog.org/mtg-0602/topics.html See y'all next month.
[afrinic-discuss] AfriNIC to start allocating from 41/8 (fwd)
FYI: -- Forwarded message -- Date: Mon, 16 Jan 2006 13:59:15 +0200 From: Ernest, B.M (AfriNIC - ZA) [EMAIL PROTECTED] Reply-To: AfriNIC Discuss afrinic-discuss@afrinic.net To: afrinic-discuss@afrinic.net Cc: [EMAIL PROTECTED], afnog@afnog.org Subject: [afrinic-discuss] AfriNIC to start allocating from 41/8 Dear Colleagues, As you may be aware, AfriNIC received a 41/8 block from IANA in April 2005. With effect from February 2006, all IPv4 address space allocated within the AfriNIC service region will be made from 41/8. The 196/8 block previously used for allocations in AfriNIC service region will now be used only for direct end-user (PI) assignments. This is therefore a notice that any filters you have may need appropriate adjustments. Kind regards, Ernest, AfriNIC. ___ afrinic-discuss mailing list afrinic-discuss@afrinic.net http://lists.afrinic.net/mailman/listinfo.cgi/afrinic-discuss
Re: Intradomain Traffic Engineering
1. In the traces I have, there exist several intervals with a huge, sudden increase of traffic on some links. The prediction model I use cannot predict those 'big spikes'. Do these 'big spikes' really happen in operational networks? Or are they merely measurement errors? If they really happen, is there a gradual ramp up of traffic in smaller time scale, say, on the order of tens of seconds? Or do these 'big spikes' really occur very quickly, say, in a few seconds? 2. I have the option to make a tradeoff between average case performance and worst case performance guarantee, but I don't know which one is deemed more important by you. Are ISP networks currently optimized for worst case or average case performance? Is the trade-off between these two an appealing idea, or may the ISP networks are already doing it? This email covers a lot of issues, perhaps it'll start a discussion. I think the question depends on how big a core you are talking about. Excluding local effects (the operator of the network bounces a link or loses a router, etc), I doubt if you have a significantly large network you have many effects that shift traffic faster than 10s of seconds (upperbound on this statement is ~30 seconds). For example, if you lose a BGP session, it may take more than 30 seconds for the router to notice it. Once it realizes that its gone, it may re-route traffic very rapidly. But it would still take a while (at least a few seconds for a local link, more for a backbone link) before that traffic really renormalizes). This has more to do with TCP noticing packet loss, backing off [only for the traffic that has been effected] and starting back up. It takes up to half a second to *establish* a single TCP session on an average latency link. So, the trick would be to discover the traffic has gone or gone wonky before the BGP session is dropped. This would allow your algorithm to back off until a new /normal/ has been established. However, the talk of traffic engineering and maximum utilization always come into vogue when folks want to squeeze more utilization out of their networks without really spending more money. IMO, the best time to use TE is when customer-links to your network approach your maximum core speed [relative here... there is /core/ in your datacenter/pop and there is /core/ that is your network to the point the packets get handed off on average]. Often this limit on the operator's core is technology imposed (though budgetary concerns get in there too). I think the technology doesn't really exist at a scalable level to operate for the worst-case scenario, despite what some people may say. Our traffic measurement/link measurement tools are almost all average... and spot checks are of only marginal value. I would suggest that this is because of the nature of TCP. If the Internet were UDP based, there would be a *lot* more flash traffic problems. So, for those who have a high amount of UDP traffic (media streamers, DNS hosts, etc) would have a very different experience. I'm not the first person to say it, and I can't remember the first place I heard it... but I'd suggest that the core is not where TE has the best benefits. Cores by their nature need to be overengineered. You have very little flexibility because the demands on them are wide [they need to handle UDP and TCP, low latency and high latency acceptable applications with aplomb]. TE belongs to the Customer or non-backbone operating ISP. If one were to start an ISP where all residential customer connections were 1Gb/s I could conceivably have thousands of customers operating without needing 200Gb/s of uplink [assuming that were really feasible for a network with very little traffic terminating on the network]. By using TE I could shape my peak traffic needs (MLU) to approach my average. This would make me a much more desirable customer to sell transit to. TE, MLU, and other concerns while most well understood by core-operators, aren't by customers. Core operators may eventually need to push these concerns to customers if backbone link speeds do not stay far above end-user connection speeds. [on an ICB basis, they are -- whenever you want to buy a few OC-48s in a single POP or an OC-192 customer connection, someone is always going to ask you what your traffic looks like and when]. This would be easiest to push over by providing differential pricing. Enforcement and Analysis of *what* is a desirable traffic pattern and what financial value that provides is where we are largely lacking today. Since a customer knows their traffic and their needs better than a core operator, they would be much better at enforcing traffic flows/engineering. This is better than a core that optimizes for its own link utilization instead one that just tries to stay as empty as possible for as long as possible. This is way early in the day for me, so this may not make any sense. YMMV,
Re: GoDaddy.com shuts down entire data center?
On Mon, 16 Jan 2006 11:36:39 -0800, Joe McGuckin [EMAIL PROTECTED] said: By all means, the Justice Dept. and police should move against anyone performing illegal acts such as phishing, I just don't think that it is ICANN or ARIN and GoDaddy's job to police good net citizenship. You forget that the internet-services are based on best-effort. Anything else will require accountability for everyone involved. That is accountability going both ways so that users also can be held accountable for *all* their actions. To achieve that you'll have to toss any idea of anonymity for internet users. Wonder if that is what those who complain about restricive AUPs really want ;) Besides, whose authorities should do excactly what? Global legislation for the internet is just about as big an illusion as the new economy the internet once was assumed to create. //per -- Per Heldal http://heldal.eml.cc/
Yahoo Reception is Monday not Sunday
Oopsie - I misspoke below: SUNDAY ACTIVITIES - Newcomer's Orientation and Reception 3:30 - 5:00 p.m. Steering Committee Community Meeting 5:00 - 7:00 p.m. Welcome Reception, location TBA 6:30 - 11:00 p.m. Yahoo's Welcome Reception is actually *Monday* evening, not Sunday. The Beer 'n Gear is Tuesday evening. Sorry for the confusion.
Network Solutions DNS Outage
Network Solutions seem to be having a DNS outage--the worldnic servers are timing out--all of the domains they host DNS for seem to be down. Customer Service indicated that they were having a problem, and were working to resolve it. Justin M. Wilson [EMAIL PROTECTED]
Cisco Security Advisory: IOS Stack Group Bidding Protocol Crafted Packet DoS
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Cisco Security Advisory: IOS Stack Group Bidding Protocol Crafted Packet DoS Document ID: 68793 Advisory ID: cisco-sa-20060118-sgbp http://www.cisco.com/warp/public/707/cisco-sa-20060118-sgbp.shtml Revision 1.0 For Public Release 2006 January 18 1600 UTC (GMT) - - Contents Summary Affected Products Details Impact Software Versions and Fixes Workarounds Obtaining Fixed Software Exploitation and Public Announcements Status of This Notice: FINAL Distribution Revision History Cisco Security Procedures - - Summary === The Cisco IOS Stack Group Bidding Protocol (SGBP) feature in certain versions of Cisco IOS software is vulnerable to a remotely-exploitable denial of service condition. Devices that do not support or have not enabled the SGBP protocol are not affected by this vulnerability. Cisco has made free software available to address this vulnerability for affected customers. There are workarounds available to mitigate the effects of the vulnerability. This advisory is posted at http://www.cisco.com/warp/public/707/cisco-sa-20060118-sgbp.shtml Affected Products = Vulnerable Products +-- This vulnerability affects any device that runs Cisco IOS and has enabled the SGBP protocol. SGBP is enabled by defining a stack group, which is done using the global IOS command sgbp group name. The presence of this command will cause the device to begin listening on port 9900, even if the remaining SGBP parameters are not fully configured. The following examples demonstrate device configurations for which SGBP is enabled: Router#show sgbp Group Name: test Ref: 0xA3728C00 Seed bid: default, 50, default seed bid setting Or: Router#show running-config | include sgbp sgbp group test_group If your device displays output similar to either of the above examples, please consult the IOS software table below to determine whether your version of IOS is affected. Products Confirmed Not Vulnerable + Cisco products that do not run IOS, do not contain support for SGBP, or do not have SGBP enabled are not affected by this vulnerability. Systems on which SGBP is not supported or enabled will return either blank output or an error message. The following examples demonstrate device configurations that are not affected by this vulnerability: * A system that supports but is not enabled for SGBP returns this output: Router#show sgbp Router# * A system that does not support SGBP returns this error message: Router#show sgbp Router#show sgbp ^ % Invalid input detected at '^' marker. Details === Multilink PPP (MLP) allows users to combine multiple PPP links into a single logical network connection, thus enabling on demand bandwidth allocation. When implemented across multiple device chassis, this is known as Multichassis Multilink PPP (MMP). The Stack Group Bidding Protocol is the mechanism by which devices participating in MMP locate each other and negotiate for a connection termination point. The SGBP implementation provided by the Cisco Internetwork Operating System (IOS) is susceptible to a denial of service attack when presented with a crafted UDP packet. Sending such a packet to port 9900 of an affected device will cause it to freeze and stop responding to or passing traffic. After a delay, the system watchdog timer will detect this condition and force a reset of the device. The system recovery behavior will be controlled by the device configuration register; for example, the router may reload or drop to the ROM monitor. This vulnerability is documented in Cisco bug ID CSCsb11124. Impact == Successful exploitation of this vulnerability may cause the affected device to become unresponsive and trigger a hardware reset, resulting in a denial of service condition. Software Versions and Fixes === Cisco has provided updated software to address this vulnerability. For further details, please refer to the software table below. When considering software upgrades, also consult http://www.cisco.com/go/psirt and any subsequent advisories to determine exposure and a complete upgrade solution. In all cases, customers should exercise caution to be certain the devices to be upgraded contain sufficient memory and that current hardware and software configurations will continue to be supported properly by the new release. If the information is not clear, contact the Cisco Technical Assistance Center (TAC) or your contracted maintenance provider for assistance. Each row of the Cisco IOS software table (below) describes a release train and the platforms or products for which
PI space and colocation
Questions: If one gets PI space from ARIN for their network, then moves the servers to a rack at a data center (still using the space efficiently), will most colocation providers announce this space for them, or would most providers require them to take allocated space from them? Is it a reasonable alternative to establish a BGP connection with the provider over ethernet? Is this ok per ARINs requirements, assuming you first acquired this space under their multihomed network guidelines? TIA, James Smallacombe PlantageNet, Inc. CEO and Janitor [EMAIL PROTECTED] http://3.am =
Re: PI space and colocation
On Jan 18, 2006, at 2:41 PM, [EMAIL PROTECTED] wrote: If one gets PI space from ARIN for their network, then moves the servers to a rack at a data center (still using the space efficiently), will most colocation providers announce this space for them, or would most providers require them to take allocated space from them? I don't know about most, but every one I've asked has done it. You might need to sign an LOA. Is it a reasonable alternative to establish a BGP connection with the provider over ethernet? It is technical feasible, but I don't think 'reasonable'. Stub ASes are pollution on the 'Net. But that doesn't stop some people. Is this ok per ARINs requirements, assuming you first acquired this space under their multihomed network guidelines? That I do not know, but would guess no. (I would also guess they won't notice. =) Of course, if the space is /20 or more, you qualify under other rules too. -- TTFN, patrick
Re: PI space and colocation
On Wed, 18 Jan 2006, Patrick W. Gilmore wrote: If one gets PI space from ARIN for their network, then moves the servers to a rack at a data center (still using the space efficiently), will most colocation providers announce this space for them, or would most providers require them to take allocated space from them? I don't know about most, but every one I've asked has done it. We'd do it as long as everything looked legit (i.e. it really seems to be the customer's IP space). Is it a reasonable alternative to establish a BGP connection with the provider over ethernet? It is technical feasible, but I don't think 'reasonable'. Stub ASes are pollution on the 'Net. We've done this as well. Whats wrong with letting the customer use their ASN and BGP peering with them in your data center? They might even get a connection to someone else there and multihome again. Either way, the routes are getting into the global table...does the end of the aspath matter that much? -- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Strange issue involving sampling
Title: Strange issue involving sampling
First, apologies if this isn't the right place, but I was hoping to hit a lot of networking folks in one shot and this seemed like the likely venue.
I have this problem where a customer of mine has issues getting to secure websites (https sites like Charles Schwab's). It doesn't happen all the time, maybe once a month or so. We went to Juniper with the issue (we're using M-20s as our edge routers) and they couldn't figure it out, but one of our engineers found that the config pasted below (with proprietary info removed) fixed the problem. The only problem is that even with this config, we have to restart the sampling daemon every month or so because the problem will come back. Understandably, the customer would prefer to have a more permanent solution.
Anyone have an idea why this one customer on my entire network would have this issue? Supposedly the customer had Cisco come out and look at their network and they couldn't find any reason for it either.
routerx# show | compare rollback 0
[edit]
- forwarding-options {
- sampling {
- input {
- family inet {
- rate 1;
- }
- }
- output {
- file filename customer.sample;
- }
- }
- }
[edit firewall]
- filter customer {
- term 1 {
- then {
- sample;
- accept;
- }
- }
- term default {
- then accept;
- }
- }
[edit interfaces ls-2/3/0 unit 3]
routerx# show
description Customer X;
encapsulation multilink-ppp;
ml-pic-compatible;
family inet {
no-redirects;
filter {
input customer;
output customer;
}
address x.x.x.x/30;
}
Diane Turley
Sr. Network Engineer
Xspedius Communications Co.
636-625-7178
Re: PI space and colocation
On Jan 18, 2006, at 3:03 PM, Jon Lewis wrote: Is it a reasonable alternative to establish a BGP connection with the provider over ethernet? It is technical feasible, but I don't think 'reasonable'. Stub ASes are pollution on the 'Net. We've done this as well. Whats wrong with letting the customer use their ASN and BGP peering with them in your data center? They might even get a connection to someone else there and multihome again. Either way, the routes are getting into the global table...does the end of the aspath matter that much? It adds zero useful data to the global table, but increases RAM, CPU, etc. on every router looking at the global table. Given how vociferously people argue against items in the table which _do_ add useful data, superfluous info should be avoided whenever possible. IMHO, of course. -- TTFN, patrick
RE: PI space and colocation
On Wednesday, January 18, 2006 12:10 PM, Pat wrote: On Jan 18, 2006, at 3:03 PM, Jon Lewis wrote: Is it a reasonable alternative to establish a BGP connection with the provider over ethernet? It is technical feasible, but I don't think 'reasonable'. Stub ASes are pollution on the 'Net. We've done this as well. Whats wrong with letting the customer use their ASN and BGP peering with them in your data center? They might even get a connection to someone else there and multihome again. Either way, the routes are getting into the global table...does the end of the aspath matter that much? It adds zero useful data to the global table, but increases RAM, CPU, etc. on every router looking at the global table. Given how vociferously people argue against items in the table which _do_ add useful data, superfluous info should be avoided whenever possible. IMHO, of course. In the past under these circumstances, if the customer still insists on BGP after I strongly recommeded just a static DFG, I'd peer with the customer with a private AS (64512-65535). Then they usually ask me to annouce a DFG to them. Sometimes they'd want a full table. Sigh. At least they'd have the future flexibility of adding another provider without much change. I've personally done that too. Chris
Re: PI space and colocation
Once upon a time, Patrick W. Gilmore [EMAIL PROTECTED] said: It adds zero useful data to the global table, but increases RAM, CPU, etc. on every router looking at the global table. How much difference is there between one AS (the colo provider) announcing a prefix and another AS (the customer) announcing it through the first AS (the colo provider)? If the space is ARIN assigned PI, it isn't going to aggregate with the colo provider's space, so the prefix will still be a separate announcement. The only difference is the AS path is one entry longer. -- Chris Adams [EMAIL PROTECTED] Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
Re: Strange issue involving sampling
On Wed, Jan 18, 2006 at 03:09:50PM -0500, Peering wrote: First, apologies if this isn't the right place, but I was hoping to hit a lot of networking folks in one shot and this seemed like the likely venue. This sounds like a Juniper-specific issue, so the appropriate place is probably going to be http://puck.nether.net/juniper-nsp/. I have this problem where a customer of mine has issues getting to secure websites (https sites like Charles Schwab's). It doesn't happen all the time, maybe once a month or so. We went to Juniper with the issue (we're using M-20s as our edge routers) and they couldn't figure it out, but one of our engineers found that the config pasted below (with proprietary info removed) fixed the problem. The only problem is that even with this config, we have to restart the sampling daemon every month or so because the problem will come back. Understandably, the customer would prefer to have a more permanent solution. You have to restart the sampling daemon to forward packets to SSL based websites? Wha? Are you sure you didn't accidentally install a Crackpipe Services PIC in that router? :) Anyone have an idea why this one customer on my entire network would have this issue? Supposedly the customer had Cisco come out and look at their network and they couldn't find any reason for it either. [snip] Nothing in that config would cause or cure the problem you've described, unless the config it replaced was from destination-port 443; then reject;. I suspect your problem lies elsewhere, which is why Juniper and Cisco both said there were no problems. :) But if there really is something going on with the Juniper, re-post this to juniper-nsp (with more details about the failure behavior) and I'm sure someone will give it their best shot to figure out what your problem is. -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: PI space and colocation
On Jan 18, 2006, at 3:39 PM, Chris Ranch wrote: In the past under these circumstances, if the customer still insists on BGP after I strongly recommeded just a static DFG, I'd peer with the customer with a private AS (64512-65535). Then they usually ask me to annouce a DFG to them. Sometimes they'd want a full table. Sigh. If they are annoying, just let them use their own AS and make it a confederation. You see it, they see it, the rest of the world doesn't. At least they'd have the future flexibility of adding another provider without much change. I've personally done that too. Easier if they're using their own ASN. -- TTFN, patrick
Re: PI space and colocation
On Jan 18, 2006, at 4:02 PM, Chris Adams wrote: Once upon a time, Patrick W. Gilmore [EMAIL PROTECTED] said: It adds zero useful data to the global table, but increases RAM, CPU, etc. on every router looking at the global table. How much difference is there between one AS (the colo provider) announcing a prefix and another AS (the customer) announcing it through the first AS (the colo provider)? If the space is ARIN assigned PI, it isn't going to aggregate with the colo provider's space, so the prefix will still be a separate announcement. The only difference is the AS path is one entry longer. Well, obviously, the path entry is longer. :) It's not huge, but it is there. And like I said, many people argue over additions to the table which are actually useful. -- TTFN, patrick
Re: PI space and colocation
--On January 18, 2006 5:21:35 PM -0500 Patrick W. Gilmore [EMAIL PROTECTED] wrote: Well, obviously, the path entry is longer. :) Yeah and if they (somehow) obtain an ASN for this non-multihoming venture then that completely wastes an ASN for no good. And as we all know there aren't an infinite number of those either. It's not huge, but it is there. And like I said, many people argue over additions to the table which are actually useful. -- TTFN, patrick -- Genius might be described as a supreme capacity for getting its possessors into trouble of all kinds. -- Samuel Butler
Re: PI space and colocation
Thus spake Chris Adams [EMAIL PROTECTED] Once upon a time, Patrick W. Gilmore [EMAIL PROTECTED] said: It adds zero useful data to the global table, but increases RAM, CPU, etc. on every router looking at the global table. How much difference is there between one AS (the colo provider) announcing a prefix and another AS (the customer) announcing it through the first AS (the colo provider)? If the space is ARIN assigned PI, it isn't going to aggregate with the colo provider's space, so the prefix will still be a separate announcement. The only difference is the AS path is one entry longer. Routing slots aren't the only resource you're consuming. In general, many of the prefixes coming out of a given AS have common attributes, e.g. path, MEDs, etc. Those attributes are stored only once (at least in the BGP implementation I know) even if they're used by hundreds of prefixes. If you attach a new leaf AS, it must, by necessity, consume another one of those slots. If the customer prefix were announced by the upstream, however, it would not require an additional attribute slot; it'd reuse one of the existing ones. Now, I'm not aware that there's any serious shortage of attribute slots like there is routing slots, but there's no sense wasting them if there's no gain to be had doing it. Save your (and everyone else's) RAM for more prefixes. S Stephen SprunkStupid people surround themselves with smart CCIE #3723 people. Smart people surround themselves with K5SSS smart people who disagree with them. --Aaron Sorkin
Re: PI space and colocation
Routing slots aren't the only resource you're consuming. In general, many of the prefixes coming out of a given AS have common attributes, e.g. path, MEDs, etc. Those attributes are stored only once (at least in the BGP implementation I know) even if they're used by hundreds of prefixes. If you attach a new leaf AS, it must, by necessity, consume another one of those slots. If the customer prefix were announced by the upstream, however, it would not require an additional attribute slot; it'd reuse one of the existing ones. Now, I'm not aware that there's any serious shortage of attribute slots like there is routing slots, but there's no sense wasting them if there's no gain to be had doing it. Save your (and everyone else's) RAM for more prefixes. I think that this deserves a bit more explanation... Most implementations use an attribute cache. An entry in this cache typically consists of a set of different attributes. Which attributes constitute a cache entry is entirely up to the implementation. Each prefix will have a number of paths. Each path will point to an attribute cache entry and also contain one or more other uncached attributes. Individual attributes themselves may also be cached. The primary attribute cache may or may not include the AS path. If it does not, it is very likely that there is a cache for the AS paths. Again, this is all implementation dependent. If an implementation does cache AS paths independently from the attribute cache, then the cost of a stub AS is only one more AS path entry in the AS path cache. If an implementation does not cache AS paths independently, then creating a stub AS will create a new attribute cache entry, complete with AS path. Regardless of this, it should be noted that this is only using BGP table RAM. This should not affect the main routing table or the forwarding table. Having an additional PI prefix in the first place is the expensive part, as that does consume BGP RAM, routing table RAM and forwarding table entries. IMHO, wasting any resource is unfortunate, but the cost of additional forwarding table entries far outstrips the cost of additional DRAM. Thus, adding an additional prefix does merit a significant shout from others, but the stub AS should only be an incremental whimper. Regards, Tony
Re: PI space and colocation
i On Wed, 18 Jan 2006 [EMAIL PROTECTED] wrote: If one gets PI space from ARIN for their network, then moves the servers to a rack at a data center (still using the space efficiently), will most colocation providers announce this space for them, or would most providers require them to take allocated space from them? Most larger colo providers will do so happily, provided you have sufficient expertise to operate your own BGP router and make the announcement to them. Is it a reasonable alternative to establish a BGP connection with the provider over ethernet? Yes. Is this ok per ARINs requirements, assuming you first acquired this space under their multihomed network guidelines? It's okay regardless of the policy under which you received the space. -Bill
Re: PI space and colocation
On Jan 18, 2006, at 6:22 PM, Tony Li wrote: IMHO, wasting any resource is unfortunate, but the cost of additional forwarding table entries far outstrips the cost of additional DRAM. Thus, adding an additional prefix does merit a significant shout from others, but the stub AS should only be an incremental whimper. It's not just the amount of resources spent, it's what you get for them. Spending a little on nothing is worse than spending more on something useful. Personally, I think a prefix which gives routability info is useful. A Stub AS is just a waste. -- TTFN, patrick P.S. This also means a /24 with the same AS path as the enclosing /16 is also a waste - an even bigger one.
Re: Collateral Damage
1 Yes 2 No 3 No 4 No -Original Message- From: Patrick W. Gilmore [EMAIL PROTECTED] Subj: Collateral Damage Date: Tue Jan 17, 2006 4:44 pm Size: 2K To: [EMAIL PROTECTED] cc: Patrick W. Gilmore [EMAIL PROTECTED] My previous post sparked quite a bit of traffic (mostly to me personally). It also sparked some confusion. That's mostly my fault for writing e-mails far too late at night and mixing it with an emotionally charged thread. So I would like to separate my questions out of the GoDaddy thread, write them slightly differently, and give a little more scope for clarity. These questions are designed as yes/no, not it depends. The idea being if there are general circumstances (not billion-in-one corner cases) which would make the action in question acceptable, please answer yes, and move to the next question. For instance, I would answer the first question as yes, because there are circumstances which happen reasonably often where I would take down an innocent domain to stop network abuse. (E.g. I would null-route a /24 that is sending gigabits of DoS traffic, even if there is an innocent mail server in that block.) Anyway, on to the poll. You are welcome and encouraged to send the answers to me privately, I will collate and post back to the list in a few days. * Please answer yes/no. - Additional text is encouraged, but I need a yes/no to tabulate the vote. * These questions are not regarding a specific provider or even specific abuse type. - You can consider spam, DoS, phishing, hacking, etc. - Please assume what you consider to be the worst abuse which is common on the Internet today. * There is a basic assumption that due diligence has been applied. - You have investigated and are certain this is not a false positive or such. - I hope we can all agree that shutting someone down without doing proper investigation is a Bad Thing. * There is a basic assumption of notification and grace period. - The provider in question knows Bad Things are happening. - The provider in question has had a reasonable amount of time to fix said Bad Things. - Bad Things are still happening. * Please do not consider extremely rare occurrences or utra-extreme scenarios. - Null-routing an IP address to stop nuclear war is not in scope of this survey. If you have any questions, please feel free to e-mail me. 1) Do you think it is ever acceptable to cause collateral damage to innocent bystanders if it will stop network abuse? 2) If yes, do you still think it is ever acceptable to take down a provider with 100s of innocent customers because one customer is misbehaving? 3) If yes, do you still think it is ever acceptable if the misbehaving customer is not intentionally misbehaving - i.e. they've been hacked? 4) If yes, do you still think it is ever acceptable if the collateral damage (taking out 100s of innocent businesses) doesn't actually stop the spam run / DoS attack / etc.? Thank you all for your time. -- TTFN, patrick
Re: Intradomain Traffic Engineering
Hi Deepak, Thanks a lot for your opinions! Especially, your idea that TE may be more appropriate to stub networks is very interesting. Is it a common practice of large transit ISPs to determine the pricing based on 'what the customer's traffic looks like and when'? And do the transit ISPs actively use traffic regulation (rate control and/or traffic shaping) to control the incoming traffic, or they just simply use some pricing scheme based on traffic pattern, such as 95-percentile charging? Thanks, Hao This email covers a lot of issues, perhaps it'll start a discussion.I think the question depends on how big a core you are talking about. Excluding local effects (the operator of the network bounces a link orloses a router, etc), I doubt if you have a significantly large networkyou have many effects that shift traffic faster than 10s of seconds (upperbound on this statement is ~30 seconds).For example, if you lose a BGP session, it may take more than 30seconds for the router to notice it. Once it realizes that its gone, itmay re-route traffic very rapidly. But it would still take a while (at least a few seconds for a local link, more for a backbone link) beforethat traffic really renormalizes). This has more to do with TCP noticingpacket loss, backing off [only for the traffic that has been effected] and starting back up. It takes up to half a second to *establish* asingle TCP session on an average latency link.So, the trick would be to discover the traffic has gone or gone wonkybefore the BGP session is dropped. This would allow your algorithm to back off until a new /normal/ has been established.However, the talk of traffic engineering and maximum utilization alwayscome into vogue when folks want to squeeze more utilization out of theirnetworks without really spending more money. IMO, the best time to use TE is when customer-links to your network approach your maximum corespeed [relative here... there is /core/ in your datacenter/pop and thereis /core/ that is your network to the point the packets get handed off on average]. Often this limit on the operator's core is technologyimposed (though budgetary concerns get in there too).I think the technology doesn't really exist at a scalable level tooperate for the worst-case scenario, despite what some people may say. Our traffic measurement/link measurement tools are almost all average...and spot checks are of only marginal value. I would suggest that thisis because of the nature of TCP. If the Internet were UDP based, there would be a *lot* more flash traffic problems. So, for those who have ahigh amount of UDP traffic (media streamers, DNS hosts, etc) would havea very different experience.I'm not the first person to say it, and I can't remember the first place I heard it... but I'd suggest that the core is not where TE has the bestbenefits. Cores by their nature need to be overengineered. You havevery little flexibility because the demands on them are wide [they need to handle UDP and TCP, low latency and high latency acceptableapplications with aplomb].TE belongs to the Customer or non-backbone operating ISP. If one were tostart an ISP where all residential customer connections were 1Gb/s I could conceivably have thousands of customers operating without needing200Gb/s of uplink [assuming that were really feasible for a network withvery little traffic terminating on the network]. By using TE I could shape my peak traffic needs (MLU) to approach my average. This wouldmake me a much more desirable customer to sell transit to.TE, MLU, and other concerns while most well understood bycore-operators, aren't by customers. Core operators may eventually need to push these concerns to customers if backbone link speeds do not stayfar above end-user connection speeds. [on an ICB basis, they are --whenever you want to buy a few OC-48s in a single POP or an OC-192customer connection, someone is always going to ask you what your traffic looks like and when]. This would be easiest to push over byproviding differential pricing. Enforcement and Analysis of *what* is adesirable traffic pattern and what financial value that provides is where we are largely lacking today. Since a customer knows their trafficand their needs better than a core operator, they would be much betterat enforcing traffic flows/engineering. This is better than a core that optimizes for its own link utilization instead one that just tries tostay as empty as possible for as long as possible.This is way early in the day for me, so this may not make any sense.YMMV, Deepak JainAiNET
Security inside AS
Hi, I understand that in theory we need to protect our IGPs from all sorts of attacks. But do we really have service providers who enable authentication (MD5, etc) inside their ASes for their IGPs (OSPF/IS-IS)? Thanks, Glen
