RE: Survey: Peering Staffing Levels
Even with large providers, if you peer with them, you generally know the peering coordinator by name. In some cases, you know their assistant by email. :) Deepak Jain AiNET -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Andy Dills Sent: Wednesday, June 12, 2002 4:47 PM To: Dwight Ernest Cc: [EMAIL PROTECTED] Subject: Re: Survey: Peering Staffing Levels On Wed, 12 Jun 2002, Dwight Ernest wrote: I'm interested in getting some idea of the level of staffing provided by NSPs and ISPs in their peering departments. In fact, I've been asked by my management to provide as much info about such levels as possible, without a need to disclose the identity of any responding company. Forgive me if I'm just used to small companies, but why would you really need more than one full time person (with an assistant possibly) in your peering department? Sure, the job requires a very specific skill set (something along the lines of an engineer with an MBA), but the day-to-day interactions and changes regarding peering would seem to be minimal. In fact, my impression seems to be that you don't really need anybody on staff to not return emails to peering@, which is seemingly how most providers deal with it. :) Note: I have absolutely no experience or data to base my assumptions on, so don't slap me too hard. Andy Andy Dills 301-682-9972 Xecunet, LLCwww.xecu.net Dialup * Webhosting * E-Commerce * High-Speed Access
Re: Error in assignments....?
NB: this is neither an endorsement for or against generating policy
from databases.
Could somebody that has done this comment on how complicated this is to
set up? What steps were involved?
Taking this to mean filter on policy learned from databases,
following is a Tcl fragment wrapped around RAToolkit's peval that I
used to use to query the RADB and build intermediate data from which I
would then generate either Cisco prefix lists or Juniper policy
statements.
The Tcl proc psort, used to sort a list of prefixes in CIDR
notation, is left as an exercise to the reader.
proc peval {macro tag allow_incomplete description} {
set res [list $tag\tdescription\t[list $description]]
set incomplete 0
if {[catch {set tmp [exec peval $macro]} why]} {
set tmp [lindex [split $why \n] 0]
set incomplete 1
}
set plist
if {[regexp {\(\{([^\}]+)\}\)} $tmp junk tmp2]} {
set tmp3 [split $tmp2 ,]
foreach U [lsort -command psort $tmp3] {
lappend res $tag\tpermit\t[string trim $U]
}
}
if {[info exists res]} {
if {$incomplete !$allow_incomplete} {
return # [join $res \n# ]
} else {
return [join $res \n]
}
}
}
The Tcl proc named peval takes four arguments: the macro to be
evaluated, a tag that I would use later to name the final result,
whether an incomplete list of prefixes is permitted, and a
description.
That third bit, whether an incomplete list of prefixes is permitted,
turns out to be an important bit. Some bits of policy refer to other
bits of policy, and when bits referenced to not exist peval (the
RAToolkit peval, called by Tcl exec) writes them to stderr and causes
Tcl to raise an exception.
An example (I used to run AS33, and the policy for AS33 doesn't appear
to have been changed since I last updated it so I'll take the liberty
of picking on it; yes, I know DEC was bought by Compaq and Compaq
bought by HP):
% source xpeval.tcl
% peval as33 33 1 Digital Equipment Corporation prefixes
33 description {Digital Equipment Corporation prefixes}
33 permit 16.0.0.0/8
33 permit 128.45.0.0/16
33 permit 130.180.0.0/16
33 permit 198.55.32.0/21
33 permit 198.55.40.0/23
33 permit 199.33.32.0/24
33 permit 199.33.32.0/19
33 permit 199.80.128.0/17
33 permit 204.123.0.0/16
(Goodness, that's a lot of address space, isn't it?)
RAToolkit's peval uses rpsl-p.merit.edu as its source of data, and,
amusingly, returns data for the macro AS33, even though the RADB
seems to have no AS33 aut-num object. Go figure.
Anyways, there was more glue to (a) build vendor-specific
configuration language to turn that into a syntactically correct
filter for routers (the kind of glue that has to be rewritten every
time a new vendor invents a new configuration language), with care
taken not to replace a previously-defined filter with no filter should
an error be introduced into the RADB, (b) and update the router
configs nightly with the new policy.
When I ran into the problem of a list of prefixes for one peer being
generated that caused the resulting (compressed) configuration to
exceed the size of flash memory on my routers, I stopped the cron job
and switched all the peers over to maximum-prefix-style limits with
a standard bogon exclusion filter.
It took a couple days to put it together and test it (although I
didn't think to test the list too long case), and was in production
for about a year and a half. The vendors' implementation of maximum
prefix limits was not available when I started it, and was available
when the list too long case cropped up.
RE: GigEth regenerators
a brief summary of responses up to now: - there are several vendors making some kind of sx-to-zx gbe converters (they call it gbe extenders), which gives an equivalent of a device with a zx gbic. these vendors include jdsu, luxn, extreme etc. - two companies were found making gbe optical regenerators - imcnetworks and transmode - other solution is to try with edfa mikael: which exact gbic did you use? i was comparing cisco-reselled gbics and their cwdm gbics seem to be more than 10dB better on power budget... anybody tried this in real life? thanks again -- Tomas Daniska systems engineer Tronet Computer Networks Plynarenska 5, 829 75 Bratislava, Slovakia tel: +421 2 58224111, fax: +421 2 58224199 A transistor protected by a fast-acting fuse will protect the fuse by blowing first. -Original Message- From: Mikael Abrahamsson [mailto:[EMAIL PROTECTED]] Sent: 12. júna 2002 17:48 To: [EMAIL PROTECTED] Subject: Re: GigEth regenerators On Wed, 12 Jun 2002, Daniska Tomas wrote: but for gigeth in this case - we need to connect two sites about 200km apart over dark fiber Check out the 7020 from Transmode http://www.transmode.se/products/sing_dual.htm Btw, my personal best so far is 150km over dark fiber using a extra long haul GBIC, 32dB loss over the fiber and it worked perfectly. Only tested it for 10 minutes, but there were no CRC errors during that time. +4dB output from the GGBIC, now we have to worry to not look into the laser :) -- Mikael Abrahamssonemail: [EMAIL PROTECTED]
RE: What's wrong with provisioning tools?
bob, i was more interested in something emulating a vt100 that one could eventually plug to a console port and chat with the box... from someone's post sooner in this thread it seemed that someone is using it out there... i like the idea of talking with the box while let's say driving a car... e.g. vocollect does something close to this but it's more an in-building solution than an over-the-phone stuff http://www.vocollect.com/sitehtml/products/talkman01.php maybe it would be worth making some mediation to pstn and a proxy app which could ssh the boxes :) -- Tomas Daniska systems engineer Tronet Computer Networks Plynarenska 5, 829 75 Bratislava, Slovakia tel: +421 2 58224111, fax: +421 2 58224199 A transistor protected by a fast-acting fuse will protect the fuse by blowing first. -Original Message- From: Bob Bradlee [mailto:[EMAIL PROTECTED]] Sent: 13. júna 2002 16:29 To: Daniska Tomas Subject: RE: What's wrong with provisioning tools? I have a client HTTP://www.CORRS.ORG using several speech-synthesis terminals, they even have a brail printer on the network. I donate my eyes to them from time to time, but they get along very well on their own. Bob --Original Message Text--- From: Daniska Tomas Date: Thu, 13 Jun 2002 15:15:23 +0200 Message by the way - those speech-synthesis terminals were a just joke or is anyone really using them? :))
Re: What's wrong with provisioning tools?
On Wed, 12 Jun 2002, Stephen Griffin wrote: In the referenced message, David Daley said: snip 4) There isn't anything to track non sanctioned changes to the network (i.e.: hacker induced re-configurations) I would be really surprised if anything other than mom-and-pop shops didn't have _at least_ this. rtrmon or rancid can do great config archiving and provide difference output. I didn't find anything that really suited my needs at the time (late 2000/early 2001), so I ended up writing my own archiver. From time to time I've thought about adding it to the COSI-NMS project on Sourceforge, but never gotten around to it. I've also other similar tools outside of Sourceforce, such as Pancho (http://pancho.lunarmedia.net/). I wrote the code behind mine to be fairly modular, so that adding a module to back up a config from a new device is pretty easy. It currently backs up these devices using either SNMP or Expect scripts for devices that require it: Cisco IOS 12.0 Cisco IOS =12.0 Cisco CatOS Cisco 5000 VPN concentrators (the Compatible Systems ones, not Altiga) Cisco LocalDirectors Lucent TAOS (Max TNTs) Alteon WebOS (ACEdirectors) Redback AOS Nortel BayRS (Bay Networks nee Wellfleet) -config is binary other odds and ends as they come up, like Netopia routers, etc. I haven't written anything to back up Junipers yet because I don't have any to test against. Aside from the Nortel routers, I support versioning on everything else. Keep in mind this is only one piece of the puzzle - backing up what's already out there. I intentionally left out the functionality to allow a config to be uploaded to one of the devices above for reasons already specified in this thread - it's just too dangerous. You can melt down a whole network really quickly if you're not careful. jms
Re:Survey: Peering Staffing Levels
Dwight, Contact Peter Jansen, ([EMAIL PROTECTED]). He is *clearly* The Man when it comes to peering, and I'm certain that he'd be more than glad to answer all of your questions. -- Original Message From: Dwight Ernest[EMAIL PROTECTED] Subject: Survey: Peering Staffing Levels Date: Wed, 12 Jun 2002 15:11:13 -0400 Please forgive the non-operational content. I'm interested in getting some idea of the level of staffing provided by NSPs and ISPs in their peering departments. In fact, I've been asked by my management to provide as much info about such levels as possible, without a need to disclose the identity of any responding company. If you have time, and wish to participate, I'd sure appreciate it. I will provide a summary of the responses to respondents. No identifying information need be provided. Get a disposable email account at Hotmail or Yahoo if you'd like to be really anonymous. Any question may be skipped if you wish. I appreciate your assistance! DO NOT RESPOND TO THE LIST! 1. Do your peering staff members do peering negotiations and planning only, or do they also do peering-related hands-on router engineering? ___ planning and negotiation only ___ planning, negotiation, and hands-on router stuff ___ something other than these two choices: __ 2. What is the size of your peering staff? ___ full-time staff members ___ part-time staff members 3. Do you feel this staffing level is appropriate? ___ too high ___ just right ___ too low 4. What is the ballpark aggregate exchange volume in megabits/second at peak, for your AS, or for all of the ASses for which you are responsible? ___ mb/s @ peak 5. What is the primary location of the majority of your peering department's staff members? ___ USA ___ North America other than USA ___ Europe ___ Central or Western Asia ___ Eastern or Southeastern Asia ___ Australia/NZ ___ South America ___ Africa 6. Approximately how many private or public peers does your network exchange traffic with? ___ private peers ___ public peers 7. What percentage volume of your network's total exchange volume is exchange via peering (as opposed to being exchanged via transit)? ___% is exchanged via peering Again, thank you very much for your participation. Cheers, --Dwight Ernest _ Free email with personality! Over 200 domains! http://www.MyOwnEmail.com
LEAP Security Vulnerabilities??
Title: LEAP Security Vulnerabilities?? I am well aware of the many security vulnerabilities that exist on wireless networks as well as the inadequacies of WEP. I was curious if anyone has had any experiences with Cisco's LEAP authentication protocol? I have scoured the net for reviews or documents examining any potential vulnerabilities, but have not been able to find any. Any and all help or information would be appreciated. Thanks in advance, Jason Hyska Worldwide Information Security Johnson Johnson [EMAIL PROTECTED]
Re: What's wrong with provisioning tools?
### On Wed, 12 Jun 2002 18:37:07 -0400 (EDT), jeffrey arnold ### [EMAIL PROTECTED] casually decided to expound upon [EMAIL PROTECTED] ### the following thoughts about Re: What's wrong with provisioning ### tools?: ja On Wed, 12 Jun 2002, Stephen Griffin wrote: ja ja :: I would be really surprised if anything other than mom-and-pop shops ja :: didn't have _at least_ this. ja :: ja :: rtrmon or rancid can do great config archiving and provide difference ja :: output. ja ja I don't think the issue is detecting change as much as it is associating ja change to specific goals/tickets, etc.. If an ACL changes on a router, ja rancid will pick it up, but right now there is no automated way to tell ja whether that was as a result of a customer request or a security breach. I've had quite a bit of experience with config management tools and have written some myself many years ago as did probably others due to the at the time lack of such things. However, many vendors are providing thrid-party solutions. The one I've seen that seems most suited to an ISP environment is GoldWire although to be honest, I have not really looked in-depth into such products for almost a year now so there might be others. -- /*===[ Jake Khuon [EMAIL PROTECTED] ]==+ | Packet Plumber, Network Engineers /| / [~ [~ |) | | --- | | for Effective Bandwidth Utilisation / |/ [_ [_ |) |_| N E T W O R K S | +=*/
Level 3
Hi, Is there a network status page for level 3? Their website seems a bit off today. Thanks much, Jane begin:vcard n:Pawlukiewicz;Jane tel;cell:703 517-2591 tel;fax:703 289-5814 tel;work:703 289-5307 x-mozilla-html:FALSE org:Booz Allen Hamilton;Visit us on the Internet: a href=http://boozallen.com;BoozOnline/a adr:;; version:2.1 email;internet:[EMAIL PROTECTED] title:Senior Consultant fn:Jane Pawlukiewicz end:vcard
RE: LEAP Security Vulnerabilities??
Title: LEAP Security Vulnerabilities?? If you're serious enough about security to find 128 WEP inadequate, I would think you would be doing some sort of VPN or other SSL solution anyway, making WEP redundant. Or am I missing something? Best, -Al Rowland -Original Message-From: Hyska, Jason [JJCUS] [mailto:[EMAIL PROTECTED]]Sent: Thursday, June 13, 2002 10:15 AMTo: [EMAIL PROTECTED]Subject: LEAP Security Vulnerabilities?? I am well aware of the many security vulnerabilities that exist on wireless networks as well as the inadequacies of WEP. I was curious if anyone has had any experiences with Cisco's LEAP authentication protocol? I have scoured the net for reviews or documents examining any potential vulnerabilities, but have not been able to find any. Any and all help or information would be appreciated. Thanks in advance, Jason Hyska Worldwide Information Security Johnson Johnson [EMAIL PROTECTED]
Re: LEAP Security Vulnerabilities??
Thus spake Hyska, Jason [JJCUS] [EMAIL PROTECTED] I am well aware of the many security vulnerabilities that exist on wireless networks as well as the inadequacies of WEP. WEP's only real failure was the failure to specify keying; vendors (and users) with less security experience interpreted this to mean static keys were sufficient. The choice of RC4 was unfortunate given the above problem, but the coming switch to AES should fix that. I was curious if anyone has had any experiences with Cisco's LEAP authentication protocol? I have scoured the net for reviews or documents examining any potential vulnerabilities, but have not been able to find any. Any and all help or information would be appreciated. LEAP itself is unlikely to present problems, as it's just a means to verify 802.1x credentials and force key rotation. I'd be much more wary of potential problems in 802.1x itself, since that's the over-the-air portion. S
Re: LEAP Security Vulnerabilities??
On Thu, Jun 13, 2002 at 02:34:29PM -0500, Stephen Sprunk wrote: WEP's only real failure was the failure to specify keying; vendors (and users) with less security experience interpreted this to mean static keys were sufficient. The choice of RC4 was unfortunate given the above problem, but the coming switch to AES should fix that. Most existing wireless APs cannot keep up with 802.11b doing RC4 (which is EXTREMELY light on the cpu) at line rate. I'm afraid to see what they consider acceptable for AES, anything done as a firmware upgrade is going to be quite limiting. At least for 802.11a I believe they're doing better. -- 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: GigEth regenerators
[EMAIL PROTECTED] (Daniska Tomas) writes: a brief summary of responses up to now: in response to my earlier reply on this topic, i was also pointed at http://www.nbase-xyplex.com/products.html which indeed shows how to do 65Km regen points. pretty cool other stuff too.
Re: LEAP Security Vulnerabilities??
Thus spake Richard A Steenbergen [EMAIL PROTECTED] On Thu, Jun 13, 2002 at 02:34:29PM -0500, Stephen Sprunk wrote: The choice of RC4 was unfortunate given the above problem, but the coming switch to AES should fix that. Most existing wireless APs cannot keep up with 802.11b doing RC4 (which is EXTREMELY light on the cpu) at line rate. I'm afraid to see what they consider acceptable for AES, anything done as a firmware upgrade is going to be quite limiting. At least for 802.11a I believe they're doing better. Most vendors chose to do their RC4 encryption in software and consequently can't do more than 1-2mb/s -- caveat emptor. That's hardly a failing of the 802.11 WG; at least one vendor can do RC4 (and soon AES) at wire rate. You can have it good, fast, or cheap -- pick two. S
RE: GigEth regenerators
On Thu, 13 Jun 2002, Daniska Tomas wrote: mikael: which exact gbic did you use? The Finisar FTR1619-55. My experiense is that buying directly from the manufacturer is taking a chance, it's much cheaper, but you get great variance in quality and you should really do testing on the gbics, or be prepared to swap gbics in case you get problems. Buying from the switch vendor ensures that you do not get finger-pointing and they do test the gbics more than the manufacturer. -- Mikael Abrahamssonemail: [EMAIL PROTECTED]
Re: KPNQWEST cease operation?
## On 2002-06-14 04:08 +0100 Chrisy Luke typed: CL CL ?$BLpEDIt?(B wrote (on Jun 14): CL I heard that NOC of KPQWEST in Frankfurt would cease operation at 1400 CL hour (local time) today. CL CL Is there any additional information about this? CL CL http://live.ebone.com/ is probably about as much info as you can get unless You mean http://live.ebone.net/ or http://live.save-ebone.com/ ? -- Rafi
