RE: CGNAT scaling cost (was Re: V6 still not supported)

@nanog.org] On Behalf Of Masataka Ohta Sent: Thursday, March 31, 2022 3:56 AM To: nanog@nanog.org Subject: Re: CGNAT scaling cost (was Re: V6 still not supported) Vasilenko Eduard via NANOG wrote: > CGNAT cost was very close to 3x compared to routers of the same > performance. That

Re: CGNAT scaling cost (was Re: V6 still not supported)

Vasilenko Eduard via NANOG wrote: CGNAT cost was very close to 3x compared to routers of the same performance. That should be because you are comparing cost of carrier, that is telco, grade NAT and consumer grade routers. Remember the cost of carrier grade datalink of SONET/SDH

RE: RE: CGNAT scaling cost (was V6 still not supported)

Hi Jared, I did mean big systems where performance needed is n*100Gbps or bigger. For router or CGNAT: the chassis cost is less than 1 card. Hence, all cost is in ports (for the big router up to 95% if counting QSFP too). Chassis, power supplies, switching fabrics - could be discarded for a big

Re: RE: CGNAT scaling cost (was V6 still not supported)

Hi Eduard, Do I interpret your findings correctly, if this means that CGNAT costs scale more or less linearly with traffic growth over time? And as a corollary, that the cost of scaling CGNAT in itself isn't likely a primary driver for IPv6 adoption? - Jared Vasilenko Eduard wrote

RE: CGNAT scaling cost (was Re: V6 still not supported)

CGNAT cost was very close to 3x compared to routers of the same performance. Hence, 1 hop through CGNAT = 3 hops through routers. 3 router hops maybe the 50% of overall hops in the particular Carrier (or even less). DWDM is 3x more expensive per hop. Fiber is much more expensive (greatly varies

CGNAT scaling cost (was Re: V6 still not supported)

An oft-cited driver of IPv6 adoption is the cost of scaling CGNAT or equivalent infrastructure for IPv4. Those of you facing costs for scaling CGNAT, are your per unit costs rising or declining faster or slower than your IPv4 traffic growth? I ask because I realize I am not fit to evaluate

RE: Quantifying the customer support and impact of cgnat for residential ipv4

>We have 10,000+ customers and by default everyone is behind CGNAT. Around 25 >customers have asked for a dedicated public IP >address and we usually just give them one free of charge. For our case, very >low percentage actually request one. > Travis Out of curiosity

RE: Quantifying the customer support and impact of cgnat for residential ipv4

I have >50,000 subscribers behind CGNat. I would have to find out from the assigners group, the rate at which static/public IP address sales increased during our CGNat deployment over the last few years. I do understand that we had an up-tick in public IP sales, but unsure of the r

RE: Quantifying the customer support and impact of cgnat for residential ipv4

We have 10,000+ customers and by default everyone is behind CGNAT. Around 25 customers have asked for a dedicated public IP address and we usually just give them one free of charge. For our case, very low percentage actually request one. Travis From: NANOG On Behalf Of Eric Kuhnke Sent

Quantifying the customer support and impact of cgnat for residential ipv4

Looking for anecdotal examples of the following: If you put N number of individual DHCP client residential broadband customers behind cgnat for ipv4, what percent of customers contact support and become a support/troubleshooting case later. And what percent of customers have a significant

RE: NAT/CGNAT IP address/users ratios

I currently have about ~2750 public IP's (11 /24's) for ~53,000 broadband customers. (ftth, cable modem and dsl) I cap them at 3,000 ports using PBA, port block allocation.. Blocks of 100 at a time, and 30 blocks per subscriber. (100*30=3000) I usually see, when a private internal IP is

NAT/CGNAT IP address/users ratios

Hello NANOG (and friends), Asking if anyone would care to share their CGNAT and NAT ratios. We're looking at some best practices and I wanted to see what the community at large has seen working, and not working. I am by no means a NAT expert, and usually I see the other end where it's clearly

Re: DualStack (CGNAT) vs Other Transition methods

