Merge pull request #860 from 128technology/DOCS-491-service-route-types

adding service route definitions

Author: Chr1st0ph3rTurn3r

docs/bcp_dhcp_relay_overview.md

@@ -99,6 +99,8 @@ config
 exit
 ```
 
+See [Service Routes](concepts_glossary.md#service-routes) for additional information.
+
 ### Network Interface
 
 On the router processing the DHCP relay requests (Branch 2), the unique tenant created must be applied to the network-interface receiving the DHCP broadcasts. These DHCP request broadcasts are tagged by the tenant and associated with the `dhcp-relay` service. After the association is made, the SSR will convert the broadcast into a unicast and forward it to the IP of the DHCP servers.

docs/bcp_sdwan_design_guide.md

@@ -115,9 +115,7 @@ Many times, the customer may have an accelerated timeline and wish to deploy wit
 
 One larger consideration for a large deployment is FIB size. FIB entries consume memory resources on the router. One way to avoid this is to avoid creating FIB entries where they are not needed. If a service does not apply to all routers in the configuration, we should restrict it to apply only where it is needed. We can do this by creating router groups. In the first portion of this document, one item was to enumerate the applications used by the customer and to indicate the site categories that used the services, either as the source or destination. These site categories can be used to create router groups, which is a label we can apply in config to any router that fits within this category. In our service configurations, we can configure an applies-to setting that indicates the particular router groups to which it should apply.
 
-### Routing Design
-
-#### Routing Services
+### Routing Design - Service Routes
 
 The SSR allows for routing on more criteria than simply L3 address. Routing decisions can be made based on the services that network operators define, which includes transport protocols and port ranges. As mentioned in the section on service design, in order for any traffic to pass through an SSR, its source must be classified as belonging to a tenant, its destination needs to match a configured service to which this tenant has access, and a next-hop must be available for this service traffic. This section attempts to provide details of where those next-hops come from.
 
@@ -141,6 +139,8 @@ One design consideration to keep in mind when using BGPoSVR is that for services
 
 A single SD-WAN deployment can leverage both BGP over SVR for certain services and service-routes for other services. Likely, the two use of these design options will be driven by the customer's routing architecture in the remote data center that hosts the applications. In the next section, we will explore this in more detail.
 
+For a list of the service route types, see [Service Routes](concepts_glossary.md#service-routes).
+
 #### Integrating into a customer's existing routing infrastructure
 
 This section generally applies only to data center sites. In SD-WAN branch sites, typically the SSR is the gateway for all devices at the location and there is no other routing required. In a data center environment, the SSR needs to interface with the customer's existing network to be able to provide access to services. There will typically be other devices to consider such as routers and firewalls. This portion of the design will greatly depend on the customer's legacy environment. This section will enumerate several design options to consider when integrating into a data center environment. This section assumes that valid services exist within the SSR configuration to allow all traffic to egress to the right location and that our only concern is routing.

docs/concepts_fib_design.md

@@ -46,6 +46,8 @@ FIB:
 
 ```
 
