From: Hobbs (deadheadblues@gmail.com)
Date: Tue Jan 20 2009 - 02:02:51 ARST
Yeah, now that I think about it, it might have something else I read related
to the multipoint interface with EEK - not necessarily that point-point
won't work. I did read that example, it would be nice to hear if anyone else
knows what the deal is...
On Mon, Jan 19, 2009 at 8:59 PM, Pavel Bykov <slidersv@gmail.com> wrote:
> ...wow.... well... I'd be really interested in finding out where did you
> read about it.
> But it sure as heck isn't supposed to be intended behaviour...
> For one, the example on
> http://www.cisco.com/en/US/docs/ios/12_0t/12_0t5/feature/guide/FRKeep.html
> is with point-to-point subif.
>
> For the other, i'd expect something of that caliber would be mentioned
> everywhere, like clock rate.
>
> Thanks Hobbs.
>
>
>
> On Mon, Jan 19, 2009 at 7:07 PM, Hobbs <deadheadblues@gmail.com> wrote:
>
>> Hello Pavel, I just labbed this up and I am getting the same behavior. The
>> only way I get the interface to stay down is by using multipoint interface
>> instead of point-to-point. Doesn't seem to make sense, but for some reason I
>> remember reading about this somewhere...
>>
>> On Mon, Jan 19, 2009 at 6:44 AM, Pavel Bykov <slidersv@gmail.com> wrote:
>>
>>> I have a question about FR EEK.
>>> I configure it and apply on the interface, with intention that S0/1 will
>>> be
>>> my backup. (I checked S0/1 beforehand and it works by itself)
>>> Here is the config:
>>>
>>> ----------------------------------------
>>> interface Serial0/0.54 point-to-point
>>> backup interface Serial0/1
>>> ip address 173.1.54.5 255.255.255.0
>>> frame-relay interface-dlci 504
>>> class EEK
>>> end
>>> ----------------------------------------
>>>
>>>
>>> So then to test it I deconfigure EEK on the other side of FR cloud, and
>>> it
>>> works as expected. SUBIF is considered down and backup comes up:
>>>
>>> ----------------------------------------
>>> Jan 18 14:22:17.833: %LINK-3-UPDOWN: Interface Serial0/1, changed state
>>> to
>>> up
>>> Jan 18 14:22:18.835: %LINEPROTO-5-UPDOWN: Line protocol on Interface
>>> Serial0/1, changed state to up
>>> ----------------------------------------
>>>
>>> But then, after a minute or so, the subinterface is brought up and backup
>>> goes down again:
>>>
>>> ----------------------------------------
>>> Jan 18 14:23:16.838: %LINK-5-CHANGED: Interface Serial0/1, changed state
>>> to
>>> standby mode
>>> Jan 18 14:23:17.839: %LINEPROTO-5-UPDOWN: Line protocol on Interface
>>> Serial0/1, changed state to down
>>> ----------------------------------------
>>>
>>> Can anybody give me pointer why this would happen? The Subinterface is
>>> considered up while EEK is down? Why would it happen? Why it shows
>>> everywhere DOWN, but Subinterface is up all of a sudden?
>>> Here is the interface status along with PVC and EEK status taken at the
>>> same
>>> time:
>>>
>>> ----------------------------------------
>>> Rack1R5#sh ip int brie | ex una
>>> Interface IP-Address OK? Method Status
>>> Protocol
>>> Ethernet0/0 192.10.1.5 YES manual up
>>> up
>>> Serial0/0.54 173.1.54.5 YES manual up
>>> up
>>> Serial0/0.125 173.1.125.5 YES manual up
>>> up
>>> Serial0/1 173.1.45.5 YES manual standby mode
>>> down
>>> FastEthernet1/0 173.1.5.5 YES manual up
>>> up
>>> Loopback0 150.1.5.5 YES manual up
>>> up
>>>
>>>
>>> Rack1R5#show frame-relay pvc interface Serial0/0.54
>>>
>>> PVC Statistics for interface Serial0/0.54 (Frame Relay DTE)
>>>
>>> Active Inactive Deleted Static
>>> Local 2 1 0 0
>>> Switched 0 0 0 0
>>> Unused 0 2 0 0
>>>
>>> DLCI = 504, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE (EEK DOWN), INTERFACE
>>> =
>>> Serial0/0.54
>>>
>>> input pkts 622 output pkts 700 in bytes 9632
>>> out bytes 17276 dropped pkts 35 in pkts dropped
>>> 35
>>> out pkts dropped 0 out bytes dropped 0
>>> in FECN pkts 0 in BECN pkts 0 out FECN pkts 0
>>> out BECN pkts 0 in DE pkts 0 out DE pkts 0
>>> out bcast pkts 27 out bcast bytes 9602
>>> 5 minute input rate 0 bits/sec, 0 packets/sec
>>> 5 minute output rate 0 bits/sec, 0 packets/sec
>>> pvc create time 00:42:04, last time pvc status changed 00:01:43
>>>
>>> Rack1R5#sh frame-relay end-to-end keepalive interface Serial0/0.54
>>>
>>> End-to-end Keepalive Statistics for Interface Serial0/0.54 (Frame Relay
>>> DTE)
>>>
>>> DLCI = 504, DLCI USAGE = LOCAL, VC STATUS = ACTIVE (EEK DOWN)
>>>
>>> SEND SIDE STATISTICS
>>>
>>> Send Sequence Number: 251, Receive Sequence Number: 193
>>> Configured Event Window: 3, Configured Error Threshold: 3
>>> Total Observed Events: 255, Total Observed Errors: 59
>>> Monitored Events: 3, Monitored Errors: 3
>>> Successive Successes: 0, End-to-end VC Status: DOWN
>>>
>>> RECEIVE SIDE STATISTICS
>>>
>>> Send Sequence Number: 193, Receive Sequence Number: 192
>>> Configured Event Window: 3, Configured Error Threshold: 3
>>> Total Observed Events: 268, Total Observed Errors: 71
>>> Monitored Events: 3, Monitored Errors: 3
>>> Successive Successes: 0, End-to-end VC Status: DOWN
>>> ----------------------------------------
>>>
>>>
>>>
>>>
>>>
>>> --
>>> Pavel Bykov
>>> ----------------
>>> Don't forget to help stopping the braindumps, use of which reduces value
>>> of
>>> your certifications. Sign the petition at http://www.stopbraindumps.com/
>>>
>>>
>>> Blogs and organic groups at http://www.ccie.net
>>>
>>> _______________________________________________________________________
>>> Subscription information may be found at:
>>> http://www.groupstudy.com/list/CCIELab.html
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>
>
> --
> Pavel Bykov
> ----------------
> Don't forget to help stopping the braindumps, use of which reduces value of
> your certifications. Sign the petition at http://www.stopbraindumps.com/
Blogs and organic groups at http://www.ccie.net
This archive was generated by hypermail 2.1.4 : Sun Mar 01 2009 - 09:43:39 ARST