MGMT port and last hop

Hi ktstyle,

 

 

The mgmt port does not support Auto Last Hop because the mgmt port is controlled by the Linux kernel, and not the Traffic Management Microkernel (TMM), which essentially manages all of the switch interfaces. Also, the Linux kernel typically uses a separate default gateway than TMM and thus maintains a separate routing table for this purpose, aka "Management Routes". It is possible to use the "arp" command to create static ARP entries for the Linux kernel, and it is also possible to edit the kernel's routing table if for some reason ClusterXL VMAC is causing issues here:

 

 

SOL3669: Overview of management interface routing (9.x - 10.x)

 

https://support.f5.com/kb/en-us/solutions/public/3000/600/sol3669.html?sr=25931722

 

 

If you desire to take packet captures of your mgmt interface to help determine root cause of your icmp issue, use the following syntax on the BIG-IP as the root user:

 

To save a .cap file for Wireshark

 

tcpdump -ni eth0 -s0 host -w /var/tmp/mgmt_1.cap

 

To use STDOUT to troubleshoot ping

 

tcpdump -ni eth0 -e -s0 "host and (icmp or arp)"

 

 

Cheers,

 

Dr. W

I should have elaborated the syntax as follows:

 

 

To save a .cap file for Wireshark

 

tcpdump -ni eth0 -s0 host -w /var/tmp/mgmt_1.cap

 

To use STDOUT to troubleshoot ping

 

tcpdump -ni eth0 -e -s0 "host and (icmp or arp)"

Odd, the forum editor is not allowing text between angled brackets. Third time is the charm I guess! Substitute your management IP below for "mgmt.ip.addr"

 

 

To save a .cap file for Wireshark

 

tcpdump -ni eth0 -s0 host mgmt.ip.addr -w /var/tmp/mgmt_1.cap

 

To use STDOUT to troubleshoot ping

 

tcpdump -ni eth0 -e -s0 "host mgmt.ip.addr and (icmp or arp)"

What mode are you running your clusterxl in? And are you running ipso or splat?

 

 

H

Thank you!

 

 

Sorry for the late reply. I see really problem for VMAC and MGMT interface.

 

This APR table on the switch:

 

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

 

IP ARP

 

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

 

IP Address Age (min) MAC Address VLAN-Unit/Port/Trunk Flags

 

 

-------------------------------------------------------------------------------

 

172.16.1.255 0 ff:ff:ff:ff:ff:ff VLAN129 LB

 

172.16.1.254 306 00:1c:7f:01:e0:66 VLAN129-37 D

 

172.16.1.253 357 00:1c:7f:32:4d:b5 VLAN129-38 D

 

172.16.1.252 270 00:1c:7f:32:4d:4d VLAN129-37 D

 

172.16.1.0 0 ff:ff:ff:ff:ff:ff VLAN129 LB

 

Total ARP entries : 15

 

-------------------------------------------------------------------------------

 

Flags Legend:

 

S=Static, D=Dynamic, L=Local, B=Broadcast

 

 

It's in Wireshark:

 

No. Time Source Destination Protocol Length Info

 

5 4.352158 10.133.150.1 172.16.1.21 ICMP 74 Echo (ping) request id=0x0010, seq=7107/49947, ttl=124

 

 

Frame 5: 74 bytes on wire (592 bits), 74 bytes captured (592 bits)

 

Ethernet II, Src: CheckPoi_32:4d:4d (00:1c:7f:32:4d:4d), Dst: F5Networ_3e:3c:81 (00:23:e9:3e:3c:81)

 

Internet Protocol Version 4, Src: 10.133.150.1 (10.133.150.1), Dst: 172.16.1.21 (172.16.1.21)

 

Internet Control Message Protocol

 

 

No. Time Source Destination Protocol Length Info

 

6 4.352185 172.16.1.21 10.133.150.1 ICMP 74 Echo (ping) reply id=0x0010, seq=7107/49947, ttl=64

 

 

Frame 6: 74 bytes on wire (592 bits), 74 bytes captured (592 bits)

 

Ethernet II, Src: F5Networ_3e:3c:81 (00:23:e9:3e:3c:81), Dst: CheckPoi_32:4d:4d (00:1c:7f:32:4d:4d)

 

Internet Protocol Version 4, Src: 172.16.1.21 (172.16.1.21), Dst: 10.133.150.1 (10.133.150.1)

 

Internet Control Message Protocol

 

 

 

You can see BIG-IP sent packets to physically address, but must send to VMAC, because 172.16.1.254 has VMAC mac address.

 

 

I used Checpoint GAIA 75.45 in ClusterXL with virtual IP and VMAC.

 

 

 

 

Correct me if I'm wrong but the IP used in the PING is 10.133.150.1, so I assume the CP is not on the local mgmt subnet? Please clarify the which IPs and which MACs are which.

172.16.1.254 306 00:1c:7f:01:e0:66 VLAN129-37 D VMAC

 

172.16.1.253 357 00:1c:7f:32:4d:b5 VLAN129-38 D REALMAC for NODE2 checkpoint

 

172.16.1.252 270 00:1c:7f:32:4d:4d VLAN129-37 D REALMAC for NODE1 checkpoint

 

NET MGMT 172.16.1.0/24

 

 

10.133.150.1 it's laptop from i ping MGMT interface. Same situation when i try ping from interface checkpoint:

 

No. Time Source Destination Protocol Length Info

 

5 2.909866 172.16.1.254 172.16.1.21 ICMP 98 Echo (ping) request id=0x28a2, seq=1/256, ttl=64

 

 

Frame 5: 98 bytes on wire (784 bits), 98 bytes captured (784 bits)

 

Ethernet II, Src: CheckPoi_32:4d:4d (00:1c:7f:32:4d:4d), Dst: F5Networ_3e:3c:81 (00:23:e9:3e:3c:81)

 

Internet Protocol Version 4, Src: 172.16.1.254 (172.16.1.254), Dst: 172.16.1.21 (172.16.1.21)

 

Internet Control Message Protocol

 

 

No. Time Source Destination Protocol Length Info

 

6 2.909929 172.16.1.21 172.16.1.254 ICMP 98 Echo (ping) reply id=0x28a2, seq=1/256, ttl=64

 

 

Frame 6: 98 bytes on wire (784 bits), 98 bytes captured (784 bits)

 

Ethernet II, Src: F5Networ_3e:3c:81 (00:23:e9:3e:3c:81), Dst: CheckPoi_32:4d:4d (00:1c:7f:32:4d:4d)

 

Internet Protocol Version 4, Src: 172.16.1.21 (172.16.1.21), Dst: 172.16.1.254 (172.16.1.254)

 

Internet Control Message Protocol

 

 

OK, thanks. It seems to me that the issue is with the CP. It's not using the VMAC from what I can see. I take it the laptop PING went through the CP too. In both cases the VMAC is not used as the source MAC. I'd take a closer look at your CP configuration.

CP not use VMAC in request - it's normal for CP. Why F5 sent reply to Physical MAC address if in it ARP table has recordr 172.16.1.254 with VMAC?

 

What exactly are you interested in the configuration CP?