Fortinet white logo
Fortinet white logo

Administration Guide

Support cross-VRF local-in and local-out traffic for local services

Support cross-VRF local-in and local-out traffic for local services

When local-out traffic such as SD-WAN health checks, SNMP, syslog, and so on are initiated from an interface on one VRF and then pass through interfaces on another VRF, the reply traffic will be successfully forwarded back to the original VRF.

Example

In this example, there is an NPU VDOM link that is configured on the root VDOM. Two VLANs, vrf10 and vrf20, are created on either ends of the NPU VDOM link, each belonging to a different VRF.

When pinging from the vrf10 interface in VRF 10 to the destination server 172.16.202.2, since there is a single static route for VRF 10 with a gateway of vrf20/10.32.70.2, traffic is sent to the next hop and subsequently routed through port12 to the server.

As seen in the sniffer trace, the ICMP replies are received on port12 in VRF 20, then pass through vrf20, and are ultimately forwarded back to vrf10 in VRF 10. The traffic flow demonstrates that local-out traffic sourced from one VRF passing through another VRF can return back to the original VRF.

To configure cross-VRF local-out traffic for local services:
  1. Configure the interfaces:
    config system interface
        edit "vrf10"
            set vdom "root"
            set vrf 10
            set ip 10.32.70.1 255.255.255.0
            set allowaccess ping
            set device-identification enable
            set role lan
            set snmp-index 35
            set interface "npu0_vlink0"
            set vlanid 22
        next
        edit "vrf20"
            set vdom "root"
            set vrf 20
            set ip 10.32.70.2 255.255.255.0
            set allowaccess ping
            set device-identification enable
            set role lan
            set snmp-index 36
            set interface "npu0_vlink1"
            set vlanid 22
        next
        edit "port12"
            set vdom "root"
            set vrf 20
            set ip 172.16.202.1 255.255.255.0
            set allowaccess ping https ssh snmp http telnet fgfm radius-acct probe-response fabric ftm speed-test
            set type physical
            set alias "TO_FGT_D_port22"
            set snmp-index 14
            config ipv6
                set ip6-address 2003:172:16:202::1/64
                set ip6-allowaccess ping
            end
        next
    end
  2. Configure the firewall policy:
    config firewall policy
        edit 1
            set srcintf "vrf20"
            set dstintf "port12"
            set action accept
            set srcaddr "all"
            set dstaddr "all"
            set srcaddr6 "all"
            set dstaddr6 "all"
            set schedule "always"
            set service "ALL"
        next
    end
  3. Configure the static route:
    config router static
        edit 2
            set gateway 10.32.70.2
            set distance 3
            set device "vrf10"
        next
    end
To test the configuration:
  1. Execute a ping from the vrf10 interface in VRF 10 to the destination server (172.16.202.2):
    # execute ping-options interface vrf10
    # execute ping 172.16.202.2
    PING 172.16.202.2 (172.16.202.2): 56 data bytes
    64 bytes from 172.16.202.2: icmp_seq=0 ttl=254 time=0.1 ms
    64 bytes from 172.16.202.2: icmp_seq=1 ttl=254 time=0.0 ms
    
    --- 172.16.202.2 ping statistics ---
    2 packets transmitted, 2 packets received, 0% packet loss
    round-trip min/avg/max = 0.0/0.0/0.1 ms
    
  2. Run a sniffer trace on 172.16.202.2 for ICMP:
    # diagnose sniffer packet any "host 172.16.202.2 and icmp" 4
    interfaces=[any]
    filters=[host 172.16.202.2 and icmp]
    3.393920 vrf10 out 10.32.70.1 -> 172.16.202.2: icmp: echo request
    3.393922 npu0_vlink0 out 10.32.70.1 -> 172.16.202.2: icmp: echo request
    3.393927 vrf20 in 10.32.70.1 -> 172.16.202.2: icmp: echo request
    3.393943 port12 out 10.32.70.1 -> 172.16.202.2: icmp: echo request
    3.393977 port12 in 172.16.202.2 -> 10.32.70.1: icmp: echo reply
    3.393987 vrf20 out 172.16.202.2 -> 10.32.70.1: icmp: echo reply
    3.393988 npu0_vlink1 out 172.16.202.2 -> 10.32.70.1: icmp: echo reply
    3.393993 vrf10 in 172.16.202.2 -> 10.32.70.1: icmp: echo reply
    4.393941 vrf10 out 10.32.70.1 -> 172.16.202.2: icmp: echo request
    4.393942 npu0_vlink0 out 10.32.70.1 -> 172.16.202.2: icmp: echo request
    4.393948 vrf20 in 10.32.70.1 -> 172.16.202.2: icmp: echo request
    4.393957 port12 out 10.32.70.1 -> 172.16.202.2: icmp: echo request
    4.393980 port12 in 172.16.202.2 -> 10.32.70.1: icmp: echo reply
    4.393987 vrf20 out 172.16.202.2 -> 10.32.70.1: icmp: echo reply
    4.393987 npu0_vlink1 out 172.16.202.2 -> 10.32.70.1: icmp: echo reply
    4.393994 vrf10 in 172.16.202.2 -> 10.32.70.1: icmp: echo reply

