ats

В общем рассматриваю модель без dynamic-profile. Собрал следующий конфиг: ats@MX-204_QinQ# show interfaces xe-0/0/3:1 stacked-vlan-tagging; mtu 9000; unit 179 { vlan-tags outer 0x8100.179 inner-range 0x8100.50-300; family inet { address 100.64.0.1/20; } } Никаких SM все просто. Есть arp запись для клиента. Есть маршрут. Однако с клиента 100.64.0.3 нет пинга до роутера. S-Vlan 179, C-Vlan 100 попадает в диапазон inner-range 0x8100.50-300. Ответ нашел не сразу: ats@MX-204_QinQ# run monitor traffic interface xe-0/0/3:1 detail layer2-headers Address resolution is ON. Use <no-resolve> to avoid any reverse lookup delay. Address resolution timeout is 4s. Listening on xe-0/0/3:1, capture size 1514 bytes Reverse lookup for 100.64.0.1 failed (check DNS reachability). Other reverse lookup failures will not be reported. Use <no-resolve> to avoid reverse lookups on IP addresses. 00:14:08.963656 In 70:5a:0f:22:2c:e8 > Broadcast, ethertype 802.1Q (0x8100), length 68: vlan 179, p 0, ethertype 802.1Q, vlan 100, p 0, ethertype ARP, arp who-has 100.64.0.1 tell 100.64.0.3 00:14:08.963698 Out 78:50:7c:41:41:dc > 70:5a:0f:22:2c:e8, ethertype 802.1Q (0x8100), length 46: vlan 50, p 0, ethertype ARP, arp reply 100.64.0.1 is-at 78:50:7c:41:41:dc 00:14:09.988087 In 70:5a:0f:22:2c:e8 > Broadcast, ethertype 802.1Q (0x8100), length 68: vlan 179, p 0, ethertype 802.1Q, vlan 100, p 0, ethertype ARP, arp who-has 100.64.0.1 tell 100.64.0.3 00:14:09.988120 Out 78:50:7c:41:41:dc > 70:5a:0f:22:2c:e8, ethertype 802.1Q (0x8100), length 46: vlan 50, p 0, ethertype ARP, arp reply 100.64.0.1 is-at 78:50:7c:41:41:dc 00:14:11.011662 In 70:5a:0f:22:2c:e8 > Broadcast, ethertype 802.1Q (0x8100), length 68: vlan 179, p 0, ethertype 802.1Q, vlan 100, p 0, ethertype ARP, arp who-has 100.64.0.1 tell 100.64.0.3 00:14:11.011696 Out 78:50:7c:41:41:dc > 70:5a:0f:22:2c:e8, ethertype 802.1Q (0x8100), length 46: vlan 50, p 0, ethertype ARP, arp reply 100.64.0.1 is-at 78:50:7c:41:41:dc Приходящий пакет приходит в 100 влане, а отправляется назад в 50.. В минимальный указанный в inner-range. Что ему не хватает? Почему так? https://www.juniper.net/documentation/en_US/junos/topics/reference/configuration-statement/vlan-tags-edit-interfaces.html Вариант не оптимальный судя по доке, но не нерабочий же?

Не гибок, по тому что нет возможности купить только то что нужно. Мне нужна терминация QinQ C-Vlan. Мне не нужен полноценный сервис-роутер. И платить более 2М за лицензии на 64 К я естественно не хочу.

Это понято, вопрос был организовать терминацию по указанной выше схеме без вложения в лицензию, учитывая что железка не должна быть ни dhcp ни брасом. Нужен роутер на термниацию, а не мультикомбайн все в одном. К сожалению juniper не гибок. и не годится для решения простых задач.

То есть то что работало на 13.3 по сути являлось дыркой, которую в 15.1 и выше прикрыли? И задача для MX-204 в этом виде не имеет решения?

