Есть схема: 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
Hello, давно не возился с FR-ом, но мне странно как оно вообще заводится, если с обоих сторон intf-type dce: --------8<---------------- interface SerialK/L frame-relay intf-type dce .. interface SerialA/B:0 frame-relay intf-type dce -------8<------------------ On Wed, Jun 01, 2005 at 03:17:31PM +0300, Vladimir A. Podgorny wrote:
Есть схема:
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
-- Alexey Balabushevich nic-hdl: AB433-RIPE =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
Hello, может сюда копать? http://www.cisco.com/en/US/partner/products/sw/iosswrel/ps1830/products_feat... это такой себе end-to-end keepalive, который долетает до точки, где FR именно терминируется, а не до ближайшего FR свитча. Wednesday, June 1, 2005, 3:17:31 PM, you wrote: VAP> Есть схема: VAP> se X/Y @ 26xx --- Ukrtel FR cloud --- se M/N @ 72xx @ se A/B:0 --- se K/L @ 26xx VAP> @ se A/B:1 --- VAP> На участке между 26xx и 72xx через Укртелекомовский FR cloud VAP> имеем ситуацию: VAP> #sh frame-relay pvc interface se M/N | inc status changed VAP> pvc create time 33w2d, last time pvc status changed 3w1d VAP> 3w1d потому, что телеком проводил профилактику на МГТС, это VAP> нормально. VAP> А вот на участке между se A/B и se K/L имеем противную VAP> ситуцию, когда интерфейс/протокол не падают, а один из PVC VAP> ведет себя вот так: VAP> #sh frame-relay pvc interface se A/B | inc (status changed|PVC STATUS) VAP> DLCI = 16, DLCI USAGE = SWITCHED, PVC STATUS = ACTIVE, INTERFACE = SerialA/B VAP> pvc create time 33w2d, last time pvc status changed 00:12:13 VAP> ^^^^^^^^ VAP> DLCI = 17, DLCI USAGE = SWITCHED, PVC STATUS = ACTIVE, INTERFACE = SerialA/B VAP> pvc create time 33w2d, last time pvc status changed 23:21:33 VAP> PVC дохнет и поднимается достаточно регулярно. Из-за этого VAP> дохнут терминальные сессии. Текущая конфигурация (см. ниже) VAP> ничего криминального (IMHO) не содержит, но сама ситуация VAP> уже успела достать. VAP> Any suggestions? RTFM what, куда смотреть, чего копать? VAP> #sh run int se K/L VAP> Building configuration... VAP> Current configuration : 286 bytes VAP> ! VAP> interface SerialK/L VAP> no ip address VAP> encapsulation frame-relay VAP> load-interval 30 VAP> serial restart_delay 0 VAP> no fair-queue VAP> frame-relay intf-type dce VAP> frame-relay route 16 interface SerialA/B:0 16 VAP> frame-relay route 17 interface SerialA/B:1 17 VAP> end VAP> #sh run int se A/B:0 VAP> Building configuration... VAP> Current configuration : 207 bytes VAP> ! VAP> interface SerialA/B:0 VAP> no ip address VAP> encapsulation frame-relay VAP> load-interval 30 VAP> frame-relay intf-type dce VAP> frame-relay route 16 interface SerialK/L 16 VAP> end -- Best regards, Timofey Kolesnikov (TIM-RIPE) mailto:tim@newline.net.ua =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
On Wed, Jun 01, 2005 at 04:07:50PM +0300, Alexey Balabushevich wrote: [...skipped...]
--------8<---------------- interface SerialA/B:0 frame-relay intf-type dce -------8<------------------
Спасибо всем ответившим, разобрались. Всему виной оказался FR cloud телекома - время от времени хлопал protocol на se A/B:0, из-за чего разваливался PVC. -- VP992-RIPE =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
participants (3)
-
Alexey Balabushevich
-
Timofey Kolesnikov
-
Vladimir A. Podgorny