L3 a kontejnery bez overlay: Project Calico prakticky (3) – BGP

V minulém díle jsme nainstalovali Calico na dva Docker hostitele a BGP protokol zajistil výměnu informací o IP adresách kontejnerů. Dnes se na BGP podíváme blíž a napojíme ho do sítě datového centra.

Pro úvod do konceptů L3 fabricu a nasazení Calico se můžete vrátit k článku o L3 fabric.

Calico a jeden rack

Nejprve se podívejme na situaci, kdy provozujete pár desítek fyzických serverů v jednom racku. V rámci ukázky to budou dva hostitelé ve formě VM, které jsme si připravili minule, a top-of-rack prvek budeme simulovat virtuálním routerem HPE VSR s operačním systémem Comware. V praxi to ovšem může být cokoli, třeba HPE Altoline disagregovaný prvek a na něm OpenSwitch operační systém.

Ve výchozím stavu (jak jsme viděli minule) používá Calico mesh peering mezi nody, takže malé prostředí máte hned nahoře a nepotřebujete nic dalšího. Tuto funkci ale pro nasazení s top-of-rack prvkem nechceme. Vypněte ji a koukněte co se stalo – Calico odmazalo peery.

docker@node1:~$ calicoctl bgp node-mesh off
docker@node1:~$ sudo -E calicoctl status
calico-node container is running. Status: Up About an hour
Running felix version 1.4.0rc1

IPv4 BGP status
IP: 192.168.99.101    AS Number: 64511 (inherited)
+--------------+-----------+-------+-------+------+
| Peer address | Peer type | State | Since | Info |
+--------------+-----------+-------+-------+------+
+--------------+-----------+-------+-------+------+

IPv6 BGP status
No IPv6 address configured.

Tím pádem nevidí IP adresy kontejnerů na druhém hostiteli (což se dalo čekat).

docker@node1:~$ ip r
default via 10.0.2.2 dev eth0  metric 1
10.0.2.0/24 dev eth0  proto kernel  scope link  src 10.0.2.15
blackhole 10.111.0.0/26  proto bird
10.111.0.1 dev cali696be34ff1e  scope link
10.111.0.2 dev cali769dd09cf1e  scope link
blackhole 10.111.0.128/26  proto bird
10.111.0.150 dev cali6d865923f1e  scope link
127.0.0.1 dev lo  scope link
172.17.0.0/16 dev docker0  proto kernel  scope link  src 172.17.0.1
192.168.99.0/24 dev eth1  proto kernel  scope link  src 192.168.99.101

Pro jednoduchost (máme přecijen pouze jeden rack) použijeme globální nastavení pro všechny Calico nody (tato informace je sdílena v Etcd). Nastavte výchozí číslo BGP autonomního systému na 65000 a přidejte globálního peera ve stejném AS s adresou 192.168.99.200 (tam později bude Comware router).

docker@node1:~$ calicoctl bgp default-node-as 65000
docker@node1:~$ calicoctl bgp peer add 192.168.99.200 as 65000

Použili jsme globální konfiguraci (všechny Calico nody chceme nastavené stejně), takže na node2 nemusíme nic dělat.

Do stejné sítě (192.168.99.0/24) jsem přidal VM s HPE VSR – virtuálním Comware routerem. Nastavme v něm adresaci, BGP v AS 65000, peering do dvou našich Docker hostitelů a zapněme funkci Route reflectoru.

interface LoopBack1
 ip address 10.0.0.1 255.255.255.255
#
interface GigabitEthernet1/0
 port link-mode route
 ip address 192.168.99.200 255.255.255.0
#
bgp 65000
 router-id 10.0.0.1
 peer 192.168.99.101 as-number 65000
 peer 192.168.99.102 as-number 65000
 #
 address-family ipv4 unicast
  peer 192.168.99.101 enable
  peer 192.168.99.101 reflect-client
  peer 192.168.99.102 enable
  peer 192.168.99.102 reflect-client

To bychom měli. Vidí VSR naše Calico nody?

<HPE>dis bgp peer ipv4

   BGP local router ID: 10.0.0.1
   Local AS number: 65000
   Total number of peers: 2                 Peers in established state: 2

    * - Dynamically created peer
    Peer                    AS  MsgRcvd  MsgSent OutQ PrefRcv Up/Down  State

    192.168.99.101       65000        6        5    0       3 00:01:41 Established
    192.168.99.102       65000       17       47    0       3 00:06:56 Established

