Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
New Member

"frame-relay map ip" and "interface-dlci" allowed both?

Hi,

we are using a configuration with a "frame-relay map" combined with a "frame-relay interface-dlci" on the major interface as back-to-back-configuration. (saving unneeded sub-ifs - avoids to big MRTG-cfg)

interface Serial0/0

ip address 10.21.255.26 255.255.255.252

encapsulation frame-relay IETF

frame-relay traffic-shaping

frame-relay map ip 10.21.255.25 16

frame-relay interface-dlci 16

class 384k

frame-relay lmi-type q933a

We now got a problem with a C2612 and 12.3.1a. If we ping from over the FrameRelay-Link to a target on the tokenring, we only get about half of the requests answered back over the frame-relay-pvc. A extended ping done from the router itself is answered correctly.

Now I have made a sub-if-config on this router and everything is fine (see below)

interface Serial0/0

encapsulation frame-relay IETF

frame-relay traffic-shaping

frame-relay lmi-type q933a

!

interface Serial0/0.1 point-to-point

ip address 10.21.255.26 255.255.255.252

frame-relay class 384k

frame-relay interface-dlci 16

Anybody who knows what we did wrong or if this is a bug?

Regards,

Chris

6 REPLIES
Bronze

Re: "frame-relay map ip" and "interface-dlci" allowed both?

Chris,

The "frame-relay interface dlci" command is not necessary on the physical interface because a DLCI is assigned to the physical interface by default. The command is used to assign a DLCI to a sub-interface. I don't know if this would explain the poor performance, however. Try the original configuration without the frame-relay interface DLCI command and see how it works.

HTH

Mark

New Member

Re: "frame-relay map ip" and "interface-dlci" allowed both?

The "frame-relay interface-dlci"-command was used from my colleague to specify a map-class with qos.

I am not sure if there is also a solution if only "frame-relay map ip" is configured?

Regards,

Chris

Re: "frame-relay map ip" and "interface-dlci" allowed both?

FR map statements are generally used in point-to-multipoint scenarios, whereas "intf-dlci" is used when you use a point-to-point..

In your case, you are doing a normal point to point connection.. use only the interface-dlci command and take off the frame-relay map command on the previous configuration...

Also let us know the routing you are doing.. the packet drops might be due to improper routing too..

If you are able to ping 10.21.255.25 (FR interface of the other end), you dont have problems with FR configurations..

give us some info on this..

New Member

Re: "frame-relay map ip" and "interface-dlci" allowed both?

Hi,

there is static routing only and the error only happens if you ping anything on the tokenring. A ping to any ip-address on the router itself does not make any problem. And also the same configuration with ethernet interfaces works.

If we change the FR-configuration to sub-if it works without any problems (without any ip routing change).

So I think this is a bug concerning tokenring and our little strange frame-relay configuration.

Regards,

Chris

Re: "frame-relay map ip" and "interface-dlci" allowed both?

Strange !!!!

The FR connectivity is only upto the other end router(even if you put sub-interface on your end router). No way it can affect the performance to any other interface in that router.

What is the configuration on the remote end ? is it also in normal interface or in sub-interface ?

Strange anyway !!!

New Member

Re: "frame-relay map ip" and "interface-dlci" allowed both?

Hi,

the "remote end" router (a cisco3640) is now running in the configuration without sub-if and it works. I am sitting on the "remote end"-router side.

Before removing the sub-ifs and getting problems, both ends were configured with subifs. Then we tried to remove the sub-ifs on both sides and we got problems. So we configured the subif again on the c2612/TR-router.

Configuring the sub-if on the C2612-router was enough to get the configuration running again.

It has not looked like any performance problem. Even if there is no other packets running we lost exactly every second packet if the target was on the tokenring. Sounds like any bug on the C2612-router.

Regards,

Chris

265
Views
0
Helpful
6
Replies
CreatePlease to create content