Automatic Multicast Tunneling (AMT) provides a method to tunnel multicast data over a unicast network, this is protocol for delivering multicast traffic from sources in a multicast-enabled network to receivers that lack multicast connectivity to the source network. The protocol uses UDP encapsulation and unicast replication to provide this functionality.

The AMT protocol if an RFC 7450 - https://datatracker.ietf.org/doc/html/rfc7450
Both Cisco and Juniper have implementations for this protocol. Additionally, there is also an open source project in C++ that implements the AMT Relay and AMT Gateway.
https://github.com/GrumpyOldTroll/amt

I was wondering whether RouterOS from Mikrotik supports this protocol or whether there are plans to support it in the future.

Do you have any idea how many "add this" requests are in the queue???
If they followed them, by hypothesis, all of them, they would do yours in 20 years.

Probably it will be added soon (7.18)

Probably it will be added soon (7.18)

More or less reliable sources, or do you just write because you don't know what to write?

or do you just write because you don't know what to write?

I think it's about you. Already second post in this topic without any sense...
Just wait until 7.18.

or do you just write because you don't know what to write?

I think it's about you. Already second post in this topic without any sense...
Just wait until 7.18.

The problem is you. Why necroposting on a topic from 2022 without the official source where it is written that probably they add the function in 7.18,
otherwise you just write random things without knowing what you're writing about.

If you open a feature request ticket, sometimes MT will say something to effect that it will be in the next release...

I saw a 7.18 Alpha version, it is already int there. So it is definitely coming.

Strange, in 7.18alpha4 there is not present...

The only things added not for joke are:

Support for CEF (Commont Event Format) logging format and timestamp support for milliseconds.

/31 address support

OpenVPN Password cap increased to 1000 characters

The problem is you. Why necroposting on a topic from 2022 without the official source where it is written that probably they add the function in 7.18,
otherwise you just write random things without knowing what you're writing about.

I won't comment these stupid conclusions. Calm down and don't scream so loud.
.

If they followed them, by hypothesis, all of them, they would do yours in 20 years.

I guess someone wins the lottery...

And, their AMT implementation does look simplier than PIM-SM or IGMP proxy (x2). Hopefully AMT works with WG tunnels to add multicast.

I won't comment these stupid conclusions. Calm down and don't scream so loud.

The conclusion is not stupid, someone passing by, without be one forum admin or post official sources, announces something, it's just bullshit.
Not to mention that maybe, as already happened, they remove some features from the alpha when they publish the beta, to then reinsert them later.

I won't comment these stupid conclusions. Calm down and don't scream so loud.

The conclusion is not stupid, someone passing by, without be one forum admin or post official sources, announces something, it's just bullshit.
Not to mention that maybe, as already happened, they remove some features from the alpha when they publish the beta, to then reinsert them later.

When people say it's rainy in their town, you also asking officials to confirm this? And regarding removal/readding i said it will probably appear in 7.18. You are the only bullshitter here... I'm stopping this conversation.

I'm not aware of Application-level support for any of AMT, so I guess currently it relies on gateway equipment to support this? Would love to read about any deployments of this technology, sounds interesting in the context of roadwarrior VPN clients, as Amm0 suggested.

@teslasystems

this cat always screams and posts in that manner are unfortunately usual. try to not bother to much ... one cannot re-educate or soften a stiff spaghetti even if it is on point

maybe "just roll with it" might be a good option

Anyway, has anyone tested this over WG? Would that approach even work over WG or over VPNs?

I've never use AMT anywhere, so sorry for basic question - just the concept/config scheme look simpler than other approaches to tunnel multicast over a L3 VPNs.

Anyway, has anyone tested this over WG? Would that approach even work over WG or over VPNs?

I've never use AMT anywhere, so sorry for basic question - just the concept/config scheme look simpler than other approaches to tunnel multicast over a L3 VPNs.

II will try to test it within a week or two.

Could someone clarify, what interface should be specified in 'Interface' field for relay side and for gateway side?

I won't comment these stupid conclusions. Calm down and don't scream so loud.

The conclusion is not stupid, someone passing by, without be one forum admin or post official sources, announces something, it's just bullshit.
Not to mention that maybe, as already happened, they remove some features from the alpha when they publish the beta, to then reinsert them later.

v7.18 beta 4, just like he said
*) net - added initial support for automatic multicast tunneling (AMT) interface (additional fixes);

So what bullshit are you referring to again?

v7.18 beta 4, just like he said
*) net - added initial support for automatic multicast tunneling (AMT) interface (additional fixes);

So what bullshit are you referring to again?

@TrevinLC1997
If you can't read, it's not mine's fault, and you're the one who made a fool of yourself again.

