Hello! Bonjour! Hola! Nǐ hǎo! Здравствуйте!

Сегодня поговорим о наболевшем – совместимости западного сетевого оборудования с отечественным. У нас уже есть опыт построения фабрики ЦОДов на российских коммутаторах Eltex. И мы даже проверили ее работоспособность под нагрузкой. Вывод – работает.  Бери и делай – построить фабрику с нуля на едином вендоре проблем не составляет. 

Но что, если нам нужно расширить существующую фабрику ЦОДов или заменить только один, вышедший из строя, коммутатор?

Можем ли мы использовать оборудование Eltex в комбинации с другими вендорами? Давайте проверим. А проверять мы будем на всем привычном оборудовании Cisco (Hello!) и Huawei (Nǐ hǎo!).

Топология

Конечно, правильным подходом было бы собрать фабрики на Cisco и Huawei, и плавно менять/добавлять оборудование Eltex, но мы пойдем другим путем. Ведь у нас уже есть фабрика Eltex, к которой мы привыкли, и можно добавлять/менять оборудование в ней (помните правило из школы: от перестановки мест слагаемых сумма не меняется).

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

Нам не сильно сейчас важно, что у нас 2 площадки, поэтому сократим схему, заменим часть коммутаторов и будем тестировать такую топологию:

Коммутаторы Spine нам тоже не принципиально тестировать, так как они, по большому счету, просто BGP Route Reflector.

Чтобы всё было честно и прозрачно, вот какое оборудование мы будем проверять на совместимость:

L3-схему дополним коммутаторами Huawei, а Cisco должна взять на себя роль коммутатора Leaf1-1:

Теперь у нас соседство LLDP на коммутаторах Spine:

eSpine1-1#sh lldp neighbors

System capability legend:

B - Bridge; R - Router; W - Wlan Access Point; T - telephone;

D - DOCSIS Cable Device; H - Host; r - Repeater;

TP - Two Ports MAC Relay; S - S-VLAN; C - C-VLAN; O - Other

   Port        Device ID          Port ID               System Name           Capabilities  TTL

---------- ----------------- ----------------- ------------------------------ ------------ -----

hu1/0/1    a0:23:9f:3b:35:76   Ethernet1/49               cLeaf1-1                B, R      94

hu1/0/2    90:54:b7:59:ff:80      hu1/0/5                 eLeaf1-2                B, R      96

hu1/0/3    28:53:4e:83:26:51    100GE1/0/7                hLeaf1-3                B, R      104

eSpine1-2#sh lldp neighbors

System capability legend:

B - Bridge; R - Router; W - Wlan Access Point; T - telephone;

D - DOCSIS Cable Device; H - Host; r - Repeater;

TP - Two Ports MAC Relay; S - S-VLAN; C - C-VLAN; O - Other

   Port        Device ID          Port ID               System Name           Capabilities  TTL

---------- ----------------- ----------------- ------------------------------ ------------ -----

hu1/0/1    a0:23:9f:3b:35:7a   Ethernet1/50               cLeaf1-1                B, R      105

hu1/0/2    90:54:b7:59:ff:80      hu1/0/6                 eLeaf1-2                B, R      106

hu1/0/3    28:53:4e:83:26:51    100GE1/0/8                hLeaf1-3                B, R      104

Интересно наблюдать за тем, как разные вендоры дают имена интерфейсов (несмотря на то, что это всё 100G интерфейсы): Ethernet1/50, hu1/0/6, 100GE1/0/8. А вот службе эксплуатации сетей такое разнообразие уже совсем не нравится.

Поэтому не стоит строить сети по принципу «я его слепила из того, что было». Ведь когда у вас единая линейка используемого оборудования, единая версия ПО на сетевом оборудовании, то и вероятность несовместимости ниже, и количество проблем будет меньше. Кстати, унификация оборудования и версии ПО называется у них там термином baseline. Поэтому вы можете иногда услышать фразу «выровнять baseline» — это будет означать, что, например, не на всем оборудовании стоит одна и та же версия ПО, а значит, вероятность нетипичных ошибок будет выше. А если у вас есть процессы автоматизации настроек или системы управления, то поддерживать все возможные варианты будет крайне трудозатратно.

Что ж, со схемами определились. Давайте настраивать!

Настройка Underlay

Вы ведь уже обратили внимание, что eLeaf1-1 у нас поменялся на cLeaf1-1, а hLeaf1-3 – это новый коммутатор? Это неслучайно. Мы проверим потребность в добавлении настроек в зависимости от вендора.

Настроим cLeaf1-1:

feature ospf

feature bgp

feature interface-vlan

feature vn-segment-vlan-based

feature lldp

feature bfd

interface Ethernet1/49

  description to_spine

  speed 100000

  duplex full

  fec rs-fec

  no negotiate auto

  ip address 10.1.1.2/30

  ip ospf mtu-ignore

  ip router ospf 100 area 0.0.0.0

  no shutdown

interface Ethernet1/50

  description to_spine

  speed 100000

  duplex full

  fec rs-fec

  no negotiate auto

  ip address 10.1.1.10/30

  ip ospf mtu-ignore

  ip router ospf 100 area 0.0.0.0

  no shutdown

interface loopback0

  ip address 10.1.0.13/32

  ip router ospf 100 area 0.0.0.0

router ospf 100

  router-id 10.1.0.13

Настроим hLeaf1-3:

interface 100GE1/0/7

 undo portswitch

 description eSpine1-1

 ip address 10.1.1.18 255.255.255.252

 device transceiver 100GBASE-COPPER

 negotiation disable

 fec mode rs

#

interface 100GE1/0/8

 undo portswitch

 description eSpine1-2

 ip address 10.1.1.22 255.255.255.252

 device transceiver 100GBASE-COPPER

 negotiation disable

 fec mode rs

interface LoopBack0

 ip address 10.1.0.18 255.255.255.255

ospf 100 router-id 10.1.0.18

 area 0.0.0.0

  network 10.1.0.18 0.0.0.0

  network 10.1.1.18 0.0.0.0

  network 10.1.1.22 0.0.0.0

