Re: Frame Relay EEK

I'm sorry, I should probably respond at greater length. The reason your EEK
status kept going down, is because Keepalives run on top of LMI. If you have
no DLCI tied to the interface (which seems to be the case)

R4
interface Serial0/0/0
 ip address 155.18.200.4 255.255.255.0
 encapsulation frame-relay
 frame-relay class FREEK

How would keepalives be able to flow across the DLCI? The absent of LMI
prevent the DLCI from ever coming up, which in turn doesnt allow keepalives
to flow across a downed link...Tieing the dlci to the interface, allows LMI
across the dlci which then brings the dlci UP and allows keepalives to start
flowing which turn ON your EEK

Hope this helps.

On Tue, Apr 5, 2011 at 10:53 AM, Michael Jones <majonestx_at_gmail.com> wrote:

> This is because you don't/didnt have your map class tied to a specific DLCI
> on r4 :)
>
>
> On Tue, Apr 5, 2011 at 8:39 AM, Garth Bryden <
> hacked.the.planet.on.28.8k.dialup_at_gmail.com> wrote:
>
>> Hi Group,
>>
>> I have come across an interesting frame relay eek issue, and I'm wondering
>> if anybody had seen it before or had an explanation as to why it occurs, I
>> had trouble finding information using good ol google.
>>
>> Our topology is as follows
>>
>> [ R4 ] ----DLCI 405-------- [ FR CLOUD ] -----DLCI 504----- R5
>>
>> I have configured FR EEK's between R4 and R5, with the following
>> configuration-
>>
>> R4
>>
>> interface Serial0/0/0
>> ip address 155.18.200.4 255.255.255.0
>> encapsulation frame-relay
>> frame-relay class FREEK
>> !
>> interface Serial0/0/0.999 multipoint
>> frame-relay interface-dlci 401
>> frame-relay interface-dlci 402
>> frame-relay interface-dlci 403
>> frame-relay interface-dlci 413
>> !
>> map-class frame-relay FREEK
>> frame-relay end-to-end keepalive mode reply
>> frame-relay end-to-end keepalive timer recv 5
>> frame-relay end-to-end keepalive event-window recv 10
>> frame-relay end-to-end keepalive error-threshold recv 8
>>
>> R5
>>
>> interface Serial0/0/0
>> no ip address
>> encapsulation frame-relay
>> !
>> interface Serial0/0/0.200 multipoint
>> ip address 155.18.200.5 255.255.255.0
>> frame-relay interface-dlci 503
>> frame-relay interface-dlci 504
>> class FREEK
>> !
>> map-class frame-relay FREEK
>> frame-relay end-to-end keepalive mode request
>> frame-relay end-to-end keepalive timer send 5
>> frame-relay end-to-end keepalive event-window send 10
>> frame-relay end-to-end keepalive error-threshold send 8
>>
>> To test that the configuration is working, I remove the class FREEK from
>> R5
>> then wait on R4 until enough errors have occured to cause the PVC to go
>> from
>> UP->DOWN. I can see this occur, but then immediately after the PVC comes
>> back up, and all the EEK Counters have reset to 0! I managed to look at
>> the
>> output of show frame-relay end-to-end keepalives fast enough to see it
>> actually removes the 405 PVC and re-installs it.....
>>
>> I tested on both ends and this occured on R4 but not on R5. I ended up
>> applying the "frame-relay interface-dlci 405" to the physical interface of
>> Serial0/0/0 to which resolved the problem, but I was wondering why it was
>> occuring? Would LMI be removing the PVC on the DTE then when the next
>> status
>> update comes from the FR Switch re-add it??
>>
>> Cheers,
>>
>> Garth
>>
>>
>> Blogs and organic groups at http://www.ccie.net
>>
>> _______________________________________________________________________
>> Subscription information may be found at:
>> http://www.groupstudy.com/list/CCIELab.html

Blogs and organic groups at http://www.ccie.net
Received on Tue Apr 05 2011 - 11:08:01 ART