Cisco SAF provides a framework that allows applications to discover the existence, location, and configuration of networked resources within networks. Cisco SAF allows a timely and reliable awareness of the services within networks, as applications advertise and discover services on networks. Service information distributes though a network of Cisco SAF cooperative nodes that assume specific functions to efficiently distribute knowledge of services and facilitate their discovery.

A non-SAF node is any node in a network that does not understand SAF. Non-SAF nodes are called “dark nets” and are required to traverse ISPs. Cisco SAF messages are IP-based and therefore are unaffected by dark nets.

These Cisco SAF cooperative network nodes are grouped into two major functional responsibilities:

• Cisco SAF Forwarder
• Cisco SAF Client

To configure Cisco SAF, you must configure both an SAF Forwarder and an SAF Client.

The flexibility of Cisco SAF allows you to configure a single edge router to act as a Cisco SAF Forwarder and a Cisco SAF Client, if necessary.

This section provides the following information:

• Cisco SAF Forwarder Overview
  
• Cisco SAF Client Overview
  
• Cisco SAF Client and SAF Forwarder Interaction Overview
  

A service is any information that a Cisco SAF Client application wishes to advertise, that can then be used by other Cisco SAF Client applications. A service advertisement consists of service data. Service advertisements are propagated between forwarders using header data. Cisco SAF Clients that are interested in a service receive, and may inspect, service header and service data.

A service identifier number uniquely identifies the service on a network. The following example shows the format of a service identifier number:

service:sub-service:instance.instance.instance.instance

The service identifier is a 16-bit decimal identifier for the major service being advertised. A major service refers to a specific technology area, such as Cisco Unified Communications (UC). Service identifiers are assigned by Cisco to various customers requiring an SAF client.

The following example shows the service ID values for IP Everywhere and Cisco Unified Communications:

Cisco Defined Numbers 
    SAF_SERVICE_ID_IPE            	= 100 	 ! IP Everywhere
    SAF_SERVICE_ID_UC            	 = 101 				 ! Unified Communications

The sub-service identifier is a 16-bit decimal identifier for the minor service being advertised. A sub-service (also referred to as a minor service) refers to the type of service within a technology. For example, within UC:

• Sub-service 1 is TDM gateway
• Sub-service 2 is hosted-DN
• Instance identifies a specific service advertisement for this kind of service. For example, service identifier 101:1:abcd.1234.ef.678 could be an advertisement of a UC (service 101) TDM gateway (sub-service 1) announced by the Communications Manager cluster in a certain location (instance abcd.1234.ef.678).

The instance identifier is a unique 128-bit number that identifies the specific service advertised.

Client teams define the use of sub-service and instance values for their applications. Clients must ensure instance uniqueness within a Cisco SAF domain.

As the variety and number of network services grows, providing timely and reliable awareness of these services starts to play a more significant role in increasing productivity and efficiency. One of the biggest challenges in propagating service availability awareness over a WAN is one of scalability. As networks grow, the services offered by the devices on these networks increases. Protocols responsible for the service advertisement need to scale to handle this increased load. These protocols also need to react to rapid changes efficiently and propagate the new information in a timely manner.

Cisco SAF is designed to be a scalable solution for enterprise service locations and is capable of spanning LAN and WAN internet segments. As an enterprise solution, you can configure Cisco SAF to use domains to scale for very large networks. Just as Cisco Enhanced Interior Gateway Routing Protocol (EIGRP) defines the concept of an autonomous system in which routes can be searched for in a hierarchical manner, Cisco SAF employs the similar concept of a domain and sub-domains.

Cisco SAF provides a dynamic peer discovery and service advertisement propagation technique known as IP multicast. IP multicast requires the cooperation of IP Cisco SAF Forwarders (the devices that connect IP subnets together to form intranets). IP multicasting, however, may not be completely implemented across some intranets. In the absence of IP multicasting, Cisco SAF operates within the configured subnet, or within the groups of subnets over which IP multicast is supported.

Cisco SAF Forwarders offer two primary types of administrative domains (AD); a domain and a subdomain. A domain and a subdomain function the same with one notable exception; subdomains do not form unique neighbor relationships, but instead rely on a single peering.

Ideally, a network would only require a single domain to use for advertising all services. However, due to scaling and policy issues, some networks require the creation of multiple domains. The recommendation is to use a single domain. Consider using multiple domains when:

• More than 30,000 services are registered in a single domain
• Logical grouping of services is needed to restrict propagation of services

Closed groups are needed to prevent users from browsing services they are not allowed to access

Service redistribution allows different domains to exchange service information. Services may need to be bound to specific areas of the network, or the number of services in a given network my need to be limited. If you cannot use a single domain, service advertisement redistribution might be the solution.

Each domain on a network is separated into an administrative domain (AD). All Cisco SAF Forwarders in the same AD (running the same domain) have complete knowledge of the entire AS. A Cisco Forwarder that connects two (or more) administrative domains is known as a border Forwarder. A border Forwarder advertises service information from one AS to another AS. Proper design should also be considered if multiple border Forwarders are used to avoid loops (information learned from one AD being sent back to the same AD).

Cisco EIGRP Service-Family Support extends the named configuration to allow configuration of multiple instances, which operate independently. The addition of a Virtual Router ID (VRID) to the base Cisco EIGRP packet encoding allows for multiple instances.

As each virtual router is created, a VRID is assigned to the top level router and shared with the address families and service families that are configured under it.

Cisco SAF Forwarders can operate in networks that do not have routers that support the Cisco SAF Forwarder protocol. These networks are referred to as “dark nets.” There are two methods for configuring Cisco SAF Forwarders over IP networks that do not support Cisco SAF (IP clouds); unicast Cisco SAF neighbors and multicast Cisco SAF neighbors.

You can use a unicast configuration to provide a reliable point-to-point adjacency with neighbors. As the number of Cisco SAF Forwarders increases, you can use multicast to provide an efficient transport between multiple Cisco SAF neighbors. A single IP multicast group address can be used for multiple Cisco SAF neighbors to exchange SAF information in a peer-group.

1.    enable

2.    configure terminal

3.    router eigrp virtual-instance-name

4.    service-family {ipv4 | ipv6} [vrf vrf-name ] autonomous-system autonomous-system-number

5.    exit-service-family

1.    enable

2.    configure terminal

3.    router eigrp virtual-instance-name

4.    service-family {ipv4 | ipv6} [vrf vrf-name ] autonomous-system autonomous-system-number

5.    sf-interface interface-name interface-number

6.    sf-interface

7.    exit-sf-interface

1.    enable

2.    configure terminal

3.    router eigrp virtual-instance-name

4.    service-family {ipv4 | ipv6} [vrf vrf-name ] autonomous-system autonomous-system-number

5.    topology base

6.    exit-sf-topology

1.    enable

2.    configure terminal

3.    router eigrp virtual-instance-name

4.    service-family {ipv4 | ipv6} [vrf vrf-name ] autonomous-system autonomous-system-number

5.    neighbor {ip-address{interface-type interface-number}| description word | maximum-service}| maximum-service number [threshold-value][dampened| reset-time| restart interval| restart-count| warning-only]}

6.    exit-service-family

1.    enable

2.    configure terminal

3.    router eigrp virtual-instance-name

4.    service-family {ipv4 | ipv6} [vrf vrf-name ] autonomous-system number

5.    eigrp stub [receive-only | connected ]

6.    exit-service-family

1.    enable

2.    configure terminal

3.    router eigrp virtual-instance-name

4.    service-family {ipv4 | ipv6} [vrf vrf-name ] autonomous-system autonomous-system-number

5.    sf-interface interface-name interface-number

6.    authentication key-chain name-of-chain

7.    authentication mode {hmac-sha-256 {0 | 7} password | md5}

8.    exit-sf-interface

9.    exit-service-family

10.    exit

11.    key-chain name-of-chain

12.    key key-id

13.    key-string text

14.    accept-lifetime start-time [local {duration seconds | end-time | infinite}]

15.    send-lifetime start-time [local {duration seconds | end-time | infinite}]

16.    exit

1.    enable

2.    configure terminal

3.    router eigrp virtual-instance-name

4.    service-family {ipv4 | ipv6} [vrf vrf-name ] autonomous-system autonomous-system-number

5.    eigrp log-neighbor-changes

6.    eigrp log-neighbor-warnings seconds

7.    exit-service-family

1.    enable

2.    configure terminal

3.    router eigrp virtual-instance-name

4.    service-family {ipv4 | ipv6} [vrf vrf-name ] autonomous-system autonomous-system-number