Проверим соседство:

cLeaf1-1# sh ip ospf neighbors

 OSPF Process ID 100 VRF default

 Total number of neighbors: 2

 Neighbor ID     Pri State            Up Time  Address         Interface

 10.1.0.11         1 FULL/BDR         2w0d     10.1.1.1        Eth1/49

 10.1.0.12         1 FULL/BDR         2w0d     10.1.1.9        Eth1/50

[~hLeaf1-3]dis ospf peer brief

(M) Indicates MADJ neighbor

OSPF Process 100 with Router ID 10.1.0.18

                   Peer Statistic Information

Total number of peer(s): 2

 Peer(s) in full state: 2

-----------------------------------------------------------------------------

 Area Id         Interface                  Neighbor id          State

 0.0.0.0         100GE1/0/7                 10.1.0.11            Full

 0.0.0.0         100GE1/0/8                 10.1.0.12            Full

-----------------------------------------------------------------------------

И проверим, что IP-адреса Loopback приходят на коммутаторы Spine:

eSpine1-1#show ip route | include 10.1.0.1[38]

O    10.1.0.13/32 [30/11] via 10.1.1.2, 339:07:07, hu1/0/1

O    10.1.0.18/32 [30/10] via 10.1.1.18, 64:36:07, hu1/0/3

eSpine1-2#show ip route | include 10.1.0.1[38]

O    10.1.0.13/32 [30/11] via 10.1.1.10, 339:06:35, hu1/0/1

O    10.1.0.18/32 [30/10] via 10.1.1.22, 64:35:39, hu1/0/3

Коммутаторы Spine по OSPF видны, Loopback-адреса коммутаторов Leaf анонсируются, можем переходить к настройке BGP.

Заполним таблицу, как и ранее это делали:

Настройки BGP для cLeaf1-1:

router bgp 65001

  router-id 10.1.0.13

  log-neighbor-changes

  address-family l2vpn evpn

  template peer RR

    bfd

    remote-as 65001

    password 3 173f895b54107e20

    update-source loopback0

    address-family ipv4 unicast

      soft-reconfiguration inbound

    address-family l2vpn evpn

      send-community

      send-community extended

  neighbor 10.1.0.11

    inherit peer RR

    remote-as 65001

    no shutdown

  neighbor 10.1.0.12

    inherit peer RR

    remote-as 65001

    no shutdown

Настройки BGP для hLeaf1-3:

bfd

bgp 65001

 router-id 10.1.0.18

 private-4-byte-as enable

 group RR internal

 peer RR connect-interface LoopBack0

 peer RR password simple Eltex

 peer RR bfd enable

 peer 10.1.0.11 as-number 65001

 peer 10.1.0.11 group RR

 peer 10.1.0.12 as-number 65001

 peer 10.1.0.12 group RR

 #

 ipv4-family unicast

  peer RR enable

  peer RR advertise-community

  peer RR advertise-ext-community

  peer 10.1.0.11 enable

  peer 10.1.0.11 group RR

  peer 10.1.0.12 enable

  peer 10.1.0.12 group RR

Не забываем, что hLeaf1-3 – это новое устройство и его надо добавить в конфигурацию коммутаторов eSpine1-1 и eSpine1-2:

router bgp 65001

 neighbor 10.1.0.18

  peer-group RRC

  address-family ipv4 unicast

  exit

  !

  address-family l2vpn evpn

  exit

 exit

Кто повнимательнее – заметил, что у hLeaf1-3 не хватает части настройки (об этом чуть позже).

А пока давайте проверим BGP связность.

cLeaf1-1# sh ip bgp sum

BGP summary information for VRF default, address family IPv4 Unicast

BGP router identifier 10.1.0.13, local AS number 65001

BGP table version is 5, IPv4 Unicast config peers 2, capable peers 2

0 network entries and 0 paths using 0 bytes of memory

BGP attribute entries [0/0], BGP AS path entries [0/0]

BGP community entries [0/0], BGP clusterlist entries [6/40]

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd

10.1.0.11       4 65001  115150   40885        5    0    0 00:11:30 0

10.1.0.12       4 65001  118980   40885        5    0    0 00:11:30 0

[~hLeaf1-3]dis bgp peer

 BGP local router ID        : 10.1.0.18

 Local AS number            : 65001

 Total number of peers      : 2

 Peers in established state : 2

  Peer                             V          AS  MsgRcvd  MsgSent  OutQ  Up/Down       State  PrefRcv

  10.1.0.11                        4       65001      155      173     0 01:14:06 Established        0

  10.1.0.12                        4       65001      152      170     0 01:12:26 Established        0

Обратите внимание, что количество полученных префиксов у нас равно 0.

И так как у нас BGP завязан на BFD, то проверим сразу и его:

cLeaf1-1# sh bfd neighbors

OurAddr         NeighAddr       LD/RD                 RH/RS           Holdown(mult)     State       Int                   Vrf                              Type

10.1.0.13       10.1.0.11       1090519043/2147483655 Up              634(3)            Up          Lo0                   default                          MH

10.1.0.13       10.1.0.12       1090519044/2147483654 Up              695(3)            Up          Lo0                   default                          MH

[~hLeaf1-3]dis bfd session all

S: Static session

D: Dynamic session

IP: IP session

IF: Single-hop session

PEER: Multi-hop session

AUTO: Automatically negotiated session

VXLAN: VXLAN session

(w): State in WTR

(*): State is invalid

Total UP/DOWN Session Number : 2/0

--------------------------------------------------------------------------------

Local      Remote     PeerIpAddr      State     Type        InterfaceName

--------------------------------------------------------------------------------

16386      2147483654 10.1.0.11       Up        D/IP-PEER          -

16388      2147483653 10.1.0.12       Up        D/IP-PEER          -

--------------------------------------------------------------------------------

Так почему же у нас 0 принятых префиксов? Всё просто – мы используем BGP для EVPN-семейства, поэтому нужно проверять именно для него:

cLeaf1-1# sh bgp l2vpn evpn summary

