snar

jimho, вы переупростили стенд, вот оно и не работает. Чего точно не хватает: igp (ospf/isis) между свитчами. Что точно сделано неправильно: туннель поднимается не между loopback-адресами (/32, должны быть известны и по igp и по ldp), а между интерфейсными. В результате: да, ldp поднят, туннельной меткой железки обмениваются. Но, поскольку транспортной метки до другой железки ни одна из них не знает - туннель и не работает... PS: как диагностировать на huawei, к сожалению, не подскажу, с этим оборудованием не работал. Но на наших жужиперах не завелось бы точно так же.

[edited] по витой паре класса utp5 таки не было[/edited] По более взрослой витой паре 1.2мм - было дело, не взлетело (~1км): http://xn--80ax0d.blogspot.com/2013/05/220.html ( рассказ со стороны клиента) https://netch.livejournal.com/21818.html (и со стороны оператора) ps: а bgp over dialup бывает ? :)

Читайте маны, они рулят. Как-то так: route delete default; route add default <gw> -ifa <loopback_ip>

ex9200, iirc, вполне себе на том же trio, что и mx. Ну и qfx10k уже не на броадкомах, а на своих чипах (в статье про это упоминалось).

С MTU по дороге всё в порядке ? Очень похоже.. (keepalive'ы маленькие и проходят, а update'ы жирные и дропаются, ретрансмитятся, опять дропаются... и так до истечения holdtime)

На входящем dial-peer'е нужно прописать direct-inward-dial.

Судя по тому, что в show chassis hardware отсутствует и Routing Engine и FPC - похоже на то. Что ещё можно попробовать - это "полную переустановку", через инсталляционную флешку. Ну и внимательно почитать логи на предмет "что же ему мешает запуститься"...

Мой конфиг чуть выше по триду приведён (ответ от 29 марта). IFL'ей создаётся два, один в сторону downstream с vlan push/pop (собственно QinQ), один в сторону uplink с указанием vlan-id на ifl. Описание vlan'а на уровне set vlan ... содержит только IFL'и, но ни в коем случае не vlan-id.

14.1X53-D46.7, на одном из портов в QinQ пакуются все vlan'ы (вообще все): flexible-vlan-tagging; native-vlan-id 1; mtu 9216; encapsulation extended-vlan-bridge; unit 0 { vlan-id-list 1-4094; input-vlan-map { push; vlan-id 734; } output-vlan-map pop; } вполне работает. При этом на свитче, разумеется, ещё пара сотен vlan'ов есть. Или имелся в виду какой-то другой конфиг ? Или я не понял, что именно не работает ? PS: не, если на свитче дополнительно к QinQ vlan'у, создать ещё и vlan с vlan-id 734 и разрешить его на аплинке (например, имплицитно, vlan members all) - да, тут может получиться тыква, но это всё-таки из разряда "сам себе злобный буратина".

Не надо искать конспирологию там, где это обьясняется гораздо проще. При переходе с поиска на страницу, в заголовке Referer указываются, в том числе, и те слова, по которым гугль/яндекс/... выдал эту страницу в поиске. Отдать эти слова конкуренту в наше время ajax и прочих google analytics - даже проще, чем два байта переслать. PS: на любимом нами forum.nag.ru снизу есть иконки twitter/facebook/g+/.. Которые подгружаются с этих сайтов и говорят их владельцам минимум о том, что "с такого-то ip интересовались такой-то страницей". А если у Вашего браузера есть кука этого сайта - так браузер и её отдаст, не задумываясь. А с учётом того, что куку можно выдать и при запросе иконки.. А с учётом того, что такие иконки есть почти на каждом сайте..

Если нужно принять все сети с маской больше или равными /5 и меньше или равными /18 - можно и проще, from route-filter 0.0.0.0/0 prefix-length-range /5-/18 i.e., префикс-фильтр вообще не нужен.   Работает то, что префикс попадает под оба правила.

