IES

This section discusses QPPB as it applies to VPRN, IES, and router interfaces. See the IES section and the ‟IP Router Configuration” section in the 7450 ESS, 7750 SR, 7950 XRS, and VSR Router Configuration Guide.

QoS policy propagation using BGP (QPPB) is a feature that allows a route to be installed in the routing table with a forwarding-class and priority so that packets matching the route can receive the associated QoS. The forwarding-class and priority associated with a BGP route are set using BGP import route policies. In the industry, this feature is called QPPB, and even though the feature name refers to BGP specifically. On SR OS, QPPB is supported for BGP (IPv4, IPv6, VPN-IPv4, VPN-IPv6), RIP and static routes.

While SAP ingress and network QoS policies can achieve the same end result as QPPB, the effort involved in creating the QoS policies, keeping them up-to-date, and applying them across many nodes is much greater than with QPPB. This is because of assigning a packet, arriving on a particular IP interface, to a specific forwarding-class and priority/profile, based on the source IP address or destination IP address of the packet. In a typical application of QPPB, a BGP route is advertised with a BGP community attribute that conveys a particular QoS. Routers that receive the advertisement accept the route into their routing table and set the forwarding-class and priority of the route from the community attribute.

There are two main aspects of the QPPB feature:

• the ability to associate a forwarding-class and priority with specific routes in the routing table.

• the ability to classify an IP packet arriving on a particular IP interface to the forwarding-class and priority associated with the route that best matches the packet.

Source-address based QPPB is not supported on any SAP or spoke SDP interface of a VPRN configured with the grt-lookup command.

This feature introduces a generic operational group object which associates different service endpoints (pseudowires and SAPs) located in the same or in different service instances. The operational group status is derived from the status of the individual components using specific rules specific to the application using the concept. A number of other service entities, the monitoring objects, can be configured to monitor the operational group status and to perform specific actions as a result of status transitions. For example, if the operational group goes down, the monitoring objects are brought down.

All IPv6 Enhanced Subscriber Management (ESM) services require either Routed CO (IES), or Routed CO for VPRN as a supporting service construct. Because of the complexities of the IPv6 link-model, there is currently no support for IPv6 ESM in a VPLS. There is also currently no support for IPv6 in combination with Basic Subscriber Management (BSM). This feature applies to the 7450 ESS and 7750 SR only.

In the 7750 SR OS, the accounting paradigm is based on sla-profile instances, yet this is at odds with traditional RADIUS authentication and accounting which is host-centric. In previous OS releases, it was possible to have many hosts sharing a common sla-profile instance, and therefore accounting and QoS parameters. Complications would arise with RADIUS accounting because Accounting-Start and Accounting-Stop are a function of sla-profile instance and not the hosts – this meant that some host-specific parameters (like Framed-Ip-Address) would not be consistently included in RADIUS accounting.

Dual-stack subscribers are now two different hosts sharing a single sla-profile instance. A new RADIUS accounting mode has been introduced to support multiple-host environments.

A new command, host-accounting, is introduced under accounting-policy, which allows configurable behavior.

No host-accounting:

When no host-accounting is configured, accounting behavior is as follows:

• A RADIUS accounting start message is sent when the SLA-profile instance is created. It contains accounting (octets/packets) and the Framed-Ip-Address of the host which caused the sla-profile instance to be created.

• Additional hosts may bind to the sla-profile instance at any time, but no additional accounting messages are sent during these events.

• If the original host disconnects, then future accounting messages use an IP address of one of the remaining hosts.

• When the final host associated with an sla-profile instance disconnects, an accounting stop message is sent.

Host-accounting enabled:

When host-accounting is configured, additional RADIUS accounting messages are created for host activity in addition to messages for common queue accounting. The behavior is as follows:

• A RADIUS accounting start message is sent each time a host is authenticated. It contains the Framed-Ip-Address among other things. It does not contain any octet or packet counts.

• A RADIUS accounting start message is sent each time a sla-profile instance is created.

• Whenever a host disconnects a RADIUS, accounting stop message is sent for that host.

