Перейти к содержимому
Калькуляторы

ASR 1002 - IPOE

Коллеги всем добрый день.

Ситуация следующая. имеем стенд ASR1002 + коммутатор доступа длинк DES-3200-52 + биллинг Ланбиллинг. (IPOE)

 

до лога что я привел. абонент был подключен к 3-му (000402bc0003) порту коммутатора с remote id 0006acf1dfbc4250

далее я решил переткнуть абонента из 3-го порта в 1-й и посмотреть как там авторизация пройдет. при этом абоненту разрешено подключаться и в 1 порт.

но получаю облом.

 

стал смотреть логи и вижу:

 

.Jul 12 12:35:39.985: DHCPD: Reload workspace interface GigabitEthernet0/0/0.700 tableid 0.

.Jul 12 12:35:39.985: DHCPD: tableid for 46.148.255.254 on GigabitEthernet0/0/0.700 is 0

.Jul 12 12:35:39.985: DHCPD: client's VPN is .

.Jul 12 12:35:39.985: DHCPD: message is from trusted interface GigabitEthernet0/0/0.700

.Jul 12 12:35:39.985: DHCPD: using received relay info.

.Jul 12 12:35:39.985: DHCPD: Sending notification of DISCOVER:

.Jul 12 12:35:39.985: DHCPD: htype 1 chaddr fc75.161f.af65

 

> Это абонент в 1 порту

.Jul 12 12:35:39.985: DHCPD: remote id 0006acf1dfbc4250

.Jul 12 12:35:39.985: DHCPD: circuit id 000402bc0001

 

 

.Jul 12 12:35:39.985: DHCPD: interface = GigabitEthernet0/0/0.700

.Jul 12 12:35:39.986: DHCPD: class id 756468637020302e392e38

.Jul 12 12:35:39.986: DHCPD: DHCPDISCOVER received from client 01fc.7516.1faf.65 on interface GigabitEthernet0/0/0.700.

.Jul 12 12:35:39.986: DHCPD: using received relay info.

.Jul 12 12:35:39.986: DHCPD: Sending notification of DISCOVER:

.Jul 12 12:35:39.986: DHCPD: htype 1 chaddr fc75.161f.af65

.Jul 12 12:35:39.986: DHCPD: remote id 0006acf1dfbc4250

.Jul 12 12:35:39.986: DHCPD: circuit id 000402bc0001

.Jul 12 12:35:39.986: DHCPD: interface = GigabitEthernet0/0/0.700

.Jul 12 12:35:39.986: DHCPD: class id 756468637020302e392e38

.Jul 12 12:35:39.986: DHCPD: FSM state change WAIT-FOR-CONFIG

.Jul 12 12:35:39.986: DHCPD: Workspace state changed from INIT to WAIT-FOR-CONFIG

.Jul 12 12:35:39.986: DHCPD: Saving workspace (ID=0xE00012D)

.Jul 12 12:35:39.986: DHCPD: New packet workspace 0x3624653C (ID=0x3D00012E)

.Jul 12 12:35:39.987: SSS INFO: Element type is Access-Type = 18 (DHCP)

.Jul 12 12:35:39.987: SSS INFO: Element type is Protocol-Type = 4 (IP Access Protocol)

.Jul 12 12:35:39.987: SSS INFO: Element type is Media-Type = 2 (IP)

.Jul 12 12:35:39.987: SSS INFO: Element type is AccIe-Hdl = 2969567386 (B100009A)

.Jul 12 12:35:39.987: SSS INFO: Element type is AAA-Id = 165 (000000A5)

.Jul 12 12:35:39.987: SSS INFO: Element type is SHDB-Handle = 67109169 (04000131)

.Jul 12 12:35:39.987: SSS INFO: Element type is Input Interface = "GigabitEthernet0/0/0.700"

.Jul 12 12:35:39.987: SSS INFO: Element type is Mac-Address = fc75.161f.af65

 

> А ASR грит - "да нифига ты не на первом порту и ремоут ид твой вот такой". ну и в результате облом.

 

.Jul 12 12:35:39.987: SSS INFO: Element type is Circuit-id = "000402bc0003"

.Jul 12 12:35:39.987: SSS INFO: Element type is Remote-id = "011141432d46312d44462d42432d34322d3530"

 

.Jul 12 12:35:39.987: SSS INFO: Element type is Vendor-Class-id = "udhcp 0.9.8"

.Jul 12 12:35:39.987: SSS INFO: Element type is Restart = 1 (YES)

.Jul 12 12:35:39.987: SSS MGR [uid:154]: Sending a Session Assert ID Mgr request

.Jul 12 12:35:39.987: SSS MGR [uid:154]: Updating ID Mgr with the following keys:

 

Собственно вопрос, как цыске сказать чтоб забывала она прежние сведения о клиенте?

 