+See [Service Routes](concepts_glossary.md#service-routes) for additional information.
+
 ### FIB Sprawl
 
 The amount of RAM present in the system dictates the maximum number of entries allowed in the FIB table. Therefore, FIB space is a limited resource on the platform and should be considered during configuration design. Design decisions of the tenant/service model for a deployment have a major impact on the size of the FIB. The number of service addresses, transport/port-ranges, and tenant access-policies configured have a major influence on how the FIB is built, as do the number of routes seen in the RIB. 

docs/concepts_glossary.md

@@ -582,6 +582,25 @@ service-route                 local-webserver3-route
     service-route-policy  lb-policy
 exit
 ```
+For a detailed description of service-routes, refer to the [Routing Services](bcp_sdwan_design_guide.md#routing-design---service-routes) section of the SDWAN Design Guide.
+
+### Types of Service Routes
+
+- `service-agent`: Used to steer traffic out an interface as non-SVR traffic (routed). When the service used in this service-route has `share-service-routes` set to `true`, configuring a `service-agent` on a router triggers a peer or next-peer service-route to this SSR from any other SSR managed by the same conductor, and in the same neighborhood.
+
+- `peer`: Auto-generated service route used to send traffic via SVR to another SSR. The conductor creates the peer service-route from the neighborhood configuration.
+
+- `next-peer`: The `next-peer` service-route is auto-generated by the conductor when the service-policy option `peer-path-resiliency` is set to true. This allows the SSR to consider multiple SSR peer routers that are available to receive traffic. The order of the peer routers within this service-route does not dictate the preferred order of peers; instead, the overall service-policy vector configuration for all peer paths to all SSR peer routers is used.
+
+- `use-learned-routes`: An option that allows the auto-generation of peer/next-peer service routes to this router, as done with `service-agent` service routes. The difference is that when traffic arrives at this router, it leverages the next-hop from the RIB to dictate how the traffic egresses as non-SVR, routed traffic. The typical use case is a scenario where the local router is learning routes from a non-SSR peer router to determine the next-hop.
+
+- `routing-stack`: Used for auto-generated services for BGP over SVR and multicast traffic to send routing protocol traffic to the routing stack. **This should never be manually configured.** 
+
+- `host`: This option is used to steer traffic to the internal kni254 interface of the router to the Linux OS. When configuring this service route, set a `nat-target` of 169.254.127.127, which is the Linux-side IP of the kni254 interface.
+
+- `eosvr-bridge`: Only used for Ethernet over SVR to ensure that traffic is steered to the correct bridge.
+
+- `use-bgp-over-svr`: Despite the name, this option is not required for BGP over SVR. By default the SSR takes the next-hop from the RIB, which includes routes from BGP over SVR. This option exists for scenarios where the user wants to leverage BGP over SVR in conjunction with a service-agent, should the BGP routes fail. The standard use case is: The user prefers to send Internet traffic to a hub router following BGP over SVR. If the router loses BGP with the hub, the local router can fall back to steering the traffic out a local interface with a service-agent. To do this, the user specifies vectors in the service-routes and ranks them using the service-policy. Both service-routes must set `enable-failover` to `true`. When a service route of this type is used, the local SSR **only** considers routes from BGP over SVR. It will not consider any other routes from the RIB, including locally connected routes.
 
 ## Service Route Policies
 A Service Route Policy is way to set limits on the Service Routes to use when the SSR is determining which path to take. This is necessary for load balancing. You can set limits based on the max number of concurrent sessions to send down one path or the session rate/second for that path. Service Route Policies get applied to the Service Routes. 

docs/config_ha.md

@@ -268,7 +268,7 @@ Available with SSR Version 5.4 and higher.
 
 #### `enable-failover` on the `service-route`:
 
-Service routes are used to influence traffic destinations for services. By enabling failover on the service route, failover includes the existing sessions, eliminating the lag time previously encountered as those sessions were re-established. Service route redundancy is not exclusive to dual node, high availability configurations. It is configured as shown below.
+[Service Routes](concepts_glossary.md#service-routes) are used to influence traffic destinations for services. By enabling failover on the service route, failover includes the existing sessions, eliminating the lag time previously encountered as those sessions were re-established. Service route redundancy is not exclusive to dual node, high availability configurations. It is configured as shown below.
 
 To enable existing sessions to failover between the nodes, `enable-failover` is configured on both the service-routes `test-1_intf13_route-0` and `test-2_intf113_route-0`. Any generated peer service-routes will inherit this property as well. 
 

docs/config_management_over_forwarding.md

@@ -21,7 +21,7 @@ Once a forwarding interface is provisioned for management traffic, any existing
 
 ## Management Services
 
-One of the strengths of the SSR data model is to dynamically apply policy only as needed. As it relates to management traffic, service policy will only be created for those management applications provisioned. The list of applications natively supported are:
+One of the strengths of the SSR data model is to dynamically apply policy only as needed. As it relates to management traffic, a service policy will only be created for those management applications provisioned. The list of applications natively supported are:
 
 * [Conductor traffic](concepts_machine_communication.md#router-to-conductor-connectivity). This works in tandem with [conductor services](bcp_conductor_deployment.md)
 * [Web server access](config_reference_guide.md#webserver)
@@ -43,7 +43,7 @@ Because a default route is added in Linux, all traffic not captured by a static
 
 For each of the [management services](#management-services) configured, the SSR will automatically generate corresponding `service` and `service-route` configurations for forwarding the respective traffic. The generated configuration objects will all start with the prefix `_management_`.
 
-Each of the service and service-routes share one important attribute: they are created with the `generated` flag set to `true`. If you want to make any modifications to the generated services, you must first set `generated` to `false`, or else your configuration changes will be stripped upon the next time the configuration is committed. For more information on configuration work-flows involving the `generated` flag, refer to the [SSR software documentation](config_basics.md#generated-configuration).
+Each of the service and service-routes share one important attribute: they are created with the `generated` flag set to `true`. If you want to make any modifications to the generated services, you must first set `generated` to `false`, or else your configuration changes will be stripped upon the next time the configuration is committed. For more information on configuration work-flows involving the `generated` flag, refer to the [Generated Configuration documentation](config_basics.md#generated-configuration).
 
 :::note
 `management` interfaces cannot be used on device-interface types of `host` or `bridge`.

docs/config_ospf.md

@@ -120,7 +120,7 @@ exit
 
 ![OSPF Redistribution](/img/ospfv2-image9.png)
 
-To enable service routing (service-route elements) to leverage the learned routes that a SSR has exchanged via OSPF (or any routing protocol), the “use-learned-routes” selector should be enabled in the appropriate service-route configuration.
+To enable service routing ([service-route elements](concepts_glossary.md#service-routes)) to leverage the learned routes that a SSR has exchanged via OSPF (or any routing protocol), the “use-learned-routes” selector should be enabled in the appropriate service-route configuration.
 ```
 *[email protected] (router[name=burlington])# service-route rte_internet
 *[email protected] (service-route[name=rte_internet])# use-learned-routes