Cisco 851, падает туннель через минуту после поднятия

Тема в разделе "Технические вопросы", создана пользователем movaxdx, 10 сен 2010.


    1. movaxdx

      movaxdx

      Регистрация:
      26 авг 2010
      Сообщения:
      2
      Симпатии:
      0
      Код:
      Cisco IOS Software, C850 Software (C850-ADVSECURITYK9-M), Version 12.4(15)T13, RELEASE SOFTWARE (fc3)
      

      deb ppp auth
      deb ppp nego
      deb l2tp all


      Код:
      001727: Sep 10 18:35:46.945 PCTime: Vp1 LCP: O CONFREQ [REQsent] id 34 len 10
      001728: Sep 10 18:35:46.945 PCTime: Vp1 LCP:    MagicNumber 0xB22DFA38 (0x0506B22DFA38)
      001729: Sep 10 18:35:46.945 PCTime: Vp1 LCP: I CONFREQ [REQsent] id 1 len 19
      001730: Sep 10 18:35:46.945 PCTime: Vp1 LCP:    MRU 1460 (0x010405B4)
      001731: Sep 10 18:35:46.945 PCTime: Vp1 LCP:    AuthProto CHAP (0x0305C22305)
      001732: Sep 10 18:35:46.945 PCTime: Vp1 LCP:    MagicNumber 0xE3DA8A4B (0x0506E3DA8A4B)
      001733: Sep 10 18:35:46.945 PCTime: Vp1 LCP: O CONFNAK [REQsent] id 1 len 8
      001734: Sep 10 18:35:46.945 PCTime: Vp1 LCP:    MRU 1500 (0x010405DC)
      001735: Sep 10 18:35:46.945 PCTime: Vp1 LCP: I CONFACK [REQsent] id 34 len 10
      001736: Sep 10 18:35:46.945 PCTime: Vp1 LCP:    MagicNumber 0xB22DFA38 (0x0506B22DFA38)
      001737: Sep 10 18:35:46.953 PCTime: Vp1 LCP: I CONFREQ [ACKrcvd] id 2 len 19
      001738: Sep 10 18:35:46.953 PCTime: Vp1 LCP:    MRU 1500 (0x010405DC)
      001739: Sep 10 18:35:46.953 PCTime: Vp1 LCP:    AuthProto CHAP (0x0305C22305)
      001740: Sep 10 18:35:46.953 PCTime: Vp1 LCP:    MagicNumber 0xE3DA8A4B (0x0506E3DA8A4B)
      001741: Sep 10 18:35:46.953 PCTime: Vp1 LCP: O CONFACK [ACKrcvd] id 2 len 19
      001742: Sep 10 18:35:46.953 PCTime: Vp1 LCP:    MRU 1500 (0x010405DC)
      001743: Sep 10 18:35:46.953 PCTime: Vp1 LCP:    AuthProto CHAP (0x0305C22305)
      001744: Sep 10 18:35:46.953 PCTime: Vp1 LCP:    MagicNumber 0xE3DA8A4B (0x0506E3DA8A4B)
      001745: Sep 10 18:35:46.953 PCTime: Vp1 LCP: State is Open
      001746: Sep 10 18:35:46.953 PCTime: Vp1 PPP: No authorization without authentication
      001747: Sep 10 18:35:46.953 PCTime: Vp1 PPP: Phase is AUTHENTICATING, by the peer
      001748: Sep 10 18:35:46.957 PCTime: Vp1 CHAP: I CHALLENGE id 1 len 37 from "ar0-co25.zp.fttb"
      001749: Sep 10 18:35:46.961 PCTime: Vp1 CHAP: Using hostname from interface CHAP
      001750: Sep 10 18:35:46.961 PCTime: Vp1 CHAP: Using password from interface CHAP
      001751: Sep 10 18:35:46.961 PCTime: Vp1 CHAP: O RESPONSE id 1 len 31 from "0003803100"
      001752: Sep 10 18:35:47.049 PCTime: Vp1 CHAP: I SUCCESS id 1 len 4
      001753: Sep 10 18:35:47.049 PCTime: Vp1 PPP: Phase is FORWARDING, Attempting Forward
      001754: Sep 10 18:35:47.049 PCTime: Vp1 PPP: Queue IPCP code[1] id[1]
      001755: Sep 10 18:35:47.049 PCTime: Vp1 PPP: Phase is ESTABLISHING, Finish LCP
      001756: Sep 10 18:35:47.049 PCTime: Vp1 PPP: Phase is UP
      001757: Sep 10 18:35:47.049 PCTime: Vp1 IPCP: O CONFREQ [Closed] id 1 len 10
      001758: Sep 10 18:35:47.049 PCTime: Vp1 IPCP:    Address 0.0.0.0 (0x030600000000)
      001759: Sep 10 18:35:47.049 PCTime: Vp1 PPP: Process pending ncp packets
      001760: Sep 10 18:35:47.049 PCTime: Vp1 IPCP: Redirect packet to Vp1
      001761: Sep 10 18:35:47.049 PCTime: Vp1 IPCP: I CONFREQ [REQsent] id 1 len 10
      001762: Sep 10 18:35:47.049 PCTime: Vp1 IPCP:    Address 94.27.126.8 (0x03065E1B7E08)
      001763: Sep 10 18:35:47.049 PCTime: Vp1 IPCP: O CONFACK [REQsent] id 1 len 10
      001764: Sep 10 18:35:47.049 PCTime: Vp1 IPCP:    Address 94.27.126.8 (0x03065E1B7E08)
      001765: Sep 10 18:35:47.057 PCTime: Vp1 IPCP: I CONFNAK [ACKsent] id 1 len 10
      001766: Sep 10 18:35:47.057 PCTime: Vp1 IPCP:    Address 46.118.74.110 (0x03062E764A6E)
      001767: Sep 10 18:35:47.057 PCTime: Vp1 IPCP: O CONFREQ [ACKsent] id 2 len 10
      001768: Sep 10 18:35:47.057 PCTime: Vp1 IPCP:    Address 46.118.74.110 (0x03062E764A6E)
      001769: Sep 10 18:35:47.061 PCTime: Vp1 IPCP: I CONFACK [ACKsent] id 2 len 10
      001770: Sep 10 18:35:47.061 PCTime: Vp1 IPCP:    Address 46.118.74.110 (0x03062E764A6E)
      001771: Sep 10 18:35:47.061 PCTime: Vp1 IPCP: State is Open
      001772: Sep 10 18:35:47.061 PCTime: Vp1 IPCP: Install negotiated IP interface address 46.118.74.110
      
      001773: Sep 10 18:35:48.049 PCTime: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-PPP1, changed state to up 
      
      поднялся, получили WAN адрес.
      всё нужное в апе:

      Код:
      Interface                  IP-Address      OK? Method Status                Protocol
      FastEthernet0              unassigned      YES unset  up                    up     
      FastEthernet1              unassigned      YES unset  up                    down   
      FastEthernet2              unassigned      YES unset  up                    down   
      FastEthernet3              unassigned      YES unset  up                    down   
      FastEthernet4              10.68.183.241   YES DHCP   up                    up     
      Virtual-PPP1               46.118.74.110   YES IPCP   up                    up     
      Vlan1                      192.168.1.254   YES NVRAM  up                    up      
      
      таблица маршрутов в этот момент:

      Код:
      Gateway of last resort is 0.0.0.0 to network 0.0.0.0
      
           10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
      S       10.10.14.2/32 [254/0] via 10.68.183.1, FastEthernet4
      S       10.0.0.28/32 [1/0] via 10.68.183.1
      C       10.68.183.0/24 is directly connected, FastEthernet4
           46.0.0.0/32 is subnetted, 1 subnets
      C       46.118.74.110 is directly connected, Virtual-PPP1
      C    192.168.1.0/24 is directly connected, Vlan1
      S*   0.0.0.0/0 is directly connected, Virtual-PPP1 
      
      пожили и упали:

      Код:
      001775: Sep 10 18:36:40.288 PCTime: Vp1 PPP: Missed 5 keepalives, taking LCP down
      001776: Sep 10 18:36:40.288 PCTime: Vp1 PPP: Sending Acct Event[Down] id[D]
      001777: Sep 10 18:36:40.288 PCTime: Vp1 LCP: State is Closed
      001778: Sep 10 18:36:40.288 PCTime: Vp1 PPP: Phase is DOWN
      001779: Sep 10 18:36:40.288 PCTime: Vp1 IPCP: State is Closed
      001780: Sep 10 18:36:40.288 PCTime: Vp1 PPP: Phase is ESTABLISHING, Passive Open
      001781: Sep 10 18:36:40.288 PCTime: Vp1 LCP: State is Listen
      001782: Sep 10 18:36:40.296 PCTime: Vp1 IPCP: Remove route to 94.27.126.8
      001783: Sep 10 18:36:41.288 PCTime: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-PPP1, changed state to down 
      
      таблица маршрутов после дауна:

      Код:
      Gateway of last resort is 10.68.183.1 to network 0.0.0.0
      
           10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
      S       10.10.14.2/32 [254/0] via 10.68.183.1, FastEthernet4
      S       10.0.0.28/32 [1/0] via 10.68.183.1
      C       10.68.183.0/24 is directly connected, FastEthernet4
      C    192.168.1.0/24 is directly connected, Vlan1
      S*   0.0.0.0/0 [254/0] via 10.68.183.1 
      
      причём, после всего этого пинги на локалку провайдера ходить перестают, до тех пор пока не переведёшь в даун Virtual-PPP1 и не передёрнешь Fe4.
       
    2. movaxdx

      movaxdx

      Регистрация:
      26 авг 2010
      Сообщения:
      2
      Симпатии:
      0
      короче, причина проблемы вроде как выявлена:

      --------------
      У cisco есть проблема: она инсталлит полученный от pptp/l2tp-сервера маршрут как directly connected в интерфейс, а передавать трафик (в том числе служебный) после не может, так как даже статический маршрут имеет метрику 1, а присоединенный 0. И если адрес сервера, к которому терминируется соединение такой же как и адрес публичного шлюза, то работать не будет. Тунель строится к адресу сервера, маршрут до которого лежит через один интерфейс, а после поднятия туннеля выясняется, что приоритетный маршрут на этот сервер указывает в туннель.
      -------------

      или в другой конференции -
      -Many PPTP servers use their primary address (i.e., the address that
      you might use in the vpdn-group's "initiate-to ip" command) for their end
      of the ppp connection. This is a problem because IOS will install a /32
      route to that address through the dialer interface thus creating a loop
      that chokes the connection (and possibly even crashes the router). If
      you can't find an alternate address for the server you will need to use
      policy routing to work around the problem as it appears that nothing can
      compete with a /32 "directly" connected interface route.

      вопрос в том, как с этим бороться.

      ну, или придётся сменить провайдера на "нормального", с PPPoE.



      а насчёт "техподдержки" в этом форуме - это, наверное, шутка.
       
    3. u-men

      u-men

      Регистрация:
      17 апр 2011
      Сообщения:
      3
      Симпатии:
      0
      Проблема решаеется следующим образом: no ip gratuitous-arps
      На Virtual-PPP можно оставлять peer neighbor-route и ppp ipcp route default. Тогда маршрут 0.0.0. 0.0.0.0 Virtual-PPP не directly-connected, а с метрикой 1. Но, это не суть. Главная проблема с ip gratuitous-arps была, когда при поднятии PPP, падал коннект со шлюзом.
       
    4. u-men

      u-men

      Регистрация:
      17 апр 2011
      Сообщения:
      3
      Симпатии:
      0
      Проблема решаеется следующим образом: no ip gratuitous-arps
      На Virtual-PPP можно оставлять peer neighbor-route и ppp ipcp route default. Тогда маршрут 0.0.0. 0.0.0.0 Virtual-PPP не directly-connected, а с метрикой 1. Но, это не суть. Главная проблема с ip gratuitous-arps была, когда при поднятии PPP, падал коннект со шлюзом.
       

    Поделиться этой страницей