Community discussions

MikroTik App
 
mafiosa
Member Candidate
Member Candidate
Topic Author
Posts: 110
Joined: Fri Dec 09, 2016 8:10 pm

dual wan PCC loadbalancing with GRE tunnel.

Fri Jan 08, 2021 9:14 pm

Here is my configuration. I am learning routes from gre/ipsec tunnels via OSPF but cannot reach them. Please help me out. I have PCC with port forwarding configured.

# jan/09/2021 00:40:36 by RouterOS 6.46.8
# software id = 7HJJ-N0I9
#
# model = RouterBOARD 3011UiAS
# serial number = 783D066965C5
/caps-man channel
add band=2ghz-onlyn name=2.4 tx-power=27
add band=5ghz-n/ac name=5 tx-power=27
/interface bridge
add name=LAN
add admin-mac=6C:3B:6B:69:69:69 auto-mac=no name=WAN
add name=WLAN
add name=loopback
/interface ethernet
set [ find default-name=ether1 ] comment="Alliance bypass"
set [ find default-name=ether2 ] comment=SSWL mac-address=6C:3B:6B:96:96:96
set [ find default-name=ether5 ] comment="Data Center"
set [ find default-name=ether10 ] comment=Wifi
/interface l2tp-server
add name=Nabanna-PoP user=nabanna
/interface gre
add !keepalive local-address=10.28.115.18 name=Bally-PoP remote-address=\
172.19.65.221
add !keepalive local-address=10.28.115.18 name=Dumdum-PoP remote-address=\
10.14.94.232
add !keepalive local-address=10.28.115.18 name=Madhyamgram-PoP \
remote-address=10.14.96.109
add !keepalive local-address=10.28.115.18 name=ifog remote-address=\
193.148.249.44
/caps-man security
add authentication-types=wpa-psk,wpa2-psk encryption=aes-ccm \
group-encryption=aes-ccm name=wifikey
/caps-man configuration
add channel=2.4 country=taiwan distance=indoors installation=indoor mode=ap \
multicast-helper=full name=wifi2.4 security=wifikey ssid="Kalpak AP"
add channel=5 country=taiwan distance=indoors installation=indoor mode=ap \
multicast-helper=full name=wifi5 security=wifikey ssid="Kalpak AP 5GHz"
/caps-man interface
add configuration=wifi2.4 disabled=no l2mtu=1600 mac-address=\
B8:69:F4:20:C6:BA master-interface=none name=wifi2.4 radio-mac=\
B8:69:F4:20:C6:BA radio-name=B869F420C6BA
add configuration=wifi5 disabled=no l2mtu=1600 mac-address=B8:69:F4:20:C6:BB \
master-interface=none name=wifi5 radio-mac=B8:69:F4:20:C6:BB radio-name=\
B869F420C6BB
/interface list
add name=lans
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
/ip ipsec policy group
add name=group1
/ip ipsec profile
set [ find default=yes ] dh-group=modp2048 enc-algorithm=aes-256 \
hash-algorithm=sha256
add dh-group=modp2048 enc-algorithm=aes-256 hash-algorithm=sha256 name=\
pop-profile
/ip ipsec peer
add address=172.19.65.221/32 exchange-mode=ike2 local-address=10.28.115.18 \
name=bally profile=pop-profile
add address=10.14.96.109/32 exchange-mode=ike2 local-address=10.28.115.18 \
name=madhyamgram profile=pop-profile
add address=10.14.94.232/32 exchange-mode=ike2 local-address=10.28.115.18 \
name=dumdum profile=pop-profile
/ip ipsec proposal
set [ find default=yes ] auth-algorithms=sha256 enc-algorithms=aes-256-cbc \
lifetime=8h pfs-group=modp2048
add auth-algorithms=sha256 enc-algorithms=aes-256-cbc lifetime=8h name=\
pop-proposal pfs-group=modp2048
/ip pool
add name=dhcp_pool0 ranges=172.22.146.2-172.22.146.62
add name=dhcp_pool1 ranges=172.22.146.66-172.22.146.126
/ip dhcp-server
add address-pool=dhcp_pool0 disabled=no interface=LAN lease-time=1w name=\
dhcp1
add address-pool=dhcp_pool1 disabled=no interface=WLAN lease-time=1w name=\
dhcp2
/routing bgp instance
set default as=213326 router-id=192.168.254.1
/routing ospf area
add area-id=0.0.0.1 name=area1
add area-id=0.0.0.2 name=area2
add area-id=0.0.0.3 name=area3
add area-id=0.0.0.4 name=area4
/routing ospf instance
set [ find default=yes ] router-id=192.168.254.1
/snmp community
add addresses=::/0 name=corerouter
/caps-man manager
set enabled=yes upgrade-policy=suggest-same-version
/interface bridge port
add bridge=WLAN interface=wifi2.4
add bridge=WLAN interface=wifi5
add bridge=LAN interface=ether7
add bridge=LAN interface=ether8
add bridge=LAN interface=ether9
add bridge=LAN interface=ether6
add bridge=WAN interface=ether1
add bridge=WAN interface=sfp1
/ip neighbor discovery-settings
set discover-interface-list=all
/interface bridge vlan
add untagged=sfp1,ether2,ether1 vlan-ids=10
add tagged=ether2 untagged=ether3 vlan-ids=20
/interface l2tp-server server
set allow-fast-path=yes enabled=yes use-ipsec=yes
/interface list member
add interface=WLAN list=lans
add interface=LAN list=lans
/ip address
add address=192.168.254.1 interface=loopback network=192.168.254.1
add address=172.22.146.1/26 interface=LAN network=172.22.146.0
add address=172.22.146.65/26 interface=WLAN network=172.22.146.64
add address=192.168.168.21/30 interface=Dumdum-PoP network=192.168.168.20
add address=192.168.168.5/30 interface=Madhyamgram-PoP network=192.168.168.4
add address=192.168.168.9/30 interface=Bally-PoP network=192.168.168.8
add address=192.168.72.1/23 interface=ether5 network=192.168.72.0
add address=10.28.115.18/30 interface=WAN network=10.28.115.16
add address=172.28.55.3/24 interface=ether2 network=172.28.55.0
/ip cloud
set ddns-enabled=yes
/ip dhcp-server network
add address=172.22.146.0/26 gateway=172.22.146.1
add address=172.22.146.64/26 gateway=172.22.146.65
/ip dns
set allow-remote-requests=yes servers=192.168.72.72,192.168.73.73
/ip firewall mangle
add action=mark-connection chain=input in-interface=WAN new-connection-mark=\
abspl_out_conn passthrough=yes
add action=mark-routing chain=output connection-mark=abspl_out_conn \
new-routing-mark=abspl_out_traffic passthrough=no
add action=mark-connection chain=input in-interface=ether2 \
new-connection-mark=sswl_out_conn passthrough=yes
add action=mark-routing chain=output connection-mark=sswl_out_conn \
new-routing-mark=sswl_out_traffic passthrough=no
add action=mark-connection chain=forward connection-state=new in-interface=\
WAN new-connection-mark=abspl_out_pfw passthrough=no
add action=mark-routing chain=prerouting connection-mark=abspl_out_pfw \
in-interface-list=lans new-routing-mark=abspl_out_traffic passthrough=no
add action=mark-connection chain=forward connection-state=new in-interface=\
ether2 new-connection-mark=sswl_out_pfw passthrough=no
add action=mark-routing chain=prerouting connection-mark=sswl_out_pfw \
in-interface-list=lans new-routing-mark=sswl_out_traffic passthrough=no
add action=accept chain=prerouting in-interface=WAN
add action=accept chain=prerouting in-interface=ether2
add action=mark-connection chain=prerouting dst-address-type=!local \
new-connection-mark=abspl_conn passthrough=yes per-connection-classifier=\
src-address-and-port:2/0
add action=mark-connection chain=prerouting dst-address-type=!local \
new-connection-mark=sswl_conn passthrough=yes per-connection-classifier=\
src-address-and-port:2/1
add action=mark-routing chain=prerouting connection-mark=abspl_conn \
in-interface-list=lans new-routing-mark=to_abspl passthrough=yes
add action=mark-routing chain=prerouting connection-mark=sswl_conn \
in-interface-list=lans new-routing-mark=to_sswl passthrough=yes
/ip firewall nat
add action=masquerade chain=srcnat out-interface=WAN
add action=masquerade chain=srcnat out-interface=ether2
add action=dst-nat chain=dstnat dst-address=10.28.115.18 dst-port=4789 \
protocol=udp to-addresses=192.168.72.8 to-ports=4789
/ip ipsec identity
add peer=dumdum policy-template-group=group1 remote-id=ignore
add peer=madhyamgram policy-template-group=group1
add peer=bally policy-template-group=group1
/ip ipsec policy
add dst-address=10.14.94.232/32 peer=dumdum proposal=pop-proposal protocol=\
gre src-address=10.28.115.18/32
add dst-address=10.14.96.109/32 peer=madhyamgram proposal=pop-proposal \
protocol=gre src-address=10.28.115.18/32
add dst-address=172.19.65.221/32 peer=bally proposal=pop-proposal \
src-address=10.28.115.18/32
/ip route
add distance=1 gateway=10.28.115.17 routing-mark=abspl_out_traffic
add distance=1 gateway=172.28.55.1 routing-mark=sswl_out_traffic
add check-gateway=ping distance=1 gateway=10.28.115.17 routing-mark=to_abspl
add check-gateway=ping distance=2 gateway=172.28.55.1 routing-mark=to_sswl
add check-gateway=ping distance=1 gateway=10.28.115.17
add check-gateway=ping distance=2 gateway=172.28.55.1
/ip route rule
add action=lookup-only-in-table dst-address=172.22.146.64/26 src-address=\
172.22.146.0/26 table=main
add action=lookup-only-in-table dst-address=172.22.146.0/26 src-address=\
172.22.146.64/26 table=main
/ip service
set telnet disabled=yes
set ftp disabled=yes
set ssh disabled=yes
set www-ssl disabled=no
set api disabled=yes
set api-ssl disabled=yes
/ip upnp
set enabled=yes
/ip upnp interfaces
add interface=WAN type=external
add interface=LAN type=internal
add interface=WLAN type=internal
/ipv6 address
add address=2a0c:9a40:100f:45e::2 advertise=no interface=ifog
add address=2a0f:9400:8017::1 advertise=no interface=loopback
add address=2a0f:9400:8017:69::1 advertise=no interface=Madhyamgram-PoP
add address=2a0f:9400:8017:20::1 advertise=no interface=Dumdum-PoP
/mpls ldp
set enabled=yes lsr-id=192.168.254.1 transport-address=192.168.254.1
/mpls ldp interface
add interface=Dumdum-PoP
add interface=Madhyamgram-PoP
add interface=Nabanna-PoP
/ppp secret
add local-address=192.168.168.25 name=nabanna profile=default-encryption \
remote-address=192.168.168.26 service=l2tp
add local-address=192.168.168.29 name=abhishek1 profile=default-encryption \
remote-address=192.168.168.30 service=l2tp
add local-address=192.168.168.29 name=abhishek2 profile=default-encryption \
remote-address=192.168.168.31 service=l2tp
/routing bgp network
add network=2a0f:9400:8017::/48 synchronize=no
add network=2a0e:b107:9e0::/46 synchronize=no
add network=2a0e:b107:9e4::/46 synchronize=no
add network=2a0e:b107:9e8::/46 synchronize=no
add network=2a0e:b107:9ec::/46 synchronize=no
add network=2a0e:b107:b00::/46 synchronize=no
add network=2a0e:b107:b04::/46 synchronize=no
add network=2a0e:b107:b08::/46 synchronize=no
add network=2a0e:b107:b0c::/46 synchronize=no
/routing bgp peer
add address-families=ipv6 name=ifog out-filter=ix-out remote-address=\
2a0c:9a40:100f:45e::1 remote-as=34927
/routing filter
add action=accept chain=ix-out prefix=2a0f:9400:8017::/48
add action=accept chain=ix-out prefix=2a0e:b107:9e0::/46
add action=accept chain=ix-out prefix=2a0e:b107:9e4::/46
add action=accept chain=ix-out prefix=2a0e:b107:9e8::/46
add action=accept chain=ix-out prefix=2a0e:b107:9ec::/46
add action=accept chain=ix-out prefix=2a0e:b107:b00::/46
add action=accept chain=ix-out prefix=2a0e:b107:b04::/46
add action=accept chain=ix-out prefix=2a0e:b107:b08::/46
add action=accept chain=ix-out prefix=2a0e:b107:b0c::/46
add action=discard chain=ix-out
/routing igmp-proxy interface
add interface=WAN upstream=yes
add interface=Nabanna-PoP
add interface=LAN
add interface=Dumdum-PoP
add interface=Madhyamgram-PoP
add interface=WLAN
add interface=ether2
/routing ospf interface
add interface=loopback network-type=broadcast
add interface=Dumdum-PoP network-type=broadcast
add interface=Madhyamgram-PoP network-type=broadcast
add interface=Nabanna-PoP network-type=broadcast
add interface=Bally-PoP network-type=broadcast
add interface=LAN network-type=broadcast
add interface=WLAN network-type=broadcast
add interface=ether5 network-type=broadcast
/routing ospf network
add area=backbone network=192.168.254.1/32
add area=backbone network=172.22.146.0/26
add area=backbone network=172.22.146.64/26
add area=area1 network=192.168.168.20/30
add area=area2 network=192.168.168.4/30
add area=area3 network=192.168.168.24/30
add area=area4 network=192.168.168.8/30
add area=backbone network=192.168.72.0/23
/snmp
set contact="Kalpak Mukhopadhyay +91 7059787415" enabled=yes location=Sodpur \
trap-community=corerouter trap-interfaces=all trap-version=2
/system clock
set time-zone-name=Asia/Kolkata
/system identity
set name=core.kalpak.net.in
/system logging
add disabled=yes topics=ipsec,!packet
/system ntp client
set enabled=yes primary-ntp=10.28.115.17 secondary-ntp=172.28.55.1
/system package update
set channel=long-term
/system routerboard settings
set auto-upgrade=yes
/tool graphing interface
add store-on-disk=no
/tool netwatch
add host=192.168.168.26
 
