Documento con revisione aggiornata su PC
E' possibile utilizzare VXLAN e BGP EVPN.
Le prime infrastrutture di IXP erano basate su un centrostella con due switch ridondati molto grandi e performati sulle quali erano configurate una o due VLAN sulle quali erano collegati tutti gli afferenti in configurazione singola o ridondata. L'infrastruttura di rete era pertando molto semplice e ridondata, almeno per chi richiedeva un accesso ad ogni VLAN.
Successivamente l'avvento di tecnologie chiamate "switching fabrics" permettevano la interconnessione a maglia di differenti switch senza necessita' di STP per loop-avoidance in quanto dotati di tecnologie quali stacking, Fabricpath/TRILL. Con questa soluzione e' possibile avere più switch "piccoli" invece di pochi grandi. Questo consente la creazione di una maglia di switch ridondati da distribuire anche su più sale e quindi scalare l'infrastruttura. In particolare il TRILL protocol utilizza IS-IS per calcolare il path ottimale in una maglia di switch senza bisogno di utilizzare STP e senza dover configurare indirizzi IP.
Gli svantaggi del Layer 2 sono:
- Utilizzo di MAC address;
- Le BPDU utilizzano CPU e crescono con il numero di VLAN;
- Meta' dei link della topologia sono bloccati;
- Problemi di configurazione possono creare loop di Layer 2 creando grossi problemi;
Le switching fabric L2 sono state sostituite progressivamente da IP fabrics L3. Ad esempio VXLAN (flooding), OTV (IS-IS con IP), LISP (IP/MAC). OTV utilizzata Inter-DC.
Intra datacenter FabricPath/TRILL/VXLAN/LISP (quest'ultimo per IP mobility)
Quindi si e' passati da switching fabric a IP fabric e overlay network.
------
All of these factors eventually led to the choice of NVIDIA Mellanox as the hardware vendor together with NVIDIA Cumulus Linux as the network OS, paired with an entirely in-source developed configuration framework based on Ansible.
The basic features of the IP fabric implementation based on VXLAN and BGP/EVPN are the following:
- All nodes properly act as L3 devices (routers) in the relationships between each other
- Customer traffic is switched locally on the node but routed when flowing between different nodes
- Customer traffic entering a leaf node and destined to a remote leaf node is encapsulated into UDP packets and then routed between nodes
- Tunnels are established between any leaf nodes which provide encapsulation and L3 forwarding of L2 frames
- BGP is used to exchange information about MAC address reachability between nodes, by means of an additional ‘evpn’ address family
- BGP ECMP (Equal Cost Multipath) is used to balance traffic load across multiple paths between leaf nodes
In short, the use of IP as the underlying “fabric” protocol, paired with BGP for dynamically controlling the data paths, ensures stability and simplicity of use, thus finally overcoming the complexity issues of meshed L2 networks. We’ll see more technical details about this in the next sections.
In this perspective, Cumulus Linux proved to be an ideal interface for network automation since:
- It provides native Ansible support (local execution of tasks)
- Network configuration is split into multiple files instead of a monolithic file
- Configuration change is achieved by rewriting and reloading files without the need for complex extraction and parsing of configuration snippets (this proves tremendously effective in all cases where you need to remove a specific configuration section)
Importante ANSIBLE
FUNZIONAMENTO DI BASE
L’idea di base delle VXLAN è quella ben nota delle overlay virtual networks, ossia la possibilità di realizzare una rete logica (virtuale) sopra una rete fisica esistente. La rete fisica esistente (la rete underlay !) è in questo caso una banale rete IP (v4 o v6, non fa differenza), ma potrebbe essere anche un altro tipo di rete. La convenienza che la rete underlay sia una rete IP è dovuta alla diffusione pervasiva di questo tipo di reti, ormai diventate a tutti gli effetti vere e proprie reti multiservizio.
La rete logica è in questo caso un semplice segmento LAN, denominato da qui in poi segmento VXLAN. Le trame Ethernet generate dagli host (fisici o virtuali) appartenenti a un particolare segmento VXLAN, vengono trasportate da host a host utilizzando un incapsulamento di tipo MAC-in-UDP, i cui dettagli saranno visti in una prossima sezione. In pratica ciò che avviene è la sostituzione, per il trasporto delle trame Ethernet, della rete switched Ethernet con una semplice rete IP. I vantaggi che ne conseguono sono enormi:
- Non è più necessario il protocollo Spanning Tree.
- Vengono eliminati alla radice i (gravi) problemi causati dai broadcast storm.
- Aumenta la banda disponibile poiché non esistono più porte nello stato blocking.
- È possibile sfruttare meglio tutta la banda a disposizione utilizzando le tecniche di load balancing tipiche dei protocolli di routing IP.
In breve, il concetto di VXLAN In breve, il concetto di VXLAN può essere pensato come una ulteriore applicazione trasportata in una rete IP, al pari di altre applicazioni ben note (HTTP, SMTP, FTP, DNS, ecc.).
These key aspects were leveraged at their best in the next phase of our process towards full network automation: automation of provisioning operations. Choosing the right approach was crucial at this stage, our goal was to develop a framework that could push configurations to the nodes starting from a high level interface such an administration dashboard that might eventually provide customers on-demand service configuration capabilities (example: “configure this VLAN between my router port and that customer router port”). This required the Ansible configuration framework to act as an interface layer between an higher level software system (currently under development) and the actual nodes.
Our first approach was to try and mimic the workings of CLI commands (yes, Cumulus also has its own CLI, named nclu) but this approach implied the same issues you have with traditional network operating systems, basically: you have your device status wired into the device itself.
The breakthrough was to understand that we needed to move the state out of each node and into an external repository, this proved to be most easy and effective way to go, because:
- External repository acts as a proxy between any higher-level software (think of IXP Manager or our own management software under development)
- Configurations can be generated on the fly by Ansible according to data retained in the repository
- Describing the desired final state of the node is actually the proper way Ansible was designed to work
- State repository can be managed as software code through a version management system such as Git
We thus developed our own configuration language inside the Ansible framework which enables us to perform basic provisioning tasks:
- Full customer interface configuration (single port, bond, VLAN behavior)
- Customer VLANs and supporting VNIs configuration
- Basic ACL configuration (MAC and protocol filtering)
We finally ended in a situation where, since day one, all provisioning operations were automated via Ansible playbooks
https://www.youtube.com/watch?v=OWKPxAgh9DU <--- ANSIBLE
https://www.youtube.com/watch?v=iIQ62T-Gsxw <--- ansible gui centos8
Nella figura compaiono due concetti chiave nel funzionamento delle VXLAN:
- VNI (VXLAN Network Identifier): è l’identificativo del segmento VXLAN. Praticamente sostituisce il VLAN tag come identificativo di un segmento LAN. Come si vedrà nel seguito nella sezione dedicata all’incapsulamento VXLAN, il VNI è di 24 bit, il che consente di definire più di 16,7 milioni di segmenti VXLAN (contro i 4096 (teorici) delle VLAN classiche).
- VTEP (VXLAN Tunnel End Point): è una funzione che gestisce l’origine e la terminazione, ossia l’incapsulamento e il decapsulamento, dei pacchetti VXLAN. Inoltre, si occupa di associare ciascun host a un determinato segmento VXLAN. Questa funzione può essere definita sia su una macchina fisica (es. un switch L2), oppure su un Hypervisor (es. VMware ESX/NSX, KVM, ecc.).
La funzione VTEP può essere pensata come costituita da due interfacce, una lato host per consentire il local bridging tra host appartenenti allo stesso segmento VXLAN, l’altra lato rete underlay. Per semplicità, chiameremo da qui in poi quest’ultima interfaccia, interfaccia VTEP. A ogni interfaccia VTEP viene assegnato un indirizzo IP, utilizzato come indirizzo IP sorgente dei pacchetti VXLAN.
Poiché le trame Ethernet generate dagli host vengono incapsulate dalla funzione VTEP in pacchetti UDP/IP e a destinazione, sempre da una funzione VTEP vengono decapsulate, una VXLAN può anche essere pensata come uno schema di tunneling di trame di Livello 2 (trame Ethernet) su una rete di Livello 3 (la rete IP underlay). I tunnel sono di tipo stateless, che significa che ciascuna trama L2 viene incapsulata seguendo certe regole, e i router della rete underlay non hanno bisogno di alcuno stato aggiuntivo per espletare la funzione di trasporto. Inoltre, gli host si comportano come normali host connessi a un normale switch L2, e sono totalmente ignari della modalità di trasporto. La gestione dei VNI e dell’incapsulamento e decapsulamento delle trame L2 è demandata interamente alla funzione VTEP.
- Open Network Linux. Open Network Linux is a Linux distribution for open hardware switches, i.e. network forwarding devices built from commodity components. ...
- SONiC. SONiC is an open source network operating system based on Linux that runs on switches from multiple vendors and ASICs.
- + VAGRANT
Commenti
Posta un commento