Frame-relay pt-pt subinterface - protocol is up - always

[crhodes]

I have two paths to a remote site. The preferred path is via IOS Router A with a F/R interface and a PVC to the remote F/R IOS router via a point-point subinterface. The backup path is via IOS Router B with ISDN.

In Router A I have two static routes to the remote site. One via the F/R subinterface, and a second static route with a higher metric via Router B.

The idea is that if the F/R goes down, Router A will forward the packet to Router B for sending via ISDN.

The problem I have is that if the remote F/R router subinterface for the PVC is shutdown, my F/R Router doesn't show protocol down on its subinterface, and the alternate static route is not installed in the routing table.

What do I have to do to get the subinterface protocol to go down when contact is lost with the remote F/R router?

My FR router config is:

interface Serial0/1.7 point-to-point

description "Link to remote site"

ip address 172.16.248.9 255.255.255.252

no ip route-cache

no ip mroute-cache

frame-relay interface-dlci 21

!

ip route 172.16.224.0 255.255.255.248 172.16.248.10

ip route 172.16.224.0 255.255.255.248 203.17.35.229 10

Is there a config command for the subinterface that causes protocol to go down when the remote router is unavailable?

Any assistance appreciated.

[Erick Bergquist]

Frame-Relay End-To-End keepalives (cisco propiertary) can be used to accomplish this.

http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/120newft/120t/120t5/frkeep.htm

[crhodes]

Looks interesting, but it doesn't mention what happens when keepalive decides the remote router is down.

Does it cause the subinterface to report protocol is down, and thus alow the static route in the route table to be replaced with the alternate higher metric value configured?

[t.baranski]

The subinterface changes state from up to down when its PVC goes down.

[crhodes]

I've implemented this now, and do see the subinterface and protocol change to down state. Interestingly, the state change is not logged like normal interface state changes.

Also, my static route that uses the next hop address at the other end of this point to point subinterface was not removed from the ip route table when the state changed to down.

I had to change my static route configuration to use the subinterface as the next hop before the entry was removed from the route table when the subinterface went down. Is this a feature or a bug?

The following console log illustrates this

interface Serial0/1.7 point-to-point

ip address 172.16.248.9 255.255.255.252

frame-relay class pvckeepalive

ip route 172.16.224.0 255.255.255.248 172.16.248.10

ip route 172.16.224.0 255.255.255.248 172.17.35.229 10

map-class frame-relay pvckeepalive

frame-relay end-to-end keepalive mode bidirectional

Cisco_3640#debug frame-relay end-to-end keepalive events

Frame-relay EEK events debugging is on

Cisco_3640#sho log

Feb 12 07:30:53: EEK receiver timeout (Serial0/1.7 DLCI 21)

Feb 12 07:31:02: EEK sender timeout (Serial0/1.7 DLCI 21)

Feb 12 07:31:08: EEK receiver timeout (Serial0/1.7 DLCI 21)

Feb 12 07:31:12: EEK sender timeout (Serial0/1.7 DLCI 21)

Cisco_3640# sho int s0/1.7

Serial0/1.7 is down, line protocol is down

Cisco_3640#sho ip route

S 172.16.224.0/29 [1/0] via 172.16.248.10

Cisco_3640(config)#no ip route 172.16.224.0 255.255.255.248 172.16.248.10

Cisco_3640(config)#ip route 172.16.224.0 255.255.255.248 serial 0/1.7

Cisco_3640#sho ip route

S 172.16.224.0/29 [10/0] via 172.17.35.229

Cisco_3640(config)#int s0/1.7

Cisco_3640(config-subif)#no frame-relay class pvckeepalive

Cisco_3640#sho int s0./1.7

Serial0/1.7 is up, line protocol is up

Cisco_3640#sho ip route

C 172.16.248.8/30 is directly connected, Serial0/1.7

S 172.16.224.0/29 is directly connected, Serial0/1.7

[t.baranski]

How long did you wait for the static route to be removed? I think (think...) that Cisco routers only check the validity of static routes once per minute. So you could see a delay of up to a minute between the time the interface changes state and the time the static route is removed.

[crhodes]

A minimum 76 seconds elapsed (time between keepalive configuration completed and latest log entry) before I issued the sho ip route command and saw the bad route still in the table.

[deilert]

check with you r service provider . They are spoofing LMI back to your router from their CSU. You can prove this by having a tech on the site unplug the cable that is connected to the smartjack , turn on debug frame lmi if you are still getting lmi this proves it is coming from the CSU .

[kcgeorge]

Sounds interesting....have you tried to configure your sub-interface with the same DLCI number, s0/1.21 ??

Also, if the remote end is a Non-Cisco , then use "frame-relay interface-dlci 21 ietf ".