Em ter., 6 de abr. de 2021 às 04:32, JORDI PALET MARTINEZ via NANOG < nanog@nanog.org> escreveu: > > > I don’t understand what you mean with the support folks, they just do what their boss decides, like in any other technology deployment. Well, Jordi... Do You know what is the important Body

Re: DualStack (CGNAT) vs Other Transition methods

and don't map it to the "fake" > v6 address > - Some APPs do (by some crazy reason) the re-write of Session Layer header > to v6 address, and Sip-Proxys ignores it... > > After hours and hours fighting against the lions, we decided: > "Let's keep those clients in Dual

Re: DualStack (CGNAT) vs Other Transition methods

I wish I could do it already! As soon as the client starts the massive deployment, it should be announced. Covid delayed it at least for 1 year up to now … Regards, Jordi @jordipalet El 6/4/21 7:07, "NANOG en nombre de Mark Tinka" escribió: On 4/5/21 22:00, JORDI PALET

Re: DualStack (CGNAT) vs Other Transition methods

On 4/5/21 21:30, Douglas Fischer wrote: Here goes a link fo an excellent analysis of IPv6 and Playstation This says a lot about why some prefer DualStack. https://toreanderson.github.io/2021/02/23/ipv6-support-in-the-playstation-5.html

Re: DualStack (CGNAT) vs Other Transition methods

On 4/5/21 22:00, JORDI PALET MARTINEZ via NANOG wrote:  Further to that, I’ve done a very complete testing, for a customer, with a PS4 in a LAN with 464XLAT and everything worked fine. Unfortunately, as this was contracted by a customer, I can’t disclose all the test set, but believe me

Re: DualStack (CGNAT) vs Other Transition methods

red as you may have native IPv6 clients rather >> than clients behind a CLAT on the customer side. >> >> > On 25 Feb 2021, at 01:48, Douglas Fischer >> wrote: >> > >> > >> > >> > Is this pain you have lived or verified with first h

Re: DualStack (CGNAT) vs Other Transition methods

ternet, with deep analysis at > all the parts involved. > > The most common issue is incoming Calls to SIP endpoints behind 464Xlat > using IPv4 with unidirectional audio. > > And several types of causes: > > - CPEs receives the RTP-Stream but doesn't Re-Map it correctly t

Re: DualStack (CGNAT) vs Other Transition methods

ool receives the RTP-Stream but ignores it and don't map it to the "fake" > v6 address > - Some APPs do (by some crazy reason) the re-write of Session Layer header > to v6 address, and Sip-Proxys ignores it... > > After hours and hours fighting against the lions, we d

Re: DualStack (CGNAT) vs Other Transition methods

rrectly to the >> IPv4 inside end-point >> > - Jool receives the RTP-Stream but ignores it and don't map it to the >> "fake" v6 address >> > - Some APPs do (by some crazy reason) the re-write of Session Layer >> header to v6 address, and Sip-Proxys

RE: CGNAT

in with multiple MX960's w/MS-MPC-128Gnow over 50,000 customers of dsl, cable modem and ftth ...all that behind about ~/21 I'll add that we already had the 960's for the 100gig mpls sp core we had built, so it was an investment only on the service module to do cgnat. -Aaron

RE: CGNAT

While I won't go into the costs as well, I've got actual work to do I must say my calculations of purchase ipv4 (@25USD/IP) vs CGNAT have always fallen significantly into the CGNAT camp. If you are doing a stand alone A10 or similar yes things would be different. If you are already buying

Re: CGNAT

If you buy more IPv4 space you will neither have to deal with CGNAT nor worry about traffic growth. Both of those benefits are easily worth the (short term) premium. In the long term, buying more IPv4 blocks now is likely to be cheaper than running CGNAT for the foreseeable futur

Re: DualStack (CGNAT) vs Other Transition methods

er > header to v6 address, and Sip-Proxys ignores it... > > > > After hours and hours fighting against the lions, we decided: > > "Let's keep those clients in Dual-Stak and CGNAT" and it just worked. > > > > And after that, the obvious conclusions: > &

Re: CGNAT

