VLL Service Configuration Command Reference

Command Hierarchies

Apipe Service Configuration Commands

config
— service
apipe service-id [customer customer-id] [vpn vpn-id] [vc-type {atm-vcc | atm-sdu | atm-vpc | atm-cell}] [vc-switching] [test] [create]
— no apipe service-id
description description-string
[no] endpoint endpoint-name
active-hold-delay active-hold-delay
description description-string
revert-time revert-time
interworking frf-5
sap {port-id | aps-id}:[vpi/vci | vpi | vpi1.vpi2 | cp.conn-prof-id]
sap sap-id [no-endpoint]
sap sap-id [endpoint endpoint-name]
— no sap sap-id
accounting-policy acct-policy-id
atm
egress
traffic-desc traffic-desc-profile-id
traffic-desc traffic-desc-profile-id
[no] llf
oam
[no] alarm-cells
[no] terminate
[no] collect-stats
cpu-protection policy-id [mac-monitoring] | [eth-cfm-monitoring [aggregate] [car]]
description description-string
dist-cpu-protection policy-name
egress
[no] agg-rate
rate kilobits-per-second
— no rate
max-rate {rate | max}
[no] priority level
mbs-contribution size [{bytes | kilobytes}]
policer-control-policy policy-name
policer policer-id [create]
— no policer policer-id
cbs size [{bytes | kilobytes}]
no cbs
mbs size [{bytes | kilobytes}]
no mbs
packet-byte-offset {add add-bytes | subtract sub-bytes}
percent-rate pir-percent [cir cir-percent]
rate {rate | max} [cir {max | rate}]
stat-mode stat-mode
no stat-mode
qos policy-id [port-redirect-group queue-group-name instance instance-id]
— no qos
[no] queue queue-id
adaptation-rule [pir adaptation-rule] [cir adaptation-rule]
avg-frame-overhead percentage
burst-limit size-in-kbytes
high-prio-only percent
mbs {size-in-kbytes | default}
no mbs
[no] monitor-depth
parent {[weight weight] [cir-weight cir-weight]}
no parent
percent-rate pir-percent [cir cir-percent]
rate pir-rate [cir cir-rate]
no rate
[no] scheduler scheduler-name
parent [weight weight] [cir-weight cir-weight]
no parent
rate pir-rate [cir cir-rate]
no rate
scheduler-policy scheduler-policy-name
scheduling-class class-id
max-rate {rate | max}
[no] priority level
mbs-contribution size [bytes | kilobytes]
policer policer-id [create]
— no policer policer-id
cbs size [bytes | kilobytes]
no cbs
mbs size [bytes | kilobytes]
no mbs
packet-byte-offset add add-bytes | subtract sub-bytes}
percent-rate pir-percent [cir cir-percent]
rate {rate | max} [cir {max | rate}]
stat-mode stat-mode
no stat-mode
qos policy-id [shared-queuing] [fp-redirect-group queue-group-name instance instance-id]
— no qos
[no] queue queue-id
adaptation-rule [pir adaptation-rule] [cir adaptation-rule]
burst-limit size-in-kbytes
high-prio-only percent
mbs {size-in-kbytes | default}
no mbs
[no] monitor-depth
rate pir-rate [cir cir-rate]
no rate
[no] scheduler scheduler-name
parent [weight weight] [cir-weight cir-weight]
no parent
rate pir-rate [cir cir-rate]
no rate
scheduler-policy scheduler-policy-name
multi-service-site customer-site-name
[no] shutdown
service-mtu octets
service-name service-name
[no] shutdown
spoke-sdp [sdp-id[:vc-id] [no-endpoint]
spoke-sdp [sdp-id[:vc-id] endpoint endpoint-name [icb]
— no spoke-sdp [sdp-id[:vc-id]
[no] bandwidth
— no bfd-enable
bfd-template name
[no] clp-change
max-cells cell-count
— no max-cells [cell-count>]
max-delay delay-time
— no max-delay [delay-time]
refresh-timer value
request-timer timer1 retry-timer timer2 [timeout-multiplier multiplier]
[no] control-word
egress
qos network-policy-id port-redirect-group queue-group-name [instance instance-id]
— no qos
vc-label ingress-vc-label
— no vc-label [ingress-vc-label]
qos network-policy-id fp-redirect-group queue-group-name instance instance-id
— no qos
vc-label ingress-vc-label
— no vc-label [ingress-vc-label]
precedence [precedence-value | primary]
— no precedence
[no] pw-path-id
agi agi
— no agi
saii-type2 global-id:node-id:ac-id
— no saii-type2
taii-type2 global-id:node-id:ac-id
— no taii-type2
[no] shutdown
config
connection-profile conn-prof-id [create]
— no connection-profile conn-prof-id

Related Apipe Commands

Connection Profile Commands

config
connection-profile conn-prof-id [create]
— no connection-profile conn-prof-id
description description-string
member encap-value [create]
— no member encap-value

Cpipe Service Configuration Commands

config
— service
cpipe service-id [customer customer-id] [vpn vpn-id] [vc-type {satop-e1 | satop-t1 | cesopsn | cesopsn-cas}] [vc-switching] [test] [create]
— no cpipe service-id
description description-string
— no description [description-string]
endpoint endpoint-name [create]
— no endpoint endpoint-name
active-hold-delay active-endpoint-delay
description description-string
— no description [description-string]
revert-time revert-time
sap sap-id [no-endpoint] [create]
sap sap-id endpoint endpoint-name [create]
— no sap sap-id
accounting-policy acct-policy-id
— no accounting-policy [acct-policy-id]
cem
packet jitter-buffer milliseconds [payload-size bytes]
packet payload-size bytes
— no packet
[no] report-alarm [stray] [malformed] [pktloss] [overrun] [underrun] [rpktloss] [rfault] [rrdi]
[no] rtp-header
[no] collect-stats
cpu-protection policy-id [mac-monitoring] | [eth-cfm-monitoring [aggregate] [car]]
description description-string
— no description [description-string]
dist-cpu-protection policy-name
egress
[no] agg-rate
rate kilobits-per-second
— no rate
policer policer-id [create]
— no policer policer-id
cbs size [bytes | kilobytes]
no cbs
mbs size [bytes | kilobytes]
no mbs
packet-byte-offset add add-bytes | subtract sub-bytes}
percent-rate pir-percent [cir cir-percent]
rate {rate | max} [cir {max | rate}]
stat-mode stat-mode
no stat-mode
[no] qos [policy-id]
queue queue-id [create]
— no queue queue-id
adaptation-rule [pir adaptation-rule}] [cir adaptation-rule}]
avg-frame-overhead percent
burst-limit size-in-kbytes
high-prio-only percent
mbs size-in-kbytes
no mbs
parent {[weight weight] [cir-weight cir-weight]}
no parent
percent-rate pir-percent [cir cir-percent]
rate pir-rate [cir cir-rate]
no rate
scheduler scheduler-name [create]
— no scheduler scheduler-name
parent [weight weight] [cir-weight cir-weight]
no parent
rate pir-rate [cir cir-rate]
no rate
scheduler-policy scheduler-policy-name
policer policer-id [create]
— no policer policer-id
cbs size [bytes | kilobytes]
no cbs
mbs size [bytes | kilobytes]
no mbs
packet-byte-offset add add-bytes | subtract sub-bytes}
percent-rate pir-percent [cir cir-percent]
rate {rate | max} [cir {max | rate}]
stat-mode stat-mode
no stat-mode
[no] qos [policy-id]
queue queue-id [create]
— no queue queue-id
adaptation-rule [pir adaptation-rule}] [cir adaptation-rule}]
avg-frame-overhead percent
burst-limit size-in-kbytes
high-prio-only percent
mbs size-in-kbytes
no mbs
[no] monitor-depth
rate pir-rate [cir cir-rate]
no rate
scheduler scheduler-name [create]
— no scheduler scheduler-name
parent [weight weight] [cir-weight cir-weight]
no parent
rate pir-rate [cir cir-rate]
no rate
scheduler-policy scheduler-policy-name
multi-service-site customer-site-name
service-mtu octets
service-name service-name
[no] shutdown
spoke-sdp sdp-id[:vc-id] [no-endpoint] [create]
spoke-sdp sdp-id:vc-id [create] endpoint endpoint-name [icb]
— no spoke-sdp sdp-id[:vc-id]
accounting-policy acct-policy-id
bandwidth bw-value
bandwidth max
— no bandwidth
— no bfd-enable
bfd-template name
[no] collect-stats
refresh-timer value
request-timer timer1 retry-timer timer2 [timeout-multiplier multiplier]
[no] control-word
egress
qos network-policy-id port-redirect-group queue-group-name [instance instance-id]
— no qos
vc-label egress-vc-label
— no vc-label [egress-vc-label]
qos network-policy-id fp-redirect-group queue-group-name instance instance-id
— no qos
vc-label ingress-vc-label
— no vc-label [ingress-vc-label]
[no] pw-path-id
agi agi
— no agi
saii-type2 global-id:node-id:ac-id
— no saii-type2
taii-type2 global-id:node-id:ac-id
— no taii-type2
precedence [precedence-value| primary]
— no precedence
[no] shutdown

Epipe Service Configuration Commands

Epipe Global Commands

config
— service
[no] epipe service-id [customer customer-id] [test] [create] [vpn vpn-id] [vc-switching]
[no] bgp
pw-template-binding policy-id [import-rt {ext-community,.(upto 5 max)}]
— no pw-template-binding policy-id
[no] bfd-enable
bfd-template name
[no] shutdown
route-target {ext-community | {[export ext-community][import ext-community]}}
[no] bgp-vpws
[no] remote-ve-name name
ve-id value
— no ve-id
[no] shutdown
[no] ve-name name
ve-id value
— no ve-id
description description-string
[no] endpoint endpoint-name
active-hold-delay active-endpoint-delay
description description-string
revert-time [revert-time | infinite]
pw-port pw-port-id fpe fpe-id [create]
— no pw-port
egress
[no] shaper
int-dest-id name
vport vport
— no vport
monitor-oper-group group-name
[no] shutdown
service-mtu octets
service-name service-name
site name [create]
— no site
boot-timer seconds
— no boot-timer
sap sap-id
— no sap
site-min-down-timer min-down-time
site-id value
— no site-id
site-preference preference-value
[no] shutdown
spoke-sdp sdp-id[:vc-id] [vc-type {ether | vlan}] [create] [no-endpoint]
spoke-sdp sdp-id[:vc-id] [vc-type {ether | vlan}] [create] endpoint
— no spoke-sdp sdp-id[:vc-id]
[no] bfd-enable
bfd-template name
refresh-timer value
request-timer timer1 retry-timer timer2 [timeout-multiplier multiplier]
[no] control-word
— no hash-label
[no] pw-path-id
agi agi
— no agi
saii-type2 global-id:node-id:ac-id
— no saii-type2
taii-type2 global-id:node-id:ac-id
— no taii-type2

Epipe SAP Configuration Commands

config
— service
epipe service-id
sap sap-id [create] [no-endpoint]
sap sap-id [create] endpoint endpoint-name
— no sap sap-id
aarp aarpId type type
accounting-policy acct-policy-id
— no accounting-policy acct-policy-id
app-profile app-profile-name
atm
egress
traffic-desc traffic-desc-profile-id
encapsulation atm-encap-type
traffic-desc traffic-desc-profile-id
oam
[no] alarm-cells
cem
local-ecid emulated circuit identifier
— no local-ecid
packet jitter-buffer milliseconds [payload-size bytes]
packet payload-size bytes
— no packet
remote-ecid emulated circuit identifier
remote-mac ieee-address
— no remote-mac
[no] report-alarm [stray] [malformed] [pktloss] [overrun] [underrun] [rpktloss] [rfault] [rrdi]
[no] rtp-header
[no] cflowd
[no] collect-stats
cpu-protection policy-id [mac-monitoring] | [eth-cfm-monitoring [aggregate][car]]
description description-string
dist-cpu-protection policy-name
egress
[no] agg-rate
rate kilobits-per-second
— no rate
filter [ip ip-filter-id]
filter [ipv6 ipv6-filter-id]
filter [mac mac-filter-id]
— no filter [ip ip-filter-id] [ipv6 ipv6-filter-id] [mac mac-filter-id]
packet-byte-offset {add add-bytes | subtract sub-bytes}
queue queue-id
— no queue queue-id
mbs size {[bytes | kilobytes] | default}
no mbs
rate pir-rate
no rate
slope-policy hsmda-slope-policy-name allowable
wrr-weight weight
no wrr-weight
secondary-shaper secondary-shaper-name
wrr-policy hsmda-wrr-policy-name
— no wrr-policy
max-rate {rate | max}
[no] priority level
mbs-contribution size [bytes | kilobytes]
policer-control-policy policy-name
policer policer-id [create]
no policer policer-id
cbs size [bytes | kilobytes]
no cbs
mbs size [bytes | kilobytes]
no mbs
packet-byte-offset add add-bytes | subtract sub-bytes}
percent-rate pir-percent [cir cir-percent]
rate {rate | max} [cir {max | rate}]
stat-mode stat-mode
no stat-mode
qos policy-id [port-redirect-group queue-group-name instance instance-id]
— no qos
queue queue-id [create]
no queue queue-id
adaptation-rule [pir adaptation-rule] [cir adaptation-rule]
avg-frame-overhead percentage
cbs size-in-kbytes
no cbs
high-prio-only percent
mbs size [bytes|kilobytes]
no mbs
[no] monitor-depth
parent {[weight weight] [cir-weight cir-weight]}
percent-rate pir-percent [cir cir-percent]
rate pir-rate [cir cir-rate]
no rate
[no] scheduler scheduler-name
parent [weight weight] [cir-weight cir-weight]
no parent
rate pir-rate [cir cir-rate]
no rate
scheduler-policy scheduler-policy-name
[no] ais-enable
[no] mep mep-id domain md-index association ma-index [direction {up | down}] primary-vlan-enable [vlan vlan-id]
[no] ais-enable
[no] client-meg-level [[level [level ...]]
low-priority-defect {allDef | macRemErrXcon}
[no] interval {1 | 60}
[no] priority priority-value
[no] ccm-enable
[no] ccm-ltm-priority priority
ccm-padding-size ccm-padding
— no ccm-padding-size ccm-padding
[no] csf-enable
multiplier multiplier-value
no multiplier
[no] description description-string
[no] bit-error-threshold bit-errors
test-pattern {all-zeros | all-ones} [crc-enable]
[no] fault-propagation-enable {use-if-tlv | suspend-ccm}
low-priority-defect {allDef | macRemErrXcon | remErrXcon | errXcon | xcon | noXcon}
one-way-delay-threshold mac-address
[no] shutdown
mip [mac mac-address] primary-vlan-enable [vlan vlan-id]
mip default-mac
— no mip
[no] squelch-ingress-levels [md-level [md-level…]]
tunnel-fault [accept | ignore]
path path-index tag qtag[.qtag]
— no path path-index
[no] llf
[no] frf-12
[no] interleave
scheduling-class class-id
filter [ip ip-filter-id]
filter [ipv6 ipv6-filter-id]
filter [mac mac-filter-id]
— no filter [ip ip-filter-id] [ipv6 ipv6-filter-id] [mac mac-filter-id]
qos network-policy-id fp- redirect-group queue-group-name instance instance-id
— no qos
packet-byte-offset {add add-bytes | subtract sub-bytes}
[no] queue queue-id
rate pir-rate
no rate
slope-policy hsmda-slope-policy-name allowable
match-qinq-dot1p {top | bottom}
max-rate {rate | max}
[no] priority level
mbs-contribution size [bytes | kilobytes]
policer-control-policy policy-name
policer policer-id [create]
— no policer policer-id
cbs size-in-kilobytes
no cbs
mbs size [bytes | kilobytes]
no mbs
packet-byte-offset add add-bytes | subtract sub-bytes}
percent-rate pir-percent [cir cir-percent]
rate {rate | max} [cir {max | rate}]
stat-mode stat-mode
no stat-mode
qos policy-id [shared-queuing] [fp-redirect-group queue-group-name instance instance-id]
— no qos
[no] queue queue-id
adaptation-rule [pir adaptation-rule] [cir adaptation-rule]
cbs size-in-kilobytes
— no cbs
high-prio-only percent
mbs size [bytes | kilobytes]
— no mbs
[no] monitor-depth
parent {[weight weight] [cir-weight cir-weight]}
— no parent
percent-rate pir-percent [cir cir-percent]
rate pir-rate [cir cir-rate]
— no rate
[no] scheduler scheduler-name
parent [weight weight] [cir-weight cir-weight]
no parent
rate pir-rate [cir cir-rate]
no rate
scheduler-policy scheduler-policy-name
vlan-translation {vlan-id | copy-outer}
lag-link-map-profile link-map-profile-id
lag-per-link-hash class {1 | 2 | 3} weight [1..1024]
monitor-oper-group group-name
multi-service-site customer-site-name
oper-group group-name
— no oper-group
ring-node ring-node-name
— no ring-node
[no] shutdown
transit-policy {ip ip-aasub-policy-id | prefix prefix-aasub-policy-id}

Epipe Spoke SDP Configuration Commands

config
— service
epipe service-id
spoke-sdp sdp-id[:vc-id] [vc-type {ether | vlan}] [create] [no-endpoint]
spoke-sdp sdp-id[:vc-id] [vc-type {ether | vlan}] [create] endpoint [icb]
— no spoke-sdp sdp-id[:vc-id]
aarp aarpId type type
accounting-policy acct-policy-id
app-profile app-profile-name
bandwidth bandwidth
no bandwidth
[no] bfd-enable
bfd-template name
[no] collect-stats
[no] control-word
cpu-protection policy-id [mac-monitoring] | [eth-cfm-monitoring [aggregate][car]]
[no] description
[no] egress
filter [ip ip-filter-id]
filter [ipv6 ipv6-filter-id]
filter [mac mac-filter-id]
— no filter [ip ip-filter-id] [ipv6 ipv6-filter-id][mac mac-filter-id]
l2tpv3
cookie cookie
— no cookie
qos network-policy-id port-redirect-group queue-group-name [instance instance-id]
— no qos
[no] vc-label egress-vc-label
[no] entropy-label
[no] ais-enable
[no] client-meg-level [[level [level ...]]
[no] interval {1 | 60}
low-priority-defect {allDef | macRemErrXcon}
[no] priority priority-value
[no] ccm-enable
[no] ccm-ltm-priority priority
ccm-padding-size ccm-padding
— no ccm-padding-size ccm-padding
[no] csf-enable
multiplier multiplier-value
— no multiplier
[no] description
[no] test-pattern {all-zeros | all-ones} [crc-enable]
[no] fault-propagation-enable {use-if-tlv | suspend-ccm}
[no] one-way-delay-threshold seconds
[no] mip [{mac mac-address | default-mac}]
mep mep-id domain md-index association ma-index [direction {up | down}]
— no mep mep-id domain md-index association ma-index
[no] ccm-enable
ccm-ltm-priority priority
[no] description
ccm-padding-size ccm-padding
— noccm-padding-size ccm-padding
fault-propagation-enable {use-if-tlv | suspend-ccm}
low-priority-defect {allDe f |macRemErrXcon | remErrXcon | errXcon | xcon | noXcon}
[no] shutdown
[no] squelch-ingress-levels [md-level [md-level…]]
[no] hash-label
[no] ingress
filter [ip ip-filter-id]
filter [ipv6 ipv6-filter-id]
filter [mac mac-filter-id]
— no filter [ip ip-filter-id] [ipv6 ipv6-filter-id][mac mac-filter-id]
l2tpv3
cookie [cookie1][cookie2]
— no cookie
qos network-policy-id fp-redirect-group queue-group-name instance instance-id
— no qos
[no] vc-label egress-vc-label
monitor-oper-group group-name
precedence [precedence-value| primary]
— no precedence
[no] shutdown
transit-policy {ip ip-aasub-policy-id | prefix prefix-aasub-policy-id}
[no] use-sdp-bmac
vlan-vc-tag 0..4094
— no vlan-vc-tag [0..4094]
spoke-sdp-fec spoke-sdp-fec-id [fec fec-type] [aii-type aii-type] [create]
spoke-sdp-fec spoke-sdp-fec-id no-endpoint
spoke-sdp-fec spoke-sdp-fec-id [fec fec-type] [aii-type aii-type] [create] endpoint name [icb]
— no spoke-sdp-fec spoke-sdp-fec-id
[no] auto-config
path name
— no path
precedence prec-value
precedence primary
— no precedence
pw-template-bind policy-id
retry-count retry-count
retry-timer retry-timer
saii-type2 global-id:prefix:ac-id
— no saii-type2
[no] shutdown
signaling signaling
taii-type2 global-id:prefix:ac-id
— no taii-type2

Template Commands

configure
— service
epipe-sap-template name [create]
— no epipe-sap-template name
egress
[no] filter
ip filter-id
— no ip
ipv6 filter-id
— no ipv6
mac filter-id
— no mac
qos policy-id
— no qos
[no] filter
ip filter-id
— no ip
ipv6 filter-id
— no ipv6
mac filter-id
— no mac
qos policy-id {shared-queuing | multipoint-shared}
qos policy-id
— no qos

Fpipe Service Configuration Commands

config
— service
fpipe service-id [customer customer-id] [vpn vpn-id] [vc-type {fr-dlci}] [vc-switching]
— no fpipe service-id
description description-string
[no] endpoint endpoint-name
active-hold-delay active-endpoint-delay
description description-string
revert-time revert-time
sap sap-id [no-endpoint]
sap sap-id endpoint endpoint-name
— no sap sap-id
accounting-policy acct-policy-id
[no] collect-stats
cpu-protection policy-id [mac-monitoring] | [eth-cfm-monitoring [aggregate][car]]
description description-string
dist-cpu-protection policy-name
egress
[no] agg-rate
rate kilobits-per-second
— no rate
filter [ip ip-filter-id]
filter [ipv6 ipv6-filter-id]
— no filter [ip ip-filter-id] [ipv6 ipv6-filter-id]
max-rate {rate | max}
[no] priority level
mbs-contribution size [bytes | kilobytes]
policer-control-policy policy-name
policer policer-id [create]
— no policer policer-id
cbs size [bytes | kilobytes]
no cbs
mbs size [bytes | kilobytes]
no mbs
packet-byte-offset add add-bytes | subtract sub-bytes}
percent-rate pir-percent [cir cir-percent]
rate {rate | max} [cir {max | rate}]
stat-mode stat-mode
no stat-mode
qos policy-id
— no qos
[no] queue queue-id
adaptation-rule [pir adaptation-rule] [cir adaptation-rule]
avg-frame-overhead percent
burst-limit size-in-kbytes
high-prio-only percent
mbs {size-in-kbytes | default}
no mbs
[no] monitor-depth
parent {[weight weight] [cir-weight cir-weight]}
no parent
percent-rate pir-percent [cir cir-percent]
rate pir-rate [cir cir-rate]
no rate
[no] scheduler scheduler-name
parent [weight weight] [cir-weight cir-weight]
no parent
rate pir-rate [cir cir-rate]
no rate
scheduler-policy scheduler-policy-name
scheduling-class class-id
filter [ip ip-filter-id]
filter [ipv6 ipv6-filter-id]
— no filter [ip ip-filter-id] [ipv6 ipv6-filter-id]
policer policer-id [create]
— no policer policer-id
cbs size [bytes | kilobytes]
no cbs
mbs size [bytes | kilobytes]
no mbs
packet-byte-offset add add-bytes | subtract sub-bytes}
percent-rate pir-percent [cir cir-percent]
rate {rate | max} [cir {max | rate}]
stat-mode stat-mode
no stat-mode
qos policy-id [shared-queuing]
— no qos
[no] queue queue-id
adaptation-rule [pir adaptation-rule] [cir adaptation-rule]
avg-frame-overhead percent
burst-limit size-in-kbytes
high-prio-only percent
mbs {size-in-kbytes | default}
no mbs
[no] monitor-depth
rate pir-rate [cir cir-rate]
no rate
[no] scheduler scheduler-name
parent [weight weight] [cir-weight cir-weight]
no parent
rate pir-rate [cir cir-rate]
no rate
scheduler-policy scheduler-policy-name
scheduler-policy scheduler-policy-name
multi-service-site customer-site-name
[no] shutdown
service-mtu octets
service-name service-name
[no] shutdown
spoke-sdp sdp-id[:vc-id] [no-endpoint]
spoke-sdp sdp-id[:vc-id] endpoint endpoint-name [icb]
— no spoke-sdp sdp-id[:vc-id]
bandwidth bandwidth
— no bandwidth
— no bfd-enable
bfd-template name
egress
filter [ip ip-filter-id]
filter [ipv6 ipv6-filter-id]
— no filter [ip ip-filter-id] [ipv6 ipv6-filter-id]
qos network-policy-id port-redirect-group queue-group-name [instance instance-id]
— no qos
vc-label ingress-vc-label
— no vc-label [ingress-vc-label]
[no] entropy-label
[no] hash-label
filter [ip ip-filter-id]
filter [ipv6 ipv6-filter-id]
— no filter [ip ip-filter-id] [ipv6 ipv6-filter-id]
qos network-policy-id fp-redirect-group queue-group-name instance instance-id
— no qos
vc-label ingress-vc-label
— no vc-label [ingress-vc-label]
precedence [precedence-value| primary]
— no precedence
[no] shutdown

Ipipe Service Configuration Commands

