cancel
Showing results for 
Search instead for 
Did you mean: 

WE Need IPV6 Support in MX

SOLVED
Getting noticed

Re: WE Need IPV6 Support in MX

I agree that communication has been poor on this issue.

 

There have been statements that early decisions were made about the MX design that need to be rethought because of IPV6.  Besides the technical issues related directly to an IPV6 stack, there likely is the issue of a schema design change in the MX.  This would mean potential complex transition steps from old MX to IPV6 MX.  One would want to preserve any IPV4 settings on an existing production MX after such an upgrade for IPV6, and that schema change requires careful planning and execution on Meraki's part.

Kind of a big deal

Re: WE Need IPV6 Support in MX

  • 1996 - IPv6 specified (RFC 1883)
  • 2006 - Meraki founded

 

No excuse for any engineer at Meraki to be blind-sided by IPv6. 

 

Trying to explain away the reality that the engineers really screwed up just insults the audience being addressed.

 

Can we have some straight talk please from somebody at the C-level. Vague flummery or testiculation will only exacerbate an already bad situation.

 

Note for the philologists: testiculation - waving one's arms around whilst talking balls.

 

rs_T709-Testiculating[1].jpg

 

Robin St.Clair | Principal, Caithness Analytics | @uberseehandel
Getting noticed

Re: WE Need IPV6 Support in MX

A customer asked his internet provider to setup a cost-free, public IP address (as of EU-VO2015/2120 Art3 Abs1/2).

 

Answer: You'll get an IPv6 net for free, but an IPv4 address only for $$. That's already clarified with the Austrian regulatory authority (RTR).

 

Meraki: ACT!

 

The actual email follows (German):