mbaute
just joined
Posts: 17
Joined: Fri May 22, 2015 3:54 pm

Re: dual wan PCC loadbalancing with GRE tunnel.

Sat Jan 09, 2021 2:32 am

hi,

add action=mark-connection chain=prerouting dst-address-type=!local \
new-connection-mark=abspl_conn passthrough=yes per-connection-classifier=\
src-address-and-port:2/0
add action=mark-connection chain=prerouting dst-address-type=!local \
new-connection-mark=sswl_conn passthrough=yes per-connection-classifier=\
src-address-and-port:2/1
add action=mark-routing chain=prerouting connection-mark=abspl_conn \
in-interface-list=lans new-routing-mark=to_abspl passthrough=yes
add action=mark-routing chain=prerouting connection-mark=sswl_conn \
in-interface-list=lans new-routing-mark=to_sswl passthrough=yes

this part should exclude traffic to addresses learnt through your gre tunnels as it's being sent out through WAN and ether 2 interfaces
 
mafiosa
Member Candidate
Member Candidate
Topic Author
Posts: 110
Joined: Fri Dec 09, 2016 8:10 pm

Re: dual wan PCC loadbalancing with GRE tunnel.

Sat Jan 09, 2021 12:21 pm

hi,

add action=mark-connection chain=prerouting dst-address-type=!local \
new-connection-mark=abspl_conn passthrough=yes per-connection-classifier=\
src-address-and-port:2/0
add action=mark-connection chain=prerouting dst-address-type=!local \
new-connection-mark=sswl_conn passthrough=yes per-connection-classifier=\
src-address-and-port:2/1
add action=mark-routing chain=prerouting connection-mark=abspl_conn \
in-interface-list=lans new-routing-mark=to_abspl passthrough=yes
add action=mark-routing chain=prerouting connection-mark=sswl_conn \
in-interface-list=lans new-routing-mark=to_sswl passthrough=yes