BGP summary information for VRF default, address family L2VPN EVPN

BGP router identifier 10.1.0.13, local AS number 65001

BGP table version is 361362, L2VPN EVPN config peers 2, capable peers 2

46 network entries and 66 paths using 11592 bytes of memory

BGP attribute entries [46/8464], BGP AS path entries [0/0]

BGP community entries [0/0], BGP clusterlist entries [6/40]

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd

10.1.0.11       4 65001  115527   41015   361362    0    0 01:16:11 0

10.1.0.12       4 65001  119376   41015   361362    0    0 01:16:11 0

А почему не вся часть конфигурации BGP на Huawei была прописана? На Huawei тоже есть что-то вроде feature-set («evpn-overlay»), который нужно включать, чтобы появились нужные настройки.

Ведь изначально в секции BGP мы даже не можем настроить EVPN:

[~hLeaf1-3-bgp]?

Current view commands:

<пропущено>

  keep-all-routes            Keep all original route's information

  load                       Load operation

  load-balancing             Change route load-balancing

<пропущено>

Донастроим hLeaf1-3:

evpn-overlay enable

bgp 65001

 l2vpn-family evpn                        <- появилась после включения evpn-overlay

  policy vpn-target

  peer RR enable

  peer RR advertise irb

  peer RR advertise-community

  peer 10.1.0.11 enable

  peer 10.1.0.11 group RR

  peer 10.1.0.12 enable

  peer 10.1.0.12 group RR

[~hLeaf1-3]dis bgp evpn group RR

Group in EVPN:

 BGP peer-group                       : RR

 Remote AS                            : 65001

 Authentication type configured       : MD5

 Group's BFD has been enabled

 Type                                 : internal

 Configured hold timer value   : 180

 Keepalive timer value         : 60

 Connect-retry timer value     : 32

 Minimum route advertisement interval is 15 seconds

 Connect-interface has been configured

 PeerSession Members                  :

 10.1.0.11                               10.1.0.12

 Send community has been configured

 Peer Preferred Value: 0

 No routing policy is configured

 Peer Members:

  Peer            V          AS  MsgRcvd  MsgSent  OutQ  Up/Down       State  PrefRcv

  10.1.0.11       4       65001       48        9     0 00:01:50 Established        0

  10.1.0.12       4       65001       50        9     0 00:01:50 Established        0

BGP EVPN установился с обоими вендорами. Пора настраивать Overlay!

Настройка Overlay

Ну что, готовы к гению технической мысли? Вот наша схема overlay:

Тем временем где-то высококвалифицированный инженер с регалиями CCIE/HCIE получает психический шок:

Да не переживайте вы так! Мы же не просто пытаемся разобраться в вопросах совместимости, но и попробовать по пути ответить на вопросы: «а если так?», «почему нет?», «кто-то проверял?» и даже «какого …………?». Пробуем, комментируем, корректируем. Кстати, на коммутаторах Eltex я легко соберу такую схему.

Настройки L2/L3 VNI

Итак, настройки cLeaf1-1:

nv overlay evpn

feature fabric forwarding

feature interface-vlan

feature vn-segment-vlan-based

feature nv overlay

fabric forwarding anycast-gateway-mac 1234.5678.abcd

vlan 10,20,3000-3001

vlan 10

  vn-segment 20010

vlan 20

  vn-segment 20020

vlan 3000

  vn-segment 30000

vlan 3001

  vn-segment 30001

vrf context A

  vni 30000

  rd 10.1.0.13:30000

  address-family ipv4 unicast

    route-target import 1.2.3.4:3000

    route-target import 1.2.3.4:3000 evpn

    route-target export 1.2.3.4:3000

    route-target export 1.2.3.4:3000 evpn

vrf context B

  vni 30001

  rd 10.1.0.13:30001

  address-family ipv4 unicast

    route-target import 1.2.3.4:3001

    route-target import 1.2.3.4:3001 evpn

    route-target export 1.2.3.4:3001

    route-target export 1.2.3.4:3001 evpn

interface Vlan10

  no shutdown

  vrf member A

  ip address 10.1.10.1/24

  fabric forwarding mode anycast-gateway

interface Vlan20

  no shutdown

  vrf member B

  ip address 10.1.20.1/24

  fabric forwarding mode anycast-gateway

interface Vlan3000

  no shutdown

  vrf member A

  ip forward

interface Vlan3001

  no shutdown

  vrf member B

  ip forward

interface nve1

  no shutdown

  host-reachability protocol bgp

  source-interface loopback0

  member vni 20010

    suppress-arp

    ingress-replication protocol bgp

  member vni 20020

    suppress-arp

    ingress-replication protocol bgp

  member vni 30000 associate-vrf

  member vni 30001 associate-vrf

evpn

  vni 20010 l2

    rd 10.1.0.13:20010

    route-target import 10.1.10.0:10

    route-target export 10.1.10.0:10

  vni 20020 l2

    rd 10.1.0.13:20020

    route-target import 10.1.20.0:20

    route-target export 10.1.20.0:20

Настройки eLeaf1-2:

ip vrf A

 vni 30000

 route-target both 1.2.3.4:3000

exit

!

ip vrf B

 vni 30001

 route-target both 1.2.3.4:3001

exit

!

!

vlan database

 vlan 11,20,3000-3001

exit

!

port jumbo-frame

vxlan VLAN11

 vni 20011

 arp-suppression

 vlan 11

 route-target both 10.1.11.0:11

exit

!

vxlan VLAN20

 vni 20020

 arp-suppression

 vlan 20

 route-target both 10.1.20.0:20

exit

!

vxlan VRF_A

 vni 30000 ip-routing

 vlan 3000

exit                                                  

!                                                     

vxlan VRF_B                                           

 vni 30001 ip-routing                                 

 vlan 3001                                            

exit       

anycast-gateway mac-address 12:34:56:78:ab:cd

interface vlan 11

 name CustomerA-2

 ip vrf A                                             

 ip address 10.1.11.1 255.255.255.0

 anycast-gateway

exit

!

