search

F5Networks / f5-declarative-onboarding

F5 BIG-IP Declarative Onboarding
Apache License 2.0
58 stars 22 forks source link

tmsh modify cm traffic-group <traffic-group-name> mac <MAC-address> #174

Open jackyatesaustin opened 3 years ago

jackyatesaustin commented 3 years ago

Is your feature request related to a problem? Please describe.

Not currently available via DO

Describe the solution you'd like

To be made available via DO

Describe alternatives you've considered

N/A

dstokesf5 commented 3 years ago

@jackyatesaustin, can you elaborate on your use case here? If you need to do MAC masquerading, you can already do that with DO: https://clouddocs.f5.com/products/extensions/f5-declarative-onboarding/latest/bigip-examples.html?highlight=masquerade#configuring-mac-masquerading-on-traffic-groups

jackyatesaustin commented 3 years ago

@dstokesf5 can you provide an example of how I can configure the MAC address?

I can't figure out how to define the MAC address from the link you provided (or in the schema).

"myMac": { "class": "MAC_Masquerade", "source": { "interface": "1.1" }, "trafficGroup": "traffic-group-1" }

jackyatesaustin commented 3 years ago

I'm looking for something akin to the following example. Thanks!

"traffic-group-1": { "class": "TrafficGroup", "mac-address": "mac-address" },

samualblair commented 2 years ago

I would second this request. Unless I am missing something it would seem that using a real interface to 'source' the MAC address has limitations.

For example if device A has interface 1.1 with MAC AA:AA:AA:AA:AA:AA and Device B has MAC BB:BB:BB:BB:BB:BB , then the current syntax only allows DO to configure the MAC_Masquerade as a value of AA:AA:AA:AA:AA:AA or BB:BB:BB:BB:BB:BB , conflicting with a local MAC.

This would mean if say MAC_Masquerade is set on Device A to 1.1 (so AA:AA:AA:AA:AA:AA) and not Device B, sync will ensure device B also uses MAC_Masquerade (so AA:AA:AA:AA:AA:AA). But when Device B becomes active for traffic and starts using the MAC AA:AA:AA:AA:AA:AA this conflicts with Device A. So if device A was to try and send monitors out that interface they would fail (as they would be returning to device B not device A).

Ideally we would want to set the MAC value, so we could specify CC:CC:CC:CC:CC:CC , then whichever device is active it would not matter, both devices could still use local MAC's for monitoring of servers.

Am I missing something or is this not the problem, and the reason for the enhancement request?

samualblair commented 2 years ago

As a workaround for now I have found that I can use an unused interface (such as 1.2) and the MAC address then used by MAC_Masquerade does not conflict with Device A or Device B's physical MAC on interface 1.1

This workaround has a limitation though, it requires I have an unused port to call upon for the MAC address. At least an unused port as far as TMM is concerned, so I considered using the MGMT port as source for MAC address, but it does not appear to be supported (errors that interface mgmt is not found). I have some devices that are VM's on VMware and are using the maximum number of ports available (10 vNICs, so 9 data VLANs). For these I am not able to provision an 'unused' interface.

For other devices I can provision an unused interface, 4 vNICs for say 3 data VLANs, I can provision a 5th vNIC and just use it for the MAC source. But this is much less clean than just configuring a MAC address instead of source interface in DO (which just converts the source interface reference to a MAC anyway in the TMSH running configuration).

mdditt2000 commented 1 month ago

Created AUTOTOOL-4467. Added to sprint 43-1 scheduled for end of September