• If all host associated with an sla-profile instance disconnect, a RADIUS accounting stop message is sent for that instance.

This behavior means specific AVP may be in either host, sla-profile instance, or both accounting records. See RADIUS accounting table .

SR OS supports IPv4/IPv6 RADIUS connectivity for dot1x host authentication. IPv4 connectivity is supported through legacy configuration using the config>system>security>radius command. IPv4/IPv6 connectivity is supported through common RADIUS backend using the config>router>radius-server command.

The following SAP encapsulations are supported on the IES services:

• Ethernet null

• Ethernet dot1q

This feature allows customers of an IES, VPRN, or Epipe VLL service and connected to an Ethernet SAP on an Access PE to be backhauled through an Ethernet aggregation network using MPLS pseudowires terminating directly on a converged PE hosting the IES, VPRN, or Epipe VLL service. If Enhanced Subscriber Management over PW is also used, then the converged PE may also act as a BNG. This service is different from VLL Spoke-SDP termination on an IES or VPRN because access QoS policies can be applied directly at a centralized PE hosting the IES or VPRN instance. This feature uses the same concepts of pseudowire ports and pseudowire SAPs that are used for ESM over MPLS pseudowires, described in the 7450 ESS, 7750 SR, and VSR Triple Play Service Delivery Architecture Guide.

The MPLS pseudowire originates from the first hop aggregation PE (referred to as access PE) upstream of the Access-Node (or directly from a multi-service AN), and terminates on the converged PE. Multiple customers from a specific access-port on the Access-PE can be backhauled over a single MPLS pseudowire toward the converged PE. This capability allows the network to scale and does not require an MPLS pseudowire per customer between the Access-PE and the converged PE. The access-port on the Access-PE can be dot1q, q-in-q or NULL encapsulated. The converged PE terminates the MPLS pseudowire, decapsulates the received frames, and provides access QoS functions including HQoS, without requiring an internal or external loopback. Each MPLS pseudowire is represented on the BNG as a ‟PW-port” for which SAPs are created. These SAPs are termed ‟PW SAPs”, and must be statically configured on IES or VPRN interfaces or under the VLL service (unlike the ESM case where a capture SAP can be configured). The underlying Ethernet port must be in hybrid mode. Pseudowire SAPs are supported on Ethernet MDAs.

Network architecture using pseudowire SAPs illustrates the architecture of an aggregation network that uses pseudowire SAPs.

The packet is encapsulated on an Ethernet pseudowire, which is associated with a pseudowire port on the converged PE, and a spoke SDP on the access PE. The SDP could use an LDP LSP, RSVP LSP, segment routed tunnel, BGP RFC 8277 tunnel, or LDP over RSVP tunnel. Hash labels are not supported. The SDP may be bound to a port or a LAG, although shaping Vports for pseudowire ports on LAGs in distributed mode is not supported. If an SDP is rerouted, then the corresponding pseudowire ports are brought operationally down. Pseudowire ports are associated with an SDP by configuration.

Pseudowire SAPs support the QoS models allowed for regular VLL, IES or VPRN SAPs. These include:

• Per-service HQoS

  Note: This allows shaping of the total traffic per access node (and total traffic per class per AN), assuming one pseudowire per AN from the A-PE.

• SAP QoS support as available on the IOM3-XP, including

  • H-QoS (service scheduler child to port scheduler parent)

    • SAP queues attached to H-QoS scheduler by ‛parent’ statement

    • Scheduler attached to Port Scheduler by ‛port-parent’ statement

  • Direct service queue to port scheduler mapping

    • Aggregate-rate-limit

  Support for the redirection of SAP egress queues to an access queue group instance. It is possible to redirect SAP queues of a pseudowire SAP using the SAP based redirection for the IOM with Ethernet MDA, and policy based redirection for the IOM with Ethernet MDA, as applicable.

• Policing and H-POL

Pseudowire SAPs can be shaped on egress by a Vport on a physical port. The pseudowire SAP egress cannot explicitly declare which Vport to use, but they inherit the Vport used by the PW port egress shaping.

The intermediate destination identifier, used for ESM on MPLS pseudowires, is not applicable to VLL, IES and VPRN pseudowire SAPs.