interface vlan 20

 name CustomerB-1

 ip vrf B

 ip address 10.1.20.1 255.255.255.0

 anycast-gateway

exit

!

interface vlan 3000

 name VRF_A

 ip vrf A

exit

!

interface vlan 3001

 name VRF_B

 ip vrf B

exit

router bgp 65001

 vrf A

  address-family ipv4 unicast

   network 0.0.0.0 mask 0.0.0.0

   redistribute connected

  exit

 exit

 !

 vrf B

  address-family ipv4 unicast

   network 0.0.0.0 mask 0.0.0.0

   redistribute connected

  exit

 exit

exit

Настройки hLeaf1-3:

evpn-overlay enable

evpn

 mac-duplication

ip vpn-instance A

 ipv4-family    

  route-distinguisher 10.1.0.18:30000

  vpn-target 1.2.3.4:3000 export-extcommunity evpn

  vpn-target 1.2.3.4:3000 import-extcommunity evpn

 vxlan vni 3000 

#               

ip vpn-instance B

 ipv4-family    

  route-distinguisher 10.1.0.18:30001

  vpn-target 1.2.3.4:3001 export-extcommunity evpn

  vpn-target 1.2.3.4:3001 import-extcommunity evpn

 vxlan vni 3001

bridge-domain 12

 vxlan vni 20012

 #              

 evpn           

  route-distinguisher 10.1.0.18:20012

  vpn-target 10.1.12.0:12 export-extcommunity

  vpn-target 10.1.12.0:12 import-extcommunity

#               

bridge-domain 21

 vxlan vni 20021

 #              

 evpn           

  route-distinguisher 10.1.0.18:20021

  vpn-target 10.1.21.0:21 export-extcommunity

  vpn-target 10.1.21.0:21 import-extcommunity

interface Vbdif12

 ip binding vpn-instance A

 ip address 10.1.12.1 255.255.255.0

 mac-address 1234-5678-abcd

 vxlan anycast-gateway enable

 arp collect host enable

 arp direct-route enable

#               

interface Vbdif21

 ip binding vpn-instance B

 ip address 10.1.21.1 255.255.255.0

 mac-address 1234-5678-abcd

 vxlan anycast-gateway enable

 arp collect host enable

 arp direct-route enable

interface Nve1  

 source 10.1.0.18

 vni 20012 head-end peer-list protocol bgp

 vni 20021 head-end peer-list protocol bgp

bgp 65001

 ipv4-family vpn-instance A

  import-route direct

  advertise l2vpn evpn

 #              

 ipv4-family vpn-instance B

  import-route direct

  advertise l2vpn evpn

Настройки EVPN Multihoming

Перед тем, как настраивать EVPN Multihoming, давайте вспомним, что мы успешно настроили его в фабрике Eltex. Но сейчас нам надо настроить его для пары Eltex/Cisco и Eltex/Huawei.

Какие же команды используются у этих заморских вендоров?

Cisco:

evpn esi multihoming – глобальная команда на включение

Huawei:

interface eth-trunk <X>

 esi xxxx.xxxx.xxxx.xxxx.xxxx

Посмотрим, что у нас:

Cisco:

cLeaf1-1(config)# evpn ?

  <CR>           

  multisite      Multisite

  storm-control  Storm-control

Huawei:

[~hLeaf1-3-Eth-Trunk0]e?

  enable                                  erps

Ни там, ни там нет нужных нам команд… Ну, берем инструкцию, читаем.

Cisco:

See the following limitations for configuring VXLAN EVPN multi-homing:

EVPN multi-homing is only supported on first generation Cisco Nexus 9300 platform switches. It is not supported on Cisco Nexus 9200 switches nor on Cisco Nexus 9300-EX switches (and newer models)

Huawei:

Constraints on the EVPN ESI All-Active Function

Only the CE5881, CE6881, CE6881K, CE6863K, CE6863E, CE6881E, and CE6863 support the EVPN ESI all-active function

Смотрим на наши коммутаторы:

cLeaf1-1# show version 

Software

  NXOS: version 10.1(2)

Hardware

  cisco Nexus9000 C93180YC-EX chassis

[~hLeaf1-3]dis version 

YunShan OS, Version 1.24.0.1 (CE6800 V300R024C00SPC500)

HUAWEI CE6866-48S8CQ-P

Джекпот! Ни Cisco, ни Huawei не поддерживают EVPN Multihoming на наших коммутаторах.

А значит проверить данный функционал на совместимость мы не сможем. А еще это значит, что если вы предполагаете менять коммутаторы Cisco или Huawei в ЦОД, то делать это нужно как минимум парами, потому что эти вендоры используют VPC/MLAG для организации отказоустойчивых подключений (ограничение в 2 коммутатора). А вот если понадобится заменить 1 коммутатор Eltex, то можно использовать любой коммутатор, который поддерживает EVPN Multihoming, потому что это не проприетарная технология.

Что ж, прокомментировали, теперь подкорректируем нашу схему:

Настройки Access ports

Наш тестовый коммутатор Maipu, который мы используем для симуляции конечного оборудования, имеет следующие физические подключения:

TestEndpoint#sh lldp neighbors 

Index        Local Intf           Hold-time  Capability     Peer Intf                        Device ID          

1            100ge0/49            120        B,R            Ethernet1/53                     cLeaf1-1           

2            100ge0/52            120        B,R            hu1/0/2                          eLeaf1-2           

3            100ge0/54            120        B,R            100GE1/0/1                       hLeaf1-3  

Настроим соответствующие Peer Intf на коммутаторах.

cLeaf1-1:

interface Ethernet1/53

  switchport

  switchport mode trunk

  switchport trunk allowed vlan 10,20

  speed 100000

  duplex full

  fec rs-fec

  no negotiate auto

  no shutdown

eLeaf1-2:

interface HundredGigabitEthernet1/0/2

 switchport mode trunk

 switchport trunk allowed vlan add 11,20

 fec cl91

exit

hLeaf1-3:

interface 100GE1/0/1

 port link-type trunk

 device transceiver 100GBASE-COPPER

 negotiation disable

 fec mode rs

