Darwinggl

И как эти "другие" будут гарантировать SLA клиенту?

Тогда VRFы на циске + динамические маршруты между этими VRFами и "шейперами". Вместо VRF можно так же раскидать по PBRу. Если не надо заботиться о стейтах потоков, то можно сделать ECMP, если нужно, то active/active тут вряд ли выйдет, поэтому igp с разными метриками, vrrp, bgp или на что фантазии хватит.

Конкретика в книжках. Если ТС с голым конфигом выставил маршрутизатор наружу, то получит полный комплект всех возможных ошибок. В каких книжках? Какие ошибки? Вы по делу то можете ответить или нет?

Приведите, пожалуйста, пример, при котором в данной конфигурации может возникнуть роут луп. В текущей конфигурации. Тсс. Это следующий этап. Читать про BCOP и MANRS. Конкретика то будет?

Приведите, пожалуйста, пример, при котором в данной конфигурации может возникнуть роут луп. Как только ваша квагга станет транзитной. Ни одного access-list не прописано, что, так и будем какать своими серыми адресами в инет ? Ну есть же в инете куча примеров настроек bgp. Конфиги bgp что у киски, что у квагги, что у брокады - даже синтаксисом почти не отличаются. Ну так в текущем конфиге она не транзитная, это раз. Два, откуда возьмется роут луп? Серым адресам тоже взяться неоткуда, ведь прописан конкретный network и нет редистрибьюции.

Приведите, пожалуйста, пример, при котором в данной конфигурации может возникнуть роут луп.

О каких петлях идет речь?

Обычному клиенту никакие функции vCPE не нужны. А вот энтерпрайзу - да, терминация L2/L3 VPN, шифрование между бранчами, роутинг, мултикаст и все такое. А ШПД клиенту хватит и роутера за тысячу рублей, что бы натить и вайфай раздавать, все таки не для этих целей технология придумана :)

И никто не сказал, что vCPE это фишка для энтерпрайз сегмента, а не для ШПД :)

Похоже, что коннект рвет ваша сторона, при этом не посылая NOTIFICATION. Хорошо бы посмотреть в логи вашего спикера, а так же снять дамп bgp трафика в момент появления проблемы.

Клиент выбирает тот сервер, который ответил ему первым.Более производительный сервер заберёт на себя всех, поэтому для балансировки пппое-сервера должны быть идентичными. Как быть в таком случае? Ставить второй микротик, разумеется!

Кто первый ответил на PADI того клиент и выберет, если явно не указывать AC-Name на стороне клиента.

А что не RIP с unicast нейборами сразу?

Именно о невозможности использования BGP-SD я указал в топике :)

Приветствую, коллеги! Предположим такую ситуацию: в качестве PE используется какой-нибудь L3 коммутатор с маленьким RIB (посему всякие BGP-SD не помогут), с которого нужно отдать клиенту FV. Насколько я понимаю, проблему можно решить протянув от PE vpws до бордера, где есть fv, либо поднимать сессию с ebgp-multihop. Кто нибудь сталкивался с похожей проблемой, как решаете? Каков бест-практис? :)

core show channels с грепом?

Все верно. Up0 это физический интерфейс, а BRI это ISDN конфигурация, обеспечивающая 2B1D

А в фильтрах что? UPDATE с NLRI то приходит...

Спасибо за развернутый ответ. Является ли достаточным показателем умения раскидывать прерывания то, что top -SPH показывает по 8 прерываний на каждую igb сетевую карту? Каким образом при отключенном isr можно отслеживать потери пакетов (в целом на железке)? Кстати, вот тут какой-то японец писал про распределение пакетов по обработчикам isr в зависимости от значения хеш-функции от IP, номеров портов и т.д. проходящих потоков. Такое решение помогло бы в нашей ситуации - тогда пакеты в рамках одной сессии (или пары src-dst ip) гарантированно обрабатывались в одном потоке на одном ядре.