Vidí. A naučil se nějaké routy?

<HPE>dis ip routing-table protocol bgp

Summary Count : 5

BGP Routing table Status : <Active>
Summary Count : 4

Destination/Mask   Proto   Pre Cost        NextHop         Interface
10.111.0.0/26      BGP     255 0           192.168.99.101  GE1/0
10.111.0.3/32      BGP     255 0           192.168.99.102  GE1/0
10.111.0.4/32      BGP     255 0           192.168.99.102  GE1/0
10.111.0.128/26    BGP     255 0           192.168.99.101  GE1/0

Perfektní – naučil. Protože funguje jako route reflector, měli bychom v našich hostitelých vidět cestu ke všem kontejnerům bez nutnosti přímého BGP peeringu mezi nimi. Je to tak?

docker@node1:~$ ip r
default via 10.0.2.2 dev eth0  metric 1
10.0.2.0/24 dev eth0  proto kernel  scope link  src 10.0.2.15
blackhole 10.111.0.0/26  proto bird
10.111.0.1 dev cali696be34ff1e  scope link
10.111.0.2 dev cali769dd09cf1e  scope link
10.111.0.3 via 192.168.99.102 dev eth1  proto bird
10.111.0.4 via 192.168.99.102 dev eth1  proto bird
blackhole 10.111.0.128/26  proto bird
10.111.0.150 dev cali6d865923f1e  scope link
127.0.0.1 dev lo  scope link
172.17.0.0/16 dev docker0  proto kernel  scope link  src 172.17.0.1
192.168.99.0/24 dev eth1  proto kernel  scope link  src 192.168.99.101

docker@node2:~$ ip r
default via 10.0.2.2 dev eth0  metric 1
10.0.2.0/24 dev eth0  proto kernel  scope link  src 10.0.2.15
10.111.0.0/26 via 192.168.99.101 dev eth1  proto bird
10.111.0.3 dev cali96fdd530f1e  scope link
10.111.0.4 dev cali99a85c7df1e  scope link
10.111.0.128/26 via 192.168.99.101 dev eth1  proto bird
127.0.0.1 dev lo  scope link
172.17.0.0/16 dev docker0  proto kernel  scope link  src 172.17.0.1
192.168.99.0/24 dev eth1  proto kernel  scope link  src 192.168.99.102

Gratuluji – právě jste rozjeli BGP mezi Docker hostiteli a vaším top-of-rack prvkem. Můžeme se teď třeba rozhodnout, že hostitel by měl znát cestu k loopback síti v top-of-rack. Stačí ji ve VSR oznamovat a ověříme, že se objevila v nodech, a že na ni hostitel dokáže pingnout.

Nastavíme router.

bgp 65000
 address-family ipv4 unicast
  network 10.0.0.1 255.255.255.255

Prohlédneme výsledek v hostiteli a zkusíme ping.

docker@node1:~$ ip r
default via 10.0.2.2 dev eth0  metric 1
10.0.0.1 via 192.168.99.200 dev eth1  proto bird
10.0.2.0/24 dev eth0  proto kernel  scope link  src 10.0.2.15
blackhole 10.111.0.0/26  proto bird
10.111.0.1 dev cali696be34ff1e  scope link
10.111.0.2 dev cali769dd09cf1e  scope link
10.111.0.3 via 192.168.99.102 dev eth1  proto bird
10.111.0.4 via 192.168.99.102 dev eth1  proto bird
blackhole 10.111.0.128/26  proto bird
10.111.0.150 dev cali6d865923f1e  scope link
127.0.0.1 dev lo  scope link
172.17.0.0/16 dev docker0  proto kernel  scope link  src 172.17.0.1
192.168.99.0/24 dev eth1  proto kernel  scope link  src 192.168.99.101


docker@node1:~$ ping 10.0.0.1
PING 10.0.0.1 (10.0.0.1): 56 data bytes
64 bytes from 10.0.0.1: seq=0 ttl=255 time=2.245 ms
64 bytes from 10.0.0.1: seq=1 ttl=255 time=1.302 ms

Máme hotovo. V rámci racku máme jednu „spojovačku“, tedy VLAN/síť, ve které mluví naše BGP zařízení (čili top-of-rack a compute nody). V praxi bychom určitě použili ToR prvky dva. Pro řadu nasazení máme hotovo. Ale co když je prostředí větší?

