Skip to main content

This document explains how the user can query using a URL clause and how the system models URL-based policies to return results for these Layer 7 queries. The main goal is to provide visibility into whether a resource specified with its URL can be accessed by a specific traffic flow.

Structure of a URL

URL example: https://xyz.jira.local.forwardnetworks.co.us:8338/projects/fwd/plans/plan-1

In the above example:

  • https is the scheme
  • xyz.jira.local. is the sub-domain, which is optional and consists of a maximum of 3 parts.
  • forwardnetworks is the domain.
  • co.us is the TLD (Top Level Domain) and it consists of 1-2 parts.
  • 8338 is the port
  • projects/fwd/plans/plan-1 is the path, which is optional and consists of a maximum of 4 parts.
caution

Note: Forward won’t be supporting the scheme (http, https) and the port in the URL clause of the path query. IP addresses in the URL within the URL clause are not supported either.

Policy Patterns Supported in the Model

Forward supports URL-based policies defined as:

  • Full URLs
  • Prefix-wildcarding in sub-domains
  • Suffix-wildcarding in TLD and path

Here a non-exhaustive list of examples of URLs that Forward will be able to model:

  • xyz.jira.local.forwardnetworks.co.us/projects/fwd/plans/plan-1
  • *.jira.local.forwardnetworks.co.us/projects/fwd/plans/plan-1
  • *.jira.local.forwardnetworks.co.us/projects/fwd/plans
  • *.jira.local.forwardnetworks.co.us/projects/fwd
  • *.jira.local.forwardnetworks.co.us/projects
  • *.jira.local.forwardnetworks.co.us
  • *.jira.local.forwardnetworks.co
  • *.jira.local.forwardnetworks.*
  • xyz.jira.local.forwardnetworks.co.*
info

Forward supports URL-based policies for Palo Alto, SilverPeak and Viptela devices.

Path Query in a URL-based Policy Context

This section describes examples of supported queries and their semantics.

tip

The queries below are examples where some optional filters are missing (i.e. Dest L4 Port). They are missing because their presence does not affect the concepts being explained.

Queries without url​

  • User query: ”from IP-X with ip_dest IP-Y delivered”
  • System behavior:
    • The system interprets this query as “tell me the paths for the traffic that leaves from IP-X, destined to IP-Y and it gets delivered along the path”.
    • Because the user didn’t specify any URL, if along the path the traffic matches an ACL that contains a URL, the system will ignore the match. In fact, Forward assumes that by not specifying the URL, the user is not interested in anything specific to that URL including an ACL matching. The assumption again is based on the fact that if the user was debugging or was generally interested in understanding the network behavior for a specific resource in the form of its URL, he/she would specify that in the query. While this approach may not be true for 100% of the cases, it is a reasonable assumption that will cover most of them.

Queries with url​

Forward supports querying with FULL url as well as wildcarded URL in the path query.

  • User query: ” from IP-X with ip_dest IP-Y url xyz.jira.local.forwardnetworks.co.us/projects/fwd/plans/plan-1 delivered ”
  • System behavior:
    • The system interprets this query as “tell me the paths for the traffic that leaves from IP-X, is destined to IP-Y and is trying to access the resource located at this URL: xyz.jira.local.forwardnetworks.co.us/projects/fwd/plans/plan-1 , show me only the traffic that gets delivered”.
    • The system fully supports this case in the first release and will return the paths matching the query.

The following examples go deeper in sub-scenarios that differentiate from each other based on how the URL policy has been defined in the ACL on the network device.

Matching on Policy with full URL​

  • User query: ” from IP-X with ip_dest IP-Y url xyz.jira.local.forwardnetworks.co.us/projects/fwd/plans/plan-1 delivered ”
  • ACL rule matches exactly on: xyz.jira.local.forwardnetworks.co.us/projects/fwd/plans/plan-1
  • This is a complete match, the URL filter in the filter panel is automatically selected and contains the full URL

Matching on Policy with wildcarded URL​

In these cases, the matching policy is wildcarded in one of the possible ways described above (sub-domain, TLD, etc.). Wildcarding in the policy definition is commonly found in enterprise networks. The examples below describe how Forward helps the user understand how the network behavior may change based on that wildcarding. In the following examples, the user query does not change.

