Ok, here's my current state of understanding:
*Question is related to what R1 sees as pvc info.
This is transferred via LMI and AFAIK there is no way to filter
it, so only chance is to disable it at R1-FRsw, if that's possible.
*Routers as DTEs can disable LMI and work, no problem
*LMI transfers not only DLCI availability but also other end status
*If you disable LMI at one DTE, the other will see remote as inactive
and will not TX over the main interface.
(It will, though, tx over a subinterface even if main is UP/down because
of remote inactive!)
*Cisco's implementation of frame relay switch will not transfer data
over a DLCI that has both ends with LMI and it's inactive!
It makes sense, given that both ends know or are supposed to know that
the link is inoperative.
*Cisco's implementation of frame relay switch *will* transfer data over
a DLCI that has one end with no LMI regardless of the status of a
possibly managed end.
And that surprised me a little.
But then, if the frame relay switch is cisco, I would say that the
problem has no solution w/o touching the frame relay config.
Sorry about the emotions that entered the thread, I'll *try* not to do
that again.
-Carlos
selamat pagi @ 25/8/2010 15:07 -0300 dixit:
> I know this has been discussed several times here, but I still don't
> have/understand the solution.
> If there is none, I just will believe it and can continue with something
> more interesting :-)
>
> QUESTION:
> Is there a way to avoid that the FR-switch responds with all the DLCI
> configured ?
> So we will only see our configured PVC in the output of "sh frame-relay
> pvc"
>
> (assumed the FR-switch config cannot be changed ;-)
>
> I played around with keepalive and lmi-n391dte-values, however the type 0 I
> don't get rid of ..?
>
> thanks, keti
-- Carlos G Mendioroz <tron_at_huapi.ba.ar> LW7 EQI Argentina Blogs and organic groups at http://www.ccie.netReceived on Fri Aug 27 2010 - 11:08:43 ART
This archive was generated by hypermail 2.2.0 : Wed Sep 01 2010 - 11:20:53 ART