HA management interface Reservation ( not working )

[BensonLEI]

Hi, guys,

I am using Forti600E HA-pair with FortiOS v6.4.4. (Forti600E03_04 pair )

And I have configured the physical mgmt interface for HA mgmt interface; but the mgmt interface does not work after the HA mgmt int Reservation:

The configuration:

Forti600E_03 # show sys ha config system ha set group-id 17 set group-name "HA" set mode a-a set hbdev "ha" 301 "port1" 100 set ha-mgmt-status enable config ha-mgmt-interfaces edit 1 set interface "mgmt" set gateway 10.101.1.254 next end set override enable set priority 200 set ha-direct enable end

Forti600E_03 # show sys int mgmt config system interface edit "mgmt" set ip 10.101.1.40 255.255.255.0 set allowaccess ping https ssh snmp fgfm ftm set type physical set dedicated-to management set lldp-reception disable set lldp-transmission disable set role lan set snmp-index 2 set trust-ip-1 10.101.1.0 255.255.255.0 next end

Forti600E_03 # exe ping 10.101.1.40 PING 10.101.1.40 (10.101.1.40): 56 data bytes

--- 10.101.1.40 ping statistics --- 5 packets transmitted, 0 packets received, 100% packet loss

Forti600E_03 #

==========================

Problems:

1. The device can not pingtest to 10.101.1.254

2. Trom outside (same subnet, 10.101.1.0 /24 ) can not pingtest to 10.101.1.40

3. The switchport connected to the mgmt interface, can not see the mac add of the mgmt interface

4. Trom the network switch, can not see any traffic from the mgmt interface.

Noted:

Without configuring the mgmt interface into "HA-mgmt-int Reservation" ( standalone device ), the mgmt interface can be pingtest.

Any advice and recommendation.

Many many thanks.

[BensonLEI]

Hi, guys,

I found the problem, it is due to traffic routed through internet port2 ( not the right port -mgmt port) :

id=20085 trace_id=4 func=print_pkt_detail line=5700 msg="vd-root:0 received a packet(proto=1, 10.0.0.245:5888->10.101.1.40:2048) from local. type=8, code=0, id=5888, seq=3." id=20085 trace_id=4 func=resolve_ip_tuple_fast line=5781 msg="Find an existing session, id-00004b34, original direction" id=20085 trace_id=4 func=ipd_post_route_handler line=490 msg="out port2 vwl_zone_id 0, state2 0x0, quality 0.

How I can control the routing of the mgmt interface, thx ?

[nael]

Hello,

I have the same issue. Did you resolved it?

Thanks

 

[Kangming]

