Перейти к содержимому

Lost carrier что это

  • автор:

Lost carrier что это

Добрый день!
Уважаемые, может кто сталкивался, с чем связаны ошибки на интерфейсах lost carrier, и как можно избавится от этого.

Схема сети следующая:
Cisco 2611(Ethernet 1/0) -> Конвертор (Ethernet-оптика)——ВОЛС—- Конвертор (оптика-Ethernet)конвертор Ethernet в G.703SDHКонвертор G.703 в Ethernet.
Ошибки появляются на интерфейсе Ethernet 1/0 маршрутизатора. (если ставить к примеру комп вместо 2611, то канал идеальный с нулевыми задержками).

-show interfaces ethernet 1/0
Ethernet1/0 is up, line protocol is up
Hardware is AmdP2, address is 000f.9073.7750 (bia 000f.9073.7750)
Internet address is 62.33.197.249/29
MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec,
reliability 255/255, txload 2/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:02, output 00:00:00, output hang never
Last clearing of «show interface» counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 97000 bits/sec, 18 packets/sec
1819 packets input, 497512 bytes, 0 no buffer
Received 1796 broadcasts, 0 runts, 0 giants, 0 throttles
1 input errors, 1 CRC, 1 frame, 0 overrun, 0 ignored
0 input packets with dribble condition detected
154477 packets output, 65714787 bytes, 0 underruns
21096 output errors, 0 collisions, 11 interface resets
0 babbles, 0 late collision, 0 deferred
21096 lost carrier, 0 no carrier
0 output buffer failures, 0 output buffers swapped out

-show running-config interface ethernet 1/0

Current configuration : 125 bytes
!
interface Ethernet1/0
ip address 62.33.197.249 255.255.255.248
ip route-cache flow
half-duplex
no routing dynamic
end

Как избавится от lost carier?
С Уважением.

