Re: Above.net problems ??
On Tue, Nov 25, 2003 at 11:29:32PM +0100, Laurent Frigault wrote: anyone having trouble with above.net at the moment ? Yes. The problem seems related to the TAT14 failure. Since, around 16h30 (GMT +0100) our bgp sessions with AS 6461 reset and now they received only 82305 prefix. The sessions reset again 35 minutes ago. Missing prefixes are back and above.net network seems reachable again. Regards, -- Laurent Frigault - NOC GANDI
Re: [Activity logging archiving tool]
If ACS and CiscoWorks are too costly and CVS and RANCID too unwieldy, SourceForge has 2 alternatives that you might want to consider... tool http://tool.sourceforge.net/ and NCAT http://ncat.sourceforge.net/ both of which can be sufficiently tweaked to meet your device audit needs. (A SourceForge loyalist, but I'm a RANCID kind of girl, myself...) And, of course, remember the least costly and most oft overlooked practice of establishing solid policies. Tools should be deployed to enforce a well-defined policy, including guidelines and procedures laying down the law when it comes to change management and change control of production devices. You mentioned an outlet for _manual_ recording/documentation of laying on of hands befalling the nodes, so define a must-have and must-do list holding dominion over such activity, requiring that appropriate backups occur, backouts are ready to go when things burst into flames, and that all work be delineated and documented explicitly ex post facto. Then, sit back and enjoy the grumbling of your paperwork-hating associates, and be prepared to crack skulls if they flake on updating the change control machanisms, as set forth in the unbudging monolith that is your change management policy. Still liking TACACS-RANCID though, as you can lead a horse to water, but you can't make him think... --ra On Tue, Nov 25, 2003 at 03:54:34PM -0700, guy said something to the effect of: Don't forget that TACACS can log all commands entered into a router. When used in combination with rancid and cvs/cvs-web, it's very useful. I'm looking for a simple tool, in which each and every one has to manually record whatever (s)he has done or any incident (s)he observed so that the tool archives that data someway. Later, in case if someone needs, (s)he should be able to search for that archive by date, by person, by a random phrase, etc. rancid (http://www.shrubbery.net/rancid) and cvs-web (http://stud.fh-heilbronn.de/~zeller/cgi/cvsweb.cgi/) -- K. Rachael Treu, CISSP rara at navigo dot com ..sic itur ad astra..
Re: TAT 14 failure
[EMAIL PROTECTED] disait : In a message written on Tue, Nov 25, 2003 at 07:24:27PM +, [EMAIL PROTECTED] wrote: still seeing decent ping times. anyone detect an actual outage or issue? Best info we have is that there are two outages. One has existed for the last 3 weeks or so between Tuckerton (New Jersey) and Bude (UK). It takes out the southern path across the atlantic. There is a second outage between Bude (UK) and Katwijk (NL). For circuits that landed in London or France this (should have) taken out the redundant path for those circuits. Circuits from Tuckerton (New Jersey) or Manasquan (New Jersey) to Katwijk (NL), Norden (DE), or some city in Denmark who's name I forget should still be up on the northern path. So, if you're in London or France your circuits are likely to be down, however some people in those locations used Contentinal capacity to link up to Katwijk, in which case they might still be operational. I confirm that France is having some problem with TAT14. France Telecom International Backbone (Opentransit) is currently running with non TAT14 capacity (10G) and one oc48 direct to Copenhagen (that is ok). We (Opentransit) are currently not experiencing any congestion but are implementing a new 10G circuit to secure our topology until TAT14 is back to life (one leg at least). Both problems are undersea issues, so don't expect speedy resolution if you are down. Yep .. i heard days ... not hours :-( Vincent, Opentransit (France Telecom)
Re: Above.net problems ??
In a message written on Wed, Nov 26, 2003 at 09:35:16AM +0100, Laurent Frigault wrote: The sessions reset again 35 minutes ago. Missing prefixes are back and above.net network seems reachable again. We did restore full service overnight last night (well, probably early in the morning for those in Europe), our operations should be back to normal. If anyone is still seeing above.net issues please open a ticket through the normal channels. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgp0.pgp Description: PGP signature
Re: Open source traffic shaper experiences? (was Re: looking for a review of traffic shapers)
Even though it compares more with WebSense, CensorNet does basic shaping plus has some nice features. Free download. (Extra features (i.e. image filter and blacklist updates) require a subscription.) CensorNet http://www.censornet.com/ -W On Tue, 2003-11-25 at 13:38, [EMAIL PROTECTED] wrote: Note: delurk. Some of the commercial traffic shaping devices reviewed here are tens of thousands of dollars. For a smaller ISP (i.e. less than a DS3 of aggregate upstream bandwidth), that kind of expense doesn't make sense-- but the need to control bandwidth consumption is still an issue. For example, I work at an ISP in Central America where bandwidth costs are quite high. A 2Mbps dedicated link typically sells for over $4,000 per month. One can imagine how important it is to be able to throttle the top P2P talkers in this kind of environment. Is anyone on the NANOG list aware of a disk-less Linux solution? One might imagine a Knoppix-like bootable CD image (perhaps CD-RW, so config files could be updated) that would turn an inexpensive Linux box into an effective traffic shaping device, using tools like CBQinit, MRTG/RRDTOOL, and a Webmin-like admin interface. The closest thing to this I've seen is ETINC's BWMGR, but that's a closed-source solution and is still somewhat expensive. -Andrew White On Tue, 25 Nov 2003, William Caban wrote: A resume of some of the answers I have received: What's missing from (at least some) current traffic shaping appliances http://darkwing.uoregon.edu/~joe/what-shapers-need.pdf Ten Odd Strategies for Picking Numerical Values for Your Traffic Shaper http://darkwing.uoregon.edu/~joe/picking-a-shaper-policy.pdf The Case for Traffic Shaping at Internet2 Schools http://darkwing.uoregon.edu/~joe/i2-traffic-shaping.ppt Bandwidth Management Strategies and Methodologies http://rdweb.cns.vt.edu/~cgaylord/talks/20020507-i2bandwidth.pdf Bandwidth Managers: Going With The Flow http://www.bcr.com/bcrmag/2003/04/p32.asp Reviewing Packet Shaping Products http://www.net.cmu.edu/docs/arch/qospe-pre.html Succesful Bandwidth Management at Crnegie Mellon http://www.net.cmu.edu/pres/jt0803/ Bandwidth Management Technologies http://www.etinc.com/index.php?page=bwcompare.htm Thanks everyone. -W On Mon, 2003-11-24 at 17:36, William Caban wrote: I'm looking for a review/report on traffic/packet shapers products with a side-by-side comparison. Did any one has a clue where I can find one such report? Thanks, -W -- William Caban [EMAIL PROTECTED]
Re: Above.net problems ??
Hi there. Is there any relationship between this europeanwide above.net failure and the huge amount of DNS requests to lockup.zonelabs.com which failed that every ISP (at least in France) seem to have encountered last night ? The zonelabs.com zone is hosted on Above.net NS servers. --On mercredi 26 novembre 2003 09:49 -0500 Leo Bicknell [EMAIL PROTECTED] wrote: In a message written on Wed, Nov 26, 2003 at 09:35:16AM +0100, Laurent Frigault wrote: The sessions reset again 35 minutes ago. Missing prefixes are back and above.net network seems reachable again. We did restore full service overnight last night (well, probably early in the morning for those in Europe), our operations should be back to normal. If anyone is still seeing above.net issues please open a ticket through the normal channels. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org -- Jerome Fleury Tiscali France Network Engineer Tel: +33 1 45082314
RE: Activity logging archiving tool
I've now got several options. Let me think and select one. Thanks a lot for all your quick responses. Regards, Priyantha -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Priyantha Sent: Tuesday, November 25, 2003 2:15 PM To: [EMAIL PROTECTED] Subject: Activity logging archiving tool In my company, there are several technical guys make changes to the existing network and it's very difficult to keep track of what we did when, etc. I'm looking for a simple tool, in which each and every one has to manually record whatever (s)he has done or any incident (s)he observed so that the tool archives that data someway. Later, in case if someone needs, (s)he should be able to search for that archive by date, by person, by a random phrase, etc. Any help in this regard is appreciated, Priyantha Pushpa Kumara --- Manager - Data Services Wightman Internet Ltd. Clifford, ON N0G 1M0 Fax: 519-327-8010
Re: WLAN shielding
Unless you are looking to isolate a small box for such purposes as testing RF devices, I would not use a shielding technique to limit access to your wireless network. Containing 2.4GHz signals within a room of any reasonable size is extremely difficult. You would probably have to cover it with a double-walled, seamless sheet or fine grid of conductive material. Any holes, cracks, windows, or doors are likely to blow the whole deal. I'd recommend using both WEP and an encrypting VPN if you're worried about people getting on your network. Also make sure to turn off SSID broadcasts. Planning on limiting signal using a physical mechanism of some sort's just a little too scifi to be useful. Cheers, Doug On Wed, 26 Nov 2003, Andy Grosser wrote: Apologies in advance if this may not quite be the proper list for such a question... My company is investigating the use of wireless in a couple of our conference rooms. Aside from limiting the scope of reception with various directional antennae, does anyone have any suggestions or pointers for other ways to limit the propagation of signals (i.e. special shielding paint, panels or other wall coatings)? Feel free to reply off-list. Thanks! Andy --- Andy Grosser, CCNP andy at meniscus dot org ---
Re: WLAN shielding
Planning on limiting signal using a physical mechanism of some sort's just a little too scifi to be useful. It's too much effort to shield the room itself, but you might want to try making the inverse square law work for you by shielding all of the wireless antennae so that the signal is too weak to travel more than a meter or two. Put extra shielded wireless access points on the conference tables so that everyone can place their laptops within range of a signal. But make sure that you thoroughly test the reception both inside and outside the room to be certain that there are no leaks. No guarantees but I'd be interested to hear a report if you try this. --Michael Dillon
Re: Above.net problems ??
In a message written on Wed, Nov 26, 2003 at 05:39:33PM +0100, Jerome Fleury wrote: Is there any relationship between this europeanwide above.net failure and the huge amount of DNS requests to lockup.zonelabs.com which failed that every ISP (at least in France) seem to have encountered last night ? The zonelabs.com zone is hosted on Above.net NS servers. I replied privately, but then saw this also went to Nanog. I'm also looking into that problem. My initial observation: 1) AboveNet DNS servers were down for some people in Europe. 2) ZoneLab's other nameservers are both on the same lan and connected to our network. 3) ZoneLab's software seems to have an overly agressive retry (I've been told 2 queries per second per machine) when it can't resolve a DNS name. Clearly we can only directly address #1, which is a top priority for us, we are trying to make the customer aware of why #2 and #3 are bad. I haven't proven #3 yet, it's based on other peoples reports, so I might be wrong about the software's exact behavior. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgp0.pgp Description: PGP signature
Re: WLAN shielding
--- [EMAIL PROTECTED] wrote: Planning on limiting signal using a physical mechanism of some sort's just a little too scifi to be useful. It's too much effort to shield the room itself, but you might want to try making the inverse square law work for you by shielding all of the wireless antennae so that the signal is too weak to travel more than a meter or two. Put extra shielded wireless access points on the conference tables so that everyone can place their laptops within range of a signal. However, if you're talking about one room only, and you're trying to prevent outsiders from sniffing, why not just use a cheap workgroup switch/hub? Having to buy multiple WAPs and insulate them quickly destroys the wireless value-add... -David Barak = David Barak -fully RFC 1925 compliant- __ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/
RE: Above.net problems ??
Title: RE: Above.net problems ?? Is there any relationship between this europeanwide above.net failure and the huge amount of DNS requests to lockup.zonelabs.com which failed that every ISP (at least in France) seem to have encountered last night ? The zonelabs.com zone is hosted on Above.net NS servers. The Netherlands were hit as well. We saw a massive flood of queries for lockup.zonelabs.com, too. It performed a nice DoS on our client name servers :-( You'd think that an unresponsive nameserver would be flagged dead, and such information be cached. Does anyone know whether that's actually done in Bind 8.3.4? Or perhaps not by default? Cheers, Arjan H Not even a clue-by-four would work with this clown. dr. Arjan Hulsebos Security Engineer Essent Kabelcom, @Home Benelux department 1042 AX Amsterdam Email: [EMAIL PROTECTED] Tel: +31 20 88 55 407 Mob: +31 6 21 548 777
RE: Above.net problems ??
You'd think that an unresponsive nameserver would be flagged dead, and such information be cached. Does anyone know whether that's actually done in Bind 8.3.4? Or perhaps not by default? This certainly does not happen when all authoritative nameservers are unresponsive. See http://www.nanog.org/mtg-0310/wessels.html, in particular pages 23 and 24 of the slides. In my simulations with 100% packet loss, DNS caches running BIND8, dnscache, W2000, and W2003 all amplified the user's query rates. Only BIND9 attenuated. The results do depend on the actual query rate, however. At a higher query rate, the other caches would/should attenuate as well (perhaps reaching their hard-coded rate limits), but I don't have the exact numbers. It would be interesting to repeat the simulation and take out, say, half of a set of authoritative nameservers during the middle of the test. Duane W.
Re: looking for a review of traffic shapers
(caveat: I am not in sales - I'm a very happy PacketShaper user.) Traffic shaping comes in many shapes and forms. Many places who need to do traffic shaping need to do it down to the application level, so those apps that are of a mission-critical nature get through, while those that can wait are made to wait. Trouble with the 'diskless' units is a) they can't distinguish enough different applications to really be useful, b) they don't have control over the incoming traffic, and c) they can't provide you with a historical trend analysis (or event analysis) to correlate with issues that may be happening on the network. Most make use of queueing, which can only provide some control for outbound traffic, and at worst can lead to further retransmissions and thus further congestion. The CMU study between the Allot and the Packeteer devices was not well done, and I would encourage you to look further at each of these devices - especially since a full year has passed since those reports, and that the testing didn't even look at the rate-limiting features of them, which is what would make all the difference. Certainly, the shaping devices out there are not inexpensive, but a box that can shape 10MBit of traffic, broken out to over 500 different classes, a PacketShaper 2500 can be had for well under US$1. The ROI on these devices is proven, and depending on the scenario, it can be months, not years before the device has paid for itself. In many situations, it is the *only* solution to keeping control of ever-increasing bandwidth demands in non-ISP (just move packets as fast as possible) environments. I would be more than happy to discuss my experiences with these units. -Peter Peter Murray Pittsburgh, PA On Wed, 26 Nov 2003, William Caban wrote: On Tue, 2003-11-25 at 13:38, [EMAIL PROTECTED] wrote: Note: delurk. Some of the commercial traffic shaping devices reviewed here are tens of thousands of dollars. For a smaller ISP (i.e. less than a DS3 of aggregate upstream bandwidth), that kind of expense doesn't make sense-- but the need to control bandwidth consumption is still an issue. [snip] Is anyone on the NANOG list aware of a disk-less Linux solution? One might imagine a Knoppix-like bootable CD image (perhaps CD-RW, so config files could be updated) that would turn an inexpensive Linux box into an effective traffic shaping device, using tools like CBQinit, MRTG/RRDTOOL, and a Webmin-like admin interface. The closest thing to this I've seen is ETINC's BWMGR, but that's a closed-source solution and is still somewhat expensive. -Andrew White
Re: Anit-Virus help for all of us??????
On Mon, Nov 24, 2003 at 02:31:42PM -0800, Henry Linneweh wrote: The latest Zone Alarm Pro also invites subscribed users to participate in creating a more robust solution The latest Zone Alarm also creates a nice ddos to your ISP's dns servers if lockup.zonelabs.com can't be resolved (as we found out the hard way here in europe after the Above downtime). -- Cliff Albert| RIPE: CA3348-RIPE | https://oisec.net/ [EMAIL PROTECTED] | 6BONE: CA2-6BONE | PGP Fingerprint = 9ED4 1372 5053 937E F59D B35F 06A1 CC43 9A9B 1C5A
Re: Anit-Virus help for all of us??????
Dave Howe wrote: perhaps a migration to linux is in order? after all, its free(ish), doesn't care too much about marketing deadlines, and if you start them young enough, KDE or Gnome is certainly is no harder to learn than windows. Why stop at an intermediate step but migrate to free OS while we are at it? Like FreeBSD, NetBSD or OpenBSD. Pete
Re: [Re: [RE: MPLS billing model]]
On Tue, Nov 25, 2003 at 06:16:43PM -0500, Alex Rubenstein wrote: In a working transport system, what goes in must come out. So, if you add all the ports in a common direction (in or out), you'll at least get a nice aggregate even if you can't measure individual virtual circuits properly due to whatever brokeass vendor you're using. :) ... which doesn't take into account distance. Assume for a moment you sell a customer a port in Newark, NYC, and London. Clearly, a bit from nyc to newark should be priced differently than one from nyc to london. Agreed? Yes... Based on the current market, the circuit from NYC to Newark is going to be way more expensive than a larger circuit from NYC to London. :) -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: looking for a review of traffic shapers
Check out http://www.ellacoya.com/products/products.html. They are tried and true. Their deep packet inspection to pick up all known P2P for example works extremely well. Regards, Timo At 01:35 PM 26/11/2003 -0500, Peter Murray wrote: (caveat: I am not in sales - I'm a very happy PacketShaper user.) Traffic shaping comes in many shapes and forms. Many places who need to do traffic shaping need to do it down to the application level, so those apps that are of a mission-critical nature get through, while those that can wait are made to wait. Trouble with the 'diskless' units is a) they can't distinguish enough different applications to really be useful, b) they don't have control over the incoming traffic, and c) they can't provide you with a historical trend analysis (or event analysis) to correlate with issues that may be happening on the network. Most make use of queueing, which can only provide some control for outbound traffic, and at worst can lead to further retransmissions and thus further congestion. The CMU study between the Allot and the Packeteer devices was not well done, and I would encourage you to look further at each of these devices - especially since a full year has passed since those reports, and that the testing didn't even look at the rate-limiting features of them, which is what would make all the difference. Certainly, the shaping devices out there are not inexpensive, but a box that can shape 10MBit of traffic, broken out to over 500 different classes, a PacketShaper 2500 can be had for well under US$1. The ROI on these devices is proven, and depending on the scenario, it can be months, not years before the device has paid for itself. In many situations, it is the *only* solution to keeping control of ever-increasing bandwidth demands in non-ISP (just move packets as fast as possible) environments. I would be more than happy to discuss my experiences with these units. -Peter Peter Murray Pittsburgh, PA On Wed, 26 Nov 2003, William Caban wrote: On Tue, 2003-11-25 at 13:38, [EMAIL PROTECTED] wrote: Note: delurk. Some of the commercial traffic shaping devices reviewed here are tens of thousands of dollars. For a smaller ISP (i.e. less than a DS3 of aggregate upstream bandwidth), that kind of expense doesn't make sense-- but the need to control bandwidth consumption is still an issue. [snip] Is anyone on the NANOG list aware of a disk-less Linux solution? One might imagine a Knoppix-like bootable CD image (perhaps CD-RW, so config files could be updated) that would turn an inexpensive Linux box into an effective traffic shaping device, using tools like CBQinit, MRTG/RRDTOOL, and a Webmin-like admin interface. The closest thing to this I've seen is ETINC's BWMGR, but that's a closed-source solution and is still somewhat expensive. -Andrew White
Re: Above.net problems ??
On Wed, Nov 26, 2003 at 11:31:32AM -0700, Duane Wessels wrote: In my simulations with 100% packet loss, DNS caches running BIND8, dnscache, W2000, and W2003 all amplified the user's query rates. Only BIND9 attenuated. pdns_recursor also throttles queries, see http://doc.powerdns.com/x2025.html -- http://www.PowerDNS.com Open source, database driven DNS Software http://lartc.org Linux Advanced Routing Traffic Control HOWTO
RE: Above.net problems ??
On Wed, 26 Nov 2003, Arjan Hulsebos wrote: The Netherlands were hit as well. We saw a massive flood of queries for lockup.zonelabs.com, too. It performed a nice DoS on our client name servers :-( You'd think that an unresponsive nameserver would be flagged dead, and such information be cached. Does anyone know whether that's actually done in Bind 8.3.4? Or perhaps not by default? BIND9 does this, but it won't prevent clients from still asking the question over and over again. So an ISP with lots of downstream dumb clients (i.e. Windows) will still experience the DOS unless they have sufficient capacity in their DNS servers or rate-limit tcp/udp 53 at their network edge. client - caching name server - authoritative name server
Re: WLAN shielding
Andy Grosser wrote: My company is investigating the use of wireless in a couple of our conference rooms. Aside from limiting the scope of reception with various directional antennae, does anyone have any suggestions or pointers for other ways to limit the propagation of signals (i.e. special shielding paint, panels or other wall coatings)? Andy, What is wrong with the 'good old' 802.1x with EAP or WPA solution? -- Marco
Re: WLAN shielding
Andy Grosser wrote: My company is investigating the use of wireless in a couple of our conference rooms. * [EMAIL PROTECTED] (Marco Davids (SARA)) [Wed 26 Nov 2003, 21:30 CET]: What is wrong with the 'good old' 802.1x with EAP or WPA solution? There is a difference between keeping signals from leaking out, and keeping them from leaking out in decipherable form. In some situations the latter may be enough - hopefully it will be if you need to be out and still have signal. In other situations even that will be undesirable. I'm aware of at least one regular office building here that has extremely poor wireless (802.11b) reception through real walls. No idea how that was established, however, though I do believe it was done on purpose, and from Andy's story it seems as though it wouldn't have been enough anyway. Regards, -- Niels.
Cox.Net Contact
If there is a Cox.Net contact on this list please contact me off-list. I have an issue where I cannot get to my MCI IPs from Cox's backbone. Thanks! Andy Ellifson
SBC BGP Eng pls contact
Need to talk to a BGP person at SBC, issue with routes between SPRINT and SBC in DFW area. called number listed at puck, person that answered doesn't have access to those routers, would have somone call back, its been 4+ hours... multiple providers can't reach 170.49/16 from NM please reply off list. thank you
peer routing issue between SBC and SPRINT in DFW??
seems there is an issue with SPRINT and SBC out of DFW SBC NS's are unreachable... Sprint says there is no problem with their gw-39 router. SBC NOC/NRC refused to assist because we aren't their customer. SBC's customer (BN Railroad) hasn't had any luck thru the normal customer support channels seems to be a return path issue from the router pasted sl-gw39, which according to SPRINT is the SBC router sbcbackbone.net is unreachable as well anyone around from SBC with enable to check routing?? mucho thanks traceroute to 151.164.1.1 (151.164.1.1), 64 hops max, 40 byte packets 1 rt01 (216.223.236.225) 1.049 ms 0.992 ms 0.899 ms 2 as10480.fa0-0-0-v-2.co.rt01.ixnm.net (63.170.28.137) 1.237 ms 1.024 ms 0.898 ms 3 sl-gw37-fw-0-0-TS7.sprintlink.net (160.81.60.57) 19.983 ms 16.596 ms 16.625 ms 4 sl-bb22-fw-4-0.sprintlink.net (144.232.11.169) 30.996 ms 16.957 ms 16.749 ms 5 sl-bb26-fw-11-0.sprintlink.net (144.232.11.30) 17.068 ms 17.299 ms 18.230 ms 6 sl-gw39-fw-0-0.sprintlink.net (144.232.11.61) 17.254 ms 16.786 ms 17.967 ms 7 * * * 8 * * * 9 * * * 10 * * * traceroute to 170.49.49.66 (170.49.49.66), 64 hops max, 40 byte packets 1 rt01 (216.223.236.225) 1.049 ms 0.992 ms 0.899 ms 2 as10480.fa0-0-0-v-2.co.rt01.ixnm.net (63.170.28.137) 1.237 ms 1.024 ms 0.898 ms 3 sl-gw37-fw-0-0-TS7.sprintlink.net (160.81.60.57) 19.983 ms 16.596 ms 16.625 ms 4 sl-bb22-fw-4-0.sprintlink.net (144.232.11.169) 30.996 ms 16.957 ms 16.749 ms 5 sl-bb26-fw-11-0.sprintlink.net (144.232.11.30) 17.068 ms 17.299 ms 18.230 ms 6 sl-gw39-fw-0-0.sprintlink.net (144.232.11.61) 17.254 ms 16.786 ms 17.967 ms 7 * * * 8 * * * 9 * * * 10 * * *
resolved Re: peer routing issue between SBC and SPRINT in DFW??
Thanks to Tom S at SBC for fixing the issue... john brown On Wed, Nov 26, 2003 at 03:50:17PM -0700, John Brown (CV) wrote: seems there is an issue with SPRINT and SBC out of DFW SBC NS's are unreachable... Sprint says there is no problem with their gw-39 router. SBC NOC/NRC refused to assist because we aren't their customer. SBC's customer (BN Railroad) hasn't had any luck thru the normal customer support channels seems to be a return path issue from the router pasted sl-gw39, which according to SPRINT is the SBC router sbcbackbone.net is unreachable as well anyone around from SBC with enable to check routing?? mucho thanks traceroute to 151.164.1.1 (151.164.1.1), 64 hops max, 40 byte packets 1 rt01 (216.223.236.225) 1.049 ms 0.992 ms 0.899 ms 2 as10480.fa0-0-0-v-2.co.rt01.ixnm.net (63.170.28.137) 1.237 ms 1.024 ms 0.898 ms 3 sl-gw37-fw-0-0-TS7.sprintlink.net (160.81.60.57) 19.983 ms 16.596 ms 16.625 ms 4 sl-bb22-fw-4-0.sprintlink.net (144.232.11.169) 30.996 ms 16.957 ms 16.749 ms 5 sl-bb26-fw-11-0.sprintlink.net (144.232.11.30) 17.068 ms 17.299 ms 18.230 ms 6 sl-gw39-fw-0-0.sprintlink.net (144.232.11.61) 17.254 ms 16.786 ms 17.967 ms 7 * * * 8 * * * 9 * * * 10 * * * traceroute to 170.49.49.66 (170.49.49.66), 64 hops max, 40 byte packets 1 rt01 (216.223.236.225) 1.049 ms 0.992 ms 0.899 ms 2 as10480.fa0-0-0-v-2.co.rt01.ixnm.net (63.170.28.137) 1.237 ms 1.024 ms 0.898 ms 3 sl-gw37-fw-0-0-TS7.sprintlink.net (160.81.60.57) 19.983 ms 16.596 ms 16.625 ms 4 sl-bb22-fw-4-0.sprintlink.net (144.232.11.169) 30.996 ms 16.957 ms 16.749 ms 5 sl-bb26-fw-11-0.sprintlink.net (144.232.11.30) 17.068 ms 17.299 ms 18.230 ms 6 sl-gw39-fw-0-0.sprintlink.net (144.232.11.61) 17.254 ms 16.786 ms 17.967 ms 7 * * * 8 * * * 9 * * * 10 * * *
Re: peer routing issue between SBC and SPRINT in DFW??
Hi John, I just chatted with someone in the SBCIS NRC and discovered the situation has been resolved. There was a loop in Dallas and they did escalate properly resolved it within an hour of notification. Not bad for 6 pm on the eve of a national holiday G BTW, http://www.sbcbackbone.net is working, confirmed from three other peer networks. Enjoy your turkey day tomorrow! Cheers, -ren At 03:50 PM 11/26/2003 -0700, John Brown (CV) wrote: seems there is an issue with SPRINT and SBC out of DFW SBC NS's are unreachable... Sprint says there is no problem with their gw-39 router. SBC NOC/NRC refused to assist because we aren't their customer. SBC's customer (BN Railroad) hasn't had any luck thru the normal customer support channels seems to be a return path issue from the router pasted sl-gw39, which according to SPRINT is the SBC router sbcbackbone.net is unreachable as well anyone around from SBC with enable to check routing?? mucho thanks traceroute to 151.164.1.1 (151.164.1.1), 64 hops max, 40 byte packets 1 rt01 (216.223.236.225) 1.049 ms 0.992 ms 0.899 ms 2 as10480.fa0-0-0-v-2.co.rt01.ixnm.net (63.170.28.137) 1.237 ms 1.024 ms 0.898 ms 3 sl-gw37-fw-0-0-TS7.sprintlink.net (160.81.60.57) 19.983 ms 16.596 ms 16.625 ms 4 sl-bb22-fw-4-0.sprintlink.net (144.232.11.169) 30.996 ms 16.957 ms 16.749 ms 5 sl-bb26-fw-11-0.sprintlink.net (144.232.11.30) 17.068 ms 17.299 ms 18.230 ms 6 sl-gw39-fw-0-0.sprintlink.net (144.232.11.61) 17.254 ms 16.786 ms 17.967 ms 7 * * * 8 * * * 9 * * * 10 * * * traceroute to 170.49.49.66 (170.49.49.66), 64 hops max, 40 byte packets 1 rt01 (216.223.236.225) 1.049 ms 0.992 ms 0.899 ms 2 as10480.fa0-0-0-v-2.co.rt01.ixnm.net (63.170.28.137) 1.237 ms 1.024 ms 0.898 ms 3 sl-gw37-fw-0-0-TS7.sprintlink.net (160.81.60.57) 19.983 ms 16.596 ms 16.625 ms 4 sl-bb22-fw-4-0.sprintlink.net (144.232.11.169) 30.996 ms 16.957 ms 16.749 ms 5 sl-bb26-fw-11-0.sprintlink.net (144.232.11.30) 17.068 ms 17.299 ms 18.230 ms 6 sl-gw39-fw-0-0.sprintlink.net (144.232.11.61) 17.254 ms 16.786 ms 17.967 ms 7 * * * 8 * * * 9 * * * 10 * * *
Re: WLAN shielding
Speaking on Deep Background, the Press Secretary whispered: My company is investigating the use of wireless in a couple of our conference rooms. Aside from limiting the scope of reception with various directional antennae, does anyone have any suggestions or pointers for other ways to limit the propagation of signals (i.e. special shielding paint, panels or other wall coatings)? As I told Andy, you need a RayProof or similar brand shielded conference room. This is Faraday Cage, with a tight-fighting door, etc. I don't know what they cost, but I've installed one or 2. Outside of labor, I suppose they might be in the $50-500K range or so, for small (12'x6') ones. Note it's a PITA to keep tight; as the door needs very tight-fitting gaskets. You'll need to bring phone/Ethernet in over fiber, but that's not hard. -- A host is a host from coast to [EMAIL PROTECTED] no one will talk to a host that's close[v].(301) 56-LINUX Unless the host (that isn't close).pob 1433 is busy, hung or dead20915-1433
Re: WLAN shielding
On Wed, 26 Nov 2003, David Lesher wrote: Speaking on Deep Background, the Press Secretary whispered: My company is investigating the use of wireless in a couple of our conference rooms. Aside from limiting the scope of reception with various directional antennae, does anyone have any suggestions or pointers for other ways to limit the propagation of signals (i.e. special shielding paint, panels or other wall coatings)? As I told Andy, you need a RayProof or similar brand shielded conference room. This is Faraday Cage, with a tight-fighting door, etc. Uhm, dumb question. If it is that important, why are you using wireless at all? Why not install a cheap switch/hub in the middle of the conference table and let people plug a patch cord from the hub to their laptops? Stupid pen-test tricks, instead of using an expensive WiFi scanner and cracking WEP; often you can collect better intelligence with a radio turned to the frequency used by wireless lapel mics used by executives during briefings.
