Fortinet black logo

Administration Guide

Copying the DSCP value from the session original direction to its reply direction

Copying the DSCP value from the session original direction to its reply direction

In an SD-WAN scenario when DSCP tags are used to mark traffic from the spoke to the hub, it is sometimes desirable for the hub to mark the reply traffic with the same DSSP tags. The diffserv-copy setting in firewall policy configurations allows the DSCP tag to be copied to the reply direction.

config firewall policy
    edit <id>
        set diffserv-copy {enable | disable}
    next
end

Example

The use cases in this example are for a hub and spoke SD-WAN deployment. Traffic from the spoke (either real traffic or SLA health check probes) can be marked with a certain DSCP tag when leaving the spoke. QoS may be applied by an upstream device based on the DSCP tag. When the traffic arrives on the hub, the hub may also want to mark the reply traffic to the spoke with the same DSCP tag. This would allow QoS to be applied to the traffic in the reply direction as well, which is traffic in the hub to spoke direction associated with the same session in the spoke to hub direction.

While this topology simplifies the SD-WAN deployment into a single hub and spoke, this feature applies to the following configurations:

  • Multiple spokes (branch sites)
  • One or more hubs (data center sites)
  • Multiple overlays connecting spokes to hubs
  • SD-WAN configured on spokes to pick the best overlay

Use case 1: typical forwarding traffic

Traffic originates from the spoke and is destined for a server behind the hub. The spoke marks the traffic with a DSCP tag of 101010. This is done by enabling diffserv-foward on the spoke firewall policy. It can also be accomplished by enabling dscp-forward in an SD-WAN rule.

The hub allows the traffic in through a firewall policy. By enabling diffserv-copy on the firewall policy, it will mark the reply traffic on the corresponding sessions with the same DSCP tag in which it came.

To configure the FortiGates:
  1. Configure the firewall policy on the spoke (FortiGate A):

    config firewall policy
        edit 1
            set srcintf "port1"
            set dstintf "virtual-wan-link"
            set action accept
            set srcaddr "all"
            set dstaddr "all"
            set srcaddr6 "all6"
            set dstaddr6 "all6"
            set schedule "always"
            set service "ALL"
            set logtraffic all
            set nat enable
            set diffserv-forward enable
            set diffservcode-forward 101010
        next
    end
  2. Configure the firewall policy on the hub (FortiGate B):

    config firewall policy
        edit 3
            set srcintf "virtual-wan-link"
            set dstintf "wan1"
            set action accept
            set srcaddr "all"
            set dstaddr "all"
            set srcaddr6 "all"
            set dstaddr6 "all"
            set schedule "always"
            set service "ALL"
            set logtraffic all
            set auto-asic-offload disable
            set nat enable
            set diffserv-copy enable
        next
    end
To test the configuration:
  1. Generate some forwarding traffic.

  2. Verify that the session’s tos value from the original direction is applied to the reply direction:

    # diagnose sys session filter policy 3
    # diagnose sys session filter dst 172.16.200.55
    # diagnose sys session list
    
    session info: proto=1 proto_state=00 duration=35 expire=59 timeout=0 flags=00000000 socktype=0 sockport=0 av_idx=0 use=3
    origin-shaper=
    reply-shaper=
    per_ip_shaper=
    class_id=0 ha_id=0 policy_dir=0 tunnel=/ vlan_cos=0/255
    state=log may_dirty f00 
    statistic(bytes/packets/allow_err): org=3024/36/1 reply=3024/36/1 tuples=2
    tx speed(Bps/kbps): 82/0 rx speed(Bps/kbps): 82/0
    orgin->sink: org pre->post, reply pre->post dev=20->17/17->20 gwy=172.16.200.55/10.2.2.1
    hook=post dir=org act=snat 10.2.2.1:25290->172.16.200.55:8(172.16.200.2:25290)
    hook=pre dir=reply act=dnat 172.16.200.55:25290->172.16.200.2:0(10.2.2.1:25290)
    misc=0 policy_id=3 pol_uuid_idx=1097 auth_info=0 chk_client_info=0 vd=3
    serial=0000a018 tos=6a/6a app_list=0 app=0 url_cat=0
    rpdb_link_id=00000000 ngfwid=n/a
    npu_state=0x4000001 no_offload
    no_ofld_reason:  disabled-by-policy
    total session 1

Use case 2: local-in traffic destined to a loopback interface

SLA health checks from the spoke are destined for a loopback interface on the hub. The health check is marked with a DSCP tag of 000001 by the spoke. When the hub receives the probes to its loopback, it will mark the replies with the same DSCP tags in which it came.