Kevin, One of the presented options isn't like the others. As such the comparison isn't really fair, especially if you expect to run your business longer than 7 years. If you buy more IPv4 space you will neither have to deal with CGNAT nor worry about traffic growth. Both of those benefits

Re: DualStack (CGNAT) vs Other Transition methods

re-write of Session Layer header > to v6 address, and Sip-Proxys ignores it... > > After hours and hours fighting against the lions, we decided: > "Let's keep those clients in Dual-Stak and CGNAT" and it just worked. > > And after that, the obvious conclusions: > - Why

Re: DualStack (CGNAT) vs Other Transition methods

uot; v6 address - Some APPs do (by some crazy reason) the re-write of Session Layer header to v6 address, and Sip-Proxys ignores it... After hours and hours fighting against the lions, we decided: "Let's keep those clients in Dual-Stak and CGNAT" and it just worked. And after that, the

Re: DualStack (CGNAT) vs Other Transition methods

), makes things work without issues! Regards, Jordi @jordipalet El 24/2/21 14:28, "Douglas Fischer" escribió: P.S.: Forking thread from CGNAT. Hello Jordi! Since our last heated talk about transitions methods(Rosario, 2018?), I must recognize that the intoleranc

Re: DualStack (CGNAT) vs Other Transition methods

On Wed, Feb 24, 2021 at 5:29 AM Douglas Fischer wrote: > P.S.: Forking thread from CGNAT. > > Hello Jordi! > > Since our last heated talk about transitions methods(Rosario, 2018?), I > must recognize that the intolerance to other scenarios other than > dual-stack had r

DualStack (CGNAT) vs Other Transition methods

P.S.: Forking thread from CGNAT. Hello Jordi! Since our last heated talk about transitions methods(Rosario, 2018?), I must recognize that the intolerance to other scenarios other than dual-stack had reduced(mostly because of improvements on the applications in generral). I'm even considering

Re: CGNAT

/AFRINIC While that’s true, even at current prices, IPv4 addresses are cheaper to buy and/or lease than CGN. > IPv6 migration is not generally aided by CGNAT, but CGNAT deployment is generally aided by IPv6 deployment; to reiterate the earlier point, any ISPs deploying CGNAT with

Re: CGNAT

this presentation was still in "primary > market" era for LACNIC/ARIN/AFRINIC While that’s true, even at current prices, IPv4 addresses are cheaper to buy and/or lease than CGN. > IPv6 migration is not generally aided by CGNAT, but CGNAT deployment is > generally aided by IPv6 deploy

Re: CGNAT

IPv4AAS will also work easily for any ISP on the planet. CGNAT requires IPv4 address space between the CGNAT and the customer CPE which doesn’t overlap with that on the Internet nor that behind the CPE (no you can’t use RFC 1918). 100.64/10 gives you ~4M addresses which fit this criteria

Re: CGNAT

, 9:04 am > To: Steve Saner > Cc: nanog@nanog.org > Subject: Re: CGNAT > > Why not go whole hog and provide IPv4 as a service? That way you are not > waiting for your customers to turn up IPv6 to take the load off your NAT box. > > Yes, you can do it dual stack but yo

Re: CGNAT

Hi Steve We are looking at implementing a similar solution with A10 for CGNAT. We've been in touch with A10. Just wondering if there are some alternative vendors that anyone would recommend. We'd probably be looking at a solution to support 5k to 15k customers and bandwidth up to around 30-40

RE: CGNAT

speaking, this presentation was still in "primary market" era for LACNIC/ARIN/AFRINIC IPv6 migration is not generally aided by CGNAT, but CGNAT deployment is generally aided by IPv6 deployment; to reiterate the earlier point, any ISPs deploying CGNAT without first deploying IPv6 are bu

Re: CGNAT

> On Feb 18, 2021, at 8:38 AM, Steve Saner wrote: > > We are starting to look at CGNAT solutions. The primary motivation at the > moment is to extend current IPv4 resources, but IPv6 migration is also a > factor. IPv6 Migration is generally not aided by CGNAT. In general

