Re: More long AS-sets announced
Hank wrote: Wrong again. You used both AS1221 and AS2121: I logged pretty much the same thing with max-as limit blocking/logging the announcements (of course, the paths, and time stamp seconds are different, YMMV) Perhaps the unforeseen technical difficulties have something to do with not sticking to the original plan? Announce something different to get around filters, and thus, detect who put filters in place? Or more innocent. maybe fat fingers, or copy/paste gone horribly wrong? Doesn't really matter what happened though, because a controlled announce is a lot better than a malicious one. Since a stupid person is the most dangerous type of person (fifth basic law of human stupidity), a malicious announcement is even safer than a clueless one. I'd much rather see this done by someone with clue that's going to announce and withdraw them, then check for damage, than by someone that might not know what the heck they're doing. If there is damage, we'll all hear about it, and figure out how to stop it in the future when someone else tries to be malicious. Or when someone else is just plain clueless. Apparently that's not the case since this whole experiment was so disruptive that it took 16 hours for someone to notice and point out on NANOG that it neither did nor did not go off as previously announced. (I'm guilty of looking it over in the logs, and not even noticing the difference between 2121 and 1221) The internet is our playground... can't we just all get along? If someone's going to load 50 kids on a merry-go-round, and get 50 more kids to push it I'll just stand over by the monkey bars and try to avoid the flying vomit. :-) -Jerry
Re: [NON-OPERATIONAL] Re: NANOG Evolution
It shouldn't be complicated. I think members are looking for Operator experience. I don't think it's too hard to make that easily discernable as long as it's fair. Members aren't looking for Operator experience (sic). Members are looking for talks that do not suck. i think you mean to s/members/meeting attendees/ which is a small subset of those with a stake in nanog. randy
Re: [NON-OPERATIONAL] Re: NANOG Evolution
At 10:18 PM -0700 2005-06-20, Tony Li wrote: It is true that the PC will not get enough of these if it continues to rely on contributions. Which of us *wants* to present? Public speaking is the number one common fear, bar none. Speaking only for myself, I'm not afraid of public speaking. It does have to be a topic I feel comfortable with, which usually means either re-using a talk that I have previously done before (albeit updated), or updating a topic that I've talked on before. The former is easier for me, as I can take an existing presentation and re-work it (more or less). The latter is more difficult but probably more interesting for many in the audience who may have seen the presentation before. All you gotta do is help me get there, help me with the cost of staying there, and fit into my schedule. I don't require any speakers fees, and for small conferences I'd be willing to help more with the expenses, but larger conferences would need to provide more of the funding themselves. However, I will consider all offers. My registration at the SAGE Speakers Bureau (see http://www.sage.org/speakers/speakerhtml/15.mm) is a little old, but mostly still correct. p.s. No, I'm not a candidate. If elected, I will not serve. ;-) I'm not a candidate either, and will not serve if anyone was stupid enough to try to elect me. But I'd be happy to speak, if someone was interested in hearing me. -- Brad Knowles, [EMAIL PROTECTED] Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See http://www.sage.org/ for more info.
RE: [NON-OPERATIONAL] Re: NANOG Evolution
On Mon, 20 Jun 2005, Hannigan, Martin wrote: Ultimately, the SC is elected to represent the membership and carry out it's will and that should be uniformly actionable across the board in order for the SC to be taken seriously by the group and by Merit. I'm not sure what you mean here. It means that it doesn't make a lot of sense to handcuff the SC out of the gate on a supposition that they will do 'something bad' to the PC. Anyhow, it's a window dressing handcuffing. Looks like anyone can be removed with a 5 to 7 vote of the SC. You've all read the revised Charter, top to bottom? Kind of makes 6.2.1 ceremonial. It should be removed based on that alone. As the charter is currently written, every future steering committee will be stuck with a specific half of the program committee, left over from the previous year. The first steering committee gets to decide which of the current program committee members are in the half that they're stuck with, so they're much more powerful when it comes to program committee selection than any future steering committee will be. In the draft that several of us worked on, the first steering committee had even more power than that, as they could have fired the entire program committee and started over. Merit changed that, and gave lots of time for people to object, but nobody did. As a result, we've got a system where all program committee members will have been chosen by the steering committee immediately, but half of them will have been chosen from a limited pool. A year later, we'll have a program committee that has been entirely chosen by the first two elected steering committees. In the original draft, we staggered the steering committee terms because we wanted continuity. In Merit's version, that continuity was extended to the first year. As Marty points out, a super-majority of the steering committee could remove more program committee members. The super-majority requirement was put in to make it hard to do -- something that should happen when there's consensus that somebody isn't working out. I don't think it would be appropriate or necessary for the steering committee to use that power to override the intent of the charter, nor do I think it would be a good idea for the steering committee to get rid of even half of the program committee at once. If Marty is feeling constrained by that section of the charter (I'm not sure if he is, or if he's just making noise), then we've found at least one difference between two of the candidates. ;) -Steve
Re: NANOG Evolution
Randy Bush wrote: # The candidates for the Steering Committee are: # Joe Abley # Randy Bush # Christopher Chin # Ron da Silva # Vince Fuller # Steve Gibbard # Dan Golding # Martin Hannigan # Dorian Kim # Mark Kosters # Jared Mauch # Chris Morrow # William B. Norton # Philip Smith # Josh Snowhorn # Dave Wodelet # Lixia Zhang # # could you annotate which of these candidates actually work # at an isp or large content provider? # # randy Better yet, what about links to resumes/backgrounds? /herb
Re: More long AS-sets announced
On Tue, Jun 21, 2005 at 08:13:08AM +0300, Hank Nussbacher wrote:
due to unforeseen technical difficulties, we have been forced to
postpone these experiments. We plan to make the announcements at the
same times on Monday 20 June.
The prefixes will be the same (84.205.73.0/24 and 84.205.89.0/24) and
will be originated by AS12654 as before, but the AS-set will consist of
AS2121 repeated n times, so the paths will look like 12654 {2121, 2121,
.., 2121}. AS2121 is the RIPE meeting AS, which is reserved for RIPE
meetings and does not currently appear in the global routing table.
Wrong again. You used both AS1221 and AS2121:
Yups, smells like a small but very dangerous typo.
From a netcitizen's perpesctive and as being involved in operating a part
of the internet, I'm starting to dislike this whole experiment more and
more. I understand, as people already commented, the internet in fact is
one big experiment, but this is getting out-of-hand.
Can the people responsible for this please reconsider and put things on
hold until certain conditions are met:
Publish a detailed workplan including AS-es used, windows and risk
analysis to the various mailinglists.
A reasonable time between annoucements and the experiment instead of 24
hours.
Some assurance that input files are checked for typos.
Take another look wether it is smart to use 'production' AS-es for it,
such as the RIS or meeting AS numbers, instead of a seperate set. I think
people are going to get real unhappy if somewhere in October they found
out the meeting network is blocked at various places.
Just my 2 cents,
MarcoH
Re: More long AS-sets announced
Can the people responsible for this please reconsider and put things on hold until certain conditions are met: Publish a detailed workplan including AS-es used, windows and risk analysis to the various mailinglists. given they are using their own prefixes, can you please tell us what risk there might be. Some assurance that input files are checked for typos. hopefully better than the mean of operators doing so :-)/2 randy
MCI routing loop near Chicago
MCI administrator(s): Whilst attempting to contact host '64.195.130.100' (NS1.USR.COM). From Net-Nation (TIER-1 peering with BIG PIPE, LEVEL 3, MCI, VAIX): 3 r1.netnation.com (64.40.105.1) 0.580 ms 0.716 ms 0.618 ms 4 122.ATM2-0.GW1.VAN1.ALTER.NET (209.167.46.101) 0.727 ms 0.898 ms 1.122 ms 5 0.so-1-0-0.XL2.VAN1.ALTER.NET (152.63.137.134) 1.518 ms 1.171 ms 1.150 ms 6 0.so-6-0-0.XL2.CHI6.ALTER.NET (152.63.65.126) 47.873 ms 48.239 ms 47.895 ms 7 POS7-0.GW6.CHI6.ALTER.NET (152.63.68.189) 47.759 ms 47.986 ms 47.879 ms 8 mci28259-gw.customer.alter.net (63.84.148.170) 50.134 ms 50.505 ms 49.439 ms 9 Serial4-8.GW6.CHI6.ALTER.NET (63.84.148.169) 49.412 ms 49.208 ms 49.800 ms 10 mci28259-gw.customer.alter.net (63.84.148.170) 51.736 ms 50.326 ms 50.194 ms 11 Serial4-8.GW6.CHI6.ALTER.NET (63.84.148.169) 50.191 ms 49.972 ms 50.192 ms 12 mci28259-gw.customer.alter.net (63.84.148.170) 51.314 ms 51.605 ms 52.499 ms 13 Serial4-8.GW6.CHI6.ALTER.NET (63.84.148.169) 54.37 ms 53.607 ms 54.81 ms For what its worth if someone from US Robotics is listening, neither of your two listed nameservers are reachable from Western Canada as tested from Net-Nation, the Shaw and Telus residential networks, and the Telus business network. Cheers, James -- James Couzens, Programmer http://libspf.org - ANSI C Sender Policy Framework library http://ses.codeshare.ca - Signed Envelope Sender, A comprehensive and simple solution to stopping SMTP forgery. Please review our work and find any flaws in our protocol. signature.asc Description: This is a digitally signed message part
Re: NANOG Evolution
Perhaps using the ARIN model for this would be a good idea. IIRC, after someone in nominated, they are asked to fill out a small questionnaire. Things like Organization, Org URL, Why do you want to serve on the AC?, Describe how your professional goals and experience are relevant, Describe your technical (especially IP) and professional qualifications for filling an AC seat, etc. Also, an important question is: Please provide detailed biographical information to include all experience, activities, associations, and affiliations (national and international) relevant to serving on the AC. Describe positions held, and your specific duties, achievements, and levels of responsibility. Include the names of organizations served and dates of service. Realising the above is specific to the AC, I believe with simple modifications, these questions would serve the NANOG community well in letting us feel comfortable with the nominees. On Tue, 21 Jun 2005, Herb Leong wrote: Randy Bush wrote: # The candidates for the Steering Committee are: # Joe Abley # Randy Bush # Christopher Chin # Ron da Silva # Vince Fuller # Steve Gibbard # Dan Golding # Martin Hannigan # Dorian Kim # Mark Kosters # Jared Mauch # Chris Morrow # William B. Norton # Philip Smith # Josh Snowhorn # Dave Wodelet # Lixia Zhang # # could you annotate which of these candidates actually work # at an isp or large content provider? # # randy Better yet, what about links to resumes/backgrounds? /herb -- Alex Rubenstein, AR97, K2AHR, [EMAIL PROTECTED], latency, Al Reuben Net Access Corporation, 800-NET-ME-36, http://www.nac.net
Re: MCI routing loop near Chicago
On Tue, 21 June 2005 04:52:44 -0700, James Couzens wrote: MCI administrator(s): Ehm... seriously, you as a customer should know the NOC email address of them, right? At least that traceroute indicates you are one, or the host from where it starts. From Net-Nation (TIER-1 peering with BIG PIPE, LEVEL 3, MCI, VAIX): And that is crap, sorry to say. Please, post to NANOG if you have to and if there is no way out. And kindly explain what you did before and what did not work when you post such stuff. Alexander
Re: MCI routing loop near Chicago
On Tue, 2005-06-21 at 04:52 -0700, James Couzens wrote: MCI routing loop near Chicago As Alexander Koch pointed out I could have been more detailed in my post with respect to methods attempted to notify the relevant parties prior to posting to the NANOG list. With that in mind, after roughly two hours of attempting to notify MCI through the available channels receiving only two responses, both from MCI (US Robotics can not respond, their poor DNS setup has left me with no means to contact them via e-mail (NS2.RACKSPACE.COM doesn't appear to know about USR and their primary is unreachable to me and additionally through several on-line DNS lookup engines I tried)) I felt that I would post to NANOG as a last resort. For what its worth the auto-generated ticket number I received from MCI's [EMAIL PROTECTED] address was: 2005062102342. The other response I received was an Out of Office Autoreply from [EMAIL PROTECTED] Hope that helps, Cheers, James -- James Couzens, Programmer http://libspf.org - ANSI C Sender Policy Framework library http://ses.codeshare.ca - Signed Envelope Sender, A comprehensive and simple solution to stopping SMTP forgery. Please review our work and find any flaws in our protocol. - PGP: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x7A7C7DCF This is not quite as crazy as it sounds, since people knew how to write small, efficient programs in those days, a skill that has subsequently been lost. -- Andrew S. Tanenbaum signature.asc Description: This is a digitally signed message part
Re: NANOG Evolution
On Tue, Jun 21, 2005 at 07:40:43AM -0400, Alex Rubenstein wrote: Perhaps using the ARIN model for this would be a good idea. IIRC, after someone in nominated, they are asked to fill out a small questionnaire. Things like Organization, Org URL, Why do you want to serve on the AC?, Describe how your professional goals and experience are relevant, Describe your technical (especially IP) and professional qualifications for filling an AC seat, etc. Also, an important question is: Please provide detailed biographical information to include all experience, activities, associations, and affiliations (national and international) relevant to serving on the AC. Describe positions held, and your specific duties, achievements, and levels of responsibility. Include the names of organizations served and dates of service. Realising the above is specific to the AC, I believe with simple modifications, these questions would serve the NANOG community well in letting us feel comfortable with the nominees. While it's not quite as specific as above, don't the candidate bios http://www.nanog.org/candidates05.html serve much the same purpose? Quick glance at the bios seem to fairly cogently list candidates' current employment and responsibilities as well as relevant activities. So, are we missing something? Should we be adding candidate position statements and such? -dorian
Re: NANOG Evolution
While it's not quite as specific as above, don't the candidate bios http://www.nanog.org/candidates05.html serve much the same purpose? there are at least two folk on the list who are pretty much purely marketing. hard to tell from that page. randy
Re: [NON-OPERATIONAL] Re: NANOG Evolution
There's a mailing list for this. Betty announced it last week, I can't remember off the top of my head. I think it was pre-populated with the list of eligible voters. (I hope there's a way to get off, for those who may not want to receive campaign ads. It's [EMAIL PROTECTED] Everyone who was subscribed to nanog-futures has been added, and we'll soon (today) add all the eligible voters listed at www.nanog.org/voters05.html. To cover all bases, there's subscription info here: www.nanog.org/email.html It would be *great* if we could move this discussion over there.
Re: More long AS-sets announced
On Tue, Jun 21, 2005 at 10:27:18AM +0100, Randy Bush wrote: Can the people responsible for this please reconsider and put things on hold until certain conditions are met: Publish a detailed workplan including AS-es used, windows and risk analysis to the various mailinglists. given they are using their own prefixes, can you please tell us what risk there might be. Not much, but I guess people in the audience might get happy from the small note that labtests showed IOS won't crash when it encounters these annoucements. MarcoH
Re: [NON-OPERATIONAL] Re: NANOG Evolution
The PC has 16 seats. Finding eight qualified people will be doable. Finding 16 qualified people, capable of hitting the ground running, with a conference 4 months in their future to plan, would be untenable. It takes a non-trivial amount of time to recruit and organize that many folks. I'm not crazy about this being written into the bylaws, but in practice, its the most efficient approach and probably the one that would have been taken in any case. The other issue is, when looking at the current composition of the PC, there are at least 8 qualified, dedicated people. The idea of moving the PC to a be more representative of the operational and infrastructure community is a good one. The PC has, in the past, been too heavily weighted towards vendors and ex-Merit folks. Appointing 8 new folks will move the PC in the direction that the community wants to take. I don't think we should be worried about the power of the SC. Instead, we should be concerned about being able to effect the necessary changes that the community wants - a more representative PC, better talks on a wider and more interesting range of topics, etc. Part of this will involve changed to the mission of the PC... - an expectation that each PC member will actively recruit/present/moderate at least one quality session per conference. - expanding the scope of presentations to include new (to us) topics such as those related to providing VoIP services, hosting, access networks (DSL/Broadband/Wireless), network security, MPLS VPN scalability and interconnection issues, etc. I'd rather have a great talk on WiMax (IEEE 802.16-2000) than a bad talk on BGP any day. - Finding ways to inject the material we've seen in recent BOFs into the plenary or tracking sessions. The BOF material has been the most innovative stuff due to a relative lack of oversight combined with a freer format. - Maintaining and expanding the educational aspects of NANOG's mission through tutorials and other sessions. PC folks who are ok with this, old or new, will be able to contribute to and lead this effort. (BTW, for those responding or posting to this thread or others which are similar, please include a non-op tag in the subject line so that folks who don't want to read about political machinations can procmail us efficiently) - Daniel Golding On 6/21/05 3:03 AM, Steve Gibbard [EMAIL PROTECTED] wrote: On Mon, 20 Jun 2005, Hannigan, Martin wrote: Ultimately, the SC is elected to represent the membership and carry out it's will and that should be uniformly actionable across the board in order for the SC to be taken seriously by the group and by Merit. I'm not sure what you mean here. It means that it doesn't make a lot of sense to handcuff the SC out of the gate on a supposition that they will do 'something bad' to the PC. Anyhow, it's a window dressing handcuffing. Looks like anyone can be removed with a 5 to 7 vote of the SC. You've all read the revised Charter, top to bottom? Kind of makes 6.2.1 ceremonial. It should be removed based on that alone. As the charter is currently written, every future steering committee will be stuck with a specific half of the program committee, left over from the previous year. The first steering committee gets to decide which of the current program committee members are in the half that they're stuck with, so they're much more powerful when it comes to program committee selection than any future steering committee will be. [snip] -Steve
Re: More long AS-sets announced
Can the people responsible for this please reconsider and put things on hold until certain conditions are met: Publish a detailed workplan including AS-es used, windows and risk analysis to the various mailinglists. given they are using their own prefixes, can you please tell us what risk there might be. Not much, but I guess people in the audience might get happy from the small note that labtests showed IOS won't crash when it encounters these annoucements. showing that ios won't crash is very difficult because the number of versions of ios, and the amazing dependencies of things on which blade is in which slot and what phase is the moon. but reading the roma gang's papers and the main email note leads me to feel they have done as good a job on this as we can reasonably expect. considering that we have fellow isps dumping horrifying garbage in the rib, it's amusing how we attack a seemingly well-run very small experiment. randy
Re: Email peering
On Fri, Jun 17, 2005 at 11:48:58AM -0400, Ben Hubbard wrote: You seem to repeatedly describe a solution that becomes so big that it (at least substantially) replaces 25/SMTP. That's what I don't think will work, or is needed. Please let me borrow Ben's point and expand on it. Spam as it's usually discussed (spam propagated via SMTP) is only part of the spam problem. We've seen Usenet spam, chat room spam, http referrer log spam, blog spam, and so on. And all of those bundled together and labeled as spam are only part of the overall network abuse problem -- which also involves phishing, zombies, DoS attacks, spyware, etc. And these are all (increasingly) interelated problems, e.g. spam is used to phish people to sites which forcibly download spyware, and so on. We could (and some already have) spend an enormous amount of time devising very clever solutions to these and deploying them. But as we've seen, doing so usually results only in a shift in the nature of the abuse, not an overall reduction in it. So even if we had The Perfect Solution to SMTP spam and it was globally deployed tomorrow and had no adverse side-effects...we'd buy ourselves a brief respite, no better. I'm not saying some of the technical approaches aren't clever. They are. But none of them are going to solve the problem for any acceptable value of solve, not because there's anything wrong with them per se, but because they're technological attempts to solve the problem at its end points -- rather than its source points. The best place to stop abuse is as near its source as possible. Meaning: it's far easier for network X to stop abuse from leaving its network than it is for 100,000 other networks to defend themselves from it. Especially since techniques for doing so (for instance, controlling outbound SMTP spam) are well-known, heavily documented, and easily put into service. The problem is that network X, for many values of X (see the data compiled by Spamhaus or SPEWS or any number of others) hasn't done so. Whether that failure is due to incompetence, greed, laziness, negligence or anything else is an interesting question...but really doesn't matter, because regardless of the cause, the fastest way to get it fixed is to make it X's problem...*not everyone else's*. (It's often impressive how fast X can move--despite protestations otherwise--when this situation is created.) Those who have been around a long long time know that this is how it used to be. If your network started spewing crap, and didn't stop spewing crap in a fairly timely manner, you got a phone call or email explaining that someone had their hand on your plug and was going to pull it. The point? The point is that there is no need for any new technology to deal with the spam/abuse probem. What there is a desperate need for is the *will* to use the technology we already have -- to shift the burden of dealing with abuse onto those who are permitting it to originate from their network. This can be done in a number of ways: using DNSBLs, firewalls, routers, whatever. Because if it's not done, then Network X, for many values of X, will be perfectly happy to watch everyone else innovate and scramble and spend money to defend themselves *as long as X doesn't have to*. As we've seen. For many years. Over and over and over again. After all, why should they? There's nothing in it for them and no downside if they don't. [...] if you give people the means to hurt you, and they do it, and you take no action except to continue giving them the means to hurt you, and they take no action except to keep hurting you, then one of the ways you can describe the situation is it isn't scaling well. --- Paul Vixie So either the collective we has the will to stop putting up with this nonsense -- or we don't. If it's the former, then we already have all the tools we need. If it's the latter, then nothing we come up with, no matter who clever it is, is going to make any real difference. ---Rsk
OSPF -vs- ISIS
All, Can anyone point me to information on what the top N service providers are using for their IGP? I'm trying to build a case for switching from OSPF to IS-IS. Those on this list who are currently running IS-IS, do you find better scalability and stability running IS-IS than OSPF? I understand that this question is a lot more complex than a simple yes or no since factors like design and routing policy will certainly affect the protocols behavior. Any insights or experiences that you can share would be most helpful. Thanks, Daniel Evans Alltel Communications
Re: OSPF -vs- ISIS
Can anyone point me to information on what the top N service providers are using for their IGP? Can we expand this to include enterprise networks as well? The University that I work for is planning to do a switch-over from OSPF to ISIS, but I'd like to know if we're really a one off. Eric :)
Re: OSPF -vs- ISIS
On Tue, 2005-06-21 at 09:04 -0500, Dan Evans wrote: Can anyone point me to information on what the top N service providers are using for their IGP? I'm trying to build a case for switching from OSPF to IS-IS. Why are you trying to build a case...? Would you already have operational benefit from switching and are you building a case round that and if not, why switch...? Switching IGP in a non-trivial network isn't something you'd want to do unless you've got a clear motive and it gives you some operational advantage... Cheers, -- --- Erik Haagsman Network Architect We Dare BV Tel: +31(0)10-7507008 Fax: +31(0)10-7507005 http://www.we-dare.nl
Re: OSPF -vs- ISIS
Dan Evans wrote: All, Can anyone point me to information on what the top N service providers are using for their IGP? I'm trying to build a case for switching from OSPF to IS-IS. Those on this list who are currently running IS-IS, do you find better scalability and stability running IS-IS than OSPF? I understand that this question is a lot more complex than a simple yes or no since factors like design and routing policy will certainly affect the protocols behavior. Any insights or experiences that you can share would be most helpful. Thanks, Daniel Evans Alltel Communications Daniel, in short, we've found ISIS to be slightly easier to maintain and run, with slightly more peace of mind in terms of securitiy than OSPF. Performance and stability wise, no major difference that was noticable. For more information, see the talk by Dave Katz at http://www.nanog.org/mtg-0006/katz.html Also, AOL's experience in switching from OSPF to ISIS is covered at http://www.nanog.org/mtg-0310/gill.html the PDF on that page is actually an older version. The full version I used at NANOG is available at http://www.vijaygill.com/oi.pdf /vijay
Re: MCI routing loop near Chicago
On Tue, 21 Jun 2005, James Couzens wrote: On Tue, 2005-06-21 at 04:52 -0700, James Couzens wrote: MCI routing loop near Chicago As Alexander Koch pointed out I could have been more detailed in my post with respect to methods attempted to notify the relevant parties prior to posting to the NANOG list. With that in mind, after roughly two hours of attempting to notify MCI through the available channels receiving only two responses, both from MCI (US Robotics can not respond, their poor DNS setup has left me with no means to contact them via e-mail (NS2.RACKSPACE.COM doesn't appear to know about USR and their primary is unreachable to me and additionally through several on-line DNS lookup engines I tried)) I felt that I would post to NANOG as a last resort. For what its worth the auto-generated ticket number I received from MCI's [EMAIL PROTECTED] address was: 2005062102342. The other response and help4u probably isn't going to fix this as it's clearly the customer's loop, not mci's... traffic looping from 11 Serial4-8.GW6.CHI6.ALTER.NET (63.84.148.169) 50.191 ms 49.972 ms 50.192 ms 12 mci28259-gw.customer.alter.net (63.84.148.170) 51.314 ms 51.605 ms 52.499 ms (gw == edge/aggregation device, 'customer.alter.net' == cpe) is a 'customer problem'. Help4u will likely have responded with a 'not our problem, but thanks' (or something polite and along those lines). Thanks though. -Chris
Re: OSPF -vs- ISIS
We're currently running OSPF. Believe me, I understand that switching IGP's is not a simple undertaking. There are several benefits that I'm looking at, some of which have already been mentioned in replies to my original thread. Security is one, the other being IPv6 support. I'm going to have to turn on another protocol in order to support IPv6. My two choices are OSFPv3 or IS-IS. The decision then becomes, do I have a single IGP protocol that maintains both IPv4 and IPv6 information, or do I run two seperate (although closely related) protocols. -Dan On 6/21/05, Dan Evans [EMAIL PROTECTED] wrote: All, Can anyone point me to information on what the top N service providers are using for their IGP? I'm trying to build a case for switching from OSPF to IS-IS. Those on this list who are currently running IS-IS, do you find better scalability and stability running IS-IS than OSPF? I understand that this question is a lot more complex than a simple yes or no since factors like design and routing policy will certainly affect the protocols behavior. Any insights or experiences that you can share would be most helpful. Thanks, Daniel Evans Alltel Communications
Re: OSPF -vs- ISIS
It is a dangerous thing when, in the course of engineering, you have a solution looking for a problem, instead of a problem looking for a solution. I'd say that the biggest benefit in using IS-IS over OSPF is the tuning of route metrics, but aside from that, I'd say that the two routing protocols are substantially similar enough to warrant close consideration of exactly what one would want bad enough to switch from one to the other. - ferg -- Erik Haagsman [EMAIL PROTECTED] wrote: On Tue, 2005-06-21 at 09:04 -0500, Dan Evans wrote: Can anyone point me to information on what the top N service providers are using for their IGP? I'm trying to build a case for switching from OSPF to IS-IS. Why are you trying to build a case...? Would you already have operational benefit from switching and are you building a case round that and if not, why switch...? Switching IGP in a non-trivial network isn't something you'd want to do unless you've got a clear motive and it gives you some operational advantage... -- Fergie, a.k.a. Paul Ferguson Engineering Architecture for the Internet [EMAIL PROTECTED] or [EMAIL PROTECTED] ferg's tech blog: http://fergdawg.blogspot.com/
RE: OSPF -vs- ISIS
The State of Illinois converted to ISIS in 2002 from EIGRP and it has definitely been a good thing for us. It's been operationally bullet proof, and simple to maintain. We typically get features faster than we would if we ran OSPF. For example, we have a desire in the future to use IPFRR. Every indication from the vendor is that this feature will be available to ISIS first, most likely because of either the extensibility of ISIS or more likely because ISIS is in so many larger providers. Mike Bernico -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of vijay gill Sent: Tuesday, June 21, 2005 9:20 AM To: Dan Evans Cc: nanog@merit.edu Subject: Re: OSPF -vs- ISIS Dan Evans wrote: All, Can anyone point me to information on what the top N service providers are using for their IGP? I'm trying to build a case for switching from OSPF to IS-IS. Those on this list who are currently running IS-IS, do you find better scalability and stability running IS-IS than OSPF? I understand that this question is a lot more complex than a simple yes or no since factors like design and routing policy will certainly affect the protocols behavior. Any insights or experiences that you can share would be most helpful. Thanks, Daniel Evans Alltel Communications Daniel, in short, we've found ISIS to be slightly easier to maintain and run, with slightly more peace of mind in terms of securitiy than OSPF. Performance and stability wise, no major difference that was noticable. For more information, see the talk by Dave Katz at http://www.nanog.org/mtg-0006/katz.html Also, AOL's experience in switching from OSPF to ISIS is covered at http://www.nanog.org/mtg-0310/gill.html the PDF on that page is actually an older version. The full version I used at NANOG is available at http://www.vijaygill.com/oi.pdf /vijay
Re: OSPF -vs- ISIS
Isn't that because Dave re-wrote all of the IS-IS code? ;-) - ferg -- vijay gill [EMAIL PROTECTED] wrote: Daniel, in short, we've found ISIS to be slightly easier to maintain and run, with slightly more peace of mind in terms of securitiy than OSPF. Performance and stability wise, no major difference that was noticable. For more information, see the talk by Dave Katz at http://www.nanog.org/mtg-0006/katz.html Also, AOL's experience in switching from OSPF to ISIS is covered at http://www.nanog.org/mtg-0310/gill.html the PDF on that page is actually an older version. The full version I used at NANOG is available at http://www.vijaygill.com/oi.pdf /vijay -- Fergie, a.k.a. Paul Ferguson Engineering Architecture for the Internet [EMAIL PROTECTED] or [EMAIL PROTECTED] ferg's tech blog: http://fergdawg.blogspot.com/
Re: More long AS-sets announced
Randy Bush wrote: showing that ios won't crash is very difficult because the number of versions of ios, and the amazing dependencies of things on which blade is in which slot and what phase is the moon. Thank you. You've provided a clean, concise counter to Lorenzo's original claim that long AS sets won't trip on IOS bugs. This may be a well-run, very small experiment, but it's experimenting with a space that's rarely explored and therefore less likely to have encountered the same level of operational testing that horrifying garbage leaks have tested. As such, I'm frustrated that the testers consider requests to provide more advance notice to be so obtuse. Many of us in the operational community are required to conduct testing in lab environments, followed by well-announced maintenance windows. Why is this operational test supposed to be given freer reign on the 'net than our own operations? Alternatively, why can't the test be conducted in a lab, with interested operators providing router configurations and xOS versions to give the test bed the most realistic sample of the 'net, without using the production 'net? pt
Re: More long AS-sets announced
On Tue, 21 Jun 2005, Pete Templin wrote: Randy Bush wrote: showing that ios won't crash is very difficult because the number of versions of ios, and the amazing dependencies of things on which blade is in which slot and what phase is the moon. Thank you. You've provided a clean, concise counter to Lorenzo's original claim that long AS sets won't trip on IOS bugs. .. Alternatively, why can't the test be conducted in a lab, with interested operators providing router configurations and xOS versions to give the test bed the most realistic sample of the 'net, without using the production 'net? Has anyone considered that the project may have indeed done testing of available IOS/$ROUTER versions in a lab environment before even considering testing on the 'live' internet? Reading the cited material might be of benefit to the vocal complainers. I think Lorenzo would be the first to admit that the timing of operator notifications, and more importantly the wording, may be less than desired, however this does not detract from the caution, and professionalism exhibited thus far in this set of experiments. This may be a well-run, very small experiment, but it's experimenting with a space that's rarely explored and therefore less likely to have encountered the same level of operational testing that horrifying garbage leaks have tested. Part of the problem is that because it is, as you put it, a rarely explored problem space, the number of interested parties with sufficient and varied resources is extremely small, resulting in a less-than-complete testing environment. Another part of the problem is that you cannot put the concept back in the box. The black-hats do read operational lists, and with all the fuss being made over possible breakage caused by AS-sets, some of them will do will perform their own, possibly destructive experiments in order to find out what specific $ROUTER versions do under various inputs. So, which would you prefer.. Lorenzo at a known contact number with known working hours (+31 20 535 , 10am to 5pm GMT +1), and with the Internet's best interests at heart, or some malcontent with unknown contacts, unknown hours, and very definitely not your best interests at heart ? --==-- Bruce. Unfortunately, option 3, do nothing to see whether it is actually a problem, is no longer valid.
Re: More long AS-sets announced
RB Date: Tue, 21 Jun 2005 14:40:47 +0100 RB From: Randy Bush [ trimming CC list ] RB considering that we have fellow isps dumping horrifying garbage in RB the rib, it's amusing how we attack a seemingly well-run very small RB experiment. Bears would rather attack fish than wolverines. Considering Lorenzo's attitude, I'm sure he's taking into account the requests for more heads up. If he tickles an IOS bug, I'd rather have it happen in this scenario than when a less-clued individual or a miscreant tries announcing wacky routes. Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita DO NOT send mail to the following addresses: [EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
Re: More long AS-sets announced
Thank you. You've provided a clean, concise counter to Lorenzo's original claim that long AS sets won't trip on IOS bugs. no problem. you're quite welcome. This may be a well-run, very small experiment, but it's experimenting with a space that's rarely explored and therefore less likely to have encountered the same level of operational testing that horrifying garbage leaks have tested. As such, I'm frustrated that the testers consider requests to provide more advance notice to be so obtuse. could you please give me the command to configure ios to not crash if given advance notice? Why is this operational test supposed to be given freer reign on the 'net than our own operations? Alternatively, why can't the test be conducted in a lab, with interested operators providing router configurations and xOS versions to give the test bed the most realistic sample of the 'net, without using the production 'net? the first announcement of this experiment was months ago. randy
Re: OSPF -vs- ISIS
Thus spake Mike Bernico [EMAIL PROTECTED] The State of Illinois converted to ISIS in 2002 from EIGRP and it has definitely been a good thing for us. It's been operationally bullet proof, and simple to maintain. We typically get features faster than we would if we ran OSPF. For example, we have a desire in the future to use IPFRR. Every indication from the vendor is that this feature will be available to ISIS first, most likely because of either the extensibility of ISIS or more likely because ISIS is in so many larger providers. This points to something that's really unrelated to the minor technical differences between the two protocols: how they're viewed by your vendor. One vendor in particular sees ISIS as an ISP protocol and OSPF as an enterprise protocol. Their implementation of the latter has often gotten many enterprise-oriented features (e.g. dial-on-demand link support) that the other didn't, whereas the former was known for reliability because the coders were admonished to touch it rarely and test the heck out of every change because screwing up might break the Internet. The difference in stability is less apparent today, but the mindset is still quite alive. That means ISIS gets ISP features faster, and the code still tends to be more solid than OSPF even though ISIS might now be getting changes more frequently than it did in the past. S Stephen Sprunk Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do. K5SSS --Isaac Asimov
Re: OSPF -vs- ISIS
On Tue, Jun 21, 2005 at 11:50:59AM -0500, Stephen Sprunk wrote: Thus spake Mike Bernico [EMAIL PROTECTED] The State of Illinois converted to ISIS in 2002 from EIGRP and it has definitely been a good thing for us. It's been operationally bullet proof, and simple to maintain. We typically get features faster than we would if we ran OSPF. For example, we have a desire in the future to use IPFRR. Every indication from the vendor is that this feature will be available to ISIS first, most likely because of either the extensibility of ISIS or more likely because ISIS is in so many larger providers. This points to something that's really unrelated to the minor technical differences between the two protocols: how they're viewed by your vendor. One vendor in particular sees ISIS as an ISP protocol and OSPF as an enterprise protocol. Their implementation of the latter has often gotten many enterprise-oriented features (e.g. dial-on-demand link support) that the other didn't, whereas the former was known for reliability because the coders were admonished to touch it rarely and test the heck out of every change because screwing up might break the Internet. To that end, you also need to be aware that outside of the major vendors, most don't even know what ISIS is. So if you're trying to integrate other vendors' equipment into your network, you may have no choice but OSPF. The difference in stability is less apparent today, but the mindset is still quite alive. That means ISIS gets ISP features faster, and the code still tends to be more solid than OSPF even though ISIS might now be getting changes more frequently than it did in the past. Personally, I still favor ISIS in provider style networks, especially as they grow larger but with the passage of time, there really isn't a great deal of difference between ISIS level 2 only and one great big area 0 these days. (Personal experience has suggested to me that ISIS tends to handle that somewhat better but that doesn't say you won't be just as happy with OSPF.) So the long and short of it really boils down to your personal preference. --- Wayne Bouchard [EMAIL PROTECTED] Network Dude http://www.typo.org/~web/
Re: OSPF -vs- ISIS
Wayne E. Bouchard [EMAIL PROTECTED] writes: One vendor in particular sees ISIS as an ISP protocol and OSPF as an enterprise protocol. Their implementation of the latter has often gotten many enterprise-oriented features (e.g. dial-on-demand link support) that the other didn't, whereas the former was known for reliability because the coders were admonished to touch it rarely and test the heck out of every change because screwing up might break the Internet. To that end, you also need to be aware that outside of the major vendors, most don't even know what ISIS is. So if you're trying to integrate other vendors' equipment into your network, you may have no choice but OSPF. The other edge of that sword is that letting someone outside of the major vendors' OSPF (1) talk to your cloud qualifies as risky behavior. ---rob (1) where major vendors means widely deployed, not widely deployed for money. the question is whether installing on your network is an unspoke part of their beta testing strategy.
Re: More long AS-sets announced
On Tue, 21 Jun 2005, Bruce Campbell wrote: Has anyone considered that the project may have indeed done testing of available IOS/$ROUTER versions in a lab environment before even considering testing on the 'live' internet? Reading the cited material might be of benefit to the vocal complainers. Not everyone runs IOS. Wasn't it something similar to this that crashed gated and possibly other BGP implementations a few years ago? Is this test intended to make sure everyone upgraded / nobody's deployed new gear with old affected code? And finally, we're doing it, we're not doing it, Surprise, we did it is a crappy way to notify the community that they're about to piss in the global pool. At least there was some level of notification, but why bother if you're not going to stick to what you publicize? -- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: Email peering
Rich Kulawiec wrote: The best place to stop abuse is as near its source as possible. Meaning: it's far easier for network X to stop abuse from leaving its network than it is for 100,000 other networks to defend themselves from it. Especially since techniques for doing so (for instance, controlling outbound SMTP spam) are well-known, heavily documented, and easily put into service. The problem with countermeasures that would actually hurt the source of junk heavily enough would also have to hurt legitimate traffic making you an immediate lawsuit magnet. If that would not be the case, or some larger parties feel they could stand despite this fact, the problem would be fairly straightforward to reduce to a fraction in a few months time. Pete
Re: More long AS-sets announced
Randy Bush wrote: could you please give me the command to configure ios to not crash if given advance notice? telnet your.mail.server 25 helo your.pc mail.from you mail.to you data Be sure to sit near a terminal with OOB access to your network at XYZ while an experiment is conducted with the Internet. Have vendor support contracts handy, and find a PC with a dialup connection in case IOS crashes. .
Re: More long AS-sets announced
Edward B. Dreger wrote: Considering Lorenzo's attitude, I'm sure he's taking into account the requests for more heads up. If he tickles an IOS bug, I'd rather have it happen in this scenario than when a less-clued individual or a miscreant tries announcing wacky routes. Bull. His attitude (at least to me) was he needed a consensus of the operational community before he would feel compelled to provide more notice and/or postpone the testing to provide said notice. pt
Re: More long AS-sets announced
And finally, we're doing it, we're not doing it, Surprise, we did it is a crappy way to notify the community that they're about to piss in the global pool. At least there was some level of notification, but why bother if you're not going to stick to what you publicize? One might suspect that the change of plans was due to the impact of operational reality. I would expect some small amount of sympathy from those on this list for those types of events. Tony
Re: More long AS-sets announced
On Tue, 21 Jun 2005, Tony Li wrote:
And finally, we're doing it, we're not doing it, Surprise, we did it
is a crappy way to notify the community that they're about to piss in
the global pool. At least there was some level of notification, but why
bother if you're not going to stick to what you publicize?
One might suspect that the change of plans was due to the impact of
operational reality. I would expect some small amount of sympathy from
those on this list for those types of events.
So send out another email.
Hey people, something came up and we couldn't get started on schedule.
We've rescheduled the test to begin at 16:00 UTC, June 20.
Incidentally, I got a small flurry of MAXAS-LIMIT messages from our
transit routers, but only saw the {2121,...} set.
--
Jon Lewis | I route
Senior Network Engineer | therefore you are
Atlantic Net|
_ http://www.lewis.org/~jlewis/pgp for PGP public key_
IANA IPv4 allocations and bogon updates: 74/8, 75/8, 76/8, 189/8, 190/8
-BEGIN PGP SIGNED MESSAGE- [ Apologies to those of you who receive this note in multiple forums. ] Hi, all. The numerous Team Cymru bogon projects have been updated as of 17 JUN 2005 to reflect the following IANA allocation made on 17 JUN 2005: 074/8 Jun 05 ARIN(whois.arin.net) 075/8 Jun 05 ARIN(whois.arin.net) 076/8 Jun 05 ARIN(whois.arin.net) 189/8 Jun 05 LACNIC (whois.lacnic.net) 190/8 Jun 05 LACNIC (whois.lacnic.net) IANA allocations change over time, so please check regularly to ensure you have the latest filters if you are not using the bogon BGP feed(s). We do announce updates to the bogon projects to sundry lists, such as the bogon-announce list. We can not stress this point strongly enough - these allocations change. If you do not adjust your filters, you will be unable to access perhaps large portions of the Internet. Worse yet, you may end up blocking access for people who transit through you. Please do not apply any filters or blocks to your network without carefully considering the ramifications of doing so. As a point of reference, the Team Cymru master Bogon Reference Page can be found here: http://www.cymru.com/Bogons/ A quick summary of the documents and projects that have been updated include the following: HTTP The Bogon List - http://www.cymru.com/Documents/bogon-list.html The Text Bogon Lists - http://www.cymru.com/Documents/bogon-bn-nonagg.txt - http://www.cymru.com/Documents/bogon-bn-agg.txt Secure BIND Template - http://www.cymru.com/Documents/secure-bind-template.html Secure IOS Template (Cisco) - http://www.cymru.com/Documents/secure-ios-template.html Secure BGP Template (Cisco) - http://www.cymru.com/Documents/secure-bgp-template.html Secure JUNOS Template (Juniper) - http://www.cymru.com/gillsr/documents/junos-template.htm Secure JUNOS BGP Template (Juniper) - http://www.cymru.com/gillsr/documents/junos-bgp-template.htm Ingress Prefix Filter Templates, Loose and Strict (Cisco) - ftp://ftp-eng.cisco.com/cons/isp/security/Ingress-Prefix-Filter- Templates/ Ingress Prefix Filter Template, Loose (Juniper) - http://www.cymru.com/gillsr/documents/junos-isp-prefix-filter-loose.htm Ingress Prefix Filter Template, Strict (Juniper) - http://www.cymru.com/gillsr/documents/junos-isp-prefix-filter-strict.htm BGP Bogon route-server for AUTOMATED updates of bogon filters - All bogon route-server peers have already received the appropriate BGP prefix updates. - http://www.cymru.com/BGP/bogon-rs.html RADb fltr-unallocated fltr-martian fltr-bogons - http://www.cymru.com/Bogons/index.html#radb RIPE NCC fltr-unallocated fltr-martian fltr-bogons - http://www.cymru.com/Bogons/index.html#ripe DNS Bogon (bogons.cymru.com) zone - http://www.cymru.com/Bogons/index.html#dns Monitoring Bogon prefix monitoring - http://www.cymru.com/BGP/robbgp-bogon.html Bogus ASN monitoring - http://www.cymru.com/BGP/asnbogusrep.html Please feel free to contact Team Cymru [EMAIL PROTECTED] with any comments, questions, or concerns. Thank you for your continued support. Rob, for Team Cymru. - -- Rob Thomas http://www.cymru.com Shaving with Occam's razor since 1999. -BEGIN PGP SIGNATURE- Version: PGP 6.5.2 iQCVAwUBQrjLPlkX3QAo5sgJAQFHwAP/Z8KrLp9id6PD51KNEjAlveJCxRnvP4ev RofqRMex1SB5itogkB4O6JmrpSqIjqgM2GsnAUREZr5/r2ekdAZwejT85zHftl92 3ExvEec3P2PVDdfWF5v9TSVWfzwwbMW2HWwymzUYT7klWpjblcUUPdAWl+khD+FU /C8cCA2b8qk= =JvMq -END PGP SIGNATURE-