If a pseudowire port is configured on a LAG, then Vport shaping is only supported if the LAG is in link mode.

Per-access node shaping is configured as follows:

1. Configure a Vport per AN under the port (or LAG) to which the SDP corresponding to the pseudowire SAP is bound. The Vport would be configured with aggregate rate-limit. (config>port>ethernet>access>egress>vport vport-name create).

2. Explicitly assign (by static configuration) a pseudowire port to a Vport. For limiting the total traffic to an AN, all pseudowire ports for an AN-port would refer to the same Vport.

For bandwidth control per pseudowire, the following configuration steps are used:

1. Create multiple Vports under the port to which SDP is bound. Each Vport can be configured with agg-rate rate, a scheduler or port-scheduler.

2. Assign each pseudowire to an AN to a unique Vport shaper (regular IOM/MDA).

To make use of the agg-rate rate or port-scheduler under a Vport, PW SAP queues and schedulers must be configured with the port-parent command. To make use of a scheduler under a Vport, PW SAP schedulers must be configured with a parent command and the parent-location vport under the tier 1 of the scheduler policy. The egress hierarchical parenting relationship options are shown in PW SAP egress scheduling hierarchy options. See the 7450 ESS, 7750 SR, 7950 XRS, and VSR Quality of Service Guide Quality of Service guide for more information.

PW ports may be bound to Vport schedulers bound to a LAG. However, if the LAG is configured in distributed mode, then bandwidth is shared according to the active LAG members across a single IOM. If the LAG spans multiple IOMs, then it effectively operates in link mode across the IOMs. That is, the full LAG bandwidth is allocated to the LAG members on each IOM. Therefore, the use of a Vport on a distributed mode LAG with a port scheduler on the port or Vport and PW SAPs is explicitly not supported and is not a recommended configuration. It is recommended that port-fair mode is used instead.

In the application where pseudowire SAPs are used to apply access QoS for services aggregated from an Ethernet access network, MPLS labels may not be present on the last-mile and link from an access node. In these cases, policers, queues and H-QoS schedulers should account for packets without MPLS overhead, modeled as ‟encaps-offset”. Vport and port schedulers behave as per the table below. In the data-path, the actual pseudowire encap overhead (taking into account the MPLS labels) added to the packet is tracked, and may be applied to the scheduler calculations via the configured packet-byte-offset.

The rate limit configured for the pseudowire SAP accounts for subscriber or service frame wire rate: without MPLS overhead and including the last mile overhead (unless a packet-byte-offset is configured).

Packet sizes used for pseudowire SAPs summarizes the default packet sizes used at each of the schedulers on the IOM/Ethernet MDA, assuming a 1000byte customer packet.

This section describes a mechanism in which one end on a pseudowire (the "master") dictates the active PW selection, which is followed by the other end of the PW (the 'slave'). This mechanism and associated terminology is specified in RFC6870.

Within a chassis, IOM and port based redundancy is based on active/backup LAG. The topology for the base MPLS LSP used by the SDP could be constrained such that it could get re-routed in the aggregation network, but would always appear on the LAG ports on the Layer 3 PE. In the case that the tunnel is re-routed to a different port, the MPLS pseudowire SAPs would be brought down.

To provide Layer 3 PE redundancy, dual homing of the access PE into separate Layer 3 PEs using active/standby pseudowire status is supported. This is shown in Dual homing into multiple Layer 3 PEs.

Dual homing operates in a similar manner to Spoke-SDP termination on IES/VPRN. Dual homing into multiple Layer 3 PEs displays the access PE is dual-homed to the Layer 3 PEs using two spoke-SDPs. The endpoint in the access PE is configured to be the master from a pseudowire redundancy perspective using the standby-signaling-master command. The access PE picks one of the Spoke-SDPs to make active, and one to make standby, based on the local configuration of primary or spoke SDP precedence.

The pseudowire port at the Layer 3 PE behaves as a slave from the perspective of pseudowire status signaling. That is, if its peer signals ‟PW FWD standby (0x20)” status bit for the specific Spoke-SDP and the local configuration does not allow this bit to be ignored, the PE takes the pseudowire port to a local operationally down state. This is consistent with the Spoke-SDP behavior for the case of Spoke-SDP termination on IES/VPRN.