Re: CGNAT

SPs are running 464XLAT with great success. We're in a situation where making IPv6 a *prerequisite* of your IPv4 connectivity can realistically improve your margins when some sort of CGNAT gateway is a requirement. Yes it requires looking at your CPE support, but if you're doing even 00,000's of subs,

Re: CGNAT

0 February 2021, 9:04 am > To: Steve Saner > Cc: nanog@nanog.org > Subject: Re: CGNAT > > Why not go whole hog and provide IPv4 as a service? That way you are not > waiting for your customers to turn up IPv6 to take the load off your NAT box. > > Yes, you can do it dual s

Re: CGNAT

IPv4 as a Service such as 464XLAT, will allow them to use less IPv4 public addresses than CGNAT, less costly equipment (or open source) and still provide dual-stack inside the customers networks. There is nothing from Internet that will not work. I’ve many deployments based

Re: CGNAT

IPv6 to take the load off your NAT box.Yes, you can do it dual stack but you have waited so long you may as well miss that step along the deployment path.-- Mark AndrewsOn 20 Feb 2021, at 01:55, Steve Saner wrote:We are starting to look at CGNAT solutions. The primary motivation at the moment

Re: CGNAT

20 Feb 2021, at 01:55, Steve Saner wrote: > >  > We are starting to look at CGNAT solutions. The primary motivation at the > moment is to extend current IPv4 resources, but IPv6 migration is also a > factor. > > We've been in touch with A10. Just wondering if there are som

RE: CGNAT

running dual stack IPv6 as you can bypass 40%+ traffic from the CGN process for all that CDN traffic. From: NANOG On Behalf Of Steve Saner Sent: Friday, 19 February 2021 5:39 am To: nanog@nanog.org Subject: CGNAT We are starting to look at CGNAT solutions. The primary motivation

Re: CGNAT

I recommend you to take a look at DANOS. https://danosproject.atlassian.net/wiki/spaces/DAN/pages/416153601/Carrier+Grade+NAT+CGNAT - A very active open-source project. - Sponsored by AT - Uses Vyatta (and DPDK for good performance) - The Routing Engine is based on FRR. - Syntax sounds like

CGNAT

We are starting to look at CGNAT solutions. The primary motivation at the moment is to extend current IPv4 resources, but IPv6 migration is also a factor. We've been in touch with A10. Just wondering if there are some alternative vendors that anyone would recommend. We'd probably be looking

Re: CGNAT Opensource with support to BPA, EIM/EIF, UPnP-PCP

On 7/Jul/20 19:23, JORDI PALET MARTINEZ via NANOG wrote: >   > > There was, long time ago, something developed by ISC, but I think > never completed and not updated … > >   > > 464XLAT is always a solution and becomes much cheaper, than CGN from > vendors, even if you need to replace the CPEs.

Re: CGNAT Opensource with support to BPA, EIM/EIF, UPnP-PCP

ordipalet > > > > > > El 7/7/20 18:44, "NANOG en nombre de Douglas Fischer" > fischerdoug...@gmail.com> escribió: > > We are looking for a CGNAT solution open source based. > > Yep, I know that basic CGNAT can be done with iptables / nftables,

RE: CGNAT Opensource with support to BPA, EIM/EIF, UPnP-PCP

As someone who has spent quite a long time building CGNAT solutions I have some good news for you, there is an easy solution to your below point that works exceptionally well. The solution is dual stack IPv6, its trivial to route your IPv6 to bypass the CGNAT device you are using and pretty

Re: CGNAT Opensource with support to BPA, EIM/EIF, UPnP-PCP

route-maps, prefix-lists, access-lists with BGP are broken. On Tue, Jul 7, 2020 at 9:44 AM Douglas Fischer wrote: > We are looking for a CGNAT solution open source based. > > Yep, I know that basic CGNAT can be done with iptables / nftables, or PF / > IPFILTER / IPFW. > > Bu

Re: CGNAT Opensource with support to BPA, EIM/EIF, UPnP-PCP

down by the Covid-19). Regards, Jordi @jordipalet El 7/7/20 18:44, "NANOG en nombre de Douglas Fischer" escribió: We are looking for a CGNAT solution open source based. Yep, I know that basic CGNAT can be done with iptables / nftables, or PF / IPFILTER / IPFW. But I

CGNAT Opensource with support to BPA, EIM/EIF, UPnP-PCP

We are looking for a CGNAT solution open source based. Yep, I know that basic CGNAT can be done with iptables / nftables, or PF / IPFILTER / IPFW. But I only know Open Source CGNAT recipes with predefined public-ports <-> private IPs mapping. What It brings two types of issues: A - Th

Re: CGNAT Solutions

Ca By wrote: The proper number to be considered should be percentage of IPv6 hosts which can not communicate with IPv4 only hosts. Isn't it 0%? I think you agree with me, here. For those of us running networks, especially growing networks, uniquely numbering hosts is our goal and ipv6 fits

Re: CGNAT Solutions

And more and more CPE providers support it. See RFC8585. I inititally started using OpenWRT, but now I already got samples from several vendors. Regards, Jordi @jordipalet El 30/4/20 6:16, "NANOG en nombre de Ca By" escribió: On Wed, Apr 29, 2020 at 7:17 PM

Re: CGNAT Solutions

On Wed, Apr 29, 2020 at 7:17 PM Brandon Martin wrote: > On 4/29/20 10:12 PM, William Herrin wrote: > >> What allows them to work with v6 in such an efficient manner? > > A piece of client software is installed on every phone that presents > > an IPv4 address to the phone and then translates

Re: CGNAT Solutions

On Wed, Apr 29, 2020 at 7:46 PM Masataka Ohta < mo...@necom830.hpcl.titech.ac.jp> wrote: > Ca By wrote: > > >>>You can't eliminate that unless the CPE also knows what internal > port > >>> range it's mapped to so that it restricts what range it uses. If you > >>> can do that, you can get rid

Re: CGNAT Solutions

Ca By wrote: You can't eliminate that unless the CPE also knows what internal port range it's mapped to so that it restricts what range it uses. If you can do that, you can get rid of the programmatic state tracking entirely and just use static translations for TCP and UDP which, while

Re: CGNAT Solutions

On 4/29/20 10:12 PM, William Herrin wrote: What allows them to work with v6 in such an efficient manner? A piece of client software is installed on every phone that presents an IPv4 address to the phone and then translates packets to IPv6 for relay over the network. This works because T-Mobile

Re: CGNAT Solutions

On Wed, Apr 29, 2020 at 5:27 PM Thomas Scott wrote: > > cell-phone environment. A classic small ISP fills a different niche. > > I've dealt with traditional cable and fiber SP environments, but I'm curious > how the architecture differs so drastically with T-Mobile to allow v6 to work > so

Re: CGNAT Solutions

On Wed, Apr 29, 2020 at 7:19 AM Ca By wrote: > Since we are talking numbers ans hard facts > > 42% of usa accesses google on ipv6 > > https://www.google.com/intl/en/ipv6/statistics.html Be careful with those stats; they might not be telling you what you think they are. For example, phone clients

RE: CGNAT Solutions

ron -Original Message- From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Robert Blayzor Sent: Wednesday, April 29, 2020 9:14 AM To: nanog@nanog.org Subject: Re: CGNAT Solutions On 4/28/20 11:01 PM, Brandon Martin wrote: > Depending on how many IPs you need to reclaim and what your

Re: CGNAT Solutions

On Wed, 29 Apr 2020, Robert Blayzor wrote: So as a happy medium of about 2048 ports per subscriber, that's roughly a 32:1 NAT/IP over-subscription ? Yes, around that. -- Mikael Abrahamssonemail: swm...@swm.pp.se

Re: CGNAT Solutions

e to work > from home. I am starting to run low on IP's and need to consider CGNAT. > > I do have IPV6 space, but we all know that until we force everyone to move > to IPV6, we need to keep IPV4 up and running. > > I could buy more space, but I am really wondering i

Re: CGNAT Solutions