Hi     For the connectivity test of the HA independent management interface, we should do this:    # execute enter vsys_hamgmt  then # execute ping 192.168.91.254(HA MGMT Gateway)   ================ FGT101E_Master_379 # FGT101E_Master_379 # execute enter <name>    vdom name vsys_hamgmt root   FGT101E_Master_379 # execute enter vsys_hamgmt  // Enter the lightweight independent management vdom current vdom=vsys_hamgmt:3   FGT101E_Master_379 # get router info routing-table all    // Have a separate routing table   Routing table for VRF=0 Codes: K - kernel, C - connected, S - static, R - RIP, B - BGP        O - OSPF, IA - OSPF inter area        N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2        E1 - OSPF external type 1, E2 - OSPF external type 2        i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area        * - candidate default   C       192.168.91.0/24 is directly connected, mgmt   FGT101E_Master_379 # diagnose ip route list tab=255 vf=3 scope=253 type=3 proto=2 prio=0 0.0.0.0/0.0.0.0/0->127.0.0.0/32 pref=127.0.0.1 gwy=0.0.0.0 dev=39(vsys_hamgmt) tab=255 vf=3 scope=254 type=2 proto=2 prio=0 0.0.0.0/0.0.0.0/0->127.0.0.0/8 pref=127.0.0.1 gwy=0.0.0.0 dev=39(vsys_hamgmt) tab=255 vf=3 scope=254 type=2 proto=2 prio=0 0.0.0.0/0.0.0.0/0->127.0.0.1/32 pref=127.0.0.1 gwy=0.0.0.0 dev=39(vsys_hamgmt) tab=255 vf=3 scope=253 type=3 proto=2 prio=0 0.0.0.0/0.0.0.0/0->127.255.255.255/32 pref=127.0.0.1 gwy=0.0.0.0 dev=39(vsys_hamgmt) tab=255 vf=3 scope=253 type=3 proto=2 prio=0 0.0.0.0/0.0.0.0/0->192.168.91.0/32 pref=192.168.91.21 gwy=0.0.0.0 dev=6(mgmt) tab=255 vf=3 scope=254 type=2 proto=2 prio=0 0.0.0.0/0.0.0.0/0->192.168.91.21/32 pref=192.168.91.21 gwy=0.0.0.0 dev=6(mgmt) tab=255 vf=3 scope=253 type=3 proto=2 prio=0 0.0.0.0/0.0.0.0/0->192.168.91.255/32 pref=192.168.91.21 gwy=0.0.0.0 dev=6(mgmt) tab=254 vf=3 scope=0 type=1 proto=17 prio=0 0.0.0.0/0.0.0.0/0->0.0.0.0/0 pref=0.0.0.0 gwy=192.168.91.254 dev=6(mgmt)   // Independently managed default route tab=254 vf=3 scope=253 type=1 proto=2 prio=0 0.0.0.0/0.0.0.0/0->192.168.91.0/24 pref=192.168.91.21 gwy=0.0.0.0 dev=6(mgmt)   FGT101E_Master_379 # FGT101E_Master_379 # execute ping 192.168.91.254 PING 192.168.91.254 (192.168.91.254): 56 data bytes 64 bytes from 192.168.91.254: icmp_seq=0 ttl=255 time=0.3 ms 64 bytes from 192.168.91.254: icmp_seq=1 ttl=255 time=0.1 ms 64 bytes from 192.168.91.254: icmp_seq=2 ttl=255 time=0.1 ms 64 bytes from 192.168.91.254: icmp_seq=3 ttl=255 time=0.1 ms 64 bytes from 192.168.91.254: icmp_seq=4 ttl=255 time=0.1 ms   --- 192.168.91.254 ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max = 0.1/0.1/0.3 ms FGT101E_Master_379 #  FGT101E_Master_379 # diagnose sniffer packet any "host 192.168.91.254" 4 interfaces=[any] filters=[host 192.168.91.254] 3.235814 mgmt out 192.168.91.21 -> 192.168.91.254: icmp: echo request   //Match detailed direct route, ping data from mgmt out, you can successfully ping the gateway 3.235900 mgmt in 192.168.91.254 -> 192.168.91.21: icmp: echo reply 4.245672 mgmt out 192.168.91.21 -> 192.168.91.254: icmp: echo request 4.245747 mgmt in 192.168.91.254 -> 192.168.91.21: icmp: echo reply   Exit the lightweight vdom of the independent management port: FGT101E_Master_379 # FGT101E_Master_379 # execute enter <name>    vdom name vsys_hamgmt root   FGT101E_Master_379 # execute enter root  // Exit the lightweight independent management vdom and return to the root vdom (business VDOM) current vdom=root:0 FGT101E_Master_379 # get router info routing-table all  // The independent routing table of the business is completely independent from the independently managed routing table, which is equivalent to the lightweight isolation of routing. Routing table for VRF=0 Codes: K - kernel, C - connected, S - static, R - RIP, B - BGP        O - OSPF, IA - OSPF inter area        N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2        E1 - OSPF external type 1, E2 - OSPF external type 2        i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area        * - candidate default   S*      0.0.0.0/0 [1/0] via 202.100.1.192, wan1 C       101.100.1.0/24 is directly connected, wan2 C       192.168.10.0/24 is directly connected, port1 C       202.100.1.0/24 is directly connected, wan1   FGT101E_Master_379 # execute ping 192.168.91.254  // root ping 192.168.91.254 PING 192.168.91.254 (192.168.91.254): 56 data bytes   --- 192.168.91.254 ping statistics --- 5 packets transmitted, 0 packets received, 100% packet loss   FGT101E_Master_379 #  FGT101E_Master_379 # diagnose sniffer packet any "host 192.168.91.254 and icmp" 4 interfaces=[any] filters=[host 192.168.91.254 and icmp] 12.785835 wan1 out 202.100.1.21 -> 192.168.91.254: icmp: echo request  // The default route is matched, the ping data is out from wan1, and the independently managed gateway cannot be pinged. The result is correct, but it is not the result we want to. In an error state, it is not unreasonable, it just didn't enter vsys_hamgmt. 13.795618 wan1 out 202.100.1.21 -> 192.168.91.254: icmp: echo request 14.805621 wan1 out 202.100.1.21 -> 192.168.91.254: icmp: echo request 15.815615 wan1 out 202.100.1.21 -> 192.168.91.254: icmp: echo request 16.825621 wan1 out 202.100.1.21 -> 192.168.91.254: icmp: echo request

[Sathapon_SS]

Hi Kangming, 

CLI #execute enter vsys_hamgmt     It works for testing ping/telnet from mgmt interface that has been reserved for Management Interface Reservation. I don't know, Why this CLI didn't exist in the Fortinet KB? I asked TAC fortinet and He told me that cannot use the mgmt that has been set as Management Interface Reservation for testing ping/telnet. 

[AlexC-FTNT]

When you enable "set dedicated-to management" for an interface, this interface is automatically moved to a separate, hidden vdom, called vsys_mgmt. This interface will not be possibly added in routing (you can't change or add routes) or policies. You also can't ping it from the FortiGate itself. So yes, your test results are expected.

There is nothing to configure in this vdom either (so you can't change the routing in vsys_hamgmt). The purpose of dedicated to management is for out of band management, so you can't create a traffic loop within the FortiGate.
https://community.fortinet.com/t5/FortiGate/Technical-Note-How-to-dedicate-an-interface-to-managemen...