My post is 2025-Jan-20 14:04:08

The beta4 is build on 2025-Jan-31 15:46

I wrote the post 11 days before it was build.
Not counting the day of release which I don't know if it's the same.

So, don't you realize the (using the word you like and that you used in your post) bullshit you're writing?

To make some announcements, official sources should be cited, not bullshit like you like.
Announcing new features with only assumptions gets nowhere.

Let's end this dispute, it was implemented finally.

Can anyone answer my previous question about interfaces? Should I specify upstream interface on relay side and LAN interface on gateway side? Or something else? I'm not very familiar with specifics of AMT, just want to check it, but also don't want to mess something and cause multicast traffic going to ISP...

Let's end this dispute, it was implemented finally.

For me it was already ended since 2025-Jan-20 14:04:08 (and again now).
It was @TrevinLC1997 who rather unwisely wrote what he wrote.

////////////////

If I don't answer you it's because I haven't tried it yet, otherwise I would have done it.

6,000+ views. No ones tested AMT? Only testing patience for diatribes.

6,000+ views. No ones tested AMT? Only testing patience for diatribes.

I was trying, but not sure what to specify in interfaces. Can't make it work yet. The latest attempt finished with kernel failure...

6,000+ views. No ones tested AMT? Only testing patience for diatribes.

Could you describe the specific problem you would like to solve with AMT?

6,000+ views. No ones tested AMT? Only testing patience for diatribes.

Could you describe the specific problem you would like to solve with AMT?

Basically whether it could be used to tunnel multicast over a L3 VPN like WG. I guess I could try it myself, but just seem like something someone might have tried already.

It looks like 'Interface' parameter stands for interface, that is used for communication between gateway and relay. And it doesn't allow to choose L3 interfaces like WireGuard. But there are also local IP/remote IP parameters for communication, so I don't see any sense in 'Interface' parameter. Why it requires to choose interface in addition to IPs, when specifying IPs is enough for communication and sending UDP/2268 packets? Strange. Or may be it also sends multicast packets...
Anyway, still can't make it work. It's a new stuff for me, so may be I don't understand something...

