Re: [c-nsp] wisdom of switchport block ...
I have been thinking about doing he same thing on our customer access networks. I would be curious what others features you are enabling as well good topic! Sent from my iPhone On Feb 9, 2014, at 6:34 PM, Mike mike-cisconspl...@tiedyenetworks.com wrote: Hello, I am looking at tightening up my subscriber access network and, if I understand the documentation correctly, 'switchport block unicast' will prevent a cisco switch (3560g in this case) from flooding unicast frames out any port so configured, unless the destination mac address was learned from that port. Is there any reason on earth why I would NOT want to have this as a standard default option? Arp would still work, as would dhcp and pppoe... trying to fathom how this could be bad? Would appreciate any insights! Thank you. Mike- ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] wisdom of switchport block ...
Hi, Hello, I am looking at tightening up my subscriber access network and, if I understand the documentation correctly, 'switchport block unicast' will prevent a cisco switch (3560g in this case) from flooding unicast frames out any port so configured, unless the destination mac address was learned from that port. Is there any reason on earth why I would NOT want to have this as a standard default option? It will break connectivity in the direction network -- host when the host is inactive for 5 minutes (or mac address-table aging-time xy when configured other than default) and will only be restored when the host originates traffic (not the other way around). This can be very dangerous depending on your use-case. Arp would still work ARP default timeout on Cisco gear is 4 hours, while the switch aging time is 5 minutes. So in the worst case it would work the first five minutes and then fail for the next 235 minutes. Also keep in mind that ARP likes to use unicast request when the destination mac is known and valid (when refreshing the arp table entry) and only falls back to broadcast when the entry is purged from the table. would dhcp If your lease time is below 5 minutes, sure. and pppoe... PPP keepalives will keep the switch from purging the mac from the table, so this may actually work. Is there any reason on earth why I would NOT want to have this as a standard default option? Like mentioned above, this breaks connectivity if your host is idle. Since you are talking about a subscriber access network, this may work if you use PPPoE or IPoE/DHCP with short lease timers, but evaluate carefully. Regards, Lukas ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] wisdom of switchport block ...
hey, I am looking at tightening up my subscriber access network and, if I understand the documentation correctly, 'switchport block unicast' will prevent a cisco switch (3560g in this case) from flooding unicast frames out any port so configured, unless the destination mac address was learned from that port. Blocking unknown unicast is very typical for access networks using service-vlans (or N:1, whatever you like to call it). MAC aging and DHCP lease timers will have to be tuned accordingly, make sure DHCP aging. This way DHCP renewals will keep active addresses in the MAC table. -- tarko ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] wisdom of switchport block ...
Hi, Let's not forget STP topology change notifications (TCNs) because they'll cause the MAC address entries to age out in forward-delay (15 sec) or even immediately with Rapid-STP. A STP topology change is observed (and TCN generated) when a non-edge (non-portfast) port goes either from Forwarding to Blocking or from Blocking to Forwarding. With RSTP non-edge port moving to Forwarding will generate TCNs. This can lead to hosts becoming unreachable with unicast blocking even with a carefully chosen ARP aging timer. Regards, Andras On Mon, Feb 10, 2014 at 7:30 PM, Tarko Tikan ta...@lanparty.ee wrote: hey, I am looking at tightening up my subscriber access network and, if I understand the documentation correctly, 'switchport block unicast' will prevent a cisco switch (3560g in this case) from flooding unicast frames out any port so configured, unless the destination mac address was learned from that port. Blocking unknown unicast is very typical for access networks using service-vlans (or N:1, whatever you like to call it). MAC aging and DHCP lease timers will have to be tuned accordingly, make sure DHCP aging. This way DHCP renewals will keep active addresses in the MAC table. -- tarko ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] wisdom of switchport block ...
hey, Let's not forget STP topology change notifications (TCNs) because they'll cause the MAC address entries to age out in forward-delay (15 sec) or even immediately with Rapid-STP. TCN will also screw up IGMP snooping and will cause multicast flooding for N * general-query-timeout. As a best practice, run all customer facing ports with portfast and BPDU guard. -- tarko ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] wisdom of switchport block ...
You pose an interesting question wrt what the default should be. I don't have that answer. On the same token, unknown unicast flooding is required for certain topologies to work - campus networks come to mind. ...Your network, you decide based on your topology what to leave-enabled and what to disable. ./Randy From: Mike mike-cisconspl...@tiedyenetworks.com To: cisco-nsp@puck.nether.net cisco-nsp@puck.nether.net Sent: Sunday, February 9, 2014 4:34 PM Subject: [c-nsp] wisdom of switchport block ... Hello, I am looking at tightening up my subscriber access network and, if I understand the documentation correctly, 'switchport block unicast' will prevent a cisco switch (3560g in this case) from flooding unicast frames out any port so configured, unless the destination mac address was learned from that port. Is there any reason on earth why I would NOT want to have this as a standard default option? Arp would still work, as would dhcp and pppoe... trying to fathom how this could be bad? Would appreciate any insights! Thank you. Mike- ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