5.    sf-interface interface-name interface-number

6.    bandwidth-percent maximum-bandwidth-percentage

7.    exit-sf-interface

Because metric components can be changed rapidly, the frequency of the changes can have an impact on the network. Frequent changes require that prefixes learned though the SAF interface be updated and sent to all adjacencies. This update can result in further updates and in a worst-case scenario, cause network-wide churn. To prevent such effects, metrics can be dampened or thresholds set so that any change that does not exceed the dampening threshold is ignored.

Network changes that cause an immediate update include any change in a metric that results in the router selecting a new nexthop or a down interface or router.

Dampening the metric changes can be configured based on a change or on a time interval.

If the dampening method is:

• Change-based, changes in routes learned though a specific interface or in the metrics for a specific interface will not be advertised to adjacencies until the computed metric changes from the last advertised value are significant enough to cause an update to be sent.
• Interval-based, changes in routes learned though a specific interface or in the metrics for a specific interface will not be advertised to adjacencies until the specified interval is met or unless the change results in a new route path selection. When the timer expires, routes that have outstanding changes to report are sent. If a route changes and the final metric of the route matches the last updated metric, no updated routes are sent.

Refer to the following sections for information on configuring change-based and interval-based metric dampening configurations.

• Change-based Dampening Configuration
  
• Interval-based Dampening Configuration
  

1.    enable

2.    configure terminal

3.    router eigrp virtual-instance-name

4.    service-family {ipv4 | ipv6} [vrf vrf-name ] autonomous-system autonomous-system-number

5.    sf-interface interface-name interface-number

6.    hello-interval seconds

7.    hold-time seconds

8.    exit-sf-interface

1.    enable

2.    configure terminal

3.    router eigrp virtual-instance-name

4.    service-family {ipv4 | ipv6} [vrf vrf-name ] autonomous-system autonomous-system-number

5.    sf-interface interface-name interface-number

6.    no split-horizon

7.    exit-sf-interface

1.    enable

2.    configure terminal

3.    router eigrp virtual-instance-name

4.    service-family {ipv4 | ipv6} [vrf vrf-name ] autonomous-system autonomous-system-number

5.    sf-interface interface-name interface-number

6.    metric maximum-hops

7.    exit-sf-interface

Before configuring:

• Cisco SAF Clients, you should understand the concepts in the Cisco SAF Client_Overview.
• Neighbor relationships for Cisco SAF External Clients located on separate LANs, ensure that you have IP routing configured between each Cisco External Client.

Cisco SAF currently supports a maximum of 50 Cisco SAF External Clients.

1.    enable

2.    configure terminal

3.    router eigrp virtual-instance-name

4.    service-family {ipv4 | ipv6} [vrf vrf-name ] autonomous-system autonomous-system-number

5.    topology base

6.    external-client client-label

7.    exit-sf-topology

8.    exit-service-family

9.    exit

10.    service-family external-client listen {ipv4 | ipv6} tcp_port_number

11.    external-client client-label basename

12.    username user-name

13.    password password-name

14.    keepalive number

15.    exit

The following terms are used when describing neighbor types:

• Local Neighbor--A neighbor that is adjacent on a shared subnet (or common subnet) and uses a link-local multicast address for packet exchange. This is the default type of neighbor in Cisco SAF.
• Static Neighbor--Any neighbor that uses unicast to communicate, is one hop away, is on a common subnet, and whose IP address has been specified using the neighborip-address command.
• Remote Neighbor--Any neighbor that is multiple hops away, including Remote Static Neighbors.
• Remote Static Neighbor--Any neighbor that uses unicast to communicate, is multiple hops away, and whose IP address has been specified using the neighborip-address command.
• Remote Multicast-Group--Any neighbor that is multiple hops away, but does not have its IP address manually configured using the neighborip-address command, and uses a configured multicast group address for packet exchange.
• Remote Unicast-listen (or simply Unicast-listen)--Any neighbor that uses unicast to communicate, is multiple hops away, and whose IP address has not been configured using the neighborip-address command.

When using remote unicast-listen or remote multicast-group neighbor configurations, SAF neighbor IP addresses are not pre-defined, and neighbors may be many hops away. A router with this configuration could peer with any router that sends a valid HELLO packet. Because of security considerations, this open aspect requires policy capabilities to limit peering to valid routers and to restrict the number of neighbors to limit resource consumption. This capability is accomplished using the following manually configured parameters, and takes effect immediately.

• Neighbor Filter List
  
• Maximum Remote Neighbors
  
• Configuration Changes for Neighbor Filter List and Maximum Remote Neighbors
  

For configurations in which multiple remote neighbors peer with a single hub (point-to-point), the hub can be configured for remote unicast-listen peering using the remote-neighbors command to allow the remote neighbors to peer with the hub without having to manually configure the remote neighbor IP addresses on the hub.

When configured with this command, the hub router:

• Uses its interface IP address as the source IP address for any unicast transmissions. This IP address must be routable.
• Requires neighbors peering with the hub to be configured using the neighborip-address loopback loopback-interface-number remotemaximum-hops command where ip-address is the unicast address of the local router interface IP address.
• Listens for unicast HELLO packets on the interface specified in the remote-neighbor command.
• Accepts a unicast HELLO packet if it is in the IP address range configured using the allow-list keyword, or any unicast HELLO packet if an allow list is not defined.
• Rejects multicast HELLO packets from any neighbor that is also sending unicast HELLO packets and is permitted by the unicast allow-list (or all neighbors if an allow-list is not defined).
• Begins normal neighbor establishment using the IP addresses of the remote neighbors for packet transmission once the neighbor relationship is established.

Multicast can be used to provide an efficient transport between multiple Cisco SAF neighbors. A single multicast-group address can be used for multiple Cisco SAF neighbors to exchange information within the same multicast-group. To configure multipoint-to-multipoint configurations, use the multicast-group keyword available in the remote neighbors command.

When configured with this command, the router:

• Uses the interface IP address as the source IP address for any unicast transmissions. This IP address must be routable.
• Uses the configured multicast-group address for all multicast packets sent and received.
• Requires all forwarders and routers, which form the multipoint-to-multipoint neighbor relationships, to be configured using the same multicast-group IP address.
• Requires multicast forwarding for the defined multicast-group address to be configured and functional for packet delivery.

Static neighbors configured with the neighborip-address or the neighborip addressremote commands take precedence over the remote neighbors that are created as a result of the remote-neighbors command. If the remote IP address of an incoming unicast Cisco SAF connection matches both a static neighbor and the remote unicast-listen neighbor access list, the static neighbor is used and no remote unicast-listen neighbor is created. If you configure a new static neighbor while a remote neighbor for the same remote IP address already exists, Cisco SAF automatically removes the remote unicast-listen neighbor.

Remote unicast-listen neighbors take precedence over remote multicast-group neighbors. If Cisco SAF is receiving both unicast and multicast HELLOs from the same remote IP address targeted at the same local interface, the neighbor will be treated as unicast (unicast-listen) rather than multicast (multicast-group) for packet exchange.

Before configuring SAF dynamic neighbors, ensure that when using:

• Unicast-listen mode--IP connectivity (reachability) exists between routers that need to do dynamic peering.
• Multicast-group mode--Multicast is running on the network.
• allow-list keyword--The configured Access Control List that will specify the remote IP addresses from which EIGRP neighbor connections may be accepted.

• The remote-neighbors command requires a loopback as a source interface.
• Only named ACLs (Access Control Lists) are permitted with the allow-list keyword. Numbered ACLs configured are not permitted.
• Within a service-family:
  • Only one remote-neighbors unicast-listen command and one remote-neighbors multicast-group command may be configured per interface. (For example, you cannot configure remote-neighbors source Loopback1 multicast-group 224.1.1.1 and remote-neighbors source Loopback1 multicast-group 224.1.1.2.) If you want to configure multiple different multicast-group addresses in the same service-family, you need to use multiple source interfaces.
  • A multicast-group address may only be associated to a single source interface. (For example, you cannot configure remote-neighbors source Loopback1 multicast-group 224.1.1.1 and remote-neighbors source Loopback2 multicast-group 224.1.1.1.)

1.    enable

2.    configure terminal

3.    router eigrp virtual-instance-name

4.    service-family {ipv4 | ipv6} [vrf vrf-name ] autonomous-system autonomous-system-number

5.    remote-neighbors source interface {unicast-listen | multicast-group group-address } [allow-list access-list-name ] [max-neighbors max-remote-peers ]

6.    exit-service-family