Re: ATT NYC
It would also be interesting to know which backbone/core product requires a reboot to activate OSPF configuration changes. Sounds like something one should stay away from. Pete Frank Scalzo wrote: Whoops! 2 hours to find routers w/o an IGP tsk tsk. Dear ATT IP Services Customer, Please be advised of the following: Date: 8/28/02 Customer Care TT#: 1070909 Start of Impairment:14:56 ET End of Impairment: 16:52 ET On behalf of ATT, we would like to extend our apologies for any inconveniences to your business caused by the service impairment and delay in restoring your service. ATT IP Services customers with traffic routed through our Chicago backbone routers may have been affected by this impairment. Our Network Engineers found that OSPF* network statements were missing from two backbone routers, causing the routing issues that customers were experiencing. ATT Network Engineers manually reloaded the OSPF network statements and then proceeded to reboot the routers in order for the changes to take effect. The network statements were mistakenly deleted during a routine configuration update to our backbone routers. Management has been made aware of these findings and appropriate actions will be taken to ensure this situation does not re-occur. Prior reported information was leading the ATT Network Engineers to believe that there were issues with the route reflectors being out of synch. However, this was only symptomatic of the problem stated above. In other words, due to the missing network statements, the route reflectors were not advertising certain networks; therefore traffic was not properly routed. It is ATT?s goal to provide the highest level of service to our customers. We appreciate your business and look forward to continuing our relationship in the future. *Routing protocol (Open Shortest Path First) Depending on the particular IP access services to which you are subscribed you may also find additional information as it becomes available at: ATT MIS: https://mis-att.bus.att.com/ ATT VPNS: http://www.vpn.att.net If you require further information, please feel free to contact ATT at: ATT MIS: 1-888-613-6330 ATT VPNS: 1-888-613-6501 Thank you for using ATT. Sincerely, The ATT Customer Care Team -Original Message- From: Matt Levine [mailto:[EMAIL PROTECTED]] Sent: Wed 8/28/2002 6:21 PM To: Mike Tancsa Cc: Wes Bachman; [EMAIL PROTECTED] Subject:Re: ATT NYC On Wednesday, August 28, 2002, at 04:17 PM, Mike Tancsa wrote: route-server.ip.att.net is not currently reachable, but AS15290's router server is for those who want a view on things... Interestingly enough, ATT is announcing 12.0.0.0/23 to BBN (and nobody else, including AS7018 internal).. route-server.east.attcanada.com. and route-server.west.attcanada.com. which come in handy :-) ---Mike At 04:11 PM 28/08/2002 -0400, Mike Tancsa wrote: I am seeing this as well. One of my upstreams (ATT Canada- 15290) has connections with ATT US (7018) in Chicago and Vancouver. Chicago seems to have disappeared for me and all traffic bound via that path is going via Vancouver now. ---Mike At 02:52 PM 28/08/2002 -0500, Wes Bachman wrote: Bryan, There is a known ATT outage in Chicago currently. Could this be effecting you in some way? -Wes On Wed, 2002-08-28 at 14:44, Bryan Heitman wrote: Anyone seeing any problems with ATT in new york? Best regards, Bryan Heitman Interland, Inc. -- Wes Bachman System Network Administration, Software Development Leepfrog Technologies, Inc. [EMAIL PROTECTED] -- Matt Levine @Home: [EMAIL PROTECTED] @Work: [EMAIL PROTECTED] ICQ : 17080004 AIM : exile GPG : http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x6C0D04CF The Trouble with doing anything right the first time is that nobody appreciates how difficult it was. -BIX
Re: Paul's Mailfrom (Was: IETF SMTP Working Group Proposal at
On Tue, 27 Aug 2002 03:43:42 +, Paul Vixie [EMAIL PROTECTED] writes: dialup users and get away with it, but that person was VERY busy. that ratio only works if the rest of the system is designed to repel the professional spammers, [[SNIP]], and instant termination even at 4AM on sunday morning, ~30 hours or more before the account manager or any other manager could give approval. Careful here I don't know if the rest of you saw this.. But Edward Felton (computer science faculty at Princeton University) had his site blackholed for *three* days because of overzealousness on the parts of spamcop and his ISP in responding to a mistaken spamcop complaint. http://catless.ncl.ac.uk/Risks/22.19.html#subj7 http://catless.ncl.ac.uk/Risks/22.21.html#subj4 There must be a balance. Mistakes happen. How overzealous do you want ISP's to be be at shutting off spam sites or accounts? Some might consider the costs of mistakes acceptable, but are they the majority? Or a minority? If such a system is created, how will this new system be abused, when an innocent misunderstanding and a single message took down a site created by princeton faculty member for 3 DAYS This was an accident How fast will someone's site go down if someone doesn't like them? Given this, who on the list would want to be a customer of any ISP with behavior like Felton's? Scott ** Keystone SpamKops Edward W. Felten [EMAIL PROTECTED] Fri, 16 Aug 2002 09:45:06 -0400 I recently set up a web site at www.freedom-to-tinker.com. It's a weblog containing my commentary on various issues. Earlier this week, my ISP shut off the site, because the site had appeared on a list of spammers published by an outfit called SpamCop. Apparently, this happened because one person, whose identity I was not allowed to learn, had sent SpamCop an accusation saying that he had received an unwanted e-mail message, which I was not allowed to see, that did not come from me but that did mention my web site. On that evidence SpamCop declared me guilty of spamming and decreed that my site should be shut down. Never mind that I had never sent a single e-mail message from the site. Never mind that my site was not selling anything. Naturally, I was not allowed to see the accusation, or to learn who had submitted it, or to rebut it, or even to communicate with an actual human being at SpamCop. You see, they're not interested in listening to complaints from spammers. With help from my ISP, I eventually learned that the offending message was sent on a legitimate mailing list, and that the person who had complained was indeed subscribed to that list, and had erroneously reported the message as unsolicited. Ironically, the offending message was sent by someone who liked my site and wanted to recommend it to others. Everybody involved (me, my ISP, the person who filed the complaint, and the author of the message) agreed that the report was an error, and we all told this to SpamCop. Naturally, SpamCop failed to respond and continued to block the site. Why did my ISP shut me down? According to the ISP, SpamCop's policy is to put all of the ISP's accounts on the block list if the ISP does not shut down the accused party's site. Note the similarities to the worst type of Stalinist justice system: conviction is based on a single anonymous complaint; conviction is based not on anything the accused did but on favorable comments about him by the wrong people; the evidence is withheld from the accused; there is no procedure for challenging erroneous or malicious accusations; and others are punished based on mere proximity to the accused (leading to shunning of the accused, even if he is clearly innocent). Note also that the evidence against me consisted only of a single unsigned e-mail message which would have been trivial for anyone to forge. Thus SpamCop provides an easy denial of service attack against a web site. The only bright spot in this picture is that our real justice system allows lawsuits to be filed against guys like SpamCop for libel and/or defamation. My guess is that eventually somebody will do that and put SpamCop out of business.
Re: Contact for dmisinetworks.com /
After literally YEARS of complaining, I think theres so one alive at bell south abuse...they're typical bell-spawn...fat, lazy, and un-responsive. At 07:13 8/29/02 +0100, you wrote: Currently seeking an abuse contact for the above domain, or the party responsible for netblock that 66.21.84.209 is a part of: Netname: BELLSNET-BLK8 Netblock: 66.20.0.0 - 66.21.255.255 Maintainer: BELL Seeing repeated abuse from a single user against multiple hosts, and emails to abuse@bellsouth have gone unanswered. -- Avleen Vig: Work Time: Unix Systems Admin Email: [EMAIL PROTECTED] Play Time: Network Security Admin Pager: av-pager, at silverwraith.com Smurf Amplifier Finding Executive:http://www.ircnetops.org/smurf
RE: Paul's Mailfrom (Was: IETF SMTP Working Group Proposal at
Barry Shein wrote: Fair enough but let me explain why I find this unsatisfying. It's like I'm living in a neighborhood where the crime rate is rising and rising, and you're selling security grates and better locks. They even seem to keep the crooks out of the bedroom at night for a while anyhow, so that's your measure, often keeps you from being murdered! The problem is, the crooks are still banging at the doors, trying to crowbar their way in, etc. But as long as you live that's better than letting them have their ways now is it. Now stop the anal-ogies and come up with something that will _stop_ the crackdealing. You might notice due the fact that the internet is an immense thing, spread over many different countries with many different regulations and laws that one certainly can't break down the crackhouses and stop the drive-by's Let me give two common spam examples to show this is a very tight analogy: a) The other day our mail servers were groaning unusually. What was happening was that someone had firehosed MSN.COM with a spam with a return address forged with our domain. So even tho we were blocking it, in fact the bounce user didn't exist so we didn't really have to block it, all of MSN's server power being pointed at us trying to return many thousands of bounces as fast as they could was quite painful. b) A few weeks ago I counted over 200 open relays simultaneously spewing the same spam at us. Thats where RBL's are for, they close them up, if you had used an RBL your box would simply deny those relays at all, block them IP based and bingo no spewing from them. The point being they will fill your pipes, cause you to need more servers just to run these various filters, run our people ragged, etc. If it's war you are talking about, they could also 'simply' ddos your boxes away, with spam or with packets, they don't mind... So, it's nice that someone is providing security grates and alarm systems etc, but it'd be nice if the crack (spam) houses would just shut down entirely so we could sit on our porches and chit-chat without worrying about the constant drive-by shootings. One way of doing that is pulling your plug from the internet, there are always going to be people who don't and won't play nice simply because they see some easy bucks or at least even if they think they see them ;) Or they simply won't because they think it's fun to harrass others. Kick one down and the next comes up, put a bar in their faces and they will need to do more work to get in, but at least one is not keeping the door open for them putting it in your words: 'killing you in your sleep'. If you get my drift. And that's going to require socio-legal approaches, not ever stronger security grates. Nopes all it takes is making the protocol secure against these fake messages. This takes away the way of even sending you the message at all and stops your bounces ;) Because sooner or later you can't see out the grated windows any more or get some air through them, and you're afraid to go outside... Never been in the city (those places where more than 100k people live) now have you ? Greets, Jeroen
Re: IPv6 Interview Questions and critic
What is interesting is that people can identify a EUI-64 unicast address no matter where you are. For example, i use my laptop at work and at home (assuming I had an ipv6 connection at home). I could be identified as the same computer, without using cookies, since my base 64 address would be the same, despite the network prefix. What I as external viewer could determine would that you where a computer that moved. From the frequency I could probably tell that you where a laptop. I would not tell me what would be home or work, and it would not say who you actually where. - kurtis -
Re: (RADIATOR) wireless access point accounting
Hello again - Many thanks to all those who replied to my request regarding wireless accounting via radius. It is obviously fairly early days looking at the replies I received, with the Cisco being the only unit sending (partially) useful accounting starts and accounting stops (note that this is not an exhaustive survey). Any additions, corrections, modifications, etc. gratefully received. Thanks again. regards Hugh On Saturday, August 24, 2002, at 12:35 AM, Hugh Irvine wrote: Hello Everyone - I have recently been investigating wireless access points for 802.1x. Is anyone out there using radius authentication and accounting with these devices? If so could you please send me copies of the authentication requests and the accounting starts and stops? Any war stories regarding different brands would also be welcome. many thanks Hugh NB: I am travelling this week, so there may be delays in our correspondence. -- Radiator: the most portable, flexible and configurable RADIUS server anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, MacOS X. - Nets: internetwork inventory and management - graphical, extensible, flexible with hardware, software, platform and database independence. === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message. -- Radiator: the most portable, flexible and configurable RADIUS server anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, MacOS X. - Nets: internetwork inventory and management - graphical, extensible, flexible with hardware, software, platform and database independence.
irtf-chair@ietf.org: Internet Measurement Research Group
Folks- A new group within the IRTF has been formed that will focus on measuring networks. It seems obvious that operators will have some valuable input into these issues and I would encourage folks to participate if they can. The announcement ( group charter) are attached. allman -- Mark Allman -- BBN/NASA GRC -- http://roland.grc.nasa.gov/~mallman/ --- Forwarded Message From: [EMAIL PROTECTED] To: IETF-Announce:;;@loki.ietf.org Subject: Internet Measurement Research Group Date: Thu, 29 Aug 2002 07:24:02 -0400 A new IRTF research group, IMRG (Internet Measurement Research Group), has begun, with the appended charter. Use [EMAIL PROTECTED] to subscribe to the mailing list. See http://imrg.grc.nasa.gov/imrg/ for further information. - - Vern Paxson (IRTF chair) - -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ There is considerable network measurement work being conducted within the Internet community -- both in standards bodies (e.g., IETF IPPM WG) and in various research labs. The goal of the Internet Measurement Research Group (IMRG) is to provide a venue to: (1) provide a forum for discussion of Internet measurement research issues, (2) aid in the coordination of various research projects, (3) assess new measurement techniques, and (4) increase interactions between operators, developers of measurement tools and techniques, and researchers who analyze and model Internet dynamics. The scope includes all kinds of network measurement (active techniques, passive monitoring, end-point probing, in-network methods, network layer, transport layer, application layer, etc.). The RG will both attempt to design new measurement techniques and analyze measurements of the network taken. The following represent examples of the types of projects that the RG might undertake: Tackle outstanding issues dealing with measurement infrastructures (e.g., Surveyor, NIMI), such as: scalability of meshes, security of measurement tools in the mesh, access control, resource control, scheduling issues. Tackle the often thorny issue of sharing measurement data within the community. The RG could define a systematic way for storing measurements and any needed meta-data that should be kept with the measurements. In addition, the RG could foster research into systems for remote requests for measurement, analysis, and anonymization, facilitating a formed of reduced access to data that cannot be directly released. Provide a venue for assessing new measurement techniques, and a forum for sharing preliminary findings in rough form, to encourage further work and collaboration. Provide a venue for developing models based on network measurements, helping to better understand network dynamics and aiding researchers attempting to conduct useful simulations of the network. Foster communication between the research and operations communities. For example, operators could provide feedback to researchers as to what sorts of network properties/characteristics they would like to see measured, and how well current techniques work. Catalog core problems that need to be addressed. Even if the RG is not actively working on these problems, having a wish list of outstanding problems may foster work in these areas. Coordination - the RG will provide: A venue for exploring measurement techniques before they are ready to be standardized by the IETF (in IPPM, for instance). A venue for discussing real world experience with IETF defined metrics and measurement techniques. A measurement arm to various IETF working groups to gain a better understanding of how protocols work in the wild (e.g., which HTTP capabilities are being implemented or the performance of the global DNS system). --- End of Forwarded Message
Broadening the IPv6 discussion
Since we're on the topic of IPv6, I wanted to gauge the current attitude of the ops. community toward its deployment. We're seeing a lot more interest from our enterprise clients in using v6, especially as things like VoIP and PDAs consume their address pools, and NAT gets in the way of collaborative apps such as netmeeting and business-to-business connectivity. However, the road-block seems to be the lack of ISPs that offer IPv6 services. Given that places like China Japan are now mandating IPv6 for their ISPs, does anyone see anything resembling a growing momentum toward IPv6 adoption, or is it still a moot issue for you guys? Irwin
RE: ATT NYC
This is impressive. It's very nice to see a carrier providing this level of technical analysis to customers after an outage. Many carriers would be embaressed or try to gloss over what has happened. Sprintlink, in the old days, was also very good about this. Customers really appreciate honesty and being kept in the loop on these sorts of things. Sure, this was a dumb mistake, but everyone has made mistakes - no carrier or engineer is perfect. I think ATT gets big points on this one. It's a sad statement about our industry that being honest with your customers is the mark of outstanding customer service, rather than average customer service. - Daniel Golding -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Frank Scalzo Sent: Wednesday, August 28, 2002 11:21 PM To: Matt Levine; Mike Tancsa Cc: Wes Bachman; [EMAIL PROTECTED] Subject: RE: ATT NYC Whoops! 2 hours to find routers w/o an IGP tsk tsk. Dear ATT IP Services Customer, Please be advised of the following: Date: 8/28/02 Customer Care TT#: 1070909 Start of Impairment:14:56 ET End of Impairment: 16:52 ET On behalf of ATT, we would like to extend our apologies for any inconveniences to your business caused by the service impairment and delay in restoring your service. ATT IP Services customers with traffic routed through our Chicago backbone routers may have been affected by this impairment. Our Network Engineers found that OSPF* network statements were missing from two backbone routers, causing the routing issues that customers were experiencing. ATT Network Engineers manually reloaded the OSPF network statements and then proceeded to reboot the routers in order for the changes to take effect. The network statements were mistakenly deleted during a routine configuration update to our backbone routers. Management has been made aware of these findings and appropriate actions will be taken to ensure this situation does not re-occur. Prior reported information was leading the ATT Network Engineers to believe that there were issues with the route reflectors being out of synch. However, this was only symptomatic of the problem stated above. In other words, due to the missing network statements, the route reflectors were not advertising certain networks; therefore traffic was not properly routed. It is ATTs goal to provide the highest level of service to our customers. We appreciate your business and look forward to continuing our relationship in the future. *Routing protocol (Open Shortest Path First) Depending on the particular IP access services to which you are subscribed you may also find additional information as it becomes available at: ATT MIS: https://mis-att.bus.att.com/ ATT VPNS: http://www.vpn.att.net If you require further information, please feel free to contact ATT at: ATT MIS: 1-888-613-6330 ATT VPNS: 1-888-613-6501 Thank you for using ATT. Sincerely, The ATT Customer Care Team -Original Message- From: Matt Levine [mailto:[EMAIL PROTECTED]] Sent: Wed 8/28/2002 6:21 PM To: Mike Tancsa Cc: Wes Bachman; [EMAIL PROTECTED] Subject: Re: ATT NYC On Wednesday, August 28, 2002, at 04:17 PM, Mike Tancsa wrote: route-server.ip.att.net is not currently reachable, but AS15290's router server is for those who want a view on things... Interestingly enough, ATT is announcing 12.0.0.0/23 to BBN (and nobody else, including AS7018 internal).. route-server.east.attcanada.com. and route-server.west.attcanada.com. which come in handy :-) ---Mike At 04:11 PM 28/08/2002 -0400, Mike Tancsa wrote: I am seeing this as well. One of my upstreams (ATT Canada- 15290) has connections with ATT US (7018) in Chicago and Vancouver. Chicago seems to have disappeared for me and all traffic bound via that path is going via Vancouver now. ---Mike At 02:52 PM 28/08/2002 -0500, Wes Bachman wrote: Bryan, There is a known ATT outage in Chicago currently. Could this be effecting you in some way? -Wes On Wed, 2002-08-28 at 14:44, Bryan Heitman wrote: Anyone seeing any problems with ATT in new york? Best regards, Bryan Heitman Interland, Inc. -- Wes Bachman System Network Administration, Software Development Leepfrog Technologies, Inc. [EMAIL PROTECTED] -- Matt Levine @Home: [EMAIL PROTECTED] @Work: [EMAIL PROTECTED] ICQ : 17080004 AIM : exile GPG : http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x6C0D04CF The Trouble with doing anything right the first time is that nobody appreciates how difficult it was. -BIX
RE: Broadening the IPv6 discussion
Hmm. I'm afraid that I have to disagree with just about everything you've said :) . I haven't seen any enterprise folks demanding v6 - If VOIP and PDA's (?) use up their IP addresses, they can easily ask for more. The more you use, the more you get. There is no shortage of v4 space. China and Japan are not mandating anything, AFAIK. I believe that v6 deployment is being encouraged by some countries, and the spread of 3G is helping things along, but we have yet to see really widespread v6 deployments anywhere. Basically, major backbone networks will deploy v6 when it makes economic sense for them to do so. Right now, there is no demand and no revenue upside. I don't expect this to change in the near future. v6 is, currently, a solution in search of a problem. v4 space is being consumed slowly, but we are quite some time from a crisis. Of course, even when we consume all such ipv4 space, there are still expedients that can be used, including making v4 assets tradable and fungible. - Dan Irwin Lazar Said... Since we're on the topic of IPv6, I wanted to gauge the current attitude of the ops. community toward its deployment. We're seeing a lot more interest from our enterprise clients in using v6, especially as things like VoIP and PDAs consume their address pools, and NAT gets in the way of collaborative apps such as netmeeting and business-to-business connectivity. However, the road-block seems to be the lack of ISPs that offer IPv6 services. Given that places like China Japan are now mandating IPv6 for their ISPs, does anyone see anything resembling a growing momentum toward IPv6 adoption, or is it still a moot issue for you guys? Irwin
RE: ATT NYC
Has anybody mentioned the benefits of ISIS as an IGP to them. Kesva -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Daniel Golding Sent: Thursday, August 29, 2002 10:57 AM To: Frank Scalzo; Matt Levine; Mike Tancsa Cc: Wes Bachman; [EMAIL PROTECTED] Subject: RE: ATT NYC This is impressive. It's very nice to see a carrier providing this level of technical analysis to customers after an outage. Many carriers would be embaressed or try to gloss over what has happened. Sprintlink, in the old days, was also very good about this. Customers really appreciate honesty and being kept in the loop on these sorts of things. Sure, this was a dumb mistake, but everyone has made mistakes - no carrier or engineer is perfect. I think ATT gets big points on this one. It's a sad statement about our industry that being honest with your customers is the mark of outstanding customer service, rather than average customer service. - Daniel Golding -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Frank Scalzo Sent: Wednesday, August 28, 2002 11:21 PM To: Matt Levine; Mike Tancsa Cc: Wes Bachman; [EMAIL PROTECTED] Subject: RE: ATT NYC Whoops! 2 hours to find routers w/o an IGP tsk tsk. Dear ATT IP Services Customer, Please be advised of the following: Date: 8/28/02 Customer Care TT#: 1070909 Start of Impairment:14:56 ET End of Impairment: 16:52 ET On behalf of ATT, we would like to extend our apologies for any inconveniences to your business caused by the service impairment and delay in restoring your service. ATT IP Services customers with traffic routed through our Chicago backbone routers may have been affected by this impairment. Our Network Engineers found that OSPF* network statements were missing from two backbone routers, causing the routing issues that customers were experiencing. ATT Network Engineers manually reloaded the OSPF network statements and then proceeded to reboot the routers in order for the changes to take effect. The network statements were mistakenly deleted during a routine configuration update to our backbone routers. Management has been made aware of these findings and appropriate actions will be taken to ensure this situation does not re-occur. Prior reported information was leading the ATT Network Engineers to believe that there were issues with the route reflectors being out of synch. However, this was only symptomatic of the problem stated above. In other words, due to the missing network statements, the route reflectors were not advertising certain networks; therefore traffic was not properly routed. It is ATTs goal to provide the highest level of service to our customers. We appreciate your business and look forward to continuing our relationship in the future. *Routing protocol (Open Shortest Path First) Depending on the particular IP access services to which you are subscribed you may also find additional information as it becomes available at: ATT MIS: https://mis-att.bus.att.com/ ATT VPNS: http://www.vpn.att.net If you require further information, please feel free to contact ATT at: ATT MIS: 1-888-613-6330 ATT VPNS: 1-888-613-6501 Thank you for using ATT. Sincerely, The ATT Customer Care Team -Original Message- From: Matt Levine [mailto:[EMAIL PROTECTED]] Sent: Wed 8/28/2002 6:21 PM To: Mike Tancsa Cc: Wes Bachman; [EMAIL PROTECTED] Subject: Re: ATT NYC On Wednesday, August 28, 2002, at 04:17 PM, Mike Tancsa wrote: route-server.ip.att.net is not currently reachable, but AS15290's router server is for those who want a view on things... Interestingly enough, ATT is announcing 12.0.0.0/23 to BBN (and nobody else, including AS7018 internal).. route-server.east.attcanada.com. and route-server.west.attcanada.com. which come in handy :-) ---Mike At 04:11 PM 28/08/2002 -0400, Mike Tancsa wrote: I am seeing this as well. One of my upstreams (ATT Canada- 15290) has connections with ATT US (7018) in Chicago and Vancouver. Chicago seems to have disappeared for me and all traffic bound via that path is going via Vancouver now. ---Mike At 02:52 PM 28/08/2002 -0500, Wes Bachman wrote: Bryan, There is a known ATT outage in Chicago currently. Could this be effecting you in some way? -Wes On Wed, 2002-08-28 at 14:44, Bryan Heitman wrote: Anyone seeing any problems with ATT in new york? Best regards, Bryan Heitman Interland, Inc. -- Wes Bachman System Network Administration, Software Development Leepfrog Technologies, Inc. [EMAIL PROTECTED] -- Matt Levine @Home: [EMAIL PROTECTED] @Work: [EMAIL PROTECTED] ICQ : 17080004 AIM : exile GPG : http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x6C0D04CF
Re: Broadening the IPv6 discussion
Thus spake Daniel Golding [EMAIL PROTECTED] Hmm. I'm afraid that I have to disagree with just about everything you've said :) . I haven't seen any enterprise folks demanding v6 - If VOIP and PDA's (?) use up their IP addresses, they can easily ask for more. The more you use, the more you get. There is no shortage of v4 space. Most enterprise folks use nowhere near their paltry allotment of IPv4 addresses because 95% or more of their hosts are on RFC1918 space. Even most companies with multiple class B legacy allocations use RFC1918 internally and are just holding the class B's so they can multihome effectively. Basically, major backbone networks will deploy v6 when it makes economic sense for them to do so. Right now, there is no demand and no revenue upside. I don't expect this to change in the near future. Enterprise networks will not be the driver for ISPs to go to IPv6; NAT is too entrenched. Perhaps greater adoption of always-on broadband access will be the necessary push. S
Re: Paul's Mailfrom (Was: IETF SMTP Working Group Proposal at
http://catless.ncl.ac.uk/Risks/22.19.html#subj7 http://catless.ncl.ac.uk/Risks/22.21.html#subj4 There must be a balance. Mistakes happen. How overzealous do you want ISP's to be be at shutting off spam sites or accounts? Some might consider the costs of mistakes acceptable, but are they the majority? Or a minority? zeal must become the norm. there are too many legitimate sources of error to make any loose assumptions about probable illegitimacy when faced with a report. under a high zeal regime, errors will be made until training and policy and toolworks all catches up to the need. -- Paul Vixie
RE: ATT NYC
On Thu, 29 Aug 2002, NAIDOO Kesva FTLD/IAP wrote: : :Has anybody mentioned the benefits of ISIS as an IGP to them. : Of course, ISIS is no more resilient against the deletion of igp configuration than OSPF. cheers, brian
RE: Broadening the IPv6 discussion
Mmmm... me too post. I have to agree with Dan on this. The only people who ask me about IPv6 are people who have heard something about it from some tech magazine and want the Newest Thing. Much of its useful functionality (except the widened address space) is available in v4, and v4 is deployed. There is no commercial demand for a v6 backbone. That's the big roadblock right now. -Dave On 8/29/2002 at 11:05:49 -0400, Daniel Golding said: Hmm. I'm afraid that I have to disagree with just about everything you've said :) . I haven't seen any enterprise folks demanding v6 - If VOIP and PDA's (?) use up their IP addresses, they can easily ask for more. The more you use, the more you get. There is no shortage of v4 space. China and Japan are not mandating anything, AFAIK. I believe that v6 deployment is being encouraged by some countries, and the spread of 3G is helping things along, but we have yet to see really widespread v6 deployments anywhere. Basically, major backbone networks will deploy v6 when it makes economic sense for them to do so. Right now, there is no demand and no revenue upside. I don't expect this to change in the near future. v6 is, currently, a solution in search of a problem. v4 space is being consumed slowly, but we are quite some time from a crisis. Of course, even when we consume all such ipv4 space, there are still expedients that can be used, including making v4 assets tradable and fungible. - Dan Irwin Lazar Said... Since we're on the topic of IPv6, I wanted to gauge the current attitude of the ops. community toward its deployment. We're seeing a lot more interest from our enterprise clients in using v6, especially as things like VoIP and PDAs consume their address pools, and NAT gets in the way of collaborative apps such as netmeeting and business-to-business connectivity. However, the road-block seems to be the lack of ISPs that offer IPv6 services. Given that places like China Japan are now mandating IPv6 for their ISPs, does anyone see anything resembling a growing momentum toward IPv6 adoption, or is it still a moot issue for you guys? Irwin
RE: ATT NYC
Has anybody mentioned the benefits of ISIS as an IGP to them. Link-state protocols are evil, and when they break, they *really* break. I still do not see a compeling argument for not using BGP as your IGP. Alex
Re: ATT NYC
On Thu, Aug 29, 2002 at 01:09:54PM -0400, [EMAIL PROTECTED] wrote: Has anybody mentioned the benefits of ISIS as an IGP to them. Link-state protocols are evil, and when they break, they *really* break. I still do not see a compeling argument for not using BGP as your IGP. Slow convergence. Greetz, Peter -- MegaBIT - open air networking event - http://www.megabit.nl/
Re: ATT NYC
On Thu, 29 Aug 2002, Peter van Dijk wrote: On Thu, Aug 29, 2002 at 01:09:54PM -0400, [EMAIL PROTECTED] wrote: Has anybody mentioned the benefits of ISIS as an IGP to them. Link-state protocols are evil, and when they break, they *really* break. I still do not see a compeling argument for not using BGP as your IGP. Slow convergence. As well there is the issues of running a full iBGP mesh. I've actually been doing it, and now that I'm about to add my 5th router, OSPF is looking a lot better than configuring 4 more BGP sessions. I've heard some people recommend a route-reflector, but that would mean if the route-reflector goes down you're screwed. -Ralph
Re: ATT NYC
That's why you configure two. :) -C looking a lot better than configuring 4 more BGP sessions. I've heard some people recommend a route-reflector, but that would mean if the route-reflector goes down you're screwed. -Ralph msg04911/pgp0.pgp Description: PGP signature
RE: ATT NYC
On Thu, Aug 29, 2002 at 01:09:54PM -0400, [EMAIL PROTECTED] wrote: Has anybody mentioned the benefits of ISIS as an IGP to them. Link-state protocols are evil, and when they break, they *really* break. I still do not see a compeling argument for not using BGP as your IGP. Slow convergence. As well there is the issues of running a full iBGP mesh. I've actually been doing it, and now that I'm about to add my 5th router, OSPF is looking a lot better than configuring 4 more BGP sessions. I've heard some people recommend a route-reflector, but that would mean if the route-reflector goes down you're screwed. What about a well choosen (wrt topo) pair of them... Planning on doing away with that pesky IBGP mesh and just redistributing BGP into OSPF are we Ralph? There is so much wrong with the above post that I can't do anything except hang my head in shame for people running networks everywhere around the world. mh -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6)
Re: Broadening the IPv6 discussion
On Thu, 29 Aug 2002, Irwin Lazar wrote: Since we're on the topic of IPv6, I wanted to gauge the current attitude of the ops. community toward its deployment. We're seeing a lot more interest from our enterprise clients in using v6, Yes, we see this too. This is in addition to the continuing rise in tunnels in use we see via our free IPv6 tunnel broker at tunnelbroker.com. However, the road-block seems to be the lack of ISPs that offer IPv6 services. Ha! Ahem, no. We have IPv6 routers deployed nationally and have even sold IPv6 direct connections, even in the presence of the ability to get a free tunnel, because enterprise type clients want to have a business class level of service where they can call you for support (among other reasons). I'd say the observable low usage of IPv6 compared to IPv4 is because IPv6 is still in its early product phase where early adopters are still considering how it works and what you can do with it and suppliers are giving out free samples (i.e. all the tunnel brokers and 6to4 gateways out there). does anyone see anything resembling a growing momentum toward IPv6 adoption, Yes, it's an gradual trend. We are seeing and increase over time in active tunnels and in average traffic per tunnel. Right now IPv6 is something to research, if the trend of increasing usage continues it will become commercially significant. How inevitable of a trend you think this is depends on if you think every cell phone, car, light switch, tv, washer, dryer, toaster, etc will eventually have it's own IP address. If you don't think that IP addresses allocations are based on scarcity then IPv4 should rule for ever. If on the other hand... Mike. +- H U R R I C A N E - E L E C T R I C -+ | Mike Leber Direct Internet Connections Voice 510 580 4100 | | Hurricane Electric Web Hosting Colocation Fax 510 580 4151 | | [EMAIL PROTECTED] http://www.he.net | +---+
Re: ATT NYC
Um. Set up more than one reflector On Thu, 29 Aug 2002, Ralph Doncaster wrote: On Thu, 29 Aug 2002, Peter van Dijk wrote: On Thu, Aug 29, 2002 at 01:09:54PM -0400, [EMAIL PROTECTED] wrote: Has anybody mentioned the benefits of ISIS as an IGP to them. Link-state protocols are evil, and when they break, they *really* break. I still do not see a compeling argument for not using BGP as your IGP. Slow convergence. As well there is the issues of running a full iBGP mesh. I've actually been doing it, and now that I'm about to add my 5th router, OSPF is looking a lot better than configuring 4 more BGP sessions. I've heard some people recommend a route-reflector, but that would mean if the route-reflector goes down you're screwed. -Ralph
routing architectures ( was Re: ATT NYCrouting )
On Thu, 29 Aug 2002, Robert A. Hayden wrote: Um. Set up more than one reflector So how many is enough? I would think 3 is a minimum to come close to the reliability/redundancy of OSPF. -Ralph
RE: ATT NYC
Um. Set up more than one reflector yes... and align your setup with your physical topology(so making it useful); use other proto for mapping your infra, etc, etc,.. mh On Thu, 29 Aug 2002, Ralph Doncaster wrote: On Thu, 29 Aug 2002, Peter van Dijk wrote: On Thu, Aug 29, 2002 at 01:09:54PM -0400, [EMAIL PROTECTED] wrote: Has anybody mentioned the benefits of ISIS as an IGP to them. Link-state protocols are evil, and when they break, they *really* break. I still do not see a compeling argument for not using BGP as your IGP. Slow convergence. As well there is the issues of running a full iBGP mesh. I've actually been doing it, and now that I'm about o add my 5th router, OSPF is looking a lot better than configuring 4 more BGP sessions. I've heard some people recommend a route-reflector, but that would mean if the route-reflector goes down you're screwed. -Ralph
Re: routing architectures ( was Re: ATT NYCrouting )
It depends a lot on your topgraphy. For example, if you have a specific city/region aggregation center, your redundant boarder routers for that city are probably also RRs. Those boarders peer with your boarders in other cities as well as your intra-region routers. Of course, this is just one way. Trying not to start a religious war. On Thu, 29 Aug 2002, Ralph Doncaster wrote: On Thu, 29 Aug 2002, Robert A. Hayden wrote: Um. Set up more than one reflector So how many is enough? I would think 3 is a minimum to come close to the reliability/redundancy of OSPF. -Ralph
RE: ATT NYC
Yup. I like using OSPF to set up the mesh to the loopbacks and then ibgp as the IGP. On Thu, 29 Aug 2002, Michael Hallgren wrote: Um. Set up more than one reflector yes... and align your setup with your physical topology(so making it useful); use other proto for mapping your infra, etc, etc,.. mh On Thu, 29 Aug 2002, Ralph Doncaster wrote: On Thu, 29 Aug 2002, Peter van Dijk wrote: On Thu, Aug 29, 2002 at 01:09:54PM -0400, [EMAIL PROTECTED] wrote: Has anybody mentioned the benefits of ISIS as an IGP to them. Link-state protocols are evil, and when they break, they *really* break. I still do not see a compeling argument for not using BGP as your IGP. Slow convergence. As well there is the issues of running a full iBGP mesh. I've actually been doing it, and now that I'm about o add my 5th router, OSPF is looking a lot better than configuring 4 more BGP sessions. I've heard some people recommend a route-reflector, but that would mean if the route-reflector goes down you're screwed. -Ralph
RE: routing architectures ( was Re: ATT NYCrouting )
Figure out how to do reverse route reflecting. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Ralph Doncaster Sent: Thursday, August 29, 2002 3:46 PM To: Robert A. Hayden Cc: Peter van Dijk; [EMAIL PROTECTED] Subject: routing architectures ( was Re: ATT NYCrouting ) On Thu, 29 Aug 2002, Robert A. Hayden wrote: Um. Set up more than one reflector So how many is enough? I would think 3 is a minimum to come close to the reliability/redundancy of OSPF. -Ralph
RE: routing architectures ( was Re: ATT NYCrouting )
Uhh, come to think of it, the term reverse route reflecting probably won't get you much help -- client to client route reflecting is probably an easier term to understand.. My bad. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Ralph Doncaster Sent: Thursday, August 29, 2002 3:46 PM To: Robert A. Hayden Cc: Peter van Dijk; [EMAIL PROTECTED] Subject: routing architectures ( was Re: ATT NYCrouting ) On Thu, 29 Aug 2002, Robert A. Hayden wrote: Um. Set up more than one reflector So how many is enough? I would think 3 is a minimum to come close to the reliability/redundancy of OSPF. -Ralph
RE: ATT NYC
I personally prefer using IS-IS for loopback/infrastructure routes, and I use confederations for my IBGP. If a confederation ever gets to large, I can always add a route-reflector inside the confederation. Ralph, you have never failed to amaze me with your love for WCP (Worst Current Practices.) Derek -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Robert A. Hayden Sent: Thursday, August 29, 2002 3:53 PM To: Michael Hallgren Cc: Ralph Doncaster; Peter van Dijk; [EMAIL PROTECTED] Subject: RE: ATT NYC Yup. I like using OSPF to set up the mesh to the loopbacks and then ibgp as the IGP. On Thu, 29 Aug 2002, Michael Hallgren wrote: Um. Set up more than one reflector yes... and align your setup with your physical topology(so making it useful); use other proto for mapping your infra, etc, etc,.. mh On Thu, 29 Aug 2002, Ralph Doncaster wrote: On Thu, 29 Aug 2002, Peter van Dijk wrote: On Thu, Aug 29, 2002 at 01:09:54PM -0400, [EMAIL PROTECTED] wrote: Has anybody mentioned the benefits of ISIS as an IGP to them. Link-state protocols are evil, and when they break, they *really* break. I still do not see a compeling argument for not using BGP as your IGP. Slow convergence. As well there is the issues of running a full iBGP mesh. I've actually been doing it, and now that I'm about o add my 5th router, OSPF is looking a lot better than configuring 4 more BGP sessions. I've heard some people recommend a route-reflector, but that would mean if the route-reflector goes down you're screwed. -Ralph
Re: Broadening the IPv6 discussion
Yes, it's an gradual trend. We are seeing and increase over time in active tunnels and in average traffic per tunnel. Two easy things to drive v6 traffic: 1) switch your NNTP feeds to ipv6 2) put names which resolve to ipv6 addresses in your MX´s Both of these have little or no operational hazard. (SMTP fails over to v4 gracefully) Pete
building a better route reflector
Running two routing protocols is too much of a hassle. I think I would rather use static routes, and synchronize routers using rsync, diff, and patch. Our NOC has several 286s running Xenix that could act as servers for this. This would eliminate the hassle of running OSPF, ISIS, or RIP. Does anyone know of a Tier-1 for under $30/Mbps that would run something like this instead of BGP? I'd love it if we didn't need any routing protocols. -Dalph Get your free encrypted email at https://www.hushmail.com
Re: Broadening the IPv6 discussion
Two easy things to drive v6 traffic: 1) switch your NNTP feeds to ipv6 2) put names which resolve to ipv6 addresses in your MX´s Both of these have little or no operational hazard. (SMTP fails over to v4 gracefully) Driver #1 : Sell p00rn via IPv6 only. Sad but true. Content and use is all there is. - kurtis -
RE: Broadening the IPv6 discussion
On Thu, 29 Aug 2002, Daniel Golding wrote: Hmm. I'm afraid that I have to disagree with just about everything you've said :) . I haven't seen any enterprise folks demanding v6 - If VOIP and PDA's (?) use up their IP addresses, they can easily ask for more. The more you use, the more you get. There is no shortage of v4 space. As far as I know, we're still scheduled to run out of IPv4 address space this decade. But it's anybody's guess if this is really going to happen (even if you define running out as too hard to manage rather than nothing left). Address usage will follow an S curve: slow start, then steeper and steeper, until you come close to everyone that wants one has one and then it levels off again. The question is: where on the S are we now? There is something to be said for high (close to leveling off) because pretty much anyone who wants/needs IP in North America and Europe has it, but maybe we're still quite low, since lots of stuff that could benefit from IP connectivity is still standalone. (And then there's the rest of the world, of course.) Basically, major backbone networks will deploy v6 when it makes economic sense for them to do so. Right now, there is no demand and no revenue upside. I don't expect this to change in the near future. The question is not if they're going to carry v6, because they already are. The question is: will they do native v6, or tunnel it over v4? Since next to none of the high end stuff can do native v6 at wire speed, it's obviously still the latter now, but this is something that can change relatively easy. There are already many signs of impending v6 adoption: exchanges such as the AMS-IX are starting to do native v6, OSes have it built in, router vendors are implementing it deeper inside the hardware rather than at the main CPU level. However, noone is in a big hurry. That's probably a good thing. When we really need it, IPv6 will be good and ready. v6 is, currently, a solution in search of a problem. v4 space is being consumed slowly, but we are quite some time from a crisis. Of course, even when we consume all such ipv4 space, there are still expedients that can be used, including making v4 assets tradable and fungible. The problem is not so much address space (you can run a fortune 500 company behind a single address with NAT) but routing. This is still a big problem in IPv6 (as we're hoping to avoid the mess that is IPv4), but I think we're getting closer to a solution. Iljitsch van Beijnum
Re: building a better route reflector
I hope that in five years I'll be running a Tier 1 and can look back at my posts and laugh at them. However I hope that nobody else is laughing at me in the mean time. -Dalph Wiggum Roncaster Get your free encrypted email at https://www.hushmail.com
RE: ATT NYC
On Thu, 29 Aug 2002, Derek Samford wrote: I personally prefer using IS-IS for loopback/infrastructure routes, and I use confederations for my IBGP. If a confederation ever gets to large, I can always add a route-reflector inside the confederation. Ralph, you have never failed to amaze me with your love for WCP (Worst Current Practices.) OK, then hand me a clue and explain why ruing an iBGP mesh with 3-4 routers is so bad (seeing as Bassam Halabi didn't in his book). -Ralph
RE: ATT NYC
I wish this was a joke, but I know it's not. Ralph, they are talking about running BGP as an IGP, not if they are going to run BGP at all. Most large carriers run BGP everywhere. They also run an IGP for next-hop reachability within their networks (loopbacks, interface /30s, etc). The issue was whether you can get away with not running the IGP, and just running BGP. The problem is, of course, BGP handles many routes well, and converges relatively slowly. IGPs converge quickly, but only handle a relatively small number of routes. If you are offering transit to folks, you need to run BGP pretty much everywhere. If you are peering, or have multiple transits in multiple locations, with a network between them, BGP makes a lot of sense. If not, just run BGP on your edge routers. As far as an IGP - you need one. You don't need route reflectors for 5 routers. You probably do need something at double that number. Use two route reflectors, so if one goes down, you're ok. Redundancy is wonderful. Or use confederation BGP, which doesn't usually have single points of failure, but many be a bit too complex for some networks. Finally, if cutting and pasting a configuration is making you a sad clown, learn Expect or Perl, and write a script. That way, more routers can be broken in a shorter period of time, leading to greater efficiency. We now return to our regularly scheduled, low level of signal to noise. - Daniel Golding Ralph Doncaster Said On Thu, 29 Aug 2002, Peter van Dijk wrote: On Thu, Aug 29, 2002 at 01:09:54PM -0400, [EMAIL PROTECTED] wrote: Has anybody mentioned the benefits of ISIS as an IGP to them. Link-state protocols are evil, and when they break, they *really* break. I still do not see a compeling argument for not using BGP as your IGP. Slow convergence. As well there is the issues of running a full iBGP mesh. I've actually been doing it, and now that I'm about to add my 5th router, OSPF is looking a lot better than configuring 4 more BGP sessions. I've heard some people recommend a route-reflector, but that would mean if the route-reflector goes down you're screwed. -Ralph
RE: ATT NYC
Ralph, Okay, no one ever said an IBGP mesh was bad. We were all upset by the mention of an IGP distributed into an EGP. Let's do a little math here. The formula for IBGP sessions goes as follows. n*(n-1)/2 2=1 3=3 4=6 5=10 So you've only got 4 routers? That's fine, 6 sessions is not too hard to maintain. However, one more router, annd10 can get to be cumbersome and 10 Routers in your network, you have to maintain 45 BGP sessions. My personal favorite approach (And this may, or may not, start a religious war.) is confederations. The great part is, if your IBGP mesh inside a Sub-as gets to large, you can add a route-reflector, and have a hybrid RR/Confederation approach. This is very scalable, although there are some issues with being able to follow shortest path out of a confederation, so you need to have a little skill at traffic engineering. Building networks is easy Ralph, building SCALEABLE networks, is not. Derek -Original Message- From: Ralph Doncaster [mailto:[EMAIL PROTECTED]] Sent: Thursday, August 29, 2002 4:44 PM To: Derek Samford Cc: 'Robert A. Hayden'; 'Michael Hallgren'; 'Peter van Dijk'; [EMAIL PROTECTED] Subject: RE: ATT NYC On Thu, 29 Aug 2002, Derek Samford wrote: I personally prefer using IS-IS for loopback/infrastructure routes, and I use confederations for my IBGP. If a confederation ever gets to large, I can always add a route-reflector inside the confederation. Ralph, you have never failed to amaze me with your love for WCP (Worst Current Practices.) OK, then hand me a clue and explain why ruing an iBGP mesh with 3-4 routers is so bad (seeing as Bassam Halabi didn't in his book). -Ralph
Re: ATT NYC
Ralph == Ralph Doncaster [EMAIL PROTECTED] writes: Ralph I think we're both confused now. Your example seems to Ralph have nothing to do with what I'm talking about. I'm Ralph currently using an iBGP mesh in my network, with no OSPF or Ralph IS-IS. In other words I have internal routers not Ralph connected to external peers that are running iBGP. Ralph Specifically I have 2 routers that are ruinning EBGP and Ralph iBGP, and 2 routers that are running iBGP only. Now that Ralph I'm adding a 5th router to my network, I'm considering Ralph running OSPF for my IGP. I would still run iBGP between my Ralph 2 peering routers, as well as EBGP to my peers. Ralph, there is nothing wrong with doing that. Just make sure that you don't have any routers without full tables in your transit path -- i.e. between your two peering routers -- and it will be fine as long as you don't do anything wacky like redistributing BGP routes into OSPF. Be careful with redistributing in the other direction also. There's no problem. It won't ruin anything. It is a pretty standard setup. Cheers, -w
Re: Broadening the IPv6 discussion
Driver #1 : Sell p00rn via IPv6 only. Sad but true. Content and use is all there is. Remember that multicast never happened either. How much it would take to sponsor free content over multicast to get it deployed. Don´t know if this would be approvable for government subsidies though. Pete
RE: ATT NYC
Dmitri, Absolutely unavoidable. I think it's called Dalph Roncaster's Law of Impropability. Derek -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Dmitri Krioukov Sent: Thursday, August 29, 2002 5:10 PM To: Daniel Golding Cc: [EMAIL PROTECTED] Subject: RE: ATT NYC daniel, why would you return to that state? -- dima. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Daniel Golding Sent: Thursday, August 29, 2002 3:27 PM To: Ralph Doncaster; Peter van Dijk Cc: [EMAIL PROTECTED] Subject: RE: ATT NYC We now return to our regularly scheduled, low level of signal to noise. - Daniel Golding
Re: ATT NYC
On Thu, 29 Aug 2002, Peter van Dijk wrote: On Thu, Aug 29, 2002 at 01:09:54PM -0400, [EMAIL PROTECTED] wrote: Has anybody mentioned the benefits of ISIS as an IGP to them. Link-state protocols are evil, and when they break, they *really* break. I still do not see a compeling argument for not using BGP as your IGP. Slow convergence. As well there is the issues of running a full iBGP mesh. I've actually been doing it, and now that I'm about to add my 5th router, OSPF is looking a lot better than configuring 4 more BGP sessions. I've heard some people recommend a route-reflector, but that would mean if the route-reflector goes down you're screwed. Confederations are your friends. route-map set-igp-community is your friend. Alex -Ralph --
Re: Broadening the IPv6 discussion
From: Petri Helenius [EMAIL PROTECTED] Date: Fri, 30 Aug 2002 00:32:38 +0300 Sender: [EMAIL PROTECTED] Remember that multicast never happened either. How much it would take to sponsor free content over multicast to get it deployed. Don´t know if this would be approvable for government subsidies though. But multicast HAS happened, but mostly in the enterprise. Interdomain multicast is still unusual outside the RE community. RE nets like Abilene, vBNS, and ESnet make heavy use of interdomain multicast, especially for the Access Grid (http://www.accessgrid.org). While the Access Grid tends to be mostly RE, there are a number of commercial providers supporting it and interdomain multicast. I do not believe that the Access Grid has yet been used for pr0n, but is is largely government subsidized. R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634
Re: ATT NYC
Every time you see one of us mention ISIS or OSPF, all it has to do with is carrying loopback/infrastructure routes. I don't think anyone has said to Ralph why the above is done. Just in case it isn't obvious: you need to make sure the next-hops are known on each router by a means other than bgp. -mark
Re: Paul's Mailfrom (Was: IETF SMTP Working GroupProposal at smtpng.org)
At 8:20 PM -0700 2002/08/28, David Schwartz wrote: There are a few thousand people and more computers than you can shake a stick at located at Fort Meade for just this purpose. I'm not worried about Fort Meade for something like this. Moreover, this is not widely available. -- Brad Knowles, [EMAIL PROTECTED] They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++): a C++(+++)$ UMBSHI$ P+++ L+ !E W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++ h--- r---(+++)* z(+++)
RE: Paul's Mailfrom (Was: IETF SMTP Working GroupProposal at
At 11:54 AM +0200 2002/08/29, Jeroen Massar wrote: But as long as you live that's better than letting them have their ways now is it. It's still the death of a thousand cuts. Yes, it buys us time, but we have to use that time wisely to get real socio-legal solutions. And we have to get people to agree that the only thing it really does is buy us time, so that we can get real socio-legal solutions faster -- hopefully, in time to save the patient. Now stop the anal-ogies and come up with something that will _stop_ the crackdealing. I could say the same to you. b) A few weeks ago I counted over 200 open relays simultaneously spewing the same spam at us. Thats where RBL's are for, they close them up, if you had used an RBL your box would simply deny those relays at all, block them IP based and bingo no spewing from them. That's assuming that all those open relays were on one of the blacklists. Even then, they'd still hammer his machines with connections. Because sooner or later you can't see out the grated windows any more or get some air through them, and you're afraid to go outside... Never been in the city (those places where more than 100k people live) now have you ? Yeah, I have. Those people still leave their apartments on occasion. -- Brad Knowles, [EMAIL PROTECTED] They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++): a C++(+++)$ UMBSHI$ P+++ L+ !E W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++ h--- r---(+++)* z(+++)
