Let me first say that these two features are supposed to do very similar things – they are designed to separate access users so their traffic cannot go directly between them without any control. The firs possible solution is a port-isolate command which separates L2 and L3 traffic between the isolated (access) ports. This leads to complete separation with all the advantages and disadvantages. The biggest disadvantage is that all traffic trunked up to another switch where it will be dealt with – usually it will be routed. As the separation is also on L2 and L3 you cannot use arp proxy which could resolve the overhead on access switch. The advantage is that the separation is absolute which could be quite useful in ISP’s access networks.
So how does one configure this feature? Port isolate config is very straight forward but there are small differences among the switch types. But I will cover the config in one more complex example.
The steps are:
- create port isolate group in system-view
- add the appropriate port range to the wanted group
# … # port-isolate group 2 description port-isolate-2/0/1-to-2/0/12 # port-isolate group 3 description port-isolate-3/0/1-to-3/0/12 # interface Ethernet2/0/1 . port isolate group 2 #
What is configured here is done on S6500 and those are two groups which ports are separated internally inside the group so as the groups should be separated among each other. It is very good idea to put some description of ports which actually belong to the the group especially on switches with higher density of ports. Adding the port to a port-isolate group can be done either directly from the port-isolate group by command “port” followed by defining the range or from the interface itself by “port isolate group X” where the X is the number of the group. If you are thinking why there are two groups the answer is simple as S6500 can contain multiple card-blades the group can be configured only within one card so if you want to have all users separated like this you need to have at least the same number of groups as you have cards. Adding of the ports to the port group should be available on all series of switches but has meaning only on multiple-blade chassis types. There is one small warning about this feature especially on S6500 and S7800 I had encountered some sw releases which were not maintaining the separation among groups so be careful when testing.
As you can see it is very simple config. So now is tome to have a look on Mac Forced Forwarding (abbreviation in Huawei papers is MFF but on Wikipedia and some other sources you will find it under MACFF). MFF is a standard adopted by IETF under rfc4562 and it is a very interesting bud a bit long reading.
MFF is L2 isolation and broadcast suppression method which uses arp-reply (so as arp-proxy does) to divert traffic from direct access switch – to – access switch communication to access switch – diverted L3 interface – access switch. The mechanism how to recognize the clients on the access switches is via DHCP-snooping mechanism. So for proper function you really need DHCP server running in the network. MFF is also dependent on few other things (as you will see from the config).
MFF on Huawei equipment has two modes “manual” and “automatic” so the last (and really automated mode defined by rfc) is missing. And also defines user (facing) port, network (facing) port and the MFF gateway. Using the manual mode is a workaround for networks which does not have DHCP so you can actually use MFF there but there is one really important thing – you will have to configure absolutely everything manually – all the bindings MAC/IPs/Gateways which is not really user friendly (I guess that this would drive anyone configuring it crazy in less than 20 PC network).
The automatic mode is not so automatic as it could look like but it is much more convenient yet with excessive control about what is happening.
So let’s have a look at the config of this second mode.
step No.1 is to define on which vlan you want to enable the feature, set the default gateway (L3 interface which will provide the arp-reply feature) and the DHCP server (MFF server). The arp-detection feature is a protection against arp-spoofing attacks and MFF will not work without it enabled.
# vlan 30 description MFF_test arp detection enable arp mac-forced-forwarding default-gateway 10.30.0.254 arp mac-forced-forwarding server 10.0.0.1 #
If you want to use MFF without vlans just do this config on VLAN1.
Step No2. is to determine and configure the network and user ports.
# interface Ethernet1/0/1 port link-type trunk undo port trunk permit vlan 1 port trunk permit vlan 10 20 30 dhcp-snooping trust arp detection trust arp mac-forced-forwarding network-port #
The key line in the above config is arp detection trust which defines this port as network port as it should trust whatever it learns from arp.
So now the config of the user port
# interface Ethernet1/0/11 port link-type trunk undo port trunk permit vlan 1 port trunk permit vlan 10 20 30 port trunk pvid vlan 30 ip check source ip-address mac-address arp mac-forced-forwarding user-port #
In this config I used a small glitch instead using proper access port I used trunk with tagging of untagged traffic and thus effectively making it trunk and access at the same time. But for MFF it doesn’t matter as the only important line is ip check source ip-address (and optionally) mac-address.
MFF requires this command so the switches can check the client’s traffic according to it’s DHCP snooping table.
So the last step is (as we are using the DHCP snooping) to enable the DHCP snooping globally.
# dhcp-snooping #
And yes that is all, your MFF should be working. You can also define some options for the snooping (like opt82 I was writing about before).
To verify your MFF config and state you can use these two commands:
display arp mac-forced-forwarding interface
and
display arp mac-forced-forwarding vlan
What does MFF do and what does it not. MFF does not solve L2 isolation among clients. For that is needed to use it with combination with port-isolate feature.
As far as I know MFF is available on VRP310-F1701L05 for S3900 but hopefully with later releases especially of VRp 5.X it will be generally available.
If there will be somebody interested in more details and/or packet exchanges flow let me know in comments and I can explain it or write separate article about it.