/ 12.2.-evpn-multihoming / 0.-example-exercise.md.md
0.-example-exercise.md.md
  1  # Практический пример
  2  
  3  Мы будем рассмотрим вот такую топологию:
  4  
  5  ![](https://habrastorage.org/web/f23/a32/b5d/f23a32b5db884e789ba27c903253d67c.jpg)  
  6  В конфигурации я буду использовать vlan-aware метод, то есть через виртуальный свич, так как данный метод наиболее гибок и интересен, во всяком случае для меня. На каждом PE-маршрутизаторе создано по три EVPN инстанса \(сокращенно EVI — EVPN Instance\), конфигурация которых на всех трех РЕ-ках примерно одинакова — различия лишь в RD, RT и номерах вланов. Два других инстанса добавлены только чтобы продемонстрировать некоторые особенности EVPN Multihoming наглядно.
  7  
  8  Конфигурация EVPN инстансов имеет такой вид:
  9  
 10  ```text
 11  bormoglotx@RZN-PE-1> show configuration routing-instances vSwitch-eVPN-1 
 12  instance-type virtual-switch;
 13  interface ae3.777;
 14  route-distinguisher 62.0.0.1:1;
 15  vrf-target target:42000:1;
 16  protocols {
 17  evpn {
 18  extended-vlan-list 777;
 19  }
 20  }
 21  bridge-domains {
 22  BRIDGE-777 {
 23  vlan-id 777;
 24  }
 25  }
 26  ```
 27  
 28  Ничего сложного: инстанс с типом виртуальный свич, RT, RD и всего лишь один бридж-домен с vlan-id 777. Этот же влан указан в расширенном списке вланов протокола evpn. Для тестирования нам ничего больше и не надо.
 29  
 30  Теперь перейдем к конфигурации интерфейсов. На RZN-PE-3 все просто и банально:
 31  
 32  ```text
 33  bormoglotx@RZN-PE-3> show configuration interfaces ae0 
 34  description "RZN-SW-3 | ae0";
 35  flexible-vlan-tagging;
 36  encapsulation flexible-ethernet-services;
 37  aggregated-ether-options {
 38  lacp {
 39  active;
 40  periodic fast;
 41  }
 42  }
 43  unit 777 {
 44  description eVPN-1;
 45  encapsulation vlan-bridge;
 46  family bridge {
 47  interface-mode trunk;
 48  vlan-id-list 777;
 49  }
 50  }
 51  ```
 52  
 53  Простой агрегат, работающий как транковый интерфейс, в котором разрешен только 777 влан.
 54  
 55  А вот на PE1 и PE2 конфиг несколько отличается от PE3, так как данные PE-ки являются multihomed к RZN-SW-1:
 56  
 57  ```text
 58  bormoglotx@RZN-PE-1> show configuration interfaces ae3 
 59  description "RZN-SW-1 | ge-0/0/0 | ae3<<>>ae0 ";
 60  flexible-vlan-tagging;
 61  mtu 1600;
 62  encapsulation flexible-ethernet-services;
 63  esi {
 64  00:00:00:00:00:00:00:00:00:01;
 65  all-active;
 66  }
 67  aggregated-ether-options {
 68  lacp {
 69  active;
 70  periodic fast;
 71  system-id 02:00:00:00:00:01;
 72  }
 73  }
 74  unit 777 {
 75  description eVPN-1;
 76  encapsulation vlan-bridge;
 77  family bridge {
 78  interface-mode trunk;
 79  vlan-id-list 777;
 80  }
 81  }
 82  ```
 83  
 84  Тут нам интересен появившийся идентификатор ESI. Напомню для тех кто забыл \(или не знал\) — данный идентификатор необходимо назначить вручную \(при использовании MC-LAG может генерироваться автоматически\), причем у всех интерфейсов, подключенных к одному и тому же сегменту этот идентификатор должен быть одинаковым.
 85  
 86  > Примечание: для какой цели тут указан system-id будет описано в конце статьи
 87  
 88  В нашем случае я выбрал простой идентификатор 00:00:00:00:00:00:00:00:00:01, так как его значение не играет для нас большой роли, главное чтобы оно было отлично от зарезервированных значений \(все нули и все единицы\) и не пересекалось со значением уже сконфигурированных значений ESI в других сегментах. То есть грубо говоря ESI должен быть уникален для всей сети, где запускается EVPN. Для non-multihoming сегментов данный идентификатор не играет вообще никакой роли и автоматически выставляется в 0-ль. Естественно, даже для non-multihoming PE-маршрутизаторов можно ручкамии задать ненулевое значение ESI на линках, и это всего навсего повлечет за собой генерацию лишних маршрутов — то есть по сути проблем как таковых и не будет. А вот если это заданное ручками значение ESI совпадает со значением уже сконфигурированного ESI на другом или других стыках то у вас начнутся проблемы.
 89  
 90  В EVPN существует 5 типов маршрутов \(тип 5 я прошлый раз не рассматривал, но я постараюсь затронуть эту тему в статье о EVPN/VxLAN\):
 91  
 92  Тип 2 — это MAC/IP маршрут. Данный маршрут указывает PE-маршрутизатору куда и с какой меткой отправлять юникастовые пакеты на конкретный мак-адрес, указанный в маршруте. По сути аналогичен анонсу vpnv4 префикса в L3VPN. Маршрут может также содержать и ip адрес хоста.
 93  
 94  Тип 3 — это Inclusive Multicast маршрут. Данный маршрут указывает PE-маршрутизатору куда и с какой меткой отправлять BUM трафик.
 95  
 96  Тип 1 и 4 — основные маршруты, предоставляющие нам функционал EVPN Multihoming. Их мы рассмотрим далее.
 97  
 98  Итак, в 0-вой момент времени, как только мы запустили EVPN, маршрутизаторы начинают рассылать друг другу маршруты типа 3, что бы можно было обмениваться BUM трафиком. Это справедливо для сценария без multihoming-га. Так как в нашем сегменте два маршрутизатора смотрят в один и тот же сегмент, то у нас появляются маршруты типа 1 и 4. Зачем нам маршрут типа 3 вы уже должны знать, поэтому далее мы заострим внимание на маршрутах типа 1 и 4.
 99  
100  Как я написал выше — мы только что запустили EVPN и пока что никакого обмена трафиком между хостами не было, о чем говорит нам отсутствие MAC-адресов в таблице форвардинга инстанса vSwitch-eVPN-1:
101  
102  ```text
103  bormoglotx@RZN-PE-1> show evpn instance vSwitch-eVPN-1 brief 
104  Intfs IRB intfs MH MAC addresses
105  Instance Total Up Total Up Nbrs ESIs Local Remote
106  vSwitch-eVPN-1 1 1 0 0 2 1 0 0
107  ```
108  
109  В представленном выводе видно, что у нас есть multihomed сегмент. Чтобы узнать информацию об этом сегменте мы рассмотрим extensive вывод предыдущей команды:
110  
111  ```text
112  bormoglotx@RZN-PE-1> show evpn instance vSwitch-eVPN-1 extensive 
113  Instance: vSwitch-eVPN-1
114  Route Distinguisher: 62.0.0.1:1
115  Per-instance MAC route label: 299792
116  Per-instance multicast route label: 299776
117  MAC database status Local Remote
118  MAC advertisements: 0 0
119  MAC+IP advertisements: 0 0
120  Default gateway MAC advertisements: 0 0
121  Number of local interfaces: 1 (1 up)
122  Interface name ESI Mode Status
123  ae3.777 00:00:00:00:00:00:00:00:00:01 all-active Up 
124  Number of IRB interfaces: 0 (0 up)
125  Number of bridge domains: 1
126  VLAN Domain ID Intfs / up IRB intf Mode MAC sync IM route label
127  777 1 1 Extended Enabled 299776 
128  Number of neighbors: 2
129  62.0.0.2
130  Received routes
131  MAC address advertisement: 0
132  MAC+IP address advertisement: 0
133  Inclusive multicast: 1
134  Ethernet auto-discovery: 2
135  62.0.0.3
136  Received routes
137  MAC address advertisement: 0
138  MAC+IP address advertisement: 0
139  Inclusive multicast: 1
140  Ethernet auto-discovery: 0
141  Number of ethernet segments: 1
142  ESI: 00:00:00:00:00:00:00:00:00:01
143  Status: Resolved by IFL ae3.777
144  Local interface: ae3.777, Status: Up/Forwarding
145  Number of remote PEs connected: 1
146  Remote PE MAC label Aliasing label Mode
147  62.0.0.2 300208 300208 all-active 
148  Designated forwarder: 62.0.0.2
149  Backup forwarder: 62.0.0.1
150  Last designated forwarder update: May 07 06:59:19
151  Advertised MAC label: 300112
152  Advertised aliasing label: 300112
153  Advertised split horizon label: 302752
154  ```
155  
156  Данный вывод дает нам полную информацию по нашему EVPN инстансу. Часть полей вам должна быть уже понятна. Согласно данному выводу у нас есть ESI 00:00:00:00:00:00:00:00:00:01, который работает в режиме Active-Active:
157  
158  ```text
159  Number of local interfaces: 1 (1 up)
160  Interface name ESI Mode Status
161  ae3.777 00:00:00:00:00:00:00:00:00:01 all-active Up
162  ```
163  
164  Далее в выводе представлена информация по каждому PE-маршрутизатору, участвующему в данном EVPN домене:
165  
166  ```text
167  Number of neighbors: 2
168  62.0.0.2
169  Received routes
170  MAC address advertisement: 0
171  MAC+IP address advertisement: 0
172  Inclusive multicast: 1
173  Ethernet auto-discovery: 2
174  ```
175  
176  Судя по информации выше от RZN-PE-2 мы получаем один маршрут типа 3 и два маршрута типа 1.Правда это не совсем так. Помимо этих маршрутов, RZN-PE-2 отдает нам еще один маршрут типа 4, но почему он тут не показан, увидим позже.
177  
178  А вот от RZN-PE-3 на данный момент мы получаем только один маршрут типа 3 и все:
179  
180  ```text
181  62.0.0.3
182  Received routes
183  MAC address advertisement: 0
184  MAC+IP address advertisement: 0
185  Inclusive multicast: 1
186  Ethernet auto-discovery: 0
187  ```
188  
189  Это и логично, так как данный PE-маршрутизатор не является multihomed и пока все что нам от него надо знать — это маршрут типа 3. Дальше по мере изучения маков данный маршрутизатор начнет рассылать анонсы типа 2, но пока что никаких маков он не изучил. Если бы у нас были бы сконфигурены дефолтные шлюзы, то появились бы еще маршруты типа 2 \(в завизимости от количества irb интерфейсов, добавленных в инстанс\).
190  
191  Помимо описанной выше информации по нашему EVI в выводе указано, что для сегмента с ESI 00:00:00:00:00:00:00:00:00:01 выбран Designated forwarder и указана Aliasing label:
192  
193  ```text
194  Number of ethernet segments: 1
195  ESI: 00:00:00:00:00:00:00:00:00:01
196  Status: Resolved by IFL ae3.777
197  Local interface: ae3.777, Status: Up/Forwarding
198  Number of remote PEs connected: 1
199  Remote PE MAC label Aliasing label Mode
200  62.0.0.2 300208 300208 all-active 
201  Designated forwarder: 62.0.0.2
202  Backup forwarder: 62.0.0.1
203  ```
204  
205  В данный момент многое из выводов не понятно. Для понимания принципов работы EVPN Multihoming нам надо разобраться как минимум со следующими вопросам:
206  
207  1. Зачем Multihomed PE-маршрутизатор начинает анонсировать дополнительные маршруты типа 1 и 4, каково их назначение;  
208  2. Что такое DF и как происходят его выборы;  
209  3. Почему маршрутов типа 1 аж два.  
210  4. Что такое Aliasing label в выводе выше.
211  
212  Но эти и некоторые другие вопросы я постараюсь ответить дальше.