помогите с policy-map для ISG

[SkyCaster]

Помогите о уважаемый гуру!

 

Ситуация следующая. Есть сиска с настроенным (вроде) ISG. По-минимуму, по-спартански - правильный ип в инет пускаем, неправильный ип редиректим на портал. Настройки такие:

сервис:

policy-map type service LocServ4Redirect
  service local
  class type traffic CLASS-FOR-REDIRECT
   redirect to ip <portal_ip> port 80
  !
  class type traffic default in-out
   drop
  !
!

полиси:

policy-map type control ISG-POLICY
  class type control ISG-IP-UNAUTH event timed-policy-expiry
    1 service disconnect
  !
  class type control always event session-start
    10 authorize aaa list ISG-AUTH-1 password ISGPSWRD identifier source-ip-address
    20 service-policy type service name LocServ4Redirect
    30 set-timer IP-UNAUTH-TIMER 5
  !
!

интерфейс куда воткнуты юзеры

interface TenGigabitEthernet0/0/0.40
  encapsulation dot1Q 40
  ip address 10.7.0.8 255.255.255.0
  ip nat inside
  ip flow ingress
  ip flow egress
  ip virtual-reassembly
  service-policy type control ISG-POLICY
  ip subscriber routed
    initiator unclassified ip-address

 

интерфейс где аплинк -

interface TenGigabitEthernet0/0/0.4100
  encapsulation dot1Q 4100
  ip address 100.200.300.400 255.255.255.248
  ip nat outside
  ip virtual-reassembly

 

Когда юзер с _реальным ип_ первым посылает какой-нить пакет (пинг тот же например) в сторону Te0/0/0.40

- сессия поднимается, авторизуется, даже скорости навешиваются - в общем все работает.

А вот когда сессии с этим ип нет и запускаешь пинги извне на этот _реальный ип_ - то пинги не проходят, сессия даже не пытается подниматься. Как только пинганешь с клиента и установится сессия - то пинги идти начинают.

 

Что делать? Какие дебаги включать?

 

[pliskinsad]

А должно ли оно себя вести так, как вы хотите?

Вот читаю сейчас документацию по ISG, там такая фраза есть как раз про портал:

1 ) a user session is created upon detection of a new IP SOUSE address. Some default services are applied.

Да и на схеме однако сессию инициализирует клиент, что впринципе логично.

Edited June 1, 2010 by pliskinsad

[White_Alex]

Когда юзер с _реальным ип_ первым посылает какой-нить пакет (пинг тот же например) в сторону Te0/0/0.40

- сессия поднимается, авторизуется, даже скорости навешиваются - в общем все работает.

А вот когда сессии с этим ип нет и запускаешь пинги извне на этот _реальный ип_ - то пинги не проходят, сессия даже не пытается подниматься. Как только пинганешь с клиента и установится сессия - то пинги идти начинают.

 

Что делать? Какие дебаги включать?

все она делает именно так, как и должна

Вы сам подумайте - если нет авторизованной сессии, с какой радости она должна трафик пускать?:-)

у Вас стоит

ip subscriber routed

initiator unclassified ip-address

что и подразумевает взлет сессии по первому пакету от абонента в сторону интернет

[SkyCaster]

Когда юзер с _реальным ип_ первым посылает какой-нить пакет (пинг тот же например) в сторону Te0/0/0.40

- сессия поднимается, авторизуется, даже скорости навешиваются - в общем все работает.

А вот когда сессии с этим ип нет и запускаешь пинги извне на этот _реальный ип_ - то пинги не проходят, сессия даже не пытается подниматься. Как только пинганешь с клиента и установится сессия - то пинги идти начинают.

 

Что делать? Какие дебаги включать?

все она делает именно так, как и должна

Вы сам подумайте - если нет авторизованной сессии, с какой радости она должна трафик пускать?:-)

у Вас стоит

ip subscriber routed

initiator unclassified ip-address

что и подразумевает взлет сессии по первому пакету от абонента в сторону интернет

http://www.cisco.com/en/US/docs/ios/isg/co....html#wp1054732

вот тут сказано что сессия может взлететь и по первому пакету из интернет в сторону абонента. Вроде бы. Но видно у меня мешает что-то. Вот как бы сказать сиске что вот на такой диапазон ип-шников чтоб сессия взлетали и по первому входящему трафику?

Ибо представим себе ситуацию - есть абонент, с реальным ип, у него какой-нить веб-сервер, почтовый, или вообще впн. Трафик вначале с сервера особо не идет, или вообще сессия по таймауту отвалились... И все - сколько не долбись к нему извне - пока его сервер сам вначале что-нить в инет не зашлет - до клиента не достучаться :(

[White_Alex]

http://www.cisco.com/en/US/docs/ios/isg/co....html#wp1054732

вот тут сказано что сессия может взлететь и по первому пакету из интернет в сторону абонента. Вроде бы. Но видно у меня мешает что-то. Вот как бы сказать сиске что вот на такой диапазон ип-шников чтоб сессия взлетали и по первому входящему трафику?

Ибо представим себе ситуацию - есть абонент, с реальным ип, у него какой-нить веб-сервер, почтовый, или вообще впн. Трафик вначале с сервера особо не идет, или вообще сессия по таймауту отвалились... И все - сколько не долбись к нему извне - пока его сервер сам вначале что-нить в инет не зашлет - до клиента не достучаться :(

прочитал приведенную Вами цитату - ну и где там написано, что сессия взлетит по пакету снаружи? там есть только, что traffic flows идентифицируется в обе стороны на основании ip адреса абонента

я говорю, это фича, а не баг, главное - объяснить это абоненту, они как правило сами придумывают что пинговать, чтобы сессия стояла:-)

[SkyCaster]

И снова я обращаюсь к вам о великие гуру. Насчет фичи а не бага я понял и смирился. Теперь у меня возникла другая проблема.

У меня юзеры из сетки 10.0.0.0/8

 

Хочу на том же интерфейсе принимать l2tp сессии (юзеры будут идти с тех же ип-адресов 10.0.0.0/8). Но не могу. Если убрать блок

 

service-policy type control ISG-POLICY

ip subscriber routed

initiator unclassified ip-address

 

то сессии л2тп взлетают, но как только ставлю например

ip subscriber routed

initiator unclassified ip-address

л2тп сессии взлетают, но перестают идти пинги.

если убрать

initiator unclassified ip-address

и оставить только

ip subscriber routed

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