Оглавление

  • Ошибки lost carrier, и потери пакетов на интерфейсе., alexb, 10:55 , 06-Апр-05, (1)
    • Ошибки lost carrier, и потери пакетов на интерфейсе., trial, 11:12 , 06-Апр-05, (2)
      • Ошибки lost carrier, и потери пакетов на интерфейсе., alexb, 11:37 , 06-Апр-05, (3)
        • Ошибки lost carrier, и потери пакетов на интерфейсе., trial, 13:02 , 06-Апр-05, (4)

        Сообщения по теме

        А что за конвертор ?
        Какой у тебя Duplex на нем стоит. Попробуй поставить на int e1/0 full duplex.

        >Добрый день!
        >Уважаемые, может кто сталкивался, с чем связаны ошибки на интерфейсах lost carrier,
        >и как можно избавится от этого.
        >
        >Схема сети следующая:
        >Cisco 2611(Ethernet 1/0) -> Конвертор (Ethernet-оптика)——ВОЛС—- Конвертор (оптика-Ethernet)конвертор Ethernet в G.703SDHКонвертор G.703 в Ethernet.
        >Ошибки появляются на интерфейсе Ethernet 1/0 маршрутизатора. (если ставить к примеру комп
        >вместо 2611, то канал идеальный с нулевыми задержками).
        >
        >-show interfaces ethernet 1/0
        >Ethernet1/0 is up, line protocol is up
        > Hardware is AmdP2, address is 000f.9073.7750 (bia 000f.9073.7750)
        > Internet address is 62.33.197.249/29
        > MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec,
        > reliability 255/255, txload 2/255, rxload 1/255
        > Encapsulation ARPA, loopback not set
        > Keepalive set (10 sec)
        > ARP type: ARPA, ARP Timeout 04:00:00
        > Last input 00:00:02, output 00:00:00, output hang never
        > Last clearing of «show interface» counters never
        > Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
        > Queueing strategy: fifo
        > Output queue: 0/40 (size/max)
        > 5 minute input rate 0 bits/sec, 0 packets/sec
        > 5 minute output rate 97000 bits/sec, 18 packets/sec
        > 1819 packets input, 497512 bytes, 0 no
        >buffer
        > Received 1796 broadcasts, 0 runts, 0 giants,
        >0 throttles
        > 1 input errors, 1 CRC, 1 frame,
        >0 overrun, 0 ignored
        > 0 input packets with dribble condition detected
        >
        > 154477 packets output, 65714787 bytes, 0 underruns
        >
        > 21096 output errors, 0 collisions, 11 interface
        >resets
        > 0 babbles, 0 late collision, 0 deferred
        >
        > 21096 lost carrier, 0 no carrier
        > 0 output buffer failures, 0 output buffers
        >swapped out
        >
        >
        >-show running-config interface ethernet 1/0
        >
        >Current configuration : 125 bytes
        >!
        >interface Ethernet1/0
        > ip address 62.33.197.249 255.255.255.248
        > ip route-cache flow
        > half-duplex
        > no routing dynamic
        >end
        >
        >Как избавится от lost carier?
        >С Уважением.

        Конвертор D-link DMC190T
        Поставил Full-Duplex, ничего не изменилось. Мне кажется ошибка в маршрутизации. только вот какая не пойму.
        Коннектил к свитчу, пакеты ходили через тегированный порт FAst Ethernet0/0, и убегали на конвертор ,без ошибок.

        -#show run
        Building configuration.

        Current configuration : 6345 bytes
        !
        ! Last configuration change at 11:58:32 oren Wed Apr 6 2005 by 123456
        ! NVRAM config last updated at 11:58:32 oren Wed Apr 6 2005 by 123456
        !
        version 12.3
        service timestamps debug datetime msec
        service timestamps log datetime msec
        service password-encryption
        !
        hostname —
        !
        boot-start-marker
        boot-end-marker
        !
        clock timezone oren 5
        no network-clock-participate slot 1
        no network-clock-participate wic 0
        ip subnet-zero
        ip wccp version 1
        ip wccp web-cache
        !
        ip dhcp excluded-address 192.168.2.1
        !
        ip dhcp pool 0
        network 192.168.2.0 255.255.255.0
        domain-name local
        dns-server 217.150.34.129
        default-router 192.168.2.1
        !
        ip cef
        ip ips po max-events 100
        no ip rcmd domain-lookup
        ip rcmd rsh-enable
        ip rcmd remote-host TESTER 62.165.56.162 root enable
        no aaa new-model
        no ftp-server write-enable
        !
        controller E1 0/1
        channel-group 0 timeslots 1-24 speed 64
        channel-group 1 timeslots 25-31 speed 64
        description ==ttk==
        !
        class-map match-any VoIP
        match access-group 130
        class-map match-all RTP
        match access-group 1
        !
        !
        policy-map RTP
        class RTP
        priority 24
        class class-default
        fair-queue
        random-detect
        policy-map PM_VoIP
        class VoIP
        set precedence 5
        class class-default
        set precedence 1
        !
        interface Loopback1
        ip address 217.150.39.244 255.255.255.255
        !
        interface Loopback2
        ip address 62.33.197.33 255.255.255.255
        !
        interface Loopback3
        ip address 10.200.1.73 255.255.255.252
        !
        interface Loopback4
        ip address 62.33.197.100 255.255.255.255
        !
        interface Loopback6
        no ip address
        !
        interface FastEthernet0/0
        no ip address
        ip route-cache flow
        speed auto
        half-duplex
        no cdp enable
        !
        interface FastEthernet0/0.2
        encapsulation dot1Q 2
        ip address 192.168.2.1 255.255.255.0 secondary
        ip address 62.33.197.1 255.255.255.224
        ip nat inside
        ip virtual-reassembly
        !
        interface FastEthernet0/0.10
        description == Oren-TV ==
        encapsulation dot1Q 10
        ip address 62.33.197.161 255.255.255.252
        !
        interface FastEthernet0/0.11
        description ===ORTPZ===
        encapsulation dot1Q 11
        !
        interface FastEthernet0/0.12
        shutdown
        !
        interface FastEthernet0/0.40
        encapsulation dot1Q 40
        ip address 62.33.197.197 255.255.255.252
        !
        interface FastEthernet0/0.41
        encapsulation dot1Q 41
        ip address 62.33.197.173 255.255.255.252
        !
        interface FastEthernet0/0.42
        encapsulation dot1Q 42
        ip address 62.33.197.177 255.255.255.252
        !
        interface FastEthernet0/0.43
        encapsulation dot1Q 43
        ip address 62.33.197.181 255.255.255.252
        !
        interface FastEthernet0/0.44
        encapsulation dot1Q 44
        ip address 62.33.197.185 255.255.255.252
        !
        interface FastEthernet0/0.45
        encapsulation dot1Q 45
        ip address 62.33.197.189 255.255.255.252
        !
        interface FastEthernet0/0.46
        encapsulation dot1Q 46
        ip address 62.33.197.169 255.255.255.252
        no cdp enable
        !
        interface FastEthernet0/0.47
        encapsulation dot1Q 47
        ip address 62.33.197.193 255.255.255.252
        !
        interface FastEthernet0/0.49
        encapsulation dot1Q 49
        ip address 62.33.197.209 255.255.255.252
        !
        interface FastEthernet0/0.50
        encapsulation dot1Q 50
        ip address 62.33.197.213 255.255.255.252
        no cdp enable
        !
        interface FastEthernet0/0.51
        description ==X-plat==
        encapsulation dot1Q 51
        ip address 192.168.134.5 255.255.255.248 secondary
        ip address 62.33.197.201 255.255.255.252
        no cdp enable
        !
        interface FastEthernet0/0.52
        description ===TurAgenstvo===
        encapsulation dot1Q 52
        ip address 62.33.197.221 255.255.255.252
        !
        interface FastEthernet0/0.53
        encapsulation dot1Q 53
        ip address 62.33.197.157 255.255.255.252
        !
        interface FastEthernet0/0.54
        description ===Buro===
        encapsulation dot1Q 54
        ip address 62.33.197.225 255.255.255.252
        !
        interface Serial0/0
        ip unnumbered Loopback1
        encapsulation ppp
        shutdown
        no cdp enable
        !
        interface FastEthernet0/1
        no ip address
        shutdown
        duplex auto
        speed auto
        standby ip
        !
        interface Serial0/1:0
        ip unnumbered Loopback1
        ip access-group 110 in
        ip nat outside
        ip virtual-reassembly
        encapsulation ppp
        ip route-cache flow
        !
        interface Serial0/1:1
        ip unnumbered Loopback3
        service-policy input PM_VoIP
        service-policy output PM_VoIP
        encapsulation ppp
        ip route-cache flow
        !
        interface Ethernet1/0
        ip address 62.33.197.249 255.255.255.248
        ip route-cache flow
        full-duplex
        no routing dynamic
        !
        interface Ethernet1/1
        no ip address
        no ip mroute-cache
        shutdown
        half-duplex
        no cdp enable
        !
        interface Ethernet1/2
        no ip address
        shutdown
        half-duplex
        !
        interface Ethernet1/3
        ip address 192.168.0.1 255.255.255.252
        ip nat inside
        ip virtual-reassembly
        full-duplex
        !
        interface Ethernet1/3.1
        !
        router eigrp 1
        network 62.33.197.0 0.0.0.255
        auto-summary
        !
        ip classless
        ip route 0.0.0.0 0.0.0.0 Serial0/1:0
        ip route 62.33.197.34 255.255.255.255 62.33.197.17
        ip route 62.33.197.100 255.255.255.255 FastEthernet0/1
        ip route 62.33.197.248 255.255.255.248 Ethernet1/0
        ip route 80.237.12.34 255.255.255.255 Serial0/1:1
        ip route 80.237.13.33 255.255.255.255 Serial0/1:1
        ip route 192.168.3.10 255.255.255.255 FastEthernet0/1
        !
        ip flow-export source FastEthernet0/0.2
        ip flow-export version 5
        ip flow-export destination 62.33.197.15 9992
        !
        no ip http server
        no ip http secure-server
        ip nat inside source list local_ofice interface Loopback2 overload
        !
        ip access-list standard local_ofice
        permit 192.168.2.0 0.0.0.255
        ip access-list standard squid
        deny 62.33.197.9
        permit any
        !
        access-list 1 permit 0.0.0.0 255.255.255.224
        access-list 1 permit 62.33.197.0 0.0.0.32
        access-list 110 deny tcp any any eq 135
        access-list 110 deny tcp any any eq 136
        access-list 110 deny tcp any any eq 137
        access-list 110 deny tcp any any eq 138
        access-list 110 deny tcp any any eq 139
        access-list 110 deny tcp any any eq 445
        access-list 110 permit ip any any
        access-list 130 permit ip any 80.237.12.0 0.0.1.255
        snmp-server community access RW
        snmp-server packetsize 2046
        snmp-server host 62.33.197.15 tty tty
        !
        route-map RM_SET_RT permit 10
        match ip address 130
        set ip precedence critical
        !
        !
        !
        control-plane
        !
        !
        line con 0
        line aux 0
        line vty 0

        login local
        line vty 1 4

        login
        line vty 5 6
        login
        !
        ntp clock-period 17180398
        ntp master
        ntp server 195.2.64.5
        ntp server 192.5.41.209 prefer
        !
        end

        -#

        К сожалению не нашел описания этого DLINK. Проблемма не в маршрутизации, у тебя ошибки на интрефейсе, а к маршрутизации это отношения не имеет.
        Я бы провел эксперемент возьми свич выдели на нем два порта в отдельный Vlan и подключи к ним циско E1/0 а на второй порт конвертор. Я думаю все будет замечательно работать.(если свича нет возьми хаб).Если не поможет то скорее всего это аппаратная проблемма с портом E1/0

        >Конвертор D-link DMC190T
        >Поставил Full-Duplex, ничего не изменилось. Мне кажется ошибка в маршрутизации. только вот
        >какая не пойму.
        >Коннектил к свитчу, пакеты ходили через тегированный порт FAst Ethernet0/0, и убегали
        >на конвертор ,без ошибок.

        >К сожалению не нашел описания этого DLINK. Проблемма не в маршрутизации, у
        >тебя ошибки на интрефейсе, а к маршрутизации это отношения не имеет.
        >
        >Я бы провел эксперемент возьми свич выдели на нем два порта в
        >отдельный Vlan и подключи к ним циско E1/0 а на второй
        >порт конвертор. Я думаю все будет замечательно работать.(если свича нет возьми
        >хаб).Если не поможет то скорее всего это аппаратная проблемма с портом
        >E1/0
        >

        Интересный факт, если прокидывать на удаленное оборудование, две сети через простой хаб, (одна идет через Vlan локальная сеть из 32 адресов вторая на 8 адресов с которой проблеммы), пишешь на удаленном интерфейсе ip add *.*.*.*.* и ip addd *.*.*.* second, то канал выравнивается.

        Пожалуйста, прежде чем написать сообщение, ознакомьтесь с данными рекомендациями.

        Lost carrier что это

        Часовой пояс: UTC + 3 часа

        Ответ МТУ -прошивки от D -Link глючные

        Страница 1 из 1 [ Сообщений: 13 ]

        Заголовок сообщения: Ответ МТУ -прошивки от D -Link глючные
        Добавлено: Вт дек 13, 2005 01:12

        Сегодня разговаривал со службой поддержки Стрим — МТУ.
        На удивление попался понимающий специалист.
        Проблемма заключалась в следующем:
        После установлении сессии DSL-500T с прошивкой V2.00B01T01.EU.20050930 завершает сессию и несколько раз пытается установить нулевые сессии, затем коннект сново происходит.
        Но этот глюк проявляется раз в два-три часа.
        Причём если не переконнектится из WEB интерфейса самого рутера,
        то он может висеть часами.
        МТУшники посоветовали связаться с дликом и решить вопросы с ними.
        По поводу перепрошивки DSLAM -ов они говорят, что поменяли лишь внутренние VLAN -ы.
        Вопрос: Кто создал этот трабл?
        Спецы — ВАМ слово.

        Заголовок сообщения: Доп. инфа
        Добавлено: Вт дек 13, 2005 01:42

        Тех. поддержка МТУ заверяет, что «перепрошивка DSLAM -ов никак не связана с внедрением Стрим-ТВ.
        Может стоит воспользоваться прошивкой от McMCC?

        Заголовок сообщения:
        Добавлено: Вт дек 13, 2005 02:08

        У меня этот баг (что модем перестаёт пытатся восстановить связь после нескольких попыток до ручного вмешательства) был и с 20050614.

        _________________
        DFL-260E A1 v.12.00.13.05-34465; DFL-210 A4 v.2.27.08.03-22678; DAP-2310 A1 v.1.16
        Заголовок сообщения:
        Добавлено: Вт дек 13, 2005 10:08
        Это не баг — это новая фича от Длинка.
        Заголовок сообщения: Re: Ответ МТУ -прошивки от D -Link глючные
        Добавлено: Вт дек 13, 2005 10:41
        iapetus писал(а):

        Сегодня разговаривал со службой поддержки Стрим — МТУ.
        На удивление попался понимающий специалист.
        Проблемма заключалась в следующем:
        После установлении сессии DSL-500T с прошивкой V2.00B01T01.EU.20050930 завершает сессию и несколько раз пытается установить нулевые сессии, затем коннект сново происходит.
        Но этот глюк проявляется раз в два-три часа.
        Причём если не переконнектится из WEB интерфейса самого рутера,
        то он может висеть часами.
        МТУшники посоветовали связаться с дликом и решить вопросы с ними.
        По поводу перепрошивки DSLAM -ов они говорят, что поменяли лишь внутренние VLAN -ы.
        Вопрос: Кто создал этот трабл?
        Спецы — ВАМ слово.

        Что значит «нулевая сессия»?
        Заголовок сообщения:
        Добавлено: Ср дек 14, 2005 02:01

        Нулевая сессия — это когда со стороны тех поддержки в логах соединений видно, что мопед стартует сессию, nas успевает выделить айпишник и моментально сразу же user-request. Сессии дляться 0 секунд, при том 0 байт получено и 0 передано. Встречал на 2 модемах — 660й зухель и длинк (марку не помню).
        Причем если мопед утащить на другую линию и посмотреть логи со стороны провайдера — такая же хрень.
        Причем ситуация не постоянная, он может через примерно 20 попыток соединиться нормально. Причина не ясна.

        _________________
        DSL 504T [VX.XXXXXXXX.RU.XXXXXXXX]

        Заголовок сообщения:
        Добавлено: Ср дек 14, 2005 10:08
        n0taz писал(а):

        Нулевая сессия — это когда со стороны тех поддержки в логах соединений видно, что мопед стартует сессию, nas успевает выделить айпишник и моментально сразу же user-request. Сессии дляться 0 секунд, при том 0 байт получено и 0 передано. Встречал на 2 модемах — 660й зухель и длинк (марку не помню).
        Причем если мопед утащить на другую линию и посмотреть логи со стороны провайдера — такая же хрень.
        Причем ситуация не постоянная, он может через примерно 20 попыток соединиться нормально. Причина не ясна.

        Что такое «user-request»? Можно увидеть лог модема во время этих самых «нулевых сессий»?
        Если у Вас есть доступ к логам провайдера, я бы на них тоже взгянул. Спасибо.

        Заголовок сообщения:
        Добавлено: Ср дек 14, 2005 12:51

        Грубо говоря user-request — это когда модем сам изъявил желание отключиться. Еще может быть lost-carrier — связь прервалась помимо желания модема и DSLAMа — например телефонную линию обрубили топором

        Заголовок сообщения:
        Добавлено: Ср дек 14, 2005 15:28
        Sen’Ja писал(а):

        Грубо говоря user-request — это когда модем сам изъявил желание отключиться. Еще может быть lost-carrier — связь прервалась помимо желания модема и DSLAMа — например телефонную линию обрубили топором

        А можно без «грубо говоря»? Если мы сейчас обсуждаем проблему и пытаемся обнаружить причину ее возникновения, давайте говорить техническим языком, используя общепринятые термины, а не «user-request» и «нулевая сессия». Если же Вы хотите просто поговорить, то для этого, наверное, есть более подходящие форумы.
        Спасибо.

        Заголовок сообщения:
        Добавлено: Ср дек 14, 2005 21:29

        Логи предоставить не имею права.
        User-request это так и есть — программный запрос на завершение сессии (либо от модема, если он в режиме роутера, либо со стороны ПО компьютера, если используется режим бридж).
        Еще бывает lost-carrier — это когда по истечению некоторого времени не приходит alive от клиента. В этом случае сессия рвётся принудительно со стороны провайдера.

        В логах со стороны провайдера видно, что Start и User-Request происходят в одну секунду. Если бы было все впорядке, то сначала бы был Start, потом каждые, например, 5 минут от клиента приходили бы пакеты на Alive, и затем, когда пользователь бы отключался от интернета нормальным способом (либо Disconnect на модеме, либо разрывает PPPoE соединение на компе) — то приходит пакетик на разрыв сессии и видно User-Request.

        _________________
        DSL 504T [VX.XXXXXXXX.RU.XXXXXXXX]

        Заголовок сообщения:
        Добавлено: Чт дек 15, 2005 00:58

        И еще по названию топика — если бы прошивки от Д-Линк были бы глючными — то такая ситуация была бы у всех устройств хотя бы одной модели. Но это лишь единичные случаи. При том, как я и написал выше, видел аналогичную ситуацию и у Престижа от Зухеля.

        _________________
        DSL 504T [VX.XXXXXXXX.RU.XXXXXXXX]

        Заголовок сообщения:
        Добавлено: Чт дек 15, 2005 13:23
        n0taz писал(а):

        Логи предоставить не имею права.
        User-request это так и есть — программный запрос на завершение сессии (либо от модема, если он в режиме роутера, либо со стороны ПО компьютера, если используется режим бридж).
        Еще бывает lost-carrier — это когда по истечению некоторого времени не приходит alive от клиента. В этом случае сессия рвётся принудительно со стороны провайдера.

        В логах со стороны провайдера видно, что Start и User-Request происходят в одну секунду. Если бы было все впорядке, то сначала бы был Start, потом каждые, например, 5 минут от клиента приходили бы пакеты на Alive, и затем, когда пользователь бы отключался от интернета нормальным способом (либо Disconnect на модеме, либо разрывает PPPoE соединение на компе) — то приходит пакетик на разрыв сессии и видно User-Request.

        Я понимаю, что Вы мне сейчас пытаетесь объяснить значения каких-то отрывков логов какого-то устройства провайдера. Но, во-первых, это не является стандартной терминологией. Во-вторых, непонятно какому именно протоколу относится этот самый «программный запрос» — PPPoE, LCP.
        Если Вы не можете предоставить мне логи провайдера, то каков смысл этой темы?
        «Вот Ваша посылка, но я ее Вам не отдам» (С) Почтальон Печкин

        Заголовок сообщения:
        Добавлено: Чт дек 15, 2005 18:44

        Это не моя проблема, у меня все хорошо работает. Я просто попытался объяснить о чем говорит создатель топика. Соединение естественно PPPoE. Если вам трудно понять, то извините, значит зря писал, если создатель топика сможет объяснить так, как необходимо вам — я буду рад за него.

        _________________
        DSL 504T [VX.XXXXXXXX.RU.XXXXXXXX]

        Страница 1 из 1 [ Сообщений: 13 ]

        Часовой пояс: UTC + 3 часа

        Кто сейчас на форуме

        Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 19

        Вы не можете начинать темы
        Вы не можете отвечать на сообщения
        Вы не можете редактировать свои сообщения
        Вы не можете удалять свои сообщения
        Вы не можете добавлять вложения

        Lost carrier что это

        Проблема началась сегодня.

        OS: Debian — Linux 2.6.26-2-amd64 #1 SMP Wed Aug 19 22:33:18 UTC 2009 x86_64 GNU/Linux
        Freeradius: Version 2.0.4, for host x86_64-pc-linux-gnu, built on Sep 7 2008 at 17:42:33)

        Еесть клиенты которые конектятся к hotspot (Mikrotik) через WiFi, hotspot авторизует юзеров через freeradius. У нескольких из клиентов, через несколько минут после авторизации ( разные интервалы 1,2,5 минут ) опять просит авторизоватся. В базе радиуса у этих клиентов,
        acctterminatecause — Lost-Carrier

        Цитата
        Lost Carrier DCD was dropped on the port.

        Что это означает .

        в нете нечего интересного не нашел .
        где-то было написано, что проблема между NAS-ом и клиентом. Посмотрел с сигналами все норма.

        в чем вообще может быт проблема ?

        Это нравится: 0Да / 0Нет
        28.12.2009 23:08:04

        Lost Carrier во всех системах означает, что пропадает основное соединение, в вашем случает это инет.
        вот примерная выдержка:

        Цитата
        Lost Carrier.
        Session terminated when modem dropped DCD(Data Carrier Detect). This can either mean the user or his modem hung up the phone from their end, in which case there is no problem, or can mean that the line was dropped or took a noise hit too severe for the modems to recover from, or can mean that the local modem dropped DCD for some other reason. Also sent to RADIUS Accounting.

        а вот еще одна цитата:

        Цитата
        acctTerminateCause
        Description: Used in RADIUS accounting to indicate how a session was terminated.

        Убедил я вас в какую сторону надо копать?
        Это нравится: 0Да / 0Нет
        28.12.2009 23:12:58

        2 дня назад уже был убежден что проблема из за слабого сигнала с клиентской стороны.

        Все таки, спасибо за ответ (:

        Что может быть причиной возникновения lost carrier?

        Столкнулся с такой проблемой, в неопределённые интервалы времени возникает ошибка lost carrier:

        1921-grt01-nya#sh int gig 0/0
        GigabitEthernet0/0 is up, line protocol is up
        Hardware is CN Gigabit Ethernet, address is 84b8.0239.99a0 (bia 84b8.0239.99a0)
        Description: pp21-p1
        Internet address is x.x.x.x/30
        MTU 1500 bytes, BW 100000 Kbit/sec, DLY 100 usec,
        reliability 255/255, txload 1/255, rxload 1/255
        Encapsulation ARPA, loopback not set
        Keepalive set (10 sec)
        Full Duplex, 100Mbps, media type is RJ45
        output flow-control is unsupported, input flow-control is unsupported
        ARP type: ARPA, ARP Timeout 04:00:00
        Last input 00:00:14, output 00:00:00, output hang never
        Last clearing of «show interface» counters 4d19h
        Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 26
        Queueing strategy: fifo
        Output queue: 0/40 (size/max)
        5 minute input rate 135000 bits/sec, 15 packets/sec
        5 minute output rate 8000 bits/sec, 11 packets/sec
        5707773 packets input, 3204418960 bytes, 0 no buffer
        Received 10201 broadcasts (0 IP multicasts)
        0 runts, 0 giants, 0 throttles
        78 input errors, 12 CRC, 27 frame, 0 overrun, 0 ignored
        0 watchdog, 0 multicast, 0 pause input
        3805486 packets output, 384755047 bytes, 0 underruns
        0 output errors, 0 collisions, 0 interface resets
        0 unknown protocol drops
        0 babbles, 0 late collision, 0 deferred
        7 lost carrier, 0 no carrier, 0 pause output
        0 output buffer failures, 0 output buffers swapped out

        Это данные за три дня, причём input errors, CRC и frame, не увеличиваются постоянно, они возникли при одном из lost carrier event, но больше не растут. Сами lost carrier ошибки возникают без какого-либо объяснимого события.

        Схема подключения до коммутатора ISP выглядит следующим образом: edge router -> patch panel main cross -> patch panel inductory cross -> lightning protection -> ISP switch.

        Само собой кабель проверен, по крайней мере базовым тестером, к сожалению такого, чтобы мог замерить характеристики прохождения сигнала в кабеле нет.

        Switch ISP находится в необогреваемом шкафу, морозы у нас до -35, корреляции температуры и количества возникающих ошибок, пока установить не удалось, на первый взгляд их количество увеличивается при достижение температуры ниже -15, но мало вводных данных.

        Есть подозрение на возможное влияние пассивной грозозащиты на возникновение данной ошибки, запланировано мероприятие по её временному обходу, для исключения этого фактора.

        Что ещё можно предпринять, до полного пере монтажа всего кабельного тракта?

        Любые советы и тем более собственный опыт борьбы с lost carrier, приветствуется.

        Не могу найти, есть ли у CISCO debug для таких events, чтобы можно было более детально увидеть, что происходит при этом lost carrier error event?

        U.P.D. Вопрос закрыт.

        Виною был и есть, коммутатор фирмы D-Link, как оказалось, у ISP нашлась ещё куча тикетов с той же самой проблемой, lost carrier, все они решались переходом в no negotiation.

        Грозозащита, FTP кабеля, низкие температуры, всё это было не при чём, D-Link, знает, что-то о стандартах, чего не знают другие компании.

        • Вопрос задан более трёх лет назад
        • 9800 просмотров

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *