We've encountered this as well, and looking at a few options and would appreciate feedback or other ideas.
1) The suggestion we received from TAC was to summarize IPv6 routes. Our border router also contains VRFs, so we would need to contact our transit providers to summarize prior to receiving them. 2) Drop some routes, and renegotiate with our transits to receive a default v6 route. 3) Link our transit connections to CERs instead. That's not an option we would likely pursue immediately, but we're anticipating the v4 DFZ table exceeding 768K in 18-24 months, at current growth rates (we're on the multi-service-4 profile). 4) Upgrade to line cards with larger CAM, at substantial cost. On 09/12/16 14:43 +0000, David Hubbard wrote:
Ugh, that’s bad news. I guess they’ve decided dual stack routers should not also have VRF’s. ☹ David From: Youssef Bengelloun-Zahr <[email protected]> Date: Monday, September 12, 2016 at 10:27 AM To: David Hubbard <[email protected]> Cc: "[email protected]" <[email protected]> Subject: Re: [f-nsp] Does VRF still take CAM resources from 'ipv4 vpn' in later MLXe code? Dear David, I just heard back from my SE and it seems that your RFE has been "returned" ie rejected in June 2016. Best regards. 2016-08-31 20:10 GMT+02:00 Youssef Bengelloun-Zahr <[email protected]<mailto:[email protected]>>: I can always ask my SE to check its' status on my end. I'll be definitly interested if you get a feedback. Best regards. Le 31 août 2016 à 19:43, David Hubbard <[email protected]<mailto:[email protected]>> a écrit : Ah, good catch, I forgot about the RFE. It’s 102535. I’ll attempt to find its status. From: Youssef Bengelloun-Zahr <[email protected]<mailto:[email protected]>> Date: Wednesday, August 31, 2016 at 12:36 PM To: David Hubbard <[email protected]<mailto:[email protected]>> Cc: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: Re: [f-nsp] Does VRF still take CAM resources from 'ipv4 vpn' in later MLXe code? Dear David, I'm in the exact same case. I have started seeing those exact IPv6 CAM error related messages 3 weeks ago. Interestingly enough, only getting those for MLXe boxes and not CER-RT. I'm running 5.7e and about to upgrade to 5.8e. If memory serves right, I think I read something in some release notes (or other documentation) about a special feature/profil that would accomodate CAM for 1 VRF. I can't seem to recall which, so I'd invite you to read the litterature. Also, IIRC, I think I read That someone put up an RFE for this following your thread two years ago. Best regards. Le 31 août 2016 à 18:20, David Hubbard <[email protected]<mailto:[email protected]>> a écrit : Hey all, in 2014 I ran into an issue where I converted an MLXe to the ipv4-ipv6-2 profile to get maximum routes for both. When I did that, I lost management access because I use management VRF’s, and those require resources from the ‘IPv4 VPN’ segment of CAM. The ipv4-ipv6-2 profile sets that to zero. So, I switched to multi-service-4 as a workaround since it still had enough room. Fast forward two years and IPv6 adoption has increased to the point where an MLXe with –X cards is just about out of CAM if it’s acting as an internet router and using the multi-service-4 profile. Starting to see these alerts: Aug 31 11:51:10:A:CAM IPv6 partition warning: total 32768 (reserved 0), free 1602, slot 3, ppcr 1 because internet routers are seeing roughly 31,000 IPv6 advertisements now and multi-service-4 only has room for 32k. At the time, there was no way to configure custom CAM values, such as my desired goal of 768k minus 1 ipv4, 64k ipv6, 1 IPv4 VPN to facilitate one VRF. I didn’t want to use ipv4-ipv6-2 either since I like having the VRF. Is there any workaround for this issue in later code releases? Thanks, David _______________________________________________ foundry-nsp mailing list [email protected]<mailto:[email protected]> http://puck.nether.net/mailman/listinfo/foundry-nsp -- Youssef BENGELLOUN-ZAHR
_______________________________________________ foundry-nsp mailing list [email protected] http://puck.nether.net/mailman/listinfo/foundry-nsp
-- Dan White BTC Broadband Network Admin Lead Ph 918.366.0248 (direct) main: (918)366-8000 Fax 918.366.6610 email: [email protected] http://www.btcbroadband.com _______________________________________________ foundry-nsp mailing list [email protected] http://puck.nether.net/mailman/listinfo/foundry-nsp