Calico a celé datové centrum

V jednom z článků jsem popisoval topologii L3 fabric s využitím Calico v serverech. Typické nasazení je použití L3 principů mezi leaf prvky (top-of-rack) a spine prvky, konkrétně BGP. Nejčastější nasazení je eBGP, tedy každý rack (dvojice ToR) má svoje AS. V takovém případě už nám nestačí, aby celé Calico mělo identicky nastavený peering a číslo AS. Calico uzle v jednom racku budou peerovat do svého ToR ve svém AS, ve druhém racku se naváží na svůj ToR v jiném AS. ToR prvky pak peerují s prvky ve spine vrstvě. V našem jednodušším případě (kde spine nemám) propojíme oba racky napřímo. Pojďme si to vyzkoušet.

Globální nastavení peeringu zrušíme.

docker@node1:~$ sudo -E calicoctl bgp peer remove 192.168.99.200

Pro jednoduchost nebudeme měnit adresy nodů a ponecháme je všechny i s routery ve stejné síti, ale BGP nastavíme jako kdyby to tak nebylo (pro pochopení nastavení a výsledku je to teď jedno).

Na node1 nastartujte Calico v AS 65000 a přidejte peering (per-node, proto je v příkazu slovo node) do routeru 192.168.99.200.

docker@node1:~$ sudo -E calicoctl node --as 65000
docker@node1:~$ sudo -E calicoctl node bgp peer add 192.168.99.200 as 65000

V node2, který je „v druhém racku“, nastartujeme v AS 65001 a vytvoříme per-node peering na router 192.168.99.201 (ten zatím neexistuje, ale to napravíme).

docker@node2:~$ sudo -E calicoctl node --as 65001
docker@node2:~$ sudo -E calicoctl node bgp peer add 192.168.99.201 as 65001

Upravíme konfiguraci našeho VSR routeru. Už nebudeme peerovat s 192.168.99.102 (ten už je součástí jiného AS), za to ale peerujeme přes eBGP do druhého ToR (reprezentovaného routerem, který teprve vytvoříme, 192.168.99.201 v AS 65001).

#
bgp 65000
 router-id 10.0.0.1
 peer 192.168.99.101 as-number 65000
 peer 192.168.99.201 as-number 65001
 #
 address-family ipv4 unicast
  network 10.0.0.1 255.255.255.255
  peer 192.168.99.101 enable
  peer 192.168.99.101 reflect-client
  peer 192.168.99.201 enable

Teď přidáme další VSR, dáme mu loopback 10.0.0.2 a adresu 192.168.99.201 a nastavíme jeho BGP. Běží v AS 65001, peeruje do Calico na adrese 192.168.99.102 a také přes eBGP na sousedního top-of-rack (192.168.99.200 v AS 65000).

#
bgp 65001
 router-id 10.0.0.2
 peer 192.168.99.102 as-number 65001
 peer 192.168.99.200 as-number 65000
 #
 address-family ipv4 unicast
  network 10.0.0.2 255.255.255.255
  peer 192.168.99.102 enable
  peer 192.168.99.102 reflect-client
  peer 192.168.99.200 enable

To bude všechno. Teď bychom měli ověřit směrovací tabulku v prvním routeru a zejména si prohlédnout, co jsme se naučili uvnitř svého AS a co vně. Soustřeďme se tedy na písmenko „i“ vs. „e“ případně na Path políčko.

[HPE-bgp]dis bgp routing-table ipv4

 Total number of routes: 8

 BGP local router ID is 10.0.0.1
 Status codes: * - valid, > - best, d - dampened, h - history,
               s - suppressed, S - stale, i - internal, e - external
               Origin: i - IGP, e - EGP, ? - incomplete

     Network            NextHop         MED        LocPrf     PrefVal Path/Ogn

* >  10.0.0.1/32        127.0.0.1       0                     32768   i
* >e 10.0.0.2/32        192.168.99.201  0                     0       65001i
* >i 10.111.0.0/26      192.168.99.101             100        0       i
* >e 10.111.0.3/32      192.168.99.102                        0       65001i
* >e 10.111.0.4/32      192.168.99.102                        0       65001i
* >i 10.111.0.128/26    192.168.99.101             100        0       i
* >i 192.168.99.0       192.168.99.101             100        0       i
*  e                    192.168.99.102                        0       65001i