To configure the FortiGates:
  1. Configure the health check on the spoke (FortiGate A):

    config system sdwan
        config health-check
            edit "ping"
                set server "1.1.1.1"
                set diffservcode 000001
            set members 0
        next
    end
  2. Configure the loopback interface on the hub (FortiGate B):

    config system interface
        edit "loopback"
            set vdom "vdom1"
            set ip 1.1.1.1 255.255.255.255
            set allowaccess ping https ssh  http telnet 
            set type loopback
            set role lan
            set snmp-index 35
        next
    end
  3. Configure the firewall policy on the hub:

    config firewall policy
        edit 1
            set srcintf "virtual-wan-link"
            set dstintf "loopback"
            set action accept
            set srcaddr "all"
            set dstaddr "all"
            set srcaddr6 "all"
            set dstaddr6 "all"
            set schedule "always"
            set service "ALL"
            set logtraffic all
            set auto-asic-offload disable
            set nat enable
            set diffserv-copy enable
        next
    end
To test the configuration:
  1. Generate some local-in traffic.

  2. Verify that the session’s tos value from the original direction is applied to the reply direction:

    # diagnose sys session list
    
    session info: proto=1 proto_state=00 duration=1 expire=59 timeout=0 flags=00000000 socktype=0 sockport=0 av_idx=0 use=3
    origin-shaper=
    reply-shaper=
    per_ip_shaper=
    class_id=0 ha_id=0 policy_dir=0 tunnel=/ vlan_cos=0/0
    state=log local may_dirty 
    statistic(bytes/packets/allow_err): org=80/2/1 reply=80/2/1 tuples=2
    tx speed(Bps/kbps): 0/0 rx speed(Bps/kbps): 0/0
    orgin->sink: org pre->in, reply out->post dev=20->42/42->20 gwy=1.1.1.1/0.0.0.0
    hook=pre dir=org act=noop 10.2.2.1:15->1.1.1.1:8(0.0.0.0:0)
    hook=post dir=reply act=noop 1.1.1.1:15->10.2.2.1:0(0.0.0.0:0)
    misc=0 policy_id=1 pol_uuid_idx=0 auth_info=0 chk_client_info=0 vd=3
    serial=0001a846 tos=41/41 app_list=0 app=0 url_cat=0
    rpdb_link_id=00000000 ngfwid=n/a
    npu_state=0x000001 no_offload
    no_ofld_reason:  local disabled-by-policy
    total session 1
    Tooltip

    Capture packets can also be used verify that the DSCP value from the original direction is applied to the reply direction.

Copying the DSCP value from the session original direction to its reply direction

In an SD-WAN scenario when DSCP tags are used to mark traffic from the spoke to the hub, it is sometimes desirable for the hub to mark the reply traffic with the same DSSP tags. The diffserv-copy setting in firewall policy configurations allows the DSCP tag to be copied to the reply direction.

config firewall policy
    edit <id>
        set diffserv-copy {enable | disable}
    next
end

Example

The use cases in this example are for a hub and spoke SD-WAN deployment. Traffic from the spoke (either real traffic or SLA health check probes) can be marked with a certain DSCP tag when leaving the spoke. QoS may be applied by an upstream device based on the DSCP tag. When the traffic arrives on the hub, the hub may also want to mark the reply traffic to the spoke with the same DSCP tag. This would allow QoS to be applied to the traffic in the reply direction as well, which is traffic in the hub to spoke direction associated with the same session in the spoke to hub direction.

While this topology simplifies the SD-WAN deployment into a single hub and spoke, this feature applies to the following configurations:

  • Multiple spokes (branch sites)
  • One or more hubs (data center sites)
  • Multiple overlays connecting spokes to hubs
  • SD-WAN configured on spokes to pick the best overlay

Use case 1: typical forwarding traffic

Traffic originates from the spoke and is destined for a server behind the hub. The spoke marks the traffic with a DSCP tag of 101010. This is done by enabling diffserv-foward on the spoke firewall policy. It can also be accomplished by enabling dscp-forward in an SD-WAN rule.

The hub allows the traffic in through a firewall policy. By enabling diffserv-copy on the firewall policy, it will mark the reply traffic on the corresponding sessions with the same DSCP tag in which it came.

To configure the FortiGates:
  1. Configure the firewall policy on the spoke (FortiGate A):

    config firewall policy
        edit 1
            set srcintf "port1"
            set dstintf "virtual-wan-link"
            set action accept
            set srcaddr "all"
            set dstaddr "all"
            set srcaddr6 "all6"
            set dstaddr6 "all6"
            set schedule "always"
            set service "ALL"
            set logtraffic all
            set nat enable
            set diffserv-forward enable
            set diffservcode-forward 101010
        next
    end
  2. Configure the firewall policy on the hub (FortiGate B):

    config firewall policy
        edit 3
            set srcintf "virtual-wan-link"
            set dstintf "wan1"
            set action accept
            set srcaddr "all"
            set dstaddr "all"
            set srcaddr6 "all"
            set dstaddr6 "all"
            set schedule "always"
            set service "ALL"
            set logtraffic all
            set auto-asic-offload disable
            set nat enable
            set diffserv-copy enable
        next
    end
