Autor: Jacek Piskozub (piskozub_at_iopan.gda.pl)
Data: Mon 20 Nov 1995 - 15:56:22 MET
Przegladalem ostatnio spis trouble-tickets glownego niemieckiego
wezla lacznosci (sa tamb. ciekawe statystyki lacznosci wewnatrz
oraz do i z Nemiec - polecam za wzor NASowi).
Gdyby kogos interesowalo: finger help_at_noc.dfn.de
Oto fragment 25kB kilo jednego z trouble-tickets [w wiekszosci po
niemiecku: dosc wazny kawalek jest jednak po angielsku]
Jest tam miedzy innymi o slynnym i w Posce pozeraczu pakietow
Mae-East. Cytuje i extenso:
=========================== poczatek cytatu
Dear colleagues,
(Please pass this message on to your management, where appropriate)
During the last weeks the general US connectivity suffered from
several
problems at the same time, which added up to quite bad performance
for some
of you. I will try to give a summary of the single problems here.
1.) Transatlantic line overload
Generally all our US lines have been and are still heavily loaded.
There is
only one proper solution to that, which is to order new bandwidth.
Currently 1 more T1 from the NL IBDNS PoP to New York is on order.
The line
is expected soon, but there are still problems on the NL side. The
countries to benefit from this upgrade will be ES, BE, GR, LU, SI.
We are
working on more upgrades here, but nothing has been ordered yet.
This is
more of a commercial question than a technical though.
2.) Problems on both New-York routers
New-York2.dante.net and to some extent New-York1.dante.net have
been
suffering from two problems:
a) SW problems with regard to buffering. Basically the T1s are
overloaded and packets got dropped in the FDDI buffer, which
caused initially the BGP sessions to drop. Later the FDDI
buffer
froze due to SW bugs, causing the FDDI to hang completely.
Cisco provided a workaround for these problems, such that
the buffer is reset after 20s inactivity... Whilst this is not
a
proper solution it should work for the time being.
b) HW problem on the FDDI card. This problem used to reset the
FDDI card several times a day. This is supposed to be cured
with
upgrading to a 7010. Availability is an issue here, of course.
Currently ANS is investigating the possibility of putting a 7010
there,
which will at least cure the HW problem (other chip there). The SW
problems
should at least not affect us that heavily any more. However, the
underlying problem is always the overload of the links, but a
bigger router
might be able to solve the problem. ANS is getting back to DANTE
later
today about the possibilities, meanwhile the matter was escalated
to Cisco
management which is treating this as a high-priority issue. DANTE
have
several times pointed out to ANS that we are not prepared to act as
guinea-pigs for Cisco in that matter.
3.) Hop count problems
Several regionals experience that their packets time out to some
destinations, because the number of hops is bigger than 32 in some
cases.
This has been first noted by SWITCH, after the change of US
connectivity. I
have checked with ANS if the routing is correct and/or if the path
to some
(mostly MCI destinations) can be shortened. But the path seems to
be
already the shortest possible.
Solutions here are firstly to change network topologies, which is
not an
easy matter for any network. I do not think this is feasible.
Secondly,
tunnels could be deployed. But at least on a backbone level this
does not
seem feasible due to performance problems. Nationally that might be
an
option. May I also remind here to the heavy opposition we had wrt a
"cloud
model" implemented by EMPB. We can discuss that at the APM meeting.
However, also this is not an easy solution. The third solution is
to
increase the TTL counters in the applications, which are currently
limited
in some cases (Microsoft) to 32 hops.
I want to make the general point here that I do not believe that
this is a
problem with the Internet (it is not one single provider to blame
anyway),
but rather a problem of the SW in use, which assumes arbitrarily
that the
Internet would never be bigger than 32 hops. The question is if one
should
adapt the Internet to Microsoft SW or if Microsoft SW should adapt
to the
Internet. The latter sounds more reasonable, I would think. I
propose that
all Internet service providers should take a firm view on that
issue when
dealing with customers.
4.) Topology in the US
I had a conversation with ANS to find out more about the topology
of ANSnet
from the point where our lines end (New York Uptown). New-york1 and
-2.dante.net peer with (enss32) over an otherwise unused FDDI. This
is a
backbone router, which holds two T3 (45M) of the ANSnet backbone.
In
addition there is another T3 to the Sprint NAP in Pensauken. None
of these
lines is overloaded, so that the performance within ANSnet should
be good
(note: according to ANS). There were a number of issues across
MAE-East
lately and connections which traversed the shared FDDI there might
have had
bad performance through that.
We will keep you up to date with regard to these issues. If you
have any
further questions, please let us know.
Michael Behringer
DANTE NMC
========================= koniec cytatu
Mam nadzieje, ze to rozjasni przynajmniej czesc tajemnicmarnego
polaczenia
do USA.
JP.
-- Jacek Piskozub Institute of Oceanology PAS, Sopot, Poland mailto:piskozub_at_iopan.gda.pl http://www.iopan.gda.pl/jacek.html
To archiwum zostało wygenerowane przez hypermail 2.1.7 : Wed 19 May 2004 - 15:53:34 MET DST