{"id":154,"date":"2018-01-07T20:38:23","date_gmt":"2018-01-07T20:38:23","guid":{"rendered":"https:\/\/www.kuncar.net\/blog\/?p=154"},"modified":"2018-01-07T20:45:10","modified_gmt":"2018-01-07T20:45:10","slug":"port-isolate-vs-mac-forced-forwarding","status":"publish","type":"post","link":"https:\/\/www.kuncar.net\/blog\/2018\/port-isolate-vs-mac-forced-forwarding\/","title":{"rendered":"Port isolate vs. Mac Forced Forwarding"},"content":{"rendered":"
\n

\"\"Let me first say that these two features are supposed to do very similar things \u2013 they are designed to separate access users so their traffic cannot go directly between them without any control.\u00a0The 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.<\/span><\/p>\n

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.<\/span><\/p>\n

The steps are:<\/span><\/p>\n

    \n
  1. create port isolate group in system-view<\/span><\/li>\n
  2. add the appropriate port range to the wanted group<\/span><\/li>\n<\/ol>\n
    #<\/span><\/em>\r\n\u2026<\/span><\/em>\r\n#<\/span><\/em>\r\nport-isolate group 2<\/span><\/em>\r\ndescription port-isolate-2\/0\/1-to-2\/0\/12<\/span><\/em>\r\n#<\/span><\/em>\r\nport-isolate group 3<\/span><\/em>\r\ndescription port-isolate-3\/0\/1-to-3\/0\/12<\/span><\/em>\r\n#<\/span><\/em>\r\ninterface Ethernet2\/0\/1<\/span><\/em>\r\n.<\/span><\/em>\r\nport isolate group 2<\/span><\/em>\r\n#<\/span><\/em><\/pre>\n
    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 \u201cport<\/em>\u201d followed by defining the range or from the interface itself by \u201cport isolate group X<\/em>\u201d where the X is the number of the group.\u00a0<\/span>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.\u00a0<\/span>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.\u00a0<\/span>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.<\/span><\/p>\n
    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\u00a0MACFF<\/a>). MFF is a standard adopted by IETF under\u00a0rfc4562<\/a>\u00a0and it is a very interesting bud a bit long reading.<\/span><\/p>\n
    MFF is L2 isolation and broadcast suppression method which uses arp-reply (so as arp-proxy does) to divert traffic from direct access switch \u2013 to \u2013 access switch communication to access switch \u2013 diverted L3 interface \u2013 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).<\/span><\/p>\n
    MFF on Huawei equipment has two modes \u201cmanual\u201d and \u201cautomatic\u201d \u00a0so the last (and really automated mode defined by rfc) is missing. \u00a0And also defines user (facing) port, network (facing) port and the MFF gateway.\u00a0<\/span>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 \u2013 you will have to configure absolutely everything manually \u2013 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).<\/span><\/p>\n
    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.<\/span><\/p>\n
    So let\u2019s have a look at the config of this second mode.<\/span><\/p>\n
    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.<\/span><\/p>\n
    #<\/span><\/em>\r\nvlan 30<\/span><\/em>\r\ndescription MFF_test<\/span><\/em>\r\narp detection enable<\/span><\/em>\r\narp mac-forced-forwarding default-gateway 10.30.0.254<\/span><\/em>\r\narp mac-forced-forwarding server 10.0.0.1<\/span><\/em>\r\n#<\/span><\/em><\/pre>\n
    If you want to use MFF without vlans just do this config on VLAN1.<\/span><\/p>\n
    Step No2. is to determine and configure the network and user ports.<\/span><\/p>\n
    #<\/span><\/em>\r\ninterface Ethernet1\/0\/1<\/span><\/em>\r\nport link-type trunk<\/span><\/em>\r\nundo port trunk permit vlan 1<\/span><\/em>\r\nport trunk permit vlan 10 20 30<\/span><\/em>\r\ndhcp-snooping trust<\/span><\/em>\r\narp detection trust<\/span><\/em>\r\narp mac-forced-forwarding network-port<\/span><\/em>\r\n#<\/span><\/em><\/pre>\n
    The key line in the above config is\u00a0arp detection trust which defines this port as network port as it should trust whatever it learns from arp.<\/span><\/p>\n
    So now the config of the user port<\/span><\/p>\n
    #<\/span><\/em><\/span>\r\ninterface Ethernet1\/0\/11<\/span><\/em><\/span>\r\nport link-type trunk<\/span><\/em><\/span>\r\nundo port trunk permit vlan 1<\/span><\/em><\/span>\r\nport trunk permit vlan 10 20 30<\/span><\/em><\/span>\r\nport trunk pvid vlan 30<\/span><\/em><\/span>\r\nip check source ip-address mac-address<\/span><\/em><\/span>\r\narp mac-forced-forwarding user-port<\/span><\/em><\/span>\r\n#<\/span><\/em><\/span><\/pre>\n
    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\u2019t matter as the only important line is ip check source ip-address \u00a0(and optionally) mac-address.<\/span><\/p>\n
    MFF requires this command so the switches can check the client\u2019s traffic according to it\u2019s DHCP snooping table.<\/span><\/p>\n
    So the last step is (as we are using the DHCP snooping) to enable the DHCP snooping globally.<\/span><\/p>\n
    #<\/span><\/em>\r\ndhcp-snooping<\/span><\/em>\r\n#<\/span><\/em><\/pre>\n
    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).<\/span><\/p>\n
    To verify your MFF config and state you can use these two commands:<\/span><\/p>\n
    display arp mac-forced-forwarding interface<\/span>
    \nand<\/span>
    \ndisplay arp mac-forced-forwarding vlan<\/span><\/p><\/blockquote>\n
    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.<\/span><\/p>\n
    As \u00a0far 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.<\/span><\/p>\n
    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.<\/span><\/p>\n<\/div>\n","protected":false},"excerpt":{"rendered":"
    Let me first say that these two features are supposed to do very similar things \u2013 they are designed to separate access users so their traffic cannot go directly between them without any control.\u00a0The firs possible solution is a port-isolate command which separates L2 and L3 traffic between the isolated (access) ports. This leads to … <\/p>\n
    Continue reading “Port isolate vs. Mac Forced Forwarding”<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[8,5,13],"tags":[],"class_list":["post-154","post","type-post","status-publish","format-standard","hentry","category-huawei","category-networks","category-recovered"],"_links":{"self":[{"href":"https:\/\/www.kuncar.net\/blog\/wp-json\/wp\/v2\/posts\/154","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.kuncar.net\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.kuncar.net\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.kuncar.net\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.kuncar.net\/blog\/wp-json\/wp\/v2\/comments?post=154"}],"version-history":[{"count":1,"href":"https:\/\/www.kuncar.net\/blog\/wp-json\/wp\/v2\/posts\/154\/revisions"}],"predecessor-version":[{"id":155,"href":"https:\/\/www.kuncar.net\/blog\/wp-json\/wp\/v2\/posts\/154\/revisions\/155"}],"wp:attachment":[{"href":"https:\/\/www.kuncar.net\/blog\/wp-json\/wp\/v2\/media?parent=154"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.kuncar.net\/blog\/wp-json\/wp\/v2\/categories?post=154"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.kuncar.net\/blog\/wp-json\/wp\/v2\/tags?post=154"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}