info

Note that all examples below assume that full path (/projects/fwd/plans/plan-1) is valid, meaning each word is known for the snapshot.

Example 1 – Wildcard in subdomain

  • User query: ” from IP-X with ip_dest IP-Y url xyz.jira.local.forwardnetworks.co.us/projects/fwd/plans/plan-1 delivered ”
  • ACL matches on: *.jira.local.forwardnetworks.co.us/projects/fwd/plans/plan-1
  • The system matches on the wildcarded policy and displays the following selectable options in the filter panel on the left:
    • xyz.jira.local.forwardnetworks.co.us/projects/fwd/plans/plan-1 when “xyz” is a known sub-domain in the system (“xyz” is present as part of a URL policy somewhere in the current snapshot)
    • *.jira.local.forwardnetworks.co.us/projects/fwd/plans/plan-1 when “xyz” is an unknown sub-domain in the system (“xyz” is not present as part of any URL policy in the current snapshot)

Example 2 – Wildcard in subdomain and TLD

  • User query: ” from IP-X with ip_dest IP-Y url xyz.jira.local.forwardnetworks.co.us/projects/fwd/plans/plan-1 delivered ”
  • ACL matches on (note the multiple wildcards in subdomain and TLD): *.jira.local.forwardnetworks.co.*/projects/fwd/plans/plan-1
  • The system matches on the wildcarded policy and displays the following selectable options in the filter panel on the left:
    • xyz.jira.local.forwardnetworks.co.us/projects/fwd/plans/plan-1 when “xyz” and “us” are known subdomain and TLD in the system (“xyz” and “us” are present as part of a URL policy somewhere in the current snapshot)
    • *.jira.local.forwardnetworks.co.us/projects/fwd/plans/plan-1 when “xyz” is an unknown subdomain and “us” is a known TLD in the system (“xyz” is not present while “us” is as part of URL policy in the current snapshot)
    • *.jira.local.forwardnetworks.co.*/projects/fwd/plans/plan-1 when “xyz” and “us” are both unknown in the system (neither is present as part of any URL policy in the current snapshot)

Example 3 – Implicit wildcard for part of TLD

  • User query: ” from IP-X with ip_dest IP-Y url xyz.jira.local.forwardnetworks.co.us/projects/fwd/plans/plan-1 delivered ”
  • ACL matches on: *.jira.local.forwardnetworks.co/projects/fwd/plans/plan-1
  • The system matches on the wildcarded policy and displays the same filters as in the example 2.

Example 4 – Wildcard in the path portion of the URL

  • User query: ” from IP-X with ip_dest IP-Y url xyz.jira.local.forwardnetworks.co.us/projects/fwd/plans/plan-1 delivered ”
  • ACL matches on *.jira.local.forwardnetworks.co.us/projects/*
  • The system matches on the wildcarded policy and displays the following selectable options in the filter panel on the left (same as in example 2 with additional suggestions):
    • If “xyz” and “us” are known and any of the parts of the path: “ fwd ”, “ plans ”, “ plan-1 ” are unknown the system would show “ xyz.jira.local.forwardnetworks.co.us/projects/* “
    • If all parts in the query are known the system would show xyz.jira.local.forwardnetworks.co.us/projects/fwd/plans/plan-1

Example 5 – Implicit wildcard for part of the path portion of the URL

  • User query: ” from IP-X with ip_dest IP-Y url xyz.jira.local.forwardnetworks.co.us/projects/fwd/plans/plan-1 delivered ”
  • ACL matches on *.jira.local.forwardnetworks.co.us/projects
  • The system matches on the wildcarded policy and displays the same filters as in the example 4.

Supported Query Types in the following releases​

The user should expect Forward to add support for live DNS resolution to release the user from the need to specify the destination IP address

Consideration for URL-based SD-WAN policies​

The modeling explained in the above sections allows Forward to support SD-WAN routing policies based on URLs, like the BIO (Business Intent Overlay) on SilverPeak. By querying Forward, as described in above examples, the user will be able to gain visibility into which tunnel gets selected when the traffic carries specific URLs.