Я не указываю demux в dynamic-profile но в интерфейсе вижу: ts@MX-204_QinQ> show interfaces xe-0/0/3:0.3221225531 detail Logical interface xe-0/0/3:0.3221225531 (Index 536871035) (SNMP ifIndex 200000123) (Generation 115) Flags: Up VLAN-Tag [ 0x8100.179 0x8100.100 ] Encapsulation: ENET2 Demux: Underlying interface: xe-0/0/3:0 (Index 160) Bandwidth: 0 Traffic statistics: Input bytes : 27375 Output bytes : 3876 Input packets: 412 Output packets: 47 Local statistics: Input bytes : 3900 Output bytes : 3876 Input packets: 47 Output packets: 47 Transit statistics: Input bytes : 23475 5408 bps Output bytes : 0 0 bps Input packets: 365 11 pps Output packets: 0 0 pps Protocol inet, MTU: 1500 Max nh cache: 0, New hold nh limit: 0, Curr nh cnt: 0, Curr new hold cnt: 0, NH drop cnt: 0 Generation: 0, Route table: 0 Flags: Unnumbered Donor interface: lo0.0 (Index 64) Input Filters: QinQ_230-xe-0/0/3:0.3221225531-in Addresses, Flags: Is-Primary Destination: Unspecified, Local: 100.96.0/20, Broadcast: Unspecified, Generation: 0 Для сравнения на 104 : ats@junmx104core> show interfaces xe-2/0/0.1073853620 detail Logical interface xe-2/0/0.1073853620 (Index 330) (SNMP ifIndex 93959) (Generation 111766) Flags: Up SNMP-Traps 0x0 VLAN-Tag [ 0x8100.179 0x8100.100 ] Encapsulation: ENET2 Traffic statistics: Input bytes : 973065 Output bytes : 732965 Input packets: 11876 Output packets: 8003 Local statistics: Input bytes : 398500 Output bytes : 479102 Input packets: 4769 Output packets: 4769 Transit statistics: Input bytes : 574565 0 bps Output bytes : 253863 0 bps Input packets: 7107 0 pps Output packets: 3234 0 pps Protocol inet, MTU: 8978, Generation: 223361, Route table: 0 Flags: Sendbcast-pkt-to-re, Unnumbered Donor interface: lo0.0 (Index 321) Input Filters: test_new-xe-2/0/0.1073853620-in Addresses, Flags: Is-Default Is-Preferred Is-Primary Destination: 100.96.0/20, Local: 100.96.0.1, Broadcast: Unspecified, Generation: 472 Protocol multiservice, MTU: Unlimited, Generation: 223362, Route table: 0 Policer: Input: __default_arp_policer__

Доброго 204 относительно новый, на нем нет ПО 13 версии. На 204 интерфейс собирается но криво, с демуксом, нет арп записи для клиента, нет роута до клиента

Доброго, нужно терминировать абонентские QinQ С-Vlan DHCP через juniper не проходит. Есть конфиг который работает на МХ-104 13.3 но не работает на MX-204 18.2 Файл с примером конфигураций на обоих устройствах и описанием действий прикрепил. Перенос конфигурации с MX-104 на MX-204

Похоже, что начиная с 15 версии софта изменилась логика работы и та конфигурация что работала на 13.3 на версиях старше 15 работать не будет. Так как для dynamic-profile по умолчанию работает demux. Как обойти пока не ясно.

