SkyCaster Опубликовано 1 июня, 2010 · Жалоба Помогите о уважаемый гуру! Ситуация следующая. Есть сиска с настроенным (вроде) 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 - сессия поднимается, авторизуется, даже скорости навешиваются - в общем все работает. А вот когда сессии с этим ип нет и запускаешь пинги извне на этот _реальный ип_ - то пинги не проходят, сессия даже не пытается подниматься. Как только пинганешь с клиента и установится сессия - то пинги идти начинают. Что делать? Какие дебаги включать? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pliskinsad Опубликовано 1 июня, 2010 (изменено) · Жалоба А должно ли оно себя вести так, как вы хотите? Вот читаю сейчас документацию по ISG, там такая фраза есть как раз про портал: 1 ) a user session is created upon detection of a new IP SOUSE address. Some default services are applied. Да и на схеме однако сессию инициализирует клиент, что впринципе логично. Изменено 1 июня, 2010 пользователем pliskinsad Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
White_Alex Опубликовано 2 июня, 2010 · Жалоба Когда юзер с _реальным ип_ первым посылает какой-нить пакет (пинг тот же например) в сторону Te0/0/0.40- сессия поднимается, авторизуется, даже скорости навешиваются - в общем все работает. А вот когда сессии с этим ип нет и запускаешь пинги извне на этот _реальный ип_ - то пинги не проходят, сессия даже не пытается подниматься. Как только пинганешь с клиента и установится сессия - то пинги идти начинают. Что делать? Какие дебаги включать? все она делает именно так, как и должна Вы сам подумайте - если нет авторизованной сессии, с какой радости она должна трафик пускать?:-) у Вас стоит ip subscriber routed initiator unclassified ip-address что и подразумевает взлет сессии по первому пакету от абонента в сторону интернет Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
SkyCaster Опубликовано 4 июня, 2010 · Жалоба Когда юзер с _реальным ип_ первым посылает какой-нить пакет (пинг тот же например) в сторону Te0/0/0.40- сессия поднимается, авторизуется, даже скорости навешиваются - в общем все работает. А вот когда сессии с этим ип нет и запускаешь пинги извне на этот _реальный ип_ - то пинги не проходят, сессия даже не пытается подниматься. Как только пинганешь с клиента и установится сессия - то пинги идти начинают. Что делать? Какие дебаги включать? все она делает именно так, как и должна Вы сам подумайте - если нет авторизованной сессии, с какой радости она должна трафик пускать?:-) у Вас стоит ip subscriber routed initiator unclassified ip-address что и подразумевает взлет сессии по первому пакету от абонента в сторону интернет http://www.cisco.com/en/US/docs/ios/isg/co....html#wp1054732вот тут сказано что сессия может взлететь и по первому пакету из интернет в сторону абонента. Вроде бы. Но видно у меня мешает что-то. Вот как бы сказать сиске что вот на такой диапазон ип-шников чтоб сессия взлетали и по первому входящему трафику? Ибо представим себе ситуацию - есть абонент, с реальным ип, у него какой-нить веб-сервер, почтовый, или вообще впн. Трафик вначале с сервера особо не идет, или вообще сессия по таймауту отвалились... И все - сколько не долбись к нему извне - пока его сервер сам вначале что-нить в инет не зашлет - до клиента не достучаться :( Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
White_Alex Опубликовано 4 июня, 2010 · Жалоба http://www.cisco.com/en/US/docs/ios/isg/co....html#wp1054732вот тут сказано что сессия может взлететь и по первому пакету из интернет в сторону абонента. Вроде бы. Но видно у меня мешает что-то. Вот как бы сказать сиске что вот на такой диапазон ип-шников чтоб сессия взлетали и по первому входящему трафику? Ибо представим себе ситуацию - есть абонент, с реальным ип, у него какой-нить веб-сервер, почтовый, или вообще впн. Трафик вначале с сервера особо не идет, или вообще сессия по таймауту отвалились... И все - сколько не долбись к нему извне - пока его сервер сам вначале что-нить в инет не зашлет - до клиента не достучаться :( прочитал приведенную Вами цитату - ну и где там написано, что сессия взлетит по пакету снаружи? там есть только, что traffic flows идентифицируется в обе стороны на основании ip адреса абонента я говорю, это фича, а не баг, главное - объяснить это абоненту, они как правило сами придумывают что пинговать, чтобы сессия стояла:-) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
SkyCaster Опубликовано 2 июля, 2010 · Жалоба И снова я обращаюсь к вам о великие гуру. Насчет фичи а не бага я понял и смирился. Теперь у меня возникла другая проблема. У меня юзеры из сетки 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тп для начала. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...