Привет Может кто-нибудь объяснить как между собой коррелируют нити netisr и прерывания igb очередей? Чем грозит отключение потоков в netisr? Отключить весь тюнинг не представляется возможным, т.к. через машину идет коммерческий трафик и какие-либо эксперименты не допустимы. Меня смущает еще вывод netstat -Q: #netstat -Q Configuration: Setting Current Limit Thread count 8 8 Default queue limit 4096 10240 Dispatch policy direct n/a Threads bound to CPUs disabled n/a Protocols: Name Proto QLimit Policy Dispatch Flags ip 1 10240 flow default --- igmp 2 4096 source default --- rtsock 3 1024 source default --- arp 7 4096 source default --- ether 9 4096 source direct --- Workstreams: WSID CPU Name Len WMark Disp'd HDisp'd QDrops Queued Handled 0 0 ip 0 1 27031259 0 0 2 27031261 0 0 igmp 0 0 0 0 0 0 0 0 0 rtsock 0 8 0 0 0 40144 40144 0 0 arp 0 0 17473797 0 0 0 17473797 0 0 ether 0 0 3424331738 0 0 0 3424331738 1 1 ip 0 0 868045497 0 0 0 868045497 1 1 igmp 0 0 0 0 0 0 0 1 1 rtsock 0 0 0 0 0 0 0 1 1 arp 0 0 0 0 0 0 0 1 1 ether 0 0 2833888542 0 0 0 2833888542 2 2 ip 0 1 705085703 0 0 2 705085705 2 2 igmp 0 0 0 0 0 0 0 2 2 rtsock 0 0 0 0 0 0 0 2 2 arp 0 0 0 0 0 0 0 2 2 ether 0 0 4245441054 0 0 0 4245441054 3 3 ip 0 1 841181863 0 0 2 841181865 3 3 igmp 0 0 0 0 0 0 0 3 3 rtsock 0 0 0 0 0 0 0 3 3 arp 0 0 0 0 0 0 0 3 3 ether 0 0 2898602573 0 0 0 2898602573 4 4 ip 0 0 1330342052 0 0 0 1330342052 4 4 igmp 0 0 0 0 0 0 0 4 4 rtsock 0 0 0 0 0 0 0 4 4 arp 0 0 0 0 0 0 0 4 4 ether 0 0 2726208890 0 0 0 2726208890 5 5 ip 0 0 1108369835 0 0 0 1108369835 5 5 igmp 0 0 0 0 0 0 0 5 5 rtsock 0 0 0 0 0 0 0 5 5 arp 0 0 0 0 0 0 0 5 5 ether 0 0 3434355155 0 0 0 3434355155 6 6 ip 0 14 1302603711 0 0 33066832 1335667822 6 6 igmp 0 0 0 0 0 0 0 6 6 rtsock 0 0 0 0 0 0 0 6 6 arp 0 0 0 0 0 0 0 6 6 ether 0 0 2909362322 0 0 0 2909362322 7 7 ip 0 0 1262496778 0 0 0 1262496778 7 7 igmp 0 0 0 0 0 0 0 7 7 rtsock 0 0 0 0 0 0 0 7 7 arp 0 0 0 0 0 0 0 7 7 ether 0 0 2980323173 0 0 0 2980323173 Почему-то счетчик Queued растет только на 6 WSID для пакетов типа IP.

да точно, и всё таки, как пайпы конфигурите? Кроме дамминета в фаерволе ещё что-нибудь есть? Кроме дамминета в фаерволе больше ничего нет. Пайпы: pipe tablearg ip from any to table(16) out via vlan* pipe tablearg ip from table(17) to any in via vlan* В таблице абонентские сети привязываются к пайпам. Пайпы 12.000 Mbit/s 0 ms burst 0 q131136 50 sl. 0 flows (1 buckets) sched 65600 weight 0 lmax 0 pri 0 droptail sched 65600 type FIFO flags 0x1 32768 buckets 14 active mask: 0x00 0x00000000/0x0000 -> 0xffffffff/0x0000 12.000 Mbit/s 0 ms burst 0 q131104 50 sl. 0 flows (1 buckets) sched 65568 weight 0 lmax 0 pri 0 droptail sched 65568 type FIFO flags 0x1 32768 buckets 4 active mask: 0x00 0xffffffff/0x0000 -> 0x00000000/0x0000

Я же писал...

надо видеть дамп... интересно, там netisr включен или выключен?... что касается netisr # sysctl net.isr net.isr.numthreads: 16 net.isr.maxprot: 16 net.isr.defaultqlimit: 4096 net.isr.maxqlimit: 10240 net.isr.bindthreads: 0 net.isr.maxthreads: 16 net.isr.direct: 0 net.isr.direct_force: 0 net.isr.dispatch: direct По поводу дампа, тут все просто, был написан скрипт, который воспроизводит данную проблему. Скрипт генерирует UDP пакеты разной длины и шлет их через FreeBSD'шный шлюз в заданной последовательности: На входе (igb0) картина такая: IP 1.1.1.1.5060 > 2.2.2.2.5060: SIP, length: 615 IP 1.1.1.1.5060 > 2.2.2.2.5060: SIP, length: 492 IP 1.1.1.1.5060 > 2.2.2.2.5060: SIP, length: 615 IP 1.1.1.1.5060 > 2.2.2.2.5060: SIP, length: 492 А на выходе (vlan интерфейс): IP 1.1.1.1.5060 > 2.2.2.2.5060: SIP, length: 615 IP 1.1.1.1.5060 > 2.2.2.2.5060: SIP, length: 492 IP 1.1.1.1.5060 > 2.2.2.2.5060: SIP, length: 492 IP 1.1.1.1.5060 > 2.2.2.2.5060: SIP, length: 615 Как видно, порядок пакетов при прохождении через шлюз изменился.

ifconfig_igb1="inet XX.XX.XX.XX netmask 255.255.255.128 up -rxcsum -txcsum -promisc -lro" ifconfig_igb2="up -rxcsum -txcsum -lro -promisc "

Это не означает, что можно невозбранно терять и менять порядок следования пакетов.