Iată ce mi-am dat seama (răspunzând la propria întrebare):
De ce și cum face Azure acest lucru?
De ce:
Spre deosebire de rețelele fizice, Azure are avantajul unei evidențe a tuturor sistemelor și interfețelor de rețea din mediu.
Într-o rețea fizică, „Address Resolution Protocol”, adică ARP este un protocol bazat pe difuzare pentru descoperirea mașinilor într-un domeniu de difuzare sau într-un mediu L2 „atașat local”. Acest lucru este necesar doar pentru că nu există o înregistrare centrală.
Azure funcționează fără transmisii. Este mai eficient și nu este necesar când cunoști deja toate mașinile din subrețea.
Cum a direcționat pachetele la L3?:
Pentru problema de rutare, Azure observă toate pachetele care părăsesc Alice și le trimite lui Bob fără a ține cont de ruta implicită a sistemului de operare. Nu contează dacă pachetul destinat pentru 10.0.2.5 a fost transmis către 10.0.1.4 pentru rutare. Acea direcție L2 ar fi folosit ARP, care nu funcționează aici. În schimb, vnet-ul controlează complet L3. Cu un tip de rută Azure „vnet local” într-un tabel de rutare eficient, pachetul este livrat direct către Bob, indiferent dacă se află sau nu în aceeași subrețea.
„vnet local” pentru intervalul de adrese vnet este implicit în Azure. Această rută trebuie să fie suprascrisă în UDR-ul subrețelei pentru ca pachetul să fie livrat către „router”
Cum ar trebui să se facă acest lucru?
Tabelele de rutare locale pe VM-uri sunt aproape ignorate (încă trebuie să fiți atenți la interfața pe care o lasă un pachet, deoarece aceasta afectează subrețeaua în care apare și tabelul de rutare aplicat).
Având în vedere că L2 este unicast, L3 permite destinații în afara subrețelei și tabelele de rutare Azure sunt aplicate subrețelei, este posibil un design complet diferit.
„Ar trebui” nu este clar, dar asta am făcut.
Observați că routerul rutează între două subrețele acolo unde are nicio interfață în acele subrețele.