Betreff:[XXX #NNN] Bitte um Öffentliche IP Adresse
Datum:Tue, 21 May 2019 09:16:44 +0200
Von:AAA BBB via RT <CCC@XXX.at>

Sehr geehrter DDD,

allen unseren Kunden wird ein öffentliches IPv6-Netz zugewiesen. Die
öffentliche IP-Adresse muss nicht IPv4 sein, so steht es in den BEREC
Leitlinien zur Netzneutralität und ist auch mit der RTR (Rundfunk und Telekom
Regulierung) so abgeklärt. Auf Grund der Knappheit von IPv4 Adressen könnten
viele - insbesondere noch nicht so lange am Markt befindliche - Anbieter sonst
keine Internetzugangsleistungen anbieten.

Wir weisen bei der Bestellung sowie in der Leistungsbeschreibung ausdrücklich
darauf hin, dass es sich bei den Privat-Produkten von CCC um IPv6 sowie im
IPv4 Bereich Carrier-NAT handelt und auf Wunsch eine statische öffentliche IPv4
Adresse um 2,40 Euro dazugebucht werden kann:
...Die Anbindung des Anschlusses an das Internet erfolgt über ein öffentliches
IPv6-Netz sowie über eine betreiberinterne IPv4-Adresse (Carrier-Grade-Nat –
CGN)....

Es gibt kostenfreie und kommerzielle Dienste, die einzelne Ports von IPv4 auf
IPv6 (IPv4 zu IPv6 Port Mapping) weiterleiten. Zwei Beispiele:
Freier Dienst: https://myonlineportal.net/portmapper
Kommerzieller Dienst:
http://www.feste-ip.net/dslite-ipv6-portmapper/allgemeine-informationen/

Alternativ bieten wir die statische öffentliche IPv4 Adresse um 2,40 Euromonatlich an.

Mit freundlichen Grüßen, EEE
Here to help

Re: WE Need IPV6 Support in MX

if only i had the luxury of being able to pay

EE in the UK said its simply not an option any more.

 

raising the spectre of what to do with a publicised feature (4g wan backup) not working the 4g providers all work with ipv6 only...

 

Getting noticed

Re: WE Need IPV6 Support in MX

this is a bug, not a missing feature. i think that's unclear to them.

Here to help

Re: WE Need IPV6 Support in MX

i think the line is that the feature of ipv6 wan has never been advertised, and so it is not possible for it to be filed as a bug.

 

however the lack of support results in another feature (4g failover) not working 

which maybe then is classed as a bug (grey area)?

Kind of a big deal

Re: WE Need IPV6 Support in MX


@danielpugh wrote:

if only i had the luxury of being able to pay

EE in the UK said its simply not an option any more.

 

raising the spectre of what to do with a publicised feature (4g wan backup) not working the 4g providers all work with ipv6 only...

 


Curiously, yesterday I activated an EE LTE/4G data SIM, which was assigned an IPv4 address on activation. Whether it will always be the same IP address, I do not know, but as it is for a travelling Z3C, the cellular sub-system will be enabled/disabled frequently, so I shall soon find out. I did not have to specify IPv4.

 

It occurs to me that the person who declined your request for an IPv4 address, did not understand the implications as far as you are concerned, and that such a request should be fulfilled if at all possible. Perhaps you could move up the food chain at EE and find somebody who can make things happen.

Robin St.Clair | Principal, Caithness Analytics | @uberseehandel
Highlighted
Here to help

Re: WE Need IPV6 Support in MX

tried and tried with support, but despite multiple support people they werent able to help, and refunded me.

i suspect its some level of automation that gives out ipv4 automatically based on the device (we have a cisco ISR with 4g card that got an ipv4 when installed last week), but it didnt work on ours...

 

as a second level - what i ideally want (but will probably never get) is;

4g router (decent mimo aerials and upgradeable) -> lan port -> meraki (mx64) wan2

 

tried that, but although a pc works fine via ipv6, obviously the meraki didnt

Building a reputation

Re: WE Need IPV6 Support in MX

This post is almost two years old and still nothing has happened? I‘m working for one of Europes‘ biggest Cisco partners and thinking about upcoming SD-WAN projects, this could be a showstopper for Meraki equipment 😞

New here

Re: WE Need IPV6 Support in MX

Agreed. It would be nice for an update and a roadmap as to Cisco's plan to deploy IPv6 to the Meraki line. We spend good money on our licenses. We don't deserve second rate support to mainline Cisco or lack of answers.
Conversationalist

Re: WE Need IPV6 Support in MX

Cisco's position and this thread is rediculous. Look at the time that has passed. The will be never ipv6 in Meraki. Otherwise it would been on the roadmap a long this ago and just completed.

 

As a partner, I need to replace my Merki now, because I can`t communicate properly with ipv6. What other vendor / product do you recommend?

 

If cisco would be working on it they would be able to show a prototype. They don`t.... So they havn´t started. How long to you want to wait for a feature that is to big for they to handle or they can`t because of the existing hardware that is not compatible? Switch....

Here to help

Re: WE Need IPV6 Support in MX

As I said in my first (or second) post: If you really need v6 WAN, then the MX isn't for you. Especially if you need it right-this-second, change your WAN device to something else that does support your needs.

All other vendors can easily and swiftly include support for it because while they may offer a "cloud" controller option (like Ubiquiti), you still have local access to all other functions of the device from the device itself (or, at least, provides a local controller option as well).

 

If your network has "stacked" or "cascaded routers" -- like let's say you have a "transit VLAN" in between your WAN and your internal networks, where your DHCP-PD requesting device isn't also then another DHCPv6 server capable of re-delegating delegated prefixes it received from its own upstream delegation, you'll have a difficult time getting your network online to get to the Meraki Dashboard to even set up the network to begin with. I think that's the problem. If Meraki allowed local device access to the same core functions (interface addressing, DHCP, group policies, ARP tables, routing, etc) from the dashboard on the local device itself, this wouldn't be as big of a fundamental mountain to overcome. Especially in a dual-stacked environment.

Since some RFC (I think 6724, which obseleted 3484, I also think) specifies how clients select source addressing with a dual-stacked system, you run the risk of clients in specific network configurations (like the one above) getting degraded performance while it tries to use v6 before falling back to v4.

 

And that's also ignoring dual/multi-homed WANs without BGP or PI/static PA from statically-assigned prefixes.  That's still a "work-in-progress", too.  Stay single-homed to a single ISP and remove the USB LTE connection, or cancel service on that SIM.  That way you only have a single source address to source v6 traffic from, and if the FW is the only L3 device in your network, SLAAC should work fine unless you're running a domain on your local network.  Or, if the device you switch to has the option of suppressing RAs of the 2nd WAN option as long as your primary WAN is still active, then RAs can fail over your WANs for you in the event of a WAN failure.  Depending on the settings, the failover might not even be noticable unless you're on an active VoIP call.

Maybe everyone clamoring for it here wouldn't have that issue; as long as your FW is the only L3 device in each of your networks, you'll be alright. In which case, as I said here and before: Meraki MX ain't for you. Switch.  That is probably going to be the fastest way to resolve your WAN connectivity issues.

Here to help

Re: WE Need IPV6 Support in MX

Can't say it's possible to go back in time and not buy our mx84.  

 

For both ubiquity and meraki Mx the device wan is configured locally in order for the device to connect to cloud and obtain configuration, so don't really understand your point.

 

Currently can't use failover/4g/ipv6 on wan and would like to whilst also believing that at the price point and for many scenarios (customer requirements/business case) this would be important to have.  

 

At the price point if business grade features are not provided (but are by all other competitors) then meraki sales lose out. As do  Engineers who struggle to install or use and users or customers who are equally unable to understand the (lack of)  explanation...

Here to help

Re: WE Need IPV6 Support in MX

I know you can't go back in time and stop yourself from buying your MX84.  I can't go back in time either.

 

But as far as decisions to be made, you entirely have control over where you go from here:  stay with Meraki MXes and see if "name and shaming" them will get them to move or work any faster to make their devices suit your specific needs...

 

...or switch vendors.

 

The situation we're in with Meraki is not just of our own making, but the decision of what to do about it going forward certainly is.  It may not entirely be up to you specifically, but your decision makers certainly have that choice.

 

As far as Ubiquiti versus Meraki, at least with Ubiquiti you have the option of configuring your entire network from your on-prem controller, irrespective of your WAN or connection to a cloud Dashboard hosted on AWS, or, failing that, you can SSH directly into your USG or EdgeRouter to configure the features you need to work with what you have available.

Here to help

Re: WE Need IPV6 Support in MX

Yep I have one at home (USG pro4)- lacking in the the  but more complex features (my local config file has a lot of settings),I but like mine a lot.

 

 

That said i really like the meraki Mx and would really like it to have ipv6 working as it needs to be managed by me or the other engineers who don't know Linux so well (features not in ubiquity controller)

 

Fingers crossed...

Getting noticed

Re: WE Need IPV6 Support in MX


@Daghan wrote:

I run part of Meraki Product Management that includes MX.

 

We agree (PM / Eng teams) with everyone on this list that we need IPv6 and we need it yesterday! 

 

There is nothing sinister about the delay. It isn't a hardware limitation, nor a Cisco ploy to drive a wedge between Meraki and Enterprise Networking products. In fact, we have engineers working on IPv6 right now and we are in the process of formulating an accurate roadmap. I believe we are within 3-6 months window for being able to articulate what IPv6 features will be available when. 

 

What is taking us this long?

 

When I launched MX with 2 engineers 8 years ago, we were the little engine that could. One strategy we adopted was to "fit the use-case", not to build generic features. Well, in some instances, we overfitted some of those use-cases that created technical debt. We had no clue that we had to worry about it. If someone came to me in 2011 and said you'll sell 1M MX in the next 8 years, I would have asked which psychedelic drug there were on.

 

But it happened!  We are energetically trying to redo some of our earlier decisions (network objects, n uplinks, no-nat, full support for BGP...are some highlights from our infinitely long to-do list).

 

None of the above is an excuse, but I wanted to shine the light of transparency on our thought process. 

 

To remain a strong (we are in fact 14K customers strong) SD-WAN provider, we have to put IPv6 behind us... and we will.

 

Thanks,

Daghan.


@Daghan @tnight 

 

In Nov. of 2018 you said and I quote "I believe we are within 3-6 months window for being able to articulate what IPv6 features will be available when." yet a full 10 months later Meraki continues to remain silent and frustrate an ever growing number of us. It's one thing that that Meraki is handling this IPv6 thing poorly in the first place but then to completely ignore their commitment to do better and articulate their plan is simply unacceptable.

 

 

Cohort Networks Inc.
Your Business. Connected.
Kind of a big deal

Re: WE Need IPV6 Support in MX


@danielpugh wrote:

Yep I have one at home (USG pro4)- lacking in the the  but more complex features (my local config file has a lot of settings),I but like mine a lot.

 . . . . as it needs to be managed by me or the other engineers who don't know Linux so well (features not in ubiquity controller)


Configuration (of the USG) is through the CLI, if it cannot be done through the controller. The  device runs under EdgeOS, which is a fork of Vyatta.

 

With the right tools (eg decent SSH client and something to browse directories and their contents via a GUI, such as FileZilla), the need for Linux skills is virtually gone. Most of the time SUDO is your friend, if you have rights issues. I think I have one page of notes that cover my required Linux knowledge.

 

That said, the Meraki dashboard is a more solid piece of software than the UniFi controller, but it can't do as much.

Robin St.Clair | Principal, Caithness Analytics | @uberseehandel
Here to help

Re: WE Need IPV6 Support in MX

Yes you can log on via SSH, but for config that is not supported on the controller you add to the local conf file (e.g. using vi).  This is then merged with the config received from the cloud controller.  

 

Pretty conversant with the details as we manage hundreds of sites from centralised cloud controllers in aws.   have had the pro4 at home for about 4 years - in those days lots of features were not available on the controller (many are still not such as split DNS).

 

You are right in that different tools/boxes for different scenarios, but at the same time sticking to the key point of this forum is important as Meraki has many great qualities - key point being that this feature request and a few others (better nat management) are well overdue.

 

Kind of a big deal

Re: WE Need IPV6 Support in MX

yes, daniel.


Robin St.Clair | Principal, Caithness Analytics | @uberseehandel
Meraki Employee

Re: WE Need IPV6 Support in MX

Hi all, thank you for your continued patience on this topic. We’d like to provide an update and bring further transparency on the IPv6 status for Cisco Meraki products.  Firstly, we want to acknowledge the clear gap in supporting IPv6 across the Meraki portfolio and sincerely understand the frustration that’s been expressed. 

 

Each Cisco Meraki product has a different set of IPv6 requirements and technical complexities. IPv6 is not a single feature but rather a suite of features and capabilities that need to be enabled as a journey; which, unfortunately, is not a quick undertaking especially since we need to solve for effective management of IPv6 functionality in addition to enabling IPv6 data plane capabilities. 

 

On our IPv6 journey, we have identified the key functions to be delivered across the Cisco Meraki portfolio. Our primary objective is to deliver IPv6 in a phased manner that is as simple and streamlined as possible to adopt for our existing and future customers.  IPv6 is one of our strategic cross-product initiatives and this is backed by engineering resources we have aligned to it.

 

We know you have asked for details, and we don’t yet have publicly-sharable specifics, but please rest assured that we have a comprehensive plan for IPv6 support that we are aggressively driving and are committed to providing continued updates on our progress.  As such, please expect the next update by the end of September 2019 on our IPv6 @ Meraki thread.

 

Thank you for your continued partnership,

 

The Cisco Meraki team

 

 

[Mod comment: We are marking this post as the solution to this thread. This is not because the issue is solved, but because we want to make the new location for updates from Meraki on this topic easier to access. That topic is: IPv6 @ Meraki.]

Community Manager

Re: WE Need IPV6 Support in MX

We are now locking this thread to further comments; stay tuned for updates on the new IPv6 @ Meraki thread.

 

UPDATE 14 JulyWe were over-zealous in our thread-locking. Opening this thread for further comments. Please also subscribe to the IPv6 @ Meraki thread for further updates from the Meraki team.

Caroline S | Community Manager, Cisco Meraki | @merakicaroline
New to the community? Get started here
Building a reputation

Re: WE Need IPV6 Support in MX

Hey, over two years ago I used to work for a Belgian ISP as technician and they were on the forefront of IPv6 in pretty much entire Europe.
They also use DHCP-PD for assigning prefixes to customers.

They also had their own modem/routers that supported a nifty feature called hiërarchical prefix delegation.
That means the ISP assigns a /56 prefix on the WAN side of that modem/router and that further could give out /60 prefixes to downstream routers so they could further subdivide those into /64 client networks.

I believe for the global unicast addressing that support on all L3 devices for hiërarchical prefix delegation is crucial to deal with dynamic addressing.

If Meraki is to support features like this in the future it is also important that just like on a cisco ISR you can define the subnet part of each of your subnets. So you dynamically get your global prefix from upstream and you put the subnet part in it which is fixed to your preference.
Kind of a big deal

Re: WE Need IPV6 Support in MX

I think most of us are planning on being allocated a /48 or /56 address or better, rather than a /64.

Robin St.Clair | Principal, Caithness Analytics | @uberseehandel
Here to help

Re: WE Need IPV6 Support in MX

That sounds suspiciously like the (subset of) HomeNet protocol -- a good idea that was thought of and "worked on" far too late in the IPv6 lifecycle for most enterprise-y products...at least to my knowledge...to make use of.

 

It would work for connections with dynamic prefixes (since they're delegated), as long as all the clients were SLAAC'd and you didn't have any managed endpoint requirements or non Windows 10 devices (for RDNSS) or any policy routing requirements (MX SD-WAN) for separate WAN connections or any servers that don't support...ummmmm...generic prefixes, I think?  The mechanism that lets an admin specify a host interface ID, but accepts any new prefixes when the RAs change?  The router/FW ACLs would also have to support that in the case of dynamic prefixes as well.

 

Thinking it through, I'd think for this to have hope of working the way IPv4 with Merakis do now, MXes would have to support pretty much every IPv6 mechanism defined by a non-superceded RFC; NPTv6 (if you want to use it), "Generic Prefix" (if you want to use it), hierarchal DHCP-PD/v6, ULA (if you want to use them), some sort of prefix-variable managed DHCPv6 delegating server with short DUID lease times where the scope prefixes change along with the upstream delegated prefixes received from (each) ISP(s) so that clients can renew leases on new prefixes without much downtime...or something.  At least bring some kind of auditing for any org that needs host ID tracking but doesn't want to sell their SMB employee kidney pairs for something like InfoBlox or Bluecoat IPAM.

 

The problem...errrrr..."challenge"....is keeping the "Meraki-ness".  This seems kinda feasible with something that lets you connect directly to the device to do the entire device configuration -- in the sense that you don't need a working IPv6 Internet connection to the cloud in order to configure your device to give you the IPv6 Internet access you'd already need in order to configure it -- again, that assumes if the local device admin interface remains roughly the same.  At the very least, each MX local admin page would have to provide a field that allows an admin to specify the prefix hint and length for DHCP-PD for each WAN-capable interface.  Or maybe MXes would just be initially configurable and managed over just IPv4 to connect to the Dashboard and then v6 access is configured then and isn't "live" until everything is validated via some WAN connectivity test from the client machine behind it (and any other L3 devices it might hierarchically be behind).  I mean, why not?  We're going to be dual-stacked for the foreseeable future, so nothing says we have to completely get rid of v4 usage.

 

Actually, that last part might not be ideal given current source address selection policies of most modern client OSes.  As soon as v6 global addresses are assigned or SLAAC'd by clients, they'll prefer them, even if the prefixes are not fully routable, and may have to "fail" to v4, which would negatively affect user sessions depending on how Happy Eyeballs behaves for each client.

 

But I'll be quite honest, I'm not sure how most of the above translates to a Dashboard interface.

Kind of a big deal

Re: WE Need IPV6 Support in MX

I have been reluctant to jump on the IPv6 bandwagon because of the need for Toredo tunnelling and for dual stacks, in most environments. In some implementations I have seen, dual stacking disables hardware offloading, which can have a big impact upon throughput.

 

So I would ask that a pure IPv6 implementation be introduced sooner rather than later. At that point, I'll switch over. All the AV kit, Playout devices, Smart TVs, workstations etc do IPv6 already, only the network kit doesn't,

Robin St.Clair | Principal, Caithness Analytics | @uberseehandel
Conversationalist

Re: WE Need IPV6 Support in MX


@Meraki-PM-Team wrote:

We know you have asked for details, and we don’t yet have publicly-sharable specifics, but please rest assured that we have a comprehensive plan for IPv6 support that we are aggressively driving and are committed to providing continued updates on our progress.  As such, please expect the next update by the end of September 2019 on our IPv6 @ Meraki thread.

 

Thank you for your continued partnership,

 

The Cisco Meraki team

 

 

[Mod comment: We are marking this post as the solution to this thread. This is not because the issue is solved, but because we want to make the new location for updates from Meraki on this topic easier to access. That topic is: IPv6 @ Meraki.]


Looking forward to the promised update later this month.

Getting noticed

Re: WE Need IPV6 Support in MX

I have to say I about died laughing when Meraki had the Podcast last weekend on IPv6 and pretty much none of the hardware supports it. The podcast also made it sound like things were coming quickly. Fingers Crossed for the September update.

 

@Meraki-PM-TeamPLEASE BEG management for them to allow you to share more. We all love Meraki hardware its just getting harder and harder to recommend with this glaring hole. Some of the other major firewall stuff we know is coming like ikev2 and objects.

Getting noticed

Re: WE Need IPV6 Support in MX

We dropped Meraki about a year ago because of some bugs that seemed like they were never going to get fixed and for me the major issue is lack of IPv6.  How does Meraki expect us to be taken seriously with our customers when they are asking for IPv6 and we couldn’t give them a straight answer?  I voted with my wallet and moved to FortiNet - not to start a debate on Cisco vs X but FortiNet supports IPv6 and has a much richer feature set at a lower price point.... 

Getting noticed

Re: WE Need IPV6 Support in MX

Why don't you keep the updates on the thread WHERE EVERYONE IS DISCUSSING.

 

I'm sick and tired of Meraki trying to suppress this discussion. Unmark as solved, keep updates in this thread.

Getting noticed

Re: WE Need IPV6 Support in MX

Trusting the September “Update” isn’t simply another delay. Anything less than a detailed roadmap to IPv6 will be simply insulting at this point.

Cohort Networks Inc.
Your Business. Connected.
Welcome to the Meraki Community!
To start contributing, simply sign in with your Cisco account. If you don't yet have a Cisco account, you can sign up.