Хм.. отличие в том что на 204 присутствует demux... ats@MX-204_QinQ> show interfaces xe-0/0/3:0.3221225524 detail Logical interface xe-0/0/3:0.3221225524 (Index 536871025) (SNMP ifIndex 200000113) (Generation 105) Flags: Up VLAN-Tag [ 0x8100.179 0x8100.100 ] Encapsulation: ENET2 Demux: Underlying interface: xe-0/0/3:0 (Index 160) Bandwidth: 0 Traffic statistics: Input bytes : 6019183 Output bytes : 836676 Input packets: 90605 Output packets: 10042 Local statistics: Input bytes : 838932 Output bytes : 836676 Input packets: 10041 Output packets: 10041 Transit statistics: Input bytes : 5180251 7688 bps Output bytes : 0 672 bps Input packets: 80564 15 pps Output packets: 1 1 pps Protocol inet, MTU: 1500 Max nh cache: 0, New hold nh limit: 0, Curr nh cnt: 0, Curr new hold cnt: 0, NH drop cnt: 0 Generation: 0, Route table: 0 Flags: Unnumbered Donor interface: lo0.0 (Index 64) Input Filters: QinQ_230-xe-0/0/3:0.3221225524-in Addresses, Flags: Is-Primary Destination: Unspecified, Local: 100.96.0/20, Broadcast: Unspecified, Generation: 0 Вопрос как его выпилить если вообще возможно. В логах роутера есть такие сообщения: Apr 15 13:50:30 Received async msg for ifl demux0.-2147483647 Apr 15 13:50:30 Received add async msg for ifl demux0.-2147483647 Apr 15 13:50:30 session 0 not found to attach ifl demux0.-2147483647, index 337 to session Apr 15 13:50:30 autoconfd_add_ifl: ifl demux0.-2147483647 added, index 0x151, gen num 4, ifl session 0 phy dev-index 152 Apr 15 13:50:30 Received async msg for ifd xe-0/0/3:0 Apr 15 13:50:30 Received chg async msg for ifd xe-0/0/3:0 Apr 15 13:50:30 In Parse TLV: rtsm info len 14 for xe-0/0/3:0 Apr 15 13:50:30 In Parse TLV: found autoconf info for xe-0/0/3:0 Apr 15 13:50:30 In Parse TLV: autoconf, vlan profs 0, svlan profs 1 vlan orides 0 svlan orides 0 Apr 15 13:50:30 In Parse TLV: xe-0/0/3:0: tpid 0x8100 Apr 15 13:50:30 Received async msg for ifl demux0.-2147483647 Apr 15 13:50:30 Received chg async msg for ifl demux0.-2147483647 Apr 15 13:50:31 autoconfd_authd_connect: Attempt to connect to authd Apr 15 13:50:31 autoconfd_authd_connect: Error connecting to authd, will retry: 12 - Failure Apr 15 13:50:31 autoconfd_authd_retry() Apr 15 13:50:35 autoconfd_authd_connect: Attempt to connect to authd Apr 15 13:50:35 autoconfd_authd_connect: Error connecting to authd, will retry: 12 - Failure Apr 15 13:50:35 autoconfd_authd_retry()

Видимо Juniper является dhcp сервером? У меня он не брас и не dhcp. Только треминация а далее я unnumbered вешаю его в dynamic-profile.. В общем изменения ни к чему не приводят. Не работает

