RE: Frame-relay interface-dlci command dependancy on physical

From: Serran (groupstudy@swiftdsl.com.au)
Date: Sat Mar 20 2004 - 08:47:36 GMT-3


Just playing around with configurable options.. part of ipexpert chapter 3.

btw, a frame-relay interface-dlci command is not required on a physical
intf... all you need are static maps.

so my question is why is there a dependancy on this actual command
"frame-relay interface-dlci [dlci]" on a physical interface after this
command has been added after static maps. You cannot do a "no frame-relay
interface-dlci [dlci]" without first removing the static maps.

cheers
Serran

-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
SANCHEZ-MONGE,ANTONIO (HP-France,ex2)
Sent: Saturday, 20 March 2004 10:40 PM
To: 'Serran'; Ccielab@Groupstudy. Com
Subject: RE: Frame-relay interface-dlci command dependancy on physical
int erfaces

Hi Serran,

A map statement binds a DLCI to an interface, regardless whether it is the
physical or a subinterface.

Why do you want to delete a DLCI referenced by a map? Maybe you want to add
the map to the subinterface?

Cheers,
Ato.

-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Serran
Sent: sabado, 20 de marzo de 2004 12:32
To: Ccielab@Groupstudy. Com
Subject: Frame-relay interface-dlci command dependancy on physical
interfaces

Hi All,

I understand the use of this command with ptp or ptmp sub intf's.. however
if I use this command on a physical intf (on a spoke router).. AND after I
have confirgured static maps, i cannot remove this command unless i have
removed the static maps first. The following IOS msg is parsed out:

R5(config-if)#no frame-relay interface-dlci 501
%Cannot remove PVC as being referenced by map statement R5(config-if)#

Is there any reason why the command seems to bind to the static maps when
not really required in the first place for a phy intf?

Thanks
Serran



This archive was generated by hypermail 2.1.4 : Thu Apr 01 2004 - 08:15:41 GMT-3