To test the configuration:
  1. Generate some forwarding traffic.

  2. Verify that the session’s tos value from the original direction is applied to the reply direction:

    # diagnose sys session filter policy 3
    # diagnose sys session filter dst 172.16.200.55
    # diagnose sys session list
    
    session info: proto=1 proto_state=00 duration=35 expire=59 timeout=0 flags=00000000 socktype=0 sockport=0 av_idx=0 use=3
    origin-shaper=
    reply-shaper=
    per_ip_shaper=
    class_id=0 ha_id=0 policy_dir=0 tunnel=/ vlan_cos=0/255
    state=log may_dirty f00 
    statistic(bytes/packets/allow_err): org=3024/36/1 reply=3024/36/1 tuples=2
    tx speed(Bps/kbps): 82/0 rx speed(Bps/kbps): 82/0
    orgin->sink: org pre->post, reply pre->post dev=20->17/17->20 gwy=172.16.200.55/10.2.2.1
    hook=post dir=org act=snat 10.2.2.1:25290->172.16.200.55:8(172.16.200.2:25290)
    hook=pre dir=reply act=dnat 172.16.200.55:25290->172.16.200.2:0(10.2.2.1:25290)
    misc=0 policy_id=3 pol_uuid_idx=1097 auth_info=0 chk_client_info=0 vd=3
    serial=0000a018 tos=6a/6a app_list=0 app=0 url_cat=0
    rpdb_link_id=00000000 ngfwid=n/a
    npu_state=0x4000001 no_offload
    no_ofld_reason:  disabled-by-policy
    total session 1

Use case 2: local-in traffic destined to a loopback interface

SLA health checks from the spoke are destined for a loopback interface on the hub. The health check is marked with a DSCP tag of 000001 by the spoke. When the hub receives the probes to its loopback, it will mark the replies with the same DSCP tags in which it came.

To configure the FortiGates:
  1. Configure the health check on the spoke (FortiGate A):

    config system sdwan
        config health-check
            edit "ping"
                set server "1.1.1.1"
                set diffservcode 000001
            set members 0
        next
    end
  2. Configure the loopback interface on the hub (FortiGate B):

    config system interface
        edit "loopback"
            set vdom "vdom1"
            set ip 1.1.1.1 255.255.255.255
            set allowaccess ping https ssh  http telnet 
            set type loopback
            set role lan
            set snmp-index 35
        next
    end
  3. Configure the firewall policy on the hub:

    config firewall policy
        edit 1
            set srcintf "virtual-wan-link"
            set dstintf "loopback"
            set action accept
            set srcaddr "all"
            set dstaddr "all"
            set srcaddr6 "all"
            set dstaddr6 "all"
            set schedule "always"
            set service "ALL"
            set logtraffic all
            set auto-asic-offload disable
            set nat enable
            set diffserv-copy enable
        next
    end
To test the configuration:
  1. Generate some local-in traffic.

  2. Verify that the session’s tos value from the original direction is applied to the reply direction:

    # diagnose sys session list
    
    session info: proto=1 proto_state=00 duration=1 expire=59 timeout=0 flags=00000000 socktype=0 sockport=0 av_idx=0 use=3
    origin-shaper=
    reply-shaper=
    per_ip_shaper=
    class_id=0 ha_id=0 policy_dir=0 tunnel=/ vlan_cos=0/0
    state=log local may_dirty 
    statistic(bytes/packets/allow_err): org=80/2/1 reply=80/2/1 tuples=2
    tx speed(Bps/kbps): 0/0 rx speed(Bps/kbps): 0/0
    orgin->sink: org pre->in, reply out->post dev=20->42/42->20 gwy=1.1.1.1/0.0.0.0
    hook=pre dir=org act=noop 10.2.2.1:15->1.1.1.1:8(0.0.0.0:0)
    hook=post dir=reply act=noop 1.1.1.1:15->10.2.2.1:0(0.0.0.0:0)
    misc=0 policy_id=1 pol_uuid_idx=0 auth_info=0 chk_client_info=0 vd=3
    serial=0001a846 tos=41/41 app_list=0 app=0 url_cat=0
    rpdb_link_id=00000000 ngfwid=n/a
    npu_state=0x000001 no_offload
    no_ofld_reason:  local disabled-by-policy
    total session 1
    Tooltip

    Capture packets can also be used verify that the DSCP value from the original direction is applied to the reply direction.