Есть схема: 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@uanog.kiev.ua with "unsubscribe uanog" in the body of the message