As a consequence, all of the pseudowire SAPs bound to the pseudowire port are taken down, which causes the corresponding IES or VPRN interface to go to a local operationally down state and therefore stops forwarding packets toward this pseudowire port.

Conversely, the formerly standby pseudowire is made active and then the corresponding pseudowire port on the second Layer 3 PE is taken locally operationally up. Therefore, all of the pseudowire SAPs bound to the pseudowire port are brought up, which causes the corresponding IES or VPRN interface to go to a local operationally up state allowing forwarding of packets toward this pseudowire port.

For VLLs, a PW port always behaves as a slave from the perspective of PW redundancy. This is because the PW port is taken locally operationally down if any non-zero PW status (including a PW Preferential Forwarding status of standby) is received. Master-slave PW redundancy mechanisms for dual homing of the access PE into separate converged PEs using active or standby PW status are supported as shown in Master-slave PW redundancy . However, this is only applicable to VLL services consisting of only SAPs, PW-SAPs, or spoke-SDPs. Dual-homing redundancy, taking into account the status of the PW SAP, is not supported where a PBB tunnel between the two converged PEs exists in the Epipe VLL service.

As in the existing implementation, standby-signaling-master is configured on the Spoke-SDP at the access PE. However explicit configuration of standby-signaling-slave on the PW port is not required, as this is the default behavior.

The forwarding behavior is the same as when standby-signaling-slave is configured for Epipe Spoke-SDPs. That is, when enabled, if a PW Forwarding Standby (0x20) LDP status message is received for the P11111111W, then the transmit direction is blocked for the PW port. All PW SAPs bound to the corresponding PW port are treated from a SAP OAM perspective in the same manner as a fault on the service, such as an SDP-binding down or remote SAP down.

PW redundancy with multiple active/standby PW ports or PW SAPs bound to the same Ethernet SAP in the converged PE is not supported. The independent mode of operation for PW redundancy is not also supported for a PW port.

A PW port state may be linked to the state of an oper-group, such that if the oper-group goes down, the SDP binding for the PW port also goes operationally down, and therefore the corresponding PW status bit signaled (0x00000001 - Pseudowire Not Forwarding). If a status of 0x00000001 is signaled for a currently active PW, and active/standby dual homing is in use then the access PE fails over to the standby PW to the standby converged PE.

This is achieved by linking an SDP binding to an operational group for PW SAPs belonging to any supported service types (including those with group interfaces) bound to that PW port, such as IES, VPRN, or Epipe VLL. The association to an operational group is configured under the PW port config at the SDP binding level, as follows:

config
   service
      sdp
         binding
            [no] pw-port <pw-port-id> [vc-id <vc-id>] [create]
               monitor-oper-group <group-name>

The monitor-oper-group command specifies the operational group to be monitored by the PW-Port under which it is configured. The oper-group name must be already configured under the config>service context before its name is referenced in this command.

The following illustrates how a PW port can track the status of VPRN uplinks using monitor-oper-group.

Uplinks in a VPRN may be monitored using a BFD session on the network facing IP interfaces in a VPRN or on the network IP interfaces supporting the uplinks.

Oper-groups monitor the state of these BFD sessions inside the VPRN as follows:

config>service>
    oper-group "test-oper-grp" create
       bfd-enable interface "vprn-if" dest-ip 10.0.0.20 service 105

Alternatively, the state of network interfaces can be monitored as follows:

config>service>
   oper-group "test-oper-grp" create
      bfd-enable interface "network-if" dest-ip 10.0.1.20 

The PW port is then configured with monitor-oper-group as follows:

config>service>sdp>binding
            pw-port 100 vc-id 25
            monitor-oper-group "test-oper-group"

Static routes are used within many IES services. Unlike dynamic routing protocols, there is no way to change the state of routes based on availability information for the associated CPE. CPE connectivity check adds flexibility so that unavailable destinations are removed from the service provider’s routing tables dynamically and minimize wasted bandwidth.