#

interface 100GE1/0/1.12 mode l2

 encapsulation dot1q vid 12

 bridge-domain 12

#               

interface 100GE1/0/1.21 mode l2

 encapsulation dot1q vid 21

 bridge-domain 21

Обратили внимание на масштаб трагедии, если нам, скажем, понадобится на 48 портов Huawei прописать 100 VLAN в какую-нибудь систему виртуализации? Придется создавать 48*100=4800 подинтерфейсов!

Давайте проверять.

Проверка

Проверка связности

Для простоты будем проверять связность от имени конечных IP с адресами 10.1.10.100 (VRF A) и 10.1.20.100 (VRF B) – они расположены за коммутатором Cisco.

Тест доступности из VRF A:

Доступность шлюза на коммутаторе Cisco, VRF A из VRF A:

TestEndpoint#ping vrf Pod1VRFA 10.1.10.1  

Press key (ctrl + shift + 6) interrupt it.

Sending 5, 76-byte ICMP Echos to 10.1.10.1 , timeout is 0 seconds:

!!!!!

Success rate is 100% (5/5). Round-trip min/avg/max = 1/1/1 ms.

Доступность хоста на коммутаторе Eltex, VRF A из VRF A:

TestEndpoint#ping vrf Pod1VRFA 10.1.11.100

Press key (ctrl + shift + 6) interrupt it.

Sending 5, 76-byte ICMP Echos to 10.1.11.100 , timeout is 0 seconds:

!!!!!

Success rate is 100% (5/5). Round-trip min/avg/max = 1/1/1 ms.

Доступность хоста на коммутаторе Huawei, VRF A из VRF A:

TestEndpoint#ping vrf Pod1VRFA 10.1.12.100

Press key (ctrl + shift + 6) interrupt it.

Sending 5, 76-byte ICMP Echos to 10.1.12.100 , timeout is 0 seconds:

!!!!!

Success rate is 100% (5/5). Round-trip min/avg/max = 1/1/1 ms.

Доступность хоста на коммутаторе Cisco, VRF B из VRF A:

TestEndpoint#ping vrf Pod1VRFA 10.1.20.100

Press key (ctrl + shift + 6) interrupt it.

Sending 5, 76-byte ICMP Echos to 10.1.20.100 , timeout is 0 seconds:

.....

Success rate is 0% (0/5). 

Доступность хоста на коммутаторе Eltex, VRF B из VRF A:

TestEndpoint#ping vrf Pod1VRFA 10.1.20.101

Press key (ctrl + shift + 6) interrupt it.

Sending 5, 76-byte ICMP Echos to 10.1.20.101 , timeout is 0 seconds:

.....

Success rate is 0% (0/5). 

Доступность хоста на коммутаторе Huawei, VRF B из VRF A:

TestEndpoint#ping vrf Pod1VRFA 10.1.21.100

Press key (ctrl + shift + 6) interrupt it.

Sending 5, 76-byte ICMP Echos to 10.1.21.100 , timeout is 0 seconds:

.....

Success rate is 0% (0/5).

Тест доступности из VRF B:

Доступность шлюза на коммутаторе Cisco, VRF B из VRF B:

TestEndpoint#ping vrf Pod1VRFB 10.1.20.1

Press key (ctrl + shift + 6) interrupt it.

Sending 5, 76-byte ICMP Echos to 10.1.20.1 , timeout is 0 seconds:

!!!!!

Success rate is 100% (5/5). Round-trip min/avg/max = 1/1/1 ms.

Доступность хоста на коммутаторе Eltex, VRF B из VRF B:

TestEndpoint#ping vrf Pod1VRFB 10.1.20.101

Press key (ctrl + shift + 6) interrupt it.

Sending 5, 76-byte ICMP Echos to 10.1.20.101 , timeout is 0 seconds:

!!!!!

Success rate is 100% (5/5). Round-trip min/avg/max = 1/1/1 ms.

Доступность хоста на коммутаторе Huawei, VRF B из VRF B:

TestEndpoint#ping vrf Pod1VRFB 10.1.21.100

Press key (ctrl + shift + 6) interrupt it.

Sending 5, 76-byte ICMP Echos to 10.1.21.100 , timeout is 0 seconds:

!!!!!

Success rate is 100% (5/5). Round-trip min/avg/max = 1/1/1 ms.

Доступность хоста на коммутаторе Cisco, VRF A из VRF B:

TestEndpoint#ping vrf Pod1VRFB 10.1.10.100

Press key (ctrl + shift + 6) interrupt it.

Sending 5, 76-byte ICMP Echos to 10.1.10.100 , timeout is 0 seconds:

.....

Success rate is 0% (0/5).

Доступность хоста на коммутаторе Eltex, VRF A из VRF B:

TestEndpoint#ping vrf Pod1VRFB 10.1.11.100

Press key (ctrl + shift + 6) interrupt it.

Sending 5, 76-byte ICMP Echos to 10.1.11.100 , timeout is 0 seconds:

.....

Success rate is 0% (0/5).

Доступность хоста на коммутаторе Huawei, VRF A из VRF B:

TestEndpoint#ping vrf Pod1VRFB 10.1.12.100

Press key (ctrl + shift + 6) interrupt it.

Sending 5, 76-byte ICMP Echos to 10.1.12.100 , timeout is 0 seconds:

.....

Success rate is 0% (0/5).

Всё работает! Даже не так – всё работает, как задумано! Или нет? Проверим на коммутаторах?

Проверка на коммутаторах

Посмотрим таблицу EVPN на Cisco:

cLeaf1-1# sh bgp l2vpn evpn | i 10.1....10[01]

*>l[2]:[0]:[0]:[48]:[ccd8.1f47.173d]:[32]:[10.1.10.100]/272

*>i[2]:[0]:[0]:[48]:[aaaa.bbbb.cc52]:[32]:[10.1.11.100]/272

*>i[2]:[0]:[0]:[48]:[aaaa.bbbb.cc52]:[32]:[10.1.20.101]/272

