[semop]

В 05.07.2019 в 12:38, erka сказал:

Я каких то клиентов хочу засовывать в один аплинк, других в другой, не зависимо от дестенейшена

А клиенты как то отличаются между собой?

Именно препендами и локалпреф все рассовывается на аплинки в зависимости от веса, если это анонсирование сеток.

Этот туда, этот сюда.

Хотя это "разломать" смогут вышестоящие, которые так же могут разгрузиться где нибудь, а ваши длинные препенды станут короткими)

Для жесткости первое что бы мне пришло в голову это PBR+SLA, как выше писали.

ВРФ это имхо лишнее облако, тем более если его надо будет перемешивать с global таблицей. PBR вроде попроще для процессора, чем 10 врфов качать, тем более если выхлоп получится одинаковый.

[erka]

On 7/5/2019 at 8:32 PM, GrandPr1de said:

https://www.juniper.net/documentation/en_US/junos/topics/concept/routing-protocol-static-security-route-preference-and-qualified-next-hop-understanding.html

Не понял как связан qualified next hop и source routing, если первое позволяет просто использовать несколько некст хопов, а второе роутинг на основе сорс адреса. 

On 7/7/2019 at 11:11 AM, vurd said:

Нет. Неправильно.

У него транзитная АС, клиенты по БГП. Штуки 3-4 наверное, судя по хотелкам, ибо нормальный оператор такой херней страдать не будет.

Почему не будет? Пример был абстрактный, который первый в голову пришел. Бывают разные причины, по которым клиентам не нужен доступ в одного из возможных аплинков. Вот другой пример, когда не во всех аплинках есть фильтрация трафика РКН и не все клиенты имеют собственную. Ряд клиентов нужно пускать в аплинков у которых есть фильтрация, а клиентов со своей фильтрацией можно пускать куда угодно. Либо другой пример, что ряд клиентов хочет в первую очередь попадать в Ростелек, но пускать туда всех не хочется, т.к. линк забит и расширить нет возможности. 

Возможно я плохо описал задачу. 

9 hours ago, semop said:

А клиенты как то отличаются между собой?

Именно препендами и локалпреф все рассовывается на аплинки в зависимости от веса, если это анонсирование сеток.

Этот туда, этот сюда.

Хотя это "разломать" смогут вышестоящие, которые так же могут разгрузиться где нибудь, а ваши длинные препенды станут короткими)

Для жесткости первое что бы мне пришло в голову это PBR+SLA, как выше писали.

ВРФ это имхо лишнее облако, тем более если его надо будет перемешивать с global таблицей. PBR вроде попроще для процессора, чем 10 врфов качать, тем более если выхлоп получится одинаковый.

Клиенты отличаются асками. Окей препендами я указал как получать входящий(помним что это кстати не идеальный способ), локалпреф это атрибут маршрута, я им могу сказать куда лить траф в зависимости от дестенейшена, он никак не влияет на того кому туда лить можно. Но что если я НЕ хочу чтобы клиент из AS12345 лил свой траф в одного из ISPов?

PBR+SLA я как раз озвучивал как один из вариантов, но мне не понравились костыли в виде SLA и к сожалению я не знаю как PBR будет сказывать на загрузке. Вы уверены что пбр меньше ресурсов сожрет чем врф? Есть конкретный опыт?)

 

Всем спасибо. 

Изменено 8 июля, 2019 пользователем erka

[semop]

11 часов назад, erka сказал:

Есть конкретный опыт?)

Ну можно сказать да.

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

Именно PBR+SLA. 

Но это так клиент пожелал. Конфига пара строчек и особой мороки нет. Может поэтому.

У нас тоже эта штука скоро будет с этим клиентом. И тоже PBR+SLA. Правда SLA на свои удаленные IP у них.

Гугл - не эталон ;) Даже целую холивар-тему можно поднять с этими восьмерками. Но не надо.

 

Ну и да, эта схема вроде не балансируется. Только ручками в зависимости от загрузки каналов.

[semop]

12 часов назад, erka сказал:

Вы уверены что пбр меньше ресурсов сожрет чем врф?

в зависимости от размера таблиц маршрутизации.

У нас 2 fullview и 1 partialview. 

Плюс свое.

Если все это по врфам раскидать, то я даже не знаю сколько это памяти надо будет дать. Вы вроде свой врф на таблицу хотели.

 

Вот просто читая про утечки памяти на джуниперах я б сразу отказался от такого исполнения. Ну или не на джунипере это делать.

PBR это по идее просто рутинг "по скрипту". Тут даже бгп и АСок не надо) микротик справится. Я думаю PBR легче чем VRF'ы с global таблицами внутри для железки.

Работать будет и то и то, просто внатяг то зачем. Ну это мое мнение.

Инженер - творец. Как сделаете, так и будет)

[GrandPr1de]

4 часа назад, semop сказал:

в зависимости от размера таблиц маршрутизации.

У нас 2 fullview и 1 partialview. 

Плюс свое.

Если все это по врфам раскидать, то я даже не знаю сколько это памяти надо будет дать. Вы вроде свой врф на таблицу хотели.

 

Вот просто читая про утечки памяти на джуниперах я б сразу отказался от такого исполнения. Ну или не на джунипере это делать.

PBR это по идее просто рутинг "по скрипту". Тут даже бгп и АСок не надо) микротик справится. Я думаю PBR легче чем VRF'ы с global таблицами внутри для железки.

Работать будет и то и то, просто внатяг то зачем. Ну это мое мнение.

Инженер - творец. Как сделаете, так и будет)

какое-то bullshit bingo

"джунипер не видел но микротики буду советовать под магистраль с FV" ™

 

16 часов назад, erka сказал:

Не понял как связан qualified next hop и source routing

пбр без некстхопа как делать собираешься?

а qualified дает хоть тупые проверки живности некстхопа

[semop]

Там про микротик сарказм был если что ;)

[vvertexx]

@GrandPr1de @semop 

Вы PBR на джуне настраивали?

PS: и qualified next hop...

[semop]

@vvertexx я нет. HWI/cisco - да.

А почему на ju для этого надо vrf? Это особенность такая у него?

[GrandPr1de]

9 часов назад, vvertexx сказал:

@GrandPr1de @semop 

Вы PBR на джуне настраивали?

PS: и qualified next hop...

да, настраивал

[vvertexx]

@semop 

У джуна нет понятия PBR. Оно есть как частный случай vrf (routing instance), называется FBF (Filter-based forwarding). Поэтому все эти рассуждения бессмысленны.

PS: qualified next hop - настраивается для статических маршрутов, для динамики достаточно манипулировать значением preference (Administrative Distance в терминах cisco)

[pingz]

@semop https://habr.com/ru/post/275119/ 

 

Для общего развития прочитайте. 

[semop]

@pingz так то прикольно. Согласен.

Хотя я не особо вник зачем столько всего, если то же самое можно сделать 2мя инструментами.

VRF и BGP. Всё вроде. А дальше хоть чего. Это умеют все маршрутизаторы.

 

Ну вот например Forwarding там так же работает как и PBR.

Но пишут

Цитата

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

 

То есть 2 клиента. Надо обоим свои правила и политики маршрутизации на основе Forwarding, но с работой по глобальной таблице.

Надо создать по две таблички на каждого? Это тот же самый VRF и получается.

Этому таблица, этому таблица.

 

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

Ну может я неправ. И это на самом деле благо...

[pingz]

@semop я не силен в джуне, и с циской не работал. 

 

Каждого вида VRF есть свои ограничения плюсы и минусы. 

 

По поводу памяти на сколько мне известно два фулвью влазит в MX80(за другие железки не знаю) т.к. у него один RE  если при этом разнести все в разные VRF и сливать все в inet(общая таблица) то получается количество маршрутов будет уже две таблицы bgp + rib . 

 

set routing-instances nat1 instance-type forwarding
set routing-instances nat1 routing-options static route 0.0.0.0/0 next-hop 172.16.255.2

