On 6/26/17 1:45 PM, Vladimir Sharun wrote:

> Если ты вливаешь в коммутатор 20000 префиксов и у него переполняется TCAM, то это не коммутатора проблема

Это многогранная ситуация, сужать ее лишь до проблемы выбора свича и планнинга - лукавство. Никогда не знаешь, что ждет завтра. Реакция разных коммутаторов на одно и то же - есть разница. В случае с Cisco всё встало колом. В случае с Juniper - всё продолжает работать - свитч выкинул непоместившиеся маршруты и насрал в логи. Ну пошло что-то через дефолт, ну и хрен с ним.
Это не лукавство. Вендор разрабатывает своё оборудование под определенные задачи, ставит туда определенные ASIC'и, тестирует определенные сценарии и несёт ответственность (саппортом, заменой, багфиксами) в рамках только этих задач. Рассчитывать, что устройство в неподдерживаемом сценарии поведет себя так, как представляется тебе - это, как минимум, наивность. Я ни секунды не сомневаюсь, что у Джуна есть свои ограничения, на которые ты просто не наступил. А я вот общался с людьми, которые страшно плевались на коммутаторы Juniper, потому что наступили на какие-то феерические, с их точки зрения, грабли.

Лукавство - это купить Шкоду и думать, что оказался умнее владельцев Ауди и Фольксвагена :)

> Равно как строить GRE для чего-либо кроме management задач.

у GRE гораздо больше применений, чем только менеджмент

Безусловно. Но почему ты считаешь, что коммутатор (даже L3) - это то самое устройство, которое будет обрабатывать в ASIC'ах L3-инкапсуляции? Это написано в документации и производительность гарантируется вендором? То есть ты обвиняешь вендора в том, что он не соответствует твоим ожиданиям? :)

NB: я не провожу сравнение вендоров. Я указываю на ошибки в путях достижения целей.

-- 
Volodymyr Litovka
  "Vision without Execution is Hallucination." -- Thomas Edison