Please enable JavaScript.

Coggle requires JavaScript to display documents.

M3-packet flow - Coggle Diagram

- - - - uses the mapping database to forward unknown unicast traffic to the destination port without relying on flood-and-learn behavior, as long as the MAC address
        is known to the spine (which means that the host is not a silent host).
  - - - If this setting is enabled and a subnet address is configured, it fabric provides the default gateway function and routes the traffic
      - It also instructs the mapping database to learn the endpoint IP-to-VTEP mapping for this bridge domain. The IP learning is not dependent upon having a subnet configured
  - - - A glean packet is generated and sent to all leaves that have the VRF instance deployed.
      - When leaves receive this glean packet and and an ARP request is sent out all interfaces that have the target BD that deployed
      - Once host reply the ARP, sends a COOP update to the spines so the endpoint can be installed
      - Mean silent hostt tracking
        
        Spine will inform leaf to send ARP request with source of ACI BD prevasive address & flood to all leaf switch
      - destination will be set to GIPO Multicast adddresss
  - - - Public: The subnet can be advertised via a routed connection using a dynamic routing protocol.
      - ■ Private: The subnet applies only within its tenant.
      - ■ Shared: The subnet can be shared with and exported to multiple VRF instances in
      - the same tenant or across tenants as part of a shared service. An example of a shared
      - service is a routed connection to an EPG present in another VRF in a different tenant. This is sometimes referred to as a “shared L3-out,” and it enables traffic to pass
      - in both directions across VRF instances.
- - - - result: App VM see the arp request
      - default: hardware proxy with ARP flooding enabled (checked)
    - - will see ARP gleaning
        
        ARP request sent by ARP prevasive GW (10.0.1.254)
  - - - S2- 5: add static ARP in Web and APP VM
        
        this will prevent from sending ARP request
      - s6: change BD unknow unicast to flooding instead of Hardware Proxy with ARP flooding uncheck(disabled)
      - Verification= Ping from non-existence IP from Web-VM and verify at App-VM
        
        will see the the ICMP echo request
        
        ping fail since it is non-existence
    - - Maintain static ARP entry on Web-VM
      - Verify 1 : when Web-VM ping APP-VM, ping fail
        
        because ACI doesn't know where to forward L2 unknow
        
        ARP gleaning doesn't help because ACI didn't receive ARP request
      - Verify 2: Ping App-VM from web-VM
        
        ping works
        
        because ACI has learned both endpoint
    - - verify: Web-VM ping App-VM
        
        Ping work
        
        ACI flood initial ICMP echo
        
        ACI learn both endpoint although no ARP was involved