The availability of the far-end static route is monitored through periodic polling. The polling period is configured. If the poll fails a specified number of sequential polls, the static route is marked as inactive.

An ICMP ping mechanism is used to test the connectivity.

If the connectivity check fails and the static route is deactivated, the router continues to send polls and re-activate any routes that are restored.

SRRP uses the same messaging format as VRRP with slight modifications. The source IP address is derived from the system IP address assigned to the local router. The destination IP address and IP protocol are the same as VRRP (224.0.0.18 and 112, respectively).

The message type field is set to 1 (advertisement) and the protocol version is set to 8 to differentiate SRRP message processing from VRRP message processing.

The vr-id field supports an SRRP instance ID of 32 bits.

Because of the large number of subnets backed up by SRRP, only one message every minute carries the gateway IP addresses associated with the SRRP instance. These gateway addresses are stored by the local SRRP instance and are compared with the gateway addresses associated with the local subscriber IP interface.

Unlike VRRP, only two nodes may participate in an SRRP instance due the explicit association between the SRRP instance group IP interface, the associated redundant IP interface and the multi-chassis synchronization (MCS) peering. Because only two nodes are participating, the VRRP skew timer is not used when waiting to enter the master state. Also, SRRP always preempts when the local priority is better than the current master and the backup SRRP instance always inherits the master’s advertisement interval from the SRRP advertisement messaging.

SRRP advertisement messages carry a becoming-master indicator flag. The becoming-master flag is set by a node that is attempting to usurp the master state from an existing SRRP master router. When receiving an SRRP advertisement message with a better priority and with the becoming-master flag set, the local master initiates its becoming-backup state, stops routing with the SRRP gateway MAC and sends an SRRP advertisement message with a priority set to zero. The new master continues to send SRRP advertisement messages with the becoming-master flag set until it either receives a return priority zero SRRP advertisement message from the previous master or its becoming-master state timer expires. The new backup node continues to send zero priority SRRP advertisement messages every time it receives an SRRP advertisement message with the becoming-master flag set. After the new master either receives the old masters priority zero SRRP advertisement message or the become-master state timer expires, it enters the master state. The become-master state timer is set to 10 seconds upon entering the become-master state.

The SRRP advertisement message is always evaluated to see if it has a higher priority than the SRRP advertisement that would be sent by the local node. If the advertised priority is equal to the current local priority, the source IP address of the received SRRP advertisement is used as a tie breaker. The node with the lowest IP address is considered to have the highest priority. SRRP does not preempt when priorities are equal. Preemption occurs only when priorities are specified. The lower IP address is only used as a tie-breaker when there is no master in the network. In other words, when both routers are changing from the ‟init” state, the lower IP is used to choose the master. If a master already exists, despite having the lower IP address, the system does not preempt the current master.

The SRRP instance maintains the source IP address of the current master. If an advertisement is received with the current masters source IP address and the local priority is higher priority than the masters advertised priority, the local node immediately enters the becoming-master state unless the advertised priority is zero. If the advertised priority is zero, the local node bypasses the becoming-master state and immediately enters the master state. Priority zero is a special case and is sent when an SRRP instance is relinquishing the master state.

To take full advantage of SRRP resiliency and diagnostic capabilities, the SRRP instance should be tied to a MCS peering that terminates on the redundant node. The SRRP instance is tied to the peering using the srrp srrp-id command within the appropriate MCS peering configuration. Once the peering is associated with the SRRP instance, MCS synchronizes the local information about the SRRP instance with the neighbor router. MCS automatically derives the MCS key for the SRRP instance based on the SRRP instance ID. For example, an SRRP instance ID of 1 would appear in the MCS peering database with a MCS-key srrp-0000000001.

The SRRP instance information stored and sent to the neighbor router consists of the following:

• SRRP instance MCS key

• containing service type and ID

• containing subscriber IP interface name

• subscriber subnet information

• containing group IP interface information

• SRRP group IP interface redundant IP interface name, IP address and mask

• SRRP advertisement message SAP

• local system IP address (SRRP advertisement message source IP address)

