I've checked the CIR and we're doing fine there, especially since this is a
256k fractional t-1 running at about 1% utilization. Our circuits are not
policed, so even if we were above CIR, nothing gets dropped unless the frame
relay network became obscenely congested.
As I mentioned before, all other PVCs on this major interface work just fine
except one other that has the same symptoms. When I first brought up this
circuit, I was at the remote site with a laptop in the console port. Where
I first did "show cdp n", both neighbors were in the list, but after a
minute or two, one of them disappeared and has yet to return.
The line itself is functioning correctly, as far as I can tell. We're not
seeing any interface errors whatsoever and it's been up for a couple of
weeks, now. Perhaps I've found an IOS "feature." We're using 11.2(18). I
think I'll check CCO and see if they've noticed this in the past.
Thanks for all the help!
> ... m'tinks Ele'Chil' might be on to sumpin' here.... could you capture
the
> sho fr pvc / and sho fr map from both ends of the one NOT passing CDP
> traffic... and post them?
>
> .... yeah, this is of some interest to me too, but priscilla hit the
issue
> with the "broadcast" thread....
>
> .... think of all the mechanisms passing the various protocol encaps
here....
> inarp - what's the LPort doing? What's the CIR/BW? Util? When you do
> an extended ping with a bit pattern of 0x4040; 0xAAAA; & 0xFFFF with,
> say 150 itterations, what happens?
>
> R/
> Rainman
>
> ElephantChild wrote:
>
> > On Wed, 12 Jul 2000, John Neiberger wrote:
> >
> > > The PVC is working perfectly, except for CDP. It's configured
exactly like
> > > the 89 other subinterfaces on that major interface, so I doubt it's a
> > > configuration issue, but it still may be. The remote side has two
PVCs on
> > > one major interface and CDP is working on one subinterface only and
they,
> > > too, are configured exactly the same except for DLCI and IP address.
> >
> > Do you have problems with other broadcasts not making it on that (or
any
> > other) PVC? If you're not exceeding your CIR on that PVC (have you
> > checked that?), my guess is that the broadcast queue on the
> > (sub)interface gets full, or that some other queuing limit kicks in.
> >
> > > > Is it just CDP not working or is the whole PVC showing as
inactive?
> > > I've
> > > > seen where if LMI was configured incorrectly at the remote end
when the
> > > > router was first brought up it would come up but after a minute or
so go
> > > > down because it wasn't receiving lmi keepalives from the switch.
In this
> > > > case it was a telco switch problem and I do know that LMI is
supposed to
> > > be
> > > > autosensing with the newer software.
> > > >
> > > > If it is just CDP down I would have suggested something to do with
the
> > > > timers but you said the remote end isn't receiving any packets at
all?
> > > > Hmmm.
> > > >
> > > > -----Original Message-----
> > > > From: John Neiberger [mailto:[EMAIL PROTECTED]]
> > > > Subject: RE: CDP not working on subinterface
> > > >
> > > > We use entirely point-to-point subinterfaces, and we have no
special
> > > > configuration on them regarding broadcasts. On this particular
major
> > > > interface, there are 90 subinterfaces and CDP is working just fine
on all
> > > > but two of them. They all have identical configs except for the
DLCIs
> > > and
> > > > IP addresses. "show cdp int" shows that CDP packets are being
sent, but
> > > > they aren't being received at the opposite end, according to
"debug cdp
> > > > packets".
> > > >
> > > > Another oddity about this is that it worked correctly when I first
> > > brought
> > > > the circuit up for about a minute or so, and then it stopped.
Very
> > > > strange...
> > > >
> > > > > This is purely a guess.......
> > > > >
> > > > > Are you allowing broadcasts across the PVC by using the
broadcast
> > > keyword
> > > >
> > > > > on the frame-relay map command? CDP sends to a multicast
address.
> > > > >
> > > > > Priscilla
> > > > >
> > > > > At 08:50 PM 7/11/00, John Neiberger wrote:
> > > > > >No, I haven't done that, but I did "show cdp int" and the
router said
> > > > that
> > > > > >it was sending cdp packets out that interface. Both routers
on each
> > > end
> > > > of
> > > > > >the link reported this. I'll try debugging tomorrow.
> > > > > >
> > > > > >
> > > > > > > Did you run "debug cdp" to verify that it is being sent?
> > > > > > >
> > > > > > > Magnus Thorne
> > > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: John Neiberger [mailto:[EMAIL PROTECTED]]
> > > > > > > Subject: CDP not working on subinterface
> > > > > > >
> > > > > > > We do not have CDP disabled anywhere on our routers,
either
> > > globally
> > > > or
> > > > > >at
> > > > > > > the interface level. I brought up a new PVC today and at
the
> > > remote
> > > > side
> > > > > >I
> > > > > > > could see both PVCs to that router. After a few seconds,
though,
> > > > one of
> > > > > > > them disappeared from the "show cdp neighbors" output. No
> > > changes
> > > > were
> > > > > >made
> > > > > > > to configs at either side, it just did this on it's own.
This
> > > > particular
> > > > > > > PVC is terminating at a subinterface on both routers, and
other
> > > > > > > subinterfaces on the major interfaces at each end still
report
> > > their
> > > > cdp
> > > > > > > neighbors correctly; the problem is only on this
particular
> > > > > >subinterface.
> > > > > > >
> > > > > > > I have noticed this in the past with a different PVC, so
it's
> > > > happened at
> > > > > > > least twice in our network.
> > > > > > >
> > > > > > > any ideas why it works temporarily and then quits?
> >
> > --
> > Bungee jumping and skydiving are for wimps. If you want to experience
> > true gut-wrenching terror, have children. --Dusty Rhoades.
> >
> > ___________________________________
> > UPDATED Posting Guidelines: http://www.groupstudy.com/list/guide.html
> > FAQ, list archives, and subscription info: http://www.groupstudy.com
> > Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
>
_______________________________________________________
Say Bye to Slow Internet!
http://www.home.com/xinbox/signup.html
___________________________________
UPDATED Posting Guidelines: http://www.groupstudy.com/list/guide.html
FAQ, list archives, and subscription info: http://www.groupstudy.com
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
