[dmvy]

все зависит от оборудования апстримов. еще зависит от роутмапов с различными условиями по коммьюнити

[alks]

Спасибо за ответ

попутно возник еще один вопрос по mtu

 

http://www.juniper.net/techpubs/en_US/junos12.2/topics/usage-guidelines/interfaces-configuring-the-media-mtu.html

 

Note: The actual frames transmitted also contain cyclic redundancy check (CRC) bits, which are not part of the media MTU. For example, the media MTU for a Gigabit Ethernet Version 2 interface is specified as 1514 bytes, but the largest possible frame size is actually 1518 bytes; you need to consider the extra bits in calculations of MTUs for interoperability.

The physical MTU for Ethernet interfaces does not include the 4-byte frame check sequence (FCS) field of the Ethernet frame.

 

т.е. mtu 1514 для 802.1q это 1500 полезной нагрузки + l2 заголовки - 4байта FCS

и если стыкуем циску-джун ставим cisco(1500)-jun(1514)

 

а как быть в случае если стыкуем скажем сервер(10GE)-джун, на сервере eth0 mtu 1500, сабинтерфейс vlan10 mtu 1500

какой mtu ставить на xe-0/0/0 и на его юните xe-0/0/0.10

если я верно понял то на юните мы указываем mtu 1500 а на самом порту 1514 так?

Edited September 28, 2012 by alks

[nnm]

т.е. mtu 1514 для 802.1q это 1500 полезной нагрузки + l2 заголовки - 4байта FCS

1514 это физический MTU по умолчанию для Ethernet-интерфейса БЕЗ 802.1q тэга. Тэг добавляет 4 байта. Но в большинстве случаев об этом думать не нужно, при включении тэгирования JUNOS сам корректирует MTU.

и если стыкуем циску-джун ставим cisco(1500)-jun(1514)

Да, и это настройки по умолчанию. Можно ничего и не конфигурировать.

а как быть в случае если стыкуем скажем сервер(10GE)-джун, на сервере eth0 mtu 1500, сабинтерфейс vlan10 mtu 1500

какой mtu ставить на xe-0/0/0 и на его юните xe-0/0/0.10

После того, как на физическом интерфейсе напишете flexible-vlan-tagging, Juniper сам увеличит физический MTU на 8 байт до 1522 (чтобы можно было добавить два тэга). Протокольный IP MTU на юнитах при этом останется равным 1500. Это справедливо и для native-vlan-tagged юнитов. Т.е. опять-таки ничего конфигурировать не нужно. :)

[alks]

to nnm - спасибо

[dazgluk]

Коллеги, прошу проконсультировать.

 

Являюсь обладателем коробки MX480 вот с таким набором:

FPC 0            DPCE-R-20GE-2XGE
FPC 1            DPCE-R-20GE-2XGE
FPC 2            MS-DPC
FPC 3            MS-DPC

Предполагается делать на ней NAT+Netflow, c НАТом пока не разбирался. На счет Netflow затык.

Семплирование средствами RouteEngine оотпадает сразу, остается inline-jflow либо семплирование средствами MS-DPC.

Поддерживают ли эта конфигурация inline-jflow, если да, то ткните пальцем в документацию или какой configuration-guide?

Мне так же не удалось найти нормальный Datasheet на MS-DPC по части трафика. Однако есть подозрение что умеет она всего 2x4Gb/s

У меня трафа 14G идет с 2х десяток и в две десятки же и уходит, соответственно я не совсем понимаю как настроить sampling-instance (и надо ли), чтобы раскидать семлирование по разным service-pic ам MS-DPC.

 

Вопросы:

Оно вообще взлетит на такой конфигурации? (14Gb/s NAT+Netflow)

Какой throutput у MS-DPC?

Как идеологически все это чудо настраивать? (что на какие карты раскидывать)

 

Спасибо.

[uxcr]

 

Поддерживают ли эта конфигурация inline-jflow

 

 