а чтобы не попало "что не нужно" (например, /32'ые) prefix-list-filter можно дополнительно ограничить route-filter'ом, типа from { prefix-list-filter ${name} orlonger; route-filter 0.0.0.0/0 upto /24; } в результате пройдут только префиксы, которые попадают под оба правила. PS: при этом префикс-лист ни в коем случае не должен храниться в dynamic-db, иначе будет весело Ж:-(

Примерно так должно работать: клиентская сторона: flexible-vlan-tagging; native-vlan-id 1; encapsulation extended-vlan-bridge; unit 1497 { vlan-id-list 1-1497; input-vlan-map push; output-vlan-map pop; } unit 1498 { vlan-id-list 1498-2048; input-vlan-map push; output-vlan-map pop; } аплинковая сторона: flexible-vlan-tagging; mtu 9216; encapsulation flexible-ethernet-services; unit 0 { family ethernet-switching { interface-mode trunk; vlan { members all; } } } unit 1497 { encapsulation vlan-bridge; vlan-id 1497; } unit 1498 { encapsulation vlan-bridge; vlan-id 1498; } ну и, собственно, бридж между клиентской и аплинковой сторонами vlan NNN { interface ${client-facing}.1497; interface ${uplink-facing}.1497; } Важно: а) не забывать, что в vlan NNN ни в коем случае не должен быть указан vlan-id б) перед первым применением flexible-ethernet-services в сторону аплинка проверять в лабе (ну или на свободном интерфейсе) или оно действительно на этой версии JunOS и этом свитче работает (например, на 5110 в 15.1Xчто-то в результате применения этой команды аплинк просто падал нафиг. в 17.4R1 - работает). в) забыть про большую часть protocol-tunneling'ов (пропустить lacp/lldp/.. не получится, cdp/stp/vtp - только начиная с 17.4R1).

.... бага этой железки, которая втихую вычислила количество препендов делением ASN'а на 256... btw, это не первый случай за месяц: http://www.merit.edu/mail.archives/nanog/msg15730.html, просто в прошлый раз ASN был меньше, и получилось всего 177 препендов ;)

Да для себя любимого хоть по батарее можно перестукиваться. А если окучивать в мелкопромышленном масштабе клиента ? Открывать пункт приема списаных кошек у населения ? А вам действительно dialup over voip нужен в промышленном масштабе ? Не завидую.... :) У нас это нужно одному-двум клиентам на тысячу, соответственно, как только заходит речь "а у нас банк-клиент не работает" - если этот банк действительно работает только по модему, мы им без вопросов меняем оборудование, благо полкоробки старых аташек действительно есть... (btw, решил поинтересоваться, почему эта проблема давно не всплывала - оказывается, Сбербанка уже предоставляет клиент-банк через интернет). И на протяжении всего топика забывается одна очень простая вещь - клиенты разные. У которых разное понятие того, что же им будет удобно, и которым в результате нужно предоставлять несколько разные услуги. И что voip для части клиентов тупо неудобен... Некоторым удобнее получить телефонию по e1 - они ее получат по e1.. Некоторым удобнее забрать телефонию по sip на свой asterisk - они получат ее по sip на свой asterisk... Некоторым нужна одна-две-...-десять линий (зачастую с serial hunting, чтобы воткнуть эти линии в свой существующий панасоник) - пожалуйста, вот вам преднастроенные linksys'ы, и втыкайте туда аппараты или панасоник. Инженер (младший) используется ровно на этапе генерации конфига для этого linksys'а... Так что все вышеперечисленные решения - вполне тиражируемы, причем без напильника (более того, даже без asterisk'а - чуть подпиленного ser под эти задачи хватает). Те же (редкие) случаи когда клиент хочет получить "станцию без станции" (ip-pbx на провайдерском железе) - по пальцам посчитать можно. Как правило, если клиенту нужна станция - он ее уже поставил, и она у него работает, и он не хочет ее выкидывать. И не наше операторское дело настаивать на том, чтобы он ее выкинул... Но если все-таки очень захочет (или, например, если у него еще нету станции) - решения на asterisk'е имеют право на существование. Если вы, как оператор/интегратор ставите клиенту станцию на voip - то, простите, с вашим опытом у вас не должно возникнуть проблем с кодеками и интероперабельностью :)