how-to block ads
|
Carl F
@speakeasy.n
| reply to KatOak
Re: Packet Loss/Latency Reports
Hi koitsu -
Is the motive to move to Juniper just cost? Or does software controlled routing mean that Juniper boxes offer ISPs many more options for traffic management policies?
Flexibility is usually expensive to implement in hardware, but cheap and easy in software, especially if the software architecture is partitioned into appropriate abstractions. The knobs will be cool and will all function as advertised, as long as the performance demands don't exceed operating limits, BEYOND WHICH the exception detection, propagation and handling elements of the software's architecture had better be pretty robust, or else there will be a constant refrain of, "I've fallen down and I can't get up." 
Maybe the problem isn't just that Juniper equipment offers less head room because of what it does in software rather than in hardware. Maybe the problem is also that SpeakEasy is experimenting with new capabilities in the Juniper system, or worse, sold premium bandwidth on the assumption that they could implement new policies in the new equipment, either without onerous side-effects, or that they could do adequate spin-control on whatever side-effects they anticipated... Maybe SpeakEasy bought a lemon, and is now stuck convincing the world that there must be something wrong with us if we're not happy being served lemonade.
Am I just blowing smoke here? Does anyone know enough about the flavors of traffic management policy that Juniper equipment offers on paper, even if some of them don't work as advertised?
Cheers,
Carl F. | |
paulhaskew
Unoffical Dominos Spokesman
join:2002-01-10
Vancouver, WA
clubs: | reply to KatOak
this issue/thread has been going on how long????
service rating keeps dropping... | |
koitsu
Premium
join:2002-07-16
Mountain View, CA
| reply to Carl F
Junipers are essentially FreeBSD-based routers, to put it lightly. Their interface cards do some CPU offloading (duh), but not as much as the Cisco cards do. For example, at the time of my experiences with Junipers (2001 or so), their top-of-the-line advertised "backbone router" (model number I forget, sorry) was running off a Pentium II 450MHz CPU. This was what they felt was suiting for a backbone router -- and not a border router, mind you.
Story time!
We experienced "Juniper stupidity" the instant a host on our network (just for documentation purposes, an EFnet-based IRC hub) got DDoS'd (the uplink was an OC48, the pps count was essentially that of an OC3). That top-of-the-line Juniper turned into hunk of junk in a matter of seconds -- dropping packets, and doing weird things like packet forwards not getting executed (?!) and things of that nature. It affected the ENTIRE facility -- which sported over 70 racks of co-location customers as well as technical support and sales departments. Our Cisco would get slow and start to chunk a little bit, but it wouldn't die/malfunction.
Some of us SAs started poking fun at the Juniper with some tools we had, just to see what could effectively kill it. We found that a simple 10mbit half-duplex Ethernet connection, running smurf (an extremely ancient DoS method), could literally bring that Juniper to a stand-still. Yes, you read that right; 8-9mbit/s of broadcast traffic could totally bring down Juniper's top-of-the-line badboy.
We discussed this our immediate networking department (since Verio's NOC refused to discuss any networking details with us for reasons unknown to my manager as well as my manager's manager), who basically said "the Ciscos held up because they do hardware-level routing. Most of the packet switching and filters are done via dedicated ICs; the Junipers offload most of this onto the CPU. They can't handle heavy loads as well."
The advantages to the Juniper were that the interface for administrators was a lot more streamlined (the command-line interface is essentially UNIX), and navigation is easier. Things are lot more dynamic (which I realise sounds pretty "buzzword-ish" coming from me, but it's hard to explain); sure, IOS is that way as well, but IOS relies extensively on the applicable hardware working how it should (i.e. any sort-of fault and IOS says "GAH!" and reloads the entire config). The Junipers permitted the NOC folk to deploy filters and access lists a lot more quickly and reliably, plus be able to get more detailed information from the unit as to what was going on during packet storms and things of that nature.
Each company has their reasons for going to Juniper. I think the three big ones are the following
1) Lower cost of ownership / maintenance
2) Easier to maintain / administrate
3) Tired of dealing with Cisco hardware and/or IOS bugs
Most of the time, these are the reasons I see people moving to Junipers. You'd have to point out all of this over in the Advanced Networking forum -- although, I think the guys there would probably jump all over me for some of my statements (I'm not a network administrator! Go easy on me, guys!).
I have absolutely *NO* problem with SE using Juniper equipment (other than the fact that I hate Junipers ). If they want to go down that path, all power to them. However, when it comes to deploying something like that, I URGE them to do what's called TESTING. Send out an Email to some customers in each region deployment is planned for, and ask them if they'd like to be guinea pigs for new routing equipment/new network topologies. Don't deploy it and then be like "BUT IT'S GREAT!". TEST things first. Users who would become guinea pigs could provide feedback.
IMPORTANT: The problem at hand with SE might not have ANYTHING to do with Juniper equipment! It might be something else; I have no idea. But when Kat says the equipment is oversaturated in regards to how many pps (packets per second) the equipment can push out, the first thing I think of is their Junipers. Software routing, ugh.
--
Making life hard for others since 1977. | |
davec22
join:2003-09-27
Chestnut Hill, MA
| reply to KatOak
Hi:
I have been a customer of Speakeasy’s since January 2000. My legacy SDSL 384/128 service typically runs in the 300’s in both directions. I am connected to the Boston POP, and my setup is a SpeedStream 5250 bridge attached to a Linksys WAP Router configured with a static IP. I have 3 PC’s networked, 2 Win98 SE’s using Cat 5 cable and 1 XP Pro laptop using WiFi. For the first 3 ½ years, I was as happy as any SE customer could be…maybe a few hours of downtime in several years, just a handful of trouble tix, and plenty of help from tech support when needed. I touted my Speakeasy DSL service as awesome to anyone who would listen.
In early August 2003, I started to experience intermittent outages. First, my connection was more up than down, then it was more down then up. The bridge lights would go from 4 green to the retraining cycles, typically not successfully retraining. I opened a trouble ticket, a few days later the problem disappeared, so I closed the ticket.
A few days after that, the problem reappeared (intermittently more down than up), so I opened a second trouble ticket and began working with advance tech Jesse x248. We went through the litany of tests…swapping out cables, doing the on the phone testing with Covad, etc. We had Verizon come out and check the box on the side of my house as well as the connection at the pole 600 ft. off of the house. All was deemed fine, and Jesse fed me the “it’s either your inside wiring or your bridge is failing” line. I believed him and was either going to a) upgrade to ADSL with a Covad Pro Install to get new equipment, a NID filter, and my wires checked, b) buy a new bridge and stick with the service I have, or c) (heaven forbid) switch to Verizon DSL or Comcast.
Before I could decide which way to go (leaning towards a), of course), the problem disappeared. I closed the ticket and life was grand again thru much of September. Then, late this week (Th 9/25), the problems began again, this time with a new symptom. Not only did the bridge keep retraining unsuccessfully, but for most of Thursday and part of Friday, the 4 lights were green, but I seemingly had no connection at all.
I stumbled upon this thread on Friday, and after reading it, it seems that my problems aren’t really my own. If I read this stuff correctly, all of you seem to be having similar ones. Is it the hurricane, the blackout, the worms, or what? I believed Jesse until I saw that the same “it’s your problem” line has been fed to others.
Of course, by Friday night and all of today (Sat), my connection is up and humming as it should be. So, my questions are:
1) Do I have the same problem as all of you, or am I really missing the boat here and I have a different problem? Could it truly be my wiring or my bridge?
2) Can someone point me to a FAQ re: ping plotter, etc.? I run the bos.speakeasy.net speed test, but haven’t tested any of the other stuff you guys are throwing around on this thread. What else should I be looking at, if anything?
3) Should I upgrade or switch ISP’s? Based on what I read in this forum and the VOL forum, the intermittent problems are not going to disappear if I upgrade or switch. You guys all refer to packet loss, ping times, etc…is that the same thing as my intermittent problems?
4) I am a little leery of upgrading to ADSL and the relating “line sharing”. I like the fact that my SDSL is on a separate pair of copper wires than my dial tone. Other than giving me more download speed for the same $$, what’s the benefit to me of upgrading? My 384 is fast enough for what I do (no gaming, little to no FTP, etc. – just surfing, streaming music and emailing mostly) when it is humming.
5) How else can I make this problem go away so that I can go back to being the happily satisfied, always connected SE customer that I once was?
Any thoughts or input any of you (including Kat!!) can provide would be much appreciated.
Thanks,
Dave C. | |
koitsu
Premium
join:2002-07-16
Mountain View, CA
| Dave,
Your problem definitely sounds unrelated to this thread. This thread is discussing problems with Speakeasy IP network reliability and not DSL-related issues. Your issue definitely sounds DSL-related, especially if you were losing sync. I'd ask for noise margins to be provided (you can ask for this on the Covad forum if you have your Covad Circuit ID #), as well as ask Speakeasy to have Covad run an MLT test (which will report back the physical electrical distance between you and your Central Office (Verizon)).
Hope this helps, but please remember this thread is for IP networking issues (packet loss, primarily). 
--
Making life hard for others since 1977. | |
scooby
Premium
join:2001-05-01
Schaumburg, IL
| reply to koitsu
said by koitsu  :
IMPORTANT: The problem at hand with SE might not have ANYTHING to do with Juniper equipment! It might be something else; I have no idea. But when Kat says the equipment is oversaturated in regards to how many pps (packets per second) the equipment can push out, the first thing I think of is their Junipers. Software routing, ugh.
Either you were using a beta product or one of their 'lollypops'. Juniper used to let you have the OS to install on a pc to play with so you could teach people how they work without using a router that was in production.
Junipers are complete hardware routers. Whoever told you they were software routers was incorrect. There is no way you could push the following amount of data through a software router.
M5 - 3.2-Gbps full duplex (6.4 Gbps total)
M10 - 6.4-Gbps full duplex (12.8 Gbps total)
M20 - 12.8-Gbps full duplex (25.6 Gbps total)
M40 - 25.6-Gbps full duplex (51.2 Gbps total)
and the processor in each can handle 40 million packets per second.
Oh and btw, a very common router used at ISPs the Cisco 7513 spec'd to the max only handles .5 million packets per second.
[text was edited by author 2003-09-27 23:47:56] | |
macmouse
Premium
join:2002-05-30
Saratoga, CA
| reply to koitsu
For whatever its worth on speakeasy's site (system status) it looks like they now officially saying there is an problem. (Or at least, its on their page instead of just in this forum.) Its for SEA,NYC and CHI. Message identical except for city names. Adjust as necessary
09/26/03 02:18:07 PM Seattle POP Packet Loss
Region : Seattle
E.T.A. : (none)
Services Affected : Some broadband services
We are presently seeing packet loss on one of our Seattle POP’s backhaul circuits caused by an unexpected increase in traffic caused by Internet worms. We will be fully upgrading this POP within the next few months and are presently investigating interim solutions to these packet loss issues. | |
paulhaskew
Unoffical Dominos Spokesman
join:2002-01-10
Vancouver, WA
clubs:
|  reply to KatOak
sorry folks, looks like its wait till it gets done
[text was edited by author 2003-09-28 00:55:53] | |
koitsu
Premium
join:2002-07-16
Mountain View, CA
| reply to scooby
Interesting post, scooby. I've taken up the details with you in private, but the Juniper in question was an M40 (I provided pictures so you can see that I'm not talking out my rear ).
It's likely that the unit was misconfigured, and it's highly likely that they're _still_ misconfigured. I no longer work there (thanks for laying off 85% of your work force, Verio!), but I still occasionally see "Verio networking madness," especially since InterNAP has a peering link with Verio.
Thanks for clearing up the software vs. hardware issue as well. The individuals who told me they were software-based was one of the Verio network administrators I knew, which may explain how and why the units were misconfigured.
Either way, thanks for stepping in and saying something. *thumbs up*
--
Making life hard for others since 1977. | |
koitsu
Premium
join:2002-07-16
Mountain View, CA
| reply to KatOak
Switched back over to the ADSL line at 08:45 this morning. By 13:00 it was unusable due to the infamous "socket stalling" problem. It's now 18:01 and the problem is quite apparent.
Back to the cable modem.
--
Making life hard for others since 1977. | |
Yourself
join:2000-08-10
Lynnwood, WA
| reply to macmouse
said by macmouse :
For whatever its worth on speakeasy's site (system status) it looks like they now officially saying there is an problem. (Or at least, its on their page instead of just in this forum.) Its for SEA,NYC and CHI. Message identical except for city names. Adjust as necessary
09/26/03 02:18:07 PM Seattle POP Packet Loss
Region : Seattle
E.T.A. : (none)
Services Affected : Some broadband services
We are presently seeing packet loss on one of our Seattle POP’s backhaul circuits caused by an unexpected increase in traffic caused by Internet worms. We will be fully upgrading this POP within the next few months and are presently investigating interim solutions to these packet loss issues.
I'm going on 6 weeks and counting with a worthless connection(gaming). I wonder how long it's going to take to "investigate" and find an interim fix before the POP upgrade. sigh...:( | |
sh0V3L
join:2002-02-16
San Carlos, CA
| reply to KatOak
i dont know what to say i geuss a picture is worth a 1000 words
the battle for a decent connection continues of course they say my connections fine @##%&$!!!!!!!!
[text was edited by author 2003-10-01 12:41:53] | |
Yourself
join:2000-08-10
Lynnwood, WA | Lol...they closed my trouble ticket saying it was resolved. I get the same PL and I also have serious circuit issue thats brought my speedtest down to 352/33. Yet, my ticket shows "resolved"...
Self | |
sh0V3L
join:2002-02-16
San Carlos, CA
| reply to sh0V3L
Ok now 5 mins later it clears up so i stress test a lil by pinging epic with 1472 byte packets :
Microsoft Windows 2000 [Version 5.00.2195]
(C) Copyright 1985-2000 Microsoft Corp.
C:\>ping www.epicgames.com -t -l 1472
Pinging www.epicgames.com [207.135.145.4] with 1472 bytes of data:
Reply from 207.135.145.4: bytes=1472 time=80ms TTL=117
Reply from 207.135.145.4: bytes=1472 time=70ms TTL=117
Ping statistics for 207.135.145.4:
Packets: Sent = 199, Received = 199, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 70ms, Maximum = 90ms, Average = 71ms
Control-C
This Instability should not be a charicteristic of an sdsl circuit and they need to address this issue as it has not gone away by itself ive been backhauled depro repro diff ips nothing changes the internitant instabilty and of course it wont do it when im on the phone with them and pipj can kiss my ass my personal account mngr wtf it was so much better service /tech support before they started the personal account mngr BS. IMHO speakeasy has changed they have become the attbi/comcast of the dsl market i feel for kat being stuck in this she used to be able to get things done for ppl but now it appears she just cant do the things as before , must be the new ceo of course this just my opinion
the above jpeg shows they can do sdsl right but why cant they do stability also ? i have had an open ticket for over a month i refuse to close it until this is stable and will continue to request credit for services not recieved | |
|