this part should exclude traffic to addresses learnt through your gre tunnels as it's being sent out through WAN and ether 2 interfaces
Not working just tested! I disabled the 4 old lines that were similar and enabled these new ones. Rebooted still doesn't help.
 
sindy
Forum Guru
Forum Guru
Posts: 6655
Joined: Mon Dec 04, 2017 9:19 pm

Re: dual wan PCC loadbalancing with GRE tunnel.

Sat Jan 09, 2021 12:45 pm

It seems you didn't get what @mbaute wanted to say, so I'll try to re-word it.

The routes learned through OSPF are added to routing table called main, which is used to route packets without any routing-mark assigned. Those rules @mbaute has shown were your own rules from the export, and the suggestion was not to replace your original ones by them (as they are the same), but to modify these rules to prevent them from matching the traffic which should use the routes learned through OSPF, so that these packets would be routed using the routing table main (or to add a rule before them which will assign some other connection-mark value to this traffic, so that the rules translating connection-mark abspl_conn to routing-mark to_sswl would ignore them). Something like

add action=mark-connection chain=prerouting dst-address-list=ospf-destinations new-connection-mark=ospf_conn passthrough=yes

placed before that set of rules. You have to populate the address-list ospf-destinations with the correct list of subnets. If the OSPF destinations consist of just a few prefixes, use of /ip route rule rows to revert the routing-mark assignment may be more efficient.

