Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
New Member

Unknown unicast control in Cisco Metro Products

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?

1 ACCEPTED SOLUTION

Accepted Solutions

Unknown unicast control in Cisco Metro Products

Hi ,

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

Regards

Dan

12 REPLIES

Unknown unicast control in Cisco Metro Products

Hi ,

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

Regards

Dan

New Member

Unknown unicast control in Cisco Metro Products

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

Unknown unicast control in Cisco Metro Products

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

Dan

New Member

Unknown unicast control in Cisco Metro Products

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.

Unknown unicast control in Cisco Metro Products

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

New Member

Unknown unicast control in Cisco Metro Products

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 ? 

Unknown unicast control in Cisco Metro Products

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

New Member

Re: Unknown unicast control in Cisco Metro Products

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.

Unknown unicast control in Cisco Metro Products

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

New Member

Unknown unicast control in Cisco Metro Products

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.

Unknown unicast control in Cisco Metro Products

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

New Member

Re: Unknown unicast control in Cisco Metro Products

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

1149
Views
0
Helpful
12
Replies
CreatePlease to create content