Klopoty z lacznoscia do USA (ciekawe info)

Autor: Jacek Piskozub (piskozub_at_iopan.gda.pl)
Data: Mon 20 Nov 1995 - 15:57:33 MET


[Powtorka z poprawnym polem Subject - przepraszam]

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