Yeah, I tried in beta for an hour. Could not figure it out... now that was after very quick read the RFC (https://datatracker.ietf.org/doc/html/rfc7450), which left a lot open to vendors on details. I can normally guess my way through the new features, but not this one...

Based on RFC, it wants an anycast address, so local address likely should be identical. But this is where my guessing stopped, since AMT didn't allow you to enter a IPv6 address, and I'm that should work fine on RouterOS. Imagine anycast must work on IPv4 on RouterOS since they must have to have tested it (and UI doesn't allow IPv6), but never really considered Mikrotik being involved in anycast (vs just routing it).

This feature is already in "stable" release, and I think MT should update the docs and add some usage examples...

Has anyone tried this yet and have it working?

Would you theoretically be able to transport multicast IPTV over some sort of a VPN?

I currently use L2TP w/ BCP to have IPTV multicast from one location to another. I've also had it working with EOIP over Wireguard but just curious if the AMT method would be stabler or faster?

Would you theoretically be able to transport multicast IPTV over some sort of a VPN?

.
guess this is the intention ... without the fuzz to ballot the adressing scheme of a vpn protocol ...
.
... it is ... a upstream-big-head request ... so ... it's quickly done

stabler or faster

.
stable ... in the means of entropy ... ? ... there is no "more stable"
.
faster ... ... in the means ... of fewer CPU-cycles ?! ... maybe ...
.
... but who gives a *

tried to replace a running GRE-over-Wireguard-Multicast-Solution ... nope !
... not speaking
... sometimes ... you're ... sitting duck ... peep'in for documentation

MT said, that they are still testing it and it's not fully implemented yet. Until then, there will be no documentation.

MT said, that they are still testing it and it's not fully implemented yet. Until then, there will be no documentation.

Then it shouldn't be in the stable release, I guess.

MT said, that they are still testing it and it's not fully implemented yet. Until then, there will be no documentation.

Then it shouldn't be in the stable release, I guess.

Well, I guess perhaps I'm not the idiot who couldn't figure it out. And just a fool for believing it had to work under some conditions if it was in "stable".

Some document in help.mikroitk.com before going to "stable" that said "This feature is still underdevelopment" would avoided a lot of waste time. I spend an hour, other here have too.

Ridiculous if that was the answer & response was NOT adding a doc page or post somewhere customers could see.

In 7.19beta6, I saw this:

*) net - remove support for automatic multicast tunneling (AMT) interface (introduced in v7.18)

Now... how this wasn't found before shipping 7.18, IDK. Or if "stable" has something that is "experimental" and/or potentially dropped next release — even just one word like "experimental" in their terse release note scheme would have helped here.

Historically, docs often lag behind release notes, even "stable". So if something was in a "rc" and "stable", you kinda assume the "docs are missing". Not that something that does not work well enough to even remain in the release.

I don't need AMT... but just example of more sloppiness in Mikrotik release management.

Reverting changes seems to be common in recent releases. e.g. introduced hw acceleration for openvpn just to revert it for some ciphers after several feedback. I mean, is this really not testable? Rhetorical question, of course this could be tested beforehand.

Rhetorical question, of course this could be tested beforehand.

Yeah that's kinda my question. I wouldn't have spend 1+ hour testing if there was SOME clue it was "experimental"/"for testing"/etc

I won't comment these stupid conclusions. Calm down and don't scream so loud.

The conclusion is not stupid, someone passing by, without be one forum admin or post official sources, announces something, it's just bullshit.
Not to mention that maybe, as already happened, they remove some features from the alpha when they publish the beta, to then reinsert them later.

Well, I see I was right...

Well, I see I was right...

LOL. When I saw the release note, I thought of you and this thread "guess rex' is right"

The conclusion is not stupid, someone passing by, without be one forum admin or post official sources, announces something, it's just bullshit.
Not to mention that maybe, as already happened, they remove some features from the alpha when they publish the beta, to then reinsert them later.

Well, I see I was right...

This absolutely doesn't change the fact, that AMT has appeared in 7.18, as I initially stated. Everything else is another question.

This absolutely doesn't change the fact, that AMT has appeared in 7.18, as I initially stated. Everything else is another question.

And this absolutely does not change the fact that when someone appeared on the forum and writes about new features added to RouterOS,
he must always cite the official sources, otherwise he is not credible, as I initially stated. Everything else is another question.



An example?

In RouterOS 7.20_ab158 they added DoQ (DNS over QUIC) support.

This absolutely doesn't change the fact, that AMT has appeared in 7.18, as I initially stated. Everything else is another question.

And this absolutely does not change the fact that when someone appeared on the forum and writes about new features added to RouterOS,
he must always cite the official sources, otherwise he is not credible, as I initially stated. Everything else is another question.

You are good in being a parrot.

When people say it's rainy in their town, you also asking officials to confirm this?

...

I'm tired of this bullshit.

Don't worry, my bet is @rextended is going to be wrong in then end...

they would do yours in 20 years.

So I have no idea why your commentary sparked a reaction. And to be clear, my LOL is I was expecting the "I'm right", not supportive of the hostile tone. And guessing more discussion ahead on it this DUMB subtopic.

The issue isn't it was in a "alpha", the issue is it made it into 7.18 "stable" so different case at this point.... And, I'm 100% supportive of people reporting what there testing in "alpha", and can make my own judgement about it.

Regardless, Mikrotik needs to get their act together on docs/communications. I don't mind testing things - but really don't like my time wasted. On that point, the whole @rextended vs @telsasystem discussion is just childish.

When people say it's rainy in their town, you also asking officials to confirm this?

...

I'm tired of this bullshit.

Your words bother you? Then don't say them...

I'm fed up too, especially with the wrong examples.
I don't care about the information about whether it rains somewhere or not,
certainly (...) doesn't depend on RouterOS and I can't install that information inside the RouterBOARD...

discussion is just childish.

You are right, I will stop here, or rather there↑↑↑

The point is that it is wrong to provide information WITHOUT PROOF.

The point is that it is wrong to provide information WITHOUT PROOF.

The point is when someone sees a new funtionality, he has a full right to say this. What the hell is wrong with you?

Aside from the fact that they banned my account for a week for revealing some things in advance,
I'm not telling you that they shouldn't be published, but that in the face of this news, there needs to be PROOF.
Do you understand what I write or not?

Aside from the fact that they banned my account for a week for revealing some things in advance,

Yeah I don't run my restraml /console/inspect tool against of the alpha I've occasionally get for that reason. But others want to post, well, as a reader that might interesting.

But Mikrotik could communicate more directly is my usual grip and present here. And, if we pretend they are working on DNS-over-QUIC, they should send that to folk who complained about Quad9 and use them as ginny pigs... the sooner you find problem in a feature, the better in IMO.

My other grip is whomever requested this feature, should have posted an article here using it, or tested it under some conditions. Every feature I've requested where they implementing it, you'll find some posting here on how I works.

there you have it

¯\_(ツ)_/¯
maybe ... uncontrolled Premier-League Public-Viewings all over the world ?
( but it's ... world-cup quali break ?! ) ... ?