Cisco CBR8 Configuration Guide 17.6.x

Cisco cBR Converged Broadband Routers DOCSIS Software
Configuration Guide for Cisco IOS XE Bengaluru 17.6.x

First Published: 2021-08-16
Americas Headquarters
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134-1706
USA
http://www.cisco.com
Tel: 408 526-4000
800 553-NETS (6387)
Fax: 408 527-0883
© 2021 Cisco Systems, Inc. All rights reserved.
CONTENTS
PART I Basic Configuration 77
CHAPTER 1 Start Up Configuration of the Cisco cBR Router 1
Prerequisites for Configuring the Cisco CMTS 2

Booting and Logging onto the Cisco CMTS 3
First Time Boot Up with ROMMON 3

Configuration Register 4
Setting Environment Variables 5
Unsetting Environment Variables 5
Booting from the TFTP on the Cisco cBR 6
Listing Supported Devices 6
Booting from the Device on the Cisco cBR 7
Setting AUTOBOOT image in ROMMON 7
Verifying the ROMMON Version 8
Resetting the Cisco cBR 8
Configuring PTP 9
Overview of PTP 9
Configure PTP Subordinate Through DPIC 11

Configure Cisco cBR as PTP Subordinate 12
Verifying PTP Subordinate Configuration 13
PTP Subordinate Configuration Examples 13
Feature Information for PTP Subordinate 15
File Systems 15
Verification of Hardware Bring Up 16
Monitoring the Cisco cBR Chassis Using CLI 16
Gigabit Ethernet Management Interface Overview 24
Cisco cBR Converged Broadband Routers DOCSIS Software Configuration Guide for Cisco IOS XE Bengaluru 17.6.x
iii
Contents
Gigabit Ethernet Port Numbering 24

IP Address Handling in ROMMON and the Management Ethernet Port 24
Gigabit Ethernet Management Interface VRF 25
Common Ethernet Management Tasks 25
Viewing the VRF Configuration 25
Setting a Default Route in the Management Ethernet Interface VRF 26
Setting the Management Ethernet IP Address 26
Telnetting over the Management Ethernet Interface 26
Pinging over the Management Ethernet Interface 26
Copy Using TFTP or FTP 27
NTP Server 27
SYSLOG Server 27
SNMP-Related Services 27
Domain Name Assignment 27
DNS service 28
RADIUS or TACACS+ Server 28
VTY lines with ACL 28
Configuring the AUX Port for Network Management 28
Preprovisioning the Supervisor in the Cisco cBR Chassis 29

Configuring the Gigabit Ethernet Interface for Network Management 29
Configuring the DTI Port on the Supervisor PIC 30
Configuring the TenGigabit Ethernet Interface for Network Management 31
Connecting the New Router to the Network 32
Setting Password Protection on the Cisco CMTS 33

Recovering Lost Password on the Cisco CMTS 33
Saving Your Configuration Settings 35
Reviewing Your Settings and Configurations 36
Recovering Unresponsive Modems 36
CHAPTER 2 Cisco Smart Licensing 37
Hardware Compatibility Matrix for the Cisco cBR Series Routers 37

Prerequisites for Cisco Smart Licensing 38
Information About Cisco Smart Licensing 39
Downstream License 40
iv
Contents
Out of Compliance Enforcement 40

How to Configure Cisco Smart Licensing 41
Using Cisco Smart Licensing Agent on the Router 41
Setting Up a Cisco Smart Account 41
Creating Virtual Accounts 48
Creating a Product Instance Registration Token 49
Registering the Router with the Cisco Licensing Cloud Using the Registration Token 50
Re-establishing Connectivity to Cisco Smart Call Home Server 51
How to Configure Cisco Smart Licensing using Transport Gateway Solution 51
Configuring 100G Licenses for Supervisor 250G 53
Overview of 100G License for Supervisor 250G 53
Applying 10G WAN License to the 100G WAN Ports 53
Displaying the License Information 54
Feature Information for 100G License for Supervisor 250G 57
Verifying Cisco Smart Licensing Configuration 58
Troubleshooting Cisco Smart Licensing 64
Manually Renewing the Smart License Registration 64
Unregistering the Router from Cisco Smart Licensing 65
Additional References 65
Feature Information for Cisco Smart Licensing 65
CHAPTER 3 Core Peak Bandwidth Licensing 67
Core Peak Bandwidth License 67

CPB Calculation 67
Configure CPB on Cisco cBR Routers 68
Enable CPB Licensing 68
View CPB Usage Details 68
Example: Show CPB Usage Details 68
View Details of All Licenses 68
Example: View Details of All Licenses 68
View CPB Sample History 69
Example: View CPB Sample History 69
Feature Information for Core Peak Bandwidth Licensing 69
v
Contents
CHAPTER 4 Capped License Enforcement 71

Information About Capped License Support 73
SNMP-MIB-based Capped Enforcement 73
Use Case Scenarios 73
How to Configure Capped License Enforcement 74
Configuring Capped License Enforcement 74
Viewing the License Usage Count 74
Configuration Examples 74
Feature Information for Capped License Enforcement 75
CHAPTER 5 Consolidated Packages and SubPackages Management 77
Finding Feature Information 77

Running the Cisco cBR Series Routers Using Individual and Optional SubPackages: An Overview 77
Running the Cisco cBR Series Routers Using a Consolidated Package: An Overview 78
Running the Cisco cBR Series Routers: A Summary 78
Software File Management Using Command Sets 79
Managing and Configuring the Router to Run Using Consolidated Packages and Individual
SubPackages 80
Cable Line Card Process Restart 81
Cable Line Card Control Plane Process Restart 81
Cable Line Card Upstream Scheduler Process Restart 87
Quick Start Software Upgrade 93
Managing and Configuring a Consolidated Package Using the copy Command 94
Managing and Configuring a Router to Run Using Individual SubPackages From a Consolidated
Package 95
Extracting a Consolidated Package and Booting Using the Provisioning File 95
Copying a Set of Individual SubPackage Files, and Booting Using a Provisioning File 98
Installing an Optional SubPackage 98
Upgrading Individual SubPackages 100

Patch Installation 100
Installing a Patch that Affects Both Line Card and Supervisor Card 100
Installing a Patch that Affects Only Line Cards 100
vi
Contents
Installing a Patch that Affects Only Supervisor Cards 101
Upgrading a Line Card SubPackage 101

Feature Information for Consolidated Packages and SubPackages Management 108
CHAPTER 6 Support for 2x100G DPIC 109
Information About Cisco cBR 2x100G DPIC 111
Limitations on Downstream Bandwidth 111
Support for Link Redundancy 112
How to Configure 2x100G DPIC 113
View 2x100G DPIC Details 113
Configure 2x100G DPIC Mode 113
Verify 2x100G DPIC Mode 113
Verify 2x100G Ethernet Interface Status 113
Switch Between 8x10G and 2x100G Modes 114
Configure RPD 115
Configure Link Redundancy 115
Feature Information for 2x100G DPIC Support 115
CHAPTER 7 G.8275.2 Telecom Profile 117
G.8275.2 Telecom Profile 117

Information About G.8275.2 Telecom Profile 117
Why G.8275.2 Telecom Profile? 118
PTP Clocks 118
PTP Domain 118
PTP Messages and Transport 119
PTP Ports 119
Alternate BPCA 119
Benefits 119
Restrictions for Using the G.8275.2 Profile 119
How to Configure the G.8275.2 Profile 120
Creating an Ordinary Subordinate (T-TSC-P) 120
Configuring Dual PTP Primary Clocks 120
vii
Contents
Configuring the G.8275.2 Profiles 120

Configuring an IPv4 Single Clock Source 121
Configuring an IPv6 Single Clock Source 121
Verifying the G.8275.2 Profile 121
DPIC PTP Primary 122
Configuring DPIC PTP Primary 122
Verifying the DPIC PTP Primary 124
Feature Information for G.8275.2 Profile 128
CHAPTER 8 Model-Driven Telemetry 129
Information About Model-Driven Telemetry 131
Restrictions for Model Driven Telemetry 131
Prerequisites to Enable Telemetry 132
Configuring Telemetry 132
Configuring Telemetry using gRPC 132
Configuring Telemetry using NETCONF 134

Feature Information for Model-Driven Telemetry 135
PART II High Availability Configuration 137
CHAPTER 9 Cisco IOS-XE In-Service Software Upgrade Process 139
Information about In-Service Software Upgrade 141
How to Configure In-Service Software Upgrade 141
Configuring Subpackage Upgrade 141
Subpackages Upgrade 141
Line Card Only In-Service Software Upgrade 142
ISSU Upgrade Across Major Releases 143
Feature Information for In-Service Software Upgrade 144
CHAPTER 10 Supervisor Redundancy 145
viii
Contents
Prerequisites for Supervisor Redundancy 147
Information About Supervisor Redundancy 147
Switchover Procedure 147
Using Redundant File Systems 148
Console Port Usage After Supervisor Switchover 150
Benefits 150
How to Configure Supervisor Redundancy 150
Forcing Switchover 151
Changing the System Boot Behavior 152
Saving a Configuration File to the Bootflash or Hard Disk 155
Verifying the Supervisor Redundancy Configuration 155
Verifying Supervisor Redundancy 155
Verifying Supervisor Switchover 158
Configuration Example for Supervisor Redundancy 159

Feature Information for Supervisor Redundancy 160
CHAPTER 11 Line Card Redundancy 161
Prerequisites for Line Card Redundancy 163
Restrictions for Line Card Redundancy 163
Information About Line Card Redundancy 164
How to Configure Line Card Redundancy 164
Configuring Line Card Manual Switchover 165
Configuring N+1 Line Card Redundancy 165
Verifying the Line Card Redundancy Configuration 166
Feature Information for Line Card Redundancy 170
PART III Layer 2 and DOCSIS 3.0 Configuration 173
CHAPTER 12 Downstream Interface Configuration 175
ix
Contents
Information About Downstream Interface Configuration 177
How to Configure Downstream Interfaces 179

Configuring the Cisco CMTS Manually Using Configuration Mode 179
Configuring the QAM Profile on the Downstream Channels 179
Configuring the Frequency Profile on the Downstream Channels 180
Configuring the Controller on the Downstream Channels 181
Troubleshooting Tips 182

Configuring the RF Channel on a Controller 182

Feature Information for Downstream Interface Configuration on the Cisco cBR Router 187
CHAPTER 13 Upstream Interface Configuration 189

Information About Upstream Interface Configuration 191
How to Configure Upstream Interfaces 191
Configuring the Cisco CMTS Manually Using Configuration Mode 191
Configuring the Modulation Profile and Assigning to an Upstream Channel 192
Configuring the Upstream Channel with PHY Layer 192
Associating Upstream Channels with a MAC Domain and Configuring Upstream Bonding 193
Configuring Upstream Channel Priority 195

Feature Information for Upstream Interface Configuration on the Cisco cBR Router 196
CHAPTER 14 DOCSIS Interface and Fiber Node Configuration 197
Overview of DOCSIS Interfaces and Fiber Node Configurations 199
Downstream Features 199
Upstream Features 200
MAC Domains (Cable Interfaces) 200
Fiber Nodes 200
x
Contents
Configuring DOCSIS Interfaces and Fiber Nodes 200

Configuring Upstream Channels 200
Verifying the Controller Configuration 200
Binding Upstream Channels to MAC Domain 201
Configuring Primary Capable Downstream Channels 202
Verifying Downstream Configuration in Controller 202
Configuring Integrated-cable Interface 202
Binding Primary Capable Downstream Channels to a MAC Domain 204
Configuring MAC Domain Service Groups 206
Configuring the Fiber Nodes 206
Verify MD-DS-SG Channel Membership 208
Verify MD-US-SG Channel Membership 208
Downstream Bonding Group Configuration 209
Configuring Wideband-cable Interface (Downstream Bonding Grouping) 209
Verifying the Bonding Group Interfaces 210
Upstream Bonding Group Configuration 212
Restrictions for Upstream Bonding Groups 212
Configuring Upstream Bonding Groups 213
Verifying Upstream Bonding Groups 214
Feature Information for DOCSIS Interface and Fiber Node Configuration 216
CHAPTER 15 Service Group Based Configuration of the Cisco cBR Router 217
Service Group Profile Based Configuration 217

Service Profile Configuration for 16x8 with One MAC Domain 219
Service Profile Configuration for 16x8 with Two MAC Domains 221
MAC-Domain Split Configuration 223
CHAPTER 16 DOCSIS Load Balancing Groups 227
Prerequisites for DOCSIS Load Balancing Groups 229
Restrictions for DOCSIS Load Balancing Groups 229
Information About DOCSIS Load Balancing Groups 230
Service-Based Load Balancing 230
xi
Contents
RLBG/GLBG Assignment 231

Channel Assignment 232
Upstream Load Balancing for DOCSIS 3.0 Cable Modems in Single Upstream Mode 235
Auto-generate DOCSIS 2.0 GLBG 235
Independent Upstream/Downstream Throughput Rules 235
How to Configure DOCSIS Load Balancing Groups 236
Configuring DOCSIS 3.0 and 2.0 RLBG and DOCSIS 2.0 GLBG 237
Configuring DOCSIS 3.0 GLBG 239
Configuring a DOCSIS 3.0 General Load Balancing Group 240
Configuring Default Values of DOCSIS 3.0 Load Balancing Group 241
Configuring Cable Modems to RLBG or a Service Type ID 242
Configuring Rules and Policies 243
Configuring Load Balancing Parameter for a Cable Modem Movement Failure 244
Creating and Configuring TLV type Tag 244
Configuration Examples for DOCSIS Load Balancing Groups 246
Example: Configuring a Tag 246
Example: Disabling Load Balancing 247
How to Configure Load Balancing with Operational Simplification 247
Load Balancing Groups with Operational Simplification 250
Verifying DOCSIS Load Balancing Groups 251
Feature Information for DOCSIS Load Balancing Groups 256
CHAPTER 17 DOCSIS Load Balancing Movements 257
Prerequisites 260
Prerequisites for Load Balancing 260
Prerequisites for Dynamic Channel Change for Load Balancing 260
Prerequisites for Dynamic Bonding Change for DOCSIS 3.0 Static Modem Count-Based Load
Balancing 260
Restrictions 260
Restrictions for Load Balancing 260
Restrictions for Dynamic Channel Change for Load Balancing 262
xii
Contents
DCC Restrictions with N+1 Redundancy and Inter-Card Load Balancing 263
Restrictions for DOCSIS 3.0 Static Modem Count-Based Load Balancing 263
Restrictions for Dynamic Bonding Change for DOCSIS 3.0 Static Modem Count-Based Load
Balancing 264
Restrictions for MRC-Only Cable Modems 264
Information on the Load Balancing on the Cisco CMTS 265
Feature Overview 265
Methods to Determine When Interfaces Are Balanced 266
Modems Method 266
Utilization Method 266
Load Balancing Parameters 267
Configurable Minimum Threshold under Utilization Method 267
Single Channel Load Balancing 268
Error Handling of Channel Assignment 268
Downstream Load Balancing Distribution with Upstream Load Balancing 268
Upstream Load Balancing for DOCSIS 3.0 Cable Modems in Single Upstream Mode 269
Interaction with Spectrum Management 269
Using Dynamic Channel Change 270
Multiple Channel Load Balancing 270
Algorithm for Bonded Channel Cable Modem Load Balancing 270
DOCSIS 3.0 Static Modem Count-Based Load Balancing 270
Dynamic Load Balancing for DOCSIS 3.0 Cable Modems 273
Multiple Channel Load Balancing Operation 273
Using DBC for DOCSIS 3.0 Load Balancing Movement 277
Benefits of Load Balancing 279
Exclude Cable Modems from Load Balancing Groups 280
How to Configure Load Balancing 280
Enabling Single Channel Load Balancing 281
Configuring Dynamic Bonding Change for DOCSIS 3.0 Static Load Balancing 281
Excluding Cable Modems from a Load Balancing Group 281
Distributing Downstream Load Balancing with Upstream Load Balancing 282
How to Configure Dynamic Channel Change for Load Balancing 283
Configuring Dynamic Channel Change for Load Balancing 284
Verifying Load Balancing Operations 285
xiii
Contents
Example 286
Configuration Examples for Load Balancing 289
Example: Configuring Dynamic Channel Change for Load Balancing 290
Feature Information for DOCSIS Load Balancing Movements 293
CHAPTER 18 DOCSIS 3.0 Downstream Bonding 295
Information About DOCSIS 3.0 Downstream Bonding 297
Receive Channel Profile 297
Receive Channel Configuration 297
RCC Template 297
Channel Assignment 298

Downstream Traffic Forwarding 298
Service Flow Priority in Downstream Extended Header 298
How to Configure RCP and RCC Encoding 298
Configuring the RCP ID 298
Configuring the RCC Templates 301
Assigning an RCC Template to a MAC Domain (Cable Interface) 304
Verifying the RCC Configuration 307
How to Configure Attribute Masks 307
Configuring Provisioned Attributes for an Integrated Cable Interface 308
Configuring Provisioned Attributes for a Wideband Cable Interface 309
Verifying the Attribute-Based Service Flow Assignments 310
How to Enable Service Flow Priority in Downstream Extender Header 311
Enabling Service Flow Priority in Downstream Extender Header 311
Verifying the Enablement of the Service Flow Priority in Downstream Extended Header 312
Enabling Verbose Reporting for Receive Channel Profiles 313
Configuration Example for an RCC Template 314
Feature Information for DOCSIS 3.0 Downstream Bonding 315
CHAPTER 19 DOCSIS 2.0 A-TDMA Modulation Profiles 317
xiv
Contents
Prerequisites for DOCSIS 2.0 A-TDMA Modulation Profiles 319
Restrictions for DOCSIS 2.0 A-TDMA Services 319
Information About DOCSIS 2.0 A-TDMA Services 319
Modes of Operation 320
Modulation Profiles 322
Benefits 322
How to Configure DOCSIS 2.0 A-TDMA Services 322
Creating Modulation Profiles 322
Creating a TDMA Modulation Profile 323
Creating a Mixed Mode Modulation Profile 323
Creating an A-TDMA Modulation Profile 324
Configuring the DOCSIS Mode and Profile on an Upstream 325
Monitoring the DOCSIS 2.0 A-TDMA Services 326
Displaying Modulation Profiles 327
Displaying Cable Modem Capabilities and Provisioning 327
Configuration Examples for DOCSIS 2.0 A-TDMA services 329
Creating Modulation Profiles Examples 329
Example: DOCSIS 1.0/DOCSIS 1.1 TDMA Modulation Profiles 329
Example: Mixed TDMA/A-TDMA Modulation Profiles 329
Example: DOCSIS 2.0 A-TDMA Modulation Profiles 330
Assigning Modulation Profiles to Upstreams Examples 330
Example: Assigning DOCSIS 1.0/DOCSIS 1.1 TDMA Modulation Profiles 331
Example: Assigning Mixed TDMA/A-TDMA Modulation Profiles 331
Example: Assigning DOCSIS 2.0 A-TDMA Modulation Profiles 331
Feature Information for DOCSIS 2.0 A-TDMA Modulation Profile 333
CHAPTER 20 Downstream Resiliency Bonding Group 335
Prerequisites for Downstream Resiliency Bonding Group 337
Restrictions for the Downstream Resiliency Bonding Group 337
Information About Downstream Resiliency Bonding Group 338
Finding a Best-Fit RBG for the Cable Modem 339
xv
Contents
How to Configure Downstream Resiliency Bonding Group 339

Enabling Downstream Resiliency Bonding Group 339
Reserving a Resiliency Bonding Group for a Line Card 340
Verifying Downstream Resiliency Bonding Group Configuration 341
Verifying the Downstream Resiliency Bonding Group 341
Verifying a Reserved Resiliency Bonding Group 341
Downstream Resiliency Narrowband Mode Versus Resiliency Bonding Group 342
Troubleshooting the Downstream Resiliency Bonding Group Configuration 346
Configuration Examples for the Downstream Resiliency Bonding Group 346
Feature Information for Downstream Resiliency Bonding Group 350
CHAPTER 21 Downstream Channel ID Assignment 351
Information About Downstream Channel ID Assignment on the Cisco CMTS Routers 353
Manual Downstream Channel ID Assignment 353
Automatic Downstream Channel ID Assignment on the Cisco CMTS Routers 354
How to Configure Downstream Channel ID Assignment on the Cisco CMTS Routers 355
Configuring Manual Downstream Channel ID Assignment 355
Configuring Automatic Downstream Channel ID Assignment 356
Feature Information for Downstream Channel ID Assignment 359
CHAPTER 22 Upstream Channel Bonding 361
Prerequisites for Upstream Channel Bonding 363
Restrictions for Upstream Channel Bonding 363
Information About Upstream Channel Bonding 364

Multiple Transmit Channel Mode 364
Multiple Receive Channel Mode 364
Dynamic Range Window and Transmit Power Levels for Upstream Channel Bonding 365
Extended Transmit Power 365
Reduced Transmit Channel Set 366

T4 Multiplier 367
xvi
Contents
Fiber Node Configuration for Upstream Channel Bonding 367

New TLVs for Upstream Channel Bonding 367
Upstream Weighted Fair Queuing 368
Class-Based Weighted Fair Queuing 369

Activity-Based Weighted Fair Queuing 369
Custom Weight for Service Flow Priorities 369
Upstream Scheduler and Service Flows 369
Upstream Service Flow Fairness 370
Distribution of Traffic across all Channels in a USBG 370
DOCSIS 3.0 Load Balancing with USBG Smaller than Cable Modem Capabilities 371
Cisco cBR-8 CCAP Line Card Rate Limiting 371
SID Tracking 371
Service ID Clusters 372
How to Configure Upstream Channel Bonding 372
Enabling MTC Mode on a Cisco CMTS Router 372

Default MTC Mode Configuration on a Cisco CMTS Router 372
Enabling MTC Mode for All CMs 373
Configuring UCSB Required Attribute 373

Creating a Bonding Group 374
Adding Upstream Channels to a Bonding Group 375
Adding Upstream Channel Ports to a Fiber Node 376
Configuring the Class-Based Weighted Fair Queuing 377

Configuring the Activity-Based Weighted Fair Queuing 378
Configuring Custom Weights for Service Flow Priorities 378
Configuring the SID Cluster 379
Configuring the Channel Timeout for a Cable Modem 381
Configuring Cable Upstream Resiliency 381
Configuring Rate Limiting on the Cisco cBR-8 CCAP Line Card 383
Enabling Upstream Related Events for CM Status Reports 384
Modifying the Bonding Group Attributes 384
Modifying the Ranging Poll Interval on Upstream Channels 385

Configuring the Reduced Channel Set Assignment 386
Configuring DOCSIS Extended Transmit Power Feature 387
xvii
Contents
Configuration Example for Upstream Channel Bonding 387
Example: Enabling MTC Mode for a Single CM Using the CM Configuration File 389
Verifying the Upstream Channel Bonding Configuration 389
Verifying Weighted Fair Queuing for Upstream Service Flows 390
Verifying Rate Limiting for Upstream Bonded Service Flows 390
Verifying Extended Power Transmission 390

Feature Information for Upstream Channel Bonding 391
CHAPTER 23 Dynamic Bonding Group 393
Information About Dynamic Bonding Group 395
Overview of Dynamic Bonding Group 395
How to configure Dynamic Bonding Group 395
Enable Dynamic Bonding Group 395
Enable DS-Resiliency and Configure Resiliency Bonding Group 396
Enable ACFE 396
Configure Interface Mac-Domain and Fiber-Node 397
Enable Load Balancing for DOCSIS 3.0 and DOCSIS 3.1 398
Enable DOCSIS 3.0 and DOCSIS 3.1 Static Load Balance 398
Enable DOCSIS 3.0 and DOCSIS 3.1 General Load Balance Group 399
Enable Dynamic Load Balance and Fixed-Primary Channel Movement 399
Verifying Dynamic Bonding Group Configuration 400
Verifying Static Load Balancing Configuration 402
Verifying Dynamic Load Balancing Configuration 404
Feature Information for Dynamic Bonding Group 406
CHAPTER 24 Spectrum Management and Advanced Spectrum Management 407

Prerequisites for Spectrum Management 409
Restrictions for Spectrum Management 409
Shared Spectrum Groups 409
Dynamic Upstream Modulation 410
xviii
Contents
Fixed-Frequency Spectrum Groups with Advanced Spectrum Management 410

Limitations on Upstream Modulation Parameters for PacketCable VoIP Calls 410
N+1 Redundancy Support 410
Intelligent and Advanced Spectrum Management Support 410
Information About Spectrum Management 411
Spectrum Management Measurements 412
Signal and Carrier Noise Ratios 412
Differences Between the MER (SNR) and CNR (CNiR) Values 413
SNR Smoothing 414
Additional Measurements 415
Upstream Signal Channel Overview 416
Upstream Segments and Combiner Groups 417
Frequency Management Policy 418
Noise Impairments 419
Spectrum Groups and Frequency Hopping 419
Guidelines for Spectrum Management 420
Guided and Scheduled Spectrum Management 420
Frequency Hopping Capabilities 420
Dynamic Upstream Modulation (MER [SNR]-Based) 422
Input Power Levels 424
Intelligent and Advanced Hardware-Based Spectrum Management 425
Intelligent Spectrum Management Enhancements 425
Benefits 425
Guided and Scheduled Spectrum Management Benefits 425
Intelligent and Advanced Spectrum Management Benefits 426
How to Configure Spectrum Management 427
Guided and Scheduled Spectrum Management Configuration Tasks 428
Creating and Configuring Spectrum Groups 428
Assigning a Spectrum Group to One or More Upstream Ports 430
Configuring Shared Spectrum Groups (Fiber Node Groups) for DOCSIS 3.0 431
Configuring Dynamic Upstream Modulation (MER [SNR]-Based) 431

Verifying Frequency Hopping 433
Intelligent and Advanced Spectrum Management Configuration Tasks 437
Configuring and Assigning Spectrum Groups 437
xix
Contents
Configuring Dynamic Upstream Modulation (CNR-Based) 437

Configuring Proactive Channel Management 439
Verifying the Spectrum Management Configuration 441

Monitoring Spectrum Management 444
Using CLI Commands 444
Using SNMP 445
ccsSNRRequestTable 446
ccsSpectrumRequestTable 446
ccsSpectrumDataTable 447
ccsUpSpecMgmtTable 447
ccsHoppingNotification 449
Spectrum Group and Combiner Group Examples 450
Example: Verifying Spectrum Group Creation 450
Example: Time-Scheduled Spectrum Group 450

Example: Verifying Spectrum Group Configuration 450
Example: Determining the Upstream Ports Assigned to a Combiner Group 451
Example: Combiner Group 451
Example: Other Spectrum Management Configurations 453

Dynamic Upstream Modulation Examples 454
Verifying Your Settings 454
Example: Modulation Profiles 454
Example: Input Power Level 456
Advanced Spectrum Management Configuration Examples 456

Example: Advanced Spectrum Management for the Cisco cBR Series Routers 456
Feature Information for Spectrum Management and Advanced Spectrum Management 458
CHAPTER 25 Upstream Scheduler Mode 459

Restrictions for Upstream Scheduler Mode 461
Information About Upstream Scheduler Mode for the Cisco CMTS Routers 461
How to Configure Upstream Scheduler Modes 461
xx
Contents

Feature Information for Upstream Scheduler Mode 463
CHAPTER 26 Generic Routing Encapsulation 465

Restrictions for Implementing Tunnels 467
Restrictions for GRE IPv6 Tunnels 468
Information About Implementing Tunnels 468
Tunneling Versus Encapsulation 468
Tunnel ToS 468
Path MTU Discovery 469
QoS Options for Tunnels 469
Information About IPv6 over IPv4 GRE Tunnels 470
Overlay Tunnels for IPv6 470
GRE IPv4 Tunnel Support for IPv6 Traffic 471
Information About GRE IPv6 Tunnels 472
Overview of GRE IPv6 Tunnels 472
How to Implement Tunnels 472
Determining the Tunnel Type 472
Configuring an IPv4 GRE Tunnel 473
GRE Tunnel Keepalive 473
What to Do Next 475
Configuring 6to4 Tunnels 476
What to Do Next 477

Verifying Tunnel Configuration and Operation 477
Configuration Examples for Implementing Tunnels 479
Example: Configuring a GRE IPv4 Tunnel 479
Configuring QoS Options on Tunnel Interfaces Examples 480
Policing Example 481
How to Configure IPv6 over IPv4 GRE Tunnels 482
Configuring GRE on IPv6 Tunnels 482
Configuration Examples for IPv6 over IPv4 GRE Tunnels 483
Example: GRE Tunnel Running IS-IS and IPv6 Traffic 483
xxi
Contents
Example: Tunnel Destination Address for IPv6 Tunnel 484

How to Configure GRE IPv6 Tunnels 484
Configure CDP Over GRE IPv6 Tunnels 484
Configuration Examples for GRE IPv6 Tunnels 486
Example: Configuring CDP Over GRE IPv6 Tunnels 486
Feature Information for Generic Routing Encapsulation 488
CHAPTER 27 Transparent LAN Service over Cable 489
Prerequisites for Transparent LAN Service over Cable 491
Restrictions for Transparent LAN Service over Cable 491
Information About Transparent LAN Service over Cable 492
Transparent LAN Service and Layer 2 Virtual Private Networks 492
IEEE 802.1Q Mapping 492
Overview 493
Details of IEEE 802.1Q Mapping 493
Benefits 493
How to Configure the Transparent LAN Service over Cable 494
Configuring IEEE 802.1Q VLAN Mapping 494
Enabling and Configuring Layer 2 Tunneling for IEEE 802.1Q Mapping 494
Creating the IEEE 802.1Q VLAN Bridge Group 495
Configuration Examples for Transparent LAN Service over Cable 496
Example: Configuring IEEE 802.1Q VLAN Mapping 496
Example: Configuring IEEE 802.1Q Bridge Aggregator 497
Verifying the Transparent LAN Service over Cable Configuration 498
Feature Information for Transparent LAN Service over Cable 499
CHAPTER 28 Downgrading Channel Bonding in Battery Backup Mode 501
Prerequisites for Downgrading Channel Bonding in Battery Backup Mode 503
Restrictions for Downgrading Channel Bonding in Battery Backup Mode 503
xxii
Contents
Information About Downgrading Channel Bonding in Battery Backup Mode 503

How to Configure Downgrading Channel Bonding in Battery Backup Mode 504
Configuring Channel Bonding Downgrade in Battery Backup Mode Globally 504
Configuring Channel Bonding Downgrade in Battery Backup Mode for MAC Domain 505
Verifying the Configuration for Channel Bonding Downgrade in Battery Backup Mode 506
Feature Information for Downgrading Channel Bonding in Battery Backup Mode 510
CHAPTER 29 Upstream Bonding Support for D-PON 511
Prerequisites for Upstream Bonding Support for D-PON 512
Restrictions for Upstream Bonding Support for D-PON 513
Information About Upstream Bonding Support for D-PON 514
D-PON on Upstream Scheduling 514
How to Configure Upstream Bonding Support for D-PON 515
Verifying the Upstream Bonding Support for D-PON 516

Feature Information for Upstream Bonding Support for D-PON 517
CHAPTER 30 Energy Management Mode 519
Information About Energy Management Mode 519

Dynamic Downstream Bonding Group 519
Flow Chart of the CM Power State 520
Interaction with the Battery Mode 521
Handling Energy Management Request Load 523
Supervisor High Availability and Line Card Switchover 523
Prerequisites for Energy Management Mode 523
Restrictions for the Energy Management Mode 523
Restrictions for CMTS High Availability 523
Restrictions for Dynamic Bonding Group 524
Restrictions for Interaction of CMTS with Other Features 524
Voice 524
Dynamic Bonding Change and Dynamic Channel Change and Related Applications 524
Multicast 524
xxiii
Contents
Committed Information Rate 524

Admission Control 525
Battery Mode 525
Attribute Mask 525
Dynamic Service Addition 525
Restrictions for Configuration Change and Interface Shutdown 525
How to Configure the Energy Management Mode 526
Enabling Energy Management Mode 526
Enabling Energy Management Mode per MAC Domain 527
Configuring Initialization Ranging Technique in Dynamic Bonding Channel 527
Configuring the Percentage for the Dynamic Channel Bandwidth 527
Configuring the Queue Size for Energy Management 527
Verifying the Energy Management Mode 527
Viewing the Basic Statistics for Energy Management Receive Request 528
Verifying the Configuration Parameters 528
Viewing Information Regarding a Cable Modem 528
Feature Information for Energy Management Mode 530
CHAPTER 31 Cable Modem Steering 531
Cable Modem Steering on the Cisco cBR Series Converged Broadband Routers 531
Prerequisites for Cable Modem Steering 532
Restrictions for Cable Modem Steering 532
Information About Cable Modem Steering 532
Upstream Channel Descriptor TLV for Ranging Hold-off 533
Ranging Class ID 533
Cable Modem Exclusion for DOCSIS Load Balance 533
How to Configure Cable Modem Steering on the CMTS Router 534
Configuring an Upstream Channel Class ID 534
Configuring an Upstream Ranging Hold-off Priority Value 535
Verifying and Troubleshooting Cable Modem Steering 536

Verifying an Upstream Ranging Class ID Configuration 536
Feature Information for Cable Modem Steering 539
xxiv
Contents
CHAPTER 32 DOCSIS Predictive Scheduler 541
Information about DOCSIS Predictive Scheduler 541

Configuring DPS on Cable Interface 542
Displaying DPS Grants on Upstream Channel 542
Displaying DPS Grants for Cable Modem 542
Displaying Upstream Utilization 543
Displaying Upstream Capacity Reserved for Contention Minislot 545
DOCSIS Predictive Scheduler Best Practices 545
MIBs 545
Load Balancing 545
Contention Based Bandwidth Requests 545
MAP Advance Time 546
Cable Modem Interoperability 546
TaFDM 546
Feature Information for DOCSIS Predictive Scheduler 546
PART IV Layer 2 and DOCSIS 3.1 Configuration 549
CHAPTER 33 DOCSIS 3.1 OFDM Channel Configuration 551
Information about OFDM Channel Configuration 553
OFDM Channels 553
Channel Profile 553
Modulation Profile 553
OFDM Channel Exclusion Band 553
How to Configure OFDM Channel 554
Configuring OFDM Modulation Profile 554
Verifying OFDM Modulation Profile Configuration 554
Configuring OFDM Channel Profile 555
Verifying OFDM Channel Profile Configuration 556
Configuring OFDM Channel as Primary Channel 557
Verifying OFDM Primary Channel Configuration 557
Configuring Port or Controller and Channel 558
xxv
Contents
Verifying Port/Controller and Channel Configuration 558

Feature Information for DOCSIS 3.1 OFDM Channel Configuration 563
CHAPTER 34 OFDM Channel Power Profile 565
Information About OFDM Channel Power Profile 567
Restrictions for Configuring OFDM Power Profile 567
How to Configure the OFDM Channel Power Profile 568

Configuring OFDM Power Profile Using Band-index 568
Verifying the Power Profile Configuration 568
Configuring OFDM Power Profile with Linear Power-tilt 569
Verifying the Power Profile Using show controller Command 569
Configuration Example for OFDM Power Profile 569
Feature Information for OFDM Channel Power Profile 570
CHAPTER 35 DOCSIS 3.1 Path Selection 571
Information about Path Selection 571

How to Configure Path Selection 571
Configuring Downstream Bonding Group with OFDM Channel 571
Verifying Downstream Bonding Group with OFDM Channel Configuration 572
Configuring Upstream Bonding Group with OFDMA Channel 572
Verifying Upstream Bonding Group with OFDMA Channel Configuration 572
Verifying the Path Selection Status 573
Clearing the Path Selection Status 573
Verifying the RCC Configuration 573
Feature Information for DOCSIS 3.1 Path Selection 575
CHAPTER 36 DOCSIS 3.1 Downstream Profile Selection 577
Information about Downstream Profiles 579
Default Data Profile 579
xxvi
Contents
Recommended Profile 579
Unfit Profile 579
How to Configure Profiles 580

Configuring Profile Downgrade 580
Configuring RxMER to Bit Loading Mapping 580
Hitless OFDM Profile Changes 581
Ephemeral Profile to Cable Modem Assignment 582
Display the Cable Modem Count per Profile 582
Feature Information for Downstream Profile Selection 583
CHAPTER 37 DOCSIS 3.1 Commanded Power for Upstream SC-QAMs 585
Information About Commanded Power Feature for Upstream SC-QAMs 587
Feature TLVs 587
TLVs Affected by Commanded Power for US SC-QAMs 587
Commanded Power Sub-TLVs 587
Feature Information for Commanded Power for US SC-QAMs 588
CHAPTER 38 DOCSIS3.1 Downstream Resiliency for OFDM channel 591
Information about DOCSIS3.1 Downstream Resiliency for OFDM Channel 593
How to Configure DOCSIS3.1 Downstream Resiliency for OFDM Channel 594
Configuring DOCSIS3.1 Downstream Resiliency for OFDM Channel 594
Displaying OFDM Specific CM-STATUS Events 594
Feature Information for DOCSIS3.1 Downstream Resiliency for OFDM Channel 595
CHAPTER 39 DOCSIS 3.1 OFDMA Channel Configuration 597
Information about OFDMA Channel Configuration 599
OFDMA Channels 599
Modulation Profile 599
OFDMA Channel Exclusion Band 600
xxvii
Contents
Configure OFDMA Channel 600

Configuring OFDMA Controller Profile 600
Verifying OFDMA Modulation Profile Configuration 601
Configuring OFDMA Channel 602
Verifying OFDMA Channel Configuration 604
Configure Exclusion / Unused Bands 605
Verifying Exclusion / Unused Bands 606
Override OFDMA Profile Per Channel 606
Verifying Override Configuration 608
Apply OFDMA Upstream To Cable Interface 609
Determine DOCSIS 3.1 Cable Modems and the Cable Modems Using OFDMA Upstreams 609
Verifying DOCSIS 3.1 Upstream OFDMA channel bonding across DOCSIS 3.0 ATDMA
channels 611
Display the OFDMA Performance Statistics 611
Feature Information for DOCSIS 3.1 OFDMA Channel Configuration 616
CHAPTER 40 OFDMA OUDP Leak Detection Configuration 617
OUDP Leakage Detection 617

Methods to Configure OUDP Leak Detection 618
Supported Line Cards 618
OUDP Leakage Detection Test Sessions 618
OUDP Parent Test Sessions 620
OUDP Child Test Sessions 621
Persistent OUDP Test Sessions 622
OUDP Late Modem Joining 624
OUDP System Boot Holdoff 624
OUDP Test Expiration 624
OUDP Test Session High Availability 625
EXEC Mode Command Summary 625
Global Configuration Mode Command Summary 627
Configuration Mode Command Summary 628
OUDP Burst-Profile Sub-Mode Config CLI Commands 629
Show OUDP Command Summary 630
Related Show Command Summary 631
xxviii
Contents
Example: Configuration Command Mode 631

Example: EXEC Command Mode 631
Verifying the OUDP Session 632
Example: Creating a Test Session on Selected Modems Using the EXEC Mode 633
Specifications 634
Recommendations for the OFDMA Burst Testing Channel Configuration 634
Example: Channel Configuration for a Third-Party Leak Detector 634
CHAPTER 41 Time and Frequency Division Multiplexing Configuration 637
Information About TaFDM Support 637

Prerequisites for Configuring TaFDM Support 637
How to Configure cBR for TaFDM Support 638
Configuring TaFDM Modulation Profile 638
Configuring I/O Controller for TaFDM 638
Enhancing OFDMA Channel Throughput 639
Enhancing SC-QAM Channel UGS Flow Performance 639
Configuring Cable Interface-MAC Domain 639
Configuring Service Class 640
Excluding a Frequency Band from TaFDM 640
Verifying TaFDM Configuration 640
Configuration Example 640
Feature Information for TaFDM Configuration 641
CHAPTER 42 DOCSIS 3.1 Upstream Profile Selection 643
Information about Upstream Profiles 645
Default Data IUC 645
Recommended Interval Usage Code (IUC) 645
How to Configure Upstream Profiles 645
Configuring RxMER to Bit Loading Mapping 645
Configuring Codeword Error Threshold 646
Downgrading to Partial Mode 648
Configuring RxMER Downgrade 649
Display the Cable Modem Count per Profile 650
xxix
Contents
Feature Information for Upstream Profile Selection 651
CHAPTER 43 Proactive Network Management 653

Information about Proactive Network Management 654
Proactive Network Management for Supervisor High Availability, Line Card High Availability and
containers 654
Proactive Network Management Using Upstream Triggered Spectrum Capture 654
Proactive Network Management Interface Index 656

Upstream Triggered Spectrum Capture Configuration Parameters 659
Upstream Triggered Spectrum Capture Configuration Objects 659

Upstream Triggered Spectrum Capture Configuration MIB Objects 660
Upstream Triggered Spectrum Capture Control Objects and MIBs 669
Upstream Triggered Spectrum Capture Status Objects and MIBs 671
Upstream Triggered Spectrum Capture Capability Objects and MIBs 671

Upstream Triggered Spectrum Capture Bulk Data Control Objects and MIBs 673
Configuring the PNM MAX-HOLD Trigger Mode 674
Proactive Network Management MAX-HOLD trigger mode 675
Debugging the PNM feature on cBR8 676
Quick Install Guide 677
Proactive Network Management using OFDMA RxMER Probes 679
PNM RxMER Probe High Availability 681
RxMer Probe Debugging 681
Troubleshooting Proactive Network Management Issues 683
Feature Information for Proactive Network Management 685
CHAPTER 44 Downstream Power Tilt 687

Information about Downstream Power Tilt 689
Restrictions for Configuring Downstream Power Profile 689
How to Configure the Downstream Power Tilt 689
Configuring Downstream Power Tilt 689
Verifying Downstream Power Tilt Configuration 690
Feature Information for Downstream Power Tilt 691
xxx
Contents
CHAPTER 45 Controller Profile Configuration 693
Information about Controller Profile Configuration 695
How to Configure the Controller Profile 695
Configuring Downstream Controller Profile 695
Verifying Downstream Controller Profile Configuration 696
Configuring Upstream Controller Profile 697
Verifying Upstream Controller Profile Configuration 698
Feature Information for Controller Profile Configuration 699
CHAPTER 46 Voltage Thresholds for AC Power Supply Module Mode Control 701
Information about Voltage Thresholds for AC PSM Mode Control 703
Overview of Voltage Thresholds for AC PSM Mode Control 703
How to Configure Voltage Thresholds for AC PSM Mode Control 703
Configuring Voltage Thresholds for AC PSM Mode Control 703
Verifying Voltage Thresholds for AC PSM Mode Control 704
Example: Configuring Voltage Thresholds for AC PSM Mode Control 704
Feature Information for Voltage Thresholds for AC PSM Mode Control 704
CHAPTER 47 DOCSIS3.1 Downstream Zero Bit Loading 707
Information about DOCSIS3.1 Downstream Zero Bit Loading 709
How to Configure DOCSIS3.1 Downstream Zero Bit Loading 709
Configuring Downstream Zero Bit Loading 709
Verifying Downstream Zero Bit Loading 710
Feature Information for DOCSIS3.1 Downstream Zero Bit Loading 711
CHAPTER 48 Reducing Power Consumption 713

Information About Reducing Power Consumption 715
xxxi
Contents
Restrictions for Setting Up Power-Saving Configuration 715
Configure Reduction of Power Consumption 715

Verifying the Power-Saving Configuration 716
Feature Information for Reducing Power Consumption 716
PART V Layer 2 and Layer 3 VPN Configuration 717
CHAPTER 49 L2VPN Support over Cable 719

Prerequisites for L2VPN Support over Cable 721
Restrictions for L2VPN Support over Cable 721
VPN ID Restrictions 722
Information About L2VPN Support over Cable 722
Point-to-Point L2VPN Forwarding Mode 723
L2VPN Encodings in the CM Configuration File 724
Supported L2VPN Encodings 725
Voice-Call Support on L2VPN CM 726
How to Configure L2VPN Support over Cable 726
Configuring the Ethernet Network System Interface 726
Preparing the DOCSIS Configuration File for L2VPN Support 727
Manual Switchover Command Line Interface 727
Verifying L2VPN Support over Cable 728
Enabling Voice-Call on a L2VPN CM 730
Verifying Dynamic Service Flows 730
Configuration Examples for L2VPN over Cable 731
Example: Specifying the Ethernet NSI Interface 731
Example: Enabling Voice Call Support on MPLS L2VPN 732
Example: Enabling Voice Call Support on 802.1q L2VPN 732
Example: Enabling Voice Call Support on CLI-based L2VPN 733

Feature Information for L2VPN Support over Cable 735
CHAPTER 50 L2VPN Over Port-Channel 737
xxxii
Contents
Information About L2VPN Over Port-Channel 737

TLS L2VPN 737
DOCSIS L2VPN 737
Benefits of L2VPN Over Port-Channel 738
Restrictions for L2VPN Over Port-Channel 738
How to Configure the L2VPN Over Port-Channel 738
Configuring the Port-Channel Uplink Port for TLS L2VPN 738
Configuring the Port-Channel Uplink Port for DOCSIS L2VPN 738
Verifying Port-Channel Configuration 738
Feature Information for L2VPN Over Port-Channel 739
CHAPTER 51 MPLS Pseudowire for Cable L2VPN 741

Prerequisites for MPLS Pseudowire for Cable L2VPN 743
Restrictions for MPLS Pseudowire for Cable L2VPN 743
Information About MPLS Pseudowire for Cable L2VPN 744
How MPLS Transports Layer 2 Packets 744
Supported Ethernet Encapsulation on UNI 746

MPLS Pseudowire 746
Bundle254 Interface 746
Ingress Process 746
Egress Process 747
MPLS Pseudowire Control Plane Process 747
L2VPN Pseudowire Redundancy 747
MPLS Pseudowire Provisioning Methods 747
Static Provisioning Method for MPLS Pseudowires 748
Dynamic Provisioning Method for MPLS Pseudowires 748
Cisco-Specific L2VPN TLVs 750
How to Enable MPLS on a Cisco CMTS Router 752
Configuring an LDP Router ID 752
Configuring MPLS on a Gigabit Ethernet Interface 753
Configuring an MPLS Label Distribution Protocol 754
Enabling the Cisco CMTS Support for MPLS Pseudowire for Cable L2VPN 755
xxxiii
Contents
Customize MTU 756

How to Provision MPLS Pseudowires 756
Dynamic Provisioning of MPLS Pseudowires 756
Static Provisioning Method for MPLS Pseudowires 757
How to Configure L2VPN Pseudowire Redundancy 757
Configuring the Backup Pseudowire 757
Configuring Backup Delay 758
Performing Manual Switchover 760
Configuration Examples for MPLS Pseudowire for Cable L2VPN 760
Configuration Example for Static Provisioning of MPLS Pseudowires 761
Configuration Examples for Dynamic Provisioning of MPLS Pseudowires 761
BSOD Specification-Based MPLS Pseudowire Provisioning: Example 761
Type-4 MPLS Pseudowire Provisioning Using the CM Configuration File: Example 763
Type-5 MPLS Pseudowire Provisioning Using the CM Configuration File: Example 765
Configuration Examples for L2VPN Pseudowire Redundancy 765
Example: Configuring Backup Pseudowire Peer and VC ID 765
Example: Configuring Backup Delay 766

Example: L2VPN Backup MPLS Pseudowire Provisioning Using the CM Configuration File 766
Verifying the MPLS Pseudowire Configuration 767
Feature Information for MPLS Pseudowire for Cable L2VPN 771
CHAPTER 52 MPLS VPN Cable Enhancements 773

Benefits 777
Restrictions 778
Prerequisites 778
Other Important Information 779
Configuration Tasks 779
Creating VRFs for each VPN 779
Defining Subinterfaces on a Virtual Bundle Interface and Assigning VRFs 781
xxxiv
Contents
Configuring Cable Interface Bundles 782

Configuring Subinterfaces and MPLS VPNs on a Virtual Bundle Interface 782
Configuring MPLS in the P Routers in the Provider Core 782
Verifying the MPLS VPN Configuration 783
VRF Definition Configuration 784
Cable Bundle SubInterface Configuration 785
PE WAN Interface Configuration 786
PE BGP Configuration 786

Feature Information for MPLS VPN Cable Enhancements 789
CHAPTER 53 Multicast VPN and DOCSIS 3.0 Multicast QoS Support 791

Restrictions for the Multicast VPN and DOCSIS 3.0 Multicast QoS Support 793
Information About the Multicast VPN and DOCSIS 3.0 Multicast QoS Support 793
Enhanced Quality of Service 793
Intelligent Multicast Admission Control 794
Multicast Session Limit Support 794
Multicast Virtual Private Network 794
How to Configure the Multicast VPN and DOCSIS 3.0 Multicast QoS Support 795
Configuring a QoS Profile for a Multicast Group 795
Configuring a Multicast QoS Group 795
Configuring a Default Multicast QoS Group for VRF 797
Verifying Configuration of the Multicast VPN and DOCSIS 3.0 Multicast QoS Support 798
Configuration Examples for the Multicast VPN and DOCSIS 3.0 Multicast QoS Support 799
Example: Configuring Group QoS and Group Encryption Profiles 799
Example: Configuring a QoS Group 799
Feature Information for Multicast VPN and DOCSIS3.0 Multicast QoS Support 801
CHAPTER 54 EtherChannel for the Cisco CMTS 803

xxxv
Contents
Restrictions for EtherChannel on the Cisco CMTS 805

Information About EtherChannel on the Cisco CMTS 805
Introduction to EtherChannel on the Cisco CMTS 805
Cisco Ten Gigabit EtherChannel on the Cisco cBR Series Routers 806
How to Configure EtherChannel on the Cisco CMTS 806
Configuring Ten Gigabit EtherChannel on the Cisco CMTS 806
What to Do Next 808

Verifying EtherChannel on the Cisco CMTS 808
Configuration Examples for EtherChannel on the Cisco CMTS 809
Feature Information for EtherChannel on Cisco CMTS 811
CHAPTER 55 Flow-Based per Port-Channel Load Balancing 813
Restrictions for Flow-Based per Port-Channel Load Balancing 814
Information About Flow-Based per Port-Channel Load Balancing 815
Flow-Based Load Balancing 815
Buckets for Flow-Based Load Balancing 815
Load Balancing on Port Channels 815
How to Enable Flow-Based per Port-Channel Load Balancing 817
Configuring Load Balancing on a Port Channel 817
Verifying Load Balancing Configuration on a Ten GEC Interface 818
Configuration Examples for Flow-Based per Port-Channel Load Balancing 820
Example: Flow-Based Load Balancing 820
Feature Information for Flow-Based per Port-Channel Load Balancing 821
CHAPTER 56 MPLS QoS via TLV for non-L2VPN Service Flow 823
Restrictions for MPLS QoS via TLV for non-L2VPN Service Flow 824
Information About MPLS QoS via TLV for non-L2VPN Service Flow 825
Configuring MPLS QoS via TLV for non-L2VPN Service Flow 825
Traffic Class for MPLS Imposition Packets 825
xxxvi
Contents
Traffic Classification for MPLS Disposition Packets 825

Using Vendor-Specific TLVs with AToM L2VPN and MPLS L3VPN 826
Example: Upstream Service Flow Marking TLV 826
Example: Downstream Packet Classification TLV 827
Example: MPLS QoS Configuration File 827

Feature Information for MPLS QoS via TLV for non-L2VPN Service Flow 830
CHAPTER 57 IPsec Security Support 831

IPsec Security Support 833
IPsec Security Limitations 833
Configuring IPsec Security 833
Configuring Transform Sets for IKEv2 835
Feature Information for IPsec Security Support 836
PART VI Layer 3 Configuration 839
CHAPTER 58 DHCP, ToD, and TFTP Services for CMTS Routers 841
Prerequisites for DHCP, ToD, and TFTP Services 841

Restrictions for DHCP, ToD, and TFTP Services 841
Information About DHCP, ToD, and TFTP Services 842
External DHCP Servers 842
Cable Source Verify Feature 842
Smart Relay Feature 843
GIADDR Field 844
DHCP Relay Agent Sub-option 844
Time-of-Day Server 844
TFTP Server 846
Sniff out boot file name from DHCP process per CM 846
Benefits 847
xxxvii
Contents
How to Configure ToD, and TFTP Services 847

Configuring Time-of-Day Service 847
Enabling Time-of-Day Service 847
Disabling Time-of-Day Service 848
Configuring TFTP Service 849
Optimizing the Use of an External DHCP Server 852
Configuring Cable Source Verify Option 852
Configuring Prefix-based Source Address Verification 854
Configuring Optional DHCP Parameters 855
How to Configure ToD, and TFTP Services 858

ToD Server Example 858
TFTP Server Example 858
Feature Information for the DHCP, ToD, and TFTP Services for the CMTS Routers 859
CHAPTER 59 Virtual Interface Bundling 861
Information About Virtual Interface Bundling 862
Overview of Virtual Interface Bundling 863
Guidelines for Virtual Interface Bundling 864
Virtual Interface Bundle-aware and Bundle-unaware Support 864
Configuring Virtual Interface Bundling 865
Verfiying the Virtual Interface Bundling Configuration 867
Feature Information for Virtual Interface Bundling 870
CHAPTER 60 IPv6 on Cable 871
Restrictions for IPv6 on Cable 873
Multicast Restrictions 873
QoS Restrictions 873
Information About IPv6 on Cable 874

Features Supported 874
xxxviii
Contents
Overview of the DOCSIS 3.0 Network Model Supporting IPv6 875

Overview of Cable Modem IPv6 Address Provisioning 876
Overview of IPv6 Dual Stack CPE Support on the CMTS 878

Overview of IPv6 over Subinterfaces 878
Overview of High Availability on IPv6 878

DOCSIS PRE HA 878
DOCSIS Line Card HA 878
Dynamic Channel Change 879
Overview of IPv6 VPN over MPLS 879

Cable Monitor 880
Overview of IPv6 CPE Router Support on the Cisco CMTS 880
Support for IPv6 Prefix Stability on the CMTS 881
Configurable DHCPv6 Relay Address 881
Support for Multiple IAPDs in a Single Advertise 882
IPv6 Neighbor Discovery Gleaning 883
How to Configure IPv6 on Cable 883
Configuring IPv6 Switching Services 883

Implementing IPv6 Addressing and Basic Connectivity for Cable Interfaces and Bundles 885
Configuring the Cable Virtual Bundle Interface 885
Configuring the IP Provisioning Mode and Bundle on the Cable Interface 886
Enabling MDD with Pre-Registration DSID 888

Configuring IPv6 Cable Filter Groups 888
Configuring IPv6 Cable Filter Groups 888
Cable Filter Groups and the DOCSIS Subscriber Management MIB 888
Configuring IPv6 Domain Name Service 893
Configuring IPv6 Source Verification 895
Configuring IPv6 VPN over MPLS 896
Configuring DHCPv6 Relay Agent 896
Configuring IPv6 Source Address and Link Address 897
Configurable DOCSIS CMTS Capabilities DHCPv6 Field 897
Disabling IPv6 ND Gleaning 898

How to Verify IPv6 Dual Stack CPE Support 898
Examples 899
xxxix
Contents
Configuration Examples for IPv6 on Cable 900

Example: IPv6 over Subinterfaces 900
Example: Basic IPv6 Cable Filter Groups 900
Example: Complete Cable Configuration with IPv6 901
Example: BGP Configuration for 6VPE 909
Example: Subinterface Configuration for 6VPE 909
Example: Cable Interface Bundling 910
Example: VRF Configuration for 6VPE 910
Verifying IPv6 on Cable 910

Verifying IPv6 VRF Configuration 910
Verifying IPv6 BGP Status 911
Verifying MPLS Forwarding Table 911
Verifying IPv6 Cable Modem and its Host State 911
Verifying Multiple IAPDs in a Single Advertise 912
Supported MIBs 912
Feature Information for IPv6 on Cable 913
CHAPTER 61 Cable DHCP Leasequery 915
Prerequisites for Cable DHCP Leasequery 917
Restrictions for Cable DHCP Leasequery 917
Information About Cable DHCP Leasequery 917
DHCP MAC Address Exclusion List 918
Unitary DHCPv6 Leasequery 918
How to Configure Filtering of Cable DHCP Leasequery Requests 919

Enabling DHCP Leasequery Filtering on Downstreams 919
Enabling DHCP Leasequery Filtering on Upstreams 920
Configuring Unitary DHCPv6 Leasequery Filtering 920
Enabling DHCPv6 Leasequery Filtering on Downstreams 922
Configuration Examples for Filtering of DHCP Leasequery 923
Example: DHCP Leasequery Filtering 923

Example: Unitary DHCPv6 Leasequery Filtering 923
xl
Contents
Feature Information for Cable DHCP Leasequery 924
CHAPTER 62 DHCPv6 Bulk-Lease query 925
Information About DHCPv6 Bulk-Lease Query 927
How to Configure DHCPv6 Bulk-Lease Query 927
Debugging DHCPv6 Bulk-Lease Query 928
Feature Information for DHCPv6 Bulk-Lease query 928
CHAPTER 63 Layer 3 CPE Mobility 929

Prerequisites for Layer 3 CPE Mobility 930
Restrictions for Layer 3 CPE Mobility 931
Information About Layer 3 CPE Mobility 931
Benefits of Layer 3 CPE Mobility 932

How to Configure Layer 3 Mobility 932
Configuring CPE Mobility 932
Configure Source-Based Rate Limit (SBRL) for L3-mobility 933
Disabling CPE Mobility 934
Verifying Layer 3 Mobility Configuration 935
Configuration Examples for Layer 3 Mobility 935
Example: Configuring CPE Layer 3 Mobility 935
Example: Configuring SBRL for L3-mobility 936
Feature Information for Layer 3 CPE Mobility 936
CHAPTER 64 DOCSIS 3.0 Multicast Support 939
Prerequisites for the DOCSIS 3.0 Multicast Support 940
Restrictions for the DOCSIS 3.0 Multicast Support 941
Information About the DOCSIS 3.0 Multicast Support 941
Multicast DSID Forwarding 941
Multicast Forwarding on Bonded CM 942
Static TLV Forwarding 943
xli
Contents
Explicit Tracking 943

Multicast Quality of Service Enhancement 943
Multicast Secondary Bonding Group 944
Load Balancing 944
Multicast DSID Forwarding Disabled Mode 944
MDF1 Support for DOCSIS 2.0 Hybrid Cable Modems 945
DSG Disablement for Hybrid STBs 945

Benefits of MDF1 Support 945
Dynamic Multicast Replication Sessions 945
Cache Multicast Replication Sessions 946
How to Configure the DOCSIS 3.0 Multicast Support 946
Configuring Basic Multicast Forwarding 946
Configuring Querier’s Robustness Variable 947
Configuring Multicast DSID Forwarding 948
Configuring Explicit Tracking 948
Configuring Multicast QoS 948
Selecting a Forwarding Interface Based on Service Flow Attribute 949
Configuring Multicast DSID Forwarding Disabled Mode 952
Configuring Multicast Replication Session Globally 953
Configuring Multicast Replication Sessions on Forwarding Interface 953
Clearing Multicast Replication Cache 954
How to Monitor the DOCSIS 3.0 Multicast Support 954
Verifying the Basic Multicast Forwarding 954
Verifying the Multicast DSID Forwarding 955
Verifying the Explicit Tracking Feature 956
Verifying the Multicast QoS Feature 956
Verifying the Service Flow Attributes 957

Verifying the Multicast Group Classifiers 957
Viewing Current Cache 958
Configuration Examples for DOCSIS 3.0 Multicast Support 959
Example: Configuring Basic Multicast Forwarding 959
Example: Configuring Multicast QoS 960
Example: Configuring Forwarding Interface Selection Based on Service Flow Attribute 960
xlii
Contents
Example: Configuring Multicast Replication Session 960

Feature Information for DOCSIS 3.0 Multicast Support 962
CHAPTER 65 IPv6 Segment Routing on Cisco cBR 963

Information about IPv6 Segment Routing 965
Restriction for Configuring IPv6 Segment Routing 965
How to Configure IPv6 Segment Routing 965
Configuring IPv6 Segment Routing on cBR 965
Verifying IPv6 Segment Routing Configuration 965
Configure Multiple IPv6 Addresses for Segment Routing 966
Verifying IPv6 Segment Routing Configuration on Multiple IPv6 Addresses 966
Disabling Prefix SID 966
Verifying whether Prefix SID is Disabled 967
Disabling SRv6 for a Prefix-SID 967
Verifying whether SRv6 is Disabled and Prefix SID Removed 967
Example: Configuring IPv6 Segment Routing on Cisco cBR 967
Example: Configure Multiple IPv6 Addresses for SRv6 968
Example: Disabling Prefix SID 968
Example: Disabling SR with an Active Prefix SID 968
Feature Information for IPv6 Segment Routing 968
PART VII IP Access Control Lists 969
CHAPTER 66 IP Access Control Lists 971
Information About IP Access Lists 973
Benefits of IP Access Lists 973
Border Routers and Firewall Routers Should Use Access Lists 973
Definition of an Access List 974
Access List Rules 975
Helpful Hints for Creating IP Access Lists 975
xliii
Contents
Named or Numbered Access Lists 976

Standard or Extended Access Lists 976
IP Packet Fields You Can Filter to Control Access 977
Wildcard Mask for Addresses in an Access List 978
Access List Sequence Numbers 979
Access List Logging 979
Alternative to Access List Logging 979
Additional IP Access List Features 980
Where to Apply an Access List 980
Feature Information for IP Access Lists 981
CHAPTER 67 Creating an IP Access List and Applying It to an Interface 983
Information About Creating an IP Access List and Applying It to an Interface 985
Access List Remarks 986
Additional IP Access List Features 986
How to Create an IP Access List and Apply It to an Interface 986
Creating a Standard Access List to Filter on Source Address 986
Creating a Named Access List to Filter on Source Address 987
Creating a Numbered Access List to Filter on Source Address 989
Creating an Extended Access List 990
Creating a Named Extended Access List 990
Creating a Numbered Extended Access List 992
Applying an Access List to an Interface 994
Configuration Examples for Creating an IP Access List and Applying It to a Physical Interface 995
Example: Filtering on Host Source Address 995
Example: Filtering on Subnet Source Address 996
Example: Filtering on Source and Destination Addresses and IP Protocols 996
Example: Filtering on Source Addresses Using a Numbered Access List 996
Example: Preventing Telnet Access to a Subnet 997
Example: Filtering on TCP and ICMP Using Port Numbers 997
Example: Allowing SMTP E-mail and Established TCP Connections 997
xliv
Contents
Example: Preventing Access to the Web by Filtering on Port Name 998

Example: Filtering on Source Address and Logging the Packets 998
Example: Limiting Debug Output 998
Additional References Creating an IP Access List and Applying It to an Interface 999
Feature Information Creating an IP Access List and Applying It to an Interface 1000
CHAPTER 68 Creating an IP Access List to Filter IP Options, TCP Flags, Noncontiguous Ports 1001
Prerequisites for Creating an IP Access List to Filter IP Options TCP Flags Noncontiguous Ports 1003
Information About Creating an IP Access List to Filter IP Options, TCP Flags, Noncontiguous Ports
1003
IP Options 1003
Benefits of Filtering IP Options 1003
Benefits of Filtering on TCP Flags 1004
TCP Flags 1004
Benefits of Using the Named ACL Support for Noncontiguous Ports on an Access Control Entry
Feature 1005
How Filtering on TTL Value Works 1005
Benefits of Filtering on TTL Value 1006
How to Create an IP Access List to Filter IP Options TCP Flags Noncontiguous Ports 1006
Filtering Packets That Contain IP Options 1006

What to Do Next 1008
Filtering Packets That Contain TCP Flags 1008
Configuring an Access Control Entry with Noncontiguous Ports 1010
Consolidating Access List Entries with Noncontiguous Ports into One Access List Entry 1011
What To Do Next 1013
Filtering Packets Based on TTL Value 1013
Enabling Control Plane Policing to Filter on TTL Values 0 and 1 1015
Configuration Examples for Filtering IP Options, TCP Flags, Noncontiguous Ports 1017
Example: Filtering Packets That Contain IP Options 1017

Example: Filtering Packets That Contain TCP Flags 1018
Example: Creating an Access List Entry with Noncontiguous Ports 1018
Example: Consolidating Some Existing Access List Entries into One Access List Entry with
Noncontiguous Ports 1018
xlv
Contents
Example: Filtering on TTL Value 1019

Example: Control Plane Policing to Filter on TTL Values 0 and 1 1019

Feature Information for Creating an IP Access List to Filter IP Options, TCP Flags, Noncontiguous
Ports, or TTL Values 1021
CHAPTER 69 Refining an IP Access List 1023
Information About Refining an IP Access List 1025
Access List Sequence Numbers 1025
Benefits of Access List Sequence Numbers 1025
Sequence Numbering Behavior 1025
Benefits of Time Ranges 1026
Benefits Filtering Noninitial Fragments of Packets 1026
Access List Processing of Fragments 1027
How to Refine an IP Access List 1028
Revising an Access List Using Sequence Numbers 1028
Restricting an Access List Entry to a Time of Day or Week 1031
Configuration Examples for Refining an IP Access List 1033
Example Resequencing Entries in an Access List 1033
Example Adding an Entry with a Sequence Number 1033
Example Adding an Entry with No Sequence Number 1034
Example Time Ranges Applied to IP Access List Entries 1034
Example Filtering IP Packet Fragments 1034
Feature Information for Refining an IP Access List 1036
CHAPTER 70 IP Named Access Control Lists 1037
Information About IP Named Access Control Lists 1039
Definition of an Access List 1039
Named or Numbered Access Lists 1039
xlvi
Contents
Access List Rules 1040

Where to Apply an Access List 1042
How to Configure IP Named Access Control Lists 1043
Creating an IP Named Access List 1043
Applying an Access List to an Interface 1045
Additional References for IP Named Access Control Lists 1045
Feature Information for IP Named Access Control Lists 1046
CHAPTER 71 IPv4 ACL Chaining Support 1047
Restrictions for IPv4 ACL Chaining Support 1049
Information About IPv4 ACL Chaining Support 1049
ACL Chaining Overview 1049
IPv4 ACL Chaining Support 1049
How to Configure IPv4 ACL Chaining Support 1050
Configuring an Interface to Accept Common ACL 1050
Configuration Examples for IPv4 ACL Chaining Support 1050

Example: Configuring an Interface to Accept a Common ACL 1051
Additional References for IPv4 ACL Chaining Support 1051
Feature Information for IPv4 ACL Chaining Support 1052
CHAPTER 72 IPv6 ACL Chaining with a Common ACL 1053
Information About IPv6 ACL Chaining with a Common ACL 1055
ACL Chaining Overview 1055
IPv6 ACL Chaining with a Common ACL 1055
How to Configure IPv6 ACL Chaining with a Common ACL 1055
Configuring IPv6 ACL to an Interface 1056
Configuration Examples for IPv6 ACL Chaining with a Common ACL 1057
Example: Configuring an Interface to Accept a Common ACL 1057
Additional References for IPv6 ACL Chaining with a Common ACL 1058
Feature Information for IPv6 ACL Chaining with a Common ACL 1059
xlvii
Contents
CHAPTER 73 Commented IP Access List Entries 1061
Information About Commented IP Access List Entries 1063
Access List Remarks 1063
How to Configure Commented IP Access List Entries 1064
Writing Remarks in a Named or Numbered Access List 1064
Additional References for Commented IP Access List Entries 1065
Feature Information for Commented IP Access List Entries 1065
CHAPTER 74 Standard IP Access List Logging 1067
Restrictions for Standard IP Access List Logging 1068
Information About Standard IP Access List Logging 1069
Standard IP Access List Logging 1069
How to Configure Standard IP Access List Logging 1069
Creating a Standard IP Access List Using Numbers 1069
Creating a Standard IP Access List Using Names 1070
Configuration Examples for Standard IP Access List Logging 1071
Example: Limiting Debug Output 1071
Additional References for Standard IP Access List Logging 1072
Feature Information for Standard IP Access List Logging 1072
CHAPTER 75 IP Access List Entry Sequence Numbering 1073
Restrictions for IP Access List Entry Sequence Numbering 1074
Information About IP Access List Entry Sequence Numbering 1075
Purpose of IP Access Lists 1075
How an IP Access List Works 1075
IP Access List Process and Rules 1075
Source and Destination Addresses 1077
Wildcard Mask and Implicit Wildcard Mask 1077
xlviii
Contents
Transport Layer Information 1078

Benefits IP Access List Entry Sequence Numbering 1078
Sequence Numbering Behavior 1078
How to Use Sequence Numbers in an IP Access List 1079
Sequencing Access-List Entries and Revising the Access List 1079
Configuration Examples for IP Access List Entry Sequence Numbering 1082
Example: Resequencing Entries in an Access List 1082
Example: Adding Entries with Sequence Numbers 1083
Example: Entry Without Sequence Number 1083
Feature Information for IP Access List Entry Sequence Numbering 1084
CHAPTER 76 ACL IP Options Selective Drop 1085
Restrictions for ACL IP Options Selective Drop 1087
Information About ACL IP Options Selective Drop 1087
Using ACL IP Options Selective Drop 1087
Benefits of Using ACL IP Options Selective Drop 1087
How to Configure ACL IP Options Selective Drop 1087
Configuring ACL IP Options Selective Drop 1087
Configuration Examples for ACL IP Options Selective Drop 1088
Example Configuring ACL IP Options Selective Drop 1088
Example Verifying ACL IP Options Selective Drop 1088
Additional References for IP Access List Entry Sequence Numbering 1089
Feature Information for ACL IP Options Selective Drop 1090
CHAPTER 77 ACL Syslog Correlation 1091
Prerequisites for ACL Syslog Correlation 1093
Information About ACL Syslog Correlation 1093
ACL Syslog Correlation Tags 1093
ACE Syslog Messages 1093
How to Configure ACL Syslog Correlation 1094
Enabling Hash Value Generation on a Device 1094
xlix
Contents
Disabling Hash Value Generation on a Device 1095

Configuring ACL Syslog Correlation Using a User-Defined Cookie 1096
Configuring ACL Syslog Correlation Using a Hash Value 1097
Changing the ACL Syslog Correlation Tag Value 1099
Configuration Examples for ACL Syslog Correlation 1100
Example: Configuring ACL Syslog Correlation Using a User-Defined Cookie 1100
Example: Configuring ACL Syslog Correlation using a Hash Value 1101
Example: Changing the ACL Syslog Correlation Tag Value 1101
Additional References for IPv6 IOS Firewall 1102
Feature Information for ACL Syslog Correlation 1102
CHAPTER 78 IPv6 Access Control Lists 1105
Information About IPv6 Access Control Lists 1107
Access Control Lists for IPv6 Traffic Filtering 1107
IPv6 Packet Inspection 1107
Access Class Filtering in IPv6 1107
How to Configure IPv6 Access Control Lists 1107
Configuring IPv6 Traffic Filtering 1107
Creating and Configuring an IPv6 ACL for Traffic Filtering 1107
Applying the IPv6 ACL to an Interface 1109
Controlling Access to a vty 1110
Creating an IPv6 ACL to Provide Access Class Filtering 1110
Applying an IPv6 ACL to the Virtual Terminal Line 1111
Configuration Examples for IPv6 Access Control Lists 1112
Example: Verifying IPv6 ACL Configuration 1112
Example: Creating and Applying an IPv6 ACL 1112
Example: Controlling Access to a vty 1113
Feature Information for IPv6 Access Control Lists 1113
CHAPTER 79 IPv6 Template ACL 1115
l
Contents
Information About IPv6 ACL—Template ACL 1117

IPv6 Template ACL 1117
How to Enable IPv6 ACL—Template ACL 1117
Enabling IPv6 Template Processing 1117
Configuration Examples for IPv6 ACL—Template ACL 1118
Example: IPv6 Template ACL Processing 1118
Feature Information for IPv6 Template ACL 1120
CHAPTER 80 IPv6 ACL Extensions for Hop by Hop Filtering 1121
Information About IPv6 ACL Extensions for Hop by Hop Filtering 1123
ACLs and Traffic Forwarding 1123
How to Configure IPv6 ACL Extensions for Hop by Hop Filtering 1123
Configuring IPv6 ACL Extensions for Hop by Hop Filtering 1123
Configuration Example for IPv6 ACL Extensions for Hop by Hop Filtering 1124
Example: IPv6 ACL Extensions for Hop by Hop Filtering 1124
Feature Information for IPv6 ACL Extensions for Hop by Hop Filtering 1126
PART VIII Application—Voice and Video Configuration 1127
CHAPTER 81 Unique Device Identifier Retrieval 1129
Unique Device Identifier Overview 1131
Benefits of the Unique Device Identifier Retrieval Feature 1131
Retrieving the Unique Device Identifier 1131
Feature Information for Unique Device Identifier Retrieval 1135
CHAPTER 82 Advanced-Mode DOCSIS Set-Top Gateway 1.2 for the Cisco CMTS Routers 1137
Prerequisites for Advanced-Mode DSG Issue 1.2 1139
li
Contents
Restrictions for Advanced-Mode DSG Issue 1.2 1139
DSG Configuration File Transfer Operations 1139

Multicast Configuration Restrictions 1139
NAT for DSG Unicast-only Mapping 1139
PIM and SSM for Multicast 1140
Subinterfaces 1140
Information About Advanced-Mode DSG Issue 1.2 1140
DSG 1.2 Clients and Agents 1140

FQDN Support 1140
DSG Name Process and DNS Query 1141
A-DSG Forwarding on the Primary Channel 1141

DOCSIS 3.0 DSG MDF Support 1141
Source Specific Multicast Mapping 1142
How to Configure Advanced-Mode DSG Issue 1.2 1142
Configuring the Default Multicast Quality of Service 1142

Configuring DSG OPS Under MAC Domain Profile 1143
Configuring Global Tunnel Group Settings for Advanced-Mode DSG 1.2 1145
Global A-DSG 1.2 Tunnel Settings 1145

Adding DSG Tunnel Group to a Subinterface 1147
Configuring the DSG Client Settings for Advanced-Mode DSG 1.2 1147
Configuring Downstream DSG 1.2 Settings for Advanced-Mode DSG 1.2 1149
Configuring IP Multicast Operations 1150

Enabling DNS Query and DSG Name Process 1151
Configuring NAT to Support Unicast Messaging 1152
Configuring WAN Interfaces for Multicast Operations 1154
Configuring a Standard IP Access List for Packet Filtering 1154
Configuring a Standard IP Access List for Multicast Group Filtering 1156
Disabling A-DSG Forwarding on the Primary Channel 1158
How to Monitor and Debug the Advanced-mode DOCSIS Set-Top Gateway Feature 1158
Displaying Global Configurations for Advanced-Mode DSG 1.2 1159
show cable dsg cfr 1159

show cable dsg host 1159
show cable dsg tunnel 1159
show cable dsg tg 1159
lii
Contents
show running-config interface 1160

show cable dsg static-group bundle 1160
Displaying Interface-level Configurations for Advanced-Mode DSG 1.2 1160
show cable dsg tunnel interfaces 1160
show interfaces cable dsg downstream 1160

show interfaces cable dsg downstream dcd 1160
show interfaces cable dsg downstream tg 1161
show interfaces cable dsg downstream tunnel 1161
Debugging Advanced-Mode DSG 1161
Configuration Examples for Advanced-Mode DSG 1161
Example: Enabling DNS Query 1163
Example: Disabling A-DSG Forwarding on the Primary Channel 1164
Feature Information for Advanced-Mode DSG 1.2 for the Cisco CMTS Routers 1164
CHAPTER 83 Cisco Network Registrar for the Cisco CMTS Routers 1167
Servers Required on the HFC Network 1169
Cisco Network Registrar Description 1170
Overview of DHCP Using CNR 1170
How Cisco Converged Broadband Routers and Cable Modems Work 1171
DHCP Fields and Options for Cable Modems 1172
Cisco Network Registrar Sample Configuration 1173
Cable Modem DHCP Response Fields 1175
DOCSIS DHCP Fields 1175
DHCP Relay Option (DOCSIS Option 82) 1176
Overview of Scripts 1176
Two-way Cable Modem Scripts 1176
Telco Return Cable Modem Scripts 1176
Placement of Scripts 1177
Windows NT 1177
Solaris 1177
Activating Scripts in Cisco Network Registrar 1177
Configuring the Cisco CMTS Routers to Use Scripts 1177
liii
Contents
Configuring the System Default Policy 1178

Cable Modems 1178
PCs 1178
Creating Selection Tag Scopes 1178
General 1178
Telco Return for the Cisco cBR-8 Router 1179
Creating Network Scopes 1179
Creating Policies for Class of Service or for Upgrading Cable Modem Cisco IOS Images 1180
CNR Steps to Support Subinterfaces 1180
PART IX PacketCable and PacketCable Multimedia Configuration 1183
CHAPTER 84 PacketCable and PacketCable Multimedia 1185

Restrictions for PacketCable Operations 1187
Information About PacketCable Operations 1187
Emergency 911 Features 1188
PacketCable Emergency 911 Cable Interface Line Card Prioritization 1188
PacketCable Emergency 911 Services Listing and History 1188
PacketCable Network Components 1188
Dynamic Quality of Service 1189
Two-Stage Resource Reservation Process 1190
Making a Call Using DQoS 1190
DQoSLite Based IPv6 Voice Support 1191
Dynamic Service Transaction ID Support 1191
PacketCable Subscriber ID Support 1192
Benefits 1192
How to Configure PacketCable Operations 1193
Enabling PacketCable Operation 1193
Disabling PacketCable Operation 1194
Configuring PacketCable Operation 1195
liv
Contents
Enabling Both PacketCable and Non-PacketCable UGS Service Flows 1196
Enabling PacketCable Subscriber ID Support 1197

Configuring RADIUS Accounting for RKS Servers 1198
PacketCable Client Accept Timeout 1200
Configuration Examples for PacketCable 1201
Example: Typical PacketCable Configuration 1201
Verifying PacketCable Operations 1204
Verifying Emergency 911 Calls 1205
Information About PacketCable Multimedia Operations 1208
PCMM Overview 1208
PCMM Enhancements over PacketCable 1.x 1209
PCMM and High Availability Features on the Cisco CMTS Router 1209
PCMM Gates 1210
PCMM Gate Overview and PCMM Dynamic Quality of Service 1210
PCMM Persistent Gate 1210
PCMM High Priority Calls 1210
PCMM Interfaces 1211
PCMM to COPS Interface 1211
PCMM and Distributed Cable Interface Line Cards 1211
PCMM Unicast and Multicast 1211
PCMM Multicast Session Range 1212
How to Configure PCMM Operations 1212
Enabling PCMM Operations on the Cisco CMTS Router 1212
Configuring a PCMM Multicast Session Range 1213
Configuration Examples for PacketCable Multimedia 1214
Example: Enabling PCMM Operations on the Cisco CMTS Router 1214
Example: Enabling a Multicast Session Range on the Cisco CMTS Router 1215
Verifying PCMM Operations 1215
High Availability Stateful Switchover (SSO) for PacketCable and PacketCable MultiMedia 1217
PacketCable and PCMM with Admission Control 1217
Voice MGPI Support 1217
Voice Support Over DOCSIS 3.0 E-MTAs 1218
PacketCable and PCMM Call Trace 1218
Verifying PacketCable and PCMM Statistics 1218
lv
Contents

Feature Information for PacketCable and PacketCable Multimedia 1221
CHAPTER 85 COPS Engine Operation 1223

Prerequisites for the COPS Engine on the Cisco CMTS Routers 1225
Restrictions for the COPS Engine on the Cisco CMTS 1225
Information About the COPS Engine on the Cisco CMTS 1225
How to Configure the COPS Engine on the Cisco CMTS 1225
Configuring COPS TCP and DSCP Marking 1225
Configuring COPS TCP Window Size 1227
Configuring Access Control List Support for COPS Engine 1228
Restricting RSVP Policy to Specific Access Control Lists 1228
Displaying and Verifying COPS Engine Configuration on the Cisco CMTS 1229
Show Commands for COPS Engine Information 1230
Displaying COPS Servers on the Network 1230
Displaying COPS Policy Information on the Network 1230
Displaying Access Lists for COPS 1230
COPS Engine Configuration Examples for Cable 1230
Example: COPS Server Specified 1231
Example: COPS Server Display 1231

Feature Information for COPS Engine Operation 1232
PART X Quality of Services Configuration 1235
CHAPTER 86 Dynamic Bandwidth Sharing 1237

Information About Dynamic Bandwidth Sharing 1239
How to Configure Dynamic Bandwidth Sharing 1239
Configuring DBS for a Wideband Cable Interface 1239
Configuring DBS for an Integrated Cable Interface 1240
Verifying the Dynamic Bandwidth Sharing Configuration 1240
lvi
Contents

Feature Information for Dynamic Bandwidth Sharing 1244
CHAPTER 87 Modular Quality of Service Command-Line Interface QoS 1245

Restrictions for Applying QoS Features Using the MQC 1247
About 1247
The MQC Structure 1247
Elements of a Traffic Class 1247
Elements of a Traffic Policy 1249
Nested Traffic Classes 1251
match-all and match-any Keywords of the class-map Command 1251
input and output Keywords of the service-policy Command 1252
Benefits of Applying QoS Features Using the MQC 1252
How to Apply QoS Features Using the MQC 1252
Creating a Traffic Class 1252
Creating a Traffic Policy 1254
Attaching a Traffic Policy to an Interface Using the MQC 1255
Verifying the Traffic Class and Traffic Policy Information 1256
Configuration Examples for Applying QoS Features Using the MQC 1257
Creating a Policy Map 1257
Example: Attaching a Traffic Policy to an Interface 1257
Using the match not Command 1258
Configuring a Default Traffic Class 1258
How Commands "class-map match-any" and "class-map match-all" Differ 1258
Establishing Traffic Class as a Match Criterion (Nested Traffic Classes) 1259
Example: Nested Traffic Class for Maintenance 1259
Example: Nested Traffic Class to Combine match-any and match-all Characteristics in One Traffic
Class 1260
Example: Traffic Policy as a QoS Policy (Hierarchical Traffic Policies) 1260
How to Configure Input MQC on the Port-Channel Interfaces 1261
lvii
Contents
Creating a Policy Map 1261

Defining QoS Actions in a Policy Map 1262
Set Actions 1262
Configuring Aggregate Port-Channel Interface 1262
Attaching a Traffic Policy to an Interface 1262
Example: Configuring Input MQC on the Port-Channel Interfaces 1262
Feature Information for Modular Quality of Service Command-Line Interface QoS 1264
CHAPTER 88 DOCSIS 1.1 for the Cisco CMTS Routers 1265
Prerequisites for DOCSIS 1.1 Operations 1267
Restrictions for DOCSIS 1.1 Operations 1267
Information about DOCSIS 1.1 1269
Baseline Privacy Interface Plus 1270

Concatenation 1270
Dynamic MAC Messages 1270
Enhanced Quality of Service 1271
Fragmentation 1271
Interoperability 1272
Payload Header Suppression 1272
Downstream ToS Overwrite 1272
DOCSIS 1.1 Quality of Service 1273
Service Flow 1273
Service Class 1274
Packet Classifiers 1274
Packet Header Suppression Rules 1275
Quality of Service Comparison 1275
Enhanced Rate Bandwidth Allocation (ERBA) Support for DOCSIS 1.0 Cable Modems 1277
DOCSIS 3.0 Downstream Peak Traffic Rate TLV Support for ERBA 1278
Suppressing Upstream and Downstream Peak Rate TLVs for pre DOCSIS 3.0 Cable Modems 1279
Downstream Classification Enhancement with MAC Addresses 1280
Benefits 1280
How to Configure the Cisco CMTS for DOCSIS 1.1 Operations 1282
lviii
Contents
Configuring Baseline Privacy Interface 1282
Downloading the DOCSIS Root Certificate to the CMTS 1285
Adding a Manufacturer’s Certificate as a Trusted Certificate 1287
Adding a Certificate as a Trusted Certificate Using SNMP Commands 1287

Adding a Manufacturer’s or CM Certificate to the Hotlist 1289
Adding a Certificate to the Hotlist Using SNMP Commands 1289
Enabling Concatenation 1290
Enabling DOCSIS Fragmentation 1291
Enabling DOCSIS 1.1 Downstream Maximum Transmit Burst on the Cisco cBR-8 Router 1293
Monitoring DOCSIS Operations 1294
Monitoring the DOCSIS Network 1294
Displaying the Status of Cable Modems 1294
Displaying a Summary Report for the Cable Modems 1296
Displaying the Capabilities of the Cable Modems 1296
Displaying Detailed Information About a Particular Cable Modem 1297
Monitoring the RF Network and Cable Interfaces 1297
Displaying Information About Cloned Cable Modems 1297
Denying RF Access For Cable Modems 1297
Displaying Information About the Mac Scheduler 1297
Displaying Information About QoS Parameter Sets 1297
Displaying Information About Service Flows 1298
Displaying Information About Service IDs 1298
Monitoring BPI+ Operations 1298
Displaying the Current BPI+ State of Cable Modems 1298
Displaying the BPI+ Timer Values on the CMTS 1299
Displaying the Certificate List on the CMTS 1299
Configuration Examples for DOCSIS 1.1 Operations 1300
Example: DOCSIS 1.1 Configuration for Cisco cBR-8 Router (with BPI+) 1300
Feature Information for DOCSIS 1.1 for Cisco CMTS Routers 1304
CHAPTER 89 Default DOCSIS 1.0 ToS Overwrite 1305
Restrictions for Default DOCSIS 1.0 ToS Overwrite 1306
lix
Contents
Information About Default DOCSIS 1.0 ToS Overwrite 1307

Default DOCSIS 1.0 ToS Overwrite Overview 1307
DOCSIS 1307
Type-of-Service (ToS) 1307
How to Configure Default DOCSIS 1.0 ToS Overwrite 1308
Enabling Default DOCSIS 1.0 ToS Overwrite 1308
Editing QoS Profiles 1309
Feature Information for Default DOCSIS 1.0 ToS Overwrite 1310
CHAPTER 90 DOCSIS WFQ Scheduler on the Cisco CMTS Routers 1311

Prerequisites for DOCSIS WFQ Scheduler 1312
Restrictions for DOCSIS WFQ Scheduler 1313
Information About DOCSIS WFQ Scheduler 1313
Queue Types 1314
Priority Queues 1314
CIR Queues 1314
Best Effort Queues 1314
DOCSIS QoS Support 1315
Traffic Priority 1315
Maximum Sustained Traffic Rate 1316
Minimum Reserved Traffic Rate 1316
High Priority Traffic 1316
Enhanced Rate Bandwidth Allocation 1317
Peak Traffic Rate 1317
DOCSIS 3.0 Downstream Bonding Support with Bonding Group Dynamic Bandwidth Sharing 1318
How to Configure DOCSIS WFQ Scheduler 1319
Mapping DOCSIS Priority to Excess Ratio 1319

Verifying the Downstream Queues Information 1320
Feature Information for DOCSIS WFQ Scheduler 1320
CHAPTER 91 Fairness Across DOCSIS Interfaces 1321
lx
Contents
Prerequisites for Fairness Across DOCSIS Interfaces 1323
Restrictions for Fairness Across DOCSIS Interfaces 1323

Information About Fairness Across DOCSIS Interfaces 1323
On-demand CIR Acquisition 1324
Fairness Across Bonding Groups 1324
OFDM Channels 1324
Interface Bandwidth 1324
How to Configure Fairness Across DOCSIS Interfaces 1325
Configuring Fairness Across DOCSIS Interfaces 1325
Configuring Maximum Excess Information Rate Ratio 1325
Configuring Constant Excess Information Rate Demand 1326
Configuring Maximum Bonus Bandwidth 1327
Verifying the Fairness Across DOCSIS Interfaces 1328
Verifying Reservable Bandwidth 1328
Verifying Global Fairness Across DOCSIS Interfaces Status and Statistics 1330
Verifying Per-Controller Fairness Across DOCSIS Interfaces Status and Statistics 1330
Verifying Per-Interface Fairness Across DOCSIS Interfaces Status and Statistics 1331
Configuration Examples for Fairness Across DOCSIS Interfaces 1331
Example: Fairness Across DOCSIS Interfaces 1331
Example: Maximum EIR Demand Ratio 1331
Example: Constant EIR Demand 1332
Example: Maximum Bonus Bandwidth 1332
Feature Information for Fairness Across DOCSIS Interfaces 1333
CHAPTER 92 Service Group Admission Control 1335

Restrictions for Service Group Admission Control 1336
Information About Service Group Admission Control 1337
Overview 1337
SGAC and Downstream Bandwidth Utilization 1337
Categorization of Service Flows 1337
lxi
Contents
Thresholds for Downstream Bandwidth 1338

Overview of Bonding Group Admission Control 1338
How to Configure, Monitor, and Troubleshoot Service Group Admission Control 1339
Defining Rules for Service Flow Categorization 1339
Naming Application Buckets 1341
Preempting High-Priority Emergency 911 Calls 1341
Calculating Bandwidth Utilization 1343
Enabling SGAC Check 1343
Configuration Examples for SGAC 1344
Example: SGAC Configuration Commands 1344
Example: SGAC for Downstream Traffic 1346
Feature Information for Service Group Admission Control 1348
CHAPTER 93 Subscriber Traffic Management 1349
Restrictions for Subscriber Traffic Management on the Cisco CMTS Routers 1351
Information About Subscriber Traffic Management on the Cisco CMTS Routers 1352
Feature List 1352
Sliding Window for Monitoring Service Flows 1353
Weekend Monitoring 1354
SNMP Trap Notifications 1354
Cable Modem Interaction with the Subscriber Traffic Management Feature 1356
How to Configure the Subscriber Traffic Management Feature on the Cisco CMTS Routers 1357
Creating and Configuring an Enforce-Rule 1357
Examples 1359
Configuring Weekend Monitoring 1361
Prerequisites 1361
Restrictions 1361
Configuring Different Legacy Monitoring Conditions for Weekends 1361
Configuring Different Peak-Offpeak Monitoring Conditions for Weekends 1362
Disabling Weekend Monitoring 1363
Removing Weekend Monitoring Conditions and Use the Same Monitoring Criteria Every Day 1364
lxii
Contents
Disabling an Enforce-Rule 1365

Removing an Enforce-Rule 1365
Changing a Cable Modem Service Class 1366
Monitoring the Subscriber Traffic Management Feature on the Cisco CMTS Routers 1367
Displaying the Currently Defined Enforce-Rules 1367
Displaying the Current Subscriber Usage 1369
Configuration Examples for Subscriber Traffic Management on the Cisco CMTS Routers 1370
Example: DOCSIS Configuration File and STM Service Classes 1370
Example: Downstream Configuration 1372
Example: Upstream Configuration 1372

Example: Downstream and Upstream Configuration 1372
Example: Weekend Monitoring Configuration 1373

Feature Information for Subscriber Traffic Management 1375
CHAPTER 94 Narrowband Digital Forward And Narrowband Digital Return 1377
Information About NDF and NDR 1379
Restrictions for Configuring NDF and NDR 1379
1x2 RPD 1379
2x2 RPD 1379
Configure NDF and NDR 1380
Configure Static-Pseudowires for NDF and NDR 1380
Configure NDF and NDR Profile 1383
Bind NDF Static-Pseudowire and NDF Profile with Rf-Port 1384
Bind NDR Static-Pseudowire and NDR Profile with Rf-Port 1384
Display TLV Status 1384
Example: NDF Configuration 1386
Example: NDR Configuration 1386
Feature Information for Narrowband Digital Forward And Narrowband Digital Return 1387
CHAPTER 95 Differentiated Services Code Point Downstream 1389
Information About Differentiated Services Code Point Downstream Marking 1389

Feature Information for Differentiated Services Code Point Downstream Marking 1390
lxiii
Contents
PART XI Security and Cable Monitoring Configuration 1391
CHAPTER 96 Dynamic Shared Secret 1393
Prerequisites for Dynamic Shared Secret 1395
Restrictions for Dynamic Shared Secret 1395
General Restrictions for Dynamic Shared Secret 1395
Cable Modem Restrictions for Dynamic Shared Secret 1396
DHCP Restriction for Incognito Server and Thomson Cable Modems 1396
DOCSIS Compliance 1397
TFTP Restrictions 1398
Information About Dynamic Shared Secret 1399
Operation of the Dynamic Shared Secret 1400
Interaction with Different Commands 1401
Performance Information 1401
SNMP Support 1402
System Error Messages 1402
Benefits 1403
Related Features 1404
How to Configure the Dynamic Shared Secret Feature 1405
Enabling and Configuring the Dynamic Shared Secret Feature 1405
Disabling the Dynamic Shared Secret on a Cable Interface 1407
Excluding Cable Modems from the Dynamic Shared Secret Feature 1408
Clearing the Lock on One or More Cable Modems 1409
Upgrading Firmware on the Cable Modems 1410
How to Monitor the Dynamic Shared Secret Feature 1411
Displaying Marked Cable Modems 1411
Displaying the Current Dynamic Secrets 1412
Troubleshooting Cable Modems with Dynamic Shared Secret 1414
Configuration Examples for Dynamic Shared Secret 1415
Mark Configuration: Example 1415
Lock Configuration: Example 1416
lxiv
Contents
Reject Configuration: Example 1416

Disabled Configuration: Example 1417
Feature Information for Dynamic Shared Secret 1418
CHAPTER 97 Lawful Intercept Architecture 1419
Prerequisites for Lawful Intercept 1421
Restrictions for Lawful Intercept 1421
Information About Lawful Intercept 1422
Introduction to Lawful Intercept 1422
Cisco Service Independent Intercept Architecture 1422
PacketCable Lawful Intercept Architecture 1422
Cisco cBR Series Routers 1423
VRF Aware LI 1424
Lawful Intercept- Redundant Mediation Devices 1424
Lawful Intercept MIBs 1424
Restricting Access to the Lawful Intercept MIBs 1424
Service Independent Intercept 1425
Restricting Access to Trusted Hosts (without Encryption) 1425
How to Configure Lawful Intercept 1426
Creating a Restricted SNMP View of Lawful Intercept MIBs 1426
Where to Go Next 1427
Enabling SNMP Notifications for Lawful Intercept 1427
Disabling SNMP Notifications 1428
Provisioning a MAC Intercept for Cable Modems Using SNMPv3 1429
Provisioning a MAC Intercept for a CPE Device Using SNMPv3 1429
Configuration Examples for Lawful Intercept 1430
Example: Enabling Mediation Device Access Lawful Intercept MIBs 1430
Example: Configuring Lawful Intercept- Redundant Mediation Devices 1430
Feature Information for Lawful Intercept 1432
CHAPTER 98 Cable Monitoring Feature for Cisco cBR Series Routers 1433
lxv
Contents
Overview of Cable Monitor Command for cBR 1434

Configuring Cable Monitoring for cBR Routers 1434
Capturing Sniffed Packets 1436
Capturing Sniffed Packets on an External Host 1436
Capturing Sniffed Packets on a Local Hard Drive 1437
Cable Monitor Packet Struct 1439
Feature Information for Cable Monitoring 1439
CHAPTER 99 Source-Based Rate Limit 1441
Prerequisites for Source-Based Rate Limit 1442
Restrictions for Source-Based Rate Limit 1443
Information About Source-Based Rate Limit 1443
How to Configure Source-Based Rate Limit 1443
Configuring WAN-Side Source-Based Rate Limit 1444
Configuring Control Plane Policing 1444
Enabling WAN-Side Source-Based Rate Limit 1446
Configuring WAN-Side Quarantine 1446
Configuring Subscriber-Side Source-Based Rate Limit 1447

Configuring Source-Based Rate Limit Ping-Bypass 1449
Configuring SNMP RX Queuing 1449
Configuring Punt Policing 1450
Verifying the Source-Based Rate Limit Configuration 1451
Configuration Example for Source-Based Rate Limit 1455
Default SBRL Configuration 1456
Conversion of SBRL Subscriber-side Configuration from 16.8.x to 16.9.x 1456
Conversion of Divert Rate Limit Configuration on the Cisco uBR10012 Router to SBRL Configuration
on the Cisco cBR Series Routers 1457
Feature Information for Source-Based Rate Limit 1460
CHAPTER 100 Cable Duplicate MAC Address Reject 1463
Prerequisites for Cable Duplicate MAC Address Reject 1465
lxvi
Contents
Restrictions for Cable Duplicate MAC Address Reject 1465

Information About Cable Duplicate MAC Address Reject 1465
Early Authentication and Encryption 1466
EAE Enforcement Policies 1466

EAE Exclusion 1466
BPI+ Security and Cloned Cable Modems 1466
Logging of Cloned Cable Modems 1467
DOCSIS 3.0 BPI+ Policy Enforcement 1467
BPI+ Policy Enforcement Exclusion 1468
How to Configure EAE and BPI+ Enforcement Features 1468
Configuring EAE Enforcement Policies 1468
Configuring BPI+ Enforcement Policies 1469
Configuring AES-128 for non-MTC DOCSIS3.0 Cable Modem 1470
Verifying AES-128 for non-MTC DOCSIS3.0 Cable Modem 1470

Configuration Example for EAE and BPI+ Enforcement Policies 1471
Verifying EAE and BPI+ Enforcement Policies 1471
System Messages Supporting Cable Duplicate MAC Address Reject 1472
Feature Information for Cable Duplicate MAC Address Reject 1473
CHAPTER 101 Cable ARP Filtering 1475

Restrictions for Cable ARP Filtering 1477
Cable ARP Filtering 1477
Overview 1478
Filtering ARP Traffic 1478
Monitoring Filtered ARP Traffic 1479
ARP Autoreply 1479
Linksys Wireless-Broadband Router (BEFW11S4) 1479
ARP Filtering in FP 1480
Filtering ARP Traffic in FP 1480
How to Configure Cable ARP Filtering 1481
lxvii
Contents
Monitoring ARP Processing 1481

Configure ARP Autoreply 1482
Configure ARP Filter Without ARP Autoreply 1484
Enabling ARP Filtering 1484
Identifying the Sources of Major ARP Traffic 1485
Examples 1488
Clearing the Packet Counters 1488
Identifying ARP Offenders in FP 1489
cBR-8 Outputs in FP 1489
Configuration Examples for Cable ARP Filtering 1490

ARP Filtering Configuration on an Individual Cable Interface: Example 1490
ARP Filtering Configuration on Bundled Cable Interfaces: Example 1491
ARP Filtering in FP Default Configuration: Example 1492
Feature Information for Cable ARP Filtering 1493
CHAPTER 102 Subscriber Management Packet Filtering Extension for DOCSIS 2.0 1495
Prerequisites for Configuring Subscriber Management Packet Filtering 1497
Restriction for Configuring Subscriber Management Packet Filtering 1497
Information About Configuring Subscriber Management Packet Filtering 1497
How to Configure Subscriber Management Packet Filtering 1498
Configuring the Filter Group 1498
Defining the Upstream and Downstream MTA Filter Group 1499
Defining the Upstream and Downstream STB Filter Group 1499
Defining the Upstream and Downstream PS Filter Group 1500
Configuration Examples for Subscriber Management Packet Filtering 1501
Configuring the Filter Group: Example 1501
Defining the Upstream and Downstream MTA Filter Group: Example 1501
Defining the Upstream and Downstream STB Filter Group: Example 1501
Defining the Upstream and Downstream PS Filter Group: Example 1501
Feature Information for Subscriber Management Packet Filtering 1502
lxviii
Contents
CHAPTER 103 MAC Filtering 1503
Information About MAC Filtering 1505
How to Configure MAC Filtering 1505
Configuring MAC Filtering 1505
Verifying MAC Filtering 1505
Configuration Examples for MAC Filtering 1508
Feature Information for MAC Filtering 1508
PART XII Troubleshooting and Network Management Configuration 1509
CHAPTER 104 Call Home 1511
Prerequisites for Call Home 1513
Restrictions for Call Home 1513
Information About Call Home 1513
Benefits of Call Home 1514
Obtaining Smart Call Home Services 1514
Anonymous Reporting 1515
Smart Licensing 1515
How to Configure Call Home 1516
Configuring Smart Call Home (Single Command) 1516
Configuring Call Home 1517
Enabling and Disabling Call Home 1517
Configuring Contact Information 1518

Configuring Destination Profiles 1519
Subscribing to Alert Groups 1524
Configuring General Email Options 1529
Sending Call Home Messages Manually 1534
Configuring Diagnostic Signatures 1538
Prerequisites for Diagnostic Signatures 1538
Information About Diagnostic Signatures 1539
Diagnostic Signature Overview 1539
lxix
Contents
Diagnostic Signature Downloading 1539

Diagnostic Signature Signing 1540
Diagnostic Signature Workflow 1540
Diagnostic Signature Events and Actions 1541
How to Configure Diagnostic Signatures 1543
Configuring the Service Call Home for Diagnostic Signatures 1543
Configuring Diagnostic Signatures 1545
Verifying the Call Home Configuration 1546
Configuration Example for Call Home 1550
Example: Call Home Configuration 1550
Example: Configuring HTTP Transport for Call Home on the Cisco cBR Series Router 1551
Example: Configuring Email Transport for Call Home on the Cisco cBR Series Router 1553
Default Settings 1556
Alert Groups Trigger Events and Commands 1557
Message Contents 1561
Sample syslog Alert Notification in XML Format 1565
Feature Information for Call Home 1575
CHAPTER 105 SNMP Support over VPNs—Context-Based Access Control 1577

Restrictions for SNMP Support over VPNs—Context-Based Access Control 1579
Information About SNMP Support over VPNs—Context-Based Access Control 1579
SNMP Versions and Security 1579
SNMPv1 or SNMPv2 Security 1579
SNMPv3 Security 1580
SNMP Notification Support over VPNs 1580
VPN-Aware SNMP 1580
VPN Route Distinguishers 1581
SNMP Contexts 1581
How to Configure SNMP Support over VPNs—Context-Based Access Control 1582
Configuring an SNMP Context and Associating the SNMP Context with a VPN 1582
Configuring SNMP Support and Associating an SNMP Context 1583
lxx
Contents
Configuration Examples for SNMP Support over VPNs—Context-Based Access Control 1585
Example: Configuring Context-Based Access Control 1585
Feature Information for SNMP Support over VPNs—Context-Based Access Control 1588
CHAPTER 106 SNMP Engine Enhancement 1589

Restrictions for SNMP Cache Engine Enhancement 1590
Information About SNMP Cache Engine Enhancement 1591
How to Configure SNMP Cache Engine Enhancement 1591
Verifying the SNMP Cache Engine Status 1592
Feature Information for SNMP Cache Engine Enhancement 1593
CHAPTER 107 Onboard Failure Logging 1595

Understanding OBFL 1597
Configuring OBFL 1597
Displaying OBFL Logging Information 1597
Clearing OBFL Logging 1598
Configuration and Verification Examples 1598
Feature Information for Onboard Failure Logging 1604
CHAPTER 108 Control Point Discovery 1607
Prerequisites for Control Point Discovery 1608
Restrictions for Control Point Discovery 1609
Information About Control Point Discovery 1609
Control Points 1609
Network Layer Signaling (NLS) 1609
NLS for CPD 1609
Control Point Discovery 1610
CPD Protocol Hierarchy 1610
lxxi
Contents
Control Relationship 1611

How to Configure CPD 1611
Enabling CPD Functionality 1611
Examples for CPD Enable 1612
Debugging CPD Functionality 1612
Configuring Control Relationship Identifier 1612
Examples 1613
Enabling NLS Functionality 1613
Examples 1614
Debugging NLS Functionality 1614
Configuring Authorization Group Identifier and Authentication Key 1614
Examples 1615
Configuring NLS Response Timeout 1615
Examples 1616
Feature Information for Control Point Discovery 1616
CHAPTER 109 IPDR Streaming Protocol 1619
Restrictions for Configuring IPDR Streaming Protocol 1619

Information About IPDR Streaming Protocol 1620
Data Collection Methodologies 1620
How to Configure IPDR Streaming Protocol 1621
Configuring the IPDR Session 1621
Configuring the IPDR Type 1622
Configuring the IPDR Collector 1622
Configuring the IPDR Associate 1623
Configuring the IPDR Template 1623
Configuring the IPDR Exporter 1624
Configure IPDR in IPv6 Mode 1625
Start IPDR connection by CMTS 1626
Configuration Examples for IPDR Streaming Protocol 1626
Example: Configuring the IPDR Session 1626
Example: Configuring the IPDR Type 1626

Example: Configuring the IPDR Collector 1626
lxxii
Contents
Example: Configuring the IPDR Associate 1627

Example: Configuring the IPDR Template 1627
Example: Configuring the IPDR Exporter 1627
Verifying IPDR Streaming Protocol 1627
Verifying the IPDR Collector 1627
Verifying IPDR exporter 1628
Verifying IPDR session 1628
Verifying IPDR Session Collector 1628
Verifying IPDR Session Template 1629
Feature Information for IPDR Streaming Protocol 1629
CHAPTER 110 Usage-Based Billing (SAMIS) 1631
Prerequisites for Usage-Based Billing (SAMIS) 1632
Restrictions for Usage-based Billing 1633
Information About Usage-based Billing 1634
Usage-Based Billing and DOCSIS Support on the Cisco CMTS Routers 1635
Standards 1635
IPDR Service Definition Schemas 1635
IPDR Schema List for DOCSIS 3.0 1635
IPDR Schema List for DOCSIS 3.1 1639

Billing Record Format 1642
SNMP Support 1645
Benefits 1646
How to Configure the Usage-based Billing Feature 1646
Enabling Usage-based Billing Feature File Mode Using CLI Commands 1646
Enabling Usage-based Billing Feature File Mode Using SNMP Commands 1648
Examples for Enabling Usage Billing using SNMP Mode 1650
Enabling Usage-based Billing Feature Streaming Mode Using CLI Commands 1651
Enabling Usage-based Billing Feature Streaming Mode Using SNMP Commands 1653
Examples for SNMP Commands 1656
lxxiii
Contents
Enabling and Configuring the Secure Copy Protocol (optional) 1657

Configuring the Cisco CMTS for SSL Operation 1659
Prerequisites for CA 1659
Retrieving Records from a Cisco CMTS in File Mode 1660
Using SCP 1661
Using TFTP 1661
Using SNMP 1662
Using SNMP 1666
Examples To Transfer Using SNMP 1667
Disabling the Usage-based Billing Feature 1668

Configuring Certified SSL Servers for Usage-Based Billing 1670
Generating SSL Server Certification 1670
Configuring and Testing the Cisco CMTS for Certified SSL Server Support 1670
Monitoring the Usage-based Billing Feature 1672
Configuration Examples for Usage-based Billing 1673
File Mode Configuration (with Secure Copy) 1673
Non-Secure Streaming Mode Configuration 1674
Secure Streaming Mode Configuration 1674
CHAPTER 111 Frequency Allocation Information for the Cisco CMTS Routers 1675
Frequency Allocation for the Cisco CMTS Routers 1675
CHAPTER 112 Flap List Troubleshooting 1687

Prerequisites for Flap List Troubleshooting 1689
Restrictions for Flap List Troubleshooting 1689
Information About Flap List Troubleshooting 1689
Information in the Flap List 1690
Cisco Cable Manager and Cisco Broadband Troubleshooter 1691
Benefits 1691
How to Configure Flap List Troubleshooting 1692
Configuring Flap List Operation Using the CLI (optional) 1692
lxxiv
Contents
Clearing the Flap List and Counters Using the CLI (optional) 1693
Enabling or Disabling Power Adjustment Using the CLI (optional) 1694
Configuring Flap List Operation Using SNMP (optional) 1696
Clearing the Flap List and Counters Using SNMP (optional) 1697
How to Monitor and Troubleshoot Using Flap Lists 1697
Displaying the Flap List Using the show cable flap-list Command 1697
Displaying the Flap List Using the show cable modem flap Command 1698
Displaying the Flap List Using SNMP 1699
Displaying Flap-List Information for Specific Cable Modems 1700
Example 1700
Troubleshooting Suggestions 1701
Performing Amplitude Averaging 1702
Using Other Related Commands 1702
Configuration Examples for Flap List Troubleshooting 1704
Feature Information for Flap List Troubleshooting 1705
CHAPTER 113 Maximum CPE and Host Parameters 1707

Information About the MAX CPE and Host Parameters 1709
MAX CPE 1709
MAX Host 1710
Specifying an Unlimited Value for Max Host 1711
MAX CPE IP 1711
MAX CPE IPv6 1711
Interoperation of the Maximum CPE Parameters 1712
Benefits 1712
How to Configure the MAX CPE and Host Parameters 1712
Configuring the Maximum Number of CPE Devices on the Cisco CMTS 1713
Feature Information for Maximum CPE and Host Parameters 1716
lxxv
Contents
CHAPTER 114 SNMP Background Synchronization 1717
Information About SNMP Background Synchronization 1717

How to Configure SNMP Background Synchronization 1718
Enabling SNMP Background Synchronization 1718
Setting Data Interval 1718
Verifying SNMP Background Synchronization 1719
Configuring Example for SNMP Background Synchronization 1725
Feature Information for SNMP Background Synchronization 1725
CHAPTER 115 Online Offline Diagnostics 1727
Overview of Online Offline Diagnostics 1727

Benefits of Online Offline Diagnostics 1727
Prerequisites for Online Offline Diagnostics 1728
Restrictions for Online Offline Diagnostics 1728
How to Configure Online Offline Diagnostics 1728

Configuring Field Diagnostic Test 1728
Verifying the Testing Process 1728
Removing the Field Diagnostic Image from a Line Card 1729
Configuration Example for Online Offline Diagnostics 1729
Feature Information for Online Offline Diagnostics 1729
lxxvi
PA R T I
Basic Configuration
• Start Up Configuration of the Cisco cBR Router, on page 1
• Cisco Smart Licensing, on page 37
• Core Peak Bandwidth Licensing, on page 67
• Capped License Enforcement, on page 71
• Consolidated Packages and SubPackages Management, on page 77
• Support for 2x100G DPIC, on page 109
• G.8275.2 Telecom Profile, on page 117
• Model-Driven Telemetry, on page 129
CHAPTER 1
Start Up Configuration of the Cisco cBR Router
This document describes the basic start up configuration tasks that must be completed on a Cisco cBR Series
Converged Broadband Router.
• Prerequisites for Configuring the Cisco CMTS, on page 2
• Booting and Logging onto the Cisco CMTS , on page 3
• First Time Boot Up with ROMMON, on page 3
• Configuration Register, on page 4
• Setting Environment Variables, on page 5
• Unsetting Environment Variables, on page 5
• Booting from the TFTP on the Cisco cBR, on page 6
• Listing Supported Devices, on page 6
• Booting from the Device on the Cisco cBR, on page 7
• Setting AUTOBOOT image in ROMMON, on page 7
• Verifying the ROMMON Version, on page 8
• Resetting the Cisco cBR, on page 8
• Configuring PTP, on page 9
• File Systems, on page 15
• Verification of Hardware Bring Up, on page 16
• Gigabit Ethernet Management Interface Overview, on page 24
• Gigabit Ethernet Port Numbering, on page 24
• IP Address Handling in ROMMON and the Management Ethernet Port, on page 24
• Gigabit Ethernet Management Interface VRF, on page 25
• Common Ethernet Management Tasks, on page 25
• Viewing the VRF Configuration, on page 25
• Setting a Default Route in the Management Ethernet Interface VRF, on page 26
• Setting the Management Ethernet IP Address, on page 26
• Telnetting over the Management Ethernet Interface, on page 26
• Pinging over the Management Ethernet Interface, on page 26
• Copy Using TFTP or FTP, on page 27
• NTP Server, on page 27
• SYSLOG Server, on page 27
• SNMP-Related Services, on page 27
• Domain Name Assignment, on page 27
• DNS service, on page 28
1
Basic Configuration
Prerequisites for Configuring the Cisco CMTS
• RADIUS or TACACS+ Server, on page 28

• VTY lines with ACL, on page 28
• Configuring the AUX Port for Network Management , on page 28
• Preprovisioning the Supervisor in the Cisco cBR Chassis, on page 29
• Configuring the Gigabit Ethernet Interface for Network Management, on page 29
• Configuring the DTI Port on the Supervisor PIC, on page 30
• Configuring the TenGigabit Ethernet Interface for Network Management , on page 31
• Connecting the New Router to the Network , on page 32
• Setting Password Protection on the Cisco CMTS, on page 33
• Recovering Lost Password on the Cisco CMTS, on page 33
• Saving Your Configuration Settings, on page 35
• Reviewing Your Settings and Configurations, on page 36
• Recovering Unresponsive Modems, on page 36
Prerequisites for Configuring the Cisco CMTS

Complete these prerequisite steps before you power on and configure the Cisco CMTS:
• Ensure that your network supports reliable broadband data transmission. Your plant must be swept,
balanced, and certified based on National Television Standards Committee (NTSC) or appropriate
international cable plant recommendations. Ensure your plant meets all Data-over-Cable Service Interface
Specifications (DOCSIS) downstream and upstream radio frequency (RF) requirements.
• Ensure that your Cisco CMTS is installed according to the instructions in the hardware installation guide
available on Cisco.com.
• Ensure that all other required headend or distribution hub routing and network interface equipment is
installed, configured, and operational (based on the supported services). This includes:
• All routers
• Servers ( Dynamic Host Configuration Protocol (DHCP) servers, Trivial File Transfer Protocol (
TFTP) servers, and time-of-day (ToD) servers)
• Network management systems
• Other configuration or billing systems
• Ensure that DHCP and DOCSIS configuration files have been created and pushed to appropriate servers
so that each CM, when initialized, can:
• Transmit a DHCP request
• Receive an IP address
• Obtain TFTP and ToD server addresses
• Download a DOCSIS configuration file (or updated software image if using Cisco uBR924 cable
access routers or Cisco uBR910 cable data service units (DSUs) in your network)
• Ensure that customer premises equipment (CPE)—CMs or set-top boxes (STBs), PCs, telephones, or
facsimile machines—meet requirements for your network and service offerings.
• Be familiar with your channel plan to assign appropriate frequencies. Outline your strategies for setting
up bundling, if applicable to your headend or distribution hub. As appropriate, obtain:
• Passwords
• IP addresses
• Subnet masks
2
Basic Configuration
Booting and Logging onto the Cisco CMTS
• Device names
After these prerequisites are met, you are ready to configure the Cisco CMTS. This includes, at a minimum:
• Configuring a host name and password for the Cisco CMTS
• Configuring the CMTS to support IP over the cable plant and network backbone
Note If you plan to use service-class-based provisioning, the service classes must be configured at the CMTS before
CMs attempt to make a connection.
Note Do not configure the logging event link-status command during system initialization. It may take long time
or even stop the standby SUP from booting up.
Booting and Logging onto the Cisco CMTS

The Cisco CMTS is administered using the Cisco command interpreter, called the EXEC. You must boot and
log in to the router before you can enter an EXEC command.
Step 1 Connect to the console port on the Supervisor PIC and the Supervisor card.
Step 2 Establish a terminal session. You can open terminal application (Hyper Terminal) on a PC as follows:
a) Connect using: Direct to Com 1
b) Set bits per second:9600
c) Set data bits: 8
d) Set parity: none
e) Set stop bit: 1
f) Set flow control: none
Type no when the following message is displayed:
Would you like to enter the initial dialog?[yes]: no

Router>
First Time Boot Up with ROMMON

The Cisco cBR-8 boots up with ROMMON on the console with 9600 baud default configuration. It boots
image either from TFTP or from local device. Local devices supported include the bootflash and USB.
Example of the boot up display:
Initializing Hardware ...ˇ
3
Basic Configuration
Configuration Register
System Bootstrap, Version 15.5(2r)S, RELEASE SOFTWARE

Copyright (c) 1994-2015 by cisco Systems, Inc.
Current image running: Boot ROM0
Last reset cause: PowerOn
CPUID: 0x000206d7
UCODE: 0x00000710_00000000
Viper version register: 0x14121111
Set Chassis Type to 13RU
Cisco cBR-8 platform with 50331648 Kbytes of main memory
rommon 1 >
Configuration Register
The confreg ROMMON command displays the configuration and allows modification of the settings.
rommon > confreg
Configuration Summary
(Virtual Configuration Register: 0x0)
enabled are:
[ 0 ] break/abort has effect
[ 1 ] console baud: 9600
boot: ...... the ROM Monitor
do you wish to change the configuration? y/n [n]: y

enable "diagnostic mode"? y/n [n]:
enable "use net in IP bcast address"? y/n [n]:
enable "load rom after netboot fails"? y/n [n]:
enable "use all zero broadcast"? y/n [n]:
disable "break/abort has effect"? y/n [n]:
enable "ignore system config info"? y/n [n]:
change console baud rate? y/n [n]:
change the boot characteristics? y/n [n]:
enabled are:
do you wish to change the configuration? y/n [n]:
Console baud rate options:
change console baud rate? y/n [n]: y
0=9600, 1=4800, 2=1200, 3=2400, 4=19200, 5=38400, 6=57600, 7=115200
enter rate [0]:
Boot characteristics options:
change the boot characteristics? y/n [n]: y
enter to boot:
0 = ROM Monitor
1 = the boot helper image
2-15 = boot system
[0]:
4
Basic Configuration
Setting Environment Variables
Setting Environment Variables

No Environment variables are required to boot the Cisco IOS-XE image.
There are variables set by default. The ROMMON command set displays the default variables.
rommon > set

PS1=rommon ! >
?=0
rommon >
To set a variable, the format is VARIABLE="value".

Theset command displays the new variable and the sync command saves the variable to NVRAM.
Note If the variable value has a space in between, specify the value within quotes.
rommon > set

PS1=rommon ! >
?=0
rommon > IP_ADDRESS=1.2.3.4
rommon > IP_SUBNET_MASK=255.255.255.128
rommon > DEFAULT_GATEWAY=1.2.9.10
rommon > TFTP_SERVER=1.2.3.6
rommon > sync
Unsetting Environment Variables

The unset ROMMON command removes the Environment variables and the sync command saves the variable
to NVRAM.
rommon 1 > set

PS1=rommon ! >
?=0
BSI=0
BOOT=bootflash:cbrsup-adventerprisek9.SSA.bin,12;
RANDOM_NUM=1357042312
RET_2_RTS=17:45:06 PDT Sat Dec 31 2011
RET_2_RCALTS=1325378706
rommon 2 > unset BOOT
rommon 3 > sync
rommon 4 > set
PS1=rommon ! >
?=0
BSI=0
RANDOM_NUM=1357042312
RET_2_RTS=17:45:06 PDT Sat Dec 31 2011
RET_2_RCALTS=1325378706
rommon 5 >
5
Basic Configuration
Booting from the TFTP on the Cisco cBR
Booting from the TFTP on the Cisco cBR

ROMMON boots up with default environment variables. The BinOS image is booted up from TFTP over the
management port. This requires a minimum set of environment variables: IP_ADDRESS, IP_SUBNET_MASK,
DEFAULT_GATEWAY, and TFTP_SERVER.
Step 1 Type the set command and define the required environment variables.
rommon > set

PS1=rommon ! >
?=0
rommon > IP_ADDRESS=1.2.3.4
rommon > IP_SUBNET_MASK=255.255.255.128
rommon > DEFAULT_GATEWAY=1.2.9.10
rommon > TFTP_SERVER=1.2.3.6
rommon > sync
Step 2 Type the sync command to save the variables to NVRAM.

rommon 6 > sync
Step 3 Type the boot command to load the image.
rommon 7 > boot tftp:/tftpboot/username/cbrsup-universalk9.SSA.bin
IP_ADDRESS: 1.2.3.4
IP_SUBNET_MASK: 255.255.255.128
DEFAULT_GATEWAY: 1.2.9.10
TFTP_SERVER: 1.2.3.6
TFTP_FILE: /tftpboot/username/cbrsup-universalk9.SSA.bin
TFTP_MACADDR: c4:14:3c:17:e8:00
TFTP_VERBOSE: Progress
TFTP_RETRY_COUNT: 18
TFTP_TIMEOUT: 7200
TFTP_CHECKSUM: Yes
ETHER_PORT: 2
ETHER_SPEED_MODE: Auto Detect

link up........
Receiving /tftpboot/username/cbrsup-universalk9.SSA.bin from 172.19.211.47
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Listing Supported Devices

The dev command lists the devices supported on the router.
rommon 1 > dev

Devices in device table:
id name
harddisk: Internal hard disk
bootflash: Internal flash drive
usb0: External USB drive 0
6
Basic Configuration
Booting from the Device on the Cisco cBR
usb1: External USB drive 1

rommon 2 >
Booting from the Device on the Cisco cBR

Step 1 Type the dir bootflash: command.
rommon > dir bootflash:

File System: EXT2/EXT3
12 691955580 -rw-r--r-- cbrsup-xe315.SSA.bin

45 83475 -rw-r--r-- reload.log.20120103004502
Step 2 Type the boot bootflash:imagename command.
rommon > boot bootflash:cbrsup-xe315.bin

File size is 0x293e67bc
Located cbrsup-xe315.bin
Image size 691955644 inode num 145153, bks cnt 168935 blk size 8*512
#######################################################################
Setting AUTOBOOT image in ROMMON

To set AUTOBOOT of an image from bootflash:, add the Environment Variable BOOT and then change the
configuration register boot characteristics to boot and reset the system.
Step 1 Type the boot=bootflash:imagename command to load the image.

rommon > BOOT=bootflash:cbrsup-xe315-20150131.bin
Step 2 Type the sync command to copy the variables to NVRAM.

rommon > sync
Step 3 Type the confreg command to configure and modify the settings.
rommon > confreg
enabled are:
do you wish to change the configuration? y/n [n]: y

enable "diagnostic mode"? y/n [n]:
enable "use net in IP bcast address"? y/n [n]:
enable "load rom after netboot fails"? y/n [n]:
enable "use all zero broadcast"? y/n [n]:
7
Basic Configuration
Verifying the ROMMON Version
disable "break/abort has effect"? y/n [n]:

enable "ignore system config info"? y/n [n]:
change console baud rate? y/n [n]: n
change the boot characteristics? y/n [n]: y
enter to boot:
0 = ROM Monitor
1 = the boot helper image
2-15 = boot system
[0]: 2
enabled are:
boot: ...... image specified by the boot system commands or default to: cisco2-Cisco cBR-8
do you wish to change the configuration? y/n [n]:
You must reset or power cycle for new config to take effect
Step 4 Type the reset command for the new configuration to take effect.
rommon > reset
What to do next
Verifying the ROMMON Version

Use the showmon command to display the version of ROMMON.
rommon > showmon

Current image running (0/1): Boot ROM0

rommon >
Resetting the Cisco cBR

Use the reset command to soft reset the Supervisor.
rommon > reset
Resetting .......
Initializing Hardware ...ˇ

8
Basic Configuration
Configuring PTP
Current image running: Boot ROM0
Last reset cause: LocalSoftware
CPUID: 0x000206d7
UCODE: 0x00000710_00000000
Set Chassis Type to 13RU
Cisco cBR-8 platform with 50331648 Kbytes of main memory
rommon >
Configuring PTP
The Cisco cBR supports Precision Time Protocol (PTP) boundary or ordinary clock (OC) subordinate mode
when connected to the Ethernet ports of the DPIC card or Supervisor PIC card. This topic provides you with
a an overview of PTP, configuration options, commands to verify the configuration settings, and configuration
examples.
Cisco cBR supports DPIC PTP subordinate configuration with the following restraints:
• Only subordinate mode is supported.
• Only one-step timestamping is supported
Overview of PTP
Precision Time Protocol (PTP) is a packet-based two-way message exchange protocol for synchronizing
clocks between nodes in a network, thus providing an accurate time distribution over a network. PTP support
is based on the IEEE 1588-2008 standard.
IEEE Standard 1588-2008 defines a method for distributing time around a network using the Precision Time
Protocol (PTP) version 2. IEEE 1588-2008 is designed to provide precise timing and synchronization over
packet-based Ethernet infrastructures without layer-1 support along the clocking path. PTP ensures that the
best available clock is selected as the source of time (the grandmaster clock) for the network and that other
clocks in the network are synchronized to the grandmaster.
PTP consists of two parts:
• The port state machine and the best primary clock algorithm: Provides a method to determine which
ports in the network run as primary (providing time to other clocks to the network), which runs as
subordinate (receiving time from other clocks in the network), and which are passive (neither primary
nor subordinate).
• Mechanisms for subordinate ports to calculate the difference between the time of their own clocks and
the time of their primary clock. To calculate the differences, PTP uses delay request and response
mechanism and a peer delay mechanism.
An overview of clock synchronization is explained.
9
Basic Configuration
Overview of PTP
Figure 1: Clock Synchronization
After the primary-subordinate clock hierarchy is established, the clock synchronization process starts. The
message exchange occurs in this sequence:
1. The primary clock sends a Sync message. The time at which the Sync message leaves the primary is
time-stamped as t1.
2. The subordinate clock receives the Sync message and is time-stamped as t2.
3. The subordinate sends the Delay request, which is time-stamped as t3 when it leaves the subordinate, and
as t4 when the primary receives it.
4. The primary responds with a Delay request that contains the time stamp t4.
PTP employs a hierarchy of clock types to ensure that precise timing and synchronization is maintained
between the source and the numerous PTP clients that are distributed throughout the network. The types of
clock are the following:
• Grandmaster clock
This clock is the highest-ranking clock within its PTP domain. PTP grandmasters can be deployed as
either standalone devices or as plug-in modules or “blades” that can be integrated into an existing
synchronization supply unit (SSU) or building integrated timing supply (BITS) shelf. Grandmasters are
the primary reference source (PRS) for all other PTP elements within their PTP domain.
• Primary clock
The PTP primary has a precise clock, from a PRC or GPS. This clock drives the timestamp engine to
derive accurate timestamps. The primary hosts PTP sessions with several subordinates.
• Subordinate clock
The subordinate is a network element that can recover the (Frequency and phase) clock from the
timestamps that are obtained by messages that are exchanged with the PTP primary clock.
• Boundary clock
The Boundary clock acts as both PTP primary and subordinate. It is a subordinate to a grandmaster and
derive the reference from the grandmaster. It then starts its own PTP sessions with several downstream
10
Basic Configuration
Configure PTP Subordinate Through DPIC
subordinates. The advantage of placing a boundary clock is that it mitigates the number of network hops
and resulting delays that occur in the packet network between the grandmaster and subordinates.
• Transparent clock
They maintain precise internal clocking by measuring the exact time difference between the packet entry
and exit and the correction field of PTP packet is updated accordingly. Hence, the delay that is introduced
by the node will not affect the PTP subordinate.
PTP on Supervisor 250 Interfaces

Cisco cBR functions as a PTP subordinate when it has Supervisor 250 (CBR-SUP-250G) ports that are
combined to form a port channel with an IPv6 address.
In this scenario, the Cisco cBR router locks with the remote PTP server which is also configured with an IPv6
address, through the port channel.
Note You can configure a maximum of two clock sources for PTP. If you confiigure three or more clock sources,
the ptpd_mcp_rp process crashes when the PTP reaches the PHASE ALIGNED state.
Configure PTP Subordinate Through DPIC

Before you begin
You can configure PTP ports on Cisco cBR through the DPIC.
Configure the PTP subordinate using one of the following options:

• Subordinate mode with single source
config terminal
ptp clock ordinary domain <domain id>
servo tracking-type R-DTI
clock-port <name> slave
delay-req interval < Interval>
sync interval < Interval>
sync one-step
transport <ipv4/ipv6> unicast interface <loopback name> negotiation
clock source <clock ip>
• Subordinate mode with single source with profile G8275.2

config terminal
clock-port <name> slave profile g8275.2
sync one-step
• Subordinate mode with multiple clock source
11
Basic Configuration
Configure Cisco cBR as PTP Subordinate
config t
clock-port <name> slave
sync one-step
clock source <clock ip> <local priority>
• Subordinate mode with multiple clock source with profile G8275.2

config t
ptp clock boundary domain <domain id>
clock-port <name> profile g8275.2
sync one-step
transport ipv6 unicast interface <loopback name> negotiation
clock-port <name> profile g8275.2
sync one-step
Configure Cisco cBR as PTP Subordinate

You can configure the Cisco cBR router to function as a PTP subordinate. The cBR router must have Supervisor
250 cards with an IPv6 port channel. Use the following sample commands to configure the router.
Step 1 Configure a port-channel on the Cisco cBR router using the following sample command:
router#config port-channel 16
cmts.config('''
interface port-channel 16
ip address %s 255.255.255.0
ipv6 address %s/64
no shut
''' % (ipaddr_portchannel,ipaddr_portchannel_ipv6))
Step 2 Configure the two ports that belong to this port-channel using the following sample command:
For example, you can configure one port on SUP-A and another port on SUP-B:
router#config port
cmts.config('''
interface %s
channel-group 16
no shut
''' % cbr1588_mainint)
Configure the port-channel on the peer switch using the commands in Step 1.
Step 3 Configure PTP on Cisco cBR using the following sample command:
12
Basic Configuration
Verifying PTP Subordinate Configuration
router#sh run | sec ptp

ptp clock ordinary domain 55
clock-port dp-ptp slave
delay-req interval -4
sync interval -5
sync one-step
transport ipv6 unicast interface Lo1588 negotiation
clock source ipv6 2001:10:90:3::93
Step 4 Verify the configuration by pinging the PTP server IPv6 address.
The source is Lo1588 interface.
Verifying PTP Subordinate Configuration

You can verify the PTP subordinate configuration by going through the following steps.
Step 1 Verify the PTP configuration by running the show run | se ptp command.
Example:
router# show run | se ptp

clock-port slave-from-903 slave
sync interval -5
sync one-step
clock source 10.90.3.93
Step 2 To verify the PTP clock working state, use the show ptp clock running command.
The state PHASE_ALIGNED confirms a successful locking.
Example:
router# show ptp clock running

PTP Ordinary Clock [Domain 55]
State Ports Pkts sent Pkts rcvd Redundancy Mode
PHASE_ALIGNED 1 68938 138822 Hot standby
PORT SUMMARY
PTP Master
Name Tx Mode Role Transport State Sessions Port Addr
slave-from-903 unicast slave Lo1588 Slave 1 10.90.3.93
L06#
PTP Subordinate Configuration Examples

The PTP subordinate example configurations are as follows:
• PTP subordinate mode with ipv4
13
Basic Configuration
PTP Subordinate Configuration Examples
config t
sync interval -5
sync one-step
• PTP subordinate mode with ipv6

config t
sync interval -5
sync one-step
• PTP subordinate mode with ipv4 with profile G8275.2

config t
clock-port slave-from-903 slave profile g8275.2
sync interval -5
sync one-step
• PTP subordinate mode with ipv6 with profile G8275.2

config t
sync interval -5
sync one-step
• PTP subordinate mode with ipv4 with 2 clock sources

config t
sync interval -5
sync one-step
clock source 10.1.1.1 2
• PTP subordinate mode with ipv6 with 2 clock sources and with profile G8275.2
config t
ptp clock boundary domain 55
clock-port 22 profile g8275.2
14
Basic Configuration
Feature Information for PTP Subordinate
sync interval -5
sync one-step
clock-port 33 profile g8275.2
sync interval -5
sync one-step
clock source ipv6 2001:158:158:158::7
Feature Information for PTP Subordinate

Use Cisco Feature Navigator to find information about the platform support and software image support.
Cisco Feature Navigator enables you to determine which software images support a specific software release,
feature set, or platform. To access Cisco Feature Navigator, go to the https://cfnng.cisco.com/ link. An account
on the Cisco.com page is not required.
Note The following table lists the software release in which a given feature is introduced. Unless noted otherwise,
subsequent releases of that software release train also support that feature.
Table 1: Feature Information for PTP Subordinate
Feature Name Releases Feature Information
PTP Subordinate Through Cisco IOS-XE Release 16.8.1 This feature was introduced in Cisco
DPIC IOS-XE Release 16.8.1 on Cisco cBR
Series Converged Broadband Router.
PTP on Supervisor 250 Cisco IOS-XE Amsterdam 17.3.1 This feature was introduced in Cisco
Interfaces IOS-XE Release 17.3.1 on Cisco cBR
File Systems
The Cisco cBR-8 router runs on the Cisco IOS-XE image. Supported file systems include:
1. IOS File System (IFS) in IOS
2. ext2, vfs, jffs2, tmpfs, autofs, and such common file systems in Linux
Features of the File Systems:
1. Both the Harddisk and USB are hot pluggable.
2. Harddisk is not accessible under Rommon.
3. Bootflash and USB disk are accessible under Rommon.
4. The dir, show, copy, delete, mkdir, rmdir, and fsck commands are supported for bootflash, harddisk
and USB.
15
Basic Configuration
Verification of Hardware Bring Up
File System Table in the Supervisor
Name Device Size Type Visible Usage Physical Description
bootflash /dev/bootflash1 7800705024 ext2 IOS/Binos image,IOScrasinfo,etc Partition1 of bootflash

(eUSB flash).
flash /dev/bootflash1 7800705024 ext2 IOS image A copy of bootflash.
nvram /dev/bootflash2 32M N/A IOS configuretion, etc Partition2 of bootflash

(eUSB flash).
harddisk /dev/harddisk1 98394218496 ext2 IOS/Binos tracelog,corefile,etc Partition1 of the 100G

harddisk.
usb0 /dev/usb11 8G vfat IOS/Binos image Two USBs can be

inserted into one SUP.
Verification of Hardware Bring Up

Monitoring the Cisco cBR Chassis Using CLI
• show platform—Verify if the installed cards are in Ok or Inserted state.
Router# show platform
Chassis type: CBR-8-CCAP-CHASS
Slot Type State Insert time (ago)

--------- ------------------- --------------------- -----------------
1 CBR-CCAP-LC-40G ok 03:22:58
1/1 CBR-RF-PIC ok 03:19:40
SUP0 CBR-CCAP-SUP-160G inserted 03:22:58
R0 ok, active
F0 ok, active
4 ok, active
4/1 CBR-SUP-8X10G-PIC ok 03:20:30
P0 PWR-2KW-DC-V2 ok 03:21:20
P1 PWR-2KW-DC-V2 ok 03:21:20
P2 PWR-2KW-DC-V2 ok 03:21:20
P3 PWR-2KW-DC-V2 ok 03:21:20
P4 PWR-2KW-DC-V2 ok 03:21:20
P5 PWR-2KW-DC-V2 ok 03:21:20
P10 CBR-FAN-ASSEMBLY ok 03:21:10
• show platform hardware slot slot serdes status—Verify if all the links are in locked state.
Router# show platform hardware slot F1 serdes status
Slot R1-Link A
RX link locked
58-bit scrambler, 20 Gbps
0 Overruns, 0 Underruns
16
Basic Configuration
0 Reframe, 0 Disparity
0 Out of band, 0 Illegal control codes
Slot 3-Link A
RX link locked
Slot 5-Link A
RX link locked
Slot 5-Link B
RX link locked
Slot 5-Link C
RX link locked
Slot 5-Link D
RX link locked
Slot 5-Link E
RX link Init
Slot 5-Link F
RX link Init
Slot 5-Link G
RX link Init
Slot 5-Link H
RX link Init
17
Basic Configuration
• show environment all—Verify the environmental status of each FRU after installation.
This command displays the system temperature, voltage, fan, and power supply conditions.
Router# show environment all
Sensor List: Environmental Monitoring

Sensor Location State Reading
AVCC&1P2: Sens 4/1 Normal 81 mV
AVCC&1P2: Vin 4/1 Normal 12600 mV
AVCC&1P2: ADin 4/1 Normal 0 mV
VP1P35: Sens 4/1 Normal 8 mV
VP1P35: Vin 4/1 Normal 12650 mV
VP1P35: ADin 4/1 Normal 112 mV
MGTAVTT: Sens 4/1 Normal 21 mV
MGTAVTT: Vin 4/1 Normal 12625 mV
MGTAVTT: ADin 4/1 Normal 0 mV
Temp: RTMAC 4/1 Normal 34 Celsius
Temp: INLET 4/1 Normal 29 Celsius
Temp: OUTLET 4/1 Normal 27 Celsius
Temp: MAX6697 4/1 Normal 50 Celsius
Temp: TCXO 4/1 Normal 37 Celsius
Temp: SUP_OUT 4/1 Normal 49 Celsius
Temp: 3882_1 P 4/1 Normal 44 Celsius
3P3&1P0: Sens 4/1 Normal 24 mV
3P3&1P0: Vin 4/1 Normal 12625 mV
3P3&1P0: ADin 4/1 Normal 0 mV
Temp: INLET PD 4/1 Normal 27 Celsius
Temp: OUTLETPD 4/1 Normal 36 Celsius
Temp: 6697-DC 4/1 Normal 38 Celsius
Temp: PHYOUT 4/1 Normal 49 Celsius
Temp: PHYIN 4/1 Normal 38 Celsius
Temp: SSD 4/1 Normal 40 Celsius
Temp: SFP+ 4/1 Normal 36 Celsius
Temp: 3882_1PD 4/1 Normal 42 Celsius
3882_PC1_0: VO 4/1 Normal 1198 mV
3882_PC1_1: VO 4/1 Normal 999 mV
3882_PC2_0: VO 4/1 Normal 998 mV
3882_PC3_0: VO 4/1 Normal 1349 mV
PSOC-PC1_0: VO 4/1 Normal 3300 mV
18
Basic Configuration

PSOC-PC1_10: V 4/1 Normal 1798 mV
3882_PDC_0: VO 4/1 Normal 1000 mV
3882_PDC_1: VO 4/1 Normal 3300 mV
PSOC-DC1_0: VO 4/1 Normal 4998 mV
12_CUR: Sens 9 Normal 14 mV
12_CUR: Vin 9 Normal 12650 mV
12_CUR: ADin 9 Normal 267 mV
G0_CUR: Sens 9 Normal 69 mV
G0_CUR: Vin 9 Normal 12550 mV
G0_CUR: ADin 9 Normal 0 mV
G1_CUR: Sens 9 Normal 69 mV
G1_CUR: Vin 9 Normal 12575 mV
G1_CUR: ADin 9 Normal 0 mV
LB_CUR: Sens 9 Normal 11 mV
LB_CUR: Vin 9 Normal 12525 mV
LB_CUR: ADin 9 Normal 0 mV
Temp: CAPRICA 9 Normal 40 Celsius
Temp: BASESTAR 9 Normal 47 Celsius
Temp: RAIDER 9 Normal 45 Celsius
Temp: CPU 9 Normal 31 Celsius
Temp: INLET 9 Normal 25 Celsius
Temp: OUTLET 9 Normal 35 Celsius
Temp: DIGITAL 9 Normal 31 Celsius
Temp: UPX 9 Normal 29 Celsius
Temp: LEOBEN1 9 Normal 31 Celsius
Temp: LEOBEN2 9 Normal 35 Celsius
Temp: 3.3-18 9 Normal 43 Celsius
Temp: BS_1V 9 Normal 45 Celsius
Freq: 5338-49 9 Normal 0 MHz
3882_1_0: VOUT 9 Normal 3299 mV
3882_1_1: VOUT 9 Normal 1800 mV
3882_2_0: VOUT 9 Normal 2500 mV
3882_2_1: VOUT 9 Normal 1199 mV
3882_3_0: VOUT 9 Normal 1419 mV
3882_4_0: VOUT 9 Normal 1350 mV
3882_5_0: VOUT 9 Normal 1000 mV
3882_6_0: VOUT 9 Normal 1021 mV
3882_7_0: VOUT 9 Normal 1199 mV
3882_7_1: VOUT 9 Normal 1000 mV
3882_8_0: VOUT 9 Normal 1000 mV
3882_9_0: VOUT 9 Normal 999 mV
V2978: VSENSE0 9 Normal 0 mV
19
Basic Configuration
V2978: VIN 9 Normal 25218 mV

PSOC_2_0: VOUT 9 Normal 12582 mV
PSOC_2_10: VOU 9 Normal 995 mV
LTC4261: Power 9 Normal 340 Watts
PEM Iout P0 Normal 5 A
PEM Vout P0 Normal 55 V DC
PEM Vin P0 Normal 202 V AC
Temp: INLET P0 Normal 26 Celsius
Temp: OUTLET P0 Normal 48 Celsius
PSOC-MB2_0: VO R0 Normal 12758 mV
PSOC-MB2_10: V R0 Normal 994 mV
20
Basic Configuration

3882_MB1_0: VO R0 Normal 1001 mV
15301_1: VOUT R0 Normal 2500 mV
AS_VRM: Sens R0 Normal 40 mV
AS_VRM: Vin R0 Normal 12725 mV
AS_VRM: ADin R0 Normal 0 mV
Y0_VRM: Sens R0 Normal 23 mV
Y0_VRM: Vin R0 Normal 12675 mV
Y0_VRM: ADin R0 Normal 380 mV
CPU_VCC: Sens R0 Normal 6 mV
CPU_VCC: Vin R0 Normal 12725 mV
CPU_VCC: ADin R0 Normal 0 mV
5P0_BIAS: Sens R0 Normal 19 mV
5P0_BIAS: Vin R0 Normal 12700 mV
5P0_BIAS: ADin R0 Normal 0 mV
7P0_BIAS: Sens R0 Normal 45 mV
7P0_BIAS: Vin R0 Normal 12725 mV
7P0_BIAS: ADin R0 Normal 0 mV
1P0_AA: Sens R0 Normal 37 mV
1P0_AA: Vin R0 Normal 12700 mV
1P0_AA: ADin R0 Normal 0 mV
1P0_RT: Sens R0 Normal 16 mV
1P0_RT: Vin R0 Normal 12725 mV
1P0_RT: ADin R0 Normal 0 mV
1P2: Sens R0 Normal 37 mV
1P2: Vin R0 Normal 12675 mV
1P2: ADin R0 Normal 0 mV
21
Basic Configuration
0P9_T0: Sens R0 Normal 7 mV

0P9_T0: Vin R0 Normal 12750 mV
0P9_T0: ADin R0 Normal 0 mV
1P05_CPU: Sens R0 Normal 11 mV
1P05_CPU: Vin R0 Normal 12700 mV
1P05_CPU: ADin R0 Normal 0 mV
1P0_CC: Sens R0 Normal 16 mV
1P0_CC: Vin R0 Normal 12700 mV
1P0_CC: ADin R0 Normal 0 mV
1P35_DDR: Sens R0 Normal 6 mV
1P35_DDR: Vin R0 Normal 12725 mV
1P35_DDR: ADin R0 Normal 0 mV
1P35_RLD: Sens R0 Normal 0 mV
1P35_RLD: Vin R0 Normal 12675 mV
1P35_RLD: ADin R0 Normal 2047 mV
3P3_CCC: Sens R0 Normal 16 mV
3P3_CCC: Vin R0 Normal 12700 mV
3P3_CCC: ADin R0 Normal 1375 mV
1P0_R: Sens R0 Normal 29 mV
1P0_R: Vin R0 Normal 12700 mV
1P0_R: ADin R0 Normal 0 mV
1P5_A0: Sens R0 Normal 41 mV
1P5_A0: Vin R0 Normal 12700 mV
1P5_A0: ADin R0 Normal 0 mV
1P8_A: Sens R0 Normal 10 mV
1P8_A: Vin R0 Normal 12675 mV
1P8_A: ADin R0 Normal 947 mV
1P0_BV: Sens R0 Normal 24 mV
1P0_BV: Vin R0 Normal 12700 mV
1P0_BV: ADin R0 Normal 0 mV
1P2_B: Sens R0 Normal 41 mV
1P2_B: Vin R0 Normal 12725 mV
1P2_B: ADin R0 Normal 0 mV
ADM1075: Power R0 Normal 329 Watts
Temp: Y0_DIE R0 Normal 33 Celsius
Temp: BB_DIE R0 Normal 29 Celsius
Temp: VP_DIE R0 Normal 26 Celsius
Temp: RT-E_DIE R0 Normal 31 Celsius
Temp: INLET_1 R0 Normal 23 Celsius
Temp: INLET_2 R0 Normal 22 Celsius
Temp: OUTLET_1 R0 Normal 25 Celsius
Temp: 3882_1 R0 Normal 46 Celsius
Temp: 3882_1A R0 Normal 43 Celsius
Temp: 3882_1B R0 Normal 43 Celsius
22
Basic Configuration

Temp: AS_DIE R0 Normal 70 Celsius
Temp: XPT1_DTL R0 Normal 42 Celsius
Temp: XPT1_DTR R0 Normal 42 Celsius
Temp: XPT1_DBL R0 Normal 42 Celsius
Temp: XPT1_DBR R0 Normal 42 Celsius
Freq: MAX3674 R0 Normal 500 MHz
Freq: SQ420D R0 Normal 24 MHz
• show facility-alarm status —Verify the chassis status.

Router# show facility-alarm status
System Totals Critical: 4 Major: 1 Minor: 8
Source Time Severity Description [Index]

------ ------ -------- -------------------
slot 3/0 Apr 13 2015 16:25:58 CRITICAL Active Card Removed
OIR Alarm [0]
Power Supply Bay 3 Apr 13 2015 13:41:56 CRITICAL Power Supply/FAN
Module Missing [0]
Module Missing [0]
Module Missing [0]
Cable3/0/15-US0 Apr 13 2015 17:32:53 MINOR Physical Port Link
Down [0]
Down [0]
Down [0]
Down [0]
23
Basic Configuration
Gigabit Ethernet Management Interface Overview
Down [0]
Gigabit Ethernet Management Interface Overview

The purpose of this interface is to allow users to perform management tasks on the router; it is basically an
interface that should not and often cannot forward network traffic but can otherwise access the router, often
via Telnet and SSH, and perform most management tasks on the router.
The following aspects of the Management Ethernet interface should be noted:
• Each SUP has a Management Ethernet interface, but only the active SUP has an accessible Management
Ethernet interface (the standby SUP can be accessed using the console port, however).
• IPv4, IPv6, and ARP are the only routed protocols supported for the interface.
• The interface provides a method of access to the router even when some software processes are down.
• The Ethernet Management Interface cannot be used as a Lawful Intercept MD source interface.
• The Management Ethernet interface is part of its own VRF.
Gigabit Ethernet Port Numbering

The Gigabit Ethernet Management port is always GigabitEthernet0.
In a dual SUP configuration, the Management Ethernet interface on the active SUP will always be Gigabit
Ethernet 0, while the Management Ethernet interface on the standby SUP will not be accessible using the
Cisco IOS-XE CLI in the same telnet session. The standby SUP can be telnetted to through the console port,
however.
The port can be accessed in configuration mode like any other port on the Cisco cBR Series Routers:
Router#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)#interface gigabitethernet0
Router(config-if)#
IP Address Handling in ROMMON and the Management Ethernet

Port
Assuming the IOS-XE process has not begun running on the Cisco cBR Series Router, the IP address that
was set in ROMMON acts as the IP address of the Management Ethernet interface. In cases where the IOS-XE
process is running and has taken control of the Management Ethernet interface, the IP address specified when
configuring the Gigabit Ethernet 0 interface in the IOS-XE CLI becomes the IP address of the Management
Ethernet interface. The ROMMON-defined IP address is only used as the interface address when the IOS-XE
process is inactive.
For this reason, the IP addresses specified in ROMMON and in the IOS-XE CLI can be identical and the
Management Ethernet interface will function properly in single SUP configurations.
24
Basic Configuration
Gigabit Ethernet Management Interface VRF
In dual SUP configurations, however, users should never configure the IP address in the ROMMON on either
SUP0 or SUP1 to match each other or the IP address as defined by the IOS-XE CLI. Configuring matching
IP addresses introduces the possibility for an active and standby Management Ethernet interface having the
same IP address with different MAC addresses, which will lead to unpredictable traffic treatment.
Gigabit Ethernet Management Interface VRF

Placing the management Ethernet interface in its own VRF has the following effects on the Management
Ethernet interface:
• Many features must be configured or used inside the VRF, so the CLI may be different for certain
Management Ethernet functions on the Cisco cBR Series Routers than on Management Ethernet interfaces
on other routers.
• The VRF prevents route leakage and avoids unnecessary traffic through the management port.
The Management Ethernet interface VRF supports both IPv4 and IPv6 address families.
Common Ethernet Management Tasks

Because users can perform most tasks on a router through the Management Ethernet interface, many tasks
can be done by accessing the router through the Management Ethernet interface.
This section documents tasks that might be common or slightly tricky on the Cisco cBR Series Routers. It is
not intended as a comprehensive list of all tasks that can be done using the Management Ethernet interface.
Viewing the VRF Configuration

The VRF configuration for the Management Ethernet interface is viewable using the show running-config
vrf command.
This example shows the default VRF configuration:
Router# show running-config vrf

Building configuration...
Current configuration : 351 bytes

vrf definition Mgmt-intf
!
address-family ipv4
exit-address-family
!
address-family ipv6
exit-address-family
!
(some output removed for brevity)
25
Basic Configuration
Setting a Default Route in the Management Ethernet Interface VRF
Setting a Default Route in the Management Ethernet Interface

VRF
To set a default route in the Management Ethernet Interface VRF, use the ip route vrf Mgmt-intf 0.0.0.0
0.0.0.0 next-hop-IP-address command.
Setting the Management Ethernet IP Address

The IP address of the Management Ethernet port is set like the IP address on any other interface.
Below are two simple examples of configuring an IPv4 address and an IPv6 address on the Management
Ethernet interface.
IPv4 Example
Router(config)# interface GigabitEthernet 0

Router(config-if)# ip address A.B.C.D A.B.C.D
IPv6 Example
Router(config)# interface GigabitEthernet 0

Router(config-if)# ipv6 address X:X:X:X::X /prefix-length
Telnetting over the Management Ethernet Interface

Telnetting can be done through the VRF using the Management Ethernet interface.
In the following example, the router telnets to 172.17.1.1 through the Management Ethernet interface VRF:
Router# telnet 172.17.1.1 /vrf Mgmt-intf
Pinging over the Management Ethernet Interface

Pinging other interfaces using the Management Ethernet interface is done through the VRF.
In the following example, the router pings the interface with the IP address of 172.17.1.1 through the
Management Ethernet interface:
Router# ping vrf Mgmt-intf 172.17.1.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.17.1.1, timeout is 2 seconds:
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 1/1/1 ms
26
Basic Configuration
Copy Using TFTP or FTP
Copy Using TFTP or FTP

To copy a file using TFTP through the Management Ethernet interface, the ip tftp source-interface
GigabitEthernet 0 command must be entered before entering the copy tftp command because the copy tftp
command has no option of specifying a VRF name.
Similarly, to copy a file using FTP through the Management Ethernet interface, the ip ftp source-interface
GigabitEthernet 0 command must be entered before entering the copy ftp command because the copy ftp
command has no option of specifying a VRF name.
TFTP Example
Router(config)# ip tftp source-interface gigabitethernet 0
FTP Example
Router(config)# ip ftp source-interface gigabitethernet 0
NTP Server
To allow the software clock to be synchronized by a Network Time Protocol (NTP) time server over the
Management Ethernet interface, enter the ntp server vrf Mgmt-intf command and specify the IP address of
the device providing the update.
The following CLI provides an example of this procedure.
Router(config)# ntp server vrf Mgmt-intf 172.17.1.1
SYSLOG Server
To specify the Management Ethernet interface as the source IP or IPv6 address for logging purposes, enter
the logging host ip-address vrf Mgmt-intf command.
The following CLI provides an example of this procedure.
Router(config)# logging host ip-address vrf Mgmt-intf
SNMP-Related Services
To specify the Management Ethernet interface as the source of all SNMP trap messages, enter the snmp-server
source-interface traps gigabitEthernet 0 command.
The following CLI provides an example of this procedure:
Router(config)# snmp-server source-interface traps gigabitEthernet 0
Domain Name Assignment

The IP domain name assignment for the Management Ethernet interface is done through the VRF.
27
Basic Configuration
DNS service
To define the default domain name as the Management Ethernet VRF interface, enter the ip domain-name
vrf Mgmt-intf domain command.
Router(config)# ip domain-name vrf Mgmt-intf cisco.com
DNS service
To specify the Management Ethernet interface VRF as a name server, enter the ip name-server vrf Mgmt-intf
IPv4/IPv6 address command.
RADIUS or TACACS+ Server

To group the Management VRF as part of a AAA server group, enter the ip vrf forward Mgmt-intf command
when configuring the AAA server group.
The same concept is true for configuring a TACACS+ server group. To group the Management VRF as part
of a TACACS+ server group, enter the ip vrf forwarding Mgmt-intf command when configuring the
TACACS+ server group.
RADIUS Server Group Configuration
Router(config)# aaa group server radius hello

Router(config-sg-radius)# ip vrf forwarding Mgmt-intf
TACACS+ Server Group Configuration
Router(config)# aaa group server tacacs+ hello

Router(config-sg-tacacs+)# ip vrf forwarding Mgmt-intf
VTY lines with ACL

To ensure an access control list (ACL) is attached to vty lines that are and are not using VRF, use the vrf-also
option when attaching the ACL to the vty lines.
Router(config)# line vty 0 4

Router(config-line)#access-class 90 in vrf-also
Configuring the AUX Port for Network Management

Step 1 AUX port is used for IOSd command prompt. Type the set command at the rommon prompt.
Step 2 Verify if BOOT_PARAM is defined. It must not be defined.
Step 3 If the BOOT_PARAM is defined, do the following:
a) Type unset BOOT_PARAM.
b) Type sync.
c) Type reset.
28
Basic Configuration
Preprovisioning the Supervisor in the Cisco cBR Chassis
Step 4 Boot with the latest image. The AUX port will show IOS command prompt.
Preprovisioning the Supervisor in the Cisco cBR Chassis

Preprovisioning on the Cisco cBR allows you to configure the Supervisors without their physical presence in
the chassis.
Procedure
Command or Action Purpose

Step 1 enable Enables privileged EXEC mode.
Example: Enter your password if prompted.
Router> enable
Step 2 configure terminal Enters global configuration mode.

Example:
Router# configure terminal
Step 3 card slot/1 sup-pic-8x10g Preprovisions the Supervisor in the Cisco cBR chassis.
Example: • slot—Identifies the chassis slot number for the
Router(config)# card 4/1 sup-pic-8x10g Supervisor PIC. The valid values are 4 and 5.
Configuring the Gigabit Ethernet Interface for Network

Management
You must configure the GigabitEthernet0 interface and enable it to use the NME port.
Procedure

Router> enable

Example:
Step 3 interface GigabitEthernet0 Enters the Gigabit Ethernet interface configuration mode.
Example:
Router(config)# interface GigabitEthernet0
29
Basic Configuration
Configuring the DTI Port on the Supervisor PIC

Step 4 vrf forwarding vrf-name Associates a Virtual Routing and Forwarding (VRF)
instance with the interface.
Example:
Router(config-if)# vrf forwarding Mgmt-intf • vrf-name—The interface name to be associated with
the specified VRF.
Step 5 ip address ip-address subnet-mask Sets the IP address of the Gigabit Ethernet interface.
Example: • ip-address—IP address of the Gigabit Ethernet
Router(config-if)# ip address 192.71.0.1 interface.
255.255.255.0
• subnet -mask—Subnet mask for the network.
Step 6 no shutdown Enables the Gigabit Ethernet interface.

Example:
Router(config-if)# no shutdown
Step 7 speed 1000 [negotiate] Configures the speed for the Gigabit Ethernet interface.
Example:
Router(config-if)# speed 1000
Step 8 duplex full Configures full duplex operation on the Gigabit Ethernet
interface.
Example:
Router(config-if)# duplex full
Step 9 negotiation auto Selects the auto-negotiation mode.

Example:
Router(config-if)# negotiation auto
Step 10 end Exits Gigabit Ethernet interface configuration mode.

Returns to privileged EXEC mode.
Example:
Router(config-if)# end
Configuring the DTI Port on the Supervisor PIC

The Cisco cBR router can run in standalone mode, which uses internal clock and does not require any external
reference clock source. The Cisco cBR router also supports DTI server as an external clocking source. To use
a DTI server as a reference clock source, you must enable the DTI port on the Supervisor PIC.
Procedure

30
Basic Configuration
Configuring the TenGigabit Ethernet Interface for Network Management

Router> enable

Example:
Step 3 cable clock dti Configures the DTI clock reference mode for the Supervisor
PIC.
Example:
Router(config)# cable clock dti
Configuring the TenGigabit Ethernet Interface for Network

Management
You must configure the TenGigabitEthernet interface and enable it to use the NME port.
Procedure

Router> enable

Example:
Step 3 interface TenGigabitEthernet Enters the TenGigabit Ethernet interface configuration

mode.
Example:
Router(config)# interface TenGigabitEthernet4/1/0
Step 4 ip address ip-address subnet-mask Sets the IP address of the TenGigabit Ethernet interface.
Example:
Router(config-if)# ip address 1.2.3.4 255.255.255.0
Step 5 load-interval seconds Changes the length of time for which data is used to
compute load statistics.
Example:
Router(config-if)# load-interval 30
Step 6 no shutdown Enables the TenGigabit Ethernet interface.

Example:
31
Basic Configuration
Connecting the New Router to the Network

Step 7 end Exits TenGigabit Ethernet interface configuration mode.
Example:
Connecting the New Router to the Network

Connect the new router to the network using a n Ethernet interface. After the router successfully resolves its
host name, new router sends a TFTP broadcast requesting the file name-confg or name.cfg. The router name
must be in all lowercase, even if the true host name is not. The file is downloaded to the new router, where
the configuration commands take effect immediately. If the configuration file is complete, the new router
should be fully operational.
To save the complete configuration to NVRAM, use the following commands in privileged EXEC mode:
Procedure

Step 1 enable password Enters privileged mode on the new router.
Step 2 copy running-config startup-config Saves the information from the name-config file into your
startup configuration. On most platforms, this step saves
the configuration to NVRAM.
Note Verify that the existing and new routers (or
access servers) are connected before entering the
copy running-config startup-config EXEC
command to save configuration changes. Use
the ping EXEC command to verify connectivity.
If an incorrect configuration file is downloaded,
the new router will load NVRAM configuration
information before it can enter AutoInstall mode.
If the configuration file is a minimal configuration file, the

new router comes up, but with only one interface
operational. Use the following commands to connect to the
new router and configure it.
Step 3 telnet existing Establishes a Telnet connection to the existing router.
Step 4 telnet newrouter From the existing router, establishes a Telnet connection
to the new router.
Step 5 enable password Enters privileged EXEC mode.
Step 6 setup Enters setup mode to configure the new router.
32
Basic Configuration
Setting Password Protection on the Cisco CMTS
Setting Password Protection on the Cisco CMTS
Note For security purposes, the EXEC has two levels of access to commands: user EXEC mode and privileged
EXEC mode. The commands available at the user level are a subset of those available at the privileged level.
Tip Because many privileged-level EXEC commands are used to set operating parameters, password-protect these
commands to prevent unauthorized use.
Note An enable secret password can contain from 1 to 25 uppercase and lowercase alphanumeric characters. An
enable password can contain any number of uppercase and lowercase alphanumeric characters. A number
cannot be the first character. Spaces are valid password characters; for example, “two words” is a valid
password. Leading spaces are ignored. Trailing spaces are recognized. Alphanumeric characters are recognized
as uppercase or lowercase.
Passwords should be different for maximum security. If you enter the same password for both during the setup
script, the system accepts it, but you receive a warning message indicating that you should enter a different
password.
At the EXEC prompt, enter one of the following two commands to set password protection:
• enable secret password—a very secure encrypted password.
• enable—is a less secure and nonencrypted password.
To gain access to privileged-level commands, enter the desired password.
Recovering Lost Password on the Cisco CMTS

Complete the following steps to recover or replace a lost enable, enable secret, or console login password:
Step 1 Attach an ASCII terminal to the console port on your Cisco CMTS.
Step 2 Configure the terminal to operate at 9600 baud, 8 data bits, no parity, and 1 stop bits.
Step 3 If you can log in to the router as a nonprivileged user, enter the show version command to display the existing
configuration register value. Note the value for later use. If you cannot log in to the router at all, continue with the next
step.
Step 4 Press the Break key or send a Break from the console terminal.
• If Break is enabled, the router enters the ROM monitor, indicated by the ROM monitor prompt (rommon n>),
where n is the number of the command line. Proceed to configuring the register.
• If Break is disabled, power cycle the router (turn the router off or unplug the power cord, and then restore power).
Within 60 seconds of restoring the power to the router, press the Break key or send a Break. This action causes
the router to enter the ROM monitor and display the ROM monitor prompt (rommon 1>).
33
Basic Configuration
Recovering Lost Password on the Cisco CMTS
Step 5 To set the configuration register on a Cisco CMTS, use the configuration register utility by entering the confreg
command at the ROM monitor prompt as follows:
rommon 1> confreg
Answer yes to the enable ignore system config info? prompt and note the current configuration register settings.
Step 6 Initialize the router by entering the reset command as follows:

rommon 2> reset
The router initializes, the configuration register is set to 0x142, the router boots the system image from Flash memory
and enters the System Configuration dialog (setup), as follows:
--- System Configuration Dialog --
Step 7 Enter no in response to the System Configuration dialog prompts until the following message appears:
Press RETURN to get started!
Step 8 Press Return. The user EXEC prompt appears as follows:
Router>
Step 9 Enter the enable command to enter privileged EXEC mode.

Step 10 Enter the show startup-config command to display the passwords in the configuration file as follows:
Router# show startup-config
Step 11 Scan the configuration file display looking for the passwords; the enable passwords are usually near the beginning of
the file, and the console login or user EXEC password is near the end. The passwords displayed will look something
like this:
enable secret 5 $1$ORPP$s9syZt4uKn3SnpuLDrhuei

enable password 23skiddoo
.
.
line con 0
password onramp
Note The enable secret password is encrypted and cannot be recovered; it must be replaced. The enable and console
passwords can be encrypted text or clear text.
Proceed to the next step to replace an enable secret, console login, or enable password. If there is no enable secret
password, note the enable and console login passwords if they are not encrypted and proceed to set the configuration
register to the original value.
Caution Do not perform the next step unless you have determined that you must change or replace the enable, enable
secret, or console login passwords. Failure to follow the steps as presented here could cause your router
configuration to be erased.
Step 12 (Optional) Enter the configure memory command to load the startup configuration file into running memory. This
action allows you to modify or replace passwords in the configuration.
Router# configure memory
Step 13 Enter the configure terminal command for configuration mode:
34
Basic Configuration
Saving Your Configuration Settings
Step 14 To change all three passwords, enter the following commands:
Router(config)# enable secret newpassword1
Router(config)# enable password newpassword2

Router(config)# line con 0
Router(config)# password newpassword3
Change only the passwords necessary for your configuration. You can remove individual passwords by using the no
form of the previous commands. For example, entering the no enable secret command removes the enable secret
password.
Step 15 You must configure all interfaces to not be administratively shut down as follows:
Router(config)# interface gigabitethernet 0
Router(config)# no shutdown
Enter the equivalent commands for all interfaces that were originally configured. If you omit this step, all interfaces
are administratively shut down and unavailable when the router is restarted.
Step 16 Use the config-register command to set the configuration register to the original value noted earlier.
Step 17 Press Ctrl-Z or type end to exit configuration mode:
Router(config)# end
Caution Do not perform the next step unless you have changed or replaced a password. If you skipped changing or
replacing the enable, enable secret, or console login passwords previously, then proceed now to reload. Failure
to observe this sequence causes the system to erase your router configuration file.
Step 18 Enter the copy running-config startup-config command to save the new configuration to nonvolatile memory:
Router# copy running-config startup-config
Step 19 Enter the reload command to reboot the router:
Router# reload
Step 20 Log in to the router with the new or recovered passwords.
Saving Your Configuration Settings

To store the configuration or changes to your startup configuration in NVRAM, enter the copy running-config
startup-config command at the Router# prompt.
This command saves the configuration settings you set using configuration mode, the Setup facility, or
AutoInstall.
35
Basic Configuration
Reviewing Your Settings and Configurations
Note If you do not save your settings, your configuration will be lost the next time you reload the router.
Example
Reviewing Your Settings and Configurations

• To view the current configuration of a Cisco CMTS, run the show running-config command at the
command-line interface (CLI) prompt in EXEC mode or privileged EXEC mode.
• To review changes you make to the configuration, use the EXEC show startup-config command to
display the information stored in NVRAM.
Recovering Unresponsive Modems

If the cable modem does not respond to pings from the Cisco Converged Broadband Router, the modem
DSBG, DSID, and the BPI index values on the Cisco Converged Broadband Router may be incorrect. To
recover the unresponsive modem, run the cable reconciliation enable command to generate the correct DSBG,
DSID, and the BPI index values. The following CLI provides an example of this procedure:
Router# cable reconciliation enable
Router# end
To set the time when the cable reconciliation enable command should run, run the cable reconcilation time
hours command, where hours is the time in the 24 hour format. The following CLI provides an example of
this procedure:
Router# cable reconciliation time 23
Router# end
36
CHAPTER 2
Cisco Smart Licensing
A new licensing model, based on a single technology, has been designed for Cisco called Smart Licensing
that is intended to provide Enterprise Level Agreement-like capabilities for all Cisco products. The Cisco
Smart Licensing is based on the Trust but Verify model.
Your software release may not support all the features that are documented in this module. For the latest
feature information and caveats, see the release notes for your platform and software release. The Feature
Information Table at the end of this document provides information about the documented features and lists
the releases in which each feature is supported.
Use Cisco Feature Navigator to find information about platform support and Cisco software image support.
To access Cisco Feature Navigator, go to http://tools.cisco.com/ITDIT/CFN/. An account on
http://www.cisco.com/ is not required.
Contents
• Hardware Compatibility Matrix for the Cisco cBR Series Routers, on page 37
• Prerequisites for Cisco Smart Licensing, on page 38
• Information About Cisco Smart Licensing, on page 39
• How to Configure Cisco Smart Licensing, on page 41
• How to Configure Cisco Smart Licensing using Transport Gateway Solution, on page 51
• Configuring 100G Licenses for Supervisor 250G, on page 53
• Verifying Cisco Smart Licensing Configuration, on page 58
• Troubleshooting Cisco Smart Licensing, on page 64
• Additional References, on page 65
• Feature Information for Cisco Smart Licensing, on page 65
Hardware Compatibility Matrix for the Cisco cBR Series Routers
Note The hardware components that are introduced in a given Cisco IOS-XE Release are supported in all subsequent
releases unless otherwise specified.
37
Basic Configuration
Prerequisites for Cisco Smart Licensing
Table 2: Hardware Compatibility Matrix for the Cisco cBR Series Routers
Cisco CMTS Platform Processor Engine Interface Cards
Cisco cBR-8 Converged Broadband Cisco IOS-XE Release 16.5.1 and Cisco IOS-XE Release 16.5.1 and
Router Later Releases Later Releases
Cisco cBR-8 Supervisor: Cisco cBR-8 CCAP Line Cards:
• PID—CBR-SUP-250G • PID—CBR-LC-8D30-16U30
• PID—CBR-CCAP-SUP-160G • PID—CBR-LC-8D31-16U30
• PID—CBR-RF-PIC
• PID—CBR-RF-PROT-PIC
• PID—CBR-CCAP-LC-40G
• PID—CBR-CCAP-LC-40G-R
• PID—CBR-CCAP-LC-G2-R
• PID—CBR-SUP-8X10G-PIC
• PID—CBR-2X100G-PIC
Digital PICs:
• PID—CBR-DPIC-8X10G
Cisco cBR-8 Downstream PHY

Module:
• PID—CBR-D31-DS-MOD
Cisco cBR-8 Upstream PHY

Modules:
• PID—CBR-D31-US-MOD
Note Do not use DPICs (8X10G and 2x100G) to forward IP traffic, as it may cause buffer exhaustion, leading to
line card reload.
The only allowed traffic on a DPICs DEPI, UEPI, and GCP traffic from the Cisco cBR-8 router to Remote
PHY devices. Other traffic such as DHCP, SSH, and UTSC should flow via another router, since DPICs
cannot be used for normal routing.
Prerequisites for Cisco Smart Licensing

• You must configure the DNS server using the ip name-server global configuration command.
38
Basic Configuration
Information About Cisco Smart Licensing
• You must configure the IP DNS-based hostname-to-address translation using the ip domain-lookup
global configuration command.
• Cisco Smart Licensing is enabled by default on the Cisco cBR router. However, you must ensure that
the CiscoTAC-1 call-home profile points to the Cisco Smart Software Manager at the following URL
using the show call-home profile CiscoTAC-1 command:
https://tools.cisco.com/its/service/oddce/services/DDCEService
The following is a sample output of the show call-home profile CiscoTAC-1 command:
Router# show call-home profile CiscoTAC-1
Load for five secs: 10%/1%; one minute: 9%; five minutes: 8%
Time source is NTP, 16:49:35.525 PDT Thu Oct 29 2015
Profile Name: CiscoTAC-1

Profile status: ACTIVE
Profile mode: Anonymous Reporting Only
Reporting Data: Smart Call Home, Smart Licensing
Preferred Message Format: xml
Message Size Limit: 3145728 Bytes
Transport Method: http
Email address(es): callhome@cisco.com
HTTP address(es): https://tools.cisco.com/its/service/oddce/services/DDCEService
Periodic configuration info message is scheduled every 19 day of the month at 11:41
Periodic inventory info message is scheduled every 19 day of the month at 11:26
Alert-group Severity
------------------------ ------------
crash debug
diagnostic minor
environment minor
inventory normal
Syslog-Pattern Severity
------------------------ ------------
.* major
• Ensure that you can ping the DNS server. If you are unable to ping the server, verify the connectivity to
the NME port on the Cisco cBR router.
Note If you are using a Virtual Routing and Forwarding (VRF) instance, ensure that
you can ping the VRF instance.
Information About Cisco Smart Licensing

Cisco Smart Licensing is software-based licensing that consists of tools and processes to authorize the customers
for the usage and reporting of the Cisco products. The feature has the capability to capture the customer order
and communicate with the Cisco Cloud License Service through Smart Call Home transport media to complete
the product registration and authorization. If the Cisco products stop communicating with the Cisco Cloud
39
Basic Configuration
Downstream License
License Service for 90 days, the cable interfaces in the Cisco products will be locked, which means the
customer can no longer enable/disable the cable interfaces.
The Cisco Smart Licensing feature is aimed at giving users an experience of a single, standardized licensing
solution for all Cisco products.
In the Cisco Smart Licensing Model, you can activate licensed features (also known as entitlements) without
the use of a special software key or upgrade license file. You can activate the new functionality using the
appropriate product commands and configurations and the functionality is activated. A software reboot is not
required for the Cisco cBR router.
The Cisco cBR router supports software activation using Cisco Smart Licensing. The Cisco Smart Licensing
is enabled by default on the Cisco cBR router.
Note The no http secure server-identity-check option was default in versions 16.7.2 and earlier, and was not
configurable. Ensure that you configure the no http secure server-identity-check option after upgrading to
maintain parity with images earlier than 16.7.3. The default option is http secure server-identity-check.
A LCHA license is needed for each working linecard that is protected by the protect linecard.
Downstream License
The DOCSIS 3.1 license scheme provides support to identify the DOCSIS 3.1 channels and their width. The
DOCSIS 3.1 entitlement is DOCSIS 3.1 Downstream Channel License.
Note Configuration of DOCSIS 3.1 Downstream OFDM channel consumes both DOCSIS 3.0 and DOCSIS 3.1
license in a 1:1 ratio with license units of 6 MHz.
Out of Compliance Enforcement

The following two events are responsible for triggering a DOCSIS configuration lock enforcement.
Eval-Expired (Evaluation Period Expired)
When a router is not registered with Smart License Manager for more than ninety days.
Auth-Expired (authorization Period Expired)
When a registered router fails to communicate with the Smart License Manager for more than ninety
days.
When either of the above mentioned events occur, the Smart Agent sends a notification to the platform. The
platform, upon receiving such notification, locks the following CLI commands:
• [no] cable upstream shutdown upstream-port-number
• contoller upstream-cable slot/subslot/controller-port-number
• rf-chanchannel-number
40
Basic Configuration
How to Configure Cisco Smart Licensing
Any attempt to configure the above mentioned CLIs in this condition would fail and a warning message will
be displayed. Under this condition all other CLIs are configurable, some of which may be required to configure
Cisco License Call Home, connect to cisco and register the device to come out of either of the above two
events and enter into authorized or Out of Compliance (OOC) state.
You can copy the modified configuration file to the startup configuration file and reload the device to make
that configuration effective. However, when the device is in enforced state, you can only copy the running
configuration file to the startup configuration file.
Note Any attempt to copy any other file fails and a warning message is displayed.
How to Configure Cisco Smart Licensing

This section contains the following:
Using Cisco Smart Licensing Agent on the Router
Step 1 Set up a Cisco Smart Account. See Setting Up a Cisco Smart Account, on page 41.
Step 2 Log in to the Cisco Smart Software Manager.
Step 3 (Optional) Create a virtual account. See Creating Virtual Accounts, on page 48.
Note A single default virtual account is always available.
Step 4 Create a product instance registration token. See Creating a Product Instance Registration Token, on page 49.
Step 5 Register the router with the Cisco Licensing Cloud using the product instance registration token. See Registering the
Router with the Cisco Licensing Cloud Using the Registration Token, on page 50.
Step 6 Log in to the Cisco Smart Software Manager for managing licenses.
For more information, see the Cisco Smart Software Manager User Guide, which is accessible from the Cisco Smart
Software Manager tool.
Setting Up a Cisco Smart Account

Cisco Smart Account enables you to fully utilize the license management features of the smart-enabled
products.
Before you begin

• Ensure that you have a CCO ID.
Step 1 Log in to Cisco Software Workspace (CSW) with your CCO ID.
Step 2 Hover the cursor over the Administration tab and click Create Smart Accounts.
41
Basic Configuration
Figure 2: Creating Smart Account
Step 3 Perform one of the following to select the Account Approver:

• To select yourself as the Approver, click the Yes, I will be the Approver for the account radio button.
• To select other person as the Approver, click the No, the person specified below will be the Approver for the
account radio button and specify the person's e-mail ID.
Note The specified Approver must have the authority to enter legal agreements. The Approver serves as the
primary owner and nominates account administrators.
Figure 3: Selecting the Approver
Step 4 If you are the Approver, perform the following:

a) Enter the Account Name, Company/Organization Name, Country, and State/Province/Region information.
b) (Optional) Click Edit. In the Edit Account Identifier window, enter a valid Proposed Domain Identifier and Contact
Phone Number. Click OK.
Note The default domain identifier is the Approver e-mail domain. If you edit the domain identifier, the change
goes through a manual approval process.
42
Basic Configuration
c) Click Continue to select the legal address to be linked to your Cisco Smart Account.
Figure 4: Setting Up Account Information When You Are The Approver
Step 5 If you are not the Approver, perform the following:

a) Enter the Account Name and an optional Message to Approver.
b) (Optional) Click Edit. In the Edit Account Identifier window, enter a valid Proposed Domain Identifier. Click OK.
Note The default domain identifier is the Approver e-mail domain. If you edit the domain identifier, the change
goes through a manual approval process.
c) Click Continue.
Figure 5: Setting Up Account Information When You Are Not The Approver
Step 6 If you are not the Approver, the Approver will receive an e-mail and must perform the following:
a) Click Complete Smart Account Setup in the received e-mail.
43
Basic Configuration
Figure 6: Complete Smart Account Setup Link in E-mail
b) Click the appropriate radio button to accept, decline, or nominate another Approver. To nominate another Approver,
enter the person's e-mail address. Click Continue.
Note If the Approver declines, the Cisco Smart Account is deleted. If the Approver nominates another approver,
the new Approver must accept the role.
Figure 7: Accepting the Account Approver Role
c) After accepting the Approver role, click the appropriate radio button to select the Account Domain Identifier or
specify a different Account Domain Identifier.
44
Basic Configuration
Figure 8: Completing the Account Information
d) Enter the Account Name and click Continue.

The Approver role is accepted and Cisco Smart Account is pending Account Domain approval.
Step 7 After the Account Domain is approved, the Approver will receive an e-mail and must perform the following:
a) Click Complete Smart Account Setup in the received e-mail.
Figure 9: Cisco Smart Account Identifier Approved E-mail
b) Enter the Account Name, Company/Organization Name, Country, and State/Province/Region information.
45
Basic Configuration
Figure 10: Completing the Account Information and Company/Organization Information
c) Click Continue to select the legal address to be linked to the Cisco Smart Account.
d) Select the Company/Organization Primary Address using the Refine Search option and click Continue.
Figure 11: Selecting the Company/Organization Primary Address
e) (Optional) Enter the e-mail addresses of the Additional Account Approvers and Additional Account Administrators.
The initial Approver automatically becomes an Administrator. Additional Administrators can be created or assigned
separately from the Approver creation process.
46
Basic Configuration
Figure 12: Nominating Additional Account Approvers and Administrators
f) Click Continue.
g) Review the agreement and check the I agree to the terms above check box to accept.
h) Click Accept and Create Account to create the Cisco Smart Account.
Figure 13: Accepting the Agreement and Creating the Cisco Smart Account
You will receive an e-mail confirming the creation of the Cisco Smart Account.
47
Basic Configuration
Creating Virtual Accounts
Creating Virtual Accounts

This procedure is optional. Virtual accounts are collections of licenses and product instances. You can create
virtual accounts in Cisco Smart Software Manager to organize the licenses for your company into logical
entities. A single virtual account is available by default.
Before you begin

Set up a Cisco Smart Account. See Setting Up a Cisco Smart Account, on page 41.

Step 2 Click the + (plus) symbol to create a virtual account.
Figure 14: Creating a Virtual Account
Step 3 In the New Virtual Account dialog box, enter the Name and Description.
Figure 15: New Virtual Account Dialog Box
48
Basic Configuration
Creating a Product Instance Registration Token
Step 4 Click Save.
Creating a Product Instance Registration Token

Product instance registration tokens are used to register and consume a product for Cisco Smart Licensing.
You must generate a token to register the product and add the product instance to a specified virtual account.
Registration tokens can be valid from 1 to 365 days.

Step 2 Click an existing virtual account.
Step 3 In the General tab, click New Token.
Figure 16: Creating a New Registration Token
Step 4 In the Create Registration Token dialog box, enter the Description and Expire After information and click Create
Token.
49
Basic Configuration
Registering the Router with the Cisco Licensing Cloud Using the Registration Token
Figure 17: Create Registration Token Dialog Box
What to do next
Register the router with the Cisco Licensing Cloud. For more details, see the Registering the Router with the
Cisco Licensing Cloud Using the Registration Token, on page 50 section.
Registering the Router with the Cisco Licensing Cloud Using the Registration
Token
The router registration is performed only once for each product instance.
Note Ensure that you have the product instance registration token.
To register the router with the Cisco Licensing Cloud using a registration token, use the following commands:
enable
license smart register idtoken id-token
For example:
Router#license smart register idtoken
YjBkOWM5YTItMDFiOS00ZjBmLTllY2YtODEzMzg1YTMyZDVhLTEz
ODE0MjE0%0ANzc5NDF8U1BDUTAySWFRTmJqa1NnbmlzRUIyaGlYU
053L0pHZTNvUW9VTFpE%0AekxCOD0%3D%0A
The system contacts the Cisco Smart Licensing servers to obtain authorization for Smart Licensing.
50
Basic Configuration
Re-establishing Connectivity to Cisco Smart Call Home Server
The license agent registers the product with Cisco and receives an identity certificate. This certificate is saved
and automatically used for all future communications with Cisco. The license agent automatically renews the
registration information with Cisco every 30 days.
Note Smart licensing may fail if IPv6 is configured on any interface, and the router does not have IPv6 connectivity
to the Internet or Cisco Smart Software Agent (at tools.cisco.com). Log file error messages similar to the
following may appear.
(These messages may also appear as a result of other conditions being true.)
%SMART_LIC-3-AGENT_REG_FAILED: Smart Agent for Licensing Registration with Cisco licensing
cloud failed: Fail to send out Call Home HTTP message.
%SMART_LIC-3-COMM_FAILED: Communications failure with Cisco licensing cloud: Fail to send
out Call Home HTTP message.
If connectivity fails due to this issue, see the Re-establishing Connectivity to Cisco Smart Call Home Server
section.
After connectivity is established, register the router with the Cisco Licensing Cloud.
Re-establishing Connectivity to Cisco Smart Call Home Server

This section describes what to do when the router fails to connect to the Cisco Smart Call Home Server and
IPv6 is configured.
The following scenarios are applicable:
• If the interface is configured using the ip http client source-interface interface CLI and has the IPv6
address, the router establishes a session with the remote server with IPv6 connectivity.
• If the interface is configured using the ip http client source-interface interface command and has the
IPv4 address, the router establishes a session with the remote server with IPv4 connectivity.
• If the interface is configured using ip http client source-interface interfacecommand, and has an IPv6
address and an IPv4 address, the router establishes a session with the remote server with IPv6 connectivity.
• If the interface is not configured using the ip http client source-interface interface, the router establishes
a session with the remote server with the IPv6 address.
For Cisco IOS XE Everest 16.5.1 or later, if an IPv6 address is available for an interface and the device cannot
connect to the Internet or Cisco Smart Software Agent, configure the interface to only use IPv4 for smart
licensing, by running the following configuration mode command.
ip http client source-interface interface
How to Configure Cisco Smart Licensing using Transport

Gateway Solution
The steps below describe how to configure Cisco smart licensing using transport gateway solution.
51
Basic Configuration
How to Configure Cisco Smart Licensing using Transport Gateway Solution
Procedure

Example: • Enter your password if prompted.
Router> enable

Example:
Step 3 crypto pki trustpoint Declare the trustpoint that the router should use.
Example:
Router(config)# crypto pki trustpoint cisco
Step 4 enrollment terminal Specify manual cut-and-paste certificate enrollment.

Example:
Router(ca-trustpoint)# enrollment terminal
Step 5 revocation-check method Check the revocation status of a certificate. Method none
means certificate checking is not required.
Example:
Router(ca-trustpoint)# revocation-check none
Step 6 crypto pki authenticate Authenticate the certification authority.

Example:
Router(config)# crypto pki authenticate cisco
Step 7 no reporting smart-licensing-data Configure the default profile to not to communicate with
tools.cisco.com.
Example:
Router(config)# call-home
Router(cfg-call-home)# profile CiscoTAC-1
Router(cfg-call-home-profile)# no reporting
smart-licensing-data
Step 8 destination address http address Configure the custom profile to communicate with the
transport server, here we use Custom Profile 1 as the name
Example:
of the custom profile.
Router(config)# call-home
Router(cfg-call-home)# profile Custom-Profile-1
Router(cfg-call-home-profile)# reporting
smart-licensing-data
Router(cfg-call-home-profile)# destination
transport-method http
Router(cfg-call-home-profile)# no destination
transport-method email
Router(cfg-call-home-profile)# destination address
http
https://TDS.IP.HERE:8443/Transportgateway/services/DeviceRequestHandler
52
Basic Configuration
Configuring 100G Licenses for Supervisor 250G
Configuring 100G Licenses for Supervisor 250G

The Cisco cBR Smart Account supports both 100G WAN licenses and 10G WAN licenses.
You need to configure the Cisco cBR to consume 100G WAN licenses for Supervisor 250G. This would
accommodate existing 10G WAN licenses for 100G port, in addition to the 100G WAN license.
Starting from Cisco cBR release IOS-XE 16.8.1, there will be two types of WAN licenses in the Smart Account
for WAN ports on the Cisco cBR Supervisor 250G module:
• 100G WAN license: By default, the Smart Account will consume the 100G WAN license for 100G WAN
port.
• 10G WAN license: Can be applied to 10G and 100G WAN ports.
Overview of 100G License for Supervisor 250G

With the 100G WAN licenses, you can facilitate the ordering and management of WAN license for Supervisor
250G. This would help avoid the overhead of maintaining multiple 10G WAN licenses, and you can manage
a single 100G WAN license for one 100G port of Supervisor 250G, instead of ten individual 10G WAN
licenses.
However, there is no auto-conversion between 10G WAN licenses and 100G WAN licenses. They must be
ordered and managed separately. If you are an existing customer using 10G WAN license for Supervisor
250G and have not purchased any 100G WAN licenses, the Cisco Smart Licensing will report out of compliance
when attempting to upgrade to Cisco cBR release IOS-XE 16.8.1.
For information on configuring the Cisco cBR to consume 10G WAN licenses on 100G port for Supervisor
250G, see Applying 10G WAN License to the 100G WAN Ports, on page 53.
Note • In Supervisor 160, there is no 100G WAN interface and WAN 100G License. The display is same as the
previous release.
• The 100G license feature does not support an ISSU downgrade. This might cause a standby SUP crash.
Applying 10G WAN License to the 100G WAN Ports

Ensure that you go through Overview of 100G License for Supervisor 250G, on page 53 for an understanding
of the feature and the restrictions.
The Smart Account will consume the 100G WAN license for 100G WAN port by default. To apply the 10G
WAN licenses for the 100G WAN port, complete the following step.
SUMMARY STEPS
1. You can apply the 10G WAN license to the 100G WAN ports using the following command:
53
Basic Configuration
Displaying the License Information
DETAILED STEPS

Step 1 You can apply the 10G WAN license to the 100G WAN
ports using the following command:
Example:
Router(config)# cable license 100G-conversion
To disable the 10G WAN license for 100G WAN ports,

run the command with the no option. This would enable
the 100G WAN ports to consume 100G WAN license.
Router(config)# no cable license 100G-conversion

You can use the following command options to display the license information, based on wether the license
has been configured or not:
SUMMARY STEPS
1. Run either of the following command options to display license information.
• By default, or with the no option, the ports will consume a 100G WAN license for a 100G WAN
port.
For example if the no cable license 100G-conversion command has been issued, the responses to
the show cable license wan and show license summary commands would be in the following format:
Router(config)# show cable license wan

--------------------------------------------
Entitlement: WAN License
Consumed count: 0
Consumed count reported to SmartAgent: 0
Enforced state: No Enforcement
--------------------------------------------
Entitlement: WAN 100G License
Consumed count: 2
Router(config)# show license summary

Smart Licensing is ENABLED
Registration:
Status: REGISTERED
Smart Account: CBR8_DEV_1
Virtual Account: cbr8-dev-test
Export-Controlled Functionality: Allowed
Last Renewal Attempt: None
Next Renewal Attempt: Jun 13 00:47:13 2018 CST
License Authorization:
Status: AUTHORIZED
54
Basic Configuration
Last Communication Attempt: SUCCEEDED

Next Communication Attempt: Jan 14 11:34:13 2018 CST
License Usage:
License Entitlement tag Count Status
-----------------------------------------------------------------------------
regid.2017-09.com.ci... (WAN_100G_License) 2 AUTHORIZED
• With the cable license 100G-conversion command, it will consume 10G WAN license for 100G
WAN port.
For example if the cable license 100G-conversion command has been issued, the responses to the
show cable license wan and show license summary commands would be in the following format:
Router(config)# show cable licenses wan

--------------------------------------------
Consumed count: 20
--------------------------------------------
Consumed count: 0

Registration:
Status: REGISTERED
Next Renewal Attempt: Jun 13 00:47:13 2018 CST
Status: AUTHORIZED
Next Communication Attempt: Jan 14 11:25:01 2018 CST
License Usage:
-----------------------------------------------------------------------------
regid.2014-11.com.ci... (WAN_License) 20 AUTHORIZED
DETAILED STEPS

Step 1 Run either of the following command options to display
license information.
• By default, or with the no option, the ports will
consume a 100G WAN license for a 100G WAN port.
55
Basic Configuration

For example if the no cable license 100G-conversion
command has been issued, the responses to the show
cable license wan and show license summary
commands would be in the following format:
Router(config)# show cable license wan

--------------------------------------------
Consumed count: 0
--------------------------------------------
Consumed count: 2
Registration:
Status: REGISTERED
Next Renewal Attempt: Jun 13 00:47:13 2018
CST
Status: AUTHORIZED
Next Communication Attempt: Jan 14 11:34:13
2018 CST
License Usage:
License Entitlement tag
Count Status
-----------------------------------------------------------------------------
regid.2017-09.com.ci... (WAN_100G_License)
2 AUTHORIZED
• With the cable license 100G-conversion command,

it will consume 10G WAN license for 100G WAN
port.
For example if the cable license 100G-conversion
command has been issued, the responses to the show
cable license wan and show license summary
commands would be in the following format:
Router(config)# show cable licenses wan

--------------------------------------------
56
Basic Configuration
Feature Information for 100G License for Supervisor 250G

Consumed count: 20
--------------------------------------------
Consumed count: 0

Registration:
Status: REGISTERED
Next Renewal Attempt: Jun 13 00:47:13 2018
CST
Status: AUTHORIZED
Next Communication Attempt: Jan 14 11:25:01
2018 CST
License Usage:
License Entitlement tag
Count Status
-----------------------------------------------------------------------------
regid.2014-11.com.ci... (WAN_License)
20 AUTHORIZED
Feature Information for 100G License for Supervisor 250G

57
Basic Configuration
Verifying Cisco Smart Licensing Configuration
Table 3: Feature Information for 100G License for Supervisor 250G
100G License for Supervisor Cisco IOS-XE Release This feature was integrated into Cisco IOS-XE
250G 16.8.1 Release 16.8.1 on theCisco cBR Series Converged
Broadband Routers.

Use the following commands to verify the Cisco Smart Licensing Configuration on the Cisco cBR router:
• show license all—Displays all the license information.
The following is a sample output of this command:
Router# show license all
Smart Licensing Status

======================
Registration:
Status: REGISTERED
Virtual Account: auto-test-1
Initial Registration: SUCCEEDED on Mar 5 02:01:03 2015 UTC
Next Renewal Attempt: Sep 1 02:03:51 2015 UTC
Registration Expires: Never
Status: OUT OF COMPLIANCE on Mar 5 03:34:54 2015 UTC
Last Communication Attempt: SUCCEEDED on Mar 5 03:35:57 2015 UTC
Next Communication Attempt: Mar 5 15:35:57 2015 UTC
Communication Deadline: Jun 3 03:32:51 2015 UTC
License Usage
==============
(US_License):
Description:
Count: 64
Version: 1.0
Status: AUTHORIZED
(DS_License):
Description:
Count: 768
Version: 1.0
Status: AUTHORIZED
(WAN_License):
Description:
Count: 8
Version: 1.0
Status: OUT OF COMPLIANCE
Product Information
===================
58
Basic Configuration
UDI: PID:CBR-8-CCAP-CHASS,SN:FXS1739Q0NT
HA UDI List:
Active:PID:CBR-8-CCAP-CHASS,SN:FXS1739Q0NT
Standby:PID:CBR-8-CCAP-CHASS,SN:FXS1739Q0NT
Agent Version
=============
Smart Agent for Licensing: 1.2.1_throttle/5
Component Versions: SA:(1_2_1_throttle)1.1.0, SI:(rel20)1.0.1, CH:(rel4)1.0.15,
PK:(rel16)1.0.7
• show license status—Displays the license status information.

Router# show license status
Registration:
Status: REGISTERED
• show license summary—Displays the license summary information.

Router# show license summary
Registration:
Status: REGISTERED
License Usage:
---------------------------------------------------------------
(US_License) 64 AUTHORIZED
(DS_License) 768 AUTHORIZED
(WAN_License) 8 OUT OF COMPLIANCE
• show license tech support—Displays the license technical support information.
59
Basic Configuration

Router# show license tech support
Smart Licensing Tech Support info
Smart Licensing Status

======================
Registration:
Status: REGISTERED
Evaluation Period:
Evaluation Mode: Not In Use
Evaluation Period Remaining: 89 days, 23 hours, 25 minutes, 40 seconds
License Usage
=============
Handle: 1
License: 'nullPtr'
Entitlement Tag:
regid.2014-11.com.cisco.US_License,1.0_a3f32909-2c71-426c-b3e0-eeefc946f9b3
Description: <empty>
Count: 64
Version: 1.0
Status: AUTHORIZED(3)
Status time: Mar 5 03:34:54 2015 UTC
Request Time: Mar 5 03:34:17 2015 UTC
Handle: 2
License: 'nullPtr'
Entitlement Tag:
regid.2014-11.com.cisco.DS_License,1.0_71ad0ae1-5e5e-4f02-b380-d2e1b8dcfa03
Count: 768
Version: 1.0
Status: AUTHORIZED(3)
Handle: 3
License: 'nullPtr'
Entitlement Tag:
regid.2014-11.com.cisco.WAN_License,1.0_3d8bb7ba-1a92-4f01-a4aa-a4479f1d7612
Count: 8
Version: 1.0
Status: OUT OF COMPLIANCE(4)
60
Basic Configuration
Product Information
===================
HA UDI List:
Agent Version
=============
Smart Agent for Licensing: 1.2.1_throttle/5
Component Versions: SA:(1_2_1_throttle)1.1.0, SI:(rel20)1.0.1, CH:(rel4)1.0.15,
PK:(rel16)1.0.7
Upcoming Scheduled Jobs

=======================
Current time: Mar 5 03:37:46 2015 UTC
IdCert Expiration Warning: Jan 4 02:00:41 2016 UTC (304 days, 22 hours, 22 minutes,
55 seconds remaining)
Daily: Mar 6 03:21:11 2015 UTC (23 hours, 43 minutes, 25 seconds remaining)
Certificate Renewal: Sep 1 02:03:51 2015 UTC (179 days, 22 hours, 26 minutes, 5 seconds
remaining)
Certificate Expiration Check: Mar 4 02:00:41 2016 UTC (364 days, 22 hours, 22 minutes,
Authorization Renewal: Mar 5 15:35:57 2015 UTC (11 hours, 58 minutes, 11 seconds
remaining)
Authorization Expiration Check: Jun 3 03:32:51 2015 UTC (89 days, 23 hours, 55 minutes,
Init Flag Check: Not Available
License Certificates
====================
Production Cert: True
PIID: 36bf91ae-0577-4213-9e62-1b6ee0add02f
Licensing Certificated:
Id certificate Info:
Start Date: Mar 5 01:57:54 2015 UTC
Expiry Date: Mar 4 01:57:54 2016 UTC
Version Number: 3
Serial Number: 134418
Common Name: 05FB26B1A58A106DEA6878C346432186D08BC1C5::1,2
Signing certificate Info:

Start Date: Jun 14 20:18:52 2013 UTC
Expiry Date: Apr 24 21:55:42 2033 UTC
Version Number: 3
Serial Number: 3
Common Name: MMI Signer
Sub CA Info:
Start Date: Apr 24 22:19:15 2013 UTC
Expiry Date: Apr 24 21:55:42 2033 UTC
Version Number: 3
Serial Number: 2
Common Name: Smart Licensing CA - DEV
HA Info
==========
RP Role: Active
Chassis Role: Active
Behavior Role: Active
RMF: True
CF: True
61
Basic Configuration
CF State: Stateless
Other Info
==========
Software ID: regid.2014-12.com.cisco.CBR8V1,1.0_95948658-0b8b-4e8f-838d-b17020364ca9
Agent State: OOC
TS enable: True
Transport: Callhome
Locale: en_US.UTF-8
Debug flags: 0x7
Privacy Send Hostname: True
Privacy Send IP: True
Build type:: Production
sizeof(char) : 1
sizeof(int) : 4
sizeof(long) : 4
sizeof(char *): 8
sizeof(time_t): 4
sizeof(size_t): 8
Endian: Big
enableOnInit: True
routingReadyByEvent: True
systemInitByEvent: True
WaitForHaRole: False
standbyIsHot: True
chkPtType: 2
delayCommInit: False
roleByEvent: True
maxTraceLength: 150
traceAlwaysOn: False
debugFlags: 7
• show license udi—Displays the license Unique Device Identifier (UDI) information.
Router# show license udi
HA UDI List:
• show license usage—Displays the license usage information.

Router# show license usage
(US_License):
Description:
Count: 64
Version: 1.0
Status: AUTHORIZED
(DS_License):
Description:
Count: 768
Version: 1.0
Status: AUTHORIZED
62
Basic Configuration
(WAN_License):
Description:
Count: 8
Version: 1.0
• show call-home profile all—Displays the call home profile information for all configured profiles.
Router# show call-home profile all
Profile Name: CiscoTAC-1

Profile status: ACTIVE
Profile mode: Full Reporting
Reporting Data: Smart Call Home, Smart Licensing
Preferred Message Format: xml
Message Size Limit: 3145728 Bytes
Transport Method: http
Email address(es): callhome@cisco.com
HTTP address(es): https://tools.cisco.com/its/service/oddce/services/DDCEService
Periodic configuration info message is scheduled every 25 day of the month at 10:03
Periodic inventory info message is scheduled every 25 day of the month at 09:48
Alert-group Severity
------------------------ ------------
crash debug
diagnostic minor
environment minor
inventory normal
Syslog-Pattern Severity
------------------------ ------------
.* major
• show call-home smart-licensing statistics—Displays the call home smart licensing statistics information.
Router# show call-home smart-licensing statistics
Success: Successfully sent and response received.

Failed : Failed to send or response indicated error occurred.
Inqueue: In queue waiting to be sent.
Dropped: Dropped due to incorrect call-home configuration.
Msg Subtype Success Failed Inqueue Dropped Last-sent (GMT-06:00)

----------------------------------------------------------------------
REGISTRATION 1 0 0 0 2015-03-13 13:12:13
ACKNOWLEDGEMENT 1 0 0 0 2015-03-13 13:12:20
ENTITLEMENT 5 0 0 0 2015-03-13 13:22:18
Use the following commands to verify the DOCSIS 3.1 Downstream License on the Cisco cBR router:
• show cable license all | begin D3.1—Displays all the DOCSIS 3.1 downstream license information.
63
Basic Configuration
Troubleshooting Cisco Smart Licensing
Router# show cable license all | begin D3.1
Time source is NTP, 10:41:11.175 PST Mon May 9 2016
--------------------------------------------
Entitlement: DOCSIS 3.1 Downstream Channel License
Consumed count: 31
Use the following commands to verify the DOCSIS 3.1 Upstream Exclusive License on the Cisco cBR router:
• • show cable licenses us_d31_exclusive—Displays the DOCSIS 3.1 upstream exclusive license
information.
Router# show cable licenses us_d31_exclusive
Time source is NTP, *10:14:30.935 CST Tue Jun 6 2017
--------------------------------------------
Entitlement: DOCSIS 3.1 Upstream Channel Exclusive License
Total Licensed Spectrum: 188000000Hz
Consumed count: 188
Troubleshooting Cisco Smart Licensing

Before taking the steps below to troubleshoot the Cisco Smart Licensing, the customers should first make
sure the configuration is correct and see if they are able to ping the HTTP address they have configured for
the smart license. The output of the show call-home smart-licensing statistics command should have
REGISTERED and ACKNOWLEDGE information. And check the output of show logging | include SMART
| CALL.
Manually Renewing the Smart License Registration

The license agent automatically renews the registration information with Cisco every 30 days. You may need
to manually renew the registration if the license is out of compliance and it needs to be registered immediately.
Procedure

Router> enable
Step 2 license smart renew Manually renews the license registration of the device
instance with Cisco.
Example:
Router# license smart renew
64
Basic Configuration
Unregistering the Router from Cisco Smart Licensing
Unregistering the Router from Cisco Smart Licensing

You can unregister the router from Cisco Smart Licensing. You may need to unregister the router for the
Return Material Authorization (RMA) of the router.
Procedure

Router> enable
Step 2 license smart deregister Removes the Cisco Smart Licensing registration for the
device instance. All Cisco Smart Licensing certificates and
Example:
entitlements are removed.
Router# license smart deregister
Additional References
Related Documents
Related Topic Document Title

Cisco Smart Licensing Cisco Smart Software Licensing
Technical Assistance
Description Link
The Cisco Support website provides extensive online resources, including http://www.cisco.com/support
documentation and tools for troubleshooting and resolving technical issues
with Cisco products and technologies.
To receive security and technical information about your products, you can
subscribe to various services, such as the Product Alert Tool (accessed from
Field Notices), the Cisco Technical Services Newsletter, and Really Simple
Syndication (RSS) Feeds.
Access to most tools on the Cisco Support website requires a Cisco.com user
ID and password.
Feature Information for Cisco Smart Licensing

65
Basic Configuration
Feature Information for Cisco Smart Licensing
Table 4: Feature Information for Cisco Smart Licensing
Cisco Smart Licensing Cisco IOS XE Fuji This feature was integrated on theCisco cBR
16.7.1 Series Converged Broadband Routers.
DOCSIS 3.1 US Channel Cisco IOS XE Fuji This feature was integrated on theCisco cBR
Licensing 16.7.1 Series Converged Broadband Routers.
66
CHAPTER 3
Core Peak Bandwidth Licensing
The Core Peak Bandwidth (CPB) license enables you to manage Cisco cBR-8 routers with one comprehensive
license, unlike the multiple license types associated with the traditional licensing models. This document
provides information on CPB and how to configure the license on Cisco cBR-8 routers.
• Core Peak Bandwidth License, on page 67
• Configure CPB on Cisco cBR Routers, on page 68
• Feature Information for Core Peak Bandwidth Licensing , on page 69
Core Peak Bandwidth License

The CPB licensing plan functions on a quarterly basis. In this plan, you pay for additional Core Peak Bandwidth
licenses that you require. The cost of the CPB licenses is proportional to the number of subscribers on the
Cisco cBR-8 router, as the network traffic through a CCAP core is proportional to the number of subscribers
on the router.
In each quarter, as the CPB grows, additional CPB licenses equal to the growth are automatically billed and
added to your existing CPB license inventory.
CPB Calculation
The total CPB is calculated by measuring the core traffic through all the CCAP cores, taking the 95th percentile
of the monthly peak, and reporting the quarterly value on the first day of the next quarter to the Smart License
server to automatically manage the licensing process. The Smart License server automatically invoices for
additional licensing needs and then delivers the licenses when you pay.
The traffic rate is measured every 5 minutes. Cisco cBR-8 routers save this data for a minimum of three
months. The monthly CPB value is calculated and the maximum monthly value is considered as the quarterly
CPB.
When you enable CPB on Cisco cBR-8, the initial CPB value is measured as 1.
For measuring the CPB, 12 samples are collected in every hour, which is one sample every 5 minutes. Due
to a maintenance window or a shutdown, which approximately is less than 5 hours, if samples are lost and
the number of lost samples is more than 60 in a month, the cable operator is notified with an error message.
If the chassis serial number does not match the local chassis serial number, these sample records are deleted
when starting the router or rebooting it. The sample history is also cleared when a Supervisor card is replaced.
67
Basic Configuration
Configure CPB on Cisco cBR Routers
To calculate the monthly CPB value, the Cisco cBR router rates all samples collected in one month based on
the speed. For example, if 8767 samples are collected in a month, and the 8767th sample is the fastest, then
the 95th percentile is the 8329th sample rated by speed (consider the first sample as the slowest and the 8767th
the fastest). Hence, the CPB value for that month is the value of the 8329th sample divided by 100 (100Mbps).
Configure CPB on Cisco cBR Routers

Enable CPB Licensing
To enable CPB and show only the CPB usage, use the following command. When you enable CPB, the other
existing licensing features are canceled automatically.
cable license enable-CPB
Use the no cable license enable-CPB command to disable CPB. By default, CPB is disabled on Cisco
cBR routers.
View CPB Usage Details

To display CPB usage information, use the following command:
show cable licenses cpb
Example: Show CPB Usage Details

The following example shows CPB usage details:
show cable licenses cpb
Entitlement: CPB License
Consumed count: 987
Quarterly CPB is 987 (100Mbps) in the First quarter of 2018.
First monthly CPB is: 103585495480 bps, 987 (100Mbps).
Second monthly CPB is: 103595095264 bps, 987 (100Mbps).
Third monthly CPB is: 103595124064 bps, 987 (100Mbps).
View Details of All Licenses

To display the usage information of all licenses, use the following command.
If you enable CPB, this command displays only the CPB usage information. If CPB is disabled, the command
displays the usage information of all existing licenses.
show cable licenses all
Example: View Details of All Licenses

The following example shows the usage information of all licenses, when CPB is enabled.
show cable licenses all
Entitlement: CPB License
Consumed count: 987
68
Basic Configuration
View CPB Sample History
Quarterly CPB is 987 (100Mbps) in the First quarter of 2018.

First monthly CPB is: 103585495480 bps, 987 (100Mbps).
Second monthly CPB is: 103595095264 bps, 987 (100Mbps).
Third monthly CPB is: 103595124064 bps, 987 (100Mbps).
View CPB Sample History

To display the details of the CPB sample history, use the following command.
show cable licenses cpb-records year <year> month <month> day <day>
Example: View CPB Sample History

The following example CPB sample history.
show cable licenses cpb-records year 2018 month 4 day 28
index: 34626, timestamp: 28-April-2018 05:30:02 UTC, 5min rate: 105291741536 bps, 1004
(100Mbps)
(100Mbps)
(100Mbps)
(100Mbps)
(100Mbps)
(100Mbps)
----------------------------------------------
There are 6 cpb records in Apr 28 2018 UTC.
Feature Information for Core Peak Bandwidth Licensing

Table 5: Feature Information for Core Peak Bandwidth Licensing
Core Peak Bandwidth Licensing Cisco IOS XE Fuji 16.9.1a This feature was introduced on Cisco
cBR Series Converged Broadband
Routers.
69
Basic Configuration
Feature Information for Core Peak Bandwidth Licensing
70
CHAPTER 4
Capped License Enforcement
This document provides information on the Capped License feature and on how to configure it on Cisco cBR
Series Routers.
• Information About Capped License Support, on page 73
• How to Configure Capped License Enforcement, on page 74
• Configuration Examples, on page 74
• Feature Information for Capped License Enforcement, on page 75
71
Basic Configuration
Digital PICs:

Module:

Modules:
line card reload.
72
Basic Configuration
Information About Capped License Support
Information About Capped License Support

The capped license enforcement feature allows you to set a limit to the number of licenses for each licensed
feature on Cisco cBR-8. Hence, with this feature, the uncontrolled usage of licensed features and the accidental
consumption of more resources are kept under check. It also enables the users to track the usage per device
and controls the usage of resources upfront.
If any of the capped enforcement limit is lower than the current usage number, you cannot apply the capped
license option.
If capped enforcement is already in effect, the user cannot access more resources than the capped limit. The
number of feature licenses accessed must be less than or equal to the capped count.
Smart License feature, which is a Reporting Model, discourages license enforcement. Hence, the Capped
License Enforcement feature is disabled by default and is not publicized to every customer.
SNMP-MIB-based Capped Enforcement

Set the cap for the features and enable the Capped-Enforcement feature using the SNMP set command. The
SNMP set command is successful only when the cap enforcement count for all the features are greater than
or equal to the current usage count. If the usage count for any feature is above the cap count, shutdown those
resources and make sure that they are below or equal to the cap limit before issuing the SET command.
Platform, after synchronizing those values with the standby RP, enables the capped enforcement. So if the
user tries to increase the usage beyond the CAP values, the resource are blocked and warning messages appear.
During the Return Material Authorization (RMA) of the SUP and when the SUP is moved across chassis, the
stored cap numbers and the values configured while enabling cap enforcement are cleared. However, in a
system with standby RP, if the standby RP has taken over, when the new RP is plugged in during RMA, the
values are synced. In a non-redundant system, reissue the SNMP SET command after an RMA or when an
SUP is moved across the chassis.
You cannot enable capped enforcement on Cisco cBR-8, which is already in a configuration lock state.
However, a Cisco cBR8 that is cap enabled or not when fails to communicate with the license server for more
than 90 days, moves to configuration lock state.
If you do not set the CAP count for a feature, the value is set to the default 0xfff_ffff (268435455).
Use Case Scenarios

The following table shows the use cases for SNMP-MIB-based capped enforcement.
If the entitlement usage is less than or equal You can configure the limit and turn on additional resources.
to the CAP count When the feature usage reaches the CAP count, the platform
prevents the additional usage.
If the entitlement usage is greater than the CAP Stops the SNMP command from running. A message appears
count to inform you about this scenario and the difference in the
count.
The following table shows the conditions under which you must set the CAP enable and the CAP count
options.
73
Basic Configuration
How to Configure Capped License Enforcement
Scenario Non Redundant Cisco cBR Redundant Cisco cBR
First-time boot Yes Yes
System reload No No
SSO N/A No
SUP RMA Yes No
Moving SUP across chassis Yes No
How to Configure Capped License Enforcement

Configuring Capped License Enforcement

To configure the Capped License Enforcement, use the SNMP command as given in the following example.
Change the MIB value by running the following command from a Linux server:
snmpget -v <snmp_version_information> -c <snmp_readonly_community>
<cBR8_Server_IP> <MIB_OID>
snmpset -v <snmp_version_information> -c <snmp_read_write_community>
<cBR8_Server_IP> <MIB_OID> <object_type> <value>
Viewing the License Usage Count

To view the license usage count of the current configuration, use the show cable license all command as given
in the following example.
Router-config# show cable license all
Configuration Examples
The following example shows how to get the EnforcementEnabled Global value using the community private
on the server 172.25.15.210 using SNMP version 2c:
$ snmpget -v 2c -c public 172.25.15.210 1.3.6.1.4.1.9.9.839.1.1.3.0
The following example shows how to set the EnforcementEnabled Global value using the community private
on the server 172.25.15.210 using SNMP version 2c.
$ snmpset -v 2c -c private 172.25.15.210 1.3.6.1.4.1.9.9.839.1.1.3.0 i 1
The following example shows how to set the DS license cap limit to 999999.
$ snmpset -v 2c -u private 123 172.25.15.210 1.3.6.1.4.1.9.9.839.1.1.4.1 u 999999
74
Basic Configuration
Feature Information for Capped License Enforcement

Table 7: Feature Information for Capped License Enforcement
Capped License Enforcement Cisco IOS XE Everest 16.6.1 This feature was introduced in Cisco
IOS XE Everest 16.6.1 on Cisco cBR
75
Basic Configuration
76
CHAPTER 5
Consolidated Packages and SubPackages
Management
This document discusses how consolidated packages and software subpackages (individual and optional) are
run and managed on the Cisco cBR Series Converged Broadband Router. It contains the following sections:
• Finding Feature Information, on page 77
• Running the Cisco cBR Series Routers Using Individual and Optional SubPackages: An Overview , on
page 77
• Running the Cisco cBR Series Routers Using a Consolidated Package: An Overview , on page 78
• Running the Cisco cBR Series Routers: A Summary , on page 78
• Software File Management Using Command Sets , on page 79
• Managing and Configuring the Router to Run Using Consolidated Packages and Individual SubPackages,
on page 80
• Upgrading Individual SubPackages, on page 100
• Feature Information for Consolidated Packages and SubPackages Management, on page 108
Finding Feature Information

Running the Cisco cBR Series Routers Using Individual and

Optional SubPackages: An Overview
The Cisco cBR Series Converged Broadband Router can be configured to run using individual subpackages
and optional subpackages.
77
Basic Configuration
Running the Cisco cBR Series Routers Using a Consolidated Package: An Overview
When the router is configured to run using individual and optional subpackages:
• Each individual subpackage within a consolidated package is extracted onto the router as its own file.
• Additionally, any optional subpackages must be separately downloaded and stored in the same directory
with the provisioning file and the other individual subpackages that have been extracted.
• The router then runs by accessing each file as needed for operational purposes. All individual and optional
subpackage files must be stored in the same directory on the router for the router to run properly using
individual subpackages.
When the router runs using the individual and optional subpackages, the router needs to be configured to boot
using the provisioning file that was included in the consolidated package with the individual subpackage files.
This provisioning file must also be in the same directory as the individual and optional subpackage files. The
router boots faster when configured to run using individual and optional subpackages than it does when
configured to run using a consolidated package.
A Cisco cBR Series Router cannot be configured to run individual and optional subpackages stored on a TFTP
or any other network server. To use this method of running the router, copy the individual and optional
subpackages along with the provisioning file onto the bootflash: file system.
Running the Cisco cBR Series Routers Using a Consolidated

Package: An Overview
The Cisco cBR Series Converged Broadband Router can also be configured to run using a consolidated
package.
Note Booting the router from a consolidated package is not supported for installation of optional subpackages.
When the router is configured to run using a consolidated package, the entire consolidated package file is
copied onto the router or accessed by the router via TFTP or another network transport method. The router
runs using the consolidated package file.
A router configured to run using a consolidated package is booted by booting the consolidated package file.
Because this file is large, the boot process for routers running using the consolidated package is slower than
the boot process for routers running individual subpackages.
A router configured to run using a consolidated package does have some advantages over a router configured
to run individual subpackages. First, a consolidated package can be booted and utilized using TFTP or another
network transport method. Secondly, configuring the router to use the one consolidated package file is easier
than managing several individual subpackage files. Running the router using a consolidated package may be
the right method of running the router in certain networking environments.
The consolidated package should be stored on bootflash:, usb[0-1]:, or a remote file system when this method
is used to run the router.
Running the Cisco cBR Series Routers: A Summary

The advantages of running your router using individual subpackages include:
78
Basic Configuration
Software File Management Using Command Sets
• The router boots fastest when booted using the individual subpackage boot approach.
• Individual subpackages can be upgraded instead of the complete consolidated image.
The advantages of running your router using a consolidated package include:

• Simplified installation—Only one software file needs to be managed instead of several separate images.
• Storage—A consolidated package, unlike individual subpackages, can be used to run the router while
being stored in bootflash:, on a USB Flash disk, or on a network server. A consolidated package can be
booted and utilized using TFTP or another network transport method, while the individual subpackage
method requires the individual subpackage files to be copied into the bootflash: file directory on the
router.
Approach Advantages Disadvantages
Individual and optional Faster boot time. • Multiple software

subpackages subpackages more difficult to
manage.
Note This method is required
if you need to install any • Cannot be booted from TFTP
optional subpackages or any other network server.
for your system. If you are going to use the
individual subpackage boot
method, each individual
subpackage file must be
placed in the bootflash:
directory.
• Individual and optional
subpackage files and the
provisioning file must be
stored in bootflash:.
Consolidated Package • Easier management. Only Slower boot times and lessened
have to manage one file maximum system scalability
instead of many files. because the larger image must be
processed at all times.
• A consolidated package file
can be stored in bootflash:, on
any TFTP or other network
server.
Software File Management Using Command Sets

Software files can be managed on the Cisco cBR Series Converged Broadband Router using the following
distinct command sets.
79
Basic Configuration
Managing and Configuring the Router to Run Using Consolidated Packages and Individual SubPackages
The request platform Command Set

The request platform software package command is part of the larger request platform command set being
introduced on the Cisco cBR Series Converged Broadband Router.
The request platform software package command, which can be used to upgrade individual subpackages
and a complete consolidated package, is used to upgrade software on the Cisco cBR Series Converged
Broadband Router. Notably, the request platform software package command is the recommended way of
performing an individual subpackage upgrade, and also provides the only method of no-downtime upgrades
of individual subpackages on the router when the router is running individual subpackages.
The request platform software package command requires that the destination device or process be specified
in the command line, so the commands can be used to upgrade software on both an active or a standby
processor.
Command Syntax
request platform software package install rp rp-slot-number file file-URL
where
• rp-slot-number is the number of the RP slot and
• file-URL is the path to the file being used to upgrade the Router.
The copy Command

The copy command can be used to move consolidated packages and individual subpackages onto the router,
though using this command to move individual subpackage files from one storage area to another is often
inefficient (in these scenarios, it is almost always preferable to move the consolidated package, then extract
the subpackages, or to extract the subpackages without moving the consolidated package).
To upgrade a consolidated package on the Cisco cBR Series Converged Broadband Router, copy the
consolidated package onto a file system, usually bootflash: , using the copy command as you would on most
other Cisco routers. After making this copy, configure the router to boot using the consolidated package file.
To upgrade the router and reboot using individual subpackages, copy the consolidated package onto the router
using the copy command, enter the request platform software package expand command to extract the
individual subpackages, and configure the router to boot using subpackages. Other methods, such as copying
each individual subpackage in the same consolidated package from a directory or using the request platform
software package command to extract the subpackages onto a router directory are also usable, though copying
individual subpackages is often inefficient.
Managing and Configuring the Router to Run Using Consolidated

Packages and Individual SubPackages
This section describes methods that are used to manage and configure the packages, sub-packages and patches
on the router.
80
Basic Configuration
Cable Line Card Process Restart
Cable Line Card Process Restart

The last step, in many of the methods used to upgrade and manage the packages and sub-packages, is to reload
the router or the component for which the software is being configured or upgraded. Reloading the router or
the components involves the following disadvantages:
• service disruption (limited)
• loss of modem configuration data
• time consumption in rebooting the line cards and other components
The N+1 line card high availability (LCHA) system reboots the active and the standby line cards whenever
a package is upgraded on a line card. This occurs for sub-package upgrade for Field Replaceable Units (FRUs)
on the line card as well. Every time an upgrade is done to a package or sub-package, the line card must be
rebooted. The time taken for the package upgrade on N number of active line cards, the total number of reboots
would be 2xN. This is time-consuming and may affect services on the rebooting line cards.
To avoid the disadvantages of reloading the router and the line cards, use the Cable Line Card Process Restart
features when you upgrade packages on the RF line cards.
Note Do not use the process restart features without upgrading or installing packages on the RF line cards.
Primarily there are two features that allow you to restart Cable Line Card processes:
• Cable Line Card Control Plane Process Restart
• Cable Line Card Upstream Scheduler Process Restart
Cable Line Card Control Plane Process Restart

The Cable Line Card Control Plane Process Restart feature provides the following advantages:
• Simplified package upgrade without LCHA based reboot of active and standby line cards.
• Restart of specific processes without service disruption.
• All the modem configuration data is recovered after the IOSd process restarts.
• Changes in the modem configuration data during the IOSd process restart is reconciled after the IOSd
process is restarted.
• The secondary line card shutdown and un-shutdown processes occur automatically.
Restrictions:
• To upgrade a line card IOS using the Cable Line Card Control Plane Process Restart feature, the
sub-package must have the patches for cbrsup-clcios and cbrsup-clciosdb.
• IOSd and us-scheduler restart are supported. You can restart IOSd only, which requires IOSd/IOSdb
packages or restart the us-scheduler only, which requires clc-docsis package. You can also restart both
using a single command, where the us-scheduler is restarted first and then the IOSd is restarted. In this
case, IOSd/IOSdb and clc-docsis packages are required.
81
Basic Configuration
Restart on Crash
Other restrictions include the following:

• The IOSd process can be restarted only on the primary active RF line cards.
• Any secondary RF line card must be shut down before restarting the IOSd process.
• The IOSd process restart does not work when double failures (i.e. termination of IOSd and one or more
process at the same time) occur. The double failures result in line card reload.
• The restart of the next IOSd (i.e. IOSd process on the next RF line card) does not occur until the current
IOSd process recovers fully.
The Cable Line Card Control Plane Process Restart feature provides the following restart options:
• Restart a specific slot using the request platform software process restart command with the slot slot
number option.
• Restart all the line cards without specifying a specific slot, using the request platform software process
restart command without the slot slot number option.
• Interval based restart option of all line card using the request platform software process restart
command with the interval secs option.
Important points to remember:

• Before using the Cable Line Card Control Plane Process Restart feature, shut down the secondary line
card, using the hw-module slot shutdown command.
• When the Cable Line Card Control Plane Process Restart feature is started, the secondary line card shuts
down automatically.
• Before using the Cable Line Card Control Plane Process Restart feature, shut down the secondary line
card, using the hw-module slot shutdown command.
• When the Cable Line Card Control Plane Process Restart feature is started, the secondary line card shuts
down automatically.
• To prevent reloading the line card after sub-package upgrade, use the request platform software package
install node file command with the noreload linecard option.
• Verify the restart process using the show platform software ios slot slot number restart info command.
Restart on Crash
The cable line card control plane and upstream scheduler process restarts automatically after a crash. After
restarting process, secondary line card is reset.
Restrictions:
• Restart on crash supported only on primary active line cards
The table below lists the cable line card behaviors when crash happens under different rules.
82
Basic Configuration
Using the Cable Line Card Control Plane Process Restart Feature
Table 8: Cable Line Card Process Restart Policy Matrix
Secondary Cable Line Crash Secondary Cable Line

Card Present Card state
LCHA or LCPR Yes Cable line card reset Active after switchover
Process restart enabled No Restart N/A
LCHA or LCPR Yes Cable line card reset Active after switchover
Process restart Disabled No Cable line card reset N/A
No LCHA Preferred or Yes Process restart Secondary cable line card

LCPR resets after process restart
on primary cable line card
Process restart Enabled No Process restart N/A
No LCHA Preferred or Yes Cable line card reset Active after switchover
LCPR
Process restart Disabled No Cable line card reset N/A
Note • Manual process restart does not depend on policy configured, and will shut/unshut secondary cable line
card if present.
• “LCHA preferred” and “process restart enable” are default. User can set these two parameters using
disable-auto-restart and lcha-preferred commands. For the details, see
http://www.cisco.com/c/en/us/td/docs/cable/cmts/cmd_ref/b_cmts_cable_cmd_ref.html.
• Behavior is the same for Control Plane Process Restart and Upstream Scheduler Process Restart.
• Secondary cable line card in standby mode is considered present.
The restart retry limit feature is added to the Cable Line Card Process Restart, it is applicable only to restart
on crash. Using this feature, the customer can set a restart retry time limit, if the process cannot restart
successfully within this limit, the line card will reload. This feature can prevent the line card from continuous
restart when restart failed.
Using the Cable Line Card Control Plane Process Restart Feature
To use the Cable Line Card Control Plane Process Restart Feature, install the RF line card sub-package upgrade
using the command.
Step 1 Install the RF line card sub-package upgrade using the request platform software package install node file noreload
linecard command.
Router#request platform software package install node file bootflash:sp/cbr_patch.9.0.tar noreload

linecard
83
Basic Configuration
Configuring the Cable Line Card Control Plane Process Restart Retry Limit
Step 2 Use the request platform software process restart command to restart the RF line card IOSd process on all the cable
line cards sequentially.
Router# request platform software process restart
Step 3 Use the request platform software process restart slot slot# command to restart the RF line card IOSd process on a
specific cable line card.
Router# request platform software process restart slot 7
To configure the Cable Line Card Control Plane Process Restart Retry Limit, complete the following procedure:
enable
configure terminal
process-restart
lc-control-plane-timeout time
restart-retry retry-times
exit
Examples for Cable Line Card Control Plane Process Restart Feature
This section provides the sample outputs for the commands used in the Cable Line Card Control Plane Process.
This example shows the output of the request platform software package install node file command with
the noreload linecard option that installs the sub-package upgrade:
Router# request platform software package install node file bootflash:sp/cbr_patch.9.0.tar

noreload linecard
Image file expanded and copied
Expanding image file: stby-bootflash:sp/cbr_patch.9.0.tar
Finished image file expansion
Found clc package
STAGE 1: Installing software on standby RP
==========================================
--- Starting local lock acquisition on R0 ---
Finished local lock acquisition on R0
--- Starting installation state synchronization ---
Finished installation state synchronization
--- Starting file path checking ---
Finished file path checking
--- Starting image file verification ---
Checking image file names
Locating image files and validating name syntax
Found cbrsup-clcios.2015-03-23_17.53_haolin2.SSA.pkg
Found cbrsup-clciosdb.2015-03-23_17.53_haolin2.SSA.pkg
Verifying image file locations
Inspecting image file types
Processing image file constraints
Creating candidate provisioning file
Finished image file verification
84
Basic Configuration
--- Starting candidate package set construction ---

Verifying existing software set
Processing candidate provisioning file
Constructing working set for candidate package set
Constructing working set for running package set
Checking command output
Constructing merge of running and candidate packages
Checking if resulting candidate package set would be complete
Finished candidate package set construction
--- Starting ISSU compatibility verification ---
Verifying image type compatibility
Checking IPC compatibility with running software
Checking candidate package set infrastructure compatibility
Checking infrastructure compatibility with running software
Checking package specific compatibility
Finished ISSU compatibility verification
--- Starting list of software package changes ---
Old files list:
Removed cbrsup-clcios.2015-03-23_17.28_haolin2.SSA.pkg
Removed cbrsup-clciosdb.2015-03-23_17.28_haolin2.SSA.pkg
New files list:
Added cbrsup-clcios.2015-03-23_17.53_haolin2.SSA.pkg
Added cbrsup-clciosdb.2015-03-23_17.53_haolin2.SSA.pkg
Finished list of software package changes
--- Starting commit of software changes ---
Updating provisioning rollback files
Creating pending provisioning file
Committing provisioning file
Finished commit of software changes
--- Starting analysis of software changes ---
Finished analysis of software changes
--- Starting update running software ---
Blocking peer synchronization of operating information
Creating the command set placeholder directory
Finding latest command set
Finding latest command shortlist lookup file
Finding latest command shortlist file
Assembling CLI output libraries
Assembling CLI input libraries
Assembling Dynamic configuration files
Applying interim IPC and database definitions
Replacing running software
Replacing CLI software
Restarting software
Restarting software: target frus filtered out ... skipped
Applying final IPC and database definitions
Generating software version information
Notifying running software of updates
Unblocking peer synchronization of operating information
Unmounting old packages
Cleaning temporary installation files
Finished update running software
SUCCESS: Finished installing software.
STAGE 2: Installing software on active RP
=========================================
85
Basic Configuration
Found cbrsup-clcios.2015-03-23_17.53_haolin2.SSA.pkg
Found cbrsup-clciosdb.2015-03-23_17.53_haolin2.SSA.pkg
Finished ISSU compatibility verification
--- Starting impact testing ---
Checking operational impact of change
Finished impact testing
Old files list:
Removed cbrsup-clcios.2015-03-23_17.28_haolin2.SSA.pkg
Removed cbrsup-clciosdb.2015-03-23_17.28_haolin2.SSA.pkg
New files list:
Added cbrsup-clcios.2015-03-23_17.53_haolin2.SSA.pkg
Added cbrsup-clciosdb.2015-03-23_17.53_haolin2.SSA.pkg
Restarting software
Found clc package
86
Basic Configuration
Cable Line Card Upstream Scheduler Process Restart
SUCCESS: node ISSU finished successfully.

Invoking cleanup routine
This example shows the output of the show platform software ios restart info command:
Router#show platform software ios 6 restart info

IOSD process restart info:
Process restartable: Yes
IOSD restart state : ACTIVE
Total Modem Count : 31
Active Modem Count : 31
This example shows the output of the request platform software process restart command:

--- Upgrading/Restarting LineCard-2 Packages/Processes ---
NOTICE: No upgrades available.
Provide process name in cli if you wish to restart a process
Available upgrades
cbrsup-clcios.2015-03-23_17.53_haolin2.SSA.pkg
cbrsup-clciosdb.2015-03-23_17.53_haolin2.SSA.pkg
--- Checking for ready state before IOSD upgrade on LineCard-3
Updating Package cbrsup-clcios.2015-03-23_17.28_haolin2.SSA.pkg
---> cbrsup-clcios.2015-03-23_17.53_haolin2.SSA.pkg
Restarting ubrclc_k9lc_ms
--- Checking for ready state before IOSDB upgrade on LineCard-3
Updating Package cbrsup-clciosdb.2015-03-23_17.28_haolin2.SSA.pkg
---> cbrsup-clciosdb.2015-03-23_17.53_haolin2.SSA.pkg
Restarting iosdb
SUCCESS: Finished
Router#show platform software patch 2 info

cbrsup-clciosdb: 3.17.0 (3.0)
cbrsup-clc-firmware: 3.17.0 (0.0)
cbrsup-clcvideo: 3.17.0 (0.0)
cbrsup-clcios: 3.17.0 (3.0)
cbrsup-clccontrol: 3.17.0 (0.0)
cbrsup-clcdocsis: 3.17.0 (0.0)
Cable Line Card Upstream Scheduler Process Restart

The Cable Line Card Upstream Scheduler Process Restart feature is used to restart the upstream scheduler
process on the RF line cards.
The Cable Line Card Upstream Scheduler Process Restart feature provides the following advantages:
• Allows to restart line card US- Scheduler (CDMAN) process with minimum impact to upstream traffic
and no impact to downstream traffic.
• All modem configuration data recovered to the state before restart.
• Changes in modem configuration data during restart are reconciled.
• New modems coming online are blocked during restart.
87
Basic Configuration
Using the Cable Line Card Upstream Scheduler Process Restart Feature
• The request platform software package restart command is used to upgrade the new DOCSIS sub-pkg
patch without reloading the line card.
• Effective with Cisco IOS-XE Release 3.18.0S, the card restarts automatically after a crash. For more
information, see Restart on Crash, on page 82 section.
Restrictions:
The following restrictions apply to the :
• The Upstream Scheduler process can be restarted only on the primary active RF line cards.
• The Upstream Scheduler process restart does not work when double failures (i.e. termination of Upstream
Scheduler and one or more process at the same time) occur. The double failures result in line card reload.
• The restart of the next Upstream Scheduler (i.e. Upstream Scheduler process on the next RF line card)
does not occur until the current Upstream Scheduler process recovers fully.
Important points to remember:

• With Cisco IOS-XE Release 3.17.0S, when the Cable Line Card Upstream Scheduler Process Restart
feature is started, the secondary line card shuts down automatically.
• To prevent reloading the line card after sub-package upgrade, use the request platform software package
install node file command with the noreload linecard option.
• Verify the restart process using the show platform software us-scheduler restart info command.
Router# show platform software us-scheduler 3 restart info

us-scheduler process restart info:
Process restartable : Yes
us-scheduler state : RESTART_OPERATIONAL
Features bit map : 0x001e
us-scheduler restart count : 4
Using the Cable Line Card Upstream Scheduler Process Restart Feature
To use the Cable Line Card Upstream Scheduler Process Restart Feature, install the RF line card sub-package
upgrade using the command.
Step 1 Install the RF line card sub-package upgrade using the request platform software package install node file noreload
linecard command.
Router#request platform software package install node file bootflash:sp/cbr_patch.9.0.tar noreload

linecard
Step 2 Use the request platform software process restart command to restart the Upstream Scheduler process on all the cable
line cards sequentially.
Step 3 Use the request platform software process restart slot slot# command to restart the Upstream Scheduler process on a
specific cable line card.
88
Basic Configuration
Router# request platform software process restart slot 7
To configure the Cable Line Card Control Plane Process Restart Retry Limit, complete the following procedure:
enable
configure terminal
process-restart
lc-us-scheduler-timeout time
restart-retry retry-times
exit
Examples for Cable Line Card Upstream Scheduler Process Restart Feature
This section provides the sample outputs for the commands used in the Cable Line Card Upstream Scheduler
Process Restart Feature.
This example shows the output of the show platform software us-scheduler restart info command.
Router#show platform software us-scheduler 6 restart info

This example shows the output when the upstream scheduler process is restarted.
Router# request platform software package install node file

bootflash:subpkg/cbr_patch-3.17.0-patch2.tar noreload linecard
NOTE: Currently node has booted from a provisioning file
NOTE: Going to start a dual rp sub-packages node ISSU install
--- Starting initial file path checking --- Copying
bootflash:subpkg/cbr_patch-3.17.0-patch2.tar to
stby-bootflash:subpkg/cbr_patch-3.17.0-patch2.tar
Finished initial file path checking
--- Starting config-register verification --- Finished config-register verification
--- Starting Checking noreload options --- Finished Checking noreload options
--- Starting image file expansion ---
Expanding image file: bootflash:subpkg/cbr_patch-3.17.0-patch2.tar
Expanding image file: stby-bootflash:subpkg/cbr_patch-3.17.0-patch2.tar
Found clc package
STAGE 1: Installing software on standby RP ==========================================
--- Starting local lock acquisition on R0 --- Finished local lock acquisition on R0
--- Starting installation state synchronization --- Finished installation state
synchronization
--- Starting image file verification --- Checking image file names Locating image files and
89
Basic Configuration
validating name syntax

Found cbrsup-clcdocsis.2015-10-08_18.10_haolin2.SSA.pkg
--- Starting candidate package set construction --- Verifying existing software set Processing
candidate provisioning file Constructing working set for
candidate package set Constructing working set for running package set Checking command
output Constructing merge of running and candidate packages
Checking if resulting candidate package set would be complete Finished candidate package
set construction
WARNING:
WARNING: ISSU between engineering builds with release strings in non-standard fo rmat.
Skipping ISSU Software Compatibility checks.
WARNING:
WARNING:
WARNING:
WARNING:
WARNING:
WARNING:
WARNING:
Checking IPC compatibility with running software Checking candidate package set infrastructure
compatibility Checking infrastructure compatibility with running
software Checking package specific compatibility Finished ISSU compatibility verification
--- Starting list of software package changes --- Old files list:
Removed cbrsup-clcdocsis.BLD_MCP_DEV_LATEST_20151006_133623.SSA.pkg
New files list:
Added cbrsup-clcdocsis.2015-10-08_18.10_haolin2.SSA.pkg
--- Starting commit of software changes --- Updating provisioning rollback files Creating
pending provisioning file Committing provisioning file Finished
commit of software changes
--- Starting analysis of software changes --- Finished analysis of software changes
--- Starting update running software --- Blocking peer synchronization of operating
information Creating the command set placeholder directory
Restarting software
Unblocking peer synchronization of operating information Unmounting old packages Cleaning
temporary installation files
STAGE 2: Installing software on active RP =========================================
90
Basic Configuration
--- Starting installation state synchronization --- Finished installation state
synchronization
--- Starting image file verification --- Checking image file names Locating image files and
validating name syntax
Found cbrsup-clcdocsis.2015-10-08_18.10_haolin2.SSA.pkg
candidate provisioning file Constructing working set for candidate
package set Constructing working set for running package set Checking command output
Constructing merge of running and candidate packages Checking if resulting
candidate package set would be complete Finished candidate package set construction
WARNING:
WARNING:
WARNING:
WARNING:
WARNING:
WARNING:
WARNING:
WARNING:
Checking IPC compatibility with running software Checking candidate package set infrastructure
compatibility Checking infrastructure compatibility with running
software Checking package specific compatibility Finished ISSU compatibility verification
--- Starting list of software package changes --- Old files list:
Removed cbrsup-clcdocsis.BLD_MCP_DEV_LATEST_20151006_133623.SSA.pkg
New files list:
Added cbrsup-clcdocsis.2015-10-08_18.10_haolin2.SSA.pkg
--- Starting commit of software changes --- Updating provisioning rollback files Creating
pending provisioning file Committing provisioning file Finished
commit of software changes
--- Starting update running software --- Blocking peer synchronization of operating
information Creating the command set placeholder directory
Restarting software
91
Basic Configuration

Unblocking peer synchronization of operating information Unmounting old packages Cleaning
temporary installation files
Found clc package
Router#
Router#show platform software us-scheduler 2 restart info

Router#request platform software process restart slot 2

Available upgrades
cbrsup-clcdocsis.BLD_MCP_DEV_LATEST_20151006_13362
Updating Package cbrsup-clcdocsis.BLD_MCP_DEV_LATEST_20151006_13362
---> cbrsup-clcdocsis.2015-10-08_18.10_haolin2.SSA.pkg
Restarting us-scheduler
SUCCESS: Finished upgrading the LineCard-2

cbrsup-clciosdb: 3.17.0 (0.0)
cbrsup-clc-firmware: 3.17.0 (0.0)
cbrsup-clcvideo: 3.17.0 (0.0)
cbrsup-clcios: 3.17.0 (0.0)
cbrsup-clccontrol: 3.17.0 (0.0)
cbrsup-clcdocsis: 3.17.0 (2.0)
Note If the upgrade package includes both IOSD-CLC and US-scheduler sub-packages, the request platform
software process restart command first restarts the Cable Line Card Upstream Scheduler process and then
the Cable Line Card Control Plane process.
This example shows the output of the request platform software process restart command when the Control
Plane and the upstream scheduler process are restarted:
Note If the slot keyword is not used, the upstream scheduler process on all the line cards are restarted sequentially.
Router#request platform software process restart
Available upgrades
cbrsup-clcdocsis.2015-09-24_03.09_johuynh.SSA.pkg
cbrsup-clcios.2015-09-24_03.09_johuynh.SSA.pkg
cbrsup-clciosdb.2015-09-24_03.09_johuynh.SSA.pkg
92
Basic Configuration
Quick Start Software Upgrade
Updating Package cbrsup-clcdocsis.2015-09-24_03.09_johuynh.SSA.pkg

Updating Package cbrsup-clcios.2015-09-24_03.09_johuynh.SSA.pkg
Updating Package cbrsup-clciosdb.2015-09-24_03.09_johuynh.SSA.pkg
Restarting iosdb
Available upgrades
cbrsup-clcdocsis.2015-09-24_03.09_johuynh.SSA.pkg
cbrsup-clcios.2015-09-24_03.09_johuynh.SSA.pkg
cbrsup-clciosdb.2015-09-24_03.09_johuynh.SSA.pkg
Updating Package cbrsup-clcdocsis.2015-09-24_03.09_johuynh.SSA.pkg

Updating Package cbrsup-clcios.2015-09-24_03.09_johuynh.SSA.pkg
Updating Package cbrsup-clciosdb.2015-09-24_03.09_johuynh.SSA.pkg
Restarting iosdb

Router#
You can specify a time interval in seconds using the interval keyword, between the restarting of two line card
processes in the sequence. The default interval is five seconds.
This example shows the configuration of an interval of six seconds.
Router#request platform software process restart interval 6
Quick Start Software Upgrade

The following instructions provide a quick start version of upgrading the software running the Cisco cBR
Series Converged Broadband Router. These instructions assume you have access to the consolidated package
and that the files will be stored in a bootflash: file system that is not storing any previously installed subpackages
or consolidated packages and that has enough room for the file or files.
Step 1 Copy the consolidated package into bootflash: using the copy URL-to-image bootflash: command.
Step 2 If you want to run the router using individual subpackages, enter the request platform software package expand file
bootflash:/sub_dir/base_image command. If you want to run the router using a consolidated package, skip this step.
Step 3 Enter the dir bootflash: command to verify your consolidated package or your extracted subpackages are in the directory.
93
Basic Configuration
Managing and Configuring a Consolidated Package Using the copy Command
Step 4 If you are trying to run individual subpackages, use the delete bootflash:base_image to delete the consolidated package.
If you want to run the router using the consolidated package, skip this step.
Step 5 Set up the boot parameters for your boot. Set the configuration register to 0x2 by entering the config-register 0x2102
global configuration command, and enter the boot system flash bootflash:base_image (if running using the consolidated
package) or boot system flash bootflash:provisionging-file-name (if running using individual subpackages) global
configuration command.
Step 6 Enter copy running-config startup-config to save your configuration.
Step 7 Enter the reload command to reload the router and finish the boot. The upgraded software should be running when the
reload completes.
Managing and Configuring a Consolidated Package Using the copy Command

To upgrade a consolidated package on the Cisco cBR Series Routers using the copy command, copy the
consolidated package into the bootflash: directory on the router using the copy command as you would on
most other Cisco routers. After making this copy, configure the router to boot using the consolidated package
file.
In the following example, the consolidated package file is copied onto the bootflash: file system from TFTP.
The config-register is then set to boot using boot system commands, and the boot system commands instruct
the router to boot using the consolidated package stored in the bootflash: file system. The new configuration
is then saved using the copy running-config startup-config command, and the system is then reloaded to
complete the process.
Router# dir bootflash:

Directory of bootflash:/
11 drwx 16384 Dec 4 2007 04:32:46 -08:00 lost+found

86401 drwx 4096 Dec 4 2007 06:06:24 -08:00 .ssh
14401 drwx 4096 Dec 4 2007 06:06:36 -08:00 .rollback_timer
28801 drwx 4096 Mar 18 2008 17:31:17 -07:00 .prst_sync
43201 drwx 4096 Dec 4 2007 04:34:45 -08:00 .installer
13 -rw- 45977 Apr 9 2008 16:48:46 -07:00 target_support_output.tgz.tgz
928862208 bytes total (712273920 bytes free)
Router# copy tftp bootflash:

Address or name of remote host []? 172.17.16.81
Source filename []?
/auto/tftp-users/user/cbrsup-universal*.bin Destination filename [cbrsup-universal*.bin]?
Accessing
tftp://172.17.16.81//auto/tftp-users/user/ cbrsup-universal*.bin...
Loading /auto/tftp-users/user/cbrsup-universal*.bin from

172.17.16.81 (via GigabitEthernet0):
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!
[OK - 208904396 bytes]
94
Basic Configuration
Managing and Configuring a Router to Run Using Individual SubPackages From a Consolidated Package
208904396 bytes copied in 330.453 secs (632176 bytes/sec)


86401 drwx 4096 Dec 4 2007 06:06:24 -08:00 .ssh
12 -rw- 208904396 May 28 2008 16:17:34 -07:00
cbrsup-universal*.bin
Router# config t
Router(config)#boot system flash
bootflash:cbrsup-universal*.bin
Router(config)#config-reg 0x2102
Router(config)#exit
Router#show run | include boot
boot-start-marker
boot system flash bootflash:cbrsup-universal*.bin boot-end-marker
Router# copy run start
Destination filename [startup-config]? Building configuration...
[OK]
Router# reload
Managing and Configuring a Router to Run Using Individual SubPackages

From a Consolidated Package
To run the router using individual subpackages from a consolidated package, follow one of the following
procedures:
Extracting a Consolidated Package and Booting Using the Provisioning File

T o extract a consolidated package and to boot using provisioning file, perform the following steps:
Step 1 Perform one of the following tasks:

a) Copy the consolidated package file (or, in cases where you have every individual subpackage and a provisioning file
for the subpackages available, each individual subpackage and the provisioning file) onto the bootflash: file system
using the copy command. Make sure to copy the consolidated package into the bootflash: file system and directory
where you want to store the provisioning file and the individual image subpackages. Enter the request platform
software package expand file bootflash:url-to-Cisco-IOS-XE-imagename command with no other option to extract
the provisioning file and the individual subpackages out of the consolidated package file and into the current directory
in bootflash:. We recommend that you extract the sub packages to an empty directory to simplify the management
of these files.
b) Copy the consolidated package file onto any file system on your router, then enter the request platform software
package expand file file-system:url-to-Cisco-IOS-XE-imagename to bootflash: command to extract the provisioning
file and the individual image subpackages onto the bootflash: file system.
95
Basic Configuration
Note After performing this step, do not move any of the files. The bootup process cannot function properly unless
all of the subpackages and the provisioning file are located in the same directory. Also, do not rename the
subpackage files. Only the provisioning file can be renamed, and the renaming of the provisioning file, if
desired, should be done at this step before the router is rebooted.
Step 2 Configure the router to boot using the provisioning file.

The sequence below provides an example that would boot the router using the provisioning file named packages.conf
that was stored with the other subpackages in the bootflash: file system:
Router(config)# no boot system

Router(config)# config-register 0x2102
Router(config)# boot system flash bootflash:packages.conf
Router(config)# exit
*May 11 01:31:04.815: %SYS-5-CONFIG_I: Configured from console by con
Building configuration... [OK]
Router# reload
Extracting the SubPackages and the Provisioning File: Example 1

The following example shows how to extract the individual subpackages and the provisioning file from a consolidated
package that has already been placed in the directory where you want to store the individual subpackages and the
provisioning file. We recommend that you extract the sub packages to an empty directory to simplify the management
of these files.
Output of the directory before and after the extraction is given to confirm the files were extracted.


86401 drwx 4096 Dec 4 2007 06:06:24 -08:00 .ssh
12 -rw- 208904396 May 9 2008 14:36:31 -07:00
Router# request platform software package expand file bootflash:cbrsup-universal*.bin

Verifying parameters
Validating package type
Copying package files
SUCCESS: Finished expanding all-in-one software package.


86401 drwx 4096 Dec 4 2007 06:06:24 -08:00 .ssh
12 -rw- 208904396 May 9 2008 14:36:31 -07:00
96
Basic Configuration
57611 -rw- 47071436 May 22 2008 11:26:23 -07:00 cbr000rp1-espbase.02.01.00.122-33.XNA.pkg

57602 -rw- 5740 May 22 2008 11:26:22 -07:00 cbr000rp1-packages-adventerprisek9.02.01.00.122-33.XNA.conf
57612 -rw- 20334796 May 22 2008 11:26:24 -07:00
cbr000rp1-rpaccess.02.01.00.122-33.XNA.pkg
57613 -rw- 22294732 May 22 2008 11:26:24 -07:00 cbr000rp1-rpbase.02.01.00.122-33.XNA.pkg
57614 -rw- 21946572 May 22 2008 11:26:25 -07:00 cbr000rp1-rpcontrol.02.01.00.122-33.XNA.pkg
57615 -rw- 48099532 May 22 2008 11:26:26 -07:00
cbr000rp1-rpios-adventerprisek9.02.01.00.122-33.XNA.pkg
57616 -rw- 34324684 May 22 2008 11:26:27 -07:00 cbr000rp1-sipbase.02.01.00.122-33.XNA.pkg
57617 -rw- 22124748 May 22 2008 11:26:28 -07:00 cbr000rp1-sipspa.02.01.00.122-33.XNA.pkg
57603 -rw- 6256 May 22 2008 11:26:28 -07:00 packages.conf
Extracting the SubPackages, Configuring the Router to Boot Using the Provisioning File, and Reloading the
Router: Example 2
In the following example, the provisioning file and the individual subpackages are extracted from a consolidated package.
The router is then configured to boot using the provisioning file. This example also shows the config-register being set
and the running configuration being saved because these tasks must be performed for the router to reload properly. The
router is then reloaded to complete the process.


86401 drwx 4096 Dec 4 2007 06:06:24 -08:00 .ssh
12 -rw- 208904396 May 9 2008 14:36:31 -07:00
Router# request platform software package expand file bootflash:cbrsup-universal*.bin

Verifying parameters
Validating package type
Copying package files
SUCCESS: Finished expanding all-in-one software package.


86401 drwx 4096 Dec 4 2007 06:06:24 -08:00 .ssh
12 -rw- 208904396 May 9 2008 14:36:31 -07:00
57611 -rw- 47071436 May 22 2008 11:26:23 -07:00 cbr000rp1-espbase.02.01.00.122-33.XNA.pkg
57602 -rw- 5740 May 22 2008 11:26:22 -07:00
cbr000rp1-packages-adventerprisek9.02.01.00.122-33.XNA.conf
57612 -rw- 20334796 May 22 2008 11:26:24 -07:00 cbr000rp1-rpaccess.02.01.00.122-33.XNA.pkg
57613 -rw- 22294732 May 22 2008 11:26:24 -07:00 cbr000rp1-rpbase.02.01.00.122-33.XNA.pkg
57614 -rw- 21946572 May 22 2008 11:26:25 -07:00
cbr000rp1-rpcontrol.02.01.00.122-33.XNA.pkg
57615 -rw- 48099532 May 22 2008 11:26:26 -07:00 cbr000rp1-rpios-adventerprisek9.02.01.00.122-33.XNA.pkg
97
Basic Configuration
Copying a Set of Individual SubPackage Files, and Booting Using a Provisioning File
57616 -rw- 34324684 May 22 2008 11:26:27 -07:00 cbr000rp1-sipbase.02.01.00.122-33.XNA.pkg

57617 -rw- 22124748 May 22 2008 11:26:28 -07:00
cbr000rp1-sipspa.02.01.00.122-33.XNA.pkg
57603 -rw- 6256 May 22 2008 11:26:28 -07:00 packages.conf

Router# copy run start
Router# reload
Copying a Set of Individual SubPackage Files, and Booting Using a Provisioning File
To copy a set of individual subpackage files and to boot using a provisioning file, perform the following steps:
Note Although this upgrade method works, it is less efficient than other methods of upgrading the router's software.
Step 1 Copy each individual subpackage and the provisioning file into the bootflash: directory using the copy command. Note
that this method of running the router will only work if all the individual subpackages for a release and a provisioning
file are downloaded onto the router and stored in the bootflash: directory. No other file directories should be used for
booting the router using individual subpackages.
The files can also be moved on the router physically using a USB Flash drive.
Step 2 Configure the router to boot using the provisioning file.

The sequence below provides an example that describes how to boot the router using the provisioning file named
packages.conf that was stored with the other subpackages in the bootflash: file system. The router runs using individual
subpackages once the reload is complete.

*May 11 01:31:04.815: %SYS-5-CONFIG_I: Configured from console by con
Router# write memory Building configuration... [OK]
Router# reload
Installing an Optional SubPackage

To run the router using an optional subpackage, perform the following steps for each Supervisor in the chassis:
98
Basic Configuration
Installing an Optional SubPackage
Step 1 Verify that the Supervisor is running in individual subpackage mode and was booted from a provisioning file.
Step 2 Verify that the version of the optional subpackage that you want to install is the same version as the software running on
the active Supervisor.
Step 3 Download the optional subpackage that you want to install. Optional subpackages must be downloaded independently
from consolidated packages for the Cisco cBR Series Routers.
Step 4 On each Supervisor, copy the optional subpackage to the directory where any other individual subpackages and the
provisioning file is located.
Step 5 Run the request platform software package install rp file command, as shown in the following example.
Note Do not use the optional slot or bay keywords for the initial installation.
Router# request platform software package install rp 0 file

bootflash: cbrsup-universal*.bin
--- Starting file path checking --- Finished file path checking
--- Starting image file verification --- Checking image file names Verifying image file locations
Found cbrsup-universal*.bin
Inspecting image file types Processing image file constraints Creating candidate provisioning file
WARNING: No package of type sipspawmak9 is installed.

WARNING: Package will be installed for all SIP slots and bays. Finished image file verification
candidate provisioning file Constructing working set for candidate package set Constructing working
set for running package set Checking command output Constructing merge of running and candidate
packages Checking if resulting candidate package set would be complete Finished candidate package
set construction
--- Starting compatibility testing ---

Determining whether candidate package set is compatible
WARNING:
WARNING: Candidate software combination not found in compatibility database
WARNING:
Determining whether installation is valid
WARNING:
WARNING: Candidate software combination not found in compatibility database
WARNING:
Software sets are identified as compatible Checking IPC compatibility with running software Checking
candidate package set infrastructure compatibility Checking infrastructure compatibility with running
software Checking package specific compatibility Finished compatibility testing
--- Starting impact testing --- Checking operational impact of change Finished impact testing
--- Starting list of software package changes --- No old package files removed New files list:
Added cbrsup-universal*.bin Finished list of software package changes
--- Starting commit of software changes --- Updating provisioning rollback files Creating pending
provisioning file Committing provisioning file Finished commit of software changes
--- Starting update running software --- Blocking peer synchronization of operating information
99
Basic Configuration
Upgrading Individual SubPackages

Finding latest command shortlist lookup file Finding latest command shortlist file Assembling CLI
output libraries
Replacing running software Replacing CLI software Restarting software
Applying final IPC and database definitions Generating software version information Notifying running
software of updates
Unblocking peer synchronization of operating information Unmounting old packages
Upgrading Individual SubPackages

Patch Installation
Individual subpackages can be upgraded in subpackage mode. Patch releases consist of one or more
subpackages. After a patch has been installed, a message is displayed indicating whether the entire chassis or
only the line cards must be rebooted for the updates to take effect.
Installing a Patch that Affects Both Line Card and Supervisor Card
Step 1 The Cisco cBR router must be in subpackage mode.

Step 2 Copy the patch file to the same location as the active subpackages on both the active and standby supervisor cards.
Step 3 Install the patch using the request platform software package install rp slot file patch file command on the standby
card.
Step 4 Install the patch using therequest platform software package install rp slot file patch file command on the active card.
Step 5 Reload the chassis.
Installing a Patch that Affects Only Line Cards

card.
Step 4 Install the patch using therequest platform software package install rp slot file patch file command on the active card.
Step 5 Reload the line cards.
100
Basic Configuration
Installing a Patch that Affects Only Supervisor Cards
Installing a Patch that Affects Only Supervisor Cards

card.
Step 4 Switch over to the standby card. This will make it the active card.
card.
Upgrading a Line Card SubPackage

Use the request platform software package install node file filename command to upgrade a line card
subpackage.
Router# request platform software package install node file

bootflash:/subpkg/cbr_patch.5.0.tar

--- Starting initial file path checking ---

Copying bootflash:/subpkg/cbr_patch.5.0.tar to stby-bootflash:/subpkg/cbr_patch.5.0.tar
--- Starting config-register verfication ---

Finished config-register verfication

Expanding image file: bootflash:/subpkg/cbr_patch.5.0.tar
Expanding image file: stby-bootflash:/subpkg/cbr_patch.5.0.tar

==========================================




Found cbrsup-clcdocsis.2015-02-20_01.02.SSA.pkg
101
Basic Configuration


--- Starting ISSU compatiblity verficiation ---

Finished ISSU compatiblity verficiation

Old files list:
Removed cbrsup-clcdocsis.BLD_V155_2_S_XE315_THROTTLE_LATEST_20150217_110041-st
d.SSA.pkg
New files list:
Added cbrsup-clcdocsis.2015-02-20_01.02.SSA.pkg



Restarting software
102
Basic Configuration

=========================================







Old files list:
Removed cbrsup-clcdocsis.BLD_V155_2_S_XE315_THROTTLE_LATEST_20150217_110041-st
d.SSA.pkg
New files list:



103
Basic Configuration

Restarting software

Found clc package
Found clc package
Found clcdocsis package
SUCCESS: Reload Cable Linecard at slot 1
SUCCESS: Reload Cable Linecard at slot 2
Use the request platform software package install node file filename noreload linecard command to
upgrade a line card subpackage.
Router#request platform software package install node file bootflash:/subpkg/cbr_patch.5.0.tar

noreload linecard
--- Starting initial file path checking ---

Copying bootflash:/subpkg/cbr_patch.5.0.tar to stby-bootflash:/subpkg/cbr_patch.
5.0.tar
--- Starting config-register verfication ---

Finished config-register verfication
--- Starting Checking noreload options ---

Finished Checking noreload options

Expanding image file: bootflash:/subpkg/cbr_patch.5.0.tar
Expanding image file: stby-bootflash:/subpkg/cbr_patch.5.0.tar
Found clc package

==========================================
104
Basic Configuration






Old files list:
Removed cbrsup-clcdocsis.2015-03-01_03.43.SSA.pkg
New files list:



105
Basic Configuration
Restarting software

=========================================







Old files list:
Removed cbrsup-clcdocsis.2015-03-01_03.43.SSA.pkg
New files list:

106
Basic Configuration




Restarting software

Found clc package
Use the show platform software patch n info command to verify completion of this upgrade.

cbrsup-clciosdb: 3.15 (0.0)
cbrsup-clc-firmware: 3.15 (0.0)
cbrsup-clcvideo: 3.15 (0.0)
cbrsup-clcios: 3.15 (0.0)
cbrsup-clccontrol: 3.15 (0.0)
cbrsup-clcdocsis: 3.15 (1.0)
cbrsup-clcmipsbase: 3.15 (0.0)

cbrsup-clciosdb: 3.15 (0.0)
cbrsup-clc-firmware: 3.15 (0.0)
cbrsup-clcvideo: 3.15 (0.0)
cbrsup-clcios: 3.15 (0.0)
cbrsup-clccontrol: 3.15 (0.0)
cbrsup-clcdocsis: 3.15 (1.0)
cbrsup-clcmipsbase: 3.15 (0.0)
Use the show platform software ios slot-number restart info command to verify completion of this upgrade.
This example shows the output of this show command for the RF line card slot number 2.
107
Basic Configuration
Router#show platform software ios 2 restart info

IOSD process restart info:
Process restartable: Yes
IOSD restart state : NOT_RESTARTED_YET
Total Modem Count : 251
Active Modem Count : 251
Router#
Description Link
ID and password.
Feature Information for Consolidated Packages and

SubPackages Management
Table 9: Feature Information for Consolidated Packages and SubPackages Management
Consolidated Packages and Cisco IOS XE Fuji 16.7.1 This feature was integrated on the
SubPackages Management Cisco cBR Series Converged
Broadband Routers.
108
CHAPTER 6
Support for 2x100G DPIC
This document provides details of the Cisco cBR support for the Cisco cBR-8 2x100G DPIC and how to
configure it on Cisco cBR Series Routers.
• Information About Cisco cBR 2x100G DPIC, on page 111
• How to Configure 2x100G DPIC, on page 113
• Feature Information for 2x100G DPIC Support, on page 115
109
Basic Configuration
Digital PICs:

Module:

Modules:
line card reload.
110
Basic Configuration
Information About Cisco cBR 2x100G DPIC
Information About Cisco cBR 2x100G DPIC

The Cisco cBR-8 2x100G Digital Physical Interface Card (DPIC) fo Remote PHY provides two QSFP ports.
The 2x100G DPIC works only with the CBR-CCAP-LC-G2-R line card to transmit DEPI, UEPI, and GCP
traffic from the Cisco cBR-8 router to Remote PHY devices.
The 2x100G DPIC has two groups of LEDs mapped to each QSFP port. If you have configured 10GE mode,
QSFP0 maps to LEDs 0,2,4, and 6, while QSFP1 maps to LEDs 1,3,5, and 7. If you have configured 100GE
mode, QSFP0 maps to LED 0 and QSFP1 maps to LED 1.
This DPIC supports Onboard Failure Logging (OBFL), environment monitoring, and FPD. However, the
2x100G DPIC does not support 8x10G DPIC or RF-PIC card protection.
The product ID (PID) of 2x100G DPIC is CBR-DPIC-2X100G.
Limitations on Downstream Bandwidth

For 2x100G DPIC, each XFI group supports a maximum of 10Gbps bandwidth—9Gbps for data traffic and
1Gbps for control packets. An error message similar to the following is logged in the syslog, when the
theoretical maximum bandwidth for all video channels in a group exceeds 9Gbps.
%IOSXE-3-PLATFORM: CLC8: cdman: Video channel oversubscribed!! Downstream controller 8/0/0~7
bandwidth ratio is 100.1040%.
For CBR-CCAP-LC-G2-R cards that support 40G DPIC, eight 10GE interfaces are divided into four XFI
groups.
For each 10G interface, theoretical bandwidth of all downstream channels configured under Te
<slot>/<subslot>/0 and Te <slot>/<subslot>/1 must not exceed 9Gbps.
10GE Port XFI Group
0 0
2 1
4 2
6 3
For CBR-CCAP-LC-G2-R cards supporting 40G DPIC 2x100G mode, only one 100GE interface is active.
32 downstream controllers are divided into four XFI groups.
Since there is only one 100G interface, for each downstream controller, the theoretical bandwidth of all
downstream channels configured under cable downstream controller <slot>/<subslot>/0 | <slot>/<subslot>/7
must not exceed 9Gbps.
111
Basic Configuration
Support for Link Redundancy
Controller XFI Group
0-7 0
8-15 1
16-23 2
24-31 3
This table shows the theoretical maximum number of SCQAM downstream channels in each XFI group for
different annex and QAM modulation.
Annex QAM Modulation Theoretical Bandwidth Maximum Number of

(Mbps) Downstream Channels
Annex A 64 38.4 234
Annex A 256 51.3 175
Annex B 64 26.9 334
Annex B 256 38.8 231
Support for Link Redundancy

The 2x100G DPIC supports only active-standby link redundancy mode, where if one interface is active, the
other remains on standby. The 2x100G DPIC does not support active-active link redundancy mode. But, if
the 2x100G DPIC is configured to work in the 8x10G DPIC mode, then the 2x100G DPIC supports
active-standby and active-active link redundancy modes. Run the sh ip int b | in te slot/subslot command to
view the details.
Router#sh ip int b | in Te9/1/

Te9/1/0 90.0.0.1 YES NVRAM up up
Te9/1/1 91.0.0.1 YES NVRAM administratively down down
Te9/1/2 92.0.0.1 YES VRAM up up
If link redundancy is not enabled, then you cannot use port 1.

The 2x100G DPIC supports both standby-hot and standby-cold redundancy modes.
The 100GE <slot>/1/9 always remains administratively down irrespective of whether QSFP is installed or
not. Run the sh ip int b | in Hu command to view the 100GE interface details.
Router#sh ip int b | in Hu
HundredGigE0/1/8 209.165.200.225 YES NVRAM up up
HundredGigE0/1/9 unassigned YES unset administratively down down
112
Basic Configuration
How to Configure 2x100G DPIC
How to Configure 2x100G DPIC

View 2x100G DPIC Details
To view the 2x100G DPIC details, run the show platform
.This is a sample configuration.
Chassis type: CBR-8-CCAP-CHASS

--------- ------------------- --------------------- -----------------
0 CBR-CCAP-LC-G2-R ok 01:06:50
0/1 CBR-DPIC-2X100G ok 01:03:36
1/1 CBR-RF-PROT-PIC ok 01:03:35
2/1 CBR-DPIC-8X10G ok 01:03:33
3/1 CBR-DPIC-2X100G ok 01:03:29
…
Configure 2x100G DPIC Mode

The 2x100G DPIC supports two modes—10G and 100G modes. To create a DPIC-100G card with 2x100GE
interface mode, perform these steps.
Router(config)# card <slot>/0 CBR-CCAP-LC-G2-R r-phy DPIC-G2-100GE
To create a DPIC-100G card with 8x10GE interface mode, perform these steps.
Router(config)# card 2/0 CBR-CCAP-LC-G2-R r-phy DPIC-G2-10GE
Verify 2x100G DPIC Mode

To verify the 2x100G DPIC mode configuration, run the sh run | i card command.
Router# sh run | i card
card 0/0 CBR-CCAP-LC-G2-R r-phy DPIC-G2-100GE
...
Verify 2x100G Ethernet Interface Status

To verify the 2x100G ethernet interface status, run the show interfaces HundredGigE <slot>/1/<8-9>
.This is a sample configuration.
Router# show interface HundredGigE 3/1/8
113
Basic Configuration
Switch Between 8x10G and 2x100G Modes
HundredGigE3/1/8 is up, line protocol is up

Hardware is CBR-DPIC-2X100G, address is 1ce4.3df59.6e12 (bia 1c6.8df5.1c13)
Internet address is 209.165.200.225/24
MTU 2350 bytes, BW 100000000 Kbit/sec, DLY 10 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
. . .
Full Duplex, 100000Mbps, link type is force-up, media type is QSFP_100GE_SR
. . .
30 second input rate 10000 bits/sec, 5 packets/sec
30 second output rate 0 bits/sec, 0 packets/sec
26487 packets input, 6442316 bytes, 0 no buffer
Received 3913 broadcasts (0 IP multicasts)
0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 22571 multicast, 0 pause input
965 packets output, 152548 bytes, 0 underruns
0 output errors, 0 collisions, 1 interface resets
1375 unknown protocol drops
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier, 0 pause output
0 output buffer failures, 0 output buffers swapped out
Switch Between 8x10G and 2x100G Modes

To switch between 8x10G and 2x100G modes, perform these steps.
1. Verify the current mode by running show run.
Router#sh run | in card 9/0
2. Switch modes by running these commands.

Router#config t
Router(config)#hw-module slot 9 shutdown
Router(config)#hw-module subslot 9/1 shutdown
Router(config)#no card 9/0 CBR-CCAP-LC-G2-R r-phy DPIC-G2-10GE
Router(config)#card 9/0 CBR-CCAP-LC-G2-R r-phy DPIC-G2-100GE
Router(config)#no hw-module subslot 9/1 shutdown
Router(config)#no hw-module slot 9 shutdown
Router(config)#end
Caution When you run the no card command, the console becomes nonresponsive for more than 20 seconds. While
the console is nonresponsive, do not run any commands in other sessions to the Cisco cBR.
3. Verify the mode again by running show run.
Router#sh run | in card 9/0

4. Run the show platform command to verify the status of the DPIC.
Router# show platform

--------- ------------------- -------- -----------------
114
Basic Configuration
Configure RPD
0/1 CBR-DPIC-2X100G ok 01:03:36
Configure RPD
To configure RPD using the 100G interface, use the cable rpd node command. This is an example of onfiguring
RPD.
cable rpd node_313

identifier badb.ad13.419a
type shelf
rpd-ds 0 max-carrier 158
rpd-ds 0 base-power 32
rpd-ds 1 max-carrier 158
rpd-ds 1 base-power 34
core-interface Hu0/1/8
principal
rpd-ds 0 downstream-cable 0/0/19 profile 32
rpd-us 0 upstream-cable 0/0/38 profile 37
r-dti 6
rpd-event profile 0
rpd-55d1-us-event profile 0
Configure Link Redundancy

To enable link redundancy, run the cable rphy link redundancy [hot | cold] command.
To verify if link redundancy is enabled, run the show redundancy digi-PIC command.
Router#show redundancy digi-PIC

Time source is NTP, *13:26:58.020 CST Mon Jul 1 2019
RPHY Link HA: Cold mode enabled

Core Interface Port Mode Role Status
-------------- ---- ---------- -------- ------
Hu 0/1/8 8 Primary Active Up
Hu 0/1/8 9 Secondary Standby Ready
Hu 1/1/8 8 Primary Active Up
Hu 1/1/8 9 Secondary Standby Ready
Feature Information for 2x100G DPIC Support

115
Basic Configuration
Feature Information for 2x100G DPIC Support
Table 11: Feature Information for 2x100G DPIC Support
Support for 2x100G DPIC Cisco IOS XE Gibraltar 16.12.1 This feature was introduced in Cisco
IOS XE Gibraltar 16.12.1 on Cisco cBR
116
CHAPTER 7
G.8275.2 Telecom Profile
This document provides information on the support for G.8275.2 telecom profile and how to configure Cisco
cBR series routers to avail the support.
• G.8275.2 Telecom Profile, on page 117
• Information About G.8275.2 Telecom Profile, on page 117
• How to Configure the G.8275.2 Profile, on page 120
• DPIC PTP Primary, on page 122
• Feature Information for G.8275.2 Profile, on page 128
G.8275.2 Telecom Profile
Information About G.8275.2 Telecom Profile

Precision Time Protocol (PTP) is a protocol for distributing precise time and frequency over packet networks.
PTP is defined in the IEEE Standard 1588. It defines an exchange of timed messages.
PTP allows for separate profiles to be defined in order to adapt PTP for use in different scenarios. A profile
is a specific selection of PTP configuration options that are selected to meet the requirements of a particular
application.
Effective Cisco IOS XE Fuji 16.8.1, Cisco cBR Converged Broadband routers support the ITU- T G.8275.2
telecom profile (PTP telecom profile for Phase/Time-of-day synchronization with partial timing support from
the network).
The G.8275.2 is a PTP profile for use in telecom networks where phase or time-of-day synchronization is
required. It differs from G.8275.1 in that it is not required that each device in the network participates in the
PTP protocol. Also, G.8275.2 uses PTP over IPv4 and IPv6 in unicast mode.
117
Basic Configuration
Why G.8275.2 Telecom Profile?
Why G.8275.2 Telecom Profile?

The G.8275.2 profile is based on the partial timing support from the network. Hence nodes using G.8275.2
are not required to be directly connected.
The G.8275.2 profile is used in mobile cellular systems that require accurate synchronization of time and
phase. For example, the fourth generation (4G) of mobile telecommunications technology.
PTP Clocks
Two types of ordinary clocks are used in this profile:
Ordinary Clocks (OCs)
• Telecom Grandmaster (T-GM)—A telecom grandmaster provides timing for other devices in the network,
and is usually connected to a primary reference time source, such as a GNSS receiver. It does not
synchronize its local clock to other network elements. Considerations for a T-GM:
• Only one PTP port can be configured as a primary port.
• One T-GM primary port can have multiple subordinates associated with it.
• The T-GM OC primary port is a fixed port; that is, it always acts as a primary clock and its role
does not change by negotiating with its peer.
• Partial-Support Telecom Time Subordinate Clocks (T-TSC-P and T-TSC-A)—A subordinate clock
synchronizes its local clock to another PTP clock (GM, T-GM or T-BC), and does not provide
synchronization through PTP to any other device. Considerations for a T-TSC-P:
• An ordinary clock with single subordinate port can be configured.
• Only one peer clock address can be configured as clock source.
Note • Ordinary clocks (OC) always have only one PTP port.
• In G.8275.2 (02/2016), PTP transparent clocks are not permitted.
PTP Domain
A PTP domain is a logical grouping of clocks that communicate with each other using the PTP protocol.
A single computer network can have multiple PTP domains operating separately, for example, one set of
clocks synchronized to one time scale and another set of clocks synchronized to another time scale. PTP can
run over either Ethernet or IP, so a domain can correspond to a local area network or it can extend across a
wide area network.
The allowed domain numbers of PTP domains within a G.8275.2 network are in the range of 44 and 63 (both
inclusive). The default domain number is 44.
118
Basic Configuration
PTP Messages and Transport
PTP Messages and Transport

The following PTP transport parameters are defined:
• In Cisco IOS XE Fuji 16.8.1, PTP over IPv4 in unicast mode must be used.
• One-step clock mode must be used.
• The G.8275.2 profile supports unicast message negotiation.
PTP Ports
A port can be configured to perform either fixed primary or subordinate role or can be configured to change
its role dynamically. If no role is assigned to a port, it can dynamically assume a primary, passive, or subordinate
role based on the BMCA.
In G.8275.2, PTP ports are not tied to any specific physical interfaces, but are tied to a loopback (virtual)
interface. Traffic from a PTP port is routed through any physical interface based on the routing decision.
For a dynamic port, only one clock source can be configured.
Alternate BPCA
The BPCA (Best Primary Clock Algorithm, which is also known as Best Master Clock Algorithm (BMCA
[RFCÂ 7273]) implementation in G.8275.2 is different from that in the default PTP profile. The G.8275.2
implementation specifies an alternate best primary clock algorithm (ABPCA), which is used by each device
to select a clock to synchronize to, and to decide the port states of its local ports.
The following consideration apply to the G.8275.2 implementation of the BPCA:
• PrimaryOnly—A per port attribute, PrimaryOnly defines the state of the port. If this attribute is true, the
port is never placed in the subordinate state.
• Priority 1—Priority 1 is always static in this profile and is set to 128. Priority 1 is not used in BPCA.
• Priority 2—Priority 2 is a configurable value and its range if from 0 to 255.
• Local Priority—Local priority is configured locally on clock ports to set the priority on nominated clocks.
The default value is 128 and valid range is from 1 to 255.
Benefits
With upcoming technologies like LTE-TDD, LTE-A CoMP, LTE MBSFN and Location-based services,
eNodeBs (base station devices) are required to be accurately synchronized in phase and time. Having GNSS
systems at each node is not only expensive, but also introduces vulnerabilities. The G.8275.2 profile meets
the synchronization requirements of these new technologies.
Restrictions for Using the G.8275.2 Profile

• In G.8275.2, PTP can be used in both hybrid mode and non-hybrid mode. In hybrid mode, PTP is used
to provide phase and time-of-day throughout the network synchronization along with PHY layer frequency
support (SyncE). In non hybrid mode, PTP is used without PHY layer frequency support (SyncE).
119
Basic Configuration
How to Configure the G.8275.2 Profile
• A G.8275.2 PTP clock can have redundant clock sources configured (through multiple PTP ports).
However, at any given time, a G.8275.2 PTP clock synchronizes to only one clock source, which is
selected by BMCA.
• The G.8275.2 does not provide any recommendations for performance analysis and network limits for
the clocks.
How to Configure the G.8275.2 Profile

Creating an Ordinary Subordinate (T-TSC-P)
Cisco cBR-8 supports PTP ordinary clock subordinate mode with G8275.2 profile. In this mode, PTP ports
are either on the Supervisor PIC cards or on the 10GE Ethernet ports on the DPIC cards.
To create an ordinary subordinate, run the following steps:
ptp clock Ordinary domain 44
clock-port slave-port slave profile G.8275.2
transport ipv4 unicast interface lo 0 negotiation
Configuring Dual PTP Primary Clocks

Dual PTP primary clocks must connect to the same grandmaster. Both PTP primary clocks and the grandmaster
must be set to Priority 2 configuration. You must set the minimum Priority 2 value for the grandmaster to
keep the highest priority. The PTP primary clocks connected to the grandmaster must have a Priority 2 value.
The following example shows a grandmaster in the Dual PTP primary clocks configuration:
Router# show run | se ptp
license feature ptp
priority2 2
clock-port master-to-two903 master profile g8275.2
sync interval -5
sync one-step
Configuring the G.8275.2 Profiles

To configure G.8275.2 Profiles, run the following steps:
Router# config terminal
Router(config)# ptp clock ordinary domain 55
Router(config-ptp-clk)#servo tracking-type R-DTI
Router(config-ptp-clk)#clock-port slave-port slave profile g8275.2
Router(config-ptp-port)# delay-req interval -4
Router(config-ptp-port)# sync interval -4
Router(config-ptp-port)# sync one-step
Router(config-ptp-port)# transport ipv6 unicast interface Lo1588 negotiation
Router(config-ptp-port)# clock source ipv6 2001:158:158:158::158
120
Basic Configuration
Configuring an IPv4 Single Clock Source

To configure IPv4 single clock source, run the following steps:
sync one-step

To configure IPv6 single clock source, run the following steps:
sync one-step
clock source ipv6 <clock ip>
Verifying the G.8275.2 Profile

To verify the G.8275.2 profile, run the following command:
Router# show run | se ptp
clock-port slave-port slave profile g8275.2
sync interval -4
sync one-step
transport ipv6 unicast interface Lo1588
negotiation
clock source ipv6 2001:158:158:158::158
The following example shows IPv4 single clock source configuration:
sync interval -5
sync one-step
The following example shows IPv6 single clock source configuration:

ptp clock ordinary domain 55 profile g8275.2
121
Basic Configuration
DPIC PTP Primary
sync interval -5
sync one-step
DPIC PTP Primary

Effective Cisco IOS XE Fuji 16.12.1y, Cisco cBR Converged Broadband router provides support for Digital
Physical Interface Card (DPIC) Precision Time Protocol (PTP) Primary. With the DPIC PTP Primary feature,
RPD will sync to the PTP primary with some switch between them.
The DPIC PTP Primary feature has the following capabilities:
• PTP primary will work as ordinary clock (OC mode) when using default profile
• PTP primary will work as Boundary clock (BC mode limited) only when using G8275.2 Profile
• Supports PTP One-step mode
• Supports IPv4/IPv6 UDP PTP packets
• Supports up to 200 RPDs, 100 RPDs when ptp redundancy is configured
• Supports G8275.2 Profile
• Supports SUPHA and LCHA configurations
Note The following scenarios are not supported:

• PTP packets that are sent and received through SUPPIC or DPIC100
• Boundary clock mode with both primary and subordinate clock port
• Two step mode
• Dual Stack (IPv4/v6)
Configuring DPIC PTP Primary

The DPIC PTP Primary configuration involves the following steps in sequence:
1. Basic setup
a. Configure cBR as PTP Primary with its loopback interface.
Ensure that the IP address of cBR loopback interface and RPD core interface should be in global or
same VPN Routing/Forwarding (VRF).
b. In RPD, configure cBR loopback as its PTP Primary IP.
c. Ensure that the RPD uses its core interface IP as its PTP Gateway.
122
Basic Configuration
Configuring DPIC PTP Primary
Note The PTP traffic between cBR loopback interface and RPD are routed through the RPD core interface. Therefore,
IP address of the cBR loopback interface and RPD core interface should be in global or same VRF.
2. PTP setup redundancy

If Line Card High Availability (LCHA) is configured, RPD uses the corresponding DPIC interface on
standby LC as it is an alternate clock source and gateway. Use the following snippet to configure the
LCHA for PTP redundancy:
ptp r-dti <id>

ptp-domain <domain id>
clock-port <port id>
clock source <ip address> gateway ip <ip address >
clock source <ip address> gateway ip <ip address >alternate
3. Configure using either of the following formats:

• With Default Profile
• For cBR PTP configuration:

clock-port <port_name0> master
sync interval <interval>
sync one-step
transport <ipv4/ipv6> unicast interface <loopback0> negotiation
sync one-step
sync one-step
.
.
.
sync one-step
Note cBR supports up to 64 clock-ports.
• For RPD PTP configuration:
ptp r-dti <id>

ethernet x
[transport ipv6]
clock source [ipv6] <ip address> gateway ip <ip address >
clock source [ipv6] <ip address> gateway ip <ip address >alternate
123
Basic Configuration
Verifying the DPIC PTP Primary
Note The gateway ip is the active and standby core interface
• With G8275.2 Profile

• For cBR PTP configuration:

clock-port <port_name0> master profile G8275.2
sync one-step
sync one-step
sync one-step
.
.
.
sync one-step
Note By the ITU G8275.2 Profile specification, the ordinary clock supports only one
clock-port with G8275.2 Profile. You need to use the boundary clock if you have
scenarios where multiple clock-ports are required.
• For RPD PTP configuration:
ptp r-dti <id>

profile G.8275.2
ethernet x
[transport ipv6]
clock source [ipv6] <ip address> gateway ip <ip address >
clock source [ipv6] <ip address> gateway ip <ip address >alternate
Note The gateway IP is the active and standby core interface.

Use the following options to verify your DPIC PTP Primary configuration:
124
Basic Configuration
• To check the cBR and RPD PTP configuration, use the show run | se ptp command. The syntax is as
follows:
show run | se ptp

sync one-step
sync one-step
sync one-step
.
.
.
sync one-step
• To check the PTP Primary state, you can use the show ptp clock running domain <id> command. See
the following example:
Router# show ptp clock running domain 55

Time source is NTP, 04:34:17.164 CST Tue Dec 19 2017
PTP Boundary Clock [Domain 55]
State Ports Pkts sent Pkts rcvd Redundancy Mode
FREQ_LOCKED 2 2005322 971815 Hot standby
PORT SUMMARY
PTP Master
Name Tx Mode Role Transport State Sessions Port Addr
22 unicast master Lo1588 Master 2 -

33 unicast master Lo1589 Master 2 -
SESSION INFORMATION
22 [Lo1588] [Sessions 2]
Peer addr Pkts in Pkts out In Errs Out Errs
2001:120:101:16:A94F:61DB:D324:76B4 240839 497336 0 0

2001:120:101:16:2827:F9A6:4332:81AF 245193 505541 0 0
125
Basic Configuration
33 [Lo1589] [Sessions 2]
Peer addr Pkts in Pkts out In Errs Out Errs
2001:120:101:16:A94F:61DB:D324:76B4 240582 496880 0 0

2001:120:101:16:2827:F9A6:4332:81AF 245201 505565 0 0
Router#
• To check detailed stream statistics, use the show platform software ptpd stat stream <id|ip>
command. For example:
Router# show platform software ptpd stat stream 2001:120:101:16:A94F:61DB:D324:76B4

IP-Address : 2001:120:101:16:a94f:61db:d324:76b4 Stream-Number: 0
SYNC Contract
Remaining Duration : 105 (secs), State : ACTIVE
Tx packets : 247592, Rx Packets : 0 Error Packets : 0
Announce Contract
Delay-Response Contract
Router# show platform software ptpd stat stream 0

LOCK STATUS : FREERUN
SYNC Packet Stats
Time elapsed since last packet: 0.0
Configured Interval : -4, Acting Interval -4
Tx packets : 247325, Rx Packets : 0
Last Seq Number : 0, Error Packets : 0
Delay Req Packet Stats
Configured Interval : 0, Acting Interval : -4
Delay Response Packet Stats
Configured Interval : -4, Acting Interval : -4
Announce Packet Stats
Configured Interval : 0, Acting Interval : 0
Last Seq Number 0 Error Packets 0
Signalling Packet Stats
Configured Interval : 0, Acting Interval : 0
Current Data Set
Offset from master : +0.000000000
Mean Path Delay : +0.000000000
Forward Path Delay : +0.000000000
Reverse Path Delay : +0.000000000
Steps Removed 0
General Stats about this stream
Packet rate : 0, Packet Delta (ns) : 0
Clock Stream handle : 0, Index : 0
126
Basic Configuration
Oper State : 3, Sub oper State : 6

Log mean sync Interval : 0, log mean delay req int : 0
• To check the RPD PTP state, you can use the following commands:
• show ptp clock 0 state command is used to check the PTP state on RPD. For example:
Router# show ptp clock 0 state

apr state : PHASE_LOCK
clock state : SUB_SYNC
current tod : 1423125872 Thu Feb 5 08:44:32 2015
active stream : 0
==stream 0 :
port id : 0
master ip : 2001:158:158:158::158
stream state : PHASE_LOCK
Master offset : -110
Path delay : 957
Forward delay : 888
Reverse delay : 1026
Freq offset : -418299
1Hz offset : 40
==stream 1 :
port id : 0
master ip : 2001:158:158:158::159
stream state : PHASE_LOCK
Master offset : -15
Path delay : 969
Forward delay : 916
Reverse delay : 1023
Freq offset : -418526
1Hz offset : 47
Router#
• The show ptp clock 0 statistics command is used to check PTP packets statistics on RPD. See the
following example usage:
Router# show ptp clock 0 statistics

AprState 4 :
2@0-00:11:41.897 1@0-00:11:32.266 0@0-00:09:37.062
4@0-00:09:17.861
ClockState 5 :
5@0-00:12:02.947 4@0-00:11:59.305 3@0-00:11:55.663
2@0-00:11:42.664 1@0-00:11:41.866
BstPktStrm 1 :
0@0-00:09:10.010
StepTime 1 :
773016962@0-00:11:01.145
AdjustTime 3 :
12@0-00:13:57.520 -280@0-00:13:33.895 -1137@0-00:11:27.895
fwdFltr 0 :
Total: 4828 Drop: 513
MEAN: 973 stdDev: 974
Threshold: -299027 ~ 300973 shrink: 85714
revFltr 0 :
fwdFltr 1 :
127
Basic Configuration
Feature Information for G.8275.2 Profile
revFltr 1 :
Threshold: 619 ~ 300947 shrink: 42904
streamId msgType rx rxProcessed lost tx
0 SYNC 4828 4828 0 0
0 DELAY REQUEST 0 0 0 4827
0 P-DELAY REQUEST 0 0 0 0
0 P-DELAY RESPONSE 0 0 0 0
0 FOLLOW UP 0 0 0 0
0 DELAY RESPONSE 4827 4827 3 0
0 P-DELAY FOLLOWUP 0 0 0 0
0 ANNOUNCE 314 314 0 0
0 SIGNALING 5 5 0 5
0 MANAGEMENT 0 0 0 0
TOTAL 9974 9974 3 4832
1 SYNC 1507 1507 0 0
1 DELAY REQUEST 0 0 0 1505
1 P-DELAY REQUEST 0 0 0 0
1 P-DELAY RESPONSE 0 0 0 0
1 FOLLOW UP 0 0 0 0
1 DELAY RESPONSE 1505 1505 2 0
1 P-DELAY FOLLOWUP 0 0 0 0
1 ANNOUNCE 103 103 0 0
1 SIGNALING 2 2 0 7
1 MANAGEMENT 0 0 0 0
TOTAL 3117 3117 2 1512
Router#
Feature Information for G.8275.2 Profile

Table 12: Feature Information for G.8275.2 Profile
G.8275.2 Profile Cisco IOS XE Fuji 16.8.1 This feature was introduced in Cisco
IOS XE Fuji 16.8.1 on Cisco cBR
DPIC PTP Primary Cisco IOS XE Gibraltar 16.12.1y This feature was introduced in Cisco
IOS XE Gibraltar 16.12.1y on Cisco
cBR Series Converged Broadband
Router.
128
CHAPTER 8
Model-Driven Telemetry
This document provides information on the support for Model-Driven Telemetry and how to configure Cisco
cBR series routers to avail the support.
• Information About Model-Driven Telemetry, on page 131
• Restrictions for Model Driven Telemetry, on page 131
• Prerequisites to Enable Telemetry, on page 132
• Configuring Telemetry, on page 132
• Feature Information for Model-Driven Telemetry, on page 135
129
Basic Configuration
Digital PICs:

Module:

Modules:
line card reload.
130
Basic Configuration
Information About Model-Driven Telemetry
Information About Model-Driven Telemetry

Model-driven telemetry allows Cisco cBR-8 Converged Broadband Router to continuously stream real time
configuration and operating state information to collectors. This module describes model-driven telemetry
and provides sample telemetry RPCs.
Model-driven telemetry uses YANG models to express available data. Contents of supported YANG files can
be retrieved from cBR8 directly. Collectors can subscribe to specific data items they need, by using these
standard-based YANG data models. Telemetry can continuously stream data to the collector with periodical
or on-change mode.
YANG-filed MIBs models, following DOCSIS MIBs are converted to YANG models, and they are
automatically converted from legacy MIB file to YANG file. All the data for a converted MIB is received
from the legacy SNMP agent and then sent to Telemetry receiver by gRPC/NETCONF.
Cisco IOS XE Gibraltar 16.12.1 on Cisco cBR Series Converged Broadband Router includes a native
Cisco-IOS-XE-docsis-oper YANG file along with the YANG-filed MIB models. In the
Cisco-IOS-XE-docsis-oper YANG file the output of some show commands will be modeled.
Note Ensure that you have enabled the cable bgsync active CLI for Cisco-IOS-XE-docsis-oper. The
Cisco-IOS-XE-docsis-oper is required to get the correct data for cable modems.
• CISCO-CABLE-SPECTRUM-MIB
• CISCO-CABLE-WIDEBAND-MIB
• CISCO-DOCS-EXT-MIB
• DOCS-IF-MIB
• DOCS-IF3-MIB
• DOCS-QOS-MIB
• DOCS-SUBMGT3-MIB
• CISCO-ENVMON-MIB
• CISCO-PROCESS-MIB
• OLD-CISCO-INTERFACES-MIB
• SNMPv2-MIB
• ENTITY-MIB
• IF-MIB
Restrictions for Model Driven Telemetry

Following are the restrictions on using the Model-Driven Telemetry:
131
Basic Configuration
Prerequisites to Enable Telemetry
• All DOCSIS-specific models are supported for periodical push. On-change push is not supported.
• For the same MIB model, a NETCONF subscription’s performance is lower than the legacy SNMP walk.
Prerequisites to Enable Telemetry

Run the following command to ensure that the prerequisites are in place to configure Telemetry:
conf t
ip ssh version 2
netconf-yang
netconf-yang cisco-ia snmp-community-string testing-mib-yang
snmp-server community testing-mib-yang RO
end
Ensure that you go through the following recommendations before configuring telemetry:
• Use the show platform software yang-management process command to verify that all related processes
are running.
• The default listening tcp port number for NECCONF is 830. You can change the default port by using
the netconf-yang ssh port CLI.
• An snmp-community-string is needed for gRPC/NETCONF to retrieve YANG filed MIB. The default
snmp-community-string is ‘private’.
Configuring Telemetry
The following Telemetry protocols are supported on Cisco cBR-8 Converged Broadband Router:
• gRPC: gRPC only supports Dial-Out (Configured/Static). Initial connection starts from cBR8 triggered
by CLI configuration.
• NETCONF: NETCONF only supports Dial-In (Dynamic). Initial connection starts from telemetry
collectors.
Configuring Telemetry using gRPC

The gRPC only supports the dial-out method. You need CLI configurations on cBR-8 to create a gRPC
subscription.
To create a dial-out subscription, go through the following sample. Note that the patameteres in bold cannot
be changed.
Conf t
telemetry ietf subscription 100
encoding encode-kvgpb
filter xpath /IF-MIB:IF-MIB/ifTable/ifEntry[ifIndex=263975]
source-address 172.22.9.102
stream yang-push
update-policy periodic 3000
132
Basic Configuration
Configuring Telemetry using gRPC
receiver ip address 10.79.41.133 57566 protocol grpc-tcp

end
Note Multiple target XPaths is not supported.
To delete a subscription, run the no telemetry ietf subscription 100 command.

The following show commands are supported for gRPC:
• show telemetry ietf subscription configured detail
• show telemetry ietf subscription 100 receiver
The following examples illustrate the usage of the show commands:
router# show telemetry ietf subscription configured detail
Telemetry subscription detail:

Subscription ID: 100
State: Valid
Stream: yang-push
Filter:
Filter type: xpath
XPath: /IF-MIB:IF-MIB/ifTable/ifEntry[ifIndex=263975]
Update policy:
Update Trigger: periodic
Period: 3000
Encoding: encode-kvgpb
Source VRF: Mgmt-intf
Source Address: 172.22.9.102
Notes:
Receivers:
Address Port Protocol Protocol Profile
-----------------------------------------------------------------------------------------
10.79.41.133 57566 grpc-tcp
router# show telemetry ietf subscription 100 receiver

Telemetry subscription receivers detail:

Address: 10.79.41.133
Port: 57566
Protocol: grpc-tcp
Profile:
State: Connected
Explanation:
Note • A Valid state denotes that the configuration is good and accepted.
• A Connected state denotes that the TCP connection is established.
133
Basic Configuration
Configuring Telemetry using NETCONF
Configuring Telemetry using NETCONF

The NETCONF communication happens in the followong sequence:
1. Connect to device. Say <hello>.
2. Retrieve <capabilities>.
3. Investigate and choose the appropriate model.
4. Compose operation.
5. Send message <rpc>.
6. Retrieve <rpc-reply>.
7. Process <data>.
The following example lists how a Telemetry subscriber subscribes to an instances in an MIB:
<establish-subscription
xmlns="urn:ietf:params:xml:ns:yang:ietf-event-notifications"
xmlns:yp="urn:ietf:params:xml:ns:yang:ietf-yang-push">
<stream>yp:yang-push</stream>
<yp:xpath-filter>/IF-MIB:IF-MIB/ifTable/ifEntry[ifIndex="263975"]</yp:xpath-filter>
<yp:period>3000</yp:period>
</establish-subscription>
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="2">

<subscription-result xmlns='urn:ietf:params:xml:ns:yang:ietf-event-notifications'
xmlns:notif-bis="urn:ietf:params:xml:ns:yang:ietf-event-notifications">notif-bis:ok</subscription-result>
<subscription-id
xmlns='urn:ietf:params:xml:ns:yang:ietf-event-notifications'>2147483655</subscription-id>
</rpc-reply>
Note • The ifIndex option lists the model defined in the YANG file.
• The yp:period lists the expected time interval between push updates (3000 centisecond in this example).
The following is an example of the show or delete NETCONF subscription option:
Router# show telemetry ietf subscription 2147483655 detail

Telemetry subscription detail:
Type: Dynamic
State: Valid
Stream: yang-push
Filter:
Filter type: xpath
XPath: /IF-MIB:IF-MIB/ifTable/ifEntry[ifIndex="263975"]
Update policy:
Update Trigger: periodic
Period: 3000
Encoding: encode-xml
Source VRF:
134
Basic Configuration
Feature Information for Model-Driven Telemetry
Source Address:
Notes:
Receivers:
Address Port Protocol Protocol Profile
-----------------------------------------------------------------------------------------
10.79.41.133 38914 netconf
Router# clear telemetry ietf subscription 2147483655

Table 14: Feature Information for Model-Driven Telemetry
Model-Driven Telemetry Cisco IOS XE Gibraltar 16.12.1 This feature was introduced in Cisco
IOS XE Gibraltar 16.12.1 on Cisco cBR
135
Basic Configuration
136
PA R T II
High Availability Configuration
• Cisco IOS-XE In-Service Software Upgrade Process, on page 139
• Supervisor Redundancy, on page 145
• Line Card Redundancy, on page 161
CHAPTER 9
Cisco IOS-XE In-Service Software Upgrade
Process
Cisco cBR-8 Routers support the In-Service Software Upgrades (ISSU) for redundant platforms.
Contents
• Information about In-Service Software Upgrade, on page 141
• How to Configure In-Service Software Upgrade, on page 141
• Feature Information for In-Service Software Upgrade, on page 144
139
Digital PICs:

Module:

Modules:
line card reload.
140
Information about In-Service Software Upgrade
Information about In-Service Software Upgrade

Cisco cBR-8 Routers support the In-Service Software Upgrades (ISSU) for redundant platforms. The ISSU
process allows software to be updated or otherwise modified while packet forwarding continues with the
benefit of LCHA.
For the Cisco cBR Series Routers, ISSU-compatibility depends on the software subpackage being upgraded
and the hardware configuration.
The specific procedures in this document represent supported and tested installation sequences. The Cisco
IOS-XE system software allows other installation sequences for special purposes under the guidance of Cisco
customer support representatives, but the steps in this document should be followed otherwise. These steps
should be followed completely, as the Cisco cBR Series Routers are designed to run one version of Cisco
IOS-XE on an SUP, and running subpackages from different versions of Cisco IOS-XE can cause unexpected
router behavior.
How to Configure In-Service Software Upgrade

This section describes the configuration of the ISSU feature:
Configuring Subpackage Upgrade

Subpackages Upgrade
Subpackage upgrade allows a subset of the running software to be upgraded. It is intended for patching small
and targeted fix instead of full image upgrade. Subpackage upgrade supports both single and dual SUP setup.
Single SUP Subpackages Upgrade
Before you begin

Be sure to complete the following prerequisites before running the ISSU process:
• Config register autoboot enabled.
• Target patch copied to active SUP in the same directory of the packages.conf file system is booted up
with.
• If needed copy patch info file to SUP.
• Enough bootflash disk space on SUP.
Procedure

Router> enable
141
Dual SUPs Subpackages Upgrade

Step 2 request platform software package install rp rp-slot file Upgrades the cBR-8 router with one SUP using subpackages
bootflash: ISSU procedure.
Example:
Router# request platform software package install

rp 1 file
bootflash:cbrsup-universalk9.03.17.00.S.156-1.S-std.SPA.bin
Dual SUPs Subpackages Upgrade
Before you begin

Be sure to complete the following prerequisites before running the ISSU process:
• Standby SUP must be in hot standby.
• Config register autoboot enabled.
• Both SUP in sub-package mode, running same base image and patches from same path.
• Target patch copied to active SUP in the same directory of the packages.conf file system is booted up
with.
• If needed copy patch info file to both SUPs.
• Enough bootflash disk space on both SUPs.
Procedure

Router> enable
Step 2 request platform software package install node file Upgrades the cBR-8 router with dual SUPs using
bootflash: subpackages ISSU procedure.
Example:

node file
bootflash:cbrsup-universalk9.03.17.00.S.156-1.S-std.SPA.bin
Line Card Only In-Service Software Upgrade

If the upgrade fails or you cancel manually at line card upgrade stage, you can initiate a line card only upgrade.
Use the request platform software package install node linecard-only command to upgrade only the line
card to the same version as the one in the current active SUP, the customer can choose to upgrade one line
card or all the line cards in the chassis.
Use this command together with the request platform software package install node file file-path noreload
linecard command to upgrade SUP first, and then upgrade the line card.
142
ISSU Upgrade Across Major Releases
Procedure

Router> enable
Step 2 request platform software package install node Upgrade all line cards to the same version as the one in the
linecard-only current active SUP.
Example:

node linecard-only all
ISSU Upgrade Across Major Releases

Starting from Cisco IOS XE Fuji 16.7.1 release, ISSU can upgrade cbr-8 between major releases.
Step 1 Copy the base image to active and standby SUPs. Copy the ISSU target image to active SUP.
copy <location>/<base_image> <location_active_sup>

copy <location>/<base_image> <location_standby_sup>
copy <location>/<target_image> <location_active_sup>
Step 2 Expand base image to both SUPs at the same folder.
request platform software package expand file <location_active_sup>/<base_image>

request platform software package expand file <location_standby_sup>/<base_image>
Step 3 Config register for auto boot (eg) config-reg 0x2102.
config-register 0x2102
boot system <location_active_sup>/packages.conf
Step 4 Save then reload router via subpackage mode.
reload
Step 5 After boot up, verify base image loaded using show version running and check more.
Step 6 Copy the target image to active SUP in the same location as before.
copy <location>/<target_image> <location_active_sup>
143
Step 7 Using Request command to do ISSU.

request platform software package install node file <location_active_sup>/<target_image>
The following sections provide references related to the ISSU feature.
Description Link
The Cisco Support and Documentation website provides http://www.cisco.com/cisco/web/support/index.html

online resources to download documentation, software,
and tools. Use these resources to install and configure
the software and to troubleshoot and resolve technical
issues with Cisco products and technologies. Access to
most tools on the Cisco Support and Documentation
website requires a Cisco.com user ID and password.
Feature Information for In-Service Software Upgrade

Table 16: Feature Information for ISSU
ISSU Cisco IOS XE Fuji This feature was integrated on the cisco cBR Series Converged
16.7.1 Broadband Routers.
144
CHAPTER 10
Supervisor Redundancy
The Supervisor Redundancy feature reduces unplanned downtime. It enables a quicker switchover between
active and standby Supervisors when a fatal error occurs on the active Supervisor. When you configure
Supervisor Redundancy, the standby Supervisor is synchronized with the active Supervisor. If a fatal error
occurs on the active Supervisor, the system immediately switches to the standby Supervisor.
Contents
• Prerequisites for Supervisor Redundancy, on page 147
• Information About Supervisor Redundancy, on page 147
• How to Configure Supervisor Redundancy, on page 150
• Verifying the Supervisor Redundancy Configuration, on page 155
• Configuration Example for Supervisor Redundancy, on page 159
• Feature Information for Supervisor Redundancy, on page 160
145
Digital PICs:

Module:

Modules:
line card reload.
146
Prerequisites for Supervisor Redundancy
Prerequisites for Supervisor Redundancy

• Two Supervisors (that is, two Supervisor Cards and two Supervisor PICs) must be installed in the Cisco
cBR chassis.
• Both Supervisors must be running identical software releases. If there is release mismatch, when inserting
the standby Supervisor, either the standby Supervisor or the active Supervisor may be impacted, even
reloaded. So before inserting the new standby Supervisor, make sure it will boot with the identical
software release as the active Supervisor.
Information About Supervisor Redundancy

The Supervisor redundancy feature enables the Cisco cBR router to use two Supervisors in a redundant
configuration, so that if the active Supervisor fails or becomes inactive, the system automatically performs a
switchover , where the standby Supervisor takes over and assumes full responsibility for systems operations.
The Supervisor redundancy feature does not require a full reboot of the system to perform a switchover. When
the system boots up, the standby Supervisor performs full initialization, which includes self initialization,
running configuration synchronization from the active Supervisor, and SSO feature data synchronization from
the active Supervisor, then it enters into hot standby state and monitors the active Supervisor. If the standby
Supervisor detects a failure in the active Supervisor, it can quickly assume the active responsibility for systems
operations.
Each Supervisor contains all the resources required to operate the router, such as bootflash memory, hard
disks, Ethernet ports, and console port. In the default operation, the standby Supervisor also synchronizes the
major systems files, such as the running configuration file, so that during a switchover, the standby Supervisor
can duplicate the active Supervisor’s configuration.
You can use Cisco IOS CLI commands to access the standby Supervisor resources, such as the bootflash and
hard disk. For example, you can use the dir command to list the contents of a device, or use the copy command
to transfer files between the active and standby Supervisor.
Switchover Procedure
A switchover occurs when the standby Supervisor takes over responsibilities from the active Supervisor. The
switchover can occur automatically if the standby Supervisor has determined that the active Supervisor has
failed, or an operator can initiate a manual switchover whenever desired.
A switchover triggers the following events:
1. If this is a manual switchover, the active Supervisor verifies that the standby Supervisor is present and
has entered into SSO. If so, it instructs the standby Supervisor to begin switchover procedures, and the
active Supervisor either attempts to reload its configured Cisco IOS software image or enters ROM monitor
mode, depending on the setting of its configuration register.
2. The standby Supervisor assumes responsibility as the active Supervisor and brings the Cisco cBR chassis
into active state, and continues the service as active Supervisor.
3. The new active Supervisor begins normal systems operations, including passing traffic.
147
Using Redundant File Systems
Note The Supervisor does not begin functioning as a standby Supervisor until it is booted up with a proper Cisco
IOS software.
Is Supervisor Switchover Failing?

The usual phenomenon for a Supervisor switchover to be affected is when the active Supervisor has these
issues:
• Supervisor hangs
• Login to Supervisor console or Telnet to chassis fails
• Interface cards unable to connect to active Supervisor, hence crashing
• Cable modems drop offline
• Chassis reload required
• Reset of active Supervisor required to restore service
Note In case there is hardware issue with the Supervisor, do not reinsert the faulty Supervisor in the chassis. Inserting
a faulty Supervisor (although a standby Supervisor) may cause the interface card to switch to the faulty
Supervisor causing the interface card to crash and cable modems to go offline.

Both the active and standby Supervisors have active file systems that can be accessed to store and transfer
files. The table below lists the available file systems, the filenames that you can use with CLI commands to
access the file systems,and a short description of each.
File System File Name for CLI Commands Description
• Bootflash • bootflash: Stores image, crash file, core files,

saved configuration files, and
• Flash • flash: various user files.
• Hard disk • harddisk:
• USB • usb0:
• Standby bootflash • usb1:
• Standby hard disk • stby-bootflash:
• Standby USB • stby-harddisk:
• stby-usb0:
• stby-usb1:
148
File System File Name for CLI Commands Description
• System • system: Stores the running configuration

and other system files.
• Temporary system • tmpsys:
• Null • null:
• Tar • tar:
• Syslog • syslog:
• CNS • cns:
• RCSF • revrcsf:
• NVRAM • nvram: Typically stores the system default

configuration file and startup
• Standby NVRAM • stby-nvram: configuration file.
• Standby RCSF • stby-rcsf:
• TFTP • tftp: Protocols used to transfer files to

and from remote devices.
• RCP • rcp:
• PRAM • pram:
• FTP • ftp:
• HTTP • http:
• SCP • scp:
• HTTPS • https:
You can use the privileged EXEC commands dir, del, and copy to manage the contents of the file systems.
You can also use the commands mkdir and rmdir to create and remove directories on bootflash or hard disks.
Following is a sample output of the show file systems command on the Cisco cBRrouter:
Router# show file systems
File Systems:
Size(b) Free(b) Type Flags Prefixes

- - opaque rw system:
- - opaque rw tmpsys:
* 7800705024 1574408192 disk rw bootflash:
7800705024 1574408192 disk rw flash:
98394218496 79534682112 disk rw harddisk:
8009056256 8009023488 disk rw usb1:
33554432 33507452 nvram rw stby-nvram:
- - opaque rw null:
- - opaque ro tar:
- - network rw tftp:
- - opaque wo syslog:
33554432 33508476 nvram rw nvram:
- - network rw rcp:
- - network rw pram:
149
Console Port Usage After Supervisor Switchover
- - network rw ftp:
- - network rw http:
- - network rw scp:
- - network rw https:
- - opaque ro cns:
- - nvram rw stby-rcsf:
7800705024 1635270656 disk rw stby-bootflash:
98394218496 89040576512 disk rw stby-harddisk:
- - disk rw stby-usb0:
1000787968 301559808 disk rw stby-usb1:
- - opaque rw revrcsf:
Console Port Usage After Supervisor Switchover

When an active Supervisor fails, and the standby Supervisor becomes the active Supervisor, you must use the
console port on the new active Supervisor to give CLI commands and display statistics for the router. The
standby Supervisor console is disabled by default and cannot be used to run any CLI commands. Following
is an sample output of the standby Supervisor console:
Router-stby>
Standby console disabled
Router-stby>
To access the console, move the PC or terminal's serial cable to the console port on the other Supervisor,
which is now acting as the active Supervisor.
Benefits
• The Supervisor is not a single point of hardware failure. If a permanent hardware failure in the active
Supervisor occurs, the standby Supervisor recovers the system, increasing the level of network service
and reliability.
• The standby Supervisor can become the active Supervisor without the manual intervention of a system
operator. This reduces the recovery time and the need for an instant response from the network
administrators.
• The active Supervisor continues to dynamically synchronize the changed configuration and feature data
with the standby Supervisor after the system reaches SSO. Therefore, the standby Supervisor always
operates as a hot standby and ready to take over.
How to Configure Supervisor Redundancy

The Supervisor redundancy feature is automatically enabled when two Supervisor are installed in the Cisco
cBR chassis. The active Supervisor automatically synchronizes the running configuration file with the standby
Supervisor during the bootup of standby Supervisor.
Note The Cisco cBR router supports only the SSO mode for Supervisor redundancy. The default redundancy mode
is SSO and this mode does not need any new configurations.
150
Forcing Switchover
Forcing Switchover
To manually force a switchover, so that the standby Supervisor becomes active, use the redundancy
force-switchover command in privileged EXEC mode on the active Supervisor. Manually forcing a switchover
is useful in the following situations:
• You need to remove, replace, or upgrade the currently active Supervisor.
• A previous switchover has activated the standby Supervisor and you now want to restore the previously
active Supervisor.
Tip Simply removing the active Supervisor also triggers a switchover, but using the redundancy force-switchover
command does not generate a hardware alarm.
Before you begin

Ensure that the standby Supervisor is in the SSO state using the show redundancy command. For more
information, see Verifying Supervisor Redundancy , on page 155.
Step 1 Set the configuration register as 0x02 and the load the appropriate image on both the Supervisors
Example:
Router(config)# boot system bootflash:cbrsup-universalk9.2015-03-08_01.38_xxxxx.SSA.bin
Note Do not perform this step if you want to set the previous active Supervisor to stay in ROM monitor mode or
manually boot it up after the switchover.
Step 2 Use the redundancy force-switchover command to force the switchover.

Example:
Router# redundancy force-switchover
Proceed with switchover to standby RP? [confirm]

Manual Swact = enabled
Jan 1 19:23:22.483 R0/0: %PMAN-5-EXITACTION: Process manager is exiting: process exit with reload
fru code
Initializing Hardware ...
System Bootstrap, Version 12.2(20141120:061458) [153], DEVELOPMENT SOFTWARE

Compiled Thu 11/20/2014 18:04:24.91 by xxxxx
The standby Supervisor becomes the active Supervisor.
151
Changing the System Boot Behavior
Step 3 (Optional) If you have not performed Step 1, on page 151, the previous active Supervisor is put into the ROM monitor
mode after the switchover. To enable the previous active Supervisor to become the new standby Supervisor, manually
boot up the new standby Supervisor to enter into SSO mode.

This section describes how to change the Cisco IOS software configuration register for modifying the system
behavior when powering up or rebooting the system. The software configuration register is a 16 bit register
in NVRAM that controls the following boot functions:
• Specifies the source of the Cisco IOS software image to be loaded
• Specifies whether the Cisco IOS software must ignore the contents of the saved configuration file in
NVRAM memory
• Enables or disables the use of the Break function
Use the following procedure to change the software configuration register settings:
Step 1 Enter global configuration mode and use the config-register command to set the contents of the software configuration
register to a new value.
Specify the new value as a 16 bit hexadecimal bitmask by using the values provided in the following table.
Table 18: Definition of Bits in the Software Configuration Register
Bit No. Hex Value Meaning/Function
00 to 03 0x0000 to 0x000F Defines the source of the default Cisco IOS software image required to run the router:
• 00—When powering up, the system remains at the ROM monitor prompt (rommon),
awaiting a user command to boot the system manually by the rommon boot
command.
• 01—When powering up, the system automatically boots the first system image
found in the flash memory's single in-line memory module (SIMM) on the
Supervisor.
• 02 to 0F—When powering up, the system automatically boots from a default Cisco
IOS software image stored on a TFTP server in the network. For this setting,
configure and enable the Network Management Ethernet port on the Supervisor.
The port must be operational. This setting also enables boot system commands
which can override the default filename.
06 0x0040 Causes system software to ignore the contents of the NVRAM configuration file.
07 0x0080 Enables the original equipment manufacturer (OEM) bit.
08 0x0100 Disables the Break function after 30 seconds.
09 0x0200 Not used.
152
Bit No. Hex Value Meaning/Function
10 0x0400 Specifies that broadcast packets are based on the 0.0.0.0 IP address.
11 and 12 0x0800 to 0x1000 Defines the console baud rate (the default value is 9600 baud).
13 0x2000 Boots an image from the boot flash memory.
14 0x4000 Specifies that the broadcast packets must use the subnet broadcast address.
15 0x8000 Enables diagnostic messages and ignores the contents of the NVRAM configuration file.
For example, to configure the router to boot to the ROM monitor prompt, set the configuration register to 0x2100 with
the following commands:
Example:
Router# config t
Router(config)#
Tip The typical bitmask for normal use is 0x2102. It specifies that the router must load the Cisco IOS software
from the flash memory and boot to the Cisco IOS CLI prompt. The Break key is enabled only for 30 seconds.
Hence, if required, you can break to the ROM monitor prompt.
Step 2 Exit the global configuration mode.

Example:
Router#
Step 3 View the new software configuration register setting using the show version command.
The last line shows the settings of the configuration register:
Example:
Router# show version
Cisco IOS XE Software, Version 2015-03-04_00.38_xxxxx
Cisco IOS Software, IOS-XE Software (X86_64_LINUX_IOSD-UNIVERSALK9-M), Experimental \
Version 15.5(20150302:044048) [v155_2_s_xe315_throttle-xxxxx-XE315_0301 121]
This software is an Engineering Special
Copyright (c) 1986-2015 by Cisco Systems, Inc.
Compiled Wed 04-Mar-15 00:21 by xxxxx
Cisco IOS-XE software, Copyright (c) 2005-2015 by cisco Systems, Inc.

All rights reserved. Certain components of Cisco IOS-XE software are
licensed under the GNU General Public License ("GPL") Version 2.0. The
software code licensed under GPL Version 2.0 is free software that comes
with ABSOLUTELY NO WARRANTY. You can redistribute and/or modify such
GPL code under the terms of GPL Version 2.0. For more details, see the
documentation or "License Notice" file accompanying the IOS-XE software,
or the applicable URL provided on the flyer accompanying the IOS-XE
software.
ROM: IOS-XE ROMMON
Router uptime is 14 minutes
153
Uptime for this control processor is 17 minutes

System returned to ROM by SSO Switchover
System image file is "bootflash:cbrsup-universalk9.2015-03-04_00.38_xxxxx.SSA.bin"
Last reload reason: Reload Command
This product contains cryptographic features and is subject to United

States and local country laws governing import, export, transfer and
use. Delivery of Cisco cryptographic products does not imply
third-party authority to import, export, distribute or use encryption.
Importers, exporters, distributors and users are responsible for
compliance with U.S. and local country laws. By using this product you
agree to comply with applicable laws and regulations. If you are unable
to comply with U.S. and local laws, return this product immediately.
A summary of U.S. laws governing Cisco cryptographic products may be found at:
http://www.cisco.com/wwl/export/crypto/tool/stqrg.html
If you require further assistance please contact us by sending email to

export@cisco.com.
cisco cBR1013 (CBR) processor (revision CBR) with 3647635K/6147K bytes of memory.
Processor board ID CSJ13152101
16 Gigabit Ethernet interfaces
32768K bytes of non-volatile configuration memory.
50331648K bytes of physical memory.
7739391K bytes of eUSB flash at bootflash:.
97620247K bytes of SATA hard disk at harddisk:.
979258K bytes of USB flash at usb1:.
Configuration register is 0x2
When you modify the configuration register, the show version command shows both the current value of the register
and the value that will be used during the next reboot or reload.
Step 4 Perform one of the following to save the new software configuration register settings in the configuration file:
• Use the copy running-config startup-config command.
• Use the write command.
Example:
Router# write
[OK]
Step 5 The changes to the software configuration register will take effect the next time the router is rebooted or restarted. To
manually reboot the router, use the reload command:
Example:
Router# reload
System configuration has been modified. Save? [yes/no]: yes
Proceed with reload? [confirm]
154
Saving a Configuration File to the Bootflash or Hard Disk
Saving a Configuration File to the Bootflash or Hard Disk

This section describes how to copy a configuration file to a bootflash or hard disk and configure the Cisco
cBR router.
Step 1 Copy the configuration file to the bootflash or hard disks in both Supervisors.
Example:
Router# copy running-config bootflash:cbr8-config
Router# copy running-config stby-bootflash:cbr8-config
Router# copy running-config harddisk:cbr8-config
Router# copy running-config stby-harddisk:cbr8-config
Step 2 (Optional) If the configuration file is currently on a TFTP server, copy the file from the TFTP server to the bootflash or
hard disk in each Supervisor.
Example:
Router# copy tftp://192.168.100.10/router-config bootflash:cbr8-config
Router# copy tftp://192.168.100.10/router-config stby-bootflash:cbr8-config
Router# copy tftp://192.168.100.10/router-config harddisk:cbr8-config
Router# copy tftp://192.168.100.10/router-config stby-harddisk:cbr8-config
Verifying the Supervisor Redundancy Configuration

This section contains the following topics:
Verifying Supervisor Redundancy
Step 1 View the startup configuration and verify whether the lines for configuring redundancy appear:
Example:
Router# show startup-config
...
redundancy
mode sso
...
Step 2 View the current Supervisor redundancy state by running the show redundancy command.
The active Supervisor is typically shown in slot 4 (SUP0).
Router# show redundancy
Redundant System Information :

------------------------------
Available system uptime = 28 minutes
Switchovers system experienced = 0
Standby failures = 0
155
Last switchover reason = none
Hardware Mode = Duplex

Configured Redundancy Mode = sso
Operating Redundancy Mode = sso
Maintenance Mode = Disabled
Communications = Up
Current Processor Information :

-------------------------------
Active Location = slot 4
Current Software state = ACTIVE
Uptime in current state = 28 minutes
Image Version = Cisco IOS Software, IOS-XE Software (X86_64_LINUX_IOSD-UNIVERSALK9-M), Experimental
BOOT = bootflash:cbrsup-universalk9.2015-03-04_00.38_xxxxx.SSA.bin,12;
CONFIG_FILE = bootflash:startup_config1419513118
Configuration register = 0x2
Peer Processor Information :

----------------------------
Standby Location = slot 5
Current Software state = STANDBY HOT
If a switchover occurs, the show redundancy command shows that the active Supervisor has changed slots, moving from
slot 4 (SUP0) to slot 5 (SUP1). The output is similar to the one in the following example.

------------------------------
Last switchover reason = user forced
Hardware Mode = Duplex

Operating Redundancy Mode = sso
Communications = Up

-------------------------------
156

Peer Processor Information :

----------------------------
Standby Location = slot 4
Current Software state = STANDBY HOT
If the standby Supervisor is not installed or is not operational, the show redundancy command gives an output similar
to the following example:

------------------------------
Last switchover reason = user forced
Hardware Mode = Simplex

Operating Redundancy Mode = Non-redundant
Communications = Down Reason: Failure

-------------------------------
Peer (slot: 4) information is not available because it is in 'DISABLED' state
The show redundancy command shows details of the redundancy state, software state, system uptime, image version,
boot, configuration file, and configuration register information.
After supervisor redundancy, the following messages are displayed, for example:
CLC 3/0: May 20 07:26:01.992: %CBR-4-RECONCL_CM_FINISH_CLC: Reconciliation (cdm->ios) for slot 3
finished: total 7, success 5, failed 2, ios-only 2, cdm-only 0, mismatch 0, offline 0,
in-transaction-reconl 0, in-transaction-recover 0.
Where:
157
Verifying Supervisor Switchover
total indicates the overall number of cable modems on each linecard before failover.
success indicates the number of modems, which are remained online during failover.
failed indicates the number of cable modems which have failed reconciliation check, and deleted from database.
ios-only indicates the number of cable modems which has data entry in linecard iosd only, and have been deleted from
database.
cdm-only indicates the number of cable modems which has data entry in linecard cdman (us-schedular) only, and have
been deleted from database.
mismatch indicates the number of cable modems which with data mismatch in the modem instance or service-flows after
failover. These modems have been deleted from database.
offline indicates the number of cable modems which are dropped offline during failover.
in-transaction-reconl indicates the number of cable modems that are deleted due to in dsx operations during failover.
in-transaction-recover indicates the number of cable modems during in dsx operations during failover.
Verifying Supervisor Switchover
Step 1 Verify the LEDs on the Supervisor Card.

When a Supervisor becomes active, the RP ACT and FP ACT LEDs on the Supervisor Card illuminate green to indicate
that they have initialized and acting as the active Supervisor. The RP ACT and FP ACT on standby Supervisor Card are
off. For more information, see Monitoring the Supervisor in the Cisco cBR Chassis.
Step 2 Verify the Supervisor switchover by running the show redundancy switchover history command.
If the original Supervisor is in slot 4 (SUP0) and the standby Supervisor is in slot 5 (SUP1), the output is similar to the
following sample:
Example:
Router# show redundancy switchover history
Index Previous Current Switchover Switchover

active active reason time
----- -------- ------- ---------- ----------
1 48 49 user forced 19:23:11 CST Sun Jan 1 2012
The value 48 indicates SUP0 and 49 indicates SUP1.
After supervisor redundancy, a messages is displayed, below is an example:

CLC 3/0: May 20 07:26:01.992: %CBR-4-RECONCL_CM_FINISH_CLC: Reconciliation (cdm->ios) for
slot 3 finished: total 7, success 5, failed 2, ios-only 2, cdm-only 0, mismatch 0, offline
0, in-transaction-reconl 0, in-transaction-recover 0.
158
Configuration Example for Supervisor Redundancy
Table 19: Message Description
Name Description
total Overall amount of cable modems on each linecard

before failover.
success Indicates the number of cable modems remain online

during failover.
failed Indicates the number of cable modems failed

reconciliation check, and have been deleted from
database.
ios-only Indicates the number of cable modems which has data

entry in linecard iosd only, and have been deleted
from database.
cdm-only Indicates the number of cable modems which has data

entry in linecard cdman (us-schedular) only, and have
been deleted from database.
mismatch Indicates the number of cable modems with data

mismatch in the modem instance or service-flows
after failover. These modems have been deleted from
database.
offline Indicates the number of cable modems dropped offline

during failover.
in-transaction-reconl Indicates the number of cable modems deleted due to

in dsx operations during failover.
in-transaction-recove Indicates the number of cable modems during in dsx

operations during failover.
Configuration Example for Supervisor Redundancy

The following example shows the relevant portion of the Cisco IOS configuration file for the default
configuration of the Supervisor Redundancy feature. Use this configuration for most of the applications:
Router# show running-config | sec redundancy
redundancy
mode sso
Router#
159
Related Documents

CMTS commands Cisco IOS CMTS Cable Command Reference
Stateful Switchover Stateful Switchover
Description Link
ID and password.
Feature Information for Supervisor Redundancy

Table 20: Feature Information for Supervisor Redundancy
Supervisor Redundancy Cisco IOS XE Fuji This feature was integrated on Cisco cBR Series
16.7.1 Converged Broadband Routers.
160
CHAPTER 11
Line Card Redundancy
The line cards support high availability with redundancy schemes. Line card redundancy can help limit
customer premises equipment (CPE) downtime by enabling robust automatic switchover and recovery in the
event that there is a localized system failure.
Contents
• Prerequisites for Line Card Redundancy, on page 163
• Restrictions for Line Card Redundancy, on page 163
• Information About Line Card Redundancy, on page 164
• How to Configure Line Card Redundancy, on page 164
• Verifying the Line Card Redundancy Configuration, on page 166
• Feature Information for Line Card Redundancy, on page 170
161
Digital PICs:

Module:

Modules:
line card reload.
162
Prerequisites for Line Card Redundancy
Prerequisites for Line Card Redundancy

• At least one RF Through PIC and its corresponding interface line card must be installed in the chassis
to be configured as the primary card.
• An RF Protect PIC and its corresponding interface line card must be installed in the chassis to be
configured as the secondary card.
Restrictions for Line Card Redundancy

• For Supervisor 160G, the line cards installed in slot 3 and 6 of the Cisco cBR-8 router cannot be configured
as the secondary card. The limitation does not apply for Supervisor 250G.
• The RF Protect PIC can send RF signals only to the lower slots (with larger slot number). So, the slot
number of the secondary card must be the smallest in the redundancy group.
Note We recommend that you install the RF Protect PIC in the uppermost slot (slot 0)
of the chassis and configure it as the secondary card.
• The RF Through PIC can send RF signal only from upper slot to lower slot. So, do not install any RF
blank PICs between the secondary card and primary cards.
• You cannot change any configuration on the primary or secondary card when the secondary card is active.
• You cannot remove the last primary card if there is a secondary card in the redundancy group. You must
remove the secondary card and then remove the primary card.
• If the primary card is in the standby role, you must revert to the primary card before removing it from
the redundancy group.
• For CBR-CCAP-LC-40G high availability domain, ensure that all CBR-CCAP-LC-40G Line Cards are
in continuous slots and using the lowest slot number as secondary Line Card. The limitation does not
apply for CBR-CCAP-LC-40G-R or CBR-CCAP-LC-G2-R Line Cards.
• CBR-CCAP-LC-G2-R provides protection only to CBR-CCAP-LC-G2-R.
Note • From Cisco IOS XE Bengaluru 17.6.1, CBR-CCAP-LC-G2-R and

CBR-CCAP-LC-40G-R line cards must not be part of the same redundancy
group.
• In Cisco IOS XE Amsterdam 17.3.1 and earlier releases,
CBR-CCAP-LC-G2-R provides protection to CBR-CCAP-LC-G2-R or
CBR-CCAP-LC-40G-R.
• Protection for CBR-CCAP-LC-G2-R by CBR-CCAP-LC-40G-R is not
supported.
163
Information About Line Card Redundancy
Information About Line Card Redundancy

Line card redundancy reduces the unplanned downtime. When you configure line card redundancy, a protect
zone (redundancy group) is created on the router and the configurations on the primary cards are synchronized
with the secondary card.
The following events can trigger a switchover from an active card to a standby card:
• Manual switchover using the redundancy linecard-group switchover from slot slotcommand.
• Line card reload using the hw-module slot reload command.
• Line card crash.
• Line card Online Insertion and Removal (OIR).
The secondary card reloads after the switchover. The router can be configured to automatically revert to the
primary card when it becomes hot standby after an unplanned switchover triggered by the line card OIR or
crash.
Following are the line card redundancy states:
• Unavail—The line card state is not available.
• Init—The line card did not boot up.
• Active Cold—The active card is downloading the configuration.
• Active—The active card is fully configured and working.
• Stdby Cold—The standby card configuration is synchronizing with the active card.
• Stdby Warm—(Only for the secondary card) The standby card is fully synchronized and ready for
switchover. It is the stable state of a secondary standby card.
• Stdby Hot—The primary standby card is fully synchronized. It is the stable state of a primary standby
card. The secondary standby card is chosen to switchover for a primary card, and will be active soon. It
is a transient state when secondary card is becoming active.
N+1 Line Card Redundancy

The Cisco cBR-8 router supports N+1 redundancy scheme for line cards. A single RF Protect PIC can be
configured as a secondary card for multiple RF Through PICs (primary cards). In this redundancy scheme,
when the secondary card becomes the active card for a primary card, the redundancy scheme is changed to
1+1 redundancy.
The Cisco cBR-8 router supports a single protect zone or redundancy group (group 0).
How to Configure Line Card Redundancy

164
Configuring Line Card Manual Switchover
Configuring Line Card Manual Switchover

Before you begin
The line card must be in active role, and warm standby or hot standby state. Use the show redundancy
linecard all command to verify the role and state of the card.
Restrictions
• You cannot perform a manual switchover when the standby Supervisor is booting up and not yet entered
into SSO.
• You cannot auto revert the switchover triggered manually.
Procedure

Router> enable
Step 2 redundancy linecard-group switchover from slot slot Manually switches over from the active line card.
Example:
Router# redundancy linecard-group switchover from
slot 9
Configuring N+1 Line Card Redundancy

Procedure

Router> enable

Example:
Step 3 redundancy Enables redundancy and enters redundancy configuration

mode.
Example:
Router(config)# redundancy
Step 4 linecard-group group-id internal-switch Configures the redundancy group and enters the line card
redundancy configuration mode.
Example:
165
Verifying the Line Card Redundancy Configuration

Router(config-red)# linecard-group 0
internal-switch
Step 5 description group-description (Optional) Configures the redundancy group description.

Example:
Router(config-red-lc)# description
RedundancyGroup0
Step 6 class 1:N Configures the N+1 redundancy class for the redundancy
group.
Example:
Router(config-red-lc)# class 1:N
Step 7 revertive seconds (Optional) Configures the auto revert time for the primary
card, in seconds.
Example:
Router(config-red-lc)# revertive 60
Step 8 member slot slot primary Adds the line card as a primary card in the redundancy
group.
Example:
Router(config-red-lc)# member slot 1 primary Note Repeat this step for each primary card to be
added in the redundancy group.
Step 9 member slot slot secondary Adds the line card as a primary card in the redundancy
group.
Example:
Router(config-red-lc)# member slot 0 secondary
Step 10 end Returns to privileged EXEC mode.

Example:
Router(config-red-lc)# end

• show redundancy linecard group all—Displays the redundancy group information.
Router# show redundancy linecard group all
Group Identifier: 0
Revertive, Revert Timer: OFF (60000 sec)
Reserved Cardtype: 0xFFFFFFFF 4294967295
Group Redundancy Type: INTERNAL SWITCH
Group Redundancy Class: 1:N
Group Redundancy Configuration Type: LINECARD GROUP
Primary: Slot 6
Primary: Slot 7
Secondary: Slot 0
• show redundancy linecard all—Displays the role and state information for all line cards.
166
Following is a sample output of this command:

Router# show redundancy linecard all
LC My Peer Peer Peer

Slot Subslot Group State State Slot Subslot Role Mode
-------------------------------------------------------------------------------
9 - 0 Active Stdby Cold 0 - Active Primary
8 - 0 Active Stdby Warm 0 - Active Primary
7 - 0 Active Stdby Warm 0 - Active Primary
0 - 0 - - Multiple None Standby Secondary
Note The secondary card does not have a valid My State when it is in Standby role as
it is the peer for N primary cards. The secondary card has N peer states. For
example, it can be cold standby for some primary cards and warm standby for
the other primary card.
Following is a sample output of the command when secondary card becomes active for a primary card,
and the N+1 redundancy is changed to 1+1 redundancy:
Router# show redundancy linecard all
LC My Peer Peer Peer

Slot Subslot Group State State Slot Subslot Role Mode
-------------------------------------------------------------------------------
9 - 0 Stdby Hot Active 0 - Standby Primary
8 - 0 Active Unavail 0 - Active Primary
0 - 0 Active Stdby Hot 9 - Active Secondary
• show redundancy linecard slot—Displays the redundancy information for the line card.
Following is a sample output of the command:
Router# show redundancy linecard slot 9
LC Redundancy Is Configured:
LC Group Number: 0
LC Slot: 9 (idx=9)
LC Peer Slot: 0
LC Card Type: 0x4076 , 16502
LC Name: 9
LC Mode: Primary
LC Role: Active
LC My State: Active
LC Peer State: Stdby Warm
• show redundancy linecard history—Displays the state change history for all line cards.
167
Router# show redundancy linecard history
Jan 05 2012 12:24:27 20559 - st_mem(9): MY State Change, (Active Wait) -> (Active)
Jan 05 2012 12:24:27 20559 - st_mem(9): MY FSM execution, Active Wait:Init:State Ntfy
Jan 05 2012 12:24:27 20559 - st_mem(9): MY State Change, (Active LC Cfg Dnld) -> (Active
Wait)
Jan 05 2012 12:24:27 20559 - st_mem(9): MY FSM execution, Active LC Cfg Dnld:Init:Cfg
Dnld Done
Jan 05 2012 12:24:27 20559 - st_mem(9): MY State Change, (Active Cold) -> (Active LC
Cfg Dnld)
Jan 05 2012 12:23:09 12763 - st_mem(9): MY FSM execution, Active Cold:Init:Cfg Dnld
Jan 05 2012 12:23:09 12760 - st_mem(9): MY State Change, (Init) -> (Active Cold)
Jan 05 2012 12:23:09 12760 - st_mem(9): MY FSM execution, Init:Init:Up
Jan 05 2012 12:21:39 3746 - st_mem(9): PEER FSM Execution , Init:Init:Reset
• show lcha rfsw—Displays the internal RF switch PIC state information.

Router# show lcha rfsw
Slot 0 ====================================
Type : Secondary PIC State: normal
Slot 1 ====================================
Type : Primary PIC State: normal
• show lcha logging level—Displays the cable modem line card logs.
Router# show lcha logging level noise
11:02:03.313 CST Tue Nov 18 2014 [error] [slot=3] [txn=229] Peer-Up Message [tag=1011]
to slot 3 complete [36144 ms]; status=nak response
11:02:03.313 CST Tue Nov 18 2014 [error] [slot=0] [txn=229] Slot 0 downloaded
configuration for slot 3; result=peer-up notification failed
11:02:03.316 CST Tue Nov 18 2014 [noise] [slot=0] [txn=none]
lcha_plfm_get_max_port_count_for_slot: slot 0 maximum port count is 1794
11:02:03.316 CST Tue Nov 18 2014 [noise] [slot=0] [txn=none]
lcha_plfm_get_starting_port_index: slot 0 starting port count is 0
11:02:03.331 CST Tue Nov 18 2014 [note] [slot=0] [txn=none] Slot 0 is being reset
11:02:04.352 CST Tue Nov 18 2014 [note] [slot=0] [txn=none] slot 0 removed
• When the secondary card is active, you can use the slot number of either the primary or secondary card
in the show commands.
Following is a sample output of the show interfaces command after the primary card in slot 8 switches
over to secondary card in slot 0:
Router# show interfaces c0/0/0
Cable0/0/0 is up, line protocol is up

Hardware is CMTS MD interface, address is 0000.0000.031e (bia 0000.0000.031e)
Encapsulation MCNS, loopback not set
Keepalive set (10 sec)
ARP type: ARPA, ARP Timeout 04:00:00
Last input never, output never, output hang never
Last clearing of "show interface" counters never
Input queue: 0/375/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: weighted fair
168
Output queue: 0/1000/64/0 (size/max total/threshold/drops)

Conversations 0/0/256 (active/max active/max total)
Reserved Conversations 0/0 (allocated/max allocated)
Available Bandwidth 19500 kilobits/sec
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 13000 bits/sec, 17 packets/sec
Received 0 broadcasts (0 multicasts)
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
Router# show interfaces c8/0/0
Cable0/0/0 is up, line protocol is up

Hardware is CMTS MD interface, address is 0000.0000.031e (bia 0000.0000.031e)
• When the secondary card is active, the show running-config command displays the output for the
secondary card.
Note The output of the show running-config command is empty for the primary card
when the secondary card is active.
Following is a sample output of the show running-config command after the primary card in slot 8
switches over to secondary card in slot 0:
Router# show running-config | begin controller Upstream-Cable 0
controller Upstream-Cable 0/0/0

us-channel 0 channel-width 1600000 1600000
us-channel 0 docsis-mode atdma
us-channel 0 minislot-size 4
us-channel 0 modulation-profile 221
169
no us-channel 0 shutdown
Router# show running-config | begin controller Upstream-Cable 8

Router#
Router#
Related Documents

CMTS Cisco CMTS Cable Command Reference
commands
Description Link
ID and password.
Feature Information for Line Card Redundancy

170
Table 22: Feature Information for Line Card Redundancy
Line Card Redundancy Cisco IOS XE Fuji This feature was integrated on theCisco cBR Series
171
172
PA R T III
Layer 2 and DOCSIS 3.0 Configuration
• Downstream Interface Configuration, on page 175
• Upstream Interface Configuration, on page 189
• DOCSIS Interface and Fiber Node Configuration, on page 197
• Service Group Based Configuration of the Cisco cBR Router, on page 217
• DOCSIS Load Balancing Groups, on page 227
• DOCSIS Load Balancing Movements, on page 257
• DOCSIS 3.0 Downstream Bonding, on page 295
• DOCSIS 2.0 A-TDMA Modulation Profiles , on page 317
• Downstream Resiliency Bonding Group , on page 335
• Downstream Channel ID Assignment, on page 351
• Upstream Channel Bonding, on page 361
• Dynamic Bonding Group, on page 393
• Spectrum Management and Advanced Spectrum Management, on page 407
• Upstream Scheduler Mode , on page 459
• Generic Routing Encapsulation, on page 465
• Transparent LAN Service over Cable , on page 489
• Downgrading Channel Bonding in Battery Backup Mode, on page 501
• Upstream Bonding Support for D-PON, on page 511
• Energy Management Mode, on page 519
• Cable Modem Steering, on page 531
• DOCSIS Predictive Scheduler, on page 541
CHAPTER 12
Downstream Interface Configuration
This document describes how to configure the downstream interfaces on the Cisco cBR Series Converged
Broadband Router.
• Information About Downstream Interface Configuration , on page 177
• How to Configure Downstream Interfaces, on page 179
• Feature Information for Downstream Interface Configuration on the Cisco cBR Router, on page 187

175
Digital PICs:

Module:

Modules:
line card reload.
176
Information About Downstream Interface Configuration

Overview
• Each downstream port requires port level configuration and channel level configuration. Port level
configuration is optimized with a frequency profile that defines ranges of frequencies available on the
port. Channel level configuration is optimized with a QAM profile and channel range configuration block
that auto-increments frequency and duplicates annex, modulation, and interleaver.
• Each channel requires a set of parameters: frequency, annex, modulation, interleaver, and DOCSIS
channel id.
• Configuration is done in 4 major blocks of configuration:
• QAM Profile—Example: “cable downstream qam-profile 1”
• Frequency Profile—Example: “cable downstream freq-profile 2”
• Port/Controller—Example: “controller Integrated-Cable 3/0/0”
• RF Channel block—Example: “rf-chan 0 31”
Downstream RF Port and Channel Management

The downstream RF port and channel management feature is responsible for the configuration and management
of the downstream RF ports and channels. Each downstream RF channel can be provisioned either as a DOCSIS
or traditional MPEG video QAM channel.
QAM Profile
A QAM profile describes the common downstream channel modulator settings, referred to as physical layer
parameters. This includes QAM constellation, symbol rate, interleaver-depth, spectrum-inversion, and annex.
The QAM profile is described by CCAP DownPhyParams object. Default QAM profiles are supported and
customized for DOCSIS or MPEG Video, which are described as DocsisPhyDefault and VideoPhyDefault
objects, respectively.
A maximum of 32 QAM profiles can be defined. There are six system-defined QAM profiles (0 to 5), which
cannot be deleted or modified. You can define profiles 6 to 31.
The system defined profiles are:
• Profile 0 - default-annex-b-64-qam
• interleaver-depth: I32-J4
• symbol rate: 5057 kilo-symbol/second
• spectrum-inversion: off
177
• Profile 2 - default-annex-a-64-qam
• Profile 3 - default-annex-a-256-qam
Spectrum Inversion
Spectrum inversion happens as a result of mixing processes in RF or IF electronics. Spectrum inversion allows
for the adaptation of older equipment with the new plant. The mixing of I and Q are used to create a quadrant
profile. For some settops, the inversion of the quadrant profile is needed where the axis are flipped such that
I represents the X and Q represents the Y-axis. Most modern equipment can detect and resolve the inversion
split.
You can change this spectrum inversion configuration on a user-defined qam-profile. It cannot be changed
on a system generated qam-profile from 0 to 5.
Frequency Profile
A frequency profile defines the ranges of frequencies available on a port. A maximum of 16 frequency profiles
can be defined. There are four system-defined frequency profiles (0 to 3), which cannot be deleted or modified.
You can define profiles 4 to 15.
The system defined profiles are:
• Profile 0 - annex-b-low, Frequency range (Hz): 90000000 - 863999999
• Profile 1 - annex-b-high, Frequency range (Hz): 234000000 - 1002999999
• Profile 2 - annex-a-low, Frequency range (Hz): 94000000 - 867999999
178
How to Configure Downstream Interfaces
• Profile 3 - annex-a-high, Frequency range (Hz): 267000000 - 1002999999
The frequency ranges are defined using lanes and blocks:

• Four lanes per port, each lane can support 216 MHz range.
• Four blocks per lane, each block can support 54 MHz range.
• Lanes and blocks may have overlapping frequency ranges.
How to Configure Downstream Interfaces

Configuring the Cisco CMTS Manually Using Configuration Mode

Connect a console terminal to the console port on the I/O controller. When asked if you want to enter the
initial dialog, answer no to go into the normal operating mode of the router. After a few seconds the user
EXEC prompt (Router>) appears.
Configuring the QAM Profile on the Downstream Channels

Procedure

Router> enable

Example:
Step 3 cable downstream qam-profile Qam_Profile_ID Defines or modifies a QAM profile.

Example:
Router(config)# cable downstream qam-profile 3
Step 4 annex {A | B | C} Defines the profile MPEG framing format. The default is
Annex B.
Example:
Router(config-qam-prof)# annex A
Step 5 description LINE Name or description for this profile.

Example:
Router(config-qam-prof)# description qam1
179
Configuring the Frequency Profile on the Downstream Channels

Step 6 interleaver-depth {I12-J17 | I128-J1 | I128-J2 | I128-J3 Defines the interleaver depth. The default is I32 J4 for
| I128-J4 | I128-J5 | I128-J6 | I128-J7 | I128-J8 | I16-J8 DOCSIS.
| I32-J4 | I64-J2 | I8-J16}
Example:
Router(config-qam-prof)# interleaver-depth I64-J2
Step 7 modulation {256 | 64} Defines the modulation. The default is 256QAM.
Example:
Router(config-qam-prof)# modulation 64
Step 8 spectrum-inversion {off | on} Enables or disables spectrum inversion. Default is off.
Example:
Router(config-qam-prof)# spectrum-inversion on
Step 9 symbol-rate value Defines the symbol rate. Value is in kilo-symbol/sec.

Example:
Router(config-qam-prof)# symbol-rate 5057
Step 10 exit Exits from the QAM profile configuration mode.

Example:
Router(config-qam-prof)# exit
Configuring the Frequency Profile on the Downstream Channels

Procedure

Router> enable

Example:
Step 3 cable downstream freq-profile DS_frequency_profile_ID Defines or modifies a frequency profile.

Example:
Router(config)# cable downstream freq-profile 4
Step 4 exit Exits from the frequency lane configuration mode.

Example:
180
Configuring the Controller on the Downstream Channels
Configuring the Controller on the Downstream Channels

Procedure

Router> enable

Example:
Step 3 controller integrated-cable slot/subslot/port Enters the controller sub-mode.

Example:
Router(config)#controller Integrated-Cable 3/0/0
Step 4 base-channel-power value Sets the base channel power level. If not specified, the
default value is calculated based on the number of carriers.
Example:
Maximum limit is 34 dBmV DRFI. If you configure a value
Router(config-controller)#base-channel-power 26 greater than the maximum specified by DRFI, the following
message is displayed:
Caution: RF Power above DRFI specification. May result
in minor fidelity degradation.
Step 5 freq-profile number Specifies the frequency profile for the port.
Example:
Router(config-controller)#freq-profile 0
Step 6 max-carrier value Specifies the maximum number of carriers.

Example:
Router(config-controller)#max-carrier 1
Step 7 mute Mutes the port. Use the no prefix to unmute the port. Default
is "no mute".
Example:
Router(config-controller)#mute
Step 8 rf-chan starting_Qam_ID ending_Qam_ID Enters RF channel configuration sub-mode to configure an

individual channel or a block of channels.
Example:
Router(config-controller)#rf-chan 0 1
Step 9 shutdown Changes the port administration state to down. Use the no
prefix to change the port administration state to up.
Example:
Router(config-controller)#shutdown
181
Troubleshooting Tips
Shutting and No Shutting Downstream Controller Immediately

Problem Shutting down a downstream controller on a cable line card and bringing the controller back up
immediately can cause a Queue ID Pending Drain event on the system. This results in traffic disruption to
the modems or modems going offline.
Solution It is recommended that you wait for a few seconds (>30 secs) before issuing the no shut command
on a shut downstream controller. The system also restricts the user from issuing the no shut command
immediately by printing this message.
Config change could not be applied as a cleanup is pending following shut on

controller x/x/x. Please wait for the cleanup to complete before attempting to
no shut controller.
Configuring the RF Channel on a Controller

The RF channel submode is entered from the channel controller configuration submode using the rf-chan
command as described in the previous section. If an individual channel was specified in the rf-chan command,
only that channel configuration is changed. If a block of channels was specified in the rf-chan command, the
configuration change is applied to all channels in the block.
Note If the user tries to add a video type RF channel to a cable interface, the following message appears to reject
the configuration:
X/X/X rf-channel XX is video type channel, it can't be configured as primary DS
If a RF channel is configured under cable interface, when the user tries to change the channel type to video,
the following message appears to reject the configuration:
X/X/X rf channel X can't be set to video type.
It is configured under Cable1/0/1.
Please remove the configuration before change the qam type
Step 1 docsis-channel-id dcid

Example:
Router(config-rf-chan)#docsis-channel-id 1
Changes the channel DOCSIS channel identifier. In block mode, the value is assigned to the first channel and incremented
for successive channels.
Step 2 frequency value

Example:
Router(config-rf-chan)#frequency 93000000
Configures the channel's center frequency in Hz. The available frequency range is determined from the port's frequency
profile, if configured. If not configured, the available range will be the full port spectrum. In block mode, the frequency
will be assigned to the first channel. Successive channels will get the next center frequency for the annex specified in the
QAM profile (+6 Hz for Annex B, +8 Hz for Annex A).
182
Step 3 mute
Example:
Router(config-rf-chan)#mute
Mutes the RF channel. Enter the no prefix to unmute the channel. Default is "no mute".
Step 4 power-adjust pwr_adj_range

Example:
Router(config-rf-chan)#power-adjust 8.0 - 0.0 dBmV
Adjusts the RF channel's power.
Step 5 qam-profile qam_profile_number

Example:
Router(config-rf-chan)#qam-profile 0
Specifies the QAM profile for this channel.
Step 6 rf-output value

Example:
Router(config-rf-chan)#rf-output normal
Changes the RF output mode to test the channel.
Step 7 shutdown
Example:
Router(config-rf-chan)#shutdown
Changes the channel administration state to down. Use the no prefix to change the channel administration state to up.
The default is "no shut".
Step 8 type value

Example:
Router(config-rf-chan)#type video
Configures the channel QAM type. The default is DOCSIS.
Downstream Interface Configuration Example
The example below shows the configuration of:
• QAM Profile—The system defined QAM profile for Annex B and 256 QAM.
• Frequency Profile—The system defined frequency profile annex-b-low.
• Controller and RF channel—Port 0 on slot 3/0 with frequency profile 0; 96 channels with QAM profile
1 and center frequencies starting at 93 MHz.
183
cable downstream qam-profile 1

annex B
modulation 256
interleaver-depth I32-J4
symbol-rate 5361
spectrum-inversion off
description default-annex-b-256-qam
cable downstream freq-profile 0
lane 1 start-freq 90000000
block 1 start-freq 90000000
controller Integrated-Cable 3/0/0
max-carrier 128
base-channel-power 34
freq-profile 0
rf-chan 0 95
type DOCSIS
frequency 93000000
rf-output NORMAL
power-adjust 0
docsis-channel-id 1
qam-profile 1
Show Command Examples for Displaying the State

Use the following commands to display the state of any QAM profile, Frequency profile, downstream controller
or channel.
QAM Profile Configuration Example

Router#show cable qam-profile 0
QAM Profile ID 0: default-annex-b-64-qam
annex: B
modulation: 64
interleaver-depth: I32-J4
symbol rate: 5057 kilo-symbol/second
spectrum-inversion: off
Router#
184
Frequency Profile Configuration Example

Router#show cable freq-profile 0
Frequency Profile ID 0 annex-b-low:
Lane 1 start-freq 90000000hz
Block 1 start-freq 90000000hz
Router#
Controller Configuration Example

Router#show controller Integrated-Cable 3/0/0 rf-port
Admin: UP MaxCarrier: 128 BasePower: 34 dBmV Mode: normal
Rf Module 0: UP
Frequency profile: 0
Free freq block list has 1 blocks:
666000000 - 863999999
Rf Port Status: UP
Router#
RF Channel Configuration Example
Router#show controller integrated-Cable 3/0/0 rf-channel 0-3 95

Chan State Admin Frequency Type Annex Mod srate Interleaver dcid power output
0 UP UP 93000000 DOCSIS B 256 5361 I32-J4 1 34 NORMAL
Router# show controller integrated-Cable 3/0/0 rf-channel 0 verbose

Qam profile: 1
Spectrum Inversion: Off
Frequency Lane: 1 Block: 1 index: 1
Resource status: OK
License: granted <02:00:04 EDT Jan 2 2012>
JIB channel number: 0
Chan EnqQ Pipe RAF SyncTmr Vid Mac Video Primary DqQ TM Mpts Sniff
0 0 0 4 0 0 0000.0000.0000 0 0 0 0 0 NO
Grp Prio P Prate Phy0-ctl Phy1-ctl Enable Tun-Id L2TPv3_Ses_id
0 0 0 1 1 0 TRUE 0 0
Chan Qos-Hi Qos-Lo Med-Hi Med-Lo Low-Hi Low-Lo
0 32774 16384 32768 16384 65536 32768
185
Chan Med Low TB-neg Qos_Exc Med_Xof Low_Xof Qdrops Pos Qlen(Hi-Med-lo) Fl
0 0 0 0 0 0 0 0 Y 0 0 0 0
DSPHY Info:
DSPHY Register Local Copy: QPRHI = c0000163, QPRLO = e30d0
DSPHY Register Local Copy Vaddr = 80000290, qam2max_mapping = 80000000
DSPHY Register Local Copy: SPR ID = 0, SPR Mapping= c200000a
Last read from HW: Mon Jan 2 02:02:04 2012
QPRHI = c0000163, QPRLO = e30d0, SPR = c200000a SPRMAPING c0000000 Q2Max 80000000
Last time read spr rate info from HW: Mon Jan 2 13:21:41 2012
SPR ID 0, rate value in kbps 0, overflow count 0, underflow count 0
Router# sh controllers Integrated-Cable 7/0/0 counter rf-channel
Controller RF MPEG MPEG MPEG Sync MAP/UCD User QAM
Chan Packets bps Mbps Packets Packets Mbps Util
Tx Tx Tx Percentage
7/0/0 0 0 0 00.00 0 0 00.00 000.00
7/0/0 1 0 0 00.00 0 0 00.00 000.00
7/0/0 2 8239954 2475952 02.47 0 0 02.39 006.60
7/0/0 3 85927382 25769779 25.76 0 0 24.94 068.71
7/0/0 4 85927608 25769027 25.76 0 0 24.94 068.71
7/0/0 5 8239088 2474599 02.47 0 0 02.39 006.59
7/0/0 6 8210840 2463770 02.46 0 0 02.38 006.57
7/0/0 7 50103 15040 00.01 0 0 00.01 000.04
7/0/0 8 50103 15040 00.01 0 0 00.01 000.04
Router# show cable licenses ds
--------------------------------------------
Entitlement: Downstream License
Consumed count: 672
Forced-Shut count: 0
Router#
Description Link
ID and password.
186
Feature Information for Downstream Interface Configuration on the Cisco cBR Router
Feature Information for Downstream Interface Configuration on

the Cisco cBR Router
Table 24: Feature Information for Downstream Interface Configuration
Downstream Interface Cisco IOS XE Fuji 16.7.1 This feature was integrated on the
Configuration Cisco cBR Series Converged
Broadband Routers.
Display QAM Utillization Cisco IOS XE Gibraltar 16.10.1f This feature was integrated on the
Percentage using the sh controllers Cisco cBR Series Converged
Integrated-Cable 7/0/0 counter Broadband Routers.
rf-channel
187
Feature Information for Downstream Interface Configuration on the Cisco cBR Router
188
CHAPTER 13
Upstream Interface Configuration
This document describes how to configure the upstream interfaces on the Cisco cBR Series Converged
Broadband Router.
• Information About Upstream Interface Configuration, on page 191
• How to Configure Upstream Interfaces, on page 191
• Feature Information for Upstream Interface Configuration on the Cisco cBR Router, on page 196

189
Digital PICs:

Module:

Modules:
line card reload.
190
Information About Upstream Interface Configuration
Information About Upstream Interface Configuration

The cable interface in the Cisco cBR router supports upstream signals and serves as the radio frequency (RF)
interface. This chapter provides an overview of the upstream interfaces on the Cisco cBR Series Converged
Broadband Router.
Cisco IOS XE Fuji 16.9.1 and later releases support 10 Gbps of upstream throughput on the following line
cards on the Cisco cBR Series Converged Broadband Router:
• CBR-CCAP-LC-40G
• CBR-CCAP-LC-40G-R
Upstream Channel Management

Upstream Channel Management (UCM) is responsible for the physical (PHY) layer configuration and resource
management of upstream channels in the Cisco cBR Series Converged Broadband Router.
Upstream Controller
An upstream port represents a physical upstream RF connector on a cable line card, connected to one or more
fiber nodes. An upstream RF port is a container of upstream RF channels, which imposes constraints on both
topology and spectrum for the group of RF channels contained in the physical port. An upstream RF port also
represents the RF front-end hardware component on a cable line card including the connector, variable gain
adjustment (VGA), and A/D converter. This is directly connected to a set of upstream physical channel
receivers. The number of upstream physical channels per port is thus constrained by the number of receivers
accessible to the port.
Upstream Channel
An upstream RF channel represents DOCSIS physical layer operation on a single upstream center frequency
with a particular channel width. It is contained by a single physical port on the CMTS line card hardware.
Upstream Resource Management

The upstream resource management (URM) feature is primarily responsible for the maintenance of the
relationship between a physical upstream connector on the line card and the upstream RF channels received
on that connector.
How to Configure Upstream Interfaces

Configuring the Cisco CMTS Manually Using Configuration Mode

Connect a console terminal to the console port on the I/O controller. When asked if you want to enter the
initial dialog, answer no to go into the normal operating mode of the router. After a few seconds the user
EXEC prompt (Router>) appears.
191
Configuring the Modulation Profile and Assigning to an Upstream Channel
Configuring the Modulation Profile and Assigning to an Upstream Channel

Procedure

Router> enable

Example:
Step 3 cable modulation-profile profile mode_of_oper Creates a preconfigured modulation profile, where the burst
qam_profile parameters are set to their default values for each burst type.
Example:
Router(config)# cable modulation-profile 23 tdma
qam-16
Step 4 Controller Upstream-Cable slot/subslot/port Enters the controller interface configuration mode.
Example:
Router(config)# Controller Upstream-Cable 7/0/0
Step 5 us-channel n modulation-profile primary-profile-number Assigns up to three modulation profiles to an upstream port.
[secondary-profile-number] [tertiary-profile-number]
Example:
Router(config-if)#cable upstreamus-channel 0
modulation-profile 23
Step 6 end Exits controller configuration submode and returns to

privileged EXEC mode.
Example:
Router(config-controller)# end
Configuring the Upstream Channel with PHY Layer

Procedure

Router> enable

Example:
192
Associating Upstream Channels with a MAC Domain and Configuring Upstream Bonding

Step 3 controller upstream-cable slot/subslot/port Specifies the controller interface line card and enters
upstream controller config configuration submode.
Example:
Router(config)# controller upstream-cable 1/0/0
Step 4 us-channel rf-channel frequency freq-val Assigns frequency to an RF channel on a controller

interface.
Example:
Router(config-controller)# us-channel 1 frequency
20000000
Step 5 us-channel rf-channel docsis-mode mode Assigns DOCSIS mode to an RF channel on a controller
interface.
Example:
Router(config-controller)# us-channel 1 docsis-mode
tdma
Step 6 us-channel rf-channel channel-width value Assigns channel width in Hertz to an RF channel on a
controller interface.
Example:
Router(config-controller)# us-channel 1
channel-width 3200000
Step 7 us-channel rf-channel modulation-profile profile Assigns modulation profile to an RF channel on a controller
interface.
Example:
modulation-profile 21
Step 8 no us-channel rf-channel shutdown Enables the upstream channel.

Example:
Router(config-controller)# no us-channel 1 shutdown
Step 9 end Exits upstream controller configuration submode and returns

to privileged EXEC mode.
Example:
AssociatingUpstreamChannelswithaMACDomainandConfiguringUpstream
Bonding
Procedure

Router> enable
193
Associating Upstream Channels with a MAC Domain and Configuring Upstream Bonding

Example:
Step 3 interface cable slot/subslot/cable-interface-index Specifies the cable interface line card on a Cisco CMTS
router.
Example:
Router(config)# interface cable 7/0/0
Step 4 downstream integrated-cable slot/subslot/port rf-channel Associates a set of upstream channels to the integrated
rf-chan [upstream grouplist] downstream channels.
Example:
Router(config-if)# downstream integrated-cable
7/0/0 rf-channel 3 upstream 3
Step 5 upstream md-us-chan-id upstream-cable slot/subslot/port Associates a set of physical upstream channels with the
us-channel rf-channel Mac Domain.
Example:
Router(config-if)# upstream 0 upstream-cable 7/0/0
us-channel 0
Step 6 cable upstream bonding-group id Creates the upstream bonding group on the specified cable
interface and enters upstream bonding configuration
Example:
submode.
Router(config-if)# cable upstream bonding-group
200
Step 7 upstream number Adds an upstream channel to the upstream bonding group.
Example: A maximum of 16 upstream channels can be configured for
Router(config-upstream-bonding)# upstream 1 each MAC Domain, which are divided into two groups:
• Group 1: upstream channel 0-7
The upstream bonding-group should include all the
upstream channels either from Group 1 or Group 2 only.
Step 8 attributes value Modifies the attribute value for the specified upstream
bonding group.
Example:
Router(config-upstream-bonding)# attributes
eeeeeeee
Step 9 end Exits upstream bonding configuration submode and returns

Example:
Router(config-upstream-bonding)# end
194
Configuring Upstream Channel Priority
Configuring Upstream Channel Priority

Feature History
Table 26: Feature History
Feature Name Release Information Feature Description
Upstream Channel Cisco IOS XE Bengaluru This feature allows the cable modem to do the
Priority 17.6.1w initial ranging on the upstream channel with the
highest priority.
Starting from Cisco IOS XE Bengaluru 17.6.1w release, you can use the cable upstream priority command
to configure the upstream channel with different priorities.
Router(config-if)# cable upstream 0 priority 1
You can also run this command for mac-domain profile.

Router(config-profile-md)# cable upstream 0 priority 2
Use show cable mac-domain mdd | in MD-US command to check the upstream channel priority.
Router#show cable mac-domain c3/0/1 mdd | in MD-US
MD-US Chan ID/CM-STATUS: 1/0x0000
MD-US Chan Priority: 3
MD-US Chan DCID Binding: 9 10 11 12 13 14 15 16
Upstream Channel with PHY Layer Configuration Example
...
us-channel 0 frequency 20000000
us-channel 0 power-level 0
us-channel 0 docsis-mode tdma
...
Upstream Channels with a MAC Domain Configuration Example
...
interface Cable8/0/0
downstream Modular-Cable 8/0/0 rf-channel 0
upstream 0 Upstream-Cable 8/0/0 us-channel 0
195
cable mtc-mode
cable upstream bonding-group 1
upstream 0
upstream 1
attributes 80000000
...
Description Link
ID and password.
Feature Information for Upstream Interface Configuration on

the Cisco cBR Router
Table 27: Feature Information for Upstream Interface Configuration
Upstream Interface Configuration Cisco IOS XE Fuji 16.7.1 This feature was integrated on
theCisco cBR Series Converged
Broadband Routers.
196
CHAPTER 14
DOCSIS Interface and Fiber Node Configuration
• Overview of DOCSIS Interfaces and Fiber Node Configurations, on page 199
• Configuring DOCSIS Interfaces and Fiber Nodes, on page 200
• Configuring MAC Domain Service Groups, on page 206
• Downstream Bonding Group Configuration, on page 209
• Upstream Bonding Group Configuration, on page 212
• Feature Information for DOCSIS Interface and Fiber Node Configuration, on page 216
197
Digital PICs:

Module:

Modules:
line card reload.
198
Overview of DOCSIS Interfaces and Fiber Node Configurations
Overview of DOCSIS Interfaces and Fiber Node Configurations

The Interface line card used in the Cisco cBR chassis is an integrated line card that has two downstream
modules and one upstream module. The line cards support DOCSIS 3.0 features including downstream bonding
groups, and upstream bonding groups.
Downstream Features
Physically, the downstream modules support eight physical connectors or ports. The downstream modules
support the following features:
• The downstream modules support eight downstream integrated-cable controllers for these eight ports.
Each downstream integrated-cable controller is associated with an RF port.
• Each downstream controller supports up to 128 downstream channels (0-127).
• Each downstream controller supports up to 128 integrated-cable interfaces. Therefore, each line card has
1024 integrated-cable interfaces.
• Each integrated-cable interface has a static mapping to an integrated-cable controller RF channel. For
example, Integrated-Cable interface 3/0/0:0 is mapped to RF Channel 0 on Integrated-Cable controller
3/0/0.
• The following table lists the number of downstream DOCSIS channels different Cisco cBR-8 line cards
support.
This table lists the number of downstream DOCSIS channels different Cisco cBR-8 line cards support.
Table 29: Support for Downstream DOCSIS Channels
Line Card Downstream DOCSIS Channels
CBR-CCAP-LC-40G Up to 768
CBR-CCAP-LC-40G-R Up to 1024
CBR-CCAP-LC-G2-R Up to 1536
Note In Cisco IOS XE Amsterdam 17.3.x and earlier releases, CBR-CCAP-LC-G2-R

line card supports up to 768 downstream DOCSIS channels.
• A total of 512 wideband-cable interfaces (downstream bonding groups) may be configured on each line
card.
• Each wideband-cable interface supports a maximum of 64 downstream channels.
• 128 of the 512 wideband-cable interfaces (downstream bonding groups) may contain 33 or more
channels.
199
Upstream Features
Upstream Features
The Interface line card has one upstream module supporting 16 physical connectors or ports. The upstream
features are as follows:
• The line card supports 16 upstream-cable controllers, each mapping to one upstream connector.
• 12 upstream channels can be configured per upstream controller.
• 12 upstream channels can be enabled per pair of upstream controllers.
For more details on the upstream features, see the Downstream Upstream Guide.
MAC Domains (Cable Interfaces)

1. 16 MAC domains (cable interfaces) may be configured per line card.
Note CBR-CCAP-LC-G2-R line card supports up to 32 MAC domains per line card.
2. Maximum of 16 upstream channels can be configured in each MAC domain.

3. A maximum of 255 downstream channels may be added to a MAC domain.
4. Maximum number of primary capable downstream channels per MAC Domain is 32. Non Primary
downstream channels are added automatically to the MAC domains when the fiber nodes are configured.
Fiber Nodes
512 fiber nodes may be configured for each Cisco cBR-8 chassis.
Configuring DOCSIS Interfaces and Fiber Nodes

Configuring Upstream Channels
Verifying the Controller Configuration
Use the show controllers upstream-cable command to verify the configuration of the upstream channels in
the controllers. Use the modifier | include upstream to see the administrative and operational state of the
controllers.
Router#show controllers upstream-Cable 1/0/0 | include upstream

Controller 1/0/0 upstream 0 AdminState:UP OpState: UP
Controller 1/0/0 upstream 4 AdminState:DOWN Opstate: DOWN (Reason: Default)
Router#
200
Binding Upstream Channels to MAC Domain
Binding Upstream Channels to MAC Domain

By default, a MAC domain does not contain any upstream channels. This section describes the configurations
necessary to bind one or more upstream channels to a MAC domain. Each upstream channel is bound to only
one MAC domain. The MAC domain and the upstream channel must reside on the same line card (same slot).
If required, the upstream channels within the same upstream controller can be bound to different MAC domains.
Before you begin

Restrictions
• A maximum of 8 upstream channels may be bound to one MAC domain.
Note A maximum of 16 upstream channels may be configured in each MAC domain.
• The MAC domain and channels must share the same slot. That is, a MAC Domain may include channels
from any controller on the same slot.
Procedure

Router> enable

Example:
Step 3 interface cable Enters MAC Domain configuration mode. Values for slot
are 0-3 and 6-9, for subslot is always 0, for MD Index is
Example:
0-15.
Router#interface cable 1/0/0
Step 4 upstream upstream-Cable us-channel Binds the specified upstream channel to the MAC Domain.
Example:
Router(config-if)#upstream 4 upstream-Cable 1/0/0

us-channel 7

Example:
Router# end
201
Configuring Primary Capable Downstream Channels
What to do next
To verify MAC Domain configurations for upstream, use the show cable mac-domain command with
cgd-associations keyword.
The MD US Binding table shows the upstream channel binding.
Router#show cable mac-domain c1/0/0 cgd-associations

Time source is NTP, *13:36:26.209 PST Fri Jan 20 2012
CGD Host Resource DS Channels Upstreams (ALLUS) Active DS
Ca1/0/0 1/0/0 8 0-1 Yes 8
16 0-1 Yes 16
24 0-1 Yes 24
32-33 0-1 Yes 32-33
40 0-1 Yes 40
MD US binding:
Host MD Controller US channel State
Ca1/0/0 U0 1/0/0 0 UP
Ca1/0/0 U1 1/0/0 1 UP
Ca1/0/0 U2 1/0/0 2 UP
Ca1/0/0 U3 1/0/0 3 UP
Ca1/0/0 U4 1/0/1 0 UP
Ca1/0/0 U5 1/0/1 1 UP
Ca1/0/0 U6 1/0/1 2 UP
Ca1/0/0 U7 1/0/1 3 UP
Router#
Configuring Primary Capable Downstream Channels

Verifying Downstream Configuration in Controller
Use the show controller Integrated-Cable command to verify the status of the downstream channels configured
on an Integrated-cable controller.
Router# show controller Integrated-Cable 1/0/0 rf-channel 0-127

Configuring Integrated-cable Interface

Configure an integrated-cable interface to prepare a downstream channel for inclusion within a MAC Domain
as a primary-capable downstream channel. The interface configuration provides the following advantages:
• It enables the allocation of bandwidth to the downstream channel.
• It enables the control of the administrative state (shut/no shut) of the channel interface.
202
Configuring Integrated-cable Interface
The time interval required between the shut and no shut administrative states for the same controller is
approximately 30 seconds. You must not change the shut and no shut states rapidly without any delay in script
or copy-paste. It can generate unexpected errors.
Each integrated-cable interface is mapped statically to an integrated-cable controller RF channel. For example,
IC interface 1/0/0:0 is mapped to IC controller 1/0/0 RF channel 0. Similarly, IC interface 1/0/0:1 is mapped
to IC controller 1/0/0 RF channel 1.
IC controllers are numbered 0-7 and RF Channels on each controller are numbered 0-127.
Before you begin

Determine the percentage of bandwidth to allocate to a channel. The bandwidth percentage configured is
converted to a committed information rate (CIR) value for the interface. The value is used to admit non-bonded
service flows on this channel. For more information, see the Dynamic Bandwidth Sharing on the Cisco CMTS
Router.
Step 1 enable
Example:
Router> enable
Enables privileged EXEC mode.

Enter your password if prompted.
Step 2 configure terminal

Example:
Enters global configuration mode.
Step 3 interface integrated-cable

Example:
Router(config)# interface integrated-cable 1/0/0:0
Enter the integrated-cable interface configuration mode for specified integrated-cable interface.
Step 4 cable rf-bandwidth-percent percentage-number

Example:
Router(config-if)# cable rf-bandwidth-percent 30
Configures the bandwidth allocation to the specified integrated-cable interface.
Step 5 end
Example:
Router# end
203
Binding Primary Capable Downstream Channels to a MAC Domain
What to do next
The following conditions are used to determine if an IC (Integrated-Cable) interface is up in current software.
• The IC interface is associated to a MD (MAC Domain) interface.
• The MD interface, which the IC interface associated to, is in UP state.
• The IC interface is not configured shut down.
• The IC interface is configured with bandwidth.
• The associated downstream channel within the IC controller is operationally up.
Use the show interface Integrated-Cable controller command to verify the status of the specified
integrated-cable interface. The State info table provides information to diagnose issues affecting the operational
state of the interface.
Router# show interface Integrated-Cable 1/0/0:0 controller

Integrated-Cable1/0/0:0 is up, line protocol is up
…
----------------------------------------------
State info (DSNB if and its underlying states)
----------------------------------------------
DSNB IF state : UP
RF Chan state : UP
RF Chan frequency : 381000000
Bandwidth configured on DSNB IF : YES
Inject Header/HW flow creation status : DSNB_IF_SM_UP
MD state (9/0/0) : UP
*DSNB i/f Line State : UP
----------------------------------------------

After a downstream channel has a properly configured Integrated-cable interface, it may be bound to a MAC
Domain as a primary capable channel. The Channel Grouping Domain (CGD) configuration allows specified
downstream channels to be bound to a MAC Domain as primary capable channels. Optionally, it also allows
downstream channels to be associated with a subset of upstream channels within the MAC domain.
Before you begin

Restrictions
• The downstream channel and MAC domain must reside on the same line card (same slot)
• A maximum of 32 primary capable downstream channels may be bound to a single MAC domain.
Step 1 enable
Example:
Router> enable

204

Example:
Step 3 interface cable

Example:
Router#interface cable 1/0/0
Enters MAC domain configuration mode.

• slot—Specifies the chassis slot number of the interface line card. Valid values are 0-3 and 6-9
• subslot—Specifies the secondary slot number of the interface line card. Valid subslot is 0.
• MD index—Specifies the MAC Domain index number. Valid values are 0-15.
Step 4 downstream Integrated-Cable slot/subslot/port rf-channels grouplist

Example:
Router#downstream Integrated-Cable 1/0/0 rf-channels 1-6
Configures the downstream primary capable channels.

• grouplist—Specify the range of downstream rf-channels.
Step 5 end
Example:
Router# end
What to do next
To verify the downstream primary capable channels, use the show cable mac-domain command with
cgd-associations keyword.
Router#show cable mac-domain c1/0/0 cgd-associations

Time source is NTP, *13:36:26.209 PST Fri Jan 20 2012
Ca1/0/0 1/0/0 8 0-1 Yes 8
16 0-1 Yes 16
24 0-1 Yes 24
32-33 0-1 Yes 32-33
40 0-1 Yes 40
205
Configuring MAC Domain Service Groups
MD US binding:
Host MD Controller US channel State
Ca1/0/0 U0 1/0/0 0 UP
Ca1/0/0 U1 1/0/0 1 UP
Ca1/0/0 U2 1/0/0 2 UP
Ca1/0/0 U3 1/0/0 3 UP
Ca1/0/0 U4 1/0/1 0 UP
Ca1/0/0 U5 1/0/1 1 UP
Ca1/0/0 U6 1/0/1 2 UP
Ca1/0/0 U7 1/0/1 3 UP
Router#
Configuring MAC Domain Service Groups

Configuring the Fiber Nodes
A maximum of 512 fiber nodes may be configured per CMTS. A fiber node configured on the CMTS represents
one or more matching physical fiber nodes in the HFC plant. The CMTS uses the fiber node configuration to
identify the DOCSIS downstream service group (DS-SG) and DOCSIS upstream Service Group (US-SG) of
the physical fiber nodes in the plant. The Service Group information is compared with MAC Domain channel
configuration to automatically calculate the MAC Domain downstream and upstream service groups
(MD-DS-SGs and MD-US-SGs respectively) within the MAC Domains.
The following is required to create a valid fiber node configuration.
• Each fiber node configuration must include at least one downstream controller and one upstream controller.
• Every MAC Domain and Wideband Interface including channels within the fiber node must use the same
bundle interface.
• All downstream channels included within the fiber node must be assigned a unique frequency.
• All downstream channels associated with a particular MAC Domain must be assigned a unique DOCSIS
channel ID.
If automatic DOCSIS channel ID allocation is preferred over manual DOCSIS channel ID configuration, the
cable downstream-channel-id automatic command may be used to enable automatic DOCSIS channel ID
allocation for the CMTS.
For details, see the Cisco CMTS Cable Command Reference.
Step 1 enable
Example:
Router> enable


Example:
206
Configuring the Fiber Nodes
Step 3 cable fiber-node id

Example:
Router(config)#cable fiber-node 1
Router(config-fiber-node)#
Enters cable fiber-node configuration mode to configure a fiber node

• id— cable fiber node ID. The valid range is 1-512.
Step 4 downstream Integrated-Cable slot/subslot/port

Example:
Router(config-fiber-node)#downstream Integrated-Cable 1/0/0
Adds the DOCSIS downstream channels within the controller to the fiber node.
Step 5 upstream upstream-Cable slot/subslot/port

Example:
Router(config-fiber-node)#upstream upstream-Cable 1/0/0
Adds the upstream channels within the controller to the fiber node.
Step 6 end
Example:
Router# end
What to do next
To verify the fiber-node configuration use the show cable fiber-node command.
Router# show cable fiber-node 1

-------------------------------------------------------------------------------
--
Fiber-Node 1
Description: Feed Mac Domain: Cable1/0/0
Channel(s) : downstream Integrated-Cable 1/0/0: 0-3, 32-35, 64-67,
96-99
Channel ID(s): 1 2 3 4 33 34 35 36 65 66 67 68 97 98
99 100
Upstream-Cable 1/0/0
FN Config Status: Configured (status flags = 0x01)
MDD Status: Valid
Router#
The output shows the downstream channel IDs configured on a fiber node. It also shows the status of the
upstream-cable configured on the fiber node. Further, it shows the status of MAC Domain Descriptor (MDD)
messaging.
207
Verify MD-DS-SG Channel Membership
Verify MD-DS-SG Channel Membership

Once the fiber node is valid, the MD-DS-SGs within the associated MAC domains will be automatically
populated with downstream channels. The MD-DS-SGs will include the active primary downstream channels
within the MAC domain as well as non-primary downstream channels automatically associated with the MAC
domain through the fiber node configuration. The non-primary channels must be properly configured within
the controller (that are operationally up) to be included in MD-DS-SGs
Use the show cable mac-domain command with the downstream-service-group option to display the
MD-DS-SG channel membership.
outer#show cable mac-domain c1/0/0 downstream-service-group

Cable MD-DS-SG RF
IF Id Resource Chan Primary Chan
C1/0/0 5 1/0/0 0-3 0-3
32-35 32-35
64-67
96-99
To verify that the primary downstream channels are transmitting MAC Management Messages (MMMs) use
the show controller Integrated-Cable counter rf-channel command.
Router#sh controllers Integrated-Cable 7/0/0 counter rf-channel
Controller RF MPEG MPEG MPEG Sync MAP/UCD User QAM
Chan Packets bps Mbps Packets Packets Mbps Util
Tx Tx Tx Percentage
7/0/0 0 0 0 00.00 0 0 00.00 000.00
7/0/0 1 0 0 00.00 0 0 00.00 000.00
7/0/0 2 8239954 2475952 02.47 0 0 02.39 006.60
7/0/0 3 85927382 25769779 25.76 0 0 24.94 068.71
7/0/0 4 85927608 25769027 25.76 0 0 24.94 068.71
7/0/0 5 8239088 2474599 02.47 0 0 02.39 006.59
7/0/0 6 8210840 2463770 02.46 0 0 02.38 006.57
7/0/0 7 50103 15040 00.01 0 0 00.01 000.04
7/0/0 8 50103 15040 00.01 0 0 00.01 000.04
Verify MD-US-SG Channel Membership

Use the show cable mac-domain command with the upstream-service-group option to display the MD-US-SG
channel membership.
Router#show cable mac-domain c1/0/0 upstream-service-group

Cable MD 1/0/0
US-SG-ID : 5 US-Chan : U0,1,2,3
Primary-DS: 1/0/0:0 US-SG-ID: 5
MDD US-List : U0,1,2,3
MDD Ambiguity : U0,1,2,3
208
Downstream Bonding Group Configuration
Downstream Bonding Group Configuration

Configuring Wideband-cable Interface (Downstream Bonding Grouping)
A Wideband-Cable interface forwards bonded traffic in the downstream direction. A set of downstream RF
channels is configured under the Wideband interface. Each line card will support up to 512 Wideband interfaces.
Although there is no real relationship between these wideband interfaces and the 8 controllers (ports), there
is a convention of dividing the wideband interfaces into groups per controller.
The 512 wideband interfaces are divided among the 8 controllers - 64 interfaces per controller.
You can create a wideband-cable interface to define a downstream bonding group. A downstream bonding
group bonds together a set of downstream RF channels. It can only contain the RF channels from the same
line card.
Associations between bonding groups and MAC Domains are automatically created. Associations occur when
a bonding group channel set is found to be a subset of a MAC Domain Downstream Service Group (MD-DS-SG)
within a MAC Domain. The automatic associations will trigger the creation of an RCC that contains the
bonding group's channel set within the MAC Domain.
Before you begin

Restrictions:
1. Included downstream channels must be a part of the same line card slot.
2. All the downstream channels must be from the integrated-cable controllers 0-3 or 4-7.
Step 1 enable
Example:
Router> enable


Example:
Step 3 interface wideband-Cable

Example:
Router(config)#interface wideband-Cable 1/0/0:1

Router(config-if)#
Enter the wideband-cable interface configuration mode for specified wideband-cable interface.
Step 4 cable bundle id
209
Verifying the Bonding Group Interfaces
Example:
Router(config-if)#cable bundle 1
Configures the cable bundle id for this wideband-cable interface. The configured cable bundle id must match the cable
bundle id configured in associated MAC domains.
• Bundle number— cable bundle number. The valid range is 1-255.
Step 5 cable rf-channels channel-list grouplist bandwidth-percent percentage-bandwidth

Example:
Router(config-if)#cable rf-channel channel-list 1-3 bandwidth-percent 10
Configures the bandwidth allocation for specified channel-list and includes the channels in the downstream bonding
group. Range for channel numbers are 0-127 (<first channel num-last channel num>).
Step 6 cable rf-channels controller controller number channel-list grouplist bandwidth-percent percentage-bandwidth
Example:
Router(config-if)#cable rf-channel controller 1 channel-list 1-3 bandwidth-percent 10
Configures the bandwidth allocation for specified channel-list on downstream controllers and includes the channels in
the downstream bonding group. Range for channel numbers are 0-127.
• controller number—Downstream controller number. The valid numbers are 0-7.
Step 7 end
Example:
Router# end
What to do next
Verify the Bonding Group Interfaces.

Use wideband-channel option of the show controllers integrated-Cable command to display bonding group
interfaces:
Router# show controllers integrated-cable 1/0/0 wideband-channel

210
Time source is NTP, *17:45:51.964 PST Thu Jan 12 2012

WB BG Primary
channel ID BG
Wideband-Cable1/0/0:0 12289 Yes
• To display the RF-channel mapping to wideband channels, use mapping wb-channel option.
Router# show controllers Integrated-Cable 1/0/0 mapping wb-channel 0

Ctrlr WB RF WB % WB Rem
1/0/0 0 1/0/0:0 40 1
1/0/0:1 40 1
• To display the downstream MAC Domain service groups, use the dsbg-associations option of the show
cable mac-domain command.
Router# show cable mac-domain c1/0/0 dsbg-associations

Wi1/0/0:0 Wi1/0/0:1
Use the show interface Wideband-Cable controller command to verify the bonding group configurations.
The State info table shows the downstream bonding group state information.
Router#show interface Wideband-Cable 1/0/0:0 controller

Wideband-Cable1/0/0:0 is up, line protocol is up
Hardware is CMTS WB interface, address is c414.3c17.1dcb (bia c414.3c17.1dcb)
211
Upstream Bonding Group Configuration

BG controller details
Wi1/0/0:0 BGID: 12289
Member RFIDs:
Config RFIDs: 12288-12291 Count: 4
Active RFIDs: 12288-12291 Count: 4
Attribute mask: 0x80000000
----------------------------------------------
State info (DSBG if and its underlying states)
----------------------------------------------
DSBG IF state : UP
DSBG Member RF chan states : UP (4 out of 4 chans are UP)
DSBG HWID(FCID) : 0x3800
*DSBG i/f Line State : UP
----------------------------------------------
-----------------------------
DMP Resources
DMP handle : 0x10000800
-----------------------------
DMP BG pool entry details
HW-id BGid BGSize Enabled
-----------------------------
0 : 12289 4 1
-----------------------------
Bgid BGecnt BGaddr Channels (1023 means invalid/Unused)
0 0 0: 0 1 2 3 1023 1023 1023 1023
BG Rate Neg Pos LastTS CurrCr Pos
0 25000 65535 65535 0 0 N
-----------------------------
RFID - JIB chan mapping for active RFIDs: [rfid:jib-chan-no]
[12288:0] [12289:1] [12290:2] [12291:3]
Router#
Upstream Bonding Group Configuration

Restrictions for Upstream Bonding Groups
• Upstream bonding groups are configured within the MAC Domain interface
• Upstream bonding groups consist of a set of upstream channels that are bonded together.
212
Configuring Upstream Bonding Groups
• A maximum of 16 upstream channels can be configured for each MAC Domain, which are divided into
two groups:
The upstream bonding-group should include all the upstream channels either from Group 1 or Group
2 only.
Configuring Upstream Bonding Groups

Before you begin
Procedure

Router> enable

Example:
Step 3 interface cable slot/subslot/MD index Enters MAC domain configuration mode.
Example: • slot—Specifies the chassis slot number of the interface
Router(config)# interface cable 1/0/0 line card. Valid values are 0-3 and 6-9
• subslot—Specifies the secondary slot number of the
interface line card. Valid subslot is 0.
• MD index—Specifies the MAC Domain index number.
Valid values are 0-15.
Step 4 cable upstream bonding-group Creates a static upstream bonding group on a MAC Domain.
Example:
Router(config-if)#cable upstream bonding-group 7

Router(config-upstream-bonding)#
Step 5 upstream Add upstream channels to an upstream bonding group.

Example: A maximum of 16 upstream channels can be configured for
each MAC Domain, which are divided into two groups:
Router(config-upstream-bonding)#upstream 7
213
Verifying Upstream Bonding Groups


Example:
Router# end
What to do next
Use the show interface cable upstream bonding-group command to display upstream bonding group
information.
Router#show interface cable 1/0/0 upstream bonding-group

Cable1/0/0: Upstream Bonding Group 1

0 packets input, 0 octets input
Segments: 0 valid, 0 discarded, 0 lost
Reserved Bandwidth Max : 0 bits/sec
Reserved Bandwidth : 0 bits/sec
Available Bandwidth : 46080000 bits/sec
Total Service Flows On This Bonding Group: 0
Router#
Verifying Upstream Bonding Groups

Use the show cable upstream bonding-group command.
Router#show interface cable 1/0/0 upstream bonding-group

214

Router#
Description Link
ID and password.
215
Feature Information for DOCSIS Interface and Fiber Node Configuration
Feature Information for DOCSIS Interface and Fiber Node

Configuration
Table 30: Feature Information for DOCSIS Interface and Fiber Node Configuration
DOCSIS Interface and Fiber Node Cisco IOS XE Everest 16.6.1 This feature was integrated into
Configuration Cisco IOS XE Everest 16.6.1 on
the cisco cBR Series Converged
Broadband Routers.
Display QAM Utillization Cisco IOS XE Gibraltar 16.10.1f This feature was integrated on the
Percentage using the sh controllers Cisco cBR Series Converged
Integrated-Cable 7/0/0 counter Broadband Routers.
rf-channel
216
CHAPTER 15
Service Group Based Configuration of the Cisco
cBR Router
• Service Group Profile Based Configuration, on page 217
• Service Profile Configuration for 16x8 with One MAC Domain, on page 219
• Service Profile Configuration for 16x8 with Two MAC Domains, on page 221
• MAC-Domain Split Configuration, on page 223
Service Group Profile Based Configuration

The DOCSIS Interface and Fiber Node Configuration guide describes the interface and fiber node configurations
that are required to operationalize the Cisco cBR router. The steps described to accomplish the tasks involved
in such configuration are complex.
To simplify and speed up the process of configuring the physical and logical interfaces required to deploy the
Cisco cBR router quickly, a service group (SG) profile based approach is adopted. This document describes
the simplified SG profile approach.
This approach provides the following advantages:
• Improves and simplifies the deployment of Cisco cBR router.
• Improves and simplifies the configuration of Cisco cBR Router by eliminating duplicate configurations.
• Improves and simplifies troubleshooting of Cisco cBR router.
• Supports faster Converged Cable Access Platform (CCAP) provisioning by using common and quick
replication across nodes and regions.
To configure the interfaces and quickly operationalize the Cisco cBR router, a set of common profiles are
created and are created and configured into global service group profiles. These global service group profiles
may be applied to fiber node interfaces along with a mapping of the service group interfaces to the physical
interfaces.
Common profiles are profiles which contain configurations for common service group (SG) interfaces like
MAC domain, wideband-cable, and primary downstream
The common profiles and the global SG profiles may be independent of the topology of the network in which
they are applied. The SG interface to physical interface mapping defines the behavior of the profiles in the
topology that the SG profiles have been applied to.
217
Service Group Profile Based Configuration
Limitations:
• A common profile cannot be deleted if it is associated with the fiber nodes. It can be modified by entering
the profile configuration mode using the cable profile command.
• A service-group profile cannot be deleted or modified if it is associated with the fiber nodes.
• To associate a new global SG profile to a fiber node, dissociate the currently associated global SG profile
from the fiber node.
• To configure for a unique topology, use the full configuration approach provided in DOCSIS Interface
and Fiber Node Configuration guide.
• When the secondary line card is in active mode, the following limitations apply:
• A MAC domain, Wideband-Cable interface, downstream channel, and SG profile cannot be modified
when they are associated with the fiber nodes.
• SG profile cannot be dissociated from the fiber nodes.
• A MAC domain, Wideband-Cable interface, downstream channel, and SG profile can be created
but cannot be associated to the fiber node.
• To enable the SG operation simplification feature, auto-reset feature must be enabled using the
cable wideband auto-reset command.
• Do not support downgrade cBR-8 image from 16.7.x to previous image if the configuration includes mac
domain split configuration.
Broadly, the following steps define and deploy the common profiles and the SG profiles:
1. Define and configure the Common profiles: The SG interface profiles or the common profiles contain
configuration parameters common to a group of similar interfaces. For example, a profile may contain
specific configuration parameters shared by multiple Wideband-Cable interfaces, associated across multiple
line cards. A common profile is configured at the global or chassis level. All interfaces associated with a
profile will inherit the configuration in the profile. Any common profile may be associated with any global
SG profile. Use the cable profile profile-type profile-name command to define the following common
profiles:
• MAC Domain (MD) profile
• Primary Downstream channel (DS) profile
• Wideband-cable Interface (WB) profile
• Global Service Group (SG) profile
2. Complete the following configurations to the fiber node interface using the cable fiber-node command:
• Define the downstream and upstream ports. Map the appropriate interface-cable using the downstream
interface-cable command. Map the appropriate upstream-cable interface using the upstream
upstream-cable command.
• Use the downstream sg-channel command to map the logical downstream SG channels to the
physical RF channels and the upstream sg-channel command to map the logical upstream SG
channels to the physical upstream channels.
• Use the service-group profile to associate the global service group profile to the fiber node.
218
Service Profile Configuration for 16x8 with One MAC Domain
See the use case scenarios for configurations and examples.

This section describes the service group based configurations for a 16x8 service group with one MAC domain.
Step 1 cable profile profile-type profile-name

For MAC Domain profile, specify profile-type as mac-domain.
Router(config)#cable profile mac-domain MD1

Router(config-profile-md)#cable dynamic-secret mark
Router(config-profile-md)#cable shared-secret 0 cisco
Router(config-profile-md)#cable ip-init ipv4
Router(config-profile-md)#cable mtc-mode
Router(config-profile-md)#cable mrc-mode
Router(config-profile-md)#cable privacy mandatory
Router(config-profile-md)#cable privacy bpi-plus-policy
For Primary downstream profile, specify profile-type as downstream.
Router(config)#cable profile downstream DS1

Router(config-profile-ds)#cable rf-bandwidth-percent 20
Router(config-profile-ds)#cable attribute-mask 0x80000000
For wideband-cable interface profile, specify profile-type as wideband-interface.
Router(config)#cable profile wideband-interface BG1

Router(config-profile-wb)#cable downstream attribute-mask 0x80000000
For global service group profile, specify profile-type as service-group. In the service group profile, configure the cable
bundle associated, mac-domain profile, and the wideband interface profile
Router(config)#cable profile service-group SG-16x8-1_1

Router(config-profile-sg)#cable bundle 71
Router(config-profile-sg)#mac-domain 0 profile md1
Router(config-profile-sg-md)#downstream sg-channel 0-7 profile ds1 upstream 0-3
Router(config-profile-sg-md)#upstream 0 sg-channel 0
Router(config-profile-sg-md)#us-bonding-group 1
Router(config-profile-sg-md-usbg)#upstream 0
219
Router(config-profile-sg-md-usbg)#attributes 8000000
Router(config-profile-sg-md-usbg)#exit
Router(config-profile-sg-md)#exit
Router(config-profile-sg)#
Router(config-profile-sg)#wideband-interface 1 profile BG1

Router(config-profile-sg-bg)#downstream sg-channel 0 15 rf-bandwidth-percent 10
Router(config-profile-sg-bg)#end
Router#
Step 2 cable fiber-node

Enter fiber-node configuration mode. Configure the following in fiber-node configuration mode:
• downstream port
• upstream port
• downstream sg-channels to rf-channels mapping
• upstream sg-channels to us-channels mapping
• global service group mapping
• managed MAC domain
Router(config-fiber-node)#downstream integrated-cable 3/0/0
Router(config-fiber-node)#upstream upstream-cable 3/0/0
Router(config-fiber-node)#downstream sg-channel 0 15 integrated-cable 3/0/0 rf-channel 0 15
Router(config-fiber-node)#upstream sg-channel 0 7 upstream-cable 3/0/0 us-channel 0 7
Router(config-fiber-node)#service-group profile SG-16X8-1_1
What to do next
Use the show cable fiber-node [id] mapping and the show cable fiber-node [id] derived commands to
check the configuration of the interfaces.
Router#show cable fiber-node 1 mapping

Fiber-node 1:
Upstream:
Sg chan Us-chan Op state
0 3/0/0 0 Up
1 3/0/0 1 Up
2 3/0/0 2 Up
3 3/0/0 3 Up
4 3/0/0 4 Up
5 3/0/0 5 Up
6 3/0/0 6 Up
7 3/0/0 7 Up
Downstream:
Sg chan Ds-rf-chan Op state
0 3/0/0:0 Up
1 3/0/0:1 Up
2 3/0/0:2 Up
220
Service Profile Configuration for 16x8 with Two MAC Domains
3 3/0/0:3 Up
4 3/0/0:4 Up
5 3/0/0:5 Up
6 3/0/0:6 Up
7 3/0/0:7 Up
8 3/0/0:8 Up
9 3/0/0:9 Up
10 3/0/0:10 Up
11 3/0/0:11 Up
12 3/0/0:12 Up
13 3/0/0:13 Up
14 3/0/0:14 Up
15 3/0/0:15 Up
Router#show cable fiber-node 1 derived

Fiber-node 1:
interface Assoc successed
mac-domain 0 Cable3/0/0 Y
Wideband 1 Wideband-Cable3/0/0:0 Y
Router#
Use the show cable mac-domain fiber-node command to verify the interface associations.
Router#show cable mac-domain fiber-node 1 md 0 downstream-service-group

Cable MD-DS-SG RF
IF Id Resource Chan Primary Chan
C3/0/0
Router#
Router#show cable mac-domain fiber-node 1 md 0 upstream-service-group

Cable MD 3/0/0
Router#

This section describes the service group based configurations for a 16x8 service group with two MAC domains,
split downstream and overlaid upstream channels.
Step 1 cable profile profile-type profile-name

For MAC Domain profile, specify profile-type as mac-domain.
Router(config)#cable profile mac-domain MD1

For Primary downstream profile, specify profile-type as downstream.
221
Router(config)#cable profile downstream DS1

For wideband-cable interface profile, specify profile-type as wideband-interface.
Router(config)#cable profile wideband-interface BG1

For global service group profile, specify profile-type as service-group. In the service group profile, configure the cable
bundle associated, mac-domain profile, and the wideband interface profile
Router(config)#cable profile service-group SG-16x4-1_2

Router(config-profile-sg)#mac-domain 0 profile md1
Router(config-profile-sg-md)#downstream sg-channel 0-15 profile ds1 upstream 0-3
Router(config-profile-sg)#

Router(config-profile-sg-bg)#exit
Router#

• downstream port
• upstream port
222
MAC-Domain Split Configuration

Router(config-fiber-node)#exit
Router(config)#
Router(config-fiber-node)#exit
Router(config)#
What to do next
Use the show cable fiber-node [id] mapping and the show cable fiber-node [id] derived commands to
check the configuration of the interfaces.

This section describes the MAC-domain split configurations.
Note • In MAC domain split scenario, we must configure upstream peer-node-us and managed MAC domain.
• After a fiber node managed MAC domain, we will reserve cable interface by cable managed fiber-node
command.
• If a fiber-node has peer, we can not add managed MAC domain.
• If a fiber-node has peer, we can not modify the configuration of channel mapping and upstream
peer-node-us
• If a fiber-node has managed MAC domain, we can not remove upstream peer-node-us.
• Only both two fiber-nodes are associated with service group profile, mac-domains and wideband interfaces
will be generated.
• MAC domain and wideband interfaces will be removed as soon as one fiber-node is unassociated with
service group profile.
Step 1 cable profile mac-domain

Define global common profiles for MAC-domain, bonding group, primary downstream.
Router(config)#cable profile mac-domain MD
223
Router(config-profile-md)#load-interval 30
Router(config-profile-md)#cable privacy accept-self-signed-certificate
Router(config-profile-md)#cable privacy dsx-support
Router(config-profile-md)#cable privacy eae-policy capability-enforcement
Router(config-profile-md)#cable privacy kek life-time 300
Router(config-profile-md)#cable privacy retain-failed-certificates
Router(config-profile-md)#cable privacy skip-validity-period
Router(config-profile-md)#cable privacy tek life-time 180
Router(config-profile-md)#cable cm-status enable 3
Router(config-profile-md)#cable map-advance dynamic
Router(config-profile-md)#cable upstream 0 attribute-mask FFFFFFFF
Router(config-profile-md)#cable upstream 0 power-adjust continue 5
Router(config-profile-md)#cable upstream balance-scheduling
Router(config)#cable profile downstream DS
Router(config)#cable profile wideband-interface BG
Router(config-profile-wb)#description BG
Router(config-profile-wb)#load-interval 30
Step 2 cable profile service-group

In the service group profile, configure the cable bundle associated, mac-domain profile, and the wideband interface profile.
Router(config)#cable profile service-group MD_SPLIT

Router(config-profile-sg)#mac-domain 0 profile MD
Router(config-profile-sg-md)#downstream sg-channel 0-15 profile DS
Router(config-profile-sg)#wideband-interface 0 profile WB
Router(config-profile-sg-bg)#exit
Router(config-profile-sg)#wideband-interface 1 profile WB
224

• downstream port
• upstream port
• abstract upstream channel
Router(config-fiber-node)#downstream sg-channel 0 15 integrated-cable 6/0/6 rf-channel 0
15
Router(config-fiber-node)#upstream sg-channel 4 7 peer-node-us
Router(config-fiber-node)#service-group managed md 0 cable6/0/6
Router(config-fiber-node)#service-group profile MD_SPLIT
Router(config-fiber-node)#downstream sg-channel 0 15 integrated-cable 6/0/6 rf-channel 0
15
Router(config-fiber-node)#upstream sg-channel 0 3 peer-node-us
Router(config-fiber-node)#service-group managed md 0 cable6/0/6
Router(config-fiber-node)#service-group profile MD_SPLIT
225
226
CHAPTER 16
DOCSIS Load Balancing Groups
First Published: April 11, 2015
Support for the restricted load balancing group (RLBG)/general load balancing group (GLBG) is based on
DOCSIS 3.0 specifications.
Contents
• Prerequisites for DOCSIS Load Balancing Groups, on page 229
• Restrictions for DOCSIS Load Balancing Groups, on page 229
• Information About DOCSIS Load Balancing Groups, on page 230
• How to Configure DOCSIS Load Balancing Groups, on page 236
• Configuration Examples for DOCSIS Load Balancing Groups, on page 246
• How to Configure Load Balancing with Operational Simplification, on page 247
• Verifying DOCSIS Load Balancing Groups, on page 251
• Feature Information for DOCSIS Load Balancing Groups, on page 256
227
Digital PICs:

Module:

Modules:
line card reload.
228
Prerequisites for DOCSIS Load Balancing Groups
Prerequisites for DOCSIS Load Balancing Groups

DOCSIS Load Balancing Groups including Restricted/General Load Balancing groups with Downstream
Dynamic Load Balancing feature has the following prerequisites:
• A RLBG and a DOCSIS 2.0 GLBG should have a load balancing group (LBG) ID.
• A LBG should have a default policy ID.
• During registration, a cable modem (CM) that has been assigned to a LBG must also be assigned a policy
ID and priority, through Simple Network Management Protocol (SNMP), the cable modem configuration
file, or Cisco Cable Modem Termination System (CMTS) configuration.
• The cable modem must send service type identifier (STID), service class name, and DOCSIS version
and capability type/length/value (TLV) settings to the Cisco CMTS for registration if the fields are used
by general tagging.
Restrictions for DOCSIS Load Balancing Groups

The DOCSIS Load Balancing Groups (LBG) including RLBG/GLBG Support with DLB Support feature has
the following restrictions:
• A maximum of 256 DOCSIS policies and 256 rules per chassis are supported.
• Cross-line card (LC) configuration or moving of cable modems is not supported.
• When deployed with channel restriction features, if the target upstream channel attribute masks are
against that of the cable modem, then the cable modem on the higher load upstream will not be load
balanced, as the current load balancing moves cable modems only to the target upstream. However, cable
modems that do not have an attribute mask can still be load balanced. You should consider the following
while deploying the load balancing groups: the target upstream will always be the upstream that has the
lowest load. If some other upstreams have the same load, the upstream with the lowest index will be
chosen as the target upstream.
• We recommend all LBGs that share channels must use the same LB method.
The DOCSIS LBG with RLBG/GLBG Support and DLB Support feature have the following cross functional
restrictions:
• Cable modems operating in the multiple transmit channel (MTC) mode do not register for a RLBG
assignment, even if their configuration file contains relevant TLVs, such as STID and LBG ID. However,
cable modems operating in the multiple receive channel (MRC) can register for a RLBG assignment.
• The Cisco CMTS can parse a specific TLV encoded in cable modem configuration file, and prohibit any
DCC operation on the cable modems.
• DOCSIS MAC domain downstream service group (MD-DS-SG) channels in MDD messages are incorrect
when a combination of channels from multiple line card types are placed in the same fiber node.
In a complex fiber node setup, with channels from more than one line card, or downstream channels of one
MAC domain in more than one fiber node, some modems may not come w-online (wideband online). If a
MAC domain has more than one MD-DS-SG, the MDD will contain more than one MD-DS-SG and cause
the modem to perform downstream ambiguity resolution. When the modem analyzes the downstream channels
from the other line card, it will not see MDD packets and disqualify the channel and the MD-DS-SG. The
modem then sends a requested MD-DS-SG of 0 to the CMTS implying it will not participate in a bonding
group.
229
Information About DOCSIS Load Balancing Groups
Use the show cable mac-domain downstream-service-group command to see the channels in the same
MD-DS-SG.
The DOCSIS LBG with RLBG/GLBG Support and DLB Support feature have the following scaling limitations:
• The total number of RLBGs and DOCSIS 2.0 GLBGs cannot exceed 256.
• The total number of tags in a Cisco CMTS cannot exceed 256.
• The total number of DOCSIS 3.0 GLBGs is bounded by free memory.
• A cable modem reset occurs if a CM moves from one cable interface to another because DCC init-tech
0 resets a cable modem during a LB move. A cable modem also resets if the two cable interfaces have
been configured with a mismatched cable ip-init command.
Information About DOCSIS Load Balancing Groups

The DOCSIS 2.0 “Autonomous Load Balancing” specification is CM-centric, allowing a channel (US or DS)
to be part of multiple RLBGs. Therefore, with the DOCSIS 2.0 specifications, you can decide on which
channel the CM can be load balanced.
To configure the Restricted/General Load Balancing and Narrowband Dynamic Bandwidth Sharing with
Downstream Dynamic Load Balancing feature, you should understand the following concepts:
Service-Based Load Balancing

Using the DOCSIS 3.0 modem-based load balancing specifications, you can manage the LB activity on a
per-modem basis as follows:
1. Modem to RLBG association through STID
2. Modem to RLBG association through LBG ID
3. Per-modem LB policy assignment
4. Per-modem LB priority assignment
5. Per-modem channel restriction
Implementing the DOCSIS 3.0 modem-based LB specifications enables the Cisco CMTS to provide an
advanced service-based LB. The service-based LB can be used to alleviate the burden for the modem-based
provisioning and provide the operator an ability to selectively control LB activity based on modem service
type. For example, for LB purposes modems can be classified based on:
• Device type
• DOCSIS version
• Service class
The results of the classification can then be used to selectively control the modem LB activity by mapping
the modem to the following settings:
• LBG
• Policy
With the service-based LB enabled, existing service-based cable modem segregation features and channel
restriction become special cases and can be handled within the same LB framework.
Functionality
The Cisco CMTS functions in the following ways for general tagging and service-based LB:
230
RLBG/GLBG Assignment
• The Cisco CMTS can classify some modems with user-defined modem classifiers using the STID, service
class name, DOCSIS version and capability TLVs and MAC Organization Unique Identifier (OUI).
• Each modem classifier has a unique tag. The Cisco CMTS allows each modem to carry one tag. When
multiple tags match one cable modem, the tag that has the least index gets applied on the cable modems.
• The Cisco CMTS classifies a CM and assigns a tag, and if a RLBG with that tag is configured, the CM
gets assigned to that RLBG.
• The Cisco CMTS can match multiple tags to a RLBG and a DOCSIS policy.
• On the Cisco CMTS, a user can configure whether the general tagging overrides the RLBG or DOCSIS
policy assignment using TLVs in the CM configuration file and SNMP when a conflict occurs.
• When doing autonomous LB, the Cisco CMTS ensures that the target channels are available to a specific
CM with regard to admission control, the SF attribute masks, and CM attribute masks.
• The user can configure the number of times that a DCC fails a CM before the CM is removed from
dynamic LB on the Cisco CMTS.
• The user can configure DCC initialization techniques or whether to use Upstream Channel Change (UCC)
for a LBG or for a particular source and target pair on the Cisco CMTS. However, DCC is not issued to
cable modems provisioned in DOCSIS 1.0 mode. By default, the UCC for a LBG is not configured and
therefore, all channel changes are done through DCC.
• The Cisco CMTS supports LB on at least one logical channel on a physical US channel that has multiple
logical US channels.
• As per the DOCSIS 3.0 specifications, a lower load balancing priority indicates a higher likelihood that
a CM will be moved due to load balancing operations.
• You can create a policy to set the lower bandwidth for CMs. the LBG can only move cable modems with
throughput that is above the threshold.
Compatibility
Both downstream and upstream autonomous load balancing is supported for single channel cable modems.
RLBG/GLBG Assignment
The user can configure one or more service type IDs for each RLBG. The user can also configure the Cisco
CMTS, using CLI or SNMP, to restrict a particular cable modem to a certain STID and RLBG ID. However,
if such a configuration is made, both the STID and RLBG ID in the configuration file are ignored by the Cisco
CMTS.
When the STID is configured by CLI or SNMP or the STID is present in the cable modem configuration file,
the Cisco CMTS selects an upstream and downstream channel, which offers the signaled service type, from
a RLBG, if such channels exist. However, if an upstream and downstream channel do not exist that provide
the signaled service type the Cisco CMTS assigns an upstream and downstream channel that does not offer
the signaled service type.
When the LBG ID is configured by CLI or SNMP or the LBG ID is present in the cable modem configuration
file, the Cisco CMTS examines the available choices for upstream and downstream channels and, if they
include a channel pair associated with the signaled LBG, the Cisco CMTS assigns the cable modem to the
signaled LBG. If these conditions are not met, the Cisco CMTS disregards the LBG ID.
If there are multiple upstream and downstream channels available that meet the requirements of the STID, if
present, and the LBG ID, if present, the Cisco CMTS selects an upstream and/or downstream channel that
meet the cable modem required and forbidden attribute masks requested in the configuration file. If upstream
and downstream channels are not available that meet these criteria, the Cisco CMTS can disregard the cable
modem attribute masks and select an alternative upstream and/or downstream channel.
231
Channel Assignment
In determining a target channel pair for a cable modem during registration time, the Cisco CMTS tries to find
the target channel pair that can actually reach the cable modem by checking the current channel pair, the
MD-DS-SG-ID (Media Access Control Domain Downstream Service Group Identifier) of cable modem
(CM-DS-SG-ID) and the MD-US-SG-ID (Media Access Control Domain Upstream Service Group Identifier)
of cable modem (CM-US-SG-ID), if present, and fiber node (FN) configurations. If the target channel pair is
available to the cable modem and is different from the current channel pair, the Cisco CMTS is required to
move the CM by means of DCC technique 0 or downstream frequency override (DFO).
When the Cisco CMTS identifies multiple candidate RLBGs for a CM, but cannot determine which fiber node
configuration the cable modem is actually wired to, or cannot determine if the wired RLBG is unusable (when
interfaces in the load balance group are disabled or in an administratively down state), the Cisco CMTS assigns
the cable modem to the RLBG with the lowest group index. This assignment causes the Cisco CMTS to
attempt to move the cable modem to interfaces it is not physically connected to, resulting in service outages
for the CM.
The Cisco CMTS enforces fiber node checking during RLBG assignment.
The Cisco CMTS follows the following RLBG assignment rules:
• If there is no fiber node configuration, there is no change in the candidate RLBG list. However, if the
fiber node is configured, the fiber node must be configured correctly to reflect the real fiber node
connection.
• If the cable modem is inside a fiber node, only those RLBGs that are inside that fiber node are selected.
• If the cable modem is not inside any fiber node, that is, the fiber node configuration does not cover all
the channels, only those RLBGs that are not inside any fiber node are selected.
• If an RLBG spans across multiple fiber nodes, it is not considered to be inside any fiber node.
• If no candidate RLBG is found, cable modems are assigned to the GLBG, if the GLBG exists.
Channel Assignment
For cable modems operating in MRC mode, the registration request message can have multiple TLVs to
influence the selection of upstream and downstream channels that the Cisco CMTS assigns. To avoid conflicts
between the multiple TLVs, the Cisco CMTS follows the precedence order defined below:
1. TLV 56—Channel Assignment
2. TLV 43.11—Service Type Identifier
3. TLV 43.3—Load Balancing Group ID
4. TLVs 24/25.31-33—Service Flow Attribute Masks
5. TLV 43.9—CM Attribute Masks
The Cisco CMTS must follow this TLV precedence order for cable modems not operating in MRC mode:
1. TLV 43.11—Service Type Identifier
2. TLV 43.3—Load Balancing Group ID
3. TLV 43.9—CM Attribute Masks
4. TLVs 24/25.31-33—Service Flow Attribute Masks
Note When a target for the new receive channel configuration (RCC) and Transmit channel configuration (TCC)
is selected, ensure that the service level for cable modems is not decreased. Target total RCCs and TCCs must
not be less than the source total RCCs and TCCs so that cable modems can keep their service level unchanged.
This may cause some unbalanced results when high capacity cable modems come online, later releases..
232
Channel Assignment
The Cisco CMTS also considers the DOCSIS 3.0 cable modem capabilities defined in the registration request
message and assigns the maximum number of channels that the CM requests.
The tables below define the load balancing matrix for RLBG and GLBG assignment:
Table 32: RLBG Assignment for DOCSIS Cable Modems
Operational Mode MAC Version
DOCSIS 3.0 CM DOCSIS 2.x CM DOCSIS 2.0 CM DOCSIS 1.1 CM DOCSIS 1.0 CM
Non-MRC mode Assigned Assigned Assigned Assigned Assigned

(online)
MRC mode only Assigned Assigned Assigned NA NA

(w-online)
MRC/MTC mode Assigned NA NA NA NA

(UB-online)
DOCSIS 3.0 cable NA NA NA NA
modems are
assigned to the
DOCSIS 3.0 RLBG
Table 33: GLBG Assignment for DOCSIS Cable Modems
Operational Mode MAC Version
DOCSIS 3.0 CM DOCSIS 2.x CM DOCSIS 2.0 CM DOCSIS 1.1 CM DOCSIS 1.0 CM
Non-MRC mode Assigned to the DOCSIS 2.0 GLBG without MD-DS-SG-ID/MD-US-SG-ID

(online)
Assigned to the DOCSIS 3.0 GLBG with NA NA NA
MD-DS-SG-ID/MD-US-SG-ID
MRC mode only Assigned to the DOCSIS 2.0 GLBG without MD-DS-SG-ID/MD-US-SG-ID
(w-online)
Assigned to the DOCSIS 3.0 GLBG with NA NA NA
MD-DS-SG-ID/MD-US-SG-ID
MRC/MTC mode Assigned NA NA NA NA

(UB-online)
DOCSIS 3.0 cable NA NA NA NA
modems are
assigned to the
DOCSIS 3.0 GLBG
The tables below give a snapshot view of the load balancing methods and the operations used to "move"
bonded and non-bonded CMs.
233
Channel Assignment
Table 34: Load Balancing Method to Move Bonded and Non-bonded cable modems
Modem Mode Dynamic Service Charge (Initialization Technique)
Within MAC Domain Across MAC Domains
DOCSIS 3.0 cable modems in MTC NA DCC initialization technique 0

mode
DOCSIS 3.0/DOCSIS 2.x cable DCC initialization technique 0 DCC initialization technique 0
modems in MRC-only mode
Note CM with primary DS outside RLBG moves inside
RLBG with DOCSIS 2.0 LB.
DOCSIS 3.0 cable modems in DCC DCC initialization technique 0

MRC-only mode
Note CM outside RLBG moves inside RLBG with
DOCSIS 2.0 LB.
DOCSIS 2.x cable modems in DCC/UCC DCC initialization technique 0

MRC-only mode
DOCSIS 2.0 LB.
DOCSIS 2.0 /DOCSIS 1.1 cable DCC DCC initialization technique 0

modems in NB mode
DOCSIS 2.0 LB.
UCC UCC
DOCSIS 2.0 LB.
DOCSIS 1.0 in NB mode Force reinitialize CM Force reinitialize CM

DOCSIS 2.0 LB.
UCC UCC
DOCSIS 2.0 LB.
Table 35: Using DCC/DBC to Load Balance Bonded and Non-bonded Cable Modems
Channel CM in MRC, non-MTC Mode DOCSIS 1.1/DOCSIS 2.0 cable modems DOCSIS 1.0 cable modems
with Single US/DS with Single US/DS
Upstream (US) DCC DCC UCC
Downstream NA (within the same MAC domain) DCC (within the same MAC domain). Force reinitialize CM
(DS)
DCC with initialization technique 0 DCC with initialization technique 0 when Force reinitialize CM
when moving cable modems across moving cable modems across MAC
MAC domains. domains.
234
Upstream Load Balancing for DOCSIS 3.0 Cable Modems in Single Upstream Mode
Error Handling of Channel Assignment

This restriction is modified. As long as the interface state of the channels is not "administratively down", all
channels are available for LBG assignment. For other load balancing operations, such as moving modems
using DCC, UCC, or DBC, the interface state of the channels should be in "initial", "up", "suspicious", or
"testing" states.
The following conditions apply when an LBG is disabled:
• cable modems that match all load balancing criteria can be assigned to an LBG.
• cable modem moves for load balancing are disabled, but cable modem moves from outside of the LBG
to inside of the LBG are allowed.
Upstream Load Balancing for DOCSIS 3.0 Cable Modems in Single Upstream
Mode
The upstream load balancing functionality enables the Cisco CMTS router to effectively handle upstream
traffic for wideband and narrowband cable modems that are in single upstream mode. Single upstream mode
(Mx1) means that the modems cannot send upstream traffic on multiple upstream channels. In the event of
traffic overload on a single upstream channel of a wideband or narrowband cable modem, the Cisco CMTS
router automatically moves the cable modem to another upstream channel in the same load balancing group.
Note A cable modem operating in single upstream mode is assigned to a load balancing group based on the primary
channel of the modem. A cable modem in single upstream mode can support multiple receive channel (MRC)
mode or narrowband mode. However, a cable modem in single upstream mode cannot support multiple transmit
channel mode (MTC).
Auto-generate DOCSIS 2.0 GLBG

Cisco CMTS does not automatically implement DOCSIS 2.0 GLBG. DOCSIS 2.0 GLBG is configured
manually after a new fiber node - MAC domain (FN-MD) pair is added.
This enhancement to automatically generate DOCSIS 2.0 GLBG after adding a new FN-MD pair and resolving
a new combination of MAC domain, cable modem, and service group (MD-CM-SG). This enhancement is
implemented through a new command cable load-balance d20 GLBG auto-generate. The command has
options to renew and update DOCSIS 2.0 GLBGs for a fiber node configuration.
Independent Upstream/Downstream Throughput Rules

Currently, during upstream or downstream load balancing, to move modems in load balancing operations,
Cisco CMTS applies the DOCSIS policy throughput rules to both upstream and downstream throughput to
upstream or downstream load balancing operations. In other words, for downstream load balancing, both
upstream and downstream sets of rules are applied and similarly for upstream load balancing both set of rules
are applied. This prevents movement of modems with low upstream or high downstream throughput and high
upstream or low downstream throughput.
Upstream or downstream throughput rules are checked independently to corresponding upstream or downstream
load balancing operations. During upstream load balancing, only upstream throughput rules are checked, and
during downstream load balancing, only downstream throughput rules are checked.
235
How to Configure DOCSIS Load Balancing Groups
The following important points are implemented for independent upstream/downstream throughput rules:
• If DOCSIS 2.0 load balancing policy configured is us-across-ds, it is recommended to configure a
maximum of 16 downstream channels and 8 upstream channels.
• If a load balancing operation involves a change only in the downstream channel of a cable modem without
any change to the upstream channel, then only the downstream lower boundary rules are checked.
• If a load balancing operation involves a change only in the upstream channel of a cable modem without
any change to the downstream channel, then only the upstream lower boundary rules are checked.
• If a load balancing operation involves a change in both the upstream and downstream channels of a cable
modem, then the modem rule check must pass all the rules for that (upstream or downstream) load
balancing.
• If the load balancing policy configured is pure-ds-load, then only the downstream rules are checked.
• If the load balancing policy configured is us-across-ds or both us-across-ds and pure-ds-load, then two
types of target interfaces occur as follows:
• Local interface—where the cable modem shares the upstream with the source. Only downstream
load balancing operation occurs.
• Remote interface—where the the cable modem does not share the upstream with the source. The
upstream/downstream load balancing is triggered by upstream load.
If the load balancing policy configured is neither us-across-ds nor pure-ds-load, then the load balancing
is done based on Mac domain load.
How to Configure DOCSIS Load Balancing Groups

The Restricted/General Load Balancing and Narrowband Dynamic Bandwidth Sharing with Downstream
Dynamic Load Balancing feature can be configured as follows:
• A user can configure a DOCSIS 2.0 general load balancing group (GLBG) on the Cisco CMTS according
to DOCSIS specification. The Cisco CMTS creates a DOCSIS 3.0 GLBG for each Media Access Control
Domain Cable Modem Service Group (MD-CM-SG) automatically and checks whether the GLBG
contains both upstream and downstream channels.
• A cable modem that is not provisioned to any RLBG and cannot resolve its MD-CM-SG gets assigned
to a DOCSIS 2.0 GLBG. However, if the cable modem resolves its MD-CM-SG, it gets assigned to a
DOCSIS 3.0 GLBG.
• A user can configure RLBGs and any upstream or downstream channel into multiple RLBGs on the
Cisco CMTS. The Cisco CMTS checks whether a RLBG contains both upstream and downstream
channels. A RLBG can cross multiple MDs.
• A backward compatibility with existing Cisco LB schemes is maintained. The users can switch between
the old and new DOCSIS 3.0 compliant LB schemes.
Note When the Cisco IOS system is upgraded, if the docsis-policy configuration of the DOCSIS load balancing
groups, is missing in the output of the show running-config command, apply the docsis-policy to the DOCSIS
load balancing groups using the docsis-policy policy-id command again.
236
Configuring DOCSIS 3.0 and 2.0 RLBG and DOCSIS 2.0 GLBG
The following sections describe how to create and configure DOCSIS load balancing groups to enable DOCSIS
load balancing on the Cisco CMTS:
This section describes how to create and configure a DOCSIS load balancing group. There is a separate
configuration mode for a DOCSIS load balancing group that is different from the legacy load balancing group.
Note UGS/PCMM policy and threshold do not apply on DOCSIS 3.0 LB.
Procedure

Router> enable

Example:
Step 3 cable load-balance docsis-enable Enables DOCSIS load balancing on the Cisco CMTS.
Example:
Router(config)# cable load-balance docsis-enable
Step 4 cable load-balance docsis-group docsis-group-id Creates a DOCSIS load balance group on the Cisco CMTS,
with the following parameter:
Example:
The router enters DOCSIS load balancing group
Router(config)# cable load-balance docsis-group configuration mode.
1
Step 5 init-tech-list tech-list [ucc] Sets the DCC initialization techniques that the Cisco CMTS
can use to load balance cable modems.
Example:
Router(config-lb-group)# init-tech-list 1 ucc
Step 6 downstream {Cable {slot/subslot/port | slot/port} | Sets the downstream RF channels.

Integrated-Cable {slot/subslot/bay | slot/port}
{rf-channel group list}|{| slot/port} {rf-channel group
list}}
237

Example:
Router(config-lb-group)# downstream
integrated-Cable 5/0/0 rf-channel 2
Step 7 upstream Cable {slot/subslot/port | slot/port} Sets upstream channels with the following parameters:
upstream-list
Example:
Router(config-lb-group)# upstream Cable 1/0 2
Step 8 docsis-policy policy-id Assigns a policy to a group with the parameter that
becomes the default policy assigned to the CM, if the CM
Example:
does not choose a different policy.
Router(config-lb-group)# docsis-policy 0
Step 9 restricted Selects the restricted group type. By default, the general
group type is selected.
Example:
Router(config-lb-group)# restricted
Step 10 init-tech-ovr Cable {slot/subslot/port | slot/port} upstream Sets DCC initialization techniques that overrides the
Cable {slot/subslot/port } | slot/port upstream init-tech-list physical upstream channel pair. The init-tech-ovr
0-4 [ucc] command can also be used to determine whether the UCC
can be used for modems during dynamic upstream load
Example:
balancing.
Router(config-lb-group)# init-tech-ovr Cable 8/1/0 The following parameters override the physical upstream
0 Cable 8/1/1 1 init-tech-list 1 ucc channel pair:
Note The init-tech-list keyword accepts an upstream
that is not added into the load balancing group.
The upstream channel pair is invalid until the
upstream is added. When the load balancing
group is removed, all upstream channel pairs
are also removed.
Step 11 service-type-id string Adds a service type ID, with the following parameter, that
is compared against the cable modem provisioned service
Example:
type ID, to determine an appropriate restricted load
balancing group (RLBG):
Router(config-lb-group)# service-type-id
commercial
Step 12 tag tag name Adds a tag to the RLBG.

Example:
238
Configuring DOCSIS 3.0 GLBG
Router(config-lb-group)# tag t1
Step 13 interval <1-1000> Sets the time interval, the Cisco CMTS waits before
checking the load on an interface.
Example:
Router(config-lb-group)# interval 60
Step 14 method {modems | service-flows | utilization} Selects the method the Cisco CMTS use to determine the
{us-method {modems | service-flows | utilization}} load.
Example:
Router(config-lb-group)# method modems us-method

modems
Step 15 policy {pcmm | ugs | us-across-ds | pure-ds-load} Selects the modems based on the type of service flow that
are balanced.
Example:
Router(config-lb-group)# policy us-across-ds

Router(config-lb-group)# policy ugs
Router(config-lb-group)# policy pure-ds-load
Step 16 threshold {load {minimum <1-100> | <1-100>}| pcmm Selects the percentage of use beyond which load balancing
<1-100> | stability <0-100> | ugs <1-100>} occurs.
Example:
Router(config-lb-group)# threshold load minimum

10
Router(config-lb-group)# threshold pcmm 70
Router(config-lb-group)# threshold load 10
Router(config-lb-group)# threshold stability 50
Router(config-lb-group)# threshold ugs 70
Step 17 exit Exits DOCSIS LBG configuration.

Example:
Router# exit
Configuring DOCSIS 3.0 GLBG

The following sections describe how to configure a DOCSIS 3.0 GLBG and also how to configure default
values of DOCSIS 3.0 certification for the DOCSIS 3.0 general group:
Note If a Cable interface on the line card is in "no shut down" state, the associated DOCSIS 3.0 GLBGs are restored
in the running-configuration.
239
Configuring a DOCSIS 3.0 General Load Balancing Group
Configuring a DOCSIS 3.0 General Load Balancing Group

This section describes how to configure a DOCSIS 3.0 general load balancing group.
Procedure

Router> enable

Example:
Example:
Step 4 cable load-balance docsis-group FN fn-id MD cable Enters the DOCSIS load balancing group configuration
{slot/subslot/port | slot/port} mode.
Example:
Router(config)# cable load-balance docsis-group
FN 1 MD c5/0/0
Step 5 init-tech-list tech-list [ucc] Sets the DCC initialization technique list, with the
following parameters.
Example:
Step 6 disable Disables the load balance group.

Example:
Router(config-lb-group)# disable
Step 7 docsis-policy policy-id Sets the load balance group policy.

Example:
Router(config-lb-group)# docsis-policy 0
Step 8 interval 1-1000 Sets the interface polling interval.

Example:
Router(config-lb-group)# interval 10
Step 9 method {modems | service-flows | utilization} Sets the load balancing type or method.
{us-method {modems | service-flows | utilization}}
Example:
Router(config-lb-group)# method modems us-method
modems
240
Configuring Default Values of DOCSIS 3.0 Load Balancing Group

Step 10 policy {pcmm | ugs | us-across-ds | pure-ds-load} Sets load balancing policy.
Example:
Step 11 threshold {load {minimum 1-100 | 1-100} | pcmm 1-100 Sets the load balancing threshold in percentage.
| stability 0-100 | ugs 1-100}
Example:
Step 12 exit Exits the DOCSIS load balancing group configuration

mode.
Example:
Router# exit
Configuring Default Values of DOCSIS 3.0 Load Balancing Group

This section describes how to configure default values of DOCSIS 3.0 certification for a DOCSIS 3.0 general
group on the Cisco CMTS. A DOCSIS 3.0 general group is automatically created for each MD-CM-SG derived
from the fiber node (FN) configuration, and the group parameters are set as default values.
Note The configured default values of DOCSIS 3.0 certification are applicable to the new automatically created
DOCSIS 3.0 GLBGs and do not affect the existing DOCSIS 3.0 GLBGs. When a DOCSIS 3.0 GLBG is
removed and recreated, its group parameters do not change.
Note The default settings for interface polling interval, load balancing method, policy for modems selection, and
threshold usage in percent, can be configured for DOCSIS 3.0 general group. For more information, see the
Cisco CMTS Cable Command Reference.
Procedure

Router> enable

Example:
Step 3 cable load-balance d30-ggrp-default disable Disables the default values of the DOCSIS 3.0 general load
balance group (GLBG).
Example:
241
Configuring Cable Modems to RLBG or a Service Type ID

Router(config)# cable load-balance d30-ggrp-default
disable
Step 4 cable load-balance d30-ggrp-default init-tech-list tech-list Sets the default DOCSIS 3.0 GLBGs DCC and dynamic
bonding change (DBC) initialization techniques.
Example:
init-tech-list 1
Step 5 cable load-balance d30-ggrp-default docsis-policy Sets the default DOCSIS 3.0 GLBGs policy ID.
0-0xffffffff
Example:
docsis-policy 2
Step 6 exit Exits the global configuration mode.

Example:
Router# exit
Configuring Cable Modems to RLBG or a Service Type ID

This section shows how to configure a list of cable modems that are statically provisioned at the Cisco CMTS
to a RLBG or a service type ID.
Procedure

Router> enable

Example:
Step 3 cable load-balance restrict modem index mac-addr Assigns a modem or a group of modems with a common
[mac-mask] {docsis-group docsis-group-id | MAC mask to a load balancing group or a service type ID.
service-type-id string}
Example:
Router(config)# cable load-balance restrict modem
1 001a.c30c.7eee FFFF.FFFF.0000 docsis-group 100

Example:
Router# exit
242
Configuring Rules and Policies
Configuring Rules and Policies

This section shows how to create and configure rules and DOCSIS policies to restrict the movement of modems
during load balancing. Rules determine whether a modem can be moved and during which time periods. The
time periods are measured in seconds with the start time being an offset from midnight measured in seconds.
Rules are created individually and can be combined into policies. The user is able to create DOCSIS policies
that consist of one or more rules. When more than one rule is part of a DOCSIS policy, all rules apply. Each
group has a default DOCSIS policy.
Procedure

Router> enable

Example:
Step 3 cable load-balance rule rule-id Creates a rule to prevent the modem from being moved.
Example:
Router(config)# cable load-balance rule 1
Step 4 cable load-balance rule rule-id {enabled | disabled | Configures the rule.
{disable-period dis-start 0-86400 dis-period <0-86400>}
Note Static multicast groups should be configured on
| disable-throughput-lowerbound ds | us thrupt in kbps |
the appropriate bundle interface as well as on
vdoc-enabled}
the correct forwarding interfaces to enable this
Example: rule. This feature will not be supported on load
Router(config)# cable load-balance rule 1 balancing groups which are derived from fiber
disable-period dis-start 40 dis-period 50 node configuration and with multicast
encryption.
Step 5 cable load-balance docsis-policy policy-id rule rule-id Associates a particular rule with the DOCSIS policy with
the following parameters:
Example:
Router(config)# cable load-balance docsis-policy
2 rule 1

Example:
Router# exit
Problem When you disable load balancing and enable it for the next day using the cable load-balance rule
rule-id disable-period dis-start start-time dis-period disable-period command, the load balancing is enabled
at 12.00 am instead of the configured disable-period.
243
Configuring Load Balancing Parameter for a Cable Modem Movement Failure
Possible Cause Load balancing rule cannot be disabled and enabled on the next day (that is, after 24 hours)
using a single load balancing rule.
Solution Configure separate load balancing rules for disabling load balancing and enabling it on the next day.
Configure the rule to disable load balancing using the cable load-balance rule rule-id disable-period dis-start
start-time dis-period 0 command. Configure the rule to enable load balancing using the cable load-balance
rule rule-id disable-period dis-start 0 dis-period disable-period command to enable it for the next day.
Configuring Load Balancing Parameter for a Cable Modem Movement Failure

This section describes how to configure the number of times a CM can fail before the CM is removed from
the dynamic load balancing group.
Procedure

Router> enable

Example:
Step 3 cable load-balance modem max-failures 0-100 Configures the number of times a CM can fail before the
CM is removed from the dynamic load balancing group.
Example:
Router(config)# cable load-balance modem
max-failures 10

Example:
Router# exit
Creating and Configuring TLV type Tag

The tags for TLV type matching rule are created and configured in this section.
Procedure

Router> enable

Example:
244
Creating and Configuring TLV type Tag

Step 3 cable tag 1-1000 Creates a tag.

Example: Enters the cmts-tag configuration mode.
Router(config)# cable tag 1
Step 4 name tag name Specifies the name of the tag.

Example:
Router(cmts-tag)# name CSCO
Step 5 [exclude] service-type-id service-type-id Configures the specified service type ID for the tag.
Example:
Router(cmts-tag)# service-type-id HSD
Step 6 [exclude]service-class service-class-name Configures the specified service class name for the tag.
Example:
Router(cmts-tag)# service-class work
Step 7 [exclude] docsis-version docsis version Configures the specified DOCSIS version of the cable
modem for the tag.
Example:
Router(cmts-tag)# docsis-version docsis20
Step 8 [exclude] oui oui of CM Configures the specified OUI of the cable modem for the
tag.
Example:
Router(cmts-tag)# oui 00.1a.c3
Step 9 [exclude] tlv type value Configures the specified TLV type for the tag.
Example:
Router(cmts-tag)# tlv mrcs 4
Step 10 override Overrides the TLV or SNMP during load balancing an

RLBG.
Example:
Router(cmts-tag)# override
Step 11 exit Exits the cmts-tag configuration mode.

Example:
Router(cmts-tag)# exit
Step 12 cable load-balance docsis-group docsis-group-id Creates a DOCSIS load balancing group on the Cisco
CMTS.
Example:
Router(config)# cable load-balance docsis-group If the DOCSIS load balancing group is already present,
1 the router enters the specified DOCSIS load balancing
group configuration mode.
245
Configuration Examples for DOCSIS Load Balancing Groups

Step 13 tag tag name Adds a tag to the load balancing group.
Example:
Router(config-lb-group)# tag CSCO
Step 14 exit Exits the DOCSIS load balancing group configuration

mode.
Example:
Router(config-lb-group)# exit
Step 15 cable load-balance docsis-policy policy-id tag tag name Creates a DOCSIS policy and associates a new rule or an
[override] existing rule with the policy.
Example:
Router(config)# cable load-balance docsis-policy
2 tag CSCO

Example:
Router# exit
Configuration Examples for DOCSIS Load Balancing Groups

This section describes a sample configuration example for configuring DOCSIS Load Balancing Groups
including Restricted/General Load Balancing and downstream dynamic load balancing:
Example: Configuring a Tag

The following example shows how you can configure the tag to exclude a DOCSIS version, a MAC address,
a service class name or a service type ID:

Router(config)# cable tag 1
Router(cmts-tag)# exclude ?
docsis-version set the match rule for docsis version
oui set the match rule for oui
service-class set the match rule for service class name
service-type-id set the match rule for service type id
Router(cmts-tag)# exclude docsis-version ?
docsis10 Match docsis 1.0 modems
Router(cmts-tag)# exclude docsis-version docsis10
Router(cmts-tag)# exclude oui ?
WORD OUI of the vendor in the format xx.xx.xx or xx:xx:xx
Router(cmts-tag)# exclude oui 00.1a.c3
Router(cmts-tag)# exclude service-class ?
WORD Service class name
Router(cmts-tag)# exclude service-class work
Router(cmts-tag)# exclude service-type-id ?
246
Example: Disabling Load Balancing
WORD Service Type ID

Router(cmts-tag)# exclude service-type-id commercial
Example: Disabling Load Balancing

Use the following commands to disable DOCSIS 3.0 GLBG:
Router(config)# cable load-balance docsis-group FN 1 MD cable 6/0/0

Router(config-lb-group)#
Use the following commands to disable DOCSIS 3.0 RLBG:
Router(config)# cable load-balance docsis-group 1

Router(config-lb-group)#
How to Configure Load Balancing with Operational

Simplification
To configure Load Balancing Groups with Operational Simplification, complete the following steps:
SUMMARY STEPS
1. Define the global common Load Balancing profile. Specify the Load Balancing Group configure: method,
interval, threshold, policy, and so on.
2. Define the Load Balancing Group under service-group profile. Associate the Load Balancing profile with
Load Balancing group. Configure the DS and US channels.
3. Define the physical mapping info for US or DS channels under fiber-mode.
4. Define the service-group profile under Fiber-node.
DETAILED STEPS

Step 1 Define the global common Load Balancing profile. Specify
the Load Balancing Group configure: method, interval,
threshold, policy, and so on.
Example:
cable profile load-balance lb_1

disable
method utilization primary-distributed us-method
utilization
threshold load 2
policy pcmm
interval 1
247
How to Configure Load Balancing with Operational Simplification

Step 2 Define the Load Balancing Group under service-group
profile. Associate the Load Balancing profile with Load
Balancing group. Configure the DS and US channels.
Example:
cable profile service-group sg

load-balance docsis-group 0 profile lb_1
downstream sg-channel 0-7
upstream 0 sg-channel 0
Step 3 Define the physical mapping info for US or DS channels

under fiber-mode.
Example:
cable fiber-node 1
downstream sg-channel 0 15 downstream-Cable 6/0/0
rf-channel 0 15
upstream sg-channel 0 3 Upstream-Cable 6/0/0
us-channel 0 3
Step 4 Define the service-group profile under Fiber-node.

Example:
cable fiber-node 1
service-group profile sg
The Load Balancing Groups are auto-generated when the SG profile is applied.
Example
An example of the Load Balancing Groups Operational Simplification configuration, show run as
is as follows:
cable profile load-balance lb

method utilization primary-distributed us-method utilization
threshold load 22
threshold load lcmm 33
policy lcmm
policy pure-ds-load
init-tech-list 1-3

load-balance docs is-group 0 profile lb
downstream sg-channel 0 15
load-balance docsis-group 2 profile RLBG_STB
downstream sg-channel 0-3 8-11
248
How to Configure Load Balancing with Operational Simplification
cable fiber-node 1
downstream Downstream-Cable 6/0/0
upstream Upstream-Cable 6/0/0
downstream sg-channel 0 15 downstream-Cable downstream-Cable 6/0/0 rf-channel 0 15
upstream sg-channel 0 3 Upstream-Cable 6/0/0 us-channel 0 3
An example of the Load Balancing Groups Operational Simplification configuration, show derived
as is as follows:
cable profile load-balance lb

method utilization primary-distributed us-method utilization
threshold load 22
threshold load lcmm 33
policy lcmm
policy pure-ds-load
init-tech-list 1-3
Cable profile service-group sg

Load-balance docsis-group 0 profile lb
downstream sg-channel 0 15
load-balance docsis-group 2 profile RLBG_STB
downstream sg-channel 0-3 8-11
Cable fiber-node 1
downstream Downstream-Cable 6/0/0
upstream Upstrea-CAble 6/0/0
downstream sg-channel 0 15 downstream-Cable 6/0/0 rf-channel 0 15
Cable load-balance docsis-group 2

restricted
downstream Downstream-Cable 6/0/0/ rf-channel 0 15
upstream Upstream-Cable 6/0/0 us-channel 0-3
method utilization primary-distributed
threshold load 22
threshold pcmm 33
policy lcmm
policy pure-ds-load
init-tech-list 1-3
cable managed fiber-node 1
cable load-balance-profile lb
cable load-balance docsis-group 3
restricted
downstream Downstream-Cable 6/0/0 rf-channel 0-3 8-11
Upstream Upstream-Cable 6/0/0 us-channel 0
Threshold load 55
Interval 5
Cable managed fiber-node 1
Cable load-balance-profile RLBG_STB
249
Load Balancing Groups with Operational Simplification
Load Balancing Groups with Operational Simplification

The Cisco IOS XE Gibraltar 16.10.1d supports simplified Load Balancing configuration in the Operational
Simplification service group profile. Currently, CMTS supports auto creation of D30 GLBGs based on the
existing configuration. Load Balancing would now support creation of RLBGs and D20 GLBGs.
Following are the salient features of the feature:
• For D20 GLBG created by Operational Simplification, the Group ID is in range [65024, 65535]. This
follows legacy design.
• For RLBG created by Operational Simplification, the Group ID is related to the information of fiber-node
id/us channel controller/docsis-group index in service group file. This also follows legacy range [1,
2147483647]. For example: RLBG ID: 12330208. Where '123' is the Fiber node ID, '302' is the
Upstream-Cable 6/0/0, and '08' is the docsis-group index in service group profile.

load-balance docsis-group 8 profile lb_1
downstream sg-channel 0-7
• The default value of Load Balance profile are equal to the value of “cable load-balance d20-ggrp-default
xxx”.
• For Load Balancing Groups that are created by Operational Simplification, the user cannot configure
them with CLI.
• For one service group profile, a user is only allowed to configure one GLBG load balance.
• A user can configure a maximum of 20 tags into one load balance profile.
• A user can configure a maximum of 15 service-type-ids into one load balance profile.
• Load Balancing Groups by Operational Simplification supports fly modification.
• For Load Balancing Groups created by Operational Simplification, if a user changes the option of Load
Balance profile, the OPS would update all the related LBGs automatically. However, the user cannot
change the type of LBGs.
For the Load Balaning Groups created by Operational Simplification, the configuration of the groups would
not be dispalyed for the show run or the show run all commands. The Load Balancing Groups would only
be displayed using the derived command. This change can simplify the running configuration.
clab-cbr-S11K01#show derived-config | sec cable load

cable load-balance docsis-group 1
restricted
downstream Downstream-Cable 6/0/0 rf-channel 0-7
upstream Upstream-Cable 6/0/0 us-channel 0-1
method utilization primary-distributed
threshold load 2
cable load-balance-profile lb_1
250
Verifying DOCSIS Load Balancing Groups

This section describes how to use certain show commands to verify the configuration of the Restricted/General
Load Balancing and Narrowband Dynamic Bandwidth Sharing with Downstream Dynamic Load Balancing
feature.
Procedure

Router> enable
Step 2 show cable load-balance docsis-group {docsis-group-id Displays real-time configurational, statistical, and
| FN fn-id MD cable {slot/subslot/port | slot/port}} [all | operational information of the load balancing operations
load | pending | statistics | target | modem-list | on the router.
primary-load]
Example:
Router# show cable load-balance docsis-group 1
Router# show cable load-balance docsis-group fn 1
MD c8/1/4
Step 3 show cable fiber-node fiber-node-id [spectrum] Displays information about a fiber node.
Example:
Step 4 show cable load-balance [group n] | [all | load | pending Displays real-time statistical and operational information
| statistics | target | fiber-node-validation] for load balancing operations. If given without any options,
this command displays information for the load balancing
Example:
groups and each cable interface's current load and load
Router# show cable load-balance group 1 balancing status.
Step 5 show cable modem [ip-address | mac-address | cable Displays information for the registered and unregistered
slot/port [upstream port ] | name fqdn] [verbose] CMs.
Example:
Router# show cable modem 40.3.160.15 verbose
Examples
Use the show cable load-balance docsis-group command to see the DOCSIS group status and to
see the list of modems in the group, use the show cable fiber-node command to see the information
on fiber nodes, use the show cable load-balance command to see information on LBG and DOCSIS
channels, and use the show cable modem command to see the information on all the CMs.
The following examples show the output of the show cable load-balance docsis-group command:
251
DOCSIS LB Enabled: Yes

DOCSIS Group Status Interval DCC mask Policy Method Threshold
Group Index /UCC DS/US M/E/U/P/S
2 82 RE 10 0xF8(0)/N 0 s/s 1/1/70/70/50
Router# show cable load-balance docsis-group 1 modem-list
US Group Index Mac Address Priority
Mo1/0/0:0/U0 81 (1)
0000.ca45.9898 0
Mo1/0/0:0/U1 81 (0)
Mo1/0/0:0/U2 81 (2)
0013.711c.0820 0
0016.924f.8300 0
The output of the show cable load-balance docsis-group command is modified to include an
additional field MUPFXLR to display more status information on the modems in the DOCSIS groups.
For more information, see the Cisco IOS CMTS Cable Command Reference.
The following example shows the modified output of the show cable load-balance docsis-group
command:
Router#show cable load docsis-group fn 1 md c6/0/0 modem-list

Time source is NTP, 13:39:31.300 PDT Thu Mar 28 2013
Codes: M - Multicast, U - UGS, P - PCMM, F - Max-Failures, X - eXcluded
L - L2vpn, R - RSVP
Primary DS Grp Idx MAC Address RCC-ID Bad Rfid Priority MUPFXLR
In6/0/0:0/UB 40448 (6)
e448.c70c.98af 1 2 -------
e448.c70c.9b76 1 2 -------
e448.c70c.9c15 1 2 -------
e448.c70c.9a92 1 2 -------
e448.c70c.99e4 1 2 -------
e448.c70c.9a35 1 2 -------
In6/0/0:0/U0 40448 (0)
In6/0/0:0/U1 40448 (1)
e448.c70c.9915 2 -------
In6/0/0:0/U2 40448 (0)
In6/0/0:0/U3 40448 (0)
In6/0/0:1/UB 40448 (5)
e448.c70c.9abc 1 2 -------
e448.c70c.993f 1 2 -------
e448.c70c.9927 1 2 -------
e448.c70c.9b82 1 2 -------
4458.2945.2cb8 1 2 -------
In6/0/0:1/U0 40448 (0)
In6/0/0:1/U1 40448 (0)
In6/0/0:1/U2 40448 (0)
In6/0/0:1/U3 40448 (0)
In6/0/0:2/UB 40448 (5)
e448.c70c.9759 1 2 -------
e448.c70c.9a0e 1 2 -------
e448.c70c.992d 1 2 -------
e448.c70c.9a38 1 2 -------
0025.2ed9.9984 1 2 -----L-
In6/0/0:2/U0 40448 (0)
In6/0/0:2/U1 40448 (0)
In6/0/0:2/U2 40448 (0)
In6/0/0:2/U3 40448 (0)
In6/0/0:3/UB 40448 (5)
e448.c70c.9c00 1 2 -------
252
e448.c70c.99a5 1 2 -------
e448.c70c.9a5f 1 2 -------
e448.c70c.9a3b 1 2 -------
e448.c70c.96b1 1 2 -------
In6/0/0:3/U0 40448 (0)
In6/0/0:3/U1 40448 (0)
In6/0/0:3/U2 40448 (0)
In6/0/0:3/U3 40448 (0)
The following example shows the output of the show cable fiber-node command:
Router# show cable fiber-node

Fiber-Node Config Status
Fiber-Node 1
Modular-Cable 1/0/0: 0-1
MDD Status: Valid
The following examples show the output of the show cable load-balance command:
Router#show cable load-balance

Group Interval Method DCC Init Threshold
Technique Minimum Static Enforce Ugs PCMM
1 10 service-flows 1 1 2% 2% --- ---
2 10 modems 0 5 10% --- --- ---
DOCSIS LB Enabled: No
Router# show cable load-balance load
Interface State Group Utilization Reserved Modems Flows Weight
Index
Cable5/0/3 (459 MHz) up 1 0%(0%/0%) 0% 7 7 37
Cable5/0/3/U0 up 1 0% 0% 2 2 1.2
Cable5/0/3/U1 up 1 0% 0% 2 2 1.2
Cable5/0/3/U2 up 1 0% 0% 2 2 1.2
Cable5/0/3/U3 up 1 0% 0% 1 1 1.2
Cable5/0/4 (465 MHz) up 1 0%(0%/0%) 0% 7 7 37
Cable5/0/4/U0 up 1 0% 0% 1 1 1.2
Cable5/0/4/U1 up 1 0% 0% 2 2 1.2
Cable5/0/4/U2 up 1 0% 0% 2 2 1.2
Cable5/0/4/U3 up 1 0% 0% 2 2 1.2
Mo1/0/0:0 (555 MHz) down 1 0%(0%/0%) 0% 0 0 0
Router# show cable load-balance fiber-node-validation
DOCSIS LBG ID Match Channel Fiber-node list
1 match Ca5/0/0/U0 {1}
Ca5/0/0/U1 {1}
Ca5/0/0/U2 {1}
Ca5/0/0/U3 {1}
Mo1/0/0:0 {1}
Mo1/0/0:1 {1}
2 mismatch Ca5/0/0/U0 {1}
Ca5/0/0/U1 {1}
Ca5/0/0/U2 {1}
Ca5/0/0/U3 {1}
Ca5/0/0 {}
The following example shows the output of the show cable modem command:
253

LB group ID assigned(index) : 1(81)
LB group ID in config file(index) : N/A(N/A)
LB policy ID : 0
LB policy ID in config file : 0
LB priority : 0
Tag :
DOCSIS 3.0 GLBG is generated dynamically by the fiber node configuration, if a valid fiber node
is configured.
For example, if the fiber node configuration is:
cable fiber-node 2
downstream Modular-Cable 1/0/0 rf-channel 0-3
downstream Cable7/0/0
upstream Cable 7/0 connector 0-3
!
The GLBG generated by this fiber node is similar to:
Router# show cable load-balance docsis-group fn 2 md cable 7/0/0

DOCSIS 3.0 General LB
MD FN Group S Intv DCC mask Policy Mtd MD-CM-SG Threshold
Index /UCC D/U M/E/U/P/S
Ca7/0/0 2 48129 E 30 0xF8(0)/N 0 m/m 0x3C0101 5/10/70/70/50
Router# show cable load-balance docsis-group fn 2 md cable 7/0/0 all

MD FN Group S Intv DCC mask Policy Mtd MD-CM-SG Threshold
Index /UCC D/U M/E/U/P/S
Ca7/0/0 2 48129 E 30 0xF8(0)/N 0 m/m 0x3C0101 5/10/70/70/50
Current load:
DOCSIS load-balancing load
Interface State Group Utilization Rsvd NBCM WB/UB Flows Weight
Index Total Total
Cable7/0/0 (333 MHz) up 48129 0%(0%/0%) 0% 2 8 7 37
Cable7/0/0/U0 up 48129 0% 0% 22 7 29 7.6
Cable7/0/0/U1 up 48129 0% 0% 21 8 28 7.6
Cable7/0/0/U2 up 48129 0% 0% 21 8 28 7.6
Cable7/0/0/U3 up 48129 0% 0% 20 10 30 7.6
Mo1/0/0:0 (501 MHz) up 48129 0%(0%/0%) 0% 2 63 2 36
Mo1/0/0:0/U0 up 48129 0% 0% 22 7 29 7.6
Mo1/0/0:0/U1 up 48129 0% 0% 21 8 28 7.6
Mo1/0/0:0/U2 up 48129 0% 0% 21 8 28 7.6
Mo1/0/0:0/U3 up 48129 0% 0% 20 10 30 7.6
Mo1/0/0:1 (507 MHz) up 48129 0%(0%/0%) 0% 1 58 1 36
Mo1/0/0:1/U0 up 48129 0% 0% 22 7 29 7.6
Mo1/0/0:1/U1 up 48129 0% 0% 21 8 28 7.6
Mo1/0/0:1/U2 up 48129 0% 0% 21 8 28 7.6
Mo1/0/0:1/U3 up 48129 0% 0% 20 10 30 7.6
Mo1/0/0:2 (513 MHz) up 48129 0%(0%/0%) 0% 2 59 2 36
Mo1/0/0:2/U0 up 48129 0% 0% 22 7 29 7.6
Mo1/0/0:2/U1 up 48129 0% 0% 21 8 28 7.6
Mo1/0/0:2/U2 up 48129 0% 0% 21 8 28 7.6
254
Mo1/0/0:2/U3 up 48129 0% 0% 20 10 30 7.6

Mo1/0/0:3 (519 MHz) up 48129 0%(0%/0%) 0% 1 61 1 36
Mo1/0/0:3/U0 up 48129 0% 0% 22 7 29 7.6
Mo1/0/0:3/U1 up 48129 0% 0% 21 8 28 7.6
Mo1/0/0:3/U2 up 48129 0% 0% 21 8 28 7.6
Mo1/0/0:3/U3 up 48129 0% 0% 20 10 30 7.6
Target assignments:
Interface State Group Target
Index
Cable7/0/0 (333 MHz) up 48129
Cable7/0/0/U0 up 48129
Cable7/0/0/U1 up 48129
Cable7/0/0/U2 up 48129
Cable7/0/0/U3 up 48129
Mo1/0/0:0 (501 MHz) up 48129 Mo1/0/0:1 (507 MHz)
Mo1/0/0:0/U0 up 48129
Mo1/0/0:0/U1 up 48129
Mo1/0/0:0/U2 up 48129
Mo1/0/0:0/U3 up 48129
Mo1/0/0:1 (507 MHz) up 48129
Mo1/0/0:1/U0 up 48129
Mo1/0/0:1/U1 up 48129
Mo1/0/0:1/U2 up 48129
Mo1/0/0:1/U3 up 48129
Mo1/0/0:2 (513 MHz) up 48129
Mo1/0/0:2/U0 up 48129
Mo1/0/0:2/U1 up 48129
Mo1/0/0:2/U2 up 48129
Mo1/0/0:2/U3 up 48129
Mo1/0/0:3 (519 MHz) up 48129
Mo1/0/0:3/U0 up 48129
Mo1/0/0:3/U1 up 48129
Mo1/0/0:3/U2 up 48129
Mo1/0/0:3/U3 up 48129
Statistics:
Target interface State Transfers
Complete Pending Retries Failures
Cable7/0/0 (333 MHz) up 8 0 0 0
Cable7/0/0/U0 up 30 0 0 0
Cable7/0/0/U1 up 83 0 0 0
Cable7/0/0/U2 up 48 0 0 0
Cable7/0/0/U3 up 34 0 0 0
Mo1/0/0:0 (501 MHz) up 19 0 0 0
Mo1/0/0:0/U0 up 33 0 0 0
Mo1/0/0:0/U1 up 46 0 0 0
Mo1/0/0:0/U2 up 22 0 0 0
Mo1/0/0:0/U3 up 22 0 0 0
Mo1/0/0:1 (507 MHz) up 22 0 0 0
Mo1/0/0:1/U0 up 9 0 0 0
Mo1/0/0:1/U1 up 19 0 0 0
Mo1/0/0:1/U2 up 15 0 0 0
Mo1/0/0:1/U3 up 21 0 0 0
Mo1/0/0:2 (513 MHz) up 21 0 0 0
Mo1/0/0:2/U0 up 4 0 0 0
Mo1/0/0:2/U1 up 3 0 0 0
Mo1/0/0:2/U2 up 6 0 0 0
Mo1/0/0:2/U3 up 7 0 0 0
Mo1/0/0:3 (519 MHz) up 9 0 0 0
Mo1/0/0:3/U0 up 1 0 0 0
Mo1/0/0:3/U1 up 2 0 0 0
Mo1/0/0:3/U2 up 4 0 0 0
Mo1/0/0:3/U3 up 4 0 0 0
Pending:
Modem Grp Idx Primary RF/RCC MD/TCS Action Active Retries
255
Src Target Src Target Time
Description Link
ID and password.
Feature Information for DOCSIS Load Balancing Groups

Table 36: Feature Information for DOCSIS Load Balancing Groups
DOCSIS Load Balancing Groups Cisco IOS XE Fuji 16.7.1 This feature was integrated on the
cisco cBR Series Converged
Broadband Routers.
Load Balancing with Operational Cisco IOS XE Gibraltar 16.10.1d. This feature was integrated on the
Simplification cisco cBR Series Converged
Broadband Routers.
256
CHAPTER 17
DOCSIS Load Balancing Movements
Cisco CMTS supports static load balancing for MTC/MRC modems and dynamic load balancing for non-MTC
and/or non-MRC modems. Support for configuration of load balancing groups (LBGs) that entail multiple
interfaces, multiple load balancing policies, and the option to configure multiple additional load balancing
parameters are also included.
The load balancing policies can be configured on the Cisco CMTS, indexed by an ID, to limit the movement
of cable modems within a Load Balancing Group (LBG). The cable modem will forward TLV43.1in its
registration request (REG-REQ) message, which is then parsed and stored in the Cisco CMTS. A policy
defines whether and when cable modems can be moved within their load balancing groups.
During dynamic load balancing, the specified policy of the cable modem is checked to determine whether the
cable modem is allowed to move.
Load balancing supports Dynamic Channel Change (DCC). DCC in DOCSIS 1.1, dynamically changes cable
modem upstream or downstream channels without forcing a cable modem to go offline, and without
re-registration after the change.
Load balancing distributes downstream load balancing with upstream channel loads in the same upstream
load balancing group. This improves upon the prior load balancing limitation, in which load balancing was
implemented on the basis of the entire downstream channel load.
Load balancing uses rules and policies to decide on moving the cable modems within their LB groups. These
policies are created on the Cisco CMTS and chosen on a per-CM basis using type-length-value (TL V) portion
(43.1,Policy ID) of REG-REQ. These policies prohibit a modem from being moved or restricted.
A policy contains a set of rules. When the policy is defined by multiple rules, all rules apply in combinations.
A rule can be defined as "enabled" , "disabled" , or "disabled during time period. " Each rule can be used by
more than one policy.
DOCSIS 3.0 static modem count-based load balancing uses the dynamic bonding change (DBC) to modify
the following parameters of DOCSIS 3.0 cable modem with multiple transmit channel (MTC) mode or multiple
receive channel(MRC) mode without primary channel change:
• Transmit channel set (TCS)
• Receive channel set (RCS)
• Downstream IDs (DSID) or DSID-associated attributes
• Security association for encrypting downstream traffic
These parameters and additional load balancing schemes are supported on the Cisco CMTS, and described
in this document. This document describes all implementations of load balancing on the Cisco CMTS,
dependent upon the Cisco IOS release installed and the desired parameters.
257
• Prerequisites, on page 260
• Restrictions, on page 260
• Information on the Load Balancing on the Cisco CMTS, on page 265
• How to Configure Load Balancing, on page 280
• How to Configure Dynamic Channel Change for Load Balancing, on page 283
• Configuration Examples for Load Balancing, on page 289
• Feature Information for DOCSIS Load Balancing Movements, on page 293
258
Digital PICs:

Module:

Modules:
line card reload.
259
Prerequisites
Prerequisites
Prerequisites for Load Balancing
The Load Balancing feature has the following prerequisites:
• Load balancing can be done only on upstreams and downstreams that share physical connectivity with
the same group of cable modems.
Prerequisites for Dynamic Channel Change for Load Balancing

• DCC can be done only to a cable modem that is physically connected to both source and target upstream
or downstream channels, or both.
• Upstreams and downstream channels that share the same physical connectivity must have different center
frequencies separated by channel width.
• The difference between the physical layer parameters on the source and target DCC channels must be
within the threshold required by the desired DCC initialization technique.
• DOCSIS 1.1 must be enabled for a modem to behave properly for the DCC operation. Note that not all
DOCSIS 1.1 certified modems are DCC-capable, as the CableLabs DCC ATP tests need enhancement
for complete coverage.
Prerequisites for Dynamic Bonding Change for DOCSIS 3.0 Static Modem
Count-Based Load Balancing
• Initialization techniques 1 to 4, when used, require the Cisco CMTS to include the upstream channel
descriptor (UCD) TLV (TLV46.5) in the DBC-REQ message.
• Bandwidth must be sufficient on the target bonding group to support DBC. This is determined by the
admission control APIs.
• Fiber nodes must be configured before configuring DOCSIS 3.0 static modem count-based load balancing.
Restrictions
The following sections describe the restrictions applicable for the Load Balancing, Dynamic Channel Change,
and Dynamic Bonding Change feature:
Restrictions for Load Balancing

The Load Balancing feature has the following restrictions:
• Load balancing can be done only on a per-line card basis—all interfaces in a load balancing group must
be provided by the same line card.
260
Restrictions for Load Balancing
• All downstreams and upstreams in a load balancing group must share physical connectivity to the same
group of cable modems. All downstreams or all upstreams that have the same RF physical connectivity
must be members of the same load balancing group.
• You can create a maximum of 256 load balancing groups on each line card.
• If an upstream port is operational, using the no shutdown command, and is not being used and not
connected, load balancing attempts to use the port even though there are no cable modems registered on
that port. When the upstream port is up, it is put into INIT state and load balancing includes this port as
a potential target. However, if the load balancing sees multiple failures moving to this upstream, it is set
to DISABLE state and the port is avoided later on in load balancing processes.
• The load balancing algorithms assume a relatively even distribution of usage among modems. In the
situation where one cable modem creates the bulk of the load on an interface, the load balancing thresholds
should be configured for a value above the load created by that single modem.
• You cannot select particular cable modems to be automatically moved for load balancing, although you
can exclude cable modems from load balancing operations altogether on the basis of their MAC address
or organization unique identifier (OUI). (You can use the test cable load-balance command to manually
move a particular cable modem among upstreams, but this is done typically to test the configuration of
the load balancing groups.)
• If you have configured upstream shared spectrum groups while doing downstream load balancing, the
downstream in each MAC domain must not use overlapping upstream groups. For example, the
downstream in one MAC domain could use an upstream spectrum band of 10 to 30 MHz, while the
downstream in a second MAC domain could use an upstream spectrum band of 30 to 42 MHz. Each
MAC domain has its own upstream shared spectrum group, allowing the load balancing group to contain
the downstreams for both MAC domains.
• All upstream ports coming from the same splitter must be using different center frequencies that are
separated by the channel width. For example, if the upstreams are using a channel width of 3.2 MHz,
the center frequencies for all upstreams must be separated by at least 3.2 MHz.
• You can use four initialization techniques for Dynamic Channel Change (DCC).
• If you have configured load balancing, the provisioning system must not assign specific upstream channels
or downstream frequencies to individual cable modems in their DOCSIS configuration files. Any cable
modems requiring specific upstream channels or downstream frequencies must be excluded from load
balancing operations (using the cable load-balance exclude command).
• Do not use the utilization method of load balancing on cable interfaces that have a small number of cable
modems and where a single modem is responsible for the majority of the interface load. In this condition,
the Cisco CMTS could end up continually moving cable modems from one interface to another in an
endless attempt to load balance the interfaces. To avoid this, configure the utilization threshold to a value
that is higher than what can be caused by any single cable modem.
• When deployed with channel restriction features, if the target upstream channel attribute masks are
against that of the cable modem, then the cable modem on the higher load upstream will not be load
balanced, as the current load balancing moves cable modems only to the target upstream. However, cable
modems that do not have an attribute mask can still be load balanced. You should consider the following
while deploying the load balancing groups: the target upstream will always be the upstream that has the
lowest load. If some other upstreams have the same load, the upstream with the lowest index will be
chosen as the target upstream.
• A TLV in a cable modem configuration file restricts dynamic load balancing on per modem basis.
261
Restrictions for Dynamic Channel Change for Load Balancing
• If you remove the last rule of a DOCSIS policy, the policy itself will be removed.
• The Cisco CMTS load balancing feature moves a cable modem based on the load of the channels in a
load balancing group, without checking if the cable modem supports the extended frequency range
(5Mhz-85Mhz). This may result in moving a cable modem that supports standard frequency range
(5Mhz-65Mhz) to a channel that has extended frequency configured. To overcome such scenarios,
operators should not mix upstreams that have standard and extended frequencies configured into the
same load balancing group, unless all modems in the group support extended frequency range.
Restrictions for Dynamic Channel Change for Load Balancing

• The source and target upstreams and downstreams must share physical connectivity with the modem
desired for a DCC transaction.
• Independent downstream change is not supported, and cross-MAC domain upstream changes must occur
with the associated downstream changes.
• The source and target downstream interfaces must belong to the same virtual bundle and the same load
balancing group if DCC is used for load balancing.
• For DCC initialization techniques 1 to 4, all the configuration variables of the cable modem must remain
constant with the exception of the configuration variables that are explicitly changed by the Dynamic
Channel Change request (DCC-REQ) messages encoding.
• DCC initialization techniques 2 to 4 must not be used if the propagation delay differences between the
old and new channels exceeds the ranging accuracy requirement defined in DOCSIS, for example, ±0.25
usec plus ± symbol time.
For example, for a symbol rate of 1.28 Msps, the timing offset difference between the source and target
upstream channel is ± floor[(0.250 us + 0.5*0.781us)/(1/10.24)] = ± 6.
• The attenuation or frequency response differences between the old and new upstream channels causes
the received power at the Cisco CMTS to change by more than 6 dB.
• DCC initialization technique 3 must not be used if the conditions for using technique 2 are not met.
• DCC initialization technique 4 must not be used if the conditions for using technique 2 cannot be met.
• Micro-reflections on the new upstream channel result in an unacceptable BER (greater than 1e-8) with
pre-equalization coefficients set to the initial setting.
• DCC is used only for dynamic downstream load balancing on DOCSIS 1.1 and later CMs. Upstream
Channel Change (UCC) is always used for dynamic upstream load balancing on DOCSIS 1.x CMs. For
DOCSIS 2.x CMs, UCC is used when the ucc option is configured. For DOCSIS 3.x CMs, DCC is used
irrespective of whether the ucc option is configured or not.
• Prolonged interruption of the multicast traffic is expected if the cable modem moved by DCC is the first
one in a dynamic multicast group on the target interface. The downstream multicast service flow cannot
be reestablished until the Cisco CMTS receives an Internet Group Management Protocol (IGMP) join
message from the customer premises equipment (CPE) as the result of the Cisco CMTS IGMP query,
where the IGMP query interval is set to one minute. This is an IGMPv2 limitation.
• Multiple statically-assigned IP addresses to a CPE can be pinged. However, this works only if all the
security features, such as verification of IP addresses for cable modems and CPE devices on the upstream,
and other security mechanism are disabled.
262
DCC Restrictions with N+1 Redundancy and Inter-Card Load Balancing
• The TCS and RCS assigned to the DOCSIS 3.0 cable modems are restricted by the upstream and
downstream bonding groups configured by the Cisco CMTS.
• Load balancing and DCC are not supported for CMs that are enabled for Layer 2 VPN (L2VPN) support.
• When a DCC occurs, the cable modem US and DS counters are reset. The US and DS counters include
counters such as data and throughput seen in the show cable modem (mac-address) verbose command
output and packets and bytes seen in the show cable modem (mac-address) counters command output.
DCC Restrictions with N+1 Redundancy and Inter-Card Load Balancing

• Inter-card load balancing is not supported with cable interface line cards using N+1 redundancy. Refer
to general DCC restrictions for additional information.
• Dynamic load balancing should not be used together with N+1 redundancy. Cable modems with
outstanding DCC transactions go offline after a switchover event.
Note When cable modems go offline during a switchover event, the load balancing
feature activates. Cable modems move in relation to the switchover event. When
the cable modems return online, load balancing may need to initiate again.
To facilitate load balancing during a switchover, you can increase the dynamic
load balance threshold, if a certain percentage of cable modems that reset during
switchover is configured in the system. An alternate method is to use static load
balancing with N+1 redundancy. For more information, see the Types of Load
Balancing Operations.
Restrictions for DOCSIS 3.0 Static Modem Count-Based Load Balancing

• Static modem count-based load balancing is supported on MTC and MRC-only cable modems.
Single-channel, narrowband cable modems will continue to be supported with dynamic load balancing.
MRC-only modems are supported by dynamic load balancing on upstream channels.
Note DOCSIS 3.0 static modem count-based load balancing is not supported on:
• Multiple line cards.
• Load balancing groups and downstream channels shared across multiple
line cards.
• DOCSIS 3.0 static modem count-based load balancing does not support service flow method of load
balancing.
263
Restrictions for Dynamic Bonding Change for DOCSIS 3.0 Static Modem Count-Based Load Balancing
Restrictions for Dynamic Bonding Change for DOCSIS 3.0 Static Modem Count-Based Load
Balancing
• The Cisco CMTS can use only DBC messaging to move modems within a MAC domain and applies
only to cable modems operating in MTC mode or MRC-only mode without a primary downstream change.
• The Cisco CMTS moves the MRC-only cable modems with a primary channel change using DCC with
initialization technique 0.
• The Cisco CMTS moves cable modems across MAC domains using only DCC with initialization technique
0.
• The Cisco CMTS must ensure minimum interruption to existing QoS services while considering an
initialization technique that is suitable for the cable plant conditions.
Note DOCSIS 3.0 Static Load Balancing uses Initialization Technique 1 to move cable
modems for DBC movement.
• Initialization Technique 1—(Broadcast initial ranging) may result in a lengthy interruption of service,
which is mitigated by the reservation of QoS resources on the new channel(s). The service interruption
can be further reduced if the Cisco CMTS supplies the UCD TLV in the DBC request in addition
to providing more frequent initial ranging opportunities on the new channel.
• Initialization Technique 2—(Unicast ranging) offers the possibility of only a slight interruption of
service. To use this technique, the Cisco CMTS must include the UCD TLV in the DBC message
if the upstream channel is changing.
• Initialization Technique 3—(Broadcast or unicast ranging) offers the possibility of only a slight
interruption of service. Use this technique when there is uncertainty when the CM may execute the
DBC command and thus a chance that it might miss station maintenance slots. However, the Cisco
CMTS should not use this technique if the conditions for using techniques 1 and 2 are not completely
satisfied.
• Initialization Technique 4—(Use the new channel directly) results in the least interruption of service.
• For a DOCSIS 3.0 cable modem that in a DOCSIS 3.0 static load balancing group, the multicast join
will be dropped before REG-HOLD time elapses.
Restrictions for MRC-Only Cable Modems

• MRC-only cable modems use single channel non-bonded upstreams (similar to narrowband (NB) modems)
and multi-channel bonding groups on the downstream.
Note The following restrictions apply only to DOCSIS 2.0 and DOCSIS 3.0 cable
modems in MRC-only mode.
• cable modems are moved across upstream channels using DCC.
264
Information on the Load Balancing on the Cisco CMTS
• cable modems are moved to different downstream channels through DBC, if there is a change in the
upstream channel and downstream channel bonding group, but not in the primary downstream channel
and the upstream channel change is ignored.
However, if there is a change in the primary downstream channel also, DCC with init tech 0 is used to
balance the cable modems.
• MRC-only modems are treated similar to cable modems operating in MTC mode, to move modems
across downstream channels. For change in upstream channel, MRC-only cable modems are treated
similar to single-channel NB cable modems.
Information on the Load Balancing on the Cisco CMTS

This section describes the operation, concepts, and benefits of the Load Balancing on the Cisco CMTS feature:
Feature Overview
The Load Balancing on the Cisco CMTS feature allows service providers to optimally use both downstream
and upstream bandwidth, enabling the deployment of new, high-speed services such as voice and video
services. This feature also can help reduce network congestion due to the uneven distribution of cable modems
across the cable network and due to different usage patterns of individual customers.
By default, the Cisco CMTS platforms use a form of load balancing that attempts to equally distribute the
cable modems to different upstreams when the cable modems register
This feature has been enhanced to make use of DOCSIS policies and rules to limit the movement of cable
modems within a Load Balancing Group. A policy defines whether and when cable modems can be moved
within their load balancing groups.
A policy consists of a set of rules. Each rule can be defined as “enabled”, “disabled”, or “disabled during time
period.” Multiple policies can share a single rule. However, if you remove the last rule of a policy, that will
also remove the policy.
Each rule can be used in any number of policies. When it is defined by multiple rules, all rules apply in
combinations. Each rule helps to prohibit load balancing using a particular cable modem and to prohibit load
balancing using a particular cable modem during certain times of the day.
Following are the general guidelines for the rules and policies:
• The policy or rule is recognized by a 32-bit ID.
• Each cable modem can have one policy only.
• Each rule can be associated to one or more policies.
• Each policy is described by at least one rule, otherwise it cannot be created.
• The zero Policy ID is reserved by Cisco CMTS indicating “Do nothing to LB prohibition.”
• If the policy ID specified by the cable modem configuration file is not configured on Cisco CMTS, no
LB prohibition is applied to that CM. However, after the policy with the matched ID is configured, LB
prohibition takes effect immediately.
265
Methods to Determine When Interfaces Are Balanced
Methods to Determine When Interfaces Are Balanced

In addition to selecting how interfaces should be balanced (using the static, passive, or dynamic types of load
balancing), you can also select one of the following methods that the Cisco CMTS should use to determine
when interfaces are balanced:
• Modems Method—Uses the number of active cable modems on an interface.
• Utilization Method—Uses the current percentage of utilization of an interface.
See the following sections for more information about each method.
Modems Method
The modem method of load balancing uses the number of active cable modems on an interface to determine
the current load. This is a form of distribution-based load balancing, in which the absolute numbers of modems
are used to determine whether interfaces are load balanced.
This method does not take into account the amount of traffic flowing through the cable modems, but the
system does take into account the relative bandwidth of the channels being used, so that channels with higher
bandwidths are allocated higher numbers of cable modems. This means that when interfaces are using different
channel widths or modulation profiles, the system can assign different numbers of cable modems to the
interfaces to achieve a balanced load. For example:
• Channel widths— If two upstreams are being load balanced, and one upstream is configured with a
channel width of 1.6 MHz and the other upstream is configured for a channel width of 3.2 MHz, the
Cisco CMTS allocates twice as many cable modems to the second upstream because its channel width
is twice as large as the first upstream channel width.
• Modulation profiles— If one downstream is configured for 64-QAM and the other downstream is
configured for 256-QAM, the Cisco CMTS allocates a proportionately larger number of cable modems
to the second downstream so as to achieve a balanced load.
When both the channel width and modulation profile are set differently on two interfaces, the system calculates
a “weight” value to use as a guide to determine the relative bandwidths of the interfaces.
Tip In a system with balanced loads, the interfaces will contain the same number of cable modems only when the
interfaces are configured with the same channel width and modulation parameters.
Utilization Method
Note Narrowband cable modems, multiple downstream modems and upstreams of MRC-only cable modems
participate in the utilization method.
The utilization method uses an interface’s current percentage of utilization to determine the current load. This
method uses the amount of traffic being sent over an interface, in the form of the percentage of total bandwidth
being used. The system takes into account the relative throughput and bandwidth (as determined by the
modulation profiles and channel widths) of each interface when evaluating the load on those interfaces.
266
Load Balancing Parameters
For example, if two upstreams are being load balanced using the utilization method, and the first upstream
has twice the bandwidth of the second upstream, the two upstreams are considered balanced when they reach
the same percentage of utilization. The first upstream is carrying more traffic than the second upstream because
it has a larger capacity for traffic, but the percentage of utilization will be the same.
Wideband Interface Average Utilization and Throughput

The average utilization and average throughput between Wideband interfaces of the same size can be calculated
by:
Average Utilization (WB) = ∑ni-1rfch - util(rfi)/n
• n represents the size of the Wideband interface
• ∑ni-1rfch - util(rfi) represents the sum of rfch - util of QAM channels in Wideband interface.
Average Throughput (WB) = AverageThroughput(WB)in last 30s/∑ni=1BW(rfi)
• Average Throughput (WB) represents the KB recorded in the last 30 seconds
• ∑ni=1BW(rfi) represents the total bandwidth of Wideband interface.
Note Use the show cable load-balance load wideband command to view the average utilization and average
throughput between Wideband interfaces.
Load Balancing Parameters

You can determine which cable interfaces should participate in load balancing operations. You can also choose
which of the following methods should be used to determine the current load on a cable interface, and therefore
determine whether cable modems should be moved:
• Number of active cable modems
• Channel bandwidth utilization
You can also specify the threshold values that the Cisco CMTS should use to determine how to assign new
cable modems to upstreams and downstreams for both types of load balancing. You can also configure whether
cable modems with active Voice-over-IP (VoIP) calls should be moved, and if so, what thresholds should be
used. You can also exclude certain cable modems from one or all of the different forms of load balancing.
Configurable Minimum Threshold under Utilization Method

The utilization method does not move cable modems for load balancing until the utilization of at least one of
the interfaces reaches minimum threshold. This is done to avoid the unnecessary moving of cable modems
due to temporary spikes in an interface's utilization rate.
Minimum utilization threshold can be configured under Utilization Method. The minimum utilization threshold
may be configured in a range of 10 to 90 percent. As a result the cable modems will be moved only when the
configured minimum utilization threshold is reached on an interface.
To configure the minimum threshold under the Utilization method, use the cable load-balance
method-utilization min-threshold command in global configuration mode. For more information, refer to
cable load-balance method-utilization min-threshold command reference.
267
Single Channel Load Balancing
Single Channel Load Balancing

Error Handling of Channel Assignment
As long as the interface state of the channels is not "administratively down", all channels are available for
LBG assignment. For other load balancing operations, such as moving modems using DCC, or UCC, the
interface state of the channels should be in "initial", "up", "suspicious", or "testing" states.
Downstream Load Balancing Distribution with Upstream Load Balancing

Downstream load balancing provides equalized load balancing with upstream group members. This enhancement
synchronizes the “pending” statistic between different cable interface line cards in the load balancing group.
The result is an alternative downstream load balancing scheme that makes use of per-upstream loads rather
than total downstream loads.
This enhancement performs downstream load balancing that accounts for upstream channel loads in the same
upstream load balancing group, rather than on the basis of the entire downstream channel load. Prior Cisco
IOS releases may not have distributed cable modems evenly over individual upstream channels, nor in a way
that accounted for downstream and upstream together.
The load balancing enhancement applies when downstream load balancing occurs on a headend system with
separate upstream load balancing segments; the upstream segments are spread over multiple downstream
segments.
The configuration and operation of making downstream load balancing decisions is enabled as follows:
• The target downstream segment is in the same downstream load balancing group as the source downstream
segment.
• The upstream load balancing group can be set for the corresponding channel on which a cable modem
is balanced.
• The Cisco CMTS automatically locates the upstream segment for a load balancing group and processes
the upstream group status on the source interface that has the lowest load.
• The target downstream segment must have an upstream channel set in the upstream load balancing group.
• The highest target upstream segment must carry less load than any other potential target—the highest
upstream segment on other interfaces.
For example, several upstream segments can be configured across multiple downstream segments as follows:
U0 U1 U2 U3 Downstream
3/0 LB10 LB11 LB12 LB13 LB1
4/0 LB10 LB11 LB12 LB13 LB1
5/0 LB10 LB11 LB12 LB13 LB1
6/0 LB10 LB11 LB12 LB13 LB1
In this example, a cable modem that comes online on the interface cable 5/0 Upstream 2 could potentially
come online on the following interfaces:
• cable 3/0 upstream 2
268
The enhancement enables the following advantages and behaviors:

• This enhancement adds support for synchronizing the “pending” statistic between different cable interface
line cards and the network processing engine (NPE) so that a better decision can be made about where
cable modems should be moved. This function can be used as a normal downstream load balancing
implementation, if desired.
• This enhancement adds the us-groups-across-ds keyword to cable load-balance group command for
configuring downstream load balancing groups with upstream resources.
Note You can use the no cable load-balance docsis20-enable command to disable DOCSIS 2.0 dynamic
downstream and upstream load balance.
The upstream load balancing functionality enables the Cisco CMTS router to effectively handle upstream
traffic for wideband and narrowband cable modems that are in single upstream mode. Single upstream mode
(Mx1) means that the modems cannot send upstream traffic on multiple upstream channels. In the event of
traffic overload on a single upstream channel of a wideband or narrowband cable modem, the Cisco CMTS
router automatically moves the cable modem to another upstream channel in the same load balancing group.
Note A cable modem operating in single upstream mode is assigned to a load balancing group based on the primary
channel of the modem. A cable modem in single upstream mode can support multiple receive channel (MRC)
mode or narrowband mode. However, a cable modem in single upstream mode cannot support multiple transmit
channel mode (MTC).
Interaction with Spectrum Management

Cisco cable interface line cards support a number of features to maximize channel bandwidth and to minimize
the impact of ingress noise on cable modem traffic. These features have the following impacts upon load
balancing operations:
• Frequency hopping—Frequency hopping does not affect the load balancing algorithm, because it does
not change either the bandwidth of a channel nor the number of cable modems on an interface.
• Dynamic modulation changes—The dynamic modulation feature affects the load balancing algorithm
because it typically switches an interface from a higher-bandwidth modulation profile to a lower-bandwidth
modulation profile in response to noise conditions on the interface.
For example, if an upstream is configured for 16-QAM, sufficient noise levels could switch the upstream
to a QPSK modulation profile. Depending on the load balancing configuration, this could then result in
the movement of cable modems to other channels. Similarly, when the noise conditions improve, and
the modulation is returned to the original, higher-bandwidth profile, the cable modems could be moved
again to rebalance the upstream channels.
• Channel width changes—Cisco cable interface line cards support automatic changes to the channel width
in response to noise conditions. Because changing the channel width affects the throughput of a channel,
this also affects the load balancing algorithm.
269
Using Dynamic Channel Change
For example, if noise makes the current channel width unusable, the Cisco cable interface line card
reduces the channel width until it finds a usable channel width. Because this reduces the available
bandwidth on the channel, the load balancing algorithm moves cable modems to rebalance the upstreams.
In addition, the Cisco cable interface line card does not automatically restore the original channel width
when noise conditions improve. Instead, the card changes the channel width only when it performs a
subsequent frequency hop, either in response to additional noise conditions or when an operator performs
a manual frequency hop. When the hop occurs, the card then searches for the largest possible channel
width, and this could result in another movement of cable modems to rebalance the channels.
Using Dynamic Channel Change

DCC in DOCSIS 1.1 dynamically changes cable modem upstream or downstream channels without forcing
a cable modem to go offline, and without re-registration after the change. DCC supports five different
initialization methods (0-4).
• Load balancing techniques allow for moving cable modems with DCC by using configurable initialization
techniques.
• DCC allows line card channel changes across separate downstream channels in the same cable interface
line card, with the DCC initialization techniques ranging from 0 to 4.
• DCC transfers cable modem state information from the originating downstream channel to the target
downstream channel, and maintains synchronization of the cable modem information between the cable
interface line card and the Network Processing Engine (NPE) or Route Processor (RP).
• Applications that are sensitive to delay , such as PacketCable (PC) and PacketCable Multi Media (PCMM),
may use DCC initialization technique4 to retain services while the cable modem is performing DCC.
• If the channel is in mixed or ATDMA-only mode, the primary Service Identifier (SID) must be switched
to ATDMA-only mode.
Note You can use the no cable load-balance docsis20-enable command to disable DOCSIS 2.0 dynamic
downstream and upstream load balance.
Multiple Channel Load Balancing

Algorithm for Bonded Channel Cable Modem Load Balancing
During registration of the cable modem, the modem count-based method uses the number of active cable
modems on the allowed RCS to determine the current load on each channel. After the modem is assigned an
RCS, the Cisco CMTS does not move the cable modem even when traffic conditions change.
When a cable modem sends a registration request, modem count-based method of load balancing ranks the
allowed receive channel sets (RCS) based on their modem count and assigns the set with the lowest number
of CMs, to the ranging cable modem.
DOCSIS 3.0 Static Modem Count-Based Load Balancing

The static modem count-based load balancing supports the following:
• DOCSIS General and Restricted load balancing group assignment to include DOCSIS 3.0 cable modems
in MTC and MRC-only modes.
270
DOCSIS 3.0 Static Modem Count-Based Load Balancing
Note DOCSIS 3.0 static modem count-based load balancing is not supported:
• Across multiple line cards.
• For load balancing groups and downstream channels shared across multiple
line cards. However, autonomous load balancing-based CM steering and
load balancing group assignment is supported across multiple line cards
• Use of DCC and DBC in load balancing.

• Use of DBC for MRC-only modems during downstream move.
• Use of DCC with init tech 0 if the primary downstream channel is changed for MRC-only CMs.
• Use of DBC for cable modems in MTC mode for all upstream and downstream modem move.
• Separate counters for NB and wideband (WB)/upstream bonding (UB) CMs. For more information, see
the show cable load-balance docsis-group command in the Cisco IOS CMTS Cable Command Reference.
• Aggregate logical channels to physical channels for load balancing. Physical channel load is calculated
by using average weights among all logical channels.
• Non-primary downstream channels load where utilization of SPA QAM is considered
Note When the CM counts across different WB interfaces are within predefined threshold levels, the load is always
considered as balanced; no more CM move is initiated by the LB system. No service flow count, whether
primary or secondary, is taken into consideration during this LB process.
Note The attributes considered for the forward interface for the service flow (SF) are attribute mask and available
bandwidth, and not the number of service flows on each channel. If a channel is within the new RCS, then
irrespective of the type of narrowband SF, (whether primary or secondary, or static or dynamic) the SF
continues to use its current channel.
Note The US Phy Mode counters (scdma, atdma, and tdma) remain 0 for the UB interfaces.
DOCSIS 3.0 static modem count-based load balancing is based on legacy load balancing and supports any
type of channel combination (upstream and downstream)—MxN, with 1x1 combination being the subset.
DOCSIS 3.0 static modem count-based load balancing controls dynamic changes to the set of downstream
and upstream channels used by a registered CM. It supports the following:
• Multiple channel load balancing operation.
• Load balancing operation based on policies and priorities.
271
Primary Channel Load Display for Target RCS
• Load balancing with multicast. DOCSIS 3.0 static modem count-based load balancing does not move
any CM with active video sessions.
DOCSIS 3.0 static modem count-based load balancing supports the modem count-based load balancing in a
hybrid deployment of DOCSIS 1.x, 2.0 and 3.0 cable modems.
Static modem count-based load balancing is supported only for DOCSIS 3.0 CMs. Single-channel, narrowband
cable modems will continue to be supported with dynamic load balancing. MRC-only cable modems are
supported by dynamic load balancing on upstream channels.
With DOCSIS 3.0 static modem count-based load balancing, when load balancing related configuration within
the LBG is changed as follows, the cable modems are forced to re-register:
• Partial shut or no shut interfaces under the LBG domain
• MRC or MTC mode in cable modems is turned on or turned off
• Change in fiber node for GLBG
• Change in wideband configuration for downstream group
• Change in the upstream bonding group
Use the following commands to force cable modems to re-register:

• clear cable modem delete
• clear cable load state
• clear cable load counters
Primary Channel Load Display for Target RCS

This feature enables the bonded modems to be moved at the time of registration such that the primary channels
are distributed evenly among the primary-capable channels apart from the load being balanced on the target
DS channels. Modem method ranks the RCS based on their primary loads and assigns the set with the lowest
primary load to the ranging cable modem.
An optional keyword primary-load has been added to the show cable load-balance docsis-group command
to display the primary load of an RCS. For more information, see the Cisco CMTS Command Reference.
Although the modem count-based method distributes the cable modems fairly as they register, the following
conditions may cause a system imbalance:
• A channel or groups of channels fail because of a planned (administrative shutdown) or unplanned event.
• While some cable modems may continue to operate in partial mode, some may re-register because of
the failure and are reassigned to the channels that are active.
• When the failed channels become operational again, the cable modems do not re-register and the system
is unbalanced.
In this case, the modem count-based method sends an SNMP trap to alert the operator, and the operator can
choose to manually intervene to re-balance the cable modems by resetting the MAC domain to force all cable
modems to re-register.
272
Dynamic Load Balancing for DOCSIS 3.0 Cable Modems
Note For cable modems in MRC and MTC modes, the modem count based load balancing method considers the
number of active modems and service flows on the primary channels in the RCS and TCS of the cable modem.
Note Use no cable load-balance docsis30-enable static command to disable this feature.
Dynamic Load Balancing for DOCSIS 3.0 Cable Modems

The existing Load Balancing (LB) feature is enhanced to cope with the increase in the number of downstream
and upstream channels by Multi-Service Operators (MSO) and wider deployment of 16-channel, 24-channel
and multiple downstream channel Cable Modems (CMs). This enhancement allows the customer to better
utilize their available bandwidth. The enhancements made to the existing LB feature include:
• Utilization based Dynamic downstream LB for DOCSIS 3.0
• Support for DOCSIS 3.0 LB statistics
• Enable or Disable DOCSIS 3.0 LB feature
• Distribute the CM on all the primary channels for the target interface when performing DOCSIS 3.0 LB
dynamic movement. This feature is only used on DOCSIS 3.0 LB dynamic movement. It is disabled by
default. Use method utilization primary-distributed command in the DOCSIS load balancing group
mode to enable this feature. To disable this feature, use no form of this command or method utilization
us-method command.
Note Use cable load-balance docsis-enable command to enable this feature. In addition, use cable load-balance
docsis30-enable and cable load-balance docsis30-enable dynamic downstream command to enable dynamic
and utilization based dynamic downstream LB for DOCSIS 3.0 Cable Modems.
Multiple Channel Load Balancing Operation

CMs load balance in MRC and MTC modes. The following rules apply while load balancing CMs operating
in these modes:
• For CMs operating in MRC and MTC modes, DBC is used to move CMs across downstreams by changing
the RCS of the CM within same MAC domain.
CMs operating in MRC-only mode can be moved across upstreams only through a DCC request. However,
the Cisco CMTS uses DCC with initialization technique 0 (reinitializing the MAC domain) when changing
the downstream channel of a CM operating in MRC mode.
• During CM registration, the Cisco CMTS may send a multipart registration response (REG-RSP-MP)
message to include a TCC TLV encoding to the CM. This CM is marked as TCC-capable.
For CMs operating in MRC, non-MTC, non-TCC-capable mode, load balancing uses:
• DBC to change RCS of the CM
• DCC to change upstream channel of the CM
• For CMs operating in narrowband mode, DCC is used to move CMs within and across MAC domains.
273
The tables below provide a snapshot view of the load balancing methods and the operations used to move
bonded and non-bonded CMs:
Table 38: Load Balancing Method to Move Bonded and Non-bonded CMs
Modem Mode Load Balancing Load Channels Dynamic Service Charge

Method Balancing (Initialization Technique)
Counters
Within MAC Across

Domain MAC
Domains
DOCSIS 3.0 CM DOCSIS 3.0 static WB/UB DS DBC DCC init

in MTC mode modem tech 0
Note When
count-based load
DOCSIS
balancing
3.0 LB
(MCBLB)
is
DOCSIS 3.0 enabled,
dynamic load and the
balancing MTC
CM is
outside
RLBG,
CM is
moved
inside
RLBG.
DOCSIS 3.0 static WB/UB US DBC DCC init

modem tech 0
Note When
count-based load
DOCSIS
balancing
3.0 LB
(MCBLB)
is
enabled,
and the
MTC
CM is
outside
RLBG,
CM is
moved
inside
RLBG.
274

Counters
DOCSIS 3.0/D2.x DOCSIS 3.0 static WB/UB No change to the DBC DCC init
CMs in MCBLB primary DS channel tech 0
Note When
MRC-only mode
DOCSIS 3.0 DOCSIS
dynamic load 3.0 LB
balancing is
enabled
and CM
with all
DSs is
outside
RLBG,
CM is
moved
inside
RLBG.
Change to the primary DCC init tech 0 DCC init

DS channel tech 0
Note CM
with
primary
DS
outside
RLBG
moves
inside
RLBG
with
DOCSIS
2.0 LB.
DOCSIS 3.0 CMs DOCSIS 2.0 static NB US DCC DCC init

in MRC-only and dynamic tech 0
Note CM
mode MCBLB,
outside
dynamic
RLBG
utilization
moves
inside
RLBG
with
DOCSIS
2.0 LB.
275

Counters
D2.x CMs in DOCSIS 2.0 static NB US DCC/UCC DCC init

MRC-only mode and dynamic tech 0
Note CM
MCBLB,
outside
dynamic
RLBG
utilization
moves
inside
RLBG
with
DOCSIS
2.0 LB.
DOCSIS 2.0 DOCSIS 2.0 NB DS DCC DCC init

/DOCSIS 1.1 dynamic tech 0
Note CM
CMs in NB mode MCBLB,
outside
dynamic
RLBG
utilization
moves
inside
RLBG
with
DOCSIS
2.0 LB.
US UCC UCC
Note CM
outside
RLBG
moves
inside
RLBG
with
DOCSIS
2.0 LB.
276
Using DBC for DOCSIS 3.0 Load Balancing Movement

Counters
DOCSIS 1.0 in DOCSIS 2.0 NB DS Force reinitialize Force

NB mode dynamic CM reinitialize
MCBLB, CM
Note CM
dynamic
outside
utilization
RLBG
moves
inside
RLBG
with
DOCSIS
2.0 LB.
US UCC UCC
Note CM
outside
RLBG
moves
inside
RLBG
with
DOCSIS
2.0 LB.
Table 39: Using DCC/DBC to Load Balance Bonded and Non-bonded Cable Modems
Channel CM in MRC, MTC Mode CM in MRC, non-MTC Mode DOCSIS 1.1/2.0 CMs with DOCSIS 1.0 CMs with
Single US/DS Single US/DS
Upstream DBC DCC DCC UCC

(US)
Downstream DBC (within the same MAC DBC (within the same MAC DCC (within the same MAC Force reinitialize CM
(DS) domain) domain) domain)
DCC with initialization DCC with initialization DCC with initialization Force reinitialize CM
technique 0 when moving technique 0 when moving technique 0 when moving CMs
CMs across MAC domains CMs across MAC domains across MAC domains
Using DBC for DOCSIS 3.0 Load Balancing Movement

As part of the DOCSIS 3.0 specifications, at any time after registration, the Cisco CMTS uses the DBC
command to change any of the following parameters in a DOCSIS 3.0 CM:
• Receive channel set
• Transmit channel set
277
Using DBC to Change the Receive Channel Set
• DSID(s) or DSID associated attributes

• Security association(s) for encrypting downstream traffic
• Service Flow Cluster Assignments
Note Only RCS and TCS are used by the DOCSIS 3.0 load balancing.
Use the show cable load-balance docsis-group command to display the current, real-time statistics for load
balancing operations. For more information, see the Cisco IOS CMTS Cable Command Reference.
Using DBC to Change the Receive Channel Set

The Cisco CMTS can add, delete, or change the channels in the RCS of a cable modem by including a RCC
in the DBC-REQ.
If an RCS change affects the primary downstream channel of the cable modem, the cable modem is required
to re-register on its upstream channels.
If channels are deleted from the RCS, the Cisco CMTS may stop sending traffic on the downstream channel
to be removed, which may cause loss of traffic. The Cisco CMTS minimizes packet loss by duplicating traffic
on the new and old RCS until it receives a DBC-RSP from the cable modem.
Note For cable modems in MRC-only mode, a downstream channel move is initiated by a DBC message. However,
DCC initialization technique 0 is used if there is a change in the primary downstream channel.
Using DBC to Change the Transmit Channel Set

The Cisco CMTS can add, delete, or replace one or multiple channels in the TCS in a single DBC message.
Whenever the TCS of the cable modem changes, the CMTS appropriately modifies the service identifiers
(SIDs) associated with the affected service flows.
A change in the TCS is accompanied by a valid initialization technique.
Using DBC to Change the Downstream ID

Using DBC, the Cisco CMTS can change the following attributes of a downstream ID (DSID):
• Re-sequencing encodings:
• Downstream re-sequencing channel list—The CMTS can add, delete, and replace channels in the
DS re-sequencing channel list.
• DSID re-sequencing wait time—The CMTS can indicate a change in skew due to network or
configuration changes through DSID re-sequencing wait time.
• re-sequencing Warning Threshold

• CM-STATUS Hold-Off Timer for Out-of-range Events
• Multicast Encoding—The CMTS can initiate a DBC transaction to either add, deleted, or change attributes
of an existing multicast DSID:
278
Using DBC to Change the Security Association for Encrypting Downstream Traffic
• Client MAC Address

• Multicast cable modem interface Mask
• Group MAC Address
Using DBC to Change the Security Association for Encrypting Downstream Traffic
• The CMTS can initiate a DBC transaction to add or delete Security Associations (SA) used to encrypt
downstream traffic.
• The CMTS cannot send a DBC request to a cable modem that is not in the "Authorized" State.
• The CMTS can send a DBC request with an SA that uses a cryptographic suite unsupported by the cable
modem. However, if the cable modem receives a DBC request with an SA that it is not capable of using,
the cable modem rejects the DBC request.
Using DBC to Change the Service Flow SID Cluster Assignments

The Cisco CMTS uses the Service Flow SID Cluster Assignments TLV in the DBC request to assign new
channels to a service flow, remove channels from a service flow, or replace one channel with another for a
service flow.
Note Multiple actions can occur within a single DBC message.
Benefits of Load Balancing

The Load Balancing feature on the Cisco CMTS provides the following benefits to cable service providers
and their partners and customers:
• Provides a method that service providers can use for efficient bandwidth utilization, especially when
using multiple upstream channels per fiber node.
• Allows service providers to expand their networks in an efficient manner, avoiding the cost of having to
install additional fiber optic equipment and further segmenting the physical plant.
• Load balancing on downstream channels enables efficient bandwidth usage when using multiple
downstream channels per fiber node to enable Video over IP and other services that require high-bandwidth
real-time streams.
• Load balancing of upstream and downstream channels does not require any change to the provisioning
servers or to any DOCSIS configuration files.
• Load balancing of upstream and downstream channels does not require any administrator or user
intervention (such as manually resetting cable interfaces or manually rebooting cable modems).
• Allows service providers to equally balance their downstreams as cable modems register, so that cable
modems do not all attempt to register on the same downstream, resulting in many cable modems failing
to register and having to search for a new downstream.
• Cable modems can be moved among downstream and upstream channels without having to change any
network parameters in manual fashion, such as IP address.
279
Exclude Cable Modems from Load Balancing Groups
• Allows service providers to stay ahead of customers’ bandwidth demands by dynamically responding to
current load-usage conditions.
• Allows service providers to optimize the load balancing parameters for critical services, such as Voice
over IP (VoIP).
Exclude Cable Modems from Load Balancing Groups

Load Balancing Process
The load balancing process has two phases.
• Assignment phase.
When a modem is coming online in the assignment phase, the modem is moved to the load balance group
by assigning it a load balancing group (LBG) ID. The assignment phase occurs only when a modem is
coming online.
• Balancing phase.
In the balancing phase, a modem is re-assigned to an LBG to balance the load.
Excluding Cable Modems from Load Balancing

There are four options that are used to exclude cable modems from an LBG:
• The assignment option:
The assignment option is used to exclude a modem during the assignment phase. The modem is not
assigned an LBG and LBG ID is not displayed in the output of the show cable modem verbose command.
The assignment option cannot be used when a modem is already online.
• The static option:
The static option is used to exclude a modem during the Balancing phase. The modem is assigned to an
LBG with an LBG ID. The static option is used to exclude a modem during static load balancing.
• The enforce option:
The enforce option is similar to the static option, except that the enforce option is used to exclude a
modem during dynamic load balancing.
When a cable modem is excluded from load balancing using the assignment option, the cable modem is not
available for load balancing using the static or the enforce options.
• The strict option:
The strict option excludes a modem in both the phases of load balancing. When a modem is online
already, the strict option applies the static and the enforce options. It applies the assignment option
only when the modem comes online again.
How to Configure Load Balancing

To configure load balancing groups, and to enable load balancing, refer to the configurations in the DOCSIS
Load Balancing Groups document. Each task is marked as required or optional, as appropriate.
280
Enabling Single Channel Load Balancing
Enabling Single Channel Load Balancing

To configure Single Channel Load Balancing, see the DOCSIS Load Balancing Groups guide.
Configuring Dynamic Bonding Change for DOCSIS 3.0 Static Load Balancing
Use the cable load-balance docsis30-enabled command in the global configuration mode, to enable DOCSIS
3.0 Static Load Balancing.
Note DOCSIS 3.0 Static Load Balancing always uses Modem Count Method for load balancing.
Before you begin

Configure Load Balancing Groups. For more details, see the DOCSIS Load Balancing Groups guide.
Excluding Cable Modems from a Load Balancing Group

This configuration is optional. This section describes how to exclude a particular cable modem, or all cable
modems from a particular vendor, from participating in static or dynamic load balancing operations, and
optionally marking the modems for passive load balancing. This task is optional, because, by default, cable
modems on an interface participate in whatever load balancing operations have been configured.
Note This step might be required for some cable modems that are not DOCSIS-compliant. Such cable modems can
go offline for long periods of time when load balancing is attempted using DOCSIS MAC messages. If this
is the case, use the cable load-balance exclude command to exclude such cable modems from load balancing
operations until the modem can be upgraded to DOCSIS-compliant software.
Tip You must exclude cable modems that require specific upstream channels or downstream frequencies. Load
balancing cannot be done when cable modems are assigned specific channels or frequencies in their DOCSIS
configuration files.
Support for Excluding Old Devices

Load balancing for old cable devices like Set Top Boxes (STBs) which do not support load balancing, will
fail. In the output for show cable load-balance group command, these devices will show as 'suspicious' and
then as 'disabled'. This will disrupt normal operations of other modems in the load balancing group. To exclude
these STBs, a cable load-balance exclude command is configured to exclude each STB.
281
Distributing Downstream Load Balancing with Upstream Load Balancing
Note You can configure the cable load-balance exclude command once to exclude all the STBs, that do not support
load balancing, instead of configuring the command several times with matched MAC addresses. You can
also move cable modems that were moved to a load balancing group in assignment phase.
The cable load-balance exclude modem command is modified to include the mask argument as an optional
argument. The MAC address of a cable modem that belongs to the range specified by the MAC address mask,
will be excluded by matching the “1” bit in mask. While configuring a new range rule using the mask argument,
an existent rule with the same range is overwritten.
The cable load-balance exclude modem command is modified to include the assignment option. This option
allows you to exclude a cable modem that was moved into a load balancing group in assignment phase.
Procedure

Step 1 enable Enables privileged EXEC mode. Enter your password if
prompted.
Example:
Router> enable

Example:
Step 3 cable load-balance exclude {modem mac-address Specifies that one or more cable modems should be
[mac-mask] | oui oui-value} [assignment | enforce | static excluded from load balancing operations.
| strict]
By default, the cable modems are excluded from dynamic
Example: and static load balancing, but they continue to participate
Router(config)# cable load-balance exclude oui in passive load balancing. Use the following options to
00:00:0c exclude the cable modems from others combinations of
load balancing:
Step 4 exit Exits global configuration mode.

Example:
Distributing Downstream Load Balancing with Upstream Load Balancing

Two commands are used to configure or display the configuration and status of distributed load balancing on
the Cisco CMTS:
• cable load-balance group ds-lb-group-id policy {pcmm | ugs | us-groups-across-ds}
• show cable load all
The optional configuration of making downstream load balancing decisions is enabled as follows:
282
How to Configure Dynamic Channel Change for Load Balancing
• The target downstream segment is in the same downstream load balancing group as the source downstream
segment. This feature finds the target frequency and interface based on the upstream loads within the
same upstream group as the source.
• The upstream load balancing group can be set for the corresponding channel on which a cable modem
is balanced on the downstream channels.
• The Cisco CMTS automatically locates the upstream segment for a load balancing group and processes
the upstream group status on the source interface that has the lowest load.
• The target downstream segment must have an upstream channel set in the upstream load balancing group.
• The highest target upstream segment must carry less load than any other potential target—the highest
upstream segment on other interfaces.
Procedure

prompted.
Example:
Router> enable

Example:
Step 3 cable load-balance group ds-lb-group-id policy {pcmm Sets the type of service flow policy for use with Load
| ugs | us-groups-across-ds} Balancing. This command synchronizes the pending statistic
between different cable interface line cards in the load
Example:
balancing group. The result is an alternative downstream
Router(config)# cable load-balance group 1 policy load balancing scheme that makes use of per-upstream loads
us-groups-across-ds
rather than total downstream loads when making load
balancing decisions.

Example:
Step 5 show cable load all Displays load balancing statistics and status of load
balancing configurations on the Cisco CMTS, to include
Example:
distributed upstream-to-downstream load balancing when
Router# show cable load all configured.
How to Configure Dynamic Channel Change for Load Balancing

DCC in DOCSIS 1.1 dynamically changes cable modem upstream or downstream channels without forcing
a cable modem to go offline, and without reregistration after the change. DCC supports five different
initialization methods (0-4), instead of one, as in earlier DOCSIS support.
283
Configuring Dynamic Channel Change for Load Balancing
Dynamic Channel Change (DCC) and DCC for Load Balancing on the Cisco CMTS supports the following:
• Load balancing techniques allow for moving cable modems with DCC by using configurable initialization
techniques.
• DCC allows line card channel changes across separate downstream channels in the same cable interface
line card, with the DCC initialization techniques ranging from 0 to 4.
• DCC transfers cable modem state information from the originating downstream channel to the target
downstream channel, and maintains synchronization of the cable modem information between the cable
interface line card and the Network Processing Engine (NPE) or Route Processor (RP).
• Applications that are sensitive to delay, such as PacketCable (PC) and PacketCable MultiMedia (PCMM),
may use DCC initialization technique 4 to retain services while the cable modem is performing DCC.
• If the channel is in mixed or ATDMA-only mode, the primary Service Identifier (SID) must be switched
to ATDMA-only mode.
Configuring Dynamic Channel Change for Load Balancing

To configure the DCC feature for load balancing, use the following steps. Values indicated are sample values
that may differ from your own.
SUMMARY STEPS
1. enable
2. configure terminal
3. cable load-balance docsis-enable
4. cable load-balance docsis-group docsis-group-id
5. init-tech-list tech-list [ucc]
6. policy {pcmm | ugs | us-across-ds | pure-ds-load}
7. threshold {load {minimum <1-100> | <1-100>}| pcmm <1-100> | stability <0-100> | ugs <1-100>}
8. end
DETAILED STEPS

Router> enable

Example:
Example:
284
Verifying Load Balancing Operations

Step 4 cable load-balance docsis-group docsis-group-id Creates a DOCSIS load balance group on the Cisco CMTS,
with the following parameter:
Example:
The router enters DOCSIS load balancing group
Router(config)# cable load-balance docsis-group 1 configuration mode.
Step 5 init-tech-list tech-list [ucc] Sets the DCC initialization techniques that the Cisco CMTS
can use to load balance cable modems.
Example:
Step 6 policy {pcmm | ugs | us-across-ds | pure-ds-load} Selects the modems based on the type of service flow that
are balanced.
Example:

Router(config-lb-group)# policy ugs
Router(config-lb-group)# policy pure-ds-load
Step 7 threshold {load {minimum <1-100> | <1-100>}| pcmm Selects the percentage of use beyond which load balancing
<1-100> | stability <0-100> | ugs <1-100>} occurs.
Example:
Router(config-lb-group)# threshold load minimum 10

Router(config-lb-group)# threshold load 10
Router(config-lb-group)# threshold stability 50
Router(config-lb-group)# threshold ugs 70

Example:
Router# end
What to do next
To test and verify DCC for load balancing, use the following two commands:
• test cable dcc
• show controllers cable
These commands are described in the Cisco CMTS Cable Command Reference .
Verifying Load Balancing Operations

This section describes how to use certain test and show commands to verify the configuration and operation
of the Load Balancing feature or Dynamic Channel Change feature on the Cisco CMTS.
285
Example
Procedure

prompted.
Example:
Router> enable
Step 2 show cable load-balance [group n] [all | load | pending | Displays real-time statistical and operational information
statistics | target] for load balancing operations. If given without any options,
this command displays information for the load balancing
Example:
groups and each cable interface’s current load and load
Router# show cable load-balance group 1 balancing status. You can also specify the following options:
Step 3 test cable dcc [mac-addr | ip-addr | cable-if-src sid ] Tests Dynamic Channel Change (DCC) by moving a target
cable-if-target uschan {ranging-tech } cable modem, as specified by MAC address, IP address, or
the primary service ID (SID) value. Applies to a cable
Example:
modem on the source interface to an upstream channel on
Router# test cable dcc 0000.394e.4e59 a target downstream interface using the initialization
technique specified.
Example
This example shows the result of load balancing operations.
Router#show cable load all

DOCSIS 2.0 LB Enabled: Yes DOCSIS 3.0 LB Enabled: No
DOCSIS Status Interval DCC mask Policy Method Threshold
Group /UCC DS/US M/E/U/P/S
1 RE 30 0xF8(0)/N 0 m/m 5/10/70/70/50
12345 GE 30 0xF8(0)/N 0 m/m 5/10/70/70/50
12346 RE 30 0xF8(0)/N 0 m/m 5/10/70/70/50
12347 RE 30 0xF8(0)/N 0 m/m 5/10/70/70/50
12348 RE 30 0xF8(0)/N 0 m/m 5/10/70/70/50
12349 RE 30 0xF8(0)/N 0 m/m 5/10/70/70/50

MD FN Group ID S Intv DCC mask Policy Mtd MD-CM-SG Threshold
/UCC D/U M/E/U/P/S
Ca8/0/0 1 2147631104 E 30 0x30(2)/N 0 m/m 0x1200301 5/10/70/70/50
Ca8/0/1 3 2147631618 E 30 0x30(2)/N 0 m/m 0x1210301 5/10/70/70/50
Ca8/0/2 5 2147632132 E 30 0x30(2)/N 0 m/m 0x1220401 5/10/70/70/50
Ca8/0/2 6 2147632133 E 30 0x30(2)/N 0 m/m 0x1220402 5/10/70/70/50
Ca8/0/3 7 2147632646 E 30 0x30(2)/N 0 m/m 0x1230501 5/10/70/70/50
Ca8/0/3 8 2147632647 E 30 0x30(2)/N 0 m/m 0x1230502 5/10/70/70/50
Ca8/0/8 2 2147635201 E 30 0x30(2)/N 0 m/m 0x1280201 5/10/70/70/50
Ca8/0/9 4 2147635715 E 30 0x30(2)/N 0 m/m 0x1290201 5/10/70/70/50
Current load:
DOCSIS load-balancing load

Interface State Group Utilization Rsvd NBCM WB/UB Weight
Total Total
In8/0/0:0(411 MHz) initial 1 0%(0%/0%) 0% 0 11 37
In8/0/0:0(411 MHz) initial 2147631104 0%(0%/0%) 0% 0 11 37
Us8/0/0:0 initial 1 0% 0% 0 31 30.7
Us8/0/0:0 initial 2147631104 0% 0% 0 31 30.7
Us8/0/0:1 initial 1 0% 0% 0 31 30.7
286
Us8/0/0:1 initial 2147631104 0% 0% 0 31 30.7

Us8/0/0:2 initial 2147631104 0% 0% 0 31 30.7
Us8/0/0:2 initial 1 0% 0% 0 31 30.7
Us8/0/0:3 initial 2147631104 0% 0% 0 31 30.7
Us8/0/0:3 initial 1 0% 0% 0 31 30.7
In8/0/0:4(435 MHz) up 2147635201 0%(0%/0%) 0% 48 11 37
Us8/0/1:0 up 2147635201 0% 0% 15 0 30.7
Us8/0/1:1 up 2147635201 0% 0% 11 0 30.7
Us8/0/1:2 up 2147635201 0% 0% 11 0 30.7
Us8/0/1:3 up 2147635201 0% 0% 11 0 30.7
In8/0/0:8(459 MHz) initial 1 0%(0%/0%) 0% 0 9 37
In8/0/0:8(459 MHz) initial 2147631104 0%(0%/0%) 0% 0 9 37
Us8/0/0:0 initial 1 0% 0% 0 31 30.7
Us8/0/0:0 initial 2147631104 0% 0% 0 31 30.7
Us8/0/0:1 initial 1 0% 0% 0 31 30.7
Us8/0/0:1 initial 2147631104 0% 0% 0 31 30.7
Us8/0/0:2 initial 2147631104 0% 0% 0 31 30.7
Us8/0/0:2 initial 1 0% 0% 0 31 30.7
Us8/0/0:3 initial 2147631104 0% 0% 0 31 30.7
Us8/0/0:3 initial 1 0% 0% 0 31 30.7
In8/0/0:12(483 MHz) down 2147635201 0%(0%/0%) 0% 0 0
In8/0/0:16(507 MHz) initial 2147631104 0%(0%/0%) 0% 0 11 37
In8/0/0:16(507 MHz) initial 1 0%(0%/0%) 0% 0 11 37
Us8/0/0:0 initial 2147631104 0% 0% 0 31 30.7
Us8/0/0:0 initial 1 0% 0% 0 31 30.7
Us8/0/0:1 initial 2147631104 0% 0% 0 31 30.7
Us8/0/0:1 initial 1 0% 0% 0 31 30.7
Us8/0/0:2 initial 2147631104 0% 0% 0 31 30.7
Us8/0/0:2 initial 1 0% 0% 0 31 30.7
Us8/0/0:3 initial 2147631104 0% 0% 0 31 30.7
Us8/0/0:3 initial 1 0% 0% 0 31 30.7
In8/0/0:20(531 MHz) down 2147635201 0%(0%/0%) 0% 0 0
In8/0/1:0(555 MHz) initial 2147631618 0%(0%/0%) 0% 0 12 37
Us8/0/2:0 initial 2147631618 0% 0% 0 19 30.7
Us8/0/2:1 initial 2147631618 0% 0% 0 19 30.7
Us8/0/2:2 initial 2147631618 0% 0% 0 19 30.7
Problem Packets are dropped when a cable modem moves from one channel to another.
Possible Cause When the test cable dcc command is used to move a cable modem from one channel to
another with DCC initialization technique 3:
• If the pre-equalization coefficient is enabled, the cable modem moves and packet drop occurs for 5
seconds.
• If the pre-equalization coefficient is disabled, the cable modem moves and packet drop occurs for less
than 1 second.
Possible Cause When the test cable dcc command is used to move a cable modem from one channel to
another with DCC initialization technique 4:
• If the pre-equalization coefficient is enabled, the cable modem moves and packet drop occurs for less
than 1 second.
• If the pre-equalization coefficient is disabled, the cable modem moves without any packet drop.
Solution No action is required.
287
Examples
Examples
Use the show cable load-balance target command to display the interfaces being used for load balancing,
use the test cable load-balance command to test whether a cable modem can move between interfaces, and
use the show cable load-balance statistics command to display the results of the test.
The following example shows how to test whether a specific cable modem responds to both a UCC request
and to an upstream channel override to move from one upstream to another in its load balancing group:
Router# show cable load-balance target
Target assignments:
Cable1/0/0 (669 MHz) up 1
Cable1/0/0/U0 up 1 Cable1/0/0/U1 [enforce]
Cable1/0/0/U1 up 1
Router# show cable load-balance statistics
Statistics:

Cable1/0/0 (669 MHz) up 15 0 1 0
Cable1/0/0/U0 up 33 0 1 0
Cable1/0/0/U1 up 22 0 2 0
Router# test cable load-balance 0000.394e.4e59
Sending UCC request: Cable1/0/0/U0 --> U1

Waiting for test completion ........
Test results:
UCC Response: 0.0s
Initial Ranging: 8.5s
Ranging Complete: failed.
Modem replied to DOCSIS ping.
Test summary:
UCC Response: success rate 100% min 0.0s max 0.0s avg 0.0s
Initial Ranging: success rate 100% min 8.5s max 8.5s avg 8.5s
Testing US Channel Override: Cable1/0/0/U1 --> U0
Waiting for test completion ...........
Test results:
Ranging Complete: failed.
Test summary:
Statistics:

Cable1/0/0 (669 MHz) up 15 0 1 0
Cable1/0/0/U0 up 34 0 1 0
Cable1/0/0/U1 up 23 0 2 0
The following example shows how to test whether a specific modem responds to a UCC request to move from
one upstream to another in its load balancing group:
288
Configuration Examples for Load Balancing
Statistics:

Cable1/0/0 (669 MHz) up 15 0 1 0
Cable1/0/0/U0 up 34 0 1 0
Cable1/0/0/U1 up 23 0 2 0
Router# test cable load-balance 0007.0e01.4129 ucc 1
Sending UCC request: Cable1/0/0/U0 --> U1

Waiting for test completion ........
Test results:
UCC Response: 0.0s
Ranging Complete: 11.2s
Test summary:
Ranging Complete: success rate 100% min 11.2s max 11.2s avg 11.2s
Statistics:

Cable1/0/0 (669 MHz) up 15 0 1 0
Cable1/0/0/U0 up 35 0 1 0
Cable1/0/0/U1 up 24 0 2 0
The following example shows information when moving a cable modem to a different upstream channel using
DCC initialization technique 1. This example moves the cable modem 0012.17ea.f563 from interface c7/1/0
upstream 1 to interface c7/1/1 upstream 0 using DCC initialization technique 1:
Router# show cable modem
MAC Address IP Address I/F MAC Prim RxPwr Timing Num BPI
State Sid (dB) Offset CPE Enb
0012.17ea.f563 12.0.0.2 C7/1/0/U1 online 4 0.00 2449 0 N
Router# test cable dcc 0012.17ea.f563 c7/1/1 0 1
0012.17ea.f563 12.0.0.2 C7/1/1/U0 online 3 0.00 2451 0 N
Configuration Examples for Load Balancing

This section provides the following configuration examples:
289
Example: Configuring Dynamic Channel Change for Load Balancing

The following examples illustrate the working of dynamic load balancing working process in DOCSIS 3.0
cable modems.
Verify configuration:
DOCSIS 2.0 LB Enabled: No
DOCSIS 3.0 LB Enabled: Yes
DOCSIS 3.0 Static LB Enabled: No
DOCSIS 3.0 Dynamic Downstream LB Enabled: Yes
1 RE 60 0x38(2)/N 0 u/u 1/10/70/70/50
Verify channel current load:

Router# show cable load-balance docsis-group 1 load wideband
DOCSIS load-balancing wide band load
Interface Size Group Throughput(Kbps)/bw(Mbps) Avg-Util
Wi9/0/0:1 8 1 93324/300 36%
Wi9/0/0:2 8 1 37329/300 39%
Wi9/0/0:3 8 1 74659/300 31%
Wi9/0/0:4 8 1 0/300 13%
Wi9/0/0:5 8 1 9332/300 2%
Verify channel overload and target:

Router# show cable load-balance docsis-group 1 target wideband
Interface Bg-Id State Group Target
Wi9/0/0:1 28674 up 1 Wi9/0/0:5 ...
Wi9/0/0:2 28675 up 1 Wi9/0/0:5 ...
Wi9/0/0:3 28676 up 1 Wi9/0/0:5 ...
Wi9/0/0:4 28677 up 1 Wi9/0/0:5
Wi9/0/0:5 28678 up 1
Verify channel modem-list:

Router# show cable load-balance docsis-group 1 modem-list wideband
L - L2vpn, R - RSVP
Primary WB MAC Address Primary DS RCC-ID Priority MUPFXLR State
Wi9/0/0:1 (10)
c8fb.26a6.c02c In9/0/0:4 1 0 ------- LB_CM_READY
c8fb.26a6.c62c In9/0/0:4 1 0 ------- LB_CM_READY
c8fb.26a6.c706 In9/0/0:4 1 0 ------- LB_CM_READY
c8fb.26a6.c0dc In9/0/0:4 1 0 ------- LB_CM_READY
c8fb.26a6.c53a In9/0/0:4 1 0 ------- LB_CM_READY
Verify QAM channel utilization:

Router# show cable load-balance docsis-group 1 rfch-util
Interface Pstate Pending-In Pending-Out Throughput(Kbps) Util
In9/0/0:4 up No No 6517 17
In9/0/0:5 NA No No 6574 17
In9/0/0:6 NA No No 6520 17
In9/0/0:7 NA No No 6738 17
In9/0/0:8 up No No 8624 22
In9/0/0:9 NA No No 8482 22
In9/0/0:10 NA No No 8353 22
Verify channel statistic movement:
290
Router# show cable load-balance docsis-group 1 statistics wideband

Complete Pending Total Failures Disabled
Wi9/0/0:1 up 0 0 0 0 0
Wi9/0/0:2 up 0 0 0 0 0
Wi9/0/0:3 up 3 0 3 0 0
Wi9/0/0:4 up 0 0 0 0 0
Wi9/0/0:5 up 9 0 9 0 0
The following example of the running configuration illustrates DCC for load balancing.
Router# show cable load all
*Nov 11 15:42:18.955: %SYS-5-CONFIG_I: Configured from console by conscable load all

1 10 modems 0 5 10% --- --- ---
Current load:

Cable3/0 (0 MHz) initial 1 0%(0%/0%) 0% 0 0 26
Target assignments:

Cable3/0 (0 MHz) initial 1
Statistics:

Cable3/0 (0 MHz) initial 0 0 0 0
Pending:
Modem Group Source interface Target interface Retries
The following example of the running configuration illustrates DCC for load balancing.
Router# show running configuration
!
version 12.3
no service pad
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname Router
!
boot-start-marker
boot-end-marker
!
enable secret 5 $1$tEvV$8xICVVbFm10hx0hAB7DO90
enable password lab
!
no cable qos permission create
no cable qos permission update
cable qos permission modems
cable load-balance group 1 threshold load 75 enforce
cable load-balance group 1 threshold stability 75
cable load-balance group 1 policy ugs
cable load-balance group 1 threshold ugs 75
291
cable load-balance group 1 policy pcmm

cable load-balance group 1 threshold pcmm 75
no aaa new-model
ip subnet-zero
!
!
ip cef
no ip domain lookup
!
!
interface GigabitEthernet0/1
ip address 10.14.1.130 255.255.0.0
duplex auto
speed auto
media-type rj45
no negotiation auto
!
interface GigabitEthernet0/2
The following example of the show cable load all command illustrates DCC for load balancing.
Router# show cable load all
*Nov 11 15:43:39.979: %SYS-5-CONFIG_I: Configured fromconf t

1 10 modems 0 5 75% 75% 75% 75%
Current load:

Cable3/0 (0 MHz) initial 1 0%(0%/0%) 0% 0 0 26
Target assignments:

Cable3/0 (0 MHz) initial 1
Statistics:

Cable3/0 (0 MHz) initial 0 0 0 0
Pending:
Modem Group Source interface Target interface Retries
The following example illustrates a DCC load balancing group with the default DCC initialization technique.
This command configures load balancing group 1:
Router(config)# cable load-balance group 1 threshold load 10 enforce
This configuration creates a dynamic load balancing group with the following default settings:
cable load-balance group 1 method modem
cable load-balance group 1 threshold load 10 enforce
cable load-balance group 1 interval 10
cable load-balance group 1 dcc-init-technique 0
The following example changes this DCC load balancing configuration to initialization technique 4:
292
Router# cable load-balance group 1 dcc-init-technique 4
Note By default, UGS and PCMM policies are not turned on, so that CMs with active voice calls or PCMM calls
participate in load balancing.
Description Link
ID and password.
Feature Information for DOCSIS Load Balancing Movements

Table 40: Feature Information for DOCSIS Load Balancing Groups
DOCSIS Load Balancing Cisco IOS XE Fuji 16.7.1 This feature was integrated on the
Movements Cisco cBR Series Converged
Broadband Routers.
293
Feature Information for DOCSIS Load Balancing Movements
294
CHAPTER 18
DOCSIS 3.0 Downstream Bonding
The DOCSIS 3.0 Downstream Bonding feature helps cable operators offer new, more bandwidth-intensive
services by adding one or more additional downstream quadrature amplitude modulation (QAM) channels to
the standard broadband DOCSIS system.
• Information About DOCSIS 3.0 Downstream Bonding, on page 297
• How to Configure RCP and RCC Encoding, on page 298
• How to Configure Attribute Masks, on page 307
• How to Enable Service Flow Priority in Downstream Extender Header, on page 311
• Enabling Verbose Reporting for Receive Channel Profiles, on page 313
• Configuration Example for an RCC Template, on page 314
• Feature Information for DOCSIS 3.0 Downstream Bonding, on page 315
295
Digital PICs:

Module:

Modules:
line card reload.
296
Information About DOCSIS 3.0 Downstream Bonding
Information About DOCSIS 3.0 Downstream Bonding

DOCSIS 3.0 Downstream Bonding enables high-speed broadband access and helps cable operators offer more
bandwidth-intensive services by adding one or more additional downstream quadrature amplitude modulation
(QAM) channels to the standard broadband DOCSIS system. This new set of downstream channels is grouped
into one larger channel, known as a bonded channel.
Channel bonding combines several RF channels into one virtual channel. Data rates in this virtual channel
range from hundreds of megabits to potentially gigabits per second, creating more available bandwidth in the
network.
Receive Channel Profile

An RCP is an encoding that represents the receive channels and receive modules of a cable modem. A cable
modem communicates to the CMTS one or more RCP encodings within its registration request using either
verbose description, which contains complete subtype encoding defined in DOCSIS 3.0, or simple description,
which only contains RCP identifiers.
The cable modem reporting method is configurable within the MAC domain and communicated to cable
modems via the MDD.
You must define an RCP-ID to describe the cable modem's capabilities for that RCP-ID and to input information
about cable modems which are not defined on the system. Once configured the RCP-ID is available to the
entire system since it is not meant to be card specific or mac-domain specific. The path selection module
ensures that the RCP ID is accurately transmitted as part of the RCC profile.
The CableLabs MULPI specification defines standard RCPs which are automatically created by the CMTS.
Receive Channel Configuration

A cable modem reports its ability to receive multiple channels with one or more RCP encodings in a REG-REQ
or REG-REQ-MP message. Each receive channel profile describes a logical representation of the cable
modem’s downstream physical layer in terms of receive channels (RCs) and receive modules (RMs). The
CMTS initially configures the cable modem’s receive channels and receive modules with an RCC encoding
in the registration response.
This feature supports any arbitrary RCP ID configuration and receive channel configuration on a Cisco cBR
RCC Template
You can configure one or more RCC templates for an RCP. An RCC template configures the physical layer
components described by an RCP, including receive modules and receive channels to specific downstream
frequencies. The template also specifies the interconnections among receive modules, or between a receive
module and a receive channel. An RCC template can be associated only to the cable interface (MAC domain).
A cable modem's RCP ID is matched with an RCC, when RCC templates are configured. A cable modem's
RCP ID may be matched with an RCC generated by an RCC template when RCC templates are configured.
The path selection module ensures that the RCP ID that is transmitted as part of the RCC profile is accurate.
297
Channel Assignment
At time of registration, if there are multiple valid RCCs that can be assigned to the CM after going through
the sequence of checks outlined in the CableLabs MULPI specifications then the RCC with the most channels
will be the one selected. If there are multiple valid RCCs of equal size then the RCC with the least amount of
cable modems will be selected.
Channel Assignment
The CMTS assigns a receive channel configuration encoding to a DOCSIS 3.0-certified cable modem operating
in a Multiple Receive Channel (MRC) mode during cable modem registration.
With the implementation of this feature, the DOCSIS 3.0-certified cable modem reports its receiving capabilities
and characteristics using the receive channel profile type, length, value (TLV) list in the registration request
message. Based on this report, the CMTS assigns an RCC encoding that is compatible with the reported RCP.
Cable modems operating in MRC mode are assigned an RCC encoding associated with an RCP. RCC encodings
may be derived from RCC templates or from a wideband-cable interface configuration.
Downstream Traffic Forwarding

DOCSIS 3.0 introduces the concept of assigning downstream service flows of cable modems, which are
operating in an MRC mode, to downstream (DS) channels or bonding groups. Forwarding interfaces assigned
to service flows (SFs) can be either DS channel interfaces (integrated cable interfaces) or downstream bonding
groups (wideband interfaces).
Note Valid interfaces that are available for SF assignment must be a subset of the cable modem’s assigned RCC
encoding.
Service Flow Priority in Downstream Extended Header

The purpose of the feature is to be able to reflect the traffic priority of downstream packets into the DOCSIS
extended header. The priority is derived from the service flow that the packet is mapped to. Priority refers to
the service flow priority specified in the CM configuration file, or the Cisco CMTS service class configuration.
The service flow priority can be set using cable modem configuration file, or dynamic configuration.
By default, this feature is disabled on Cisco cBR-8 router, user can use cable service flow priority command
to enable this feature.
How to Configure RCP and RCC Encoding

The following tasks describe how to configure a receive channel profile and configuration encoding for a
receive channel profile:
Configuring the RCP ID

You must configure the RCP IDs with the cable modem capabilities that are not defined in the CMTS. This
is done to supplement the standard MULPI RCP IDs already created by the CMTS.
298
Before you begin

Restrictions
The configurations are subject to RCC Templates and RCP Interactions as follows:
• RCC templates can only be created for an RCP that is already defined on the system. By default the
system will contain the RCPs that are specified in the MULPI spec.
• When defining RCC templates for a particular RCP, error checking will be done to ensure that the
information being configured in the RCC template does not violate the corresponding RCP information.
For example, if the RCP information indicates that there are 2 receive modules then the RCC template
configuration will not allow the user to configure more than 2 modules.
• Once an RCP is included in an RCC template users will not be allowed to modify the RCP. Only an RCP
which is not being used by any RCC template can be modified
• A valid RCP that can be applied to an rcc-template must contain the following;
• center-frequency-spacing
• At least one module which defines the minimum and maximum center frequency range.
• Rules of inheritance.
• rcc-template inherit definition from the associated user-defined RCP, such as
center-frequency-spacing.
• rcc-template channel frequencies must fall within the range of the minimum and maximum center
frequency per the corresponding RCP module.
• common-module definition is applicable to the rcc-template module referenced with the same index.
• rcc-template module channel frequencies overrides the same channel from the corresponding
common-module.
Procedure

Router> enable

Example:
Step 3 cable rcp-id rcp-id Defines the RCC template.

Example: • rcp-id - Specifies an RCP ID in Hex.
This command changes the input mode to the RCC
Router(config)#cable rcp-id 00 10 00 01 08
Router(config-rcp)# configuration mode.
Step 4 name word name —Assigns a name ro the RCP ID

Example: • word—Use a string to name the RCP ID.
Note Do not include space between words in the
Router(config-rcp)# name rcp-id_1
name
299

Step 5 center-frequency-spacing frequency Assigns a center frequency space to the RCP ID. The valid
values are 6 and 8.
Example:
Router(config-rcp)#center-frequency-spacing 6
Step 6 module module index minimum-center-frequency Hz Configures a receive module configuration for the selected
maximum-center-frequency Hz RCP.
Example: • module index - Specifies the module number for the
receivemodule. The valid range is 1 to 12.
Router(config-rcp)# module 1 • minimum-center-frequency - Specifies the minimum
minimum-center-frequency 120000000 center frequency for the channels of the
maximum-center-frequency 800000000
receivemodule channel.
• Hz- Specifies the center frequency value in Hz. The
valid range is from 111000000 to 999000000.
• maximum-center-frequency - Specifies the
maximum center frequency for the channels of the
receive module channel.
Step 7 module module index number-of-adjacent-channels Specifies the frequency band for the receive module. The
Integrer valid values are 1-255.
Example:
Router(config-rcp)#module 2
number-of-adjacent-channels 10
Router(config-rcp)#
Step 8 module module index connected-module module index Specifies a receive channel configuration for the selected
RCP.
Example:
• connected-receive-module— (Optional) Specifies
Router(config-rcp)# module 1 connected-module 0 a nested receive module in the RCC template.
Generally, only one receive module is configured for
an RCC template.
• module index—Specifies the module number for the
receive module. The valid range is 1 to 12.
Step 9 number-of-channels Number of channel Specifies the number of receive channels in the RCP ID.
Example:
Router (config-rcp)#number-of-channels 8
Step 10 primary-capable-channels Number of channel Specifies the number of receive channels that are defined
as primary capable channels.
Example:
Router(config-rcp)# primary-capable-channels 1
300
Configuring the RCC Templates
What to do next
Verify RCP ID configurations using the show cable rcps command.
Router# show cable rcps

RCP ID : 00 10 00 01 08
Name : rcp-id 1
Center Frequency Spacing : 6
Max number of Channels : 8
Primary Capable Channel : 1
Number of Modules : 2
Module[1]:
Number of Adjacent Channels: 10
Minimum Center Frequency-Hz: 111000000
Maximum Center Frequency-Hz: 999000000
Module[2]:
RCP ID : 00 10 00 00 02
Name : rcp-id 2
Center Frequency Spacing : 6
Max number of Channels : 2
Primary Capable Channel : 1
Number of Modules : 1
Module[1]:
Connected Module : 64

You must configure an RCC template with a unique RCP ID for a particular CMTS. A valid RCC template
consists of a configured RCP ID, RMs, and RCs. There is dependency between the RCC templates and the
RCP since information present in the RCP configuration is also present in RCC templates.
Each RCC encoding contains all operational DS channels with their channel parameters, including the frequency
match RC attribute specified in the RCC template. An RCC template specifies the intended receive channel
assignment in the available DS spectrum.
Note If an RCC template is removed from a MAC domain through configuration, the CMTS removes all RCC
encodings derived from the RCC template, and all cable modems assigned to the RCC encoding are marked
offline.
Before you begin

At least one RC must be configured as a primary Receive Channel (RC).
301
Procedure

Router> enable

Example:
Step 3 cable rcc-templates frequency-based id id—Specifies an RCC template. The valid range is 1-64.
Example:
Router(config)#cable rcc-templates frequency-based
1
Router(config-rcc-freq-based)#
Step 4 rcp-id id id—Specifies an RCP ID for the RCC template. The valid
range is 00 00 00 00 00 to FF FF FF FF. By default, the
Example:
RCP ID is set to 00 00 00 00 00.
Router(config-rcc-freq-based)#rcp-id 00 10 00 01
08
Step 5 common-module module-index channel grouplist Specifies module configurations that are common for a
start-frequency Hz selected set of channels assigned to the selected RCP ID.
Example: • Module-index—Specifies the index value for the
Router(config-rcc-freq-based)# common-module 1 receive module. The valid range is 1 to 12.
channels 0-6 start-frequency 555000000
• channels—Specifies the list of channels to which the
common configurations apply.
• grouplist—Specifies the list of channels to which a
specific list of configurations apply. The range of
values are 1-64.
• start-frequency —Specifies the start frequency value
in Hz.
• Hz—Specifies the frequency value for the start
frequency for the common module.
Thevalidrangeisfrom 111000000 to 999000000.
Step 6 rcc-template Id Specifies an RCC template ID to configure the selected

RCC template.
Example:
Router(config-rcc-freq-based)# rcc-template 1 • Id—Specifies the ID of the RCC template. The valid
range is from 1-8.
Step 7 cm-attribute-mask value (Optional) Configured to be used to match against the cm

attribute mask define in CM 's configuration file.
Example:
302

Router (config-rcc-freq-based-tmplt)# • value—The valid range is 00 00 00 00 00 to FF FF FF
cm-attribute-mask 1
FF.
Step 8 modulemodule-index channel grouplist start-frequency Specifies module configurations that are common for a
Hz. selected set of channels assigned to the selected RCP ID.
Example: • Module-index—Specifies the index value for the
Router(config-rcc-freq-based)# common-module 1 receive module. The valid range is 1 to 12.
channels 0-6 start-frequency 555000000
• channels—Specifies the list of channels to which the
common configurations apply.
• grouplist—Specifies the list of channels to which a
specific list of configurations apply. The range of
values are 1-64.
• start-frequency —Specifies the start frequency value
in Hz.
• Hz—Specifies the frequency value for the start
frequency for the common module. The valid range is
from 111000000 to 999000000.
Repeat Step 3 and Step 7 to configure other frequency based

RCC templates.
What to do next
The following configuration examples show the cable rcc-template configuration:
cable rcc-templates frequency-based 2
rcp-id 00 10 00 01 08
common-module 1 channels 1-4 start-frequency 381000000
rcc-template 1
module 1 channels 5-8 start-frequency 501000000
rcc-template 2
rcc-template 3

rcp-id 00 10 00 01 08
rcc-template 1
cm-attribute-mask 2
rcc-template 2
rcc-template 3
After defining an RCC template, you must assign the template to a cable interface.
303
Assigning an RCC Template to a MAC Domain (Cable Interface)

The CMTS derives an RCC or RCCs from the RCC template for each MAC Domain Downstream Service
Group (MD-DS-SG).
The following information is required for RCC assignment to cable modems:
• RCC templates assigned to the MAC domain.
• DS channel physical parameters including frequency and connected-receive-module index .
• DS channel primary capable indicator.
• DS channel membership to the MD-DS-SG.
• Cable modem membership to the MD-DS-SG.
This section describes how to assign an RCC template to a MAC Domain.
Procedure

Router> enable

Example:
Step 3 interface cable slot/subslot/port Enters MAC domain configuration mode.

Example: • slot—Specifies the chassis slot number of the interface
Router(config)# interface cable 1/0/0 line card.
• subslot—Specifies the secondary slot number of the
interface line card. Valid subslot is 0.
• MD index—Specifies the MAC Domain index number.
Valid values are 0-15.
Step 4 cable rcc-template frequency-based Id Assigns the RCC template to the specified cable interface.
Example: • Id—Specifies the template you want to assign to the
cable interface. The valid range is from 1 to 64.
Router(config-if)# cable rcc-template
frequency-based 1
What to do next
Verify RCC template binding to MD.
The following example shows the RCC template binding using the show cable mac-domain rcc
304
Router#show cable mac-domain c1/0/0 rcc
RCC-ID RCP RCs MD-DS-SG CMs WB/RCC-TMPL

1 00 00 00 00 00 4 0 2 WB (Wi1/0/0:0)
2 00 00 00 00 00 4 0 2 WB (Wi1/0/0:1)
3 00 00 00 00 00 4 0 0 WB (Wi1/0/1:2)
4 00 00 00 00 00 4 0 0 WB (Wi1/0/2:3)
8 00 10 00 01 08 8 5 0 RCC-TMPL (1:1)
9 00 10 00 01 08 8 5 0 RCC-TMPL (1:2)
10 00 10 00 01 08 4 5 0 RCC-TMPL (1:3)
14 00 10 00 01 08 8 5 0 RCC-TMPL (2:1)
15 00 10 00 01 08 8 5 0 RCC-TMPL (2:2)
16 00 10 00 01 08 4 5 0 RCC-TMPL (2:3)
The following example shows the RCC template binding using the show cable mac-domain rcc id command.
Router#show cable mac-domain c1/0/0 rcc 8
RCC ID : 8
RCP : 00 10 00 01 08
Created Via : rcc-template - 1:1
CM attribute mask : 0x2
Receive Channels : 8
Receive Channel : 1
Center Frequency : 381000000
Primary Capability : YES
Receive Module Conn : 1
Receive Channel : 2
Primary Capability : NO
Receive Channel : 3
Receive Channel : 4
Receive Channel : 5
Receive Channel : 6
Receive Channel : 7
Receive Channel : 8
Receive Modules : 2
Receive Module : 1
First Frequency : 381000000
Receive Module : 2
305
RCC ID : 9
RCP : 00 10 00 01 08
Receive Channel : 1
Receive Channel : 2
Receive Channel : 3
Receive Channel : 4
Receive Channel : 5
Receive Channel : 6
Receive Channel : 7
Receive Channel : 8
Receive Modules : 2
Receive Module : 1
Receive Module : 2
RCC ID : 10
RCP : 00 10 00 01 08
Receive Channel : 1
Receive Channel : 2
Receive Channel : 3
306
Verifying the RCC Configuration
Receive Channel : 4
Receive Modules : 1
Receive Module : 2

To verify the runtime RCCs on a cable interface, use the show cable mac-domain rcc command.
Router#show cable mac-domain c1/0/0 rcc
RCC-ID RCP RCs MD-DS-SG CMs WB/RCC-TMPL

1 00 00 00 00 00 4 0 2 WB (Wi1/0/0:0)
2 00 00 00 00 00 4 0 2 WB (Wi1/0/0:1)
3 00 00 00 00 00 4 0 0 WB (Wi1/0/1:2)
4 00 00 00 00 00 4 0 0 WB (Wi1/0/2:3)
8 00 10 00 01 08 8 5 0 RCC-TMPL (1:1)
9 00 10 00 01 08 8 5 0 RCC-TMPL (1:2)
10 00 10 00 01 08 4 5 0 RCC-TMPL (1:3)
14 00 10 00 01 08 8 5 0 RCC-TMPL (2:1)
15 00 10 00 01 08 8 5 0 RCC-TMPL (2:2)
16 00 10 00 01 08 4 5 0 RCC-TMPL (2:3)
Note A zero (0) value in the RCP or MD-DS-SG field indicates that the RCC encoding is configured
directly through a wideband interface configuration and not through any RCC template.
How to Configure Attribute Masks

DOCSIS 3.0 introduces the concept of assigning service flows to channels or bonding groups based on binary
attributes. The attribute masks configured on a cable, modular, integrated or wideband interface are called
provisioned attribute masks.
The two types of attributes are as follows:
• Specification-defined attributes—Contain default values based on the characteristics of the channel or
bonding group.
• Operator-defined attributes—Default to zero.
The operator can configure a provisioned attribute mask for each channel and provisioned bonding group to
assign values to the operator-defined binary attributes. The operator can also assign new values to override
the default values of the specification-defined attributes.
The operator can configure a required attribute mask and a forbidden attribute mask for a service flow in the
cable modem configuration file. These required and forbidden attribute masks are optionally provided on the
DOCSIS 3.0 service flows and are matched with the provisioned attribute masks of the interfaces.
307
Configuring Provisioned Attributes for an Integrated Cable Interface
Each service flow is optionally configured with the following TLV parameters:
• Service flow required attribute mask—To configure this, assign a service flow to a channel that has a
1-bit in all positions of its provisioned attribute mask corresponding to the 1-bit in the service flow
required attribute mask.
• Service flow forbidden attribute mask—To configure this, assign a service flow to a channel that has a
0-bit in all positions of its provisioned attribute mask corresponding to the 1-bit in the service flow
forbidden attribute mask.
Additionally, in a cable modem-initiated dynamic service request, the cable modem can include a required
attribute mask and a forbidden attribute mask for a service flow. The CMTS assigns service flows to channels
or bonding groups so that all required attributes are present and no forbidden attributes are present in the cable
modem configuration file.
The table below lists the supported binary attributes for channels and bonding groups.
Table 42: Binary Attributes
Bit Position Definition
Bit 0 Bonded—This bit is zero for all individual channel interfaces and one for all bonding groups.
Bit 1 Low latency—This bit is set when the interface can provide relatively low latency service. This
bit is set to zero for all channels, and left up to the operator to define.
Bit 2 High availability—This bit is set to zero for all channels, and left up to the operator to define.
Bit 3:15 Reserved—Set to zero.
Bit 16:31 Operator defined—Set to zero by default.
You can configure provisioned attribute masks for cable, integrated cable, wideband cable, and modular cable
interfaces.
Prerequisites
• To assign an interface to a wideband cable modem’s service flow, the interface must be a subset of the
cable modem’s RCC.
• To assign a service flow to an integrated cable (IC) channel, the corresponding integrated cable interface
must be configured and operational.
Restrictions
• The service flow from a narrowband cable modem is always assigned to the primary interface of the
cable modem. No attribute checking is performed in this case.
This section describes the following:
Configuring Provisioned Attributes for an Integrated Cable Interface

The default provisioned attribute is zero for an integrated cable interface.
308
Configuring Provisioned Attributes for a Wideband Cable Interface
Procedure

Router> enable

Example:
Step 3 interface integrated-cable {slot/port | Specifies the cable interface line card on a Cisco CMTS
slot/subslot/port}:rf-channel router:
Example: • slot—Chassis slot number of the cable interface line
Router(config)# interface integrated-cable 1/0/0:0 card.
• subslot—subslot number of the cable interface line
card. Valid subslot is always 0.
• port—Downstream port number.
• rf-channel—RF channel number with a range of 0 to
3.
Step 4 cable attribute-mask mask Specifies the mask for the interface.
Example:
Router(config-if)# cable attribute-mask 800000ff
Configuring Provisioned Attributes for a Wideband Cable Interface

The default provisioned attribute is 0x80000000 for a wideband cable interface, and the zero bit is automatically
added to the wideband cable interface whenever an attribute is configured for that interface.
Procedure

Router> enable

Example:
Step 3 interface wideband-cable {slot/port | Specifies the wideband cable interface and enters interface
slot/subslot/port}:wideband-channel configuration mode:
Example:
309
Verifying the Attribute-Based Service Flow Assignments

Router(config)# interface wideband-cable 1/0/1:4
Step 4 cable downstream attribute-mask mask Specifies the mask for the interface.
Example:
Router(config-if)# cable downstream attribute-mask
800000ff
Verifying the Attribute-Based Service Flow Assignments

To verify the attribute-based assignment of service flows on a cable interface, use the show interface cable
service-flow or show interface wideband-cable service-flow command as shown in the following example:
Router# show interface cable 3/0 service-flow
Sfid Sid Mac Address QoS Param Index Type Dir Curr Active DS-ForwIf/
Prov Adm Act State Time US-BG/CH
17 4 001c.ea37.9aac 3 3 3 P US act 13h21m CH 3
18 N/A 001c.ea37.9aac 4 4 4 P DS act 13h21m Wi3/0:0
21 6 001c.ea37.9b5a 3 3 3 P US act 13h21m CH 4
22 N/A 001c.ea37.9b5a 4 4 4 P DS act 13h21m Wi3/0:0
23 7 0016.925e.654c 3 3 3 P US act 13h21m CH 3
24 N/A 0016.925e.654c 4 4 4 P DS act 13h21m In3/0:0
Router# show interface wideband-cable 5/1:0 service-flow

Sfid Sid Mac Address QoS Param Index Type Dir Curr Active DS-ForwIf/
Prov Adm Act State Time US-BG/CH
3 8193 ffff.ffff.ffff 3 3 3 S(s) DS act 2h06m Wi5/1:0
The table below shows descriptions for the fields displayed by this command:
Table 43: show interface cable service-flow Field Descriptions
Field Description
Sfid Identifies the service flow identification number.

Note Primary service flow IDs are displayed even for offline cable modems
because they are needed for modem re-registration.
Sid Identifies the service identification number (upstream service flows only).
Mac Address Identifies the MAC address for the cable modem.
QoS Parameter Index Prov Identifies the QoS parameter index for the provisioned state of this flow.
QoS Parameter Index Adm Identifies the QoS parameter index for the Admitted state of this flow.
QoS Parameter Index Act Identifies the QoS parameter index for the Active state of this flow.
310
How to Enable Service Flow Priority in Downstream Extender Header
Field Description
Type Indicates if the service flow is the primary flow or a secondary service flow.
Secondary service flows are identified by an “S” (created statically at the time
of registration, using the DOCSIS configuration file) or “D” (created dynamically
by the exchange of dynamic service messages between the cable modem and
CMTS).
Dir Indicates if this service flow is DS or US.
Curr State Indicates the current run-time state of the service flow.
Active Time Indicates the length of time this service flow has been active.
DS-ForwIf/US-BG/CH Indicates the bonding group ID or the downstream RFID of the forwarding
interface assigned to the downstream service flow.
BG/DS
How to Enable Service Flow Priority in Downstream Extender

Header
The following tasks describe how to enable service flow priority in downstream extender header:
Enabling Service Flow Priority in Downstream Extender Header

This section describes how to enable service flow priority in downstream extender header on the Cisco cBR-8
routers:
Procedure

Router> enable

Example:
Step 3 cable service flow priority Enables the service flow priority in downstream extender
header.
Example:
Router(config)# cable service flow priority
311
Verifying the Enablement of the Service Flow Priority in Downstream Extended Header
Verifying the Enablement of the Service Flow Priority in Downstream Extended

Header
To verify the enablement of the service flow priority in downstream extended header, use the show
running-config | in service flow or show cable modem [ip-address | mac-address] verbose command as
shown in the following example:
Router# show running-config | in service flow

cable service flow priority
MAC Address : 0025.2e2d.74f8

IP Address : 100.1.2.110
IPv6 Address : 2001:420:3800:909:7964:98F3:7760:ED2
Dual IP : Y
Prim Sid : 1
Host Interface : C3/0/0/U0
MD-DS-SG / MD-US-SG : N/A / N/A
MD-CM-SG : 0x900000
Primary Downstream : In3/0/0:32 (RfId : 12320, SC-QAM)
Wideband Capable : Y
DS Tuner Capability : 8
RCP Index : 6
RCP ID : 00 00 00 00 00
Downstream Channel DCID RF Channel : 191 3/0/0:32 (SC-QAM)
UDC Enabled : N
US Frequency Range Capability : Standard (5-42 MHz)
Extended Upstream Transmit Power : 0dB
Multi-Transmit Channel Mode : N
Upstream Channel : US0
Ranging Status : sta
Upstream SNR (dB) : 39.8
Upstream Data SNR (dB) : 36.12
Received Power (dBmV) : -1.00
Timing Offset (97.6 ns): 1799
Initial Timing Offset : 1799
Rng Timing Adj Moving Avg(0.381 ns): 0
Rng Timing Adj Lt Moving Avg : 0
Rng Timing Adj Minimum : 0
Rng Timing Adj Maximum : 0
Pre-EQ Good : 0
Pre-EQ Scaled : 0
Pre-EQ Impulse : 0
Pre-EQ Direct Loads : 0
Good Codewords rx : 8468
Corrected Codewords rx : 0
Uncorrectable Codewords rx : 0
Phy Operating Mode : atdma
sysDescr :
Downstream Power : 0.00 dBmV (SNR = ----- dB)
MAC Version : DOC3.0
QoS Provisioned Mode : DOC1.1
Enable DOCSIS2.0 Mode : Y
Service Flow Priority : N
Modem Status : {Modem= online, Security=disabled}
Capabilities : {Frag=Y, Concat=Y, PHS=Y}
Security Capabilities : {Priv=, EAE=N, Key_len=}
L2VPN Capabilities : {L2VPN=N, eSAFE=N}
L2VPN type : {CLI=N, DOCSIS=N}
Sid/Said Limit : {Max US Sids=16, Max DS Saids=15}
312
Enabling Verbose Reporting for Receive Channel Profiles
Optional Filtering Support : {802.1P=N, 802.1Q=N, DUT=N}

Transmit Equalizer Support : {Taps/Symbol= 1, Num of Taps= 24}
CM Capability Reject : {15,22,23,24,25,26,27,28,29,35,36,38}
Flaps : 3(Oct 8 16:22:23)
Errors : 0 CRCs, 0 HCSes
Stn Mtn Failures : 0 aborts, 2 exhausted
Total US Flows : 1(1 active)
Total DS Flows : 1(1 active)
Total US Data : 294 packets, 25903 bytes
Total US Throughput : 143 bits/sec, 0 packets/sec
Total DS Data : 91 packets, 10374 bytes
Total DS Throughput : 0 bits/sec, 0 packets/sec
LB group ID assigned : 1
LB group ID in config file : N/A
LB policy ID : 0
LB priority : 0
Tag : d30
Required DS Attribute Mask : 0x0
Forbidden DS Attribute Mask : 0x0
Required US Attribute Mask : 0x0
Forbidden US Attribute Mask : 0x0
Service Type ID :
Service Type ID in config file :
Active Classifiers : 0 (Max = NO LIMIT)
CM Upstream Filter Group : 0
CM Downstream Filter Group : 0
CPE Upstream Filter Group : 0
CPE Downstream Filter Group : 0
DSA/DSX messages : permit all
Voice Enabled : NO
DS Change Times : 0
Boolean Services : 0
CM Energy Management Capable : N
CM Enable Energy Management : N
CM Enter Energy Management : NO
Battery Mode : N
Battery Mode Status :
Number of Multicast DSIDs Support : 16
MDF Capability Mode : 2
IGMP/MLD Version : MLDv2
FCType10 Forwarding Support : Y
Features Bitmask : 0x0
Total Time Online : 6h00m (6h00m since last counter reset)
CM Initialization Reason : POWER_ON
Enabling Verbose Reporting for Receive Channel Profiles

A receive channel profile is an encoding that represents the receive channels and receive modules of a cable
modem. A cable modem communicates to the CMTS one or more RCP encodings within its registration
request using either verbose description, which contains complete subtype encodings defined in DOCSIS 3.0,
or simple description, which only contains RCP identifiers.
Procedure

313
Configuration Example for an RCC Template

Router> enable

Example:
Step 3 interface cable {slot/port | slot/subslot/port} Specifies the cable interface line card on a Cisco CMTS
router:
Example:
Router(config)# interface cable7/0/0 • slot—Chassis slot number of the cable interface line
card.
• subslot—subslot number of the cable interface line
card. Valid subslot is 0.
• port—Downstream port number.
Step 4 cable rcp-control verbose Enables RCP reporting with verbose description.
Example:
Router(config-if)# cable rcp-control verbose
Configuration Example for an RCC Template

The following sample shows an RCP ID configuration:
...
!
cable rcp-id 00 10 00 01 08
center-frequency-spacing 6
module 1 minimum-center-frequency 120000000 maximum-center-frequency 800000000 module 1
module 2 minimum-center-frequency 120000000 maximum-center-frequency 800000000 module 2
number-of-channels 8
primary-capable-channels 1
!
The following sample shows an RCC template configuration:
...
!
rcp-id 00 10 00 01 08
rcc-template 1
cm-attribute-mask 2
rcc-template 2
rcc-template 3
314
The following sample shows an RCC template configuration using the common-module option:
...
!
rcp-id 00 10 00 01 08
common-module 1 channels 1-4 start-frequency 381000000
rcc-template 1
rcc-template 2
rcc-template 3
!
The following sample shows the assignment of an RCC template to MAC Domain:
...
!
configure terminal
interface c1/0/0
end
...
Description Link
ID and password.
Feature Information for DOCSIS 3.0 Downstream Bonding

315
Feature Information for DOCSIS 3.0 Downstream Bonding
DOCSIS 3.0 Downstream Bonding Cisco IOS XE Everest 16.6.1 This feature was integrated on the
Cisco cBR Series Converged
Broadband Router.
Service Flow Priority in Cisco IOS XE Everest 16.6.1 This feature was integrated on the
Downstream Extended Header Cisco cBR Series Converged
Broadband Router.
316
CHAPTER 19
DOCSIS 2.0 A-TDMA Modulation Profiles
This document describes the DOCSIS 2.0 A-TDMA services feature, which provides support for DOCSIS
2.1 Advanced Time Division Multiple Access (A-TDMA) upstream modulation profiles on the router. This
feature supplements the existing support for DOCSIS 1.0 and DOCSIS 1.1 Time Division Multiple Access
(TDMA) modulation profiles.
Contents
• Prerequisites for DOCSIS 2.0 A-TDMA Modulation Profiles, on page 319
• Restrictions for DOCSIS 2.0 A-TDMA Services, on page 319
• Information About DOCSIS 2.0 A-TDMA Services, on page 319
• How to Configure DOCSIS 2.0 A-TDMA Services, on page 322
• Monitoring the DOCSIS 2.0 A-TDMA Services, on page 326
• Configuration Examples for DOCSIS 2.0 A-TDMA services, on page 329
• Feature Information for DOCSIS 2.0 A-TDMA Modulation Profile, on page 333
317
Digital PICs:

Module:

Modules:
line card reload.
318
Prerequisites for DOCSIS 2.0 A-TDMA Modulation Profiles
Prerequisites for DOCSIS 2.0 A-TDMA Modulation Profiles

• The cable physical plant must be capable of supporting the higher-bandwidth DOCSIS 2.0 A-TDMA
modulation profiles.
• Cable modems must be DOCSIS-compliant. If cable modems go offline, or appear to be online but do
not pass traffic when in the mixed TDMA/A-TDMA mode, upgrade the modem software to a
DOCSIS-compliant version.
• The following are required to support the DOCSIS 2.0 A-TDMA features:
• Cable modems must be DOCSIS 2.0 capable.
• The DOCSIS configuration file for a DOCSIS 2.0 cable modem must either omit the DOCSIS 2.0
Enable field (TLV 39), or it must set TLV 39 to 1 (enable). If you set TLV 39 to 0 (disable), a
DOCSIS 2.0 CM uses the TDMA mode.
• The upstream must be configured for either A-TDMA-only or mixed TDMA/A-TDMA mode. To
use the 6.4 MHz channel width, the upstream must be configured for A-TDMA-only mode.
• Complete a basic configuration of the router; this includes, at a minimum, the following tasks:
• Configure a host name and password for the router.
• Configure the router to support Internet Protocol (IP) operations.
• Install and configure at least one WAN adapter to provide backbone connectivity.
• Determine a channel plan for the router and all of its cable interfaces.
• Verify that your headend site includes all necessary servers to support DOCSIS and Internet connectivity,
including DHCP, ToD, and TFTP servers.
• The system clock on the router should be set to a current date and time to ensure that system logs have
the proper timestamp and to ensure that the BPI+ subsystem uses the correct timestamp for verifying
cable modem digital certificates.
Restrictions for DOCSIS 2.0 A-TDMA Services

• Does not support virtual channels, as described in DOCSIS 2.0 specification.
• Does not support Synchronous Code Division Multiple Access (S-CDMA) channels.
• Changing the DOCSIS mode of an upstream takes all cable modems on that upstream offline, which
forces the cable modems to reregister, so that the CMTS can determine the capabilities of the cable
modems on the new channels.
Information About DOCSIS 2.0 A-TDMA Services

DOCSIS 2.0 A-TDMA services improve the maximum upstream bandwidth on existing DOCSIS 1.0 and
DOCSIS 1.1 cable networks by providing a number of advanced PHY capabilities that have been specified
by the new DOCSIS 2.0 specifications.
DOCSIS 2.0 A-TDMA services incorporate the following advantages and improvements of DOCSIS 2.0
networks:
319
Modes of Operation
• Builds on existing DOCSIS cable networks by providing full compatibility with existing DOCSIS 1.0
and DOCSIS 1.1 cable modems. (The registration response (REG-RSP) message contains the DOCSIS
version number to identify each cable modem’s capabilities.)
• Upstreams can be configured for three different modes to support different mixes of cable modems:
• An upstream can be configured for TDMA mode to support only DOCSIS 1.0 and DOCSIS 1.1
cable modems.
• An upstream can be configured for A-TDMA mode to support only DOCSIS 2.0 cable modems.
• An upstream can be configured for a mixed, TDMA/A-TDMA mode, to support both DOCSIS
1.0/DOCSIS 1.1 and DOCSIS 2.0 cable modems on the same upstream.
Note DOCSIS 2.0 A-TDMA cable modems will not register on a TDMA upstream if
an A-TDMA or mixed upstream exists in the same MAC domain, unless the
CMTS explicitly switches the cable modem to another upstream using an Upstream
Channel Change (UCC) message. DOCSIS 1.0 and DOCSIS 1.1 cable modems
cannot register on an A-TDMA-only upstream.
• A-TDMA mode defines new interval usage codes (IUC) of A-TDMA short data grants, long data grants,
and Unsolicited Grant Service (UGS) grants (IUC 9, 10, and 11) to supplement the existing DOCSIS 1.1
IUC types.
• Increases the maximum channel capacity for A-TDMA upstreams to 30 Mbps per 6 MHz channel.
• A-TDMA and mixed modes of operation provide higher bandwidth on the upstream using new 32-QAM
and 64-QAM modulation profiles, while retaining support for existing 16-QAM and QPSK modulation
profiles. In addition, an 8-QAM modulation profile is supported for special applications.
• Supports a minislot size of 1 tick for A-TDMA operations.
• Increases channel widths to 6.4 MHz (5.12 Msymbol rate) for A-TDMA operations.
• A-TDMA and mixed modes of operation provide a more robust operating environment with increased
protection against ingress noise and other signal impairments, using a number of new features:
• Uses to a symbol (T)-spaced adaptive equalizer structure to increase the equalizer tap size to 24
taps, compared to 8 taps in DOCSIS 1.x mode. This allows operation in the presence of more severe
multipath and microreflections, and can accommodate operation near band edges where group delay
could be a problem.
• Supports new QPSK0 and QPSK1 preambles, which provide improved burst acquisition by
performing simultaneous acquisition of carrier and timing lock, power estimates, equalizer training,
and constellation phase lock. This allows shorter preambles, reducing implementation loss.
• Increases the forward error correction (FEC) T-byte size to 16 bytes per Reed Solomon block (T=16)
with programmable interleaving.
Modes of Operation
Depending on the configuration, the DOCSIS 2.0 A-TDMA Service feature supports either DOCSIS or
Euro-DOCSIS operation:
• DOCSIS cable networks are based on the ITU J.83 Annex B physical layer standard and Data-over-Cable
Service Interface Specifications (DOCSIS, Annex B) specification, which use 6 MHz National Television
Systems Committee (NTSC) channel plans. In this mode, the downstream uses a 6 MHz channel width
320
Modes of Operation
in the 85 to 860 MHz frequency range, and the upstream supports multiple channel widths in the 5 to 42
MHz frequency range.
• EuroDOCSIS cable networks are based on the ITU J.112 Annex A physical layer standard and European
DOCSIS (EuroDOCSIS, Annex A) specification, which use 8 MHz Phase Alternating Line (PAL) and
Systeme Electronique Couleur Avec Memoire (SECAM) channel plans. In this mode, the downstream
uses an 8 MHz channel width in the 85 to 860 MHz frequency range, and the upstream supports multiple
channel widths in the 5 to 65 MHz frequency range.
Note The difference between DOCSIS and EuroDOCSIS is at the physical layer. To support a DOCSIS or
EuroDOCSIS network requires the correct configuration of the DOCSIS 2.0 A-TDMA Service card, as well
as upconverters, diplex filters, and other equipment that supports the network type.
The table below shows the maximum supported DOCSIS 1.1 data rates.
Table 46: Maximum DOCSIS 1.1 Data Rates
Upstream Channel Width Modulation Scheme Baud Rate Sym/sec Maximum Raw Bit Rate Mbit/sec
3.2 MHz 16-QAM QPSK 2.56 M 10.24 5.12
1.6 MHz 16-QAM QPSK 1.28 M 5.12 2.56
The table below shows the maximum supported DOCSIS 2.0 (A-TDMA-mode) data rates.
Table 47: Maximum DOCSIS 2.0 (A-TDMA-mode) Data Rates
6.4 MHz 64-QAM 5.12 M 30.72

32-QAM 25.60
16-QAM 20.48
8-QAM 15.36
QPSK 10.24
3.2 MHz 64-QAM 2.56 M 15.36

32-QAM 12.80
16-QAM 10.24
8-QAM 7.68
QPSK 5.12
321
Modulation Profiles
1.6 MHz 64-QAM 1.28 M 7.68

32-QAM 6.40
16-QAM 5.12
8-QAM 3.84
QPSK 2.56
Modulation Profiles
To simplify the administration of A-TDMA and mixed TDMA/A-TDMA modulation profiles, the DOCSIS
2.0 A-TDMA Service feature provides a number of preconfigured modulation profiles that are optimized for
different modulation schemes. We recommend using these preconfigured profiles.
Each mode of operation also defines a default modulation profile that is automatically used when a profile is
not specifically assigned to an upstream. The default modulation profiles cannot be deleted. The table below
lists the valid ranges according to cable interface and modulation type:
Table 48: Allowable Ranges for Modulation Profiles
Cable Interface DOCSIS 1.X (TDMA) Mixed DOCSIS 1.X/2.0 DOCSIS 2.0 (A-TDMA)
Cisco cBR-8 CCAP Line Cards 1 to 400 (default is 21) 1 to 400 (default 121) 1 to 400 (default 221)
Benefits
The DOCSIS 2.0 A-TDMA Service feature provides the following benefits to cable service providers and
their partners and customers:
• Full compatibility with DOCSIS 1.0 and DOCSIS 1.1 cable modems (CMs) and cable modem termination
systems (CMTS).
• Additional channel capacity in the form of more digital bits of throughput capacity in the upstream path.
• Increased protection against electronic impairments that occur in cable systems, allowing for a more
robust operating environment.
How to Configure DOCSIS 2.0 A-TDMA Services

Creating Modulation Profiles

Cisco cable modem termination systems (CMTSs) can handle modulation profiles for the RF configuration
of a voice and data cable modem plant. Cisco IOS® Software is designed with a default modulation profile
that is optimal in most conditions. Therefore, do not change the default configuration. However, if the
modulation needs are different for the customer plant, Cisco IOS Software has the ability to customize and
to configure the modulation profiles to suit the customer needs.
322
Creating a TDMA Modulation Profile
Caution Only an expert, who understands modulation changes and Data-over-Cable Service Interface Specifications
(DOCSIS), should modify these parameters. Otherwise, changes can cause disruption or the degradation of
services because the commands affect the physical layer.
This section describes how to create modulation profiles for the different modes of DOCSIS operations, using
the preconfigured modulation profile options.
Creating a TDMA Modulation Profile

This section describes how to create a modulation profile for the DOCSIS 1.0/DOCSIS 1.1 TDMA mode of
operation, using one of the preconfigured modulation profiles.
Procedure

prompted.
Example:
Router> enable

Example:
Step 3 cable modulation-profile profile tdma {mix | qam-16 | Creates a preconfigured modulation profile, where the burst
qpsk | robust-mix} parameters are set to their default values for each burst type:
Example: Note You can also create custom modulation profiles
Router(config)# cable modulation-profile 3 tdma with the cable modulation-profile command
mix by configuring the values for the individual burst
Router(config)# cable modulation-profile 4 tdma parameters. These parameters, however, should
qpsk not be modified unless you are thoroughly
familiar with how changing each parameter
affects the DOCSIS MAC layer. We recommend
using the preconfigured default modulation
profiles for most cable plants.

Example:
Creating a Mixed Mode Modulation Profile

This section describes how to create a modulation profile for the mixed TDMA/A-TDMA mode of operation,
using one of the preconfigured modulation profiles.
323
Creating an A-TDMA Modulation Profile
Procedure

Router> enable

Example:
Step 3 cable modulation-profile profile mixed {mix-high | Creates a preconfigured modulation profile, where the burst
mix-low | mix-mid | mix-qam | qam-16 | qpsk | parameters are set to their default values for each burst type:
robust-mix-high | robust-mix-mid | robust-mix-qam}
Note The robust-mix profiles are similar to but more
Example: robust than the mix profiles, so that they are
Router(config)# cable modulation-profile 143 mixed more able to deal with noise on the upstream.
mix-medium
Router(config)# cable modulation-profile 144 mixed Note You can also create custom modulation profiles
mix-high with the cable modulation-profile command
by configuring the values for the individual burst
parameters. These parameters, however, should
not be modified unless you are thoroughly

Example:
Creating an A-TDMA Modulation Profile

This section describes how to create a modulation profile for the DOCSIS 2.0 A-TDMA mode of operation,
using one of the preconfigured modulation profiles.
Procedure

prompted.
Example:
Router> enable

Example:
324
Configuring the DOCSIS Mode and Profile on an Upstream

Step 3 cable modulation-profile profile atdma {mix-high | Note For Cisco Remote PHY 220, preamble with
mix-low | mix-mid | mix-qam | qam-8 | qam-16 | qam-32 QPSK modulation must have values—32x2^n
| qam-64 | qpsk | robust-mix-high | robust-mix-low | (0, 1, 2, 3) bits.
robust-mix-mid}
Preamble with 16-QAM modulation must have
Example: values—64x2^n (0, 1, 2,) bits.
Router(config)# cable modulation-profile 242 atdma
qam-32 Note The robust-mix profiles are similar to but more
Router(config)# cable modulation-profile 243 atdma robust than the mix profiles, so that they are
qam-64 more able to deal with noise on the upstream.
Example:
cable modulation-profile 45 tdma request 0 16 0 22
Note You can also create custom modulation profiles
qpsk scrambler 152 no-diff 64 fixed with the cable modulation-profile command
cable modulation-profile 45 tdma initial 5 34 0 48 by configuring the values for the individual burst
16qam scrambler 152 no-diff 256 fixed parameters. These parameters, however, should
cable modulation-profile 45 tdma station 5 34 0 48
16qam scrambler 152 no-diff 256 fixed not be modified unless you are thoroughly
cable modulation-profile 45 tdma short 3 76 12 22 familiar with how changing each parameter
16qam scrambler 152 no-diff 128 shortened affects the DOCSIS MAC layer. We recommend
cable modulation-profile 45 tdma long 9 232 0 22 using the preconfigured default modulation
16qam scrambler 152 no-diff 128 shortened
cable modulation-profile 45 tdma initial 5 34 0 48
16qam scrambler 152 no-diff 256 fixed
Note For Cisco Remote PHY 220, preamble with
QPSK modulation must have values—32x2^n
(0, 1, 2, 3) bits.
Preamble with 16-QAM modulation must have
values—64x2^n (0, 1, 2,) bits.

Example:
Configuring the DOCSIS Mode and Profile on an Upstream

This section describes how to configure an upstream for a DOCSIS mode of operation, and then to assign a
particular modulation profile to that upstream.
Note By default, all upstreams are configured for ATDMA-only mode, using the default modulation profile.
Procedure

prompted.
Example:
Router> enable
325
Monitoring the DOCSIS 2.0 A-TDMA Services

Example:
Step 3 controller upstream-Cable slot/subslot/port Enters controller configuration mode for the interface.
Example:
Router(config)# controller upstream-Cable 2/0/1
Step 4 us-channel n docsis-mode {atdma | tdma | tdma-atdma} Configures the upstream for the desired DOCSIS mode of
operation.
Example:
Router(config-controller)# us-channel 0 docsis-mode
atdma
Step 5 us-channel n modulation-profile primary-profile-number Assigns up to three modulation profiles to the upstream
[secondary-profile-number] [tertiary-profile-number] port.
Example: Note The type of modulation profiles must match the
Router(config-controller)# us-channel 0 DOCSIS mode configured for the upstream,
modulation-profile 241 using the us-channel docsis-mode command.
Step 6 us-channel n equalization-coefficient (Optional) Enables the use of a DOCSIS pre-equalization

coefficient on the upstream port.
Example:
equalization-coefficient
Step 7 us-channel n ingress-noise-cancellation interval (Optional) Configures the interval, in milliseconds, for
which the interface card should sample the signal on an
Example:
upstream to correct any ingress noise that has appeared on
Router(config-controller)# us-channel 0 that upstream.
ingress-noise-cancellation 400
Step 8 us-channel n maintain-psd (Optional) Requires DOCSIS 2.0 cable modems that are
operating on an ATDMA-only upstream to maintain a
Example:
constant power spectral density (PSD) after a modulation
Router(config-controller)# us-channel 0 rate change.
maintain-psd
Note Repeat Step 3, on page 326 through Step 8, on
page 326 for each upstream to be configured.
Step 9 end Exits controller configuration mode and returns to privileged

EXEC mode.
Example:
Monitoring the DOCSIS 2.0 A-TDMA Services

326
Displaying Modulation Profiles
Displaying Modulation Profiles

To display the modulation profiles that are currently defined on the CMTS, use the show cable
modulation-profile command without any options:
Router# show cable modulation-profile
Mod Docsis IUC Type Pre Diff FEC FEC Scrmb Max Guard Last Scrmb Pre Pre RS
-Mode len enco T k seed B time CW offst Type
BYTE BYTE siz size short
1 atdma request 16qam 32 no 0x0 0x10 0x152 0 22 no yes 0 qpsk1 no
1 atdma initial 16qam 64 no 0x5 0x22 0x152 0 48 no yes 0 qpsk1 no
1 atdma station 16qam 64 no 0x5 0x22 0x152 0 48 no yes 0 qpsk1 no
1 atdma a-short 16qam 64 no 0x4 0x4C 0x152 7 22 yes yes 0 qpsk1 no
1 atdma a-long 16qam 64 no 0x9 0xE8 0x152 0 22 yes yes 0 qpsk1 no
1 atdma a-ugs 16qam 64 no 0x9 0xE8 0x152 0 22 yes yes 0 qpsk1 no
2 atdma request 16qam 32 no 0x0 0x10 0x152 0 22 no yes 0 qpsk1 no
2 atdma initial 16qam 64 no 0x5 0x22 0x152 0 48 no yes 0 qpsk1 no
2 atdma station 16qam 64 no 0x5 0x22 0x152 0 48 no yes 0 qpsk1 no
21 tdma request qpsk 36 no 0x0 0x10 0x152 0 22 no yes 0 qpsk na
21 tdma initial qpsk 98 no 0x5 0x22 0x152 0 48 no yes 0 qpsk na
21 tdma station qpsk 98 no 0x5 0x22 0x152 0 48 no yes 0 qpsk na
21 tdma short qpsk 64 no 0x3 0x4C 0x152 12 22 yes yes 0 qpsk na
21 tdma long qpsk 64 no 0x9 0xE8 0x152 0 22 yes yes 0 qpsk na
121 mixed request qpsk 36 no 0x0 0x10 0x152 0 22 no yes 0 qpsk na
121 mixed initial qpsk 98 no 0x5 0x22 0x152 0 48 no yes 0 qpsk na
121 mixed station qpsk 98 no 0x5 0x22 0x152 0 48 no yes 0 qpsk na
121 mixed short qpsk 64 no 0x3 0x4C 0x152 12 22 yes yes 0 qpsk na
121 mixed long qpsk 64 no 0x9 0xE8 0x152 0 22 yes yes 0 qpsk na
121 mixed a-short 64qam 64 no 0x6 0x4C 0x152 6 22 yes yes 0 qpsk1 no
121 mixed a-long 64qam 64 no 0x9 0xE8 0x152 0 22 yes yes 0 qpsk1 no
121 mixed a-ugs 64qam 64 no 0x9 0xE8 0x152 0 22 yes yes 0 qpsk1 no
221 atdma request qpsk 36 no 0x0 0x10 0x152 0 22 no yes 0 qpsk0 no
221 atdma initial qpsk 98 no 0x5 0x22 0x152 0 48 no yes 0 qpsk0 no
221 atdma station qpsk 98 no 0x5 0x22 0x152 0 48 no yes 0 qpsk0 no
To display a specific modulation profile in detail, specify the profile number with the show cable
modulation-profile command:
Router# show cable modulation-profile 221
Mod Docsis IUC Type Pre Diff FEC FEC Scrmb Max Guard Last Scrmb Pre Pre RS
-Mode len enco T k seed B time CW offst Type
BYTE BYTE siz size short
221 atdma request qpsk 36 no 0x0 0x10 0x152 0 22 no yes 0 qpsk0 no
221 atdma initial qpsk 98 no 0x5 0x22 0x152 0 48 no yes 0 qpsk0 no
221 atdma station qpsk 98 no 0x5 0x22 0x152 0 48 no yes 0 qpsk0 no
Displaying Cable Modem Capabilities and Provisioning

To display the capabilities of the online cable modems and how the modems were provisioned, use the show
cable modem mac command:
327
Displaying Cable Modem Capabilities and Provisioning
Router# show cable modem mac
MAC Address MAC Prim Ver QoS Frag Concat PHS Priv DS US
State Sid Prov Saids Sids
1859.334d.7b4c init(i) 145 DOC1.0 DOC1.0 no no no 0 0
1859.334d.fa8c offline 146 DOC1.0 DOC1.0 no no no 0 0
1859.334d.fa02 offline 147 DOC1.0 DOC1.0 no no no 0 0
1859.334d.65b0 online(pt) 148 DOC3.0 DOC1.1 yes yes yes BPI+ 15 16
1859.334d.6622 offline 149 DOC1.0 DOC1.0 no no no 0 0
1859.334d.7a50 init(i) 150 DOC1.0 DOC1.0 no no no 0 0
1859.334d.7a2e offline 151 DOC1.0 DOC1.0 no no no 0 0
1859.334d.7d14 online(pt) 152 DOC2.0 DOC1.1 yes yes yes BPI+ 15 16
1859.334d.6636 online(pt) 153 DOC2.0 DOC1.1 yes yes yes BPI+ 15 16
1859.334d.7cf0 online(pt) 154 DOC2.0 DOC1.1 yes yes yes BPI+ 15 16
1859.334d.7b2a online(pt) 156 DOC2.0 DOC1.1 yes yes yes BPI+ 15 16
1859.334d.7e64 online(pt) 157 DOC2.0 DOC1.1 yes yes yes BPI+ 15 16
1859.334d.ede0 online(pt) 158 DOC2.0 DOC1.1 yes yes yes BPI+ 15 16
1859.334d.7b8a online(pt) 159 DOC2.0 DOC1.1 yes yes yes BPI+ 15 16
1859.334d.f93a online(pt) 161 DOC2.0 DOC1.1 yes yes yes BPI+ 15 16
1859.334d.7bf0 online(pt) 162 DOC2.0 DOC1.1 yes yes yes BPI+ 15 16
1859.334d.596a online(pt) 163 DOC2.0 DOC1.1 yes yes yes BPI+ 15 16
1859.334d.7d38 online(pt) 164 DOC2.0 DOC1.1 yes yes yes BPI+ 15 16
1859.334d.fc64 online(pt) 165 DOC2.0 DOC1.1 yes yes yes BPI+ 15 16
1859.334d.f62a online(pt) 167 DOC2.0 DOC1.1 yes yes yes BPI+ 15 16
!
To display how many cable modems of each DOCSIS type are online each upstream, use the show cable
modem mac summary command:
Router# show cable modem mac summary
Cable Modem Summary

-------------------
Mac Version QoS Provision Mode
Interface Total DOC3.0 DOC2.0 DOC1.1 DOC1.0 Reg/Online DOC1.1 DOC1.0
Cable3/0/1/U0 20 0 5 0 15 5 5 0
Cable3/0/1/U1 23 0 9 0 14 9 9 0
Cable3/0/1/U2 21 0 8 0 13 8 8 0
Cable3/0/1/U4 42 0 9 0 33 9 9 0
Cable3/0/1/U5 20 0 15 0 5 15 15 0
Cable3/0/1/U6 18 1 14 0 3 15 15 0
Cable3/0/2/U0 26 0 26 0 0 26 26 0
Cable3/0/2/U1 28 0 28 0 0 28 28 0
Cable3/0/2/U2 24 0 24 0 0 24 24 0
Cable3/0/2/U4 72 0 72 0 0 72 72 0
Cable3/0/3/U0 67 0 63 0 4 63 63 0
Cable3/0/3/U1 85 1 84 0 0 85 85 0
Cable3/0/3/U2 1 0 1 0 0 1 1 0
Cable3/0/4/U0 12 0 1 0 11 1 1 0
Cable3/0/4/U1 39 0 0 0 39 0 0 0
Cable3/0/4/U2 12 0 1 0 11 1 1 0
Cable3/0/4/U4 65 0 11 0 54 11 11 0
Cable3/0/4/U5 10 0 10 0 0 10 10 0
Cable3/0/4/U6 5 0 5 0 0 5 5 0
Cable3/0/5/U0 27 0 27 0 0 27 27 0
Cable3/0/5/U1 27 0 27 0 0 27 27 0
Cable3/0/5/U2 26 0 26 0 0 26 26 0
Cable3/0/5/U4 77 0 77 0 0 77 77 0
Cable3/0/6/U4 14 14 0 0 0 14 14 0
Cable3/0/6/U5 12 12 0 0 0 12 12 0
328
Configuration Examples for DOCSIS 2.0 A-TDMA services
Cable3/0/6/U6 5 5 0 0 0 5 5 0
Configuration Examples for DOCSIS 2.0 A-TDMA services

Creating Modulation Profiles Examples

Example: DOCSIS 1.0/DOCSIS 1.1 TDMA Modulation Profiles

The following sample configurations show typical modulation profiles for the DOCSIS 1.0/DOCSIS 1.1
TDMA mode of operation:
• Profile 21 is the default profile for TDMA operations.
• Profiles 24 and 25 use the preconfigured 16-QAM and QPSK modulation profiles.
• Profile 26 is a typical QPSK modulation profile using some customized burst parameters.
cable modulation-profile 24 tdma qam-16
cable modulation-profile 25 tdma qpsk
cable modulation-profile 26 tdma request 0 16 0 8 qpsk scrambler 152 no-diff 68 fixed
cable modulation-profile 26 tdma initial 5 34 0 48 qpsk scrambler 152 no-diff 128 fixed
cable modulation-profile 26 tdma station 5 34 0 48 qpsk scrambler 152 no-diff 128 fixed
cable modulation-profile 26 tdma short 4 76 12 8 qpsk scrambler 152 no-diff 80 shortened
cable modulation-profile 26 tdma long 8 236 0 8 qpsk scrambler 152 no-diff 80 shortened
Example: Mixed TDMA/A-TDMA Modulation Profiles

The following sample configurations show typical modulation profiles for the DOCSIS 1.X/DOCSIS 2.0
mixed TDMA/A-TDMA mode of operation:
• Profile 121 is the default profile for mixed mode operations.
• Profiles 122 through 126 use the preconfigured mixed mode modulation profiles.
• Profile 127 is a typical mixed mode modulation profile some customized burst parameters.
cable modulation-profile 121 mixed request 0 16 0 8 qpsk scrambler 152 no-diff 64 fixed
cable modulation-profile 121 mixed initial 5 34 0 48 qpsk scrambler 152 no-diff 32 fixed
cable modulation-profile 121 mixed station 5 34 0 48 qpsk scrambler 152 no-diff 32 fixed
cable modulation-profile 121 mixed short 5 75 6 8 qpsk scrambler 152 no-diff 72 shortened
cable modulation-profile 121 mixed long 8 220 0 8 qpsk scrambler 152 no-diff 80 shortened
cable modulation-profile 121 mixed a-short 0 16 15 99 64qam scrambler 152 no-diff 128
shortened qpsk0 0 18
cable modulation-profile 121 mixed a-long 0 16 15 200 64qam scrambler 152 no-diff 128
shortened qpsk0 0 18
cable modulation-profile 122 mixed mix-high

cable modulation-profile 123 mixed mix-low
cable modulation-profile 124 mixed mix-medium
cable modulation-profile 125 mixed qam-16
cable modulation-profile 126 mixed qpsk
cable modulation-profile 127 mixed request 0 16 0 8 qpsk scrambler 152 no-diff 68 fixed
cable modulation-profile 127 mixed initial 5 34 0 48 qpsk scrambler 152 no-diff 128 fixed
cable modulation-profile 127 mixed station 5 34 0 48 qpsk scrambler 152 no-diff 128 fixed
cable modulation-profile 127 mixed short 6 76 7 8 16qam scrambler 152 no-diff 160 shortened
329
Example: DOCSIS 2.0 A-TDMA Modulation Profiles
cable modulation-profile 127 mixed long 8 231 0 8 16qam scrambler 152 no-diff 160 shortened
cable modulation-profile 127 mixed a-short 9 76 6 8 32qam scrambler 152 no-diff 160 shortened
qpsk1 1 2048
cable modulation-profile 127 mixed a-long 12 231 0 8 64qam scrambler 152 no-diff 132 shortened
qpsk1 1 2048
Example: DOCSIS 2.0 A-TDMA Modulation Profiles

The following sample configurations show typical modulation profiles for the DOCSIS 2.0 A-TDMA mode
of operation:
• Profile 221 is the default profile for A-TDMA mode operations.
• Profiles 222 through 226 use the preconfigured A-TDMA mode modulation profiles.
• Profile 227 is a typical A-TDMA mode modulation profile customized burst parameters.
cable modulation-profile 221 atdma request 0 16 0 8 qpsk scrambler 152 no-diff 64 fixed
qpsk0 0 18
cable modulation-profile 221 atdma initial 5 34 0 48 qpsk scrambler 152 no-diff 32 fixed
qpsk0 0 18
cable modulation-profile 221 atdma station 5 34 0 48 qpsk scrambler 152 no-diff 32 fixed
qpsk0 0 18
cable modulation-profile 221 atdma short 5 75 6 8 qpsk scrambler 152 no-diff 72 shortened
qpsk0 0 18
cable modulation-profile 221 atdma long 8 220 0 8 qpsk scrambler 152 no-diff 80 shortened
qpsk0 0 18
cable modulation-profile 221 atdma a-short 5 99 10 8 64qam scrambler 152 no-diff 128 shortened
qpsk0 0 18
cable modulation-profile 221 atdma a-long 15 200 0 8 64qam scrambler 152 no-diff 128 shortened
qpsk0 0 18
cable modulation-profile 222 atdma qam-8

cable modulation-profile 226 atdma qpsk
cable modulation-profile 227 atdma request 0 16 0 8 qpsk scrambler 152 no-diff 68 fixed
qpsk0 1 2048
cable modulation-profile 227 atdma initial 0 16 0 0 qpsk no-scrambler no-diff 2 fixed qpsk1
0 18
cable modulation-profile 227 atdma station 5 34 0 48 qpsk scrambler 152 no-diff 128 fixed
qpsk0 1 2048
cable modulation-profile 227 atdma a-short 9 76 6 8 32qam scrambler 152 no-diff 160 shortened
qpsk1 1 2048
cable modulation-profile 227 atdma a-long 12 231 0 8 64qam scrambler 152 no-diff 132 shortened
qpsk1 1 2048
cable modulation-profile 227 atdma a-ugs 3 231 0 8 16qam scrambler 152 no-diff 80 shortened
qpsk1 1 2048
Assigning Modulation Profiles to Upstreams Examples

330
Example: Assigning DOCSIS 1.0/DOCSIS 1.1 TDMA Modulation Profiles
Example: Assigning DOCSIS 1.0/DOCSIS 1.1 TDMA Modulation Profiles

The following sample configuration shows DOCSIS 1.0/DOCSIS 1.1 TDMA modulation profiles being
assigned to the upstreams. The TDMA modulation profile (profile 21) is assigned to the upstream controller
2/0/0.
!
Example: Assigning Mixed TDMA/A-TDMA Modulation Profiles

The following sample configuration shows mixed mode TDMA/A-TDMA modulation profiles being assigned
to the upstreams. The mixed modulation profile (profile 121) is assigned to the upstream controller 2/0/15.
us-channel 0 docsis-mode tdma-atdma
!
Example: Assigning DOCSIS 2.0 A-TDMA Modulation Profiles

The following sample configuration shows DOCSIS 2.0 A-TDMA modulation profiles being assigned to the
upstreams. The A-TDMA modulation profile (profile 221) is assigned to the upstream controller 2/0/10.
331

us-channel 4 shutdown
!
Related Documents
Cisco CMTS Commands Cisco IOS CMTS Cable Command Reference

http://www.cisco.com/en/US/docs/ios/cable/command/reference/cbl_book.html
Standards
Standards Title
SP-RFIv1.1-I09-020830 Data-over-Cable Service Interface Specifications Radio Frequency Interface

Specification, version 1.1

SP-OSSIv2.0-I03-021218 Data-over-Cable Service Interface Specifications Operations Support System

Interface Specification, version 2.0
332
Feature Information for DOCSIS 2.0 A-TDMA Modulation Profile
Standards Title
SP-BPI+-I09-020830 Data-over-Cable Service Interface Specifications Baseline Privacy Plus Interface

RFC 2233 DOCSIS OSSI Objects Support
RFC 2665 DOCSIS Ethernet MIB Objects Support
RFC 2669 Cable Device MIB
MIBs
MIBs MIBs Link
• DOCS-BPI-PLUS-MIB To locate and download MIBs for selected platforms, Cisco

• DOCS-CABLE-DEVICE-MIB (RFC IOS releases, and feature sets, use Cisco MIB Locator found
2669) at the following URL:
• DOCS-CABLE-DEVICE-TRAP-MIB http://www.cisco.com/go/mibs
• DOCS-IF-EXT-MIB
• DOCS-IF-MIB (RFC 2670)
• DOCS-QOS-MIB
• DOCS-SUBMGT-MIB
• IGMP-STD-MIB (RFC 2933)
Description Link
ID and password.

333
Table 49: Feature Information for DOCSIS 2.0 A-TDMA Modulation Profile
DOCSIS 2.0 A-TDMA Cisco IOS XE Fuji This feature was integrated on the cisco cBR
Modulation Profile 16.7.1 Series Converged Broadband Routers.
334
CHAPTER 20
Downstream Resiliency Bonding Group
With more wideband (WB) modems being deployed in cable plants, WB modem resiliency is an important
feature. When a comparatively smaller number of cable modems (CMs) observe an impairment on an RF
channel, that RF channel stops working. It impacts all the CM using that RF channel, irrespective of whether
they reported the impairment on that RF channel. Instead, the solution should be to communicate with the
affected cable modems using the good RF channel, without affecting the other cable modems.
The Downstream Resiliency Bonding Group feature allows cable modems with multiple impaired RF channels
to be allocated to a dynamically-created wideband interface, which ensures that the performance of the
wideband cable modems is not drastically affected.
Contents
• Prerequisites for Downstream Resiliency Bonding Group, on page 337
• Restrictions for the Downstream Resiliency Bonding Group, on page 337
• Information About Downstream Resiliency Bonding Group, on page 338
• How to Configure Downstream Resiliency Bonding Group, on page 339
• Verifying Downstream Resiliency Bonding Group Configuration, on page 341
• Troubleshooting the Downstream Resiliency Bonding Group Configuration, on page 346
• Configuration Examples for the Downstream Resiliency Bonding Group, on page 346
• Feature Information for Downstream Resiliency Bonding Group, on page 350
335
Digital PICs:

Module:

Modules:
336
Prerequisites for Downstream Resiliency Bonding Group
line card reload.
Prerequisites for Downstream Resiliency Bonding Group

• Set aside WB interfaces so that new WB interfaces can be dynamically created from the reserved list of
WB interfaces.
• Free up RF bandwidth so that those RF channels can be added to a resiliency bonding group (RBG).
• Remove all existing RBG configuration from the WB interface.
Restrictions for the Downstream Resiliency Bonding Group

• If an existing wideband interface is reserved as a Resiliency Bonding Group (RBG) and later the RBG
is removed (through the no cable ds-resiliency command), the modems using this RBG go offline and
the RBG configuration itself is deleted. Therefore, it is highly recommended that users should not
configure an existing BG as an RBG.
• This feature is enabled only when the number of cable modems observing an RF channel impairment is
below the resiliency threshold. If the number of cable modems on an impaired RF channel is above the
resiliency threshold, the impaired RF channel is temporarily removed from the bonding group.
• A cable modem is assigned to an RBG on a first-come-first-served basis. To handle this feature optimally,
it is recommended to set aside more WB interfaces and RF channel bandwidth.
• The Cisco CMTS controls the freeing of unused RBGs, when there is no modem using the RGB. The
freeing of the unused RGB may take some time and the RGB, which is not completely free cannot be
used by the modems. Irrespective of the number of configured RBGs, if all the old RBGs are not
completely set free and if the Cisco CMTS tries to move the cable modem to a new RBG, the Cisco
CMTS moves the cable modem to the primary DS channel instead of RBG.
• Only SFs on the WB interface associated with the primary SF are moved to an RBG. SFs on other
interfaces will not be moved.
• Static SFs are assigned to an RBG on a best effort quality of service (QoS).
• If the resiliency rf-change-trigger setting does not have the secondary keyword set, only the primary
SF is moved to the RBG or a NB interface.
• If the Downstream Resiliency Bonding Group feature is not enabled to use an RBG, only cable modems
with impairments on the primary WB interface are moved to the NB interface.
• SFs carrying multicast traffic are not moved.
337
Information About Downstream Resiliency Bonding Group
There may not be enough reserved bonding groups to support all modems facing an impairment at any given
time thus the following restrictions must be considered:
• Each RBG has at least two RF channels.
• RBG RF assignments are always a subset of the RF channel assignment of the parent WB interface.
• If an RBG is unavailable for a cable modem, the SF of the CM is moved to a NB interface.
• If a high percentage of cable modems experience an RF impairment and there are no more available
bonding group IDs, the impaired RF itself may be removed from the bonding group. Removal of an
impaired RF from a parent bonding group is also reflected in the RBG. If an RBG drops to a single RF,
all SFs are moved to the NB interface.
The Downstream Resiliency Bonding Group feature has the following cross-functional restrictions:
• All Dynamic service flows, whether they require a committed information rate (CIR) or not, typically
voice flows, are created on the NB interface when an RF channel is impaired. Because all SFs assigned
to an RBG are best effort only, voice calls may report a quality issue.
• Cable modems participating in the resiliency mode do not take part in load balancing.
• The Downstream Resiliency Bonding Group feature is only supported in the Dynamic Bandwidth Sharing
(DBS) mode.
Information About Downstream Resiliency Bonding Group

You can set aside unused bonding groups as RBGs. Ensure that each RF channel is assigned at least 1% of
the available bandwidth. Use the cable rf-channel bandwidth-percent command to configure the RF channel
bandwidth.
Note If the bandwidth-percent is set to 100, the Cisco CMTS does not add any RFs to the RBG. In other words,
this feature will not be enabled.
The Cisco CMTS controls the assignment and freeing of unused RBGs. If an RF channel is removed from a
WB interface, it is also removed from any associated RBGs.
Note If the wideband interface is in standby mode, the Cisco CMTS does not assign or free up the unused downstream
bonding group.
A suspended RF channel is restored for all affected wideband interfaces when a specified number of cable
modems report (via CM-STATUS) that the channel connectivity is restored. The Wideband Modem Resiliency
feature defines the specified number of cable modems as half of the configured count or percentage of
rf-change-trigger, or both. For example, if the count is 20 and the percent is 10, then the number of cable
modems reporting recovery should reduce the count to 10 and the percent to 5 for the suspended RF channel
to be restored.
338
Finding a Best-Fit RBG for the Cable Modem
Finding a Best-Fit RBG for the Cable Modem

A bonding group is a list of channels that provide a means to identify the channels that are bonded together.
The Cisco CMTS assigns a service flow (SF) to an RBG based on the attributes of the SF and the attributes
of the individual channels of the bonding group.
In the Downstream Resiliency Bonding Group feature, when a line card receives a CM-STATUS message
from the cable modem informing the line card that there is an RF channel impairment, the line card checks
for the number of good RF channels and:
• Moves the cable modem to narrowband mode if there is only one available RF channel.
• Moves the cable modem to wideband mode if the cable modem reports all RF channels are in good state.
• Moves the cable modem to an RBG if there are two or more good RF channels, with at least one RF
channel impaired, and if the Downstream Resiliency Bonding Group feature is enabled.
When the Cisco CMTS receives a message from the line card to move a cable modem to an RBG, the Cisco
CMTS attempts to find an existing RBG or creates an RBG that satisfies the impairment.
Note If two or more RBGs are reserved for the same wideband controller, the Cisco CMTS creates one RBG for
each cable modem.
Note The Cisco CMTS creates more than one RBG from a parent WB interface if the user has set aside more than
one WB interface as the RBG and the RF bandwidth does not exceed 100%.
If a matching RBG is not found or cannot be created, the Cisco CMTS looks for an RBG with a subset of the
required RF channels and if available, the cable modem is assigned to such an RBG.
However, if no such RBG exists, the Cisco CMTS instructs the line card to move the cable modem to NB
mode.
How to Configure Downstream Resiliency Bonding Group

Enabling Downstream Resiliency Bonding Group

Procedure

Router> enable
339
Reserving a Resiliency Bonding Group for a Line Card

Example:
Step 3 cable rf-change-trigger {percent value | count number} Specifies the amount of time an event must persist before
[secondary] it triggers an action for the reporting CM.
Example:
Router(config)# cable rf-change-trigger percent 50
count 1 secondary
Step 4 cable resiliency ds-bonding Enables the downstream resiliency bonding group.
Example:
Router(config)# cable resiliency ds-bonding
Step 5 exit Returns to the global configuration mode.

Example:
What to do next
Note The result of using the cable rf-change-trigger command with the cable resiliency ds-bonding command
is different from using only the cable rf-change-trigger command. For more information, see Downstream
Resiliency Narrowband Mode Versus Resiliency Bonding Group, on page 342.
Reserving a Resiliency Bonding Group for a Line Card

This section describes reserving a bonding group or a wideband interface for a line card per controller.
Restriction When you reserve a resiliency bonding group using the cable ds-resiliency command, the existing bundle and
RF channel configurations on the wideband interface will be removed automatically. Other configurations
like admission control, should be removed manually.
After downstream resiliency bonding group is configured, avoid other manual configurations.
Procedure

Router> enable
340
Verifying Downstream Resiliency Bonding Group Configuration

Example:
Step 3 interface wideband-cable Configures a wideband cable interface.

slot/subslot/port:wideband-channel
Example:
Step 4 cable ds-resiliency Reserves an individual bonding group or WB interface for

usage on a line card, on a per controller basis.
Example:
Router(config-if)# cable ds-resiliency

Example:
Router(config-if)# exit
Verifying Downstream Resiliency Bonding Group Configuration

Verifying the Downstream Resiliency Bonding Group

To verify if the Downstream Resiliency Bonding Group feature is enabled, use the show cable modem
resiliency command as shown in the following example:
Router# show cable modem resiliency

Orig BG Curr BG
I/F MAC Address ID I/F RFs ID I/F RFs
------- -------------- ---------------------- ----------------------
C7/0/0 0025.2eaf.843e 897 Wi7/0/0:0 4 898 Wi7/0/0:1 3
C7/0/0 0025.2eaf.8356 897 Wi7/0/0:0 4 899 Wi7/0/0:2 3
C7/0/0 0015.d176.5199 897 Wi7/0/0:0 4 720 In7/0/0:0
The Current BG I/F field indicates whether Downstream Resiliency Bonding Group feature is enabled and
if the cable modems are assigned to a WB interface.
Verifying a Reserved Resiliency Bonding Group

To verify if a BG is reserved for a line card, use the show cable resiliency command as shown in the following
example:
Router# show cable resiliency

BG Resil BG RF
Resil BG I/F ID State Count Time Ctrl Num
341
Downstream Resiliency Narrowband Mode Versus Resiliency Bonding Group
------------- ---- -------------- ----- --------------- ----------

Wi1/0/0:10 10 Free
Wi1/0/0:20 20 Free
Wi7/0/0:1 1 Assigned 3 Nov 3 09:55:49 0 0
1
2
Wi7/0/0:2 2 Assigned 3 Nov 3 09:57:09 0 0
1
3

This section provides the sample outputs when using the cable rf-change-trigger command with the cable
resiliency ds-bonding command and using only the cable rf-change-trigger command.
Table 51: Downstream Resiliency Narrowband Mode Versus Resiliency Bonding Group - Scenario 1
Effect on Using only cable rf-change-trigger command Using cable rf-change-trigger command with cable
resiliency ds-bonding
(Downstream Resiliency NB Mode)
(Downstream Resiliency Bonding Group)
Below Threshold Above Threshold Below Threshold Above Threshold
Primary Moves to the primary Remains on the original bonding Moves to dynamic Remains on the original bonding
Service Flow channel. group while the impaired bonding group. group while the impaired
downstream channels are not downstream channels are not used
used and are reported as DOWN. and are reported as DOWN.
Secondary Remain on the Remains on the original bonding Remains on the original Remains on the original bonding
Service Flows original WB group while the impaired bonding group. group while the impaired
interface. downstream channels are not downstream channels are not used
used and are reported as DOWN. and are reported as DOWN.
The following is a sample output for a cable modem when the cable rf-change-trigger command is used
with the cable resiliency ds-bonding command and the number of cable modems observing an RF channel
impairment is below the resiliency threshold:
D
MAC Address IP Address I/F MAC Prim RxPwr Timing Num I
State Sid (dBmv) Offset CPE P
0023.be83.1c9e 10.1.11.46 C5/0/0/UB w-online 922 -0.50 1055 0 N
0023.be83.1caa 10.1.11.28 C5/0/0/UB w-online 923 0.00 1043 0 N
0025.2ecf.f19c 10.1.11.53 C5/0/0/UB w-online 925 0.00 1057 0 N
0022.3a30.9fc0 10.1.11.47 C5/0/0/UB w-online 926 0.00 1055 0 N
001a.c3ff.e3d4 10.1.11.39 C5/0/0/UB p-online 927 0.00 1307 0 N
0023.be83.1c9a 10.1.11.61 C5/0/0/UB w-online 928 0.00 1057 0 N
0022.3a30.9fbc 10.1.11.60 C5/0/0/UB p-online 929 -0.50 1055 0 N
0023.be83.1c8c 10.1.11.38 C5/0/0/UB w-online 930 0.00 1061 0 N
001e.6bfb.1964 10.1.11.63 C5/0/0/UB p-online 931 0.50 1305 0 N
0025.2ecf.f196 10.1.11.29 C5/0/0/UB w-online 932 0.00 1057 0 N
0025.2ecf.f04e 10.1.11.54 C5/0/0/UB w-online 933 0.00 1054 0 N
0022.3a30.9fc8 10.1.11.43 C5/0/0/UB w-online 934 0.00 1056 0 N
0025.2ecf.f190 10.1.11.55 C5/0/0/UB w-online 935 0.00 1059 0 N
0022.3a30.9fd0 10.1.11.52 C5/0/0/UB p-online 936 0.00 1057 0 N
342
0022.ce97.8268 10.1.11.31 C5/0/0/UB w-online 937 -0.50 1056 0 N

0022.ce97.8281 10.1.11.25 C5/0/0/UB w-online 938 0.00 1058 0 N
001a.c3ff.e4ce 10.1.11.44 C5/0/0/UB w-online 940 -0.50 1304 0 N
0022.ce9c.839e 10.1.11.32 C5/0/0/UB w-online 941 -0.50 1305 0 N
0022.cea3.e768 10.1.11.41 C5/0/0/UB w-online 942 -1.00 1305 0 N
0022.ce9c.8398 10.1.11.33 C5/0/0/UB w-online 943 0.00 1306 0 N
001a.c3ff.e50a 10.1.11.59 C5/0/0/UB w-online 944 0.00 1304 0 N
001a.c3ff.e3f8 10.1.11.57 C5/0/0/UB w-online 945 -1.00 1306 0 N
001e.6bfb.1a14 10.1.11.37 C5/0/0/UB w-online 946 0.00 1305 0 N
Note p-online indicates that cable modem has reported NP RF failure and it is in downstream partial service mode.
BG Resil BG RF
------------- ---- -------------- ----- --------------- ----------
Wi5/0/0:2 2 Assigned 1 Mar 30 14:46:43 0 0
1
2
Wi5/0/0:3 3 Assigned 1 Mar 30 14:46:43 0 0
1
2
1 0
1
2
3
Wi5/0/0:4 4 Free 0
Wi5/0/0:5 5 Free 0

Orig BG Curr BG
------- -------------- ---------------------- ----------------------
C5/0/0 001a.c3ff.e3d4 258 Wi5/0/0:1 4 259 Wi5/0/0:2 3 <- Dynamic Bonding Group
C5/0/0 0022.3a30.9fbc 257 Wi5/0/0:0 8 260 Wi5/0/0:3 7 <- Dynamic Bonding Group
C5/0/0 001e.6bfb.1964 258 Wi5/0/0:1 4 259 Wi5/0/0:2 3 <- Dynamic Bonding Group
C5/0/0 0022.3a30.9fd0 257 Wi5/0/0:0 8 260 Wi5/0/0:3 7 <- Dynamic Bonding Group
The following is a sample output for a cable modem under the following conditions:
• cable rf-change-trigger command is used with the cable resiliency ds-bonding command
• Number of cable modems observing an RF channel impairment is below the resiliency threshold
• There is no available WB interface for the resiliency bonding group:

0025.2ecf.f196 service-flow version
SUMMARY:
MAC Address IP Address Host MAC Prim Num Primary DS
Interface State Sid CPE Downstream RfId
0025.2ecf.f196 10.1.11.29 C5/0/0/UB p-online
932 0 In5/0/0:0 240
Sfid Dir Curr Sid Sched Prio MaxSusRate MaxBrst MinRsvRate Throughput
343
State Type
1867 US act 932 BE 0 0 10000 0 294
1868 DS act N/A N/A 0 0 3044 0 154

BG Resil BG RF
------------- ---- -------------- ----- --------------- ----------
Wi5/0/0:2 2 Assigned 6 Mar 30 15:57:09 0 0
1
2
3
1 0
2
3
Wi5/0/0:3 3 Assigned 8 Mar 30 15:53:58 0 0
1
2
1 1
2
3
Wi5/0/0:4 4 Assigned 2 Mar 30 15:53:58 0 0
1
2
3
1 1
2
3
Wi5/0/0:5 5 Assigned 2 Mar 30 15:58:35 0 0
1
2
3
1 0
1
3
Orig BG Curr BG
------- -------------- ---------------------- ----------------------
C5/0/0 0025.2ecf.f19c 257 Wi5/0/0:0 8 259 Wi5/0/0:2 7
C5/0/0 0025.2ecf.f196 257 Wi5/0/0:0 8 240 In5/0/0:0 <-- move NB for no available
WB interface
C5/0/0 0025.2ecf.f04e 257 Wi5/0/0:0 8 262 Wi5/0/0:5 7
C5/0/0 0022.3a30.9fbc 257 Wi5/0/0:0 8 260 Wi5/0/0:3 6
C5/0/0 0022.3a30.9fd0 257 Wi5/0/0:0 8 261 Wi5/0/0:4 7
Table 52: Downstream Resiliency Narrowband Mode Versus Resiliency Bonding Group - Scenario 2
Effect on Using only cable rf-change-trigger secondary Using cable rf-change-trigger secondary command with
command cable resiliency ds-bonding
(Downstream Resiliency NB Mode) (Downstream Resiliency Bonding Group)
Below Threshold Above Threshold Below Threshold Above Threshold
344
Effect on Using only cable rf-change-trigger secondary Using cable rf-change-trigger secondary command with
command cable resiliency ds-bonding
(Downstream Resiliency NB Mode) (Downstream Resiliency Bonding Group)
Primary Service Moves all service flows Remains on the original Moves all service flows to Remains on the original
Flow to the primary channel. bonding group while the a dynamic bonding group. bonding group while the
impaired downstream impaired downstream
Secondary Service channels are not used and channels are not used and are
Flows are reported as DOWN. reported as DOWN.
The following is a sample output for a cable modem when the cable rf-change-trigger secondary command
is used with the cable resiliency ds-bonding command and the number of cable modems observing an RF
channel impairment is below the resiliency threshold:
Router# show cable modem 0025.2ecf.f196 service-flow
SUMMARY:
MAC Address IP Address Host MAC Prim Num Primary DS
Interface State Sid CPE Downstream RfId
0025.2ecf.f196 10.1.11.29 C5/0/0/UB p-online 955 0 In5/0/0:0 240
State Type
1913 US act 955 BE 0 10000000 10000 0 425
1915 US act 956 RTPS 7 0 3044 100000 0
1916 US act 957 BE 0 0 3044 50000 0
1917 US act 958 BE 4 0 3044 0 0
1914 DS act N/A N/A 0 100000000 20000 0 0 <-- Primary
Service-Flow
1918 DS act N/A N/A 0 0 3044 0 0 <-- Secondary
Service-Flow
Service-Flow
Service-Flow
UPSTREAM SERVICE FLOW DETAIL:
SFID SID Requests Polls Grants Delayed Dropped Packets
Grants Grants
1913 955 83 0 83 0 0 92
1915 956 0 0 0 0 0 0
1916 957 0 0 0 0 0 0
1917 958 0 0 0 0 0 0
DOWNSTREAM SERVICE FLOW DETAIL:
SFID RP_SFID QID Flg Policer Scheduler FrwdIF
Xmits Drops Xmits Drops
1914 33210 131555 90 0 6 0 Wi5/0/0:3 <-- Dynamic
Bonding Group
1918 33211 131556 0 0 0 0 Wi5/0/0:3
1919 33212 131557 0 0 0 0 Wi5/0/0:3
1920 33213 131558 0 0 0 0 Wi5/0/0:3
345
Troubleshooting the Downstream Resiliency Bonding Group Configuration
Troubleshooting the Downstream Resiliency Bonding Group

Configuration
Use the following commands to get information on the WB interface, number of CMs in an impaired state,
resiliency bonding groups, their associated bonding groups, available RF channels, and the number of CMS
and service flows assigned to them:
• debug cable wbcmts resiliency
• debug cable wbcmts resiliency report
• show cable resiliency
• show cable modem resiliency
• show cable modem wideband rcs-status
• show cable modem service-flow verbose
• show cable resil-rf-status
• show cable modem summary wb-rfs
In case the CPU usage of the downstream resiliency process is high, use following commands to optimize the
downstream resiliency bonding group configuration:
• cable rf-change-up-multiplier value - The default value is 2. Use this command to set the rf-channel
up dampen time as an integer multiplier of the rf-channel down dampen time, in order to lengthen the
recovery time to keep certain modems from falling back into DOWN state shortly after recovery.
• cable resiliency free-interval seconds - The recommended value is 360. Use this command to set the
wait time before a created resiliency bonding group is freed/recycled, in order to hold the resiliency
bonding group up long enough for it to be reused by impaired cable modems.
Configuration Examples for the Downstream Resiliency Bonding

Group
The following is an example of the configuration of the Downstream Resiliency Bonding Group feature:
cable rf-change-trigger count 10 secondary
cable resiliency ds-bonding
!
us-channel 0 power-level -1
346
Configuration Examples for the Downstream Resiliency Bonding Group

!
max-carrier 128
rf-chan 0
type DOCSIS
frequency 381000000
rf-output NORMAL
power-adjust -2
docsis-channel-id 1
qam-profile 1
rf-chan 1 3
type DOCSIS
frequency 387000000
rf-output NORMAL
power-adjust 0
docsis-channel-id 2
qam-profile 1
rf-chan 32 35
type DOCSIS
frequency 477000000
rf-output NORMAL
power-adjust 0
docsis-channel-id 33
qam-profile 1
rf-chan 64 67
type DOCSIS
frequency 501000000
rf-output NORMAL
power-adjust 0
qam-profile 1
rf-chan 96 99
type DOCSIS
frequency 669000000
rf-output NORMAL
power-adjust 0
qam-profile 1
!
downstream Integrated-Cable 9/0/1 rf-channel 0-3
downstream Integrated-Cable 9/0/1 rf-channel 32-35
347

upstream 0
upstream 1
upstream 2
attributes 80000000
upstream 0
upstream 1
attributes 80000000
upstream 1
upstream 2
attributes 80000000
upstream 0
upstream 2
attributes 80000000
attributes 80000000
cable bundle 1
no cable mtc-mode
cable privacy accept-self-signed-certificate
end
!
interface Integrated-Cable9/0/1:0
cable bundle 1
cable rf-bandwidth-percent 65
!
interface Wideband-Cable9/0/1:0
cable bundle 1
cable rf-channels channel-list 0-3 bandwidth-percent 20
!
interface Integrated-Cable9/0/1:1
cable bundle 1
!
cable bundle 1
!
!
cable ds-resiliency
!
cable ds-resiliency
!
cable ds-resiliency
!
The following is a sample output for the show cable modem command to display impaired cable modems
below the resiliency threshold value:

e448.c70c.96d5 80.17.150.6 C9/0/1/U2 p-online 1 0.00 1784 0 N
e448.c70c.96f3 80.17.150.14 C9/0/1/U1 w-online 2 -1.00 1797 0 N
348
68ee.9633.0699 80.17.150.31 C9/0/1/U0 w-online 3 -1.00 2088 1 N

e448.c70c.96e7 80.17.150.29 C9/0/1/U3 p-online 4 -0.50 1785 0 N
e448.c70c.982b 80.17.150.18 C9/0/1/U2 w-online 5 0.00 1780 0 N
e448.c70c.9804 80.17.150.13 C9/0/1/U3 w-online 6 -0.50 1788 0 N
e448.c70c.9819 80.17.150.30 C9/0/1/U0 w-online 7 -1.00 1782 0 N
e448.c70c.980d 80.17.150.17 C9/0/1/U0 w-online 8 -1.00 1787 0 N
Note p-online indicates that the cable modem has reported NP RF failure and it is in downstream partial service
mode.
The following is a sample output when RBGs are created:

BG Resil BG RF
------------- ----- -------------- ----- --------------- ----------
Wi9/0/1:60 28989 Assigned 1 Jan 9 07:35:08 1 0
1
2
Wi9/0/1:61 28990 Assigned 1 Jan 9 07:36:54 1 0
1
3
Wi9/0/1:62 28991 Free 0
The following is a sample output when cable modems service flows are assigned to RBGs:
Orig BG Curr BG
------- -------------- ----------------------- -----------------------
C9/0/1 e448.c70c.96d5 28929 Wi9/0/1:0 4 28989 Wi9/0/1:60 3
C9/0/1 e448.c70c.96e7 28929 Wi9/0/1:0 4 28990 Wi9/0/1:61 3
The following is a sample output of the show cable modem command when the impaired cable modems have
recovered:

e448.c70c.96d5 80.17.150.6 C9/0/1/U2 w-online 1 0.00 1784 0 N
e448.c70c.96f3 80.17.150.14 C9/0/1/U1 w-online 2 -1.00 1797 0 N
68ee.9633.0699 80.17.150.31 C9/0/1/U0 w-online 3 -1.00 2088 1 N
e448.c70c.96e7 80.17.150.29 C9/0/1/U3 w-online 4 -0.50 1785 0 N
e448.c70c.982b 80.17.150.18 C9/0/1/U2 w-online 5 0.00 1780 0 N
e448.c70c.9804 80.17.150.13 C9/0/1/U3 w-online 6 -0.50 1788 0 N
e448.c70c.9819 80.17.150.30 C9/0/1/U0 w-online 7 -1.00 1782 0 N
e448.c70c.980d 80.17.150.17 C9/0/1/U0 w-online 8 -1.00 1787 0 N
The following is a sample output of the show cable resiliency command when the impaired cable modems
have recovered:
BG Resil BG RF
349
------------- ----- -------------- ----- --------------- ----------

Wi9/0/1:60 28989 Free 1 Jan 9 07:35:08
Wi9/0/1:61 28990 Free 1 Jan 9 07:36:54
Wi9/0/1:62 28991 Free 0
Related Documents
Cisco CMTS Command Reference http://www.cisco.com/c/en/us/td/docs/cable/cmts/cmd_ref/b_cmts_cable_cmd_ref.htm
Description Link

Feature Information for Downstream Resiliency Bonding Group

Table 53: Feature Information for Downstream Resiliency Bonding Group
Downstream Resiliency Bonding Cisco IOS XE Fuji 16.7.1 This feature was integrated on the Cisco cBR
Group Series Converged Broadband Routers.
Resiliency Bonding Group Cisco IOS XE Gibraltar This feature was integrated on the Cisco cBR
Enhancement 16.12.1y Series Converged Broadband Routers.
350
CHAPTER 21
Downstream Channel ID Assignment
First Published: April 17, 2015
The DOCSIS downstream channel ID (DCID) is defined as an 8-bit identifier for recognizing a Downstream
Channel within a MAC Domain. All CMTS downstream channels are assigned a DCID by default that may
be subsequently changed by configuration. It is used in most DOCSIS downstream packet headers and its
valid range is from 1 to 255 (0 is reserved for network management purposes).
Note All downstream channels in a MAC domain must have a unique DCID within the MAC domain.
Contents
• Information About Downstream Channel ID Assignment on the Cisco CMTS Routers, on page 353
• How to Configure Downstream Channel ID Assignment on the Cisco CMTS Routers, on page 355
• Feature Information for Downstream Channel ID Assignment, on page 359
351
Digital PICs:

Module:

Modules:
line card reload.
352
Information About Downstream Channel ID Assignment on the Cisco CMTS Routers
Information About Downstream Channel ID Assignment on the

Cisco CMTS Routers
These are the downstream channel ID assignment features:
• Unique DCIDs are provided for all channels within a single controller by default.
Note DCID values for downstream channels in the same MAC Domain must be unique.
If a MAC Domain only contains channels from a single controller, the default
DCID values will be sufficient. If a MAC Domain contains channels from multiple
controllers, DCID conflicts may be encountered within the MAC Domain. DCID
conflicts may be resolved by changing the DCID value of the conflicting channels
within the controller configuration or by enabling the automatic channel ID
assignment feature.
• The default DCID value for each downstream channel within a controller is equivalent to rf-chan number
plus one. For example, the default value for rf-chan 0 is 1, for rf-chan 1 is 2.
Manual Downstream Channel ID Assignment

When using the manual DCID provisioning feature, every downstream channel in the system is assigned a
default DCID value equivalent to (controller QAM id + 1). The table below shows the default DCID ranges
per downstream controller.
Table 55: Default Downstream Channel IDs Per Slot/Subslot/Controller
0/0 1/0 2/0 3/0 6/0 7/0 8/0 9/0
DS 1-128 1-128 1-128 1-128 1-128 1-128 1-128 1-128

Controller
0
DS 1-128 1-128 1-128 1-128 1-128 1-128 1-128 1-128

Controller
1
DS 1-128 1-128 1-128 1-128 1-128 1-128 1-128 1-128

Controller
2
DS 1-128 1-128 1-128 1-128 1-128 1-128 1-128 1-128

Controller
3
DS 1-128 1-128 1-128 1-128 1-128 1-128 1-128 1-128

Controller
4
353
Automatic Downstream Channel ID Assignment on the Cisco CMTS Routers
0/0 1/0 2/0 3/0 6/0 7/0 8/0 9/0
DS 1-128 1-128 1-128 1-128 1-128 1-128 1-128 1-128

Controller
5
DS 1-128 1-128 1-128 1-128 1-128 1-128 1-128 1-128

Controller
6
DS 1-128 1-128 1-128 1-128 1-128 1-128 1-128 1-128

Controller
7
The default DCID value can be replaced with a user configurable value. The configuration is available in the
downstream controller per channel. The current DCID values for the channels within a downstream controller
can be viewed in the dcid column of the show controller Integrated-Cable rf-chan command output. The
example shows channels with default DCID values. When a DCID value is changed in the configuration, the
new value appears in the output below.
Router#show controllers integrated-Cable 3/0/0 rf-channel 1-127

1 NPRE UP 99000000 DOCSIS B 256 5361 I32-J4 2 37 NORMAL
Router#
Automatic Downstream Channel ID Assignment on the Cisco CMTS Routers

It is possible to automatically assign a unique set of downstream channel IDs to meet all DOCSIS requirements
by enabling the Automatic DCID Assignment feature. When enabled, Downstream channel DCIDs will be
automatically assigned when the channels are added to a fiber node and associated with a MAC Domain.
Therefore, the use of fiber node configuration is a prerequisite for this feature.
Service Impact
Changing the DOCSIS downstream channel ID causes cable modems to re-register. Cable modems receive
MAC Domain Descriptor (MDD) and Upstream Channel Descriptor (UCD) messages with a changed DCID
in their headers.
• Enabling the automatic DCID assignment displays the following message:
354
How to Configure Downstream Channel ID Assignment on the Cisco CMTS Routers
WARNING: Enabling automatic DCID assignment will cause modems to flap and will apply
to all fiber nodes on this CMTS.
• Disabling the automatic DCID assignment displays the following message:
WARNING: Disabling automatic DCID assignment will no longer enforce channel-id uniqueness
at fiber nodes. Channel ID changes may require manual verification to prevent conflicts.
• If there is a DCID conflict with another channel in the MAC Domain, the following error message is
displayed:
ERROR: <slot>/<subslot>/<controller> rf-channel <channel>: The downstream channel id

conflicts with interface In<slot>/<subslot>/<controller>:channel. Downstream channel
id must be unique in a CGD.
• After automatic DCID assignment is configured, if there is a DCID conflict when a downstream channel
that belongs to a fiber node is added to a MAC Domain, the automatic DCID feature tries to resolve the
conflict by assigning another automatic DCID and the following message is displayed:
WARNING: The downstream channel id conflict for <slot>/<subslot>/<controller> rf-channel

<channel> was resolved by Automatic DCID Assignment.
Please run "interface <md-slot>/<md-subslot>/<md-index>" followed by
"<slot>/<subslot>/<controller> rf-channel <channel>" again in order to add the channel.
To add the channel, use this channel grouping domain (CGD) command again:
cable downstream x/y/z rf-channel channel
• If automatic DCID is configured and the channel does not belong to a fiber node, or if automatic DCID
cannot resolve the conflict, the following message is displayed:
WARNING: The downstream channel id conflict for <slot>/<subslot>/<controller> rf-channel

<channel> could not be resolved by Automatic DCID Assignment.
To resolve this issue, add the channel to a fiber node.
How to Configure Downstream Channel ID Assignment on the

Cisco CMTS Routers
The following sections describe how to configure downstream channel ID assignment.
Configuring Manual Downstream Channel ID Assignment

Procedure

355
Configuring Automatic Downstream Channel ID Assignment

Router> enable

Example:
Step 3 interface controller integrated-Cable slot/subslot/port Enters controller configuration mode for the Channel
Grouping Domain host line card.
Example:
Router(config)# interface controller
integrated-Cable 1/0/1
Step 4 rf-chan downstream QAM ID Enters the rf-channel configuration mode.

• Alternatively, use the rf-chan starting downstream
QAM ID ending downstream QAM ID command to
set the range of downstream channel IDs.
Example:
Router(config-controller)# rf-chan 0
Step 5 docsis-channel-id DCID Configures the downstream channel's DCID to the specified
value, for the RF channel.
Example:
Router(config-rf-chan)#docsis-channel-id 1 For the rf-channel range that was configured using the
rf-chan starting downstream QAM ID ending downstream
QAM ID command, the docsis-channel-id DCID command
configures the DCIDs for the rf-channels in that range.

Automatic DCID assignment should be permanently configured. However, if you need to remove the feature,
use the no or default commands.
Note The no or default form of the command is not written to startup-config file.
In this case, the DCIDs are retained as computed for all channels, and are not set to the defaults of the channels.
Save the configuration containing the newly-assigned DCIDs to the startup-config file by using the write
memory command.
When you enable automatic DCID assignment, any DCID conflict arising due to adding a channel to a MAC
Domain is resolved automatically.
356
Restriction • After running the cable downstream-channel-id automatic command in the configuration, manually
editing the configuration file in an editor to add RF channels to the fiber nodes could cause DCID conflicts.
The feature assumes all channels in fiber nodes have unique automatic DCIDs in global configuration
mode. If the configuration is manually edited and the feature does not verify the unique DCIDs, the
DCIDs of the newly-added channels may conflict with those of the existing channels. To fix any DCID
conflicts, undo and re-apply the global automatic DCID configuration.
Note Re-applying global automatic DCID configuration is a disruptive operation.
To avoid DCID conflicts, edit the configuration to configure the fiber nodes, then run the cable
downstream-channel-id automatic command so all channels have unique automatic DCIDs.
Make additions to the fiber nodes on the Cisco uBR10012 router command line interface with the
automatic DCID configured.
• The cable downstream-channel-id automatic command should not be manually edited in to the
startup-config file, since it does not guarantee unique DCIDs for channels in the fiber node.
Procedure

Router> enable

Example:
Step 3 cable downstream-channel-id automatic Specifies automatic assignment of the DCIDs by the Cisco
CMTS.
Example:
Router(config)# cable downstream-channel-id
automatic
Example
This example displays the restriction on manually editing configurations:
Router# show run | include automatic

cable downstream-channel-id automatic
router# show cable fiber-node 3

---------------------------------------------------------------------------------
Fiber-Node 3
Channel(s) : downstream Integrated-Cable 1/0/2: 0-3, 32-35, 64-67, 96-99
Channel ID(s): 1 2 3 4 33 34 35 36 65 66 67 68 97 98 99 100
357
MDD Status: Valid
Router#
If you manually edit the startup-config file in an editor to add a downstream controller, for example,
1/0/3, it causes a conflict.
Router> configure terminal

Router# cable fiber-node 3
Router# downstream integrated-Cable 1/0/3
If this downstream controller is added, the automatic DCID assignment feature automatically resolves
it. However, since the startup-config file was manually edited to add the downstream controller, the
automatic DCID assignment feature is unable to resolve it. This causes a DCID conflict when the
edited startup-config file is loaded and invalidates the fiber node.
down Modular-Cable 5/0/0 rf-channel 0

DS frequency is not unique.
DS channel id is not unique.
Warning: D3.0 CMs cannot get w-online with an invalid fiber-node.
router#
What to do next
Run the show cable fibernode command to view DCIDs assigned to all the channels in the fiber node.

Fiber-Node 3
Channel(s) : downstream Integrated-Cable 1/0/2: 0-3, 32-35, 64-67,
96-99
Channel ID(s): 1 2 3 4 33 34 35 36 65 66 67 68 97 98
99 100
MDD Status: Valid
358
Description Link
The Cisco Support website provides extensive online http://www.cisco.com/cisco/web/support/index.html

resources, including documentation and tools for
troubleshooting and resolving technical issues with
Cisco products and technologies.
To receive security and technical information about
your products, you can subscribe to various services,
such as the Product Alert Tool (accessed from Field
Notices), the Cisco Technical Services Newsletter, and
Really Simple Syndication (RSS) Feeds.
Access to most tools on the Cisco Support website
requires a Cisco.com user ID and password.
Feature Information for Downstream Channel ID Assignment

Table 56: Feature Information for Downstream Channel ID Assignment
Downstream Channel ID Cisco IOS XE Fuji This feature was integrated on the Cisco cBR
Assignment 16.7.1 Series Converged Broadband Router.
359
Feature Information for Downstream Channel ID Assignment
360
CHAPTER 22
Upstream Channel Bonding
The Upstream Channel Bonding (USCB) feature helps cable operators offer higher upstream (US) bandwidth
per cable modem (CM) user by combining multiple radio frequency (RF) channels to form a larger bonding
group at the MAC layer.
Contents
• Prerequisites for Upstream Channel Bonding , on page 363
• Restrictions for Upstream Channel Bonding , on page 363
• Information About Upstream Channel Bonding, on page 364
• How to Configure Upstream Channel Bonding , on page 372
• Configuration Example for Upstream Channel Bonding , on page 387
• Verifying the Upstream Channel Bonding Configuration, on page 389
• Feature Information for Upstream Channel Bonding, on page 391
361
Digital PICs:

Module:

Modules:
line card reload.
362
Prerequisites for Upstream Channel Bonding
Prerequisites for Upstream Channel Bonding

• Enable downstream channel bonding before configuring the Upstream Channel Bonding feature on a
Cisco cable modem termination system (CMTS) router.
• Ensure that the CM is registered in Multiple Receive Channel (MRC) mode before configuring upstream
channel bonding on a Cisco CMTS router.
• Ensure that the CM is DOCSIS 3.0 certified.
Restrictions for Upstream Channel Bonding

The following are the general restrictions for the Upstream Channel Bonding feature:
• Only the static bonding groups are supported.
• Only the upstream channels belonging to the same MAC domain can be added to an upstream bonding
group.
Note A maximum of 16 upstream channels can be configured for each MAC Domain,
which are divided into two groups:
The upstream bonding-group should include all the upstream channels either
from Group 1 or Group 2 only.
• Committed information rate (CIR) oversubscription is not supported on USCB groups.

Cisco CMTS allows oversubscription of the available bandwidth for individual upstream channels.
However, oversubscription of bandwidth is not supported for USCB groups.
An individual upstream may get oversubscribed due to static CIR service flows created for voice traffic.
This may cause the DOCSIS 3.0 CMs with USCB to come online on single channel US bonding group
(also known as default bonding group).
This problem is mainly encountered in the voice deployments using static service flows. It is, therefore,
recommended to choose from the following voice deployments such that the CIR is allocated (or released)
when a voice call is attempted (or dropped):
1. Dynamic Quality of Service (DQoS) Lite
2. Packet Cable (PC) DQoS
3. Packet Cable Multimedia (PCMM)
These deployments avoid the individual upstream oversubscription and CMs come online on expected
bonding groups.
363
Information About Upstream Channel Bonding
Information About Upstream Channel Bonding

DOCSIS 3.0-based upstream channel bonding is a method for increasing upstream bandwidth up to a maximum
of 120 Mbps raw throughput per CM user in a cable communications system that includes a Cisco CMTS
router and multiple CMs. The upstream channel bonding method enables a CM to transmit data to a Cisco
CMTS router on multiple upstream channels simultaneously.
Channel bonding is a method by which smaller bandwidth upstream channels are bonded together to create
a larger upstream bonding group in the MAC domain. A MAC domain is a logical sub-component of a Cisco
CMTS router and is responsible for implementing all DOCSIS functions on a set of downstream and upstream
channels.
The Upstream Channel Bonding feature supports upstream traffic in Multiple Transmit Channel (MTC) mode
for data and video services as these services require more bandwidth than voice-based services. Voice-based
services either use the traditional single upstream channel or a single upstream channel bonding group
configuration. Any traffic contract that exceeds 30 Mbps requires upstream channel bonding as the physical
capacity of a single RF channel in DOCSIS cannot exceed 30 Mbps.
The Upstream Channel Bonding feature is supported on the Cisco cBR-8 router. Upstream data from the
subscriber comes through the upstream ports (US0-US19) that are automatically configured on the cable
interface line card. The cable interface line card processes the data and sends it across the backplane to the
WAN card and out to the Internet.
The table below lists the downstream and upstream frequency supported on the cable interface line card.
Table 58: Downstream and Upstream Frequency
Line Card Downstream Frequency Upstream Frequency
Cisco cBR-8 CCAP 55-999 MHz1 The upstream frequency range for the Cisco cBR-8 CCAP
line card is from 5 to 85 MHz irrespective of the region and
Annexure configuration.
1
This frequency range is subjected to the frequency restriction of the attached EQAM device.
Multiple Transmit Channel Mode

Multiple Transmit Channel mode is a CM capability that enables CMs to send upstream traffic on multiple
upstream channels. You can enable the MTC mode on a cable interface line card:
• MTC mode for all CMs in a MAC domain—The MTC mode for all CMs in a MAC domain is enabled
by default on an upstream bonding capable cable interface line card.
Multiple Receive Channel Mode

MRC mode is a CM capability that enables CMs to receive downstream traffic on multiple downstream
channels. The MRC mode is enabled by default on an upstream bonding capable cable interface line card.
You can enable or disable the MRC mode in the MAC domain during or after the CM registration using the
cable mrc-mode command.
364
Dynamic Range Window and Transmit Power Levels for Upstream Channel Bonding
Dynamic Range Window and Transmit Power Levels for Upstream Channel
Bonding
The dynamic range window functionality is based on the CableLabs DOCSIS 3.0 MAC and Upper Layer
Protocols Interface Specification and DOCSIS 3.0 Specification. This requires a DOCSIS 3.0 CM to have
upstream transmit channel power level within a 12 dB range for all channels in its transmit channel set (TCS).
DOCSIS 1.x or 2.0 CMs operating with a single upstream channel, in non-MTC mode, have a higher maximum
transmit power level than DOCSIS 3.0 CMs operating in the MTC mode with two or more upstream channels.
That is, the maximum transmit power level per channel is reduced in the MTC mode.
When the upstream attenuation exceeds the maximum transmit power level, a DOCSIS 3.0 CM attempting
to register in the MTC mode may fail to come online, or register in partial mode. The CM fails to register
when the transmit power level of all upstream channels in its TCS exceeds the maximum transmit power level.
If the CM has some upstream channels that are within the maximum transmit power level, the CM may come
online in partial mode. However, the upstream channels that exceed the maximum transmit power level are
marked as down and cannot be used for upstream traffic.
To verify the transmit power levels on a CM, use the show cable modem command with the verbose keyword.
This command displays the following transmit power values for each assigned upstream channel:
• Reported Transmit Power—This is the reported transmit power level by the CM for each upstream
channel.
• Minimum Transmit Power—This is the minimum transmit power level that the CM in the MTC mode
could transmit at for the upstream channel.
• Peak Transmit Power—This is the maximum transmit power level that the CM in the MTC mode could
transmit at for the upstream channel.
To support upstream channel bonding, the minimum transmit power must be less than or equal to the reported
transmit power, and the reported transmit power must be less than or equal to the peak transmit power. The
peak transmit power and minimum transmit power levels are derived from the CM TCS assignment and each
individual upstream channel configuration.
If the minimum transmit power is higher than the reported transmit power, or the reported transmit power is
higher than the peak transmit power, the CM may not come online or may register in partial mode.
You can troubleshoot this transmit power problem in the following two ways:
• Insert an additional amplifier to reduce the upstream attenuation so that the upstream transmit power
falls within the allowed transmit power range (12 dB).
• Disable the MTC mode. To switch the CM from the MTC mode to non-MTC mode, disable the bonded-bit
(bit-0) in type, length, value (TLV) 43.9.3 using the CM configuration file.
Extended Transmit Power

During the early deployment of DOCSIS 3.0 CMs, additional power is required from the CMs in order to
compensate for the attenuation in the upstream path. CMs should transmit at extended power level than that
defined in DOCSIS. This scenario is generally observed when USCB is enabled at the Cisco CMTS and the
DOCSIS 3.0 CMs are operating in MTC mode.
Additional upstream power provides the operator with a power margin that helps overcome the upstream
signal loss, reduces the cable plant operational cost, and enables rapid deployment of DOCSIS 3.0 CMs.
The Cisco CMTS supports the following features with which the CMs can transmit data at an extended power:
• Cisco Extended Transmit Power Feature
365
Reduced Transmit Channel Set
• DOCSIS Extended Transmit Power Feature
Cisco Extended Transmit Power Feature

The Cisco Extended Transmit Power feature supports DOCSIS 3.0 CMs operating in MTC mode to transmit
at a higher power level than the power level specified in the DOCSIS 3.0 Specification. This feature is supported
only with Cisco DPC3000 CMs.
The Cisco Extended Transmit Power feature enables cable operators to have better control on the cable modems
that register in 4-channel or 2-channel MTC mode or in non-MTC mode to transmit at a higher power level
than the DOCSIS-defined maximum power level. The cable operator can configure extended transmit power
using the cable tx-power-headroom command in global configuration mode.
DOCSIS Extended Transmit Power Feature

The DOCSIS Extended Transmit Power feature supports extended upstream transmit power capability as
defined in the DOCSIS3.0 Specification. This feature allows the CMs to transmit at a high extended power
level to counter the attenuation in the US channel.
The table below lists the new TLVs supported by the DOCSIS Extended Transmit Power feature.
Table 59: TLVs for DOCSIS Extended Power Feature
TLV Name Type Length Value
Extended Upstream Transmit Power 16 1 0—Extended Upstream Transmit Power Support

Support Off
1—Extended Upstream Transmit Power Support
On
2-255—Reserved
Extended Upstream Transmit Power CM 5.40 1 0, 205-244 (units of one-quarter dB)

Capability
The Cisco CMTS sends TLV16 to inform the CM if the DOCSIS Extended Transmit Power feature is enabled.
The CM in turn, sends TLV5.40 to the Cisco CMTS to communicate its extended power capability. After the
negotiations are complete, the CM can transmit at an extended power.
DOCSIS Extended Transmit Power feature is enabled by default. Use the cable upstream ext-power command
to enable or disable this feature. For more information on how to enable or disable DOCSIS Extended Power
feature, see Configuring DOCSIS Extended Transmit Power Feature, on page 387.
Note DOCSIS Extended Transmit Power feature takes precedence, if both Cisco Extended Transmit Power feature
and DOCSIS Extended Transmit Power feature are configured.
Reduced Transmit Channel Set

The Reduced Transmit Channel Set feature enables the Cisco CMTS router to reduce upstream channel set
assignment based on the total power budget of the CM. For example, a reduction from four to two upstream
channels gains 3 dB headroom. Further reduction from two channels to a single channel gains another 3 dB
headroom, and the CM starts operating in non-MTC mode.
366
T4 Multiplier
In order to take advantage of the reduced upstream channel set, the corresponding static bonding groups must
be configured. For example, a MAC domain is configured with a bonding group having four channels. A CM
with the reduced channel set of two is unable to match to the 4-channel bonding group, and can only be
matched to a bonding group with two channels or less.
The Reduced Transmit Channel Set feature is helpful when a DOCSIS 3.0 CM is required to increase its total
transmit power by 3 dB. For example, a DOCSIS 1.0 or 2.0 CM supports a maximum transmit power of 58
dBmV for Quadrature Phase Shift Keying (QPSK) modulation, while a DOCSIS 3.0 CM supports a maximum
transmit power of 61 dBmV. In this case, the DOCSIS 3.0 CM operating in 4-channel MTC mode has a
reduction in the maximum transmit power per upstream channel. This feature enables the Cisco CMTS router
to support reduced input power level by 6 dB to prevent upstream path attenuation.
T4 Multiplier
T4 multiplier is the T4 timeout multiplier value of the default T4 timeout values as defined in for cable modems
that are in the MTC mode. The default value is derived from the number of channels in the modem transmit
channel set. You can change the default T4 multiplier value using the cable upstream ranging-poll command
in cable interface configuration mode.
The T4 timeout multiplier values range is from 1 to 10. If the T4 multiplier value is equal to 1, the cable
modem will T4 time out in 30 seconds (that is, 1 x 30 = 30). If you change the T4 multiplier to 4, then the
new T4 timeout value will be 120 seconds (that is, 4 x 30 = 120).
Note If the T4 timeout multiplier is not configured from the range (1 - 10), then the CMTS uses the T4 timeout
value of modem as T4 timeout value. For example, if the T4 timeout of the modem is 90 seconds, then the
CMTS applies 3 as the T4 multiplier.
In the MTC mode, you can increase the T4 timeout value in order to reduce the router overhead associated
with processing of ranging request (RNG-REQ) slots and ranging response messages. If an RNG-RSP message
does not contain a T4 timeout multiplier value, then the CM uses the default T4 timeout value.
Fiber Node Configuration for Upstream Channel Bonding

The fiber node configuration on a Cisco CMTS router is used to define MAC domain downstream service
groups (MD-DS-SGs) and MAC domain upstream service groups (MD-US-SGs) as defined in DOCSIS 3.0.
Only the DOCSIS 3.0 certified modems use this information.
In hybrid fiber coaxial (HFC) networks, all CMs connected to the same coaxial segment of a fiber node reach
the same set of downstream and upstream channels on one or more Cisco CMTS routers located at the headend.
A CM is physically connected to only one fiber node. The fiber node must include at least one primary-capable
controller for the CM connected to the fiber node to be operational.
New TLVs for Upstream Channel Bonding

The table below lists the new CableLabs defined type, length, values (TLVs) for the Upstream Channel
Bonding feature.
367
Upstream Weighted Fair Queuing
Table 60: New TLVs for Upstream Channel Bonding
TLV Name Type Length Value
CM vendor ID 43.8 3 Per vendor definition
Cable modem attribute mask 43.9 n Cable modem attribute mask subtype encodings
A Cisco CMTS can have multiple upstream channel bonding groups (USBG) configured. Each of these
bonding groups can include upstream channels with different upstream frequencies. Some bonding groups
can include channels with frequencies within the extended frequency range (see Table 58: Downstream and
Upstream Frequency, on page 364). An HFC network consists of several types of CMs, each supporting
standard or extended upstream frequencies.
When you register a CM, the Cisco CMTS does not assign bonding groups based on the upstream frequency
range supported by that CM. The assignment of the bonding groups is done to balance the CM count on each
of the bonding groups. This may lead to assignment of a bonding group, in the extended frequency range, to
a CM that lacks the extended frequency support. As a result, the CM will not be able to register. This scenario
is generally observed in the Cisco cBR-8 CCAP line card deployment (containing a mix of CMs), which
supports frequency as high as 85MHz (see Table 58: Downstream and Upstream Frequency, on page 364).
If the Cisco CMTS assigns a USBG with a channel within the extended frequency range to a CM limited to
the standard frequency range, that CM may not be able to register on that upstream bonding group. Use the
TLV 43.9.3 (CM US Required Attribute Mask) or TLV 43.9.4 (CM US Forbidden Attribute Mask) as a
workaround. These TLVs enable the Cisco CMTS to assign CM to a USBG, which is in the upstream frequency
range supported by that CM.
The default attributes (in hexadecimal) on a CM Attribute Mask (TLV 43.9) are “80 00 00 00", which means
by default the mask is all zeroes with the bonding bit enabled. The first four bytes are pre-defined while the
last four bytes are user defined. In order to enable Cisco CMTS to assign bonding groups based on the frequency
range supported by CMs, complete these steps:
1. Configure a mask, using TLV 43.9.3 or TLV 43.9.4, by modifying the last four bytes. The mask should
be configured such that a unique attribute is assigned to each of the bonding groups.
2. Apply this mask to the CM configuration file. CMs supporting extended frequency, can register with any
USBGs, irrespective of the configured frequency range of the USBG. CMs supporting standard frequency,
can only register with USBGs that are configured with standard frequency range.
Apply the mask you have configured above, to the CMs that support standard or extended frequency ranges.
However, the ONLY CMs that need to employ the attribute mask are the ones with the standard frequency
range, since they will not be able to register with the USBG configured with extended upstream frequency
range. No attribute mask on the extended frequency supporting CMs means that these modems will be assigned
any USBG.
The Cisco CMTS uses this mask, received in the CM configuration file during registration, to decide which
USBG should be assigned to the CM.
Upstream Weighted Fair Queuing

The upstream weighted fair queuing (WFQ) is a quality of service (QoS) feature that enables the Cisco CMTS
router to allocate optimum bandwidth to upstream service flows based on the WFQ parameter configurations.
To enable upstream WFQ, you must configure either the class-based or activity-based WFQ on a cable
interface.
The following WFQ parameter configurations are supported:
368
Class-Based Weighted Fair Queuing
Class-Based Weighted Fair Queuing

In the class-based weighted fair queuing configuration, allocation of available bandwidth is dependent on the
service flows that are active in a service class. A service class is a group of queuing attributes configured on
the Cisco CMTS router. The class must have at least one active service flow. The class receives its portion
of the available bandwidth based on the weight of the class. By default, each class (0 to 7) has a weight of
“class + 1.” For example, the class 0 has a weight of 1, and class 1 has a weight of 2.
Activity-Based Weighted Fair Queuing

In the activity-based weighted fair queuing configuration, allocation of available bandwidth is based on the
service class and the total number of service flows that are active in a map for the service class. A service
class with higher number of service flows receives the larger percentage of bandwidth.
Custom Weight for Service Flow Priorities

The weighted fair queuing functionality helps the Cisco CMTS router share the available bandwidth based
on the weight of the service flow priorities specified for outstanding requests from an upstream service flow.
Priority refers to the service flow priority specified in the CM configuration file, or the Cisco CMTS service
class configuration. By default, the weight of a priority is equal to “priority+1.” For example, priority 0 has
a weight of 1, and priority 1 has a weight of 2. A higher priority provides more weight to the outstanding
request. The custom weight can be specified for a total of eight priorities (0 to 7) in a service class.
The priority parameter refers to the priority of traffic in a service flow ranging from 0 (the lowest) to 7 (the
highest). In the upstream traffic, all of the pending high priority service flows are scheduled for transmission
before low priority service flows. You can configure the weight for priorities based on how much weight is
appropriate per priority.
The table below lists the default weight for each service flow priority.
Table 61: Default Weight of Service Flow Priorities
Service Flow Priority Default Weight
0 1
1 2
2 3
3 4
4 5
5 6
6 7
7 8
Upstream Scheduler and Service Flows

A DOCSIS-qualified Cisco CMTS router can provide varied upstream scheduling modes for different packet
streams or applications using upstream service flows. A service flow represents either an upstream or a
369
Upstream Service Flow Fairness
downstream flow of data. A unique service flow ID (SFID) identifies each service flow. Each service flow
can have its own quality of service (QoS) parameters, such as maximum throughput, minimum guaranteed
throughput, and priority. In the case of upstream service flows, you can also specify a scheduling mode.
Scheduling is a process that enables the Cisco CMTS router to receive bandwidth requests and grant timeslots
to CMs for the upstream traffic. The Cisco CMTS router periodically creates a grant map for each enabled
upstream channel. The map grants individual timeslots to enable CMs to place packets on the upstream
channels.
DOCSIS 3.0 describes a method by which a CM creates an upstream service flow. The following scheduling
types enable the Cisco CMTS router to allocate bandwidth for upstream service flows:
• Unsolicited grant service (UGS)
• Solicited grant service
The unsolicited grant service is primarily used for voice. In the case of UGS, the CM does not have to explicitly
request grants from the Cisco CMTS router whereas in the solicited grant service the CM has to explicitly
request grants from the Cisco CMTS router. The solicited grant service is primarily used for best effort (BE)
services.
Unlike DOCSIS 2.0, DOCSIS 3.0 allows multiple outstanding requests per service flow. For more information
about the upstream scheduler, see the Upstream Scheduler Mode for the Cisco CMTS Routers feature guide
at the following URL:
http://www.cisco.com/en/US/docs/ios/cable/configuration/guide/cmts_upstm_sch_md_ps2209_TSD_Products_Configuration_Guide_Chapter.html
Upstream Service Flow Fairness

The service flows in the same class receive approximately the same amount of bandwidth. Fairness resolves
the bandwidth distribution disparity among various service flows including:
• non-bonded service flow vs bonded service flows
• Service flows on modems of different vendors, i.e Intel/TI vs Broadcom
• Service flows associated with different sized bonding groups, i.e. 1,2 4 channels
The upstream scheduler supports flow based queuing. When Upstream Service Flow Fairness is configured,
the upstream scheduler determines the order and amount of BW a service flow should receive based on it's
current consumption relative to other flows in the flows in the same class.
Use the cable upstream qos fairness command to configure the Upstream Service Flow Fairness feature.
Use this command in interface configuration mode (or MAC Domain configuration mode).
Distribution of Traffic across all Channels in a USBG

When upstream channel bonding (USCB) is enabled, the Distribution of Traffic across all Channels in a USBG
feature can be used to balance the bandwidth utilization across upstream channels on one upstream bonding
group.
This feature balances the utilization only if there is one upstream channel bonding group configured per MAC
domain.
Restrictions:
• This feature is supported only on one upstream bonding group under a MAC domain. When multiple
upstream bonding groups are configured under a MAC domain, the utilization is unfair.
370
DOCSIS 3.0 Load Balancing with USBG Smaller than Cable Modem Capabilities
• All the channels must be configured in one upstream bonding group under the same MAC domain.
• This feature is used only for UB-online cable modems.
The USCB Balancing Scheduler may be enabled or disabled using the cable upstream balance-scheduler
command in the interface (config-if) configuration mode.
DOCSIS 3.0 Load Balancing with USBG Smaller than Cable Modem Capabilities
When using USCB in a service group with USBGs containing fewer upstream channels than the total upstream
channel set with DOCSIS 3.0 load balancing enabled, the CMTS can assign a Transmit Channel Set (TCS)
to DOCSIS 3.0 cable modems for potential use which falls outside of the configured USBG. The CMTS will
try to bind smaller UBGs and default single channel bonding groups into a bigger channel set in order to
increase the cable modem services. For example, a DOCSIS 3.0 cable modem receiving the larger TCS can
use these additional channels for dynamic service flow addition. The DOCSIS 3.0 Load Balancing feature
can also move cable modems to upstream channels that are not explicitly configured with USBGs as a result
of the larger TCS.
If you activate DOCSIS 3.0 Load Balancing while using upstream bonding, ensure that the upstream bonding
group configuration is embedded and aligned by performing the following:
• Configure USBGs, which is matched to cable modem capabilities within the service group, such as a 4
channel USBG, 2 channel USBG, and 3 channel USBG as applicable.
• Ensure that configured USBGs are optimal for the upstream channel set based on modem capabilities
within the service group. For example, if four upstream channels are available, channels 0+1 and 2+3
should each be an USBG to avoid dynamic TCS creating sub optimal bonding scenarios.
• Alternatively, you can choose to shut down any upstream channels that is not configured in USBGs
which is not be used for bonding.
Cisco cBR-8 CCAP Line Card Rate Limiting

The rate limiting functionality enables you control the aggregated rate and CPU consumption of upstream
traffic for DOCSIS 3.0 bonded service flows on the Cisco cBR-8 CCAP line card. The rate limiting functionality
is configured by default on the Cisco cBR-8 CCAP line card. However, the default configuration can be
modified using the cable upstream rate-limit-ccf command.
The rate limiting functionality uses the following two rate limiting methods:
• Aggregated rate limiting—This is based on Peripheral Component Interconnect (PCI) bus aggregated
throughput. The throughput is per line card for all bonded service flows. You can modify the default
throughput and burst rate configuration. The maximum allowed throughput is 115 Mbps.
• CPU-based rate limiting—This method controls the CPU consumed by Continuous Concatenation and
Fragmentation (CCF) and ensures that the line card functions properly when traffic is overloaded with
bonded service flows. The default configuration allocates 50 per cent of CPU to CCF. You can modify
the default CPU threshold value and burst rate as required.
SID Tracking
The service ID (SID) tracking functionality enables you to track events related to upstream bandwidth requests
and processing of grants. The SID tracker module can track events for a maximum of two service flows per
371
Service ID Clusters
MAC domain. The SID tracker module tracks up to 40,000 events per service flow on a cable interface line
card.
You can enable SID tracking for the following types of events:
• DOCSIS 2.0 bandwidth request
• DOCSIS 3.0 bandwidth request
• Grant
• Pending grant (due to traffic congestion)
• Pending grant (due to shaping)
You can enable SID tracking using the track keyword along with the debug cable interface sid command.
To verify SID tracking, use the show interface cable upstream debug command in privileged EXEC mode.
Service ID Clusters
A Cisco CMTS router can assign one or more service ID clusters to the upstream bonded service flows
(upstream service flows assigned to an upstream bonding group) at the time of service flow creation. A SID
cluster contains one SID per upstream in a bonding group. A CM uses one of the SIDs defined in the SID
cluster for the upstream interface when the CM sends a bandwidth request. The CM chooses a SID or a SID
cluster based on the SID cluster switching criteria.
For example, assume that a CM has ranged on upstream channels from 1 to 4. The Cisco CMTS router creates
a bonded service flow and assigns a single SID cluster to each upstream channel. That is SID1 for UP1, SID2
for UP2, SID3 for UP3, and SID4 for UP4. Now, the CM can send a bandwidth request using any of the four
upstream channels. That is, the CM can request bandwidth on any of the upstream interfaces in the SID cluster
using the SID defined for the particular upstream. The Cisco CMTS router grants bandwidth to the CM using
any combination of upstream channels.
How to Configure Upstream Channel Bonding
Note Before configuring the Upstream Channel Bonding feature, ensure that the fiber node is configured. The fiber
node must be configured in accordance with the physical plant topology.
The following tasks describe how to configure Upstream Channel Bonding on the Cisco cBR-8 router:
Enabling MTC Mode on a Cisco CMTS Router

To section explains how to enable the MTC mode on a Cisco CMTS router.
Default MTC Mode Configuration on a Cisco CMTS Router

By default, the MTC mode is configured on a cable interface line card. With this default configuration, the
Cisco CMTS router enables the MTC mode on a per MAC domain basis depending on the configuration file
of each CM. When the CM configuration file has the bonded-bit (bit-0) enabled in TLV 43.9.3 (cable modem
upstream required attribute mask), the Cisco CMTS router enables the CM to come online in the MTC mode.
If the CM configuration file does not have the bonded-bit on, the CM comes online in non-MTC mode.
372
Enabling MTC Mode for All CMs
For more information on how to add the required attribute in the CM configuration file, see Example: Enabling
MTC Mode for a Single CM Using the CM Configuration File, on page 389.
Enabling MTC Mode for All CMs
Note • For DOCSIS 3.1 cable modems, the CMTS router must be configured to use MTC mode.
• This MTC mode configuration supersedes the default MTC mode configuration (per CM basis) with the
required attribute. To disable the MTC mode for all CMs in a MAC domain, use the no form of the
cable mtc-mode command. If the MTC mode is enabled and the forbidden mask of the upstream bonding
in TLV 43.9.4 is disabled, the CM does not support the Upstream Channel Bonding feature.
Procedure

Router> enable

Example:
Step 3 interface cable {slot/subslot/port | Specifies the cable interface line card on a Cisco CMTS
slot/subslot/cable-interface-index | slot/port | router.
slot/cable-interface-index}
Example:
Step 4 cable mtc-mode Enables MTC mode at the MAC interface for all CMs.
Example:
Router(config-if)# cable mtc-mode
Step 5 end Exits cable interface configuration mode and returns to

Example:
Configuring UCSB Required Attribute

If the CM configuration file has TLV 43.9.3 (CM upstream required attribute mask) configured and bonded
bit is set to 1, then the modem comes UB-online on a MAC domain basis. If the CM configuration file has
no TLV 43.9.3 or the bonded bit is not set to 1, then the modem comes online with a single upstream channel
on a MAC domain basis.
373
Creating a Bonding Group
Note Without this configuration, the modem comes UB-online on the MAC domain regardless of whether the TLV
43.9.3 is configured in the modem configuration file.
Procedure

prompted
Example:
Router> enable

Example:
Step 3 interface cable { slot/subslot/port | Specifies the cable interface line card on a Cisco CMTS
Example:
Step 4 cable mtc-mode required-attribute Enable enforcement of required CM attribute on UCSB.

Example:
Router(config-if)# cable mtc-mode
required-attribute

Example:
Creating a Bonding Group

An upstream bonding group is created by combining multiple upstream channels together on a cable interface
line card.
Procedure

Router> enable

Example:
374
Adding Upstream Channels to a Bonding Group

Example:
Step 4 cable upstream bonding-group id Creates the bonding group on the specified cable interface.
Example:
200

Example:
What to do next
After creating an upstream bonding group, you must add upstream channels to the bonding group.
Adding Upstream Channels to a Bonding Group
Restriction DOCSIS 3.0-certified CMs support only four upstream channels on an upstream bonding group. These CMs
do not accept additional upstream channels that are added to a bonding group.
Procedure

Router> enable

Example:
Example:
375
Adding Upstream Channel Ports to a Fiber Node

Step 4 cable upstream bonding-group id Creates the bonding group on the specified interface.
Example:
200
Step 5 upstream number Enters upstream bonding configuration submode and adds
an upstream channel to the upstream bonding group.
Example:
Router(config-upstream-bonding)# upstream 1 Note Upstream channel needs to be bonded to
mac-domain first before adding it to the
bounding group. For detailed configuration steps
of the upstream channel bonding, please refer to
Configuration Example for Upstream Channel
Bonding
A maximum of 16 upstream channels can be configured for

each MAC Domain, which are divided into two groups:
Step 6 end Exits upstream bonding configuration submode and returns

Example:
Adding Upstream Channel Ports to a Fiber Node

You must add upstream channel controllers to a fiber node in order to complete the basic upstream channel
bonding configuration on a cable interface line card. The fiber node must contain all upstream and downstream
controllers reached by the CMs.
Restriction • Configuration of a fiber node is valid only if all upstream channels inside the fiber node have different
upstream frequencies.
• For any two upstream channels mapped to the upstream cable controllers in the same fiber node where
a spectrum group is assigned to one upstream channel, and a frequency is assigned to the other upstream
channel, any overlap between any bands associated with the spectrum group of the upstream channel
and the frequency of the upstream channel will result in an invalid fiber node configuration. That is a
fixed frequency cannot overlap with another upstream channel’s available spectrum group bands.
Note The fiber node configuration must be done in accordance with the physical plant topology.
376
Configuring the Class-Based Weighted Fair Queuing
Procedure

Router> enable

Example:
Step 3 cable fiber-node fiber-node-id Enters fiber node configuration mode.

Example:
Router(config)# cable fiber-node 2
Step 4 upstream Upstream-Cable slot/subslot/port Specifies the upstream channel ports for a fiber node.
Example:
Router(config-fiber-node)# upstream Upstream-Cable
7/0/1
Step 5 end Exits fiber node configuration mode and returns to

Example:
Router(config-fiber-node)# end
Configuring the Class-Based Weighted Fair Queuing

In the case of a class-based configuration, allocation of available bandwidth is dependent on the service flows
that are active in a service class.
Procedure

Router> enable

Example:
Example:
377
Configuring the Activity-Based Weighted Fair Queuing

Step 4 cable upstream qos wfq class Enables class-based weighted fair queuing.
Example:
Router(config-if)# cable upstream qos wfq class

Example:
Configuring the Activity-Based Weighted Fair Queuing

In the activity-based configuration, allocation of available bandwidth is based on the service class and the
total number of service flows that are active in a map for the service class.
Procedure

Router> enable

Example:
Example:
Step 4 cable upstream qos wfq activity Enables activity-based weighted fair queuing.
Example:
Router(config-if)# cable upstream qos wfq activity

Example:
Configuring Custom Weights for Service Flow Priorities

The WFQ functionality helps the Cisco CMTS router share the available bandwidth based on the weight of
the service flow priorities specified for outstanding requests from an upstream service flow.
378
Configuring the SID Cluster
Procedure

Router> enable

Example:
Example:
Step 4 cable upstream qos wfq weights priority0-priority7 Enables custom weight configuration for all the service
flow priorities in a service class.
Example:
Router(config-if)# cable upstream qos wfq weights Note You must specify custom weight values for all
10 20 30 40 50 60 70 80. the eight service flow priorities (0 to 7) when
you modify the default weights of priorities. The

Example:

This section explains how to configure and assign SID cluster to an upstream bonded service flow.
To achieve desired upstream bonded speed, you can use the cable sid-cluster-group num-of-cluster to
achieve desired upstream bonded speeds, and this takes precedence over cable sid-cluster-group dynamic.
Alternatively you can use a large upstream Max Traffic burst value in the cable modem file (such as 30 kB).
The Max Concat burst value in the cable modem file does not need change because DOCSIS 3.0 uses continuous
concatenations and fragmentation (CCF), and can therefore use the default value of 3044 in the Max Concat
field.
Note If the cable sid-cluster-group command is not used, the router accepts the default SID cluster configuration.
By default, dynamic sid-cluster assignment is configured. Similarly, if the cable sid-cluster-switching
command is not used, the router accepts the default SID cluster switchover criterion. That is, only one request
can be made using the SID cluster.
379
Procedure

Router> enable

Example:
Example:
Step 4 cable sid-cluster-group [dynamic[max_rate_threshold] Creates a SID cluster group. Starting from Cisco IOS XE
| req-multiplier value | num-of-cluster number] Gibraltar 16.12.1z release, you can configure a maximum
rate threshold for the service flow, because the original
Example:
threshold is not appropriate in some cases. If the maximum
Router(config-if)# cable sid-cluster-group dynamic rate of the service flow is larger than the configured
Router(config-if)# cable sid-cluster-group dynamic

threshold, two SIDs will be allocated to the service flow
3000000000 instead of one SID.
Router(config-if)# cable sid-cluster-group

req-multiplier 12
Router(config-if)# cable sid-cluster-group

num-of-cluster 2
Step 5 cable sid-cluster-switching [max-outstanding-byte value Specifies SID cluster switchover criteria.
| max-request value | max-time seconds | max-total-byte
value]
Example:
Router(config-if)# cable sid-cluster-switching
max-outstanding-byte 4444

max-request 222

max-time 444

max-total-byte 67890

Example:
380
Configuring the Channel Timeout for a Cable Modem
What to do next
Use the show running-config all command to verify the SID cluster configuration. Following is a sample
output of the command:
Router# show running-config all
.
.
cable sid-cluster-group req-multiplier 4
Configuring the Channel Timeout for a Cable Modem

The channel timeout configuration allows you to specify the maximum time that a CM can spend performing
initial ranging on the upstream channels described in the Registration Response (REG-RSP) and REG-RSP-MP
messages. The default channel timeout value (60 seconds) is automatically configured.
Procedure

Router> enable

Example:
Example:
Step 4 cable init-channel-timeout value Specifies the maximum time that a CM can spend
performing initial ranging on the upstream channels.
Example:
Router(config-if)# cable init-channel-timeout 160

Example:
Configuring Cable Upstream Resiliency

The cable upstream resiliency module ensures that a CM remains operational if one or more non-primary
upstream service flows of the CM enter temporary or persistent error states. This module enables a Cisco CMTS
router to handle various events and maintain the transmit channel set of each CM.
In the event of the primary upstream service flow failure, the upstream resiliency module forces the CM to
go offline.
381
Configuring Cable Upstream Resiliency
For a Multiple Transmit Channel (MTC) modem, the (NRTPS), Real-time Polling Service (RTPS), (UGS),
and (UGS-AD) upstream service flows on an impaired upstream channel is moved to another good upstream
channel in the cable modem without resetting the cable modem.
Procedure

Router> enable

Example:
Step 3 cable upstream resiliency data-burst polling-interval Configures the polling interval for data-burst resiliency in
number seconds. The range is from 5 to 3600. The default
configuration for polling-interval is 60.
Example:
Router(config)# cable upstream resiliency
data-burst polling-interval 60
Example:
Step 5 cable upstream resiliency {channel-down-detect number Configures upstream resiliency for bonded upstream service
| data-burst snr number ufec number cfec number flows.
hysteresis number | modem-offline-detect number |
on-failure {disable-channel | extended-ranging |
reset-modem} | sf-move {NRTPS | RTPS | UGS
| UGS-AD} }
Example:
Router(config-if)# cable upstream resiliency
channel-down-detect 68

modem-offline-detect 16

on-failure disable-channel

sf-move NRTPS

sf-move RTPS

sf-move UGS
382
Configuring Rate Limiting on the Cisco cBR-8 CCAP Line Card

sf-move UGS-AD

data-burst snr 24 ufec 1 cfec 0 hysteresis 3

Example:
Configuring Rate Limiting on the Cisco cBR-8 CCAP Line Card

The rate limiting functionality is configured by default on the Cisco cBR-8 CCAP line card. However, the
default configuration can be modified using the cable upstream rate-limit-ccf command.
Procedure

Router> enable

Example:
Step 3 cable upstream rate-limit-ccf [aggregated-burst value | Configures rate limiting parameters for upstream bonded
aggregated-throughput value | cpu-burst value | service flows on a cable interface line card.
cpu-threshold value]
Example:
Router(config)# cable upstream rate-limit-ccf
aggregated-burst 25000

aggregated-throughput 540000

cpu-burst 30

cpu-threshold 60
Step 4 end Exits global configuration mode and returns to privileged

EXEC mode.
Example:
Router(config)# end
383
Enabling Upstream Related Events for CM Status Reports
Enabling Upstream Related Events for CM Status Reports

You can enable upstream related CM status events only on a cable interface line card. You can enable the
following upstream related CM status events per interface using the cable cm-status enable command:
• T4 time-out
• T3 re-tries exceeded
• Successful ranging after T3 re-tries exceeded
For details on how to enable upstream and downstream related CM status events, see the Wideband Modem
Resiliency feature guide at the following URL:
http://www.cisco.com/en/US/docs/ios/cable/configuration/guide/ubr_wm_resiliency.html
Modifying the Bonding Group Attributes

Bonding group attributes are automatically configured for each upstream bonding group. You can modify
them using the attributes command in upstream bonding configuration mode.
Procedure

Router> enable

Example:
Example:
Step 4 cable upstream bonding-group id Creates the bonding group on the specified cable interface
and enters the upstream bonding configuration mode.
Example:
200
Step 5 attributes value Modifies the attribute value for the specified bonding group.
Example:
Router(config-upstream-bonding)# attributes
eeeeeeee
Step 6 end Exits upstream bonding configuration mode and returns to

Example:
384
Modifying the Ranging Poll Interval on Upstream Channels

Modifying the Ranging Poll Interval on Upstream Channels

You can change the default ranging poll interval (20 seconds) on upstream channels using the cable upstream
ranging-poll command in cable interface configuration mode. You can also specify the T4 timeout multiplier
value using this command.
For information on T4 Multiplier, see T4 Multiplier, on page 367 .
Note We recommend that you do not modify the default ranging poll interval unless required. With the default
configuration, a DOCSIS 2.0 CM in non-MTC mode performs ranging on one upstream channel every 20
seconds.
Procedure

Router> enable

Example:
Example:
Step 4 cable upstream ranging-poll [interval value | Specifies the ranging poll interval for upstream channels.
t4-multiplier timeout_value]
Note If t4-multiplier timeout_value is not configured,
Example: then the CMTS uses the the T4 timeout of the
modem. For example, if the T4 timeout of the
Router(config-if)# cable upstream ranging-poll modem is 90 seconds, then the CMTS will apply
interval 24000 t4-multiplier 4 3 as T4 multiplier for the modem.

Example:
385
Configuring the Reduced Channel Set Assignment
Configuring the Reduced Channel Set Assignment

You need to configure the transmit power offset budget to enable the Cisco CMTS router to reduce upstream
channel set assignment based on the total power budget of the CM.
Note The threshold value specified for the power budget offset (max-channel-power-offset) must be less than the
power threshold value (power-adjust continue) that determines the value of the Ranging Status field in the
Ranging Response (RNG-RSP) messages that the Cisco CMTS router sends to the CM. You can specify the
power threshold value using the cable upstream power-adjust command.
Before you begin

• Configure extended transmit power using the cable tx-power-headroom command in global configuration
mode.
• Ensure that corresponding static bonding groups are configured.
Procedure

Router> enable

Example:
Example:
Step 4 cable upstream max-channel-power-offset dB-value Specifies the power offset value for upstream channels.
Example:
Router(config-if)# cable upstream
max-channel-power-offset 2

Example:
386
Configuring DOCSIS Extended Transmit Power Feature
Configuring DOCSIS Extended Transmit Power Feature

The DOCSIS Extended Transmit Power feature is enabled by default on the Cisco CMTS. However, the
default configuration can be modified using the cable upstream ext-power command.
Procedure

Router> enable

Example:
Example:
Step 4 cable upstream ext-power Enables the DOCSIS Extended Transmit Power feature on
the Cisco CMTS.
Example:
Using the no form of this command disables the DOCSIS
Router(config-if)# cable upstream ext-power Extended Transmit Power feature.
Step 5 end Exits interface configuration mode and returns to privileged

EXEC mode.
Example:
The following debug commands help you troubleshoot an improper upstream channel bonding configuration
and its related features:
• debug cable cm-status—Provide debugging information about CM status messages on the Cisco CMTS
routers.
• debug cable mdd—Provides debugging information about MAC domain descriptor (MDD).
• debug cable md-sg—Provides information about service group debugging messages.
• debug cable ubg—Provides debugging information about upstream bonding groups.
Configuration Example for Upstream Channel Bonding

The following example shows how to configure the basic upstream channel bonding on the Cisco cBR-8
CCAP line card interface 7/0/0 on the Cisco cBR-8 router:
387
Configuration Example for Upstream Channel Bonding

us-channel 0 ingress-noise-cancellation 50
us-channel 0 equalization-coefficient
us-channel 1 ingress-noise-cancellation 50
!
load-interval 30
downstream Integrated-Cable 7/0/0 rf-channel 0
no cable upstream 0 equalization-error-recovery
cable upstream 7 attribute-mask 1FF
upstream 0
upstream 1
upstream 2
attributes 80000000
cable bundle 1
388
Example: Enabling MTC Mode for a Single CM Using the CM Configuration File
cable map-advance static 2000

cable sync-interval 121
cable reduction-mode mta-battery enable
end
cable fiber-node 1
description Feed Mac Domain: Cable7/0/0
downstream Integrated-Cable 7/0/0
Note Bonded channels are typically from the same connector; however, channels from different connectors in the
same MAC domain can also be bonded together. A single MAC domain can support multiple channel bonding
groups.
Note Up to 8 frequencies can be stacked to one upstream-cable controller. Once the upstream-cable controller has
8 frequencies stacked, no more frequency left for the adjacent upstream-cable controller.
Example: Enabling MTC Mode for a Single CM Using the CM Configuration

File
The following example shows how to enable the MTC required attribute using the CM configuration file:
03 (Net Access Control) = 1

Unknown Type 005 = 01 01 01
18 (Maximum Number of CPE) = 4
24 (Upstream Service Flow Encodings)
S01 (Service Flow Reference) = 1
S06 (QoS Parameter Set Type) = 7
S10 (Min Reserved Traffic Rate)= 500000
25 (Downstream Service Flow Encodings)
S10 (Min Reserved Traffic Rate) = 1000000
29 (Privacy Enable) = 0
43 (Vendor Specific Options)
S08 (Vendor ID) = ff ff ff
S009 (Unknown sub-type) = 03 04 80 00 00 00
Verifying the Upstream Channel Bonding Configuration

Use the following show commands to verify the upstream channel bonding configuration:
• show cable mac-domain upstream-service-group
• show cable fiber-node
• show interface cable upstream
• show interface cable service-flow
• show cable modem
389
Verifying Weighted Fair Queuing for Upstream Service Flows
To verify the runtime statistics of the upstream service group on a cable interface line card, use the show
cable mac-domain upstream-service-group command.
To verify the configuration of a fiber node, use the show cable fiber-node command.
To verify the bonding groups configured on a cable interface line card, use the show interface cable upstream
command.
To verify upstream bonding information on a cable interface line card, use the show interface cable
service-flow command.
To verify the transmit power levels on a CM, use the show cable modem command.
Verifying Weighted Fair Queuing for Upstream Service Flows

To verify WFQ parameters configured for upstream service flows on a cable interface line card, use the show
interface cable mac-scheduler command.
Verifying Rate Limiting for Upstream Bonded Service Flows

To verify the rate limiting criteria configured on the Cisco cBR8 CCAP line card for upstream bonded service
flows, use the show cable rate-limit-ccf command.
Note The show cable rate-limit-ccf command is applicable only to the Cisco cBR8 CCAP cable interface line
card.
Verifying Extended Power Transmission

To verify that a CM is transmitting at a higher power level, use the show cable modem command.
To list all the CMs that are transmitting at higher power level, use the show cable modem extended-power
command.
The following sections provide references related to the Upstream Channel Bonding feature.
390
Feature Information for Upstream Channel Bonding
Description Link
The Cisco Support website provides extensive online resources, including http://www.cisco.com/techsupport
To receive security and technical information about your products, you
can subscribe to various services, such as the Product Alert Tool (accessed
from Field Notices), the Cisco Technical Services Newsletter, and Really
Simple Syndication (RSS) Feeds.
Access to most tools on the Cisco Support website requires a Cisco.com
user ID and password.

Table 62: Feature Information for Upstream Channel Bonding
Upstream Channel Bonding Cisco IOS XE Fuji 16.7.1 This feature was integrated on the Cisco cBR
User-Configurable Dynamic SID Cisco IOS XE Gibraltar This feature was introduced on the Cisco cBR
Cluster Threshold 16.12.1z Series Converged Broadband Router.
391
392
CHAPTER 23
Dynamic Bonding Group
This document describes how to configure Dynamic Bonding Group that helps manage resource of all
downstream bonding groups by automatically creating bonding groups.
• Information About Dynamic Bonding Group, on page 395
• Overview of Dynamic Bonding Group, on page 395
• How to configure Dynamic Bonding Group, on page 395
• Feature Information for Dynamic Bonding Group, on page 406
393
Digital PICs:

Module:

Modules:
line card reload.
394
Information About Dynamic Bonding Group
Information About Dynamic Bonding Group

Dynamic Bonding Group (DBG) helps manage the resource of all downstream bonding groups, including
automatically creating and reclaiming the downstream bonding groups.
Overview of Dynamic Bonding Group

To reduce the effort required in configuring and managing RCC, the DBG feature implements the automatic
creating and reclaiming of the downstream bonding groups. DBG creates the bonding group automatically
depending on the channel’s load usage. With DBG, the modem is assigned the downstream bonding group
without any static RCC configuration. The load balancing feature leverages DBG to balance traffic among
all channels. DBG also accommodates primary channel and CM capacity distributions automatically.
DBG also accommodates primary channel and CM capacity distributions automatically.
Dynamic Bonding Group supports the following:
• Support 896 bonding groups per CLC for CBR-CCAP-LC-40G and CBR-CCAP-LC-40G-R cards.
• Support creating DBGs and reclaiming DBG.
• Support DOCSIS 3.0 and DOCSIS 3.1 channel types.
• Support DOCSIS 3.0 and DOCSIS 3.1 load balance.
• Supports DBG interoperation — Modem registration and load balancing.
• Enhance dynamic load balance — Fixed primary channel movement.
• Enhance raider FPGA SQF — Fairness in channel utilization.
How to configure Dynamic Bonding Group

Enable Dynamic Bonding Group
Feature History
Ability to create 8-channel DBG Cisco IOS XE Bengaluru 17.6.1x Some CMs change to downstream
with contiguous frequency channels partial mode when moving on the
DBG with disconnected frequency
channels. This feature allows you
to create 8-channel DBG with
contiguous frequency channels for
load balance purpose.
395
Enable DS-Resiliency and Configure Resiliency Bonding Group
To enable DBG, run the following commands:
ROUTER# config t
ROUTER(config)# cable dynamic-bonding-group
ROUTER(config)# end
ROUTER#
ROUTER#
ROUTER# show run
ROUTER# show running-config | in dynamic-bonding
cable dynamic-bonding-group
Sometimes an 8-channel DBG is created with discontinuous frequency channels (such as 0-5 and 8-9) for
load balance purpose. In this case, dual tuner 8-channel CM with BRCM3380 chipset may change to
downstream partial mode when moving on the DBG with discontinuous frequency channels. To avoid this
issue, you can force the cBR-8 router to create 8-channel DBG with contiguous frequency channels using the
following command:
ROUTER# config terminal
ROUTER(config)# cable dynamic-bonding-group eight-contiguous-channel
Enable DS-Resiliency and Configure Resiliency Bonding Group

To make sure that the modem remains w-online with maximum downstream capability when several rf channels
are impaired, enable ds-resiliency feature by running the following commands:
Router# config t
Router(config)# cable resiliency ds-bonding
Router(config)# end
Router#
Router# show running-config | in resiliency
cable resiliency ds-bonding
Router#
Router# config t
Router(config)# interface wideband-Cable 3/0/1:30
Wideband-Cable3/0/1:30 is set to WB resiliency bonding group.
Remove any existing bundle and rf-channel configuration.
Router(config-if)#end
Router#
Router#show running-config interface wideband-Cable 3/0/1:30
!
cable ds-resiliency
end
Enable ACFE
Enable ACFE feature to make sure that modem registration is not blocked because of QoS failures:
Router# config t
Router(config)# cable acfe enable
Router(config)# end
396
Configure Interface Mac-Domain and Fiber-Node
Router# show running-config | in acfe

cable acfe enable
Configure Interface Mac-Domain and Fiber-Node
Note The recommended size of service group is 32 or 48. The recommended primary channel distribution is one
primary channel for contiguous four channels, such as 0, 4, 8, 12, 16, 20, 24, 28 and so on.
To set up interface mac-domain and fiber-node, run the following commands:
Router# show running-config interface c3/0/1

!
upstream 0
upstream 1
attributes 80000002
upstream 2
upstream 3
attributes 80000000
cable bundle 255
end
Router# show cab

Router# show cable fib
Fiber-Node 1
Channel(s) : downstream Integrated-Cable 3/0/1: 0-31
Channel ID(s): 1 2 3 4 5 6 7 8 9 10 11 12 13 14
15 16 17 18 19 20 21 22 23 24 25 26 27 28
29 30 31 32
MDD Status: Valid
Router# show running-config | sec fiber-node 1
cable fiber-node 1
397
Enable Load Balancing for DOCSIS 3.0 and DOCSIS 3.1
Example of OFDM configured in the fiber node and added as part of the dynamic bonding group.
Router# show cable dynamic-bonding-group summary

Dynamic bonding group: Enable
BG ID BG Name BG Size CMs ServFlows Create Time Create Client BG
State RFid list
9219 Wi1/0/4:2 33 36 36 Nov 7 01:56:27.406 MODEM_ONLINE
OPERATIONAL 9216-9247, 9375
OPERATIONAL 9248-9279, 9375
OPERATIONAL 9248-9255
Router# show controller integrated-Cable 1/0/0 rf-channel 158

Time source is NTP, *14:07:30.643 EST Fri Nov 17 2017
Chan State Admin Mod-Type Start Width PLC Profile-ID dcid power
output
Frequency
158 UP UP OFDM 258000000 48000000 279000000 100 159 34.0 NORMAL

Time source is NTP, *13:59:39.571 EST Fri Nov 17 2017
---------------------------------------------------------------------------------
Fiber-Node 10
Channel(s) : downstream Integrated-Cable 1/0/0: 0-63, 158
Channel ID(s): 1 2 3 4 5 6 7 8 9 10 11 12 13 14
15 16 17 18 19 20 21 22 23 24 25 26 27 28
29 30 31 32 33 34 35 36 37 38 39 40 41 42
43 44 45 46 47 48 49 50 51 52 53 54 55 56
57 58 59 60 61 62 63 64 159
MDD Status: Valid
Enable Load Balancing for DOCSIS 3.0 and DOCSIS 3.1

To enable DOCSIS load balancing, run the cable load-balance docsis-enable command. When DOCSIS load
balancing is enabled, run the cable load-balance docsis30-enable command to enable load balancing for
DOCSIS 3.0 and DOCSIS 3.1.
Note The cable load-balance docsis30-enable command enables load balancing for DOCSIS 3.0 and DOCSIS
3.1.
Enable DOCSIS 3.0 and DOCSIS 3.1 Static Load Balance

To balance the load of primary channels, enable static load balance by running the following commands:
ROUTER# config t
ROUTER(config)# cable load-balance docsis30-enable static
ROUTER(config)# end
398
Enable DOCSIS 3.0 and DOCSIS 3.1 General Load Balance Group
ROUTER# show cable load-balance

DOCSIS 3.0 Static LB Enabled: Yes
DOCSIS 3.0 Dynamic Downstream LB Enabled: No
Enable DOCSIS 3.0 and DOCSIS 3.1 General Load Balance Group
To enable general load balance group, run the following commands:
Router# config t
Router(config)# cable load-balance docsis-group fn 1 md c3/0/1
Router(config-lb-group)# no disable
Router(config-lb-group)# end
Router# show cable load-balance
159
DOCSIS 3.0 Dynamic Upstream LB Enabled: Yes

/UCC D/U
M/E/U/P/S
Ca3/0/1 1 2147557888 E 90 0xF8(0)/N 0 u/u 0x91010B 5/10/70/70/50
Enable Dynamic Load Balance and Fixed-Primary Channel Movement
Note To reduce service outage while enabling dynamic load balancing, enable fixed primary channel movement.
To balance the load of all of downstream channels based on utilization, enable dynamic load balance by
running the following commands:
Router# config t
Router(config)# cable load-balance docsis30-enable dynamic downstream
Router(config)# end
Router#
Router# show cable load-balance
DOCSIS 3.0 Dynamic Upstream LB Enabled: Yes
1 GE 30 0xF8(0)/N 0 m/m 5/10/70/70/50
399
Verifying Dynamic Bonding Group Configuration

/UCC D/U M/E/U/P/S
Ca3/0/1 1 2147557888 E 90 0xF8(0)/N 0 u/u 0x91050A 5/10/70/70/50
Router#
Router# config t
Router(config)# cable load-balance fixed-primary-channel
Router(config)# end
Router#
Router# show run
Router# show running-config | in fixed
cable load-balance fixed-primary-channel

To verify that the DBGs are created:
Check the modem’s primary wideband interface by using the show cable modem wideband channel command:
Router# show cable modem 4800.33ee.ebee wideband channel

MAC Address IP Address I/F MAC DSxUS Primary
State WB
4800.33ee.ebee 30.132.15.246 C3/0/1/UB w-online 32x2 Wi3/0/1:3
Router# scm 4800.33ee.ebee ver
Check the modem’s downstream tuner capability by using the show cable modem verbose | in DS Tuner
command.
Router# show cable modem 4800.33ee.ebee verbose | in DS Tuner

DS Tuner Capability : 32
Check the related RCC by using the show cable mac-domain rcc command:
Router# show cable mac-domain c3/0/1 rcc
RCC-ID RCP RCs MD-DS-SG CMs WB/RCC-TMPL D3.0 D3.1
32 00 00 00 00 00 8 0 11 WB (Wi3/0/1:1) Y Y
33 00 00 00 00 00 32 0 6 WB (Wi3/0/1:3) Y Y
34 00 00 00 00 00 8 0 7 WB (Wi3/0/1:2) Y Y
35 00 00 00 00 00 8 0 7 WB (Wi3/0/1:4) Y Y
36 00 00 00 00 00 8 0 7 WB (Wi3/0/1:5) Y Y
Check the dynamically created bonding groups, use the show cable dynamic-bonding-group summary
command as shown in the example below:
Router# show cable dynamic-bonding-group summary

BG ID BG Name BG Size CMs ServFlows Create Time Create Client BG State
RFid list
24834 Wi3/0/1:1 8 11 11 Sep 14 14:36:35.194 MODEM_ONLINE OPERATIONAL
24832-24839
24832-24863
24840-24847
24837 Wi3/0/1:4 8 7 7 Sep 14 17:21:37.723 STATIC_LOAD_BALANCE OPERATIONAL
24856-24863
24838 Wi3/0/1:5 8 7 7 Sep 14 17:21:39.761 STATIC_LOAD_BALANCE OPERATIONAL
24848-24855
The following examples shows the DBG created with contiguous frequency channels for load balance purpose.
400
Router#show cable dynamic-bonding-group summary

DBG operation with Registration: Enable
DBG operation with Load-Balance: Enable
BG ID BG Name BG Size CMs ServFlows Create Time Create Client BG
State RFid list
24578 Wi3/0/0:1 24 4 4 Sep 26 15:07:22.760 MODEM_ONLINE
24577 Wi3/0/0:0 8 17 17 Sep 26 16:35:01.240 MODEM_ONLINE
24579 Wi3/0/0:2 8 7 7 Sep 26 16:53:48.857 DYNAMIC_LOAD_BALANCE
24580 Wi3/0/0:3 8 6 6 Sep 26 16:56:49.790 DYNAMIC_LOAD_BALANCE
Router#show derived-config interface wideband-Cable 3/0/0:3

Derived configuration : 141 bytes

!
cable bundle 255
no snmp trap link-status
end
Router#show derived-config interface wideband-Cable 3/0/0:2

Derived configuration : 139 bytes

!
cable bundle 255
no snmp trap link-status
end
Table 65: Dynamic Bonding Group States
CREATE_WAITING_SUP Line card sends request to create DBG and waits for
SUP to create the bonding group.
HOLD DBG is created from SUP, or bonding group reverts

from reclaim to ready for use.
OPERATIONAL If modem is used on the bonding group after the

HOLD state times out, the DBG state changes to
OPERATIONAL.
RECLAIM_HOLD Ready for reclaim.

If no modem is used on the bonding group or match
the reclaim in two minutes, the bonding group is
reclaimed. The DBG state changes to
RECLAIM_HOLD.
RECLAIM_MODEM_MOVING Ready for reclaim.

The modem is moved out of the bonding group.
401
Verifying Static Load Balancing Configuration
RECLAIM_WAITING_SUP Line card sends DBG reclaim request and waits for
SUP to reclaim the BG.
To show the detailed channel list information of dynamic bonding group, use the show derived-config
interface wideband command.
Router# show derived-config interface wideband-Cable 3/0/1:1

Derived configuration: 113 bytes
!
cable bundle 255
end
Check the usage of bonding group resource by using the show cable dynamic-bonding-group quota summary
| slot | controller command.
Router# show cable dynamic-bonding-group quota controller 3/0/1
slot/subslot/ctrlr: 3/0/1
Total BG number: 128
Used BG number (static/dynamic): 6(1/5) Available BG number: 122
Available BG list port: 0, 6-29, 31-127
Note 128 BGs can be configured on one controller, but only 896 BGs are supported per CLC. All controllers share
the 896 BG resources.
Check the reclaimed bonding group by using the show cable dynamic-bonding-group reclaim-history
summary command:
Router# show cable dynamic-bonding-group reclaim-history summary

BG ID BG Name BG Size Create Time Create Client Reclaim Time Reclaim Client RFid
list
24835 Wi3/0/1:2 16 Sep 14 14:40:27 MODEM_ONLINE Sep 14 14:44:27 DBG_INTERNAL
24832-2484

To verify if static load balancing is configured:
Check the load of all primary channels by using the show cable load-balance docsis-group fn 1 md cable
load | in In command.
Router# show cable load-balance docsis-group fn 1 md c3/0/1 load | in In

Interface State Group Utilization Rsvd NBCM WB/UB Weight
In3/0/1:0(573 MHz) initial 2147557888 0%(0%/0%) 0% 0 17 37
In3/0/1:4(597 MHz) initial 2147557888 0%(0%/0%) 0% 0 17 37
In3/0/1:8(621 MHz) initial 2147557888 0%(0%/0%) 0% 0 13 37
In3/0/1:12(645 MHz) initial 2147557888 0%(0%/0%) 0% 0 13 37
In3/0/1:16(669 MHz) initial 2147557888 0%(0%/0%) 0% 0 13 37
In3/0/1:20(693 MHz) initial 2147557888 0%(0%/0%) 0% 0 13 37
In3/0/1:24(717 MHz) initial 2147557888 0%(0%/0%) 0% 0 13 37
In3/0/1:28(741 MHz) initial 2147557888 0%(0%/0%) 0% 0 13 37
402
This command output lists all primary channels and shows the number of cable modems used with these
channels. NBCM is the number of narrow band modems used with a channel while WBCM (WB/UB) is the
number of wideband modems used with a channel. The total number of WBCMs should be balanced among
all the channels.
The difference between the total number of WBCMs used with any two channels is smaller or equal to the
threshold load minimum. The default value of the threshold load minimum is 5.
Check the load of all rf channels by using the show cable load-balance docsis-group fn 1 md rfch-util
command.
Router# show cable load-balance docsis-group fn 1 md c3/0/1 rfch-util

Interface Pstate Pending-In Pending-Out Throughput(Kbps) Util NBCM WBCM
In3/0/1:0 up No No 0 0% 0 17
In3/0/1:1 NA No No 0 0% 0 17
In3/0/1:2 NA No No 0 0% 0 17
In3/0/1:3 NA No No 0 0% 0 17
In3/0/1:4 up No No 0 0% 0 17
In3/0/1:5 NA No No 0 0% 0 17
In3/0/1:6 NA No No 0 0% 0 17
In3/0/1:7 NA No No 0 0% 0 17
In3/0/1:8 up No No 0 0% 0 13
In3/0/1:9 NA No No 0 0% 0 13
In3/0/1:10 NA No No 0 0% 0 13
In3/0/1:11 NA No No 0 0% 0 13
In3/0/1:12 up No No 0 0% 0 13
In3/0/1:13 NA No No 0 0% 0 13
In3/0/1:14 NA No No 0 0% 0 13
In3/0/1:15 NA No No 0 0% 0 13
…….
Average: 0.0
Variance: 0.0
This command lists the load information about the primary and secondary channels. WBCM is the number
of wideband modems used with a channel.
Check the cable modem’s internal state in load balancing using the show cable load-balance docsis-group
fn 1 md modem-list wideband command.
Router# show cable load-balance docsis-group fn 1 md c3/0/1 modem-list wideband

L - L2vpn, R - RSVP, S - DS-Resiliency
Primary WB MAC Address Primary DS RCC-ID Priority MUPFXLRS State
Wi3/0/1:0 (3)
c8fb.2631.0e56 In3/0/1:20 41 0 ------ LB_CM_HOLD_EXPIRE_IN
36
c8fb.26a6.c3dc In3/0/1:16 41 0 ------ LB_CM_HOLD_EXPIRE_IN
37
c8fb.2631.0d7e In3/0/1:16 41 0 ------ LB_CM_HOLD_EXPIRE_IN
43
Wi3/0/1:1 (9)
c8fb.2631.0c80 In3/0/1:0 32 0 ------ LB_CM_STATIC_MOVING
c8fb.2631.0cae In3/0/1:0 32 0 ------ LB_CM_STATIC_READY
c8fb.2631.0db0 In3/0/1:24 42 0 ------ LB_CM_STATIC_MOVING
c8fb.2631.0c10 In3/0/1:28 42 0 ------ LB_CM_STATIC_MOVING
c8fb.2631.0d80 In3/0/1:16 41 0 ------ LB_CM_STATIC_MOVING
403
Verifying Dynamic Load Balancing Configuration
c8fb.2631.0d26 In3/0/1:24 41 0 ------ LB_CM_STATIC_MOVING
a4a2.4a2d.b4aa In3/0/1:20 41 0 ------ LB_CM_STATIC_MOVING
c8fb.2631.0e5c In3/0/1:0 32 0 ------ LB_CM_STATIC_MOVING
c8fb.2631.0cb0 In3/0/1:0 32 0 ------ LB_CM_STATIC_MOVING

Wi3/0/1:2 (3)
c8fb.2631.0d2a In3/0/1:12 34 0 ------ LB_CM_HOLD_EXPIRE_IN
27
c8fb.2631.0e5a In3/0/1:12 34 0 ------ LB_CM_STATIC_MOVING
c8fb.2631.0bfe In3/0/1:8 34 0 ------ LB_CM_STATIC_MOVING

Wi3/0/1:3 (2)
4800.33ea.54be In3/0/1:28 33 0 ------ LB_CM_DYNAMIC_READY
4800.33ee.ebe6 In3/0/1:20 33 0 ------ LB_CM_HOLD_EXPIRE_IN

1
Wi3/0/1:4 (2)
c8fb.2631.0e44 In3/0/1:24 42 0 ------ LB_CM_HOLD_EXPIRE_IN
40
c8fb.2631.0a44 In3/0/1:28 42 0 ------ LB_CM_HOLD_EXPIRE_IN
42
Table 66: Cable Modem States
CM state Description
LB_CM_STATIC_READY Modem is ready for static load balance movement.
LB_CM_STATIC_MOVING Modem is in movement triggered via static LB.
LB_CM_HOLD_EXPIRE_IN Modem is in hold for the next movement. The default

hold time is 600 seconds.
LB_CM_DYANMIC_READY Modem is ready for dynamic load balance movement.
LB_CM_DYANMIC_MOVING Modem is in movement triggered via dynamic LB.
LB_CM_DISABLED Modem is not ready for movement. If the modem

failure movement count reaches max-failure threshold,
then set the modem in LB_CM_DISABLED to avoid
further movement.

Check the utilization of all rf channels by using show cable load-balance docsis-group fn 320 md rfch-util
command.

Do3/0/0:0 up No No 11754 31% 0 308
Do3/0/0:1 up No No 11754 31% 0 296
Do3/0/0:2 up No No 11754 31% 0 333
Do3/0/0:3 up No No 11754 31% 0 296
Do3/0/0:4 up No No 11754 31% 0 297
Do3/0/0:5 up No No 11754 31% 0 331
Do3/0/0:6 up No No 11754 31% 0 299
404
Do3/0/0:7 up No No 11753 31% 0 268

Do3/0/0:8 up No No 11754 31% 0 302
Do3/0/0:9 up No No 11754 31% 0 331
Do3/0/0:10 up No No 11753 31% 0 308
Do3/0/0:11 up No No 11754 31% 0 305
Do3/0/0:12 NA No No 12862 34% 0 258
Do3/0/0:13 NA No No 12862 34% 0 258
Do3/0/0:14 NA No No 12862 34% 0 258
…….
Average: 30.416
Variance: 1.701
The traffic among all rf channels is considered balanced when the difference between any two rf channel
utilization is under the threshold load. The default value of threshold load is 10%.
To check the potential target bonding group for each of the source bonding group, use the show cable
load-balance docsis-group fn md cable target dbg and the show cable load-balance docsis-group fn md
target wide command.
Router# show cable load-balance docsis-group fn 320 md c3/0/0 target dbg

Interface Bg-Id Size Group Target
Wi3/0/0:0 24577 4 2147557695
Wi3/0/0:3 24580 4 2147557695
Wi3/0/0:4 24581 8 2147557695
Wi3/0/0:5 24582 8 2147557695
Wi3/0/0:6 24583 24 2147557695 33% [24576, 24584-24587, 24589-24607]
Wi3/0/0:7 24584 16 2147557695 30% [24576, 24586-24587, 24595-24607]
Wi3/0/0:8 24585 16 2147557695
Wi3/0/0:9 24586 32 2147557695
Wi3/0/0:10 24587 24 2147557695 33% [24576, 24584-24587, 24589-24607]
Wi3/0/0:11 24588 8 2147557695
Wi3/0/0:12 24589 8 2147557695 27% [24596-24603]
Wi3/0/0:13 24590 8 2147557695
Wi3/0/0:14 24591 4 2147557695
Router# show cable load-balance docsis-group fn 5 md c1/0/4 target wide

Interface Bg-Id State Group Target
Wi1/0/4:2 9219 up 2147510276 Wi1/0/4:4
Wi1/0/4:3 9220 up 2147510276
Wi1/0/4:4 9221 up 2147510276
If no target bonding groups are displayed, no bonding groups are created to balance traffic among rf channels.
A sample output with DOCSIS 3.1 modems with configured threshold of 14% is shown below. For utilization
based load balancing to start on DOCSIS 3.1 modems, the OFDM channel must be 100% utilized and traffic
must flow on SC-QAM. The utilization based load balancing balances the traffic flowing on the SC-QAM
channels in a D31 modem.

In1/0/4:0 up No No 10632 28% 0 45
In1/0/4:1 NA No No 11226 29% 0 41
In1/0/4:2 NA No No 11225 29% 0 41
In1/0/4:3 NA No No 11225 29% 0 41
In1/0/4:4 down No No 11225 29% 0 41
In1/0/4:5 down No No 11225 29% 0 41
In1/0/4:6 down No No 11225 29% 0 41
In1/0/4:7 down No No 11225 29% 0 41
In1/0/4:8 up No No 10620 28% 0 43
....
....
405
Feature Information for Dynamic Bonding Group
In1/0/4:35 NA No No 6646 17% 0 6

In1/0/4:36 NA No No 6646 17% 0 6
In1/0/4:37 NA No No 6647 17% 0 6
In1/0/4:38 NA No No 6646 17% 0 6
In1/0/4:39 NA No No 6647 17% 0 6
In1/0/4:40 up No No 6088 16% 0 6
In1/0/4:41 NA No No 6648 17% 0 6
In1/0/4:42 NA No No 6647 17% 0 6
In1/0/4:43 NA No No 6647 17% 0 6
In1/0/4:44 NA No No 6646 17% 0 6
In1/0/4:45 NA No No 6646 17% 0 6
In1/0/4:46 NA No No 6647 17% 0 6
In1/0/4:47 NA No No 6648 17% 0 6
In1/0/4:48 NA No No 6648 17% 0 6
In1/0/4:49 NA No No 6648 17% 0 6
In1/0/4:50 NA No No 6646 17% 0 6
In1/0/4:51 NA No No 6648 17% 0 6
In1/0/4:52 NA No No 6647 17% 0 6
In1/0/4:53 NA No No 6648 17% 0 6
In1/0/4:54 NA No No 6647 17% 0 6
In1/0/4:55 NA No No 6648 17% 0 6
In1/0/4:56 NA No No 6647 17% 0 6
In1/0/4:57 NA No No 6647 17% 0 6
In1/0/4:58 NA No No 6646 17% 0 6
In1/0/4:59 NA No No 6645 17% 0 6
In1/0/4:60 NA No No 6646 17% 0 6
In1/0/4:61 NA No No 6646 17% 0 6
In1/0/4:62 NA No No 6647 17% 0 6
In1/0/4:63 NA No No 6647 17% 0 6
In1/0/4:159 NA No No 1819685 100% 0 47
Feature Information for Dynamic Bonding Group

Table 67: Feature Information for Dynamic Bonding Group
Dynamic Bonding Cisco IOS XE Fuji This feature was introduced on the Cisco cBR Series
Group 16.7.1 Converged Broadband Routers.
406
CHAPTER 24
Spectrum Management and Advanced Spectrum
Management
This chapter describes the spectrum management features supported for the Cisco Cable Modem Termination
System (CMTS) routers. Spectrum management support is divided into two main groups:
• Guided and scheduled spectrum management features (supported in software)
• Intelligent and advanced spectrum management features (supported in hardware only on specific cable
interfaces)

• Prerequisites for Spectrum Management, on page 409
• Restrictions for Spectrum Management, on page 409
• Information About Spectrum Management, on page 411
• How to Configure Spectrum Management, on page 427
• Monitoring Spectrum Management, on page 444
• Feature Information for Spectrum Management and Advanced Spectrum Management, on page 458

407
Digital PICs:

Module:

Modules:
408
Prerequisites for Spectrum Management
line card reload.
Prerequisites for Spectrum Management

Ensure that your network is designed to support reliable broadband data transmission. At minimum, your
network must include:
• A Dynamic Host Configuration Protocol (DHCP) server to assign IP addresses to cable modems or
set-top boxes on the hybrid fiber-coaxial (HFC) network. This can be a Cisco CMTS router that has been
configured to act as the DHCP server.
• If you are not using cable interface line cards with integrated upconverters, you must install the appropriate
IF-to-RF external upconverter between the Cisco CMTS router and the combiner.
Note The term “combiner” refers to all cables, amplifiers, and taps at the headend or
cable distribution center that connect the Cisco CMTS router to the HFC network.
• Diplex filters installed in the downstream RF path between the cable modems and the cable interface
cards in the router. RG-59 headend coaxial cable with the maximum braid available (60 percent + 40
percent braid), double foil, and the correct connector for this cable.
• Avoid frequencies with known ingress problems such as amateur radio bands or short-wave bands.
• Avoid hostile spectrums below 20 MHz.
• When designing your channel plan, allow extra bands for frequency hopping.
• Use the receive power level setting to perform slight equalization adjustments.
• Due to the nature of CATV technology, upstream noise management is a significant issue. We recommend
that you follow the rigorous North American plant maintenance procedures documented in the NCTA
Supplement on Upstream Transport Issues (available from the National Cable and Telecommunications
Association, https://www.ncta.com ) to adjust return amplifiers and lasers.
Restrictions for Spectrum Management

This section describes the restrictions for the following spectrum management features:
Shared Spectrum Groups

• Advance spectrum management does not support inter-line-card shared spectrum groups.
409
Dynamic Upstream Modulation
• Guided spectrum management does support inter-line-card shared spectrum groups.

• The Cisco CMTS router has one preconfigured (primary) modulation profile that defines a typical profile
for quadrature phase-shift keying (QPSK) modulation. To use the Dynamic Upstream Modulation feature,
you must create a secondary modulation profile that has a higher modulation scheme than the preconfigured
profile. The Three Step Dynamic Modulation feature allows you to create and use a third modulation
profile. However, the third modulation profile is optional.
• Upstream modulation profiles are assigned to upstream ports and affect all cable modems on those
upstream ports.
• Modulation profiles affect the physical layer of the cable network, so only trained technicians who are
familiar with the Data-over-Cable Service Interface Specifications (DOCSIS) specifications should create
modulation profiles.
• When using the Dynamic Upstream Modulation feature with Voice over IP (VoIP) services, frequent
changes to the upstream modulation or channel width could briefly impact the quality of voice calls.
Fixed-Frequency Spectrum Groups with Advanced Spectrum Management

Do the following to configure fixed-frequency spectrum groups:
Router(config)#controller upstream-cable 9/0/15

Router(config-controller)#us-channel 0 spectrum-group n
Router(config-controller)#us-channel 0 channel-width 1600000
Limitations on Upstream Modulation Parameters for PacketCable VoIP Calls

We recommend the use of a channel width that is 1.6Mhz, 3.2Mhz, or 6.4Mhz while configuring upstreams
for PacketCable operations and VoIP calls. (All DOCSIS channel widths and upstream parameter combinations
are supported, but not optimum when offering VoIP.)
N+1 Redundancy Support

N+1 redundancy requires the working and protect cable interface line cards to be identical. This ensures that
the protect interface supports the same exact configuration as the working interface.
When protecting cards that support intelligent and advanced spectrum management, a switchover preserves
the spectrum management configuration, and the protect interface initially uses the same upstream frequency
as the working interface. The protect interface does not begin using the advanced spectrum management
features until the system stabilizes to avoid any unnecessary frequency hops or channel width changes.
Intelligent and Advanced Spectrum Management Support

• Cable interfaces use standard DOCSIS, EuroDOCSIS, and the extended Japanese frequency ranges (5
to 85 MHz for upstream interfaces) to support the intelligent and advanced spectrum management features.
410
Information About Spectrum Management
• Intelligent and advanced spectrum management features are supported only in the DOCSIS 1.0 and
DOCSIS 1.1 Time Division Multiple Access (TDMA) mode of operation. These features cannot be used
when a cable interface is operating in the DOCSIS 2.0 mixed, Advanced TDMA (A-TDMA), and
Synchronous Code Division Multiple Access (S-CDMA) modes of operation. Similarly, these features
are also not available when the cable interface is configured to use multiple logical channels. However,
these restrictions do not apply for guided spectrum management.
• Upstream channels must meet the carrier-to-noise plus interference ratio (CNiR [CNR]), and
carrier-to-ingress power ratio values given in the DOCSIS specifications. The minimum value for both
parameters is 25 dB in the 5 to 65 MHz frequency range.
• The intelligent and advanced spectrum management features do not support inter-line card shared spectrum
groups. Spectrum management features require that upstream ports on different line cards have their own
RF domain (a unique set of non-overlapping frequencies).
• N+1 redundancy is not supported on any cable interface line card that has defined spectrum groups,
which typically is the normal configuration for advanced spectrum management.
• The intelligent and advanced spectrum management feature is activated by assigning spectrum groups
on cards with built-in spectrum analyzer.
Information About Spectrum Management

Spectrum management allows a Cisco Cable Modem Termination System (CMTS) to sense upstream plant
impairments, report them to a management entity, and automatically correct them where possible. The spectrum
management feature performs these functions without reducing throughput or latency and without creating
additional packet overhead on the radio frequency (RF) plant.
In particular, because the cable interfaces on the router receive upstream packets, it can directly detect upstream
transmission errors. The router can also indirectly monitor the condition of the plant by keeping a record of
modem state changes, such as the number and frequency of cable modems that are “flapping” (modems that
either miss a station maintenance message or that go offline and then come back online).
Note For more information about the cable modem flapping and how to monitor the cable modem flap list, see the
Flap List Troubleshooting for the Cisco CMTS Routers .
Spectrum management can prevent long-term service interruptions caused by upstream noise events in the
cable plant. It is also used for fault management and troubleshooting the cable network. When cable modems
are detected to go online and offline by flap detectors, the cable operators can look at the flap list and spectrum
tables to determine the possible causes.
Because of the nature of cable television (CATV) technology, upstream noise management is a significant
issue. Frequency bands must have a sufficient CNR (CNiR) and carrier-to-ingress power ratio to support the
transmission of QPSK and quadrature amplitude modulation (QAM) data. The DOCSIS sets the minimum
value for both of these ratios to 25 dB in the 5 to 65 MHz frequency range. If the CNR (CNiR) drops below
25 dB on a particular channel due to noise, the cable modem on that channel degrades and can drop off the
hybrid fiber-coaxial (HFC) network.
This overview contains the following subsections:
411
Spectrum Management Measurements
• Spectrum Management Measurements, on page 412—Provides an overview of fundamental concepts and

terms that are used in spectrum management.
• Upstream Signal Channel Overview, on page 416—Describes how signals are sent and how changes
occur in upstream channels.
• Upstream Segments and Combiner Groups, on page 417—Describes sparse and dense segments and
combiner groups.
• Frequency Management Policy, on page 418—Describes the types of noise impairments and how to
counteract ingress noise with spectrum groups and frequency hopping.
• Guided and Scheduled Spectrum Management, on page 420—Describes the following guided and scheduled
spectrum management features: frequency hopping capabilities, dynamic upstream modulation
(signal-to-noise ratio-based), and input power levels.
• Intelligent and Advanced Hardware-Based Spectrum Management, on page 425—Describes spectrum
management features that are supported by a number of cable interface line cards that have onboard
spectrum management hardware. These features include a real-time spectrum analyzer, CNR-based,
proactive frequency hopping, and a more robust dynamic upstream modulation.
• Benefits, on page 425—Describes the spectrum management features provided on the Cisco CMTS router
platforms.
Spectrum Management Measurements

Measuring the signal-to-noise ratio (SNR [MER]) and carrier-to-noise ratio (CNR [CNiR]) are the major ways
of determining the quality of a downstream or upstream signal. The following sections provide an overview
of these two ratios, as well as explaining the differences between them, and some additional values that might
be useful:
Signal and Carrier Noise Ratios

Measuring the Modulation Error Ratio (MER [SNR]) and CNR (CNiR) of a downstream or upstream is the
first step in determining the quality of the signal, and whether spectrum management needs to be performed
to correct any errors. The following are brief descriptions of these two values:
• Modulation Error Ratio (MER [SNR])—This is an estimate of the signal strength on the upstream after
ingress noise cancellation is performed. This means that the MER (SNR) takes into account a variety of
modulation impairments, including frequency response distortions (such as in-channel amplitude tilt and
ripple), group delay, microreflections, and phase noise. The MER (SNR) is a good gauge of the overall
end-to-end quality of the cable network, because it includes the impact that the transmitter circuitry,
receiver circuitry, and transmission media have on the upstream signal.
• Carrier-to-Noise Ratio (CNR)—This is an ratio of the measured modulated power, in dB, on the upstream
(before ingress noise cancellation is done) that compares the channel power to the noise power.
The term CNiR is part of the CableLabs nomenclature for the CNR measurement. Therefore these two
terms, CNR and CNiR, can be used interchangeably.
The CNR (CNiR) measurement is usually provided only by an external spectrum analyzer, but the cable
interface line cards that support intelligent and advanced hardware spectrum management features also
provide CNR (CNiR) measurement.
The following two types of CNR (CNiR) measurements are supported on the Cisco CMTS:
412
Differences Between the MER (SNR) and CNR (CNiR) Values
• CNR (CNiR) measured for a particular upstream—This is the overall CNR (CNiR) for all of the
cable modems on an upstream, which is determined by measuring the RF power of the upstream
receiver at the cable interface. This value is always just a snapshot in time for a particular upstream.
The cable interface measures the RF power at a time when no bursts are expected from the cable
modems, but it can be skewed by a small number of cable modems that are experiencing or creating
signal problems.
• Per-modem CNR (CNiR)—This is the CNR (CNiR) for a particular cable modem, which is signal
strength of the burst transmissions of the modem at the upstream receiver of the cable interface.
The per-modem CNR (CNiR) measurement is a very accurate measure of a particular cable modem’s
signal, but you should not use a single modem’s CNR (CNiR) to make assumptions about other
cable modems on that upstream or about the upstream itself. However, you can get a good picture
of the upstream’s signal quality by polling the CNR (CNiR) for a number of cable modems over a
representative time period.
Tip Changing the channel width has a direct impact on the CNR (CNiR). Doubling
the channel width (for example, from 400 KHz to 800 KHz) decreases the CNR
(CNiR) for an upstream by approximately 3 dB. Cutting the channel width in
half (for example, from 3.2 MHz to 1.6 MHz) increases the CNR (CNiR) for an
upstream by approximately 3 dB.
Differences Between the MER (SNR) and CNR (CNiR) Values

In a perfect network, such as a test lab where the only impairment is additive white Gaussian noise (AWGN),
you can expect the CNR (CNiR) and MER (SNR) values to be comparable throughout all of the allowable
power levels and frequency ranges. In a live network, however, it is expected that the MER (SNR) value
should be a few dB lower than the CNR (CNiR) value, given that the MER (SNR) value takes into account
noise impairments and distortions that are not accounted for by the CNR (CNiR) power measurements.
In general, when the CNR (CNiR) value is in the 15 to 25 dB range, you can expect the MER (SNR) value
to have a comparable value. The difference between the MER (SNR) and CNR (CNiR) values is expected to
be larger when the CNR (CNiR) value falls outside of the 15 to 25 dB range.
The table below provides a comparison between the MER (SNR) and CNR (CNiR) values, listing the major
reasons for why the MER (SNR) and CNR (CNiR) values might diverge on an active network that is passing
live traffic:
Table 69: Comparison of MER (SNR) and CNR (CNiR) in a DOCSIS Cable Network
Signal-to-Noise (SNR) Carrier-to-Noise (CNR)
Post-detection measurement of the RF signal. Pre-detection measurement of the RF

signal.
Measurement of the baseband domain. Measurement of the RF frequency domain.
413
SNR Smoothing
Signal-to-Noise (SNR) Carrier-to-Noise (CNR)
Includes the effect of signal distortions and impairments on the Measures only the RF modulated carrier
signal. These include: power versus noise power.
• Group delay in the channel such as occurs during operation
near the diplexer band edge.
• Channel amplitude variation and echoes.
• Data collisions.
• Microreflections.
• Narrow band ingress in the channel.
• Non-linearities in the cable plant.
• Phase noise.
• Poor selection of the preamble.
• Poor symbol fidelity in the transmission of a a cable
modem, despite a good MER (SNR) value.
• Unrecoverable carrier offsets.
• Unrecoverable symbol timing offsets.
Provides an indication of overall, end-to-end network quality Provides an indication of network

(what the transmitter, receiver, and transmission media are doing performance (what the transmission media
to the signal). or network is doing to the signal).
Average over time with current data traffic patterns, useful for Real-time spectrum analysis.
tracking long-term trends in signal quality.
Reflects the CNR (CNiR) value as part of its value. Does not reflect the MER (SNR) value as
part of its value.
Averaged over 10,000 symbols, and an accurate reading requires Unaffected by the type of traffic being
that short and long grants are being transferred. transmitted.
Does not use packets with uncorrectable FEC errors to determine Unaffected by uncorrectable FEC packet
its value. Bursts of uncorrectable errors, therefore, could result bursts.
in a deceptively high MER (SNR) value.
DOCSIS specifications do not define any required MER (SNR) Minimum downstream CNR of 35 dB in a
values for upstreams and downstreams. 6-MHz band (44 dB in DOCSIS 2.0 for
8-MHz band)
Minimum upstream CNR (CNiR) of 25 dB.
SNR Smoothing
Cisco cBR 16.12.1w and later, supports the following methods of easing the fluctuations in SNR:
• Cable Modem-based SNR
414
Additional Measurements
• US Channel-based SNR
Cable Modem-based SNR

The SNR error (2-Bytes) is decoded by US-PHY ASIC and calculated by using the SNR formula, 10 * log10
(power/error). For example:
• error=7 SNR(db)=36.62db
• error=15 SNR(db)=33.22db
The MIB is docsIf3CmtsCmUsStatusSignalNoise.

Use the cable ranging cm packet command to configure the number of ranging packets to get the CM-based
SNR.
Router(config)# cable ranging cm packet <1-20>
The number of ranging packets can be 1 to 20. The default value is 1.
US Channel-based SNR
The SNR of a single US channel is calculated from the ranging packets of cable modems (CM) on that US
channel. Cisco cBR-8 takes an average of every 10 SNR values from a CM to generate the SNR of the US
channel. If a new CM SNR value is close to (within 3DB) the current US channel SNR, the Cisco cBR-8
router uses the new CM SNR to represent the current US channel SNR.
The MIB is docsIfSigQSignalNoise.
Use the cable ranging upstream packet command to configure the number of ranging packets to get the US
channel-base SNR.
Router(config)# cable ranging upstream packet <10-80>
The default value is 10.

Use the cable ranging upstream deviation to configure the per upstream SNR deviation number.
Router(config)#cable ranging upstream deviation <1-3>
The default value is 3.

To display the cable ranging configuration, use the show cable ranging setting command. For example:
Router#show cable ranging setting
num_pkt_per_us: 20
num_pkt_per_cm: 5
snr_dev: 2
Additional Measurements
In addition to MER (SNR) and CNR (CNiR) values, you should be aware of and monitor the following
indicators of signal quality:
• MER—This is the measure of RF signal quality, in dB, which is equivalent to SNR and similar to CNR
(CNiR) under additive white Gaussian noise (AWGN) impairments. However, MER is preferred for data
networks, because it also includes additional factors that affect the signal, such as analog-to-digital and
digital-to- analog conversions, rounding errors, distortions, and signal impairments such as phase noise,
415
Upstream Signal Channel Overview
group delay, and jitter. For this reason, the DOCSIS 2.0 RF specification adds a requirement for the
minimum MER value for a signal, supplementing the existing CNR (CNiR) minimum requirements.
A simple formula for calculating the MER value for an upstream is:
MER = 20 x log (RMS error magnitude / Average symbol magnitude)
You can also calculate the Error Vector Modulation (EVM) to find the equivalent value expressed as a
percentage of noise on an upstream:
EVM = Average error magnitude / Max symbol magnitude * 100
See the DOCSIS 2.0 specification for more complete information on calculating and using the MER
value.
• FEC Counters—These are counters that keep track of how many correctable and uncorrectable FEC
errors occur on the upstream. The FEC error counters are useful for tracking fast transient errors such as
impulse noise that are not usually reflected in MER (SNR) or CNR (CNiR) values.
A correctable error count of more than 1 percent can be used as a warning sign of possible physical plant
or cable modem problems that might be developed. An uncorrectable error count of more than 1 percent
can indicate an existing problem that is blocking traffic on the upstream. Cable interface line cards that
support the intelligent and advanced spectrum management features can use the FEC counters as one of
the indicators to be monitored to determine whether an upstream must change frequencies so as to correct
noise problems.
• Microreflections—Additional copies of a signal that arrive at the receiver, usually at different times and
attenuated by different amounts, causing the receiver to misidentify the incoming signal’s true phase and
amplitude. Microreflections typically are caused by impedance mismatches in the physical cable plant,
and can indicate either equipment that has been degraded by weather or other causes, or equipment that
has not been installed correctly.
Upstream Signal Channel Overview

The upstream channel is characterized by many cable modems transmitting to the CMTS. These signals operate
in a burst mode of transmission. Time in the upstream channel is slotted. The CMTS provides time slots and
controls the usage for each upstream interval. The CMTS periodically broadcasts Upstream Channel Descriptor
(UCD) messages to all cable modems. The UCD message contains the upstream frequency and transmission
parameters associated with an upstream channel. These messages define upstream channel characteristics
including the upstream frequencies, symbol rates and modulation schemes, forward error correction (FEC)
parameters, and other physical layer values.
Cisco supports all DOCSIS error-correction encoding and modulation types and formats. Upstream signals
are demodulated using QPSK or QAM. QPSK carries information in the phase of the signal carrier, whereas
QAM uses both phase and amplitude to carry information.
Sending data reliably in the upstream direction is an issue. Because upstream spectrum varies greatly between
cable plants, select upstream parameters based on your cable plant’s return paths. Select or customize upstream
profiles for the maximum trade-off between bandwidth efficiency and upstream channel robustness. For
example, QAM-16 requires approximately 7 dB higher CNR (CNiR) to achieve the same bit error rate as
QPSK, but it transfers information at twice the rate of QPSK.
416
Upstream Segments and Combiner Groups
Note The above specifications are based on predetermined sets of frequencies that may or may not have an adequate
CNR (CNiR) at any given time.
Upstream frequencies can be assigned as follows:

• Fixed—Configuring a spectrum group disables the fixed upstream frequency setting.
• Single subband—The CMTS administrator can define a center frequency and symbol rate such that the
boundaries of the upstream carrier stay within the subband. The frequency and symbol rate can change
within the boundary in response to noisy line conditions, based on the defined upstream parameters.
• Multiple subbands—The data carrier can remain in a particular subband for a duration of time and then
hop to another subband based on the defined upstream parameters.
Tip Measurement of noise power levels with a spectrum analyzer should be part of the procedure in initially
selecting and setting up frequency allocations. We recommend having fixed frequency settings during early
deployment, at least until amplifier cascade adjustments or plant repair have become infrequent enough that
they no longer significantly affect the nodes connected to the upstream port.
Upstream Frequency Changes

As stated in the DOCSIS radio frequency interface (RFI) specification, RF channel migration or upstream
frequency change occurs when a change in the UCD message is broadcast to all cable interfaces.
The speed of channel migration via the UCD message is typically less than 20 milliseconds (ms). During this
time, upstream transmission is interrupted until the cable interface transmitter adjusts to its new frequency.
Data is stored in the cable interface buffers during this time and is sent when the frequency hop is complete.
Station maintenance intervals are used to perform per modem keepalive polling. The CMTS polls each cable
modem at least once every 30 seconds, with the default being once every 20 seconds. When ingress noise
causes loss of keepalive messages from a configurable percentage of all cable interfaces, resulting in missed
polls, a new frequency is selected from the allocation table and a UCD update is performed. The migration
time is 2 msec for any upstream UCD update. After the UCD is updated, the hop occurs. The system must
wait until a hop threshold time interval has elapsed before it can change the UCD a second time.
Upstream Segments and Combiner Groups

The Cisco routers divide a cable plant into downstream channels. Downstream channels contain upstream
segments. Each upstream segment typically serves more than one fiber node. Upstream segments can be
defined as one of the following:
• Sparse segment—Containing one upstream channel per upstream segment.
• Dense segment—Containing multiple upstream channels per upstream segment; frequencies must be
different.
417
Frequency Management Policy
Note A cable interface line card can support sparse or dense segments, or both.
Defining sparse segments allows the cable operator to share upstream bandwidth among fiber nodes with
fewer subscribers. Defining dense segments allows the cable operator to provide larger upstream bandwidth
to fiber nodes with many subscribers.
The figure below illustrates sparse versus dense segments.
Figure 18: Sparse Versus Dense Segment Illustrations
As shown in the figure above, the downstream segment can contain multiple upstream segments. Two fiber
nodes can be in one downstream segment but in different upstream segments.
The return path of several fiber nodes can be combined at a single point to form a single RF frequency domain
called a combiner group. The CMTS software allows a frequency hop table called a spectrum group to be
associated with a combiner group.
Note A combiner group refers to an RF topology point. A spectrum group refers to the frequency hop table associated
with a combiner group.
Frequency Management Policy

Spectrum management applies a common frequency-management policy to a set of upstream ports to ensure
that data is delivered reliably over the cable plant. Cable plant operators must make noise measurements and
determine the cable plant’s spectrum management policy. Different modulation schemes, upstream frequency
techniques, and symbol rates are used based on the cable plant characteristics and the cable interface line card
in the chassis.
418
Noise Impairments
See the following sections for more information about these topics:
Noise Impairments
Upstream noise impairments such as signal degradation on cable networks can negatively affect service to
subscribers. Two-way digital data signals are more susceptible than one-way signals to stresses in the condition
of the HFC network. Degradation in video signal quality might not be noticeable in one-way cable TV service,
but when two-way digital signals share the network with video signals, digital signals can be hampered by:
• Impulse and electrical signal ingress—Noise can enter the network from electrical sources within a
residence or from high-voltage lines that run near cable television cabling. Two types of ingress noise
include broadband and narrowband. Broadband noise is generally of lower frequency (below 10 MHz)
and results in harmonic rolloff. Narrowband noise is a more significant interference source. Cable
equipment and infrastructure often pick up noise from amateur radio transmissions, citizen band radios,
or high-power shortwave broadcast signals. Implement a signal leakage maintenance program to locate
and repair areas of signal ingress.
• Amplifier noise—Amplifiers add noise to the HFC network that typically goes unnoticed in video signals,
but degrades digital data signals if amplifiers are improperly configured. The larger the network, the
higher the probability of amplifier noise affecting signals.
• Noise funneling—The upstream data path to the headend is susceptible to interference from the entire
network. All upstream noise ultimately ends up at the headend because the cumulative nature of noise
becomes concentrated at the headend. As a network serviced by a single RF receiver increases in size,
the probability of noise funneling also increases.
• Variable transmit levels—Temperature affects signal loss over coaxial cable. This can cause variations
of 6 to 10 dB per year.
• Clipping—The lasers in fiber-optic transmitters can stop transmitting light when input levels are excessive.
Excessive input levels introduce bit errors in both the upstream and downstream transmissions. If a laser
is overdriven as briefly as a fraction of a second, clipping can occur.
To adjust your return amplifiers and lasers, follow rigorous plant maintenance procedures documented in the
NTSC Supplement on Upstream Transport Issues or appropriate cable plant standard.
Spectrum Groups and Frequency Hopping

We recommend that CMTS administrators configure upstream frequency hopping to counteract long-term,
narrowband noise. Cisco CMTS routers support a combination of guided frequency hopping and time-scheduled
frequency hopping.
The frequency hop to proactively avoid noise ingress is sometimes called frequency agility. Frequency agility
is configured and activated using spectrum groups. Spectrum management supports the creation of a number
of cable spectrum groups, allowing multiple upstream ports in a single spectrum group. Each spectrum group
defines the table of frequencies to be used in a specific frequency plan. Upstream frequencies can be a fixed
single frequency, a single continuous range of frequencies (band), or multiple ranges (or bands) of frequencies.
The cable interface does not operate until you assign a frequency to the upstream, which can be done either
by configuring and assigning a spectrum group or assigning a fixed frequency. The spectrum group takes
precedence, so if you configure both a spectrum group and a fixed frequency on an upstream, the spectrum
group overrides the fixed upstream frequency setting.
From the interface point of view, a spectrum group also represents the set of upstreams connected to the same
group of fiber nodes. The spectrum manager software in Cisco routers examines all the RF parameters that
419
Guidelines for Spectrum Management
have been configured on an upstream to determine whether the upstream frequencies need to be managed
together. For example, if you configure a spectrum group with several fixed frequencies, but those frequencies
are all within the configured channel width, the spectrum manager software combines the frequencies into a
single band.
The upstream ports use the spectrum group to determine which frequencies are available if frequency hopping
is needed to deal with noise or other path impairments. The types of frequency hopping techniques are guided,
time-scheduled, and combined guided and time-scheduled. See the Frequency Hopping Capabilities, on page
420 for more information on the types of frequency hopping techniques.
Note When each upstream port has its own RF domain, the group is called a nonshared spectrum group. When
multiple upstream ports share the same RF domain, the group is called a shared spectrum group.
Guidelines for Spectrum Management

In general, when defining your spectrum, use the following guidelines:
• Avoid frequencies with known ingress problems, such as amateur radio bands or short-wave bands.
• Avoid a hostile spectrum below 20 MHz.
• Allow extra bands for frequency hopping.
• Take the possible channel widths into account when creating frequency bands. The range of frequencies
being used must be able to hop between at least two different frequencies when using the channel width
that is configured on the upstream.
• Place upstream ports in the same combiner group in a shared spectrum group.
• If you combine multiple upstream ports to provide increased bandwidth, you must avoid overlapping
frequency bands. Each port should be using a discrete band of frequencies that does not overlap the bands
being used by other ports in the group. We recommend adding at least 20 KHz between the ending
frequency of one band and the starting frequency of the next band, to ensure that the bands do not overlap.
Guided and Scheduled Spectrum Management

Guided and scheduled spectrum management constitutes a set of basic features for all currently supported
cable interface line cards. These features are considered basic because they are available for all cable interfaces,
and constitute the elementary, cornerstone features upon which the intelligent and advanced spectrum
management features are built.
See the following sections for more information about each feature:
Frequency Hopping Capabilities

Noise in the upstream transmission line, that is from the consumer to the service provider, can degrade data
transmission from the subscriber’s home. If the noise impairment is of substantial duration, it may cause the
cable modem to temporarily lose communication with the headend facility. As a contingency plan, the multiple
service operators (MSOs) can reserve multiple channels or upstream frequencies for their subscribers. If one
channel suffers too much interference, the CMTS requests that the cable modems “hop” to another channel.
420
To provide frequency hopping capability, Cisco CMTS routers contain a spectrum manager that continuously
monitors the noise in unused upstream channels. If the CNR (CNiR) reaches an unacceptable level on a
particular channel, the spectrum manager automatically assigns a new upstream channel to the cable modem
using that channel.
Cisco CMTS routers support the following techniques for upstream frequency hopping when the frequency
band in use is not clean:
• Guided frequency hopping—In guided frequency hopping (also known as blind hopping), the spectrum
manager automatically assigns a new upstream channel frequency when a configurable threshold of
station maintenance (keepalive) messages fails. Failed station maintenance messages represent an
impairment of the upstream channel due to noise, plant, or equipment failure. Explicit frequency subbands
and associated input power levels are assigned in a spectrum group in guided frequency hopping.
• Time-scheduled frequency hopping—Frequency reassignment is scheduled by the time of day or by a
specific day of the week.
• Combined guided and time-scheduled frequency hopping.
Note Frequency hopping is not effective against broadband noise phenomena such as impulse noise.
Time-scheduled and guided hopping techniques are independent concepts:

• The spectrum is controlled by a script, not a frequency table.
• The available spectrum is time-scheduled as an option.
• A guided hopping frequency is selected from the available spectrum at the current time.
You can configure and activate frequency hopping by using spectrum groups. You can create up to 40 cable
spectrum groups, each containing multiple upstream ports. The configured channel width is used for each
upstream frequency.
After you have created one or more spectrum groups for your cable network, you can add characteristics to
them, providing you with more definitive control over frequency usage and frequency hopping.
You can configure hopping thresholds. For example, the frequency hop threshold percentage method prevents
a single failing cable modem from affecting service to other working cable modems. As long as a high enough
threshold is configured, the system does not hop endlessly due to a single cable modem failing to respond to
90 percent of its station maintenance (keepalive) messages.
You can also configure the minimum period between frequency hops, with a default setting of 30 seconds. If
the destination channel is expected to be impaired, you can reduce the minimum period between frequency
hops to a small value, such as 10 seconds. This allows the frequency hop to continue more rapidly until a
clear channel is found. If excessive frequency hop is an issue, you can increase the minimum period between
hops.
To configure different techniques of frequency hopping, see the Creating and Configuring Spectrum Groups,
on page 428.
Note Spectrum management is not supported for one-way (telco return) cable modems, because spectrum management
capabilities focus on the upstream path over an HFC network.
421
Dynamic Upstream Modulation (MER [SNR]-Based)
Note After the spectrum-band is changed, the spectrum management does not rearrange the frequency for each US
channel if the previous frequency belongs to the range of new spectrum-band, which means that the US
frequency will not be changed; if the previous frequceny is out of range of new spectrum-band, those US
channels will not get frequencies.
Time-Scheduled Frequency Hopping

You can specify upstream channel frequency reassignment based on a configured time of every day or of a
specific day of the week. If your cable plant has an upstream noise characteristic on a weekly cycle, use
time-scheduled spectrum allocation. With a time-scheduled policy, a single frequency becomes valid at any
given time.
Dynamic Upstream Modulation (MER [SNR]-Based)

This section describes the operation of this feature, which is based on evaluating the MER (SNR) of an
upstream.
Note A more advanced version of dynamic upstream modulation, which uses the carrier-to-noise ratio (CNR
[CNiR]), is supported on the cards that support intelligent and advanced spectrum management.
Feature Overview
Cisco cable interface line cards monitor the MER (SNR) values and the forward error correction (FEC) counters
in the active return path of each upstream port. The Dynamic Upstream Modulation feature determines whether
upstream channel signal quality can support the modulation scheme configured, and adjusts to the most robust
modulation scheme when necessary. When return path conditions improve, this feature returns the upstream
channel to the higher modulation scheme that includes the modulation profile.
A modulation profile is a collection of burst profiles that are sent out in a UCD message to configure modem
transmit parameters for the upstream. The Dynamic Upstream Modulation feature adjusts the modulation
profiles of an upstream channel based on upstream signal quality.
The Dynamic Upstream Modulation feature is configured on interfaces with fixed upstream frequencies or
on interfaces with assigned spectrum groups.
The following examples show two different configurations of the Dynamic Upstream Modulation feature,
using two and three modulation profiles.
Example Showing Dynamic Upstream Modulation Using Two Modulation Profiles

You can configure the Dynamic Upstream Modulation feature on the Cisco CMTS router using the following
primary and secondary modulation profiles:
• The primary modulation profile uses 64-QAM or 16-QAM, which is a more bandwidth-efficient
modulation scheme and has a higher throughput than a QPSK profile.
• The secondary modulation profile uses QPSK, which uses a more robust modulation scheme, but is not
bandwidth-efficient.
422
Criteria for Switching Modulation Profiles
We recommend that the primary profile use 64-QAM or 16-QAM modulation and the secondary use QPSK.
However, this is optional as both modulation profiles can either be QPSK or QAM. It is not mandatory for
one profile to be QAM and the other QPSK, but modulation profile switchover is tied to the QAM and QPSK
thresholds.
Example Showing Dynamic Upstream Modulation Using Three Modulation Profiles

You can configure the Dynamic Upstream Modulation feature on the Cisco CMTS router using the following
primary, secondary, and tertiary modulation profiles:
• The primary modulation profile uses 64-QAM, which is a more bandwidth-efficient modulation scheme
and has a higher throughput than a 16-QAM profile.
• The secondary modulation profile uses 16-QAM, which is a more bandwidth-efficient modulation scheme
and has a higher throughput than a QPSK profile.
• The tertiary modulation profile uses QPSK, which uses a more robust modulation scheme, but is not
bandwidth-efficient.
We recommend that the primary profile use 64-QAM modulation, the secondary profile use 16-QAM, and
the tertiary profile uses QPSK. However, this is optional as the modulation profiles can either be QPSK or
QAM. It is not mandatory that one is QPSK and the other two are QAM, but modulation profile switchover
is tied to the QAM and QPSK thresholds.
Criteria for Switching Modulation Profiles

The Dynamic Upstream Modulation feature uses the following criteria to determine whether it should switch
from the primary modulation profile (the more bandwidth-efficient, but less robust profile) to the secondary
modulation profile (more robust, but less bandwidth-efficient profile) or to the (optional) tertiary modulation
profile (most robust, but less bandwidth-efficient profile):
The modulation switch from the primary profile (high performance) to the secondary profile (mid-level
performance) uses the following criteria:
• The upstream MER (SNR) is less than or equal to MER (SNR) threshold one and the percentage of
correctable FEC (cFEC) errors is greater than or equal to the correctable FEC error threshold or the
percentage of uncorrectable FEC (uFEC) errors is greater than or equal to the uncorrectable FEC error
threshold.
Before switching back to the primary profile from the secondary profile, the following criteria must be satisfied:
• The upstream MER (SNR) is greater than or equal to the sum of MER (SNR) threshold one and the
hysteresis value and the percentage of correctable FEC errors is less than or equal to the correctable FEC
error threshold and the percentage of uncorrectable FEC errors is less than or equal to the uncorrectable
FEC error threshold and the hop period equals to the default value of 15 seconds.
The modulation switch from the secondary profile (mid-level performance) to the tertiary profile (most robust)
uses the following criteria:
• The upstream MER (SNR) is less than or equal to MER (SNR) threshold two and the percentage of
threshold.
Before switching back to the secondary profile from the tertiary profile, the following criteria must be satisfied:
423
Input Power Levels
• The upstream MER (SNR) is greater than or equal to the sum of MER (SNR) threshold two and the
hysteresis value and the percentage of correctable FEC errors is less than or equal to the correctable FEC
error threshold and the percentage of uncorrectable FEC errors is less than or equal to the uncorrectable
FEC error threshold.
The modulation switch from the primary profile to the tertiary profile uses the following criteria:
• The upstream MER (SNR) is less than or equal to MER (SNR) threshold two and the percentage of
threshold.
Before switching back to the primary profile from the tertiary profile, the following criteria must be satisfied:
• The modulation switch from the tertiary profile to the primary profile is a two-step process:
1. The modulation switch happens from tertiary profile to the primary profile, when the upstream MER
(SNR) is greater than or equal to the sum of MER (SNR) threshold one and the hysteresis value.
2. After a 15-second (non-configurable) delay, the modulation switch occurs from secondary profile
to the primary profile, when the upstream MER (SNR) remains greater than or equal to the sum of
MER (SNR) threshold one and the hysteresis value.
If the only problem is that the upstream is experiencing a large number of uncorrectable errors, then a situation
could occur where the router continues to switch back and forth between profiles. The uncorrectable errors
occur with the primary profile, so the router switches to the secondary profile. The secondary profile does not
experience any problems, so the router switches back to the primary profile. But the uncorrectable errors
reoccur and the router switches back to the secondary profile, and this cycle continues indefinitely.
To avoid this problem, make sure that the cable plant is capable of supporting the modulation scheme being
used in the primary profile (for example, 64-QAM). If you cannot guarantee successful operation on an
upstream using this modulation scheme, then you should select a primary profile that uses a more
bandwidth-efficient set of burst parameters (such as QPSK). The Cisco IOS software includes predefined
modulation profiles that can be used for the primary, secondary, and tertiary profiles.
Input Power Levels

The input power level, power-level-dBmV, is an option in the cable spectrum-group command. The option
allows you to specify the expected upstream input power levels on the upstream receivers on the CMTS when
the cable modems are hopping from one fixed frequency to another or from one band to another. Each upstream
channel width has an associated upstream input power level in dBmV. The power level is the modem transmit
power that each spectrum group can use when an upstream frequency change is necessary. The input power
level may be set at the time of the frequency hop.
Specifying an input power level is done so that the cable modems do not have to increase or decrease their
transmit power with every hop. The cable operator can perform minor power equalizations as a function of
frequency. The valid range is –10 to 10dBmV. The power level value should be changed only if you want to
change the power level as part of spectrum management. Some cable plants may want to change only the
input power level, and not the frequency, on a daily time schedule.
424
Intelligent and Advanced Hardware-Based Spectrum Management
Intelligent and Advanced Hardware-Based Spectrum Management

Several cable interface line cards include hardware-based spectrum management features that provide
enhancements to the basic features supported by the other Cisco cable interface line cards.
Intelligent Spectrum Management Enhancements

The following features are part of the intelligent spectrum management feature set:
• Integrates a DOCSIS cable interface line card with an onboard spectrum analyzer that continuously
analyzes the upstream spectrum quality in the DOCSIS frequency range of 5 to 42 MHz.
• Includes hardware-assisted frequency hopping, providing for more intelligent and faster frequency
selection than software-only solutions.
• Reduces the response time to ingress noise that could cause modems to drop offline.
• Eliminates blind frequency hopping by initiating frequency hops to known clean channels.
• Improves frequency agility to help eliminate dropped packets and thereby maintain full upstream data
rates.
• Supports frequency agility in dense-mode combining environments across a shared spectrum.
• Restricts frequency hopping to a set of discrete fixed frequencies or to a range of frequencies, as desired.
• Allows frequency hop conditions to be customized for specific plant environments and requirements.
• Optionally schedules frequency hops to take advantage of known usage patterns or plant conditions.
• Optionally dynamically reduces channel width to allow cable modems to remain online, even in noisy
upstream conditions.
Benefits
The spectrum management features provided on the Cisco CMTS router platforms provide several key system
benefits:
• Improves response time to ingress noise impairments that appear in the upstream return path.
• Boosts the percentage of modems online.
• Mitigates the impact of ingress to subscriber services.
• Saves time and effort by MSO staff when troubleshooting minor plant outages.
• Increases cable plant reliability.
• Maximizes spectrum utilization.
Guided and Scheduled Spectrum Management Benefits

The following summarizes the specific benefits of the guided and scheduled spectrum management features
that are supported for all Cisco CMTS router platforms.
425
Intelligent and Advanced Spectrum Management Benefits
Input Power Levels

Allows the cable plant operator to perform minor power level equalization as a function of frequency.

Proactively countermeasures upstream noise impairments by assigning a new upstream channel to the cable
modem. MSOs can take advantage of this feature especially when they have less than an optimal carrier-to-noise
ratio in the upstream frequencies or when their cable plants exhibit random bursts of ingress noise that affect
reliability.

• Reduces the risk associated with transitioning to QAM-16 modulation in the return path and provides
assurance that subscribers remain online and connected during return path impairments.
• Checks that the active upstream signal quality can support the configured modulation scheme and
proactively adjusts to the more robust modulation scheme when necessary.
• Eliminates the necessity to hop channels for cable modems to stay online by automatically switching
from the primary modulation profile to the secondary modulation profile.
Intelligent and Advanced Spectrum Management Benefits

The following summarizes the specific benefits of the advanced spectrum management features that are
supported on Cisco CMTS routers using supported cable interface line cards.
Dynamic Channel Width Change

• Improves the DOCSIS upstream channel availability by finding the maximum possible channel width
for an upstream when noise conditions make the current channel width unusable.
• Provides the maximum RF spectrum utilization efficiency for current plant conditions.
• Customizable range of channel widths that can be used to respond to noise problems.
Intelligent Frequency Hopping

• Proactively changes upstream frequency for an interface before noise conditions become severe enough
to force cable modems offline.
• Dedicated hardware intelligent frequency hopping performs “look-ahead” to choose new upstream
frequency to find a stable channel.
• Flexible priority configuration allows hopping decision criteria to be tailored to the individual cable plant
environment.
• Improves responsiveness to ingress impairments, by matching the hopping decision criteria to the
fluctuating plant conditions.
• Pinpoints CNR (CNiR) variations with per-modem accuracy to isolate problematic cable modems.
• Sustains or even improves subscriber online percentages through user-programmable proactive channel
management techniques.
426
How to Configure Spectrum Management

• Reduces the risk associated with switching between QPSK and QAM-16 modulation in the upstream to
respond to ingress noise, so that subscribers remain online and connected.
• Checks the current upstream signal to ensure that it can support the configured modulation scheme, and
proactively adjusts to the secondary more robust modulation scheme when necessary.
• Improves DOCSIS upstream channel availability and provides maximum RF spectrum utilization
efficiency.
• Eliminates unnecessary frequency hopping by switching modulation profiles to one that allows cable
modems to remain online while using the currently assigned upstream.
• Provides assurance that subscribers remain online and connected during periods of return path impairments.
SNMP Interface
• Provides a way to remotely obtain the current status of noise on an upstream. This information can then
be inserted into third-party or custom reporting and graphing applications.
• Provides visibility to ingress and impulse noise under the carrier frequency on a per-port basis.
• Provides an easy-to-use, distributed method to remotely gather real-time display of the DOCSIS upstream
spectrum for individual cable modems and set-top boxes (STBs).
• Reduces the reliance on costly spectrum analyzers at every headend or hub.
• Quickly provides spectrum views through an intuitive interface, without the complicated setup time of
a spectrum analyzer.
• Allows the technician to troubleshoot the network remotely, as opposed to having to be physically present
to connect and use a spectrum analyzer.
Default Hop Priority

For Intelligent and Advanced Spectrum Management feature, the default hop priority is as given below:
• Frequency, modulation, and channel width (when using spectrum groups on spectrum cards).
• Modulation, guided frequency hop, and channel width (when using analyzer cards with spectrum groups).
• Modulation only (when not using spectrum groups [fixed frequency]).
How to Configure Spectrum Management

This section describes the configuration tasks that are most commonly performed when using the spectrum
management features on the Cisco CMTS platforms. See the following sections for the configuration tasks
that are appropriate for your platform and cable interface line cards.
427
Guided and Scheduled Spectrum Management Configuration Tasks
Guided and Scheduled Spectrum Management Configuration Tasks

The following tasks configure the guided and scheduled spectrum management features that are supported
on all Cisco CMTS platforms:
Creating and Configuring Spectrum Groups

A spectrum group defines the frequencies that an upstream is allowed to use when frequency hopping is done,
as well as other parameters that control the frequency hops. When creating and configuring spectrum groups,
you can specify the following parameters:
• Frequencies that are assigned to the group. The cable interface uses these frequencies to determine what
frequencies are available to use when frequency hopping is needed. You can specify either a list of fixed
frequencies or a band of frequencies, or both. The Cisco CMTS uses the following rules when adding
frequencies to a spectrum group:
• When specifying a fixed frequency, the Cisco CMTS assumes it is a center frequency with a 6.4-MHz
channel width to allow that frequency to operate at all possible channel widths. For example,
specifying a frequency of 17,700,000 Hz is equivalent to specifying a frequency band from 14,500,000
Hz to 20,900,000 Hz (a band that is 6.4 MHz wide).
• If you configure multiple fixed frequencies or bands of frequencies that overlap, the spectrum group
combines them into one band. For example, if you specify a fixed frequency of 17,700,000 Hz and
a band from 15,800,000 Hz to 25,200,000 Hz, the spectrum group is configured with one band from
14,500,000 Hz to 25,200,00 Hz.
• If you want more control over a spectrum group’s frequencies, configure bands of frequencies with
the same width as the desired channel width. For example, if you want to use a center frequency of
17,700,000 Hz with a 3.2-MHz channel width, specify a band that ranges from 16,100,000 Hz to
19,300,000 Hz. To ensure you configure non-overlapping bands, separate the bands by a minimum
of 20 KHz.
• Upstream input power level—(Optional) Power level, in dBmV, that the upstream should use when
hopping to a new frequency. (Some cable plants might want to change only the input power level, and
not the frequency, on a daily time schedule.)
• Hop threshold—(Optional) Percentage of cable modems that start missing station maintenance messages
before a frequency hop can occur. Configure the hop threshold percentage as needed to prevent a single
failing cable interface from affecting service to other good cable interfaces. This ensures that the system
does not hop endlessly because one cable modem is generating 90 percent of the errors and 90 percent
of the traffic.
• Hop period—(Optional) Minimum time period that must elapse between frequency hops. This allows
you to specify a time period long enough to allow an upstream to stabilize before another frequency hop
can be performed.
• Scheduled hop time—(Optional) Time of day at which a frequency hop should be scheduled.
Tip Before adding a list of upstream frequencies (or frequency hop tables), start by determining which upstream
ports are assigned to a combiner group. Refer to the Example: Determining the Upstream Ports Assigned to
a Combiner Group, on page 451 for an example.
428
Creating and Configuring Spectrum Groups
To create and configure a spectrum group, use the following procedure.
Procedure

prompted.
Example:
Router> enable

Example:
Step 3 cable spectrum-group group-number time[day hh:mm:ss] Creates the spectrum group (if it does not already exist),
frequency up-freq-Hz [power-level-dBmV] and adds the specified fixed frequency to the group.
Example:
Router(config)# cable spectrum-group 4 time Monday
12:00:00 frequency 40000000
Step 4 cable spectrum-group group-number time [day hh:mm:ss Creates the spectrum group (if it does not already exist),
] band up-freq-Hz up-freq2-Hz [power-level-dBmV] and adds the specified band of frequencies to the group.
Example: Note Repeat Step 4 and Step 6 as needed for each
Router(config)# cable spectrum-group 4 band fixed frequency and frequency band that should
20000000 24000000 13 be a member of this spectrum group. You must
assign at least two fixed frequencies, or a
frequency band that contains at least two center
frequencies, to a spectrum group before
frequency hopping can occur.
Step 5 cable spectrum-group group-number hop period seconds Specifies the minimum time, in seconds, between frequency
hops.
Example:
Router(config)# cable spectrum-group 4 hop period Note We recommend a configuration of 30 seconds
60 when using a Cisco uBR-MC5X20S/U/H BPE.
Step 6 cable spectrum-group group-number hop threshold Specifies the frequency hop threshold for a spectrum group.
[percent]
• percent—(Optional) Frequency hop threshold as a
Example: percentage of station maintenance messages that are
Router(config)# cable spectrum-group 4 hop lost. Valid range is from 1 to 100 percent, with a
threshold 25 default of 50 percent.
Step 7 cable spectrum-group group-number (Optional) Specifies that the upstream ports in a spectrum
group should use a unique upstream frequency.
Example:
Router(config)# cable spectrum-group 4

EXEC mode.
Example:
429
Assigning a Spectrum Group to One or More Upstream Ports

Router(config)# end
Assigning a Spectrum Group to One or More Upstream Ports

After a spectrum group has been created and configured, you must assign it to one or more upstream ports
before the group’s frequency spectrum is used for frequency hopping.
To assign a spectrum group to one or all upstream ports on a controller interface, use the following procedure.
Procedure

prompted.
Example:
Router> enable

Example:
Step 3 controller upstream-cable slot/subslot/port Enters controller configuration mode.

Example:
Step 4 us-channel us -channel_num spectrum-group Assigns the specified spectrum group as the default group
spectrum-group-num for all upstream on this controller interface.
Example:
spectrum-group 1
Step 5 us-channel us -channel_num channel-width value Configures the channel-width for the specified upstream
channel spectrum group.
Example:
channel-width 1600000
Step 6 end Exits controller interface configuration mode and returns

Example:
What to do next
Tip To verify the spectrum group configuration, use the show cable spectrum-group command in privileged
EXEC mode.
430
Configuring Shared Spectrum Groups (Fiber Node Groups) for DOCSIS 3.0
Configuring Shared Spectrum Groups (Fiber Node Groups) for DOCSIS 3.0
This feature supports shared spectrum groups that cross multiple cable interface line cards on the Cisco CMTS
router, and shared spectrum groups within a single cable interface line card.
For additional information about configuring fiber node groups on the Cisco CMTS, see:
Configuring Dynamic Upstream Modulation (MER [SNR]-Based)

To use the Dynamic Upstream Modulation feature on cable interface line cards that support only the MER
(SNR) version of this feature, you must do the following:
1. Create a primary modulation profile. This typically is a more bandwidth-efficient but a less robust profile.
2. Optionally create a secondary modulation profile. This typically is a less bandwidth-efficient but a
moderately robust profile.
3. Optionally create a tertiary modulation profile. This typically is a less bandwidth-efficient but a more
robust profile.
4. Assign the profiles to the desired cable interfaces and upstreams.
Tip When creating the modulation profiles, we recommend that you use the predefined modulation profiles, as
opposed to manually specifying each burst parameter for each modulation profile.
Restriction • The Dynamic Upstream Modulation feature is supported only for DOCSIS 1.0 or DOCSIS 1.1 TDMA-only
modulation profiles for advanced spectrum management.
• The DOCSIS 2.0 mixed-mode or ATDMA-only mode modulation profiles are supported only for basic
spectrum management (MER [SNR]-based) and not for advanced spectrum management.
• The Three Step Dynamic Modulation feature supports only basic spectrum management features. It does
not support modulation profile changes based on CNR (CNiR) thresholds and CNR (CNiR) measurements.
• The Dynamic Upstream Modulation feature is not enabled for single modulation profile configurations.
• You can configure only two modulation profiles when an upstream is already assigned to a spectrum
group for frequency hopping. The spectrum group here implies advanced spectrum management and/or
the use of CNR (CNiR).
• A single profile is automatically removed from the configuration if three modulation profiles are assigned
to an upstream interface before assigning spectrum group, based on the following conditions:
• The robust profile is dropped if the upstream port is using a high performance profile.
• The high performance profile is dropped if the upstream port is using a mid-level or robust profile.
431
Configuring Dynamic Upstream Modulation (MER [SNR]-Based)
Procedure

prompted.
Example:
Router> enable

Example:
Step 3 cable modulation-profile profile {mixed | tdma | atdma Creates the primary modulation profile for use on a
DOCSIS 1.0 or DOCSIS 1.1 TDMA or A-TDMA
Example:
upstream.
Router(config)# cable modulation-profile 3 mixed
Note Repeat this command to create the secondary
and tertiary profile for use on a DOCSIS 1.0 or
DOCSIS 1.1 TDMA or A-TDMA upstream.

with the cable modulation-profile command
by configuring the values for the individual
burst parameters. These parameters, however,
should not be modified unless you are
thoroughly familiar with how changing each
parameter affects the DOCSIS MAC layer. We
recommend using the preconfigured default
modulation profiles for most cable plants.

Example:
Step 5 us-channel n modulation-profile primary-profile-number Assigns a primary modulation profile, and the optional
[secondary-profile-number] [tertiary-profile-number] secondary and tertiary modulation profiles, to the specified
upstream port.
Example:
modulation-profile 21 121 221
Step 6 Use one of the following commands: (Optional) Specifies the MER (SNR) threshold in dB.
• us-channel n threshold snr-profiles threshold1-in-db
threshold2-in-db
• us-channel n m threshold snr-profiles
threshold1-in-db threshold2-in-db
Example:
Router(config-controller)# us-channel 0 threshold
snr-profiles 25 15
432
Verifying Frequency Hopping

Step 7 Use one of the following commands: (Optional) Specifies the allowable number of correctable
FEC errors for the upstream.
• us-channel n threshold corr-fec corr-fec
• us-channel n m threshold corr-fec corr-fec
Example:
corr-fec 20
Step 8 Use one of the following commands: (Optional) Specifies the allowable number of uncorrectable
FEC errors for the upstream.
• us-channel n threshold uncorr-fec uncorr-fec
• us-channel n m threshold uncorr-fec uncorr-fec
Example:
uncorr-fec 10
Step 9 us-channel n threshold hysteresis hysteresis-in-db (Optional) Specifies the hysteresis value to be used in
conjunction with the dynamic modulation upgrade
Example:
thresholds.
hysteresis 10

Example:
What to do next
Tip See the Dynamic Upstream Modulation (MER [SNR]-Based), on page 422 for a complete description of the
Dynamic Upstream Modulation feature.

You can verify frequency hopping on the CMTS by using the command-line interface (CLI).
Verifying Frequency Hopping Using CLI Commands
To verify frequency hopping using CLI commands, use the following procedure:
Step 1 Verify that the interface being tested is up, using the show interfaces cable command in privileged EXEC mode. The
first line of the output shows whether both the interface and line protocol are up.
Example:
Router# show interfaces cable 9/0/0
Hardware is CMTS MD interface, address is c414.3c16.cf8f (bia c414.3c16.cf8f)

433

Step 2 Verify that the upstream being tested is up, using the show interfaces cable upstream command. The first line shows
whether the upstream is up.
Example:
Router# show interfaces cable 9/0/0 upstream 0
MAC domain upstream impairment report: 0x0

Cable9/0/0: Upstream 0 is up
Description: UC9/0/0:U0
Received 5 broadcasts, 0 multicasts, 26 unicasts
0 discards, 0 errors, 0 unknown protocol
31 packets input
Codewords: 348 good 0 corrected 0 uncorrectable
Step 3 Use the show cable hop upstream-cable command to display the frequency that the upstream is currently using:
Example:
Router# show cable hop upstream-cable 9/0/0
Upstream Port Poll Missed Min Missed Hop Hop Corr Uncorr
Port Status Rate Poll Poll Poll Thres Period FEC FEC
(ms) Count Sample Pcnt Pcnt (sec) Errors Errors
Cable6/0/U5 16.816 Mhz 1000 0 10 0% 20% 25 0 0
Step 4 Use the show cable hop upstream-cable history command to display the frequency change, modulation change, and
channel width change action history of the upstreams:
Example:
Router# show cable hop upstream-cable 9/0/0 history
F = Frequency Hop, M = Modulation Change, C = Channel Width Change

Upstream Action Chg Chg Action
Port Time Code From To Reason
Ca7/0/0/U0 Sep 17 17:00:24 C 1.6 3.2 Configuration changed
Sep 14 19:38:55 F 41.117 26.358 Interface state changed
Sep 14 19:38:24 M 21 221 Configuration changed
Step 5 Use the show cable hop upstream-cable threshold command to display the user-defined thresholds and current CNR,
MER (SNR), correctable FEC percentage, uncorrectable FEC percentage, and missed station maintenance percentage
values of the upstreams:
Example:
Router# show cable hop upstream-cable 6/0/0 threshold
Upstream SNR(dB) CNR(dB) CorrFEC% UncorrFEC% MissedSM%

Port Val Thre1 Thre2 Val Thre1 Thre2 Pcnt Thre Pcnt Thre Pcnt Thre
Ca6/0/0/U0 27 25 15 39 35 25 0 3 0 1 75 75
Ca6/0/0/U1 31 25 15 51 35 25 0 3 0 1 90 75
434
Ca6/0/0/U2 -- 35 25 -- 35 25 0 3 0 1 0 75
Ca6/0/0/U3 -- 35 25 -- 35 25 0 3 0 1 0 75
Step 6 Use the test cable hop command to force the desired upstream to perform a frequency hop. A few seconds after giving
the command, a console message should appear informing you of the hop. Repeat the command as needed to verify that
the upstream hops through all the frequencies that have been assigned to the upstream’s spectrum group.
Example:
Router# test cable hop cable 6/0 upstream 5
2w0d: %UBR7200-5-USFREQCHG: Interface Cable6/0 Port U5, frequency changed to 15.760 MHz
Router# test cable hop cable 6/0 upstream 5
2w0d: %UBR7200-5-USFREQCHG: Interface Cable6/0 Port U5, frequency changed to 26.832 MHz
Step 7 Use the test cable channel-width command to force the desired upstream to perform a channel-width change. A few
seconds after giving the test command, use the show cable hop command to verify the channel-width change.
Example:
Router# test cable channel-width cable 7/0/0 upstream 0
Channel width changed to 1600000 Hz for Cable7/0/0 U0
Router# *Sep 17 17:06:46.882: %UBR10000-5-USCWCHG: Interface Cable7/0/0 U0, channel width changed to
1600 kHz SLOT 7/0: Sep 17 17:06:46.898: %UBR10000-5-USCWCHG: Interface Cable7/0/0 U0, channel width
changed to 1600 kHz
Router# Sep 17 17:06:46.898: %Interface Cable7/0/0 U0 With channel width 1600 kHz, the minislot size
is now changed to 4 ticks.
Router# show cable hop cable 7/0/0 upstream 0 history

Ca7/0/0/U0 Sep 17 17:06:46 C 3.2 1.6 Test command enforced
Sep 17 17:06:02 M 222 221 SNR 36>=28 CFEC 0<=3 UnCFEC 0<=1
Sep 17 17:06:00 M 221 222 Test command enforced
Sep 17 17:03:21 M 222 221 SNR 36>=28 CFEC 0<=3 UnCFEC 0<=1
Sep 17 17:03:19 M 221 222 Test command enforced
Sep 17 17:01:44 F 26.358 19.742 Test command enforced
Sep 17 17:00:24 C 1.6 3.2 Configuration changed
Router#
Step 8 Use the test cable freq-hop command to force the desired upstream to perform a dynamic frequency change. A few
seconds after giving the test command, use the show cable hop command to verify the frequency change.
Example:
Router# test cable freq-hop cable 7/0/0 upstream 0
435
SLOT 7/0: Sep 17 17:01:44.650: %UBR10000-5-USFREQCHG: Interface Cable7/0/0 U0, changed to Freq 19.742
MHz

Ca7/0/0/U0 Sep 17 17:01:44 F 26.358 19.742 Test command enforced
Step 9 Use the test cable modulation-change command to force the desired upstream to perform a dynamic modulation change.
A few seconds after giving the test command, use the show cable hop command to verify the modulation change.
Example:
Router# test cable modulation-change cable 7/0/0 upstream 0
SLOT 7/0: Sep 17 17:03:19.038: %UBR10000-5-USMODCHANGE: Interface Cable7/0/0 U0, dynamic modulation
changed to QPSK
SLOT 7/0: Sep 17 17:03:19.038: %UBR10000-6-PREAMLENADJUST: request burst's preamble length in mod
profile 222 is adjusted to 38 bits.
SLOT 7/0: Sep 17 17:03:19.038: %UBR10000-6-PREAMLENADJUST: initial burst's preamble length in mod
SLOT 7/0: Sep 17 17:03:19.038: %UBR10000-6-PREAMLENADJUST: station burst's preamble length in mod

Ca7/0/0/U0 Sep 17 17:03:19 M 221 222 Test command enforced
Troubleshooting Spectrum Group Characteristics

To troubleshoot the configuration, make sure that you entered a valid spectrum group number, time, frequency,
and input power level. Also, when defining your spectrum, use the following guidelines:
• Avoid frequencies with known ingress problems, such as amateur radio bands or short-wave bands.
• Avoid a hostile spectrum below 20 MHz.
• Allow extra bands for frequency hopping.
• Place upstream ports in the same combiner group in a shared spectrum group.
436
Intelligent and Advanced Spectrum Management Configuration Tasks
Intelligent and Advanced Spectrum Management Configuration Tasks

The following sections describe the configuration tasks that are needed to configure a Cisco uBR7200 series
or Cisco uBR10012 universal broadband router for the intelligent and advanced spectrum management features
that are available with the Cisco cable interface line cards.
Configuring and Assigning Spectrum Groups

You must create and configure a spectrum group before you can use the intelligent and advanced spectrum
management features. These procedures are the same as those used for guided and scheduled spectrum
management, which are given in the following sections:
After the spectrum groups have been configured and assigned to upstreams, the Cisco IOS software
automatically uses the advanced frequency hopping algorithms on the cable interface line cards that support
it.
Note For efficient use of the intelligent and advanced spectrum management features, we recommend configuring
only frequency bands, and not fixed frequencies, when creating spectrum groups. A spectrum group must
contain a frequency band that is wide enough for the cable interface to find at least two center frequencies at
the configured channel width, before frequency hopping can occur.
Configuring Dynamic Upstream Modulation (CNR-Based)

Configuring the CNR-based version of the Dynamic Upstream Modulation feature is similar to configuring
the MER (SNR)-version of this feature:
1. Create a primary modulation profile. This typically is a more bandwidth-efficient but a less robust profile.
2. Create a secondary modulation profile. This typically is a less bandwidth-efficient but a more robust
profile.
Tip When creating the modulation profiles, we recommend that you use the predefined modulation profiles, as
opposed to manually specifying each burst parameter for each modulation profile.
3. Assign the profiles to the desired cable interfaces and upstreams.
After the modulation profiles have been created and assigned to upstreams, the Cisco IOS software automatically
uses the advanced CNR-based version of the Dynamic Upstream Modulation feature on the cable interface
line cards that support it.
437
Configuring Dynamic Upstream Modulation (CNR-Based)
Restriction • The Dynamic Upstream Modulation feature is supported only for DOCSIS 1.0 or DOCSIS 1.1 TDMA-only
modulation profiles. It is not supported for DOCSIS 2.0 mixed-mode or A-TDMA-only mode modulation
profiles.
• Three Step Dynamic Modulation is not supported on the CNR-based version of dynamic upstream
modulation.
• The CNR-based Dynamic Upstream Modulation feature does not support A-TDMA modulation profiles.
However, A-TDMA is supported in the MER (SNR)-based Dynamic Upstream Modulation feature.
To assign the primary and secondary profiles to an upstream, use the following procedure.
Procedure

prompted.
Example:
Router> enable

Example:
Step 3 cable modulation-profile profile {mix | qam-16 | qpsk | Creates the primary modulation profile for use on a DOCSIS
robust-mix} 1.0 or DOCSIS 1.1 TDMA upstream.
Example: Typically, the primary profile is either qam-16 or mix.
Router(config)# cable modulation-profile 3 mix Note Repeat this command to create the secondary
profile for use on a DOCSIS 1.0 or DOCSIS 1.1
TDMA upstream. Typically, the secondary
profile is either robust-mix or qpsk.

with the cable modulation-profile command
by configuring the values for the individual burst
parameters. These parameters, however, should
not be modified unless you are thoroughly

Example:
438
Configuring Proactive Channel Management

Step 5 cable upstream n modulation-profile Assigns a primary modulation profile, and an optional
primary-profile-number secondary-profile-number secondary modulation profile, to the specified upstream
port.
Example:
Router(config-controller)# cable upstream 0
modulation-profile 3 4

Example:

The cable interface line cards that support the advanced spectrum management features can be configured
with the following parameters to fine-tune the operation of proactive channel management on the upstreams
of the cards:
• Priority of the corrective actions to be taken when noise on an upstream exceeds the threshold for its
modulation profile.
• CNR (CNiR) and MER (SNR) threshold and FEC values for the upstream and its two modulation profiles.
• Allowable range of channel widths that can be used if frequency hopping or modulation switching cannot
avoid the upstream problems.
These parameters all have default settings, so you do not need to perform this procedure unless you want to
change these parameters to better match the characteristics of your physical plant.
To configure the parameters, use the following procedure.

You can configure two logical channels on a single physical port of the Cisco CMTS router. When you
configure logical channels, the upstream related commands are categorized into two groups: physical port
level and logical channel level.
Physical Port Level
Physical port level commands use the format of cable upstream n, where n denotes the physical port number.
Logical Channel Level
Logical channel level commands use the format of cable upstream n m , where n denotes the physical port
number, and m denotes the logical channel index number of 0 or 1.
Procedure

prompted.
Example:
Router> enable
439

Example:

Example:
Step 4 us-channel n hop modulation frequency channel-width Specifies the priority of the three types of corrective actions
(modulation, frequency, and channel-width) to be taken
Example:
when the noise for the upstream exceeds the threshold
Router(config-controller)# us-channel 0 hop specified for the current modulation profile. The default
modulation frequency channel-width
priority is frequency, modulation, and channel-width.
Note The channel-width option must always appear
after the frequency option.
Step 5 cable upstream n threshold cnr-profiles threshold1-in-db (Optional) Specifies the CNR (CNiR) threshold and FEC
threshold2-in-db values for the upstream and its two modulation profiles.
Example: Note To bypass both the primary and secondary CNR
Router(config-controller)# cable upstream 2 (CNiR) thresholds, set the first parameter
threshold cnr-profiles 23 14 (threshold1-in-db) to 0. This disallows the
second parameter (threshold2-in-db), enabling
you to bypass both the CNR (CNiR) thresholds.
Step 6 Use one of the following commands: (Optional) Specifies the MER (SNR) threshold and FEC
values for the upstream and its two modulation profiles.
• cable upstream n upstream threshold snr-profiles
threshold1-in-db threshold2-in-db Note You can bypass the primary MER (SNR)
• threshold (threshold1-in-db) by setting it to 0.
• cable upstream n m upstream threshold However, you must enter the second parameter
snr-profiles threshold1-in-db threshold2-in-db (threshold2-in-db).
•
Example:
threshold snr-profiles 23 14
Step 7 cable upstream n threshold hysteresis hysteresis-in-db (Optional) Specifies the hysteresis value to be used in
conjunction with the dynamic modulation upgrade
Example:
thresholds.
threshold hysteresis 3 Note You can bypass the hysteresis threshold by
setting the value to 0.
Step 8 Use one of the following commands: (Optional) Specifies the CNR (CNiR) threshold and FEC
• cable upstream n threshold corr-fec
corrfec-threshold
440
Verifying the Spectrum Management Configuration

• cable upstream n m threshold corr-fec Note You can bypass the corr-fec threshold by
corrfec-threshold setting the value to 0.
Example:
threshold corr-fec 5
Step 9 Use one of the following commands: (Optional) Specifies the CNR (CNiR) threshold and FEC
• cable upstream n threshold uncorr-fec
uncorrfec-threshold Note You can bypass the uncorr-fec threshold by
• cable upstream n m threshold uncorr-fec setting the value to 0.
uncorrfec-threshold
Note For normal plant use, we recommend that the
Example: uncorrectable FEC threshold remain at its
Router(config-controller)# cable upstream 5 default of 1 percent to avoid an unacceptable
threshold uncorr-fec 1
number of errors on the channel.
Step 10 cable upstream n channel-width first-choice-width

[last-choice-width ]
Example:
channel-width 800000 800000

Example:

Follow the steps given below to verify the spectrum management configuration.
Step 1 To check the value of the settings you have entered, use the show running-config command in privileged EXEC mode:
Example:
Router# show running-config
Step 2 To display the configuration for each modulation profile, use the show cable modulation-profile command in privileged
EXEC mode:
Example:
Router# show cable modulation-profile
To display the configuration for a specific modulation profile, add the profile number to the show cable modulation-profile
command in privileged EXEC mode:
Example:
Router# show cable modulation-profile 6
441
Step 3 To display the status and configuration of each upstream, use the show controllers cable upstream command in privileged
EXEC mode. The following example displays information for upstreams 0 on a cable line card:
Example:
Router# show controller cable 8/1/14 upstream 0
Cable8/1/14 Upstream 0 is up
Frequency 19.504 MHz, Channel Width 3.200 MHz, Symbol Rate 2.560 Msps
Modulations (64-QAM) - A-short 64-QAM, A-long 64-QAM, A-ugs 64-QAM
Mapped to shared connector 18 and receiver 56
Spectrum Group 8
MC3Gx60 CNR measurement : 30 dB
US phy MER(SNR)_estimate for good packets - 32.5530 dB
Nominal Input Power Level 0 dBmV, Tx Timing Offset 1547
Ranging Backoff Start 3, Ranging Backoff End 6
US timing offset adjustment type 0, value 0
Ranging Insertion Interval automatic (60 ms)
US throttling off
Tx Backoff Start 3, Tx Backoff End 5
Modulation Profile Group 221
Concatenation is enabled
Fragmentation is enabled
part_id=0x3142, rev_id=0xC0, rev2_id=0x00
nb_agc_thr=0x0000, nb_agc_nom=0x0000
Range Load Reg Size=0x58
Request Load Reg Size=0x0E
Minislot Size in number of Timebase Ticks is = 2
Minislot Size in Symbols = 32
Bandwidth Requests = 0xEE3AF
Piggyback Requests = 0x6A24F
Invalid BW Requests= 0x76
Minislots Requested= 0xC33362
Minislots Granted = 0x158609
Minislot Size in Bytes = 24
Map Advance (Dynamic) : 2581 usecs
Map Count Internal = 330309891
No MAP buffer= 0x0 No Remote MAP buffer= 0x0
Map Counts: Controller 8/1/0 = 1321230158
UCD Counts:
Controller 8/1/0:0 = 336057
Controller 8/1/0:1 = 336057
Controller 8/1/0:2 = 336057
Controller 8/1/0:3 = 336057
UCD procedures on lch 0

UCD ucd-succeeds(5) ucd-shut(0) init-state-err(0)
UCD init-tss-err(0) init-timeout(0) init-start-err(0)
UCD ucd-ccc-time(0) ucd-timeout(0) ucd-tss-err(0)
UCD ucd-state-err(0) ucd-process(0) ucd-retries(0)
UCD stale-tss(0)
ATDMA mode enabled
PHY: us errors 0 us recoveries 0 (enp 0)
MAC PHY TSS: tss error start 0 tss error end 0
MAC PHY Status: bcm3140 status 0 lookout status 0
PHY: TSS late 0 discontinuous 0
PHY: TSS mis-match 0 not-aligned 0
PHY: TSS missed snapshots from phy 0
MAP/UCD Replication Instructions:
Controller 8/1/0 index = 477, bitmap = 0x000F
Dynamic Services Stats:
DSA: 0 REQs 0 RSPs 0 ACKs
0 Successful DSAs 0 DSA Failures
DSC: 0 REQs 0 RSPs 0 ACKs
442
0 Successful DSCs 0 DSC Failures

DSD: 0 REQs 0 RSPs
0 Successful DSDs 0 DSD Failures
Dropped MAC messages: (none)
Step 4 To display the hop period and hop threshold values for each upstream, use the show cable hop command in privileged
EXEC mode:
Example:
Router# show cable hop
Upstream Port Poll Missed Min Missed Hop Hop Corr Uncorr
Port Status Rate Poll Poll Poll Thres Period FEC FEC
(ms) Count Sample Pcnt Pcnt (sec) Errors Errors
Cable3/0/U0 20.800 Mhz 105 0 20 0% 25% 45 1 4
Cable3/0/U1 20.800 Mhz 105 0 48 0% 25% 45 2 19
Cable3/0/U2 23.120 Mhz 105 0 45 0% 25% 45 0 5
Cable3/0/U3 22.832 Mhz 105 0 26 0% 25% 45 0 6
Cable3/0/U4 22.896 Mhz 105 0 43 0% 25% 45 0 7
Cable3/0/U5 23.040 Mhz 105 0 54 0% 25% 45 1 3
Cable4/0/U0 22.896 Mhz 117 0 26 0% 25% 45 0 2
Cable4/0/U1 23.168 Mhz 117 0 87 0% 25% 45 4 2
Cable4/0/U2 22.896 Mhz 117 0 23 0% 25% 45 1 0
Cable4/0/U3 20.800 Mhz 117 0 54 0% 25% 45 0 0
Cable4/0/U4 22.928 Mhz 117 0 22 0% 25% 45 0 1
Cable4/0/U5 22.960 Mhz 117 0 0 ----- 25% 45 0 0
Step 5 To display changes from one state to another, at any time and for any reason, for frequency, modulation, and channel
width, use the history option of the show cable hop command.
Example:
Router# show cable hop c8/1/1 u0 history

C8/1/1 U0 Feb 20 12:21:29 M 142 141 SNR 28>=28 CFEC 0<=3 UnCFEC 0<=1
Feb 20 12:09:08 F 0.000 24.000 Configuration changed
Step 6 To display thresholds for MER (SNR), CNR (CNiR), and FEC, use the threshold option of the show cable hop command.
Example:
Router# show cable hop c8/1/1 u0 threshold
Upstream SNR(dB) CNR(dB) CorrFEC% UncorrFEC% MissedSM%

Port Val Thre1 Thre2 Val Thre1 Thre2 Pcnt Thre Pcnt Thre Pcnt Thre
C8/1/1 u0 33 23 14 60 25 15 0 1 0 2 0 50
Step 7 To display the assignment of each spectrum group, use the show cable spectrum-group command in privileged EXEC
mode:
Example:
Router# show cable spectrum-group
Group Frequency Upstream Weekly Scheduled Power Shared

No. Band Port Availability Level Spectrum
(MHz) From Time: To Time: (dBmV)
443
Monitoring Spectrum Management
1 42.967 [3.20] UC2/0/4:U0 -1 No

1 83.400 [3.20] UC2/0/4:U1 -1 No
1 80.200 [3.20] UC2/0/4:U2 -1 No
1 42.922 [3.20] UC2/0/4:U3 -1 No
1 17.677 [3.20] UC2/0/5:U0 -1 54
1 10.603 [3.20] UC2/0/5:U1 -1 54
In the above example,

• No—Fiber node is not configured
• 54—ID of the fiber node
Step 8 To display the current CNR (CNiR) value for a particular cable modem, use the show cable modem cnr command in
privileged EXEC mode:
Example:
Router# show cable modem 5.100.1.94 cnr
MAC Address IP Address I/F MAC Prim snr/cnr

State Sid (dB)
0018.689c.17b8 5.100.1.94 C7/0/0/U1 online 428 36.12
Monitoring Spectrum Management

You can either use Cisco CLI commands or SNMP to monitor spectrum management activity on the Cisco
CMTS.
See the following sections for more information:
Using CLI Commands

The following commands provide information on the spectrum condition of an upstream:
Command Purpose
Router# show cable hop[cablex/y] Displays the hop period and hop threshold values, as well as the
[upstream usport] FEC error counters, for all upstreams in the router, all upstreams
on one cable interface line card, or a single upstream.
Router# show cable hop [cable Displays the configured and current value of MER (SNR) in dB,
x/y[z]] [upstream n][thresholds] CNR (CNiR) in dB, CorrFEC in percentage, UncorrFEC in
percentage, and missed station maintenance in percentage for a
specified upstream.
444
Using SNMP
Command Purpose
Router# show cable hop history 1. With the show cable hop history command for entire CMTS,
the most recent change of each action is displayed.
2. With the show cable hop history command for a MAC
domain, the most recent three changes of each action are
displayed.
3. With the show cable hop history command for a specific
upstream, the last ten changes of each action are displayed.
Changes are sorted by time with the most recent at the top.
Router# show cable hop [cable Displays hourly, daily, weekly, 30 days running average, and
x/y[z]] [upstream n][summary average since the system was brought up for each specified
upstream.
Displays changes from one state to another, at any time and for
Router# show cable hop [cable
any reason, for frequency, modulation, and channel width.
x/y[z]] [upstream n] [history]
Router# show cable modem Displays information, including MER (SNR) values, for the
[ip-address | interface | registered and unregistered cable modems.
mac-address] [options]
Router# show cable Displays the configuration for all modulation profiles, for a
modulation-profile [num] [initial particular modulation profile, or for a specific burst type for a
| long | reqdata | request | short
| station]
particular modulation profile.
Router# show cable Displays information about the spectrum groups that have been
spectrum-group[groupnum] [detail] configured.
Router# show controllers cable x/y Displays the upstream status, including the current frequency,
upstream n [ip-address | channel width, modulation rate, and spectrum groups.
mac-address] start-freq end-freq
res-freq
Router# show controllers cable x/y Displays the noise levels for a particular cable modem or displays
upstream n spectrum [ip-address the background noise for an entire upstream.
| mac-address] start-freq end-freq
res-freq
Note The show cable flap-list command displays the flap list of the CMTS router, which provides additional
information about whether cable modems on an upstream are experiencing problems, and if so, what type of
problems are occurring. For more information about the cable modem flapping and how to monitor the cable
modem flap list, see the Flap List Troubleshooting for the Cisco CMTS Routers .
Using SNMP
You can use SNMP to monitor the spectrum management activity. The SNMP manager can be a
graphically-based SNMP manager such as CiscoView or the Cable Broadband Troubleshooter (Release 3.0
or later).
445
ccsSNRRequestTable
The CISCO-CABLE-SPECTRUM-MIB has been enhanced to provide this SNMP support using the following
MIB attributes:
ccsSNRRequestTable
The table below lists the attributes in the ccsSNRRequestTable table, which contains the CNR (CNiR)
measurements that are made for individual cable modems on an upstream.
Table 70: ccsSNRRequestTable Attributes
Attribute Type Description
ccsSNRRequestIndex Integer32 Arbitrary index to uniquely identify each table entry.
ccsSNRRequestMacAddr MacAddress MAC address of the remote online cable modem

being reported on.
ccsSNRRequestSNR Integer32 MER (SNR) value, in dB, that has been measured.
This value is 0 when the Operation State is “running.”
ccsSNRRequestOperation CCSRequestOperation Sets the current operation: start, pending, running,

or cancel.
ccsSNRRequestOperState CCSRequestOperState Reports on the current operation state: idle, pending,

running, noError, canceled, notOnLine, invalidMac,
timeOut, fftBusy, fftFailed, others.
ccsSNRRequestStartTime TimeStamp Contains the time when the MER (SNR)

measurement operation starts.
ccsSNRRequestStoppedTime TimeStamp Contains the time when the MER (SNR)

measurement stops.
ccsSNRRequestStatus RowStatus Controls the modification, creation, and deletion of

table entries.
ccsSpectrumRequestTable
The table below lists the attributes for each entry in the ccsSpectrumRequestTable table, which is used to
obtain the spectrum profile for a particular cable modem or to obtain the background MER (SNR) for an entire
upstream.
Table 71: ccsSpectrumRequestTable Attributes
ccsSpectrumRequestIndex Integer32 Arbitrary index to uniquely identify each table

entry.
ccsSpectrumRequestIfIndex InterfaceIndexOrZero Interface identifying the upstream.
ccsSpectrumRequestMacAddr MacAddress MAC address to specify an MER (SNR) value for

a particular cable modem, or 0000.0000.0000 to
indicate background noise for the entire spectrum.
446
ccsSpectrumDataTable
ccsSpectrumRequestUpperFreq CCSFrequency Upper frequency for the frequency range to be

monitored (5000 to 42000 KHz, with a default of
42000 KHz).
ccsSpectrumRequestLowFreq CCSFrequency Lower frequency (in KHz) for the frequency range
to be monitored (5000 to 42000 KHz, with a
default of 5000 KHz).
ccsSpectrumRequestResolution Integer32 Requested resolution to determine how the

frequency range should be sampled (12 to 37000
KHz, with a default of 60 KHz).
ccsSpectrumRequestStartTime TimeStamp Time when the spectrum measurement began.
ccsSpectrumRequestStoppedTime TimeStamp Time when the spectrum measurement finished.
ccsSpectrumRequestOperation CCSRequestOperation Starts a new spectrum management request or

cancels the current one.
ccsSpectrumRequestOperState CCSRequestOperState Provides the operational state of the current

spectrum management request.
ccsSpectrumRequestStatus RowStatus Controls the modification, creation, and deletion

of table entries.
ccsSpectrumDataTable
The table below lists the attributes in each entry of the ccsSpectrumDataTable table, which contains the results
for a spectrum request.
Table 72: ccsSpectrumDataTable Attributes
ccsSpectrumDataFreq CCSMeasuredFrequency Frequency in KHz for which this power measurement

was made.
ccsSpectrumDataPower INTEGER Measured received power for the given frequency (–50
to 50 dBmV).
Note The ccsSpectrumRequestTable and ccsSpectrumDataTable tables provide the same information as that provided
by the show controllers cable upstream spectrum command.
ccsUpSpecMgmtTable
The table below lists the attributes in the ccsUpSpecMgmtTable table, which provides an entry describing
each frequency hop.
447
ccsUpSpecMgmtTable
Table 73: ccsUpSpecMgmtEntry Attributes
ccsUpSpecMgmtHopPriority INTEGER Specifies the priority of frequency,

modulation profile, and channel width in
determining corrective action for
excessive noise on the upstream (default
is frequency, modulation profile, and
channel width).
ccsUpSpecMgmtSnrThres1 Integer32 Specifies the upper MER (SNR) threshold

for modulation profile 1 (5 to 35 dB,
default of 25).
ccsUpSpecMgmtSnrThres2 Integer32 Specifies the upper MER (SNR) threshold

for modulation profile 2 (5 to 35 dB,
default of 13, and must be lower than that
specified for ccsUpSpecMgmtSnrThres1).
ccsUpSpecMgmtFecCorrectThres1 Integer32 Specifies the FEC correctable error

threshold for modulation profile 1 (1 to
20 percent)
ccsUpSpecMgmtFecCorrectThres2 Integer32 Zero (0). Deprecated and no longer used.
ccsUpSpecMgmtFecUnCorrectThres1 Integer32 Specifies the FEC uncorrectable error

20 percent).
ccsUpSpecMgmtFecUnCorrectThres2 Integer32 Deprecated and no longer used.
ccsUpSpecMgmtSnrPollPeriod Integer32 Deprecated and no longer used.
ccsUpSpecMgmtHopCondition INTEGER Reports the condition that triggers a

frequency hop (MER [SNR] value or
percentage of modems going offline).
ccsUpSpecMgmtFromCenterFreq CCSFrequency Provides the center frequency (in KHz)

before the latest frequency hop.
ccsUpSpecMgmtToCenterFreq CCSFrequency Provides the current center frequency (in

KHz) after the latest frequency hop.
ccsUpSpecMgmtFromBandWidth CCSFrequency Provides the channel width (in KHz)

ccsUpSpecMgmtToBandWidth CCSFrequency Provides the current channel width (in

KHz) after the latest frequency hop.
ccsUpSpecMgmtFromModProfile Integer32 Provides the modulation profile number

448
ccsHoppingNotification
ccsUpSpecMgmtToModProfile Integer32 Provides the current modulation profile

number after the latest frequency hop.
ccsUpSpecMgmtSNR Integer32 Provides the current MER (SNR) value

(in dB) for the upstream.
ccsUpSpecMgmtCnrThres1 Integer32 Specifies the upper CNR (CNiR)

35 dB, default of 25).
ccsUpSpecMgmtCnrThres2 Integer32 Specifies the upper CNR (CNiR)

35 dB, default of 13, and must be lower
than that specified for
ccsUpSpecMgmtCnrThres1).
ccsUpSpecMgmtCNR Integer32 Provides the current CNR (CNiR) value

(in dB) for the upstream.
ccsUpSpecMgmtMissedMaintMsgThres Integer32 Provides the frequency hop threshold, as

a percentage of station maintenance
messages that are lost for a spectrum
group.
ccsUpSpecMgmtHopPeriod Integer32 Provide the minimum time, in seconds,

between frequency hops.
ccsHoppingNotification
The table below describes the attributes contained in the notification that is sent after each frequency hop.
Table 74: ccsHoppingNotification Attributes
ccsUpSpecMgmtHopCondition INTEGER Reports the condition that triggers a frequency hop (MER
[SNR] value or percentage of modems going offline).
ccsUpSpecMgmtFromCenterFreq CCSFrequency Provides the center frequency (in KHz) before the latest
frequency hop.
ccsUpSpecMgmtToCenterFreq CCSFrequency Provides the current center frequency (in KHz) after the
latest frequency hop.
ccsUpSpecMgmtFromBandWidth CCSFrequency Provides the channel width (in KHz) before the latest
frequency hop.
ccsUpSpecMgmtToBandWidth CCSFrequency Provides the current channel width (in KHz) after the
ccsUpSpecMgmtFromModProfile Integer32 Provides the modulation profile number before the latest
frequency hop.
449
ccsUpSpecMgmtToModProfile Integer32 Provides the current modulation profile number after the
Spectrum Group and Combiner Group Examples

The following examples help you to determine whether spectrum group and combiner groups are configured
and activated.
Example: Verifying Spectrum Group Creation

To verify that a spectrum group has been created, enter the show cable spectrum-group command:
spectrum-group 1
spectrum-group 2
spectrum-group 3
Example: Time-Scheduled Spectrum Group

If your cable plant has an upstream noise characteristic on a weekly cycle, use time-scheduled spectrum
allocation.
Router(config)# cable spectrum-group 1 time Mon 08:00:00 frequency 21600000
Deletion is performed using the delete keyword:

Router(config)# cable spectrum-group 1 time Mon 18:00:00 delete frequency 21600000
Example: Verifying Spectrum Group Configuration

To verify if spectrum groups have been configured and activated, enter the show cable spectrum-group
command. This command displays each spectrum group, the frequencies assigned to it, the upstream port to
which it has been assigned, whether a schedule exists for it, the currently measured power level, and whether
it is a shared spectrum group.
22:07:46: %SYS-5-CONFIG_I: Configured from console by console

Group Frequency Upstream Weekly Scheduled Power Shared
No. Band Port Availability Level Spectrum
(Mhz) From Time: To Time: (dBmV)
1 5.000-15.000 0 Yes
1 12.000 0 Yes
1 22.000 Cable6/0 U5 7 Yes
2 29.000 Cable6/0 U4 6 No
2 26.000 0 No
3 35.000-41.000 0 No
3 16.000-19.000 Cable6/0 U3 5 No
5* 5.000-10.000 Thu 21:50:00 Thu 21:45:00 0 Yes
450
Example: Determining the Upstream Ports Assigned to a Combiner Group
Example: Determining the Upstream Ports Assigned to a Combiner Group

Following is a sample topology for a CMTS with combiner groups designated A through J. Combiner groups
C and E have multiple upstream ports that should be configured in a shared spectrum group. The other
upstreams should be configured in a nonshared spectrum group.
In this example, ten combiner groups are served with frequency hop tables from three spectrum groups:
Cable3/0
DS +-----+ Upconverter +----- laser group 1
U0 +----- combiner group A
U1 +----- combiner group B
U2 +------combiner group C
U3 +------combiner group C
U4 +----- combiner group D
U5 +------combiner group E
Cable4/0
DS +-----+ Upconverter +----- laser group 2
U0 +------combiner group E
U1 +----- combiner group F
U2 +----- combiner group G
U3 +----- combiner group H
U4 +----- combiner group I
U5 +----- combiner group J
The laser group term refers to the set of fiber nodes that share the same downstream signal. An optical splitter
is often used to create individual feeds per node.
In the downstream direction, two 6-MHz channel slots are assigned. All fiber nodes in combiner groups A
through E should have a channel slot containing the downstream signal from Cable3/0. Combiner groups A
through E are said to belong to laser group 1.
All fiber nodes in combiner groups E through J should have a channel slot containing the downstream signal
from Cable4/0. Combiner groups E through J are said to belong to laser group 2.
Because combiner group E belongs to two laser groups, there should be two different downstream channel
slots for Cable3/0 and Cable4/0.
Example: Combiner Group

The following example enables spectrum management for all upstream ports, where all combiner groups use
the frequency band from 20 to 26 MHz:
CMTS01(config)# cable spectrum-group 1 band 20000000 26000000
CMTS01(config)# cable spectrum-group 2 shared
CMTS01(config)# cable spectrum-group 3 shared
CMTS01(config)# controller upstream-Cable 9/0/0
CMTS01(config-controller)# cable spectrum-group 1
CMTS01(config-controller)# cable upstream 2 spectrum-group 2
CMTS01(config-controller)# exit
CMTS01(config)# controller upstream-Cable 9/0/1
CMTS01(config-controller)# cable spectrum-group 1
A description of the spectrum groups 1 through 3 follows:
451
Example: Combiner Group
• Spectrum group 1—This group is nonshared. Upstream RF domains exist for each member upstream
port.
Upstream Port RF Domain
Cable3/0 U0 combiner group A
Cable3/0 U1 combiner group B
Cable3/0 U4 combiner group D
Cable4/0 U1 combiner group F
Cable4/0 U2 combiner group G
Cable4/0 U3 combiner group H
Cable4/0 U4 combiner group I
Cable4/0 U5 combiner group J
• Spectrum group 2—This group is shared. A single upstream RF domain exists.

Cable3/0 U2 combiner group C
Cable3/0 U3 combiner group C
• Spectrum group 3—This group is shared. A single upstream RF domain exists.

Cable3/0 U5 combiner group E
Cable4/0 U0 combiner group E
For the 20- to 26-MHz band of each RF domain, the spectrum is channelized according to the channel width
settings of each member port. For example, if the ports U2 and U3 of Cable3/0 are set to 3.2 MHz and 1.6
MHz channel widths, respectively, then spectrum group 2 uses the following channelization:
> Channel Width Start Stop Center
> (Mhz) (Mhz) (Mhz) (Mhz)
> 1 3.2 20.0 23.2 21.6
> 2* 1.6 20.0 21.6 20.8
> 3* 1.6 21.6 23.2 22.4
> 4 1.6 23.2 24.8 24.0
Note Channels 2 and 3 are not available when channel 1 is in use.
Because the group is shared, ports U2 and U3 will be assigned channels 1 and 4, respectively, to prevent
overlap.
Note There are no alternate frequency assignments for either port, and bandwidth is wasted from 24.8 to 26.0 MHz.
To create alternate channels, increase the upper boundary from 26.0 to 28.0 MHz.
> Channel Width Start Stop Center

> (Mhz) (Mhz) (Mhz) (Mhz)
> 1 3.2 20.0 23.2 21.6
> 2 3.2 23.2 26.4 24.8
> 3 1.6 20.0 21.6 20.8
> 4 1.6 21.6 23.2 22.4
> 5 1.6 23.2 24.8 24.0
> 6 1.6 24.8 26.4 25.6
452
Example: Other Spectrum Management Configurations
> 7 1.6 26.4 28.0 27.4
Try to reduce the spectrum allocation when it is used with small channel widths. Otherwise, there will be a
large number of upstream channel slots, and the frequency hopping may require several minutes to find a
clean slot.
Example: Other Spectrum Management Configurations

To configure differing spectrum groups, refer to the following examples:
• Use the following example to configure spectrum group 3 with an upstream band of 12,000,000 to
18,000,000 Hz and default power level of 0 dBmV:
Router(config)# cable spectrum-group 3 band 12000000 18000000
• Use the following example to add the upstream band 20,000,000 to 24,000,000 Hz to the list of valid
bands with a change in the power level of 13 dBmV for spectrum group 3:
Router(config)# cable spectrum-group 3 band 20000000 24000000 13
• Use the following example to configure a continuous band between 5,000,004 and 40,000,000 Hz for
scheduled spectrum group 4 with a default power level of 0 dBmV. The band is available to the spectrum
group starting at 12:00 p.m. local time each Monday:
Router(config)# cable spectrum-group 4 time Monday 12:00:00 band 5000004 40000000
• Use the following example to add the upstream frequency 9,500,000 Hz to the list of valid frequencies
and change the nominal power level to 5 dBmV. The spectrum manager adjusts frequencies and power
levels on this group at 2:00 a.m. local time each day:
Router(config)# cable spectrum-group 3 time 02:00:00 frequency 9500000 5
• Use the following example to configure the minimum period before which a frequency hop can occur
in seconds:
Router(config)# cable spectrum-group 3 hop period 800
• Use the following example to configure the threshold value (expressed as a percentage) of the number
of “offline” modems identified before the router initiates an automatic frequency hop:
Router(config)# cable spectrum-group 3 hop threshold 40
• Use the following example to configure a particular spectrum group as a shared RF spectrum group.
Specifying a given spectrum group as “shared” tells the router that you want to be sure that upstream
frequencies assigned to upstream ports are not assigned to additional upstream ports:
Router(config)# cable spectrum-group 3 shared
• Use the following example to remove a specified spectrum group from your configuration:
Router(config)# no cable spectrum-group 3
453
Dynamic Upstream Modulation Examples
Dynamic Upstream Modulation Examples

The following examples describe how to display modulation profile information with the show cable
modulation-profile command and to define a modulation profile with the cable modulation-profile command.
Verifying Your Settings
Step 1 To check the value of the settings you have entered, enter the show running-config command in privileged EXEC mode:
Example:
To review changes you make to the configuration, use the show startup-config command in privileged EXEC mode to
display the information stored in NVRAM.
Step 2 To display modulation profile group information, use the show cable modulation-profile command in privileged EXEC
mode:
Example:
Router# show cable modulation-profile[profile][iuc-code]
This command uses the following syntax:

• profile—(Optional) Profile number. Valid values are from 1 to 8.
• iuc-code—(Optional) Internal usage code.
Valid options are:
• initial—Initial ranging burst
• long—Long grant burst
• request—Request burst
• short—Short grant burst
• station—Station ranging burst
Example: Modulation Profiles

The Cisco CMTS has one preconfigured modulation profile resident in memory, which defines a typical
profile for QPSK modulation. To use the Dynamic Upstream Modulation feature, a second profile must be
created that is unique from the first profile, and typically provides a higher, more robust modulation scheme.
The following example is a modulation profile for QAM-16, in which the initial, request, and station
maintenance messages are sent as QPSK, and the short and long data packets are sent as QAM-16. The
QAM-16 modulation is more bandwidth-efficient than QPSK, but QPSK is more robust than QAM-16.
454
Example: Modulation Profiles
Note The upstream request and station maintenance messages use less time on the cable network when configured
in QPSK for symbol rates of 640K, 1280K, and 2560K symbols/sec. Thus, these messages are actually more
efficient when used in QPSK mode and they ensure a more reliable modem connection. The upstream initial
maintenance message takes exactly the same amount of time on the cable network, no matter how it is
configured. Modems connect more quickly and experience fewer cycles of power adjustment during initial
maintenance if the system is set for QPSK.

Router(config)# cable modulation-profile 2 request 0 16 1 8 qpsk scrambler 152 no-diff 64
fixed uw16
Router(config)# cable modulation-profile 2 initial 5 34 0 48 qpsk scrambler 152 no-diff 128
fixed uw16
Router(config)# cable modulation-profile 2 station 5 34 0 48 qpsk scrambler 152 no-diff 128
fixed uw16
Router(config)# cable modulation-profile 2 short 6 75 6 8 16qam scrambler 152 no-diff 72
fixed uw16
Router(config)# cable modulation-profile 2 long 8 220 0 8 16qam scrambler 152 no-diff 160
fixed uw16
In the following example, all message types are carried with QAM-16 modulation. Although QAM-16
modulation offers a consistent modulation scheme for all five types of messages, the added length of the
QAM-16 preamble offsets the increased bandwidth efficiency of the MAC data message for the station
maintenance messages and bandwidth request messages.
Router(config)# cable modulation-profile 2 request 0 16 1 8 16qam scrambler 152 no-diff 128
fixed uw16
Router(config)# cable modulation-profile 2 initial 5 34 0 48 16qam scrambler 152 no-diff
256 fixed uw16
Router(config)# cable modulation-profile 2 station 5 34 0 48 16qam scrambler 152 no-diff
256 fixed uw16
Router(config)# cable modulation-profile 2 short 5 75 6 8 16qam scrambler 152 no-diff 144
fixed uw16
Router(config)# cable modulation-profile 2 long 8 220 0 8 16qam scrambler 152 no-diff 160
fixed uw16
Note When using DOCSIS concatenation with a 16-QAM or mixed symbol rate, configure the CMTS for Unique
Word 16 (“uw16”) in the preamble for both short and long data burst profiles.
Add the cable upstream port-number modulation-profile primary profile-number secondary profile-number
command to the appropriate interfaces. In this example, modulation profile 2 is for QAM-16 modulation and
profile 1 is for QPSK modulation.
Router(config)# controller upstream-Cable 6/0/0
Router(config-controller)# cable upstream 0 modulation-profile 2 1
455
Example: Input Power Level
Example: Input Power Level

In the following example, the modem transmit power at 24.8 MHz is adjusted upstream by 1 dBmV and the
modem transmit power at 28.0 MHz is adjusted upstream by 2 dBmV.
CMTS01(config)# cable spectrum-group 1 frequency 21600000
CMTS01(config)# cable spectrum-group 1 frequency 24800000 1
CMTS01(config)# cable spectrum-group 1 frequency 28000000 2
Advanced Spectrum Management Configuration Examples

This section provides the following typical configurations:
Example: Advanced Spectrum Management for the Cisco cBR Series Routers
This section provides an excerpt from a typical configuration example for a Cisco cBR Series router using a
cable interface line card. This configuration does the following:
• Configures four spectrum groups with a hop period of 30 seconds.
• Creates a QPSK modulation profile and assigns it to four upstreams on the Cisco cable interface line
card in slot 6/1/0.
• Assigns a spectrum group to each of the four upstreams.
• Configures each upstream for the default CNR (CNiR) and FEC thresholds.
cable modulation-profile 21 qpsk

cable bundle 1
cable downstream annex B
cable downstream modulation 256qam
cable downstream interleave-depth 32
! upstream 0
cable upstream 0 spectrum-group 1
cable upstream 0 modulation-profile 21
cable upstream 0 threshold cnr-profiles 16 0
cable upstream 0 threshold Corr-Fec 3
cable upstream 0 threshold Uncorr-Fec 1
no cable upstream 0 shutdown ! upstream 1
no cable upstream 3 shutdown
456
The following sections provide references related to Spectrum Management and Advanced Spectrum
Management for the Cisco CMTS routers.
Related Documents
CMTS Command Reference Cisco Broadband Cable Command Reference Guide.
Standards and RFCs
Standards Title




MIBs
MIBs MIBs Link
CISCO-CABLE-SPECTRUM-MIB To locate and download MIBs for selected platforms, Cisco IOS releases,
and feature sets, use Cisco MIB Locator found at the following URL:
https://www.cisco.com/go/mibs
Description Link
The Cisco Support and Documentation website https://www.cisco.com/cisco/web/support/index.html

provides online resources to download documentation,
software, and tools. Use these resources to install and
configure the software and to troubleshoot and resolve
technical issues with Cisco products and technologies.
Access to most tools on the Cisco Support and
Documentation website requires a Cisco.com user ID
and password.
457
Feature Information for Spectrum Management and Advanced Spectrum Management
Feature Information for Spectrum Management and Advanced

Spectrum Management
Spectrum Management and Cisco IOS XE Fuji 16.7.1 This feature was integrated on the
Advanced Spectrum Management Cisco cBR Series Converged
Broadband Routers.
458
CHAPTER 25
Upstream Scheduler Mode
This document describes how to configure optional upstream (US) scheduler modes.
With this feature, you can select Unsolicited Grant Services (UGS), Real Time Polling Service (rtPS) or
Non-Real Time Polling Service (nrtPS) scheduling types, as well as packet-based or Time Division Multiplex
(TDM) based scheduling. Low latency queuing (LLQ) emulates a packet-mode-like operation over the TDM
infrastructure of DOCSIS. As such, the feature provides the typical trade-off between packets and TDM. With
LLQ, you have more flexibility in defining service parameters for UGS, rtPS or nrtPS, but with no guarantee
(other than statistical distribution) regarding parameters such as delay and jitter.
• Restrictions for Upstream Scheduler Mode, on page 461
• Information About Upstream Scheduler Mode for the Cisco CMTS Routers, on page 461
• How to Configure Upstream Scheduler Modes, on page 461
• Feature Information for Upstream Scheduler Mode, on page 463

459
Digital PICs:

Module:

Modules:
line card reload.
460
Restrictions for Upstream Scheduler Mode
Restrictions for Upstream Scheduler Mode

• To ensure proper operation, Interface-based Admission Control must be enabled. When the LLQ option
is enabled, it is possible for the upstream path to be filled with so many calls that it becomes unusable,
making voice quality unacceptable. Interface-based admission control must be used to limit the number
of calls to ensure acceptable voice quality, as well as to ensure traffic other than voice traffic.
• Even if Interface-based admission control is not enabled, the default (DOCSIS)scheduling mode blocks
traffic after a certain number of calls.
• UGS with Activity Detection (UGS-AD) is not supported by the LLQ scheduler mode but remains
supported by the default DOCSIS scheduler mode.
Information About Upstream Scheduler Mode for the Cisco

CMTS Routers
With UGS, a service flow is created that enables a cable modem to transmit fixed-size bursts of data at a
guaranteed rate and with a guaranteed level of jitter by providing periodic transmission opportunities to the
cable modem for fixed-sized frames. This kind of service flow is particularly suitable for VoIP applications.
With rtPS, a service flow is created that provides a periodic opportunity for a cable modem to request permission
to transmit data by polling a single cable modem for a bandwidth request, rather than all the cable modems.
This satisfies applications that have a requirement for real-time data transmission, and enables the cable
modem to transmit data bursts of varying length. This kind of service flow is particularly suitable for MPEG
VoIP.
The rtPS requests, by default, are internally treated as priority 7—the highest priority for all Best Effort traffic.
This high priority reduces the latency of rtPS traffic under congestion.
With nrtPS, a service flow is created that provides a periodic opportunity for a cable modem to request
permission to transmit data by polling a single cable modem for a bandwidth request, rather than all the cable
modems. The data bursts may be of varying length. This kind of service flow is particularly suitable for
non-interactive services such as file transfers.
How to Configure Upstream Scheduler Modes

Procedure

Router> enable

Example:
461
How to Configure Upstream Scheduler Modes

Step 3 Use one the following commands: Enters interface configuration mode for the specified cable
interface.
• interface cable slot/subslot/port
• interface cable slot/port
Example:
Step 4 cable upstream n scheduling type ugs mode [llq Enables LLQ-type (packet-based) scheduling for UGS
|docsis] services.
Example: Note Any combination of ugs, rtps, nrtps, llq, and
Router(config-if)# cable upstream 4 scheduling type docsis is allowed. The only default value is
ugs mode llq docsis .
Step 5 cable upstream n scheduling type rtps mode [llq Enables standard DOCSIS (TDM-based) scheduling for
|docsis] rtPS services.
Example: Note Any combination of ugs, rtps, nrtps, llq, and
Router(config-if)# cable upstream 4 scheduling type docsis is allowed. The only default value is
rtps mode docsis docsis .

EXEC mode.
Example:
What to do next
To confirm whether the scheduler is operating in DOCSIS mode, use the show interface cable mac-scheduler
command.
Router# show interface cable 7/0/1 mac-scheduler 0
DOCSIS 1.1 MAC scheduler for Cable7/0/1/U0 : rate 30720000
wfq:None
us_balance:OFF
fairness:OFF
Queue[Rng Polls] flows 0
Queue[CIR Grants] flows 0
Queue[BE(07) Grants] flows 0
Req Slots 2601578997, Req/Data Slots 4484512
Init Mtn Slots 38265829, Stn Mtn Slots 78753
Short Grant Slots 0, Long Grant Slots 0
Adv Phy Short Grant Slots 412, Adv Phy Long Grant Slots 5519087
Adv Phy UGS Grant Slots 0
Avg upstream channel utilization : 1%
Avg percent contention slots : 98%
Avg percent initial ranging slots : 1%
462
Avg percent minislots lost on late MAPs : 0%
MAP TSS: lch_state 9, init_retries 0

late_initial_maps 0, late_ucd_maps 0
mac-phy tss errors 0, missed ccc 0
The following sections provide references related to the Cisco CMTS routers.
Related Documents
Cisco CMTS command reference Cisco CMTS Cable Command Reference

http://www.cisco.com/c/en/us/td/docs/cable/cmts/cmd_ref/b_cmts_cable_cmd_ref.h
Standards
Standard Title
DOCSIS Data-Over-Cable Service Interface Specifications, DOCSIS 2.0, Radio Frequency Interface
Specification, CM-SP-RFIv2.0-I08-050408
Description Link

Feature Information for Upstream Scheduler Mode

463
Feature Information for Upstream Scheduler Mode
Table 76: Feature Information for Upstream Scheduler Mode
Upstream Scheduler Mode Cisco IOS XE Fuji 16.7.1 This feature was integrated on the
Broadband Routers.
464
CHAPTER 26
Generic Routing Encapsulation
This document describes the Generic Routing Encapsulation (GRE) feature. This feature is a tunneling protocol
that enables the encapsulation of a wide variety of protocol packet types inside IP tunnels, creating a virtual
point-to-point link to Cisco routers at remote points over an IP internetwork.
• Restrictions for Implementing Tunnels, on page 467
• Restrictions for GRE IPv6 Tunnels, on page 468
• Information About Implementing Tunnels, on page 468
• Information About IPv6 over IPv4 GRE Tunnels, on page 470
• Information About GRE IPv6 Tunnels, on page 472
• How to Implement Tunnels, on page 472
• Configuration Examples for Implementing Tunnels, on page 479
• How to Configure IPv6 over IPv4 GRE Tunnels, on page 482
• Configuration Examples for IPv6 over IPv4 GRE Tunnels, on page 483
• How to Configure GRE IPv6 Tunnels, on page 484
• Configuration Examples for GRE IPv6 Tunnels, on page 486
• Feature Information for Generic Routing Encapsulation , on page 488

465
Digital PICs:

Module:

Modules:
466
Restrictions for Implementing Tunnels
line card reload.
Restrictions for Implementing Tunnels

• It is important to allow the tunnel protocol to pass through a firewall and access control list (ACL) check.
• Multiple point-to-point tunnels can saturate the physical link with routing information if the bandwidth
is not configured correctly on a tunnel interface.
• A tunnel looks like a single hop link, and routing protocols may prefer a tunnel over a multihop physical
path. The tunnel, despite looking like a single hop link, may traverse a slower path than a multihop link.
A tunnel is as robust and fast, or as unreliable and slow, as the links that it actually traverses. Routing
protocols that make their decisions based only on hop counts will often prefer a tunnel over a set of
physical links. A tunnel might appear to be a one-hop, point-to-point link and have the lowest-cost path,
but the tunnel may actually cost more in terms of latency when compared to an alternative physical
topology. For example, in the topology shown in the figure below, packets from Host 1 will appear to
travel across networks w, t, and z to get to Host 2 instead of taking the path w, x, y, and z because the
tunnel hop count appears shorter. In fact, the packets going through the tunnel will still be traveling
across Router A, B, and C, but they must also travel to Router D before coming back to Router C.
Figure 19: Tunnel Precautions: Hop Counts
• A tunnel may have a recursive routing problem if routing is not configured accurately. The best path to
a tunnel destination is via the tunnel itself; therefore recursive routing causes the tunnel interface to flap.
To avoid recursive routing problems, keep the control-plane routing separate from the tunnel routing by
using the following methods:
• Use a different autonomous system number or tag.
• Use a different routing protocol.
• Ensure that static routes are used to override the first hop (watch for routing loops).
467
Restrictions for GRE IPv6 Tunnels
The following error is displayed when there is recursive routing to a tunnel destination:
%TUN-RECURDOWN Interface Tunnel 0
temporarily disabled due to recursive routing
Restrictions for GRE IPv6 Tunnels

• GRE tunnel keepalive packets are not supported.
• Multipoint GRE (mGRE) IPv6 tunneling is not supported.
Information About Implementing Tunnels

Tunneling Versus Encapsulation
To understand how tunnels work, you must be able to distinguish between concepts of encapsulation and
tunneling. Encapsulation is the process of adding headers to data at each layer of a particular protocol stack.
The Open Systems Interconnection (OSI) reference model describes the functions of a network. To send a
data packet from one host (for example, a PC) to another on a network, encapsulation is used to add a header
in front of the data packet at each layer of the protocol stack in descending order. The header must contain a
data field that indicates the type of data encapsulated at the layer immediately above the current layer. As the
packet ascends the protocol stack on the receiving side of the network, each encapsulation header is removed
in reverse order.
Tunneling encapsulates data packets from one protocol within a different protocol and transports the packets
on a foreign network. Unlike encapsulation, tunneling allows a lower-layer protocol and a same-layer protocol
to be carried through the tunnel. A tunnel interface is a virtual (or logical) interface. Tunneling consists of
three main components:
• Passenger protocol—The protocol that you are encapsulating. For example, IPv4 and IPv6 protocols.
• Carrier protocol—The protocol that encapsulates. For example, generic routing encapsulation (GRE)
and Multiprotocol Label Switching (MPLS).
• Transport protocol--The protocol that carries the encapsulated protocol. The main transport protocol is
IP.
Tunnel ToS
Tunnel type of service (ToS) allows you to tunnel network traffic and group all packets in the same ToS byte
value. The ToS byte values and Time-to-Live (TTL) hop-count value can be set in the encapsulating IP header
of tunnel packets for an IP tunnel interface on a router. Tunnel ToS feature is supported for Cisco Express
Forwarding (formerly known as CEF), fast switching, and process switching.
The ToS and TTL byte values are defined in RFC 791. RFC 2474, and RFC 2780 obsolete the use of the ToS
byte as defined in RFC 791. RFC 791 specifies that bits 6 and 7 of the ToS byte (the first two least significant
bits) are reserved for future use and should be set to 0.
468
Path MTU Discovery
Path MTU Discovery

Path MTU Discovery (PMTUD) can be enabled on a GRE or IP-in-IP tunnel interface. When PMTUD (RFC
1191) is enabled on a tunnel interface, the router performs PMTUD processing for the GRE (or IP-in-IP)
tunnel IP packets. The router always performs PMTUD processing on the original data IP packets that enter
the tunnel. When PMTUD is enabled, packet fragmentation is not permitted for packets that traverse the tunnel
because the Don’t Fragment (DF) bit is set on all the packets. If a packet that enters the tunnel encounters a
link with a smaller MTU, the packet is dropped and an Internet Control Message Protocol (ICMP) message
is sent back to the sender of the packet. This message indicates that fragmentation was required (but not
permitted) and provides the MTU of the link that caused the packet to be dropped.
Note PMTUD on a tunnel interface requires that the tunnel endpoint be able to receive ICMP messages generated
by routers in the path of the tunnel. Ensure that ICMP messages can be received before using PMTUD over
firewall connections.
Use the tunnel path-mtu-discovery command to enable PMTUD for the tunnel packets and use the show
interfaces tunnel command to verify the tunnel PMTUD parameters. PMTUD works only on GRE and
IP-in-IP tunnel interfaces.
QoS Options for Tunnels

A tunnel interface supports various quality of service (QoS) features as a physical interface. QoS provides a
way to ensure that mission-critical traffic has an acceptable level of performance. QoS options for tunnels
include support for applying generic traffic shaping (GTS) directly on the tunnel interface and support for
class-based shaping using the modular QoS CLI (MQC). Tunnel interfaces also support class-based policing,
but they do not support committed access rate (CAR).
GRE tunnels allow the router to copy the IP precedence bit values of the ToS byte to the tunnel or the GRE
IP header that encapsulates the inner packet. Intermediate routers between the tunnel endpoints can use the
IP precedence values to classify packets for QoS features such as policy routing, weighted fair queueing
(WFQ), and weighted random early detection (WRED).
When packets are encapsulated by tunnel or encryption headers, QoS features are unable to examine the
original packet headers and correctly classify the packets. Packets that travel across the same tunnel have the
same tunnel headers, so the packets are treated identically if the physical interface is congested. Tunnel packets
can, however, be classified before tunneling and encryption can occur when a user applies the QoS preclassify
feature on the tunnel interface or on the crypto map.
Note Class-based WFQ (CBWFQ) inside class-based shaping is not supported on a multipoint interface.
For examples of how to implement some QoS features on a tunnel interface, see the section “Configuring
QoS Options on Tunnel Interfaces Examples, on page 480”.
469
Information About IPv6 over IPv4 GRE Tunnels
Information About IPv6 over IPv4 GRE Tunnels

Overlay Tunnels for IPv6
Overlay tunneling encapsulates IPv6 packets in IPv4 packets for delivery across an IPv4 infrastructure (a core
network or the figure below). By using overlay tunnels, you can communicate with isolated IPv6 networks
without upgrading the IPv4 infrastructure between them. Overlay tunnels can be configured between border
devices or between a border device and a host; however, both tunnel endpoints must support both the IPv4
and IPv6 protocol stacks. IPv6 supports the following types of overlay tunneling mechanisms:
• Manual
• Generic routing encapsulation (GRE)
• IPv4-compatible
• 6to4
• Intrasite Automatic Tunnel Addressing Protocol (ISATAP)
Figure 20: Overlay Tunnels
Note Overlay tunnels reduce the maximum transmission unit (MTU) of an interface by 20 octets (assuming that
the basic IPv4 packet header does not contain optional fields). A network that uses overlay tunnels is difficult
to troubleshoot. Therefore, overlay tunnels that connect isolated IPv6 networks should not be considered a
final IPv6 network architecture. The use of overlay tunnels should be considered as a transition technique
toward a network that supports both the IPv4 and IPv6 protocol stacks or just the IPv6 protocol stack.
Use the table below to help you determine which type of tunnel that you want to configure to carry IPv6
packets over an IPv4 network.
Table 78: Suggested Usage of Tunnel Types to Carry IPv6 Packets over an IPv4 Network
Tunneling Type Suggested Usage Usage Notes
Manual Simple point-to-point tunnels that can be used Can carry IPv6 packets only.
within a site or between sites.
470
GRE IPv4 Tunnel Support for IPv6 Traffic
Tunneling Type Suggested Usage Usage Notes
GRE- and IPv4- Simple point-to-point tunnels that can be used Can carry IPv6, Connectionless
compatible within a site or between sites. Network Service (CLNS), and many
other types of packets.
IPv4- compatible Point-to-multipoint tunnels. Uses the ::/96 prefix. We do not

recommend using this tunnel type.
6to4 Point-to-multipoint tunnels that can be used Sites use addresses from the 2002::/16
to connect isolated IPv6 sites. prefix.
6RD IPv6 service is provided to customers over an Prefixes can be from the SP’s own
IPv4 network by using encapsulation of IPv6 address block.
in IPv4.
ISATAP Point-to-multipoint tunnels that can be used Sites can use any IPv6 unicast
to connect systems within a site. addresses.
Individual tunnel types are discussed in detail in this document. We recommend that you review and understand
the information about the specific tunnel type that you want to implement. When you are familiar with the
type of tunnel you need, see the table below for a summary of the tunnel configuration parameters that you
may find useful.
Table 79: Tunnel Configuration Parameters by Tunneling Type
Tunneling Type Tunnel Configuration Parameter
Tunnel Mode Tunnel Source Tunnel Interface Prefix or

Destination Address
Manual ipv6ip An IPv4 An IPv4 address. An IPv6 address.

address, or
GRE/IPv4 gre ip a reference An IPv4 address. An IPv6 address.
to an
IPv4- compatible ipv6ip auto-tunnel interface on Not required. These Not required. The interface address
are all is generated as ::tunnel-source/96.
which IPv4
point-to-multipoint
6to4 ipv6ip 6to4 is An IPv6 address. The prefix must
tunneling types. The
configured. embed the tunnel source IPv4
IPv4 destination
address is address.
calculated, on a
6RD ipv6ip 6rd per-packet basis, An IPv6 address.
ISATAP ipv6ip isatap from the IPv6 An IPv6 prefix in modified eui-64
destination. format. The IPv6 address is
generated from the prefix and the
tunnel source IPv4 address.
GRE IPv4 Tunnel Support for IPv6 Traffic

IPv6 traffic can be carried over IPv4 GRE tunnels using the standard GRE tunneling technique that is designed
to provide the services to implement any standard point-to-point encapsulation scheme. As in IPv6 manually
471
Information About GRE IPv6 Tunnels
configured tunnels, GRE tunnels are links between two points, with a separate tunnel for each link. The tunnels
are not tied to a specific passenger or transport protocol but, in this case, carry IPv6 as the passenger protocol
with the GRE as the carrier protocol and IPv4 or IPv6 as the transport protocol.
The primary use of GRE tunnels is for stable connections that require regular secure communication between
two edge devices or between an edge device and an end system. The edge devices and the end systems must
be dual-stack implementations.
Information About GRE IPv6 Tunnels

Overview of GRE IPv6 Tunnels
The GRE IPv6 Tunnels feature enables the delivery of packets from other protocols through an IPv6 network
and allows the routing of IPv6 packets between private networks across public networks with globally routed
IPv6 addresses.
For point-to-point GRE tunnels, each tunnel interface requires a tunnel source IPv6 address and a tunnel
destination IPv6 address when being configured. All packets are encapsulated with an outer IPv6 header and
a GRE header.
How to Implement Tunnels

Determining the Tunnel Type
Before configuring a tunnel, you must determine the type of tunnel you want to create.
SUMMARY STEPS
1. Determine the passenger protocol. A passenger protocol is the protocol that you are encapsulating.
2. Determine the tunnel mode command keyword, if appropriate.
DETAILED STEPS
Step 1 Determine the passenger protocol. A passenger protocol is the protocol that you are encapsulating.
Step 2 Determine the tunnel mode command keyword, if appropriate.
The table below shows how to determine the appropriate keyword to be used with the tunnel mode command.
Table 80: Determining the tunnel mode Command Keyword
Keyword Purpose
dvmrp Use the dvmrp keyword to specify that the Distance Vector Multicast Routing Protocol
encapsulation will be used.
gre ip Use the gre and ip keywords to specify that GRE encapsulation over IP will be used.
472
Configuring an IPv4 GRE Tunnel
Keyword Purpose
gre ipv6 Use the gre and ipv6 keywords to specify that GRE encapsulation over IPv6 will be used.
ipip [decapsulate-any] Use the ipip keyword to specify that IP-in-IP encapsulation will be used. The optional
decapsulate-any keyword terminates any number of IP-in-IP tunnels at one tunnel interface.
Note that this tunnel will not carry any outbound traffic; however, any number of remote
tunnel endpoints can use a tunnel configured as their destination.
ipv6 Use the ipv6 keyword to specify that generic packet tunneling in IPv6 will be used.
ipv6ip Use the ipv6ip keyword to specify that IPv6 will be used as the passenger protocol and IPv4
as both the carrier (encapsulation) and transport protocol. When additional keywords are not
used, manual IPv6 tunnels are configured. Additional keywords can be used to specify
IPv4-compatible, 6to4, or ISATAP tunnels.
mpls Use the mpls keyword to specify that MPLS will be used for configuring traffic engineering
(TE) tunnels.
Configuring an IPv4 GRE Tunnel

Perform this task to configure a GRE tunnel. A tunnel interface is used to pass protocol traffic across a network
that does not normally support the protocol. To build a tunnel, you must define a tunnel interface on each of
the two routers, and the tunnel interfaces must reference each other. At each router, the tunnel interface must
be configured with a Layer 3 address. The tunnel endpoints, tunnel source, and tunnel destination must be
defined, and the type of tunnel must be selected. Optional steps can be performed to customize the tunnel.
Remember to configure the router at each end of the tunnel. If only one side of a tunnel is configured, the
tunnel interface may still come up and stay up (unless keepalive is configured), but packets going into the
tunnel will be dropped.
GRE Tunnel Keepalive

Keepalive packets can be configured to be sent over IP-encapsulated GRE tunnels. You can specify the rate
at which keepalives are sent and the number of times that a device will continue to send keepalive packets
without a response before the interface becomes inactive. GRE keepalive packets may be sent from both sides
of a tunnel or from just one side.
Before you begin

Ensure that the physical interface to be used as the tunnel source in this task is up and configured with the
appropriate IP address. For hardware technical descriptions and information about installing interfaces, see
the hardware installation and configuration publication for your product.
Procedure

473
GRE Tunnel Keepalive

Router> enable

Example:
Step 3 interface type number Specifies the interface type and number, and enters
interface configuration mode.
Example:
Router(config)# interface tunnel 0 • To configure a tunnel, use tunnel for the type
argument.
Step 4 bandwidth kb/s Sets the current bandwidth value for an interface and
communicates it to higher-level protocols.
Example:
Router(config-if)# bandwidth 1000 • Specifies the tunnel bandwidth to be used to transmit
packets.
• Use the kb/s argument to set the bandwidth, in kilobits
per second (kb/s).
Note This is only a routing parameter; it does not

affect the physical interface. The default
bandwidth setting on a tunnel interface is 9.6
kb/s. You should set the bandwidth on a tunnel
to an appropriate value.
Step 5 keepalive [period [retries]] (Optional) Specifies the number of times the device will
continue to send keepalive packets without response before
Example:
bringing the tunnel interface protocol down.
Router(config-if)# keepalive 3 7
• GRE keepalive packets may be configured either on
only one side of the tunnel or on both.
• If GRE keepalive is configured on both sides of the
tunnel, the period and retries arguments can be
different at each side of the link.
Note This command is supported only on GRE

point-to-point tunnels.
Note The GRE tunnel keepalive feature should not

be configured on a VRF tunnel. This
combination of features is not supported.
Step 6 tunnel source {ip-address | interface-type Configures the tunnel source.

interface-number}
Note The tunnel source IP address and destination
Example: IP addresses must be defined on two separate
Router(config-if)# tunnel source devices.
TenGigabitEthernet 4/1/0
474
What to Do Next

Step 7 tunnel destination {hostname | ip-address} Configures the tunnel destination.
Example: Note The tunnel source and destination IP addresses
must be defined on two separate devices.
Router(config-if)# tunnel destination 10.0.2.1
Step 8 tunnel key key-number (Optional) Enables an ID key for a tunnel interface.
Example: Note This command is supported only on GRE tunnel
Router(config-if)# tunnel key 1000 interfaces. We do not recommend relying on
this key for security purposes.
Step 9 tunnel mode gre { ip | multipoint} Specifies the encapsulation protocol to be used in the
tunnel.
Example:
Device(config-if)# tunnel mode gre ip
Step 10 ip mtu bytes (Optional) Sets the MTU size of IP packets sent on an
interface.
Example:
Device(config-if)# ip mtu 1400 • If an IP packet exceeds the MTU set for the interface,
the Cisco software will fragment it unless the DF bit
is set.
• All devices on a physical medium must have the same
protocol MTU in order to operate.
• For IPv6 packets, use the ipv6 mtu command.
Note If the tunnel path-mtu-discovery command is

enabled do not configure this command.
Step 11 ip tcp mss mss-value (Optional) Specifies the maximum segment size (MSS)
for TCP connections that originate or terminate on a router.
Example:
Device(config-if)# ip tcp mss 250
Step 12 tunnel path-mtu-discovery [age-timer {aging-mins | (Optional) Enables PMTUD on a GRE or IP-in-IP tunnel
infinite}] interface.
Example: • When PMTUD is enabled on a tunnel interface,
Device(config-if)# tunnel path-mtu-discovery PMTUD will operate for GRE IP tunnel packets to
minimize fragmentation in the path between the tunnel
endpoints.

EXEC mode.
Example:
Device(config-if)# end
What to Do Next
Proceed to the “Verifying Tunnel Configuration and Operation” section.
475
Configuring 6to4 Tunnels
Configuring 6to4 Tunnels

Before you begin
With 6to4 tunnels, the tunnel destination is determined by the border-router IPv4 address, which is concatenated
to the prefix 2002::/16 in the format 2002:border-router-IPv4-address ::/48. The border router at each end of
a 6to4 tunnel must support both the IPv4 and IPv6 protocol stacks.
Note The configuration of only one IPv4-compatible tunnel and one 6to4 IPv6 tunnel is supported on a router. If
you choose to configure both of these tunnel types on the same router, Cisco recommends that they not share
the same tunnel source.
A 6to4 tunnel and an IPv4-compatible tunnel cannot share the same interface because both of them are NBMA
“point-to-multipoint” access links, and only the tunnel source can be used to reorder the packets from a
multiplexed packet stream into a single packet stream for an incoming interface. When a packet with an IPv4
protocol type of 41 arrives on an interface, the packet is mapped to an IPv6 tunnel interface on the basis of
the IPv4 address. However, if both the 6to4 tunnel and the IPv4-compatible tunnel share the same source
interface, the router cannot determine the IPv6 tunnel interface to which it should assign the incoming packet.
Manually configured IPv6 tunnels can share the same source interface because a manual tunnel is a
“point-to-point” link, and both IPv4 source and the IPv4 destination of the tunnel are defined.
Procedure

Router> enable

Example:
Step 3 interface tunnel tunnel-number Specifies a tunnel interface and number and enters interface
configuration mode.
Example:
Router(config)# interface tunnel 0
Step 4 ipv6 address ipv6-prefix/prefix-length [eui-64] Specifies the IPv6 address assigned to the interface and
enables IPv6 processing on the interface.
Example:
• The 32 bits following the initial 2002::/16 prefix
Router(config-if)# ipv6 address correspond to an IPv4 address assigned to the tunnel
2002:c0a8:6301:1::1/64 source.
Note See the "Configuring Basic Connectivity for

IPv6" module for more information on
configuring IPv6 addresses.
476
What to Do Next

Step 5 tunnel source {ip-address | interface-type Specifies the source IPv4 address or the source interface
interface-number} type and number for the tunnel interface.
Example: Note The interface type and number specified in the
Router(config-if)# tunnel source TenGigabitEthernet tunnel source command must be configured
4/1/0 with an IPv4 address.
Step 6 tunnel mode ipv6ip 6to4 Specifies an IPv6 overlay tunnel using a 6to4 address.
Example:
Router(config-if)# tunnel mode ipv6ip 6to4
Step 7 exit Exits interface configuration mode and returns to global

configuration mode.
Example:
Step 8 ipv6 route ipv6-prefix / prefix-length tunnel Configures a static route to the specified tunnel interface.
tunnel-number
Note When configuring a 6to4 overlay tunnel, you
Example: must configure a static route for the IPv6 6to4
Router(config)# ipv6 route 2002::/16 tunnel 0 prefix 2002::/16 to the 6to4 tunnel interface.
• The tunnel number specified in the ipv6 route

command must be the same tunnel number specified
in the interface tunnel command.

EXEC mode.
Example:
Router(config)# end
What to Do Next
Proceed to the “Verifying Tunnel Configuration and Operation” section.
Verifying Tunnel Configuration and Operation

The show and ping commands in the steps below can be used in any sequence. The following commands can
be used for GRE tunnels, IPv6 manually configured tunnels, and IPv6 over IPv4 GRE tunnels.
Step 1 enable
Enables privileged EXEC mode. Enter your password if prompted.
Example:
Device> enable
Step 2 show interfaces tunnel number [accounting]
477
Verifying Tunnel Configuration and Operation
Two routers are configured to be endpoints of a tunnel. Device A has TenGigabit Ethernet interface 4/1/0 configured as
the source for tunnel interface 0 with an IPv4 address of 10.0.0.1 and an IPv6 prefix of 2001:0DB8:1111:2222::1/64.
Device B has TenGigabit Ethernet interface 4/1/0 configured as the source for tunnel interface 1 with an IPv4 address of
10.0.0.2 and an IPv6 prefix of 2001:0DB8:1111:2222::2/64.
To verify that the tunnel source and destination addresses are configured, use the show interfaces tunnel command on
Device A.
Example:
Device A# show interfaces tunnel 0
Tunnel0 is up, line protocol is up

Hardware is Tunnel
MTU 1514 bytes, BW 9 Kbit, DLY 500000 usec,
Encapsulation TUNNEL, loopback not set
Keepalive not set
Tunnel source 10.0.0.1 (TenGigabitEthernet4/1/0), destination 10.0.0.2, fastswitch TTL 255
Tunnel protocol/transport GRE/IP, key disabled, sequencing disabled
Tunnel TTL 255
Checksumming of packets disabled, fast tunneling enabled
Last input 00:00:14, output 00:00:04, output hang never
Queueing strategy: fifo
Output queue :0/0 (size/max)
Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
Step 3 ping [protocol] destination

To check that the local endpoint is configured and working, use the ping command on Device A.
Example:
DeviceA# ping 2001:0DB8:1111:2222::2

Sending 5, 100-byte ICMP Echos to 2001:0DB8:1111:2222::2, timeout is 2 seconds:
!!!!!
Step 4 show ip route [address [mask]]

To check that a route exists to the remote endpoint address, use the show ip route command.
Example:
DeviceA# show ip route 10.0.0.2
Routing entry for 10.0.0.0/24

Known via "connected", distance 0, metric 0 (connected, via interface)
Routing Descriptor Blocks:
* directly connected, via TenGigabitEthernet4/1/0
Route metric is 0, traffic share count is 1
478
Configuration Examples for Implementing Tunnels
Step 5 ping [protocol] destination

To check that the remote endpoint address is reachable, use the ping command on Device A.
Note The remote endpoint address may not be reachable using the ping command because of filtering, but the tunnel
traffic may still reach its destination.
Example:
DeviceA# ping 10.0.0.2

!!!!!
To check that the remote IPv6 tunnel endpoint is reachable, use the ping command again on Device A. The note regarding
filtering earlier in step also applies to this example.
Example:
DeviceA# ping 2001:0DB8:1111:2222::2

Sending 5, 100-byte ICMP Echos to 1::2, timeout is 2 seconds:
!!!!!
These steps may be repeated at the other endpoint of the tunnel.
Configuration Examples for Implementing Tunnels

Example: Configuring a GRE IPv4 Tunnel
The following example shows a simple configuration of GRE tunneling. Note that TenGigabit Ethernet
interface 4/1/0 is the tunnel source for Router A and the tunnel destination for Router B. TenGigabit Ethernet
interface 4/1/1 is the tunnel source for Router B and the tunnel destination for Router A.
Router A
interface Tunnel 0
ip address 10.1.1.2 255.255.255.0
tunnel source TenGigabitEthernet 4/1/0
tunnel destination 192.168.3.2
tunnel mode gre ip
!
interface TenGigabitEthernet 4/1/0
ip address 192.168.4.2 255.255.255.0
Router B
interface Tunnel 0
479
Configuring QoS Options on Tunnel Interfaces Examples
ip address 10.1.1.1 255.255.255.0

tunnel mode gre ip
!
ip address 192.168.3.2 255.255.255.0
The following example configures a GRE tunnel running both IS-IS and IPv6 traffic between Router A and
Router B:
Router A
ipv6 unicast-routing
clns routing
!
interface Tunnel 0
no ip address
ipv6 address 2001:0DB8:1111:2222::1/64
ipv6 router isis
tunnel mode gre ip
!
ip address 10.0.0.1 255.255.255.0
!
router isis
network 49.0000.0000.000a.00
Router B
clns routing
!
interface Tunnel 0
no ip address
ipv6 address 2001:0DB8:1111:2222::2/64
ipv6 router isis
tunnel mode gre ip
!
ip address 10.0.0.2 255.255.255.0
!
router isis
network 49.0000.0000.000b.00
address-family ipv6
redistribute static
exit-address-family
Configuring QoS Options on Tunnel Interfaces Examples

The following sample configuration applies GTS directly on the tunnel interface. In this example, the
configuration shapes the tunnel interface to an overall output rate of 500 kb/s.
interface Tunnel 0
ip address 10.1.2.1 255.255.255.0
480
Policing Example
traffic-shape rate 500000 125000 125000 1000

tunnel source 10.1.1.1
The following sample configuration shows how to apply the same shaping policy to the tunnel interface with
the MQC commands:
policy-map tunnel
class class-default
shape average 500000 125000 125000
!
interface Tunnel 0
ip address 10.1.2.1 255.255.255.0
service-policy output tunnel
tunnel source 10.1.35.1
Policing Example
When an interface becomes congested and packets start to queue, you can apply a queueing method to packets
that are waiting to be transmitted. Logical interfaces--tunnel interfaces in this example--do not inherently
support a state of congestion and do not support the direct application of a service policy that applies a queueing
method. Instead, you must apply a hierarchical policy. Create a "child" or lower-level policy that configures
a queueing mechanism, such as low-latency queueing, with the priority command and CBWFQ with the
bandwidth command.
policy-map child
class voice
priority 512
Create a "parent" or top-level policy that applies class-based shaping. Apply the child policy as a command
under the parent policy because admission control for the child class is done according to the shaping rate for
the parent class.
policy-map tunnel
class class-default
shape average 2000000
service-policy child
Apply the parent policy to the tunnel interface.
interface tunnel 0
service-policy tunnel
In the following example, a tunnel interface is configured with a service policy that applies queueing without
shaping. A log message is displayed noting that this configuration is not supported.
Router(config)# interface tunnel1

Router(config-if)# service-policy output child
Class Based Weighted Fair Queueing not supported on this interface
481
How to Configure IPv6 over IPv4 GRE Tunnels
How to Configure IPv6 over IPv4 GRE Tunnels

Configuring GRE on IPv6 Tunnels
GRE tunnels can be configured to run over an IPv6 network layer and to transport IPv4 and IPv6 packets in
IPv6 tunnels.
Before you begin

When GRE IPv6 tunnels are configured, IPv6 addresses are assigned to the tunnel source and the tunnel
destination. The tunnel interface can have either IPv4 addresses or IPv6 addresses assigned (this is not shown
in the task). The host or device at each end of a configured tunnel must support both the IPv4 and IPv6 protocol
stacks.
Procedure

Device> enable

Example:
Device# configure terminal
Step 3 interface tunnel tunnel-number Specifies a tunnel interface and number, and enters interface
configuration mode.
Example:
Device(config)# interface tunnel 0
Step 4 Enter one of the following commands: Specifies the IPv6 network assigned to the interface and
enables IPv6 processing on the interface.
• ipv6 address {ipv6-address/prefix-length | prefix-name
sub-bits/prefix-length} • If you specify the eui-64 keyword, the software
• ipv6 address ipv6-prefix/prefix-length [eui-64] configures an IPv6 address for an interface and enables
IPv6 processing on the interface using an EUI-64
Example: interface ID in the low-order 64 bits of the address.
Device(config-if)# ipv6 address
3ffe:b00:c18:1::3/127
Step 5 tunnel source {ip-address | ipv6-address | interface-type Specifies the source IPv4 address, IPv6 address, or the
interface-number} source interface type and number for the tunnel interface.
Example: • If an interface is specified, the interface must be
configured with an IPv4 address.
Device(config-if)# tunnel source Tengigabitethernet
4/1/0
482
Configuration Examples for IPv6 over IPv4 GRE Tunnels

Step 6 tunnel destination {hostname | ip-address | ipv6-address} Specifies the destination IPv4 address, IPv6 address, or
hostname for the tunnel interface.
Example:
Device(config-if)# tunnel destination

2001:DB8:1111:2222::1/64
Step 7 tunnel mode {aurp | cayman | dvmrp | eon | gre | gre Specifies a GRE IPv6 tunnel.
multipoint | gre ipv6 | ipip [decapsulate-any] | iptalk |
Note The tunnel mode gre ipv6 command specifies
ipv6 | mpls | nos}
GRE as the encapsulation protocol for the tunnel.
Example:
Device(config-if)# tunnel mode gre ipv6

Example:
Configuration Examples for IPv6 over IPv4 GRE Tunnels

Example: GRE Tunnel Running IS-IS and IPv6 Traffic
The following example configures a GRE tunnel running both IS-IS and IPv6 traffic between Router A and
Router B:
Router A Configuration
clns routing
!
interface tunnel 0
no ip address
ipv6 address 3ffe:b00:c18:1::3/127
ipv6 router isis
tunnel destination 2001:DB8:1111:2222::1/64
tunnel mode gre ipv6
!
interface TenGigabitEthernet4/1/0
ip address 10.0.0.1 255.255.255.0
!
router isis
net 49.0000.0000.000a.00
Router B Configuration
clns routing
483
Example: Tunnel Destination Address for IPv6 Tunnel
!
interface tunnel 0
no ip address
ipv6 address 3ffe:b00:c18:1::2/127
ipv6 router isis
tunnel destination 2001:DB8:1111:2222::2/64
!
ip address 10.0.0.2 255.255.255.0
!
router isis
net 49.0000.0000.000b.00
address-family ipv6
redistribute static
exit-address-family
Example: Tunnel Destination Address for IPv6 Tunnel

Router(config)#interface Tunnel0
Router(config-if)#ipv6 address 2001:1:1::1/48
Router(config-if)#tunnel source TenGigabitEthernet 4/1/0
Router(config-if)#tunnel destination 10.0.0.2
Router(config-if)#tunnel mode gre ipv6
Router(config-if)#exit
!
Router(config)#interface TenGigabitEthernet4/1/0
Router(config-if)#ip address 10.0.0.1 255.255.255.0
!
Router(config)#ipv6 unicast-routing
Router(config)#router isis
Router(config)#net 49.0000.0000.000a.00
How to Configure GRE IPv6 Tunnels

Configure CDP Over GRE IPv6 Tunnels
Perform this task to configure a GRE tunnel on an IPv6 network. GRE tunnels can be configured to run over
an IPv6 network layer and transport IPv6 and IPv4 packets through IPv6 tunnels.
Note You must enable IPv6 or configure IPv6 MTU size more than 1500 on a tunnel's exit interface to avoid
receiving warning messages.
Before you begin

When GRE IPv6 tunnels are configured, IPv6 addresses are assigned to the tunnel source and the tunnel
destination. The tunnel interface can have either IPv4 or IPv6 addresses. The host or device at each end of
the configured tunnel must support both IPv4 and IPv6 protocol stacks.
484
Configure CDP Over GRE IPv6 Tunnels
Procedure

Device> enable

Example:
Step 3 interface tunnel tunnel-number Specifies a tunnel interface and number and enters interface
configuration mode.
Example:
Device(config)# interface tunnel 0
Step 4 CDP enable Enables Cisco Discovery Protocol on the interface.

Example:
Device(config)# CDP enable
Step 5 tunnel source {ipv6-address | interface-type Specifies the source IPv6 address or the source interface
|interface-number } type and number for the tunnel interface.
Example: • If an interface type and number are specified, the
Device(config-if)# tunnel source ethernet 0 interface must be configured with an IPv6 address.
Note For more information on the tunnel source

command, refer to the IPv6 command reference
guide.
Step 6 tunnel destination ipv6-address Specifies the destination IPv6 address for the tunnel
interface.
Example:
Device(config-if)# tunnel destination Note For more information on the tunnel destination
2001:0DB8:0C18:2::300 command, refer to the IPv6 command reference
guide.
Step 7 tunnel mode gre ipv6 Specifies a GRE IPv6 tunnel.

Example: Note The tunnel mode gre ipv6 command specifies
Device(config-if)# tunnel mode gre ipv6 GRE as the encapsulation protocol for the tunnel
interface. Only the syntax used in this context is
displayed. For more details, see the IPv6
Command Reference.

EXEC mode.
Example:
485
Configuration Examples for GRE IPv6 Tunnels
Configuration Examples for GRE IPv6 Tunnels

Example: Configuring CDP Over GRE IPv6 Tunnels
The following example shows how to configure a GRE tunnel over an IPv6 transport. In this example,
Ethernet0/0 has an IPv6 address, and this is the source address used by the tunnel interface. The destination
IPv6 address of the tunnel is specified directly. In this example, the tunnel carries both IPv4 and IS-IS traffic.
interface Tunnel0
ip address 10.1.1.1 255.255.255.0
ip router isis
tunnel source Ethernet0/0
tunnel destination 2001:DB8:1111:2222::1
!
interface Ethernet0/0
no ip address
ipv6 address 2001:DB8:1111:1111::1/64
!
router isis
net 49.0001.0000.0000.000a.00
The following example shows how to configure CDP on GRE IPv6 P2P Tunnel Interface.
interface Tunnel1
cdp enable
ipv6 address 20::1/64
tunnel source Ethernet0/0
tunnel destination 10::2
end
The following example shows how to configure CDP on GRE IPv6 Multipoint Tunnel Interface.
interface Tunnel1
ipv6 nhrp map 172::1/64 192::1
ipv6 nhrp map multicast 192::1
ipv6 nhrp network-id 1
ipv6 nhrp nhs 172::1
llp nhrp map multicast 192::1
tunnel source 2000::1
tunnel mode gre multipoint ipv6
end
The following show example displays the CDP neighbor tunnels that are configured in a device.
Router#show cdp neighbors
Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
S - Switch, H - Host, I - IGMP, r - Repeater, P - Phone,
D - Remote, C - CVTA, M - Two-port Mac Relay
Device ID Local Intrfce Holdtme Capability Platform Port ID

Router Tunnel1 179 R Linux Uni Tunnel1
The following sections provide references related to the GRE feature.
486
Related Documents
Related Document Title

Topic
CMTS Cisco CMTS Cable Command Reference, at the following URL:

Command http://www.cisco.com/c/en/us/td/docs/cable/cmts/cmd_ref/b_cmts_cable_cmd_ref.html
Reference
Configuring Configuring GRE Tunnel over Cable, at the following URL:

GRE http://www.cisco.com/en/US/tech/tk86/tk89/technologies_configuration_example09186a008011520d.shtm
Tunnel
over Cable
Standards
Standard Title

Specification, version 1.1 ( http://www.cablemodem.com )
MIBs
MIB MIBs Link
No new or modified MIBs are To locate and download MIBs for selected platforms, Cisco IOS
supported by this feature. releases, and feature sets, use Cisco MIB Locator found at the
following URL:
http://tools.cisco.com/ITDIT/MIBS/servlet/index
RFCs
RFC Title
RFC 1701 Generic Routing Encapsulation (GRE)
RFC 1702 Generic Routing Encapsulation over IPv4 networks
RFC 1853 IP in IP Tunneling
RFC 2003 IP Encapsulation within IP
RFC 2784 Generic Routing Ecapsulation (GRE)
RFC 2890 Key and Sequence Number Extensions to GRE
487
Feature Information for Generic Routing Encapsulation
Description Link
The Cisco Technical Support & Documentation website http://www.cisco.com/cisco/web/support/index.html

contains thousands of pages of searchable technical
content, including links to products, technologies,
solutions, technical tips, and tools. Registered
Cisco.com users can log in from this page to access
even more content.
Feature Information for Generic Routing Encapsulation

Table 81: Feature Information for Generic Routing Encapsulation
Generic Routing Encapsulation Cisco IOS XE Fuji This feature was integrated on the Cisco cBR
488
CHAPTER 27
Transparent LAN Service over Cable
This document describes the Transparent LAN Service (TLS) over Cable feature, which enhances existing
Wide Area Network (WAN) support to provide more flexible Managed Access for multiple Internet service
provider (ISP) support over a hybrid fiber-coaxial (HFC) cable network. This feature allows service providers
to create a Layer 2 tunnel by mapping an upstream service identifier (SID) to an IEEE 802.1Q Virtual Local
Area Network (VLAN).
Contents
• Prerequisites for Transparent LAN Service over Cable, on page 491
• Restrictions for Transparent LAN Service over Cable, on page 491
• Information About Transparent LAN Service over Cable, on page 492
• How to Configure the Transparent LAN Service over Cable, on page 494
• Configuration Examples for Transparent LAN Service over Cable, on page 496
• Verifying the Transparent LAN Service over Cable Configuration, on page 498
• Feature Information for Transparent LAN Service over Cable , on page 499
489
Digital PICs:

Module:

Modules:
line card reload.
490
Prerequisites for Transparent LAN Service over Cable
Prerequisites for Transparent LAN Service over Cable

• You must know the hardware (MAC) addresses of the cable modems that are to be mapped to IEEE
802.1Q VLANs.
• You must create a bridge group for each separate customer on the Layer 2 bridge aggregator, so that
traffic from all of the Customer Premises Equipment (CPE) devices for the customer is grouped together
into the same 802.1Q tunnel.
Restrictions for Transparent LAN Service over Cable

• Configuring 802.1Q for a particular cable modem removes any previous cable modem configuration on
the router.
• We strongly recommend that TLS over Cable only be used when Baseline Privacy Interface (BPI) is
enabled in the environment. If BPI is not enabled when using the TLS feature, traffic can flow between
multiple virtual private networks (VPNs), and become vulnerable to denial-of-service attacks or snooping.
We also recommend that remote networks be isolated with a gateway or firewall router when BPI is not
enabled.
When the TLS feature is used with Layer 2 VPNs, the participating cable modems must have the Baseline
Privacy Interface security feature (BPI) enabled. Otherwise, the Cisco CMTS drops such Layer 2 traffic in
the upstream or downstream.
• Packets are mapped to their Layer 2 tunnel only on the basis of Layer 2 information (the cable modem’s
MAC address and primary SID). Layer 3 services, such as access lists, IP address source-verify, and IP
QoS, are not supported as packets are sent through the tunnel.
• All traffic from a cable modem is mapped to the same Layer 2 tunnel. It is not possible to differentiate
traffic from different customer premises equipment (CPE) devices behind the cable modem.
• CPE learning is not available when using the Transparent LAN Service over Cable feature. When a cable
modem is mapped to a Layer 2 tunnel, the show interface cable modem command shows that the IP
addresses for its CPE devices are “unavailable.”
• DOCSIS QoS is supported across the Layer 2 tunnel only on the primary SID. Traffic using secondary
services uses the same Layer 2 tunnel as the primary SID.
• The Spanning Tree Protocol (STP) cannot be used with devices (cable modems, their CPE devices, and
the endpoint CPE devices) that are using this feature. In particular, Spanning Tree Protocol cannot be
used between the VLAN bridge aggregator and the endpoint customer devices.
• The following restrictions apply to Layer 2 tunnels over an Ethernet IEEE 802.1Q VLAN interface:
• IEEE 802.1Q tunnels are supported only on Ten Gigabit Ethernet interfaces.
• The Cisco CMTS router supports a maximum of 4095 VLAN IDs, but the switches acting as the
bridge aggregator might support a lower number of VLAN IDs. If this is the case, the Cisco CMTS
should be configured only for the maximum number of VLANs that are supported by the bridge
aggregator switches.
491
Information About Transparent LAN Service over Cable
Information About Transparent LAN Service over Cable

Feature Overview
The Transparent LAN Service over Cable feature enables service providers to provide Layer 2 tunnels for
traffic to and from cable modems. This allows customers to create their own virtual local area network (VLAN)
using any number of cable modems in multiple sites.
On the Cisco CMTS, you map each cable modem (on the basis of its MAC address) to the appropriate VLAN.
The CMTS then creates an internal database of this one-to-one mapping of cable modems to VLANs, and
uses it to encapsulate packets for the appropriate VLAN.
The CMTS encapsulates the CPE traffic from mapped cable modems using the following method:
• IEEE 802.1Q Mapping—The cable modem’s MAC address is mapped to an IEEE 802.1Q VLAN on a
specific Ten Gigabit Ethernet interface, so that all traffic from the cable modem is tagged with the
specified VLAN ID.
Traffic to and from this group of cable modems is bridged into a single logical network (the VLAN) by the
bridge aggregator, creating a secure Virtual Private Network (VPN) for that particular group of cable modems.
Traffic in one VLAN cannot be sent into another VLAN, unless specifically done so by an external router.
The switch acting as the Layer 2 Bridge Aggregator uses the VLAN tagging to forward the traffic to the
appropriate destination. This frees up service providers from needing to know the addressing, routing, and
topological details of the customer’s network.
Transparent LAN Service and Layer 2 Virtual Private Networks

In addition, service providers can provide a Layer 2 VPN with only minimal configuration changes on the
provider’s routers. The service subscriber does not need to make any changes to their private network or cable
modems, nor does the service provider have to provide any special DOCSIS configuration files to enable this
feature.
For the TLS feature with Layer 2 VPNs:
• When the TLS feature is used with Layer 2 VPNs, the participating cable modems must have the Baseline
Privacy Interface security feature (BPI) enabled. Otherwise, the Cisco CMTS drops such Layer 2 traffic
in the upstream or downstream.
• Information about Customer Premises Equipment (CPE) does not display in the output of the show cable
modem command.
IEEE 802.1Q Mapping

This section describes the mapping of cable modems to an IEEE 802.1Q VLAN, as it is available in the
Transparent LAN Service over Cable feature:
492
Overview
Overview
The Transparent LAN Service over Cable feature enables service providers to provide Layer 2 tunnels over
an Ethernet network, using IEEE 802.1Q standard tags. This allows customers to create their own virtual
network using any number of cable modems in different sites.
On the Cisco CMTS, you map each cable modem (on the basis of its MAC address) to the appropriate VLAN.
The CMTS then creates an internal database of this one-to-one mapping of cable modems to VLANs, and
uses it to encapsulate packets for the appropriate VLAN.
The CMTS encapsulates the CPE traffic from mapped cable modems using VLAN tags, as defined in IEEE
802.1Q-1993, IEEE Standards for Local and Metropolitan Area Networks: Virtual Bridged Local Area
Networks . The switch acting as the Layer 2 Bridge Aggregator uses the VLAN tagging to forward the packets
to the appropriate destination.
Traffic to and from this group of cable modems is bridged into a single logical network by the bridge aggregator,
creating a secure Virtual Private Network (VPN) for that particular group of cable modems. Traffic in one
VLAN cannot be sent into another VLAN, unless specifically done so by an external router.
Details of IEEE 802.1Q Mapping

To implement the Transparent LAN Service over Cable feature using IEEE 802.1Q VLANs, a service provider
must perform the following configuration steps:
1. Identify the cable modems and their MAC addresses that should be mapped to the IEEE 802.1Q VLANs.
2. Create the required VLANs on the router that is acting as the bridge aggregator.
3. Enable Layer 2 mapping on the Cisco CMTS, and then map each cable modem on that Cisco CMTS to
the appropriate VLAN.
After the Transparent LAN Service over Cable feature has been enabled and configured to use IEEE 802.1Q
mappings, the Cisco CMTS immediately begins mapping traffic between the associated cable modems and
VLANs. For efficient mapping, the Cisco CMTS maintains an internal database that links each cable modem’s
primary service flow ID (SFID) and service ID (SID) to the appropriate VLAN and Ethernet interface. This
ensures that all service flows from the cable modem are routed properly.
When the Cisco CMTS receives a packet on an upstream, it looks up its SID to see if it is mapped to a VLAN.
If so, and if the packet’s source MAC address is not the cable modem’s MAC address, the Cisco CMTS inserts
the appropriate IEEE 802.1Q VLAN tag into the packet’s header and forwards the packet to the appropriate
Ethernet interface. If the packet is not being mapped, or if the packet originated from the cable modem, the
Cisco CMTS routes the packet using the normal Layer 3 processes.
When the Cisco CMTS receives a packet from a WAN interface that is encapsulated with an IEEE 802.1Q
VLAN tag, it looks up the packet’s SID to see if it belongs to a cable modem being mapped. If so, the Cisco
CMTS strips off the VLAN tag, adds the proper DOCSIS header, and transmits the packet on the appropriate
downstream interface. If the packet is not being mapped, the Cisco CMTS continues with the normal Layer
3 processing.
Benefits
The Transparent LAN Service over Cable feature provides the following benefits to cable service providers
and their partners and customers:
• Provides Layer 2 level mapping, which is transparent to Layer 3 protocols and services. This means that
service providers do not need to know the details of their customers’ network topologies, routing protocols,
or IP addressing.
493
How to Configure the Transparent LAN Service over Cable
• Allows service providers to maximize the use of their existing Ethernet WAN networks. Multiple
customers can be combined on the same outgoing interface, while still ensuring that each customer’s
network is kept private while it is transmitted over the tunnel.
• Provides a highly flexible and scalable solution for multiple customers. The service provider needs to
create only one bridge group for each VPN, and then only one VLAN mapping for each cable modem
should participate in that VPN tunnel.
• Customers retain full control over their private networks, while service providers retain full control over
cable modems and the rest of the cable and WAN networks. Only the CPE traffic from the cable modems
is mapped into the L2VPN tunnel, while traffic originating at the cable modem continues to be processed
as normal by the service provider's network.
• Allows service providers to mix tunneled and non-tunneled cable modems on the same DOCSIS cable
network.
• Allows customers to create a single, secure virtual network with Ethernet Layer 2 connectivity for multiple
sites.
• Allows multiple tunnels from different customers and endpoints to be aggregated into a single bridge,
so as to maximize the use of bandwidth and other network resources.
• Supports the tunneling of multiple Layer 3, non-IP protocols, and not just IP Layer 3 services, as is the
case with Layer 3 solutions, such as Multiprotocol Label Switching (MPLS) VPNs.
• All DOCSIS services, including BPI+ encryption and authentication, continue to be supported for all
cable modems.
How to Configure the Transparent LAN Service over Cable

Configuring IEEE 802.1Q VLAN Mapping

This section describes how to enable Layer 2 mapping on the Cisco CMTS, and then to map particular cable
modems to an IEEE 802.1Q VLAN.
Enabling and Configuring Layer 2 Tunneling for IEEE 802.1Q Mapping

This section describes how to enable Layer 2 mapping on the Cisco CMTS, and then to map particular cable
modems to IEEE 802.1Q VLANs on a Ten Gigabit Ethernet interface.
Procedure

prompted.
Example:
Router> enable

Example:
494
Creating the IEEE 802.1Q VLAN Bridge Group

Step 3 cable l2-vpn-service xconnect nsi dot1q Enables Layer 2 tunneling for IEEE 802.1Q VLAN
mapping.
Example:
Note It is not required to configure VLAN trunking
Router(config)# cable l2-vpn-service xconnect nsi on the Cisco CMTS. Though VLAN trunking is
dot1q supported, be aware of additional impact of
VLAN trunking on the Cisco CMTS.
Step 4 cable dot1q-vc-map mac-address ethernet-interface vlan-id Maps the specified MAC address of a cable modem to the
[cust-name ] indicated VLAN and Ten Gigabit Ethernet interface.
Example: Note Repeat this command for each cable modem that
is to be mapped to an IEEE 802.1Q VLAN.
Router(config)# cable dot1q-vc-map 0000.0C04.0506
TenGigabitEthernet4/1/0 10

EXEC mode.
Example:
Router(config)# end
Creating the IEEE 802.1Q VLAN Bridge Group

This section describes the minimum configuration needed to configure a Cisco router, which is acting as an
IEEE 802.1Q VLAN bridge aggregator, so that it can terminate the VLANs being used with the Transparent
LAN Service over Cable feature.
Procedure

prompted.
Example:
Router> enable

Example:
Example:
Step 3 interface TenGigabitEthernet slot/subslot/port Enters interface configuration mode for the Ten Gigabit
Ethernet interface.
Example:
Router(config)# interface TenGigabitEthernet4/1/0
Step 4 ip address ip-address mask Configures the interface with the specified IP address and
subnet mask.
Example:
495
Configuration Examples for Transparent LAN Service over Cable
Router(config-if)# ip address 10.10.10.85

255.255.255.0
Step 5 exit Exits interface configuration and returns to global

configuration mode.
Example:
Step 6 interface TenGigabitEthernet slot/subslot/port.y Creates a subinterface on the Ten Gigabit Ethernet interface.
Example: Note To simplify network management, set the
subinterface number to the same value as the
Router(config)# interface VLAN ID that will use this subinterface (which
TenGigabitEthernet4/1/0.10 in this case is 10).
Note The steps to create a subinterface is not essential
for dot1q tagging of frames, but it is
recommended.
Step 7 bridge group number Configures this subinterface to belong to the specified bridge
group.
Example:
Note Repeat steps Step 5 through Step 7 for each
Router(config-if)# bridge group 20 subinterface to be created and bridged.

EXEC mode.
Example:
Configuration Examples for Transparent LAN Service over Cable

This section lists sample configurations for the Transparent LAN Service over Cable feature on a CMTS
router and on a Cisco router acting as a bridge aggregator:
Example: Configuring IEEE 802.1Q VLAN Mapping

The following partial configuration shows a typical configuration that shows a number of cable modems being
mapped to two different IEEE 802.1Q VLANs.
cable l2-vpn-service xconnect nsi dot1q

! Customer 1
cable dot1q-vc-map 000C.0e03.69f9 TenGigabitEthernet 4/1/0 10 Customer1
cable dot1q-vc-map 0010.7bea.9c95 TenGigabitEthernet 4/1/0 11 Customer1
cable dot1q-vc-map 0010.7bed.81c2 TenGigabitEthernet 4/1/0 12 Customer1
cable dot1q-vc-map 0010.7bed.9b1a TenGigabitEthernet 4/1/0 13 Customer1
! Customer 2
cable dot1q-vc-map 0002.fdfa.137d TenGigabitEthernet 4/1/0 20 Customer2
cable dot1q-vc-map 0006.28f9.9d19 TenGigabitEthernet 4/1/0 21 Customer2
cable dot1q-vc-map 000C.7b6b.58c1 TenGigabitEthernet 4/1/0 22 Customer2
496
Example: Configuring IEEE 802.1Q Bridge Aggregator
cable dot1q-vc-map 000C.7bed.9dbb TenGigabitEthernet 4/1/0 23 Customer2

cable dot1q-vc-map 000C.7b43.aa7f TenGigabitEthernet 4/1/0 24 Customer2
cable dot1q-vc-map 0050.7302.3d83 TenGigabitEthernet 4/1/0 25 Customer2
...
Example: Configuring IEEE 802.1Q Bridge Aggregator

The following example shows a router being used as a bridge aggregator to transmit VLANs across the same
Ten Gigabit Ethernet interface, using IEEE 802.1Q tagging.
!
ip address 10.10.10.31 255.255.255.0
duplex full
speed auto
!
interface TenGigabitEthernet4/1/0.10
description Customer1-site10
encapsulation dot1Q 10
bridge-group 200
bridge-group 200
bridge-group 200
bridge-group 200
!------------------------------------
bridge-group 201
bridge-group 201
bridge-group 201
bridge-group 201
bridge-group 201
bridge-group 201
!
bridge 200 protocol ieee
bridge 201 protocol ieee
...
497
Verifying the Transparent LAN Service over Cable Configuration
Verifying the Transparent LAN Service over Cable Configuration

• show cable l2-vpn xconnect dot1q-vc-map —Displays the mapping information of the cable modems
to IEEE 802.1Q VLANs.
Router# show cable l2-vpn xconnect dot1q-vc-map
MAC Address Ethernet Interface VLAN ID Cable Intf SID Customer Name/VPNID
38c8.5cac.4a62 TenGigabitEthernet4/1/2 56 Cable3/0/0 4 Customer2
38c8.5cfe.f6fa TenGigabitEthernet4/1/2 34 Cable3/0/0 3 Customer1
602a.d083.2e1c TenGigabitEthernet4/1/4 43 Cable3/0/0 5 Customer3
• show cable l2-vpn xconnect dot1q-vc-map customer name—Displays the mapping information of the
cable modems to IEEE 802.1Q VLANs for the specified customer name.
Following is a sample output of the command.
Router# show cable l2-vpn xconnect dot1q-vc-map customer Customer1
38c8.5cfe.f6fa TenGigabitEthernet4/1/2 34 Cable3/0/0 3 Customer1
• show cable l2-vpn xconnect dot1q-vc-map mac-address—Displays the mapping information of the
cable modems to IEEE 802.1Q VLANs for the specified MAC address.
Router# show cable l2-vpn xconnect dot1q-vc-map 38c8.5cac.4a62
38c8.5cac.4a62 TenGigabitEthernet4/1/2 56 Cable3/0/0 4 Customer2
• show cable l2-vpn xconnect dot1q-vc-map mac-address verbose—Displays additional information

about the Layer 2 mapping, including the number of packets and bytes received on the upstream and
downstream.
Router# show cable l2-vpn xconnect dot1q-vc-map 38c8.5cac.4a62 verbose
MAC Address : 38c8.5cac.4a62

Customer Name : Customer2
Prim Sid : 4
Cable Interface : Cable3/0/0
Ethernet Interface : TenGigabitEthernet4/1/2
DOT1Q VLAN ID : 56
Total US pkts : 1
Total US bytes : 342
Total DS pkts : 4
Total DS bytes : 512
498
Standards
Standards Title

Specification
IEEE 802.1Q, 1998 Edition IEEE Standards for Local and Metropolitan Area Networks: Virtual Bridged
Local Area Networks
RFCs
2
RFCs Title
RFC 1163 A Border Gateway Protocol
RFC 1164 Application of the Border Gateway Protocol in the Internet
RFC 2283 Multiprotocol Extensions for BGP-4

2
Not all supported RFCs are listed.
Description Link
Technical Assistance Center (TAC) home page, http://www.cisco.com/cisco/web/support/index.html

containing 30,000 pages of searchable technical content,
including links to products, technologies, solutions,
technical tips, and tools. Registered Cisco.com users
can log in from this page to access even more content.
Feature Information for Transparent LAN Service over Cable

499
Feature Information for Transparent LAN Service over Cable
Table 83: Feature Information for Upstream Channel Bonding
Transparent LAN Service over Cisco IOS XE Fuji This feature was integrated on the Cisco cBR
Cable 16.7.1 Series Converged Broadband Router.
500
CHAPTER 28
Downgrading Channel Bonding in Battery
Backup Mode
Cisco CMTS supports downgrading the channel bonding for cable modems and media terminal adapters
(MTAs) in battery backup mode.
Contents
• Prerequisites for Downgrading Channel Bonding in Battery Backup Mode, on page 503
• Restrictions for Downgrading Channel Bonding in Battery Backup Mode, on page 503
• Information About Downgrading Channel Bonding in Battery Backup Mode, on page 503
• How to Configure Downgrading Channel Bonding in Battery Backup Mode, on page 504
• Verifying the Configuration for Channel Bonding Downgrade in Battery Backup Mode, on page 506
• Feature Information for Downgrading Channel Bonding in Battery Backup Mode, on page 510
501
Digital PICs:

Module:

Modules:
line card reload.
502
Prerequisites for Downgrading Channel Bonding in Battery Backup Mode
Prerequisites for Downgrading Channel Bonding in Battery

Backup Mode
• The cable modem must be DOCSIS3.0-compliant with battery backup capability.
• At last one free Downstream Resilient Bonding Group (RBG) must be available.
Note For information about how to reserve RBG and verify reserved RBG, refer to
Downstream Resiliency Bonding Group , on page 335
Restrictions for Downgrading Channel Bonding in Battery

Backup Mode
• If the cable modem does not support the CM-STATUS events 9 and 10, channel bonding is not downgraded
for the cable modem in battery backup mode.
Note We recommend that you configure separate dynamic bonding groups for each
primary channel in a MAC domain.
• If the cable modem has an active voice call, channel bonding is not downgraded for the cable modem in
battery backup mode.
• If the cable modem is working on the protect line card, channel bonding is not downgraded if its primary
channel is not included in the dynamic bonding group.
• If the line card switches over when the cable modem is entering or exiting the battery backup mode, the
cable modem may go offline.
Information About Downgrading Channel Bonding in Battery

Backup Mode
When this feature is enabled and the cable modem enters the battery backup mode, channel bonding is
downgraded to one downstream and one upstream channels (battery backup 1x1 mode). This feature reduces
the power usage when the cable modem is running on battery backup. When the cable modem returns to the
AC power mode, the channel bonding is returned to its original configuration. You can configure this feature
globally and for each MAC domain.
503
How to Configure Downgrading Channel Bonding in Battery Backup Mode
Note We recommend that you enable this feature globally and for each MAC domain.
The cable modem uses the following CM-STATUS events to indicate its power status to the Cisco CMTS:
• 9—Indicates that the cable modem is operating in battery backup mode.
• 10—Indicates that the cable modem has returned to AC power mode.
When this feature is disabled, cable modem cannot downgrade the channel bonding even if it is running on
battery backup.
How to Configure Downgrading Channel Bonding in Battery

Backup Mode
Configuring Channel Bonding Downgrade in Battery Backup Mode Globally

Procedure

Router> enable

Example:
Step 3 cable reduction-mode mta-battery enable Enables the channel bonding downgrade for cable modems
in battery backup mode.
Example:
Router(config)# cable reduction-mode mta-battery
enable
Step 4 cable reduction-mode mta-battery dampen-time seconds (Optional) Configures the dampen time, in seconds, to defer
the cable modems from entering or exiting the channel
Example:
bonding downgrade 1x1 mode.
dampen-time 40
Step 5 cable reduction-mode mta-battery (Optional) Configures the init-ranging technique.

ranging-init-technique us-ranging-init-technique
Example:
ranging-init-technique 3
504
Configuring Channel Bonding Downgrade in Battery Backup Mode for MAC Domain

Step 6 cable reduction-mode mta-battery (Optional) Configures the maximum and first try percentage
dynamic-channel-percent percent of dynamic channel bandwidth in battery backup mode.
Example: Note Ensure to leave enough bandwidth for primary
Router(config)# cable reduction-mode mta-battery channel so that it can allocate dynamic channel
dynamic-channel-percent 10 bandwidth when it joins a newly created dynamic
bonding group.
Step 7 exit Returns to the privileged EXEC mode.

Example:
Configuring Channel Bonding Downgrade in Battery Backup Mode for MAC

Domain
Procedure

Router> enable

Example:

slot/subslot/port:wideband-channel
Example:
Step 4 cable ds-resiliency Reserves a resiliency bonding group or WB interface for

usage on a line card, on a per controller basis.
Example:

Example:
Step 6 interface cable slot/subslot/port Specifies the cable interface on the router and enters the
Example:
505
Verifying the Configuration for Channel Bonding Downgrade in Battery Backup Mode

Step 7 cable reduction-mode mta-battery enable Enables the channel bonding downgrade for cable modems
in battery backup mode for each MAC domain.
Example:
Router(config-if)# cable reduction-mode
mta-battery enable
Step 8 cable cm-status enable 9 Enables the CM-STATUS event 9 for the MAC domain.
The value 9 indicates that the cable modem is operating
Example:
in battery backup mode.
Router(config-if)# cable cm-status enable 9
Step 9 cable cm-status enable 10 Enables the CM-STATUS event 10 for the MAC domain.
The value 10 indicates that the cable modem has returned
Example:
to AC power mode.
Router(config-if)# cable cm-status enable 10
Step 10 end Returns to the privileged EXEC mode.

Example:
Verifying the Configuration for Channel Bonding Downgrade in

Battery Backup Mode
• show cable modem—Displays information if the cable modem is running in battery backup mode.
D
MAC Address IP Address I/F MAC Prim RxPwr Timing Num
I
State Sid (dBmv) Offset CPE
P
f45f.d4a1.b75a --- C6/1/0/UB p-online(pt) 846 !-3.50 1475 0
N
c427.9551.3489 30.154.1.12 C6/1/0/UB w-online(pt) 930 -0.50 1579 2
Y
f45f.d4a1.b762 30.55.223.253 C6/1/0/UB w-online 1770 0.00 1503 0
Y
0016.925e.661a 30.55.230.136 C6/1/0/U0 online(pt) 825 -0.50 1467 1
N
4458.2945.458a 30.0.7.72 C6/1/0/UB w-online 3916 0.00 1511 2
Y
4458.2945.401e --- C6/1/0/UB w-online(pt) 847 -0.50 1473 1
N
4458.2945.20c6 --- C6/1/0/UB w-online(pt)(bm) 895 0.00 1481 0
N
• show cable modem reduction-mode mta-battery—Displays the channel bonding downgrade information
for cable modems in battery backup mode.
506
Router# show cable modem reduction-mode mta-battery
Orig BG Curr BG
I/F MAC Address ID I/F RFs ID I/F Upstream
------- -------------- ---------------------------------------------------------
C7/0/0 0025.2eaf.843e 897 Wi7/0/0:0 4 252 Wi7/0/0:1 US0
C7/0/0 0025.2eaf.8356 897 Wi7/0/0:0 4 252 Wi7/0/0:1 US0
C7/0/0 0015.d176.5199 897 Wi7/0/0:0 4 252 Wi7/0/0:1 US0
Following is a sample output of the command for a cable modem when the MAC address is specified:
Router# show cable modem 0025.2eaf.843e reduction-mode mta-battery
Orig BG Curr BG
------- -------------- ---------------------------------------------------------
C7/0/0 0025.2eaf.843e 897 Wi7/0/0:0 4 252 Wi7/0/0:1 US0
Following is a sample output of the command for a cable modem when the IP address is specified:
Router# show cable modem 90.18.0.9 reduction-mode mta-battery
Orig BG Curr BG
------- -------------- ---------------------------------------------------------
C7/0/0 0025.2eaf.843e 897 Wi7/0/0:0 4 252 Wi7/0/0:1 US0
Following is a sample output of the command for a cable modem when the IPv6 address is specified:
Router# show cable modem 2001:18::9 reduction-mode mta-battery
Orig BG Curr BG
------- -------------- ---------------------------------------------------------
C7/0/0 0025.2eaf.843e 897 Wi7/0/0:0 4 252 Wi7/0/0:1 US0
• show cable modem verbose—Displays the detailed information for the cable modem.
Router# show cable modem 54d4.6ffb.30fd verbose
MAC Address : 54d4.6ffb.30fd

IP Address : 40.4.58.14
IPv6 Address : 2001:40:4:58:741A:408D:7E4B:D7C8
Dual IP : Y
Prim Sid : 9
Host Interface : C7/0/0/UB
MD-DS-SG / MD-US-SG : 1 / 1
MD-CM-SG : 0x3C0101
Primary Wideband Channel ID : 897 (Wi7/0/0:0)
Primary Downstream : In7/0/0:2 (RfId : 722)
RCP Index : 3
RCP ID : 00 10 00 00 08
Downstream Channel DCID RF Channel : 99 7/0/0:2
Multi-Transmit Channel Mode : Y
Upstream Channel : US0 US1
507
Ranging Status : sta sta

Upstream SNR (dB) : 36.12 32.55
Upstream Data SNR (dB) : -- --
Received Power (dBmV) : 0.00 0.00
Reported Transmit Power (dBmV) : 25.25 26.00
Peak Transmit Power (dBmV) : 54.00 54.00
Phy Max Power (dBmV) : 54.00 54.00
Minimum Transmit Power (dBmV) : 24.00 24.00
Timing Offset (97.6 ns): 1226 1226
Initial Timing Offset : 1229 973
Rng Timing Adj Moving Avg(0.381 ns): -1 0
Rng Timing Adj Lt Moving Avg : -7 0
Rng Timing Adj Minimum : -768 0
Rng Timing Adj Maximum : 0 64768
Pre-EQ Good : 0 0
Pre-EQ Scaled : 0 0
Pre-EQ Impulse : 0 0
Pre-EQ Direct Loads : 0 0
Good Codewords rx : 515 472
Corrected Codewords rx : 0 0
Uncorrectable Codewords rx : 0 0
Phy Operating Mode : atdma* atdma*
sysDescr :
Modem Status : {Modem= w-online, Security=disabled}
Capabilities : {Frag=N, Concat=N, PHS=Y}
Security Capabilities : {Priv=, EAE=Y, Key_len=}
Number of CPE IPs : 0(Max CPE IPs = 16)
CFG Max-CPE : 200
Flaps : 0()
LB group ID assigned (index) : 2151416065 (48131)
LB group ID in config file (index) : N/A (N/A)
LB policy ID : 0
LB priority : 0
Tag :
Service Type ID :
Voice Enabled : NO
508
CM Energy Management Capable : Y

CM Enable Energy Management : Y
CM Enter Energy Management : No
Battery Mode : Yes
Battery Mode Status : BATTERY_MODE / AC_POWER_MODE
DS Change Times : 0
CM Initialization Reason : NO_PRIM_SF_USCHAN
CFG Max IPv6 CPE Prefix : 16 (-1 used)
Note Battery Mode indicates if the cable modem is in battery backup mode or AC
power mode.
Battery Mode Status indicates the status of the cable modem:
• When the cable modem is in AC_POWER_MODE/BATTERY_MODE
status, it is in stable state.
• When the cable modem is in
AC_POWER_PENDING/BATTERY_PENDING status, it is in transfer
state.
• When the cable modem is in AC_POWER_HOLD/BATTERY_HOLD
status, it is updating status of the last event received until the dampen time
expires.
• show cable modem cm-status—Displays the cable modem CM-STATUS event information.
Router# show cable modem e448.c70c.9d80 cm-status
I/F MAC Address Event TID Count Error Dups Time

C6/0/3/UB e448.c70c.9d80 Battery backup 14 1 0 0 Apr 2 22:17:29
e448.c70c.9d80 A/C power 1 1 0 0 Apr 2 22:43:52
Related Documents

commands
509
Feature Information for Downgrading Channel Bonding in Battery Backup Mode
Standards and RFCs
Standard/RFC Title
CM-SP- MULPIv3.1-I01-131029 Data-Over-Cable Service Interface Specifications, DOCSIS 3.1, MAC
and Upper Layer Protocols Interface Specification
Description Link
ID and password.
Feature Information for Downgrading Channel Bonding in

Battery Backup Mode
Table 85: Feature Information for Downgrading Channel Bonding in Battery Backup Mode
Battery Backup 1x1 Mode Cisco IOS XE Everest This feature was introduced in the Cisco IOS XE
16.6.1 Everest 16.6.1 on the Cisco cBR Series Converged
Broadband Routers.
510
CHAPTER 29
Upstream Bonding Support for D-PON
The DOCSIS Passive Optical Network (D-PON) architecture, also known as RF over Glass (RFoG), helps
the cable operators enter fiber-to-home market space and utilize the DOCSIS infrastructure effectively.
• Prerequisites for Upstream Bonding Support for D-PON, on page 512
• Restrictions for Upstream Bonding Support for D-PON, on page 513
• Information About Upstream Bonding Support for D-PON, on page 514
• How to Configure Upstream Bonding Support for D-PON , on page 515
• Verifying the Upstream Bonding Support for D-PON, on page 516
• Feature Information for Upstream Bonding Support for D-PON, on page 517
511
Prerequisites for Upstream Bonding Support for D-PON
Digital PICs:

Module:

Modules:
line card reload.
Prerequisites for Upstream Bonding Support for D-PON

• DOCSIS 3.0 cable modems (CMs)
512
Restrictions for Upstream Bonding Support for D-PON
• DOCSIS 2.0 capable set-top boxes (STBs)

• You should configure the cable upstream ranging-init-technique 2 command to prevent the use of
additional broadcast initial ranging opportunities for the non D-PON reference upstream channels.
Restrictions for Upstream Bonding Support for D-PON

• Multiple CMs cannot work at the same time. Each CM must get a separate time slot for upstream data
transmission. Configuring D-PON ensures that the upstream scheduler allows only a single CM to transmit
at a particular time.
• Cisco cBR-8 does not support Upstream Bonding for D-PON on Remote-PHY.
• It is possible to enable or disable D-PON for individual Mac domain.
• When you enable D-PON on a MAC domain, you must manually shut down and enable the MAC domain
using shutdown and no shutdown command.
• When enabling D-PON on a MAC domain, the D-PON is not supported with upstream balance-scheduling.
Remove the upstream balance scheduling using the following command:
no cable upstream balance-scheduling
• All frequencies in a MAC domain must have the same configuration for:
• minislot size
• channel-width
• modulation profile
• Supports only ATDMA DOCSIS mode.

• The following features are not supported in MAC domains configured for D-PON:
• Load balancing
• Spectrum management
• Upstream configuration (to change upstream configuration, you should shut down the MAC domain)
• S-CDMA logical channels
• Lower modulations profiles (D-PON uses only 16 QAM and 64 QAM modulation profiles)
• Channel-width other than 3.2 MHz and 6.4 MHz
• In-service Software Upgrade (ISSU)
• Mixing of D-PON and HFC on the same MAC domain
• Software licensing
513
Information About Upstream Bonding Support for D-PON
Information About Upstream Bonding Support for D-PON

D-PON is a type of networking that allows the CMTS to transmit RF signals over the optical network. This
technology enables the cable operators to use the RF technologies in a Hybrid Fiber-Coaxial (HFC) network.
The downstream data from the CMTS is combined with other RF signals at the hub and is sent to the transmitter.
The signal from the transmitter is intended for multiple PONs. Each PON serves 32 homes from a single fiber.
The upstream data from the Optical Network Terminal (ONT) is combined at the splitter and sent to the hub,
which is then routed to the optical receiver (RX). Upstream data from multiple optical receivers are combined
and sent to the CMTS.
The upstream data to the CMTS contains signals from multiple PONs. Each upstream optical receiver is
dedicated to a PON that can have multiple DOCSIS upstream sources (multiple modems and DSG terminals).
A PON can be configured in different ways, depending on the coaxial network. These configurations broadly
fall under the following categories:
• Internal Control Configuration—In this configuration, the internal CM of the ONT controls the laser.
Upstream signals go to the Ethernet interface of the CM allowing the ONT to control upstream timing.
The device that uses this type of configuration is the Digital Audio Visual Council (DAVIC) set top
terminal (STT).
• External Control Configuration—In this configuration, the presence of the RF at the ONT upstream input
activates the laser. The device that uses this type of configuration is the DOCSIS Set-top Gateway (DSG)
device.
• Dual Control Configuration—In this configuration, the home that contains an ONT with and internal
CM and other DOCSIS upstream sources, like DSG devices. The RF presence detector or the internal
CM control line detects the upstream signal and activates the upstream laser.
D-PON on Upstream Scheduling

In D-PON implementation, the native upstream scheduling software of the CMTS controls the timing of the
upstream data transmission. Only one PON Receiver Domain (PRD) is allowed to transmit upstream data at
any given point of time, irrespective of the upstream frequency allocation. The reason for this is that two lasers
from the ONT of a PRD cannot work simultaneously as it leads to an Optical Beat Interference (OBI). Moreover,
the use of a frequency modulation (FM) for and upstream signal transmission results in PHY errors when
multiple ONTs within a PON transmits simultaneously.
Initial maintenance regions are scheduled on all upstream channels to prevent the DOCSIS 3.0 CMs in a
D-PON environment from failing initial ranging on any upstream channel. When a ranging request is received
within a MAC domain configured for D-PON, the CM receives an upstream channel override to the D-PON
reference channel (US0).
In this implementation of D-PON, a DOCSIS device within a PRD is given a timeslot to transmit the upstream
data, irrespective of the upstream frequency. Therefore, there is no benefit in having more than one upstream
in a MAC domain without using the upstream channel bonding feature.
The D-PON feature supports the following service types:
• Best effort (BE) 3.0 using up to four frequencies concurrently
• BE 2.0 using only a single frequency
• Unsolicited grant service (UGS) using only a single frequency
514
How to Configure Upstream Bonding Support for D-PON
• Real-time polling service (RTPS) using only a single frequency

• Non-real-time polling service (nRTPS) using only a single frequency
How to Configure Upstream Bonding Support for D-PON

This section describes how to enable D-PON for a MAC domain on the Cisco cBR router. The bonding group
must include a reference channel which is default to the upstream channel 0.
Note The USCB can support a maximum of 4 US channels in a RFOG MAC domain in the following combination:
• US0
• US0, US1
• US0, US1, US2
• US0, US1, US2, US3
All US channels must be configured to have the same number of minislots, channel width (only 3.2 and 6.4
MHz supported), DOCSIS mode (only ATDMA supported) and modulation profile.
When enabling DPON on a MAC Domain, remove the command "cable upstream balance-scheduling? as
DPON is not supported with upstream balance-scheduling.
Procedure

prompted.
Example:
Router> enable

Example:
Step 3 interface cable slot/subslot/cable-interface-index Enters interface configuration mode for the specified cable
interface.
Example:
Step 4 cable upstream dpon Enables D-PON for a MAC domain.

Example:
Router(config-if)# cable upstream dpon
Step 5 shutdown Shuts down the interface.

Example:
Router(config-if)# shutdown
515
Verifying the Upstream Bonding Support for D-PON

Step 6 no shutdown Enables the interface.
Example:
Step 7 end Exits interface configuration mode and returns to the

Example:
Verifying the Upstream Bonding Support for D-PON

To verify the upstream scheduler output for a MAC domain configured with D-PON, use the show interface
cable mac-scheduler command.
Note The D-PON reference channel US0 (US channel-id 1) MAP serves as a template for producing other MAPs
within the MAC domain. Therefore, some of the statistics related to upstream scheduling is not relevant for
other channels, except for the D-PON reference channel.
Router# show interface cable 8/0/0 mac-scheduler 1

wfq:None
us_balance:OFF
dpon_mode:ON
fairness:OFF
Req Slots 1824595508, Req/Data Slots 10640906
Init Mtn Slots 89924653, Stn Mtn Slots 989543
The following sections provide references related to the Upstream Bonding Support for D-PON feature.
516
Feature Information for Upstream Bonding Support for D-PON
Related Documents
Prisma D-PON Cisco Prisma D-PON
Description Link
ID and password.

Table 87: Feature Information for Upstream Bonding Support for D-PON
Upstream Bonding Support for Cisco IOS XE Fuji This feature was integrated on the Cisco cBR
D-PON 16.7.1 Series Converged Broadband Routers.
517
518
CHAPTER 30
Energy Management Mode
Data-over-Cable Service Interface Specifications (DOCSIS) cable modems (CM) and CMTS support a low
power energy mode referred to as the Energy Management 1x1 (EM) mode. During idle times, when the data
rate demand of a user is met by the available capacity on a single upstream and downstream channel pair to
which it is assigned, the CM switches to the Energy Management 1x1 mode. When the CM requires a higher
data rate than that can be reliably provided on the single channel pair, the CMTS instructs the CM to return
to the larger transmit and receive channel set.
Contents
• Information About Energy Management Mode, on page 519
• Prerequisites for Energy Management Mode, on page 523
• Restrictions for the Energy Management Mode, on page 523
• How to Configure the Energy Management Mode, on page 526
• Verifying the Energy Management Mode, on page 527
• Feature Information for Energy Management Mode, on page 530
Information About Energy Management Mode

The following sections provide more information about the Energy Management mode.
Note DOCSIS 3.1 CM’s do not support the Energy Management mode in cBR-8 routers.
Dynamic Downstream Bonding Group

To support the Energy Management 1x1 (EM) mode feature, CMTS selects an upstream and a downstream
channel pair for CM. The downstream and upstream channel assigned to the CMs should be available. If
CMTS selects a channel that is not available, the downstream bonding channel might fail.
To simplify the process, CMTS chooses the 1x1 bonding group for the CM according to the following rules:
• For upstream, it chooses the highest actual amiable bandwidth channel from the upstream channels
currently used by the CM.
• For downstream, CMTS chooses the current primary downstream channel used by the CM.
519
Flow Chart of the CM Power State
• If the CM is online with channel bonding 1xN or Nx1, and requests to enter into the EM mode, CMTS
does not change the upstream and the downstream channel if the original channel bonding is 1 and the
Quality of Service (QoS) parameter is not updated.
• CMTS checks the existing dynamic bonding groups (DBG), for an exact match in the target channel.
• If found, CMTS uses this bonding group to instruct the CM to enter into EM mode.
• If there is no available DBG and there is an unused DBG, CMTS adds the primary channel into the
unused DBG and instructs the CM to enter the EM mode.
• If there is no available DBG and no unused DBG, CMTS logs a warning to notify you that a new
DGB should be configured.
Flow Chart of the CM Power State

The following figure shows the flow chart of the CM power state:
520
Interaction with the Battery Mode
Figure 21: Flow Chart for the Power State of the Cable Modem

Energy management mode is similar to battery mode as they both enter the 1x1 mode to save power. But,
both have a different purpose to enter the 1x1 mode, so there are some differences in their behavior. The
purpose of EM mode is to save power when the traffic is low, and it has minimum impact on the normal
service. The purpose of the battery mode is try to guarantee the voice service, especially the 911 call service,
for which it may drop other services, if necessary.
The table below describes the behavior difference between energy management mode and battery mode.
521
Energy Management (EM) Mode Battery Mode (BM)
QoS Minimum reserved rate service up No minimum reserved rate.

to 200k.
Multicast • IGMP request is guaranteed. • If the CM has joined IGMP

groups and CMTS receives a
• If the CM has joined the CM-STATUS event with code
Internet Group Management 9, CMTS lets the CM leave
Protocol (IGMP) groups, the IGMP group.
CMTS rejects the EM request
to enter the EM mode and • If the CM is in the BM, CMTS
keeps the CM in the IGMP rejects the IGMP join request
groups. from the CM.
• If the CM is in the EM mode
and IGMP join request is
received, CMTS instructs the
CM to leave the EM mode.
BM has higher priority than the EM mode. If a CM is already in EM mode and a power off occurs, CM enters
into the BM. After the power is restored, the CM returns to the normal mode, and if the traffic is lower than
the threshold, it re-enters the EM mode. The CM does not directly transfer from the BM to the EM mode.
The interaction between the battery mode and the energy management mode is illustrated in the figure below:
Figure 22: Interaction Between the BM and the EM Modes
1. When the CM is in normal mode and CMTS receives a request to enter the EM mode, CMTS instructs
the CM to enter the EM mode with downstream bonding channel (DBC).
2. When the CM is in EM mode and CMTS receives a request to leave the EM mode, CMTS instructs the
CM to leave the EM mode to normal mode with DBC.
3. When the CM is in normal mode and CMTS receives a message: CM operating on battery backup, CMTS
instructs the CM to enter the BM mode with DBC.
4. When the CM is in BM mode and CMTS receives a message: CM operating on AC power, CMTS instructs
the CM to leave the BM mode to normal mode with DBC.
522
Handling Energy Management Request Load
5. When the CM is in EM mode and CMTS receives a message: CM operating on battery backup, CMTS
instructs the CM to enter the BM mode with service flow re-admin.
6. When the CM is in BM mode and CMTS receives a request to enter EM mode, CMTS waits until it
receives the message: CM operating on AC power. It then instructs the CM to return to normal mode.
Handling Energy Management Request Load

When many CMs send EM requests at the same time, such as at the beginning or end of work hours, the traffic
soars or slumps in a very short period and causes heavy load for CMTS. A throttle mechanism is adopted to
avoid such load surge for CMTS.
The line card EM process defines a variable that indicates the current transactions handled by the process.
When an energy management request is received and the maximum number of transactions is not met, CMTS
handles this request and updates the counter of current transactions. When the maximum number of transactions
is met, CMTS sends a temporary reject response. After a transaction is over or a CM goes offline, the counter
of current transactions is updated.
Supervisor High Availability and Line Card Switchover

Energy Management feature supports supervisor high availability and line card switchover with limitations.
The active supervisor or line card syncs the EM mode data of a CM to the standby SUP or protected line card
when the CM enters a stable EM status. When a CM enters or leaves the EM mode with an ongoing DBC
process, the supervisor high availability or line card switchover causes the CM to enter into an offline or
online status.
Prerequisites for Energy Management Mode

To enable the energy management mode, you must configure resiliency bonding group (RBG) and dynamic
bonding group.
Restrictions for the Energy Management Mode

Restrictions for CMTS High Availability
• If there is no DBG available, CMTS cannot create a new DBG on the protected line card and CMs cannot
enter the EM mode.
• Line card switchover is not supported when the CM enters the EM mode from the normal mode or exits
the EM mode to the normal mode.
• To reduce the operation of the EM mode, the information about the EM status is not synced with the
protected line card. Hence, the EM status is cleared after the line card high availability.
523
Restrictions for Dynamic Bonding Group
Restrictions for Dynamic Bonding Group

To support the EM feature, CMTS configures separate DBG for each primary channel in each MAC domain.
For example, if a MAC domain has eight primary channels, it will create eight DBGs for the MAC domain.
This ensures that the EM does not fail due to lack of DBGs.
Restrictions for Interaction of CMTS with Other Features

The following sections describe the restrictions for CMTS interaction with other features.
Voice
If a voice call is in progress, CMTS does not instruct the CM to enter into the EM mode.
When the CM is in the EM mode, and it receives a voice call, it adds a dynamic Unsolicited Grant Service
(UGS) or Unsolicited Grant Service with activity detection (UGS-AD) service flow. During the voice call,
the CM does not exit from the EM mode irrespective of the flow of traffic. Voice service is given the highest
priority
Dynamic Bonding Change and Dynamic Channel Change and Related Applications
In D2.0 and D3.0 load-balance (static and dynamic), CM is not moved by load-balance when it is in EM mode.
For RF-adapt, CM is not relocated to an alternate logical channel by the RF-adapt when it is in EM mode.
Multicast
• When the CM is in a multicast group, CMTS would reject the EM request for both bonded and non
bonded multicast cases.
• When the CM is in EM state and a multicast join request is received, CMTS discards this join request
and forces the CM to exit the EM mode.
• When the CM is in EM state and a voice call is in progress, and a new multicast join request is received,
CMTS discards this join request and does not force the CM to exit the EM mode since the voice call is
in progress.
• There is a threshold for currently handled transactions. When there is multicast join request and the
maximum transaction threshold has been reached, CMTS cannot instruct the CM to exit the EM mode.
The multicast join is also be denied until the CM can exit the EM mode.
• When the CM is in EM mode and needs to join PacketCable Multimedia (PCMM) multicast, you should
send a GateSet request twice, so that the gate can be setup successfully. The first GateSet request only
forces the modem to exit the EM mode, but does not set up the gate
Committed Information Rate

If the QoS is defined by the Minimum Reserved Rate service flow QoS parameter in excess of 200 kbps,
when the CM enters into the EM mode, CMTS only provides 200 kbps as the minimum reserved rate. If the
minimum reserved rates is less than 200 kbps, CMTS schedules the minimum reserved rate according to the
service flow configuration when the CM enters into the EM mode.
CMTS records the Minimum Reserved Rate service flow QoS parameter when the CM enters into the EM
mode. When the CM exits the EM mode, CMTS uses the original parameter.
524
Admission Control
When the CM enters the EM mode, it selects one of the CM upstream channels. If the service flow is completely
on that upstream channel, the service flow parameter is not changed. This behavior is because the service
flow is not moved into the DBC operation, and the change of the service flow parameter has no benefit
Admission Control
When a request is received to exit the EM mode and recovery to the original wideband interface is restricted
due to an admission control failure, CMTS forces the CM to go offline and re-register to prevent it from
getting stuck in the EM mode. In such a case, CMTS logs a warning message.
Battery Mode
When CMTS receives the status of the CM as operating on battery power, CMTS instructs the CM to enter
into the BM. If the CM rejects the instruction received, CMTS keeps the modem in normal status.
When the CM is in BM and CMTS receives the status of the CM as operating on A/C power, CMTS instructs
the CM to exit the BM. If the CM rejects the instruction received, CMTS forces the CM to go offline to prevent
it from getting stuck in the battery mode. In such a case, CMTS logs a warning message.
Attribute Mask
When selecting an upstream or a downstream channel pair for energy management mode, CMTS selects
channels that meet the requirements of the attribute masks for the existing service flows for the corresponding
CM.
In some cases, adherence to the service flow attribute-based assignment may not be possible when selecting
an upstream and downstream channel pair for energy management mode of operation. To resolve this conflict,
CMTS supports one or both of the following approaches:
1. CMTS may require strict adherence to the required and forbidden attribute masks and thus deny entry
into the EM mode if these masks cannot be met by the available individual channels in the MD-CM-SG.
2. CMTS may allow the CM to enter the EM mode while not meeting all the criteria for the attribute masks.
In this case, CMTS logs a warning event notifying that the attribute masks are not maintained.
For the following case, CMTS supports approach two:

When the CM is instructed to enter into the EM mode and the selected target upstream and downstream
channels do not adhere to the service flow attribute mask. For this conflict CMTS instructs the modem to
enter into the EM mode. CMTS also logs a warning message to notify this conflict.
Dynamic Service Addition

When the CM is in EM mode, DSA request can still be set up even if the requested attributes can not be met
with a single channel. In order to not effect voice services, the CM is not forced to exit the EM mode.
Restrictions for Configuration Change and Interface Shutdown

1. Shutdown of the upstream channel—Shutdown of the upstream channel recalculates the MD-US-SG-ID
and assigns a new MD-US-SG-ID. In this case, the CM is not offline and internal data structure of the
CM instance is not updated. DBC operation checks the MD-US-SG-ID, so when the CM enters into the
EM mode there is a mismatch between the MD-US-SD-ID on the CM and the new MD-US-SG-ID. Hence,
DBC fails and the CM cannot get into the EM mode.
525
How to Configure the Energy Management Mode
2. Change in Upstream Service Group makes the CM in EM mode go offline—The US-SG configuration
change blocks the DBC behavior and the CM gets stuck in the EM mode. To avoid this scenario, when
there is a change in the Upstream Service Group (US-SG), such as shutdown or no shutdown of the
upstream channels, CMTS makes the CM go offline. The CM should re-register as a normal CM with the
wideband channel bonding including multiple channels.
3. Modify the original wideband interface—When the CM is in EM mode, change in the original wideband
interface channels on the CM makes the CM go offline and re-register as a normal CM.
4. Disable or enable feature— When you disable this feature, CMTS does not force CMs to exit from the
EM mode unless CMs sends a request. CMTS does not accept EM requests after the EM feature is disabled
from the CLI.
How to Configure the Energy Management Mode

This section describes how to configure the energy management feature on the Cisco cBR-8.
Contents
Enabling Energy Management Mode

To enable the energy management mode, complete the following procedure:
configure terminal
cable reduction-mode energy-management enable
Verifying the Energy Management Mode

• To verify if the CM is in EM mode, use the show cable modem command. If the cable modem is working
in energy management mode, the MAC state is displayed with an "em" flag.
show cable modem
D
MAC Address IP Address I/F MAC Prim RxPwr
Timing Num I
State
Sid (dBmv) Offset CPE P
7cb2.1b0f.ea72 40.4.58.4 C7/0/0/UB w-online(em) 2 0.00
1231 1 Y
54d4.6ffb.2f6b 40.4.58.24 C7/0/0/UB w-online 3 -0.50
1241 0 Y
0025.2ed9.9a22 40.4.58.3 C7/0/0/UB w-online 4 0.50
1240 0 Y
• To verify which CM is in EM mode and to get the original wideband and upstream channel information,
use the show cable modem reduction-mode energy-management-mode command.
show cable modem reduction-mode energy-management-mode
Orig BG Orig US Curr BG
I/F MAC Address ID I/F bitmap RFs ID I/F
Upstream
------- -------------- ---------------- -------- -----------------------------------------
C7/0/0 0025.2eaf.843e 897 Wi7/0/0:0 0x3B 4 252 Wi7/0/0:1 US0
526
Enabling Energy Management Mode per MAC Domain
C7/0/0 0025.2eaf.8356 897 Wi7/0/0:0 0x3B 4 252 Wi7/0/0:1 US0
C7/0/0 0015.d176.5199 897 Wi7/0/0:0 0x3B 4 252 Wi7/0/0:1 US0
Enabling Energy Management Mode per MAC Domain

CMTS supports the EM feature when enabled both globally and per MAC domain. Use the following procedure
to enable energy management feature per MAC domain.
To enable the EM mode per MAC domain, complete the following procedure:
configure terminal
interface cable slot/subslot/cable-interface-index
cable reduction-mode energy-management enable
Configuring Initialization Ranging Technique in Dynamic Bonding Channel

The default value for the technique in init-ranging is set to 1 and the valid range is 1-4.
To configure the technique in init-ranging, complete the following procedure:
configure terminal
cable reduction-mode energy-management ranging-init-techniquevalue
Configuring the Percentage for the Dynamic Channel Bandwidth

Make sure that you leave enough bandwith for the primary channel so that it can allocate dynamic channel
bandwidth when it joins to a newly created DBG. The default percentage value is set to 5 and the valid range
is 1-96.
To configure the percentage of dynamic channel bandwidth, complete the following procedure:
configure terminal
cable reduction-mode energy-management dynamic-channel-percent value
Configuring the Queue Size for Energy Management

The default value for the queue size is set to 150 and the valid range is 50-10000.
To set the queue size of the energy management requests, complete the following procedure:
configure terminal
cable reduction-mode energy-management process-queue-size value
Verifying the Energy Management Mode

This section describes how to verify the EM mode.
527
Viewing the Basic Statistics for Energy Management Receive Request
Contents
Viewing the Basic Statistics for Energy Management Receive Request

To view the basic statistics for all energy management receive request events for a specific CM, use the show
cable modem <cable if | mac_addr | ip_addr> reduction-mode energy-management-status command.
show cable modem c8/0/0 reduction-mode energy-management-status
I/F MAC Address Event TID Count Error Dups Time

C8/0/0 54d4.6ffb.2e21 Enter EM mode 1 1 0 1 Jul 16 21:38:18
Exit EM mode 1 1 0 0 Jul 16 21:38:39
C8/0/0 602a.d07c.4ec6 Enter EM mode 1 1 0 0 Jul 16 21:40:57
Exit EM mode 1 1 0 0 Jul 16 21:41:17
To clear the basic receive statistics for all EM_REQ events for a specified CM, use the clear cable modem
<cable if | mac_addr | ip_addr> em-status command.
Verifying the Configuration Parameters

To verify the configuration parameters used in the CM configuration file, use the show cable modem <mac
address> reduction-mode energy-management-param command.
show cable modem 54d4.6ffb.2e21 reduction-mode energy-management-param
Energy Management feature enable : Y

DS entry bitrate threshold(bps) : 100000
DS entry time threshold(s) : 120
DS exit bitrate threshold(bps) : 200000
DS exit time threshold(s) : 2
US entry bitrate threshold(bps) : 100000
US entry time threshold(s) : 120
US exit bitrate threshold(bps) : 200000
US exit time threshold(s) : 2
cycle period(s) : 300
Viewing Information Regarding a Cable Modem

To view all the information regarding a CM, use the show cable modem mac address verbose command.
show cable modem 54d4.6ffb.30fd verbose
MAC Address : 54d4.6ffb.30fd
IP Address : 40.4.58.14
IPv6 Address : 2001:40:4:58:741A:408D:7E4B:D7C8
Dual IP : Y
Prim Sid : 9
MD-CM-SG : 0x3C0101
Primary Downstream : In7/0/0:2 (RfId : 722)
RCP Index : 3
RCP ID : 00 10 00 00 08
528
Viewing Information Regarding a Cable Modem

Upstream Channel : US0 US1
Ranging Status : sta sta
Upstream SNR (dB) : 36.12 32.55
Upstream Data SNR (dB) : -- --
Received Power (dBmV) : 0.00 0.00
Reported Transmit Power (dBmV) : 25.25 26.00
Peak Transmit Power (dBmV) : 54.00 54.00
Phy Max Power (dBmV) : 54.00 54.00
Minimum Transmit Power (dBmV) : 24.00 24.00
Timing Offset (97.6 ns): 1226 1226
Initial Timing Offset : 1229 973
Rng Timing Adj Moving Avg(0.381 ns): -1 0
Rng Timing Adj Lt Moving Avg : -7 0
Rng Timing Adj Minimum : -768 0
Rng Timing Adj Maximum : 0 64768
Pre-EQ Good : 0 0
Pre-EQ Scaled : 0 0
Pre-EQ Impulse : 0 0
Pre-EQ Direct Loads : 0 0
Good Codewords rx : 515 472
Corrected Codewords rx : 0 0
Uncorrectable Codewords rx : 0 0
Phy Operating Mode : atdma* atdma*
sysDescr :
Modem Status : {Modem= w-online(em), Security=disabled}
CFG Max-CPE : 200
Flaps : 0()
LB policy ID : 0
LB priority : 0
Tag :
Service Type ID :
529
Feature Information for Energy Management Mode

Voice Enabled : NO
DS Change Times : 0
CM Energy Management Capable : Y
CM Enable Energy Management : Y
CM Enter Energy Management : YES
CM Initialization Reason : NO_PRIM_SF_USCHAN
Feature Information for Energy Management Mode

Table 88: Feature Information for Downgrading Channel Bonding in Battery Backup Mode
Energy Management Mode Cisco IOS XE Fuji This feature was integrated on the Cisco cBR Series
530
CHAPTER 31
Cable Modem Steering
The cable modem steering feature helps to redirect or steer cable modems to multiple CMTS routers. A
configurable string is used to bond the cable modem to the proper CMTS. Once the bonding is done, the
CMTS can move the cable modem within itself for load balancing.
• Cable Modem Steering on the Cisco cBR Series Converged Broadband Routers, on page 531
• Prerequisites for Cable Modem Steering, on page 532
• Restrictions for Cable Modem Steering, on page 532
• Information About Cable Modem Steering, on page 532
• How to Configure Cable Modem Steering on the CMTS Router, on page 534
• Verifying and Troubleshooting Cable Modem Steering, on page 536
• Feature Information for Cable Modem Steering, on page 539
Cable Modem Steering on the Cisco cBR Series Converged

Broadband Routers
First Published: July 13, 2016
The cable modem steering feature helps to redirect or steer cable modems to multiple CMTS routers. A
configurable string is used to bond the cable modem to the proper CMTS. Once the bonding is done, the
CMTS can move the cable modem within itself for load balancing.
531
Prerequisites for Cable Modem Steering
Contents
Prerequisites for Cable Modem Steering

DOCSIS 3.0-defined type, length, values (TLVs) are required to aid channel selection. All TLVs encoded as
general extension information in cable modem configuration files are backward compatible with DOCSIS
1.1 and DOCSIS 2.0 cable modems.
Note The hardware components introduced in a given Cisco IOS Release are supported in all subsequent releases
unless otherwise specified.
Restrictions for Cable Modem Steering

The Cable Modem Steering feature has the following general restrictions:
• To restrict the cable modem on the exact downstream on the target CMTS, the redirection must be
configured on the target CMTS.
• You must manually execute the clear cable modem service-type command to clear the cable modem
service type identifier stored at the CMTS during registration.
• You must manually execute the clear cable modem attribute-masks command to clear the cable modem
attribute masks stored at the CMTS during registration. These attribute masks are used to restrict usage
of upstream channels during ranging time.
• Cable modem steering supports only upstream masks.
• Channel steering does not take place when the cable modem fails in initial ranging.
• The cable modem will take more time to come online when channel steering is deployed. The time taken
is proportional to the number of modems, and the downstreams and upstreams that the cable modem can
reach.
• A modem cannot be load balanced to any upstream channel with attributes that conflict with attribute
masks of the modem.
• Do not configure to use UCC in DOCSIS LBG.
Information About Cable Modem Steering

Cable modem steering allows you to redirect or steer the cable modems to one or more CMTS routers using
downstream frequency overrides. Once a cable modem registers on a downstream on the proper CMTS router,
the CMTS router can move the cable modem to any location for load balancing.
The DOCSIS 3.0-compliant Service Type Identifier used as the configurable string in the cable modem
configuration file is backward-compatible with DOCSIS 1.1 and DOCSIS 2.0 cable modems.
The CMTS router can also impose restrictions on the number of channels a cable modem can use. DOCSIS
3.0 defines several TLVs to aid the channel selection.
The following TLVs are used in cable modem steering:
532
Upstream Channel Descriptor TLV for Ranging Hold-off
• TLV 43.9 (Cable Modem Attribute Masks) limits the set of channels the CMTS router can assign to the
cable modem by allowing or forbidding certain binary attributes. The cable modem attribute masks have
four sub-TLVs and cable modem steering makes use of two sub-TLVs, which are listed below:
• TLV 43.9.3—Cable Modem Upstream Required Attribute Mask (C.1.1.18.1.8.3 of
CM-SP-MULPIv3.0-I07-080215). It is a 32-bit mask representing the set of binary upstream channel
attributes required for the cable modem.
• TLV 43.9.4—Cable Modem Upstream Forbidden Attribute Mask (C.1.1.18.1.8.4 of
CM-SP-MULPIv3.0-I07-080215). It is a 32-bit mask representing the set of binary upstream channel
attributes forbidden for the cable modem.
• TLV 43.11 is used for a redirection action based on the service type identifier field. The cable modem
sends the TLV 43.11 in the REG-REQ MAC message. The DOCSIS 1.1 and DOCSIS 2.0 modems will
also send this file ID when doing the registration.
• TLV43.1, defined as Policy ID in DOCSIS 2.0 and DOCSIS 3.0, is parsed and stored in the cable modem
during registration. Before moving the cable modem during load balancing (LB), the CMTS router checks
whether the cable modem has a preconfigured policy with the same Policy ID. If the policy does exist,
the CMTS router disables LB for this cable modem and moves to the next cable modem. If the policy
does not exist on the CMTS router, or the Policy ID is missing from the cable modem configuration file,
LB prohibition is not performed.
The following TLVs are supported in cable modem steering:
• TLV 43.11 (Service type identifier) from section C.1.1.18.1.10 in CM-SP-MULPIv3.0-I07-080215.
• Cable modem attribute masks (TLV 43.9) from C.1.1.18.1.8.3 and C.1.1.18.1.8.4 of
CM-SP-MULPIv3.0-I07-080215.
• TLV portion (43.1, Policy ID) of REQ-REQ
• TLV 18--- Ranging Hold-off Priority Field
• TLV 19---Channel Class ID
Upstream Channel Descriptor TLV for Ranging Hold-off

The Upstream Channel Descriptor (UCD) TLV for Ranging Hold-off feature, enables the Cisco cBR Series
Converged Broadband router to hold off a cable modem from initial ranging based on TLV 18 and 19 specified
in the upstream channel descriptor (UCD) messages. The router can hold off a cable modem from initial
ranging only for 5 minutes. This default value cannot be changed. This feature is supported with DOCSIS 2.0
and later releases cable modems using upstream logical channels.
Ranging Class ID
The CMTS enables UCD TLV for ranging hold-off after detecting the TLVs from the cable modem registration
request (REG-REQ) or multipart registration request (REG-REQ-MP), and saves these TLVs as a cable
modem ranging class ID.
By default, DOCSIS load balance is supported for all cable modems with all types of ranging class IDs. In
the event of DOCSIS load balance, a cable modem moves to the target upstream channel only if the ranging
class ID matches with the upstream channel class ID.
Cable Modem Exclusion for DOCSIS Load Balance

You can exclude a cable modem or a group of cable modems from DOCSIS load balance based on their device
type, MAC address, and Organizational Unique Identifier (OUI) using the cable load-balance exclude
command in global configuration mode.
533
How to Configure Cable Modem Steering on the CMTS Router
How to Configure Cable Modem Steering on the CMTS Router

This section describes the following required and optional procedures:
Configuring an Upstream Channel Class ID

This configuration is optional. A channel class ID must be configured for an upstream logical channel if you
want to configure UCD TLV ranging hold-off on the CMTS router.
Procedure

Router> enable

Example:
Step 3 controller upstream-cable Specifies the cable interface and enters cable interface
slot/subslot/controller-port-number configuration mode. Arguments for this command may vary
depending on the CMTS router, line card, and Cisco IOS
Example:
software release. For details, see the Cisco IOS CMTS Cable
Router(config)# controller Upstream-Cable 3/0/0 Command Reference .
• Slot— Slot where the interface card resides. The valid
range is from 0 to 3 and 6 to 9 on the Cisco cBR-8
router.
• Subslot—Subslot where the interface card resides. The
valid value is 0 on the Cisco cBR-8 router.
• controller-port-number—Controller port number. The
valid values are from 0 to 7 on the Cisco cBR-8 router.
Step 4 us-channel us-channel-id chan-class-id id Configures the channel class ID for an upstream logical
channel.
Example:
Router(config-controller)# us-channel 3 • us-channel-id—Specifies the upstream channel id.
chan-class-id ff • id—Channel class ID for the logical upstream channel
in the hexadecimal format. The valid range is from 0
to ffffffff. The default value is 0.

Example:
534
Configuring an Upstream Ranging Hold-off Priority Value
Configuring an Upstream Ranging Hold-off Priority Value

This configuration is optional
Maximum time that a cable modem can inhibit transmissions on an upstream channel in response to its ranging
class ID matching a bit value in the Ranging Hold-off Priority field in the cable modem configuration file is
300 seconds (five minutes) per DOCSIS 3.0 MAC and Upper Layer Protocols Interface Specification . This
default timer value cannot be changed.
Procedure

Router> enable

Example:
Step 3 controller upstream-cable Specifies the cable interface and enters cable interface
slot/subslot/controller-port-number configuration mode. Arguments for this command may vary
depending on the CMTS router, line card, and Cisco IOS
Example:
software release. For details, see the Cisco IOS CMTS Cable
Router(config)# controller upstream-cable 3/0/0 Command Reference .
• Slot—Slot where the interface card resides. The valid
range is from 0 to 3 and 6 to 9 on the Cisco cBR-8
router.
• Subslot—Subslot where the interface card resides. The
valid value is 0 on the Cisco cBR-8 router.
• controller-port-number—Controller port number. The
valid values are from 0 to 7 on the Cisco cBR-8 router.
Step 4 us-channel us-channel-id rng-holdoff priority Configures the ranging hold-off priority value for an
upstream logical channel.
Example:
Router(config-controller)# us-channel 3 rng-holdoff • us-channel-id—Specifies the upstream channel id.
1 • rng-holdoff priority—Specifies the ranging hold-off
priority value in the hexadecimal format. The valid
range is from 0 to ffffffff. The default value is 0.

Example:
535
Verifying and Troubleshooting Cable Modem Steering
Verifying and Troubleshooting Cable Modem Steering

This section provides the verification and troubleshooting information:
Verifying an Upstream Ranging Class ID Configuration

To verify an upstream ranging class ID of a cable modem, use the show cable modem command with the
verbose keyword.
Following is a sample output of the show cable modem verbose command:
Router# show cable modem 68b6.fcfe.22e5 verbose
MAC Address : 68b6.fcfe.22e5

IP Address : 192.168.0.8
IPv6 Address : 2001:DB8:10:1:9951:1972:33F9:9867
Dual IP : Y
Prim Sid : 8
MD-CM-SG : 0x5A0102
Primary Downstream : Mo8/0/0:0 (RfId : 2304)
RCP Index : 3
RCP ID : 00 10 00 00 18
UDC Enabled : N
Number of US in UBG : 8
Upstream Channel : US0 US1 US2 US3
Ranging Status : sta sta sta sta
Upstream SNR (dB) : 30.62 32.32 18.25 24.26
Upstream Data SNR (dB) : -- -- -- --
Received Power (dBmV) : 0.50 0.00 -0.50 -0.50
Reported Transmit Power (dBmV) : 30.75 30.75 29.25 29.25
536
Verifying an Upstream Ranging Class ID Configuration
Peak Transmit Power (dBmV) : 61.00 61.00 61.00 61.00

Phy Max Power (dBmV) : 48.00 48.00 48.00 48.00
Minimum Transmit Power (dBmV) : 21.00 21.00 21.00 21.00
Timing Offset (97.6 ns): 1800 1800 1800 1800
Initial Timing Offset : 1544 1544 1544 1544
Rng Timing Adj Moving Avg(0.381 ns): -1 0 -1 -1
Rng Timing Adj Lt Moving Avg : -7 0 -7 -7
Rng Timing Adj Minimum : -256 0 -256 -256
Rng Timing Adj Maximum : 65536 65536 65536 65536
Pre-EQ Good : 0 0 0 0
Pre-EQ Scaled : 0 0 0 0
Pre-EQ Impulse : 0 0 0 0
Pre-EQ Direct Loads : 0 0 0 0
Good Codewords rx : 1201 1262 833 656
Corrected Codewords rx : 0 0 169 117
Uncorrectable Codewords rx : 0 0 205 335
Phy Operating Mode : atdma* atdma* atdma* atdma*
Upstream Channel : US4 US5 US6 US7
Ranging Status : sta sta sta sta
Upstream SNR (dB) : 15.53 31.62 31.1 31.87
Upstream Data SNR (dB) : -- -- -- --
Received Power (dBmV) : 0.00 0.00 -0.50 0.50
Reported Transmit Power (dBmV) : 29.25 30.75 30.75 30.75
Peak Transmit Power (dBmV) : 61.00 61.00 61.00 61.00
Phy Max Power (dBmV) : 48.00 48.00 48.00 48.00
Minimum Transmit Power (dBmV) : 21.00 21.00 21.00 21.00
Timing Offset (97.6 ns): 1800 1800 1800 1800
Initial Timing Offset : 1544 1800 1544 1544
Rng Timing Adj Moving Avg(0.381 ns): -1 -1 46 0
Rng Timing Adj Lt Moving Avg : -7 -7 104 0
Rng Timing Adj Minimum : -256 -256 0 0
Rng Timing Adj Maximum : 65536 256 65536 65536
Pre-EQ Good : 0 0 0 0
Pre-EQ Scaled : 0 0 0 0
Pre-EQ Impulse : 0 0 0 0
Pre-EQ Direct Loads : 0 0 0 0
Good Codewords rx : 718 1328 1173 1252
Corrected Codewords rx : 110 0 0 0
Uncorrectable Codewords rx : 298 0 0 0
Phy Operating Mode : atdma* atdma* atdma* atdma*
sysDescr : DOCSIS 3.0 Cable Modem Router
Downstream Power : 7.40 dBmV (SNR = 43.30 dB)
Modem Status : {Modem= w-online, Security=disabled}
L2VPN Capabilities : {L2VPN=Y, eSAFE=Y}
Optional Filtering Support : {802.1P=N, 802.1Q=N, DUT=Y}
Number of CPE : 0(Max CPE = 16)
Number of CPE IPv6 : 0(Max CPE IPv6 = 16)
CFG Max-CPE : 16
Flaps : 19(Oct 11 04:00:25)
537

LB policy ID : 0
LB priority : 0
Tag :
Service Type ID :
Ranging Class ID : 0x2
Voice Enabled : NO
DS Change Times : 0
CM Initialization Reason : BAD_DHCP_ACK
The following sections provide references related to the Cable Modem Steering feature.
Related Documents
CMTS cable commands Cisco IOS CMTS Cable Command Reference
Standards and RFCs
Standard Title
CM-SP-MULPIv3.0-I07-080215 DOCSIS 3.0 MAC and Upper Layer Protocols Interface Specification
CM-SP-MULPIv3.0-I18-120329 DOCSIS 3.0 MAC and Upper Layer Protocols Interface Specification
CM-SP-RFI2.0-I13-080215 DOCSIS 2.0 Radio Frequency Interface Specification
538
Feature Information for Cable Modem Steering
Description Link


Table 89: Feature Information for Cable Modem Steering on the Cisco CMTS Routers
Cable Modem Steering Cisco IOS XE Everest This feature was integrated into Cisco IOS XE Everest
16.6.1 16.6.1 on the Cisco cBR Series Converged Broadband
Routers.
539
540
CHAPTER 32
DOCSIS Predictive Scheduler
This chapter describes how to configure the DOCSIS Predictive Scheduler (DPS) on the Cisco cBR Series
• Information about DOCSIS Predictive Scheduler, on page 541
• Configuring DPS on Cable Interface, on page 542
• Displaying DPS Grants on Upstream Channel, on page 542
• Displaying DPS Grants for Cable Modem, on page 542
• Displaying Upstream Utilization, on page 543
• Displaying Upstream Capacity Reserved for Contention Minislot, on page 545
• DOCSIS Predictive Scheduler Best Practices, on page 545
• Feature Information for DOCSIS Predictive Scheduler, on page 546
Information about DOCSIS Predictive Scheduler

DOCSIS Predictive Scheduler (DPS) is a scheduling technique to reduce the DOCSIS upstream latency by
predictively allocating unsolicited grants to active service flows.
When enabled, DPS provides benefits to bonded service flows with scheduling service of type Real-Time
Polling Service (rtPS), Non-Real-Time Polling Service (nrtPS), and Best Effort (BE).
DPS automatically identifies:
• service flows to which to issue predictive grants
• size of the grants to send
• when to send the grants
Predictive grants are sent after honoring all bandwidth requests received by the CMTS. DPS relies on
unallocated MAP capacity to issue predictive grants. Therefore, the less upstream capacity is utilized, the
more predictive grants that DPS can issue, and vice-versa.
The upstream latency improvements depend on several factors, such as the difference between the service
flow's upstream bitrate and its max-rate, the congestion in the upstream channels, and the predictability of the
traffic. In the best-case scenario, latency reductions of 66% are achievable due to a reduction of the request-grant
delay from approximately three times the one-way propagation delay to one times the one-way propagation
delay. Reductions on the upstream latency translate into upper layer performance improvements depending
on the upper layer protocols. For example, reducing the upstream latency in the DOCSIS link may improve
the TCP upstream and downstream throughput.
541
Configuring DPS on Cable Interface
DPS is enabled on per MAC domain basis, and should be configured to issue predictive grants only on the
SCQAM channels.
Configuring DPS on Cable Interface

Use the following steps to configure DPS on a MAC domain:
enable
configure terminal
interface cable slot/subslot/interface
cable upstream dps scqam-only
DPS configuration is also supported within a MAC domain profile. If you want to configure the number of
reserved minislots for contention, use the cable upstream min-bwreq-ops command on a per MAC domain
basis.
This is a configuration example:

Router> enable
Router(config)# interface Cable 7/0/1
Router(config-if)# cable upstream dps scqam-only
Router(config-if)# cable upstream min-bwreq-ops scqam 5 0
Displaying DPS Grants on Upstream Channel

To view the number of bytes granted by DPS on an upstream channel, use the show controller cable
slot/subslot/interface upstream upstream command as shown in the following example:
Router# show controller Cable 1/0/5 upstream 0 | include DPS
DPS Bytes Granted = 27595485909
Note DPS related counters are only displayed when DPS is configured.
Displaying DPS Grants for Cable Modem

DPS grants are issued on a per service flow basis. While a service flow may be allocated with more than one
SID, DPS always grants on the SID from the first SID cluster. To determine the service flows and the
corresponding SIDs for a given CM, use the show cable modem mac-address qos command as shown in the
following example:
Router# show cable modem 0000.0020.01c0 qos
State Type
173 US act 89 BE 6 64000 3044 0 0
2538 US act 1447 BE 1 120000000 50000 0 0
2539 US act 1449 BE 1 2200000 50000 0 0
174 DS act N/A N/A 6 64000 96000 0 0
2540 DS act N/A N/A 1 0 65536 0 0
542
Displaying Upstream Utilization
2541 DS act N/A N/A 1 99000000 10000000 0 0

2542 DS act N/A N/A 1 17600000 65536 0 0
To display the number of grants and granted bytes on a per service flow basis, use the show interface cable
slot/subslot/interface sid sid counter verbose command as shown in the following example (for SFID 173):
Router# show interface cable 1/0/5 sid 89 counter verbose
Sid : 89
Request polls issued : 0
BWReqs {Cont,Pigg,RPoll,Other} : 523, 10, 0, 0
Grants issued : 533
Packets received : 1066
Bytes received : 180576
Queue-indicator bit statistics : 0 set, 0 granted
Total Codewords rx : 2073
Good Codewords rx : 2073
Corrected Codewords rx : 0
Uncorrectable Codewords rx : 0
Concatenated headers received : 0
Fragmentation headers received : 0
Fragmentation headers discarded: 0
DPS grants : 0
DPS bytes granted : 0
Note Two DPS related counters are only displayed when DPS is configured.

There are three utilization metrics that can be used to assess the behavior of DPS:
• %data bytes (upstream capacity utilization by traffic): If t1 bytes were sent in the upstream, and the
upstream channel capacity was c1 bytes, then this term refers to t1/c1.
• %dps grants (upstream grants scheduled by dps): If g1 total grant opportunities exist within a map
interval, and d1 grants are issued by DPS, then this term refers to d1/g1.
• %data grants (total upstream grants scheduled): If g1 total grant opportunities exist within a map interval,
d1 grants are issued by DPS and b1 grants are issued due to bandwidth requests, then this term refers to
(d1 + b1)/g1.
To display the utilization rates on a per upstream channel basis for all three metrics above, use the show
interface cable slot/subslot/interface mac-scheduler command as shown in the following example.
Router# show interface cable 1/0/2 mac-scheduler
wfq:None
us_balance:OFF
dps:ON - SCQAM only
dpon_mode:OFF
fairness:OFF
<snip>
Avg upstream channel utilization(%data bytes) : 0%
543
Avg upstream channel utilization(%dps grants) : 46%

Avg upstream channel utilization(%data grants) : 46%
Avg upstream channel utilization in 30 sec : 0%
Avg percent guardband slots : 0%
<snip>

wfq:None
us_balance:OFF
dps:ON - SCQAM only
dpon_mode:OFF
fairness:OFF
<snip>
Avg percent guardband slots : 0%
Ruoter#show interface cable 1/0/2 mac-scheduler | incl utilization|rate
IUC: 5 rate: 195592784
IUC: 6 rate: 175962768
IUC: 9 rate: 156332752
IUC: 10 rate: 136702736
IUC: 11 rate: 117072712
IUC: 12 rate: 97442704
IUC: 13 rate: 77989528
IUC: 5 rate: 0
IUC: 6 rate: 0
IUC: 9 rate: 0
IUC: 10 rate: 219982848
IUC: 11 rate: 202211312
IUC: 12 rate: 179636656
IUC: 13 rate: 135928256
544
Displaying Upstream Capacity Reserved for Contention Minislot
Note Data grants based utilization is calculated every 0.5 second, whereas the data bytes based utilization is calculated
every 5 seconds for SCQAM channels and every 10 seconds for OFDMA channels.
Displaying Upstream Capacity Reserved for Contention Minislot

When DPS is enabled, some of the MAP capacity that was previously allocated for contention minislots is
now used to issue predictive grants.
To display how much of the upstream capacity is reserved for contention minislots, use the show interface
cable slot/subslot/interface mac-scheduler upstream map-stats | inc bwr command as shown in the following
example:
Router#show interface cable 8/0/2 mac-schedulder 0 map-stats | inc bwr
min_bwr_ops_pct 5.0, min_bwreq_mslot 8 sched min_bwreq_mslot 8
min_bwr_ops_pct represents the percent of the upstream capacity reserved for the contention minislots.
min_bwreq_mslot represents the equivalent number of minislots reserved for the contention minislots.
DOCSIS Predictive Scheduler Best Practices

MIBs
The CMTS derives the following two MIBs from the data grants allocated in MAPs:
• MIB docsIf31CmtsUsOfdmaChanUtilization: Recalculated every 5 seconds
• MIB docsIfCmtsChannelUtUtilization: Recalculated every 5 seconds
Both MIBs include DPS related grants.
Load Balancing
Load balancing uses data grant-based average calculated over a 30-second interval. This average includes the
DPS grants.
Contention Based Bandwidth Requests

Without DPS, as the CMTS adds more data grants in a MAP, the number of bandwidth request opportunities
in a MAP decreases. During busy times, this reduction can lead to an increase in upstream latency, either due
to collisions, a much larger back-off window (in time), or both.
DPS issues data grants in a MAP at the expense of bandwidth request opportunities. The worst case is when
an upstream channel is at full data grants, at which point there is only a single bandwidth request per MAP.
To avoid this situation’s potential negative effects, we recommend setting the minimum percentage of
contention-based bandwidth request opportunities to a non-zero value, e.g., 5%. Tuning may still be needed.
This is a configuration example for SC-QAM:
545
MAP Advance Time
Router> enable
Router(config-if)# cable upstream min-bwreq-ops scqam 5 0
This is a configuration example for OFDMA:

Router> enable
Router(config-if)# cable upstream min-bwreq-ops ofdma 5 0
MAP Advance Time

The use of DPS increases the MAP build time by up to 50 microseconds per MAP. This additional build time
accumulates for each MAP in a MAC domain (a maximum of 16) such that the last MAP can be transmitted
as much as 800 microseconds later (than without DPS). Thus, when using DPS, we recommend increasing
the MAP Advance parameter. Otherwise, some CMs may transition into partial mode due to late MAPs at
the CM, even though the same MAPs would arrive on time at the PHY.
When using dynamic MAP advance, increasing the safety factor from 1200 to 2000 microseconds and the
maximum MAP advance from 2000 to 2800 microseconds mitigated the extra MAP build time. Tuning may
still be needed.
This is a configuration example:
Router> enable
Router(config-if)# cable map-advance dynamic 2000 2800
Cable Modem Interoperability

DOCSIS 3.0 and above CMs are candidates for DPS granting. Some DOCSIS 3.0 CMs do not take advantage
of the DPS grants.
TaFDM
TaFDM and DPS are mutually exclusive and not supported together, since both of them strive to reuse unused
upstream capacity on the allocated spectrum.
Feature Information for DOCSIS Predictive Scheduler

546
Table 90: Feature Information for DOCSIS Predictive Scheduler
DOCSIS Predictive Cisco IOS XE Amsterdam This feature was integrated on the Cisco cBR
Scheduler 17.3.1w Series Converged Broadband Routers.
547
548
PA R T IV
• DOCSIS 3.1 OFDM Channel Configuration, on page 551
• OFDM Channel Power Profile, on page 565
• DOCSIS 3.1 Path Selection, on page 571
• DOCSIS 3.1 Downstream Profile Selection, on page 577
• DOCSIS 3.1 Commanded Power for Upstream SC-QAMs, on page 585
• DOCSIS3.1 Downstream Resiliency for OFDM channel, on page 591
• DOCSIS 3.1 OFDMA Channel Configuration, on page 597
• OFDMA OUDP Leak Detection Configuration, on page 617
• Time and Frequency Division Multiplexing Configuration, on page 637
• DOCSIS 3.1 Upstream Profile Selection, on page 643
• Proactive Network Management, on page 653
• Downstream Power Tilt, on page 687
• Controller Profile Configuration, on page 693
• Voltage Thresholds for AC Power Supply Module Mode Control, on page 701
• DOCSIS3.1 Downstream Zero Bit Loading, on page 707
• Reducing Power Consumption, on page 713
CHAPTER 33
DOCSIS 3.1 OFDM Channel Configuration
This document describes how to configure the OFDM channel on the Cisco cBR Series Converged Broadband
Router.
• Information about OFDM Channel Configuration, on page 553
• How to Configure OFDM Channel, on page 554
• Feature Information for DOCSIS 3.1 OFDM Channel Configuration, on page 563
551
Digital PICs:

Module:

Modules:
line card reload.
552
Information about OFDM Channel Configuration
Information about OFDM Channel Configuration

OFDM Channels
DOCSIS 3.1 introduces modes for higher throughput and higher spectral efficiency while still allowing
backward compatibility to DOCSIS 3.0. The OFDM Channel support includes two OFDM channel per port
with channel bandwidth from 24 MHz to 192 MHz wide.
From the Cisco IOS XE Gibraltar 16.10.1d release, the Cisco cBR router supports two OFDM channels per
service group for an RPD downstream port. You can configure the channels using the cable downstream
controller-profile configuration.
Cisco cBR-8 supports 158 SC-QAMs for a single OFDM channel and 128 SC-QAMs for multiple OFDM
channels. The max-carrier attribute is automatically set to 158 by default. However, you should set the
max-carrier to a value of 128 or below to configure multiple OFDM channels. The Cisco cBR router does not
support any value above 128 if you are configuring multiple OFDM channels.
Each OFDM channel supports a control profile, an NCP profile, and up to five data profiles. Profiles support
one or more modulations.
You can configure the guard band of an OFDM channel to potentially trade off some performance margin
using command guardband-override. By default, Cisco cBR-8 router use the default guard band, which is
based on the roll off and spacing in OFDM channel profile.
DOCSIS 3.1 OFDM support also allows the user to configure the RF-channels 158 to 162 under the mac-domain
as primary channel.
Channel Profile
A globally configured OFDM channel profile contains channel parameters, and the modulation or modulation
profile associated with the control, NCP, and data profiles.
Each OFDM channel must specify an OFDM channel profile in its configuration.
Modulation Profile
A globally configured OFDM modulation profile assigns different modulations to ranges of sub-carriers, or
lists of individual sub-carriers.
A modulation profile may be assigned to a control, NCP, or data profile in a channel profile.
OFDM Channel Exclusion Band

Ranges of frequencies can be excluded from all OFDM channels on a port using the ofdm-freq-excl-band
command.
553
How to Configure OFDM Channel
How to Configure OFDM Channel

Configuring OFDM Modulation Profile
To configure the OFDM modulation profile, follow the steps below:
enable
configure terminal
cable downstream ofdm-modulation-profile id
description text
subcarrier-spacing value
width value
start-frequency value
assign {modulation-default mod_prof_id | modulation mod_prof_id {list-subcarriers
{freq-abs | freq-offset} value | range-subcarriers {freq-abs | freq-offset}
value width value}}
Note Subcarrier spacing must match the subcarrier spacing of each channel profile in which it is configured.
Verifying OFDM Modulation Profile Configuration

To display the OFDM modulation profile details, use the show cable ofdm-modulation-profiles command
as shown in the example below:
Router# show cable ofdm-modulation-profile 10
**** OFDM Modulation Profile Configuration ****
Prof FFT Width Start-freq Modulations

ID KHz Hz Hz
10 50 96000000 627000000 64 default
512 freq-abs 709050000 width 12000000
2048 freq-abs 629000000 width 6000000
Profile Subcarrier Modulations

Modulation: Start-freq-abs[start-sc] - End-freq-abs[end-sc] Width-freq[num-sc]
64 : 572600000[ 0] - 626950000[1087] 54400000[1088]
64 : 627000000[1088] - 628950000[1127] 2000000[ 40]
2048: 629000000[1128] - 634950000[1247] 6000000[ 120]
64 : 635000000[1248] - 709000000[2728] 74050000[1481]
512 : 709050000[2729] - 721000000[2968] 12000000[ 240]
64 : 721050000[2969] - 722950000[3007] 1950000[ 39]
64 : 723000000[3008] - 777350000[4095] 54400000[1088]
**** OFDM Modulation Profile Assigned Channel Profiles ****
Prof Channel
ID Profiles
10 30
554
Configuring OFDM Channel Profile
To display the associations between OFDM modulation profiles and OFDM channel profiles, use the show
cable ofdm-modulation-profile command with channel-profiles option as shown in the example below:
Router# show cable ofdm-modulation-profile channel-profiles
**** OFDM Modulation Profile Assigned Channel Profiles ****
Prof Channel
ID Profiles
8 None
9 28
10 30
192 192
To display the OFDM modulation profile configurations, use the show cable ofdm-modulation-profile
command with configuration option as shown in the example below:
Router# show cable ofdm-modulation-profile configuration
**** OFDM Modulation Profile Configuration ****
Prof FFT Width Start-freq Modulations Description

ID KHz Hz Hz (Limited to 20)
8 50 192000000 NA 2048 default
512 freq-off 48000000
width 24000000
9 50 96000000 627000000 512 default 512-1k-4k
1024 freq-abs 635000000
width 74050000
4096 freq-abs 629000000
width 6000000
10 50 96000000 627000000 64 default
512 freq-abs 709050000
width 12000000
2048 freq-abs 629000000
width 6000000
Configuring OFDM Channel Profile

To configure the OFDM channel profile, follow the steps below:
enable
configure terminal
cable downstream ofdm-chan-profile id
description text
cyclic-prefix value
interleaver-depth value
pilot-scaling value
roll-off value
profile-ncp modulation-default mod_prof_id
profile-control {modulation-default mod_prof_id | modulation-profile mod_prof_id}
profile-data channel_data_prof_id {modulation-default mod_prof_id |
modulation-profile mod_prof_id}
555
Verifying OFDM Channel Profile Configuration
Verifying OFDM Channel Profile Configuration

To display the OFDM channel profile details, use the show cable ofdm-chan-profiles command as shown
in the example below:
Router# show cable ofdm-chan-profile 20
**** OFDM Channel Profile Configuration ****
Prof Cycl Roll FFT Intr Pilot Modulation (D-Default, P-Profile)

ID Prfx Off KHz Depth Scale Cntrl NCP Data Profiles
1 2 3 4 5
20 1024 128 50 16 48 D:1024 D:16 NA NA NA NA NA

**** OFDM Channel Profile Assigned Channels ****
Prof Admin Controller:channels

ID
20 Up 3/0/1:158 3/0/2:158 3/0/3:158 3/0/5:158
3/0/6:158 3/0/7:158
To display the associations between OFDM channel profiles and OFDM channels, use the show cable
ofdm-chan-profiles command with channels option as shown in the example below:
Router# show cable ofdm-chan-profile channels
**** OFDM Channel Profile Assigned Channels ****
Prof Admin Controller:channels

ID
20 Up 3/0/1:158 3/0/2:158 3/0/3:158 3/0/5:158
3/0/6:158 3/0/7:158
30 Up 3/0/4:158
101 Up 3/0/0:158
To display the OFDM channel profile configurations, use the show cable ofdm-chan-profiles command with
configuration option as shown in the example below:
Router# show cable ofdm-chan-profile configuration
**** OFDM Channel Profile Configuration ****
Prof Cycl Roll FFT Intr Pilot Modulation (D-Default, P-Profile)

Description
ID Prfx Off KHz Depth Scale Cntrl NCP Data Profiles
(Limited to 20)
1 2 3 4 5
0 192 128 50 16 48 D:256 D:16 D:1024 NA NA NA NA

System Profile 0
1 192 128 50 16 48 D:256 D:16 D:1024 D:2048 D:512 NA NA
System Profile 1
20 1024 128 50 16 48 D:1024 D:16 NA NA NA NA NA
30 1024 128 50 16 48 P:10 D:16 NA NA NA NA NA
556
Configuring OFDM Channel as Primary Channel
Configuring OFDM Channel as Primary Channel

To configure an RF-channel in the mac-domain as an OFDM primary channel, use the following commands.
enable
configure terminal
interface cable <slot/subslot/port> downstream Integrated-Cable <slot/subslot/port>
rf-channel <ofdm-channel-number: 158-162>
end
Verifying OFDM Primary Channel Configuration

To display the OFDM channel configuration details, where the OFDM channel is the primary channel, use
the command as shown in the following example:
Router#sh run int c3/0/3

!
load-interval 30
upstream 0
upstream 1
upstream 2
upstream 3
attributes 80000000
cable bundle 1
cable cm-status enable 3 6-11 16-18 20-27
end
You can also use the following command to display the OFDM primary channel configuration details as
shown in this example.
Router#sh cable mac-domain c3/0/3 cgd-associations
Ca3/0/3 3/0/3 0 0-3 Yes 0
158 0-3 Yes 158
The show cable mac-domain Cable <slot>/<subslot>/<port> mdd command also displays the OFDM
primary channel configuration details as shown in the example.
...
Downstream Active Channel List
Channel ID: 159
Frequency: 836000000Hz
Primary Capable: Primary-Capable
CM-STATUS Event Bitmask:0x36
MDD Timeout
QAM FEC failure
MDD Recovery
QAM FEC recovery
MAP/UCD Transport Indicator: Can carry MAPs and UCDs
OFDM PLC Params Bitmask:
Tukey raised cosine window: 0.625
557
Configuring Port or Controller and Channel
Cyclic Prefix: 5.0

Sub carrier spacing: 50
RF channels use a zero-based numbering scheme, whereas the downstream channel IDs are numbered starting
from one. Thus RF channel 158 is equivalent to channel ID 159. The Channel ID in this example is 159. The
MAP/UCD Transport Indicator shows that MAPs and UCDs are sent only on Primary Channels.
Configuring Port or Controller and Channel

To configure the port/controller and channel, use the following commands:
enable
configure terminal
controller integrated-cable slot/subslot/port
max-ofdm-spectrum value
ofdm-freq-excl-band start-frequency value width value
rf-chan start_id [end_id]
ofdm channel-profile id start-frequency value width value [plc value]
Note The range of start_id is 158 to 162 in the OFDM channel configuration.
The maximum OFDM spectrum is assigned to OFDM channels, which is used by the the CMTS to calculate
default port base power.
Ranges of frequencies can be excluded from all OFDM channels using the ofdm-freq-excl-band command.
Verifying Port/Controller and Channel Configuration

To display the RF port details, use the show controller integrated-cable command with rf-port option as
shown in the example below:
Router# show controller integrated-cable 3/0/0 rf-port
Admin: UP MaxCarrier: 128 BasePower: 33 dBmV Mode: normal

Rf Module 0: UP
Free freq block list has 3 blocks:
45000000 - 107999999
624000000 - 644999999
837000000 - 1217999999
Rf Port Status: UP
MaxOfdmSpectrum: 192000000 Equivalent 6MHz channels: 32
UsedOfdmSpectrum: 192000000 AvailOfdmSpectrum: 0
DefaultBasePower: 33 dBmV Equivalent 6MHz channels: 160
OFDM frequency exclusion bands: None
To display the summary information on OFDM channel, use the show controller integrated-cable command
with rf-channel option as shown in the example below:
Router# show controller integrated-cable 3/0/0 rf-channel 158
output
Frequency
158 UP UP OFDM 627000000 96000000 663000000 20 159 34
558
NORMAL
To display detailed information on OFDM channel, use the show controller integrated-cable command with
rf-channel and verbose options as shown in the example below:
Router# show controller integrated-cable 3/0/0 rf-channel 158 verbose
output
Frequency
158 UP UP OFDM 627000000 96000000 663000000 30 159 32
NORMAL
Resource status: OK
License: granted <17:02:35 EDT May 18 2016>
OFDM channel license spectrum width: 92200000
OFDM modulation license (spectrum width): 2K (6000000)
OFDM config state: Configured
OFDM channel details: [3/0/4:158]

------------------------------------------
OFDM channel frequency/subcarrier range : 627000000[1088] - 722999999[3007]
OFDM spectrum frequency/subcarrier range : 572600000[ 0] - 777399999[4095]
Active spectrum frequency/subcarrier range : 628900000[1126] - 721049999[2969]
OFDM channel center frequency/subcarrier : 675000000[2048]
PLC spectrum start frequency/subcarrier : 663000000[1808]
PLC frequency/subcarrier : 665800000[1864]
Channel width : 96000000
Active Channel width : 92200000
OFDM Spectrum width : 204800000
Chan prof id : 30
Cyclic Prefix : 1024
Roll off : 128
Interleave depth : 16
Spacing : 50KHZ
Pilot Scaling : 48
Control modulation profile : 10
NCP modulation default : 16
Data modulation default : None
Data modulation profile : None
Lower guardband width in freq/subcarriers : 1900000[38]
Upper guardband width in freq/subcarriers : 1900000[38]
Licensed 4K modulation spectrum width : 0
Licensed 2K modulation spectrum width : 6000000
PLC spectrum frequencies [subcarriers] :

663000000[1808] - 668999999[1927]
PLC channel frequencies [subcarriers] :

665800000[1864] - 666199999[1871] Size: 8 subcarriers
Excluded frequencies [subcarriers] :

572600000[ 0] - 628899999[1125] 721100000[2970] - 777399999[4095]
Count: 2252
Pilot frequencies [subcarriers] :

*:PLC pilots
630700000[1162] 634300000[1234] 637900000[1306] 641500000[1378]
645100000[1450] 648700000[1522] 652300000[1594] 655900000[1666]
659500000[1738] 663450000[1817]* 664050000[1829]* 664600000[1840]*
665050000[1849]* 666900000[1886]* 667350000[1895]* 667900000[1906]*
668500000[1918]* 669100000[1930] 672700000[2002] 676300000[2074]
679900000[2146] 683500000[2218] 687100000[2290] 690700000[2362]
694300000[2434] 697900000[2506] 701500000[2578] 705100000[2650]
559
708700000[2722] 712300000[2794] 715900000[2866] 719500000[2938]

Count: 32
Active frequencies [subcarriers] :

628900000[1126] - 721099999[2969]
Count: 1844
Data frequencies [subcarriers] :

628900000[1126] - 630699999[1161] 630750000[1163] - 634299999[1233]
634350000[1235] - 637899999[1305] 637950000[1307] - 641499999[1377]
641550000[1379] - 645099999[1449] 645150000[1451] - 648699999[1521]
648750000[1523] - 652299999[1593] 652350000[1595] - 655899999[1665]
655950000[1667] - 659499999[1737] 659550000[1739] - 663449999[1816]
663500000[1818] - 664049999[1828] 664100000[1830] - 664599999[1839]
664650000[1841] - 665049999[1848] 665100000[1850] - 665799999[1863]
666200000[1872] - 666899999[1885] 666950000[1887] - 667349999[1894]
667400000[1896] - 667899999[1905] 667950000[1907] - 668499999[1917]
668550000[1919] - 669099999[1929] 669150000[1931] - 672699999[2001]
672750000[2003] - 676299999[2073] 676350000[2075] - 679899999[2145]
679950000[2147] - 683499999[2217] 683550000[2219] - 687099999[2289]
687150000[2291] - 690699999[2361] 690750000[2363] - 694299999[2433]
694350000[2435] - 697899999[2505] 697950000[2507] - 701499999[2577]
701550000[2579] - 705099999[2649] 705150000[2651] - 708699999[2721]
708750000[2723] - 712299999[2793] 712350000[2795] - 715899999[2865]
715950000[2867] - 719499999[2937] 719550000[2939] - 721099999[2969]
Count: 1804
Profiles:
Number of profiles: 2
CTRL profile (Profile A): rate: 461916 kbps, usable rate: 368000 kbps
Active frequencies [subcarriers]:
Modulation:Start-freq[start-subcarrier] - End-freq[end-subcarrier]
------------------------------------------------------------------
64 :628900000[1126] - 628950000[1127] 2048 :629000000[1128] - 630650000[1161]
2048 :630750000[1163] - 634250000[1233] 2048 :634350000[1235] - 634950000[1247]
64 :635000000[1248] - 637850000[1305] 64 :637950000[1307] - 641450000[1377]
64 :641550000[1379] - 645050000[1449] 64 :645150000[1451] - 648650000[1521]
64 :648750000[1523] - 652250000[1593] 64 :652350000[1595] - 655850000[1665]
64 :655950000[1667] - 659450000[1737] 64 :659550000[1739] - 663400000[1816]
64 :663500000[1818] - 664000000[1828] 64 :664100000[1830] - 664550000[1839]
64 :664650000[1841] - 665000000[1848] 64 :665100000[1850] - 665750000[1863]
64 :666200000[1872] - 666850000[1885] 64 :666950000[1887] - 667300000[1894]
64 :667400000[1896] - 667850000[1905] 64 :667950000[1907] - 668450000[1917]
64 :668550000[1919] - 669050000[1929] 64 :669150000[1931] - 672650000[2001]
64 :672750000[2003] - 676250000[2073] 64 :676350000[2075] - 679850000[2145]
64 :679950000[2147] - 683450000[2217] 64 :683550000[2219] - 687050000[2289]
64 :687150000[2291] - 690650000[2361] 64 :690750000[2363] - 694250000[2433]
64 :694350000[2435] - 697850000[2505] 64 :697950000[2507] - 701450000[2577]
64 :701550000[2579] - 705050000[2649] 64 :705150000[2651] - 708650000[2721]
64 :708750000[2723] - 709000000[2728] 512 :709050000[2729] - 712250000[2793]
512 :712350000[2795] - 715850000[2865] 512 :715950000[2867] - 719450000[2937]
512 :719550000[2939] - 721000000[2968] 64 :721050000[2969] - 721050000[2969]
Active subcarrier count: 1804, ZBL count: 0
Discontinuity time [days:hours:mins:secs]: 00:00:54:32 [16:15:02 EDT May 18 2016]
NCP profile:
Active frequencies [subcarriers]:
Modulation:Start-freq[start-subcarrier] - End-freq[end-subcarrier]
------------------------------------------------------------------
16 :628900000[1126] - 630650000[1161] 16 :630750000[1163] - 634250000[1233]
16 :634350000[1235] - 637850000[1305] 16 :637950000[1307] - 641450000[1377]
16 :641550000[1379] - 645050000[1449] 16 :645150000[1451] - 648650000[1521]
16 :648750000[1523] - 652250000[1593] 16 :652350000[1595] - 655850000[1665]
16 :655950000[1667] - 659450000[1737] 16 :659550000[1739] - 663400000[1816]
560
16 :663500000[1818] - 664000000[1828] 16 :664100000[1830] - 664550000[1839]

16 :664650000[1841] - 665000000[1848] 16 :665100000[1850] - 665750000[1863]
16 :666200000[1872] - 666850000[1885] 16 :666950000[1887] - 667300000[1894]
16 :667400000[1896] - 667850000[1905] 16 :667950000[1907] - 668450000[1917]
16 :668550000[1919] - 669050000[1929] 16 :669150000[1931] - 672650000[2001]
16 :672750000[2003] - 676250000[2073] 16 :676350000[2075] - 679850000[2145]
16 :679950000[2147] - 683450000[2217] 16 :683550000[2219] - 687050000[2289]
16 :687150000[2291] - 690650000[2361] 16 :690750000[2363] - 694250000[2433]
16 :694350000[2435] - 697850000[2505] 16 :697950000[2507] - 701450000[2577]
16 :701550000[2579] - 705050000[2649] 16 :705150000[2651] - 708650000[2721]
16 :708750000[2723] - 712250000[2793] 16 :712350000[2795] - 715850000[2865]
16 :715950000[2867] - 719450000[2937] 16 :719550000[2939] - 721050000[2969]
CCCs:
OCD CCC: 2
DPD CCCs:
Control profile (Profile A) CCC: 2
NCP profile CCC: 2
Resource config time taken: 2286 msecs
JIB channel number: 776

Chan Pr EnqQ Pipe RAF SyncTmr DqQ ChEn RAF Pipe Phy0 Phy1 Tun# SessId 0[TkbRt MaxP]
1[TkbRt MaxP]
776 0 384 1 725 0 384 0100 13032 1 0 1 2 0 479610000 4485120
383688000 4485120
776 1 384 1 4786 0 384 0100 2190 1 0 1 2 0 479610000 4485120
383688000 4485120
776 2 384 1 4786 0 384 0100 2190 1 0 1 2 0 479610000 4485120
383688000 4485120
776 3 384 1 4786 0 384 0100 2190 1 0 1 2 0 479610000 4485120
383688000 4485120
776 4 384 1 4786 0 384 0100 2190 1 0 1 2 0 479610000 4485120
383688000 4485120
776 5 384 1 4786 0 384 0100 2190 1 0 1 2 0 479610000 4485120
383688000 4485120
776 6 384 1 4786 0 384 0100 2190 1 0 1 2 0 479610000 4485120
383688000 4485120
776 7 384 1 0 0 384 0100 0 1 0 1 2 0 479610000 4485120
383688000 4485120
Chan Qos-Hi Qos-Lo Med-Hi Med-Lo Low-Hi Low-Lo

776 368640 245760 368640 245760 614400 368640
Chan Med Low TB-neg Qos_Exc Med_Xof Low_Xof Qdrops(H-M-L) Pos Qlen(Hi-Med-lo) Fl
Tgl_cnt Rdy_sts
776 0 0 0 0 0 0 0 0 0 Y 0 0 0 0
0 ff
Chan Rate Neg Pos LastTS CurrCr Pos [PLC Rate Neg Pos]
776 10485750 65535 65535 116199669 268431360 Y [MM 86 128 1114][EM 87 128 6204][TR 2
9 3102]
DSPHY Info:
Local rf port 0 , rf chan 158 pic loss 123
non short CWs: = 235681130, shorts = 0, stuff bytes = 235639172 bch 235681130
NCP msgs: = 453809753, PLC encodings = 16902476
flow0 rcv 70203 flow1 rcv 3 flow0 drops 0 flow1 drops 0
This section provides examples for configuring the OFDM channel.
561
Example1: Configuring OFDM Channel
Note The OFDM modulation profile must be configured before the OFDM channel profile which references it.
The following example shows how to configure the OFDM channel:

enable
configure terminal
cable downstream ofdm-modulation-profile 9
description 512-1k-4k
subcarrier-spacing 50KHz
width 96000000
start-frequency 627000000
assign modulation-default 512-QAM
assign modulation 1024-QAM range-subcarriers freq-abs 635000000 width 74050000
assign modulation 4096-QAM range-subcarriers freq-abs 629000000 width 6000000
exit
configure terminal
cable downstream ofdm-chan-profile 20
description Data profiles: 2 single mod, 1 mixed mod
cyclic-prefix 192
interleaver-depth 16
pilot-scaling 48
roll-off 128
profile-ncp modulation-default 16-QAM
profile-control modulation-default 256-QAM
profile-data 1 modulation-default 1024-QAM
profile-data 2 modulation-default 2048-QAM
profile-data 3 modulation-profile 9
exit
configure terminal
controller integrated-cable 3/0/0
max-ofdm-spectrum 96000000
ofdm-freq-excl-band start-frequency 683000000 width 10000000
rf-chan 158
power-adjust 0
ofdm channel-profile 20 start-frequency 627000000 width 96000000 plc 663000000
Example 2: Configuring OFDM Primary Channel in the MAC Domain

enable
configure terminal
interface cable 3/0/0
end
562
Related Document
Document Title Link
Cisco cBR Converged Broadband Routers Layer 2 http://www.cisco.com/c/en/us/td/docs/cable/cbr/

and DOCSIS 3.0 Configuration Guide configuration/guide/b_cbr_layer2_docsis30.html
MIBs
MIBs MIBs Link
DOCS-IF31-MIB To locate and download MIBs for selected platforms, Cisco IOS releases, and feature sets,
use Cisco MIB Locator found at the following URL:
http://www.cisco.com/go/mibs
Description Link
The Cisco Support website provides extensive online resources, including http://www.cisco.com/
documentation and tools for troubleshooting and resolving technical issues with Cisco support
products and technologies.
To receive security and technical information about your products, you can subscribe
to various services, such as the Product Alert Tool (accessed from Field Notices), the
Cisco Technical Services Newsletter, and Really Simple Syndication (RSS) Feeds.
Access to most tools on the Cisco Support website requires a Cisco.com user ID and
password.
Feature Information for DOCSIS 3.1 OFDM Channel Configuration

563
Feature Information for DOCSIS 3.1 OFDM Channel Configuration
Table 92: Feature Information for DOCSIS 3.1 OFDM Channel Configuration
DOCSIS 3.1 OFDM Channel Cisco IOS XE Fuji 16.7.1 This feature was integrated on the Cisco cBR
Support Series Converged Broadband Routers.
Full Spectrum 108-1218 MHz Cisco IOS XE Fuji 16.7.1 This feature was integrated on the Cisco cBR
Support Series Converged Broadband Routers.
DOCSIS 3.1 OFDM Primary Cisco IOS XE Fuji 16.7.1 This feature was integrated on the Cisco cBR
Channel Support Series Converged Broadband Routers.
Enhanced support for subcarrier Cisco IOS XE Fuji 16.7.1 This feature was integrated on the Cisco cBR
spacing, exclusion band, and Series Converged Broadband Routers.
LCPR
Hitless OFDM Profile Changes Cisco IOS XE Everest This feature was integrated on the Cisco cBR
16.12.1x Series Converged Broadband Routers.
Ephemeral Profile to Cable Cisco IOS XE Everest This feature was integrated on the Cisco cBR
Modem Assignment 16.12.1x Series Converged Broadband Routers.
Profile Management Application Cisco IOS XE Everest This feature was integrated on the Cisco cBR
Scaling 16.12.1z Series Converged Broadband Routers.
564
CHAPTER 34
OFDM Channel Power Profile
The OFDM Channel Power Profile feature helps in adjusting the power-level of 6 MHz bands in a DOCSIS
3.1 downstream OFDM channel.
• Information About OFDM Channel Power Profile, on page 567
• How to Configure the OFDM Channel Power Profile, on page 568
• Configuration Example for OFDM Power Profile, on page 569
• Feature Information for OFDM Channel Power Profile, on page 570
565
Digital PICs:

Module:

Modules:
line card reload.
566
Information About OFDM Channel Power Profile
Information About OFDM Channel Power Profile

The OFDM power profile provides a better, consistent power-level output at the cable modem, compensating
the power levels at a finer granularity. It reduces the differing amounts of cable-loss over the bandwidth of
OFDM channel.
This feature enables the Cisco cBR Series Converged Broadband Router to correct the transmission loss due
to the cable in the plant.
The OFDM power profile (ofdm-power-profile) adjusts the transmission power level of each 6 MHz in an
OFDM channel. The OFDM channel width can range from 24 MHz to 192 MHz, resulting in band-counts
between 4 and 32 for the profile.
Each 6 MHz band is referenced by a band index (band-index) that is zero-based, with a maximum band range
of 192 MHz OFDM channel being 0 to 31. Each band within the OFDM channel can have a unique power
level setting. The OFDM power profile allows a total band adjustment range of 8 dB. Under some specific
conditions, if the OFDM channel's downstream controller's base channel power is set to exceed the maximum
DRFI specification power level, the OFDM power profile adjustment range can become as high as 9 dB.
In a power profile, you can set the power level (power-adjust-default) to a default value. This default value
is applied to any band that is not configured through any other means.
You can configure band power levels in two methods: through the power tilt config (power-tilt-linear) or by
configuring the power level for a band or range of bands (band-index). You can use both methods for
configuring the band power levels simultaneously within an OFDM power profile.
The power tilt configuration applies a linear power-adjust value between the power-adjust-default value
applied to the band index 0, and the power-tilt-linear adjust value applied to the highest band index of the
profile. For example, an OFDM Power Profile of 96 MHz, with a power-tilt-linear of 4 dB, and
power-adjust-default of 0 dB, has16 bands numbered 0 to 15, band index 0 is +0 dB, band index 15 is +4 dB,
and bands 1 to 14 contain the linear power level setting based on the slope of the line between the band 0 and
band 15 to the nearest 1/10th dB.
The band-index configuration applies a specified value to the indicated bands. The band-index configuration
can specify a single band or a range of bands. A power-adjust configuration is used to specify the power level
for the bands to the nearest 1/10th dB.
You can simultaneously use both power tilt and band index, where band-index is applied last. When you use
both, the power-tilt-linear values can be overridden using the band-index power-adjust values.
A maximum of 64 OFDM power profiles can be configured on the Cisco cBR routers, numbered from 1 to
64. You can apply a single OFDM power profile to multiple controller OFDM channels, across line cards, as
long as all validity checks pass during configuration. The router console displays an error message explaining
any configuration errors or warnings.
Restrictions for Configuring OFDM Power Profile

The following restrictions are applicable for configuring an OFDM power profile:
• OFDM power profile can be configured only on DOCSIS 3.1 system
• The power profile can be applied only to downstream controller OFDM channels (RF-channels 158 to
162)
567
How to Configure the OFDM Channel Power Profile
How to Configure the OFDM Channel Power Profile

Configuring OFDM Power Profile Using Band-index
Use the following commands along with the band-index configuration to configure OFDM Power Profile,
where the band-index values act as an override.
enable
configure terminal
cable downstream ofdm-power-profile <profile_id>
power-adjust-default -2.1
band-index 0 7
power-adjust -1.0
band-index 8 15
power-adjust -0.5
band-index 16 23
power-adjust 0.5
band-index 24 31
power-adjust 1.5
controller Integrated-Cable {slot}/{subslot}/{port}

rf-channel {158 - 162 }
power-profile {ofdm-power-profile-id}
Verifying the Power Profile Configuration

To display the power profile configuration details, use the show cable ofdm-power-profile command as
given in the following example. This command also displays the actual power-band power levels as set by
the profile.
Router> show cable ofdm-power-profile 3
OFDM Power Profile 3
Power-Adjust-Default(*): -2.1
Power-Band:
[00-07] -1.0 -1.0 -1.0 -1.0 -1.0 -1.0 -1.0 -1.0
[08-15] -0.5 -0.5 -0.5 -0.5 -0.5 -0.5 -0.5 -0.5
[16-23] 0.5 0.5 0.5 0.5 0.5 0.5 0.5 0.5
[24-31] 1.5 1.5 1.5 1.5 1.5 1.5 1.5 1.5
+4 .0 |
|
+3 .0 |
|
+2 .0 |
| * * * * * * * *
+1 .0 |
| * * * * * * * *
+0 .0 | ----------------------------------------------------------------
| * * * * * * * *
-1 .0 | * * * * * * * *
|
-2 .0 |
|
-3 .0 |
|
(dB) 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
568
Configuring OFDM Power Profile with Linear Power-tilt
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
band-index
Configuring OFDM Power Profile with Linear Power-tilt

Use the following commands to configure the OFDM power profile with a linear power-tilt and the band-index
override.
enable
configure terminal
cable downstream ofdm-power-profile <profile_id>
power-adjust-default 0.0
power-tilt-linear 3.5
band-index 0
power-adjust 4.0
Verifying the Power Profile Using show controller Command

Use the show controller command to display the absolute power-band levels as set by the power profile.
When the power-profile is applied to the controller, the power level displayed is the actual transmit power
level in dBmV.
Router>show controller Integrated-Cable 3/0/0 rf-channel 158 verbose
Chan State Admin Mod-Type Start Width PLC Profile-ID dcid power output
Frequency
158 UP UP OFDM 849000000 96000000 856000000 20 159 33.0
NORMAL
Resource status: OK
License: granted <09:23:14 EDT Aug 1 2016>
OFDM channel license spectrum width: 92200000
OFDM config state: Configured
OFDM Power Profile: 3

Power-Band:
[00-07] 32.0 32.0 32.0 32.0 32.0 32.0 32.0 32.0
[08-15] 32.5 32.5 32.5 32.5 32.5 32.5 32.5 32.5
[16-23] 33.5 33.5 33.5 33.5 33.5 33.5 33.5 33.5
[24-31] 34.5 34.5 34.5 34.5 34.5 34.5 34.5 34.5
OFDM channel details: [3/0/0:158]

------------------------------------------
Configuration Example for OFDM Power Profile

This section provides example for the OFDM Power Profile configuration.
Example: OFDM Power Profile with Linear Power-tilt Configuration

enable
configure terminal
cable downstream ofdm-power-profile 3
power-adjust-default 0.0
power-tilt-linear 3.5
band-index 0
power-adjust 4.0
569
Feature Information for OFDM Channel Power Profile
Feature Information for OFDM Channel Power Profile

Table 94: Feature Information for OFDM Channel Power Profile
OFDM Channel Power Profile Cisco IOS XE Fuji 16.7.1 This feature was integrated into the
Broadband Routers.
570
CHAPTER 35
DOCSIS 3.1 Path Selection
This document describes how to configure the path selecion on the Cisco cBR Series Converged Broadband
Router.
• Information about Path Selection, on page 571
• How to Configure Path Selection, on page 571
• Feature Information for DOCSIS 3.1 Path Selection, on page 575
Information about Path Selection

DOCSIS 3.1 Path Selection feature is enhanced to support OFDM downstream channels and OFDMA upstream
channels. The RCC selection process is enhanced to include OFDM channels. The TCC selection process is
enhanced to include OFDMA channels.
How to Configure Path Selection

Configuring Downstream Bonding Group with OFDM Channel
To configure the downstream bonding group with OFDM channel, follow the steps below:
enable
configure terminal
interface wideband-cable slot/subslot/bay:wideband-channel
description text
cable bundle id
cable rf-channels channel-list grouplist bandwidth-percent percentage-bandwidth
Note Channel 158 to 162 are specified as OFDM channel.
571
Verifying Downstream Bonding Group with OFDM Channel Configuration
Verifying Downstream Bonding Group with OFDM Channel Configuration

To display the details of the downstream bonding group with OFDM channel, use the show running-config
interface command as shown in the example below:
Router# show running-config interface wideband-cable 3/0/0:13

!
description D31-DSBG: 1 SC-QAM plus 1 OFDM
cable bundle 1
cable rf-channels channel-list 8 bandwidth-percent 30
cable rf-channels channel-list 158 bandwidth-percent 25
end
Configuring Upstream Bonding Group with OFDMA Channel

To configure the upstream bonding group with OFDMA channel, follow the steps below:
enable
configure terminal
interface cable slot/subslot/bay
cable upstream bonding-group id
upstream id
Verifying Upstream Bonding Group with OFDMA Channel Configuration

To display the details of the upstream bonding group with OFDMA channel, use the show running-config
interface command as shown in the example below:
Router# show running-config interface cable 6/0/3

!
load-interval 30
cable upstream balance-scheduling
upstream 0
upstream 1
upstream 2
upstream 3
upstream 6
attributes 80000000
cable bundle 1
!
572
Verifying the Path Selection Status
Verifying the Path Selection Status

To display the path selection status of a cable modem, use the show cable modem path-sel command as
router#show cable modem 38c8.5cfe.efa6 path-sel
CM 38c8.5cfe.efa6 Path-Sel Info: 07:20
RCS Filter Result: Succeed

Candidate RCS List: 2
RCC-Id Owner-Id Preliminary RCP TLV-56 LBG SF-Attr CM-Attr
1 1 :12289 Pass Pass -- Pass Pass Pass
2 1 :12290 Pass Pass -- Pass Pass Pass
TCS Filter Result: Succeed

TCS Info:
TCS in CGD : 0x7 UCID: 1 2 3
TCS in Freq Range : 0x7 UCID: 1 2 3
TCS Impaired : 0x0
TCS Passed filters:
Preliminary : 0x7 UCID: 1 2 3
LB Group : 0x7 UCID: 1 2 3
SF Attr Mask : 0x7 UCID: 1 2 3
CM Attr Mask : 0x7 UCID: 1 2 3
Candidate US-BG List: 4

UBG-Id Chan-Mask Preliminary TLV-56 LBG SF-Attr CM-Attr
1 0x7 Pass -- Pass Pass Pass
Primary DS Chan Result: Skipped

Candidate Primary DS Chan List: 0
Primary US Chan Result: Skipped

Candidate Primary US Chan List: 0
Clearing the Path Selection Status

To clear the path selection status for all CMs, use the clear cable modem all path-sel command as shown in
the example below:
Router# clear cable modem all path-sel
Router# show cable modem c8fb.26a6.c46a path-sel
CM c8fb.26a6.c46a Path-Sel Info: N/A

Path-Sel status has been cleared after register online.

To verify the runtime RCCs on a cable interface, use the show cable mac-domain rcc command as shown
Router# show cable mac-domain cable 7/0/0 rcc
573
RCC-ID RCP RCs MD-DS-SG CMs WB/RCC-TMPL D3.0 D3.1

4 00 00 00 00 00 16 0 1 WB (Wi7/0/0:0) Y Y
5 00 00 00 00 00 25 0 2 WB (Wi7/0/0:1) N Y
6 00 10 00 00 08 8 0 0 RCC-TMPL(3:1) Y N
7 00 00 00 00 00 4 0 0 WB (Wi7/0/0:4) Y Y
To display the detailed information for only DOCSIS 3.1 capable RCC, use the show cable mac-domain rcc
simplified command as shown in the example below:
router#show cable mac-domain cable 7/0/0 rcc 5 simplified
RCC ID : 5
Created Via : Wideband - Wi7/0/0:1
Primary Receive Channel List:

Chan Idx RF Chan DCID Freq
1 In7/0/0:0 1 453000000
Non-Primary Receive Channel List:

Chan Idx RF Chan DCID Freq
2 In7/0/0:1 2 459000000
3 In7/0/0:2 3 465000000
4 In7/0/0:3 4 471000000
5 In7/0/0:4 5 477000000
6 In7/0/0:5 6 483000000
7 In7/0/0:6 7 489000000
8 In7/0/0:7 8 495000000
9 In7/0/0:8 9 501000000
10 In7/0/0:9 10 507000000
11 In7/0/0:10 11 513000000
12 In7/0/0:11 12 519000000
13 In7/0/0:12 13 525000000
14 In7/0/0:13 14 531000000
15 In7/0/0:14 15 537000000
16 In7/0/0:15 16 543000000
17 In7/0/0:16 17 549000000
18 In7/0/0:17 18 555000000
19 In7/0/0:18 19 561000000
20 In7/0/0:19 20 567000000
21 In7/0/0:20 21 573000000
22 In7/0/0:21 22 579000000
23 In7/0/0:22 23 585000000
24 In7/0/0:23 24 591000000
25 In7/0/0:158 159 663000000
OFDM Receive Channel List:

Chan Idx RF Chan DCID PLC-Freq Profiles
25 In7/0/0:158 159 663000000 0 1 2
574
Related Document
Document Link
Title
Cisco cBR http://www.cisco.com/c/en/us/td/docs/cable/cbr/configuration/guide/b_cbr_layer2_docsis30.html

Converged
Broadband
Routers
Layer 2 and
DOCSIS 3.0
Configuration
Guide
MIBs
MIBs MIBs Link
• DOCS-IF31-MIB To locate and download MIBs for selected platforms, Cisco IOS releases, and feature
sets, use Cisco MIB Locator found at the following URL:
Description Link
ID and password.
Feature Information for DOCSIS 3.1 Path Selection

575
Feature Information for DOCSIS 3.1 Path Selection
Table 95: Feature Information for DOCSIS 3.1 Path Selection
DOCSIS 3.1 Path Selection Cisco IOS XE Fuji This feature was integrated on the Cisco cBR
DOCSIS 3.1 Upstream Path Cisco IOS XE Fuji This feature was integrated on the Cisco cBR
Selection 16.7.1 Series Converged Broadband Routers.
576
CHAPTER 36
DOCSIS 3.1 Downstream Profile Selection
First Published: July 13, 2016
DOCSIS 3.1 introduces the concept of downstream profiles for OFDM channels.
Contents
• Information about Downstream Profiles, on page 579
• How to Configure Profiles, on page 580
• Feature Information for Downstream Profile Selection, on page 583
577
Digital PICs:

Module:

Modules:
line card reload.
578
Information about Downstream Profiles
Information about Downstream Profiles

A profile is a list of modulation orders that are defined for each of the subcarriers within an OFDM channel.
The CMTS can define multiple profiles for use in an OFDM channel, where the profiles differ in the modulation
orders assigned to each subcarrier. The CMTS can assign different profiles for different groups of CMs.
Default Data Profile

The first time a CM registers, it is assigned a default data profile. The default data profile is "profile-data 1".
If "profile-data 1" is not configured, "profile-control" is assigned to the CM.
Note Profile A, with profile ID 0, is also referred to as the control profile.
Recommended Profile
Based on the Receive Modulation Error Ratio (RxMER) values collected from a modem, the CMTS finds
among the existing profiles the one that may provide the highest speed, and yet at the same time may have
sufficient Signal to Noise Ratio (SNR) margin for the modem to receive code words with acceptable error.
This profile is called the recommended profile for that CM. The show cable modem phy ofdm-profile
command displays the recommended profile for each CM. Recommended Profile will take effect when the
CM is reset by the operator. When the CM comes back online, recommended profile is assigned to it.
Internal PMA is enabled by default on the cBR-8. If external PMA is enabled, internal PMA is disabled and
can be enabled by running the following config command on the cBR-8:
no cable downstream ofdm-prof-mgmt prof-upgrade-pma
In external PMA, the cBR-8 does not automatically upgrade a CM's profile to the recommended profile. In
internal PMA, the profile can be upgraded to the recommended profile in the next OFDM Profile Test (OPT)
cycle.
A user configurable age is associated with each recommended profile, which can be configured as follows:
Router (config)#cable downstream ofdm-prof-mgmt recommend-profile-age age-in-minutes
If the recommended profile exceeds this age, it is no longer valid for that CM.
Unfit Profile
When the CMTS receives CM-STATUS Event 16 (DS OFDM Profile Failure), the profile indicated in the
CM-STATUS message is marked as 'unfit profile' for this modem.
A user configurable maximum age is associated with each unfit profile, which can be configured as follows:
Router (config)#cable downstream ofdm-prof-mgmt unfit-profile-age age-in-minutes
If the unfit profile for a modem exceeds this age, it is no longer valid.
579
How to Configure Profiles
How to Configure Profiles

Configuring Profile Downgrade
A CM sends a CM-STATUS Event 16 message to indicate a DS OFDM profile failure. When this indication
is received by the CMTS, it takes immediate action to downgrade the modem to a lower profile, as per the
profile ordering displayed by the following command:
Router# show controllers integrated-Cable 2/0/3 rf-channel 158 prof-order
The following table, extracted from [DOCSIS 3.1 MULPI], lists the CM-Status events that will trigger a
profile downgrade:
Table 97: Table: CM-Status Events for Profile Downgrade
Event Type Event Condition Status Report Events Parameters reported by CM
Trigger event to Trigger event to DCID Profile ID

"on" "off"
16 DS OFDM Loss of FEC Re-establishment Yes Yes

profile failure lock on one of of FEC lock for
the assigned that OFDM
downstream profile;
OFDM profiles
OR
of a channel
Removal of the
channel from the
active channel
list in the
primary channel
MDD;
OR
Removal of the
channel from the
CM's Receive
Channel set via
DBC-REQ
To disable the automatic profile downgrade, use the following command in global configuration mode:
Router (config)#no cable downstream ofdm-prof-mgmt prof-dwngrd-auto
Configuring RxMER to Bit Loading Mapping

There are many ways to map the RxMER values to bit loading values. We use the following mapping
recommended in [DOCSIS 3.1 OSSI], as our baseline mapping:
580
Hitless OFDM Profile Changes
RxMER (in ¼ DB) QAM Bit Loading
60 16 4
84 64 6
96 128 7
108 256 8
122 512 9
136 1024 10
148 2048 11
164 4096 12
184 8192 13
208 16384 14
• To configure a margin to adjust the RxMER to bit loading mapping, use the following command:
Router(config)# cable downstream ofdm-prof-mgmt mer-margin-qdb quarter-DB
This configured value (quarter-DB) is added to the RxMER values collected by CMTS before using the
above mapping table, thus giving a user more control in selecting the recommended profiles.
• To specify the percentage of subcarriers that can be ignored in the recommended profile calculation, use
the following command:
Router(config)# cable downstream ofdm-prof-mgmt exempt-sc-pct percent
This provides a way to specify the extent that the outliers can be ignored.
Hitless OFDM Profile Changes

Cisco cBR supports Hitless OFDM Profile from Cisco IOS XE Everest 16.12.1x, as a Profile Management
Application (PMA) tool.
The operation is as follows:
1. PMA determines if the modulation order of a data profile in an OFDM channel can be upgraded or
downgraded. This decision is based on the MER data that is received from cable modems that uses the
profile.
2. Poll cBR for all modems with active profiles to identify inactive ones.
3. Move modems to a temporary data profile if all are in use. Note that this is not control profile.
4. Delete any unused OFDM profile. The PMA repeats step 2 and step 3 to avoid race conditions.
5. Add (or Delete) a new OFDM profile with the desired modulation order to the OFDM channel.
6. Define the new profile list for the modems (DBC sent to modems by cBR).
7. Move modems to the new profile.
581
Ephemeral Profile to Cable Modem Assignment
Ephemeral Profile to Cable Modem Assignment

Cisco cBR supports Ephemeral Profile to Cable Modem Assignment from Cisco IOS XE Everest 16.12.1x,
as a Profile Management Application (PMA) tool.
If the modem is not listening to the desired profile, you can submit up to 4 data profiles. The PMA wants to
be active for that cable modem before issuing the profile assignment command. The control profile zero (0)
is always included by default.
The following commands are supported:
• cable modem <mac> ofdm-set-profiles chan <n> profiles <profile list>
This command initiates a DBC to the cable modem with the specified profile list. The profile list order
defines the downgrade profile in case the CM-STATUS is 16.
• cable downstream ofdm-flow-to-profile interface <integrated-Cable x/y/z:n> profile-data <n> mac-
address <mac>
This command enables the CMTS to start forwarding all traffic to the cable modem using the specified
profile. Ensure that you use the accompanying cable modem mac-address mac opt0 command for the
changes to take effect immediately.
Move the cable modems traffic to one of the profiles that it is listening to. DBC is not necessary. If the
profile is not active on the cable modem, then the CLI reports error. If the CMTS receives a CM-STATUS
16 for that profile, the CMTS downgrades the profile automatically.
The CM-STATUS does not reset when moving to another profile.
Display the Cable Modem Count per Profile

Feature History
Display CM counts per US IUC Cisco IOS XE Bengaluru 17.6.1x This feature introduces new
and DS profile commands show cable modem
phy ofdm downstream prof-count
and show cable modem phy ofdm
upstream iuc-count, it helps
tracking and reporting number of
Cable Modems being in use per
Upstream IUC and Downstream
Profile on each controller
separately. These counters are
indicative of health of the RF plant.
To display the CM count per downstream channel and profile, use the show cable modem phy ofdm
downstream prof-count command as shown in the examples below:
Router#show cable modem phy ofdm downstream prof-count
|<---------------------------- CM Count per profile
-------------------------->|
Channel IF-INDX P-0 P-1 P-2 P-3 P-4 P-5 P-6 P-7 P-8 P-9 P-10 P-11 P-12 P-13
582
P-14 P-15
------------- ------- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ----
---- ----
In0/0/0:158 264134 0 0 0 3 0 0 - - - 0 - - -
- - -
In0/0/0:159 264135 0 0 0 3 0 0 - - - 0 - - -
- - -
Do9/0/0:158 321478 1 0 0 0 4 0 - - - 0 - - -
- - -
Or use the command in the example below:

Router#show controllers downstream-cable 9/0/0 rf-channel 158 prof-status
Profile status:
-------------------------------------------------------
Control profile: Oper state: UP, Modem count: 1
Modem list: 4800.33ef.3aea
Data profile 1: Oper state: UP, Modem count: 0
Modem list: 4800.33ef.06ca 4800.33ef.0d1a 4800.33ea.716a 4800.33ef.3c52
Description Link
ID and password.
Feature Information for Downstream Profile Selection

583
Feature Information for Downstream Profile Selection
Table 99: Feature Information for Downstream Profile Selection
Downstream Profile Cisco IOS XE Everest This feature was integrated into Cisco IOS XE
Selection 16.6.1 Everest 16.6.1 on the Cisco cBR Series Converged
Broadband Routers.
584
CHAPTER 37
DOCSIS 3.1 Commanded Power for Upstream
SC-QAMs
This guide describes commanded power for upstream SC-QAMs on the Cisco cBR Router.
• Information About Commanded Power Feature for Upstream SC-QAMs, on page 587
• Feature TLVs, on page 587
• Feature Information for Commanded Power for US SC-QAMs, on page 588
585
Digital PICs:

Module:

Modules:
line card reload.
586
Information About Commanded Power Feature for Upstream SC-QAMs
Information About Commanded Power Feature for Upstream

SC-QAMs
Commanded Power feature for UpStream Single Carrier Quadrature Amplitude Modulation (US SC-QAMs)
supports a new method during ranging to dynamically set the transmit power level of a DOCSIS 3.1 cable
modem.
To view the new commanded power levels pr upstream, use the following command:
Router# show cable modem [ ip-address | mac-address | cable {slot /subslot
/cable-interface-index}] verbose
Note DOCSIS 3.1 Commanded Power feature is enabled by default.
Feature TLVs
TLVs Affected by Commanded Power for US SC-QAMs
The following table lists the TLVs affected by the DOCSIS 3.1 Ranging Response (RNG-RSP) Commanded
Power for upstream SC-QAMs:
Name Type DOCSIS 3.1 Value
Power Level Adjust 2 TX Power offset adjustment (signed

8-bit, 1/4-dB units)
Power Offset 12.4.4 TX Power offset adjustment (signed

8-bit, 1/4-dB units)
Dynamic Range Window Upper 14 The upper edge of the Dynamic

Edge Range Window expressed in units
1/4 dB below the max allowable
setting (Phi) [DOCSIS PHYv3.0].
Commanded Power 17 This TLV contains the Dynamic

Range Window value,
P1.6load_min_set as well as the
Transmit Power Level for each of
the channels in the CM's Transmit
Channel Set, expressed in units of
quarter dBmV.
Commanded Power Sub-TLVs

The following table lists the sub-TLVs for DOCSIS 3.1 Commanded Power:
587
Name Type (1 byte) Length (1 byte) Value (Variable Length)
Commanded Power 17 5 + 3*N
Dynamic Range Window 17.1 1 The range, in decibels, of

the maximum difference
in power per 1.6 MHz
between multiple
transmitters in a cable
modem’s Transmit
Channel Set.
List of Upstream Channel 17.2 3*N Values for each channel

IDs and Corresponding in the TCS:
Transmit Power Levels
• Bits 23 to 16: UCID
• Bits 15 to 0:
Transmit Power
Level (quarter
dBmV)
Description Link
ID and password.
Feature Information for Commanded Power for US SC-QAMs

588
Table 101: Feature Information for Commanded Power Feature
DOCSIS 3.1 Commanded Power Cisco IOS XE Fuji This feature was integrated on the Cisco cBR
for US SC-QAMs 16.7.1 Series Converged Broadband Routers.
589
590
CHAPTER 38
DOCSIS3.1 Downstream Resiliency for OFDM
channel
This document describes how to configure the DOCSIS3.1 Downstream Resiliency for OFDM channel on
the Cisco cBR Series Converged Broadband Router.
• Information about DOCSIS3.1 Downstream Resiliency for OFDM Channel, on page 593
• How to Configure DOCSIS3.1 Downstream Resiliency for OFDM Channel, on page 594
• Feature Information for DOCSIS3.1 Downstream Resiliency for OFDM Channel, on page 595
591
Digital PICs:

Module:

Modules:
line card reload.
592
Information about DOCSIS3.1 Downstream Resiliency for OFDM Channel
Information about DOCSIS3.1 Downstream Resiliency for OFDM

Channel
When DOCSIS3.1 CM reports non-primary RF channel failure for SCQAM or OFDM channel, actions
performed by downstream resiliency is the same as DOCSIS3.0 CM. In other words, if RF channel impairment
is below the resiliency threshold, CMs service flows are moved to Resiliency Bonding Group (RBG) or Narrow
Band (NB) interface. If RF channel impairment is above the resiliency threshold, the impaired RF channel is
temporarily removed from the bonding group.
The following table summarizes the CM-STATUS events for OFDM channel, and the action to be taken by
the downstream resiliency module:
Table 103: CM-STATUS events for OFDM channel
Event Type Code Event Description DS Resiliency Action
1 MDD timeout Move CM’s service flows to

RBG/NB or suspend RF from BG.
2 FEC lock failure Move CM’s service flows to

4 MDD recovery Move CM’s service flows back to

original BG.
5 FEC lock recovery Move CM’s service flows back to

original BG.
16 DS OFDM profile failure. A loss DS OFDM Profile Manager will

of FEC lock on one of the assigned handle this event and take action.
downstream OFDM profiles of a
channel.
20 NCP profile failure. Loss of FEC Move CM's service flows to

lock on NCP. RBG/NB or suspend RF from BG.
21 Loss of FEC lock on the PLC. Move CM's service flows to

22 NCP profile recovery. Move CM's service flows back to

original BG.
23 FEC recovery on PLC channel. Move CM's service flows back to

original BG.
24 FEC recovery on OFDM profile. Recovery of impairment reported

by event 16. DS OFDM Profile
Manager will handle this event and
take action.
593
How to Configure DOCSIS3.1 Downstream Resiliency for OFDM Channel
How to Configure DOCSIS3.1 Downstream Resiliency for OFDM

Channel
Configuring DOCSIS3.1 Downstream Resiliency for OFDM Channel
User must configure the command cable rf-change-trigger percent value count number to enable the
downstream resiliency functionality.
To configure the trigger thresholds specific to OFDM RF impairment, follow the steps below:
enable
configure terminal
cable ofdm-rf-change-trigger percent value counter number [no-ncp-plc]
Starting from Cisco IOS XE Fuji 16.10.1d release, you can exclude NCP and PLC reports separately by
following these steps:
enable
configure terminal
cable ofdm-rf-change-trigger percent value counter number [no-ncp] [no-plc]
Trigger thresholds value and number apply globally to the non-primary OFDM RF channels. If this command
is not configured, the trigger thresholds configured by the command cable rf-change-trigger percent value
count number will be used for the non-primary OFDM channels.
With no-ncp-plc configured in the command, this feature will not take any action when CM reports
CM-STATUS-EVENT 20 or 21.
Note The cable rf-change-trigger percent value count number command is optional and the configured trigger
thresholds apply to non-primary OFDM channels only.
Displaying OFDM Specific CM-STATUS Events

To display the statistics of the OFDM specific CM-STATUS events, use the show cable modem wideband
rcs-status command as shown in the example below:
router#show cable modem 4800.33ea.7072 wideband rcs-status verbose
CM : 4800.33ea.7072
RF : 3/0/0 0
Status : UP
FEC/QAM Failure : 0
Dup FEC/QAM Failure : 0
FEC/QAM Recovery : 0
Dup FEC/QAM Recovery : 0
MDD Failure : 0
Dup MDD Failure : 0
MDD Recovery : 0
Dup MDD Recovery : 0
Flaps : 0
Flap Duration : 00:00
594
Feature Information for DOCSIS3.1 Downstream Resiliency for OFDM Channel
RF : 3/0/0 1
Status : UP
FEC/QAM Failure : 0
MDD Failure : 0
Dup MDD Failure : 0
MDD Recovery : 0
Flaps : 0
RF : 3/0/0 159
Status : UP
FEC/QAM Failure : 0
MDD Failure : 0
Dup MDD Failure : 0
MDD Recovery : 0
NCP PROF Failure : 2 May 8 15:14:24
Dup NCP PROF Failure : 0
NCP PROF Recovery : 1 May 8 15:15:18
Dup NCP PROF Recovery : 0
PLC Lock Failure : 1 May 8 15:14:47
Dup PLC Lock Failure : 0
PLC Lock Recovery : 1 May 8 15:15:46
Dup PLC Lock Recovery : 0
Flaps : 0
OFDM Profile Id : 2
Status : UP
Profile Failure : 1 May 8 15:16:18
DUP Profile Failure : 0
Profile Recovery : 1 May 8 15:16:44
DUP Profile Recovery : 0
Feature Information for DOCSIS3.1 Downstream Resiliency for

OFDM Channel
595
Feature Information for DOCSIS3.1 Downstream Resiliency for OFDM Channel
Table 104: Feature Information for DOCSIS3.1 Downstream Resiliency for OFDM Channel
DOCSIS3.1 Downstream Resiliency Cisco IOS XE Everest This feature was integrated on the Cisco
for OFDM Channel 16.7.1 cBR Series Converged Broadband Routers.
596
CHAPTER 39
DOCSIS 3.1 OFDMA Channel Configuration
This document describes how to configure the OFDMA channel on the Cisco cBR Series Converged Broadband
Router.
• Information about OFDMA Channel Configuration, on page 599
• Configure OFDMA Channel, on page 600
• Feature Information for DOCSIS 3.1 OFDMA Channel Configuration, on page 616
597
Digital PICs:

Module:

Modules:
line card reload.
598
Information about OFDMA Channel Configuration
Information about OFDMA Channel Configuration

OFDMA Channels
backward compatibility to DOCSIS 3.0. Orthogonal Frequency Division Multiple Access (OFDMA) channel
has following features:
• Frequency-range up to 96 MHz
• Upstream spectrum 5 – 204 MHz
• 25 kHz subcarrier spacing
• OFDMA Channel-width up to 80 MHz - The Cisco IOS XE Fuji 16.7.x release supports configuration
of a single 80 MHz OFDMA channel on every port of a line card.
• OFDMA Channel-width up to 96 MHz - The Cisco IOS XE 16.8.x release supports configuration of a
single 96 MHz OFDMA channel on every port of a line card.
• OFDMA Upstream spectrum 5 – 85 MHz - The Cisco IOS XE Fuji 16.7.x supports a maximum frequency
value of 85 Mhz for an OFDMA channel.
• OFDMA Upstream spectrum 5 – 204 MHz - The Cisco IOS XE 16.8.x extends the supported maximum
frequency value of an OFDMA channel from 85 Mhz to 204 Mhz.
For a specific subcarrier spacing, the number of subcarriers on an OFDMA channel depends on the channel
width.
Channel Width 50 kHz 25 kHz
48 MHz 960 1920
96 MHz 1920 3840
Note When the OFDMA is configured with SC-QAMs on the same port pair, it is recommended to configure no
more than 45 MHz OFDMA per port, or 90 MHz per port pair in Cisco IOS XE Everest Release 16.6.1.
Modulation Profile
A globally configured OFDMA modulation profile defines modulation orders and pilot patterns for different
interval usage codes (IUC). You can also use it to assign parameters for initial ranging and fine ranging.
The following table gives information on the supported modulation orders.
Modulation Order Support
BPSK Yes
599
OFDMA Channel Exclusion Band
Modulation Order Support
QPSK Yes
8-QAM Yes
16-QAM Yes
32-QAM Yes
64-QAM Yes
128-QAM Yes
256-QAM Yes
512-QAM Yes
1024-QAM Yes
2048-QAM Yes
4096-QAM No
OFDMA Channel Exclusion Band

Ranges of frequencies can be excluded from all OFDMA channels on a port using the
ofdma-frequency-exclusion-band command.
Exclusion and unused bands apply to OFDMA channels only. OFDMA channel never use frequencies in
exclusion band. So the legacy SC-QAM channel can be placed in this band. OFDMA channel does not use
frequencies in unused band set by ofdma-frequency-unused-band command for data traffic, but can send
probes in them.
Configure OFDMA Channel

Configuring OFDMA Controller Profile
To configure upstream controller profile, follow the steps below:
enable
configure terminal
cable mod-profile-ofdma id
initial-rng-subcarrier value
fine-rng-subcarrier value
data-iuc id modulation value pilot-pattern value
Here is a configuration example:

Router# enable
600
Verifying OFDMA Modulation Profile Configuration
Router(config)#cable mod-profile-ofdma 425

Router(config)#subcarrier-spacing 25KHz
Router(config)#initial-rng-subcarrier 64
Router(config)#fine-rng-subcarrier 192
Router(config)#data-iuc 5 modulation 2048-QAM pilot-pattern 11
Router(config)# cable mod-profile-ofdma 466
Router(config-ofdma-mod-profile)# subcarrier-spacing 50KHz
Router(config-ofdma-mod-profile)# initial-rng-subcarrier 64
Router(config-ofdma-mod-profile)# fine-rng-subcarrier 128
Router(config-ofdma-mod-profile)# data-iuc 13 modulation 1024-QAM pilot-pattern 2
Router(config-ofdma-mod-profile)# exit
Note Subcarrier spacing must match the subcarrier spacing of each channel profile in which it is configured.
Verifying OFDMA Modulation Profile Configuration

To display the OFDMA modulation profile details, use the show cable modulation-profile ofdma command
Router# show cable modulation-profile ofdma
Mod Subc IUC type Act Preamble Bit Pilot
Spacing subc Symbols Loading Pattern
421 25KHz 3 (IR) 64 4
4 (FR) 192 1
13 (data) 16-QAM 8
423 25KHz 3 (IR) 64 4

4 (FR) 128 1
6 (data) 1024-QAM 8
10 (data) 512-QAM 8
11 (data) 256-QAM 8
12 (data) 128-QAM 9
13 (data) 64-QAM 9
461 50KHz 3 (IR) 32 4

4 (FR) 192 1
13 (data) 16-QAM 1
466 50KHz 3 (IR) 64 4

4 (FR) 128 1
601
Configuring OFDMA Channel
13 (data) 1024-QAM 2

Feature History
Remote PHY 2 OFDMA channels Cisco IOS XE Bengaluru 17.6.1x This feature allows you to
per controller support configure two OFDMA channels
on the same Upstream-Cable
controller in a Remote PHY
deployment.
To configure the OFDMA channel, follow these steps:

enable
configure terminal
controller Upstream-Cable slot/subslot/port
us-channel id docsis-mode ofdma
us-channel id subcarrier-spacing value
us-channel id frequency-range start-value end-value
us-channel id modulation-profile id
us-channel id cyclic-prefix value roll-off-period value
us-channel id symbols-per-frame value
us-channel id data-iuc id band start-value end-value modulation value pilot-pattern
value

Router# enable
Router(config)# controller Upstream-Cable 1/0/4
Router(config-controller)# us-channel 12 docsis-mode ofdma
Router(config-controller)# us-channel 12 subcarrier-spacing 25KHz
Router(config-controller)# us-channel 12 frequency-range 40000000 85000000
Router(config-controller)# us-channel 12 modulation-profile 423
Router(config-controller)# us-channel 12 cyclic-prefix 640 roll-off-period 224
Router(config-controller)# us-channel 12 symbols-per-frame 9
Router(config-controller)# us-channel 12 data-iuc 9 band 50000000 60000000 modulation 512-QAM
pilot-pattern 8
This is a configuration example for two OFDMA channels in Remote PHY deployment:
Router# enable
Router(config)# cable upstream controller profile 1
Router(config-controller-profile)# us-channel 12 docsis-mode ofdma
Router(config-controller-profile)# us-channel 12 subcarrier-spacing 25KHz
Router(config-controller-profile)# us-channel 12 modulation-profile 423
Router(config-controller-profile)# us-channel 12 frequency-range 40000000 85000000
Router(config-controller-profile)# us-channel 12 initial-rng-frequency-start 50000000
Router(config-controller-profile)# us-channel 12 cyclic-prefix 96 roll-off-period 64
Router(config-controller-profile)# us-channel 12 symbols-per-frame 12
Router(config-controller-profile)# no us-channel 12 shutdown
602
Router(config-controller-profile)# us-channel 13 docsis-mode ofdma

Router(config-controller-profile)# us-channel 13 subcarrier-spacing 25KHz
Router(config-controller-profile)# us-channel 13 modulation-profile 423
Router(config-controller-profile)# us-channel 13 frequency-range 108000000 204000000
Router(config-controller-profile)# us-channel 13 initial-rng-frequency-start 118000000
Router(config-controller-profile)# us-channel 13 cyclic-prefix 96 roll-off-period 64
Router(config-controller-profile)# us-channel 13 symbols-per-frame 12
Router(config-controller-profile)# no us-channel 13 shutdown

Router(config)# cable rpd rpd-20
Router(config-rpd)# description RPD20
Router(config-rpd)# identifier badb.1111.1111
Router(config-rpd)# core-interface Te7/1/3
Router(config-rpd-core)# principal
Router(config-rpd-core)# rpd-ds 0 downstream-cable 7/0/31 profile 2
Router(config-rpd-core)# rpd-us 0 upstream-cable 7/0/63 profile 1
Note • OFDMA uses us-channel range 12–15.

• Change docsis-mode to ofdma to enable OFDMA configuration options. These options are enabled by
default on us-channel 12–15.
• The default us-channel is 12 docsis-mode (does not return configuration to default).
• In Cisco IOS XE Fuji 16.7.x and earlier releases, we recommend that you configure no more than four
active SC-QAMs on the same controller while an OFDMA channel is present.
• You can configure a maximum of one OFDMA channel per controller. Starting from Cisco IOS XE
Gibraltar 16.10.x release, two OFDMA channels—us-channel 12 and us-channel 13 can be configured
per controller. Starting from Cisco IOS XE Bengaluru 17.6.1x release, you can configure two OFDMA
channels in Remote PHY deployment.
• In Cisco IOS XE Everest 16.6.x release, place the OFDMA channel in the range from 40 through 85
MHz.
• In Cisco IOS XE Fuji 16.7.x and following releases, place OFDMA channels in the range from 5 through
85 MHz.
• Values of the options are often interdependent, changing one value may change other values or make
them invalid.
• We recommend setting the subcarrier spacing and frequency range first. Frequency range must be
increments of 50 kHz.
• Each fiber node supports two OFDMA channels.
• Each bonding group supports two OFDMA channels.
• Each controller pair supports a maximum of 192-Mhz OFDMA spectrum in iCCAP deployment.
• Each CBR-CCAP-LC-G2-R card supports a maximum of 32 OFDMA channels.
603
Verifying OFDMA Channel Configuration
Verifying OFDMA Channel Configuration

To display the OFDMA channel configuration, use the show controllers upstream-Cable us-channel
Router# show controllers upstream-Cable 1/0/4 us-channel 12
USPHY OFDMA support: FULL

ofdma mode enabled
Channel Freq Range 35.500 MHz to 79.500 MHz
Channel Subcarrier Index Range Cfg: 74, 953 Op: 74, 953
Channel SC0 Freq Cfg: 31.800 MHz Op: 31.800 MHz
#Excl bands: 2
( 0, 73), ( 954, 2047),
#Unused bands: 0
Cyclic Prefix Size 96, Rolloff Period Size 64
Subcarrier Spacing 50KHz, Symbols Per Frame 18 Subcarrier Per Minislot: 8
Modulation Profile (ID 466, Subcarrier Spacing 50KHz)

IUC type Cfg Act Preamble Bit Pilot
subc subc Symbols Loading Pattern
3 (IR) 64 64 4 - -
4 (FR) 128 128 1 - -
13 (data) - - - 1024-QAM 2
Calculated Data burst profile:
IUC Group Bit Pilot Start Consec
Loading Pattern Mslot Mslot
13 0 1024-QAM 2 0 109
#Total mslots:110 #Fine Rng capable:95 #Initial Rng capable:103

Initial Rng - Freq 50.000MHz mslotOffset:36 #mslot in frame:8
Minislot mapping: mslot#(start_sc start_freq(Mhz) end_sc end_freq(Mhz)
mslot type(E-Edge; B-Body; S-Share with SCQAM;
I-Initial rng capable; F-Fine rng capable)
(next Fine Rng capable minislot if current is not capable))
0 ( 74, 35.500, 81, 35.850, EIF ( - )), 1 ( 82, 35.900, 89, 36.250, BIF ( - )),
2 ( 90, 36.300, 97, 36.650, BIF ( - )), 3 ( 98, 36.700, 105, 37.050, BIF ( - )),
4 ( 106, 37.100, 113, 37.450, BIF ( - )), 5 ( 114, 37.500, 121, 37.850, BIF ( - )),
6 ( 122, 37.900, 129, 38.250, BIF ( - )), 7 ( 130, 38.300, 137, 38.650, BIF ( - )),
8 ( 138, 38.700, 145, 39.050, BIF ( - )), 9 ( 146, 39.100, 153, 39.450, BIF ( - )),
10 ( 154, 39.500, 161, 39.850, BIF ( - )), 11 ( 162, 39.900, 169, 40.250, BIF ( - )),
12 ( 170, 40.300, 177, 40.650, BIF ( - )), 13 ( 178, 40.700, 185, 41.050, BIF ( - )),
14 ( 186, 41.100, 193, 41.450, BIF ( - )), 15 ( 194, 41.500, 201, 41.850, BIF ( - )),
16 ( 202, 41.900, 209, 42.250, BIF ( - )), 17 ( 210, 42.300, 217, 42.650, BIF ( - )),
18 ( 218, 42.700, 225, 43.050, BIF ( - )), 19 ( 226, 43.100, 233, 43.450, BIF ( - )),
20 ( 234, 43.500, 241, 43.850, BIF ( - )), 21 ( 242, 43.900, 249, 44.250, BIF ( - )),
22 ( 250, 44.300, 257, 44.650, BIF ( - )), 23 ( 258, 44.700, 265, 45.050, BIF ( - )),
24 ( 266, 45.100, 273, 45.450, BIF ( - )), 25 ( 274, 45.500, 281, 45.850, BIF ( - )),
26 ( 282, 45.900, 289, 46.250, BIF ( - )), 27 ( 290, 46.300, 297, 46.650, BIF ( - )),
28 ( 298, 46.700, 305, 47.050, BIF ( - )), 29 ( 306, 47.100, 313, 47.450, BIF ( - )),
30 ( 314, 47.500, 321, 47.850, BIF ( - )), 31 ( 322, 47.900, 329, 48.250, BIF ( - )),
32 ( 330, 48.300, 337, 48.650, BIF ( - )), 33 ( 338, 48.700, 345, 49.050, BIF ( - )),
34 ( 346, 49.100, 353, 49.450, BIF ( - )), 35 ( 354, 49.500, 361, 49.850, BIF ( - )),
36 ( 362, 49.900, 369, 50.250, BIF ( - )), 37 ( 370, 50.300, 377, 50.650, BIF ( - )),
38 ( 378, 50.700, 385, 51.050, BIF ( - )), 39 ( 386, 51.100, 393, 51.450, BIF ( - )),
40 ( 394, 51.500, 401, 51.850, BIF ( - )), 41 ( 402, 51.900, 409, 52.250, BIF ( - )),
42 ( 410, 52.300, 417, 52.650, BIF ( - )), 43 ( 418, 52.700, 425, 53.050, BIF ( - )),
44 ( 426, 53.100, 433, 53.450, BIF ( - )), 45 ( 434, 53.500, 441, 53.850, BIF ( - )),
46 ( 442, 53.900, 449, 54.250, BIF ( - )), 47 ( 450, 54.300, 457, 54.650, BIF ( - )),
48 ( 458, 54.700, 465, 55.050, BIF ( - )), 49 ( 466, 55.100, 473, 55.450, BIF ( - )),
604
Configure Exclusion / Unused Bands
50 ( 474, 55.500, 481, 55.850, BIF ( - )), 51 ( 482, 55.900, 489, 56.250, BIF ( - )),
52 ( 490, 56.300, 497, 56.650, BIF ( - )), 53 ( 498, 56.700, 505, 57.050, BIF ( - )),
54 ( 506, 57.100, 513, 57.450, BIF ( - )), 55 ( 514, 57.500, 521, 57.850, BIF ( - )),
56 ( 522, 57.900, 529, 58.250, BIF ( - )), 57 ( 530, 58.300, 537, 58.650, BIF ( - )),
58 ( 538, 58.700, 545, 59.050, BIF ( - )), 59 ( 546, 59.100, 553, 59.450, BIF ( - )),
60 ( 554, 59.500, 561, 59.850, BIF ( - )), 61 ( 562, 59.900, 569, 60.250, BIF ( - )),
62 ( 570, 60.300, 577, 60.650, BIF ( - )), 63 ( 578, 60.700, 585, 61.050, BIF ( - )),
64 ( 586, 61.100, 593, 61.450, BIF ( - )), 65 ( 594, 61.500, 601, 61.850, BIF ( - )),
66 ( 602, 61.900, 609, 62.250, BIF ( - )), 67 ( 610, 62.300, 617, 62.650, BIF ( - )),
68 ( 618, 62.700, 625, 63.050, BIF ( - )), 69 ( 626, 63.100, 633, 63.450, BIF ( - )),
70 ( 634, 63.500, 641, 63.850, BIF ( - )), 71 ( 642, 63.900, 649, 64.250, BIF ( - )),
72 ( 650, 64.300, 657, 64.650, BIF ( - )), 73 ( 658, 64.700, 665, 65.050, BIF ( - )),
74 ( 666, 65.100, 673, 65.450, BIF ( - )), 75 ( 674, 65.500, 681, 65.850, BIF ( - )),
76 ( 682, 65.900, 689, 66.250, BIF ( - )), 77 ( 690, 66.300, 697, 66.650, BIF ( - )),
78 ( 698, 66.700, 705, 67.050, BIF ( - )), 79 ( 706, 67.100, 713, 67.450, BIF ( - )),
80 ( 714, 67.500, 721, 67.850, BIF ( - )), 81 ( 722, 67.900, 729, 68.250, BIF ( - )),
82 ( 730, 68.300, 737, 68.650, BIF ( - )), 83 ( 738, 68.700, 745, 69.050, BIF ( - )),
84 ( 746, 69.100, 753, 69.450, BIF ( - )), 85 ( 754, 69.500, 761, 69.850, BIF ( - )),
86 ( 762, 69.900, 769, 70.250, BIF ( - )), 87 ( 770, 70.300, 777, 70.650, BIF ( - )),
88 ( 778, 70.700, 785, 71.050, BIF ( - )), 89 ( 786, 71.100, 793, 71.450, BIF ( - )),
90 ( 794, 71.500, 801, 71.850, BIF ( - )), 91 ( 802, 71.900, 809, 72.250, BIF ( - )),
92 ( 810, 72.300, 817, 72.650, BIF ( - )), 93 ( 818, 72.700, 825, 73.050, BIF ( - )),
94 ( 826, 73.100, 833, 73.450, BIF ( - )), 95 ( 834, 73.500, 841, 73.850, BI (0 )),
96 ( 842, 73.900, 849, 74.250, BI (0 )), 97 ( 850, 74.300, 857, 74.650, BI (0 )),
98 ( 858, 74.700, 865, 75.050, BI (0 )), 99 ( 866, 75.100, 873, 75.450, BI (0 )),
100( 874, 75.500, 881, 75.850, BI (0 )), 101( 882, 75.900, 889, 76.250, BI (0 )),
102( 890, 76.300, 897, 76.650, BI (0 )), 103( 898, 76.700, 905, 77.050, B (0 )),
104( 906, 77.100, 913, 77.450, B (0 )), 105( 914, 77.500, 921, 77.850, B (0 )),
106( 922, 77.900, 929, 78.250, B (0 )), 107( 930, 78.300, 937, 78.650, B (0 )),
108( 938, 78.700, 945, 79.050, B (0 )), 109( 946, 79.100, 953, 79.450, B (0 )),
Mapped to connector 4 and receiver 108
Bind to Cable1/0/4 US4

MER(SNR) - Unknown - no modems online.
Spectrum Group is unassigned
Nominal Input Power Level 0 dBmV
UCD procedures on lch 0

UCD ucd-proxy-timeout (0 ) ucd-proxy-wrong-ack (0 )
Configure Exclusion / Unused Bands

An OFDMA channel never use frequencies located in exclusion bands. OFDMA probes will be sent on
frequencies located in the unused bands. Therefore exclusion bands must be used to prevent interference with
SC-QAM channels. To configure the Exclusion / Unused Bands, follow the steps below:
enable
configure terminal
cable ofdma-frequency-exclusion-band start-value end-value
cable ofdma-frequency-unused-band start-value end-value
Router# enable
Router(config-controller)# cable ofdma-frequency-exclusion-band 48000000 54200000
Router(config-controller)# cable ofdma-frequency-unused-band 50000000 52000000
605
Verifying Exclusion / Unused Bands

Verifying Exclusion / Unused Bands

To display the Exclusion / Unused Band configuration, use the show controllers upstream-Cable us-channel
Controller Exclusion Freq List:

( 40.000 MHz, 44.200 MHz),
Controller Unused Freq List:
( 50.000 MHz, 52.000 MHz),

ofdma mode enabled
#Excl bands: 3
( 0, 147), ( 608, 776), (1788, 4095),
#Unused bands: 3
( 596, 607), (1001, 1088), (1777, 1787),
Override OFDMA Profile Per Channel

It is possible to override the modulation and pilot pattern used by a particular IUC on a given OFDMA channel
as shown with the command below.
enable
configure terminal
us-channel id data-iuc id band start-value end-value modulation value pilot-pattern
value

Router# enable
Router(config-controller)# us-channel 12 data-iuc 6 band 60000000 65000000 modulation 128-QAM
pilot-pattern 9
606
Override OFDMA Profile Per Channel
Note Override values will be removed from US channel when changing modulation profile, including when profile
changes due to changes in subcarrier spacing.
From Cisco cBR Series Converged Broadband Router 16.12.1w and later, the limitation of one IUC override
per IUC configuration no longer applies for cBR-8 I-CMTS controller implementations on the
CBR-LC-8D31-16U31 line card and R-PHY implementations on CBR-LC-8D31-16U31,
CBR-CCAP-LC-40G-R, and CBR-CCAP-LC-G2-R line cards. The OFDMA - 4 override zones per IUC
feature increases the number of overrides that can be defined to four per IUC.
A maximum channel configuration would appear as below:

us-channel 12 data-iuc 5 band 40500000 41500000 modulation 64-QAM pilot-pattern 8
This allows nine modulation zones per profile across the channel. So, for example, for a modem using IUC
5, the channel modulation would be as follows:
router# show controller Upstream-Cable 1/0/0 us-channel 12 cdm-ump | beg Rang

Ranging profile:
IUC 3, preamble_len 256, sc mode 25KHz active_sc 64 guard_sc 0
IUC 4, preamble_len 192, sc mode 25KHz active_sc 192 guard_sc 0
5 0 1024-QAM 8 0 24
5 1 64-QAM 8 25 1
5 2 1024-QAM 8 27 1
5 3 128-QAM 8 29 2
5 4 1024-QAM 8 32 1
5 5 256-QAM 8 34 2
5 6 1024-QAM 8 37 1
607
Verifying Override Configuration
5 7 512-QAM 8 39 2
5 8 1024-QAM 8 42 42
...
Note • All subcarriers within a single OFDMA minislot must be assigned the same modulation order. Different
modulation orders cannot be assigned to different subcarriers within the same minislot.
• If a modulation override configuration is applied that places the frequency start and/or end within the
middle of a minislot, the entire minislot will receive the override configuration.
• If two adjacent modulation overrides overlap the same minislot, the minislot receives the modulation
configuration of the last override configuration. In most cases this will be the higher frequency override
modulation.
• For the RPHY cards, the OFDMA - 4 override zones per IUC enhancement is supported with all RPD
types that support OFDMA.
Verifying Override Configuration

To display the override configuration, use the show controllers upstream-Cable us-channel command as
.....
3 (IR) 64 64 4 - -
4 (FR) 128 128 1 - -
6 (data) - - - 1024-QAM 8
10 (data) - - - 512-QAM 8
11 (data) - - - 256-QAM 8
12 (data) - - - 128-QAM 9
13 (data) - - - 64-QAM 9
Overwrite Data Profile:
IUC Start End Start End Bit Pilot
Freq(MHz) Freq(MHz) Subc Subc Loading Pattern
6 60.0 65.0 1408 1608 128-QAM 9

6 0 1024-QAM 8 0 61
6 1 128-QAM 9 62 11
6 2 1024-QAM 8 74 10
10 0 512-QAM 8 0 84
11 0 256-QAM 8 0 84
12 0 128-QAM 9 0 84
13 0 64-QAM 9 0 84
......
608
Apply OFDMA Upstream To Cable Interface
Apply OFDMA Upstream To Cable Interface

To associate upstream channels with a MAC domain and configure upstream bonding, follow the steps below:
enable
configure terminal
interface Cable slot/subslot/interface
cable upstream bonding-group id
upstream id
attributes value
cable bundle id

Router# enable
Router(config-if)# downstream Integrated-Cable 1/0/4 rf-channel 0
Router(config-if)# downstream Integrated-Cable 1/0/4 rf-channel 16
Router(config-if)# upstream 0 Upstream-Cable 1/0/0 us-channel 0
Router(config-if)# cable upstream bonding-group 1
Router(config-upstream-bonding)# upstream 0
Router(config-upstream-bonding)# attributes 80000000
Router(config-upstream-bonding)# exit
Router(config-if)# cable upstream bonding-group 2
Router(config-upstream-bonding)# attributes 80000000
Router(config-upstream-bonding)# exit
Router(config-if)# cable bundle 1
Determine DOCSIS 3.1 Cable Modems and the Cable Modems Using OFDMA
Upstreams
To display the DOCSIS 3.1 cable modem, use the show cable modem docsis version d31-capable command
Router# show cable modem docsis version d31-capable
MAC Address I/F MAC Reg Oper DSxUS DS RCC US
State Ver Ver OFDM ID OFDMA
4800.33ea.7012 C1/0/0/UB w-online(pt) 3.1 3.1 33x4 1 5 1
203d.66ae.4169 C1/0/0/UB w-online(pt) 3.1 3.1 33x4 1 5 1
To display DOCSIS PHY layer information for the cable modem, use the show cable modem phy command
Router# show cable modem 5039.5584.5bbe phy
MAC Address I/F Sid USPwr USMER Timing DSPwr DSMER Mode DOCSIS
609
Determine DOCSIS 3.1 Cable Modems and the Cable Modems Using OFDMA Upstreams
(dBmV) (SNR) Offset (dBmV) (SNR) Prov

(dB) (dB)
5039.5584.5bbe C1/0/0/U0 15 38.75 ----- 2282 0.00 ----- ofdma 1.1
To display the cable modem using OFDMA upstream, use the show cable modem phy command as shown
Router# show cable modem phy | include ofdma
5039.5584.5bbe C1/0/0/U0 15 38.75 ----- 2282 0.00 ----- ofdma 1.1
0895.2a9b.26f1 C1/0/0/U0 16 28.00 ----- 2146 0.00 ----- ofdma 1.1
To display the OFDMA channel capacity and utilization, use the show interface cable mac-scheduler
Router# show interfaces cable 1/0/2 mac-scheduler 6
Max potential performance for each configured IUC type
IUC: 6 rate: 279807192
IUC: 10 rate: 263104848
IUC: 11 rate: 233779840
IUC: 12 rate: 203019328
IUC: 13 rate: 173899376
wfq:None
us_balance:OFF
dpon_mode:OFF
fairness:OFF
Req Slots 38510548
Req/Data Slots 1275
Init Mtn Slots 47832
Stn Mtn Slots 0
IUC 5 Slots 0
IUC 6 Slots 6378
IUC 9 Slots 0
IUC 10 Slots 254923830
IUC 11 Slots 220
IUC 12 Slots 4006
IUC 13 Slots 251213508

610
Verifying DOCSIS 3.1 Upstream OFDMA channel bonding across DOCSIS 3.0 ATDMA channels
Verifying DOCSIS 3.1 Upstream OFDMA channel bonding across DOCSIS 3.0
ATDMA channels
Starting from Cisco IOS XE Everest 16.6.1 release, DOCSIS 3.1 Upstream OFDMA channel can be bonded
with DOCSIS 3.0 ATDMA channel. If the user wants to utilize non-best effort flows, it is recommended to
bond the OFDMA channel with one or more ATDMA channels. But be aware that in Cisco IOS XE Everest
16.6.1 release, a maximum of 1 OFDMA channel and 4 ATDMA channels can be bonded together.
Below is an output example showing the bonding group 8 has both OFDMA (channel 12) and ATDMA
channels (channel 0, 1, 2, 3).
upstream 0
upstream 1
upstream 2
upstream 3
attributes 80000000
upstream 0
upstream 1
upstream 2
upstream 3
upstream 6
attributes 80000000
cable bundle 1
end
Display the OFDMA Performance Statistics

Feature History
RPHY support for show cable Cisco IOS XE Bengaluru 17.6.1x This feature introduces the
upstream ofdma mer-fec command command show cable upstream
ofdma mer-fec in Remote PHY
deployment to get the channel
performance statistics for the
upstream OFDMA channel.
611
RPHY support for show cable Cisco IOS XE Bengaluru 17.6.1x This feature introduces the
upstream ofdma mer-fec command command show cable upstream
ofdma mer-fec in Remote PHY
deployment to get the channel
performance statistics for the
upstream OFDMA channel.
To display the OFDMA channel performance statistics at chassis level, use the show cable upstream ofdma
mer-fec command as shown in the example below:
Router#show cable upstream ofdma mer-fec
Upstream:IUC MER(dB) TotalFecCW CorrectedFecCW
UncorrFecCW UncorrCW% MD:upstream
UC1/0/0:U12:IR 0.00 0 0 0
0.0 Ca1/0/0:u6
UC1/0/0:U12:FR 0.00 0 0 0
0.0 Ca1/0/0:u6
UC1/0/0:U12:IUC5 43.50 551758 161625 199
0.188 Ca1/0/0:u6
UC1/0/0:U12:IUC6 0.00 0 0 0
0.0 Ca1/0/0:u6
UC1/0/0:U12:IUC9 35.50 222 193 0
0.0 Ca1/0/0:u6
UC1/0/0:U12:IUC10 0.00 0 0 0
0.0 Ca1/0/0:u6
UC1/0/0:U12:IUC11 0.00 0 0 0
0.0 Ca1/0/0:u6
UC1/0/0:U12:IUC12 0.00 0 0 0
0.0 Ca1/0/0:u6
UC1/0/0:U12:IUC13 43.50 107 0 0
0.0 Ca1/0/0:u6
UC1/0/0:U13:IR 0.00 0 0 0
0.0 Ca1/0/0:u7
UC1/0/0:U13:FR 0.00 0 0 0
0.0 Ca1/0/0:u7
UC1/0/0:U13:IUC5 45.70 545911 14257 1153
0.100 Ca1/0/0:u7
UC1/0/0:U13:IUC6 0.00 0 0 0
0.0 Ca1/0/0:u7
UC1/0/0:U13:IUC9 0.00 0 0 0
0.0 Ca1/0/0:u7
UC1/0/0:U13:IUC10 0.00 0 0 0
0.0 Ca1/0/0:u7
UC1/0/0:U13:IUC11 0.00 0 0 0
0.0 Ca1/0/0:u7
UC1/0/0:U13:IUC12 0.00 0 0 0
0.0 Ca1/0/0:u7
UC1/0/0:U13:IUC13 45.70 85 0 0
0.0 Ca1/0/0:u7
UC9/0/0:U12:IR 0.00 0 0 0
0.0 Ca9/0/0:u6
UC9/0/0:U12:FR 0.00 0 0 0
0.0 Ca9/0/0:u6
UC9/0/0:U12:IUC5 46.50 552047 1779 0
0.0 Ca9/0/0:u6
UC9/0/0:U12:IUC6 0.00 0 0 0
0.0 Ca9/0/0:u6
UC9/0/0:U12:IUC9 0.00 0 0 0
0.0 Ca9/0/0:u6
UC9/0/0:U12:IUC10 0.00 0 0 0
612
0.0 Ca9/0/0:u6
UC9/0/0:U12:IUC11 0.00 0 0 0
0.0 Ca9/0/0:u6
UC9/0/0:U12:IUC12 0.00 0 0 0
0.0 Ca9/0/0:u6
UC9/0/0:U12:IUC13 47.70 155 0 0
0.0 Ca9/0/0:u6
UC9/0/1:U12:IR 0.00 0 0 0
0.0 Ca9/0/1:u6
UC9/0/1:U12:FR 0.00 0 0 0
0.0 Ca9/0/1:u6
UC9/0/1:U12:IUC5 46.00 552906 6353 0
0.0 Ca9/0/1:u6
UC9/0/1:U12:IUC6 0.00 0 0 0
0.0 Ca9/0/1:u6
UC9/0/1:U12:IUC9 0.00 0 0 0
0.0 Ca9/0/1:u6
UC9/0/1:U12:IUC10 0.00 0 0 0
0.0 Ca9/0/1:u6
UC9/0/1:U12:IUC11 0.00 0 0 0
0.0 Ca9/0/1:u6
UC9/0/1:U12:IUC12 0.00 0 0 0
0.0 Ca9/0/1:u6
UC9/0/1:U12:IUC13 43.70 58 0 0
0.0 Ca9/0/1:u6
UC9/0/2:U12:IR 0.00 0 0 0
0.0 Ca9/0/2:u12
UC9/0/2:U12:FR 0.00 0 0 0
0.0 Ca9/0/2:u12
UC9/0/2:U12:IUC5 42.20 552542 194533 264
0.32 Ca9/0/2:u12
UC9/0/2:U12:IUC6 41.70 55 0 0
0.0 Ca9/0/2:u12
UC9/0/2:U12:IUC9 0.00 0 0 0
0.0 Ca9/0/2:u12
UC9/0/2:U12:IUC10 0.00 0 0 0
0.0 Ca9/0/2:u12
UC9/0/2:U12:IUC11 0.00 0 0 0
0.0 Ca9/0/2:u12
UC9/0/2:U12:IUC12 0.00 0 0 0
0.0 Ca9/0/2:u12
UC9/0/2:U12:IUC13 42.00 105 0 0
0.0 Ca9/0/2:u12
UC9/0/2:U13:IR 0.00 0 0 0
0.0 Ca9/0/2:u13
UC9/0/2:U13:FR 0.00 0 0 0
0.0 Ca9/0/2:u13
UC9/0/2:U13:IUC5 0.00 0 0 0
0.0 Ca9/0/2:u13
UC9/0/2:U13:IUC6 40.20 526632 40107 3
0.44 Ca9/0/2:u13
UC9/0/2:U13:IUC9 0.00 0 0 0
0.0 Ca9/0/2:u13
UC9/0/2:U13:IUC10 0.00 0 0 0
0.0 Ca9/0/2:u13
UC9/0/2:U13:IUC11 0.00 0 0 0
0.0 Ca9/0/2:u13
UC9/0/2:U13:IUC12 0.00 0 0 0
0.0 Ca9/0/2:u13
UC9/0/2:U13:IUC13 43.00 18 0 0
0.0 Ca9/0/2:u13
613
To display the channel specific OFDMA performance statistics, use the show controllers upstream-cable
Router#show controllers upstream-Cable 9/0/0 us-channel 12
Controller RPD US Port List:
DevID RPD ID US Port I/F Name

------ --------------- -------- --------- ------------
0 70b3.1791.4278 0 Te9/1/0 LC9_RPD1_3x6_RACK4
rpd_id upstream-Port mac_idx mac_chidx discontinuityTime pollCnt

------ ------------- ------- --------- ----------------- -------
70b3.1791.4278 0 336 7 Mon Jan 17 22:38:54 2022 2327
IUC IUC FEC FEC Post FEC Post RxMer Scheduled

NoEnergy NoPreamble Error
Type Tot. CWs Pass CWs Fail CWs Avg Grants
Bursts Bursts Bursts
3 IR 0 0 0 00.00 -
- - -
4 FR 0 0 0 00.00 -
- - -
5 (data) 552083 1779 0 46.50 299078
0 -1 -1
6 (data) 0 0 0 00.00 0
0 -1 -1
9 (data) 0 0 0 00.00 0
0 -1 -1
10 (data) 0 0 0 00.00 0
0 -1 -1
11 (data) 0 0 0 00.00 0
0 -1 -1
12 (data) 0 0 0 00.00 0
0 -1 -1
13 (data) 155 0 0 47.70 132
0 -1 -1

ofdma mode enabled
#Excl bands: 2
( 0, 147), ( 908, 4095),
#Unused bands: 1
( 900, 907),
Cyclic Prefix Size 96, Rolloff Period Size 0
Subcarrier Spacing 25KHz, Symbols Per Frame 9 Subcarrier Per Minislot: 16

3 (IR) 64 64 4 - -
4 (FR) 256 256 1 - -
5 (data) - - - 4096-QAM 14
6 (data) - - - 2048-QAM 12
9 (data) - - - 1024-QAM 12
10 (data) - - - 512-QAM 12
11 (data) - - - 256-QAM 12
12 (data) - - - 128-QAM 12
614
13 (data) - - - 64-QAM 12
5 0 4096-QAM 14 0 46
6 0 2048-QAM 12 0 46
9 0 1024-QAM 12 0 46
10 0 512-QAM 12 0 46
11 0 256-QAM 12 0 46
12 0 128-QAM 12 0 46
13 0 64-QAM 12 0 46
#Total mslots:47 #Fine Rng capable:32 #Initial Rng capable:44

Initial Rng - Freq 0.000MHz mslotOffset:15 #mslot in frame:4
Minislot mapping: mslot#(start_sc start_freq(Mhz) end_sc end_freq(Mhz) peer_scqam
mslot type(E-Edge; B-Body; S-Share with SCQAM;
I-Initial rng capable; F-Fine rng capable)
(next Fine Rng capable minislot if current is not capable))
0 ( 148, 60.500, 163, 60.875, EIF ( - )), 1 ( 164, 60.900, 179, 61.275, BIF
( - )),
2 ( 180, 61.300, 195, 61.675, BIF ( - )), 3 ( 196, 61.700, 211, 62.075, BIF
( - )),
4 ( 212, 62.100, 227, 62.475, BIF ( - )), 5 ( 228, 62.500, 243, 62.875, BIF
( - )),
6 ( 244, 62.900, 259, 63.275, BIF ( - )), 7 ( 260, 63.300, 275, 63.675, BIF
( - )),
8 ( 276, 63.700, 291, 64.075, BIF ( - )), 9 ( 292, 64.100, 307, 64.475, BIF
( - )),
10 ( 308, 64.500, 323, 64.875, BIF ( - )), 11 ( 324, 64.900, 339, 65.275, BIF
( - )),
12 ( 340, 65.300, 355, 65.675, BIF ( - )), 13 ( 356, 65.700, 371, 66.075, BIF
( - )),
14 ( 372, 66.100, 387, 66.475, BIF ( - )), 15 ( 388, 66.500, 403, 66.875, BIF
( - )),
16 ( 404, 66.900, 419, 67.275, BIF ( - )), 17 ( 420, 67.300, 435, 67.675, BIF
( - )),
18 ( 436, 67.700, 451, 68.075, BIF ( - )), 19 ( 452, 68.100, 467, 68.475, BIF
( - )),
20 ( 468, 68.500, 483, 68.875, BIF ( - )), 21 ( 484, 68.900, 499, 69.275, BIF
( - )),
22 ( 500, 69.300, 515, 69.675, BIF ( - )), 23 ( 516, 69.700, 531, 70.075, BIF
( - )),
24 ( 532, 70.100, 547, 70.475, BIF ( - )), 25 ( 548, 70.500, 563, 70.875, BIF
( - )),
26 ( 564, 70.900, 579, 71.275, BIF ( - )), 27 ( 580, 71.300, 595, 71.675, BIF
( - )),
28 ( 596, 71.700, 611, 72.075, BIF ( - )), 29 ( 612, 72.100, 627, 72.475, BIF
( - )),
30 ( 628, 72.500, 643, 72.875, BIF ( - )), 31 ( 644, 72.900, 659, 73.275, BIF
( - )),
32 ( 660, 73.300, 675, 73.675, BI (0 )), 33 ( 676, 73.700, 691, 74.075, BI
(0 )),
34 ( 692, 74.100, 707, 74.475, BI (0 )), 35 ( 708, 74.500, 723, 74.875, BI
(0 )),
36 ( 724, 74.900, 739, 75.275, BI (0 )), 37 ( 740, 75.300, 755, 75.675, BI
(0 )),
38 ( 756, 75.700, 771, 76.075, BI (0 )), 39 ( 772, 76.100, 787, 76.475, BI
(0 )),
40 ( 788, 76.500, 803, 76.875, BI (0 )), 41 ( 804, 76.900, 819, 77.275, BI
(0 )),
42 ( 820, 77.300, 835, 77.675, BI (0 )), 43 ( 836, 77.700, 851, 78.075, BI
(0 )),
44 ( 852, 78.100, 867, 78.475, B (0 )), 45 ( 868, 78.500, 883, 78.875, B
(0 )),
615
Feature Information for DOCSIS 3.1 OFDMA Channel Configuration
46 ( 884, 78.900, 899, 79.275, B (0 )),
Mapped to connector 0 and receiver 256

Bind to Cable9/0/0 US6
US phy MER(SNR)_estimate - Unknown
Spectrum Group is unassigned
Nominal Input Power Level 10 dBmV
UCD procedures on lch 0 ucd-proxy-timeout (0 )

UCD ucd-proxy-wrong-ack (1 )
Feature Information for DOCSIS 3.1 OFDMA Channel

Configuration
Table 108: Feature Information for DOCSIS 3.1 OFDMA Channel Configuration
DOCSIS 3.1 US 16 OFDMA Cisco IOS XE Fuji 16.7.1 This feature was integrated on the Cisco cBR
channel support per line card Series Converged Broadband Routers.
DOCSIS 3.1 US OFDMA channel Cisco IOS XE Fuji 16.7.1 This feature was integrated on the Cisco cBR
bonding across DOCSIS 3.0 Series Converged Broadband Routers.
ATDMA channels
TaFDM OFDMA Support Cisco IOS XE Fuji 16.7.1 This feature was integrated on the Cisco cBR
Series Converged Broadband Routers.
204 Mhz Maximum Frequency Cisco IOS XE Fuji 16.8.1 This feature was integrated on the Cisco cBR
OFDMA Support Series Converged Broadband Routers.
Remote PHY DOCSIS 3.1 Cisco IOS XE Fuji 16.9.1 This feature was integrated on the Cisco cBR
OFDMA Channel Configuration Series Converged Broadband Routers.
iCCAP 2 OFDMA Channels per Cisco IOS XE Gibraltar This feature was integrated on the Cisco cBR
port 16.10.1c Series Converged Broadband Routers.
Remote PHY DOCSIS 3.1 Cisco IOS XE Gibraltar This feature was integrated on the Cisco cBR
OFDMA LCHA & LCPR 16.10.1c Series Converged Broadband Routers.
OFDMA - 4 override zones per Cisco IOS XE Gibraltar This feature was integrated on the Cisco cBR
IUC 16.12.1w Series Converged Broadband Routers.
616
CHAPTER 40
OFDMA OUDP Leak Detection Configuration
This document describes how to configure OFDMA OUDP leak detection on the Cisco cBR Series Converged
Broadband Router.
• OUDP Leakage Detection, on page 617
• Methods to Configure OUDP Leak Detection, on page 618
• Supported Line Cards, on page 618
• OUDP Leakage Detection Test Sessions, on page 618
• OUDP Parent Test Sessions, on page 620
• OUDP Child Test Sessions, on page 621
• Persistent OUDP Test Sessions, on page 622
• OUDP Late Modem Joining, on page 624
• OUDP System Boot Holdoff, on page 624
• OUDP Test Expiration, on page 624
• OUDP Test Session High Availability, on page 625
• EXEC Mode Command Summary, on page 625
• Global Configuration Mode Command Summary, on page 627
• Configuration Mode Command Summary, on page 628
• OUDP Burst-Profile Sub-Mode Config CLI Commands, on page 629
• Show OUDP Command Summary, on page 630
• Related Show Command Summary, on page 631
• Example: Configuration Command Mode, on page 631
• Example: EXEC Command Mode, on page 631
• Verifying the OUDP Session, on page 632
• Example: Creating a Test Session on Selected Modems Using the EXEC Mode, on page 633
• Specifications, on page 634
• Recommendations for the OFDMA Burst Testing Channel Configuration, on page 634
• Example: Channel Configuration for a Third-Party Leak Detector, on page 634
OUDP Leakage Detection

Cable operators can now measure cable signal leaks by initiating the Orthogonal Frequency-Division Multiple
Access (OFMDA) Upstream Data Profile (OUDP) leakage test sessions on one or more upstream OFDMA
channels simultaneously. OUDP test sessions are initiated using CLI commands in the config and exec modes.
These commands direct modems to generate a test burst, which enables operators to locate leaks in the Federal
617
Methods to Configure OUDP Leak Detection
Aviation Administration (FAA) frequency range above 100MHz. Operators use handheld or vehicle-based
devices to detect leaks.
Importance of Detecting Signal or RF Leakage
Cable operators desire to increase upstream bandwidth by utilizing high split diplexers. These diplexers
increase the upstream frequency range to 204 MHz, which allows the cable modem to transmit in the Federal
Aviation Administration (FAA) frequency range above 100MHz. This means that the 118 MHz to 136.975
MHz aeronautical band now overlaps the upstream cable frequency range. When Radio Frequency (RF) cables
are damaged or cable faults such as ground failures or shielding failures occur, it may cause electromagnetic
energy to escape from the transmission line into the environment. This energy is referred to as RF leakage.
Any cable signal leak may interfere with the FAA frequency range. Rectifying upstream RF leakage ensures
compliance with FCC guidelines.
Methods to Configure OUDP Leak Detection

There are two ways to configure the burst sessions on CBR-8 routers:
• In the Configuration mode, you can configure one or more OUDP burst profiles, and associate the burst
profiles with persistent OUDP test schedules.
• In the Privileged Exec mode, you can execute commands to create a burst session, however, these
commands are not persistent across reboots.
Supported Line Cards

The OUDP leak detection feature is supported on the following line cards:
Supported Release Supported Line Cards
17.6.1z • CBR-CCAP-LC-40G-R
• CBR-CCAP-LC-G2-R
OUDP Leakage Detection Test Sessions

OUDP test sessions are created in the Exec CLI or Configuration mode and are maintained on the SUP and
CLC line cards. A test session identifies a list of modems that will participate in the OUDP burst test, the
frequency range to be tested, the transmit burst parameters, and the start and stop time of the test. Two types
of OUDP test sessions are managed by the cBR-8, parent test sessions and child test sessions.
A parent test session is created on the SUP using Exec or Configuration CLI commands and is identified by
a unique parent session Id. parent test sessions are set up to include the frequency range to be tested, the
transmit burst parameters, and a cable modem mac-address list and/or an interface to be tested.
A child test session is created on the line card, has a child session Id that is unique to the slot and are associated
with a parent test session. There can be 0, 1 or many child test sessions associated with a parent test session
depending on the method used to identify the participating modem list. The child test sessions are set up with
618
OUDP Leakage Detection Test Sessions
the minislot frequency range and transmit burst parameters corresponding to their parent test session. A unique
child test session will be created for each OFDMA channel participating in the OUDP test.
All OUDP test sessions transition through a series of states as the test progresses.
Status/State Description
CONFIG Identifies a parent test session that is partially

configured through Exec CLI commands.
PENDING Identifies a parent or child test session that is fully

configured, either by Exec CLI or Configuration
mode, and whose pretest setup time has not been
reached yet.
PRETEST_SETUP Identifies a parent or child test session that has reached

the pretest setup state. The pretest setup time is a
configurable number of seconds prior to the test start
time.
ACTIVE Identifies a parent or child test session that has reached

its test session start time.
CLEANUP Identifies a parent or child test session that has reached

its test session stop time, or has been manually stopped
through the CLI.
COMPLETE Identifies a parent or child test session that has ended.

Per modem OUDP burst stats are retained in
completed child test sessions.
The progression of an OUDP Test Session includes the following steps:

1. The Parent Test Session is fully set up on the SUP through the Exec CLI or Configuration commands.
2. At Pre-Test Setup time—a configurable time prior to the test start:
Note The default time is 1 minute.
a. The parent test session is distributed to all cable line cards.

b. The cable line cards determine whether they have any OFDMA channels that match the parent test
parameters.
c. The cable line cards create a unique child test session for each OFDMA channel with online D3.1
CMs based on the parent test parameters.
d. The child test sessions are notified back to the SUP from the cable line card.
e. Each participating CM is assigned a unique OUDP Test Session ID (SID).
f. A DBC-REQ message is sent to each CM to set up its OUDP Test SID.
g. The US Scheduler receives the test parameters for Burst Duration, Burst Gap, and Cycle Time.
619
OUDP Parent Test Sessions
h. The US Scheduler receives the ordered list of SIDs to be scheduled for the OUDP test cycle.
3. At the start of the test, the US Scheduler begins granting on the OUDP Test SIDs.
4. Modems respond to the grants by transmitting the OUDP Test packets as defined in the MULPI
specification. Modem bursts are periodic based on the configured OUDP test cycle and always occur at
a fixed time-offset from the start of a test cycle.
5. Modem test bursts are received by the upstream PHY and processed by the upstream FPGA. The PHY
and FPGA collect the stats for burst no energy, bursts received, and bytes received.
6. Stats collection for each SID occurs periodically, every 10 seconds, on the cable line card and are forwarded
to the SUP.
7. The test continues until the test stop time is reached:
a. Final Stats collection occurs for each CM.
b. The US Scheduler SID list will be deleted.
c. The US Scheduler OUDP minislot assignments will be cleared.
d. Each modem will be sent the OUDP_DISABLE_SID to clear its OUDP Test SID.
e. The OUDP test SIDs will be deallocated and deactivated and returned to the SID pool.
8. Test Session stats can be reviewed through CLI show commands.

9. Test Sessions are manually deleted or deleted automatically at the specified Expiry age.
OUDP Parent Test Sessions

An OUDP parent test session is a test session that is created on the SUP to run at a specific time, over a specific
frequency range, using specific transmit burst parameters, and that includes a specific set of cable modems.
When created using EXEC mode, the parent test session is not persistent. In other words, the Exec mode
OUDP test session will be lost if the system is reloaded. To create a persistent OUDP test session the
Configuration CLI mode should be used, and the configuration should be saved to startup-config.
A parent test session must include either a CM-List or an interface or both. The CM-List consists of a list of
modem mac-addresses. The system supports a maximum of 400 mac-addresses in the CM-List. Mac-addresses
included in the CM-List may be from a single slot/single OFDMA channel, or from several different slots on
different OFDMA channels. Mac-addresses setup in the parent CM-List are not validated.
A parent test session may also include an interface. The interfaces supported include a mac-domain (for
example Cable1/0/0), a controller (for example controller upstream-cable 1/0/4), or a controller channel (for
example controller upstream-cable 1/0/4 us-channel 12). When both a CM-List and an interface are setup in
a parent test session, the list of modems that will participate in the test will be the logical AND of the CM-List
with the modems on the interface.
Multiple parent test sessions can be setup simultaneously. The cBR-8 will manage all parent test sessions
appropriately based on their configured start and stop times. Parent test sessions are assigned Ids in the 1 –
9999 range. If a multiple parent test sessions exist that would otherwise include the same OFDMA channels
and/or the same cable modems, the first parent test session to start will win. Subsequent overlapping parent
620
OUDP Child Test Sessions
test sessions will start on time, but will not include a child test session for an OFDMA channel that is already
active in another parent test session.
Exec CLI commands are provided to manage parent test sessions. When commands like stop and delete are
used on the parent test session, all related child test sessions will also be stopped and deleted.
When Exec CLIs are used to create a parent test session, the admin is allowed to choose the parent test session
Id, which must be in the range 1-9999. When the cBR-8 restores persistent OUDP test sessions, it will create
parent test sessions using the next available parent test session Id, starting from 1. Duplicate parent test session
Ids are not allowed.
You can create a session by using the cable oudp-leak-detect session-id <id> session create command at
the privileged EXEC mode. The specified ID is referred to as the parent ID.
OUDP Child Test Sessions

The cBR-8 routers create child test sessions, automatically, as needed. The administrator cannot create the
child test sessions directly. A child test session is created for each OFDMA channel that will be participating
in an OUDP test. When the child test session is created, it is assigned a unique child session ID. Child session
IDs are assigned a value that corresponds to the slot on which they originated.
Slot Child Session ID Range
0 100,000 – 109,999
1 10,000 – 19,999
2 20,000 – 29,999
3 30,000 – 39,999
6 60,000 – 69,999
7 70,000 – 79,999
8 80,000 – 89,999
9 90,000 – 99,99
For the child test session to be created, it must have at least one valid DOCSIS3.1 cable modem online and
that modem must also be using the OFDMA channel.
Note If the modem is reporting the OFDMA channel in partial service, it still joins and participates in the OUDP
test. Grants will be issued to the modem, but as long as the modem reports partial-service on the OFDMA
channel, it is possible that the BurstNoEnergyRx stat is incremented.
When a child test session is created from a parent test session, the frequency range of the parent test session
is translated into a frequency range aligned with the OFDMA channel minislots that are inclusive of the parent
frequency range. Thus, the child test session detailed information may show a minislot frequency range larger
than the parent test session frequency range.
621
Persistent OUDP Test Sessions
The child test session also inherits the transmit burst parameters of the parent test session. These values should
always be identical to the parent.
Child test sessions also contain CM-List and interface configuration details. The interface of a child test session
will always be a controller upstream-cable us-channel particular to a single OFDMA channel. The CM-List
of a child session will only include the cable modems particular to the OFDMA associated with the child test
session. By default, cable modems of a child test session are assigned burst positions within the OUDP test
cycle starting from position 0. However, an option strict-cm-list exists that enforces the parent CM-List
position on the child test sessions. For example, when the strict-cm-list option is used, a modem in CM-List
position 5 of the parent CM-List appears in position 5 of the corresponding child test session CM-List.
Note The strict-cm-list position should only be used if the exact time offset of the CM must be maintained within
the OUDP test cycle. The use of this option can result in unused burst positions within the OUDP test.
Mac-addresses in the parent test session are validated as they are assigned to child test sessions. Mac-addresses
in the CM-List that are invalid format, are not known on the system, are valid but the modem is offline, are
not D3.1 cable modems, or are D3.1 cable modems that are not using an OFDMA channel will not participate
in the OUDP test.
This show command output shows child sessions IDs and their associated parent ID:
Parent Child Interface Modems Status Start-Time Stop-Time

99 - - 1 ACTIVE 2022-07-23,20:05:12.0,-5:00 never
99 10006 Ca1/0/0/U6 1 ACTIVE 2022-07-23,20:05:12.0,-5:00 never
99 10008 Ca1/0/2/U14 2 ACTIVE 2022-07-23,20:05:12.0,-5:00 never
99 90007 Ca9/0/0/U6 2 ACTIVE 2022-07-23,20:05:12.0,-5:00 never
99 90008 Ca9/0/1/U6 2 ACTIVE 2022-07-23,20:05:12.0,-5:00 never
99 90009 Ca9/0/30/U6 1 ACTIVE 2022-07-23,20:05:12.0,-5:00 never
99 90010 Ca9/0/31/U6 2 ACTIVE 2022-07-23,20:05:12.0,-5:00 never

OUDP test sessions set up using the Configuration CLI mode are persistent and known as scheduled OUDP
test sessions. The parameters and options for configuration mode are similar to the commands offered by the
Exec CLI, except for the cm-add or cm-delete Exec commands. In configuration mode, the CM-List is loaded
from a file located on the hard drive, bootflash, or usb IOS file systems.
There are two types of scheduled OUDP test sessions.
• Date-Time
• Recurring Weekday
Date-Time schedules are configured to start and stop at a specified calendar date-and-time. The format follows
the OSSI specification for Date-And-Time Strings:
[YY]YY-[M]M-[D]D,[h]h:mm:ss.0,[+|-][T]T:ZZ
Example: 2022-07-23,22:31:44.0,-5:00
In addition, Date-Time schedules support the option for start ‘now’ and stop ‘never’. These options are useful
to reestablish OUDP test sessions automatically after a system reload.
622
Recurring Weekday schedules allow the administrator to create a scheduled OUDP test session that runs on
specific days of the week, and during specific times of the day. The time-of-day is specified using 24-hour
military time, and is relative to the local timezone of the cBR-8. Upon completion, a Recurring Weekday test
will be rescheduled to start on the next subsequent weekday at the configured start time.
Persistent OUDP test sessions are configured by first creating an OUDP Burst Profile. The burst profile
includes the test session parameters for frequency range, transmit burst parameters, interface and/or CM-List.
Each OUDP burst profile is assigned a unique ID, and multiple burst profiles are supported.
After the burst profile is configured, a scheduled OUDP test session can be configured. The OUDP schedule
binds the burst profile ID to the Date-Time or Recurring Weekday schedule. A single OUDP burst profile
may be configured under one or more OUDP schedules. When the OUDP burst profile and schedule
configurations are complete, an OUDP parent test session is created and associated with the OUDP schedule.
The assigned parent test session ID can be shown using the show cable oudp-leak-detect schedules command.
CM-List Format
Configured OUDP test sessions may include a CM-List that is read from a file on harddisk, bootflash, or usb0
IOS file systems. The format rules for the file are as follows:
• File type is ASCII text.
• Enter one mac-address per line.
• Mac-addresses may be either aaaa.bbbb.cccc or aa:bb:cc:dd:ee:ff format.
• Blank lines are permitted.
• Comment lines are permitted and must start with # as the first character of the line.
• Comments or other characters should not follow MAC addresses.
• Include a <CR> after the final MAC address in the file.
Example
#
###### This is an example OUDP CM-List file.######
# C1/0/0
4800.33ef.00fa
4800.33ef.014a
4800.33ef.0142
4800.33ef.0b0e
# C1/0/2
1459.c0f8.5210
4800.33ef.0d6a
4800.33ee.ff9a
4800.33ea.70c2
4800.33ea.71ba
CM-List Wildcard
The CM-List supports a wildcard mac-address. The wildcard mac-address is ffff.ffff.ffff. When this mac-address
is included in the CM-List (either Exec or Config created), it matches all eligible cable modems during child
test session creation.
623
OUDP Late Modem Joining
The wildcard CM-List is the easiest method for starting an OUDP test session on the entire cBR-8. All D3.1
modems using an OFDMA channel that matches the OUDP frequency range will be assigned to a child test
session and will participate in the OUDP test session.
OUDP Late Modem Joining

The cBR-8 provides a feature for D3.1 modems to join an OUDP test session after the test session has started.
Cable modems that are offline at the start of a test, but otherwise intended to participate in the OUDP test
session, are added to the OUDP test session after they register, provided:
1. The modem mac-address is included in the CM-List of the parent test session.
2. The parent test session includes the interface of the OFDMA channel that the modem is using.
A test session configured with only a CM-List:

• Allows late modem joining for modems whose mac-addresses are listed within the CM-List.
• Allows all eligible modems that contain the wildcard mac address ffff.ffff.ffff to join the test session.
A test session configured with only an interface will allow late modem joining only for new modems on the
specified interface.
While an OUDP test session is active, the OUDP process will periodically check every 15 minutes to determine
if new modems can be added to an existing test.
OUDP System Boot Holdoff

The cBR-8 router provides a feature for OUDP, where persistent OUDP test sessions will not be started until
the system is up and the OFDMA channel reach UP state with cable modems online. The amount of time to
wait after system boot-up is configurable. The persistent test sessions restored from startup-config will not
be distributed to the cable line cards and child test sessions will not be created until the system-boot-holdoff
time has elapsed.
Note The default system-boot-holdoff time is 15 minutes.
OUDP Test Expiration

The cBR-8 retains OUDP test sessions for a period of time after they have reached the COMPLETE state.
This allows time for the administrator to retrieve CM burst statistics for post processing and analysis. However,
OUDP test sessions occupy memory on both the SUP and cable line card processors, so they should be deleted
in a timely fashion. To facilitate their deletion, the cBR-8 automatically deletes expired OUDP test sessions
when they have aged beyond the globally configured expire-age. By default this is 3 days, and the value is
configurable from 1 to 7 days.
624
OUDP Test Session High Availability
OUDP Test Session High Availability

The cBR-8 supports the high availability feature for OUDP leakage testing.
Supervisor High Availability (SUP-HA) is supported, with child test session CM burst stats restored to the
newly active SUP shortly after switchover.
Line Card High Availability (LCHA) is also supported for OUDP leakage testing. After LCHA switchover,
CM burst stats will continue to be collected and reported up to the SUP.
CM burst stats are reported periodically every 10 seconds, so it may take up to 20 seconds after switchover
for stats to begin incrementing.
EXEC Mode Command Summary

EXEC CLI Command Description
cable oudp-leak-detect session-id <parent id> Creates a new OUDP Parent test session assigning a
session create new parent session ID.
cable oudp-leak-detect session-id <parent id> Deletes the specified OUDP Parent test session and
session delete frees the parent session ID and all children sessions
and IDs.
cable oudp-leak-detect session-id <parent id> Stops the specified OUDP test session in ACTIVE
session stop state. Stopping a parent session stops all child
sessions.
cable oudp-leak-detect session-id <parent id> Resets an OUDP Parent Test Session. Removes all
session reset child sessions, deletes all stats, clears the parent start
and stop time, and sets the session status back to
CONFIGURING. This CLI is intended to allow a
COMPLETED parent test session to be reused.
cable oudp-leak-detect session-id <parent id> start Date-and-Time Format

datetime <datetime> stop datetime <datetime> [YY]YY-[M]M-[D]D,[h]h:mm:ss.0,[+|-][T]T:ZZ
cable oudp-leak-detect session-id <parent id> start In lieu of specifying the Date-and-Time format, the
now stop never option start now and stop never are supported.
A test session that is stop never must be manually
stopped or deleted by the administrator.
cable oudp-leak-detect session-id <parent id> Sets the start and end frequencies of the OUDP parent
frequency start <hertz> end <hertz> test session. The OUDP child test session includes all
minislots, which include the parent test session
frequency range.
The valid range is 4500000-204500000 Hz.
625
EXEC Mode Command Summary
cable oudp-leak-detect session-id <parent id> Sets the OUDP parent test session OUDP transmit
transmit burst duration <3..50> gap <0..50> burst parameters for burst duration, burst gap and
[[[cycle-gap <0..400>] [fixed-bursts-per-cycle either cycle-gap or cycle-time.
<1..400>]] | cycle-time <milliseconds>]
Cycle-Gap complies with the OSSI specifications for
OUDP testing. The OUDP test cycle repeat interval
is measured in frames.
Cycle-Time provides a time-based repeat interval for
the OUDP test cycle that is compatible with
RF-detectors requiring a minimum repeat burst
interval.
• The valid range for burst-duration is 3-50 frames.
• The valid range for burst-gap is 0-50 frames.
• The valid range for cycle-gap is 0-400 frames.
• The valid range for cycle-time is 100-20000
msec.
cable oudp-leak-detect session-id <id>controller Sets the OUDP parent test session interface to specify
upstream-cable <slot/subslot/ctrlr> [us-channel an upstream-cable controller, or upstream-cable
<us-chan>] controller channel.
A controller upstream-cable interface may expand to
include up to two OFDMA channels/child test session.
A controller upstream-cable channel specifies a single
OFDMA channel/child session.
cable oudp-leak-detect session-id <id> interface Sets the OUDP parent test session interface to specify
Cable <slot/subslot/md-idx> a mac-domain.
A Cable MAC domain interface may expand to
include up to four OFDMA channels/child sessions.
cable oudp-leak-detect session-id <parent-id> Adds the MAC address to the parent test session
cm-add <mac-address> CM-List.
cable oudp-leak-detect session-id <parent-id> Removes the MAC address from the parent test
cm-delete <mac-address> session CM-List.
cable oudp-leak-detect session-id Requires the child test sessions to preserve the
<parent-id>strict-cm-list CM-List position of modems in the parent test session
CM-List.
cable oudp-leak-detect session-id <parent-id> Reserves a percentage of frames in the OUDP test
reserved-probe-pct <0-10> cycle for OFDMA channel upstream profile
management probes.
The default value is 3%.
626
Global Configuration Mode Command Summary
cable oudp-leak-detect session-id <parent-id> clear Clears the specified item.

[cm-list | cm-stats | interface | strict-cm-list]
cm-list—Removes all modems from the CM-List of
an OUDP parent test session in CONFIG or
PENDING state.
interface—Removes the interface config from a
OUDP parent test session in CONFIG or PENDING
state.
strict-cm-list—Removes the strict-cm-list setting
from a OUDP parent test session in CONFIG or
PENDING state.
cm-stats—Clears the accumulated burst statistics of
all OUDP child test session in ACTIVE state. Stats
will immediately restart accumulating from starting
from 0.
cable oudp-leak-detect session-id <parent-id> Allows the system admin to preview the child test
session preview session create from an OUDP parent test session prior
to the pretest setup time.
Child test sessions and modems are created based on
the current state of the system, and are not guaranteed
to be the same at the actual pretest setup time when
child test sessions are rebuilt for the actual test start.
cable oudp-leak-detect session-id <parent-id> Provides a mechanism for the child test sessions to
session supha-recover be restored to the Active SUP. Existing child test
sessions are deleted and all cable line cards update
the SUP with their current child test sessions.
Not recommended for normal system operational use.
cable oudp-leak-detect delete all Deletes all OUDP test sessions regardless of state.
Note Warning: Once deleted all CM burst stats
are lost.
cable oudp-leak-detect clear system-boot-holdoff Allows the administrator to manually terminate the
OUDP system-boot-holdoff timer. OUDP test
sessions are started based on the state of the OFDMA
channels and modems.
Global Configuration Mode Command Summary

Global Config CLI Command Description
cable oudp-leak-detect pre-test-setup-time The valid range is 10-300 seconds. The default value
<seconds> is 60 seconds.
627
Configuration Mode Command Summary
Global Config CLI Command Description
cable oudp-leak-detect expire-age <days> The valid range is 1-7 days. The default value is 3
days.
cable oudp-leak-detect system-boot-holdoff The valid range is 10-120 minutes. The default value
<minutes> is 15 minutes.
cable oudp-leak-detect reserved-probe-pct The valid range is 0-10 percent. The default value is
<percentage> 3 percent.
cable oudp-leak-detect ccap-modem-select Enables modems to join child test sessions after they
allow-late-cm-join reach the active state. Normal rules for CM-List and
interface modem participation apply.
cable oudp-leak-detect adjust-test-time OUDP tests are scheduled based on the PTP/GPS
[all|icmts|none] clock time. The cable line card scheduler uses the
DOCSIS frame clock. This command enables a timing
adjustment between the GPS clock and the DOCSIS
clock. Normally RPHY will not require the time
adjustment, whereas iCMTS does.
The default value is icmts.
Configuration Mode Command Summary

Config CLI Command Description
cable oudp-leak-detect burst-profile <#> Creates a OUDP burst profile and enters the burst profile
configuration sub-mode. See the OUDP Burst-Profile
Sub-Mode Config CLI Commands for more information.
The valid range is 1-9999.
cable oudp-leak-detect schedule burst-profile Creates a persistent one-time scheduled test session.
<#> start datetime <datetime>
cable oudp-leak-detect schedule burst-profile Creates a persistent 24x7 OUDP test session.
<#> start now stop never
cable oudp-leak-detect schedule recurring Creates a persistent weekly test session that runs at the same
weekday <days> start timeofday <time> stop time, each day, on configured weekdays
timeofday <time> (“SuMoTuWeThFrSa”).
One or more weekdays, for example, "MoWeFr” must be
specified.
628
OUDP Burst-Profile Sub-Mode Config CLI Commands
OUDP Burst-Profile Sub-Mode Config CLI Commands

OUDP Burst-Profile Sub-Mode Description
Config CLI Commands
transmit burst duration Sets the OUDP parent test session and OUDP transmit burst parameters
<burst-dur> gap <burst-gap> for burst duration, burst gap, and either cycle-gap or cycle-time.
[cycle-gap
Cycle-Gap complies with the OSSI specifications for OUDP testing. The
<cycle-gap>|cycle-time
OUDP test cycle repeat interval is measured in frames.
<cycle-time>]
Cycle-Time provides a time-based repeat interval for the OUDP test cycle
that is compatible with RF-detectors requiring a minimum repeat burst
interval.
• The valid range for burst-duration is 3-50 frames.
• The valid range for burst-gap is 0-50 frames.
• The valid range for cycle-gap is 0-400 frames.
• The valid range for cycle-time is 100-20000 msecs.
frequency start <start-hz> end Sets the start and end frequencies of the OUDP parent test session. The
<end-hz> OUDP child test session includes all minislots, which include the parent
test session frequency range.
The valid range is 4500000-204500000 Hz.
controller upstream-cable Sets the OUDP parent test session interface to specify an upstream-cable
<slot/subslot/ctrlr> [us-channel controller, or upstream-cable controller channel.
<ofdma-us-channel>
A controller upstream-cable interface may expand to include up to two
OFDMA channels/child test session.
A controller upstream-cable channel specifies a single OFDMA
channel/child session.
interface cable Sets the OUDP parent test session interface to specify a mac-domain.
<slot/subslot/md-idx>
A Cable MAC domain interface may expand to include up to four OFDMA
channels/child sessions.
cm-list Configure the OUDP parent test session to load the CM-List from an IOS
<IOS-filesystem:filename> filesystem file. The harddisk, bootflash, and usb0 file systems are
supported. See the CM-List Format for the text file format.
strict-cm-list Requires the child test sessions to preserve the CM-List position of
modems in the parent test session CM-List.
reserved-probe-pct <0-10> Reserves a percentage of frames in the OUDP test cycle for OFDMA
channel upstream profile management probes. When configured under
the OUDP burst-profile, this value overrides the global configuration
parameter of the same name.
If not configured, burst-profiles use global default values.
629
Show OUDP Command Summary
Show OUDP Command Summary

Show Command Description
show cable oudp-leak-detect settings Displays the values of OUDP global configuration parameters and
the CBR-8 capabilities (specifically the OSSI
SupportsNumBurstsNotReceived—We support RxNoEnergy
stat.)
show cable oudp-leak-detect Displays summary of the test session that includes parent/child IDs,
test-sessions start/stop times, interfaces, and status.
show cable oudp-leak-detect Displays the parent or child test session details.
session-id <id> detail
Includes OSSI information pertaining to:
• LeakageDetectionTestSessionStatus
• LeakageDetectionTestChannelStatus
show cable oudp-leak-detect session Displays the child test session CM stats for BurstGrants, BurstRx,
[id <id>] cm-stats BurstNoEnergyRx, and BytesRx.
Includes OSSI information pertaining to:
• LeakageDetectionTestSessionStats
All child session CM stats are displayed when the parent session-id
is entered.
show cable oudp-leak-detect Time delay during system boot to allow OFDMA channels to reach
system-boot-holdoff UP state and CMs to reach online. After this holdoff time expires,
OUDP test sessions will begin.
show cable oudp-leak-detect Displays persistent OUDP burst profiles configured in NVRAM
burst-profiles (startup-config).
show cable oudp-leak-detect Displays persistent OUDP schedules configured in NVRAM

schedules (startup-config).
show cable oudp-leak-detect Displays currently available OFDMA channels and frequencies in
rf-detector the system. Useful for identifying OFDMA channel participation
for a given OUDP frequency range.
show cable oudp-leak-detect Displays the timing reference information of the SUP and selected
docsis-clock slot <0-9> cable line card slot.
630
Related Show Command Summary
Related Show Command Summary

Related Show CLI Commands Description
show cable modem <mac-address> verbose | incl Displays CM verbose information containing new
OUDP lines for OUDP test participation.
scm <mac-address> qos Displays information about the OUDP Burst Test
(OBT) SID.
show controller upstream-Cable <slot>/0/<ctrlr> Displays the Last Enroll Error for an OFDMA channel
us-channel <12-15> | incl OUDP (if available).
show controller upstream-Cable <slot>/0/<ctrlr> Displays the UMP start and end minislot values.
us-channel <12-15> cdm-ump | i OBT
show interface cable <slot>/0/<md_idx> sid Displays the OUDP stats for the specified SID.
oudp-counters
show interface cable <slot>/0/<md-idx> Displays the OBT scheduler SID table. Indicates
mac-scheduler <us-channel> map-stats burst/gap positions and SID assignments.
show interface cable <slot>/0/<md-idx> Displays the OFDMA IUC reservation percentage
mac-scheduler <us-channel> due to OUDP testing.
show cable admission-control interface cable Displays the admission control rate reservation
<slot>/0/<md-idx> upstream <us-channel> required by the OUDP test.
Example: Configuration Command Mode

This example shows how to create a burst profile in the configuration mode:
Router#config terminal
Router(config)#cable oudp-leak-detect burst-profile 55
Router(config-oudp-burst-profile)#frequency start 45000000 end 50000000
Router(config-oudp-burst-profile)#$burst duration 4 gap 2 cycle-gap 10
OUDP cycle-gap can support 53 bursts in the test cycle
Router(config-oudp-burst-profile)#cm-list harddisk:oudp-cm-list-1
Router(config-oudp-burst-profile)#$leak-detect schedule burst-profile 55 recurring
weekdays MoTuWeThFr start timeofday 15:45:00 stop timeofday 18:00:00
Example: EXEC Command Mode

The example shows the creation of a session and assigning the required test parameters.
1. Configure an OUDP session.
Router#cable oudp-leak-detect session-id 99 session create
631
Verifying the OUDP Session
2. Configure the frequency test parameters for the OUDP session.

Router#cable oudp sess 99 frequency start 60000000 end 66000000
3. Configure the Burst Duration and Cycle Gap test parameters.

Router#cable oudp sess 99 transmit burst duration 6 gap 4 cycle-gap 20
OUDP cycle-gap can support 64 bursts in the test cycle
4. Configure the list of cable modems intended to participate in sending test bursts.
Router#cable oudp sess 99 cm-add 4800.33ea.70c2
Router#cable oudp sess 99 cm-add 4800.33ea.71ba
Router#cable oudp sess 99 cm-add 4800.33ee.ff9a
Router#cable oudp sess 99 cm-add 4800.33ef.0c56
Router#cable oudp sess 99 cm-add 4800.33ef.0c5e
5. Configure the start time and end time for the test bursts.
Router#cable oudp-leak-detect session-id 99 start datetime 2022-01-01,12:00:00.0,
-5:00 stop datetime 2022-01-02,12:00:00.0,-5:00
Verifying the OUDP Session

The show cable oudp-leak-detect test-sessions command shows all OUDP test sessions present on the cBR-8.
The status of each session will indicate whether it is PENDING with a future start time, in PRETEST_SETUP
just prior to the test start, ACTIVE with OUDP burst grants, CLEANUP for final stats collection, or
COMPLETE.
Router#show cable oudp-leak-detect test-sessions
Time source is NTP, 14:14:05.873 EST Wed Jul 27 2022
OUDP Test Sessions: 2
Parent Child Interface Modems Status Start-Time Stop-Time

99 - - 0 ACTIVE 2022-07-27,12:45:03.0,-5:00 never
99 10002 Ca1/0/2/U14 2 ACTIVE 2022-07-27,12:45:03.0,-5:00 never
The show cable oudp-leak-detect session-id <id> detail command can be used for either parent or child test
sessions. Parent session details show the test parameters as they are configured.
Router#show cable oudp-leak-detect session-id 99 detail
OUDP Test Session : 99 (parent)
Status : PRETEST
Start Time : 2022-07-27,12:45:03.0,-5:00
Stop Time : never
Burst Duration : 6 (frames)
Burst Gap : 4 (frames)
Cycle Gap : 20 (frames)
Reserved Probe Pct : 3
Freq Start : 60000000 (Hz)
Freq End : 66000000 (Hz)
Interface : controller upstream-cable 1/0/3 us-channel 12
CM-List : 0 modems
Child session detail shows test information as it pertains to the particular OFDMA channel.
632
Example: Creating a Test Session on Selected Modems Using the EXEC Mode
Router#show cable oudp-leak-detect session-id 10002 detail

OUDP Test Session : 10002 (child)
Interface : Cable1/0/2 upstream 14

Status : ACTIVE
Start Time : 2022-07-27,12:45:03.0,-5:00
Stop Time : never
Burst Duration : 6 (frames)
Burst Gap : 4 (frames)
Cycle Gap : 20 (frames)
Reserved Probe Pct : 3
Actual SC Freq Start : 59700000 (Hz)

Actual SC Freq End : 66075000 (Hz)
Minislot Start : 38
Minislot End : 53
Microsec per frame : 573.000 (usec)
Burst Spacing : 5730.000 (usec)
Test Session Type : CycleGap

Current Bursts per cycle : 2
Maximum Bursts per cycle : 64
Probe Oppty per cycle : 20 (frames)
Cycle Interval Info : 2 (bursts) / 40.00 (frames) / 22.920 (msec)
Child Session 10002, Cable1/0/2 upstream 14 - CM-List 2 modems

CM Mac-Address BurstPos Offset(us) Test Sid BurstGrants BurstNoEnergyRx BurstRx TestBytesRx
4800.33ea.71ba 0 0 27 1373428 0 1371040 2107288480
4800.33ea.70c2 1 5730 28 1373418 0 1371030 2107273110
Example: Creating a Test Session on Selected Modems Using

the EXEC Mode
This example is to create a test session where the operator has requested that the cBR-8 choose the modems.
MAC-Address Wildcard—All CLCs and All OFDMA channels
cable oudp-leak-detect session-id 5 session create
cable oudp-leak-detect session-id 5 frequency start 138100000 end 139650000
cable oudp-leak-detect session-id 5 transmit burst duration 4 gap 2 cycle-gap 10
cable oudp-leak-detect session-id 5 cm-add FFFF.FFFF.FFFF
cable oudp-leak-detect session-id 5 start datetime 2022-01-01,12:00:00.0,-5:00
stop datetime 2022-01-02,12:00:00.0,-5:00
MAC-Domain Example—All configured OFDMA channels on the MAC-Domain

cable oudp-leak-detect session-id 5 interface Cable9/0/0
Controller Example—Single controller and one or two OFDMA channels

cable oudp-leak-detect session-id 5 controller upstream-cable 9/0/0
cable oudp-leak-detect session-id 5 controller upstream-cable 9/0/0 us-channel 13
633
Specifications
Specifications
The support for RF leakage detection is defined in the following specifications:
• CableLabs OSSI Specification: CM-SP-CCAP-OSSIv3.1-I24-220518
Note The implementation tracks closely to, but does not 100% match the OSSI
specification. OSSI specification development was in progress during the time
of this implementation.
• Upstream OFDMA Data Profile Testing Burst method as defined in the CableLabs MULPI Specification
CM-SP-MULPIv3.1-I23-220328
Recommendations for the OFDMA Burst Testing Channel

Configuration
• OFDMA channel IUC 13 is used by the the cBR-8 to schedule test bursts. Change the IUC 13 parameters
as necessary to match compatibility with the leakage detection equipment in use.
• Operations Support System Interface (OSSI) recommends the use of pilot pattern 4 or 11 for OFDMA
Burst Testing. OSSI recommends not to use boosted pilot patterns.
• cBR-8 supports all OFDMA pilot pattern configurations for OFDMA Burst Testing, if desired by the
operator.
Example: Channel Configuration for a Third-Party Leak Detector

This example shows the channel configuration for detecting leaks using a digital leak detector.
The following steps are to configure OFMDA controller profile:
Router# enable
Router(config)#cable mod-profile-ofdma 420
Router(config)#subcarrier-spacing 25KHz
Router(config)#initial-rng-subcarrier 64
Router(config)#initial-rng-preamble 8
Router(config)#fine-rng-subcarrier 512
###### CableLabs OSSI recommends 11 for 25 kHz SC spacing######
######CableLabs OSSI recommends 4 for 50 kHz SC spacing######
###### CableLabs OSSI recommends not to use boosted pilot patterns######
Router(config)#data-iuc 13 modulation 64-QAM pilot-pattern 11######
To configure upstream controller profile, use the steps below:
634
Router# enable
Router(config)#cable upstream controller-profile id [RPHY|I-CMTS]
Router(config)#us-channel 13 docsis-mode ofdma
Router(config)#us-channel 13 subcarrier-spacing 25KHz
Router(config)#us-channel 13 modulation-profile 420
Router(config)#us-channel 13 frequency-range 108000000 204000000
Router(config)#us-channel 13 initial-rng-frequency-start 184000000
Router(config)# us-channel 13 cyclic-prefix 256 roll-off-period 128
Router(config)#us-channel 13 symbols-per-frame 9
Router(config)#no us-channel 13 shutdown
635
636
CHAPTER 41
Time and Frequency Division Multiplexing
Configuration
This document provides information on the Cisco cBR-8 series routers support for Time and Frequency
Division Multiplexing (TaFDM) feature in DOCSIS 3.1 upstream channels.
• Information About TaFDM Support, on page 637
• How to Configure cBR for TaFDM Support, on page 638
• Configuration Example , on page 640
• Feature Information for TaFDM Configuration, on page 641
Information About TaFDM Support

Using the Time and Frequency Division Multiplexing (TaFDM) method, the OFDMA and SCQAM channels,
which are allowed to overlap in DOCSIS 3.1, are also allowed to use the upstream at different times. With
the implementation of TaFDM, both OFDMA and SC-QAM can simultaneously operate on separate frequencies.
They can also operate on the same frequencies, but in different times.
TaFDM enables the OFDMA capability across the entire spectrum, while retaining the backward compatibility
with legacy DOCSIS SC-QAM channels.
TaFDM is typically configured at the controller level. However, it is implemented at the Mac Domain level.
Overlapping channels cannot be bound to different Mac Domains.
Overlapping SC-QAM and OFDMA channels using TaFDM may be bonded. However, we recommend this
bonding only if the modems are provisioned with UGS flows and another non-overlapping SC-QAM is not
available.
For a better performance of UGS flows on overlapped SC-QAM channel, configure OFDMA channel with
50kHz subcarrier spacing, lower symbols per frame, and lower cyclic prefix.
To achieve a higher OFDMA channel traffic throughput, configure OFDMA channel with 25kHz subcarrier
spacing, and higher pilot pattern.
Prerequisites for Configuring TaFDM Support

The following prerequisite is applicable to configuring TaFDM configuration:
637
How to Configure cBR for TaFDM Support
• All overlapped SC-QAM channels and OFDMA channels on the same port must be bound to the same
Mac Domain
• Reserve a minimum 0.8–3.2 MHz OFDMA exclusive spectrum with good signal quality to be used for
OFDMA channel IM zone
How to Configure cBR for TaFDM Support

Configuring TaFDM Modulation Profile
The TaFDM modulation profile is used to configure initial ranging, fine ranging and data IUC parameters.
To define the TaFDM modulation profile, run the configuration commands, as given in the following example:
cable mod-profile-ofdma 450
initial-rng-subcarrier 64
fine-rng-subcarrier 192
data-iuc 9 modulation 1024-QAM pilot-pattern 11
cable mod-profile-ofdma 470

initial-rng-subcarrier 64
fine-rng-subcarrier 192
Configuring I/O Controller for TaFDM

The following sample configuration defines a shared region in the areas of the SC-QAM upstream channels.
638
Enhancing OFDMA Channel Throughput

Enhancing OFDMA Channel Throughput

The following example shows how to enhance the OFDMA channel throughput:
…
us-channel 12 docsis-mode ofdma
us-channel 12 subcarrier-spacing 25KHz
us-channel 12 frequency-range 10000000 85000000 #Overlap with SC-QAM channels
us-channel 12 initial-rng-frequency-start 50000000 # Specify the preferred start
frequency for IM zone
us-channel 12 cyclic-prefix 96 roll-off-period 64
us-channel 12 symbols-per-frame 9
Enhancing SC-QAM Channel UGS Flow Performance

The following example shows how to enhance the UGS flow performance of the SC-QAM channel:
…
us-channel 12 docsis-mode ofdma
us-channel 12 subcarrier-spacing 50KHz
us-channel 12 frequency-range 10000000 85000000 #Overlap with SC-QAM channels
us-channel 12 initial-rng-frequency-start 50000000 #Specify the preferred frequency for
IM zone
us-channel 12 cyclic-prefix 96 roll-off-period 64
us-channel 12 symbols-per-frame 8
Configuring Cable Interface-MAC Domain

The following example shows how to configure a cable interface for MAC Domain:
load-interval 30

upstream 0
upstream 1
639
Configuring Service Class
upstream 2
upstream 3
attributes 80000000
upstream 0
upstream 1
upstream 2
upstream 3
upstream 6
attributes 80000000
cable bundle 1
cable sid-cluster-group num-of-cluster 2 #Maximize single modem throughput
cable sid-cluster-switching max-request 4
cable cm-status enable 3 6-11 16-18 20-27
Configuring Service Class

The following example shows how to configure service classes:
cable service class 198 name mega_up
cable service class 198 upstream
cable service class 198 max-concat-burst 16384
cable service class 198 max-rate 1000000000 # Maximize single modem throughput
cable service class 198 max-burst 250000
cable service class 198 priority 0
cable service class 198 peak-rate 0
Excluding a Frequency Band from TaFDM

If you want the SC-QAM to exclusively use a specific frequency range, configure Cisco cBR to exclude the
band using the following sample commands.
cable frequency-exclusion-band 18700000 22100000
Verifying TaFDM Configuration

The following example shows how to verify the TaFDM configuration:
# show controllers upstream-Cable slot/subslot/port us-channel uschan-number-in-controller
#show controllers upstream-Cable slot/subslot/port us-channel uschan-number-in-controller

cdm-ump
# show interfaces cable slot/subslot/port mac-scheduler uschan-number-in-mac-domain
Configuration Example
TaFDM Configuration
640
Feature Information for TaFDM Configuration

us-channel 12 frequency-range 14000000 85000000

Table 109: Feature Information for for TaFDM Configuration
TaFDM Cisco IOS XE Fuji This feature was introduced on the Cisco cBR Series
Configuration 16.7.1 Converged Broadband Routers.
641
642
CHAPTER 42
DOCSIS 3.1 Upstream Profile Selection
DOCSIS 3.1 introduces the concept of upstream profiles for OFDMA channels. This document describes how
to configure the DOCSIS 3.1 Upstream Profile Selection on the Cisco cBR Series Converged Broadband
Router.
• Information about Upstream Profiles, on page 645
• How to Configure Upstream Profiles, on page 645
• Feature Information for Upstream Profile Selection, on page 651
643
Digital PICs:

Module:

Modules:
line card reload.
644
Information about Upstream Profiles
Information about Upstream Profiles

A modulation profile is a list of interval usage codes (IUCs) that are defined for an OFDMA channel. Each
IUC will have a modulation order and pilot pattern. Multiple IUCs within a modulation profile allow for
different modulation orders on the same OFDMA channel. The CMTS can define multiple profiles for use in
an OFDMA channel, where the profiles differ in the modulation orders assigned to each minislot.
You can use the following commands to view the profiles:
• To display the profiles associated with the cable modems (CMs), use the show cable modem [ip-address|
mac-address| cable| {slot | subslot | cable-interface-index}] phy ofdm-profile upstream command.
• To display detailed profile management data associated with specific cable modem, use the show cable
modem [ip-address| mac-address] prof-mgmt upstream verbose command.
The CMTS can assign different data IUCs for different groups of CMs.
A DOCSIS 3.1 CM can only have two active OFDMA Upstream Data Profile IUCs on a given channel.
Default Data IUC

Data IUC 13 is intended to be the most robust IUC and able to be used by all cable modems.
Recommended Interval Usage Code (IUC)

Based on the receive modulation error ratio (RxMER) values collected periodically during upstream probing,
the CMTS finds among the existing IUCs up to two that provide the highest speed while having sufficient
signal to noise ratio (SNR) margin for the CMTS to receive code words with acceptable error rates. The show
cable modem phy ofdm-profile upstream command displays the one or two recommended IUCs for each
CM.
In Cisco IOS XE Everest 16.6.1 release, data IUC 13 will be one of the IUCs assigned to the CM.
To disable the automatic profile downgrade, use no cable upstream ofdma-prof-mgmt prof-upgrade-auto
How to Configure Upstream Profiles

Configuring RxMER to Bit Loading Mapping
There are many ways to map the Receive Modulation Error Ratio (RxMER) values to bit loading values. We
use the following mapping recommended in DOCSIS 3.1 OSSI, as our baseline mapping:
60 16 4
84 64 6
645
Configuring Codeword Error Threshold
96 128 7
108 256 8
122 512 9
136 1024 10
148 2048 11
164 4096 12
184 8192 13
208 16384 14
• To configure a margin to adjust the RxMER to bit loading mapping, use the following command:
Router(config)# cable upstream ofdma-prof-mgmt mer-margin-qdb interval-in-minutes
This configured value (quarter-DB) is added to the RxMER values collected by CMTS before using the
above mapping table, thus giving a user more control in selecting the recommended profiles.
• To specify the percentage of minislot average RxMER that can be ignored in the recommended profile
calculation, use the following command:
Router(config)# cable upstream ofdma-prof-mgmt exempt-mslot-pct percent
This provides a way to specify the extent that the outliers can be ignored.
• To configure the RxMER poll interval, use the following command:
Router(config)# cable upstream ofdma-prof-mgmt rxmer-poll-interval interval-in-minutes
The CMTS uses upstream probing to collect RxMER data per CM. This occurs during registration and
periodically thereafter. The collected RxMER data is averaged per minislot and used to compute the
recommended IUCs for each CM.
The no cable upstream ofdma-prof-mgmt rxmer-poll-interval command sets the rxmer-poll-interval
to 1440, which is the value to disable the feature. The rxmer data is also not displayed after disabling the
feature.

Starting from Cisco IOS XE Gibraltar 16.12.1x release, user can configure a codeword error threshold above
which the profile will be downgraded, that is, switch to a lower order QAM.
Compared with the existing profile management scheme, in which the RxMER is read at configured interval,
and data IUC is upgraded or downgraded based on RxMER data and configurable criteria, using customized
codeword error threshold has several benefits, including:
• React to noise within minimal time window to maintain service quality
• If IUC selected by RxMER causes errors, it can be downgraded quickly
• Downgrade interval is much shorter than RxMER interval
646
To configure the codeword error threshold, enable this feature first:

Router(config)# cable upstream ofdma-prof-mgmt downgrade enable
Then configure the minimum number of codewords required within downgrade interval to consider for
downgrade:
Router(config)# cable upstream ofdma-prof-mgmt downgrade min-cws value
Use show cable modem prof-mgmt upstream to check whether this feature is enabled:
Router#show cable modem 4800.33ef.3dd2 prof-mgmt upstream
Upstream Profile Management Data:
MAC Address : 4800.33ef.3dd2
Number of US Chan : 1
Ucid : 6
RxMer Exempt Percent : 0
RxMer Margin qDB : 0
RxMer Threshold Percent : 2
Start Sc : 148
End Sc : 1907
Num RxMER Measurement : 1908
Tx Time : 0h:04m:50s ago
Rx Time : 0h:04m:50s ago
MER Poll Period (min) : 5
Auto Profile Upgrade : Yes
Upgrd Dly Cnt (cur/cfg) : 0/1
Upgrd Dly rcmd IUC : none
Recommended IUC : 5
Current IUC : 5
Downgrade IUC : 6
RxMER send/recv count : 1/1
DBC : 1/1/0/0/0
(send/succeed/err/reject/timeout)
State : Ready
Profile Downgrade : Enabled
Profile Downgrade count : 0
Interval good/cor/uncor : 294/93/0
Downgrade Check Time : 0h:00m:14s ago
After a downgrade, Profile Downgrade count is updated in the command output:

Ucid : 6
Start Sc : 148
End Sc : 1907
Recommended IUC : 6
Current IUC : 6
Downgrade IUC : 9
647
Downgrading to Partial Mode

DBC : 2/1/0/0/0
State : MER Received
Holddown Time : 0h:00m:03s ago
The Holddown Time will not be displayed in the command output anymore after the configured holddown
time is expired. In the following example, after two downgrades, the holddown time was expired, an RxMER
was read and checked, and the profile was upgraded back to 5.
Ucid : 6
Start Sc : 148
End Sc : 1907
Recommended IUC : 5
Current IUC : 5
Downgrade IUC : 6
DBC : 4/4/0/0/0
State : Ready
Downgrading to Partial Mode

Starting from Cisco IOS XE Gibraltar 16.12.1y release, user can configure a codeword error threshold above
which the profile will be downgraded to partial mode, that is disable some of the OFDMA channels when the
CM is currently using IUC13 due to MER or downgrade.
To configure the codeword error threshold, enable this feature first:
Router(config)# cable upstream ofdma-prof-mgmt downgrade enable
Then configure the threshold to consider for downgrading to partial mode:
Router(config)# cable upstream ofdma-prof-mgmt downgrade partial-threshold
value
Use show cable modem partial-mode to check the reason for downgrading to partial mode:
648
Configuring RxMER Downgrade
Router#show cable modem 4800.33ef.3dd2 partial-mode

MAC Address IP Address I/F MAC Prim RCC UP-reason/
State Sid ID Failed-tcsf
81d.0f01.1e10 9.2.0.46 C1/0/0/p w-online 1 1 0x10 / 0x20
Note: 0x01 = Ranging

0x10 = CWErr Partial Mode
0x11 = Both
Configuring RxMER Downgrade

Comparing to the existing upstream profile managements mechanism, RxMER downgrade has the following
benefits:
• Ability to downgrade to partial mode based only on RxMER data
• Configurable desired lowest acceptable IUC
• This allows IUC 13 modulation to be robust for registration and DBC
• Allow certain percentage of subcarriers under threshold
• Re-evaluate RxMER data at next poll interval
• Channel leaves partial-mode and uses recommended IUC when RxMER data is above threshold
• Works independently with codeword error downgrade
By default, RxMER downgrade is disabled, use the following command to enablethis feature:
Router(config)# cable upstream ofdma-prof-mgmt downgrade rxmer-enable
Then configure the data IUC below which the OFDMA channel will be downgraded to partial mode, the
default number is 13:
Router(config-ofdma-mod-profile)# ofdma-prof-mgmt downgrade rxmer min-iuc value
You can also configure the number of minislots that can be below minimum IUC and not trigger downgrade,
the default number is 0:
cable upstream ofdma-prof-mgmt downgrade
Router(config)#
rxmer-exempt-mslot-pct value
The following example shows how to configure RxMER downgrade in cBR-8:
Router(config)# cable upstream ofdma-prof-mgmt rxmer-poll-interval 5

Router(config)# cable upstream ofdma-prof-mgmt prof-upgrade-auto
Router(config)# cable upstream ofdma-prof-mgmt downgrade rxmer-enable
Router(config-ofdma-mod-profile)# ofdma-prof-mgmt downgrade rxmer min-iuc 12
To display the count of profile partial downgrade, use the command as shown in the following example:
649
Router# show cable modem 4800.33ef.3dd2 prof-mgmt upstream

Upstream Profile Management Data :
Ucid : 6
Recommended IUC : 13
Current IUC : 13
Downgrade IUC : 13
DBC : 0/0/0/0/0 (send/succeed/err/reject/timeout)
State : MER Received
Profile Downgrade Partial count : 1
mslot RxMER(in 1/4 dB):
# msMer 0 : B3B7B4B0 B5ADB1B1 A6A9A5A3 89867A66 3A2C4152 53525D59 595F5C5F 5F636366
# msMer 32 : 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
# msMer 64 : 00000000 00000000
SC RxMER Distribution (Excluded SCs are ignored):*: 2%
>44dB: ***** 10.00%
>42dB: ** 4.31%
>39dB: 0.86%
>36dB: 1.55%
>33dB: * 2.41%
>30dB: 1.29%
>27dB: ** 5.17%
>24dB: **** 8.27%
>21dB: * 3.96%
>18dB: 1.63%
>15dB: 1.20%
<15dB: ***************************** 59.31%
---------------------------------------------------100
Percent of Subcarriers

Feature History
Display CM counts per US IUC Cisco IOS XE Bengaluru 17.6.1x This feature introduces new
and DS profile commands show cable modem
phy ofdm downstream prof-count
and show cable modem phy ofdm
upstream iuc-count, it helps
tracking and reporting number of
Cable Modems being in use per
Upstream IUC and Downstream
Profile on each controller
separately. These counters are
indicative of health of the RF plant.
To display the CM count per upstream port and IUC, use the show cable modem phy ofdm upstream
iuc-count command as shown in the example below:
650
Feature Information for Upstream Profile Selection
Router#show cable modem phy ofdm upstream iuc-count

|<----------- CM Count per profile ----------->|
I/F IF-INDX IUC-5 IUC-6 IUC-9 IUC-10 IUC-11 IUC-12 IUC-13
----------- ------- ------ ------ ------ ------ ------ ------ ------
C1/0/0/U6 488046 3 0 0 0 0 0 3
C1/0/0/U7 488047 3 0 0 0 0 0 3
C9/0/0/U6 501870 1 0 0 0 0 0 1
C9/0/0/U7 501871 1 0 0 0 0 0 1
C9/0/1/U6 501918 1 0 0 0 0 0 2
C9/0/1/U7 501919 1 0 0 0 0 0 2

Table 112: Feature Information for Upstream Profile Selection
DOCSIS3.1 US Profile Cisco IOS XE Fuji 16.7.1 This feature was integrated into Cisco IOS XE Fuji
Selection 16.7.1 on the Cisco cBR Series Converged
Broadband Routers.
Codeword Errors Cisco IOS XE Gibraltar This feature was integrated into Cisco IOS XE
Monitoring 16.12.1x Gibraltar 16.12.1x on the Cisco cBR Series
Converged Broadband Routers.
Downgrading to Partial Cisco IOS XE Gibraltar This feature was integrated into Cisco IOS XE
Mode 16.12.1y Gibraltar 16.12.1y on the Cisco cBR Series
RxMER Downgrade Cisco IOS XE Gibraltar This feature was integrated into Cisco IOS XE
16.12.1z Gibraltar 16.12.1z on the Cisco cBR Series
651
652
CHAPTER 43
Proactive Network Management
This document describes how to configure the Proactive Network Management on the Cisco cBR Series
• Information about Proactive Network Management, on page 654
• Proactive Network Management Using Upstream Triggered Spectrum Capture , on page 654
• Proactive Network Management using OFDMA RxMER Probes, on page 679
• Troubleshooting Proactive Network Management Issues, on page 683
• Feature Information for Proactive Network Management, on page 685
Note The hardware components that are introduced in a given Cisco IOS-XE release are supported in all subsequent
Cisco cBR-8 Converged Broadband Cisco IOS-XE Release 3.15.0S Cisco IOS-XE Release 3.15.0S
Router and Later Releases and Later Releases
• PID—CBR-CCAP-SUP-160G • PID—CBR-CCAP-LC-40G-R
• PID—CBR-CCAP-SUP-60G3 • PID—CBR-CCAP-LC-80G-R
3
Effective with Cisco IOS-XE Release 3.17.0S, CBR-CCAP-SUP-60G supports 8 cable line cards. The
total traffic rate is limited to 60 Gbps. The total number of downstream service flows is limited to 72268,
and downstream unicast low-latency flow does not count against the limits.
653
Information about Proactive Network Management
Information about Proactive Network Management

Proactive Network Management (PNM) enables you to measure and report conditions in the network. The
PNM detects, identifies, and quantifies undesired impacts to the network, such as cable faults and ingress
noise. The DOCSIS 3.1 PHY specification defines the different types of tests and measurements that can be
performed at CCAP and CM. You can leverage this information to make the necessary modifications that can
improve conditions and monitor networking trends to detect when network improvements are needed.
The PNM tests and receives data output from the CMTS using the Simple Network Management Protocol
(SNMP) objects. The PNM feature is supported on RPHY.
Proactive Network Management for Supervisor High Availability, Line Card

High Availability and containers
PNM Supervisor High Availability support ensures that all captures are stopped and all the captures states in
the Line Card and Supervisor client are cleaned up when Supervisor High Availability happens. You can
create new capture configurations and initiate tests on the newly active supervisor through SNMP.
cBR supports Line Card High Availability and Line Card Process Restart for Proactive Network Management,
and will support the restart of any test in progress.
Active syncing of capture data between active and standby SUP is not supported for Proactive Network
Management. After switchover, all new captures must be configured by the user/client again.
Bulk Data Transfer MIBs enables configuration of the following paramters for PNM:
• TFTP server bulk data transfer IP address
• TFTP server bulk data transfer path
Proactive Network Management Using Upstream Triggered

Spectrum Capture
Cisco cBR-8 supports Upstream Triggered Spectrum Capture (UTSC). The upstream triggered spectrum
analysis measurement provides a wideband spectrum analyzer in the CCAP which can be triggered to examine
upstream transmissions and underlying noise or interference during a quiet period.
The Cisco cBR-8 supports the following Upstream Triggered Spectrum Capture objects:
• UsTriggeredSpectrumCaptureFile
• UsTriggeredSpectrumCaptureCfg
• UsTriggeredSpectrumCaptureCtrl
• UsTriggeredSpectrumCaptureStatus
• UsTriggeredSpectrumCaptureCapabilities
• CCAPBulkDataControl
654
Proactive Network Management Using Upstream Triggered Spectrum Capture
The Cisco cBR-8 router enables you to trigger a spectrum sample capture and perform spectrum-analysis
using the FreeRun mode. FreeRun mode is a continuous-mode with a maximum of 10 samples per second
stacked on each capture file).
The CCAP supports one client configuration per port on a line card. Create a capture configuration entry
before attempting to start or stop the capture tests. The interface index key for the
UsTriggeredSpectrumCaptureCfg object defines the one capture configuration for the FreeRun trigger mode.
The Cisco cBR-8 supports only one capture per end-user client per port simultaneously. Hence, the CCAP
sets the Upstream Triggered Spectrum Capture configuration index to 1. The Cisco cBR-8 does not support
a PNM MIB query for an Upstream Triggered Spectrum Capture configuration index other than 1. The Cisco
cBR-8 supports a maximum of eight captures on upstream ports per line card. The Cisco cBR-8 supports a
maximum of 20 captures per router for RPHY.
The Cisco cBR-8 does not support the following scenarios:
• UsTriggeredSpectrumCaptureResult MIB
• Simultaneous captures on adjacent ports on CLC
• RPD support captures only one us-port per RPD at a given time.
• docsPnmCmtsUtscCfgFilename OID
Note The UsTriggeredSpectrumCaptureConfiguration MIB is supported. The docsPnmCmtsUtscCfgFilename OID

under this MIB is not supported only for UTSC capture mode for PNM.
The PNM IOX container is used for the TFTP transfer of capture files to a user configured destination server.
The guestshell IOX container for TFTP transfer of PNM files is supported. The PNM executable is built into
the guestshell that is packaged as part of cbr8 image. This executable must be installed on both active and
standby SUP manually.
Step 1 Ensure that the guestshell container is running before the captures are started to ensure successful TFTP operation. Use
the show app-hosting list command to check if the guestshell container is running.
Example:
Router# show app-hosting list

App id Stat
-----------------------------------------------------
guestshell RUNNING
Step 2 The app-hosting CLI is used to install, deploy, start, and stop the IOX container.
Example:
Router# show run | begin app-hosting

app-hosting appid guestshell
app-vnic gateway0 virtualportgroup 4 guest-interface 0
guest-ipaddress 9.32.254.2 netmask 255.255.255.0
app-default-gateway 9.32.254.1 guest-interface
Step 3 Ensure that the python is running on the guestshell container.

Example:
655
Proactive Network Management Interface Index
cBR8#guestshell run python -V

Python 2.7.5
Step 4 Ensure that the PNM TFTP process is active and running on the guestshell container.
Example:
cBR8#guestshell run systemctl status pnm

pnm.service - cbr pnm telemetry delivery system
Loaded: loaded (/etc/systemd/system/pnm.service; disabled; vendor preset: disabled)
Active: active (running) since Wed 2019-01-09 15:13:40 UTC; 9min ago
The PNM capture tests generate files to report measurements or test results. The results file includes header
information that is common to all types of PNM tests and fields. The file also includes data that is specific to
the type of PNM test. The abstract PnmCaptureFile object defines the attributes and format of the header
information common to all PNM test files. File header fields are right-justified within the field and left-padded
with zero values if necessary.
The following fields define the header for the PnmCaptureFile object for Upstream Spectrum Triggered
Capture tests.
• FileType - A four-byte hexadecimal identifier specific to the type of PNM test that generated the data
file.
For Upstream Triggered Spectrum Capture, the file type is 0x504e4e6a.
• Major Version - This attribute represents the file header version. This value is incremented by one when
the header format is modified by this specification.
For Upstream Triggered Spectrum Capture, major version is 0x1.
• Minor Version - This attribute is reserved for vendor-specific and vendor-defined version information.
For Upstream Triggered Spectrum Capture, minor version is 0x0.
• CaptureTime - This attribute represents the epoch time (also known as 'UNIX time') which is the number
of seconds that have elapsed since midnight Coordinated Universal Time (UTC), Thursday, 1 January
1970.
• IfIndex - This attribute represents the ifIndex of the upstream RF port sampled.
• UniqueCcapId - A 256-byte hexadecimal field representing a unique CCAP identifier (either a loopback
address (IPv4 or IPv6) or FQDN). This value is a null-terminated string.
For Upstream Triggered Spectrum Capture, this value is the ‘hostname’ of the CMTS.

To determine which slot/subslot/port of an ifindex translates to that of RPHY, see the mapping in the running
configuration.
656
Before you begin

The Upstream Triggered Spectrum Capture – The Cisco cBR-8 router supports multiple RPDs per line card
with multiple US-ports. However, on RPDs, you can configure only one US-port and initiate the captures
anytime.
For RPHY, it is not mandatory that the US port is bound to a MAC domain. If it is configured under an RPD,
it can be configured for PNM.
The SNMP ifindex for MIB objects can be obtained using the show CLI:
Router# show snmp mib ifmib ifindex | i 0053.0013.2be0

RPD(0053.0013.2be0)-usport0: Ifindex = 435564
where 0053.0013.2be0 is the RPD identifier.
Step 1 Run the following show command to identify the SNMP ifindex value:
Router# show snmp mib ifmib ifindex | i 435564

RPD(0053.0013.2be0)-usport0: Ifindex = 435564
Step 2 Run the following command to identify the slot/subslot/port an ifindex that translates to RPHY:
Router# show run | b 0053.0013.2be0

identifier 0053.0013.2be
core-interface Te1/1/0
principal
rpd-ds 0 downstream-cable 1/0/2 profile 2
The slot/subslot/port is upstream-cable 1/0/2 profile 21.
657
Note Cisco IOS XE Gibraltar 16.10.1g introduces an RPHY ifIndex change. Ensure that you have gone through
the following updates to enable the changes:
• The RPHY ifIndex feature removes the Cisco private ifIndex for PRHY channels (ifIndex starting from
41,000). The ifIndex are not created manually. All the ifIndex are created automatically when configuring
RPD. It is applicable for ifIndex starting from 41w for US (if-type 205) and DS (if-type 128). The RPHY
ifIndex feature does not work for ifIndex values that are greater than 41w.
Before the ifIndex feature, in 16.10.1f and earlier releases:
Router# show snmp mib ifmib ifindex | i RPD
Upstream-Cable3/0/63:0-RPD(0053.0013.420c)-usport0: Ifindex = 421224
……
RPD(0053.0013.420c)-usport0: Ifindex = 435560
RPD(0053.0013.420c)-dsport0: Ifindex = 436584
Downstream-Cable3/0/31:0-RPD(0053.0013.420c)-dsport0: Ifindex = 437608
Downstream-Cable3/0/31:1-RPD(0053.0013.420c)-dsport0: Ifindex = 437609
With the ifIndex feature, in 16.10.1g:

Router# show snmp mib ifmib ifindex | s RPD
• The RPHY ifIndex reimplement CoreToRpdMap/RpdToCoreMap tables to keep them aligned with
DOCS-RPHY-MIB-2018-07-26 definition.
You do not need to create a new ifIndex for US (if-type 205) and DS (if-type 128) channels when they are
configured to RPD. For versions before Cisco IOS XE Gibraltar 16.10.1g, it was required to create a new
ifIndex (>41k) for US (if-type 205) and DS (if-type 128) channels when they are configured to RPD:
[CBR]#show snmp mib ifmib ifindex | s RPD
With the Cisco cBR-8 16.10.1g RPHY ifIndex feature, you do not need to manually populate any extra item
in legacy MIBs.
With the Cisco cBR-8 16.10.1g RPHY ifIndex feature, you must reimplement
docsRphyRpdIfCoreToRpdMapTable / docsRphyRpdIfRpdToCoreMapTable, not mapping to ifIndex (>41k)
for US (if-type 205) and DS (if-type 128). See the following:
/* docsRphyRpdIfCoreToRpdMapRpdRfChanType OID :1.3.6.1.4.1.4491.2.1.30.1.2.6.1.5
Table Index: docsRphyRpdIfCoreToRpdMapRpdCoreIndex, docsRphyRpdIfCoreToRpdMapRpdUniqueId,
docsRphyRpdIfCoreToRpdMapRpdRfPortDirection, docsRphyRpdIfCoreToRpdMapRpdRfPortIndex*/
SNMPv2-SMI::enterprises.4491.2.1.30.1.2.6.1.5.403561.0.4.159.51.0.145.2.0 = INTEGER:
usAtdma(5)
SNMPv2-SMI::enterprises.4491.2.1.30.1.2.6.1.5.322358.0.4.159.51.0.145.1.0 = INTEGER:
dsScQam(1)
IF-MIB::ifType.403561 = INTEGER: docsCableUpstream(129)
IF-MIB::ifType.322358 = INTEGER: other(1)
[CBR]#show snmp mib ifmib ifindex

Cable9/0/0-upstream1: Ifindex = 403561
Downstream-Cable9/0/4-downstream14: Ifindex = 322358
• If RfChanType is usAtdma(5), ifType of docsRphyRpdIfCoreToRpdMapRpdCoreIndex is ifType

docsCableUpstream(129)
• If RfChanType is dsScQam(1), ifType of docsRphyRpdIfCoreToRpdMapRpdCoreIndex is other(1).
658
Upstream Triggered Spectrum Capture Configuration Parameters
Upstream Triggered Spectrum Capture Configuration Parameters

The following configuration parameters for Upstream Triggered Spectrum Capture are supported. Examples
of using the MIBs are also included.
Note PNM capture configuration on cBR8 is supported only through SNMP user interface. Configuration examples
for MIB commands for PNM are provided in the following sections with examples using both snmpr
(setany/getone commands) as well as net-snmp tools (snmpset/snmpget commands).
Upstream Triggered Spectrum Capture Configuration Objects

The following Upstream Triggered Spectrum Capture configuration objects are supported:
• PNM UTSC OBJECTS OID: 1.3.6.1.4.1.4491.2.1.27.1.3.10
• PNM UTSC CAPTURE CONFIGURATION OID: 1.3.6.1.4.1.4491.2.1.27.1.3.10.2.1.X.Y.Z
Where X is the capture config parameter, Y is Ifindex, and Z is the PNM UTSC Config Index – Which
is always 1. Currently only one capture configuration per upstream port is supported.
• The following capture configuration parameters are supported, and the corresponding MIB OID value
is listed.
Table 114: Supported capture configuration parameters and the corresponding MIB OID value
Capture configuration parameters Corresponding MIB OID value
I_docsPnmCmtsUtscCfgTriggerMode 1.3.6.1.4.1.4491.2.1.27.1.3.10.2.1.3
I_docsPnmCmtsUtscCfgCmMacAddr 1.3.6.1.4.1.4491.2.1.27.1.3.10.2.1.6
I_docsPnmCmtsUtscCfgCenterFreq 1.3.6.1.4.1.4491.2.1.27.1.3.10.2.1.8
I_docsPnmCmtsUtscCfgSpan 1.3.6.1.4.1.4491.2.1.27.1.3.10.2.1.9
I_docsPnmCmtsUtscCfgNumBins 1.3.6.1.4.1.4491.2.1.27.1.3.10.2.1.10
I_docsPnmCmtsUtscCfgAveraging 1.3.6.1.4.1.4491.2.1.27.1.3.10.2.1.11
I_docsPnmCmtsUtscCfgQualifyCenterFreq 1.3.6.1.4.1.4491.2.1.27.1.3.10.2.1.13
I_docsPnmCmtsUtscCfgQualifyBw 1.3.6.1.4.1.4491.2.1.27.1.3.10.2.1.14
I_docsPnmCmtsUtscCfgQualifyThrshld 1.3.6.1.4.1.4491.2.1.27.1.3.10.2.1.15
I_docsPnmCmtsUtscCfgWindow 1.3.6.1.4.1.4491.2.1.27.1.3.10.2.1.16
I_docsPnmCmtsUtscCfgOutputFormat 1.3.6.1.4.1.4491.2.1.27.1.3.10.2.1.17
I_docsPnmCmtsUtscCfgRepeatPeriod 1.3.6.1.4.1.4491.2.1.27.1.3.10.2.1.18
I_docsPnmCmtsUtscCfgFreeRunDuration 1.3.6.1.4.1.4491.2.1.27.1.3.10.2.1.19
I_docsPnmCmtsUtscCfgTriggerCount 1.3.6.1.4.1.4491.2.1.27.1.3.10.2.1.20
659
Upstream Triggered Spectrum Capture Configuration MIB Objects
Capture configuration parameters Corresponding MIB OID value
I_docsPnmCmtsUtscCfgStatus 1.3.6.1.4.1.4491.2.1.27.1.3.10.2.1.21
Starting from Cisco IOS XE Gibraltar 16.12.1x release, PNM output format ‘timeIQ’ and UTSC trigger mode
‘cmMac’ are supported in upstream triggered spectrum capture configuration objects.
Below is an example of the SNMP command configuration with PNM output format ‘timeIQ’ and UTSC
trigger mode ‘cmMac’.
snmpset -v2c -c private 10.74.54.13 1.3.6.1.4.1.4491.2.1.27.1.1.1.2.0 x "0B 01 01 0C"
snmpset -v2c -c private 10.74.54.13 1.3.6.1.4.1.4491.2.1.27.1.1.1.3.0 s "path"
snmpset -v2c -c private 10.74.54.13 1.3.6.1.4.1.4491.2.1.27.1.3.10.2.1.21.415084.1 i 6

snmpset -v2c -c private 10.74.54.13 1.3.6.1.4.1.4491.2.1.27.1.3.10.2.1.2.415084.1 i ifindex
snmpset -v2c -c private 10.74.54.13 1.3.6.1.4.1.4491.2.1.27.1.3.10.2.1.6.415084.1 x "CM
MAC"
snmpset -v2c -c private 10.74.54.13 1.3.6.1.4.1.4491.2.1.27.1.3.10.2.1.8.415084.1 u 16400000
snmpset -v2c -c private 10.74.54.13 1.3.6.1.4.1.4491.2.1.27.1.3.10.2.1.15.415084.1 i -200

The following Upstream Triggered Spectrum Capture configuration MIB objects are supported for PNM:
• CaptureCfg – Contains the test trigger mode and its required configuration.
• CaptureCtrl – Controls when the test is started and stopped.
• CaptureStatus – Contains the current status of the test.
• CaptureCapability – Exposes CCAP Upstream Triggered Spectrum Capture capabilities.
The following Upstream Triggered Spectrum Capture configuration MIBs are supported. SNMP walk is
supported for all the MIB objects.
• docsPnmCmtsUtscCfgTriggerMode - This attribute indicates which upstream triggered spectrum capture
function trigger modes are supported. Only FreeRun is supported. The following are the enumerated
values for trigger mode for PNM.
• D_docsPnmCmtsUsSpecAnTrigMode_other 1
• D_docsPnmCmtsUsSpecAnTrigMode_freeRunning 2
• D_docsPnmCmtsUsSpecAnTrigMode_miniSlotCount 3
• D_docsPnmCmtsUsSpecAnTrigMode_sid 4
660
• D_docsPnmCmtsUsSpecAnTrigMode_idleSid 5
• D_docsPnmCmtsUsSpecAnTrigMode_minislotNumber 6
• D_docsPnmCmtsUsSpecAnTrigMode_cmMac 7
• D_docsPnmCmtsUsSpecAnTrigMode_quietProbeSymbol 8
• For FreeRun mode, the CCAP initiates sampling and continues sampling until the time duration configured
in the attribute FreeRunDuration has transpired. Sampling terminates when the time duration configured
in FreeRunDuration has elapsed or when FFT is disabled. The interval between captures is the greater
of RepeatPeriod and the minimum period that is supported by the CCAP.
• From Cisco IOS XE Gibraltar 16.12.1x release, PNM output format ‘timeIQ’ and UTSC trigger mode
‘cmMac’ are supported in upstream triggered spectrum capture configuration objects.
• Trigger mode set and get examples:
• snmpr commands:
• server> setany -v2c <cmts_ip> <community_name>
1.3.6.1.4.1.4491.2.1.27.1.3.10.2.1.3.<ifIndex>.1 -i 2
clabProjDocsis.27.1.3.10.2.1.3.<ifIndex>.1 = 2
• server> getone -v2c <cmts_ip> <community_name>

1.3.6.1.4.1.4491.2.1.27.1.3.10.2.1.3.<ifIndex>.1
clabProjDocsis.<ifIndex> = 2
• net-snmp commands:
• server> snmpset -v2c -c <community_name> <cmts_ip>
1.3.6.1.4.1.4491.2.1.27.1.3.10.2.1.3.<ifIndex>.1 i 2
SNMPv2-SMI::enterprises.4491.2.1.27.1.3.10.2.1.3.<ifIndex>.1 = INTEGER: 2
• server> snmpget -v2c -c <community_name> <cmts_ip>

1.3.6.1.4.1.4491.2.1.27.1.3.10.2.1.3.<ifIndex>.1
• docsPnmCmtsUtscCfgCenterFreq - This attribute specifies the center frequency of the upstream spectrum
to be sampled for analysis.
• snmpr commands:
1.3.6.1.4.1.4491.2.1.27.1.3.10.2.1.8.<ifIndex>.1 –g 102400000
clabProjDocsis.27.1.3.10.2.1.8.<ifIndex> = 102400000

1.3.6.1.4.1.4491.2.1.27.1.3.10.2.1.8.<ifIndex>.1
1.3.6.1.4.1.4491.2.1.27.1.3.10.2.1.8.<ifIndex>.1 u 102400000
SNMPv2-SMI::enterprises.4491.2.1.27.1.3.10.2.1.8.<ifIndex>.1 = Gauge32: 102400000

1.3.6.1.4.1.4491.2.1.27.1.3.10.2.1.8.<ifIndex>.1
661
• docsPnmCmtsUtscCfgSpan - This attribute determines the frequency span of the upstream spectrum
sample capture. When this attribute is read, it provides the actual span, which may be different from the
requested (configured) span due to implementation effects.
• snmpr commands:
1.3.6.1.4.1.4491.2.1.27.1.3.10.2.1.9.<ifIndex>.1 –g 204800000

1.3.6.1.4.1.4491.2.1.27.1.3.10.2.1.9.<ifIndex>.1
1.3.6.1.4.1.4491.2.1.27.1.3.10.2.1.9.<ifIndex>.1 u 204800000

1.3.6.1.4.1.4491.2.1.27.1.3.10.2.1.9.<ifIndex>.1
Note The center frequency and span capture parameters are set to zero as per OSSI
specifications on capture configuration entry creation. For freerun trigger mode,
you must set these values in the valid range to run capture tests on the port.
• docsPnmCmtsUtscCfgNumBins - This attribute determines the number of frequency bins or samples per
span when sampling the upstream spectrum. This attribute provides the actual number of bins, which
may be different from the configured number due to implementation effects.
• snmpr commands
1.3.6.1.4.1.4491.2.1.27.1.3.10.2.1.10.<ifIndex>.1 –g 4096

1.3.6.1.4.1.4491.2.1.27.1.3.10.2.1.10.<ifIndex>.1
• net-snmp commands
1.3.6.1.4.1.4491.2.1.27.1.3.10.2.1.10.<ifIndex>.1 u 4096

1.3.6.1.4.1.4491.2.1.27.1.3.10.2.1.10.<ifIndex>.1
• docsPnmCmtsUtscCfgAveraging - This attribute specifies whether the CCAP should average spectral
frequency domain sample power to remove spurious spectral peaks and troughs and the number of samples
to use to calculate the average power. The CCAP must not calculate the average of the upstream spectrum
662
samples when the value of Averaging is zero. The CCAP MUST calculate the average power of upstream
spectrum samples, over the number of samples that are specified, when the value of the Averaging
attribute is nonzero.
• snmpr commands
1.3.6.1.4.1.4491.2.1.27.1.3.10.2.1.11.<ifIndex>.1 –g 245

1.3.6.1.4.1.4491.2.1.27.1.3.10.2.1.11.<ifIndex>.1
1.3.6.1.4.1.4491.2.1.27.1.3.10.2.1.11.<ifIndex>.1 u 245

1.3.6.1.4.1.4491.2.1.27.1.3.10.2.1.11.<ifIndex>.1
• docsPnmCmtsUtscCfgCmMacAddr - This attribute specifies the cable modem from which the CCAP
captures upstream transmissions. This attribute is used only when the TriggerMode is CmMac and is
ignored otherwise.
1.3.6.1.4.1.4491.2.1.27.1.3.10.2.1.6.<ifIndex>.1
x “CM-MAC”

1.3.6.1.4.1.4491.2.1.27.1.3.10.2.1.6.<ifIndex>.1
• docsPnmCmtsUtscCfgQualifyCenterFreq - This attribute specifies the center frequency of a band that

is used to qualify a spectrum for upload. The average of the FFT linear power values in this band is
computed and compared to a threshold. If the average power in the band is below the threshold, the
spectrum is discarded. If the power average is greater than or equal to the threshold, the spectrum is
considered qualified.
• snmpr commands
1.3.6.1.4.1.4491.2.1.27.1.3.10.2.1.13.<ifIndex>.1 –g 102400000

1.3.6.1.4.1.4491.2.1.27.1.3.10.2.1.13.<ifIndex>.1
1.3.6.1.4.1.4491.2.1.27.1.3.10.2.1.13.<ifIndex>.1 u 102400000
SNMPv2-SMI::enterprises.4491.2.1.27.1.3.10.2.1.13.<ifIndex>.1 = Gauge32:
102400000
663

1.3.6.1.4.1.4491.2.1.27.1.3.10.2.1.13.<ifIndex>.1
SNMPv2-SMI::enterprises.4491.2.1.27.1.3.10.2.1.13.<ifIndex>.1 = Gauge32:
102400000
• docsPnmCmtsUtscCfgQualifyBw - This attribute specifies the bandwidth of a band that is used to qualify
a spectrum for upload. The average of the FFT linear power values in this band is computed and compared
to a threshold. If the average power in the band is below the threshold, the spectrum is discarded. If the
power average is greater than or equal to the threshold, the spectrum is considered qualified.
• snmpr commands:
1.3.6.1.4.1.4491.2.1.27.1.3.10.2.1.14.<ifIndex>.1 –g 25600000

1.3.6.1.4.1.4491.2.1.27.1.3.10.2.1.14.<ifIndex>.1
1.3.6.1.4.1.4491.2.1.27.1.3.10.2.1.14.<ifIndex>.1 u 25600000

1.3.6.1.4.1.4491.2.1.27.1.3.10.2.1.14.<ifIndex>.1
• docsPnmCmtsUtscCfgQualifyThrshld - This attribute specifies the threshold that is applied to qualify a

spectrum for upload. The average of the FFT linear power values in the specified band is computed and
compared to this threshold. If the average power in the band is below the threshold, the spectrum is
discarded. If the power average is greater than or equal to the threshold, the spectrum is considered
qualified.
• snmpr commands
1.3.6.1.4.1.4491.2.1.27.1.3.10.2.1.15.<ifIndex>.1 –i 200
clabProjDocsis.27.1.3.10.2.1.15.<ifIndex> = -200

1.3.6.1.4.1.4491.2.1.27.1.3.10.2.1.15.<ifIndex>.1
clabProjDocsis.27.1.3.10.2.1.15.<ifIndex>.1 = -200
1.3.6.1.4.1.4491.2.1.27.1.3.10.2.1.15.<ifIndex>.1 i -200
SNMPv2-SMI::enterprises.4491.2.1.27.1.3.10.2.1.15.<ifIndex>.1 = INTEGER: -200

1.3.6.1.4.1.4491.2.1.27.1.3.10.2.1.15.<ifIndex>.1
SNMPv2-SMI::enterprises.4491.2.1.27.1.3.10.2.1.15.<ifIndex>.1 = INTEGER: -200
• docsPnmCmtsUtscCfgWindow - This attribute indicates which of the upstream triggered spectrum capture
function window formats are supported by the CCAP. Currently Cisco cBR-8 supports rectangular
664
(default), Blackmann-Harris, and Hann and Hamming formats. The following are the enumerated values
for window mode for PNM.
• D_docsPnmCmtsUtscCfgWindow_other 1
• D_docsPnmCmtsUtscCfgWindow_rectangular 2
• D_docsPnmCmtsUtscCfgWindow_hann 3
• D_docsPnmCmtsUtscCfgWindow_blackmanHarris 4
• D_docsPnmCmtsUtscCfgWindow_hamming 5
• D_docsPnmCmtsUtscCfgWindow_flatTop 6
• D_docsPnmCmtsUtscCfgWindow_gaussian 7
• D_docsPnmCmtsUtscCfgWindow_chebyshev 8
• Window mode set and get examples:

• snmpr commands:
1.3.6.1.4.1.4491.2.1.27.1.3.10.2.1.16.<ifIndex>.1 -i 3
clabProjDocsis.27.1.3.10.2.1.16.<ifIndex>.1= 3

1.3.6.1.4.1.4491.2.1.27.1.3.10.2.1.16.<ifIndex>.1

1.3.6.1.4.1.4491.2.1.27.1.3.10.2.1.16.<ifIndex>.1 -i 6
Error code set in packet - COMMIT_FAILED_ERROR: 1.
1.3.6.1.4.1.4491.2.1.27.1.3.10.2.1.16.<ifIndex>.1 i 3

1.3.6.1.4.1.4491.2.1.27.1.3.10.2.1.16.<ifIndex>.1

1.3.6.1.4.1.4491.2.1.27.1.3.10.2.1.16.<ifIndex>.1 i 6
Error in packet.
Reason: commitFailed
Failed object: SNMPv2-SMI::enterprises.4491.2.1.27.1.3.10.2.1.16.<ifIndex>.1
Note • Flat-top, Gaussian, and Chebyshev window-modes are not supported.
• docsPnmCmtsUtscCfgOutputFormat - This attribute indicates the upstream triggered spectrum capture

function data output formats that are supported by the CCAP. The CCAP is capable of reporting upstream
spectrum sample FFT output data in power format. The enumeration value for power format is fftPower.
665
CCAP supports time-IQ and fftPower output format. The time-IQ is supported from Cisco IOS XE
Gibraltar 16.12.1x. The following are the enumerated values for output format mode for PNM.
• D_docsPnmCmtsUtscCfgOutputFormat_timeIQ 1
• D_docsPnmCmtsUtscCfgOutputFormat_fftPower 2
• D_docsPnmCmtsUtscCfgOutputFormat_rawAdc 3
• D_docsPnmCmtsUtscCfgOutputFormat_fftIQ 4
• D_docsPnmCmtsUtscCfgOutputFormat_fftAmplitude 5
• D_docsPnmCmtsUtscCfgOutputFormat_fftDb 6
• Output format mode set and get examples:

• snmpr commands:
1.3.6.1.4.1.4491.2.1.27.1.3.10.2.1.17.<ifIndex>.1 -i 2

1.3.6.1.4.1.4491.2.1.27.1.3.10.2.1.17.<ifIndex>.1

1.3.6.1.4.1.4491.2.1.27.1.3.10.2.1.17.<ifIndex>.1 -i 4
Error code set in packet - COMMIT_FAILED_ERROR: 1.
1.3.6.1.4.1.4491.2.1.27.1.3.10.2.1.17.<ifIndex>.1 i 2

1.3.6.1.4.1.4491.2.1.27.1.3.10.2.1.17.<ifIndex>.1

1.3.6.1.4.1.4491.2.1.27.1.3.10.2.1.17.<ifIndex>.1 i 4

1.3.6.1.4.1.4491.2.1.27.1.3.10.2.1.17.<ifIndex>.1 i 1
Note Only the fft-pwr and time-IQ output formats are currently supported.
• docsPnmCmtsUtscCfgRepeatPeriod - This attribute specifies the length of time in milliseconds for which
the CCAP continues to capture and return FFT results when in free running mode. The CCAP is permitted
to trigger at larger intervals if unable to support the requested interval. Configuring a zero value indicates
that the test is to run once only.
• The Repeat Period is configured in microseconds and default is 50000 usec. The CCAP MUST reject
an attempt to set RepeatPeriod to a value greater than the current value of FreeRunDuration.
666
• Repeat Period set and get examples:

• snmpr commands:
1.3.6.1.4.1.4491.2.1.27.1.3.10.2.1.18.<ifIndex>.1 -g 25000

1.3.6.1.4.1.4491.2.1.27.1.3.10.2.1.18.<ifIndex>.1
1.3.6.1.4.1.4491.2.1.27.1.3.10.2.1.18.<ifIndex>.1 u 25000

1.3.6.1.4.1.4491.2.1.27.1.3.10.2.1.18.<ifIndex>.1
• docsPnmCmtsUtscCfgFreeRunDuration - This attribute specifies the length of time in milliseconds for

which the CCAP continues to capture and return FFT results when in free running mode. Sample captures
are expected to take a few microseconds. If FreeRunDuration is set for longer than a sample capture
duration, the CCAP could potentially capture more sample data than it can store.
• The CCAP MUST reject an attempt to set FreeRunDuration to a value less than the current value of
RepeatPeriod. Freerun duration is configured in millisec and the default value is 1000ms (1 second).The
CCAP CLC currently captures 10 samples per second stacked in a single file. With default freerun
duration configuration, there will be 11 samples.
• FreeRun Duration set and get examples:
• snmpr commands
1.3.6.1.4.1.4491.2.1.27.1.3.10.2.1.19.<ifIndex>.1 -g 5000

1.3.6.1.4.1.4491.2.1.27.1.3.10.2.1.19.<ifIndex>.1
1.3.6.1.4.1.4491.2.1.27.1.3.10.2.1.19.<ifIndex>.1 u 5000

1.3.6.1.4.1.4491.2.1.27.1.3.10.2.1.19.<ifIndex>.1
• docsPnmCmtsUtscCfgTriggerCount - This attribute determines the number of times to trigger upstream

spectrum sample capture when Enable and InitiateTest are set to true and configured trigger conditions
are met. The trigger count configuration does NOT apply and is ignored by CCAP for captures in FreeRun
trigger mode.
667
• Trigger count set and get examples:

• snmpr commands
1.3.6.1.4.1.4491.2.1.27.1.3.10.2.1.20.<ifIndex>.1 -g 200

1.3.6.1.4.1.4491.2.1.27.1.3.10.2.1.20.<ifIndex>.1
1.3.6.1.4.1.4491.2.1.27.1.3.10.2.1.20.<ifIndex>.1 u 200

1.3.6.1.4.1.4491.2.1.27.1.3.10.2.1.20.<ifIndex>.1
• docsPnmCmtsUtscCfgStatus - This attribute determines the creation, deletion, and change of status of
an actual capture configuration entry on any port of the CCAP CLC. All capture entries must first be
created by a client on a port before attempting to initiate any tests on the port. Thereby the client ‘owns’
that port and its configuration after creation. No other client can run any tests on the port till the currently
active client ‘destroys’ the configuration entry and thereby releases ownership of that port.
• Any tests on a given port that is owned by a client can be run only when the capture configuration status
is ’Active’. When a configuration is created, it is created with certain default values and marked ‘Not
Ready’. All capture parameters must be configured in valid range for the capture entry status to become
‘Active’. If the configuration values for various capture parameters are modified by the user/client and
not according to the OSSI specification, the configuration status of the entry will be marked ‘NotReady’.
• A capture configuration entry cannot be modified to any state unless created first. An entry cannot be
recreated without destroying the previous version first. An entry cannot be modified when capture tests
are currently running on the port.
• The following are the enumerated values for configuration entry status for PNM:
• D_docsPnmCmtsUtscCfgStatus_active 1
• D_docsPnmCmtsUtscCfgStatus_notInService 2
• D_docsPnmCmtsUtscCfgStatus_notReady 3
• D_docsPnmCmtsUtscCfgStatus_createAndGo 4
• D_docsPnmCmtsUtscCfgStatus_createAndWait 5
• D_docsPnmCmtsUtscCfgStatus_destroy 6
• Utsc Configuration Entry set/get example:

• snmpr commands
1.3.6.1.4.1.4491.2.1.27.1.3.10.2.1.21.<ifIndex>.1 -i 4
668
Upstream Triggered Spectrum Capture Control Objects and MIBs
• server > getone -v2c <cmts_ip> <community_name>

1.3.6.1.4.1.4491.2.1.27.1.3.10.2.1.21.<ifIndex>.1
• server > snmpset -v2c -c <community_name> <cmts_ip>
1.3.6.1.4.1.4491.2.1.27.1.3.10.2.1.21.<ifIndex>.1 i 4
• server > snmpget -v2c -c <community_name> <cmts_ip>

1.3.6.1.4.1.4491.2.1.27.1.3.10.2.1.21.<ifIndex>.1
Note A configuration can be created with certain default values and is marked 'Not
Ready'. It is only changed to 'Active' when valid capture configuration parameters
are configured by the user. Capture tests can only be run on configurations that
are 'Active'.
• Set multiple capture config parameters at the same time.

• Server > setany -v2c <cmts_ip> <community_name>
1.3.6.1.4.1.4491.2.1.27.1.3.10.2.1.18.<ifIndex>.1 -g 45000
1.3.6.1.4.1.4491.2.1.27.1.3.10.2.1.20.<ifIndex>.1 -g 10
1.3.6.1.4.1.4491.2.1.27.1.3.10.2.1.8.<ifIndex>.1 -g 100000000
1.3.6.1.4.1.4491.2.1.27.1.3.10.2.1.10.<ifIndex>.1 -g 8092
1.3.6.1.4.1.4491.2.1.27.1.3.10.2.1.15.<ifIndex>.1 -i -100
clabProjDocsis.27.1.3.10.2.1.15.<ifIndex>.1 = -100 10.3.1.1.<ifIndex>.1 = 0
SNMP walk is supported for all the above MIB objects.

The following is an example of SNMP walk on upstream triggered spectrum capture configuration parameter
repeat period:
server > snmpwalk -v2c <cmts_ip> -c <community_name> 1.3.6.1.4.1.4491.2.1.27.1.3.10.2.1.18

<<!snip>>

The following Upstream Triggered Spectrum Capture control objects and MIBs are supported:
• PNM UTSC CAPTURE CONTROL OID: 1.3.6.1.4.1.4491.2.1.27.1.3.10.3.1.1.Y.Z
669
Where Y is Ifindex, and Z is the PNM Upstream Triggered Spectrum Capture Configuration Index –
Which is always 1. Currently only one capture configuration per upstream port is supported.
• The capture control entry can be used to start captures or stop any active captures. The
docsPnmCmtsUtscCtrlInitiateTest is a boolean value which when set, initiates a capture.
• Starting a capture (You can only start a capture only if you have configured and owned the port, and if
the capture configuration entry is active).
• snmpr commands:
1.3.6.1.4.1.4491.2.1.27.1.3.10.3.1.1.<ifIndex>.1 -i 1

1.3.6.1.4.1.4491.2.1.27.1.3.10.3.1.1.<ifIndex>.1
1.3.6.1.4.1.4491.2.1.27.1.3.10.3.1.1.<ifIndex>.1 i 1

1.3.6.1.4.1.4491.2.1.27.1.3.10.3.1.1.<ifIndex>.1
• Stop a capture (You can stop an active capture only if you own that port):
• snmpr commands:
1.3.6.1.4.1.4491.2.1.27.1.3.10.3.1.1.<ifIndex>.1 -i 2

1.3.6.1.4.1.4491.2.1.27.1.3.10.3.1.1.<ifIndex>.1
Note Ensure that you pass a value '2', for the setany command to stop the capture.
1.3.6.1.4.1.4491.2.1.27.1.3.10.3.1.1.<ifIndex>.1 i 2

1.3.6.1.4.1.4491.2.1.27.1.3.10.3.1.1.<ifIndex>.1
670
Upstream Triggered Spectrum Capture Status Objects and MIBs
Note Ensure that you pass a value '2', for the snmpset command to stop the capture.
Upstream Triggered Spectrum Capture Status Objects and MIBs

The following Upstream Triggered Spectrum Capture status objects and MIBs are supported:
• PNM UTSC CAPTURE STATUS OID: 1.3.6.1.4.1.4491.2.1.27.1.3.10.4.1.1.Y.Z
Where Y is Ifindex, and Z is the PNM Upstream Triggered Spectrum Capture Configuration Index –
Which is always 1. Currently only one capture configuration per upstream port is supported.
• The capture status MIB is a read-only MIB. It reports the status of the capture on a given port (if owned
by that client).
• When the value is sampleReady, the CCAP has completed capturing and recording samples. Following
are the enumerated values for capture status entry for PNM.
• D_docsPnmCmtsUtscStatusMeasStatus_other 1
• D_docsPnmCmtsUtscStatusMeasStatus_inactive 2
• D_docsPnmCmtsUtscStatusMeasStatus_busy 3
• D_docsPnmCmtsUtscStatusMeasStatus_sampleReady 4
• D_docsPnmCmtsUtscStatusMeasStatus_error 5
• D_docsPnmCmtsUtscStatusMeasStatus_resourceUnavailable 6
• D_docsPnmCmtsUtscStatusMeasStatus_sampleTruncated 7
• The status is inactive when the capture configuration entry is created and is marked busy when the tests
are actively running on the port. Any platform resource limitation to run a test to make the status ‘resource
unavailable’ and the error encountered while running a test would mark the status as ‘error’.
• Get capture status on a port (You can get the status of capture on the port only if you own that port.
• snmpr commands:
server > getone -v2c <cmts_ip> <community_name>
1.3.6.1.4.1.4491.2.1.27.1.3.10.4.1.1.<ifIndex>.1
server > snmpget -v2c -c <community_name> <cmts_ip>
1.3.6.1.4.1.4491.2.1.27.1.3.10.4.1.1.<ifIndex>.1
Upstream Triggered Spectrum Capture Capability Objects and MIBs

The following Upstream Triggered Spectrum Capture capability objects and MIBs are supported for PNM:
671
Upstream Triggered Spectrum Capture Capability Objects and MIBs

• PNM UTSC CAPTURE CAPABILITY OID: 1.3.6.1.4.1.4491.2.1.27.1.3.10.1.1.X.Y
Where X is the capability parameter and Y is the Ifindex.
• The capture capability MIB is a read-only MIB. The Upstream Triggered Spectrum Capture Capabilities
object exposes capabilities that are supported by the CCAP for Upstream Triggered Spectrum Capture
trigger modes, data output formats, and windowing function used when performing the discrete Fourier
transform.
• The following are the enumerated values for capture capability entry for PNM for CCAP.
• docsPnmCmtsUtscCapabTriggerMode 1
• docsPnmCmtsUtscCapabOutputFormat 2
• docsPnmCmtsUtscCapabWindow 3
• docsPnmCmtsUtscCapabDescription 4
• Get capture capability on a port:

• snmpr commands:
1.3.6.1.4.1.4491.2.1.27.1.3.10.1.1.1.<ifIndex>
docsPnmCmtsObjects.10.1.1.1.<ifIndex> = 00 02

1.3.6.1.4.1.4491.2.1.27.1.3.10.1.1.2.<ifIndex>
docsPnmCmtsObjects.10.1.1.2.<ifIndex> = 04

1.3.6.1.4.1.4491.2.1.27.1.3.10.1.1.3.<ifIndex>
docsPnmCmtsObjects.10.1.1.3.<ifIndex> = 1e

1.3.6.1.4.1.4491.2.1.27.1.3.10.1.1.4.<ifIndex>
docsPnmCmtsObjects.10.1.1.4.<ifIndex> = Center Frequency range and resolution
1.3.6.1.4.1.4491.2.1.27.1.3.10.1.1.1.<ifIndex>
SNMPv2-SMI::enterprises.4491.2.1.27.1.3.10.1.1.1.<ifIndex> = Hex-STRING: 00 02

1.3.6.1.4.1.4491.2.1.27.1.3.10.1.1.2.<ifIndex>
SNMPv2-SMI::enterprises.4491.2.1.27.1.3.10.1.1.2.<ifIndex> = Hex-STRING: 04

1.3.6.1.4.1.4491.2.1.27.1.3.10.1.1.3.<ifIndex>
SNMPv2-SMI::enterprises.4491.2.1.27.1.3.10.1.1.3.<ifIndex> = Hex-STRING: 1

1.3.6.1.4.1.4491.2.1.27.1.3.10.1.1.4.<ifIndex>
SNMPv2-SMI::enterprises.4491.2.1.27.1.3.10.1.1.4.<ifIndex> = STRING: "Center
Frequency range and resolution"
672
Upstream Triggered Spectrum Capture Bulk Data Control Objects and MIBs
Upstream Triggered Spectrum Capture Bulk Data Control Objects and MIBs
The following Upstream Triggered Spectrum Capture bulk data control objects and MIBs are supported for
PNM:
• PNM Bulk Data Control Objects OID: 1.3.6.1.4.1.4491.2.1.27.1.1.1
• PNM BULK DATA CONTROL OID: 1.3.6.1.4.1.4491.2.1.27.1.1.1.X
Where X is the bulk data transfer control parameter.
• The Bulk Data Transfer (BDT) control objects that are supported are the IPaddress type, BDT server IP
and BDT destination path. This indicates to the CCAP the location where the capture results files should
be sent through TFTP transfer. In CBR8, the TFTP transfer is done through IOX container and as such,
other BDT objects are not relevant to this design model. IP address type can be automatically set by
CCAP based on the server IP value specified.
• The following are the enumerated values for BDT for PNM:
• docsPnmBulkDestIpAddrType 1
• docsPnmBulkDestIpAddr 2
• docsPnmBulkDestPath 3
• Set the BDT IPv4 IP address type and TFTP IP address

• snmpr commands:
• server> setany -v2c <cmts_ip> <community_name> 1.3.6.1.4.1.4491.2.1.27.1.1.1.2.0
-o 20:01:0d:b8
docsPnmBulkDestIpAddr.0 = 20 01 0d b8
• server > getone -v2c <cmts_ip> <community_name> 1.3.6.1.4.1.4491.2.1.27.1.1.1.1.0
docsPnmBulkDestIpAddrType.0 = ipv4(1)
1.3.6.1.4.1.4491.2.1.27.1.1.1.2.0 x 20010db8
SNMPv2-SMI::enterprises.4491.2.1.27.1.1.1.2.0 = Hex-STRING: 20 01 0D B8

1.3.6.1.4.1.4491.2.1.27.1.1.1.1.0
SNMPv2-SMI::enterprises.4491.2.1.27.1.1.1.1.0 = INTEGER: 1

1.3.6.1.4.1.4491.2.1.27.1.1.1.2.0

• snmpr commands:
• server > setany -v2c <cmts_ip> <community_name> 1.3.6.1.4.1.4491.2.1.27.1.1.1.2.0
-o 20:01:0d:b8:85:a3:00:00:00:00:8a:2e:03:70:73:11
673
Configuring the PNM MAX-HOLD Trigger Mode
docsPnmBulkDestIpAddr.0 = 2001 0db8 85a3 0000 0000 8a2e 0370 7311
docsPnmBulkDestIpAddrType.0 = ipv6(2)

docsPnmBulkDestIpAddr.0 = 2001 0db8 85a3 0000 0000 8a2e 0370 7311
1.3.6.1.4.1.4491.2.1.27.1.1.1.2.0 x 20010db885a3000000008a2e03707311
SNMPv2-SMI::enterprises.4491.2.1.27.1.1.1.2.0 = Hex-STRING: 20 01 0D B8 85 A3
00 00 00 00 8A 2E 03 70 73 11
1.3.6.1.4.1.4491.2.1.27.1.1.1.1.0

1.3.6.1.4.1.4491.2.1.27.1.1.1.2.0
SNMPv2-SMI::enterprises.4491.2.1.27.1.1.1.2.0 = Hex-STRING: 20 01 0D B8 85 A3
00 00 00 00 8A 2E 03 70 73 11
• Set the BDT destination TFTP path

• snmpr commands:
• server > setany -v2c <cmts_ip> <community_name> 1.3.6.1.4.1.4491.2.1.27.1.1.1.3.0
-o pnm
docsPnmBulkDestPath.0 = pnm
1.3.6.1.4.1.4491.2.1.27.1.1.1.3.0 s ‘pnm/test’
SSNMPv2-SMI::enterprises.4491.2.1.27.1.1.1.3.0 = STRING: "pnm/test"

1.3.6.1.4.1.4491.2.1.27.1.1.1.3.0
SNMPv2-SMI::enterprises.4491.2.1.27.1.1.1.3.0 = STRING: "pnm/test"
Configuring the PNM MAX-HOLD Trigger Mode

When RPHY configuration is for MAX-HOLD PNM mode, RPHY sends PNM data continuously, until the
user issues stop command or the duration is complete.
To configure for MAX-HOLD trigger mode on the Supervisor, complete the following steps:
Step 1 Configure the PNM docsPnmCmtsUsSpecAnTrigMode to ‘other’ mode. Both the SNMP and CLI can set the trigger
mode. See the following examples:
674
Proactive Network Management MAX-HOLD trigger mode
• For SNMP:
• For CLI:
test cable pnm uts configure trigger-mode other
Adding a new TrigMode to MIB might take long and cause many specification changes.
Step 2 Set the PNM bulk destination IP address.

• For SNMP:
snmpset -v2c -c private 80.4.2.11 1.3.6.1.4.1.4491.2.1.27.1.1.1.2.0 x "20 01 0d b8"
• For CLI:
test cable pnm bdt config set-ip 32.1.13.184
Step 3 Start and stop the capture test.

• Starting the SNMP:
• Starting the CLI:

test cable pnm uts start client-id 1 test-id 1 0004.9f00.0591 0
• Stopping the SNMP:

• Stopping the CLI:

test cable pnm uts stop client-id 1 test-id 1 0004.9f00.0591 0
Step 4 Enable GCP message support. Send the TFTP server IP address and Static L2TP session ID through TLV58 message,
and the TrigMode ‘other’ is send to RPD through TLV41 message.
Proactive Network Management MAX-HOLD trigger mode

The cBR enables MAX-HOLD trigger mode support in PNM. The non-CCAP defined MAX-HOLD mode
offers significant advantages over the existing FREE-RUN mode that was used earlier. With the MAX-HOLD
trigger mode, the RPD sends samples much faster - one sample every 2ms, compared to the earlier rate of one
sample per 100ms. The RPD also sends the sample to the server, instead of the Line Card.
The MAX-HOLD trigger mode support functionality includes:
• cBR support for the configuration of the MAX-HOLD trigger mode
• cBR support for notify UBUNTU server IP and Static L2tp session IDs to RPD
• RPD usage of the max hold mode to capture the upstream spectrum
• RPD sending the captured BIN to UBUNTU server
675
Debugging the PNM feature on cBR8
Debugging the PNM feature on cBR8

cBR supports debugging on Upstream Triggered Spectrum Capture – Proactive Network Management by
using the debug commands available for the UTSCOM client on supervisor.
Use the CLI to enable the debug commands:
• debug cable pnm utscom-error
• debug cable pnm utscom-debug
Use the following show command to check the state of capture on the Line Card. It lists the total number of
samples per capture context in the CLC. When the capture tests are running, the packet counts on the
corresponding Line Card would keep incrementing.
Router# show cable card 6/0 us-triggered-spectrum its-commonLAST event
UTSCOM event STATUS
client_id 1
test_id 1
port 0
dev 8
phy_chan 0
logi_chan 0
status 4
WBFFT Dev trig-mode, data-ready, packets on WBFFT dev, countdown :
wbfft dev 0: 0 0 11 0
wbfft dev 1: 0 0 0 0
total packets: 11
The dtrack utility can also be used for debugging the packets punted through CPP from CLC to container.
To use the dtrack utility, complete the following steps:
1. On the supervisor, use the following CLI:
test platform hardware qfp active feature docsis dtrack mac 0001.aaaa.cccc
test platform hardware qfp active feature docsis dtrack packe
2. Start the trigger and use the following CLI to dump the packets (this can be very verbose as there are 10
samples per file per second):
show platform hardware qfp active feature docsis dtrack statistics verbose
To obtain the dumping statistics on the IOX container, use the following CLI:
• dir harddisk:/iox/repo-lxc/lxc-data/<CAF id>/logs/
• more harddisk:/iox/repo-lxc/lxc-data/<CAF id>/logs/.stats
• more harddisk:/iox/repo-lxc/lxc-data/<CAF id>/logs/pnm.log
To change configuration on the container console, complete the following steps:

1. Log onto the CAF console as root.
676
Quick Install Guide
2. Run the echo "DEBUG" > /data/logs/.loglevel command.

debug level are: ERROR, WARNING, INFO, DEBUG, DEBUG1, DEBUG2, DEBUG3, DEBUG4
3. Run the echo "0" > /data/logs/.resend command.
value "0" disable "tftp resend" due to tftp error.

value "12" enable clc log pnm file at local.
Ensure that the PNM TFTP process is active and running on the guestshell container as listed:
cbr8# guestshell run systemctl status pnm

â pnm.service - cbr pnm telemetry delivery system
Loaded: loaded (/etc/systemd/system/pnm.service; disabled; vendor preset: disabled)
Active: active (running) since Wed 2019-01-09 15:13:40 UTC; 1min 28s ago
• If the PNM service is not active, attempt recovery by going through the following steps:
1. Destroy the guestshell instance. Run the guestshell destroy command.
2. Recreate the gusetshell by running the guestshell enable command.
3. Check if the guestshell instance is running by using the show app-hosting list command. Verify
that the PNM service is active.
• Verify that the TFTP server IP is reachable from the guestshell container and ping is successful.
guestshell run ping -c5 <tftp_server_ip>
Quick Install Guide

You can bring up the Proactive Network Management and get the captures running using a minimal
configuration. Complete the following steps to enable PNM with a minimal configuration:
1. Find the correct PNM Interface Index for the RPD. Run the show snmp mib ifmib ifindex | include
<rpd_mac> command.
Router# show snmp mib ifmib ifindex | i badb.ad13.2be0

RPD(badb.ad13.2be0)-usport0: Ifindex = 435564
Where badb.ad13.2be0 is the RPD identifier.

2. Ensure that the guestshell container is up and running on both active and standby SUP. Run the show
app-hosting list command.
Router# show app-hosting list

App id State
-----------------------------------------------------
guestshell RUNNING
3. Ensure that the pnm process is running on the guestshell. Run the guestshell run systemctl status pnm
command. For more information on the command usage, go through Step 4, on page 656.
4. Configure the Bulk Data Ttransfer parameters. Go through the following steps to set the TFTP IP address
and TFTP path. Alternatively, also go through Upstream Triggered Spectrum Capture Bulk Data Control
Objects and MIBs, on page 673 for detailed information.
677
Quick Install Guide
• snmpr commands:
1.3.6.1.4.1.4491.2.1.27.1.1.1.2.0 -o 20:01:0d:b8
1.3.6.1.4.1.4491.2.1.27.1.1.1.2.0 x 20010db8

1.3.6.1.4.1.4491.2.1.27.1.1.1.1.0

1.3.6.1.4.1.4491.2.1.27.1.1.1.2.0
• Set the BDT destination TFTP path

• snmpr commands:
1.3.6.1.4.1.4491.2.1.27.1.1.1.3.0 -o pnm
1.3.6.1.4.1.4491.2.1.27.1.1.1.3.0 s ‘pnm/test’
SSNMPv2-SMI::enterprises.4491.2.1.27.1.1.1.3.0 = STRING: "pnm/test"

1.3.6.1.4.1.4491.2.1.27.1.1.1.3.0
SNMPv2-SMI::enterprises.4491.2.1.27.1.1.1.3.0 = STRING: "pnm/test"
5. Create and configure a capture config entry. Go through the Upstream Triggered Spectrum Capture Control
Objects and MIBs, on page 669 for information on creating and configuring a capture config entry.
6. Set the minimum capture config paramters that are needed (center-frequency, span and duration).
a. Set the D_docsPnmCmtsUtscCfgStatus_createAndGo 4.
server > setany -v2c <cmts_ip> <community_name>
1.3.6.1.4.1.4491.2.1.27.1.3.10.2.1.21.<ifIndex>.1 -i 4
b. Set the docsPnmCmtsUtscCfgCenterFreq.

1.3.6.1.4.1.4491.2.1.27.1.3.10.2.1.8.<ifIndex>.1 –g 102400000
c. Set the docsPnmCmtsUtscCfgSpan.

1.3.6.1.4.1.4491.2.1.27.1.3.10.2.1.9.<ifIndex>.1 –g 204800000
678
Proactive Network Management using OFDMA RxMER Probes
d. Set the docsPnmCmtsUtscCfgFreeRunDuration. Increase the duration to a large value to keep the
freerun capture running.
1.3.6.1.4.1.4491.2.1.27.1.3.10.2.1.19.<ifIndex>.1 -g 5000
e. Ensure that the config entry status is active.

1.3.6.1.4.1.4491.2.1.27.1.3.10.2.1.21.<ifIndex>.1
Note Ensure that the capture center frequency and span are in a valid range. IOS error messages are triggered if the
user attempts to start capture tests with an invalid capture configuration. The recommended configuration
values are provided in the messages.
7. Start the PNM capture.

• snmpr commands:
1.3.6.1.4.1.4491.2.1.27.1.3.10.3.1.1.<ifIndex>.1 -i 1

1.3.6.1.4.1.4491.2.1.27.1.3.10.3.1.1.<ifIndex>.1
1.3.6.1.4.1.4491.2.1.27.1.3.10.3.1.1.<ifIndex>.1 i 1

1.3.6.1.4.1.4491.2.1.27.1.3.10.3.1.1.<ifIndex>.1
8. The captures are running and files should appear on the TFTP server under the BDT TFTP path configured.

Cisco cBR 16.12.1y supports Proactive Network Management using OFDMA RxMER Probes. This feature
enables collection and reporting of the OFDMA channel Receive Modulation Error Ratio (RxMER) for every
subcarrier.
The DOCSIS 3.1 CMTS and CM support OFDMA RxMER probes. The CM transmits signals over the
OFDMA upstream channel to the CMTS. The signals are received at the upstream PHY, and each subcarrier
in the OFDMA channel is evaluated. RxMER is defined as the ratio of the average power of the ideal QAM
constellation to the average error-vector power. The error vector is the difference between the equalized
received probe value and the known correct probe value. If some subcarriers (such as exclusion bands) cannot
be measured by the CMTS, a value of 0xFF will be returned for that subcarrier.
679
PNM RxMER probes are initiated and controlled through SNMP MIB commands. The DOCS-PNM-MIB
specification details the applicable commands under the docsPnmCmtsUsOfdmaRxMerTable. A single
RxMER probe can be started for each OFDMA channel in the system by specifying the target cable modem
mac-address. The RxMER probe results are sent to a remote TFTP server using the IOX Guestshell PNM
service
The following command options are supported for DocsPnmCmtsUsOfdmaRxMerTable:
• docsPnmCmtsUsOfdmaRxMerEntry.[ifIndex]
Each row of the DocsPnmCmtsUsOfdmaRxMerTable is uniquely identified by the OFDMA channel
ifIndex. You can identify the ifIndex of a particular OFDMA channel by running the following command:
Router# show snmp mib ifmib ifindex | i Cable1/0/2-upstream7 Cable1/0/2-upstream7:

Ifindex = 389839
• docsPnmCmtsUsOfdmaRxMerEnable
Set to TRUE to initiate collection of the RxMER data and send to TFTP server. Setting it to FALSE
restores the MIB values to defaults.
• docsPnmCmtsUsOfdmaRxMerCmMac
Specifies the mac-address of the CM that performs the RxMER probe.
• docsPnmCmtsUsOfdmaRxMerPreEq
You can either set the value to TRUE to perform RxMER probe with Pre-Equalization, or choose to set
the value to FALSE to perform RxMER probe without Pre-Equalization.
Note We recommend that probing is done with Pre-Equalization, as this will have the
CM transmit on each sub-carrier using a gain that will normalize the signal arriving
at the CMTS.
• docsPnmCmtsUsOfdmaRxMerNumAvgs
This is in the range of 1-255. Any integer greater than one will generate multiple probes and average the
result before sending it to the TFTP server.
• docsPnmCmtsUsOfdmaRxMerMeasStatus
Indicates the status of the probe request [Inactive, Busy, SampleReady, Error]. See the MIB definition
for complete details. Ensure that no modifications are made to other MIB fields for the table entry while
the probe is in Busy state.
• docsPnmCmtsUsOfdmaRxMerFileName
Displays the name of the file written to the TFTP server. You can choose to leave it blank, and an
autogenerated filename will be used. The filename is read back after the probe is complete and the status
is read as SampleReady.
680
PNM RxMER Probe High Availability
Note Do note that new file names are not autogenerated for subsequent probes. Hence,
ensure that your filename value is cleared or set to a new value before initiating
a subsequent probe. This will avoid the problem of new probe data overwriting
information on the previous probe with the same filename.
PNM RxMER Probe High Availability

• docsPnmCmtsUsOfdmaRxMerTable
• SUPHA: In progress operation will need to be restarted by the operator after the switchover. Currently
the IOX PNM service is not available after a SUP-HA event.
• LCHA: In progress operation will need to be restarted by the operator after switchover
Note When restarting the RxMER probe on the Standby Line Card, care should be
taken to identify the new ifIndex of the OFMDA channel. This will be different
from the Primary Line Card.
• LCPR: Operations that are in progress will be restarted by SUP after the LCPR completion. An
internal operation timeout will restart the RxMER probe after one minute, for a maximum of three
attempts. During this time, the RxMER status will remain as “Busy”.
RxMer Probe Debugging

You can use the following command options to display the status and count of the PNM RxMER jobs.
• To display the status of PNM RxMER jobs by ifIndex, use the test cable pnm rxmer show command.
See the following usage example:
Router# test cable pnm rxmer show
Job Client ifIndex CM-Mac Status Enable Pre-Eq Num-Avgs Retry

-------------------------------------------------------------------------------------
0 SNMP 389838 0000.0000.0000 INACTIVE N N 1 0
0 SNMP 389839 0000.0000.0000 INACTIVE N N 1 0
0 SNMP 389933 0000.0000.0000 INACTIVE N N 1 0
0 SNMP 389981 0000.0000.0000 INACTIVE N N 1 0
.
.
.
0 SNMP 404239 0000.0000.0000 INACTIVE N N 1 0
0 SNMP 404246 0000.0000.0000 INACTIVE N N 1 0
0 SNMP 404247 0000.0000.0000 INACTIVE N N 1 0
PNM RxMER job count 33
• To display the count of all the PNM RxMER jobs by ifIndex, use the test cable pnm rxmer <ifIndex>
get all command. See the following example:
681
RxMer Probe Debugging
Router# test cable pnm rxmer 389838 get all PNM RxMER MIB for ifIndex 389838
Status: INACTIVE
CM-mac: 0000.0000.0000
Enable: False
Pre-Eq: OFF
Num-Avgs: 1
TFTP filename: <default>
When upstream profile management is enabled, the show cable modem <mac> prof-mgmt upstream verbose
command can also be used to view the OFDMA RxMER probe data. The values shown should be similar to,
but not exactly the same as the values reported in the TFTP upload file. This is because data was collected
using probes at different times.
The RxMER probe data can also be collected and displayed directly on the CBR8 console using the ping
docsis pnm <ip-address> upstream <us-chan> ignored command. This command will initiate a RxMER
probe to the targeted cable modem upstream OFDMA channel. The ignore option on the command will
prevent the RxMER probe results from impacting OFDMA profile management. The RxMER probe data can
then be viewed on the console using the show cable modem <ip-address> prof-mgmt upstream ignored
command. For example:
Router# ping docsis pnm 9.23.4.91 upstream 6 ignore

Queueing 1 MAC-layer station maintenance intervals, timeout is 80 msec:
!
Success rate is 100 percent (1/1)
cbr8# show cable modem 9.23.4.91 prof-mgmt upstream ignored

Upstream Profile Management Data (Ignored):
MAC Address : 4800.33ea.6e3e
Ucid : 7
RxMer Threshold Percent: 2
Start Sc : 148
End Sc : 1067
MER Poll Period (min): 5
Upgrd Dly Cnt (cur/cfg): 0/1
Recommended IUC : 13
Current IUC : 13
Downgrade IUC : 13
DBC : 31/31/0/0/0
State : Ready
Profile Downgrade : Disabled
0x0000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
0x0020 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
0x0040 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
0x0060 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
0x0080 00000000 00000000 00000000 00000000 00000000 B3AEB0BB AEACA9B1 A8A9AEB8
0x00A0 ABADB6A7 AAB1B2AE B1B9B5A8 B4A7ABB0 A4B3ACAE AEB1BAB4 B2ADB3B4 B0B7B9B5
0x00C0 BAB3B5AA A5A3A7AB ABB2ACB1 B1B1B3AC B4ADAFAB 9DACA5AE AEB5ACB1 A6ADB4B2
0x00E0 A3B7ADBB B5ADAEB7 A8A7ABB2 9EAEBDB1 AAB1B6B7 B2AFAAB0 9BB0B1AF B7ACB5AD
682
Troubleshooting Proactive Network Management Issues
0x0100 AFB0B0AF A9B7A8AB B1AEB5B1 B59FAEB3 A4ADB1B3 AFB0AEB1 AEABADB7 ABB6B9B6

0x0120 ACB7B5AE ADABB5A7 A4AEB0AA ADB2B8AB B1ADAEB6 A4B2B3AF AEB7A9AE BA9FABAC
0x0140 9AA5B5BB B1BAB9B7 B0A0A8B3 A4A0B3B6 B1A7B1B5 B1ADA9B0 A6B2B1BB AFB9ACAF
0x0160 B4A4B4A7 A2A7B6B3 B1B9ADB7 B5A1B7AD A6ADBCA8 AEB3B4AD AEB0B0B3 ADAEB3B1
0x0180 A8AEACAF B0ADB4A4 A5ACB0AF B1B7B2B0 B2A5B8AC 9FABAFB7 B7A9AFB0 B6B3B1B3
0x01A0 B7AAB1B2 ACBBADC1 A8B3AAB2 B7B1B5B5 BEB1AEB6 ADB3B1AD ACB0B1B2 B7BBAFB8
0x01C0 AFAEACB5 ACB5B1B0 AEA8ACAE B4B5B0AC B4B9ADB5 B4ADB5B6 B2B3AAAB A8AEB4AC
0x01E0 AEAFADB5 AAAFB0B6 ADADAAB4 ABACABB6 B3A5ABB1 ADB4B7B9 AEB6BFAF B1B5B3B0
0x0200 ACAFBAB2 B4B5B3AF B2B4B1BB B5AFADB7 B5B1B3B2 B4B0B0B3 B7B0ACB5 B1B1B0B7
0x0220 AEAAACB9 B8AFACAF B7B1AFAD ADB1B3AE A9B9B0B0 B0AFB2AB ACADACB2 ACB4B2AE
0x0240 A8ABB1AF ADBBA8AC B4B1B3B4 B4AFADB8 B1AEA6AD B0AFAEAD BBB1B4B7 AEA7ADA7
0x0260 AEB2AEB5 B0AAB5B1 B3ACAFB6 B1ACB2A3 A8B7BCAA B5A9ABA9 B6B7AAA8 ACB1A9B3
0x0280 B0B1AFAA B4AEB1A9 ABACB4AF B3B4AFAC B1B0B2B1 B0B0B0B0 B5B7AEB0 B7B2B9A1
0x02A0 B1B0AFB1 AEAEB4A7 ABB4B8B0 ADB0ABAE B1A9B9AD B2B1BBAF B1B4AAAF A8ADB3A9
0x02C0 BDA9B9B0 B2ADB0B2 AEAFB3B4 B0AEAAAF AEAFB4A9 B4A9ADB0 B6A9B1AB B0AFAEAB
0x02E0 B1ADA9B2 A8A9A9AC ACACB2AF A8AAB1B4 ABB0ADAD B8ADB1B6 ADB4AEAE AEB0ABB1
0x0300 B2ADACAF ABADABB7 ACA8ACAD A9AFAAB5 A9B0B1BA B1ADB4B3 ABB0AFB0 AEB0ADB2
0x0320 AFABADB7 B0AEABA8 ABAFAFB1 A8A7ADAB B3AFAAB2 A9B1B6AE B1B0B1AE ACADB4B7
0x0340 ADB2B0AF B4B1ACA9 B7AFADB5 A9ACB1AD A6ADA6B1 AAA3A3A4 B7A5AFAA A7B2ABB4
0x0360 A8AFA7A7 A6A8ACAF ADA3B4AB A8AAB8AB A5A5ABA4 A7A8BBB1 ABA6A8A4 A79FA9A1
0x0380 AEA3AFAC B1AEABAD ACA8A7A6 B4A2A9A8 A8B2A2AB ABA2A6AE A99B9EA6 A9A59EA4
0x03A0 9FAD99A5 9FA39FA4 ABACA3A5 AA9FA9A1 9EA59AA2 9F9EAA9D A4A5A6A2 A59FA7A1
0x03C0 A09E98A0 9DA0A39F 9C9CA09F 9C999899 9695969A 9597939D 97979B9B 9C909291
0x03E0 938D9790 8B929492 998B8D95 8C85898A 8D878D87 7F7F7E83 817B847F 7E888071
0x0400 75787C76 7A707375 6C6A6D69 6C5B6565 615D5B68 55575458 554C5046 3641452B
0x0420 39402E32 16191D1A 1C223434
SC RxMER Distribution (Excluded SCs are ignored):

*: 2%
>44dB: *********************** 46.95%
44dB: ********** 21.19%
43dB: ***** 11.30%
42dB: ** 5.10%
41dB: * 2.28%
40dB: * 2.50%
39dB: 1.08%
38dB: 1.63%
37dB: 0.65%
36dB: 0.76%
35dB: 0.54%
34dB: 0.21%
33dB:
<33dB: ** 5.76%
---------------------------------------------------100
Percent of Subcarriers
Active SC RxMER Statistics (in 1/4 dB):

Active Subcarrier RxMER Mean : 0xAA
Active Subcarrier RxMER Standard Deviation : 0x52
Active Subcarrier RxMER Threshold Value : 0x5F
Active Subcarrier RxMER Threshold Frequency (Hz): 46800000

The Upstream Triggered Spectrum Capture issues, their possible causes, and resolution are listed.
• Capture configuration failure:
• Ensure that the ifindex that is used is correct and the port is configured correctly under RPD for
RPHY.
683
• Ensure that the capture configuration entry was created properly and the client/snmp owns the
capture port using MIB commands.
• Ensure that the parameters being configured are supported and within the valid range.
• Enable debug cable pnm utscom-error to check for any errors.
• Capture control or initiate test failure:

• Ensure that the capture configuration is created and configured correctly by the client using MIB
commands.
• Verify that the capture configuration entry status is active using MIB commands.
• The total number of captures is below the enforced limit.
• Ensure that no other tests are already running on the port using MIB commands.
• Ensure that only one port per RPD is running the test.
• TFTP file transfer failure:

• Ensure that the BDT TFTP information is configured correctly on the CMTS.
• Ensure that the TFTP server is reachable and the destination location is writable.
• Ensure that the container is in running state using show commands.
• Ensure that the PNM TFTP process is active and running on the guestshell container and the TFTP
server IP is reachable from the guestshell container.
• Ensure that the capture tests are running correctly and with the CLC show, CLI show, files are being
generated.
• Check dtrack to ensure that the punt path is working and packets are being sent to the container.
• Use the PNM debug and the container statistics/log file to check for any errors.
• PNM packets are not reaching guestshell:

• Check dtrack. All PNM packets should be punted with punt-cause Service-Engine.
• Run bash in guestshell, and check RX packets in ifconfig.
• Run bash in guestshell, and use tcpdump to check if the PNM packets are arriving.
• PNM packets from CLC use the Global Routing Table, and there is no mechanism to allow these
packets to use anything other than GRT. If the guestshell and VirtualPortGroup are in the VRF, you
can add a static route which directs the PNM packets into VRF. For example:
The current configuration is:
!
ip vrf vrf_pnm
rd yyy:zzz
route-target export yyy:w
route-target import yyy:w
!
interface VirtualPortGroup0
ip vrf forwarding vrf_pnm
ip address P.Q.R.253 255.255.255.252
684
Feature Information for Proactive Network Management
no mop enabled
no mop sysid
!
app-hosting appid guestshell
app-vnic gateway0 virtualportgroup 0 guest-interface 0
guest-ipaddress P.Q.R.254 netmask 255.255.255.252
app-default-gateway P.Q.R.253 guest-interface 0
!
Add a static route:

(config)# ip route P.Q.R.254 255.255.255.255 VirtualPortGroup0

The following table provides release information about the feature or features described in this module. This
table lists only the software release that introduced support for a given feature in a given software release
train. Unless noted otherwise, subsequent releases of that software release train also support that feature.
To access Cisco Feature Navigator, go to www.cisco.com/go/cfn. An account on Cisco.com is not required.
Table 115: Feature Information for Upstream Triggered Spectrum Capture - Proactive Network Management
DOCSIS 3.1 Upstream Cisco IOS XE Gibraltar This feature was integrated into Cisco IOS XE
Triggered Spectrum Capture 16.10.1 Gibraltar 16.10.1 on the Cisco cBR Series
MAX-HOLD trigger mode Cisco IOS XE Gibraltar This feature was integrated into Cisco IOS XE
16.10.1d Gibraltar 16.10.1d on the Cisco cBR Series
Support PNM output format Cisco IOS XE Gibraltar This feature was integrated into Cisco IOS XE
‘timeIQ’ and UTSC trigger 16.12.1x Gibraltar 16.12.1x on the Cisco cBR Series
mode ‘cmMac’ Converged Broadband Routers.
Proactive Network Management Cisco IOS XE Gibraltar This feature was integrated into Cisco IOS XE
using OFDMA RxMER Probes 16.12.1y Gibraltar 16.12.1y on the Cisco cBR Series
685
686
CHAPTER 44
Downstream Power Tilt
The Downstream Power tilt feature is used to correct cable loss in the head-end to produce a flat power
spectrum for all channels in the controller port.
• Information about Downstream Power Tilt, on page 689
• How to Configure the Downstream Power Tilt, on page 689
• Feature Information for Downstream Power Tilt, on page 691
687
Digital PICs:

Module:

Modules:
line card reload.
688
Information about Downstream Power Tilt
Information about Downstream Power Tilt

The downstream power tilt feature is used to correct cable loss in the head-end to produce a flat power spectrum
for all channels on the controller port.
Note There may be noise floor degradation on the failover path (following linecard switchover) with this feature
enabled.
Restrictions for Configuring Downstream Power Profile

The downstream power tilt feature and OFDM power profile feature are mutually exclusive. They cannot be
configured at the same time.
How to Configure the Downstream Power Tilt

Configuring Downstream Power Tilt
Downstream power tilt applies to all the SCQAM or OFDM channels on the downstream. To configure
downstream power tilt for a controller port, use the power-tilt configuration command under the downstream
controller port.
enable
configure terminal
controller Integrated-Cable slot/subslot/port
max-carrier value
base-channel-power value
power-tilt mode loss max-frequency freq-max
type value
rf-output value
power-adjust value
qam-profileid
docsis-channel-idid
Below is an example:
max-ofdm-spectrum 192000000
max-carrier 32
power-tilt linear 4.0 max-frequency 696000000
rf-chan 0 31
type DOCSIS
frequency 261000000
rf-output NORMAL
power-adjust -2.0
689
Verifying Downstream Power Tilt Configuration
qam-profile 1
docsis-channel-id 1
rf-chan 158
power-adjust 0
ofdm channel-profile 20 start-frequency 600000000 width 96000000 plc 645000000
In the above configuration steps, there is a command power-tilt mode loss max-frequency freq-max, where
the mode represent a formula that calculates the loss of a coax cable at a frequency F, given the loss at freq-max
is known. It provides two options to select:
• linear: lossF = lossfreq-max * (F / freq-max)
• cable-loss-approx: lossF = lossfreq-max * SQRT( (freq-max - F) / freq-max)
loss is the measured cable loss at freq-max, specified in 1/10 dB.
Verifying Downstream Power Tilt Configuration

To display the downstream power tilt details, use the show cable controller integrated-cable command as
given in the following example. This command will display the actual SCQAM and OFDM channel power
levels as set by the DS Power Tilt command. For OFDM channels, the power level displayed represents the
center frequency 6-MHz band power level.
Router# show controller Integrated-Cable 1/0/1 rf-chan 0-162
0 UP UP 261000000 DOCSIS B 256 5361 I32-J4 1 29.9 NORMAL
Chan State Admin Mod-Type Start Width PLC Profile-ID dcid power output Frequency
690
Feature Information for Downstream Power Tilt
158 UP UP OFDM 600000000 96000000 645000000 22 159 33.9 NORMAL

Table 117: Feature Information for Downstream Power Tilt
Downstream Power Cisco IOS XE Fuji This feature was introduced on Cisco IOS XE Fuji 16.7.1
Tilt 16.7.1 on the Cisco cBR Series Converged Broadband Routers.
691
692
CHAPTER 45
Controller Profile Configuration
This document describes how to configure the controller profile on the Cisco cBR Series Converged Broadband
Router.
• Information about Controller Profile Configuration, on page 695
• How to Configure the Controller Profile, on page 695
• Feature Information for Controller Profile Configuration, on page 699
693
Digital PICs:

Module:

Modules:
line card reload.
694
Information about Controller Profile Configuration
Information about Controller Profile Configuration

As density increases with the merging of CMTS and UEQAM functions in the same device, the current
controller configuration method becomes too complex and difficult. There are too many identical lines of
configuration.
To simplify the controller configuration, a new concept called controller profile is introduced. A controller
profile is a group of configuration parameters that apply to downstream and upstream controller, the benefits
include:
• Speed up deployment
• Simplify cBR-8 deployment, configuration and troubleshooting
• Common configurations across nodes/regions
• Consistency across Cisco products for common functions
How to Configure the Controller Profile

User configures I-CMTS controllers using legacy controller configuration commands by default. If user wants
to use I-CMTS controller profile, needs to enable it first with cable controller-profile I-CMTS enable
command.
Note • If user wants to configure controller using profile, it is recommended to start configuration on a “clean”
CMTS without any legacy command configured in Integrated-Cable and Upstream-Cable controllers.
Do not switch over between legacy configuration and profile.
• When modifying controller profile, all related controllers will be changed. So if user wants to configure
a specific controller, for example, modify the base-channel power of a controller, user should not bind
this controller to a profile together with other controllers.
• Legacy controller configuration commands are not supported if I-CMTS controller-profile is enabled.
• Legacy controller configuration cannot be shown in running-config if I-CMTS controller-profile is
enabled.
Configuring Downstream Controller Profile

To configure downstream controller profile, use the steps below:
enable
configure terminal
cable downstream controller-profile id [RPHY|I-CMTS]
base-channel-power value
max-carrier value
freq-profile id
695
Verifying Downstream Controller Profile Configuration
ofdm-freq-excl-band start-frequency value widthvalue

type value
rf-output value
power-adjust value
qam-profileid
docsis-channel-idid
power-profile id
enable
configure terminal
controller integrated-cable slot/subslot/port
profile id
Below is an example:
cable downstream controller-profile 0 I-CMTS
max-carrier 32
rf-chan 0 3
type DOCSIS
frequency 111000000
rf-output NORMAL
qam-profile 1
docsis-channel-id 1
controller integrated-cable 2/0/0

profile 0
Note • When configure a new I-CMTS controller profile, keyword I-CMTS is needed. If input RPHY or do not
input any keyword, the system will consider it as a RPHY controller profile. Once a profile type
(RPHY/I-CMTS) is set, it cannot be modified.
• Updating a profile will affect all the controllers bond with it. To delete a profile that bond with controller,
user must unbind all the controllers first. All rf-channel configuration in controller will be deleted after
unbind.
• At least 8 QAM channels should be configured to get the right power. Single continuous wave (CW)
mode is not supported.
Verifying Downstream Controller Profile Configuration

Use the show cable downstream controller-profile command to verify the configuration of the downstream
controller profile.
Router# show cable downstream controller-profile 0
Downstream controller-profile 0, type I-CMTS
Description:
Downstream controller-profile 0 is being used by controller Integrated-Cable:
2/0/0,
Admin: UP
MaxOfdmSpectrum: 192000000
MaxCarrier: 128
696
Configuring Upstream Controller Profile
BasePower: 33.0 dBmV

Mode: normal
Frequency profile: unconfigured
DS Splitting: No
OFDM frequency exclusion bands: None
Configured RF Channels:
Chan Admin Frequency Type Annex Mod srate Qam-profile dcid power output
0 UP 213000000 DOCSIS B 256 5361 1 1 33.0 NORMAL
In the above output, integrated-cable 2/0/0 is bond to profile 0. So the output of the show controllers
integrated-Cable 2/0/0 rf-channel 0 5 should match the above output. See the example below:
Router# show controllers integrated-cable 2/0/0 rf-channel 0-5
...
Chan Admin Frequency Type Annex Mod srate Qam-profile dcid power output
To check if the parameters in a profile match with the ones configured, use the show running-config [all] |
section cable downstream controller-profile command as shown in the example below:
Router# show running-config | section downstream controller-profile
cable downstream controller-profile 0 I-CMTS
max-carrier 32
rf-chan 0 3
type DOCSIS
frequency 111000000
rf-output NORMAL
qam-profile 1
docsis-channel-id 1
Configuring Upstream Controller Profile

To configure upstream controller profile, use the steps below:
enable
configure terminal
cable upstream controller-profile id [RPHY|I-CMTS]
us-channel id {chan-class-id id|channel-width {first-choice-width
[last-choice-width]}|docsis-mode{atdma| tdma|
tdma-atdma}|equalization-coefficient|frequencyvalue|hop-priority{frequency
modulation channel-width| modulation frequency channel-width| frequency
channel-width modulation}|ingress-nosie-cancellation
interval|maintain-psd|max-logical-chans id|minislot-size
value|modulation-profile
primary-profile-number[secondary-profile-number][tertiary-profile-number]|power-level
value|rng-holdoff priority|specsvl error-adaptive-profile id|spectrum-group
697
Verifying Upstream Controller Profile Configuration
id|threshold {cnr-profiles value [value]|corr-fec value|hysteresis

value|snr-profiles value [value]|corr-fec value}
enable
configure terminal
controller upstream-cable slot/subslot/port
profile id
Note • When configure a new I-CMTS controller profile, keyword I-CMTS is needed. If input RPHY or do not
input any keyword, the system will consider it as a RPHY controller profile. Once a profile type
(RPHY/I-CMTS) is set, it cannot be modified.
• Updating a profile will affect all the controllers bond with it. To delete a profile that bond with controller,
user must unbind all the controllers first.
• OFDMA does not support the use of profile in this release.
Verifying Upstream Controller Profile Configuration

Use the show cable upstream controller-profile command to verify the configuration of the upstream
controller profile.
Router# show cable upstream controller-profile 0
Upstream controller-profile 0, type I-CMTS
Description:
Upstream controller-profile 0 is being used by controller Upstream-Cable:
9/0/0
Controller Upstream-Cable
...
Upstream-channel 0
chan-class-id : 0x0
channel-width : 1600000 1600000
docsis-mode : atdma
equalization-coefficient : TRUE
frequency : 5000000
...
modulation-profile : 221
...
shutdown : FALSE
...
In the above output, upstream-cable 9/0/0 is bond to profile 0. So the output of the show controllers
upstream-Cable 9/0/0 us-channel 0 should match the above output. See the example below:
...
atdma mode enabled
Frequency 5.000 MHz, Channel Width 1.600 MHz, Symbol Rate 1.280 Msps
Modulation Profile Group 221
To check if the parameters in a profile match with the ones configured, use the show running-config [all] |
section cable upstream controller-profile command as shown in the example below:
698
Feature Information for Controller Profile Configuration
Router# show running-config | s cable upstream controller-profile 0

cable upstream controller-profile 0 I-CMTS
...

Table 119: Feature Information for Controller Profile Configuration
SG Based Config (OpSimp) Cisco IOS XE Fuji This feature was introduced on Cisco IOS XE Fuji
Phase 2 16.7.1 16.7.1 on the Cisco cBR Series Converged
Broadband Routers.
699
700
CHAPTER 46
Voltage Thresholds for AC Power Supply Module
Mode Control
This document describes how to configure the voltage thresholds for switching modes in AC Power
SupplyModule (PSM).
• Information about Voltage Thresholds for AC PSM Mode Control, on page 703
• How to Configure Voltage Thresholds for AC PSM Mode Control, on page 703
• Feature Information for Voltage Thresholds for AC PSM Mode Control, on page 704
701
Digital PICs:

Module:

Modules:
line card reload.
702
Information about Voltage Thresholds for AC PSM Mode Control
Information about Voltage Thresholds for AC PSM Mode Control

Configuring voltage thresholds help switch between different modes when power budget provided by AC
PSMs is not sufficient to power Field Replaceable Units (FRUs).
Overview of Voltage Thresholds for AC PSM Mode Control

The AC PSM can operate in either 120V or 220V mode.
When the input voltage is between 70V and 197V, the PSM operates in the 120V mode with 1300W power
capacity. When input voltage drops below 85V, the PSM powers down completely and its power capacity
becomes 0W.
When the input voltage is greater than 197V, the PSM operates in the 220V mode with 3000W power capacity.
When input voltage drops below 190V, the PSM switches to the 120V mode and its power capacity decreases
to 1300W.
To allow users configure mode switching, two new hystersis thresholds Voff_3000W and Von_3000W have
been provided. The hystersis thresholds define when the PSM should switch modes and can be configured
using CLI commands.
For example, if Voff_3000W is configured as 180V, the PSM switches to the 120V mode with 1300W capacity
when input voltage drops below 180V. If Von_3000W is configured as 200V, the PSM switches to the 220V
mode when input voltage increases to more than 200V.
Table 121: Voltage Thresholds for Mode Control
Threshold Default Value Configurable Range
Voff_3000W 190V The value of Voff_3000W can be 170V or greater.
Von_3000W 197V The value of Von_3000W can be 200V or lesser.

The value of Voff_3000W must be less than the
value of Von_3000W.
How to Configure Voltage Thresholds for AC PSM Mode Control

Configuring Voltage Thresholds for AC PSM Mode Control
To configure voltage thresholds, run the platform power protection ac220v voff von command as shown
below:
platform power protection ac220v voff von
To use the default voltage thresholds, run the no platform power protection ac220v command as shown
below:
no platform power protection ac220v
703
Verifying Voltage Thresholds for AC PSM Mode Control
Note By default, power protection action is disabled to avoid service outage. If protection action is disabled, any
online FRU is not powered down in the event of insufficient power budget, but any newly installed line card
is not powered up.
To enable the power protection action, run the platform power protection action shutdown linecard
command:
platform power protection action shutdown linecard
Verifying Voltage Thresholds for AC PSM Mode Control

To verify the voltage thresholds configuration, use the sh run command as shown in the example below:
Router (config)# sh run | i protection
platform power protection ac220v 180 200
This section provides configuration examples for the voltage threshold feature.
Example: Configuring Voltage Thresholds for AC PSM Mode Control

The following example shows how to configure voltage thresholds:
platform power protection ac220v 180 200
The following example shows how to disable DPS:

no platform power protection ac220v
Feature Information for Voltage Thresholds for AC PSM Mode

Control
704
Feature Information for Voltage Thresholds for AC PSM Mode Control
Table 122: Feature Information for Voltage Thresholds for AC PSM Mode Control
Voltage Thresholds for AC PSM Cisco IOS XE Fuji This feature was introduced in Cisco IOS XE
Mode Control 16.7.1 Fuji 16.7.1 on the Cisco cBR Series Converged
Broadband Routers.
705
Feature Information for Voltage Thresholds for AC PSM Mode Control
706
CHAPTER 47
DOCSIS3.1 Downstream Zero Bit Loading
This document describes how to configure DOCSIS3.1 Downstream Zero Bit Loading on the Cisco cBR
• Information about DOCSIS3.1 Downstream Zero Bit Loading, on page 709
• How to Configure DOCSIS3.1 Downstream Zero Bit Loading, on page 709
• Feature Information for DOCSIS3.1 Downstream Zero Bit Loading, on page 711
707
Digital PICs:

Module:

Modules:
line card reload.
708
Information about DOCSIS3.1 Downstream Zero Bit Loading
Information about DOCSIS3.1 Downstream Zero Bit Loading

Zero Bit Loading (ZBL) is a subcarrier in an OFDM channel, it has power but does not carry any user data.
ZBL can be used if the user wants to bypass one or more subcarrier because, for example, cable modem reports
that Modulation Error Ratio (MER) is too low on these subcarriers.
Unlike the excluded subcarrier which is defined per RF port and applied to all modulation profiles used on
that port’s OFDM channels, ZBL is defined per profile and applied to individual OFDM channel.
ZBL is modulated using PRBS (Pseudo Randomness Binary Sequence), it can not be used for other purpose.
Excluded subcarrier is not modulated, and does not have power, so it can be used for other purposes, such as
video.
For more information about the OFDM, see DOCSIS 3.1 OFDM Channel Configuration, on page 551.
How to Configure DOCSIS3.1 Downstream Zero Bit Loading

Configuring Downstream Zero Bit Loading
To configure downstream ZBL, follow these steps:
1. Configure ZBL for the data/control profile and the NCP profile.
2. Apply the modulation profiles to a channel profile.
3. Apply the channel profile to an OFDM channel.
Run the following commands as an example to configure ZBL:

Router(config)# cable downstream ofdm-modulation-profile 159
Router(config-ofdm-mod-prof)# description an example of ZBL starting at 10MHZ for 1MHZ
Router(config-ofdm-mod-prof)# subcarrier-spacing 50KHZ
Router(config-ofdm-mod-prof)# width 96000000
Router(config-ofdm-mod-prof)# assign modulation-default 1024-QAM
Router(config-ofdm-mod-prof)# assign modulation zero-bit-load range-subcarriers freq-offset
10000000 width 1000000

Router(config)# cable downstream ofdm-modulation-profile 160
Router(config-ofdm-mod-prof)# description an example for ZBL on NCP profile for one SC
starting 14MHZ
Router(config-ofdm-mod-prof)# subcarrier-spacing 50KHZ
Router(config-ofdm-mod-prof)# width 96000000
Router(config-ofdm-mod-prof)# assign modulation-default 16-QAM
Router(config-ofdm-mod-prof)# assign modulation zero-bit-load list-subcarriers freq-offset
14000000

Router(config)# cable downstream ofdm-chan-profile 159
Router(config-ofdm-chan-prof)# cyclic-prefix 1024
Router(config-ofdm-chan-prof)# interleaver-depth 16
Router(config-ofdm-chan-prof)# pilot-scaling 48
709
Verifying Downstream Zero Bit Loading
Router(config-ofdm-chan-prof)# roll-off 128

Router(config-ofdm-chan-prof)# subcarrier-spacing 50KHZ
Router(config-ofdm-chan-prof)# profile-control modulation-profile 159
Router(config-ofdm-chan-prof)# profile-ncp modulation-profile 160

Router(config)# controller Integrated-Cable 1/0/0
Router(config-controller)# max-ofdm-spectrum 192000000
Router(config-controller)# max-carrier 32
Router(config-controller)# base-channel-power 37
Router(config-controller)# rf-chan 0 3
Router(config-rf-chan)# type DOCSIS
Router(config-rf-chan)# frequency 261000000
Router(config-rf-chan)# rf-output NORMAL
Router(config-rf-chan)# power-adjust 0.0
Router(config-rf-chan)# qam-profile 1
Router(config-rf-chan)# docsis-channel-id 1
Router(config-rf-chan)# exit
Router(config-controller)# rf-chan 158
Router(config-rf-chan)# power-adjust 0.0
Router(config-rf-chan)# docsis-channel-id 159
Router(config-rf-chan)# ofdm channel-profile 159 start-frequency 627000000 width 96000000
plc 648000000
Verifying Downstream Zero Bit Loading

To check if the ZBL is taking effect, use show controllers verbose command as shown in the example below:
router# show controllers integrated-Cable 1/0/0 rf-channel 158 verbose | in ZBL
1024 :634350000[1235] - 636950000[1287] ZBL :637000000[1288] - 637850000[1305]
ZBL :637950000[1307] - 637950000[1307] 1024 :638000000[1308] - 641450000[1377]
ZBL :641000000[1368] - 641000000[1368] 16 :641050000[1369] - 641450000[1377]
User can also check DPD messages as shown in the example below:
router# show cable mac-domain c1/0/0 dpd integrated-Cable 1/0/0 158
DPD Message
MAC Header
Frame Control : 0xC2 (MAC specific, MAC msg, EHDR Off)
MAC Parameters : 0x0
Length : 41
Header Check Sequence : 0xB242 (45634)
MAC Management Header
Destination MAC ADDR : 01e0.2f00.0001
Source MAC ADDR : d42c.447c.2ce9
Length : 23
Destination SAP : 0
Source SAP : 0
Control : 3
Version : 5
Type : 50
Multipart : 0 (Sequence number 0, Fragments 0)
DPD fields
DCID : 159
Profile ID : 0
CCC : 4
TLV 5 Subcarrier Range/List : Range (continuous)
Modulation : 1024 (default value)
: 0000 - 4095
710
Feature Information for DOCSIS3.1 Downstream Zero Bit Loading
Modulation : Zero
: 1288 - 1307
DPD Message
MAC Header
Frame Control : 0xC2 (MAC specific, MAC msg, EHDR Off)
MAC Parameters : 0x0
Length : 39
Header Check Sequence : 0xCCAB (52395)
MAC Management Header
Destination MAC ADDR : 01e0.2f00.0001
Source MAC ADDR : d42c.447c.2ce9
Length : 21
Destination SAP : 0
Source SAP : 0
Control : 3
Version : 5
Type : 50
Multipart : 0 (Sequence number 0, Fragments 0)
DPD fields
DCID : 159
Profile ID : 255
CCC : 4
Modulation : 16 (default value)
: 0000 - 4095
TLV 5 Subcarrier Range/List : List
Modulation : Zero
: 1368

Table 124: Feature Information for DOCSIS3.1 Downstream Zero Bit Loading
DOCSIS3.1 Downstream Zero Bit Cisco IOS XE Fuji This feature was introduced into the Cisco cBR
Loading 16.8.1 Series Converged Broadband Routers.
711
712
CHAPTER 48
Reducing Power Consumption
This document describes how to reduce power consumption on the Cisco cBR Series Converged Broadband
Router.
• Information About Reducing Power Consumption, on page 715
• Configure Reduction of Power Consumption, on page 715
• Feature Information for Reducing Power Consumption , on page 716

713
Digital PICs:

Module:

Modules:
line card reload.
714
Information About Reducing Power Consumption
Information About Reducing Power Consumption

A Cisco cBR-8 CCAP line card has two downstream PHY modules. The first downstream PHY module has
port number 0 through port number 3. The second downstream PHY module has port number 4 through port
number 7. Each downstream PHY module consumes approximately 70W of power even if no RF channels
are used. By default, both downstream PHY modules are powered up.
To reduce power consumption in the Cisco cBR-8, you can power down the second downstream PHY module.
The power-saving configuration is retained for supervisor card reload, supervisor high availability, LCHA,
and LCPR configurations.
Restrictions for Setting Up Power-Saving Configuration

The following restrictions are applicable for setting up power-saving configuration:
• Before powering down the second downstream PHY module, you must shut down the downstream
controllers.
• You cannot power down the downstream PHY module on a redundant line card.
• The redundant line card must be in the hot standby mode.
Configure Reduction of Power Consumption

Before powering down the second downstream PHY module, you must shut down the downstream controllers.
To shut down downstream controllers 4 to 7, run the following commands:
Router# enable
Router(config)# controller integrated-Cable slot/subslot/port
Router (config-controller)# shutdown
The following example shows how to shut down downstream controllers 4 to 7.
Router# enable
Router(config)# controller integrated-Cable 1/0/4
Router (config-controller)# shutdown
To power down the second downstream PHY module, run the following commands:
Router# enable
Router(config)# cable downstream power-down-2nd-module slot
The following example shows how to power down the PHY module in slot 1.
Router# enable
Router(config)# cable downstream power-down-2nd-module slot 1
715
Verifying the Power-Saving Configuration
Verifying the Power-Saving Configuration

After powering down the second downstream PHY module, the power consumption in downstream controllers
4 to 7 changes to 0.
To check power consumption in downstream controllers 4 to 7, run the following command:
Router# show cable card 1/0 ds-phy display | include Watts
Port0-3 Power Consumption 82781 (mWatts), Port4-7 Power Consumption 53443 (mWatts)
To check power consumption in downstream controllers 4 to 7 after powering down the downstream PHY
module, run the following command.
Router#show cable card 1/0 ds-phy display | include Watts
Port0-3 Power Consumption 82781 (mWatts), Port4-7 Power Consumption 0 (mWatts)
The second downstream PHY module information shows Powered down to save energy when the show cable
card slot/sub-slot ds-phy display | include detected command is run.
Feature Information for Reducing Power Consumption

Table 126: Feature Information for Reducing Power Consumption
Reducing Power Cisco IOS XE Fuji This feature was introduced in Cisco IOS XE Fuji
Consumption 16.9.1a 16.9.1 on the Cisco cBR Series Converged
Broadband Routers.
716
PA R T V
Layer 2 and Layer 3 VPN Configuration
• L2VPN Support over Cable, on page 719
• L2VPN Over Port-Channel, on page 737
• MPLS Pseudowire for Cable L2VPN, on page 741
• MPLS VPN Cable Enhancements, on page 773
• Multicast VPN and DOCSIS 3.0 Multicast QoS Support, on page 791
• EtherChannel for the Cisco CMTS, on page 803
• Flow-Based per Port-Channel Load Balancing, on page 813
• MPLS QoS via TLV for non-L2VPN Service Flow, on page 823
• IPsec Security Support, on page 831
CHAPTER 49
L2VPN Support over Cable
The Layer 2 VPN (L2VPN) Support over Cable feature on the Cisco CMTS provides point-to-point Transparent
LAN Service (TLS) in support of the Business Services over DOCSIS (BSOD) Cable Labs specification.
The L2VPN Support over Cable feature supports the following:
• The feature uses an Ethernet trunking interface to transport traffic for multiple L2VPNtunnels in support
of different cable modems (CMs) and service flows (SFs) based on IEEE 802.1qVLAN IDs. For the
legacy TLS service, only the primary upstream or downstream SFs are used. With the new L2VPNSupport
over Cable feature, both primary and secondary SFs can be used.
• The TLS feature uses CLI to provision the service. The L2VPN Support over Cable feature uses the CM
configuration file to provision the service, and a single CLI to identify the default Ethernet Network
System Interface (NSI).
• Downstream traffic is forwarded on a per-CM basis and upstream traffic is forwarded on a per-SF basis.
For L2VPN Support over Cable feature, upstream traffic for the same L2VPN can use multiple upstream
service flows and downstream traffic can use different downstream service flows.

• Prerequisites for L2VPN Support over Cable, on page 721
• Restrictions for L2VPN Support over Cable, on page 721
• Information About L2VPN Support over Cable, on page 722
• Voice-Call Support on L2VPN CM, on page 726
• How to Configure L2VPN Support over Cable, on page 726
• Configuration Examples for L2VPN over Cable, on page 731
• Feature Information for L2VPN Support over Cable, on page 735

719
Digital PICs:

Module:

Modules:
720
Prerequisites for L2VPN Support over Cable
line card reload.
Prerequisites for L2VPN Support over Cable

• You should use crypto-supported images.
• Cable modems must be configured to support BPI+.
Restrictions for L2VPN Support over Cable

The L2VPN Support over Cable feature has the following general restrictions:
• DOCSIS 1.0 CMs are not supported.
• Load balancing and Dynamic Channel Change (DCC) are not supported for CMs that are enabled for
L2VPN support.
• DSx messages (Dynamic Service Add [DSA], Dynamic Service Change [DSC], and Dynamic Service
Delete [DSD]) are supported for L2VPN-provisioned CMs. However, DSx with L2VPN type, length,
values (TLVs) are not supported.
• Multipoint L2VPN is not supported, and any Simple Network Management Protocol (SNMP) MIBs for
multipoint L2VPN are not supported.
• eSAFE (embedded Service/Application Functional Entities) DHCP snooping is not supported (L2VPN
subtype 43.5.3)
• Maximum of 1024 L2VPNs are supported on a single MAC domain.
• Maximum of eight upstream SFs are supported per L2VPN service.
• Maximum of eight downstream classifiers are supported per L2VPN service.
• eSAFE exclusion is supported for only one eSAFE host. If the REG-REQ message for a compliant CM
specifies multiple eSAFE hosts, then the eMTA (ifIndex 16) is selected as the eSAFE host to be excluded
by the Cisco CMTS router. If the eMTA is not included as part of the capability of the CM, then the first
eSAFE host in the capability is selected for exclusion.
• Maximum length of the Cable Modem Interface Mask (CMIM) is 4 bytes.
• Areas of the Business Services over DOCSIS (BSOD) Layer 2 Virtual Private Networks specification
that are not supported are:
• Vendor-specific L2VPN encodings for the replacement of the required VPN ID and NSI
Encapsulation subtype are not supported.
• Mapping of egress user priority to an NSI port transmission traffic class as specified by IEEE 802.1s
is not supported.
• Forwarding with non-zero default user priority values with vendor-specific configuration is not
supported.
721
VPN ID Restrictions
• Accepting multiple Downstream Classifier L2VPN Encoding with the same VPN ID to clasify
packets to different service flows is not supported.
• Assigning multiple SAIDs to the same L2VPN on the same CM is not supported. The primary SAID
is used for encrypting all downstream traffic.
• Assigning of the same group-level L2VPN SAID to different CMs on the same MAC domain
attached to the same L2VPN identifier is not supported.
• Implementing the DOCSIS Spanning Tree Protocol (DSTP) and transmission of DSTP BPDUs on
all NSI and RF interfaces configured for L2VPN operation is not supported.
• Implementing a DSTP SAID specifically for DSTP forwarding to the customer premises equipment
(CPE) ports of all L2VPN CMs is not supported.
• dot1q L2VPN is not supported over a port-channel with load-balancing vlan configured.
VPN ID Restrictions
• A maximum of four VPN IDs are supported for each CM.
• A maximum of one VPN ID can be associated with each SF in a CM; although multiple SFs in a CM
can belong to the same L2VPN.
• A maximum of 4093 unique VPN IDs are supported per Cisco CMTS router.
• The maximum length of a VPN ID is 16 bytes.
• All L2VPN encodings must contain a VPN ID, except for upstream classifier encodings.
Information About L2VPN Support over Cable

L2VPN Support Over Cable provides the following benefits and functions on a Cisco CMTS router:
• Supports point-to-point L2VPN forwarding mode.
• Supports up to four VPN IDs per CM.
• Supports multiple upstream SFs per CM, with one or more SFs belonging to the same VPN ID.
• Supports a single Ethernet NSI that serves as a trunking port for one or more L2VPN tunnels on the
Cisco CMTS router.
• Supports BPI+ encryption using primary SAID of the CM.
• Supports L2VPN encodings in the CM configuration file and CM registration (REG-REQ with L2VPN
encoding).
• Supports upstream L2VPN tunnel in support of per-CM and per-SF forwarding.
• Supports synchronization and recovery of the L2VPN database and upstream and downstream SFs during
SUP NSF/SSO and N+1 line card redundancy switchovers.
• Supports QoS in upstream and downstream.
• Supports stacked IEEE 802.1q tags.
• Supports exclusion of traffic from the L2VPN tunnel for a single Embedded Service/Application Functional
Entity (eSAFE) host.
• Supports Layer 2 classifier via CMIM and IEEE 802.1p priority bits.
• Supports detection of provisioning errors, such as duplicate VLAN IDs across CMs or existing VLAN
IDs in use, and moves a CM offline with a corresponding error message.
• Supports coexistence of L2VPN and non-L2VPN traffic on the same RF MAC domain, with non-L2VPN
traffic isolated from other tunnel traffic.
• Supports voice calls from L2VPN-provisioned CMs. However, voice calls are not part of the L2VPN.
722
Point-to-Point L2VPN Forwarding Mode
• Supports BSOD VLAN Redundancy feature, which allows users to configure a backup WAN interface
in addition to the primary WAN interface. When the primary WAN interface is down, the L2VPN traffic
flows through the backup WAN interface.
• Supports manual switchover for VLAN Redundancy feature, which allows users to manually switch
active uplink port from the current port to another port when both the uplink ports are up.
• Supports 2000 bytes layer 2 MTU.
Point-to-Point L2VPN Forwarding Mode

The Cisco CMTS routers supports the point-to-point L2VPN forwarding mode described in the BSOD
specification. Each attachment circuit (either SF or CM) on the Cisco CMTS router has a NSI encapsulation
value, and is configured with an IEEE 802.1q VLAN ID.
The L2VPN forwarder on the Cisco CMTS router forwards both upstream and downstream traffic between
the NSI port on the router and an attachment circuit without using MAC address learning for the forwarding
decision. A L2VPN bridge on the backbone network of the cable operator performs the MAC-address learning
to bridge packets between VLAN IDs.
The image below shows an example of a point-to-point L2VPN network using IEEE 802.1q NSI encapsulation.
In this example, four CMs are associated with four different VLAN IDs: 10, 20, 30, and 40. The L2VPN
encoding of the CM includes the logical L2VPN ID (in this case, A or B) with an NSI encapsulation subtype
for IEEE 802.1q with the associated VLAN ID.
723
L2VPN Encodings in the CM Configuration File
Figure 23: Point-to-Point L2VPN Network Diagram
The logical L2VPN IDs allow creation of separate broadcast domains for certain VLAN IDs. In the diagram,
traffic for VLANs 10 and 20 from CM1 and CM2 can be sent to the network of Enterprise A, and traffic for
VLAN’s 30 and 40 from CM3 and CM4 can be sent to the network of Enterprise B.
L2VPN Encodings in the CM Configuration File

The CM configuration file contains a set of L2VPN encodings that control how the Cisco CMTS processes
L2VPN forwarding of upstream and downstream CPE packets. As per the BSOD specification, the L2VPN
encoding is encapsulated using a General Extension Information (GEI) encoding, which uses the type code
43 and subtype of 5 (43.5) with the reserved Vendor ID of 0xFFFFFF.
L2VPN defines the following types of encodings:
• Per-CM L2VPN encodings—An encoding that appears at the top level of the CM configuration file.
724
Supported L2VPN Encodings
• Per-SF L2VPN Encoding—An encoding that appears as a subtype of the Upstream Service Flow Encoding
(type 24).
• Upstream Classifier L2VPN Encoding—An encoding that appears in an Upstream Packet Classification
Configuration Setting (type 22).
• Downstream Classifier L2VPN Encoding—An encoding that appears in a Downstream Packet
Classification Configuration Setting (type 23).
The simplest CM configuration file has a single per-SF L2VPN Encoding within the primary upstream SF
definition and a single per-CM L2VPN Encoding with a NSI Encapsulation subtype for that L2VPN.
Note When BSOD (CM configuration file) is used for L2VPN configuration, and QoS policy-map settings are
applied to Cisco CMTS WAN interfaces, the packets do not match the QoS policy-map. When CLI mode is
used for L2VPN configuration, and QoS policy-map settings are applied to Cisco CMTS WAN interfaces,
the packets will match the QoS policy-map first.
Note Cisco CMTS supports BSOD VLAN redundancy feature with support for two Ethernet Network Side Interface
(NSI) configuration and a backup WAN interface. When the active NSI WAN interface is down, the L2VPN
traffic flows through the backup WAN interface.
Supported L2VPN Encodings

This section describes the supported L2VPN encodings in the CM configuration file that are supported by the
Cisco CMTS routers.
• The Cisco CMTS routers support the following CM capabilities:
• L2VPN capability (5.17)
• eSAFE host capability (5.18)
• Downstream Unencrypted Traffic (DUT) filtering (5.19)
• The Cisco CMTS routers support the following top-level encodings:

• VPN identifier (43.5.1)
• CMIM (43.5.4)—When provided, applies to all upstream SFs associated with an L2VPN tunnel;
Supports only one eSAFE host.
• NSI encapsulation (43.5.2) with format code 2 for IEEE 802.1q (43.5.2.2)
• DUT filtering encoding
• The Cisco CMTS routers support the following per-SF encodings:

• Ingress user priority (43.5.8)
725
Voice-Call Support on L2VPN CM
• The Cisco CMTS routers support the following downstream classifier encodings:
• CMIM (43.5.4) and (22/23.13)
• User priority range (43.5.9)
For more information about the CM configuration file and L2VPN encodings, see the "Business Services
over DOCSIS (BSOD) Layer 2 Virtual Private Networks" specification.
For information about how to use the configuration file generator on the Cisco CMTS, see the “DOCSIS
Internal Configuration File Generator for the Cisco CMTS” document.
Voice-Call Support on L2VPN CM

Voice calls are supported on L2VPN CMs. This feature enables the Cisco CMTS routers to support dynamic
service flows on L2VPN-provisioned cable modems to permit voice calls from a non-L2VPN CPE.
To provide voice-call support on a L2VPN CM, you have to configure correct classifiers and create two static
service flows (primary and secondary) using the cable modem configuration file. If the eMTA is L2VPN-capable
with the embedded CPE configured as an eSAFE host, then only one service flow is required. When correct
CMIM bits are configured, the Cisco CMTS does not send packets from the eSAFE host to the L2VPN.
Though the L2VPN can be configured on the primary or secondary service flow, it cannot coexist with eMTAs
on the same service flow. The eMTAs should always use a different service flow from that of L2VPN. The
classifiers to direct the traffic should also be based on the service flows the L2VPN and eMTAs are using.
When the above configuration is in place, the dynamic service flows are created automatically whenever voice
calls are initiated.
How to Configure L2VPN Support over Cable

This section contains the following procedures:
Configuring the Ethernet Network System Interface

To configure the L2VPN Support over Cable feature, you need to specify an Ethernet NSI to operate as the
trunking interface for the L2VPN traffic. You must configure the NSI using a command on the Cisco CMTS
router. It is not configurable through the CM configuration file.
Before you begin

The following interface types can be configured as an NSI for L2VPN Support over Cable:
• Cisco cBR Series Converged Broadband Router—GigabitEthernet and TenGigabitEthernet
Note The Cisco CMTS routers only support the configuration of a single L2VPN NSI per CMTS.
>
726
Preparing the DOCSIS Configuration File for L2VPN Support
Procedure

Router> enable

Example:
Step 3 cable l2-vpn-service xconnect nsi dot1q Configures WAN interface for DOT1Q L2VPN .
interfaceethernet-intf[backup-interface ethernet-intf]
(Optional) Backup-interface - If backup-interface is
Example: configured it means that BSoD VLAN redundancy feature
is enabled.
Router(config)# cable l2-vpn-service xconnect nsi
dot1q interface Te4/1/0 backup-interface Te4/1/4
Preparing the DOCSIS Configuration File for L2VPN Support

To support L2VPN, the DOCSIS configuration file must be configured with the appropriate encodings. For
information about the supported encodings by the Cisco CMTS routers, see the L2VPN Encodings in the CM
Configuration File, on page 724.
Manual Switchover Command Line Interface

For BSoD VLAN Redundancy feature, users can manually switch active uplink ports from the active port to
another port when both the uplink ports are up through the command line interface. To manually switchover,
perform the following steps:
SUMMARY STEPS
1. enable
2. cable l2-vpn dot1q-nsi-redundancy force-switchover from active-nsi-interface
DETAILED STEPS

Example: • Enter your password if prompted
Router> enable
727
Verifying L2VPN Support over Cable

Step 2 cable l2-vpn dot1q-nsi-redundancy force-switchover Switches the active uplink port from the current active port
from active-nsi-interface to the specified port.
Example:
Router# cable l2-vpn dot1q-nsi-redundancy
force-switchover from Te4/0/1
To display the dot1q L2VPN uplink redundancy information, use the show cable l2-vpn
dot1q-nsi-redundancy as shown in the following example:
Router# show cable l2-vpn dot1q-nsi-redundancy
Primary-NSI Backup-NSI Active-NSI Elapsed-after-SW
Te4/1/0 Te4/0/4 Te4/1/0 31m9s
Te4/1/2 Te4/0/5 Te4/1/2 59s

To verify L2VPN information on the Cisco CMTS router, use the show cable l2-vpn xconnect dot1q-vc-map
command.
SUMMARY STEPS
1. To display VLAN information for all cable modems, use the show cable l2-vpn xconnect dot1q-vc-map
command as shown in the following example:
2. To display VLAN information for a particular L2VPN ID or customer, use the show cable l2-vpn xconnect
dot1q-vc-map customer form of the command as shown in the following example:
3. To display information for a particular L2VPN ID on a specific cable modem, use the show cable l2-vpn
xconnect dot1q-vc-map vpn form of the command along with specification of the cable modem MAC
address, as shown in the following example:
4. To display detailed information for a particular L2VPN ID on a specific cable modem, use the show cable
l2-vpn xconnect dot1q-vc-map vpn verbose form of the command along with specification of the cable
modem MAC address, as shown in the following example:
5. To display detailed information and the current redundancy information for a particular cable modem,
use the the show cable l2-vpn xconnect dot1q-vc-map verbose form of the command along with
specification of the cable modem MAC address, as shown in the following example:
6. To display the dot1q L2VPN uplink redundancy information, use the show cable l2-vpn
dot1q-nsi-redundancy as shown in the following example:
DETAILED STEPS
Step 1 To display VLAN information for all cable modems, use the show cable l2-vpn xconnect dot1q-vc-map command as
Example:
Router# show cable l2-vpn xconnect dot1q-vc-map

MAC Address Ethernet Interface VLAN ID Cable Intf SID Customer Name/VPN ID
0014.f8c1.fd66 GigabitEthernet4/0/0 68 Cable6/0/0 3 0234560001
728
Step 2 To display VLAN information for a particular L2VPN ID or customer, use the show cable l2-vpn xconnect dot1q-vc-map
customer form of the command as shown in the following example:
Example:
Router# show cable l2-vpn xconnect dot1q-vc-map customer 0234560001
Step 3 To display information for a particular L2VPN ID on a specific cable modem, use the show cable l2-vpn xconnect
dot1q-vc-map vpn form of the command along with specification of the cable modem MAC address, as shown in the
following example:
Example:
Router# show cable l2-vpn xconnect dot1q-vc-map 0014.f8c1.fd66 vpn 0234560001
Step 4 To display detailed information for a particular L2VPN ID on a specific cable modem, use the show cable l2-vpn xconnect
dot1q-vc-map vpn verbose form of the command along with specification of the cable modem MAC address, as shown
in the following example:
Example:
Router# show cable l2-vpn xconnect dot1q-vc-map 0014.f8c1.fd66 vpn 0234560001 verbose
MAC Address : 0014.f8c1.fd66
Prim Sid : 3
VPN ID : 0234560001
L2VPN SAID : 12294
Upstream SFID : 23
Downstream CFRID[SFID] : 2[24]
CMIM : 0x60
Ethernet Interface : GigabitEthernet4/0/0
DOT1Q VLAN ID : 68
Total US pkts : 1372
Total US pkt Discards : 0
Total US byte Discards : 0
Total DS pkts : 1248
Total DS pkt Discards : 0
Total DS byte Discards : 0
Step 5 To display detailed information and the current redundancy information for a particular cable modem, use the the show
cable l2-vpn xconnect dot1q-vc-map verbose form of the command along with specification of the cable modem MAC
address, as shown in the following example:
Example:
Router# show cable l2-vpn xconnect dot1q-vc-map 0014.f8c1.fd66 verbose

MAC Address : 5039.5589.4302
Prim Sid : 45
L2VPNs provisioned : 1
DUT Control/CMIM : Disable/0x8000FFFF
729
Enabling Voice-Call on a L2VPN CM
VPN ID : 000234560001
L2VPN SAID : 45
Upstream SFID Summary : 77
Upstream SFID [77 ] : SID 45
Downstream CFRID[SFID] Summary : Primary SF
CMIM : 0x60
Primary Ethernet Interface : GigabitEthernet4/0/0
Backup Ethernet Interface : GigabitEthernet4/0/1
Active Ethernet Interface : GigabitEthernet4/0/0
DOT1Q VLAN ID : 207
Total US pkts : 151269
Total DS pkts : 150502
Step 6 To display the dot1q L2VPN uplink redundancy information, use the show cable l2-vpn dot1q-nsi-redundancy as
Example:
Router# show cable l2-vpn dot1q-nsi-redundancy
Primary-NSI Backup-NSI Active-NSI Elapsed-after-SW
Te4/1/0 Te4/0/4 Te4/1/0 31m9s
Te4/1/2 Te4/0/5 Te4/1/2 59s
Enabling Voice-Call on a L2VPN CM

You can enable the Voice-Call Support on a L2VPN CM feature by registering a cable modem with a SID to
VPN mapping cable modem configuration file (MPLS or 802.1q).
• If the L2VPN is on the primary service flow, you should use a cable modem configuration file with static
secondary service flow and the classifiers should be configured on the secondary service flow for
non-L2VPN packets.
• If the L2VPN is on the secondary service flow, then classifiers should be configured for L2VPN packets.
Note The cable modem configuration file based L2VPN configuration provides the flexibility to configure L2VPN
on the primary or secondary service flow. However, we recommend that you configure L2VPN on the secondary
service flow and the primary service flow is used for the default traffic.
Note In a CLI-based L2VPN configuration, the L2VPN is on the primary service flow; therefore the static secondary
service flow should be used for the eMTAs.
Verifying Dynamic Service Flows

To verify dynamically created service flows on the Cisco CMTS router, use the show interface cable
service-flow command.
730
Configuration Examples for L2VPN over Cable
Note To verify information about PacketCable operations, use show packetcable commands.
Router# show interface cable 5/1/0 service-flow

Sfid : 30191
Mac Address : 000a.739e.140a
Type : Secondary(Dynamic)
Direction : Upstream
Current State : Active
Current QoS Indexes [Prov, Adm, Act] : [0, 24, 24]
Active Time : 00:55
Sid : 7140
Admitted QoS Timeout : 200 seconds
Active QoS Timeout : 0 seconds
Packets : 1824
Bytes : 466944
Rate Limit Delayed Grants : 0
Rate Limit Dropped Grants : 0
Current Throughput : 68356 bits/sec, 32 packets/sec
Classifiers:
Classifier Id : 41
Service Flow Id : 30191
CM Mac Address : 000a.739e.140a
Direction : upstream
Activation State : active
Classifier Matching Priority : 128
PHSI : 1
Number of matches : -
IP Classification Parameters:
IP Source Address : 10.8.230.3
Source IP Address Mask : 255.255.255.255
Destination IP Address : 172.16.2.35
Destination IP Address Mask : 255.255.255.255
IP Protocol Type : 17
Source Port Low : 53456
Source Port High : 53456
Destination Port Low : 7052
Destination Port High : 7052
Configuration Examples for L2VPN over Cable

This section provides configuration examples for the L2VPN over Cable feature:
Example: Specifying the Ethernet NSI Interface

You can specify the Ethernet NSI within the CM configuration file, or using the cable l2-vpn-service xconnect
global configuration command as shown in the following example:
cable l2-vpn-service xconnect nsi {dot1q|mpls}
731
Example: Enabling Voice Call Support on MPLS L2VPN
Example: Enabling Voice Call Support on MPLS L2VPN

The following is a sample cable modem configuration file that enables voice call support on MPLS L2VPN.
In this example the L2VPN is applied to the primary service flow.

S005 (Unknown sub-type) = 01 04 32 30 32 30 02 07 04 05 01 0a 4c 02 01 2b 06 26 04
00 00 01 90
22 (Upstream Packet Classification Encoding Block)
S01 (Classifier Reference) = 2
S09 (IP Packet Encodings)
T03 (IP Source Address) = 050 001 005 000
T04 (IP Source Mask) = 255 255 255 000
S10 (Ethernet LLC Packet Classification Encodings)
T02 (Source MAC Address) = 00 e0 f7 5a c9 21
23 (Downstream Packet Classification Encoding Block)
S05 (Rule Priority) = 5
T05 (IP Destination Address) = 050 001 005 000
T06 (IP Destination Mask) = 255 255 255 000
T01 (Destination MAC Address) = 00 e0 f7 5a c9 21 ff ff ff ff ff ff
S43 (Vendor Specific Options)
T08 (Vendor ID) = ff ff ff
T005 (Unknown sub-type) = 01 04 32 30 32 30
S07 (Traffic Priority) = 0
Example: Enabling Voice Call Support on 802.1q L2VPN

The following is a sample cable modem configuration file that enables voice call support on 802.1q L2VPN.
In this example the L2VPN is applied to the secondary service flow.
732
Example: Enabling Voice Call Support on CLI-based L2VPN

S005 (Unknown sub-type) = 01 05 02 34 56 00 01 02 04 02 02 00 44
T02 (Source MAC Address) = 00 e0 14 e3 23 1c
T005 (Unknown sub-type) = 01 05 02 34 56 00 01
S11 (IEEE 802.1P/Q Packet Classification Encodings)
T01 (IEEE 802.1P UserPriority) = 00 07
T005 (Unknown sub-type) = 01 05 02 34 56 00 01 08 01 01
Example: Enabling Voice Call Support on CLI-based L2VPN

The following is a sample cable modem configuration file that enables voice call support on L2VPN configured
using CLI. L2VPN configured using the CLI is always applied to the primary service flow.

T03 (IP Source Address) = 050 001 005 000
T04 (IP Source Mask) = 255 255 255 000
T02 (Source MAC Address) = 00 e0 f7 5a c9 21
T05 (IP Destination Address) = 050 001 005 000
T06 (IP Destination Mask) = 255 255 255 000
733

T01 (Destination MAC Address) = 00 e0 f7 5a c9 21 ff ff ff ff ff ff
The following sections provide references related to the L2VPN Support over Cable feature.
Standards
Standard Title
CM-SP-BPI+-I12-050812 Baseline Privacy Plus Interface Specification

http://www.cablelabs.com/wp-content/uploads/specdocs/CM-SP-BPI+-C01-081104.pdf
CM-SP-L2VPN-I03-061222 Business Services over DOCSIS (BSOD) Layer 2 Virtual Private Networks
http://www.cablelabs.com/wp-content/uploads/specdocs/CM-SP-L2VPN-I12-131120.pdf
CM-SP-RFIv2.0-I11-060602 Radio Frequency Interface Specification

http://www.cablelabs.com/wp-content/uploads/specdocs/CM-SP-RFIv2.0-C02-090422.pdf
IEEE 802.1ad IEEE 802.1ad-2005 IEEE Standards for Local and metropolitan area networks— Virtual
Bridged Local Area Networks
http://www.ieee.org
IEEE 802.1q IEEE Std 802.1Q Virtual Bridged Local Area Networks
http://www.ieee.org
MIBs
MIB MIBs Link
DOCS-L2VPN-MIB To locate and download MIBs for selected platforms, Cisco IOS-XE releases, and
feature sets, use Cisco MIB Locator found at the following URL:
734
Feature Information for L2VPN Support over Cable
RFCs
RFC Title
RFC 2685 Virtual Private Networks Identifier

http://www.ietf.org/rfc/rfc2685.txt
RFC 4364 BGP/MPLS IP Virtual Private Networks (VPNs)

Description Link


Table 128: Feature Information for L2VPN Support Over Cable
L2VPN support over cable Cisco IOS XE Everest 16.6.1 This feature was integrated into
Cisco IOS XE Everest 16.6.1 on
the Cisco cBR Series Converged
Broadband Router.
735
736
CHAPTER 50
L2VPN Over Port-Channel
The Layer 2 VPN (L2VPN) over port-channel feature supports IEEE 802.1Q (dot1q) L2VPN WAN interface
port-channel. Using this feature, you can configure the dot1q L2VPN traffic to pass through port-channel
uplink
Contents
• Information About L2VPN Over Port-Channel, on page 737
• How to Configure the L2VPN Over Port-Channel, on page 738
• Verifying Port-Channel Configuration, on page 738
• Feature Information for L2VPN Over Port-Channel, on page 739
Information About L2VPN Over Port-Channel

The Cisco cBR-8 supports L2VPN, where the Ethernet frames from the cable modem are cross connected to
a specific VLAN interface. The VLAN ID to be inserted is specified. With the L2VPN over port-channel
feature, you can now support port-channel uplink interface as well as the 10 Gb uplink interface.
TLS L2VPN
For the Transparent LAN Service (TLS) L2VPN, the dot1q maps contain the cable modem MAC address,
the VLAN ID, and the outbound interface. Traffic received from a specific cable modem is tagged with a
VLAN ID and is sent out from the uplink interface.
DOCSIS L2VPN
For the Data-over-Cable Service Interface Specifications (DOCSIS) L2VPN, cable modem (CM) configuration
file holds the L2VPN encodings for both, the CM and the service flow. At the CMTS level you have to specify
the default port-channel Network Side Interface (NSI). L2VPN encodings are passed by the CM to the CMTS
during registration. The CMTS installs DOCSIS service flow VLAN mapping based on the information passed
to it during the registration. For upstream traffic, the CMTS sends the dot1q VLAN tagged traffic out from
the uplink interface. On downstream, the CMTS receives the dot1q tagged traffic from the aggregator. The
CMTS replaces the VLAN header with a DOCSIS header to the corresponding service flow.
737
Benefits of L2VPN Over Port-Channel
Benefits of L2VPN Over Port-Channel

By using the dot1q L2VPN, you can utilize the port-channel interface feature instead of a single 10 Gb port.
Restrictions for L2VPN Over Port-Channel

The CMTS dot1q L2VPN is designed to support traffic from customer premises equipment to the network or
verse vice. For CMTS L2VPN NSI port, port-channel interface does not support VLAN redundancy.
How to Configure the L2VPN Over Port-Channel

This section describes how to configure L2VPN over port-channel on the Cisco cBR-8.
Configuring the Port-Channel Uplink Port for TLS L2VPN

For TLS L2VPN, you must configure the overall enable CLI and the dot1q map. In dot1q map, you have to
designate the port-channel uplink port.
To configure the port-channel uplink port for TLS L2VPN, complete the following procedure:
cable l2-vpn-service xconnect nsi dot1q
cable dot1q-vc-map mac address port-channel number vlan id custom name
Configuring the Port-Channel Uplink Port for DOCSIS L2VPN

For DOCSIS L2VPN, you only have to configure the overall enable CLI with port-channel uplink port. The
other L2VPN related parameters are setup by the CM configuration file type-length-value parsing.
To configure the port-channel uplink port for DOCSIS L2VPN, complete the following procedure:
configure terminal
cable l2-vpn-service xconnect nsi dot1q interface port-channel number
Verifying Port-Channel Configuration

Verify the Port-Channel Mapping
To verify the port-channel mapping, use the show cable l2-vpn xconnect dot1q-vc-map command as shown
show cable l2-vpn xconnect dot1q-vc-map
c8fb.26a5.551c Port-channel64 1200 Cable6/0/0 17 Topgun
View the Port-Channel Interface

To view the port-channel interface, use the show cable l2-vpn xconnect dot1q-vc-map verbose command
738
Feature Information for L2VPN Over Port-Channel
show cable l2-vpn xconnect dot1q-vc-map c8fb.26a5.551c verbose

MAC Address : c8fb.26a5.551c
Customer Name : ats
Prim Sid : 17
Ethernet Interface : Port-channel64
DOT1Q VLAN ID : 1200
Total US pkts : 189
Total DS pkts : 615

Table 129: Feature Information for L2VPN Over Port-Channel
L2VPN over Cisco IOS XE Everest This feature was integrated into Cisco IOS XE Everest
port-channel 16.6.1 16.6.1 on the Cisco cBR Series Converged Broadband
Router.
739
740
CHAPTER 51
MPLS Pseudowire for Cable L2VPN
The Multiprotocol Label Switching (MPLS) Pseudowire for Cable Layer 2 Virtual Private Network (L2VPN)
feature enables service providers to use a single, converged, Internet Protocol (IP)/MPLS network infrastructure
to offer Ethernet data link layer (Layer 2) connectivity to two or more VPN customer sites.
• Prerequisites for MPLS Pseudowire for Cable L2VPN, on page 743
• Restrictions for MPLS Pseudowire for Cable L2VPN, on page 743
• Information About MPLS Pseudowire for Cable L2VPN, on page 744
• L2VPN Pseudowire Redundancy, on page 747
• MPLS Pseudowire Provisioning Methods, on page 747
• How to Enable MPLS on a Cisco CMTS Router, on page 752
• How to Provision MPLS Pseudowires, on page 756
• How to Configure L2VPN Pseudowire Redundancy, on page 757
• Configuration Examples for MPLS Pseudowire for Cable L2VPN, on page 760
• Verifying the MPLS Pseudowire Configuration, on page 767
• Feature Information for MPLS Pseudowire for Cable L2VPN, on page 771

741
Digital PICs:

Module:

Modules:
742
Prerequisites for MPLS Pseudowire for Cable L2VPN
line card reload.
Prerequisites for MPLS Pseudowire for Cable L2VPN

• Enable Baseline Privacy Interface Plus (BPI+) to provide a simple data encryption scheme to protect
data sent to and from cable modems in a data over cable network.
• Enable Cisco Express Forwarding (CEF) to optimize network performance.
• Ensure that the primary and backup pseudowires on the remote provider edge (PE) routers have the same
pseudowire type as the Cisco cable modem termination system (CMTS).
• Create the remote pseudowire using a pw-class with VLAN as the interworking for remote PEs, if the
CMTS is using VLAN as pseudowire type.
Restrictions for MPLS Pseudowire for Cable L2VPN

The following are the general restrictions for the MPLS Pseudowire for Cable L2VPN feature:
• Supports only Ethernet over MPLS (EoMPLS) pseudowires per RFC 4448.
• Supports only point-to-point forwarding. Ethernet switching is not supported.
• Requires DOCSIS 2.0, 3.0 and 3.1-certified cable modems (CMs). This feature is not supported on
DOCSIS 1.0-certified cable modems.
• Supports a maximum of four VPNs per cable modem.
• Supports a maximum of eight upstream service flows and eight downstream classifiers.
• Supports a maximum of 16000 EoMPLS pseudowires per Cisco CMTS router.
• Requires the backup pseudowire to be up on the remote PE for the Cisco CMTS to switchover.
• Requires the backup pseudowire to become active on the Cisco CMTS only after the primary pseudowire
fails.
• Supports 2000 Bytes MTU (default value) on remote interface for DOCSIS 3.1 cable modem.
Note The CLI-based (static provisioning) L2VPN supports traffic forwarding to VPN only on primary upstream
and downstream service flows. Hence only primary upstream and downstream service flows must be configured
in the cable modem configuration file.
743
Information About MPLS Pseudowire for Cable L2VPN
Information About MPLS Pseudowire for Cable L2VPN

The MPLS Pseudowire for Cable L2VPN feature enables Ethernet-based Layer 2 VPN service over an MPLS
network by encapsulating and transmitting the Layer 2 protocol data units (PDUs) over pseudowires (PWs).
This feature enables service providers to offer site-to-site connectivity to their business and enterprise customers.
Layer 2 services emulated over an MPLS network are commonly referred to as MPLS-based L2VPNs or
MPLS L2VPNs. Subsequently, Ethernet service emulated over an MPLS network is referred to as Ethernet
over MPLS (EoMPLS) service.
The MPLS Pseudowire for Cable L2VPN feature is fully compliant with CableLabs Business Services over
DOCSIS (BSOD) L2VPN specification, and is an extension to the existing DOCSIS L2VPN features supported
on Cisco CMTS routers.
The MPLS Pseudowire for Cable L2VPN feature provides the following capabilities:
• Supports 2000 Bytes MTU (default value) on remote interface for DOCSIS 3.1 cable modems.
• Transport Ethernet frames over an MPLS network.
• Handle a DOCSIS service flow as an attachment circuit that is mapped to an EoMPLS pseudowire.
• Enable the Cisco CMTS router to be the MPLS provider edge (PE) router.
• Enable forwarding of Ethernet frames over DOCSIS (between a CM and a Cisco CMTS router) to MPLS
(towards Metropolitan Area Network or Wide Area Network).
• Provide a common framework to encapsulate and transport supported Layer 2 traffic types over an MPLS
network.
The MPLS Pseudowire for Cable L2VPN feature differs from the existing DOCSIS L2VPN features such as
802.1q-based L2VPN (L2VPN Support over Cable). The MPLS Pseudowire for Cable L2VPN feature uses
IP/MPLS network to transport layer 2 protocol data units (PDUs), whereas 802.1q-based L2VPN feature uses
layer 2 Ethernet network to transport PDUs.
How MPLS Transports Layer 2 Packets

The MPLS subsystem removes DOCSIS encapsulation for Layer 2 Ethernet frames and adds MPLS labels at
the ingress provider edge (PE) Cisco CMTS router. Then, the MPLS subsystem sends resulting MPLS packets
to the corresponding PE router at the other end of the pseudowire. The PE routers must be configured for
successful transmission of IP/MPLS packets between the two PE routers.
The cable modem classifies Ethernet frames from the customer premise equipment (CPE) in the upstream
direction using upstream classifiers. Then, a DOCSIS header is added to these frames, and they are sent on a
given upstream service flow with a different service identifier. On the Cisco CMTS router, the upstream packet
is classified as an L2VPN packet based on the cable interface and service identifier. The Cisco CMTS router
removes the DOCSIS header and adds an MPLS header. An MPLS header contains two MPLS labels: the
outer label corresponding to the remote PE router and the inner label corresponding to the pseudowire label.
The Cisco CMTS router forwards the MPLS packet towards the remote PE router, which is the other end of
the pseudowire, over the MPLS network.
In the downstream direction, the Cisco CMTS router receives MPLS packets having only one MPLS header
that contains the label that the Cisco CMTS router previously allocated for the corresponding EoMPLS
pseudowire. The Cisco CMTS router uses the MPLS label to identify one of the L2VPN cable modems. Then,
744
How MPLS Transports Layer 2 Packets
the Cisco CMTS router classifies the MPLS packet using the L2VPN downstream classifiers based on MPLS
experimental (MPLS-EXP) bits in the MPLS header of the received MPLS packet, and removes the MPLS
header. Then, the Cisco CMTS router sends the packet on the classified downstream service flow by adding
the DOCSIS header. The cable modem then removes the DOCSIS header and delivers the Ethernet frame to
the CPE.
A unique combination of a cable modem MAC address, VPN ID (if present in the CM configuration file),
peer IP address, and a virtual circuit ID (VCID) identifies the MPLS pseudowire on the Cisco CMTS router.
Figure 24: Transporting Layer 2 Packets
The table illustrates how MPLS transports Layer 2 packets in a DOCSIS-based cable communications system.
1 A router sends an untagged Ethernet frame. 6 MPLS packets are label switched.
2 A CM adds a DOCSIS header to the frame. 7 The Cisco CMTS router receives an MPLS packet
and looks up the MPLS forwarding table using the
label value in the MPLS header.
3 The Cisco CMTS router removes the DOCSIS 8 The Cisco CMTS router replaces the MPLS header
header from the frame. with DOCSIS header (containing the right SID
value).
4 The Cisco CMTS router looks up the Service ID 9 The DOCSIS header is removed.
(SID) database using the SID value from the
DOCSIS header and finds the MPLS header.
5 The Cisco CMTS router adds the MPLS header to 10 The Ethernet frame is delivered untagged.
the frame.
745
Supported Ethernet Encapsulation on UNI
Supported Ethernet Encapsulation on UNI

The Ethernet User-Network Interface (UNI) is the connection between a cable modem and a customer premise
equipment such as a router or a switch. The service provider may or may not use any encapsulation on the
UNI.
The MPLS Pseudowire for Cable L2VPN feature supports the following transport types on an Ethernet UNI:
• Port-based UNI (independent of any VLAN)—The port-based UNI provides Metro Ethernet Forum
(MEF)-defined Ethernet Private Line (EPL) service. In this transport type, an MPLS pseudowire is
mapped to the Ethernet port.
• VLAN-based UNI—Ethernet VLAN using 802.1q encapsulation (including stacked VLANs). The
VLAN-based UNI provides MEF-defined Ethernet Virtual Private Line (EVPL) service. In this transport
type, the MPLS pseudowire is mapped to the 802.1q VLAN.
Note The Ethernet UNI must be attached to the Ethernet port of a cable modem.
Before configuring this feature, you should understand the following concepts:
MPLS Pseudowire
Pseudowire is a point-to-point Layer 2 connection between two PE routers. The MPLS Pseudowire for Cable
L2VPN feature supports the following pseudowire types:
• Type-4 pseudowire—This is used to transport only VLAN tagged Layer 2 Ethernet frames.
• Type-5 pseudowire—This is used to transport VLAN tagged and untagged Layer 2 Ethernet frames. This
is the default pseudowire type.
Bundle254 Interface
The bundle254 (Bu254) interface is an internal bundle interface on a Cisco CMTS router that is used as a
circuit identifier for all MPLS pseudowires. This internal bundle interface is created automatically on a Cisco
CMTS router when you enable the MPLS pseudowire functionality using the cable l2-vpn-service xconnect
command. Only one Bu254 interface is created to handle all the MPLS pseudowires available on the Cisco
CMTS router.
The output of the show xconnect or show cable l2-vpn xconnect command displays the circuit identifier
created by the Cisco CMTS router for all the MPLS pseudowires.
Ingress Process
When an upstream packet received from a cable interface of the Cisco CMTS router is identified as an L2VPN
packet based on the cable modem interface and Service ID (SID), the packet goes through the ingress process.
The ingress process ensures that the DOCSIS header is removed, and an MPLS label header is added to the
packet according to the MPLS pseudowire configuration and the packet is sent out from the Ethernet interface
of the Cisco CMTS router. The ingress process is also known as the label imposition process.
746
Egress Process
Egress Process
When a downstream packet received from an Ethernet interface of the Cisco CMTS router is identified as an
L2VPN packet by the innermost MPLS label, the packet goes through the egress process. The egress process
ensures that the MPLS label header is deleted from the packet and the DOCSIS header is added to the packet.
Then the packet is sent out from the cable interface of the Cisco CMTS router. The egress process is also
known as the label disposition process.
MPLS Pseudowire Control Plane Process

When an L2VPN-compliant CM registers with a Cisco CMTS router and conveys the L2VPN related parameters
to the router, the router follows the standard Label Distribution Protocol (LDP) procedures to set up an Ethernet
over MPLS pseudowire with the remote PE router. When the L2VPN-compliant CM goes offline, the Cisco
CMTS router brings down the pseudowire as well. If the Cisco CMTS router has no L2VPN-compliant CM
registered, then the router tears down the targeted LDP session with the remote PE router.
L2VPN Pseudowire Redundancy

The L2VPN Pseudowire Redundancy feature enables a PE router to detect a pseudowire failure and reroute
the Layer 2 service to a backup pseudowire that can continue to provide the service. The pseudowire redundancy
can be implemented with either Cisco CMTS or a generic router as the PE router. When the primary pseudowire
recovers from the failure, the L2VPN Pseudowire Redundancy feature provides the option to bring back the
Layer 2 service to the primary pseudowire.
Each primary pseudowire can have up to three backup pseudowires, with unique priorities. For example,
priority one cannot be given to two different pseudowires in the backup list. When the primary pseudowire
goes down, the Cisco CMTS sends the traffic to the backup pseudowire with the highest priority. For a
successful service transfer, the remote state of the backup pseudowire should already be ‘up’. Only the local
state of the active pseudowire will be 'up' when the modem is BPI online. Similarly, if the backup pseudowire
is in use, the local state of only that backup pseudowire will be 'up'.
If the active backup pseudowire goes down, the Cisco CMTS will use the next highest backup pseudowire
whose remote state is ‘up’. However, the Cisco CMTS will not switchover from the lower priority pseudowire
to the higher priority pseudowire when the backup pseudowire with the highest priority comes ‘up’. This is
to prevent unnecessary switchovers between the backup pseudowires.
When the primary pseudowire recovers from the failure, the L2VPN Pseudowire Redundancy feature brings
back the service to the primary pseudowire, after waiting for the time period set using the backup delay
command. The local state of the active backup pseudowire will be marked as ‘down’ after the primary
pseudowire comes up.
MPLS Pseudowire Provisioning Methods

The MPLS Pseudowire for Cable L2VPN feature supports the following provisioning methods for pseudowires:
747
Static Provisioning Method for MPLS Pseudowires
Note Before performing the static or dynamic provisioning of MPLS pseudowires, you must enable MPLS on a
Cisco CMTS router. For details on the tasks required to enable MPLS, see the How to Enable MPLS on a
Cisco CMTS Router.

The static provisioning method requires the MPLS pseudowire to be statically provisioned on the CMTS using
the command line interface (CLI). This type of provisioning does not require the CM configuration file to use
BSOD L2VPN-compliant TLVs. For details on how to statically provision MPLS pseudowires, see the Static
Provisioning of MPLS Pseudowires.
Dynamic Provisioning Method for MPLS Pseudowires

The dynamic provisioning method is a CM configuration file-based provisioning method and is the
recommended provisioning method for creating MPLS pseudowires. For details on how to dynamically
provision MPLS pseudowires, see the Dynamic Provisioning of MPLS Pseudowires, on page 756.
The following are the benefits of dynamic provisioning of pseudowires:
• Multiple VPNs can be specified in a CM configuration file and a pseudowire can be provisioned for each
VPN.
• Multiple upstream service flows and downstream classifiers can be associated with each VPN.
• Each upstream service flow can be tagged to an MPLS experimental (EXP) level for the egress WAN
traffic.
• Downstream ingress WAN traffic can be classified based on the downstream MPLS-EXP range specified
in each downstream classifier.
• The Cisco CMTS router will have finer control of MPLS quality of service (QoS) over cable and WAN
interfaces.
For dynamic provisioning of MPLS pseudowires, you use an L2VPN-compliant CM configuration file that
is stored on the Trivial File Transfer Protocol (TFTP) server. You use a common CM configuration file editor
such as CableLabs Config File Editor, or a sophisticated provisioning backend system such as Broadband
Access Center for Cable (BACC) to create CM configuration files.
This provisioning method requires the usage of CableLabs defined L2VPN encodings such as type, length,
value (TLV) objects in the CM configuration file. These L2VPN encodings control L2VPN forwarding of
upstream and downstream Ethernet frames.
You can specify the L2VPN encodings in the following ways:
• Per CM
• Per downstream classifier
• Per service flow
• Per upstream classifier
Note The CM L2VPN encoding is mandatory.
748
Dynamic Provisioning Method for MPLS Pseudowires
The CM L2VPN encoding contains many TLVs, out of which the two most important TLVs are VPN Identifier
and NSI Encapsulation. To configure an MPLS pseudowire, you must set the NSI Encapsulation to MPLS.
The other TLVs are used to specify the pseudowire identifiers in the form of source attachment individual
identifier (SAII), target attachment individual identifier (TAII), and attachment group identifier (AGI).
The L2VPN encoding parameter is encoded as a general extension information (GEI) parameter in the CM
configuration file. This indicates that the parameter is encoded as a subtype of the vendor-specific information
type parameter using the vendor ID (0xFFFFFF).
The table lists the important CableLabs defined TLVs that are used at the top level of the CM configuration
file for the MPLS Pseudowire for Cable L2VPN feature. See the BSOD specification, Business Services over
DOCSIS (BSOD) Layer 2 Virtual Private Networks, from CableLabs for a complete list of CableLabs defined
TLVs.
Table 131: CableLabs Defined L2VPN TLVs
TLV Name Type Length Value and Description
Downstream Unencrypted Traffic 45.1 1 Bit 0 DUT Filtering

(DUT) Control
DUT Filtering = 0: Disable (default)
DUT Filtering = 1: Enable DUT Filtering
Downstream Unencrypted Traffic 45.2 N DUT CMIM (optional)

(DUT) CMIM
CM Interface Mask (CMIM) limiting outgoing interfaces of DUT traffic. If the
DUT CMIM is omitted, its default value includes the eCM and all implemented
eSAFE interfaces, but not any CPE interfaces.
VPN Identifier 43.5.1 1 to N An opaque octet string that identifies an L2VPN. N is vendor- specific, and the
NSI Encapsulation Subtype 43.5.2 n A single NSI encapsulation format code/length/value tuple. This TLV uses any
of the following values:
NSI encapsulation = 0 : Other
NSI encapsulation = 1 : IEEE 802.1Q (specify VLAN ID)
NSI encapsulation = 2 : IEEE 802.1AD (specify Q-in-Q)
NSI encapsulation = 3 : MPLS peer (specify IPv4 or IPv6 address)
The value must be set to 3 to ensure MPLS pseudowire usage. The address must
identify the remote PE (by its IP address assigned to the loopback interface).
Attachment Group ID 43.5.5 0 to 16 Opaque byte string that identifies the CM or SF as an attachment circuit for IETF
Layer 2 VPN signaling protocols.
Source Attachment Individual ID 43.5.6 0 to 16 Opaque byte string signaled as SAII circuit for IETF Layer 2 VPN signaling
protocols.
Target Attachment Individual ID 43.5.7 0 to 16 Opaque byte string that identifies the CM or SF as an attachment circuit for IETF
Layer 2 VPN signaling protocols.
Ingress User Priority 43.5.8 1 Ingress IEEE 802.1 user priority value in the range of 0 to 7 encoded in the least
significant three bits. Higher values indicate higher priority.
749
Cisco-Specific L2VPN TLVs
TLV Name Type Length Value and Description
User Priority Range 43.5.9 2 The lower user priority value of the user priority range is encoded in the least
significant three bits of the first byte, and the higher value of the range is encoded
in the least significant three bits of the second byte.

Even though CableLabs defined L2VPN TLVs are sufficient for dynamic provisioning of MPLS pseudowires,
CMTS operators can use Cisco-specific TLVs at the top level of the CM configuration file to enable additional
functions.
This table lists the new Cisco-specific TLVs that are defined for the MPLS Pseudowire for Cable L2VPN
feature.
Table 132: Cisco-Specific L2VPN TLVs
TLV Name Type Length Value Description
MPLS-PW-TYPE 43.5.43.36 1 • 4 = Type-4 Ethernet The Cisco CMTS router interprets this subtype as MPLS
VLAN pseudowire type (Type-4 or Type-5). If this TLV value is not
• 5 = Type-5 Ethernet specified, then the router accepts the default value (5) for
port Type-5.
MPLS-VCID 43.5.43.38 4 4 bytes unsigned number = This subtype is interpreted as MPLS VCID.
MPLS VCID
This TLV is ignored, and the value of TAII is used as VCID
for the pseudowire, if the following conditions are met:
• The CableLabs BSOD specification-compliant TLVs,
SAII and TAII, are present in the CM configuration file.
• Both are of 4 bytes length.
• Value of SAII is equal to TAII.
MPLS-PEERNAME 43.5.43.39 N ASCII encoded data The Cisco CMTS router interprets this optional subtype as
MPLS peer name in ASCII encoded data.
This table lists the new Cisco-specific type, length, values (TLVs) that are defined for the L2VPN Pseudowire
Redundancy feature.
Table 133: Cisco-Specific L2VPN TLVs for Pseudowire Redundancy
BACKUP-PW 45.5.43.40 N Backup pseudowire The Cisco CMTS router interprets this subtype as
related parameters related parameters for the MPLS backup pseudowire.
This TLV indicates the start of a new backup
pseudowire.
BACKUP-PEERIP 43.5.43.40.1 4 IP address of the The Cisco CMTS router interprets this optional
backup peer (IPv4) subtype as the peer IP address of the MPLS backup
pseudowire. This TLV is an IPv4 address.
750
BACKUP-PEERNAME 43.5.43.40.2 N ASCII encoded data The Cisco CMTS router interprets this optional
subtype as the MPLS backup peer name in ASCII
encoded data.
This TLV is resolved to IPv4 address through DNS.
BACKUP-MPLS-VCID 43.5.43.40.3 4 4 bytes unsigned The Cisco CMTS router interprets this subtype as the
number = MPLS VCID VCID of the backup pseudowire.
for backup pseudowire
This TLV is ignored, and the value of TAII is used as
the VCID for the pseudowire, if the following
conditions are met:
• The CableLabs BSOD specification-compliant
TLVs, SAII, and TAII, are present in the CM
configuration file.
• SAII, and TAII are of 4 bytes length.
• Value of SAII is equal to TAII.
BACKUP-MPLS-PRIORITY 43.5.43.40.4 1 1 byte unsigned number The Cisco CMTS router interprets this subtype as the
= priority for the MPLS priority.
backup pseudowire
Each primary pseudowire can have up to three backup
pseudowires, with unique priorities. The priority
indicates the order in which the CMTS should switch
to the backup peer when the primary peer is down.
BACKUP-ENABLE-DELAY 43.5.43.41 1 1 byte unsigned number The Cisco CMTS router interprets this subtype as the
= number of seconds number of seconds the backup pseudowire should wait
to take over after the primary pseudowire goes down.
If the TLV value is not specified, then the router uses
the default value of 0 seconds.
BACKUP-DISABLE-DELAY 43.5.43.42 1 1 byte unsigned number The Cisco CMTS router interprets this subtype as the
= number of seconds number of seconds the primary pseudowire should
wait to take over after the remote state of the primary
pseudowire comes up.
If the TLV value is not specified, then the router uses
the default value of 0 seconds.
BACKUP-DISABLE-NEVER 43.5.43.43 1 1 byte unsigned number The Cisco CMTS router interprets this subtype as a
= never disable backup flag indicating that the backup pseudowire should not
pseudowire be disabled even after the primary pseudowire comes
up.
If this TLV is not present, the router takes the default
action of reverting back to the primary pseudowire.
751
How to Enable MPLS on a Cisco CMTS Router
How to Enable MPLS on a Cisco CMTS Router

Perform the following tasks in the same order to enable MPLS on a Cisco CMTS router:
Cisco CMTS router.
Configuring an LDP Router ID

The mpls ldp router-id command allows you to assign an interface IP address as the LDP router ID.
The normal process to determine the LDP router ID is as follows:
1. The router considers all the IP addresses of all operational interfaces.
2. If these addresses include loopback interface addresses, the router selects the largest loopback address.
Configuring a loopback address helps ensure a stable LDP ID for the router, because the state of loopback
addresses does not change. However, configuring a loopback interface and IP address on each router is
not required.
The loopback IP address is not considered as the router ID of the local LDP ID under the following
circumstances:
1. If the loopback interface has been explicitly shut down.
2. If the mpls ldp router-id command specifies that a different interface should be used as the LDP router
ID.
3. If you use a loopback interface, make sure that the IP address for the loopback interface is configured
with a /32 network mask. In addition, ensure that the routing protocol in use is configured to advertise
the corresponding /32 network. Otherwise, the router selects the largest interface address.
The router might select a router ID that is not usable in certain situations. For example, the router might select
an IP address that the routing protocol cannot advertise to a neighboring router. The router implements the
router ID the next time it is necessary to select an LDP router ID. The effect of the mpls ldp router-id
command is delayed until it is necessary to select an LDP router ID, which is the next time the interface is
shut down or the address is deconfigured.
If you use the force keyword with the mpls ldp router-id command, the router ID takes effect more quickly.
However, implementing the router ID depends on the current state of the specified interface:
• If the interface is up (operational) and its IP address is not currently the LDP router ID, the LDP router
ID is forcibly changed to the IP address of the interface. This forced change in the LDP router ID tears
down any existing LDP sessions, releases label bindings learned via the LDP sessions, and interrupts
MPLS forwarding activity associated with the bindings.
• If the interface is down, the LDP router ID is forcibly changed to the IP address of the interface when
the interface transitions to up. This forced change in the LDP router ID tears down any existing LDP
sessions, releases label bindings learned via the LDP sessions, and interrupts MPLS forwarding activity
associated with the bindings.
Before you begin

Ensure that the specified interface is operational before assigning it as the LDP router ID.
752
Configuring MPLS on a Gigabit Ethernet Interface
Procedure

Router> enable

Example:
Step 3 mpls ip Enables the dynamic MPLS forwarding function on the

specified Gigabit Ethernet interface.
Example:
Router(config)# mpls ip
Step 4 mpls ldp router-id loopback interface-number [force] Specifies the IP address of the loopback interface as the
LDP router ID.
Example:
Router(config)# mpls ldp router-id loopback 2030

force
Step 5 exit Exits global configuration mode and enters privileged EXEC
mode.
Example:
Configuring MPLS on a Gigabit Ethernet Interface

MPLS forwarding and Label Distribution Protocol must be enabled on 1-port or 10-port GE interfaces of the
Cisco CMTS router to ensure that the router establishes MPLS label-switched path (LSP) to the remote PE
routers. This section explains how to enable MPLS forwarding and LDP on a Gigabit Ethernet interface.
Note Configuration steps are similar for 1-port and 10-port GE interfaces.
Procedure

Router> enable
753
Configuring an MPLS Label Distribution Protocol

Example:
Step 3 interface gigabitethernet slot/subslot/port Enters interface cable configuration mode and specifies the
Gigabit Ethernet interface.
Example:
Router(config)# interface gigabitethernet 3/0/0
Step 4 mpls ip Enables the dynamic MPLS forwarding function on the

specified Gigabit Ethernet interface.
Example:
Router(config-if)# mpls ip
Step 5 end Exits interface cable configuration mode and enters

Example:
Configuring an MPLS Label Distribution Protocol

The MPLS label distribution protocol (LDP) allows the construction of highly scalable and flexible IP VPNs
that support multiple levels of services. This section explains how to configure an MPLS label distribution
protocol on a Gigabit Ethernet interface.
MPLS LDP graceful-restart may also be configured for faster L2VPN traffic recovery after a LDP session
disruption. For more information see the MPLS LDP Graceful Restart guide.
Note Ensure that the loopback interface with the IP address is present on each PE router using the show ip interface
brief command before configuring an MPLS label distribution protocol. This loopback interface identifies
the Cisco CMTS router as the peer IP address of the pseudowire.
Procedure

754
Enabling the Cisco CMTS Support for MPLS Pseudowire for Cable L2VPN
Router> enable

Example:
Step 3 interface gigabitethernet slot/subslot/port Enters interface cable configuration mode and specifies the
Gigabit Ethernet interface.
Example:
Router(config)# interface gigabitethernet 3/0/0
Step 4 mpls label protocol ldp Enables MPLS LDP parameters on the specified Gigabit
Ethernet interface.
Example:
Router(config-if)# mpls label protocol ldp
Step 5 end Exits interface cable configuration mode and enters

Example:
Enabling the Cisco CMTS Support for MPLS Pseudowire for Cable L2VPN
You must enable the MPLS tunnel traffic on the network side of the interface to support configuration of
MPLS pseudowires on a Cisco CMTS router.
Procedure

Router> enable

Example:
755
Customize MTU

Step 3 cable l2-vpn-service xconnect nsi mpls Enables the MPLS tunnel traffic, where:
Example:
Router(config)# cable l2-vpn-service xconnect nsi

mpls
Step 4 exit Exits global configuration mode and enters privileged EXEC
mode.
Example:
Customize MTU
You can extend the MTU to a maximum of 2000 B, which is the default value on a remote interface for
DOCSIS 3.1 cable modem.
Use the following commands to customize and configure the MTU:
• To configure the MTU globally, run the following command:
router(config)#cable l2-vpn-service xconnect extended-mtu ?
<1500-2000> Customized MTU
<cr>
• To configure the MTU for each session, run the following command:
router(config-ethsrv)#xconnect 2.2.2.2 2000 encapsulation mpls extended-mtu ?
<1500-2000> in bytes without L2 overhead
How to Provision MPLS Pseudowires

You can provision MPLS pseudowires in the following ways:
Cisco CMTS router.
Dynamic Provisioning of MPLS Pseudowires

The dynamic provisioning method supports the following types of configurations:
• BSOD Specification-Based MPLS Pseudowire Provisioning
• Type-4 MPLS Pseudowire Provisioning Using the CM Configuration File
• Type-5 MPLS Pseudowire Provisioning Using the CM Configuration File
756
See the Configuration Examples for Dynamic Provisioning of MPLS Pseudowires for details about the dynamic
provisioning method using the CM configuration file.
Note We recommend that you use the dynamic provisioning method instead of the static provisioning method for
MPLS pseudowires.

The static provisioning method requires the MPLS pseudowire to be statically provisioned on the CMTS using
the command line interface (CLI). This type of provisioning does not require the CM configuration file to use
BSOD L2VPN-compliant TLVs. For details on how to statically provision MPLS pseudowires, see the Static
Provisioning of MPLS Pseudowires.
How to Configure L2VPN Pseudowire Redundancy

The L2VPN Pseudowire Redundancy feature enables you to switch to backup pseudowires when the primary
pseudowire fails. The feature also allows the Cisco CMTS to resume operation on the primary pseudowire
after it comes back up.
Configuring the Backup Pseudowire

You can configure up to three backup pseudowires for a primary pseudowire. The priority of each backup
pseudowire has to be unique.
A backup pseudowire is uniquely identified by a combination of IP address or hostname and VCID. Only the
IP address or hostname and VCID can be configured for the backup peer, the remaining parameters are the
same as the primary pseudowire.
Backup pseudowires can also be configured using the DOCSIS configuration files.
Perform the steps given below to configure a backup pseudowire.
Procedure

Router> enable

Example:
757
Configuring Backup Delay

Step 3 cable l2vpn mac-address Specifies L2VPN MAC address and enters L2VPN
configuration mode.
Example:
Router(config)# cable l2vpn 0011.0011.0011
Step 4 service instance id service-type Specifies the service instance ID and enters Ethernet service
configuration mode.
Example:
Router(config-l2vpn)# service instance 1 ethernet
Step 5 xconnect peer-ip-address vc-id encapsulation mpls Specifies the tunneling method to encapsulate the data in
the MPLS pseudowire and enters xconnect configuration
Example:
mode.
Router(config-ethsrv)# xconnect 10.2.2.2 22
encapsulation mpls
Step 6 backup peer peer-ip-address vc-id [priority value] Specifies the backup pseudowire and its priority. The
priority keyword is optional, if only one backup pseudowire
Example:
is configured. When multiple backup pseudowires are
configured, it is required.
Router(config-xconn)# backup peer 10.3.3.3 33
priority 2
Step 7 end Exits xconnect configuration mode and enters Privileged

EXEC mode.
Example:
Router(config-xconn)# end

Perform the steps given below to configure the period the backup pseudowire should wait to take over after
the primary pseudowire goes down. You can also specify how long the primary pseudowire should wait after
it becomes active to take over from the backup pseudowire.
Procedure

Router> enable
758

Example:
Step 3 cable l2vpn mac-address Specifies the L2VPN MAC address and enters L2VPN
configuration mode.
Example:
• mac-address—MAC address of a CM.
Router(config)# cable l2vpn 0011.0011.0011
Step 4 service instance id service-type Specifies the service instance ID and enters Ethernet service
configuration mode.
Example:
• id—Service instance ID.
Router(config-l2vpn)# service instance 1 ethernet • service-type—Service type for the instance.
Step 5 xconnect peer-ip-address vc-id encapsulation mpls Specifies the tunneling method to encapsulate the data in
the MPLS pseudowire and enters xconnect configuration
Example:
mode.
Router(config-ethsrv)# xconnect 10.2.2.2 22 • peer-ip-address—IP address of the remote PE router.
encapsulation mpls The remote router ID can be any IP address, as long
as it is reachable.
• vc-id—32-bit identifier of the virtual circuit between
the PE routers.
• encapsulation mpls—Specifies MPLS as the tunneling
method.
Step 6 Do one of the following: Specifies the period to wait before enabling or disabling
the backup pseudowire.
• backup delay enable-delay-period
{disable-delay-period | never} • enable-delay-period—Number of seconds the backup
• pseudowire should wait to take over after the primary
pseudowire goes down. The valid range is from 0 to
Example: 180 seconds, with a default value of 0.
• disable-delay-period—Number of seconds the primary
Router(config-xconn)# backup delay 10 10
pseudowire should wait after it becomes active to take
over from the backup pseudowire. The valid range is
Example: from 0 to 180 seconds, with a default value of 0.
• never—Specifies the primary pseudowire should not
Router(config-xconn)# backup delay 10 never
be reactivated after moving to the backup pseudowire.
Step 7 end Exits xconnect configuration mode and enters privileged

EXEC mode.
Example:
Router(config-xconn)# end
759
Performing Manual Switchover
Performing Manual Switchover

Perform the steps given below to perform a manual switchover to the primary or backup pseudowire. The
xconnect backup force-switchover command can also be used to forcefully switch to the backup pseudowire
for planned outages of the primary remote peer.
Note A manual switchover can be made only to an available member in the redundancy group. If the pseudowire
specified in the command is not available, the command will be rejected.
Procedure

Router> enable
Step 2 xconnect backup force-switchover peer 10.10.1.1 123 Specifies that the router should switch to the backup or to
the primary pseudowire.
Example:
Router# xconnect backup force-switchover peer

10.10.1.1 123
The following commands help you troubleshoot an improper MPLS pseudowire configuration:
• show ip interface brief—Helps verify that the loopback interface with the IP address is present on each
PE router.
• show mpls l2transport vc—Helps verify information about primary and backup pseudowires that have
been enabled to route Layer 2 packets on a router.
• show xconnect all—Helps verify information about all xconnect attachment circuits and primary and
backup pseudowires.
• show cable l2-vpn xconnect mpls-vc-map—Helps verify that the primary and backup pseudowires are
configured properly.
Configuration Examples for MPLS Pseudowire for Cable L2VPN

The following sections provide MPLS pseudowire configuration examples for the static and dynamic
provisioning methods:
760
Configuration Example for Static Provisioning of MPLS Pseudowires
Configuration Example for Static Provisioning of MPLS Pseudowires

The following example shows CLI-based provisioning of an MPLS pseudowire:
Router> enable
Router(config)# cable l2vpn 0000.396e.6a68 customer2
Router(config-l2vpn)# service instance 2000 ethernet
Router(config-ethsrv)# xconnect 101.1.0.2 221 encapsulation mpls pw-type 4
Router(config-ethsrv)# cable set mpls-experimental 7
Configuration Examples for Dynamic Provisioning of MPLS Pseudowires

The following sections provide MPLS pseudowire provisioning examples based on BSOD CableLabs
specification, Type-4, and Type-5 TLVs using the CM configuration file:
BSOD Specification-Based MPLS Pseudowire Provisioning: Example

The following example shows an MPLS pseudowire configuration based on BSOD CableLabs specification:

S005 (L2VPN sub-type)
=
T01 (VPN Id) = 02 34 56 00 02 # VPNID=0234650002
T02 (NSI) = 04 05 01 0a 4c 01 01# [04=mpls] [05=len][01=ipv4][IP=10.76.1.1]
T05 (AGI) = 01 01 07 d1 # AGI = 0x010107d1
T06 (SAII) = 00 00 07 d1 # SAII = TAII = VCID = 0x7d1 = 2001
T07 (TAII) = 00 00 07 d1
T005 (L2VPN sub-type) =
S01 (VPNID) = 02 34 56 00 02
S08 (UserPrio) = 01

S01 (VPNID) = 02 34 56 00 02
S08 (UserPrio) = 04
S01 (VPNID) = 02 34 56 00 02
S08 (UserPrio) = 05
761
BSOD Specification-Based MPLS Pseudowire Provisioning: Example

S01 (VPNID) = 02 34 56 00 02
S08 (UserPrio) = 06
T01 (IP Type of Srv Rng & Mask) = 00 20 ff
T01 (IP Type of Srv Rng & Mask) = 41 ff ff
T005 (L2VPN sub-type)
S01 (VPNID) = 02 34 56 00 02
S01 (VPNID) = 02 34 56 00 02
762
Type-4 MPLS Pseudowire Provisioning Using the CM Configuration File: Example

S01 (VPNID) = 02 34 56 00 02

The following example shows a CM configuration file-based provisioning of a Type-4 MPLS pseudowire:

S005 (L2VPN Options) =
T001 (VPN ID) = 02 34 56 00 02 # VPN-ID = "0234560002"
T043 (Cisco Vendor Specific) = 2b 16
S008 (Vendor ID) = 00 00 0c # Vendor ID = "00 00 0C" - CISCO
S036 (MPLSPWTYPE) = 24 01 04 # MPLSPWTYPE= Type4 - Ethernet-vlan Type
S039 (MPLSPEERNAME) = 27 06 63 37 36 30 30 32 MPLSPEERNAME= "c76002" in ascii
S038 (MPLSVCID) = 26 04 00 00 07 d1 = 2001 VCID
T001 (VPN ID) = 02 34 56 00 03 # VPN-ID = "0234560003"
S008 (Vendor ID) = 00 00 0c Vendor ID = "00 00 0C" - CISCO
S036 (MPLSPWTYPE) = 24 01 04 MPLSPWTYPE= Type4 - Ethernet-vlan Type
S039 (MPLSPEERNAME) = 27 06 63 37 36 30 30 32 # MPLSPEERNAME= "c76002" in ascii
S038 (MPLSVCID) = 26 04 00 00 0b b9 # = 3001 VCID
T001 (VPN ID) = 02 34 56 00 04 # VPN-ID = "0234560004"
S036 (MPLSPWTYPE) = 24 01 04 # MPLSPWTYPE= Type4 - Ethernet-vlan Type
S038 (MPLSVCID) = 26 04 00 00 0f a1 # = 4001 VCID
T001 (VPN ID) = 02 34 56 00 02
T043 (Cisco Vendor Specific) = 2b 0A
S034 (MPLS-EXP-SET) = 22 05 # MPLSEXP-INGRESS= 5

T001 (VPN ID) = 02 34 56 00 03
S008 (Vendor ID) = 00 00 0c
# Vendor ID = "00 00 0C" - CISCO
S034 (MPLS-EXP-SET) = 22 06
# MPLSEXP-INGRESS= 6
763

T001 (VPN ID) = 02 34 56 00 04
S008 (Vendor ID) = 00 00 0c
# Vendor ID = "00 00 0C" - CISCO
S034 (MPLS-EXP-SET) = 22 04
# MPLSEXP-INGRESS= 4
T02 (IEEE 802.1Q VLAN ID) = 7d 00
T02 (IEEE 802.1Q VLAN ID) = bb 80
T02 (IEEE 802.1Q VLAN ID) = fa 00
T02 (IEEE 802.1Q VLAN ID) = 7d 00
T001 (VPN ID) = 02 34 56 00 02
T043 (Cisco Vendor Specific) = 2b 0B
S035 (MPLS-EXP_RANGE) = 23 02 03 # MPLSEXP-EGRESS_RANGE= 2 - 3
T02 (IEEE 802.1Q VLAN ID) = bb 80
T001 (VPN ID) = 02 34 56 00 03
764
S035 (MPLS-EXP-RANGE) = 23 04 05 # MPLSEXP-EGRESS_RANGE= 4 - 5

S05 (Rule Priority = 3
T02 (IEEE 802.1Q VLAN ID) = fa 00
T001 (VPN ID) = 02 34 56 00 04
S035 (MPLS-EXP-RANGE) = 23 00 01 # MPLSEXP-EGRESS_RANGE= 0 - 1


The following example shows a CM configuration file-based provisioning of a Type-5 MPLS pseudowire:

T001 (VPN ID) = 02 34 56 00 02 # VPN-ID = "0234560002"
S036 (MPLSPWTYPE) = 24 01 05 # MPLSPWTYPE= Type5 - Ethernet-Port Type
S038 (MPLSVCID) = 26 04 00 00 07 d1 # = 2001 VCID
45 (L2VPN CMIM) = 02 04 ff ff ff ff 01 01 01
T001 (VPN ID) = 02 34 56 00 02 # VPN-ID = "0234560002"
S034 (MPLS-EXP-SET) = 22 04 # MPLS-EXP-SET at INGRESS= 4
Configuration Examples for L2VPN Pseudowire Redundancy

The following sections provide L2VPN pseudowire redundancy configuration examples using the CM
configuration file:
Example: Configuring Backup Pseudowire Peer and VC ID

The following example shows how to provision a file-based backup peer router based on the CM configuration:
765
Example: Configuring Backup Delay
PE Router 1
cable l2vpn 0025.2e2d.7252

service instance 1 ethernet
encapsulation default
xconnect 10.76.2.1 400 encapsulation mpls
backup peer 10.76.2.1 600 priority 4
PE Router2
cable l2vpn 0011.0011.0011

backup peer 10.3.3.3 33 priority 2
backup delay 10 10
Example: Configuring Backup Delay

The following example shows how to configure a backup delay to determine how much time should elapse
before a secondary line status change after a primary line status has been changed.
cable l2vpn 0011.0011.0011

backup delay 10 10
Example: L2VPN Backup MPLS Pseudowire Provisioning Using the CM Configuration File
The following example shows how to provision an L2VPN Backup MPLS pseudowire based on the CM
configuration file:

S005 (Unknown sub-type) = 01 04 32 30 32 30 02 07 04 05 01 0a 4c 02 01 2b 15 26 04
00 00 00 14 28 10 01 05 01 0a 4c 02 01 03 04 00 00 07 08 04 01 05 28 0d 01 05 01 0a 4c 02
03 03 04 00 00 00 15 28 10 01 05 01 0a 4c 02 01 03 04 00 00 b1 8e 04 01 01 29 01 03 2a 01
01
S08 (Max Sustained Traffic Rate) = 2000000
S09 (Max Traffic Burst) = 3200
S15 (Service Flow Sched Type) = 2
T005 (Unknown sub-type) = 01 04 32 30 32 30
S08 (Max Sustained Traffic Rate) = 3000000
S09 (Max Traffic Burst) = 250000
766
Verifying the MPLS Pseudowire Configuration

Use the following show commands to verify the MPLS pseudowire configuration:
• show mpls ldp discovery
• show cable l2-vpn xconnect
• show xconnect
• show mpls l2transport vc
To verify the mapping between the MPLS pseudowire and virtual circuits for all cable modems, use the show
cable l2-vpn xconnect command as shown in the following example:
Router# show cable l2-vpn xconnect mpls-vc-map

MAC Address Peer IP Address VCID Type Prio CktID Cable Intf SID Customer Name/VPNID
0023.bee1.eb48 123.1.1.1 30 Prim* Bu254:4101 Cable3/0/0 3
38c8.5cac.4a62 123.1.1.1 20 Prim* Bu254:4100 Cable3/0/0 4 customer1
602a.d083.2e1c 123.1.1.1 60 Prim* Bu254:4102 Cable3/0/0 5
To verify the mapping between the MPLS pseudowire and virtual circuits for all cable modems when
pseudowire redundancy is not configured, use the show cable l2-vpn xconnect mpls-vc-map command as

0025.2e2d.7252 10.76.2.1 400 Prim* Bu254:400 Cable8/0/3 1
0014.f8c1.fd46 10.2.3.4 1000 Prim* Bu254:1000 Cable8/0/0 1 2020
0014.f8c1.fd46 10.76.2.1 1800 Prim* Bu254:1800 Cable8/0/0 1 2021
To verify the mapping between the MPLS pseudowire and virtual circuits for all cable modems when
pseudowire redundancy is configured, use the show cable l2-vpn xconnect mpls-vc-map command as shown

602a.d083.2e1c 123.1.1.1 60 Prim* Bu254:4102 Cable3/0/0 5
38c8.5cac.4a62 123.1.1.1 20 Prim* Bu254:4103 Cable3/0/0 4 000232303230
156.1.3.1 30 Bkup 3 Bu254:4103
123.1.1.1 50 Bkup 8 Bu254:4103
38c8.5cac.4a62 156.1.3.1 56 Prim* Bu254:4104 Cable3/0/0 4 000232303231
123.1.1.1 40 Bkup 1 Bu254:4104
To obtain the state of all virtual circuits associated with an MPLS pseudowire when pseudowire redundancy
is not configured, use the show cable l2-vpn xconnect mpls-vc-map state command as shown in the following
example:
Router# show cable l2-vpn xconnect mpls-vc-map state

MAC Address Peer IP Address VCID Type Prio State Customer Name/VPNID State
602a.d083.2e1c 123.1.1.1 60 Prim* UP UP
38c8.5cac.4a62 123.1.1.1 20 Prim* UP 000232303230 UP
38c8.5cac.4a62 156.1.3.1 56 Prim* UP 000232303231 UP
767
To obtain the state of all virtual circuits associated with an MPLS pseudowire when pseudowire redundancy
is configured, use the show cable l2-vpn xconnect mpls-vc-map state command as shown in the following
example:
Router# show cable l2-vpn xconnect mpls-vc-map state

602a.d083.2e1c 123.1.1.1 60 Prim* UP UP
38c8.5cac.4a62 123.1.1.1 20 Prim* UP 000232303230 UP
156.1.3.1 30 Bkup 3 UP 000232303230 STDBY
123.1.1.1 50 Bkup 8 DOWN 000232303230 STDBY
38c8.5cac.4a62 156.1.3.1 56 Prim* UP 000232303231 UP
123.1.1.1 40 Bkup 1 UP 000232303230 STDBY
When the local state of the modem is DOWN, the L2VPN is not configured on the WAN interface
and the remote state of the L2VPN will be shown as OFF.
Router#show cable l2-vpn xconnect mpls-vc-map state

602a.d083.2e1c 123.1.1.1 60 Prim* OFF DOWN
38c8.5cac.4a62 123.1.1.1 20 Prim* UP 000232303230 UP
38c8.5cac.4a62 156.1.3.1 56 Prim* UP 000232303231 UP
To verify information about the MPLS pseudowire mapping for a particular MAC address of a CM when
pseudowire redundancy is configured, use the show cable l2-vpn xconnect mpls-vc-map command as shown
Router# show cable l2-vpn xconnect mpls-vc-map 0025.2e2d.7252

0025.2e2d.7252 10.76.2.1 400 Prim* Bu254:400 Cable8/0/3 1
10.76.2.1 600 Bkup 4 Bu254:600
To verify the detailed information about the MPLS pseudowire mapping for a CM when pseudowire redundancy
is configured, use the show mpls l2-vpn xconnect mpls-vc-map verbose command as shown in the following
examples.
The following example shows the information for a modem for which pseudowires were configured using
backup peer command:
Router# show cable l2-vpn xconnect mpls-vc-map 0025.2e2d.7252 verbose

MAC Address : 0025.2e2d.7252
Customer Name :
Prim Sid : 1
MPLS-EXP : 0
PW TYPE : Ethernet
Backup enable delay : 0 seconds
Backup disable delay : 0 seconds
Primary peer
Peer IP Address (Active) : 10.76.2.1
XConnect VCID : 400
Circuit ID : Bu254:400
Local State : UP
Remote State : UP
Backup peers
Peer IP Address : 10.76.2.1
XConnect VCID : 600
Local State : STDBY
Remote State : UP
Priority : 4
768
Total US pkts : 0
Total US bytes : 0
Total US pkts discards : 0
Total US bytes discards : 0
Total DS pkts : 0
Total DS bytes : 0
Total DS pkts discards : 0
Total DS bytes discards : 0
The following example shows the information for a modem for which pseudowires were created using the
modem configuration file:
Router# show cable l2-vpn xconnect mpls-vc-map 0014.f8c1.fd46 verbose

MAC Address : 0014.f8c1.fd46
Prim Sid : 3
L2VPNs provisioned : 1
DUT Control/CMIM : Disable/0x8000FFFF
VPN ID : 2020
L2VPN SAID : 12289
Upstream SFID Summary : 15
Downstream CFRID[SFID] Summary : Primary SF
CMIM : 0x60
PW TYPE : Ethernet
MPLS-EXP : 0
Backup enable delay : 3 seconds
Backup disable delay : 1 seconds
Primary peer
Peer IP Address (Active) : 10.2.3.4
XConnect VCID : 1000
Local State : UP
Remote State : UP
Backup peers
XConnect VCID : 21
Local State : STDBY
Remote State : DOWN
Priority : 2
Local State : STDBY
Remote State : DOWN
Priority : 5
Local State : STDBY
Remote State : DOWN
To verify information about all attachment circuits and pseudowires for online modems, use the show xconnect
Router# show xconnect all

Legend: XC ST=Xconnect State S1=Segment1 State S2=Segment2 State
UP=Up DN=Down AD=Admin Down IA=Inactive
SB=Standby RV=Recovering NH=No Hardware
XC ST Segment 1 S1 Segment 2 S2
769
------+---------------------------------+--+---------------------------------+--
UP ac Bu254:2001(DOCSIS) UP mpls 10.76.1.1:2001 UP
DN ac Bu254:22(DOCSIS) UP mpls 101.1.0.2:22 DN
To verify information about MPLS virtual circuits and static pseudowires that have been enabled to route
Layer 2 packets on a Cisco CMTS router, use the show mpls l2transport vc command as shown in the
following example:
Router# show mpls l2transport vc

Local intf Local circuit Dest address VC ID Status
------------- -------------------------- --------------- ---------- ----------
Bu254 DOCSIS 2002 10.76.1.1 2002 UP
Bu254 DOCSIS 2003 10.76.1.1 2003 UP
Bu254 DOCSIS 2004 10.76.1.1 2004 DOWN
Bu254 DOCSIS 2017 10.76.1.1 2017 UP
Bu254 DOCSIS 2018 10.76.1.1 2018 UP
Bu254 DOCSIS 2019 10.76.1.1 2019 UP
Standards
Standard Title
CM-SP-L2VPN-I08-080522 Business Services over DOCSIS (BSOD) Layer 2 Virtual Private Networks
L2VPN-N-10.0918-2 L2VPN MPLS Update
MIBs
MIB MIBs Link
• DOCS-L2VPN-MIB To locate and download MIBs for selected platforms, Cisco IOS releases,
• CISCO-IETF-PW-MIB and feature sets, use Cisco MIB Locator found at the following URL:
• CISCO-CABLE-L2VPN-MIB http://tools.cisco.com/ITDIT/MIBS/servlet/index
RFCs
RFC Title
RFC 3985 Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture
RFC 4385 Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over an MPLS PSN
RFC 4446 IANA Allocations for Pseudowire Edge-to-Edge Emulation (PWE3)
RFC 4447 Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)
RFC 4448 Encapsulation Methods for Transport of Ethernet over MPLS Networks
770
Feature Information for MPLS Pseudowire for Cable L2VPN
RFC Title
RFC 5085 Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires
Description Link


Table 134: Feature Information for MPLS Pseudowire for Cable L2VPN
MPLS Pseudowire for Cable Cisco IOS XE Everest 16.6.1 This feature was integrated into
L2VPN Cisco IOS XE Everest 16.6.1 on
Broadband Routers.
771
772
CHAPTER 52
MPLS VPN Cable Enhancements
This feature module describes the Multiprotocol Label Switching Virtual Private Network (MPLS VPN) and
cable interface bundling features. It explains how to create a VPN using MPLS protocol, cable interfaces,
bundle interfaces and sub bundle interfaces. VPNs can be created in many ways using different protocols.
• Feature Overview, on page 775
• Prerequisites, on page 778
• Configuration Tasks, on page 779
• Feature Information for MPLS VPN Cable Enhancements, on page 789

773
Digital PICs:

Module:

Modules:
line card reload.
774
Feature Overview
Feature Overview
Using MPLS VPN technology, service providers can create scalable and efficient private networks using a
shared hybrid fiber coaxial (HFC) network and Internet protocol (IP) infrastructure.
The cable MPLS VPN network consists of:
• The Multiple Service Operator (MSO) or cable company that owns the physical infrastructure and builds
VPNs for the Internet Service Providers (ISPs) to move traffic over the cable and IP backbone.
• ISPs that use the HFC network and IP infrastructure to supply Internet service to cable customers.
Each ISP moves traffic to and from a subscriber's PC, through the MSO's physical network infrastructure, to
the ISP's network. MPLS VPNs, created in Layer 3, provide privacy and security by constraining the distribution
of a VPN’s routes only to the routers that belong to its network. Thus, each ISP's VPN is insulated from other
ISPs that use the same MSO infrastructure.
An MPLS VPN assigns a unique VPN Routing/Forwarding (VRF) instance to each VPN. A VRF instance
consists of an IP routing table, a derived forwarding table, a set of interfaces that use the forwarding table,
and a set of rules and routing protocols that determine the contents of the forwarding table.
Each PE router maintains one or more VRF tables. It looks up a packet’s IP destination address in the
appropriate VRF table, only if the packet arrived directly through an interface associated with that table.
MPLS VPNs use a combination of BGP and IP address resolution to ensure security. See Configuring
Multiprotocol Label Switching.
The table shows a cable MPLS VPN network. The routers in the network are:
• Provider (P) router—Routers in the core of the provider network. P routers run MPLS switching, and do
not attach VPN labels (MPLS label in each route assigned by the PE router) to routed packets. VPN
labels are used to direct data packets to the correct egress router.
• Provider Edge (PE) router— Router that adds the VPN label to incoming packets based on the interface
or subinterface on which they are received. A PE router attaches directly to a CE router. In the MPLS-VPN
approach, each Cisco CMTS router acts as a PE router.
• Customer (C) router—Router in the ISP or enterprise network.
• Customer Edge (CE) router—Edge router on the ISP’s network that connects to the PE router on the
MSO’s network. A CE router must interface with a PE router.
The MPLS network has a unique VPN that exclusively manages the MSOs devices called the management
VPN. It contains servers and devices that other VPNs can access. The management VPN connects the Cisco
CMTS router to a PE router, which connects to management servers such as Cisco Network Registrar (CNR)
and Time of Day (ToD) servers. A PE router connects to management servers and is a part of the management
VPN. Regardless of the ISP they belong to, the management servers serve the Dynamic Host Configuration
Protocol (DHCP), DNS (Domain Name System), and TOD requests coming from PCs or cable modems.
Note When configuring MPLS VPNs, you must configure the first subinterface created as a part of the management
VPN.
775
Feature Overview
Figure 25: MPLS VPN Network
Cable VPN configuration involves an:

• MSO domain that requires a direct peering link to each enterprise network (ISP), provisioning servers
for residential and commercial subscribers, and dynamic DNS for commercial users. The MSO manages
cable interface IP addressing, Data-over-Cable Service Interface Specifications (DOCSIS) provisioning,
CM hostnames, routing modifications, privilege levels, and usernames and passwords.
• ISP or enterprise domain that includes the DHCP server for subscriber or telecommuter host devices,
enterprise gateway within the MSO address space, and static routes back to the telecommuter subnets.
Note Cisco recommends that the MSO assign all addresses to the end user devices and gateway interfaces. The
MSO can also use split management to let the ISP configure tunnels and security.
In an MPLS VPN configuration, the MSO must configure the following:

• CMTS
• P routers
• PE routers
• CE routers
• One VPN per ISP DOCSIS servers for all cable modem customers. The MSO must attach DOCSIS
servers to the management VPN, and make them visible.
The MSO must configure the Cisco CMTS routers that serve the ISP, and remote PE routers connecting to
the ISP, as PE routers in the VPN.
776
Benefits
The MSO must determine the primary IP address range for all cable modems.
The ISP must determine the secondary IP address range for subscriber PCs.
To reduce security breaches and differentiate DHCP requests from cable modems in VPNs or under specific
ISP management, MSOs can use the cable helper-address command in Cisco IOS-XE software. The MSO
can specify the host IP address to be accessible only in the ISP’s VPN. This lets the ISP use its DHCP server
to allocate IP addresses. Cable modem IP address must be accessible from the management VPN.
The MPLS VPN approach of creating VPNs for individual ISPs or customers requires subinterfaces to be
configured on the virtual bundle interface. Each ISP requires one subinterface. The subinterfaces are tied to
the VPN Routing/Forwarding (VRF) tables for their respective ISPs. The first subinterface must be created
on the cable interface bound to the management VPN.
To route a reply from the CNR back to the cable modem, the PE router that connects to the CNR must import
the routes of the ISP VPN into the management VPN. Similarly, to forward management requests (such as
DHCP renewal to CNR) to the cable modems, the ISP VPN must export and import the appropriate management
VPN routes.
You can group all of the cable interfaces on a Cisco CMTS router into a single bundle so that only one subnet
is required for each router. When you group cable interfaces, no separate IP subnet or each individual cable
interface is required. This grouping avoids the performance, memory, and security problems in using a bridging
solution to manage subnets, especially for a large number of subscribers.
Subinterfaces allow traffic to be differentiated on a single physical interface, and assigned to multiple VPNs.
You can configure multiple subinterfaces, and associate an MPLS VPN with each subinterface. You can split
a single physical interface (the cable plant) into multiple subinterfaces, where each subinterface is associated
with a specific VPN. Each ISP requires access on a physical interface and is given its own subinterface. Create
a management subinterface to support cable modem initialization from an ISP.
Using each subinterface associated with a specific VPN (and therefore, ISP) subscribers connect to a logical
subinterface, which reflects the ISP that provides their subscribed services. When properly configured,
subscriber traffic enters the appropriate subinterface and VPN.
Benefits
• MPLS VPNs give cable MSOs and ISPs a manageable way of supporting multiple access to a cable
plant. Service providers can create scalable and efficient VPNs across the core of their networks. MPLS
VPNs provide systems support scalability in cable transport infrastructure and management.
• Each ISP can support Internet access services from a subscriber’s PC through an MSO’s physical cable
plant to their networks.
• MPLS VPNs allow MSOs to deliver value-added services through an ISP, and thus, deliver connectivity
to a wider set of potential customers. MSOs can partner with ISPs to deliver multiple services from
multiple ISPs and add value within the MSO’s own network using VPN technology.
• Subscribers can select combinations of services from various service providers.
• The MPLS VPN cable features set build on CMTS DOCSIS 1.0 and DOCSIS 1.0 extensions to ensure
services are reliably and optimally delivered over the cable plant. MPLS VPN provides systems support
domain selection, authentication per subscriber, selection of QoS, policy-based routing, and ability to
reach behind the cable modem to subscriber end devices for QoS and billing while preventing session
spoofing.
• MPLS VPN technology ensures both secure access across the shared cable infrastructure and service
integrity.
777
Restrictions
• Cable interface bundling eliminates the need for an IP subnet on each cable interface. Instead, an IP
subnet is only required for each cable interface bundle. All cable interfaces in a Cisco CMTS router can
be added to a single bundle.
Restrictions
• Each subinterface on the CMTS requires an address range from the ISP and from the MSO. These two
ranges must not overlap and must be extensible to support an increased number of subscribers for
scalability.
Note This document does not address allocation and management of MSO and ISP IP addresses. See Configuring
Multiprotocol Label Switching for this information.
• The cable source-verify dhcp command enables Dynamic Host Control Protocol (DHCP) Lease query
protocol from the CMTS to DHCP server to verify IP addresses of upstream traffic, and prevent MSO
customers from using unauthorized, spoofed, or stolen IP addresses.
• When using only MPLS VPNs, create subinterfaces on the virtual bundle, assign it an IP address, and
provide VRF configuration for each ISP. When you create subinterfaces and configure only MPLS VPNs,
the cable interface bundling feature is independent of the MPLS VPN.
• When using cable interface bundling:
• Define a virtual bundle interface and associate any cable physical interface to the virtual bundle.
• Specify all generic IP networking information (such as IP address, routing protocols, and switching
modes) on the virtual bundle interface. Do not specify generic IP networking information on bundle
subsidiary interfaces.
• An interface that has a subinterface(s) defined over it is not allowed to be a part of the bundle.
• Specify generic (not downstream or upstream related) cable interface configurations, such as
source-verify or ARP handling, on the virtual bundle interface. Do not specify generic configuration
on bundle subsidiary interfaces.
• Interface bundles can only be configured using the command line interface (including the CLI-based
HTML configuration).
Prerequisites
Before configuring IP-based VPNs, complete the following tasks:
• Ensure your network supports reliable broadband data transmission. Your plant must be swept, balanced,
and certified based on National Television Standards Committee (NTSC) or appropriate international
cable plant recommendations. Ensure your plant meets all DOCSIS or European Data-over-Cable Service
Interface Specifications (EuroDOCSIS) downstream and upstream RF requirements.
• Ensure your Cisco router is installed following instructions in the Hardware Installation Guide and the
Regulatory Compliance and Safety Information guide.
• Ensure your Cisco router is configured for basic operations.
778
Other Important Information
• The chassis must contain at least one port adapter to provide backbone connectivity and one Cisco cable
modem card to serve as the RF cable TV interface.
Other Important Information

• Ensure all other required headend or distribution hub routing and network interface equipment is installed,
configured, and operational based on the services to support. This includes all routers, servers (DHCP,
TFTP, and ToD), network management systems, other configuration or billing systems and backbone,
and other equipment to support VPN.
• Ensure DHCP and DOCSIS configuration files have been created and pushed to appropriate servers such
that each cable modem, when initialized, can transmit a DHCP request, receive an IP address, obtain
TFTP and ToD server addresses, and download a DOCSIS configuration file. Configure each subinterface
to connect to the ISP’s VPN.
• Ensure DOCSIS servers are visible on the management VPN.
• Be familiar with your channel plan to assign appropriate frequencies. Outline your strategies for setting
up bundling or VPN solution sets if applicable to your headend or distribution hub. Obtain passwords,
IP addresses, subnet masks, and device names as appropriate.
• Create subinterfaces off of a virtual bundle interface. Configure each subinterface to connect to the ISP
network.
The MPLS VPN configuration steps assume the following:
• IP addressing has already been determined and there are assigned ranges in the MSO and ISP network
for specific subinterfaces.
• The MSO is using CNR and has configured it (using the cable helper-address command) to serve
appropriate IP addresses to cable modems based on the cable modem MAC address. The CMTS forwards
DHCP requests to the CNR based on the cable helper-address settings. The CNR server determines the
IP address to assign the cable modem using the client-classes feature, which let the CNR assign specific
parameters to devices based on MAC addresses.
• ISP CE routers are configured (using the cable helper-address command) to appropriately route relevant
IP address ranges into the VPN.
• P and PE routers are already running Cisco Express Forwarding (CEF).
• MPLS is configured on the outbound VPN using the tag switching ip command in interface configuration
mode.
Configuration Tasks
To configure MPLS VPNs, perform the following tasks:
Creating VRFs for each VPN

To create VRFs for each VPN, perform the following steps beginning in the router configuration mode.
Note Since only the CMTS has logical subinterfaces, assignments of VRFs on the other PE devices will be to
specific physical interfaces.
779
Creating VRFs for each VPN
Procedure

Step 1 Router(config)# vrf definition mgmt-vpn Enters VRF configuration mode (config-vrf)# and maps a
VRF table to the VPN (specified by mgmt-vpn ). The
management VPN is the first VPN configured.
Step 2 Router(config-vrf)# rd mgmt-rd Creates a routing and forwarding table by assigning a route
distinguisher to the management VPN.
Step 3 Router(config-vrf)# route-target {export| import| both} Exports and/or imports all routes for the management
mgmt-rd VPNs route distinguisher. This determines which routes
will be shared within VRFs.
Step 4 Router(config-vrf)# route-target import isp1-vpn-rd Imports all routes for the VPNs (isp1-vpn) route
distinguisher.
distinguisher.
Step 6 Router(config-vrf)# vrf definition isp1-vpn Creates a routing and forwarding table by assigning a route
distinguisher to isp1-vpn .
Step 7 Router(config-vrf)# rd mgmt-rd Creates a routing and forwarding table by assigning a route
distinguisher (mgmt-rd) to the management VPN
(mgmt-vpn).
Step 8 Router(config-vrf)# route-target export isp1-vpn-rd Exports all routes for the VPNs (isp1-vpn) route
distinguisher.
distinguisher.
Step 10 Router(config-vrf)# route-target import mgmt-vpn-rd Exports all routes for the VPNs (mgmt-vpn) route
distinguisher.
Step 11 Router(config-vrf)# vrf definition isp2-vpn Creates a routing and forwarding table by assigning a route
distinguisher to isp2-vpn .
Step 12 Router(config-vrf)# route-target export isp2-vpn-rd Exports all routes for the VPNs (isp2-vpn) route
distinguisher.
distinguisher.
Step 14 Router(config-vrf)# route-target import mgmt-vpn-rd Imports all routes for the VPNs (mgmt-vpn) route
distinguisher.
780
Defining Subinterfaces on a Virtual Bundle Interface and Assigning VRFs
Defining Subinterfaces on a Virtual Bundle Interface and Assigning VRFs

To create a logical cable subinterface, perform the following steps beginning in the global configuration mode.
Create one subinterface for each VPN (one per ISP). The first subinterface created must be configured as part
of the management VPN (with the lowest subinterface number).
Procedure

Step 1 Router# configure terminal Enters configuration mode.
Step 2 Router(config)# interface bundle n.x Enters virtual bundle interface configuration mode and
defines the first (management) subinterface with the lowest
subinterface number.
Step 3 Router(config-subif)# description string Identifies the subinterface as the management subinterface.
Step 4 Router(config-subif)# vrf forwarding mgmt-vpn Assigns the subinterface to the management VPN (the
MPLS VPN used by the MSO to supply service to
customers).
Step 5 Router(config-subif)# ip address ipaddress mask Assigns the subinterface an IP address and a subnet mask.
Step 6 Router(config-subif)# cable helper-address ip-address Forwards DHCP requests from cable modems to the IP
cable-modem address listed.
Step 7 Router(config-subif)# cable helper-address ip-address Forwards DHCP requests from hosts to the IP address
host listed.
Step 8 Router(config-if)# interface bundle n.x Defines an additional subinterface for the ISP (such as
isp1).
Step 9 Router(config-subif)# description string Identifies the subinterface (such as subinterface for
isp1-vpn) .
Step 10 Router(config-subif)# vrf forwarding isp1-vpn Assigns the subinterface to isp1-vpn VPN.
host listed.
Step 14 Router(config-if)# interface bundle n.x Defines an additional subinterface for the ISP (such as
isp2).
Step 15 Router(config-subif)# description string Identifies the subinterface (such as subinterface for
isp2-vpn) .
Step 16 Router(config-subif)# vrf forwarding isp2-vpn Assigns the subinterface to isp2-vpn VPN.
781
Configuring Cable Interface Bundles

host listed.
Step 20 Router(config)# exit Returns to configuration mode.
Configuring Cable Interface Bundles

To assign a cable interface to a bundle, perform the following steps beginning in the interface configuration
mode.
Procedure

Step 1 Router(config)# interface cable slot/port Enters the cable interface configuration mode.
IP addresses are not assigned to this interface. They are
assigned to the logical subinterfaces created within this
interface.
Step 2 Router(config-if)# cable bundlebundle-number Defines the interface as the bundle interface.
Step 3 Router(config)# interface cable slot/subslot/port Enters the cable interface configuration mode for another
cable interface.
IP addresses are not assigned to this interface. They are
assigned to the logical subinterfaces created within this
interface.
Step 4 Router(config-if)# cable bundle bundle-number Adds the interface to the bundle specified by bundle-number
.
Configuring Subinterfaces and MPLS VPNs on a Virtual Bundle Interface

To configure subinterfaces on a virtual bundle interface and assign each subinterface a Layer 3 configuration:
Configure cable interface bundles.
Define subinterfaces on the virtual bundle interface and assign a Layer 3 configuration to each subinterface.
Create one subinterface for each customer VPN (one per ISP).
Configuring MPLS in the P Routers in the Provider Core

To configure MPLS in the P routers in the provider core, perform the following steps.
782
Verifying the MPLS VPN Configuration
Procedure

Step 1 Router# configure terminal Enters configuration mode.
Step 2 Router(config)#ip cef Enables Cisco Express Forwarding (CEF) operation.

For information about CEF configuration and command
syntax, see Cisco Express Forwarding Overview and
Configuring Cisco Express Forwarding.
Step 3 Router(config)#interface Tengigabitethernet Enters GigabitEthernet interface configuration mode.

slot/subslot/port
Step 4 Router(config-if)#ip address ip-address mask Defines the primary IP address range for the interface.
Step 5 Router(config-if)#mpls ip Enables the interface to be forwarded to an MPLS packet.
Step 6 Router(config-if)#exit Returns to global configuration mode.
Step 7 Router(config)#mpls label-protocol ldp Enables Label Distribution Protocol (LDP).

For information about LDP and MPLS, see Configuring
Multiprotocol Label Switching.
Step 8 Router(config)# exit Returns to the configuration mode.
Verifying the MPLS VPN Configuration

Use the following commands to verify MPLS VPN operations on PE routers. For more MPLS VPN verification
commands, see Configuring Multiprotocol Label Switching.
Procedure

Step 1 Router# show ip vrf Displays the set of VRFs and interfaces.
Step 2 Router# show ip route vrf [vrf-name] Displays the IP routing table for a VRF.
Step 3 Router# show ip protocols vrf [vrf-name] Displays the routing protocol information for a VRF.
Step 4 Router# show ip route vrf vrf-name Displays the Local and Remote CE devices that are in the
PE routing table.
Step 5 Router# show mpls forwarding-table Displays entries for a VPN Routing/Forwarding instance.
What to do next
For more verification instructions, see the MPLS: Layer 3 VPNs Configuration Guide.
783
VRF Definition Configuration

vrf definition Basketball
rd 100:2
route-target export 100:2
route-target import 100:0
!
address-family ipv4
exit-address-family
!
address-family ipv6
exit-address-family
vrf definition Football
rd 100:1
!
address-family ipv4
exit-address-family
!
address-family ipv6
exit-address-family
vrf definition MGMT
rd 100:0
!
address-family ipv4
exit-address-family
!
address-family ipv6
exit-address-family
vrf definition Mgmt-intf
!
address-family ipv4
exit-address-family
!
address-family ipv6
exit-address-family
vrf definition Tennis
rd 100:4
!
address-family ipv4
exit-address-family
!
address-family ipv6
exit-address-family
vrf definition Volleyball
rd 100:3
784
Cable Bundle SubInterface Configuration

!
address-family ipv4
exit-address-family
!
address-family ipv6
exit-address-family
Cable Bundle SubInterface Configuration

interface Bundle255
description Bundle Master Interface
no ip address
cable arp filter request-send 3 2
cable arp filter reply-accept 3 2
interface Bundle255.1
description Management Interface
vrf forwarding MGMT
ip address 112.51.0.1 255.255.0.0
cable helper-address 20.11.0.162
ipv6 address 2001:100:112:B001::1/64
vrf forwarding Basketball
ip address 112.54.0.1 255.255.0.0 secondary
ip address 112.53.0.1 255.255.0.0
ipv6 address 2001:100:112:B003::1/64
ipv6 address 2001:100:112:B004::1/64
vrf forwarding Football
ip address 112.55.0.1 255.255.0.0
ipv6 address 2001:100:112:B005::1/64
ipv6 address 2001:100:112:B006::1/64
vrf forwarding Volleyball
ip address 112.57.0.1 255.255.0.0
ipv6 address 2001:100:112:B007::1/64
ipv6 address 2001:100:112:B008::1/64
vrf forwarding Tennis
ip address 112.59.0.1 255.255.0.0
ipv6 address 2001:100:112:B009::1/64
ipv6 address 2001:100:112:B00A::1/64
785
PE WAN Interface Configuration
PE WAN Interface Configuration

mpls label protocol ldp
mpls ldp nsr
mpls ldp graceful-restart
description WAN connection to cBR8
mtu 4470
ip address 100.6.120.5 255.255.255.252
ip router isis hub
ipv6 address 2001:100:6:120::5:1/112
ipv6 enable
mpls ip
mpls traffic-eng tunnels
cdp enable
isis circuit-type level-1
isis network point-to-point
isis csnp-interval 10
hold-queue 400 in
ip rsvp bandwidth 1000000
end
PE BGP Configuration
router bgp 100
bgp router-id 100.120.120.120
bgp log-neighbor-changes
bgp graceful-restart restart-time 120
bgp graceful-restart stalepath-time 360
bgp graceful-restart
timers bgp 5 60
neighbor 100.100.4.4 remote-as 100
neighbor 100.100.4.4 ha-mode sso
neighbor 100.100.4.4 update-source Loopback0
neighbor 100.100.4.4 ha-mode graceful-restart
!
address-family ipv4
redistribute connected
redistribute static route-map static-route
redistribute rip
neighbor 100.100.4.4 activate
neighbor 100.100.4.4 send-community extended
neighbor 100.100.4.4 next-hop-self
neighbor 100.100.4.4 soft-reconfiguration inbound
maximum-paths ibgp 2
exit-address-family
!
address-family vpnv4
exit-address-family
!
address-family ipv6
redistribute rip CST include-connected
redistribute static metric 100 route-map static-route-v6
neighbor 100.100.4.4 send-label
786
PE BGP Configuration
exit-address-family
!
address-family vpnv6
exit-address-family
!
address-family ipv4 vrf Basketball
exit-address-family
!
address-family ipv6 vrf Basketball
redistribute static metric 100
exit-address-family
!
address-family ipv4 vrf Football
exit-address-family
!
address-family ipv6 vrf Football
redistribute static metric 100
exit-address-family
!
address-family ipv4 vrf MGMT
exit-address-family
!
address-family ipv6 vrf MGMT
exit-address-family
!
address-family ipv4 vrf Tennis
redistribute rip
exit-address-family
!
address-family ipv6 vrf Tennis
exit-address-family
!
address-family ipv4 vrf Volleyball
redistribute rip
exit-address-family
!
address-family ipv6 vrf Volleyball
exit-address-family
787
Standards
Standard Title
DOCSIS 1.0 DOCSIS 1.0
MIBs
MIB MIBs Link
CISCO-DOCS-REMOTE-QUERY.my To locate and download MIBs for selected platforms, Cisco IOS
releases, and feature sets, use Cisco MIB Locator found at the
following URL:
RFCs
RFC Title
RFC A Border Gateway Protocol

1163
RFC Application of the Border Gateway Protocol in the Internet

1164
RFC Multiprotocol Extensions for BGP-4

2283
RFC BGP/MPLS VPNs

2547
RFC DOCSIS OSSI Objects Support

2233
RFC Cable Device MIB

2669
788
Feature Information for MPLS VPN Cable Enhancements
Description Link


Table 136: Feature Information for MPLS VPN Cable Enhancements
Multiprotocol Label Switching Cisco IOS XE Everest 16.6.1 This feature was integrated into
Virtual Private Network (MPLS Cisco IOS XE Everest 16.6.1 on
VPN) the Cisco cBR Series Converged
Broadband Router.
789
790
CHAPTER 53
Multicast VPN and DOCSIS 3.0 Multicast QoS
Support
The CMTS enhanced multicast new features are consistent with DOCSIS 3.0 specifications and include:
• Enhanced multicast echo in which the Layer 3 multicast switching path uses a Cisco Packet Processor
(CPP) parallel express forwarding multicast routing table.
• Enhanced multicast quality of service (MQoS) framework that specifies a group configuration (GC) to
define a session range of multicast addresses and rule priorities and its associated multicast VPN (MVPN).
• Intelligent multicast admission control to include multicast service flows.
• Enhanced multicast VPN feature to configure and support multicast traffic in a multiprotocol label
switching (MPLS)-VPN environment.

• Restrictions for the Multicast VPN and DOCSIS 3.0 Multicast QoS Support, on page 793
• Information About the Multicast VPN and DOCSIS 3.0 Multicast QoS Support, on page 793
• How to Configure the Multicast VPN and DOCSIS 3.0 Multicast QoS Support, on page 795
• Configuration Examples for the Multicast VPN and DOCSIS 3.0 Multicast QoS Support, on page 799
• Feature Information for Multicast VPN and DOCSIS3.0 Multicast QoS Support, on page 801

791
Digital PICs:

Module:

Modules:
792
Restrictions for the Multicast VPN and DOCSIS 3.0 Multicast QoS Support
line card reload.
Restrictions for the Multicast VPN and DOCSIS 3.0 Multicast

QoS Support
The type of service (ToS) parameter is not recognized by the Cisco cBR series routers.
To avail 40000 multicast sessions, a minimum of one bundle should be present for each LC.
Information About the Multicast VPN and DOCSIS 3.0 Multicast

QoS Support
IP multicast—transmission of the same information to multiple cable network recipients—improves bandwidth
efficiency and allows service providers to offer differentiated quality of service for different types of traffic.
Enhanced multicast introduces multicast improvements as mandated by the introduction of DOCSIS 3.0
specifications.
Note DOCSIS 3.0 standards retain backwards compatibility with the DOCSIS 2.0 multicast mode of operation.
The Cisco cBR routers support 40000 DSG multicast sessions per chassis.
The following are the benefits of CMTS enhanced multicast are:
Enhanced Quality of Service

In the new multicast QoS (MQoS) framework, you can specify a group configuration (GC) that defines a
session range of multicast addresses and rule priorities and its associated multicast VPN (MVPN). For every
GC, there is attached a group QoS configuration (GQC) and a group encryption rule.
Based on the session range, rule priority, and MVPN, a multicast service flow is admitted into a GC and the
associated GQC and group encryption rule are applied to the flow. In MQoS implementation, the source
address of the multicast session is not checked because the current implementation for cable-specific multicast
supports IGMP Version 2 but not IGMP Version 3. The downstream service flow, service identifier (SID),
and MAC-rewrite string are created at the time of a new IGMP join (or static multicast group CLI on the
interface) and MQoS is applied to the new multicast group join.
The benefits of enhanced QoS are the following:
• Group classifiers can be applied at cable interface level and also at bundle interface level.
793
Intelligent Multicast Admission Control
• Group service flow (GSF) definition is based on service class names. The GSF is similar to individual
service flows and commonly includes the minimum rate and maximum rate parameters for the service
class. GSF is shared by all cable modems on a particular downstream channel set (DCS) that is matched
to the same group classifier rule (GCR). A default service flow is used for multicast flows that do not
match to any GCR. A GSF is always in the active state.
• CMTS replicates multicast packets and then classifies them.
• Single-stage replication and two-stage replication are supported.
• Enhanced QoS is compatible and integrated with DOCSIS Set-Top Gateway (DSG).
Intelligent Multicast Admission Control

Admission control allows you to categorize service flows into buckets. Examples of categories are the service
class name used to create the service flow, service flow priority, or the service flow type such as unsolicited
grant service (UGS). Bandwidth limits for each bucket can also be defined. For example, you can define
bucket 1 for high priority packet cable service flows and specify that bucket 1 is allowed a minimum of 30
percent and a maximum of 50 percent of the link bandwidth.
Intelligent multicast admission control includes additional features such as the inclusion of multicast service
flows using the GSF concept. GSFs are created based on the rules as defined in the GQC table. The rules link
the multicast streams to a GSF through the session range. The service class name in the rule defines the QoS
for that GSF. Additionally, another attribute is added to the rules and the group configuration table to specify
the application type to which each GSF belongs. In this way, the QoS associated with each GSF is independent
of the bucket category for the GSF.
The benefits of intelligent multicast admission control are the following:
• There is explicit acknowledgment of the establishment of each multicast session.
• Admission control does not consume additional bandwidth for multicast flows once the first flow is
established.
• Service flows are cleaned up as the multicast session is torn down.
Multicast Session Limit Support

In a multicast video environment, you can limit the number of multicast sessions admitted onto a particular
service flow. The multicast session limit feature—which adds functionality on top of the multicast QoS
infrastructure—enables you to specify the number of multicast sessions to be admitted on a particular service
flow. If the current number of sessions has reached the defined limit, new sessions will be forwarded but they
will make use of the default multicast service flow until a session ends to free up a slot for new sessions.
Multicast Virtual Private Network

The new multicast VPN (MVPN) feature allows you to configure and support multicast traffic in a multiprotocol
label switching (MPLS)-VPN environment. This feature supports routing and forwarding of multicast packets
for each individual VPN virtual routing and forwarding (VRF) instance, and also provides a mechanism to
transport VPN multicast packets across the service provider backbone.
MVPN allows you to connect multiple remote sites or devices over either a Layer 3 or Layer 2 VPN. A Layer
3 VPN enables the routing of traffic inside the VPN. A Layer 2 VPN provides a bridging transport mechanism
for traffic between remote sites belonging to a customer. To support multicast over Layer 3 VPNs, each VPN
receives a separate multicast domain with an associated MVPN routing and forwarding (mVRF) table
maintained by the provider edge (PE) router. In a cable environment, the PE router is a routing CMTS. The
794
How to Configure the Multicast VPN and DOCSIS 3.0 Multicast QoS Support
provider network builds a default multicast distribution tree (default-MDT) for each VPN between all the
associated mVRF-enabled PE routers. This tree is used to distribute multicast traffic to all PE routers.
To enable maximum security and data privacy in a VPN environment, the CMTS distinguishes between
multicast sessions on the same downstream interface that belong to different VPNs. To differentiate multicast
traffic between different VPNs, the CMTS implements a per-VRF subinterface multicast security association
identifier (MSAID) allocation feature that is BPI+ enabled. The MSAID is allocated for each cable bundle
group for each subinterface. A multicast group has a specific MSAID for each VRF instance.
How to Configure the Multicast VPN and DOCSIS 3.0 Multicast

QoS Support
Configuring a QoS Profile for a Multicast Group

To configure a QoS profile that can be applied to a QoS group configuration, use the cable multicast group-qos
command. You must configure a QoS profile before you can add a QoS profile to a QoS multicast group.
Procedure

Router> enable

Example:
Step 3 cable multicast group-qos number scn service-class-name Configures a QoS profile that can be applied to a multicast
control{ single | aggregate [limit max-sessions]} QoS group.
Example: Note If a number is not specified, a default QoS profile
is applied. The default group qos configuration
Router(config)#: cable multicast group-qos 2 scn creates a default multicast service flow for each
name1 control single cable interface that is used when a multicast
session does not match any classifiers of a GC
on the interface.
Configuring a Multicast QoS Group

You can specify a group configuration (GC) that defines a session range of multicast addresses and rule
priorities and its associated multicast VPN (MVPN). For every GC, there is attached a group QoS configuration
and a group encryption rule.
795
Configuring a Multicast QoS Group
Procedure

Router> enable
Step 2 configureterminal Enters global configuration mode.

Example:
Step 3 cable multicast group-qos number scn service-class-name (Optional) Configures a QoS profile that can be applied to
control {single | aggregate [limit max-sessions]} a multicast QoS group.
Example: Note If a number is not specified, a default QoS profile
is applied. The default group qos configuration
Router(config-mqos)# cable multicast group-qos 5 creates a default multicast service flow for each
scn name1 control single cable interface that is used when a multicast
session does not match any classifiers of a GC
on the interface.
Step 4 cable multicast qos group id priority value [global ] Configures a multicast QoS group and enters multicast QoS
configuration mode.
Example:
Router(config)# cable multicast qos group 2

priority 6
Step 5 session-range ip-address ip-mask Specifies the session range IP address and IP mask of the
multicast QoS group. You can configure multiple session
Example:
ranges.
Router(config-mqos)# session-range 224.10.10.10
255.255.255.224
Step 6 tos low-byte high-byte mask (Optional) Specifies the minimum type of service (ToS)
data bytes, maximum ToS data bytes, and mask for a
Example:
multicast QoS group.
Router(config-mqos)# tos 1 6 15
Step 7 vrfname (Optional) Specifies the name for the virtual routing and
forwarding (VRF) instance.
Example:
Note If a multicast QoS (MQoS) group is not defined
Router(config-mqos)# vrf name1 for this VRF, you will see an error message. You
must either define a specific MQoS group for
each VRF, or define a default MQoS group that
can be assigned in those situations where no
matching MQoS group is found. See the
Configuring a Default Multicast QoS Group for
VRF, on page 797.
796
Configuring a Default Multicast QoS Group for VRF

Step 8 application-idnumber (Optional) Specifies the application identification number
of the multicast QoS group. This value is configured to
Example:
enable admission control to the multicast QoS group.
Router(config-mqos)# application-id 25
Configuring a Default Multicast QoS Group for VRF

Each virtual routing and forwarding (VRF) instance that is defined must match a defined MQoS group to
avoid multicast stream crosstalk between VRFs. To avoid potential crosstalk, define a default MQoS group
that is assigned to the VRF whenever the multicast traffic in the VRF does not match an existing MQoS group.
Procedure

Router> enable

Example:
Step 3 cable multicastgroup-qosnumber scnservice-class-name (Optional) Configures a QoS profile that can be applied to
control {single | aggregate [limit max-sessions]} a multicast QoS group.
Example:
Router(config-mqos)# cable multicast group-qos 5

scn name1 control single
Step 4 cable multicast qos group id priority 255 global Configures a default multicast QoS group and enters
multicast QoS configuration mode.
Example:

priority 255 global
Step 5 session-range 224.0.0.0 224.0.0.0 Specifies the session-range IP address and IP mask of the
default multicast QoS group. By entering 224.0.0.0 for the
Example:
IP address and the IP mask you cover all possible multicast
sessions.
224.0.0.0
Step 6 vrfname Specifies the name of the virtual routing and forwarding
(VRF) instance.
Example:
797
Verifying Configuration of the Multicast VPN and DOCSIS 3.0 Multicast QoS Support
Router(config-mqos)# vrf name1
Step 7 application-idnumber (Optional) Specifies the application identification number

of the multicast QoS group. This value is configured to
Example:
enable admission control to the multicast QoS group.
Verifying Configuration of the Multicast VPN and DOCSIS 3.0 Multicast QoS
Support
To verify the configuration of the Multicast VPN and DOCSIS 3.0 Multicast QoS Support feature, use the
show commands described below.
• To show the configuration parameters for multicast sessions on a specific bundle, use the show interface
bundle number multicast-sessions command as shown in the following example:
Router# show interface bundle 1 multicast-sessions

Multicast Sessions on Bundle1
Group Interface GC SAID SFID GQC GEn RefCount GC-Interface State
234.1.1.45 Bundle1.1 1 8193 --- 1 5 1 Bundle1 ACTIVE
Aggregate Multicast Sessions on Bundle1
Aggregate Sessions for SAID 8193 GQC 1 CurrSess 3
Group Interface GC SAID SFID AggGQC GEn RefCount GC-Interface
234.1.1.45 Bundle1.1 1 8193 --- 1 5 1 Bundle1
234.1.1.46 Bundle1.1 1 8193 --- 1 5 1 Bundle1
234.1.1.47 Bundle1.1 1 8193 --- 1 5 1 Bundle1
• To show the configuration parameters for multicast sessions on a specific cable, use the show interface
cable ip-addr multicast-sessions command as shown in the following example:
Router# show interface cable 7/0/0 multicast-sessions

Default Multicast Service Flow 3 on Cable7/0/0
Multicast Sessions on Cable7/0/0
Group Interface GC SAID SFID GQC GEn RefCount GC-Interface State
234.1.1.45 Bundle1.1 1 8193 24 1 5 1 Bundle1 ACTIVE
Aggregate Multicast Sessions on Cable7/0/0
Aggregate Sessions for SAID 8193 SFID 24 GQC 1 CurrSess 3
Group Interface GC SAID SFID AggGQC GEn RefCount GC-Interface
234.1.1.45 Bundle1.1 1 8193 24 1 5 1 Bundle1
234.1.1.46 Bundle1.1 1 8193 24 1 5 1 Bundle1
234.1.1.47 Bundle1.1 1 8193 24 1 5 1 Bundle1
• To show the MSAID multicast group subinterface mapping, use the show interface cable address modem
Router# show interface cable 6/1/0 modem

SID Priv Type State IP address method MAC address Dual
bits IP
9 11 modem online(pt) 101.1.0.6 dhcp 0006.28f9.8c79 N
798
Configuration Examples for the Multicast VPN and DOCSIS 3.0 Multicast QoS Support
9 11 host unknown 111.1.1.45 dhcp 0018.1952.a859 N

10 10 modem online(pt) 101.1.0.5 dhcp 0006.5305.ac19 N
10 10 host unknown 111.1.0.3 dhcp 0018.1952.a85a N
13 10 modem online(pt) 101.1.0.3 dhcp 0014.f8c1.fd1c N
8195 10 multicast unknown 224.1.1.51 static 0000.0000.0000 N
Configuration Examples for the Multicast VPN and DOCSIS 3.0

Multicast QoS Support
Example: Configuring Group QoS and Group Encryption Profiles
Note To add group QoS and group encryption profiles to a QoS group, you must configure each profile first before
configuring the QoS group.
In the following example, QoS profile 3 and encryption profile 35 are configured.
configure terminal
cable multicast group-qos 3 scn name1 control single
cable multicast group-encryption 35 algorithm 56bit-des
Example: Configuring a QoS Group

In the following example, QoS group 2 is configured with a priority of 6 and global application. To QoS group
2, QoS profile 3 and encryption profile 35 are applied. Other parameters are configured for QoS group 2
including application type, session range, ToS, and VRF.
cable multicast qos group 2 priority 6 global

group-encryption 35
group-qos 3
session-range 224.10.10.01 255.255.255.254
tos 1 6 15
vrf vrf-name1
application-id 44
The following sections provide references related to the Multicast VPN and DOCSIS 3.0 Multicast QoS
Support.
799
Related Documents
CMTS cable commands Cisco CMTS Cable Command Reference

http://www.cisco.com/c/en/us/td/docs/cable/cmts/cmd_ref/b_cmts_cable_cmd_ref.html
Standards
Standard Title
No new or modified standards are supported by this feature, and support for existing standards has not —
been modified by this feature.
MIBs
MIB MIBs Link
No new or modified MIBs are supported by this To locate and download MIBs for selected platforms, Cisco
feature, and support for existing MIBs has not IOS releases, and feature sets, use Cisco MIB Locator
been modified by this feature. found at the following URL:
RFCs
RFC Title
RFC 2236 Internet Group Management Protocol, Version 2
Description Link
800
Feature Information for Multicast VPN and DOCSIS3.0 Multicast QoS Support
Feature Information for Multicast VPN and DOCSIS3.0 Multicast

QoS Support
Table 138: Feature Information for Multicast VPN and DOCSIS3.0 Multicast QoS Support
Multicast VPN and DOCSIS3.0 Cisco IOS XE Everest 16.6.1 This feature was integrated into
multicast QoS support Cisco IOS XE Everest 16.5.1 on
Broadband Routers.
801
Feature Information for Multicast VPN and DOCSIS3.0 Multicast QoS Support
802
CHAPTER 54
EtherChannel for the Cisco CMTS
This document describes the features, benefits and configuration of Cisco EtherChannel technology on the
Cisco Cable Modem Termination System (CMTS).
EtherChannel is a technology by which to configure and aggregate multiple physical Ethernet connections to
form a single logical port with higher bandwidth. The first EtherChannel port configured on the Cisco CMTS
serves as the EtherChannel bundle primary by default, and each subsidiary interface interacts with the network
using the MAC address of the EtherChannel bundle primary.
EtherChannel ports reside on a routing or bridging end-point. The router or switch uses EtherChannel to
increase bandwidth utilization in either half- or full-duplex mode, and load balances the traffic across the
multiple physical connections.
EtherChannel on the Cisco CMTS supports inter-VLAN routing with multiple devices and standards, and
supports Ten Gigabit EtherChannel (GEC) on the Cisco cBR series routers.
Contents
• Restrictions for EtherChannel on the Cisco CMTS, on page 805
• Information About EtherChannel on the Cisco CMTS, on page 805
• How to Configure EtherChannel on the Cisco CMTS, on page 806
• Verifying EtherChannel on the Cisco CMTS, on page 808
• Configuration Examples for EtherChannel on the Cisco CMTS, on page 809
• Feature Information for EtherChannel on Cisco CMTS, on page 811
803
Digital PICs:

Module:

Modules:
804
Restrictions for EtherChannel on the Cisco CMTS
line card reload.
Restrictions for EtherChannel on the Cisco CMTS

• EtherChannel on the Cisco CMTS is limited to Network Layer 3 functions, and does not support Data-Link
Layer 2 EtherChannel functions as with certain other Cisco product platforms.
• The Port Aggregation Protocol (PAgP) is not supported on the Cisco CMTS as with other Cisco product
platforms (such as the CatOS switch).
• Only the IEEE 802.1Q trunking protocol is supported on the Cisco CMTS. ATM trunking is not supported
on the Cisco cBR series routers.
• The maximum supported links per bundle is 8.
• EtherChannel on Cisco CMTS supports only physical ports or interfaces that have the same speed.
• EtherChannel on the Cisco cBR series routers does not support MQC QOS. You can use Equal Cost
Multi Path (ECMP) load balancing instead of EtherChannel.
• Layer 3 configurations on member interfaces of EtherChannel are not supported.
• MAC Address Accounting feature on port channel is not supported.
Information About EtherChannel on the Cisco CMTS

Introduction to EtherChannel on the Cisco CMTS

EtherChannel is based on proven industry-standard technology. The Cisco CMTS supports EtherChannel
with several benefits, including the following:
• EtherChannel on the Cisco CMTS supports subsecond convergence times.
• EtherChannel can be used to connect two switch devices together, or to connect a router with a switch.
• A single EtherChannel connection supports a higher bandwidth between the two devices.
• The logical port channels on either Cisco CMTS platform provide fault-tolerant, high-speed links between
routers, switches, and servers.
• EtherChannel offers redundancy and high availability on the Cisco CMTS. Failure of one connection
causes a switch or router to use load balancing across the other connections in the EtherChannel.
• Load balancing on the Cisco CMTS supports dynamic link addition and removal without traffic
interruption.
• EtherChannel supports inter-VLAN trunking. Trunking carries traffic from several VLANs over a
point-to-point link between the two devices. The network provides inter-VLAN communication with
trunking between the Cisco CMTS router and one or more switches. In a campus network, trunking is
805
Cisco Ten Gigabit EtherChannel on the Cisco cBR Series Routers
configured over an EtherChannel link to carry the multiple VLAN information over a high-bandwidth
channel.
Cisco Ten Gigabit EtherChannel on the Cisco cBR Series Routers

Cisco Ten Gigabit EtherChannel (GEC) is high-performance Ethernet technology that provides
gigabit-per-second transmission rates. It provides flexible, scalable bandwidth with resiliency and load sharing
across links for switches, router interfaces, and servers.
Ten GEC on the Cisco cBR series routers with the following EtherChannel capabilities:
• Supports IEEE 802.1Q encapsulation for inter-VLAN networking.
• Supports a maximum of eight physical Ten Gigabit Ethernet ports to be combined as one logical
EtherChannel link.
• Supports bandwidth up to 40 Gbps (half duplex) for a combined total of up to 80 Gbps (full duplex).
How to Configure EtherChannel on the Cisco CMTS

Configuring Ten Gigabit EtherChannel on the Cisco CMTS

Before you begin
• Ten Gigabit Ethernet cabling is completed and the ports are operational on the router and network.
• LAN interfaces are configured and operational on the router and network, with IP addresses and subnet
masks.
Note The Cisco cBR series routers support up to eight physical connectors to be configured as one logical Ten GEC
port.
SUMMARY STEPS
1. enable
3. interface port-channel n
4. exit
5. interface tengigabitethernet slot/subslot/port
6. shutdown
7. Use one of the following commands:
• For static Ten GEC configuration, use the channel-group number command.
• For dynamic Ten GEC configuration, use the channel-group number mode {active | passive}
command.
8. no shutdown
806
Configuring Ten Gigabit EtherChannel on the Cisco CMTS
9. end
DETAILED STEPS

Router> enable

Example:
Step 3 interface port-channel n Creates an EtherChannel interface. The first EtherChannel

interface configured becomes the bundle primary for all
Example:
ports in the EtherChannel group. The MAC address of the
first EtherChannel interface is the MAC address for all
Router(config)# interface port-channel 1
EtherChannel interfaces in the group.
To remove an EtherChannel interface from the
EtherChannel group, use the no form of this command.
If the first EtherChannel interface in the group is later
removed, the second EtherChannel interface in the group
becomes the bundle primary by default.
Repeat this step on every EtherChannel port to be bundled
into a Ten GEC group. This configuration must be present
on all EtherChannel interfaces before the EtherChannel
group can be configured.

configuration mode.
Example:
Step 5 interface tengigabitethernet slot/subslot/port Selects the Ten Gigabit Ethernet interface that you wish to
add as a member EtherChannel link in the EtherChannel
Example:
bundle, and enters interface configuration mode.
Router# interface gigabitethernet 4/1/0 Note We recommend that the link being added to the
Cisco CMTS EtherChannel be shut down prior
to configuring it as a member of the
EtherChannel. Use the shutdown command in
interface configuration mode immediately before
completing the following steps in this procedure.
Step 6 shutdown Shuts down the interface selected in step 5 before

configuring it as a member of the EtherChannel.
Example:
807
Router(config-if)# shutdown
Step 7 Use one of the following commands: Adds the Ten Gigabit Ethernet interface to the EtherChannel
Group, associating that interface with an EtherChannel link.
• For static Ten GEC configuration, use the
channel-group number command. To remove an EtherChannel group and the associated ports
• For dynamic Ten GEC configuration, use the from the Cisco CMTS, use the no form of this command.
channel-group number mode {active | passive}
command.
Example:
Router(config-if)# channel-group 1
or
Router(config-if)# channel-group 1 mode active
Step 8 no shutdown Enables the interface on which EtherChannel is configured.

Example:

Example: IP traffic should be visible on the network with completion
of the above steps.
Router(config# end
Once interface operations are confirmed (prior to this procedure), and EtherChannel configurations have been
verified (next procedure), any difficulty experienced through the EtherChannel links may pertain to inter-VLAN
or IP routing on the network, or perhaps very high bandwidth consumption.
What to Do Next
Additional IP, access list, inter-VLAN or load balancing configurations may be made to the Cisco CMTS and
these changes will be supported in the running EtherChannel configuration without service disruption from
EtherChannel.
Verifying EtherChannel on the Cisco CMTS

Links can be added or removed from an EtherChannel interface without traffic interruption. If an Ethernet
link in an EtherChannel interface fails, traffic previously carried over the failed link switches to the remaining
links within the EtherChannel. There are a number of events that can cause a link to be added or removed
including adding or removing a link using commands and simulating link failure and recovery (as with
(no)shutdown links).
808
Configuration Examples for EtherChannel on the Cisco CMTS
Cisco EtherChannel supports online insertion and removal (OIR) of field-replaceable units (FRUs) in the
Cisco CMTS chassis. Ports that remain active during OIR of one FRU will take over and support the traffic
bandwidth requirements without service disruption. However, OIR is not described in this procedure.
Procedure

Router> enable
Step 2 show interface port-channel n Verifies the EtherChannel configuration on the Cisco CMTS
for the selected EtherChannel group.
Example:
Router# show interface port-channel 1
Configuration Examples for EtherChannel on the Cisco CMTS

The following example illustrates Ten Gigabit EtherChannel information for the port-channel interface of 2.
This configuration is comprised of three Ten GEC port channels as follows:
• Member 0 is the Ten GEC interface bundle primary.
• Member 2 is the final subsidiary interface in this Ten GEC group.
• These three port-channel interfaces (members) comprise one Ten GEC group that is set up with a Ten
GEC peer on the network.
Router# show interface port-channel 2

Port-channel2 is up, line protocol is up
Hardware is GEChannel, address is 8888.8888.8888 (bia 0000.0000.0000)
Internet address is 101.101.101.1/16
MTU 1500 bytes, BW 3000000 Kbit, DLY 10 usec,
Encapsulation ARPA, loopback not set
No. of members in this channel: 3
No. of configured members in this channel: 3
No. of passive members in this channel: 0
No. of active members in this channel: 3
Member 0 : TenGigabitEthernet4/1/0 , Full-duplex, 1000Mb/s
No. of Non-active members in this channel: 0
Last input 00:00:02, output never, output hang never
Queueing strategy: fifo
Output queue: 0/120 (size/max)
30 second input rate 17292000 bits/sec, 9948 packets/sec
30 second output rate 17315000 bits/sec, 9935 packets/sec
809

Received 2 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 0 multicast, 0 pause input
0 input packets with dribble condition detected
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier, 0 pause output
Related Documents

Topic
EtherChannel • Cisco EtherChannel home page

for Cisco
http://www.cisco.com/warp/public/cc/techno/lnty/etty/fsetch/index.shtml
Products
• Cisco EtherChannel Technology white paper
http://www.cisco.com/en/US/tech/tk389/tk213/technologies_white_paper09186a0080092944.shtml
Configuring • Configuring EtherChannel and 802.1Q Trunking Between a Catalyst 2950 and a Router
Additional (inter-VLAN Routing)
Devices for
http://www.cisco.com/c/en/us/support/docs/switches/catalyst-2950-series-switches/24042-158.html
EtherChannel
• Configuring EtherChannel and 802.1Q Trunking Between Catalyst 2900XL/3500XL and Catalyst
2940, 2950/2955, and 2970 Switches
http://www.cisco.com/c/en/us/support/docs/switches/catalyst-2900-xl-series-switches/21041-131.html
Standards and RFCs
Standards Title
IEEE Std 802.1Q, 2003 Edition IEEE Std 802.1Q, 2003 Edition (Incorporates IEEE Std 802.1Q-1998, IEEE
Std 802.1u-2001, IEEE Std 802.1v-2001, and IEEE Std 802.1s-2002)
http://ieeexplore.ieee.org/xpl/tocresult.jsp?isNumber=27089
810
Feature Information for EtherChannel on Cisco CMTS
Description Link
The Cisco Support website provides extensive online resources, http://www.cisco.com/cisco/web/support

including documentation and tools for troubleshooting and resolving
technical issues with Cisco products and technologies.
To receive security and technical information about your products,
you can subscribe to various services, such as the Product Alert
Tool (accessed from Field Notices), the Cisco Technical Services
Newsletter, and Really Simple Syndication (RSS) Feeds.
Access to most tools on the Cisco Support website requires a
Cisco.com user ID and password.

Table 140: Feature Information for EtherChannel on Cisco CMTS
EtherChannel on Cisco CMTS Cisco IOS XE Everest 16.6.1 This feature was integrated into
Broadband Router.
811
812
CHAPTER 55
Flow-Based per Port-Channel Load Balancing
The Flow-Based per Port-Channel Load Balancing feature allows different flows of traffic over a Ten Gigabit
EtherChannel (GEC) interface to be identified based on the packet header and then mapped to the different
member links of the port channel. This feature enables you to apply flow-based load balancing and VLAN-
manual load balancing to specific port channels.
Contents
• Restrictions for Flow-Based per Port-Channel Load Balancing, on page 814
• Information About Flow-Based per Port-Channel Load Balancing, on page 815
• How to Enable Flow-Based per Port-Channel Load Balancing, on page 817
• Verifying Load Balancing Configuration on a Ten GEC Interface, on page 818
• Configuration Examples for Flow-Based per Port-Channel Load Balancing, on page 820
• Feature Information for Flow-Based per Port-Channel Load Balancing, on page 821
813
Restrictions for Flow-Based per Port-Channel Load Balancing
Digital PICs:

Module:

Modules:
line card reload.
Restrictions for Flow-Based per Port-Channel Load Balancing

• Supports up to 64 Ten GEC interfaces.
814
Information About Flow-Based per Port-Channel Load Balancing
• Supports up to 8 member links per Ten GEC interface.

• dot1q L2VPN is not supported over a port-channel with load-balancing vlan configured.
Information About Flow-Based per Port-Channel Load Balancing

Flow-Based Load Balancing
Flow-based load balancing identifies different flows of traffic based on the key fields in the data packet. For
example, IPv4 source and destination IP addressees can be used to identify a flow. The various data traffic
flows are then mapped to the different member links of a port channel. After the mapping is done, the data
traffic for a flow is transmitted through the assigned member link. The flow mapping is dynamic and changes
when there is any change in the state of a member link to which a flow is assigned. The flow mappings can
also change if member links are added to or removed from the GEC interface. Multiple flows can be mapped
to each member link.
Buckets for Flow-Based Load Balancing

Load balancing dynamically maps traffic flows to the member links of a Ten GEC interface through the
concept of buckets. The various defined traffic flows are mapped to the buckets and the buckets are evenly
distributed among the member links. Each port channel maintains 16 buckets, with one active member link
associated with each bucket. All traffic flows mapped to a bucket use the member link to which the bucket is
assigned.
The router creates the buckets-to-member links mappings when you apply flow-based load balancing to a
port channel and the port channel has at least one active member link. The mappings are also created when
the first member link is added, or comes up, and the load-balancing method is set to flow-based.
When a member link goes down or is removed from a port channel, the buckets associated with that member
link are redistributed among the other active member links in a round-robin fashion. When a member link
comes up or is added to a port channel, some of the buckets associated with other links are assigned to this
link.
If you change the load-balancing method, the bucket-to-member link mappings for flow-based load balancing
are deleted. The mappings are also deleted if the port channel is deleted or the last member link in the port
channel is deleted or goes down.
Load Balancing on Port Channels

GEC interfaces can use either dynamic flow-based load balancing or VLAN-manual load balancing. You can
configure the load-balancing method globally for all port channels or directly on specific port channels. The
global configuration applies only to those port channels for which you have not explicitly configured load
balancing. The port-channel configuration overrides the global configuration.
Flow-based load balancing is enabled by default at the global level. You must explicitly configure VLAN
load balancing or the load-balancing method is flow-based.
The table below lists the load-balancing method that is applied to port channels based on the configuration:
815
Load Balancing on Port Channels
Table 142: Flow-Based Load Balancing Configuration Options
Global Configuration Port-Channel Configuration Load Balancing Applied
Not configured Not configured Flow-based
Flow-based Flow-based
VLAN-manual VLAN-manual
VLAN-manual Not configured VLAN-manual
Flow-based Flow-based
VLAN-manual VLAN-manual
The table below lists the configuration that results if you change the global load-balancing method.
Table 143: Results When Global Configuration Changes
Port-Channel Global Configuration Action Taken at

Configuration Port-Channel
— From To —
Not configured Not configured VLAN-manual Changed from flow-based

to VLAN-manual
VLAN-manual Not configured Changed from VLAN-

manual to flow-based
Configured Any Any No change
The table below lists the configuration that results if you change the port-channel load-balancing method.
Table 144: Results When Port-Channel Configuration Changes

— From To —
816
How to Enable Flow-Based per Port-Channel Load Balancing

Not configured Not configured VLAN-manual Changed from flow-based

to VLAN-manual
Not configured Flow-based No action taken
VLAN-manual Flow-based Changed from

VLAN-manual to
flow-based
VLAN-manual Not configured Changed from VLAN-

Flow-based VLAN-manual Changed from flow-based

to VLAN-manual
Flow-based Not configured No action taken
Configured Not configured VLAN-manual No action taken
Not configured Flow-based Changed from VLAN-

VLAN-manual Flow-based Changed from

VLAN-manual to
flow-based
VLAN-manual Not configured No action taken
Flow-based VLAN-manual Changed from flow-based

to VLAN-manual
Flow-based Not configured Changed from flow-based

to VLAN-manual
How to Enable Flow-Based per Port-Channel Load Balancing

Configuring Load Balancing on a Port Channel
To configure load balancing on a port channel, perform the following steps. Repeat these steps for each GEC
interface.
Before you begin

If you have already configured your desired load-balancing method globally and want to use that method for
all port channels, you need not perform this task. To configure load balancing globally, use the port-channel
load-balancing vlan-manual command. If you do not configure the global command, flow-based load
balancing is applied to all port channels.
817
Verifying Load Balancing Configuration on a Ten GEC Interface
SUMMARY STEPS
1. enable
3. interface port-channel channel-number
4. load-balancing {flow | vlan}
5. end
DETAILED STEPS

Router> enable

Example:
Step 3 interface port-channel channel-number Enters interface configuration mode and defines the
interface as a port channel.
Example:
Router(config)# interface port-channel 1
Step 4 load-balancing {flow | vlan} Applies a load-balancing method to the specific port
channel.
Example:
• If you do not configure this command, the port channel
Router(config-if)# load-balancing flow uses the global load-balancing method configured with
the port-channel load-balancing vlan-manual
command. The global default is flow-based.
Step 5 end Exits configuration mode.

Example:

• show running-config interface port-channel channel-number —Displays the port channel configuration.
Router# show running-config interface port-channel 62

!
818
interface Port-channel62
ip address 12.1.1.1 255.255.255.0
ipv6 address 2001:12:1:1::1/64
mpls
• show etherchannel load-balancing — Displays the load balancing method applied to each port channel.
Router# show etherchannel load-balancing
EtherChannel Load-Balancing Method:

Global LB Method: flow-based
Port-Channel: LB Method
Port-channel62 : flow-based
Port-channel63 : flow-based
• show interfaces port-channel channel-number etherchannel —Displays the bucket distribution

currently in use.
The following is a sample output for an interface with load balancing set to flow-based:
Router(config)# show interface port-channel 62 etherchannel
All IDBs List contains 8 configured interfaces

Port: TenGigabitEthernet4/1/0 (index: 0)
Active Member List contains 8 interfaces

Port: TenGigabitEthernet4/1/0
LACP Mode: Active
LACP Mode: Active
LACP Mode: Active
LACP Mode: Active
LACP Mode: Active
LACP Mode: Active
LACP Mode: Active
LACP Mode: Active
Passive Member List contains 0 interfaces

Load-Balancing method applied: flow-based
819
Configuration Examples for Flow-Based per Port-Channel Load Balancing
Bucket Information for Flow-Based LB:

Interface: Buckets
TenGigabitEthernet4/1/0:
Bucket 0 , Bucket 1
Bucket 2 , Bucket 3
Bucket 4 , Bucket 5
Bucket 6 , Bucket 7
Bucket 8 , Bucket 9
Bucket 10, Bucket 11
Configuration Examples for Flow-Based per Port-Channel Load

Balancing
Example: Flow-Based Load Balancing
The following example shows a configuration where flow-based load balancing is configured on port-channel
2 while the VLAN-manual method is configured globally:
!
no aaa new-model
port-channel load-balancing vlan-manual
ip source-route
.
.
.
interface Port-channel2
ip address 10.0.0.1 255.255.255.0
no negotiation auto
load-balancing flow
!
interface Port-channel2.10
ip rsvp authentication key 11223344
ip rsvp authentication
!
interface Port-channel2.50
!
no ip address
negotiation auto
cdp enable
channel-group 2
!
820
Description Link
ID and password.
Feature Information for Flow-Based per Port-Channel Load

Balancing
Table 145: Feature Information for Flow-Based per Port-Channel Load Balancing
Flow-based per port-channel Load Cisco IOS XE Everest 16.6.1 This feature was integrated into
balancing Cisco IOS XE Everest 16.6.1 on
Broadband Routers.
821
Feature Information for Flow-Based per Port-Channel Load Balancing
822
CHAPTER 56
MPLS QoS via TLV for non-L2VPN Service Flow
The MPLS QoS via TLV for non-L2VPN Service Flow feature allows to mark TC bits for MPLS L3VPN
imposition packets and classify downstream packets based on TC bits of MPLS disposition packets, using
vendor-specific TLVs.
• Restrictions for MPLS QoS via TLV for non-L2VPN Service Flow, on page 824
• Information About MPLS QoS via TLV for non-L2VPN Service Flow, on page 825
• Configuring MPLS QoS via TLV for non-L2VPN Service Flow, on page 825
• Feature Information for MPLS QoS via TLV for non-L2VPN Service Flow, on page 830
823
Restrictions for MPLS QoS via TLV for non-L2VPN Service Flow
Digital PICs:

Module:

Modules:
line card reload.
Restrictions for MPLS QoS via TLV for non-L2VPN Service Flow
• This feature supports only IPv4. It will not support IPv6.
824
Information About MPLS QoS via TLV for non-L2VPN Service Flow
• This feature does not support SNMP.

• This feature does not support dynamic service flows.
• Only up to four VPNs and eight upstream service flows per CM can be configured.
• For a VPN, only a maximum of eight DS classifiers (using TC bits in the range from 0 to 7) can be
configured.
• If TC bits downstream classifiers are configured for a VPN, then the downstream MPLS packets belonging
to the VPN are processed only on TC bits classification. It will not process general IP header field
classification.
Information About MPLS QoS via TLV for non-L2VPN Service

Flow
The MPLS QoS via TLV for non-L2VPN Service Flow feature is a QoS enhancement based on MPLS Traffic
Class (TC) bits for MPLS L3VPN. The MPLS TC bits were previously known as MPLS EXP bits. RFC 5462
has renamed the MPLS EXP field to MPLS TC field.
For upstream service flow encoding, use Cisco-specific TLV to set TC bits value for MPLS imposition packets.
For downstream classifier encoding, use Cisco-specific TLV to implement downstream classification based
on TC bits of MPLS disposition packets.
Configuring MPLS QoS via TLV for non-L2VPN Service Flow
Note This feature is configured using a cable modem configuration file and is dependent on the general configuration
of the L3VPN.
This section describes how to configure traffic class bits for MPLS imposition and disposition packets and
on how to use vendor-specific TLVs with AToM L2VPN and MPLS L3VPN.
Traffic Class for MPLS Imposition Packets

The table lists the vendor-specific TLV to be included in the cable modem configuration file to configure TC
bits for MPLS imposition packets. The MPLS-TC-SET TLV is defined in the upstream and is associated with
the VPN RD in upstream service flow encoding.
Table 147: TLV to Configure TC Bits for MPLS Imposition Packets
TLV Name SubType Length Value
MPLS-TC-SET TLV 43.5.43.34 1 Imposition MPLS-TC-SET bits
Traffic Classification for MPLS Disposition Packets

The table lists the vendor-specific TLV to be included in the cable modem configuration file to classify DS
packets based on TC bits of MPLS disposition packets.
825
Using Vendor-Specific TLVs with AToM L2VPN and MPLS L3VPN
The MPLS-TC-RANGE TLV is defined only under DS classifier encodings. It supports multi-downstream
flow in a CM belonging to the same MPLS L3VPN, associated with the VPN RD in downstream classifier
encoding.
Table 148: TLV to Classify TC Bits for MPLS Disposition Packets
TLV Name SubType Length Value
MPLS-TC-RANGE 43.5.43.35 2 MPLS-TC-low and MPLS-TC-high
Using Vendor-Specific TLVs with AToM L2VPN and MPLS L3VPN

If both AToM L2VPN (L2 MPLS) and MPLS L3VPN (L3 MPLS) are using the same set of TLVs
(MPLS-TC-SET and MPLS-TC-RANGE), then you should differentiate them. Configure the TLVs for
upstream service flow encoding and downstream classifier encodings as indicated below:
Upstream Service Flow Encoding

• For L2VPN, configure MPLS-TC-SET (43.5.43.34) and L2VPN ID (43.5.1).
• For MPLS L3VPN, configure MPLS-TC-SET (43.5.43.34) and VPN RD (43.5.1).
Note Do not configure the TLVs for L2VPN and MPLS L3VPN at the same time for upstream service flow
encodings, as it will result in a TLV error.
Downstream Classifier Encoding

• L2VPN—Configure MPLS-TC-RANGE (43.5.43.35) and L2VPN ID (43.5.1).
• MPLS L3VPN—Configure MPLS-TC-RANGE (43.5.43.35) and VPN RD (43.5.1).
Example: Upstream Service Flow Marking TLV

The following example shows a sample CM configuration TLV for the provisioning of TC bits for MPLS
imposition packets:
24 (Upstream Service Flow Encoding)

T08 (Vendor ID) = 00 00 0c
T004 (VPN Route Distinguisher) = xx xx xx xx xx xx xx xx
S005 (Vendor specific L2VPN TLV)
S043 (Cisco Vendor Specific)
T034 (MPLS-TC-SET) = 04 # MPLSTC-SET = 4
826
Example: Downstream Packet Classification TLV
Example: Downstream Packet Classification TLV

The following example shows a sample CM configuration TLV for classifying downstream packets based on
TC bits of MPLS disposition packets:
23 (Downstream Packet Classification Encoding)

T08 (Vendor ID) = 00 00 0c
S004 (VPN Route Distinguisher) = xx xx xx xx xx xx xx xx
S005 (Vendor specific L2VPN TLV)
S043 (Cisco Vendor Specific)
S035 (MPLS-TC-RANGE) = 04 05 # MPLSTC-EGRESS_RANGE= 4 – 5
Example: MPLS QoS Configuration File

The following example shows a cable modem being configured to mark TC bits for MPLS L3VPN imposition
packets and classify downstream packets based on TC bits of MPLS L3VPN disposition packets, using
vendor-specific TLVs:
CM-CONFIG
=========
T01 (IP Type of Srv Rng & Mask) = a0 e0 ff
T08 (Vendor ID) = 00 00 0c
T004 (Unknown sub-type) = 00 00 00 01 00 00 00 01
T005 (Unknown sub-type) = 2b 09 08 03 00 00 0c 23 02 01 01
827

T08 (Vendor ID) = 00 00 0c
T08 (Vendor ID) = 00 00 0c
T08 (Vendor ID) = 00 00 0c
T005 (Unknown sub-type) = 2b 08 08 03 00 00 0c 22 01 04
T08 (Vendor ID) = 00 00 0c
T08 (Vendor ID) = 00 00 0c
828

T08 (Vendor ID) = 00 00 0c
T08 (Vendor ID) = 00 00 0c
T08 (Vendor ID) = 00 00 0c
T08 (Vendor ID) = 00 00 0c
T08 (Vendor ID) = 00 00 0c
#<EOF>
829
Description Link
ID and password.
Feature Information for MPLS QoS via TLV for non-L2VPN

Service Flow
Table 149: Feature Information for MPLS QoS via TLV for non-L2VPN Service Flow
MPLS QoS via TLV for Cisco IOS XE Everest 16.6.1 This feature was integrated into
non-L2VPN Service Flow Cisco IOS XE Everest 16.6.1 on
Broadband Routers.
MPLS QoS via TLV for Cisco IOS XE Everest 16.6.1 This feature was integrated into
non-L2VPN Service Flow Cisco IOS XE Everest 16.6.1 on
Broadband Routers.
830
CHAPTER 57
IPsec Security Support
IPsec is a security framework of open standards developed by the IETF. IPsec enables security for information
that is send over unprotected networks. IPsec acts at the network layer, protecting and authenticating IP packets
between participating IPsec devices (“peers”), such as Cisco routers.
• IPsec Security Support, on page 833
• IPsec Security Limitations, on page 833
• Configuring IPsec Security, on page 833
• Configuring Transform Sets for IKEv2, on page 835
• Feature Information for IPsec Security Support, on page 836

831
Digital PICs:

Module:

Modules:
line card reload.
832

Cisco IOS XE Amsterdam 17.2.x provides limited support for up to 16 Gbps encrypted IPsec that is sent or
forwarded by cBR8.
IPsec is a security framework of open standards developed by the IETF. IPsec enables security for information
that is send over unprotected networks. IPsec acts at the network layer, protecting and authenticating IP packets
between participating IPsec devices (“peers”), such as Cisco routers.
IPsec is mainly for securing lawful intercept (LI) traffic from cBR8 to MAC Domain profile. The IPsec feature
now supports:
• AES-CBC-128 encryption
• HMAC-SHA-256 authentication
• ESP tunnel mode
• IKEv2 with certificate or preshared key
• PFS (Perfect Forward Secrecy)
IPsec Security Limitations

The IPsec feature for Cisco IOS XE Amsterdam 17.2.1 has the following limitations:
• Only supported on SUP 160.
• The RX path of IPsec tunnel only supports minimum control traffic. The traffic is punted to IOSd, and
is heavily rate-limited. The default limit is 200 packets/second (configurable).
Configuring IPsec Security

To configure the IPsec security, complete the following steps:
1. Use the crypto ipsec transform-set <ts-name> esp-aes esp-sha256-hmac command. However, note
that only the following options are supported:
• Support for esp-aes esp-sha256-hmac
• Support for mode tunnel
You can optionally use set pfs <dh-group-name> to enable perfect forward secrecy in IPsec profile.
2. Use the crypto ipsec profile <profile-name>, where the IKEv2 profile is set into IPsec profile.
3. Use the tunnel protection ipsec profile tunnel interface.
To view your IPsec information, use the show crypto ipsec sa detail command:
Router# show crypto ipsec sa detail

833
Configuring IPsec Security
Time source is NTP, 12:40:49.195 EDT Wed Feb 26 2020
interface: Tunnel101
Crypto map tag: Tunnel101-head-0, local addr 102.0.0.2
protected vrf: (none)

local ident (addr/mask/prot/port): (102.0.0.2/255.255.255.255/47/0)
remote ident (addr/mask/prot/port): (102.0.0.1/255.255.255.255/47/0)
current_peer 102.0.0.1 port 500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0
#pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#pkts no sa (send) 0, #pkts invalid sa (rcv) 0
#pkts encaps failed (send) 0, #pkts decaps failed (rcv) 0
#pkts invalid prot (recv) 0, #pkts verify failed: 0
#pkts invalid identity (recv) 0, #pkts invalid len (rcv) 0
#pkts replay rollover (send): 0, #pkts replay rollover (rcv) 0
##pkts replay failed (rcv): 0
#pkts tagged (send): 0, #pkts untagged (rcv): 0
#pkts not tagged (send): 0, #pkts not untagged (rcv): 0
#pkts internal err (send): 0, #pkts internal err (recv) 0
local crypto endpt.: 102.0.0.2, remote crypto endpt.: 102.0.0.1

plaintext mtu 1438, path mtu 1500, ip mtu 1500, ip mtu idb TenGigabitEthernet4/1/0
current outbound spi: 0xBD3A2CBF(3174706367)
PFS (Y/N): N, DH group: none
inbound esp sas:

spi: 0xC67787E8(3329722344)
transform: esp-aes esp-sha256-hmac ,
in use settings ={Tunnel, }
conn id: 2, flow_id: SW:2, sibling_flags FFFFFFFF80000040, crypto map:
Tunnel101-head-0
sa timing: remaining key lifetime (k/sec): (4242079/86293)
IV size: 16 bytes
replay detection support: Y
Status: ACTIVE(ACTIVE)
inbound ah sas:
inbound pcp sas:
outbound esp sas:

spi: 0xBD3A2CBF(3174706367)
transform: esp-aes esp-sha256-hmac ,
in use settings ={Tunnel, }
conn id: 1, flow_id: SW:1, sibling_flags FFFFFFFF80000040, crypto map:
Tunnel101-head-0
sa timing: remaining key lifetime (k/sec): (4242079/86293)
IV size: 16 bytes
replay detection support: Y
Status: ACTIVE(ACTIVE)
outbound ah sas:
outbound pcp sas:
834
Configuring Transform Sets for IKEv2
Configuring Transform Sets for IKEv2

You can choose to configure the IKEv2 using eitheir of the following options:
• IKEv2 with pre-shared key. This includes the following options:
• crypto ikev2 proposal <proposal-name>.
• crypto ikev2 policy <policy-name>
• crypto ikev2 keyring <keyring-name>
Set keyring in IKEv2 profile. A configuration example using IKEv2 with pre-shared key is as shown:
crypto ikev2 proposal li-ikev2-proposal

encryption aes-cbc-128
integrity sha256
group 5 2
crypto ikev2 policy li-ikev2-policy
match address local 102.0.0.2
proposal li-ikev2-proposal
crypto ikev2 keyring li-kyr
peer li-peer
address 102.0.0.1 255.255.255.0
identity address 102.0.0.2
pre-shared-key key1
!
crypto ikev2 profile li-profile
match address local interface TenGigabitEthernet4/1/7
match identity remote address 102.0.0.1 255.255.255.255
authentication remote pre-share
authentication local pre-share key key1
keyring local li-kyr
crypto ipsec transform-set TS esp-aes esp-sha256-hmac
mode tunnel
crypto ipsec profile li-ipsec-gre
set security-association lifetime seconds 86400
set transform-set TS
set pfs group14
set ikev2-profile li-profile
• IKEv2 with certificate authority. This includes the following steps:

1. Generate the RSA key pair.
2. Configure the PKI trustpoint. This requires the CA server supporting SCEP (Simple Certificate
Enrollment Protocol).
Configure crypto pki trustpoint to enroll to CA. Note that the subject-name will be used for
authentication in the example
3. Set the certificate map in IKEv2 profile by configuring crypto pki certificate map <map-name>
<id> to match the certificate content.
4. Enroll the certificate.
To view your IPsec information, use the show crypto ikev2 sa detail command:
835
Feature Information for IPsec Security Support
Router# show crypto ikev2 sa detail

Time source is NTP, 12:40:57.672 EDT Wed Feb 26 2020
IPv4 Crypto IKEv2 SA
Tunnel-id Local Remote fvrf/ivrf Status

1 102.0.0.2/500 102.0.0.1/500 none/none READY
Encr: AES-CBC, keysize: 128, PRF: SHA256, Hash: SHA256, DH Grp:5, Auth sign: RSA,
Auth verify: RSA
Life/Active Time: 86400/115 sec
CE id: 1001, Session-id: 1
Status Description: Negotiation done
Local spi: A3C274EBBD7FFF2F Remote spi: AA160367FFD29C2D
Local id: hostname=tb34-cBR8.cisco.com,cn=ANSSI Test CBR8
Remote id: hostname=cCMTS-bcl-ASR1K6-2,cn=ANSSI Test ASR1K
Local req msg id: 2 Remote req msg id: 0
Local next msg id: 2 Remote next msg id: 0
Local req queued: 2 Remote req queued: 0
Local window: 5 Remote window: 5
DPD configured for 0 seconds, retry 0
Fragmentation not configured.
Dynamic Route Update: enabled
Extended Authentication not configured.
NAT-T is not detected
Cisco Trust Security SGT is disabled
Initiator of SA : Yes
IPv6 Crypto IKEv2 SA
Note The IPsec and IKEv2 are configured in the same way as ASR 1000. Go through the ASR 1000 Internet Key
Exchange for IPsec VPNs Configuration Guide for more information. The following limitations apply:
• Supported encryption
• Authentication algorithms
• ESP tunnel mode

836
Table 151: Feature Information for IPsec Security Support
IPsec Security Support Cisco IOS XE Amsterdam 17.2.1 This feature was integrated into
Cisco IOS XE Amsterdam 17.2.1
on the Cisco cBR Series Converged
Broadband Routers.
837
838
PA R T VI
Layer 3 Configuration
• DHCP, ToD, and TFTP Services for CMTS Routers, on page 841
• Virtual Interface Bundling, on page 861
• IPv6 on Cable, on page 871
• Cable DHCP Leasequery, on page 915
• DHCPv6 Bulk-Lease query, on page 925
• Layer 3 CPE Mobility, on page 929
• DOCSIS 3.0 Multicast Support, on page 939
• IPv6 Segment Routing on Cisco cBR, on page 963
CHAPTER 58
DHCP, ToD, and TFTP Services for CMTS Routers
This document describes how to configure Cisco Cable Modem Termination System (CMTS) platforms so
that they support onboard servers that provide Dynamic Host Configuration Protocol (DHCP), Time-of-Day
(ToD), and Trivial File Transfer Protocol (TFTP) services for use in Data-over-Cable Service Interface
Specification (DOCSIS) networks. In addition, this document provides information about optional configurations
that can be used with external DHCP servers.
• Prerequisites for DHCP, ToD, and TFTP Services, on page 841
• Restrictions for DHCP, ToD, and TFTP Services, on page 841
• Information About DHCP, ToD, and TFTP Services, on page 842
• How to Configure ToD, and TFTP Services, on page 847
• How to Configure ToD, and TFTP Services, on page 858
• Feature Information for the DHCP, ToD, and TFTP Services for the CMTS Routers, on page 859
Prerequisites for DHCP, ToD, and TFTP Services

To use the Cisco CMTS as the ToD server, either standalone or with other external ToD servers, you must
configure the DHCP server to provide the IP address of the Cisco CMTS as one of the valid ToD servers
(DHCP option 4) for cable modems.
Restrictions for DHCP, ToD, and TFTP Services

• The ToD server must use the UDP protocol to conform to DOCSIS specifications.
• For proper operation of the DOCSIS network, especially a DOCSIS 1.1 network using BPI+ encryption
and authentication, the system clock on the Cisco CMTS must be set accurately. You can achieve this
by manually using the set clock command, or by configuring the CMTS to use either the Network Time
Protocol (NTP) or the Simple Network Time Protocol (SNTP).
• Cisco cBR series routers do not support internal DHCP servers.
841
Information About DHCP, ToD, and TFTP Services
Information About DHCP, ToD, and TFTP Services

This section provides the following information about the DHCP, ToD, and TFTP Services feature, and its
individual components:
Feature Overview
All Cisco CMTS platforms support onboard servers that provide DHCP, ToD, and TFTP proxy-services for
use in DOCSIS cable networks. These servers provide the registration services needed by DOCSIS 1.0- and
1.1-compliant cable modems:
• External DHCP Servers—Provides DHCP services. External DHCP servers are usually part of an
integrated provisioning system that is more suitable when managing large cable networks.
• Time-of-DayServer_—Provides an RFC 868 -compliant ToD service so that cable modems can obtain
the current date and time during the registration process. The cable modem connects with the ToD server
after it has obtained its IP address and other DHCP-provided IP parameters.
Although cable modems do not need to successfully complete the ToD request before coming online, this
allows them to add accurate timestamps to their event logs so that these logs are coordinated to the clock used
on the CMTS. In addition, having the accurate date and time is essential if the cable modem is trying to register
with Baseline Privacy Interface Plus (BPI+) encryption and authentication.
• External TFTP_Server—Downloads the DOCSIS configuration file to the cable modem. The DOCSIS
configuration file contains the operational parameters for the cable modem. The cable modem downloads
its DOCSIS configuration file after connecting with the ToD server.
Note You can add additional servers in a number of ways. For example, most cable operators use Cisco Network
Registrar (CNR) to provide the DHCP and TFTP servers. ToD servers are freely available for most workstations
and PCs. You can install the additional servers on one workstation or PC or on different workstations and
PCs.
External DHCP Servers

The Cisco CMTS router provides the following optional configurations that can enhance the operation and
security of external DHCP servers that you are using on the DOCSIS cable network:
Cable Source Verify Feature

To combat theft-of-service attacks, you can enable the cable source-verify command on the cable interfaces
on the Cisco CMTS router. This feature uses the router’s internal database to verify the validity of the IP
packets that the CMTS receives on the cable interfaces, and provides three levels of protection:
• At the most basic level of protection, the Cable Source Verify feature examines every IP upstream packet
to prevent duplicate IP addresses from appearing on the cable network. If a conflict occurs, the Cisco
CMTS recognizes only packets coming from the device that was assigned the IP address by the DHCP
server. The devices with the duplicate addresses are not allowed network address. The CMTS also refuses
to recognize traffic from devices with IP addresses that have network addresses that are unauthorized
for that particular cable segment.
842
Prefix-based Source Address Verification
• Adding the dhcp option to the cable source-verify command provides a more comprehensive level of
protection by preventing users from statically assigning currently-unused IP addresses to their devices.
When the Cisco CMTS receives a packet with an unknown IP address on a cable interface, the CMTS
drops the packet but also issues a DHCP LEASEQUERY message that queries the DHCP servers for
any information about the IP and MAC addresses of that device. If the DHCP servers do not return any
information about the device, the CMTS continues to block the network access for that device.
• When you use the dhcp option, you can also enable the leasetimer option, which instructs the Cisco
CMTS to periodically check its internal CPE database for IP addresses whose lease times have expired.
The CPE devices that are using expired IP addresses are denied further access to the network until they
renew their IP addresses from a valid DHCP server. This can prevent users from taking DHCP-assigned
IP addresses and assigning them as static addresses to their CPE devices.
• In addition to the dhcp option, you can also configure prefix-based source address verification (SAV)
on the Cisco CMTS using the cable source-verify group command. A CM may have a static IPv4 or IPv6
prefix configured, which belongs to an SAV group. When the SAV prefix processing is enabled on the
Cisco CMTS, the source IP address of the packets coming from the CM is matched against the configured
prefix and SAV group (for that CM) for verification. If the verification fails, the packets are dropped,
else the packets are forwarded for further processing. For more information on SAV prefix processing
and SAV prefix configuration, see Prefix-based Source Address Verification , on page 843 and Configuring
Prefix-based Source Address Verification, on page 854
Prefix-based Source Address Verification

The Source Address Verification (SAV) feature verifies the source IP address of an upstream packet to ensure
that the SID/MAC and IP are consistent. The DOCSIS 3.0 Security Specification introduces prefix-based
SAV where every CM may have static IPv4 or IPv6 prefixes configured. These prefixes are either preconfigured
on the CMTS, or are communicated to the CMTS during CM registration. The Cisco CMTS uses these
configured prefixes to verify the source IP address of all the incoming packets from that CM.
An SAV group is a collection of prefixes. A prefix is an IPv4 or IPv6 subnet address. You can use the cable
source-verify group command in global configuration mode to configure SAV groups. A total of 255 SAV
groups are supported on a CMTS, with each SAV group having a maximum of four prefixes. Prefixes can be
configured using the prefix command.
During registration, CMs communicate their configured static prefixes to the CMTS using two TLVs, 43.7.1
and 43.7.2. The TLV 43.7.1 specifies the SAV prefix group name that the CM belongs to, and TLV 43.7.2
specifies the actual IPv4 or IPv6 prefix. Each CM can have a maximum of four prefixes configured. When
the Cisco CMTS receives these TLVs, it first identifies if the specified SAV group and the prefixes are already
configured on the Cisco CMTS. If they are configured, the Cisco CMTS associates them to the registering
CM. However if they are not configured, the Cisco CMTS automatically creates the specified SAV group and
prefixes before associating them to the registering CM.
The SAV group name and the prefixes that are provided by these TLVs are considered valid by the Cisco
CMTS. The packets received (from the CM) with the source IP address belonging to the prefix specified by
the TLV are considered authorized. For example, if a given CM has been configured with an SAV prefix of
10.10.10.0/24, then any packet received from this CM (or CPE behind the CM) that is sourced with this address
in the subnet 10.10.10.0/24 is considered to be authorized.
For more information on how to configure SAV groups and prefixes see Configuring Prefix-based Source
Address Verification, on page 854.
Smart Relay Feature

The Cisco CMTS supports a Smart Relay feature (the ip dhcp smart-relay command), which automatically
switches a cable modem or CPE device to secondary DHCP servers or address pools if the primary server
843
GIADDR Field
runs out of IP addresses or otherwise fails to respond with an IP address. The relay agent attempts to forward
DHCP requests to the primary server three times. After three attempts with no successful response from the
primary, the relay agent automatically switches to the secondary server.
When you are using the cable dhcp-giaddr policy command to specify that the CPE devices should use the
secondary DHCP pools corresponding to the secondary addresses on a cable interface, the smart relay agent
automatically rotates through the available secondary in a round robin fashion until an available pool of
addresses is found. This ensures that clients are not locked out of the network because a particular pool has
been exhausted.
GIADDR Field
When using separate IP address pools for cable modems and CPE devices, you can use the cable dhcp-giaddr
policy command to specify that cable modems should use an address from the primary pool and that CPE
devices should use addresses from the secondary pool. The default is for the CMTS to send all DHCP requests
to the primary DHCP server, while the secondary servers are used only if the primary server does not respond.
The different DHCP servers are specified using the cable helper commands.
DHCP Relay Agent Sub-option

The DHCP Relay Agent Information sub-option (DHCP Option 82, Suboption 9) enhancement simplifies
provisioning of the CPE devices. Using this sub-option, the cable operators can relay the service class or QoS
information of the CPE to the DHCP server to get an appropriate IP address.
To provision a CPE, the DHCP server should be made aware of the service class or QoS information of the
CPE. The DHCP server obtains this information using the DHCP DISCOVER message, which includes the
service class or QoS information of the CM behind which the CPE resides.
During the provisioning process, the Cisco CMTS uses the DHCPv4 Relay Agent Information sub-option to
advertise information about the service class or QoS profile of the CMs to the DHCP server. Using the same
technique, the CPE information is relayed to the DHCP server to get an appropriate IP address.
To enable the service classes option, the service class name specified in the CM configuration file must be
configured on the Cisco CMTS. This is done by using the cable dhcp-insert service-class command.
Note To insert service class relay agent information option into the DHCP DISCOVER messages, the ip dhcp
relay information option-insert command must be configured on the bundle interface.
Time-of-Day Server
The Cisco CMTS can function as a ToD server that provides the current date and time to the cable modems
and other customer premises equipment (CPE) devices connected to its cable interfaces. This allows the cable
modems and CPE devices to accurately timestamp their Simple Network Management Protocol (SNMP)
messages and error log entries, as well as ensure that all of the system clocks on the cable network are
synchronized to the same system time.
The DOCSIS 1.0 and 1.1 specifications require that all DOCSIS cable modems request the following
time-related fields in the DHCP request they send during their initial power-on provisioning:
• Time Offset (option 2)—Specifies the time zone for the cable modem or CPE device, in the form of the
number of seconds that the device’s timestamp is offset from Greenwich Mean Time (GMT).
844
Time-of-Day Server
• Time Server Option (option 4)—Specifies one or more IP addresses for a ToD server.
After a cable modem successfully acquires a DHCP lease time, it then attempts to contact one of the ToD
servers provided in the list provided by the DHCP server. If successful, the cable modem updates its system
clock with the time offset and timestamp received from the ToD server.
If a ToD server cannot be reached or if it does not respond, the cable modem eventually times out, logs the
failure with the CMTS, and continues on with the initialization process. The cable modem can come online
without receiving a reply from a ToD server, but it must periodically continue to reach the ToD server at least
once in every five-minute period until it successfully receives a ToD reply. Until it reaches a ToD server, the
cable modem must initialize its system clock to midnight on January 1, 1970 GMT.
Note Initial versions of the DOCSIS 1.0 specification specified that the cable device must obtain a valid response
from a ToD server before continuing with the initialization process. This requirement was removed in the
released DOCSIS 1.0 specification and in the DOCSIS 1.1 specifications. Cable devices running older firmware
that is compliant with the initial DOCSIS 1.0 specification, however, might require receiving a reply from a
ToD server before being able to come online.
Because cable modems will repeatedly retry connecting with a ToD server until they receive a successful
reply, you should consider activating the ToD server on the Cisco CMTS, even if you have one or more other
ToD servers at the headend. This ensures that an online cable modem will always be able to connect with the
ToD server on the Cisco CMTS, even if the other servers go down or are unreachable because of network
congestion, and therefore will not send repeated ToD requests.
Tip To be able to use the Cisco CMTS as the ToD server, you must configure the DHCP server to provide the IP
address Cisco CMTS as one of the valid ToD servers (DHCP option 4) for cable modems.
In addition, although the DOCSIS specifications do not require that a cable modem successfully obtain a
response from a ToD server before coming online, not obtaining a timestamp could prevent the cable modem
from coming online in the following situations:
• If DOCSIS configuration files are being timestamped, to prevent cable modems from caching the files
and replaying them, the clocks on the cable modem and CMTS must be synchronized. Otherwise, the
cable modem cannot determine whether a DOCSIS configuration file has the proper timestamp.
• If cable modems register using Baseline Privacy Interface Plus (BPI+) authentication and encryption,
the clocks on the cable modem and CMTS must be synchronized. This is because BPI+ authorization
requires that the CMTS and cable modem verify the timestamps on the digital certificates being used for
authentication. If the timestamps on the CMTS and cable modem are not synchronized, the cable modem
cannot come online using BPI+ encryption.
Note DOCSIS cable modems must use RFC 868 -compliant ToD server to obtain the current system time. They
cannot use the Network Time Protocol (NTP) or Simple Network Time Protocol (SNTP) service for this
purpose. However, the Cisco CMTS can use an NTP or SNTP server to set its own system clock, which can
then be used by the ToD server. Otherwise, you must manually set the clock on the CMTS using the clock
set command each time that the CMTS boots up.
845
TFTP Server
Tip Additional servers can be provided by workstations or PCs installed at the cable headend. UNIX and Solaris
systems typically include a ToD server as part of the operating system, which can be enabled by putting the
appropriate line in the inetd.conf file. Windows systems can use shareware servers such as Greyware and
Tardis. The DOCSIS specifications require that the ToD servers use the User Datagram Protocol (UDP)
protocol instead of the TCP protocol for its packets.
TFTP Server
All Cisco CMTS platforms can be configured to provide a TFTP server that can provide the following types
of files to DOCSIS cable modems:
• DOCSIS Configuration File—After a DOCSIS cable modem has acquired a DHCP lease and attempted
to contact a ToD server, the cable modem uses TFTP to download a DOCSIS configuration file from an
authorized TFTP server. The DHCP server is responsible for providing the name of the DOCSIS
configuration file and IP address of the TFTP server to the cable modem.
• Software Upgrade File—If the DOCSIS configuration file specifies that the cable modem must be running
a specific version of software, and the cable modem is not already running that software, the cable modem
must download that software file. For security, the cable operator can use different TFTP servers for
downloading DOCSIS configuration files and for downloading new software files.
• Cisco IOS-XE Configuration File—The DOCSIS configuration file for Cisco cable devices can also
specify that the cable modem should download a Cisco IOS-XE configuration file that contains
command-line interface (CLI) configuration commands. Typically this is done to configure
platform-specific features such as voice ports or IPSec encryption.
Note Do not confuse the DOCSIS configuration file with the Cisco IOS-XE configuration file. The DOCSIS
configuration file is a binary file in the particular format that is specified by the DOCSIS specifications, and
each DOCSIS cable modem must download a valid file before coming online. In contrast, the Cisco IOS-XE
configuration file is an ASCII text file that contains one or more Cisco IOS-XE CLI configuration commands.
Only Cisco cable devices can download a Cisco IOS-XE file.
All Cisco CMTS platforms can be configured as TFTP servers that can upload these files to the cable modem.
The files can reside on any valid device but typically should be copied to the Flash memory device inserted
into the Flash disk slot on the Cisco CMTS.
Sniff out boot file name from DHCP process per CM

Starting from Cisco IOS XE Gibraltar 16.12.1, the cBR-8 can sniff, parse and save the configuration file
related information per CM. This includes path and name of the configuration file, the IPv4 or IPv6 address
of the TPFT server from which the CM requests the configuration file, and the timestamp when cBR-8 sniffed
the CM’s TFTP RRQ packet that requests the configuration file. This feature is enabled by default and cannot
be disabled.
The show cable modem tftp command displays a single CM’s configuration file related information.
The following example shows the sample output for this command.
Router#show cable modem 34bd.fa0f.4418 tftp
Host Interface : C1/0/0
846
Benefits
MAC Address : 34bd.fa0f.4418

IP Address : 50.13.0.4
IPv6 Address : 2001:50:13:0:74E3:4197:E2F2:8162
Modem Status : w-online(pt)
TFTP Server Address : 2001:1:38::25:3
Modem Configuration File Name : cbr8/cm.bin
Timestamp : 02:16:02 CST Tue May 21 2019
Benefits
• The Cisco CMTS can act as a primary or backup ToD server to ensure that all cable modems are
synchronized with the proper date and time before coming online. This also enables cable modems to
come online more quickly because they will not have to wait for the ToD timeout period before coming
online.
• The ToD server on the Cisco CMTS ensures that all devices connected to the cable network are using
the same system clock, making it easier for you to troubleshoot system problems when you analyze the
debugging output and error logs generated by many cable modems, CPE devices, the Cisco CMTS, and
other services.
• The Cisco CMTS can act as a TFTP server for DOCSIS configuration files, software upgrade files, and
Cisco IOS configuration files.
How to Configure ToD, and TFTP Services

See the following configuration tasks required to configure time-of-day service, and TFTP service on a Cisco
CMTS:
Configuring Time-of-Day Service

This section provides procedures for enabling and disabling the time-of-day (ToD) server on the Cisco CMTS
routers.
Prerequisites
To be able to use the Cisco CMTS as the ToD server you must configure the DHCP server to provide the IP
address Cisco CMTS as one of the valid ToD servers (DHCP option 4) for cable modems.
Enabling Time-of-Day Service

To enable the ToD server on a Cisco CMTS, use the following procedure, beginning in EXEC mode.
Procedure

prompted.
Example:
Router> enable
Router#
847
Disabling Time-of-Day Service

Example:

Router(config)#
Step 3 service udp-small-servers max-servers no-limit Enables use of minor servers that use the UDP protocol
(such as ToD, echo, chargen, and discard).
Example:
The max-servers no-limit option allows a large number of
Router(config)# service udp-small-servers cable modems to obtain the ToD server at one time, in the
max-servers no-limit event that a cable or power failure forces many cable
Router(config)#
modems offline. When the problem has been resolved, the
cable modems can quickly reconnect.
Step 4 cable time-server Enables the ToD server on the Cisco CMTS.
Example:
Router(config)# cable time-server

Router(config)#

Example:
Router#
Disabling Time-of-Day Service

To disable the ToD server, use the following procedure, beginning in EXEC mode.
Procedure

prompted.
Example:
Router> enable
Router#

Example:

Router(config)#
Step 3 no cable time-server Disables the ToD server on the Cisco CMTS.
Example:
848
Configuring TFTP Service
Router(config)# cable time-server

Router(config)#
Step 4 no service udp-small-servers (Optional) Disables the use of all minor UDP servers.
Example: Note Do not disable the minor UDP servers if you are
also enabling the other DHCP or TFTP servers.
Router(config)# no service udp-small-servers
Router(config)#

Example:
Router#

To configure TFTP service on a Cisco CMTS where the CMTS can act as a TFTP server and download a
DOCSIS configuration file to cable modems, perform the following steps:
• Create the DOCSIS configuration files using the DOCSIS configuration editor of your choice.
• Copy all desired files (DOCSIS configuration files, software upgrade files, and Cisco IOS configuration
files) to the Flash memory device on the Cisco CMTS. Typically, this is done by placing the files first
on an external TFTP server, and then using TFTP commands to transfer them to the router’s Flash
memory.
• Enable the TFTP server on the Cisco CMTS with the tftp-server command.
Each configuration task is required unless otherwise listed as optional.
Step 1 Use the show file systems command to display the Flash memory cards that are available on your CMTS, along with the
free space on each card and the appropriate device names to use to access each card.
Most configurations of the Cisco CMTS platforms support both linear Flash and Flash disk memory cards. Linear Flash
memory is accessed using the slot0 (or flash) and slot1 device names. Flash disk memory is accessed using the disk0
and disk1 device names.
For example, the following command shows a Cisco uBR7200 series router that has two linear Flash memory cards
installed. The cards can be accessed by the slot0 (or flash) and slot1 device names.
Example:
File Systems:
48755200 48747008 flash rw slot0: flash:
16384000 14284000 flash rw slot1:
32768000 31232884 flash rw bootflash:
* - - disk rw disk0:
- - disk rw disk1:
849
- - opaque rw null:
522232 507263 nvram rw nvram:
- - network rw rcp:
- - network rw ftp:
- - network rw scp:
Router#
The following example shows a Cisco uBR10012 router that has two Flash disk cards installed. These cards can be
accessed by the disk0 and sec-disk0 device names.
Example:
File Systems:
- - flash rw slot0: flash:
- - flash rw slot1:
32768000 29630876 flash rw bootflash:
* 128094208 95346688 disk rw disk0:
- - disk rw disk1:
- - flash rw sec-slot0:
- - flash rw sec-slot1:
* 128094208 95346688 disk rw sec-disk0:
- - disk rw sec-disk1:
32768000 29630876 flash rw sec-bootflash:
- - nvram rw sec-nvram:
- - opaque rw null:
522232 505523 nvram rw nvram:
- - network rw rcp:
- - network rw ftp:
- - network rw scp:
Router#
Step 2 Verify that the desired Flash memory card has sufficient free space for all of the files that you want to copy to the CMTS.
Step 3 Use the ping command to verify that the remote TFTP server that contains the desired files is reachable. For example,
the following shows a ping command being given to an external TFTP server with the IP address of 10.10.10.1:
Example:
Router# ping 10.10.10.1

!!!!!
Step 4 Use the copy tftp devname command to copy each file from the external TFTP server to the appropriate Flash memory
card on the CMTS, where devname is the device name for the destination Flash memory card. You will then be prompted
for the IP address for the external TFTP server and the filename for the file to be transferred.
The following example shows the file docsis.cm being transferred from the external TFTP server at IP address 10.10.10.1
to the first Flash memory disk (disk0):
Example:
Router# copy tftp disk0

Address or name of remote host []? 10.10.10.1
850
Source filename []? config-files/docsis.cm
Destination filename [docsis.cm]?

Accessing tftp://10.10.10.1/config-file/docsis.cm......
Loading docsis.cm from 10.10.10.1 (via Ethernet2/0): !!!
[OK - 276/4096 bytes]
276 bytes copied in 0.152 secs
Router#
Step 5 Repeat Step 4, on page 850 as needed to copy all of the files from the external TFTP server to the Flash memory card on
the Cisco CMTS.
Step 6 Use the dir command to verify that the Flash memory card contains all of the transferred files.
Example:
Router# dir disk0:
Directory of disk0:/
1 -rw- 10705784 May 30 2002 19:12:46 ubr10k-p6-mz.122-2.8.BC
2 -rw- 4772 Jun 20 2002 18:12:56 running.cfg.save
3 -rw- 241 Jul 31 2002 18:25:46 gold.cm
4 -rw- 225 Jul 31 2002 18:25:46 silver.cm
5 -rw- 231 Jul 31 2002 18:25:46 bronze.cm
6 -rw- 74 Oct 11 2002 21:41:14 disable.cm
7 -rw- 2934028 May 30 2002 11:22:12 ubr924-k8y5-mz.bin
8 -rw- 3255196 Jun 28 2002 13:53:14 ubr925-k9v9y5-mz.bin
Router#
Step 7 Use the configure terminal command to enter global configuration mode:
Example:
Router(config)#
Step 8 Use the tftp-server command to specify which particular files can be transferred by the TFTP server that is onboard the
Cisco CMTS. You can also use the alias option to specify a different filename that the DHCP server can use to refer to
the file. For example, the following commands enable the TFTP transfer of the configuration files and software upgrade
files:
Example:
Router(config)# tftp-server disk0:gold.cm alias gold.cm
Router(config)# tftp-server disk0:silver.cm alias silver.cm
Router(config)# tftp-server disk0:bronze.cm alias bronze.cm
Router(config)# tftp-server disk0:ubr924-k8y5-mz.bin alias ubr924-codefile
Router(config)# tftp-server disk0:ubr925-k9v9y5-mz.bin alias ubr925-codefile
Router(config)#
Note The tftp-server command also supports the option of specifying an access list that restricts access to the
particular file to the IP addresses that match the access list.
851
Optimizing the Use of an External DHCP Server
Step 9 (Optional) Use the following command to enable the use of the UDP small servers, and to allow an unlimited number of
connections at one time. This will allow a large number of cable modems that have gone offline due to cable or power
failure to rapidly come back online.
Example:
Router(config)# service udp-small-servers max-servers no-limit
Router(config)#
Optimizing the Use of an External DHCP Server

The Cisco CMTS offers a number of options that can optimize the operation of external DHCP servers on a
DOCSIS cable network. See the following sections for details. All procedures are optional, depending on the
needs of your network and application servers.
Configuring Cable Source Verify Option

To enhance security when using external DHCP servers, you can optionally configure the Cable Source Verify
feature with the following procedure.
Restriction • The Cable Source Verify feature supports only external DHCP servers. It cannot be used with the internal
DHCP server.
Procedure

prompted.
Example:
Router> enable
Router#

Example:

Router(config)#
Step 3 interface cable x/y Enters cable interface configuration mode for the specified
cable interface.
Example:
Router(config)# interface cable 4/0

Router(config-if)#
852
Configuring Cable Source Verify Option

Step 4 cable source-verify [dhcp | leasetimer value ] (Optional) Ensures that the CMTS allows network access
only to those IP addresses that DCHP servers issued to
Example:
devices on this cable interface. The CMTS examines DHCP
packets that pass through the cable interfaces to build a
Router(config-if)# cable source-verify dhcp
database of which IP addresses are valid on which interface.
Example:
• dhcp = (Optional) Drops traffic from all devices with
unknown IP addresses, but the CMTS also sends a
Router(config-if)# cable source-verify leasetimer
30 query to the DHCP servers for any information about
Router(config-if)# the device. If a DHCP server informs the CMTS that
the device has a valid IP address, the CMTS then
allows the device on the network.
• leasetimer value = (Optional) Specifies how often, in
minutes, the router should check its internal CPE
database for IP addresses whose lease times have
expired. This can prevent users from taking
DHCP-assigned IP addresses and assigning them as
static addresses to their CPE devices. The valid range
for value is 1 to 240 minutes, with no default.
Note The leasetimer option takes effect only when
the dhcp option is also used on an interface.
Step 5 no cable arp (Optional) Blocks Address Resolution Protocol (ARP)

requests originating from devices on the cable network. Use
Example:
this command, together with the cable source-verify dhcp
command, to block certain types of theft-of-service attacks
Router(config-if)# no cable arp
Router(config-if)# that attempt to hijack or spoof IP addresses.
Note Repeat Step 3, on page 852 through Step 5, on
page 853 for each desired cable interface.
Step 6 exit Exits interface configuration mode.

Example:
Router(config)#
Step 7 ip dhcp relay information option (Optional) Enables the CMTS to insert DHCP relay
information (DHCP option 82) in relayed DHCP packets.
Example:
This allows the DHCP server to store accurate information
about which CPE devices are using which cable modems.
Router(config)# ip dhcp relay information option
Router(config)# You should use this command if you are also using the
cable source-verify dhcp command.

Example:
Router#
853
Configuring Prefix-based Source Address Verification
Configuring Prefix-based Source Address Verification

To enhance security when using external DHCP servers, you can configure a prefix-based SAV with the
following procedure, beginning in global configuration (config) mode.
Procedure

prompted.
Example:
Router> enable
Router#

Example:

Router(config)#
Step 3 cable source-verify enable-sav-static Enables SAV prefix processing on the Cisco CMTS.
Example:
Router# cable source-verify enable-sav-static

Router(config)#
Step 4 cable source-verify group groupname Configures the SAV group name.
Example: groupname— Name of the SAV group with a maximum
length of 16 characters.
Router(config)# cable source-verify group sav-1
Step 5 prefix [ipv4_prefix/ipv4_prefix_length | Configures the IPv4 or IPv6 prefix associated with the SAV
ipv6_prefix/ipv6_prefix_length ] group.
Example: • ipv4_prefix— IPv4 prefix associated with the SAV
group, specified in the X.X.X.X/X format.
Router(config-sav)# prefix 10.10.10.0/24 • ipv4_prefix_length—Length of the IPv4 prefix. The
Router(config-sav)# valid range is from 0 to 32.
• ipv6_prefix—IPv6 prefix associated with a particular
SAV group, specified in the X:X:X:X::/X format.
• ipv6_prefix_length—Length of the IPv6 prefix. The
A maximum of four prefixes can be configured in a single
SAV group. These prefixes can be either IPv4s, IPv6s, or
a combination of both.
Step 6 exit Exits SAV configuration mode.

Example:
Router(config-sav)# exit
854
Configuring Optional DHCP Parameters

Example:

When using an external DHCP server, the Cisco CMTS supports a number of options that can enhance
operation of the cable network in certain applications. To configure these options, use the following procedure,
beginning in EXEC mode.
Procedure

prompted.
Example:
Router> enable
Router#

Example:

Router(config)#
Step 3 ip dhcp smart-relay (Optional) Enables the DHCP relay agent on the CMTS
to automatically switch a cable modem or CPE device to
Example:
a secondary DHCP server or address pool if the primary
DHCP server does not respond to three successive requests.
Router(config)# ip dhcp smart-relay
Router(config)# If multiple secondary servers have been defined, the relay
agent forwards DHCP requests to the secondary servers
in a round robin fashion.
Step 4 ip dhcp ping packet 0 (Optional) Instructs the DHCP server to assign an IP
address from its pool without first sending an ICMP ping
Example:
to test whether a client is already currently using that IP
address. Disabling the ping option can speed up address
Router(config)# ip dhcp ping packet 0
Router(config)# assignment when a large number of modems are trying to
connect at the same time. However, disabling the ping
option can also result in duplicate IP addresses being
assigned if users assign unauthorized static IP addresses
to their CPE devices.
855

Note By default, the DHCP server pings a pool
address twice before assigning a particular
address to a requesting client. If the ping is
unanswered, the DHCP server assumes that the
address is not in use and assigns the address to
the requesting client.
Step 5 ip dhcp relay information check (Optional) Configures the DHCP server to validate the
relay agent information option in forwarded BOOTREPLY
Example:
messages. Invalid messages are dropped.
Router(config)# ip dhcp relay information check Note The ip dhcp relay information command
Router(config)# contains several other options that might be
useful for special handling of DHCP packets.
See its command reference page in the Cisco
IOS-XE documentation for details.
Step 6 interface cable x/y Enters cable interface configuration mode for the specified
cable interface.
Example:

Router(config-if)#
Step 7 cable dhcp-giaddr policy [host | stb | mta | ps| profile Sets the DHCP GIADDR field for DHCP request packets
name] giaddr to the primary address for cable modems, and the
secondary address for CPE devices. This enables the use
Example:
of separate address pools for different clients.
Router(config-if)# cable dhcp-giaddr policy mta • host—Specifies the GIADDR for hosts.
172.1.1.10
Router(config-if)# • mta—Specifies the GIADDR for MTAs.
• ps—Specifies the GIADDR for PSs.
• stb—Specifies the GIADDR for STBs.
• profile nameSpecifies DHCP profile as control policy.
• giaddr—IP addresses of the secondary interface of
the bundle interface.
Note The cable dhcp-giaddr command also supports

the primary option. The primary option forces
all device types to use only the primary interface
IP address as GIADDR and not rotate through
the secondary address if the primary address
fails.
Step 8 cable helper-address address [cable-modem | host | mta (Optional) Enables load-balancing of DHCP requests from
| stb| profile name] cable modems and CPE devices by specifying different
DHCP servers according to the cable interface or
Example:
subinterface. You can also specify separate servers for
cable modems and CPE devices.
Router(config-if)# cable helper-address
856

10.10.10.13 • address = IP address of a DHCP server to which UDP
Router(config-if)#
broadcast packets will be sent via unicast packets.
• cable-modem = Specifies this server should only
accept cable modem packets (optional).
• host = Specifies this server should only accept CPE
device packets (optional).
• mta—(Optional) Specifies this server should only
accept MTA packets .
• stb —(Optional) Specifies this server should only
accept STB packets .
• profile name—(Optional) Specifies that only UDP
broadcasts with specific DHCP profile are forwarded.
Note If you do not specify an option, the

helper-address will support all cable devices,
and the associated DHCP server will accept
DHCP packets from all cable device classes.
Note If you specify only one option, the other types

of devices (cable modem, host, mta, or stb) will
not be able to connect with a DHCP server. You
must specify each desired option in a separate
command
.
Tip Repeat this command to specify more than one
helper address on each cable interface. You can
specify more than 16 helper addresses, but the
Cisco IOS software uses only the first 16 valid
addresses.
Tip If you configure different helper addresses on

different sub-bundles within a bundle, the cable
modem may not come online. We recommend
that you use the same helper address on all
sub-bundles within a bundle.
Note The ip helper-address command performs a

similar function to cable helper-address, but
it should be used on non-cable interfaces. The
cable helper-address command should be used
on cable interfaces because it is optimized for
the operation of DHCP requests on DOCSIS
networks.
857

Step 9 cable dhcp-giaddr policy Selects the control policy, so the primary address is used
for cable modems and the secondary addresses are used
Example:
for hosts and other customer premises equipment (CPE)
devices. This setting is typically used when the CMs on
Router(config-if)# cable dhcp-giaddr policy
the interface are configured for routing mode, so that the
cabel modems and hosts can use IP addresses on different
subnets.

Example:
Router(config)#

Example:
Router#

See the following configuration tasks required to configure time-of-day service, and TFTP service on a Cisco
CMTS:
This section provides examples for the following configurations:
ToD Server Example

The following example shows a typical ToD server configuration:
service udp-small-servers max-servers no-limit

cable time-server
These are the only commands required to enable the ToD server.
TFTP Server Example

The following lines are an excerpt from a configuration that includes a TFTP server. Change the files listed
with the tftp-server command to match the specific files that are on your system.
! Enable the user of unlimited small servers

!
858
...
! Enable the TFTP server and specify the files that can be
! downloaded along with their aliases
tftp-server disk0:gold.cm alias gold.cm
tftp-server disk0:silver.cm alias silver.cm
tftp-server disk0:bronze.cm alias bronze.cm
tftp-server disk0:ubr924-k8y5-mz.bin alias ubr924-codefile
tftp-server disk0:ubr925-k9v9y5-mz.bin alias ubr925-codefile
Description Link
ID and password.
Feature Information for the DHCP, ToD, and TFTP Services for
the CMTS Routers
DHCP, ToD, and TFTP services Cisco IOS XE Fuji 16.7.1 This feature was integrated into
Cisco IOS XE Fuji 16.7.1 on the
Broadband Routers.
859
Feature Information for the DHCP, ToD, and TFTP Services for the CMTS Routers
Sniff out boot file name from Cisco IOS XE Gibraltar 16.12.1 This feature was supported on the
DHCP process per CM Cisco cBR Series Converged
Broadband Routers.
860
CHAPTER 59
Virtual Interface Bundling
Virtual Interface Bundling allows supports combining multiple cable interfaces in a Cisco cBR series router
into a single logical bundle, so as to conserve IP address space and simplify network management.
Contents
• Information About Virtual Interface Bundling, on page 862
• Configuring Virtual Interface Bundling, on page 865
• Verfiying the Virtual Interface Bundling Configuration, on page 867
• Feature Information for Virtual Interface Bundling, on page 870
861
Information About Virtual Interface Bundling
Digital PICs:

Module:

Modules:
line card reload.
Information About Virtual Interface Bundling

862
Overview of Virtual Interface Bundling
Overview of Virtual Interface Bundling
Note All cable bundles are automatically converted and configured to virtual interface bundles. Any standalone
cable interfaces must be manually configured to be in a virtual bundle to operate properly.
Virtual interface bundling supports the following:

• Virtual interface bundling uses bundle interface and bundle members instead of primary or secondary
interfaces.
• A virtual bundle interface is virtually defined, as with IP loopback addresses.
• Virtual interface bundling supports bundle information in multiple show commands.
• The CISCO-DOCS-EXT-MIB is updated for cable helper-address and IPv6 DHCP relay configurations.
Virtual interface bundling prevents loss of connectivity on physical interfaces should there be a failure,
problematic online insertion and removal (OIR) of one line card in the bundle, or erroneous removal of
configuration on the primary interface.
Virtual interface bundling supports and governs the following Layer 3 settings for the bundle member interfaces:
• IP address
• IP helper-address
• source-verify and lease-timer functions
• cable dhcp-giaddr (The giaddr field is set to the IP address of the DHCP client.)
• Protocol Independent Multicast (PIM)
• Access control lists (ACLs)
• Sub-interfaces
• IPv6
• 1982 bytes layer 3 MTU.
Note In case customer wants to test 1982 bytes MTU by issuing a ping from CMTS
to DOCSIS 3.1 modem, cable mtu-override command needs to be configured.
After the test, please remove this configuration using no cable mtu-override
command. By default, there is no cable mtu-override configured in bundle
interface.
Note This virtual interface for the bundle should always remain on (enabled with no shutdown).
863
Guidelines for Virtual Interface Bundling
Guidelines for Virtual Interface Bundling

The following guidelines describe virtual interface bundling:
• Initial configuration of the first virtual bundle member automatically creates a virtual bundle interface.
• All cable bundles are automatically converted and configured to be in a virtual bundle after loading the
software image.
• Standalone cable interfaces must be manually configured to be in a virtual bundle to operate properly.
• The virtual bundle interface accumulates the counters from members; counters on member links are not
cleared when they are added to the bundle. If a bundle-only counter is desired, clear the bundle counter
on the members before adding them to the bundle, or before loading the image.
• This feature supports a maximum of 40 virtual interface bundles, with the numeric range from 1 to 255.
• The virtual bundle interface remains configured unless specifically deleted, even if all members in the
bundle are deleted.
• This feature supports subinterfaces on the virtual bundle interface.
• Bundle-aware configurations are supported on the virtual bundle interface.
• Bundle-unaware configurations are supported on each bundle member.
• While creating the virtual bundle interface, if the bundle interface existed in earlier Cisco IOS releases,
then the earlier cable configurations re-appear after upgrade.
• When using sub-bundle, all layer 3 configurations must be configured on sub-bundle, instead of main
bundle.
Virtual Interface Bundle-aware and Bundle-unaware Support

Virtual interface bundling uses two configurations: the virtual bundle itself, and the interfaces in that virtual
bundle, known as bundle members . The virtual interface bundle and bundle members are either aware of the
bundle, or unaware of the bundle, as follows.
• Bundle-aware features are maintained on the virtual bundle . These include:
• IP Address
• IP helper, cable helper
• Dhcp-giaddr
• Sub-interface
• Source verify
• Lease-query
• Address Resolution Protocol (Cable ARP filtering, which also bundles cable interfaces, and Proxy
ARP)
• Cable match
• Access Control Lists (ACLs)
• Protocol Independent Multicast (PIM)
• Cable Intercept
• Bundle-unaware features are maintained on the bundle members . These include:
864
Configuring Virtual Interface Bundling
• DS/US configurations
• HCCP redundancy
• Load balancing
• DMIC, tftp-enforce, shared-secret
• Spectrum management
• Admission control
• Intercept

To enable virtual interface bundling, and to reconfigure interface information on the Cisco CMTS as required,
you first configure the virtual interface bundle, then add additional bundle members for the specified virtual
bundle. Perform these steps on each interface, as needed for all virtual interface bundles.
Procedure

Router> enable

Example:
Step 3 interface bundle n Adds the selected interface to the virtual bundle. If this is
the first interface on which the virtual bundle is configured,
Example:
this command enables the bundle on the specified interface.
Router(config-if)# interface bundle 1 As many as 40 virtual interface bundles can be configured
on the Cisco CMTS. Numeric identifiers may range from
1 to 255.
Step 4 ip address address mask Use as needed after Cisco IOS upgrade.
Example: Configures the IP address for the specified interface and
virtual bundle.
255.255.255.0
Step 5 cable helper-address address [cable-modem | host | mta (Optional) Specifies the IPv4 DHCP server address.
| ps | stb]
Example:
Router(config-if)# cable helper-address

10.10.10.13
865

Step 6 cable dhcp-giaddr {primary | policy [host | stb | mta | Sets the DHCP GIADDR field for DHCP request packets.
ps | strict]}
Example:
Router(config-if)# cable dhcp-giaddr policy host
Step 7 cable source-verify dhcp (Optional) Ensures that the Cisco CMTS allows network
access only to those IP addresses that DCHP servers issued
Example:
to devices on this cable interface. The Cisco CMTS
Router(config-if)# cable source-verify dhcp examines the DHCP packets that pass through the cable
interfaces to build a database of which IP addresses are
valid on which interface. Drops traffic from all devices
with unknown IP addresses, but the Cisco CMTS also
sends a query to the DHCP servers for any information
about the device. If a DHCP server informs the Cisco
CMTS that the device has a valid IP address, the CMTS
then allows the device on the network.
Step 8 no cable arp (Optional) Blocks the static IPv4 CPE from coming online.
Also blocks Address Resolution Protocol (ARP) process
Example:
destined to devices on the cable network.
Router(config-if)# no cable arp
Note Use this command, together with the cable
source-verify dhcp command, to block certain
types of scanning attacks that attempt to cause
denial of service (DoS) on the Cisco CMTS.
Step 9 exit Exits the interface configuration mode and enters global
configuration mode.
Example:
Step 10 interface cable slot /subslot/port Enters interface configuration mode for the selected
interface, on which virtual interface bundling is to be
Example:
enabled.
Step 11 cable bundle n Configures a cable interface to belong to an interface

bundle, where n is the bundle number.
Example:
Step 12 no cable upstream n shut Use as needed after Cisco IOS upgrade.
Example: The cable interface must be enabled using the no shutdown
command for the specified cable interface.
Router(config-if)# no cable upstream 4 shut
n —Specifies the cable interface to enable for the virtual
bundle.
866
Verfiying the Virtual Interface Bundling Configuration

Example:
What to do next
To remove a virtual bundle from the interface, use the no interface bundle command in interface configuration
mode, where n specifies the bundle identifier:
no interface bundle n
If you remove a member from a bundle, the bundle remains on the interface (even if empty) until the bundle
itself is specifically removed.
For more information on configuring IPv6 parameters for bundle interface, see IPv6 on Cable feature guide.

• show ip interface brief—Displays the summary of interfaces.
Router# show ip interface brief
Interface IP-Address OK? Method Status Protocol

Cable3/0/0 Bundle1 YES unset up up
GigabitEthernet0 10.86.3.175 YES NVRAM administratively down down
Bundle1 100.1.2.1 YES manual up up
Bundle2 100.1.3.1 YES NVRAM up up
Dti4/1/0 unassigned YES unset administratively down down
Loopback1 1.2.3.4 YES NVRAM up up
Tunnel0 unassigned YES unset up up
• show running-config interface bundle n—Displays the information about the specified bundle.
Router# show running-config interface Bundle 1

!
interface Bundle2
ip address 100.1.3.1 255.255.255.0
no cable nd
no cable arp
cable ipv6 source-verify dhcp
cable source-verify dhcp
cable dhcp-giaddr primary
ipv6 address 2001:420:3800:910::1/64
867
ipv6 enable
ipv6 nd reachable-time 3600000
ipv6 nd cache expire 65536
ipv6 nd managed-config-flag
ipv6 nd other-config-flag
ipv6 nd ra interval msec 2000
no ipv6 redirects
ipv6 dhcp relay destination 2001:420:3800:800:250:56FF:FEB2:F11D
ipv6 dhcp relay destination vrf vrfa 2001:420:3800:800:250:56FF:FEB2:F11D
ipv6 dhcp relay source-interface Bundle2
arp timeout 2147483
• show ip interface brief | include bundle—Displays the bundle interface information.

Router# show ip interface brief | include Bundle
Bundle1 unassigned YES unset up up

Bundle1.1 100.1.2.1 YES NVRAM up up
Bundle2 100.1.3.1 YES NVRAM up up
• show running-config interface bundle n.n—Displays the subinterface information for the specified
bundle.
Router# show running-config interface bundle 1.1

!
interface Bundle1.1
ip address 100.1.2.1 255.255.255.0
ip pim sparse-mode
ip rip send version 2
ip rip receive version 2
ip rip authentication mode md5
ip rip authentication key-chain ubr-rip
ip igmp static-group 239.1.4.1 source 115.255.0.100
ip igmp static-group 230.1.4.1
ip igmp version 3
ip igmp query-interval 20
no cable arp
cable ipv6 source-verify dhcp
ipv6 address 2001:420:3800:909::1/64
ipv6 enable
ipv6 nd cache expire 65536
868
ipv6 nd prefix default no-advertise

no ipv6 redirects
ipv6 dhcp relay destination 2001:420:3800:800:250:56FF:FEB2:F11D link-address
2001:420:3800:909::1
ipv6 dhcp relay source-interface Bundle1
ipv6 rip CST enable
arp timeout 2147483
Related Documents
CMTS Command Reference Cisco IOS CMTS Cable Command Reference Guide
Standards and RFCs
Standards Title




Description Link
ID and password.
869
Feature Information for Virtual Interface Bundling
Feature Information for Virtual Interface Bundling

Table 154: Feature Information for Virtual Interface Bundling
Virtual interface bundling Cisco IOS XE Fuji This feature was integrated into Cisco IOS XE Fuji
16.7.1 16.7.1 on the Cisco cBR Series Converged Broadband
Routers.
870
CHAPTER 60
IPv6 on Cable
Cisco cBR series Converged Broadband Router supports full IPv6 functionality.
The IPv6 feature support available in the Cisco IOS software and for Cisco CMTS routers is extensive. This
document provides a comprehensive overview of all of the IPv6 features supported on the Cisco CMTS routers,
and their restrictions.
However, the details of every feature are not covered in this document. The areas of IPv6 protocol support
for the Cisco CMTS routers discussed in this document are classified by platform-independence or by
platform-specific feature support.
• Platform-independent IPv6 features—Describes IPv6 features that are supported in the Cisco IOS software
for several other Cisco platforms, and which generally do not have any platform-specific behavior or
configuration differences on the Cisco CMTS routers.
• Documentation about the restrictions for these platform-independent features can be found in the
Restrictions for IPv6 on Cable.
• Detailed information about these features, including conceptual and task-based configuration information,
is documented outside of this feature and in the Cisco IOS software documentation. Detailed information
about the location of this related documentation in the Cisco IOS software documentation is described
in the Feature Information for IPv6 on Cable.
Platform-specific IPv6 features—Describes IPv6 features that are specific to the cable technology area and
that only apply to the supported Cisco CMTS routers. The cable-specific IPv6 feature support includes new
or modified cable features supporting IPv6, and any transparent support of the IPv6 protocol in existing
(legacy) cable features on the CMTS router platforms.
• Restrictions for IPv6 on Cable, on page 873
• Information About IPv6 on Cable, on page 874
• How to Configure IPv6 on Cable , on page 883
• How to Verify IPv6 Dual Stack CPE Support , on page 898
871
• Configuration Examples for IPv6 on Cable, on page 900

• Verifying IPv6 on Cable, on page 910
• Supported MIBs, on page 912
• Feature Information for IPv6 on Cable , on page 913
Digital PICs:

Module:

Modules:
872
Restrictions for IPv6 on Cable
line card reload.
Restrictions for IPv6 on Cable

Multicast Restrictions
IPv6 multicast has the following behavior restrictions on the Cisco CMTS routers:
• ICMP redirects are not sent to the originating host if the packet is destined for another CPE behind the
same CM. All CPE-to-CPE traffic is processed by the Cisco CMTS router.
• IPv6 multicast forwarding is not supported in Parallel Express Forwarding (PXF), therefore, the IPv6
multicast forwarding performance is limited by the Router Processor (RP).
The following areas of IPv6 multicast are not supported by the Cisco CMTS routers:
• Address family support for Multiprotocol Border Gateway Protocol (MBGP)
• Bidirectional Protocol Independent Multicast (PIM)
• Bootstrap router (BSR)
• DOCSIS 3.0 encrypted multicast
• Explicit tracking of receivers
• IPv6 multicast echo
• Multicast Forwarding Information Base (MFIB) display enhancements
• Multicast use authentication and profile support
• PIM embedded rendezvous point
• Protocol Independent Multicast sparse mode (PIM-SM) accept register feature
• Reverse path forwarding (RPF) flooding of bootstrap router (BSR) packets
• Routable address hello option
• Source Specific Multicast (SSM) mapping for Multicast Listener Device (MLD) version 1 SSM
QoS Restrictions
In Cisco IOS-XE Release 16.5.1, the following fields are supported for theIPv6 downstream classification:
• IPv6 dest addr
873
Information About IPv6 on Cable
• ipv6 src addr

• IPv6 next header
• IPv6 traffic class
Note IPv6 flow label field is not supported.
The following areas of DOCSIS QoS are not supported by the Cisco CMTS routers:
• Upstream IPv6 Type of Service (ToS) overwrite
• Downstream IPv6 classification
Note ToS overwrite, DOCSIS classification, and Modular QoS CLI (MQC) on Gigabit Ethernet are supported.
Information About IPv6 on Cable

This section includes the following topics:
Features Supported
The following features are supported on the Cisco CMTS routers:
• Source verification of IPv6 packets in PXF
• ACL support for PXF
• ToS overwrite
• DOCSIS classification
• Modular QoS CLI (MQC) on Gigabit Ethernet
• IPv6 DOCSIS RP and LC HA and DCC
• MAC tapping of IPv6 packets
• Equal cost route load balancing of IPv6 packets destined to the backhaul
• IPv6 over IPv4 GRE tunnels
• Assignment of different prefixes to CM and CPE
• DHCPv6 over MPLS-VPN
• DHCPv6 relay prefix delegation VRF awareness
• Assignment of multiple IAPDs in a single advertise for each CPE.
• Assignment of multiple IA_NA and IAPD combinations to multiple CPEs behind a CM.
• The default maximum number of IA_NA and IAPD combinations for each cable modem is 16, including
link-local addresses.
• IPv6 Downstream ToS overwrite.
• DHCPv6 Client Link-Layer Address Option (RFC 6939).
874
Overview of the DOCSIS 3.0 Network Model Supporting IPv6
• Voice over IPv6. PacketCable Multimedia needs to be enabled before using this feature. For more
information, see http://www.cisco.com/c/en/us/td/docs/cable/cbr/configuration/guide/b_pktcbl_pktcblmm/
packetcable_and_packetcable_multimedia.html.
Overview of the DOCSIS 3.0 Network Model Supporting IPv6

Figure below illustrates the network model described by the DOCSIS 3.0 MAC and Upper Layer Protocols
Interface Specification.
Figure 26: DOCSIS 3.0 Network Model
In this model, the different devices support the following functions and services:
• Customer premises equipment (CPE)—Supports IPv4, IPv6, or dual stack operation.
Note Cisco cBR routers support CPE devices provisioned for dual stack operation.
• Cable modem (CM)—Functions as a bridging device and supports IPv4, IPv6, or dual stack operation.
• Cable modem termination system (CMTS) router—Works with the CM over the hybrid fiber coaxial
cable (HFC) network to provide IPv4 and IPv6 network connectivity to the provisioning servers and the
core data network behind the CMTS router.
The CMTS router supports IPv6 address assignment, routing, and forwarding of IPv6 multicast and unicast
packets.
Note The Cisco cBR router supports only a single DHCPv6 IPv6 address per client cable modem or CPE. This
restriction also applies to DHCPv6 Prefix Delegation prefixes. The reason for blocking more than one DHCPv6
address or prefix for a client is because the end-to-end network requires Source Address Selection (SAS) and
all nodes in the end-to-end network may not support the correct SAS. Moreover, the SAS specification (RFC
3484) is being revised by the IETF to define the correct SAS behavior.
875
Overview of Cable Modem IPv6 Address Provisioning
• Simple Network Management Protocol (SNMP) agent—Provides management tools to configure and
query devices on the network.
• Syslog server—Collects messages from the CM to support its functions.
• Dynamic Host Control Protocol (DHCP) server—The DOCSIS 3.0 network model supports both DHCPv4
and DHCPv6 servers to control the assignment of IP addresses.
• Time server—Provides the current time to the CM.
• Trivial File Transport Protocol (TFTP) server—Provides the CM configuration file.

Prior to cable modem registration with a CMTS router, the CMTS router sends a MAC Domain Descriptor
(MDD) message to provide information to the cable modem about its supported IP provisioning mode. You
configure the CMTS router provisioning mode using the cable ip-init interface configuration command. For
more information, see the Implementing IPv6 Addressing and Basic Connectivity for Cable Interfaces and
Bundles, on page 885.
The MDD contains an IP initialization parameters type length value (TLV) that defines the IP version,
management and alternate provisioning mode, and pre-registration downstream service ID (DSID) that is
used by cable modems that are capable of downstream traffic filtering.
When IPv6 is configured and active, for transmitting multicast DSID carrying IPv6 ND messages within a
MAC domain, the CMTS contains the pre-registration DSID TLV encoding (type 5.2) in the MDD message.
Note The Cisco CMTS routers do not support alternate provisioning mode or pre-registration DSID.
To support the MULPIv3.0 I04 or later version of the DOCSIS 3.0 MAC and Upper Layer Protocols Interface
Specification, the cable modem must attempt IPv6 address acquisition first.
Figure below illustrates the message flow between a cable modem, the CMTS router, and the DHCP server
when the cable modem is requesting an IPv6 address.
876
Figure 27: Message Flow for CM Provisioning of DHCP IPv6 Address Assignment
1. Link-local address assignment—The cable modem sends a Neighbor Solicit (NS) message with its link-local
address (LLA) to the CMTS router, which starts the duplicate address detection (DAD) process for that
LLA. The cable modem expects no response to the NS message.
2. Router discovery—The cable modem listens to the downstream to detect periodical Router Advertise
(RA) messages. When an RA message is detected, the cable modem uses the data in the RA message to
configure the default route. If an RA is not detected in a specified period, the cable modem sends a Router
Solicit (RS) message to find the router on the link (all nodes multicast). The CMTS router responds with
a Router Advertise (RA) message with theM and O bits set to 1 to instruct the CM to perform stateful
address configuration.
Note Cisco CMTS routers do not support SLAAC address assignment.
• DHCPv6—The cable modem sends a DHCPv6 Solicit message to the CMTS router to request an IPv6
address. The CMTS router relays this message to the DHCPv6 servers. The DHCPv6 servers send an
Advertise message indicating the server’s availability.
If the Rapid-Commit option is not used by the cable modem, then the cable modem responds to the Advertise
message of the server with a Request message to select the server that the CMTS router relays to the DHCPv6
server. If the Rapid-Commit option is used, then multiple DHCPv6 servers that could assign different addresses
to the same CPE must not be used.
The cable modem starts the DAD process to verify the uniqueness of the IPv6 address that the DHCPv6 server
assigns to it.
• TFTP and Time of Day (ToD)—Once the CM establishes IP connectivity, it sends a request to the TFTP
server to download a configuration file and requests the current time from the ToD server to complete
its boot process.
877
Overview of IPv6 Dual Stack CPE Support on the CMTS
Overview of IPv6 Dual Stack CPE Support on the CMTS

Most operating systems (OS) deployed at homes support dual stack operation. Cisco CMTS supports dual
stack, which is both IPv4 and IPv6 addressing on the CPE.
Overview of IPv6 over Subinterfaces

Cisco CMTS supports IPv6 over bundle subinterfaces. To configure IPv6 on bundle subinterfaces, see the
Implementing IPv6 Addressing and Basic Connectivity for Cable Interfaces and Bundles, on page 885 section.
For a CMTS bundle configuration example, see the Example: IPv6 over Subinterfaces , on page 900 section.
To enable IPv6 on subinterfaces, configure IPv6 on bundle subinterfaces and not the bundle. Reset the CMs
after the subinterface is configured.
Note MPLS VPN over subinterfaces for IPv6 is not supported.
Overview of High Availability on IPv6

Cisco cBR Series routers support IPv6 HA for the Supervisor card.
Note IPv6 DOCSIS HA and HCCP is supported on the Cisco CMTS routers.
The IPv6 HA feature support in Cisco CMTS routers covers the following capabilities:
• DOCSIS PRE HA
• DOCSIS line card HA
• Dynamic Channel Change (DCC)
DOCSIS PRE HA
The DOCSIS PRE HA has the following behavior restrictions and prerequisites on the Cisco CMTS routers:
• The CMs and CPEs should not go offline after a PRE switchover.
• The data structures of the IPv6 CM and CPE should be synchronized to the standby PRE before the PRE
switchover. Both dynamic and bulk synchronization is supported.
• Single stack, dual stack, and APM are supported for the CM.
• Single stack and dual stack provisioning modes are supported on the CPE.
• After a PRE switchover, the IPv6 neighbor entries are rebuilt by Neighbor Discovery (ND) messages on
the standby PRE, and the IPv6 routes are rebuilt after converging the routing protocol.
DOCSIS Line Card HA

The DOCSIS line card HA has the following behavior restrictions and prerequisites on the Cisco CMTS
routers:
• The data structures of the IPv6 CM and CPE should be synchronized to the standby line card before the
line card switchover. Both dynamic and bulk synchronization is supported.
878
Dynamic Channel Change
• The CMs and CPEs should not fall offline after a line card switches over and reverts; the CMs and CPEs
should behave the same as before the switchover.
• The DOCSIS line card HA supports both 4+1 and 7+1 redundancy.
• Traffic outages in IPv6 may be longer because traffic recovery occurs only after converging the routing
protocol.
Dynamic Channel Change

The Dynamic Channel Change (DCC) feature is supported on Cisco CMTS routers.
Note The behavior of the DCC for single stack IPv6 CM and CPE, or dual stack CM and CPE is the same as that
of a single stack IPv4 CM and CPE.
The IPv6 and IPv4 DCC functionality has the following behavior restrictions and prerequisites on the Cisco
CMTS routers:
Narrowband Cable Modem

• If the source and destination MAC domains of the CM are on the same line card, DCC initialization
techniques 0, 1, 2, 3, and 4 are used to move the CM and its associated CPE from one upstream or
downstream to another; or move the CM and CPE from one upstream and downstream combination to
another.
• If the source and destination MAC domains of the CM are on different line cards, you can use only the
DCC initialization technique 0 to move the CM and its associated CPE across line cards.
Wideband Cable Modem

• If the source and destination MAC domains of the CM are on the same line card, DCC initialization
techniques 0, 1, 2, 3, and 4 are used to move the CM and its associated CPE from one upstream to another.
• If the primary downstream of a CM is changed after DCC, you can use only the DCC initialization
technique 0 to move the CM and its associated CPE across line cards.
Overview of IPv6 VPN over MPLS

The Multiprotocol Label Switching (MPLS) VPN feature represents an implementation of the provider edge
(PE) based VPN model. This document describes the IPv6 VPN over MPLS (6VPE) feature.
The 6VPE feature allows Service Providers to provide an IPv6 VPN service that does not require an upgrade
or reconfiguration of the PE routers in the IPv4 MPLS Core. The resulting IPv6 VPN service has a configuration
and operation which is virtually identical to the current IPv4 VPN service.
In principle, there is no difference between IPv4 and IPv6 VPNs. In both IPv4 and IPv6, the multiprotocol
BGP is the core of the MPLS VPN for IPv6 (VPNv6) architecture. It is used to distribute IPv6 routes over
the service provider backbone using the same procedures to work with overlapping addresses, redistribution
policies, and scalability issues.
Figure below illustrates the 6PE/6VPE reference architecture diagram.
879
Cable Monitor
Figure 28: 6PE/6VPE Reference Architecture
Cable Monitor
The Cable Monitor and Intercept features for Cisco CMTS routers provide a software solution for monitoring
and intercepting traffic coming from a cable network. These features give service providers Lawful Intercept
capabilities.
For more information, see the Cable Monitor and Intercept Features for the Cisco CMTS Routers guide.
Overview of IPv6 CPE Router Support on the Cisco CMTS

The IPv6 CPE router support is provided on the Cisco CMTS. The IPv6 CPE router is a node primarily for
home or small office use that connects the end-user network to a service provider network. It is also referred
to as the home router.
The IPv6 CPE router is responsible for implementing IPv6 routing; that is, the IPv6 CPE router looks up the
IPv6 destination address in its routing table and decides to which interface the packet should be sent.
The IPv6 CPE router performs the following functions:
• Provisions its WAN interface automatically.
• Acquires IP address space for provisioning of its LAN interfaces.
• Fetches other configuration information from the service provider network.
880
Support for IPv6 Prefix Stability on the CMTS
Figure below illustrates the CPE router reference architecture diagram between the CPE router, the CMTS,
and the DHCPv6 server (CNR) when the CM is requesting an IPv6 address.
Figure 29: IPv6 CPE Router Reference Architecture
As part of the IPv6 CPE Router Support feature, the following enhancements are introduced:
• Support to IPv6 router devices.
• IPv6 Prefix Delegation (PD) High Availability.
• Prefix awareness support in IPv6 cable source-verify, Cable DOCSIS filters code, and packet intercepts.
Support for IPv6 Prefix Stability on the CMTS

IPv6 prefix stability is supported on the Cisco CMTS as specified in DOCSIS 3.0 MULPI
CM-SP-MULPIv3.0-I15-110210 standard. The IPv6 prefix stability allows an IPv6 home router to move from
one Cisco CMTS to another while retaining the same prefix.
The multiple service operators (MSOs) can use this feature to allow their business customers (with IPv6
routers) to retain the same IPv6 prefix during a node split.
Configurable DHCPv6 Relay Address

The DHCPv6 Cisco IOS relay agent on the Cisco CMTS router sends relay-forward messages from a source
address to all configured relay destinations. The source address is either an IPv6 address provisioned on the
network interface or a Cisco CMTS WAN IPv6 address. The relay destination can be a unicast address of a
server, another relay agent, or a multicast address. The relay-forward messages contain specific DHCPv6
link-addresses.
A DHCP relay agent is used to relay messages between the client and server. A client locates a DHCP server
using a reserved, link-scoped multicast address.
Use the cable ipv6 dhcp-insert hostname command to configure the Cisco cBR-8 routers for inserting
descriptors into DHCPv6 packets and to insert the specific hostname.
881
Support for Multiple IAPDs in a Single Advertise
DHCPv6 Client Link-Layer Address Option (RFC 6939)

Cisco IOS-XE Releases support DHCPv6 Client Link-Layer Address Option (RFC 6939). It defines an optional
mechanism and the related DHCPv6 option to allow first-hop DHCPv6 relay agents (relay agents that are
connected to the same link as the client) to provide the client's link-layer address in the DHCPv6 messages
being sent towards the server.
The format of the DHCPv6 Client Link-Layer address option is shown below.
Name Description
option-code OPTION_CLIENT_LINKLAYER_ADDR (79)
option-length 2 + length of MAC address
link-layer type CPE or CM MAC address type. The link-layer type MUST be a valid
hardware type assigned by the IANA, as described in RFC0826.
link-layer address MAC address of the CPE or CM.
Note RFC6939 is enabled by default. It can not be enabled/disabled by any CLI command.
To configure DHCPv6 Relay Address on the Cisco CMTS bundle subinterfaces, see the Configuring DHCPv6
Relay Agent, on page 896 section.
For more information about the DHCPv6 client, server, and relay functions, see the Implementing DHCP for
IPv6 chapter in the IPv6 Implementation Guide, Cisco IOS XE Release 3S.
Support for Multiple IAPDs in a Single Advertise

Assignment of multiple IA_NA and IAPD to CPEs behind a CM is supported on Cisco CMTS routers. This
feature includes support for link-local addresses and IA_NA and IAPD. However, a CM can be assigned only
one IA_NA. This IA_NA can be either static or DHCP-assigned.
The CPEs behind the CM can request for multiple DHCPv6 IA_NAs and IAPDs. Each CPE is assigned
multiple IA_NAs and IAPDs in a single Advertise/Reply message. Each CPE request for IA_NA and IAPD
is treated as a separate Advertise/Reply message.
882
IPv6 Neighbor Discovery Gleaning
IPv6 Neighbor Discovery Gleaning

The IPv6 Neighbor Discovery (ND) Gleaning feature enables Cisco CMTS routers to automatically recover
lost IPv6 CPE addresses and update the CPE records in the Cisco CMTS subscriber database. The Cisco
CMTS router gleans only the solicited neighbor advertise (NA) messages transmitted in the upstream direction.
IPv6 ND gleaning is similar to Address Resolution Protocol (ARP) gleaning for IPv4 CPE recovery.
The IPv6 ND Gleaning feature is configured by default on Cisco CMTS routers. To disable this feature, use
the no form of the cable nd command in bundle interface configuration mode. The cable nd command adds
a CPE (host behind a cable modem) to the Cisco CMTS subscriber database. This command does not impact
the IPv6 ND protocol operation on the router.
Note The IPv6 ND Gleaning feature does not support gleaning of NA messages transmitted in the downstream
direction.
How to Configure IPv6 on Cable

This section includes the following tasks:
Configuring IPv6 Switching Services

The CMTS routers support forwarding of unicast and multicast IPv6 traffic using either Cisco Express
Forwarding for IPv6 (CEFv6) or distributed CEFv6 (dCEFv6):
• CEFv6—All CMTS platforms
• dCEFv6—Cisco uBR10012 universal broadband router only
The CMTS routers also support Unicast Reverse Path Forwarding (RPF), as long as you enable Cisco Express
Forwarding switching or distributed Cisco Express Forwarding switching globally on the router. There is no
need to configure the input interface for Cisco Express Forwarding switching. As long as Cisco Express
Forwarding is running on the router, individual interfaces can be configured with other switching modes.
To configure forwarding of IPv6 traffic using Cisco Express Forwarding or distributed Cisco Express
Forwarding (supported on the Cisco uBR10012 universal broadband router only) on the CMTS routers, you
must configure forwarding of IPv6 unicast datagrams using the ipv6 unicast-routing global configuration
command, and you must configure an IPv6 address on the bundle interface using the ipv6 address command.
The show ipv6 cef platform command is supported on the Cisco CMTS platform. You can use the show
ipv6 cef platform command for debugging purposes.
Before you begin

• You must enable Cisco Express Forwarding for IPv4 globally on the router by using the ip cef or ip cef
distributed command before configuring Cisco Express Forwarding v6 or distributed Cisco Express
Forwarding v6.
883
Configuring IPv6 Switching Services
Note The ip cef command is enabled by default on all Cisco CMTS routers. Therefore, you only must configure
the command if it has been disabled. However, you must explicitly configure the ip cef distributed command
on a Cisco uBR10012 universal broadband router if you want to run distributed CEF switching services for
IPv4 or IPv6.
• You must configure forwarding of IPv6 unicast datagrams using the ipv6 unicast-routing global
configuration command.
• You must configure IPv6 addressing on the cable bundle interface.
• CEF switching is required for Unicast RPF to work.
Procedure

prompted.
Example:
Router> enable

Example:
Step 3 Do one of the following: Enables Cisco Express Forwarding.

• ip cef or
• ip cef distributed Enables distributed Cisco Express Forwarding for IPv4
Example: datagrams.
Note For CMTS routers, distributed Cisco Express
Router(config)# ip cef
Forwarding is supported only on a Cisco
or uBR10012 universal broadband router.
Router(config)# ip cef distributed
Step 4 Do one of the following: Enables Cisco Express Forwarding v6.

• ipv6 cef or
• ipv6 cef distributed Enables distributed Cisco Express Forwarding v6 for IPv6
Example: datagrams.
Note For CMTS routers, distributed Cisco Express
Router(config)# ipv6 cef
Forwarding v6 is supported only on a Cisco
or uBR10012 universal broadband router.
Router(config)# ipv6 cef distributed
884
Implementing IPv6 Addressing and Basic Connectivity for Cable Interfaces and Bundles

Step 5 ipv6 unicast-routing Enables the forwarding of IPv6 unicast datagrams.
Example:
Router(config)# ipv6 unicast-routing
What to do next
• (Optional) Enable IPv6 multicast routing using the ipv6 multicast-routing command in global
configuration mode and configure other multicast features.
Implementing IPv6 Addressing and Basic Connectivity for Cable Interfaces

and Bundles
Configuring the Cable Virtual Bundle Interface
The only required IPv6 configuration on a cable line card interface is the IP provisioning mode. The remainder
of the IPv6 features are configured at the virtual bundle interface, which is then associated with a particular
cable line card interface to establish its configuration.
Most of the IPv6 features that are supported in interface configuration mode (both cable-specific as well as
platform-independent IPv6 features) are configured at a cable bundle interface.
The Cisco CMTS routers support IPv6 routing on the bundle interface and map both IPv6 unicast and multicast
addresses into the cable bundle forwarding table, for packet forwarding.
Each bundle interface has a unique link-local address (LLA) to support link-local traffic when IPv6 is enabled.
Cisco CMTS routers can support a maximum of 40 active bundle interfaces, which also translates to a maximum
of 40 active IPv6-enabled bundle interfaces.
IPv6 commands can be configured on multiple bundle subinterfaces.
Before you begin

The cable ipv6 source-verify and cable nd commands are not compatible with each other in Cisco IOS
release 12.2(33)SCE and later. You must disable IPv6 ND gleaning using the no form of the cable nd command
before using the cable ipv6 source-verify command to ensure that only DHCPv6 and SAV-based CPEs can
send traffic on the router.
Restriction All multicast traffic is flooded onto bundle member interfaces.
Procedure

prompted.
Example:
885
Configuring the IP Provisioning Mode and Bundle on the Cable Interface
Router> enable

Example:
Step 3 interface bundle n Specifies the cable bundle interface and enters interface
configuration mode, where n specifies the number of the
Example:
bundle interface.
Router(config)# interface bundle 1
Step 4 ipv6 addressipv6-prefix/prefix-length [eui-64 ] Specifies an IPv6 network assigned to the interface and
enables IPv6 processing on the interface. The ipv6 address
Example:
eui-64 command configures site-local and global IPv6
addresses with an interface identifier (ID) in the low-order
Router(config-if)# ipv6 address 2001:DB8::/32
eui-64
64 bits of the IPv6 address. You need to specify only the
64-bit network prefix for the address; the last 64 bits are
automatically computed from the interface ID.
Step 5 ipv6 addressipv6-prefix /prefix-length link-local (Optional) Specifies an IPv6 address assigned to the
interface and enables IPv6 processing on the interface. The
Example:
ipv6 address link-local command configures a link-local
address on the interface that is used instead of the link-local
Router(config-if)# ipv6 address 2001:DB8::/32
link-local
address that is automatically configured, when IPv6 is
enabled on the interface (using the ipv6 enable command).
Step 6 ipv6 enable Automatically configures an IPv6 link-local address on the

interface while also enabling the interface for IPv6
Example:
processing. The link-local address can be used only to
communicate with nodes on the same link.
Router(config-if)# ipv6 enable
Step 7 cable ipv6 source-verify (Optional) Enables source verification of MAC

address-MD-SID-IPv6 address binding packets received
Example:
by a cable interface upstream on Cisco CMTS routers.
Router(config-if)# cable ipv6 source-verify
What to do next
• Configure the desired platform-independent IPv6 features on the bundle interface, such as Neighbor
Discovery and DHCPv6 features.
• Configure the IP provisioning mode and bundle on the cable interface.

The CMTS routers allow you to configure cable interfaces to support cable modems provisioned for both
IPv4 and IPv6 addressing support (known as “dual stack”), only IPv4 addressing, or only IPv6 addressing.
886
Prior to cable modem registration, the CMTS router sends its supported provisioning mode to the cable modem
in the MDD message.
In addition to configuring the provisioning mode on the cable interface, you must also associate the cable
interface with a cable bundle. You perform most of the other IPv6 feature configuration at the bundle interface.
Note This section describes only the commands associated with establishing IPv6 support on a CMTS router. Other
cable interface commands that apply but are optional are not shown, such as to configure upstream and
downstream features.
Before you begin

Configuration of a bundle interface is required.
Step 1 enable
Example:
Router> enable

Example:
Step 3 interface cable {slot / port | slot / subslot /port }

Example:
Specifies the cable interface line card, where:

The valid values for these arguments are dependent on your CMTS router and cable interface line card. Refer to the
hardware documentation for your router chassis and cable interface line card for supported slot and port numbering.
Step 4 cable ip-init {apm | dual-stack | ipv4 | ipv6}

Example:
Router(config-if)# cable ip-init ipv6
Specifies the IP provisioning mode supported by the cable interface, where:
Step 5 cable bundlen

Example:
Router(config)# cable bundle 1
887
Enabling MDD with Pre-Registration DSID
Associates the cable interface with a configured virtual bundle interface, where n specifies the number of the bundle
interface.
What to do next
• Proceed to configuring any other cable interface features that you want to support, such as upstream and
downstream features. For more information about the other cable interface features, refer to the Cisco
IOS CMTS Cable Software Configuration Guide.
• Proceed to configure other optional IPv6 cable features.
Enabling MDD with Pre-Registration DSID

When only IPv4 is configured and active, where the IP provisioning mode is IPv4, for Cable Modems to come
online, the pre-registration DSID (TLV 5.2) is required in the MAC Domain Descriptor (MDD) message. To
enable this pre-registration DSID, use the following command.
By default, this command is disabled.
Router#configure terminal
Router(config)#cable ipv4-prereg-dsid
Router(config)#end
Configuring IPv6 Cable Filter Groups

The Cisco CMTS router supports IPv6 cable filter group capability with IPv6 filter options.
Configuring IPv6 Cable Filter Groups

The Cisco CMTS router supports IPv6 cable filter group capability with IPv6 filter options.
Cable Filter Groups and the DOCSIS Subscriber Management MIB

Cable subscriber management is a DOCSIS 1.1 specification, which can be established using the following
configuration methods:
• CMTS router configuration (via CLI)
• SNMP configuration
• DOCSIS 1.1 configuration file (TLVs 35, 36, and 37)
This section describes the IPv6 cable filter group feature support of the packet filtering portion of the DOCSIS
Subscriber Management MIB (DOCS-SUBMGMT-MIB) using configuration commands on the CMTS routers.
This IPv6 cable filter group support extends filter classifiers with IPv6 addressing options for CM and CPE
traffic, but is independent of DOCSIS IPv6 classifiers, which are used to match packets to service flows.
Configuration of IPv6 cable filter groups on the CMTS routers is supported according to the following
guidelines:
• A cable filter group consists of a set of cable filter group commands that share the same group ID.
• Separate indexes can be used to define different sets of filters for the same group ID. This can be used
to define both IPv4 and IPv6 filters to the same filter group.
• CMs can be associated with one upstream and one downstream filter group.
888
• Upstream traffic—All traffic coming from CMs is evaluated against the assigned upstream filter
group that is configured by the cable submgmt default filter-group cm upstream command.
• Downstream traffic—All traffic going to CMs is evaluated against the assigned downstream filter
group that is configured by the cable submgmt default filter-group cm downstream command.
• CPEs can be associated with one upstream and one downstream filter group.
• Upstream traffic—All traffic coming from CPEs is evaluated against the assigned upstream filter
group that is configured by the cable submgmt default filter-group cpe upstream command.
• Downstream traffic—All traffic going to CPEs is evaluated against the assigned downstream filter
group that is configured by the cable submgmt default filter-group cpe downstream command.
Note Because TLVs 35, 36, and 37 do not apply to DOCSIS 1.0 CM configuration files, the only way to enable
cable subscriber management for a DOCSIS 1.0 CM is to configure it explicitly on the Cisco CMTS router
and activate it by using the cable submgmt default active global configuration command.
Before you begin

You must create the cable filter group before you assign it to a CM or CPE upstream or downstream.
Restriction • Chained IPv6 headers are not supported.

• An individual filter group index cannot be configured to support both IPv4 and IPv6 versions at the same
time. If you need to support IPv4 and IPv6 filters for the same filter group, then you must use a separate
index number with the same filter group ID, and configure one index as ip-version ipv4, and the other
index as ip-version ipv6.
• Only a single upstream and a single downstream filter group can be assigned for CM traffic.
• Only a single upstream and a single downstream filter group can be assigned to CPEs attached to a CM
such that all CPEs behind a CM share a common filter group.
• For the filter group to work for CMs, a CM must re-register after the CMTS router is configured for the
filter group.
• If parallel eXpress forwarding (PXF) is configured on the Cisco uBR10012 router, either the cable filter
group commands or the interface ACL (ip access-list) command can be configured.
• If you do not provision TLVs 35, 36, and 37 in the DOCSIS CM configuration file, then you must activate
the functionality by specifying the cable submgmt default active global configuration command on the
CMTS router.
Procedure

prompted.
Example:
Router> enable
889

Example:
Step 3 cable filter groupgroup-id (Optional) Specifies the TCP/UDP destination port number
indexindex-numdest-portport-num that should be matched. The valid range is from 0 to 65535.
The default value matches all TCP/UDP port numbers
Example:
(IPv4 and IPv6 filters).
Router(config)# cable filter group 1 index 1
dest-port 69
Step 4 cable filter group group-id index index-num ip-proto (Optional) Specifies the IP protocol type number that
proto-type should be matched. The valid range is from 0 to 256, with
a default value of 256 that matches all protocols (IPv4 and
Example:
IPv6 filters).
Router(config)# cable filter group 1 index 1 Some commonly used values are:
ip-proto 17
Step 5 cable filter group group-id index index-num ip-tos (Optional) Specifies a ToS mask and value to be matched
tos-mask tos-value (IPv4 and IPv6 filters):
Example: The tos-mask is logically ANDed with the tos-value and
compared to the result of ANDing the tos-mask with the
Router(config)# cable filter group 1 index 1 actual ToS value of the packet. The filter considers it a
ip-tos 0xff 0x80 match if the two values are the same.
The default values for both parameters matches all ToS
values.
Step 6 cable filter group group-id index index-num ip-version Specifies that this filter group is an IPv6 filter group.
ipv6
Example:

ip-version ipv6
Step 7 cable filter group group-id index index-num (Optional) Specifies the action that should be taken for
match-action {accept | drop} packets that match this filter (IPv4 and IPv6 filters):
Example:

match-action drop
Step 8 cable filter group group-id index index-num src-port (Optional) Specifies the TCP/UDP source port number
port-num that should be matched. The valid range is from 0 to 65535.
The default value matches all TCP/UDP port numbers
Example:
(IPv4 and IPv6 filters).
src-port 50
890

Step 9 cable filter group group-id index index-num status (Optional) Enables or disables the filter (IPv4 and IPv6
{active | inactive} filters):
Example: Note You must create a filter group using at least one
of the other options before you can use this
Router(config)# cable filter group 1 index 1 command to enable or disable the filter.
status inactive
Step 10 cable filter group group-id index index-num tcp-flags (Optional) Specifies the TCP flag mask and value to be
flags-mask flags-value matched (IPv4 and IPv6 filters):
Example:

tcp-flags 0 0
Step 11 cable filter group group-id index index-num (Optional) Specifies the IPv6 destination address that
v6-dest-address ipv6-address should be matched using the format X:X:X:X::X (IPv6
filters only).
Example:

v6-dest-address 2001:DB8::/32
Step 12 cable filter group group-id index index-num (Optional) Specifies the length of the network portion of
v6-dest-pfxlen prefix-length the IPv6 destination address. The valid range is from 0 to
128.
Example:

v6-dest-pfxlen 64
Step 13 cable filter group group-id index index-num (Optional) Specifies the IPv6 source address that should
v6-src-address ipv6-address be matched using the format X:X:X:X::X (IPv6 filters
only).
Example:

v6-src-address 2001:DB8::/32
Step 14 cable filter group group-id index index-num (Optional) Specifies the length of the network portion of
v6-src-pfxlen prefix-length the IPv6 source address. The valid range is from 0 to 128
(IPv6 filters only).
Example:

v6-src-pfxlen 48
Step 15 cable submgmt default filter-group {cm | cpe} Applies a defined filter group (by specifying its group-id)
{downstream | upstream} group-id to either a CM or its CPE devices, for downstream or
upstream traffic.
Example:
Router(config)# cable submgmt default filter-group

cm upstream 1
891

Step 16 cable submgmt default active (Required if you do not provision TLVs 35, 36, and 37 in
the DOCSIS 1.1 CM configuration file)
Example:
Enables filters and allows the CMTS to manage the CPE
Router(config)# cable submgmt default active devices for a particular CM (sets the
docsSubMgtCpeActiveDefault attribute to TRUE).
Example
The following example shows how to create an IPv6 filter group with ID 254 and an index number
of 128. The ip-version ipv6 keywords must be configured to create the IPv6 filter group; otherwise,
the default is an IPv4 filter group:
configure terminal
cable filter group 254
index 128 v6-src-address 2001:DB8::/32
index 128 v6-src-pfxlen 48
index 128 v6-dest-address 2001:DB8::/32
index 128 v6-dest-pfxlen 64
index 128 ip-version ipv6
index 128 match-action drop
cable submgmt default filter-group cm upstream 254
This group filters CM upstream traffic and drops any packets with an IPv6 source address of
2001:33::20B:BFFF:FEA9:741F (with network prefix of 128) destined for an IPv6 address of
2001:DB8::/32 (with network prefix of 128).
All of the cable filter group commands are associated by their group ID of 254 (and index of 128),
and the cable submgmt default filter-group command applies the corresponding filter group ID of
254 to CM upstream traffic.
To monitor your cable filter group configuration, use forms of the show cable filter command as
shown in the following examples. In these output examples, the output from the show cable filter,
show cable filter group 254, and show cable filter group 254 index 128 commands all display the
same information because there is currently only a single filter group and index defined.
Note The “Use Verbose” string appears in the output area of the SrcAddr/mask and DestAddr/Mask fields
suggesting use of the show cable filter group verbose form of the command to display the complete
IPv6 address.
Router# show cable filter

Filter SrcAddr/Mask DestAddr/Mask Prot ToS SPort DPort TCP Action Status
Grp Id v6 Flags
254 128Y Use Verbose
Use Verbose
drop active
892
Router# show cable filter group 254

Grp Id v6 Flags
254 128Y Use Verbose Use Verbose drop active
Router# show cable filter group 254 index 128
Grp Id v6 Flags
254 128Y Use Verbose Use Verbose drop active
Router# show cable filter group 254 index 128 verbose
Filter Group : 254
Filter Index : 128
Filter Version : IPv6
Matches : 0
Source IPv6 address : 2001:DB8::/32
Destination IPv6 address : 2001:DB8::/32
Match action : drop
Status : active
You should configure the cable filter group commands prior to applying a filter group using the cable
submgmt default filter-group command. Failure to do so results in the following message, and an association
to a filter group that is undefined:
Router(config)# cable submgmt default filter-group cm upstream 100

Default value set to a nonexistent filter-group 100.
Configuring IPv6 Domain Name Service

Cisco IOS releases support the domain name service (DNS) capability for devices using IPv6 addressing on
the Cisco CMTS routers.
DNS simplifies the identification of cable devices by associating a hostname with what can often be a complex
128-bit IPv6 address. The hostname can then be used in place of the IPv6 address within the CMTS router
CLI that supports use of hostnames.
There are two separate DNS caches supported on a CMTS router—an IOS DNS cache and a cable-specific
DNS cache that stores IPv6 addresses learned by the CMTS router for CMs and CPEs.
In this phase of the IPv6 DNS service on cable, the DNS server is queried for domain name information as
needed when you use the show cable modem domain-name command. When you use this command, the
following actions take place:
1. The CMTS router checks whether CMs are online. If a CM is online, the CMTS router uses the
corresponding IPv6 address assigned to the CM and looks up its domain name from the IOS DNS cache.
2. If no match is found, the CMTS router sends a DNS-QUERY message with the IPv6 address of the CM
to the DNS server, which tries to resolve the domain name.
3. When the DNS reply is received, the CMTS router stores the domain name in the IOS DNS cache for
each IPv6 address.
4. The CMTS router also stores the fully-qualified domain name (FQDN) that is replied by the DNS server
in the cable-specific DNS cache.
Note Running the no ip domain lookup command turns off the DNS resolution.
893
Configuring IPv6 Domain Name Service
The following platform-independent Cisco IOS-xe software commands are supported using host names by
the CMTS router for IPv6 DNS on cable:
• connect
• ping ipv6
• show hosts
• telnet
• traceroute
Before you begin

• A DNS server must be configured.
• You must identify and assign the host names to the IPv6 addresses. If you are using the Cisco DNS
server, use the ip host global configuration command to map hostnames to IP addresses.
• You must configure the DNS server using the ip name-server global configuration command before
use of DNS host names (or domains) are available in the supported commands.
• The show cable modem domain-name command must be run first on the Route Processor (RP) of the
CMTS router before any domain name can be used as part of a cable command.
Restriction • DNS for cable devices using IPv4 addressing is not supported.
• Due to column size limitations within the command-line interface (CLI), the domain name display is
limited to 32 characters. Therefore, the entire domain name cannot always be seen in CMTS router
command output.
• Only those cable devices where IPv6 address learning takes place are supported, such as acquiring an
IPv6 address through DHCPv6 or the IPv6 (ND) process.
• The cable-specific DNS cache is only updated when you use the show cable modem domain-name
command on the Route Processor (RP). A DNS-QUERY can only be sent on the RP using this command,
therefore the DNS cache cannot update if you use the show cable modem domain-name command on
a line card console. The output is displayed on the RP only.
• The cable-specific DNS cache does not store partially qualified domain names, only FQDNs are stored.
• The cable-specific DNS cache is not associated with the timeouts that apply to the IOS DNS cache.
Therefore, a cable-specific DNS cache entry is not removed when an IOS DNS cache timeout occurs for
that device. The cable-specific DNS cache is only updated when you use the show cable modem
domain-name command.
• The CMTS router supports storage of only one domain name per IPv6 address in the cable-specific DNS
cache.
• Domain names for the link local address are not supported.
• The no ip domain-name command disables DNS lookup.
894
Configuring IPv6 Source Verification
Procedure

prompted.
Example:
Router> enable

Example:
Step 3 ip name-server [vrf vrf-name] server-address1 Specifies the address of one or more name servers to use
[server-address2...server-address6] for name and address resolution.
Example:
Router(config)# ip name-server 2001:DB8::/32
Step 4 exit Leaves global configuration mode and enters privileged

EXEC mode.
Example:
Step 5 show cable modem domain-name Updates the cable-specific DNS cache and displays the
domain name for all CMs and the CPE devices behind a
Example:
CM.
Router# show cable modem domain-name
Configuring IPv6 Source Verification

Typically, the IPv6 source verification feature is enabled on a cable bundle interface. From there, the cable
interface is associated with the virtual bundle interface to acquire its configuration.
When you enable IPv6 source verification on a cable line card interface, the source verification routine verifies
the MAC address-MD-SID-IP binding of the packet. If the source verification succeeds, the packet is forwarded.
If the verification fails, the packet is dropped.
When a CM is operating as a bridge modem device, then the CMTS router verifies all the IPv6 addresses
related to that CM and the CPEs behind that CM.
The cable ipv6 source-verify command controls only the source verification of IPv6 packets. For IPv4-based
source verification, use the cable source-verify command, which also supports different options.
For more information about how to configure IPv6 source verification on a bundle interface, see the Configuring
the Cable Virtual Bundle Interface, on page 885.
Restrictions
Source verification of IPv6 packets occurs only on packets in the process-switched path of the Route Processor
(RP).
895
Configuring IPv6 VPN over MPLS
Configuring IPv6 VPN over MPLS

The Cisco CMTS routers support the IPv6 VPN over MPLS (6VPE) feature. Implementing this feature includes
the following configuration tasks.
• Configuring a VRF instance for IPv6
• Binding a VRF to an interface
• Creating a subinterface
• Configuring a static route for PE-to-CE-routing
• Configuring eBGP PE-to-CE routing sessions
• Configuring the IPv6 VPN address family for iBGP
• Configuring route reflectors for improved scalability
• Configuring Internet access
For detailed information about the configuration examples, see Configuration Examples for IPv6 on Cable,
on page 900.
Note The IPv6 address of the sub-bundle interface (to which the CM is connected) is used in the DHCPv6 relay
packet of the CPE DHCPv6 request. If the DHCPv6 packet has to go from one VRF interface to another, the
IPv6 address of each VRF interface should be configured on the Cisco CMTS to establish connectivity.
Configuring DHCPv6 Relay Agent

The Cisco CMTS router supports DHCPv6 relay agent to forward relay-forward messages from a specific
source address to client relay destinations.
Perform the following steps to enable the DHCPv6 relay agent function and specify relay destination addresses
on an interface.
Before you begin

The relay-forward messages must contain specific source IPv6 address. This is required because the firewall
deployed between the Cisco CMTS DHCPv6 relay agent and the DHCPv6 server expects only one source
address for one Cisco CMTS bundle interface.
Restriction If you change one or more parameters of the ipv6 dhcp relay destination command, you have to disable the
command using the no form, and execute the command again with changed parameters.
Step 1 Run the following commands to specify an interface type and number, and to enter the interface configuration mode.
Router> enable
Router(config)# interface type number
896
Configuring IPv6 Source Address and Link Address
Example:
Router> enable
Router(config)# interface ethernet 4/2
Step 2 Specify the destination address to which the client packets are forwarded and enable the DHCPv6 relay service on the
interface. ipv6 dhcp relay destination ipv6-address[ interface] [link-address link-address ] [ source-address
source-address]
ipv6 dhcp relay destination ipv6-address [interface] [link-address] [source-address]
Example:
Router(config-if)#ipv6 dhcp relay destination 2001:db8:1234::1 ethernet 4/2 link-address 2001:db8::1

source-address 2001:db8::2
Configuring IPv6 Source Address and Link Address

In some network deployments, there is a firewall between CNR servers and CMTS router. The firewall only
allows packets from certain addresses to transmit to CMTS router.
To allow the DHCPv6 message to be sent to CNR server with specific source address, user needs to configure
the source address of the relayed forwarded DHCPv6 message in the following 3 ways:
1. In the global configuration mode, use the command ipv6 dhcp-relay source-interface interface-type
interface-number
2. In the interface configuration mode, use the command ipv6 dhcp relay source-interface interface-type
interface-number
3. In the interface configuration mode, use the command ipv6 dhcp relay destination ipv6-address[interface]
[link-address link-address ] [source-address source-address]
If the user does not have any of the above configuration, the DHCPv6 message will be relay forwarded with
default source-address, which will be calculated based on relay destination address.
If any one of above is configured, the source-address of the DHCPv6 message will be based on that
configuration.
If more than one configuration above is configured, the overriding rule is that more specific configuration
wins, i.e., 3>2>1.
Configurable DOCSIS CMTS Capabilities DHCPv6 Field

According to DOCSIS 3.1 specification, CMTS must support DOCSIS 3.0 cable modems and features. To
support the backward compatibility of DOCSIS versions, the DHCPv6 vendor option must change from 30
to 31.
You can now upgrade to any DOCSIS version using the cable docsis-ver [major version | minor version]
command.
The default value of the command is cable docsis-ver 3 1.
897
Disabling IPv6 ND Gleaning
Disabling IPv6 ND Gleaning

You must disable IPv6 ND gleaning before configuring IPv6 source verification using DHCPv6 leasequery.
Procedure

prompted.
Example:
Router> enable

Example:
Step 3 interfacebundle bundle-no Specifies a bundle interface number and enters bundle
Example:
• bundle-no —Bundle interface number. The valid range
Router(config)# interface bundle 1 is from 1 to 255.
Step 4 no cable nd Disables IPv6 ND gleaning on the Cisco CMTS router.

Example:
Router(config-if) no cable nd

Example:
Router(config-if) end
How to Verify IPv6 Dual Stack CPE Support

This section describes how to use show commands to verify the configuration of the IPv6 Dual Stack CPE
Support on the CMTS feature.
Procedure

prompted.
Example:
Router> enable
898
Examples

Step 2 show cable modem [ip-address | mac-address ] ipv6[ cpe Displays IPv6 information for specified CMs and CPEs
| prefix | registered | unregistered] behind a CM on a Cisco CMTS router. You can specify the
following options:
Example:
Router# show cable modem ipv6 registered
Example:
Router# show cable modem 0019.474a.c14a ipv6 cpe
Step 3 show cable modem [ip-address | mac-address] registered Displays a list of the CMs that have registered with the
Cisco CMTS. You can specify the following options:
Example:
Router# show cable modem 0019.474e.e4DF registered
Step 4 show cable modem {ip-address | mac-address} cpe Displays the CPE devices accessing the cable interface
through a particular CM. You can specify the following
Example:
options:
Router# show cable modem 0019.474a.c14a cpe
Examples
Use the show cable modem ipv6 command to display the IPv6 portion of a dual stack CPE and use the show
cable modem cpe command to display the IPv4 mode of a dual stack CPE. Both show cable modem ipv6
registered and show cable modem registered commands display CPE count as one for a dual stack CPE.
The following example shows the output of the show cable modem ipv6 command:
Router# show cable modem ipv6 registered

Interface Prim Online CPE IP Address MAC Address
Sid State
C4/0/U2 1 online 0 --- 0019.474a.c18c
C4/0/U2 3 online(pt) 1 2001:420:3800:809:EDA4:350C:2F75:4779 0019.474a.c14a
Router# show cable modem 0019.474a.c14a ipv6 cpe
MAC Address IP Address Domain Name
0005.0052.2c1d 2001:420:3800:809:48F7:3C33:B774:9185
The following example shows the output of the show cable modem ipv6 command:
0023.bed9.4c8e ipv6 cpe
Time source is hardware calendar, *06:37:20.439 UTC Thu Aug 2 2012
MAC Address IP Address
0023.bed9.4c91 2001:40:3:4:200:5EB7:BB6:C759
2001:40:3:4:210:D73B:7A50:2D05
The following example shows the output of the show cable modem registered command:
Router# show cable modem registered

Interface Prim Online Timing Rec QoS CPE IP address MAC address
Sid State Offset Power
C4/0/U2 3 online 1022 0.00 2 1 50.3.37.12 0019.474a.c14a
899
Configuration Examples for IPv6 on Cable
The following example shows the output of the show cable modem cpe command:
Router# show cable modem 0019.474a.c14a cpe
IP address MAC address Dual IP

50.3.37.3 0005.0052.2c1d Y
Configuration Examples for IPv6 on Cable

This section includes the following examples:
Example: IPv6 over Subinterfaces

The following example shows the CMTS bundle configuration that can be used with subinterfaces:
Router# show cable modem ipv6

Device Type: B - CM Bridge, R - CM Router
IP Assignment Method: D - DHCP
MAC Address Type Interface Mac State D/IP IP Address
0019.474a.c18c B/D C4/0/U2 online Y 2001:420:3800:809:4C7A:D518:91
C6:8A18
Router# show run interface bundle2
!
interface Bundle2
no ip address
no cable ip-multicast-echo
end
Router#
show run interface bundle2.1

!
interface Bundle2.1
ip address 50.3.37.1 255.255.255.0
ipv6 address 2001:DB8::/32
ipv6 enable
ipv6 nd prefix default no-advertise
ipv6 dhcp relay destination 2001:420:3800:800:203:BAFF:FE11:B644
arp timeout 240
end
Example: Basic IPv6 Cable Filter Groups

The following example shows the configuration of an IPv6 filter group that drops traffic from a specific IPv6
host (with source address 2001:DB8::1/48) behind a cable router to an IPv6 host on the network (with
destination address 2001:DB8::5/64):
900
Example: Complete Cable Configuration with IPv6
configure terminal
!
! Specify the filter group criteria using a common group ID
!
cable filter group 254 index 128 v6-src-address 2001:DB8::1
cable filter group 254 index 128 v6-src-pfxlen 128
cable filter group 254 index 128 v6-dest-address 2001:DB8::5
cable filter group 254 index 128 v6-dest-pfxlen 128
!
! Specify that the filter group is IP version 6
!
cable filter group 254 index 128 ip-version ipv6
!
! Specify the drop action for matching packets
!
cable filter group 254 index 128 match-action drop
!
! Apply the filter group with ID 254 to all CM upstream traffic
!
cable submgmt default filter-group cm upstream 254

The following example shows a complete cable configuration example; it also displays the configuration of
multiple cable filter groups using both IPv4 and IPv6 and separate indexes to associate the filter definitions
with the same group ID.

!
! Last configuration change at 08:32:14 PST Thu Nov 8 2007
!
version 12.2
no service pad
service timestamps debug uptime
service timestamps log uptime
service internal
service compress-config
!
hostname router
!
boot-start-marker
boot-end-marker
!
enable password password1
!
no aaa new-model
clock timezone PST -9
clock summer-time PDT recurring
clock calendar-valid
facility-alarm core-temperature major 53
facility-alarm core-temperature minor 45
facility-alarm core-temperature critical 85
facility-alarm intake-temperature major 49
facility-alarm intake-temperature minor 40
facility-alarm intake-temperature critical 67
!
!
901
card 1/0 2jacket-1

card 1/0/0 24rfchannel-spa-1
card 5/0 5cable-mc520h-d
cable admission-control preempt priority-voice
cable modem vendor 00.18.68 SA-DPC2203
cable modem vendor 00.19.47 SA-DPC2505
!
cable filter group 1 index 1 src-ip 0.0.0.0
cable filter group 1 index 1 src-mask 0.0.0.0
cable filter group 1 index 1 dest-ip 0.0.0.0
cable filter group 1 index 1 dest-mask 0.0.0.0
ip subnet-zero
ip domain name cisco.com
ip host host1 239.192.254.254
ip host host2 239.192.254.253
ip name-server 10.39.26.7
ip name-server 2001:0DB8:4321:FFFF:0:800:20CA:D8BA
902
!
!
!
!
ipv6 cef
packetcable multimedia
packetcable
!
!
!
redundancy
mode sso
!
!
controller Modular-Cable 1/0/0
annex B modulation 64qam 0 23
ip-address 10.30.4.175
modular-host subslot 5/0
rf-channel 0 cable downstream channel-id 24
!
!
policy-map foo
policy-map 1
policy-map cos
policy-map qpolicy
policy-map shape
policy-map dscp
!
!
!
!
!
!
interface Loopback0
ip address 127.0.0.1 255.255.255.255
!
interface FastEthernet0/0/0
ip address 10.39.21.10 255.255.0.0
speed 100
half-duplex
903

ipv6 enable
!
no cable packet-cache
cable bonding-group-id 1
!
!
!
!
cable bundle 1
cable rf-channel 1 bandwidth-percent 60
!
cable bundle 1
cable rf-channel 2
cable rf-channel 3
!
!
!
!
!
!
!
cable bundle 1
cable downstream channel-id 119
904
cable downstream frequency 99000000

no cable downstream rf-shutdown
cable upstream max-ports 4
cable upstream 0 connector 0
cable upstream 0 frequency 6000000
cable upstream 0 ingress-noise-cancellation 200
cable upstream 0 docsis-mode tdma
cable upstream 0 channel-width 1600000 1600000
cable upstream 0 minislot-size 4
cable upstream 0 range-backoff 3 6
cable upstream 1 shutdown
!
cable ip-init ipv6
cable bundle 1
905

!
cable downstream rf-shutdown
!
906

!
907

!
interface Bundle1
ip address 10.46.1.1 255.255.0.0
cable dhcp-giaddr policy strict
ipv6 enable
ipv6 nd ra interval 5
ipv6 dhcp relay destination 2001:0DB8:4321:FFFF:0:800:20CA:D8BA
!
ip default-gateway 10.39.0.1
ip classless
ip route 0.0.0.0 0.0.0.0 10.39.26.12
ip route 192.168.254.253 255.255.255.255 10.39.0.1
ip route 192.168.254.254 255.255.255.255 10.39.0.1
!
!
no ip http server
no ip http secure-server
!
logging cmts cr10k log-level errors
cpd cr-id 1
nls resp-timeout 1
cdp run
!
tftp-server bootflash:docs10.cm alias docs10.cm
tftp-server bootflash:rfsw_x373.bin alias rfsw_x373.bin
snmp-server community private RW
snmp-server enable traps cable
snmp-server manager
!
!
control-plane
!
!
line con 0
logging synchronous
stopbits 1
line aux 0
line vty 0 4
password lab
login
!
!
cable fiber-node 1
downstream Modular-Cable 1/0/0 rf-channel 1
upstream Cable 5/0 connector 0
908
Example: BGP Configuration for 6VPE
!
cable fiber-node 2
downstream Modular-Cable 1/0/0 rf-channel 0 2-3
upstream Cable 5/0 connector 4
!
end
Example: BGP Configuration for 6VPE

The following example shows a sample BGP configuration on CMTS 6VPE.
Router# router bgp 1

no synchronization
bgp log-neighbor-changes
neighbor 11.1.1.5 remote-as 1
neighbor 11.1.1.5 update-source Loopback1
no auto-summary
!
address-family vpnv6 --- Enable vpnv6 AF
neighbor 11.1.1.5 activate --- Activate neighbor 6VPE-2
exit-address-family
!
address-family ipv6 vrf vrf_mgmt
redistribute connected ---- Publish directly connected route
redistribute static
no synchronization
exit-address-family
!
address-family ipv6 vrf vrfa --- Enable IPv6 vrf AF for each VRF
no synchronization
exit-address-family
!
address-family ipv6 vrf vrfb --- Enable IPv6 vrf AF for each VRF
no synchronization
exit-address-family
!
Example: Subinterface Configuration for 6VPE

The following example shows how to define a subinterface on virtual bundle interface 1.
When configuring IPv6 VPNs, you must configure the first subinterface created as a part of the management
VRF. In the following example, Bundle 1.10 is the first sub-interface, which is configured into management
VRF. Make sure the CNR server is reachable in management VRF.
interface Bundle1.10 --- Management VRF

vrf forwarding vrf_mgmt
ipv6 address 2001:40:3:110::1/64
ipv6 enable
ipv6 dhcp relay destination 2001:10:74:129::2
interface Bundle1.11 --- VRF A
vrf forwarding vrfa
909
Example: Cable Interface Bundling
ipv6 address 2001:40:3:111::1/64

ipv6 enable
interface Bundle1.12 --- VRFB
vrf forwarding vrfb
ipv6 address 2001:40:3:112::1/64
ipv6 enable
Example: Cable Interface Bundling

The following example shows how to bundle a group of physical interfaces.
int C5/0/4 and int c5/0/3 are bundled.

int c5/0/4
cable bundle 1
int c5/0/3
cable bundle 1
Example: VRF Configuration for 6VPE

The following example shows how to create VRFs for each VPN.
vrf definition vrf_mgmt

rd 1:1
!
address-family ipv4
exit-address-family
!
address-family ipv6
route-target import 2:1 -- import route of vrfa
route-target import 2:2 -- import route of vrfb
exit-address-family
Verifying IPv6 on Cable

This section explains how to verify IPv6 on cable configuration and it contains the following topics:
Verifying IPv6 VRF Configuration

To verify the IPv6 VRF configuration, use the show vrf ipv6 command in privileged EXEC mode.
Router# show vrf ipv6 vrfa

Name Default RD Protocols Interfaces
vrfa 2:1 ipv4,ipv6 Bu1.11
Router# show vrf ipv6 interfaces
Interface VRF Protocol Address
910
Verifying IPv6 BGP Status
Bu1.10 vrf_mgmt up 2001:40:3:110::1
Fa0/0/0 vrf_mgmt up 2001:20:4:1::38
Bu1.11 vrfa up 2001:40:3:111::1
Bu1.12 vrfb up 2001:40:3:112::1
CMTS#
Verifying IPv6 BGP Status

To verify the IPv6 BGP status, use the show ip bgp command in privileged EXEC mode.
Router# show ip bgp vpnv6 unicast all neighbors
BGP neighbor is 11.1.1.5, remote AS 1, internal link

BGP version 4, remote router ID 11.1.1.5
Session state = Established, up for 00:35:52
Last read 00:00:37, last write 00:00:14, hold time is 180, keepalive interval is 60 seconds
BGP multisession with 2 sessions (2 established), first up for 00:40:07

Neighbor sessions:
2 active, is multisession capable
Neighbor capabilities:
Route refresh: advertised and received(new) on session 1, 2
Address family IPv4 Unicast: advertised and received
Address family VPNv6 Unicast: advertised and received
......
Verifying MPLS Forwarding Table

To verify the output of the MPLS forwarding table, use the show mpls forwarding-table command in the
Router# show mpls forwarding-table
Local Outgoing Prefix Bytes Label Outgoing Next Hop

Label Label or VC or Tunnel Id Switched interface
......
19 No Label 2001:40:3:110::/64[V] \ ---Route in
vrf_mgmt
0 aggregate/vrf_mgmt
vrfa
0 aggregate/vrfa
vrfb
0 aggregate/vrfb
......
Verifying IPv6 Cable Modem and its Host State

To verify IPv6 addresses and connected host states of cable modems and CPEs, use the show interface cable
modem command in the privileged EXEC mode:
911
Verifying Multiple IAPDs in a Single Advertise
Router# show interface cable 7/0/0 modem ipv6

SID Type State IPv6 Address M MAC address
11 CM online 2001:420:3800:809:3519:5F9C:B96A:D31 D 0025.2e2d.743a
11 CPE unknown 2001:420:3800:809:3DB2:8A6C:115F:41D8 D 0011.2544.f33b
Verifying Multiple IAPDs in a Single Advertise

To verify the multiple IPv6 prefixes assigned to devices on a network, use the show cable modem ipv6 prefix
command in privileged EXEC mode:
Router# show cable modem ipv6 prefix

MAC Address Type IPv6 prefix
0023.bed9.4c91 R/D 2001:40:1012::/64
R/D 2001:40:2012:1::/64
0000.002e.074c R/D 2001:40:1012:8::/64
R/D 2001:40:2012:1D::/64
0000.002e.074b R/D 2001:40:1012:23::/64
R/D 2001:40:2012:1C::/64
0000.002e.074a R/D 2001:40:1012:22::/64
R/D 2001:40:2012:1B::/64
To verify the multiple IPv6 prefixes assigned to CPEs behind a CM with a specific MAC address, use the
show cable modem mac-address ipv6 prefix command in privileged EXEC mode:
Router# show cable modem 0023.bed9.4c8e ipv6 prefix

MAC Address Type IPv6 prefix
0023.bed9.4c91 R/D 2001:40:1012::/64
R/D 2001:40:2012:1::/64
To verify the IPv6 information of CPEs behind a CM with a specific MAC address, use the show cable modem
mac-address ipv6 cpe command in privileged EXEC mode:
Router# show cable modem 0023.bed9.4c8e ipv6 cpe

MAC Address IP Address
0023.bed9.4c91 2001:40:3:4:200:5EB7:BB6:C759
2001:40:3:4:210:D73B:7A50:2D05
Supported MIBs
CISCO-DOCS-EXT-MIB
The CISCO-DOCS-EXT-MIB contains objects that support extensions to the Data-over-Cable Service Interface
Specifications (DOCSIS) interface MIB, DOCS-IF-MIB.
• CdxBundleIpHelperEntry—Provides a list of cable helper entries on the bundle and sub-bundle interfaces.
912
• CdxBundleIPv6DHCPRelayEntry—Contains the IPv6 DHCP relay option, IPv6 DHCP relay

source-interface details, and IPv6 DHCP relay trust configuration on a bundle and sub-bundle interface.
• CdxBundleIPv6DHCPRelayDestEntry—Contains a list of IPv6 DHCP relay destination entries on the
cable bundle and sub-bundle interfaces.
Description Link
ID and password.
Feature Information for IPv6 on Cable

Enabling MDD with Cisco IOS XE Gibraltar 16.12.1x This feature was introduced on the
Pre-Registration DSID Cisco cBR Series Converged
Broadband Routers.
Configurable DOCSIS CMTS Cisco IOS XE Fuji 16.7.1 This feature was introduced on the
Capabilities DHCPv6 Field Cisco cBR Series Converged
Broadband Routers.
913
Feature Information for IPv6 on Cable
IPv6 on cable Cisco IOS XE Everest 16.6.1 This feature was integrated into the
Broadband Routers.
914
CHAPTER 61
Cable DHCP Leasequery
This document describes the Dynamic Host Configuration Protocol (DHCP) Leasequery feature on the Cisco
cable modem termination system (CMTS) router.
Contents
• Prerequisites for Cable DHCP Leasequery, on page 917
• Restrictions for Cable DHCP Leasequery, on page 917
• Information About Cable DHCP Leasequery, on page 917
• How to Configure Filtering of Cable DHCP Leasequery Requests, on page 919
• Configuration Examples for Filtering of DHCP Leasequery , on page 923
• Feature Information for Cable DHCP Leasequery, on page 924
915
Digital PICs:

Module:

Modules:
line card reload.
916
Prerequisites for Cable DHCP Leasequery
Prerequisites for Cable DHCP Leasequery

• You must configure a cable interface with the cable source-verify dhcp command and the no cable arp
command before the Cisco CMTS router can enable DHCP Leasequery. Lease queries are sent to the
DHCP server or to a configured alternate server.
To divert DHCP Leasequeries to a specific server, you must use the cable source-verify dhcp server ipaddress
command and the no cable arp command before the Cisco CMTS router is enabled for DHCP Leasequery.
Only one alternate server may be configured.
• You must configure the ipv6 route command when IPv6 Customer Premise Equipment (CPE) routers
are deployed on the Cisco CMTS router.
Restrictions for Cable DHCP Leasequery

• Leasequeries are sent to the DHCP server unless an alternate server is configured.
• Only one alternate server can be configured.
• Users are responsible for the synchronization of the DHCP server and the configured alternate server.
• If the configured alternate server fails, leasequery requests are not returned to the DHCP server.
• Only one IA_IADDR is supported per client. If the leasequery returns multiple results, only the IA_ADDR
matching the query is added to the Cisco CMTS subscriber database.
• The Cisco CMTS will not verify the source of the IPv6 link-local address of a CPE.
Information About Cable DHCP Leasequery

Problems can occur when viruses, denial of service (DoS) attacks, and theft-of-service attacks begin scanning
a range of IP addresses, in an attempt to find unused addresses. When the Cisco CMTS router is verifying
unknown IP addresses, this type of scanning generates a large volume of DHCP leasequeries, which can result
in the following problems:
• High CPU utilization on the Cisco CMTS router PRE card.
• High utilization on the DHCP servers, resulting in a slow response time or no response at all.
• Packets can be dropped by the Cisco CMTS router or DHCP server (or configured alternate server).
• Lack of available bandwidth for other customers on the cable interface.
To prevent such a large volume of leasequery requests on cable interfaces, you can enable filtering of these
requests on upstream interfaces, downstream interfaces, or both. When the Cable DHCP Leasequery feature
is enabled, the Cisco CMTS allows only a certain number of DHCP leasequery requests for each service ID
(SID) on an interface within the configured interval time period. If an SID generates more Leasequeries than
the maximum, the router drops the excess number of requests until the next interval period begins.
You can configure both the number of allowable DHCP leasequery requests and the interval time period, so
as to match the capabilities of your DHCP server (or configured alternate server) and cable network.
To configure the Cisco CMTS router to send DHCP leasequery requests to the DHCP server, use the cable
source-verify dhcp and no cable arp commands. Unknown IP addresses that are found in packets for customer
premises equipment (CPE) devices that use the cable modems on the cable interface are verified. The DHCP
917
DHCP MAC Address Exclusion List
server returns a DHCP ACK message with the DHCP relay information and lease information of the CPE
device that has been assigned this IP address, if any.
When cable source-verify dhcp and no cable arp commands are configured, DHCP leasequery is sent for
downstream packets to verify unknown IP addresses within the IP address range configured on the cable
bundle interface.
For DHCP leasequery to work in the downstream direction, the Cisco Network Registrar (CNR) should be
made aware of the DHCP Option 82. This is required to make the CMTS map the CPE IP address to the
correct CM. To do this, configure the ip dhcp relay information option command on the bundle interface
to insert service class relay agent option into the DHCP DISCOVER messages. When the configuration is in
place, during DHCP DISCOVER the values of DHCP Option 82 is cached by the CNR and is returned to the
CMTS on any subsequent DHCP leasequery for that IP address.
To configure the Cisco CMTS router to divert DHCP leasequery requests to a server other than the DHCP
server, use the cable source-verify dhcp server ipaddress and no cable arp commands.
The Cisco CMTS supports two types of DHCP leasequery implementation, Cisco standard compliant DHCP
leasequery and RFC 4388 standard compliant DHCP leasequery. These two standards differ mostly in the
identifiers used to query or respond to the DHCP Server. You can choose between these two implementations
depending on which standard is supported on your DHCP Server.
Use the ip dhcp compatibility lease-query client {cisco | standard} command to configure the Cisco CMTS
in either Cisco mode or RFC 4388 standard mode.
DHCP MAC Address Exclusion List

This feature enables the ability to exclude trusted MAC addresses from the standard DHCP source verification
checks for the Cisco CMTS. The DHCP MAC Address Exclusion List feature enables packets from trusted
MAC addresses to pass when otherwise packets would be rejected with standard DHCP source verification.
This feature overrides the cable source-verify command on the Cisco CMTS for the specified MAC address,
yet maintains overall support for standard and enabled DHCP source verification processes. This feature is
supported on the Performance Routing Engine 1 (PRE1), PRE2, and PRE4 modules on the Cisco cBR router
chassis.
To enable packets from trusted source MAC addresses in DHCP to pass without source verification checks,
use the cable trust command in global configuration mode. To remove a trusted MAC address from the MAC
exclusion list, use the no form of this command. Removing a MAC address from the exclusion list subjects
all packets from that source to standard DHCP source verification.
For more information on the cable trust command, see the Cisco IOS CMTS Cable Command Reference
Guide .
Unitary DHCPv6 Leasequery

This feature supports unitary DHCPv6 leasequery protocol (RFC 5007) on the Cisco CMTS routers for
upstream IPv6 source verification. This protocol verifies the authenticity of the IPv6 CPE behind a home or
small office cable deployment.
If the IPv6 source verification fails on the router and the cable ipv6 source-verify dhcp and no cable nd
commands are configured on the bundle interface or subinterface, the Cisco CMTS triggers a unitary DHCPv6
leasequery to the Cisco Network Registrar (CNR). If a valid leasequery response is received from the CNR,
the Cisco CMTS adds the CPE to its subscriber database and allows future traffic for the CPE.
918
How to Configure Filtering of Cable DHCP Leasequery Requests
The primary use of the unitary DHCPv6 leasequery protocol on the Cisco CMTS router is to recover lost CPE
data including the Prefix Delegation (PD) route. The IPv6 CPE data can be lost from the Cisco CMTS in
several ways. For example, PD route loss can occur during a Cisco CMTS reload.
The unitary DHCPv6 leasequery protocol also supports the following:
• DHCPv6 leasequery protocol.
• Rogue client database for failed source-verify clients.
• DHCPv6 leasequery filters.
• DHCPv6 leasequeries to a specific DHCPv6 server.
How to Configure Filtering of Cable DHCP Leasequery Requests

Use the following procedures to configure the filtering of DHCP Leasequery requests on the Cisco CMTS
downstreams and upstreams:
Enabling DHCP Leasequery Filtering on Downstreams

Use the following procedure to start filtering DHCP leasequeries on all downstreams of a cable interface.
Procedure

Router> enable

Example:
Step 3 cable source-verify leasequery-filter downstream Enables leasequery filtering on all downstreams on the
threshold interval specified bundle interface, using the specified threshold
and interval values.
Example:
Router(config)# cable source-verify

leasequery-filter downstream 5 10
Step 4 end Exits configuration mode and returns to privileged EXEC

mode.
Example:
Router(config)# end
919
Enabling DHCP Leasequery Filtering on Upstreams
Enabling DHCP Leasequery Filtering on Upstreams

Use the following procedure to start filtering DHCP Leasequeries on all upstreams on a bundle interface.
Procedure

Router> enable

Example:
Step 3 interface bundle bundle-no Enters interface configuration mode for the specified bundle
interface.
Example:
Step 4 cable source-verify leasequery-filter upstream threshold Enables leasequery filtering on all upstreams on the
interval specified bundle interface, using the specified threshold
and interval values.
Example:
Note The cable source-verify leasequery-filter
Router(config-if)# cable source-verify upstream command can only be configured
leasequery-filter upstream 2 5 under bundle interface.
Note Repeat step 3 and step 4 to enable the filtering
of DHCP Leasequeries on the upstreams for
other bundle interfaces. Primary and secondary
interfaces in a cable bundle must be configured
separately.

EXEC mode.
Example:
Configuring Unitary DHCPv6 Leasequery Filtering

Use the following procedure to configure the Cisco CMTS router to send Leasequeries to a DHCP server to
verify the authenticity of the IPv6 CPE. You can also enable filtering of these requests to prevent large volumes
920
Configuring Unitary DHCPv6 Leasequery Filtering
of Leasequery requests on the bundle interfaces. Similarly, the number of allowable Leasequery requests and
the interval time period can also be configured.
Note When the leasequery timer expires, only the IPv4 static CPE is automatically removed from the host database.
Before you begin

• Disable the IPv6 Neighbor Discovery (ND) Gleaning feature using the no form of the cable nd command
in bundle interface configuration mode before configuring the unitary DHCPv6 leasequery protocol. For
details on IPv6 ND gleaning, see IPv6 on Cable feature guide.
• Configure the cable ipv6 source-verify dhcp command under the Cisco CMTS bundle or bundle
subinterface to enable the unitary DHCPv6 leasequery protocol.
• Use the cable ipv6 source-verify dhcp [server ipv6-address] command for a single DHCP server.
• Use the cable ipv6 source-verify dhcp command without any keywords for multiple DHCP servers.
Procedure

Router> enable

Example:
Step 3 interface bundle bundle-no Enters interface configuration mode for the specified bundle
interface.
Example:
Step 4 cable ipv6 source-verify orcable ipv6 source-verify dhcp Enables leasequery filtering on the specified bundle
[server ipv6-address] interface and verifies the IP address with multiple DHCPv6
servers. or Enables leasequery filtering on the specified
Example:
bundle interface and verifies the IP address with a specified
DHCPv6 server.
or
Router(config-if)# cable ipv6 source-verify dhcp
server 2001:DB8:1::1
921
Enabling DHCPv6 Leasequery Filtering on Downstreams

Step 5 cable ipv6 source-verify leasetimer value Enables leasequery timer on the specified bundle interface,
for the Cisco CMTS to check its internal CPE database for
Example:
IPv6 addresses whose lease time has expired.
leasetimer 200
Step 6 cable ipv6 source-verify leasequery-filter threshold Enables filtering of the IPv6 leasequery requests.
interval
Example:

leasetimer 5 10

EXEC mode.
Example:
Enabling DHCPv6 Leasequery Filtering on Downstreams

Use the following procedure to start filtering DHCP Leasequeries on all downstreams of a cable interface.
Procedure

Router> enable

Example:
Step 3 cable ipv6 source-verify leasequery-filter downstream Enables leasequery filtering on all downstreams on the
threshold interval specified bundle interface, using the specified threshold and
interval values:
Example:

leasetimer 5 10
922
Configuration Examples for Filtering of DHCP Leasequery

EXEC mode.
Example:
Configuration Examples for Filtering of DHCP Leasequery

This section provides the following examples on how to configure the DHCP leasequery filtering feature:
Example: DHCP Leasequery Filtering

The following example shows an excerpt from a typical configuration of a bundle interface that is configured
for filtering DHCP leasequery requests on both its upstream and downstream interfaces:
Note If an alternate server has been configured to receive leasequery requests, the cable source-verify dhcp server
ipaddress command would display in place of the cable source-verify dhcp command below.
.
.
.
cable source-verify leasequery-filter downstream 5 20
.
.
.
interface bundle 1
.
.
.
cable source-verify leasequery-filter upstream 1 5
no cable arp
.
.
Example: Unitary DHCPv6 Leasequery Filtering

The following example shows how to display the total number of DHCPv6 leasequery requests that have been
filtered on the router in Cisco IOS Release 12.2(33)SCF1:
Router# show cable leasequery-filter

IPv4 Lease Query Filter statistics for Unknown Sid
Requests Sent : 0 total. 0 unfiltered, 0 filtered
IPv6 Lease Query Filter statistics for Unknown Sid
Requests Sent : 0 total. 0 unfiltered, 0 filtered
923
Description Link
ID and password.
Feature Information for Cable DHCP Leasequery

Table 158: Feature Information for Cable DHCP Leasequery
Cable DHCP leasequery Cisco IOS XE Fuji 16.7.1 This feature was integrated into
Cisco IOS XE Fuji 16.7.1 on the
Broadband Routers.
924
CHAPTER 62
DHCPv6 Bulk-Lease query
This document describes the Dynamic Host Configuration Protocol (DHCP) v6 Bulk-Lease query feature on
the Cisco cable modem termination system (CMTS) router.
• Information About DHCPv6 Bulk-Lease Query, on page 927
• How to Configure DHCPv6 Bulk-Lease Query, on page 927
• Debugging DHCPv6 Bulk-Lease Query, on page 928
• Feature Information for DHCPv6 Bulk-Lease query, on page 928
925
Digital PICs:

Module:

Modules:
line card reload.
926
Information About DHCPv6 Bulk-Lease Query
Information About DHCPv6 Bulk-Lease Query

This document describes the Dynamic Host Configuration Protocol (DHCP) v6 bulk-lease query feature on
the Cisco cable modem termination system (CMTS) router. Cisco cBR-8 supports DHCPv6 bulk lease query
in accordance with RFC 5460.
DHCPv6 bulk lease query is used to recover the IPv6 bindings(GUA/PD/LLA) for CPE ONLY after a chassis
reload. The CPE’s IPv6 binding information is retrieved from the DHCPv6 server. On cBR8,this feature is
designed to be started some time later after a chassis reload. Since before recover CPE’s information, we must
wait its CM online firstly.
cBR8 will check all active CPE IPv6 bindings retrieved from DHCPv6 server one by one:
• If the IPv6 binding is for CM, cBR8 will drop it.
• If the IPv6 binding is for a CPE. If this binding does not present on cBR8 side and the CM of the CPE
is online, cBR8 will recover the IPv6 binding, otherwise, cBR8 will drop it.
The DHCPv6 bulk-lease query feature is disabled by default.

To make this feature works, the DHCPv6 server side must also support DHCPv6 bulk lease query.
How to Configure DHCPv6 Bulk-Lease Query

The following steps help you to setup the DHCPv6 Bulk-Lease query feature with Cisco cBR-8 Converged
Broadband Router.
To enable the DHCPv6 Bulk-Lease query feature, run the following commands:
1. Run the [no] ipv6 dhcp-relay bulk-lease disable command.
2. Run the cable ipv6 source-verify bulk-lease [start <start-seconds> timeout <timeout-seconds>]
command.
Note The start-seconds means the time DHCPv6 Bulk-lease will be started after common reload. The start-seconds
default value is 2400 seconds. The timeout-seconds means the max time that DHCPv6 Bulk-lease allowed to
run. The timeout-seconds default value is 600 seconds.
Ensure that you enable both the Cisco common and Cable specific parts.
To disable the DHCPv6 Bulk-Lease query feature, run the following commands:
1. Run the ipv6 dhcp-relay bulk-lease disable command.
2. Run the [no] cable ipv6 source-verify bulk-lease command.
Note The DHCPv6 server needs to listen on the TCP port 547.
927
Debugging DHCPv6 Bulk-Lease Query
Debugging DHCPv6 Bulk-Lease Query

The following debugging commands are supported for the DHCPv6 Bulk-Lease Query:
• debug cable ipv6 bulk-lq
• debug ipv6 dhcp relay bulk-lease
To check the results of DHCPv6 Bulk-Lease query, you can use the debug cable ipv6 bulk-lq command.
See the following example:
Router# show cable ipv6 bulk-lq

CMTS DHCPv6 Bulk Lease Query Statistics:
Start time 1200 seconds after system up
End time 1500 seconds after system up
DHCPv6 Bulk Lease Query glean ready: 0
DHCPv6 Bulk Lease Query process created: 0
Time out happened: No
Total number of CM option received: 31
Total number of LLA received: 10
Total number of LLA recovered: 7
Total number of GUA received: 10
Total number of GUA recovered: 8
Total number of PD received: 0
Total number of PD recovered: 0
Feature Information for DHCPv6 Bulk-Lease query

Table 160: Feature Information for DHCPv6 Bulk-Lease query
DHCPv6 Bulk-Lease query Cisco IOS XE Gibraltar 16.12.1 This feature was integrated into
Cisco IOS XE Gibraltar 16.12.1 on
Broadband Routers.
928
CHAPTER 63
Layer 3 CPE Mobility
Layer 3 CPE Mobility feature is introduced to allows the mobility CPE devices to move between cable modems
with as less disruption of traffic as possible.
Contents
• Prerequisites for Layer 3 CPE Mobility , on page 930
• Restrictions for Layer 3 CPE Mobility , on page 931
• Information About Layer 3 CPE Mobility , on page 931
• How to Configure Layer 3 Mobility, on page 932
• Configuration Examples for Layer 3 Mobility, on page 935
• Feature Information for Layer 3 CPE Mobility , on page 936
929
Prerequisites for Layer 3 CPE Mobility
Digital PICs:

Module:

Modules:
line card reload.
Prerequisites for Layer 3 CPE Mobility

No special equipment or software is needed to use the Layer 3 CPE Mobility feature.
930
Restrictions for Layer 3 CPE Mobility
Restrictions for Layer 3 CPE Mobility

• Layer 3 CPE Mobility feature allows CPE devices to move only in the same bundle or sub-bundle
interface.
• The IPv4 or IPv6 subnets that are configured with mobility must match with the IPv4 or IPv6 subnets
already configured on bundle or sub-bundle interface. Otherwise, configuration will not be accepted and
the following message will be displayed:
Please remove the previous online CPEs or reset CMs,
• If you remove the IPv4 or IPv6 address on bundle or sub-bundle interface, it also removes the relative
mobility subnets at the same time.
• Multicast packets will not trigger the Layer 3 CPE Mobility feature.
• VRF configured under bundle or sub-bundle interface is not supported for CPE mobility feature.
• In Layer 3 CPE Mobility feature, the packet lost time period during mobility will be unpredictable,
depending on how many CPE devices move at the same time and system loading conditions.
• For CPE devices, which have multiple IPv4 or IPv6 addresses, all of IPv4 or IPv6 addresses will be
rebuilt with new source information.
• Layer 3 CPE Mobility may be failed during line card or SUP HA and the trigger upstream packet will
be dropped.
• If CPE mobility is turned on, mobility behavior will become effective before cable Ipv4 or IPv6 source
verify.
• If Layer 3 CPE Mobility is enabled, some of the security checks will be skipped for the mobility subnets
to achieve faster movement of the CPE devices.
Information About Layer 3 CPE Mobility

The Layer 3 CPE Mobility feature allows CPE devices to move from cable modem to other by trigger of any
unicast upstream packets of IPv4 or IPV6.
Each cable modem would be situated at a business hotspot location and the CPE devices move from one
business location to another, where the service provider is the same and the head end CMTS is the same. This
mobility is allowed for selected IP subnets.
The IPv4 or IPv6 subnets that are configured with mobility must match with the IPv4 or IPv6 subnets already
configured on bundle or sub-bundle interface. Otherwise, configuration will not be accepted and the following
message will be displayed:
Please remove the previous online CPEs or reset CMs,
When you remove mobility subnets under bundle or sub-bundle interface. The following warning message
will be displayed after mobility subnets is configured or removed.
Warning: Please remove the previous online CPEs or reset CMs, to make the mobility scope
change works for every device !!!
931
Benefits of Layer 3 CPE Mobility
Note If you have enabled mobility configuration for a subnet, the existing online CPE devices will be updated to
aware of the mobility subnets, and the CPU usage will rise up during that time. So it's better to configure the
mobility subnets before CM and CPE come online.
Enabling the Layer 3 CPE Mobility feature may, in certain situations, cause excessive punted packets. By
default, the Source-Based Rate-Limiting (SBRL) feature rate-limits these punted packets to avoid CPU
overload.
Benefits of Layer 3 CPE Mobility

The feature provides the movement of CPE devices from one cable modem to another without change in the
IP address and the TCP or UDP sessions established are maintained.
How to Configure Layer 3 Mobility

Configuring CPE Mobility
This section describes how to enable mobility on a particular IP subnet on a interface or subinterface bundle.
Before you begin

Mobility subnets should match the IPv4 or IPv6 address configured on the bundle or sub-bundle interface.
Procedure

prompted.
Example:
Router> enable

Example:
Step 3 interface bundle bundle number| bundle-subif-number Enters interface configuration or subinterface mode.
Example:

or
Router(config)# interface Bundle 1.1
Step 4 cable l3-mobility IP-address mask | IPv6 prefix Enables mobility for a particular IPv4 or IPv6 subnet.
932
Configure Source-Based Rate Limit (SBRL) for L3-mobility

Example: Note This command can be configured on a interface
or a subinterface bundle.
Router(config-if)# cable l3-mobility
2001:DB:22:1::1/64
Example:
Router(config-subif)# cable l3-mobility 192.0.3.1

255.255.255.0
Example:
Router(config-subif)#cable l3-mobility
2001:DB:22:1::1/64

Example:
What to do next
If the mobility IP address does not match with the mobility subnet, the following warning message is displayed:
Mobility IP should match the IDB subnet!
If you remove the IPv4 or IPv6 address from the interface, the mobility scope is removed for the IP address
and the following warning message is displayed.
IPv6 2001:DBB:3:111::1 removed from Mobility subnets on Bundle1
Configure Source-Based Rate Limit (SBRL) for L3-mobility

This section describes how to configure Source-Based Rate Limit (SBRL) for the L3-mobility feature. This
procedure is optional and if not configured, the default SBRL configuration will apply.
Note SBRL for L3-mobility is enabled by default, so this configuration is optional.
Subscriber-side SBRL has a global and per-punt-cause configuration. L3-mobility punts are only subject to
the per-punt-cause configuration. Traffic streams are identified by hashing the punt-cause and the
source-MAC-address. This value is used as the index for rate-limiting. There is no special processing for
hash-collisions, so hash-colliding streams are treated as if they are the same stream.
The default rate for L3-mobility punts is 4 packets per second.
933
Disabling CPE Mobility
Before you begin
Note All punted packets are subject to CoPP and the punt-policer.
Procedure

prompted.
Example:
Router> enable

Example:
Step 3 platform punt-sbrl subscriber punt-cause punt-cause Configures Subscriber-MAC-address SBRL.

rate rate
Example:
Router(config)# platform punt-sbrl subscriber

punt-cause 99 rate 8

Example:
Disabling CPE Mobility

This section describes how to disable mobility on a particular IP subnet.
Before you begin

The CPE mobility should be enabled on a particular IP subnet before you complete this procedure.
Procedure

prompted.
Example:
Router> enable
934
Verifying Layer 3 Mobility Configuration

Example:
Step 3 interface bundle bundle number | bundle-subif-number Enters interface configuration or subinterface mode.
Example:

or
Router(config)# interface Bundle 1.1
Step 4 no cable l3-mobility IP-address mask | IPv6 prefix Disbles mobility for a particular IPv4 or IPv6 subnet.
Example: Note This command can be configured on a interface
or a subinterface bundle
Router(config-if)# cable l3-mobility 192.0.3.1
255.255.255.0
Router(config-if)# cable l3-mobility

2001:DB:22:1::1/64

Example:
Verifying Layer 3 Mobility Configuration

To verify the layer 3 mobility configuration, use the show cable bundle command.
Configuration Examples for Layer 3 Mobility

Example: Configuring CPE Layer 3 Mobility

The following example shows how to configure the layer 3 CPE mobility on a interface bundle:
Router#show running interface bundle 10

!
interface Bundle10
ip address 192.3.23.1 255.255.255.0
ip pim sparse-dense-mode
935
Example: Configuring SBRL for L3-mobility

no cable arp filter request-send
no cable arp filter reply-accept
cable l3-mobility 192.0.3.1 255.255.255.0
cable l3-mobility 192.2.21.1 255.255.255.0
cable l3-mobility 192.3.23.1 255.255.255.0
cable l3-mobility 2001:DB:26:1::1/64
cable l3-mobility 2001:DB:27:1::1/96
ipv6 address 2001:DB:26:1::1/64
ipv6 address 2001:DB:27:1::1/96
ipv6 enable
ipv6 dhcp relay destination 2001:DB:1:1:214:4FFF:FEA9:5863
end
Example: Configuring SBRL for L3-mobility

The following example shows how SBRL is configured for L3-mobility:
Router# show run | i punt-sbrl

platform punt-sbrl subscriber punt-cause 99 rate 8
The following sections provide references related to Layer 3 CPE Mobility feature for the Cisco CMTS routers.
Description Link

Feature Information for Layer 3 CPE Mobility

936
Table 162: Feature Information for Layer 3 CPE Mobility
Layer 3 Mobility Cisco IOS XE Fuji This feature was integrated into Cisco IOS XE Fuji 16.7.1 on
16.7.1 theCisco cBR Series Converged Broadband Routers.
937
938
CHAPTER 64
DOCSIS 3.0 Multicast Support
The Cisco cBR Series Routers support multicast improvements based on Data-over-Cable Service Interface
Specifications (DOCSIS) 3.0. DOCSIS 3.0 multicast support improves bandwidth efficiency and allows
service providers to offer differentiated quality of service for different types of traffic.
Contents
• Prerequisites for the DOCSIS 3.0 Multicast Support, on page 940
• Restrictions for the DOCSIS 3.0 Multicast Support, on page 941
• Information About the DOCSIS 3.0 Multicast Support, on page 941
• How to Configure the DOCSIS 3.0 Multicast Support, on page 946
• Configuring Multicast Replication Session Globally, on page 953
• Configuring Multicast Replication Sessions on Forwarding Interface, on page 953
• Clearing Multicast Replication Cache, on page 954
• How to Monitor the DOCSIS 3.0 Multicast Support, on page 954
• Configuration Examples for DOCSIS 3.0 Multicast Support, on page 959
• Feature Information for DOCSIS 3.0 Multicast Support, on page 962
939
Prerequisites for the DOCSIS 3.0 Multicast Support
Digital PICs:

Module:

Modules:
line card reload.
Prerequisites for the DOCSIS 3.0 Multicast Support

• DOCSIS 3.0-compliant Cisco CMTS and DOCSIS 3.0-enabled cable modems are required.
940
Restrictions for the DOCSIS 3.0 Multicast Support
• Cisco CMTS must be MDF-enabled by default.

• Quality of service (QoS) parameters must be configured for various multicast sessions.
Restrictions for the DOCSIS 3.0 Multicast Support

• You cannot disable explicit tracking.
• For multicast QoS, you must define three objects and templates, Service-Class, Group-QoS-Config
(GQC), and Group-Config, and associate them to a particular bundle or forwarding interface.
• You must define a default service class and GQC before defining objects and templates.
• Static multicast feature is always enabled and you cannot disable it.
• The service flow attribute-based selection will be ignored if the group configuration is configured on the
default forwarding interface.
• The multicast DSID feature is supported only on DOCSIS 3.0-compliant cable modems.
• The cable multicast mdf-disable wb-incapable-cm command disables multicast downstream service
identifier (DSID) forwarding capability on the cable modem, which impacts the DSID capability between
the Cisco CMTS and the cable modem.
• The multicast traffic to CPE increases two-fold after changing the multicast QoS configuration or the
service-flow attribute during an active session. The traffic replication will continue till the default session
timeout period (180 seconds). After the session timeout, the multicast DSID is removed from both Cisco
CMTS and CM, and normal multicast traffic flow is resumed.
• For the DOCSIS 3.0 Multicast support feature to function properly, the CPE and the CM must be in the
same virtual routing and forwarding (VRF) interface.
Information About the DOCSIS 3.0 Multicast Support

IP multicast, an integral technology in networked applications, is the transmission of the same information
to multiple recipients. Any network application, including cable networks, can benefit from the bandwidth
efficiency of multicast technology. Two new technologies—Channel Bonding and Single Source Multicast
(SSM)—are expected to dramatically accelerate multicast deployment.
The channel bonding and SSM technologies dramatically increase the operational efficiency of the existing
hybrid fiber-coaxial (HFC) network. Using the multicast improvements, the cable operators can seamlessly
deliver advanced services like video on demand (VoD), internet protocol television (IPTV), and facilitate
interactive video and audio, and data services.
The following sections explain the benefits of DOCSIS 3.0 Multicast Support:
Multicast DSID Forwarding

DOCSIS 3.0 multicast support introduces centralized control at the Cisco CMTS to provide flexibility and
scalability to support a large array of multicast protocols. It replaces the Internet Group Management Protocol
(IGMP), version 2 snooping infrastructure, which was part of the DOCSIS 1.1 and 2.0 models. Now, the Cisco
941
Multicast Forwarding on Bonded CM
CMTS allocates an unique Downstream Service Identifier (DSID) to identify every multicast stream. These
DSIDs are sent to the CMs that use these DSIDs to filter and forward Multicast traffic to the CPEs.
The multicast DSID forwarding (MDF) provides the following benefits:
• Unique identification of packet stream across bonding group within a MAC domain.
• Designation of packet stream as either Any Source Multicast (ASM) or Source Specific Multicast (SSM)
per multicast channel.
• Implementation of multicast DSID management on the Route Processor (RP) makes it operate on a
standalone basis.
• Snooping of all upstream signal control packets by the Cisco CMTS to find the customer premises
equipment (CPE) on the Multicast DSID-based Forwarding (MDF) enabled CM and allocates DSID
from the pool.
• Transmission of allocated DSIDs to the CM through Dynamic Bonding Change (DBC) message.
• Reuse of DSIDs on other MDF-enabled CMs in the same bonding group, joining the multicast session.
• Removal of DSIDs from the CM through a DBC message by the Cisco CMTS after a multicast session
leave event.
• Release of DSID to the pool by the Cisco CMTS when the last member leaves the bonding group.
• The following DSIDs are preallocated for each primary downstream (modular and integrated cable
interfaces) to forward general query messages. These DSIDs form part of the multicast group signaling
protocol. Other multicast groups, do no use these DSIDs.
• IGMPv2 general query (IPv4)
• IGMPv3 general query (IPv4)
• MLDv1 general query (IPv6)
• MLDv2 general query (IPv6)
• Preregistration of DSID (IPv6)
• Allocation of DSID ensures traffic segregation between virtual private networks (VPNs) for DOCSIS
3.0 MDF-enabled CMs. For example, two clients from two VPNs joining the same multicast will get
two distinct DSIDs.
Multicast Forwarding on Bonded CM

Multicast packets to the DOCSIS 3.0-enabled CMs are transmitted as bonded packets with DSID extension
header on the primary bonding group if the Secondary Multicast Bonding Group is disabled. Multicast packets
for MDF-disabled or pre-DOCSIS 3.0 CMs are transmitted as non-bonded without DSID extension header.
For more information on this feature, refer to Multicast Secondary Bonding Group, on page 944.
In a network, where only MDF-enabled or MDF-disabled CMs exist, the traffic is segregated using field types.
The MDF-enabled CM forwards the frame with the field type and the MDF-disabled CM drops it. The DSID
labeling ensures that MDF-enabled CM gets a copy of the multicast session to prevent “cross talk”.
For hybrid CMs (MDF-enabled and MDF-disabled CMs) that do not support field type forwarding, you should
configure per session encryption or security association identifier (SAID) isolation to ensure traffic segregation.
DOCSIS 3.0 mandates that if the hybrid CM fails to forward field type frames, the Cisco CMTS should employ
multicast security association identifier (MSAID) isolation. This isolation is achieved by assigning different
MSAID to each replication, one to bonded CM and another to the non-bonded or hybrid CM. This helps to
prevent CMs from receiving duplicate traffic.
942
Static TLV Forwarding
Static TLV Forwarding

As per DOCSIS 3.0 specifications, the Cisco CMTS must support Static Multicast. When the CM tries to
register with the Cisco CMTS, the Cisco CMTS checks whether Static Multicast Encoding is present in the
CM configuration file. If the Static Multicast Encoding is present, the Cisco CMTS sends a DSID corresponding
to each Static Multicast channel in the Registration-Response (REG-RSP) message.
The Multicast DSID management is located at Supervisor and the interface card has to contact the Supervisor
for proper DSID assignment. The interface card also caches the response from Supervisor to eliminate the
need to communicate to the Supervisor for subsequent Static Multicast encoding.
Explicit Tracking
The Cisco CMTS can perform explicit tracking with IGMPv3 support. The IGMPv3 removes the report
suppression feature associated with the IGMPv2 specification enabling the Cisco CMTS to get the complete
information on session and host information. This benefits the IGMP Fast Leave processing and DSID
management for each CM.
A host or session database is used to track hosts (IP/MAC) joining a particular multicast session. From the
host, you can track the CM based on the SID and cable downstream interface. This database also helps to
determine whether the Cisco CMTS should remove the DSID from a particular CM when the multicast session
is over.
Multicast Quality of Service Enhancement

DOCSIS 3.0 mandates that the CMTS should not admit any flow exceeding the session limit. Though the
current Multicast QoS (MQoS) session limit admits the session, it fails to provide any QoS for sessions
exceeding the session limit.
Note Multicast packets are sent using the default Group Service Flows (GSF) when the Multicast QoS feature is
disabled.
As part of DOCSIS 3.0 requirements for Multicast QoS, Group Classifier Rules (GCR) is supported. The
Cisco CMTS determines the set of Group Configurations (GCs) whose session range matches the multicast
group address. For SSM, the source address is also used to identify the matching GCs. A GCR is created for
each matching GC and linked to the multicast session. The GCR is assigned also with an unique identifier,
SAID, and Group Service Flow (GSF).
The following conditions are used to select the GC entries:
• The GC entry with the highest rule priority is selected, if more than one GC entry matches.
• All matching GC entries are selected, when multiple GCs have the same highest rule priority.
The GCR classification is done based on type of service (TOS) fields. The TOS specifier in the GCR is used
to choose the correct GCR when multiple GCRs match a single multicast session.
Note When two multicast group configurations (GCs) have the same session range and configuration (under global
or bundle configuration), then the same forwarding interface selection is not guaranteed.
943
Multicast Secondary Bonding Group
Non-IP multicasts and broadcast packets use GSF. They are similar to individual service flows and are shared
by all the CMs on a particular Digital Command Signal (DCS) matching the same GCR. A single GSF is used
for multicast sessions matching different GCs using the same aggregate GQC.
Multicast Secondary Bonding Group

The DOCSIS 3.0-compliant CM can receive multicast packets from non-primary (or bonded) channels using
the MDF support at the CMTS.
The multicast secondary bonding group is defined as a shared bonding group or RF channel that feeds more
than one fiber node through an optical split. This allows CMs from different primary bonding groups and
channels to listen to one or more shared sets. The multicast packets are replicated only to the shared downstream
channel set, which helps conserve the downstream bandwidth.
DOCSIS 3.0 defines attribute-based service flow creation, which allows the Cisco CMTS to make more
“intelligent” decisions on the selection of bonding group or individual channel for unicast and multicast
forwarding.
The Multicast Secondary Bonding Group provides the following benefits:
• New MQoS and attribute-based forwarding for Multicast Secondary Bonding Group.
• The primary downstream interface acts as a forwarding interface for narrowband CMs.
• The following algorithm is used to select a forwarding interface for wideband CMs:
• A primary bonding group is selected if a group-config matching the session is present in it. MQoS
parameters are taken from the group-config.
• A primary bonding group is selected if a group-config is not present at the bundle level or at the
global level.
• A group-config found at the bundle level or global level is used to find the Group-QoS-Config
(GQC) and eventually the attribute and forbidden bit-masks, which are then used to find the interface.
• All Wideband Cable Modems (WCMs) in a bundle use the same secondary bonding group if a
bundle-level group-config or global-level group-config is configured.
• The IGMP report ignores a source if the given source address fails to find a matching interface.
• If a matching interface is found, that interface is used for forwarding and the MQoS parameters are
taken from the matching group-config from the forwarding interface or bundle interface or global
level.
• If a matching interface is not found, then the IGMP report is ignored.
• For a static join, attribute-based forwarding is not supported, and only the primary downstream is used.
Load Balancing
The Load Balancing feature does not load balance a CM while a multicast stream is going on for that particular
CM. It utilizes the Explicit Tracking Database, which holds complete information on the CM subscription to
achieve this.
Multicast DSID Forwarding Disabled Mode

For any application that needs the cable modem to perform IGMP snooping, the MDF on the cable modem
must be disabled. Cable modems registered in MDF-enabled mode by the Cisco CMTS do not perform IGMP
944
MDF1 Support for DOCSIS 2.0 Hybrid Cable Modems
snooping because MDF forwarding is based on DSID filtering. The cable multicast mdf-disable command
disables the MDF capability on the cable modem.
This command is configured on the route processor and is downloaded to the cable line card via the
configuration update. The configuration does not change the Cisco CMTS forwarding mechanism or DSID
allocation. The Cisco CMTS allocates the DSID and the multicast packet is encapsulated with the DSID
header. This does not affect traffic forwarding on the MDF-disabled cable modem. According to DOCSIS3.0
specification, pre-DOCSIS2.0 or MDF-disabled cable modems ignore the DSID header and continue multicast
forwarding based on the Group Media Access Control (GMAC) from IGMP snooping. When the cable modem
runs in MDF-disabled mode, only IGMPv2 is supported and the Cisco CMTS drops IGMPv3 and MLD
messages.
Multicast encryption based on BPI+ is not supported on non-MDF cable modems, if IGMP SSM mapping is
used. A non-MDF cable modem is either a pre-DOCSIS 3.0 cable modem or a DOCSIS 3.0 cable modem
running in MDF-disabled mode.
MDF1 Support for DOCSIS 2.0 Hybrid Cable Modems

The Cisco CMTS router enables MDF capability for DOCSIS 2.0 hybrid cable modems, IPv6, and other cable
modems that advertise MDF capability to allow IPv6 packet forwarding. The wb-incapable-cm keyword in
the cable multicast mdf-disable command disables MDF on all DOCSIS 2.0 hybrid cable modems including
DOCSIS Set-Top Gateway (DSG) hybrid embedded cable modems to support IGMP snooping.
DSG Disablement for Hybrid STBs

The cable multicast mdf-disable command with the wb-incapable-cm keyword prevents all DOCSIS 2.0
DSG embedded cable modems from receiving DSG multicast traffic besides disabling MDF support.
The wb-incapable-cm keyword disables MDF capability only on non-DSG DOCSIS 2.0 hybrid cable modems.
To disable MDF capability on all DSG embedded cable modems (DOCSIS 3.0 DSG and DOCSIS 2.0 DSG
hybrid), a new keyword, DSG, is introduced.
Note After disabling MDF capability, you must run clear cable modem reset command to bring all DSG embedded
cable modems online.
Benefits of MDF1 Support

• Supports IPv6 on different known cable modem firmware types.
• Disables the MDF capability on the Cisco CMTS.
• Supports In-Service Software Upgrade (ISSU) and line card high availability.
Dynamic Multicast Replication Sessions

When users enable IPTV service on the Cisco cBR routers, to enhance the performance, the following features
are supported on Cisco cBR.
• Supports 8000 SIDs per bundle interface:
The Cisco cBR supports 8000 SIDs per bundle, because each MQoS need one SID for each multicast
session.
945
Cache Multicast Replication Sessions
• Provides faster and efficient IP Communicator messages.

• Provides faster multicast forwarding.
• Enables caching of dynamic multicast sessions.
Cache Multicast Replication Sessions

Creating a new multicast replication session takes most of the CPU cycles when compared to joining an
existing multicast replication session. Most resources associated with a multicast replication session can be
cached after the session ends.
Hence, when a new IGMP join request is received later, these resources can be reused.
The multicast session replication cache is available only on an active SUP. When SUPSO happens, all cached
sessions are lost, and are then recreated on the new active SUP when an IGMP/MLD join request is received.
When LCSO happens, all cache sessions of this LC are cleared and are recreated on the new active LC when
an IGMP/MLD join request is received.
How to Configure the DOCSIS 3.0 Multicast Support

This section describes the following tasks that are required to implement DOCSIS 3.0 Multicast Support on
Cisco CMTS Routers:
Configuring Basic Multicast Forwarding

To configure a basic multicast forwarding profile that can be applied to a DOCSIS 3.0 multicast configuration,
use the ip multicast-routing command. You must configure a multicast routing profile before you can proceed
with a multicast group.
Procedure

Router> enable

Example:
Step 3 IP multicast-routing [vrf] Enables multicast routing globally or on a particular virtual

routing and forwarding (VRF) interface.
Example:
Router(config)# IP multicast-routing vrf
946
Configuring Querier’s Robustness Variable

Step 4 interface bundle number Configures the interface bundle and enters interface
configuration mode.
Example:
Step 5 IP pim sparse-mode Configures sparse mode of operation.

Example: Note The Cisco CMTS router must have a Protocol
Independent Multicast (PIM) rendezvous point
Router(config-if)# IP pim sparse-mode (RP) configured for the PIM sparse mode. The
Supervisor is configured using the ip pim
rp-address command or Auto-Supervisor
configuration protocol.
Step 6 IP pim sparse-dense-mode Configures the interface for either sparse mode or dense
mode of operation, depending on the mode in which the
Example:
multicast group is operating.
Router(config-if)# IP pim sparse-dense-mode
Step 7 IP igmp version version-number Configures the interface to use IGMP version 3.
Example:
Router(config-if)# IP igmp version 3
Step 8 IP igmp v3-query-max-response-time response_time Configures the maximum query response time for igmp
version 3.
Example:
Router(config-if)# IP igmp
v3-query-max-response-time 500
Configuring Querier’s Robustness Variable

Ability to configure Querier’s Cisco IOS XE This feature fine-tunes the IGMP robustness
Robustness Variable value in Bengaluru 17.6.1a variable to allow for expected packet loss on a
IGMP queries subnet. You can increase the robustness variable
on a congested network to increase the number of
times that packets are resent.
You can configure a robustness value to compensate for packet loss on a congested network. The robustness
value is used by the IGMP software to determine the number of times to send messages.
The following example shows how to configure robustness value:
Router(config-if)# ip igmp robustness-variable 1

[Bundle1] Warning: robustness variable of 1 is advised only for reliable
947
Configuring Multicast DSID Forwarding
links. Please be aware of the other IGMP parameters that may be affected by this
configuration change.
Router (config-if)#end
Configuring Multicast DSID Forwarding

The multicast DSID forwarding is enabled by default. You cannot configure this feature.
Configuring Explicit Tracking

The Explicit Tracking feature is enabled by default. You cannot configure it.
Configuring Multicast QoS

To configure a Multicast QoS profile that can be applied to a DOCSIS 3.0 configuration, use the cable
multicast group-qos command. You must configure a Multicast QoS profile before you can add a Multicast
QoS profile to a QoS multicast group.
Procedure

Router> enable

Example:
Step 3 cable service class class-index name service-class-name Configures the name of the cable service class.
Example:
Router(config)# cable service class 1 name

MQOS_DEFAULT
Step 4 cable service class class-index downstream Configures the downstream for the cable service class.
Example:
Router(config)# cable service class 1 downstream
Step 5 cable service class class-index max-rate Configures the maximum allowed bandwidth for the cable
maximum-bandwidth-allowed service class.
Example:
Router(config)# cable service class 1 max-rate

10000000
948
Selecting a Forwarding Interface Based on Service Flow Attribute

Step 6 cable service class class-index min-rate cir Configures the minimum committed information rate for
the cable service class.
Example:
Router(config)# cable service class 1 min-rate

1000000
Step 7 cable multicast group-qos default scn service-class-name Specifies the default service class name for the QoS profile.
aggregate
Example:
Router(config)# cable multicast group-qos default

scn MQOS_DEFAULT aggregate
Step 8 cable multicast qos group number priority value Configures a multicast QoS group and enters multicast
QoS configuration mode, and specifies the priority of the
Example:
cable multicast QoS group.
priority 1
Step 9 application-id app-id Specifies the application identification number of the

multicast QoS group. This value is configured to enable
Example:
admission control to the multicast QoS group.
Step 10 session-range ip-address ip-mask Specifies the session range IP address and IP mask of the
multicast QoS group. You can configure multiple session
Example:
ranges.
255.0.0.0
Step 11 cable multicast qos group number priority value [global] Specifies the multicast QoS group identifier.
Example:
Router(config)#cable multicast qos group 20

priority 63 global

The Service Flow Attribute feature allows a bonded CM to listen to multiple bonding groups, and using the
interface-specific bit-masks, the CM can select the best route to receive multicast traffic.
The Service Flow Attribute feature allows selection of a forwarding interface based on the DOCSIS 3.0
construct named “service flow attribute mask.” Every interface has an attribute bit-mask depicting attributes
of that interface. The multicast service class specified in the group QoS configuration contains required and
forbidden attribute bit-masks. If a bonded CM can listen to multiple bonding groups (wideband interfaces),
using specific bit-masks in the service class as well as on the bonding group, then one of these bonding groups
can be selected for forwarding of multicast traffic.
949
Procedure

Router> enable

Example:
Step 3 cable service class class-index name name Configures the service class name.
Example:
Router(config)# cable service class 10 name

mcast10
Step 4 cable service class class-index downstream Configures the downstream for the selected service class.
Example:
Router(config)# cable service class 10 downstream
Step 5 cable service class class-index max-rate maximum-rate Configures the maximum rate for the selected service class.
Example:
Router(config)# cable service class 10 max-rate

1000000
Step 6 cable service class class-index min-rate minimum-rate Configures the minimum rate for the selected service class.
Example:
Router(config)# cable service class 10 min-rate

100000
Step 7 cable service class class-index req-attr-mask Configures the required attribute mask for the selected
required-attribute-mask service class.
Example:
Router(config)# cable service class 10

req-attr-mask 8000000F
Step 8 cable service class class-index forb-attr-mask Configures the forbidden attribute mask for the selected
forbidden-attribute-mask service class name.
Example:
Router(config)# cable service class 10

forb-attr-mask 7FFFFFF0
950

Step 9 cable multicast group-qos number scn service-class-name Configures the cable multicast group QoS identifier,
aggregate service class name, and multicast value.
Example:
Router(config)# cable multicast group-qos 1 scn

10 mcast10 aggregate
Step 10 cable multicast qos group group priority priority Configures the cable MQoS group and enters MQoS
configuration mode.
Example:

priority 1
Step 11 session-range session-range mask Specifies session range.

Example:

255.255.255.255
Step 12 group-qos qos Specifies the group QoS.

Example:
Router(config-mqos)# group-qos 1
Step 13 exit Returns to global configuration mode.

Example:
Router(config-mqos)# exit
Step 14 interface bundle number Configures the interface bundle with the IP address, helper
address, and MQoS group.
• ip address ip mask
• ip pim sparse-mode
• ip helper-address helper-address
• cable multicast-qos group group
Example:
Router(config)# interface Bundle1

Router(config-if)#ip address 40.1.1.1
255.255.255.0
Router(config-if)#ip pim sparse-mode
Router(config-if)#ip helper-address 2.39.16.1
Router(config-if)#cable multicast-qos group 1
Step 15 exit Returns to global configuration mode.

Example:
951
Configuring Multicast DSID Forwarding Disabled Mode

Step 16 interface wideband-cable Selects the interface for forwarding based on the bit-masks
slot/subslot/port:wideband-channel specified in the service class and on the wideband interface.
• description description
• cable bundle number
• cable rf-channel channel-list grouplist
bandwidth-percent bw-percent
• cable downstream attribute-mask attribute-mask
Example:
Router(config)# interface Wideband-Cable1/0/0:0

Router(config-if)# description cable rf-channels
channel-list 0-7 bandwidth-percent 20
Router(config-if)# cable rf-channels channel-list
0-7 bandwidth-percent 20
Router(config-if)# cable downstream attribute-mask
8000000F

Example:
Configuring Multicast DSID Forwarding Disabled Mode

To disable MDF on the cable modem, use the cable multicast mdf-disable command in global configuration
mode.
Note Multicast encryption based on BPI+ is not supported on non-MDF cable modems, if IGMP SSM mapping is
used.
Procedure

Router> enable

Example:
952
Configuring Multicast Replication Session Globally

Step 3 cable multicast mdf-disable [wb-incapable-cm] Disables MDF capability on the cable modem.
Example:
Router(config)# cable multicast mdf-disable

Example:
Router#
Configuring Multicast Replication Session Globally

Use the following command to configure the maximum number of multicast replication sessions globally and
the value is configured per L2 forwarding interface.
If the operator does not configure a value for the maximum number, by default, is set to 0 for all L2 forwarding
interfaces, and the cache function is not valid. Cisco cBR does not cache the multicast replication sessions.
If the value is changed from a number such as 10 to 0, all current caches is cleared. The value range is from
0 to 500.
The following example shows how to set the maximum number of cache to 0:
enable
configure terminal
cable multicast ses-cache 0
The following example shows how to change the current value:

enable
configure terminal
[no|default] cable multicast ses-cache <0-500>
Configuring Multicast Replication Sessions on Forwarding

Interface
Use the following command to enable the multicast replication session on each L2 forwarding interface.
The value range for the maximum number is 0 to 500. If the value is changed from a number such as 10 to 0,
all current caches is cleared.
The configured value for the interface has higher priority than the system value. The following example shows
how to configure session cache on forwarding interface and make Cisco cBR use the system values:
enable
configure terminal
interface wideband-Cable {slot /subslot /controller :wideband-channel}
953
Clearing Multicast Replication Cache
[no|default] cable multicast ses-cache
The following example shows how to set the maximum number of cache for the interface:
enable
configure terminal
interface integrated-Cable {slot/subslot/port:rf-channel}
The following example shows how to configure a value 0 for an interface:

enable
configure terminal
interface integrated-Cable {slot/subslot/port:rf-channel}
no cable multicast ses-cache
Clearing Multicast Replication Cache

Use the following command to clear the multicast replication session for all or for a specific L2 forwarding
interface. The system deletes all current cache entries for all L2 forwarding interfaces or for a specific L2
interface.
enable
clear cable multicast ses-cache [interface xxx | all | counter]
How to Monitor the DOCSIS 3.0 Multicast Support

To monitor the DOCSIS 3.0 Multicast Support feature, use the following procedures:
Verifying the Basic Multicast Forwarding

To verify the configuration parameters for basic multicast forwarding, use the show ip mroute command as
Router# show ip mroute
IP Multicast Routing Table

Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,
T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,
X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
U - URD, I - Received Source Specific Host Report,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group,
V - RD & Vector, v - Vector
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 230.1.1.1), 00:00:03/00:02:55, RP 30.1.1.1, flags: S

Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Bundle1, Forward/Sparse, 00:00:03/00:02:55, H
(*, 224.0.1.40), 00:12:02/00:02:19, RP 30.1.1.1, flags: SJCL
954
Verifying the Multicast DSID Forwarding
Incoming interface: Null, RPF nbr 0.0.0.0

Outgoing interface list:
Bundle1, Forward/Sparse, 00:12:02/00:02:19
To verify the multicast information for the specified virtual interface bundle, based on IGMPv3, use the show
cable bundle multicast command as shown in the following example:
Router# show cable bundle 1 multicast
CableBundle Interface Source IP Multicast IP MAC Address

1 Bundle1.1 * 230.1.1.1 0100.5e00.0001
To verify the MAC forwarding table for the specified virtual interface bundle, based on IGMPv3, use the
show cable bundle forwarding command as shown in the following example:
Router# show cable bundle 1 forwarding
MAC address Interface Flags Location link sublink

00c0.5e01.0203 Cable8/0/0 3 64E5BF60 0 64E5BE00
00c0.5e01.0203 Cable7/0/0 3 64E5BE00 0 0
00c0.5e01.0101 Cable8/0/0 3 64E5BEE0 0 64E5BE40
Verifying the Multicast DSID Forwarding

To verify the entire DSID database content, use the show cable multicast dsid command as shown in the
following example:
Router# show cable multicast dsid

Multicast Group : 230.1.2.3
Source : *
IDB : Bu2 Interface: Mo1/1/0:0 Dsid: 0x1F078
StatIndex : 2 SAID: DEFAULT
Source : *
StatIndex : 3 SAID: 8196
Source : *
StatIndex : 4 SAID: 8197

To verify the entire database content, use the show cable multicast db command as shown in the following
example:
Router# show cable multicast db
interface : Bundle1
Session (S,G) : (*,230.1.1.1)
Fwd Intfc Sub Intfc Host Intfc CM Mac Hosts
Wi1/1/0:0 Bundle1 Ca5/0/0 0018.6852.8056 1
To verify the information for the registered and unregistered CMs, use the show cable modem verbose
Router# show cable modem 0010.7bb3.fcd1 verbose
955
Verifying the Explicit Tracking Feature
MAC Address : 00C0.7bb3.fcd1

IP Address : 10.20.113.2
Prim Sid : 1
QoS Profile Index : 6
Interface : C5/0/U5
sysDescr : Vendor ABC DOCSIS 2.0 Cable Modem
Upstream Power : 0 dBmV (SNR = 33.25 dBmV)
Downstream Power : 0 dBmV (SNR = ----- dBmV)
Timing Offset : 1624
Received Power : 0.25
Qos Provisioned Mode : DOC1.0
Phy Operating Mode : atdma
Capabilities : {Frag=N, Concat=N, PHS=N, Priv=BPI}
Sid/Said Limit : {Max Us Sids=0, Max Ds Saids=0}
Optional Filtering Support : {802.1P=N, 802.1Q=N}
Number of CPE IPs : 0(Max CPEs = 1)
CFG Max-CPE : 1
Flaps : 373(Jun 1 13:11:01)
DSA/DSX messages : reject all
Dynamic Secret : A3D1028F36EBD54FDCC2F74719664D3F
Spoof attempt : Dynamic secret check failed
Total Time Online : 16:16
Verifying the Explicit Tracking Feature

To verify explicit tracking information, use the show cable multicast db command as shown in the following
example:
Router# show cable multicast db
Interface : Bundle1
Session (S,G) : (*,230.1.1.1)
Fwd Intfc Sub Intfc Host Intfc CM Mac Hosts
Mo1/1/0:0 Bundle1 Ca5/0/0 0018.6852.8056 1
Verifying the Multicast QoS Feature

To verify the cable MQoS details, use the show cable multicast qos commands as shown in the following
example:
Router# show cable multicast qos ?

group-config Display Multicast Group Config information
group-encryption Display Multicast Group Encryption information
group-qos Display Multicast Group QOS information
Router# show cable multicast qos group-config
956
Verifying the Service Flow Attributes
Multicast Group Config 1 : Priority 1

Group QOS - 1
Group Encryption - 1
Session Range - Group Prefix 230.0.0.0 Mask 255.0.0.0 Source Prefix 0.0.0.0 Mask 0.0.0.0
Router# show cable multicast qos group-encryption
Multicast Group Encryption 1 : Algorithm 56bit-des
Router# show cable multicast qos group-qos
Group QOS Index Service Class Control Igmp Limit Override
DEFAULT MQOS_DEFAULT Aggregate NO-LIMIT 1 MQOS Aggregate NO-LIMIT
To verify the DOCSIS service flows on a given cable interface, use the show interface service-flow command
as shown in the following example:
Router# show interface cable 6/0 service-flow
Sfid Sid Mac Address QoS Param Index Type Dir Curr Active
BG/CH
Prov Adm Act State Time
4 8193 ffff.ffff.ffff 3 3 3 sec(S) DS act 21h57m
5 8196 ffff.ffff.ffff 4 4 4 sec(S) DS act 00:17
Verifying the Service Flow Attributes

To verify the configuration of service flow attributes on the service class configuration, use the show cable
service-class verbose command as shown in the following example:
Router# show cable service-class 10 verbose

Index: 10
Name: mcast10
Direction: Downstream
Traffic Priority: 0
Maximum Sustained Rate: 1000000 bits/sec
Max Burst: 3044 bytes
Minimum Reserved Rate: 1000000 bits/sec
Minimum Packet Size 0 bytes
Admitted QoS Timeout 200 seconds
Active QoS Timeout 0 seconds
Required Attribute Mask 8000000F
Forbidden Attribute Mask 7FFFFFF0
Scheduling Type: Undefined
Max Latency: 0 usecs
Parameter Presence Bitfield: {0x3148, 0x0}
To verify the configuration of SF attributes on the Wideband interface configuration, use the show
running-config interface command as shown in the following example:
Router# show running-config interface Wideband-Cable 1/0/0:2

cable bundle 1
cable rf-channel 3
cable downstream attribute-mask 8000000F
end
Verifying the Multicast Group Classifiers

To verify the details of the Group Classifier Rule, use the show interface wideband-cable multicast-gcr
957
Router# show interface wideband-cable 1/1/0:0 multicast-gcr

Group Classifier Rules on Wideband-Cable1/1/0:0:
Classifier_id Group_id Group_Qos_id Sid SFID ref_count
7 1 1 8196 10 1
8 2 1 8197 11 1
Make sure that CM can listen to the RF-frequencies specified for the Wideband interfaced chosen for forwarding
multicast traffic.
Viewing Current Cache

Use this command to show the current multicast replication session per L2 forwarding interface.
• If you do not specify an interface, this command shows a summary of the current L2 forwarding interface.
The summary includes the cache number.
• If you specify an interface, this command shows a summary of the interface. Add the verbose option for
more detailed information of the cache.
Router#show cable multicast ses-cache global summary
Global Cache Config: 20

-----------------------------------------------------------------
Fwd Cache Cache Cache Cache
Intfc Config Used Missed Hitted
Wi7/0/0:1 10 4 4 12
-----------------------------------------------------------------
Total 4 4 12
Router# show cable multicast ses-cache global
Fwd Intfc Sub Intfc Session (S,G)

Wi7/0/0:0 Bundle1 (30.30.30.30,227.0.0.20)
Bundle1 (30.30.30.30,227.0.0.22)
Wi7/0/0:1 Bundle1 (30.30.30.30,226.0.0.20)

Bundle1 (30.30.30.30,226.0.0.22)
Bundle1 (30.30.30.30,226.0.0.23)
Bundle1 (30.30.30.30,226.0.0.21)
Router#show cable multicast ses-cache interface wi7/0/0:1
Fwd Intfc Sub Intfc Session (S,G)

Wi7/0/0:1 Bundle1 (30.30.30.30,226.0.0.20)
Bundle1 (30.30.30.30,226.0.0.22)
Bundle1 (30.30.30.30,226.0.0.23)
Bundle1 (30.30.30.30,226.0.0.21)
Router# show cable multicast ses-cache interface wi7/0/0:1 summary
Global Cache Config: 20

--------------------------------------------------
Fwd Cache Cache Cache Cache
Intfc Config Used Missed Hitted
958
Configuration Examples for DOCSIS 3.0 Multicast Support
Wi7/0/0:1 10 4 4 12
Router# show cable multicast ses-cache wi8/0/0:0 verbose
Source : 100.0.0.2
Act GCRs : 1
Interface : Bu255 State: A GI: Bu255 RC: 0
GCR : GC SAID SFID Key GQC GEn
10 8858 24 0 1 0
Source : 100.0.0.2
Act GCRs : 1
10 8859 25 0 1 0
Total session cache num: 2
For the Cache Missed value, the value is increased for a new join request when cached entry is not available
for reusing.
Configuration Examples for DOCSIS 3.0 Multicast Support

Example: Configuring Basic Multicast Forwarding
Note The commands given below are required to enable the Cisco CMTS to forward multicast packets. However,
Multicast QoS, and Authorization features are all optional for multicast packets to be forwarded correctly.
In the following example, a basic multicast forwarding profile is configured.
ip multicast-routing
ip pim sparse-dense-mode
interface Bundle 1
ip pim sparse-mode
ip igmp version 3
959
Example: Configuring Multicast QoS
Example: Configuring Multicast QoS
Note A default service class and GQC must be defined before proceeding with configuring Multicast QoS.
In the following example, Multicast QoS is configured. You should define three objects and templates and
then associate these to a particular bundle or forwarding interface. The objects are Service-Class,
Group-QoS-Config (GQC), and Group-Config.
cable service class 1 name MQOS_DEFAULT

cable service class 1 downstream
cable service class 1 max-rate 10000000
cable service class 1 min-rate 1000000
cable multicast group-qos default scn MQOS_DEFAULT aggregate
cable multicast group-qos 10 scn MQOS single
cable multicast qos group 20 priority 1
application-id 10
session-range 230.0.0.0 255.0.0.0
tos 1 6 15
vrf name1
cable multicast qos group 20 priority 63 global
Example: Configuring Forwarding Interface Selection Based on Service Flow

Attribute
In the following example, the service flow attribute-based Forwarding Interface Selection is configured. To
send multicast traffic for group 230.1.1.1, interface W6/0/0:0 is selected. The multicast QoS parameters are
taken from group qos 1 (effectively from service class “mcast10”).
cable service class 10 name mcast10

cable service class 10 min-rate 1000000
cable service class 10 req-attr-mask 8000000F
cable service class 10 forb-attr-mask 7FFFFFF0
cable multicast group-qos 1 scn mcast10 aggregate
cable multicast qos group 1 priority 1
session-range 230.1.1.1 255.255.255.255
group-qos 1
interface Bundle1
ip address 40.1.1.1 255.255.255.0
ip pim sparse-mode
ip helper-address 2.39.16.1
cable multicast-qos group 1
end
cable bundle 10
cable downstream attribute-mask 8000000F
end
Example: Configuring Multicast Replication Session

The following example shows how to enable the multicast replication session on each L2 forwarding interface.
960
enable
conf t
interface xxx
[no|default] cable multicast ses-cache

The following sections provide references related to the DOCSIS 3.0 Multicast Support on the CMTS Routers.
Related Documents
CMTS cable commands http://www.cisco.com/en/US/docs/ios/cable/command/reference/

cbl_book.htmlCisco IOS CMTS Cable Command Reference
Multicast VPN and DOCSIS 3.0 Multicast Multicast VPN and DOCSIS 3.0 Multicast QoS Support
QoS
DOCSIS 3.0 QoS Support DOCSIS WFQ Scheduler on the Cisco CMTS Routers
Standards
Standard Title
CM-SP-CMCIv3-I01-080320 Cable Modem to Customer Premise Equipment Interface Specification
CM-SP-MULPIv3.0-I08-080522 MAC and Upper Layer Protocols Interface Specification
CM-SP-OSSIv3.0-I07-080522 Operations Support System Interface Specification
CM-SP-PHYv3.0-I07-080522 Physical Layer Specification
CM-SP-SECv3.0-I08-080522 Security Specification
MIBs
4
MIB MIBs Link
• DOCS-MCAST-AUTH-MIB To locate and download MIBs for selected platforms, Cisco software releases,
• DOCS-MCAST-MIB and feature sets, use Cisco MIB Locator found at the following URL:
4
Not all supported MIBs are listed.
961
Feature Information for DOCSIS 3.0 Multicast Support
RFCs
RFC Title
No new or modified RFCs are supported by this feature, and support for existing RFCs has not been —
modified by this feature.
Description Link

Feature Information for DOCSIS 3.0 Multicast Support

Table 165: Feature Information for DOCSIS 3.0 Multicast Support
DOCSIS 3.0 Multicast Support Cisco IOS XE Fuji 16.7.1 This feature was integrated into the Cisco cBR
Series Converged Broadband Routers.
Dynamic Multicast Replication Cisco IOS XE Fuji 16.7.1 This feature was integrated into the Cisco cBR
Sessions Series Converged Broadband Routers.
962
CHAPTER 65
IPv6 Segment Routing on Cisco cBR
In Cisco Converged Broadband Router, IPv6 Segment Routing is available as a sub mode of IPv6 address
configuration.
• Information about IPv6 Segment Routing, on page 965
• How to Configure IPv6 Segment Routing, on page 965
• Feature Information for IPv6 Segment Routing, on page 968
963
Digital PICs:

Module:

Modules:
line card reload.
964
Information about IPv6 Segment Routing
Information about IPv6 Segment Routing

IPv6 Segment Routing (SR) is an SDN technology supporting IPv6 forwarding. In SR, a source or edge router
performs source routing of traffic and encodes it as a segment list in an IPv6 routing extension header. The
network is not required to maintain a per-application or per-flow state.
Any IPv6 capable node in a network may forward IPv6 traffic with an SR extension header to the first segment
in the segment list without supporting IPv6 Segment Routing (SRv6).
At the node that hosts the current segment in the segment list, SRv6 is configured to modify the destination
address of the traffic containing the SR extension header and destined to that segment ID. As part of SRv6
final processing, the next segment ID in the SR extension header is written to the destination address of the
packet and a lookup is performed to forward the traffic to the new destination address.
The forwarding and SRv6 end processing continues at nodes hosting the segment IDs in the SR extension
header until the last segment in the list is removed and the traffic is delivered to its ultimate destination.
Restriction for Configuring IPv6 Segment Routing

Configuring duplicate IPv6 addresses on the same interface is not allowed.
How to Configure IPv6 Segment Routing

Configuring IPv6 Segment Routing on cBR
To configure IPv6 segment routing, use the following procedure.
1. Enter segment-routing sub mode when configuring an IPv6 address on an interface.
enable
configure terminal
interface type [slot_#/]port_#
ipv6 address ipv6_address_prefix/prefix_length
ipv6 address ipv6_address_prefix/prefix_length segment-routing
2. Define a local prefix as an SID

ipv6-sr prefix-sid
exit
Verifying IPv6 Segment Routing Configuration

The following example shows how to verify SRv6 configuration:c
Router#sh run
*Oct 17 13:13:23.975: %SYS-5-CONFIG_I: Configured from console by console
Router#sh run | sec Ether
no ip address
shutdown
965
Configure Multiple IPv6 Addresses for Segment Routing
ipv6 address 2001::2001/64 segment-routing >>>>>>>

ipv6-sr prefix-sid >>>>>>>
Configure Multiple IPv6 Addresses for Segment Routing

To configure multiple IPv6 addresses for SRv6 under the same interface, use the following commands.
1. Enter segment-routing sub mode when configuring an IPv6 address on an interface.
enable
configure terminal
2. Define a local prefix as an SID.

ipv6-sr prefix-sid
exit
Verifying IPv6 Segment Routing Configuration on Multiple IPv6 Addresses

The following example shows how to verify SRv6 configuration for multiple IPv6 addresses:
no ip address
shutdown
ipv6 address 2001:db8:110::/64 segment-routing >>> submode 1
ipv6-sr prefix-sid
ipv6 address 2001:db9:111::/64 segment-routing >>> submode 2
ipv6-sr prefix-sid
no ip address
shutdown
no ip address
shutdown
no ip address
shutdown
no ip address
shutdown
no ip address
shutdown
Disabling Prefix SID

To disable the local prefix SID associated to the segment ID, use the following commands.
enable
configure terminal
no ipv6-sr prefix-sid
end
966
Verifying whether Prefix SID is Disabled
Verifying whether Prefix SID is Disabled

The following example shows how to verify whether the prefix SID is disabled:
no ip address
shutdown
ipv6 address 110::110/64 segment-routing >>> "ipv6-sr prefix sid" is no longer present
ipv6 address 111::111/64 segment-routing
ipv6-sr prefix-sid
Disabling SRv6 for a Prefix-SID

To disable SRv6 configuration for an IPv6 address and remove the IPv6 address, use the following command:
enable
configure terminal
no ipv6 address ipv6_address_prefix/prefix_length segment-routing
end
Verifying whether SRv6 is Disabled and Prefix SID Removed

The following example shows how to verify whether SRv6 is disabled and the prefix SID is removed for the
prefix SID.
Router#sh run |
*Oct 17 13:17:51.523: %SYS-5-CONFIG_I: Configured from console by console
no ip address
shutdown
ipv6 address 110::110/64 segment-routing
ipv6 address 111::111/64 segment-routing is entirely removed from ethernet0/0
This section provides examples for IPv6 Segment Routing.
Example: Configuring IPv6 Segment Routing on Cisco cBR

Router#conf terminal
Router(config)#inter Ether0/0
Router(config-if)#ipv6 address 110::110/64 ?
anycast
eui-64
segment-routing
<cr>
Router(config-if)#ipv6 address 110::110/64 segment-routing
Router(config-if-sr-ipv6)#?
ipv6 address segment-routing mode configuration commands:
default Set a command to its defaults
exit Exit from SR submode
ipv6-sr Request options specific to IPV6 segment-routing
no Negate a command or set its defaults
967
Example: Configure Multiple IPv6 Addresses for SRv6
Router(config-if-sr-ipv6)#ipv6-sr ?
prefix-sid Set host prefix as IPv6 SR identifier prefix-sid
Router(config-if-sr-ipv6)#ipv6-sr prefix-sid
Router(config-if-sr-ipv6)#exit
Router(config)#exit
Router#
Example: Configure Multiple IPv6 Addresses for SRv6

Router(config)#inter Ether 0/0
Router(config-if)# ipv6 address 110::110/64 segment-routing
Router(config-if)# ipv6 address 111::111/64 segment-routing
Router(config-if-sr-ipv6)#ipv6-sr prefix-sid
Router(config-if-sr-ipv6)#end
Example: Disabling Prefix SID

Router(config-if)#inter Ether0/0
Router(config-if)#ipv6 address 110::110/64 segment-routing
Router(config-if-sr-ipv6)#no ipv6-sr prefix-sid
Router(config-if-sr-ipv6)#end
Example: Disabling SR with an Active Prefix SID

Router(config-if)#no ipv6 address 111::111/64 segment-routing
Feature Information for IPv6 Segment Routing

Table 167: Feature Information for IPv6 Segment Routing
IPv6 Segment Cisco IOS XE Fuji This feature was integrated into Cisco IOS XE Fuji 16.7.1
Routing 16.7.1 on theCisco cBR Series Converged Broadband Routers.
968
PA R T VII
IP Access Control Lists
• IP Access Control Lists, on page 971
• Creating an IP Access List and Applying It to an Interface, on page 983
• Creating an IP Access List to Filter IP Options, TCP Flags, Noncontiguous Ports, on page 1001
• Refining an IP Access List , on page 1023
• IP Named Access Control Lists, on page 1037
• IPv4 ACL Chaining Support , on page 1047
• IPv6 ACL Chaining with a Common ACL , on page 1053
• Commented IP Access List Entries, on page 1061
• Standard IP Access List Logging , on page 1067
• IP Access List Entry Sequence Numbering, on page 1073
• ACL IP Options Selective Drop , on page 1085
• ACL Syslog Correlation , on page 1091
• IPv6 Access Control Lists, on page 1105
• IPv6 Template ACL , on page 1115
• IPv6 ACL Extensions for Hop by Hop Filtering, on page 1121
CHAPTER 66
Access control lists (ACLs) perform packet filtering to control which packets move through a network and
to where. The packet filtering provides security by helping to limit the network traffic, restrict the access of
users and devices to a network, and prevent the traffic from leaving a network. IP access lists reduce the
chance of spoofing and denial-of-service attacks and allow dynamic, temporary user-access through a firewall.
IP access lists can also be used for purposes other than security, such as bandwidth control, restrict the content
of routing updates, redistribute routes, trigger dial-on-demand (DDR) calls, limit debug output, and identify
or classify traffic for quality of service (QoS) features. This module provides an overview of IP access lists.
Contents
• Information About IP Access Lists, on page 973
• Feature Information for IP Access Lists, on page 981
971
Digital PICs:

Module:

Modules:
line card reload.
972
Information About IP Access Lists
Information About IP Access Lists

Benefits of IP Access Lists
Access control lists (ACLs) perform packet filtering to control the flow of packets through a network. Packet
filtering can restrict the access of users and devices to a network, providing a measure of security. Access
lists can save network resources by reducing traffic. The benefits of using access lists are as follows:
• Authenticate incoming rsh and rcp requests—Access lists can simplify the identification of local users,
remote hosts, and remote users in an authentication database that is configured to control access to a
device. The authentication database enables Cisco software to receive incoming remote shell (rsh) and
remote copy (rcp) protocol requests.
• Block unwanted traffic or users—Access lists can filter incoming or outgoing packets on an interface,
thereby controlling access to a network based on source addresses, destination addresses, or user
authentication. You can also use access lists to determine the types of traffic that are forwarded or blocked
at device interfaces. For example, you can use access lists to permit e-mail traffic to be routed through
a network and to block all Telnet traffic from entering the network.
• Control access to vty—Access lists on an inbound vty (Telnet) can control who can access the lines to
a device. Access lists on an outbound vty can control the destinations that the lines from a device can
reach.
• Identify or classify traffic for QoS features—Access lists provide congestion avoidance by setting the
IP precedence for Weighted Random Early Detection (WRED) and committed access rate (CAR). Access
lists also provide congestion management for class-based weighted fair queueing (CBWFQ), priority
queueing, and custom queueing.
• Limit debug command output—Access lists can limit debug output based on an IP address or a protocol.
• Provide bandwidth control—Access lists on a slow link can prevent excess traffic on a network.
• Provide NAT control—Access lists can control which addresses are translated by Network Address
Translation (NAT).
• Reduce the chance of DoS attacks—Access lists reduce the chance of denial-of-service (DoS) attacks.
Specify IP source addresses to control traffic from hosts, networks, or users from accessing your network.
Configure the TCP Intercept feature to can prevent servers from being flooded with requests for connection.
• Restrict the content of routing updates—Access lists can control routing updates that are sent, received,
or redistributed in networks.
• Trigger dial-on-demand calls—Access lists can enforce dial and disconnect criteria.
Border Routers and Firewall Routers Should Use Access Lists

There are many reasons to configure access lists; for example, you can use access lists to restrict contents of
routing updates or to provide traffic flow control. One of the most important reasons to configure access lists
is to provide a basic level of security for your network by controlling access to it. If you do not configure
access lists on your router, all packets passing through the router could be allowed onto all parts of your
network.
973
Definition of an Access List
An access list can allow one host to access a part of your network and prevent another host from accessing
the same area. In the figure below, by applying an appropriate access list to the interfaces of the router, Host
A is allowed to access the Human Resources network and Host B is prevented from accessing the Human
Resources network.
Access lists should be used in firewall routers, which are often positioned between your internal network and
an external network such as the Internet. You can also use access lists on a router positioned between two
parts of your network, to control traffic entering or exiting a specific part of your internal network.
To provide some security benefits of access lists, you should at least configure access lists on border
routers--routers located at the edges of your networks. Such an access list provides a basic buffer from the
outside network or from a less controlled area of your own network into a more sensitive area of your network.
On these border routers, you should configure access lists for each network protocol configured on the router
interfaces. You can configure access lists so that inbound traffic or outbound traffic or both are filtered on an
interface.
Access lists are defined on a per-protocol basis. In other words, you should define access lists for every
protocol enabled on an interface if you want to control traffic flow for that protocol.

Access control lists (ACLs) perform packet filtering to control the movement of packets through a network.
Packet filtering provides security by limiting the access of traffic into a network, restricting user and device
access to a network, and preventing traffic from leaving a network. IP access lists reduce the chance of spoofing
and denial-of-service attacks, and allow dynamic, temporary user-access through a firewall.
IP access lists can also be used for purposes other than security, such as to control bandwidth, restrict the
content of routing updates, redistribute routes, trigger dial-on-demand (DDR) calls, limit debug output, and
identify or classify traffic for quality of service (QoS) features.
An access list is a sequential list that consists of at least one permit statement and possibly one or more deny
statements. In the case of IP access lists, these statements can apply to IP addresses, upper-layer IP protocols,
or other fields in IP packets.
Access lists are identified and referenced by a name or a number. Access lists act as packet filters, filtering
packets based on the criteria defined in each access list.
After you configure an access list, for the access list to take effect, you must either apply the access list to an
interface (by using the ip access-group command), a vty (by using the access-class command), or reference
the access list by any command that accepts an access list. Multiple commands can reference the same access
list.
In the following configuration, an IP access list named branchoffices is configured on Ten Gigabit Ethernet
interface 4/1/0 and applied to incoming packets. Networks other than the ones specified by the source address
and mask pair cannot access Ten Gigabit Ethernet interface 4/1/0. The destinations for packets coming from
sources on network 172.16.7.0 are unrestricted. The destination for packets coming from sources on network
172.16.2.0 must be 172.31.5.4.
ip access-list extended branchoffices

10 permit 172.16.7.0 0.0.0.3 any
20 permit 172.16.2.0 0.0.0.255 host 172.31.5.4
!
interface tengigabitethernet 4/1/0
ip access-group branchoffices in
974
Access List Rules
Access List Rules

The following rules apply to access lists:
• Only one access list per interface, per protocol, and per direction is allowed.
• An access list must contain at least one permit statement or all packets are denied entry into the network.
• The order in which access list conditions or match criteria are configured is important. While deciding
whether to forward or block a packet, Cisco software tests the packet against each criteria statement in
the order in which these statements are created. After a match is found, no more criteria statements are
checked. The same permit or deny statements specified in a different order can result in a packet being
passed under one circumstance and denied in another circumstance.
• If an access list is referenced by a name, but the access list does not exist, all packets pass. An interface
or command with an empty access list applied to it permits all traffic into the network.
• Standard access lists and extended access lists cannot have the same name.
• Inbound access lists process packets before the packets are routed to an outbound interface. Inbound
access lists that have filtering criteria that deny packet access to a network saves the overhead of routing
lookup. Packets that are permitted access to a network based on the configured filtering criteria are
processed for routing. For inbound access lists, when you configure a permit statement, packets are
processed after they are received, and when you configure a deny statement, packets are discarded.
• Outbound access lists process packets before they leave the device. Incoming packets are routed to the
outbound interface and then processed by the outbound access list. For outbound access lists, when you
configure a permit statement, packets are sent to the output buffer, and when you configure a deny
statement, packets are discarded.
• An access list can control traffic arriving at a device or leaving a device, but not traffic originating at a
device.
Helpful Hints for Creating IP Access Lists

The following tips will help you avoid unintended consequences and help you create more efficient, useful
access lists.
• Create the access list before applying it to an interface (or elsewhere), because if you apply a nonexistent
access list to an interface and then proceed to configure the access list, the first statement is put into
effect, and the implicit deny statement that follows could cause you immediate access problems.
• Another reason to configure an access list before applying it is because an interface with an empty access
list applied to it permits all traffic.
• All access lists need at least one permit statement; otherwise, all packets are denied and no traffic passes.
• Use the statement permit any any if you want to allow all other packets not already denied. Using the
statement permit any any in effect avoids denying all other packets with the implicit deny statement at
the end of an access list. Do not make your first access list entry permit any any because all traffic will
get through; no packets will reach the subsequent testing. In fact, once you specify permit any any, all
traffic not already denied will get through.
• Although all access lists end with an implicit deny statement, we recommend use of an explicit deny
statement (for example, deny ip any any). On most platforms, you can display the count of packets
975
Named or Numbered Access Lists
denied by issuing the show access-list command, thus finding out more information about who your
access list is disallowing. Only packets denied by explicit deny statements are counted, which is why
the explicit deny statement will yield more complete data for you.
• While you are creating an access list or after it is created, you might want to delete an entry.
• You cannot delete an entry from a numbered access list; trying to do so will delete the entire access
list. If you need to delete an entry, you need to delete the entire access list and start over.
• You can delete an entry from a named access list. Use the no permit or no deny command to delete
the appropriate entry.
• In order to make the purpose of individual statements more scannable and easily understood at a glance,
you can write a helpful remark before or after any statement by using the remark command.
• If you want to deny access to a particular host or network and find out if someone from that network or
host is attempting to gain access, include the log keyword with the corresponding deny statement so that
the packets denied from that source are logged for you.
• This hint applies to the placement of your access list. When trying to save resources, remember that an
inbound access list applies the filter conditions before the routing table lookup. An outbound access list
applies the filter conditions after the routing table lookup.

All access lists must be identified by a name or a number. Named access lists are more convenient than
numbered access lists because you can specify a meaningful name that is easier to remember and associate
with a task. You can reorder statements in or add statements to a named access list.
Named access lists support the following features that are not supported by numbered access lists:
• IP options filtering
• Noncontiguous ports
• TCP flag filtering
• Deleting of entries with the no permit or no deny command
Note Not all commands that accept a numbered access list will accept a named access list. For example, vty uses
only numbered access lists.
Standard or Extended Access Lists

All access lists are either standard or extended access lists. If you only intend to filter on a source address,
the simpler standard access list is sufficient. For filtering on anything other than a source address, an extended
access list is necessary.
• Named access lists are specified as standard or extended based on the keyword standard or extended
in the ip access-list command syntax.
• Numbered access lists are specified as standard or extended based on their number in the access-list
command syntax. Standard IP access lists are numbered 1 to 99 or 1300 to 1999; extended IP access lists
976
IP Packet Fields You Can Filter to Control Access
are numbered 100 to 199 or 2000 to 2699. The range of standard IP access lists was initially only 1 to
99, and was subsequently expanded with the range 1300 to 1999 (the intervening numbers were assigned
to other protocols). The extended access list range was similarly expanded.
Note Starting from Cisco IOS XE 16.9.4, use the ip access-list command to configure object-group based numbered
ACL.
Standard Access Lists

Standard IP access lists test only source addresses of packets (except for two exceptions). Because standard
access lists test source addresses, they are very efficient at blocking traffic close to a destination. There are
two exceptions when the address in a standard access list is not a source address:
• On outbound VTY access lists, when someone is trying to telnet, the address in the access list entry is
used as a destination address rather than a source address.
• When filtering routes, you are filtering the network being advertised to you rather than a source address.
Extended Access Lists

Extended access lists are good for blocking traffic anywhere. Extended access lists test source and destination
addresses and other IP packet data, such as protocols, TCP or UDP port numbers, type of service (ToS),
precedence, TCP flags, and IP options. Extended access lists can also provide capabilities that standard access
lists cannot, such as the following:
• Filtering IP Options
• Filtering TCP flags
• Filtering noninitial fragments of packets (see the module “Refining an IP Access List”)
Note Packets that are subject to an extended access list will not be autonomous switched.
IP Packet Fields You Can Filter to Control Access

You can use an extended access list to filter on any of the following fields in an IP packet. Source address
and destination address are the two most frequently specified fields on which to base an access list:
• Source address--Specifies a source address to control packets coming from certain networking devices
or hosts.
• Destination address--Specifies a destination address to control packets being sent to certain networking
devices or hosts.
• Protocol--Specifies an IP protocol indicated by the keyword eigrp, gre, icmp, igmp, ip, ipinip, nos,
ospf, tcp, or udp, or indicated by an integer in the range from 0 to 255 (representing an Internet protocol).
If you specify a transport layer protocol (icmp, igmp, tcp, or udp), the command has a specific syntax.
977
Wildcard Mask for Addresses in an Access List
• Ports and non-contiguous ports--Specifies TCP or UDP ports by a port name or port number. The
port numbers can be noncontiguous port numbers. Port numbers can be useful to filter Telnet traffic
or HTTP traffic, for example.
• TCP flags--Specifies that packets match any flag or all flags set in TCP packets. Filtering on specific
TCP flags can help prevent false synchronization packets.
• IP options--Specifies IP options; one reason to filter on IP options is to prevent routers from being
saturated with spurious packets containing them.
Wildcard Mask for Addresses in an Access List

Address filtering uses wildcard masking to indicate to the software whether to check or ignore corresponding
IP address bits when comparing the address bits in an access list entry to a packet being submitted to the
access list. By carefully setting wildcard masks, you can specify one or more IP addresses for permit or deny
tests.
Wildcard masking for IP address bits uses the number 1 and the number 0 to specify how the software treats
the corresponding IP address bits. A wildcard mask is sometimes referred to as an inverted mask because a
1 and 0 mean the opposite of what they mean in a subnet (network) mask.
• A wildcard mask bit 0 means check the corresponding bit value; they must match.
• A wildcard mask bit 1 means ignore that corresponding bit value; they need not match.
If you do not supply a wildcard mask with a source or destination address in an access list statement, the
software assumes an implicit wildcard mask of 0.0.0.0, meaning all values must match.
Unlike subnet masks, which require contiguous bits indicating network and subnet to be ones, wildcard masks
allow noncontiguous bits in the mask.
The table below shows examples of IP addresses and masks from an access list, along with the corresponding
addresses that are considered a match.
Table 169: Sample IP Addresses, Wildcard Masks, and Match Results
Address Wildcard Mask Match Results
0.0.0.0 255.255.255.255 All addresses will match the access list conditions.
172.18.0.0/16 0.0.255.255 Network 172.18.0.0
172.18.5.2/16 0.0.0.0 Only host 172.18.5.2 matches
172.18.8.0 0.0.0.7 Only subnet 172.18.8.0/29 matches
10.1.2.0 0.0.252.255 (noncontiguous bits in Matches any even-numbered network in the range of
mask) 10.1.2.0 to 10.1.254.0
978
Access List Sequence Numbers

The ability to apply sequence numbers to IP access list entries simplifies access list changes. Prior to the IP
Access List Entry Sequence Numbering feature, there was no way to specify the position of an entry within
an access list. If you wanted to insert an entry in the middle of an existing list, all of the entries after the desired
position had to be removed, then the new entry was added, and then all the removed entries had to be reentered.
This method was cumbersome and error prone.
This feature allows users to add sequence numbers to access list entries and resequence them. When you add
a new entry, you specify the sequence number so that it is in a desired position in the access list. If necessary,
entries currently in the access list can be resequenced to create room to insert the new entry.
Access List Logging

The Cisco IOS software can provide logging messages about packets permitted or denied by a single standard
or extended IP access list entry. That is, any packet that matches the entry will cause an informational logging
message about the packet to be sent to the console. The level of messages logged to the console is controlled
by the logging console global configuration command.
The first packet that triggers the access list entry causes an immediate logging message, and subsequent packets
are collected over 5-minute intervals before they are displayed or logged. The logging message includes the
access list number, whether the packet was permitted or denied, the source IP address of the packet, and the
number of packets from that source permitted or denied in the prior 5-minute interval.
However, you can use the ip access-list log-update command to set the number of packets that, when match
an access list (and are permitted or denied), cause the system to generate a log message. You might want to
do this to receive log messages more frequently than at 5-minute intervals.
Caution If you set the number-of-matches argument to 1, a log message is sent right away, rather than caching it; every
packet that matches an access list causes a log message. A setting of 1 is not recommended because the volume
of log messages could overwhelm the system.
Even if you use the ip access-list log-update command, the 5-minute timer remains in effect, so each cache
is emptied at the end of 5 minutes, regardless of the count of messages in each cache. Regardless of when the
log message is sent, the cache is flushed and the count reset to 0 for that message the same way it is when a
threshold is not specified.
Note The logging facility might drop some logging message packets if there are too many to be handled or if there
is more than one logging message to be handled in 1 second. This behavior prevents the router from crashing
due to too many logging packets. Therefore, the logging facility should not be used as a billing tool or an
accurate source of the number of matches to an access list.
Alternative to Access List Logging

Packets matching an entry in an ACL with a log option are process switched. It is not recommended to use
the log option on ACLs, but rather use NetFlow export and match on a destination interface of Null0. This is
done in the CEF path. The destination interface of Null0 is set for any packet that is dropped by the ACL.
979
Additional IP Access List Features

Beyond the basic steps to create a standard or extended access list, you can enhance your access lists as
mentioned below. Each of these methods is described completely in the module entitled “Refining an Access
List.”
• You can impose dates and times when permit or deny statements in an extended access list are in effect,
making your access list more granular and specific to an absolute or periodic time period.
• After you create a named access list, you might want to add entries or change the order of the entries,
known as resequencing an access list.
• You can achieve finer granularity when filtering packets by filtering on noninitial fragments of packets.
Where to Apply an Access List

You can apply access lists to the inbound or outbound interfaces of a device. Applying an access list to an
inbound interface controls the traffic that enters the interface and applying an access list to an outbound
interface controls the traffic that exits the interface.
When software receives a packet at the inbound interface, the software checks the packet against the statements
that are configured for the access list. If the access list permits packets, the software processes the packet.
Applying access lists to filter incoming packets can save device resources because filtered packets are discarded
before entering the device.
Access lists on outbound interfaces filter packets that are transmitted (sent) out of the interface. You can use
the TCP Access Control List (ACL) Splitting feature of the Rate-Based Satellite Control Protocol (RBSCP)
on the outbound interface to control the type of packets that are subject to TCP acknowledgment (ACK)
splitting on an outbound interface.
You can reference an access list by using a debug command to limit the amount of debug logs. For example,
based on the filtering or matching criteria of the access list, debug logs can be limited to source or destination
addresses or protocols.
You can use access lists to control routing updates, dial-on-demand (DDR), and quality of service (QoS)
features.
Related Documents
IP access list commands: complete command syntax, Cisco IOS IP Addressing Services Command
command mode, command history, defaults, usage Reference
guidelines, and examples
Filtering on source address, destination address, or Creating an IP Access List and Applying It to an
protocol Interface” module
Filtering on IP Options, TCP flags, noncontiguous ports, Creating an IP Access List to Filter IP Options, TCP
or TTL Flags, or Noncontiguous Ports module
980
Feature Information for IP Access Lists
Standards
Standards & RFCs Title
None —
MIBs
MIB MIBs Link
None To locate and download MIBs for selected platforms, Cisco IOS XE software releases, and feature
sets, use Cisco MIB Locator found at the following URL:
Description Link


Table 170: Feature Information for IP Access Lists
IP access lists Cisco IOS XE Fuji This feature was integrated into Cisco IOS XE Fuji 16.7.1 on
981
982
CHAPTER 67
Creating an IP Access List and Applying It to an
Interface
IP access lists provide many benefits for securing a network and achieving nonsecurity goals, such as
determining quality of service (QoS) factors or limiting debug command output. This module describes how
to create standard, extended, named, and numbered IP access lists. An access list can be referenced by a name
or a number. Standard access lists filter on only the source address in IP packets. Extended access lists can
filter on source address, destination address, and other fields in an IP packet.
After you create an access list, you must apply it to something in order for it to have any effect. This module
describes how to apply an access list to an interface. However, there are many other uses for access lists,
which are mentioned in this module and described in other modules and in other configuration guides for
various technologies.
Contents
• Information About Creating an IP Access List and Applying It to an Interface, on page 985
• How to Create an IP Access List and Apply It to an Interface, on page 986
• Configuration Examples for Creating an IP Access List and Applying It to a Physical Interface, on page
995
• Additional References Creating an IP Access List and Applying It to an Interface, on page 999
• Feature Information Creating an IP Access List and Applying It to an Interface, on page 1000
983
Digital PICs:

Module:

Modules:
984
Information About Creating an IP Access List and Applying It to an Interface
line card reload.
Information About Creating an IP Access List and Applying It

to an Interface
effect, and the implicit deny statement that follows could cause immediate access problems.
• Organize your access list so that more specific references in a network or subnet appear before more
general ones.
• A packet will match the first ACE in the ACL. Thus, a permit ip any any will match all packets, ignoring
all subsequent ACES.
denied by issuing the show access-list command, thus finding out more information about who your
• While you are creating an access list or after it is created, you might want to delete an entry. You can
delete an entry from a named access list. Use the no permit or no deny command to delete the appropriate
entry.
985
Access List Remarks
Access List Remarks

You can include comments or remarks about entries in any IP access list. An access list remark is an optional
remark before or after an access list entry that describes the entry so that you do not have to interpret the
purpose of the entry. Each remark is limited to 100 characters in length.
The remark can go before or after a permit or deny statement. Be consistent about where you add remarks.
Users may be confused if some remarks precede the associated permit or deny statements and some remarks
follow the associated statements.
The following is an example of a remark that describes function of the subsequent deny statement:
ip access-list extended telnetting

remark Do not allow host1 subnet to telnet out
deny tcp host 172.16.2.88 any eq telnet

Beyond the basic steps to create a standard or extended access list, you can enhance your access lists as
mentioned below. Each of these methods is described completely in the Refining an IP Access List module.
• You can impose dates and times when permit or deny statements in an extended access list are in effect,
making your access list more granular and specific to an absolute or periodic time period.
• After you create a named or numbered access list, you might want to add entries or change the order of
the entries, which are known as resequencing an access list.
• You can achieve finer granularity when filtering packets by filtering on noninitial fragments of packets.
How to Create an IP Access List and Apply It to an Interface

This section describes the general ways to create a standard or extended access list using either a name or a
number. Access lists are very flexible; the tasks simply illustrate one permit command and one deny command
to provide you the command syntax of each. Only you can determine how many permit and deny commands
you need and their order.
Note The first two tasks in this module create an access list; you must apply the access list in order for it to function.
If you want to apply the access list to an interface, perform the task “Applying the Access List to an Interface”.
Creating a Standard Access List to Filter on Source Address

If you want to filter on source address only, a standard access list is simple and sufficient. There are two
alternative types of standard access list: named and numbered. Named access lists allow you to identify your
access lists with a more intuitive name rather than a number, and they also support more features than numbered
access lists.
986
Creating a Named Access List to Filter on Source Address

Use a standard, named access list if you need to filter on source address only. This task illustrates one permit
statement and one deny statement, but the actual statements you use and their order depend on what you want
to filter or allow. Define your permit and deny statements in the order that achieves your filtering goals.
Step 1 enable
Example:
Device> enable

• Enter your password if prompted.

Example:
Step 3 ip access-list standard name

Example:
Device(config)# ip access-list standard R&D
Defines a standard IP access list using a name and enters standard named access list configuration mode.
Step 4 remark remark

Example:
Device(config-std-nacl)# remark deny Sales network
(Optional) Adds a user-friendly comment about an access list entry.

• A remark can precede or follow an access list entry.
• In this example, the remark reminds the network administrator that the subsequent entry denies the Sales network
access to the interface (assuming this access list is later applied to an interface).
Step 5 deny {source [source-wildcard] | any} [log]

Example:
Device(config-std-nacl)# deny 172.16.0.0 0.0.255.255 log
(Optional) Denies the specified source based on a source address and wildcard mask.
• If the source-wildcard is omitted, a wildcard mask of 0.0.0.0 is assumed, meaning match on all bits of the source
address.
• Optionally use the keyword any as a substitute for the source source-wildcard to specify the source and source
wildcard of 0.0.0.0 255.255.255.255.
987
• In this example, all hosts on network 172.16.0.0 are denied passing the access list.
• Because this example explicitly denies a source address and the log keyword is specified, any packets from that
source are logged when they are denied. This is a way to be notified that someone on a network or host is trying
to gain access.
Step 6 remark remark

Example:
Device(config-std-nacl)# remark Give access to Tester’s host
(Optional) Adds a user-friendly comment about an access list entry.

• A remark can precede or follow an access list entry.
• This remark reminds the network administrator that the subsequent entry allows the Tester’s host access to the
interface.
Step 7 permit {source [source-wildcard] | any} [log]

Example:
Device(config-std-nacl)# permit 172.18.5.22 0.0.0.0
Permits the specified source based on a source address and wildcard mask.
• Every access list needs at least one permit statement; it need not be the first entry.
address.
wildcard of 0.0.0.0 255.255.255.255.
• In this example, host 172.18.5.22 is allowed to pass the access list.
Step 8 Repeat some combination of Steps 4 through 7 until you have specified the sources on which you want to base your
access list.
Remember that all sources not specifically permitted are denied by an implicit deny statement at the end of the access
list.
Step 9 end
Example:
Device(config-std-nacl)# end
Exits standard named access list configuration mode and enters privileged EXEC mode.
Step 10 show ip access-list

Example:
Device# show ip access-list
988
Creating a Numbered Access List to Filter on Source Address
(Optional) Displays the contents of all current IP access lists.
Creating a Numbered Access List to Filter on Source Address

Configure a standard, numbered access list if you need to filter on source address only and you prefer not to
use a named access list.
IP standard access lists are numbered 1 to 99 or 1300 to 1999. This task illustrates one permit statement and
one deny statement, but the actual statements you use and their order depend on what you want to filter or
allow. Define your permit and deny statements in the order that achieves your filtering goals.
Step 1 enable
Example:
Device> enable


Example:
Step 3 access-list access-list-number permit {source [source-wildcard] | any} [log]

Example:
Device(config)# access-list 1 permit 172.16.5.22 0.0.0.0
Permits the specified source based on a source address and wildcard mask.
• Every access list needs at least one permit statement; it need not be the first entry.
• Standard IP access lists are numbered 1 to 99 or 1300 to 1999.
address.
wildcard of 0.0.0.0 255.255.255.255.
• In this example, host 172.16.5.22 is allowed to pass the access list.
Step 4 access-list access-list-number deny {source [source-wildcard] | any} [log]

Example:
Device(config)# access-list 1 deny 172.16.7.34 0.0.0.0
989
Creating an Extended Access List
Denies the specified source based on a source address and wildcard mask.
address.
• Optionally use the abbreviation any as a substitute for the source source-wildcard to specify the source and source
wildcard of 0.0.0.0 255.255.255.255.
• In this example, host 172.16.7.34 is denied passing the access list.
Step 5 Repeat some combination of Steps 3 through 6 until you have specified the sources on which you want to base your
access list.
Remember that all sources not specifically permitted are denied by an implicit deny statement at the end of the access
list.
Step 6 end
Example:
Device(config)# end
Exits global configuration mode and enters privileged EXEC mode.
Step 7 show ip access-list

Example:
(Optional) Displays the contents of all current IP access lists.
Creating an Extended Access List

If you want to filter on anything other than source address, you need to create an extended access list. There
are two alternative types of extended access list: named and numbered. Named access lists allow you to
identify your access lists with a more intuitive name rather than a number, and they also support more features.
For details on how to filter something other than source or destination address, see the syntax descriptions in
the command reference documentation.
Creating a Named Extended Access List

Create a named extended access list if you want to filter the source and destination address or filter a
combination of addresses and other IP fields.
SUMMARY STEPS
1. enable
3. ip access-list extended name
990
Creating a Named Extended Access List
4. deny protocol source [source-wildcard] destination [destination-wildcard] [option option-name]

[precedence precedence] [tos tos] [established] [log | log-input] [time-range time-range-name]
[fragments]
5. permit protocol source [source-wildcard] destination [destination-wildcard] [option option-name]
[precedence precedence] [tos tos] [established] [log | log-input] [time-range time-range-name]
[fragments]
6. Repeat some combination of Steps 4 through 7 until you have specified the fields and values on which
you want to base your access list.
7. end
8. show ip access-list
DETAILED STEPS

Device> enable

Example:
Step 3 ip access-list extended name Defines an extended IP access list using a name and enters
extended named access list configuration mode.
Example:
Device(config)# ip access-list extended acl1
Step 4 deny protocol source [source-wildcard] destination (Optional) Denies any packet that matches all of the
[destination-wildcard] [option option-name] [precedence conditions specified in the statement.
precedence] [tos tos] [established] [log | log-input]
• If the source-wildcard or destination-wildcard is
[time-range time-range-name] [fragments]
omitted, a wildcard mask of 0.0.0.0 is assumed,
Example: meaning match on all bits of the source or destination
address, respectively.
Device(config-ext-nacl)# deny ip 172.18.0.0
0.0.255.255 host 172.16.40.10 log • Optionally use the keyword any as a substitute for the
source source-wildcard or destination
destination-wildcard to specify the address and
wildcard of 0.0.0.0 255.255.255.255.
• Optionally use the keyword host source to indicate a
source and source wildcard of source 0.0.0.0 or the
abbreviation host destination to indicate a destination
and destination wildcard of destination 0.0.0.0.
• In this example, packets from all sources are denied
access to the destination network 172.18.0.0. Logging
messages about packets permitted or denied by the
access list are sent to the facility configured by the
991
Creating a Numbered Extended Access List

logging facility command (for example, console,
terminal, or syslog). That is, any packet that matches
the access list will cause an informational logging
message about the packet to be sent to the configured
facility. The level of messages logged to the console
is controlled by the logging console command.
Step 5 permit protocol source [source-wildcard] destination Permits any packet that matches all of the conditions
[destination-wildcard] [option option-name] [precedence specified in the statement.
precedence] [tos tos] [established] [log | log-input]
• Every access list needs at least one permit statement.
Example: • If the source-wildcard or destination-wildcard is
Device(config-ext-nacl)# permit tcp any any
meaning match on all bits of the source or destination
• Optionally use the keyword any as a substitute for the
wildcard of 0.0.0.0 255.255.255.255.
• In this example, TCP packets are allowed from any
source to any destination.
• Use the log-input keyword to include input interface,
source MAC address, or virtual circuit in the logging
output.
Step 6 Repeat some combination of Steps 4 through 7 until you Remember that all sources not specifically permitted are
have specified the fields and values on which you want to denied by an implicit deny statement at the end of the access
base your access list. list.
Step 7 end Exits standard named access list configuration mode and
enters privileged EXEC mode.
Example:
Device(config-ext-nacl)# end
Step 8 show ip access-list (Optional) Displays the contents of all current IP access
lists.
Example:

Create a numbered extended access list if you want to filter on source and destination address, or a combination
of addresses and other IP fields, and you prefer not to use a name. Extended IP access lists are numbered 100
to 199 or 2000 to 2699.
992
SUMMARY STEPS
1. enable
3. access-list access-list-number remark remark
4. access-list access-list-number permit protocol {source [source-wildcard] | any} {destination
[destination-wildcard] | any} [precedence precedence] [tos tos] [established] [log | log-input] [time-range
time-range-name] [fragments]
5. access-list access-list-number remark remark
6. access-list access-list-number deny protocol {source [source-wildcard] | any} {destination
[destination-wildcard] | any} [precedence precedence] [tos tos] [established] [log | log-input] [time-range
7. Repeat some combination of Steps 3 through 6 until you have specified the fields and values on which
you want to base your access list.
8. end
DETAILED STEPS

Device> enable

Example:
Step 3 access-list access-list-number remark remark (Optional) Adds a user-friendly comment about an access
list entry.
Example:
• A remark of up to 100 characters can precede or follow
Device(config)# access-list 107 remark allow Telnet an access list entry.
packets from any source to network 172.69.0.0
(headquarters)
Step 4 access-list access-list-number permit protocol {source Permits any packet that matches all of the conditions
[source-wildcard] | any} {destination [destination-wildcard] specified in the statement.
| any} [precedence precedence] [tos tos] [established] [log
• Every access list needs at least one permit statement;
| log-input] [time-range time-range-name] [fragments]
it need not be the first entry.
Example:
• Extended IP access lists are numbered 100 to 199 or
Device(config)# access-list 107 permit tcp any
2000 to 2699.
172.69.0.0 0.0.255.255 eq telnet
meaning match on all bits of the source or destination
993
Applying an Access List to an Interface

wildcard of 0.0.0.0 255.255.255.255.
• TCP and other protocols have additional syntax
available. See the access-list command in the
command reference for complete syntax.
Step 5 access-list access-list-number remark remark (Optional) Adds a user-friendly comment about an access
list entry.
Example:
• A remark of up to 100 characters can precede or follow
Device(config)# access-list 107 remark deny all an access list entry.
other TCP packets
Step 6 access-list access-list-number deny protocol {source Denies any packet that matches all of the conditions
[source-wildcard] | any} {destination [destination-wildcard] specified in the statement.
| any} [precedence precedence] [tos tos] [established] [log
| log-input] [time-range time-range-name] [fragments]
Example: meaning match on all bits of the source or destination
Device(config)# access-list 107 deny tcp any any
wildcard of 0.0.0.0 255.255.255.255.
have specified the fields and values on which you want to denied by an implicit deny statement at the end of the access
base your access list. list.
Step 8 end Exits global configuration mode and enters privileged EXEC
mode.
Example:
Device(config)# end
lists.
Example:

SUMMARY STEPS
1. enable
994
Configuration Examples for Creating an IP Access List and Applying It to a Physical Interface
3. interface type number

4. ip access-group {access-list-number | access-list-name} {in | out}
5. end
DETAILED STEPS

Device> enable

Example:
Step 3 interface type number Specifies an interface and enters interface configuration
mode.
Example:
Device(config)# interface TenGigabitEthernet4/1/0
Step 4 ip access-group {access-list-number | access-list-name} Applies the specified access list to the inbound interface.
{in | out}
• To filter source addresses, apply the access list to the
Example: inbound interface.
Device(config-if)# ip access-group acl1 in

EXEC mode.
Example:
Configuration Examples for Creating an IP Access List and

Applying It to a Physical Interface
Example: Filtering on Host Source Address
In the following example, the workstation belonging to user1 is allowed access to Ten Gigabit Ethernet
interface 4/1/0, and the workstation belonging to user2 is not allowed access:
ip access-group workstations in
!
ip access-list standard workstations
remark Permit only user1 workstation through
permit 172.16.2.88
remark Do not allow user2 workstation through
deny 172.16.3.13
995
Example: Filtering on Subnet Source Address
Example: Filtering on Subnet Source Address

In the following example, the user1 subnet is not allowed access to Ten Gigabit Ethernet interface 4/1/0, but
the Main subnet is allowed access:
ip access-group prevention in
!
ip access-list standard prevention
remark Do not allow user1 subnet through
deny 172.22.0.0 0.0.255.255
remark Allow Main subnet
permit 172.25.0.0 0.0.255.255
Example: Filtering on Source and Destination Addresses and IP Protocols

The following configuration example shows an interface with two access lists, one applied to outgoing packets
and one applied to incoming packets. The standard access list named Internet-filter filters outgoing packets
on source address. The only packets allowed out the interface must be from source 172.16.3.4.
The extended access list named marketing-group filters incoming packets. The access list permits Telnet
packets from any source to network 172.26.0.0 and denies all other TCP packets. It permits any ICMP packets.
It denies UDP packets from any source to network 172.26.0 0 on port numbers less than 1024. Finally, the
access list denies all other IP packets and performs logging of packets passed or denied by that entry.
ip address 172.20.5.1 255.255.255.0
ip access-group Internet-filter out
ip access-group marketing-group in
!
ip access-list standard Internet-filter
permit 172.16.3.4
ip access-list extended marketing-group
permit tcp any 172.26.0.0 0.0.255.255 eq telnet
deny tcp any any
permit icmp any any
deny udp any 172.26.0.0 0.0.255.255 lt 1024
deny ip any any
Example: Filtering on Source Addresses Using a Numbered Access List

In the following example, network 10.0.0.0 is a Class A network whose second octet specifies a subnet; that
is, its subnet mask is 255.255.0.0. The third and fourth octets of a network 10.0.0.0 address specify a particular
host. Using access list 2, the Cisco IOS-XE software would accept one address on subnet 48 and reject all
others on that subnet. The last line of the list shows that the software would accept addresses on all other
network 10.0.0.0 subnets.
ip access-group 2 in
!
access-list 2 permit 10.48.0.3
access-list 2 deny 10.48.0.0 0.0.255.255
access-list 2 permit 10.0.0.0 0.255.255.255
996
Example: Preventing Telnet Access to a Subnet
Example: Preventing Telnet Access to a Subnet

In the following example, the user1 subnet is not allowed to telnet out of Ten Gigabit Ethernet interface 4/1/0:
ip access-group telnetting out
!
remark Do not allow user1 subnet to telnet out
deny tcp 172.20.0.0 0.0.255.255 any eq telnet
remark Allow Top subnet to telnet out
permit tcp 172.33.0.0 0.0.255.255 any eq telnet
Example: Filtering on TCP and ICMP Using Port Numbers

In the following example, the first line of the extended access list named acl1 permits any incoming TCP
connections with destination ports greater than 1023. The second line permits incoming TCP connections to
the Simple Mail Transfer Protocol (SMTP) port of host 172.28.1.2. The last line permits incoming ICMP
messages for error feedback.
ip access-group acl1 in
!
ip access-list extended acl1
permit tcp any 172.28.0.0 0.0.255.255 gt 1023
permit tcp any host 172.28.1.2 eq 25
permit icmp any 172.28.0.0 255.255.255.255
Example: Allowing SMTP E-mail and Established TCP Connections

Suppose you have a network connected to the Internet, and you want any host on an Ethernet to be able to
form TCP connections to any host on the Internet. However, you do not want IP hosts to be able to form TCP
connections to hosts on the Ten Gigabit Ethernet except to the mail (SMTP) port of a dedicated mail host.
SMTP uses TCP port 25 on one end of the connection and a random port number on the other end. The same
two port numbers are used throughout the life of the connection. Mail packets coming in from the Internet
will have a destination port of 25. Outbound packets will have the port numbers reversed. The fact that the
secure system behind the router always will accept mail connections on port 25 is what makes possible separate
control of incoming and outgoing services. The access list can be configured on either the outbound or inbound
interface.
In the following example, the Ten Gigabit Ethernet network is a Class B network with the address 172.18.0.0,
and the address of the mail host is 172.18.1.2. The established keyword is used only for the TCP protocol to
indicate an established connection. A match occurs if the TCP datagram has the ACK or RST bits set, which
indicate that the packet belongs to an existing connection.
!
access-list 102 permit tcp any 172.18.0.0 0.0.255.255 established
access-list 102 permit tcp any host 172.18.1.2 eq 25
997
Example: Preventing Access to the Web by Filtering on Port Name
Example: Preventing Access to the Web by Filtering on Port Name

In the following example, the w1and w2 workstations are not allowed web access; other hosts on network
172.20.0.0 are allowed web access:
ip access-group no-web out
!
ip access-list extended no-web
remark Do not allow w1 to browse the web
deny host 172.20.3.85 any eq http
remark Do not allow w2 to browse the web
deny host 172.20.3.13 any eq http
remark Allow others on our network to browse the web
permit 172.20.0.0 0.0.255.255 any eq http
Example: Filtering on Source Address and Logging the Packets

The following example defines access lists 1 and 2, both of which have logging enabled:
ip address 172.16.1.1 255.0.0.0
ip access-group 2 out
!
access-list 1 permit 172.25.0.0 0.0.255.255 log
access-list 1 deny 172.30.0.0 0.0.255.255 log
!
access-list 2 permit 172.27.3.4 log
access-list 2 deny 172.17.0.0 0.0.255.255 log
If the interface receives 10 packets from 172.25.7.7 and 14 packets from 172.17.23.21, the first log will look
like the following:
list 1 permit 172.25.7.7 1 packet

list 2 deny 172.17.23.21 1 packet
Five minutes later, the console will receive the following log:
list 1 permit 172.25.7.7 9 packets

list 2 deny 172.17.23.21 13 packets
Example: Limiting Debug Output

The following sample configuration uses an access list to limit the debug command output. Limiting the
debug output restricts the volume of data to what you are interested in, saving you time and resources.
Device(config)# ip access-list acl1

Device(config-std-nacl)# remark Displays only advertisements for LDP peer in acl1
Device(config-std-nacl)# permit host 10.0.0.44
Device# debug mpls ldp advertisements peer-acl acl1
tagcon: peer 10.0.0.44:0 (pp 0x60E105BC): advertise 172.17.0.33

998
Additional References Creating an IP Access List and Applying It to an Interface

Additional References Creating an IP Access List and Applying

It to an Interface
Related Documents
Security commands • Cisco IOS Security Command Reference: Commands

A to C
• Cisco IOS Security Command Reference: Commands
D to L
M to R
S to Z
• Order of access list entries Refining an IP Access List

• Access list entries based on time of day or
week
• Packets with noninitial fragments
Filtering on IP options, TCP flags, or Creating an IP Access List for Filtering

noncontiguous ports
Controlling logging-related parameters Understanding Access Control List Loggingl
Standards and RFCs
Standard/RFC Title
No new or modified standards or RFCs are supported by this feature, and support for existing standards —
or RFCs has not been modified by this feature.
999
Feature Information Creating an IP Access List and Applying It to an Interface
Description Link

Feature Information Creating an IP Access List and Applying It

to an Interface
Table 172: Feature Information for Creating an IP Access List and Applying It to an Interface
1000
CHAPTER 68
Creating an IP Access List to Filter IP Options,
TCP Flags, Noncontiguous Ports
This module describes how to use an IP access list to filter IP packets that contain certain IP Options, TCP
flags, noncontiguous ports.
Contents
• Prerequisites for Creating an IP Access List to Filter IP Options TCP Flags Noncontiguous Ports , on
page 1003
• Information About Creating an IP Access List to Filter IP Options, TCP Flags, Noncontiguous Ports ,
on page 1003
• How to Create an IP Access List to Filter IP Options TCP Flags Noncontiguous Ports , on page 1006
• Configuration Examples for Filtering IP Options, TCP Flags, Noncontiguous Ports , on page 1017
• Feature Information for Creating an IP Access List to Filter IP Options, TCP Flags, Noncontiguous Ports,
or TTL Values, on page 1021
1001
Digital PICs:

Module:

Modules:
line card reload.
1002
Prerequisites for Creating an IP Access List to Filter IP Options TCP Flags Noncontiguous Ports
Prerequisites for Creating an IP Access List to Filter IP Options

TCP Flags Noncontiguous Ports
Before you perform any of the tasks in this module, you should be familiar with the information in the following
modules:
• “IP Access List Overview”
• “Creating an IP Access List and Applying It to an Interface”
Information About Creating an IP Access List to Filter IP Options,

TCP Flags, Noncontiguous Ports
IP Options
IP uses four key mechanisms in providing its service: Type of Service, Time to Live, Options, and Header
Checksum.
The Options, commonly referred to as IP Options, provide for control functions that are required in some
situations but unnecessary for the most common communications. IP Options include provisions for time
stamps, security, and special routing.
IP Options may or may not appear in datagrams. They must be implemented by all IP modules (host and
gateways). What is optional is their transmission in any particular datagram, not their implementation. In
some environments the security option may be required in all datagrams.
The option field is variable in length. There may be zero or more options. IP Options can have one of two
formats:
• Format 1: A single octet of option-type.
• Format 2: An option-type octet, an option-length octet, and the actual option-data octets.
The option-length octet counts the option-type octet, the option-length octet, and the option-data octets.
The option-type octet is viewed as having three fields: a 1-bit copied flag, a 2-bit option class, and a 5-bit
option number. These fields form an 8-bit value for the option type field. IP Options are commonly referred
to by their 8-bit value.
For a complete list and description of IP Options, refer to RFC 791, Internet Protocol at the following URL:
http://www.faqs.org/rfcs/rfc791.html
Benefits of Filtering IP Options

• Filtering of packets that contain IP Options from the network relieves downstream devices and hosts of
the load from options packets.
1003
Benefits of Filtering on TCP Flags
• This feature also minimizes load to the Route Processor (RP) for packets with IP Options that require
RP processing on distributed systems. Previously, the packets were always routed to or processed by the
RP CPU. Filtering the packets prevents them from impacting the RP.
Benefits of Filtering on TCP Flags

The ACL TCP Flags Filtering feature provides a flexible mechanism for filtering on TCP flags. Previously,
an incoming packet was matched as long as any TCP flag in the packet matched a flag specified in the access
control entry (ACE). This behavior allows for a security loophole, because packets with all flags set could
get past the access control list (ACL). The ACL TCP Flags Filtering feature allows you to select any
combination of flags on which to filter. The ability to match on a flag set and on a flag not set gives you a
greater degree of control for filtering on TCP flags, thus enhancing security.
Because TCP packets can be sent as false synchronization packets that can be accepted by a listening port, it
is recommended that administrators of firewall devices set up some filtering rules to drop false TCP packets.
The ACEs that make up an access list can be configured to detect and drop unauthorized TCP packets by
allowing only the packets that have a very specific group of TCP flags set or not set. The ACL TCP Flags
Filtering feature provides a greater degree of packet-filtering control in the following ways:
• You can select any desired combination of TCP flags on which to filter TCP packets.
• You can configure ACEs to allow matching on a flag that is set, as well as on a flag that is not set.
TCP Flags
The table below lists the TCP flags, which are further described in RFC 793, Transmission Control Protocol.
Table 174: TCP Flags
TCP Flag Purpose
ACK Acknowledge flag—Indicates that the acknowledgment field

of a segment specifies the next sequence number the sender
of this segment is expecting to receive.
FIN Finish flag—Used to clear connections.
PSH Push flag—Indicates the data in the call should be

immediately pushed through to the receiving user.
RST Reset flag—Indicates that the receiver should delete the

connection without further interaction.
SYN Synchronize flag—Used to establish connections.
URG Urgent flag—Indicates that the urgent field is meaningful

and must be added to the segment sequence number.
1004
Benefits of Using the Named ACL Support for Noncontiguous Ports on an Access Control Entry Feature
Benefits of Using the Named ACL Support for Noncontiguous Ports on an

Access Control Entry Feature
This feature greatly reduces the number of access control entries (ACEs) required in an access control list to
handle multiple entries for the same source address, destination address, and protocol. If you maintain large
numbers of ACEs, use this feature to consolidate existing groups of access list entries wherever it is possible
and when you create new access list entries. When you configure access list entries with noncontiguous ports,
you will have fewer access list entries to maintain.
How Filtering on TTL Value Works

IP extended named and numbered access lists may filter on the TTL value of packets arriving at or leaving
an interface. Packets with any possible TTL values 0 through 255 may be permitted or denied (filtered). Like
filtering on other fields, such as source or destination address, the ip access-group command specifies in or
out, which makes the access list ingress or egress and applies it to incoming or outgoing packets, respectively.
The TTL value is checked in conjunction with the specified protocol, application, and any other settings in
the access list entry, and all conditions must be met.
Special Handling for Packets with TTL Value of 0 or 1 Arriving at an Ingress Interface
The software switching paths—distributed Cisco Express Forwarding (dCEF), CEF, fast switching, and
process switching—will usually permit or discard the packets based on the access list statements. However,
when the TTL value of packets arriving at an ingress interface have a TTL of 0 or 1, special handling is
required. The packets with a TTL value of 0 or 1 get sent to the process level before the ingress access list is
checked in CEF, dCEF, or the fast switching paths. The ingress access list is applied to packets with TTL
values 2 through 255 and a permit or deny decision is made.
Packets with a TTL value of 0 or 1 are sent to the process level because they will never be forwarded out of
the device; the process level must check whether each packet is destined for the device and whether an Internet
Control Message Protocol (ICMP) TTL Expire message needs to be sent back. This means that even if an
ACL with TTL value 0 or 1 filtering is configured on the ingress interface with the intention to drop packets
with a TTL of 0 or 1, the dropping of the packets will not happen in the faster paths. It will instead happen in
the process level when the process applies the ACL. This is also true for hardware switching platforms. Packets
with TTL value of 0 or 1 are sent to the process level of the route processor (RP) or Multilayer Switch Feature
Card (MSFC).
On egress interfaces, access list filtering on TTL value works just like other access list features. The check
will happen in the fastest switching path enabled in the device. This is because the faster switching paths
handle all the TTL values (0 through 255) equally on the egress interface.
Control Plane Policing for Filtering TTL Values 0 and 1

The special behavior for packets with a TTL value of 0 or 1 results in higher CPU usage for the device. If you
are filtering on TTL value of 0 or 1, you should use control plane policing (CPP) to protect the CPU from
being overwhelmed. In order to leverage CPP, you must configure an access list especially for filtering TTL
values 0 and 1 and apply the access list through CPP. This access list will be a separate access list from any
other interface access lists. Because CPP works for the entire system, not just on individual interfaces, you
would need to configure only one such special access list for the entire device. This task is described in the
section "Enabling Control Plane Policing to Filter on TTL Values 0 and 1".
1005
Benefits of Filtering on TTL Value
Benefits of Filtering on TTL Value

• Filtering on time-to-live (TTL) value provides a way to control which packets are allowed to reach the
device or are prevented from reaching the device. By looking at your network layout, you can choose
whether to accept or deny packets from a certain device based on how many hops away it is. For example,
in a small network, you can deny packets from a location more than three hops away. Filtering on TTL
value allows you to validate if the traffic originated from a neighboring device. You can accept only
packets that reach you in one hop, for example, by accepting only packets with a TTL value of one less
than the initial TTL value of a particular protocol.
• Many control plane protocols communicate only with their neighbors, but receive packets from everyone.
By applying an access list that filters on TTL to receiving routers, you can block unwanted packets.
• The Cisco software sends all packets with a TTL value of 0 or 1 to the process level. The device must
then send an Internet Control Message Protocol (ICMP) TTL value expire message to the source. By
filtering packets that have a TTL value of 0 through 2, you can reduce the load on the process level.
How to Create an IP Access List to Filter IP Options TCP Flags

Noncontiguous Ports
Filtering Packets That Contain IP Options
Complete these steps to configure an access list to filter packets that contain IP options and to verify that the
access list has been configured correctly.
Note • The ACL Support for Filtering IP Options feature can be used only with named, extended ACLs.
• Resource Reservation Protocol (RSVP) Multiprotocol Label Switching Traffic Engineering (MPLS TE),
Internet Group Management Protocol Version 2 (IGMPV2), and other protocols that use IP options
packets may not function in drop or ignore mode if this feature is configured.
• On most Cisco devices, a packet with IP options is not switched in hardware, but requires control plane
software processing (primarily because there is a need to process the options and rewrite the IP header),
so all IP packets with IP options will be filtered and switched in software.
Step 1 enable
Example:
Device> enable


Example:
1006
Filtering Packets That Contain IP Options
Step 3 ip access-list extended access-list-name

Example:
Device(config)# ip access-list extended mylist1
Specifies the IP access list by name and enters named access list configuration mode.
Step 4 [sequence-number] deny protocol source source-wildcard destination destination-wildcard [option option-value]
[precedence precedence] [tos tos] [log] [time-range time-range-name] [fragments]
Example:
Device(config-ext-nacl)# deny ip any any option traceroute
(Optional) Specifies a deny statement in named IP access list mode.

• This access list happens to use a denystatement first, but a permit statement could appear first, depending on the
order of statements you need.
• Use the option keyword and option-value argument to filter packets that contain a particular IP Option.
• In this example, any packet that contains the traceroute IP option will be filtered out.
• Use the no sequence-number form of this command to delete an entry.
Step 5 [sequence-number] permit protocol source source-wildcard destination destination-wildcard [option option-value]
[precedence precedence] [tos tos] [log] [time-range time-range-name] [fragments]
Example:
Device(config-ext-nacl)# permit ip any any option security
Specifies a permit statement in named IP access list mode.

• In this example, any packet (not already filtered) that contains the security IP option will be permitted.
• Use the no sequence-number form of this command to delete an entry.
Step 6 Repeat Step 4 or Step 5 as necessary.

Allows you to revise the access list.
Step 7 end
Example:
(Optional) Exits named access list configuration mode and returns to privileged EXEC mode.
Step 8 show ip access-lists access-list-name

Example:
Device# show ip access-lists mylist1
(Optional) Displays the contents of the IP access list.
1007
What to Do Next
What to Do Next
Apply the access list to an interface or reference it from a command that accepts an access list.
Note To effectively eliminate all packets that contain IP Options, we recommend that you configure the global ip
options drop command.
Filtering Packets That Contain TCP Flags

This task configures an access list to filter packets that contain TCP flags and verifies that the access list has
been configured correctly.
Note • TCP flag filtering can be used only with named, extended ACLs.
• The ACL TCP Flags Filtering feature is supported only for Cisco ACLs.
• Previously, the following command-line interface (CLI) format could be used to configure a TCP
flag-checking mechanism:
permit tcp any any rst The following format that represents the same ACE can now be used: permit tcp
any any match-any +rst Both the CLI formats are accepted; however, if the new keywords match-all or
match-any are chosen, they must be followed by the new flags that are prefixed with “+” or “-”. It is advisable
to use only the old format or the new format in a single ACL. You cannot mix and match the old and new
CLI formats.
Caution If a device having ACEs with the new syntax format is reloaded with a previous version of the Cisco software
that does not support the ACL TCP Flags Filtering feature, the ACEs will not be applied, leading to possible
security loopholes.
Step 1 enable
Example:
Device> enable


Example:
1008
Filtering Packets That Contain TCP Flags
Example:
Device(config)# ip access-list extended kmd1
Step 4 [sequence-number] permit tcp source source-wildcard [operator [port]] destination destination-wildcard [operator
[port]] [established|{match-any | match-all} {+ | -} flag-name] [precedence precedence] [tos tos] [log] [time-range
Example:
Device(config-ext-nacl)# permit tcp any any match-any +rst
Specifies a permit statement in named IP access list mode.

• This access list happens to use a permitstatement first, but a deny statement could appear first, depending on the
• Use the TCP command syntax of the permitcommand.
• Any packet with the RST TCP header flag set will be matched and allowed to pass the named access list kmd1 in
Step 3.
Step 5 [sequence-number] deny tcp source source-wildcard [operator [port]] destination destination-wildcard [operator [port]]
[established|{match-any | match-all} {+ | -} flag-name] [precedence precedence] [tos tos] [log] [time-range
Example:
Device(config-ext-nacl)# deny tcp any any match-all -ack -fin
(Optional) Specifies a deny statement in named IP access list mode.

• This access list happens to use a permitstatement first, but a deny statement could appear first, depending on the
• Use the TCP command syntax of the denycommand.
• Any packet that does not have the ACK flag set, and also does not have the FIN flag set, will not be allowed to pass
the named access list kmd1 in Step 3.
• See the deny(IP) command for additional command syntax to permit upper-layer protocols (ICMP, IGMP, TCP,
and UDP).
Step 6 Repeat Step 4 or Step 5 as necessary, adding statements by sequence number where you planned. Use the no
sequence-numbercommand to delete an entry.
Step 7 end
Example:
(Optional) Exits the configuration mode and returns to privileged EXEC mode.
1009
Configuring an Access Control Entry with Noncontiguous Ports
Example:
Device# show ip access-lists kmd1

• Review the output to confirm that the access list includes the new entry.
Configuring an Access Control Entry with Noncontiguous Ports

Perform this task to create access list entries that use noncontiguous TCP or UDP port numbers. Although
this task uses TCP ports, you could use the UDP syntax of the permit and deny commands to filter
noncontiguous UDP ports.
Although this task uses a permit command first, use the permit and deny commands in the order that achieves
your filtering goals.
Note The ACL—Named ACL Support for Noncontiguous Ports on an Access Control Entry feature can be used
only with named, extended ACLs.
Step 1 enable
Example:
Device> enable


Example:

Example:
Device(config)# ip access-list extended acl-extd-1
Step 4 [sequence-number] permit tcp source source-wildcard [operator port [port]] destination destination-wildcard [operator
[port]] [established {match-any | match-all} {+ | -} flag-name] [precedence precedence] [tos tos] [log] [time-range
Example:
Device(config-ext-nacl)# permit tcp any eq telnet ftp any eq 450 679
Specifies a permit statement in named IP access list configuration mode.
1010
Consolidating Access List Entries with Noncontiguous Ports into One Access List Entry
• Operators include lt (less than), gt (greater than), eq (equal), neq (not equal), and range (inclusive range).
• If the operator is positioned after the source and source-wildcard arguments, it must match the source port. If the
operator is positioned after the destination and destination-wildcard arguments, it must match the destination port.
• The range operator requires two port numbers. You can configure up to 10 ports after the eq and neqoperators. All
other operators require one port number.
• To filter UDP ports, use the UDP syntax of this command.
Step 5 [sequence-number] deny tcp source source-wildcard [operator port [port]] destination destination-wildcard [operator
[port]] [established {match-any | match-all} {+ | -} flag-name] [precedence precedence] [tos tos] [log] [time-range
Example:
Device(config-ext-nacl)# deny tcp any neq 45 565 632 any
(Optional) Specifies a deny statement in named access list configuration mode.

• Operators include lt (less than), gt (greater than), eq (equal), neq (not equal), and range (inclusive range).
• If the operator is positioned after the source and source-wildcard arguments, it must match the source port. If the
operator is positioned after the destination and destination-wildcard arguments, it must match the destination port.
• The range operator requires two port numbers. You can configure up to 10 ports after the eq and neqoperators. All
other operators require one port number.
• To filter UDP ports, use the UDP syntax of this command.
Step 6 Repeat Step 4 or Step 5 as necessary, adding statements by sequence number where you planned. Use the no
sequence-number command to delete an entry.
Step 7 end
Example:

Example:
(Optional) Displays the contents of the access list.
Consolidating Access List Entries with Noncontiguous Ports into One Access
List Entry
Perform this task to consolidate a group of access list entries with noncontiguous ports into one access list
entry.
1011
Consolidating Access List Entries with Noncontiguous Ports into One Access List Entry
Although this task uses TCP ports, you could use the UDP syntax of the permit and deny commands to filter
noncontiguous UDP ports.
Although this task uses a permit command first, use the permit and deny commands in the order that achieves
your filtering goals.
Step 1 enable
Example:
Device> enable


Example:

• Review the output to see if you can consolidate any access list entries.

Example:

Example:
Device(config)# ip access-list extended mylist1
Step 5 no [sequence-number] permit protocol source source-wildcard destination destination-wildcard[option option-name]

[precedence precedence][tos tos] [log] [time-range time-range-name] [fragments]
Example:
Device(config-ext-nacl)# no 10
Removes the redundant access list entry that can be consolidated.

• Repeat this step to remove entries to be consolidated because only the port numbers differ.
• After this step is repeated to remove the access list entries 20, 30, and 40, for example, those entries are removed
because they will be consolidated into one permit statement.
• If a sequence-number is specified, the rest of the command syntax is optional.
Step 6 [sequence-number] permit protocol source source-wildcard[operator port[port]] destination destination-wildcard[operator

port[port]] [option option-name] [precedence precedence][tos tos] [log] [time-range time-range-name] [fragments]
Example:
1012
What To Do Next
Device(config-ext-nacl)# permit tcp any neq 45 565 632 any eq 23 45 34 43
Specifies a permit statement in named access list configuration mode.

• In this instance, a group of access list entries with noncontiguous ports was consolidated into one permit statement.
• You can configure up to 10 ports after the eq and neq operators.
Step 7 Repeat Steps 5 and 6 as necessary, adding permit or deny statements to consolidate access list entries where possible.
Use the no sequence-number command to delete an entry.
Step 8 end
Example:

Example:
(Optional) Displays the contents of the access list.
What To Do Next
Filtering Packets Based on TTL Value

Because access lists are very flexible, it is not possible to define only one combination of permit and deny
commands to filter packets based on the TTL value. This task illustrates just one example that achieves TTL
filtering. Configure the appropriate permit and deny statements that will accomplish your filtering plan.
Note When the access list specifies the operation EQ or NEQ, depending on the Cisco software release in use on
the device, the access lists can specify up to ten TTL values. The number of TTL values can vary by the Cisco
software release.
SUMMARY STEPS
1. enable
3. ip access-list extended access-list-name
4. [sequence-number] permit protocol source source-wildcard destination destination-wildcard[option
option-name] [precedence precedence] [tos tos] [ttl operator value] [log] [time-range time-range-name]
[fragments]
5. Continue to add permit or deny statements to achieve the filtering you want.
1013
Filtering Packets Based on TTL Value
6. exit
8. ip access-group access-list-name {in | out}
DETAILED STEPS

Device> enable

Example:
Step 3 ip access-list extended access-list-name Defines an IP access list by name.

Example: • An access list that filters on TTL value must be an
extended access list.
Device(config)# ip access-list extended ttlfilter
Step 4 [sequence-number] permit protocol source source-wildcard Sets conditions to allow a packet to pass a named IP access
destination destination-wildcard[option option-name] list.
[precedence precedence] [tos tos] [ttl operator value] [log]
• Every access list must have at least one permit
statement.
Example:
• This example permits packets from source 172.16.1.1
Device(config-ext-nacl)# permit ip host 172.16.1.1
to any destination with a TTL value less than 2.
any ttl lt 2
Step 5 Continue to add permit or deny statements to achieve the --

filtering you want.
Step 6 exit Exits any configuration mode to the next highest mode in
the command-line interface (CLI) mode hierarchy.
Example:
Device(config-ext-nacl)# exit
Step 7 interface type number Configures an interface type and enters interface
configuration mode.
Example:
Step 8 ip access-group access-list-name {in | out} Applies the access list to an interface.
Example:
Device(config-if)# ip access-group ttlfilter in
1014
Enabling Control Plane Policing to Filter on TTL Values 0 and 1

Perform this task to filter IP packets based on a TTL value of 0 or 1 and to protect the CPU from being
overwhelmed. This task configures an access list for classification on TTL value 0 and 1, configures the
Modular QoS Command-Line Interface (CLI) (MQC), and applies a policy map to the control plane. Any
packets that pass the access list are dropped. This special access list is separate from any other interface access
lists.
Because access lists are very flexible, it is not possible to define only one combination of permit and deny
commands to filter packets based on the TTL value. This task illustrates just one example that achieves TTL
filtering. Configure the appropriate permit and deny statements that will accomplish your filtering plan.
SUMMARY STEPS
1. enable
3. ip access-list extended access-list-name
4. [sequence-number] permit protocol source source-wildcard destination destination-wildcard ttl operator
value
5. Continue to add permit or deny statements to achieve the filtering you want.
6. exit
7. class-map class-map-name [match-all | match-any]
8. match access-group {access-group | name access-group-name}
9. exit
10. policy-map policy-map-name
11. class {class-name | class-default}
12. drop
13. exit
14. exit
15. control-plane
16. service-policy {input | output} policy-map-name
DETAILED STEPS

Device> enable

Example:
Step 3 ip access-list extended access-list-name Defines an IP access list by name.

Example: • An access list that filters on a TTL value must be an
extended access list.
1015
Device(config)# ip access-list extended ttlfilter
Step 4 [sequence-number] permit protocol source Sets conditions to allow a packet to pass a named IP access
source-wildcard destination destination-wildcard ttl list.
operator value
• Every access list must have at least one permit
Example: statement.
Device(config-ext-nacl)# permit ip host 172.16.1.1

• This example permits packets from source 172.16.1.1
any ttl lt 2 to any destination with a TTL value less than 2.
Step 5 Continue to add permit or deny statements to achieve the The packets that pass the access list will be dropped.
filtering you want.
the CLI mode hierarchy.
Example:
Device(config-ext-nacl)# exit
Step 7 class-map class-map-name [match-all | match-any] Creates a class map to be used for matching packets to a
specified class.
Example:
Device(config)# class-map acl-filtering
Step 8 match access-group {access-group | name Configures the match criteria for a class map on the basis
access-group-name} of the specified access control list.
Example:
Device(config-cmap)# match access-group name

ttlfilter
Example:
Device(config-cmap)# exit
Step 10 policy-map policy-map-name Creates or modifies a policy map that can be attached to
one or more interface to specify a service policy.
Example:
Device(config)# policy-map acl-filter
Step 11 class {class-name | class-default} Specifies the name of the class whose policy you want to
create or change or to specify the default class (commonly
Example:
known as the class-default class) before you configure its
policy.
Device(config-pmap)# class acl-filter-class
Step 12 drop Configures a traffic class to discard packets belonging to

a specific class.
Example:
1016
Configuration Examples for Filtering IP Options, TCP Flags, Noncontiguous Ports
Device(config-pmap-c)# drop
Example:
Device(config-pmap-c)# exit
Example:
Device(config-pmap)# exit
Step 15 control-plane Associates or modifies attributes or parameters that are

associated with the control plane of the device.
Example:
Device(config)# control-plane
Step 16 service-policy {input | output} policy-map-name Attaches a policy map to a control plane for aggregate
control plane services.
Example:
Device(config-cp)# service-policy input acl-filter
Configuration Examples for Filtering IP Options, TCP Flags,

Noncontiguous Ports
Example: Filtering Packets That Contain IP Options
The following example shows an extended access list named mylist2 that contains access list entries (ACEs)
that are configured to permit TCP packets only if they contain the IP Options that are specified in the ACEs:
ip access-list extended mylist2

10 permit ip any any option eool
20 permit ip any any option record-route
30 permit ip any any option zsu
40 permit ip any any option mtup
The show access-list command has been entered to show how many packets were matched and therefore
permitted:
Device# show ip access-list mylist2

Extended IP access list test
10 permit ip any any option eool (1 match)
20 permit ip any any option record-route (1 match)
30 permit ip any any option zsu (1 match)
40 permit ip any any option mtup (1 match)
1017
Example: Filtering Packets That Contain TCP Flags
Example: Filtering Packets That Contain TCP Flags

The following access list allows TCP packets only if the TCP flags ACK and SYN are set and the FIN flag
is not set:
ip access-list extended aaa

permit tcp any any match-all +ack +syn -fin
end
The show access-list command has been entered to display the ACL:
Device# show access-list aaa
Extended IP access list aaa

10 permit tcp any any match-all +ack +syn -fin
Example: Creating an Access List Entry with Noncontiguous Ports

The following access list entry can be created because up to ten ports can be entered after the eq and neq
operators:
ip access-list extended aaa

permit tcp any eq telnet ftp any eq 23 45 34
end
Enter the show access-lists command to display the newly created access list entry.
Device# show access-lists aaa
Extended IP access list aaa

10 permit tcp any eq telnet ftp any eq 23 45 34
Example: Consolidating Some Existing Access List Entries into One Access
List Entry with Noncontiguous Ports
The show access-lists command is used to display a group of access list entries for the access list named abc:
Device# show access-lists abc

Extended IP access list abc
10 permit tcp any eq telnet any eq 450
20 permit tcp any eq telnet any eq 679
30 permit tcp any eq ftp any eq 450
40 permit tcp any eq ftp any eq 679
Because the entries are all for the same permit statement and simply show different ports, they can be
consolidated into one new access list entry. The following example shows the removal of the redundant access
list entries and the creation of a new access list entry that consolidates the previously displayed group of access
list entries:
ip access-list extended abc

no 10
no 20
no 30
no 40
1018
Example: Filtering on TTL Value
permit tcp any eq telnet ftp any eq 450 679

end
When the show access-lists command is reentered, the consolidated access list entry is displayed:
Device# show access-lists abc

Extended IP access list abc
10 permit tcp any eq telnet ftp any eq 450 679
Example: Filtering on TTL Value

The following access list filters IP packets containing type of service (ToS) level 3 with time-to-live (TTL)
values 10 and 20. It also filters IP packets with a TTL greater than 154 and applies that rule to noninitial
fragments. It permits IP packets with a precedence level of flash and a TTL value not equal to 1, and it sends
log messages about such packets to the console. All other packets are denied.
ip access-list extended incomingfilter

deny ip any any tos 3 ttl eq 10 20
deny ip any any ttl gt 154 fragments
permit ip any any precedence flash ttl neq 1 log
!
ip access-group incomingfilter in
Example: Control Plane Policing to Filter on TTL Values 0 and 1

The following example configures a traffic class called acl-filter-class for use in a policy map called acl-filter.
An access list permits IP packets from any source having a time-to-live (TTL) value of 0 or 1. Any packets
matching the access list are dropped. The policy map is attached to the control plane.
ip access-list extended ttlfilter
permit ip any any ttl eq 0 1
class-map acl-filter-class
match access-group name ttlfilter
policy-map acl-filter
class acl-filter-class
drop
control-plane
service-policy input acl-filter
1019
Related Documents
Security commands Cisco IOS Security Command

Reference
Configuring the device to drop or ignore packets containing IP ACL IP Options Selective Drop
Options by using the no ip options command.
Overview information about access lists. IP Access List Overview
Information about creating an IP access list and applying it to an Creating an IP Access List and
interface Applying It to an Interface
QoS commands Cisco IOS Quality of Service Solutions

Command Reference
RFCs
RFC Title
RFC 791 Internet Protocol

http://www.faqs.org/rfcs/rfc791.html
RFC 793 Transmission Control Protocol
RFC 1393 Traceroute Using an IP Option
Description Link

1020
Feature Information for Creating an IP Access List to Filter IP Options, TCP Flags, Noncontiguous Ports, or TTL Values
Feature Information for Creating an IP Access List to Filter IP

Options, TCP Flags, Noncontiguous Ports, or TTL Values
Table 175: Feature Information for Creating an IP Access List to Filter IP Options, TCP Flags, Noncontiguous Ports, or TTL Values
IP access lists Cisco IOS XE Fuji This feature was integrated into Cisco IOS XE Fuji 16.7.1 on the
16.7.1 Cisco cBR Series Converged Broadband Routers.
1021
Feature Information for Creating an IP Access List to Filter IP Options, TCP Flags, Noncontiguous Ports, or TTL Values
1022
CHAPTER 69
Refining an IP Access List
There are several ways to refine an access list while or after you create it. You can change the order of the
entries in an access list or add entries to an access list. You can restrict access list entries to a certain time of
day or week, or achieve finer granularity when filtering packets by filtering noninitial fragments of packets.
Contents
• Information About Refining an IP Access List, on page 1025
• How to Refine an IP Access List, on page 1028
• Configuration Examples for Refining an IP Access List, on page 1033
• Feature Information for Refining an IP Access List, on page 1036
1023
Digital PICs:

Module:

Modules:
line card reload.
1024
Information About Refining an IP Access List
Information About Refining an IP Access List

an access list. If you wanted to insert an entry in the middle of an existing list, all of the entries after the desired
position had to be removed, then the new entry was added, and then all the removed entries had to be reentered.
This method was cumbersome and error prone.
Sequence numbers allow users to add access list entries and resequence them. When you add a new entry,
you specify the sequence number so that it is in a desired position in the access list. If necessary, entries
currently in the access list can be resequenced to create room to insert the new entry.
Benefits of Access List Sequence Numbers

An access list sequence number is a number at the beginning of a permit or deny command in an access list.
The sequence number determines the order that the entry appears in the access list. The ability to apply
sequence numbers to IP access list entries simplifies access list changes.
Prior to having sequence numbers, users could only add access list entries to the end of an access list; therefore,
needing to add statements anywhere except the end of the list required reconfiguring the entire access list.
There was no way to specify the position of an entry within an access list. If a user wanted to insert an entry
(statement) in the middle of an existing list, all of the entries after the desired position had to be removed,
then the new entry was added, and then all the removed entries had to be reentered. This method was
cumbersome and error prone.
This feature allows users to add sequence numbers to access list entries and resequence them. When a user
adds a new entry, the user chooses the sequence number so that it is in a desired position in the access list. If
necessary, entries currently in the access list can be resequenced to create room to insert the new entry.
Sequence numbers make revising an access list much easier.
Sequence Numbering Behavior

• For backward compatibility with previous releases, if entries with no sequence numbers are applied, the
first entry is assigned a sequence number of 10, and successive entries are incremented by 10. The
maximum sequence number is 2147483647. If the generated sequence number exceeds this maximum
number, the following message is displayed:
Exceeded maximum sequence number.
• If the user enters an entry without a sequence number, it is assigned a sequence number that is 10 greater
than the last sequence number in that access list and is placed at the end of the list.
• If the user enters an entry that matches an already existing entry (except for the sequence number), then
no changes are made.
• If the user enters a sequence number that is already present, the following error message is generated:
1025
Benefits of Time Ranges
Duplicate sequence number.
• If a new access list is entered from global configuration mode, then sequence numbers for that access
list are generated automatically.
• Sequence numbers are not nvgened. That is, the sequence numbers themselves are not saved. In the event
that the system is reloaded, the configured sequence numbers revert to the default sequence starting
number and increment. The function is provided for backward compatibility with software releases that
do not support sequence numbering.
• This feature works with named and numbered, standard and extended IP access lists.
Benefits of Time Ranges

Benefits and possible uses of time ranges include the following:
• The network administrator has more control over permitting or denying a user access to resources. These
resources could be an application (identified by an IP address/mask pair and a port number), policy
routing, or an on-demand link (identified as interesting traffic to the dialer).
• Network administrators can set time-based security policy, including the following:
• Perimeter security using access lists
• Data confidentiality with IP Security Protocol (IPsec)
• When provider access rates vary by time of day, it is possible to automatically reroute traffic cost
effectively.
• Network administrators can control logging messages. Access list entries can log traffic at certain times
of the day, but not constantly. Therefore, administrators can simply deny access without needing to
analyze many logs generated during peak hours.
Benefits Filtering Noninitial Fragments of Packets

Filter noninitial fragments of packets with an extended access list if you want to block more of the traffic you
intended to block, not just the initial fragment of such packets. You should first understand the following
concepts.
If the fragmentskeyword is used in additional IP access list entries that deny fragments, the fragment control
feature provides the following benefits:
Additional Security
You are able to block more of the traffic you intended to block, not just the initial fragment of such packets.
The unwanted fragments no longer linger at the receiver until the reassembly timeout is reached because they
are blocked before being sent to the receiver. Blocking a greater portion of unwanted traffic improves security
and reduces the risk from potential hackers.
Reduced Cost
By blocking unwanted noninitial fragments of packets, you are not paying for traffic you intended to block.
1026
Access List Processing of Fragments
Reduced Storage
By blocking unwanted noninitial fragments of packets from ever reaching the receiver, that destination does
not have to store the fragments until the reassembly timeout period is reached.
Expected Behavior Is Achieved

The noninitial fragments will be handled in the same way as the initial fragment, which is what you would
expect. There are fewer unexpected policy routing results and fewer fragments of packets being routed when
they should not be.
Access List Processing of Fragments

The behavior of access list entries regarding the use or lack of use of the fragments keyword can be summarized
as follows:
If the Access-List Entry Has... Then...
...no fragments keyword (the For an access list entry that contains only Layer 3 information:
default), and assuming all of the
• The entry is applied to nonfragmented packets, initial fragments, and
access-list entry information
noninitial fragments.
matches,
For an access list entry that contains Layer 3 and Layer 4 information:
• The entry is applied to nonfragmented packets and initial fragments.
• If the entry is a permit statement, then the packet or fragment is
permitted.
• If the entry is a deny statement, then the packet or fragment is
denied.
• The entry is also applied to noninitial fragments in the following
manner. Because noninitial fragments contain only Layer 3
information, only the Layer 3 portion of an access list entry can be
applied. If the Layer 3 portion of the access list entry matches, and
• If the entry is a permit statement, then the noninitial fragment
is permitted.
• If the entry is a deny statement, then the next access list entry is
processed.
Note The deny statements are handled differently for noninitial

fragments versus nonfragmented or initial fragments.
...the fragments keyword, and The access list entry is applied only to noninitial fragments.
assuming all of the access-list
The fragments keyword cannot be configured for an access list entry that
entry information matches,
contains any Layer 4 information.
Be aware that you should not add the fragments keyword to every access list entry because the first fragment
of the IP packet is considered a nonfragment and is treated independently of the subsequent fragments. An
initial fragment will not match an access list permit or deny entry that contains the fragments keyword. The
packet is compared to the next access list entry, and so on, until it is either permitted or denied by an access
1027
How to Refine an IP Access List
list entry that does not contain the fragments keyword. Therefore, you may need two access list entries for
every deny entry. The first deny entry of the pair will not include the fragments keyword and applies to the
initial fragment. The second deny entry of the pair will include the fragments keyword and applies to the
subsequent fragments. In the cases in which there are multiple deny entries for the same host but with different
Layer 4 ports, a single deny access list entry with the fragments keyword for that host is all that needs to be
added. Thus all the fragments of a packet are handled in the same manner by the access list.
Packet fragments of IP datagrams are considered individual packets, and each counts individually as a packet
in access list accounting and access list violation counts.
How to Refine an IP Access List

The tasks in this module provide you with various ways to refine an access list if you did not already do so
while you were creating it. You can change the order of the entries in an access list, add entries to an access
list, restrict access list entries to a certain time of day or week, or achieve finer granularity when filtering
packets by filtering on noninitial fragments of packets.
Revising an Access List Using Sequence Numbers

Perform this task if you want to add entries to an existing access list, change the order of entries, or simply
number the entries in an access list to accommodate future changes.
Note Remember that if you want to delete an entry from an access list, you can simply use the no deny or no permit
form of the command, or the no sequence-number command if the statement already has a sequence number.
Note • Access list sequence numbers do not support dynamic, reflexive, or firewall access lists.
SUMMARY STEPS
1. enable
3. ip access-list resequence access-list-name starting-sequence-number increment
4. ip access-list {standard| extended} access-list-name
5. Do one of the following:
• sequence-number permit source source-wildcard
• sequence-number permit protocol source source-wildcard destination destination-wildcard
• sequence-number deny source source-wildcard
• sequence-number deny protocol source source-wildcard destination destination-wildcard
1028
7. Repeat Step 5 and Step 6 as necessary, adding statements by sequence number where you planned. Use
the no sequence-number command to delete an entry.
8. end
9. show ip access-lists access-list-name
DETAILED STEPS

Router> enable

Example:
Step 3 ip access-list resequence access-list-name Resequences the specified IP access list using the starting
starting-sequence-number increment sequence number and the increment of sequence numbers.
Example: • This example resequences an access list named kmd1.
The starting sequence number is 100 and the increment
Router(config)# ip access-list resequence kmd1 100 is 15.
15
Step 4 ip access-list {standard| extended} access-list-name Specifies the IP access list by name and enters named access
list configuration mode.
Example:
• If you specify standard, make sure you specify
Router(config)# ip access-list standard xyz123 subsequent permit and deny statements using the
standard access list syntax.
• If you specify extended, make sure you specify
subsequent permit and deny statements using the
extended access list syntax.
Step 5 Do one of the following: Specifies a permit statement in named IP access list mode.
• sequence-number permit source source-wildcard • This access list happens to use a permitstatement first,
• sequence-number permit protocol source but a deny statement could appear first, depending on
source-wildcard destination destination-wildcard the order of statements you need.
[precedence precedence][tos tos] [log] [time-range
• See the permit (IP) command for additional command
syntax to permit upper layer protocols (ICMP, IGMP,
Example: TCP, and UDP).
Router(config-std-nacl)# 105 permit 10.5.5.5

• Use the no sequence-number command to delete an
0.0.0.255 entry.
• As the prompt indicates, this access list was a standard
access list. If you had specified extended in Step 4,
the prompt for this step would be
1029

Router(config-ext-nacl)# and you would use the
extended permit command syntax.
Step 6 Do one of the following: (Optional) Specifies a deny statement in named IP access
list mode.
• sequence-number deny protocol source • This access list happens to use a permitstatement first,
source-wildcard destination destination-wildcard but a deny statement could appear first, depending on
[precedence precedence][tos tos] [log] [time-range the order of statements you need.
• See the deny (IP) command for additional command
Example: syntax to permit upper layer protocols (ICMP, IGMP,
TCP, and UDP).
Router(config-std-nacl)# 110 deny 10.6.6.7
0.0.0.255 • Use the no sequence-number command to delete an
entry.
Router(config-ext-nacl)# and you would use the
extended deny command syntax.
Step 7 Repeat Step 5 and Step 6 as necessary, adding statements Allows you to revise the access list.
by sequence number where you planned. Use the no
sequence-number command to delete an entry.
Step 8 end (Optional) Exits the configuration mode and returns to
Example:
Router(config-std-nacl)# end
Step 9 show ip access-lists access-list-name (Optional) Displays the contents of the IP access list.
Example: • Review the output to see that the access list includes
the new entry.
Router# show ip access-lists xyz123
Examples
The following is sample output from the show ip access-lists command when the xyz123 access list
is specified.
Router# show ip access-lists xyz123

Standard IP access list xyz123
100 permit 10.4.4.0, wildcard bits 0.0.0.255
1030
Restricting an Access List Entry to a Time of Day or Week
Restricting an Access List Entry to a Time of Day or Week

By default, access list statements are always in effect once they are applied. However, you can define the
times of the day or week that permit or deny statements are in effect by defining a time range, and then
referencing the time range by name in an individual access list statement. IP and Internetwork Packet Exchange
(IPX) named or numbered extended access lists can use time ranges.
SUMMARY STEPS
1. enable
4. [sequence-number] deny protocol source[source-wildcard] [operator port[port]]
destination[destination-wildcard] [operator port[port]]
5. [sequence-number] deny protocol source[source-wildcard][operator port[port]]
destination[destination-wildcard] [operator port[port]] fragments
6. [sequence-number] permit protocol source[source-wildcard] [operator port[port]]
7. Repeat some combination of Steps 4 through 6 until you have specified the values on which you want to
base your access list.
8. end
DETAILED STEPS

Router> enable

Example:
Example:
Router(config)# ip access-list extended rstrct4
Step 4 [sequence-number] deny protocol source[source-wildcard] (Optional) Denies any packet that matches all of the
[operator port[port]] destination[destination-wildcard] conditions specified in the statement.
[operator port[port]]
• This statement will apply to nonfragmented packets
Example: and initial fragments.
Router(config-ext-nacl)# deny ip any 172.20.1.1
1031
What to Do Next

Step 5 [sequence-number] deny protocol (Optional) Denies any packet that matches all of the
source[source-wildcard][operator port[port]] conditions specified in the statement
• This statement will apply to noninitial fragments.
fragments
Example:
Router(config-ext-nacl)# deny ip any 172.20.1.1

fragments
Step 6 [sequence-number] permit protocol Permits any packet that matches all of the conditions
source[source-wildcard] [operator port[port]] specified in the statement.
• Every access list needs at least one permit statement.
Example:
• If the source-wildcard or
Router(config-ext-nacl)# permit tcp any any
destination-wildcardisomitted, a wildcard mask of
0.0.0.0 is assumed, meaning match on all bits of the
source or destination address, respectively.
source source-wildcardor destination
destination-wildcardto specify the address and
wildcard of 0.0.0.0 255.255.255.255.
have specified the values on which you want to base your denied by an implicit deny statement at the end of the access
access list. list.
Step 8 end Ends configuration mode and returns the system to

Example:
Router(config-ext-nacl)# end
lists.
Example:
Router# show ip access-list
What to Do Next
Note To effectively eliminate all packets that contain IP Options, we recommend that you configure the global ip
options drop command.
1032
Configuration Examples for Refining an IP Access List
Configuration Examples for Refining an IP Access List

Example Resequencing Entries in an Access List
The following example shows an access list before and after resequencing. The starting value is 1, and increment
value is 2. The subsequent entries are ordered based on the increment values that users provide, and the range
is from 1 to 2147483647.
When an entry with no sequence number is entered, by default it has a sequence number of 10 more than the
last entry in the access list.
Router# show access-list carls

Extended IP access list carls
10 permit ip host 10.3.3.3 host 172.16.5.34
20 permit icmp any any
30 permit tcp any host 10.3.3.3
40 permit ip host 10.4.4.4 any
50 Dynamic test permit ip any any
70 permit ip host 10.3.3.3 any log
80 permit tcp host 10.3.3.3 host 10.1.2.2
100 permit ip any any
Router(config)# ip access-list extended carls
Router(config)# ip access-list resequence carls 1 2
Router(config)# end
Router# show access-list carls
Extended IP access list carls
Example Adding an Entry with a Sequence Number

In the following example, an new entry (sequence number 15) is added to an access list:

Standard IP access list tryon
Router(config)# ip access-list standard tryon
Router(config-std-nacl)# 15 permit 10.5.5.5 0.0.0.255
1033
Example Adding an Entry with No Sequence Number

Example Adding an Entry with No Sequence Number

The following example shows how an entry with no specified sequence number is added to the end of an
access list. When an entry is added without a sequence number, it is automatically given a sequence number
that puts it at the end of the access list. Because the default increment is 10, the entry will have a sequence
number 10 higher than the last entry in the existing access list.
Router(config)# ip access-list standard resources

Router(config-std-nacl)# permit 10.1.1.1 0.0.0.255
Router# show access-list
Standard IP access list resources
Router(config)# ip access-list standard resources
Router(config-std-nacl)# end
Router# show access-list
Standard IP access list resources
Example Time Ranges Applied to IP Access List Entries

The following example creates a time range called no-http, which extends from Monday to Friday from 8:00
a.m. to 6:00 p.m. That time range is applied to the deny statement, thereby denying HTTP traffic on Monday
through Friday from 8:00 a.m. to 6:00 p.m.
The time range called udp-yes defines weekends from noon to 8:00 p.m. That time range is applied to the
permit statement, thereby allowing UDP traffic on Saturday and Sunday from noon to 8:00 p.m. only. The
access list containing both statements is applied to inbound packets on Ten Gigabit Ethernet interface 4/1/0.
time-range no-http
periodic weekdays 8:00 to 18:00
!
time-range udp-yes
periodic weekend 12:00 to 20:00
!
ip access-list extended strict
deny tcp any any eq http time-range no-http
permit udp any any time-range udp-yes
!
ip access-group strict in
Example Filtering IP Packet Fragments

In the following access list, the first statement will deny only noninitial fragments destined for host 172.16.1.1.
The second statement will permit only the remaining nonfragmented and initial fragments that are destined
1034
for host 172.16.1.1 TCP port 80. The third statement will deny all other traffic. In order to block noninitial
fragments for any TCP port, we must block noninitial fragments for all TCP ports, including port 80 for host
172.16.1.1. That is, non-initial fragments will not contain Layer 4 port information, so, in order to block such
traffic for a given port, we have to block fragments for all ports.
access-list 101 deny ip any host 172.16.1.1 fragments

access-list 101 permit tcp any host 172.16.1.1 eq 80
access-list 101 deny ip any any
Related Documents
Using the time-range command to establish The chapter Performing Basic System Management in the
time ranges Cisco IOS XE Network Management Configuration Guide
Network management command descriptions Cisco IOS Network Management Command Reference
Standards
Standard Title
No new or modified standards are supported by this feature, and support for existing standards has not --
been modified by this feature.
MIBs
MIB MIBs Link
No new or modified MIBs are supported by this To locate and download MIBs for selected platforms, Cisco
feature, and support for existing MIBs has not IOS XE software releases, and feature sets, use Cisco MIB
been modified by this feature. Locator found at the following URL:
RFCs
RFC Title
No new or modified RFCs are supported by this feature, and support for existing RFCs has not been --
modified by this feature.
1035
Feature Information for Refining an IP Access List
Description Link

Feature Information for Refining an IP Access List

Table 177: Feature Information for Refining an IP Access List
1036
CHAPTER 70
IP Named Access Control Lists
The IP Named Access Control Lists feature gives network administrators the option of using names to identify
their access lists.
This module describes IP named access lists and how to configure them.
Contents
• Information About IP Named Access Control Lists, on page 1039
• How to Configure IP Named Access Control Lists, on page 1043
• Additional References for IP Named Access Control Lists, on page 1045
• Feature Information for IP Named Access Control Lists, on page 1046
1037
Digital PICs:

Module:

Modules:
line card reload.
1038
Information About IP Named Access Control Lists
Information About IP Named Access Control Lists

IP access lists can also be used for purposes other than security, such as to control bandwidth, restrict the
content of routing updates, redistribute routes, trigger dial-on-demand (DDR) calls, limit debug output, and
identify or classify traffic for quality of service (QoS) features.
An access list is a sequential list that consists of at least one permit statement and possibly one or more deny
statements. In the case of IP access lists, these statements can apply to IP addresses, upper-layer IP protocols,
or other fields in IP packets.
Access lists are identified and referenced by a name or a number. Access lists act as packet filters, filtering
packets based on the criteria defined in each access list.
After you configure an access list, for the access list to take effect, you must either apply the access list to an
interface (by using the ip access-group command), a vty (by using the access-class command), or reference
the access list by any command that accepts an access list. Multiple commands can reference the same access
list.
In the following configuration, an IP access list named branchoffices is configured on Ten Gigabit Ethernet
interface 4/1/0 and applied to incoming packets. Networks other than the ones specified by the source address
and mask pair cannot access Ten Gigabit Ethernet interface 4/1/0. The destinations for packets coming from
sources on network 172.16.7.0 are unrestricted. The destination for packets coming from sources on network
172.16.2.0 must be 172.31.5.4.
ip access-list extended branchoffices

10 permit 172.16.7.0 0.0.0.3 any
20 permit 172.16.2.0 0.0.0.255 host 172.31.5.4
!
ip access-group branchoffices in

All access lists must be identified by a name or a number. Named access lists are more convenient than
numbered access lists because you can specify a meaningful name that is easier to remember and associate
with a task. You can reorder statements in or add statements to a named access list.
Named access lists support the following features that are not supported by numbered access lists:
• IP options filtering
• Noncontiguous ports
• TCP flag filtering
• Deleting of entries with the no permit or no deny command
1039
Note Not all commands that accept a numbered access list will accept a named access list. For example, vty uses
only numbered access lists.

reach.
Translation (NAT).
Access List Rules

The following rules apply to access lists:
• Only one access list per interface, per protocol, and per direction is allowed.
1040
• An access list must contain at least one permit statement or all packets are denied entry into the network.
• The order in which access list conditions or match criteria are configured is important. While deciding
whether to forward or block a packet, Cisco software tests the packet against each criteria statement in
the order in which these statements are created. After a match is found, no more criteria statements are
checked. The same permit or deny statements specified in a different order can result in a packet being
passed under one circumstance and denied in another circumstance.
• If an access list is referenced by a name, but the access list does not exist, all packets pass. An interface
or command with an empty access list applied to it permits all traffic into the network.
• Standard access lists and extended access lists cannot have the same name.
• Inbound access lists process packets before the packets are routed to an outbound interface. Inbound
access lists that have filtering criteria that deny packet access to a network saves the overhead of routing
lookup. Packets that are permitted access to a network based on the configured filtering criteria are
processed for routing. For inbound access lists, when you configure a permit statement, packets are
processed after they are received, and when you configure a deny statement, packets are discarded.
outbound interface and then processed by the outbound access list. For outbound access lists, when you
configure a permit statement, packets are sent to the output buffer, and when you configure a deny
statement, packets are discarded.
• An access list can control traffic arriving at a device or leaving a device, but not traffic originating at a
device.

access lists.
• Because the software stops testing conditions after it encounters the first match (to either a permit or
deny statement), you will reduce processing time and resources if you put the statements that packets
are most likely to match at the beginning of the access list. Place more frequently occurring conditions
before less frequent conditions.
general ones.
1041
denied by issuing the show access-listcommand, thus finding out more information about who your
• You can delete an entry from a named access list. Use the no permitor no deny command to delete
• Before you add new ACL statements, provide time to the parser to clean up the deletion.

You can apply access lists to the inbound or outbound interfaces of a device. Applying an access list to an
inbound interface controls the traffic that enters the interface and applying an access list to an outbound
interface controls the traffic that exits the interface.
When software receives a packet at the inbound interface, the software checks the packet against the statements
that are configured for the access list. If the access list permits packets, the software processes the packet.
Applying access lists to filter incoming packets can save device resources because filtered packets are discarded
before entering the device.
Access lists on outbound interfaces filter packets that are transmitted (sent) out of the interface. You can use
the TCP Access Control List (ACL) Splitting feature of the Rate-Based Satellite Control Protocol (RBSCP)
on the outbound interface to control the type of packets that are subject to TCP acknowledgment (ACK)
splitting on an outbound interface.
You can reference an access list by using a debug command to limit the amount of debug logs. For example,
based on the filtering or matching criteria of the access list, debug logs can be limited to source or destination
addresses or protocols.
You can use access lists to control routing updates, dial-on-demand (DDR), and quality of service (QoS)
features.
1042
How to Configure IP Named Access Control Lists
How to Configure IP Named Access Control Lists

Creating an IP Named Access List
You can create an IP named access list to filter source addresses and destination addresses or a combination
of addresses and other IP fields. Named access lists allow you to identify your access lists with an intuitive
name.
SUMMARY STEPS
1. enable
4. remark remark
5. deny protocol [source source-wildcard] {any | host {address | name} {destination [destination-wildcard]
{any | host {address | name} [log]
6. remark remark
7. permit protocol [source source-wildcard] {any | host {address | name} {destination
[destination-wildcard] {any | host {address | name} [log]
8. Repeat Steps 4 through 7 to specify more statements for your access list.
9. end
10. show ip access-lists
DETAILED STEPS

Device> enable

Example:
Example:
Device(config)# ip access-list extended acl1
Step 4 remark remark (Optional) Adds a description for an access list statement.
Example: • A remark can precede or follow an IP access list entry.
Device(config-ext-nacl)# remark protect server by
denying sales access to the acl1 network
• In this example, the remark command reminds the
network administrator that the deny command
configured in Step 5 denies the Sales network access
to the interface.
1043
Creating an IP Named Access List

Step 5 deny protocol [source source-wildcard] {any | host (Optional) Denies all packets that match all conditions
{address | name} {destination [destination-wildcard] {any specified by the remark.
| host {address | name} [log]
Example:
Device(config-ext-nacl)# deny ip 192.0.2.0
0.0.255.255 host 192.0.2.10 log
Step 6 remark remark (Optional) Adds a description for an access list statement.
Example: • A remark can precede or follow an IP access list entry.
Device(config-ext-nacl)# remark allow TCP from
any source to any destination
Step 7 permit protocol [source source-wildcard] {any | host Permits all packets that match all conditions specified by
{address | name} {destination [destination-wildcard] {any the statement.
| host {address | name} [log]
Example:
Device(config-ext-nacl)# permit tcp any any
Step 8 Repeat Steps 4 through 7 to specify more statements for Note All source addresses that are not specifically
your access list. permitted by a statement are denied by an
implicit deny statement at the end of the access
list.
Step 9 end Exits extended named access list configuration mode and
returns to privileged EXEC mode.
Example:
Step 10 show ip access-lists Displays the contents of all current IP access lists.
Example:
Device# show ip access-lists
Example:
The following is sample output from the show ip access-lists command:
Device# show ip access-lists acl1
Extended IP access list acl1

permit tcp any 192.0.2.0 255.255.255.255 eq telnet
deny tcp any any
deny udp any 192.0.2.0 255.255.255.255 lt 1024
deny ip any any log
1044

Procedure

Device> enable

Example:
Step 3 interface type number Specifies an interface and enters interface configuration
mode.
Example:
Step 4 ip access-group {access-list-number | access-list-name} Applies the specified access list to the inbound interface.
{in | out}
• To filter source addresses, apply the access list to the
Example: inbound interface.
Device(config-if)# ip access-group acl1 in

EXEC mode.
Example:
Additional References for IP Named Access Control Lists

Related Documents
Security commands • Cisco IOS Security Command Reference: Commands A to C

• Cisco IOS Security Command Reference: Commands D to L
• Cisco IOS Security Command Reference: Commands M to R
• Cisco IOS Security Command Reference: Commands S to Z
1045
Feature Information for IP Named Access Control Lists
Description Link

Feature Information for IP Named Access Control Lists

Table 179: Feature Information for IP Named Access Control Lists
1046
CHAPTER 71
IPv4 ACL Chaining Support
ACL Chaining, also known as Multi-Access Control List, allows you to split access control lists (ACLs). This
module describes how with the IPv4 ACL Chaining Support feature, you can explicitly split ACLs into
common and user-specific ACLs and bind both ACLs to a target for traffic filtering on a device. In this way,
the common ACLs in Ternary Content Addressable Memory (TCAM) are shared by multiple targets, thereby
reducing the resource usage.
Contents
• Restrictions for IPv4 ACL Chaining Support, on page 1049
• Information About IPv4 ACL Chaining Support, on page 1049
• How to Configure IPv4 ACL Chaining Support, on page 1050
• Configuration Examples for IPv4 ACL Chaining Support, on page 1050
• Additional References for IPv4 ACL Chaining Support, on page 1051
• Feature Information for IPv4 ACL Chaining Support, on page 1052
1047
Digital PICs:

Module:

Modules:
line card reload.
1048
Restrictions for IPv4 ACL Chaining Support
Restrictions for IPv4 ACL Chaining Support

• A single access control List (ACL) cannot be used for both common and regular ACLs for the same
target in the same direction.
• ACL chaining applies to only security ACLs. It is not supported for feature policies, such as Quality of
Service (QoS), Firewall Services Module (FW) and Policy Based Routing (PBR).
• Per-target statistics are not supported for common ACLs.
Information About IPv4 ACL Chaining Support

ACL Chaining Overview
The packet filter process supports only a single Access control list (ACL) to be applied per direction and per
protocol on an interface. This leads to manageability and scalability issues if there are common ACL entries
needed on many interfaces. Duplicate Access control entries (ACEs) are configured for all those interfaces,
and any modification to the common ACEs needs to be performed for all ACLs.
A typical ACL on the edge box for an Internet Service Provider (ISP) has two sets of ACEs:
• Common ISP specific ACEs
• Customer/interface specific ACEs
The purpose of these address blocks is to deny access to ISP's protected infrastructure networks and
anti-spoofing protection by allowing only customer source address blocks. This results in configuring unique
ACL per interface and most of the ACEs being common across all ACLs on a device. ACL provisioning and
modification is very cumbersome, hence, any changes to the ACE impacts every target.
IPv4 ACL Chaining Support

IPv4 ACL Chaining Support allows you to split the Access control list (ACL) into common and
customer-specific ACLs and attach both ACLs to a common session. In this way, only one copy of the common
ACL is attached to Ternary Content Addressable Memory (TCAM) and shared by all users, thereby making
it easier to maintain the common ACEs.
The IPv4 ACL Chaining feature allows two IPV4 ACLs to be active on an interface per direction:
• Common
• Regular
• Common and Regular
Note If you configure both common and regular ACLs on an interface, the common ACL is considered over a
regular ACL.
1049
How to Configure IPv4 ACL Chaining Support
How to Configure IPv4 ACL Chaining Support

ACL chaining is supported by extending the ip traffic filter command.
The ip traffic filter command is not additive. When you use this command, it replaces earlier instances of
the command.
For more information, refer to the IPv6 ACL Chaining with a Common ACL section in the Security
Configuration Guide: Access Control Lists Configuration Guide.
Configuring an Interface to Accept Common ACL

Perform this task to configure the interface to accept a common Access control list (ACL) along with an
interface-specific ACL:
Procedure

prompted.
Example:
Device> enable

Example:
Step 3 interface type number Configures an interface and enters the interface
configuration mode.
Example:
Step 4 ip access-group {common {common-access-list-name Configures the interface to accept a common ACL along
{regular-access-list | acl}}{in | out}} with the interface-specific ACL.
Example:
Device(config-if)# ipv4 access-group common acl-p

acl1 in

Example:
Configuration Examples for IPv4 ACL Chaining Support

This section provides configuration examples of Common Access Control List (ACL).
1050
Example: Configuring an Interface to Accept a Common ACL

This example shows how to replace an Access Control List (ACL) configured on the interface without explicitly
deleting the ACL:
ipv4 access-group common C_acl ACL1 in
end
replace interface acl ACL1 by ACL2
end
This example shows how common ACL cannot be replaced on interfaces without deleting it explicitly from
the interface:
ipv4 access-group common C_acl1 ACL1 in
end
change the common acl to C_acl2
no ipv4 access-group common C_acl1 ACL1 in
end
end
Note When reconfiguring a common ACL, you must ensure that no other interface on the line card is attached to
the common ACL.
Note If both common ACL and interface ACL are attached to an interface and only one of the above is reconfigured
on the interface, then the other is removed automatically.
This example shows how the interface ACL is removed:

end
Additional References for IPv4 ACL Chaining Support

Related Documents

IPv6 ACL Chaining Security Configuration Guide: Access Control Lists
Support
1051
Feature Information for IPv4 ACL Chaining Support

Security commands • Cisco IOS Security Command Reference: Commands A to
C
• Cisco IOS Security Command Reference: Commands D to
L
• Cisco IOS Security Command Reference: Commands M
to R
• Cisco IOS Security Command Reference: Commands S to
Z
Description Link
ID and password.
Feature Information for IPv4 ACL Chaining Support

Table 181: Feature Information for IPv4 ACL Chaining Support
IP access lists Cisco IOS XE Fuji This feature was integrated into Cisco IOS XE Fuji 16.7.1 on the
1052
CHAPTER 72
IPv6 ACL Chaining with a Common ACL
ACL Chaining, also known as Multi-Access Control List (ACL), allows you to split ACLs. This document
describes how with the IPv6 ACL Chaining Support feature, you can explicitly split ACLs into common and
user-specific ACLs and bind both ACLs to a target for traffic filtering on a device. In this way, the common
ACLs in Ternary Content Addressable Memory (TCAM) are shared by multiple targets, thereby reducing the
resource usage.
Contents
• Information About IPv6 ACL Chaining with a Common ACL, on page 1055
• How to Configure IPv6 ACL Chaining with a Common ACL, on page 1055
• Configuration Examples for IPv6 ACL Chaining with a Common ACL, on page 1057
• Additional References for IPv6 ACL Chaining with a Common ACL, on page 1058
• Feature Information for IPv6 ACL Chaining with a Common ACL, on page 1059
1053
Digital PICs:

Module:

Modules:
line card reload.
1054
Information About IPv6 ACL Chaining with a Common ACL
Information About IPv6 ACL Chaining with a Common ACL

ACL Chaining Overview
The packet filter process supports only a single Access control list (ACL) to be applied per direction and per
protocol on an interface. This leads to manageability and scalability issues if there are common ACL entries
needed on many interfaces. Duplicate Access control entries (ACEs) are configured for all those interfaces,
and any modification to the common ACEs needs to be performed for all ACLs.
A typical ACL on the edge box for an Internet Service Provider (ISP) has two sets of ACEs:
• Common ISP specific ACEs
• Customer/interface specific ACEs
The purpose of these address blocks is to deny access to ISP's protected infrastructure networks and
anti-spoofing protection by allowing only customer source address blocks. This results in configuring unique
ACL per interface and most of the ACEs being common across all ACLs on a device. ACL provisioning and
modification is very cumbersome, hence, any changes to the ACE impacts every target.
IPv6 ACL Chaining with a Common ACL

With IPv6 ACL Chaining, you can configure a traffic filter with the following:
• Common ACL
• Specific ACL
• Common and Specific ACL
Each Access control list (ACL) is matched in a sequence. For example, if you have specified both the ACLs
- a common and a specific ACL, the packet is first matched against the common ACL; if a match is not found,
it is then matched against the specific ACL.
Note Any IPv6 ACL may be configured on a traffic filter as a common or specific ACL. However, the same ACL
cannot be specified on the same traffic filter as both common and specific.
How to Configure IPv6 ACL Chaining with a Common ACL

Before you begin
IPv6 ACL chaining is configured on an interface using an extension of the existing IPv6 traffic-filter command:
ipv6 traffic-filter [common common-acl] [specific-acl] [ in | out]
1055
Configuring IPv6 ACL to an Interface
Note You may choose to configure either of the following:
• Only a common ACL. For example: ipv6 traffic-filter common common-acl

• Only a specific ACL. For example: ipv6 traffic-filter common-acl
• Both ACLs. For example: ipv6 traffic-filter common common-acl specific-acl
The ipv6 traffic-filter command is not additive. When you use the command, it replaces earlier instances of
the command. For example, the command sequence: ipv6 traffic-filter [common common-acl] [specific-acl]
in ipv6 traffic-filter [specific-acl] in binds a common ACL to the traffic filter, removes the common ACL
and then binds a specific ACL.
Configuring IPv6 ACL to an Interface

Perform this task to configure the interface to accept a common access control list (ACL) along with an
interface-specific ACL:
SUMMARY STEPS
1. enable
4. ipv6 traffic filter {common-access-list-name {in | out}}
5. end
DETAILED STEPS

prompted.
Example:
Device> enable

Example:
Step 3 interface type number Specifies the interface type and number, and enters interface
configuration mode.
Example:
Step 4 ipv6 traffic filter {common-access-list-name {in | out}} Applies the specified IPv6 access list to the interface
specified in the previous step.
Example:
Device(config)# ipv6 traffic-filter outbound out
1056
Configuration Examples for IPv6 ACL Chaining with a Common ACL

Example:
Configuration Examples for IPv6 ACL Chaining with a Common

ACL
You may configure the following combinations in no particular order:
• A common ACL, for example: ipv6 traffic-filter common common-acl in
• A specific ACL, for example: ipv6 traffic-filter specific-acl in
• Both ACLs, for example: ipv6 traffic-filter common common-acl specific-acl in

This example shows how to replace an access control list (ACL) configured on the interface without explicitly
deleting the ACL:
end
replace interface acl ACL1 by ACL2
end
This example shows how to delete a common ACL from an interface. A common ACL cannot be replaced
on interfaces without deleting it explicitly from the interface.
end
change the common acl to C_acl2
no ipv6 access-group common C_acl1 ACL1 in
end
end
Note When reconfiguring a common ACL, you must ensure that no other interface on the line card is attached to
the common ACL.
1057
Additional References for IPv6 ACL Chaining with a Common ACL
Note If both common ACL and interface ACL are attached to an interface and only one of the above is reconfigured
on the interface, then the other is removed automatically.
This example shows how to remove the interface ACL:

end
Additional References for IPv6 ACL Chaining with a Common

ACL
Related Documents

IPv4 ACL Chaining Security Configuration Guide: Access Control Lists, Cisco IOS XE Release 3S
Support

Description Link
ID and password.
1058
Feature Information for IPv6 ACL Chaining with a Common ACL

Table 183: Feature Information for IPv6 ACL Chaining with a Common ACL
IPv6 access Cisco IOS XE Fuji This feature was integrated into Cisco IOS XE Fuji 16.7.1 on
lists 16.7.1 theCisco cBR Series Converged Broadband Routers.
1059
1060
CHAPTER 73
Commented IP Access List Entries
The Commented IP Access List Entries feature allows you to include comments or remarks about deny or
permit conditions in any IP access list. These remarks make access lists easier for network administrators to
understand. Each remark is limited to 100 characters in length.
This module provides information about the Commented IP Access List Entries feature.
Contents
• Information About Commented IP Access List Entries, on page 1063
• How to Configure Commented IP Access List Entries, on page 1064
• Additional References for Commented IP Access List Entries, on page 1065
• Feature Information for Commented IP Access List Entries, on page 1065
1061
Digital PICs:

Module:

Modules:
line card reload.
1062
Information About Commented IP Access List Entries
Information About Commented IP Access List Entries

reach.
Translation (NAT).
Access List Remarks

You can include comments or remarks about entries in any IP access list. An access list remark is an optional
remark before or after an access list entry that describes the entry so that you do not have to interpret the
purpose of the entry. Each remark is limited to 100 characters in length.
1063
How to Configure Commented IP Access List Entries
The remark can go before or after a permit or deny statement. Be consistent about where you add remarks.
Users may be confused if some remarks precede the associated permit or deny statements and some remarks
follow the associated statements.
The following is an example of a remark that describes function of the subsequent deny statement:

remark Do not allow host1 subnet to telnet out
deny tcp host 172.16.2.88 any eq telnet
How to Configure Commented IP Access List Entries

Writing Remarks in a Named or Numbered Access List
You can use a named or numbered access list configuration. You must apply the access list to an interface or
terminal line after the access list is created for the configuration to work.
SUMMARY STEPS
1. enable
3. ip access-list {standard | extended} {name | number}
4. remark remark
5. deny protocol host host-address any eq port
6. end
DETAILED STEPS

Device> enable

Example:
Step 3 ip access-list {standard | extended} {name | number} Identifies the access list by a name or number and enters
Example:
Device(config)# ip access-list extended telnetting
Step 4 remark remark Adds a remark for an entry in a named IP access list.
Example: • The remark indicates the purpose of the permit or
Device(config-ext-nacl)# remark Do not allow host1 deny statement.
subnet to telnet out
1064
Additional References for Commented IP Access List Entries

Step 5 deny protocol host host-address any eq port Sets conditions in a named IP access list that denies packets.
Example:
Device(config-ext-nacl)# deny tcp host 172.16.2.88
any eq telnet
Step 6 end Exits extended named access list configuration mode and
enters privileged EXEC mode.
Example:
Additional References for Commented IP Access List Entries

Related Documents

Description Link

Feature Information for Commented IP Access List Entries

1065
Feature Information for Commented IP Access List Entries
Table 185: Feature Information for Commented IP Access List Entries
IP Access Lists Cisco IOS XE Fuji 16.7.1 This feature was integrated into Cisco IOS XE Fuji 16.7.1 on
theCisco cBR Series Converged Broadband Routers.
1066
CHAPTER 74
Standard IP Access List Logging
The Standard IP Access List Logging feature provides the ability to log messages about packets that are
permitted or denied by a standard IP access list. Any packet that matches the access list logs an information
message about the packet at the device console.
This module provides information about standard IP access list logging.
Contents
• Restrictions for Standard IP Access List Logging, on page 1068
• Information About Standard IP Access List Logging, on page 1069
• How to Configure Standard IP Access List Logging, on page 1069
• Configuration Examples for Standard IP Access List Logging, on page 1071
• Additional References for Standard IP Access List Logging, on page 1072
• Feature Information for Standard IP Access List Logging , on page 1072
1067
Restrictions for Standard IP Access List Logging
Digital PICs:

Module:

Modules:
line card reload.
Restrictions for Standard IP Access List Logging

IP access list logging is supported only for routed interfaces or router access control lists (ACLs).
1068
Information About Standard IP Access List Logging
Information About Standard IP Access List Logging

Standard IP Access List Logging
The Standard IP Access List Logging feature provides the ability to log messages about packets that are
permitted or denied by a standard IP access list. Any packet that matches the access list causes an information
log message about the packet to be sent to the device console. The log level of messages that are printed to
the device console is controlled by the logging console command.
The first packet that the access list inspects triggers the access list to log a message at the device console.
Subsequent packets are collected over 5-minute intervals before they are displayed or logged. Log messages
include information about the access list number, the source IP address of packets, the number of packets
from the same source that were permitted or denied in the previous 5-minute interval, and whether a packet
was permitted or denied. You can also monitor the number of packets that are permitted or denied by a
particular access list, including the source address of each packet.
How to Configure Standard IP Access List Logging

Creating a Standard IP Access List Using Numbers
SUMMARY STEPS
1. enable
3. access-list access-list-number {deny | permit} host address [log]
4. access-list access-list-number {deny | permit} any [log]
6. ip access-group access-list-number {in | out}
7. end
DETAILED STEPS

Device> enable

Example:
Step 3 access-list access-list-number {deny | permit} host address Defines a standard numbered IP access list using a source
[log] address and wildcard, and configures the logging of
1069
Creating a Standard IP Access List Using Names

Example: informational messages about packets that match the access
Device(config)# access-list 1 permit host 10.1.1.1 list entry at the device console.
log
Step 4 access-list access-list-number {deny | permit} any [log] Defines a standard numbered IP access list by using an
abbreviation for the source and source mask 0.0.0.0
Example:
255.255.255.255.
Device(config)# access-list 1 permit any log
Step 5 interface type number Configures an interface and enters interface configuration
mode.
Example:
Step 6 ip access-group access-list-number {in | out} Applies the specified numbered access list to the incoming
or outgoing interface.
Example:
Device(config-if)# ip access-group 1 in • When you filter based on source addresses, you
typically apply the access list to an incoming interface.
Step 7 end Exits interface configuration mode and enters privileged

EXEC mode.
Example:
Creating a Standard IP Access List Using Names

SUMMARY STEPS
1. enable
3. ip access-list standard name
4. {deny | permit} {host address | any} log
5. exit
7. ip access-group access-list-name {in | out}
8. end
DETAILED STEPS

Device> enable

Example:
1070
Configuration Examples for Standard IP Access List Logging

Step 3 ip access-list standard name Defines a standard IP access list and enters standard named
access list configuration mode.
Example:
Device(config)# ip access-list standard acl1
Step 4 {deny | permit} {host address | any} log Sets conditions in a named IP access list that will deny
packets from entering a network or permit packets to enter
Example:
a network, and configures the logging of informational
Device(config-std-nacl)# permit host 10.1.1.1 log messages about packets that match the access list entry at
the device console.
Step 5 exit Exits standard named access list configuration mode and
enters global configuration mode.
Example:
Device(config-std-nacl)# exit
Step 6 interface type number Configures an interface and enters interface configuration
mode.
Example:
Step 7 ip access-group access-list-name {in | out} Applies the specified access list to the incoming or outgoing
interface.
Example:
Device(config-if)# ip access-group acl1 in • When you filter based on source addresses, you
typically apply the access list to an incoming interface.
Step 8 end Exits interface configuration mode and enters privileged

EXEC mode.
Example:
Configuration Examples for Standard IP Access List Logging

Example: Limiting Debug Output
The following sample configuration uses an access list to limit the debug command output. Limiting the
debug output restricts the volume of data to what you are interested in, saving you time and resources.
Device(config)# ip access-list acl1

Device(config-std-nacl)# remark Displays only advertisements for LDP peer in acl1
Device(config-std-nacl)# permit host 10.0.0.44
Device# debug mpls ldp advertisements peer-acl acl1

1071
Additional References for Standard IP Access List Logging
Additional References for Standard IP Access List Logging

Related Documents

Description Link

Feature Information for Standard IP Access List Logging

Table 187: Feature Information for Standard IP Access List Logging
IP Access Lists Cisco IOS XE Fuji This feature was integrated into Cisco IOS XE Fuji 16.7.1 on the
1072
CHAPTER 75
IP Access List Entry Sequence Numbering
The IP Access List Entry Sequence Numbering feature allows you to apply sequence numbers to permit or
deny statements as well as reorder, add, or remove such statements from a named IP access list. The IP Access
List Entry Sequence Numbering feature makes revising IP access lists much easier. Prior to this feature, you
could add access list entries to the end of an access list only; therefore, needing to add statements anywhere
except at the end of a named IP access list required reconfiguring the entire access list.
Contents
• Restrictions for IP Access List Entry Sequence Numbering, on page 1074
• Information About IP Access List Entry Sequence Numbering, on page 1075
• How to Use Sequence Numbers in an IP Access List, on page 1079
• Configuration Examples for IP Access List Entry Sequence Numbering, on page 1082
• Feature Information for IP Access List Entry Sequence Numbering , on page 1084
1073
Restrictions for IP Access List Entry Sequence Numbering
Digital PICs:

Module:

Modules:
line card reload.
Restrictions for IP Access List Entry Sequence Numbering

• This feature does not support dynamic, reflexive, or firewall access lists.
1074
Information About IP Access List Entry Sequence Numbering
• This feature does not support old-style numbered access lists, which existed before named access lists.
Keep in mind that you can name an access list with a number, so numbers are allowed when they are
entered in the standard or extended named access list (NACL) configuration mode.
Information About IP Access List Entry Sequence Numbering

Purpose of IP Access Lists
Access lists perform packet filtering to control which packets move through the network and where. Such
control can help limit network traffic and restrict the access of users and devices to the network. Access lists
have many uses, and therefore many commands accept a reference to an access list in their command syntax.
Access lists can be used to do the following:
• Filter incoming packets on an interface.
• Filter outgoing packets on an interface.
• Restrict the contents of routing updates.
• Limit debug output based on an address or protocol.
• Control virtual terminal line access.
• Identify or classify traffic for advanced features, such as congestion avoidance, congestion management,
and priority and custom queuing.
• Trigger dial-on-demand routing (DDR) calls.
How an IP Access List Works

An access list is a sequential list consisting of a permit statement and a deny statement that apply to IP addresses
and possibly upper-layer IP protocols. The access list has a name by which it is referenced. Many software
commands accept an access list as part of their syntax.
An access list can be configured and named, but it is not in effect until the access list is referenced by a
command that accepts an access list. Multiple commands can reference the same access list. An access list
can control traffic arriving at the device or leaving the device, but not traffic originating at the device.
IP Access List Process and Rules

• The software tests the source or destination address or the protocol of each packet being filtered against
the conditions in the access list, one condition (permit or deny statement) at a time.
• If a packet does not match an access list statement, the packet is then tested against the next statement
in the list.
• If a packet and an access list statement match, the rest of the statements in the list are skipped and the
packet is permitted or denied as specified in the matched statement. The first entry that the packet matches
determines whether the software permits or denies the packet. That is, after the first match, no subsequent
entries are considered.
1075
• If the access list denies the address or protocol, the software discards the packet and returns an Internet
Control Message Protocol (ICMP) Host Unreachable message.
• If no conditions match, the packet is dropped. This is because each access list ends with an unwritten or
implicit deny statement. That is, if the packet has not been permitted by the time it was tested against
each statement, it is denied.
• Because the software stops testing conditions after the first match, the order of the conditions is critical.
The same permit or deny statements specified in a different order could result in a packet being passed
under one circumstance and denied in another circumstance.
• If an access list is referenced by name in a command, but the access list does not exist, all packets pass.
• Only one access list per interface, per protocol, per direction is allowed.
• Inbound access lists process packets arriving at the device. Incoming packets are processed before being
routed to an outbound interface. An inbound access list is efficient because it saves the overhead of
routing lookups if the packet is to be discarded because it is denied by the filtering tests. If the packet is
permitted by the tests, it is then processed for routing. For inbound lists, permit means continue to process
the packet after receiving it on an inbound interface; deny means discard the packet.
outbound interface and then processed through the outbound access list. For outbound lists, permit means
send it to the output buffer; deny means discard the packet.

access lists.
• Because the software stops testing conditions after it encounters the first match (to either a permit or
deny statement), you will reduce processing time and resources if you put the statements that packets
are most likely to match at the beginning of the access list. Place more frequently occurring conditions
before less frequent conditions.
general ones.
1076
Source and Destination Addresses
denied by issuing the show access-listcommand, thus finding out more information about who your
• You can delete an entry from a named access list. Use the no permitor no deny command to delete
• Before you add new ACL statements, provide time to the parser to clean up the deletion.
Source and Destination Addresses

Source and destination address fields in an IP packet are two typical fields on which to base an access list.
Specify source addresses to control the packets being sent from certain networking devices or hosts. Specify
destination addresses to control the packets being sent to certain networking devices or hosts.
Wildcard Mask and Implicit Wildcard Mask

When comparing the address bits in an access list entry to a packet being submitted to the access list, address
filtering uses wildcard masking to determine whether to check or ignore the corresponding IP address bits.
By carefully setting wildcard masks, an administrator can select one or more IP addresses for permit or deny
tests.
Wildcard masking for IP address bits uses the number 1 and the number 0 to specify how the software treats
the corresponding IP address bits. A wildcard mask is sometimes referred to as an inverted mask because a
1 and 0 mean the opposite of what they mean in a subnet (network) mask.
• A wildcard mask bit 0 means check the corresponding bit value.
• A wildcard mask bit 1 means ignore that corresponding bit value.
If you do not supply a wildcard mask with a source or destination address in an access list statement, the
software assumes a default wildcard mask of 0.0.0.0.
Unlike subnet masks, which require contiguous bits indicating network and subnet to be ones, wildcard masks
allow noncontiguous bits in the mask.
1077
Transport Layer Information
Transport Layer Information

You can filter packets based on transport layer information, such as whether the packet is a TCP, UDP, Internet
Control Message Protocol (ICMP) or Internet Group Management Protocol (IGMP) packet.
Benefits IP Access List Entry Sequence Numbering

an access list. If you wanted to insert an entry (statement) in the middle of an existing list, all of the entries
after the desired position had to be removed. Then, once you added the new entry, you needed to reenter all
of the entries you removed earlier. This method was cumbersome and error prone.
The IP Access List Entry Sequence Numbering feature allows you to add sequence numbers to access list
entries and resequence them. When you add a new entry, you can choose the sequence number so that the
entry is in a desired position in the access list. If necessary, entries currently in the access list can be resequenced
(reordered) to create room to insert the new entry.
Sequence Numbering Behavior

• For backward compatibility with previous releases, if entries with no sequence numbers are applied, the
first entry is assigned a sequence number of 10, and successive entries are incremented by 10. The
maximum sequence number is 2147483647. If the generated sequence number exceeds this maximum
number, the following message is displayed:
Exceeded maximum sequence number.
• If you enter an entry without a sequence number, it is assigned a sequence number that is 10 greater than
the last sequence number in that access list and is placed at the end of the list.
• If you enter an entry that matches an already existing entry (except for the sequence number), then no
changes are made.
• If you enter a sequence number that is already present, the following error message is generated:
Duplicate sequence number.
• If a new access list is entered from global configuration mode, then sequence numbers for that access
list are generated automatically.
• Entries that contain a fully qualified 32-bit host address are hashed instead of linked. And entries that
define a sub-net are maintained in a linked list that is sorted by the sequence number for speed of ACL
classification. When a packet is matched against a standard ACL, the source address is hashed and
matched against the hash table. If no match is found, it then searches the linked list for a possible match.
• Distributed support is provided so that the sequence numbers of entries in the Route Processor (RP) and
line card (LC) are always synchronized.
• From Cisco IOS XE Release 16.12, sequence numbers are nvgened. That is, the sequence numbers are
saved. In the event that a system is reloaded, the configured sequence numbers are preserved.
1078
How to Use Sequence Numbers in an IP Access List
• From Cisco IOS XE Release 16.12, remarks can be added with or without sequence number. These
remarks can be added to any existing ACE and they are nvgened.
• Sequence numbers are not nvgened. That is, the sequence numbers themselves are not saved. In the event
that the system is reloaded, the configured sequence numbers revert to the default sequence starting
number and increment from that number. The function is provided for backward compatibility with
software releases that do not support sequence numbering.
• The IP Access List Entry Sequence Numbering feature works with named standard and extended IP
access lists. Because the name of an access list can be designated as a number, numbers are acceptable.
How to Use Sequence Numbers in an IP Access List

Sequencing Access-List Entries and Revising the Access List
This task shows how to assign sequence numbers to entries in a named IP access list and how to add or delete
an entry to or from an access list. When completing this task, keep the following points in mind:
• Resequencing the access list entries is optional. The resequencing step in this task is shown as required
because that is one purpose of this feature and this task demonstrates that functionality.
• In the following procedure, the permit command is shown in Step 5 and the deny command is shown
in Step 6. However, that order can be reversed. Use the order that suits the need of your configuration.
SUMMARY STEPS
1. enable
3. ip access-list resequence access-list-name starting-sequence-number increment
4. ip access-list {standard| extended} access-list-name
1079

9. Repeat Step 5 and/or Step 6 to add sequence number statements, as applicable.
10. end
11. show ip access-lists access-list-name
DETAILED STEPS

prompted.
Example:
Device> enable

Example:
Step 3 ip access-list resequence access-list-name Resequences the specified IP access list using the starting
starting-sequence-number increment sequence number and the increment of sequence numbers.
Example:
Device(config)# ip access-list resequence kmd1

100 15
Step 4 ip access-list {standard| extended} access-list-name Specifies the IP access list by name and enters named
access list configuration mode.
Example:
• If you specify standard, make sure you subsequently
Device(config)# ip access-list standard kmd1 specify permit and/or deny statements using the
standard access list syntax.
• If you specify extended, make sure you subsequently
specify permit and/or deny statements using the
extended access list syntax.
• sequence-number permit source source-wildcard • This access list happens to use a permit statement
• sequence-number permit protocol source first, but a deny statement could appear first,
source-wildcard destination destination-wildcard depending on the order of statements you need.
Example: the prompt for this step would be
Device(config-ext-nacl) and you would use the
Device(config-std-nacl)# 105 permit 10.5.5.5 0.0.0 extended permit command syntax.
255
1080

list mode.
• sequence-number deny protocol source • This access list uses a permit statement first, but a
source-wildcard destination destination-wildcard deny statement could appear first, depending on the
[precedence precedence][tos tos] [log] [time-range order of statements you need.
Example: access list. If you had specified extended in Step 4,
Device(config-std-nacl)# 105 deny 10.6.6.7 0.0.0 Device(config-ext-nacl) and you would use the
255 extended deny command syntax.
• sequence-number permit source source-wildcard • This access list happens to use a permitstatement
• sequence-number permit protocol source first, but a deny statement could appear first,
source-wildcard destination destination-wildcard depending on the order of statements you need.
• See the permit (IP) command for additional command
syntax to permit upper layer protocols (ICMP, IGMP,
Example: TCP, and UDP).
Device(config-ext-nacl)# 150 permit tcp any any

log entry.
list mode.
• sequence-number deny protocol source • This access list happens to use a permitstatement
source-wildcard destination destination-wildcard first, but a deny statement could appear first,
[precedence precedence][tos tos] [log] [time-range depending on the order of statements you need.
• See the deny (IP) command for additional command
Example: syntax to permit upper layer protocols (ICMP, IGMP,
TCP, and UDP).
Device(config-ext-nacl)# 150 deny tcp any any log
entry.
Step 9 Repeat Step 5 and/or Step 6 to add sequence number Allows you to revise the access list.
statements, as applicable.
Example:
Step 11 show ip access-lists access-list-name (Optional) Displays the contents of the IP access list.
Example:
1081
Configuration Examples for IP Access List Entry Sequence Numbering
Examples
Review the output of the show ip access-lists command to see that the access list includes the new
entries:
Standard IP access list kmd1

Configuration Examples for IP Access List Entry Sequence

Numbering
Example: Resequencing Entries in an Access List
The following example shows access list resequencing. The starting value is 1, and increment value is 2. The
subsequent entries are ordered based on the increment values specified, and the range is from 1 to 2147483647.
When an entry with no sequence number is entered, by default the entry has a sequence number of 10 more
than the last entry in the access list.
Device# show access-list 150
Extended IP access list 150

Device(config)# ip access-list extended 150

Device(config)# ip access-list resequence 150 1 2
Device(config)# exit
Device# show access-list 150

10 permit tcp any any eq 22 log
1082
Example: Adding Entries with Sequence Numbers

Example: Adding Entries with Sequence Numbers

In the following example, an new entry is added to a specified access list:

Device(config)# ip access-list standard tryon

Device(config-std-nacl)# 15 permit 10.5.5.5 0.0.0.255
Device(config-std-nacl)# exit

Example: Entry Without Sequence Number

The following example shows how an entry with no specified sequence number is added to the end of an
access list. When an entry is added without a sequence number, it is automatically given a sequence number
that puts it at the end of the access list. Because the default increment is 10, the entry will have a sequence
number 10 higher than the last entry in the existing access list.
Device(config)# ip access-list standard 1

Device(config-std-nacl)## exit
Device# show access-list
Standard IP access list 1

Device(config)# ip access-list standard 1

Device(config-std-nacl)## exit
Device# show access-list

1083

Related Documents
IP access list commands Cisco IOS Security Command Reference
Configuring IP access Creating an IP Access List and Applying It to an Interface

lists
Description Link

Feature Information for IP Access List Entry Sequence

Numbering
Table 189: Feature Information for IP Access List Entry Sequence Numbering
IP Access Lists Cisco IOS XE Fuji This feature was integrated into the Cisco cBR Series Converged
16.7.1 Broadband Routers.
1084
CHAPTER 76
ACL IP Options Selective Drop
The ACL IP Options Selective Drop feature allows Cisco routers to filter packets containing IP options or to
mitigate the effects of IP options on a router or downstream routers by dropping these packets or ignoring the
processing of the IP options.
Contents
• Restrictions for ACL IP Options Selective Drop, on page 1087
• Information About ACL IP Options Selective Drop, on page 1087
• How to Configure ACL IP Options Selective Drop, on page 1087
• Configuration Examples for ACL IP Options Selective Drop, on page 1088
• Additional References for IP Access List Entry Sequence Numbering, on page 1089
• Feature Information for ACL IP Options Selective Drop, on page 1090
1085
Digital PICs:

Module:

Modules:
line card reload.
1086
Restrictions for ACL IP Options Selective Drop
Restrictions for ACL IP Options Selective Drop

Resource Reservation Protocol (RSVP) (Multiprotocol Label Switching traffic engineering [MPLS TE]),
Internet Group Management Protocol Version 2 (IGMPv2), and other protocols that use IP options packets
may not function in drop or ignore modes.
Information About ACL IP Options Selective Drop

Using ACL IP Options Selective Drop
The ACL IP Options Selective Drop feature allows a router to filter IP options packets, thereby mitigating
the effects of these packets on a router and downstream routers, and perform the following actions:
• Drop all IP options packets that it receives and prevent options from going deeper into the network.
• Ignore IP options packets destined for the router and treat them as if they had no IP options.
For many users, dropping the packets is the best solution. However, in environments in which some IP options
may be legitimate, reducing the load that the packets present on the routers is sufficient. Therefore, users may
prefer to skip options processing on the router and forward the packet as though it were pure IP.
Benefits of Using ACL IP Options Selective Drop

• Drop mode filters packets from the network and relieves downstream routers and hosts of the load from
options packets.
• Drop mode minimizes loads to the Route Processor (RP) for options that require RP processing on
distributed systems. Previously, the packets were always routed to or processed by the RP CPU. Now,
the ignore and drop forms prevent the packets from impacting the RP performance.
How to Configure ACL IP Options Selective Drop

Configuring ACL IP Options Selective Drop
This section describes how to configure the ACL IP Options Selective Drop feature.
SUMMARY STEPS
1. enable
3. ip options {drop | ignore}
4. exit
5. show ip traffic
1087
Configuration Examples for ACL IP Options Selective Drop
DETAILED STEPS

Router> enable

Example:
Step 3 ip options {drop | ignore} Drops or ignores IP options packets that are sent to the
router.
Example:
Router(config)# ip options drop
Step 4 exit Returns to privileged EXEC mode.

Example:
Step 5 show ip traffic (Optional) Displays statistics about IP traffic.

Example:
Router# show ip traffic
Configuration Examples for ACL IP Options Selective Drop

Example Configuring ACL IP Options Selective Drop
The following example shows how to configure the router (and downstream routers) to drop all options packets
that enter the network:
Router(config)# ip options drop

% Warning:RSVP and other protocols that use IP Options packets may not function in drop or
ignore modes.
end
Example Verifying ACL IP Options Selective Drop

The following sample output is displayed after using the ip options drop command:
Router# show ip traffic

IP statistics:
Rcvd: 428 total, 323 local destination
1088
Additional References for IP Access List Entry Sequence Numbering
0 format errors, 0 checksum errors, 0 bad hop count

0 unknown protocol, 0 not a gateway
0 security failures, 0 bad options, 0 with options
Opts: 0 end, 0 nop, 0 basic security, 0 loose source route
0 timestamp, 0 extended security, 0 record route
0 stream ID, 0 strict source route, 0 alert, 0 cipso, 0 ump
0 other, 30 ignored
Frags: 0 reassembled, 0 timeouts, 0 couldn't reassemble
0 fragmented, 0 fragments, 0 couldn't fragment
Bcast: 0 received, 0 sent
Mcast: 323 received, 809 sent
Sent: 809 generated, 591 forwarded
Drop: 0 encapsulation failed, 0 unresolved, 0 no adjacency
0 no route, 0 unicast RPF, 0 forced drop, 0 unsupported-addr
0 options denied, 0 source IP address zero
Additional References for IP Access List Entry Sequence

Numbering
The following sections provide references related to IP access lists.
Related Documents
Configuring IP access lists "Creating an IP Access List and Applying It to an Interface"
IP access list commands • Cisco IOS Security Command Reference: Commands A to

C
L
• Cisco IOS Security Command Reference: Commands M
to R
Z
1089
Feature Information for ACL IP Options Selective Drop
Description Link
Feature Information for ACL IP Options Selective Drop

Table 191: Feature Information for ACL IP Options Selective Drop
1090
CHAPTER 77
ACL Syslog Correlation
The Access Control List (ACL) Syslog Correlation feature appends a tag (either a user-defined cookie or a
device-generated MD5 hash value) to access control entry (ACE) syslog entries. This tag uniquely identifies
the ACE , within the ACL, that generated the syslog entry.
Contents
• Prerequisites for ACL Syslog Correlation, on page 1093
• Information About ACL Syslog Correlation, on page 1093
• How to Configure ACL Syslog Correlation, on page 1094
• Configuration Examples for ACL Syslog Correlation, on page 1100
• Additional References for IPv6 IOS Firewall, on page 1102
• Feature Information for ACL Syslog Correlation, on page 1102
1091
Digital PICs:

Module:

Modules:
line card reload.
1092
Prerequisites for ACL Syslog Correlation
Prerequisites for ACL Syslog Correlation

Before you configure the ACL Syslog Correlation feature, you must understand the concepts in the "IP Access
List Overview" module.
The ACL Syslog Correlation feature appends a user-defined cookie or a device-generated hash value to ACE
messages in the syslog. These values are only appended to ACE messages when the log option is enabled for
the ACE.
Information About ACL Syslog Correlation

ACL Syslog Correlation Tags
The ACL Syslog Correlation feature appends a tag (either a user-defined cookie or a device-generated MD5
hash value) to access control entry (ACE) syslog entries. This tag uniquely identifies an ACE that generated
the syslog entry.
Network management software can use the tag to identify which ACE generated a specific syslog event. For
example, network administrators can select an ACE rule in the network management application and can then
view the corresponding syslog events for that ACE rule.
To append a tag to the syslog message, the ACE that generates the syslog event must have the log option
enabled. The system appends only one type of tag (either a user-defined cookie or a device-generated MD5
hash value) to each message.
To specify a user-defined cookie tag, the user must enter the cookie value when configuring the ACE log
option. The cookie must be in alpha-numeric form, it cannot be greater than 64 characters, and it cannot start
with hex-decimal notation (such as 0x).
To specify a device-generated MD5 hash value tag, the hash-generation mechanism must be enabled on the
device and the user must not enter a cookie value while configuring the ACE log option.
ACE Syslog Messages

When a packet is matched against an access control entry (ACE) in an ACL, the system checks whether the
log option is enabled for that event. If the log option is enabled and the ACL Syslog Correlation feature is
configured on the device, the system attaches the tag to the syslog message. The tag is displayed at the end
of the syslog message, in addition to the standard information.
The following is a sample syslog message showing a user-defined cookie tag:
Jun 5 12:55:44.359: %SEC-6-IPACCESSLOGP: list logacl permitted tcp 192.168.16.1(38402) ->

192.168.16.2(23), 1 packet [User_permiited_ACE]
The following is a sample syslog message showing a hash value tag:
Jun 5 12:55:44.359: %SEC-6-IPACCESSLOGP: list logacl permitted tcp 192.168.16.1(38402) ->

192.168.16.2(23), 1 packet [0x723E6E12]
1093
How to Configure ACL Syslog Correlation
How to Configure ACL Syslog Correlation

Enabling Hash Value Generation on a Device
Perform this task to configure the device to generate an MD5 hash value for each log-enabled access control
entry (ACE) in the system that is not configured with a user-defined cookie.
When the hash value generation setting is enabled, the system checks all existing ACEs and generates a hash
value for each ACE that requires one. When the hash value generation setting is disabled, all previously
generated hash values are removed from the system.
SUMMARY STEPS
1. enable
3. ip access-list logging hash-generation
4. end
• show ip access-list access-list-number
• show ip access-list access-list-name
DETAILED STEPS

Device> enable

Example:
Step 3 ip access-list logging hash-generation Enables hash value generation on the device.
Example: • If an ACE exists that is log enabled, and requires a
hash value, the device automatically generates the
Device(config)# ip access-list logging value and displays the value on the console.
hash-generation
Step 4 end (Optional) Exits global configuration mode and returns to

Example:
Device(config)# end
1094
Disabling Hash Value Generation on a Device

Step 5 Do one of the following: (Optional) Displays the contents of the numbered or named
IP access list.
• show ip access-list access-list-name • Review the output to confirm that the access list for a
log-enabled ACE includes the generated hash value.
Example:
Device# show ip access-list 101
Example:
Device# show ip access-list acl
Disabling Hash Value Generation on a Device

Perform this task to disable hash value generation on the device. When the hash value generation setting is
disabled, all previously generated hash values are removed from the system.
SUMMARY STEPS
1. enable
3. no ip access-list logging hash-generation
4. end
• show ip access-list access-list-name
DETAILED STEPS

Device> enable

Example:
Step 3 no ip access-list logging hash-generation Disables hash value generation on the device.
Example: • The system removes any previously created hash
values from the system.
Device(config)# no ip access-list logging
hash-generation
1095
Configuring ACL Syslog Correlation Using a User-Defined Cookie

Example:
Device(config)# end
Step 5 Do one of the following: (Optional) Displays the contents of the IP access list.
• show ip access-list access-list-number • Review the output to confirm that the access list for a
• show ip access-list access-list-name log-enabled ACE does not have a generated hash value.
Example:
Example:
Device# show ip access-list acl
Configuring ACL Syslog Correlation Using a User-Defined Cookie

Perform this task to configure the ACL Syslog Correlation feature on a device for a specific access list, using
a user-defined cookie as the syslog message tag.
The example in this section shows how to configure the ACL Syslog Correlation feature using a user-defined
cookie for a numbered access list. However, you can configure the ACL Syslog Correlation feature using a
user-defined cookie for both numbered and named access lists, and for both standard and extended access
lists.
Note The following restrictions apply when choosing the user-defined cookie value:
• The maximum number of characters is 64.
• The cookie cannot start with hexadecimal notation (such as 0x).
• The cookie cannot be the same as, or a subset of, the following keywords: reflect, fragment, time-range.
For example, reflect and ref are not valid values. However, the cookie can start with the keywords. For
example, reflectedACE and fragment_33 are valid values
• The cookie must contains only alphanumeric characters.
>
SUMMARY STEPS
1. enable
3. access-list access-list-number permit protocol source destination log word
4. end
5. show ip access-list access-list-number
1096
Configuring ACL Syslog Correlation Using a Hash Value
DETAILED STEPS

Device> enable

Example:
Step 3 access-list access-list-number permit protocol source Defines an extended IP access list and a user-defined cookie
destination log word value.
Example: • Enter the cookie value as the wordargument.
Device(config)# access-list 101 permit tcp host

10.1.1.1 host 10.1.1.2 log UserDefinedValue

Example:
Device(config)# end
Step 5 show ip access-list access-list-number (Optional) Displays the contents of the IP access list.
Example: • Review the output to confirm that the access list
includes the user-defined cookie value.
Examples
The following is sample output from the show ip access-list command for an access list with a
user-defined cookie value.

101
30 permit tcp host 10.1.1.1 host 10.1.1.2 log (tag = UserDefinedValue)

Perform this task to configure the ACL Syslog Correlation feature on a device for a specific access list, using
a device-generated hash value as the syslog message tag.
The steps in this section shows how to configure the ACL Syslog Correlation feature using a device-generated
hash value for a numbered access list. However, you can configure the ACL Syslog Correlation feature using
1097
a device-generated hash value for both numbered and named access lists, and for both standard and extended
access lists.
SUMMARY STEPS
1. enable
3. ip access-list logging hash-generation
4. access-list access-list-number permit protocol source destination log
5. end
DETAILED STEPS

Device> enable

Example:
Step 3 ip access-list logging hash-generation Enables hash value generation on the device.
Example: • If an ACE exists that is log enabled, and requires a
hash value, the device automatically generates the
Device(config)# ip access-list logging value and displays the value on the console.
hash-generation
Step 4 access-list access-list-number permit protocol source Defines an extended IP access list.
destination log
• Enable the log option for the access list, but do not
Example: specify a cookie value.
Device(config)# access-list 102 permit tcp host

• The device automatically generates a hash value for
10.1.1.1 host 10.1.1.2 log the newly defined access list.

Example:
Device(config)# end
Example: • Review the output to confirm that the access list
includes the router-generated hash value.
1098
Changing the ACL Syslog Correlation Tag Value
Examples
The following is sample output from the show ip access-list command for an access list with a
device-generated hash value.

102
10 permit tcp host 10.1.1.1 host 10.1.1.2 log (hash = 0x7F9CF6B9)
Changing the ACL Syslog Correlation Tag Value

Perform this task to change the value of the user-defined cookie or replace a device-generated hash value with
a user-defined cookie.
The steps in this section shows how to change the ACL Syslog Correlation tag value on a numbered access
list. However, you can change the ACL Syslog Correlation tag value for both numbered and named access
lists, and for both standard and extended access lists.
SUMMARY STEPS
1. enable
2. show access-list
4. access-list access-list-number permit protocol source destination log word
5. end
DETAILED STEPS

Device> enable
Step 2 show access-list (Optional) Displays the contents of the access list.
Example:
Device(config)# show access-list

Example:
Step 4 access-list access-list-number permit protocol source Modifies the cookie or changes the hash value to a cookie.
destination log word
1099

Example: • You must enter the entire access list configuration
command, replacing the previous tag value with the
Device(config)# access-list 101 permit tcp host new tag value.
10.1.1.1 host 10.1.1.2 log NewUDV
Example:
OR
Example:
Example:
Device(config)# access-list 101 permit tcp any any

log replacehash

Example:
Device(config)# end
Example: • Review the output to confirm the changes.
Use the debug ip access-list hash-generation command to display access list debug information. The following
is an example of the debug command output:
Device# debug ip access-list hash-generation

Syslog hash code generation debugging is on
Device# show debug
IP ACL:
Syslog hash code generation debugging is on
Device# no debug ip access-list hash-generation
Syslog hash code generation debugging is off

Device# show debug
Device#
Configuration Examples for ACL Syslog Correlation

Example: Configuring ACL Syslog Correlation Using a User-Defined Cookie
The following example shows how to configure the ACL Syslog Correlation feature on a device using a
user-defined cookie.
1100
Example: Configuring ACL Syslog Correlation using a Hash Value
Device#
Syslog MD5 hash code generation debugging is on
Device(config)# access-list 33 permit 10.10.10.6 log cook_33_std
Device(config)# do show ip access 33
10 permit 10.10.10.6 log (tag = cook_33_std)
Device(config)# end
Example: Configuring ACL Syslog Correlation using a Hash Value

The following examples shows how to configure the ACL Syslog Correlation feature on a device using a
device-generated hash value.

Syslog MD5 hash code generation debugging is on
Device(config)# access-list 33 permit 10.10.10.7 log
Device(config)#
*Nov 7 13:51:23.615: %IPACL-HASHGEN: Hash Input: 33 standard permit 10.10.10.7
Hash Output: 0xCE87F535
Device(config)#
do show ip access 33

10 permit 10.10.10.6 log (tag = cook_33_std)
20 permit 10.10.10.7 log (hash = 0xCE87F535)
Example: Changing the ACL Syslog Correlation Tag Value

The following example shows how to replace an existing access list user-defined cookie with a new cookie
value, and how to replace a device-generated hash value with a user-defined cookie value.

Device(config)# do show ip access-list 101
10 permit tcp host 10.1.1.1 host 10.1.1.2 log (tag = MyCookie)
20 permit tcp any any log (hash = 0x75F078B9)
Device(config)# access-list 101 permit tcp host 10.1.1.1 host 10.1.1.2 log NewUDV
Device(config)# do show access-list
10 permit tcp host 10.1.1.1 host 10.1.1.2 log (tag = NewUDV)
20 permit tcp any any log (hash = 0x75F078B9)
Device(config)# access-list 101 permit tcp any any log replacehash
Device(config)# do show access-list
10 permit tcp host 10.1.1.1 host 10.1.1.2 log (tag = NewUDV)
20 permit tcp any any log (tag = replacehash)
1101
Additional References for IPv6 IOS Firewall
Additional References for IPv6 IOS Firewall

Related Documents
Security commands • Cisco IOS Security Command Reference: Commands A to

C
L
• Cisco IOS Security Command Reference: Commands M to
R
Z
IPv6 commands Cisco IOS IPv6 Command Reference
IPv6 addressing and connectivity IPv6 Configuration Guide
Cisco IOS IPv6 features Cisco IOS IPv6 Feature Mapping
Standards and RFCs
Standard/RFC Title
RFCs for IPv6

IPv6 RFCs
Description Link

Feature Information for ACL Syslog Correlation

1102
Table 193: Feature Information for ACL Syslog Correlation
1103
1104
CHAPTER 78
IPv6 Access Control Lists
Access lists determine what traffic is blocked and what traffic is forwarded at device interfaces and allow
filtering of traffic based on source and destination addresses, and inbound and outbound traffic to a specific
interface. Standard IPv6 ACL functionality was extended to support traffic filtering based on IPv6 option
headers and optional, upper-layer protocol type information for finer granularity of control. Standard IPv6
ACL functionality was extended to support traffic filtering based on IPv6 option headers and optional,
upper-layer protocol type information for finer granularity of control.
Contents
• Information About IPv6 Access Control Lists, on page 1107
• How to Configure IPv6 Access Control Lists, on page 1107
• Configuration Examples for IPv6 Access Control Lists, on page 1112
• Feature Information for IPv6 Access Control Lists, on page 1113
1105
Digital PICs:

Module:

Modules:
line card reload.
1106
Information About IPv6 Access Control Lists
Information About IPv6 Access Control Lists

Access Control Lists for IPv6 Traffic Filtering
The standard ACL functionality in IPv6 is similar to standard ACLs in IPv4. Access lists determine what
traffic is blocked and what traffic is forwarded at device interfaces and allow filtering based on source and
destination addresses, inbound and outbound to a specific interface. Each access list has an implicit deny
statement at the end. IPv6 ACLs are defined and their deny and permit conditions are set using the ipv6
access-listcommand with the deny and permit keywords in global configuration mode.
IPv6 extended ACLs augments standard IPv6 ACL functionality to support traffic filtering based on IPv6
option headers and optional, upper-layer protocol type information for finer granularity of control (functionality
similar to extended ACLs in IPv4).
IPv6 Packet Inspection

The following header fields are used for IPv6 inspection: traffic class, flow label, payload length, next header,
hop limit, and source or destination IP address. For further information on and descriptions of the IPv6 header
fields, see RFC 2474.
Access Class Filtering in IPv6

Filtering incoming and outgoing connections to and from the device based on an IPv6 ACL is performed
using the ipv6 access-class command in line configuration mode. The ipv6 access-class command is similar
to the access-class command, except the IPv6 ACLs are defined by a name. If the IPv6 ACL is applied to
inbound traffic, the source address in the ACL is matched against the incoming connection source address
and the destination address in the ACL is matched against the local device address on the interface. If the
IPv6 ACL is applied to outbound traffic, the source address in the ACL is matched against the local device
address on the interface and the destination address in the ACL is matched against the outgoing connection
source address. We recommend that identical restrictions are set on all the virtual terminal lines because a
user can attempt to connect to any of them.
How to Configure IPv6 Access Control Lists

Configuring IPv6 Traffic Filtering
Creating and Configuring an IPv6 ACL for Traffic Filtering
Note IPv6 ACLs on the Cisco cBR router do not contain implicit permit rules. The IPv6 neighbor discovery process
uses the IPv6 network-layer service; therefore, to enable IPv6 neighbor discovery, you must add IPv6 ACLs
to allow IPv6 neighbor discovery packets to be sent and received on an interface. In IPv4, the Address
Resolution Protocol (ARP), which is equivalent to the IPv6 neighbor discovery process, uses a separate
data-link-layer protocol; therefore, by default IPv4 ACLs implicitly allow ARP packets to be sent and received
on an interface.
1107
Creating and Configuring an IPv6 ACL for Traffic Filtering
SUMMARY STEPS
1. enable
3. ipv6 access-list access-list-name
• permit protocol {source-ipv6-prefix/prefix-length | any | host source-ipv6-address} [operator
[port-number]] {destination-ipv6-prefix / prefix-length | any | host destination-ipv6-address}
[operator [port-number]] [dest-option-type [doh-number | doh-type]] [dscp value] [flow-label
value] [fragments] [log] [log-input] [mobility] [mobility-type [mh-number | mh-type]] [routing]
[routing-type routing-number] [sequence value] [time-range name]
• deny protocol {source-ipv6-prefix/prefix-length | any | host source-ipv6-address} [operator
port-number]] {destination-ipv6-prefix/prefix-length | any | host destination-ipv6-address} [operator
[port-number]] [dest-option-type [doh-number | doh-type] ] [dscp value] [flow-label value]
[fragments] [log] [log-input] [mobility] [mobility-type [mh-number | mh-type]] [routing]
[routing-type routing-number] [sequence value] [time-range name] [undetermined-transport
DETAILED STEPS

Device> enable

Example:
Step 3 ipv6 access-list access-list-name Defines an IPv6 ACL, and enters IPv6 access list
configuration mode.
Example:
• The access-list nameargument specifies the name of
Device(config)# ipv6 access-list inbound the IPv6 ACL. IPv6 ACL names cannot contain a space
or quotation mark, or begin with a numeral.
Step 4 Do one of the following: Specifies permit or deny conditions for an IPv6 ACL.
• permit protocol {source-ipv6-prefix/prefix-length |
any | host source-ipv6-address} [operator
[port-number]] {destination-ipv6-prefix / prefix-length
| any | host destination-ipv6-address} [operator
[port-number]] [dest-option-type [doh-number |
doh-type]] [dscp value] [flow-label value] [fragments]
[log] [log-input] [mobility] [mobility-type
[mh-number | mh-type]] [routing] [routing-type
routing-number] [sequence value] [time-range name]
• deny protocol {source-ipv6-prefix/prefix-length |
1108
Applying the IPv6 ACL to an Interface

port-number]] {destination-ipv6-prefix/prefix-length
doh-type] ] [dscp value] [flow-label value]
[fragments] [log] [log-input] [mobility]
[mobility-type [mh-number | mh-type]] [routing]
[routing-type routing-number] [sequence value]
[time-range name] [undetermined-transport
Example:
Device(config-ipv6-acl)# permit tcp

2001:DB8:0300:0201::/32 eq telnet any
Example:
Device(config-ipv6-acl)# deny tcp host

2001:DB8:1::1 any log-input
Applying the IPv6 ACL to an Interface
SUMMARY STEPS
1. enable
4. ipv6 traffic-filter access-list-name {in| out}
DETAILED STEPS

Device> enable

Example:
Step 3 interface type number Specifies the interface type and number, and enters interface
configuration mode.
Example:
Step 4 ipv6 traffic-filter access-list-name {in| out} Applies the specified IPv6 access list to the interface
specified in the previous step.
Example:
1109
Controlling Access to a vty
Device(config-if)# ipv6 traffic-filter outbound

out
Controlling Access to a vty

Creating an IPv6 ACL to Provide Access Class Filtering
SUMMARY STEPS
1. enable
• permit protocol {source-ipv6-prefix/prefix-length | any | host source-ipv6-address} [operator
[port-number]] {destination-ipv6-prefix / prefix-length | any | host destination-ipv6-address} [operator
[port-number]] [dest-option-type [doh-number | doh-type]] [dscp value] [flow-label value]
[routing-type routing-number] [sequence value] [time-range name
• deny protocol {source-ipv6-prefix/prefix-length | any | host source-ipv6-address} [operator
port-number]] {destination-ipv6-prefix/prefix-length | any | host destination-ipv6-address} [operator
[port-number]] [dest-option-type [doh-number | doh-type]] [dscp value] [flow-label value]
[routing-type routing-number] [sequence value] [time-range name] [undetermined-transport
DETAILED STEPS

Device> enable

Example:
Step 3 ipv6 access-list access-list-name Defines an IPv6 ACL, and enters IPv6 access list
configuration mode.
Example:
Device(config)# ipv6 access-list cisco
1110
Applying an IPv6 ACL to the Virtual Terminal Line

Step 4 Do one of the following: Specifies permit or deny conditions for an IPv6 ACL.
• permit protocol {source-ipv6-prefix/prefix-length |
[port-number]] {destination-ipv6-prefix / prefix-length
doh-type]] [dscp value] [flow-label value] [fragments]
[log] [log-input] [mobility] [mobility-type
[mh-number | mh-type]] [routing] [routing-type
routing-number] [sequence value] [time-range name
• deny protocol {source-ipv6-prefix/prefix-length | any
| host source-ipv6-address} [operator port-number]]
{destination-ipv6-prefix/prefix-length | any | host
destination-ipv6-address} [operator [port-number]]
[dest-option-type [doh-number | doh-type]] [dscp
value] [flow-label value] [fragments] [log] [log-input]
[mobility] [mobility-type [mh-number | mh-type]]
[routing] [routing-type routing-number] [sequence
value] [time-range name] [undetermined-transport
Example:
Device(config-ipv6-acl)# permit ipv6 host

2001:DB8:0:4::32 any
Example:
Device(config-ipv6-acl)# deny ipv6 host

2001:DB8:0:6::6 any
Applying an IPv6 ACL to the Virtual Terminal Line
SUMMARY STEPS
1. enable
3. line [aux| console| tty| vty] line-number[ending-line-number]
4. ipv6 access-class ipv6-access-list-name {in| out}
DETAILED STEPS

Device> enable
1111
Configuration Examples for IPv6 Access Control Lists

Example:
Step 3 line [aux| console| tty| vty] Identifies a specific line for configuration and enters line
line-number[ending-line-number] configuration mode.
Example: • In this example, the vty keyword is used to specify the
virtual terminal lines for remote console access.
Device(config)# line vty 0 4
Step 4 ipv6 access-class ipv6-access-list-name {in| out} Filters incoming and outgoing connections to and from the
device based on an IPv6 ACL.
Example:
Device(config-line)# ipv6 access-class cisco in
Configuration Examples for IPv6 Access Control Lists

Example: Verifying IPv6 ACL Configuration
In this example, the show ipv6 access-list command is used to verify that IPv6 ACLs are configured
correctly:
Device> show ipv6 access-list
IPv6 access list inbound

permit tcp any any eq bgp (8 matches) sequence 10
permit tcp any any eq telnet (15 matches) sequence 20
permit udp any any sequence 30
IPv6 access list Virtual-Access2.1#427819008151 (per-user)

permit tcp host 2001:DB8:1::32 eq bgp host 2001:DB8:2::32 eq 11000 sequence 1
permit tcp host 2001:DB8:1::32 eq telnet host 2001:DB8:2::32 eq 11001 sequence 2
Example: Creating and Applying an IPv6 ACL

The following example shows how to restrict HTTP access to certain hours during the day and log any activity
outside of the permitted hours:

Device(config)# time-range lunchtime
Device(config-time-range)# periodic weekdays 12:00 to 13:00
Device(config-time-range)# exit
Device(config)# ipv6 access-list INBOUND
Device(config-ipv6-acl)# permit tcp any any eq www time-range lunchtime
Device(config-ipv6-acl)# deny tcp any any eq www log-input
Device(config-ipv6-acl)# permit tcp 2001:DB8::/32 any
1112
Example: Controlling Access to a vty
Device(config-ipv6-acl)# permit udp 2001:DB8::/32 any

Device(config-ipv6-acl)# end
Example: Controlling Access to a vty

In the following example, incoming connections to the virtual terminal lines 0 to 4 are filtered based on the
IPv6 access list named acl1:
ipv6 access-list acl1

permit ipv6 host 2001:DB8:0:4::2/32 any
!
line vty 0 4
ipv6 access-class acl1 in
Related Documents
IP access list commands Cisco IOS Security Command Reference
Configuring IP access Creating an IP Access List and Applying It to an Interface

lists
Description Link

Feature Information for IPv6 Access Control Lists

1113
Feature Information for IPv6 Access Control Lists
Table 195: Feature Information for IPv6 Access Control Lists
IPv6 Access Lists Cisco IOS XE Fuji This feature was integrated into Cisco IOS XE Fuji 16.7.1 on
16.7.1 the Cisco cBR Series Converged Broadband Routers.
1114
CHAPTER 79
IPv6 Template ACL
When user profiles are configured using vendor-specific attribute (VSA) Cisco AV-pairs, similar per-user
IPv6 ACLs may be replaced by a single template ACL. That is, one ACL represents many similar ACLs. By
using IPv6 template ACLs, you can increase the total number of per-user ACLs while minimizing the memory
and Ternary Content Addressable Memory (TCAM) resources needed to support the ACLs.
The IPv6 Template ACL feature can create templates using the following ACL fields:
• IPv6 source and destination addresses
• TCP and UDP, including all associated ports (0 through 65535)
• ICMP neighbor discovery advertisements and solicitations
• IPv6 DSCP with specified DSCP values
ACL names are dynamically generated by this feature; for example:

• 6Temp_#152875854573--Example of a dynamically generated template name for a template ACL parent
• Virtual-Access2.32135#152875854573--Example of a child ACL or an ACL that has not yet been made
part of a template.
Contents
• Information About IPv6 ACL—Template ACL, on page 1117
• How to Enable IPv6 ACL—Template ACL, on page 1117
• Configuration Examples for IPv6 ACL—Template ACL, on page 1118
• Feature Information for IPv6 Template ACL, on page 1120
1115
Digital PICs:

Module:

Modules:
1116
Information About IPv6 ACL—Template ACL
line card reload.
Information About IPv6 ACL—Template ACL

IPv6 Template ACL
When user profiles are configured using vendor-specific attribute (VSA) Cisco AV-pairs, similar per-user
IPv6 ACLs may be replaced by a single template ACL. That is, one ACL represents many similar ACLs. By
using IPv6 template ACLs, you can increase the total number of per-user ACLs while minimizing the memory
and Ternary Content Addressable Memory (TCAM) resources needed to support the ACLs.
The IPv6 Template ACL feature can create templates using the following ACL fields:
• IPv6 source and destination addresses
• TCP and UDP, including all associated ports (0 through 65535)
• ICMP neighbor discovery advertisements and solicitations
• IPv6 DSCP with specified DSCP values
ACL names are dynamically generated by this feature; for example:

• 6Temp_#152875854573--Example of a dynamically generated template name for a template ACL parent
• Virtual-Access2.32135#152875854573--Example of a child ACL or an ACL that has not yet been made
part of a template.
How to Enable IPv6 ACL—Template ACL

Enabling IPv6 Template Processing
SUMMARY STEPS
1. enable
3. access-list template [number-of-rules]
4. exit
5. show access-list template {summary | aclname | exceed number | tree}
1117
Configuration Examples for IPv6 ACL—Template ACL
DETAILED STEPS

Router> enable

Example:
Step 3 access-list template [number-of-rules] Enables template ACL processing.

Example: • The example in this task specifies that ACLs with 50
or fewer rules will be considered for template ACL
Router(config)# access-list template 50 status.
• The number-of-rules argument default is 100.
Step 4 exit Exits global configuration mode and places the router in
Example:
Step 5 show access-list template {summary | aclname | exceed Displays information about ACL templates.
number | tree}
Example:
Router# show access-list template summary
Configuration Examples for IPv6 ACL—Template ACL

Example: IPv6 Template ACL Processing
In this example, the contents of ACL1 and ACL2 are the same, but the names are different:
ipv6 access-list extended ACL1 (PeerIP: 2001:1::1/64)

permit igmp any 2003:1::1/64
permit icmp 2002:5::B/64 any
permit udp any host 2004:1::5
permit udp any host 2002:2BC::a
permit icmp host 2001:BC::7 host 2003:3::7
ipv6 access-list extended ACL2 (PeerIP: 2007:2::7/64)
1118

The template for these ACLs is as follows:
ipv6 access-list extended Template_1

Related Documents
Standards and RFCs
Standard/RFC Title
RFCs for IPv6

IPv6 RFCs
MIBs
To locate and download MIBs for selected platforms, Cisco IOS releases, and feature sets, use Cisco MIB
Locator found at the following URL:
Description Link

1119
Feature Information for IPv6 Template ACL
Feature Information for IPv6 Template ACL

Table 197: Feature Information for IPv6 Template ACL
IPv6 Access Lists Cisco IOS XE Fuji This feature was integrated into Cisco IOS XE Fuji 16.7.1 on
1120
CHAPTER 80
IPv6 ACL Extensions for Hop by Hop Filtering
The IPv6 ACL Extensions for Hop by Hop Filtering feature allows you to control IPv6 traffic that might
contain hop-by-hop extension headers. You can configure an access control list (ACL) to deny all hop-by-hop
traffic or to selectively permit traffic based on protocol.
Contents
• Information About IPv6 ACL Extensions for Hop by Hop Filtering, on page 1123
• How to Configure IPv6 ACL Extensions for Hop by Hop Filtering, on page 1123
• Configuration Example for IPv6 ACL Extensions for Hop by Hop Filtering, on page 1124
• Feature Information for IPv6 ACL Extensions for Hop by Hop Filtering, on page 1126
1121
Digital PICs:

Module:

Modules:
line card reload.
1122
Information About IPv6 ACL Extensions for Hop by Hop Filtering
Information About IPv6 ACL Extensions for Hop by Hop Filtering

ACLs and Traffic Forwarding
IPv6 access control lists (ACLs) determine what traffic is blocked and what traffic is forwarded at device
interfaces. ACLs allow filtering based on source and destination addresses, inbound and outbound to a specific
interface. Use the ipv6 access-list command to define an IPv6 ACL, and the deny and permit commands
to configure its conditions.
The IPv6 ACL Extensions for Hop by Hop Filtering feature implements RFC 2460 to support traffic filtering
in any upper-layer protocol type.
How to Configure IPv6 ACL Extensions for Hop by Hop Filtering

Configuring IPv6 ACL Extensions for Hop by Hop Filtering
SUMMARY STEPS
1. enable
4. permit protocol {source-ipv6-prefix/prefix-length | any | host source-ipv6-address | auth} [operator
[port-number]] {destination-ipv6-prefix/prefix-length | any | host destination-ipv6-address | auth}
[operator [port-number]] [dest-option-type [header-number | header-type]] [dscp value] [flow-label
value] [fragments] [hbh] [log] [log-input] [mobility] [mobility-type [mh-number | mh-type]] [reflect
name [timeout value]] [routing] [routing-type routing-number] [sequence value] [time-range name]
5. deny protocol {source-ipv6-prefix/prefix-length | any | host source-ipv6-address | auth} [operator
[port-number]] {destination-ipv6-prefix/prefix-length | any | host destination-ipv6-address | auth}
[operator [port-number]] [dest-option-type [header-number | header-type]] [dscp value] [flow-label
value] [fragments] [hbh] [log] [log-input] [mobility] [mobility-type [mh-number | mh-type]] [routing]
[routing-type routing-number] [sequence value] [time-range name] [undetermined-transport]
6. end
DETAILED STEPS

Device> enable

Example:
1123
Configuration Example for IPv6 ACL Extensions for Hop by Hop Filtering

Step 3 ipv6 access-list access-list-name Defines an IPv6 ACL and enters IPv6 access list
configuration mode.
Example:
Device(config)# ipv6 access-list hbh-acl
Step 4 permit protocol {source-ipv6-prefix/prefix-length | any | Sets permit conditions for the IPv6 ACL.
host source-ipv6-address | auth} [operator [port-number]]
destination-ipv6-address | auth} [operator [port-number]]
[dest-option-type [header-number | header-type]] [dscp
value] [flow-label value] [fragments] [hbh] [log]
[log-input] [mobility] [mobility-type [mh-number |
mh-type]] [reflect name [timeout value]] [routing]
[routing-type routing-number] [sequence value]
[time-range name]
Example:
Device(config-ipv6-acl)# permit icmp any any
dest-option-type
Step 5 deny protocol {source-ipv6-prefix/prefix-length | any | Sets deny conditions for the IPv6 ACL.
host source-ipv6-address | auth} [operator [port-number]]
destination-ipv6-address | auth} [operator [port-number]]
[dest-option-type [header-number | header-type]] [dscp
value] [flow-label value] [fragments] [hbh] [log]
[log-input] [mobility] [mobility-type [mh-number |
mh-type]] [routing] [routing-type routing-number]
[sequence value] [time-range name]
[undetermined-transport]
Example:
Device(config-ipv6-acl)# deny icmp any any
dest-option-type
Step 6 end Returns to privileged EXEC configuration mode.

Example:
Device (config-ipv6-acl)# end
Configuration Example for IPv6 ACL Extensions for Hop by Hop

Filtering
Example: IPv6 ACL Extensions for Hop by Hop Filtering
Device(config)# ipv6 access-list hbh_acl
Device(config-ipv6-acl)# permit tcp any any hbh
1124
Device(config-ipv6-acl)# permit tcp any any

Device(config-ipv6-acl)# permit udp any any
Device(config-ipv6-acl)# permit udp any any hbh
Device(config-ipv6-acl)# permit hbh any any
Device(config-ipv6-acl)# permit any any
Device(config-ipv6-acl)# hardware statistics
Device(config-ipv6-acl)# exit
! Assign an IP address and add the ACL on the interface.

Device(config-if)# ipv6 address 1001::1/64
Device(config-if)# ipv6 traffic-filter hbh_acl in
Device(config-if)# exit
Device# clear counters
Clear "show interface" counters on all interfaces [confirm]
Device#
! Verify the configurations.
Device# show running-config interface TenGigabitEthernet4/1/0

!
no switchport
ipv6 traffic-filter hbh_acl
end
Related Documents
Standards and RFCs
Standard/RFC Title
RFCs for IPv6

IPv6 RFCs
1125
Feature Information for IPv6 ACL Extensions for Hop by Hop Filtering
MIBs
To locate and download MIBs for selected platforms, Cisco IOS releases, and feature sets, use Cisco MIB
Locator found at the following URL:
Description Link

Feature Information for IPv6 ACL Extensions for Hop by Hop

Filtering
Table 199: Feature Information for IPv6 ACL Extensions for Hop by Hop Filtering
IPv6 access Cisco IOS XE Fuji This feature was integrated into Cisco IOS XE Fuji 16.7.1 on
lists 16.7.1 theCisco cBR Series Converged Broadband Routers.
1126
PA R T VIII
Application—Voice and Video Configuration
• Unique Device Identifier Retrieval , on page 1129
• Advanced-Mode DOCSIS Set-Top Gateway 1.2 for the Cisco CMTS Routers, on page 1137
• Cisco Network Registrar for the Cisco CMTS Routers, on page 1167
CHAPTER 81
Unique Device Identifier Retrieval
The Unique Device Identifier (UDI) Retrieval feature provides the ability to retrieve and display the UDI
information from any Cisco product that has electronically stored such identity information.
Contents
• Unique Device Identifier Overview, on page 1131
• Benefits of the Unique Device Identifier Retrieval Feature, on page 1131
• Retrieving the Unique Device Identifier, on page 1131
• Troubleshooting Tips, on page 1134
• Feature Information for Unique Device Identifier Retrieval , on page 1135
1129
Digital PICs:

Module:

Modules:
line card reload.
1130
Unique Device Identifier Overview
Unique Device Identifier Overview

Each identifiable product is an entity, as defined by the Entity MIB (RFC-2737) and its supporting documents.
Some entities, such as a chassis, will have sub-entities like slots. An Ethernet switch might be a member of
a super-entity like a stack. Most Cisco entities that can be ordered leave the factory with an assigned UDI.
The UDI information is printed on a label that is affixed to the physical hardware device, and it is also stored
electronically on the device in order to facilitate remote retrieval.
A UDI consists of the following elements:
• Product identifier (PID)
• Version identifier (VID)
• Serial number (SN)
The PID is the name by which the product can be ordered; it has been historically called the “Product Name”
or “Part Number.” This is the identifier that one would use to order an exact replacement part.
The VID is the version of the product. Whenever a product has been revised, the VID will be incremented.
The VID is incremented according to a rigorous process derived from Telcordia GR-209-CORE, an industry
guideline that governs product change notices.
The SN is the vendor-unique serialization of the product. Each manufactured product will carry a unique serial
number assigned at the factory, which cannot be changed in the field. This is the means by which to identify
an individual, specific instance of a product.
Benefits of the Unique Device Identifier Retrieval Feature

• Identifies individual Cisco products in your networks.
• Reduces operating expenses for asset management through simple, cross-platform, consistent identification
of Cisco products.
• Identifies PIDs for replaceable products.
• Facilitates discovery of products subject to recall or revision.
• Automates Cisco product inventory (capital and asset management).
• Provides a mechanism to determine the entitlement level of a Cisco product for repair and replacement
service.
Product Item Descriptor for Cable Products
For information on the Product Item Descriptor (PID), see the product hardware installation guide available
on Cisco.com.
Retrieving the Unique Device Identifier

To use UDI retrieval, the Cisco product in use must be UDI-enabled. A UDI-enabled Cisco product supports
five required Entity MIB objects. The five Entity MIB v2 (RFC-2737) objects are:
• entPhysicalName
• entPhysicalDescr
• entPhysicalModelName
1131
• entPhysicalHardwareRev
• entPhysicalSerialNum
Although the show inventory command may be available, using that command on devices that are not
UDI-enabled will likely produce no output.
Enter the show inventory command to retrieve and display information about all of the Cisco products installed
in the networking device that are assigned a PID, VID, and SN. If a Cisco entity is not assigned a PID, that
entity is not retrieved or displayed.
Router# show inventory
NAME: "Chassis", DESCR: "Cisco cBR-8 CCAP Chassis"

PID: CBR-8-CCAP-CHASS , VID: V01, SN: FXS1739Q0PR
NAME: "clc 3", DESCR: "Cisco cBR CCAP Line Card"

PID: CBR-CCAP-LC-40G , VID: V01, SN: TEST1234567
NAME: "Cable PHY Module", DESCR: "CLC Downstream PHY Module 3/0"
PID: CBR-D30-DS-MOD , VID: V01, SN: CAT1725E1BZ
NAME: "Cable PHY Module", DESCR: "CLC Downstream PHY Module 3/1"
PID: CBR-D30-DS-MOD , VID: V01, SN: CAT1725E1AT
NAME: "Cable PHY Module", DESCR: "CLC Upstream PHY Module 3/2"
PID: CBR-D30-US-MOD , VID: V01, SN: CAT1717E0FF
NAME: "sup 1", DESCR: "Cisco cBR CCAP Supervisor Card"

PID: CBR-CCAP-SUP-60G , VID: V01, SN: CAT1824E0MT
NAME: "harddisk 5/1", DESCR: "Hard Disk"

PID: UGB88RTB100HE3-BCU-DID, VID: , SN: 11000066829
NAME: "sup-pic 5/1", DESCR: "Cisco cBR CCAP Supervisor Card PIC"
PID: CBR-SUP-8X10G-PIC , VID: V01, SN: CAT1720E0F4
NAME: "SFP+ module 5/1/0", DESCR: "iNSI xcvr"

PID: SFP+ 10GBASE-SR , VID: A , SN: FNS172720X6

PID: SFP+ 10GBASE-LR , VID: A , SN: UGT085P

PID: SFP+ 10GBASE-LR , VID: A , SN: UGT087Z

PID: SFP+ 10GBASE-SR , VID: G4.1, SN: AVD1729A38T

PID: 10GE ZR , VID: A , SN: FNS11300AUH
NAME: "Power Supply Module 0", DESCR: "Cisco cBR CCAP AC Power Supply"
PID: PWR-3KW-AC-V2 , VID: V02, SN: DTM17370345
NAME: "Power Supply Module 2", DESCR: "Cisco cBR CCAP AC Power Supply"
PID: PWR-3KW-AC-V2 , VID: V02, SN: DTM173702KF
For diagnostic purposes, the show inventory command can be used with the raw keyword to display every
RFC 2737 entity including those without a PID, UDI, or other physical identification.
1132
Note The raw keyword option is primarily intended for troubleshooting problems with the show inventory command
itself.
Router# show inventory raw
NAME: "Chassis", DESCR: "Cisco cBR-8 CCAP Chassis"

PID: CBR-8-CCAP-CHASS , VID: V01, SN: FXS1739Q0PR
NAME: "slot 0/0", DESCR: "Chassis Slot"

PID: , VID: , SN:

PID: , VID: , SN:

PID: , VID: , SN:

PID: , VID: , SN:

PID: , VID: , SN:

PID: , VID: , SN:

PID: , VID: , SN:
NAME: "clc 3", DESCR: "Cisco cBR CCAP Line Card"

PID: CBR-CCAP-LC-40G , VID: V01, SN: TEST1234567
NAME: "12_CUR: Sens 3/0", DESCR: "12_CUR: Sens"

PID: , VID: , SN:
NAME: "12_CUR: Vin 3/1", DESCR: "12_CUR: Vin"

PID: , VID: , SN:
NAME: "12_CUR: ADin 3/2", DESCR: "12_CUR: ADin"

PID: , VID: , SN:
NAME: "G0_CUR: Sens 3/3", DESCR: "G0_CUR: Sens"

PID: , VID: , SN:
NAME: "G0_CUR: Vin 3/4", DESCR: "G0_CUR: Vin"

PID: , VID: , SN:
NAME: "G0_CUR: ADin 3/5", DESCR: "G0_CUR: ADin"

PID: , VID: , SN:
NAME: "G1_CUR: Sens 3/6", DESCR: "G1_CUR: Sens"

PID: , VID: , SN:
NAME: "G1_CUR: Vin 3/7", DESCR: "G1_CUR: Vin"

PID: , VID: , SN:
NAME: "G1_CUR: ADin 3/8", DESCR: "G1_CUR: ADin"

PID: , VID: , SN:
NAME: "LB_CUR: Sens 3/9", DESCR: "LB_CUR: Sens"
1133
PID: , VID: , SN:
NAME: "LB_CUR: Vin 3/10", DESCR: "LB_CUR: Vin"

PID: , VID: , SN:
NAME: "LB_CUR: ADin 3/11", DESCR: "LB_CUR: ADin"

PID: , VID: , SN:
NAME: "Temp: CAPRICA 3/12", DESCR: "Temp: CAPRICA"

PID: , VID: , SN:
NAME: "Temp: BASESTAR 3/13", DESCR: "Temp: BASESTAR"

PID: , VID: , SN:
NAME: "Temp: RAIDER 3/14", DESCR: "Temp: RAIDER"

PID: , VID: , SN:
NAME: "Temp: CPU 3/15", DESCR: "Temp: CPU"

PID: , VID: , SN:
NAME: "Temp: INLET 3/16", DESCR: "Temp: INLET"

PID: , VID: , SN:
NAME: "Temp: OUTLET 3/17", DESCR: "Temp: OUTLET"

PID: , VID: , SN:
NAME: "Temp: DIGITAL 3/18", DESCR: "Temp: DIGITAL"

PID: , VID: , SN:
NAME: "Temp: UPX 3/19", DESCR: "Temp: UPX"

PID: , VID: , SN:
If any of the Cisco products do not have an assigned PID, the output may display incorrect PIDs and the VID
and SN elements may be missing, as in the following example.
NAME: "POS3/0/0", DESCR: "Skystone 4302 Sonet Framer"
PID: FastEthernet, VID: , SN:
NAME: "Serial1/0", DESCR: "M4T"
PID: M4T , VID: , SN:
In the sample output, the PID is exactly the same as the product description. The UDI is designed for use with
new Cisco products that have a PID assigned. UDI information on older Cisco products is not always reliable.
1134
Related Documents

Information about managing configuration files Cisco IOS Configuration Fundamentals Configuration
Guide
Commands for showing interface statistics Cisco IOS Interface Command Reference
Standards and RFCs
Standard/RFC Title
RFC 2737 Entity MIB (Version 2)
MIBs
MIB MIBs Link

CISCO-ENTITY-ASSET-MIB To locate and download MIBs for selected platforms, Cisco IOS releases,
and feature sets, use Cisco MIB Locator found at the following URL:
Description Link
Feature Information for Unique Device Identifier Retrieval

1135
Feature Information for Unique Device Identifier Retrieval
Table 201: Feature Information for Unique Device Identifier Retrieval
Unique Device Identifier Cisco IOS XE Everest This feature was integrated into Cisco IOS XE
Retrieval 16.6.1 Everest 16.6.1 on the Cisco cBR Series Converged
Broadband Routers.
1136
CHAPTER 82
Advanced-Mode DOCSIS Set-Top Gateway 1.2
for the Cisco CMTS Routers
The Advanced-Mode DOCSIS Set-Top Gateway (A-DSG) Issue 1.2 introduces support for the latest DOCSIS
Set-Top specification from CableLabs™, to include the following enhancements:
• DOCSIS Set-top Gateway (DSG) Interface Specification
• A-DSG 1.2 introduces support for the DOCS-DSG-IF MIB.
Cisco A-DSG 1.2 is certified by CableLabs™, and is a powerful tool in support of latest industry innovations.
A-DSG 1.2 offers substantial support for enhanced DOCSIS implementation in the broadband cable
environment. The set-top box (STB) dynamically learns the overall environment from the Cisco CMTS router,
to include MAC address, traffic management rules, and classifiers.
Contents
• Prerequisites for Advanced-Mode DSG Issue 1.2, on page 1139
• Restrictions for Advanced-Mode DSG Issue 1.2, on page 1139
• Information About Advanced-Mode DSG Issue 1.2, on page 1140
• How to Configure Advanced-Mode DSG Issue 1.2, on page 1142
• How to Monitor and Debug the Advanced-mode DOCSIS Set-Top Gateway Feature, on page 1158
• Configuration Examples for Advanced-Mode DSG, on page 1161
• Feature Information for Advanced-Mode DSG 1.2 for the Cisco CMTS Routers, on page 1164
1137
Digital PICs:

Module:

Modules:
1138
Prerequisites for Advanced-Mode DSG Issue 1.2
line card reload.
Prerequisites for Advanced-Mode DSG Issue 1.2

No special equipment or software is needed to use the Advanced-Mode DSG Issue 1.2 feature.
Restrictions for Advanced-Mode DSG Issue 1.2

This section contains restrictions that are specific to A-DSG 1.2 on a Cisco CMTS router.
DSG Configuration File Transfer Operations

DSG 1.2 does not support the copying of a DSG configuration file from a TFTP server, file system, or bootflash
to the running configuration.
Multicast Configuration Restrictions

IP multicasting must be configured for correct operation of A-DSG 1.2. Specifically, IP multicast routing
must be set in global configuration. Also, IP PIM must be configured on all bundle interfaces of cable interfaces
that are to carry multicast traffic.
See the Configuring the Default Multicast Quality of Service, on page 1142 and the Configuring IP Multicast
Operations, on page 1150 for additional Multicast information and global configurations supporting DSG.
NAT for DSG Unicast-only Mapping

A-DSG 1.2 supports multicast IP addressing. However, it also supports unicast IP destination addresses. On
the Cisco cBR-8 router, DSG 1.2 support is provided with the configuration of Network Address Translation
(NAT) on the router, to include these settings:
• WAN interface(s) are configured with the ip nat outside command.
• Cable interface(s) are configured with the ip nat inside command.
• For each mapping, additional configuration includes the source static multicast IP address and the unicast
IP address.
The unicast IP address is the unicast destination IP address of the DSG packets arriving at the Cisco CMTS
router. The multicast IP address is the new destination IP address that is configured to map to one or a set of
DSG tunnels.
1139
PIM and SSM for Multicast
PIM and SSM for Multicast

When using Source Specific Multicast (SSM) operation in conjunction with A-DSG 1.2, the following
system-wide configuration command must be specified:
• ip pim ssm
Refer to the Configuring IP Multicast Operations, on page 1150.
Subinterfaces
A-DSG 1.2 supports subinterfaces on the Cisco CMTS router.
Information About Advanced-Mode DSG Issue 1.2

A-DSG 1.2 offers these new or enhanced capabilities:
• A-DSG client and agent modes
• Advanced-mode MIBs supporting DSG 1.2, including the DOCS-DSG-IF-MIB
• Advanced-mode tunnels with increased security
• Cable interface bundling through virtual interface bundling
• Downstream Channel Descriptor
• IP multicast support
• Quality of Service (QoS)
DSG 1.2 Clients and Agents

A-DSG 1.2 supports the DSG client and agent functions outlined by the CableLabs™ DOCSIS Set-top Gateway
(DSG) Interface Specification , CM-SP-DSG-I05-050812.
FQDN Support
You can specify either a fully-qualified domain name (FQDN) or IP address for A-DSG classifier multicast
group and source addresses using the cable dsg cfr command in global configuration mode. We recommend
that you use an FQDN to avoid modification of multicast group and source addresses when network changes
are implemented.
This feature allows you to use a hostname (FQDN) in place of the source IP address using the cable dsg cfr
command. For example, you have two A-DSG tunnel servers, in two locations, sending multicast traffic to
the same multicast address. In this scenario, you can specify a hostname for the source IP address and let the
DNS server determine which source is sending the multicast traffic.
If you configure an A-DSG classifier with a hostname, the Cisco CMTS router immediately verifies if the
hostname can be resolved against an IP address using the local host cache. If not, the router does not enable
the classifier until the hostname is resolved. If the hostname cannot be resolved locally, the router performs
a DNS query to verify the DSG classifiers.
The FQDN format does not support static Internet Group Management Protocol (IGMP) join requests initiated
on the Cisco CMTS router. The IGMP static group IP address created automatically under a bundle interface
at the time of A-DSG configuration is not displayed in the show running-config interface command output.
1140
DSG Name Process and DNS Query
To display the A-DSG static groups configured under a bundle interface, use the show cable dsg static-group
bundle command in privileged EXEC mode.
DSG Name Process and DNS Query

Every DNS record contains a time to live (TTL) value set by the server administrator, and this may vary from
seconds to weeks. The DSG name process supersedes the TTL value criterion to update A-DSG classifiers
on the Cisco CMTS router.
The DSG name process enables the Cisco CMTS router to query the DNS server for faster classifier updates.
To enable the Cisco CMTS router to perform a DNS query for an A-DSG classifier verification, you must
configure one or more DNS servers using the ip name-server command in global configuration mode. You
can also specify the DNS query interval using the cable dsg name-update-interval command in global
configuration mode.
During a Cisco IOS software reload or a route processor switchover, the router may fail to query the DNS
server if the interfaces are down, and the router may not wait for the interval specified using the cable dsg
name-update-interval command to perform a DNS query. In this case, for an unresolved hostname, the router
automatically performs a DNS query based on a system-defined (15 seconds) interval to facilitate faster DSG
classifier updates. You cannot change the system-defined interval.
A-DSG Forwarding on the Primary Channel

You can disable A-DSG forwarding per primary capable interface using the cable downstream dsg disable
command in interface configuration mode. Primary capable interfaces include modular, integrated cable
interfaces, and Cisco cBR-8 CCAP cable interfaces.
For example, assume the cable interface 7/1/1 has A-DSG enabled and has four modular channels attached
to it. However, you want A-DSG forwarding enabled only on two of these four modular channels. You can
exclude the channels of your choice using the cable downstream dsg disable command. For details on how
to disable modular channels, see the Disabling A-DSG Forwarding on the Primary Channel, on page 1158.
Note If A-DSG downstream forwarding is disabled on a primary capable interface, the router does not create
multicast service flows on the primary capable interface and stops sending Downstream Channel Descriptor
(DCD) messages.
DOCSIS 3.0 DSG MDF Support

Support for DOCSIS 3.0 DSG Multicast DSID Forwarding (MDF) is introduced using DSG DA-to-DSID
Association Entry type, length, value (TLV 13) in the MAC domain descriptor (MDD) message to communicate
the association between a downstream service identifier (DSID) and a group MAC address used for DSG
tunnel traffic. This is automatically supported on the Cisco CMTS router.
DOCSIS 2.0 hybrid CMs and DOCSIS 3.0 CMs use Dynamic Bonding Change (DBC) to get DSID information
from the Cisco CMTS router, whereas DOCSIS 2.0 DSG hybrid embedded CMs and DOCSIS 3.0 DSG
embedded CMs get DSID information from the Cisco CMTS router through MDD messages.
To disable MDF capability on all DSG embedded cable modems, including DOCSIS 3.0 DSG and DOCSIS
2.0 DSG hybrid modems, use the cable multicast mdf-disable command with the dsg keyword in global
configuration mode.
1141
Source Specific Multicast Mapping
Source Specific Multicast Mapping

Source Specific Multicast (SSM) is a datagram delivery model that best supports one-to-many applications,
also known as broadcast applications. SSM is a core networking technology for the Cisco implementation of
IP multicast solutions targeted for audio and video broadcast application environments.
The following two Cisco IOS components together support the implementation of SSM:
• Protocol Independent Multicast source-specific mode (PIM-SSM)
• Internet Group Management Protocol Version 3 (IGMPv3)
SSM mapping can be configured on Cisco CMTS routers.
For details on how to configure SSM mapping on a Cisco CMTS router, see the Source Specific Multicast
(SSM) Mapping feature guide.
How to Configure Advanced-Mode DSG Issue 1.2

Advanced-mode DSG Issue 1.2 entails support for DSG tunnel configuration, to include global, WAN-side,
and interface-level settings in support of Multicast.
Configuring the Default Multicast Quality of Service

According to DOCSIS 3.0, you must configure the default multicast quality of service (MQoS) when using
the MQoS. This also applies to the DSG, which uses the MQoS by associating a service class name with the
tunnel.
If the default MQoS is not configured, the DSG tunnel service class configuration is rejected. Similarly, if no
DSG tunnel uses the MQoS, you are prompted to remove the default MQoS.
The CMTS selects the primary downstream channel to forward the multicast traffic when the default MQoS
is configured and there is no matching MQoS group configuration. Otherwise, the wideband interface is used
to forward the multicast traffic.
Procedure

Router> enable

Example:
Example:
Router(config)#
1142
Configuring DSG OPS Under MAC Domain Profile

Step 3 cable multicast group-qos default scn service-class-name Configures a service class name for the QoS profile.
aggregate
Example:
Router(config)# cable multicast group-qos default

scn name1 aggregate

Example:
Router(config)# end
What to do next
Note If you configure or remove the default MQoS while the CMTS is sending multicast traffic, duplicate traffic
is generated for approximately 3 minutes (or 3 times the query interval).

The DOCSIS Set-Top Gateway (DSG) OPS CLI automatically creates the DSG Tunnel Group (TG) channels
to MAC domain when you apply the MAC domain profile with the DSG configuration. Use the following
commands to configure DSG globally.
cable dsg client-list XXX id-index Y freq 470000
cable dsg vendor-param X vendor Y oui Z
cable dsg timer X Tdsg1 2 Tdsg2 150 Tdsg3 10 Tdsg4 150
cable dsg tg XXX
cable dsg tg XXX default-prority Y
cable dsg tg XXX channel Y priotity Z
cable dsg tg XXX channel Y ucid Z
cable dsg tg XXX channel Y vendor-param Z
The DSG TG channel generated with the MAC domain profile cannot be removed globally.
Router(config)#no cable dsg tg 4500 ch 1
% tg 4500 channel 1 is generated by profile,would not remove it.
CBR(config)#
Configure DSG Under Service Group Profile

Router(config)#cable profile service-group Y
Router(config-profile-sg)#mac-domain 0 profile MD0
Router(config-profile-sg-md)# cable downstream dsg ?
chan-list DSG Channel List Setting
dcd-enable Enable DSG DCD messages when no enabled rules/tunnels
tg DSG Tunnel group
timer DSG Timer Setting
vendor-param DSG vendor specific parameters
1143
Apply Service Group Under Fiber Node
Router(config)#cable fiber-node X
Router(config-fiber-node)#service-group profile Y
Verify DSG TG Configuration

Router#show cabl dsg tg
TG Chan TG Rule Vendor UCID Service-group Profile
id id state I/F pri Param list Profile chan state
----- ----- ----- ------- ---- ------ ------ -------------- ----------
2000 1 en C1/0/0 0 SG1 en
4500 1 en C1/0/0 2 2 1 2 SG1 dis
4500 2 en 0 -- --
Verify Service Group Profile

show cable profile service-group <name>
Remove DSG
You can remove the OPS commands by CLI under the MAC domain. Use the following commands:
Router#interface Cable1/0/1
Router(config-if)#no cable downstream dsg tg 4500 channel 1
Tunnel group 4500 channel 1 is configured by profile.
Do you want to remove it?[confirm]
(config-if)#
or use the folowing command: no cable downstream dsg tg 4500 channel 1 force
Re-apply DSG Configuration

Router#interface Cable1/0/1
Router(config-if)#cable downstream dsg tg 4500 channel 1
Router(config-if)#
Example
cable dsg timer 1 Tdsg1 2 Tdsg2 600 Tdsg3 300 Tdsg4 1800
cable dsg chan-list 111 index 1 freq 47000000
cable dsg vendor-param 2 vendor 2 oui 00000B
cable dsg tg 4500
cable dsg tg 4500 channel 1
cable profile service-group SG1

cable bundle 255
mac-domain 0 profile MD1
downstream sg-channel 2-3 profile DS1 upstream 2-3
cable downstream dsg chan-list 111
cable downstream dsg timer 1
cable downstream dsg vendor-param 2
cable downstream dsg tg 4500
cable downstream dsg tg 4500 priority 2
cable downstream dsg tg 4500 vendor-param 2
cable downstream dsg tg 4500 ucid 1 2
cable fiber-node 1
downstream sg-channel 0 15 integrated-cable 1/0/1 rf-channel 0 15
1144
Configuring Global Tunnel Group Settings for Advanced-Mode DSG 1.2

service-group profile SG1
cable mac-domain-profile MD1
cable bundle 255
Configuring Global Tunnel Group Settings for Advanced-Mode DSG 1.2

This procedure configures global and interface-level commands on the Cisco CMTS router to enable DSG
tunnel groups. A DSG tunnel group is used to bundle some DSG channels together and associate them to a
MAC domain interface.
Global A-DSG 1.2 Tunnel Settings

This procedure sets and enables global configurations to support both A-DSG 1.2 clients and agents. Additional
procedures provide additional settings for these clients and agents.
Before you begin

When DOCSIS Set-top Gateway (DSG) is configured to have quality of service (QoS) for tunnel, ensure that
the default multicast QoS (MQoS) is also configured. For more information, see Configuring the Default
Multicast Quality of Service, on page 1142.
Note The DSG tunnel service class configuration is rejected, if default MQoS is not configured.
Procedure

Router> enable

Example:

Router(config)#
Step 3 cable dsg tggroup-id [channelchannel-id Command allows the association of a group of tunnels to
|priorityDSG-rule-priority ] [enable|disable] one or more downstream interfaces on the Cisco CMTS.
Example:
Router(config)# cable dsg tg 1 channel 1 priority

1 enable
1145
Global A-DSG 1.2 Tunnel Settings

Step 4 cabledsg tggroup-id [channel channel-id [ucid ID1 ]] Sets the upstream channel or channels to which the DSG
1.2 tunnel applies.
Example:
Router(config)# cable dsg tg 1 channel 1 ucid 1
Step 5 cable dsg tg group-id [channel channel-id [vendor-param Sets the vendor-specific parameters for upstream DSG 1.2
vendor-group-id ]] channels.
Example:
Router(config)# cable dsg tg 1 channel 1

vendor-param 1
Step 6 cable dsg vendor-param group-id vendor vendor-index Configures vendor-specific parameters for A-DSG 1.2. To
oui oui value value-in-TLV remove this configuration from the Cisco CMTS, use the
no form of this command.
Example:
Router(config)# cable dsg vendor-param 1 vendor 1

oui ABCDEA value 0101AB
Step 7 cable dsg chan-list list-index index entry-index freq freq Configures the A-DSG 1.2 downstream channel list. The
channel list is a list of DSG channels (downstream
Example:
frequencies) that set-top boxes can search to find the DSG
tunnel appropriate for their operation. To remove the
Router(config)# cable dsg chan-list 1 index 1 freq
47000000 A-DSG 1.2 channel list from the Cisco CMTS, us the no
form of this command.
Step 8 cable dsg timer inde [Tdsg1 Tdsg1 ] | [ Tdsg2 Tdsg2 ] | Configures the A-DSG 1.2 timer entry to be associated to
[Tdsg3 Tdsg3 ] | [ Tdsg4 Tdsg4 ] the downstream channel, and encoded into the Downstream
Channel Descriptor (DCD) message. To remove the cable
Example:
DSG timer from the Cisco CMTS, use the no form of this
command.
Router(config)# cable dsg timer 1 Tdsg1 1 Tdsg2 2
Tdsg3 3 Tdsg4 4

Example:
Router(config)# end
What to do next
Refer to debug and show commands in the How to Monitor and Debug the Advanced-mode DOCSIS Set-Top
Gateway Feature, on page 1158.
1146
Adding DSG Tunnel Group to a Subinterface
Adding DSG Tunnel Group to a Subinterface

This procedure adds a DSG tunnel group to a subinterface using the cable dsg tg group-id command. After
adding the DSG tunnel-group to a subinterface, appropriate IP Internet Group Management Protocol (IGMP)
static joins are created and forwarding of DSG traffic begins, if the downstream DSG is configured.
Before you begin

The downstream DSG should exist to create IGMP static joins.
Restriction You can associate a DSG tunnel group to only one subinterface within the same bundle interface.
Procedure

Router> enable

Example:

Router(config)#
Step 3 interface bundlebundle-subif-number Specifies the interface bundle and enters the subinterface
configuration mode.
Example:
Router(config)# interface bundle 11.2

Router(config-subif)#
Step 4 cable dsg tggroup-id Adds a DSG tunnel group to a subinterface.

Example:
Router(config-subif)# cable dsg tg 1

Example:
Router(config-subif)# end
Configuring the DSG Client Settings for Advanced-Mode DSG 1.2

After the global configurations and DSG client configurations are set for DSG 1.2 on the Cisco CMTS, use
the following procedure to continue DSG 1.2 client configurations.
1147
Configuring the DSG Client Settings for Advanced-Mode DSG 1.2
Restriction The in-dcd ignore option is not supported by DSG-IF-MIBS specification.
Procedure

Router> enable

Example:
Step 3 cable dsg client-list client-list-id id-index id Sets the DSG client parameters. This command is changed
{application-id app-id | ca-system-id sys-id | mac-addr from earlier Cisco IOS Releases, and for DSG 1.2, this
mac-addr | broadcast [broadcast-id ]} command specifies the optional broadcast ID to client ID
broadcast type and vendor specific parameter index.
Example:
Router(config)# cable dsg client-list 1 id-index

1 mac-addr abcd.abcd.abcd
Step 4 cable dsg client-list client-list-id id-index id Sets vendor-specific parameters for the DSG client.
[vendor-param vendor-group-id ]
Example:
Router(config-if)# cable dsg client-list 1 id-index

1 vendor-param 1
Step 5 cable dsg tunnel tunnel id mac_addr mac addr tg This command is changed to associate a tunnel group and
tunnel-group clients client-list-id [enable | disable] client-list ID to a DSG tunnel. Also, an optional QoS service
class name can be associated to the tunnel.
Example:
Note To associate a cable service class with an A-DSG
Router(config)# cable dsg tunnel mac-addr tunnel on a Cisco CMTS router, use the cable
abcd.abcd.abcd tg 1 clients 1 enable dsg tunnel srv-class command in global
configuration mode.
Step 6 cable dsg cfr cfr index [dest-ip {ipaddr |hostname}] Specifies the DSG classifier index, with optional support
[tunnel tunnel-index ][dest-port start end ]| [priority for the DCD parameter, indicating whether or not to include
priority ][src-ip {ipaddr |hostname} [src-prefix-len length the classifier in the DCD message.
]] [enable | disable] [in-dcd {yes | no | ignore}]
Note When you use the ignore option, the DSG
Example: classifier is not included in the DCD message.
Router(config)# cable dsg cfr 1 dest-ip
1148
Configuring Downstream DSG 1.2 Settings for Advanced-Mode DSG 1.2

224.225.225.225 tunnel 1 dest-port 40 50 priority
2 src-ip ciscovideo.com src-prefix-len 24 enable

Example:
Router(config)# end
Router#
What to do next
Refer to debug and show commands in the How to Monitor and Debug the Advanced-mode DOCSIS Set-Top
Gateway Feature, on page 1158.
Configuring Downstream DSG 1.2 Settings for Advanced-Mode DSG 1.2

When the global and client configurations are set for DSG 1.2 on the Cisco CMTS, use the following procedure
to continue with DSG 1.2 downstream configurations.
Procedure

Router> enable

Example:
Step 3 interface cable {slot /port |slot /subslot/port } Enters interface configuration mode.
Example:
Step 4 cable downstream dsg tg group-id [channel channel-id] Associates the DSG tunnel group to the downstream
interface. To remove this setting, use the no form of this
Example:
command.
Router(config-if)# cable downstream dsg tg 1
channel 1
1149
Configuring IP Multicast Operations

Step 5 cable downstream dsg chan-list list-index Associates the A-DSG channel list entry to a downstream
channel, to be included in the DCD message. To remove
Example:
this setting, use the no form of this command.
Router(config-if)# cable downstream dsg chan-list
2
Step 6 cable downstream dsg timer timer-index Associates the DSG timer entry to a downstream channel,
to be included in the DCD message. To remove this setting,
Example:
use the no form of this command.
Router(config-if)# cable downstream dsg timer 3
Step 7 cable downstream dsg vendor-param vsif-grp-id Associates A-DSG vendor parameters to a downstream to
be included in the DCD message. To remove this
Example:
configuration from the Cisco CMTS, use the no form of
this command.
Router(config-if)# cable downstream dsg
vendor-param 2
Step 8 cable downstream dsg [dcd-enable | dcd-disable] Enables DCD messages to be sent on a downstream channel.
This command is used when there are no enabled rules or
Example:
tunnels for A-DSG currently on the Cisco CMTS. To disable
DCD messages, use the disable form of this command.
Router(config-if)# cable downstream dsg dcd-enable

Example:
Configuring IP Multicast Operations

This section describes how to configure the operation of IP multicast transmissions on the cable and WAN
interfaces on the Cisco CMTS. You should perform this configuration on each cable interface being used for
DSG traffic and for each WAN interface that is connected to a network controller or Conditional Access (CA)
server that is forwarding IP multicast traffic.
Procedure

Example:
Step 2 ip multicast-routing Enables multicast routing on the router.

Example:
Router(config)# ip multicast-routing
1150
Enabling DNS Query and DSG Name Process

Step 3 ip pim ssm {default | range{access-list | word }} Defines the Source Specific Multicast (SSM) range of IP
multicast addresses. To disable the SSM range, use the no
Example:
form of this command.
Router(config)# ip pim ssm range 4 Note When an SSM range of IP multicast addresses
is defined by the ip pim ssm command, no
Multicast Source Discovery Protocol (MSDP)
Source-Active (SA) messages will be accepted
or originated in the SSM range.
Step 4 ip cef distributed Enables Cisco Express Forwarding (CEF) on the route
processor card. To disable CEF, use the no form of this
Example:
command.
Router(config)# ip cef distributed For additional information about the ip cef command, refer
to the following document on Cisco.com:
• Cisco IOS Switching Services Command Reference ,
Release 12.3
http://www.cisco.com/en/US/docs/ios/12_3/switch/command/reference/swtch_r.html
Step 5 interface bundle bundle-number Enters interface configuration mode for each interface
bundle being used for DSG traffic.
Example:
Step 6 ip pim {dense-mode | sparse-mode | sparse-dense-mode} Enables Protocol Independent Multicast (PIM) on the cable
interface, which is required to use the DSG feature:
Example:
Note You must configure this command on each
Router(config-if)# ip pim dense-mode interface that forwards multicast traffic.
Step 7 Repeat Step 5, on page 1151 and Step 6, on page 1151 for each
cable interface that is being used for DSG traffic. Also
repeat these steps on each W AN interface that is forwarding
IP multicast traffic from the DSG network controllers and
Conditional Access (CA) servers.
EXEC mode.
Example:
Enabling DNS Query and DSG Name Process

The DSG name process enables the Cisco CMTS router to query the DNS server for faster classifier updates.
1151
Configuring NAT to Support Unicast Messaging
Before you begin

Ensure that the IP DNS-based hostname-to-address translation is configured on the Cisco CMTS router using
the ip domain-lookup command in global configuration mode. This is configured by default, and the status
is not displayed in the running configuration.
Procedure

Example:
Step 2 ip domain-name name Sets the IP domain name that the Cisco IOS software uses
to complete unqualified host names
Example:
Router(config)# ip domain-name cisco.com
Step 3 r ip name-serveserver-address[multiple-server-addresses] Sets the server IP address.

Example:
Router(config)# ip name-server 131.108.1.111
Step 4 cable dsg name-update-intervalminutes Sets the interval to check the DNS server for any FQDN
classifier changes.
Example:
Router(config)# cable dsg name-update-interval 10

Example:
Router(config)# end

This section describes how to configure a Cisco CMTS router for Network Address Translation (NAT) to
enable the use of IP unicast addresses for DSG messaging. This allows the Cisco CMTS router to translate
incoming IP unicast addresses into the appropriate IP multicast address for the DSG traffic.
For the Cisco cBR-8 router, A-DSG 1.2 can use an external router that is close to the Cisco CMTS to support
unicast messaging. In this case, the nearby router must support NAT, and then send the address-translated
multicast IP packets to the Cisco CMTS.
Tip This procedure should be performed after the cable interface has already been configured for DSG operations,
as described in the Configuration Examples for Advanced-Mode DSG, on page 1161.
1152
Note The Cisco CMTS router supports NAT only when it is running an “IP Plus” (-i-) Cisco IOS software image.
Refer to the release notes for your Cisco IOS release for complete image availability and requirements.
Procedure

Example:
Step 2 interface wan-interface Enters interface configuration mode for the specified WAN
interface.
Example:
Router(config)# interface FastEthernet0/0
Step 3 ip nat outside Configures the WAN interface as the “outside” (public)
NAT interface.
Example:
Router(config-if)# ip nat outside
Step 4 interface bundle bundle-number Enters interface configuration mode for the specified
interface bundle.
Example:
Note This interface bundle should have previously
Router(config-if)# interface bundle 10 been configured for DSG operations.
Step 5 ip address ip-address mask secondary Configures the cable interface with an IP address and
subnet that should match the unicast address being used
Example:
for DSG traffic. This IP address and its subnet must not
be used by any other cable interfaces, cable modems, or
255.255.255.0 secondary any other types of traffic in the cable network.
Step 6 ip nat inside Configures the cable interface as the “inside” (private)
NAT interface.
Example:
Router(config-if)# ip nat inside

configuration mode.
Example:
Step 8 ip nat inside source static ip-multicast-address Maps the unicast IP address assigned to the cable interface
cable-ip-address to the multicast address that should be used for the DSG
traffic.
Example:
1153
Configuring WAN Interfaces for Multicast Operations
Router(config)# ip nat inside source static

224.3.2.1 192.168.18.2
Step 9 Repeat Step 2, on page 1153 and Step 8, on page 1153 for each
cable interface to be configured for DSG unicast traffic.
EXEC mode.
Example:
Router(config)# end
Configuring WAN Interfaces for Multicast Operations

In addition to basic WAN interface configuration on the Cisco CMTS, described in other documents, the
following WAN interface commands should be configured on the Cisco CMTS to support IP multicast
operations with A-DSG 1.2, as required.
• ip pim
• ip pim ssm
• ip cef
These commands are described in the Configuring IP Multicast Operations, on page 1150, and in the following
documents on Cisco.com.
For additional information about the ip pim command, refer to the following document on Cisco.com:
• Cisco IOS IP Command Reference, Volume 3 of 4 : Multicast, Release 12.3
http://www.cisco.com/en/US/docs/ios/12_3/ipmulti/command/reference/iprmc_r.html
For additional information about the ip pim ssm command, refer to the following document on Cisco.com:
• Cisco IOS IP Command Reference, Volume 3 of 4: Multicast , Release 12.3 T
http://www.cisco.com/en/US/docs/ios/12_3t/ip_mcast/command/reference/ip3_i2gt.html
For additional information about the ip cef command, refer to the following document on Cisco.com:
• Cisco IOS Switching Services Command Reference , Release 12.3
http://www.cisco.com/en/US/docs/ios/12_3/switch/command/reference/swtch_r.html
Configuring a Standard IP Access List for Packet Filtering

This section describes how to configure a standard IP access list so that only authorized traffic is allowed on
the cable interface.
Tip This procedure assumes a basic knowledge of how access lists use an IP address and bitmask to determine
the range of IP addresses that are allowed access. For full details on configuring access lists, see the documents
listed in the Additional References, on page 1164.
1154
Configuring a Standard IP Access List for Packet Filtering
Procedure

Example:
Step 2 access-list access-list permit group-ip-address [mask ] Creates an access list specifying that permits access to the
specific multicast address that matches the specified
Example:
group-ip-address and mask .
Router(config)# access-list 90 permit 228.1.1.1 • access-list —Number or name of a standard IP access
list. The number can range from 1 to 99 with no
default.
• group-ip-address —IP address to be used as a base for
this access list. It should be based on the group IP
address used for DSG tunnels of the interface.
• mask —(Optional) Bitmask that determines which
addresses in the group-ip-address will be allowed
access. The default is 255.255.255.255.
Step 3 access-list access-list deny group-ip-address [mask ] Configures the access list that denies access to any multicast
address that matches the specified group-ip-address and
Example:
mask .
Router(config)# access-list 90 deny 224.0.0.0 • access-list —Number or name of a standard IP access
15.255.255.255 list. The number can range from 1 to 99 with no
default.
address used for the interface’s DSG tunnels.
Step 4 access-list access-list deny any Configures the access list so that it denies access to any IP
addresses other than the ones previously configured.
Example:
Router(config)# access-list 90 deny any
Step 5 interface bundle bundle-number Enters interface configuration mode for the specified
interface bundle.
Example:
1155
Configuring a Standard IP Access List for Multicast Group Filtering

Step 6 ip access-group access-list (Optional, but recommended) Configures the interface with
the access list, so that packets are filtered by the list before
Example:
being accepted on the interface.
Router(config-if)# ip access-group 90 • access-list —Number or name of a standard IP access
list. The number can range from 1 to 99 and should be
the same list created in Step 3.
Note Standard Access lists only allow one address to

be specified in the earlier step. If you apply an
outbound access-list with only the multicast
address of the tunnel denied, then the DSG traffic
is not allowed to pass.
Note On the Cisco uBR10012 router, inbound access
lists on the cable interface do not apply to
multicast traffic, so they do not apply here. As
a result, the Cisco uBR10012 requires that you
use extended access lists that are blocked in the
outbound direction for packets originating from
the cable modem or CPE device on the network,
and destined to the multicast group. The
multicast group contains the classifiers associated
with A-DSG 1.1 rules enabled on the interface.
Step 7 end Exits interface configuration mode and returns to Privileged

EXEC mode.
Example:

This section describes how to configure a standard IP access list so that non-DOCSIS devices, such as DSG
set-top boxes, can access only the authorized multicast group addresses and DSG tunnels.
Tip This procedure assumes a basic knowledge of how access lists use an IP address and bitmask to determine
the range of IP addresses that are allowed access. For full details on configuring access lists, see the documents
listed in the Additional References, on page 1164.
Procedure

Example:
1156

Step 2 access-list access-list permit group-ip-address [mask ] Creates an access list specifying that permits access to the
specific multicast address that matches the specified
Example:
group-ip-address and mask .
Router(config)# access-list 90 permit 228.1.1.1 • access-list —Number or name of a standard IP access
list. The number can range from 1 to 99 with no
default.
Step 3 access-list access-list deny group-ip-address [mask ] Configures the access list that denies access to any multicast
address that matches the specified group-ip-address and
Example:
mask .
Router(config)# access-list 90 deny 224.0.0.0 • access-list —Number or name of a standard IP access
15.255.255.255 list. The number can range from 1 to 99 with no
default.
Step 4 access-list access-list deny any Configures the access list so that it denies access to any IP
addresses other than the ones previously configured.
Example:
Router(config)# access-list 90 deny any
Step 5 interface cable interface Enters interface configuration mode for the specified cable
interface.
Example:
Step 6 ip igmp access-group access-list [version ] (Optional, but recommended) Configures the interface to
accept traffic only from the associated access list, so that
Example:
only authorized devices are allowed to access the DSG
tunnels.
Router(config-if)# ip igmp access-group 90
• access-list —Number or name of a standard IP access
list. The number can range from 1 to 99 and should be
the same list created in Step 3.
1157
Disabling A-DSG Forwarding on the Primary Channel

• version —(Optional) Specifies the IGMP version. The
default is 2.

EXEC mode.
Example:
Disabling A-DSG Forwarding on the Primary Channel

You can disable A-DSG forwarding per primary capable interface.
Procedure

Example:
Step 2 interface modular-cable slot /subslot/port Specifies the modular cable interface and enters cable
:interface-number interface configuration mode. Variables for this command
may vary depending on the Cisco CMTS router and the
Example:
Cisco IOS-XE software release.
Router(config)# interface modular-cable 1/0/0:0
Step 3 cable downstream dsg disable Disables A-DSG forwarding and DCD messages on the
primary capable interface.
Example:
Router(config-if)# cable downstream dsg disable

Example:
How to Monitor and Debug the Advanced-mode DOCSIS Set-Top

Gateway Feature
This section describes the following commands that you can use to monitor and display information about
the Advanced-mode DOCSIS Set-Top Gateway feature:
1158
Displaying Global Configurations for Advanced-Mode DSG 1.2
Displaying Global Configurations for Advanced-Mode DSG 1.2

The following commands display globally-configured or interface-level DSG settings, status, statistics, and
multiple types of DSG 1.2 tunnel information.
show cable dsg cfr

To verify all DSG classifier details, such as the classifier state, source, and destination IP addresses, use the
show cable dsg cfr command.
To verify details of a particular DSG classifier, use the show cable dsg cfr cfr-id command.
To verify the detailed output for all DSG classifiers, use the show cable dsg cfr verbose command.
To verify the detailed output for a single DSG classifier, use the show cable dsg cfr cfr-id verbose command.
show cable dsg host

To verify the mapping of the DSG hostnames and IP addresses on a Cisco CMTS router, use the show cable
dsg host command.
To verify the verbose output of the mapping of the DSG hostnames and IP addresses on a Cisco CMTS router,
use the show cable dsg host verbose command.
show cable dsg tunnel

To display tunnel MAC address, state, tunnel group id, classifiers associated to tunnel and its state, use the
show cable dsg tunnel command in privileged EXEC mode. This command also displays the number of
interfaces to which a tunnel is associated, the clients associated, and the QoS service class name for all the
configured tunnels.
To display information for a given DSG tunnel, use the show cable dsg tunnel tunnel-id command, specifying
the tunnel for which to display information.
show cable dsg tunnel tunnel-id [cfr | clients | interfaces | statistics | verbose]
• cfr—Shows DSG tunnel classifiers.
• clients—Shows DSG tunnel clients.
• interfaces—Shows DSG tunnel interfaces.
• statistics—Shows DSG tunnel statistics.
• verbose—Shows DSG tunnel detail information.
show cable dsg tg

To display the configured parameters for all DSG tunnel groups, use show cable dsg tg command.
Note The Chan state column in the show cable dsg tg command output indicates that a channel belonging to a
tunnel group is either enabled or diabled. It is possible that a tunnel group is enabled but a particular channel
in that tunnel group is disabled.
To display the configured parameters for the specified tunnel group, use show cable dsg tg tg-id channel
channel-id command.
1159
show running-config interface
To display detailed information for the specified tunnel group, use show cable dsg tg tg-id channel channel-id
verbose command.
show running-config interface

To display a tunnel group attached to a subinterface, use the show running-config interface command in
privileged EXEC mode, as shown in the example below:
Router# show running-config interface bundle 11.2

!
ip address 4.4.2.1 255.255.255.0
no ip unreachables
ip pim sparse-mode
cable dsg tg 61
end
Note The IGMP static group IP address created automatically at the time of DSG configuration is not displayed in
the show running-config interface command output.
show cable dsg static-group bundle

To verify all DSG static groups configured under a bundle interface, use the show cable dsg static-group
bundle command in privileged EXEC mode.
Displaying Interface-level Configurations for Advanced-Mode DSG 1.2

The following show commands display interface-level configurations for A-DSG 1.2.
show cable dsg tunnel interfaces

To display all interfaces and DSG rules for the associated tunnel, use the show cable dsg tunnel interfaces
command in privileged EXEC mode.
show cable dsg tunnel (tunnel-id ) interfaces
show interfaces cable dsg downstream

To display DSG downstream interface configuration information, to include the number of DSG tunnels,
classifiers, clients, and vendor-specific parameters, use the show interfaces cable dsg downstream command
in privileged EXEC mode.
show interfaces cable dsg downstream dcd

To display DCD statistics for the given downstream, use the show interfaces cable dsg downstream dcd
command in privileged EXEC mode. This command only displays DCD Type/Length/Value information if
the debug cable dsg command is previously enabled.
1160
show interfaces cable dsg downstream tg
show interfaces cable dsg downstream tg

To display DSG tunnel group parameters, and rule information applying to the tunnel group, to include tunnels
and tunnel states, classifiers, and client information, use the show interfaces cable dsg downstream tg
command in privileged EXEC mode. You can display information for a specific tunnel, if specified.
show interfaces cable dsg downstream tunnel

To display DSG tunnel information associated with the downstream, use the show interfaces cable dsg
downstream tunnel command in privileged EXEC mode.
Debugging Advanced-Mode DSG

To enable debugging for A-DSG on a Cisco CMTS router, use the debug cable dsg command in privileged
EXEC mode.
Configuration Examples for Advanced-Mode DSG

This configuration example illustrates a sample DSG network featuring these components:
• Two Cisco universal broadband routers
• IP Multicast for each DSG implementation
• Two DSG Clients for each Cisco CMTS
• Two DSG Servers (one for each Cisco CMTS)
Each Cisco CMTS is configured as follows, and the remainder of this topic describes example configurations
that apply to this architecture.
CMTS Headend 1
• DSG Server #1—Connected to Cisco CMTS via IP Multicast, with DSG Server having IP Address
12.8.8.1
• Destination IP Address for the Cisco CMTS—228.9.9.1
• DSG Tunnel Address—0105.0005.0005
• Downstream #1 Supporting two DSG Clients:
• DSG Client #1—ID 101.1.1
CMTS Headend 2
• DSG Server #2—Connected to Cisco CMTS via IP Multicast, with DSG Server having IP Address
12.8.8.2
• Destination IP Address for the Cisco CMTS—228.9.9.2
• Downstream #2 Supporting two DSG Clients:
1161
Configuration Examples for Advanced-Mode DSG
Example of Two DSG Tunnels with MAC DA Substitution

In this configuration, and given the two Cisco CMTS Headends cited above, below are the two sets of DSG
rules, with each set applying to each Cisco CMTS, in respective fashion.
These settings apply to DSG #1 and two downstreams:
• DSG Rule ID 1
• DSG Client ID 101.1.1
• DSG Tunnel Address 105.5.5
These settings apply to DSG Rule #2 and two downstreams:
• DSG Rule ID 1
DSG Example with Regionalization Per Downstream

In this configuration, and given the two Cisco CMTS Headends cited earlier in this topic, below are two
downstream rules that can be configured in this architecture, for example:
• Downstream Rule #1
• DSG Rule ID #1
• DSG Client ID—101.1.1
• Downstream Rule #2
• DSG Rule ID #2
DSG Example with Regionalization Per Upstream

In this configuration, and given the two Cisco CMTS Headends cited earlier in this topic, below are two
upstream rules that can be configured in this architecture, for example:
• Upstream Rule #1
• DSG Rule ID #1
• DSG UCID Range—0 to 2
• Upstream Rule #2
• DSG Rule ID #2
• DSG UCID Range—3 to 5
1162
Example: Enabling DNS Query
Example of Two DSG Tunnels with Full Classifiers and MAC DA Substitution
In this configuration, and given the two Cisco CMTS Headends cited above, below are the two sets of DSG
rules, with each set applying to each Cisco CMTS, in respective fashion.
These settings apply to DSG #1:
• DSG Rule ID 1
• Downstreams 1 and 2
• DSG Classifier ID—10
• IP SA—12.8.8.1
• IP DA—228.9.9.1
• UDP DP—8000
These settings apply to DSG Rule #2:
• DSG Rule ID 2
• IP SA—12.8.8.2
• IP DA—228.9.9.2
• UDP DP—8000
Example of One DSG Tunnel Supporting IP Multicast from Multiple DSG Servers
In this configuration, and given the two Cisco CMTS Headends cited earlier in this topic, below is an example
of one DSG Tunnel with multiple DSG servers supporting IP Multicast:
• DSG Rule ID 1
• DSG Client ID 101.1.1 and 102.2.2
• IP SA—12.8.8.1
• IP DA—228.9.9.1
• UDP DP—8000
• IP SA—12.8.8.2
• IP DA—228.9.9.2
• UDP DP—8000
Example: Enabling DNS Query

The following example shows how to enable a DNS query on the Cisco CMTS router:
1163
Example: Disabling A-DSG Forwarding on the Primary Channel

Router(config)# ip domain-lookup
Router(config)# ip domain-name cisco.com
Router(config)# ip name-server 131.108.1.111
Router(config)# cable dsg name-update-interval 10
Router(config)# end
Example: Disabling A-DSG Forwarding on the Primary Channel

The following example shows how to disable A-DSG forwarding on a primary capable modular interface on
the Cisco CMTS router:

Router(config)# interface modular-cable 1/0/0:0
Router(config-if)# cable downstream dsg disable
The following sections provide references related to A-DSG 1.2.
Description Link

Feature Information for Advanced-Mode DSG 1.2 for the Cisco

CMTS Routers
1164
Feature Information for Advanced-Mode DSG 1.2 for the Cisco CMTS Routers
Table 203: Feature Information for DOCSIS Set-Top Gateway and A-DSG for the Cisco CMTS Routers
DOCSIS Set-Top Gateway for the Cisco IOS XE Everest This feature was integrated into Cisco IOS XE
Cisco CMTS Routers 16.6.1 Everest 16.6.1 on the Cisco cBR Series
1165
Feature Information for Advanced-Mode DSG 1.2 for the Cisco CMTS Routers
1166
CHAPTER 83
Cisco Network Registrar for the Cisco CMTS
Routers
This chapter supplements the Cisco Network Registrar (CNR) documentation by providing additional
cable-specific instructions to provision a hybrid fiber-coaxial (HFC) network using Cisco universal broadband
routers as CMTSs at the headend of the network.
Note For information about the IPv6 provisioning on CNR server, please refer to IPv6 on Cable.
Contents
• Servers Required on the HFC Network, on page 1169
• Cisco Network Registrar Description, on page 1170
• Overview of DHCP Using CNR, on page 1170
• How Cisco Converged Broadband Routers and Cable Modems Work, on page 1171
• DHCP Fields and Options for Cable Modems, on page 1172
• Cisco Network Registrar Sample Configuration, on page 1173
• Overview of Scripts, on page 1176
• Placement of Scripts, on page 1177
• Activating Scripts in Cisco Network Registrar, on page 1177
• Configuring the Cisco CMTS Routers to Use Scripts, on page 1177
• Configuring the System Default Policy, on page 1178
• Creating Selection Tag Scopes, on page 1178
• Creating Network Scopes, on page 1179
• Creating Policies for Class of Service or for Upgrading Cable Modem Cisco IOS Images, on page 1180
1167
• CNR Steps to Support Subinterfaces, on page 1180

Digital PICs:

Module:

Modules:
1168
Servers Required on the HFC Network
line card reload.
Servers Required on the HFC Network

A TFTP server, DHCP server, and time-of-day (TOD) server are required to support two-way data cable
modems on an HFC network. A cable modem will not boot if these servers are not available. The log server
and security servers are not required to configure and operate a cable modem. If the log server or security
servers are not present, a cable modem will generate warning messages, but it will continue to boot and
function properly.
Figure 30: Servers Required on a Two-Way HFC Network
In this provisioning model, TOD and TFTP servers are standard Internet implementations of the RFC 868
and RFC 1350 specifications. Most computers running a UNIX-based operating system supply TOD and
TFTP servers as a standard software feature. Typically, the TOD server is embedded in the UNIX inetd and
it requires no additional configuration. The TFTP server is usually disabled in the standard software but can
be enabled by the user. Microsoft NT server software includes a TFTP server that can be enabled with the
services control panel. Microsoft NT does not include a TOD server. A public domain version of the TOD
server for Microsoft NT can be downloaded from several sites.
The DHCP and Domain Name System (DNS) server shown in Figure above must be the DHCP/DNS server
available in Cisco Network Registrar version 2.0 or later. CNR is the only DHCP server that implements
policy-based assignment of IP addresses. The headend must be a Cisco cBR-8 converged broadband router.
The remote access server is only required on HFC networks that are limited to one-way (downstream only)
communication. In a one-way HFC network, upstream data from a PC through the headend to the Internet is
carried over a dialup connection. This dialup connection for upstream data is referred to as telco return. For
simplification, the model will not include a log or security server. Cable modems can be set up to use the
1169
Cisco Network Registrar Description
logging and security servers by including the appropriate DHCP options in the cable modem policy as described
in the Cisco Network Registrar User Manual.
Cisco Network Registrar Description

CNR is a dynamic IP address management system, running on Windows or Solaris, that uses the Dynamic
Host Configuration Protocol (DHCP) to assign IP addresses to cable interfaces, PCs, and other devices on the
broadband network. The CNR tool includes script extensions that allow a cable system administrator to define
and view individual DHCP options, define the identity or type of device on the network, and assign the device
to a predefined class or group.
Using the CNR tool, a cable system administrator can specify policies to provide:
• Integrated DHCP and Domain Name Server (DNS) services
• Time of Day (ToD) and Trivial File Transfer Protocol (TFTP) server based on the size of the network
• DHCP safe failover and dynamic DNS updates
Note This is available only in CNR 3.0 or higher.
Using the CNR tool and the extension scripts identified in the Overview of Scripts, on page 1176 section, a
cable system administrator can specify scopes, policies, and options for the network and each cable interface
based on the services and configuration to support at each subscriber site.
Note Scopes refer to the administrative grouping of TCP/IP addresses; all IP addresses within a scope should be
on the same subnet.
The cable system administrator defines system default policies for all standard options and uses scope-specific
policies for options related to particular subnets, such as cable interfaces. This allows DHCP to send the
information with the IP address.
Seven entry points exist for scripts:
• post-packet-decode
• pre-client-lookup
• post-client-lookup—Examines and takes action on results of the client-class process, places data items
in the environment dictionary to use at the pre-packet-encode extension point, includes DHCP relay
option
• check-lease-acceptable
• pre-packet-encode
• post-sent-packet
• pre-dns-add-forward
Overview of DHCP Using CNR

Cisco Network Registrar (CNR) is a dynamic IP address management system that uses the Dynamic Host
Configuration Protocol (DHCP) and assigns IP addresses to PCs and other devices on a network based on a
1170
How Cisco Converged Broadband Routers and Cable Modems Work
predefined set of policies, such as class of service. CNR assigns available IP addresses from address pools
based on the identity or type of the requesting device and the policies in effect. For example, CNR can
distinguish between registered devices, unregistered devices, and registered devices that have been assigned
to a particular class of service.
CNR also provides extensions that can be customized (via programming or a script) so that you can view
individual DHCP options, determine the identity or type of a device based on the content of the options, and
assign a device to a predefined class or group. Using these extensions, you can determine the difference
between PCs and cable modems and assign them IP addresses from different address pools.
In typical data-over-cable environments, service providers are interested in simplifying provisioning to limit
the amount of information that must be collected about subscribers’ customer premise equipment (CPEs). To
support current provisioning models, a field technician must be sent to a subscriber’s home or business to
install and setup a cable modem. During this site visit, the technician might register the serial number and
MAC address of the cable modem in the customer account database. Because a field technician must go to a
subscriber’s site to replace a cable modem, you can easily track modem information.
Manually registering and tracking information about a cable subscriber’s PC is more difficult. A subscriber
might purchase a new PC or exchange the network interface card (NIC) without notifying you of the change.
Automatic provisioning with CNR reduces the amount of customer service involvement needed to track
customer equipment. To use the provisioning model described in this document, you must still track serial
numbers and MAC addresses for cable modems, but you do not need to track information about the PC or
NIC cards installed at a subscriber site.
The remainder of this document describes how to configure CNR to support this model. The following sections
describe the equipment and servers required for the cable headend, provide an overview of the interaction
between DOCSIS-compatible cable modems and the Cisco universal broadband routers, and provide a guide
on how to configure CNR to support this provisioning model.
How Cisco Converged Broadband Routers and Cable Modems

Work
Cisco converged broadband routers and cable modems are based on the Data Over Cable Service Interface
Specification (DOCSIS) standards. These standards were created by a consortium of cable service providers
called Multimedia Cable Network Systems, Ltd. (MCNS) to that cable headend and cable modem equipment
produced by different vendors will interoperate. The key DOCSIS standards provide the basis for a cable
modem to communicate with any headend equipment and headend equipment to communicate with any cable
modem.
Cable modems are assigned to operate on specific cable channels so activity can be balanced across several
channels. Each Cisco cBR-8 router installed at the headend serves a specific channel. Part of network planning
is to decide which channel each cable modem can use.
A cable modem cannot connect to the network until the following events occur:
• The cable modem initializes and ranges through available frequencies until it finds the first frequency
that it can use to communicate to the headend. The cable modem might be another vendor’s
DOCSIS-compatible device and the headend might have a Cisco cBR-8 router installed. At this point
on the initial connection, the cable modem cannot determine if it is communicating on the correct channel.
• The cable modem goes through the DHCP server process and receives a configuration file from the
server.
• One of the parameters in the configuration file tells the cable modem which channel it can use.
1171
DHCP Fields and Options for Cable Modems
• If the assigned channel is not available on the Cisco cBR-8 router to which the cable modem is currently
connected, it resets itself and comes up on the assigned channel.
• During this second DHCP process, the modem will be connected to the correct CMTS. This time, the
configuration file will be loaded. For a DOCSIS-compatible cable modem to access the network, it might
go through the DHCP server two times on two different networks; therefore, one-lease-per-client IP
addressing is critical.
DHCP Fields and Options for Cable Modems

DHCP options and packet fields are required to enable cable modems to boot and operate properly. Table
below lists the required DHCP options and fields.
Table 205: Required DHCP Fields and Options
Required Field/Option Field/Option In Cisco Network Value/Description

Registrar
Fields
giaddr - IP address. As a DHCP packet

passes through the relay agent to
the DHCP server, the relay agent
supplies a unique IP address to the
packet and stores it in this field.
The relay agent is a cBR-8 router
with the iphelper attribute defined.
subnet-mask - Subnet mask for the IP address

stored in the giaddr field. This
value is also stored in the DHCP
packet by the relay agent.
file Packet-file-name Name of the cable modem
configuration file that will be read
from a TFTP server.
siaddr Packet-siaddr IP address of the TFTP server

where configuration files are stored.
Options
Time-servers - List of hosts running the time server

specified in the RFC 868 standard.
Time-offset - Time offset of a cable modem

internal clock from Universal Time
Coordinated (UTC). This value is
used by cable modems to calculate
the local time that is stored in
time-stamping error logs.
1172
Cisco Network Registrar Sample Configuration
Required Field/Option Field/Option In Cisco Network Value/Description

Registrar
MCNS-security-server - IP address of the security server.

This should be set if security is
required. See RFC 1533 for details.

You can use the following information to set up Cisco Network Registrar in a trial configuration. The
configuration describes DHCP-related setup only; it does not cover setting up DNS or configuring dynamic
DNS (DDNS). You should be familiar with important CNR concepts including scopes, primary and secondary
scopes, scope selection tags, client classes, and CNR policies. See the Using Network Registrar publication
for detailed information on these concepts.
In the trial configuration, you can configure CNR to perform the following operations:
• Receive DHCP requests from a cable modem and a PC on an HFC network via a port supporting multiple
network numbers. The Cisco cBR-8 router at the headend must be configured as a forwarder (iphelper
is configured).
• Serve IP addresses on two networks; a net-10 network (non-Internet routable) and a net-24 network
(Internet routable).
• Tell the difference between a cable modem and a PC based on the MAC address of the device and provide
net-24 addresses to the PC and net-10 addresses to the cable modem.
• Refuse to serve IP addresses to MAC addresses that it does not recognize.
To perform these options, you must implement the following CNR configuration items:
• Create two scope selection tags; one for PCs, one for cable modems.
• Create two client-classes; one for PCs , one for cable modems.
• Create a lease policy appropriate for the cable modem devices.
• Create a lease policy appropriate for the PC devices.
• Create a scope containing Class A net-24 (routable) addresses.
• Create a scope containing Class A net-10 (nonroutable) addresses.
• Identify the scope containing the net-24 addresses as the primary scope and configure the other scope
containing the net-10 addresses as secondary to the net-24 scope.
Note The Cisco cBR-8 router upstream ports must be configured with the primary network address on the net-24
network; such as 24.1.1.1.
• Assign the policies to the appropriate scope.

• Add the MAC address of the cable modem and the PC to the client-entry list.
• Associate the PC tag with the scope containing routable addresses.
• Associate the cable modem tag with the scope containing nonroutable addresses.
• Associate the cable modem tag with the cable modem client-class.
• Associate the PC tag with the PC client-class.
• Assign the PC MAC to the PC class.
1173
• Assign the cable modem MAC to the cable modem class.

• Enable client-class processing.
Figure below shows the trial CNR configuration in an HFC network.
Figure 31: Trial Configuration in an HFC Network
These configuration items and their associations can be created using either the CNR management graphical
user interface (GUI) or command-line interface (CLI). The following sample script configures DHCP for a
sample server:
File: cabledemo.rc
Command line: nrcmd -C <cluster> -N <user name> -P <password> -b < cabledemo.rc
---------------------------------------------------------------------------------------
scope-selection-tag tag-CM create
scope-selection-tag tag-PC create
client-class create class-CM
client-class class-CM set selection-criteria=tag-CM
client-class create class-PC
client-class class-PC set selection-criteria=tag-PC
policy cmts-cisco create
policy cmts-cisco setleasetime 1800
policy cmts-cisco setoption domain-name-servers 192.168.10.2
policy cmts-cisco setoption routers 10.1.1.1
policy cmts-cisco setoption time-offset 604800
policy cmts-cisco setoption time-servers 192.168.10.20
policy cmts-cisco set packet-siaddr=192.168.10.2
policy cmts-cisco setoption log-servers 192.168.10.2
policy cmts-cisco setoption mcns-security-server 192.168.10.2
policy cmts-cisco set packet-file-name=golden.cfg
policy cmts-cisco set dhcp-reply-options=packet-file-name,packet-siaddr,mcns-security-server
policy pPC create
policy pPC set server-lease-time 1800
policy pPC setleasetime 1800
policy pPC setoption domain-name-servers 192.168.10.2
policy pPC setoption routers 24.1.1.1
scope S24.1.1.0 create 24.1.1.0 255.255.255.0
scope S24.1.1.0 addrange 24.1.1.5 24.1.1.254
scope S24.1.1.0 set policy=pPC
scope S24.1.1.0 set selection-tags=tag-PC
scope S10.1.1.0 create 10.1.1.0 255.255.255.0
1174
Cable Modem DHCP Response Fields
scope S10.1.1.0 addrange 10.1.1.5 10.1.1.254

scope S10.1.1.0 set policy=cmts-cisco
scope S10.1.1.0 set selection-tags=tag-CM
scope S10.1.1.0 set primary-scope=S24.1.1.0
client 01:02:03:04:05:06 create client-class-name=class-PC
client ab:cd:ef:01:02:03 create client-class-name=class-CM
client default create action=exclude
dhcp enable client-class
dhcp enable one-lease-per-client
save
dhcp reload
In addition to the DHCP server setup, you might want to enable packet-tracing. When packet-tracing is enabled,
the server parses both requests and replies, and then adds them to the logs. If you do enable tracing, performance
will be adversely affected, and the logs will roll over quickly.
Use the following nrcmd command to set packet tracing.
DHCP set log-settings=incoming-packet-detail,outgoing-packet-detail
Cable Modem DHCP Response Fields

Each cable interface on the broadband network requires the following fields in the DHCP response:
• CM’s IP address
• CM’s subnet mask
Note For cable operators with less experience in networking, you can fill in a guess based on the network number
and indicate how your IP network is divided.
• Name of the DOCSIS configuration file on the TFTP server intended for the cable interface
• Time offset of the cable interface from the Universal Coordinated Time (UTC), which the cable interface
uses to calculate the local time when time-stamping error logs
• Time server address from which the cable interface obtains the current time
DOCSIS DHCP Fields

DOCSIS DHCP option requirements include:
• IP address of the next server to use in the TFTP bootstrap process; this is returned in the siaddr field
• DOCSIS configuration file that the cable interface downloads from the TFTP server
Note If the DHCP server is on a different network that uses a relay agent, then the relay agent must set the gateway
address field of the DHCP response.
• IP address of the security server should be set if security is required
1175
DHCP Relay Option (DOCSIS Option 82)
DHCP Relay Option (DOCSIS Option 82)

DOCSIS Option82 modifies DHCPDISCOVER packets to distinguish cable interfaces from the CPE devices
or “clients” behind them. The DOCSIS Option82 is comprised of the following two suboptions:
• Suboption 1, Circuit ID:
Type 1 (1 byte)
Len 4 (1 byte)
Value (8 bytes)
<bit 31,30,....................0)
<xYYYYYYYYYYYYYYYYYYYYYYYYYYYYYY>
where the MSB indicates if the attached device is a cable interface.

x=1 Cable Modem REQ
x=0 CPE device (Behind the cable interface with the cable interface MAC address shown in suboption 2.)
The rest of the bits make up the SNMP index to the CMTS interface.
Y=0xYYYYYYY is the SNMP index to the CMTS interface.
• Suboption 2, MAC address of the cable interface:
Type 2 (1 byte)
Len 6 (1 byte)
Value xxxx.xxxx.xxxx (6 bytes)
Overview of Scripts
This section lists the scripts applicable to cable interface configuration.
Two-way Cable Modem Scripts

To support two-way configurations at a subscriber site, use these scripts:
• Relay.tcl
• SetRouter.tcl
Telco Return Cable Modem Scripts

To support telco return and two-way cable interface configurations on the same cable interface card or chassis,
use these scripts:
• PostClientLookup.tcl
• PrePacketEncode.tcl
1176
Placement of Scripts
Placement of Scripts
Windows NT
For CNR running on Windows NT, place the appropriate scripts in the following directory:
\program files\network registrar\extensions\dhcp\scripts\tcl
Solaris
For CNR running on Solaris, place the appropriate scripts in the following directory:
/opt/nwreg2/extensions/dhcp/scripts/tcl
Activating Scripts in Cisco Network Registrar

To activate the scripts after you have placed them in the appropriate directory:
Step 1 Open up a text editor.

Step 2 Open one of the scripts at the nrcmd> command prompt.
Step 3 Create the extension points and attach them to the system.
Note The easiest way to do this is to simply cut and paste the command lines from the scripts to the nrcmd> command
line.
Step 4 After you have created and attached the extension points, do a dhcp reload.
The scripts are active.
Configuring the Cisco CMTS Routers to Use Scripts

Each cable interface must be set up as a BOOTP forwarder and have the relay option enabled. The primary
and secondary IP addresses for each cable interface must be in sync with the CNR tool.
To properly communicate with scripts in the system, use the following commands on the Cisco CMTS router:
• To enable option 82, use the ip dhcp relay info option command.
• To disable the validation of DHPC relay agent information in forwarded BOOTREPLY messages, use
the no ip dhcp relay information option check command.
1177
Configuring the System Default Policy
Note You can also use the cable dhcp-giaddr command in cable interface configuration mode to modify the GIADDR
field of DHCPDISCOVER and DHCPREQUEST packets to provide a relay IP address before packets are
forwarded to the DHCP server. Use this command to set a “policy” option such that primary addresses are
used for CMs and secondary addresses are used for hosts behind the CMs.
Configuring the System Default Policy

Add these options to the system default policy for:
• Cable modems to support on your network
• PCs to support behind each cable interface on your network
Cable Modems
Define these settings following the CNR tool documentation:
• TFTP server (IP address) for those cable interfaces using BOOTP
• Time-server (IP address)
• Time-offset (Hex value, 1440 for Eastern Standard Time)
• Packet-siaddr (IP address of CNR)
• Router (set to 0.0.0.0)
• Boot-file (name of .cm file for those cable interfaces using BOOTP)
• Packet-file-name (.cm file name)
PCs
Define these settings following the CNR tool documentation:
• Domain name
• Name servers (IP address of DNS servers)
Creating Selection Tag Scopes

General
When you create your scope selection tags:
Step 1 Cut and paste the scope selection tag create commands from the scripts into the nrcmd> command line.
Note These names have to be exactly as they appear in the scripts.
Step 2 Then attach the selection tags to the appropriate scripts:

Example:
1178
Telco Return for the Cisco cBR-8 Router
CM_Scope tagCablemodem
PC_Scope tagComputer
Telco Return for the Cisco cBR-8 Router

Before you begin
Note If you are using the prepacketencode and postclientlookup .tcl scripts for telco return, the telco return scope
does not have a selection tag associated to the scope.
SUMMARY STEPS
1. Put the tag Telcocablemodem on the primary cable interface scope to pull addresses from that pool instead.
2. Follow the same procedure as above, but use a telco return policy which has a different .cm file with
telco-specific commands in it.
DETAILED STEPS
Step 1 Put the tag Telcocablemodem on the primary cable interface scope to pull addresses from that pool instead.
Step 2 Follow the same procedure as above, but use a telco return policy which has a different .cm file with telco-specific
commands in it.
Creating Network Scopes

Following is an example for creating scopes for your network. This example assumes two Cisco cBR-8
converged broadband routers in two locations, with one cable interface card on one Cisco cBR-8 configured
for telco return.
cm-toledo1_2-0 10.2.0.0 255.255.0.0 assignable 10.2.0.10-10.2.254.254 tagCablemodem

tagTelcomodem Default GW=10.2.0.1 (assigned by scripts)
cm-toledo1_3-0 10.3.0.0 255.255.0.0 assignable 10.3.0.10-10.3.254.254 tagCablemodem
tagTelcomodem Default GW=10.3.0.1 (assigned by scripts)
pc-toledo1_2-0 208.16.182.0 255.255.255.248 assignable 208.16.182.2-208.16.182.6 tagComputer
Default GW=208.16.182.1 (assigned by scripts)
telco_return_2-0 192.168.1.0 255.255.255.0 (No assignable addresses, tag was put on cable
modem primary scope to force telco-return cable modem to pull address from primary scope)
cm-arlington1_2-0 10.4.0.0 255.255.0.0 assignable 10.4.0.10-10.4.254.254 tagCablemodem
cm-arlington1_3-0 10.5.0.0 255.255.0.0 assignable 10.5.0.10-10.5.254.254 tagCablemodem
pc-arlington1_2-0 208.16.182.16 255.255.255.248 assignable 208.16.182.17-208.16.182.22
tagComputer Default GW=208.16.182.17 (assigned by scripts)
1179
Creating Policies for Class of Service or for Upgrading Cable Modem Cisco IOS Images

Note Remember the last valid address in the .248 subnet range is the broadcast address; do not use this.
Creating Policies for Class of Service or for Upgrading Cable

Modem Cisco IOS Images
To support Class of Service (CoS), define:
• Scope selection tags—Identifiers that describe types of scope configurations
Note This is needed for Option82.
• Client classes—Class with which a group of clients is associated
Note Scope selection tags are excluded from or included in client-classes.
• Client—Specific DHCP clients and the defined class to which they belong
To assign the CoS or use Option82, make a client entry with a MAC address and point to the appropriate
policy. To use client-based MAC provisioning, add a client entry “default - exclude,” then put in MAC
addresses for all devices (for example, cable interfaces and PCs) in the client tab and select the policy to use,
including the appropriate tag.
CNR Steps to Support Subinterfaces

The CNR configuration is done differently if subinterfaces are configured. Here is an example. If you have
configured two ISP subinterfaces and one management subinterface on a Cisco cBR-8 router, make sure that
the management subinterface is the first subinterface that is configured. If cable interface three—c3/0/0—is
being used, create c3/0/0.1, c3/0/0.2 and c3/0/0.3 as three subinterfaces and c3/0/0.1 as the first subinterface
configured as the management subinterface.
Note The Cisco cBR-8 router requires management subinterfaces to route DHCP packets from CMs when they
first initialize because the Cisco cBR-8 router does not know the subinterfaces they belong to until it has seen
the IP addresses assigned to them by gleaning DHCP reply message from CNR.
In CNR, complete the following steps for such a configuration:
1180
SUMMARY STEPS
1. Create two scope selection tags such as: isp1-cm-tag and isp2-cm-tag
2. Configure three scopes; for example, mgmt-scope, isp1-cm-scope, and isp2-cm-scope such that
isp1-cm-scope and isp2-cm-scope each define mgmt-scope to be the primary scope
3. Also configure two scopes for PCs for each of the ISPs; isp1-pc-scope and isp2-pc-scope. For scope
isp1-cm-scope, configure isp1-cm-tag to be the scope selection tag. For scope isp2-cm-scope, configure
isp2-cm-tag to be the scope selection tag
4. Configure two client classes; for example, isp1-client-class and isp2-client-class
5. Create client entries with their MAC addresses for CMs that belong to ISP1 and assign them to
isp1-client-class. Also assign the scope selection tag isp1-cm-tag
6. Create client entries for CMs that belong to ISP2 and assign them to isp2-client-class. Also assign the
scope selection tag isp2-cm-tag
7. Enable client class processing from the scope-selection-tag window
DETAILED STEPS
Step 1 Create two scope selection tags such as: isp1-cm-tag and isp2-cm-tag
Step 2 Configure three scopes; for example, mgmt-scope, isp1-cm-scope, and isp2-cm-scope such that isp1-cm-scope and
isp2-cm-scope each define mgmt-scope to be the primary scope
Step 3 Also configure two scopes for PCs for each of the ISPs; isp1-pc-scope and isp2-pc-scope. For scope isp1-cm-scope,
configure isp1-cm-tag to be the scope selection tag. For scope isp2-cm-scope, configure isp2-cm-tag to be the scope
selection tag
Step 4 Configure two client classes; for example, isp1-client-class and isp2-client-class
Step 5 Create client entries with their MAC addresses for CMs that belong to ISP1 and assign them to isp1-client-class. Also
assign the scope selection tag isp1-cm-tag
Step 6 Create client entries for CMs that belong to ISP2 and assign them to isp2-client-class. Also assign the scope selection
tag isp2-cm-tag
Step 7 Enable client class processing from the scope-selection-tag window
Overlapping address ranges cannot be configured on these subinterfaces because software gleans the DHCP reply to
figure out the subinterface it really belongs to. Although CNR can be configured with overlapping address range scopes,
it cannot be used to allocate addresses from these scopes.
The following sections provide references related to Cisco Network Registrar for use with the Cisco CMTS
routers.
1181
Description Link
Technical Assistance Center (TAC) home page, http://www.cisco.com/cisco/web/support/index.html

containing 30,000 pages of searchable technical content,
including links to products, technologies, solutions,
technical tips, and tools. Registered Cisco.com users
can log in from this page to access even more content.
1182
PA R T IX
PacketCable and PacketCable Multimedia
Configuration
• PacketCable and PacketCable Multimedia, on page 1185
• COPS Engine Operation, on page 1223
CHAPTER 84
PacketCable and PacketCable Multimedia
This document describes how to configure the Cisco CMTS for PacketCable and PacketCable Multimedia
operations over an existing DOCSIS (1.1and later versions) network.
• Restrictions for PacketCable Operations, on page 1187
• Information About PacketCable Operations, on page 1187
• How to Configure PacketCable Operations, on page 1193
• Configuration Examples for PacketCable, on page 1201
• Verifying PacketCable Operations, on page 1204
• Information About PacketCable Multimedia Operations, on page 1208
• How to Configure PCMM Operations, on page 1212
• Configuration Examples for PacketCable Multimedia, on page 1214
• Verifying PCMM Operations, on page 1215
• High Availability Stateful Switchover (SSO) for PacketCable and PacketCable MultiMedia, on page 1217
• Voice MGPI Support, on page 1217
• Feature Information for PacketCable and PacketCable Multimedia, on page 1221

1185
PacketCable and PacketCable Multimedia Configuration
Digital PICs:

Module:

Modules:
1186
Restrictions for PacketCable Operations
line card reload.
Restrictions for PacketCable Operations

• Supports only embedded multimedia terminal adapter (E-MTA) clients. Standalone MTA (S-MTA)
clients are not supported.
• PacketCable operations can be configured together with HCCP N+1 redundancy, but the PacketCable
states are not synchronized between the Working and Protect interfaces. If a switchover occurs, existing
voice calls continue, but when the user hangs up, PacketCable event messages are not generated because
the Protect interface is not aware of the previous call states. However, new voice calls can be made and
proceed in the normal fashion.
• The 200,000 Hz channel width cannot be used on upstreams that support PacketCable voice calls, or on
any upstreams that use Unsolicited Grant Service (UGS) or UGS with Activity Detection (UGS-AD)
service flows. Using this small a channel width with voice and other UGS/UGS-AD service flows results
in calls being rejected because of “DSA MULTIPLE ERRORS”.
Information About PacketCable Operations

This section provides an overview and other information about PacketCable operations, the components of a
PacketCable network, and how they interact with the other components of a DOCSIS cable networks.
Feature Overview
PacketCable is a program initiative from Cablelabs and its associated vendors to establish a standard way of
providing packet-based, real-time video and other multimedia traffic over hybrid fiber-coaxial (HFC) cable
networks. The PacketCable specification is built upon the Data-over-Cable System Interface Specifications
(DOCSIS) 1.1, but it extends the DOCSIS protocol with several other protocols for use over noncable networks,
such as the Internet and the public switched telephone network (PSTN).
This allows PacketCable to be an end-to-end solution for traffic that originates or terminates on a cable network,
simplifying the task of providing multimedia services over an infrastructure composed of disparate networks
and media types. It also provides an integrated approach to end-to-end call signaling, provisioning, quality
of service (QoS), security, billing, and network management.
1187
Emergency 911 Features
Emergency 911 Features

PacketCable Emergency 911 Cable Interface Line Card Prioritization
The PacketCable Emergency 911 cable interface line card prioritization feature enables cable interface line
cards that are supporting an Emergency 911 call to be given automatic priority over cable interface line cards
supporting non-emergency voice calls, even in the case of HCCP switchover events. In such cases, Protect
HCCP line card interfaces automatically prioritize service to Emergency 911 voice calls, should Working
HCCP cable interface line cards be disrupted. This feature is enabled by default, and may not be disabled with
manual configuration.
Note Emergency 911 cable interface line card prioritization applies only to PacketCable voice calls.
During HCCP switchover events, cable modems recover in the following sequence:
1. Cable modems supporting Emergency 911 voice traffic
2. Cable modems supporting non-emergency voice traffic
3. Cable modems that are nearing a T4 timeout event, in which service would be disrupted
4. Remaining cable modems
To view information about Emergency 911 voice events and cable interface line card prioritization on the
Cisco CMTS router, use the show hccp, show cable calls, and show hccp event-history commands in privileged
EXEC mode.
PacketCable Emergency 911 Services Listing and History

The enhanced informational support for PacketCable Emergency 911 calls on the Cisco CMTS router provides
the following information and related history:
• active Emergency 911 calls
• recent Emergency 911 calls
• regular voice calls
• voice calls made after recent Emergency 911 calls
This feature is enabled and supported with the following configuration and show commands:
• cable high-priority-call-window
• show cable calls
• show cable modem calls
To set the call window (in minutes) during which the Cisco CMTS router maintains records of Emergency
911 calls, use the cable high-priority-call-window command in global configuration mode. To remove the
call window configuration from the Cisco CMTS router, use the no form of this command:
PacketCable Network Components

A PacketCable network contains a number of components. Some components are the same as those that exist
in a DOCSIS 1.1 network, while other components are new entities that create the end-to-end infrastructure
that the PacketCable network needs to establish calls. Wherever possible, the PacketCable components and
protocols build on existing protocols and infrastructures to simplify implementation and interoperability.
1188
Dynamic Quality of Service
• Cable modem—A customer premises equipment (CPE) device that connects to a DOCSIS 1.0 or DOCSIS
1.1 cable network. All DOCSIS cable modems provide high-speed data connectivity to the Internet, while
other cable modems can provide additional features, such as telephone connectivity.
• Cable Modem Termination System (CMTS)—A headend-based router that connects a DOCSIS cable
network to the IP backbone network. The CMTS controls the DOCSIS 1.1 MAC layer and enforces the
quality of service (QoS) limits that the cable operator guarantees to its subscribers. A typical CMTS
services between several hundred and several thousand cable modems.
Note See the DOCSIS 1.1 specifications for information about cable modem and CMTS operations.
• Multimedia terminal adapter (MTA)—A CPE device that connects telephones and other end-user devices
to the PacketCable network. The PacketCable specification defines two MTA types, an embedded MTA
(E-MTA) and a standalone MTA (S-MTA). The E-MTA is an MTA integrated into a DOCSIS 1.1 cable
modem, while the S-MTA is a separate MTA that requires a DOCSIS 1.1 cable modem to connect to
the cable network.
• Call management server (CMS)—A centrally located server that provides the signaling functions that
allow MTAs to establish calls over the network. The CMS uses the Network-based call signaling (NCS)
protocol to provide authentication and authorization, call routing, and support for special features such
as three-way calling. A PacketCable network could have multiple CMS servers, depending on its size
and complexity.
Note The CMS implements several protocols on top of the Common Open Policy Service (COPS) protocol to
communicate with the rest of the PacketCable network.
• Gate controller (GC)—A server that controls the establishment of gates in the PacketCable network. A
gate is a logical entity in the CMTS that ensures that a service flow is authorized for the QoS features it
is requesting. A separate gate controls the upstream and downstream directions of a service flow. When
a call is established, the GC instructs the CMTS to create each gate and supplies the set of authorized
parameters for each gate, which the CMTS uses to authorize the QoS requests that the MTA is making
for the call. The GC is also responsible for coordinating the creation of the two sets of gates at each end
of the call so that the call can be authorized and established.
Note A PacketCable network can contain multiple GCs, although only one server at a time is in control of any
particular call. Typically, the same workstation provides both the CMS and GC servers.
• Record keeping server (RKS)—Billing server that collects the information about each call as it is made.
The RKS uses the Remote Authentication Dial-In User Service (RADIUS) protocol to collect the billing
data from the CMTS and other PacketCable servers. The RKS generates a call data record (CDR) for
every call and forwards that information to the appropriate application server at the service provider’s
data processing center for further processing.
Dynamic Quality of Service

A key feature of a PacketCable network is a dynamic quality of service (DQoS) capability that is similar to
the dynamic services provided by DOCSIS 1.1. However, DOCSIS 1.1 DQoS authorizes and provisions
1189
Two-Stage Resource Reservation Process
services only in the cable network and does not reserve the resources needed to propagate a call from one
endpoint to another across the network.
The PacketCable DQoS extends the DOCSIS 1.1 services across the entire network, so that resources can be
dynamically authorized and provisioned from one endpoint to another. This prevents possible theft-of-service
attacks and guarantees customers the services they are authorized to use.
Note PacketCable 1.0 requires that DOCSIS 1.1 be used for resource reservation within the cable network for
E-MTA clients.
Two-Stage Resource Reservation Process

The PacketCable DQoS model uses a two-stage resource reservation process, in which resources are first
reserved and then committed. This allows a bidirectional reservation process that ensures that resources are
available at both endpoints of the connection before actually placing the call.
When an MTA makes a call request, the local CMTS communicates with the gate controller to authorize the
call’s resources. After the resources are authorized, the CMTS reserves the local resources while it negotiates
with the remote end for the resources that are required at that end.
Note The CMTS uses DOCSIS 1.1 Dynamic Service Addition (DSA) messages to reserve the resources, and then
uses Dynamic Service Change (DSC) messages to commit the resources.
When all required resources are available, the local CMTS and remote CMTS both commit the resources,
allowing traffic to flow. Usage accounting and billing do not begin until the remote MTA picks up and the
call is actually in progress.
The DQoS model ensures that both endpoints of a call, as well as the backbone network, have reserved the
same bandwidth, and that the bandwidth is reserved only while the call is in progress. When a call terminates,
all portions of the network can release the call’s resources and make them available for other users.
Making a Call Using DQoS

DOCSIS 1.1 networks use service flows to implement different QoS policies, but service flows exist only
within the cable network. To control the service flows and to extend them across the entire network, a
PacketCable network creates and maintains “gates.”
A gate is a logical entity created on the CMTS at each side of a connection that authorizes and establishes a
particular DQoS traffic flow. The CMTS communicates with the gate controller to coordinate the creation of
matching gates at each side of the connection.
Gates are unidirectional, so separate gates are required for the downstream and upstream traffic flows. The
same gate ID, however, is usually used for the downstream and upstream gates for a call. Each CMTS maintains
its own set of gates, so a bidirectional traffic flow requires four gates to be created, two gates on the local
CMTS and two gates on the remote CMTS.
For a typical call, gates progress through the following stages to create a DQoS traffic flow:
1. The local MTA makes a call request, and the gate controller sends a Gate-Allocation command to the
CMTS, which creates a gate in response and puts it into the Allocated state.
1190
DQoSLite Based IPv6 Voice Support
2. The call management server, which might be the same server as the gate controller, parses the call request
to translate the destination phone number into the appropriate destination gateway.
3. The gate controller verifies that the MTA making the call request is authorized for the required resources
and sends a Gate-Set command to the CMTS, which puts the gate into the Authorized state.
4. The CMTS on each side of the connection reserves the local resources needed for the call, putting the
gate into the Reserved state.
5. As the remote CMTS and local CMTS perform gate coordination, their respective gates get put into the
Local_Committed and Remote_Committed states.
6. When both sides have reserved all required resources, each CMTS puts its gates into the Committed state,
allowing traffic to flow.
DQoSLite Based IPv6 Voice Support

DQoSLite is a modem centric solution without notion of gates, to validate and deliver residential voice services
over IPv6 to reclaim IPv4 address space. CMTS does not participate in resource reservation and authorization.
DQoSLite leverages elements from PacketCable 2.0. It is SIP based, it's provision mechanism is similar to
PacketCable 2.0 and it can be part of an IP Multimedia Subsystem (IMS) infrastructure for the ISP.
The key factors for deploying IPv6 voice solution on this new DQoSLite infrastructure are as follows:
• It is SIP or IMS based.
• Support for a wide range of multimedia services.
• To reclaim some IPv4 address space.
This feature is enabled and supported with the following configuration and show commands:
• packetcale authorize vanilla-docsis-mta
• show cable modem {ip-address|mac-address} qos
• show cable modem {ip-address|mac-address} service-flow
• show interface cable slot/subslot/cable-interface-index sid sid
• show interface cable slot/subslot/cable-interface-index service-flow sfid
Dynamic Service Transaction ID Support

DOCSIS 2.0 mandates unique Transaction IDs (TAIDs) across transactions. The TAIDs must be unique and
not incremented. The TAIDs are assigned by the senders and sometimes the TAID timeout is mismatched
between senders and receivers. This affects the uniqueness of the TAID.
A TAID can be reused when the sender finishes a transaction. Similarly, DOCSIS allows the receiver to
identify a transaction by TAID without the SFID. Problems arise in DSD transaction and DSA/DSC interrupted
transactions, when these two requirements are combined.
The uniqueness of TAID must be ensured to resolve the interoperability issue. This is done by making the
CMTS wait until T10 to reuse the same TAID. A new TAID allocation algorithm is used to fulfill this
requirement.
It creates a TAID pool to replace the existing 16-bit counter. This TAID pool is monitored by timers to track
the TAID expiration. A flag is assigned to each TAID in the pool to indicate its availability. When new TAID
1191
PacketCable Subscriber ID Support
is requested, the dynamic service process checks the availability of the TAID. If the TAID is available, it is
allocated to the new service flow, else the request is rejected.
Once the TAID is allocated, the timer starts with T10 expiration time and the TAID flag is set to FALSE to
indicate the unavailability of TAID. The dynamic service process keeps track of the timer. When the time
expires, the timer stops and the flag is set to TRUE to indicate the availability of TAID.
The TAID pool is allocated and initialized at the process initialization. All timers associated with the TAIDs
are added as leaf timers to the process' parent timer.
PacketCable Subscriber ID Support

The PacketCable Subscriber ID feature adds a subscriber ID to all Gate Control messages and enhances error
codes returned from the Cisco CMTS router.
Previously, the Gate ID was unique only to individual CMTS systems, with the CMTS proxying all CMS
Gate Control messaging through a central device, which manages the CMTS connections on behalf of the
CMS. The CMS had a single Common Open Policy Service (COPS) association to the proxy device. Therefore,
the Gate IDs could be duplicated when using multiple CMTS systems.
A subscriber ID is added to each Gate Control message to disambiguate the Gate IDs between the CMS and
proxy device. The subscriber ID parameter is added to the following COPS messages:
• GATE-INFO
• GATE-DELETE
• GATE-OPEN
• GATE-CLOSE
The subscriber ID is available at the CMS and is used in the Gate-Set messages. Additionally, the error codes
returned from CMTS or its proxy are enhanced to include more specific information about gate operation
failures.
To enable this feature, use the packetcable gate send-subscriberID command in global configuration mode.
Benefits
The PacketCable feature offers the following benefits to service providers and their customers:
Integrated Services on a Cable Network

PacketCable allows cable operators the ability to offer multimedia, real-time services, in addition to data
connectivity, across their entire network. These services could include basic telephony with lifeline support,
as well as telephony that offers competitive extended calling services. Operators can deploy new services
while heavily leveraging their existing network infrastructures.
The widespread use of IP as the standard transport mechanism for data networks today is enabling many
advanced Internet applications such as multimedia e-mail, real-time chat, streaming media (including music
and video), and videoconferencing. The PacketCable initiative provides the network architecture for a cable
operator to deliver these services quickly and economically.
1192
How to Configure PacketCable Operations
Standardized Provisioning
PacketCable provides a standardized, efficient method to provision IP services for individual subscribers,
because PacketCable specifications define a uniform, open, and interoperable network. Cable operators are
assured of standardized provisioning and the associated lower costs of deployment.
Interoperability
Customer premises equipment (CPE) devices account for a major portion of the capital expense in deploying
a VoIP solution at a cable plant. The PacketCable specifications ensure that vendors will build MTA clients
that support the voice and other services that cable operators plan to deploy. Because these CPE devices are
based on existing DOCSIS-compliant cable modems, time and cost of development is minimized.
Interoperability with the other components of the PacketCable network is also guaranteed because of the
standards-based approach to the specifications. Any PacketCable-certified component will be able to interoperate
within a network that conforms to the PacketCable standards.
Secure Architecture
Because PacketCable is built upon the security features available in DOCSIS 1.1, cable operators will be
assured of networks that are secure from end to end, with a high standard of security that prevents the most
common theft-of-service attacks. The comprehensive, standards-based PacketCable specifications are designed
to create a network that is as secure as the public switched telephone network (PSTN).
CALEA Support
The PacketCable architecture was designed to accommodate the 1994 Communications Assistance for Law
Enforcement Act (CALEA), which requires telecommunications carriers to assist law-enforcement agencies
in conducting court-ordered electronic surveillance. PacketCable networks will be able to provide the two
types of information that a carrier must provide, depending on the type of court order:
• Call-identifying information—The carrier must provide the call-identifying information for calls to or
from an intercept target. For telephone calls, this information includes the phone numbers called by the
target or calling the target.
• Call content—The carrier must provide the content of calls to or from an intercept target. For telephone
calls, this real-time content is the voice conversation.
How to Configure PacketCable Operations

This section contains the following tasks to configure the PacketCable feature. Each task is required unless
otherwise identified as optional.
Enabling PacketCable Operation

To enable PacketCable operation, use the following commands beginning in user EXEC mode. This is a
required procedure.
Step 1 enable
Example:
1193
Disabling PacketCable Operation
Router> enable

Example:
Step 3 packetcable
Example:
Router(config)# packetcable
Enables PacketCable operation on all cable interfaces.
Step 4 exit
Example:
Exits global configuration mode.
Disabling PacketCable Operation

To disable PacketCable operation, use the following commands beginning in user EXEC mode. This procedure
is required only when you no longer want the Cisco CMTS to support PacketCable signaling.
Step 1 enable
Example:
Router> enable

Example:
Step 3 no packetcable
Example:
Router(config)# no packetcable
1194
Configuring PacketCable Operation
Disables PacketCable operation on all cable interfaces.
Step 4 exit
Example:
Configuring PacketCable Operation

To configure the different parameters that affect PacketCable operations, use the following commands beginning
in user EXEC mode. All of these procedures are optional, because each parameter is set to a default that is
appropriate for typical PacketCable operations.
Step 1 enable
Example:
Router> enable

Example:
Step 3 packetcable element-id n

Example:
Router(config)# packetcable element-id 23
Configures the Event Message Element ID for the Cisco CMTS. If you do not manually configure the Element ID, the
CMTS defaults to a random value between 0 and 99,999 when PacketCable operations are enabled.
Step 4 packetcable gate maxcount n

Example:
Router(config)# packetcable gate maxcount 524288
Sets the maximum number of gate IDs to be allocated in the gate database on the Cisco CMTS.
Step 5 packetcable timer T0 timer-value

Example:
Router(config)# packetcable timer T0 40000
1195
Enabling Both PacketCable and Non-PacketCable UGS Service Flows
Sets the T0 timer in milliseconds.
Step 6 packetcable timer T1 timer-value

Example:
Sets the T1 timer in milliseconds.
Step 7 exit
Example:
Enabling Both PacketCable and Non-PacketCable UGS Service Flows

By default, when PacketCable operations are enabled using the packetcable command, cable modems must
follow the PacketCable protocol when requesting Unsolicited Grant Service (UGS) service flows. This prevents
DOCSIS cable modems that do not support PacketCable operations from using DOCSIS-style UGS service
flows.
If you have a mixed network that contains both PacketCable and non-PacketCable DOCSIS CMs, you can
use the packetcable authorize vanilla-docsis-mta command to enable both types of UGS service flows. This
is an optional procedure.
Step 1 enable
Example:
Router> enable

Example:
Step 3 packetcable
Example:
Enables PacketCable operations.
Step 4 packetcable authorize vanilla-docsis-mta
1196
Enabling PacketCable Subscriber ID Support
Example:
Router(config)# packetcable authorize vanilla-docsis-mta
Enables the use of DOCSIS-style UGS service flow requests.
Step 5 cable dsx authorization

Example:
Router(config)# cable dsx authorization
Enables the dsx authorization.
Step 6 exit
Example:
What to do next
Tip Use the show packetcable global command to display whether non-PacketCable UGS service flows have
been enabled.
Enabling PacketCable Subscriber ID Support

To include subscriber identification in GATE-OPEN and GATE-CLOSE Gate Control messages, use the
packetcable gate send-subscriberID command in global configuration mode.
Step 1 enable
Example:
Router> enable

Example:
Step 3 packetcable
Example:
1197
Configuring RADIUS Accounting for RKS Servers
Enables PacketCable operations.
Step 4 packetcable gate send-subscribeID

Example:
Router(config)# packetcable gate send-subscriberID
Enables the use of gate control subscriber identification information.
Step 5 exit
Example:

To enable the Cisco CMTS router to communicate with the Record Keeping Servers (RKS servers) using the
RADIUS protocol, use the following commands. This is a required procedure.
Step 1 enable
Example:
Router> enable

Example:
Step 3 aaa new-model

Example:
Router(config)# aaa new-model
Enables the authentication, authorization, and accounting (AAA) access control model.
Step 4 aaa group server radius group-name

Example:
Router(config)# aaa group server radius packetcable
1198
Creates a group of RADIUS servers for authentication and enters RADIUS group configuration mode. The value of
group-name is a unique, arbitrary string that identifies this group.
Step 5 server {hostname | ip-address} [auth-port udp-port ] [acct-port udp-port ]

Example:
Router(config-sg-radius)# server radius-server1
Specifies the host name or IP address for the RADIUS server that is providing the RKS services.
Note Repeat this command as needed to enter multiple RADIUS servers. The Cisco CMTS uses the servers in the
order given with this command.
Step 6 exit
Example:
Router(config-sg-radius)# exit
Exits RADIUS group configuration mode.
Step 7 aaa accounting network default start-stop group radius group group-name
Example:
Router(config)# aaa accounting network default start-stop group radius group packetcable
Enables AAA services using the group of RADIUS servers that are defined in the previously created group. The
group-name parameter should be the same name specified in Step 4 .
Step 8 radius-server host {hostname | ip-address} [auth-port port-number] [acct-port port-number ] [timeout seconds
] [retransmit retries ] key 0000000000000000
Example:
Router(config)# radius-server host radius-server1 key 0000000000000000
Specifies a RADIUS host. Use the same values for hostname or ip-address as for one of the servers specified in Step
5 . If you also specified the auth-port or acct-port values in Step 5 , you must also specify those here, as well. The
key value is required and must be 16 ASCII zeros, as shown.
Note Repeat this command for each RADIUS server entered in Step 5 .
Step 9 radius-server vsa send accounting

Example:
Router(config)# radius-server vsa send accounting
Configures the Cisco CMTS to recognize and use accounting-related vendor-specific attributes (VSA).
Step 10 exit
Example:
1199
PacketCable Client Accept Timeout
What to do next
If the connection between a PacketCable CMS and the Cisco CMTS router is not completely established, and
the PacketCable CMS does not correctly terminate the session by sending a TCP FIN message, the connection
shows a COPS server in the output of the show cops server command.
PacketCable Client Accept Timeout

The PacketCable Client Accept Timeout feature supports COPS for PacketCable on the Cisco CMTS router.
This feature also allows you to set timeout values for COPS Telnet connections on the Cisco CMTS router,
and for clearing COPS Telnet sessions.
Telnet errors on the network or Cisco CMTS router might cause incomplete COPS sessions to be created. In
order to address this issue, the timeout timer enables clearing and cleaning of allocated resources for the stale
COPS Telnet sessions on the Cisco CMTS router.
The timeout timer applies to each COPS Telnet connection on the Cisco CMTS router. When this timeout
setting expires, it terminates the Telnet session and clears supporting resources on the Cisco CMTS router.
Step 1 enable
Example:
Router> enable


Example:
Step 3 packetcable timer {T0 timer-value | T1 timer-value | multimedia T1 timer-value}

Example:
Example:
Example:
Router(config)# packetcable timer multimedia T1 400000
1200
Configuration Examples for PacketCable
Sets the PacketCable timer value.
Step 4 end
Example:
Router(config)# end
What to do next
If the connection between a PacketCable CMS and the Cisco CMTS router is not completely established, and
the PacketCable CMS does not correctly terminate the session by sending a TCP FIN message, the connection
shows a COPS server in the output of the show cops server command.
Configuration Examples for PacketCable

This section provides a PacketCable configuration example.
Example: Typical PacketCable Configuration

This section provides a typical configuration for a Cisco CMTS router that has been configured for PacketCable
operations, using default parameters. To use this configuration, you must change the IP addresses for the
RADIUS and RKS servers to match the addresses for the servers in your network.
!
version 15.5
no parser cache
no service pad
service timestamps debug datetime msec localtime show-timezone
service timestamps log datetime msec localtime show-timezone
service internal
service tcp-small-servers max-servers no-limit
!
hostname Router
!
no logging rate-limit
aaa new-model
!
!
aaa group server radius a
server 10.9.62.12 auth-port 1813 acct-port 1812
server 10.9.62.13 auth-port 1813 acct-port 1812
!
aaa accounting network default start-stop group radius group a
aaa session-id common
enable password <delete>
!
cable modulation-profile 2 request 0 16 0 8 qpsk scrambler 152 no-diff 64 fixed uw16
1201
cable modulation-profile 2 initial 5 34 0 48 qpsk scrambler 152 no-diff 128 fixed uw16
cable modulation-profile 2 station 5 34 0 48 qpsk scrambler 152 no-diff 128 fixed uw16
cable modulation-profile 2 short 6 75 6 8 16qam scrambler 152 no-diff 144 shortened uw8
cable modulation-profile 2 long 8 220 0 8 16qam scrambler 152 no-diff 160 shortened uw8
cable qos profile 5 max-burst 1200
cable qos profile 5 max-downstream 2000
cable qos profile 5 max-upstream 128
cable qos profile 5 priority 5
cable qos profile 5 privacy
cable qos profile 7 guaranteed-upstream 87
cable qos profile 7 privacy
cable qos permission enforce 5
cable time-server
no cable privacy accept-self-signed-certificate
ip subnet-zero
!
!
no ip domain-lookup
ip domain-name cisco.com
ip host tftp 10.8.8.8
ip host cnr 10.9.62.17
!
packetcable
packetcable element-id 12456
!
!
!
interface Tunnel0
ip address 10.55.66.3 255.255.255.0
load-interval 30
!
interface Tunnel10
ip address 10.0.1.1 255.255.0.0
!
ip address 10.9.60.10 255.255.0.0
no ip redirects
no ip mroute-cache
full-duplex
!
ip address 172.22.79.44 255.255.254.0
no ip redirects
no ip mroute-cache
full-duplex
!
interface Cable3/0
ip address 10.3.1.1 255.255.255.0
load-interval 30
1202
no keepalive
cable upstream 1 power-level 0
cable upstream 1 channel-width 3200000
cable upstream 1 data-backoff automatic
cable dhcp-giaddr policy
!
router eigrp 48849
network 1.0.0.0
network 10.0.0.0
auto-summary
no eigrp log-neighbor-changes
!
ip default-gateway 10.9.0.1
ip classless
ip route 0.0.0.0 0.0.0.0 172.22.78.1
ip route 10.8.0.0 255.255.0.0 10.9.0.1
ip route 192.168.80.0 255.255.255.0 Tunnel0
ip route 192.168.80.0 255.255.255.0 172.27.184.69
ip route 10.255.254.254 255.255.255.255 10.9.0.1
no ip http server
ip pim bidir-enable
!
!
cdp run
!
!
radius-server host 10.9.62.12 auth-port 1813 acct-port 1812 key 0000000000000000
radius-server retransmit 3
radius-server vsa send accounting
!
line con 0
exec-timeout 0 0
1203
Verifying PacketCable Operations
privilege level 15
line aux 0
line vty 0 4
session-timeout 33
exec-timeout 0 0
password <deleted>
!
ntp clock-period 17179976
ntp server 1.9.35.8
end
Verifying PacketCable Operations

To verify and maintain information about PacketCable operations, use one or more of the following commands:
• show packetcable global
• show packetcable gate
• show packetcable gate ipv6
• show packetcable gate dqos
• show packetcable gate counter commit
To verify the PacketCable configuration, values for the Element ID, maximum number of gates, and the
different CMTS-based DQoS timers, use the show packetcable global command in privileged EXEC mode.
Router# show packetcable global

Packet Cable Global configuration:
Enabled : Yes
Element-ID: 12456
Max Gates : 1048576
Allow non-PacketCable UGS
Default Timer value -
T0 : 30000 msec
T1 : 300000 msec
To verify information about one or more gates in the gate database, use the show packetcable gate command
Router# show packetcable gate summary

GateID i/f SubscriberID GC-Addr State Type SFID(us) SFID(ds)
13582 Ca8/1/0 3.18.1.4 20.5.0.254 RECOVERY Dqos 74
29962 Ca8/1/0 3.18.1.5 20.5.0.254 RECOVERY Dqos 73
46354 Ca8/1/0 ------ 20.5.0.254 RECOVERY Dqos 72
62738 Ca8/1/0 ------ 20.5.0.254 RECOVERY Dqos 69
Total number of gates = 4
Total Gates committed(since bootup or clear counter) = 8
To verify information about one or more PacketCable gates associated with IPv6 subscriber IDs in the gate
database, use the show packetcable gate ipv6 command as shown in the following example:
Router# show packetcable gate ipv6 summary

GateID i/f SubscriberID State SFID(us) SFID(ds)
13582 Ca8/1/0 2001:40:1:42:C0B4:84E5:5081:9B5C COMMIT 74
29962 Ca8/1/0 2001:40:1:42:C0B4:84E5:5081:9B5C COMMIT 73
46354 Ca8/1/0 2001:40:1:42:C0B4:84E5:5081:9B5C COMMIT 72
62738 Ca8/1/0 2001:40:1:42:C0B4:84E5:5081:9B5C COMMIT 69
Total number of gates = 4

1204
Verifying Emergency 911 Calls
To verify information about one or more PacketCable gates associated with IPv4 subscriber IDs in the gate
database, use the show packetcable gate dqos command as shown in the following example:
Router# show packetcable gate dqos summary

13576 Ca8/1/0 40.1.43.60 10.74.58.5 COMMIT DQoS 527 528
29956 Ca8/1/0 40.1.43.56 10.74.58.5 COMMIT DQoS 525 526
Total number of DQOS gates = 2
To verify the total number of gates that the Cisco CMTS router has moved to the Committed state since the
router was last reset, or since the counter was last cleared, use the show packetcable gate counter commit
Router# show packetcable gate counter commit
Total Gates committed (since bootup or clear counter) = 132

This section provides a few examples to illustrate how you can use the show cable calls and show cable modem
calls commands to verify different scenarios associated with Emergency 911 calls.
The following example displays Emergency 911 calls made on the Cable8/1/1 interface on the Cisco CMTS
router during the window set for high priority calls:
Router# show cable calls

Interface ActiveHiPriCalls ActiveAllCalls PostHiPriCallCMs RecentHiPriCMs
C5/0/0 0 0 0 0
C5/0/1 0 0 0 0
C5/1/0 0 0 0 0
C5/1/1 0 0 0 0
C5/1/2 0 0 0 0
C5/1/3 0 0 0 0
C5/1/4 0 0 0 0
C6/0/0 0 0 0 0
C6/0/1 0 0 0 0
C7/0/0 0 0 0 0
C7/0/1 0 0 0 0
C8/1/0 0 0 0 0
C8/1/1 1 1 0 0
C8/1/2 0 0 0 0
C8/1/3 0 0 0 0
C8/1/4 0 0 0 0
Total 1 1 0 0
The following example displays the change on the Cisco CMTS router when this Emergency 911 calls ends:

C5/0/0 0 0 0 0
C5/0/1 0 0 0 0
C5/1/0 0 0 0 0
C5/1/1 0 0 0 0
C5/1/2 0 0 0 0
C5/1/3 0 0 0 0
C5/1/4 0 0 0 0
C6/0/0 0 0 0 0
C6/0/1 0 0 0 0
1205
C7/0/0 0 0 0 0
C7/0/1 0 0 0 0
C8/1/0 0 0 0 0
C8/1/1 0 0 0 1
C8/1/2 0 0 0 0
C8/1/3 0 0 0 0
C8/1/4 0 0 0 0
Total 0 0 0 1
The following example displays information that is available when making a voice call from the same MTA
to another MTA on the same interface:

C5/0/0 0 0 0 0
C5/0/1 0 0 0 0
C5/1/0 0 0 0 0
C5/1/1 0 0 0 0
C5/1/2 0 0 0 0
C5/1/3 0 0 0 0
C5/1/4 0 0 0 0
C6/0/0 0 0 0 0
C6/0/1 0 0 0 0
C7/0/0 0 0 0 0
C7/0/1 0 0 0 0
C8/1/0 0 0 0 0
C8/1/1 0 2 1 1
C8/1/2 0 0 0 0
C8/1/3 0 0 0 0
C8/1/4 0 0 0 0
Total 0 2 1 1
The following example displays information that is available when a voice call from the same MTA to another
MTA on the same interface ends:

C5/0/0 0 0 0 0
C5/0/1 0 0 0 0
C5/1/0 0 0 0 0
C5/1/1 0 0 0 0
C5/1/2 0 0 0 0
C5/1/3 0 0 0 0
C5/1/4 0 0 0 0
C6/0/0 0 0 0 0
C6/0/1 0 0 0 0
C7/0/0 0 0 0 0
C7/0/1 0 0 0 0
C8/1/0 0 0 0 0
C8/1/1 0 0 0 1
C8/1/2 0 0 0 0
C8/1/3 0 0 0 0
C8/1/4 0 0 0 0
Total 0 0 0 1
The following examples display the show cable modem calls command output on the Cisco CMTS router
over a period of time, with changing call status information. The call information disappears when a call ends.
Router# show cable modem calls

Cable Modem Call Status Flags:
H: Active high priority calls
R: Recent high priority calls
1206
V: Active voice calls (including high priority)

MAC Address IP Address I/F Prim CMCallStatus LatestHiPriCall
Sid (min:sec)
0000.cab7.7b04 10.10.155.38 C8/1/1/U0 18 R 0:39
Sid (min:sec)
The following example displays a new Emergency 911 call on the Cisco CMTS router:

Sid (min:sec)
0000.cab7.7b04 10.10.155.38 C8/1/1/U0 18 HV 1:30
The following example displays the end of the Emergency 911 call on the Cisco CMTS router:

Sid (min:sec)
0000.cab7.7b04 10.10.155.38 C8/1/1/U0 18 R 0:3
The following example displays a non-emergency voice call on the Cisco CMTS router from the same MTA:

Sid (min:sec)
0000.ca36.f97d 10.10.155.25 C8/1/1/U0 5 V -
0000.cab7.7b04 10.10.155.38 C8/1/1/U0 18 RV 0:30
The following example displays the end of the non-emergency voice call on the Cisco CMTS router:

Sid (min:sec)
0000.cab7.7b04 10.10.155.38 C8/1/1/U0 18 R 0:36
1207
Information About PacketCable Multimedia Operations
Information About PacketCable Multimedia Operations

The PacketCable Multimedia (PCMM) feature is a powerful implementation of the CableLabs® standards for
PacketCable Multimedia. PCMM provides enhanced QoS for multimedia applications, voice, and
bandwidth-intensive services over a DOCSIS (DOCSIS 1.1 and later versions) network.
The Cisco CMTS router supports DOCSIS QoS for SIP-based telephones and SIP video phones,
Bandwidth-on-Demand applications, and network-based gaming applications, all of which place extensive
bandwidth demands on the network.
This section provides information about the following aspects of PacketCable Multimedia for the Cisco CMTS
router, emphasizing PCMM components that are configured with the Cisco IOS command-line interface later
in this document:
PCMM Overview
The following network components are required to support the PCMM feature:
• Application Server—Responsible for relaying client requests to the Application Manager.
• Application Manager—Responsible for application or session-level state and for applying session control
domain (SCD) policy.
• Policy Server—Responsible for applying the RCD policy and for managing relationships between the
Application Manager and a Cisco CMTS router.
• Cisco CMTS router—Responsible for performing admission control and managing network resources
through DOCSIS service flows.
Figure below provides an architectural overview of the PCMM functionality:
1208
PCMM Enhancements over PacketCable 1.x
Figure 32: PCMM Architectural Overview
PCMM Enhancements over PacketCable 1.x

PacketCable Multimedia is a service delivery framework that leverages and uses as much of existing
PacketCable 1.x deployments and functionality as possible. Furthermore, PCMM offers powerful enhancements
to the VoIP service delivery framework with straightforward CLI implementation. The key enhancements
that the PCMM provides are:
• Time and volume based network resource authorizations are based on DOCSIS 1.1 Quality of Service
(QoS) mechanisms.
• Event-based network resource auditing and management functions.
• Secure infrastructure that protects all interfaces at appropriate levels.
• Preauthorized model from PacketCable 1.x, where the PCMM gate installation and management is
supplemented with service flow creation, modification and deletion functions. Together, these provide
a secure, network-based QoS.
PCMM and High Availability Features on the Cisco CMTS Router

High Availability on the Cisco CMTS router accommodates synchronization of service flows created for the
PCMM applications and the PCCM gate.
1209
PCMM Gates
PCMM Gates
PCMM Gate Overview and PCMM Dynamic Quality of Service
A PacketCable 1.x gate defines QoS parameters and policy-based authorization for subscribers, and a specific
envelope of network resources. A PacketCable 1.x gate also maintains classifiers for originating and terminating
IP addresses and ports.
The subscriber ID can identify both IPv4 and IPv6 addresses of either the cable modem or the client CPE.
PacketCable 1.x defines a preauthorization model. The PacketCable gates are created and installed at the
Cisco CMTS router prior to network resource reservation or activation requests. This process, termed gate
control, is managed through a COPS-based policy interface on the Cisco CMTS router.
In PCMM, this COPS-based interface is enhanced for QoS life-cycle management. PCMM gates maintain
service flow creation, modification and deletion functions to provide for network-based QoS. Multiple PCMM
gates and service flow policies can be maintained on the Cisco CMTS router at a given time, and these PCMM
gates are fully interoperable with PacketCable 1.x gates.
When a cable modem subscriber requests bandwidth for a network-intensive application, the network Policy
Server sends a Gate-Set message to the Cisco CMTS router. This message contains QoS, service flow, and
billing information for this subscriber. This gate profile information is maintained on the Cisco CMTS router,
to include PCMM gate states and PCMM state transitions.
The Cisco CMTS router initiates service flows with cable modems, and optimizes DOCSIS resource availability
on the Cisco CMTS router for bandwidth-intensive service flows characteristic to PCMM.
Restrictions
On some upstream paths, best effort service flows are configured on some modems with Committed Information
Rate (CIR). When a number of bandwidth requests are queued in the modems, only a few requests are sent
to the CMTS. This occurs due to congestion of sending requests caused by higher number of service flows,
greater traffic and small size of packets. Therefore, only a few best effort service flow requests are satisfied
by the CMTS.
PCMM Persistent Gate

Persistent Gate is a feature by which PCMM gate information is maintained for cable modems that go offline.
This gate information is quickly enabled after a cable modem returns online. When a cable modem returns
online, the Cisco CMTS router scans PCMM gates previously stored, and initiates service to the cable modem
according to the respective PCMM gate. This re-enabled service maintains traffic support profiles for that
gate, and allocates DOCSIS resources based on the new online subscriber.
PCMM High Priority Calls

From Cisco IOS XE Amsterdam 17.3.1x release, you can specify the SessionClassID of the PCMM gate that
the Cisco cBR has to consider as high priority (911) calls. Previously the Cisco cBR considered a
SessionClassID of 0xF as high priority (911) calls.
Use the packetcable multimedia high-priority priority command to set SessionClassID of high priority
(911) calls. You can use show cable calls and show cable modem calls to display the ongoing high priority
calls.
1210
PCMM Interfaces
Note • The default SessionClassID for high priority PCMM calls is 15(0xF).
• Enable packetcable multimedia before you use packetcable multimedia high-priority priority.
• The Cisco cBR always considers PCMM gates with SessionClassID 15(0xF) as high priority class even
after you set a different high priority SessionClassID.
Example: Configuring a Different SessionClassID for High Priority Calls

The following example shows how to set the SessionClassID for high priority calls to 7.
Router(config)# packetcable multimedia
Router(config)# packetcable multimedia high-priority 7
PCMM Interfaces
PCMM optimizes the IPC handshake between the cable interface line card and the Route Processor (RP) for
the Cisco CMTS router. Additional PCMM interface changes from PacketCable 1.x include the handling for
COPS interface and distributed cable interface line cards.
PCMM to COPS Interface

PCMM differs from PacketCable 1.x in handling COPS sessions. The COPS sessions on PCMM use TCP
port number 3918 by default. Whereas, PacketCable uses the DQoS specification for TCP port requirements
and COPS sessions.
When the PCMM module initializes for the first time, a PCMM registry is added to the cable interface line
card and the route processor. The PCMM module also registers the PCMM COPS client with the COPS layer
on the Cisco CMTS router.
PCMM and Distributed Cable Interface Line Cards

As with PacketCable 1.x, PCMM uses IPC messages for voice support. When PCMM gates are created on
the Network Processing Engine (NPE) or route processor (RP), the PCMM gate parameters are sent to cable
interface line cards. IPC maintains all communication between the NPE or RP, and the cable interface line
cards.
Event messaging is used with PCMM to support billing information based on Gate-Set messages. Event
messaging for distributed cable interface line cards originates from the line cards, based on the success of
DSX operation.
The PCMM module also registers the PCMM COPS client with the COPS layer.
PCMM Unicast and Multicast

In unicast transmission, content is sent to a unique user. In multicast transmission, content is sent to multiple
users simultaneously.
1211
PCMM Multicast Session Range
PCMM Multicast Session Range

You can configure a PCMM multicast session range by specifying IPv4 IP addresses and a mask for a PCMM
multicast group. The PCMM multicast session range enables the Cisco CMTS router to accept Gate-Set
messages from the PCMM Policy Server. If a PCMM multicast session range is configured, the Cisco CMTS
router does not allow you to create multicast sessions using other sources such as Internet Group Management
Protocol (IGMP) and DOCSIS Set-Top Gateway (DSG).
How to Configure PCMM Operations

The following tasks describe how to enable PCMM operations and configure its related features on the Cisco
CMTS router:
Enabling PCMM Operations on the Cisco CMTS Router

To enable PCMM operations on the Cisco CMTS router:
Step 1 enable
Example:
Router> enable


Example:
Step 3 packetcable multimedia

Example:
Enables and displays PCMM processing on the Cisco CMTS router. This command enables the Cisco CMTS router to
start or stop responding to PCMM COPS messages received from the PCMM Policy Server.
Step 4 packetcable authorize vanilla-docsis-mta

Example:
Allows non-DQoS MTAs to send DOCSIS DSX messages.
Step 5 packetcable gate maxcount n
1212
Configuring a PCMM Multicast Session Range
Example:
Sets the maximum number of PCMM gates in the gate database.
Step 6 packetcable timer multimedia T1 timer-value

Example:
Router(config)# packetcable timer multimedia T1 300000
Sets the timeout value for T1 timer used in PCMM gate processing.
Step 7 clear packetcable gate counter commit [dqos | multimedia]

Example:
Router(config)# clear packetcable gate counter commit multimedia
(Optional) Clears the specified PCMM gate counter.
Step 8 end
Example:
Router(config)# end
Configuring a PCMM Multicast Session Range

A PCMM multicast session range enables the Cisco CMTS router to use a range of IP addresses for a PCMM
multicast group.
Before you begin

Ensure that PCMM is configured using the packetcable multimedia command.
Note • You can configure only one PCMM multicast group on the Cisco CMTS router. You can configure a
maximum of ten multicast sessions for a single multicast group.
• The PCMM multicast feature is supported only with the cable modems that are capable of Multicast
DSID-based Forwarding (MDF).
Step 1 enable
Example:
Router> enable
1213
Configuration Examples for PacketCable Multimedia


Example:
Step 3 cable multicast source pcmm

Example:
Router(config)# cable multicast source pcmm
Enables PCMM-based multicast service on the Cisco CMTS router and enters multicast session range configuration
mode.
Step 4 session-range ip-addressip-mask

Example:
Router(config)# session-range 229.0.0.0 255.0.0.0
Configures a session range for the PCMM multicast group.
Step 5 end
Example:
Router(config)# end
Configuration Examples for PacketCable Multimedia

The following sections provide configuration examples for PCMM operations on the Cisco CMTS router:
Example: Enabling PCMM Operations on the Cisco CMTS Router

Router(config)# packetcable timer multimedia 30000
1214
Example: Enabling a Multicast Session Range on the Cisco CMTS Router
Example: Enabling a Multicast Session Range on the Cisco CMTS Router

Router(config)# cable multicast source pcmm
Router(config)# session-range 229.0.0.0 255.0.0.0
Verifying PCMM Operations

Use the following show commands to verify PCMM operations:
• show packetcable gate multimedia
• show cable multicast db
• show interface wideband-cable
• show cable multicast qos
To verify the PCMM multicast gates, use the show packetcable gate multimedia command as shown in the
following example:
Router# show packetcable gate multimedia multicast summary

134 Ca5/0/0 60.1.1.202 2.39.26.19 COMMIT MM 4
Total number of Multimedia-MCAST gates = 1
To verify the PCMM IPv6 gates, use the show packetcable gate multimedia ipv6command as shown in the
following example:
Router# show packetcable gate multimedia ipv6 summary

Time source is NTP, 03:29:42.153 EST Mon Nov 9 2015
GateID i/f SubscriberID State SFID(us) SFID(ds)

409 Ca5/0/2 2001:420:2C7F:FC38:58AF:E36A:80:213A COMMIT 1326
16789 Ca5/0/2 2001:420:2C7F:FC38:AC40:A49A:F80A:8D0B COMMIT 1321

33177 Ca5/0/2 2001:420:2C7F:FC38:DD49:72A3:2ECC:8770 COMMIT 1322
49577 Ca5/0/2 2001:420:2C7F:FC38:485:31DF:C88B:E315 COMMIT 1308

65953 Ca5/0/2 2001:420:2C7F:FC38:5AB:AA0B:34AD:ACCF COMMIT 1336
82337 Ca5/0/2 2001:420:2C7F:FC38:5AB:AA0B:34AD:ACCF COMMIT 1337
98721 Ca5/0/2 2001:420:2C7F:FC38:5570:EF2E:7565:D36A COMMIT 1316
115097 Ca5/0/2 2001:420:2C7F:FC38:6009:EF26:F573:7356 COMMIT 1318
131489 Ca5/0/2 2001:420:2C7F:FC38:7D4A:BC50:3FD:CA7 COMMIT 1312

147873 Ca5/0/2 2001:420:2C7F:FC38:E83E:8259:AEF6:5624 COMMIT 1332
Total number of Multimedia gates = 10

To verify all the PCMM client entries available with the multicast database, use the show cable multicast
db command as shown in the following example:
1215
Verifying PCMM Operations
Router# show cable multicast db client pcmm

Interface : Bundle1
Session (S,G) : (*,229.2.2.12)
Fwd Intf Bundle Intf Host Intf CM MAC CPE IP Gate-ID SFID
Wi1/1/0:0 Bundle1 Ca5/0/0 0018.6852.8056 60.1.1.202 134 4
To verify multicast sessions on a specific wideband cable interface, use the show interface wideband-cable
Router# show interface wideband-cable 1/1/0:0 multicast-sessions

Default Multicast Service Flow 3 on Wideband-Cable1/1/0:0
Source : N/A
Act GCRs : 1
512 8196 4 0 512 0
To verify the attribute-based assignment of service flows on a specific wideband cable interface, use the show
interface wideband-cable command as shown in the following example:
Router# show interface wideband-cable 1/1/0:0

service-flow 4 verbose
Sfid : 4
Mac Address : ffff.ffff.ffff
Type : Secondary(Static)
Direction : Downstream
Current State : Active
Current QoS Indexes [Prov, Adm, Act] : [4, 4, 4]
Active Time : 05:26
Required Attributes : 0x00000000
Forbidden Attributes : 0x00000000
Aggregate Attributes : 0x00000000
Multicast Sid : 8196
Traffic Priority : 0
Maximum Sustained rate : 0 bits/sec
Maximum Burst : 3044 bytes
Minimum Reserved Rate : 250000 bits/sec
Minimum Packet Size : 0 bytes
Maximum Latency : 0 usecs
Peak Rate : 0 bits/sec
Admitted QoS Timeout : 200 seconds
Active QoS Timeout : 0 seconds
Packets : 0
Bytes : 0
Rate Limit Delayed Packets : 0
Rate Limit Dropped Packets : 0
Current Throughput : 0 bits/sec, 0 packets/sec
Application Priority : 0
Low Latency App : No
Blaze/JIB3 DS Statistic Index : 0
Forwarding Interface : Wi1/1/0:0
Classifiers: NONE
To verify that the PCMM-based MQoS gate controllers are created using the correct session ranges, use the
show cable multicast qoscommand as shown in the following example:
1216
High Availability Stateful Switchover (SSO) for PacketCable and PacketCable MultiMedia
Router# show cable multicast qos group-qos

Group QOS Index Service Class Control Igmp Limit Override App
DEFAULT mcast_default Aggregate NO-LIMIT
1 SDV_SD Single --- No CLI
512 SDV_HD Single --- No PCMM
High Availability Stateful Switchover (SSO) for PacketCable

and PacketCable MultiMedia
Enhanced high availability support enables the synchronization of PacketCable and PacketCable MultiMedia
(PCMM) gates during switchover events on the Cisco CMTS router. This enhancement is enabled by default.
This functionality uses the existing per-interface HCCP commands that are used to associate the working and
protect interfaces in the case of N+1 redundancy.
PacketCable and PCMM with Admission Control

A PacketCable or PacketCable Multimedia network contains a number of components that benefit from
Admission Control QoS. Admission Control manages and optimizes QoS for PacketCable and PCMM in
these ways:
• QoS (based on DOCSIS 1.1 or later versions) for voice and data
• Cable modem registration
• CMS
• Gateway controllers (GC)
• Record keeping servers (RKS)
• Video telephony
When configuring Admission Control with either PacketCable or PCMM, PacketCable or PCMM must be
fully operational on the Cisco CMTS headend prior to gaining the benefits from Admission Control.
Voice MGPI Support

The multiple grants per interval (MGPI) feature enables the Cisco CMTS router to map multiple PacketCable
Multimedia gates (application flows) to a single DOCSIS service flow using UGS traffic profiles of the same
cable modem. In other words, the Cisco CMTS router increases the number of grants per interval for each
application flow based on a single service flow, resulting in multiple grants per interval.
The MGPI feature supports the flow-aggregated voice MGPI functionality based on CableLabs PacketCable
Specification (PKT-SP-MM-I05-091029). The flow-aggregated MGPI functionality allows the application
manager to use the UGS traffic profile to explicitly set the number of grants per interval and place several
application flows on a single gate. This results in an aggregated view for event messages, volume, and time
usage limits.
1217
Voice Support Over DOCSIS 3.0 E-MTAs
Voice Support Over DOCSIS 3.0 E-MTAs

PacketCable and PCMM services are supported on embedded multimedia terminal adapters (E-MTAs). An
E-MTA is a network element that contains the interface to a physical voice device, a network interface, and
all signaling and encapsulation functions required for the VoIP transport, class features signaling, and QoS
signaling.
PacketCable and PCMM Call Trace

To effectively capture signaling information, this functionality buffers signaling for a configured number of
PacketCable or PCMM gates. By default, only ten user-configured gate traces are saved in a buffer. After the
specified number is reached, any subsequent gate signaling information does not get buffered. When one of
the gates being traced is deleted, gate signaling of a new gate is buffered.
Use the cable dynamic-qos trace command in global configuration mode to enable the call trace functionality
for PacketCable and PacketCable Multimedia gates on the Cisco CMTS router. You will have to specify the
number of subscribers for whom call trace needs to be enabled.
Verifying PacketCable and PCMM Statistics

Use the following commands to verify PacketCable and PCMM statistics on the Cisco CMTS router:
• show interface cable dynamic-service statistics
• show interface cable packetcable statistics
• show packetcable cms
To verify dynamic service statistics based on the cable interface, use the show interface cable dynamic-service
statistics command as shown in the following example:
Router# show interface cable 7/1/0 dynamic-service statistics

Upstream Downstream
DSA REQ 0 5
DSA RSP 5 0
DSA ACK 0 5
DSC REQ 0 5
DSC RSP 5 0
DSC ACK 0 5
DSD REQ 0 0
DSD RSP 0 0
Retransmission counts
Upstream Downstream
DSA REQ 0 0
DSA RSP 0 0
DSA ACK 0 0
DSC REQ 0 5
DSC RSP 5 0
DSC ACK 0 0
DSD REQ 0 0
DSD RSP 0 0
To verify PacketCable IPC statistics based on the cable interface, use the show interface cable packetcable
statistics command as shown in the following example:
Router# show interface cable 7/1/0 packetcable statistics

Packetcable IPC Statistics on RP
Msg create gate gate gate set dsd
1218
Verifying PacketCable and PCMM Statistics
gie set del notify notify

Sent 0 10 0 0 0
Rcvd 0 0 0 10 0
Packetcable IPC Statistics on LC
Msg create gate gate gate set dsd
gie set del notify notify
Sent 0 0 0 10 0
Rcvd 0 10 0 0 0
To verify all gate controllers that are currently connected to the PacketCable client, use the show packetcable
cms command as shown in the following example:
Router# show packetcable cms

GC-Addr GC-Port Client-Addr COPS-handle Version PSID Key PDD-Cfg
1.100.30.2 47236 2.39.34.1 0x2FF9E268/1 4.0 0 0 0
2.39.26.19 55390 2.39.34.1 0x2FF9D890/1 1.0 0 0 2
To verify all gate controllers including the COPS servers for which the PacketCable connection is gone down,
use the show packetcable cms command with the all keyword as shown in the following example:
Router# show packetcable cms all

1.100.30.2 47236 2.39.34.1 0x2FF9E268/1 4.0 0 0 0
2.39.26.19 55390 2.39.34.1 0x2FF9D890/1 1.0 0 0 2
1.10.30.22 42307 2.39.34.1 0x0 /0 4.0 0 0 0
To verify gate controller statistics, use the show packetcable cms command with the keyword, verbose, as
Router# show packetcable cms verbose

Gate Controller
Addr : 1.100.30.2
Port : 47236
Client Addr : 2.39.34.1
COPS Handle : 0x2FF9E268
Version : 4.0
Statistics :
gate del = 0 gate del ack = 0 gate del err = 0
gate info = 0 gate info ack = 0 gate info err = 0
gate open = 0 gate report state = 0
gate set = 0 gate set ack = 0 gate set err = 0
gate alloc = 0 gate alloc ack = 0 gate alloc err = 0
gate close = 0
Gate Controller
Addr : 2.39.26.19
Port : 55390
Client Addr : 2.39.34.1
COPS Handle : 0x2FF9D890
Version : 1.0
Statistics :
gate del = 0 gate del ack = 0 gate del err = 0
gate info = 0 gate info ack = 0 gate info err = 0
gate open = 0 gate report state = 0
gate set = 2 gate set ack = 2 gate set err = 0
PCMM Timers Expired
Timer T1 = 0 Timer T2 = 0 Timer T3 = 0 Timer T4 = 0
1.100.30.2 47236 2.39.34.1 0x2FF9E268/1 4.0 0 0 0
2.39.26.19 55390 2.39.34.1 0x2FF9D890/1 1.0 0 0 2
1219
Related Documents

Topic

commands
N+1 N+1 Redundancy for the Cisco CMTS Routers

redundancy
http://www.cisco.com/en/US/docs/ios/cable/configuration/guide/cmts_nplus1_redun_ps2209_TSD_Produc
NTP or To configure the Cisco CMTS router to use Network Time Protocol (NTP) or Simple Network Time Proto
SNTP the “Performing Basic System Management” chapter in the “System Management” section of the Cisco IO
Configuration Configuration Guide.
Standards
5
Standards Title
PKT-SP-MM-I06-110629 PacketCable™ Specification Multimedia Specification
ITU X.509 V3 International Telecommunications Union (ITU) X.509 Version 3.0 standard
PKT-EM-I03-011221 PacketCable™ Event Message Specification
PKT-SP-DQOS-I04-021018 PacketCable™ Dynamic Quality-of-Service Specification
PKT-SP-EC-MGCP-I04-011221 PacketCable™ Network-Based Call Signaling Protocol Specification
PKT-SP-ESP-I01-991229 PacketCable™ Electronic Surveillance Specification
PKT-SP-ISTP-I02-011221 PacketCable™ Internet Signaling Transport Protocol (ISTP) Specification
PKT-SP-PROV-I03-011221 PacketCable™ MTA Device Provisioning Specification

5
Not all supported standards are listed.
MIBs
MIBs MIBs Link
No new or changed MIBs are To locate and download MIBs for selected platforms, Cisco software
supported by this feature. releases, and feature sets, use Cisco MIB Locator found at the
following URL:
1220
Feature Information for PacketCable and PacketCable Multimedia
RFCs
RFCs Title
RFC 1321 The MD5 Message-Digest Algorithm
RFC 1510 The Kerberos Network Authentication Service (V5)
RFC 2138 Remote Authentication Dial In User Service (RADIUS)
RFC 2205 Resource ReSerVation Protocol (RSVP)
RFC 2327 SDP: Session Description Protocol
RFC 2748 The COPS (Common Open Policy Service) Protocol
Description Link

Feature Information for PacketCable and PacketCable

Multimedia
PacketCable and PacketCable Cisco IOS XE Everest 16.6.1 This feature was integrated into
Multimedia Unicast Cisco IOS XE Everest 16.6.1 on
Broadband Routers.
1221
Feature Information for PacketCable and PacketCable Multimedia
PacketCable and PacketCable Cisco IOS XE Everest 16.6.1 This feature was integrated into
Multimedia Multicast Cisco IOS XE Everest 16.6.1 on
Broadband Routers.
DQoSLite Based IPv6 Voice Cisco IOS XE Everest 16.6.1 This feature was integrated into
Support Cisco IOS XE Everest 16.6.1 on
Broadband Routers.
1222
CHAPTER 85
COPS Engine Operation
This document describes the Common Open Policy Service (COPS) engine feature on the Cisco CMTS routers.
The Cisco CMTS routers also support Access control lists (ACLs) with the COPS engine.
• Prerequisites for the COPS Engine on the Cisco CMTS Routers, on page 1225
• Restrictions for the COPS Engine on the Cisco CMTS, on page 1225
• Information About the COPS Engine on the Cisco CMTS, on page 1225
• How to Configure the COPS Engine on the Cisco CMTS, on page 1225
• COPS Engine Configuration Examples for Cable, on page 1230
• Feature Information for COPS Engine Operation, on page 1232

1223
Digital PICs:

Module:

Modules:
line card reload.
1224
Prerequisites for the COPS Engine on the Cisco CMTS Routers
Prerequisites for the COPS Engine on the Cisco CMTS Routers

• A compatible policy server must be connected to the network, such as the Cisco COPS QoS Policy
Manager.
• Compliance with administrative policy, such as the Computer Assisted Law Enforcement Act (CALEA)
or other lawful intercept (LI), is required for use of this feature on the Cisco CMTS routers.
Restrictions for the COPS Engine on the Cisco CMTS

• Resource Reservation Protocol (RSVP) is not configured on the Cisco CMTS. COPS engine configuration
on the Cisco CMTS is limited to networks in which separate RSVP and COPS Servers are configured
and operational.
Information About the COPS Engine on the Cisco CMTS

Common Open Policy Service (COPS) is a protocol for communicating network traffic policy information
to network devices.
COPS works in correspondence with the Resource Reservation Protocol (RSVP), which is a means for reserving
network resources—primarily bandwidth—to guarantee that applications sending end-to-end across the Internet
will perform at the desired speed and quality. RSVP is not configured on the Cisco CMTS, but the Cisco
CMTS presumes RSVP on the network for these configurations.
Refer to the Additional References, on page 1231 for further information about COPS for RSVP.
How to Configure the COPS Engine on the Cisco CMTS

This section describes the tasks for configuring the COPS for RSVP feature on the Cisco CMTS.
To configure the COPS engine on the Cisco CMTS, perform the following tasks:
Configuring COPS TCP and DSCP Marking

This feature allows you to change the Differentiated Services Code Point (DSCP) marking for COPS messages
that are transmitted or received by the Cisco router. The cops ip dscp command changes the default IP
parameters for connections between the Cisco router and COPS servers in the cable network.
DSCP values are used in Quality of Service (QoS) configurations on a Cisco router to summarize the
relationship between DSCP and IP precedence. This command allows COPS to remark the packets for either
incoming or outbound connections.
The default setting is 0 for outbound connections. On default incoming connections, the COPS engine takes
the DSCP value from the COPS server initiating the TCP connection.
Note This feature affects all TCP connections with all COPS servers.
1225
Configuring COPS TCP and DSCP Marking
• For messages transmitted by the Cisco router, the default DSCP value is 0.
• For incoming connections to the Cisco router, the COPS engine takes the DSCP value used by the COPS
server that initiates the TCP connection, by default.
• The cops ip dscp command allows the Cisco router to re-mark the COPS packets for either incoming or
outbound connections.
• This command affects all TCP connections with all COPS servers.
• This command does not affect existing connections to COPS servers. Once you issue this command, this
function is supported only for new connections after that point in time.
Perform the following steps to enable optional DSCP marking for COPS messages on the Cisco CMTS.
Procedure

Router> enable

Example:
Step 3 cops ip dscp [<0-63> | default | af11-af43 | cs1-cs7] Specifies the marking for COPS messages that are
transmitted by the Cisco router.
Example:
The values for this command specify the markings with
Router(config)# cops ip dscp default which COPS messages are transmitted. The following
values are supported for the Cisco CMTS router:
• 0-63—DSCP value ranging from 0-63.
• af11—Use AF11 dscp (001010)
• af12—Use AF12 dscp (001100)
• af13—Use AF13 dscp (001110)
• af21—Use AF21 dscp (010010)
• af22—Use AF22 dscp (010100)
• af23—Use AF23 dscp (010110)
• af31—Use AF31 dscp (011010)
• af32—Use AF32 dscp (011100)
• af33—Use AF33 dscp (011110)
• af41—Use AF41 dscp (100010)
• af42—Use AF42 dscp (100100)
• af43—Use AF43 dscp (100110)
• cs1—Use CS1 dscp (001000) [precedence 1]
1226
Configuring COPS TCP Window Size

• default—Use default dscp (000000)
• ef—Use EF dscp (101110)

Example:
Router#
Configuring COPS TCP Window Size

This feature allows you to override the default TCP receive window size that is used by COPS processes.
This setting can be used to prevent the COPS server from sending too much data at one time.
Perform the following steps to change the TCP Window size on the Cisco CMTS.
Procedure

Router> enable

Example:
Step 3 cops tcp window-size bytes Overrides the default TCP receive window size on the Cisco
CMTS. To return the TCP window size to a default setting
Example:
of 4K, use the no form of this command.
Note The default COPS TCP window size is 4000
Router(config)# cops tcp window-size 64000 bytes.
Note This command does not affect existing
connections to COPS servers. Once you issue
this command, this function is supported only
for new connections after that point in time.
Note This command affects all TCP connections with
all COPS servers.

Example:
1227
Configuring Access Control List Support for COPS Engine
Router#
Configuring Access Control List Support for COPS Engine

Perform the following steps to configure COPS ACLs on the Cisco CMTS.
Procedure

Router> enable

Example:
Step 3 cops listeners access-list{ acl-num |acl-name } Configures access control lists (ACLs) for inbound
connections to all COPS listener applications on the Cisco
Example:
CMTS. To remove this setting from the Cisco CMTS, us
the no form of this command.
Router# cops listeners access-list 40

Example:
Router#
What to do next
Access lists can be displayed by using the show access-list command in privileged EXEC mode.
Restricting RSVP Policy to Specific Access Control Lists

Perform the following steps to restrict the RSVP policy to specific ACLs, as already configured on the Cisco
CMTS.
For ACL configuration, refer to the Configuring Access Control List Support for COPS Engine, on page 1228.
1228
Displaying and Verifying COPS Engine Configuration on the Cisco CMTS
Procedure

Router> enable

Example:
Step 3 interface cable (slot /subslot /port } Enters interface configuration mode.
Example:
Router(config)#interface cable 8/0/1

Router(config-if)#
Step 4 ip rsvp policy cops ACL-1 ACL-2 servers iP-addr1 Tells the router to apply RSVP policy to messages that
IP-addr2 match the specified ACLs, and specifies the COPS server
or servers for those sessions.
Example:
Router(config-if)# ip rsvp policy cops 40 160

servers 161.44.130.164 161.44.129.2

Example:
Router#
Displaying and Verifying COPS Engine Configuration on the Cisco CMTS

Once COPS is enabled and configured on the Cisco CMTS, you can verify and track configuration by using
one or all of the show commands in the following steps.
Procedure

Router> enable
Step 2 show cops servers Displays server addresses, port, state, keepalives, and policy
client information.
Example:
Router# show cops servers
1229
Show Commands for COPS Engine Information

Step 3 show ip rsvp policy cops Displays policy server addresses, ACL IDs, and client/server
connection status.
Example:
Router# show ip rsvp policy cops
Step 4 show ip rsvp policy Displays ACL IDs and their connection status.
Example:
Router# show ip rsvp policy
Show Commands for COPS Engine Information

The following examples display three views of the COPS engine configuration on the Cisco router. These
respective show commands verify the COPS engine configuration.
Displaying COPS Servers on the Network

This example displays the policy server address, state, keepalives, and policy client information:

COPS SERVER: Address: 161.44.135.172. Port: 3288. State: 0. Keepalive: 120 sec
Number of clients: 1. Number of sessions: 1.
COPS CLIENT: Client type: 1. State: 0.
Displaying COPS Policy Information on the Network

This example displays the policy server address, the ACL ID, and the client/server connection status:

COPS/RSVP entry. ACLs: 40 60
PDPs: 161.44.135.172
Current state: Connected
Currently connected to PDP 161.44.135.172, port 0
Displaying Access Lists for COPS

This example displays the ACL ID numbers and the status for each ACL ID:

Local policy: Currently unsupported
COPS:
ACLs: 40 60 . State: CONNECTED.
ACLs: 40 160 . State: CONNECTING.
COPS Engine Configuration Examples for Cable

The following sections provide COPS for RSVP configuration examples on the Cisco CMTS:
1230
Example: COPS Server Specified
Example: COPS Server Specified

The following example specifies the COPS server and enables COPS for RSVP on the server. Both of these
functions are accomplished by using the ip rsvp policy cops command. By implication, the default settings
for all remaining COPS for RSVP commands are accepted.

Router(config)# ip rsvp policy cops servers 161.44.130.168 161.44.129.6
Example: COPS Server Display

The following examples display three views of the COPS for RSVP configuration on the router, which can
be used to verify the COPS for RSVP configuration.
This example displays the policy server address, state, keepalives, and policy client information:

COPS SERVER: Address: 161.44.135.172. Port: 3288. State: 0. Keepalive: 120 sec
Number of clients: 1. Number of sessions: 1.
COPS CLIENT: Client type: 1. State: 0.
This example displays the policy server address, the ACL ID, and the client/server connection status:

COPS/RSVP entry. ACLs: 40 60
PDPs: 161.44.135.172
Current state: Connected
Currently connected to PDP 161.44.135.172, port 0
This example displays the ACL ID numbers and the status for each ACL ID:

Local policy: Currently unsupported
COPS:
ACLs: 40 60 . State: CONNECTED.
ACLs: 40 160 . State: CONNECTING.
Related Documents
Cisco CMTS Commands Cisco CMTS Cable Command Reference
COPS for RSVP • Configuring COPS for RSVP

http://www.cisco.com/en/US/docs/ios-xml/ios/qos_rsvp/configuration/12-4t/cops_rsvp.htm
• COPS for RSVP
http://www.cisco.com/en/US/docs/ios/12_1t/12_1t1/feature/guide/CopsRSVP.html
1231
Feature Information for COPS Engine Operation
Standards
Standard Title
PKT-SP-ESP-I01-991229 PacketCable™ Electronic Surveillance Specification ( http://www.packetcable.com

)
MIBs
MIB MIBs Link
• No MIBs have been introduced or To locate and download MIBs for selected platforms, Cisco IOS
enhanced for support of this feature. releases, and feature sets, use Cisco MIB Locator found at the
following URL:
RFCs
RFC Title
General RFC Resources • RFC Index Search Engine

http://www.rfc-editor.org/rfcsearch.html
• SNMP: Frequently Asked Questions About MIB RFCs
http://www.cisco.com/en/US/tech/tk648/tk362/technologies_q_and_a_item09186a00800c2612.s
Description Link
The Cisco Technical Support & Documentation website contains thousands http://www.cisco.com/techsupport
of pages of searchable technical content, including links to products,
technologies, solutions, technical tips, and tools. Registered Cisco.com
users can log in from this page to access even more content.

1232
Table 208: Feature Information for COPS Engine Operation
COPS Engine Operation Cisco IOS XE Everest 16.6.1 This feature was integrated into
Broadband Routers.
1233
1234
PA R T X
Quality of Services Configuration
• Dynamic Bandwidth Sharing, on page 1237
• Modular Quality of Service Command-Line Interface QoS, on page 1245
• DOCSIS 1.1 for the Cisco CMTS Routers, on page 1265
• Default DOCSIS 1.0 ToS Overwrite, on page 1305
• DOCSIS WFQ Scheduler on the Cisco CMTS Routers, on page 1311
• Fairness Across DOCSIS Interfaces, on page 1321
• Service Group Admission Control, on page 1335
• Subscriber Traffic Management, on page 1349
• Narrowband Digital Forward And Narrowband Digital Return, on page 1377
• Differentiated Services Code Point Downstream, on page 1389
CHAPTER 86
Dynamic Bandwidth Sharing
The Cisco cBR series router enables dynamic bandwidth sharing (DBS) on integrated cable (IC) and wideband
(WB) cable interfaces.
Contents
• Information About Dynamic Bandwidth Sharing, on page 1239
• How to Configure Dynamic Bandwidth Sharing, on page 1239
• Verifying the Dynamic Bandwidth Sharing Configuration, on page 1240
• Feature Information for Dynamic Bandwidth Sharing, on page 1244
1237
Digital PICs:

Module:

Modules:
line card reload.
1238
Information About Dynamic Bandwidth Sharing
Information About Dynamic Bandwidth Sharing

DBS for Integrated and Wideband Cable Interfaces
Prior to DOCSIS 3.0 standards, cable service flows were associated with a single cable interface, which in
turn corresponded to a physical downstream on a line card. Under DOCSIS 3.0 standards, cable service flows
can be associated with more than one downstream channel.
DBS is the dynamic allocation of bandwidth for IC and WB cable interfaces sharing the same downstream
channel. The bandwidth available to each IC, WB cable, or narrowband channel is not a fixed value—it
depends on the configuration and the traffic load on the IC or WB cable.
DBS enables high burst rates with DOCSIS 2.0 cable modems as well as DOCSIS 3.0 cable modems. The
DBS feature continues working across line card and Supervisor switchovers with no loss of functionality.
How to Configure Dynamic Bandwidth Sharing

Dynamic bandwidth sharing is enabled by default on the integrated and wideband cable interfaces on the
Cisco cBR router. You can configure the bandwidth allocation for the WB and IC interfaces.
Important Dynamic bandwidth sharing cannot be disabled on the Cisco cBR router.
Configuring DBS for a Wideband Cable Interface

Perform the following to configure the bandwidth allocation for a wideband cable interface.
Procedure

Router> enable

Example:

slot/subslot/portwideband-channel
Example:
1239
Configuring DBS for an Integrated Cable Interface
Step 4 cable rf-channel channel-list grouplist Configures the bandwidth allocation for the wideband
[bandwidth-percent bw-percent ] channel interface.
Example:
Router(config-if)# cable rf-channel channel-list

10 bandwidth-percent 50
Configuring DBS for an Integrated Cable Interface

Perform this procedure to configure the bandwidth allocation for an integrated cable interface.
Procedure

Router> enable

Example:
Step 3 interface integrated-cable slot/subslot/portrf-channel Enters the cable interface mode.

Example:
Step 4 cable rf-bandwidth-percent bw-percent Configures the bandwidth allocation for the integrated cable
interface.
Example:
Router(config-if)# cable rf-bandwidth-percent 50
Verifying the Dynamic Bandwidth Sharing Configuration

Use the following commands to verify the dynamic bandwidth sharing information:
• show controllers Integrated-Cable slot/subslot/port bandwidth rf-channel—Displays the bandwidth
information for RF channels.
1240
Router# show controllers integrated-Cable 2/0/0 bandwidth rf-channel
Ctrlr RF IF CIR(Kbps) Guar(Kbps)

2/0/0 0 In2/0/0:0 7500 13750
Wi2/0/0:0 7500 13750
Wi2/0/0:1 3750 10000
2/0/0 1 In2/0/0:1 7500 13750
Wi2/0/0:0 7500 13750
Wi2/0/0:1 3750 10000
2/0/0 2 In2/0/0:2 7500 12500
Wi2/0/0:0 7500 12500
Wi2/0/0:1 7500 12500
2/0/0 3 In2/0/0:3 7500 12500
Wi2/0/0:0 7500 12500
Wi2/0/0:1 7500 12500
2/0/0 4 In2/0/0:4 7500 12500
Wi2/0/0:0 7500 12500
Wi2/0/0:1 7500 12500
2/0/0 5 In2/0/0:5 7500 12500
Wi2/0/0:0 7500 12500
Wi2/0/0:1 7500 12500
2/0/0 6 In2/0/0:6 7500 12500
Wi2/0/0:0 7500 12500
Wi2/0/0:1 7500 12500
2/0/0 7 In2/0/0:7 7500 12500
Wi2/0/0:0 7500 12500
Wi2/0/0:1 7500 12500
2/0/0 8 In2/0/0:8 7500 18750
Wi2/0/0:1 7500 18750
Wi2/0/0:2 7500 0
2/0/0 9 In2/0/0:9 7500 18750
Wi2/0/0:1 7500 18750
Wi2/0/0:2 7500 0
2/0/0 10 In2/0/0:10 7500 18750
Wi2/0/0:1 7500 18750
Wi2/0/0:2 7500 0
2/0/0 11 In2/0/0:11 7500 18750
Wi2/0/0:1 7500 18750
Wi2/0/0:2 7500 0
2/0/0 12 In2/0/0:12 7500 37500
Wi2/0/0:2 7500 0
Wi2/0/0:3 7500 0
2/0/0 13 In2/0/0:13 7500 37500
Wi2/0/0:2 7500 0
Wi2/0/0:3 7500 0
• show controllers Integrated-Cable slot/subslot/port bandwidth wb-channel—Displays the bandwidth

information for wideband channels.
Router# show controllers Integrated-Cable 2/0/0 bandwidth wb-channel
Ctrlr WB RF CIR(Kbps) Guar(Kbps)

2/0/0 0 60000 102500
2/0/0:0 7500 13750
2/0/0:1 7500 13750
2/0/0:2 7500 12500
2/0/0:3 7500 12500
2/0/0:4 7500 12500
2/0/0:5 7500 12500
2/0/0:6 7500 12500
2/0/0:7 7500 12500
1241
2/0/0 1 82500 170000

2/0/0:0 3750 10000
2/0/0:1 3750 10000
2/0/0:2 7500 12500
2/0/0:3 7500 12500
2/0/0:4 7500 12500
2/0/0:5 7500 12500
2/0/0:6 7500 12500
2/0/0:7 7500 12500
2/0/0:8 7500 18750
2/0/0:9 7500 18750
2/0/0:10 7500 18750
2/0/0:11 7500 18750
2/0/0:32 0 0
2/0/0:33 0 0
2/0/0:34 0 0
2/0/0:35 0 0
2/0/0 2 60000 0
2/0/0:8 7500 0
2/0/0:9 7500 0
2/0/0:10 7500 0
2/0/0:11 7500 0
2/0/0:12 7500 0
2/0/0:13 7500 0
2/0/0:14 7500 0
2/0/0:15 7500 0
2/0/0:64 0 0
2/0/0:65 0 0
2/0/0:66 0 0
2/0/0:67 0 0
• show controllers Integrated-Cable slot/subslot/port mapping rf-channel—Displays the mapping for

RF channels.
Router# show controllers integrated-Cable 2/0/0 mapping rf-channel
Ctrlr RF IC % IC Rem WB WB % WB Rem

2/0/0 0 20 1 2/0/0:0 20 1
2/0/0:1 10 1
2/0/0 1 20 1 2/0/0:0 20 1
2/0/0:1 10 1
2/0/0 2 20 1 2/0/0:0 20 1
2/0/0:1 20 1
2/0/0 3 20 1 2/0/0:0 20 1
2/0/0:1 20 1
2/0/0 4 20 1 2/0/0:0 20 1
2/0/0:1 20 1
2/0/0 5 20 1 2/0/0:0 20 1
2/0/0:1 20 1
2/0/0 6 20 1 2/0/0:0 20 1
2/0/0:1 20 1
2/0/0 7 20 1 2/0/0:0 20 1
2/0/0:1 20 1
2/0/0 8 20 1 2/0/0:1 20 1
2/0/0:2 20 1
2/0/0 9 20 1 2/0/0:1 20 1
2/0/0:2 20 1
2/0/0 10 20 1 2/0/0:1 20 1
2/0/0:2 20 1
1242
• show controllers Integrated-Cable slot/port/interface-number mapping wb-channel—Displays the

mapping for wideband channels.
Router# show controllers integrated-Cable 2/0/0 mapping wb-channel
Ctrlr WB RF WB % WB Rem
2/0/0 0 2/0/0:0 20 1
2/0/0:1 20 1
2/0/0:2 20 1
2/0/0:3 20 1
2/0/0:4 20 1
2/0/0:5 20 1
2/0/0:6 20 1
2/0/0:7 20 1
2/0/0 1 2/0/0:0 10 1
2/0/0:1 10 1
2/0/0:2 20 1
2/0/0:3 20 1
2/0/0:4 20 1
2/0/0:5 20 1
2/0/0:6 20 1
2/0/0:7 20 1
2/0/0:8 20 1
2/0/0:9 20 1
2/0/0:10 20 1
2/0/0:11 20 1
2/0/0:32 20 1
2/0/0:33 20 1
2/0/0:34 20 1
2/0/0:35 20 1
2/0/0 2 2/0/0:8 20 1
2/0/0:9 20 1
2/0/0:10 20 1
2/0/0:11 20 1
2/0/0:12 20 1
2/0/0:13 20 1
2/0/0:14 20 1
2/0/0:15 20 1
2/0/0:64 20 1
2/0/0:65 20 1
2/0/0:66 20 1
2/0/0:67 20 1
2/0/0 3 2/0/0:12 20 1
2/0/0:13 20 1
2/0/0:14 20 1
2/0/0:15 20 1
2/0/0:16 20 1
2/0/0:17 20 1
Related Documents

Cisco CMTS cable commands Cisco CMTS Cable Command Reference
1243
Feature Information for Dynamic Bandwidth Sharing
Description Link
ID and password.
Feature Information for Dynamic Bandwidth Sharing

Table 210: Feature Information for Dynamic Bandwidth Sharing
Dynamic bandwidth sharing Cisco IOS XE Everest 16.6.1 This feature was integrated into
Broadband Routers.
1244
CHAPTER 87
Modular Quality of Service Command-Line
Interface QoS
This module contains the concepts about applying QoS features using the Modular Quality of Service (QoS)
Command-Line Interface (CLI) (MQC) and the tasks for configuring the MQC. The MQC allows you to
define a traffic class, create a traffic policy (policy map), and attach the traffic policy to an interface. The
traffic policy contains the QoS feature that will be applied to the traffic class.
• Restrictions for Applying QoS Features Using the MQC, on page 1247
• About, on page 1247
• How to Apply QoS Features Using the MQC, on page 1252
• Configuration Examples for Applying QoS Features Using the MQC, on page 1257
• How to Configure Input MQC on the Port-Channel Interfaces, on page 1261
• Example: Configuring Input MQC on the Port-Channel Interfaces, on page 1262
• Feature Information for Modular Quality of Service Command-Line Interface QoS, on page 1264

Your software release may not support all the features documented in this module. For the latest caveats and
feature information, see Bug Search Tool and the release notes for your platform and software release. To
find information about the features documented in this module, and to see a list of the releases in which each
feature is supported, see the feature information table.
To access Cisco Feature Navigator, go to https://cfnng.cisco.com/. An account on Cisco.com is not required.
1245
Digital PICs:

Module:

Modules:
line card reload.
1246
Restrictions for Applying QoS Features Using the MQC
Restrictions for Applying QoS Features Using the MQC

The MQC-based QoS does not support classification of legacy Layer 2 protocol packets such as Internetwork
Packet Exchange (IPX), DECnet, or AppleTalk. When these types of packets are being forwarded through a
generic Layer 2 tunneling mechanism, the packets can be handled by MQC but without protocol classification.
As a result, legacy protocol traffic in a Layer 2 tunnel is matched only by a "match any" class or class-default.
The number of QoS policy maps and class maps supported varies by platform and release.
Note The policy map limitations do not refer to the number of applied policy map instances, only to the definition
of the policy maps.
About
The MQC Structure
The MQC (Modular Quality of Service (QoS) Command-Line Interface (CLI)) enables you to set packet
classification and marking based on a QoS group value. MQC CLI allows you to create traffic classes and
policies, enable a QoS feature (such as packet classification), and attach these policies to interfaces.
The MQC structure necessitates developing the following entities: traffic class, policy map, and service policy.
Elements of a Traffic Class

A traffic class contains three major elements: a traffic class name, a series of match commands, and, if more
than one match command is used in the traffic class, instructions on how to evaluate these match commands.
The match commands are used for classifying packets. Packets are checked to determine whether they meet
the criteria specified in the matchcommands; if a packet meets the specified criteria, that packet is considered
a member of the class. Packets that fail to meet the matching criteria are classified as members of the default
traffic class.
Available match Commands

The table below lists some of the available match commands that can be used with the MQC. The available
match commands vary by Cisco IOS XE release. For more information about the commands and command
syntax, see the Cisco IOS Quality of Service Solutions Command Reference.
Table 212: match Commands That Can Be Used with the MQC
Command Purpose
match access-group Configures the match criteria for a class map on the basis of the specified
access control list (ACL).
1247
Elements of a Traffic Class
Command Purpose
match any Configures the match criteria for a class map to be successful match
criteria for all packets.
match cos Matches a packet based on a Layer 2 class of service (CoS) marking.
match destination-address mac Uses the destination MAC address as a match criterion.
match discard-class Matches packets of a certain discard class.
match [ip] dscp Identifies a specific IP differentiated service code point (DSCP) value as
a match criterion. Up to eight DSCP values can be included in one match
statement.
match input-interface Configures a class map to use the specified input interface as a match
criterion.
match ip rtp Configures a class map to use the Real-Time Transport Protocol (RTP)
port as the match criterion.
match mpls experimental Configures a class map to use the specified value of the Multiprotocol
Label Switching (MPLS) experimental (EXP) field as a match criterion.
match mpls experimental Matches the MPLS EXP value in the topmost label.
topmost
match not Specifies the single match criterion value to use as an unsuccessful match
criterion.
Note The match not command, rather than identifying the specific
match parameter to use as a match criterion, is used to specify
a match criterion that prevents a packet from being classified
as a member of the class. For instance, if the match not
qos-group 6 command is issued while you configure the traffic
class, QoS group 6 becomes the only QoS group value that is
not considered a successful match criterion. All other QoS
group values would be successful match criteria.
match packet length Specifies the Layer 3 packet length in the IP header as a match criterion
in a class map.
match port-type Matches traffic on the basis of the port type for a class map.
match [ip] precedence Identifies IP precedence values as match criteria.
match protocol Configures the match criteria for a class map on the basis of the specified
protocol.
Note A separate match protocol (NBAR) command is used to
configure network-based application recognition (NBAR) to
match traffic by a protocol type known to NBAR.
match protocol fasttrack Configures NBAR to match FastTrack peer-to-peer traffic.
1248
Elements of a Traffic Policy
Command Purpose
match protocol gnutella Configures NBAR to match Gnutella peer-to-peer traffic.
match protocol http Configures NBAR to match Hypertext Transfer Protocol (HTTP) traffic
by URL, host, Multipurpose Internet Mail Extension (MIME) type, or
fields in HTTP packet headers.
match protocol rtp Configures NBAR to match RTP traffic.
match qos-group Identifies a specific QoS group value as a match criterion.
match source-address mac Uses the source MAC address as a match criterion.
Multiple match Commands in One Traffic Class

If the traffic class contains more than one match command, you need to specify how to evaluate the match
commands. You specify this by using either the match-any or match-all keyword of the class-map command.
Note the following points about the match-any and match-all keywords:
• If you specify the match-any keyword, the traffic being evaluated by the traffic class must match one
of the specified criteria.
• If you specify the match-all keyword, the traffic being evaluated by the traffic class must match all of
the specified criteria.
• If you do not specify either keyword, the traffic being evaluated by the traffic class must match all of
the specified criteria (that is, the behavior of the match-all keyword is used).

A traffic policy contains three elements: a traffic policy name, a traffic class (specified with the class command),
and the command used to enable the QoS feature.
The traffic policy (policy map) applies the enabled QoS feature to the traffic class once you attach the policy
map to the interface (by using the service-policy command).
Note A packet can match only one traffic class within a traffic policy. If a packet matches more than one traffic
class in the traffic policy, the first traffic class defined in the policy will be used.
Commands Used to Enable QoS Features

The commands used to enable QoS features vary by Cisco IOS XE release. The table below lists some of the
available commands and the QoS features that they enable. For complete command syntax, see the Cisco IOS
QoS Command Reference.
For more information about a specific QoS feature that you want to enable, see the appropriate module of the
Cisco IOS XE Quality of Service Solutions Configuration Guide.
1249
Table 213: Commands Used to Enable QoS Features
Command Purpose
bandwidth Configures a minimum bandwidth guarantee for a class.
bandwidth remaining Configures an excess weight for a class.
fair-queue Enables the flow-based queueing feature within a traffic class.
fair-queue pre-classify Configures and checks whether the qos pre-classify command can be
used for fair queue. When the qos pre-classify command is enabled on
the tunnel inteface, and then the fair-queue pre-classify command is
enabled for the policy-map, the policy-map is attached to either the tunnel
interface or the physical interface.
The inner IP header of the tunnel will be used for the hash algorithm of
the fair queue.
drop Discards the packets in the specified traffic class.
police Configures traffic policing.
police (percent) Configures traffic policing on the basis of a percentage of bandwidth

available on an interface.
police (two rates) Configures traffic policing using two rates, the committed information
rate (CIR) and the peak information rate (PIR).
priority Gives priority to a class of traffic belonging to a policy map.
queue-limit Specifies or modifies the maximum number of packets the queue can
hold for a class configured in a policy map.
random-detect Enables Weighted Random Early Detection (WRED).
random-detect discard-class Configures the WRED parameters for a discard-class value for a class in
a policy map.
random-detect Configures WRED on the basis of the discard class value of a packet.
discard-class-based
random-detect Configures the exponential weight factor for the average queue size
exponential-weighting-constant calculation for the queue reserved for a class.
random-detect precedence Configure the WRED parameters for a particular IP Precedence for a
class policy in a policy map.
service-policy Specifies the name of a traffic policy used as a matching criterion (for
nesting traffic policies [hierarchical traffic policies] within one another).
set atm-clp Sets the cell loss priority (CLP) bit when a policy map is configured.
set cos Sets the Layer 2 class of service (CoS) value of an outgoing packet.
set discard-class Marks a packet with a discard-class value.
1250
Nested Traffic Classes
Command Purpose
set [ip] dscp Marks a packet by setting the differentiated services code point (DSCP)
value in the type of service (ToS) byte.
set fr-de Changes the discard eligible (DE) bit setting in the address field of a
Frame Relay frame to 1 for all traffic leaving an interface.
set mpls experimental Designates the value to which the MPLS bits are set if the packets match
the specified policy map.
set precedence Sets the precedence value in the packet header.
set qos-group Sets a QoS group identifier (ID) that can be used later to classify packets.
shape Shapes traffic to the indicated bit rate according to the algorithm specified.
Nested Traffic Classes

The MQC does not necessarily require that you associate only one traffic class to one traffic policy.
In a scenario where packets satisfy more than one match criterion, the MQC enables you to associate multiple
traffic classes with a single traffic policy (also termed nested traffic classes) using the match class-map
command. (We term these nested class maps or MQC Hierarchical class maps.) This command provides the
only method of combining match-any and match-all characteristics within a single traffic class. By doing so,
you can create a traffic class using one match criterion evaluation instruction (either match-any or match-all)
and then use that traffic class as a match criterion in a traffic class that uses a different match criterion type.
For example, a traffic class created with the match-any instruction must use a class configured with the
match-all instruction as a match criterion, or vice versa.
Consider this likely scenario: Suppose A, B, C, and D were all separate match criterion, and you wanted traffic
matching A, B, or C and D (i.e., A or B or [C and D]) to be classified as belonging to a traffic class. Without
the nested traffic class, traffic would either have to match all four of the match criterion (A and B and C and
D) or match any of the match criterion (A or B or C or D) to be considered part of the traffic class. You would
not be able to combine “and” (match-all) and “or” (match-any) statements within the traffic class; you would
be unable to configure the desired configuration.
The solution: Create one traffic class using match-all for C and D (which we will call criterion E), and then
create a new match-any traffic class using A, B, and E. The new traffic class would have the correct evaluation
sequence (A or B or E, which is equivalent to A or B or [C and D]).
match-all and match-any Keywords of the class-map Command

One of the commands used when you create a traffic class is the class-mapcommand. The command syntax
for the class-map command includes two keywords: match-all and match-any. The match-all and match-any
keywords need to be specified only if more than one match criterion is configured in the traffic class. Note
the following points about these keywords:
• The match-all keyword is used when all of the match criteria in the traffic class must be met in order
for a packet to be placed in the specified traffic class.
• The match-any keyword is used when only one of the match criterion in the traffic class must be met
in order for a packet to be placed in the specified traffic class.
1251
input and output Keywords of the service-policy Command
• If neither the match-all keyword nor match-any keyword is specified, the traffic class will behave in a
manner consistent with the match-all keyword.
input and output Keywords of the service-policy Command

As a general rule, the QoS features configured in the traffic policy can be applied to packets entering the
interface or to packets leaving the interface. Therefore, when you use the service-policy command, you need
to specify the direction of the traffic policy by using the input or output keyword.
For instance, the service-policy output policy-map1 command would apply the QoS features in the traffic
policy to the interface in the output direction. All packets leaving the interface (output) are evaluated according
to the criteria specified in the traffic policy named policy-map1.
Note For Cisco releases, queueing mechanisms are not supported in the input direction. Nonqueueing mechanisms
(such as traffic policing and traffic marking) are supported in the input direction. Also, classifying traffic on
the basis of the source MAC address (using the match source-address mac command) is supported in the
input direction only.
Benefits of Applying QoS Features Using the MQC

The MQC structure allows you to create the traffic policy (policy map) once and then apply it to as many
traffic classes as needed. You can also attach the traffic policies to as many interfaces as needed.
How to Apply QoS Features Using the MQC

Creating a Traffic Class
To create a traffic class, use the class-map command to specify the traffic class name. Then use one or more
match commands to specify the appropriate match criteria. Packets matching the criteria that you specify are
placed in the traffic class. For more information about the match-all and match-any keywords of the class-map
comand, see the “match-all and match-any Keywords of the class-map Command” section.
Note The match cos command is shown in Step 4. The match cos command is simply an example of one of the
match commands that you can use. For information about the other available match commands, see the
“match-all and match-any Keywords of the class-map Command” section.
SUMMARY STEPS
1. enable
3. class-map [match-all | match-any] class-map-name
4. match cos cos-number
1252
5. Enter additional match commands, if applicable; otherwise, continue with step 6.

6. end
DETAILED STEPS

Router> enable

Example:
Step 3 class-map [match-all | match-any] class-map-name Creates a class to be used with a class map and enters
class-map configuration mode.
Example:
• The class map is used for matching packets to the
Router(config)# class-map match-any class1 specified class.
• Enter the class name.
Note The match-all keyword specifies that all match

criteria must be met. The match-any keyword
specifies that one of the match criterion must be
met. Use these keywords only if you will be
specifying more than one match command.
Step 4 match cos cos-number Matches a packet on the basis of a Layer 2 class of service
(CoS) number.
Example:
• Enter the CoS number.
Router(config-cmap)# match cos 2
Note The match cos command is an example of the
match commands you can use. For information
about the other match commands that are
available, see the “match-all and match-any
Keywords of the class-map Command” section.
Step 5 Enter additional match commands, if applicable; otherwise, --

continue with step 6.
Step 6 end (Optional) Exits QoS class-map configuration mode and
returns to privileged EXEC mode.
Example:
Router(config-cmap)# end
1253
Creating a Traffic Policy
Creating a Traffic Policy
Note The bandwidth command is shown in Step 5. The bandwidth command is an example of the commands that
you can use in a policy map to enable a QoS feature (in this case, Class-based Weighted Fair Queuing
(CBWFQ). For information about other available commands, see the “Elements of a Traffic Policy” section.
SUMMARY STEPS
1. enable
3. policy-map policy-map-name
4. class {class-name | class-default}
5. bandwidth {bandwidth-kbps | percent percent}
6. Enter the commands for any additional QoS feature that you want to enable, if applicable; otherwise,
continue with Step 7.
7. end
DETAILED STEPS

Router> enable

Example:
Step 3 policy-map policy-map-name Creates or specifies the name of the traffic policy and enters
QoS policy-map configuration mode.
Example:
• Enter the policy map name.
Router(config)# policy-map policy1
Step 4 class {class-name | class-default} Specifies the name of a traffic class and enters QoS
policy-map class configuration mode.
Example:
Note This step associates the traffic class with the
Router(config-pmap)# class class1 traffic policy.
Step 5 bandwidth {bandwidth-kbps | percent percent} (Optional) Specifies a minimum bandwidth guarantee to a
traffic class in periods of congestion.
Example:
• A minimum bandwidth guarantee can be specified in
Router(config-pmap-c)# bandwidth 3000 kb/s or by a percentage of the overall available
bandwidth.
1254
Attaching a Traffic Policy to an Interface Using the MQC

Note The bandwidth command enables CBWFQ. The
bandwidth command is an example of the
commands that you can use in a policy map to
enable a QoS feature. For information about the
other commands available, see the “Elements of
a Traffic Policy” section.
Step 6 Enter the commands for any additional QoS feature that --
you want to enable, if applicable; otherwise, continue with
Step 7.
Step 7 end (Optional) Exits QoS policy-map class configuration mode
and returns to privileged EXEC mode.
Example:
Router(config-pmap-c)# end
Attaching a Traffic Policy to an Interface Using the MQC

Procedure

Router> enable

Example:
Step 3 interface type number Configures an interface type and enters interface
configuration mode.
Example:
• Enter the interface type and interface number.
Router(config)# interface TenGigabitEthernet 4/1/0
Step 4 service-policy {input | output} policy-map-name Attaches a policy map to an interface.

Example: • Enter either the input or output keyword and the
policy map name.
Router(config-if)# service-policy input policy1
Step 5 end (Optional) Exits interface configuration mode and returns

Example:
1255
Verifying the Traffic Class and Traffic Policy Information
Verifying the Traffic Class and Traffic Policy Information

The show commands described in this section are optional and can be entered in any order.
Procedure

Router> enable
Step 2 show class-map (Optional) Displays all class maps and their matching
criteria.
Example:
Router# show class-map
Step 3 show policy-map policy-map-name class class-name (Optional) Displays the configuration for the specified class
of the specified policy map.
Example:
• Enter the policy map name and the class name.
Router# show policy-map policy1 class class1
Step 4 show policy-map (Optional) Displays the configuration of all classes for all
existing policy maps.
Example:
Router# show policy-map
Step 5 show policy-map interface type number (Optional) Displays the statistics and the configurations of
the input and output policies that are attached to an interface.
Example:
• Enter the interface type and number.
Router# show policy-map interface
TengigabitEthernet 4/1/0
Step 6 exit (Optional) Exits privileged EXEC mode.

Example:
Router# exit
1256
Configuration Examples for Applying QoS Features Using the MQC
Configuration Examples for Applying QoS Features Using the

MQC
In the following example, we create traffic classes and define their match criteria. For the first traffic class
(class1), we use access control list (ACL) 101 as match criteria; for the second traffic class (class2), ACL
102. We check the packets against the contents of these ACLs to determine if they belong to the class.
class-map class1
match access-group 101
exit
class-map class2
end
Creating a Policy Map

In the following example, we define a traffic policy (policy1) containing the QoS features that we will apply
to two classes: class1 and class2. The match criteria for these classes were previously defined in Creating a
Traffic Class, on page 1257).
For class1, the policy includes a bandwidth allocation request and a maximum packet count limit for the queue
reserved for that class. For class2, the policy specifies only a bandwidth allocation request.
policy-map policy1
class class1
bandwidth 3000
queue-limit 30
exit
class class2
bandwidth 2000
end
Example: Attaching a Traffic Policy to an Interface

The following example shows how to attach an existing traffic policy to an interface. After you define a traffic
policy with the policy-map command, you can attach it to one or more interfaces by using the service-policy
command in interface configuration mode. Although you can assign the same traffic policy to multiple
interfaces, each interface can have only one traffic policy attached in the input direction and only one traffic
policy attached in the output direction.
Router(config)# interface TengigabitEthernet 4/1/0

Router(config-if)# service-policy output policy1
Router(config)# interface TengigabitEthernet 4/1/0
Router(config-if)# service-policy output policy1
1257
Using the match not Command
Using the match not Command

Use the match not command to specify a QoS policy value that is not used as a match criterion. All other
values of that QoS policy become successful match criteria. For instance, if you issue the match not qos-group
4 command in QoS class-map configuration mode, the specified class will accept all QoS group values except
4 as successful match criteria.
In the following traffic class, all protocols except IP are considered successful match criteria:
class-map noip
match not protocol ip
end
Configuring a Default Traffic Class

Traffic that does not meet the match criteria specified in the traffic classes (that is, unclassified traffic) is
treated as belonging to the default traffic class.
If you do not configure a default class, packets are still treated as members of that class. The default class has
no QoS features enabled so packets belonging to this class have no QoS functionality. Such packets are placed
into a first-in, first-out (FIFO) queue managed by tail drop, which is a means of avoiding congestion that
treats all traffic equally and does not differentiate between classes of service. Queues fill during periods of
congestion. When the output queue is full and tail drop is active, packets are dropped until the congestion is
eliminated and the queue is no longer full.
The following example configures a policy map (policy1) for the default class (always called class-default)
with these characteristics: 10 queues for traffic that does not meet the match criteria of other classes whose
policy is defined by class policy1, and a maximum of 20 packets per queue before tail drop is enacted to
handle additional queued packets.
In the following example, we configure a policy map (policy1) for the default class (always termed class-default)
with these characteristics: 10 queues for traffic that does not meet the match criterion of other classes whose
policy is defined by the traffic policy policy1.
policy-map policy1
class class-default
shape average 100m
How Commands "class-map match-any" and "class-map match-all" Differ

This example shows how packets are evaluated when multiple match criteria exist. It illustrates the difference
between the class-map match-any and class-map match-all commands. Packets must meet either all of the
match criteria (match-all) or one of the match criteria (match-any) to be considered a member of the traffic
class.
The following examples show a traffic class configured with the class-map match-all command:
class-map match-all cisco1

match qos-group 4
If a packet arrives on a router with traffic class cisco1 configured on the interface, we assess whether it matches
the IP protocol, QoS group 4, and access group 101. If all of these match criteria are met, the packet is classified
1258
Establishing Traffic Class as a Match Criterion (Nested Traffic Classes)
as a member of the traffic class cisco1 (a logical AND operator; Protocol IP AND QoS group 4 AND access
group 101).
class-map match-all vlan

match vlan 1
match vlan inner 1
The following example illustrates use of the class-map match-any command. Only one match criterion must
be met for us to classify the packet as a member of the traffic class (i.e., a logical OR operator; protocol IP
OR QoS group 4 OR access group 101):
class-map match-any cisco2

match protocol ip
match qos-group 4
In the traffic class cisco2, the match criterion are evaluated consecutively until a successful match is located.
The packet is first evaluated to determine whether the IP protocol can be used as a match criterion. If so, the
packet is matched to traffic class cisco2. If not, then QoS group 4 is evaluated as a match criterion and so on.
If the packet matches none of the specified criteria, the packet is classified as a member of the default traffic
class (class default-class).
Establishing Traffic Class as a Match Criterion (Nested Traffic Classes)

There are two reasons to use the match class-map command. One reason is maintenance; if a large traffic
class currently exists, using the traffic class match criterion is easier than retyping the same traffic class
configuration. The second and more common reason is to mix match-all and match-any characteristics in one
traffic policy. This enables you to create a traffic class using one match criterion evaluation instruction (either
match-any or match-all) and then use that traffic class as a match criterion in a traffic class that uses a different
match criterion type.
Consider this likely scenario: Suppose A, B, C, and D were all separate match criterion, and you wanted traffic
matching A, B, or C and D (i.e., A or B or [C and D]) to be classified as belonging to a traffic class. Without
the nested traffic class, traffic would either have to match all four of the match criterion (A and B and C and
D) or match any of the match criterion (A or B or C or D) to be considered part of the traffic class. You would
not be able to combine “and” (match-all) and “or” (match-any) statements within the traffic class; you would
be unable to configure the desired configuration.
The solution: Create one traffic class using match-all for C and D (which we will call criterion E), and then
create a new match-any traffic class using A, B, and E. The new traffic class would have the correct evaluation
sequence (A or B or E, which is equivalent to A or B or [C and D]).
Example: Nested Traffic Class for Maintenance

In the following example, the traffic class called class1 has the same characteristics as the traffic class called
class2, with the exception that traffic class class1 has added a destination address as a match criterion. Rather
than configuring traffic class class1 line by line, you can enter the match class-map class2 command. This
command allows all of the characteristics in the traffic class called class2 to be included in the traffic class
called class1, and you can add the new destination address match criterion without reconfiguring the entire
traffic class.
Router(config)# class-map match-any class2
1259
Example: Nested Traffic Class to Combine match-any and match-all Characteristics in One Traffic Class
Router(config-cmap)# match protocol ip

Router(config-cmap)# match qos-group 3
Router(config-cmap)# match access-group 2
Router(config-cmap)# exit
Router(config)# class-map match-all class1
Router(config-cmap)# match class-map class2
Router(config-cmap)# match destination-address mac 0000.0000.0000
Example: Nested Traffic Class to Combine match-any and match-all Characteristics in One Traffic
Class
The only method of including both match-any and match-all characteristics in a single traffic class is to use
the match class-map command. To combine match-any and match-all characteristics into a single class, use
the match-any instruction to create a traffic class that uses a class configured with the match-all instruction
as a match criterion (through the match class-map command).
The following example shows how to combine the characteristics of two traffic classes, one with match-any
and one with match-all characteristics, into one traffic class with the match class-map command. The result
requires a packet to match one of the following three match criteria to be considered a member of traffic class
class4: IP protocol and QoS group 4, destination MAC address 00.00.00.00.00.00, or access group 2.
In this example, only the traffic class called class4 is used with the traffic policy called policy1.
Router(config)# class-map match-all class3

Router(config-cmap)# match protocol ip
Router(config-cmap)# match qos-group 4
Router(config)# class-map match-any class4
Router(config-cmap)# match class-map class3
Router(config-cmap)# match destination-address mac 00.00.00.00.00.00
Router(config-pmap)# class class4
Router(config-pmap-c)# police 8100 1500 2504 conform-action transmit exceed-action
set-qos-transmit 4
Router(config-pmap-c)# end
Example: Traffic Policy as a QoS Policy (Hierarchical Traffic Policies)

A traffic policy can be included in a QoS policy when the service-policy command is used in QoS
policy-map class configuration mode. A traffic policy that contains a traffic policy is called a
hierarchical traffic policy.
A hierarchical traffic policy contains a child policy and a parent policy. The child policy is the
previously defined traffic policy that is being associated with the new traffic policy through the use
of the service-policy command. The new traffic policy using the preexisting traffic policy is the
parent policy. In the example in this section, the traffic policy called child is the child policy and
traffic policy called parent is the parent policy.
Hierarchical traffic policies can be attached to subinterfaces. When hierarchical traffic policies are
used, a single traffic policy (with a child and parent policy) can be used to shape and priority traffic
on subinterfaces.
1260
How to Configure Input MQC on the Port-Channel Interfaces
Router(config)# policy-map child

Router(config-pmap)# class voice
Router(config-pmap-c)# priority 50
Router(config)# policy-map parent
Router(config-pmap)# class class-default
Router(config-pmap-c)# shape average 10000000
Router(config-pmap-c)# service-policy child
The value used with the shape command is provisioned from the committed information rate (CIR)
value from the service provider.
How to Configure Input MQC on the Port-Channel Interfaces

To configure input MQC on a port-channel interface to differentiate traffic flow and set corresponding
"qos-group" features, follow the steps given below.
Restriction • QoS actions like policing, shaping, WRED, and queuing are not supported.
• Input MQC cannot be configured on cable physical interfaces.

The class-map command is used to create a traffic class. A traffic class contains three major elements: a name,
a series of match commands, and, if more than one match command exists in the traffic class, an instruction
on how to evaluate these match commands.
The match commands are used to specify various criteria for classifying packets. Packets are checked to
determine whether they match the criteria specified in the match commands; if a packet matches the specified
criteria, that packet is considered a member of the class and is forwarded according to the QoS specifications
set in the traffic policy. Packets that fail to meet any of the matching criteria are classified as members of the
default traffic class.
To create traffic classes and define their match criteria, complete the following procedure:
configure terminal
class-map class
match type
Creating a Policy Map

After creating traffic classes, you can configure traffic policies to configure marking features to apply certain
actions to the selected traffic in those classes.
The policy-map command is used to create a traffic policy. The purpose of a traffic policy is to configure the
QoS features that should be associated with the traffic that has been classified in a user-specified traffic class.
Note A packet can match only one traffic class within a traffic policy. If a packet matches more than one traffic
class in the traffic policy, the first traffic class defined in the policy will be used.
1261
Defining QoS Actions in a Policy Map
To define a traffic policy, complete the following procedure:

configure terminal
policy-map policy
class class
Defining QoS Actions in a Policy Map

Action commands can be added from within class mode on a policy map.
Set Actions
Set commands allow traffic to be marked such that other network devices along the forwarding path can
quickly determine the proper class of service to apply to a traffic flow.
To define a set action, complete the following procedure:
configure terminal
policy-map policy
class class
set option
Configuring Aggregate Port-Channel Interface

To configure port-channel interface, complete the following procedure:
configure terminal
platform qos port-channel-aggregate port_channel_number
interface port-channel port_channel_number
ip address ip musk
interface name
channel-group number
Attaching a Traffic Policy to an Interface

After you define a traffic policy with the policy-mapcommand, you can attach it to one or more interfaces
by using the service-policy command in interface configuration mode. Although you can assign the same
traffic policy to multiple interfaces, each interface can have only one traffic policy attached in the input
direction and only one traffic policy attached in the output direction.
To attach a traffic policy to an interface, complete the following procedure:
configure terminal
interface port-channel port_channel_number
service-policy input policy
Example: Configuring Input MQC on the Port-Channel Interfaces

The following example shows how to configure input MQC on the port-channel interfaces.
1262

Router(config)# class-map class1
Router(config-cmap)# match any
Router(config-pmap)# class class1
Router(config-pmap-c)# set dscp af11
Router(config-pmap-c)# exit
Router(config-pmap)# exit
Router(config)# platform qos port-channel-aggregate 2 Router(config)# interface port-channel
2
Router(config-if)# ip address 192.168.0.1 255.255.255.0
Router(config-if)# no shut
Router(config-if)# interface tenGigabitEthernet 4/1/1
Router(config-if)# no ip address
Router(config-if)# no shut
Router(config-if)# channel-group 2
Router(config-if)# interface port-channel 2
Router(config-if)# service-policy input policy1
Related Documents
QoS commands: complete command syntax, Cisco IOS Quality of Service Solutions Command
command modes, command history, defaults, usage Reference
guidelines, and examples
Packet classification “Classifying Network Traffic” module
Frame Relay Fragmentation (FRF) PVCs “FRF .20 Support” module
Selective Packet Discard “IPv6 Selective Packet Discard” module
Scaling and performance information “Broadband Scalability and Performance” module of the
Cisco ASR 1000 Series Aggregation Services Routers
Software Configuration Guide .
Description Link

1263
Feature Information for Modular Quality of Service Command-Line Interface QoS
Feature Information for Modular Quality of Service

Command-Line Interface QoS
Table 214: Feature Information for Modular Quality of Service Command-Line Interface QoS
Modular Quality of Service Cisco IOS XE Everest 16.6.1 This feature was integrated into
Command-Line Interface QoS Cisco IOS XE Everest 16.6.1 on
Broadband Routers.
Service Policy on Port-Channel Cisco IOS XE Everest 16.6.1 This feature was integrated into
Interfaces Cisco IOS XE Everest 16.6.1 on
Broadband Routers.
1264
CHAPTER 88
DOCSIS 1.1 for the Cisco CMTS Routers
This document describes how to configure the Cisco CMTS router for Data-over-Cable Service Interface
Specifications (DOCSIS) 1.1 operations.
Contents
• Prerequisites for DOCSIS 1.1 Operations, on page 1267
• Restrictions for DOCSIS 1.1 Operations, on page 1267
• Information about DOCSIS 1.1, on page 1269
• How to Configure the Cisco CMTS for DOCSIS 1.1 Operations, on page 1282
• Monitoring DOCSIS Operations, on page 1294
• Configuration Examples for DOCSIS 1.1 Operations, on page 1300
• Feature Information for DOCSIS 1.1 for Cisco CMTS Routers, on page 1304
1265
Digital PICs:

Module:

Modules:
line card reload.
1266
Prerequisites for DOCSIS 1.1 Operations
Prerequisites for DOCSIS 1.1 Operations

To support DOCSIS 1.1 operations, the cable modem must also support the DOCSIS 1.1 feature set. In
addition, before you power on and configure the Cisco CMTS, check the following points:
• Ensure that your network supports reliable broadband data transmission. Your plant must be swept,
balanced, and certified, based on NTSC or appropriate international cable plant recommendations. Ensure
that your plant meets all DOCSIS downstream and upstream RF requirements.
• Ensure that your Cisco CMTS is installed according to the instructions provided in the appropriate
Hardware Installation Guide. The chassis must contain at least one port adapter to provide backbone
connectivity and one Cisco cable line card to serve as the RF cable TV interface.
• Ensure that all other required headend or distribution hub routing and network interface equipment is
installed, configured, and operational, based on the services to support. This includes all routers, servers
(DHCP, TFTP, and ToD), network management systems, and other configuration or billing systems.
This includes IP telephony equipment including gatekeepers and gateways; backbone and other equipment
if supporting virtual private networks (VPNs); and dialup access servers, telephone circuits and connections
and other equipment if supporting telco return.
• Ensure that DHCP and DOCSIS configuration files have been created and pushed to appropriate servers
such that each cable modem, when initialized, can transmit a DHCP request, receive an IP address, obtain
TFTP and ToD server addresses, and download DOCSIS configuration files. Optionally, ensure that your
servers can also download updated software images to DOCSIS 1.0 and DOCSIS 1.1 cable modems.
• Ensure that customer premises equipment (CPE)—cable modems or set-top boxes, PCs, telephones, or
facsimile machines—meet the requirements for your network and service offerings.
• Familiarize yourself with your channel plan to ensure assigning of appropriate frequencies. Outline your
strategies for setting up bundling or VPN solution sets, if applicable, to your headend or distribution hub.
Know your dial plan if using H.323 for VoIP services and setting up VoIP-enabled cable modem
configuration files. Obtain passwords, IP addresses, subnet masks, and device names, as appropriate.
• Ensure that the system clocks on the Cisco CMTS and on the time-of-day (ToD) servers are synchronized.
If this does not occur, the clocks on the CMs will not match the clocks on the Cisco CMTS, which could
interfere with BPI+ operations. In particular, this could prevent the proper verification of the digital
certificates on the cable modem (CM).
After these prerequisites are met, you are ready to configure the Cisco CMTS. This includes, at a minimum,
configuring a host name and password for the Cisco CMTS and configuring the Cisco CMTS to support IP
over the cable plant and network backbone.
Caution If you plan to use service-class-based provisioning, the service classes must be configured at the Cisco CMTS
before cable modems attempt to make a connection. Use the cable service class command to configure service
classes.
Restrictions for DOCSIS 1.1 Operations

DOCSIS 1.1 operations includes the following restrictions:
1267
Restrictions for DOCSIS 1.1 Operations
Baseline Privacy Interface Plus Requirements

BPI+ encryption and authentication must be supported and enabled by both the cable modem and CMTS. In
addition, the cable modem must contain a digital certificate that conforms to the DOCSIS 1.1 and BPI+
specifications.
Also, ensure that the system clocks on the CMTS and on the time-of-day (ToD) servers are synchronized. If
this does not occur, the clocks on the CMs will not match the clocks on the CMTS, which could interfere with
BPI+ operations. In particular, this could prevent the proper verification of the digital certificates on the CM.
Note Ensure that the system clocks on the CMTS and on the time-of-day (ToD) servers are synchronized. If this
does not occur, the clocks on the CMs will not match the clocks on the CMTS, which could interfere with
BPI+ operations. In particular, this could prevent the proper verification of the digital certificates on the CM.
BPI+-Encrypted Multicast Not Supported with Bundled Subinterfaces on the Cisco cBR-8 Router
The current Cisco IOS-XE releases do not support using BPI+ encrypted multicast on bundled cable
subinterfaces on the Cisco cBR-8 router. Encrypted multicast is supported on bundled cable interfaces or on
non-bundled cable subinterfaces, but not when a subinterface is bundled on the Cisco cBR-8 router.
BPI+ Not Supported with High Availability Configurations

The current Cisco IOS-XE releases do not support using BPI+ encrypted multicast on a cable interface when
the interface has also been configured for N+1 (1:n) High Availability or Remote Processor Redundancy Plus
(RPR+) High Availability redundancy.
In addition, BPI+ is not automatically supported after a switchover from the Working cable interface to the
Protect cable interface, because the cable interface configurations that are required for BPI+ encryption are
not automatically synchronized between the two interfaces. A workaround for this is to manually configure
the Protect cable interfaces with the required configurations.
DOCSIS Root Certificates

The Cisco CMTS supports only one DOCSIS Root CA certificate.
Maximum Burst Size

Previously, the maximum concatenated burst size parameter could be set to zero to specify an unlimited value.
In a DOCSIS 1.1 environment, this parameter should be set to a nonzero value, with a maximum value of
1522 bytes for DOCSIS 1.0 cable modems.
If a cable modem attempts to register with a maximum concatenation burst size of zero, the DOCSIS 1.1
CMTS refuses to allow the cable modem to come online. This avoids the possibility that a DOCSIS 1.0 cable
modem could interfere with voice traffic on the upstream by sending extremely large data packets. Since
DOCSIS 1.0 does not support fragmentation, transmitting such data packets could result in unwanted jitter
in the voice traffic.
In addition, DOCSIS 1.1 requires that the maximum transmit burst size be set to either 1522 bytes or the
maximum concatenated burst size, whichever is larger. Do not set the maximum concatenation burst size to
values larger than 1522 bytes for DOCSIS 1.0 cable modems.
1268
Information about DOCSIS 1.1
Note This change requires you to change any DOCSIS configuration files that specify a zero value for the maximum
concatenation burst size. This limitation does not exist for DOCSIS 1.1 cable modems unless fragmentation
has been disabled.
Performance
DOCSIS 1.0 cable modems lack the ability to explicitly request and provide scheduling parameters for advanced
DOCSIS 1.1 scheduling mechanisms, such as unsolicited grants and real-time polling. DOCSIS 1.1 cable
modems on the same upstream channel can benefit from the advanced scheduling mechanisms and a DOCSIS
1.1 CMTS can still adequately support voice traffic from DOCSIS 1.1 cable modems with DOCSIS 1.0 cable
modems on the same upstream channel.
Provisioning
The format and content of the TFTP configuration file for a DOCSIS 1.1 cable modem are significantly
different from the file for a DOCSIS 1.0 cable modem. A dual-mode configuration file editor is used to
generate a DOCSIS 1.0 style configuration file for DOCSIS 1.0 cable modems and a DOCSIS 1.1 configuration
file for DOCSIS 1.1 cable modems.
Registration
A DOCSIS 1.1 CMTS must handle the existing registration Type/Length/Value parameters from DOCSIS
1.0 cable modems as well as the new type TLVs from DOCSIS 1.1 cable modems. A DOCSIS 1.0 and DOCSIS
1.1 cable modem can successfully register with the same DOCSIS 1.1 CMTS.
A DOCSIS 1.1 cable modem can be configured to make an indirect reference to a service class that has been
statically defined at the CMTS instead of explicitly asking for the service class parameters. When this
registration request is received by a DOCSIS 1.1 CMTS, it encodes the actual parameters of the service class
in the registration response and expects a DOCSIS 1.1-specific registration-acknowledge MAC message from
the cable modem.
When a DOCSIS 1.0 cable modem registers with a DOCSIS 1.1 CMTS, the registration request explicitly
requests all nondefault service-class parameters in the registration. The absence of an indirect service class
reference eliminates the need for the DOCSIS 1.1 TLVs and eliminates the need to establish a local registration
acknowledge wait state.
When a DOCSIS 1.1 CMTS receives a registration request from a DOCSIS 1.0 cable modem, it responds
with the DOCSIS 1.0 style registration response and does not expect the cable modem to send the
registration-acknowledge MAC message.
Information about DOCSIS 1.1

DOCSIS 1.1 is the first major revision of the initial DOCSIS 1.0 standard for cable networks. Although the
initial standard provided quality data traffic over the coaxial cable network, the demands of real-time traffic
such as voice and video required many changes to the DOCSIS specification.
The DOCSIS 1.1 specification provides the following feature enhancements over DOCSIS 1.0 networks:
1269
Baseline Privacy Interface Plus
Baseline Privacy Interface Plus

DOCSIS 1.0 introduced a Baseline Privacy Interface (BPI) to protect user data privacy across the shared-medium
cable network and to prevent unauthorized access to DOCSIS-based data transport services across the cable
network. BPI encrypts traffic across the RF interface between the cable modem and CMTS, and also includes
authentication, authorization, and accounting (AAA) features.
BPI supports access control lists (ACLs), tunnels, filtering, protection against spoofing, and commands to
configure source IP filtering on RF subnets to prevent subscribers from using source IP addresses that are not
valid. DOCSIS 1.1 enhances these security features with BPI Plus (BPI+), which includes the following
enhancements:
• X.509 Digital certificates provide secure user identification and authentication. The Cisco CMTS supports
both self-signed manufacturer’s certificates and certificates that are chained to the DOCSIS Root CA
certificate.
• Key encryption uses 168-bit Triple DES (3DES) encryption that is suitable for the most sensitive
applications.
• 1024-bit public key with Pkcs#1 Version 2.0 encryption.
• Support for encrypted multicast broadcasts, so that only authorized service flows receive a particular
multicast broadcast.
• Secure software download allows a service provider to upgrade a cable modem’s software remotely,
without the risk of interception, interference, or alteration.
Concatenation
Concatenation allows a cable modem to make a single time-slice request for multiple upstream packets,
sending all of the packets in a single large burst on the upstream. Concatenation can send multiple upstream
packets as part of one larger MAC data frame, allowing the cable modem to make only one time-slot request
for the entire concatenated MAC frame, reducing the delay in transmitting the packets on the upstream channel.
This avoids wasting upstream bandwidth when sending a number of very small packets, such as TCP
acknowledgement packets.
Dynamic MAC Messages

Dynamic Service MAC messages allow the cable modem to dynamically create service flows on demand.
These messages are DOCSIS link layer equivalents of the higher layer messages that create, tear down, and
modify a service flow.
The DOCSIS 1.1 dynamic services state machine supports the following messages:
• Dynamic Service Add (DSA)—This message is used to create a new service flow.
• Dynamic Service Change (DSC)—This message is used to change the attributes of an existing service
flow.
• Dynamic Service Deletion (DSD)—This message is used to delete an existing service flow.
Note These messages are collectively known as DSX messages.
1270

DOCSIS 1.1 provides enhanced quality of service (QoS) capabilities to give priority for real-time traffic such
as voice and video:
• The DOCSIS 1.0 QoS model (a service ID (SID) associated with a QoS profile) has been replaced with
a service flow and service class model that allows greater flexibility in assigning QoS parameters to
different types of traffic and in responding to changing bandwidth conditions.
• Support for multiple service flows per cable modem allows a single cable modem to support a combination
of data, voice, and video traffic.
• Greater granularity in QoS per cable modem in either direction, using unidirectional service flows.
• Upstream service flows can be assigned one of the following QoS scheduling types, depending on the
type of traffic and application being used:
• Best-effort—Data traffic sent on a non-guaranteed best-effort basis. This type of service flow is
similar to the method used in DOCSIS 1.0 networks.
• Real-time polling (rtPS)—Real-time service flows, such as video, that produce unicast, variable
size packets at fixed intervals.
• Non-real-time polling service (nrtPS)—Similar to the rtPS type, in that the cable modem is guaranteed
regular opportunities to request data bursts of varying length, except that the CMTS can vary the
time between its polling of the cable modem depending on the amount of traffic and congestion on
the network.
• Unsolicited grants (UGS)—Constant bit rate (CBR) or committed information rate (CIR) traffic,
such as voice, that is characterized by fixed-size packets at fixed intervals, providing a guaranteed
minimum data rate.
• Unsolicited grants with activity detection (USG-AD)—Combination of UGS and rtPS, to
accommodate real-time traffic that might have periods of inactivity (such as voice using silence
suppression). The service flow uses UGS fixed grants while active, but switches to rtPS polling
during periods of inactivity to avoid wasting unused bandwidth.
Fragmentation
DOCSIS fragmentation allows the upstream MAC scheduler to slice large data requests to fit into the scheduling
gaps between UGS (voice slots). This prevents large data packets from affecting real-time traffic, such as
voice and video.
Fragmentation reduces the run-time jitter experienced by the UGS slots when large data grants preempt the
UGS slots. Disabling fragmentation increases the run-time jitter, but also reduces the fragmentation reassembly
overhead for fragmented MAC frames.
Note DOCSIS fragmentation should not be confused with the fragmentation of IP packets, which is done to fit the
packets on network segments with smaller maximum transmission unit (MTU) size. DOCSIS Fragmentation
is Layer 2 fragmentation that is primarily concerned with efficiently transmitting lower-priority packets without
interfering with high-priority real-time traffic, such as voice calls. IP fragmentation is done at Layer 3 and is
primarily intended to accommodate routers that use different maximum packet sizes.
1271
Interoperability
Interoperability
DOCSIS 1.1 cable modems can coexist with DOCSIS 1.0 and 1.0+ cable modems in the same network. The
Cisco CMTS provides the levels of service that are appropriate for each cable modem.
Payload Header Suppression

Payload header suppression (PHS) conserves link-layer bandwidth by suppressing repetitive or redundant
packet headers on both upstream and downstream service flows. PHS is enabled or disabled per service flow,
and each service flow can support a separate set of PHS rules that determine which parts of the header are
suppressed. This ensures that PHS is done in the most efficient manner for each service flow and its particular
type of application.
Downstream ToS Overwrite

Downstream ToS Overwrite is supported in DOCSIS 1.1. It can be used in IPv4 and IPv6 environment. You
can use CLI command cable service class class-index tos-overwrite and-mask or-mask or the cable modem
configuration file to configure downstream ToS overwrite.
To display the ToS value, use the show cable modem qos verbose command as shown in the following
example:
Router# show cable modem 30.140.0.41 qos verbose
Time source is NTP, 15:22:46.911 CST Wed Apr 25 2018
Sfid: 29
Current State: Active
Sid: 8
Service Class Name:
Traffic Priority: 0
Maximum Sustained rate: 0 bits/sec
Maximum Burst: 3044 bytes
Minimum Reserved rate: 0 bits/sec
Minimum Packet Size: 0 bytes
Admitted QoS Timeout: 200 seconds
Active QoS Timeout: 0 seconds
Maximum Concatenated Burst: 1522 bytes
Scheduling Type: Best Effort
Request/Transmission policy: 0x0
IP ToS Overwrite[AND-mask, OR-mask]: 0xFF, 0x0
Peak Rate: 0 bits/sec
Current Throughput: 545 bits/sec, 0 packets/sec
Sfid: 30
Current State: Active
Sid: N/A
Low Latency App: No
Service Class Name:
Traffic Priority: 0
Maximum Sustained rate: 0 bits/sec
Maximum Burst: 3044 bytes
Minimum Reserved rate: 0 bits/sec
Minimum Packet Size: 0 bytes
Admitted QoS Timeout: 200 seconds
Active QoS Timeout: 0 seconds
Maximum Latency: 0 usecs
IP ToS Overwrite[AND-mask, OR-mask]: 0xFF, 0x0
1272
DOCSIS 1.1 Quality of Service
Peak Rate: 0 bits/sec

Current Throughput: 446 bits/sec, 0 packets/sec
DOCSIS 1.1 Quality of Service

The DOCSIS 1.1 QoS framework is based on the following objects:
• Service flow—A unidirectional sequence of packets on the DOCSIS link. Separate service flows are
used for upstream and downstream traffic, and define the QoS parameters for that traffic.
• Service class—A collection of settings maintained by the CMTS that provide a specific QoS service tier
to a cable modem that has been assigned a service flow associated with that service class.
• Packet classifier—A set of packet header fields used to classify packets onto a service flow to which the
classifier belongs. The CMTS uses the packet classifiers to match the packet to the appropriate service
flow.
• Payload header suppression (PHS) rule—A set of packet header fields that are suppressed by the sending
entity before transmitting on the link, and are restored by the receiving entity after receiving a
header-suppressed frame transmission. PHS increases the bandwidth efficiency by removing repeated
packet headers before transmission.
See the following sections for more information on these components.
Service Flow
In DOCSIS 1.1, the basic unit of QoS is the service flow, which is a unidirectional sequence of packets
transported across the RF interface between the cable modem and CMTS. A service flow defines a set of QoS
parameters such as latency, jitter, and throughput assurances, and these parameters can be applied independently
to the upstream and downstream traffic flows. This is a major difference from DOCSIS 1.0 networks, where
the same QoS parameters were applied to both the downstream and upstream flows.
Note DOCSIS 1.0 networks used service IDs (SIDs) to identify the QoS parameter set for a particular flow. DOCSIS
1.1 networks use the service flow ID (SFID) to identify the service flows that have been assigned to a particular
upstream or downstream. DOCSIS 1.1 networks still use the term SID, but it applies exclusively to upstream
service flows.
Every cable modem establishes primary service flows for the upstream and downstream directions, with a
separate SFID for the upstream and the downstream flows. The primary flows maintain connectivity between
the cable modem and CMTS, allowing the CMTS to send MAC management messages at all times to the
cable modem.
In addition, a DOCSIS 1.1 cable modem can establish multiple secondary service flows. The secondary service
flows either can be permanently created (by configuring them in the DOCSIS configuration file that is
downloaded to the cable modem), or the service flows can be created dynamically to meet the needs of the
on-demand traffic, such as voice calls. Permanent service flows remain in effect, even if they are not being
used, while dynamic service flows are deleted when they are no longer needed.
At any given time, a service flow might be in one of three states (provisioned, admitted, or active). Only active
flows are allowed to pass traffic on the DOCSIS network. Every service flow is identified by an SFID, while
upstream service flows in the admitted and active state have an extra Layer 2 SID associated with them. The
SID is the identifier used by the MAC scheduler when specifying time-slot scheduling for different service
flows.
1273
Service Class
Service Class
Each service flow is associated with a service class, which defines a particular class of service and its QoS
characteristics, such as the maximum bandwidth for the service flow and the priority of its traffic. The service
class attributes can be inherited from a preconfigured CMTS local service class (class-based flows), or they
can be individually specified when a cable modem dynamically requests a service flow and the CMTS creates
it.
The DOCSIS 1.1 service class also defines the MAC-layer scheduling type for the service flow. The schedule
type defines the type of data burst requests that the cable modem can make, and how often it can make those
requests. The following types of schedule types are supported:
• Best-effort (BE)—A cable modem competes with the other cable modems in making bandwidth requests
and must wait for the CMTS to grant those requests before transmitting data. This type of service flow
is similar to the method used in DOCSIS 1.0 networks.
• Real-time polling service (rtPS)—A cable modem is given a periodic time slot in which it can make
bandwidth requests without competing with other cable modems. This allows real-time transmissions
with data bursts of varying length.
• Non-real-time polling service (nrtPS)—A cable modem is given regular opportunities to make bandwidth
requests for data bursts of varying size. This type of flow is similar to the rtPS type, in that the cable
modem is guaranteed regular opportunities to request data bursts of varying length, except that the CMTS
can vary the time between its polling of the cable modem, depending on the amount of traffic and
congestion on the network.
• Unsolicited grant service (UGS)—A cable modem can transmit fixed data bursts at a guaranteed minimum
data rate and with a guaranteed maximum level of jitter. This type of service flow is suitable for traffic
that requires a Committed Information Rate (CIR), such as Voice-over-IP (VoIP) calls.
• Unsolicited grant service with activity detection (UGS-AD)—Similar to the UGS type, except that the
CMTS monitors the traffic to detect when the cable modem is not using the service flow (such as voice
calls when nobody is speaking). When the CMTS detects silence on the service flow, the CMTS
temporarily switches the service flow to an rtPS type. When the cable modem begins using the flow
again, the CMTS switches the flow back to the UGS type. This allows the CMTS to more efficiently
support VoIP calls.
Each service flow is assigned a single service class, but the same service class can be assigned to multiple
service flows. Also, a cable modem can be assigned multiple service flows, allowing it to have multiple traffic
flows that use different service classes.
Packet Classifiers
In DOCSIS 1.0 networks, a cable modem used only one set of QoS parameters for all of its traffic, so the
CMTS simply had to route packets to and from the appropriate cable modems. In DOCSIS 1.1 networks,
however, cable modems can be using multiple service flows, and each service flow can be given a different
level of service. To quickly assign upstream and downstream packets to their proper service flows, the CMTS
uses the concept of packet classifiers.
Each packet classifier specifies one or more packet header attributes, such as source MAC address, destination
IP address, or protocol type. The classifier also specifies the service flow to be used when a packet matches
this particular combination of headers. Separate classifiers are used for downstream and upstream service
flows.
When the CMTS receives downstream and upstream packets, it compares each packet’s headers to the contents
of each packet classifier. When the CMTS matches the packet to a classifier, the CMTS then assigns the proper
SFID to the packet and transmits the packet to or from the cable modem. This ensures that the packet is
assigned its proper service flow, and thus its proper QoS parameters.
1274
Packet Header Suppression Rules
Figure below illustrates the mapping of packet classifiers.

Figure 33: Classification Within the MAC Layer
Packet Header Suppression Rules

Because many data and real-time applications may use fixed values in their packet header fields, DOCSIS
1.1 supports PHS to suppress the duplicate portions of the packet headers when a group of packets is transmitted
during a session. Each service flow can support a separate set of PHS rules that determine which parts of the
header are suppressed.
When PHS is being used, the transmitting CMTS suppresses the specified headers in all the packets for that
service flow. The receiving CMTS then restores the missing headers before forwarding the packets on to their
ultimate destination.
Proper use of PHS can increase the efficiency of packetized transmissions, especially for real-time data that
is encapsulated by other protocols, such as VoIP traffic.
Quality of Service Comparison

This section summarizes the differences in QoS between DOCSIS 1.0, DOCSIS 1.0+, and DOCSIS 1.1
networks.
1275
DOCSIS 1.0
Note Cisco CMTS routers can transparently interoperate with cable modems running DOCSIS 1.0, DOCSIS 1.0+
extensions, or DOCSIS 1.1. If a cable modem indicates at system initialization that it is DOCSIS 1.1-capable,
the Cisco CMTS router uses the DOCSIS 1.1 features. If the cable modem is not DOCSIS 1.1-capable, but
does support the DOCSIS 1.0+ QoS extensions, the Cisco CMTS automatically supports the cable modem's
requests for dynamic services. Otherwise, the cable modem is treated as a DOCSIS 1.0 device.
DOCSIS 1.0
DOCSIS1.0 uses a static QoS model that is based on a class of service (CoS) that is preprovisioned in the
DOCSIS configuration file that is downloaded to the cable modem. The CoS is a bidirectional QoS profile
that applies to both the upstream and downstream directions, and that has limited control, such as peak rate
limits in either direction, and relative priority on the upstream.
DOCSIS 1.0 defines the concept of a service identifier (SID), which identifies the cable modems that are
allowed to transmit on the network. In DOCSIS 1.0 networks, each cable modem is assigned only one SID
for both the upstream and downstream directions, creating a one-to-one correspondence between a cable
modem and its SID. All traffic originating from, or destined for, a cable modem is mapped to that particular
SID.
Typically, a DOCSIS 1.0 cable modem has one CoS and treats all traffic the same, which means that data
traffic on a cable modem can interfere with the quality of a voice call in progress. The CMTS, however, has
a limited ability to prioritize downstream traffic based on IP precedent type-of-service (ToS) bits.
For example, voice calls using higher IP precedence bits receive a higher queueing priority (but without a
guaranteed bandwidth or rate of service). A DOCSIS 1.0 cable modem could increase voice call quality by
permanently reserving bandwidth for voice calls, but then that bandwidth would be wasted whenever a voice
call is not in progress.
DOCSIS 1.0+
In response to the limitations of DOCSIS 1.0 networks in handling real-time traffic, such as voice calls, Cisco
created the DOCSIS 1.0+ extensions to provide the more important QoS enhancements that were expected
in DOCSIS 1.1. In particular, the DOCSIS 1.0+ enhancements provide basic Voice-over-IP (VoIP) service
over the DOCSIS link.
Cisco’s DOCSIS 1.0+ extensions include the following DOCSIS 1.1 features:
• Multiple SIDs per cable modem, creating separate service flows for voice and data traffic. This allows
the CMTS and cable modem to give higher priority for voice traffic, preventing the data traffic from
affecting the quality of the voice calls.
• Cable modem-initiated dynamic MAC messages—Dynamic Service Addition (DSA) and Dynamic
Service Deletion (DSD). These messages allow dynamic SIDs to be created and deleted on demand, so
that the bandwidth required for a voice call can be allocated at the time a call is placed and then freed
up for other uses when the call is over.
• Unsolicited grant service (CBR-scheduling) on the upstream—This helps provide a higher-quality channel
for upstream VoIP packets from an Integrated Telephony Cable Modem (ITCM) such as the Cisco
uBR925 cable access router.
• Ability to provide separate downstream rates for any given cable modem, based on the IP-precedence
value in the packet. This helps separate voice signaling and data traffic that goes to the same ITCM to
address rate shaping purposes.
1276
Interoperability with Different Versions of DOCSIS Networks
• Concatenation allows a cable modem to send several packets in one large burst, instead of having to
make a separate grant request for each.
Caution All DOCSIS 1.0 extensions are available only when using a cable modem and CMTS that supports these
extensions. The cable modem activates the use of the extensions by sending a dynamic MAC message. DOCSIS
1.0 cable modems continue to receive DOCSIS 1.0 treatment from the CMTS.
Interoperability with Different Versions of DOCSIS Networks

DOCSIS 1.1 cable modems have additional features and better performance than earlier DOCSIS 1.0 and
1.0+ models, but all three models can coexist in the same network. DOCSIS 1.0 and 1.0+ cable modems will
not hamper the performance of a DOCSIS 1.1 CMTS, nor will they interfere with operation of DOCSIS 1.1
features.
Table below shows the interoperability of a DOCSIS 1.1 CMTS with different versions of cable modems.
Table 216: DOCSIS 1.1 Interoperability
For this configuration... The result is...
DOCSIS 1.1 CMTS with DOCSIS DOCSIS 1.0 cable modems receive DOCSIS 1.0 features and capabilities.
1.0 cable modems BPI is supported if available and enabled on the CMTS.
DOCSIS 1.1 CMTS with DOCSIS DOCSIS 1.0+ cable modems receive basic DOCSIS 1.0 support. BPI is
1.0+ cable modems supported if available and enabled on the CMTS. In addition, DOCSIS
1.0+ cable modems also receive the following DOCSIS 1.1 features:
• Multiple SIDs per cable modem
• Dynamic service MAC messaging initiated by the cable modem
• Unsolicited grant service (UGS, CBR-scheduling) on the upstream
• Separate downstream rates for any given cable modem, based on
the IP-precedence value
• Concatenation
DOCSIS 1.1 CMTS with DOCSIS DOCSIS 1.1 cable modems receive all the DOCSIS 1.1 features listed
1.1 cable modems in this document. BPI+ is supported if available and enabled on the
CMTS.
Enhanced Rate Bandwidth Allocation (ERBA) Support for DOCSIS 1.0 Cable
Modems
To define ERBA on the downstream for DOCSIS 1.0 cable modems, use the cable qos promax-ds-burst
The ERBA feature is characterized by the following enhancements:
• Enables support for the DOCSIS1.1 Downstream Maximum Transmit Burst parameter on the Cisco
CMTS by using the cable ds-max-burst configuration command.
• Allows DOCSIS1.0 modems to support the DOCSIS1.1 Downstream Maximum Transmit Burst parameter
by mapping DOCSIS1.0 modems to overriding DOCSIS 1.1 QoS profile parameters on the Cisco CMTS.
1277
DOCSIS 3.0 Downstream Peak Traffic Rate TLV Support for ERBA
ERBA allows DOCSIS1.0 modems to burst their temporary transmission rate up to the full line rate for short
durations of time. This capability provides higher bandwidth for instantaneous bandwidth requests, such as
those in Internet downloads, without having to make changes to existing service levels in the QoS Profile.
This feature allows you to set the DOCSIS 1.0 cable modems burst transmissions, with mapping to overriding
DOCSIS 1.1 QoS profile parameters on the Cisco CMTS. DOCSIS 1.0 cable modems require DOCSIS 1.0
parameters when registering to a matching QoS profile. This feature enables maximum downstream line rates,
and the ERBA setting applies to all cable modems that register to the corresponding QoS profile.
Note QoS definitions must previously exist on the Cisco CMTS headend to support this feature.
ERBA for DOCSIS 1.0 cable modems is supported with these new or enhanced commands or keywords:
• cable qos pro max-ds-burst burst-size
• show cable qos profile n [verbose]
DOCSIS 3.0 Downstream Peak Traffic Rate TLV Support for ERBA
The DOCSIS WFQ Scheduler allows each service flow to have one dedicated queue. When ERBA is enabled
for the service flow, the peak rate is implemented as the queue shape rate within the scheduler, while the
maximum sustained rate is set as the token bucket refill rate. When ERBA is turned off, the burst size and the
peak rate value are not used.
The maximum traffic burst parameter is used to control a service flow burst duration, to burst up to the channel
line rate or a configured peak rate, when it is within its maximum burst size allowance. On the Cisco cBR-8
Converged Broadband Router, the cable ds-max-burst command is used to control this behavior explicitly.
The peak-rate keyword is introduced to specify the peak rate an ERBA-enabled service flow can use. The
peak rate value is applied to a specific service flow created after the configuration of the cable ds-max-burst
command.
If the DOCSIS 3.0 TLV 25.27 is specified for a service flow, the peak rate value is set as the TLV value.
However, if ERBA is not turned on for a service flow, the peak rate value is ignored.
During modem registration or Dynamic Service Addition (DSA) operation, the service class name TLV 25.4
is sent to create the static or dynamic downstream service flow that matches the service class template. These
downstream service flows are created with a specific peak rate.
Some of the DOCSIS 1.x an DOCSIS 2.0 cable modems, which are not fully DOCSIS 1.x or DOCSIS 2.0
compliant, may fail to come online when the downstream peak rate TLV 25.27 is received from the CMTS
during registration. To overcome this failure, you can configure the cable service attribute withhold-TLVs
command to restrict sending of the peak traffic rate TLVs to DOCSIS1.x and DOCSIS 2.0 cable modems.
For more information on how to suppress peak rate TLVs, see Suppressing Upstream and Downstream Peak
Rate TLVs for pre DOCSIS 3.0 Cable Modems, on page 1279.
Note The ERBA feature is not applicable for high priority service flows and multicast service flows.
Table below summarizes the ERBA support for the Cisco cBR-8 router.
1278
Suppressing Upstream and Downstream Peak Rate TLVs for pre DOCSIS 3.0 Cable Modems
Table 217: Enhanced Rate Bandwidth Allocation Support for the Cisco cBR-8 Router
Policer Rate Policer Exceed Policer Token Bucket Queue Shape Rate
Action Size
Traditional Maximum Sustained Transmit A value computed Maximum Sustained

Service Flow Traffic Rate (unused) internally by CMTS Traffic Rate
(unused)
ERBA-Enabled Maximum Sustained Drop Maximum Traffic Burst Peak Traffic Rate
Service Flow Traffic Rate TLV
In Cisco cBR-8 routers, the dual token bucket-based shaper is used to support ERBA on the Cisco cBR-8
CCAP line card (the ERBA feature is always enabled on the Cisco cBR-8 CCAP line card). The dual token
bucket shaper has two independent token buckets for each service flow. The maximum rate of one bucket is
configured to MSR and the maximum tokens are set to maximum traffic burst. The other bucket is configured
with the refilling rate of the peak rate and the maximum tokens are set to the default level of 4 milliseconds.
Packets are shaped if any of the two buckets are exhausted.
Table below summarizes the ERBA dual token bucket configuration for the Cisco cBR-8 routers.
Table 218: ERBA Dual Token Bucket Configuration
Token Bucket Rate (One) Token Bucket Size Token Bucket Token Bucket
(One) Rate (Two) Size (Two)
Traditional Service Maximum Sustained 4ms * MSR N/A N/A

Flow Traffic Rate
ERBA-enabled Maximum Sustained Maximum Traffic Peak Rate 4ms * Peak Rate
Service Flow Traffic Rate Burst or 4ms * MSR
Suppressing Upstream and Downstream Peak Rate TLVs for pre DOCSIS 3.0
Cable Modems
The DOCSIS 3.0 upstream (US) peak rate TLV 24.27 and downstream (DS) peak rate TLV 25.27 are enabled
on the Cisco CMTS through the cable service class command or the CM configuration file. The DOCSIS 1.x
and DOCSIS 2.0 CMs do not support these TLVs. Ideally, if a DOCSIS 1.x or DOCSIS 2.0 CM receives peak
rate TLVs during registration, it should ignore these TLVs and proceed with the registration. However there
are a few old non-compliant pre DOCSIS 3.0 CMs, which may fail to come online when peak-rate TLVs are
received in the registration response from the Cisco CMTS. To overcome this, the Cisco CMTS enables
suppression of the DOCSIS 3.0 peak rate TLVs for the pre-DOCSIS3.0 CMs.
To suppress the DOCSIS 3.0 US and DS peak rate TLVs, use the cable service attribute withhold-TLVs
command with the peak-rate keyword in global configuration mode. When configured, this command
restricts the Cisco CMTS from sending US and DS peak rate TLVs to the DOCSIS 1.x and DOCSIS 2.0 CMs.
The decision to send the TLVs is based on the DOCSIS version of the CM received during registration. If the
registration request is from a pre DOCSIS 3.0 CM, the peak rate TLVs are not sent in the registration response.
However this command does not restrict sending of DOCSIS 3.0 peak-rate TLVs to DOCSIS 3.0 CMs.
1279
Downstream Classification Enhancement with MAC Addresses
Downstream Classification Enhancement with MAC Addresses

Downstream classifiers, specified in the cable modem configuration file, are used to map packets to service
flows based on DOCSIS specifications. New combinations of downstream classifiers with a destination MAC
address are supported. This enhancement enables service providers to better manage high priority service
flows associated with a downstream classifier. For example, a single User Datagram Protocol (UDP) port can
be shared by high priority and low priority traffic.
Downstream classification is automatically enabled on the Cisco CMTS router. The downstream classifier
combinations that are supported on the router are listed below:
Without Combination
• IP (IPv4)
• IPv6
• TCP/UDP
• Destination MAC
With Combination
• IPv4 + TCP/UDP
• IPv6 + TCP/UDP
• Destination MAC + IPv4 (with the exception of a destination IP address)
• Destination MAC + IPv6 (with the exception of a destination IPv6 address)
• Destination MAC + TCP/UDP
• Destination MAC + IPv4 + TCP/UDP (with the exception of a destination IP address)
• Destination MAC + IPv6 + TCP/UDP (with the exception of a destination IPv6 address)
Benefits
DOCSIS 1.1 includes a rich set of features that provide advanced and flexible QoS capabilities for various
types of traffic (voice, data, and video) over the cable network. It also provides enhanced security and
authentication features.
Baseline Privacy Interface Plus Enhancement

The Plus (+) version of the Baseline Privacy Interface (BPI+) in DOCSIS 1.1 provides a set of extended
services within the MAC sublayer that increase performance and system security. Digital certificates provide
secure authentication for each cable modem, to prevent identity theft on the basis of MAC and IP addresses.
Advanced encryption provides a secure channel between the cable modem and CMTS, and secure software
download allows a service provider to upgrade the software on cable modems, without the threat of interception,
interference, or alteration of the software code.
Dynamic Service Flows

The dynamic creation, modification, and deletion of service flows allows for on-demand reservation on Layer
2 bandwidth resources. The CMTS can now provide special QoS to the cable modem dynamically for the
duration of a voice call or video session, as opposed to the static provisioning and reservation of resources at
the time of cable modem registration. This provides a more efficient use of the available bandwidth.
1280
Benefits
Concatenation
The cable modem concatenates multiple upstream packets into one larger MAC data frame, allowing the cable
modem to make only one time-slot request for the entire concatenated MAC frame, as opposed to requesting
a time slot for each packet. This reduces the delay in transferring the packet burst upstream.
Enhanced QoS
Extensive scheduling parameters allow the CMTS and the cable modem to communicate QoS requirements
and achieve more sophisticated QoS on a per service-flow level.
Different new time-slot scheduling disciplines help in providing guaranteed delay and jitter bound on shared
upstream. Activity detection helps to conserve link bandwidth by not issuing time slots for an inactive service
flow. The conserved bandwidth can then be reused for other best-effort data slots.
Packet classification helps the CMTS and cable modem to isolate different types of traffic into different
DOCSIS service flows. Each flow could be receiving a different QoS service from CMTS.
Fragmentation
Fragmentation splits large data packets so that they fit into the smaller time slots inbetween UGS slots. This
reduces the jitter experienced by voice packets when large data packets are transmitted on the shared upstream
channel and preempt the UGS slots used for voice.
Multiple Subflows per SID

This feature allows the cable modem to have multiple calls on a single hardware queue. This approach scales
much better than requiring a separate SID hardware queue on the cable modem for each voice call.
Payload Header Suppression

Payload Header Suppression (PHS) allows the CMTS and cable modem to suppress repetitive or redundant
portions in packet headers before transmitting on the DOCSIS link. This conserves link bandwidth, especially
with types of traffic such as voice, where the header size tends to be as large as the size of the actual packet.
Service Classes
The use of the service class provides the following benefits for a DOCSIS 1.1 network:
• It allows operators to move the burden of configuring service flows from the provisioning server to the
CMTS. Operators provision the modems with the service class name; the implementation of the name
is configured at the CMTS. This allows operators to modify the implementation of a given service to
local circumstances without changing modem provisioning. For example, some scheduling parameters
might need to be set differently for two different CMTSs to provide the same service. As another example,
service profiles could be changed by time of day.
• It allows CMTS vendors to provide class-based-queuing if they choose, where service flows compete
within their class and classes compete with each other for bandwidth.
• It allows higher-layer protocols to create a service flow by its service class name. For example, telephony
signaling might direct the cable modem to instantiate any available provisioned service flow of class
G.711.
1281
How to Configure the Cisco CMTS for DOCSIS 1.1 Operations
Note The service class is optional. The flow scheduling specification may always be provided in full; a service flow
may belong to no service class whatsoever. CMTS implementations may treat such unclassed flows differently
from classed flows with equivalent parameters.
How to Configure the Cisco CMTS for DOCSIS 1.1 Operations

See the following sections for the configuration tasks for DOCSIS 1.1 operations. Each task in the list is
identified as either required or optional.
Note This section describes only the configuration tasks that are specific for DOCSIS 1.1 operations.
Configuring Baseline Privacy Interface

BPI+ encryption is by default enabled for 56-bit DES encryption on all cable interfaces. If BPI+ encryption
has been previously disabled, or if you want to reconfigure BPI+ encryption on a cable interface on the CMTS,
use the following procedure.
Note If you have disabled BPI+ encryption on a cable interface, and a cable modem attempts to register on that
interface using BPI+ encryption, the CMTS will reject its registration request, displaying a
%CBR-4-SERVICE_PERMANENTLY_UNAVAILABLE error message. The show cable modem command
will also show that this cable modem has been rejected with a MAC status of reject(c).
Before you begin

BPI+ encryption is supported on all Cisco CMTS images that include “k1”, “k8”, or “k9” in its file name or
BPI in the feature set description. All BPI images support 40-bit and 56-bit DES encryption.
By default, BPI+ encryption is enabled for 56-bit DES encryption. Also, when a cable modem is running
DOCSIS 1.1 software, BPI+ encryption is enabled by default, unless the service provider has disabled it by
setting the Privacy Enable field (TLV 29) in the DOCSIS configuration file to 0. Therefore, both the CMTS
and cable modem are set to use BPI+ encryption when using the default configurations.
Procedure

prompted.
Example:
Router> enable
Router#
1282

Example:

Router(config)#
Step 3 interface cableslot /subslot /port Enters interface configuration mode for the cable interface
line card at this particular slot.
Example:

Router(config-if)#
Step 4 cable privacy (Optional) Enables BPI+ 56-bit DES encryption on the
cable interface (default).
Example:
Router(config-if)# cable privacy

Router(config-if)#
Step 5 cable privacyaccept-self-signed-certificate (Optional) Allows cable modems to register using

self-signed manufacturer certificates, as opposed to the
Example:
default of allowing only manufacturer’s certificates that
are chained to the DOCSIS root certificate.
Router(config-if)# cable privacy
accept-self-signed-certificate Caution Use the above command sparingly, as it
Router(config-if)#
bypasses DOCSIS BPI+ certificates. Otherwise,
self-signed certificates provide workaround
registration for cable modems that are not
compliant with DOCSIS BPI+ certificates. This
functionality is strictly intended for
troubleshooting of a short duration or in the
context of additional security measures.
Note By default, the CMTS does not accept

self-signed certificates. In the default
configuration, if a cable modem attempts to
register with self-signed certificates, the CMTS
will refuse to allow the cable modem to register.
Step 6 cable privacy authorize-multicast (Optional) Enables BPI+ encryption on the cable interface
and uses AAA protocols to authorize all multicast stream
Example:
(IGMP) join requests.
Router(config-if)# cable privacy Note If you use this command to authorize multicast
authorize-multicast streams, you must also use the cable privacy
Router(config-if)#
authenticate-modem command to enable AAA
services on the cable interface.
1283

Step 7 cable privacy mandatory (Optional) Requires baseline privacy be active for all CMs
with BPI/BPI+ enabled in the DOCSIS configuration files,
Example:
else the CMs are forced to go offline.
Router(config-if)# cable privacy mandatory If a CM does not have BPI enabled in its DOCSIS
Router(config-if)# configuration file, it will be allowed to come online without
BPI.
Step 8 cable privacy oaep-support (Optional) Enables BPI+ encryption on the cable interface
and enables Optimal Asymmetric Encryption Padding
Example:
(OAEP). This option is enabled by default. Disabling this
option could have a performance impact.
Router(config-if)# cable privacy oaep-support
Router(config-if)#
Step 9 cable privacy kek {life-time seconds } (Optional) Configures the life-time values for the key
encryption keys (KEKs) for BPI+ operations on all cable
Example:
interfaces.
Router(config-if)# cable privacy kek life-time
302400
Router(config-if)#
Step 10 cable privacy tek {life-time seconds} (Optional) Configures the life-time values for the traffic
encryption keys (TEKs) for BPI+ operations on all cable
Example:
interfaces.
Router(config-if)# cable privacy tek life-time
86400
Router(config-if)#

Example: Note Repeat steps Step 3, on page 1283 through
Step 11, on page 1284 for each cable interface.
Router(config)#

Example:
Router#
What to do next
You can also configure the following additional timers for BPI+ operations in the DOCSIS configuration file
for each cable modem. As a general rule, you do not need to specify these timers in the DOCSIS configuration
file unless you have a specific reason for changing them from their default values.
1284
Downloading the DOCSIS Root Certificate to the CMTS
Table 219: Individual Cable Modem BPI+ Timer Values
Timer Description
Authorize Wait Timeout The amount of time a cable modem will wait for a response from a CMTS
when negotiating a KEK for the first time.
Reauthorize Wait Timeout The amount of time a cable modem will wait for a response from a CMTS
when negotiating a new KEK because the Authorization Key (KEK) lifetime
is about to expire.
Authorize Reject Wait Timeout The amount of time a cable modem must wait before attempting to negotiate
a new KEK if the CMTS rejects its first attempt to negotiate a KEK.
Operational Wait Timeout The amount of time a cable modem will wait for a response from a CMTS
when negotiating a TEK for the first time.
Rekey Wait Timeout The amount of time a cable modem will wait for a response from a CMTS
when negotiating a new TEK because the TEK lifetime is about to expire.

DOCSIS 1.1 allows cable modems to identify themselves using a manufacturer’s chained X.509 digital
certificate that is chained to the DOCSIS root certificate. The DOCSIS root certificate is already installed on
the bootflash of the CMTS router. However, if you want to install another root certificate, for example, the
Euro-DOCSIS certificate, download the certificate and save it on the bootflash as "euro-root-cert".
Tip For more information about the DOCSIS root certificate provided by Verisign, see the information at the
following URL: http://www.verisign.com/products-services/index.html
Note You may load the DOCSIS root certificate and a EuroDOCSIS or PacketCable root certificate. Cisco
recommends that the EuroDOCSIS PacketCable root certificates be copied into bootflash.
To download the DOCSIS root certificate to the Cisco CMTS, which is required if any cable modems on the
network are using chained certificates, use the following procedure:
Step 1 Download the DOCSIS root certificate from the DOCSIS certificate signer, Verisign. At the time of this document’s
printing, the DOCSIS root certificate is available for download at the following URL:
http://www.verisign.com/products-services/index.html
Step 2 Verisign distributes the DOCSIS root certificate in a compressed ZIP archive file. Extract the DOCSIS root certificate
from the archive and copy the certificate to a TFTP server that the CMTS can access.
Tip To avoid possible confusion with other certificates, keep the file’s original filename of “CableLabs_DOCSIS.509”
when saving it to the TFTP server.
1285
Step 3 Log in to the Cisco CMTS using either a serial port connection or a Telnet connection. Enter the enable command and
password to enter Privileged EXEC mode:
Example:
Router> enable
Password: <password>
Router#
Step 4 Use the dir bootflash command to verify that the bootflash has sufficient space for the DOCSIS root certificate
(approximately 1,000 bytes of disk space):
Example:
1 -rw- 3229188 Dec 30 2002 15:53:23 cbrsup-universalk9.2015-03-18_03.30_johuynh.SSA.bin

Router#
Tip If you delete files from the bootflash to make room for the DOCSIS root certificate, remember to use the squeeze
command to reclaim the free space from the deleted files.
Step 5 Use the copy tftp bootflash command to copy the DOCSIS root certificate to the router’s bootflash memory. (The file
must be named “root-cert” on the bootflash for the CMTS to recognize it as the root certificate.)
Example:
Router# copy tftp bootflash:
Address or name of remote host []? tftp-server-ip-address
Source filename []? CableLabs_DOCSIS.509
Destination filename [CableLabs_DOCSIS.509]? root-cert
Loading CableLabs_DOCSIS.509 from tftp-server-ip-address (via FastEthernet0/0): !

[OK - 996/1024 bytes]
996 bytes copied in 4.104 secs (249 bytes/sec)
Router#
Tip You can also copy the root certificate to a PCMCIA Flash Disk (disk0 or disk1). However, because Flash Disks
are not secure and easily removed from the router, we recommend that you keep the root certificate in the
bootflash for both operational and security reasons.
Step 6 Verify that the DOCSIS root certificate has been successfully copied to the bootflash memory:
Example:
1 -rw- 3229188 Dec 30 2002 15:53:23 cbrsup-universalk9.2015-03-18_03.30_johuynh.SSA.bin
2 -rw- 996 Mar 06 2002 16:03:46 root-cert

3408876 bytes total (248696 zxbytes free)
Router#
1286
Adding a Manufacturer’s Certificate as a Trusted Certificate
Step 7 (Optional) After the first cable modem has registered using BPI+, you can use the show crypto ca trustpoints command
to display the Root certificate that the CMTS has learned:
Note The show crypto ca trustpoints command does not display the root certificate until after at least one cable
modem has registered with the CMTS using BPI+ encryption. Alternatively, you can use the unsupported
command test cable generate in privileged EXEC mode to force the CMTS to register the root certificate.
Example:
Router# show crypto ca trustpoints

Root certificate
Status: Available
Certificate Serial Number: D54BB68FE934324F6B8FD0E41A65D867
Key Usage: General Purpose
Issuer:
CN = DOCSIS Cable Modem Root Certificate Authority
OU = Cable Modems
O = Data Over Cable Service Interface Specifications
C = US
Subject Name:
CN = "BPI Cable Modem Root Certificate Authority "
OU = DOCSIS
O = BPI
C = US
Validity Date:
start date: 07:00:00 UTC Mar 27 2001
end date: 06:59:59 UTC Jan 1 2007
What to do next
Tip To display all certificates (Root, Manufacturers, CM) that the CMTS has learned, use the show crypto ca
certificates command.
Adding a Manufacturer’s Certificate as a Trusted Certificate

The DOCSIS specifications allow operators to control which manufacturer’s and CM certificates are allowed
on each CMTS by marking them as either trusted or untrusted. You can add a certificate to the list of trusted
certificates on the Cisco CMTS using SNMP commands, as described in the following section:
Adding a Certificate as a Trusted Certificate Using SNMP Commands

You can also use an SNMP manager to create and add certificates to the CMTS list of trusted certificates by
manipulating the tables and attributes in the DOCS-BPI-PLUS-MIB . To add a manufacturer’s certificate,
add an entry to the docsBpi2CmtsCACertTable table. Specify the following attributes for each entry:
• docsBpi2CmtsCACertStatus—Set to 4 to create the row entry.
• docsBpi2CmtsCACert—The hexadecimal data, as an X509Certificate value, for the actual X.509
certificate.
• docsBpi2CmtsCACertTrust—An Integer value from 1 to 4 specifying the certificate’s trust status:
1=trusted, 2=untrusted, 3= chained, 4=root. Specify 1 for certificates that should be trusted and 3 for
chained certificates that should be verified with the root certificate.
1287
Adding a Certificate as a Trusted Certificate Using SNMP Commands
Similarly, to add a CM certificate to the list of trusted certificates, add an entry to the
docsBpi2CmtsProvisionedCmCertTable table. Specify the following attributes for each entry:
• docsBpi2CmtsProvisionedCmCertStatus—Set to 4 to create the row entry.
• docsBpi2CmtsProvisionedCmCert—The hexadecimal data, as an X509Certificate value, for the actual
X.509 certificate.
• docsBpi2CmtsProvisionedCmCertTrust—An Integer value from 1 to 2 specifying the certificate’s trust
status: 1=trusted, 2=untrusted. Specify 1 for CM certificates that should be trusted.
Tip Always set the CertStatus attributes before loading the actual certificate data, because otherwise the CMTS
will assume the certificate is chained and will immediately attempt to verify it with the manufacturers and
root certificates.
For example, to use the Unix command-line SNMP utility to add a manufacturer’s certificate to the list of
trusted certificates on the CMTS at IP address 192.168.100.134, enter the following command (be sure to
substitute a valid index pointer for the table entry for the <index> value).
% setany -v2c 192.168.100.134 private docsBpi2CmtsCACertStatus.

<index>
-i 4
docsBpi2CmtsCACert.
<index>
-o
'<hex_data>' docsBpi2CmtsCACertTrust.
<index>
-i 1
To do the same thing for a CM certificate, use the following command:
% setany -v2c 192.168.100.134 private docsBpi2CmtsProvisionedCmCertStatus.

<index>
-i 4 docsBpi2CmtsProvisionedCmCert.
<index>
-o
'<hex_data>' docsBpi2CmtsProvisionedCmCertTrust.
<index>
-i 1
Tip Most operating systems cannot accept input lines that are as long as needed to input the hexadecimal decimal
string that specifies a certificate. For this reason, you should use a graphical SNMP manager to set these
attributes. For a number of certificates, you can also use a script file, if more convenient.
Note If you are adding self-signed certificates, you must also use the cable privacy accept-self-signed-certificate
command before the CMTS will accept the certificates.
1288
Adding a Manufacturer’s or CM Certificate to the Hotlist
Adding a Manufacturer’s or CM Certificate to the Hotlist

The DOCSIS specifications allow operators to add a digital manufacturer’s or CM certificate to a hotlist (also
known as the certificate revocation list, or CRL) on the CMTS, to indicate that this particular certificate should
no longer be accepted. This might be done when a user reports that their cable modem has been stolen, or
when the service provider decides not to support a particular manufacturer’s brand of cable modems.
Adding a Certificate to the Hotlist Using SNMP Commands

You can also use an SNMP manager to create and add certificates to the hotlist by manipulating the tables
and attributes in the DOCS-BPI-PLUS-MIB . To add a manufacturer’s certificate, add an entry to the
docsBpi2CmtsCACertTable table. Specify the following attributes for each entry:
• docsBpi2CmtsCACertStatus—Set to 4 to create the row entry.
• docsBpi2CmtsCACert—The hexadecimal data, as an X509Certificate value, for the actual X.509
certificate.
• docsBpi2CmtsCACertTrust—An Integer value from 1 to 4 specifying the certificate’s trust status:
1=trusted, 2=untrusted, 3= chained, 4=root. When adding a certificate to the hotlist, set this attribute to
2 for untrusted.
Similarly, to add a CM certificate to the hotlist, add an entry to the docsBpi2CmtsProvisionedCmCertTable
table. Specify the following attributes for each entry:
• docsBpi2CmtsProvisionedCmCertStatus—Set to 4 to create the row entry.
• docsBpi2CmtsProvisionedCmCert—The hexadecimal data, as an X509Certificate value, for the actual
X.509 certificate.
• docsBpi2CmtsProvisionedCmCertTrust—An Integer value from 1 to 2 specifying the certificate’s trust
status: 1=trusted, 2=untrusted. When adding a certificate to the hotlist, set this attribute to 2 for untrusted.
Tip Always set the CertStatus attributes before loading the actual certificate data, because otherwise the CMTS
will assume the certificate is chained and will immediately attempt to verify it with the manufacturers and
root certificates.
Note This procedure is identical to the one given for adding a certificate as a trusted certificate in the Adding a
Certificate as a Trusted Certificate Using SNMP Commands, on page 1287, except that the
docsBpi2CmtsProvisionedCmCertTrust attribute is set to 2 instead of 1.
For example, to use the Unix command-line SNMP utility to add a manufacturer’s certificate to the hotlist on
the CMTS at IP address 192.168.100.113, enter the following command (be sure to substitute a valid index
pointer for the table entry for the <index> value).
% setany -v2c 192.168.100.113 private docsBpi2CmtsCACertStatus.

<index>
-i 4
docsBpi2CmtsCACert.
<index>
-o
'<hex_data>' docsBpi2CmtsCACertTrust.
<index>
-i 2
1289
Enabling Concatenation
To do the same thing for a CM certificate, use the following command:
% setany -v2c 192.168.100.113 private docsBpi2CmtsProvisionedCmCertStatus.

<index>
-i 4
docsBpi2CmtsProvisionedCmCert.
<index>
-o
'<hex_data>' docsBpi2CmtsProvisionedCmCertTrust.
<index>
-i 2
Tip Most operating systems cannot accept input lines that are as long as needed to input the hexadecimal decimal
string that specifies a certificate. For this reason, you should use a graphical SNMP manager to set these
attributes. For a number of certificates, you can also use a script file, if more convenient.
Enabling Concatenation
To enable concatenation for one or more upstreams on a cable interface (which is the default configuration),
use the following procedure:
Procedure

prompted.
Example:
Router> enable
Router#

Example:

Router(config)#
Step 3 interface cableslot / port Enters interface configuration mode for the cable interface
Example:

Router(config-if)#
Step 4 cable upstream n concatenation Enables concatenation for the specified upstream on the
cable interface.
Example:
Note Repeat this command for each upstream on the
Router(config-if)# cable upstream 0 concatenation interface.
Router(config-if)# cable upstream 1 concatenation
Router(config-if)#
1290
Enabling DOCSIS Fragmentation

Example:
Router(config)#

Example:
Router#

To enable DOCSIS fragmentation for one or more upstreams on a cable interface (which is the default
configuration), use the following procedure:
SUMMARY STEPS
1. enable
3. interface cableslot /port
4. cable upstreamn fragmentation
5. cable upstream n unfrag-slot-jitter [limitjitter | cac-enforce]
6. exit
7. exit
DETAILED STEPS

prompted.
Example:
Router> enable
Example:
Router#

Example:

Router(config)#
Step 3 interface cableslot /port Enters interface configuration mode for the cable interface
Example:
1291

Router(config-if)#
Step 4 cable upstreamn fragmentation Enables fragmentation for the specified upstream on the
cable interface.
Example:
Note Repeat this command for each upstream on the
Router(config-if)# cable upstream 2 fragmentation interface.
Router(config-if)# cable upstream 3 fragmentation
Router(config-if)#
Step 5 cable upstream n unfrag-slot-jitter [limitjitter | (Optional) Specifies the amount of jitter that can be tolerated
cac-enforce] on the upstream due to unfragmentable slots. The limit
option specifies the allowable jitter limit in microseconds
Example:
(0 to 4,294,967,295. The cac-enforce option configures the
upstream so that it rejects service flows requesting jitter
Router(config-if)# cable upstream 0
unfrag-slot-jitter limit 2000 cac-enforce less than the fragmentable slot jitter.
Router(config-if)#
Note By default, jitter is set to a limit of 0
microseconds, and the cac-enforce option is
enabled.

Example:
Router(config)#

Example:
Router#
Example
The following example of the show cable qos profile command illustrates that the maximum
downstream burst has been defined, and is a management-created QoS profile:
Router# show cable qos profile

ID Prio Max Guarantee Max Max TOS TOS Create B IP prec.
upstream upstream downstream tx mask value by priv rate
bandwidth bandwidth bandwidth burst enab enab
1 0 0 0 0 0 0xFF 0x0 cmts(r) no no
2 0 64000 0 1000000 0 0xFF 0x0 cmts(r) no no
3 7 31200 31200 0 0 0xFF 0x0 cmts yes no
4 7 87200 87200 0 0 0xFF 0x0 cmts yes no
6 1 90000 0 90000 1522 0xFF 0x0 mgmt yes no
10 1 90000 0 90000 1522 0x1 0xA0 mgmt no no
50 0 0 0 96000 0 0xFF 0x0 mgmt no no
1292
Enabling DOCSIS 1.1 Downstream Maximum Transmit Burst on the Cisco cBR-8 Router
51 0 0 0 97000 0 0xFF 0x0 mgmt no no
The following example illustrates the maximum downstream burst size in sample QoS profile 10
with the show cable qos profileverbose command in privileged EXEC mode:
Router# show cable qos profile 10 verbose

Profile Index 10
Name
Upstream Traffic Priority 1
Upstream Maximum Rate (bps) 90000
Upstream Guaranteed Rate (bps) 0
Unsolicited Grant Size (bytes) 0
Unsolicited Grant Interval (usecs) 0
Upstream Maximum Transmit Burst (bytes) 1522
Downstreamam Maximum Transmit Burst (bytes) 100000
IP Type of Service Overwrite Mask 0x1
IP Type of Service Overwrite Value 0xA0
Downstream Maximum Rate (bps) 90000
Created By mgmt
Baseline Privacy Enabled no
Enabling DOCSIS 1.1 Downstream Maximum Transmit Burst on the Cisco cBR-8
Router
Perform the following steps to configure ERBA on the Cisco cBR-8 router. This procedure and the associated
commands are subject to the guidelines and restrictions cited in this document.
Procedure

Router> enable

Example:

Router(config)#
Step 3 [no] cable ds-max-burst burst-threshold threshold Enables the support for DOCSIS 1.1 downstream max burst.
To remove this configuration, use the no form of this
Example:
command.
Router(config)# cable ds-max-burst burst-threshold
2048
Step 4 cable service class class-index peak-rate peak-rate Set the peak-rate value of a specific service class.
Example:
1293
Monitoring DOCSIS Operations
Router(config)# cable service class 1 peak-rate

1000
Step 5 Ctrl^Z Returns to privileged EXEC mode.

Example:
Router(config)# Ctrl^Z
Router#
Example
When this feature is enabled, new service flows with burst size larger than the burst threshold are
supported. However, the existing service flows are not affected.
When this feature is disabled, no new service flows are configured with the Downstream Maximum
Transmit Burst parameter—the cable ds-max-burst command settings. However, the existing service
flows are not affected.
Monitoring DOCSIS Operations

The following sections describe the commands that provide information about the DOCSIS network and its
cable modems, the RF network and cable interfaces on the CMTS, and BPI+ operations.
Monitoring the DOCSIS Network

The show cable modem command is the primary command to display the current state of cable modems and
the DOCSIS network. This command has many options that provide information on different aspects of
DOCSIS operations.
Displaying the Status of Cable Modems

To display a list of known cable modems and their current status, use the show cable modem command.
You can also display a particular cable modem by specifying its MAC address or IP address with the show
cable modem command. If you specify the MAC address or IP address for a CPE device, the command will
display the information for the cable modem that is associated with that device.
Note If the CPE IP address is no longer associated with a cable modem, the show cable modem command might
not display information about the cable modem. To display the IP address of the CPE device for the cable
modem, use the clear cable host ip-address command to clear the IP address of the modem from the router
database, and then enter the ping docsis mac-address command, which resolves the MAC address by sending
the DOCSIS ping to the CM.
To display a list of cable modems sorted by their manufacturer, use the vendor option.
1294
Displaying the Status of Cable Modems
The MAC state field in each of these displays shows the current state of the cable modem:
Table 220: Descriptions for the MAC State Field
MAC State Value Description
Registration and Provisioning Status Conditions
init(r1) The CM sent initial ranging.
init(r2) The CM is ranging. The CMTS received initial ranging from the Cm and has sent
RF power, timing offset, and frequency adjustments to the CM.
init(rc) Ranging has completed.
init(d) The DHCP request was received. This also indicates that the first IP broadcast
packet has been received from the CM.
init(i) The DHCP reply was received and the IP address has been assigned, but the CM
has not yet replied with an IP packet.
init(o) The CM has begun to download the option file (DOCSIS configuration file) using
the Trivial File Transfer Protocol (TFTP), as specified in the DHCP response. If
the CM remains in this state, it indicates that the download has failed.
init(t) Time-of-day (TOD) exchange has started.
resetting The CM is being reset and will shortly restart the registration process.
Non-error Status Conditions
offline The CM is considered offline (disconnected or powered down).
online The CM has registered and is enabled to pass data on the network.
online(d) The CM registered, but network access for the CM has been disabled through the
DOCSIS configuration file.
online(pk) The CM registered, BPI is enabled and KEK is assigned.
online(pt) The CM registered, BPI is enabled and TEK is assigned. BPI encryption is now
being performed.
expire(pk) The Cm registered, BPI is enabled, KEK was assigned but has since expired.
expire(pt) The Cm registered, BPI is enabled, TEK was assigned but has since expired.
Error Status Conditions
1295
Displaying a Summary Report for the Cable Modems
MAC State Value Description
reject(m) The CM attempted to register but registration was refused due to a bad Message
Integrity Check (MIC) value. This also could indicate that the shared secret in the
DOCSIS configuration file does not match the value configured on the CMTS with
the cable shared-secret command.
It can also indicate that the cable tftp-enforce command has been used to require
that a CM attempt a TFTP download of the DOCSIS configuration file before
registering, but the CM did not do so.
reject(c) The CM attempted to register, but registration was refused due to a a number of
possible errors:
• The CM attempted to register with a minimum guaranteed upstream bandwidth
that would exceed the limits imposed by the cable upstream
admission-control command.
• The CM has been disabled because of a security violation.
• A bad class of service (COS) value in the DOCSIS configuration file.
• The CM attempted to create a new COS configuration but the CMTS is
configured to not permit such changes.
reject(pk) KEK key assignment is rejected, BPI encryption has not been established.
reject(pt) TEK key assignment is rejected, BPI encryption has not been established.
reject(ts) The CM attempted to register, but registration failed because the TFTP server
timestamp in the CM registration request did not match the timestamp maintained
by the CMTS. This might indicate that the CM attempted to register by replaying
an old DOCSIS configuration file used during a prior registration attempt.
reject(ip) The CM attempted to register, but registration failed because the IP address in the
CM request did not match the IP address that the TFTP server recorded when it
sent the DOCSIS configuration file to the CM. IP spoofing could be occurring.
reject(na) The CM attempted to register, but registration failed because the CM did not send
a Registration-Acknowledgement (REG-ACK) message in reply to the
Registration-Response (REG-RSP) message sent by the CMTS. A
Registration-NonAcknowledgement (REG-NACK) is assumed.
Displaying a Summary Report for the Cable Modems

The show cable modem command also can provide a summary report of the cable modems by using the
summary and total options.
You can also use the summary and total options to display information for a single interface or a range of
interfaces.
Displaying the Capabilities of the Cable Modems

To display the capabilities and current DOCSIS provisioning for cable modems, use the mac option.
To get a summary report of the cable modems and their capabilities, use the mac option with the summary
and total options.
1296
Displaying Detailed Information About a Particular Cable Modem
Displaying Detailed Information About a Particular Cable Modem

Several options for the show cable modem command display detailed information about a particular cable
modem (as identified by its MAC address). The verbose option displays the most comprehensive output.
The connectivity and maintenance options also provide information that can be useful in troubleshooting
problems with a particular cable modem.
Monitoring the RF Network and Cable Interfaces

You can use the show interface cable command to display information about the operation of the RF network
and the cable interfaces on the CMTS.
Tip For a complete description of the show cable interface command and its options, see the “Cisco Cable Modem
Termination System Commands” chapter in the Cisco Broadband Cable Command Reference Guide (see
http://www.cisco.com/c/en/us/td/docs/cable/cbr/configuration/guide/b_cmts_quality_of_services/docsis_1_
1.html#ref_1239231).
Displaying Information About Cloned Cable Modems

To display the list of cable modems detected as cloned, use the privacy hotlist option with the show interface
cable command.
Denying RF Access For Cable Modems

To deny radio frequency (RF) access for cable modems during ranging, use the cable privacy hotlist cm
mac-address command.
The following example shows how to block cloned cable modems using their own MAC address:
Router(config)# cable privacy hotlist cm 00C0.0102.0304

Router(config)#
When an operator identifies a modem’s MAC address that should not be registered on a specific CMTS, the
operator can add this MAC address to the CMTS using the above command. This command ensures that the
modem will not be allowed to come online on any interface on that CMTS.
Displaying Information About the Mac Scheduler

To display information about the DOCSIS MAC layer scheduler that is operating on each cable interface, use
the mac-scheduler option with the show cable interface command. You can display information for all of
the upstreams on an interface, or you can display information for a single upstream on an interface.
Displaying Information About QoS Parameter Sets

To display information about the DOCSIS 1.1 QoS parameter sets that have been defined on a cable interface,
use the qos paramset option with the show cable interface command.
You can also display detailed information for a particular parameter set by specifying the index number for
its Class of Service along with the verbose option.
1297
Displaying Information About Service Flows
Displaying Information About Service Flows

To display the service flows and their QoS parameter sets that are configured on a cable interface, use the
service-flow option with the show interface cable command.
To display the major QoS parameters for each service flow, add the qos option to this command.
To display the complete QoS parameters for a particular service flow, use the qos and verbose options. You
can use these options separately or together.
Displaying Information About Service IDs

To display information about Service IDs (SIDs), which are assigned to only upstreams in DOCSIS 1.1
networks, use the sid option with the show interface cable command.
Add the qos option to display the major QoS parameters associated with each SID.
To display detailed information about a particular SID and its QoS parameters, use both the qos and verbose
options.
Monitoring BPI+ Operations

See the following sections to monitor the state of BPI operations on the CMTS and its connected cable modems:
Displaying the Current BPI+ State of Cable Modems

To display the current BPI+ state of cable modems, use the show cable modem command. If used without
any options, this command displays the status for cable modems on all interfaces. You can also specify a
particular cable interface on the CMTS, or the IP address or MAC address for a specific cable modem:

[ip-address
| interface
| mac-address
The MAC State column in the output of the show cable modem command displays the current status of each
cable modem. The following are the possible BPI-related values for this field:
Table 221: Possible show cable modem BPI+ States
State Description
online A cable modem has come online and, if configured to use BPI+, is negotiating its privacy
parameters for the session. If the modem remains in this state for more than a couple of minutes,
it is online but not using BPI+. Check that the cable modem is running DOCSIS-certified software
and is using a DOCSIS configuration file that enables BPI+.
online(pk) The cable modem is online and has negotiated a Key Encryption Key(KEK) with the CMTS. If
BPI+ negotiation is successful, this state will be shortly followed by online(pt).
online(pt) The cable modem is online and has negotiated a Traffic Encryption Key (TEK) with the CMTS.
The BPI+ session has been established, and the cable modem is encrypting all user traffic with
the CMTS using the specified privacy parameters.
1298
Displaying the BPI+ Timer Values on the CMTS
State Description
reject(pk) The cable modem failed to negotiate a KEK with the CMTS, typically because the cable modem
failed authentication. Check that the cable modem is properly configured for BPI+ and is using
valid digital certificates. If the CMTS requires BPI+ for registration, the cable modem will go
offline and have to reregister. Check that the cable modem is properly registered in the CMTS
provisioning system.
Note If a cable modem fails BPI+ authentication, a message similar to the following appears
in the CMTS log:
%CBR-5-UNAUTHSIDTIMEOUT: CMTS deleted BPI unauthorized Cable Modem 00c0.abcd.ef01
Note In cBR-8, if the CM status has a * (asterisk) as prefix, the router does not apply ACL
to block the Layer 3 traffic of the CM. While in Cisco uBR10000, the router will
apply ACL.
reject(pt) The cable modem failed to successfully negotiate a TEK with the CMTS. If the CMTS requires
BPI+ for registration, the cable modem will have to reregister.
Displaying the BPI+ Timer Values on the CMTS

To display the values for the KEK and TEK lifetime timers on a particular cable interface, use the show
interface cable x/y privacy [kek | tek] command.
Displaying the Certificate List on the CMTS

Use the show crypt ca certificates command to display the list of known certificates on the CMTS. For
example:
Router# show crypto ca certificates
Certificate
Status: Available
Certificate Serial Number: 7DBF85DDDD8358546BB1C67A16B3D832
Subject Name
Name: Cisco Systems
Validity Date:
start date: 00:00:00 UTC Sep 12 2001
end date: 23:59:59 UTC Sep 11 2021
Root certificate
Status: Available
Certificate Serial Number: 5853648728A44DC0335F0CDB33849C19
CN = DOCSIS Cable Modem Root Certificate Authority
OU = Cable Modems
O = Data Over Cable Service Interface Specifications
C = US
Validity Date:
start date: 00:00:00 UTC Feb 1 2001
end date: 23:59:59 UTC Jan 31 2031
1299
Configuration Examples for DOCSIS 1.1 Operations
Configuration Examples for DOCSIS 1.1 Operations

This section lists the following sample configurations for DOCSIS 1.1 operations on the Cisco CMTS:
Example: DOCSIS 1.1 Configuration for Cisco cBR-8 Router (with BPI+)
version 12.2
service timestamps log datetime msec localtime
service password-encryption
!
hostname cBR-8
!
redundancy
main-cpu
auto-sync standard
logging queue-limit 100
no logging buffered
no logging rate-limit
enable password my-enable-password
!
ipc cache 5000
card 1/1 2cable-tccplus
card 2/0 1gigethernet-1
card 2/1 2cable-tccplus
card 3/0 1gigethernet-1
card 4/0 1oc12pos-1
card 8/0 5cable-mc520s
card 8/1 5cable-mc520s
cable flap-list insertion-time 60
cable flap-list power-adjust threshold 4
cable flap-list aging 86400
cable modem vendor 00.50.F1 TI
cable spectrum-group 2 band 11000000 16000000
cable spectrum-group 32 shared
cable modulation-profile 21 request 0 16 0 22 qpsk scrambler 152 no-diff 32 fixed
cable modulation-profile 21 initial 5 34 0 48 qpsk scrambler 152 no-diff 64 fixed
cable modulation-profile 21 station 5 34 0 48 qpsk scrambler 152 no-diff 64 fixed
cable modulation-profile 21 short 3 76 12 22 qpsk scrambler 152 no-diff 64 shortened
cable modulation-profile 21 long 7 231 0 22 qpsk scrambler 152 no-diff 64 shortened
cable modulation-profile 22 short 4 76 7 22 16qam scrambler 152 no-diff 128 shortened
cable modulation-profile 22 long 7 231 0 22 16qam scrambler 152 no-diff 128 shortened
cable modulation-profile 23 short 4 76 7 22 16qam scrambler 152 no-diff 128 shortened
cable modulation-profile 23 long 7 231 0 22 16qam scrambler 152 no-diff 128 shortened
1300
cable qos profile 5 tos-overwrite 0x3 0x0

cable qos profile 5 name cm_no_priority
cable qos profile 6 name qos6
cable qos profile 8 name qos8
cable event syslog-server 10.10.10.131
ip subnet-zero
!
!
interface FastEthernet0/0/0
ip address 10.10.32.21 255.255.0.0
no cdp enable
!
interface GigabitEthernet2/0/0
ip address 10.10.31.2 255.0.0.0
no ip redirects
no ip unreachables
no ip proxy-arp
load-interval 30
negotiation auto
no cdp enable
!
interface GigabitEthernet3/0/0
no ip address
ip pim sparse-mode
no ip route-cache cef
load-interval 30
shutdown
negotiation auto
no cdp enable
!
interface POS4/0/0
no ip address
crc 32
no cdp enable
pos ais-shut
!
!
ip address 10.10.10.28 255.255.255.0
cable bundle 2 master
cable downstream rf-power 45
1301

cable upstream 0 data-backoff 0 6
no cable upstream 0 rate-limit
cable source-verify
cable privacy kek life-time 300
cable privacy tek life-time 180
no keepalive
!
ip address 10.10.11.121
cable bundle 2
cable upstream 0 modulation-profile 23 21
no cable upstream 0 rate-limit
1302

cable source-verify
cable privacy kek life-time 300
cable privacy tek life-time 180
no keepalive
!
!
ip classless
ip http server
no ip http secure-server
!
!
no cdp run
snmp-server community public RW
snmp-server community private RW
snmp-server enable traps cable
!
line con 0
exec-timeout 0 0
line aux 0
line vty 0 4
exec-timeout 0 0
password my-telnet-password
login
length 0
!
end
For additional information related to DOCSIS 1.1 operations, refer to the following references:
Description Link

1303
Feature Information for DOCSIS 1.1 for Cisco CMTS Routers
Feature Information for DOCSIS 1.1 for Cisco CMTS Routers

Table 222: Feature Information for DOCSIS 1.1 for the Cisco CMTS Routers
DOCSIS 1.1 for the Cisco Cisco IOS XE Everest This feature was integrated into Cisco IOS XE
CMTS Routers 16.6.1 Everest 16.6.1 on Cisco cBR Series Converged
Broadband Routers.
1304
CHAPTER 89
Default DOCSIS 1.0 ToS Overwrite
This document describes the Default DOCSIS 1.0 ToS Overwrite feature for the Cisco Cable Modem
Termination System (CMTS). This feature eliminates the need to create multiple QoS profiles in order to
perform type of service (ToS) overwrite by enabling a default ToS overwrite to be bound to all DOCSIS 1.0
Cable Modem (CM) created profiles.
Contents
• Restrictions for Default DOCSIS 1.0 ToS Overwrite, on page 1306
• Information About Default DOCSIS 1.0 ToS Overwrite, on page 1307
• How to Configure Default DOCSIS 1.0 ToS Overwrite, on page 1308
• Feature Information for Default DOCSIS 1.0 ToS Overwrite, on page 1310
1305
Restrictions for Default DOCSIS 1.0 ToS Overwrite
Digital PICs:

Module:

Modules:
line card reload.
Restrictions for Default DOCSIS 1.0 ToS Overwrite

• The Default DOCSIS 1.0 ToS Overwrite feature is only applicable to CMs running DOCSIS version 1.0.
1306
Information About Default DOCSIS 1.0 ToS Overwrite
• Once the Default DOCSIS 1.0 ToS Overwrite feature is configured, all CMs will need to be reset in order
for the effect to take place.
• Once the Default DOCSIS 1.0 ToS Overwrite feature is configured, all CMs will display the default
values that were configured. After which, overwrite values can only be changed by editing the QoS
profiles.
Information About Default DOCSIS 1.0 ToS Overwrite

To configure the Default DOCSIS 1.0 ToS Overwrite feature, you should understand the following topic:
Default DOCSIS 1.0 ToS Overwrite Overview

Currently, ToS overwrite requires the creation of static cable QoS profiles, which are assigned ToS fields and
are then associated with 1.0 CMs. This implementation works well if only a few different service types are
offered.
However, scalability issues arises when large numbers of service types are presented; each requiring a static
QoS profile in order to perform ToS overwrite.
The Default DOCSIS 1.0 ToS Overwrite feature eliminates the need to create multiple QoS profiles in order
to perform type-of-service (ToS) overwrite by automatically bounding all DOCSIS 1.0 Cable Modem (CM)
created profiles to a default ToS overwrite.
DOCSIS
Created by CableLabs, Data Over Cable Service Interface Specification (DOCSIS) defines the interface
standards and requirements for all cable modems associated with high-speed data distribution over a cable
television system network.
The DOCSIS architecture consists of the following two components:
• Cable Modem (CM)
• Cable Modem Termination System (CMTS)
Each of these components are situated at different locations, often with the CM located on a customer site
and the CMTS on the service provider site, and communication between the CM and CMTS is conducted
over cable through DOCSIS.
Note Though there are several versions of DOCSIS available, the Default DOCSIS 1.0 ToS Overwrite feature is
only applicable to CMs running DOCSIS 1.0.
Type-of-Service (ToS)
Tools such as type-of-service (ToS) bits identification make it possible to isolate network traffic by the type
of application being used. ToS capabilities can be further expanded to isolate network traffic down to the
specific brands, by the interface used, by the user type and individual user identification, or by the site address.
1307
How to Configure Default DOCSIS 1.0 ToS Overwrite
How to Configure Default DOCSIS 1.0 ToS Overwrite

The tasks in this section enables the use of the Default DOCSIS 1.0 ToS Overwrite feature.
Enabling Default DOCSIS 1.0 ToS Overwrite

All CMs with a DOCSIS 1.0 configuration file currently have their ToS overwrite default values are set to
tos-and: 0xff and tos-or: 0x00. Since there were previously no mechanism in the DOCSIS 1.0 configuration
file to specify the ToS overwrite, QoS profiles were created and assigned to the default ToS overwrites.
The following procedures enable the Default DOCSIS 1.0 ToS Overwrite feature, which will allow a default
ToS overwrite to be bound to all CM created profiles.
Before you begin

There are no prerequisites for these procedures.
Note • The Default DOCSIS 1.0 ToS Overwrite feature is only applicable to CMs running DOCSIS version 1.0.
• Once the Default DOCSIS 1.0 ToS Overwrite feature is configured, all CMs will need to be reset in order
for the effect to take place.
• Once the Default DOCSIS 1.0 ToS Overwrite feature is configured, all CMs will display the default
values that were configured. After which, overwrite values can only be changed by editing the QoS
profiles.
Procedure

Router> enable

Example:
Step 3 cable default-tos-qos10 tos-overwrite tos-and tos-or Configures the ToS overwrite default value for the CM.
This default value will be bound to all future CM created
Example:
profiles.
Router(config)# cable default-tos-qos10
tos-overwrite 0x1F 0xE0

EXEC mode.
Example:
1308
Editing QoS Profiles
What to do next
After configuring the ToS overwrite default value, reset the CM using the clear cable modem delete command
to allow the new ToS overwrite default value to take effect.
Editing QoS Profiles

Once the Default DOCSIS 1.0 ToS Overwrite feature is configured, additional ToS overwrite values can be
changed by editing the QoS profiles.
Procedure

Router> enable

Example:
Step 3 cable qos profile {groupnum | ip-precedence | Configures the QoS profile.
guaranteed-upstream | max-burst | max-upstream |
max-downstream | priority | tos-overwrite | value
Example:
Router(config)# cable qos profile 4

guaranteed-upstream 2

EXEC mode.
Example:
The following sections provide references related to the Default DOCSIS 1.0 ToS Overwrite feature.
1309
Feature Information for Default DOCSIS 1.0 ToS Overwrite
Description Link
The Cisco Technical Support & Documentation website http://www.cisco.com/cisco/web/support/index.html

contains thousands of pages of searchable technical
content, including links to products, technologies,
solutions, technical tips, tools, and technical
documentation. Registered Cisco.com users can log in
from this page to access even more content.
Feature Information for Default DOCSIS 1.0 ToS Overwrite

Table 224: Feature Information for Default DOCSIS 1.0 ToS Overwrite
Default DOCSIS 1.0 ToS Cisco IOS XE Everest This feature was integrated into Cisco IOS XE
overwrite 16.6.1 Everest 16.6.1 on the Cisco cBR Series
1310
CHAPTER 90
DOCSIS WFQ Scheduler on the Cisco CMTS
Routers
The DOCSIS WFQ Scheduler is an output packet scheduler that provides output scheduling services on both
WAN uplink interfaces and DOCSIS downstream interfaces.
Contents
• Prerequisites for DOCSIS WFQ Scheduler, on page 1312
• Restrictions for DOCSIS WFQ Scheduler, on page 1313
• Information About DOCSIS WFQ Scheduler, on page 1313
• How to Configure DOCSIS WFQ Scheduler , on page 1319
• Feature Information for DOCSIS WFQ Scheduler, on page 1320
1311
Prerequisites for DOCSIS WFQ Scheduler
Digital PICs:

Module:

Modules:
line card reload.
Prerequisites for DOCSIS WFQ Scheduler

No special equipment or softwareis needed to use the DOCSIS WFQ Scheduler feature.
1312
Restrictions for DOCSIS WFQ Scheduler
Restrictions for DOCSIS WFQ Scheduler

• The DBS feature is only applicable to DOCSIS 3.0 downstream channel bonding.
Information About DOCSIS WFQ Scheduler

The DOCSIS WFQ scheduling engine is used to provide output packet scheduling services, including absolute
priority queueing, weighted fair queueing, minimum rate guarantee, traffic shaping, and DOCSIS bonding
group dynamic bandwidth sharing on the Cisco cBR-8 converged broadband router.
The DOCSIS WFQ Scheduler provides services on both WAN uplink interfaces and DOCSIS downstream
interfaces. The scheduling parameters on WAN uplink interfaces are configured through the Modular QoS
CLI (MQC). On cable downstream interfaces, queues are created for DOCSIS service flows with parameters
configured by DOCSIS downstream QoS type, length, values (TLVs).
The default queue size for the DOCSIS service flows (with bandwidth greater than 150 Mbps) is based on
the bandwidth on the cable downstream interfaces (see Table below). Additionally, the queue limit for all
service flows can also be adjusted using the cable queue-limit command, buffer size in service class or
downstream buffer control TLVs.
Note The default queue size change, and the cable queue-limit command do not affect the DOCSIS high priority
queues.
Table below is an example of the queue size based on Annex B 256 QAM channels.
Table 226: Bandwidth, Queue Sizes, and Queue Limits
Channel Bandwidth (Mbps) Default Queue Queue Size

Size
1 ms 20 30 40 200
ms ms ms ms
1 37.5 63 63 63 92 123 617
2 75 255 63 123 185 247 1235
3 112.5 255 63 185 277 370 1852
4 150 255 63 247 370 494 2470
5 187.5 319 63 308 463 617 3087
6 225 383 63 370 555 741 3705
7 262.5 447 63 432 648 864 4323
8 300 511 63 494 741 988 4940
12 450 767 63 741 1111 1482 7411
1313
Queue Types
Channel Bandwidth (Mbps) Default Queue Queue Size

Size
1 ms 20 30 40 200
ms ms ms ms
14 525 895 63 864 1296 1729 8646
16 600 1023 63 988 1482 1976 9881
The DOCSIS WFQ Scheduler also allows significant enhancement to the queue scaling limits.
The following sections explain the DOCSIS WFQ Scheduler features:
Queue Types
The DOCSIS WFQ Scheduler feature supports the following types of queues:
• Priority queues
• CIR queues
• Best Effort queues
Priority Queues
Priority queues are serviced with absolute priority over all the other queues. On DOCSIS downstream interfaces,
the priority queues are configured by DOCSIS applications that request a priority service flow, for example,
a packet cable voice service flow. On WAN uplink interfaces, the priority queues are configured by the MQC
policy maps.
The following restrictions apply to priority queues:
• Only one priority queue is allowed per WAN uplink interface.
• Only one priority queue is allowed for low latency service flows created for each DOCSIS downstream
interface.
• All low latency flows on a DOCSIS downstream are aggregated to the single priority queue.
CIR Queues
A CIR queue is guaranteed to be serviced with at least the Committed Information Rate (CIR). CIR queues
are used to service DOCSIS service flows with non-zero minimum reserved rates. If the offered load to a CIR
queue exceeds its CIR value, the excess traffic is serviced as best effort traffic.
Best Effort Queues

The Best Effort (BE) queues share the interface bandwidth not used by the priority queue and the CIR queues.
The sharing is in proportion to each queue’s excess ratio.
The following conditions apply to BE queues:
• On DOCSIS downstream interfaces, BE queues are created by DOCSIS service flows that do not request
a minimum reserved rate.
• Each DOCSIS flow without a minimum reserved rate uses its own BE queue.
1314
DOCSIS QoS Support
DOCSIS QoS Support

DOCSIS defines a set of quality of service (QoS) parameters, including traffic priority, maximum sustained
traffic rate, minimum reserved traffic rate, maximum traffic burst, maximum downstream latency, and peak
traffic rate.
The downstream service flows use the QoS parameters to specify the desired QoS. The downstream policer
and scheduler provides services such as traffic shaping, bandwidth provisioning, traffic prioritization, and
bandwidth guarantee.
The DOCSIS service flow parameters are mapped to the packet queue parameters and provided with appropriate
QoS support for the packet queues to support the DOCSIS parameters
The following DOCSIS QoS parameters are supported:
• Traffic priority
• Maximum sustained traffic rate
• Minimum reserved traffic rate
Note The maximum traffic burst size and the peak traffic rate are supported as described in the http://www.cisco.com/
c/en/us/td/docs/cable/cbr/configuration/guide/b_cmts_quality_of_services/docsis_wfq_scheduler.html#con_
1085732.
Traffic Priority
The downstream channel bandwidth available to the best effort traffic, namely the channel bandwidth minus
the amount consumed by the priority traffic and the CIR traffic, is allocated to the best effort service flows
in proportion to their DOCSIS traffic priorities. For example, if there are three service flows sending packets
at a particular moment over the same downstream channel, and their DOCSIS traffic priorities are 0, 1 and
3, respectively, their share of the channel bandwidth will be 1:2:4. To achieve this bandwidth allocation, each
service flow is assigned a value known as its excess ratio which is derived from its DOCSIS priority. Table
below shows the default mappings of DOCSIS priority to excess ratio.
Note When traffic priority for a flow is not explicitly specified, a default priority value of 0 is used as per the
DOCSIS specification.
Table 227: DOCSIS Priority to Excess Ratio Mapping
DOCSIS Traffic Priority Excess Ratio
0 4
1 8
2 12
3 16
4 20
1315
Custom DOCSIS Priority to Excess Ratio Mappings
DOCSIS Traffic Priority Excess Ratio
5 24
6 28
7 32
Custom DOCSIS Priority to Excess Ratio Mappings

This option is introduced to configure custom priority to excess ratio mappings for downstream service flows
that override the default mappings listed in the above Table.
Note The configured values are used only for new service flows that are created after the configuration has been
applied. All the existing service flows maintain their previous excess ratio values.
The option to configure priority to excess ratio mappings is available on a per downstream forwarding interface
basis and is applicable to legacy cable, wideband and modular cable, and integrated cable interfaces.
The cable downstream qos wfq weights command is used to configure the mappings.
Maximum Sustained Traffic Rate

The maximum sustained traffic rate (MSR) specifies the peak information rate of a service flow. The MSR
of a service flow is mapped to the shape rate of the packet queue. When the maximum sustained traffic rate
is not specified or set to zero, its traffic rate becomes limited only by the physical channel capacity set by
DOCSIS specifications.
Note The Cisco cBR Cisco Packet Processor (CPP) forwarding processor supports a maximum ratio of 1,000:1
between the highest MaxSusRate or MinRsvRate and the lowest MaxSusRate or MinRsvRate. The scheduler
is impacted when the ratio exceeds the value. This limitation is per downstream forwarding interface
(Wideband-Cable, Integrated-Cable, and Downstream-Cable).
However, flows implemented by Low Latency Queuing (LLQ) are not be affected by this limitation.
Minimum Reserved Traffic Rate

The minimum reserved traffic rate (MRR) specifies the minimum rate reserved for a service flow. The MRR
of a service flow is mapped to the CIR of the packet queue, which ensures the minimum amount of bandwidth
a queue gets under congestion. When the MRR is not specified, the CIR is set to zero as per DOCSIS
specifications.
High Priority Traffic

High priority traffic flows are mapped to a Low Latency Queue (LLQ) on the data forwarding interface. The
packets in LLQ are serviced with absolute priority over other queues on the same interface.
The following service flows require high priority service:
1316
Enhanced Rate Bandwidth Allocation
• Service flows with DOCSIS downstream latency TLV set to a value above zero. For example, PacketCable
Multimedia Specification (PCMM) voice calls.
• PacketCable downstream service flows.
• Service flows with Unsolicited Grant Service (UGS) type—non-PacketCable voice calls—upstream
flows.
Enhanced Rate Bandwidth Allocation

The DOCSIS WFQ Scheduler supports the Enhanced Rate Bandwidth Allocation (ERBA) feature for service
flows. The ERBA feature allows cable modems (CMs) to burst their temporary transmission rates up to the
full line rate for short durations of time. This capability provides higher bandwidth for instantaneous bandwidth
requests without having to make changes to existing service levels in the QoS profile.
The DOCSIS WFQ Scheduler allows each service flow to have one dedicated queue. When ERBA is enabled
for the service flow, the peak rate is implemented as the queue shape rate within the scheduler, while the
maximum sustained rate is set as the token bucket refill rate. When ERBA is turned off, the burst size and the
peak rate value are not used.
The maximum traffic burst parameter is used to control a service flow burst duration, to burst up to the channel
line rate or a configured peak rate, when it is within its maximum burst size allowance. On the Cisco cBR-8
Converged Broadband Router, the cable ds-max-burst command is used to control this behavior explicitly.
Note The ERBA feature is not applicable for high priority service flows and multicast service flows.
Table below summarizes the ERBA support for the Cisco cBR-8 router.
Table 228: Enhanced Rate Bandwidth Allocation Support for the Cisco cBR-8 Router
Policer Rate Policer Exceed Policer Token Bucket Queue Shape Rate
Action Size
Traditional Maximum Sustained Transmit A value computed Maximum Sustained

Service Flow Traffic Rate (unused) internally by CMTS Traffic Rate
(unused)
ERBA-Enabled Maximum Sustained Drop Maximum Traffic Burst Peak Traffic Rate
Service Flow Traffic Rate TLV
For information about ERBA support on the Cisco CMTS routers, refer to Using Enhanced Bandwidth Rate
Allocation (ERBA) Support for DOCSIS 1.0 Cable Modems at the following location: DOCSIS 1.1 for the
Cisco CMTS Routers
Peak Traffic Rate

The peak-rate option of the cable ds-max-burst command allows you to specify the peak rate an ERBA-enabled
service flow can use. The peak-rate value is a global value and is applied to all service flows created after the
configuration of the cable ds-max-burst command. The default value of the peak-rate is zero.
If the DOCSIS 3.0 TLV 25.27 is specified for a service flow, the peak-rate value is set as the TLV value.
However, if ERBA is not turned on for a service flow, the peak-rate value is ignored.
1317
DOCSIS 3.0 Downstream Bonding Support with Bonding Group Dynamic Bandwidth Sharing
The peak-rate value can also be configured through cable service class command which forms part of the
service class template. During modem registration or Dynamic Service Addition (DSA) operation, the service
class name TLV 25.4 is sent to create the static or dynamic downstream service flow that matches the service
class template. These downstream service flows are created with a specific peak-rate . If the peak-rate is not
specified in he cable modem's configuration file, then the peak rate specified by the cable ds-max-burst
burst-threshold threshold peak-rate peak rate command is used.
Note The option to specify peak rate in the cable ds-max-burst command is not available on the Cisco cBR Series
Converged Broadband routers.
If a service flow has both service class and TLV 25.27 defined peak-rate , then the peak-rate value specified
in the TLV is used.
Some of the DOCSIS 1.x and DOCSIS 2.0 cable modems, which are not fully DOCSIS 1.x or DOCSIS 2.0
compliant, may fail to come online when they receive TLV 25.27 from the Cisco CMTS during registration.
In order to overcome this you can configure the cable service attribute withhold-TLVs command with the
peak-rate keyword to restrict sending of this TLV to non-DOCSIS 3.0 cable modems.
DOCSIS 3.0 Downstream Bonding Support with Bonding Group Dynamic

Bandwidth Sharing
DOCSIS 3.0 introduces the concept of downstream channel bonding. Each Bonding Group (BG) is made up
of a collection of downstream channels, which can be used by one or more bonding groups. Each downstream
channel can also serve as a primary channel in a MAC domain and carry non-bonded traffic, while being part
of a BG.
Prior to DOCSIS 3.0 standards, the downstream service flows were associated with a single downstream
interface, which in turn corresponded to a physical downstream on an RF channel. In DOCSIS 3.0, the
downstream service flows are associated with the downstream bonding groups. These bonding groups can
use multiple downstream RF channels.
DBS is the dynamic allocation of bandwidth for wideband (WB) and integrated cable (IC) interfaces sharing
the same downstream channel. Due to the channel sharing nature of the bonding groups, the bandwidth
available to bonding groups or non-bonded channels is not fixed. The bandwidth depends on the configuration
and the traffic load on the WB or IC.
Note Bonding groups are implemented as WB interfaces and non-bonded channels as IC interfaces.
In the DBS mode, the bandwidth of the shared RF channels is dynamically allocated among the WB and IC
interfaces. The DBS enables efficient use of the underlying RF channel bandwidth even in the presence of
high burst traffic. The DBS is configured at the WB or IC interface level. By default, bandwidth for a WB or
IC channel is statically allocated (non-DBS).
For information about DBS support on the Cisco CMTS routers, refer to the Dynamic Bandwidth Sharing on
the Cisco CMTS Router feature.
1318
How to Configure DOCSIS WFQ Scheduler
How to Configure DOCSIS WFQ Scheduler

You cannot configure the DOCSIS WFQ Scheduler feature as it is automatically loaded. The parameters that
the schedule uses include the interface bandwidth and queue parameters.
This section describes the following required and optional procedures:
Mapping DOCSIS Priority to Excess Ratio

This section describes how to map DOCSIS priorities to custom excess ratios for downstream service flows.
These custom mappings will override the default mappings.
Procedure

prompted.
Example:
Router> enable

Example:
Step 3 interface wideband-cable slot/subslot/port Enters interface configuration mode for the indicated cable
:wideband-channel or interface integrated-cable downstream interface.
slot/subslot/port :rf-channel
Example:

or
Step 4 cable downstream qos wfq weigthts {weight1...weight8} Configures the custom excess ratios for 8 priorities:
Example: Note The custom values are used only for new service
flows and not existing ones.
Router(config-if)# cable downstream qos wfq weights
10 20 30 40 50 60 70 80

EXEC mode.
Example:
1319
Verifying the Downstream Queues Information
Verifying the Downstream Queues Information

To verify the downstream queue information for a modem, use the show cable modem [mac-address |ip-address
]service-flow command.
To check queue stats of all queues on an Integrated-Cable or Wideband-Cable interface, use the show cable
dp queue interface command.
The following sections provide references related to the DOCSIS WFQ Scheduler feature.
Description Link
ID and password.
Feature Information for DOCSIS WFQ Scheduler

Table 229: Feature Information for DOCSIS WFQ Scheduler
DOCSIS WFQ scheduler Cisco IOS XE Everest This feature was integrated into Cisco IOS XE
16.6.1 Everest 16.6.1 on the Cisco cBR Series Converged
Broadband Routers.
1320
CHAPTER 91
Fairness Across DOCSIS Interfaces
The Fairness Across DOCSIS Interfaces feature introduces an adaptive mechanism to effectively distribute
reservable bandwidth for committed information rate (CIR) flows and fair bandwidth for best-effort (BE)
service flows across adjacent bonding groups (BGs).
Contents
• Prerequisites for Fairness Across DOCSIS Interfaces , on page 1323
• Restrictions for Fairness Across DOCSIS Interfaces, on page 1323
• Information About Fairness Across DOCSIS Interfaces, on page 1323
• How to Configure Fairness Across DOCSIS Interfaces, on page 1325
• Verifying the Fairness Across DOCSIS Interfaces, on page 1328
• Configuration Examples for Fairness Across DOCSIS Interfaces, on page 1331
• Feature Information for Fairness Across DOCSIS Interfaces, on page 1333
1321
Digital PICs:

Module:

Modules:
line card reload.
1322
Prerequisites for Fairness Across DOCSIS Interfaces
Prerequisites for Fairness Across DOCSIS Interfaces
Note The term ‘Bonding Group (BG)’ is used in this document to refer to all the integrated-cable (IC) and
wideband-cable (WC) interfaces in the context of Fairness Across DOCSIS Interfaces feature context. The
IC interfaces are considered as a single-channel BG.
Restrictions for Fairness Across DOCSIS Interfaces

• The CIR flows cannot reserve all the RF bandwidth. The CIR flows can only reserve 90 percent6 of the
RF bandwidth that is not statically reserved by the “bandwidth-percent”, in addition to the legacy CIR
bandwidth.
• It is recommended that the CIR reservation be cleared before disabling Fairness Across DOCSIS Interfaces
feature to ensure that the CIR reservation is not more than the static reservable bandwidth specified by
the “bandwidth-percent” in legacy configuration. This is to prevent CIR over-subscription after disabling
Fairness Across DOCSIS Interfaces feature.
• The effect of Fairness Across DOCSIS Interfaces feature depends on topology and flow distribution. In
certain cases, Fairness Across DOCSIS Interfaces feature may not achieve BE fairness or maximum CIR
utilization.
• Fairness Across DOCSIS Interfaces feature applies only to dynamic bandwidth sharing (DBS) enabled
IC and WB interfaces.
Information About Fairness Across DOCSIS Interfaces

The Fairness Across DOCSIS Interfaces feature is an enhancement over the DOCSIS WFQ scheduler. It
enables downstream CIR service flows to be admitted on the interfaces over the thresholds defined in the
legacy configuration (that is, “bandwidth-percent” or “max-reserved-bandwidth”). For example, the feature
enables large CIR flows (like multicast service flows) to be admitted when the current parameters cannot
guarantee enough bandwidth. However, its success rate depends on the allocation and reservation of the
bandwidth for cable interfaces within common RF channels.
This feature also ensures fair bandwidth for downstream BE service flows across cable interfaces with common
RF channels. The per-flow bandwidth of all active service flows on the adjacent BGs are balanced periodically.
The weights (DOCSIS traffic priority (traffic priority + 1)) of all the BGs are equal for downstream BE service
flows. The bandwidth, available for BE traffic, can be used to admit additional CIR flows.
Note For information about DOCSIS traffic priority, see DOCSIS WFQ Scheduler on the Cisco CMTS Routers
guide.
6
The reservable bandwidth for CIR flows consists of static and dynamic portions. By default, the static portion of bandwidth is assigned from the legacy
configuration. The dynamic portion of bandwidth comes from the headroom left on each RF channel for BE traffic.
1323
On-demand CIR Acquisition
On-demand CIR Acquisition

When multiple bonding groups sharing the RF-channel bandwidth and the current bonding group's guaranteed
bandwidth is insufficient, this feature can "borrow" neighbor bonding group's non-reserved guaranteed
bandwidth for current bonding group's CIR.
This feature is only used by multicast service flow.
Fairness Across Bonding Groups

Fairness Across DOCSIS Interfaces feature use the weight value of the aggregated active flow count, that is
EIR demand, to periodically re-balance the reservable bandwidth. So that the service flows with the same
weight in different bonding groups will have roughly the same throughput.
OFDM Channels
OFDM Channel
backward compatibility to DOCSIS 3.0. OFDM Channel support includes 1 OFDM channel per port with
channel bandwidth from 24 MHz to 192 MHz wide. In Cisco IOS-XE 16.5.1, a bonding group can consist of
SC-QAMs and OFDM channels. An OFDM channel can have multiple profiles configured, and each profile
may have different rate. The OFDM Channel rate can vary constantly depending on the profiles being used.
For more information on OFDM channels, see OFDM Channel Configuration Guide.
OFDM Channel Rate

An OFDM channel can have multiple profiles configured, and each profile can have different rates. For
example, with a 96MHz OFDM channel that is configured with profile A (Control Profile) with modulation
1024-QAM, profile B with modulation 2048-QAM, and profile C with modulation 4096-QAM, the profile
rates of profile A, B, and C are 616Mbps, 680Mbps, and 736Mbps respectively.
In Cisco IOS-XE 16.5.1, if an OFDM channel has both Control Profile (profile A) and Data Profiles (profile
B, C, and so on) configured, the lowest Data Profile rate is used for Fairness Across DOCSIS Interface
calculation. Otherwise, the Control Profile rate is used.
Interface Bandwidth
A Wideband-Cable (WB) interface can consist of both SC-QAMs and OFDM channels. If it contains OFDM
channels, the highest profile rates are used to calculate the interface bandwidth.
For example, with a 96MHz OFDM channel that is configured with profile A having modulation 1024-QAM,
profile B with modulation 2048-QAM, and profile C with modulation 4096-QAM, the profile rates of profile
A, B, and C are 616Mbps, 680Mbps, and 736Mbps respectively. Here, 736Mbps is used to calculate the
interface bandwidth.
1324
How to Configure Fairness Across DOCSIS Interfaces
How to Configure Fairness Across DOCSIS Interfaces

This section describes the following tasks that are required to implement Fairness Across DOCSIS Interfaces
feature:
Configuring Fairness Across DOCSIS Interfaces

This section describes how to enable Fairness Across DOCSIS Interfaces feature on the cable interfaces. The
configuration is applied to all WB or IC interfaces on the router.
Restriction We recommend that you clear the CIR reservation before disabling the Fairness Across DOCSIS Interfaces
feature to ensure that CIR reservation is not more than the static reservable bandwidth specified by the
“bandwidth-percent” in the legacy configuration.
Procedure

Router> enable

Example:
Step 3 cable acfe enable Enables Fairness Across DOCSIS Interfaces feature on the
cable interfaces.
Example:
Router(config)# cable acfe enable
Step 4 exit Exits global configuration mode and returns to privileged

EXEC mode.
Example:
Configuring Maximum Excess Information Rate Ratio

This section describes how to configure the maximum Excess Information Rate (EIR) ratio between the BE
bandwidth among adjacent BGs.
1325
Configuring Constant Excess Information Rate Demand
The EIR ratio is used to maintain the maximum EIR bandwidth difference between BGs. It helps to prevent
BGs (which has only a few active BE service flows) from getting very low or zero EIR bandwidth. Otherwise,
these BGs will not be able to admit CIR flows as they get only very low EIR bandwidth.
For example, there are two BGs sharing the same RF channel, with BG1 having 1000 active BE service flows
and BG2 having none. If “max-eir-ratio” is not used, BG1 gets all the bandwidth leaving no bandwidth for
BG2. When a voice CIR tries for bandwidth at BG2, it will get rejected. If “max-eir-ratio” is set at 10, BG2
gets about 10 percent of the QAM that is sufficient to admit the voice CIR. The ‘max-eir-ratio’ is a trade-off
between perfect fairness and CIR utilization. It means, compromising 'flow fairness' to prevent some BGs
from getting all the bandwidth leaving the other BGs with none.
Procedure

Router> enable

Example:
Step 3 cable acfe max-eir-ratio eir-ratio Configures the maximum EIR ratio between the BE
bandwidth among adjacent BGs.
Example:
Router(config)# cable acfe max-eir-ratio 20

EXEC mode.
Example:
Configuring Constant Excess Information Rate Demand

This section describes how to configure the constant excess information rate (EIR) demand for a bonding
group (BG). EIR demand is a unitless value that is used to determine relative bandwidth ratio between BGs.
An active EIR flow with DOCSIS priority-0 is given 1000 units of demand in ACFE module. Therefore a BG
with constant-eir-demand set to 1 will get no more than 1/1000 of the bandwidth of a single service flow.
SUMMARY STEPS
1. enable
3. cable acfe constant-eir-demand value
4. exit
1326
Configuring Maximum Bonus Bandwidth
DETAILED STEPS

Router> enable

Example:
Step 3 cable acfe constant-eir-demand value Configures the constant EIR demand as 20 for a BG.
Example:
Router(config)# cable acfe constant-eir-demand 20

EXEC mode.
Example:
Configuring Maximum Bonus Bandwidth

This section describes how to configure the maximum usable bonus bandwidth for a BG.
Bonus bandwidth is the additional bandwidth provided by the Fairness Across DOCSIS Interfaces feature to
each BG for CIR reservation. In the default maximum bonus bandwidth configuration, a single BG can reserve
all the underlying RF bandwidth. When the maximum bonus is set, the AC module will not admit CIR flows
above that setting even if the scheduler has guaranteed more bandwidth. This will effectively prevent BGs
from being starved for CIR flows.
Note The cable acfe max-bonus-bandwidth command configuration is applicable only for the new incoming CIR
flows. It will not terminate the existing CIR flows that exceeds the max-bonus-bandwidth .
Restriction If the maximum bonus bandwidth is less than the current CIR reservation on an interface, no new CIR flows
are admitted until the CIR reservation drops below the maximum bonus bandwidth configuration.
Procedure

1327
Verifying the Fairness Across DOCSIS Interfaces

Router> enable

Example:
Step 3 interface {wideband-cable | interface-cable }slot/subslot Specifies the interface to be configured.

/port :interface-num
Note The valid values for the arguments depend on
Example: CMTS router and cable interface line card. See
the hardware documentation for your router
Router(config)# interface wideband-cable 1/0/0:0 chassis and cable interface line card for
supported values.
Step 4 cable acfe max-bonus-bandwidth bonus-bandwidth Configures the maximum usable bonus bandwidth for a
BG.
Example:
Router(config-if)# cable acfe max-bonus-bandwidth

1000000

EXEC mode.
Example:
Router(config)# end
Verifying the Fairness Across DOCSIS Interfaces

To monitor the Fairness Across DOCSIS Interfaces feature, use the following procedures:
Verifying Reservable Bandwidth

To display the reserved and reservable bandwidth for a particular interface, use the show interface
{wideband-cable | modular-cable | integrated-cable} command as shown in the example:
Router# show interfaces wideband-cable 1/0/0:1 downstream

Total downstream bandwidth 1875 Kbps
Total downstream reserved/reservable bandwidth 20000/1500 Kbps
Total downstream guaranteed/non-guaranteed bonus bandwidth 20760/9741 Kbps
Router#
The “reservable bandwidth” is a part of the guaranteed bandwidth from the legacy configuration. When the
Fairness Across DOCSIS Interfaces feature is disabled, values of both the “guaranteed bonus bandwidth” and
“non-guaranteed bonus bandwidth” is zero. When the feature is enabled, the “reservable bandwidth” and
“guaranteed bonus bandwidth” represents the maximum CIR that can be reserved on the interface. Unicast
CIR flows exceeding this limit are rejected. The additional “non-guaranteed bonus bandwidth” allows the
1328
Verifying Reservable Bandwidth
multicast CIR flows to pass the AC module. However, the service flow may not be created successful because
the bandwidth comes from the shared pool.
To display the reserved and reservable bandwidth for a particular interface, use the show cable
admission-control interface command as shown in the example:
Router#show cable admission-control interface wideband-Cable 1/0/0:0
Interface Wi1/0/0:0
BGID: 28673
Resource - Downstream Bandwidth

-------------------------------
App-type Name Reservation/bps Exclusive
1 0 Not configured
2 0 Not configured
3 0 Not configured
4 0 Not configured
5 0 Not configured
6 0 Not configured
7 0 Not configured
8 20000000 Not configured
Max Reserved BW = 1500000 bps
Total Current Reservation = 20000000 bps
Guaranteed Bonus BW = 20760000 bps
Non-guaranteed Bonus BW = 9741000 bps
Subset BGs: In1/0/0:8 In1/0/0:9 In1/0/0:10 In1/0/0:11 In1/0/0:12
Superset BGs: N/A
Overlapping BGs: Wi1/0/0:8 Wi1/0/0:9 Wi1/0/0:10
Router#
Effective with Cisco IOS-XE Release 3.18.0SP, Capacity BW is also displayed. It is a summation of the
channel capacity of the RF channels in this interface, and the capacity of OFDM channels is calculated
considering the lowest profile rate.
Interface Wi2/0/0:1
BGID: 8194

-------------------------------
App-type Name Reservation/bps Maximum Rejected
1 4000 90% 0
2 0 N/A 0
3 0 90% 0
4 0 N/A 0
5 0 N/A 0
6 0 90% 0
7 0 N/A 0
8 0 87% 0
Capacity BW = 1428000000 bps
Subset BGs: In2/0/0:0 In2/0/0:1 In2/0/0:2 In2/0/0:3 In2/0/0:4 In2/0/0:5 In2/0/0:6 In2/0/0:7
In2/0/0:158 Wi2/0/0:0
Superset BGs: N/A
1329
Verifying Global Fairness Across DOCSIS Interfaces Status and Statistics
Verifying Global Fairness Across DOCSIS Interfaces Status and Statistics

To display the global status and statistics of the Fairness Across DOCSIS Interfaces feature, use the show
cable acfe summary command as shown in the example:
Router# show cable acfe summary

ACFE state: Enabled
EIR Rebalance period (secs): 5
EIR Rebalance invocations: 254
CIR Acquire rate/limit: 100/100
CIR Acquire invocations: 0
CIR Acquire throttled: 0
CIR Oversubscriptions: 0
Maximal EIR ratio: 10
Constant EIR demand: 2
Verifying Per-Controller Fairness Across DOCSIS Interfaces Status and

Statistics
To display the status and statistics for each controller interface, use the show cable acfe controller command
Router# show cable acfe controller integrated-Cable 1/0/0

EIR Rebalance invoked: 450963
Adaptive CIR granted: 20
Adaptive CIR rejected: 1
Total clusters: 9
RF FlexBW
8 36376
9 36376
10 32625
......
The BG clusters span across multiple channels and are used as a means to share the underlying RF channel
bandwidth dynamically.
Use the show controllers integrated-Cable acfe cluster command to show Per-controller statistics and
clusters and checking the bandwidth information as follows:
Router# show controllers integrated-Cable 1/0/0 acfe cluster 0

Integrated-Cable 1/0/0 status:
Topology changed: No
========Cluster 0========
Number of RF: 2
RF FlexBW WB ExcessBW Quanta
0 35625 - 35438 35438
0 187 187
1 35250 0 35250 35250
Number of BG: 2
Intf Demand CIR Max CstrMin Alloc NBonus Ratio
WB0 1000 0 70875 35250 35437 35438 14855190400
IC0 1000 0 35625 0 35438 187 14855609600
1330
Verifying Per-Interface Fairness Across DOCSIS Interfaces Status and Statistics
VerifyingPer-InterfaceFairnessAcrossDOCSISInterfacesStatusandStatistics
To display the status and statistics for each interface, use the show cable acfe interface command as shown
Router# show cable acfe interface wideband-cable 1/0/0:1

EIR Demand (raw/scale): 0/1
Per-Flow EIR BW (kbps): 19125
Guar Bonus BW (kbps): 19125
Non-guar Bonus BW (kbps): 38250
Reserved Bonus BW (kbps): 0
!
Configuration Examples for Fairness Across DOCSIS Interfaces

This section lists the following sample configurations for the Fairness Across DOCSIS Interfaces feature on
a Cisco CMTS router:
Example: Fairness Across DOCSIS Interfaces

The following sample configuration shows Fairness Across DOCSIS Interfaces feature enabled on the router:

!
! Last configuration change at 04:30:02 UTC Wed Jan 19 2
! NVRAM config last updated at 04:23:17 UTC Wed Jan 19 2
!
version 12.2
!
cable clock dti
cable acfe enable
!
.
.
.
Example: Maximum EIR Demand Ratio

The following sample configuration shows maximum EIR demand ratio configured on the router:
!
version 12.2
!
cable clock dti
cable acfe enable
cable acfe max-eir-ratio 20
!
The effect of the cable acfe max-eir-ratio command is demonstrated using a simple BG cluster.
!
interface integrated-Cable1/0/0:0
1331
Example: Constant EIR Demand
cable bundle 1
!
cable bundle 1
cable rf-channels channel-list 0
bandwidth-percent 1
end
!
On this RF channel, 20 percent of the bandwidth is reserved by the ‘bandwidth-percent’ allowing Fairness
Across DOCSIS Interfaces feature to use 27 Mbps, that is: (100 - 20) * 90 * 37.5). If the ‘max-eir-ratio’ is
above 100 and the WB interface has 99 active BE flows and the IC interface has only 1 BE flow, then IC
interface gets only 270 kbps, that is 1/(1+99)*27 of the bonus bandwidth. The BE traffic enjoys perfect fairness
here. However, it is not possible to admit a unicast CIR flow beyond 270 kbps on the IC interface, as it would
exceed the bonus bandwidth. If the ‘max-eir-ratio’ is set to 10, then the IC interface is treated to have 99/10
flows on it, resulting in a higher bonus bandwidth allocation. The ‘max-eir-ratio’ is a trade-off between perfect
fairness and CIR utilization.
Example: Constant EIR Demand

The following sample configuration shows constant EIR demand on the router:
!
version 12.2
!
cable clock dti
cable acfe enable
cable acfe max-eir-ratio 20
cable acfe constant-eir-demand 2
!
!
interface integrated-Cable1/0/0:0
cable bundle 1
!
cable bundle 1
cable rf-channels channel-list 0
bandwidth-percent 1
end
!
Example: Maximum Bonus Bandwidth

The following sample configuration shows the maximum bonus bandwidth enabled on the router:
!
cable bundle 1
1332

cable acfe max-bonus-bandwidth 10000
end
!
In this per-interface configuration, even if the Fairness Across DOCSIS Interfaces feature guarantees more
than 10 Mbps for a WB interface, the AC module will not pass more than 10 Mbps bandwidth above the
legacy reservable bandwidth.
!
.
.
.
Description Link
ID and password.
Feature Information for Fairness Across DOCSIS Interfaces

1333
Feature Information for Fairness Across DOCSIS Interfaces
Fairness across DOCSIS interfaces Cisco IOS XE Everest 16.6.1 This feature was integrated into
Broadband Routers.
1334
CHAPTER 92
Service Group Admission Control
This document describes the Service Group Admission Control feature.
• Restrictions for Service Group Admission Control, on page 1336
• Information About Service Group Admission Control, on page 1337
• How to Configure, Monitor, and Troubleshoot Service Group Admission Control, on page 1339
• Configuration Examples for SGAC, on page 1344
• Feature Information for Service Group Admission Control, on page 1348

Your software release may not support all the features documented in this module. For the latest caveats and
feature information, see Bug Search Tool and the release notes for your platform and software release. To
find information about the features documented in this module, and to see a list of the releases in which each
feature is supported, see the feature information table.
To access Cisco Feature Navigator, go to https://cfnng.cisco.com/. An account on Cisco.com is not required.
1335
Restrictions for Service Group Admission Control
Digital PICs:

Module:

Modules:
line card reload.
Restrictions for Service Group Admission Control

• To configure SGAC, the Fairness Across DOCSIS Interfaces feature must be enabled.
1336
Information About Service Group Admission Control
• SGAC supports downstream only.
Information About Service Group Admission Control

Overview
Service Group Admission Control (SGAC) is a mechanism that gracefully manages service group based
admission requests when one or more resources are not available to process and support the incoming service
request. Lack of such a mechanism not only causes the new request to fail with unexpected behavior but could
potentially cause the flows that are in progress to have quality related problems. SGAC monitors such resources
constantly, and accepts or denies requests based on resource availability.
SGAC enables you to provide a reasonable guarantee about the Quality of Service (QoS) to subscribers at the
time of call admission, and to enable graceful degradation of services when resource consumption approaches
critical levels. SGAC reduces the impact of unpredictable traffic demands in circumstances that would otherwise
produce degraded QoS for subscribers.
Note SGAC begins graceful degradation of service when either a critical threshold is crossed, or when bandwidth
is nearly consumed on the Cisco CMTS, depending on the resource being monitored.
SGAC enables you to configure thresholds for each resource on the Cisco CMTS. These thresholds are
expressed in a percentage of maximum allowable resource utilization. Alarm traps may be sent each time a
threshold is crossed for a given resource.
For downstream (DS) channels, you can configure the bandwidth allocation with thresholds for each fiber
node.
SGAC and Downstream Bandwidth Utilization

SGAC allows you to control the bandwidth usage for various DOCSIS traffic types or application types. The
application types are defined by the user using a CLI to categorize the service flow.
Categorization of Service Flows

The SGAC feature allows you to allocate the bandwidth based on the application types. Flow categorization
allows you to partition bandwidth in up to eight application types or buckets. The composition of a bucket is
defined by the command-line interface (CLI), as is the definition of rules to categorize service flows into one
of these eight application buckets. Various attributes of the service flow may be used to define the rules.
For flows created by PacketCable, the following attributes may be used:
• The priority of the Packetcable gate associated with the flow (high or normal)
For flows created by PacketCable MultiMedia (PCMM), the following attributes may be used:
• Priority of the gate (0 to 7)
• Application type (0 to 65535)
All flows use the following attribute type:
1337
Thresholds for Downstream Bandwidth
• Service class name

Before a service flow is admitted, it is passed through the categorization routine. Various attributes of the
service flow are compared with the user-configured rules. Based on the match, the service flow is labeled
with application type, from 1 to 8. The bandwidth allocation is then performed per application type.
Before a service flow is admitted, it is categorized based on its attributes. The flow attributes are compared
against CLI-configured rules, one bucket at a time. If a match is found for any one of the rules, the service
flow is labeled for that bucket, and no further check is performed.
Bucket 1 rules are scanned first and bucket 8 rules are scanned last. If two different rules match two different
buckets for the same service flow, the flow gets categorized under the first match. If no match is found, the
flow is categorized as Best Effort (BE) and the bucket with best effort rule is labelled to the flow. By default,
the BE bucket is bucket 8.
Thresholds for Downstream Bandwidth

SGAC monitors downstream bandwidth consumption using the configured maximum reserved bandwidth. It
rejects service flows with a non-zero minimal rate that would make the total reserved bandwidth exceed the
configured threshold.
Flexible Bandwidth Allocation

To address the issue of restricted bandwidth allocation for different application types, admission control can
be applied for both normal priority and emergency voice flows. This is done by extending the threshold and
assigning a group of application types in a fiber node. Each downstream service flow continues to be categorized
for a single application type. However, the one-to-one mapping between an application type and a threshold
no longer exists.
Each configured threshold and its associated group of application types can thus be treated as a constraint. A
service flow categorized to a certain application type must pass all the constraints associated with that
application type.
Overview of Bonding Group Admission Control

DOCSIS 3.0 introduced bonded channels or bonding groups that allow a single cable modem to send data
over multiple RF channels achieving higher throughput. These bonding groups are defined for both upstream
and downstream channels. Bonding groups are created by combining multiple RF channels. A single RF
channel may also be shared by multiple bonding groups.
Note Effective from Cisco IOS-XE 3.18.0SP Release, as per DOCSIS 3.1, if bonding group contains an OFDM
channel, the bonding group's total bandwidth that can be reserved (its capacity), is calculated using the least
efficient OFDM profile it can use.
Bonding group SGAC functionality allows to define the maximum reserved bandwidth for an application-type
as a fraction of the available bandwidth. This fraction of the bandwidth is defined as a percentage value of
the total bandwidth that can be reserved.
1338
How to Configure, Monitor, and Troubleshoot Service Group Admission Control
How to Configure, Monitor, and Troubleshoot Service Group

Admission Control
Configuration procedures are optional because the default configurations are enabled by default. This section
presents a sequence of procedures for non-default configurations, monitoring and debugging procedures for
both the default or non-default operations of SGAC.
Defining Rules for Service Flow Categorization

This procedure describes how to configure service flow categorization rules on the Cisco CMTS. This flexible
procedure changes default global service flow rules with variations of the cable application type include
command.
Any one or several of these steps or commands may be used, in nearly any combination, to set or re-configure
SGAC on the Cisco CMTS.
Note Application rules for SGAC are global configurations, and downstream bandwidth resources use the same
sets of service flow rules.
Procedure

Router> enable

Example:
Step 3 cable application-type n include packetcable { normal For PacketCable, this command variation maps PacketCable
| priority } service flow attributes to the specified bucket. PacketCable
service flows are associated with PacketCable gates. The
Example:
gate can be normal or high-priority.
Router(config)# cable application-type 5 include
packetcable priority
Step 4 cable application-type n include pcmm {priority For PCMM, this command variation maps PCMM service
gate-priority / app-id gate-app-id } flow priority or application to the specified bucket. The
PCMM gates are characterized by a priority level and by
Example:
an application identifier.
pcmm priority 7
1339
Defining Rules for Service Flow Categorization

pcmm app-id 152
Step 5 cable application-type n include service-class For service class parameters, this command variation applies
service-class-name a service class name to the service flows, and applies
corresponding QoS parameters.
Example:
DOCSIS 1.1 introduced the concept of service classes. A
Router(config)# cable application-type 1 include service class is identified by a service class name. A service
service-class stream1 class name is a string that the Cisco CMTS associates with
a QoS parameter set One of the objectives of using a service
class is to allow the high level protocols to create service
flows with the desired QoS parameter set. Using a service
class is a convenient way to bind the application with the
service flows. The rules provide a mechanism to implement
such binding.
Note the following factors when using the command in this
step:
• Service classes are separately configured using the
cable service class command to define the service
flow.
• A named service class may be classified into any
application type.
• Up to ten service class names may be configured per
application types. Attempting to configure more than
ten service classes prints an error message.
• Use the no cable traffic-type command to remove
the configuration of a service class before adding a
new class.
Step 6 cable application-type n include BE For Best Effort service flows, this command variation
elaborates on Step 3, and changes the default bucket of 8
Example:
for Best Effort service flows with non-zero Committed
Information Rate (CIR). These BE service flows are often
Router# cable application-type 3 include BE
created during cable modem registration.
Step 7 Ctrl-Z Returns to Privileged EXEC mode.

Example:
Example
The following example maps high-priority PacketCable service flows into application bucket 5.
Router(config)# cable application-type 5 include packetcable priority
The following example maps normal PacketCable service flows into application bucket 1.
1340
Naming Application Buckets
Router(config)# cable application-type 1 include packetcable normal
The following example maps the specified bucket number with PCMM service flow with a priority
of 7, then maps an application identifier of 152 for the same bucket number:
Router(config)# cable application-type 2 include pcmm priority 7

Router(config)# cable application-type 2 include pcmm app-id 152
The following example maps the Best Effort CIR flows to bucket 3:
Router(config)# cable application-type 3 include BE
Naming Application Buckets

This procedure enables you to assign alpha-numeric names to six of the eight application buckets that SGAC
supports. The default bucket identifiers range from 1 to 8.
Procedure

Router> enable

Example:
Step 3 cable application-type nname bucket-name Assigns an alpha-numeric name for the specified bucket.
Example: Note This bucket name appears in supporting show
and debug commands along with the default
Router(config)# cable application-type 7 name bucket number.
besteffort

Example:
Preempting High-Priority Emergency 911 Calls

You may configure SGAC rules and thresholds so that the high-priority voice (911) traffic receives an exclusive
share of bandwidth. Because the average call volume for Emergency 911 traffic may not be very high, the
fraction of bandwidth reserved for Emergency 911 calls may be small. In the case of regional emergency, the
1341
Preempting High-Priority Emergency 911 Calls
call volume of Emergency 911 calls may surge. In this case, it may be necessary to preempt some of the
normal voice traffic to make room for surging Emergency 911 calls.
The Cisco CMTS software preempts one or more normal-priority voice flows to make room for the high-priority
voice flows. SGAC provides the command-line interface (CLI) to enable or disable this preemption ability.
SGAC preemption logic follows the following steps:
1. When the first pass of admission control fails to admit a high priority PacketCable flow, it checks if it is
possible to admit the flow in another bucket configured for normal PacketCable calls (applicable only if
the PacketCable normal and high-priority rules are configured for different buckets). If the bandwidth is
available, the call is admitted in the normal priority bucket.
2. If there is no room in normal priority bucket, it preempts a normal priority PacketCable flow and admits
the high priority flow in the bucket where the low priority flow was preempted.
3. If there is no normal priority flow that it can preempt, it rejects the admission for high-priority flow. This
usually happens when both normal and high-priority buckets are filled with 911 flows.
This preemption is effective only for PacketCable high-priority flows.
When a downstream low-priority service flow is chosen for preemption, the corresponding service flow for
the same voice call in the opposite direction gets preempted as well.
Procedure

Router> enable

Example:
Step 3 [ no ] cable admission-control preempt priority-voice Changes the default Emergency 911 call preemption
functions on the Cisco CMTS, supporting throughput and
Example:
bandwidth requirements for Emergency 911 calls above all
other buckets on the Cisco CMTS.
Router(config)# no cable admission-control preempt
priority-voice The no form of this command disables this preemption, and
returns the bucket that supports Emergency 911 calls to
default configuration and normal function on the Cisco
CMTS.

Example:
Router#
1342
Calculating Bandwidth Utilization
Calculating Bandwidth Utilization

The SGAC feature maintains a counter for every US and DS channel, and this counter stores the current
bandwidth reservation. Whenever a service request is made to create a new service flow, SGAC estimates the
bandwidth needed for the new flow, and adds it to the counter. The estimated bandwidth is computed as
follows:
• For DS service flows, the required bandwidth is the minimum reservation rate, as specified in the DOCSIS
service flow QoS parameters.
In each of the above calculations, SGAC does not account for the PHY overhead. DOCSIS overhead is counted
only in the UGS and UGS-AD flows. To estimate the fraction of bandwidth available, the calculation must
account for the PHY and DOCSIS overhead, and also the overhead incurred to schedule DOCSIS maintenance
messages. SGAC applies a correction factor of 80% to the raw data rate to calculate the total available
bandwidth.
Note For the DS and US flow in bonded channels, the maximum reserved bandwidth is the bandwidth defined for
the SGAC threshold values. This value is indicated in kbps.
Enabling SGAC Check

A fiber node configured on the CMTS represents one or more matching physical fiber nodes in the HFC plant.
The CMTS uses the fiber node configuration to identify the DOCSIS downstream service group (DS-SG) and
DOCSIS upstream Service Group (US-SG) of the physical fiber nodes in the plant. The Service Group
information is compared with MAC Domain channel configuration to automatically calculate the MAC Domain
downstream and upstream service groups (MD-DS-SGs and MD-US-SGs respectively) within the MAC
Domains.
Under each Fiber node, use the following procedure to enable SGAC check for an application type and any
service flow of the specified application type, which is admitted to a service group.
Before you begin

Fairness Across DOCSIS Interfaces feature should always be enabled and the bandwidth percentage configured
on each bonding group should be kept minimal to allow flexible adjustment of reservable bandwidth.
Restrictions
SGAC is supported only on the downstream.
SUMMARY STEPS
1. enable
2. configureterminal
3. cable fiber-node id
4. admission-control application-type n ds-bandwidth pct
5. Ctrl-Z
1343
Configuration Examples for SGAC
DETAILED STEPS

Router> enable

Example:
Step 3 cable fiber-node id Enters cable fiber-node configuration mode to configure a

fiber node.
Example:
Router(config)# cable fiber-node 1
Step 4 admission-control application-type n ds-bandwidth pct Enables SGAC checking for the specified application-type.
Example: Use the no form of this command to disable SGAC
Router(config-fiber-node)# admission-control checking.
application-type 1 ds-bandwidth 1

Example:
Router(config-if)# Ctrl^Z
What to do next
Use the show cable admission-control fiber-node n command to verify admission-control configuration.
Configuration Examples for SGAC

This section describes solutions-level examples of the SGAC feature on the Cisco CMTS. This section
illustrates the functioning of SGAC in default or non-default operational configurations.
Example: SGAC Configuration Commands

In this section of configuration examples, the following SGAC parameters are set on the Cisco CMTS:
• All the packetcable flows are mapped into bucket 1.
• The BE service flows are mapped into bucket 8.
The following configuration commands enable these settings:
• To map the packetcable voice flows, use:
cable application-type 1 include packetcable normal
1344
Example: SGAC Configuration Commands
cable application-type 1 include packetcable priority

cable application-type 1 name PktCable
• To map the BE flows into bucket 8, use:
cable application-type 8 name HSD

cable application-type 8 include best-effort
• Given the above configurations, you may also control bandwidth allocation to a PCMM streaming video
application. The streaming video application is identified by the PCMM application ID 35. The following
commands implement this configuration:
cable application-type 2 name PCMM-Vid

cable application-type 2 include pcmm app-id 35
• These configurations may be verified on the Cisco CMTS using the following show commands:
Router# show cable application-type

For bucket 1, Name PktCable
Packetcable normal priority gates
Packetcable high priority gates
For bucket 2, Name PCMM-Vid
PCMM gate app-id = 30
For bucket 3, Name Gaming
PCMM gate app-id = 40
For bucket 4, Name
For bucket 5, Name
For bucket 6, Name
For bucket 7, Name
For bucket 8, Name HSD
Best-effort (CIR) flows
Router# show cable admission-control fiber-node 1

App-type Name Exclusive
1 N/A
2 N/A
3 Normal 10%
4 N/A
5 N/A
6 N/A
7 Emergency N/A
8 N/A
Router#show cable admission-control interface integrated-Cable 8/0/0:0
Interface In8/0/0:0
RFID 24576

-------------------------------
App-type Name Reservation/bps Exclusive Rejected
1 0 N/A 0
2 0 N/A 0
3 Normal 0 10% 0
4 0 N/A 0
5 0 N/A 0
6 0 N/A 0
7 Emergency 0 N/A 0
8 0 N/A 0
1345
Example: SGAC for Downstream Traffic

Superset BGs: Wi8/0/0:0 Wi8/0/0:4 Wi8/0/0:6
Interface Wi8/0/0:0
BGID: 24577

-------------------------------
App-type Name Reservation/bps Exclusive Rejected
1 0 N/A 0
2 0 N/A 0
3 Normal 0 10% 0
4 0 N/A 0
5 0 N/A 0
6 0 N/A 0
7 Emergency 0 N/A 0
8 0 N/A 0
Subset BGs: In8/0/0:0 In8/0/0:1
Superset BGs: Wi8/0/0:4 Wi8/0/0:6
Overlapping BGs: N/A
These above configuration examples might be omitted or changed, but the remaining examples in this section
presume the above configurations.
Example: SGAC for Downstream Traffic

This example presumes that you have configured the rules according to the commands illustrated at the start
of this section.
• All the voice flows in bucket 1.
• All the CIR data flows are categorized in bucket 8.
The below example illustrates a sample configuration for SGAC with downstream traffic. In this example, if
voice traffic exceeds 30% bandwidth consumption, additional voice flows are denied.
• 30% downstream throughput is reserved exclusively for voice traffic.
The following command implements this configuration:
Router(config-fiber-node)#admission-control application-type 1 ds-bandwidth 30
The below example illustrates how flexible bandwidth allocation is configured. In this example, normal voice
traffic (application-type 1) is associated with two thresholds. Normal voice traffic alone can use up to 40%
of the service group's capacity, while normal and emergency voice traffic combined can use up to 50% of the
service group’s capacity. This means that emergency voice traffic can have at least 10% of the service group's
capacity, even if normal voice traffic has used up its share of 40%:
1346
Router(config-fiber-node)#admission-control application-type 1 ds-bandwidth 40

Router(config-fiber-node)#admission-control application-type 1-2 ds-bandwidth 50
where,
• 1 is normal voice application type
• 2 is emergency voice application type
The following topics provide references related to SGAC for the Cisco CMTS.
Related Documents
Cisco CMTS Cable Commands Cisco CMTS Cable Command Reference
Standards
Standard Title
CableLabs™ DOCSIS 1.1 http://www.cablelabs.com/cablemodem/

specifications
CableLabs™ PacketCable http://www.cablelabs.com/packetcable/

specifications
CableLabs™ PacketCable http://www.cablelabs.com/packetcable/specifications/multimedia.html

MultiMedia specifications
MIBs
MIB MIBs Link
MIBs To locate and download MIBs for selected platforms, use Cisco MIB Locator found at the following
URL:
1347
Feature Information for Service Group Admission Control
Description Link

Feature Information for Service Group Admission Control

Table 233: Feature Information for Service Group Admission Control
Service group admission Cisco IOS XE Everest This feature was integrated into Cisco IOS XE
control 16.6.1 Everest 16.6.1 on Cisco cBR Series Converged
Broadband Routers.
1348
CHAPTER 93
Subscriber Traffic Management
This document describes the Subscriber Traffic Management (STM) feature Version 1.3. STM feature supports
all DOCSIS-compliant cable modems.
The STM feature allows a service provider to configure a maximum bandwidth threshold over a fixed period
for a specific service class (or quality of service [QoS] profile)). The subscribers who exceed this configured
threshold can then be identified and allocated reduced QoS. STM works as a low-CPU alternative to
Network-Based Application Recognition (NBAR) and access control lists (ACLs). However, using STM does
not mean that NBAR and ACLs have to be turned off; STM can be applied along with NBAR and ACLs.
STM also works in conjunction with the Cisco Broadband Troubleshooter to support additional network
management and troubleshooting functions in the Cisco CMTS.
Important In this document, the phrase QoS profile is synonymously used to indicate a service class for a DOCSIS 1.1
cable modem. However, QoS profile applies only to DOCSIS 1.0 operations. In instances where QoS profile
is mentioned to indicate DOCSIS1.1 operations, the QoS profile should be treated as a service class.
• Restrictions for Subscriber Traffic Management on the Cisco CMTS Routers, on page 1351
• Information About Subscriber Traffic Management on the Cisco CMTS Routers, on page 1352
• How to Configure the Subscriber Traffic Management Feature on the Cisco CMTS Routers, on page 1357
• Monitoring the Subscriber Traffic Management Feature on the Cisco CMTS Routers, on page 1367
• Configuration Examples for Subscriber Traffic Management on the Cisco CMTS Routers, on page 1370
• Feature Information for Subscriber Traffic Management, on page 1375
1349
Digital PICs:

Module:

Modules:
1350
Restrictions for Subscriber Traffic Management on the Cisco CMTS Routers
line card reload.
Restrictions for Subscriber Traffic Management on the Cisco

CMTS Routers
Note In this document, the phrase QoS profile is synonymously used to indicate a service class for a DOCSIS 1.1
cable modem. However, QoS profile applies only to DOCSIS 1.0 operations. In instances where QoS profile
is mentioned to indicate DOCSIS 1.1 operations, the QoS profile should be treated as a service class.
The STM feature has the following restrictions and limitations:

• In STM version 1.1, the sampling rate range (duration) is calculated using the monitoring duration rather
than the constant range (10 to 30 minutes) used in STM 1.0.
• If the monitoring duration is more than a day (1440 minutes), the duration sample rate is calculated
as (duration / 100).
• If the monitoring duration is less than a day, the sample rate range is from 10 to 30 minutes.
• If you are using STM 1.0 with a duration of two days and a sample rate of 20 minutes, and you try
to restore that configuration in STM 1.1, the command fails because now the valid range is from
28 to 86 minutes.
• For DOCSIS1.0, the registered QoS profile specified by an enforce-rule must match exactly a QoS profile
that exists on the Cisco CMTS. To manage a cable modem that is using a modem-created QoS profile,
you must first create that same exact QoS profile on the Cisco CMTS. All parameters in the QoS profile
must match before the cable modem can be managed by the enforce-rule.
• The Cisco cBR series routers support a certain maximum of 40 enforce-rules. If you have created the
maximum number of enforce-rules and want to create another rule, you must first delete one of the
existing rules.
• Changing the configuration of an enforce-rule automatically resets all byte counters for the subscribers
who are mapped to that enforce-rule.
• When specifying a QoS profile to be enforced when users violate their registered QoS profiles, both the
originally provisioned QoS profile and the enforced QoS profile must be created on the Cisco CMTS.
• The Subscriber Traffic Management feature calculates duration based on the time set on the router, not
uptime. Therefore, if you use the clock set command to change the time on the router, you might affect
the STM monitoring behavior.
1351
Information About Subscriber Traffic Management on the Cisco CMTS Routers
• The maximum cycle for subscriber traffic management is 31 days. If you choose a cycle of 31 days, the
minimum sample rate that you can set is (31 days/100) minutes.
Information About Subscriber Traffic Management on the Cisco

CMTS Routers
Feature Overview
The STM feature allows service providers to configure a maximum bandwidth threshold over a fixed period,
for a specific service class (or QoS profile). The subscribers who exceed this configured threshold can then
be identified and allocated a reduced QoS. This feature supplements current techniques such as NBAR and
ACLs, to ensure that a minority of users do not consume a majority of a cable network’s bandwidth.
Current subscriber controls, such as NBAR and ACLs, examine all packets coming into the CMTS. These
techniques can curb a large volume of problem traffic, but they are not as effective in dealing with the latest
generation of peer-to-peer file-sharing applications that can place heavy demands on a network’s available
bandwidth.
The STM feature allows service providers to focus on a minority of potential problem users without impacting
network performance or other users who are abiding by their service agreements.
The STM feature supports two types of monitoring:
• Legacy Monitoring—Legacy monitoring allows you to set up a single monitoring duration without the
ability to choose the time of day when that monitoring is performed. The configured monitoring parameters
remain constant throughout the day.
• Peak-Offpeak Monitoring—Peak-Offpeak monitoring allows you to specify up to two high-traffic periods
in a day for monitoring, in addition to the ability to continue monitoring during the remaining (or off-peak)
periods. By combining the peak time option with weekend monitoring, you can identify and limit the
bandwidth usage of certain subscribers for up to two peak network usage periods during weekdays, and
during a different set of peak usage periods on weekends.
When a cable modem goes offline and remains offline for 24 hours, the Cisco CMTS router deletes its service
flow IDs from its internal databases, and also deletes the modem’s traffic counters. This can allow some users
to exceed their bandwidth limits, go offline, and come back online with new counters. The Subscriber Traffic
Management feature helps to thwart these types of theft-of-service attacks by implementing a penalty period
for cable modems that violate their service level agreements (SLAs). Even if a cable modem goes offline, its
counters are still reset, and the CMTS continues to enforce the penalty period.
Feature List
The Subscriber Traffic Management feature has the following operational features:
• Subscriber Traffic Management 1.1 (STM 1.1) supports cable modems that have registered for DOCSIS
1.1 operations (using the service class/service flow ID [SFID] model).
• Up to 40 enforce-rules can be created on each router.
1352
Sliding Window for Monitoring Service Flows
• Separate enforce-rules can be used for downstream traffic and for upstream traffic. However, the limit
on the total number of enforce-rules that can be configured includes the upstream and downstream rules
combined.
• Each enforce-rule uses a subscriber’s registered QoS profile to identify which users should be monitored
for excessive traffic for DOCSIS1.0 cable modems. The registered QoS profile must exist on the Cisco
CMTS. If you want to manage cable modems that are using QoS profiles that were created by the cable
modem, you must first manually create a QoS profile with the exact same QoS parameters on the Cisco
CMTS, and then allow the cable modem to come online using the manually created profile.
• Each enforce-rule specifies the maximum number of kilobytes a user can transmit during a specified
window.
• Subscribers who exceed the maximum bandwidth that is specified by their enforce-rule can be
automatically switched to a separate enforced QoS profile that limits their network use for a customizable
penalty period. The enforced QoS profile can change the guaranteed bandwidth, priority, or any other
aspect of the traffic that the service provider considers an acceptable response to subscribers who violate
their service agreements.
• Subscribers are automatically switched back to their registered QoS profile at the end of their penalty
period. A technician at the service provider’s network operations center (NOC) can also switch them
back before the penalty period expires.
Note To manually switch back, delete the cable modem and allow it to register again.
• This feature also supports a no-persistence option, so that the enforced QoS profile does not remain in
effect when a cable modem reboots. This option is particularly useful when the feature is initially
implemented, so that the service providers can identify problem subscribers and applications, without
creating a major impact on the entire user base. When repeat offenders are found, they can then be
switched to an enforce-rule that does keep the enforced QoS profile in effect even when the cable modem
reboots.
• Service providers can display a list of all subscribers’ current usage statistics. Service providers can also
display a list of just those subscribers who are overconsuming bandwidth.
• The penalty period persists across reboots of the cable modem, so subscribers cannot avoid the enforced
QoS profile by resetting their modems and reregistering on the cable network. This allows service
providers to set an appropriate penalty for those users that consistently exceed the maximum bandwidth
they have been allocated. Service providers also can specify a time of day when CMs that are identified
for penalty can be released from the penalty period.
• If a user that is using excessive bandwidth decides to upgrade to a higher level of service, the service
provider can reconfigure the provisioning system to assign a new QoS profile to the cable modem. The
user can then reboot the cable modem and come online using the new level of service.
• Service providers can change subscriber service classes for a particular modem using the cable modem
service-class-name command.
• Different subscriber monitoring parameters can be configured for weekends, including peak and offpeak
monitoring windows. You can also establish the same monitoring windows for every day of the week,
or turn off monitoring altogether on the weekends as desired.
Sliding Window for Monitoring Service Flows

When an enforce-rule is activated, the CMTS periodically checks the bandwidth being used by subscribers
to determine whether any subscribers are consuming more bandwidth than that specified by their registered
1353
Weekend Monitoring
QoS profiles. The CMTS keeps track of the subscribers using a sliding window that begins at each sample-rate
interval and continues for the monitoring-duration period.
Each sample-rate interval begins a new sliding window period for which the CMTS keeps track of the total
bytes transmitted. At the end of each sliding window period, the CMTS examines the byte counters to determine
if any subscriber is currently overconsuming bandwidth on the network.
For example, with the default sample-rate interval of 15 minutes and the default monitoring-duration window
of 360 minutes (6 hours), the CMTS samples the bandwidth usage every 15 minutes and determines the total
bytes transmitted at the end of each 360-minute window. Therefore, every 15 minutes, the CMTS determines
each subscriber’s usage statistics for the preceding 6-hour period.
Figure below illustrates how this process works, with a new sliding window beginning at the beginning of
each sample-rate interval period.
Figure 34: Monitoring-Duration Windows
Weekend Monitoring
With standard legacy and peak-offpeak monitoring configuration, monitoring continues to occur on the
weekends.
STM version 1.2 supports configuration of different monitoring conditions on weekends. Weekend monitoring
options support the same parameters that are available in the existing monitoring options, but use a separate
set of commands to configure alternate monitoring on weekend days. This includes configuration of peak and
offpeak weekend monitoring windows.
In addition, the CLI supports the ability to turn off any monitoring on the weekend, or to use the same
monitoring conditions for every day of the week.
SNMP Trap Notifications

Simple Network Management Protocol (SNMP) trap notification can be sent whenever a subscriber violates
the enforce-rule. This trap is defined in the CISCO-CABLE-QOS-MONITOR-MIB and is enabled using the
snmp-server enable traps cable command.
1354
SNMP Trap Notifications
Each SNMP trap notification contains the following information:

• MAC address of the subscriber’s cable modem
• Name of the enforce-rule being applied to this subscriber
• Total bytes sent by the subscriber during the monitoring-duration window
• Time at which the subscriber’s penalty period expires
The CISCO-CABLE-QOS-MONITOR-MIB also contains the following tables that provide information about
the Subscriber Traffic Management configuration and about subscribers who violate their enforce-rules:
• ccqmCmtsEnforceRuleTable—Contains the attributes of the enforce-rules that are currently configured
on the Cisco CMTS.
• ccqmEnfRuleViolateTable—Provides a snapshot list of the subscribers who violated their enforce-rules
over the sliding monitoring-duration window.
The following objects are used for enforce rules:
• ccqmCmtsEnfRulePenaltyEndTime
• ccqmCmtsEnfRuleWkndOff
• ccqmCmtsEnfRuleWkndMonDuration
• ccqmCmtsEnfRuleWkndAvgRate
• ccqmCmtsEnfRuleWkndSampleRate
• ccqmCmtsEnfRuleWkndFirstPeakTime
• ccqmCmtsEnfRuleWkndFirstDuration
• ccqmCmtsEnfRuleWkndFirstAvgRate
• ccqmCmtsEnfRuleWkndSecondPeakTime
• ccqmCmtsEnfRuleWkndSecondDuration
• ccqmCmtsEnfRuleWkndSecondAvgRate
• ccqmCmtsEnfRuleWkndOffPeakDuration
• ccqmCmtsEnfRuleWkndOffPeakAvgRate
• ccqmCmtsEnfRuleWkndAutoEnforce
• ccqmCmtsEnfRuleFirstPeakTimeMin
• ccqmCmtsEnfRuleSecondPeakTimeMin
• ccqmCmtsEnfRuleWkndFirstPeakTimeMin
• ccqmCmtsEnfRuleWkndSecondPeakTimeMin
• ccqmCmtsEnfRulePenaltyEndTimeMin
• ccqmCmtsEnfRuleWkPenaltyPeriod
• ccqmCmtsEnfRuleWkndPenaltyPeriod
• ccqmCmtsEnfRuleRelTimeMonitorOn
The following objects are used for enforce rule violations:
• ccqmEnfRuleViolateID
• ccqmEnfRuleViolateMacAddr
• ccqmEnfRuleViolateRuleName
• ccqmEnfRuleViolateByteCount
• ccqmEnfRuleViolateLastDetectTime
• ccqmEnfRuleViolatePenaltyExpTime
1355
Cable Modem Interaction with the Subscriber Traffic Management Feature
• ccqmEnfRuleViolateAvgRate
Cable Modem Interaction with the Subscriber Traffic Management Feature

The Subscriber Traffic Management feature ensures that users cannot bypass the QoS restrictions by rebooting
their cable modems or performing other configuration changes. The service provider, however, continues to
be able to change the modems’ profiles and other configuration parameters as desired.
When the Subscriber Traffic Management feature is enabled, the following behavior is in effect:
• The primary service flow counters for downstream and upstream traffic are preserved when the cable
modem reboots. The service provider, however, can reset the counters by changing the QoS profile for
the cable modem using the cable modem qos profile command and resetting the cable modem.
• Secondary service flow counters are reset whenever the cable modem reboots. This happens regardless
of the enforce-rule configuration.
• The cable modem retains its current primary downstream and upstream service flows when it reboots.
If the cable modem is in an enforced QoS profile penalty period when it reboots, it continues using the
enforced QoS profile after the reboot. Service providers can manually change the profile by assigning a
new QoS profile using the cable modem qos profile command.
Note Changing the QoS profile for a cable modem using the cable modem qos profile command, also changes the
enforce-rule for the cable modem when it reboots. When the cable modem comes back online, it begins
operating under the enforce-rule whose registered QoS profile (see the qos-profile registered command)
matches the new QoS profile the modem is using.
• Service providers can also change the enforce-rule configuration. The following happens when the
provider changes the enforce-rule configuration:
• If the enforce-rule is disabled (using the no enabled command), all cable modems using that rule’s
registered QoS profile are no longer managed by the Subscriber Traffic Management feature.
Configuring no enabled, deactivates the enforce-rule and moves all the modems in penalty to its
registered QoS.
• If the registered QoS profile for the rule is changed (using the qos-profile registered command),
the cable modems that are using the previous registered QoS profile are no longer managed by the
Subscriber Traffic Management feature. Instead, any cable modems that use the new registered QoS
profile begin being managed by this rule.
• If the enforced QoS profile for the rule is changed (using the qos-profile enforced command), any
cable modems using this rule that are currently in the penalty period continue using the previously
configured enforced QoS profile. Any cable modems that enter the penalty period after this
configuration change, however, use the new enforced QoS profile.
• Service providers also have the option of making an enforce-rule nonpersistent, so that the enforced QoS
profile does not remain in force when a cable modem reboots. Instead, when the cable modem reboots
and reregisters with the Cisco CMTS, the CMTS assigns it the QoS profile that is specified in its DOCSIS
configuration file.
1356
How to Configure the Subscriber Traffic Management Feature on the Cisco CMTS Routers
How to Configure the Subscriber Traffic Management Feature

on the Cisco CMTS Routers
Creating and Configuring an Enforce-Rule

Every service class name that needs to be monitored will be linked with an enforce-rule. An enforce-rule
defines the monitoring duration, the sample rate, the penalty period, and the registered service class name that
the enforce-rule is linked to and the enforced service class name.
Use the procedure given below to create and configure an enforce-rule. An enforce-rule does not become
active until the enabled command is given.
Before you begin

• The registered and enforced service (QoS) profiles must be created on the CMTS before creating an
enforce-rule that uses those profiles. If you want to manage a cable modem that currently uses a
modem-created QoS profile, you must first manually create a new QoS profile on the CMTS with the
same QoS parameters as the modem-created profile. Then allow the modem to come online using the
manually created profile before beginning this procedure.
• To display quality of service (QoS) profiles for a Cisco CMTS, use the show cable qos profile
command in privileged EXEC mode.
• To configure a QoS profile, use the cable qos profile command in global configuration mode. To
set a particular value to its default, or to delete the profile when no specific parameters have been
set, use the no form of this command.
• For monitoring of DOCSIS 1.1 cable modems:
• Only DOCSIS 1.1 modems that register with a service class name are monitored.
• To ensure that the DOCSIS 1.1 service flow counters remain across a reboot of the CM, configure
the cable primary-sflow-qos11 keep all global configuration command.
• Only primary upstream and downstream service flows are supported.
Restriction • When configuring peak-offpeak monitoring, you can define a maximum of two peak durations within a
day, and also monitoring of the remaining hours, if you configure the offpeak duration. The monitoring
duration and threshold for first peak, second peak, and offpeak, can be different. However, the monitoring
duration for any peak or offpeak configuration cannot be more than a day.
• The parameters defined by the named service class should always be a compatible subset of the registered
set of parameters for the CM. Only certain options can be changed using a CMTS router service class,
such as the max-rate, priority, or tos-overwrite options. The max-burst option in both the enforced
and registered CMTS router service classes must strictly match the value for max-burst in the registered
DOCSIS configuration file. If the service class value does not match, either the cable modem registration
will fail with a reject-c state, or the enforced class will fail.
1357
Creating and Configuring an Enforce-Rule
Procedure

prompted.
Example:
Router> enable
Step 2 configure terminal Enters the global configuration mode.

Example:
Step 3 cable qos enforce-rule name Creates an enforce-rule with the specified name and enters
the enforce-rule configuration mode.
Example:
Note Each enforce-rule can be created by giving it a
Router(config)# cable qos enforce-rule test name.
Step 4 monitoring-basics{legacy | peak-offpeak} {docsis10 | Defines the kind of monitoring desired and the type of
docsis11} modems to be monitored.
Example: The default is legacy and DOCSIS 1.0.
Router(enforce-rule)# monitoring-basics
peak-offpeak docsis11
Step 5 Perform one of the following: • For DOCSIS 1.0 cable modems:
• If you specified DOCSIS 1.0 cable modems in Step 4, a. Specifies the registered quality of service (QoS)
on page 1358, use the following commands: profile that should be used for this enforce-rule.
a. qos-profile registered profile-id Note If you want to manage a cable modem
that currently uses a modem-created
b. qos-profile enforced profile-id [no-persistence] QoS profile, you must first manually
create a new QoS profile on the CMTS
• If you specified DOCSIS 1.1 cable modems in Step 4, with the same QoS parameters as the
on page 1358, use the service-class {enforced | modem-created profile. Then allow
registered} name command. the modem to come online using the
Example: manually created profile before using
this command.
Router(enforce-rule)# service-class enforced test
b. Specifies the quality of service (QoS) profile that
should be enforced when users violate their
registered QoS profiles for DOCSIS 1.0 cable
modems.
• For DOCSIS 1.1 (and later) cable modems, identifies

a particular service class with the specified name for
cable modem monitoring in an enforce-rule.
1358
Examples

Step 6 duration minutes avg-rate rate sample-interval Specifies the time period and sample rate used for
minutes[penalty minutes] {downstream | upstream} monitoring subscribers when legacy monitoring is
[enforce] configured (Step 4, on page 1358).
Example:
Router(enforce-rule)# duration 120 avg-rate 500

sample-interval 15 penalty 120 downstream enforce
Step 7 peak-time1 {hour | hour:minutes} duration minutes Specifies peak monitoring periods when peak-offpeak
avg-rate rate [peak-time2 {hour | hour:minutes} duration monitoring is configured (Step 4, on page 1358).
minutes avg-rate rate][duration offpeak-minutes avg-rate
offpeak-rate ] sample-interval minutes[penalty minutes]
{downstream | upstream}[enforce]
Example:
Router(enforce-rule)# peak-time1 6 duration 120

avg-rate 2 peak-time2 18 duration 120 avg-rate 2
duration 120 avg-rate 3 sample-interval 15
upstream enforce
Router(enforce-rule)# peak-time1 6:30 duration
120 avg-rate 2 peak-time2 18:40 duration 120
avg-rate 2 duration 120 avg-rate 3 sample-interval
15 penalty 120 upstream enforce
Step 8 penalty-period minutes [time-of-day (Optional) Specifies the period for which an enforced QoS
{hour|hour:minutes}] [monitoring-on] profile should be in effect for subscribers who violate their
registered QoS profiles.
Example:
Router(enforce-rule)# penalty-period 120
Step 9 enabled (Optional) Activates the enforce-rule and begins subscriber

traffic management.
Example:
Router(enforce-rule)# enabled
Step 10 end Exits enforce-rule configuration mode and returns to

Example:
Router(enforce-rule)# end
Examples
This section provides command-line interface (CLI) examples, including the help feature for some of the
enforce-rule commands.
Example: Legacy Monitoring Configuration

The following example shows a sample configuration of an enforce-rule for legacy monitoring:
1359
Example: Peak-offpeak Monitoring Configuration
Router(config)# cable qos enforce-rule test

Router(enforce-rule)# monitoring-basics ?
legacy Enable legacy (same average rate for all day) monitoring
peak-offpeak Enable peak-offpeak monitoring
Router(enforce-rule)# monitoring-basics legacy ?
docsis10 Enforce-rule will map to docsis 1.0 modems
docsis11 Enforce-rule will map to docsis 1.1 modems
Router(enforce-rule)# monitoring-basics legacy docsis11
Router(enforce-rule)# service-class ?
enforced Enforced service class
registered Registered service class
Router(enforce-rule)# service-class registered ?
WORD Registered service class name
Router(enforce-rule)# service-class registered BEUS
Router(enforce-rule)# service-class enforced test
Router(enforce-rule)# duration ?
<10-10080> Duration in minutes
Router(enforce-rule)# duration 120 ?
avg-rate Average rate for the duration in kbits/sec
Router(enforce-rule)# duration 120 avg-rate ?
<1-4294967> average rate in kbits/sec
Router(enforce-rule)# duration 120 avg-rate 2 ?
sample-interval Rate of sampling in Minutes
Router(enforce-rule)# duration 120 avg-rate 2 sample-interval ?
<1-30> Sampling rate in Minutes
Router(enforce-rule)# duration 120 avg-rate 2 sample-interval 15 ?
downstream downstream
upstream upstream
Router(enforce-rule)# duration 120 avg-rate 2 sample-interval 15 upstream ?
enforce enforce the qos-profile automatically
<cr>
Router(enforce-rule)# duration 120 avg-rate 2 sample-interval 15 upstream enf
Router(enforce-rule)# $ avg-rate 2 sample-interval 15 upstream enforce
Example: Peak-offpeak Monitoring Configuration

The following example shows a sample configuration of an enforce-rule for peak-offpeak monitoring:

Router(enforce-rule)# monitoring-basics peak-offpeak
Router(enforce-rule)# monitoring-basics peak-offpeak docsis10
Router(enforce-rule)# qos-profile ?
enforced Enforced qos profile
registered QoS profile index
Router(enforce-rule)# qos-profile registered ?
<1-255> Registered QoS profile index
Router(enforce-rule)# qos-profile registered 5
Router(enforce-rule)# qos-profile enforced 4
Router(enforce-rule)# peak-time1 6 ?
duration First peak duration
Router(enforce-rule)# peak-time1 6 duration ?
Router(enforce-rule)# peak-time1 6 duration 120 ?
avg-rate First peak average rate in kbits/sec
Router(enforce-rule)# peak-time1 6 duration 120 avg-rate ?
<1-4294967> Average rate in kbits/sec
Router(enforce-rule)# peak-time1 6 duration 120 avg-rate 2 ?
duration Off-peak duration
1360
Configuring Weekend Monitoring
peak-time2 Second peak time

sample-interval Rate of sampling in minutes
Router(enforce-rule)# peak-time1 6 duration 120 avg-rate 2 peak-time2 ?

<10-1440> Start of second peak time
Router(enforce-rule)# peak-time1 6 duration 120 avg-rate 2 peak-time2 18 ?
duration Second peak duration
Router(enforce-rule)# $6 duration 120 avg-rate 2 peak-time2 18 duration ?
Router(enforce-rule)# $6 duration 120 avg-rate 2 peak-time2 18 duration 120 ?
avg-rate Second peak average rate in kbits/sec
Router(enforce-rule)# $ 180 avg-rate 2 peak-time2 18 duration 120 avg-rate ?
<1-4294967> Average rate in kbits/sec
Router(enforce-rule)# $ 180 avg-rate 2 peak-time2 18 duration 120 avg-rate 3 ?
duration Off-peak duration
Router(enforce-rule)# $ 180 avg-rate 2 peak-time2 18 duration 120 avg-rate 3 d
Router(enforce-rule)# $-time2 18 duration 120 avg-rate 3 duration 120 ?
avg-rate Off-peak average rate in kbits/sec
Router(enforce-rule)# $duration 120 avg-rate 3 duration 120 avg-rate 1 ?

Router(enforce-rule)# $40 avg-rate 3 duration 120 avg-rate 1 sample-interval ?
<1-30> Sampling rate in Minutes
Router(enforce-rule)# $e 3 duration 120 avg-rate 1 sample-interval 15 ?
downstream downstream
upstream upstream
Router(enforce-rule)# $e 3 duration 120 avg-rate 1 sample-interval 15 upstream ?
enforce enforce the qos-profile automatically
<cr>
Router(enforce-rule)# $on 120 avg-rate 1 sample-interval 15 upstream enforce
Configuring Weekend Monitoring

This section describes the tasks required to configure weekend monitoring for STM on a Cisco CMTS router.
Prerequisites
You must first configure the weekday monitoring parameters for an enforce-rule before configuring weekend
monitoring. See the Creating and Configuring an Enforce-Rule, on page 1357.
Restrictions
• Up to 40 total enforce-rules across both upstream and downstream configurations are supported.
• When using SNMP for weekend monitoring, only SNMP GET and GETMANY operations are supported.
Configuring Different Legacy Monitoring Conditions for Weekends

Use the following procedure if you want to establish different legacy monitoring conditions for subscribers
for either upstream or downstream traffic on weekend days.
1361
Configuring Different Peak-Offpeak Monitoring Conditions for Weekends
Procedure

prompted.
Example:
Router> enable

Example:
Step 3 cable qos enforce-rule name Accesses the enforce-rule with the specified name and enters
enforce-rule configuration mode.
Example:
Step 4 weekend duration minutes avg-rate rate sample-interval Specifies the time period and sample rate used for
minutes {downstream | upstream} [penalty minutes] monitoring subscribers on weekends.
[enforce]
Example:
Router(enforce-rule)# weekend duration 120 avg-rate

500 sample-interval 15 penalty 120 downstream
enforce

Example:
Configuring Different Peak-Offpeak Monitoring Conditions for Weekends

Use the following procedure if you want to establish different peak and offpeak monitoring conditions for
subscribers for either upstream or downstream traffic on weekend days.
Procedure

prompted.
Example:
Router> enable

Example:
1362
Disabling Weekend Monitoring
Example:
Step 4 weekend peak-time1{hour | hour:minutes} duration Specifies peak and offpeak monitoring times on weekends.
minutes avg-rate rate [peak-time2 hour duration minutes
avg-rate rate] [duration offpeak-minutes avg-rate
offpeak-rate] sample-interval minutes[penalty minutes]
{downstream| upstream}[enforce]
Example:
Router(enforce-rule)# weekend peak-time1 9 duration

120 avg-rate 2 peak-time2 16 duration 120 avg-rate
2 duration 120 avg-rate 3 sample-interval 15
upstream enforce
Example:
Router(enforce-rule)# weekend peak-time1 9:30

duration 120 avg-rate 2 peak-time2 16:58 duration
180 avg-rate 2 duration 120 avg-rate 3
sample-interval 15 penalty 120 upstream enforce

Example:
Disabling Weekend Monitoring

Use the following procedure to turn off the weekend monitoring configuration and monitor on weekdays only.
Procedure

prompted.
Example:
Router> enable

Example:
1363
Removing Weekend Monitoring Conditions and Use the Same Monitoring Criteria Every Day

Step 3 cable qos enforce-rule name Accesses the enforce-rule with the specified name and
enters enforce-rule configuration mode.
Example:
Step 4 weekend off Disables monitoring on weekends.

Example:
Router(enforce-rule)# weekend off

Example:
Removing Weekend Monitoring Conditions and Use the Same Monitoring Criteria Every Day
Use the following procedure to remove the specified weekend monitoring conditions and use the same
monitoring criteria all week (including weekends).
Procedure

prompted.
Example:
Router> enable

Example:
Example:
Step 4 no weekend Performs monitoring on the weekends using the same

parameters for weekdays and weekends.
Example:
Router(enforce-rule)# no weekend

Example:
1364
Disabling an Enforce-Rule
Disabling an Enforce-Rule
Use the following procedure to disable an enforce-rule. The enforce-rule remains in the CMTS configuration
file, but any subscriber traffic management that uses this enforce-rule ends.
Procedure

prompted.
Example:
Router> enable

Example:
Step 3 cable qos enforce-rulename Creates an enforce-rule with the specified name and enters
Example:
Step 4 no enabled Disables the enforce-rule and ends subscriber traffic

management for users with the rule’s registered QoS profile.
Example:
It moves all modems in penalty to its registered QoS.
Router(enforce-rule)# no enabled

Example:
Removing an Enforce-Rule
Use the following procedure to delete an enforce-rule and remove it from the CMTS configuration file. Any
subscriber traffic management that uses this rule also ends.
1365
Changing a Cable Modem Service Class
Procedure

prompted.
Example:
Router> enable

Example:
Step 3 no cable qos enforce-rulename Deletes the enforce-rule with the specified name . This
enforce-rule and its configuration are removed from the
Example:
CMTS configuration, and any subscriber traffic management
that uses this rule ends.
Router(config)# no cable qos enforce-rule ef-rule

EXEC mode.
Example:
Router(config)# end
Changing a Cable Modem Service Class

Use the following procedure to change a QoS service class for a particular DOCSIS 1.1 cable modem.
Restriction • The command is supported only on DOCSIS 1.1 CM primary service flows.
• You can specify the cable modem service-class-name command only after the CM has been online for
at least 200 seconds.
• The parameters defined by the named service class should always be a compatible subset of the registered
set of parameters for the CM. Only certain options can be changed using a CMTS router service class,
such as the max-rate, priority, or tos-overwrite options. The max-burst option in both the enforced
and registered CMTS router service classes must strictly match the value for max-burst in the registered
DOCSIS configuration file. If the service class value does not match, then CM registration will fail with
a reject-c state, or the enforced class will fail.
Procedure

prompted.
Example:
Router> enable
1366
Monitoring the Subscriber Traffic Management Feature on the Cisco CMTS Routers

Step 2 cable modem {ip-address | mac-address} Changes a QoS service class for a particular cable modem.
service-class-name name
Example:
Router# cable modem aaaa.bbbb.cccc

service-class-name test
Step 3 end Exits privileged EXEC mode.

Example:
Router# end
Monitoring the Subscriber Traffic Management Feature on the

Cisco CMTS Routers
This section describes the following tasks that can be used to monitor the Subscriber Traffic Management
feature:
Displaying the Currently Defined Enforce-Rules

To display all enforce-rules that are currently defined on the Cisco CMTS router, or the definitions for a
particular enforce-rule, use the show cable qos enforce-rule command in privileged EXEC mode.
For offpeak monitoring, use the show cable qos enforce-rule command to display the monitoring duration
and average-rate values applicable for that time of day. If no monitoring is taking place, 0 is displayed.
The following example shows sample output from the show cable qos enforce-rule command for all configured
enforce-rules:
Router# show cable qos enforce-rule

Name Dur Dir byte-cnt Auto rate penalty Reg Enf Ena Persist
(min) (kbytes) enf (min) (min) QoS QoS
residential 10 us 5 act 1 10080 5 10 Yes Yes
ef-q11d 30 ds 150 act 1 20 11 99 Yes Yes
ef-q11u 30 us 60 act 1 20 11 99 Yes Yes
ef-q21 720 us 60 act 1 10 21 81 Yes Yes
ef-q22 720 us 60 act 1 10 22 82 Yes Yes
ef-q22d 300 ds 150 act 1 10 22 82 Yes No
ef-q23 720 us 60 act 1 10 23 83 Yes Yes
ef-q24 720 us 60 act 1 10 24 84 Yes Yes
ef-q25 720 us 60 act 1 10 25 85 Yes Yes
ef-q26 720 us 60 act 1 10 26 86 Yes Yes
ef-q27 720 us 60 act 1 10 27 87 Yes Yes
ef-q28 720 us 60 act 1 10 28 88 Yes Yes
1367
Displaying the Currently Defined Enforce-Rules
ef-q28d 300 ds 150 act 1 10 28 88 Yes No

ef-q5u 720 us 600 act 1 10 5 99 Yes Yes
The following example shows sample output from the show cable qos enforce-rule command for a particular
enforce-rule named “test”:
Router# show cable qos enforce-rule test

Name Type Dur Dir Avg-rate Auto rate Reg Enf En Per
(min) kbits/s enf (min)
test p-off 120 us 1 act 10 255 4 Y Y
The following example shows the sample output from the show cable qos enforce-rule verbose command
for an enforce-rule named “test”:
Router# show cable qos enforce-rule test verbose

Name : test
Version : docsis11
Monitoring Type : peak-offpeak
Registered : REG-DS
Enforced : ENF-DS
Monitoring Duration : 70 (in minutes)
Sample-rate : 10 (in minutes)
Average-rate : 3 kbits/sec
Direction : downstream
Auto Enforce : Yes
Current Penalty Duration : 10 (in minutes)
Default Penalty Duration : 10 (in minutes)
Penalty End-time : 23:0 (time of day)
Rule Enabled : Yes
Persistence : Yes
Weekend : No
Penalty Off : No
Monitor Weekend : Yes
Monitoring after RelTime : Off
First Peak Time : 10:0
Duration : 120 (in minutes)
First Average-rate : 1 kbits/sec
Second Peak Time : 19:0
Second Average-rate : 2 kbits/sec
Offpeak Duration : 70 (in minutes)
Offpeak Average-rate : 3 kbits/sec
Auto Enforce : Yes
Sample Rate : 10
Penalty-Period for week-days : 0
Weekend First Peak Time : 11:0
Weekend Duration : 75 (in minutes)
Weekend First Average-rate : 4 kbits/sec
Weekend Second Peak Time : 20:0
Weekend Duration : 80 (in minutes)
Weekend Second Average-rate : 5 kbits/sec
Weekend Offpeak Duration : 85 (in minutes)
Weekend Offpeak Average-rate : 6 kbits/sec
Weekend Auto Enforce : Yes
Weekend Sample Rate : 12
Penalty-Period for week-ends : 0
router#sh clock
*17:30:50.259 UTC Mon Apr 19 2010
The following example shows sample output from the show cable qos enforce-rule verbose command for
a particular enforce-rule named “test” that has specified peak-offpeak weekend monitoring options:
1368
Displaying the Current Subscriber Usage
Router# show cable qos enforce-rule test verbose

Name : test
Version : docsis10
Monitoring Type : peak-offpeak
Registered : 255
Enforced : 4
Monitoring Duration : 120 (in minutes)
Sample-rate : 10 (in minutes)
Average-rate : 1 kbits/sec
Direction : upstream
Penalty Time : 10080 (in minutes)
Penalty End-time : 23 (time of day in hrs)
Rule Enabled : Yes
Persistence : Yes
Week-end : Yes
First Peak Time : 6
First Average-rate : 2 kbits/sec
Second Peak Time : 18
Second Averate-rate : 3 kbits/sec
Offpeak Duration : 120 (in minutes)
Offpeak Average-rate : 1 kbits/sec
Auto-enforce : active
Weekend First Peak Time : 8
Weekend First Duration : 120 (in minutes)
Weekend First Average-rate : 2 kbits/sec
Weekend Second Peak Time : 18
Weekend Second Duration : 180 (in minutes)
Weekend Second Average-rate : 5 kbits/sec
Weekend Offpeak Duration : 240 (in minutes)
Weekend Offpeak Average-rate : 4 kbits/sec
Weekend Auto-enforce : active
Displaying the Current Subscriber Usage

To display the usage for all subscribers on a cable interface, use the show cable subscriber-usage command
in privileged EXEC mode without any options.
To display the usage for just those subscribers who are violating their registered quality of service (QoS)
profiles, use the show cable subscriber-usage over-consume form of the command.
The following example shows sample output from the show cable subscriber-usage command for all users
on the specified cable interface:
Router# show cable subscriber-usage cable 6/0/1

Sfid Mac Address Enforce-rule Total-Kbyte Last-detect Last-penalty Pen
Name Count time time Flag
3 0007.0e03.110d efrule-q5 121944817 Jan1 03:44:08 Jan1 03:54:08 Act
4 0007.0e03.110d efrule-q5d 1879076068 Jan1 03:35:05 Jan1 03:45:06 Act
5 0007.0e03.1431 efrule-q5 120052387 Jan1 03:44:18 Jan1 03:54:18 Act
6 0007.0e03.1431 efrule-q5d 1838493626 Jan1 03:34:55 Jan1 03:44:55 Act
8 0007.0e03.1445 efrule-q5d 1865955172 Jan1 03:35:06 Jan1 03:45:06 Act
10 0007.0e03.1225 efrule-q5d 1839681070 Jan1 03:34:55 Jan1 03:44:55 -
11 0007.0e03.0cb1 efrule-q5 122941643 Jan1 03:43:58 Jan1 03:53:58 Act
12 0007.0e03.0cb1 efrule-q5d 1889107176 Jan1 03:35:06 Jan1 03:45:06 Act
14 0007.0e03.1435 efrule-q5d 1835164034 Jan1 03:34:55 Jan1 03:44:55 -
1369
Configuration Examples for Subscriber Traffic Management on the Cisco CMTS Routers
By default, the display is sorted by the service flow ID (SFID). To sort the display by the subscriber byte
count, with the largest byte counts listed first, use the sort-byte-count option. The following example shows
sample output for show cable subscriber-usage sort-byte-count form of the command:
Note The sort-byte-count option was replaced by the sort-avg-rate option.
Router# show cable subscriber-usage

sort-byte-count
Sfid Mac Address Enforce-rule Total-Kbyte Last-detect Last-penalty Pen

Name Count time time Flag
7 0007.0e03.2cad test1 65157114 Feb24 11:36:34 Mar3 11:36:34 Act
9 0007.0e03.2c45 test1 16381014 -
5 0007.0e03.2c25 test1 13440960 -
Configuration Examples for Subscriber Traffic Management on

the Cisco CMTS Routers
This section lists sample configurations for the Subscriber Traffic Management feature on a CMTS router:
Example: DOCSIS Configuration File and STM Service Classes

The following example shows a sample DOCSIS configuration file along with sample registered and enforced
QoS service classes that you could define on a Cisco CMTS router to perform subscriber traffic management.
DOCSIS Configuration File Options

This is an example of a very basic set of options that you can configure for a cable modem in your DOCSIS
configuration file that supports a successful configuration of new QoS service class options on the Cisco
CMTS router.
Note There are certain QoS parameters that cannot be changed from the registered QoS parameter set and a new
service class. For example, the max-burst value must match the originally registered in the DOCSIS
configuration file, and the registered and enforced QoS service classes on the Cisco CMTS router. If the
max-burst value differs from the registered CMTS service class and the DOCSIS configuration file, the CM
might go into reject-c state, or the enforced class could fail.
The following example shows the configuration of two service classes named “BE-STM-US-1” and
“BE-STM-DS-1” in a DOCSIS configuration file to define a basic set of upstream and downstream parameters:
03 (Net Access Control) = Yes

17 (Baseline Privacy Block)
S01 (Authorize Wait Timeout) = 10
24 (Upstream Service Flow Block)
S01 (Flow Reference) = 1
1370
Example: DOCSIS Configuration File and STM Service Classes
S04 (Service Class Name) = BE-STM-US-1

25 (Downstream Service Flow Block)
S01 (Flow Reference) = 2
S04 (Service Class Name) = BE-STM-DS-1
29 (Privacy Enable) = Yes
The following example shows sample cable service class
commands on the Cisco CMTS router for configuration of subscriber traffic management that
correspond to the service class names in the DOCSIS configuration file of “BE-STM-US-1” and
“BE-STM-DS-1.” These service classes correspond to the registered service classes configured
by the service-class registered
command for the QoS enforce-rules shown later in this example:
cable service class 2 name BE-STM-US-1
cable service class 3 name BE-STM-DS-1
For the cable modem to achieve maximum US thoroughput, provide a large value to the max-concat-burst
keyword in the cable service class command.
The following example shows sample cable service class commands on the Cisco CMTS router that configure
new QoS parameters for identified subscribers to limit bandwidth using the max-rate parameter. These service
classes correspond to the enforced service classes configured by the service-class enforced command for the
QoS enforce rules shown later in this example:
cable service class 102 name BEUS-1

cable service class 103 name BEDS-1
The following example shows configuration of the corresponding enforce-rules for upstream and downstream
monitoring, which identifies the registered and enforced service classes:
cable qos enforce-rule US-1

monitoring-basics legacy docsis11
penalty-period 120
service-class registered BE-STM-US-1
service-class enforced BEUS-1
duration 120 avg-rate 1 sample-interval 15 up enf
enabled
!
cable qos enforce-rule DS-1
penalty-period 120
service-class registered BE-STM-DS-1
service-class enforced BEDS-1
duration 120 avg-rate 1 sample-interval 15 do enf
enabled
1371
Example: Downstream Configuration
Example: Downstream Configuration

The following example shows a typical enforce-rule configuration for traffic in the downstream direction:
!
cable qos enforce-rule downstream-rule
penalty-period 120
service-class registered class5
service-class enforced class99
duration 120 avg-rate 1 sample-interval 15 downstream enforce
enabled
Example: Upstream Configuration

The following example shows a typical enforce-rule configuration for traffic in the upstream direction:
!
cable qos enforce-rule upstream-rule
penalty-period 120
duration 120 avg-rate 1 sample-interval 15 upstream enforce
enabled
Example: Downstream and Upstream Configuration

The following example shows a typical enforce-rule configuration for traffic in both the downstream and
upstream directions. Two separate rules are created, using the identical configuration, except for the keywords
upstream and downstream in the duration command.
Note The enforce rules for the upstream and downstream directions can use either an identical configuration, or
they can use their own individual configurations.
!
cable qos enforce-rule upstream-rule
penalty-period 120
duration 120 avg-rate 5 sample-interval 15 upstream enforce
enabled
cable qos enforce-rule downstream-rule
penalty-period 120
enabled
The following example shows an enforce-rule configuration for traffic in upstream direction. A unique penalty
duration is configured for upstream, with monitoring turned on after the penalty release time.
1372
Example: Weekend Monitoring Configuration
Note For upstream direction, a unique penalty duration (120 minutes) is configured, which takes precedence over
the duration configured using the penalty-period command (60 minutes). A fresh monitoring starts after the
penalty release time (23:00), when all the traffic counters are reset to 0.
!
cable qos enforce-rule upstream_rule
monitoring-basics peak-offpeak docsis10
penalty-period 120 time-of-day 23:00 monitoring-on
qos-profile registered 6
qos-profile enforced 100
peak-time1 10:30 duration 120 avg-rate 10 peak-time2 22:10 duration 60 avg-rate 10
sample-interval 15 penalty 120 upstream enforce
enabled
Example: Weekend Monitoring Configuration

The following example shows a sample configuration of peak-offpeak weekend monitoring for DOCSIS 1.0
cable modems:
cable qos enforce-rule monitoring

monitoring-basics peak-offpeak docsis10
penalty-period 120
qos-profile registered 6
qos-profile enforced 100
peak-time1 10 duration 120 avg-rate 10 peak-time2 23 duration 120 avg-rate 10
sample-interval 15 upstream enforce
weekend peak-time1 8 duration 120 avg-rate 100 peak-time2 20 duration 120 avg-rate 10000
enabled
For additional information related to the Subscriber Traffic Management feature, refer to the following
references:
Related Documents
Cable Cisco IOS CMTS Cable Command Reference

commands
Standards
7
Standards Title
SP-RFIv1.1-I09-020830 Data-over-Cable Service Interface Specifications Radio Frequency

Interface Specification, version 1.1 ( http://www.cablemodem.com)
1373
7
Standards Title
draft-ietf-ipcdn-docs-rfmibv2-06 Radio Frequency (RF) Interface Management Information Base for

DOCSIS 2.0 Compliant RF Interfaces
7
MIBs
8
MIBs MIBs Link
• CISCO-CABLE-QOS-MONITOR-MIB To locate and download MIBs for selected platforms, Cisco IOS
• DOSCIS-QOS-MIB releases, and feature sets, use Cisco MIB Locator found at the
following URL:
8
RFCs
9
RFCs Title

9
Description Link

1374
Feature Information for Subscriber Traffic Management

Table 235: Feature Information for Subscriber Traffic Management
Subscriber traffic Cisco IOS XE Everest This feature was integrated into Cisco IOS XE
management 16.6.1 Everest 16.6.1 on Cisco cBR Series Converged
Broadband Routers.
1375
1376
CHAPTER 94
Narrowband Digital Forward And Narrowband
Digital Return
This document describes the narrowband digital forward and narrowband digital return feature.
• Information About NDF and NDR, on page 1379
• Restrictions for Configuring NDF and NDR, on page 1379
• Configure NDF and NDR, on page 1380
• Feature Information for Narrowband Digital Forward And Narrowband Digital Return, on page 1387
1377
Digital PICs:

Module:

Modules:
line card reload.
1378
Information About NDF and NDR
Information About NDF and NDR

Narrowband Digital Forward (NDF) refers to the digitizing of an analog portion of the downstream spectrum
at the headend, sending the digital samples as payload in [DEPI] packets to the RPD, and then re-creating the
original analog stream at the RPD. NDF supports services such as FM Broadcast, DAB+ Broadcast, and OOB
signals for Forward Sweep, DS Leakage, and Element management.
Narrowband Digital Return (NDR) refers to the digitizing of an analog portion of the upstream spectrum at
the RPD, sending the digital samples as payload in [R-UEPI] packets to the CMTS, and then re-creating the
original analog stream at the headend. NDR supports legacy OOB signals for Reverse Sweep, Return Path
Monitoring, FSK based HMS, and other FSK based telemetry signals.
Restrictions for Configuring NDF and NDR

The following restrictions are applicable for configuring NDF and NDR:
1x2 RPD
NDF
• Supports a maximum of three narrow band NDF channels if OOB 55-1 or OOB 55-2 is not configured.
Only channel ID 0, 1 and 2 can be used for 1x2 RPD, channel ID 3 is not supported and will be rejected
by 1x2 RPD.
• If OOB 55-1 DS is configured, only one NDF channel is supported. OOB 55-1 DS uses first and the
second OOB channel while NDF uses the third OOB channel. If 55-1 DS is configured after configuring
NDF, ensure that not more than one NDF channel is configured.
• If OOB 55-2 is configured, two NDF channels are supported. OOB 55-2 uses the first OOB channel.
• Supports NDF Mode 0 to Mode 6. NDF Mode 7 is not supported.
NDR
• Each upstream port supports three OOB channels. OOB 55-1 and OOB 55-2 channels share the upstream
OOB resource with NDR channels.
• If two OOB 55-1 channels are configured on upstream port 0, then only one NDR channel is supported
on port 0, and up to three NDR channels are suppported on port 1.
• If one OOB 55-2 upstream channel is configured on a port, then either one mode 6 (5.12 MHz) NDR
can be configured or 2 NDR with mode 5 or lesser can be configured.
• NDR Mode 0 (80 KHz) is not supported.
2x2 RPD
Starting from Cisco IOS XE Amsterdam 17.2.1, 4 NDF (3 narrowband and 1 wideband) sessions are supported.
1379
Configure NDF and NDR
Configure NDF and NDR

To configure NDF and NDR, perform these steps.
1. Configure static-pseudowires for NDF and NDR.
2. Configure NDF and NDR profiles.
3. Bind static-pseudowires and profiles with RPD.
Configure Static-Pseudowires for NDF and NDR
Note • For NDF static pseudowire, session ID must be unique within a rf-port across all rf-channels configured
in that port.
• For NDR static pseudowire, the session ID and the server IP must be unique within a RPD.
To configure NDF static-pseudowires, run the following commands:
Router# enable
Router(config)# cable oob
Router(config-oob)# [no] static-pseudowire <name> type ndf [id <id>]
Router(config-oob-spw)# [no] dest-ip <ipv4/ipv6 addr> [source-ip <ipv4 | ipv6 addr>]
Router(config-oob-spw)# [no] session-id <session id>
To configure NDR static-pseudowires, run the following commands:
Router# enable
Router(config-oob)# [no] static-pseudowire <name> type ndr [id <id>]
Router(config-oob-spw)# [no] server-ip <ipv4/ipv6 addr>
Router(config-oob-spw)# [no] mtusize <mtu size value>
Router(config-oob-spw)# [no] per-hop-behavior <IP DSCP per hop behavior value>
Router(config-oob-spw)# [no] session-id <session id>
Table 237: Syntax Description
Syntax Description
name Specify a unique name for the static-pseudowire. The name can be up to 30
characters long and is case sensitive.The name can be alphanumeric and
undescore ( _ ) can be used.
id Specify a unique ID for the static-pseudowire. The valid range is from 1 to

4294967295.
If the ID is not specified, the system auto-generates an ID.
1380
Syntax Description
dest-ip For multicast NDF, specify the Group (Destination) IP address of the multicast
group from which RPD has to receive data on a static pseudowire.
For unicast NDF, the Group (Destination) IP address is set to 0.0.0.0 or 0::0.
The Group (Destination) IP address can IPv4 or IPv6.
source-ip For source specific multicast (SSM) group, specify the source IP address of
the multicast group that RPD has to join to to receive data on a static
pseudowire.
For unicast NDF, specify the source IP address of the remote peer from which
RPD has to receive data on a NDF static pseudowire.
server-ip Specify the destination IP address from which RPD has to receive data on a
static pseudowire. The server IP can be IPv4 or IPv6 address.
type Configure the static-pseudowire type. The static-pseudowire type is NDF or

NDR.
mtusize Specify the MTU (Maximum Transmission Unit) size supported by the CCAP
Core on a return static pseudowire. MTU is the Layer 3 payload of a Layer
2 frame. The MtuSize attribute carries information equivalent to DEPI Local
MTU. CCAP core can receive the configured MTU size from the RPD on
the CIN interface.
The valid range for MTU size is 1500–9216. The default MTU size is 1500.
1381
Syntax Description
per-hop-behavior Specify the Per Hop Behavior Identifier that is equal to the 6-bit DSCP with
which the RPD transmits L2TPv3 data packets on the selected return static
pseudowire.The per-hop-behavior configures information that is equivalent
to the information configured by the PHBID field of the Upstream Flow. The
upper two bits are set as 00 by the CCAP core and ignored by the RPD. The
default value is 0.
These standard QOS DSCP values are allowed to be selected in the CLI.
af11 Match packets with AF11 dscp (001010)
cs1 Match packets with CS1(precedence 1) dscp (001000)
default Match packets with default dscp (000000)
ef Match packets with EF dscp (101110)
session-id Configure the session ID for the static pseudowire.

Note One session ID is configured for each static pseudowire as static
pseudowires are defined in a single direction.
1382
Configure NDF and NDR Profile
Configure NDF and NDR Profile
Note You can configure only one rf-channel in a NDF and NDR profile.
To configure NDF profile, run the following commands:
Router# enable
Router(config)# [no] controller downstream-oob NDF-profile <profile id>
Router(config-profile)# [no] ds-channel <channel id> rf-mute
Router(config-profile)# [no] ds-channel <channel id> shutdown
Router(config-profile)# [no] ds-channel <channel id> frequency <frequency>
Router(config-profile)# [no] ds-channel <channel id> width <width>
Router(config-profile)# [no] ds-channel <channel id> poweradjust <power-adjust>
To configure NDR profile, run the following commands:
Router# enable
Router(config)# [no] controller upstream-oob NDR-profile <profile id>
Router(config-profile)# [no] us-channel <channel id> shutdown
Router(config-profile)# [no] us-channel <channel id> frequency <frequency>
Router(config-profile)# [no] us-channel <channel id> width <width>
Router(config-profile)# [no] us-channel <channel id> poweradjust <power-adjust>
Table 238: Syntax Description
Syntax Description
rf-mute Specify True to set the modulator in the muted diagnostic state. In the
muted diagnostic state, the modulator does not transmit signal, but the
operational status of the channel is not affected.
shutdown Set the administrative state of the selected NDF/NDR channel. Specifying
shutdown removes all configuration from the channel. Specifying
unshutdown retrieves all configuration of the channel.
width Sepcify the total width of the spectrum in Hertz, including any required
guardband.
frequency Specify the frequency of the channel in Hertz.
poweradjust Specify the power level adjustment for the NDF channel relative to the
base power level configured for the DS RF port.
1383
Bind NDF Static-Pseudowire and NDF Profile with Rf-Port
Bind NDF Static-Pseudowire and NDF Profile with Rf-Port
Note • Destination IP address must be configured before binding NDF static-pseudowire to RPD. Once the
destination IP address is bound, it cannot be removed, but can be updated.
• Frequency and channel width must be configured in NDF profile before binding NDF static-pseudowire
to RPD. If frequency is configured, channel width cannot be removed or updated. To remove or update
the channel width from the NDF profile, you must remove the frequency.
• To update frequency and channel width when the NDF profile is associated with the RPD, you must shut
down the rf-channel in the NDF profile.
To bind NDF static-pseudowire and NDF profile with rf-port, execute the bind commands under core-interface
TenGigabitEthernet [interface] command:

Router(config)# cable rpd <rpd name>
Router(config-rpd)# core-interface TenGigabitEthernet <interface>
Router(cable-rpd-core)# [no] rpd-ds <port id> static-pseudowire <name> profile <id>
Bind NDR Static-Pseudowire and NDR Profile with Rf-Port
Note • Server IP address must be configured before binding NDR static-pseudowire to RPD. Once the server
IP address is bound, it cannot be removed, but can be updated.
• Frequency and channel width must be configured in NDR profile before binding NDR static-pseudowire
to RPD. If frequency is configured, channel width cannot be removed or updated. To remove or update
the channel width from the NDR profile, you must remove the frequency.
• To update frequency and channel width when the NDR profile is associated with the RPD, you must
shut down the rf-channel in the NDR profile.
To bind NDR static-pseudowire and NDR profile with rf-port, run the bind commands under core-interface
TenGigabitEthernet [interface] command.

Router(config)# cable rpd <rpd name>
Router(config-rpd)# core-interface TenGigabitEthernet <interface>
Router(cable-rpd-core)# [no] rpd-us <port id> static-pseudowire <name> profile <id>
Display TLV Status

To display the TLV status sent from cBR-8, run these commands:
Router# show cable rpd ndf-channels
Router# show cable rpd ndr-channels
1384
Display TLV Status
To display per channel static-pseudowire and controller profile configuration, run these commands:
Router# show cable rpd ndf-channels detailed
Router# show cable rpd ndr-channels detailed
These examples show how to display the TLV status.
Router# show cable rpd ndf-channels
RPD-MAC-ID Port Chan Session-Id AdminState Rf-Mute Frequency TLV-94-Status
0004.9f31.0785 0 0 0x88000001 NO SHUTDOWN NO MUTE 70000000 Failed-In-RPD
0004.9f31.0785 0 1 0x88000002 NO SHUTDOWN NO MUTE 72000000 RPD-Not-Capable
TLV-58-Status RPD-NAME
Success-In-RPD RPD0-RACK1
RPD-Not-Capable RPD0-RACK1
Router# show cable rpd ndr-channels
RPD-MAC-ID Port Chan Session-Id AdminState Frequency TLV-95-Status
0004.9f31.0785 0 0 0x48000001 NO SHUTDOWN 5216000 Failed-In-RPD
0004.9f31.0785 0 1 0x48000002 NO SHUTDOWN 5216000 RPD-Not-Capable
0004.9f31.0785 1 0 0x48000001 NO SHUTDOWN 5216000 Failed-In-RPD
TLV-58-Status RPD-NAME
Table 239: TLV Status Description
TLV Status Description
Success-In-RPD NDF/NDR configuration is sent to the RPD and RPD sends the response
TLV with status as SUCCESS.
Failed-In-RPD NDF/NDR configuration is sent to the RPD and RPD sends the response
TLV with status as ERROR.
Sent-To-RPD NDF/NDR configuration is sent to the RPD but no reponse is recieved from
the RPD.
Failed-To-Send NDF/NDR TLV fails to deliver from CCAP core to RPD.
RPD-Not-Capable RPD is not capable of supporting attributes in TLV. For example, if RPD
does not support NDF or NDR, the TLV status sent as RPD-Not-Capable.
1385
Example: NDF Configuration
TLV Status Description
In-Progress Frequency and channel width are set to 0 in a NDF or NDR profile.
Depending on the TLV response from the RPD when frequency and channel
width are configured and a no shutdown is performed on the rf-channel, the
In-Progress status changes.
RPD-Offline RPD is offline.
Example: NDF Configuration

This example shows how to configure static-pseudowire for NDF.
Configure static-pseudowire for unicast NDF
Router(config-oob)# static-pseudowire ndf0 type ndf id 1
Router(config-oob-spw)# dest-ip 0.0.0.0 source-ip 192.168.1.10
Router(config-oob-spw)# session-id 0x1
Configure static-pseudowire for multicast NDF

Router(config-oob)# static-pseudowire ndf2 type ndf id 12
Router(config-oob-spw)# dest-ip 232.1.1.10 source-ip 10.10.10.5
This example shows how to configure downstream OOB NDF profile.

Router(config)# controller downstream-oob NDF-profile id 100
Router(config-profile)# no ds-channel 0 rf-mute
Router(config-profile)# no ds-channel 0 shutdown
Router(config-profile)# ds-channel 0 frequency 70000000
Router(config-profile)# ds-channel 0 width 1280000
Router(config-profile)# ds-channel 0 poweradjust -10
This example shows how to configure bind NDF static-pseudowire and NDF profile with rf-port.
Router(config)# cable rpd node6
Router(config-rpd)# core-interface TenGigabitEthernet 7/1/0
Router(config-rpd-core)# rpd-ds 0 static-pseudowire ndf0 profile 100
Example: NDR Configuration

This example shows how to configure static-pseudowire for NDR.
Router(config-oob)# static-pseudowire ndr0 type ndr id 19
Router(config-oob-spw)# server-ip 192.168.69.1
1386
Feature Information for Narrowband Digital Forward And Narrowband Digital Return
Router(config-oob-spw)# mtusize 1500

Router(config-oob-spw)# per-hop-behavior default
This example shows how to configure upstream OOB NDR profile.

Router(config)# controller upstream-oob NDR-profile id 100
Router(config-profile)# no us-channel 0 shutdown
Router(config-profile)# us-channel 0 frequency 5216000
Router(config-profile)# us-channel 0 width 1280000
Router(config-profile)# us-channel 0 poweradjust -5
This example shows how to configure bind NDR static-pseudowire and NDR profile with rf-port.
Router(config)# cable rpd node6
Router(config-rpd)# core-interface TenGigabitEthernet 7/1/0
Router(config-rpd-core)# rpd-us 0 static-pseudowire ndr0 profile 100
Feature Information for Narrowband Digital Forward And

Narrowband Digital Return
Table 240: Feature Information for Narrowband Digital Forward And Narrowband Digital Return
Narrowband Digital Forward And Cisco IOS XE Gibraltar This feature was introduced on the Cisco
Narrowband Digital Return 16.10.1 cBR Converged Broadband Router.
1387
Feature Information for Narrowband Digital Forward And Narrowband Digital Return
1388
CHAPTER 95
Differentiated Services Code Point Downstream
Differentiated Services Code Point (DSCP) is a packet header value marking that can be used to request
priority traffic.
• Information About Differentiated Services Code Point Downstream Marking, on page 1389
• Feature Information for Differentiated Services Code Point Downstream Marking, on page 1390
Information About Differentiated Services Code Point

Downstream Marking
From Cisco IOS XE Amsterdam 17.3.x and later, Cisco cBR-8 Converged Broadband Router conforms to
DOCSIS service’s priority to drive traffic by high queue or low queue with various Differentiated Services
Code Point Downstream (DSCP) marking. The following changes would apply:
• In high queue, L2TP traffic will be set to DSCP 40.
• In low queue, L2TP traffic will be set to DSCP 0.
• For the traffic with priority greater than or equal to the threshold, the L2TP packet’s DSCP will be
changed to CS5(40).
You might see the following message when you change the threshold:
Router# cable rphy flow downstream 3

High flow queue congestion may cause packets drop or jitter or latency is unexpectedly
increased. To avoid this, suggest the traffic in high queue less than 60% of full bandwidth
per line-card!
This change will take effect after modem reset and online again.
We recommend that you configure the traffic for less than 60% of full bandwidth per linecard in high-flow
queue. The high-flow queue is designed for high priority traffic, and without the recommended configuration
it may cause unexpected packet drop, jitter, or latency in high flow queue.
1389
Feature Information for Differentiated Services Code Point Downstream Marking
Feature Information for Differentiated Services Code Point

Downstream Marking
Table 241: Feature Information for Differentiated Services Code Point Downstream Marking
Differentiated Services Code Point Cisco IOS XE Gibraltar This feature was introduced on the Cisco
Downstream Marking 17.3.1w cBR Converged Broadband Router.
1390
PA R T XI
Security and Cable Monitoring Configuration
• Dynamic Shared Secret, on page 1393
• Lawful Intercept Architecture, on page 1419
• Cable Monitoring Feature for Cisco cBR Series Routers , on page 1433
• Source-Based Rate Limit, on page 1441
• Cable Duplicate MAC Address Reject, on page 1463
• Cable ARP Filtering, on page 1475
• Subscriber Management Packet Filtering Extension for DOCSIS 2.0, on page 1495
• MAC Filtering, on page 1503
CHAPTER 96
Dynamic Shared Secret
This document describes the Dynamic Shared Secret feature, which enables service providers to provide
higher levels of security for their Data-over-Cable Service Interface Specifications (DOCSIS) cable networks.
This feature uses randomized, single-use shared secrets to verify the DOCSIS configuration files that are
downloaded to each cable modem.
The Dynamic Shared Secret feature automatically creates a unique DOCSIS shared secret on a per-modem
basis, creating a one-time use DOCSIS configuration file that is valid only for the current session. This ensures
that a DOCSIS configuration file that has been downloaded for one cable modem can never be used by any
other modem, nor can the same modem reuse this configuration file at a later time.
This patented feature is designed to guarantee that all registered modems use only the quality of service (QoS)
parameters that have been specified by the DOCSIS provisioning system for a particular modem at the time
of its registration. This feature is an accepted DOCSIS standard.
Contents
• Prerequisites for Dynamic Shared Secret, on page 1395
• Restrictions for Dynamic Shared Secret, on page 1395
• Information About Dynamic Shared Secret, on page 1399
• How to Configure the Dynamic Shared Secret Feature, on page 1405
• How to Monitor the Dynamic Shared Secret Feature, on page 1411
• Troubleshooting Cable Modems with Dynamic Shared Secret, on page 1414
• Configuration Examples for Dynamic Shared Secret, on page 1415
• Feature Information for Dynamic Shared Secret, on page 1418
1393
Digital PICs:

Module:

Modules:
1394
Prerequisites for Dynamic Shared Secret
line card reload.
Prerequisites for Dynamic Shared Secret

The configuration of Dynamic Shared Secret feature is supported on the Cisco CMTS routers.
Following is a list of other important prerequisites for the Dynamic Shared Secret feature:
• The Cisco CMTS must be running Cisco IOS-XE 3.15.0S or later.
• The Dynamic Shared Secret feature supports an external provisioning server.
• A cable modem must be able to register with the Cisco CMTS before enabling the Dynamic Shared
Secret feature.
• For full security, DOCSIS configuration files should have filenames that are at least 5 or more characters
in length.
• For best performance during the provisioning of cable modems, we recommend using Cisco Network
Registrar Release 3.5 or later.
Note When the Dynamic Shared Secret feature is enabled using its default configuration, a cable modem diagnostic
webpage shows a scrambled name for its DOCSIS configuration file. This filename changes randomly each
time that the cable modem registers with the CMTS. To change the default behavior, use the nocrypt option
with the cable dynamic-secret command.
Restrictions for Dynamic Shared Secret

General Restrictions for Dynamic Shared Secret
• Shared-secret and secondary-shared-secret cannot be configured with Dynamic Shared Secret feature.
• If you configure the Dynamic Shared Secret feature on a primary cable interface, you should also configure
the feature on all of the corresponding subordinate cable interfaces.
• The Dynamic Shared Secret feature ensures that each cable modem registering with the CMTS can use
only the DOCSIS configuration file that is specified by the service provider’s authorized Dynamic Host
Configuration Protocol (DHCP) and TFTP servers, using the DOCSIS-specified procedures.
1395
Cable Modem Restrictions for Dynamic Shared Secret
• The Dynamic Shared Secret feature does not affect cable modems that are already online and provisioned.
If a cable modem is online, you must reset it, so that it reregisters, before it complies with the Dynamic
Shared Secret feature.
• The DMIC lock mode uses the following behavior during a switchover event in HCCP N+1 Redundancy.
All cable modems which were previously in lock mode are taken offline during a switchover event, and
the prior state of locked modems is lost. If previously locked modems remain non-compliant, they will
return to LOCK mode after three failed registration attempts. If the modems have become DOCSIS
compliant, they will return online in the normal fashion. Refer to the SNMP Support, on page 1402 for
additional information about DMIC lock mode.
• If a Broadband Access Center for Cable (BACC) provisioning server is being used, the Device Provisioning
Engine (DPE) TFTP server verifies that the IP address of the TFTP client matches the expected DOCSIS
cable modem IP Address. If a match is not found, the request is dropped. This functionality is incompatible
with the CMTS DMIC feature. Use the no tftp verify-ip command on all BACC DPE servers to disable
the verification of the requestor IP address on dynamic configuration TFTP requests. Refer to the Cisco
Broadband Access Centre DPE CLI Reference in the http://www.cisco.com/c/en/us/td/docs/net_mgmt/
broadband_access_center_for_cable/4-0/command/reference/DPECLIRef40.html for additional
information.
Cable Modem Restrictions for Dynamic Shared Secret

DHCP Restriction for Incognito Server and Thomson Cable Modems
The Dynamic Host Configuration Protocol (DHCP) passes configuration information to DHCP hosts on a
TCP/IP network. Configuration parameters and other control information are stored in the options field of the
DHCP message.
When using DMIC with the Incognito DHCP server, the Incognito server must be re-configured so that the
following two options are not sent in the DHCP message:
• option 66 —This option is used to identify a TFTP server when the sname field in the DHCP header has
been used for DHCP options. Option 66 is a variable-length field in the Options field of a DHCP message
described as "an option used to identify a TFTP server when the 'sname' field in the DHCP header has
been used for DHCP options" as per RFC 2132.
• sname field —The sname field is a 64-octet field in the header of a DHCP message described as "optional
server host name, null terminated string," as per RFC2131. A DHCP server inserts this option if the
returned parameters exceed the usual space allotted for options. If this option is present, the client interprets
the specified additional fields after it concludes interpretation of the standard option fields.
Note It is not compliant with DOCSIS to include both of these options in the DHCP message.
The problematic packet capture below is a DHCP offer in which both sname and option 66 are set (in this
respective sequence):
0000 00 30 19 47 8f 00 00 d0 b7 aa 95 50 08 00 45 00
0010 01 4a 8f 50 00 00 80 11 46 30 ac 10 02 01 ac 10
0020 0a 01 00 43 00 43 01 36 0c 75 02 01 06 00 b0 a0
0030 25 01 00 00 00 00 00 00 00 00 ac 10 0a 53 00 00
0040 00 00 ac 10 0a 01 00 10 95 25 a0 b0 00 00 00 00
1396
DOCSIS Compliance
0050 00 00 00 00 00 00 5b 31 37 32 2e 31 36 2e 32 2e
(sname option immediately above)
0060 31 5d 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0090 00 00 00 00 00 00 64 65 66 61 75 6c 74 2e 63 66
00a0 67 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0100 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0110 00 00 00 00 00 00 63 82 53 63 35 01 02 36 04 ac
0120 10 02 01 33 04 00 06 94 0d 01 04 ff ff ff 00 02
0130 04 ff ff b9 b0 03 08 ac 10 02 fe ac 10 0a 01 04
0140 04 ac 10 02 01 07 04 ac 10 02 01 42 0a 31 37 32
(option 66 immediately above)
0150 2e 31 36 2e 32 2e 31 ff
When using DMIC with Incognito DHCP servers and Thomson cable modems, you must prevent both options
from being sent in the DHCP offer. Use one of the following workaround methods to achieve this:
• Change the Incognito DHCP server so that it does not include the sname option as described above.
• Change the cable modem code so that sname is not prioritized above option 66, as in the problematic
packet capture shown in the example above.
• Migrate to a compliant DHCP and TFTP server such as CNR. This also offers significantly higher
performance.
Refer to these resources for additional DOCSIS DHCP information, or optional DHCP MAC exclusion:
• DHCP Options and BOOTP Vendor Extensions, RFC 2132
• Filtering Cable DHCP Lease Queries on Cisco CMTS Routers
http://www.cisco.com/en/US/docs/cable/cmts/feature/cblsrcvy.html
DOCSIS Compliance
• Cable modems are assumed to be DOCSIS-compliant. If a cable modem is not fully DOCSIS-compliant,
it could trigger a CMTS Message Integrity Check (MIC) failure during registration in rare circumstances.
Under normal operations, however, it can be assumed that cable modems that fail the CMTS MIC check
from the Dynamic Shared Secret feature are either not DOCSIS-compliant, or they might have been
hacked by the end user to circumvent DOCSIS security features.
Some of the cable modems with the following OUIs have been identified as having problems with the Dynamic
Shared Secret feature, depending on the hardware and software revisions:
• • 00.01.03
• 00.E0.6F
• 00.02.B2
These particular cable modems can remain stuck in the init(o) MAC state and cannot come online until the
Dynamic Shared Secret feature is disabled. If this problem occurs, Cisco recommends upgrading the cable
modem’s software to a fully compliant software revision.
1397
TFTP Restrictions
Alternatively, these cable modems may be excluded from the dynamic secret function using the following
command in global configuration mode:
cable dynamic-secret exclude
Excluding cable modems means that if a violator chooses to modify their cable modem to use one of the
excluded OUIs, then the system is no longer protected. Refer to the #unique_1878.
Tip To help providers to identify non-DOCSIS compliant modems in their network, the Dynamic Shared Secret
feature supports a “mark-only” option. When operating in the mark-only mode, cable modems might be able
to successfully obtain higher classes of service than are provisioned, but these cable modems will be marked
as miscreant in the show cable modem displays (with !online, for example). Such cable modems also display
with the show cable modem rogue command. Service providers may decide whether those cable modems
must be upgraded to DOCSIS-compliant software, or whether the end users have hacked the cable modems
for a theft-of-service attack.
The following example illustrates output from a Cisco CMTS that is configured with the cable dynamic-secret
mark command with miscreant cable modems installed. These cable modems may briefly show up as
"reject(m)" for up to three registration cycles before achieving the !online status.
Router# show cable modem rogue

Spoof TFTP
MAC Address Vendor Interface Count Dnld Dynamic Secret
000f.0000.0133 00.0F.00 C4/0/U1 3 Yes 905B740F906B48870B3A9C5E441CDC67
000f.0000.0130 00.0F.00 C4/0/U1 3 Yes 051AEA93062A984F55B7AAC979D10901
000f.0000.0132 00.0F.00 C4/0/U2 3 Yes FEDC1A6DA5C92B17B23AFD2BBFBAD9E1
vxr#scm | inc 000f
000f.0000.0133 4.174.4.101 C4/0/U1 !online 1 -7.00 2816 0 N
000f.0000.0130 4.174.4.89 C4/0/U1 !online 2 -6.50 2819 0 N
000f.0000.0132 4.174.4.90 C4/0/U2 !online 18 -7.00 2819 0 N
TFTP Restrictions
• Cable modems can become stuck in the TFTP transfer state (this is indicated as init(o) by the show cable
modem command) in the following situation:
• The Dynamic Shared Secret feature is enabled on the cable interface, using the cable dynamic-secret
command. This feature applies if the cable modem is a miscreant cable modem, or if the cable
modem is a DOCSIS 1.0 cable modem running early DOCSIS 1.0 firmware that has not yet been
updated. This feature also applies if the TFTP server is unable to provide the cable modem's TFTP
configuration file to the Cisco CMTS. This is the case, for example, when using BACC and not
configuring the system to permit a TFTP request from a non-matching source IP address. The debug
cable dynamic-secret command also shows this failure.
• A large number of cable modems are registering at the same time. Some or all of those cable modems
could also be downloading the DOCSIS configuration file using multiple TFTP transfers that use
multiple TFTP ports on the Cisco CMTS router, and the TFTP server is unable to keep up with the
rate of TFTP requests generated by the system. Some TFTP servers may be limited to the number
of concurrent TFTP get requests initiated by the same source IP address per unit time, or simply
unable to handle the rate of new modem registrations before cable dynamic-secret is configured.
The debug cable dynamic-secret command shows failure to receive some files in this situation.
This situation of stuck cable modems can result in the TFTP server running out of available ports, resulting
in the cable modems failing the TFTP download stage. To prevent this situation from happening, temporarily
1398
Information About Dynamic Shared Secret
disable the Dynamic Shared Secret feature on the cable interface or reduce the size of the DOCSIS configuration
file.
Information About Dynamic Shared Secret

The DOCSIS specifications require that cable modems download, from an authorized TFTP server, a DOCSIS
configuration file that specifies the quality of service (QoS) and other parameters for the network session.
Theft-of-service attempts frequently attempt to intercept, modify, or substitute the authorized DOCSIS
configuration file, or to download the file from a local TFTP server.
To prevent theft-of-service attempts, the DOCSIS specification allows service providers to use a shared secret
password to calculate the CMTS Message Integrity Check (MIC) field that is attached to all DOCSIS
configuration files. The CMTS MIC is an MD5 digest that is calculated over the DOCSIS Type/Length/Value
(TLV) fields that are specified in the configuration file, and if a shared secret is being used, it is used in the
MD5 calculation as well.
The cable modem must include its calculation of the CMTS MIC in its registration request, along with the
contents of the DOCSIS configuration file. If a user modifies any of the fields in the DOCSIS configuration
file, or uses a different shared secret value, the CMTS cannot verify the CMTS MIC when the cable modem
registers. The CMTS does not allow the cable modem to register, and marks it as being in the “reject(m)”
state to indicate a CMTS MIC failure.
Users, however, have used various techniques to circumvent these security checks, so that they can obtain
configuration files that provide premium services, and then to use those files to provide themselves with higher
classes of services. Service providers have responded by changing the shared secret, implementing DOCSIS
time stamps, and using modem-specific configuration files, but this has meant creating DOCSIS configuration
files for every cable modem on the network. Plus, these responses would have to be repeated whenever a
shared secret has been discovered.
The Dynamic Shared Secret feature prevents these types of attacks by implementing a dynamically generated
shared secret that is unique for each cable modem on the network. In addition, the dynamic shared secrets are
valid only for the current session and cannot be reused, which removes the threat of “replay attacks,” as well
as the reuse of modified and substituted DOCSIS configuration files.
Modes of Operation
The Dynamic Shared Secret feature can operate in three different modes, depending on what action should
be taken for cable modems that fail the CMTS MIC verification check:
• Marking Mode—When using the mark option, the CMTS allows cable modems to come online even if
they fail the CMTS MIC validity check. However, the CMTS also prints a warning message on the
console and marks the cable modem in the show cable modem command with an exclamation point (!),
so that this situation can be investigated.
• Locking Mode—When the lock option is used, the CMTS assigns a restrictive QoS configuration to
CMs that fail the MIC validity check twice in a row. You can specify a particular QoS profile to be used
for locked cable modems, or the CMTS defaults to special QoS profile that limits the downstream and
upstream service flows to a maximum rate of 10 kbps.
If a customer resets their CM, the CM will reregister but still uses the restricted QoS profile. A locked CM
continues with the restricted QoS profile until it goes offline and remains offline for at least 24 hours, at which
point it is allowed to reregister with a valid DOCSIS configuration file. A system operator can manually clear
the lock on a CM by using the clear cable modem lock command.
1399
Operation of the Dynamic Shared Secret
This option frustrates users who are repeatedly registering with the CMTS in an attempt to guess the shared
secret, or to determine the details of the Dynamic Shared Secret security system.
• Reject Mode—In the reject mode, the CMTS refuses to allow CMs to come online if they fail the CMTS
MIC validity check. These cable modems are identified in the show cable modem displays with a MAC
state of “reject(m)” (bad MIC value). After a short timeout period, the CM attempts to reregister with
the CMTS. The CM must register with a valid DOCSIS configuration file before being allowed to come
online. When it does come online, the CMTS also prints a warning message on the console and marks
the cable modem in the show cable modem command with an exclamation point (!), so that this situation
can be investigated.
Note To account for possible network problems, such as loss of packets and congestion, the Cisco CMTS will allow
a cable modem to attempt to register twice before marking it as having failed the Dynamic Shared Secret
authentication checks.
Operation of the Dynamic Shared Secret

The Dynamic Shared Secret feature automatically creates a unique DOCSIS shared secret on a per-modem
basis, creating a one-time use DOCSIS configuration file that is valid only for the current session. This ensures
that a DOCSIS configuration file that has been downloaded for one cable modem can never be used by any
other modem, nor can the same modem reuse this configuration file at a later time.
This patent pending feature is designed to guarantee that all registered modems are using only the QOS
parameters that have been specified by the DOCSIS provisioning system for that particular modem at the time
of its registration.
When a DOCSIS-compliant cable modem registers with the CMTS, it sends a DHCP request, and the DHCP
server sends a DHCP response that contains the name of the DOCSIS configuration file that the cable modem
should download from the specified TFTP server. The cable modem downloads the DOCSIS configuration
file and uses its parameters to register with the CMTS
When the Dynamic Shared Secret feature is enabled, the CMTS performs the following when it receives the
DHCP messages:
• The CMTS creates a dynamically generated shared secret.
• In the default configuration, the CMTS takes the name of the DOCSIS configuration file and generates
a new, randomized filename. This randomized filename changes every time the cable modem registers,
which prevents the caching of DOCSIS configuration files by cable modems that are only semi-compliant
with the DOCSIS specifications. You can disable this randomization of the filename by using the nocrypt
option with the cable dynamic-secret command.
• The CMTS changes the IP address of the TFTP server that the cable modem should use to the IP address
of the CMTS. This informs the cable modem that it should download its configuration file from the
CMTS.
• The CMTS downloads the original DOCSIS configuration file from the originally specified TFTP server
so that it can modify the file to use the newly generated dynamic secret.
When the cable modem downloads the DOCSIS configuration file, it receives the modified file from the
CMTS. Because this file uses the one-time-use dynamically generated shared secret, the CMTS can verify
that the cable modem is using this configuration file when it attempts to register with the CMTS.
1400
Interaction with Different Commands
Note The Dynamic Shared Secret feature does not support and is incompatible with, the use of the original shared
secret or secondary shared secrets that are configured using the cable shared-secondary-secret and cable
shared-secret commands.
Tip Although a user could attempt to circumvent these checks by downloading a DOCSIS configuration file from
a local TFTP server, the cable modem would still fail the CMTS MIC verification.
Interaction with Different Commands

The Dynamic Shared Secret feature works together with a number of other commands to ensure network
security and integrity:
• cable shared-secret—The DOCSIS specification allows service providers to use a shared-secret to
ensure that cable modems are using only authorized DOCSIS configuration files.
The Dynamic Shared Secret feature is incompatible with cable shared-secret. Do not configure the
cable shared-secret command when using the Dynamic Shared Secret feature
• cable shared-secondary-secret— The Dynamic Shared Secret feature is incompatible with cable
shared-secret. Do not configure the cable secondary-shared-secret command when using the Dynamic
Shared Secret feature
Performance Information
The Dynamic Shared Secret feature does not add any additional steps to the cable modem registration process,
nor does it add any additional requirements to the current provisioning systems. This feature can have either
a small negative or a small positive effect on the performance of the network provisioning system, depending
on the following factors:
• The provisioning system (DHCP and TFTP servers) being used
• The number of cable modems that are coming online
• The vendor and software versions of the cable modems
• The number and size of the DOCSIS configuration files
Large-scale testing has shown that the Dynamic Shared Secret feature can affect the time it takes for cable
modems to come online from 5% slower to 10% faster. The most significant factor in the performance of the
provisioning process is the provisioning system itself. For this reason, Cisco recommends using Cisco Network
Registrar (CNR) Release 3.5 or greater, which can provide significant performance improvements over generic
DHCP and TFTP servers.
The second-most important factor in the performance of cable modem provisioning is the number and size
of the DOCSIS configuration files. The size of the configuration file determines how long it takes to transmit
the file to the cable modem, while the number of configuration files can impact how efficiently the system
keeps the files in its internal cache, allowing it to reuse identical configuration files for multiple modems.
1401
SNMP Support
SNMP Support
Cisco IOS-XE 3.15.0S and later releases add the following SNMP support for the Dynamic Shared Secret
feature:
• Adds the following MIB objects to the CISCO-DOCS-EXT-MIB:
• cdxCmtsCmDMICMode—Sets and shows the configuration of the Dynamic Shared Secret feature
for a specific cable modem (not configured, mark, lock, or reject).
• cdxCmtsCmDMICLockQoS—Specifies the restrictive QoS profile assigned to a cable modem that
has failed the Dynamic Shared Secret security checks, when the interface has been configured for
lock mode.
• cdxCmtsCmStatusDMICTable—Lists all cable modems that have failed the Dynamic Shared Secret
security checks.
• An SNMP trap (cdxCmtsCmDMICLockNotification) can be sent when a cable modem is locked for
failing the Dynamic Shared Secret security checks. The trap can be enabled using the snmp-server
enable traps cable dmic-lock command.
Note The DMIC lock mode is disabled during a switchover event in HCCP N+1 Redundancy.
System Error Messages

The following system error messages provide information about cable modems that have failed the CMTS
Message Integrity Check (MIC) when the Dynamic Shared Secret feature is enabled.
Message
%CBR-4-CMLOCKED
The cable modem’s DOCSIS configuration file did not contain a Message Integrity Check (MIC) value that
corresponds with the proper Dynamic Shared Secret that was used to encode it. The CMTS has, therefore,
assigned a restrictive quality of service (QoS) configuration to this cable modem to limit its access to the
network. The CMTS has also locked the cable modem so that it will remain locked in the restricted QoS
configuration until it goes offline for at least 24 hours, at which point it is permitted to reregister and obtain
normal service (assuming it is DOCSIS-compliant and using a valid DOCSIS configuration file).
This error message appears when the cable dynamic-secret lock command has been applied to a cable
interface to enable the Dynamic Shared Secret feature for the DOCSIS configuration files on that cable
interface. The cable modem has been allowed to register and come online, but with a QoS configuration that
is limited to a maximum rate of 10 kbps for both the upstream and downstream flows. Check to ensure that
this cable modem is not running old software that caches the previously used configuration file. Also check
for a possible theft-of-service attempt by a user attempting to download a modified DOCSIS configuration
file from a local TFTP server. The CM cannot reregister with a different QoS profile until it has been offline
for 24 hours, without attempting to register, or you have manually cleared the lock using the clear cable
modem lock command.
Message
%CBR-4-CMMARKED
1402
Benefits
The cable modem’s DOCSIS configuration file did not contain a Message Integrity Check (MIC) value that
corresponds with the proper dynamic shared secret that was used to encode it. The CMTS has allowed this
modem to register and come online, but has marked it in the show cable modem displays with an exclamation
point (!) so that the situation can be investigated.
This error message appears when the cable dynamic-secret mark command has been applied to a cable
interface to enable the Dynamic Shared Secret feature for the DOCSIS configuration files on that cable
interface. Check to ensure that this cable modem is not running old software that caches the previously used
configuration file. Also check for a possible theft-of-service attempt by a user attempting to download a
modified DOCSIS configuration file from a local TFTP server.
Message
%CBR-4-NOCFGFILE
The CMTS could not obtain the DOCSIS configuration file for this cable modem from the TFTP server. This
message occurs when the Dynamic Shared Secret feature is enabled on the cable interface with the cable
dynamic-secret command.
Verify that the CMTS has network connectivity with the TFTP server, and that the specified DOCSIS
configuration file is available on the TFTP server. Check that the DHCP server is correctly configured to send
the proper configuration filename in its DHCP response to the cable modem. Also verify that the DOCSIS
configuration file is correctly formatted.
This problem could also occur if the TFTP server is offline or is overloaded to the point where it cannot
respond promptly to new requests. It might also be seen if the interface between the CMTS and TFTP server
is not correctly configured and flaps excessively.
Note This error indicates a problem with the provisioning system outside of the Cisco CMTS. Disabling the Dynamic
Shared Secret feature does not clear the fault, nor does it allow cable modems to come online. You must first
correct the problem with the provisioning system.
Benefits
The Dynamic Shared Secret feature provides the following benefits to cable service providers and their partners
and customers:
Improves Network Security

Service providers do not need to worry about users discovering the shared secret value and using it to modify
DOCSIS configuration files to give themselves higher levels of service. Even if a user were to discover the
value of a dynamically generated shared secret, the user would not be able to use that shared secret again to
register.
The generic TFTP server performance and error handling on the Cisco CMTS routers has been greatly improved
to support the high performance that is required for rapidly provisioning cable modems.
Flexibility in Dealing with Possible Theft-of-Service Attempts

Service providers have the option of deciding what response to take when a DOCSIS configuration file fails
its CMTS MIC check: mark that cable modem and allow the user online, reject the registration request and
1403
Related Features
refuse to allow the user to come online until a valid DOCSIS configuration file is used, or lock the cable
modem in a restricted QoS configuration until the modem remains offline for 24 hours. Locking malicious
modems is the most effective deterrent against hackers, because it provides the maximum penalty and minimum
reward for any user attempting a theft-of-service attack.
No Changes to Provisioning System Are Needed

Service providers can use the Dynamic Shared Secret feature without changing their provisioning or
authentication systems. Existing DOCSIS configuration files can be used unchanged, and you do not need to
change any existing shared secrets.
Tip If not already done, the service provider could also install access controls that allow only the CMTS routers
to download DOCSIS configuration files from the TFTP servers.
No Changes to Cable Modems Are Needed

The Dynamic Shared Secret feature does not require any end-user changes or any changes to the cable modem
configuration. This feature supports any DOCSIS compliant cable modem.
Note The Dynamic Shared Secret feature does not affect cable modems that are already online and provisioned.
Cable modems that are already online when the feature is enabled or disabled remain online.
Simplifies Network Management

Service providers do not have to continually update the shared secrets on a cable interface whenever the files
providing premium services become widely available. Instead, providers can use the same shared secret on a
cable interface for significant periods of time, trusting in the Dynamic Shared Secret feature to provide unique,
single-use shared secrets for each cable modem.
In addition, service providers do not have to manage unique DOCSIS configuration files for each cable modem.
The same configuration file can be used for all users in the same service class, without affecting network
security.
Related Features
The following features can be used with the Dynamic Shared Secret feature to enhance the overall security
of the cable network.
• Baseline Privacy Interface Plus (BPI+) Authorization and Encryption—Provides a secure link between
the cable modem and CMTS, preventing users from intercepting or modifying packets that are transmitted
over the cable interface. BPI+ also provides for secure authorization of cable modems, using X.509
digital certificates, as well as a secure software download capability that ensures that software upgrades
are not spoofed, intercepted, or altered.
1404
How to Configure the Dynamic Shared Secret Feature
How to Configure the Dynamic Shared Secret Feature

The following sections describe how to enable and configure the Dynamic Shared Secret feature, to disable
the feature, to manually clear a lock on a cable modem, or dynamically upgrade firmware on the cable modems.
Note All procedures begin and end at the privileged EXEC prompt (“Router#”).
Enabling and Configuring the Dynamic Shared Secret Feature

This section describes how to enable and configure the Dynamic Shared Secret feature on a cable interface.

Example:
Example:
Router(config)#
Step 2 cable qos permission create

Example:
Router(config)# cable qos permission create
Example:
Router(config)#
(Optional) If you are using the lock option in Step 6, and if you are not specifying a specific QoS profile to be used, you
must allow cable modems to create their own QoS profiles.
Step 3 cable qos permission update

Example:
Router(config)# cable qos permission update
Example:
Router(config)#
(Optional) If you are using the lock option in Step 6, and if you are not specifying a specific QoS profile to be used, you
must allow cable modems to update their own QoS profiles.
Step 4 snmp-server enable traps cable dmic-lock
1405
Enabling and Configuring the Dynamic Shared Secret Feature
Example:
Router(config)# snmp-server enable traps cable dmic-lock
Example:
Router(config)#
(Optional) Enables the sending of SNMP traps when a cable modem fails a dynamic shared-secret security check.
Step 5 interface cable interface

Example:
Example:
Router(config-if)#
Enters interface configuration mode for the specified cable interface.
Step 6 cable dynamic-secret {lock [lock-qos ] | mark | reject} [nocrypt

Example:
Router(config-if)# cable dynamic-secret lock
Example:
Router(config-if)# cable dynamic-secret lock 90
Example:
Router(config-if)# cable dynamic-secret mark
Example:
Router(config-if)# cable dynamic-secret reject
Example:
Router(config-if)#
Enables the Dynamic Shared Secret feature on the cable interface and configures it for the appropriate option:
• nocrypt—(Optional) The Cisco CMTS does not encrypt the filenames of DOCSIS configuration files, but sends
the files to CMs using their original names.
• lock—Cable modems that fail the MIC verification are allowed online with a restrictive QoS profile. The cable
modems must remain offline for 24 hours to be able to reregister with a different QoS profile.
• lock-qos —(Optional) Specifies the QoS profile that should be assigned to locked cable modems. The valid range
is 1 to 256, and the profile must have already been created. If not specified, locked cable modems are assigned a
QoS profile that limits service flows to 10 kbps (requires Step 2 and Step 3).
• mark—Cable modems that fail the MIC verification are allowed online but are marked in the show cable modem
displays so that the situation can be investigated.
• reject—Cable modems that fail the MIC verification are not allowed to register.
1406
Disabling the Dynamic Shared Secret on a Cable Interface
Note Repeat Step 5 and Step 6 for each cable interface to be configured.
Step 7 end
Example:
Example:
Router#
Exits interface configuration mode and returns to privileged EXEC mode.

Note If you have enabled the optional Dynamic Message Integrity Check (DMIC), you may need to specify source
address/VRF for the cable modem configuration file downloaded from CNR to cBR8. You can do this by using
the following command:
cable dmic-src [ipv4|ipv6] <addr> [vrf <vrf-name-string>].
Example:
Router(config-if)# cable dmic-src ipv4 10.1.1.1 vrf vrf-name-1
The dmic-src configuration applies to bundle and sub-bundle. The vrf keyword is optional.
What to do next
Note If you configure the Dynamic Shared Secret feature on any interface in a cable interface bundle, you should
configure it on all interfaces in that same bundle.
Disabling the Dynamic Shared Secret on a Cable Interface

This section describes how to disable the Dynamic Shared Secret feature on a cable interface. The cable
modem continues to be validated against any shared secret or secondary shared secrets that have been defined
on the cable interface.

Example:
Example:
Router(config)#
Step 2 interface cable interface
1407
Excluding Cable Modems from the Dynamic Shared Secret Feature
Example:
Example:
Router(config-if)#
Enters interface configuration mode for the specified cable interface.
Step 3 no cable dynamic-secret

Example:
Router(config-if)# no cable dynamic-secret
Example:
Router(config-if)#
Disables the Dynamic Shared Secret feature on the cable interface.

Note Repeat Step 2 and Step 3 for each cable interface to be configured.
Step 4 end
Example:
Example:
Router#
Exits interface configuration mode and returns to privileged EXEC mode.
Excluding Cable Modems from the Dynamic Shared Secret Feature

This section describes how to exclude one or more cable modems from being processed by the Dynamic
Shared Secret feature. The cable modem continues to be validated against any shared secret or secondary
shared secrets that have been defined on the cable interface.

Example:
Step 2 cable dynamic-secret exclude {oui oui-id | modem mac-address}

Example:
Router(config)# cable dynamic-secret exclude oui 00.01.B4

Router(config)# cable dynamic-secret exclude modem 00d0.45ba.b34b
1408
Clearing the Lock on One or More Cable Modems
Excludes one or more cable modems from being processed by the Dynamic Shared Secret security checks, on the basis
of their MAC addresses or OUI values:
• modem mac-address—Specifies the hardware (MAC) address of one specific and individual cable modem to be
excluded from the Dynamic Shared Secret feature. (You cannot specify a multicast MAC address.)
• oui oui-id—Specifies the organization unique identifier (OUI) of a vendor, so that a group of cable modems from
this vendor are excluded from the Dynamic Shared Secret feature. The OUI should be specified as three hexadecimal
bytes separated by either periods or colons.
Note Repeat this command for each cable modem MAC address or OUI vendor to be excluded.
Step 3 exit
Example:
Exits the interface configuration mode and returns to privileged EXEC mode.
Clearing the Lock on One or More Cable Modems

This section describes how to manually clear the lock on one or more cable modems. This forces the cable
modems to reinitialize, and the cable modems must reregister with a valid DOCSIS configuration file before
being allowed online. If you do not manually clear the lock (using the clear cable modem lock command),
the cable modem is locked in its current restricted QoS profile and cannot reregister with a different profile
until it has been offline for at least 24 hours.
Procedure

Step 1 clear cable modem {mac-addr | ip-addr | all | ouistring | Clears the lock for the cable modems, which can be
reject} lock identified as follows:
Example: • mac-addr —Specifies the MAC address for one
particular cable modem to be cleared.
Router# clear cable modem 0001.0203.0405 lock • ip-addr —Specifies the IP address for one particular
cable modem to be cleared.
Example: • all—Clears the locks on all locked cable modems.
• oui string —Clears the locks on all cable modems with
Router# clear cable modem all lock a vendor ID that matches the specified Organizational
Unique Identifier (OUI) string.
Example: • reject—Clears the locks on all cable modems that are
currently in the reject state (which would occur if a
Router# clear cable modem oui 00.00.0C lock locked cable modem went offline and attempted to
reregister before 24 hours had elapsed).
Example:
Router#
1409
Upgrading Firmware on the Cable Modems
What to do next
Tip A cable modem can also be unlocked by manually deleting the cable modem from all CMTS internal databases,
using the clear cable modem delete command.
Upgrading Firmware on the Cable Modems

This section describes how to upgrade firmware on cable modems by dynamically inserting the correct TLV
values in the DOCSIS configuration file that is downloaded by the cable modem. The DOCSIS configuration
file contains the following TLV values:
• Software Upgrade Filename (TLV 9)—Specifies the filename of the firmware.
• Upgrade IPv4 TFTP Server (TLV21)—Specifies the IPv4 address of the TFTP server from where the
modem downloads the DOCSIS configuration file.
• Upgrade IPv6 TFTP Server (TLV58)—Specifies the IPv6 address of the TFTP server from where the
modem downloads the DOCSIS configuration file.
Note The TFTP server addresses are inserted only when the software upgrade filename (TLV9) is specified and
when the TFTP server address (TLV21/TLV58) is either not specified or set to 0.
Before you begin

The Dynamic Shared Secret feature must be enabled first before you can upgrade the firmware on cable
modems. See Enabling and Configuring the Dynamic Shared Secret Feature, on page 1405 for more information.
Note The command to enable or disable the Dynamic Shared Secret feature is available at the MAC domain level.
However, the command to upgrade the firmware on cable modems is available at the global level.
Procedure

Step 1 configure terminal Enters the global configuration mode.
Example:
Example:
Router(config)#
1410
How to Monitor the Dynamic Shared Secret Feature

Step 2 cable dynamic-secret tftp insert-upgrade-server Dynamically inserts the specific IPv4 or IPv6 TLV values
in the DOCSIS configuration file to complete firmware
Example:
upgrade on cable modems.
Router(config)# cable dynamic-secret tftp
insert-upgrade-server
Step 3 end Exits the configuration mode and returns to the privileged
EXEC mode.
Example:
Router(config)# end
Example:
Router#
What to do next
Note If you configure the Dynamic Shared Secret feature on an interface in a cable interface bundle, you should
configure it on all the interfaces of that bundle.
How to Monitor the Dynamic Shared Secret Feature

This section describes the following procedures you can use to monitor and display information about the
Dynamic Shared Secret feature:
Displaying Marked Cable Modems

When you configure a cable interface with the cable dynamic-secret mark command, cable modems that
fail the dynamically generated CMTS MIC verification are allowed online, but are marked with an exclamation
point (!) in the MAC state column in the show cable modem display. The exclamation point is also used to
identify cable modems that were initially rejected, using the cable dynamic-secret reject command, but then
reregistered using a valid DOCSIS configuration file.
For example, the following example shows that four cable modems are marked as having failed the CMTS
MIC verification, but that they have been allowed online:
Router# show cable modems
State Sid (db) Offset CPE Enb
0010.9507.01db 144.205.151.130 C5/1/0/U5 online(pt) 1 0.25 938 1 N
0080.37b8.e99b 144.205.151.131 C5/1/0/U5 online 2 -0.25 1268 0 N
0002.fdfa.12ef 144.205.151.232 C6/1/0/U0 online(pt) 13 -0.25 1920 1 N
0002.fdfa.137d 144.205.151.160 C6/1/0/U0 !online 16 -0.50 1920 1 N
1411
Displaying the Current Dynamic Secrets
0003.e38f.e9ab 144.205.151.237 C6/1/0/U0 !online 3 -0.50 1926 1 N

0003.e3a6.8173 144.205.151.179 C6/1/1/U2 offline 4 0.50 1929 0 N
0003.e3a6.8195 144.205.151.219 C6/1/1/U2 !online(pt) 22 -0.50 1929 1 N
0006.28dc.37fd 144.205.151.244 C6/1/1/U2 online(pt) 61 0.00 1925 2 N
0006.28e9.81c9 144.205.151.138 C6/1/1/U2 online(pt) 2 0.75 1925 1 N
0006.28f9.8bbd 144.205.151.134 C6/1/1/U2 online 25 -0.25 1924 1 N
0006.28f9.9d19 144.205.151.144 C6/1/1/U2 online(pt) 28 0.25 1924 1 N
0010.7bed.9b6d 144.205.151.228 C6/1/1/U2 online(pt) 59 0.25 1554 1 N
0002.fdfa.12db 144.205.151.234 C7/0/0/U0 online 15 -0.75 1914 1 N
0002.fdfa.138d 144.205.151.140 C7/0/0/U5 online 4 0.00 1917 1 N
0003.e38f.e85b 144.205.151.214 C7/0/0/U5 !online 17 0.25 1919 1 N
0003.e38f.f4cb 144.205.151.238 C7/0/0/U5 online(pt) 16 0.00 !2750 1 N
0003.e3a6.7fd9 144.205.151.151 C7/0/0/U5 online 1 0.25 1922 0 N
0020.4005.3f06 144.205.151.145 C7/0/0/U0 online(pt) 2 0.00 1901 1 N
0020.4006.b010 144.205.151.164 C7/0/0/U5 online(pt) 3 0.00 1901 1 N
0050.7302.3d83 144.205.151.240 C7/0/0/U0 online(pt) 18 -0.25 1543 1 N
00b0.6478.ae8d 144.205.151.254 C7/0/0/U5 online(pt) 44 0.25 1920 21 N
00d0.bad3.c0cd 144.205.151.149 C7/0/0/U5 online 19 0.25 1543 1 N
00d0.bad3.c0cf 144.205.151.194 C7/0/0/U0 online 13 0.00 1546 1 N
00d0.bad3.c0d5 144.205.151.133 C7/0/0/U0 online 12 0.50 1546 1 N
Router#
You can also use the show cable modem rogue command to display only those cable modems that have been
rejected for failing the dynamic shared-secret authentication checks:
Router# show cable modem rogue

Spoof TFTP
MAC Address Vendor Interface Count Dnld Dynamic Secret
AAAA.7b43.aa7f Vendor1 C4/0/U5 2 Yes 45494DC933F8F47A398F69EE6361B017
AAAA.7b43.aa7f Vendor1 C4/0/U5 2 Yes D47BCBB5494E9936D51CB0EB66EF0B0A
BBBB.7b43.aa7f Vendor2 C4/0/U5 2 No 8EB196423170B26684BF6730C099D271
AAAA.7b43.aa7f Vendor1 C4/0/U5 2 No DF8FE30203010001A326302430120603
BBBB.7b43.aa7f Vendor2 C4/0/U5 2 No 300E0603551D0F0101FF040403020106
AAAA.7b43.aa7f Vendor1 C4/0/U5 2 Yes 820101002D1A264CE212A1BB6C1728B3
DDDD.7b43.aa7f Vendor4 C4/0/U5 2 Yes 7935B694DCA90BC624AC92A519C214B9
AAAA.7b43.aa7f Vendor1 C4/0/U5 2 No 3AB096D00D56ECD07D9B7AB662451CFF
Router#

In Cisco IOS XE Everest 16.5.1, the verbose option for the show cable modem command displays the
dynamically generated shared secret (a 16-byte hexadecimal value) that was used in the cable modem’s
previous registration cycle. The display also shows if the cable modem failed the dynamic shared-secret check
or did not download the DOCSIS configuration file from the TFTP server. If a cable modem is offline, its
dynamic secret is shown as all zeros.
For example, the following example shows a typical display for a single cable modem that failed the dynamic
shared-secret check:
Router# show cable modem 00c0.73ee.bbaa verbose
MAC Address : 00c0.73ee.bbaa

IP Address : 3.18.1.6
Prim Sid : 2
Interface : C3/0/U0
Upstream Power : 0.00 dBmV (SNR = 26.92 dBmV)
Downstream Power : 0.00 dBmV (SNR = ----- dBmV)
1412

Received Power : 0.00
Provisioned Mode : DOC1.0
Capabilities : {Frag=N, Concat=N, PHS=N, Priv=BPI}
CFG Max-CPE : 1
Flaps : 26(Feb 14 02:35:39)
Dynamic Secret : A3D1028F36EBD54FDCC2F74719664D3F
Router#
The following example shows a typical display for a single cable modem that is currently offline (the Dynamic
Secret field shows all zeros):
Router# show cable modem 00C0.6914.8601 verbose
MAC Address : 00C0.6914.8601

IP Address : 10.212.192.119
Prim Sid : 6231
Interface : C5/1/0/U3
Upstream Power : 0.00 dBmV (SNR = 30.19 dBmV)
Downstream Power : 0.00 dBmV (SNR = ----- dBmV)
Received Power : !-2.25
Provisioned Mode : DOC1.0
Capabilities : {Frag=N, Concat=Y, PHS=N, Priv=BPI}
CFG Max-CPE : 4
Flaps : 20638(Feb 10 16:04:10)
Dynamic Secret : 00000000000000000000000000000000
Router#
1413
Troubleshooting Cable Modems with Dynamic Shared Secret
Note The Dynamic Secret field shown above is all zeros (“00000000000000000000000000000000”), which indicates
that this cable modem is offline.
You can also use the following command to display all the dynamically generated shared secrets that are in
use:
Router# show cable modem verbose | include Dynamic Secret
Dynamic Secret : 43433036434644344643303841313237

Dynamic Secret : 308203E0308202C8A003020102021058
Dynamic Secret : 0D06092A864886F70D01010505003081
Dynamic Secret : 3037060355040A133044617461204F76
Dynamic Secret : 20496E74657266616365205370656369
Dynamic Secret : 00000000000000000000000000000000
Dynamic Secret : 040B130C4361626C65204D6F64656D73
Dynamic Secret : 53204361626C65204D6F64656D20526F
Dynamic Secret : 7574686F72697479301E170D30313032
Dynamic Secret : 313233353935395A308197310B300906
Dynamic Secret : 0A133044617461204F76657220436162
Dynamic Secret : 66616365205370656369666963617469
Dynamic Secret : 626C65204D6F64656D73313630340603
Dynamic Secret : 65204D6F64656D20526F6F7420436572
Dynamic Secret : 747930820122300D06092A864886F70D
Dynamic Secret : 010100C0EF369D7BDAB0A938E6ED29C3
Dynamic Secret : DA398BF619A11B3C0F64912D133CFFB6
Dynamic Secret : FFAD6CE01590ABF5A1A0F50AC05221F2
Dynamic Secret : 73504BCA8278D41CAD50D9849B56552D
Dynamic Secret : 05F4655F2981E031EB76C90F9B3100D1
Dynamic Secret : F4CB0BF4A13EA9512FDE4A2A219C27E9
Dynamic Secret : D47BCBB5494E9936D51CB0EB66EF0B0A
Dynamic Secret : 8EB196423170B26684BF6730C099D271
Dynamic Secret : DF8FE30203010001A326302430120603
Dynamic Secret : 300E0603551D0F0101FF040403020106
Dynamic Secret : 820101002D1A264CE212A1BB6C1728B3
Dynamic Secret : 7935B694DCA90BC624AC92A519C214B9
Dynamic Secret : 3AB096D00D56ECD07D9B7AB662451CFF
Dynamic Secret : 92E68CFD8783D58557E3994F23A8140F
Dynamic Secret : 225A3B01DB67AF0C3637A765E1E7C329
Dynamic Secret : 2BB1E6221B6D5596F3D6F506804C995E
Dynamic Secret : 45494DC933F8F47A398F69EE6361B017
Router#
Troubleshooting Cable Modems with Dynamic Shared Secret

If a cable modem is being marked as having violated the dynamic shared secret, you can enable the following
debugs to get more information about the sequence of events that is occurring:
• debug cable mac-address cm-mac-addr verbose—Enables detailed debugging for the cable modem
with the specific MAC address.
• debug cable tlv—Displays the contents of Type/Length/Value messages that are sent during the
registration process.
• debug cable dynamic-secret—Displays debugging messages about dynamic shared secret operation.
1414
Configuration Examples for Dynamic Shared Secret
• debug tftp server events—Displays debugging messages for the major events that occur with the Cisco
CMTS router’s onboard TFTP server.
• debug tftp server packets—Displays a packet dump for the DOCSIS configuration files that the TFTP
server downloads to a cable modem.
Tip For more information about these debug commands, see the Cisco CMTS Debugging Commands chapter in
the Cisco Broadband Cable Command Reference Guide, at the following URL:
In addition, examine the messages in the router’s log buffer for any helpful information. Use the show logging
command to display the contents of the router’s logging buffer to display these messages. You can limit the
output to a specific hour and minute by using the begin output modifier. For example, to display only those
messages that were recorded at 12:10, give the following command:
Router# show logging | begin 12:10
Note The exact format for the begin output modifier depends on the timestamp you are using for your logging
buffer.
Configuration Examples for Dynamic Shared Secret

This section lists a typical configuration for the Dynamic Shared Secret feature.
Note These configurations also show a shared secret and secondary secret being configured on the cable interface.
This is optional but highly recommended, because it adds an additional layer of security during the registration
of cable modems.
Mark Configuration: Example

The following excerpt from a configuration for the cable interface on a Cisco CMTS router configures
the cable interface so that cable modems that fail the CMTS MIC check are allowed to come online,
but are marked with an exclamation point (!) in the show cable modem displays, so that the situation
can be investigated further.
interface cable c5/1/0

cable dynamic-secret mark
...
1415
Lock Configuration: Example
Lock Configuration: Example

The following excerpt from a configuration for the cable interface on a Cisco CMTS router configures
the cable interface so that cable modems that fail the CMTS MIC check are allowed to come online,
but are locked into a restrictive QoS configuration that limits the upstream and downstream service
flows to a maximum rate of 10 kbps. A locked cable modem remains locked into the restrictive QoS
configuration until the modem has remained offline for more than 24 hours, or until you have manually
cleared it using the clear cable modem lock command.
cable qos permission create

cable qos permission update
...
interface cable c3/0
cable dynamic-secret lock
...
Note If you use the lock option without specifying a specific QoS profile, you must allow cable modems
to create and update QoS profiles, using the cable qos permission command. If you do not do this
and continue to use the lock option without specifying a particular QoS profile, locked cable modems
will not be allowed to register until the lock clears or expires.
The following example is the same except that it specifies that the locked cable modem should be
assigned QoS profile 90. The cable modem remains locked with this QoS profile until the modem
has remained offline for more than 24 hours, or until you have manually cleared it using the clear
cable modem lock command. Because a specific QoS profile is specified, you do not need to use
the cable qos permission command.

cable dynamic-secret lock 90
...
Note When a locked modem is cleared, it is automatically reset so that it reregisters with the CMTS. It is
allowed online with the requested QoS parameters if it registers with a valid DOCSIS configuration
that passes the Dynamic Shared Secret checks. However, the modem is locked again if it violates
the DOCSIS specifications again.
Reject Configuration: Example

The following excerpt from a configuration for the cable interface on a Cisco CMTS configures the cable
interface so that cable modems that fail the CMTS MIC check are rejected and not allowed to register. The
cable modem must reregister using a DOCSIS configuration file with a CMTS MIC that matches one of the
shared secret or secondary secret values. When it does come online, the CMTS also prints a warning message
on the console and marks the cable modem in the show cable modem command with an exclamation point
(!), so that this situation can be investigated.
1416
Disabled Configuration: Example

cable dynamic-secret reject
...
Disabled Configuration: Example

The following excerpt from a configuration for the cable interface on a Cisco uBR7100 series router disables
the Dynamic Shared Secret feature. In this configuration, the CMTS uses the shared secret and secondary
shared secret values unchanged when verifying the CMTS MIC value for each DOCSIS configuration file.

no cable dynamic-secret
...
For additional information related to Dynamic Shared Secret, refer to the following references:
Standards
10
Standards Title

10
MIBs
11
MIBs MIBs Link
No new or modified MIB objects are supported by the To locate and download MIBs for selected
Dynamic Shared Secret feature. platforms, Cisco IOS releases, and feature sets,
use Cisco MIB Locator found at the following
• CISCO-DOCS-EXT-MIB—Includes attributes to
URL:
configure the Dynamic Shared Secret feature and to
generate traps when a cable modem fails the http://www.cisco.com/go/mibs
shared-secret security checks.
11
RFCs
12
RFCs Title
1417
Feature Information for Dynamic Shared Secret
12
Feature Information for Dynamic Shared Secret

Dynamic shared secret Cisco IOS XE Everest 16.6.1 This feature was integrated into
Broadband Router.
1418
CHAPTER 97
Lawful Intercept Architecture
The Lawful Intercept (LI) feature supports service providers in meeting the requirements of law enforcement
agencies to provide the ability to intercept Voice-over-Internet protocol (VoIP) or data traffic going through
the edge routers. This document explains LI architecture, including Cisco Service Independent Intercept
architecture and PacketCable Lawful Intercept architecture. It also describes the components of the LI feature
and provides instructions on how to configure the LI feature in your system.
Contents
• Prerequisites for Lawful Intercept, on page 1421
• Restrictions for Lawful Intercept, on page 1421
• Information About Lawful Intercept, on page 1422
• How to Configure Lawful Intercept, on page 1426
• Configuration Examples for Lawful Intercept, on page 1430
• Feature Information for Lawful Intercept, on page 1432
1419
Digital PICs:

Module:

Modules:
line card reload.
1420
Prerequisites for Lawful Intercept
Prerequisites for Lawful Intercept

Access to the Cisco LI MIB view should be restricted to the mediation device and to system administrators
who need to be aware of lawful intercepts on the router. To access the MIB, users must have level-15 access
rights on the router.
Communication with Mediation Device

For the router to communicate with the mediation device to execute a lawful intercept, the following
configuration requirements must be met:
• The domain name for both the router and the mediation device must be registered in the Domain Name
System (DNS).
In DNS, the router IP address is typically the address of the TenGigabitEthernet5/1/0 or TenGigabitEthernet4/1/0
interface (depending on the slot in which the Supervisor is installed) on the router.
• The mediation device must have an access function (AF) and an access function provisioning interface
(AFPI).
• You must add the mediation device to the Simple Network Management Protocol (SNMP) user group
that has access to the CISCO-TAP2-MIB view. Specify the username of the mediation device as the user
to add to the group.
When you add the mediation device as a CISCO-TAP2-MIB user, you can include the mediation device’s
authorization password if you want. The password must be at least eight characters in length.
Restrictions for Lawful Intercept

General Restrictions
There is no command-line interface (CLI) available to configure LI on the router. All error messages are sent
to the mediation device as SNMP notifications. All intercepts are provisioned using SNMPv3 only.
Lawful Intercept does not support SUP HA. LI configuration needs to be reapplied after SUP switchover. An
SNMP trap will be generated for this event.
Lawful Intercept MIBs

Only the mediation device and users who need to know about lawful intercepts are allowed to access the LI
MIBs.
Due to its sensitive nature, the Cisco LI MIBs are only available in software images that support the LI feature.
These MIBs are not accessible through the Network Management Software MIBs Support page (
http://www.cisco.com/public/sw-center/netmgmt/cmtk/mibs.shtml ).
SNMP Notifications
SNMP notifications for LI must be sent to User Datagram Protocol (UDP) port 161 on the mediation device,
not port 162 (which is the SNMP default).
1421
Information About Lawful Intercept
Information About Lawful Intercept

Introduction to Lawful Intercept
LI is the process by which law enforcement agencies (LEAs) conduct electronic surveillance as authorized
by judicial or administrative order. Increasingly, legislation is being adopted and regulations are being enforced
that require service providers (SPs) and Internet service providers (ISPs) to implement their networks to
explicitly support authorized electronic surveillance. The types of SPs or ISPs that are subject to LI mandates
vary greatly from country to country. LI compliance in the United States is specified by the Commission on
Accreditation for Law Enforcement Agencies (CALEA).
Cisco supports two architectures for LI: PacketCable and Service Independent Intercept. The LI components
by themselves do not ensure customer compliance with applicable regulations but rather provide tools that
can be used by SPs and ISPs to construct an LI-compliant network.
Cisco Service Independent Intercept Architecture

The Cisco Service Independent Intercept Architecture Version 3.0 document describes implementation of
LI for VoIP networks using the Cisco BTS 10200 Softswitch call agent, version 5.0, in a non-PacketCable
network. Packet Cable Event Message specification version 1.5-I01 is used to deliver the call identifying
information along with version 2.0 of the Cisco Tap MIB for call content.
LI for VoIP networks using the Cisco BTS 10200 Softswitch call agent, versions 4.4 and 4.5, in a
non-PacketCable network. Although not a PacketCable network, PacketCable Event Messages Specification
version I08 is still used to deliver call identifying information, along with version 1.0 or version 2.0 of the
Cisco Tap MIB for call content. The Cisco Service Independent Intercept Architecture Version 2.0 document
adds additional functionality for doing data intercepts by both IP address and session ID, which are both
supported in version 2.0 of the Cisco Tap MIB (CISCO-TAP2-MIB).
LI for VoIP networks that are using the Cisco BTS 10200 Softswitch call agent, versions 3.5 and 4.1, in a
non-PacketCable network. Although not a PacketCable network, PacketCable Event Message Specification
version I03 is still used to deliver call identifying information, along with version 1.0 of the Cisco Tap MIB
(CISCO-TAP-MIB) for call content. Simple data intercepts by IP address are also discussed.
PacketCable Lawful Intercept Architecture

The PacketCable Lawful Intercept Architecture for BTS Version 5.0 document describes the implementation
of LI for VoIP using Cisco BTS 10200 Softswitch call agent, version 5.0, in a PacketCable network that
conforms to PacketCable Event Messages Specification version 1.5-I01.
The PacketCable Lawful Intercept Architecture for BTS Versions 4.4 and 4.5 document describes the
implementation of LI for VoIP using Cisco BTS 10200 Softswitch call agent, versions 4.4 and 4.5, in a
PacketCable network that conforms to PacketCable Event Messages Specification version I08.
The PacketCable Lawful Intercept Architecture for BTS Versions 3.5 and 4.1 document describes the
implementation of LI for voice over IP (VoIP) using Cisco Broadband Telephony Softswitch (BTS) 10200
Softswitch call agent, versions 3.5 and 4.1, in a PacketCable network that conforms to PacketCable Event
Message Specification version I03.
1422
Cisco cBR Series Routers
The PacketCable Control Point Discovery Interface Specification document defines an IP-based protocol
that can be used to discover a control point for a given IP address. The control point is the place where Quality
of Service (QoS) operations, LI content tapping operations, or other operations may be performed.
Note The Cisco cBR router does not support PacketCable Communications Assistance for Law Enforcement Act
(CALEA).
Cisco cBR Series Routers

TheCisco cBR series router support two types of LI: regular and broadband (per-subscriber). Regular wiretaps
are executed on access subinterfaces and physical interfaces. Wiretaps are not required, and are not executed,
on internal interfaces. The router determines which type of wiretap to execute based on the interface that the
target’s traffic is using.
LI on the Cisco cBR series routers can intercept traffic based on a combination of one or more of the following
fields:
• Destination IP address and mask (IPv4 or IPv6 address)
• Destination port or destination port range
• Source IP address and mask (IPv4 or IPv6 address)
• Source port or source port range
• Protocol ID
• Type of Service (TOS)
• Virtual routing and forwarding (VRF) name, which is translated to a vrf-tableid value within the router.
• Subscriber (user) connection ID
• Cable modem
• MAC address
The LI implementation on the Cisco cBR series routers is provisioned using SNMP3 and supports the following
functionality:
• Interception of communication content. The router duplicates each intercepted packet and then places
the copy of the packet within a UDP-header encapsulated packet (with a configured CCCid). The router
sends the encapsulated packet to the LI mediation device. Even if multiple lawful intercepts are configured
on the same data flow, only one copy of the packet is sent to the mediation device. If necessary, the
mediation device can duplicate the packet for each LEA.
• Interception of IPv4, IPv4 multicast, IPv6, and IPv6 multicast flows.
• Maximum interception time—The maximum value of cTap2MediationTimeout is 260640 minutes or
181 days from the current time. The minimum value for cTap2MediationTimeout is 1 minute from the
current time.
LI includes two ways of setting a MAC-based tap:
1423
VRF Aware LI
• On CPE—Only intercepts traffic whose source or destination match the MAC address of the CPE device.
• On CM—Intercepts all of the traffic behind the CM, including the CM traffic itself. This form of intercept
might generate a lot of traffic to the mediation device.
VRF Aware LI
VRF Aware LI is the ability to provision a LI wiretap on IPv4 data in a particular Virtual Private Network
(VPN). This feature allows a LEA to lawfully intercept targeted data within that VPN. Only IPv4 data within
that VPN is subject to the VRF-based LI tap.
VRF Aware LI is available for the following types of traffic:
• ip2ip
• ip2tag (IP to MPLS)
• tag2ip (MPLS to IP)
To provision a VPN-based IPv4 tap, the LI administrative function (running on the mediation device) uses
the CISCO-IP-TAP-MIB to identify the name of the VRF table that the targeted VPN uses. The VRF name
is used to select the VPN interfaces on which to enable LI in order to execute the tap.
The router determines which traffic to intercept and which mediation device to send the intercepted packets
based on the VRF name (along with the source and destination address, source and destination port, and
protocol).
Note When using the Cisco-IP-TAP-MIB, if the VRF name is not specified in the stream entry, the global IP routing
table is used by default.
Lawful Intercept- Redundant Mediation Devices

The Cisco cBR Series Converged Broadband Routers supports replicating Lawful Intercept (LI) packets to
multiple Mediation Devices (MDs). To use this feature, multiple identical taps are configured. The Cisco cBR
Series Converged Broadband Routers support up to two identical taps to replicate to two MDs. Only MAC-
and CM-taps are supported with multiple MDs.
For a sample SNMP configuration command set to configure two identical taps to tap to two MDs, see Example:
Configuring Lawful Intercept- Redundant Mediation Devices, on page 1430.
Lawful Intercept MIBs

Due to its sensitive nature, the Cisco LI MIBs are only available in software images that support the LI feature.
These MIBs are not accessible through the Network Management Software MIBs Support page (
http://www.cisco.com/public/sw-center/netmgmt/cmtk/mibs.shtml ).
Restricting Access to the Lawful Intercept MIBs

Only the mediation device and users who need to know about lawful intercepts should be allowed to access
the LI MIBs. To restrict access to these MIBs, you must:
1424
Service Independent Intercept
1. Create a view that includes the Cisco LI MIBs.

2. Create an SNMP user group that has read-and-write access to the view. Only users assigned to this user
group can access information in the MIBs.
3. Add users to the Cisco LI user groups to define who can access the MIBs and any information related to
lawful intercepts. Be sure to add the mediation device as a user in this group; otherwise, the router cannot
perform lawful intercepts.
For more information, see the Creating a Restricted SNMP View of Lawful Intercept MIBs module.
Note Access to the Cisco LI MIB view should be restricted to the mediation device and to system administrators
who need to be aware of lawful intercepts on the router. To access the MIB, users must have level-15 access
rights on the router.
Service Independent Intercept

Cisco developed the Service Independent Intercept (SII) architecture in response to requirements that support
lawful intercept for service provider customers. The SII architecture offers well-defined, open interfaces
between the Cisco equipment acting as the content Intercept Access Point (IAP) and the mediation device.
The modular nature of the SII architecture allows the service provider to choose the most appropriate mediation
device to meet specific network requirements and regional, standards-based requirements for the interface to
the law enforcement collection function.
The mediation device uses SNMPv3 to instruct the call connect (CC) IAP to replicate the CC and send the
content to the mediation device. The CC IAP can be either an edge router or a trunking gateway for voice,
and either an edge router or an access server for data.
Note The Cisco cBR router does not support encryption of lawful intercept traffic.
To increase the security and to mitigate any SNMPv3 vulnerability, the following task is required:
Restricting Access to Trusted Hosts (without Encryption)

SNMPv3 provides support for both security models and security levels. A security model is an authentication
strategy that is set up for a user and the group in which the user resides. A security level is the permitted level
of security within a security model. A combination of a security model and a security level will determine the
security mechanism employed when handling an SNMP packet.
Additionally, the SNMP Support for the Named Access Lists feature adds support for standard named access
control lists (ACLs) to several SNMP commands.
To configure a new SNMP group or a table that maps SNMP users to SNMP views, use the snmp-server
group command in global configuration mode.
access-list my-list permit ip host 10.10.10.1

snmp-server group my-group v3 auth access my-list
1425
How to Configure Lawful Intercept
In this example, the access list named my-list allows SNMP traffic only from 10.10.10.1. This access list is
then applied to the SNMP group called my-group.
How to Configure Lawful Intercept

Although there are no direct user commands to provision lawful intercept on the router, you do need to perform
some configuration tasks, such as providing access to LI MIBs, and setting up SNMP notifications. This
section describes how to perform the required tasks:
Creating a Restricted SNMP View of Lawful Intercept MIBs

To create and assign users to an SNMP view that includes the Cisco lawful intercept MIBs, perform the steps
in this section.
Before you begin

• You must issue the commands in global configuration mode with level-15 access rights.
• SNMPv3 must be configured on the device.
Procedure

Device> enable

Example:
Step 3 snmp-server view view-name MIB-name included Creates an SNMP view that includes the CISCO-TAP2-MIB
(where exampleViewis the name of the view to create for
Example:
the MIB).
Device(config)# snmp-server view exampleView • This MIB is required for both regular and broadband
ciscoTap2MIB included lawful intercept.
Step 4 snmp-server view view-name MIB-name included Adds the CISCO-IP-TAP-MIB to the SNMP view.
Example:
Device(config)# snmp-server view exampleView

ciscoIpTapMIB included
Step 5 snmp-server view view-name MIB-name included Adds the CISCO-802-TAP-MIB to the SNMP view.
Example:
1426
Where to Go Next
Device(config)# snmp-server view exampleView

cisco802TapMIB included
Step 6 snmp-server group group-name v3 noauth read Creates an SNMP user group that has access to the LI MIB
view-name write view-name view and defines the group’s access rights to the view.
Example:
Device(config)# snmp-server group exampleGroup v3

noauth read exampleView write exampleView
Step 7 snmp-server user user-name group-name v3 auth Adds users to the specified user group.
md5 auth-password
Example:
Device(config)# snmp-server user exampleUser

exampleGroup v3 auth md5 examplePassword
Step 8 end Exits the current configuration mode and returns to

Example:
Device(config)# end
Where to Go Next
The mediation device can now access the lawful intercept MIBs and issue SNMP set and get requests to
configure and run lawful intercepts on the router. To configure the router to send SNMP notification to the
mediation device, see the Enabling SNMP Notifications for Lawful Intercept.
Enabling SNMP Notifications for Lawful Intercept

SNMP automatically generates notifications for lawful intercept events. To configure the router to send lawful
intercept notifications to the mediation device, perform the steps in this section.
Before you begin

• You must issue the commands in global configuration mode with level-15 access rights.
• SNMPv3 must be configured on the router.
SUMMARY STEPS
1. enable
3. snmp-server host ip-address community-string udp-port port notification-type
4. snmp-server enable traps snmp authentication linkup linkdown coldstart warmstart and snmp-server
enable traps rf
5. end
1427
Disabling SNMP Notifications
DETAILED STEPS

Device> enable

Example:
Step 3 snmp-server host ip-address community-string Specifies the IP address of the mediation device and the
udp-port port notification-type password-like community-string that is sent with a
notification request.
Example:
• For lawful intercept, the udp-port must be 161 and
Device(config)# snmp-server 10.2.2.1 not 162 (the SNMP default).
community-string udp-port 161 udp
Step 4 snmp-server enable traps snmp authentication linkup Configures the router to send RFC 1157 notifications to the
linkdown coldstart warmstart and snmp-server enable mediation device.
traps rf
These notifications indicate authentication failures, link
Example: status (up or down), and router restarts.
Device(config)# snmp-server enable traps snmp

authentication linkup linkdown coldstart warmstart
Device(config)# snmp-server enable traps rf

Example:
Device(config)# end
Disabling SNMP Notifications

To disable SNMP notifications on the router, perform the steps in this section.
Note To disable lawful intercept notifications, use SNMPv3 to set the CISCO-TAP2-MIB object
cTap2MediationNotificationEnable to false(2). To reenable lawful intercept notifications through SNMPv3,
reset the object to true(1).
SUMMARY STEPS
1. enable
1428
Provisioning a MAC Intercept for Cable Modems Using SNMPv3
3. no snmp-server enable traps

4. end
DETAILED STEPS

Device> enable

Example:
Step 3 no snmp-server enable traps Disables all SNMP notification types that are available on
your system.
Example:
Device(config)# no snmp-server enable traps

Example:
Device(config)# end
Provisioning a MAC Intercept for Cable Modems Using SNMPv3

1. Configure the c802tapStreamInterface object.
2. Set the following bit flags in the c802tapStreamFields object:
• dstMacAddress (bit 1)
• srcMacAddress (bit 2)
• cmMacAddress (bit 6)—The cmMacAddress bit field is newly introduced for cable modem support
and determines whether the intercept is a CPE-based or CM-based intercept.
3. Configure the following objects with the same CM MAC address value:
• c802tapStreamDestinationAddress
• c802tapStreamSourceAddress
Provisioning a MAC Intercept for a CPE Device Using SNMPv3

1. Configure the c802tapStreamInterface object.
2. Set the following bit flags in the c802tapStreamFields object:
• dstMacAddress (bit 1)
• srcMacAddress (bit 2)
1429
Configuration Examples for Lawful Intercept
3. Configure the following objects with the same CPE MAC address value:
• c802tapStreamDestinationAddress
• c802tapStreamSourceAddress
Configuration Examples for Lawful Intercept

Example: Enabling Mediation Device Access Lawful Intercept MIBs
The following example shows how to enable the mediation device to access the lawful intercept MIBs. It
creates an SNMP view (tapV) that includes four LI MIBs (CISCO-TAP2-MIB, CISCO-IP-TAP-MIB,
CISCO-802-TAP-MIB, and CISCO-USER-CONNECTION-TAP-MIB). It also creates a user group that has
read, write, and notify access to MIBs in the tapV view.
snmp-server view tapV ciscoTap2MIB included

snmp-server view tapV ciscoIpTapMIB included
snmp-server view tapV cisco802TapMIB included
snmp-server view tapV ciscoUserConnectionTapMIB included
snmp-server group tapGrp v3 noauth read tapV write tapV notify tapV
snmp-server user MDuser tapGrp v3 auth md5 MDpasswd
snmp-server engineID local 1234
Example: Configuring Lawful Intercept- Redundant Mediation Devices

Lawful Intercept is configured using SNMPv3. The following example shows SNMP configuration command
set to configure two identical taps to tap two MDs:
• Setup MD1:
setany -v3 -timeout 30 -retries 3 10.12.0.34 user1 \

cTap2MediationStatus.1 -i 4 \
cTap2MediationDestAddressType.1 -i 1 \
cTap2MediationTimeout.1 -o 07:E0:04:01:B:15:1A:0 \
cTap2MediationTransport.1 -i 1 \
cTap2MediationSrcInterface.1 -i 0 \
cTap2MediationDestAddress.1 -o 0a:0a:00:35 \
cTap2MediationDestPort.1 -g 63
• Setup CM tap:

c802tapStreamStatus.1.2 -i 4 \
c802tapStreamFields.1.2 -o 62 \
c802tapStreamInterface.1.2 -i -1 \
c802tapStreamDestinationAddress.1.2 -o "c8 fb 26 a5 55 98" \
c802tapStreamSourceAddress.1.2 -o "c8 fb 26 a5 55 98"

cTap2StreamStatus.1.2 -i 5 \
cTap2StreamType.1.2 -i 2 \
cTap2StreamInterceptEnable.1.2 -i 1 \
cTap2StreamStatus.1.2 -i 4
1430
• Setup MD2:
cTap2MediationStatus.2 -i 4 \
cTap2MediationDestAddressType.2 -i 1 \
cTap2MediationTimeout.2 -o 07:E0:03:03:7:15:1A:0 \
cTap2MediationTransport.2 -i 1 \
cTap2MediationSrcInterface.2 -i 0 \
cTap2MediationDestAddress.2 -o 0a:0a:00:06 \
cTap2MediationDestPort.2 -g 63
• Setup CM tap:
c802tapStreamStatus.2.2 -i 4 \
c802tapStreamFields.2.2 -o 62 \
c802tapStreamInterface.2.2 -i -1 \
c802tapStreamDestinationAddress.2.2 -o "c8 fb 26 a5 55 98" \
c802tapStreamSourceAddress.2.2 -o "c8 fb 26 a5 55 98"

cTap2StreamStatus.2.2 -i 5 \
cTap2StreamType.2.2 -i 2 \
cTap2StreamInterceptEnable.2.2 -i 1 \
cTap2StreamStatus.2.2 -i 4
• Get tapped packets count:

getmany -v3 -timeout 30 -retries 3 10.12.0.34 user1 \
cTap2StreamInterceptedPackets
Related Documents

Configuring SNMP Support Configuring SNMP Support
Security commands Cisco IOS Security Command Reference
Standards and RFCs
Standard/RFC Title
PacketCable™ Control Point Discovery PacketCable ™ Control Point Discovery Interface
Interface Specification Specification (PKT-SP-CPD-I02-061013)
RFC-3924 Cisco Architecture for Lawful Intercept in IP Networks
1431
Feature Information for Lawful Intercept
MIBs
MIB MIBs Link

• CISCO-TAP2-MIB To locate and download MIBs for selected platforms, Cisco IOS
releases, and feature sets, use Cisco MIB Locator found at the
• CISCO-IP-TAP-MIB following URL:
• CISCO-802-TAP-MIB http://www.cisco.com/go/mibs
• CISCO-USER-CONNECTION-TAP-MIB
Description Link
ID and password.
Feature Information for Lawful Intercept

Table 245: Feature Information for Lawful Intercept
Lawful intercept - Redundant Cisco IOS XE Everest This feature was integrated into Cisco IOS XE
mediation devices 16.6.1 Everest 16.6.1 on theCisco cBR Series
1432
CHAPTER 98
Cable Monitoring Feature for Cisco cBR Series
Routers
After you configure cable monitoring, the router forwards copies of selected packets on the cable interface to
an external LAN analyzer attached to another interface on the Cisco CMTS router. This command can help
in troubleshooting network and application problems.
Note This feature does not monitor traffic for the purpose of preventing denial-of-service attacks and other types
of network attacks. Even after configuring the cable monitoring feature, the traffic continues to its original
destination, and only copies of the selected packets are forwarded to the CALEA server or LAN analyzer.
Note This feature doesn't support line card high availability (LCHA).
Contents
• Overview of Cable Monitor Command for cBR, on page 1434
• Configuring Cable Monitoring for cBR Routers, on page 1434
• Capturing Sniffed Packets, on page 1436
• Cable Monitor Packet Struct, on page 1439
• Feature Information for Cable Monitoring, on page 1439
1433
Overview of Cable Monitor Command for cBR
Overview of Cable Monitor Command for cBR

The cable monitor command sends copies of packets for specific types of traffic that is sent over a particular
cable interface to a LAN analyzer, for use in troubleshooting network problems. This command can select
packets to be forwarded using one or more of the following parameters:
• Either incoming or outbound packets
• Packets that match a specific MAC address (source and destination)
• Packets with a specific Service ID (SID)
Packets can also be timestamped to aid in troubleshooting. The packets are then forwarded out of the specified
10 Gigabit Ethernet port to the LAN analyzer for additional analysis.
The figure below illustrates a LAN packet analyzer attached to a Fast Ethernet port in a DOCSIS two-way
configuration.
Figure 35: LAN Packet Analyzer in a DOCSIS Two-Way Configuration
Note The WAN port used for cable monitoring should be exclusively used by the LAN packet analyzer.
Configuring Cable Monitoring for cBR Routers

To enable the cable traffic monitoring feature on a particular cable interface, use the following procedure,
starting in privileged EXEC mode.
SUMMARY STEPS
1. enable
3. cable monitor
1434
Configuring Cable Monitoring for cBR Routers
4. sniff card <slot num> <ds/us> <sniff point> <filter> dest cmon-tunnel <cmon-tunnel num>
5. end
DETAILED STEPS

prompted.
Example:
Router> enable
Example:
Router#

Example:
Example:
Router(config)#
Step 3 cable monitor Enters cable monitor configuration mode.

Example:
Router(config)# cable monitor
Example:
Router(config-cable-monitor)#
Step 4 sniff card <slot num> <ds/us> <sniff point> <filter> dest Configures the card to forward the sniffed packets.
cmon-tunnel <cmon-tunnel num>
• slot number—Slot number of the line card
Example:
• ds/us—Downstream or upstream
Downstream traffic: For each channel
• sniff point—Sniff point in downstream or upstream
Router(config-cable-monitor)sniff card 3 outbound
docsis integrated-Cable 3/0/0:0 dest cmon-tunnel FPGA (field-programmable gate array)
3
• filter—Packet type filter
Example:
• dest cmon-tunnel—Cable monitor tunnel for captured
Downstream traffic: For each wideband channel
packets
pre-docsis wideband-Cable 3/0/0:0 dest cmon-tunnel • cmon-tunnel num—Cable monitor tunnel number for
3 capture packets
Example:
Downstream traffic: For each MAC address
docsis mac-address 0100.5e01.0101 dest cmon-tunnel
3
Example:
Upstream traffic: For each channel
1435
Capturing Sniffed Packets

Router(config-cable-monitor)# sniff card 3 incoming
post-docsis upstream-cable 3/0/0 us-channel 0 dest

cmon-tunnel 3
Example:
Upstream traffic: For each MAC address (cable modem or
CPE)
Router(config-cable-monitor)#sniff card 3 incoming
post-docsis mac-address e448.c70c.9c27 dest

cmon-tunnel 3
Example:
Upstream traffic: For MD/SID
Router(config-cable-monitor)#sniff card 3 incoming
post-docsis cable 3/0/0 sid 12 upstream 0 dest

cmon-tunnel 3
Step 5 end Exits global configuration mode.

Example:
Router(config)# end
Example:
Router#
What to do next
You can capture and forward the sniffed packets to an external server or a local hard disk. For more details,
see Capturing Sniffed Packets, on page 1436.
Capturing Sniffed Packets

To forward the captured traffic to an external server, you should configure a tunnel. The external server might
not be directly connected and can be away from CMTS.
To capture sniffed packets, you can follow one of these procedures:
• Capture output packets using an external host
• Capture packets by locating the hard disk
Capturing Sniffed Packets on an External Host

To forward the captured traffic to an external server, you should configure a tunnel. The external server might
not be directly connected and can be away from CMTS.
1436
Capturing Sniffed Packets on a Local Hard Drive
SUMMARY STEPS
2. interface cmon-tunnel number
3. tunnel destination IP address, tunnel source IP address
4. end
DETAILED STEPS

Example:
Example:
Router(config)#
Step 2 interface cmon-tunnel number Enters the interface cmon-tunnel mode to capture sniffed
packets.
Example:
Router(config)# interface CMON-Tunnel 3
Router(config-if)#
Step 3 tunnel destination IP address, tunnel source IP address Configures destination IP address and the source IP address
for an external host to capture output packets.
Example:
Router(config-if)#tunnel destination 10.10.21.11
Router(config-if)#tunnel source 10.10.21.1

Example:
Router(config)# end
Example:
Router#

To forward the captured traffic to a local hard disk, use the following procedure.
SUMMARY STEPS
2. interface cmon-tunnel number
3. mode buffer
4. end
5. show platform software interface fp active name-string CMON-Tunnel number
6. test platform hardware qfp active feature docsis cmon-copy 3 QFP_ID
1437
DETAILED STEPS

Example:
Router#configure CMON-Tunnel 3
Example:
Router(config)#
Step 2 interface cmon-tunnel number Enters the interface cmon-tunnel mode.

Example:
Router(config)#interface CMON-Tunnel 3
Router(config-if)#
Step 3 mode buffer Enables mode buffer in the cmon-tunnel to capture packets
by locating the hard disk.
Example:
Router(config-if)#mode buffer

Example:
Router#
Step 5 show platform software interface fp active name-string Gets the QFP ID.
CMON-Tunnel number
Example:
Router# show platform software interface fp active
name-string CMON-Tunnel3
Name: CMON-Tunnel3, ID: 131074, QFP ID: 11745,
Schedules: 0
Type: CABLE-MONITOR, State: enabled, SNMP ID: 0,
MTU: 0
IP Address: 0.0.0.0
IPV6 Address: ::
Flags: unknown
ICMP Flags: unreachables, no-redirects,
no-info-reply, no-mask-reply
ICMP6 Flags: unreachables, no-redirects
SMI enabled on protocol(s): UNKNOWN
Authenticated-user:
FRR linkdown ID: 65535
Monitor Type: 0, Instance ID: 3, Mode: 3
Monitor Tunnel Source: 0.0.0.0, Destination:
0.0.0.0
vNet Name: , vNet Tag: 0, vNet Extra Information:
0
Dirty: unknown
AOM dependency sanity check: PASS
AOM Obj ID: 24094
Step 6 test platform hardware qfp active feature docsis Uses the QFP ID to copy the buffer to the harddisk.
cmon-copy 3 QFP_ID
1438
Cable Monitor Packet Struct

Example:
Router# test platform hardware qfp active feature
docsis cmon-copy 3 11745
Router #dir harddisk: | in CMON
50 -rw- 24 Mar 5 2020 12:33:42
+02:00 CMON_3_20200305-123342.pcap
Cable Monitor Packet Struct

The cable monitor packet struct is described as follows:
• For post-docsis and pre-docsis sniffer points: Internal Header (16 Bytes) + Ethernet Header
• For docsis sniffer point: Internal Header (16 Bytes) + Docsis Header + Ethernet Header
If remove-jib is configured under CMON-Tunnel interface, the packets will not contain Internal Header.
Feature Information for Cable Monitoring

Table 246: Feature Information for Cable Monitoring
Cable Cisco IOS XE Everest This feature was integrated into Cisco IOS XE Everest 16.6.1
Monitoring 16.6.1 on theCisco cBR Series Converged Broadband Routers.
1439
Feature Information for Cable Monitoring
1440
CHAPTER 99
Source-Based Rate Limit
The Source-Based Rate Limit (SBRL) feature prevents congestion of packets on the forwarding processor
(FP) to the Route Processor (RP) interface, which can be caused by denial of service (DoS) attacks directed
at the Cisco CMTS or by faulty hardware.
Contents
• Prerequisites for Source-Based Rate Limit, on page 1442
• Restrictions for Source-Based Rate Limit, on page 1443
• Information About Source-Based Rate Limit, on page 1443
• How to Configure Source-Based Rate Limit, on page 1443
• Verifying the Source-Based Rate Limit Configuration, on page 1451
• Configuration Example for Source-Based Rate Limit, on page 1455
• Default SBRL Configuration, on page 1456
• Conversion of SBRL Subscriber-side Configuration from 16.8.x to 16.9.x, on page 1456
• Conversion of Divert Rate Limit Configuration on the Cisco uBR10012 Router to SBRL Configuration
on the Cisco cBR Series Routers, on page 1457
• Feature Information for Source-Based Rate Limit, on page 1460
1441
Prerequisites for Source-Based Rate Limit
Digital PICs:

Module:

Modules:
line card reload.
Prerequisites for Source-Based Rate Limit

• You must configure Control-Plane Policing (CoPP) for WAN-side SBRL.
1442
Restrictions for Source-Based Rate Limit
Restrictions for Source-Based Rate Limit

• WAN-IP and Subscriber MAC address entities are identified using a hash, and hash collisions can occur
between two (or more) entities.
• On the WAN-side there is no special processing for hash collisions. Sources that hash-collide are
rate-limited as if they are the same source.
• The QOS group 99 is reserved for SBRL and cannot be used for other class maps.
Information About Source-Based Rate Limit

Source-Based Rate Limit (SBRL) feature operates on the punt path in CPP. SBRL identifies and rate-limits
the packet streams that can overload the punt path or RP.
Punted packets are sent from the FP to the RP through the FP-to-RP queues. Denial of service (DoS) can
occur when:
• The FP-to-RP queues are congested
• The RP cannot process punted packets fast enough
In both cases, the valid punted packets are not processed properly. These situations can be caused deliberately
by DoS attacks or by faulty external hardware.
Packet streams identified by SBRL are rate-limited according to configured parameters. Rate-limiting occurs
in CPP before the packets reach the FP-to-RP queues. This protects the RP, and also allows other valid punted
packets to reach the RP.
SBRL has a separate configuration for the WAN-side and the subscriber-side. WAN-side SBRL is disabled
by default. Subscriber-side SBRL has default settings.
WAN-Side Source-Based Rate Limit

WAN-side SBRL uses Control Plane Policing (CoPP). CoPP specifies the WAN-side packet streams that are
directed for SBRL. Both trusted and untrusted sites can be specified using CoPP. Using CoPP, you can specify
unlimited trusted sites. Access control list (ACL) is used to specify the trusted sites.
Subscriber-Side Source-Based Rate Limit

All subscriber-side punts are processed by subscriber-side SBRL. Note that the CoPP processes all punted
packets, but there is no dependency between CoPP and subscriber-side SBRL.
How to Configure Source-Based Rate Limit

1443
Configuring WAN-Side Source-Based Rate Limit
Configuring WAN-Side Source-Based Rate Limit

You must enable WAN-side SBRL in two parts:
1. Configure Control Plane Policing (CoPP) to specify which packets are subject to SBRL.
2. Configure WAN-side SBRL to set the rate-limiting parameters for the specified punt-causes.
In the CoPP policy map, the special action set qos-group 99 denotes that the packets matching a particular
class are subject to WAN-side SBRL. This means that the QOS group 99 is globally reserved for SBRL, and
must not be used in other policy-maps.
Packets matching a class without set qos-group 99 bypass WAN-side SBRL. This means that CoPP is also
used to specify trusted traffic streams that are not subject to WAN-side SBRL.
All punted packets are subject to CoPP. So, you must ensure that subscriber-side traffic does not match a
trusted class.
WAN-side SBRL identifies traffic streams by hashing the punt cause, VRF index, and source IP address. This
value is used as the index for rate-limiting. The router does not perform special processing for hash collisions,
so hash-colliding streams are treated as if they are from the same stream.
By default, WAN-side SBRL is disabled.
Restrictions
• All the punted packets are subject to CoPP and punt-policing.
Configuring Control Plane Policing

Punted packets matching the trusted class bypass WAN-side SBRL. The rest of the WAN-side punts are sent
to WAN-side SBRL.
Note The following example shows a simple trusted class.
Procedure

Example: • Enter your password, if prompted.
Router> enable

Example:
Step 3 access-list access-list-number permit protocol {any | Configures an access list for filtering frames by protocol
host {address | name}} {any | host {address | name}} type.
tos tos
1444
Configuring Control Plane Policing

Example: Note Since all the punted packets are subject to
Router(config)# access-list 130 permit ip CoPP, you must ensure that subscriber-side
192.168.1.10 0.0.0.0 192.168.1.11 0.0.0.0 tos 4 traffic does not match a trusted class.
Step 4 class-map class-map-name Creates a class-map and enters QoS class-map

configuration mode.
Example:
Router(config)# class-map match-all
sbrl_v4_trusted
Step 5 match access-group access-list-index Specifies access groups to apply to an identity policy. The
range of is from 1 to 2799.
Example:
Step 6 exit Exits QoS class-map configuration mode and returns to

global configuration mode.
Example:
Step 7 policy-map policy-map-name Specifies a service policy and enters QoS policy-map
configuration mode.
Example:
Router(config)# policy-map copp_policy
Step 8 class class-map-name Enters QoS policy-map class configuration mode.

Example:
Router(config)# class sbrl_v4_trusted
Step 9 police rate units pps conform-action action Polices traffic destined for the control plane at a specified
exceed-action action rate.
Example: Note The rate is irrelevant if both the configured
Router(config-pmap-c)# police rate 1000 pps actions are transmit.
conform-action transmit exceed-action transmit
Step 10 exit Exits policy-map class police configuration mode

Example:
Step 11 class class-default Specifies the action to take on the packets that do not match
any other class in the policy map.
Example:
Router(config-pmap)# class class-default
Step 12 set qos-group 99 Enables WAN-side SBRL for the packets that match this
class.
Example:
Router(config-pmap-c)# set qos-group 99
Step 13 exit Exits policy-map class configuration mode

Example:
1445
Enabling WAN-Side Source-Based Rate Limit

Step 14 exit Exits policy-map configuration mode

Example:
Router(config-pmap)# exit
Step 15 control-plane [host | transit | cef-exception] Associates or modifies attributes (such as a service policy)
that are associated with the control plane of the router and
Example:
enters control plane configuration mode.
Router(config)# control-plane
Step 16 service-policy {input | output} policy-map-name Attaches a policy map to a control plane.
Example:
Router(config-cp)# service-policy input
copp_policy
Step 17 end Exits control plane configuration mode and returns to

Example:
Router(config-cp)# end
Enabling WAN-Side Source-Based Rate Limit
Procedure

Router> enable

Example:
Step 3 platform punt-sbrl wan punt-cause punt-cause Configures WAN-side rate limit.
rate-per-1-sec rate
• punt-cause punt-cause—Specifies the punt-cause
Example: value in number 1 to 107 or string.
Router(config)# platform punt-sbrl wan punt-cause
• rate-per-1-sec rate—Specifies the rate in packets per
10 rate-per-1-sec 4
second. The range is from 1 to 256, specified in
powers-of-2.
Configuring WAN-Side Quarantine

The WAN-side quarantine extends the WAN-side SBRL configuration. When a traffic stream enters quarantine,
all punted packets in the stream are dropped for the configured period.
1446
Configuring Subscriber-Side Source-Based Rate Limit
Procedure

Router> enable

Example:
Step 3 platform punt-sbrl wan punt-cause punt-cause Configures quarantine for the WAN-side packet stream.
rate-per-1-sec rate quarantine-time time burst-factor
• punt-cause punt-cause—Specifies the punt-cause
burst-factor
value in number 1 to 107 or string.
Example:
• rate-per-1-sec rate—Specifies the rate limit in
Router(config)# platform punt-sbrl wan punt-cause
10 rate-per-1-sec 4 quarantine-time 10
packets per second. The range is from 1 to 256,
burst-factor 500 specified in powers-of-2.
• quarantine-time time—Specifies the quarantine time,
in minutes. The range is from 1 to 60.
• burst-factor burst-factor—Specifies the burst-factor,
in number of packets. The range is from 50 to 1000.
Example
When (burst-factor x rate) packets arrive at a rate faster than rate, the packet stream enters quarantine.
For example, during a DoS attack, when the following occurs:
• Punted packets from a WAN-side source are arrive at 100 packets per second.
• WAN-side SBRL is configured with a rate of 4 packets per second, quarantine time of 10
minutes, and burst-factor of 500 packets.
The packet rate is significantly higher than the configured rate. Therefore, when 2000 (4 x 500)
packets have arrived, the packet stream enters into quarantine. Quarantine is activated at 20 seconds
(2000 packets per 100 packets per second), and all punted packets from the stream are dropped for
10 minutes. After 10 minutes, the quarantine is deactivated.
The quarantine calculations restart immediately. So, if the scanning attack is continuous, quarantine
is reactivated after the next 20 seconds.

Restrictions
• All punted packets are subject to CoPP and punt-policing.
1447
• The ARP-filter handles the subscriber-side ARP packets. ARP packets are not processed by subscriber-side
SBRL.
• The maximum rate is 255. Due to this, the configured rate of 256 from 16.8.X will not transfer properly.
A new command must be entered to transfer the configuration.
Subscriber-MAC address SBRL identifies traffic streams by hashing the punt cause and the source MAC
address. The hash value is used as the index for rate-limiting. Hash-collision detection is performed so that
all traffic streams are processed separately.
Default settings for subscriber-side SBRL are listed in this topic. Using the 'no' configuration returns the rate
to the default value.
Rate-limiting is performed using a 2-color token-bucket algorithm. The rate is specified in
packets-per-4-seconds, in the range [1, 255]. This translates to a packets-per-second rate in the range [0.25,
~64]. The optional bucket-size is specified in packets, in the range [1, 255]. If not specified, then bucket-size
is set equal to rate.
The "no-drop" keyword disables rate-limiting for the specified punt-cause.
There is an optional quarantine configuration. When a traffic stream enters quarantine, all punted packets in
the stream are dropped for the configured period. A traffic stream enters quarantine when (burst-factor x rate)
packets arrive at a rate faster than rate. An example would be that of a faulty cable modem that continuously
sends DHCPv6 solicits.
• DHCPv6 solicits from the faulty cable modem arrive at 100 packets/second, and are all punted.
• Subscriber-side SBRL is configured with a rate-per-4-sec of 8 (i.e. 2 packets-per-sec), quarantine time
of 10 minutes, and burst-factor of 500 packets.
The traffic stream rate is higher than the configured rate. Therefore, when approximately 1000 (2 x 500)
packets have arrived, the traffic stream enters quarantine. The quarantine happens after about 10 seconds
(1000 packets at 100 packets per second), and all punted packets from the stream are dropped for 10 minutes.
After 10 minutes, the quarantine is deactivated. The quarantine calculations restart immediately, so if the
traffic stream remains continuous, quarantine is reactivated after the next 10 seconds.
1. enable
Router> enable
Enables privileged EXEC mode. Enter your password, if prompted.


3. platform punt-sbrl subscriber punt-causepunt-causerate-per-4-sec
rate[bucket-sizebucket-size][quarantine-timetimeburst-factorburst-factor]
Configures subscriber-MAC address SBRL.
• punt-cause punt-cause - Specifies the punt cause.
• rate-per-4-sec rate - Specifies the rate in packets per 4-seconds. The range is from 1 to 255.
• bucket-sizebucket-size – Specifies the bucket-size in packets. The range is from 1 to 255. If bucket-size
is not entered, the bucket-size is set equal to the rate.
1448
Configuring Source-Based Rate Limit Ping-Bypass
• quarantine-time time– Specifies the quarantine time, in minutes. The range is from 1 to 60.
• burst-factor burst-factor– Specifies the burst-factor, in number of packets. The range is from 50
to 1000.
Configuring Source-Based Rate Limit Ping-Bypass

Follow the steps below to configure source-based rate limit ping-bypass.
Procedure

Router> enable

Example:
Step 3 platform punt-sbrl ping-bypass Configures source-based rate limit ping-bypass.

Example:
Router(config)# platform punt-sbrl ping-bypass
Configuring SNMP RX Queuing

SNMP RX Cisco IOS XE Bengaluru This feature introduces a control plane policing queue to
queuing 17.6.1a shape incoming SNMP traffic in Cisco cBR-8 routers. It
reduces the need for SNMP poller to retransmit the polling
request in case the request is dropped when SNMP traffic
overloads the queue.
Spike in SNMP traffic leads to drops in punt-path-rate-limiting (PPRL). Cisco IOS XE Bengaluru 17.6.1a
release introduces a control plane policing queue to shape incoming SNMP traffic. It reduces the need for
SNMP poller to retransmit the polling request in case the request is dropped when SNMP traffic overloads
the queue.
This feature is disabled by default. Use the following command to configure this feature:
cable rxq snmp rate packets-per-second qlimit packets [avg-pkt-size bytes]
For example:
1449
Configuring Punt Policing
Router(config)#cable rxq snmp rate 1024 qlimit 8192 avg-pkt-size 1500

Router(config)#end
The SNMP packet rate range is 64–1024 packet/second. The queue limit range is 64–8192 packets. The
average packet size range is 95–1500 bytes, default size is 128 bytes.
Note The RXQ rate must be smaller than the punt-policer rate, so that RXQ handles the rate-limiting of SNMP
packets.
When you update the RXQ parameters, the existing queue must be empty. It results in delay before the new
queue parameters take effect.
To verify the SNMP RX queuing configuration, use the show command as shown in the following examples:
Router#show platform hardware qfp active feature docsis rxq idx 1

Idx Uidb Qid Rate(Kbps) Qlmt(Byte)
1 0x0003ed92 0x0000b3a0 12288 12288000
Router#show plat hard qfp active infra bqs queue output default interface-string RXQ0
Interface: RXQ0 QFP: 0.0 if_h: 4718 Num Queues/Schedules: 1
Queue specifics:
Index 0 (Queue ID:0xb3a0, Name: )
Software Control Info:
(cache) queue id: 0x0000b3a0, wred: 0x52783200, qlimit (bytes): 12288000
parent_sid: 0x29e23, debug_name:
sw_flags: 0x48000011, sw_state: 0x00000801, port_uidb: 257426
orig_min : 0 , min: 1228800
min_qos : 0 , min_dflt: 0
orig_max : 0 , max: 0
max_qos : 0 , max_dflt: 0
share : 1
plevel : 0, priority: 65535
defer_obj_refcnt: 0, cp_ppe_addr: 0x00000000
Statistics:
tail drops (bytes): 115203800 , (packets): 525349
total enqs (bytes): 208955400 , (packets): 1131326
queue_depth (bytes): 0
licensed throughput oversubscription drops:
(bytes): 0 , (packets): 0
Configuring Punt Policing

The punt policer aggregates all packets (both subscriber-side and WAN-side) with the specified punt cause,
and rate-limits them according to the configured parameters.
Procedure

Router> enable
1450
Verifying the Source-Based Rate Limit Configuration

Example:
Step 3 platform punt-policer {cable-snmp | punt-cause Configures punt policing.

}punt-rate [high]
• punt-cause—Specifies the punt cause value.
Example:
• cable-snmp—This is the punt-cause assigned to SNMP
Router(config)# platform punt-policer 1 10
packets destined to the CMTS.
• punt-rate—Specifies the rate in packets/second. The
range is from 10 to 300000.
• high—(Optional) Specifies that the punt policing is
performed only for high priority traffic.

• show cable dp sbrl config—Displays the SBRL configuration, including default settings. This is
equivalent to show running-config all | include punt-sbrl.
Router# show cable dp sbrl config
platform punt-sbrl wan punt-cause for-us-data rate-per-1-sec 8
platform punt-sbrl wan punt-cause glean-adj rate-per-1-sec 4 quarantine-time 10
burst-factor 1000
platform punt-sbrl subscriber punt-cause for-us-data rate-per-4-sec 32 bucket-size 32
platform punt-sbrl subscriber punt-cause for-us-ctrl rate-per-4-sec 8 bucket-size 8
platform punt-sbrl subscriber punt-cause cable-l3-mobility rate-per-4-sec 16 bucket-size
16
platform punt-sbrl subscriber punt-cause sv-match-unknown rate-per-4-sec 4 bucket-size
4
platform punt-sbrl subscriber punt-cause cable-pre-reg rate-per-4-sec 8 bucket-size 8
platform punt-sbrl subscriber punt-cause cbl-dhcpv6-solicit rate-per-4-sec 8 bucket-size
8
platform punt-sbrl subscriber punt-cause cbl-dhcpv6-req rate-per-4-sec 8 bucket-size 8
platform punt-sbrl subscriber punt-cause cbl-dhcpv6-sub rate-per-4-sec 8 bucket-size 8
platform punt-sbrl subscriber punt-cause cbl-dhcpv4-disc-req rate-per-4-sec 8 bucket-size
8
• show access-lists —Displays the access list information for verifying CoPP configuration.
Router# show access-lists

10 permit ip any any dscp af31
20 permit ip any any dscp cs2
30 permit ip any any dscp af21
40 permit ip 68.86.0.0 0.1.255.255 any
IPv6 access list TRUSTEDV6
1451
permit ipv6 2001:558::/32 any sequence 10
• show policy-map policy-map-name—Displays the information for the policy map.

Router# show policy-map copp_policy
Policy Map copp_policy

Class sbrl_trusted
police rate 1000 pps
conform-action transmit
exceed-action transmit
Class class-default
set qos-group 99
• show policy-map control-plane—Displays the control plane policy map information.

Router# show policy-map control-plane
Control Plane
Service-policy input: copp_policy
Class-map: sbrl_trusted (match-any)

0 packets, 0 bytes
5 minute offered rate 0000 bps, drop rate 0000 bps
Match: access-group 120
Match: access-group name TRUSTEDV6
police:
rate 1000 pps, burst 244 packets
conformed 0 packets, 0 bytes; actions:
transmit
exceeded 0 packets, 0 bytes; actions:
transmit
conformed 0 pps, exceeded 0 pps
Class-map: class-default (match-any)

28 packets, 4364 bytes
5 minute offered rate 0000 bps, drop rate 0000 bps
Match: any
QoS Set
qos-group 99
Marker statistics: Disabled
• show platform hardware qfp active infrastructure punt sbrl—Displays the SBRL statistics.
Router# show platform hardware qfp active infrastructure punt sbrl
SBRL statistics
Subscriber MAC-addr
drop-cnt evict-cnt quar MAC-Address ID punt-cause
-------------------------------------------------------------------------------------------
10000 10000 0 0010.88a3.0456 101 cable-l3-mobility
WAN-IPv4
1452
drop-cnt evict-cnt quar VRF cause IP-address

------------------------------------------------------
456788 456788 0 0 050 1.2.0.66
WAN-IPv6
drop-cnt evict-cnt quar VRF cause IP-address
----------------------------------------------------------------------------
129334 129334 1 0 011 3046:1829:fefb::ddd1
965 965 0 0 011 2001:420:2c7f:fc01::3
. . .
Note The value of quar is either 0 or 1. The value 1 indicates that quarantine is
activated.
Note The SBRL statistics algorithm stores the data for the worst offenders. Sources
that drop only a few packets are displayed in the table initially, but may be
overwritten if the drop-cnt does not increase continuously. The evict-cnt increases
in tandem with drop-cnt, but begins to decrease when a source is no longer being
actively rate-limited. When the evict-cnt drops below 10, the record may be
overwritten.
• show platform hardware qfp active infrastructure punt statistics type global-drop—Displays the
global punt policer statistics.
Router# show platform hardware qfp active infrastructure punt statistics type global-drop
Global Drop Statistics
Number of global drop counters = 22
Counter ID Drop Counter Name Packets

---------------------------------------------------------------------
000 INVALID_COUNTER_SELECTED 0
001 INIT_PUNT_INVALID_PUNT_MODE 0
002 INIT_PUNT_INVALID_PUNT_CAUSE 0
003 INIT_PUNT_INVALID_INJECT_CAUSE 0
004 INIT_PUNT_MISSING_FEATURE_HDR_CALLBACK 0
005 INIT_PUNT_EXT_PATH_VECTOR_REQUIRED 0
006 INIT_PUNT_EXT_PATH_VECTOR_NOT_SUPPORTED 0
007 INIT_INJ_INVALID_INJECT_CAUSE 0
008 INIT_INJ_MISSING_FEATURE_HDR_CALLBACK 0
009 PUNT_INVALID_PUNT_CAUSE 0
010 PUNT_INVALID_COMMON_HDR_VERSION 0
011 PUNT_INVALID_PLATFORM_HDR_VERSION 0
012 PUNT_PATH_NOT_INITIALIZED 0
013 PUNT_GPM_ALLOC_FAILURE 0
014 PUNT_TRANSITION_FAILURE 0
015 PUNT_DELAYED_PUNT_PKT_SB_NOT_IN_USE 0
016 PUNT_CAUSE_GLOBAL_POLICER 0
017 INJ_INVALID_INJECT_CAUSE 0
018 INJ_INVALID_COMMON_HDR_VERSION 0
019 INJ_INVALID_PLATFORM_HDR_VERSION 0
1453
020 INJ_INVALID_PAL_HDR_FORMAT 0
021 PUNT_GPM_TX_LEN_EXCEED 0
• show platform hardware qfp active infrastructure punt summary [threshold

threshold-value]—Displays the punt path rate-limiting summary.
Router# show platform hardware qfp active infrastructure punt summary
Punt Path Rate-Limiting summary statistics
Subscriber-side
ID punt cause CPP punt CoPP ARPfilt/SBRL per-cause global
------------------------------------------------------------------------------------
017 IPv6 Bad hop limit 22 0 0 0 0
050 IPv6 packet 13 0 0 0 0
080 CM not online 335 0 0 0 0
WAN-side
ID punt cause CPP punt CoPP SBRL per-cause global
------------------------------------------------------------------------------------
017 IPv6 Bad hop limit 471 0 0 0 0
018 IPV6 Hop-by-hop Options 29901 0 0 1430 0
024 Glean adjacency 111 0 0 0 0
025 Mcast PIM signaling 19 0 0 0 0
050 IPv6 packet 11 0 0 0 0
• show platform software punt-policer—Displays the punt policer configuration and statistics.
Router# show platform software punt-policer
Per Punt-Cause Policer Configuration and Packet Counters
Punt Configured (pps) Conform Packets Dropped Packets

Cause Description Normal High Normal High Normal High
-------------------------------------------------------------------------------------
2 IPv4 Options 4000 3000 0 0 0 0
3 Layer2 control and legacy 40000 10000 16038 0 0 0
4 PPP Control 2000 1000 0 0 0 0
5 CLNS IS-IS Control 2000 1000 0 0 0 0
6 HDLC keepalives 2000 1000 0 0 0 0
7 ARP request or response 2000 1000 0 49165 0 0
8 Reverse ARP request or re... 2000 1000 0 0 0 0
9 Frame-relay LMI Control 2000 1000 0 0 0 0
10 Incomplete adjacency 2000 1000 0 0 0 0
11 For-us data 40000 5000 279977 0 0 0
12 Mcast Directly Connected ... 2000 1000 0 0 0 0
. . .
• show platform hardware qfp active infrastructure punt policer summary—Displays the punt policer
summary.
Router# show platform hardware qfp active infrastructure punt policer summary
QFP Punt Policer Config Summary
1454
Configuration Example for Source-Based Rate Limit
Policer Rate PeakRate ConformBurst ExceedBurst Scaling

Handle (pps) (pps) (pps) (pps) Factor
---------------------------------------------------------------------
001 300000 0 2288 2288 0
002 4000 0 4000 0 0
003 3000 0 3000 0 0
004 40000 0 40000 0 0
005 10000 0 10000 0 0
006 2000 0 2000 0 0
007 1000 0 1000 0 0
008 2000 0 2000 0 0
009 1000 0 1000 0 0
010 2000 0 2000 0 0
011 1000 0 1000 0 0
012 2000 0 2000 0 0
013 1000 0 1000 0 0
014 2000 0 2000 0 0
. . .
Configuration Example for Source-Based Rate Limit

Example: WAN-Side SBRL Configuration
access-list 120 permit ip any any dscp af31
access-list 120 permit ip any any dscp cs2
access-list 120 permit ip 192.168.1.10 0.1.255.255 any
ipv6 access-list TRUSTEDV6

permit ipv6 any any dscp af31
permit ipv6 any any dscp cs2
permit ipv6 2001:558::/32 any
class-map match-all sbrl_trusted_v4


match access-group name TRUSTEDV6
policy-map copp_policy
! IPv4 trusted:
! Specified rate is irrelevant.
! No special action; these packets bypass WAN-side SBRL.
class sbrl_trusted_v4
police rate 1000 pps conform transmit exceed transmit
! IPv6 trusted:
! Specified rate is irrelevant.
! No special action; these packets bypass WAN-side SBRL.
! add other classes here, if necessary
! Special action to activate WAN-side SBRL for this class.

class class-default
set qos-group 99
1455
Default SBRL Configuration
control-plane
service-policy input copp_policy
platform punt-sbrl wan punt-cause for-us-data rate-per-1-sec 4

platform punt-sbrl wan punt-cause glean-adj rate-per-1-sec 4 quarantine-time 10 burst-factor
1000
Example: Subscriber-Side SBRL Configuration
platform punt-sbrl subscriber punt-cause cbl-dhcpv6-solicit rate-per-4-sec 2 bucket-size 8

platform punt-sbrl subscriber punt-cause sv-match-unknown rate-per-4-sec 4 bucket-size 10
quarantine-time 5 burst-factor 500
Default SBRL Configuration

Because of the dependency on CoPP, WAN-side SBRL is disabled by default. There is no default WAN-side
SBRL configuration.
Subscriber-side SBRL has the following default settings:
platform punt-sbrl subscriber punt-cause for-us-data rate-per-4-sec 32 bucket-size 32

platform punt-sbrl subscriber punt-cause for-us-ctrl rate-per-4-sec 8 bucket-size 8
platform punt-sbrl subscriber punt-cause cable-l3-mobility rate-per-4-sec 16 bucket-size
16
platform punt-sbrl subscriber punt-cause sv-match-unknown rate-per-4-sec 4 bucket-size 4
platform punt-sbrl subscriber punt-cause cable-pre-reg rate-per-4-sec 8 bucket-size 8
platform punt-sbrl subscriber punt-cause cbl-dhcpv6-solicit rate-per-4-sec 8 bucket-size 8
platform punt-sbrl subscriber punt-cause cbl-dhcpv6-req rate-per-4-sec 8 bucket-size 8
platform punt-sbrl subscriber punt-cause cbl-dhcpv4-disc-req rate-per-4-sec 8 bucket-size
8
Conversion of SBRL Subscriber-side Configuration from 16.8.x

to 16.9.x
In 16.9.x, several new punt-causes were added for DHCP packets on the subscriber-side. This means that the
recommended configuration for 16.8.x does not match up with the default configuration in 16.9.x.
In 16.8.x, the cable-dhcp punt-cause is used by both subscriber-side and WAN-side DHCP punts. In 16.9.x,
new punt-causes were added on the subscriber-side for DHCP packets, with the result that the cable-dhcp
punt-cause is used ONLY for WAN-side DHCP punts. This means that configuring a rate for cable-dhcp on
the subscriber-side is meaningless. The chart below shows the DHCP-related punt-causes for 16.8.x and
16.9.x. In 16.9.x, all the subscriber-side DHCP punt-causes have default SBRL settings.
1456
Conversion of Divert Rate Limit Configuration on the Cisco uBR10012 Router to SBRL Configuration on the Cisco cBR Series Routers
Table 249: 16.8.x
punt-cause Origin Description
cbl-dhcpv6-solicit sub DHCPv6 solicit
cbl-dhcpv6-req sub DHCPv6 request
cable-dhcp sub/WAN all other DHCP packets
Table 250: 16.9.x
punt-cause Origin Description
cbl-dhcpv6-solicit sub DHCPv6 solicit
cbl-dhcpv6-req sub DHCPv6 request
cbl-dhcpv6-sub sub all other (sub-side) DHCPv6

packets
cbl-dhcpv4-disc-req sub DHCPv4 discover & request
cbl-dhcpv4-sub sub all other (sub-side) DHCPv4

packets
cable-dhcp WAN all (WAN-side) DHCP packets
Conversion of Divert Rate Limit Configuration on the Cisco

uBR10012 Router to SBRL Configuration on the Cisco cBR Series
Routers
Divert Rate Limit Configuration on the Cisco uBR10012 Router
The following is a sample Divert Rate Limit (DRL) configuration on the Cisco uBR10012 router:
service divert-rate-limit ip fib_rp_glean rate 4 limit 4

service divert-rate-limit ip fib_rp_dest rate 4 limit 4
service divert-rate-limit ip fib_rp_punt rate 4 limit 4
service divert-rate-limit ipv6 ipv6_rp_dest rate 4 limit 4
service divert-rate-limit ipv6 ipv6_rp_punt rate 4 limit 4
service divert-rate-limit ipv6 ipv6_rp_glean rate 4 limit 4
service divert-rate-limit ipv6 icmpv6 rate 4 limit 4
service divert-rate-limit trusted-site 0.0.0.0 0.0.0.0 tos 0x68 mask 0xFF

service divert-rate-limit trusted-site 68.86.0.0 255.254.0.0 tos 0x0 mask 0x0
service divert-rate-limit trusted-site-ipv6 ::/0 traffic-class 0x40 mask 0xFF
1457

service divert-rate-limit trusted-site-ipv6 2001:558::/32 traffic-class 0x0 mask 0x0
interface Cablex/y/z
cable divert-rate-limit rate 4 limit 30
In Cisco IOS Release 12.2(33)SCH2, the divert-rate-limit max-rate wan command was introduced on the
Cisco uBR10012 router. This configuration limits the aggregate rate of diverted packets on the WAN-side,
on a per-divert-code basis. The following is the recommended best-practice configuration for the
divert-rate-limit max-rate wan command:
service divert-rate-limit max-rate wan fib_rp_glean rate 5000
service divert-rate-limit max-rate wan fib_rp_punt rate 5000
service divert-rate-limit max-rate wan fib_rp_dest rate 40000
service divert-rate-limit max-rate wan ipv6_fib_glean rate 5000

service divert-rate-limit max-rate wan ipv6_fib_punt rate 5000
service divert-rate-limit max-rate wan ipv6_fib_dest rate 40000
SBRL Configuration on the Cisco cBR Series Routers

The DRL functionality is called as Source-Based Rate Limit (SBRL) on the Cisco cBR Series Routers. The
punt-path has three layers of protection:
• CoPP, on page 1458
• SBRL, on page 1459
• Punt Policer, on page 1460
CoPP
CoPP is used to specify the trusted sites and activate WAN-side SBRL. However, since CoPP applies
to all punted packets, you must ensure that cable-side punts do not match the trusted sites.
The following is a sample CoPP configuration, which is equivalent to the configuration on the Cisco
uBR10012 router:
access-list 120 permit ip any any dscp cs2
access-list 120 permit ip 68.86.0.0 0.1.255.255 any
ipv6 access-list TRUSTEDV6

permit ipv6 any any dscp cs2
permit ipv6 2001:558::/32 any


match access-group name TRUSTEDV6
policy-map copp_policy
1458

class class-default
set qos-group 99
control-plane
service-policy input copp_policy
Note • The set qos-group 99 command activates SBRL for the specified class.
• The police rate for sbrl_trusted_vx is irrelevant, as both actions are set to transmit.
• You can add other trusted sites, as necessary.
SBRL
The following subscriber-side SBRL configuration is recommended. This configuration covers the
expected subscriber-side punt-causes.
platform punt-sbrl subscriber punt-cause for-us-data rate-per-4-sec 32

platform punt-sbrl subscriber punt-cause for-us-ctrl rate-per-4-sec 8
platform punt-sbrl subscriber punt-cause sv-match-unknown rate-per-4-sec 4
platform punt-sbrl subscriber punt-cause cable-pre-reg rate-per-4-sec 8
platform punt-sbrl subscriber punt-cause cable-dhcp rate-per-4-sec 8
platform punt-sbrl subscriber punt-cause cbl-dhcpv6-solicit rate-per-4-sec 8
platform punt-sbrl subscriber punt-cause cbl-dhcpv6-req rate-per-4-sec 8
The recommended subscriber-side SBRL configuration is the default configuration. All expected
subscriber-side punt-causes have default settings.
For WAN-side SBRL, the Cisco cBR Series routers do not have separate IPv4 and IPv6 configurations
as the punt causes are shared between IPv4 and IPv6. The limit cannot be configured as the hardware
policer is used. Therefore, we recommend that you configure a higher rate initially. In the following
sample configuration, glean-adj and for-us-data correspond to x_rp_glean and x_rp_dest, respectively
on the Cisco uBR 10012 router.
platform punt-sbrl wan punt-cause for-us-data rate 8

platform punt-sbrl wan punt-cause glean-adj rate 8
Note • The fib-punt punt cause is used in the Cisco uBR10012 router for packets destined to the
management Ethernet. This punt cause is not used on the Cisco cBR Series routers.
• The Cisco cBR Series routers do not have an equivalent punt cause for ICMPV6. In the Cisco
uBR10012 routers, ICMPv6 packets must be processed by the Route Processor to generate the
checksum. In the Cisco cBR Series routers, ICMPv6 is processed in the control-plane. However,
ICMPv6 punts can be identified and rate-limited (in aggregate) using CoPP.
1459
Punt Policer
The punt policer operates on all punt causes and is fully configurable. The punt policer is not divided
into WAN-side and subscriber-side. All packets with a given punt cause are aggregated and rate-limited
as configured.
Following are the default settings (best-practice configuration) for the punt policer on the Cisco cBR
Series routers:
punt-cause LO HI
CPP_PUNT_CAUSE_GLEAN_ADJ 2000 5000

CPP_PUNT_CAUSE_FOR_US 40000 5000
Note • The equivalent punt cause for fib-glean (on the Cisco uBR10012 router) is GLEAN_ADJ/HI on
the Cisco cBR Series routers.
• The equivalent punt cause for fib-dest (on the Cisco uBR10012 router) is FOR_US/LO on the
Cisco cBR Series routers.
Description Link
ID and password.
Feature Information for Source-Based Rate Limit

1460
Table 251: Feature Information for Source-Based Rate Limit
Source-based rate limit Cisco IOS XE Everest 16.6.1 This feature was integrated into Cisco IOS XE Everest
16.6.1 on theCisco cBR Series Converged Broadband
Routers.
Source-based rate limit Cisco IOS XE Gibraltar A new punt cause cable-snmp was added to rate-limit
16.12.1z1 the SNMP packets destined to the CMTS.
1461
1462
CHAPTER 100
Cable Duplicate MAC Address Reject
The Cable Duplicate MAC Address Reject feature is a DOCSIS 1.1-compliant security enhancement that
helps to eliminate denial-of-service (DOS) attacks that are caused by cloned cable modems. A clone is presumed
to be one of two physical cable modems on the same Cisco CMTS router with the same HFC interface MAC
address. The cloned cable modem may be DOCSIS 1.0 or later, and may be semi-compliant or non-compliant
with portions of the DOCSIS specifications.
Contents
• Prerequisites for Cable Duplicate MAC Address Reject, on page 1465
• Restrictions for Cable Duplicate MAC Address Reject, on page 1465
• Information About Cable Duplicate MAC Address Reject, on page 1465
• How to Configure EAE and BPI+ Enforcement Features, on page 1468
• Configuration Example for EAE and BPI+ Enforcement Policies, on page 1471
• Verifying EAE and BPI+ Enforcement Policies, on page 1471
• System Messages Supporting Cable Duplicate MAC Address Reject, on page 1472
• Feature Information for Cable Duplicate MAC Address Reject, on page 1473
1463
Digital PICs:

Module:

Modules:
line card reload.
1464
Prerequisites for Cable Duplicate MAC Address Reject
Prerequisites for Cable Duplicate MAC Address Reject

The Cable Duplicate MAC Address Reject feature entails the following behaviors and prerequisites on the
DOCSIS-compliant network:
• The Cisco CMTS router requires that the legitimate cable modem is Baseline Privacy Interface Plus
(BPI+) compliant, meaning that it can come to one of the following four online states when provisioned
with a DOCSIS configuration file containing at least one BPI+ related type, length, value (TLV). For
brevity, this document refers to these states as online(p_).
• The Cisco CMTS router gives priority to any cable modem that registers to the Cisco CMTS router in
any of the following four states:
• online(pt)
• online(pk)
• online(ptd)
• online(pkd)
The Cisco CMTS router drops registration requests from another device that purports to use the same MAC
address as an already operational modem that is in one of these four states.
Hardware Compatibility Matrix for the Cisco cBR Series Routers, on page 37 shows the hardware compatibility
prerequisites for this feature.
Note The hardware components introduced in a given Cisco IOS Release are supported in all subsequent releases
unless otherwise specified.
Restrictions for Cable Duplicate MAC Address Reject

• If the cable modem is not provisioned to use DOCSIS BPI+, as characterized by not coming online with
the above initialization states of online(p_), then the existing behavior of the Cisco CMTS router remains
unchanged. The Cisco CMTS router does not attempt to distinguish between two cable modems if the
provisioning system does not provide a DOCSIS configuration file specifying BPI+ be enabled.
• When this feature is enabled, the Cisco CMTS router issues security breach notice in a log message in
the cable logging layer2events log, or the generic log if the cable logging layer2events command is not
configured on the Cisco CMTS router.
Information About Cable Duplicate MAC Address Reject

The Cable Duplicate MAC Address Reject feature is enabled by default on the Cisco CMTS router, and has
no associated configuration commands. This feature creates a new log message, which appears in the system
log by default.
This document also describes the following security features that are associated with the Cable Duplicate
MAC Address Reject feature:
1465
Early Authentication and Encryption
Early Authentication and Encryption

The Early Authentication and Encryption (EAE) feature enables the Cisco CMTS router to authenticate
DOCSIS 3.0 cable modems immediately after completion of the ranging process, and encrypt all of the
registration packets including DHCP and TFTP traffic. This security feature, compatible only with DOCSIS
3.0 cable modems, was introduced to help multiple service operators (MSOs) prevent theft of service.
This feature is enabled only for cable modems that initialize on a downstream channel on which the Cisco
CMTS router is transmitting MAC Domain Descriptor (MDD) messages. The Cisco CMTS router uses TLV
type 6 in the MDD MAC message to signal EAE to a cable modem. If this feature is enabled, only the
authenticated cable modems are allowed to continue their initialization process and subsequently admitted to
the network. The early authentication and encryption process involves the following:
• Authentication of the cable modem (that is the BPI+ authorization exchanges) after the ranging process.
• Traffic encryption key (TEK) exchanges for the cable modem primary Security Association Identifier
(SAID).
• Encryption of IP provisioning traffic and Multipart Registration Request (REG-REQ-MP) messages
during cable modem initialization.
EAE Enforcement Policies

The Cisco CMTS router supports the following EAE enforcement policies:
• No EAE enforcement (Policy 1)—EAE is disabled and the Cisco CMTS router cannot enforce EAE on
any cable modem.
• Ranging-based EAE enforcement (Policy 2)—EAE is enforced on all DOCSIS 3.0 cable modems that
range with a B-INIT-RNG-REQ MAC message.
• Capability-based EAE enforcement (Policy 3)—EAE is enforced on all DOCSIS 3.0 cable modems that
range with a B-INIT-RNG-REQ MAC message in which the EAE capability flag is set using the .
• Total EAE enforcement (Policy 4)—EAE is enforced on all cable modems irrespective of the EAE
capability flag status.
The EAE enforcement policies are mutually exclusive. By default, EAE is disabled on the Cisco CMTS router.
EAE Exclusion
You can exclude cable modems from EAE enforcement using the cable privacy eae-exclude command in
the global configuration mode. Cable modems in the EAE exclusion list are always exempted from EAE
enforcement. You can remove cable modems from the exclusion list using the no form of the cable privacy
eae-exclude command.
BPI+ Security and Cloned Cable Modems

The BPI+ Security and Cloned Cable Modems feature prioritizes cable modems that are online with BPI+
security over new cable modem registration requests that use the same cable modem MAC address. As a
result, the legitimate cable modem with BPI+ security certificates that match the HFC MAC address does not
experience service disruption, even if a non-compliant cable modem with the same HFC MAC address attempt
to register.
The cloned cable modem detection function requires that a cable modem use DOCSIS 1.1 or a later version
and should be provisioned with BPI+ enabled. That is, one BPI+ type, length, value (TLV) must be included
in the DOCSIS configuration file. All DOCSIS 1.0, DOCSIS 1.1, and later cable modems that are provisioned
1466
Logging of Cloned Cable Modems
without DOCSIS BPI+ enabled continue to use the legacy DOCSIS behavior, and experience a DoS attack
when a cloned cable modem appears on the Cisco CMTS router.
This cloned cable modem detection function mandates that a cable modem provisioned with BPI+ and DOCSIS
1.1 QoS must register with BPI+ and not use BPI. The commonly available non-DOCSIS-compliant cable
modems contain an option to force registration in BPI as opposed to BPI+ mode even when DOCSIS 1.1 QoS
and BPI+ are specified in the DOCSIS configuration file.
Logging of Cloned Cable Modems

Cloned cable modems are detected and tracked with system logging. The Logging of Cloned Cable Modem
feature is enabled by default. Due to the large number of DOCSIS Layer 2 messages typically seen in a
production network, a separate log is available to segregate these messages. By default, cloned cable modem
messages are placed in the cable logger, cable layer2events logging. If you disable this feature using the no
form of the cable logging layer2events command in global configuration mode, then the cloned cable modem
messages are placed in the system log (syslog).
A cloned cable modem might attempt dozens of registration attempts in a short period of time. In order to
suppress the number of log messages generated, the Cisco CMTS router suppresses clone detected messages
for approximately 3 minutes under certain conditions.
The log message provides the cable interface and MAC address of the cable modem attempting to register
when another physical modem with that same MAC address is already in a state of online(p_) elsewhere on
the Cisco CMTS router.
DOCSIS 3.0 BPI+ Policy Enforcement

The DOCSIS 3.0 BPI+ Policy Enforcement feature was introduced to prevent cable modem MAC address
cloning and theft of service. This feature enables a Cisco CMTS router to validate the MAC address of each
cable modem. To enforce BPI+ on cable modems, you must configure one of the following enforcement
policies per MAC domain on the router:
• 1.1 Style Configuration File Parameters and Capability (Policy 1)—The Cisco CMTS router enforces
BPI+ on cable modems that register with a DOCSIS 1.1 configuration file with parameters indicating
BPI+ is enabled with or without TLV 29. To configure this policy, the privacy support modem capability
TLV (type 5.6) in the DOCSIS configuration file must be set to BPI+ support. This policy forces BPI+
on a cable modem that is BPI+ capable and provisioned with DOCSIS1.1 configuration file. A cable
modem that signals these capabilities during registration is blocked from accessing the network until the
modem completes BPI+ negotiation.
• 1.1 Style Configuration File Parameters (Policy 2)—The Cisco CMTS router enforces BPI+ on cable
modems that register with a DOCSIS 1.1 configuration file with parameters indicating BPI+ is enabled
with or without TLV 29. A cable modem that registers with this type of configuration file is blocked
from accessing the network until the modem completes BPI+ negotiation.
• 1.1 Style Configuration File (Policy 3)—The Cisco CMTS router enforces BPI+ on cable modems that
register with a DOCSIS 1.1 configuration file. This means that if you provision a DOCSIS 1.1
configuration file with security disabled (privacy flag is not present in the configuration file), all DOCSIS
1.1 and 2.0 cable modems are blocked from accessing the network. Only the DOCSIS 3.0 cable modems
that have security enabled implicitly will pass this check if the privacy flag is not present in the
configuration file.
• Total enforcement (Policy 4)—The Cisco CMTS router enforces BPI+ on all cable modems. This means
that all cable modems that do not run BPI+ are blocked from accessing the network.
1467
BPI+ Policy Enforcement Exclusion
Note You can configure only one enforcement policy at a time per MAC domain. If you configure one policy after
another, the latest policy supersedes the already existing policy. For example, if you want Policy 2 to take
over Policy 1, you can directly configure the former without disabling the latter.
These enforcement policies are implemented based on CableLabs Security Specification,

CM-SP-SECv3.0-I13-100611. You can configure these enforcement policies using the cable privacy
bpi-plus-policy command in cable interface configuration mode. The cable modems that do not comply with
the configured policy can still come online but they cannot access the DOCSIS network and some dual stack
cable modems may not get both the IPv4 and IPv6 addresses.
Policies 1, 2, and 3 support a mixed network of DOCSIS 1.0 (including DOCSIS Set-top Gateway), DOCSIS
1.1, and later cable modems. Policy 4 is the most effective configuration for preventing cable modem MAC
address cloning as this policy enforces BPI+ on all cable modems. Policy 4 blocks all DOCSIS 1.0 cable
modems as they do not register in BPI+ mode. Therefore, if Policy 4 is used, you must upgrade all authorized
DOCSIS 1.0 cable modems or remove them from the network.
BPI+ Policy Enforcement Exclusion

You can exclude cable modems (DOCSIS 1.0 and later versions) from BPI+ policy enforcement based on
their MAC addresses, using the cable privacy bpi-plus-exclude command in global configuration mode.
You can exclude a maximum of 30 cable modems per MAC domain.
How to Configure EAE and BPI+ Enforcement Features

This section provides information on how to configure the following BPI+ enforcement features:
Configuring EAE Enforcement Policies

By default, EAE is disabled on the Cisco CMTS router. You can configure EAE enforcement policies using
the cable privacy eae-policy command in cable interface configuration mode.
Note EAE enforcement policies are enabled only for the DOCSIS 3.0 cable modems that initialize on a downstream
channel.
Procedure

Router> enable

Example:
1468
Configuring BPI+ Enforcement Policies

Step 3 interface cable {slot/cable-interface-index | Enters interface configuration mode.

slot/subslot/cable-interface-index}
Example:
Step 4 cable privacy eae-policy {capability-enforcement | Specifies EAE enforcement policies on DOCSIS 3.0 cable
disable-enforcement | ranging-enforcement | modems.
total-enforcement}
Example:
Router(config-if)# cable privacy eae-policy

total-enforcement

Example:
Router(config)# end
Configuring BPI+ Enforcement Policies

The BPI+ enforcement policies are configured per MAC domain to prevent cable modem MAC address
cloning and theft of service.
Before you begin

The customer premise equipment (CPE) must use DHCP to acquire IP addresses to access the network, or
the statically assigned IP addresses must be managed appropriately.
Note Only a single enforcement policy can be applied per MAC domain.
Procedure

Router> enable
1469
Configuring AES-128 for non-MTC DOCSIS3.0 Cable Modem

Example:
Step 3 interface cable {slot/subslot/port |slot/port} Specifies the cable interface line card on a Cisco CMTS
router.
Example:
Step 4 cable privacy bpi-plus-policy {capable-enforcement | Specifies the BPI+ enforcement policies per MAC domain.
d11-enabled-enforcement | d11-enforcement |
total-enforcement}
Example:
Router (config-if)# cable privacy bpi-plus-policy

total-enforcement
Step 5 end Returns to Privileged EXEC mode.

Example:
Configuring AES-128 for non-MTC DOCSIS3.0 Cable Modem

This feature is enabled by default. To disable this feature, follow the steps below:
enable
configure terminal
no cable privacy non-mtc-aes128
end
Verifying AES-128 for non-MTC DOCSIS3.0 Cable Modem

To verify whether AES-128 is supported for non-MTC DOCSIS3.0 Cable Modem, use show running-config
Router# show running-config | include cable privacy non-mtc-aes128
no cable privacy non-mtc-aes128
Use the following debug commands to troubleshoot BPI+ policy enforcement configuration:
1470
Configuration Example for EAE and BPI+ Enforcement Policies
• debug cable mac-address—Provides debugging information about a specific cable modem.

• debug cable bpiatp—Enables debugging of the BPI handler.
Configuration Example for EAE and BPI+ Enforcement Policies

The following example shows how to configure an EAE enforcement policy on the Cisco cBR-8 router:

Router (config-if)# cable privacy eae-policy capability-enforcement
Router (config-if)# cable privacy eae-policy ranging-enforcement
Router (config-if)# cable privacy eae-policy total-enforcement
The following example shows how to configure a BPI+ enforcement policy at slot/subslot/port 5/1/0 on the
Cisco cBR-8 router:

Router (config-if)# cable privacy bpi-plus-policy total-enforcement
Verifying EAE and BPI+ Enforcement Policies

Use the following show commands to verify EAE and BPI+ enforcement configurations:
• show interface cable privacy
• show cable privacy
• show cable modem access-group
To verify which EAE policy is configured on the Cisco CMTS router, use the show interface cable privacy
command.
To verify which cable modems are excluded from EAE enforcement on the Cisco CMTS router, use the show
cable privacy command.
To verify BPI+ enforcement policies, use the show interface cable privacy command.
Note A character "*" is placed before the online state to identify modems that have not satisfied the bpi-plus-policy.
What to Do Next
The Cloned Cable Modem Detection feature relates to multiple BPI+ certificate and DOCSIS 1.1 factors.
1471
System Messages Supporting Cable Duplicate MAC Address Reject
System Messages Supporting Cable Duplicate MAC Address

Reject
The following example illustrates logged events for the Cloned Cable Modem Detection feature on a Cisco
cBR-8 router.
In the below scenario, there are two cable modems with MAC addresses that have been cloned:
• For MAC address 000f.66f9.48b1, the legitimate cable modem is on C5/0/0 upstream 0, and the cloned
cable modem is on C7/0/0.
• For MAC address 0013.7116.e726, the legitimate cable modem is on C7/0/0 upstream 0, and the cloned
cable modem is also on the same interface.
• In the below example, the CMMOVED message occurred because the cloned cable modem for MAC
address 000f.66f9.48b1 came online before the legitimate cable modem.
• There is no CMMOVED message for the cable modem on interface C7/0/0 with MAC address
0013.7116.e726 because the legitimate cable modem came online with state of online(pt) before the
cloned cable modem attempted to come online.
Dec 5 13:08:18: %CBR-6-CMMOVED: Cable modem 000f.66f9.48b1 has been moved from interface
Cable7/0/0 to interface C able5/0/0.
Dec 5 13:08:44: %CBR-5-CLONED_CM_DETECTED: Cloned CM with MAC address 0013.7116.e726
connection attempt rejected o n Cable7/0/0 U0
Dec 5 13:10:48: %CBR-5-CLONED_CM_DETECTED: Cloned CM with MAC address 000f.66f9.48b1
connection attempt rejected on Cable7/0/0 U1
connection attempt rejected o n Cable7/0/0 U0
The following example of the show cable modem command illustrates additional cable modem information
for the above scenario involving the specified MAC addresses:
Router# show cable modem 000f.66f9.48b1

State Sid (dBmv) Offset CPE Enb
000f.66f9.48b1 4.222.0.253 C5/0/0/U0 online(pt) 24 0.50 1045 1 Y
1472
Description Link
The Cisco Support and Documentation website provides online resources to http://www.cisco.com/cisco/
download documentation, software, and tools. Use these resources to install web/support/index.html
and configure the software and to troubleshoot and resolve technical issues
with Cisco products and technologies. Access to most tools on the Cisco
Support and Documentation website requires a Cisco.com user ID and
password.
Feature Information for Cable Duplicate MAC Address Reject

Table 253: Feature Information for Cable Duplicate MAC Address Reject
Cable Duplicate MAC Address Cisco IOS XE Everest This feature was integrated into Cisco IOS XE
Reject 16.6.1 Everest 16.6.1 on theCisco cBR Series Converged
Broadband Routers.
AES-128 for non-MTC Cisco IOS XE Everest This feature was integrated into Cisco IOS XE
DOCSIS 3.0 Cable Modem 16.6.1 Everest 16.6.1 on theCisco cBR Series Converged
Broadband Routers.
1473
Feature Information for Cable Duplicate MAC Address Reject
1474
CHAPTER 101
Cable ARP Filtering
This document describes the Cable ARP Filtering feature for the Cisco Cable Modem Termination System
(CMTS). This feature enables service providers to filter Address Resolution Protocol (ARP) requests and
reply packets, to prevent a large volume of such packets from interfering with the other traffic on the cable
network.
Contents
• Restrictions for Cable ARP Filtering, on page 1477
• Cable ARP Filtering, on page 1477
• How to Configure Cable ARP Filtering, on page 1481
• Configuration Examples for Cable ARP Filtering, on page 1490
• Feature Information for Cable ARP Filtering, on page 1493
1475
Digital PICs:

Module:

Modules:
line card reload.
1476
Restrictions for Cable ARP Filtering
Restrictions for Cable ARP Filtering

Cisco cBR-8 Router Restrictions
• The Cisco cBR-8 router maintains ARP filtering statistics on the Supervisor (SUP) module. Statistics
are viewed with the show cable arp-filter command for a specific interface. When a switchover event
occurs, as in SUP redundancy, these ARP filtering statistics are reset to zero.
• The Cable ARP filter feature is not configurable for each subinterface.
FP ARP Filter Restrictions

• The FP microcode must be enhanced to provide the rate limiting functionality for ARP filtering in FP.
• The ARP filter in FP feature is not configurable for each subinterface.
Cable ARP Filtering

Theft-of-service and denial-of-service (DNS) attacks have become increasingly common in cable broadband
networks. In addition, virus attacks are becoming more common, and users are often unaware that their
computers have become infected and are being used to continue the attacks on the network.
One sign that often appears during these attacks is an unusually high volume of Address Resolution Protocol
(ARP) packets. The user or virus repeatedly issues ARP requests, trying to find the IP addresses of additional
computers that might be vulnerable to attack.
ARP requests are broadcast packets, so they are broadcast to all devices on that particular network segment.
In some cases, a router can also forward ARP broadcasts to an ARP proxy for further processing.
This problem is also made worse because some low-end routers commonly used by subscribers for home
networks can also incorrectly respond to all ARP requests, which generates even more traffic. Until these
customer premises equipment (CPE) devices can be upgraded with firmware that is compliant to the appropriate
Request for Comments (RFC) specifications, service providers need to be able to deal with the incorrectly
generated or forwarded traffic.
In addition, the Cisco CMTS router automatically monitors ARP traffic and enters the IP addresses found in
ARP requests into its own ARP table, in the expectation that a device will eventually be found with that IP
address. Unacknowledged IP addresses remain in the router’s ARP table for 60 seconds, which means that a
large volume of ARP traffic can fill the router’s ARP table.
This process can create a large volume of ARP traffic across the network. In some situations, the volume of
ARP requests and replies can become so great that it can throttle other traffic and occupy most of the Cisco
CMTS router’s processing time, hampering efforts by technicians to recover their network.
The router cannot use fast-switching to process ARP packets, but must instead forward them to the route
processor (RP). Because of this, processing a large volume of ARP traffic can also prevent the router from
handling normal traffic.
1477
Overview
Overview
Theft-of-service and denial-of-service (DNS) attacks have become increasingly common in cable broadband
networks. In addition, virus attacks are becoming more common, and users are often unaware that their
computers have become infected and are being used to continue the attacks on the network.
One sign that often appears during these attacks is an unusually high volume of Address Resolution Protocol
(ARP) packets. The user or virus repeatedly issues ARP requests, trying to find the IP addresses of additional
computers that might be vulnerable to attack.
ARP requests are broadcast packets, so they are broadcast to all devices on that particular network segment.
In some cases, a router can also forward ARP broadcasts to an ARP proxy for further processing.
This problem is also made worse because some low-end routers commonly used by subscribers for home
networks can also incorrectly respond to all ARP requests, which generates even more traffic. Until these
customer premises equipment (CPE) devices can be upgraded with firmware that is compliant to the appropriate
Request for Comments (RFC) specifications, service providers need to be able to deal with the incorrectly
generated or forwarded traffic.
In addition, the Cisco CMTS router automatically monitors ARP traffic and enters the IP addresses found in
ARP requests into its own ARP table, in the expectation that a device will eventually be found with that IP
address. Unacknowledged IP addresses remain in the router’s ARP table for 60 seconds, which means that a
large volume of ARP traffic can fill the router’s ARP table.
This process can create a large volume of ARP traffic across the network. In some situations, the volume of
ARP requests and replies can become so great that it can throttle other traffic and occupy most of the Cisco
CMTS router’s processing time, hampering efforts by technicians to recover their network.
The router cannot use fast-switching to process ARP packets, but must instead forward them to the route
processor (RP). Because of this, processing a large volume of ARP traffic can also prevent the router from
handling normal traffic.
Filtering ARP Traffic

To control the volume of ARP traffic on a cable interface, you can configure the cable arp filter command
to specify how many ARP packets are allowed per Service ID (SID) during a user-specified time period. You
can configure separate thresholds for ARP request packets and for ARP reply packets.
When a cable interface is configured to filter ARP packets, it maintains a table of the number of ARP request
or reply packets that have been received for each SID. If a SID exceeds the maximum number of packets
during the window time period, the Cisco CMTS drops the packets until a new time period begins.
Note If using bundled cable interfaces, the Cable ARP Filtering feature is configured on the primary and subordinate
interfaces separately. This allows you to configure the feature only on the particular interfaces that require it.
In addition, you can configure the feature with different threshold values, allowing you to customize the
feature for each interface’s traffic patterns.
1478
Monitoring Filtered ARP Traffic
Monitoring Filtered ARP Traffic

After ARP filtering has been enabled on a cable interface, you can then use the service divert-rate-limit
command to display the devices that are generating excessive amounts of ARP traffic. These devices could
be generating this traffic for any of the following reasons:
• Cable modems that are running software images that are either not DOCSIS-compliant or that have been
hacked to allow theft-of-service attacks.
• CPE devices that are either performing a theft-of-service or denial-of-service attack, or that have been
infected with a virus that is searching for other computers that can be infected.
• Routers or other devices that mistakenly reply to or forward all ARP requests.
After identifying the specific devices that are generating this traffic, you can use whatever techniques are
allowed by your service level agreements (SLAs) to correct the problem.
ARP Autoreply
Built-in routers (eRouters) in cable modems, typically use the Linux operating system, which has a default
Address Resolution Protocol (ARP) refresh time of 30 or 60 seconds. With randomizing skew, the cable
bundle interface receives a unicast ARP from an eRouter approximately every 45 seconds.
Large-scale deployments may have over 20000 eRouters, which results in a steady-state ARP rate of over
400 packets per second. All ARPs are processed by the route processor (RP), consuming a significant amount
of CPU.
To reduce CPU consumption, unicast ARPs can be processed in the dataplane in certain conditions. However,
a dataplane-processed ARP does not refresh the ARP-refresh time-out that is maintained by the RP. Hence,
the dataplane must periodically punt a unicast ARP.
To achieve both, the ARP-filter feature is enabled on the subscriber-side source-based rate limit (SBRL), and
the SBRL processing for ARP is also updated for ARP autoreply functionality.
ARP autoreply is enabled by default, and the ARP-filter default setting is changed to disabled. You can revert
the configuration when required, where the ARP-filter is enabled, and both subscriber-side SBRL for ARP
and ARP autoreply are disabled.
With the ARP autoreply feature in Cisco cBR-8 router, the default configuration for ARP filter is:
(config-if)# no cable arp filter request-send
(config-if)# no cable arp filter reply-accept
Linksys Wireless-Broadband Router (BEFW11S4)

The Linksys Wireless-B Broadband Router, Model number BEFW11S4 version 4 with 1.44.2 firmware,
incorrectly sends its own ARP reply packet for every ARP request packet it receives, instead of replying only
to the ARP requests that are specifically for itself. Customers with these routers should upgrade the firmware
to the latest revision to fix this bug. To upgrade the firmware, go to the download section on the Linksys
website.
Note It is extremely important that non-compliant CPE devices be updated to firmware that correctly handles ARP
and other broadcast traffic. Even one or two non-compliant devices on a segment can create a significant
problem with dropped packets, impacting all of the other customers on that segment.
1479
ARP Filtering in FP
ARP Filtering in FP
ARP filter feature is performed on SUP FP complex. When enabled, this FP complex filters ARP packets for
identified ARP offenders, decreasing the ARP punt rate and RP CPU usage. It also provides the user with
clearer separation in ARP filtering by utilizing source MAC addresses instead of SIDs.
The filter logic now filters by source MAC address instead of by SID. Currently, the modem MAC addresses
are excluded from having their ARPs filtered, but Multimedia Terminal Adapters (MTAs) and other
non-offending CPEs can still (statistically) have ARPs filtered because all ARPs appear to come from the
same SID. Therefore, filtering by source MAC address will isolate the filtering to the offensive devices. By
doing so, a customer who has Voice-over-IP (VoIP) service via an MTA and an infected CPE will not have
MTA issues while being contacted by the service provider in regards to the infected CPE.
ARP offenders will still be allowed to use ARP to avoid complete loss of Internet connectivity through their
configured or provisioned gateway address. Because of this, it is expected that the “ARP Input” process will
still show a few percentage points of CPU usage, but the net interrupt CPU usage will decrease.
Note ARP filtering in FP is enabled by default on Cisco cBR-8 router.
Filtering ARP Traffic in FP

When ARP traffic in FP is enabled, a lightweight algorithm executing on the RP is used to identify ARP
offenders by the source MAC address or the SID. All offending source MAC addresses or SIDs are then
programmed by the ARP Filter control module into the FP ucode divert rate limiting module (ARP offenders
are still allowed to perform ARP transactions, but only at the configured filtering rate).
Offending source MAC addresses or SIDs are filtered in FP for a minimum of 50 minutes (ten 5-minute
intervals with no occurring offenses). Utilizing the existing ARP Filter CLI tools, the cable operator can obtain
enough information about the modem and CPE to contact the end user to request the necessary anti-virus
software installation or firmware upgrade for the CPE.
Note If the offending device is not “repaired” or shut off, it will remain in the FP ARP Filter indefinitely.
The FP ARP rate limiter is designed to filter a maximum of 16,000 ARP offenders. If this pool of 16,000
filterable entities is exhausted, then the entity is filtered on the RP. The CLI statistics will distinguish mac
addresses filtered on the RP verses FP.
Because of possible mac address hash collisions, ARP offenders that cannot be programmed into the FP ARP
rate limiter will still be filtered in FP by SID. Since the hash is done by source mac address and SID, such
devices can actually moved back to mac address filtering by deleting the associated modem and forcing it
back online with a new SID (this merely a possibility and is not expected to be a common practice).
ARP packets with a source mac address that is not “known” to the CMTS as a modem or CPE will be filtered
by their SID in FP. Therefore, there will never be an unusual ARP packet source that will NOT be filtered in
FP. False ARP packets with invalid operation codes will be filtered as if they are an ARP Reply.
1480
How to Configure Cable ARP Filtering
How to Configure Cable ARP Filtering

Use the following procedures to determine whether ARP filtering is required and to configure ARP filtering
on one or more cable interfaces.
Monitoring ARP Processing

Use the following steps to monitor how the router is processing ARP traffic and whether the volume of ARP
packets is a potential problem.
Step 1 To discover the CPU processes that are running most often, use the show process cpu sorted command and look for the
ARP Input process:
Example:
Router# show process cpu sorted
CPU utilization for five seconds: 99%/28%; one minute: 93%; five minutes: 90%
PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process
19 139857888 44879804 3116 31.44% 28.84% 28.47% 0 ARP Input
154 74300964 49856254 1490 20.29% 19.46% 15.78% 0 SNMP ENGINE
91 70251936 1070352 65635 8.92% 9.62% 9.59% 0 CEF process
56 17413012 97415887 178 3.01% 3.67% 3.28% 0 C10K BPE IP Enqu
78 24985008 44343708 563 3.68% 3.47% 3.24% 0 IP Input
54 6075792 6577800 923 0.90% 0.67% 0.65% 0 CMTS SID mgmt ta
...
In this example, the ARP Input process has used 31.44 percent of the CPU for the past five seconds. Total CPU utilization
is also at 99 percent, indicating that a major problem exists on the router.
Note As a general rule, the ARP Input process should use no more than one percent of CPU processing time during
normal operations. The ARP Input process could use more processing time during certain situations, such as
when thousands of cable modems are registering at the same time, but if it uses more than one percent of
processing time during normal operations, it probably indicates a problem.
Step 2 To monitor only the ARP processes, use the show process cpu | include ARP command:
Example:
Router# show process cpu | include ARP
19 139857888 44879804 3116 31.44% 28.84% 28.47% 0 ARP Input

110 0 1 0 0.00% 0.00% 0.00% 0 RARP Input
Step 3 To monitor the number of ARP packets being processed, use the show ip traffic command.
Example:
Router# show ip traffic | begin ARP
ARP statistics:
Rcvd: 11241074 requests, 390880354 replies, 0 reverse, 0 other
1481
Configure ARP Autoreply
Sent: 22075062 requests, 10047583 replies (2127731 proxy), 0 reverse
Repeat this command to see how rapidly the ARP traffic increases.
Step 4 If ARP traffic appears to be excessive, use the show cable arp-filter command to display ARP traffic for each cable
interface, to identify the interfaces that are generating the majority of the traffic.
Example:
Router# show cable arp-filter Cable5/0/0
ARP Filter statistics for Cable5/0/0:

Rcvd Replies: 177387 total, 0 unfiltered, 0 filtered
Sent Requests For IP: 68625 total, 0 unfiltered, 0 filtered
Sent Requests Proxied: 7969175 total, 0 unfiltered, 0 filtered
In the above example, the unfiltered and filtered counters show zero, which indicates that ARP filtering has not been
enabled on the cable interface. After ARP filtering has been enabled with the cable arp filter command, you can identify
the specific devices that are generating excessive ARP traffic by using the service divert-rate-limit command (see the
Identifying the Sources of Major ARP Traffic, on page 1485).

To configure ARP autoreply time and the subscriber-side SBRL, run the following command:
Router(config)# platform punt-sbrl subscriber punt-cause arp rate-per-4-sec {R}
[bucket-size {B}] [autoreply-time {T}]
To disable ARP autoreply and subscriber-side SBRL for ARP, run the following command:
Router(config)# platform punt-sbrl subscriber punt-cause arp rate-per-4-sec no-drop
Keyword Range Default Units
rate-per-4-sec {R} [1 - 255] 6 packets-per-4-sec
bucket-size {B} 1 - 255] 6 packets
autoreply-time {T} [1 - 60] 5 minutes
View SBRL Statistics

Run the following sample commands to see the SBRL statistics:
Router#show platform hardware qfp active infrastructure punt sbrl
SBRL statistics
Subscriber MAC-addr
-------------------------------------------------------------------------------------------
2 2 0 xxxx.xxxx.xxxx 103 cable-pre-reg
1482
2919265 2919265 0 xxxx.xxxx.xxxx 055 for-us-ctrl
499440 499440 0 xxxx.xxxx.xxxx 134 cbl-dhcpv4-sub
WAN-IPv4
nothing to report
WAN-IPv6
nothing to report
Router#
show platform hardware qfp active infrastructure punt sbrl
clear Clear the sbrl statistics
sub-mac-addr Show the SBRL subscriber MAC-addr statistics
threshold Show the sbrl stats gte threshold
wan-ipv4 Show the SBRL WAN IPv4 statistics
wan-ipv6 Show the SBRL WAN IPv6 statistics
| Output modifiers
<cr> <cr>
Router#show platform hardware qfp active infrastructure punt sbrl sub-mac-addr mac-address
xxxx.xxxx.xxxx
Time source is NTP, *09:47:31.486 EDT Mon Sep 13 2021
SBRL statistics
Subscriber MAC-addr
-------------------------------------------------------------------------------------------
2919324 2919324 0 xxxx.xxxx.xxxx 055 for-us-ctrl
499440 499440 0 xxxx.xxxx.xxxx 134 cbl-dhcpv4-sub
show platform hardware qfp active infrastructure punt sbrl sub-mac-addr punt-cause
<0-65535> punt-cause
Router#show platform hardware qfp active infrastructure punt sbrl sub-mac-addr punt-cause
103
Time source is NTP, *09:48:01.221 EDT Mon Sep 13 2021
SBRL statistics
Subscriber MAC-addr
-------------------------------------------------------------------------------------------
1483
Configure ARP Filter Without ARP Autoreply
Router# 103
Configure ARP Filter Without ARP Autoreply

To revert to the ARP filter configuration and disable ARP autoreply, use the following procedure:
1. Disable ARP rate-limiting in subscriber-side SBRL:
(config)# platform punt-sbrl subscriber punt-cause arp rate-per-4-sec no-drop
2. Enable ARP filter on the bundle interface:

(config-if)# cable arp filter request-send {num-pkts} {seconds}
(config-if)# cable arp filter reply-accept {num-pkts} {seconds}
Enabling ARP Filtering

Use the following procedure to enable ARP filtering on a particular cable interface.
Procedure

prompted.
Example:
Router> enable

Example:
Step 3 interface cable x/y Enters interface configuration mode for the specified cable
interface.
Example:
1484
Identifying the Sources of Major ARP Traffic

Step 4 cable arp filter reply-accept number window-size Configures the cable interface to accept only the specified
number of ARP reply packets every window-size seconds
Example:
for each active Service ID (SID) on that interface. The cable
interface drops ARP reply packets for a SID that would
Router(config-if)# cable arp filter reply-accept
2 2 exceed this number. (The default behavior is to accept all
ARP reply packets.)
Step 5 cable arp filter request-send number window-size Configures the cable interface to send only the specified
number of ARP request packets every window-size seconds
Example:
for each active SID on that interface. The cable interface
drops ARP requests for a SID that would exceed this
Router(config-if)# cable arp filter request-send
3 1 number. (The default behavior is to send all ARP request
packets.)
Note Repeat Step 3 through Step 5 to enable ARP
filtering on other cable interfaces. Primary and
subordinate interfaces in a cable bundle must be
configured separately.

EXEC mode.
Example:

After you have begun filtering ARP traffic on a cable interface, use the following procedure to identify the
cable modems or CPE devices that are generating or forwarding major amounts of ARP traffic.
Tip The Linksys Wireless-B Broadband Router, Model number BEFW11S4 version 4 with 1.44.2 firmware, has
a known problem in which it incorrectly generates an ARP reply for every ARP request packet it receives.
See the Linksys Wireless-Broadband Router (BEFW11S4) guide for information on how to resolve this
problem.
Step 1 To discover the devices that are responsible for generating or forwarding more ARP requests on a specific cable interface
than a specified minimum number of packets, use the show cable arp-filter requests-filtered command where number
is the threshold value for the number of packets being generated:
Example:
show cable arp-filter cable interface requests-filtered number
For example, to display the devices that have generated more than 100 ARP request packets, enter the following command:
Example:
1485
Router# show cable arp-filter cable 5/1/0 requests-filtered 100
Sid MAC Address IP Address Req-Filtered Req-For-IP-Filtered Rep-Filtered

1 0006.2854.72d7 10.3.81.4 12407 0 0
81 00C0.c726.6b14 10.3.81.31 743 0 0
Step 2 Repeat the show cable arp-filter command to show how quickly the devices are generating the ARP packets.
Step 3 To discover the devices that are responsible for generating or forwarding more ARP replies on a specific cable interface
than a specified minimum number of packets, use the show cable arp-filter replies-filtered command where number is
the threshold value for the number of packets being generated:
Example:
show cable arp-filter cable interface requests-filtered number
For example, to display the devices that have generated more than 200 ARP reply packets, enter the following command:
Example:
Router# show cable arp-filter cable 5/0/0 replies-filtered 200

2 0006.53b6.562f 10.11.81.16 0 0 2358
191 0100.f31c.990a 10.11.81.6 0 0 11290
Step 4 (Optional) If a particular cable modem is generating or forwarding excessive ARP replies, contact the customer to see if
they are using a Linksys Wireless-B Broadband Router, Model number BEFW11S4. If so, this router could be running
old firmware that is incorrectly generating excessive ARP packets, and the customer should upgrade their firmware. For
more information, see the Linksys Wireless-Broadband Router (BEFW11S4) guide
Step 5 Repeat this command during each filter period (the time period you entered with the cable arp filter command) to show
how quickly the devices are generating the ARP packets.
Step 6 (Optional) The ARP reply and request packet counters are 16-bit counters, so if a very large number of packets are being
generated on an interface, these counters could wrap around to zero in a few hours or even a few minutes. Clearing the
ARP counters eliminates stale information from the display and makes it easier to see the worst offenders when you
suspect ARP traffic is currently creating a problem on the network.
To eliminate the modems that are not currently triggering the ARP filters and to isolate the worst current offenders, use
the clear counters cable interface command to reset all of the interface counters to zero. Then the show cable arp-filter
commands clearly identify the SIDs of the modems that are currently forwarding the most ARP traffic.
For example, the following example indicates that a number of modems are forwarding a large enough volume of ARP
traffic that they have triggered the ARP packet filters:
Example:

1 0006.2854.72d7 10.3.81.4 8 0 0
23 0007.0e02.b747 10.3.81.31 32 0 0
57 0007.0e03.2c51 10.3.81.31 12407 0 0
...
81 00C0.c726.6b14 10.3.81.31 23 0 0
1486
SID 57 shows the largest number of packets, but it is not immediately apparent if this modem is causing the current
problems. After clearing the counters though, the worst offenders are easily seen:
Example:
Router# clear counter cable 5/1/0
Clear show interface counters on this interface [confirm] y
08:17:53.968: %CLEAR-5-COUNTERS: Clear counter on interface Cable5/1/0 by console

Router# show cable arp cable 5/1/0
ARP Filter statistics for Cable3/0:

Replies Rcvd: 0 total. 0 unfiltered, 0 filtered
Requests Sent For IP: 0 total. 0 unfiltered, 0 filtered
Requests Forwarded: 0 total. 0 unfiltered, 0 filtered


57 0007.0e03.2c51 10.3.81.31 20 0 0
81 00C0.c726.6b14 10.3.81.31 12 0 0

57 0007.0e03.2c51 10.3.81.31 31 0 0
81 00C0.c726.6b14 10.3.81.31 18 0 0
Step 7 (Optional) If the Req-For-IP-Filtered column shows the majority of ARP packets, use the show cable arp-filter
ip-requests-filtered command to display more details about the CPE device that is generating this traffic. Then use the
debug cable mac-address and debug cable arp filter commands to display detailed information about this particular
traffic; for example:
Example:
Router# show cable arp-filter c5/0/0 ip-requests-filtered 100

1 0007.0e03.1f59 50.3.81.3 0 37282 0
Router# debug cable mac-address 0007.0e03.1f59
Router# debug cable arp filter
Router#
Apr 23 23:03:23.565: ARP for IP Filter=F sid 1 s 0000.0000.0049 d 0005.00e5.3610 sip 50.3.81.13 dip
50.3.82.173 prot 6 len 46 SrcP 445 DstP 445
[additional output omitted]...
This example shows that the CPE device at IP address 50.3.81.13 is sending packets to TCP port 445 to every IP address
on the 50.3.82.0 subnet, in a possible attempt to find a computer that has Microsoft Windows file-sharing enabled.
1487
Examples
Step 8 After determining the specific devices that are generating excessive ARP traffic, you can take whatever action is allowed
by your company’s service level agreements (SLAs) to correct the problem.
Examples
In this example, two cable interfaces, C5/0/0 and C7/0/0, are joined in the same bundle, which means
the interfaces share the same broadcast traffic. Separate devices on each interface are generating
excessive ARP traffic:
• The device at MAC address 000C.2854.72D7 on interface C7/0/0 is generating or forwarding
a large volume of ARP requests. Typically, this device is a cable modem that is forwarding the
ARP requests that are being generated by a CPE device behind the modem. The CPE device
could be attempting a theft-of-service or denial-of-service attack, or it could be a computer that
has been infected by a virus and is trying to locate other computers that can be infected.
• The device at MAC address 000C.53B6.562F on Cable 5/0/0 is responding to a large number
of ARP requests, which could indicate that the device is a router that is running faulty software.
The following commands identify the device on the C7/0/0 interface that is generating the excessive
ARP requests:
Router# show cable arp-filter c7/0/0

Router# show cable arp-filter c7/0/0 requests-filtered 100

1 000C.2854.72d7 50.3.81.4 62974 0 0
The following commands identify the device on the C5/0/0 interface that is generating the excessive
ARP replies:
Router# show cable arp-filter c5/0/0

Router# show cable arp-filter c5/0/0 replies-filtered 100

2 000C.53b6.562f 50.3.81.6 0 0 2097
Clearing the Packet Counters

To clear the packet counters on an interface, which includes the ARP packet counters, use the clear counters
cable interface command. You can also clear the packet counters on all interfaces by using the clear counters
command without any options. This allows you to use the show cable arp commands to display only the CPE
devices that are currently generating the most traffic.
1488
Identifying ARP Offenders in FP
Note The clear counters command clears all of the packet counters on an interface, not just the ARP packet counters.
Identifying ARP Offenders in FP

When the FP ARP Filter feature is enabled, use the show cable arp-filter interface command to generate a
list of ARP offenders.
cBR-8 Outputs in FP
When the FP ARP Filter feature is enabled, the cBR-8 output formatting displays the modem and the CPE
addresses on a single line, in addition to the following columns:
• M/S—This column shows if packets are being filtered by MAC address or SID. A majority of these
columns will show MAC address.
• Rate—This column shows the packet rate for FP-filtered packets in the last 5 minutes monitoring time
window. Rate is not calculated for RP-filtered packets.
• Pro—This column will identify the processor that performed the filtering with either “RP” or “FP.” On
the cBR-8, it is expected that 99.9% of Pro fields will show “FP.”
The following is a sample output for an ARP request on a cBR-8 in FP:
Router# show cable arp-filter Bundle1 requests-filtered 40

Interface Cable5/0/0 - none
Interface Cable6/0/2
Sid CPE Mac CPE IP Modem MAC Modem IP M/S Rate Pro REQS
4 00d0.b75a.822a 50.3.81.56 0007.0e03.9cad 50.3.81.15 MAC - RP 46
4 00d0.b75a.822a 50.3.81.56 0007.0e03.9cad 50.3.81.15 MAC 25 FP 5012
5 00b0.d07c.e51d 50.3.81.57 0007.0e03.1f59 50.3.81.13 MAC - RP 64000
6 - - 0006.2854.7347 50.3.81.4 MAC 101 FP 5122
7 - - 0006.2854.72d7 50.3.81.11 SID - FP 961205
Interface Cable7/0/0 - none

Cisco CBR8 Configuration Guide 17.6.x

Uploaded by

Copyright:

Available Formats

Cisco CBR8 Configuration Guide 17.6.x

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Cisco CBR8 Configuration Guide 17.6.x

Uploaded by

Copyright:

Available Formats

Cisco cBR Converged Broadband Routers DOCSIS Software

Configuration Guide for Cisco IOS XE Bengaluru 17.6.x

PART I Basic Configuration 77

CHAPTER 1 Start Up Configuration of the Cisco cBR Router 1

Prerequisites for Configuring the Cisco CMTS 2

First Time Boot Up with ROMMON 3

Configure PTP Subordinate Through DPIC 11

Gigabit Ethernet Port Numbering 24

Preprovisioning the Supervisor in the Cisco cBR Chassis 29

Connecting the New Router to the Network 32

Setting Password Protection on the Cisco CMTS 33

CHAPTER 2 Cisco Smart Licensing 37

Hardware Compatibility Matrix for the Cisco cBR Series Routers 37

Out of Compliance Enforcement 40

CHAPTER 3 Core Peak Bandwidth Licensing 67

Core Peak Bandwidth License 67

CHAPTER 4 Capped License Enforcement 71

Hardware Compatibility Matrix for the Cisco cBR Series Routers 71

CHAPTER 5 Consolidated Packages and SubPackages Management 77

Finding Feature Information 77

Running the Cisco cBR Series Routers: A Summary 78

Software File Management Using Command Sets 79

Installing an Optional SubPackage 98

Upgrading Individual SubPackages 100

Installing a Patch that Affects Only Line Cards 100

Installing a Patch that Affects Only Supervisor Cards 101

Upgrading a Line Card SubPackage 101

CHAPTER 6 Support for 2x100G DPIC 109

CHAPTER 7 G.8275.2 Telecom Profile 117

G.8275.2 Telecom Profile 117

Configuring the G.8275.2 Profiles 120

CHAPTER 8 Model-Driven Telemetry 129

Configuring Telemetry using NETCONF 134

PART II High Availability Configuration 137

CHAPTER 9 Cisco IOS-XE In-Service Software Upgrade Process 139

CHAPTER 10 Supervisor Redundancy 145

Verifying Supervisor Switchover 158

Configuration Example for Supervisor Redundancy 159

CHAPTER 11 Line Card Redundancy 161

PART III Layer 2 and DOCSIS 3.0 Configuration 173

CHAPTER 12 Downstream Interface Configuration 175

Finding Feature Information 175

How to Configure Downstream Interfaces 179

Configuring the QAM Profile on the Downstream Channels 179

Configuring the Frequency Profile on the Downstream Channels 180

Configuring the Controller on the Downstream Channels 181

Troubleshooting Tips 182

Configuration Examples 183

CHAPTER 13 Upstream Interface Configuration 189

Finding Feature Information 189

Configuring the Modulation Profile and Assigning to an Upstream Channel 192

Configuring the Upstream Channel with PHY Layer 192

Configuring Upstream Channel Priority 195

CHAPTER 14 DOCSIS Interface and Fiber Node Configuration 197

Configuring DOCSIS Interfaces and Fiber Nodes 200

Service Group Profile Based Configuration 217

CHAPTER 16 DOCSIS Load Balancing Groups 227

RLBG/GLBG Assignment 231

CHAPTER 17 DOCSIS Load Balancing Movements 257

Restrictions for Dynamic Channel Change for Load Balancing 262