On 4/29/20 10:29 AM, Mikael Abrahamsson wrote: > There are some numbers in there for instance talking about 1024 ports > per subscriber as a good number. In presentations I have seen over time, > people typically talk about 512-4096 as being a good number for the bulk > port allocation size. So

Re: CGNAT Solutions

I haven't used them, but 6-WIND is pretty proud of their CGNAT performance. - Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com - Original Message - From: "John Alcock" To: nanog@nanog.org Sent: Tuesday

Re: CGNAT Solutions

On Wed, 29 Apr 2020, Robert Blayzor wrote: One would think a 1000 ports would be enough, but if you have a dozen devices at home all browsing and doing various things, and with IOT, etc, maybe not? https://www.juniper.net/documentation/en_US/junos/topics/concept/nat-best-practices.html

Re: CGNAT Solutions

How big is your ip pool for CGNAT? On Wed, Apr 29, 2020 at 10:17 AM Robert Blayzor wrote: > On 4/28/20 11:01 PM, Brandon Martin wrote: > > Depending on how many IPs you need to reclaim and what your target > > IP:subscriber ratio is, you may be able to eliminate the

Re: CGNAT Solutions

numbers for different destination IP or even destination port. We are seeing very good results with 256 ports per subscriber in the mobile scenario where consumer is mobile handset. So not directly translatable to broadband setup but still good datapoint. If you must go CGNAT today it's only

Re: CGNAT Solutions

On Wed, Apr 29, 2020 at 1:06 AM Masataka Ohta < mo...@necom830.hpcl.titech.ac.jp> wrote: > Brandon Martin wrote: > > >> If you mean getting rid of logging, not necessarily. It is enough if > >> CPEs are statically allocated ranges of external port numbers. > > > > Yes, you can get rid of the

Re: CGNAT Solutions

On 4/28/20 11:01 PM, Brandon Martin wrote: > Depending on how many IPs you need to reclaim and what your target > IP:subscriber ratio is, you may be able to eliminate the need for a lot > of logging by assigning a range of TCP/UDP ports to a single inside IP > so that the TCP/UDP port number

Re: CGNAT Solutions

Brandon Martin wrote: If you mean getting rid of logging, not necessarily. It is enough if CPEs are statically allocated ranges of external port numbers. Yes, you can get rid of the logging by statically allocating ranges of port numbers to a particular customer. And, that was the original

Re: CGNAT Solutions

On 4/29/20 2:35 AM, Masataka Ohta wrote: If you mean getting rid of logging, not necessarily. It is enough if CPEs are statically allocated ranges of external port numbers. Yes, you can get rid of the logging by statically allocating ranges of port numbers to a particular customer. What I

Re: CGNAT Solutions

Brandon Martin wrote: You can't get rid of all the state tracking without also having the CPE know which ports to use If you mean getting rid of logging, not necessarily. It is enough if CPEs are statically allocated ranges of external port numbers.

Re: CGNAT Solutions

On 4/28/20 4:53 PM, William Herrin wrote: How small is small? Up to a certain size regular NAT with enough logging to trace back abusers will tend to work fine. if we're talking single-digit gbps, it may not be worth the effort to consider the wonderful world of CGNAT. Depending on how many

Re: CGNAT Solutions

@jordipalet > > > > > > > > El 28/4/20 21:15, "NANOG en nombre de John Alcock" < > nanog-boun...@nanog.org en nombre de j...@alcock.org> escribió: > > > > Afternoon, > > > > I run a small ISP in Tennessee. COVID has forced a lo

Re: CGNAT Solutions

, "NANOG en nombre de John Alcock" escribió: Afternoon, I run a small ISP in Tennessee. COVID has forced a lot of people to work from home. I am starting to run low on IP's and need to consider CGNAT. I do have IPV6 space, but we all know that until we force everyone to mov

Re: CGNAT Solutions

On Tue, Apr 28, 2020 at 12:12 PM John Alcock wrote: > I run a small ISP in Tennessee. I am starting to run low on IP's and need to > consider CGNAT. Hi John, How small is small? Up to a certain size regular NAT with enough logging to trace back abusers will tend to work fine. if we're t

