Frame Relay End to End Keepalive Problem

Unanswered Question
Jun 6th, 2007

Hello Group,

I am facing problem regarding Frame Relay end to end keepalive feature. Problem which I am facing is that, in case of any problem in service provider's network the FR EEK at customer router becomes DOWN but the line protocol remain UP and due to this reason customer router doesn't install the backup route in its routing table. Below is the configuration of routers at 2 sites of a customer.

Router A:

(config)#interface serial 1/1

(config-if)#encapsulation frame-relay ietf

(config-if)# frame-relay class TEST

(config)# map-class frame-relay TEST

frame-relay end-to-end keepalive mode bidirectional

Router B:

(config)#interface serial 1/1

(config-if)# encapsulation frame-relay ietf

(config-if)frame-relay class TEST

(config)# map-class frame-relay TEST

(config)# frame-relay end-to-end keepalive mode bidirectional

Regards,

Mujeeb

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Paolo Bevilacqua Wed, 06/06/2007 - 10:08

Hello,

Please configure a subinterface point-to-point and apply the FR end-to-end keepalive configuration in there. The feature works sending packet on the PVC and if applied to the main interface won't know which PVC to use.

Hope this helps, please rate post if it does

rmujeeb81 Fri, 06/08/2007 - 06:42

Hello,

I had forwarded configuration of EEK in my last email as general conf. We have configured EEK on sub interface for one of our client where this feature is working fine but for another client its not working even we have configured EEK on sub interface. Strange thing which we observed is that EEK itself goes down but protocol at sub interface does not go down. Is this problem could be due to lmi type ??

Regards,

Mujeeb

Paolo Bevilacqua Fri, 06/08/2007 - 07:06

Hello,

FR EEK does not depends on LMI type, in fact it does not depends on LMI at all. To understand why is not working in some case, the full configuration and some show commands would be required.

As an alternative you can use an IP routing protocol that will be able to detect when an PVC is not carrying data.

Useful post? Please rate it using the scrollbox below!

rmujeeb81 Fri, 06/08/2007 - 21:20

Hello,

Thanks for your response.Yes one of the solution could be routing protocol but we can not configure routing protocol bcz this FR link is between Client and us (SP) and we can't run any routing protocol with our client due to policy matter.I have tried debug for FR end-to-end keepalive events & packets but could not get any clue from this. Can you help me out for other troubleshooting commands ??

Regards,

Mujeeb

Paolo Bevilacqua Sat, 06/09/2007 - 04:45

Hello,

please sends configuration for interface and sub interface only, and debugs you have collected. Note you will need same configuration on both ends.

Paolo Bevilacqua Tue, 06/12/2007 - 06:11

Hi,

I assume the PVC you have been doing the test, is working and passes traffic normally.

Now as you can see, the EEK is never received.

Can you ask the FR SP if they are doing FR/ATM interworking? It is possible the FR SP is not letting the EEK frame to pass.

As an other thing to try, can you change encapsulation to cisco on both sides ?

rmujeeb81 Tue, 06/12/2007 - 21:47

Hello,

Thanks for your contineous support.Well I want to clear one thing that the debug output which I have sent in my previous email was from time period during which we(SP) disabled PVC between client and us.

Another thing which I want to mention is that we are using FR/ATM Internetworking to provide data services to our client. We have another client connected with another sub interface of same router at our end and for that client this feature is working fine(FR encapsulation is IETF on both end ).

Problem which we are facing is that once we disable the PVC then EEK state goes down on both end ( SP and client ) but line protocol on the client's router does not go down due to which floating static route does not inject into routing table of client's router.

Thanks,

Mujeeb

Actions

This Discussion