config
— service
ipipe service-id [customer customer-id] [vpn vpn-id] [vc-switching]
— no ipipe service-id
ce-address-discovery [ipv6] [keep]
description description-string
[no] endpoint endpoint-name
active-hold-delay active-endpoint-delay
description description-string
revert-time revert-time
recovery-timer timer-value
[no] shutdown
sap sap-id [no-endpoint]
sap sap-id endpoint endpoint-name
[no] sap eth-tunnel-tunnel-id [:eth-tunnel-sap-id] [create]
— no sap sap-id
accounting-policy acct-policy-id
atm
egress
traffic-desc traffic-desc-profile-id
encapsulation atm-encap-type
traffic-desc traffic-desc-profile-id
oam
[no] alarm-cells
ce-address ip-address
— no ce-address
cpu-protection policy-id [mac-monitoring] | [eth-cfm-monitoring [aggregate][car]]
description description-string
dist-cpu-protection policy-name
egress
[no] agg-rate
rate kilobits-per-second
— no rate
filter {ip ip-filter-id | ipv6 ipv6-filter-id}
— no filter {ip ip-filter-id | ipv6 ipv6-filter-id}
secondary-shaper secondary-shaper-name
wrr-policy hsmda-wrr-policy-name
— no wrr-policy
packet-byte-offset {add add-bytes | subtract sub-bytes}
queue queue-id
— no queue queue-id
wrr-weight weight
no wrr-weight
mbs size {[bytes | kilobytes] | default}
no mbs
rate pir-rate
no rate
slope-policy hsmda-slope-policy-name allowable
policer policer-id [create]
— no policer policer-id
cbs size [bytes | kilobytes]
no cbs
mbs size [bytes | kilobytes]
no mbs
packet-byte-offset add add-bytes | subtract sub-bytes}
percent-rate pir-percent [cir cir-percent]
rate {rate | max} [cir {max | rate}]
stat-mode stat-mode
no stat-mode
qos policy-id
— no qos
[no] queue queue-id
adaptation-rule [pir adaptation-rule] [cir adaptation-rule]
avg-frame-overhead percent
burst-limit size-in-kbytes
high-prio-only percent
mbs {size-in-kbytes | default}
no mbs
[no] monitor-depth
parent {[weight weight] [cir-weight cir-weight]}
no parent
percent-rate pir-percent [cir cir-percent]
rate pir-rate [cir cir-rate]
no rate
[no] scheduler scheduler-name
parent [weight weight] [cir-weight cir-weight]
no parent
rate pir-rate [cir cir-rate]
no rate
scheduler-policy scheduler-policy-name
[no] mep mep-id domain md-index association ma-index [direction {up | down}]
[no] ccm-enable
[no] ccm-ltm-priority priority
[no] description
[no] bit-error-threshold bit-errors
[no] test-pattern {all-zeros | all-ones} [crc-enable]
[no] fault-propagation-enable {use-if-tlv | suspend-ccm}
low-priority-defect {allDef | macRemErrXcon | remErrXcon | errXcon | xcon | noXcon}
[no] one-way-delay-threshold mac-address
[no] one-way-delay-threshold <seconds>
[no] shutdown
[no] mip [{mac mac-address | default-mac}]
[no] squelch-ingress-levels [md-level [md-level…]]
tunnel-fault [accept | ignore]
path path-index tag qtag[.qtag]
— no path path-index
filter {ip ip-filter-id | ipv6 ipv6-filter-id}
— no filter {ip ip-filter-id | ipv6 ipv6-filter-id}
match-qinq-dot1p {top | bottom}
policer policer-id [create]
— no policer policer-id
cbs size [bytes | kilobytes]
no cbs
mbs size [bytes | kilobytes]
no mbs
packet-byte-offset add add-bytes | subtract sub-bytes}
percent-rate pir-percent [cir cir-percent]
rate {rate | max} [cir {max | rate}]
stat-mode stat-mode
no stat-mode
qos policy-id [shared-queuing]
— no qos
[no] queue queue-id
adaptation-rule [pir adaptation-rule] [cir adaptation-rule]
burst-limit size-in-kbytes
high-prio-only percent
mbs {size-in-kbytes | default}
no mbs
[no] monitor-depth
rate pir-rate [cir cir-rate]
no rate
[no] scheduler scheduler-name
parent [weight weight] [cir-weight cir-weight]
no parent
rate pir-rate [cir cir-rate]
no rate
scheduler-policy scheduler-policy-name
lag-link-map-profile link-map-profile-id
lag-per-link-hash class {1 | 2 | 3} weight [1..1024]
mac [ieee-address]
— no mac
mac-refresh [refresh interval]
multi-service-site customer-site-name
[no] shutdown
service-mtu octets
service-name service-name
[no] shutdown
spoke-sdp [sdp-id[:vc-id] [no-endpoint]
spoke-sdp [sdp-id[:vc-id] endpoint endpoint-name [icb]
— no spoke-sdp sap-id
bandwidth bandwidth
— no bandwidth
— no bfd-enable
bfd-template name
ce-address ip-address
— no ce-address
[no] control-word
egress
filter {ip ip-filter-id | ipv6 ipv6-filter-id}
— no filter {ip ip-filter-id | ipv6 ipv6-filter-id}
qos network-policy-id port-redirect-group queue-group-name [instance instance-id]
— no qos
[no] vc-label vc-label
[no] entropy-label
[no] hash-label
filter {ip ip-filter-id | ipv6 ipv6-filter-id}
— no filter {ip ip-filter-id | ipv6 ipv6-filter-id}
qos network-policy-id fp-redirect-group queue-group-name instance instance-id
— no qos
vc-label ingress-vc-label
— no vc-label [ingress-vc-label]
precedence [precedence-value| primary]
— no precedence
[no] shutdown

Command Descriptions

Generic Commands

shutdown

Syntax 
[no] shutdown
Context 
config>service>apipe
config>service>apipe>sap
config>service>apipe>spoke-sdp
config>service>cpipe
config>service>cpipe>sap
config>service>cpipe>spoke-sdp
config>service>epipe
config>service>epipe>bgp-vpws
config>service>epipe>sap
config>service>epipe>spoke-sdp
config>service>epipe>sap>eth-cfm>mep
config>service>epipe>spoke-sdp>eth-cfm>mep
config>service>fpipe
config>service>fpipe>sap
config>service>fpipe>spoke-sdp
config>service>ipipe
config>service>ipipe>sap
config>service>ipipe>spoke-sdp
config>service>epipe>pw-port
Description 

This command administratively disables an entity. When disabled, an entity does not change, reset, or remove any configuration settings or statistics.

The operational state of the entity is disabled as well as the operational state of any entities contained within. Many objects must be shut down before they may be deleted.

Services are created in the administratively down (shutdown) state. When a no shutdown command is entered, the service becomes administratively up and then tries to enter the operationally up state. Default administrative states for services and service entities is described below in Special Cases.

The no form of this command places the entity into an administratively enabled state.

Special Cases 
Service Admin State—
Bindings to an SDP within the service will be put into the out-of-service state when the service is shutdown. While the service is shutdown, all customer packets are dropped and counted as discards for billing and debugging purposes.
Service Operational State—
A service is regarded as operational providing that at least one SAP and one SDP are operational or if two SAPs are operational.
SDP (global)—
When an SDP is shutdown at the global service level, all bindings to that SDP are put into the out-of-service state and the SDP itself is put into the administratively and operationally down states. Packets that would normally be transmitted using this SDP binding will be discarded and counted as dropped packets.
SDP (service level)—
Shutting down an SDP within a service only affects traffic on that service from entering or being received from the SDP. The SDP itself may still be operationally up for other services.

description

Syntax 
description description-string
no description
Context 
config>service>apipe
config>service>apipe>sap
config>service>apipe>endpoint
config>service>cpipe
config>service>cpipe>endpoint
config>service>cpipe>sap
config>service>epipe
config>service>epipe>sap
config>service>epipe>spoke-sdp
config>service>epipe>endpoint
config>service>fpipe
config>service>fpipe>sap
config>service>fpipe>endpoint
config>service>ipipe
config>service>ipipe>sap
config>service>ipipe>endpoint
Description 

This command creates a text description stored in the configuration file for a configuration context. The description command associates a text string with a configuration context to help identify the content in the configuration file.

The no form of this command removes the string from the configuration.

Default 

No description associated with the configuration context.

Parameters 
description-string—
The description character string. Allowed values are any string up to 80 characters long composed of printable, 7-bit ASCII characters. If the string contains special characters (#, $, spaces, etc.), the entire string must be enclosed within double quotes.

Service Commands

apipe

Syntax 
apipe service-id [customer customer-id] [vpn vpn-id] [vc-type {atm-vcc | atm-sdu | atm-vpc | atm-cell}] [vc-switching] [test] [create]
no apipe service-id
Context 
config>service
Description 

The Apipe service provides a point-to-point Layer 2 VPN connection to a remote SAP or to another local SAP. An Apipe can connect an ATM or Frame Relay endpoint either locally or over a PSN to a remote endpoint of the same type or of a different type and perform interworking between the two access technologies.

Parameters 
service-id—
The unique service identification number or string identifying the service in the service domain. This ID must be unique to this service and may not be used for any other service of any type. The service-id must be the same number used for every 7450 ESS or 7750 SR on which this service is defined.
Values—
service-id:1 to 2147483648
svc-name: 64 characters maximum
customer customer-id
Specifies the customer ID number to be associated with the service. This parameter is required on service creation and optional for service editing or deleting.
Values—
1 to 2147483647
vpn vpn-id—
Specifies the VPN ID number which allows you to identify virtual private networks (VPNs) by a VPN identification number.
Values—
1 to 2147483647
Values—
null (0)
vc-type—
Keyword that specifies a 15 bit value that defines the type of the VC signaled to the peer. Its values are defined in draft-ietf-pwe3-iana-allocation and it defines both the signaled VC type as well as the resulting datapath encapsulation over the Apipe.
Values—
atm-vcc, atm-sdu, atm-vpc, atm-cell
Values—
atm-sdu
vc-switching—
Specifies if the pseudowire switching signaling is used for the spoke SDPs configured in this service.
test—
Specifies a unique test service type for the service context which will contain only a SAP configuration. The test service can be used to test the throughput and performance of a path for MPLS-TP PWs. This parameter is not supported on the 7950 XRS.

cpipe

Syntax 
cpipe service-id [customer customer-id] [vpn vpn-id] [vc-type {satop-e1 | satop-t1 | [vc-switching] |cesopsn | cesopsn-cas}] [vc-switching] [test] [create]
no cpipe service-id
Context 
config>service
Description 

This command configures a Circuit Emulation Services instance.

When a service is created, the customer keyword and customer-id must be specified and associates the service with a customer. The customer-id must already exist having been created using the customer command in the service context. Once a service has been created with a customer association, it is not possible to edit the customer association. The service must be deleted and recreated with a new customer association.

Once a service is created, the use of the customer customer-id is optional for navigating into the service configuration context. Attempting to edit a service with the incorrect customer-id specified will result in an error.

By default, no services exist until they are explicitly created with this command.

The no form of this command deletes the service instance with the specified service-id. The service cannot be deleted until the service has been shutdown.

Parameters 
service-id—
The unique service identification number or string identifying the service in the service domain. This ID must be unique to this service and may not be used for any other service of any type. The service-id must be the same number used for every router on which this service is defined.
Values—
service-id: 1to 2147483648
svc-name: Specifies an existing service name up to 64 characters in length.
customer customer-id
Specifies the customer ID number to be associated with the service. This parameter is required on service creation and optional for service editing or deleting.
Values—
1 to 2147483647
vpn vpn-id—
Specifies the VPN ID number which allows you to identify virtual private networks (VPNs) by a VPN ID. If this parameter is not specified, the VPN ID uses the same service ID number.
Values—
1 to 2147483647
Values—
null (0)
vc-type—
The vc-type defines the type of unstructured or structured circuit emulation service to be configured.
Values—
satop-e1: unstructured E1 circuit emulation service
satop-t1: unstructured DS1 circuit emulation service
cesopsn: basic structured n*64 kbps circuit emulation service
cesopsn-cas: structured n*64 kbps circuit emulation service with signaling
vc-switching—
Specifies if the pseudowire switching signaling is used for the spoke SDPs configured in this service.
test—
Specifies a unique test service type for the service context which will contain only a SAP configuration. The test service can be used to test the throughput and performance of a path for MPLS-TP PWs. This parameter applies to the 7450 ESS and 7750 SR only.
create—
Keyword used to create the service. The create keyword requirement can be enabled/disabled in the environment>create context.

epipe

Syntax 
epipe service-id customer customer-id [vpn vpn-id] [vc-switching] [create]
epipe service-id [test] [create]
no epipe service-id
Context 
config>service
Description 

This command configures an Epipe service instance. This command is used to configure a point-to-point epipe service. An Epipe connects two endpoints defined as Service Access Points (SAPs). Both SAPs may be defined in one 7450 ESS, 7750 SR, or 7950 XRS or they may be defined in separate devices connected over the service provider network. When the endpoint SAPs are separated by the service provider network, the far end SAP is generalized into a Service Distribution Point (SDP). This SDP describes a destination and the encapsulation method used to reach it.

No MAC learning or filtering is provided on an Epipe.

When a service is created, the customer keyword and customer-id must be specified and associates the service with a customer. The customer-id must already exist having been created using the customer command in the service context. Once a service has been created with a customer association, it is not possible to edit the customer association. The service must be deleted and recreated with a new customer association.

Once a service is created, the use of the customer customer-id is optional for navigating into the service configuration context. Attempting to edit a service with the incorrect customer-id specified will result in an error.

By default, no epipe services exist until they are explicitly created with this command.

The no form of this command deletes the epipe service instance with the specified service-id. The service cannot be deleted until the service has been shutdown.

Cpipe services are enabled on the 7450 ESS in mixed mode.

Parameters 
service-id—
The unique service identification number or string identifying the service in the service domain. This ID must be unique to this service and may not be used for any other service of any type. The service-id must be the same number used for every 7450 ESS, 7750 SR, or 7950 XRS on which this service is defined.
Values—
service-id: 1 to 2147483648
svc-name: 64 characters maximum
customer customer-id
Specifies the customer ID number to be associated with the service. This parameter is required on service creation and optional for service editing or deleting.
Values—
1 to 2147483647
vpn vpn-id—
Specifies the VPN ID number which allows you to identify virtual private networks (VPNs) by a VPN ID. If this parameter is not specified, the VPN ID uses the same service ID number.
Values—
1 to 2147483647
Values—
null (0)
vc-switching—
Specifies if the pseudowire switching signaling is used for the spoke SDPs configured in this service.
test—
Specifies a unique test service type for the service context which will contain only a SAP configuration. The test service can be used to test the throughput and performance of a path for MPLS-TP PWs. This parameter applies to the 7450 ESS and 7750 SR only.
create—
Keyword used to create the service instance. The create keyword requirement can be enabled/disabled in the environment>create context.

fpipe

Syntax 
fpipe service-id [customer customer-id] [vpn vpn-id] [vc-type {fr-dlci}] [vc-switching]
no fpipe service-id
Context 
config>service
Description 

This command configures an Fpipe service. An Fpipe provides a point-to-point L2 VPN connection to a remote SAP or to another local SAP. An Fpipe connects only Frame Relay endpoints either locally or over a PSN to a remote endpoint of the same type.

Parameters 
service-id—
The unique service identification number or string identifying the service in the service domain. This ID must be unique to this service and may not be used for any other service of any type. The service-id must be the same number used for every 7750 SR on which this service is defined.
Values—
service-id: 1 to 2147483648
svc-name: 64 characters maximum
customer customer-id
Specifies the customer ID number to be associated with the service. This parameter is required on service creation and optional for service editing or deleting.
Values—
1 to 2147483647
vpn vpn-id—
Specifies the VPN ID number which allows you to identify virtual private networks (VPNs) by a VPN identification number.
Values—
1 to 2147483647
Values—
null (0)
vc-type—
Specifies a 15 bit value that defines the type of the VC signaled to the peer. Its values are defined in draft-ietf-pwe3-iana-allocation and it defines both the signaled VC type as well as the resulting datapath encapsulation over the apipe.
Values—
fr-dlci
vc-switching—
Specifies if the pseudowire switching signaling is used for the spoke SDPs configured in this service.

ipipe

Syntax 
ipipe service-id [customer customer-id] [create] [vpn vpn-id] [vc-switching]
no ipipe service-id
Context 
config>service
Description 

This command configures an IP-Pipe service.

Parameters 
service-id—
The unique service identification number or string identifying the service in the service domain. This ID must be unique to this service and may not be used for any other service of any type. The service-id must be the same number used for every 7450 ESS or 7750 SR on which this service is defined.
Values—
service-id: 1 to 2147483648
svc-name: 64 characters maximum
customer customer-id
Specifies the customer ID number to be associated with the service. This parameter is required on service creation and optional for service editing or deleting.
Values—
1 to 2147483647
vpn vpn-id—
Specifies the VPN ID number which allows you to identify virtual private networks (VPNs) by a VPN identification number.
Values—
1 to 2147483647
Values—
null (0)
vc-switching—
Specifies if the pseudowire switching signaling is used for the spoke SDPs configured in this service.
create—
Keyword used to create the Ipipe service instance. The create keyword requirement can be enabled/disabled in the environment>create context.

VLL Global Commands

bgp

Syntax 
bgp
Context 
config>service>epipe
Description 

This command enables the context to configure the BGP related parameters BGP used for Multi-Homing and BGP VPWS.

The no form of this command removes the string from the configuration.

pw-template-binding

Syntax 
pw-template-binding policy-id [import-rt {ext-community,.(upto 5 max)}]
no pw-template-binding policy-id
Context 
config>service>epipe>bgp
Description 

This command binds the advertisements received with the route targets (RT) that match the configured list (either the generic or the specified import) to a specific pw-template. If the RT list is not present, or if multiple matches are found, the numerically lowest pw-template is used.

The pw-template-binding applies to BGP-VPWS when enabled in the Epipe.

For BGP VPWS, the following additional rules govern the use of pseudowire-template:

  1. On transmission, the settings for the L2-Info extended community in the BGP updates are derived from the pseudowire template attributes. If multiple pseudowire template bindings (with or without import-rt) are specified for the same VPWS instance the first pw-template entry will be used.
  2. On reception, the values of the parameters in the L2-Info extended community of the BGP updates are compared with the settings from the corresponding pseudowire template bindings. The following steps are used to determine the local pw-template:
    1. The RT values are matched to determine the pw-template.
    2. If multiple pw-template-binding matches are found from the previous step, the first (numerically lowest) configured pw-template entry will be considered.
    3. If the value used for Layer 2 MTU (unless the value zero is received) does not match the pseudowire is created but with the oper state down.
    4. If the value used for the S (sequenced delivery) flags is not zero the pseudowire is not created.

The tools perform commands can be used to control the application of changes in pw-template for BGP-VPWS.

The no form of the command removes the values from the configuration.

Parameters 
policy-id —
Specifies an existing policy ID.
Values—
1 to 2147483647
import-rt ext-comm —
Specifies the communities allowed to be accepted from remote PE neighbors. An extended BGP community in the type:x:y format. The value x can be an integer or IP address. The type can be the target or origin.
Values—

target:{ip-addr:comm-val | 2byte-asnumber:ext-comm-val| 4byte-snumber:comm-val}

ip-addr

a.b.c.d

comm-val

0 to 65535

2byte-asnumber

0 to 65535

ext-comm-val

0 to 4294967295

4byte-asnumber

0 to 4294967295

route-distinguisher

Syntax 
route-distinguisher auto-rd
no route-distinguisher
route-distinguisher rd
Context 
config>service>epipe>bgp
Description 

This command configures the Route Distinguisher (RD) component that is signaled in the MPBGP NLRI for L2VPN AFI. This value is used for BGP Multi-Homing and BGP-VPWS.

An RD value must be configured under BGP node.

Alternatively, the auto-rd option allows the system to automatically generate an RD based on the bgp-auto-rd-range command configured at the service level.

Format: Six bytes, other 2 bytes of type will be automatically generated.

Parameters 
ip-addr:comm-val—
Specifies the IP address.
Values—
ip-addr: a.b.c.d
comm-val: 0 to 65535
as-number:
as-number:ext-comm-val—
Specifies the AS number.
Values—
as-number: 1 to 65535
ext-comm-val : 0 to 4294967295
auto-rd—
The system will generate an RD for the service according to the IP address and range configured in the bgp-auto-rd-range command.
rd—
Specifies the route distinguisher.
Values—

<rd>

<ip-addr:comm-val> | <2byte-asnumber:ext-comm-val>|<4byte-asnumber:comm-val>

ip-addr

a.b.c.d

comm-val

0 to 65535

2byte-asnumber

1 to 65535

ext-comm-val

0 to 4294967295

4byte-asnumber

0 to 4294967295

route-target

Syntax 
route-target {ext-community | {[export ext-community][import ext-community]}}
no route-target
Context 
config>service>epipe>bgp
Description 

This command configures the route target (RT) component that is signaled in the related MPBGP attribute to be used for BGP Multi-Homing and BGP-VPWS when configured in the Epipe service. The ext-comm can have two formats:

  1. A two-octet AS-specific extended community, IPv4 specific extended community.
  2. An RT value must be configured under BGP node when BGP Epipe is configured.
Parameters 
export ext-community—
Specifies communities allowed to be sent to remote PE neighbors.
import ext-community—
Specifies communities allowed to be accepted from remote PE neighbors.

bgp-vpws

Syntax 
[no] bgp-vpws
Context 
config>service>epipe
Description 

This command enables the context to configure BGP-VPWS parameters and addressing.

Default 

no bgp-vpws

remote-ve-name

Syntax 
[no] remote-ve-name name
Context 
config>service>epipe>bgp-vpws
Description 

This command creates or edits a remote-ve-name. A single remote-ve-name can be created per BGP VPWS instance if the service is single-homed or uses a single pseudowire to connect to a pair of dual-homed systems. When the service requires active/standby pseudowires to be created to remote dual-homed systems then two remote-ve-names must be configured.

This context defines the remote PE to which a pseudowire will be signaled.

remote-ve-name commands can be added even if bgp-vpws is not shutdown.

The no form of the command removes the configured remote-ve-name from the bgp vpws node. It can be used when the BGP VPWS status is either shutdown or “no shutdown”.

Parameters 
name—
Specifies a site name up to 32 characters in length.

ve-id

Syntax 
ve-id value
no ve-id
Context 
config>service>epipe>bgp-vpws>ve-name
config>service>epipe>bgp-vpws>remote-ve-name
Description 

This command configures a ve-id for either the local VPWS instance when configured under the ve-name, or for the remote VPWS instance when configured under the remote-ve-name.

A single ve-id can be configured per ve-name or remote-ve-name. The ve-id can be changed without shutting down the VPWS instance. When the ve-name ve-id changes, BGP withdraws the previously advertised route and sends a route-refresh to all the peers which would result in reception of all the remote routes again. The old PWs are removed and new ones are instantiated for the new ve-id value.

When the remote-ve-name ve-id changes, BGP withdraws the previously advertised route and send a new update matching the new ve-id. The old pseudowires are removed and new ones are instantiated for the new ve-id value.

NLRIs received whose advertised ve-id does not match the list of ve-ids configured under the remote ve-id will not have a spoke-SDP binding auto-created but will remain in the BGP routing table but not in the L2 route table. A change in the locally configured ve-ids may result in auto-sdp-bindings either being deleted or created, based on the new matching results.

Each ve-id configured within a service must be unique.

The no form of the command removes the configured ve-id. It can be used just when the BGP VPWS status is shutdown. Command “no shutdown” cannot be used if there is no ve-id configured.

Default 

no ve-id

Parameters 
value—
A two bytes identifier that represents the local or remote VPWS instance and is advertised through the BGP NLRI.
Values—
1 to 65535

ve-name

Syntax 
[no] ve-name name
Context 
config>service>epipe>bgp-vpws
Description 

This command configures the name of the local VPWS instance in this service.

The no form of the command removes the ve-name.

Parameters 
name—
Specifies a site name up to 32 characters in length.

shutdown

Syntax 
[no] shutdown
Context 
config>service>epipe>bgp-vpws
Description 

This command administratively enables/disables the local BGP VPWS instance. On de-activation an MP-UNREACH-NLRI is sent for the local NLRI.

The no form of the command enables the BGP VPWS addressing and the related BGP advertisement. The associated BGP VPWS MP-REACH-NLRI will be advertised in an update message and the corresponding received NLRIs must be considered to instantiate the data plane.

Default 

shutdown

site

Syntax 
site name [create]
no site name
Context 
config>service>epipe
Description 

This command configures a Epipe site.

The no form of the command removes the name from the configuration.

Parameters 
name —
Specifies a site name up to 32 characters in length.
create —
This keyword is mandatory while creating a Epipe service.

boot-timer

Syntax 
boot-timer seconds
no boot-timer
Context 
config>service>epipe>site
Description 

This command configures for how long the service manger waits after a node reboot before running the DF election algorithm. The boot-timer value should be configured to allow for the BGP sessions to come up and for the NLRI information to be refreshed/exchanged.

The no form of the command reverts the default.

Default 

10

Parameters 
seconds —
Specifies the site boot-timer in seconds.
Values—
0 to 600

sap

Syntax 
sap sap-id
no sap
Context 
config>service>epipe>site
Description 

This command configures a SAP for the site.

The no form of the command removes the SAP ID from the configuration.

Parameters 
sap-id—
Specifies the physical port identifier portion of the SAP definition.

site-activation-timer

Syntax 
site-activation-timer seconds
no site-activation-timer
Context 
config>service>epipe>site
Description 

This command configures the time-period the system keeps the local sites in standby status, waiting for BGP updates from remote PEs before running the DF (designated-forwarder) election algorithm to decide whether the site should be unblocked. This timer is terminated if an update is received for which the remote PE has transitioned from DF to non-DF.

The no form of the command removes the value from the configuration.

Default 

2

Parameters 
seconds —
Specifies the site activation timer in seconds.
Values—
0 to 100

site-min-down-timer

Syntax 
site-min-down-timer min-down-time
no site-min-down-timer
Context 
config>service>epipe>site
Description 

This command configures the BGP multi-homing site minimum down time. When set to a non-zero value, if the site goes operationally down it will remain operationally down for at least the length of time configured for the site-min-down-timer, regardless of whether other state changes would have caused it to go operationally up. This timer is restarted every time that the site transitions from up to down. Setting this parameter to zero allows the minimum down timer to be disabled for this service.

The above operation is optimized in the following circumstances:

  1. If the site goes down on the designated forwarder but there are no BGP multi-homing peers with the same site in an UP state, then the site-min-down-timer is not started and is not used.
  2. If the site goes down on the designated forwarder but there are no active BGP multi-homing peers, then the site-min-down-timer is not started and is not used.
  3. If the site-min-down-timer is active and a BGP multi-homing update is received from the designated forwarder indicating its site has gone down, the site-min-down-timer is immediately terminated and this PE becomes the designated forwarder if the BGP multi-homing algorithm determines it should be the designated forwarder.

The no form of the command reverts to default value.

Default 

Taken from the value of site-min-down-timer configured for Multi-Chassis BGP Multi-Homing under the config>redundancy>bgp-multi-homing context.

Parameters 
min-down-time —
Specifies the time, in seconds, that a BGP multi-homing site remains operationally down after a transition from up to down.
Values—
0 to 100

site-id

Syntax 
site-id value
no site-id
Context 
config>service>epipe>site
Description 

This command configures the identifier for the site in this service. It must match between services but it is local to the service.

Parameters 
value —
Specifies the site identifier.
Values—
1 to 65535

site-preference

Syntax 
site-preference preference-value
no site-preference
Context 
config>service>epipe>site
Description 

This command defines the value to advertise in the VPLS preference field of the BGP VPWS and BGP Multi-homing NLRI extended community. This value can be changed without having to shutdown the site itself. The site-preference is only applicable to VPWS services.

When not configured, the default is zero, indicating that the VPLS preference is not in use.

Default 

no site-preference, value=0

Parameters 
preference-value—
Specifies the preference value to advertise in the NLRI L2 extended community for this site.
Values—
1 to 65535
primary—
Sets the site-preference to 65535
backup—
Sets the site-preference to 1

ce-address-discovery

Syntax 
[no] ce-address-discovery [ipv6] [keep]
Context 
config>service>ipipe
Description 

This command specifies whether the service will automatically discover the CE IP addresses.

When enabled, the addresses will be automatically discovered on SAPs that support address discovery, and on the spoke SDPs. When enabled, addresses configuration on the Ipipe SAP and spoke SDPs will not be allowed.

If disabled, CE IP addresses must be manually configured for the SAPs to become operationally up.

Default 

no ce-address-discovery

Parameters 
ipv6—
The ipv6 keyword enables IPv6 CE address discovery support on the Ipipe so that both IPv4 and IPv6 address discovery are supported. If the ipv6 keyword is not included, then only IPv4 address discovery is supported and IPv6 packets are dropped. This feature requires IOM2 or better. It requires chassis mode C or above. If any Ipipe services require IPv6 support, then all network ports on the node must be configured on 7750 SR IOM-3-XPs. For the 7450 ESS platforms, it requires mixed mode support and network chassis mode D to be enabled.
keep—
The keep keyword is only applicable to eth-legacy-fault-notification. This option maintains the CE address discovered even when the SAP on which the address was learned fails. The ARP entry will not be maintained if the SAP is administratively shutdown, the clear service id x {arp | neighbor} is used to remove the ARP entry or the node reboots.

stack-capability-signaling

Syntax 
[no] stack-capability-signaling
Context 
config>service>ipipe
Description 

This command enables stack capability signaling in the initial label mapping message of the ipipe PW to indicate that IPv6 is supported.

When enabled, the 7750 SR includes the stack capability TLV with the IPv6 stack bit set according to the ce-address-discovery ipv6 keyword, and also checks the value of the stack-capability TLV received from the far end.

This command must be blocked if no ce-address-discovery is specified, or the ipv6 keyword is not included with the ce-address-discovery command.

This command if only applicable to the ipipe service and must be blocked for all other services.

This command has no effect if both SAPs on the ipipe service are local to the node.

This feature requires IOM2 or better. It requires chassis mode C or above. If any Ipipe services require IPv6 support, then all network ports on the node must be configured on 7750 SR IOM-3-XPs. For the 7450 ESS platforms, it requires mixed mode support and network chassis mode D to be enabled.

Default 

no stack-capability-signaling

endpoint

Syntax 
[no] endpoint endpoint-name
Context 
config>service>apipe
config>service>cpipe
config>service>fpipe
config>service>epipe
config>service>ipipe
Description 

This command configures a service endpoint.

Parameters 
endpoint-name—
Specifies an endpoint name.

load-balancing

Syntax 
load-balancing
Context 
config>service>epipe>
Description 

This command enables the load-balancing context to configure interface per-flow load balancing options that will apply to traffic entering this interface and egressing over a LAG/ECMP on system-egress. This is a per interface setting. For load-balancing options that can also be enabled on the system level, the options enabled on the interface level overwrite system level configurations.

Default 

not applicable

per-service-hashing

Syntax 
[no] per-service-hashing
Context 
config>service>epipe>load-balancing
Description 

This command enables on a per service basis, consistent per-service hashing for Ethernet services over LAG, over Ethernet tunnel (eth-tunnel) using loadsharing protection-type or over CCAG. Specifically, it enables the new hashing procedures for Epipe, VPLS, regular or PBB services.

The following algorithm describes the hash-key used for hashing when the new option is enabled:

  1. If the packet is PBB encapsulated (contains an I-TAG ethertype) at the ingress side, use the ISID value from the I-TAG
  2. If the packet is not PBB encapsulated at the ingress side
    1. For regular (non-PBB) VPLS and Epipe services, use the related service ID
    2. If the packet is originated from an ingress IVPLS or PBB Epipe SAP
    3. If there is an ISID configured use the related ISID value
    4. If there is no ISID yet configured use the related service ID
    5. For BVPLS transit traffic use the related flood list id
    6. Transit traffic is the traffic going between BVPLS endpoints
    7. An example of non-PBB transit traffic in BVPLS is the OAM traffic
    8. The above rules apply regardless of traffic type
    9. Unicast, BUM flooded without MMRP or with MMRP, IGMP snooped

The no form of this command implies the use of existing hashing options.

Default 

no per-service-hashing

tunnel

Syntax 
tunnel service-id backbone-dest-mac ieee-address isid ISID
no tunnel
Context 
config>service>epipe>pbb
Description 

This command configures a Provider Backbone Bridging (PBB) tunnel with Backbone VPLS (B-VPLS) service information.

Parameters 
service-id —
Specifies the B-VPLS service for the PBB tunnel associated with this service.
Values—
service-id: 1 to 2147483648
svc-name: 64 characters maximum
backbone-dest-mac ieee-address
Specifies the backbone destination MAC-address for PBB packets.
isid ISID
Specifies a 24 bit service instance identifier for the PBB tunnel associated with this service. As part of the PBB frames, it is used at the destination PE as a demultiplexor field.
Values—
0 to 16777215

active-hold-delay

Syntax 
active-hold-delay active-hold-delay
no active-hold-delay
Context 
config>service>cpipe>endpoint
config>service>apipe>endpoint
config>service>fpipe>endpoint
config>service>ipipe>endpoint
config>service>epipe>endpoint
Description 

This command specifies that the node will delay sending the change in the T-LDP status bits for the VLL endpoint when the MC-LAG transitions the LAG subgroup which hosts the SAP for this VLL endpoint from active to standby or when any object in the endpoint. For example, SAP, ICB, or regular spoke SDP, transitions from up to down operational state.

By default, when the MC-LAG transitioned the LAG subgroup which hosts the SAP for this VLL endpoint from active to standby, the node sends immediately new T-LDP status bits indicating the new value of “standby” over the spoke SDPs which are on the mate-endpoint of the VLL. The same applies when any object in the endpoint changes an operational state from up to down.

There is no delay applied to the VLL endpoint status bit advertisement when the MC-LAG transitions the LAG subgroup which hosts the SAP from standby to active or when any object in the endpoint transitions to an operationally up state.

Default 

0 — A value of zero means that when the MC-LAG transitioned the LAG subgroup which hosts the SAP for this VLL endpoint from active to standby, the node sends immediately new T-LDP status bits indicating the new value of standby over the spoke SDPs which are on the mate-endpoint of the VLL. The same applies when any object in the endpoint changes an operational state from up to down.

Parameters 
active-hold-delay—
Specifies the active hold delay in 100s of milliseconds.
Values—
0 to 60

revert-time

Syntax 
revert-time [revert-time | infinite]
no revert-time
Context 
config>service>apipe>endpoint
config>service>fpipe>endpoint
config>service>cpipe>endpoint
config>service>epipe>endpoint
config>service>ipipe>endpoint
Description 

This command configures the time to wait before reverting back to the primary spoke SDP defined on this service endpoint, after having failed over to a backup spoke SDP.

Parameters 
revert-time—
Specifies the time, in seconds, to wait before reverting to the primary SDP.
Values—
0 to 600
Values—
0
infinite—
Causes the endpoint to be non-revertive.

eth-legacy-fault-notification

Syntax 
eth-legacy-fault-notification
Context 
config>service>ipipe
Description 

This is the top level of the hierarchy containing Ethernet to Legacy fault notification parameters. This context must activate using the no shutdown command before Ethernet to legacy fault notification can occur for iPipe services that make use of PPP, MLPPP or HDLC. This is only applicable to iPipe services with one legacy (PPP, MLPPP or HDLC) connection and an Ethernet SAP. No other services, not other combinations are supported.

recovery-timer

Syntax 
recovery-timer timer-value
no recovery-timer
Context 
config>service>ipipe>eth-legacy-fault-notification
Description 

This timer provides the legacy protocols PPP, MLPPP and HDLC time to establish after the Ethernet fault condition has cleared. The legacy protocol is afforded this amount of time to establish the connection before a fault is declared on the legacy side and propagated to the Ethernet segment. This timer is started as a result of a clearing Ethernet failure. Faults that may exist on the legacy side will not be detected until the expiration of this timer. Until the legacy side connection is established or the timer expires the traffic arriving on the Ethernet SAP from a peer will be discarded. The default value is unlikely to be a representative of all operator requirements and must be evaluated on a case by case basis.

Parameters 
timer-value—
The value of the wait time in tenths of a second (100ms). Granularity is in 500ms increments, starting from 1s and up to 30 seconds.
Values—
10 to 300
Values—
100

shutdown

Syntax 
[no] shutdown
Context 
config>service>ipipe>eth-legacy-fault-notification
Description 

This command enables or disables the propagation of fault from the Ethernet segment to the legacy connection using PPP, MLPPP and HDLC for an iPipe service. Issuing a “no shutdown” will activate the feature. Issuing a “shutdown” will deactivate the feature and stop fault notification from the Ethernet to PPP, MLPPP and HDLC protocols.

The no form of the command activates the ethernet legacy fault propagation.

Default 

shutdown

standby-signaling-master

Syntax 
[no] standby-signaling-master
Context 
config>service>vll>endpoint
Description 

When this command is enabled, the pseudowire standby bit (value 0x00000020) will be sent to T-LDP peer for each spoke-sdp of the endpoint that is selected as a standby.

This command is mutually exclusive with a VLL mate SAP created on a mc-lag/mc-aps or ICB. It is also mutually exclusive with vc-switching.

Default 

standby-signaling-master

standby-signaling-slave

Syntax 
[no] standby-signaling-slave
Context 
config>service>epipe>endpoint
config>service>epipe>spoke-sdp
Description 

When this command is enabled, the node will block the transmit forwarding direction of a spoke SDP based on the pseudowire standby bit received from a T-LDP peer.

This command is present at the endpoint level as well as the spoke-SDP level. If the spoke SDP is part of an explicit-endpoint, it will not be possible to change this setting at the spoke-sdp level. An existing spoke SDP can be made part of the explicit endpoint only if the settings do not conflict. A newly created spoke SDP, which is part of a given explicit-endpoint, will inherit this setting from the endpoint configuration.

This command is mutually exclusive with an endpoint that is part of an mc-lag, mc-aps or an ICB.

If the command is disabled, the node assumes the existing independent mode of behavior for the forwarding on the spoke SDP.

Default 

disabled

interworking

Syntax 
interworking frf-5
no interworking
Context 
config>service>apipe
Description 

This command specifies the interworking function that should be applied for packets that ingress/egress SAPs that are part of an Apipe service.

Interworking is applicable only when the two endpoints (i.e., the two SAPs or the SAP and the spoke-sdp) are of different types. Also, there are limitations on the combinations of SAP type, vc-type, and interworking values as shown in Table 11.

Table 11:  SAP types, VC-types and Interworking Values 

SAP Type

Allowed VC-Type Value

Allowed Interworking Value

ATM VC

atm-vcc, atm-sdu

none

fr-dlci

Not Supported

FR DLCI

fr-dlci

none

atm-sdu

frf-5

Default 

none (Interworking must be configured before adding a Frame-Relay SAP to an Apipe service.)

Parameters 
frf-5—
Specifies Frame Relay to ATM Network Interworking (FRF.5).

service-name

Syntax 
service-name service-name
no service-name
Context 
config>service>apipe
config>service>cpipe
config>service>fpipe
config>service>ipipe
config>service>epipe
Description 

This command configures an optional service name, up to 64 characters in length, which adds a name identifier to a given service to then use that service name in configuration references as well as display and use service names in show commands throughout the system. This helps the service provider/administrator to identify and manage services within the SR OS platforms.

All services are required to assign a service ID to initially create a service. However, either the service ID or the service name can be used o identify and reference a given service once it is initially created.

Parameters 
service-name—
Specifies a unique service name to identify the service. Service names may not begin with an integer (0 to 9).

service-mtu

Syntax 
service-mtu octets
no service-mtu
Context 
config>service>epipe
config>service>ipipe
config>service>apipe
config>service>cpipe
config>service>fpipe
Description 

This command configures the service payload (Maximum Transmission Unit – MTU), in bytes, for the service. This MTU value overrides the service-type default MTU. The service-mtu defines the payload capabilities of the service. It is used by the system to validate the SAP and SDP binding’s operational state within the service.

The service MTU and a SAP’s service delineation encapsulation overhead (4 bytes for a dot1q tag) is used to derive the required MTU of the physical port or channel on which the SAP was created. If the required payload is larger than the port or channel MTU, then the SAP will be placed in an inoperative state. If the required MTU is equal to or less than the port or channel MTU, the SAP will be able to transition to the operative state.

When binding an SDP to a service, the service MTU is compared to the path MTU associated with the SDP. The path MTU can be administratively defined in the context of the SDP. The default or administrative path MTU can be dynamically reduced due to the MTU capabilities discovered by the tunneling mechanism of the SDP or the egress interface MTU capabilities based on the next hop in the tunnel path. If the service MTU is larger than the path MTU, the SDP binding for the service will be placed in an inoperative state. If the service MTU is equal to or less than the path MTU, then the SDP binding will be placed in an operational state.

In the event that a service MTU, port or channel MTU, or path MTU is dynamically or administratively modified, then all associated SAP and SDP binding operational states are automatically re-evaluated.

Binding operational states are automatically re-evaluated.

For i-VPLS and Epipes bound to a b-VPLS, the service-mtu must be at least 18 bytes smaller than the b-VPLS service MTU to accommodate the PBB header.

Because this connects a Layer 2 to a Layer 3 service, adjust either the service-mtu under the Epipe service. The MTU that is advertised from the Epipe side is service-mtu minus EtherHeaderSize.

The no form of this command returns the default service-mtu for the indicated service type to the default value.

By default if no service-mtu is configured it is (1514 - 14) = 1500.

Default 

apipe, fpipe: 1508

ipipe: 1500

epipe: 1514

Table 12 shows MTU values for specific VC types.

Table 12:  MTU Values 

SAP VC-Type

Example: Service MTU

Advertised MTU

Ethernet

1514

1500

Ethernet (with preserved dot1q)

1518

1504

VPLS

1514

1500

VPLS (with preserved dot1q)

1518

1504

VLAN (dot1p transparent to MTU value)

1514

1500

VLAN (Q-in-Q with preserved bottom Qtag)

1518

1504

Parameters 
octets—
the size of the MTU in octets, expressed as a decimal integer
Values—
1 to 9194

pw-port

Syntax 
pw-port pw-port-id fpe fpe-id [create]
no pw-port
Context 
config>service>epipe
Description 

This command is used to associate the PW-port with the PXC ports or PXC based LAGs referenced in the FPE. In other words, the PW-port becomes anchored by the PXC. This enables an external PW that is mapped to the anchored PW-port to be seamlessly rerouted between the I/O ports without interruption of service on the PW-port. This mapping between the external PW (spoke SDP) and the PXC based PXC-port is performed via an Epipe operating in vc-switching mode (creation time parameter).

Default 

no pw-port

Parameters 
pw-port-id—
Specifies the PW-port associated with this service.
Values—
1 to 10239
fpe fpe-id
Specifies the FPE object which contains the PXC-based ports or PXC-based LAGs.
Values—
1 to 64

egress

Syntax 
egress
Context 
config>service>epipe>pw-port
Description 

This command enables the context to configure PW-port egress-side parameters

Default 

N/A

shaper

Syntax 
[no] shaper
Context 
config>service>epipe>pw-port>egress
Description 

This command enables the context to configure PW-port shaper parameters.

Default 

N/A

int-dest-id

Syntax 
int-dest-id name
no int-dest-id
Context 
config>service>epipe>pw-port>egress>shaper
Description 

This command configures an intermediate destination identifier applicable to ESM PW SAPs.

Default 

N/A

Parameters 
name—
Specifies the default intermediate destination identifier, up to 32 characters in length, on the egress side for this PW-port entry.

vport

Syntax 
vport vport
no vport
Context 
config>service>epipe>pw-port>egress>shaper
Description 

This command configures specifies the virtual port name of the shaper on the egress side for this PW-port entry.

Default 

N/A

Parameters 
vport—
Specifies a virtual port applicable to all PW SAPs.

monitor-oper-group

Syntax 
monitor-oper-group group-name
no monitor-oper-group
Context 
config>service>epipe>pw-port
Description 

This command configures the monitoring operational group name, up to 32 characters in length, associated with this PW-port entry.

Default 

N/A

Parameters 
group-name—
Specifies an operational group to monitor.

signaled-vc-type-override

Syntax 
signaled-vc-type-override {atm-vcc}
no signaled-vc-type-override
Context 
<root>
Description 

This command overrides the pseudowire type signaled to type 0x0009 N:1 VCC cell within an Apipe VLL service of vc-type atm-cell. Normally, this service vc-type signals a pseudowire of type 0x0003 ATM Transparent Cell.

This command is not allowed in an Apipe VLL of vc-type value atm-cell if a configured ATM SAP is not using a connection profile. Conversely, if the signaling override command is enabled, only an ATM SAP with a connection profile assigned will be allowed.

The override command is not allowed on Apipe VLL service of vc-type value other than atm-cell. It is also not allowed on a VLL service with the vc-switching option enabled since signaling of the PW FEC in a Multi-Segment PW (MS-PW) is controlled by the T-PE nodes. Thus for this feature to be used on a MS-PW, it is required to configure an Apipe service of vc-type atm-cell at the T-PE nodes with the signaled-vc-type-override enabled, and to configure a Apipe VLL service of vc-type atm-vcc at the S-PE node with the vc-switching option enabled.

The no form of this command returns the Apipe VLL service to signal its default pseudowire type

Default 

none

Parameters 
atm-vcc —
Specifies the pseudowire type to be signaled in the pseudowire establishment

connection-profile

Syntax 
connection-profile conn-prof-id [create]
no connection-profile conn-prof-id
Context 
<root>
Description 

This command creates a profile for the user to configure the list of discrete VPI/VCI values to be assigned to an ATM SAP of an Apipe VLL of vc-type atm-cell.

A connection profile can only be applied to a SAP which is part of an Apipe VLL service of vc-type atm-cell. The ATM SAP can be on a regular port or APS port.

A maximum of 8000 connection profiles can be created on the system.

The no form of this command deletes the profile from the configuration.

Default 

none

Parameters 
conn-prof-id —
Specifies the profile number.
Values—
1 to 8000

member

Syntax 
member encap-value [create]
no member encap-value
Context 
config>connection-profile
Description 

This command allows the adding of discrete VPI/VCI values to an ATM connection profile for assignment to an ATM SAP of an Apipe VLL of vc-type atm-cell.

Up to a maximum of 16 discrete VPI/VCI values can be configured in a connection profile. The user can modify the content of a profile which triggers a re-evaluation of all the ATM SAPs which are currently using the profile.

The no form of this command deletes the member from the configuration.

Default 

none

Parameters 
encap-value—
Specifies the VPI and VCI values of this connection profile member.
Values—
vpi: NNI: 0 to 4095
UNI: 0 to 255
vci: 1, 2, 5 to 65535

VLL SAP Commands

sap

Syntax 
sap sap-id [create] [no-endpoint]
sap sap-id [create] endpoint endpoint-name
no sap sap-id
Context 
config>service>apipe
config>service>cpipe
config>service>fpipe
config>service>ipipe
config>service>epipe
Description 

This command creates a Service Access Point (SAP) within a service. A SAP is a combination of port and encapsulation parameters which identifies the service access point on the interface and within the device. Each SAP must be unique.

All SAPs must be explicitly created. If no SAPs are created within a service or on an IP interface, a SAP will not exist on that object.

Enter an existing SAP without the create keyword to edit SAP parameters. The SAP is owned by the service in which it was created.

A SAP can only be associated with a single service. A SAP can only be defined on a port that has been configured as an access port. Channelized TDM ports are always access ports.

If a port is shutdown, all SAPs on that port become operationally down. When a service is shutdown, SAPs for the service are not displayed as operationally down although all traffic traversing the service will be discarded.

The operational state of a SAP is relative to the operational state of the port on which the SAP is defined.

The following are supported on the 7750 SR only:

  1. ATM VPI/VCI on an ATM port for vc-type atm-vcc and atm-sdu
  2. ATM VPI on an ATM port for vc-type atm-vpc
  3. ATM virtual trunk - a range of VPIs on an ATM port for vc-type atm-cell
  4. ATM port for vc-type atm-cell
  5. ATM connection profile for vc-type atm-cell
  6. Frame Relay DLCI on a port for vc-type atm-sdu
  7. ATM SAP carries the IPv4 packet using RFC 2684, VC-Mux or LLC/SNAP routed PDU encapsulation for an Ipipe service
  8. Frame Relay SAP RFC 2427, routed PDU encapsulation for an Ipipe service
  9. Ethernet SAP RFC 1332, PPP IPCP encapsulation of an IPv4 packet for an Ipipe service
  10. Ethernet SAP HDLC SAP uses the routed IPv4 encapsulation for an Ipipe service
  11. ATM - Frame Relay, PPP/IPCP - PPP/IPCP
  12. Frame Relay-Frame Relay, ATM - ATM
  13. Ethernet-Ethernet
  14. cHDLC-cHDLC
  15. An ATM SAP can be part of an IMA bundle.
  16. A PPP SAP can be part of an MLPPP bundle.
  17. A FR SAP can be part of a MLFR bundle.

Ethernet SAPs support null, dot1q, and qinq is supported for all routers.

The no form of this command deletes the SAP with the specified port. When a SAP is deleted, all configuration parameters for the SAP will also be deleted. For Internet Enhanced Service (IES), the IP interface must be shutdown before the SAP on that interface may be removed.

Default 

No SAPs are defined

Special Cases 
Special Cases—
A SAP can be defined with Ethernet ports, SONET/SDH or TDM channels. At most, only one sdp-id can be bound to an VLL service. Since a VLL is a point-to-point service, it can have, at most, two end points. The two end points can be one SAP and one SDP or two SAPs. Up to 49 SDPs can be associated with a service in a single router. Each SDP must have a unique router destination or an error will be generated.

A default SAP has the following format: port-id:*. This type of SAP is supported only on Ethernet MDAs and its creation is allowed only in the scope of Layer 2 services (Epipe and VPLS). This type of SAP is mutually exclusive with a SAP defined by explicit null encapsulation (for example, 1/1/1:0).

Two Frame Relay SAPs cannot be configured on an Apipe service on the 7750 SR. The limitation is for an Apipe service in local mode, which has two SAPs associated with the service, as opposed to a configuration with a SAP and a SDP in remote case, the only combination of the type of SAPs allowed is either two ATM SAPs or an ATM SAP and a Frame Relay SAP. The CLI prevents adding two Frame Relay SAPs under an Apipe service.

Parameters 
sap-id—
Specifies the physical port identifier portion of the SAP.
port-id—
Specifies the physical port ID.

If the card in the slot has Media Dependent Adapters (MDAs) installed, the port-id must be in the slot_number/MDA_number/port_number format. For example 6/2/3 specifies port 3 on MDA 2 in slot 6.

The port-id must reference a valid port type. When the port-id parameter represents SONET/SDH and TDM channels, the port ID must include the channel ID. A period “.” separates the physical port from the channel-id. The port must be configured as an access port.

If the SONET/SDH port is configured as clear-channel then only the port is specified.

port-id

slot/mda/port [.channel]

eth-sat-id

esat-id/slot/port

esat

keyword

id

1 to 20

pxc-id

pxc-id.sub-port

pxc

keyword

id

1 to 64

sub-port

a, b

endpoint—
Adds a SAP endpoint association.
no endpoint—
removes the association of a SAP or a spoke-sdp with an explicit endpoint name.
create—
Keyword used to create a SAP instance. The create keyword requirement can be enabled/disabled in the environment>create context.
Output 

Sample Output
*A:bksim2801>config>service>apipe>sap$ 
=================================================================
ATM PVCs, Port 1/1/1 
=================================================================
VPI/VCI     Owner     Type     Ing.TD   Egr.TD  Adm  OAM     Opr 
-----------------------------------------------------------------
2/102      SAP       PVC       1        1       up   ETE-AIS dn 
10/100     SAP       PVC       1        1       up   ETE-AIS dn 
=================================================================
*A:bksim2801# 

sap

Syntax 
[no] sap eth-tunnel-tunnel-id[:eth-tunnel-sap-id] [create]
Context 
config>service>epipe
config>service>ipipe
config>service>vpls
Description 

This command configures an Ethernet tunnel SAP.

An Ethernet tunnel control SAP has the format eth-tunnel-tunnel-id and is not configured with an Ethernet tunnel SAP ID. No Ethernet tunnel tags can be configured under a control SAP since the control SAP uses the control tags configured under the Ethernet tunnel port. This means that at least one member port and control tag must be configured under the Ethernet tunnel port before this command is executed. The control SAP is needed for carrying G.8031 and 802.1ag protocol traffic. This SAP can also carry user data traffic.

An Ethernet tunnel same-fate SAP has the format eth-tunnel-tunnel-id:eth-tunnel-sap-id. Same-fate SAPs carry only user data traffic. Multiple same-fate SAPs can be configured on one Ethernet tunnel port and share the fate of that port, provided the SAPs are properly configured with corresponding tags.

Ethernet tunnel SAPs are supported under VPLS, Epipe and Ipipe services only.

Default 

no sap

Parameters 
tunnel-id—
Specifies the tunnel ID.
Values—
1 to 1024
eth-tunnel-sap-id—
Specifies a SAP ID of a same-fate SAP.
Values—
0 to 4094

aarp

Syntax 
aarp aarpId type type
no aarp
Context 
config>service>epipe>sap
config>service>epipe>spoke-spd
Description 

This command associates an AARP instance with a multi-homed SAP or spoke SDP. This instance uses the same AARP ID in the same node to provide traffic flow and packet asymmetry removal for a multi-homed SAP or spoke SDP.

The type specifies the role of this service point in the AARP: either, primary (dual-homed) or secondary (dual-homed-secondary). The AA service attributes (app-profile and transit-policy) of the primary are inherited by the secondary endpoints. All endpoints within an AARP must be of the same type (SAP or spoke), and all endpoints with an AARP must be within the same service.

The no form of the command removes the association between an AARP instance and a multi-homed SAP or spoke SDP.

Default 

no aarp

Parameters 
aarpid—
specifies the AARP instance associated with this SAP. If not configured, no AARP instance is associated with this SAP.
Values—
1 to 65535
type—
specifies the role of the SAP referenced by the AARP instance
Values—
dual-homed — the primary dual-homed AA subscriber side service-point of an AARP instance; only supported for Epipe, IES, and VPRN SAP and spoke SDP
dual-homed-secondary — one of the secondary dual-homed AA subscriber side service-points of an AARP instance; only supported for Epipe, IES, and VPRN SAP and spoke SDP

lag-link-map-profile

Syntax 
lag-link-map-profile link-map-profile-id
no lag-link-map-profile
Context 
config>service>epipe>sap
config>service>ipipe>sap
Description 

This command assigns a pre-configured lag link map profile to a SAP/network interface configured on a LAG or a PW port that exists on a LAG. Once assigned/de-assigned, the SAP’s/network interface’s egress traffic will be re-hashed over LAG as required by the new configuration.

The no form of this command reverts the SAP/network interface to use per-flow, service or link hash as configured for the service/LAG.

Default 

no lag-link-map-profile

Parameters 
link-map-profile-id—
An integer from 1 to 64 that defines a unique lag link map profile on the LAG the SAP/network interface exists on.

lag-per-link-hash

Syntax 
lag-per-link-hash class {1 | 2 | 3} weight [1..1024]
no per-link-hash
Context 
config>service>epipe>sap
config>service>ipipe>sap
config>service>vpls>sap
config>service>ies>if>sap
config>service>vprn>if>sap
config>service>ies>sub-if>grp-if>sap
config>service>vprn>sub-if>grp-if>sap
Description 

This command configures weight and class to this SAP to be used on LAG egress when the LAG uses weighted per-link-hash.

The no form of this command restores default configuration.

Default 

no lag-per-link-hash (equivalent to weight 1 class 1)

monitor-oper-group

Syntax 
monitor-oper-group group-name
no monitor-oper-group
Context 
config>service>if
config>service>ies>spoke-sdp
config>service>ies>sap
Description 

This command specifies the operational group to be monitored by the object 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 no form of the command removes the association.

agg-rate

Syntax 
[no] agg-rate
Context 
config>service>apipe>sap>egress
config>service>cpipe>sap>egress
config>service>epipe>sap>egress
config>service>fpipe>sap>egress
config>service>ipipe>sap>egress
Description 

This command is used to control an HQoS aggregate rate limit. It is used in conjunction with the following parameter commands: rate, limit-unused-bandwidth, and queue-frame-based-accounting.

rate

Syntax 
rate kilobits-per-second
no rate
Context 
config>service>apipe>sap>egress>agg-rate
config>service>cpipe>sap>egress>agg-rate
config>service>epipe>sap>egress>agg-rate
config>service>fpipe>sap>egress>agg-rate
config>service>ipipe>sap>egress>agg-rate
Description 

This command defines the enforced aggregate rate for all queues associated with the agg-rate context. A rate must be specified for the agg-rate context to be considered to be active on the context’s object (SAP, subscriber, Vport, and so on).

Parameters 
kilobits-per-second—
the enforced aggregate rate for all queues associated with the agg-rate context, in kilobits per second
Values—
1 to 3200000000 | max

limit-unused-bandwidth

Syntax 
[no] limit-unused-bandwidth
Context 
config>service>apipe>sap>egress>agg-rate
config>service>cpipe>sap>egress>agg-rate
config>service>epipe>sap>egress>agg-rate
config>service>fpipe>sap>egress>agg-rate
config>service>ipipe>sap>egress>agg-rate
Description 

This command is used to enable (or disable) aggregate rate overrun protection on the agg-rate context.

queue-frame-based-accounting

Syntax 
[no] queue-frame-based-accounting
Context 
config>service>apipe>sap>egress>agg-rate
config>service>cpipe>sap>egress>agg-rate
config>service>fpipe>sap>egress>agg-rate
config>service>ipipe>sap>egress>agg-rate
Description 

This command is used to enable (or disable) frame based accounting on all policers and queues associated with the agg-rate context.

The command is supported on Ethernet ports only; it is not supported on HSMDA Ethernet ports.

Packet byte offset settings are not included in the applied rate when queue frame based accounting is configured; however the offsets are applied to the statistics.

policer-control-override

Syntax 
policer-control-override [create]
no policer-control-override
Context 
config>service>apipe>sap>egress
config>service>apipe>sap>ingress
config>service>cpipe>sap>egress
config>service>cpipe>sap>ingress
config>service>epipe>sap>egress
config>service>epipe>sap>igress
config>service>fpipe>sap>egress
config>service>fpipe>sap>ingress
config>service>ipipe>sap>egress
config>service>ipipe>sap>igress
Description 

This command, within the SAP ingress or egress contexts, creates a CLI node for specific overrides to the applied policer-control-policy. A policy must be applied for a policer-control-overrides node to be created. If the policer-control-policy is removed or changed, the policer-control-overrides node is automatically deleted from the SAP.

The no form of the command removes any existing policer-control-policy overrides and the policer-control-overrides node from the SAP.

Default 

no policer-control-override

Parameters 
create—
The create keyword is required when the policer-control-overrides node is being created and the system is configured to expect explicit confirmation that a new object is being created. When the system is not configured to expect explicit confirmation, the create keyword is not required.

max-rate

Syntax 
max-rate {rate | max}
Context 
config>service>apipe>sap>egress>policer-control-override
config>service>apipe>sap>ingress>policer-control-override
config>service>cpipe>sap>egress>policer-control-override
config>service>cpipe>sap>ingress>policer-control-override
config>service>epipe>sap>egress>policer-control-override
config>service>epipe>sap>igress>policer-control-override
config>service>fpipe>sap>egress>policer-control-override
config>service>fpipe>sap>ingress>policer-control-override
config>service>ipipe>sap>egress>policer-control-override
config>service>ipipe>sap>igress>policer-control-override
Description 

This command, within the SAP ingress and egress contexts, overrides the root arbiter parent policer max-rate that is defined within the policer-control-policy applied to the SAP.

When the override is defined, modifications to the policer-control-policy max-rate parameter have no effect on the SAP’s parent policer until the override is removed using the no max-rate command within the SAP.

Parameters 
rate—
Specifies the rate override in kilobits per second
Values—
1 to 2000000000
max—
Specifies the maximum rate override

priority-mbs-thresholds

Syntax 
priority-mbs-thresholds
Context 
config>service>apipe>sap>egress>policer-control-override
config>service>apipe>sap>ingress>policer-control-override
config>service>cpipe>sap>egress>policer-control-override
config>service>cpipe>sap>ingress>policer-control-override
config>service>epipe>sap>egress>policer-control-override
config>service>epipe>sap>ingress>policer-control-override
config>service>fpipe>sap>egress>policer-control-override
config>service>fpipe>sap>ingress>policer-control-override
config>service>ipipe>sap>egress>policer-control-override
config>service>ipipe>sap>ingress>policer-control-override
Description 

This command overrides the CLI node contains the configured min-thresh-separation and the various priority level mbs-contribution override commands.

min-thresh-separation

Syntax 
min-thresh-separation size [bytes | kilobytes]
Context 
config>service>apipe>sap>egress>policer-control-override>priority-mbs-threshold
config>service>apipe>sap>ingress>policer-control-override>priority-mbs-threshold
config>service>cpipe>sap>egress>policer-control-override>priority-mbs-threshold
config>service>cpipe>sap>ingress>policer-control-override>priority-mbs-threshold
config>service>epipe>sap>egress>policer-control-override>priority-mbs-threshold
config>service>epipe>sap>ingress>policer-control-override>priority-mbs-threshold
config>service>fpipe>sap>egress>policer-control-override>priority-mbs-threshold
config>service>fpipe>sap>ingress>policer-control-override>priority-mbs-threshold
config>service>ipipe>sap>egress>policer-control-override>priority-mbs-threshold
config>service>ipipe>sap>ingress>policer-control-override>priority-mbs-threshold
Description 

This command, within the SAP ingress and egress contexts, is used to override the root arbiter’s parent policer min-thresh-separation parameter that is defined within the policer-control-policy applied to the SAP.

When the override is defined, modifications to the policer-control-policy min-thresh-separation parameter have no effect on the SAP’s parent policer until the override is removed using the no min-thresh-separation command within the SAP.

The no form of the command removes the override and allows the min-thresh-separation setting from the policer-control-policy to control the root arbiter’s parent policer’s minimum discard threshold separation size.

Default 

no min-thresh-separation

Parameters 
size—
The minimum discard threshold separation override value
Values—
1 to 16777216 | default
bytes—
Signifies that size is expressed in bytes. The bytes and kilobytes keywords are mutually exclusive and optional. The default is kilobytes.
kilobytes—
Signifies that size is expressed in kilobytes. The bytes and kilobytes keywords are mutually exclusive and optional. The default is kilobytes.

priority

Syntax 
[no] priority level
Context 
config>service>apipe>sap>egress>policer-control-override>priority-mbs-threshold
config>service>apipe>sap>ingress>policer-control-override>priority-mbs-threshold
config>service>cpipe>sap>egress>policer-control-override>priority-mbs-threshold
config>service>cpipe>sap>ingress>policer-control-override>priority-mbs-threshold
config>service>epipe>sap>egress>policer-control-override>priority-mbs-thresholds
config>service>epipe>sap>ingress>policer-control-override>priority-mbs-thresholds
config>service>fpipe>sap>egress>policer-control-override>priority-mbs-threshold
config>service>fpipe>sap>ingress>policer-control-override>priority-mbs-threshold
config>service>ipipe>sap>egress>policer-control-override>priority-mbs-threshold
config>service>ipipe>sap>ingress>policer-control-override>priority-mbs-threshold
Description 

The priority-level level override CLI node contains the specified priority level’s mbs-contribution override value.

This node does not need to be created and will not be output in show or save configurations unless an mbs-contribution override exist for level.

Parameters 
level—
The level parameter is required when specifying priority-level and identifies which of the parent policer instances priority level’s the mbs-contribution is overriding.
Values—
1 to 8

mbs-contribution

Syntax 
mbs-contribution size [bytes | kilobytes]
Context 
config>service>apipe>sap>egress>policer-control-override>priority-mbs-threshold>priority
config>service>apipe>sap>ingress>policer-control-override>priority-mbs-threshold>priority
config>service>cpipe>sap>egress>policer-control-override>priority-mbs-threshold>priority
config>service>cpipe>sap>ingress>policer-control-override>priority-mbs-threshold>priority
config>service>epipe>sap>egress>policer-control-override>priority-mbs-threshold>priority
config>service>epipe>sap>ingress>policer-control-override>priority-mbs-threshold>priority
config>service>fpipe>sap>egress>policer-control-override>priority-mbs-threshold>priority
config>service>fpipe>sap>ingress>policer-control-override>priority-mbs-threshold>priority
config>service>ipipe>sap>egress>policer-control-override>priority-mbs-threshold>priority
config>service>ipipe>sap>ingress>policer-control-override>priority-mbs-threshold>priority
Description 

The mbs-contribution override command within the SAP ingress and egress contexts is used to override a parent policer’s priority level’s mbs-contribution parameter that is defined within the policer-control-policy applied to the SAP. This override allow the priority level’s burst tolerance to be tuned based on the needs of the SAP’s child policers attached to the priority level.

When the override is defined, modifications to the policer-control-policy priority level’s mbs-contribution parameter have no effect on the SAP’s parent policer priority level until the override is removed using the no mbs-contribution command within the SAP.

The no form of the command removes the override and allows the mbs-contribution setting from the policer-control-policy to control the parent policer’s priority level’s burst tolerance.

Default 

no mbs-contribution

Parameters 
size—
The mbs-contribution override value
Values—
1 to 16777216 | default
bytes—
Signifies that size is expressed in bytes. The bytes and kilobytes keywords are mutually exclusive and optional. The default is kilobytes.
kilobytes—
Signifies that size is expressed in kilobytes. The bytes and kilobytes keywords are mutually exclusive and optional. The default is kilobytes.

policer-control-policy

Syntax 
policer-control-policy policy-name [create]
no policer-control-policy
Context 
config>service>apipe>sap>egress
config>service>apipe>sap>ingress
config>service>fpipe>sap>egress
config>service>fpipe>sap>ingress
config>service>epipe>sap>egress
Description 

This command, within the QoS CLI node, is used to create, delete or modify policer control policies. A policer control policy is very similar to the scheduler-policy which is used to manage a set of queues by defining a hierarchy of virtual schedulers and specifying how the virtual schedulers interact to provide an aggregate SLA. In a similar fashion, the policer-control-policy controls the aggregate bandwidth available to a set of child policers. Once created, the policy can be applied to ingress or egress SAPs.

Policer Control Policy Instances

On the SAP side, an instance of a policy is created each time a policy is applied.

When applied to a sub-profile on a 7450 ESS and 7750 SR, an instance of the policy is created each time a subscriber successfully maps one or more hosts to the profile per ingress SAP.

Each instance of the policer-control-policy manages the policers associated with the object that owns the policy instance (SAP or subscriber). If a policer on the object is parented to an appropriate arbiter name that exists within the policy, the policer will be managed by the instance. If a policer is not parented or is parented to a non-existent arbiter, the policer will be orphaned and will not be subject to bandwidth control by the policy instance.

Maximum Rate and Root Arbiter

The policer-control-policy supports an overall maximum rate (max-rate) that defines the total amount of bandwidth that may be distributed to all associated child policers. By default, that rate is set to max which provides an unlimited amount of bandwidth to the policers. Once the policy is created, an actual rate should be configured in order for the policy instances to be effective. At the SAP level, the maximum rate may be overridden on a per instance basis.

For subscribers, the maximum rate may only be overridden on the subscriber profile which will then be applied to all instances associated with the profile.

The maximum rate is defined within the context of the root arbiter which is always present in a policer-control-policy. The system creates a parent policer which polices the output of all child policers attached to the policy instance to the configured rate. Child policers may be parented directly to the root arbiter (parent root) or parented to one of the tiered arbiters (parent arbiter-name). Since each tiered arbiter must be parented to either another tiered arbiter or the root arbiter (default), every parented child policer is associated with the root arbiter and thus the root arbiter’s parent policer.

Parent Policer PIR Leaky Bucket Operation

The parent policer is a single leaky bucket that monitors the aggregate throughput rate of the associated child policers. Forwarded packets increment the bucket by the size of each packet. The rate of the parent policer is implemented as a bucket decrement function which attempts to drain the bucket. If the rate of the packets flowing through the bucket is less than the decrement rate, the bucket does not accumulate depth. Each packet that flows through the bucket is accompanied by a derived discard threshold. If the current depth of the bucket is less than the discard threshold, the packet is allowed to pass through, retaining the colors derived from the packet’s child policer. If the current depth is equal to or greater than the threshold value, the packet is colored red and the bucket depth is not incremented by the packet size. Also, any increased bucket depths in the child policer are canceled making any discard event an atomic function between the child and the parent.

Due to the fact that multiple thresholds are supported by the parent policer, the policer control policy is able to protect the throughput of higher priority child policers from the throughput of the lower priority child policers within the aggregate rate.

Tier 1 and Tier 2 Arbiters

As stated above, each child is attached either to the always available root arbiter or to an explicitly created tier 1 or tier 2 arbiter. Unlike the hardware parent policer based root arbiter, the arbiters at tier 1 and tier 2 are only represented in software and are meant to provide an arbitrary hierarchical bandwidth distribution capability. An arbiter created on tier 2 must parent to either to an arbiter on tier 1 or to the root arbiter. Arbiters created on tier 1 always parent to the root arbiter. In this manner, every arbiter ultimately is parented or grand-parented by the root arbiter.

Each tiered arbiter supports an optional rate parameter that defines a rate limit for all child arbiters or child policers associated with the arbiter. Child arbiters and policers attached to the arbiter have a level attribute that defines the strict level at which the child is given bandwidth by the arbiter. Level 8 is the highest and 1 is the lowest. Also a weight attribute defines each child’s weight at that strict level in order to determine how bandwidth is distributed to multiple children at that level when insufficient bandwidth is available to meet each child’s required bandwidth.

Fair and Unfair Bandwidth Control

Each child policer supports three leaky buckets. The PIR bucket manages the policer’s peak rate and maximum burst size, the CIR leaky bucket manages the policer’s committed rate and committed burst size. The third leaky bucket is used by the policer control policy instance to manage the child policer’s fair rate (FIR). When multiple child policers are attached to the root arbiter at the same priority level, the policy instance uses each child’s FIR bucket rate to control how much of the traffic forwarded by the policer is fair and how much is unfair.

In the simplest case where all the child policers in the same priority level are directly attached to the root arbiter, each child’s FIR rate is set according to the child’s weight divided by the sum of the active children’s weights multiplied by the available bandwidth at the priority level. The result is that the FIR bucket will mark the appropriate amount of traffic for each child as fair-based on the weighted fair output of the policy instance.

The fair/unfair forwarding control in the root parent policer is accomplished by implementing two different discard thresholds for the priority. The first threshold is discard-unfair and the second is discard-all for packet associated with the priority level. As the parent policer PIR bucket fills (due the aggregate forwarded rate being greater than the parent policers PIR decrement rate) and the bucket depth reaches the first threshold, all unfair packets within the priority are discarded. This leaves room in the bucket for the fair packets to be forwarded.

In the more complex case where one or more tiered arbiters are attached at the priority level, the policer control policy instance must consider more than just the child policer weights associated with the attached arbiter. If the arbiter is configured with an aggregate rate limit that its children cannot exceed, the policer control policy instance will switch to calculating the rate each child serviced by the arbiter should receive and enforces that rate using each child policers PIR leaky bucket.

When the child policer PIR leaky bucket is used to limit the bandwidth for the child policer and the child’s PIR bucket discard threshold is reached, packets associated with the child policer are discarded. The child policer’s discarded packets do not consume depth in the child policer’s CIR or FIR buckets. The child policers discarded packets are also prevented from impacting the parent policer and will not consume the aggregate bandwidth managed by the parent policer.

Parent Policer Priority Level Thresholds

As stated above, each child policer is attached either to the root arbiter or explicitly to one of the tier 1 or tier 2 arbiters. When attached directly to the root arbiter, its priority relative to all other child policers is indicated by the parenting level parameter. When attached through one of the tiered arbiters, the parenting hierarchy of the arbiters must be traced through to the ultimate attachment to the root arbiter. The parenting level parameter of the arbiter parented to the root arbiter defines the child policer’s priority level within the parent policer.

The priority level is important since it defines the parent policer discard thresholds that will be applied at the parent policer. The parent policer has 8 levels of strict priority and each priority level has its own discard-unfair and discard-all thresholds. Each priority’s thresholds are larger than the thresholds of the lower priority levels. This ensures that when the parent policer is discarding, it will be priority sensitive.

To visualize the behavior of the parent policer, picture that when the aggregate forwarding rate of all child policers is currently above the decrement rate of the parent PIR leaky bucket, the bucket depth will increase over time. As the bucket depth increases, it will eventually cross the lowest priority’s discard-unfair threshold. If this amount of discard sufficiently lowers the remaining aggregate child policer rate, the parent PIR bucket will hover around this bucket depth. If however, the remaining aggregate child rate is still greater than the decrement rate, the bucket will continue to rise and eventually reach the lowest priority’s discard-all threshold which will cause all packets associated with the priority level to be discarded (fair and unfair). Again, if the remaining aggregate child rate is less than or equal to the bucket decrement rate, the parent PIR bucket will hover around this higher bucket depth. If the remaining aggregate child rate is still higher than the decrement rate, the bucket will continue to rise through the remaining priority level discards until equilibrium is achieved.

As noted above, each child’s rate feeding into the parent policer is governed by the child policer’s PIR bucket decrement rate. The amount of bandwidth the child policer offers to the parent policer will not exceed the child policer’s configured maximum rate.

Root Arbiter’s Parent Policer’s Priority Aggregate Thresholds

Each policer-control-policy root arbiter supports configurable aggregate priority thresholds which are used to control burst tolerance within each priority level. Two values are maintained per priority level; the shared-portion and the fair-portion. The shared-portion represents the amount of parent PIR bucket depth that is allowed to be consumed by both fair and unfair child packets at the priority level. The fair-portion represents the amount of parent PIR bucket depth that only the fair child policer packets may consume within the priority level. It should be noted that the fair and unfair child packets associated with a higher parent policer priority level may also consume the bucket depth set aside for this priority.

While the policy maintains a parent policer default or explicit configurable values for shared-portion and fair-portion within each priority level, it is possible that some priority levels will not be used within the parent policer. Most parent policer use cases require fewer than eight strict priority levels.

In order to derive the actual priority level discard-unfair and discard-all thresholds while only accounting for the actual in-use priority levels, the system maintains a child policer to parent policer association counter per priority level for each policer control policy instance. As a child policer is parented to either the root or a tiered arbiter, the system determines the parent policer priority level for the child policer and increments the association counter for that priority level on the parent policer instance.

The shared-portion for each priority level is affected by the parent policer global min-thresh-separation parameter that defines the minimum separation between any in-use discard thresholds. When more than one child policer is associated with a parent policer priority level, the shared-portion for that priority level will be the current value of min-thresh-separation. When only a single child policer is associated, the priority level’s shared-portion is zero since all packets from the child will be marked fair and the discard-unfair threshold is meaningless. When the association counter is zero, both the shared-portion and the fair-portion for that priority level are zero since neither discard thresholds will be used. Whenever the association counter is greater than 0, the fair-portion for that priority level will be derived from the current value of the priority’s mbs-contribution parameter and the global min-thresh-separation parameter.

Each priority level’s discard-unfair and discard-all thresholds are calculated based on an accumulation of lower priorities shared-portions and fair-portions and the priority level’s own shared-portion and fair-portion. The base threshold value for each priority level is equal to the sum of all lower priority level’s shared-portions and fair-portions. The discard-unfair threshold is the priority level’s base threshold plus the priority level’s shared-portion. The discard-all threshold for the priority level is the priority level’s base threshold plus both the shared-portion and fair-portion values of the priority. As can be seen, an in-use priority level’s thresholds are always greater than the thresholds of lower priority levels.

Policer Control Policy Application

A policer-control-policy may be applied on any Ethernet ingress or egress SAP that is associated with a port (or ports in the case of LAG).

The no form of the command removes a non-associated policer control policy from the system. The command will not execute when policer-name is currently associated with any SAP context.

Default 

none

Parameters 
policy-name—
Each policer-control-policy must be created with a unique policy name. The name must given as policy-name must adhere to the system policy ASCII naming requirements. If the defined policy-name already exists, the system will enter that policy’s context for editing purposes. If policy-name does not exist, the system will attempt to create a policy with the specified name. Creating a policy may require use of the create parameter when the system is configured for explicit object creation mode.
create—
The keyword is required when a new policy is being created and the system is configured for explicit object creation mode.

policer-override

Syntax 
[no] policer-override
Context 
config>service>apipe>sap>egress
config>service>apipe>sap>ingress
config>service>cpipe>sap>egress
config>service>cpipe>sap>ingress
config>service>epipe>sap>egress
config>service>epipe>sap>ingress
config>service>fpipe>sap>egress
config>service>fpipe>sap>ingress
config>service>ipipe>sap>egress
config>service>ipipe>sap>ingress
Description 

This command, within the SAP ingress or egress contexts, is used to create a CLI node for specific overrides to one or more policers created on the SAP through the sap-ingress or sap-egress QoS policies.

The no form of the command is used to remove any existing policer overrides.

Default 

no policer-overrides

policer

Syntax 
policer policer-id [create]
no policer policer-id
Context 
config>service>apipe>sap>egress>policer-override
config>service>apipe>sap>ingress>policer-override
config>service>cpipe>sap>egress>policer-override
config>service>cpipe>sap>ingress>policer-override
config>service>fpipe>sap>egress>policer-override
config>service>fpipe>sap>ingress>policer-override
config>service>ipipe>sap>egress>policer-override
config>service>ipipe>sap>ingress>policer-override
config>service>epipe>sap>egress>policer-override
Description 

This command, within the SAP ingress or egress contexts, is used to create a CLI node for specific overrides to a specific policer created on the SAP through a sap-ingress or sap-egress QoS policy.

The no form of the command is used to remove any existing overrides for the specified policer-id.

Parameters 
policer-id—
The policer-id parameter is required when executing the policer command within the policer-overrides context. The specified policer-id must exist within the sap-ingress or sap-egress QoS policy applied to the SAP. If the policer is not currently used by any forwarding class or forwarding type mappings, the policer will not actually exist on the SAP. This does not preclude creating an override context for the policer-id.
create—
The create keyword is required when a policer policer-id override node is being created and the system is configured to expect explicit confirmation that a new object is being created. When the system is not configured to expect explicit confirmation, the create keyword is not required.

cbs

Syntax 
cbs size [{bytes | kilobytes}]
no cbs
Context 
config>service>apipe>sap>egress>policer-override>policer
config>service>apipe>sap>ingress>policer-override>policer
config>service>cpipe>sap>egress>policer-override>policer
config>service>cpipe>sap>ingress>policer-override>policer
config>service>ipipe>sap>egress>policer-override>policer
config>service>ipipe>sap>ingress>policer-override>policer
config>service>epipe>sap>egress>policer-override>policer
Description 

This command, within the SAP ingress and egress policer-overrides contexts, is used to override the sap-ingress and sap-egress QoS policy configured CBS parameter for the specified policer-id.

The no form of this command returns the CBS size to the default value.

Default 

no cbs

Parameters 
size —
The size parameter is required when specifying cbs override and is expressed as an integer representing the required size in either bytes or kilobytes. The default is kilobytes. The optional byte and kilobyte keywords are mutually exclusive and are used to explicitly define whether size represents bytes or kilobytes.
Values—
0 to 16777216 | default
bytes—
When bytes is defined, the value given for size is interpreted as the policer’s MBS value in bytes.
kilobytes—
When kilobytes is defined, the value given for size is interpreted as the policer’s MBS value in kilobytes.

mbs

Syntax 
mbs size [{bytes | kilobytes}]
no mbs
Context 
config>service>apipe>sap>egress>policer-override
config>service>apipe>sap>ingress>policer-override>policer
config>service>cpipe>sap>egress>policer-override
config>service>cpipe>sap>ingress>policer-override>policer
config>service>ipipe>sap>egress>policer-override
config>service>ipipe>sap>ingress>policer-override>policer
config>service>epipe>sap>egress>policer-override>policer
config>service>epipe>sap>ingress>policer-override>policer
Description 

This command, within the SAP ingress and egress policer-overrides contexts, is used to override the sap-ingress and sap-egress QoS policy configured mbs parameter for the specified policer-id.

The no form of the command is used to restore the policer’s mbs setting to the policy defined value.

Default 

no mbs

Parameters 
size —
The size parameter is required when specifying mbs override and is expressed as an integer representing the required size in either bytes or kilobytes. The default is kilobytes. The optional byte and kilobyte keywords are mutually exclusive and are used to explicitly define whether size represents bytes or kilobytes.
Values—
0 to 16777216 | default
bytes—
When bytes is defined, the value given for size is interpreted as the policer’s MBS value in bytes.
kilobytes—
When kilobytes is defined, the value given for size is interpreted as the policer’s MBS value in kilobytes.

packet-byte-offset

Syntax 
packet-byte-offset {add add-bytes | subtract sub-bytes}
Context 
config>service>apipe>sap>egress>policer-override>policer
config>service>apipe>sap>ingress>policer-override>policer
config>service>cpipe>sap>egress>policer-override>policer
config>service>cpipe>sap>ingress>policer-override>policer
config>service>ipipe>sap>egress>policer-override>policer
config>service>ipipe>sap>ingress>policer-override>policer
config>service>epipe>sap>egress>policer-override>policer
Description 

This command, within the SAP ingress and egress policer-overrides contexts, is used to override the sap-ingress and sap-egress QoS policy configured packet-byte-offset parameter for the specified policer-id. Packet byte offset settings are not included in the applied rate when (queue) frame based accounting is configured; however, the offsets are applied to the statistics.

The no packet-byte-offset command is used to restore the policer’s packet-byte-offset setting to the policy defined value.

Default 

no packet-byte-offset

Parameters 
add-bytes—
Specifies the number of bytes that are added to the size each packet associated with the policer for rate metering, profiling and accounting purposes. From the policer’s perspective, the maximum packet size is increased by the amount being added to the size of each packet.
Values—
1 to 31
sub-bytes—
Specifies the number of bytes that are subtracted from the size of each packet associated with the policer for rate metering, profiling and accounting purposes. From the policer’s perspective, the maximum packet size is reduced by the amount being subtracted from the size of each packet.
Values—
1 to 64

percent-rate

Syntax 
percent-rate pir-percent [cir cir-percent]
no percent-rate
Context 
config>service>apipe>sap>egress>policer-override>policer
config>service>apipe>sap>ingress>policer-override>policer
config>service>cpipe>sap>egress>policer-override>policer
config>service>cpipe>sap>ingress>policer-override>policer
config>service>ipipe>sap>egress>policer-override>policer
config>service>ipipe>sap>ingress>policer-override>policer
config>service>epipe>sap>egress>policer-override>policer
Description 

This command configures the percent rates (CIR and PIR) override.

Parameters 
pir-percent —
Specifies the policer’s PIR as a percentage of the policers’s parent arbiter rate.
Values—
0.01 to 100.00
Values—
100.00
cir-percent —
Specifies the policer’s CIR as a percentage of the policers’s parent arbiter rate.
Values—
0.00 to 100.00

percent-rate

Syntax 
percent-rate pir-percent [cir cir-percent] [
no percent-rate
Context 
config>service>epipe>sap>egress>queue-override>queue
Description 

The percent-rate command within the SAP ingress and egress QoS policy enables supports for a queue’s PIR and CIR rate to be configured as a percentage of the egress port’s line rate or of its parent scheduler’s rate.

When the rates are expressed as a port-limit, the actual rates used per instance of the queue will vary based on the port speed. For example, when the same QoS policy is used on a 1-Gigabit and a 10-Gigabit Ethernet port, the queue’s rates will be 10 times greater on the 10 Gigabit port due to the difference in port speeds. This enables the same QOS policy to be used on SAPs on different ports without needing to use SAP based queue overrides to modify a queue’s rate to get the same relative performance from the queue.

If the port’s speed changes after the queue is created, the queue’s PIR and CIR rates will be recalculated based on the defined percentage value.

When the rates are expressed as a local-limit, the actual rates used per instance of the queue are relative to the queue’s parent scheduler rate. This enables the same QOS policy to be used on SAPs with different parent scheduler rates without needing to use SAP based queue overrides to modify a queue’s rate to get the same relative performance from the queue.

If the parent scheduler rate changes after the queue is created, the queue’s PIR and CIR rates will be recalculated based on the defined percentage value.

Queue rate overrides can only be specified in the form as configured in the QoS policy (a SAP override can only be specified as a percent-rate if the associated QoS policy was also defined as percent-rate). Likewise, a SAP override can only be specified as a rate (kbps) if the associated QoS policy was also defined as a rate. Queue-overrides are relative to the limit type specified in the QOS policy.

When no percent-rate is defined within a SAP ingress or egress queue-override, the queue reverts to the defined shaping and CIR rates within the SAP ingress and egress QOS policy associated with the queue.

Parameters 
percent-of-line-rate —
The percent-of-line-rate parameter is used to express the queue’s shaping rate as a percentage of line rate. The line rate associated with the queue’s port may dynamically change due to configuration or auto-negotiation. The line rate may also be affected by an egress port scheduler defined max-rate.
pir-percent —
Specifies the queue’s PIR as a percentage dependent on the use of the port-limit or local-limit.
Values—
0.01 to 100.00
Values—
100.00
cir-percent —
Specifies the queue’s CIR as a percentage dependent on the use of the port-limit or local-limit.
Values—
0.00 to 100.00
Values—
100.00

rate

Syntax 
rate {rate | max} [cir {rate | max}]
Context 
config>service>apipe>sap>egress>policer-override>policer
config>service>apipe>sap>ingress>policer-override>policer
config>service>cpipe>sap>egress>policer-override>policer
config>service>cpipe>sap>ingress>policer-override>policer
config>service>epipe>sap>egress>policer-override>policer
config>service>epipe>sap>ingress>policer-override>policer
config>service>ipipe>sap>egress>policer-override>policer
config>service>ipipe>sap>ingress>policer-override>policer
Description 

This command within the SAP ingress and egress policer-overrides contexts is used to override the sap-ingress and sap-egress QoS policy configured rate parameters for the specified policer-id.

The no rate command is used to restore the policy defined metering and profiling rate to a policer.

Parameters 
rate rate
Specifies the policer instance metering rate for the PIR leaky bucket, in kilobits per second. The integer value is multiplied by 1000 to derive the actual rate in bits per second.
Values—
1 to 2000000000
cir rate
Specifies the overriding value for the policy-derived profiling rate of the policer, in kilobits per second. The integer value is multiplied by 1000 to derive the actual rate in bits per second.
Values—
0 to 2000000000
max—
Uses the maximum policer rate, equal to the maximum capacity of the card on which the policer is configured. If the policer rate is set to a value larger than the maximum rate possible for the card, then the PIR or CIR used is equivalent to max.

stat-mode

Syntax 
stat-mode stat-mode
no stat-mode
Context 
config>service>apipe>sap>egress>policer-override>policer
config>service>apipe>sap>ingress>policer-override>policer
config>service>cpipe>sap>egress>policer-override>policer
config>service>cpipe>sap>ingress>policer-override>policer
config>service>epipe>sap>egress>policer-override>policer
config>service>epipe>sap>ingress>policer-override>policer
config>service>fpipe>sap>egress>policer-override>policer
config>service>fpipe>sap>ingress>policer-override>policer
config>service>ipipe>sap>egress>policer-override>policer
config>service>ipipe>sap>ingress>policer-override>policer
Description 

The SAP QoS policy’s policer stat-mode command is used to configure the forwarding plane counters that allow offered, output, and discard accounting to occur for the policer. A policer has multiple types of offered packets (for example, soft in-profile and out-of-profile from ingress and hard in-profile and out-of-profile due to egress profile overrides) and each of these offered types is interacting with the policers metering and profiling functions resulting in colored output packets (green, yellow, and red). Due to the potentially large number of egress policers, it is not economical to allocate counters in the forwarding plane for all possible offered packet types and output conditions. Many policers will not be configured with a CIR profiling rate and not all policers will receive explicitly re-profiled offered packets. The stat-mode command allows provisioning of the number of counters each policer requires and indicates how the offered packet types and output conditions should be mapped to the counters.

While a no-stats mode is supported that prevents any packet accounting, the use of the policer’s parent command requires that the policer’s stat-mode to be set at least to the minimal setting so that offered statistics are available for the policer’s Fair Information Rate (FIR) to be calculated.

Each time the policer’s stat mode is changed, any previous counter values are lost and any new counters are set to zero.

Each mode uses a certain number of counters per policer instance that are allocated from the forwarding plane’s policer counter resources.The total/allocated/free statistics can be viewed by using the tools dump resource-usage card fp command. If insufficient counters exist to implement a mode on any policer instance, the stat-mode change will fail and the previous mode will continue unaffected for all instances of the policer.

The stat-mode setting defined for the policer in the QoS policy may be overridden on a SAP where the policy is applied. If insufficient policer counter resources exist to implement the override, the stat-mode override command will fail. The current active stat mode setting will continue to be used by the policer.

The no stat-mode command attempts to return the policer’s stat-mode setting to minimal. The command will fail if insufficient policer counter resources exist to implement minimal where the QoS policer is currently applied and has a forwarding class mapping.

Refer to the 7750 SR OS Quality of Service Guide for detailed information about the supported parameters for the policer stat-mode command.

ce-address

Syntax 
ce-address ip-address
no ce-address
Context 
config>service>ipipe>sap
config>service>ipipe>spoke-sdp
Description 

This command specifies the IP address of the CE device associated with an Ipipe SAP or spoke SDP. In the case of a SAP, it is the address of the CE device directly attached to the SAP. For a spoke SDP, it is the address of the CE device reachable through that spoke SDP (for example, attached to the SAP on the remote node). The address must be a host address (no subnet addresses are accepted) as there must be only one CE device attached to an Ipipe SAP. The CE address specified at one end of an Ipipe will be used in processing ARP messages at the other endpoint, as the router acts as a proxy for ARP messages.

On a 7450 ESS, this command specifies the IP address of the CE device associated with an Ipipe SAP. In the case of a SAP, it is the address of the CE device directly attached to the SAP. The address must be a host address (no subnet addresses are accepted) as there must be only one CE device attached to an Ipipe SAP. The CE address specified at one end of an Ipipe will be used in processing ARP messages at the other endpoint, as the router acts as a proxy for ARP messages.

Parameters 
ip-address—
specifies the IP address of the CE device associated with an Ipipe SAP.

qinq-mark-top-only

Syntax 
[no] qinq-mark-top-only
Context 
config>service>cpipe>sap>egress
config>service>apipe>sap>egress
config>service>epipe>sap>egress
config>service>fpipe>sap>egress
config>service>apipe>sap>egress
Description 

When enabled (the encapsulation type of the access port where this SAP is defined as qinq), the qinq-mark-top-only command specifies which P-bits/DEI bit to mark during packet egress. When disabled, both set of P-bits/DEI bit are marked. When the enabled, only the P-bits/DEI bit in the top Q-tag are marked.

Default 

no qinq-mark-top-only

multi-service-site

Syntax 
multi-service-site customer-site-name
no multi-service-site
Context 
config>service>ipipe>sap
config>service>apipe>sap
config>service>cpipe>sap
config>service>fpipe>sap
config>service>epipe>sap
Description 

This command associates the SAP with a customer-site-name. If the specified customer-site-name does not exist in the context of the service customer ID an error occurs and the command will not execute. If customer-site-name exists, the current and future defined queues on the SAP (ingress and egress) will attempt to use the scheduler hierarchies created within customer-site-name as parent schedulers.

The no form of the command removes the SAP from any multi-service customer site the SAP belongs to. Removing the site can cause existing or future queues to enter an orphaned state.

Default 

None

Parameters 
customer-site-name—
The customer-site-name must exist in the context of the customer-id defined as the service owner. If customer-site-name exists and local scheduler policies have not been applied to the SAP, the current and future queues defined on the SAP will look for their parent schedulers within the scheduler hierarchies defined on customer-site-name.
Values—
Any valid customer-site-name created within the context of the customer-id.

ring-node

Syntax 
ring-node ring-node-name
no ring-node
Context 
config>service>epipe>sap
Description 

This command configures a multi-chassis ring-node for this SAP.

The no form of the command removes the name from the configuration.

Default 

none

transit-policy

Syntax 
transit-policy {ip ip-aasub-policy-id | prefix prefix-aasub-policy-id}
no transit-policy
Context 
config>service>epipe>sap
config>service>epipe>spoke-sdp
Description 

This command associates an AA transit policy to the service. The transit IP policy must be defined prior to associating the policy with a SAP in the config>application assurance>group>policy>transit-ip-policy context.

Transit AA subscribers are managed by the system through this service policy, which determines how transit subs are created and removed for that service.

The no form of the command removes the association of the policy to the service.

Default 

no transit-policy

Parameters 
ip-aasub-policy-id—
specifies an integer identifying an IP transit IP profile entry
Values—
1 to 65535
prefix-aasub-policy-id—
specifies an integer identifying a prefix transit profile entry
Values—
1 to 65535

use-broadcast-mac

Syntax 
[no] use-broadcast-mac
Context 
config>service>ipipe>sap
Description 

This command enables the user of a of broadcast MAC on SAP.

An Ipipe VLL service with the ce-address-discovery command enabled forwards unicast IP packets using the broadcast MAC address until the ARP cache is populated with a valid entry for the CE IP and MAC addresses.

The no form of this command enables the user of a of broadcast MAC on SAP.

Default 

no use-broadcast-mac

mac

Syntax 
[no] mac ieee-address
Context 
config>service>ipipe>sap
Description 

This command assigns a specific MAC address to an Ipipe SAP.

The no form of this command returns the MAC address of the SAP to the default value.

Default 

The physical MAC address associated with the Ethernet interface where the SAP is configured.

Parameters 
ieee-address—
Specifies the 48-bit MAC address in the form aa:bb:cc:dd:ee:ff or aa-bb-cc-dd-ee-ff where aa, bb, cc, dd, ee, and ff are hexadecimal numbers.

mac-refresh

Syntax 
mac-refresh refresh interval
no mac-refresh
Context 
config>service>ipipe>sap
Description 

This command specifies the interval between ARP requests sent on this Ipipe SAP. When the SAP is first enabled, an ARP request will be sent to the attached CE device and the received MAC address will be used in addressing unicast traffic to the CE. Although this MAC address will not expire while the Ipipe SAP is enabled and operational, it is verified by sending periodic ARP requests at the specified interval.

The no form of this command restores mac-refresh to the default value.

Default 

14400

Parameters 
refresh interval—
Specifies the interval, in seconds, between ARP requests sent on this Ipipe SAP.
Values—
0 to 65535

accounting-policy

Syntax 
accounting-policy acct-policy-id
no accounting-policy
Context 
config>service>apipe>sap
config>service>cpipe>sap
config>service>epipe>sap
config>service>fpipe>sap
config>service>ipipe
config>service>epipe>spoke-sdp
Description 

This command creates the accounting policy context that can be applied to a SAP.

An accounting policy must be defined before it can be associated with a SAP. If the policy-id does not exist, an error message is generated.

A maximum of one accounting policy can be associated with a SAP at one time. Accounting policies are configured in the config>log context.

The no form of this command removes the accounting policy association from the SAP, and the accounting policy reverts to the default.

Default 

Default accounting policy.

Parameters 
acct-policy-id—
Enter the accounting policy-id as configured in the config>log>accounting-policy context.
Values—
1 to 99

app-profile

Syntax 
app-profile app-profile-name
no app-profile
Context 
config>service>epipe>sap
config>service>epipe>spoke-sdp
Description 

This command configures the application profile name.

Parameters 
app-profile-name—
Specifies an existing application profile name configured in the config>app-assure>group>policy context.

bandwidth

Syntax 
bandwidth bandwidth
no bandwidth
Context 
config>service>epipe>spoke-sdp
config>service>fpipe>spoke-sdp
config>service>apipe>spoke-sdp
config>service>ipipe>spoke-sdp
config>service>cpipe>spoke-sdp
Description 

This command specifies the bandwidth to be used for VLL bandwidth accounting by the VLL CAC feature.

The service manager keeps track of the available bandwidth for each SDP. The maximum value is the sum of the bandwidths of all constituent LSPs in the SDP. The SDP available bandwidth is adjusted by the user configured booking factor.

If an LSP consists of a primary and many secondary standby LSPs, then the bandwidth used in the maximum SDP available bandwidth is that of the active path. Any change to and LSP active path bandwidth will update the maximum SDP available bandwidth. Note however that a change to any constituent LSP bandwidth due to re-signaling of the primary LSP path or the activation of a secondary path which causes overbooking of the maximum SDP available bandwidth causes a warning and a trap to be issued but no further action is taken. The activation of a bypass or detour LSP in the path of the primary LSP does not change the maximum SDP available bandwidth.

When the user binds a VLL service to this SDP, an amount of bandwidth equal to bandwidth is subtracted from the SDP available bandwidth adjusted by the booking factor. When the user deletes this VLL service binding from this SDP, an amount of bandwidth equal to bandwidth is added back into the SDP available bandwidth.

If the total SDP available bandwidth when adding this VLL service is about to overbook, a warning is issued and the binding is rejected. This means that the spoke-sdp bandwidth does not update the maximum SDP available bandwidth. In this case, the spoke-sdp is put in operational down state and a status message of “pseudowire not forwarding” is sent to the remote SR-Series PE node. A trap is also generated. The service manager will not put the spoke-sdp into operational UP state until the user performs a shutdown/no-shutdown of the spoke-sdp and the bandwidth check succeeds. Thus, the service manager will not automatically audit spoke-sdp’s subsequently to their creation to check if bandwidth is available.

If the VLL service contains an endpoint with multiple redundant spoke-sdp’s, each spoke-sdp will have its bandwidth checked against the available bandwidth of the corresponding SDP.

If the VLL service performs a pseudowire switching (VC switching) function, each spoke-sdp is separately checked for bandwidth against the corresponding SDP.

Note that this feature does not alter the way service packets are sprayed over multiple RSVP LSPs, which are part of the same SDP. In other words, by default load balancing of service packets occurs over the SDP LSPs based on service-id, or based on a hash of the packet header if ingress SAP shared queuing is enabled. In both cases, the VLL bandwidth is not checked against the selected LSP(s) available bandwidth but on the total SDP available bandwidth. Thus, if there is a single LSP per SDP, these two match.

If class-forwarding is enabled on the SDP, VLL service packets are forwarded to the SDP LSP which the packet forwarding class maps to, or if this is down to the default LSP. However, the VLL bandwidth is not checked against the selected LSP available bandwidth but on the total SDP available bandwidth. If there is a single LSP per SDP, these two match.

If a non-zero bandwidth is specified for a VLL service and attempts to bind the service to an LDP or a GRE SDP, a warning is issued that CAC failed but the VLL is established. A trap is also generated.

The no form of the command reverts to the default value.

Parameters 
bandwidth—
The bandwidth to be used for VLL bandwidth accounting by the VLL CAC feature, in kilobits per second
Values—
0 to 100000000
Values—
0

bfd-enable

Syntax 
[no] bfd-enable
Context 
config>service>epipe>spoke-sdp
config>service>epipe>bgp>pw-template-binding
config>service>fpipe>spoke-sdp
config>service>apipe>spoke-sdp
config>service>ipipe>spoke-sdp
config>service>cpipe>spoke-sdp
Description 

This command enables VCCV BFD on the PW associated with the VLL, BGP VPWS, or VPLS service. The parameters for the BFD session are derived from the named BFD template, which must have been first configured using the bfd-template command.

bfd-template

Syntax 
bdf-template name
no bfd-template
Context 
config>service>epipe>spoke-sdp
config>service>epipe>bgp>pw-template-binding
config>service>fpipe>spoke-sdp
config>service>apipe>spoke-sdp
config>service>ipipe>spoke-sdp
config>service>cpipe>spoke-sdp
Description 

This command configures a named BFD template to be used by VCCV BFD on PWs belonging to the VLL, BGP VPWS, or VPLS service. The template specifies parameters, such as the minimum transmit and receive control packet timer intervals, to be used by the BFD session. Template parameters are configured under the config>router>bfd context.

Default 

no bfd-template

Parameters 
name—
A text string name for the template of up to 32 characters in printable 7-bit ASCII, enclosed in double quotes.

block-on-peer-fault

Syntax 
[no] block-on-peer-fault
Context 
config>service>epipe>spoke-sdp
Description 

When enabled, this command blocks the transmit direction of a PW when any of the following PW status codes is received from the far end PE:

0x00000001

Pseudowire Not Forwarding

0x00000002

Local Attachment Circuit (ingress) Receive Fault

0x00000004

Local Attachment Circuit (egress) Transmit Fault

0x00000008

Local PSN-facing PW (ingress) Receive Fault

0x00000010

Local PSN-facing PW (egress) Transmit Fault

The transmit direction is unblocked when the following PW status code is received:

0x00000000

Pseudowire forwarding (clear all failures)

This command is mutually exclusive with no pw-status-signaling, and standby-signaling-slave. It is not applicable to spoke SDPs forming part of an MC-LAG or spoke SDPs in an endpoint.

Default 

no block-on-peer-fault

cflowd

Syntax 
[no] cflowd
Context 
config>service>epipe>sap
Description 

This command enables cflowd to collect traffic flow samples through a service interface (SAP) for analysis. When cflowd is enabled on an Ethernet service SAP, the Ethernet traffic can be sampled and processed by the system’s cflowd engine and exported to IPFIX collectors with the l2-ip template enabled.

cflowd is used for network planning and traffic engineering, capacity planning, security, application and user profiling, performance monitoring, usage-based billing, and SLA measurement. When cflowd is enabled at the SAP level, all packets forwarded by the interface are subjected to analysis according to the cflowd configuration.

For L2 services, only ingress sampling is supported.

Default 

no cflowd

collect-stats

Syntax 
[no] collect-stats
Context 
config>service>cpipe>sap
config>service>cpipe>spoke-sdp
config>service>epipe>spoke-sdp
config>service>apipe>sap
config>service>fpipe>sap
config>service>epipe>sap
Description 

This command enables accounting and statistical data collection for either the SAP, network port, or IP interface. When applying accounting policies the data, by default, is collected in the appropriate records and written to the designated billing file.

When the no collect-stats command is issued the statistics are still accumulated by the cards. However, the CPU will not obtain the results and write them to the billing file. If a subsequent collect-stats command is issued then the counters written to the billing file include all the traffic while the no collect-stats command was in effect.

Default 

no collect-stats

cpu-protection

Syntax 
cpu-protection policy-id [mac-monitoring] | [eth-cfm-monitoring [aggregate] [car]]
no cpu-protection
Context 
config>service>apipe>sap
config>service>epipe>spoke-sdp
config>service>epipe>sap
Description 

This command assigns an existing CPU protection policy to the associated service. The CPU protection policies are configured in the config>sys>security>cpu-protection>policy cpu-protection-policy-id context.

Default 

cpu-protection 254 (for access interfaces)

cpu-protection 255 (for network interfaces)

The configuration of no cpu-protection returns the interface/SAP to the default policies as shown above.

If no CPU protection policy is assigned to a service SAP then a the default policy is used to limit the overall-rate.

Parameters 
policy-id—
Specifies an existing CPU protection policy.
Values—
1 to 255
mac-monitoring—
This keyword enables MAC monitoring.
eth-cfm-monitoring —
This keyword enables Ethernet Connectivity Fault Management monitoring.
aggregate—
This keyword applies the rate limit to the sum of the per peer packet rates.
car—
(Committed Access Rate) This keyword causes Eth-CFM packets to be ignored when enforcing the overall-rate.

dist-cpu-protection

Syntax 
dist-cpu-protection policy-name
no dist-cpu-protection
Context 
config>service>epipe>sap
config>service>apipe>sap
config>service>cpipe>sap
config>service>fpipe>sap
config>service>ipipe>sap
Description 

This command assigns a Distributed CPU Protection (DCP) policy to the SAP. Only a valid created DCP policy can be assigned to a SAP or a network interface (note that this rule does not apply to templates such as an msap-policy)

Default 

no dist-cup-protection

Parameters 
policy-name—
The name of the DCP policy. 32 characters maximum.

ethernet

Syntax 
ethernet
Context 
config>service>epipe>sap
Description 

Use this command to configure Ethernet properties in this SAP.

llf

Syntax 
[no] llf
Context 
config>service>apipe>sap>atm
config>service>epipe>sap>ethernet
Description 

This command enables Link Loss Forwarding (LLF) on an Ethernet port or an ATM port. This feature provides an end-to-end OAM fault notification for Ethernet VLL service and for ATM VLL service of vc-type atm-cell. It brings down the Ethernet port (Ethernet LLF) or sends a SONET/SDH Path AIS (ATM LLF) towards the attached CE when there is a local fault on the Pseudowire or service, or a remote fault on the SAP or pseudowire, signaled with label withdrawal or T-LDP status bits. It ceases when the fault disappears.

The Ethernet port must be configured for null encapsulation.

For the 7750 SR, the ATM port must be configured as a SAP on an apipe service of vc-type atm-cell. The ATM port must also be configured on the following MDAs:

  1. 1-port OC12/STM4 ASAP MDA. At OC3/STM1 port level
  2. 4-port ATM MDA at OC12/STM4 or OC3/STM1 port level
  3. 16-port ATM MDA at OC3/STM1 port level

The ATM port must be configured as a SAP on an apipe service of vc-type atm-cell. The ATM port must also be configured on the following MDAs:

  1. 1-port OC12/STM4 ASAP MDA. At OC3/STM1 port level
  2. 4-port ATM MDA at OC12/STM4 or OC3/STM1 port level
  3. 16-port ATM MDA at OC3/STM1 port level

Circuit Emulation Commands

cem

Syntax 
cem
Context 
config>service>cpipe>sap
config>service>epipe>sap
Description 

This command enables the context to specify circuit emulation (CEM) properties.

local-ecid

Syntax 
local-ecid emulated circuit identifier
no local-ecid
Context 
config>service>epipe>sap>cem
Description 

This command defines the Emulated Circuit Identifiers (ECID) to be used for the local (source) end of the circuit emulation service.

The no form of the command removes the ECID from the configuration.

Default 

65535

Parameters 
emulated circuit identifier—
Specifies the value to be used as the local (source) ECID for the circuit emulation service. On CES packet reception, the ECID in the packet will be compared to the configured local-ecid value. These must match for the packet payload to be used for the TDM circuit. The remote-ecid value is inserted into the MEF-8 CES packet to be transmitted.
Values—
0 to 1048575

packet

Syntax 
packet jitter-buffer milliseconds [payload-size bytes]
packet payload-size bytes
no packet bytes
Context 
config>service>cpipe>sap
config>service>epipe>sap>cem
Description 

This command specifies the jitter buffer size, in milliseconds, and payload size, in bytes.

Default 

The default value depends on the CEM SAP endpoint type, and if applicable, the number of timeslots as shown in Table 13.

Table 13:  packet CEM SAP Endpoint Types 

Endpoint Type

Timeslots

Default Jitter Buffer (in ms)

unstructuredE1

n/a

5

unstructuredT1

n/a

5

nxDS0 (E1/T1)

32

N = 1

16

N = 2 to 4

8

N = 5 to 15

5

nxDS0WithCas (E1)

N

8

nxDS0WithCas (T1)

N

12

Parameters 
milliseconds—
specifies the jitter buffer size in milliseconds (ms).

Configuring the payload size and jitter buffer to values that result in less than 2 packet buffers or greater than 32 packet buffers is not allowed. Setting the jitter butter value to 0 sets it back to the default value.

Values—
1 to 250
payload-size bytes
Specifies the payload size (in bytes) of packets transmitted to the packet service network (PSN) by the CEM SAP. This determines the size of the data that will be transmitted over the service. If the size of the data received is not consistent with the payload size then the packet is considered malformed.
Values—
0 | 16 to 2048
Values—
The default value depends on the CEM SAP endpoint type, and if applicable, the number of timeslots as shown in Table 14.
Table 14:  CEM SAP Endpoint Types 

Endpoint Type

Timeslots

Default Payload Size (in bytes)

unstructuredE1

n/a

256

unstructuredT1

n/a

192

nxDS0 (E1/T1)

N = 1

64

N = 2 to 4

N x 32

N = 5 to 15

N x 16

N >= 16

N x 8

nxDS0WithCas (E1)

N

N x 16

nxDS0WithCas (T1)

N

N x 24

For all endpoint types except for nxDS0WithCas, the valid payload size range is from the default to 2048 bytes.

For nxDS0WithCas, the payload size divide by the number of timeslots must be an integer factor of the number of frames per trunk multi-frame (for example, 16 for E1 trunk and 24 for T1 trunk).

For 1xDS0, the payload size must be a multiple of 2.

For NxDS0, where N > 1, the payload size must be a multiple of the number of timeslots.

For unstructuredE1 and unstructuredT1, the payload size must be a multiple of 32 bytes.

Configuring the payload size and jitter buffer to values that result in less than 2 packet buffers or greater than 32 packet buffer is not allowed.

Setting the payload size to 0 sets it back to the default value.

remote-ecid

Syntax 
remote-ecid emulated circuit identifier
no remote-ecid
Context 
config>service>epipe>sap>cem
Description 

This command defines the Emulated Circuit Identifiers (ECID) to be used for the remote (destination) end of the circuit emulation service.

Parameters 
emulated circuit identifier—
Specifies the value to be used as the remote (destination) ECID for the circuit emulation service. Upon CES packet reception, the ECID in the packet will be compared to the configured local-ecid value. These must match for the packet payload to be used for the TDM circuit. The remote-ecid value is inserted into the MEF-8 CES packet to be transmitted.
Values—
0 to 1048575

remote-mac

Syntax 
remote-mac ieee-address
no remote-mac
Context 
config>service>epipe>sap>cem
Description 

This command defines the destination IEEE MAC address to be used to reach the remote end of the circuit emulation service.

Default 

00:00:00:00:00:00

Parameters 
ieee-address—
Specifies the 48-bit MAC address in the form aa:bb:cc:dd:ee:ff or aa-bb-cc-dd-ee-ff where aa, bb, cc, dd, ee and ff are hexadecimal numbers. Allowed values are any non-broadcast, non-multicast MAC and non-IEEE reserved MAC addresses.

report-alarm

Syntax 
[no] report-alarm [stray] [malformed] [pktloss] [overrun] [underrun] [rpktloss] [rfault] [rrdi]
Context 
config>service>epipe>sap>cem
Description 

This command indicates the type of CEM SAP alarm.

The no form of the command removes the parameter from the configuration.

Default 

On: stray, malformed, pktloss and overrun

Off: rpktloss, rfault, rrdi

Parameters 
stray—
Reports the reception of packets not destined for this CES circuit.
malformed—
Reports the reception of packet not properly formatted as CES packets.
pktloss—
Reports the lack of reception of CES packets.
overrun—
Reports the reception of too many CES packets resulting in a overrun of the receive jitter buffer.
underrun—
Reports the reception of too few CES packets resulting in a overrun of the receive jitter buffer.
rpktloss—
Reports hat the remote peer is currently in packet loss status.
rfault—
Reports that the remote TDM interface is currently not in service.
rrdi—
Reports that the remote TDM interface is currently in RDI status.

rtp-header

Syntax 
[no] rtp-header
Context 
config>service>epipe>sap>cem
config>service>cpipe>sap>cem
Description 

This command specifies whether an RTP header is used when packets are transmitted to the packet service network (PSN) by the CEM SAP. This mode must be enabled for differential-timed DS1/E1s. It can optionally be enabled for other DS1/E1s for interoperability purposes.

Default 

no rtp-header

ETH-CFM Service Commands

eth-cfm

Syntax 
eth-cfm
Context 
config>service>epipe>spoke-sdp
config>service>epipe
config>service>epipe>sap
config>service>ipipe>sap
Description 

This command enables the context to configure ETH-CFM parameters.

ais-enable

Syntax 
[no] ais-enable
Context 
config>service>epipe>sap>eth-cfm
config>service>epipe>sap>eth-cfm>mep
config>service>epipe>spoke-sdp>eth-cfm>mep
Description 

This command enables the generation and the reception of AIS messages.

low-priority-defect

Syntax 
low-priority-defect {allDef | macRemErrXcon}
Context 
config>lag>eth-cfm>mep>ais
config>lag>eth-cfm>mep>ais
config>port>ethernet>eth-cfm>mep>ais
config>service>epipe>sap>eth-cfm>mep>ais
config>service>epipe>spoke-sdp>eth-cfm>mep>ais
config>service>vpls>mesh-sdp>eth-cfm>mep>ais
Description 

This command allows the operator to include all CCM Defect conditions or exclude the Remote Defect Indication CCM (DefRDICCM) as a trigger for generating AIS. AIS generation can only occur when the client-meg-level configuration option has been included. Changing this parameter will evaluate the MEP for AIS triggers based on the new criteria.

Parameters 
allDef —
Keyword that includes any CCM defect condition to trigger AIS generation
macRemErrXcon—
Keyword that excludes RDI CCM Defect condition to trigger AIS generation.

collect-lmm-stats

Syntax 
collect-lmm-stats
no collect-lmm-stats
Context 
config>service>epipe>sap>eth-cfm
config>service>epipe>spoke-sdp>eth-cfm
config>service>vpls>sap>eth-cfm
config>service>vpls>spoke-sdp>eth-cfm
config>service>vpls>mesh-sdp>eth-cfm
config>service>ies>if>sap>eth-cfm
config>service>ies>if>spoke-sdp>eth-cfm
config>service>ies>sub-if>grp-if>sap>eth-cfm
config>service>vprn>if>sap>eth-cfm
config>service>vprn>if>spoke-sdp>eth-cfm
config>service>vprn>sub-if>grp-if>sap>eth-cfm
config>service>ipipe>sap>eth-cfm
Description 

This command enables the collection of statistics on the SAP or MPLS SDP binding on which the ETH- LMM test is configured. The collection of LMM statistics must be enabled if a MEP is launching or responding to ETH-LMM packets. If LMM statistics collection is not enabled, the counters in the LMM and LMR PDU do not represent accurate measurements and all measurements should be ignored. The show sap-using eth-cfm collect-lmm-stats command and the show sdp-using eth-cfm collect-lmm-stats command can be used to display which entities are collecting stats.

The no form of the command disables and deletes the counters for this SAP or MPLS SDP binding.

Default 

no collect-lmm-stats

interface-support-enable

Syntax 
[no] interface-support-enable
Context 
config>service>epipe>sap>eth-cfm>mep>ais
config>service>epipe>spoke-sdp>eth-cfm>mep>ais
Description 

This command enables the AIS function to consider the operational state of the entity on which it is configured. With this command, ETH-AIS on DOWN MEPs will be triggered and cleared based on the operational status of the entity on which it is configured. If CCM is also enabled then transmission of the AIS PDU will be based on either the non operational state of the entity or on ANY CCM defect condition. AIS generation will cease if BOTH operational state is UP and CCM has no defect conditions. If the MEP is not CCM enabled then the operational state of the entity is the only consideration assuming this command is present for the MEP.

Default 

no interface-support-enabled (AIS will not be generated or stopped based on the state of the entity on) which the DOWN MEP is configured.

client-meg-level

Syntax 
client-meg-level [[level [level ...]]
no client-meg-level
Context 
config>service>epipe>sap>eth-cfm>mep
config>service>epipe>spoke-sdp>eth-cfm>aid-enable
Description 

This command configures the client maintenance entity group (MEG) level(s) to use for AIS message generation. Up to 7 levels can be provisioned with the restriction that the client MEG level must be higher than the local MEG level.

Parameters 
level—
Specifies the client MEG level.
Values—
1 to 7
Values—
1

interval

Syntax 
interval {1 | 60}
no interval
Context 
config>service>epipe>sap>eth-cfm>mep>ais-enable
config>service>epipe>spoke-sdp>eth-cfm>ais-enable
Description 

This command specifies the transmission interval of AIS messages in seconds.

Parameters 
1 | 60—
The transmission interval of AIS messages in seconds.
Values—
1

priority

Syntax 
priority priority-value
no priority
Context 
config>service>epipe>sap>eth-cfm>mep
config>service>epipe>spoke-sdp>eth-cfm>aid-enable
Description 

This command specifies the priority of AIS messages originated by the node.

Parameters 
priority-value—
Specifies the priority value of the AIS messages originated by the node.
Values—
0 to 7
Values—
1

eth-tunnel

Syntax 
eth-tunnel
Context 
config>service>epipe>sap
config>service>ipipe>sap
Description 

The command enables the context to configure Ethernet Tunnel SAP parameters.

path

Syntax 
path path-index tag qtag[.qtag]
no path path-index
Context 
config>service>epipe>sap>eth-tunnel
config>service>ipipe>sap>eth-tunnel
Description 

This command configures Ethernet tunnel SAP path parameters.

The no form of the command removes the values from the configuration.

Default 

none

Parameters 
path-index—
Specifies the path index value.
Values—
1 to 16
tag qtag[.qtag]
Specifies the qtag value.
Values—
0 to 4094 | *

mep

Syntax 
mep mep-id domain md-index association ma-index [direction {up | down}]
no mep mep-id domain md-index association ma-index primary-vlan-enable [vlan vlan-id]
Context 
config>service>epipe>sap>eth-cfm
config>service>ies>sub-if>eth-cfm
config>service>epipe>spoke-sdp>eth-cfm
config>service>ipipe>sap>eth-cfm
Description 

This command provisions the maintenance endpoint (MEP).

The no form of the command reverts to the default values.

Parameters 
mep-id—
Specifies the maintenance association end point identifier.
Values—
1 to 81921
md-index—
Specifies the maintenance domain (MD) index value.
Values—
1 to 4294967295
ma-index—
Specifies the MA index value.
Values—
1 to 4294967295
direction {up | down}—
Indicates the direction in which the maintenance association (MEP) faces on the bridge port. The UP direction is not supported for all Fpipe services. For example, Ipipe does not support the direction of UP for MEPs.
up—
Sends ETH-CFM messages towards the MAC relay entity.
down—
Sends ETH-CFM messages away from the MAC relay entity.
primary-vlan-enable—
Provides a method for linking the MIP with the primary VLAN configured under the bridge-identifier for the MA. This is only allowed if the mhf-creation method is static. MIPs can not be changed from or to primary vlan functions without first being deleted. This must be configured as part of the creation step and can only be changed by deleting the MEP and recreating it. Primary VLANs are only supported under Ethernet SAPs.
vlan —
A required parameter when including primary-vlan-enable. Provides a method for associating the VLAN under the bride-identifier under the MA with the MIP.
vlan-id
Must match the vlan-id under the bridge-identifier for the MA that is appropriate for this service.
Values—
0 to 4094

ccm-enable

Syntax 
[no] ccm-enable
Context 
config>service>epipe>spoke-sdp>eth-cfm>mep
config>service>epipe>sap>eth-cfm>mep
config>service>ipipe>sap>eth-cfm>mep
Description 

This command enables the generation of CCM messages.

The no form of the command disables the generation of CCM messages.

ccm-ltm-priority

Syntax 
ccm-ltm-priority priority
no ccm-ltm-priority
Context 
config>service>epipe>spoke-sdp>eth-cfm>mep
config>service>epipe>sap>eth-cfm>mep
config>service>ipipe>sap>eth-cfm>mep
Description 

This command specifies the priority value for CCMs and LTMs transmitted by the MEP.

The no form of the command removes the priority value from the configuration.

Default 

The highest priority on the bridge-port.

Parameters 
priority—
Specifies the priority of CCM and LTM messages.
Values—
0 to 7

ccm-padding-size

Syntax 
ccm-padding-size ccm-padding
no ccm-padding-size ccm-padding
Context 
config>service>epipe>sap>eth-cfm>mep
config>service>ipipe>sap>eth-cfm>mep
config>service>epipe>sdp>eth-cfm>mep
config>service>epipe>spoke-sdp>eth-cfm>mep
config>service>vpls>sap>eth-cfm>mep
config>service>vpls>spoke-sdp>eth-cfm>mep
config>service>vpls>mesh-sdp>eth-cfm>mep
config>service>vpls>sap>eth-cfm>mep
config>service>vpls>spoke-sdp>eth-cfm>mep
config>service>vpls>mesh-sdp>eth-cfm>mep
config>service>ies>if>sap>eth-cfm>mep>
config>service>ies>if>spoke-sdp>eth-cfm>mep
config>service>ies>sub-if>grp-if>sap>eth-cfm>mep
config>service>vprn>if>sap>eth-cfm>mep
config>service>vprn>if>spoke-sdp>eth-cfm>mep
config>service>vprn>sub-if>grp-if>sap>eth-cfm>mep
config>port>ethernet>eth-cfm>mep
config>lag>eth-cfm>eth-cfm>mep
config>router>if>eth-cfm>mep
Description 

Set the byte size of the optional Data TLV to be included in the ETH-CC PDU. This will increase the size of the ETH-CC PDU by the configured value. The base size of the ETH-CC PDU, including the Interface Status TLV and Port Status TLV, is 83 bytes not including the Layer Two encapsulation. CCM padding is not supported when the CCM-Interval is less than one second.

Default 

[no] ccm-padding-size

Parameters 
ccm-padding—
Specifies the byte size of the Optional Data TLV.
Values—
3 to 1500

csf-enable

Syntax 
[no] csf-enable
Context 
config>service>epipe>sap>eth-cfm>mep
config>service>epipe>spoke-sdp>eth-cfm>mep
Description 

This command enables the reception and local processing of ETH-CSF frames.

multiplier

Syntax 
multiplier multiplier-value
no multiplier
Context 
config>service>epipe>sap>eth-cfm>mep>cfs-enable
config>service>epipe>spoke-sdp>eth-cfm>mep>cfs-enable
Description 

This command enables the multiplication factor applied to the receive time used to clear the CSF condition in increments of .5.

Default 

3.5

Parameters 
multiplier-value—
Specifies the multiplier used for timing out CSF.
Values—
0.0 | 2.0 to 30.0

ccm-tlv-ignore

Syntax 
ccm-tlv-ignore [interface-status] [port-status]
no ccm-tlv-ignore
Context 
config>port>ethernet>eth-cfm>mep
config>lag>eth-cfm>mep
config>router>if>eth-cfm>mep
Description 

This command allows the receiving MEP to ignore the specified TLVs in CCM PDU. Ignored TLVs will be reported as absent and will have no impact on the MEP state machine.

The no form of the command means the receiving MEP will process all recognized TLVs in the CCM PDU.

Default 

no ccm-tlv-ignore

Parameters 
interface-status—
Ignores the interface status TLV on reception.
port-status—
Ignores the port status TVL on reception.

eth-test-enable

Syntax 
[no] eth-test-enable
Context 
config>service>epipe>spoke-sdp>eth-cfm>mep
config>service>epipe>sap>eth-cfm>mep
config>service>ipipe>sap>eth-cfm>mep
Description 

For this test to work, operators need to configure ETH-test parameters on both sender and receiver nodes. The ETH-test then can be done using the following OAM commands:

oam eth-cfm eth-test mac-address mep mep-id domain md-index association ma-index [priority priority] [data-length data-length]

A check is performed for both the provisioning and test to ensure the MEP is an Y.1731 MEP (MEP provisioned with domain format none, association format icc-based). If not, the operation fails. An error message in the CLI and SNMP indicates the problem.

bit-error-threshold

Syntax 
bit-error-threshold errors
no bit-error-threshold
Context 
config>service>epipe>sap>eth-cfm>mep>eth-test-enable
Description 

This command is used to specify the threshold value of bit errors.

Parameters 
errors—
The threshold value of bit errors
Values—
0 to 11840
Values—
1

test-pattern

Syntax 
test-pattern {all-zeros | all-ones} [crc-enable]
no test-pattern
Context 
config>service>epipe>spoke-sdp>eth-cfm>mep>eth-test-enable
config>service>epipe>sap>eth-cfm>mep>eth-test-enable
config>service>ipipe>sap>eth-cfm>mep>eth-test-enable
Description 

This command configures the test pattern for eth-test frames.

The no form of the command removes the values from the configuration.

Default 

all-zeros

Parameters 
all-zeros —
Specifies to use all zeros in the test pattern.
all-ones—
Specifies to use all ones in the test pattern.
crc-enable—
Generates a CRC checksum.

fault-propagation-enable

Syntax 
fault-propagation-enable {use-if-tlv | suspend-ccm}
no fault-propagation-enable
Context 
config>service>epipe>sap>eth-cfm>mep
config>service>epipe>spoke-sdp>eth-cfm>mep
config>service>ipipe>sap>eth-cfm>mep
Description 

This command configures the fault propagation for the MEP.

Parameters 
use-if-tlv—
Uses the interface TLV
suspend-ccm—
Suspends continuity check messages

low-priority-defect

Syntax 
low-priority-defect {allDef | macRemErrXcon | remErrXcon | errXcon | xcon | noXcon}
Context 
config>service>epipe>spoke-sdp>eth-cfm>mep
config>service>epipe>sap>eth-cfm>mep
config>service>ipipe>sap>eth-cfm>mep
Description 

This command specifies the lowest priority defect that is allowed to generate a fault alarm.

Default 

macRemErrXcon

Parameters 
low-priority-defect—
The low priority defect values are defined below.
Values—

allDef

DefRDICCM, DefMACstatus, DefRemoteCCM, efErrorCCM, and DefXconCCM

macRemErrXcon

Only DefMACstatus, DefRemoteCCM, DefErrorCCM, and DefXconCCM

remErrXcon

Only DefRemoteCCM, DefErrorCCM, and efXconCCM

errXcon

Only DefErrorCCM and DefXconCCM

xcon

Only DefXconCCM; or

noXcon

No defects DefXcon or lower are to be reported

one-way-delay-threshold

Syntax 
one-way-delay-threshold seconds
Context 
config>service>vpls>sap>eth-cfm>mep
Description 

This command enables/disables eth-test functionality on MEP.

Parameters 
seconds—
Specifies the one way delay threshold in seconds.
Values—
0 to 600
Values—
3

mip

Syntax 
mip [mac mac-address] primary-vlan-enable [vlan vlan-id]
mip default-mac
no mip
Context 
config>service>epipe>sap>eth-cfm
Description 

This command allows Maintenance Intermediate Points (MIPs). The creation rules of the MIP are dependent on the mhf-creation configuration for the MA. This MIP option is only available for default and static mhf-creation methods.

Default 

no mip

Parameters 
mac—
Provides a method for manually configuring the MIP MAC.
mac-address—
Specifies the MAC address of the MIP.
Values—
6-byte mac-address in the form of xx:xx:xx:xx:xx:xx or xx-xx-xx-xx-xx-xx of the MIP. The MAC must be unicast. Using the all zeros address is equivalent to the no form of this command.
default-mac—
Using the no command deletes the MIP. If the operator wants to change the mac back to the default mac without having to delete the MIP and reconfiguring this command is useful.
primary-vlan-enable—
Provides a method for linking the MIP with the primary VLAN configured under the bridge-identifier for the MA. This is only allowed if the mhf-creation method is static. MIPs can not be changed from or to primary vlan functions without first being deleted. This must be configured as part of the creation step and can only be changed by deleting the MEP and recreating it. Primary VLANs are only supported under Ethernet SAPs.
vlan —
A required parameter when including primary-vlan-enable. Provides a method for associating the VLAN under the bride-identifier under the MA with the MIP.
vlan-id
Must match the vlan-id under the bridge-identifier for the MA that is appropriate for this service.
Values—
0 to 4094

squelch-ingress-levels

Syntax 
squelch-ingress-levels [md-level [md-level…]]
no squelch-ingress-levels
Context 
config>service>epipe>sap>eth-cfm
config>service>epipe>spoke-sdp>eth-cfm
config>service>vpls>sap>eth-cfm
config>service>vpls>spoke-sdp>eth-cfm
config>service>vpls>mesh-sdp>eth-cfm
config>service>ies>if>sap>eth-cfm
config>service>ies>if>spoke-sdp>eth-cfm
config>service>ies>sub-if>grp-if>sap>eth-cfm
config>service>vprn>if>sap>eth-cfm
config>service>vprn>if>spoke-sdp>eth-cfm
config>service>vprn>sub-if>grp-if>sap>eth-cfm
config>service>ipipe>sap>eth-cfm
config>service>template>vpls-sap-template>eth-cfm
Description 

This command defines the levels of the ETH-CFM PDUs that will silently be discarded on ingress into the SAP or SDP Binding from the wire. All ETH-CFM PDUs inbound to the SAP or SDP binding will be dropped that match the configured levels without regard for any other ETH-CFM criteria. No statistical information or drop count will be available for any ETH-PDU that is silently discarded by this option. The operator must configure a complete contiguous list of md-levels up to the highest level that will be dropped. The command must be retyped in complete form to modify a previous configuration, if the operator does not want to delete it first.

The no form of the command removes the silent discarding of previously matching ETH-CFM PDUs.

Default 

no squelch-ingress-levels

Parameters 
md-level—
Identifies the level.
Values—
0 to 7

tunnel-fault

Syntax 
tunnel-fault {accept | ignore}
Context 
config>service>epipe>eth-cfm
config>service>epipe>sap>eth-cfm
config>service>ipipe>eth-cfm
config>service>ipipe>sap>eth-cfm
Description 

Allows the individual service SAPs to react to changes in the tunnel MEP state. When tunnel-fault accept is configured at the service level, the SAP will react according to the service type, Epipe will set the operational flag and VPLS, IES and VPRN SAP operational state will become down on failure or up on clear. This command triggers the OAM mapping functions to mate SAPs and bindings in an Epipe service as well as setting the operational flag. If AIS generation is the requirement for the Epipe services this command is not required. See the ais-enable command under config>service>epipe>sap>eth-cfm>ais-enable context for more details. This works in conjunction with the tunnel-fault accept on the individual SAPs. Both must be set to accept to react to the tunnel MEP state. By default the service level command is “ignore” and the sap level command is “accept”. This means simply changing the service level command to “accept” will enable the feature for all SAPs. This is not required for Epipe services that only wish to generate AIS on failure.

Default 

ignore (Service Level)

accept (SAP Level for Epipe and VPLS)

Parameters 
accept—
Shares fate with the facility tunnel MEP.
ignore—
Does not share fate with the facility tunnel MEP.

Service Filter and QoS Policy Commands

egress

Syntax 
egress
Context 
config>service>apipe>sap
config>service>cpipe>sap
config>service>cpipe>spoke-sdp
config>service>epipe>spoke-sdp
config>service>fpipe>sap
config>service>ipipe>sap
config>service>epipe>sap
Description 

This command enables the context to configure egress SAP parameters.

If no sap-egress QoS policy is defined, the system default sap-egress QoS policy is used for egress processing.

force-qinq-vc-forwarding

Syntax 
[no] force-qinq-vc-forwarding
Context 
config>service>epipe>spoke-sdp
config>service>vpls>mesh-sdp
config>service>vpls>spoke-sdp
config>service>pw-template
Description 

This command forces the data path to insert and remove two VLAN tags for spoke and mesh SDPS that have either vc-type ether or vc-type vlan. The use of this command is mutually exclusive with the force-vlan-vc-forwarding command.

The VLAN identifiers and dot 1p/DE bits used in the two VLAN tags are taken from the inner tag received on a qinq SAP or qinq mesh/spoke SDP, or from the VLAN tag received on a dot1q SAP or mesh/spoke SDP (with vc-type vlan or force-vlan-vc-forwarding), or 0 if there is no service delimiting VLAN tag at the ingress SAP or mesh/spoke SDP. Alternatively, the VLAN identifiers in both VLAN tags can be set to the value configured in the vlan-vc-tag parameter in the pw-template or under the mesh/spoke SDP configuration.

The Ethertype used for both VLAN tags is 0x8100. A different Ethertype can be used for the outer VLAN tag by configuring the pseudowire template with the use-provisioned-sdp or prefer-provisioned-sdp options and setting the Ethertype using the sdp vlan-vc-etype parameter (this Ethertype value is then used for all mesh and spoke SDPs using that SDP).

The no version of this command sets the default behavior.

force-vlan-vc-forwarding

Syntax 
[no] force-vlan-vc-forwarding
Context 
config>service>epipe>spoke-sdp
config>service>vpls>mesh-sdp
config>service>vpls>spoke-sdp
Description 

This command forces vc-vlan-type forwarding in the data path for spoke and mesh SDPs which have either vc-type. This command is not allowed on vlan-vc-type SDPs.

The no version of this command sets default behavior.

Default 

By default this feature is disabled.

ingress

Syntax 
ingress
Context 
config>service>apipe>sap
config>service>cpipe>sap
config>service>cpipe>spoke-sdp
config>service>epipe>spoke-sdp
config>service>fpipe>sap
config>service>ipipe>sap
config>service>epipe>sap
config>service>epipe>sap
Description 

This command enables the context to configure ingress SAP Quality of Service (QoS) policies.

If no sap-ingress QoS policy is defined, the system default sap-ingress QoS policy is used for ingress processing.

filter

Syntax 
filter [ip ip-filter-id]
filter [ipv6 ipv6-filter-id]
filter [mac mac-filter-id]
no filter [ip ip-filter-id]
no filter [ipv6 ipv6-filter-id]
no filter [mac mac-filter-id]
Context 
config>service>epipe>sap>egress
config>service>epipe>sap>ingress
config>service>epipe>spoke-sdp>egress
config>service>epipe>spoke-sdp>ingress
config>service>ipipe>spoke-sdp>egress
config>service>ipipe>sap>ingress
config>service>ipipe>sap>egress
config>service>ipipe>spoke-sdp>ingress
config>service>epipe>sap>egress
config>service>epipe>sap>ingress
Description 

This command associates an IP filter policy with an ingress or egress Service Access Point (SAP) or IP interface.

Filter policies control the forwarding and dropping of packets based on IP matching criteria. Only one filter can be applied to a SAP at a time.

The filter command is used to associate a filter policy with a specified filter-id with an ingress or egress SAP. The filter-id must already be defined before the filter command is executed. If the filter policy does not exist, the operation will fail and an error message returned.

IP filters apply only to RFC 2427-routed IP packets. Frames that do not contain IP packets will not be subject to the filter and will always be passed, even if the filter's default action is to drop.

The no form of this command removes any configured filter ID association with the SAP or IP interface. The filter ID itself is not removed from the system unless the scope of the created filter is set to local. To avoid deletion of the filter ID and only break the association with the service object, use scope command within the filter definition to change the scope to local or global. The default scope of a filter is local.

Note that IPv6 filters are only supported by the 7450 ESS and 7750 SR but are not supported on a Layer 2 SAP that is configured with QoS MAC criteria. Also, MAC filters are not supported on a Layer 2 SAP that is configured with QoS IPv6 criteria.

Special Cases 
Epipe—
Both MAC and IP filters are supported on an Epipe service SAP.
Parameters 
ip-filter-id—
Specifies IP filter policy. The filter ID must already exist within the created IP filters.
Values—
1 to 65535
ipv6-filter-id—
Specifies the IPv6 filter policy for 7450 ESS or 7750 SR. The filter ID must already exist within the created IPv6 filters.
Values—
1 to 65535
mac-filter-id—
Specifies the MAC filter policy. The specified filter ID must already exist within the created MAC filters. The filter policy must already exist within the created MAC filters.
Values—
1 to 65535

l2tpv3

Syntax 
l2tpv3
Context 
config>service>epipe>spoke-sdp>egress
config>service>epipe>spoke-sdp>ingress
Description 

This command enters the context to configure an RX/TX cookie for L2TPv3 spoke-SDPs for Epipe services.

cookie

Syntax 
cookie [cookie1] [cookie2]
no cookie
Context 
config>service>epipe>spoke-sdp>egress>l2tpv3
config>service>epipe>spoke-sdp>ingress>l2tpv3
Description 

This command configures the RX/TX cookie for L2TPv3 spoke-SDPs for Epipe services. The RX cookie must match the configured TX cookie on a far-end node, while the TX cookie must match the configured RX cookie on a far-end node. If a mismatch is detected between the configured (far-end binding cookie) to what is received by the local IP address of the SDP a flag is set and must be manually cleared by an operator.

The purpose of the cookie is to provide validation against misconfiguration of service endpoints, and to ensure that the right service egress is being used.

One egress cookie and up to two ingress cookies may be configured per spoke-SDP binding. One or two cookies can be configured for matching ingress packets from the far-end node, in order to support cookie rollover without dropping packets. When a cookie is not configured, SR-OS assumes a value of 00:00:00:00:00:00:00:00.

A cookie is not mandatory. An operator may delete an egress cookie or either or both ingress cookies.

Default 

no cookie1 cookie2

Parameters 
cookie1—
Specifies the first cookie, in the form of a 64-bit colon-separated hex value
cookie2—
Specifies the second cookie, in the form of a 64-bit colon-separated hex value

hsmda-queue-override

Syntax 
[no] hsmda-queue-override
Context 
config>service>epipe>sap>egress
config>service>ipipe>sap>egress
Description 

This command configures HSMDA egress and ingress queue overrides.

packet-byte-offset

Syntax 
packet-byte-offset {add add-bytes | subtract sub-bytes}
no packet-byte-offset
Context 
config>service>epipe>sap>egress>hsmda-queue-over
config>service>ipipe>sap>egress>hsmda-queue-over
Description 

This command adds or subtracts the specified number of bytes to the accounting function for each packet handled by the HSMDA queue. Normally, the accounting and leaky bucket functions are based on the Ethernet DLC header, payload and the 4-byte CRC (everything except the preamble and inter-frame gap). For example, this command can be used to add the frame encapsulation overhead (20 bytes) to the queues accounting functions.

The accounting functions affected include:

  1. Offered High Priority / In-Profile Octet Counter
  2. Offered Low Priority / Out-of-Profile Octet Counter
  3. Discarded High Priority / In-Profile Octet Counter
  4. Discarded Low Priority / Out-of-Profile Octet Counter
  5. Forwarded In-Profile Octet Counter
  6. Forwarded Out-of-Profile Octet Counter
  7. Peak Information Rate (PIR) Leaky Bucket Updates
  8. Committed Information Rate (CIR) Leaky Bucket Updates
  9. Queue Group Aggregate Rate Limit Leaky Bucket Updates

The secondary shaper leaky bucket, scheduler priority level leaky bucket and the port maximum rate updates are not affected by the configured packet-byte-offset. Each of these accounting functions are frame based and always include the preamble, DLC header, payload and the CRC regardless of the configured byte offset.

The packet-byte-offset command accepts either add or subtract as valid keywords which define whether bytes are being added or removed from each packet traversing the queue. Up to 20 bytes may be added to the packet and up to 43 bytes may be removed from the packet. An example use case for subtracting bytes from each packet is an IP based accounting function. Given a Dot1Q encapsulation, the command packet-byte-offset subtract 14 would remove the DLC header and the Dot1Q header from the size of each packet for accounting functions only. The 14 bytes are not actually removed from the packet, only the accounting size of the packet is affected.

As mentioned above, the variable accounting size offered by the packet-byte-offset command is targeted at the queue and queue group level. When the queue group represents the last-mile bandwidth constraints for a subscriber, the offset allows the HSMDA queue group to provide an accurate accounting to prevent overrun and underrun conditions for the subscriber. The accounting size of the packet is ignored by the secondary shapers, the scheduling priority level shapers and the scheduler maximum rate. The actual on-the-wire frame size is used for these functions to allow an accurate representation of the behavior of the subscriber’s packets on an Ethernet aggregation network.

The packet-byte-offset value can be overridden for the HSMDA queue at the SAP or subscriber profile level.

The no form of the command removes any accounting size changes to packets handled by the queue. The command does not effect overrides that may exist on SAPs or subscriber profiles associated with the queue.

Parameters 
add-bytes—
Specifies a byte value to add to packets for queue and queue group-level accounting functions. The corresponding byte value must be specified when executing the packet-byte-offset command.
Values—
0 to 31
sub-bytes—
Specifies a byte value to subtract from packets for queue and queue group-level accounting functions. The corresponding byte value must be specified when executing the packet-byte-offset command.
Values—
1 to 64

queue

Syntax 
queue queue-id [create]
no queue queue-id
Context 
config>service>epipe>sap>egress>hsmda-queue-over
config>service>ipipe>sap>egress>hsmda-queue-over
Description 

This command, within the QoS policy hsmda-queue context, is a container for the configuration parameters controlling the behavior of an HSMDA queue. Unlike the standard QoS policy queue command, this command is not used to actually create or dynamically assign the queue to the object which the policy is applied. The queue identified by queue-id always exists on the SAP or subscriber context whether the command is executed or not. In the case of HSMDA SAPs and subscribers, all eight queues exist at the moment the system allocates an HSMDA queue group to the object (both ingress and egress).

Best-Effort, Expedited and Auto-Expedite Queue Behavior Based on Queue-ID

With standard service queues, the scheduling behavior relative to other queues is based on two items, the queues Best-Effort or Expedited nature and the dynamic rate of the queue relative to the defined CIR. HSMDA queues are handled differently. The create time auto-expedite and explicit expedite and best-effort qualifiers have been eliminated and instead the scheduling behavior is based solely on the queues identifier. Queues with a queue-id equal to 1 are placed in scheduling class 1. Queues with queue-id 2 are placed in scheduling class 2. And so on up to scheduling class 8. Each scheduling class is either mapped directly to a strict scheduling priority level based on the class ID, or the class may be placed into a weighted scheduling class group providing byte fair weighted round robin scheduling between the members of the group. Two weighted groups are supported and each may contain up to three consecutive scheduling classes. The weighted group assumes its highest member class inherent strict scheduling level for scheduling purposes. Strict priority level 8 has the highest priority while strict level 1 has the lowest. When grouping of scheduling classes is defined, some of the strict levels will not be in use.

Single Type of HSMDA Queues

Another difference between HSMDA queues and standard service queues is the lack of Multipoint queues. At ingress, an HSMDA SAP or subscriber does not require Multipoint queues since all forwarding types (broadcast, multicast, unicast and unknown) forward to a single destination ñ the ingress forwarding plane on the IOM. Instead of a possible eight queues per forwarding type (for a total of up to 32) within the SAP ingress QoS policy, the hsmda-queues node supports a maximum of eight queues.

Every HSMDA Queue Supports Profile Mode Implicitly

Unlike standard service queues, the HSMDA queues do not need to be placed into the special mode profile at create time in order to support ingress color aware policing. Each queue may handle in-profile, out-of-profile and profile undefined packets simultaneously. As with standard queues, the explicit profile of a packet is dependent on ingress sub-forwarding class to which the packet is mapped.

The no form of the command restores the defined queue-id to its default parameters. All HSMDA queues having the queue-id and associated with the QoS policy are re-initialized to default parameters.

Parameters 
queue-id—
Specifies the HSMDA queue to use for packets in this forwarding class. This mapping is used when the SAP is on a HSMDA MDA.
Values—
1 to 8

rate

Syntax 
rate pir-rate
no rate
Context 
config>service>epipe>sap>egress>hsmda-queue-over
config>service>ipipe>sap>egress>hsmda-queue-over
Description 

This command specifies the administrative PIR by the user.

Parameters 
pir-rate —
Configures the administrative PIR specified by the user.
Values—
1 to 40000000, max

wrr-weight

Syntax 
wrr-weight value
no wrr-weight
Context 
config>service>epipe>sap>egress>hsmda-queue-over>queue
config>service>ipipe>sap>egress>hsmda-queue-over>queue
Description 

This command assigns the weight value to the HSMDA queue.

The no form of the command returns the weight value for the queue to the default value.

Parameters 
value—
Specifies the weight for the HSMDA queue.
Values—
1 to 32

wrr-policy

Syntax 
wrr-policy hsmda-wrr-policy-name
no wrr-policy
Context 
config>service>epipe>sap>egress>hsmda-queue-over
config>service>ipipe>sap>egress>hsmda-queue-over
Description 

This command associates an existing HSMDA weighted-round-robin (WRR) scheduling loop policy to the HSMDA queue.

Parameters 
hsmda-wrr-policy-name—
Specifies the existing HSMDA WRR policy name to associate to the queue.

slope-policy

Syntax 
slope-policy hsmda-slope-policy-name
no slope-policy
Context 
config>service>epipe>sap>egress>hsmda-queue-over
config>service>ipipe>sap>egress>hsmda-queue-over
Description 

This command assigns an HSMDA slope policy to the SAP. The policy may be assigned to an ingress or egress HSMDA queue. The policy contains the Maximum Buffer Size (MBS) that will be applied to the queue and the high and low priority RED slope definitions. The function of the MBS and RED slopes is to provide congestion control for an HSMDA queue. The MBS parameter defines the maximum depth a queue may reach when accepting packets. The low and high priority RED slopes provides for random early detection of congestion and slope based discards based on queue depth.

An HSMDA slope policy can be applied to queues defined in the SAP ingress and SAP egress QoS policy HSMDA queues context. Once an HSMDA slope policy is applied to a SAP QoS policy queue, it cannot be deleted. Any edits to the policy are updated to all HSMDA queues indirectly associated with the policy.

Default HSMDA Slope Policy

An HSMDA slope policy named “default” always exists on the system and does not need to be created. The default policy is automatically applied to all HSMDA queues unless another HSMDA slope policy is specified for the queue. The default policy cannot be modified or deleted. Attempting to execute the no hsmda-slope-policy default command results in an error.

The no form of the command removes the specified HSMDA slope policy from the configuration. If the HSMDA slope policy is currently associated with an HSMDA queue, the command will fail.

Parameters 
hsmda-slope-policy-name—
Specifies a HSMDA slope policy up to 32 characters in length. The HSMDA slope policy must be exist prior to applying the policy name to an HSMDA queue.

secondary-shaper

Syntax 
secondary-shaper secondary-shaper-name
no secondary-shaper
Context 
config>service>epipe>sap>egress>hsmda-queue-over
config>service>ipipe>sap>egress>hsmda-queue-over
Description 

This command configures an HSMDA egress secondary shaper.

Parameters 
secondary-shaper-name—
Specifies a secondary shaper name up to 32 characters in length.

filter

Syntax 
filter [ip ip-filter-id]
filter [ipv6 ipv6-filter-id]
no filter [ip ip-filter-id] [ipv6 ipv6-filter-id]
no filter [ip ip-filter-id]
Context 
config>service>fpipe>sap>egress
config>service>fpipe>sap>ingress
config>service>cpipe>spoke-sdp>egress
config>service>cpipe>spoke-sdp>ingress
config>service>fpipe>spoke-sdp>egress
config>service>fpipe>spoke-sdp>ingress
config>service>ipipe>spoke-sdp>egress
config>service>ipipe>sap>ingress
config>service>ipipe>sap>egress
config>service>ipipe>spoke-sdp>ingress
Description 

This command associates a filter policy with an ingress or egress Service Access Point (SAP) or IP interface.

Filter policies control the forwarding and dropping of packets based on IP matching criteria. Only one filter can be applied to a SAP at a time.

The filter command is used to associate a filter policy with a specified ip-filter-id with an ingress or egress SAP. The ip-filter-id must already be defined before the filter command is executed. If the filter policy does not exist, the operation will fail and an error message returned.

IP filters apply only to RFC 2427-routed IP packets. Frames that do not contain IP packets will not be subject to the filter and will always be passed, even if the filter's default action is to drop.

The no form of this command removes any configured filter ID association with the SAP or IP interface. The filter ID itself is not removed from the system unless the scope of the created filter is set to local. To avoid deletion of the filter ID and only break the association with the service object, use scope command within the filter definition to change the scope to local or global. The default scope of a filter is local.

Parameters 
ip-filter-id—
Specifies IP filter policy. The filter ID must already exist within the created IP filters.
Values—
1 to 65535
ipv6-filter-id—
Specifies the IPv6 filter policy. The filter ID must already exist within the created IPv6 filters.
Values—
1 to 65535

qos

Syntax 
qos policy-id [shared-queuing] [fp-redirect-group queue-group-name instance instance-id]
no qos
Context 
config>service>apipe>sap>ingress
config>service>fpipe>sap>ingress
config>service>ipipe>sap>ingress
config>service>epipe>sap>ingress
Description 

This command associates a Quality of Service (QoS) policy with an ingress Service Access Point (SAP).

QoS ingress and egress policies are important for the enforcement of SLA agreements. The policy ID must be defined prior to associating the policy with a SAP. If the policy-id does not exist, an error will be returned.

The qos command, when used under the ingress context, is used to associate ingress QoS policies. The qos command only allows ingress policies to be associated on SAP ingress and egress policies on SAP egress. Attempts to associate a QoS policy of the wrong type returns an error.

Only one ingress and one egress QoS policy can be associated with a SAP at one time. Attempts to associate a second QoS policy of a given type will return an error.

By default, if no specific QoS policy is associated with the SAP for ingress or egress, so the default QoS policy is used.

The no form of this command removes the QoS policy association from the SAP, and the QoS policy reverts to the default.

Default 

none

Parameters 
policy-id—
The ingress policy ID to associate with SAP or IP interface on ingress. The policy ID must already exist.
Values—
1 to 65535
shared-queuing—
This keyword can only be specified on SAP ingress. The shared-queuing keyword specifies the shared queue policy will be used by this SAP. When the value of this object is null, the SAP will use individual ingress QoS queues, instead of the shared ones.
fp-redirect-group—
This keyword can only be used on SAP ingress and associates a SAP ingress with an instance of a named queue group template on the ingress forwarding plane of a given IOM/IMM/XMA. The queue-group-name and instance instance-id are mandatory parameters when executing the command.
queue-group-name
Specifies the name of the queue group to be instance on the forwarding plane of the IOM/IMM/XMA, up to 32 characters in length. The queue-group-name must correspond to a valid ingress forwarding plane queue group, created under config>card>fp>ingress>access.
instance-id—
Specifies the instance of the named queue group on the IOM/IMM/XMA ingress forwarding plane.

qos

Syntax 
qos policy-id port-redirect-group queue-group-name instance instance-id
qos policy-id
no qos [policy-id]
Context 
config>service>apipe>sap>egress
config>service>cpipe>sap>egress
config>service>fpipe>sap>egress
config>service>ipipe>sap>egress
config>service>epipe>sap>egress
Description 

This command associates a Quality of Service (QoS) policy with an egress Service Access Point (SAP).

QoS ingress and egress policies are important for the enforcement of SLA agreements. The policy ID must be defined prior to associating the policy with a SAP. If the policy-id does not exist, an error will be returned.

The qos command, when used under the egress context, is used to associate egress QoS policies.

The qos command only allows ingress policies to be associated on SAP ingress and egress policies on SAP egress. Attempts to associate a QoS policy of the wrong type returns an error.

Only one ingress and one egress QoS policy can be associated with a SAP at one time. Attempts to associate a second QoS policy of a given type will return an error.

By default, if no specific QoS policy is associated with the SAP for ingress or egress, so the default QoS policy is used.

The no form of this command removes the QoS policy association from the SAP, and the QoS policy reverts to the default.

Default 

none

Parameters 
policy-id—
The egress policy ID to associate with SAP on egress. The policy ID must already exist.
Values—
1 to 65535
queue-group-name—
Specifies the name of the egress port queue group of the IOM/IMM/XMA, up to 32 characters in length. The queue-group-name must correspond to a valid egress queue group, created under config>port>ethernet>access>egress.
instance-id—
Specifies the instance of the named egress port queue group on the IOM/IMM/XMA.
Values—
1 to 40960
Values—
1

queue-override

Syntax 
[no] queue-override
Context 
config>service>apipe>sap>egress
config>service>apipe>sap>ingress
config>service>cpipe>sap>egress
config>service>cpipe>sap>ingress
config>service>fpipe>sap>egress
config>service>fpipe>sap>ingress
config>service>ipipe>sap>egress
config>service>ipipe>sap>ingress
config>service>epipe>sap>egress
config>service>epipe>sap>ingress
Description 

This command enables the context to configure override values for the specified SAP egress or ingress QoS queue. These values override the corresponding ones specified in the associated SAP egress or ingress QoS policy. If the policy was created as a template policy, this command overrides the parameter and its description and queue parameters in the policy.

queue

Syntax 
queue queue-id [create]
no queue queue-id
Context 
config>service>apipe>sap>egress>queue-override
config>service>apipe>sap>ingress>queue-override
config>service>cpipe>sap>egress>queue-override
config>service>cpipe>sap>ingress>queue-override
config>service>fpipe>sap>egress>queue-override
config>service>fpipe>sap>ingress>queue-override
config>service>ipipe>sap>egress>queue-override
config>service>ipipe>sap>ingress>queue-override
config>service>epipe>sap>egress>queue-override
config>service>epipe>sap>ingress>queue-override
Description 

This command specifies the ID of the queue whose parameters are to be overridden.

Parameters 
queue-id—
The queue ID whose parameters are to be overridden.
Values—
1 to 32
create—
This keyword is mandatory when creating a queue.

adaptation-rule

Syntax 
adaptation-rule [pir adaptation-rule}] [cir adaptation-rule}]
no adaptation-rule
Context 
config>service>apipe>sap>egress>queue-override>queue
config>service>apipe>sap>ingress>queue-override>queue
config>service>fpipe>sap>egress>queue-override>queue
config>service>fpipe>sap>ingress>queue-override>queue
config>service>ipipe>sap>egress>queue-override>queue
config>service>ipipe>sap>ingress>queue-override>queue
config>service>epipe>sap>egress>queue-override>queue
config>service>epipe>sap>ingress>queue-override>queue
Description 

This command can be used to override specific attributes of the specified queue’s adaptation rule parameters. The adaptation rule controls the method used by the system to derive the operational CIR and PIR settings when the queue is provisioned in hardware. For the CIR and PIR parameters individually, the system attempts to find the best operational rate depending on the defined constraint.

The no form of the command removes any explicitly defined constraints used to derive the operational CIR and PIR created by the application of the policy. When a specific adaptation-rule is removed, the default constraints for rate and cir apply.

Default 

no adaptation-rule

Parameters 
pir—
The pir parameter defines the constraints enforced when adapting the PIR rate defined within the queue queue-id rate command. The pir parameter requires a qualifier that defines the constraint used when deriving the operational PIR for the queue. When the rate command is not specified, the default applies.
cir—
The cir parameter defines the constraints enforced when adapting the CIR rate defined within the queue queue-id rate command. The cir parameter requires a qualifier that defines the constraint used when deriving the operational CIR for the queue. When the cir parameter is not specified, the default constraint applies.
adaptation-rule—
Specifies the criteria to use to compute the operational CIR and PIR values for this queue, while maintaining a minimum offset.
Values—
max — The max (maximum) keyword is mutually exclusive with the min and closest options. When max is defined, the operational PIR for the queue will be equal to or less than the administrative rate specified using the rate command.
min — The min (minimum) keyword is mutually exclusive with the max and closest options. When min is defined, the operational PIR for the queue will be equal to or greater than the administrative rate specified using the rate command.
closest — The closest parameter is mutually exclusive with the min and max parameter. When closest is defined, the operational PIR for the queue will be the rate closest to the rate specified using the rate command.

avg-frame-overhead

Syntax 
avg-frame-overhead percent
no avg-frame-overhead
Context 
config>service>apipe>sap>egress>queue-override>queue
config>service>cpipe>sap>egress>queue-override>queue
config>service>epipe>sap>egress>queue-override>queue
Description 

This command configures the average frame overhead to define the average percentage that the offered load to a queue will expand during the frame encapsulation process before sending traffic on-the-wire. While the avg-frame-overhead value may be defined on any queue, it is only used by the system for queues that egress a SONET or SDH port or channel. Queues operating on egress Ethernet ports automatically calculate the frame encapsulation overhead based on a 20 byte per packet rule (8 bytes for preamble and 12 bytes for Inter-Frame Gap).

When calculating the frame encapsulation overhead for port scheduling purposes, the system determines the following values:

  1. Offered-load — The offered-load of a queue is calculated by starting with the queue depth in octets, adding the received octets at the queue and subtracting queue discard octets. The result is the number of octets the queue has available to transmit. This is the packet based offered-load.
  2. Frame encapsulation overhead — Using the avg-frame-overhead parameter, the frame encapsulation overhead is simply the queue’s current offered-load (how much has been received by the queue) multiplied by the avg-frame-overhead. If a queue had an offered load of 10000 octets and the avg-frame-overhead equals 10%, the frame encapsulation overhead would be 10000 x 0.1 or 1000 octets.
    For egress Ethernet queues, the frame encapsulation overhead is calculated by multiplying the number of offered-packets for the queue by 20 bytes. If a queue was offered 50 packets then the frame encapsulation overhead would be 50 x 20 or 1000 octets.
  1. Frame based offered-load — The frame based offered-load is calculated by adding the offered-load to the frame encapsulation overhead. If the offered-load is 10000 octets and the encapsulation overhead was 1000 octets, the frame based offered-load would equal 11000 octets.
  2. Packet to frame factor — The packet to frame factor is calculated by dividing the frame encapsulation overhead by the queue’s offered-load (packet based). If the frame encapsulation overhead is 1000 octets and the offered-load is 10000 octets then the packet to frame factor would be 1000 / 10000 or 0.1. When in use, the avg-frame-overhead will be the same as the packet to frame factor making this calculation unnecessary.
  3. Frame based CIR — The frame based CIR is calculated by multiplying the packet to frame factor with the queue’s configured CIR and then adding that result to that CIR. If the queue CIR is set at 500 octets and the packet to frame factor equals 0.1, the frame based CIR would be 500 x 1.1 or 550 octets.
  4. Frame based within-cir offered-load — The frame based within-cir offered-load is the portion of the frame based offered-load considered to be within the frame-based CIR. The frame based within-cir offered-load is the lesser of the frame based offered-load and the frame based CIR. If the frame based offered-load equaled 11000 octets and the frame based CIR equaled 550 octets, the frame based within-cir offered-load would be limited to 550 octets. If the frame based offered-load equaled 450 octets and the frame based CIR equaled 550 octets, the frame based within-cir offered-load would equal 450 octets (or the entire frame based offered-load).
    As a special case, when a queue or associated intermediate scheduler is configured with a CIR-weight equal to 0, the system automatically sets the queue’s frame based within-cir offered-load to 0, preventing it from receiving bandwidth during the port scheduler’s within-cir pass.
  1. Frame based PIR — The frame based PIR is calculated by multiplying the packet to frame factor with the queue’s configured PIR and then adding the result to that PIR. If the queue PIR is set to 7500 octets and the packet to frame factor equals 0.1, the frame based PIR would be 7500 x 1.1 or 8250 octets.
  2. Frame based within-pir offered-load — The frame based within-pir offered-load is the portion of the frame based offered-load considered to be within the frame based PIR. The frame based within-pir offered-load is the lesser of the frame based offered-load and the frame based PIR. If the frame based offered-load equaled 11000 octets and the frame based PIR equaled 8250 octets, the frame based within-pir offered-load would be limited to 8250 octets. If the frame based offered-load equaled 7000 octets and the frame based PIR equaled 8250 octets, the frame based within-pir offered load would equal 7000 octets.

Port scheduler operation using frame transformed rates — The port scheduler uses the frame based rates to figure the maximum rates that each queue may receive during the within-cir and above-cir bandwidth allocation passes. During the within-cir pass, a queue may receive up to its frame based within-cir offered-load. The maximum it may receive during the above-cir pass is the difference between the frame based within-pir offered load and the amount of actual bandwidth allocated during the within-cir pass.

On the 7450 ESS and 7750 SR, SAP and subscriber SLA-profile average frame overhead override — The average frame overhead parameter on a sap-egress may be overridden at an individual egress queue basis. On each SAP and within the sla-profile policy used by subscribers an avg-frame-overhead command may be defined under the queue-override context for each queue. When overridden, the queue instance will use its local value for the average frame overhead instead of the sap-egress defined overhead.

The no form of this command restores the average frame overhead parameter for the queue to the default value of 0 percent. When set to 0, the system uses the packet based queue statistics for calculating port scheduler priority bandwidth allocation. If the no avg-frame-overhead command is executed in a queue-override queue id context, the avg-frame-overhead setting for the queue within the sap-egress QoS policy takes effect.

Default 

0

Parameters 
percent—
This parameter sets the average amount of packet-to-frame encapsulation overhead expected for the queue. This value is not used by the system for egress Ethernet queues.
Values—
0.00 to 100.00

burst-limit

Syntax 
burst-limit {default | size [byte | kilobyte]}
no burst-limit
Context 
config>service>apipe>sap>egress>queue-override>queue
config>service>apipe>sap>ingress>queue-override>queue
config>service>cpipe>sap>egress>queue-override>queue
config>service>cpipe>sap>ingress>queue-override>queue
config>service>fpipe>sap>egress>queue-override>queue
config>service>fpipe>sap>ingress>queue-override>queue
config>service>ipipe>sap>egress>queue-override>queue
config>service>ipipe>sap>ingress>queue-override>queue
config>service>epipe>sap>egress>queue-override>queue
config>service>epipe>sap>ingress>queue-override>queue
Description 

The queue burst-limit command is used to define an explicit shaping burst size for a queue. The configured size defines the shaping leaky bucket threshold level that indicates the maximum burst over the queue’s shaping rate.

The burst-limit command is supported under the sap-ingress and sap-egress QoS policy queues. The command is also supported under the ingress and egress queue-group-templates queues.

The no form of this command is used to restore the default burst limit to the specified queue. This is equivalent to specifying burst-limit default within the QoS policies or queue group templates. When specified within a queue-override queue context, any current burst limit override for the queue will be removed and the queue’s burst limit will be controlled by its defining policy or template.

Parameters 
default—
The default parameter is mutually exclusive to specifying an explicit size value. When burst-limit default is executed, the queue is returned to the system default value.
size—
When a numeric value is specified (size), the system interprets the value as an explicit burst limit size. The value is expressed as an integer and by default is interpreted as the burst limit in Kilobytes. If the value is intended to be interpreted in bytes, the byte qualifier must be added following size.
Values—
1 to 14000 (14000 or 14000000 depending on bytes or kilobytes)
Values—
No default for size, use the default keyword to specify default burst limit
byte—
The bytes qualifier is used to specify that the value given for size must be interpreted as the burst limit in bytes. The byte qualifier is optional and mutually exclusive with the kilobytes qualifier.
kilobyte—
The kilobyte qualifier is used to specify that the value given for size must be interpreted as the burst limit in Kilobytes. The kilobyte qualifier is optional and mutually exclusive with the bytes qualifier. If neither bytes nor kilobytes is specified, the default qualifier is kilobytes.

cbs

Syntax 
cbs size-in-kbytes
no cbs
Context 
config>service>apipe>sap>egress>queue-override>queue
config>service>apipe>sap>ingress>queue-override>queue
config>service>cpipe>sap>egress>queue-override>queue
config>service>cpipe>sap>ingress>queue-override>queue
config>service>fpipe>sap>egress>queue-override>queue
config>service>fpipe>sap>ingress>queue-override>queue
config>service>ipipe>sap>egress>queue-override>queue
config>service>ipipe>sap>ingress>queue-override>queue
config>service>epipe>sap>egress>queue-override>queue
config>service>epipe>sap>ingress>queue-override>queue
Description 

This command can be used to override specific attributes of the specified queue’s CBS parameters.

It is permissible, and possibly desirable, to oversubscribe the total CBS reserved buffers for a given access port egress buffer pool. Oversubscription may be desirable due to the potential large number of service queues and the economy of statistical multiplexing the individual queue’s CBS setting into the defined reserved total.

When oversubscribing the reserved total, it is possible for a queue depth to be lower than its CBS setting and still not receive a buffer from the buffer pool for an ingress frame. As more queues are using their CBS buffers and the total in use exceeds the defined reserved total, essentially the buffers are being removed from the shared portion of the pool without the shared in use average and total counts being decremented. This can affect the operation of the high and low priority RED slopes on the pool, causing them to miscalculate when to start randomly to drop packets.

The no form of this command returns the CBS size to the default value.

Default 

no cbs

Parameters 
size-in-kbytes—
The size parameter is an integer expression of the number of kilobytes reserved for the queue. If a value of 10KBytes is desired, enter the value 10. A value of 0 specifies that no reserved buffers are required by the queue (a minimal reserved size can still be applied for scheduling purposes).
Values—
0 to 131072, default

high-prio-only

Syntax 
high-prio-only percent
no high-prio-only
Context 
config>service>apipe>sap>egress>queue-override>queue
config>service>apipe>sap>ingress>queue-override>queue
config>service>cpipe>sap>egress>queue-override>queue
config>service>cpipe>sap>ingress>queue-override>queue
config>service>fpipe>sap>egress>queue-override>queue
config>service>fpipe>sap>ingress>queue-override>queue
config>service>ipipe>sap>egress>queue-override>queue
config>service>ipipe>sap>ingress>queue-override>queue
config>service>epipe>sap>egress>queue-override>queue
config>service>epipe>sap>ingress>queue-override>queue
Description 

This command can be used to override specific attributes of the specified queue’s high-prio-only parameters. The high-prio-only command configures the percentage of buffer space for the queue, used exclusively by high priority packets.

The priority of a packet can only be set in the SAP ingress QoS policy and is only applicable on the ingress queues for a SAP. The high-prio-only parameter is used to override the default value derived from the network-queue command.

The defined high-prio-only value cannot be greater than the MBS size of the queue. Attempting to change the MBS to a value smaller than the high priority reserve will generate an error and fail execution. Attempting to set the high-prio-only value larger than the current MBS size will also result in an error and fail execution.

The no form of this command restores the default high priority reserved size.

Parameters 
percent—
The percent parameter is the percentage reserved for high priority traffic on the queue. If a value of 10KBytes is desired, enter the value 10. A value of 0 specifies that none of the MBS of the queue will be reserved for high priority traffic. This does not affect RED slope operation for packets attempting to be queued.
Values—
0 to 100, default

mbs

Syntax 
mbs size [bytes | kilobytes]
no mbs
Context 
config>service>apipe>sap>egress>queue-override>queue
config>service>apipe>sap>ingress>queue-override>queue
config>service>cpipe>sap>egress>queue-override>queue
config>service>cpipe>sap>egress>queue-override>queue
config>service>cpipe>sap>ingress>queue-override>queue
config>service>fpipe>sap>egress>queue-override>queue
config>service>fpipe>sap>ingress>queue-override>queue
config>service>ipipe>sap>egress>queue-override>queue
config>service>ipipe>sap>ingress>queue-override>queue
config>service>epipe>sap>egress>queue-override>queue
config>service>epipe>sap>ingress>queue-override>queue
Description 

This command can be used to override specific attributes of the specified queue’s MBS parameters. The MBS value is used by a queue to determine whether it has exhausted all of its buffers while enqueuing packets. Once the queue has exceeded the amount of buffers allowed by MBS, all packets are discarded until packets have been drained from the queue.

The sum of the MBS for all queues on an ingress access port can oversubscribe the total amount of buffering available. When congestion occurs and buffers become scarce, access to buffers is controlled by the RED slope a packet is associated with. A queue that has not exceeded its MBS size is not guaranteed that a buffer will be available when needed or that the packet’s RED slope will not force the discard of the packet. Setting proper CBS parameters and controlling CBS oversubscription is one major safeguard to queue starvation (when a queue does not receive its fair share of buffers). Another is properly setting the RED slope parameters for the needs of services on this port or channel.

The defined high-prio-only value cannot be greater than the MBS size of the queue. Attempting to change the MBS to a value smaller than the high priority reserve will generate an error and fail execution. Attempting to set the high-prio-only value larger than the current MBS size will also result in an error and fail execution.

The no form of this command returns the MBS size assigned to the queue to the default value.

Default 

default

Parameters 
size—
The size parameter is an integer expression of the maximum number of kilobytes or bytes of buffering allowed for the queue. A value of 0 causes the queue to discard all packets.
Values—
0 to 1073741824, default
bytes—
Indicates that the size parameter value is expressed in bytes
kilobytes—
Indicates that the size parameter is expressed in kilobytes

monitor-depth

Syntax 
[no] monitor-depth
Context 
config>service>apipe>sap>egress>queue-override>queue
config>service>apipe>sap>ingress>queue-override>queue
config>service>cpipe>sap>egress>queue-override>queue
config>service>cpipe>sap>ingress>queue-override>queue
config>service>epipe>sap>egress>queue-override>queue
config>service>epipe>sap>ingress>queue-override>queue
config>service>fpipe>sap>egress>queue-override>queue
config>service>fpipe>sap>ingress>queue-override>queue
config>service>ipipe>sap>egress>queue-override>queue
config>service>ipipe>sap>ingress>queue-override>queue
Description 

This command enables queue depth monitoring for the specified queue.

The no form of the command removes queue depth monitoring for the specified queue.

parent

Syntax 
parent {[weight weight] [cir-weight cir-weight]}
no parent
Context 
config>service>epipe>sap>egress>queue-override>queue
config>service>epipe>sap>ingress>queue-override>queue
config>service>apipe>sap>egress>queue-override>queue
config>service>apipe>sap>ingress>queue-override>queue
Description 

This command defines an optional parent scheduler that further governs the available bandwidth given the queue aside from the queue’s PIR setting. When multiple schedulers and/or queues share a child status with the parent scheduler, the weight or level parameters define how this queue contends with the other children for the parent’s bandwidth.

Checks are not performed to see if a scheduler-name exists when the parent command is defined on the queue. Scheduler names are configured in the config>qos>scheduler-policy>tier level context. Multiple schedulers can exist with the scheduler-name and the association pertains to a scheduler that should exist on the egress SAP as the policy is applied and the queue created. When the queue is created on the egress SAP, the existence of the scheduler-name is dependent on a scheduler policy containing the scheduler-name being directly or indirectly applied (through a multi-service customer site) to the egress SAP. If the scheduler-name does not exist, the queue is placed in the orphaned operational state. The queue will accept packets but will not be bandwidth limited by a virtual scheduler or the scheduler hierarchy applied to the SAP. The orphaned state must generate a log entry and a trap message. The SAP which the queue belongs to must also depict an orphan queue status. The orphaned state of the queue is automatically cleared when the scheduler-name becomes available on the egress SAP.

The parent scheduler can be made unavailable due to the removal of a scheduler policy or scheduler. When an existing parent scheduler is removed or inoperative, the queue enters the orphaned state mentioned above and automatically return to normal operation when the parent scheduler is available again.

When a parent scheduler is defined without specifying weight or strict parameters, the default bandwidth access method is weight with a value of 1.

The no form of the command removes a child association with a parent scheduler. If a parent association does not currently exist, the command has no effect and returns without an error. Once a parent association has been removed, the former child queue attempts to operate based on its configured rate parameter. Removing the parent association on the queue within the policy takes effect immediately on all queues using the SAP egress QoS policy.

Parameters 
weight—
These optional keywords are mutually exclusive to the level keyword. The weight defines the relative weight of this queue in comparison to other child schedulers, policers, and queues while vying for bandwidth on the parent scheduler-name. Any policers, queues, or schedulers defined as weighted receive no parental bandwidth until all policers, queues, and schedulers with a higher (numerically larger) priority on the parent have reached their maximum bandwidth or are idle.

All weight values from all weighted active policers, queues, and schedulers with a common parent scheduler are added together. Then, each individual active weight is divided by the total, deriving the percentage of remaining bandwidth provided to the policer, queue, or scheduler. A weight is considered to be active when the pertaining policer, queue, or scheduler has not reached its maximum rate and still has packets to transmit. All child policers, queues, and schedulers with a weight of 0 are considered to have the lowest priority level and are not serviced until all non-zero weighted policers, queues, and schedulers at that level are operating at the maximum bandwidth or are idle.

Values—
0 to 100
Values—
1
cir-weight—
Defines the weight the queue or scheduler will use at the within-cir port priority level (defined by the cir-level parameter). The weight is specified as an integer value from 0 to 100 with 100 being the highest weight. When the cir-weight parameter is set to a value of 0 (the default value), the policer, queue, or scheduler does not receive bandwidth during the port schedulers within-cir pass and the cir-level parameter is ignored. If the cir-weight parameter is 1 or greater, the cir-level parameter comes into play.
Values—
0 to 100

percent-rate

Syntax 
percent-rate pir-percent [cir cir-percent]
Context 
config>service>epipe>sap>egress>queue-override>queue
Description 

The percent-rate command supports a queue’s shaping rate and CIR rate as a percentage of the egress port’s line rate. When the rates are expressed as a percentage within the template, the actual rate used per instance of the queue group queue-id will vary based on the port speed. For example, when the same template is used to create a queue group on a 1-Gigabit and a 10-Gigabit Ethernet port, the queue’s rates will be 10 times greater on the 10 Gigabit port due to the difference in port speeds. This enables the same template to be used on multiple ports without needing to use port based queue overrides to modify a queue’s rate to get the same relative performance from the queue.

If the port’s speed changes after the queue is created, the queue’s shaping and CIR rates will be recalculated based on the defined percentage value.

The rate and percent-rate commands override one another. If the current rate for a queue is defined using the percent-rate command and the rate command is executed, the percent-rate values are deleted. In a similar fashion, the percent-rate command causes any rate command values to be deleted. A queue’s rate may dynamically be changed back and forth from a percentage to an explicit rate at anytime.

An egress port queue group queue rate override may be expressed as either a percentage or an explicit rate independent on how the queue's template rate is expressed.

The no form of this command returns the queue to its default shaping rate and cir rate. When no percent-rate is defined within a port egress queue group queue override, the queue reverts to the defined shaping and CIR rates within the egress queue group template associated with the queue.

Parameters 
pir-percent
Specifies the queue’s shaping rate as a percentage of line rate. The line rate associated with the queue’s port may dynamically change due to configuration or auto-negotiation. The line rate may also be affected by an egress port scheduler defined max-rate.
Values—
0.01 to 100.00
Values—
100.00
cir-percent—
Specifies the queue’s committed scheduling rate as a percentage of line rate. The line rate associated with the queue’s port may dynamically change due to configuration or auto-negotiation. The line rate may also be affected by an egress port scheduler defined max-rate.
Values—
0.00 to 100.00
Values—
100.00

rate

Syntax 
rate pir-rate [cir cir-rate]
no rate
Context 
config>service>apipe>sap>egress>queue-override>queue
config>service>apipe>sap>ingress>queue-override>queue
config>service>cpipe>sap>egress>queue-override>queue
config>service>cpipe>sap>ingress>queue-override>queue
config>service>fpipe>sap>egress>queue-override>queue
config>service>fpipe>sap>ingress>queue-override>queue
config>service>ipipe>sap>egress>queue-override>queue
config>service>ipipe>sap>ingress>queue-override>queue
config>service>epipe>sap>egress>queue-override>queue
config>service>epipe>sap>ingress>queue-override>queue
Description 

This command can be used to override specific attributes of the specified queue’s Peak Information Rate (PIR) and the Committed Information Rate (CIR) parameters.

The PIR defines the maximum rate that the queue can transmit packets out an egress interface (for SAP egress queues). Defining a PIR does not necessarily guarantee that the queue can transmit at the intended rate. The actual rate sustained by the queue can be limited by oversubscription factors or available egress bandwidth.

The CIR defines the rate at which the system prioritizes the queue over other queues competing for the same bandwidth. In-profile and then out-of-profile packets are preferentially queued by the system at egress and at subsequent next hop nodes where the packet can traverse. To be properly handled throughout the network, the packets must be marked accordingly for profiling at each hop.

The CIR can be used by the queue’s parent commands cir-level and cir-weight parameters to define the amount of bandwidth considered to be committed for the child queue during bandwidth allocation by the parent scheduler.

The rate command can be executed at any time, altering the PIR and CIR rates for all queues created through the association of the SAP egress QoS policy with the queue-id.

The no form of the command returns all queues created with the queue-id by association with the QoS policy to the default PIR and CIR parameters (max, 0).

Default 

rate max cir 0 — The max default specifies the amount of bandwidth in kilobits per second (thousand bits per second). The max value is mutually exclusive to the pir-rate value.

Parameters 
pir-rate—
Defines the administrative PIR rate, in kilobits per second, for the queue. When the rate command is executed, a valid PIR setting must be explicitly defined. When the rate command has not been executed, the default PIR of max is assumed.

Fractional values are not allowed and must be given as a positive integer.

The actual PIR rate is dependent on the queue’s adaptation-rule parameters and the actual hardware where the queue is provisioned.

Values—
1 to 3200000000, max
Values—
max
cir-rate—
The cir parameter overrides the default administrative CIR used by the queue. When the rate command is executed, a CIR setting is optional. When the rate command has not been executed or the cir parameter is not explicitly specified, the default CIR (0) is assumed.

Fractional values are not allowed and must be given as a positive integer. The sum keyword specifies that the CIR be used as the summed CIR values of the children schedulers, policers, or queues.

Values—
0 to 3200000000, max, sum
Values—
0

scheduler-override

Syntax 
[no] scheduler-override
Context 
config>service>apipe>sap>egress
config>service>apipe>sap>ingress
config>service>cpipe>sap>egress
config>service>cpipe>sap>ingress
config>service>fpipe>sap>egress
config>service>fpipe>sap>ingress
config>service>ipipe>sap>egress
config>service>ipipe>sap>ingress
config>service>epipe>sap>egress
config>service>epipe>sap>ingress
Description 

This command specifies the set of attributes whose values have been overridden by management on this virtual scheduler. Clearing a given flag will return the corresponding overridden attribute to the value defined on the SAP's ingress scheduler policy.

scheduler

Syntax 
[no] scheduler scheduler-name [create]
Context 
config>service>apipe>sap>egress>sched-override
config>service>apipe>sap>ingress>sched-override
config>service>cpipe>sap>egress>sched-override
config>service>cpipe>sap>ingress>sched-override
config>service>fpipe>sap>egress>sched-override
config>service>fpipe>sap>ingress>sched-override
config>service>ipipe>sap>egress>sched-override
config>service>ipipe>sap>ingress>sched-override
config>service>epipe>sap>egress>sched-override
config>service>epipe>sap>ingress>sched-override
Description 

This command can be used to override specific attributes of the specified scheduler name. A scheduler defines bandwidth controls that limit each child (other schedulers, policers, and queues) associated with the scheduler. Scheduler objects are created within the hierarchical tiers of the policy. It is assumed that each scheduler created will have policers, queues or other schedulers defined as child associations. The scheduler can be a child (take bandwidth from a scheduler in a higher tier, except for schedulers created in tier 1). A total of 32 schedulers can be created within a single scheduler policy with no restriction on the distribution between the tiers.

Each scheduler must have a unique name within the context of the scheduler policy; however the same name can be reused in multiple scheduler policies. If scheduler-name already exists within the policy tier level (regardless of the inclusion of the keyword create), the context changes to that scheduler name for the purpose of editing the scheduler parameters. Modifications made to an existing scheduler are executed on all instantiated schedulers created through association with the policy of the edited scheduler. This can cause policers, queues, or schedulers to become orphaned (invalid parent association) and adversely affect the ability of the system to enforce service level agreements (SLAs).

If the scheduler-name exists within the policy on a different tier (regardless of the inclusion of the keyword create), an error occurs and the current CLI context will not change.

If the scheduler-name does not exist in this or another tier within the scheduler policy, it is assumed that an attempt is being made to create a scheduler of that name. The success of the command execution is dependent on the following:

  1. The maximum number of schedulers has not been configured.
  2. The provided scheduler-name is valid.
  3. The create keyword is entered with the command if the system is configured to require it (enabled in the environment create command).

When the maximum number of schedulers has been exceeded on the policy, a configuration error occurs and the command will not execute, nor will the CLI context change.

If the provided scheduler-name is invalid according to the criteria below, a name syntax error will occur, the command will not execute, and the CLI context will not change.

Parameters 
scheduler-name—
The name of the scheduler.
Values—
Valid names consist of any string up to 32 characters long composed of printable, 7-bit ASCII characters. If the string contains special characters (#, $, spaces, etc.), the entire string must be enclosed within double quotes.
Values—
None. Each scheduler must be explicitly created.
create—
This optional keyword explicitly specifies that it is acceptable to create a scheduler with the given scheduler-name. If the create keyword is omitted, scheduler-name is not created when the system environment variable create is set to true. This safeguard is meant to avoid accidental creation of system objects (such as schedulers) while attempting to edit an object with a mistyped name or ID. The keyword has no effect when the object already exists.

parent

Syntax 
parent [weight weight] [cir-weight cir-weight]
no parent
Context 
config>service>apipe>sap>ingress>sched-override>scheduler
config>service>apipe>sap>egress>sched-override>scheduler
config>service>cpipe>sap>ingress>sched-override>scheduler
config>service>cpipe>sap>egress>sched-override>scheduler
config>service>epipe>sap>ingress>sched-override>scheduler
config>service>epipe>sap>egress>sched-override>scheduler
config>service>fpipe>sap>ingress>sched-override>scheduler
config>service>fpipe>sap>egress>sched-override>scheduler
config>service>ipipe>sap>ingress>sched-override>scheduler
config>service>ipipe>sap>egress>sched-override>scheduler
Description 

This command can be used to override the scheduler’s parent weight and cir-weight information. The weights apply to the associated level/cir-level configured in the applied scheduler policy. The scheduler name must exist in the scheduler policy applied to the ingress or egress of the SAP or multi-service site.

The override weights are ignored if the scheduler does not have a parent command configured in the scheduler policy – this allows the parent of the scheduler to be removed from the scheduler policy without having to remove all of the SAP/MSS overrides. If the parent scheduler does not exist causing the configured scheduler to be fostered on an egress port scheduler, the override weights will be ignored and the default values used; this avoids having non default weightings for fostered schedulers.

The no form of the command returns the scheduler’s parent weight and cir-weight to the value configured in the applied scheduler policy.

Default 

no parent

Parameters 
weight—
Weight defines the relative weight of this scheduler in comparison to other child schedulers, policers, and queues at the same strict level defined by the level parameter in the applied scheduler policy. Within the level, all weight values from active children at that level are summed and the ratio of each active child’s weight to the total is used to distribute the available bandwidth at that level. A weight is considered to be active when the policer, queue, or scheduler the weight pertains to has not reached its maximum rate and still has packets to transmit.

A 0 (zero) weight value signifies that the child scheduler will receive bandwidth only after bandwidth is distributed to all other non-zero weighted children in the strict level.

Values—
0 to 100
Values—
1
cir-weight—
The cir-weight keyword defines the relative weight of this scheduler in comparison to other child schedulers, policers, and queues at the same cir-level defined by the cir-level parameter in the applied scheduler policy. Within the strict cir-level, all cir-weight values from active children at that level are summed and the ratio of each active child’s cir-weight to the total is used to distribute the available bandwidth at that level. A cir-weight is considered to be active when the policer, queue, or scheduler that the cir-weight pertains to has not reached the CIR and still has packets to transmit.

A 0 (zero) cir-weight value signifies that the child scheduler will receive bandwidth only after bandwidth is distributed to all other non-zero weighted children in the strict cir-level.

Values—
0 to 100
Values—
1

rate

Syntax 
rate pir-rate [cir cir-rate]
no rate
Context 
config>service>apipe>sap>egress>sched-override>scheduler
config>service>apipe>sap>ingress>sched-override>scheduler
config>service>cpipe>sap>egress>sched-override>scheduler
config>service>cpipe>sap>ingress>sched-override>scheduler
config>service>fpipe>sap>egress>sched-override>scheduler
config>service>fpipe>sap>ingress>sched-override>scheduler
config>service>ipipe>sap>egress>sched-override>scheduler
config>service>ipipe>sap>ingress>sched-override>scheduler
config>service>epipe>sap>egress>sched-override>scheduler
config>service>epipe>sap>ingress>sched-override>scheduler
Description 

This command can be used to override specific attributes of the specified scheduler rate. The rate command defines the maximum bandwidth that the scheduler can offer its child policers, queues or schedulers. The maximum rate is limited to the amount of bandwidth the scheduler can receive from its parent scheduler. If the scheduler has no parent, the maximum rate is assumed to be the amount available to the scheduler. When a parent is associated with the scheduler, the CIR parameter provides the amount of bandwidth to be considered during the parent scheduler’s ‘within CIR’ distribution phase.

The actual operating rate of the scheduler is limited by bandwidth constraints other than its maximum rate. The scheduler’s parent scheduler may not have the available bandwidth to meet the scheduler’s needs or the bandwidth available to the parent scheduler could be allocated to other child schedulers or child policers or queues on the parent based on higher priority. The children of the scheduler may not need the maximum rate available to the scheduler due to insufficient offered load or limits to their own maximum rates.

When a scheduler is defined without specifying a rate, the default rate is max. If the scheduler is a root scheduler (no parent defined), the default maximum rate must be changed to an explicit value. Without this explicit value, the scheduler will assume that an infinite amount of bandwidth is available and allow all child policers, queues, and schedulers to operate at their maximum rates.

The no form of this command returns the scheduler’s PIR and CIR parameters to the values configured in the applied scheduler policy.

Parameters 
pir-rate—
The pir parameter accepts the max keyword or a value of 1 to 3200000000. Any other value will result in an error without modifying the current PIR rate.
Values—
1 to 3200000000, max
Values—
max
cir cir-rate—
The cir parameter accepts a value of 0 to 3200000000 or the max keyword. Any other value will result in an error without modifying the current CIR rate.

If the cir parameter is set to max, then the CIR rate is set to infinity but bounded by the PIR rate.

The sum keyword specifies that the CIR will be used as the summed CIR values of the children schedulers, policers, or queues.

Values—
0 to 3200000000, max, sum
Values—
sum

scheduler-policy

Syntax 
scheduler-policy scheduler-policy-name
no scheduler-policy
Context 
config>service>apipe>sap>ingress
config>service>apipe>sap>egress
config>service>cpipe>sap>ingress
config>service>cpipe>sap>egress
config>service>fpipe>sap>ingress
config>service>fpipe>sap>egress
config>service>ipipe>sap>ingress
config>service>ipipe>sap>egress
config>service>epipe>sap>ingress
config>service>epipe>sap>egress
Description 

This command applies an existing scheduler policy to an ingress or egress scheduler used by SAP queues associated with this multi-service customer site. The schedulers defined in the scheduler policy can only be created once the customer site has been appropriately assigned to a chassis port, channel or slot. Scheduler policies are defined in the config>qos>scheduler-policy scheduler-policy-name context.

The no form of this command removes the configured ingress or egress scheduler policy from the multi-service customer site. When the policy is removed, the schedulers created due to the policy are removed also making them unavailable for the ingress SAP queues associated with the customer site. Policers or queues that lose their parent scheduler association are deemed to be orphaned and are no longer subject to a virtual scheduler. The SAPs that have policers or queues reliant on the removed schedulers enter into an operational state depicting the orphaned status of one or more policers or queues. When the no scheduler-policy command is executed, the customer site ingress or egress node will not contain an applied scheduler policy.

Parameters 
scheduler-policy-name—
The scheduler-policy-name parameter applies an existing scheduler policy that was created in the config>qos>scheduler-policy scheduler-policy-name context to create the hierarchy of ingress or egress virtual schedulers. The scheduler names defined within the policy are created and made available to any ingress or egress queues and to egress policers managed by HQoS created on associated SAPs.

vlan-translation

Syntax 
vlan-translation {vlan-id | copy-outer}
no vlan-translation
Context 
config>service>epipe>sap>ingress
Description 

This command configures ingress VLAN translation. If enabled with an explicit VLAN value, the preserved vlan-id will be overwritten with this value. This setting is applicable to dot1q encapsulated ports. If enabled with “copy-outer” keyword, the outer vlan-id will be copied to inner position on QinQ encapsulated ports. The feature is not supported on default-dot1q saps (1/1/1:* and 1/1/1:0), nor on TopQ saps.

The no version of the command sets the default value and no action will be taken.

Default 

By default, the preserved VLAN values will not be overwritten.

Parameters 
vlan-id—
Specifies that the preserved vlan-id will be overwritten with this value.
Values—
0 to 4094
copy-outer—
Keyword specifies to use the outer VLAN ID.

match-qinq-dot1p

Syntax 
match-qinq-dot1p {top | bottom}
no match-qinq-dot1p de
Context 
config>service>ipipe>sap>ingress
config>service>epipe>sap>ingress
Description 

This command specifies which Dot1Q tag position Dot1P bits in a QinQ encapsulated packet should be used to evaluate Dot1P QoS classification.

The match-qinq-dot1p command allows the top or bottom PBits to be used when evaluating the applied sap-ingress QoS policy’s Dot1P entries. The top and bottom keywords specify which position should be evaluated for QinQ encapsulated packets.

The setting also applies to classification based on the DE indicator bit.

The no form of this command reverts the dot1p and de bits matching to the default tag.

By default, the bottom most service delineating Dot1Q tags Dot1P bits are used. Table 15 defines the default behavior for Dot1P evaluation.

Table 15:  Default QinQ and TopQ SAP Dot1P Evaluation 

Port / SAP Type

Existing Packet Tags

PBits Used for Match  

Null

None

None

Null

Dot1P (VLAN-ID 0)

Dot1P PBits

Null

Dot1Q

Dot1Q PBits

Null

TopQ BottomQ

TopQ PBits

Null

TopQ (No BottomQ)

TopQ PBits

Dot1Q

None (Default SAP)

None

Dot1Q

Dot1P (Default SAP VLAN-ID 0)

Dot1P PBits

Dot1Q

Dot1Q

Dot1Q PBits

QinQ / TopQ

TopQ

TopQ PBits

QinQ / TopQ

TopQ BottomQ

TopQ PBits

QinQ / QinQ

TopQ BottomQ

BottomQ PBits

Default 

no match-qinq-dot1p (no filtering based on p-bits)

(top or bottom must be specified to override the default QinQ dot1p behavior)

Parameters 
top—
The top parameter is mutually exclusive to the bottom parameter. When the top parameter is specified, the top most PBits are used (if existing) to match any dot1p dot1p-value entries. Table 16 defines the dot1p evaluation behavior when the top parameter is specified.
Table 16:  Top Position QinQ dot1P Evaluation Behavior 

Port / SAP Type

Existing Packet Tags

PBits Used for Match

Null

None

None

Null

Dot1P (VLAN-ID 0)

Dot1P PBits

Null

Dot1Q

Dot1Q PBits

Null

TopQ BottomQ

TopQ PBits

Null

TopQ (No BottomQ)

TopQ PBits

Dot1Q

None (Default SAP)

None

Dot1Q

Dot1P (Default SAP VLAN-ID 0)

Dot1P PBits

Dot1Q

Dot1Q

Dot1Q PBits

QinQ / TopQ

TopQ

TopQ PBits

QinQ / TopQ

TopQ BottomQ

TopQ PBits

QinQ / QinQ

TopQ BottomQ

TopQ PBits

bottom—
The bottom parameter is mutually exclusive to the top parameter. When the bottom parameter is specified, the bottom most PBits are used (if existing) to match any dot1p dot1p-value entries. Table 17 defines the dot1p evaluation behavior when the bottom parameter is specified.
Table 17:  Bottom Position QinQ and TopQ SAP Dot1P Evaluation 

Port / SAP Type

Existing Packet Tags

PBits Used for Match  

Null

None

None

Null

Dot1P (VLAN-ID 0)

Dot1P PBits

Null

Dot1Q

Dot1Q PBits

Null

TopQ BottomQ

TopQ PBits

Null

TopQ (No BottomQ)

TopQ PBits

Dot1Q

None (Default SAP)

None

Dot1Q

Dot1P (Default SAP VLAN-ID 0)

Dot1P PBits

Dot1Q

Dot1Q

Dot1Q PBits

QinQ / TopQ

TopQ

TopQ PBits

QinQ / TopQ

TopQ BottomQ

TopQ PBits

QinQ / QinQ

TopQ BottomQ

BottomQ PBits

Table 18:  Egress SAP Types 

Egress SAP Type

Ingress Packet Preserved Dot1P State

Marked (or Remarked) PBits

Null

No preserved Dot1P bits

None

Null

Preserved Dot1P bits

Preserved tag PBits remarked using dot1p-value

Dot1Q

No preserved Dot1P bits

New PBits marked using dot1p-value

Dot1Q

Preserved Dot1P bits

Preserved tag PBits remarked using dot1p-value

TopQ

No preserved Dot1P bits

TopQ PBits marked using dot1p-value

TopQ

Preserved Dot1P bits (used as TopQ and BottomQ PBits)

TopQ PBits marked using dot1p-value, BottomQ PBits preserved

QinQ

No preserved Dot1P bits

TopQ PBits and BottomQ PBits marked using dot1p-value

QinQ

Preserved Dot1P bits (used as TopQ and BottomQ PBits)

TopQ PBits and BottomQ PBits marked using dot1p-value

The QinQ and TopQ SAP PBit/DEI bit marking follows the default behavior defined in the table above when qinq-mark-top-only is not specified.

The dot1p dot1p-value command must be configured without the qinq-mark-top-only parameter to remove the TopQ PBits only marking restriction.

Note that a QinQ-encapsulated Ethernet port can have two different sap types:

For a TopQ SAP type, only the outer (top) tag is explicitly specified. For example, sap 1/1/1:10.*

For QinQ SAP type, both inner (bottom) and outer (top) tags are explicitly specified. For example, sap 1/1/1:10.100.

VLL Frame Relay Commands

frame-relay

Syntax 
frame-relay
Context 
config>service>apipe>sap
config>service>fpipe>sap
config>service>ipipe>sap
config>service>epipe>sap
Description 

This command enables the context to configure Frame Relay parameters.

frf-12

Syntax 
[no] frf-12
Context 
config>service>fpipe>sap>frame-relay
config>service>ipipe>sap>frame-relay
config>service>epipe>sap>frame-relay
Description 

This command enables the use of FRF12 headers.

The no form of the command disables the use of FRF12 headers.

ete-fragment-threshold

Syntax 
ete-fragment-threshold threshold
no ete-fragment-threshold
Context 
config>service>fpipe>sap>frame-relay>frf-12
config>service>ipipe>sap>frame-relay>frf-12
config>service>epipe>sap>frame-relay>frf-12
Description 

This command specifies the maximum length of a fragment to be transmitted.

The no form of the command reverts to the default.

Parameters 
threshold—
The maximum length of a fragment to be transmitted.
Values—
128 to 512
Values—
0

interleave

Syntax 
[no] interleave
Context 
config>service>epipe>sap>frame-relay>frf.12
config>service>ipipe>sap>frame-relay>frf.12
Description 

This command enables interleaving of high priority frames and low-priority frame fragments within a FR SAP using FRF.12 end-to-end fragmentation.

When this option is enabled, only frames of the FR SAP non expedited forwarding class queues are subject to fragmentation. The frames of the FR SAP expedited queues are interleaved, with no fragmentation header, among the fragmented frames. In effect, this provides a behavior like in MLPPP Link Fragment Interleaving (LFI).

When this option is disabled, frames of all the FR SAP forwarding class queues are subject to fragmentation. The fragmentation header is however not included when the frame size is smaller than the user configured fragmentation size. In this mode, the SAP transmits all fragments of a frame before sending the next full or fragmented frame.

The receive direction of the FR SAP supports both modes of operation concurrently, with and without fragment interleaving.

The no form of this command restores the default mode of operation.

Default 

no interleave

scheduling-class

Syntax 
scheduling-class class-id
Context 
config>service>apipe>sap>frame-relay
config>service>fpipe>sap>frame-relay
config>service>ipipe>sap>frame-relay
config>service>epipe>sap>frame-relay
Description 

This command specifies the scheduling class to use for this SAP.

Parameters 
class-id—
Specifies the scheduling class to use for this sap.
Values—
0 to 3
Values—
0

VLL SDP Commands

spoke-sdp

Syntax 
spoke-sdp sdp-id[:vc-id] [vc-type {ether | vlan}] [no-endpoint]
spoke-sdp sdp-id[:vc-id] [vc-type {ether | vlan}] endpoint endpoint-name [icb]
no spoke-sdp sdp-id[:vc-id]
Context 
config>service>cpipe
config>service>epipe
Description 

This command binds a service to an existing Service Distribution Point (SDP). A spoke SDP is treated like the equivalent of a traditional bridge “port” where flooded traffic received on the spoke SDP is replicated on all other “ports” (other spoke and mesh SDPs or SAPs) and not transmitted on the port it was received.

The SDP has an operational state which determines the operational state of the SDP within the service. For example, if the SDP is administratively or operationally down, the SDP for the service will be down.

The SDP must already be defined in the config>service>sdp context in order to associate an SDP with an Epipe, VPLS, VPRN, VPRN service. If the sdp sdp-id is not already configured, an error message is generated. If the sdp-id does exist, a binding between that sdp-id and the service is created.

SDPs must be explicitly associated and bound to a service. If an SDP is not bound to a service, no far-end devices can participate in the service.

The no form of this command removes the SDP binding from the service. The SDP configuration is not affected; only the binding of the SDP to a service. Once removed, no packets are forwarded to the far-end router.

Default 

No sdp-id is bound to a service.

Special Cases 
Epipe—
At most, only one sdp-id can be bound to an Epipe service. Since an Epipe is a point-to-point service, it can have, at most, two end points. The two end points can be one SAP and one SDP or two SAPs. Vc-switching VLLs are an exception. If the VLL is a “vc-switching” VLL, then the two endpoints must both be SDPs.

L2TPv3 SDP types are only supported on Epipe services and not other xpipe services.

Parameters 
sdp-id—
The SDP identifier.
Values—
1 to 17407
vc-id—
The virtual circuit identifier. The VC-ID is not used with L2TPv3 SDPs, however it must be configured.
Values—
1 to 4294967295
vc-type—
This command overrides the default VC type signaled for the spoke or mesh binding to the far end of the SDP. The VC type is a 15 bit-quantity containing a value which represents the type of VC. The actual signaling of the VC type depends on the signaling parameter defined for the SDP. If signaling is disabled, the vc-type command can still be used to define the dot1q value expected by the far-end provider equipment. A change of the bindings VC type causes the binding to signal the new VC type to the far end when signaling is enabled.

VC types are derived according to IETF draft-martini-l2circuit-trans-mpls.

The VC type value for Ethernet is 0x0005.

The VC type value for an Ethernet VLAN is 0x0004.

The VC type value for a VPLS service is defined as 0x000B.

Values—
ethernet
ether—
Defines the VC type as Ethernet. The ethernet and vlan keywords are mutually exclusive. When the VC type is not defined then the default is Ethernet for spoke SDP bindings. Defining Ethernet is the same as executing no vc-type and restores the default VC type for the spoke SDP binding.
vlan—
Defines the VC type as VLAN. The top VLAN tag, if a VLAN tag is present, is stripped from traffic received on the pseudowire, and a vlan-tag is inserted when forwarding into the pseudowire. The ethernet and vlan keywords are mutually exclusive. When the VC type is not defined then the default is Ethernet for spoke SDP bindings.

The VLAN VC-type requires at least one dot1Q tag within each encapsulated Ethernet packet transmitted to the far end.

Note: The system expects a symmetrical configuration with its peer, specifically it expects to remove the same number of VLAN tags from received traffic as it adds to transmitted traffic. As some of the related configuration parameters are local and not communicated in the signaling plane, an asymmetrical behavior cannot always be detected and so cannot be blocked. Consequently, protocol extractions will not necessarily function for asymmetrical configurations as they would with a symmetrical configurations resulting in an unexpected operation.

no-endpoint—
Removes the association of a spoke SDP with an explicit endpoint name.
endpoint-name—
Specifies the name of the service endpoint.
icb—
Configures the spoke SDP as an inter-chassis backup SDP binding.

spoke-sdp

Syntax 
spoke-sdp sdp-id[:vc-id] [no-endpoint]
spoke-sdp sdp-id[:vc-id] endpoint endpoint-name [icb]
no spoke-sdp sdp-id[:vc-id]
Context 
config>service>apipe
config>service>fpipe
config>service>ipipe
config>service>cpipe
Description 

This command binds a service to an existing Service Distribution Point (SDP). A spoke SDP is treated like the equivalent of a traditional bridge “port” where flooded traffic received on the spoke SDP is replicated on all other “ports” (other spoke and mesh SDPs or SAPs) and not transmitted on the port it was received.

The SDP has an operational state which determines the operational state of the SDP within the service. For example, if the SDP is administratively or operationally down, the SDP for the service will be down.

The SDP must already be defined in the config>service>sdp context in order to associate an SDP with a service. If the sdp sdp-id is not already configured, an error message is generated. If the sdp-id does exist, a binding between that sdp-id and the service is created.

SDPs must be explicitly associated and bound to a service. If an SDP is not bound to a service, no far-end SR/ESS devices can participate in the service.

The no form of this command removes the SDP binding from the service. The SDP configuration is not affected; only the binding of the SDP to a service. Once removed, no packets are forwarded to the far-end router.

Default 

No sdp-id is bound to a service.

Parameters 
sdp-id—
The SDP identifier.
Values—
1 to 17407
vc-id—
The virtual circuit identifier.
Values—
1 to 4294967295
no-endpoint—
Adds or removes a spoke SDP association.
endpoint-name—
Specifies the name of the service endpoint.
icb—
Configures the spoke SDP as an inter-chassis backup SDP binding.

entropy-label

Syntax 
[no] entropy-label
Context 
config>service>epipe>spoke-sdp
config>service>ipipe>spoke-sdp
config>service>fpipe>spoke-sdp
config>service>vpls>spoke-sdp
config>service>vpls>mesh-sdp
config>service>pw-template
config>service>vpls>bgp-evpn>mpls
config>service>epipe>bgp-evpn>mpls
config>service>ies>if>spoke-sdp
config>service>vprn>if>spoke-sdp
config>service>vprn
Description 

This command enables or disables the use of entropy labels for spoke-SPDs.

If entropy-label is configured, the entropy label and ELI are inserted in packets for which at least one LSP in the stack for the far-end of the tunnel used by the service has advertised entropy-label-capability. If the tunnel is RSVP type, entropy-label can also be controlled under the config>router>mpls or config>router>mpls>lsp contexts.

The entropy label and hash label features are mutually exclusive. The entropy label cannot be configured on a spoke-SDP or service where the hash label feature has already been configured.

Default 

no entropy-label

hash-label

Syntax 
hash-label [signal-capability]
no hash-label
Context 
config>service>epipe>spoke-sdp
config>service>fpipe>spoke-sdp
config>service>ipipe>spoke-sdp
config>service>pw-template
config>service>vprn
config>service>vprn>if>spoke-sdp
config>service>ies>if>spoke-sdp
Description 

This command enables the use of the hash label on a VLL, VPRN or VPLS service bound to any MPLS type encapsulated SDP, as well as to a VPRN service that is using the auto-bind-tunnel with the resolution-filter set to any MPLS tunnel type. This feature is not supported on a service bound to a GRE SDP or for a VPRN service using the autobind mode with the gre option. This feature is also not supported on multicast packets forwarded using RSVP P2MP LPS or mLDP LSP in both the base router instance and in the multicast VPN (mVPN) instance. It is, however, supported when forwarding multicast packets using an IES/VPRN spoke-interface.

When this feature is enabled, the ingress data path is modified such that the result of the hash on the packet header is communicated to the egress data path for use as the value of the label field of the hash label. The egress data path appends the hash label at the bottom of the stack (BoS) and sets the S-bit to one (1).

In order to allow applications where the egress LER infers the presence of the hash label implicitly from the value of the label, the Most Significant Bit (MSB) of the result of the hash is set before copying into the Hash Label. This means that the value of the hash label will always be in the range [524,288 - 1,048,575] and will not overlap with the signaled/static LSP and signaled/static service label ranges. This also guarantees that the hash label will not match a value in the reserved label range.

The (unmodified) result of the hash continues to be used for the purpose of ECMP and LAG spraying of packets locally on the ingress LER. Note, however, that for VLL services, the result of the hash is overwritten and the ECMP and LAG spraying will be based on service-id when ingress SAP shared queuing is not enabled. However, the hash label will still reflect the result of the hash such that an LSR can use it to perform fine grained load balancing of VLL PW packets.

Packets generated in CPM and that are forwarded labeled within the context of a service (for example, OAM packets) must also include a Hash Label at the BoS and set the S-bit accordingly.

The TTL of the hash label is set to a value of 0.

The user enables the signaling of the hash-label capability under a VLL spoke-sdp, a VPLS spoke-sdp or mesh-sdp, or an IES/VPRN spoke interface by adding the signal-capability option. In this case, the decision whether to insert the hash label on the user and control plane packets by the local PE is solely determined by the outcome of the signaling process and can override the local PE configuration. The following are the procedures:

  1. The 7450 ESS or 7750 SR local PE will insert the flow label interface parameters sub-TLV with F=1 in the PW ID FEC element in the label mapping message for that spoke-sdp or mesh-sdp.
  2. If the remote PE includes this sub-TLV with F=1 or F=0, then local PE must insert the hash label in the user and control plane packets.
  3. If remote PE does not include this sub-TLV (for example, it does not support it, or it is supported but the user did not enable the hash-label option or the signal-capability option), then the local PE establishes the PW but must not insert the hash label in the user and control packets over that spoke-sdp or mesh-sdp. If the remote PE does not support the signal-capability option, then there are a couple of possible outcomes:
    1. If the hash-label option was enabled on the local configuration of the spoke-sdp or mesh-sdp at the remote PE, the PW packets received by the local PE will have the hash label included. These packets must be dropped. The only way to solve this is to disable the signaling capability option on the local node which will result in the insertion of the hash label by both PE nodes.
    2. If the hash-label option is not supported or was not enabled on the local configuration of the spoke-sdp or mesh-sdp at the remote PE, the PW received by the local PE will not have the hash label included.
  4. The user can enable or disable the signal-capability option in CLI as needed. When doing so, the 7450 ESS or 7750 SR must withdraw the label it sent to its peer and send a new label mapping message with the new value of the F bit in the flow label interface parameters sub-TLV of the PW ID FEC element.

The no form of this command disables the use of the hash label.

Default 

no hash-label

Parameters 
signal-capability—
Enables the signaling and negotiation of the use of the hash label between the local and remote PE nodes. The signal-capability option is not supported on a VPRN spoke-sdp.

cell-concatenation

Syntax 
cell-concatenation
Context 
config>service>apipe>spoke-sdp
Description 

This command enables the context to provide access to the various options that control the termination of ATM cell concatenation into an MPLS frame. Several options can be configured simultaneously. The concatenation process for a given MPLS packet ends when the first concatenation termination condition is met. The concatenation parameters apply only to ATM N:1 cell mode VLL.

aal5-frame-aware

Syntax 
[no] aal5-frame-aware
Context 
config>service>apipe>spoke-sdp>cell-concat
Description 

This command enables the configuration of AAL5 end-of-message (EOM) to be an indication to complete the cell concatenation operation.

The no form of the command resets the configuration to ignore the AAL5 EOM as an indication to complete the cell concatenation.

clp-change

Syntax 
[no] clp-change
Context 
config>service>apipe>spoke-sdp>cell-concat
Description 

This command enables the configuration of CLP change to be an indication to complete the cell concatenation operation.

The no form of the command resets the configuration to ignore the CLP change as an indication to complete the cell concatenation.

max-cells

Syntax 
max-cells cell-count
no max-cells [cell-count]
Context 
config>service>apipe>spoke-sdp>cell-concat
Description 

This command enables the configuration of the maximum number of ATM cells to accumulate into an MPLS packet. The remote peer will also signal the maximum number of concatenated cells it is willing to accept in an MPLS packet. When the lesser of (the configured value and the signaled value) number of cells is reached, the MPLS packet is queued for transmission onto the pseudowire. It is ensured that the MPLS packet MTU conforms to the configured service MTU.

The no form of this command sets max-cells to the value ‘1’ indicating that no concatenation will be performed.

Parameters 
cell-count—
Specify the maximum number of ATM cells to be accumulated into an MPLS packet before queuing the packet for transmission onto the pseudowire.
Values—
1 to 128
Values—
1

max-delay

Syntax 
max-delay delay-time
no max-delay [delay-time]
Context 
config>service>apipe>spoke-sdp>cell-concat
Description 

This command enables the configuration of the maximum amount of time to wait while performing ATM cell concatenation into an MPLS packet before transmitting the MPLS packet. This places an upper bound on the amount of delay introduced by the concatenation process. When this amount of time is reached from when the first ATM cell for this MPLS packet was received, the MPLS packet is queued for transmission onto the pseudowire.

The no form of this command resets max-delay to its default value.

Parameters 
delay-time—
Specifies the maximum amount of time, in hundreds of microseconds, to wait before transmitting the MPLS packet with whatever ATM cells have been received. For example, to bound the delay to 1 ms the user would configure 10 (hundreds of microseconds). The delay-time is rounded up to one of the following values 1, 5, 10, 50, 100, 200, 300 and 400.
Values—
1 to 400
Values—
400

control-word

Syntax 
[no] control-word
Context 
config>service>apipe>spoke-sdp
config>service>cpipe>spoke-sdp
config>service>epipe>spoke-sdp
config>service>fpipe>spoke-sdp
config>service>ipipe>spoke-sdp
Description 

The control word command provides the option to add a control word as part of the packet encapsulation for pseudowire types for which the control word is optional. These are Ethernet pseudowires (Epipe). For the 7750 SR only, ATM N:1 cell mode pseudowires (apipe vc-types atm-vcc and atm-vpc) and VT pseudowire (apipe vc-type atm-cell).

The configuration for the two directions of the pseudowire must match because the control word negotiation procedures described in Section 6.2 of RFC 4447 are not supported. The C-bit in the pseudowire FEC sent in the label mapping message is set to 1 when the control word is enabled. Otherwise, it is set to 0.

The service will only come up if the same C-bit value is signaled in both directions. If a spoke-sdp is configured to use the control word but the node receives a label mapping message with a C-bit clear, the node releases the label with the an “Illegal C-bit” status code as per Section 6.1 of RFC 4447. As soon as the user also enabled the control the remote peer, the remote peer will withdraw its original label and will send a label mapping with the C-bit set to 1 and the VLL service will be up in both nodes. The control word must be enabled to allow MPLS-TP OAM to be used on a static spoke-sdp in a apipe, epipe and cpipe service.

pw-path-id

Syntax 
[no] pw-path-id
Context 
config>service>epipe>spoke-sdp
config>service>cpipe>spoke-sdp
config>service>apipe>spoke-sdp
config>service>vpls>spoke-sdp
config>service>ies>if>spoke-sdp
config>service>vprn>if>spoke-sdp
Description 

This command enables the context to configure an MPLS-TP Pseudowire Path Identifier for a spoke-sdp. All elements of the PW path ID must be configured in order to enable a spoke-sdp with a PW path ID.

For an IES or VPRN spoke-sdp, the pw-path-id is only valid for ethernet spoke-sdps.

The pw-path-id is only configurable if all of the following is true:

  1. The system is using network chassis mode D
  2. SDP signaling is off
  3. control-word is enabled (control-word is disabled by default)
  4. the service type is epipe, vpls, cpipe, apipe, or IES/VPRN interface
  5. mate SDP signaling is off for vc-switched services

The no form of the command deletes the PW path ID.

Default 

no pw-path-id

agi

Syntax 
agi agi
no agi
Context 
config>service>epipe>spoke-sdp>pw-path-id
config>service>cpipe>spoke-sdp>pw-path-id
config>service>apipe>spoke-sdp>pw-path-id
config>service>vpls>spoke-sdp>pw-path-id
config>service>ies>if>spoke-sdp>pw-path-id
config>service>vprn>if>spoke-sdp>pw-path-id
Description 

This command configures the attachment group identifier for an MPLS-TP PW.

Parameters 
agi—
Specifies the attachment group identifier.
Values—
0 to 4294967295

saii-type2

Syntax 
saii-type2 global-id:node-id:ac-id
no saii-type2
Context 
config>service>epipe>spoke-sdp>pw-path-id
config>service>cpipe>spoke-sdp>pw-path-id
config>service>apipe>spoke-sdp>pw-path-id
config>service>vpls>spoke-sdp>pw-path-id
config>service>ies>if>spoke-sdp>pw-path-id
config>service>vprn>if>spoke-sdp>pw-path-id
Description 

This command configures the source individual attachment identifier (SAII) for an MPLS-TP spoke-sdp. If this is configured on a spoke-sdp for which vc-switching is also configured (for example, it is at an S-PE), then the values must match those of the taii-type2 of the mate spoke-sdp.

Parameters 
global-id—
Specifies the global ID at the source PE or T-PE for the MPLS-TP PW for a spoke-SDP.
Values—
0 to 4294967295
node-id—
Specifies the node ID at the source PE or T-PE for the MPLS-TP PW for a spoke-SDP.
Values—
a.b.c.d or 0 to 4294967295
ac-id—
Specifies the attachment circuit ID at the source PE or T-PE for the MPLS-TP PW for a spoke-SDP. If this node is the source of the PW, then the AC ID must be set to a locally unique value.
Values—
1 to 4294967295

taii-type2

Syntax 
taii-type2 global-id:node-id:ac-id
no taii-type2
Context 
config>service>epipe>spoke-sdp>pw-path-id
config>service>cpipe>spoke-sdp>pw-path-id
config>service>apipe>spoke-sdp>pw-path-id
config>service>vpls>spoke-sdp>pw-path-id
config>service>ies>if>spoke-sdp>pw-path-id
config>service>vprn>if>spoke-sdp>pw-path-id
Description 

This command configures the target individual attachment identifier (TAII) for an MPLS-TP spoke-sdp. If this is configured on a spoke-sdp for which vc-switching is also configured (for example, it is at an S-PE), then the values must match those of the saii-type2 of the mate spoke-sdp.

Parameters 
global-id—
Specifies the global ID at the target PE or T-PE for the MPLS-TP PW for a spoke-SDP.
Values—
0 to 4294967295
node-id—
Specifies the node ID at the target PE or T-PE for the MPLS-TP PW for a spoke-SDP.
Values—
a.b.c.d or 0 to 4294967295
ac-id—
Specifies the attachment circuit ID at the target PE or T-PE for the MPLS-TP PW for a spoke-SDP. If this node is the source of the PW, then the AC ID must be set to a locally unique value.
Values—
1 to 4294967295

control-channel-status

Syntax 
[no] control-channel-status
Context 
config>service>cpipe>spoke-sdp
config>service>epipe>spoke-sdp
config>service>apipe>spoke-sdp
config>service>ies>if>spoke-sdp
config>service>vpls>spoke-sdp
config>service>vprn>if>spoke-sdp
Description 

This command enables the configuration of static pseudowire status signaling on a spoke-SDP for which signaling for its SDP is set to OFF.

A control-channel-status no shutdown is allowed only if all of the following are true:

  1. The system is using network chassis mode D
  2. SDP signaling is off.
  3. The control-word is enabled (the control-word is disabled by default)
  4. The service type is Epipe, Apipe, VPLS, Cpipe, or IES/VPRN
  5. Mate SDP signaling is off (in vc-switched services)
  6. The pw-path-id is configured for this spoke-SDP.

The no form of this command removes control channel status signaling from a spoke-SDP. It can only be removed if control channel status is shut down.

Default 

no control-channel-status

acknowledgment

Syntax 
[no] acknowledgment
Context 
config>service>cpipe>spoke-sdp>control-channel-status
config>service>epipe>spoke-sdp>control-channel-status
config>service>apipe>spoke-sdp>control-channel-status
config>service>vpls>spoke-sdp>control-channel-status
config>service>ies>if>spoke-sdp>control-channel-status
config>service>vprn>if>spoke-sdp>control-channel-status
Description 

This command enables the acknowledgment of control channel status messages. By default, no acknowledgment packets are sent.

refresh-timer

Syntax 
refresh-timer value
no refresh-timer
Context 
config>service>epipe>spoke-sdp>control-channel-status
config>service>cpipe>spoke-sdp>control-channel-status
config>service>apipe>spoke-sdp>control-channel-status
config>service>vpls>spoke-sdp>control-channel-status
config>service>ies>if>spoke-sdp>control-channel-status
config>service>vprn>if>spoke-sdp>control-channel-status
Description 

This command configures the refresh timer for control channel status signaling packets. By default, no refresh packets are sent.

Default 

no refresh-timer

Parameters 
value—
Specifies the refresh timer value, in seconds.
Values—
10 to 65535
Values—
0 (off)

request-timer

Syntax 
request-timer timer1 retry-timer timer2 timeout-multiplier multiplier
no request-timer
Context 
config>service>cpipe>spoke-sdp>control-channel-status
config>service>epipe>spoke-sdp>control-channel-status
config>service>apipe>spoke-sdp>control-channel-status
config>service>vpls>spoke-sdp>control-channel-status
config>service>ies>if>spoke-sdp>control-channel-status
config>service>vprn>if>spoke-sdp>control-channel-status
Description 

This command configures the control channel status request mechanism. When it is configured, control channel status request procedures are used. These augment the procedures for control channel status messaging from RFC 6478. This command is mutually exclusive with a non-zero refresh-timer value.

Parameters 
timer1—
Specifies the interval, in seconds, at which pseudowire status messages, including a reliable delivery TLV with the “request” bit set, are sent.
Values—
10 to 65535
timer2—
specifies the timeout interval, in seconds, if no response to a pseudowire status request is received. This parameter must be configured. A value of zero (0) disables retries.
Values—
0, 3 to 60
multiplier—
If a requesting node does not receive a valid response to a pseudowire status request within a number of seconds equal to the retry timer multiplied by this multiplier, then it will assume the pseudowire is down. This parameter is optional.
Values—
3 to 20

control-word

Syntax 
[no] control-word
Context 
config>service>ies>if>spoke-sdp
config>service>vprn>if>spoke-sdp
Description 

This command enables/disables the PW control word on spoke-sdps terminated on an IES or VPRN interface. The control word must be enabled to allow MPLS-TP OAM on the spoke-sdp.

It is only valid for MPLS-TP spoke-sdps when used with IES and VPRN services.

Default 

no control-word

egress

Syntax 
egress
Context 
config>service>apipe>spoke-sdp
config>service>cpipe>spoke-sdp
config>service>fpipe>spoke-sdp
config>service>ipipe>spoke-sdp
Description 

This command configures the egress SDP context.

hash-label

Syntax 
hash-label [signal-capability]
no hash label
Context 
config>service>fpipe>spoke-sdp
config>service>ipipe>spoke-sdp
config>service>epipe>spoke-sdp
Description 

This command enables the use of the hash label on a VLL, VPLS, or VPRN service bound to any MPLS type encapsulated SDP, as well as to a VPRN service using the auto-bind-tunnel with the resolution-filter set to any MPLS tunnel type. This feature is not supported on a service bound to a GRE SDP or for a VPRN service using the autobind mode with the gre option.

When this feature is enabled, the ingress data path is modified such that the result of the hash on the packet header is communicated to the egress data path for use as the value of the label field of the hash label. The egress data path appends the hash label at the bottom of the stack (BoS) and sets the S-bit to 1 to indicate that.

In order to allow for applications whereby the egress LER infers the presence of the Hash Label implicitly from the value of the label, the Most Significant Bit (MSB) of the result of the hash is set before copying into the Hash Label. This means that the value of the hash label will always be in the range [524,288 - 1,048,575] and will not overlap with the signaled/static LSP and signaled/static service label ranges. This also guarantees that the hash label will not match a value in the reserved label range.

The (unmodified) result of the hash continues to be used for the purpose of ECMP and LAG spraying of packets locally on the ingress LER. Note however that for VLL services, the result of the hash is overwritten and the ECMP and LAG spraying will be based on service-id when ingress SAP shared queuing is not enabled. However, the hash label will still reflect the result of the hash such that an LSR can use it to perform fine grained load balancing of VLL pseudowire packets.

Packets that are generated in CPM and forwarded labeled within the context of a service (for example, OAM packets) must also include a Hash Label at the BoS and set the S-bit accordingly.

The TTL of the Hash Label is set to a value of 0.

The no form of this command disables the use of the hash label.

The user enables the signaling of the hash-label capability under a VLL spoke-sdp, a VPLS spoke-sdp or mesh-sdp, or an IES/VPRN spoke interface by adding the signal-capability option. In this case, the decision whether to insert the hash label on the user and control plane packets by the local PE is solely determined by the outcome of the signaling process and can override the local PE configuration. The following are the procedures:

  1. The 7450 ESS or 7750 SR local PE will insert the flow label interface parameters sub-TLV with F=1 in the PW ID FEC element in the label mapping message for that spoke-sdp or mesh-sdp.
  2. If the remote PE includes this sub-TLV with F=1 or F=0, then local PE must insert the hash label in the user and control plane packets.
  3. If remote PE does not include this sub-TLV (for example, it does not support it, or it is supported but the user did not enable the hash-label option or the signal-capability option), then the local PE establishes the PW but must not insert the hash label in the user and control packets over that spoke-sdp or mesh-sdp. If the remote PE does not support the signal-capability option, then there are a couple of possible outcomes:
    1. If the hash-label option was enabled on the local configuration of the spoke-sdp or mesh-sdp at the remote PE, the PW packets received by the local PE will have the hash label included. These packets must be dropped. The only way to solve this is to disable the signaling capability option on the local node which will result in the insertion of the hash label by both PE nodes.
    2. If the hash-label option is not supported or was not enabled on the local configuration of the spoke-sdp or mesh-sdp at the remote PE, the PW received by the local PE will not have the hash label included.
  4. The user can enable or disable the signal-capability option in CLI as needed. When doing so, the 7450 ESS or 7750 SR must withdraw the label it sent to its peer and send a new label mapping message with the new value of the F bit in the flow label interface parameters sub-TLV of the PW ID FEC element.

The no form of this command disables the use of the hash label.

Default 

no hash-label

Parameters 
signal-capability—
Enables the signaling and negotiation of the use of the hash label between the local and remote PE nodes. The signal-capability option is not supported on a VPRN spoke-sdp.

ignore-oper-down

Syntax 
ignore-oper-down
[no] ignore-oper-down
Context 
config>service>epipe>sap>
Description 

An ePipe service will not transition to Oper State: Down when a SAP fails and when this optional command is configured under that specific SAP. Only a single SAP in an ePipe may have this optional command included.

Default 

no ignore-oper-down

ingress

Syntax 
ingress
Context 
config>service>fpipe>spoke-sdp
config>service>apipe>spoke-sdp
config>service>cpipe>spoke-sdp
Description 

This command configures the ingress SDP context.

filter

Syntax 
filter [ip ip-filter-id]
no filter
Context 
config>service>fpipe>spoke-sdp>egress
config>service>fpipe>spoke-sdp>ingress
Description 

This command associates an IP filter policy with an ingress or egress Service Distribution Point (SDP). Filter policies control the forwarding and dropping of packets based on IP matching criteria. Only one filter can be applied to a spoke SDP at a time.

The filter command is used to associate a filter policy with a specified ip-filter-id with an ingress or egress spoke SDP. The ip-filter-id must already be defined before the filter command is executed. If the filter policy does not exist, the operation will fail and an error message returned.

IP filters apply only to RFC 2427-routed IP packets. Frames that do not contain IP packets will not be subject to the filter and will always be passed, even if the filter's default action is to drop.

The no form of this command removes any configured filter ID association with the SDP. The filter ID itself is not removed from the system unless the scope of the created filter is set to local. To avoid deletion of the filter ID and only break the association with the service object, use the scope command within the filter definition to change the scope to local or global. The default scope of a filter is local.

Parameters 
ip—
Keyword indicating the filter policy is an IP filter.
ip-filter-id—
The filter name acts as the ID for the IP filter policy. The filter ID must already exist within the created IP filters.
Values—
1 to 65535

qos

Syntax 
qos network-policy-id port-redirect-group queue-group-name [instance instance-id]
no qos
Context 
config>service>apipe>spoke-sdp>egress
config>service>cpipe>spoke-sdp>egress
config>service>epipe>spoke-sdp>egress
config>service>fpipe>spoke-sdp>egress
config>service>ipipe>spoke-sdp>egress
config>service>vpls>spoke-sdp>egress
config>service>vpls>mesh-sdp>egress
config>service>pw-template>egress
config>service>vprn>if>spoke-sdp>egress
config>service>ies>if>spoke-sdp>egress
Description 

This command is used to redirect PW packets to an egress port queue-group for the purpose of shaping.

The egress PW shaping provisioning model allows the mapping of one or more PWs to the same instance of queues, or policers and queues, that are defined in the queue-group template.

Operationally, the provisioning model consists of the following steps:

  1. Create an egress queue-group template and configure queues only, or policers and queues for each FC that needs to be redirected.
  2. Apply the queue-group template to the network egress context of all ports where there exists a network IP interface that the PW packets can be forwarded on. This creates one instance of the template on the egress of the port. One or more instances of the same template can be created.
  3. Configure FC-to-policer or FC-to-queue mappings together with the redirect to a queue-group in the egress context of a network QoS policy. No queue-group name is specified in this step, which means the same network QoS policy can redirect different PWs to different queue-group templates.
  4. Apply this network QoS policy to the egress context of a spoke-sdp inside a service, or to the egress context of a PW template and specify the redirect queue-group name.

One or more spoke-sdps can have their FCs redirected to use queues only, or queues and policers in the same queue-group instance.

The following are the constraints and rules of this provisioning model:

  1. When a PW FC is redirected to use a queue or a policer and a queue in a queue-group and the queue-group name does not exist, the association is failed at the time the user associates the egress context of a spoke-sdp to the named queue-group. In such a case, the PW packet will be fed directly to the corresponding egress queue for that FC used by the IP network interface the PW packet is forwarded on. This queue can be a queue-group queue or the egress shared queue for that FC defined in the network-queue policy applied to the egress of this port. This is the existing implementation and default behavior for a PW packet.
  2. When a PW FC is redirected to use a queue or a policer and a queue in a queue-group and the queue-group name exists but the policer-id and/or the queue-id is not defined in the queue-group template, the association is failed at the time the user associates the egress context of a spoke-sdp to the named queue-group. In such a case, the PW packet will be fed directly to the corresponding egress queue for that FC used by the IP network interface the PW packet is forwarded on.
  3. When a PW FC is redirected to use a queue or a policer and a queue in a queue-group and the queue-group name exists and the policer-id or policer-id plus queue-id exist, it is not required to check that an instance of that queue-group exists in all egress network ports that have network IP interfaces. The handling of this is dealt with in the data path as follows:
    1. When a PW packet for that FC is forwarded and an instance of the referenced queue-group name exists on that egress port, the packet is processed by the queue-group policer and will then be fed to the queue-group queue.
    2. When a PW packet for that FC is forwarded and an instance of the referenced queue-group name does not exist on that egress port, the PW packet will be fed directly to the corresponding egress shared queue for that FC defined in the network-queue policy applied to the egress of this port.
  4. If a network QoS policy is applied to the egress context of a PW, any PW FC that is not explicitly redirected in the network QoS policy will have the corresponding packets feed directly the corresponding the egress shared queue for that FC defined in the network-queue policy applied to the egress of this port.

When the queue-group name the PW is redirected to exists and the redirection succeeds, the marking of the packet’s DEI/dot1p/DSCP and the tunnel’s DEI/dot1p/DSCP/EXP is performed according to the relevant mappings of the {FC, profile} in the egress context of the network QoS policy applied to the PW. This is true regardless if an instance of the queue-group exists or not on the egress port the PW packet is forwarded to. If the packet’s profile value changed due to egress child policer CIR profiling, the new profile value is used to mark the packet’s DEI/dot1p and the tunnel’s DEI/dot1p/EXP, and the DSCP/prec will be remarked if enable-dscp-prec-marking is enabled under the policer.

When the queue-group name the PW is redirected does not exist, the redirection command is failed. In this case, the marking of the packet’s DEI/dot1p/DSCP and the tunnel’s DEI/dot1p/DSCP/EXP fields is performed according to the relevant commands in the egress context of the network QoS policy applied to the network IP interface the PW packet is forwarded to.

The no version of this command removes the redirection of the PW to the queue-group.

Parameters 
network-policy-id—
Specifies the network policy identification. The value uniquely identifies the policy on the system.
Values—
1 to 65535
queue-group-name—
Specifies the name of the queue group template up to 32 characters in length.
instance-id—
Specifies the optional identification of a specific instance of the queue-group.
Values—
1 to 40960

qos

Syntax 
qos network-policy-id fp-redirect-group queue-group-name instance instance-id
no qos
Context 
config>service>apipe>spoke-sdp>ingress
config>service>cpipe>spoke-sdp>ingress
config>service>epipe>spoke-sdp>ingress
config>service>fpipe>spoke-sdp>ingress
config>service>ipipe>spoke-sdp>ingress
config>service>vpls>spoke-sdp>ingress
config>service>vpls>mesh-sdp>ingress
config>service>pw-template>ingress
config>service>vprn>if>spoke-sdp>ingress
config>service>ies>if>spoke-sdp>ingress
Description 

This command is used to redirect PW packets to an ingress forwarding plane queue-group for the purpose of rate-limiting.

The ingress PW rate-limiting feature uses a policer in queue-group provisioning model. This model allows the mapping of one or more PWs to the same instance of policers that are defined in a queue-group template.

Operationally, the provisioning model in the case of the ingress PW shaping feature consists of the following steps:

  1. Create an ingress queue-group template and configure policers for each FC that needs to be redirected and optionally for each traffic type (unicast or multicast).
  2. Apply the queue-group template to the network ingress forwarding plane where there exists a network IP interface that the PW packets can be received on. This creates one instance of the template on the ingress of the FP. One or more instances of the same template can be created.
  3. Configure FC-to-policer mappings together with the policer redirect to a queue-group in the ingress context of a network QoS policy. No queue-group name is specified in this step which means the same network QoS policy can redirect different PWs to different queue-group templates.
  4. Apply this network QoS policy to the ingress context of a spoke-sdp inside a service, or to the ingress context of a PW template and specify the redirect queue-group name.

One or more spoke-sdps can have their FCs redirected to use policers in the same policer queue-group instance.

The following are the constraints and rules of this provisioning model when used in the ingress PW rate-limiting feature:

  1. When a PW FC is redirected to use a policer in a named policer queue-group and the queue-group name does not exist, the association is failed at the time the user associates the ingress context of a spoke-sdp to the named queue-group. In such a case, the PW packet will feed directly the ingress network shared queue for that FC defined in the network-queue policy applied to the ingress of the MDA/FP.
  2. When a PW FC is redirected to use a policer in a named policer queue-group and the queue-group name exists but the policer-id is not defined in the queue-group template, the association is failed at the time the user associates the ingress context of a spoke-sdp to the named queue-group. In such a case, the PW packet will feed directly the ingress network shared queue for that FC defined in the network-queue policy applied to the ingress of the MDA/FP.
  3. When a PW FC is redirected to use a policer in a named policer queue-group and the queue-group name exists and the policer-id is defined in the queue-group template, it is not required to check that an instance of that queue-group exists in all ingress FPs that have network IP interfaces. The handling of this is dealt within the data path as follows:
    1. When a PW packet for that FC is received and an instance of the referenced queue-group name exists on that FP, the packet is processed by the policer and will then feed the per-FP ingress shared queues referred to as “policer-output-queues”.
    2. When a PW packet for that FC is received and an instance of the referenced queue-group name does not exist on that FP, the PW packets will be fed directly into the corresponding ingress network shared queue for that FC defined in the network-queue policy applied to the ingress of the MDA/FP.
  4. If a network QoS policy is applied to the ingress context of a PW, any PW FC that is not explicitly redirected in the network QoS policy will have the corresponding packets feed directly into the ingress network shared queue for that FC defined in the network-queue policy applied to the ingress of the MDA/FP.
  5. If no network QoS policy is applied to the ingress context of the PW, then all packets of the PW will feed:
    1. the ingress network shared queue for the packet’s FC defined in the network-queue policy applied to the ingress of the MDA/FP. This is the default behavior.
    2. a queue-group policer followed by the per-FP ingress shared queues, referred to as “policer-output-queues”, if the ingress context of the network IP interface from which the packet is received is redirected to a queue-group. The only exceptions to this behavior are for packets received from an IES/VPRN spoke interface and from an R-VPLS spoke-sdp that is forwarded to the R-VPLS IP interface. In these two cases, the ingress network shared queue for the packet’s FC defined in the network-queue policy applied to the ingress of the MDA/FP is used.

When a PW is redirected to use a policer queue-group, the classification of the packet for the purpose of FC and profile determination is performed according to the default classification rule or the QoS filters defined in the ingress context of the network QoS policy applied to the PW. This is true regardless if an instance of the named policer queue-group exists on the ingress FP the pseudowire packet is received on. The user can apply a QoS filter matching the dot1-p in the VLAN tag corresponding to the Ethernet port encapsulation, the EXP in the outer label when the tunnel is an LSP, the DSCP in the IP header if the tunnel encapsulation is GRE, and the DSCP in the payload’s IP header if the user enabled the ler-use-dscp option and the pseudowire terminates in IES or VPRN service (spoke-interface).

When the policer queue-group name the pseudowire is redirected does not exist, the redirection command is failed. In this case, the packet classification is performed according to the default classification rule or the QoS filters defined in the ingress context of the network QoS policy applied to the network IP interface the pseudowire packet is received on.

The no version of this command removes the redirection of the pseudowire to the queue-group.

Parameters 
network-policy-id—
Specifies the network policy identification on the system.
Values—
1to 65535
queue-group-name—
Specifies the name of the queue group template up to 32 characters in length.
instance-id—
Specifies the identification of a specific instance of the queue-group.
Values—
1to 16384

vc-label

Syntax 
[no] vc-label vc-label
Context 
config>service>fpipe>spoke-sdp>egress
config>service>apipe>spoke-sdp>egress
config>service>cpipe>spoke-sdp>egress
config>service>ipipe>spoke-sdp>egress
config>service>apipe>spoke-sdp>ingress
config>service>cpipe>spoke-sdp>ingress
config>service>fpipe>spoke-sdp>ingress
config>service>ipipe>spoke-sdp>ingress
Description 

This command configures the egress and ingress VC label.

Note that the actual maximum value that can be configured is limited by the config>router>mpls-labels>static-label-range command.

Parameters 
vc-label—
A VC egress value that indicates a specific connection.
Values—
for egress: 16 to 1048575
Values—
for ingress: 32 to 18431

monitor-oper-group

Syntax 
monitor-oper-group group-name
no monitor-oper-group
Context 
config>service>epipe>spoke-sdp
config>service>epipe>sap
Description 

This command specifies the operational group to be monitored by the object 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 no form of the command removes the association.

Default 

none

Parameters 
group-name—
Specifies an oper group name.

oper-group

Syntax 
oper-group group-name
no oper-group
Context 
config>service>epipe>sap
Description 

This command configures the operational group identifier.

The no form of the command removes the group name from the configuration.

Default 

none

Parameters 
group-name—
Specifies the Operational-Group identifier up to 32 characters in length.

precedence

Syntax 
precedence [precedence-value | primary]
no precedence
Context 
config>service>apipe>spoke-sdp
config>service>cpipe>spoke-sdp
config>service>fpipe>spoke-sdp
config>service>ipipe>spoke-sdp
config>service>epipe>spoke-sdp
Description 

This command specifies the precedence of the SDP binding when there are multiple SDP bindings attached to one service endpoint. The value of zero can only be assigned to one SDP bind making it the primary SDP bind. When an SDP binding goes down, the next highest precedence SDP binding will begin to forward traffic.

The no form of the command returns the precedence value to the default.

Default 

4

Parameters 
precedence-value—
Specifies the spoke SDP precedence.
Values—
1 to 4
primary—
Assigns primary precedence to the spoke SDP.

pw-status-signaling

Syntax 
[no] pw-status-signaling
Context 
config>service>epipe>spoke-sdp
Description 

This command enables pseudowire status signaling for this spoke SDP binding.

The no form of the command disables the status signaling.

Default 

pw-status-signaling

use-sdp-bmac

Syntax 
[no] use-sdp-bmac
Context 
config>service>epipe>spoke-sdp
Description 

This command indicates that this spoke-SDP is expected to be part of a redundant pseudowire connected to a PBB Epipe service. Enabling this parameter will cause traffic forwarded from this spoke-SDP into the B-VPLS domain to use a virtual backbone MAC as its source MAC address when both this, and the control pseudowire, are in the active state on this BEB. This virtual backbone MAC is derived from the SDP source-bmac-lsb configuration.

This command will fail when configuring it under a spoke-SDP within a PBB-Epipe that is connected to a B-VPLS with mac-notification enabled.

Default 

no use-sdp-bmac

vc-label

Syntax 
[no] vc-label vc-label
Context 
config>service>cpipe>spoke-sdp>egress
config>service>epipe>spoke-sdp>egress
config>service>cpipe>spoke-sdp>ingress
config>service>epipe>spoke-sdp>ingress
Description 

This command configures the egress and ingress VC label.

Note that the actual maximum value that can be configured is limited by the config>router>mpls-labels>static-label-range command.

Parameters 
vc-label—
A VC egress value that indicates a specific connection.
Values—
for egress: 16 to 1048575
Values—
for ingress: 32 to 18431

vlan-vc-tag

Syntax 
vlan-vc-tag 0 to 4094
no vlan-vc-tag [0 to 4094]
Context 
config>service>epipe>spoke-sdp
Description 

This command specifies an explicit dot1q value used when encapsulating to the SDP far end. When signaling is enabled between the near and far end, the configured dot1q tag can be overridden by a received TLV specifying the dot1q value expected by the far end. This signaled value must be stored as the remote signaled dot1q value for the binding. The provisioned local dot1q tag must be stored as the administrative dot1q value for the binding.

When the dot1q tag is not defined, the default value of zero is stored as the administrative dot1q value. Setting the value to zero is equivalent to not specifying the value.

The no form of this command disables the command.

Default 

no vlan-vc-tag

Parameters 
0 to 4094—
Specifies a valid VLAN identifier to bind an 802.1Q VLAN tag ID.
Values—
0 to 4094

spoke-sdp-fec

Syntax 
spoke-sdp-fec
spoke-sdp-fec spoke-sdp-fec-id [fec fec-type] [aii-type aii-type] [create]
spoke-sdp-fec spoke-sdp-fec-id no-endpoint
spoke-sdp-fec spoke-sdp-fec-id [fec fec-type] [aii-type aii-type] [create] endpoint name [icb]
Context 
config>service>epipe
Description 

This command binds a service to an existing Service Distribution Point (SDP), using a dynamic MS-PW.

A spoke SDP is treated like the equivalent of a traditional bridge “port” where flooded traffic received on the spoke SDP is replicated on all other “ports” (other spoke and mesh SDPs or SAPs) and not transmitted on the port it was received.

The SDP has an operational state which determines the operational state of the SDP within the service. For example, if the SDP is administratively or operationally down, the SDP for the service will be down.

When using dynamic MS-PWs, the particular SDP to bind-to is automatically selected based on the Target Attachment Individual Identifier (TAII) and the path to use, specified under spoke-SDP FEC. The selected SDP will terminate on the first hop S-PE of the MS-PW. Therefore, an SDP must already be defined in the config>service>sdp context that reaches the first hop router of the MS-PW. The router will in order to associate an SDP with a service. If an SDP to that is not already configured, an error message is generated. If the sdp-id does exist, a binding between that sdp-id and the service is created.

It differs from the spoke-sdp command in that the spoke-sdp command creates a spoke SDP binding that uses a pseudowire with the PW ID FEC. However, the spoke-sdp-fec command enables pseudowires with other FEC types to be used. In Release 9.0, only the Generalized ID FEC (FEC129) may be specified using this command.

The no form of this command removes the SDP binding from the service. The SDP configuration is not affected; only the binding of the SDP to a service. Once removed, no packets are forwarded to the far-end router.

Default 

none

Parameters 
spoke-sdp-fec-id —
An unsigned integer value identifying the spoke SDP.
Values—
1 to 4294967295
fec-type —
An unsigned integer value for the type of the FEC used by the MS-PW.
Values—
129 to 130
aii-type —
An unsigned integer value for the Attachment Individual Identifier (AII) type used to identify the MS-PW endpoints.
Values—
1 to 2
endpoint-name —
Specifies the name of the service endpoint.
no endpoint —
Adds or removes a spoke SDP association.
icb —
Configures the spoke-SDP as an inter-chassis backup SDP binding.

auto-config

Syntax 
[no] auto-config
Context 
config>service>epipe>spoke-sdp-fec
Description 

his command enables single sided automatic endpoint configuration of the spoke-SDP. The router acts as the passive T-PE for signaling this MS-PW.

Automatic Endpoint Configuration allows the configuration of a spoke-SDP endpoint without specifying the TAII associated with that spoke-SDP. It allows a single-sided provisioning model where an incoming label mapping message with a TAII that matches the SAII of that spoke-SDP to be automatically bound to that endpoint. In this mode, the far end T-PE actively initiates MS-PW signaling and will send the initial label mapping message using T-LDP, while the router T-PE for which auto-config is specified will act as the passive T-PE.

The auto-config command is blocked in CLI if signaling active has been enabled for this spoke-SDP. It it is only applicable to spoke SDPs configured under the Epipe, IES and VPRN interface context.

The no form of the command means that the router T-PE either acts as the active T-PE (if signaling active is configured) or automatically determines which router will initiate MS-PW signaling based on the prefix values configured in the SAII and TAII of the spoke-SDP. If the SAII has the greater prefix value, then the router will initiate MS-PW signaling without waiting for a label mapping message from the far end. However, if the TAII has the greater value prefix, then the router will assume that the far end T-PE will initiate MS-PW signaling and will wait for that label mapping message before responding with a T-LDP label mapping message for the MS-PW in the reverse direction.

Default 

no auto-config

path

Syntax 
path name
no path
Context 
config>service>epipe>spoke-sdp-fec
Description 

This command specifies the explicit path, containing a list of S-PE hops, that should be used for this spoke SDP. The path-name should correspond to the name of an explicit path configured in the config>service>pw-routing context.

If no path is configured, then each next-hop of the MS-PW used by the spoke-SDP will be chosen locally at each T-PE and S-PE.

Default 

no path

Parameters 
name —
The name of the explicit path to be used, as configured under config>service>pw-routing.

precedence

Syntax 
precedence prec-value
precedence primary
no precedence
Context 
config>service>epipe>spoke-sdp-fec
Description 

This command specifies the precedence of the SDP binding when there are multiple SDP bindings attached to one service endpoint. The value of zero can only be assigned to one SDP bind making it the primary SDP bind. When an SDP binding goes down, the next highest precedence SDP binding will begin to forward traffic.

The no form of the command returns the precedence value to the default.

Default 

42

Parameters 
prec-value —
Specifies the spoke SDP precedence.
Values—
1 to 4
primary—
Assigns primary precedence to this spoke SDP.

pw-template-bind

Syntax 
pw-template-bind policy-id
no pw-template-bind
Context 
config>service>epipe>spoke-sdp-fec
Description 

This command binds includes the parameters included in a specific PW Template to a spoke SDP.

The no form of the command removes the values from the configuration.

Default 

none

Parameters 
policy-id—
Specifies the existing policy ID.
Values—
1 to 2147483647

retry-count

Syntax 
retry-count retry-count
no retry-count
Context 
config>service>epipe>spoke-sdp-fec
Description 

This optional command specifies the number of attempts software should make to re-establish the spoke-SDP after it has failed. After each successful attempt, the counter is reset to zero.

When the specified number is reached, no more attempts are made and the spoke-sdp is put into the shutdown state.

Use the no shutdown command to bring up the path after the retry limit is exceeded.

The no form of this command reverts the parameter to the default value.

Default 

30

Parameters 
retry-count—
The maximum number of retries before putting the spoke-sdp into the shutdown state.
Values—
10 to 10000

retry-timer

Syntax 
retry-timer retry-timer
no retry-timer
Context 
config>service>epipe>spoke-sdp-fec
Description 

This command specifies a retry-timer for the spoke-SDP. This is a configurable exponential back-off timer that determines the interval between retries to re-establish a spoke-SDP if it fails and a label withdraw message is received with the status code “AII unreachable”.

The no form of this command reverts the timer to its default value.

Default 

30

Parameters 
retry-timer—
The initial retry-timer value in seconds.
Values—
10 to 480

saii-type2

Syntax 
saii-type2 global-id:prefix:ac-id
no saii-type2
Context 
config>service>epipe>spoke-sdp-fec
Description 

This command configures the source attachment individual identifier for the spoke-sdp. This is only applicable to FEC129 AII type 2.

Parameters 
global-id —
A Global ID of this router T-PE. This value must correspond to one of the global_id values configured for a local-prefix under config>service>pw-routing>local-prefix context.
Values—
1 to 4294967295
prefix —
The prefix on this router T-PE that the spoke-sdp SDP is associated with.This value must correspond to one of the prefixes configured under config>service>pw-routing>local-prefix context.
Values—
an IPv4-formatted address a.b.c.d or 1 to 4294967295
ac-id —
An unsigned integer representing a locally unique identifier for the spoke-SDP.
Values—
1 to 4294967295

signaling

Syntax 
signaling signaling
Context 
config>service>epipe>spoke-sdp-fec
Description 

This command enables a user to configure this router as the active pr passive T-PE for signaling this MS-PW, or to automatically select whether this T-PE is active or passive based on the prefix. In an active role, this endpoint initiates MS-PW signaling without waiting for a T-LDP label mapping message to arrive from the far end T-PE. In a passive role, it will wait for the initial label mapping message from the far end before sending a label mapping for this end of the PW. In auto mode, if the SAII has the greater prefix value, then the router will initiate MS-PW signaling without waiting for a label mapping message from the far end. However, if the TAII has the greater value prefix, then the router will assume that the far end T-PE will initiate MS-PW signaling and will wait for that label mapping message before responding with a T-LDP label mapping message for the MS-PW in the reverse direction.

The no form of the command means that the router T-PE automatically selects the which router will initiate MS-PW signaling based on the prefix values configured in the SAII and TAII of the spoke-SDP, as described above.

Default 

auto

Parameters 
signaling —
Configures this router as the active T-PE for signaling this MS-PW.
Values—
auto, master

standby-signaling-slave

Syntax 
[no] standby-signaling-slave
Context 
config>service>epipe>spoke-sdp-fec
Description 

This command enables standby-signaling-slave for an Epipe.

taii-type2

Syntax 
taii-type2 global-id:prefix:ac-id
no taii-type2
Context 
config>service>epipe>spoke-sdp-fec
Description 

taii-type2 configures the target attachment individual identifier for the spoke-sdp. This is only applicable to FEC129 AII type 2.

This command is blocked in CLI if this end of the spoke-SDP is configured for single-sided auto configuration (using the auto-config command).

Parameters 
global-id —
A Global ID of this router T-PE. This value must correspond to one of the global_id values configured for a local-prefix under config>service>pw-routing>local-prefix context.
Values—
1 to 4294967295
prefix —
The prefix on this router T-PE that the spoke-sdp SDP is associated with.This value must correspond to one of the prefixes configured under config>service>pw-routing>local-prefix context.
Values—
an IPv4-formatted address a.b.c.d or 1 to 4294967295
ac-id —
An unsigned integer representing a locally unique identifier for the spoke-SDP.
Values—
1 to 4294967295

ATM Commands

atm

Syntax 
atm
Context 
config>service>epipe>sap
config>service>apipe>sap
config>service>ipipe>sap
config>service>epipe>sap
Description 

This command enables access to the context to configure ATM-related attributes.This command can only be used when a given context (for example, a channel or SAP) supports ATM functionality such as:

  1. Configuring ATM port or ATM port-related functionality on MDAs supporting ATM functionality
  2. Configuring ATM-related configuration for ATM-based SAPs that exist on MDAs supporting ATM functionality.

If ATM functionality is not supported for a given context, the command returns an error.

egress

Syntax 
egress
Context 
config>service>epipe>sap
config>service>epipe>sap>atm
config>service>apipe>sap>atm
config>service>fpipe>sap
Description 

This command configures egress ATM attributes for the SAP.

ingress

Syntax 
ingress
Context 
config>service>epipe>sap
config>service>epipe>sap>atm
config>service>epipe>sap
config>service>apipe>sap>atm
Description 

This command configures ingress ATM attributes for the SAP.

encapsulation

Syntax 
encapsulation atm-encap-type
Context 
config>service>epipe>sap>atm
Description 

This command specifies the data encapsulation for an ATM PVCC delimited Epipe SAP. The definition references RFC 2684, Multiprotocol Encapsulation over ATM AAL5, and to the ATM Forum LAN Emulation specification. Ingress traffic that does not match the configured encapsulation will be dropped.

Default 

aal5snap-bridged

Parameters 
atm-encap-type—
Specify the encapsulation type.
Values—
aal5snap-bridged — Bridged encapsulation for LLC encapsulated circuit (LLC/SNAP precedes protocol datagram) as defined in RFC 2684.
aal5mux-bridged-eth-nofcs — Bridged IP encapsulation for VC multiplexed circuit as defined in RFC 2684

encapsulation

Syntax 
encapsulation atm-encap-type
Context 
config>service>ipipe>sap>atm
Description 

This command specifies the data encapsulation for an ATM PVCC delimited Ipipe SAP. The definition references RFC 2684, Multiprotocol Encapsulation over ATM AAL5, and to the ATM Forum LAN Emulation specification. Ingress traffic that does not match the configured encapsulation will be dropped.

Default 

aal5snap-routed

Parameters 
atm-encap-type—
Specify the encapsulation type.
Values—
aal5snap-routed — Routed encapsulation for LLC encapsulated circuit (LLC/SNAP precedes protocol datagram) as defined in RFC 2684.
aal5mux-ip — Routed IP encapsulation for VC multiplexed circuit as defined in RFC 2684

traffic-desc

Syntax 
traffic-desc traffic-desc-profile-id
no traffic-desc
Context 
config>service>epipe>sap
config>service>apipe>sap>atm>egress
config>service>apipe>sap>atm>ingress
config>service>epipe>sap>atm>egress
config>service>epipe>sap>atm>ingress
Description 

This command assigns an ATM traffic descriptor profile to a given context (for example, a SAP).

When configured under the ingress context, the specified traffic descriptor profile defines the traffic contract in the forward direction. When configured under the egress context, the specified traffic descriptor profile defines the traffic contract in the backward direction.

The no form of the command reverts the traffic descriptor to the default traffic descriptor profile.

Default 

The default traffic descriptor (trafficDescProfileId. = 1) is associated with newly created PVCC-delimited SAPs.

Parameters 
traffic-desc-profile-id—
Specify a defined traffic descriptor profile (see the QoS atm-td-profile command).

OAM Commands

oam

Syntax 
oam
Context 
config>service>epipe>sap
config>service>apipe>sap>atm
Description 

This command enables the context to configure OAM functionality for a PVCC delimiting a SAP.

  1. The ATM-capable MDAs support end-to-end and segment OAM functionality (AIS, RDI, Loopback) over both F5 (VC) and end-to-end F4 (VP) OAM:
  2. ITU-T Recommendation I.610 - B-ISDN Operation and Maintenance version 11/95
  3. GR-1248-CORE - Generic Requirements for Operations of ATM N3 June 1996
  4. GR-1113-CORE - Bellcore, Asynchronous Transfer Mode (ATM) (AAL) Protocols Generic Requirements, Issue 1, July 1994

alarm-cells

Syntax 
[no] alarm-cells
Context 
config>service>epipe>sap>oam
config>service>epipe>sap>oam
config>service>apipe>sap>atm>oam
Description 

This command configures AIS/RDI fault management on a PVCC. Fault management allows PVCC terminations to monitor and report the status of their connection by propagating fault information through the network and by driving PVCC’s operational status.

When alarm-cells functionality is enabled, a PVCC’s operational status is affected when a PVCC goes into an AIS or RDI state because of an AIS/RDI processing (assuming nothing else affects PVCC’s operational status, for example, if the PVCC goes DOWN, or enters a fault state and comes back UP, or exits that fault state). RDI cells are generated when PVCC is operationally DOWN. No OAM-specific SNMP trap is raised whenever an endpoint enters/exits an AIS or RDI state, however, if as result of an OAM state change, the PVCC changes operational status, then a trap is expected from an entity the PVCC is associated with (for example a SAP).

The no command disables alarm-cells functionality for a PVCC. When alarm-cells functionality is disabled, a PVCC’s operational status is no longer affected by a PVCC’s OAM state changes due to AIS/RDI processing (Note that when alarm-cells is disabled, a PVCC will change operational status to UP due to alarm-cell processing) and RDI cells are not generated as result of the PVCC going into AIS or RDI state. The PVCC’s OAM status, however, will record OAM faults as described above.

Default 

Enabled for PVCCs delimiting IES SAPs

terminate

Syntax 
[no] terminate
Context 
config>service>apipe>sap>atm>oam
Description 

This command specifies whether this SAP will act as an OAM termination point. ATM SAPs can be configured to tunnel or terminate OAM cells.

When configured to not terminate (the default is no terminate), the SAP will pass OAM cells through the VLL without inspecting them. The SAP will respond to OAM loopback requests that are directed to the local node by transmitting a loopback reply. Other loopback requests are transparently tunneled through the pseudowire. In this mode, it is possible to launch a loopback request towards the directly-attached ATM equipment and see the results of the reply.

When configured to terminate, the SAP will respond to AIS by transmitting RDI and will signal the change of operational status to the other endpoint (for example, through LDP status notifications). The SAP will respond to OAM loopback requests by transmitting a loopback reply. In this mode, it is possible to launch a loopback request towards the directly-attached ATM equipment and see the results of the reply.

For Apipe services, the user has the option of enabling or disabling this option for VC types atm-vcc and atm-sdu since these service types maintain the ATM layer and/or the AAL5 layer across the VLL. It is not supported on atm-vpc and atm-cell apipe vc types since the VLL must pass the VC level (F5) OAM cells.

The terminate option for OAM is the only and default mode of operation supported for an ATM SAP which is part of Epipe, Ipipe, VPLS, and IES/VPRN. This is because the ATM and AAL5 layers are terminated.

For Apipe services, the user has the option of enabling or disabling this option for vc types atm-vcc and atm-sdu since these service types maintain the ATM layer and/or the AAL5 layer across the VLL. It is not supported on atm-vpc and atm-cell Apipe vc types since the VLL must pass the VC level (F5).

The terminate option for OAM is the only and default mode of operation supported for an ATM SAP which is part of Epipe, Ipipe, VPLS, and IES/VPRN. This is because the ATM and AAL5 layers are terminated.

Default 

no terminate

Cpipe Commands

endpoint

Syntax 
[no] endpoint endpoint-name
Context 
config>service>cpipe
Description 

This command configures a service endpoint.

Parameters 
endpoint-name—
Specifies an endpoint name.

active-hold-delay

Syntax 
active-hold-delay active-hold-delay
no active-hold-delay
Context 
config>service>cpipe>endpoint
Description 

This command specifies that the node will delay sending the change in the T-LDP status bits for the service endpoint when the MC-LAG transitions the LAG subgroup which hosts the SAP for this VLL endpoint from “active” to “standby” or when any object in the endpoint. For example., SAP, ICB, or regular spoke SDP, transitions from up to down operational state.

By default, when the MC-LAG transitioned the LAG subgroup which hosts the SAP for this VLL endpoint from “active” to “standby”, the node sends immediately new T-LDP status bits indicating the new value of “standby” over the spoke SDPs which are on the mate-endpoint of the VLL. The same applies when any object in the endpoint changes an operational state from up to down.

There is no delay applied to the VLL endpoint status bit advertisement when the MC-LAG transitions the LAG subgroup which hosts the SAP from “standby” to “active” or when any object in the endpoint transitions to an operationally up state.

Default 

0 — A value of zero means that when the MC-LAG transitioned the LAG subgroup which hosts the SAP for this VLL endpoint from “active” to “standby”, the node sends immediately new T-LDP status bits indicating the new value of “standby” over the spoke SDPs which are on the mate-endpoint of the VLL. The same applies when any object in the endpoint changes an operational state from up to down.

Parameters 
active-hold-delay—
Specifies the active hold delay in 100s of milliseconds.
Values—
0 to 60

revert-time

Syntax 
revert-time revert-time
revert-time infinite
no revert-time
Context 
config>service>cpipe>endpoint
Description 

This command configures the time to wait before reverting back to the primary spoke SDP defined on this service endpoint, after having failed over to a backup spoke SDP.

Parameters 
revert-time—
Specify the time, in seconds, to wait before reverting to the primary SDP.
Values—
0 to 600
infinite—
Causes the endpoint to be non-revertive.

VLL SAP Commands

sap

Syntax 
sap sap-id [no-endpoint] [create]
sap sap-id endpoint endpoint-name [create]
no sap sap-id
Context 
config>service>cpipe
Description 

This command creates a Service Access Point (SAP) within a service. A SAP is a combination of port and encapsulation parameters which identifies the service access point on the interface and within the service router. Each SAP must be unique.

All SAPs must be explicitly created. If no SAPs are created within a service or on an IP interface, a SAP will not exist on that object.

Enter an existing SAP without the create keyword to edit SAP parameters. The SAP is owned by the service in which it was created.

A SAP can only be associated with a single service. A SAP can only be defined on a port that has been configured as an access port using the config router interface port-type port-id mode access command. Channelized TDM ports are always access ports.

If a port is shutdown, all SAPs on that port become operationally down. When a service is shutdown, SAPs for the service are not displayed as operationally down although all traffic traversing the service will be discarded.

The operational state of a SAP is relative to the operational state of the port on which the SAP is defined.

The no form of this command deletes the SAP with the specified port. When a SAP is deleted, all configuration parameters for the SAP will also be deleted.

Default 

No SAPs are defined.

Special Cases 
VLL Services—
A SAP can be defined with Ethernet ports, SONET/SDH or TDM channels. At most, only one sdp-id can be bound to an VLL service. Since a VLL is a point-to-point service, it can have, at most, two end points. The two end points can be one SAP and one SDP or two SAPs. Up to 49 SDPs can be associated with a service in a single router. Each SDP must have a unique router destination or an error will be generated.

A default SAP has the following format: port-id:*. This type of SAP is supported only on Ethernet MDAs and its creation is allowed only in the scope of Layer 2 services. This type of SAP is mutually exclusive with a SAP defined by explicit null encapsulation (for example, 1/1/1:0).

Parameters 
sap-id—
Specifies the physical port identifier portion of the SAP definition.
port-id—
Specifies the physical port ID.

If the card in the slot has Media Dependent Adapters (MDAs) installed, the port-id must be in the slot_number/MDA_number/port_number format. For example 61/2/3 specifies port 3 on MDA 2 in slot 61.

The port-id must reference a valid port type. When the port-id parameter represents SONET/SDH and TDM channels, the port ID must include the channel ID. A period “.” separates the physical port from the channel-id. The port must be configured as an access port.

If the SONET/SDH port is configured as clear-channel then only the port is specified.

port-id

slot/mda/port [.channel]

eth-sat-id

esat-id/slot/port

esat

keyword

id

1 to 20

pxc-id

pxc-id.sub-port

pxc

keyword

id

1 to 64

sub-port

a, b

endpoint—
Adds a SAP endpoint association.
no endpoint—
Removes the association of a SAP or a spoke-sdp with an explicit endpoint name.
create—
Keyword used to create a SAP instance. The create keyword requirement can be enabled/disabled in the environment>create context.

cem

Syntax 
cem
Context 
config>service>cpipe>sap
Description 

This command enables the context to specify circuit emulation (CEM) properties.

packet

Syntax 
packet jitter-buffer milliseconds [payload-size bytes]
packet payload-size bytes
no packet
Context 
config>service>cpipe>sap
Description 

This command specifies the jitter buffer size, in milliseconds, and payload size, in bytes.

Default 

The default value depends on the CEM SAP endpoint type, and if applicable, the number of timeslots.

Table 19:  Default CEM SAP Endpoint Types 

Endpoint Type

Timeslots

Default Jitter Buffer (in ms)

unstructuredE1

n/a

5

unstructuredT1

n/a

5

nxDS0 (E1/T1)

N = 1

32

N = 2 to 4

16

N = 5 to 15

8

N >= 16

5

nxDS0WithCas (E1)

N

8

nxDS0WithCas (T1)

N

12

Parameters 
milliseconds—
specifies the jitter buffer size in milliseconds (ms).

Configuring the payload size and jitter buffer to values that result in less than 2 packet buffers or greater than 32 packet buffers is not allowed.

Setting the jitter butter value to 0 sets it back to the default value.

Values—
1 to 250
payload-size bytes
Specifies the payload size (in bytes) of packets transmitted to the packet service network (PSN) by the CEM SAP. This determines the size of the data that will be transmitted over the service. If the size of the data received is not consistent with the payload size, then the packet is considered malformed.
Values—
0, 16 to 2048
Values—
The default value depends on the CEM SAP endpoint type, and if applicable, the number of timeslots.
Table 20:  Payload Size CEM SAP Endpoint Types 

Endpoint Type

Timeslots

Default Payload Size (in bytes) 

unstructuredE1

n/a

256

unstructuredT1

n/a

192

nxDS0 (E1/T1)

N = 1

64

N = 2 to 4

N x 32

N = 5 to 15

N x 16

N >= 16

N x 8

nxDS0WithCas (E1)

N

N x 16

nxDS0WithCas (T1)

N

N x 24

For all endpoint types except for nxDS0WithCas, the valid payload size range is from the default to 2048 bytes.
For nxDS0WithCas, the payload size divide by the number of timeslots must be an integer factor of the number of frames per trunk multi-frame (for example, 16 for E1 trunk and 24 for T1 trunk).
For 1xDS0, the payload size must be a multiple of 2.
For NxDS0, where N > 1, the payload size must be a multiple of the number of timeslots.
For unstructuredE1 and unstructuredT1, the payload size must be a multiple of 32 bytes.
Configuring the payload size and jitter buffer to values that result in less than 2 packet buffers or greater than 32 packet buffer is not allowed.
Setting the payload size to 0 sets it back to the default value.

report-alarm

Syntax 
[no] report-alarm [stray] [malformed] [pktloss] [overrun] [underrun] [rpktloss] [rfault] [rrdi]
Context 
config>service>cpipe>sap>cem
Description 

This command indicates the type of CEM SAP alarm.

The no form of the command removes the parameter from the configuration.

Parameters 
stray—
Reports the reception of packets not destined for this CES circuit.
malformed—
Reports the reception of packet not properly formatted as CES packets.
pktloss—
Reports the lack of reception of CES packets.
overrun—
Reports the reception of too many CES packets resulting in a overrun of the receive jitter buffer.
underrun—
Reports the reception of too few CES packets resulting in a overrun of the receive jitter buffer.
rpktloss—
Reports hat the remote peer is currently in packet loss status.
rfault—
Reports that the remote TDM interface is currently not in service.
rrdi—
Reports that the remote TDM interface is currently in RDI status.

rtp-header

Syntax 
[no] rtp-header
Context 
config>service>cpipe>sap>cem
Description 

This command specifies whether an RTP header is used when packets are transmitted to the packet service network (PSN) by the CEM SAP.

Default 

no rtp-header

CPipe SDP Commands

spoke-sdp

Syntax 
spoke-sdp sdp-id[:vc-id] [no-endpoint] [create]
spoke-sdp sdp-id:vc-id [create] endpoint endpoint-name [icb]
no spoke-sdp sdp-id[:vc-id]
Context 
config>service>cpipe
Description 

This command binds a service to an existing Service Distribution Point (SDP). A spoke SDP is treated like the equivalent of a traditional bridge “port” where flooded traffic received on the spoke SDP is replicated on all other “ports” (other spoke and mesh SDPs or SAPs) and not transmitted on the port it was received.

The SDP has an operational state which determines the operational state of the SDP within the service. For example, if the SDP is administratively or operationally down, the SDP for the service will be down.

The SDP must already be defined in the config>service>sdp context. If the sdp sdp-id is not already configured, an error message is generated. If the sdp-id does exist, a binding between that sdp-id and the service is created. SDPs must be explicitly associated and bound to a service. If an SDP is not bound to a service, no far-end devices can participate in the service.

The no form of this command removes the SDP binding from the service. The SDP configuration is not affected; only the binding of the SDP to a service. Once removed, no packets are forwarded to the far-end router.

Default 

No sdp-id is bound to a service.

Parameters 
sdp-id—
The SDP identifier. Allowed values are integers in the range of 1 to 17407 for existing SDPs.
vc-id—
The virtual circuit identifier.
Values—
1 to 4294967295
vc-type—
This command overrides the default VC type signaled for the spoke or mesh binding to the far end of the SDP. The VC type is a 15 bit-quantity containing a value which represents the type of VC. The actual signaling of the VC type depends on the signaling parameter defined for the SDP. If signaling is disabled, the vc-type command can still be used to define the dot1q value expected by the far-end provider equipment. A change of the bindings VC type causes the binding to signal the new VC type to the far end when signaling is enabled.

VC types are derived according to IETF draft-martini-l2circuit-trans-mpls.

The VC type value for Ethernet is 0x0005.

The VC type value for an Ethernet VLAN is 0x0004.

The VC type value for a VPLS service is defined as 0x000B.

Values—
ethernet
no endpoint—
removes the association of a spoke SDP with an explicit endpoint name.
endpoint-name—
Specifies the name of the service endpoint.
icb—
Configures the spoke SDP as an inter-chassis backup SDP binding.

egress

Syntax 
egress
Context 
config>service>cpipe>spoke-sdp
Description 

This command enables the context to configure egress spoke-SDP context.

ingress

Syntax 
ingress
Context 
config>service>cpipe>spoke-sdp
Description 

This command enables the context to configure ingress spoke-SDP context.

vc-label

Syntax 
vc-label egress-vc-label
no vc-label [egress-vc-label]
Context 
config>service>cpipe>spoke-sdp>egress
config>service>cpipe>spoke-sdp>ingress
Description 

This command configures the spoke-SDP egress and ingress VC label.

Note that the actual maximum value that can be configured is limited by the config>router>mpls-labels>static-label-range command.

Parameters 
egress-vc-label—
A VC egress value that indicates a specific connection.
Values—
for egress: 16 to 1048575
Values—
for ingress: 32 to 18431

precedence

Syntax 
precedence [precedence-value | primary]
no precedence
Context 
config>service>cpipe>spoke-sdp
Description 

This command specifies the precedence of the SDP binding when there are multiple SDP bindings attached to one service endpoint. The value of zero can only be assigned to one SDP bind making it the primary SDP bind. When an SDP binding goes down, the next highest precedence SDP binding will begin to forward traffic.

The no form of the command returns the precedence value to the default.

Default 

4

Parameters 
precedence-value—
Specifies the spoke SDP precedence.
Values—
1 to 4
primary—
Specifies to make this the primary spoke SDP.

Epipe SAP Template Commands

template

Syntax 
template
Context 
config>service
Description 

This is the node for service templates.

epipe-sap-template

Syntax 
epipe-sap-template name [create]
no epipe-sap-template name
Context 
config>service>template
Description 

This command specifies which SAP parameter template should be applied to the l2-ap SAP. This can only be changed when the l2-ap is shutdown.

The no form of the command removes the template, the SAP will use default parameters.

Default 

None

Parameters 
name—
Specifies the SAP template name associated with this template.

egress

Syntax 
egress
Context 
config>service>template
Description 

This command enables the context to configure egress filter policies.

ingress

Syntax 
ingress
Context 
config>service>template>epipe-sap-template
Description 

This command enables the context to configure ingress SAP Quality of Service (QoS) policies and filter policies.

filter

Syntax 
[no] filter
Context 
config>service>template>epipe-sap-template>egress
config>service>template>epipe-sap-template>ingress
Description 

This command enables the context to configure filter parameters.

ip

Syntax 
ip filter-id
no ip
Context 
config>service>template>epipe-sap-template>egress>filter
config>service>template>epipe-sap-template>ingress>filter
Description 

This command associates an existing IP filter policy with the template.

Parameters 
filter-id—
Specifies the IP filter policy ID. The filter ID must already exist within the created IP filters.
Values—
1 to 65535

ipv6

Syntax 
ipv6 filter-id
no ipv6
Context 
config>service>template>epipe-sap-template>egress>filter
config>service>template>epipe-sap-template>ingress>filter
Description 

This command associates an existing IPv6 filter policy with the template.

Parameters 
ipv6-filter-id—
Specifies the IPv6 filter policy. The filter ID must already exist within the created IPv6 filters.
Values—
1 to 65535

mac

Syntax 
mac filter-id
no mac
Context 
config>service>template>epipe-sap-template>egress>filter
config>service>template>epipe-sap-template>ingress>filter
Description 

This command associates an existing MAC filter policy with the template.

Parameters 
mac-filter-id—
Specifies the MAC filter policy. The specified filter ID must already exist within the created MAC filters. The filter policy must already exist within the created MAC filters.
Values—
1 to 65535

qos

Syntax 
qos policy-id
no qos
Context 
config>service>template>epipe-sap-template>egress
Description 

This command associates an existing QoS policy with the template.

Parameters 
policy-id—
The egress policy ID to associate with SAP or IP interface on egress. The policy ID must already exist.
Values—
1 to 65535, or a name up to 64 characters in length

qos

Syntax 
qos policy-id {shared-queuing | multipoint-shared}
qos policy-id
no qos
Context 
config>service>template>epipe-sap-template>ingress
Description 

This command associates a Quality of Service (QoS) policy with an ingress Service Access Point (SAP) for the Epipe SAP template.

Default 

none

Parameters 
policy-id—
The ingress policy ID to associate with SAP or IP interface on ingress. The policy ID must already exist.
Values—
1 to 65535
shared-queuing—
This keyword can only be specified on SAP ingress. Specify the ingress shared queue policy used by this SAP. When the value of this object is null, the SAP will use individual ingress QoS queues, instead of the shared ones.
multipoint-shared—
This keyword can only be specified on SAP ingress. Multipoint shared queuing is a superset of shared queuing. When multipoint shared queuing keyword is set, in addition to the unicast packets, multipoint packets also used shared queues.

Ingress unicast service queues are mapped one-for-one with hardware queues and unicast packets traverse the ingress forwarding plane twice, similar to the shared-queuing option. In addition, the multipoint queues defined in the ingress SAP QoS policy are not created. Instead, multipoint packets (broadcast, multicast and unknown unicast destined) are treated to the same dual pass ingress forwarding plane processing as unicast packets.

When the value of this object is null, the SAP will use individual ingress QoS queues, instead of the shared ones.

When the value of this object is null, the SAP will use individual ingress QoS queues, instead of the shared ones.

Values—
Multipoint or not present.
Values—
Present (the queue is created as non-multipoint).