• group IP interface MAC address

• SRRP gateway MAC address

• SRRP instance administration state (up / down)

• SRRP instance operational state (disabled / becoming-backup / backup / becoming-master / master)

• current SRRP priority

• remote redundant IP interface availability (available / unavailable)

• local receive SRRP advertisement SAP availability (available / unavailable)

The SRRP instance uses the received information to verify provisioning and obtain operational status of the SRRP instance on the neighboring router.

In order for the network to reliably reach the owned IP addresses on a subscriber subnet, it is not necessary for the owning node to advertise the IP addresses as /32 host routes into the core. Network reachability to the subscriber subnet is advertised into the IGP core by both of the dual homing nodes. The shortest path to the subscriber may not always traverse the active path for a subscriber. In this case, the path traverses the non-active/primary node for the subscriber and the traffic is redirected through the redundant interface to the other node through the redundant interface to the active path. This ensures that all downstream traffic to a subscriber always flows through one node.

The SRRP gateway IP addresses on the subscriber subnets cannot be advertised as /32 host routes because they may be active (master) on multiple group IP interfaces on multiple SRRP routers. Without a /32 host route path, the network forwards any packet destined for an SRRP gateway IP address to the closest router advertising the subscriber subnet. While a case may be made that only a node that is currently forwarding for the gateway IP address in a master state should respond to ping or other diagnostic messages, the distribution of the subnet and the case of multiple masters make any resulting response or non-response inconclusive at best. To provide some ability to ping the SRRP gateway address from the network side reliably, any node receiving the ICMP ping request responds if the gateway IP address is defined on its subscriber subnet.

The group IP interface SAPs are designed to support subscriber hosts and perform an ingress anti-spoof function that ensures that any IP packet received on the group IP interface is coming in the correct SAP with the correct MAC address. If the IP and MAC are not registered as valid subscriber hosts on the SAP, the packet is silently discarded. Because the SRRP advertisement source IP addresses are not subscriber hosts, an anti-spoof entry does not exist and SRRP advertisement messages would normally be silently discarded. To avoid this issue, when a group IP interface SAP is configured to send and receive SRRP advertisement messages, anti-spoof processing on the SAP is disabled. This precludes subscriber host management on the SRRP messaging SAP.

BFD with SRRP is supported. This allows the use of longer timers inside SRRP resulting in more SRRP instances while still retaining fast failure detection with BFD.

Use the following CLI syntax to create an IES service:

The following example displays a basic IES service configuration for the 7450 ESS and 7750 SR:

A:ALA-48>config>service#
----------------------------------------------
...
ies 1001 customer 1730 vpn 1001 create
            description "to-internet"
            no shutdown
exit
----------------------------------------------
A:ALA-48>config>service#

The following example displays a basic IES service configuration for the 7950 XRS:

A:ALA-48>config>service#
----------------------------------------------
...
ies 1001 customer 1730 create
            description "to-internet"
            no shutdown
exit
----------------------------------------------
A:ALA-48>config>service#

Subscriber interfaces operate only with basic (or enhanced) subscriber management. At the very least, a host, either statically configured or dynamically learned by DHCP must be present in order for the interface to be useful.

The following example displays a subscriber interface configuration for the 7750 SR:

A:ALA-48>config>service>ies>sub-if# info
----------------------------------------------
                address 192.168.140.1/24
                group-interface "abc-if" create
                    sap 1/1/19:0 create
                        ingress
                            qos 2
                            filter ip 10
                        exit
                        static-host ip 192.168.145.100 mac 00:01:00:00:00:01 create
                        exit
                    exit
                exit
----------------------------------------------
A:ALA-48>config>service>ies>sub-if#

The following example displays an IES configuration with interface parameters for the 7450 ESS and 7750 SR:

A:ALA-48>config>service>ies>if# info
----------------------------------------------
                address 10.1.1.1/24
                sap 1/1/10:0.* create
                    ingress
                        qos 100
                    exit
                    egress
                        scheduler-policy "SLA1"
                    exit
                exit
                vrrp 1 owner
 authentication-key "3WErEDozxyQ" hash
                exit
