Community discussions

MikroTik App
 
User avatar
floaty
Member
Member
Topic Author
Posts: 314
Joined: Sat Oct 20, 2018 1:24 am
Location: 52°08'32.34"N 14°39'05.0"E

CRS3xx L3HW in redundant topology

Mon Nov 02, 2020 2:24 pm

Hello,
are there any recommendations, opinions or a prospect how CRS3xx-hardware-offloading could be implemented in a redundant IP-topology.
Is this possibly part of a roadmap ?
Just learned that an IP-redundancy-protocol like VRRP or even a simple script - state of play - can't be used to achieve L3HW-offloading capacity and IP-redundancy ~<=1sec.
Thanks
 
User avatar
floaty
Member
Member
Topic Author
Posts: 314
Joined: Sat Oct 20, 2018 1:24 am
Location: 52°08'32.34"N 14°39'05.0"E

Re: CRS3xx L3HW in redundant topology

Tue Nov 03, 2020 1:21 am

mmh ... "vrrp-by-proxy*
(using *vrrp-v3 with a script for setting 'vlan-if'-IP ) could be a workaround
made some tests ... just dreaming ... : )
... setting an address ... pushing some extra pakets ... : | ?
.
guess the problem isn't merely connected to hw-offloading, then to presenting the "client" a viable hw-offload-capable-gateway ... in a way or another ...
.
0001080006040001000c29bd76b9ac101e0a000000000000ac101e0a---# full
                                                           #
0001 ------------------------------------------------------# hw-type
    0800                                                   # protocol-type
        06-------------------------------------------------# hw-size
          04                                               # proto-size
            0001-------------------------------------------# opcode:request(1)
                000c29bd76b9                               # sender-mac
                            ac101e0a-----------------------# sender-ip
                                    000000000000           # target-mac
                                                ac101e0a---# target-ip
.
maybe ...
.
script+packet(s).png
 
User avatar
floaty
Member
Member
Topic Author
Posts: 314
Joined: Sat Oct 20, 2018 1:24 am
Location: 52°08'32.34"N 14°39'05.0"E

Re: CRS3xx L3HW in redundant topology

Wed Nov 04, 2020 9:18 am

.
Actually the results from my testing are better than expected.
Using only the up-down-scripts from VRRP to set the IP-address of an hardware-offloaded (vlan-)interface, then push some gratuitous-arp packets with the traffic-generator tool.
Downtime <~ 1Sec. ... Not Datacenter-like but better than pre-version3-VRRP.
You have to handcarve the gratuitous arp-packets with a hex-editor ( note: colasoft p-builder isn't working incomp. pcap-format **)
Master/Backup script shouldn't use static interface-numbers ...
.
example-packet and visual:
https://my.hidrive.com/share/rn-m0ysaz9
.
vrrp on master:
####
/ip address set interface=71-e2-vlan100 address=172.16.30.10/24 numbers=3
/tool traffic-generator inject-pcap pcap-file=gr-arp-e2-v100.pcap once interface=71-e2-vlan100
/tool traffic-generator inject-pcap pcap-file=gr-arp-e2-v100.pcap once interface=71-e2-vlan100
/tool traffic-generator inject-pcap pcap-file=gr-arp-e2-v100.pcap once interface=71-e2-vlan100
/tool traffic-generator inject-pcap pcap-file=gr-arp-e2-v100.pcap once interface=71-e2-vlan100
/tool traffic-generator inject-pcap pcap-file=gr-arp-e2-v100.pcap once interface=71-e2-vlan100
/tool traffic-generator inject-pcap pcap-file=gr-arp-e2-v100.pcap once interface=71-e2-vlan100
/tool traffic-generator inject-pcap pcap-file=gr-arp-e2-v100.pcap once interface=71-e2-vlan100
/tool traffic-generator inject-pcap pcap-file=gr-arp-e2-v100.pcap once interface=71-e2-vlan100
/tool traffic-generator inject-pcap pcap-file=gr-arp-e2-v100.pcap once interface=71-e2-vlan100
/tool traffic-generator inject-pcap pcap-file=gr-arp-e2-v100.pcap once interface=71-e2-vlan100
####
vrrp on backup
####
ip address set interface=71-e2-vlan100 address=172.16.30.9/24 numbers=3
.
########
**http://packeth.sourceforge.net/packeth/Home.html is a compatible editor - a packet build with this tool is accepted from /tool traffic-generator inject-pcap
########
.
Last edited by floaty on Thu Nov 05, 2020 12:58 pm, edited 2 times in total.
 
User avatar
raimondsp
MikroTik Support
MikroTik Support
Posts: 267
Joined: Mon Apr 27, 2020 10:14 am

Re: CRS3xx L3HW in redundant topology

Wed Nov 04, 2020 9:40 am

Hi there, and thanks for the research!

If I understood correctly, the current limitation in hardware-offloading of VRRP interfaces is that the device fails to resolve the MAC address of VRRP IP? The device sends an ARP request to identify the MAC address. However, when being the VRRP master, the device owns the IP and, therefore, already should know the MAC.
 
User avatar
floaty
Member
Member
Topic Author
Posts: 314
Joined: Sat Oct 20, 2018 1:24 am
Location: 52°08'32.34"N 14°39'05.0"E

Re: CRS3xx L3HW in redundant topology

Wed Nov 04, 2020 10:53 am

Not 100% sure about that. Since hw-offloading is working with the "real" interface address - mac or IP (and I presume the hw-offloading is anchored to the mac-address) my idea was to use VRRP only as failure-recognition and use the master/backup-script to set and reset the IP of the interface which is hw-offload capable.
As workaround for the change of the underlying mac-address I tried to push a couple of gratuitous arp-packets, to inform the clients that a change has occured.
Obviously this isn't working so bad (for a normal client, ... a modern firewall or client with arp-watch is may be not so easy convinced).
It's of course also not so suitable for daily use to build a matching grat.-arp-packet for every interface ... but a function like "push n gratuitous arps out of interface x" ?
Not shure if this is already script-able with the paket-generator, but from the winbox I could'nt find a function to insert customized payload.
Or (the gold-standard) it's possible to directly connect, the VRRP-mac with the hw-offload capability, but that depends - as you already said - on the chip-design.

Who is online

Users browsing this forum: Google [Bot] and 22 guests