26 Jun
2017
26 Jun
'17
10:58 a.m.
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