Other than that:
  • dst-address-type=local matches only on own addresses of the router itself, not on addresses in all subnets to which these own addresses belong. Someone has misunderstood this years ago, and since then people keep copy-pasting that blindly from each other.
  • there is no point in assigning a connection-mark to each packet and then translate it to routing-mark using another rule. The very point of connection-mark is to mark the whole connection while handling its initial packet, and then just do the connection-mark -> routing-mark translation for the rest of that connection's packets. If done properly, this will reduce the number of rules matched against every single packet, so your CPU will become a bit colder.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
mafiosa
Member Candidate
Member Candidate
Topic Author
Posts: 110
Joined: Fri Dec 09, 2016 8:10 pm

Re: dual wan PCC loadbalancing with GRE tunnel.

Sat Jan 09, 2021 5:09 pm

It seems you didn't get what @mbaute wanted to say, so I'll try to re-word it.

The routes learned through OSPF are added to routing table called main, which is used to route packets without any routing-mark assigned. Those rules @mbaute has shown were your own rules from the export, and the suggestion was not to replace your original ones by them (as they are the same), but to modify these rules to prevent them from matching the traffic which should use the routes learned through OSPF, so that these packets would be routed using the routing table main (or to add a rule before them which will assign some other connection-mark value to this traffic, so that the rules translating connection-mark abspl_conn to routing-mark to_sswl would ignore them). Something like