С вашим типом платы дела не имел, но перед заказом mx240 в своё время документацию читал,и там говорится - inline-jlow поддерживают trio-чипсеты.

https://kb.juniper.net/InfoCenter/index?page=content&id=KB25385&cat=T_SERIES&actp=LIST

Видимо, не поддерживает.

 

На джуниперовском форуме про загрузку обещают "MSDPC supports 4Gbps per PIC, 8Gbps per MSDPC" и "Flows and NAT translations are _not_ automatically shared between NPUs, you have to direct flows into different NPUs explicitly in the config (based on source IP ranges or IP header fields hash) to share the load."

[dazgluk]

 

Поддерживают ли эта конфигурация inline-jflow

 

 

С вашим типом платы дела не имел, но перед заказом mx240 в своё время документацию читал,и там говорится - inline-jlow поддерживают trio-чипсеты.

https://kb.juniper.net/InfoCenter/index?page=content&id=KB25385&cat=T_SERIES&actp=LIST

Видимо, не поддерживает.

 

На джуниперовском форуме про загрузку обещают "MSDPC supports 4Gbps per PIC, 8Gbps per MSDPC" и "Flows and NAT translations are _not_ automatically shared between NPUs, you have to direct flows into different NPUs explicitly in the config (based on source IP ranges or IP header fields hash) to share the load."

Спасибо, по поводу inline-jflow так и подозревал.

Форум джуниперский читал, спасибо. Думал просто что кто-то Datasheet видел.

Соответственно остается последний вопрос, правильно ли я подозреваю, что джуниперская идеология netflow это

1. Создать sampling instance

2. Создать sampling output внутри интсанса и прилепить туда NPU

3. Прилепить sampling instance к PFC плате.

Учитывая, что я говорил что у меня две десятки, в двух платах, получается не взлетит?

[nnm]

Форум джуниперский читал, спасибо. Думал просто что кто-то Datasheet видел.

На MS-DPC стоит какой-то жутко многоядерный проц общего назначения. Скорее всего поэтому они и производительность не пишут. Трудно ее одной полосой пропускания охарактеризовать. И она кстати от версии софта зависит (индусы код оптимизируют :) ). Для 11.2 делалась оптимизация кода NAT и для него заявляется ~19Gbit/s на MS-DPC SIMPLEX. Рискну предположить, что производительность для flows должна быть того-же порядка (алгоритм по идее проще). Если это так, то можно попробовать слить трафик с каждой десятки на 'свой' комплекс и есть шанс, что оно полетить.

 

Соответственно остается последний вопрос, правильно ли я подозреваю, что джуниперская идеология netflow это

1. Создать sampling instance

2. Создать sampling output внутри интсанса и прилепить туда NPU

3. Прилепить sampling instance к PFC плате.

4. Не забыть сказать sampling на интерфейсе или в firewall-filter, приаттаченном к этому интерфейсу.

Учитывая, что я говорил что у меня две десятки, в двух платах, получается не взлетит?

Если нужно собирать flows только в одну сторону (только для входящего) и можно разнести uplink-и по разным DPC, то можно раскидать траф на два NPU и если оно действительно может 19Gbit/s на MS-DPC, то шансы есть.

Если будете пробовать, расскажите пожалуйста о результатах :)

[survivor]

Как хорошо что у меня циско, а не джун :)

у меня море документации, океан форумов, где сидят добрые отзывчивые адекватные люди, готовые к острым вопросам и бурному мозговому штурму.

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

Извините за сильнейший оффтоп - не удержался. Но эта идея с закрытым форумом бред и противоречит свободе общения в интернете.

[alks]

да, кстати, идея c закрытым форумом не совсем понятна, а так по сути, к примеру MX80 я брал потому что он дешевле аналогичного cisco ASR

да и младшие модели SRX дешевле цисковской ASA

[h1vs2]

Подскажите, пожалуйста, а на mx80 virtual chassis появилось уже?

 

