Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!ucbvax!JESSICA.STANFORD.EDU!almquist
From: almquist@JESSICA.STANFORD.EDU (Philip Almquist)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: EGP and C-30s
Message-ID: <8906121813.AA12143@ucbvax.Berkeley.EDU>
Date: 12 Jun 89 16:22:00 GMT
References: <brescia@BBN.COM>
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 35

Mike,
>     We're installing cisco MGS gateways at different sites on Milnet and 
>     occasionally a problem crops up with exchanging EGP updates with the
>     "new" core buttergates.  Essentially there seems to be an infinite 
>     cycling up and down between the gateways with the core never sending an 
>     update.
>
>     This gones on until the PSN (C-30) is reset, at which point updates from
>     the core begin coming in.
>     ... nothing except resetting the PSN seems tp work.
>
> This sounds like an X.25 type of problem, involving x.25 window size, x.25
> packet size, and resources in the local PSN.

	This same problem (or at least a very similar one) can occur in
1822-connected gateways, or at least it could when Stanford lost its PSN
connection in March.  At the time, cisco looked at it and Steve Atlas
put in some patches into the Butterflies to make them work properly in
passive mode, but the problem was still unsolved when the PSN's plug got
pulled.

						Philip

PS: It seems that even when things are "working" that EGP connectivity
    between ciscos and Butterflies is not as robust as one might like.
    I observe in the SRI ARPANet gateway this morning:

		neighbor      uptime     j/k
		----------------------------
		10.6.0.22       2:08       3
		10.2.0.68       2:46       2

    Ideally, one would hope that the uptime of the peer relationships
    would be roughtly equal to the uptime of the gateway (ie, 2 weeks
    instead of 2 hours) and that j/k = 4.