----------------------------------------------
A:ALA-48>config>service>ies>if#

The following example displays an IES configuration with interface parameters for the 7950 XRS:

A:ALA-48>config>service>ies>if# info
----------------------------------------------
                address 10.1.1.1/24
                sap 1/1/10:0.* create
 exit
----------------------------------------------
A:ALA-48>config>service>ies>if#

The following example displays a spoke SDP configuration for the 7450 ESS and 7750 SR:

A:ALA-48>config>service>ies# info
----------------------------------------------
            description "to internet"
            interface "spokeSDP-test" create
                spoke-sdp 2:100 create
                    egress
                        filter ip 10
                    exit
                exit
            exit
            no shutdown
----------------------------------------------
A:ALA-48>config>service>ies#

A SAP is a combination of a port and encapsulation parameters which identifies the service access point on the interface and within the router. Each SAP must be unique within a router.

When configuring IES SAP parameters on a 7450 ESS or 7750 SR, a default QoS policy is applied to each ingress and egress SAP. Additional QoS policies and scheduler policies must be configured in the config>qos context. Filter policies are configured in the config>filter context and must be explicitly applied to a SAP. There are no default filter policies.

This example displays an IES SAP configuration for the 7450 ESS and 7750 SR:

*A:ALA-A>config>service>ies>if# info
----------------------------------------------
                address 10.10.36.2/24
                sap 5/1/3.1:0 create
                    ingress
                        qos 101
                    exit
                    egress
                        scheduler-policy "alpha"
                        qos 1010
                    exit
                exit
----------------------------------------------
*A:ALA-A>config>service>ies>if#

This example displays an IES SAP configuration for the 7950 XRS:

*A:ALA-A>config>service>ies>if# info
----------------------------------------------
                address 10.10.36.2/24
 exit
----------------------------------------------
*A:ALA-A>config>service>ies>if#

Configuring VRRP parameters on an IES interface is optional and applies only to the 7450 ESS and 7750 SR. VRRP can be configured in either an owner or non-owner mode. The owner is the VRRP router whose virtual router IP address is the same as the real interface IP address. This is the router that responds to packets addressed to one of the IP addresses for ICMP pings, TCP connections, and so on. All other virtual router instances participating in this message domain must have the same VRID configured and cannot be configured as owner.

For further information about VRRP CLI syntax and command descriptions, see the 7450 ESS, 7750 SR, 7950 XRS, and VSR Router Configuration Guide.

The following example displays the IES configuration:

*A:ALA-A>config>service>ies>if# info
----------------------------------------------
                address 10.10.36.2/24
                vrrp 2 owner
                    backup 10.10.36.2
 authentication-key "3WErEDozxyQ" hash
                exit
----------------------------------------------
*A:ALA-A>config>service#

The following output displays an IES service with IPsec parameters configured for the 7750 SR:

*A:ALA-49>config# info
----------------------------------------------
...
    service
        ies 100 customer 1 create
            interface "ipsec-public" create
                address 10.10.10.1/24
                sap ipsec-1.public:1 create
                exit
            exit
            no shutdown
        exit
    exit
...
----------------------------------------------
*A:ALA-49>config#

The following output displays an IES service with IGMP host tracking parameters configured.

*A:ALA-49>config>service# info
----------------------------------------------
...
         ies 25 customer 1 create
             interface "ip_if_4" create
                 loopback
                 hold-time down ip 1200
                 address 10.64.64.64/24
                 sap lag-64:64 create
                     no shutdown
                 exit
                 allow-directed-broadcasts
                 host-connectivity-verify
                 ip-mtu 9000
                 local-dhcp-server "server 1"
                 local-proxy-arp
                 proxy-arp-policy treetrace-1
                 remote-proxy-arp
                 secondary 10.3.4.5 255.255.255.0
                 secondary 10.3.4.5/24
                 tos-marking-state trusted
                 tos-marking-state untrusted
                 urpf-check
                 exit
             exit
             igmp-host-tracking
                 expiry-time 65535
                 no shutdown
             exit
...
----------------------------------------------
*A:ALA-49>config>service#