*>l[2]:[0]:[0]:[48]:[ccd8.1f47.173d]:[32]:[10.1.20.100]/272

* i[2]:[0]:[0]:[48]:[aaaa.bbbb.cc52]:[32]:[10.1.11.100]/272

*>i[2]:[0]:[0]:[48]:[aaaa.bbbb.cc52]:[32]:[10.1.20.101]/272

*>i[5]:[0]:[0]:[32]:[10.1.12.100]/224

*>i[5]:[0]:[0]:[32]:[10.1.21.100]/224

*>i[2]:[0]:[0]:[48]:[aaaa.bbbb.cc52]:[32]:[10.1.11.100]/272

*>i[5]:[0]:[0]:[32]:[10.1.12.100]/224

*>i[2]:[0]:[0]:[48]:[aaaa.bbbb.cc52]:[32]:[10.1.20.101]/272

*>i[5]:[0]:[0]:[32]:[10.1.21.100]/224

Обратите внимание, что IP 10.1.11.100 и 10.1.20.101 с коммутатора Eltex присутствуют в таблице как EVPN записи типа 2, а вот IP 10.1.12.100 и 10.1.21.100 с коммутатора Huawei присутствуют только как EVPN записи типа 5. Почему?

А что говорит коммутатор Eltex?

eLeaf1-2#sh ip bgp l2vpn evpn | i 10.1....10[01]

*>i[2][0][0][48][cc:d8:1f:47:17:3d][32][10.1.10.100]/272

* i[2][0][0][48][cc:d8:1f:47:17:3d][32][10.1.10.100]/272

*>i[2][0][0][48][cc:d8:1f:47:17:3d][32][10.1.20.100]/272

* i[2][0][0][48][cc:d8:1f:47:17:3d][32][10.1.20.100]/272

*>a[2][0][0][48][aa:aa:bb:bb:cc:52][32][10.1.11.100]/272

*>a[2][0][0][48][aa:aa:bb:bb:cc:52][32][10.1.20.101]/272

*>i[2][0][0][48][cc:d8:1f:47:17:3d][32][10.1.12.100]/272

* i[2][0][0][48][cc:d8:1f:47:17:3d][32][10.1.12.100]/272

*>i[2][0][0][48][cc:d8:1f:47:17:3d][32][10.1.21.100]/272

* i[2][0][0][48][cc:d8:1f:47:17:3d][32][10.1.21.100]/272

*>i[5][0][0][32][10.1.12.100]/224

* i[5][0][0][32][10.1.12.100]/224

*>i[5][0][0][32][10.1.21.100]/224

* i[5][0][0][32][10.1.21.100]/224

Хм… Тут присутствуют и записи EVPN типа 2 и записи типа 5.

Давайте разбираться. Как Huawei генерирует EVPN тип 5? Для этого используется команда «advertise l2vpn evpn»:

bgp 65001

 ipv4-family vpn-instance A

  advertise l2vpn evpn

 ipv4-family vpn-instance B

  advertise l2vpn evpn

А как генерируется запись EVPN типа 2? Для этого используются ext-community:

bridge-domain 12

 vxlan vni 20012

 #              

 evpn           

  route-distinguisher 10.1.0.18:20012

  vpn-target 10.1.12.0:12 export-extcommunity

  vpn-target 10.1.12.0:12 import-extcommunity

Давайте попробуем убрать «advertise l2vpn evpn» на Huawei и посмотрим выводы команд снова.

Cisco:

cLeaf1-1# sh bgp l2vpn evpn | i 10.1....10[01]

*>l[2]:[0]:[0]:[48]:[ccd8.1f47.173d]:[32]:[10.1.10.100]/272

*>i[2]:[0]:[0]:[48]:[aaaa.bbbb.cc52]:[32]:[10.1.11.100]/272

*>i[2]:[0]:[0]:[48]:[aaaa.bbbb.cc52]:[32]:[10.1.20.101]/272

*>l[2]:[0]:[0]:[48]:[ccd8.1f47.173d]:[32]:[10.1.20.100]/272

* i[2]:[0]:[0]:[48]:[aaaa.bbbb.cc52]:[32]:[10.1.11.100]/272

*>i[2]:[0]:[0]:[48]:[aaaa.bbbb.cc52]:[32]:[10.1.20.101]/272

*>i[2]:[0]:[0]:[48]:[aaaa.bbbb.cc52]:[32]:[10.1.11.100]/272

*>i[2]:[0]:[0]:[48]:[aaaa.bbbb.cc52]:[32]:[10.1.20.101]/272

Eltex:

eLeaf1-2#sh ip bgp l2vpn evpn | i 10.1....10[01]

*>i[2][0][0][48][cc:d8:1f:47:17:3d][32][10.1.10.100]/272

* i[2][0][0][48][cc:d8:1f:47:17:3d][32][10.1.10.100]/272

*>i[2][0][0][48][cc:d8:1f:47:17:3d][32][10.1.20.100]/272

* i[2][0][0][48][cc:d8:1f:47:17:3d][32][10.1.20.100]/272

*>a[2][0][0][48][aa:aa:bb:bb:cc:52][32][10.1.11.100]/272

*>a[2][0][0][48][aa:aa:bb:bb:cc:52][32][10.1.20.101]/272

*>i[2][0][0][48][cc:d8:1f:47:17:3d][32][10.1.12.100]/272

* i[2][0][0][48][cc:d8:1f:47:17:3d][32][10.1.12.100]/272

*>i[2][0][0][48][cc:d8:1f:47:17:3d][32][10.1.21.100]/272

* i[2][0][0][48][cc:d8:1f:47:17:3d][32][10.1.21.100]/272

Так, записи EVPN типа 5 пропали, но на Eltex, в отличие от Cisco, остались записи EVPN типа 2. В чем же отличие? Сейчас мне будет стыдно, потому что…

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

А на Cisco, так уж совпало, уже был и VLAN 12, и VLAN 21, да только с другими ext-commuity:

evpn

  vni 20012 l2

    rd 10.11.0.6:20012

    route-target import 65100:20012

    route-target export 65100:20012

  vni 20021 l2

    rd 10.11.0.6:20021

    route-target import 65100:20021

    route-target export 65100:20021

А на Huawei тем временем:

bridge-domain 12

 vxlan vni 20012

 evpn           

  route-distinguisher 10.1.0.18:20012

  vpn-target 10.1.12.0:12 export-extcommunity

  vpn-target 10.1.12.0:12 import-extcommunity

#               

bridge-domain 21

 vxlan vni 20021

 evpn           

  route-distinguisher 10.1.0.18:20021

  vpn-target 10.1.21.0:21 export-extcommunity

  vpn-target 10.1.21.0:21 import-extcommunity

Получается, что EVPN пакеты от Huawei до Cisco доходят, да не принимаются, так как не совпадают ext-community. Ладно, нам по схеме Overlay (исправленной) всё равно не надо, чтобы на cLeaf1-2 были записи L2VNI для VLAN 12 и VLAN 21. Поэтому просто немного зачистим конфигурацию на Cisco. Но почему тогда эти записи приходят на Eltex?!

Версия Иван-дурак 2.0, дополненная. После написания статьи о настройке фабрики Eltex я, опять же, не стал чистить конфигурацию на eLeaf1-2, поэтому там остались записи:

vxlan VLAN12

 vni 20012

 arp-suppression

 vlan 12

 route-target both 10.1.12.0:12

exit

!

vxlan VLAN21

 vni 20021

 arp-suppression

 vlan 21

 route-target both 10.1.21.0:21

exit

Поэтому-то на коммутаторе Eltex и присутствуют эти записи EVPN тип 2. Уберем эти настройки с eLeaf1-2. Проверим?

eLeaf1-2:

eLeaf1-2#sh ip bgp l2vpn evpn | i 10.1....10[01]

*>i[2][0][0][48][cc:d8:1f:47:17:3d][32][10.1.10.100]/272

* i[2][0][0][48][cc:d8:1f:47:17:3d][32][10.1.10.100]/272

*>i[2][0][0][48][cc:d8:1f:47:17:3d][32][10.1.20.100]/272

* i[2][0][0][48][cc:d8:1f:47:17:3d][32][10.1.20.100]/272

*>a[2][0][0][48][aa:aa:bb:bb:cc:52][32][10.1.11.100]/272

*>a[2][0][0][48][aa:aa:bb:bb:cc:52][32][10.1.20.101]/272

*>i[2][0][0][48][cc:d8:1f:47:17:3d][32][10.1.12.100]/272

* i[2][0][0][48][cc:d8:1f:47:17:3d][32][10.1.12.100]/272

*>i[2][0][0][48][cc:d8:1f:47:17:3d][32][10.1.21.100]/272

* i[2][0][0][48][cc:d8:1f:47:17:3d][32][10.1.21.100]/272

А?! Что?! Иван-дурак, версия 3.0?! Не хочу! А сделаю-ка я быстрый тест – заведу на Huawei вообще новый VLAN777 и новую сеть 7.7.7.0/24 (тестовый хост 7.7.7.7), чтобы проверить. Сказано – сделано (пропущу здесь настройки на Huawei, не благодарите). Быстро проверяем на коммутаторах.

Cisco:

cLeaf1-1# sh bgp l2vpn evpn | i 7.7.7

<пусто>

Eltex:

eLeaf1-2#sh ip bgp l2vpn evpn | i 7.7.7

*>i[2][0][0][48][cc:d8:1f:47:17:3d][32][7.7.7.7]/272

* i[2][0][0][48][cc:d8:1f:47:17:3d][32][7.7.7.7]/272

Что получается? Cisco, получая пакеты по EVPN видит, что это не её ext-community (vpn-target) и не обрабатывает их. Eltex же игнорирует ext-community и добавляет в таблицу В ЛЮБОМ СЛУЧАЕ. И пусть это можно назвать косметическим багом, но ведь эти записи точно хранятся где-то в памяти и снижают полезную нагрузку. В реальной жизни, конечно, вы будете настраивать одни и те же VxLAN на всех коммутаторах Leaf.

Давайте вернем назад на Huawei анонс EVPN Type 5 и уберем все временные настройки.

Итак, на данном этапе у нас есть полная связность (см. раздел «Проверка связности»).

Мы посмотрели записи EVPN, но не посмотрели маршруты.

Почему же у нас есть связность? Ограничим нашу диагностику только для VRF A.

Cisco:

cLeaf1-1# sh ip route vrf A

10.1.12.0/24, ubest/mbest: 1/0

    *via 10.1.0.18%default, [200/0], 00:07:34, bgp-65001, internal, tag 65001, segid: 3000 (Asymmetric) tunnelid: 0xa010012 encap: VXLAN

10.1.12.1/32, ubest/mbest: 1/0

    *via 10.1.0.18%default, [200/0], 00:07:34, bgp-65001, internal, tag 65001, segid: 3000 (Asymmetric) tunnelid: 0xa010012 encap: VXLAN

10.1.12.100/32, ubest/mbest: 1/0

    *via 10.1.0.18%default, [200/0], 00:07:34, bgp-65001, internal, tag 65001, segid: 3000 (Asymmetric) tunnelid: 0xa010012 encap: VXLAN

Eltex:

eLeaf1-2#sh ip route vrf A

B    10.1.12.0/24 [200/0] via 10.1.0.18, 00:07:42, VNI 30000, router-mac   

28:53:4e:83:26:51                                                          

B    10.1.12.1/32 [200/0] via 10.1.0.18, 00:07:42, VNI 30000, router-mac   

28:53:4e:83:26:51                                                          

B    10.1.12.100/32 [200/0] via 10.1.0.18, 00:07:42, VNI 30000,            

router-mac 28:53:4e:83:26:51

Мы ожидаем, что связность у нас достигается за счет Symmetric IRB, так как в качестве назначения указаны L3 VNI. Так почему в выводе команды на Cisco указано «Asymmetric»?

Проверим настройки L3 VNI на Cisco:

vlan 3000

  vn-segment 30000