Чудеса ... с клиента до роутера проходит пинг, но arp записи на роутере нет... Соответсвено клиент не пингуется. При этом с клиента роутер пингуется и арп запись есть... Listening on xe-0/0/3:0, capture size 1514 bytes Reverse lookup for 100.96.0.1 failed (check DNS reachability). Other reverse lookup failures will not be reported. Use <no-resolve> to avoid reverse lookups on IP addresses. 15:18:28.916970 In arp who-has 100.96.0.1 tell 100.96.0.3 15:18:28.918041 Out 78:50:7c:41:41:db > 33:33:00:01:00:02 Null Information, send seq 67, rcv seq 110, Flags [Poll], length 7678:50:7c:41:41:db > 33:33:00:01:00:02, 802.3, length 0: 0000 86dd 6000 0000 0020 0001 fe80 0000 0000 0000 7a50 7cff fe41 41db ff02 0000 0000 0000 0000 0000 0001 0002 3a00 0100 0502 0000 8300 48b3 0000 0000 ff02 0000 0000 0000 0000 0000 0001 0002 5420 945e 0000 0000 a802 0e00 0000 15:18:28.918184 Out 78:50:7c:41:41:db > 33:33:00:01:00:03 Null Information, send seq 67, rcv seq 110, Flags [Poll], length 7678:50:7c:41:41:db > 33:33:00:01:00:03, 802.3, length 0: 0000 86dd 6000 0000 0020 0001 fe80 0000 0000 0000 7a50 7cff fe41 41db ff05 0000 0000 0000 0000 0000 0001 0003 3a00 0100 0502 0000 8300 48ab 0000 0000 ff05 0000 0000 0000 0000 0000 0001 0003 5420 945e 0000 0000 9f04 0e00 0000 15:18:28.918687 Out arp reply 100.96.0.1 is-at 78:50:7c:41:41:db 15:18:28.919147 In IP (tos 0x0, ttl 64, id 60116, offset 0, flags [DF], proto: TCP (6), length: 60) 100.96.0.3.43050 > 5.255.86.129.https: S 2347123414:2347123414(0) win 64240 <mss 1460,sackOK,timestamp 1323311388 0,nop,wscale 7> 15:18:29.036770 In IP (tos 0x0, ttl 64, id 14228, offset 0, flags [DF], proto: ICMP (1), length: 84) 100.96.0.3 > 100.96.0.1: ICMP echo request, id 24413, seq 13745, length 64 15:18:29.036876 Out IP (tos 0xc0, ttl 255, id 0, offset 0, flags [DF], proto: ICMP (1), length: 84) 100.96.0.1 > 100.96.0.3: ICMP echo reply, id 24413, seq 13745, length 64 15:18:30.057148 In IP (tos 0x0, ttl 64, id 14251, offset 0, flags [DF], proto: ICMP (1), length: 84) 100.96.0.3 > 100.96.0.1: ICMP echo request, id 24413, seq 13746, length 64 15:18:30.057269 Out IP (tos 0xc0, ttl 255, id 0, offset 0, flags [DF], proto: ICMP (1), length: 84) 100.96.0.1 > 100.96.0.3: ICMP echo reply, id 24413, seq 13746, length 64 15:18:31.058849 In IP (tos 0x0, ttl 64, id 14380, offset 0, flags [DF], proto: ICMP (1), length: 84) 100.96.0.3 > 100.96.0.1: ICMP echo request, id 24413, seq 13747, length 64 15:18:31.058968 Out IP (tos 0xc0, ttl 255, id 0, offset 0, flags [DF], proto: ICMP (1), length: 84) 100.96.0.1 > 100.96.0.3: ICMP echo reply, id 24413, seq 13747, length 64 15:18:31.999707 Out 78:50:7c:41:41:db > 33:33:00:01:00:03 Null Information, send seq 67, rcv seq 110, Flags [Poll], length 7678:50:7c:41:41:db > 33:33:00:01:00:03, 802.3, length 0: 0000 86dd 6000 0000 0020 0001 fe80 0000 0000 0000 7a50 7cff fe41 41db ff05 0000 0000 0000 0000 0000 0001 0003 3a00 0100 0502 0000 8300 48ab 0000 0000 ff05 0000 0000 0000 0000 0000 0001 0003 5820 945e 0000 0000 8bea 0000 0000 15:18:32.060043 In IP (tos 0x0, ttl 64, id 14597, offset 0, flags [DF], proto: ICMP (1), length: 84) 100.96.0.3 > 100.96.0.1: ICMP echo request, id 24413, seq 13748, length 64 15:18:32.060151 Out IP (tos 0xc0, ttl 255, id 0, offset 0, flags [DF], proto: ICMP (1), length: 84) 100.96.0.1 > 100.96.0.3: ICMP echo reply, id 24413, seq 13748, length 64 15:18:33.065061 In IP (tos 0x0, ttl 64, id 14740, offset 0, flags [DF], proto: ICMP (1), length: 84) 100.96.0.3 > 100.96.0.1: ICMP echo request, id 24413, seq 13749, length 64 15:18:33.065176 Out IP (tos 0xc0, ttl 255, id 0, offset 0, flags [DF], proto: ICMP (1), length: 84) 100.96.0.1 > 100.96.0.3: ICMP echo reply, id 24413, seq 13749, length 64 15:18:33.268691 Out 78:50:7c:41:41:db > 33:33:00:01:00:02 Null Information, send seq 67, rcv seq 110, Flags [Poll], length 7678:50:7c:41:41:db > 33:33:00:01:00:02, 802.3, length 0: 0000 86dd 6000 0000 0020 0001 fe80 0000 0000 0000 7a50 7cff fe41 41db ff02 0000 0000 0000 0000 0000 0001 0002 3a00 0100 0502 0000 8300 48b3 0000 0000 ff02 0000 0000 0000 0000 0000 0001 0002 5a20 945e 0000 0000 3d02 0100 0000 15:18:34.066109 In IP (tos 0x0, ttl 64, id 14946, offset 0, flags [DF], proto: ICMP (1), length: 84) 100.96.0.3 > 100.96.0.1: ICMP echo request, id 24413, seq 13750, length 64 15:18:34.066244 Out IP (tos 0xc0, ttl 255, id 0, offset 0, flags [DF], proto: ICMP (1), length: 84) 100.96.0.1 > 100.96.0.3: ICMP echo reply, id 24413, seq 13750, length 64 ^Z15:18:35.081025 In IP (tos 0x0, ttl 64, id 15098, offset 0, flags [DF], proto: ICMP (1), length: 84) 100.96.0.3 > 100.96.0.1: ICMP echo request, id 24413, seq 13751, length 64 15:18:35.081158 Out IP (tos 0xc0, ttl 255, id 0, offset 0, flags [DF], proto: ICMP (1), length: 84) 100.96.0.1 > 100.96.0.3: ICMP echo reply, id 24413, seq 13751, length 64 ^C 21 packets received by filter 0 packets dropped by kernel Конфиг роутера: <details open>скрытое/показанное содержимое system { configuration-database { max-db-size 104857600; } services { ssh { root-login deny; } subscriber-management { traceoptions { file test_auto.log size 4096000 files 10; flag all; } enable; } } } dynamic-profiles { interfaces { xe-0/0/3:0 { flexible-vlan-tagging; auto-configure { stacked-vlan-ranges { dynamic-profile QinQ_230 { accept [ inet any ]; ranges { 179-180,any; } } } } mtu 9000; } QinQ_230 { interfaces { "$junos-interface-ifd-name" { unit "$junos-interface-unit" { description QinQ_230-profile; proxy-arp restricted; vlan-tags outer "$junos-stacked-vlan-id" inner "$junos-vlan-id"; mrru 9000; family inet { filter { input QinQ_230; } policer { arp arp4k; } unnumbered-address lo0.0; } } } } } } chassis { network-services enhanced-ip; } lo0 { unit 0 { family inet { address 100.96.0.1/20; } } } } firewall { family inet { filter QinQ_230 { interface-specific; term QinQ_local_traff { from { source-address { 100.64.0.0/10; } destination-address { 100.64.0.0/10; } } then { count inet_local_100.64; accept; } } term QinQ_local_server { from { source-address { 100.64.0.0/10; } destination-address { 94.232.104.0/21; } } then { count inet_local_100.64; accept; } } term QinQ_inet { from { source-address { 100.96.0.0/20; } } then { count to-inet-from-100.64; next-interface { xe-0/1/0.0; } } } } } } </details>

