M3-packet flow
1.COOP
council of oracle protoocl
IP traffic means
if destination is router MAC
Non-IP ?
Destination MAC is not router MAC
if connect to external network using L2
flooding is faster than hardware proxy
if use hardware proxy
if link down between legacy sw and leafe 3 and4, traffic may be disrupted if link down
unless switch A/B send traffic
destination MAC is unknown to spine COOP
example silent host
should use flooding mode
VPC traffic flow
there will be a dedicated anycastTEP IP to represent the 2 VPC peer switch
step 3 Spine send to dedicated anycast VPC TEP IP but pick leaf 2
Lab 6
Explain create DB_BD (with DB-VM) and allow unicast routing between this 2 BD
APP VM is consumer in different DB
create contract between them
Lab 7
task 1
step 1-6
result: App VM see the arp request
Test scenario: Ping from web VM (10.0.1.1): ping 10.0.1.3 (non-existence) and verify at App VM (10.0.1.2)
default: hardware proxy with ARP flooding enabled (checked)
task 2 Prevent ACI from learning ARP
step 7: uncheck (disable)ARP flooding
will see ARP gleaning
ARP request sent by ARP prevasive GW (10.0.1.254)
s1: Vswitch set to promiscuous mode
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
Enable back hardware proxy with flooding eabled
- Maintain static ARP entry on Web-VM
Verify 1 : when Web-VM ping APP-VM, ping fail
those host enable static ARP
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
Enable L2 unknown unicast to Flood and ARP Flooding
verify: Web-VM ping App-VM
Ping work
ACI flood initial ICMP echo
ACI learn both endpoint although no ARP was involved
Basic BD
default
hardware proxy for L2 unknow unicast
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).
unicast routing enabled
click to edit
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
IP add and virtual MAC
refer to anycast diagram
It provide a given endpoint always can use the local default gateway
function on the Cisco ACI leaf node to which it is connected
pervasive GW ?
The default gateway IP address of endpoint will be the pervasive gateway of the ACI fabric
ARP Gleaning
click to edit
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
- Leaf 3 does table lookup and sends a packet with the source of Leaf3 TEP IP address
flooding of L2 unknown unicast packet
click to edit
When set to Flood, unknown unicast frames are flooded in the BD.
When set to Hardware Proxy, unknown unicast frames are sent to the spine proxy for lookup
Note: Modifying the L2 Unknown Unicast setting causes the BD to get
redeployed on the leaf switches. This means there is a slight disruption in
service when making this change.
Unknown L3 multicast flood
click to edit
When set to Flood, if an L3 multicast packet is received, the packet is flooded to all interfaces in the BD, even if there are no receivers
When set to Optimized, if an L3 multicast packet is received, the packet is only to router port
. If there are no router ports, the packet is dropped.
Multidestination flooding
click to edit
When set to Flood in BD, floods the packet in the BD.
When set to Flood in Encapsulation, floods the packet only in the VLAN
encapsulation it was received in.
When set to Drop, drops the packet.
custom MAC
When virtual MAC is configured, it becomes router-mac for the BD. Hence the packet with DMAC set to physical MAC (custom MAC in GUI) is no longer routed on the BD but just bridged.
ARP requests for any of SVI subnets on the BD is resolved with this virtual MAC. If it wasn’t resolved with virtual MAC
Virtual MAC
When virtual MAC is configured, it becomes router-mac for the BD. Hence the packet with DMAC set to physical MAC (custom MAC in GUI) is no longer routed on the BD but just bridged.
ARP requests for any of SVI subnets on the BD is resolved with this virtual MAC. If it wasn’t resolved with virtual MAC,
click to edit
click to edit
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
subnet scope
click to edit
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.