vlan 3001

  vn-segment 30001

Настройки L3 VNI на Huawei:

ip vpn-instance A

 vxlan vni 3000 

ip vpn-instance B

 vxlan vni 3001

Вот и ошибка! Случайно (или нет?) на Huawei я указал неправильный L3 VNI!

Это же мы видим в поле Label Information на Huawei (приходит 30000, а не 3000):

[~hLeaf1-3]dis bgp vpnv4 vpn-instance A routing-table 10.1.10.100 

 BGP local router ID : 10.1.0.18

 Local AS number : 65001

 VPN-Instance A, Router ID 10.1.0.18:

 Paths:   2 available, 1 best, 1 select, 0 best-external, 0 add-path

 BGP routing table entry information of 10.1.10.100/32:

 Route Distinguisher: 10.1.0.13:20010

 Remote-Cross route

 Evpn route: Type 2, irb

 Label information (Received/Applied): 30000/NULL

 From: 10.1.0.11 (10.1.0.11)

 Route Duration: 1d02h59m57s

 Relay Tunnel Out-Interface: VXLAN

 Original nexthop: 10.1.0.13

 Qos information : 0x0

 Ext-Community: RT <1.2.3.4 : 3000>, RT <10.1.10.0 : 10>, Tunnel Type <VxLan>, Router's MAC <a023-9f3b-3545>

 AS-path Nil, origin igp, localpref 100, pref-val 0, valid, internal, best, select, pre 255

 Originator: 10.1.0.13

 Cluster list: 10.1.0.11

 Not advertised to any peer yet

Исправляем на hLeaf1-3:

ip vpn-instance A

 vxlan vni 30000

ip vpn-instance B

 vxlan vni 30001

И проверяем на cLeaf1-1:

cLeaf1-1# sh ip route vrf A

    *via 10.1.0.14%default, [200/0], 21:26:20, bgp-65001, internal, tag 65001, segid: 30000 tunnelid: 0xa01000e encap: VXLAN

10.1.12.0/24, ubest/mbest: 1/0

    *via 10.1.0.18%default, [200/0], 00:04:15, bgp-65001, internal, tag 65001, segid: 30000 tunnelid: 0xa010012 encap: VXLAN

10.1.12.1/32, ubest/mbest: 1/0

    *via 10.1.0.18%default, [200/0], 00:04:15, bgp-65001, internal, tag 65001, segid: 30000 tunnelid: 0xa010012 encap: VXLAN

10.1.12.100/32, ubest/mbest: 1/0

    *via 10.1.0.18%default, [200/0], 00:04:15, bgp-65001, internal, tag 65001, segid: 30000 tunnelid: 0xa010012 encap: VXLAN

Готово! Теперь нам приходит по L3 VNI 30000.

Но это очень интересная мысль для разработчиков – всего одно слово «Asymmetric» показало мне, что я где-то неправильно настроил коммутатор. Eltex, возьмете на заметку?

Выводы

Что ж, мы можем много всего протестировать на совместимость, сравнить фичи и особенности реализации. Но фактически мы будем использовать минимальный базовый функционал для построения фабрики ЦОДов. Конечно, очень важно, чтобы реализация ПО была основана на конкретных RFC с учетом аппаратных особенностей конкретного оборудования – тогда вопросы совместимости не будут настолько актуальны.

Мы выяснили, что вполне можем миксовать сетевое оборудование для построения ЦОДа. А еще мы выяснили, что службы эксплуатации и автоматизации ни за что не скажут нам за это спасибо.

Также мы увидели, что всегда есть нюансы реализации конкретных технических решений, как, например, в случае настройки отказоустойчивого решения MLAG/VPC/EVPN Multihoming. Каждый производитель сетевого оборудования сам определяет способ организации High Availability, но в случае с Cisco и Huawei, я бы сказал, что наблюдается некая коммерческая/маркетинговая нотка: «Вы можете поставить в пару только наше оборудование». Здесь мне больше импонирует решение Eltex – оно открытое (не проприетарное) и позволяет, при необходимости, собрать High Availability более чем на 2 коммутаторах, а также не требует дополнительных физических линков между коммутаторами.

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

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

P.S.

Дописав 3-ю статью об оборудовании Eltex – о настройке фабрики ЦОД, ее нагрузочном тестировании и совместимости с оборудованием других производителей, –  я вдруг поймал себя на мысли: а как вы, коллеги-инженеры, думаете, ошибки, которые мы с вами разбирали в статьях, случайны или были заложены специально? Когда вам дают готовую рабочую конфигурацию оборудования (на старте это здорово!) и всё работает, сможете ли вы найти причину, если что-то пошло не так?

Скажу лишь одно – эти статьи написаны от имени простого инженера для таких же инженеров, как и он сам. От инженера, который может допускать ошибки («забыл», «очепятался», «не учел», «ошибка copy/paste» и т.д.), но, несомненно, от инженера, который всегда проверяет качество своей работы в конце.

А мнение о том, были ли эти ошибки случайными, пишите в комментариях, как говорится!

Конец

Вот и написаны статьи, в которых мы с вами сосредоточились на технических возможностях и функционале коммутаторов ЦОДа компании Eltex. Много команд для настройки и проверок, тернистый путь от простого к сложному, но, надеюсь, у вас сложилось мнение об этом оборудовании, которое очень важно не только для самого производителя сетевого оборудования, но и для инженеров, которые им пользуются.

Впереди осталась последняя статья: о системе управления Eltex ECCM. Там, уже расслабившись от технически нагруженных статей, мы будем, как маленькие дети, смотреть много красивых картинок и разбирать ее возможности. 

Кстати, если кто-то хочет посмотреть на работу Eltex вживую, приглашаю на наше мероприятие по ЦОДам 28 октября в Москве. Покажем лабораторию, демо-стенды с оборудованием для ЦОД, склад ЗИП. Поговорим о том, что вообще сейчас происходит на рынке ЦОДов – законодательство, дефицит мощностей, энергоэффективность, оборудование, техподдержка и тд. Участие бесплатное, регистрация тут 

А пока…