Steven,
Did you have a SUP720C or B? How do I find out what the limit on the ND table size is? Good article on IPv6 MLD snooping here: http://blog.ipspace.net/2014/09/ipv6-neighbor-discovery-nd-and.html Frank From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Lee, Steven Sent: Wednesday, September 10, 2014 9:49 AM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: Re: [WIRELESS-LAN] IPv6 on wireless experiences? Jason, We went through this a few years ago. At the time, we had about 8000 IPv6 clients on each of our 720's. We fought with it for about a semester until we could replace them with SUP2T's. I dug up some notes from 2011 and included some lessons learned/ best practices below. Things may have changed since then so please consult with your SE before trying any of this. 1. ND table size- Once you reach the max, all traffic from additional clients is SW processed. We did exceed the table size, but other factors below actually had more of an effect on our CPU. 2. ND table reachability timer - The default ND reachability timer is 30 seconds as defined by the ND RFC. This is too aggressive for a wireless deployment, driving up the CPU as it tries to send out solicitations and write to the ND table for thousands of clients. The table rewrite chews up CPU. We played with the timers and settled on changing it to 5 minutes. We were concerned about the table limit size as once the table reaches its max, as all traffic from additional clients is processed in SW. 3. Mcast - the Sup720 processes mcast in SW, this means all RA's, NS's, bonjour, etc. will drive your interrupt CPU high. We started blocking L2 multicast at the interface before it could go to the CPU 4. Cisco recommended that we enable IPv6 multicast on all your core routers. Cisco stated that this will allow MLD snooping to handle most of the IPv6 solicitation messages (instead of sending them to the CPU). Sounds good in theory, but it had unintended consequences that forced all the mcast traffic that we were blocking in #2 to get punted to the CPU. Cisco said bug. You may want to follow up on this as we moved to the SUP2T 5. Deny ICMP redirects on your client facing interfaces. - another measure to reduce demand on CPU resources. Cisco may tell you to also deny ICMP unreachables. If your running dual stack, this is a bad idea. 6. uRPF for IPv6 was done solely in SW on the 720. We replaced with appropriate ACL's (HW based) In short, depending on the number of IPv6 clients your expecting, you may want to consider another solution. Id be happy to provide more detail if you need. steve From: Jason Chan <szeho.c...@utoronto.ca <mailto:szeho.c...@utoronto.ca> > Reply-To: The EDUCAUSE Wireless Issues Constituent Group Listserv <WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU <mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> > Date: Tuesday, September 9, 2014 10:35 PM To: "WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU <mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> " <WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU <mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> > Subject: Re: [WIRELESS-LAN] IPv6 on wireless experiences? I was wondering if anyone is having issues with exceeding NDP entries number on routers? I'm also about to enable IPv6 on wireless but I've been advised by Cisco to watch out for the NDP table size limit on our 6500 with SUP720-3B, which is only 15K entries. On the IPv4 side we are slightly above 28K (out of 30K recommended maximum) entries on one of our routers. Jason -- Jason Chan Enterprise Infrastructure Solutions, Information + Technology Services University of Toronto Phone: (416)946-5233 Email: szeho.c...@utoronto.ca <mailto:szeho.c...@utoronto.ca> ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/. ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.
