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
