Hello,
I'm discovering PCC on CCR1009 with 6.48.6.
At the moment, I'm focusing on src-address classifier as it look like the simplest classifier to check.
My setup is:
Webserver ------ WAN1 router ------ CCR1009 ------- My PC
|----------------WAN2 router -------------|
CCR1009 config includes:
7 ;;; PCC1
chain=prerouting action=mark-connection new-connection-mark=ISP1 passthrough=yes dst-address-type=!local
connection-mark=no-mark in-interface=vlan10 per-connection-classifier=src-address:2/0 log=no log-prefix=""
8 ;;; PCC2
chain=prerouting action=mark-connection new-connection-mark=ISP2 passthrough=yes dst-address-type=!local
connection-mark=no-mark in-interface=vlan10 per-connection-classifier=src-address:2/1 log=no log-prefix=""
Now I'm setting My PC IP to be equivalent to 10.0.0.5, 10.0.0.6, 10.0.0.7
To my surprise, my webserver shows every request it gets come from WAN1 router.
1. Am I correct to expect changing from one uplink to the other, when I pick a new address ?
2. Is there a way to look at PCC tables ?
3. Is it correct to expect WAN1 uplink to be choosen if IP address ends with an even figure, and WAN2 for odd figure ?
Best regards
Re: How to test PCC with src-address classifier ?
When you change the source address, the per-connection-classifier hash changes; it is not excluded that for two distinct src-address, the reminder of the hash after division by two is the same, but for, say, 5 consecutive addresses you would have to be "very lucky".1. Am I correct to expect changing from one uplink to the other, when I pick a new address?
No, and there are no tables - the hash is calculated from the indicated header fields for every single packet, making the per connection classifier stateless.2. Is there a way to look at PCC tables?
Not necessarily, I don't know the hashing function.3. Is it correct to expect WAN1 uplink to be choosen if IP address ends with an even figure, and WAN2 for odd figure?
You have shown only the rules that assign a connection-mark depending on the per-connection-classifier match. Do you translate the connection-mark to a routing-mark later on?
What does /ip firewall filter print stats where per-connection-classifier~"." show, do both rules show non-zero counts of packets & bytes?
Re: How to test PCC with src-address classifier ?
It's easier to test with dst-address, you won't have to reconfigure anything, just select different target address for e.g. ping.
To make sure it doesn't work because of some mistake elsewhere, enable logging for these PCC rules (log=yes log-prefix="PCC1"), and you'll see what they do, independent on anything else.
To make sure it doesn't work because of some mistake elsewhere, enable logging for these PCC rules (log=yes log-prefix="PCC1"), and you'll see what they do, independent on anything else.
-
-
olivier2831
Member
- Posts: 312
- Joined:
Re: How to test PCC with src-address classifier ?
Yes, testing with dst-address seems simpler ! Thank you for mentioning this !It's easier to test with dst-address, you won't have to reconfigure anything, just select different target address for e.g. ping.
To make sure it doesn't work because of some mistake elsewhere, enable logging for these PCC rules (log=yes log-prefix="PCC1"), and you'll see what they do, independent on anything else.
The issue is as long as the hashing algo remains unknown as Sindy said, it's not easy to check if PCC is working at all !
Testing failover is easy, testing load balance is not, IMHO.
Do you see any error in the following config.
Code: Select all
/ip firewall mangle
add action=accept chain=prerouting dst-address="$NET1/$LEN1" in-interface=bridge1 comment="Skip load balance rules for traffic to WAN1 hosts"
add action=accept chain=prerouting dst-address="$NET2/$LEN2" in-interface=bridge1 comment="Skip load balance rules for traffic to WAN2hosts"
add action=mark-connection chain=prerouting connection-mark=no-mark in-interface=ether1 new-connection-mark=ISP1 comment="Mark trafic from ISP1 to make sure replies leaves through the same interface"
add action=mark-connection chain=prerouting connection-mark=no-mark in-interface=ether2 new-connection-mark=ISP2 comment="Mark trafic from ISP2 to make sure replies leaves through the same interface"
add action=mark-connection chain=prerouting connection-mark=no-mark dst-address-type=!local in-interface=$GUESTIF new-connection-mark=ISP1 per-connection-classifier=both-addresses:2/0 comment="PCC WAN1 for traffic from Guest LAN"
add action=mark-connection chain=prerouting connection-mark=no-mark dst-address-type=!local in-interface=$GUESTIF new-connection-mark=ISP2 per-connection-classifier=both-addresses:2/1 comment="PCC WAN2 for traffic from Guest LAN"
add action=mark-routing chain=prerouting connection-mark=ISP1 in-interface=bridge1 new-routing-mark=to_ISP1 comment="Force ISP1 marked packets from LAN to use to_ISP1 routing table"
add action=mark-routing chain=prerouting connection-mark=ISP2 in-interface=bridge1 new-routing-mark=to_ISP2 comment="Force ISP2 marked packets from LAN to use to_ISP2 routing table"
add action=mark-routing chain=output connection-mark=ISP1 new-routing-mark=to_ISP1
add action=mark-routing chain=output connection-mark=ISP2 new-routing-mark=to_ISP2
Re: How to test PCC with src-address classifier ?
/ip firewall mangle print stats will show you immediately whether the rules do something or not.The issue is as long as the hashing algo remains unknown as Sindy said, it's not easy to check if PCC is working at all !
Testing failover is easy, testing load balance is not, IMHO.
Nope, the mangle rules seem allright to me. Have you disabled/removed/never added the action=fasttrack-connection rule in chain forward of /ip firewall filter?Do you see any error in the following config.
Another wild guess, an eventual typo in the routing-mark value of a route would cause packets to fallback to routing table main (the one consisting of routes with no routing-mark explicitly set).
-
-
olivier2831
Member
- Posts: 312
- Joined:
Re: How to test PCC with src-address classifier ?
I do have a fasttrack forward rule in /ip firewall filter./ip firewall mangle print stats will show you immediately whether the rules do something or not.The issue is as long as the hashing algo remains unknown as Sindy said, it's not easy to check if PCC is working at all !
Testing failover is easy, testing load balance is not, IMHO.
Nope, the mangle rules seem allright to me. Have you disabled/removed/never added the action=fasttrack-connection rule in chain forward of /ip firewall filter?Do you see any error in the following config.
Another wild guess, an eventual typo in the routing-mark value of a route would cause packets to fallback to routing table main (the one consisting of routes with no routing-mark explicitly set).
I used variables all over the place to avoid typos when entering IP addresses.
Code: Select all
/ip route
add check-gateway=ping distance=1 gateway=$GW1 routing-mark=to_ISP1
add check-gateway=ping distance=1 gateway=$GW2 routing-mark=to_ISP2
add distance=1 gateway=$GW1
add check-gateway=ping distance=2 gateway=$GW2
So it seems, traffic is correctly divided in two flows but flows leave through the same interface.
-
-
olivier2831
Member
- Posts: 312
- Joined:
Re: How to test PCC with src-address classifier ?
Does the order with which routes are entered matter ?
If positive, can you change it with WebFig ? In my testing, I couldn't move routes as I could move firewall routes.
If positive, can you change it with WebFig ? In my testing, I couldn't move routes as I could move firewall routes.
Re: How to test PCC with src-address classifier ?
No, the order of routes does not matter, as the route with the best matching (longest) dst-address prefix is always chosen; among all routes with the same dst-address, the distance parameter determines priority.
What does /ip route print detail show? And what does /ip route rule export show?
Also, disable the fasttrack rule, fasttracking bypasses mangle.
What does /ip route print detail show? And what does /ip route rule export show?
Also, disable the fasttrack rule, fasttracking bypasses mangle.
-
-
olivier2831
Member
- Posts: 312
- Joined:
Re: How to test PCC with src-address classifier ?
What does /ip route print detail show? And what does /ip route rule export show?
Also, disable the fasttrack rule, fasttracking bypasses mangle.
What does /ip route print detail show? And what does /ip route rule export show?
Also, disable the fasttrack rule, fasttracking bypasses mangle.
Code: Select all
[foo@MikroTik] > /ip route print detail
Flags: X - disabled, A - active, D - dynamic, C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme,
B - blackhole, U - unreachable, P - prohibit
0 A S dst-address=0.0.0.0/0 gateway=1.2.135.22 gateway-status=1.2.135.22 reachable via ether1 check-gateway=ping distance=1
scope=30 target-scope=10 routing-mark=to_ISP1
1 A S dst-address=0.0.0.0/0 gateway=3.4.30.254 gateway-status=3.4.30.254 reachable via ether2 check-gateway=ping distance=1
scope=30 target-scope=10 routing-mark=to_ISP2
2 A S dst-address=0.0.0.0/0 gateway=1.2.135.22 gateway-status=1.2.135.22 reachable via ether1 distance=1 scope=30
target-scope=10
3 S dst-address=0.0.0.0/0 gateway=1.2.135.22 gateway-status=1.2.135.22 reachable via ether1 distance=1 scope=30
target-scope=10
4 S dst-address=0.0.0.0/0 gateway=3.4.30.254 gateway-status=3.4.30.254 reachable via ether2 check-gateway=ping distance=2
scope=30 target-scope=10
5 ADC dst-address=10.111.0.0/21 pref-src=10.111.0.1 gateway=vlan10 gateway-status=vlan10 reachable distance=0 scope=10
6 ADC dst-address=3.4.30.248/29 pref-src=3.4.30.249 gateway=ether2 gateway-status=ether2 reachable distance=0 scope=10
7 ADC dst-address=1.2.135.16/29 pref-src=1.2.135.17 gateway=ether1 gateway-status=ether1 reachable distance=0 scope=10
8 ADC dst-address=192.168.1.0/24 pref-src=192.168.1.221 gateway=bridge1 gateway-status=bridge1 reachable distance=0 scope=10
9 ADC dst-address=192.168.2.0/24 pref-src=192.168.2.221 gateway=vlan2 gateway-status=vlan2 reachable distance=0 scope=10 Before and after disabling fasttrack, I run a serie of 5 tests or more (with src-address classifier), changing IP address between each test:
all went through WAN1 link (while WAN2 was up and running).
Between each test, I checked firewall counters and saw rules PCC rules being alternatively incremented :
increment IP by one digit, then download from webserver: counter1 incremented and counter2 unchanged
increment IP one more time by one digit, then download from webserver: counter2 incremented and counter1 unchanged
increment IP one more time by one digit, then download from webserver: counter1 incremented and counter2 unchanged
increment IP by two digits, then download from webserver: the same counter increments by one while the other stay unchanged.
So basically:
- both rules are applied alternatively
- either the action they are supposed to done is not done or the action is triggered but the consequence is not what I expected (changing from either1 to either2 or the opposite).
-
-
olivier2831
Member
- Posts: 312
- Joined:
Re: How to test PCC with src-address classifier ?
I should have written I ran latest tests with 6.49.2 box, not with 6.48.6 anymore.
Re: How to test PCC with src-address classifier ? [SOLVED]
Unless $GUESTIF is bridge1, you assign connection-marks properly, but you do not translate connection-marks to routing-marks properly. That's why I was asking you to watch counters of all rules, not just the mark-connnection/per-connection-classifier ones.
-
-
olivier2831
Member
- Posts: 312
- Joined:
Re: How to test PCC with src-address classifier ?
Yes, your are right: the rule that translated connection-marks to routing-marks didn't referred $GUESTIF as it should have.Unless $GUESTIF is bridge1, you assign connection-marks properly, but you do not translate connection-marks to routing-marks properly. That's why I was asking you to watch counters of all rules, not just the mark-connnection/per-connection-classifier ones.
Thank you very, very much !
On important note:
when you increment by one the latest digit of IP address, if I may call it this way (192.168.1.64, 65, 66, and so on) the route often flaps (leaves through ether1 or ether2) but not always.
I hope this can help others.