Хм инетресно... На MX 204 инетрфейс создается, но нет arp записи для клиента. Соответсвенно ничего не работает. Разница со 104: Это на 204 100.96.0.0/20 *[Direct/0] 6d 20:49:48 > via lo0.0 100.96.0.1/32 *[Local/0] 5d 17:11:51 Local via lo0.0 А это на 104: 100.96.0.0/20 *[Direct/0] 4d 18:47:00 > via lo0.0 100.96.0.1/32 *[Local/0] 4d 18:47:00 Local via xe-2/0/0.1073853620 То есть на 204 адрес на интерфейс не попадает... В рамках интерфеса есть отличие на 104 есть такая запись: Policer: Input: __default_arp_policer__ На 204 нет...

Спасибо, в таком виде получилось. интерфейс с фильтром создается, интернет работает. Проверял на MX-104 софт 13.3 Попробую перенести на MX-204 софт 18.2 ats@junmx104core> show interfaces xe-2/0/0.1073853620 detail Logical interface xe-2/0/0.1073853620 (Index 330) (SNMP ifIndex 93959) (Generation 111766) Flags: Up SNMP-Traps 0x0 VLAN-Tag [ 0x8100.179 0x8100.100 ] Encapsulation: ENET2 Traffic statistics: Input bytes : 973065 Output bytes : 732965 Input packets: 11876 Output packets: 8003 Local statistics: Input bytes : 398500 Output bytes : 479102 Input packets: 4769 Output packets: 4769 Transit statistics: Input bytes : 574565 0 bps Output bytes : 253863 0 bps Input packets: 7107 0 pps Output packets: 3234 0 pps Protocol inet, MTU: 8978, Generation: 223361, Route table: 0 Flags: Sendbcast-pkt-to-re, Unnumbered Donor interface: lo0.0 (Index 321) Input Filters: test_new-xe-2/0/0.1073853620-in Addresses, Flags: Is-Default Is-Preferred Is-Primary Destination: 100.96.0/20, Local: 100.96.0.1, Broadcast: Unspecified, Generation: 472 Protocol multiservice, MTU: Unlimited, Generation: 223362, Route table: 0 Policer: Input: __default_arp_policer__ ats@junmx104core> show system license License usage: Licenses Licenses Licenses Expiry Feature name used installed needed scale-subscriber 0 1000 0 permanent scale-l2tp 0 1000 0 permanent scale-mobile-ip 0 1000 0 permanent MX104-2x10Gig-port-0-1 0 1 0 permanent MX104-2x10Gig-port-2-3 0 1 0 permanent Licenses installed: License identifier: E008040024 License version: 2 Features: MX104-2x10Gig-port-0-1 - MX104 2X10Gig Builtin Port(xe-2/0/0 & xe-2/0/1) upgrade permanent MX104-2x10Gig-port-2-3 - MX104 2X10Gig Builtin Port(xe-2/0/2 & xe-2/0/3) upgrade permanent Доступ в интернет клиент имеет. Лицензии не расходуются. Кстати о лицензиях. Не нашел описания таковых, что дает та или иная лицензия. Странно что в магазине нет характеристик...