add action=mark-connection chain=prerouting dst-address-list=ospf-destinations new-connection-mark=ospf_conn passthrough=yes

placed before that set of rules. You have to populate the address-list ospf-destinations with the correct list of subnets. If the OSPF destinations consist of just a few prefixes, use of /ip route rule rows to revert the routing-mark assignment may be more efficient.

Other than that:
  • dst-address-type=local matches only on own addresses of the router itself, not on addresses in all subnets to which these own addresses belong. Someone has misunderstood this years ago, and since then people keep copy-pasting that blindly from each other.
  • there is no point in assigning a connection-mark to each packet and then translate it to routing-mark using another rule. The very point of connection-mark is to mark the whole connection while handling its initial packet, and then just do the connection-mark -> routing-mark translation for the rest of that connection's packets. If done properly, this will reduce the number of rules matched against every single packet, so your CPU will become a bit colder.
Please share the modified PCC rules here it will definitely help many other like me.
 
sindy
Forum Guru
Forum Guru
Posts: 6655
Joined: Mon Dec 04, 2017 9:19 pm

Re: dual wan PCC loadbalancing with GRE tunnel.

Sat Jan 09, 2021 6:15 pm

Please share the modified PCC rules here it will definitely help many other like me.
Sharing particular rules makes little sense for "many other", as everyone's environment is a little bit different (yours is far from usual as an example, and I don't have in mind just using country=taiwan in wireless settings of a device operated in India). So it is critical that people understand the principle, otherwise they would blindly copy-paste those rules and be surprised that the magic wouldn't happen.

