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

Hi!

Installing the default route is a valid option, if you do no need the as 
path information in the BGP table, in SFLOW packets and attached tools. 
In my eyes that is a big trade-off.

So I think for me one of these options will come first:

a) Hence of ROHS 2016 there is an end of sale for several X-boards in 
Europe and the smallest version that you can buy is now a 10-port 
licensed GX20-X2. Depending on the growth or the replacement attitude, 
the X2 will come sooner or later and can replace one or two X-cards at 
once. If you sell BGP full feeds to customers, you will need the X2 
sooner or later.

b) I will block certain ranges and as-numbers by regions and will also 
install a default route and extend our tools to resolve the as-path 
later. Not pretty but it can bridge the time and extend life of current 
boards.

Conclusion: If there is memory to fill, people will (ab)use it. The 
whole disaggregation of IPv6,  this is just the beginning.

Jörg

On 12 Sep 2016, at 17:10, Dan White wrote:

> 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

_______________________________________________
foundry-nsp mailing list
[email protected]
http://puck.nether.net/mailman/listinfo/foundry-nsp