Unknown unicast control in Cisco Metro Products

[anazarenko]

I am curious how ISPs control unknown unicast towards subscriber ports in recent Metro aggregation products? SUP720-10G had this feature in 6500 afair, but what about recent products?

[Dan-Ciprian Cicioiu · Accepted solution]

Hi ,

"switchport block unicast"  is supported also on metro switches.

Regards

Dan

[anazarenko]

Do you tune ARP timer as well? I can't imagine scenario where this command can't be harmful.

[Dan-Ciprian Cicioiu]

Personaly I do not use "block unicast" . Regarding the arp timer , I prefer to change the mac-address-table aging timer

Dan

[anazarenko]

The  issue with increasing FDB ageing is blackholing of traffic in case of instabilities such as switch reboot, link flap, STP TCN. In all scenarios basically, when the switch looses its FDB table and there's no any kind of keepalive mechanism from the customer like PPPoE. The fact that this filtering is globally enabled per interface instead of per VLAN makes this command useless in real world.

[Dan-Ciprian Cicioiu]

I dont realy understand  the issues that you are talking about.

As per my understanding "block unicast" will block frames that have an unknown unicast destination. Unkown to its local FDB. Broadcast required to complete the ARP table does not go in this category.  My understanding is that a host will want to comunicate inside a brodcast domain with another host - including here its gateway , first it will try to learn it's mac and entering it in the arp table. This process is made using ARP request, and has as destination address the broadcast mac address.

Dan

[anazarenko]

What will happen with incoming traffic towards the customer when his port flaps and FDB gets flushed in scenario when old ARP entry exists on Cisco router with ageing time of 4 hours ? 

[Dan-Ciprian Cicioiu]

As I told you , if you modify the FDB aging timer to be higher the the ARP time out.

The router will make a ARP request via a broadcast. The host will respond with its own mac addr as a source. The switch will reset the FDB aging timer. The router will update the ARP table .

Dan

[anazarenko]

yes correct, but then the switch will finally loose end-station MAC, due to the reasons described above and all traffic from the router will be blackholed. You are trying to explain the ideal book scenario , which has no relationship with a real world.

[Dan-Ciprian Cicioiu]

Not quite.

"Loose" is very general. Generaly speaking if there is communication between those to hosts there is almost no reason to lose the mac-address. And therefore the switch will keep its FDB update to date.

If the switch reset. The host interface will go down, it's arp table will be flushed. When the switch will come UP, the host connected to it will generate a ARP request to find the other host's mac-address and to populate it's arp table. This way the switch that was reloaded - and let's suppose that the other host is connected to other switch in the network - and also other switches in the path to the other host will update the FDB.

Dan

[anazarenko]

Host connected on the customer side may not generate ARP, there are thousand situations when it may happen.

1) It has no traffic to send and just wants to get incoming request, e.g. SIP call.

2) It didn't detect link failure, e.g. DSLAM  or FTTH CPE between host and aggregation switch, so it just keeps the previous ARP entry.

3) TCN happened in the backbone.

4) EARL7 mac flushing when removing vlans.

[Dan-Ciprian Cicioiu]

We can go on and on

As a general rule the FDB aging time should be higher then the ARP timeout. ARP request/reply will update the FDB.

1) SIP call also uses bidirectional flows, as far as I know.

2) I'm reserved regarding link failure detection.

3) Has impact only for the case of ARP not aged, and there is no traffic at all between hosts.

4) This will have an impact if there is no traffic at that moment between hosts and ARP will be not age out for a period higher then the one in which hosts will start communicating.

Dan

[anazarenko]

This will have impact in all above cases

FTTH/DSL equipment is in general not OAM aware.

if SIP customer can't get incoming INVITE ( which is dropped by any of 2),3),4) cases, due to missed FDB entry and taking into account that default ARP ageing time is 4h) , SIP will not establish bidirectional signalling communication if caller from abroad wants to reach you, unless some kind of keepalive signalling is enabled.

Usually ISPs are not aware what is plugged in user ports and what kind of applications they are using and especially what  ARP timeouts they are using.

Decreasing ageing time on the provider router is also not a good choice. 

In 99,9% the network can't function properly without unknown unicast and there's only one solution for this: storm control or rate-limiting.

Which is unfortunately not supported on anything except sup720-10G and maybe sup-2T