Internet Enhanced Service

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.

The following SAP encapsulations are supported on IES services:

• Ethernet null

• Ethernet dot1q

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 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, 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. Use the rate command option in the following context to configure the Vport with an aggregate rate-limit:

   • MD-CLI

     configure port ethernet access egress virtual-port aggregate-rate

   • classic CLI

     configure port ethernet access egress vport agg-rate-limit

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 an aggregate rate limit, a scheduler, or a port scheduler.

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

To configure the aggregate rate limit 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 tier 1 of the scheduler policy. The egress hierarchical parenting relationship options are shown in PW SAP egress scheduling hierarchy options. See the 7705 SAR Gen 2 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 datapath, 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 1000 byte 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 'standby'). 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. Use the following command to configure the endpoint in the access PE to be the master from a pseudowire redundancy perspective:

• MD-CLI

  configure service epipe endpoint standby-signaling master

• classic CLI

  configure service epipe endpoint standby-signaling-master

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 standby 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 standby 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-standby 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-standby 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 is configured to master on the spoke SDP at the access PE. However, explicit configuration of standby signaling to the standby on the PW port is not required, as this is the default behavior.

The forwarding behavior is the same as when standby-signaling is configured to standby 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.

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 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 reactivate any routes that are restored.

The following example displays a basic IES service configuration.

[ex:/configure service]
A:admin@node-2# info
    ies "1001" {
        admin-state enable
        description "to-internet"
        customer "1"
        vpn-id 1001
    }

A:node-2>config>service# info
----------------------------------------------
        ies 1001 name "1001" customer 1 vpn 1001 create
            description "to-internet"
            no shutdown
        exit
----------------------------------------------

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 7705 SAR Gen 2.

[ex:/configure service ies "11" subscriber-interface "test1"]
A:admin@node-2# info
    ipv4 {
        address 192.168.140.1 {
            prefix-length 24
        }
    }
    group-interface "abc-if" {
        sap 1/1/19:0 {
            ingress {
                qos {
                    sap-ingress {
                        policy-name "2"
                    }
                }
                filter {
                    ip "10"
                }
            }
            static-host {
                ipv4 192.168.145.100 mac 00:01:00:00:00:01 {
                }
            }
        }

A:node-2>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
----------------------------------------------

The following example shows a spoke-SDP configuration for the 7705 SAR Gen 2.

[ex:/configure service ies "4"]
A:admin@node-2# info
    admin-state enable
    description "to internet"
    customer "1"
    interface "spokeSDP-test" {
        spoke-sdp 2:100 {
            egress {
                filter {
                    ip "10"
                }
            }
        }
    }

A:node-2>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 service access point (SAP) is a combination of a port and encapsulation command options that identifies the SAP on the interface and within the router. Each SAP must be unique within a router.

When configuring IES SAP command options on a 7705 SAR Gen 2, a default QoS policy is applied to each ingress and egress SAP. Additional QoS policies and scheduler policies must be configured in the configure qos context. Filter policies are configured in the configure filter context and must be explicitly applied to a SAP. There are no default filter policies.

[ex:/configure service ies "2"]
A:admin@node-2# info
    customer "1"
    interface "test2" {
        sap 5/1/3.1:0 {
            ingress {
                qos {
                    sap-ingress {
                        policy-name "101"
                    }
                }
            }
            egress {
                qos {
                    sap-egress {
                        policy-name "1010"
                    }
                    scheduler-policy {
                        policy-name "alpha"
                    }
                }
            }
        }
        ipv4 {
            primary {
                address 10.10.36.2
                prefix-length 24
            }
        }
    }

A:node-2>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
----------------------------------------------

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.

See the 7705 SAR Gen 2 Router Configuration Guide for more information about VRRP.

The following example shows the VRRP on an IES interface configuration.

[ex:/configure service ies "16"]
A:admin@node-2# info
    customer "1"
    interface "test16" {
        ipv4 {
            primary {
                address 10.10.36.2
                prefix-length 24
            }
            vrrp 2 {
                authentication-key "McTNkSePNJMVFysxyZa4y1fsBIiad0g= hash2"
                backup [10.10.36.2]
                owner true
            }
        }
    }

A:node-2>config>service>ies>if$ info
----------------------------------------------
                address 10.10.36.2/24
                vrrp 2 owner
                    backup 10.10.36.2
                    authentication-key "McTNkSePNJMVFysxyZa4y1fsBIiad0g=" hash2
                exit
----------------------------------------------

The following example shows an IES service with IPsec configured for the 7705 SAR Gen 2.

[ex:/configure service]
A:admin@node-2# info
    ies "100" {
        admin-state enable
        customer "1"
        interface "ipsec-public" {
            admin-state enable
            sap ipsec-1.public:1 {
            }
            ipv4 {
                primary {
                    address 10.10.10.1
                    prefix-length 24
                }
            }
        }
    }

A:node-2>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
...
----------------------------------------------

The following example shows an IES service with IGMP host tracking configured.

[ex:/configure service]
A:admin@node-2# info
...
    ies "25" {
        admin-state enable
        customer "1"
        interface "ip_if_4" {
            ip-mtu 9000
            tos-marking-state untrusted
            sap lag-64:64 {
            }
            hold-time {
                ipv4 {
                    down {
                        seconds 1200
                    }
                }
            }
            ipv4 {
                allow-directed-broadcasts true
                local-dhcp-server "server 1"
                urpf-check {
                }
                primary {
                    address 10.64.64.64
                    prefix-length 24
                }
                secondary 10.3.4.5 {
                    prefix-length 24
                }
                neighbor-discovery {
                    local-proxy-arp true
                    remote-proxy-arp true
                    proxy-arp-policy ["treetrace-1"]
                }
                dhcp {
                    admin-state enable
                    description "server 1"
                    server [192.168.17.1]
                }
            }
        }
        igmp-host-tracking {
            expiry-time 65535     
        }

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