Сегодня ПНД и клинет прицепился :) за выходные осознала что не права была.

Jul 15 06:03:39.914: DHCPD: Sending notification of DISCOVER:

Jul 15 06:03:39.914: DHCPD: htype 1 chaddr fc75.161f.af65

Jul 15 06:03:39.914: DHCPD: remote id 0006acf1dfbc4250

Jul 15 06:03:39.914: DHCPD: circuit id 000402bc0001

Jul 15 06:03:39.914: DHCPD: interface = GigabitEthernet0/0/0.700

Jul 15 06:03:39.914: DHCPD: class id 756468637020302e392e38

Jul 15 06:03:39.914: DHCPD: DHCPDISCOVER received from client 01fc.7516.1faf.65 on interface GigabitEthernet0/0/0.700.

Jul 15 06:03:39.914: DHCPD: using received relay info.

Jul 15 06:03:39.914: DHCPD: Sending notification of DISCOVER:

Jul 15 06:03:39.914: DHCPD: htype 1 chaddr fc75.161f.af65

Jul 15 06:03:39.914: DHCPD: remote id 0006acf1dfbc4250

Jul 15 06:03:39.914: DHCPD: circuit id 000402bc0001

Jul 15 06:03:39.914: DHCPD: interface = GigabitEthernet0/0/0.700

Jul 15 06:03:39.914: DHCPD: class id 756468637020302e392e38

Jul 15 06:03:39.915: DHCPD: FSM state change WAIT-FOR-CONFIG

Jul 15 06:03:39.915: DHCPD: Workspace state changed from INIT to WAIT-FOR-CONFIG

Jul 15 06:03:39.915: DHCPD: Saving workspace (ID=0x37000131)

Jul 15 06:03:39.915: DHCPD: New packet workspace 0x36249C30 (ID=0x99000132)

Jul 15 06:03:39.915: SSS INFO: Element type is Access-Type = 18 (DHCP)

Jul 15 06:03:39.915: SSS INFO: Element type is Protocol-Type = 4 (IP Access Protocol)

Jul 15 06:03:39.915: SSS INFO: Element type is Media-Type = 2 (IP)

Jul 15 06:03:39.915: SSS INFO: Element type is AccIe-Hdl = 3909091484 (E900009C)

Jul 15 06:03:39.915: SSS INFO: Element type is AAA-Id = 167 (000000A7)

Jul 15 06:03:39.915: SSS INFO: Element type is SHDB-Handle = 4076863797 (F3000135)

Jul 15 06:03:39.915: SSS INFO: Element type is Input Interface = "GigabitEthernet0/0/0.700"

Jul 15 06:03:39.915: SSS INFO: Element type is Mac-Address = fc75.161f.af65

Jul 15 06:03:39.915: SSS INFO: Element type is Circuit-id = "000402bc0001"

Jul 15 06:03:39.915: SSS INFO: Element type is Remote-id = "0006acf1dfbc4250"

Jul 15 06:03:39.915: SSS INFO: Element type is Vendor-Class-id = "udhcp 0.9.8"

Jul 15 06:03:39.915: SSS MGR [uid:156]: Sending a Session Assert ID Mgr request

Jul 15 06:03:39.915: SSS MGR [uid:156]: Updating ID Mgr with the following keys:

 

 

Спасибо всем кто подскажет заветную команду.

Может ли это быть проблемой длинка?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Думаю это из-за lease time'а.

Попробуйте уменьшить lease и добавить мониторинг активных клиентов.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

выше я приводил с RELAY-пуллом на циске. DHCP сервер поднят на серверах ланбиллинга.

 

А вот этот лог был сделан уже без пулла через интерфейс loopback и ip unnumbered

Тут картина интереснее, ремоут иды уже совпадают а вот circuit id нет

 

 

.Jul 15 12:49:48.245: DHCPD: Reload workspace interface GigabitEthernet0/0/0.700 tableid 0.

.Jul 15 12:49:48.245: DHCPD: tableid for 46.148.255.254 on GigabitEthernet0/0/0.700 is 0

.Jul 15 12:49:48.245: DHCPD: client's VPN is .

.Jul 15 12:49:48.245: DHCPD: message is from trusted interface GigabitEthernet0/0/0.700

.Jul 15 12:49:48.245: DHCPD: using received relay info.

.Jul 15 12:49:48.245: DHCPD: Sending notification of DISCOVER:

.Jul 15 12:49:48.245: DHCPD: htype 1 chaddr fc75.161f.af65

.Jul 15 12:49:48.245: DHCPD: remote id 0006acf1dfbc4250

.Jul 15 12:49:48.245: DHCPD: circuit id 000402bc0001

.Jul 15 12:49:48.245: DHCPD: interface = GigabitEthernet0/0/0.700

.Jul 15 12:49:48.245: DHCPD: class id 756468637020302e392e38