set routing-options interface-routes rib-group inet nat
set routing-options rib-groups nat import-rib inet.0
set routing-options rib-groups nat import-rib nat1.inet.0

 

Получается что из таблицы inet.0 перетирают маршруты в nat1.inet.0 и на оборот. 

 

Так же нужно понимать, что все это обрабатывает PFE, оперативка нужна для самого процесса BGP.  

 

show pfe route ip

Slot 0


IPv4 Route Table 0, default.0, 0x80000:
Destination                       NH IP Addr      Type     NH ID Interface
--------------------------------- --------------- -------- ----- ---------
default                           x.x.x.x  Unicast   657 RT-ifl 0 xe-0/0/0.xxx ifl 336
0.0.0.0                                            Discard    34 RT-ifl 0
10.10.1/24                                         Resolve   622 RT-ifl 337 xe-0/0/0.999 ifl 337
10.10.1.0                         10.10.1.0           Recv   620 RT-ifl 337 xe-0/0/0.999 ifl 337
10.10.1.1                         10.10.1.1        Unicast   720 RT-ifl 337 xe-0/0/0.999 ifl 337




show route

inet.0: 3604 destinations, 3604 routes (3604 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

0.0.0.0/0          *[Static/5] 9w4d 20:26:12
                    > to x.x.x.x via xe-0/0/0.xxx
10.10.1.0/24       *[Direct/0] 65w1d 17:08:57
                    > via xe-0/0/0.999

 

[semop]

 

47 минут назад, pingz сказал:

Каждого вида VRF есть свои ограничения плюсы и минусы. 

6 видов джуниперских VRF'ов - можно сделать одним способом на Cisco/huawei/.., я вот это имел ввиду.

Может это удобно конечно, и я ошибаюсь.

Но смысл и выхлоп то один и тот же получится все равно)

 

Мы ни к чему не придем. Просто на джуниперах так можно. В качестве вариантов. Ничего плохого в этом нет, я считаю.

 

ПС: есть один очень популярный вендор роутеров, которые тоже умеют много чего, а на них поднимают пппое дома и локальную сеть офиса 192.168.0.0

Целый раздел форума создан для них.

Вот тоже само же ;)

[jffulcrum]

7 часов назад, semop сказал:

локальную сеть офиса 192.168.88.0

Исправил :)

[GrandPr1de]

В 11.07.2019 в 13:28, semop сказал:

6 видов джуниперских VRF'ов

нет, это куча видов routing-instance один из которых это VRF.

[semop]

В 11.07.2019 в 20:44, jffulcrum сказал:

Исправил :)

да. Простите)

[Andrei]

В 09.07.2019 в 18:31, semop сказал:

я нет. HWI/cisco - да.

А как на циске сделать "частичный роутинг мимо pbr"?

Поясню на реальном примере.

 

Стыковой интерфейс со вторым магистралом (есть и еще один магистрал, туда pbr настроен аналогично):

interface GigabitEthernet0/3.502
 encapsulation dot1Q 502
 ip address 62.141.xxx.xxx 255.255.255.252
 ip nat outside
 no cdp enable
 

НАТ:

access-list 100 permit ip 172.21.40.0 0.0.0.255 any
access-list 100 permit ip 172.21.41.0 0.0.0.255 any

ip nat inside source list 100 interface GigabitEthernet0/3.502 overload
 

Cобственно pbr:

route-map nat_to_sovintel permit 10
 match ip address 100
 set ip next-hop 62.141.xxx.xxx
 

Темплейт для pppoe/pptp:

interface Virtual-Template1
 ip unnumbered Loopback0

 ip nat inside
 ...

 ip policy route-map nat_to_sovintel
 

И есть своя сетка 188.130.ххх.ххх, хочется ходить на нее не по правилам pbr, а через directly connected interface.

 

 

[vurd]

Дени напишите на нее в акцес листе 100 первой строкой. всё

P.s. а второй строчкой можно агрегат двух подсетей по /23 написать (хз зачем)

[Andrei]

Типа такого:
access-list 100 deny ip any 188.130.xxx.xxx 0.0.0.255 

?

[vurd]

Да