Support cross-VRF local-in and local-out traffic for local services

Support cross-VRF local-in and local-out traffic for local services

When local-out traffic such as SD-WAN health checks, SNMP, syslog, and so on are initiated from an interface on one VRF and then pass through interfaces on another VRF, the reply traffic will be successfully forwarded back to the original VRF.

Example

In this example, there is an NPU VDOM link that is configured on the root VDOM. Two VLANs, vrf10 and vrf20, are created on either ends of the NPU VDOM link, each belonging to a different VRF.

When pinging from the vrf10 interface in VRF 10 to the destination server 172.16.202.2, since there is a single static route for VRF 10 with a gateway of vrf20/10.32.70.2, traffic is sent to the next hop and subsequently routed through port12 to the server.

As seen in the sniffer trace, the ICMP replies are received on port12 in VRF 20, then pass through vrf20, and are ultimately forwarded back to vrf10 in VRF 10. The traffic flow demonstrates that local-out traffic sourced from one VRF passing through another VRF can return back to the original VRF.

To configure cross-VRF local-out traffic for local services:
  1. Configure the interfaces:
    config system interface
        edit "vrf10"
            set vdom "root"
            set vrf 10
            set ip 10.32.70.1 255.255.255.0
            set allowaccess ping
            set device-identification enable
            set role lan
            set snmp-index 35
            set interface "npu0_vlink0"
            set vlanid 22
        next
        edit "vrf20"
            set vdom "root"
            set vrf 20
            set ip 10.32.70.2 255.255.255.0
            set allowaccess ping
            set device-identification enable
            set role lan
            set snmp-index 36
            set interface "npu0_vlink1"
            set vlanid 22
        next
        edit "port12"
            set vdom "root"
            set vrf 20
            set ip 172.16.202.1 255.255.255.0
            set allowaccess ping https ssh snmp http telnet fgfm radius-acct probe-response fabric ftm speed-test
            set type physical
            set alias "TO_FGT_D_port22"
            set snmp-index 14
            config ipv6
                set ip6-address 2003:172:16:202::1/64
                set ip6-allowaccess ping
            end
        next
    end
  2. Configure the firewall policy:
    config firewall policy
        edit 1
            set srcintf "vrf20"
            set dstintf "port12"
            set action accept
            set srcaddr "all"
            set dstaddr "all"
            set srcaddr6 "all"
            set dstaddr6 "all"
            set schedule "always"
            set service "ALL"
        next
    end
  3. Configure the static route:
    config router static
        edit 2
            set gateway 10.32.70.2
            set distance 3
            set device "vrf10"
        next
    end
To test the configuration:
  1. Execute a ping from the vrf10 interface in VRF 10 to the destination server (172.16.202.2):
    # execute ping-options interface vrf10
    # execute ping 172.16.202.2
    PING 172.16.202.2 (172.16.202.2): 56 data bytes
    64 bytes from 172.16.202.2: icmp_seq=0 ttl=254 time=0.1 ms
    64 bytes from 172.16.202.2: icmp_seq=1 ttl=254 time=0.0 ms
    
    --- 172.16.202.2 ping statistics ---
    2 packets transmitted, 2 packets received, 0% packet loss
    round-trip min/avg/max = 0.0/0.0/0.1 ms
    
  2. Run a sniffer trace on 172.16.202.2 for ICMP:
    # diagnose sniffer packet any "host 172.16.202.2 and icmp" 4
    interfaces=[any]
    filters=[host 172.16.202.2 and icmp]
    3.393920 vrf10 out 10.32.70.1 -> 172.16.202.2: icmp: echo request
    3.393922 npu0_vlink0 out 10.32.70.1 -> 172.16.202.2: icmp: echo request
    3.393927 vrf20 in 10.32.70.1 -> 172.16.202.2: icmp: echo request
    3.393943 port12 out 10.32.70.1 -> 172.16.202.2: icmp: echo request
    3.393977 port12 in 172.16.202.2 -> 10.32.70.1: icmp: echo reply
    3.393987 vrf20 out 172.16.202.2 -> 10.32.70.1: icmp: echo reply
    3.393988 npu0_vlink1 out 172.16.202.2 -> 10.32.70.1: icmp: echo reply
    3.393993 vrf10 in 172.16.202.2 -> 10.32.70.1: icmp: echo reply
    4.393941 vrf10 out 10.32.70.1 -> 172.16.202.2: icmp: echo request
    4.393942 npu0_vlink0 out 10.32.70.1 -> 172.16.202.2: icmp: echo request
    4.393948 vrf20 in 10.32.70.1 -> 172.16.202.2: icmp: echo request
    4.393957 port12 out 10.32.70.1 -> 172.16.202.2: icmp: echo request
    4.393980 port12 in 172.16.202.2 -> 10.32.70.1: icmp: echo reply
    4.393987 vrf20 out 172.16.202.2 -> 10.32.70.1: icmp: echo reply
    4.393987 npu0_vlink1 out 172.16.202.2 -> 10.32.70.1: icmp: echo reply
    4.393994 vrf10 in 172.16.202.2 -> 10.32.70.1: icmp: echo reply