V druhém routeru to bude nepochybně opačně, ověřme to.

[HPE_2-bgp]dis bgp routing-table ipv4

 Total number of routes: 8

 BGP local router ID is 10.0.0.2
 Status codes: * - valid, > - best, d - dampened, h - history,
               s - suppressed, S - stale, i - internal, e - external
               Origin: i - IGP, e - EGP, ? - incomplete

     Network            NextHop         MED        LocPrf     PrefVal Path/Ogn

* >e 10.0.0.1/32        192.168.99.200  0                     0       65000i
* >  10.0.0.2/32        127.0.0.1       0                     32768   i
* >e 10.111.0.0/26      192.168.99.101                        0       65000i
* >i 10.111.0.3/32      192.168.99.102             100        0       i
* >i 10.111.0.4/32      192.168.99.102             100        0       i
* >e 10.111.0.128/26    192.168.99.101                        0       65000i
* >i 192.168.99.0       192.168.99.102             100        0       i
*  e                    192.168.99.101                        0       65000i

V tuto chvíli jsme rozchodili čistý L3 networking v modelu BGP AS per rack a vůbec to nebylo složité. A to považte, že jsme u „nejsložitější“ a nejškálovatelnější varianty. Využívá principů, na kterých stojí celý Internet. Stále nám ale chybí mikrosegmentační politiky, abychom konečně řekli, který kontejner kam smí komunikovat. To uděláme hned příště.

Series Navigation<< L3 a kontejnery bez overlay: Project Calico prakticky (2) – rozjezdL3 a kontejnery bez overlay: Project Calico prakticky (4) – mikrosegmentace >>
Similar posts
  • Moderní 10G v datovém centru s novou ... HPE tento týden oznámilo evoluční vývoj portfolia v oblasti data center 1U prvků s 10G/40G/100G technologií, konkrétně novou řadu 5940. Co je nového? Hardwarové vlastnosti Prvky přichází s novou generací 10/40/100 čipů, které umožnily mít nově prvky se 100G uplinky (a to hned šesti) a také přináší podporou nových vlastností jako je směrování VXLAN (předchozí [...]
  • OpenSwitch a Ansible automatizace pra... Posledně jsme si nastavili naší virtuální OpenSwitch leaf-spine topologii a vybudovali jsme BGP L3 fabric. Dnes si ukážeme více z životního cyklu s použitím Ansible – otestování sítě, vrácení odchylek do požadovaného stavu sítě a rolování změn. Jste líní číst? Mrkněte na video: Playbook pro testování sítě Ansible můžete použít i pro testování, že síť [...]
  • OpenSwitch a Ansible automatizace pra... Minule jsme napojili naši virtuální topologii na Ansible a spustili náš první testovací Playbook. Dnes provodeme automatizovanou konfiguraci L3 fabric a otestujeme síť. Příprava konfiguračních podkladů Pro zprovoznění L3 fabric potřebujeme Loopback adresu, IP adresy na jednotlivých spojeních mezi prvky a nastavení BGP (autonomní systémy, peering). V našem Ansible prostředí si vytvoříme jeden YAML soubor, [...]
  • OpenSwitch a Ansible automatizace pra... V minulém díle jsme si rozjeli Lead-Spine OpenSwitch topologii s využitím Dockeru a skript nám vygeneroval také hosts file pro Ansible. Dnes se vyzkoušíme napojení na Ansible 2.1. Příprava Ansible a vašeho VM První co potřebujeme udělat je nainstalovat Ansible minimálně ve verzi 2.1. Postup najdete zde: http://docs.ansible.com/ansible/intro_installation.html Dále vyřešíme nastavení SSH klienta v naší [...]
  • L3 a kontejnery bez overlay: Project ... Část 6 z celkových 6 v seriálu L3 a kontejnery bez overlay: Project Calico praktickyL3 a kontejnery bez overlay: Project Calico praktickyL3 a kontejnery bez overlay: Project Calico prakticky (1) – architekturaL3 a kontejnery bez overlay: Project Calico prakticky (2) – rozjezdL3 a kontejnery bez overlay: Project Calico prakticky (3) – BGPL3 a kontejnery bez [...]

No Comments Yet

Napsat komentář

Vaše emailová adresa nebude zveřejněna. Vyžadované informace jsou označeny *