Jump to content
Калькуляторы

WCCPv2: Catalyst 6500 и Squid 3.0 (freebsd) Не проходят запросы

Коллеги, второй день маюсь с WCCP на каталисте и сквиде. Вроде видят друг друга, но до сквида запросы не доходят.

 

Squid последний (3.0), ОС - FreeBSD 6.3

 

Адреса

 

Squid - 10.0.0.2
Catalyst - 10.0.0.1 (вилан) и 192.168.10.1 (loopback0)

 

Как настраивал

 

На FreeBSD поднял GRE

 

gre0: flags=d051<UP,POINTOPOINT,RUNNING,LINK0,LINK2,MULTICAST> mtu 1476
    tunnel inet 10.0.0.2 --> 192.168.10.1
    inet 1.1.1.1 --> 1.1.1.2 netmask 0xff000000

 

В Squid прописал

 

http_port 3128 transparent
wccp2_router 10.0.0.1
wccp2_forwarding_method 1   #GRE encapsulation (forward the packet in a GRE/WCCP tunnel)
wccp2_return_method 1         #GRE encapsulation (forward the packet in a GRE/WCCP tunnel)
wccp2_assignment_method 1 #Hash assignment
wccp2_service standard 0

 

Прописал форвард WWW трафика на Squid

 

# ipfw show
00100    69    3312 fwd 127.0.0.1,3128 tcp from any to any dst-port 80 recv gre0
65535 34774 5382644 allow ip from any to any

 

На каталисте включил WCCP

 

ip wccp web-cache redirect-list WCCP_REDIRECT_TEST

 

Отфильтровал то, что будем кидать на WCCP

 

ip access-list extended WCCP_REDIRECT_TEST
deny   tcp host 10.0.0.2 any eq www
permit tcp host 10.0.0.5 any eq www
deny   ip any any

 

Проверяем что получилось

 

Видим, что каталист вроде как видит Squid и даже редиректит на него что-то

 

#sh ip wccp 
Global WCCP information:
    Router information:
    Router Identifier:                   192.168.10.1
    Protocol Version:                    2.0

    Service Identifier: web-cache
    Number of Cache Engines:             1
    Number of routers:                   1
    Total Packets Redirected:            9
    Redirect access-list:                WCCP_REDIRECT_TEST
    Total Packets Denied Redirect:       0
    Total Packets Unassigned:            0
    Group access-list:                   -none-
    Total Messages Denied to Group:      0
    Total Authentication failures:       0

 

Включил дебаг на каталисте, видим фигню (не понял, о чем это он)

 

4d11h: WCCP-PKT:S00: Sending I_See_You packet to 10.0.0.2 w/ rcv_id 0000003F
4d11h: WCCP-EVNT:wccp_update_assignment_status: enter
4d11h: WCCP-EVNT:wccp_update_assignment_status: exit
4d11h: WCCP-EVNT:wccp_validate_wc_assignments: enter
4d11h: WCCP-EVNT:wccp_validate_wc_assignments: not mask assignment, exit
4d11h: WCCP-PKT:S00: Sending I_See_You packet to 10.0.0.2 w/ rcv_id 00000040
4d11h: WCCP-EVNT:wccp_update_assignment_status: enter
4d11h: WCCP-EVNT:wccp_update_assignment_status: exit
4d11h: WCCP-EVNT:wccp_validate_wc_assignments: enter
4d11h: WCCP-EVNT:wccp_validate_wc_assignments: not mask assignment, exit
4d11h: WCCP-PKT:S00: Sending I_See_You packet to 10.0.0.2 w/ rcv_id 00000041

 

Включил дебаг на Squid - вроде нормально, посылает и принимает ответы от каталиста

 

2008/12/23 22:44:26.277| Sending HereIam packet size 144
2008/12/23 22:44:26.279| Incoming WCCPv2 I_SEE_YOU length 132.
2008/12/23 22:44:26.279| Incoming WCCP2_I_SEE_YOU Received ID old=138 new=139.

 

На всякий случай проверяем tcpdump'ом - вроде живут и общаются

 

# tcpdump -n dst port 2048
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ti0, link-type EN10MB (Ethernet), capture size 96 bytes
22:46:26.421922 IP 10.0.0.2.2048 > 10.0.0.1.2048: UDP, length 144
22:46:26.423288 IP 10.0.0.1.2048 > 10.0.0.2.2048: UDP, length 140
22:46:36.432922 IP 10.0.0.2.2048 > 10.0.0.1.2048: UDP, length 144
22:46:36.434309 IP 10.0.0.1.2048 > 10.0.0.2.2048: UDP, length 140

 

Пробуем запросить страничку и заглянем что в тунеле...

 

# tcpdump -i gre0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on gre0, link-type NULL (BSD loopback), capture size 96 bytes
22:49:05.674370 IP 10.0.0.5.objective-dbc > ya.ru.http: S 2290750273:2290750273(0) win 16384 <mss 1460,nop,nop,sackOK>
22:49:08.670139 IP 10.0.0.5.objective-dbc > ya.ru.http: S 2290750273:2290750273(0) win 16384 <mss 1460,nop,nop,sackOK>
22:49:14.678962 IP 10.0.0.5.objective-dbc > ya.ru.http: S 2290750273:2290750273(0) win 16384 <mss 1460,nop,nop,sackOK>

 

Запросы по тунелю идут, а вот ответов почему-то нет. По логам в сквид ничего не приходит, хотя форвард пакетов есть - счетчик увеличивается.

# ipfw show
00100   103    4944 fwd 127.0.0.1,3128 tcp from any to any dst-port 80 recv gre0
65535 38366 6090184 allow ip from any to any

 

Сам сквид работает - пробовал стучаться через него напрямую.

 

