Hello,
I started to use mikrotik 2 months ago and is a great product but i think that the documentation and examples are not enought. Last week i was traying to find out how to make mangle in order to redirect all p2p traffic to my secund internet link but i didn´t find a clear example. Can someone help me with that cause i really need it. This is my scenario:

Interfaces:
Ether1 => LAN side (192.168.1.0/24)
Ether2 => WAN side (cablemodem ISP)
Ether3 => WAN side (cablemodem another ISP)

I want that all P2P traffic goes to the Ether3

Thanks

Search on the historial and check this

http://wiki.mikrotik.com/wiki/Routing

Maximiliano

you won't be able to redirect ALL p2p traffic to second gateway... never! Reason is simple, not all p2p packets are recognized by packet mangler. There are several p2p protocols which can be only blocked and not speed limited - why do you think it is so?

once again : forget it, you will NEVER be able to send p2p traffic to one gateway and rest to other. The only thing you can do is to send known traffic (http, ftp, etc, etc) to one gateway and LEAVE p2p GOING THRU THE DEFAULT GATEWAY.

what protocols can be blocked but not shaped?
if you can block then why cant you shape it?

So this means that a customer that is being mangled out another isp will eventually have traffic try to route out the default gateway?

> what protocols can be blocked but not shaped?

encrypted bittorrent and Warez for sure. But it's more complicated, read below.




> if you can block then why cant you shape it?

because it's not possible to recognize ALL p2p traffic packets. It's that simple.

Many protocols are recognized to extent they can be blocked only (not traffic shaped) as this was technically sufficient for bandwidth management purposes (=allow p2p during night, disable throughout day) and main reason is that it's not technically possible to recognize all packets. Nobody has the knowledge, time, passion, luck etc to analyze p2p communication to maximum detail... read something about it on ipp2p.org and other l7 filtering solutions. And yet, we're not taking into account ciphering here

Our biggest bandwidth hogger is dc++ then followed by bitorrent. DC++ is one of the oldest protocols, it's pretty straight forward and SIMPLE - yet we were not able to move DC++ traffic to another gateway no matter how we tried. And believe me, we spent a lot of time with this as it's causing us some technical problems and we are not networking novices.


Knowing some technical details about p2p protocols (search for technical p2p protocol description, there are several guides on internet), we simply won't devote our time to this anymore. You haven't seen a single person here on forum to report "I got it working, p2p goes to second gateway". And you won't see one soon.

> what protocols can be blocked but not shaped?

encrypted bittorrent and Warez for sure. But it's more complicated, read below.

that makes no sense

> if you can block then why cant you shape it?

because it's not possible to recognize ALL p2p traffic packets. It's that simple.

of course, but why can't you shape it when you can identify it and block it?
Are you referring to it's inherent imperfectness (i.e can't identify it early enough) ?

Many protocols are recognized to extent they can be blocked only (not traffic shaped) as this was technically sufficient for bandwidth management purposes (=allow p2p during night, disable throughout day) and main reason is that it's not technically possible to recognize all packets. Nobody has the knowledge, time, passion, luck etc to analyze p2p communication to maximum detail... read something about it on ipp2p.org and other l7 filtering solutions. And yet, we're not taking into account ciphering here

I wouldn't say nobody. I'd like to think that people experienced enough to accomplish this would consider the implications before doing so.

Our biggest bandwidth hogger is dc++ then followed by bitorrent. DC++ is one of the oldest protocols, it's pretty straight forward and SIMPLE - yet we were not able to move DC++ traffic to another gateway no matter how we tried. And believe me, we spent a lot of time with this as it's causing us some technical problems and we are not networking novices

Was NAT in the picture?

Knowing some technical details about p2p protocols (search for technical p2p protocol description, there are several guides on internet), we simply won't devote our time to this anymore. You haven't seen a single person here on forum to report "I got it working, p2p goes to second gateway". And you won't see one soon.[/quote]

The problem is: how to mangle all other unknown protocols (e.g. client/server custom applications) and redirect them to another gateway?

> of course, but why can't you shape it when you can identify it and block it?


sten, please read ipp2p.org and l7filter pages, particularly this one:
http://l7-filter.sourceforge.net/protocols

there you will see what I said : you can't identify ALL packets (100%, all of them) that belongs to p2p protocol ; maybe there is one or two p2p protocols which have 100% packets identified but there is another 20473 p2p protocols that DO NOT HAVE (okej, maybe not 20473 but at least ten).

then, AS YOU DON'T HAVE 100% OF P2P TRAFFIC IDENTIFIED, how do you want to shape it? You don't know that this packet and that packet is p2p, so it will not go into your shaping. I don't remember exactly which protocol (maybe it was encrypted bitorrent) is identified by synchronization packets only - you can't identify "body" of the transfer, actual data, because they are encrypted. This encryption was done this year with one simple target in mind : OBEY ALL KNOWN TRAFFIC SHAPERS AND LIMITERS. Simple, huh? And authors did succeed! So right now you can either block that protocol totally or - if you let it go through - you have to accept fact you CAN'T SHAPE IT.

And because you don't know ALL PACKETS BELONGING TO P2P communication, YOU CAN'T SEND IT TO ANOTHER GATEWAY. Simple as that. You won't be able to redirect p2p traffic to slower gateway leaving your main upstream provider free of p2p balast.

enough said. We have two CCIEs on board and after some time we came to conclusion that best strategy to fight with p2p leechers is to limit them GENERALLY to some exact speed (for example like dsl : half megabit) and don't bother with them anymore. Never ever. Your time is more valuable.

> of course, but why can't you shape it when you can identify it and block it?

sten, please read ipp2p.org and l7filter pages, particularly this one:
http://l7-filter.sourceforge.net/protocols

there you will see what I said : you can't identify ALL packets (100%, all of them) that belongs to p2p protocol ; maybe there is one or two p2p protocols which have 100% packets identified but there is another 20473 p2p protocols that DO NOT HAVE (okej, maybe not 20473 but at least ten).

I never said you could, but i DID ask you wether you where referring to it's inherent imperfectness on the line below the one you quoted, which your rant indicates.

then, AS YOU DON'T HAVE 100% OF P2P TRAFFIC IDENTIFIED, how do you want to shape it? You don't know that this packet and that packet is p2p, so it will not go into your shaping. I don't remember exactly which protocol (maybe it was encrypted bitorrent) is identified by synchronization packets only - you can't identify "body" of the transfer, actual data, because they are encrypted. This encryption was done this year with one simple target in mind : OBEY ALL KNOWN TRAFFIC SHAPERS AND LIMITERS. Simple, huh? And authors did succeed! So right now you can either block that protocol totally or - if you let it go through - you have to accept fact you CAN'T SHAPE IT.

I asked you; "...., but why can't you shape it when you can identify it and block it?". Here i clearly indicated on the assumption that you can identify it since you say you can block it.

And because you don't know ALL PACKETS BELONGING TO P2P communication, YOU CAN'T SEND IT TO ANOTHER GATEWAY. Simple as that. You won't be able to redirect p2p traffic to slower gateway leaving your main upstream provider free of p2p balast.

enough said. We have two CCIEs on board and after some time we came to conclusion that best strategy to fight with p2p leechers is to limit them GENERALLY to some exact speed (for example like dsl : half megabit) and don't bother with them anymore. Never ever. Your time is more valuable.

It has become clear to me that you are talking about things you do not fully comprehend. Please do not give us your uneducated opinion on us ever again.