Да все верно, радиус не используется, просто создаются интерфейсы согласно трафика содержащего Svlan указанного диапазона. С VRF попробую. Однако не думаю что изолированная таблица маршрутизации что то решит...   Спасибо, попробую.

Как есть, не расходуются лицензии ни в 13.3 на MX-104 ни в 18.2 в MX-204. Вопрос в том куда навешивать фильтр в dynamic-profile ? Наткнулся на просторах инета на токое обсуждение https://networkengineering.stackexchange.com/questions/40217/juniper-dynamic-subscriber-management-traffic-policing/40816#40816 Тоже не понятно куда подвешивать второй profile

Настроил вот так: subscriber-management { traceoptions { file autoconfig_1 size 2m files 10 world-readable; flag all; } } } Версия ПО 13.3 В логе особо ничего нет

Аналог debug cisco ? Посмотрю как запустить.. спасибо

Да, конечно 13.3 ошибся. Для 18.2 service-subscriber-managment и configuration-database max-db-size настроено. А вот касаемо лицензий вопрос.. ats@junmx104core> show interfaces xe-2/0/0.1073853613 Logical interface xe-2/0/0.1073853613 (Index 330) (SNMP ifIndex 93959) Flags: Up SNMP-Traps 0x0 VLAN-Tag [ 0x8100.179 0x8100.100 ] Encapsulation: ENET2 Input packets : 130 Output packets: 71 Protocol inet, MTU: 8978 Flags: Sendbcast-pkt-to-re, Unnumbered Donor interface: lo0.0 (Index 321) Addresses, Flags: Is-Default Is-Preferred Is-Primary Destination: 100.96.0/20, Local: 100.96.0.1 Protocol multiservice, MTU: Unlimited License usage: Licenses Licenses Licenses Expiry Feature name used installed needed scale-subscriber 0 1000 0 permanent scale-l2tp 0 1000 0 permanent scale-mobile-ip 0 1000 0 permanent MX104-2x10Gig-port-0-1 0 1 0 permanent MX104-2x10Gig-port-2-3 0 1 0 permanent Licenses installed: License identifier: E008040024 License version: 2 Features: MX104-2x10Gig-port-0-1 - MX104 2X10Gig Builtin Port(xe-2/0/0 & xe-2/0/1) upgrade permanent MX104-2x10Gig-port-2-3 - MX104 2X10Gig Builtin Port(xe-2/0/2 & xe-2/0/3) upgrade permanent Как видно интерфейс создан, лицензии не задействованы. Как я понимаю сами динамические профили вполне работают без лицензий. На MX-204 та же картина по лицензиям.