Не понимаю, что ему еще нужно? Помогите плиз разобраться.

Share this post


Link to post
Share on other sites
Твой конфиг весь не читал. Но недавно сам решал аналогичную задачу, вот краткое описание как я это делал:

http://mschedrin.wordpress.com/2008/09/05/...-freebsd-squid/

В общем-то все так и сделано за исключением метода wccp2_forwarding_method, я сделал по умолчанию по GRE, вместо L2 - смысл городить огород, раз уж тунель есть.

 

Но суть в том, что пакеты по тунелю проходят в одну только сторону (от каталиста до интерфейса GRE), заворачиваются на порт сквида и вобщем-то на этом все заканчивается.

 

Из дебага каталиста кажется подозрительным вот это

4d11h: WCCP-PKT:S00: Sending I_See_You packet to 10.0.0.2 w/ rcv_id 0000003F
4d11h: WCCP-EVNT:wccp_update_assignment_status: enter
4d11h: WCCP-EVNT:wccp_update_assignment_status: exit
4d11h: WCCP-EVNT:wccp_validate_wc_assignments: enter
4d11h: WCCP-EVNT:wccp_validate_wc_assignments: not mask assignment, exit
4d11h: WCCP-PKT:S00: Sending I_See_You packet to 10.0.0.2 w/ rcv_id 00000040
4d11h: WCCP-EVNT:wccp_update_assignment_status: enter
4d11h: WCCP-EVNT:wccp_update_assignment_status: exit
4d11h: WCCP-EVNT:wccp_validate_wc_assignments: enter
4d11h: WCCP-EVNT:wccp_validate_wc_assignments: not mask assignment, exit
4d11h: WCCP-PKT:S00: Sending I_See_You packet to 10.0.0.2 w/ rcv_id 00000041

 

Как мне кажется тут должны идти пинги запрос/ответ, а тут только I_See_You...

Share this post


Link to post
Share on other sites

kostas,

ТЫ видимо не весь мой пост прочитал.

3750 умеет редиректить пакеты к проксе только через L2. Похоже, она просто подменяет destination mac в пакете пользователя. Получать пакеты обратно, однако, 3750 хочет уже только через GRE.
Ответ почему не работает напрашивается сам собой :)

Share this post


Link to post
Share on other sites

Может 3750 не умеет, а 6500 по крайней мере показывает что умеет

 

#sh ip wccp web-cache detail 
WCCP Cache-Engine information:
    Web Cache ID:          10.0.0.2
    Protocol Version:      2.0
    State:                 Usable
    Redirection:           GRE
    Packet Return:         GRE
    Assignment:            HASH
    Initial Hash Info:     00000000000000000000000000000000
                           00000000000000000000000000000000
    Assigned Hash Info:    FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
                           FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
    Hash Allotment:        256 (100.00%)
    Packets Redirected:    262
    Connect Time:          17:24:40

 

Да и в тунель запросы попадают, значит точно умеет. Но я пробовал и так и эдак, на всякий случай - результат тот же.

Edited by kostas

Share this post


Link to post
Share on other sites

Нужели у всех работает и подобных проблем небыло?

Share this post


Link to post
Share on other sites

На своей кошке сталкивался с такой проблемой. Т.к. на кошке нельзя явно указать source-интерфейс, с которого будут лететь gre-пакеты, мне на фряхе пришлось поднять по gre на каждый цисковский интерфейс, имеющий ip-адрес... Как правило оно в качестве source-адреса берет последний присвоеный какому-нибудь интефейсу ip-шник.

Share this post


Link to post
Share on other sites
На своей кошке сталкивался с такой проблемой. Т.к. на кошке нельзя явно указать source-интерфейс, с которого будут лететь gre-пакеты, мне на фряхе пришлось поднять по gre на каждый цисковский интерфейс, имеющий ip-адрес... Как правило оно в качестве source-адреса берет последний присвоеный какому-нибудь интефейсу ip-шник.
Упс, у меня вилан на человека и интерфейсов немерянно :(

И он постоянно меняется чтоли при добавлении нового интерфейса?

Share this post


Link to post
Share on other sites

Вы должны строить туннель с адресом на кошке 192.168.10.1 - тем, что указан в Router Identifier, иначе ничего не будет работать. Я голову себе сломал пока дошел до этого.

Share this post


Link to post
Share on other sites
Вы должны строить туннель с адресом на кошке 192.168.10.1 - тем, что указан в Router Identifier, иначе ничего не будет работать. Я голову себе сломал пока дошел до этого.
Так вроде так и строю

#sh ip wccp
Global WCCP information:
    Router information:
    Router Identifier:                   192.168.10.1
    Protocol Version:                    2.0

 

gre0: flags=d051<UP,POINTOPOINT,RUNNING,LINK0,LINK2,MULTICAST> mtu 1476
    tunnel inet 10.0.0.2 --> 192.168.10.1
    inet 1.1.1.1 --> 1.1.1.2 netmask 0xff000000

Share this post


Link to post
Share on other sites

Подниму тему.

Если автору удалось добиться работы wccp, то не будет ли он так любезен поделится рабочими конфигами?

У меня ситуация примерно такая-же. Настраиваю wccp между freebsd squid 2.7 и, правда, маршрутизатором cisco.

 

Cisco squid видит, но пакеты по gre между freebsd и cisco никак ходить не хотят. Хотя cisco при этом увеличивает счетчики перенаправленных пакетов. Веб естественно не работает.

Отдельно от cisco сквид работает нормально.

 

В логах и у цыски и у сквида только информация об успешном обмене I see you wccp пакетами.

Share this post


Link to post
Share on other sites

У меня заработал WCCP только после установки L2 redirect в сквиде.

 

wccp2_forwarding_method 2

 

Остальное по умолчанию.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this