RE: CGNAT Solutions

originally envisioned. (but bought more as well) I slow started my CGNat deployment, like with most things, baby-steps when doing something as extreme as taking away the public ip address from my isp residential customers… so yeah, slow-start… DSL was my first target. One DSLAM at a time

Re: CGNAT Solutions

Just go with Linux and iptables. It is by far the cheapest option and it just works. tir. 28. apr. 2020 21.13 skrev John Alcock : > Afternoon, > > I run a small ISP in Tennessee. COVID has forced a lot of people to work > from home. I am starting to run low on IP's and need to co

CGNAT Solutions

Afternoon, I run a small ISP in Tennessee. COVID has forced a lot of people to work from home. I am starting to run low on IP's and need to consider CGNAT. I do have IPV6 space, but we all know that until we force everyone to move to IPV6, we need to keep IPV4 up and running. I could buy more

cgnat ams0 vrf-aware flow data export help

Need assistance with exporting flow data for inside interface of cgnat ams0 aggregated multiservice interface I have MX960 with MS-MPC-128G doing cgnat using AMS0 (aggregated multiservice of underlying mams interfaces) using next-hop-style vrf-aware cgnat. I need the cgnat inside domain

Re: CGNAT

if the NAT device doesn't adequately prune fragmented packets from the memory when there is a flood of these type of packets. On 2/7/19, 11:47 AM, "Aaron Gould" wrote: Rich, et al, Circling back on some older threads... I'm doing this because I've been growing my cgnat en

RE: CGNAT

