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

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

  1. movaxdx
    Код:
    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
    короче, причина проблемы вроде как выявлена:

    --------------
    У 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
    Проблема решаеется следующим образом: 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
    Проблема решаеется следующим образом: 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, падал коннект со шлюзом.
     

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