In your particular case, you assign some connection-mark values to guarantee that incoming connections via WAN and ether2 will be responded via these interfaces, so these action=mark-connection rules may stay as they are.

To both your existing PCC rules, you have to add connection-state=new dst-address-list=!ospf-destinations. This will cause the specific connection-mark value to be assigned only once, when handling the initial packet of each connection, and only if the destination is not one of those learned through OSPF. So it will exempt the connections towards destinations reachable via OSPF from the PCC distribution, as they will stay without any connection-mark, and so their packets will not get any routing-mark, and so they will be routed using routing table main which contains the routes learned via OSPF.

Since no embedded match condition like dst-address-type=accessible-through-dynamic-route is available, you have to use the address-list named ospf-destinations and populate it on your own, according to the actual address plan of your network. Maybe it is enough that it consists of all three RFC1918 private address ranges, but maybe some private ranges are accessible via WAN or ether2 or, vice versa, some public ranges are accessible via OSPF. Only you know that.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
mafiosa
Member Candidate
Member Candidate
Topic Author
Posts: 110
Joined: Fri Dec 09, 2016 8:10 pm

Re: dual wan PCC loadbalancing with GRE tunnel.

Sat Jan 09, 2021 8:12 pm

Since no embedded match condition like dst-address-type=accessible-through-dynamic-route is available, you have to use the address-list named ospf-destinations and populate it on your own, according to the actual address plan of your network. Maybe it is enough that it consists of all three RFC1918 private address ranges, but maybe some private ranges are accessible via WAN or ether2 or, vice versa, some public ranges are accessible via OSPF. Only you know that.
[/quote]

Thanks for your explanation. I got it! I actually didn't want to manually create a list using OSPF! was looking for a way to avoid that manual address list creation.
 
mbaute
just joined
Posts: 17
Joined: Fri May 22, 2015 3:54 pm

Re: dual wan PCC loadbalancing with GRE tunnel.

Sun Jan 10, 2021 3:47 am

It seems you didn't get what @mbaute wanted to say, so I'll try to re-word it.

The routes learned through OSPF are added to routing table called main, which is used to route packets without any routing-mark assigned. Those rules @mbaute has shown were your own rules from the export, and the suggestion was not to replace your original ones by them (as they are the same), but to modify these rules to prevent them from matching the traffic which should use the routes learned through OSPF, so that these packets would be routed using the routing table main (or to add a rule before them which will assign some other connection-mark value to this traffic, so that the rules translating connection-mark abspl_conn to routing-mark to_sswl would ignore them). Something like

add action=mark-connection chain=prerouting dst-address-list=ospf-destinations new-connection-mark=ospf_conn passthrough=yes

