Mailing List Archive

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@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@puck.nether.net
> http://puck.nether.net/mailman/listinfo/foundry-nsp

Ah, good catch, I forgot about the RFE. It’s 102535. I’ll attempt to find its status.

From: Youssef Bengelloun-Zahr <youssef@720.fr>
Date: Wednesday, August 31, 2016 at 12:36 PM
To: David Hubbard <dhubbard@dino.hostasaurus.com>
Cc: "foundry-nsp@puck.nether.net" <foundry-nsp@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@dino.hostasaurus.com<mailto:dhubbard@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@puck.nether.net<mailto:foundry-nsp@puck.nether.net>
http://puck.nether.net/mailman/listinfo/foundry-nsp

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@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@720.fr>
> Date: Wednesday, August 31, 2016 at 12:36 PM
> To: David Hubbard <dhubbard@dino.hostasaurus.com>
> Cc: "foundry-nsp@puck.nether.net" <foundry-nsp@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@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@puck.nether.net
> http://puck.nether.net/mailman/listinfo/foundry-nsp

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@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@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@720.fr>
> *Date: *Wednesday, August 31, 2016 at 12:36 PM
> *To: *David Hubbard <dhubbard@dino.hostasaurus.com>
> *Cc: *"foundry-nsp@puck.nether.net" <foundry-nsp@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@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@puck.nether.net
> http://puck.nether.net/mailman/listinfo/foundry-nsp
>
>


--
Youssef BENGELLOUN-ZAHR

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@720.fr>
Date: Monday, September 12, 2016 at 10:27 AM
To: David Hubbard <dhubbard@dino.hostasaurus.com>
Cc: "foundry-nsp@puck.nether.net" <foundry-nsp@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@720.fr<mailto:youssef@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@dino.hostasaurus.com<mailto:dhubbard@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@720.fr<mailto:youssef@720.fr>>
Date: Wednesday, August 31, 2016 at 12:36 PM
To: David Hubbard <dhubbard@dino.hostasaurus.com<mailto:dhubbard@dino.hostasaurus.com>>
Cc: "foundry-nsp@puck.nether.net<mailto:foundry-nsp@puck.nether.net>" <foundry-nsp@puck.nether.net<mailto:foundry-nsp@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@dino.hostasaurus.com<mailto:dhubbard@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@puck.nether.net<mailto:foundry-nsp@puck.nether.net>
http://puck.nether.net/mailman/listinfo/foundry-nsp



--
Youssef BENGELLOUN-ZAHR

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@720.fr>
>Date: Monday, September 12, 2016 at 10:27 AM
>To: David Hubbard <dhubbard@dino.hostasaurus.com>
>Cc: "foundry-nsp@puck.nether.net" <foundry-nsp@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@720.fr<mailto:youssef@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@dino.hostasaurus.com<mailto:dhubbard@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@720.fr<mailto:youssef@720.fr>>
>Date: Wednesday, August 31, 2016 at 12:36 PM
>To: David Hubbard <dhubbard@dino.hostasaurus.com<mailto:dhubbard@dino.hostasaurus.com>>
>Cc: "foundry-nsp@puck.nether.net<mailto:foundry-nsp@puck.nether.net>" <foundry-nsp@puck.nether.net<mailto:foundry-nsp@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@dino.hostasaurus.com<mailto:dhubbard@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@puck.nether.net<mailto:foundry-nsp@puck.nether.net>
>http://puck.nether.net/mailman/listinfo/foundry-nsp
>
>
>
>--
>Youssef BENGELLOUN-ZAHR

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

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 <youssef@720.fr>
>> Date: Monday, September 12, 2016 at 10:27 AM
>> To: David Hubbard <dhubbard@dino.hostasaurus.com>
>> Cc: "foundry-nsp@puck.nether.net" <foundry-nsp@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@720.fr<mailto:youssef@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@dino.hostasaurus.com<mailto:dhubbard@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@720.fr<mailto:youssef@720.fr>>
>> Date: Wednesday, August 31, 2016 at 12:36 PM
>> To: David Hubbard
>> <dhubbard@dino.hostasaurus.com<mailto:dhubbard@dino.hostasaurus.com>>
>> Cc: "foundry-nsp@puck.nether.net<mailto:foundry-nsp@puck.nether.net>"
>> <foundry-nsp@puck.nether.net<mailto:foundry-nsp@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@dino.hostasaurus.com<mailto:dhubbard@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@puck.nether.net<mailto:foundry-nsp@puck.nether.net>
>> http://puck.nether.net/mailman/listinfo/foundry-nsp
>>
>>
>>
>> --
>> Youssef BENGELLOUN-ZAHR
>
>> _______________________________________________
>> foundry-nsp mailing list
>> foundry-nsp@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@olp.net
> http://www.btcbroadband.com
> _______________________________________________
> foundry-nsp mailing list
> foundry-nsp@puck.nether.net
> http://puck.nether.net/mailman/listinfo/foundry-nsp

_______________________________________________
foundry-nsp mailing list
foundry-nsp@puck.nether.net
http://puck.nether.net/mailman/listinfo/foundry-nsp

Hi,

so to answer my own posting and statement b): I have pushed

https://github.com/ipcjk/asnbuilder

to git, which is basically building Brocade MLX-compatible regular
expressions out of the official as numbers and therefore can be used to
clean up your router from NIC-regions that you might want reach via a
default route.

E.g.
./main -region "AFRINIC" | head -n 10
ip as-path access-list region-summary permit
_3276[8-9][0-9]|_327[7-9][0-9][0-9]|_328[0-6][0-9][0-9]|_32870[0-3]$
ip as-path access-list region-summary permit _122[8-9]|_123[0-2]$
ip as-path access-list region-summary permit _2018$
ip as-path access-list region-summary permit _2561$
ip as-path access-list region-summary permit _2905$
ip as-path access-list region-summary permit _306[7-8]$
ip as-path access-list region-summary permit _3208$

./main -help
Usage of ./main:
-acltitle string
Title for generated as-path list (default "region-summary")
-permitOrDeny int
Deny = 0, Permit = 1 (default 1)
-region string
Comma separated list with region for generated prefix
-summary
Print summary of downloaded lists only

./main -summary
2016/09/15 12:53:02 APNIC [119 table entries]
2016/09/15 12:53:02 RIPE NCC [248 table entries]
2016/09/15 12:53:02 LACNIC [683 table entries]
2016/09/15 12:53:02 AFRINIC [201 table entries]
2016/09/15 12:53:02 ARIN [1046 table entries]

Next I need a tool to clean up redundant more specific prefixes.

Jörg


On 13 Sep 2016, at 8:38, Jörg Kost wrote:

> 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

_______________________________________________
foundry-nsp mailing list
foundry-nsp@puck.nether.net
http://puck.nether.net/mailman/listinfo/foundry-nsp