Доброго времени форумчане. Не буду описывать всю предысторию, она долгая. Понадобилось сегментировать большие абонентские vlan. Технология IPoE. В качестве роутера планируется использовать Juniper MX 204. Единственное ограничение нет лицензий браса вообще. После долгих дум был выработан концепт подсесть /20 на кластер, vlan на коммутатор. В кластере от 500 до 2000 абонентов. Ввиду кольцевой топологии сети: два S-vlan на кластер, и по C-vlan на коммутатор. Далее это все разбирается и терминируется на MX-204. Тесты прошли замечательно. Ввиду большого количества коммутаторов на роутере должно быть создано более 3К интерфейсов. Заводить в ручную или скриптами не вариант. Конфиг не читаемый, да и после рестарта железки загружаться будет минут 30. Покурив интернеты решили использовать динамическое создание интерфейсов по документации https://www.juniper.net/documentation/en_US/junos/topics/task/configuration/subscriber-management-stacked-vlan.html. Столкнулся со следующими ньюансами: при такой конфигурации( Привожу в сокращенном виде): dynamic-profiles { QinQ { interfaces { "$junos-interface-ifd-name" { unit "$junos-interface-unit" { description QinQ-profile; vlan-tags outer "$junos-stacked-vlan-id" inner "$junos-vlan-id"; family inet { unnumbered-address lo0.0 } } } } } chassis { network-services enhanced-ip; } interfaces { xe-2/0/0 { flexible-vlan-tagging; auto-configure { stacked-vlan-ranges { dynamic-profile QinQ { accept inet; ranges { 101-180,any; } } } } lo0 { unit 0 { family inet { address 100.96.0.1/20; } } } динамический интерфейс интерфейс замечательно создается, есть arp запись клиента: Логический интерфейс: Logical interface xe-2/0/0.1073787610 (Index 330) (SNMP ifIndex 38619) Flags: Up SNMP-Traps 0x0 VLAN-Tag [ 0x8100.179 0x8100.100 ] Encapsulation: ENET2 Input packets : 359 Output packets: 267 Protocol inet, MTU: 8978 Flags: Sendbcast-pkt-to-re, Unnumbered Donor interface: lo0.0 (Index 321) Addresses, Flags: Is-Default Is-Preferred Is-Primary Destination: 100.96.0/20, Local: 100.96.0.1 Protocol multiservice, MTU: Unlimited arp запись: 70:5a:0f:22:2c:e8 100.96.0.3 100.96.0.3 xe-2/0/0.1073787610 none Но при попытке повесить в dynamic-profile фильтр для выпуска в интернет клиета интерфейс перестает созаваться. irewall { family inet { filter QinQ_230 { term QinQ_local_traff { from { source-address { 100.96.0.0/20; } destination-address { 100.96.0.0/20; } } then { count local_traf_100.96; accept; } } term QinQ_local_inet { from { source-address { 100.96.0.0/20; } } then { count inet_100.96.0.0; next-interface { xe-2/0/3.0; } } } } Все вышеперечисленное собиралось на MX-104 c версией ПО 13.9 Дальше интереснее. при попытке переноса конфигурации на MX-204 При создании динамического интерфейса, так же без фильтра в dynamic-profile не появляется arp запись клиента. DHCP к джуниперу отношения не имеет, настроен relay на коммутаторах access. Видимо схема не совсем типовая, помогите пожалуйста разобраться.

Железо стоит в серверной, температура стабильна. Кондеры могут подсохнуть наверно, не смотрел что там стоит внутри. БП маловероятно наверно.. их по два в каждой... С учетом горячего переключения. "Запиратся" по отраженке не ясно откуда она должна вдруг появится, и потом так же исчезнуть... Просто при таком уровне отраженки сигнал был бы кривой на мой взгляд..

Это понятно и так, суть вопроса что вызывает такую проблему, с учетом того, что проблема на определенных железках купленных в одну единицу времени, аппаратный баг конкретной платы?

Провал именно у железа, пропадает сигнал на телевизорах.

Доброго времени суток! Есть две железки, edfa 24 db бренда vermax компании НАГ. периодически на обоих на короткое время, порядка 10-20 секунд пропадает выходной сигнал, вход стоит на месте. На мониторинге посредством заббикс есть провал. Железки стоят в серверной. На сети есть еще усилители этого бренда. Однако проблема только с двумя, стоящими в серверной. Электропитание от ИБП APC 6000 , онлайн. Проблем по питанию в мониторинге не видно.. Температура в норме. Проблемы может не быть полгода, а может пару тройку раз по разу в день и затихнуть. Кто нибудь сталкивался с подобным?

В этом и вопрос, хочется пообщатся с тем кто это реализовывал, с теорией то более менее ясно. Да полноценная ОС, только вот процессор обыкновенный, с обыкновенными инструкциями, не уверен что в cisco & juniper эти же хадачи решаются таким же железом. По сути нужно только BGP но хорошо и быстро, аппаратных альтернатив в похожие суммы нет.

Дело не только в дороговизне,вопрос в зип'е в масштабируемости решения, cisco juniper и подобное комплексные решения, а нужен только бордер, переплачивать за полноценный сервис-центр не хочется, а у железок попроще не хватает производительности для количества трафика... Вот и рассматриваются софт решения.