.Jul 15 12:49:48.245: DHCPD: FSM state change WAIT-FOR-CONFIG

.Jul 15 12:49:48.245: DHCPD: Workspace state changed from INIT to WAIT-FOR-CONFIG

.Jul 15 12:49:48.246: DHCPD: Saving workspace (ID=0xB400016C)

.Jul 15 12:49:48.246: DHCPD: New packet workspace 0x40E30C5C (ID=0xFB00016D)

.Jul 15 12:49:48.246: SSS INFO: Element type is Access-Type = 18 (DHCP)

.Jul 15 12:49:48.246: SSS INFO: Element type is Protocol-Type = 4 (IP Access Protocol)

.Jul 15 12:49:48.246: SSS INFO: Element type is Media-Type = 2 (IP)

.Jul 15 12:49:48.246: SSS INFO: Element type is AccIe-Hdl = 1895825593 (710000B9)

.Jul 15 12:49:48.246: SSS INFO: Element type is AAA-Id = 196 (000000C4)

.Jul 15 12:49:48.246: SSS INFO: Element type is SHDB-Handle = 687866216 (29000168)

.Jul 15 12:49:48.246: SSS INFO: Element type is Input Interface = "GigabitEthernet0/0/0.700"

.Jul 15 12:49:48.246: SSS INFO: Element type is Mac-Address = fc75.161f.af65

.Jul 15 12:49:48.246: SSS INFO: Element type is Circuit-id = "000402bc0003"

.Jul 15 12:49:48.246: SSS INFO: Element type is Remote-id = "0006acf1dfbc4250"

.Jul 15 12:49:48.246: SSS INFO: Element type is Vendor-Class-id = "udhcp 0.9.8"

.Jul 15 12:49:48.246: SSS INFO: Element type is Restart = 1 (YES)

.Jul 15 12:49:48.246: SSS MGR [uid:185]: Sending a Session Assert ID Mgr request

.Jul 15 12:49:48.246: SSS MGR [uid:185]: Updating ID Mgr with the following keys:

 

 

Вот как это SSS INFO чистить? абонент подключен в нужный порт все разрешено но цыска грит а н нифига. ты в 3 порту и далее отстань.

к утро забудет и все опять будет ок.

 

Гуру, помогите плиз. я в этом деле новичек.

 

Думаю это из-за lease time'а.

Попробуйте уменьшить lease и добавить мониторинг активных клиентов.

 

Это где нужно прописывать? можно командочи или ссылку на мануал?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Добрый день, удалось решить?

Возникла похожая проблема -

НА свитче с маком 00219192d463 на 4-ом порту сидит абонент

со свитча до ASR идут правильные dhcp пакеты,

Circuit ID: 000408090004

Remote ID: 000600219192d463

на ASR в remote id появляется длинная билиберда,

VSA: l=40 t=Cisco-AVPair(1): remote-id-tag=020a000005e3800100000806

а circuit id вообще не передается, в итоге биллинг не понимает что ему прислали

VERBOSE 0x451ba940 [TryAuthISGByOpt82] Opt82 params: "800100000806", 0

и сессия не создается.

Собственно вопрос, кто с таким сталкивался? Проблема появилась не сразу, а при наличии около 1500 клиентских сессий и сейчас кол-во проблемных абонентов растет :(

При этом в это же время с других портов этих же свитчей dhcp пакеты обрабатываются нормально, абоненты работают

Проблема возникает с работавшими абонентами - т.е. абонент выключил компьютер, пошел спать, с утра включил компьютер - ip получил, интернета нет, звонит в техподдержку

Изменено пользователем mmvds

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Проблема решена откатом прошивки на ASR назад с 3.9 к 3.6!

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Проблема решена откатом прошивки на ASR назад с 3.9 к 3.6!

А почему сразу к 3.6 . 3.7 и 3.8 тоже так же себя ведут как 3.9?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Проблема решена откатом прошивки на ASR назад с 3.9 к 3.6!

А почему сразу к 3.6 . 3.7 и 3.8 тоже так же себя ведут как 3.9?

Потому что так сказал инженер из Cisco (неофициально) "в версии 3.7 мы кое что поменяли, попробуйте откатиться до 3.6", мы откатились, баг пропал.

Cisco попросили снова вернуться на новую прошивку и провести ряд тестов, но нам важнее чтоб юзеры работали СЕЙЧАС, а на железке живые клиенты, остались на 3.6

Поэтому если у кого-то аналогичная проблема, советую обратиться в саппорт циски, о проблеме они в курсе, м.б. вы поможете им с тестами

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Подниму старую тему. Коллеги Cisco баг пофиксила или так все и сидят на 3.6

Просто прислали мне тут пачку иосов от 3.6 до 3.10 вот и думаю на 3.6 висеть пока или 3.10 можно накатить?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.