Rich, et al, Circling back on some older threads... I'm doing this because I've been growing my cgnat environments and needing to remind myself of somethings, etc... If an attack is targeted at 1 ip address, you would think that if would/could affect all the napt-44 (nat overloaded/pat'd) ip's

Re: OpenDNS CGNAT Issues

On Wed, 12 Sep 2018 09:42:11 -0700, Owen DeLong said: > If you do it for a mere footlocker, I will be happy to watch and laugh. So.. taking this as a size: https://www.containerstore.com/s/storage/trunks/black-rolling-trunk-with-tray/12d?productId=1230 We'll shave off an inch or so off each

Re: OpenDNS CGNAT Issues

On 2018-09-12 19:40, Lee Howard wrote: On 09/11/2018 09:31 AM, Matt Hoppes wrote: So don't CGNat?  Buy IPv4 addresses at auction? Buy IPv4 addresses until CGN is cheaper. If a customer has to call, and you have to assign an IPv4 address, you have to recover the cost of that call and address

Re: OpenDNS CGNAT Issues

If you do it for a mere footlocker, I will be happy to watch and laugh. Owen > On Sep 12, 2018, at 9:11 AM, valdis.kletni...@vt.edu wrote: > > On Wed, 12 Sep 2018 14:10:05 -, Kenny Taylor said: > >> For a truckload of gold, I’m pretty sure most of us would make that work ☺ > > Unless

Re: OpenDNS CGNAT Issues

On 09/11/2018 09:31 AM, Matt Hoppes wrote: So don't CGNat?  Buy IPv4 addresses at auction? Buy IPv4 addresses until CGN is cheaper. If a customer has to call, and you have to assign an IPv4 address, you have to recover the cost of that call and address. While ((CostOfCall + CostOfAddress

Re: OpenDNS CGNAT Issues

On Wed, 12 Sep 2018 14:10:05 -, Kenny Taylor said: > For a truckload of gold, I’m pretty sure most of us would make that work ☺ Unless they get underbid by the one of us willing to settle for a foot locker full of gold. pgp6lNCVQkTiq.pgp Description: PGP signature

Re: OpenDNS CGNAT Issues

ounces+kenny.taylor=kccd@nanog.org>> On Behalf Of Owen > DeLong > Sent: Tuesday, September 11, 2018 10:04 PM > To: Christopher Morrow <mailto:morrowc.li...@gmail.com>> > Cc: nanog list mailto:nanog@nanog.org>> > Subject: Re: OpenDNS CGNAT Issues &g

RE: OpenDNS CGNAT Issues

For a truckload of gold, I’m pretty sure most of us would make that work ☺ Kenny From: NANOG On Behalf Of Owen DeLong Sent: Tuesday, September 11, 2018 10:04 PM To: Christopher Morrow Cc: nanog list Subject: Re: OpenDNS CGNAT Issues On Sep 11, 2018, at 21:58 , Christopher Morrow

Re: OpenDNS CGNAT Issues

On Tue, Sep 11, 2018 at 10:03 PM Owen DeLong wrote: > > > On Sep 11, 2018, at 21:58 , Christopher Morrow > wrote: > > > > On Tue, Sep 11, 2018 at 9:06 PM Jerry Cloe wrote: > >> OpenDNS, or anyone for that matter, should never see 100.64/10 ip's. If >> they do, something is wrong at the source,

Re: OpenDNS CGNAT Issues

> On Sep 11, 2018, at 21:58 , Christopher Morrow > wrote: > > > > On Tue, Sep 11, 2018 at 9:06 PM Jerry Cloe > wrote: > OpenDNS, or anyone for that matter, should never see 100.64/10 ip's. If they > do, something is wrong at the source, and OpenDNS wouldn't be

Re: OpenDNS CGNAT Issues

pendns peers directly with such an eyeball network? and in that case maybe they have an agreement to accept traffic from the 100.64 space? > > > -Original message- > *From:* Aled Morris via NANOG > *Sent:* Tue 09-11-2018 11:57 am > *Subject:* Re: OpenDNS CGNAT Issues >

RE: OpenDNS CGNAT Issues

am Subject:Re: OpenDNS CGNAT Issues To:cb.li...@gmail.com; CC:NANOG ;  Incidentally, I hope OpenDNS considers 100.64.0.0/10 <http://100.64.0.0/10> as space that can't be registered to any end-user.  Aled

Re: OpenDNS CGNAT Issues

> On 11 Sep 2018, at 11:07 pm, Aled Morris via NANOG wrote: > > On Tue, 11 Sep 2018 at 13:56, Ca By wrote: > You should provide your users ipv6, opendns supports ipv6 and likely will not > have this issue you see > > OpenDNS does not support IPv6 for their customisable services "Home"

Re: OpenDNS CGNAT Issues

an IP to every customer > but it's not ready yet. > > Thank you > >> On Tue, Sep 11, 2018 at 8:39 AM, Ca By wrote: >> >> >>> On Tue, Sep 11, 2018 at 6:31 AM Matt Hoppes >>> wrote: >>> So don't CGNat? Buy IPv4 addresses

Re: OpenDNS CGNAT Issues

On Tue, 11 Sep 2018 at 13:56, Ca By wrote: > You should provide your users ipv6, opendns supports ipv6 and likely will > not have this issue you see > OpenDNS does not support IPv6 for their customisable services "Home" etc. which I believe is the service the OP is using as he refers to the

Re: OpenDNS CGNAT Issues

y we get ipv4 issues. Not CGNAT ipv4 issues, we actually have not seen a single issue with CGNAT for our customer base, our techs ask a simple question at install, "what do you use the internet for?", "gaming", "Okay, dedicated public it is". And yet, with all those publics

Re: OpenDNS CGNAT Issues

tt Hoppes rivervalleyinternet.net> wrote: > >> So don't CGNat? Buy IPv4 addresses at auction? >> > > As long as you don’t deploy ipv6, you should be good. > > Seriously. Not sure why this is so hard. IPv4 does not scale. Your > customers, like my customers, probably m

Re: OpenDNS CGNAT Issues

On Tue, Sep 11, 2018 at 6:31 AM Matt Hoppes < mattli...@rivervalleyinternet.net> wrote: > So don't CGNat? Buy IPv4 addresses at auction? > As long as you don’t deploy ipv6, you should be good. Seriously. Not sure why this is so hard. IPv4 does not scale. Your customers, like

  1   2   >