placed before that set of rules. You have to populate the address-list ospf-destinations with the correct list of subnets. If the OSPF destinations consist of just a few prefixes, use of /ip route rule rows to revert the routing-mark assignment may be more efficient.

Other than that:
  • dst-address-type=local matches only on own addresses of the router itself, not on addresses in all subnets to which these own addresses belong. Someone has misunderstood this years ago, and since then people keep copy-pasting that blindly from each other.
  • there is no point in assigning a connection-mark to each packet and then translate it to routing-mark using another rule. The very point of connection-mark is to mark the whole connection while handling its initial packet, and then just do the connection-mark -> routing-mark translation for the rest of that connection's packets. If done properly, this will reduce the number of rules matched against every single packet, so your CPU will become a bit colder.
Damn! I wish I had your ability to explain things, awesome 👏🏽👏🏽
Since no embedded match condition like dst-address-type=accessible-through-dynamic-route is available, you have to use the address-list named ospf-destinations and populate it on your own, according to the actual address plan of your network. Maybe it is enough that it consists of all three RFC1918 private address ranges, but maybe some private ranges are accessible via WAN or ether2 or, vice versa, some public ranges are accessible via OSPF. Only you know that.
Thanks for your explanation. I got it! I actually didn't want to manually create a list using OSPF! was looking for a way to avoid that manual address list creation.
[/quote]

to automate that address list you can use something like

:do {
:foreach i in=[/ip route find ospf] do={
:local network [/ip route get $i dst-address];
/ip firewall address-list remove [/ip firewall address-list find where timeout=00:00:00];
/ip fire addr add list=OSPF address=$network timeout=00:01:00;
}
:delay 60s;
} while=(true)

and keep it up with another script that checks if it's running, like of php supervisor

Regards,
 
sindy
Forum Guru
Forum Guru
Posts: 6655
Joined: Mon Dec 04, 2017 9:19 pm

Re: dual wan PCC loadbalancing with GRE tunnel.

Sun Jan 10, 2021 11:49 am

I wish I had your ability to explain things, awesome
Thank you, but the thing here is that you've understood it already before reading my explanation; the true measure of that ability is the number of people who didn't before and do after. And here I sometimes question myself 🙂

to automate that address list you can use something like
I gave a thought to this too, but I was somehow assuming that either there are just a few subnets accessible via OSPF and not accessible via the two WANs and vice versa, hence the scripting would be an overkill, or those subnets accesible via the GRE tunnels are accessible via the two WANs too but access via the GRE tunnels is preferred, and in such case the lag between learning the route via OSPF and adding the destination to the address-list would let some connections take the suboptimal route.

And then there is e.g. the issue of an error if you attempt to add a duplicate item to an address-list (I expect multiple OSPF routes to the same distance to be learned, with different distance values), so writing and debugging a script capable of handling all such exceptions may quickly turn more complex than creating the address-list just once manually.

But it's of course up to @mafiosa to decide.

Another thing - for a reason I don't understand, when the timeout of a dynamically added address-list item expires, the item stays accessible to scripting for five more seconds, indicating a timeout of 0:0:0. Do you happen to know the idea behind that?
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
mafiosa
Member Candidate
Member Candidate
Topic Author
Posts: 110
Joined: Fri Dec 09, 2016 8:10 pm

Re: dual wan PCC loadbalancing with GRE tunnel.

Sun Jan 10, 2021 8:19 pm

to automate that address list you can use something like

:do {
:foreach i in=[/ip route find ospf] do={
:local network [/ip route get $i dst-address];
/ip firewall address-list remove [/ip firewall address-list find where timeout=00:00:00];
/ip fire addr add list=OSPF address=$network timeout=00:01:00;
}
:delay 60s;
} while=(true)

and keep it up with another script that checks if it's running, like of php supervisor

