[f-nsp] Does VRF still take CAM resources from 'ipv4 vpn' in later MLXe code?

[Dan White]

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 <youssef at 720.fr>
>Date: Monday, September 12, 2016 at 10:27 AM
>To: David Hubbard <dhubbard at dino.hostasaurus.com>
>Cc: "foundry-nsp at puck.nether.net" <foundry-nsp at puck.nether.net>
>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 <youssef at 720.fr<mailto:youssef at 720.fr>>:
>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 <dhubbard at dino.hostasaurus.com<mailto:dhubbard at dino.hostasaurus.com>> a écrit :
>Ah, good catch, I forgot about the RFE.  It’s 102535.  I’ll attempt to find its status.
>
>From: Youssef Bengelloun-Zahr <youssef at 720.fr<mailto:youssef at 720.fr>>
>Date: Wednesday, August 31, 2016 at 12:36 PM
>To: David Hubbard <dhubbard at dino.hostasaurus.com<mailto:dhubbard at dino.hostasaurus.com>>
>Cc: "foundry-nsp at puck.nether.net<mailto:foundry-nsp at puck.nether.net>" <foundry-nsp at puck.nether.net<mailto:foundry-nsp at puck.nether.net>>
>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 <dhubbard at dino.hostasaurus.com<mailto:dhubbard at dino.hostasaurus.com>> 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
>foundry-nsp at puck.nether.net<mailto:foundry-nsp at puck.nether.net>
>http://puck.nether.net/mailman/listinfo/foundry-nsp
>
>
>
>--
>Youssef BENGELLOUN-ZAHR

>_______________________________________________
>foundry-nsp mailing list
>foundry-nsp at puck.nether.net
>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: dwhite at olp.net
http://www.btcbroadband.com