Alex - When I have seen packet loss between two providers peering across the various shared medium FDDI interconnects, it has almost always been due to one or more of the following situations : - Network A has congested pipe(s) into the L2 thing. - Network B has congested pipe(s) into the L2 thing. - Network A has congested pipe(s) to the rest of their network. - Network B has congested pipe(s) to the rest of their network. - The peering session between Network A and Network B is traversing the network of FDDI switches at the IX, as the networks are not peering across a FDDI switch that they have in common, and the links are congested. The above situations are mostly correctable, assuming : - Additional FDDI ports are available. - Additional capacity to their network is obtainable. Other things one can do : - FD-FDDI - Peering session can be moved to a FDDI switch that the two networks have in common. Don't get me wrong-- certainly one should explore means of interconnecting beyond the shared medium FDDI option. The various ATM public peering services seem a viable way of scaling public peering as it exists today... while also affording a network the opportunity to put "private [atm-vc] peering" on their marketing web pages. ;) This is my personal observation- hope it helps. - jsb
Does anyone care about trying to get packet loss over MAE-East reduced any more? Some peers have quite heavy packet loss to them from where I'm sitting, and have done for a good while. It seems to me it's not a problem with my port, and I don't think I have head of line blocking problems, which means it's either a Gigaswitch problem, or their ports are simply full. Does anyone still hassle Worldcom and peers about this or have we lost hope of ever getting it fixed (i.e. people peer privately or hope other exchange points or a replacement will come along).
-- Alex Bligh GX Networks (formerly Xara Networks)
On Wed, Aug 19, 1998 at 05:35:57PM -0400, Jeff Barrows wrote:
- The peering session between Network A and Network B is traversing the network of FDDI switches at the IX, as the networks are not peering across a FDDI switch that they have in common, and the links are congested.
Other things one can do :
- Peering session can be moved to a FDDI switch that the two networks have in common.
The others, as you've observed are reasonably fixable problems, given inclination, but this last problem is non-trivial to fix, because of the physically distributed nature of some interconnects. I'm not yet certain as to whether ATM replacement of FDDI is the right solution to this problem. -dorian
I'm not yet certain as to whether ATM replacement of FDDI is the right solution to this problem.
-dorian
Denial, it's not just a river in Africa....... :\ (I know, it is *not* that cut and dry, but I couldn't resist ;) My two cents..... The ATM exchanges/naps, while certainly not as taxed as MAEE, are presenting me with better paths.... ATM's ability to isolate damage to the individual that has oversubscribed seems to scale... It seems the philosophy: "If I oversubsribe, I make more money, yet trash my neighbors paths, as well as mine" doesn't produce the altruistic behavior one might expect.... However, "If I oversubscribe, I trash MYSELF and ANYONE trying to get to ME, and no one else" seems to work somewhat better..... *Pure* communism was a great ideaology! However, its failure, for the most part, was cited as "not accounting for human nature" Go figure :\ Not that this will help if it is NAP trunks that are saturated, but, production capable OC12 and up interfaces, do. And don't forget, most carrier class switches have *non-blocking* backplanes..... :) At least that puts the solution back into *your* hands.... I, for one, have an 0C3-C awaiting your descision. (And a religion ;)
The above situations are mostly correctable, assuming :
- Additional FDDI ports are available.
Which they are NOT at Mae-east. aaggh (Has anyone got a spare one that they could transfer to us ?) - We run multiple ethernets at the moment .. Richard -- Richard Almeida email: rpa@insnet.net Technical Director phone: +44 181 239 5000 Internet Network Services Ltd fax: +44 181 239 5001 The Education Exchange Ltd (EDEX) mobile: /dev/null
participants (4)
-
Dorian Kim
-
Jeff Barrows
-
Richard Irving
-
rpaļ¼ insnet.net