Modification on Unknown Unicast Policy

[Lee Yau Mun]

Hi,

I would like to know what is the impact to concurrent traffic if I modify from Layer 2 Unknown Unicast to Hardware Proxy?

We are not dare to modify the setting as we saw a warning box saying it might flap the interface that connected to this particular EPG/BD. 

Hence, do it really flap the interface once I modify to Hardware Proxy?

[richmond]

Yes, all interfaces associated with the BD will go down and then come back up. Do this in a maintenance window and advertise an outage for it. Try testing it with a test BD to see the behaviour. 

[Manuel Velasco · Accepted solution]

Hi Lee,

What that message mean is that there would be a small interruption in the traffic on the BD when you make the change from flood to proxy or proxy to flood.  It doesn't mean that you need to flap the interfaces.  If you have critical applications that are sensitive to traffic disruption, it is recommended to make this change during a MW.

[Lee Yau Mun]

Hi Manuel,
Yes. APIC did showing the caution message when we change from L2 Unknown Unicast to Hardware proxy.
Did APIC really bounce the interface when we make the changes?

[Manuel Velasco]

No, it does not bounce the interfaces, it bounces the traffic through the BD.  

[richmond]

Are you sure about this? When I tested it the ports to a neighbouring switch did bounce when I changed the BD forwarding mode.

[Manuel Velasco]

Yes, 100% sure. If the interfaces were to bounce other the traffic for other BDs could be affected.  

For example, if you were to configure your ACI fabric in network centric, where you define one BD to one VLAN, and let’s assume that you have a single port channel trunking all your vlans to your legacy Network.  If the operation above were to flap the interfaces associated to the BD you would not just see traffic disruption on the BD where you made the change but instead to all of the BD using the same port channel.

if the interfaces bounce when you made this change, I would suggest for you to open a TAC case to have them take a look at your setup, you might be hitting a defect.

[richmond]

Thanks. I'll try it again once the lab is online.

[KELLEYD]

Are you REALLY sure? I'm running 3.0(1k) and literally had a change this last Tuesday where I had to change unknown unicast from hardware proxy to flood. I tested this first in my lab. I had an EPG in this BD statically mapped to two ports. One was trunk, the other was 802.1p.

Both ports FLAPPED. Line proto down, link down. Link up line proto up. It was painful to watch.

So, before performing the change on Tuesday, I had to delete all static mappings where I can't have the port bounce, then re apply them. It was "fun" :)

[Luke Poskitt]

I'm currently encountering the same concerns as the posters above regarding the warning message as it would appear to unambiguously indicate that any interfaces associated with EPGs that are associated with the BD will bounce.

Consequently, as almost all of our EPGs/BDs share common trunks, I'm very reluctant to change the L2 behavior.