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
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 …
.
.
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
########
.
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.
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.