- To tell the status of a PVC (whether its up or down) DESPITE what LMI tells us. i.e we IGNORE what the FR Switch tells us about the status of the DLCI!
- End-to-end keepalives add ability to track VC status (Active/Inactive/Deleted) between DTE devices (routers) across a multi provider domain
Why would we want to not rely on LMI?
- Frame Relay networks today arent what they used to be. We USED to have end-to-end LMI & if we were told “active” it really meant things were working. TODAY’s networks are most likely just frame relay to the edge of the client. Once inside the SP network we can have:
- Multiple providers (FRNNIs between each provider) (AT&T -> Sprint – > CLEC)
- Protocol handoffs
or something else where we LOSE LMI.
- As long as the PE router has a route to the other side’s PE router, it thinks everything is perfectly cool REGARDLESS of whether your router on the other side is even powered on!
Consider the following scenario:
R2 (DLCI 204) s1/1.1 multipoint <==== Frame Switch ====> S1/0 (DLCI 402) R4
R1 (DLCI 104) s1/1.1 <==== Frame Switch ====> s1/0 (DLCI 401) R4
We want to implement FREEK here between R2 (DLCI 204) & R4 ONLY (DLCI 402)
FREEK is configured under a map class with the following command:
- frame-relay end-to-end {bidirectional | request | reply | passive-reply}
- bidirectional – both ends send & receive freeks
- request – the side this is set on, can send keepalives & respond to any replies
- reply – the side this is set on, can NOT send keepalive; it only replies to keepalives it receives
- passive-reply – same as reply but does not
So lets configure the FREEK map class on R2 & R4:
map-class frame-relay FREEK
frame-relay end-to-end keepalive mode bidirectional |
NB. I used bidirectional as there was no requirement for R2 to only send or receive e2e keepalives.
A few things of note here:
FREEK keepalive timer for sending keepalives is every 10 secs (default)
However the keepalive timer for receiving/expecting keepalives is 15 secs (default), no doubt the extra 5 secs is to help in receiving keepalives that may take slightly longer than 10 secs to arrive.
FREEK has a concept called the event window, & error event.
An error event corresponds to a missed keepalive.
The event window is the max no of error events (missed keepalives) that can occur before FREEK will bring down the pvc that has the missed keepalives. The default event window size is 3 (the usual 3 missed keepalives = problem thing)
Now the command to apply a map class varies depending on where you are applying it.
It can be applied under:
- Main interface
- Subinterface
- PVC
In the case of R2, the DLCI 204 resides on the multipoint subinterface of R2.
So, in this case we need to apply the FREEK map class under R2’s multipoint subint s1/1.1
In the case of R4, the DLCI 402 resides on the main interface of R4, s1/0
However! We also have ANOTHER dlci (401) also residing on R4’s main interface s1/0.
Now, if we went ahead & applied the map class to R4’s MAIN interface what would happen?
FREEK would be associated with ALL the DLCIs residing on the main interface.
So, FREEK would be working fine between R2 & R4, as R2 & R4 are both configured for FREEK.
However, as FREEK is also associated with DLCI 401 on R4, R4 will send out keepalives on DLCI 401 to R1.
R1, naturally, is not configured for FREEK, & as such, will ignore the FREEKs sent by R4!
You can probably see now that we will have a problem.
As R4 is configured for keepalive mode bidirectional, R4 is expecting a response to the keepalives it is sending to R1.
R1 shrugs and doesn’t respond to any FREEKs it gets from R4.
After 3 missed keepalives on DLCI 401 (to R1) (i.e 3×10 = 30 secs), R4 brings down the pvc to R1.
If you recall I wrote at the beginning:
To tell the status of a PVC (whether its up or down) DESPITE what LMI tells us. i.e we IGNORE what the FR Switch tells us about the status of the DLCI!
Even though R4’s PVC status = ACTIVE, FREEK doesn’t care and drops the PVC.
So, in order to circumvent this problem, on R4, we ONLY apply the map class to the PVC 402!
The config is:
On R2:
int s1/1.1
frame-relay class FREEK |
On R4:
int s1/0
frame-relay interface-dlci 402
class FREEK |
And thats that.
Modifying FREEK parameters
- All commands begin with: frame-relay end-to-end keepalive
Verifying FREEK
- show frame-relay end-to-end keepalive
- look for: * – EEK UP | EEK DOWN
- show frame-relay PVC
- look for: * – EEK UP | EEK DOWN
Finally some rules regarding FREEK configuration:
- You must configure both ends of a VC to send keepalives.
- If one end is configured as bidirectional, the other end must also be configured as bidirectional.
- If one end is configured as request, the other end must be configured as reply or passive-reply.
- If one end is configured as reply or passive-reply, the other end must be configured as request
Comments(0)
)