BIG problem with migrating config form BIG IP 5200 to new r5000 series

[markisa321]

Currently, the client has two BIG IP devices BIG IP 5200v and they are in the process of replacing those two devices with new BIG IP r5000 devices. On the new devices, we manually set everything we need, vlans, self ip addresses, routes, trunks and that's all ok. When we tried to migrate the rest of the configuration, specifically the virtual servers with over 1000, we failed.

Please help us, this is extremely important and urgent.

Error output during verification:

UCS load validation: failed Validating system configuration... /defaults/asm_base.conf /defaults/config_base.conf /defaults/ipfix_ie_base.conf /defaults/ipfix_ie_f5base.conf /defaults/low_profile_base.conf /defaults/low_security_base.conf /defaults/policy_base.conf /defaults/analytics_base.conf /defaults/apm_base.conf /defaults/apm_oauth_base.conf /defaults/apm_pua_ssh_base.conf /defaults/apm_saml_base.conf /defaults/app_template_base.conf /defaults/classification_base.conf /var/libdata/dpi/conf/classification_update.conf /defaults/ips_base.conf /var/libdata/ips/ips_update.conf /defaults/daemon.conf /defaults/pem_base.conf /defaults/profile_base.conf /defaults/sandbox_base.conf /defaults/security_base.conf /defaults/urldb_base.conf /usr/share/monitors/base_monitors.conf /defaults/cipher.conf /defaults/ilx_base.conf /defaults/integrated_auth.conf Validating configuration... /config/bigip_base.conf /config/bigip_user.conf /config/bigip.conf Loading schema version: 14.1.4.6 Syntax Error:(/config/bigip.conf at line: 31507) "bad-tcp-flags-all-clr" identifier doesn't match to any of the following: arp-flood or bad-ext-hdr-order or bad-icmp-chksum or bad-icmp-frame or bad-igmp-frame or bad-ip-opt or bad-ipv6-hop-cnt or bad-ipv6-ver or bad-sctp-chksum or bad-tcp-chksum or bad-tcp-flags-malformed or bad-ttl-val or bad-udp-chksum or bad-udp-hdr or bad-ver or dns-a-query or dns-aaaa-query or dns-any-query or dns-axfr-query or dns-cname-query or dns-ixfr-query or dns-malformed or dns-mx-query or dns-ns-query or dns-nxdomain-query or dns-other-query or dns-oversize or dns-ptr-query or dns-qdcount-limit or dns-response-flood or dns-soa-query or dns-srv-query or dns-txt-query or dup-ext-hdr or ether-brdcst-pkt or ether-mac-sa-eq-da or ether-multicst-pkt or ext-hdr-too-large or flood or hdr-len-gt-l2-len or hdr-len-too-short or hop-cnt-leq-one or host-unreachable or icmp-frag or icmp-frame-too-large or icmpv4-flood or icmpv6-flood or igmp-flood or igmp-frag-flood or ip-bad-src or ip-err-chksum or ip-frag-flood or ip-len-gt-l2-len or ip-opt-frames or ip-other-frag or ip-overlap-frag or ip-short-frag or ip-uncommon-proto or ip-unk-prot or ipv4-mapped-ipv6 or ipv6-atomic-frag or ipv6-bad-src or ipv6-ext-hdr-frames or ipv6-frag-flood or ipv6-len-gt-l2-len or ipv6-other-frag or ipv6-overlap-frag or ipv6-short-frag or l2-len-ggt-ip-len or l4-bdos or l4-ext-hdrs-go-end or land-attack or no-l4 or no-listener-match or non-tcp-connection or opt-present-with-illegal-len or payload-len-ls-l2-len or routing-header-type-0 or sip-ack-method or sip-bye-method or sip-cancel-method or sip-invite-method or sip-malformed or sip-message-method or sip-notify-method or sip-options-method or sip-other-method or sip-prack-method or sip-publish-method or sip-register-method or sip-subscribe-method or sip-uri-limit or sweep or tcp-ack-flood or tcp-ack-ts or tcp-bad-urg or tcp-flags-uncommon or tcp-half-open or tcp-hdr-len-gt-l2-len or tcp-hdr-len-too-short or tcp-opt-overruns-tcp-hdr or tcp-rst-flood or tcp-syn-flood or tcp-syn-oversize or tcp-synack-flood or tcp-window-size or tidcmp or too-many-ext-hdrs or ttl-leq-one or udp-flood or unk-ipopt-type or unk-tcp-opt-type

• There are screenshot of all steps what we have done:

1. Created a UCS file on one big ip device that is at the client's
2. Manually created VLANs, routes, self-ip addresses, trunk interface on the new device
3. Started Jourenys and inserted the UCS file from the client's device, screenshot of the steps we did:

After last step we got this message:

[azahajkiewicz]

Seems like one of the AFM DOS vector names (bad-tcp-flags-all-clr) is not allowed on the new platform. As a quick workaround you could try updating the bigip.conf (config/bigip.conf and/or config/partitions/DMZ/bigip.conf) file in the editor and manually remove that vector from the configuration.

[markisa321]

Hello,

Thank you for feedback. I already try something like that but mybe it's not good. I will try again.

On Fri, Dec 15, 2023, 22:59 azahajkiewicz @.***> wrote:

Seems like one of the AFM DOS vector names (bad-tcp-flags-all-clr) is not allowed on the new platform. As a quick workaround you could try updating the bigip.conf (config/bigip.conf and/or config/partitions/DMZ/bigip.conf) file in the editor and manually remove that vector from the configuration.

— Reply to this email directly, view it on GitHub https://github.com/f5devcentral/f5-journeys/issues/122#issuecomment-1858538976, or unsubscribe https://github.com/notifications/unsubscribe-auth/AKSGFDPIEWQHHYCIOOJ72JLYJTB5ZAVCNFSM6AAAAABAUUF66KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNJYGUZTQOJXGY . You are receiving this because you authored the thread.Message ID: @.***>

[d-bamini]

Hi, Please , can you share with us the resolution of the issues? regards

[wojtek0806]

@d-bamini has the suggestion in this comment been followed: https://github.com/f5devcentral/f5-journeys/issues/122#issuecomment-1858538976 ?

[wojtek0806]

definitely reproducible, tracking JOURNEYS-643

[wojtek0806]

@d-bamini and @markisa321 this seems to be a problem when tenant is on version 17.1.1, i have retested deployment on tenant 15.1.8 and it went through, if this is not a big problem for you, you can create the migration target (tenant on 15.1.8) and try migrating like that if you do not want to manually edit the config files as per @azahajkiewicz suggestion, we will investigate this internally and update here

[markisa321]

Hello everyone, sorry for the late reply.

We have not managed to solve the problem at all. We tried to manually remove the part that popped up as an error from the config file, but that didn't help. In the end, we were forced to do a legacy migration, disconnected two old devices from the cluster and connected a new one and an old one and messed with the migration.

In general, the journey tool was of no use to us in this case :)

[kavilla07v]

Hi! We have a DHD deployment and trying to upgrade from 15.1.2.1 to v17, but we are having a similar issue with vector, I found this article, but it seems not resolving my issue. I wanted to share, I think its comething with v17+dos

https://cdn.f5.com/product/bugtracker/ID1282029.html

Message on load sys config verify: network attack data (tcp-flags-uncommon): Suspicious vector feature is not supported for tcp-flags-uncommon vector.

Katherine V.