И будет ли аналог initiator unclassified ip-address в ISG ?

[Tima]

Подскажите, пожалуйста, а на mx80 virtual chassis появилось уже?

 

Нет

[h1vs2]

Подскажите, пожалуйста, а на mx80 virtual chassis появилось уже?

 

Нет

 

Дополнительный вопрос : а появится? Если да - когда обещают?

[dazgluk]

Отпишусь о тестировании Netflow на MS-DPC.

 

19Gb/s похоже на правду, только half-duplex и на оба сервис пика. Тоеть получается 4.75 гигабита full-duplex на один сервис пик, у нас к сожалению уже больше.

Косвенно это подтверждается тестами:

 

user@mx480_re1> show services accounting errors

Service Accounting interface: sp-3/0/0, Local interface index: 303

Service name: (default sampling)

Interface state: Accounting

Error information

Packets dropped (no memory): 52132351408, Packets dropped (not IP): 0

Packets dropped (not IPv4): 0, Packets dropped (header too small): 0

Memory allocation failures: 0, Memory free failures: 0

Memory free list failures: 386113

Memory warning: No, Memory overload: No, PPS overload: No, BPS overload: Yes

 

Так что от этой идеи пришлось отказаться, а из MX-480 наверное придется делать L3-BRAS раз уж платы есть, а NAT+Netflow не взлетит

Edited November 1, 2012 by dazgluk

[FtoR1]

Коллеги, день добрый, можно поинтересоваться статусом заявки на доступ в форум? show chassis hardware отправил с кластера EX4200 еще до праздников. Могу еще прислать, оборудования в бою достаточно. Отправил ответ повторно - нет никакой реакции. Списывался с Дмитрием С. Есть какой-нибудь фидбек у кого-нибудь?

[kha0s]

Нету никакой реакции на заявки. Видимо это была шутка.

[dazgluk]

Так же оставил заявку на доступ, а есть ли этот форум вообще?)

Edited November 9, 2012 by dazgluk

[z.a.v.]

Мне тоже не ответили.

[SNR]

Нету никакой реакции на заявки. Видимо это была шутка.

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

 

Добрый день.

Сообщите название вашей компании и логин с форума. Покажите sh ver.

 

кому:	 Victor <kha0s@ukr.net>
копия:	 juniper@nag.ru
дата:	 18 июля 2012 г., 14:10
тема:	 Re: запрос на доступ
отправлено через:	 nag.ru

 

Так же оставил заявку на доступ, а есть ли этот форум вообще?)

Вам ответили.

Всем остальным: на заявки отвечаем достаточно оперативно, доступ предоставляется без проблем. Исключения составляют компании-интеграторы. Вам то зачем сюда?

[FtoR1]

Т.е. Мне не ответили, ибо посчастливилось указать имя компании и работать в системное интеграторе? Можно понять логику? Наоборот, есть возможность делиться на русском языке друг с другом проблемами с оборудованием того же операторского класса. Можно получить комментарии?

[Bachaa]

Насколько хороши эти железки не знаю, но уж очень они тяжелые!

[akocherov]

а мне видимо "повезло" ответ приходит быстро.

 

>Delivery to the following recipient failed permanently:

>

> juniper@nag.ru

>

>Technical details of permanent failure:

>Message rejected by Google Groups. Please visit http://mail.google.com/support/bin/answer.py?hl=en&answer=188131 to review our Bulk Email Senders Guidelines.

[Wingman]

А у меня зачем-то доступ отобрали вчера, можно вернуть? Джуник у вас же и покупали

[SNR]

А у меня зачем-то доступ отобрали вчера, можно вернуть? Джуник у вас же и покупали

там начали добавлять в группы по обсуждению firewall и случайно сняли принадлежность к группе juniper. fixed.

а мне видимо "повезло" ответ приходит быстро.

напишите с другого емейла

[z.a.v.]

Когда доступ то дадут, и почему сообщение удалили.