Есть схема:
se X/Y @ 26xx --- Ukrtel FR cloud --- se M/N @ 72xx @ se A/B:0 --- se K/L @ 26xx
@ se A/B:1 ---
На участке между 26xx и 72xx через Укртелекомовский FR cloud
имеем ситуацию:
#sh frame-relay pvc interface se M/N | inc status changed
pvc create time 33w2d, last time pvc status changed 3w1d
3w1d потому, что телеком проводил профилактику на МГТС, это
нормально.
А вот на участке между se A/B и se K/L имеем противную
ситуцию, когда интерфейс/протокол не падают, а один из PVC
ведет себя вот так:
#sh frame-relay pvc interface se A/B | inc (status changed|PVC STATUS)
DLCI = 16, DLCI USAGE = SWITCHED, PVC STATUS = ACTIVE, INTERFACE = SerialA/B
pvc create time 33w2d, last time pvc status changed 00:12:13
^^^^^^^^
DLCI = 17, DLCI USAGE = SWITCHED, PVC STATUS = ACTIVE, INTERFACE = SerialA/B
pvc create time 33w2d, last time pvc status changed 23:21:33
PVC дохнет и поднимается достаточно регулярно. Из-за этого
дохнут терминальные сессии. Текущая конфигурация (см. ниже)
ничего криминального (IMHO) не содержит, но сама ситуация
уже успела достать.
Any suggestions? RTFM what, куда смотреть, чего копать?
#sh run int se K/L
Building configuration...
Current configuration : 286 bytes
!
interface SerialK/L
no ip address
encapsulation frame-relay
load-interval 30
serial restart_delay 0
no fair-queue
frame-relay intf-type dce
frame-relay route 16 interface SerialA/B:0 16
frame-relay route 17 interface SerialA/B:1 17
end
#sh run int se A/B:0
Building configuration...
Current configuration : 207 bytes
!
interface SerialA/B:0
no ip address
encapsulation frame-relay
load-interval 30
frame-relay intf-type dce
frame-relay route 16 interface SerialK/L 16
end
--
VP992-RIPE | The girl opened her mouth, I opened my veins,
| The girl opened her heart, I opened a door to another world...
| (c) Tiamat '92, Clouds, "Undressed".
===================================================================
uanog mailing list.
To Unsubscribe: send mail to majordomo(a)uanog.kiev.ua
with "unsubscribe uanog" in the body of the message
