Set MAC address of a VLAN interface

[Adrian_Lewis]

Hi,

AFAIK, you can only set the MAC address of a physical interface to something custom but not that of a VLAN interface. There is a setting called 'set subst enable' and 'set substitute-dst-mac XX:XX:XX:XX:XX:XX' on the 'conf sys int' branch for a VLAN interface but I can't quite gather what it does. Every time I try to use it and put in a MAC address the config just ignores it and so it does nothing at all.

The problem I'm facing is that I'm trying to assign VLAN interfaces to VDOMs on a single physical port but when I do this, they all have the same MAC address. In this particular situation, I need each VLAN interface to have a unique MAC address as they are being bridged by another device so that they can exist on the same subnet.

I know there are other solutions to this issue but if anyone knows what the subst settings are supposed to do, I'd be interested in knowing. The CLI guide says very little about this and there doesn't appear to be anything in the KB about this setting. If the 'set subst*' commands might help, I'll try to work out why they're not working for me.

Adrian

[Paul_Dean]

Hi Adrian,

is this what you are looking for? It seems you can create entries in a substitute table when using transparent VDOMs.

http://docs-legacy.fortin...fig_system.24.039.html

[ede_pfau]

VLANs are inheriting the MAC address of their parent interface, according to the documentation. Having the "subst" command available in a VLAN section is an oversight IMHO.

Technically, if each VLAN had it's own MAC address (which? it's got to be unique worldwide) then the FGT would have to expand it's ARP handling a lot. Suggestion: use the physical interface's MAC but use the VLAN ID as the last 2 bytes (there are 4096 IDs possible = 14 bits).

Nothing too complicated but apparently not of frequent use in the real world.

This would then be a candidate for a feature request.

[Adrian_Lewis]

ede_pfau wrote:
use the VLAN ID as the last 2 bytes

Or do what is already done for HA MAC addresses and use the interface index with some other element to create a unique address for that LAN segment (doesn't have to be globally unique). This automatic creation of the MAC address is additional however - simply giving the option to change it manually would be a good start. For 99% of use cases, having a VLAN tag on a frame puts it into a different segment from the physical interface or any other differently VLAN tagged frame but in some cases this can't be assumed.

Paul: Thanks but this is not a transparent mode thing (unless that is what the subst enable and substitute-dst-mac options are for).

Has anyone used this command in the past and had any useful outcome? e.g:

config system interface
    edit "wan1.vlan20"
        set vdom "root"
        set subst enable

        set substitute-dst-mac 00:09:0f:aa:bb:cc
        set snmp-index 7
        set interface "wan1"
        set vlanid 20
    next
end

Every time I try this to see what it does, the 'set substitute-dst-mac 00:09:0f:aa:bb:cc' part seems to be ignored completely with no warning or error message.

The best solution of course would be to allow interfaces on different VDOMs to be connected to the same L2 domain, be that a physical interface or the same VLAN ID. Can't see that happening soon though. The only solution at present that I can think of is to use a transparent mode vdom and ethernet style inter-vdom links but this reduces the VDOM license count, doubles the session count on a physical box, and makes vclusters far less flexible.

Hmm. Not happy.

[Adrian_Lewis]

Managed to come up with a sort of L3 bridge instead. Each VLAN interface on the connected router uses IP unnumbered links, borrowing the IP from a loopback address. Each VLAN interface on the router does proxy arp and so devices can also communicate from VDOM to VDOM. Actually works very well and solves the whole 'use a transparent VDOM' issue when trying to put multiple VDOMs onto a single subnet. Gives me much better control of the separation between customers as well despite the fact that they're on the same IP subnet.

Happy now.