Regards,
Hello if you don't mind can you modify the script so that it adds connected routes also to the address list. I think that will solve my issue. I mean both ospf and connected routes will be added to a single address list.
 
mafiosa
Member Candidate
Member Candidate
Topic Author
Posts: 110
Joined: Fri Dec 09, 2016 8:10 pm

Re: dual wan PCC loadbalancing with GRE tunnel.

Sun Jan 10, 2021 10:09 pm

UPDATE: I have finally been able to manage it. Now I can use PCC load balancing while accessing the gre tunnel networks. Now waiting for Mikrotik to FIX port flapping issue on my RB3011 with 6.48 release. I added two mangle rule: 1 to mark new connections with destination address list ospf as vpn_conn and then to make those marked connections to use main routing table. Also in the PCC rule I have used != vpn_conn in connection mark so that those are excluded from PCC.
 
mbaute
just joined
Posts: 17
Joined: Fri May 22, 2015 3:54 pm

Re: dual wan PCC loadbalancing with GRE tunnel.

Sun Jan 10, 2021 11:05 pm

I wish I had your ability to explain things, awesome
Thank you, but the thing here is that you've understood it already before reading my explanation; the true measure of that ability is the number of people who didn't before and do after. And here I sometimes question myself 🙂

to automate that address list you can use something like
I gave a thought to this too, but I was somehow assuming that either there are just a few subnets accessible via OSPF and not accessible via the two WANs and vice versa, hence the scripting would be an overkill, or those subnets accesible via the GRE tunnels are accessible via the two WANs too but access via the GRE tunnels is preferred, and in such case the lag between learning the route via OSPF and adding the destination to the address-list would let some connections take the suboptimal route.

And then there is e.g. the issue of an error if you attempt to add a duplicate item to an address-list (I expect multiple OSPF routes to the same distance to be learned, with different distance values), so writing and debugging a script capable of handling all such exceptions may quickly turn more complex than creating the address-list just once manually.

But it's of course up to @mafiosa to decide.
Yes totally! adding wan interfaces to the mix would break things apart. unless the wan used is also a default, primary, no mangled gateway, you are screwed!

In my previous job I used this to exclude in my router ospf domain with family routers from networks reachable through work's vpn. There were no redundancy whatsoever, just ptp links in a single area to reach family devices for assistance, but merely just for fun and lazyness managing routes lol

Another thing - for a reason I don't understand, when the timeout of a dynamically added address-list item expires, the item stays accessible to scripting for five more seconds, indicating a timeout of 0:0:0. Do you happen to know the idea behind that?
this is a classic mikrotik's "deal with it and move along", learn through frustration to include
/ip firewall address-list remove [/ip firewall address-list find where/where list= && timeout=00:00:00];
in every script involving lists :c . A couple of years ago they just didn't expire unless you rebooted the router or manually deleted them but hey, 5sec is an improvement 😅😅

Hello if you don't mind can you modify the script so that it adds connected routes also to the address list. I think that will solve my issue. I mean both ospf and connected routes will be added to a single address list.
Maybe you should exclude your LAN networks with another static list and prerouting rule, remember that your other networks with address in /ip address are also connected, including WAN and ppp ones.
 
mafiosa
Member Candidate
Member Candidate
Topic Author
Posts: 110
Joined: Fri Dec 09, 2016 8:10 pm

Re: dual wan PCC loadbalancing with GRE tunnel.

Mon Jan 11, 2021 2:01 pm


Hello if you don't mind can you modify the script so that it adds connected routes also to the address list. I think that will solve my issue. I mean both ospf and connected routes will be added to a single address list.
Maybe you should exclude your LAN networks with another static list and prerouting rule, remember that your other networks with address in /ip address are also connected, including WAN and ppp ones.
[/quote]
yes did that only! created another addresslistfor connected routes and marked the connection with the same markings of vpn_conn

Who is online

Users browsing this forum: eworm, kenyloveg, RonJohn63 and 215 guests