You are on page 1of 2062

Alcatel-Lucent

Advanced Configuration | Release 12.0 R1


Advanced Configuration Guide

93-0267-04-01

*93-0267-04-01*

Alcatel-Lucent Proprietary
This document contains proprietary information of Alcatel-Lucent and is not to be disclosed
or used except in accordance with applicable agreements.
Copyright 2014 Alcatel-Lucent. All rights reserved.

Table of Contents
Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23
About This Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23

Aggregate Route Indirect Next-Hop Option


In This Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25
Applicability. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26
Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27
Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35

Application Assurance - Application Identification and User-Defined Applications


In This Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .37
Applicability. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39
Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .41
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .70

Application Assurance Asymmetry Removal


In This Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .71
Applicability. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .72
Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .73
Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .74
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .87

Application Assurance Stateful Firewall


In This Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .89
Applicability. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .90
Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .91
Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .95
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .106

ARP Hosts
In This Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .107
Applicability. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .108
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .109
Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .110
Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .111
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .134

Associating Communities with Static and Aggregate Routes


In This Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .135
Applicability. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .136
Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .138
Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .140
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .162

Advanced Configuration Guide

Page 3

Table of Contents
BGP Anycast
In This Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .163
Applicability. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .164
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .165
Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .166
Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .171
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .205

BGP Multi-Homing for VPLS Networks


In This Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .207
Applicability. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .208
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .209
Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .211
Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .213
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .243

BGP Virtual Private Wire Services


In This Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .245
Applicability. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .246
Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .247
Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .251
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .276

BGP VPLS
In This Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .277
Applicability. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .278
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .279
Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .280
Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .282
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .313

Bi-Directional Forwarding Detection


In This Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .315
Applicability. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .316
Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .317
Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .319
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .362

Bridged CO
In This Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .363
Applicability. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .364
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .365
Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .366
Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .372
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .403

Class Fair Hierarchical Policing for SAPs


In This Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .405
Applicability. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .406
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .407

Page 4

Advanced Configuration Guide

Table of Contents
Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .408
Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .419
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .448

Carrier Supporting Carrier IP VPNs


In This Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .449
Applicability. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .450
Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .451
Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .453
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .474

Deterministic Large Scale NAT44


In This Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .475
Applicability. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .476
Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .477
Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .481
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .514

Distributed CPU Protection


In This Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .515
Applicability. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .516
Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .517
Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .518
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .540

ESMv4: PPPoE Hosts


In This Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .541
Applicability. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .542
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .543
Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .544
Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .557
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .590

ESM IPv4: Multicast with Redirection


In This Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .591
Applicability. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .592
Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .593
Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .595
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .627

ESM IPv4: Multicast with SRRP


In This Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .629
Applicability. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .630
Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .631
Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .633
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .661

ESMv6: IPoE Dual Stack Hosts


In This Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .663

Advanced Configuration Guide

Page 5

Table of Contents
Applicability. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .664
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .665
Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .666
Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .674
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .705

ESMv6: PPPoE Dual Stack Hosts


In This Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .707
Applicability. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .708
Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .709
Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .713
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .742

Flexible Authentication Model in ESM


In This Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .743
Applicability. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .744
Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .745
Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .747
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .788

Full IGP Shortcuts


In This Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .789
Applicability. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .790
Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .791
Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .794
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .831

G.8032 Ethernet Ring Protection Single Ring Topology


In This Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .833
Applicability. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .834
Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .835
Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .838
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .855

Ingress Multicast Path Management


In This Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .857
Applicability. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .858
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .859
Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .860
Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .865
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .900

Inter-Area TE Point-to-Point LSPs


In This Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .901
Applicability. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .902
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .903
Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .905
Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .907
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .925

Page 6

Advanced Configuration Guide

Table of Contents
Inter-AS Model C for VLL
In This Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .927
Applicability. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .928
Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .929
Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .931
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .947

IP/GRE Termination
In This Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .949
Applicability. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .950
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .951
Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .952
Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .955
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .977

IPv4 DHCP Hosts


In This Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .979
Applicability. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .980
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .981
Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .982
Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .986
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1022

LDP over RSVP Using OSPF as IGP


In This Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1023
Applicability. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1024
Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1025
Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1027
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1057

LDP VPLS using BGP-Auto Discovery


In This Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1059
Applicability. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1060
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1061
Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1062
Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1064
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1089

Managed SAPs with Routed CO


In This Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1091
Applicability. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1092
Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1093
Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1096
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1122

MPLS LDP FRR using ISIS as IGP


In This Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1123
Applicability. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1124
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1125
Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1126

Advanced Configuration Guide

Page 7

Table of Contents
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1145

Multicast in a VPN I
In This Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1147
Applicability. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1148
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1149
Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1152
Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1155
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1203

Multicast in a VPN II
In This Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1205
Applicability. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1206
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1207
Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1209
Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1211
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1260

Multi-Chassis Endpoint for VPLS Active/Standby Pseudowire


In This Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1261
Applicability. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1262
Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1263
Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1267
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1291

Multi-Chassis APS and Pseudowire Redundancy Interworking


In This Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1293
Applicability. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1294
Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1295
Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1298
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1314

Multi-Chassis IPSec Redundancy


In This Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1315
Applicability. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1316
Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1317
Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1319
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1352

Multi-Chassis LAG and Pseudowire Redundancy Interworking


In This Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1353
Applicability. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1354
Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1355
Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1358
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1379

Multi-Chassis Ring Layer 2 with Enhanced Subscriber Management


In This Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1381
Applicability. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1382

Page 8

Advanced Configuration Guide

Table of Contents
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1383
Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1384
Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1389
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1413

Multi-Segment Pseudowire Routing


In This Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1415
Applicability. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1416
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1417
Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1418
Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1421
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1467

Multicast VPN: Sender-Only, Receiver-Only


In This Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1469
Applicability. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1470
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1471
Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1472
Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1474
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1522

MVPN: Inter-AS Option B


In This Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1523
Applicability. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1524
Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1525
Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1533
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1548

NAT in Combination with ESM


In This Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1549
Applicability. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1550
Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1551
Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1554
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1574

PBB-Epipe
In This Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1575
Applicability. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1576
Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1577
Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1579
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1598

PBB-VPLS
In This Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1599
Applicability. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1600
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1601
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1602
Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1603
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1638

Advanced Configuration Guide

Page 9

Table of Contents
Point-to-Point LSPs
In This Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1639
Applicability. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1640
Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1641
Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1645
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1666

Pseudowire QoS
In This Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1667
Applicability. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1668
Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1669
Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1674
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1691

QoS Architecture and Basic Operation


In This Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1693
Applicability. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1694
Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1695
Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1696
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1735

RADIUS-Triggered Dynamic Data Service Provisioning


In This Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1737
Applicability. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1738
Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1739
Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1742
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1781

Routed CO
In This Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1783
Applicability. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1784
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1785
Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1786
Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1789
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1829

RSVP Signalled Point-to-Multipoint LSPs


In This Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1831
Applicability. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1832
Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1833
Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1835
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1876

Shared Risk Link Groups for RSVP-Based LSP


In This Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1877
Applicability. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1878
Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1879
Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1881
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1898

Page 10

Advanced Configuration Guide

Table of Contents
Shortest Path Bridging for MAC
In This Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1899
Applicability. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1900
Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1901
Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1903
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1933

Spoke Termination for IPv6-6VPE


In This Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1935
Applicability. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1936
Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1937
Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1940
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1965

Subscriber Redundancy for Routed-CO


In This Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1967
Applicability. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1968
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1969
Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1970
Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1972
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2000

Synchronous Ethernet
In This Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2001
Applicability. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2002
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2003
Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2004
Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2011
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2018

VPRN Inter-AS VPN Model C


In This Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2019
Applicability. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2020
Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2021
Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2024
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2033

WiFi Aggregation and Offload Migrant User Support


In This Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2035
Applicability. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2036
Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2037
Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2045
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2049

Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2051
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2055

Advanced Configuration Guide

Page 11

Table of Contents

Page 12

Advanced Configuration Guide

List of Tables
Table 1:
Table 2:
Table 3:
Table 4:
Table 5:
Table 6:
Table 7:
Table 8:
Table 9:
Table 10:
Table 11:
Table 12:
Table 1:
Table 2:
Table 3:
Table 4:
Table 5:
Table 6:
Table 7:
Table 8:
Table 9:
Table 10:
Table 11:
Table 12:
Table 13:
Table 14:
Table 15:
Table 16:
Table 17:
Table 18:
Table 19:
Table 20:
Table 21:
Table 22:
Table 23:
Table 24:
Table 25:
Table 26:
Table 27:
Table 28:
Table 29:
Table 30:

Customer-Reserved App-Filter Ranges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .45


ISP ON-Net Classification Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .50
Application Assurance Asymmetry Removal Topology. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .75
ARP Host Time-Related Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .122
VE-IDs and Labels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .289
VE-IDs and Number of Labels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .290
Correlation of Hosts and BSA/BSR Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .371
BSA/BSR Configuration for Host-1 Operation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .375
BSA/BSR Configuration for Host-2 Operation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .376
BSA/BSR Configuration for Host-3 Operation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .378
Burst Levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .409
Policer stat-mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .420
Reserved PPPoE Tags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .547
LCP and IPCP Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .550
Valid Combinations for RADIUS Authenticated Hosts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .666
Valid Combinations for LUDB Authenticated Hosts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .666
Applicable Subscriber-Prefix Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .679
Timer Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .681
Router Advertisements Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .683
RADIUS AVPs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .685
Local User Database Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .688
DHCP Lease State Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .689
Subscriber Prefix Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .716
Subscriber Prefix Subnetting for SLAAC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .716
Subscriber-Prefix Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .719
Prefix Subnetting for delegated-prefix-length /56 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .719
RADIUS AVPs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .721
SLAAC-Related Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .725
IPv6CP Nack Message Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .741
Shortcut Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .807
Supported DHCP Option 82 Sub-Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .989
Information in DHCP Lease State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .995
Next Generation MVPN Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1150
SAP Ingress Classification Match Criteria. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1699
QinQ Dot1p Bit Classification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1701
Forwarding classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1702
Queue Priority vs. Profile Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1706
Network QoS Policy DSCP Remarking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1713
Dynamic Service Attribute List for Setup, Modify and Teardown . . . . . . . . . . . . . . . . . . . . . .1748
Dynamic Service Actions on Control- and Data-Channel . . . . . . . . . . . . . . . . . . . . . . . . . . . .1749
Function and Dictionary Relationship . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1752
Revertive, Non-Revertive Timing Reference Switching Operation . . . . . . . . . . . . . . . . . . . . .2008

Advanced Configuration Guide

Page 13

List of Tables

Page 14

Advanced Configuration Guide

List of Figures
Figure 1:
Figure 2:
Figure 3:
Figure 4:
Figure 5:
Figure 6:
Figure 7:
Figure 8:
Figure 9:
Figure 10:
Figure 11:
Figure 12:
Figure 13:
Figure 14:
Figure 15:
Figure 16:
Figure 17:
Figure 18:
Figure 19:
Figure 20:
Figure 21:
Figure 22:
Figure 23:
Figure 24:
Figure 25:
Figure 26:
Figure 27:
Figure 28:
Figure 29:
Figure 30:
Figure 31:
Figure 32:
Figure 33:
Figure 34:
Figure 35:
Figure 36:
Figure 37:
Figure 38:
Figure 39:
Figure 40:
Figure 41:
Figure 42:
Figure 43:
Figure 44:
Figure 45:
Figure 46:

Aggregate Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27


Test topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28
App-Filters/Applications/App-Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .40
HTTP Persistent Connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .46
FoxMeter www.wikipedia.org . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .48
Wireshark www.wikipedia.org . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .48
Wireshark HTTPS www.whatsapp.com . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .52
HTTPS SNI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .54
SIP Wireshark Capture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .55
H323 Wireshark Capture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .57
Wireshark GoGlobal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .64
Application Assurance Asymmetry Removal Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .75
Network to Subscriber Traffic Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .84
Subscriber to Network Traffic Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .85
Block Unsolicited Traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .92
SFW Allow Gaming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .92
ALG Support Example FTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .93
Configuration Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .96
Bridged CO and Routed CO Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .110
ARP Hosts in a Bridged CO Environment Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .111
ARP Hosts in a Routed CO Environment Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .114
ARP Host Session Timeout Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .123
Trap Generation Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .125
Throttling Toward RADIUS Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .127
ARP Host Mobility Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .129
Network Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .138
CE Connections for Next-Hops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .142
CE-1 Connectivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .153
CE-3 Connectivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .157
BGP Anycast Operation in GRT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .166
BGP Anycast Operation with IP-VPN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .168
BGP Anycast Data Path (BGP to BGP Swapping) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .169
BGP Anycast BGP Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .170
Anycast Address Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .173
E2E MPLS Between Access Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .185
Data Path with Failing ABR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .187
End-to-End Transport Tunnel Using Additional Loopback Interfaces . . . . . . . . . . . . . . . . . . .188
IP-VPN with Anycast NH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .190
IP-VPN with Anycast NH, Data Path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .204
Network Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .211
Nodes Involved in BGP MH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .216
MAC Flush for BGP MH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .230
Access PE/CE Signalling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .231
Oper-Groups and BGP-MH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .234
Network Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .247
Single Homed BGP VPWS using Auto-Provisioned SDPs . . . . . . . . . . . . . . . . . . . . . . . . . . .254

Advanced Configuration Guide

Page 15

List of Figures

Figure 47:
Figure 48:
Figure 49:
Figure 50:
Figure 51:
Figure 52:
Figure 53:
Figure 54:
Figure 55:
Figure 56:
Figure 57:
Figure 58:
Figure 59:
Figure 60:
Figure 61:
Figure 62:
Figure 63:
Figure 64:
Figure 65:
Figure 66:
Figure 67:
Figure 68:
Figure 69:
Figure 70:
Figure 71:
Figure 72:
Figure 73:
Figure 74:
Figure 75:
Figure 76:
Figure 77:
Figure 78:
Figure 79:
Figure 80:
Figure 81:
Figure 82:
Figure 83:
Figure 84:
Figure 85:
Figure 86:
Figure 87:
Figure 88:
Figure 89:
Figure 90:
Figure 91:
Figure 92:
Figure 93:
Figure 94:
Figure 95:

Page 16

Single Homed BGP VPWS using Pre-Provisioned SDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261


Dual Homed BGP VPWS with Single Pseudowire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265
Dual Homed BGP VPWS with Active/Standby Pseudowire . . . . . . . . . . . . . . . . . . . . . . . . . . 271
Network Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280
BGP VPLS Using Auto-Provisioned SDPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287
BGP VPLS Using Pre-Provisioned SDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303
BFD Multi-Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318
BFD Centralized Sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320
BFD Interface Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321
BFD for ISIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327
BFD for OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329
BFD for OSPF and PIM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331
BFD for Static Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333
BFD for IES over Spoke SDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336
BFD for RSVP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341
BFD for T-LDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345
BFD for OSPF PE-CE I/F . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348
BFD Sessions within IPSec Tunnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351
Logic for Shared BFD Sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354
BFD for VRRP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355
Bridged CO Network Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366
Key Concepts of Bridged CO Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367
Flow Chart for Subscriber-Profile Identification Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . 369
Flowchart for SLA-Profile Identification Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370
Sample Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372
Functionality of Each Node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372
Host-1 Setup Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384
Host-2 Setup Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 388
Host-3 Setup Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395
Policer Token Bucket Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 408
Peak Information Rate (PIR) Bucket . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 410
Committed Information Rate (CIR) Bucket . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 411
Fair Information Rate (FIR) Bucket . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 412
Policer and Arbiter Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414
Parent Policer and Root Arbiter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415
Configuration Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 417
Post Policing Queues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 418
Parent Policer Thresholds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424
CSC Network Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 451
Deterministic NAT Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 477
Deterministic NAT Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 478
Deterministic Mapping: Inside -> Outside Routing Instances . . . . . . . . . . . . . . . . . . . . . . . . . 479
Deterministic Mapping: Outside IP Port-Blocks/Ranges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 480
Test Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 481
Case 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 486
Case 1 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 491
Case 1 Flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 491
Case 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 496
Case 2 Prefix 10.1.0.0/23 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 501

Advanced Configuration Guide

List of Figures

Figure 96:
Figure 97:
Figure 98:
Figure 99:
Figure 100:
Figure 1:
Figure 2:
Figure 3:
Figure 4:
Figure 5:
Figure 6:
Figure 7:
Figure 8:
Figure 9:
Figure 10:
Figure 11:
Figure 12:
Figure 13:
Figure 14:
Figure 15:
Figure 16:
Figure 17:
Figure 18:
Figure 19:
Figure 20:
Figure 21:
Figure 22:
Figure 23:
Figure 24:
Figure 25:
Figure 26:
Figure 27:
Figure 28:
Figure 29:
Figure 30:
Figure 31:
Figure 32:
Figure 33:
Figure 34:
Figure 35:
Figure 36:
Figure 37:
Figure 38:
Figure 39:
Figure 40:
Figure 41:
Figure 42:
Figure 43:
Figure 44:

Case 2 Prefix 10.2.0.0/22 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .502


Case 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .503
Case 3 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .507
Inverse Mapping Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .508
Sending flows: Det + non-Det NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .513
Test Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .518
Count Traffic with DCP Policy Count . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .524
Limit Traffic with dcp-static-policy-1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .527
Dynamic Policing Local Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .535
Dynamic Policers Instantiated . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .535
Routed CO Network Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .544
Discovery Stage Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .548
LCP Phase Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .551
CHAP Handshaking Overview Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .552
PAP Overview Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .553
IPCP Phase Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .554
Keepalive Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .555
Link Termination Phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .556
Authentication Flow Chart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .570
Pado-Delay Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .588
Network Topology Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .594
Single BNG Setup with Multicast Redirection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .595
Network Topology with MC-LAG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .602
IPoE Multicast Message Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .612
PPPoE Multicast Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .616
Network Topology Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .631
Network Topology Used for the Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .633
IPoE Subscriber Multicast Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .643
PPPoE Multicast Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .648
IPoE Dual Stack Subscriber Hosts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .667
Dual Stack IPoE Routed Gateway Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .668
DHCPv6 Lease Process (Part A) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .670
DHCPv6 Lease Process (Part B) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .671
Prefix Delegation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .673
IPv6 Address/Prefix Timers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .681
PPPoE Dual Stack Hosts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .709
Dual Stack PPPoE Bridged Gateway Service Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . .710
Dual Stack PPPoE Routed Gateway Service Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .711
Message Flow for a Dual Stack PPPoE Host . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .714
Dual Stack PPPoE for Routed Gateway . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .717
DHCPv6 Renewals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .727
Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .747
Normal SPF Tree Sourced by PE-1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .791
SPF Tree Sourced by PE-1 Using LSP Shortcuts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .792
Tested Network Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .793
LSPs between PE-1 and PE-6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .809
Network Topology to Verify Installation of Shortcuts into RTM . . . . . . . . . . . . . . . . . . . . . . . .815
Shortcuts Within a VRF Topology Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .827
G.8032 Operation and Topologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .837

Advanced Configuration Guide

Page 17

List of Figures

Figure 45:
Figure 46:
Figure 47:
Figure 48:
Figure 49:
Figure 50:
Figure 51:
Figure 52:
Figure 53:
Figure 54:
Figure 55:
Figure 56:
Figure 57:
Figure 58:
Figure 59:
Figure 60:
Figure 61:
Figure 62:
Figure 63:
Figure 64:
Figure 65:
Figure 66:
Figure 67:
Figure 68:
Figure 69:
Figure 70:
Figure 71:
Figure 72:
Figure 73:
Figure 74:
Figure 75:
Figure 76:
Figure 77:
Figure 78:
Figure 79:
Figure 80:
Figure 81:
Figure 82:
Figure 83:
Figure 84:
Figure 85:
Figure 86:
Figure 87:
Figure 88:
Figure 89:
Figure 90:
Figure 91:
Figure 92:
Figure 93:

Page 18

Test Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 838


Ethernet CFM Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 842
IOM/IMM Paths Connecting to Switch Fabric Planes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 860
Dynamic Bandwidth Rate Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 875
Falling-Percent-Reset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 876
Admin-Bw Rate Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 877
Inter-Area TE LSP Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 905
Inter-Area TE LSP Path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 905
ABR Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 915
Protection of All Nodes/Links Along the LSP Path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 916
Admin Group Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 918
Share Risk Link Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 921
Network Setup - Inter-AS Model C for VLL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 930
Inter-AS Model C for VLL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 930
Network Setup Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 931
GRE Packet Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 952
7x50 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 953
IP/GRE over IPSec Tunnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 954
GRE for Remote Access to a VPRN Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 962
IP/GRE Tunneling via Static Route . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 962
Example GRE over IPSec Tunnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 967
Bridged CO Network Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 982
Routed CO Network Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 982
DHCP Lease Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 984
Subscriber Host Connectivity Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1012
DHCP Proxy Server: Lease Split Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1018
DHCP Proxy Server: Lease Split Operation, DHCP Client Disconnected . . . . . . . . . . . . . . 1019
DHCP Host Mobility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1020
Initial Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1026
VPRN 1 with LDPoRSVP and No Intra-Area PE Connectivity . . . . . . . . . . . . . . . . . . . . . . . 1040
VPRN 1 with LDPoRSVP and Intra-Area PE Connectivity . . . . . . . . . . . . . . . . . . . . . . . . . . 1054
Network Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1062
VPLS Instance with Auto-Provisioned SDPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1070
VPLS Instance using Pre-Provisioned SDPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1082
Network Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1093
Initial Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1126
LFA Computation, Inequality 3 for Prefix PE-4 (D) on PE1 (S) . . . . . . . . . . . . . . . . . . . . . . . 1132
Data Verification, Direction PE-1 => PE-5 Using VLL Service . . . . . . . . . . . . . . . . . . . . . . . 1135
LFA Computation, Inequality 3 for Prefix PE-5 (D) on PE-1 (S) . . . . . . . . . . . . . . . . . . . . . . 1140
LFA Computation, Inequality 1 for Prefix PE-5 (D) on PE-1 (S) . . . . . . . . . . . . . . . . . . . . . . 1140
IS-IS Overload on PE-2, Inequality 1 for 192.168.24.0/30 (D) on PE-1 (S) . . . . . . . . . . . . . 1144
Network Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1152
Network Topology for Anycast RP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1177
IGMP and PIM Control Messaging Schematic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1184
PIM SSM in Customer Signaling Plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1188
Network Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1209
VPRN 1 Topology used for mLDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1216
VPRN 2 Topology used for RSVP-TE P2MP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1233
VPRN 2 Topology used for MVPN Source Redundancy . . . . . . . . . . . . . . . . . . . . . . . . . . . 1251

Advanced Configuration Guide

List of Figures

Figure 94:
Figure 95:
Figure 96:
Figure 97:
Figure 98:
Figure 99:
Figure 100:
Figure 101:
Figure 102:
Figure 103:
Figure 104:
Figure 105:
Figure 106:
Figure 107:
Figure 108:
Figure 109:
Figure 110:
Figure 111:
Figure 112:
Figure 113:
Figure 114:
Figure 115:
Figure 116:
Figure 117:
Figure 118:
Figure 119:
Figure 120:
Figure 121:
Figure 122:
Figure 123:
Figure 124:
Figure 125:
Figure 126:
Figure 127:
Figure 128:
Figure 129:
Figure 130:
Figure 131:
Figure 132:
Figure 133:
Figure 134:
Figure 135:
Figure 136:
Figure 137:
Figure 138:
Figure 139:
Figure 140:
Figure 141:
Figure 142:

VPRN 3 Topology used for MVPN Source Redundancy . . . . . . . . . . . . . . . . . . . . . . . . . . . .1257


H-VPLS with STP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1263
VPLS Pseudowire Redundancy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1264
Multi-Chassis Endpoint with Mesh Resiliency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1264
Multi-Chassis Endpoint with Square Resiliency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1265
Network Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1266
Core Node Failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1283
Multi-Chassis Node Failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1285
Multi-Chassis Passive Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1288
MC-APS Network Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1296
Access Node and Network Resilience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1297
Association of SAPs/SDPs and Endpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1303
ICB Spoke SDPs and Association with the Endpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1307
Additional Setup Example 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1310
Additional Setup Example 2 (Part 1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1311
Additional Setup Example 2 (Part 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1312
MC-IPSec Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1318
Test Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1319
MC-LAG Network Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1356
Network Resiliency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1357
Association of SAPs/SDPs and Endpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1365
ICB Spoke SDPs and Their Association with the Endpoints . . . . . . . . . . . . . . . . . . . . . . . . .1371
Additional Setup Example 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1375
Additional Setup Example 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1376
MC-Ring Layer 2 CO Dual Homing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1384
Dual homing Under Steady-State Condition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1386
Broken Ring State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1388
Network Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1389
Unicast Services Logical Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1397
Multicast Service Logical Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1407
FEC129 Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1418
AII Type 2 Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1419
Pseudowire Routing NLRI (the AC ID is always zero) . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1419
Configuration Flow Chart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1421
Intra-AS MS-PW Network Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1439
Inter-AS MS-PW Network Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1452
Default PMSI Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1472
Optimized PMSI Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1473
Test Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1474
RSVP-Based BGP Message Flow Between PE-2 and PE-3 . . . . . . . . . . . . . . . . . . . . . . . .1482
RSVP-Based BGP Message Flow Between PE-1 and PE-3 . . . . . . . . . . . . . . . . . . . . . . . .1485
mLDP-Based BGP Message Flow Between PE-2 and PE-3 . . . . . . . . . . . . . . . . . . . . . . . .1504
mLDP-Based BGP Message Flow Between PE-1 and PE-3 . . . . . . . . . . . . . . . . . . . . . . . .1510
General Topology for Inter-AS MVPN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1525
Protocols Used for Inter-AS MVPN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1525
BGP Signalling Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1528
PIM-P Signalling Steps for Default MDT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1529
PIM-C Signalling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1530
PIM-P Signalling Steps for Data MDT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1531

Advanced Configuration Guide

Page 19

List of Figures

Figure 143:
Figure 144:
Figure 145:
Figure 146:
Figure 147:
Figure 148:
Figure 149:
Figure 150:
Figure 151:
Figure 152:
Figure 153:
Figure 154:
Figure 155:
Figure 156:
Figure 157:
Figure 158:
Figure 159:
Figure 160:
Figure 161:
Figure 162:
Figure 163:
Figure 164:
Figure 165:
Figure 166:
Figure 167:
Figure 168:
Figure 169:
Figure 170:
Figure 171:
Figure 172:
Figure 173:
Figure 174:
Figure 175:
Figure 176:
Figure 177:
Figure 178:
Figure 179:
Figure 180:
Figure 181:
Figure 182:
Figure 183:
Figure 184:
Figure 185:
Figure 186:
Figure 187:
Figure 188:
Figure 189:
Figure 190:
Figure 191:

Page 20

Test Topology Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1533


BGP Signalling Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1536
PIM-P Signalling Steps for Default MDT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1540
PIM-C Signalling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1543
PIM-P Signalling Steps for Data MDT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1545
Network Address Translation Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1551
Setup Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1555
Simplified Routing Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1555
Subscriber-Host Creation Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1559
Network Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1578
Setup Detailed View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1580
Virtual MEPs for Flooding Avoidance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1589
Network Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1602
MTU-1 and PE-1 Nodes as Configuration Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1604
Blackhole . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1616
Send Flush on BVPLS Failure Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1619
Inter-Domain B-VPLS and MMRP Policies/ISID-Based Filters Example . . . . . . . . . . . . . . . 1627
Generic MPLS Network, MPLS Label Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1642
MPLS Testbed Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1644
Static LSP Running Over PE-1 PE-2 PE-5 PE-6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1646
Ingress PW QoS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1670
Egress PW QoS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1670
Example Epipe Pseudowire Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1674
Service and Network QoS Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1697
Visualization of Default Network Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1717
Default Buffer Pools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1719
WRED Slope Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1724
Buffer Pools and Queue Sizing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1726
Scheduling (Dequeuing Packets from the Queue) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1729
IOM QoS Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1730
Principle Model of Dynamic Data Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1740
Test Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1742
Building Blocks of Dynamic Data Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1743
Hierarchy of Snippets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1754
Components of the Routed CO Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1786
Numbered Scenario For IES 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1796
Unnumbered Scenario for IES 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1808
Hybrid Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1818
P2MP Network Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1834
P2MP LSP LSP-p2mp-1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1840
P2MP LSP p-to-mp-1 with Metric Change . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1857
P2MP LSP LSP-p2mp-1 with Strict S2L Path Towards PE-7 . . . . . . . . . . . . . . . . . . . . . . . . 1860
Intelligent Remerge, Case 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1862
Intelligent Remerge, Case 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1866
Intelligent Remerge, Case 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1870
Initial Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1880
SRLG Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1881
Path Primary RSVP_TE LSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1888
SRLG for FRR Path With and Without SRLG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1890

Advanced Configuration Guide

List of Figures

Figure 192:
Figure 193:
Figure 194:
Figure 195:
Figure 196:
Figure 197:
Figure 198:
Figure 199:
Figure 200:
Figure 201:
Figure 202:
Figure 203:
Figure 204:
Figure 205:
Figure 206:
Figure 207:
Figure 208:
Figure 209:
Figure 210:
Figure 211:

SRLG for Secondary Path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1893


SRLG Database Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1896
Basic SPBM Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1903
Control and User B-VPLS Test Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1914
Access Resiliency Test Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1919
Access Resiliency Test Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1923
Spoke Termination for IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1938
IPv6 Addressing and IPv6 Prefixes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1938
MP-BGP VPNv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1940
Spoke Termination for IPv6 Addressing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1942
PE-3 VPRN with SAP to CE-2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1953
Network Redundancy Components for ESM Routed-CO . . . . . . . . . . . . . . . . . . . . . . . . . . .1970
SyncE Hypothetical Reference Network Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2004
Packet Based Network Timing Infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2006
Current 7x50 Timing Sub-System Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2007
Network Considerations for Ethernet Timing Distribution . . . . . . . . . . . . . . . . . . . . . . . . . . .2010
Inter-AS VPN Model C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2022
Protocol Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2022
Sequence of Events to Establish and Authenticate a Migrant User (continued) . . . . . . . . . .2043
Sequence of Events to Establish and Authenticate a Migrant User . . . . . . . . . . . . . . . . . . .2044

Advanced Configuration Guide

Page 21

List of Figures

Page 22

Advanced Configuration Guide

Preface

About This Guide


This guide provides advanced configuration solutions for Alcatel-Lucents 7750 SR, 7710 SR, and
7450 ESS router and is meant to be supplemental to the basic user configuration guides listed
below.
The guide is organized alphabetically and provides feature and configuration explanations, CLI
descriptions and overall solutions.

Audience
This manual is intended for network administrators who are responsible for configuring the
routers. It is assumed that the network administrators have a detailed understanding of networking
principles and configurations.

List of Technical Publications


For information on routing and networking concept, configuration, and CLI command
descriptions, refer to the user documentation.

7750 SR/7710 SR/7450 ESS OS Basic System Configuration Guide


This guide describes basic system configurations and operations.

7750 SR/7710 SR/7450 ESS OS System Management Guide


This guide describes system security and access configurations as well as event logging
and accounting logs.

7750 SR/7710 SR/7450 ESS OS Interface Configuration Guide


This guide describes card, Media Dependent Adapter (MDA), and port provisioning.

7750 SR/7710 SR/7450 ESS OS Router Configuration Guide

Advanced Configuration Guide

Page 23

Preface

This guide describes logical IP routing interfaces and associated attributes such as an IP
address, port, link aggregation group (LAG) as well as IP and MAC-based filtering,
VRRP, and Cflowd.

7750 SR/7710 SR/7450 ESS OS Routing Protocols Guide


This guide provides an overview of routing concepts and provides configuration examples
for RIP, OSPF, IS-IS, Multicast, BGP, and route policies.

7750 SR/7710 SR/7450 ESS OS MPLS Guide


This guide describes how to configure Multiprotocol Label Switching (MPLS) and Label
Distribution Protocol (LDP).

7750 SR/7710 SR/7450 ESS OS Services Guide


This guide describes how to configure service parameters such as service distribution
points (SDPs), customer information, and user services.

7750 SR/7710 SR/7450 ESS OS OAM and Diagnostic Guide


This guide describes how to configure features such as service mirroring and Operations,
Administration and Management (OAM) tools.

7750 SR/7710 SR/7450 ESS OS Triple Play Guide


This guide describes Triple Play services and support and presents examples to configure
and implement various protocols and services.

7750 SR/7710 SR/7450 ESS OS Quality of Service Guide


This guide describes how to configure Quality of Service (QoS) policy management.

7750 SR/7710 SR OS Multi-Service ISA Guide


This guide describes services provided by integrated service adapters such as Application
Assurance, IPSec, ad insertion (ADI) and Network Address Translation (NAT).

Technical Support
If you purchased a service agreement for your router and related products from a distributor or
authorized reseller, contact the technical support staff for that distributor or reseller for assistance.
If you purchased an Alcatel-Lucent service agreement, contact your welcome center:
http://www.alcatel-lucent.com/wps/portal/support
Report documentation errors, omissions and comments to:
ipd_online_feedback@alcatel-lucent.com
Include document name, version, part number and page(s) affected.

Page 24

Advanced Configuration Guide

Aggregate Route Indirect Next-Hop


Option

In This Chapter
This section provides information about aggregate route indirect next-hop option configurations.
Topics in this section include:

Applicability on page 26

Overview on page 27

Configuration on page 28

Conclusion on page 35

Advanced Configuration Guide

Page 25

Applicability

Applicability
This section is applicable to all of the 7950 XRS series, 7750 SR series (SR-7, SR-12, SR-c4 and
SR-c12), 7710 SR, as well as 7450 ESS (ESS-6, ESS-7 and ESS-12) series in mixed mode. This
configuration is supported by all IOM/IMMs and supported on all chassis types as long as the
protocol is supported.
The configuration was tested in release 11.0R1.

Page 26

Advanced Configuration Guide

Aggregate Route Indirect Next-Hop Option

Overview
The 7x50s have for many releases supported the ability to configure IPv4 and IPv6 aggregate
routes. A configured aggregate route that has the best preference for the prefix is added to the
routing table (activated) when it has at least one contributing route and removed when there are no
longer any more contributing routes. A contributing route is any route installed in the forwarding
table that is a more-specific match of the aggregate. (10.16.12.0/24 is a contributing route to the
aggregate route 10.16.12.0/22, but for this same aggregate 10.16.12.0/22 and 10.0.0.0/8 are not
contributing routes).
10.16.12.0/24

10.16.13.0/24

10.16.14.0/24

Router A

10.16.12.0/22

Routing Table
10.16.12.0/24
10.16.13.0/24
10.16.14.0/24
10.16.15.0/24

10.16.15.0/24

Router B
Routing Table
10.16.12.0/22

al_0294

Figure 1: Aggregate Routes

In Figure 1, Router A could choose to advertise all the four routes or one aggregate route. By
aggregating the four routes, fewer updates are sent on the link between routers A and B, router B
needs to maintain a smaller routing table resulting in better convergence and router B saves on
computational resources by evaluating fewer entries in its routing table.
Different network operators have different requirements for how to forward a packet that matches
an aggregate route but not any of the more-specific routes in the forwarding table that activated it.
In general, there are three different options:
1. The packet can be forwarded according to the next-most specific route, ignoring the aggregate route. This can lead to routing loops in some topologies.
2. The packet can be discarded.
3. The packet can be forwarded towards an indirect next-hop address that is configured by the
operator. The indirect next-hop could be the address of a threat management server that analyzes the packets it receives for security threats. This option requires the aggregate route to
be installed in the forwarding table with a resolved next-hop interface determined from a
route lookup of the indirect next-hop address.

Advanced Configuration Guide

Page 27

Configuration

Configuration
The test topology is shown in Figure 2.

Aggregate Route with Indirect Next Hop

Resolved Indirect Next Hop

PE-1

PE-2

Tester

al_0295

Figure 2: Test topology

This feature adds a new indirect keyword and associated IP address parameter to the existing
aggregate command in these configuration contexts:
config>router
config>service>vprn
The aggregate route configuration commands are shown below.
config
router
aggregate ip-prefix/ip-prefix-length [summary-only] [as-set] [aggregator as
-number: ip-address] [community comm-id] [black-hole | indirect ip-address]
config
service
vprn
aggregate ip-prefix/ip-prefix-length [summary-only] [as-set] [aggregator as
-number: ip-address] [community comm-id] [black-hole | indirect ip-address]

Parameters:

Page 28

indirect This indicates that the aggregate route has an indirect address. Note from this
syntax that the indirect option is mutually exclusive with the black-hole option. To change
the next-hop type of an aggregate route (for example from black-hole to indirect) the route
must be deleted and then re-added with the new next-hop type (however other
configuration attributes can generally be changed dynamically).

Advanced Configuration Guide

Aggregate Route Indirect Next-Hop Option

<ip-address> Installing an aggregate route with an indirect next-hop is supported for


both IPv4 and IPv6 prefixes, however if the aggregate prefix is IPv6 the indirect next-hop
must be an IPv6 address and if the aggregate prefix is IPv4 the indirect next-hop must be
an IPv4 address.

An indirect next-hop address of an aggregate route may be resolved by any of the following route
types:

Direct/local route

Static route with regular next-hop, black-hole next-hop or an indirect next-hop

OSPFv2 or RIP IPv4 route (applicable only to IPv4 aggregate routes)

LDP shortcut route (applicable only to IPv4 aggregate routes])

OSPFv2 or IS-IS shortcut route (IPv4 route with an LDP/RSVP or RSVP tunnel next-hop)
(applicable only to IPv4 aggregate routes)

OSPFv3 or IS-IS route

BGP route resolved by an IGP route

BGP route resolved by a BGP route

BGP labeled-IPv4 route resolved by an LDP or RSVP tunnel (applicable only to IPv4
aggregate routes

6PE route resolved by an LDP tunnel or static route with black-hole next-hop (applicable
only to IPv6 aggregate routes)

BGP-VPN route resolved by a BGP labeled-IPv4 route, LDP tunnel, or RSVP tunnel
(applicable only to aggregate routes configured in a VPRN context)

If an indirect next-hop is not resolved, the aggregate route will show up as black-hole.
Step 1.

Configure the aggregate route.

Command: aggregate
Syntax

Context
Description

aggregate ip-prefix/ip-prefix-length [summary-only] [as-set] [aggregator as-number: ipaddress] [community comm-id] [black-hole | indirect ip-address]
no aggregate ip-prefix/ip-prefix-length
config>router
config>service>vprn
Use this command to automatically install an aggregate in the routing table when there are one or
more component routes. A component route is any route used for forwarding that is a morespecific match of the aggregate.

Advanced Configuration Guide

Page 29

Configuration

The use of aggregate routes can reduce the number of routes that need to be advertised to neighbor
routers, leading to smaller routing table sizes.
Overlapping aggregate routes may be configured; in this case a route becomes a component of
only the one aggregate route with the longest prefix match. For example if one aggregate is
configured as 10.0.0.0/16 and another as 10.0.0.0/24, then route 10.0.128/17 would be aggregated
into 10.0.0.0/16, and route 10.0.0.128/25 would be aggregated into 10.0.0.0/24. If multiple entries
are made with the same prefix and the same mask the previous entry is overwritten.
A standard 4-byte BGP community may be associated with an aggregate route in order to facilitate
route policy matching.
By default aggregate routes are not installed in the forwarding table, however there are
configuration options that allow an aggregate route to be installed with a black-hole next hop or
with an indirect IP address as next hop.
The no form of the command removes the aggregate.
Default
Parameters

No aggregate routes are defined.


ip-prefix/ip-prefix-length The destination address of the aggregate route.
Values:

ipv4-prefix
ipv4-prefix-length
ipv6-prefix

ipv6-prefix-length

a.b.c.d (host bits must be 0)


0 32
x:x:x:x:x:x:x:x
x:x:x:x:x:x:d.d.d.d
x: [0 FFFF]H
d: [0 255]D
0 128

summary-only This optional parameter suppresses the advertisement of more specific


component routes for the aggregate. To remove the summary-only option, enter the same
aggregate command without the summary-only parameter.
as-set This optional parameter is only applicable to BGP and creates an aggregate where the
path advertised for this route will be an AS_SET consisting of all elements contained in all paths
that are being summarized. Use this feature carefully as it can increase the amount of route churn
due to best path changes.
aggregator as-number:ip-address This optional parameter adds the BGP aggregator path
attribute to the aggregate route. When configuring the aggregator, a two-octet AS number used to
form the aggregate route must be entered, followed by the IP address of the BGP system that
created the aggregate route.
community comm-id This configuration option associates a BGP community with the
aggregate route. The community can be matched in route policies and is automatically added to
BGP routes exported from the aggregate route.

Page 30

Advanced Configuration Guide

Aggregate Route Indirect Next-Hop Option

Values:

comm-id
asn
comm-val
well-known-comm

asn:comm-val | well-known-comm
0 65535
0 65535
no-advertise, no-export, no-export-subconfed

black-hole This optional parameter installs the aggregate route, when activated, in the FIB
with a black-hole next-hop. Packets matching an aggregate route with a black-hole next hop are
discarded.
indirect ip-address This configuration option specifies that the aggregate route should be
installed in the FIB with a next-hop taken from the route used to forward packets to ip-address.
Values

ipv4-prefix
ipv6-prefix

a.b.c.d
x:x:x:x:x:x:x:x
x:x:x:x:x:x:d.d.d.d
x: [0 FFFF]H
d: [0 255]D

A:PE-1>config#router aggregate 10.10.10.0/24 community 64496:64497 indirect 192.168.11.11

A:PE-1# show router aggregate


===============================================================================
Aggregates (Router: Base)
===============================================================================
Prefix
Aggr IP-Address
Aggr AS
Summary
AS Set
State
NextHop
Community
NextHopType
------------------------------------------------------------------------------10.10.10.0/24
0.0.0.0
0
False
False
Inactive
192.168.11.11
64496:64497
Indirect
------------------------------------------------------------------------------No. of Aggregates: 1
===============================================================================

Advanced Configuration Guide

Page 31

Configuration

Step 2.

Configure the contributing routes to activate the aggregate route.

*A:PE-1# show router route-table


===============================================================================
Route Table (Router: Base)
===============================================================================
Dest Prefix[Flags]
Type
Proto
Age
Pref
Next Hop[Interface Name]
Metric
------------------------------------------------------------------------------10.10.10.0/24
Remote Aggr
00h00m20s 130
Black Hole
0
10.10.10.3/32
Remote Static
00h00m24s 5
10.18.0.89
1
10.10.10.4/32
Remote Static
00h00m24s 5
10.18.0.89
1
10.10.10.5/32
Remote Static
00h00m24s 5
10.18.0.89
1
10.10.10.8/32
Remote Static
00h00m24s 5
10.18.0.89
1
10.12.0.0/24
Local
Local
00h00m24s 0
to_PE-2
0
10.18.0.0/24
Local
Local
00h00m24s 0
to_Routers
0
10.19.0.0/24
Local
Local
00h00m24s 0
to_Tester
0
10.20.1.1/32
Local
Local
00h00m24s 0
system
0
------------------------------------------------------------------------------No. of Routes: 9
Flags: L = LFA nexthop available
B = BGP backup route available
n = Number of times nexthop is repeated
===============================================================================

The aggregate route is now active:


A:PE-1# show router aggregate
===============================================================================
Aggregates (Router: Base)
===============================================================================
Prefix
Aggr IP-Address
Aggr AS
Summary
AS Set
State
NextHop
Community
NextHopType
------------------------------------------------------------------------------10.10.10.0/24
0.0.0.0
0
False
False
Active
192.168.11.11
64496:64497
Indirect
------------------------------------------------------------------------------No. of Aggregates: 1
===============================================================================

Page 32

Advanced Configuration Guide

Aggregate Route Indirect Next-Hop Option

Step 3.

Configure the resolving route.

A:PE-2# show router route-table


===============================================================================
Route Table (Router: Base)
===============================================================================
Dest Prefix[Flags]
Type
Proto
Age
Pref
Next Hop[Interface Name]
Metric
------------------------------------------------------------------------------10.10.10.0/24
Remote Static
00h00m14s 5
10.29.0.99
1
10.12.0.0/24
Local
Local
00h00m14s 0
to_PE-1
0
10.20.1.2/32
Local
Local
00h00m14s 0
system
0
10.29.0.0/24
Local
Local
00h00m14s 0
to_Tester
0
192.168.11.0/24
Remote Static
00h00m14s 5
10.12.0.2
1
------------------------------------------------------------------------------No. of Routes: 5
Flags: L = LFA nexthop available
B = BGP backup route available
n = Number of times nexthop is repeated
===============================================================================

The aggregate route now has the resolved next-hop.


*A:PE-2# show router route-table
===============================================================================
Route Table (Router: Base)
===============================================================================
Dest Prefix[Flags]
Type
Proto
Age
Pref
Next Hop[Interface Name]
Metric
------------------------------------------------------------------------------10.10.10.0/24
Remote Aggr
00h00m20s 130
10.12.0.2
0
10.10.10.3/32
Remote Static
00h00m24s 5
10.18.0.89
1
10.10.10.4/32
Remote Static
00h00m24s 5
10.18.0.89
1
10.10.10.5/32
Remote Static
00h00m24s 5
10.18.0.89
1
10.10.10.8/32
Remote Static
00h00m24s 5
10.18.0.89
1
10.12.0.0/24
Local
Local
00h00m24s 0
to_PE-2
0
10.18.0.0/24
Local
Local
00h00m24s 0
to_Routers
0
10.19.0.0/24
Local
Local
00h00m24s 0
to_Tester
0
10.20.1.1/32
Local
Local
00h00m24s 0
system
0
192.168.11.0/24
Remote Static
00h00m24s 5
10.12.0.2
1
------------------------------------------------------------------------------No. of Routes: 10
Flags: L = LFA nexthop available
B = BGP backup route available

Advanced Configuration Guide

Page 33

Configuration

n = Number of times nexthop is repeated


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

Page 34

Advanced Configuration Guide

Aggregate Route Indirect Next-Hop Option

Conclusion
Aggregate routes offer several advantages, the key being reduction in the routing table size and
overcoming routing loops, among other things. Aggregate routes with indirect next hop option
helps in faster network convergence by decreasing the number of route table changes. This
example shows how to configure aggregate routes with indirect next hop option.

Advanced Configuration Guide

Page 35

Conclusion

Page 36

Advanced Configuration Guide

Application Assurance - Application


Identification and User-Defined
Applications

In This Chapter
This section describes advanced Application Assurance (AA) application identification and userdefined application configurations.
Topics in this section include:

Applicability on page 38

Summary on page 39

Configuration on page 41

Conclusion on page 70

Advanced Configuration Guide

Page 37

Applicability

Applicability
This example is applicable to all 7750, 7450 and 7750 SR-c4/12 chassis supporting Application
Assurance and was tested on release 11.0R3.
There are no specific pre-requisites for this example.

Page 38

Advanced Configuration Guide

Application Assurance - Application Identification and User-Defined Applications

Summary
This example is intended for Application Assurance (AA) network architects and engineers. It
provides best practice information to customize the AA policy and classify any type traffic to meet
the service provider reporting, charging or control requirements.
In addition to the signatures built and supported by Alcatel-Lucent, service providers can create
their own application signatures based on various criteria. This customization capability can be
used to classify traffic hosted on the provider network (web portal, streaming service) or hosted on
the Internet and not yet covered by the default AA signature set.

Basics and Terminology


The following main components are used for AA classification:
Application Filters App-filters are used to define applications based on Layer 3 to Layer 7
criteria, they provide a mapping between one or more protocol signature or customized traffic
patterns into an application of interest.
Application Such as BitTorrent and Netflix.
Traffic is classified into applications using app-filters.
Application Group Such as peer-to-peer, multimedia streaming.
For the purpose of reporting and control, applications of similar type/function can be grouped
together in application groups (app-group).
Charging Group Such as zero rating, default.
For the purpose of charging or control, applications and app-group can be grouped together in
charging groups.
The following table is a high level example to illustrate how app-filters are used to defined
applications and show their logical grouping into app-group and charging group.

Advanced Configuration Guide

Page 39

Summary

Criteria

App-Filter
(ordered list of
entries, ACL-like)
Expression http: yahoo.com

Protocol
Expression: (HTTP,
SIP, H323, TLS, RTSP)
Layer 4 server port
IP server address
Flow direction
Custom protocol

Expression http:maps.google.com
Expression http:facebook.com
Protocol:
ftp_control, ftp_data
Protocol:
bittorent, dht, utp
Protocol:
emule

Flexible classification/identification rules (app-filters) to identify:


- Standard applications
- Custom-defined applications

Application

Application
Group

Yahoo
Web
Google Maps
Facebook

Social Networking

FTP

File Transfer

BitTorrent
Peer-to-Peer

Charging
Group
CG#1 Default

CG#2 - Zero
Rating

CG#1 Default

Emule

Flexible applications/app-group creation and


mapping for:
- Reporting
-Control (redirect, enrichment, policing...)

Independent charging
group mapping for
differentiated billing.

Figure 3: App-Filters/Applications/App-Groups

Page 40

BitTorrent and Emule applications are defined using their protocol signature and
grouped in the P2P App-Group.

FTP application is defined using both ftp_data and ftp_control protocol signatures, the
application is mapped in the file transfer app-group.

Google Maps and Yahoo web sites are defined using an HTTP expression and grouped
together in the web app-group.

Advanced Configuration Guide

Application Assurance - Application Identification and User-Defined Applications

Configuration
Classification Criteria (App-Filter)
The operator can take full advantage of the flexible AA policy configuration to classify traffic
from any application of interest using various criteria ranging from Layer 3 to Layer 7
expressions.
Expression match criteria allows to further refine traffic classification by identifying traffic from
HTTP, HTTPS (SSL/TLS), SIP, H323, RTSP, Citrix protocol signatures.
The different app-filter match criteria are listed below:
L7 Expression
HTTP
: Host, URI, User Agent, Referer
SSL/TLS : Certificate Org Name, Common Name, SNI
H323
: Product-ID
SIP
: URI, User Agent, Media Type
RTSP
: Host, URI, User Agent
Citrix : Application Published Name
IP Protocol Number
IP Server Address
TCP/UDP Server Port
Custom Protocol
Protocol Signature

The following operators are supported to define expression based app-filters:


^ :
$ :
* :
\I:
\d:
\.:
\*:

Expression start with


Expression end with
Wildcard - anything before or after
Forces case sensitivity
Any single decimal digit [0-9]
Any single character
Asterisk character

Examples of expression match combinations:


^abcd*: match abcd at beginning, can end with anything
*abcd*: match abcd anywhere
*abcd$: match abcd at the end
^abcd$: exact expression match abcd
^ab*cd$: string starts with 'ab', ends with 'cd' (anything else in between)
^ab\dcd$: string starts with 'ab', followed by a decimal digit, ends with 'cd'

Note: It is possible to combine different criteria or expressions within the same filter in which case
an implicit AND operation between the criteria within the same filter is done by the system.

Advanced Configuration Guide

Page 41

Configuration

Application Definition Example


The example below provides a basic configuration example with the application FTP made of two
protocol signatures ftp_control and ftp_data; the application is mapped into the application group
file transfer:
Create the application group.
configure application-assurance group 1:1 policy
app-group "File Transfer"
exit

Create the application.


configure application-assurance group 1:1 policy
application "FTP"
app-group "File Transfer"
exit

Create the app-filters.


configure application-assurance group 1:1 policy
app-filter
entry <1..65535> create
protocol eq "ftp_data"
application "FTP"
no shutdown
exit
entry <1..65535> create
protocol eq "ftp_control"
application "FTP"
no shutdown
exit

Note: Once the application is created the operator is expected to configure the collection of
statistics at the subscriber level for this new application (usually only for business VPNs).

Page 42

Advanced Configuration Guide

Application Assurance - Application Identification and User-Defined Applications

User-Defined Applications
General Recommendations
In order to classify traffic properly it is recommended to follow the guidelines and best practises
defined in this section before creating a new application:

Analyze the application traffic


Identify what type traffic is used (Wireshark).
Use the application in the same way the end user would use it, the same application
can create various flows.

Configure the appropriate App-Filters


Following the analysis of the application done above, create the application.
Follow the App-Filter best practises chapter to understand in which range to add the
filters.
More than one App-Filters can be required to identify a single application.

AppDB / Default AA Policy


The default AA policy called AppDB (Application Database) is provided by Alcatel-Lucent and
should be used on most deployments. Contact your regional support organization for more details
on how to obtain it.
This configuration includes applications and application-groups most providers can use by default
and is designed to allow the addition of any custom entries required by service providers to
identify additional services/applications.
Before adding new entries to the template and customizing the configuration it is recommended to
follow the next guidelines on app-filters and ranges. These guidelines are key to allow an easy
upgrade path from the policy configuration provided by Alcatel-Lucent.

Advanced Configuration Guide

Page 43

Configuration

App-Filters
App-filters are an ordered list of entries. It is important to keep the order of this list consistent with
the classification objective.
For instance a common configuration mistake is to configure a filter rule for the HTTP protocol
signature before HTTP expression filters. If that was the case then app-filters using HTTP
expressions would not be used as the system would find an acceptable match with the protocol
signature before walking the list of expressions configured. This mistake is described in the
example below:
entry 100 create
description "Default HTTP Protocol"
protocol eq "http"
application "HTTP"
no shutdown
exit
entry 110 create
description "Google"
expression 1 http-host eq "*.google.com$"
application "Google"
no shutdown
exit

This is in incorrect AppFilter order.


App-filter entry #100 will always match
before the http expression entry #110.

Note: It is not necessary to specify a protocol when defining an expression filter, the protocol is
implicitly based on the type of expression match criteria used (http, sip, h323 ...).

App-Filters Ranges
The app-filter list is an ordered list, it is key to configure each app-filter in the right order and in
the proper range.
The operator can customize the policy and create applications and app-filters by using the
following ranges (Table 1) (other ranges are used by the Alcatel-Lucent default policy):

Page 44

Advanced Configuration Guide

Application Assurance - Application Identification and User-Defined Applications

Table 1: Customer-Reserved App-Filter Ranges


Range Name

Description

Start

End

Top range

Top range, matches before any other filters.

2000

3999

Expression range A

HTTP host, Host + URI, optionally with IP/


port match.

19000

22999

Expression range B

Other expression match; optionally with IP/


port match.

33000

34999

Extended protocols

Protocol-signature + port|IP|dir. match

40000

41999

Custom protocols

Custom protocol signature match

61000

61499

Trusted/validate ports

First packet validate,


First packet trusted match

61500

61999

Ordering basics:

Layer 7 expressions based filters are located before their parent protocol signature (for
example, expression matches on HTTP are located before the HTTP protocol app-filter;
the same applies to TLS, SIP, H323, RTSP, Citrix).

HTTP host and URI are located before the HTTP referer for accounting accuracy (for
example, YouTube from within Facebook is classified as YouTube).

App-filters combining protocol signatures with Layer 4 port, IP protocol, IP address or


flow direction are always located before the protocol signature only filter range.

Advanced Configuration Guide

Page 45

Configuration

HTTP
Protocol
HTTP is a client/server protocol using TCP/IP at the transport layer to deliver resources such as
HTML files, images, videos and more.
HTTP 1.1 enables HTTP clients to use a persistent connection to a server allowing them to reuse
the same TCP session for multiple HTTP transactions. Text, images, video, scripts and other
objects can be downloaded individually in different transactions through the same TCP session.
Figure 4 describes a typical persistent HTTP connection between a web client and a server with
multiple HTTP transactions within the same TCP session:

Client

Open TCP Connection

Server
Index.html

GET www.example.com/index.html
HTTP Transaction #1
Single TCP
Connection

...

Index.html
GET/Images/1.gif

HTTP Transaction #2

<img src=http://
www.example.com/images/1.gif>
...

1.gif
Close TCP Connection
al_0298

Figure 4: HTTP Persistent Connection

User-defined expression based HTTP applications will use the first HTTP transaction to classify
the flow (optionally this behavior can be modified).

Page 46

Advanced Configuration Guide

Application Assurance - Application Identification and User-Defined Applications

HTTP Request
The example below shows the content of a typical HTTP request to wikipedia.org which includes
the following header fields: HTTP Host, HTTP URI, HTTP User Agent and HTTP referer fields:
Web Browser URL: http://en.wikipedia.org/wiki/Main_Page
Host

URI

HTTP Request Header


Host: en.wikipedia.org
URI: /wiki/Main_Page
User Agent: Mozilla/5.0(Windows NT 6.1; WOW64)
Referer: http://www.google.com/

HTTP Host Represents the domain name (does not include http://).
HTTP URI The URL trailer after the host domain name (begins with slash /).
HTTP Referer The address of the previous web page from which a link to the currently
requested page was followed (in this example, the referer is www.google.com which means the
user clicked on a link from a Google search pointing to wikipedia.org).
HTTP User Agent This identifies the web browser or application making the HTTP request.

Advanced Configuration Guide

Page 47

Configuration

Configuration Examples
HTTP Host (Wikipedia)
FoxMeter provides the following list of HTTP host recorded when browsing
www.wikipedia.org. (Figure 5):

Figure 5: FoxMeter www.wikipedia.org

Alternatively, Wireshark provides similar output as FoxMeter for one of the HTTP TCP flows
between the web client and the server (Figure 6):

Figure 6: Wireshark www.wikipedia.org

Capturing HTTP traffic from this web site can be done using a single expression tail anchored on
the HTTP host:

Page 48

Advanced Configuration Guide

Application Assurance - Application Identification and User-Defined Applications

configure application-assurance group 1:1 policy


app-filter
entry <1..65535> create
description "Wikipedia Web Access"
expression 1 http-host eq "*.wikipedia.org$"
application "Wikipedia"
no shutdown
exit

Note: There is no requirement to use HTTP URI, UserAgent or Referer for the site.

Advanced Configuration Guide

Page 49

Configuration

HTTP Host + Referer (YouTube)


A thorough analysis shows that classifying YouTube HTTP traffic requires two different
expression filters:
1. HTTP HOST: *.youtube.com (depending on the transaction it can be s.youtube.com,
www.youtube.com ).
2. HTTP HOST: *.ytming.com (depending on the transaction it can be any string followed by
.ytming.com).
Therefore the corresponding configuration can be used to classify YouTube:
configure application-assurance group 1:1 policy
entry <1..65535> create
description "YouTube Web Access"
expression 1 http-host eq "*.youtube.com$"
application "YouTube"
no shutdown
exit
entry <1..65535> create
description "YouTube Web Access"
expression 1 http-host eq "*.ytimg.com$"
application "YouTube"
no shutdown
exit

HTTP URI (Mobile Charging)


Mobile operators may need to apply different charging rules to different content located on the
same HTTP server domain (different URI, same host).
Table 2 displays an example of classification rules for content services traffic within the operator
network.

Table 2: ISP ON-Net Classification Rules


URL

Page 50

Charging Rule

AA Application

www.ispdomain.com/video

Rule #1 0 Rating

ISP_Portal_Video

www.ispdomain.com/images

Rule #2 Charge X

ISP_Portal_Images

www.ispdomain.com/*

Rule #3 Charge Y

ISP_Portal_Default

Advanced Configuration Guide

Application Assurance - Application Identification and User-Defined Applications

Because HTTP 1.1 clients can reuse the same TCP connection for many transactions to the same
server, classifying each transaction to www.ispdomain.com independently requires a specific AA
configuration at the partition level to enable classification of each HTTP transaction within the
same TCP flow independently (in the absence of Proxy):
configure application-assurance group 1:1
http-match-all-requests
exit

Note: If the content of ispdomain.com/video and ispdomain.com/images were hosted on different


servers this configuration would not be required as each URL request would create a separate TCP
flow to each server.

Advanced Configuration Guide

Page 51

Configuration

SSL/TLS (HTTPS)
Protocol
HTTPS uses SSL/TLS to encrypt traffic between the client and the server. Since this
communication is encrypted it is not possible to identify the HTTP Host or URI; however, AA can
still identify the service requested by the subscriber by looking at the TLS certificate information
or Server Name Indication exchanged in the clear before the TLS session is established.
Note: SSL/TLS expression based app-filters are not limited to HTTPS. HTTPS is not a protocol in
itself, but is HTTP traffic-tunnelled encrypted into SSL/TLS on port 443.

SSL/TLS Certificates
The snapshot (Figure 7) from Wireshark shows the SSL/TLS certificate exchanged using the
mobile application whatsapp.

Figure 7: Wireshark HTTPS www.whatsapp.com

The certificate information can be found in the Server Hello message sent by the server, capturing
SSL/TLS (HTTPS) traffic from this application can be done using a single app-filter entry tail
anchored on the TLS Common Name Certificate:

Page 52

Advanced Configuration Guide

Application Assurance - Application Identification and User-Defined Applications

configure application-assurance group 1:1 policy


app-filter
entry <1..65535> create
description "Whats App tls and image/voice/video traffic"
expression 1 tls-cert-subj-common-name eq
"*.whatsapp.net$"
application "Whats App"
no shutdown
exit

Advanced Configuration Guide

Page 53

Configuration

Server Name Indication


SSL/TLS traffic can optionally be identified using the Server Name Indication (SNI) which is an
extension to the TLS protocol.
The SNI is found in the TLS Client Hello, the http-host expression in the app-filter is reused to
classify this traffic:

Figure 8: HTTPS SNI

configure application-assurance group 1:1 policy


app-filter
entry <1..65535> create
description "Yahoo HTTP or TLS SNI"
expression 1 http-host eq "*.yahoo.com$"
application "Yahoo"
no shutdown
exit

Page 54

Advanced Configuration Guide

Application Assurance - Application Identification and User-Defined Applications

SIP
Protocol
SIP is a signalling protocol used for controlling multimedia communication sessions such as voice
and video over RTP. AA automatically monitors SIP control flows and associate RTP/RTCP
media flows accordingly in the sip_rtp protocol signature.
The operator can use a SIP expression match criteria in app-filter to further refine traffic
classification and identify any additional application on top of the default AA policy. This can be
particularly useful in business VPNs to identify voice and telepresence applications.
AA supports SIP expression match criteria on SIP URI, SIP user agent and SIP media type. The
snapshot below from Wireshark shows a SIP control exchange using the voice-video application
Vonage followed by the RTP media audio flow; the expression fields that can be matched using
AA app-filters are highlighted:

Figure 9: SIP Wireshark Capture

Advanced Configuration Guide

Page 55

Configuration

Configuration Example
The configuration example below provides the configuration to classify Vonage SIP/RTP
desktop traffic using SIP URI expression:
configure application-assurance group 1:1 policy
app-filter
entry <1..65535> create
description "Vonage"
expression 1 sip-uri eq "*voncp.com*"
application "Vonage"
no shutdown
exit

Page 56

Advanced Configuration Guide

Application Assurance - Application Identification and User-Defined Applications

H323
Protocol
Similarly to SIP, H323 is a signalling protocol used for controlling multimedia communication
sessions such as voice and video over RTP. AA automatically monitors H323 control flows and
associates the RTP media flow accordingly in the h323_rtp protocol signature.
The operator can use an H323 expression match criteria app-filter to further refine traffic
classification and identify any additional application on top of the default AA policy. This can be
particularly useful in business VPNs to identify voice and telepresence applications.
AA supports H323 expression match criteria on the H323 Product ID. The snapshot below from
Wireshark shows an H323 control exchange using the telepresence application LifeSize
followed by the RTP media audio flow; the expression field that can be matched using AA appfilters is highlighted:

Figure 10: H323 Wireshark Capture

Configuration Example
The configuration example below provides the configuration to classify LifeSize H323/RTP
traffic using the H323 Product ID expression:
configure application-assurance group 1:1 policy

Advanced Configuration Guide

Page 57

Configuration

app-filter
entry <1..65535> create
description "LifeSize H323 traffic"
expression 1 h323-product-id eq "^LifeSize*"
application "LifeSize"
no shutdown
exit

Page 58

Advanced Configuration Guide

Application Assurance - Application Identification and User-Defined Applications

RTSP
Protocol
RTSP is a signaling protocol used for controlling media streaming content such as audio and video
over RTP/RDT. AA automatically monitors the RTSP control flows and associates its RTP/RDT
media flow with the rtp_rtsp protocol signature.
The operator can use an RTSP expression match criteria app-filter to further refine traffic
classification and identify any additional application on top of the default AA policy. This can be
particularly useful to identify specific streaming applications.
AA supports RTSP expression match criteria on the RTSP Host, URI, UserAgent. The snapshot
below from Wireshark shows an RTSP setup request to YouTube followed by the RTP media
audio flow; the expression fields that can be matched in RTSP SETUP request using AA appfilters are highlighted:
Host

URI

RTSP Header
SETUP rtsp://v3.cache7.c.youtube.com/ZTww=/0/0/0/video.3gp/trackID=13 RTSP/1.0
CSeq: 3
User-Agent: Mozilla/5.0 (BlackBerry; U; BlackBerry 9800; en) AppleWebKit/54.8+
x-wap-profile:
"http://www.blackberry.net/go/mobile/profiles/uaprof/9800_unknown/6.0.0.rdf"
Transport: RTP/AVP;unicast;client_port=51132-51133;mode="PLAY"

Configuration Example
The configuration example below provides the configuration to classify YouTube RTSP/RTP
traffic using RTSP host expression:
configure application-assurance group 1:1 policy
app-filter
entry <1..65535> create
description "YouTube RTSP/RTP Video"
expression 1 rtsp-host eq "*.youtube.com$"
application "YouTube"
no shutdown
exit

Advanced Configuration Guide

Page 59

Configuration

Citrix
Protocol
Independent Computing Architecture (ICA) is a Citrix Systems protocol used in Citrixs
WinFrame, Citrix XenApp (formerly called MetaFrame/Presentation Server), and Citrix
XenDesktop products.
Citrix makes it possible to run applications remotely on large servers, thus making better use of
server resources while at the same time allowing people using other platforms to use the
applications, for example, run Microsoft Word on a UNIX workstation.
Citrix_ica protocol signature will detect any remote application using Citrix (the protocol needs to
be unencrypted and configured to non-seamless). The Citrix ICA session is started from a client
and can be anything from Remote Desktop, SAP to Microsoft Word.
The Citrix expression match app-filter is used to classify traffic based on the Citrix-published
application; this published application is configured on the server and in the example above can be
for instance RDP, SAP, Word, XLS or Microsoft Word depending how the server is configured.

Configuration Example
configure application-assurance group 1:1 policy
app-filter
entry <1..65535> create
description "Citrix SAP Application"
expression 1 citrix-app eq "SAP"
application "Citrix SAP"
no shutdown
exit

Page 60

Advanced Configuration Guide

Application Assurance - Application Identification and User-Defined Applications

IP Address and TCP/UDP Port


Traffic from specific server(s) can be classified using IPv4/v6 server-address app-filter rules; it is
used usually to identify traffic from an internal (on-net) server as opposed to an Internet (off-net)
server.
The server-address app-filter automatically detects the client from the server by identifying which
side opens the connection and implicitly classify traffic based on the server IP address or Port
number, for example, if A initiates a TCP connection to B, then flows A->B and B<-A can be
classified with a match on server-address = B. Similarly a flow initiated from B to A would be
classified using a match on server-address = A.

Server-Address
The configuration example below uses a server-address app-filter to classify traffic from server
10.0.0.1 in the application called Application-1:
configure application-assurance group 1:1 policy
app-filter
entry <1..65535> create
description "Server #1 10.0.0.1"
server-address eq 10.0.0.1/32
application "Application-1"
no shutdown
exit

Server-Address + Server Port


The configuration example below uses server-address and server-port app-filters to classify traffic
from server 10.0.0.2 on port 1234 in the application called Application-2. It is particularly useful
when the same server is used to provide different services that need to be classified separately:
configure application-assurance group 1:1 policy
entry <1..65535> create
description "Server #2 10.0.0.2 port 1234 Only"
server-address eq 10.0.0.2/32
server-port eq 1234
application "Application-2"
no shutdown
exit

Advanced Configuration Guide

Page 61

Configuration

Server Port + Protocol Signature


It is possible to combine a protocol signature with a port number in the same app-filter, this is
typically done in business VPNs for specific internal applications not detected using existing AA
protocol signature.
The configuration below classifies a business VPN application running on TCP port 4000 and not
detected by any other signatures, combining the protocol signature unknown_tcp with the desired
port number allows keeping the classification untouched for the rest of the protocols/applications
and is the recommended approach:
configure application-assurance group 1:1 policy
app-filter
entry <1..65535> create
description "Business VPN Application X Port 4000"
server-port eq 4000
protocol eq unknown_tcp
application "Busines VPN Application X"
no shutdown
exit

Note: It is important to follow the app-filter range recommendations for a proper classification of
traffic using IP address or port number.

Flow Setup Direction


Traffic can be classified based on flow-setup-direction app-filter, the flow setup direction can be
either subscriber-to-network or network-to-subscriber.
Network side and subscriber side is AA terminology related to where AA is enabled:
In broadband and mobile networks, AA is enabled per subscriber, meaning the subscriber side
represents the ESM/mobile/transit subscriber while the network side represents Internet or other
subscribers.
In business VPNs, AA is enabled on a VPN SAP/spoke SDP and the subscriber side represents the
local VPN site (SAP/spoke/transit).
The example below shows the configuration to classify http traffic hosted by AA subscribers (for
example, broadband subscribers running a web server):
configure application-assurance group 1:1 policy
app-filter
entry <1..65535> create
description "HTTP Server on the subscriber side"
flow-setup-direction network-to-subscriber
protocol eq http
application "HTTP Server"
no shutdown
exit

Page 62

Advanced Configuration Guide

Application Assurance - Application Identification and User-Defined Applications

IP Protocol
Traffic can be classified using an IP protocol number for non TCP/UDP traffic.
The example below example provides the configuration to classify ICMP IPv4/v6 traffic:
configure application-assurance group 1:1 policy
app-filter
entry <1..65535> create
description "ICMP v4"
protocol eq "non_tcp_udp"
ip-protocol-num eq icmp
application "ICMP"
no shutdown
exit
entry <1..65535> create
description " ICMP v6"
protocol eq "non_tcp_udp"
ip-protocol-num eq ipv6-icmp
application "ICMP"
no shutdown
exit

Custom Protocol
Custom protocols can be used to classify TCP/UDP applications using hexadecimal string
matching (up to 16 hex octets) at a configurable payload offset in the data payload. The expression
string length and offset must not exceed 128 bytes.
To illustrate this feature the Solaris application GoGlobal (similar to VNC it provides remote
access to a server) is used. The snapshot below from Wireshark shows a TCP SYN/ACK session
establishment followed by the first data exchange:

Advanced Configuration Guide

Page 63

Configuration

Figure 11: Wireshark GoGlobal

Wireshark shows that each TCP session payload starts with 80DC0400 (no offset) after the 3way TCP handshake, as a result the configuration required to classify this traffic is described
below.
configure application-assurance group 1:1 policy
custom-protocol 1 ip-protocol-num tcp create
description "goglobal tcp"
expression 1 eq "\x80\xdc\x04\x00" offset 0 direction client-to-server
no shutdown
exit
app-filter
entry <1..65535> create
description "GoGlobal "
protocol eq "custom_01"
application "GoGlobal"
no shutdown
exit

Page 64

Advanced Configuration Guide

Application Assurance - Application Identification and User-Defined Applications

Typical Configuration Mistakes


An operator creating new user-defined applications can make a few typical mistakes which are
listed below:

App-filters in shutdown state. The default app-filter state is shutdown. A no shutdown


command must be executed in order for it to be enabled.

App-filters with no match criteria This is a more troublesome mistake as it will catch
all the traffic entering the filter in a particular application.

Advanced Configuration Guide

Page 65

Configuration

Troubleshooting Application Identification


Show Commands
Router/Partition Statistics
Partition level statistics are not updated in real time. Instead, statistics for a particular flow are
updated either at flow closure or every 5 minutes. The 5 minute sliding window interval is a
common interval for all flows in a given ISA MDA. Different ISA MDAs will have a different 5
minute windows as this interval is set at the MDA boot time.
The following command can be used to view the statistics for all applications configured in the
ISA Group 1, Partition 1:
show application-assurance group 1:1 application count
The operator can also identify which app-filters are being hit by the AA policy per partition (this
command is not available per subscriber), it is particularly useful to identify which filters are used
and optionally prune unnecessary app-filters from user-defined applications:
show application-assurance group 1:1 policy app-filter
Note: The app-filter policy is usually relatively large, in which case additional 7x50 SR CLI
functionality can be used to filter out the output and only show the relevant information. The
example below was created for the application FTP:
A:PE# show application-assurance group 1:1 policy app-filter | match "application \"FTP\""
pre-lines 3 post-lines 2
exit
entry 44300 create (2 flows, 1205 B)
protocol eq "ftp_control"
application "FTP"
no shutdown
exit
entry 44301 create (2 flows, 1401 B)
protocol eq "ftp_data"
application "FTP"
no shutdown
exit

Because partition level statistics are not updated in real time it is recommended for
troubleshooting purposes to use subscriber statistics or sub-study statistics.

Page 66

Advanced Configuration Guide

Application Assurance - Application Identification and User-Defined Applications

Subscriber Statistics
Subscriber level statistics can be updated in real time. AA is usually configured by the Operator to
collect subscriber level statistics for all application groups in residential and Wifi, while business
VPNs typically collect Application group and all applications for each site with AA enabled.
The commands below can be used to view per subscriber statistics for all app-groups or
applications configured in ISA Group 1, Partition 1 for the ESM subscriber "Bob" or business
VPN SAP 1/1/1:10:
show application-assurance group 1:1 aa-sub esm "bob" app-group count
show application-assurance group 1:1 aa-sub sap 1/1/1:10 application count
For residential and Wifi it is therefore recommended to use the aa-sub-study feature to view per
subscriber application level statistics. It requires the subscriber to be configured for aa-sub-study
first as described below:
A:PE# configure application-assurance group 1:1 statistics aa-sub-study application
A:PE>config>app-assure>group>statistics>aa-sub-study# aa-sub esm "bob"

Once done, the system will show all application level statistics for this subscriber:
show application-assurance group 1:1 aa-sub-study esm "bob" application count
Note: When the number of flows per ISA card reaches a threshold then per subscriber statistics are
not available in real time anymore and only the snapshot command can be used to display the
statistics recorded in the previous 5 minute interval window:
show application-assurance group 1:1 aa-sub-study esm "bob" snapshot application count

AppFilterMiss
The default policy configuration provides a failsafe application at the very end of the app-filter list
to classify any remaining traffic in the AppFilterMiss application. There should never be any
traffic in this application, this failsafe filter is used as a debug to make sure that there is no major
issues in the configuration.
Note: Traffic can typically be classified as AppFilterMiss when not all protocol signatures are
mapped to a particular application. This could happen when upgrading to a new ISA software and
enabling new protocol signature detection while not ensuring first that the correct application was
provisioned. See the 7x50 SR Release Note upgrade section for more details on AA signature
upgrade.

Advanced Configuration Guide

Page 67

Configuration

Tools
Flow-Record-Search
Traditional show commands may not provide enough information when troubleshooting flow
identification and the operator can use the ISA flow-record-search tool to dump the ISA flow table
for more information. This feature comes with a large number of filtering options documented in
the user guide.
Each flow gives visibility into: Flow ID, Sub-Type, Sub-Name, Initiator, Direction, Source IP,
Dest. IP, IP Protocol, Source Port, Dest. Port, FC, DSCP, Classified, Protocol, Application, AppGroup, Charging Group, Packets tx, Bytes Tx, Packets-discarded, Bytes-discarded etc.
See below for the most commonly used commands.
To show all the flows in a given ISA card per ISA group:partition (can be a very long output, up to
3M entries):
tools dump application-assurance group 1:1 flow-record-search isa 1/2
To show all the flows per AA subscriber in a given group:partition:
tools dump application-assurance group 1:1 flow-record-search aa-sub esm "bob"
To show all the active flows per AA subscriber in a given group:partition:
tools dump application-assurance group 1:1 flow-record-search aa-sub esm "bob" flowstatus active
The flow-record-search command is also available with additional details by adding search-type
detail at the end of the command line. Note that due to the length of the output it is recommended
to paste the CLI output content in a notepad file.

Page 68

Advanced Configuration Guide

Application Assurance - Application Identification and User-Defined Applications

HTTP Host Recorder


SR OS 11.0 R1 introduces the comprehensive cflowd feature which allows AA to export the
HTTP domain extracted from HTTP flows to the 5670 RAM reporting solution, as such it is the
preferred functionality to understand which HTTP hosts are visible in the network.
Prior to SR OS 11.0 R1, the HTTP host recorder is a tool function available in the 7x50 SR to
record HTTP Hosts seen by AA. See the 7x50 OS Multi-Service Integrated Services Adapter
Guide for more details.
A:PE# show debug
debug
application-assurance
group 1:1
http-host-recorder
filter
default-filter-action record
record http-host-app-filter-candidates
exit
rate 100
no shutdown
exit
exit
exit
exit
A:PE# tools dump application-assurance group 1:1 http-host-recorder top bytes

Port Recorder
This function is particularly useful in a business VPN (it can also be used in residential networks).
The port-recorder AA tool function is similar to the http-recorder. It allows the operator to record
which ports are used on selected applications.
It is most commonly used with the applications Unidentified TCP and Unidentified UDP but it can
be configured to record any other applications:
A:PE# show debug
debug
application-assurance
group 1:1
port-recorder
application "Unidentified TCP"
application "Unidentified UDP"
rate 100
shutdown
exit
exit
exit
exit
A:PE# tools dump application-assurance group 1:1 port-recorder top bytes

Advanced Configuration Guide

Page 69

Conclusion

Conclusion
This example, which is intended for Application Assurance (AA) network architects and
engineers, provides the information required to modify an existing AA policy following AA best
practices and guidelines, and provides the necessary troubleshooting information to better
understand application classification using Application Assurance.

Page 70

Advanced Configuration Guide

Application Assurance Asymmetry


Removal

In This Chapter
This section describes Application Assurance asymmetry removal configurations.
Topics in this section include:

Applicability on page 72

Overview on page 73

Configuration on page 74

Conclusion on page 87

Advanced Configuration Guide

Page 71

Applicability

Applicability
This configuration note is applicable to all 7750 SR and 7450 ESS chassis supporting Application
Assurance and was tested on release 11.0R1. Note that Asymmetry Removal is supported on 7750
SR-c12 but not on the 7750 SR-c4. For the Application Assurance Redundancy Protocol (AARP)
feature, the diverting flexpath (FP) must be FP2 or higher as it makes use of spoke SDP divert.
The pre-requisites for this configuration note are a base understanding of AA configuration and
operation for single homed deployments. This note applies to dual-homed SAPs and spoke SDPs
configurations, in a business or residential AA context. AARP is not used for ESM AA
subscribers.

Page 72

Advanced Configuration Guide

Application Assurance Asymmetry Removal

Overview
This section is intended for Application Assurance (AA) network architects and engineers. It
provides best practices recommendations to configure AA Asymmetry Removal.
Asymmetry means that the two directions of traffic for a given flow (to-sub and from-sub) take
different paths through the network. Asymmetry removal is a means of eliminating traffic
asymmetry between a set of dual-homed SAP or spoke SDP endpoints. This can be across
endpoints within a single node or across a pair of inter-chassis link connected routers, which is the
topology explained in this section. Asymmetry removal ensures all packets of a dual-homed AA
subscriber are diverted to a given AA ISA in order to achieve accurate per subscriber traffic
identification and policy enforcement.
Traffic asymmetry is created when there are dual-homed links for a given service, and the links are
simultaneously carrying traffic. Asymmetry removal for transit subscribers must be implemented
in the first routed hop on the network side of the subscriber management point, so there will be a
deterministic and fixed SAP/spoke SDP representing the downstream subscriber management
node. This ensures there are no more than two paths that the flows can take, both covered by the
asymmetry removal solution.

Advanced Configuration Guide

Page 73

Configuration

Configuration
Application Assurance Redundancy Protocol (AARP) provides the data plane connectivity for
dynamically keeping a dual-homed AA subscribers traffic on the same ISA-AA for AA
processing. An AARP instance is configured between the dual-homed routers to establish
connectivity with the same AARP instance number on each node.
When asymmetry exists between dual-chassis redundant systems, Ipipe spoke SDPs are used to
interconnect these services between peer nodes over an Inter-Chassis Link (ICL). The following
sections explain the configuration and operation of the services for use with the Application
Assurance Redundancy Protocol.

AARP Service Configuration


The following services must be configured to establish communications between the AARP
instances in each of the paired nodes.

Page 74

Network topology is a VPRN (or IES) service configured in each node, with a dualhomed SAP from each node to a downstream access element.

Assumes starting point with AA ISAs installed with identical AA policy and divert
enabled in each node.

Also, the system needs basic routing and LDP configuration for the SDP and the spoke
SDPs to be established.

Advanced Configuration Guide

Application Assurance Asymmetry Removal

MPLS CORE
AARP InterfacesNetwork Side Shunt
(SpokeSDP)
10.1.1.2

10.1.1.1

21:213

PE-2
Backup AARP

12:201
21:201

IPIPE
210 21:200

VPRN
200

12:213
12:212

IPIPE
210

21:212

VPRN
200

PE-1
Master AARP

12:200

SAP 1/1/4:200
App Profile appProf1
AARP Instance 200

SAP 1/1/4:200
App Profile appProf1
AARP Instance 200

AARP InterfacesSubcriber Side Shunt


(Spoke SDP)
7450/BRAS
al_0242

Figure 12: Application Assurance Asymmetry Removal Topology

Table 3: Application Assurance Asymmetry Removal Topology


On PE-2

On PE-1

system ip: 10.1.1.2

system ip: 10.1.1.1

dual-homed service: 200

dual-homed service: 200

dual-homed sap: 1/1/4:200

dual-homed sap: 1/1/4:200

app-profile diverting: yes

app-profile diverting: yes

Advanced Configuration Guide

Page 75

Configuration

Configuration Commands for AARP


To enable AARP, AARP instances and AARP interfaces on both nodes must be configured. AARP
operation has the following dependencies between the nodes:

Shunt links configured and operationally up, both subscriber side shunt and network side
shunt.

Peer communications established between nodes, AARP instance operational status will
be up when peers are communicating.

Dual-homed sap/spoke SDP configured with a unique AARP instance (matched by dualhomed interface).

App-profile configured against sap/spoke SDP with divert enabled (making the sub an aasub). The app-profile is the trigger to divert the traffic node with the active AARP
instance to one of the ISAs in that node, per normal AA divert behavior.

Begin with PE-2:


configure
aarp 200 create
description "aarp protecting a dual-homed sap"
peer 10.1.1.1
priority 100
no shutdown
exit

Ipipe shunt configuration


configure service
sdp 21 mpls create
far-end 10.1.1.1
ldp
keep-alive
shutdown
exit
no shutdown
exit
ipipe 210 customer 1 vc-switching create
service-mtu 9174
spoke-sdp 21:200 create
aarp 200 type subscriber-side-shunt
no shutdown
exit
spoke-sdp 21:201 create
aarp 200 type network-side-shunt
no shutdown
exit
no shutdown
exit

Page 76

Advanced Configuration Guide

Application Assurance Asymmetry Removal

Dual-homed and Interface Shunt Configuration


vprn 200 customer 1 create
description "VPRN 200 Dual Homed Routed Service"
interface "bras1" create
sap 1/1/10:4 create
app-profile "appProf1"
aarp 200 type dual-homed
exit
exit
aarp-interface "subside_1" create
spoke-sdp 21:212 create
aarp 200 type subscriber-side-shunt
no shutdown
exit
exit
aarp-interface "netside_1" create
spoke-sdp 21:213 create
aarp 200 type network-side-shunt
no shutdown
exit
exit

Then similarly configure the associated AARP configuration on PE-1:


configure
application-assurance
aarp 200 create
description "aarp protecting a dual-homed sap"
peer 10.1.1.2
priority 200
no shutdown
exit

Ipipe Shunt Configuration


sdp 12 mpls create
far-end 10.1.1.2
ldp
keep-alive
shutdown
exit
no shutdown
exit
ipipe 210 customer 1 vc-switching create
service-mtu 9174
spoke-sdp 12:212 create
aarp 200 type subscriber-side-shunt
no shutdown
exit
spoke-sdp 12:213 create
aarp 200 type network-side-shunt
no shutdown
exit
no shutdown
exit

Advanced Configuration Guide

Page 77

Configuration

Dual-homed and Interface Shunt Configuration


vprn 200 customer 1 create
interface "bras1" create
sap 1/1/4:200 create
description "AA enabled SAP"
aarp 200 type dual-homed
app-profile "appProf1"
exit
exit
aarp-interface "subside_1" create
spoke-sdp 12:200 create
aarp 200 type subscriber-side-shunt
no shutdown
exit
exit
aarp-interface "netside_1" create
spoke-sdp 12:201 create
aarp 200 type network-side-shunt
no shutdown
exit
exit

Page 78

Advanced Configuration Guide

Application Assurance Asymmetry Removal

Show Commands for AARP


Verify correct configuration on each node. The following output displays the example
configuration for PE-1.
Starting with the AARP instance in each node, verify that the AARP instance operational state is
up (if everything is properly configured as intended):
*A:PE-1# show application-assurance aarp 200
========================================================================
AARP Instance 200
========================================================================
Description
: aarp protecting dual homed sap
Admin State
: Up
Oper State
: Up
Local IP
: 10.1.1.1
Local State
: master
Local Priority : 200

Peer IP
Peer State
Peer Priority

: 10.1.1.2
: backup
: 100

Local Flags
: none
Peer Flags
: none
Peer End-Point : none
Master Selection Mode
: minimize-switchovers
------------------------------------------------------------------------------Service References
------------------------------------------------------------------------------Service
Reference
Reference Type
------------------------------------------------------------------------------VPRN 200
1/1/4:200
Dual-Homed
Ipipe 210
12:212
Subscriber-Side Pipe Shunt
Ipipe 210
12:213
Network-Side Pipe Shunt
VPRN 200
12:200
Subscriber-Side AARP-Interface Shunt
VPRN 200
12:201
Network-Side AARP-Interface Shunt
------------------------------------------------------------------------------No. of service references: 5

Verifying that the AARP instance is up is an indication that the dual-node communications for
AARP is working (instance, shunts, etc.). In addition, in the above output, verify on both PE nodes
that the intended SAPs are dual-homed for that instance.
Now a detailed review of the configured AARP shunt infrastructure services can be shown to
make sure they are all properly configured with intended AARP parameters (such as AARP ID
and Type on the network and subscriber side shunts) as displayed in the following output:
*A:PE-1>show# service id 210 all
===============================================================================
Service Detailed Information
===============================================================================
Service Id
: 210
Vpn Id
: 0
Service Type
: Ipipe
Name
: (Not Specified)
Description
: (Not Specified)

Advanced Configuration Guide

Page 79

Configuration

Customer Id
: 1
Creation Origin
: manual
Last Status Change: 05/29/2013 12:48:25
Last Mgmt Change : 05/27/2013 13:47:32
Admin State
: Up
Oper State
: Up
MTU
: 9174
Vc Switching
: True
SAP Count
: 0
SDP Bind Count
: 2
CE IPv4 Discovery : n/a
CE IPv6 Discovery : n/a
Stack Cap Sig
: n/a
------------------------------------------------------------------------------ETH-CFM service specifics
------------------------------------------------------------------------------Tunnel Faults
: ignore
------------------------------------------------------------------------------Service Destination Points(SDPs)
------------------------------------------------------------------------------------------------------------------------------------------------------------Sdp Id 12:212 -(10.1.1.2)
------------------------------------------------------------------------------Description
: (Not Specified)
SDP Id
: 12:212
Type
: Spoke
Spoke Descr
: (Not Specified)
Split Horiz Grp
: (Not Specified)
VC Type
: Ipipe
VC Tag
: 0
Admin Path MTU
: 0
Oper Path MTU
: 9174
Delivery
: MPLS
Far End
: 10.1.1.2
Tunnel Far End
: 10.1.1.2
LSP Types
: LDP
Hash Label
: Disabled
Hash Lbl Sig Cap : Disabled
Oper Hash Label
: Disabled
Admin State
: Up
Oper State
: Up
...
Application Profile: None
Transit Policy
: None
AARP Id
: 200
AARP Type
: subscriber-side-shunt
...
------------------------------------------------------------------------------IPIPE Service Destination Point specifics
------------------------------------------------------------------------------Configured CE IPv4 Addr: n/a
Peer CE IPv4 Addr : 0.0.0.0
------------------------------------------------------------------------------Sdp Id 12:213 -(10.1.1.2)
------------------------------------------------------------------------------Description
: (Not Specified)
SDP Id
: 12:213
Type
: Spoke
Spoke Descr
: (Not Specified)
Split Horiz Grp
: (Not Specified)
VC Type
: Ipipe
VC Tag
: 0
Admin Path MTU
: 0
Oper Path MTU
: 9174
Delivery
: MPLS
Far End
: 10.1.1.2
Tunnel Far End
: 10.1.1.2
LSP Types
: LDP
Hash Label
: Disabled
Hash Lbl Sig Cap : Disabled
Oper Hash Label
: Disabled
Admin State
...

Page 80

: Up

Oper State

: Up

Advanced Configuration Guide

Application Assurance Asymmetry Removal

Application Profile:
Transit Policy
:
AARP Id
:
AARP Type
:
...

None
None
200
network-side-shunt

Next, the configuration of the VPRN service of the dual-homed SAP can be reviewed to ensure it
reflects the attached endpoints for the shunt Ipipe spoke SDPs:
*A:PE-1>show>service>id 200 all
===============================================================================
Service Detailed Information
===============================================================================
Service Id
: 200
Vpn Id
: 0
Service Type
: VPRN
Name
: (Not Specified)
Description
: (Not Specified)
Customer Id
: 1
Creation Origin
: manual
Last Status Change: 05/27/2013 13:47:32
Last Mgmt Change : 05/27/2013 13:47:32
Admin State
: Up
Oper State
: Up
Route Dist.
AS Number
ECMP
Max IPv4 Routes
Max IPv6 Routes
Ignore NH Metric
Hash Label
Vrf Target
Vrf Import
Vrf Export
MVPN Vrf Target
MVPN Vrf Import
MVPN Vrf Export
Car. Sup C-VPN
Label mode
BGP VPN Backup

:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:

65004:1
None
Enabled
No Limit
No Limit
Disabled
Disabled
target:65004:200
None
None
None
None
None
Disabled
vrf
Disabled

SAP Count
...

: 4

VPRN Type
Router Id
ECMP Max Routes
Auto Bind

:
:
:
:

regular
10.1.1.1
1
LDP

SDP Bind Count

: 2

------------------------------------------------------------------------------Service Destination Points(SDPs)


------------------------------------------------------------------------------------------------------------------------------------------------------------Sdp Id 12:200 -(10.1.1.2)
------------------------------------------------------------------------------Description
: (Not Specified)
SDP Id
: 12:200
Type
: Spoke
Spoke Descr
: (Not Specified)
VC Type
: n/a
VC Tag
: n/a
Admin Path MTU
: 0
Oper Path MTU
: 9174
Delivery
: MPLS
Far End
: 10.1.1.2
Tunnel Far End
: 10.1.1.2
LSP Types
: LDP
Hash Label
: Disabled
Hash Lbl Sig Cap : Disabled

Advanced Configuration Guide

Page 81

Configuration

Oper Hash Label

: Disabled

Admin State
:
...
Application Profile:
Transit Policy
:
AARP Id
:
AARP Type
:

Up

Oper State

: Up

None
None
200
subscriber-side-shunt

...
------------------------------------------------------------------------------IPIPE Service Destination Point specifics
------------------------------------------------------------------------------Configured CE IPv4 Addr: n/a
Peer CE IPv4 Addr : 0.0.0.0
------------------------------------------------------------------------------Sdp Id 12:201 -(10.1.1.2)
------------------------------------------------------------------------------Description
: (Not Specified)
SDP Id
: 12:201
Type
: Spoke
Spoke Descr
: (Not Specified)
VC Type
: n/a
VC Tag
: n/a
Admin Path MTU
: 0
Oper Path MTU
: 9174
Delivery
: MPLS
Far End
: 10.1.1.2
Tunnel Far End
: 10.1.1.2
LSP Types
: LDP
Hash Label
: Disabled
Hash Lbl Sig Cap : Disabled
Oper Hash Label
: Disabled
Admin State
...

: Up

Application Profile:
Transit Policy
:
AARP Id
:
AARP Type
:
...

Oper State

: Up

None
None
200
network-side-shunt

Continuing deeper into the same VPRN service show output, it can be verified that the dualhomed SAP itself is properly configured and associated with that service and AARP instance:
------------------------------------------------------------------------------SAP 1/1/4:200
------------------------------------------------------------------------------Service Id
: 200
SAP
: 1/1/4:200
Encap
: q-tag
Description
: (Not Specified)
Admin State
: Up
Oper State
: Up
Flags
: PortOperDown
Multi Svc Site
: None
Last Status Change: 05/27/2013 13:47:32
Last Mgmt Change : 05/27/2013 13:47:32
Sub Type
: regular
Dot1Q Ethertype
: 0x8100
QinQ Ethertype
: 0x8100
Split Horizon Group: (Not Specified)
Admin MTU
Ingr IP Fltr-Id

Page 82

: 1518
: n/a

Oper MTU
Egr IP Fltr-Id

: 1518
: n/a

Advanced Configuration Guide

Application Assurance Asymmetry Removal

Ingr Mac Fltr-Id


Ingr IPv6 Fltr-Id
BGP IPv4 FlowSpec
BGP IPv6 FlowSpec
tod-suite

:
:
:
:
:

n/a
n/a
Disabled
Disabled
None

Egr Mac Fltr-Id


Egr IPv6 Fltr-Id

: n/a
: n/a

qinq-pbit-marking : both
Egr Agg Rate Limit: max

Q Frame-Based Acct : Disabled


Acct. Pol

: None

Anti Spoofing
: None
Avl Static Hosts
: 0
Calling-Station-Id : n/a
Application Profile:
Transit Policy
:
AARP Id
:
AARP Type
:
Oper Group
Host Lockout Plcy
Lag Link Map Prof
...

Collect Stats

: Disabled

Dynamic Hosts
Tot Static Hosts

: Enabled
: 0

Monitor Oper Grp

: (none)

appProf1
ip 200
200
dual-homed

: (none)
: n/a
: (none)

Advanced Configuration Guide

Page 83

Configuration

Network to Subscriber Traffic Flow


When the AARP is operationally up, AARP tracks which ISA is the master ISA for each dualhomed AARP instance and uses the inter-chassis services (spoke SDP AARP shunts) to move all
traffic for each instance traffic to the node with the Master ISA.
Looking at traffic in the network to subscriber direction (Figure 13):

Traffic arriving on PE-1 is diverted to the local master ISA, processed, then proceeds to
the egress SAP.

Traffic arriving on PE-2 with the backup AARP interface is sent to the master node for
AA processing. The ingress FP forwards packets to network-side-shunt AARP interface
for remote AA divert.

Arriving on PE-1, the packets on the AARP Ipipe are diverted to the master ISA where the
packets are processed as if this traffic was travelling in the to-sub direction towards the
dual-homed endpoint on PE-1, then returned to PE-2.

Entering PE-2, the traffic from the subscriber side shunt interface is not diverted to ISAs
in that node and egresses on the AARP instance SAP.

With this behavior, traffic always returns to the original ingress node before egressing toward the
subscriber (network path for the flows are not modified).
Ingress FP routing/destination
lookup from AARP backup interface.
Forwards packets network-sideshunt AARP interface for remote
AA divert.

Traffic to/from backup AARP is sent to


the master Node for AA Divert

MPLS CORE

AA divert to AA-ISA for flow


processing (divert to ISA paths
not shown).

21:213

PE-2
Master AARP
AA Sub Context
No AA Flow Records

12:201
21:201

VPRN/
IES

12:213

VPRN/
IES

IPIPE

IPIPE
21:200

12:212

21:212

PE-1
Master AARP
AA Sub Context
AA Flow Records

12:2.0.0
AA-Subscriber Interface

AA-Subscriber Interface

Traffic not diverted to the


MS-ISA and forwarded to
its destination.

7450/BRAS
al_0243

Figure 13: Network to Subscriber Traffic Flow

Page 84

Advanced Configuration Guide

Application Assurance Asymmetry Removal

Subscriber to Network Traffic Flow


Looking at traffic in the subscriber to network direction (Figure 14):

Traffic arriving on PE-1 is diverted to the local master ISA, processed, then proceeds to
the egress SAP.

Traffic arriving on PE-2 with the backup AARP ISA is sent to the master node for AA
processing (not diverted to an ISA in PE-2). The ingress FP forwards packets to
subscriber-side-shunt AARP interface for remote AA divert.

Arriving on PE-1, the packets on the AARP Ipipe are diverted to the master ISA where the
packets are processed as if the traffic was flowing in the from-sub direction on the dualhomed endpoint, then returned to PE-2 over the Ipipes AARP subscriber-side-shunt.

Entering PE-2, the traffic from the network side shunt interface is forwarded by the IES/
VPRN service to its destination.
Traffic to/from backup
AARP interface is sent to
the master Node for AA
Divert

MPLS CORE
Traffic forwarded to
its destination by FP.

21:213

PE-2
Backup AARP
AA Sub Context
No AA Flow Records

12:201
21:201

VPRN/
IES

12:213

21:200

12:212

21:212

PE-1
Master AARP
AA Sub Context
AA Flow Records

12:200
AA-Subscriber
Interface
ber In

AA-Subscriber Interface

Ingress FP routing/destination
lookup from backup AARP interface.
Forwards packet to subscriber-sideshunt AARP interface for remote
AA divert.

VPRN/
IES

IPIPE

IPIPE

AA divert to AA-ISA for flow


processing (divert to ISA paths
not shown).

7450/BRAS
al_0244

Figure 14: Subscriber to Network Traffic Flow

Advanced Configuration Guide

Page 85

Configuration

Typical Configuration Mistakes


Operators configuring AARP can make some typical mistakes listed below that will keep the
AARP instance in Operational State down:

Page 86

The spoke SDP AARP shunt instances IDs must be aligned with the respective spoke
SDP on the peer node: if not, it will result in a flag indicating shunt mismatch in the
show output.

Ipipe service MTU alignment The Ipipe service MTU values must be the same in both
nodes, otherwise it will result in the services be in operational status UP, but the AARP
instance will remain down.

Advanced Configuration Guide

Application Assurance Asymmetry Removal

Conclusion
This section is intended for Application Assurance (AA) network architects and engineers to
provide the information required to understand and configure dual-node asymmetry removal
following the intended service configuration as used by the AARP implementation.

Advanced Configuration Guide

Page 87

Conclusion

Page 88

Advanced Configuration Guide

Application Assurance Stateful


Firewall

In This Chapter
This section describes Application Assurance stateful firewall (FW) configurations for protecting
residential and WiFi subscribers.
Topics in this section include:

Applicability on page 90

Overview on page 91

Configuration on page 95

Conclusion on page 106

Advanced Configuration Guide

Page 89

Applicability

Applicability
This configuration note is applicable to all 7750 SR/SR-c and 7450 ESS chassis supporting
Application Assurance (AA).
The configuration was tested on release 11.0R1.

Page 90

Advanced Configuration Guide

Application Assurance Stateful Firewall

Overview
The AA SR OS 11.0R1 FW feature extends AA-ISA application level analysis to provide an inline integrated stateful service that protects subscribers from malicious attacks. AA stateful packet
filtering feature combined with AA L7 classification and control, empowers operators with
advanced, next generation firewall functionality that is integrated within the Service Router. The
AA stateful firewall (FW) and application firewall runs on AA-ISA. Using stateful inspection, the
AA firewall not only inspects packets at layers 3-7, but also monitors and keeps track of the
connection's state. If the operator configures a deny action within a session filter, then the
matching packets (matching both the AA Application QoS policy (AQP) and associated session
filter match conditions) are dropped and no flow session state/context is created.
AA FW can be used in all deployments of AA-ISA; mobile (MGOS) and fixed (SROS), however
the configurations examples here, while still very applicable (and almost 100% identical in mobile
deployments) are focused on AA-ISA deployments in fixed networks.
The AA-ISA FW enabled solution provides:

Stateful (and stateless) packet filtering and inspection with application-level gateway
(ALG) support

DoS attack protection

The objective of this section is to describe the required configuration within AA-ISA (divert to
AA-ISA basic knowledge is assumed) in order to enable AA FW and protect AA subscribers from
attacks (Unsolicited attacks and DoS attacks), while still allowing pin-holing through the firewall,
so that applications like peer to peer gaming and various ALGs (such as FTP) are not affected.

Stateful Filtering
By performing stateful inspection, AA-ISA takes into account which side initiated a session and
acts accordingly. Stateful flow processing and inspection utilizes IP layers 3/ 4 header information
to build a state of the flow within AA-ISA. Layer 7 inspection is used in order to provide ALG
support. Stateful flow/session processing takes note of the originator of the session and hence can
allow traffic to be initiated from the subscriber, while denying (when configured) traffic
originating from the network. Packets received from the network are inspected against the session
filter and only those that are part of a subscriber initiated session are allowed.

Advanced Configuration Guide

Page 91

Overview

alcatel-lucent.com
Stateful Packet
Inspection Firewall
1 Request a
web page.
2 Heres the web page
you asked for.

Internet
Subscriber
Device
3 This was requested by
a computer on the home
network, deliver it.

Hacker
1 Heres the web
file transfer you
asked for.

2 This was not requested by


a computer on the home
network, drop it.

al_0254

Figure 15: Block Unsolicited Traffic

To support the example shown in Figure 15, AA is configured with an action to block unsolicited
traffic; traffic that is not originated/initiated from the subscriber. The direction field in match
criteria of AQPs is utilized to enable this functionality.

Gaming Server
Internet
Hacker

Discarded

P2P Gaming
(With Server
based
Registration)

Subscriber
1

Unsolicited Traffic
from Internet
or On-net

Web-access

Subscriber
2

Hacker
al_0255

Figure 16: SFW Allow Gaming

Page 92

Advanced Configuration Guide

Application Assurance Stateful Firewall

Figure 16 shows a similar concept. It is used to allow UDP traffic for peer to peer applications
(such as gaming). Once the traffic from one peer is seen by AA-ISA, a pin-hole is opened in the
reverse direction to allow for the corresponding UDP traffic from the peer.
Stateless packet filtering on the other hand does not take note of the session initiator. It discards or
allows packets independently of any previous packets. In addition to AA-ISAs support for
stateless (and stateful) filtering, stateless packet filtering can be performed in the system using line
card ACLs (and/or MGISM PCC rules in mobile gateway deployments).

Application Layer Gateway Filtering


Active Mode FTP
Connection

Client

Data Port
38069

Command Port
37843

Server

Command Port
21

Data Port
20

AA-FW
Client uses random port to
connect to servers port 21 to
establish connection
Server then opens data connection from servers
port 20 to clients computer on a random port

2. AA FW inspects
the flow and open
a pinhole for the
dataport (38069)

1. AA FW allows
the flow since it is
initiated by the user
al_0256

Figure 17: ALG Support Example FTP

AA FW inspection of packets at Layer 7 offers Application Layer Gateway functionality for a


large list of applications (for example, FTP, SIP, RTSP, PPTP, IRC, etc.). These applications make
use of control channels or flows that spawn other flows. AA FW inspects the payload of these
control flows so it can open a pinhole in advance for unspawned data flows. Figure 17 depicts an
example of AA ALG support for FTP traffic.

Advanced Configuration Guide

Page 93

Overview

Denial Of Service (DOS) Protection


DoS attacks work by consuming network and system resources, making them unavailable for
legitimate network applications. Network flooding attacks, malformed packets and port scans are
examples of such DoS attacks.
The aim of AA FW DOS protection is to protect subscribers and prevent any abuse of network
resources.
Using AA FW stateful session filters, operators can protect their subscribers from any port scan
scheme. This can be done by configuring the session filters to disallow any traffic that is initiated
from the network.
Furthermore, AA ISA provides configurable flow policers. These policers, once configured,
prevent a wide range of flooding attacks (such as ICMP PING flooding, UDP flooding, SYN
Flood Attack...etc.). These policers provide protection at multiple levels; per system per
application/application groups and per subscriber per applications/applications groups.
There are two types of AA ISA flow policers; flow setup rate policers and flow count policers.
Flow setup rate policers limit the number of new flows, while flow count policers limit the total
number of active flows.
In order to protect hosts and network resources, AA FW validates/checks different fields in the
packets header (checksum, TCP Flag, etc.) and if any fails it declares the packet to be invalid.
This complements the 7x50 subscriber management enhanced security features, such as IP (or
MAC) anti-spoofing protection (such as protecting against LAND attacks) and network protocol
DoS protections. The cut-through-drop AQP action must be configured in order to drop these
types of invalid packets.

Virtual FW/Zone-Based FW
AA FW can provide up to 128 virtual FWs, each with its own FW policies. This is achieved
through the use of AA-partitions.
In addition, AA subscribers within the same AA partition can have different application profiles
with different Application Service Options (ASO) values. This provides a further control
mechanism to enable/disable firewall rules.
For example, the operator may want to have some subscribers possess full firewall protection,
while others (who have not subscribed to this service) to have a partial firewall protection that
focuses on protecting network resources, rather than network and subscribers resources.

Page 94

Advanced Configuration Guide

Application Assurance Stateful Firewall

Configuration
AA-ISA AQPs are enhanced in R11.0R1 with several new AQP actions that provide session
filtering functionality. As is the case of all AQPs, these have partition level scope, which allows
different FW policies to be implemented by utilizing AA partitions concepts within the same AAISA group. Hence, multiple virtual AA FW instances can be realized, without the need for
multiple physical instances of FWs to implement different FW policies.
The AA FW stateful session filter consists of multiple entries (similar to ACLs) with a match an
action per entry. Actions are deny or permit. A deny action results in packets being discarded
without creating a session/flow context. Match conditions include IP protocol types, source and
destination IP addresses and ports. An overall default action is also configurable in case of no
match to any session filter entry.
Note that AQPs with session filter actions need to have, as a matching condition; traffic direction,
ASOs and/or a subscriber name. These AQP match rules cannot have any references to
applications and/or application groups.
An AQP action to drop malformed/errored packets is also available.
Statistics are incremented when packets are dropped by a session filter. These are accounted
against:
protocol = denied by default policy,
application= unknown,
application group = unknown.
The configuration topology is shown in Figure 18.

Advanced Configuration Guide

Page 95

Configuration

Gaming Server
Internet
ISP-Management
Sub-Net

Hacker

LAN1: 10.10.8.0/24
LAN2: 192.168.0.0/24

Unsolicited Traffic
(Not Dropped)

P2P Gaming
(With Serverbased
Registration)

Unsolicited Traffic
(Dropped)
Except from
ISPs Management
Subnets
Web-access

Subscriber
1

Subscriber
2

app-profile
ProtectedSub

app-profile
ProtectedSub

Hacker

Subscriber
3
(Unprotected)
app-profile
not_ProtectedSub

al_0257

Figure 18: Configuration Topology

Step 1. Application Profile configuration:


There is nothing new introduced in application profiles in order to support FW. This section deals
with how to configure the application profile to allow differentiated FW services for different
subscribers. In a nut shell, the AA common building construct/attribute for differentiated policy is
ASO.
To configure an ASO for FW protection:
configure application-assurance group 1:2 policy
begin
app-service-options
characteristic "FW-Protection" create
value "None"
value "ON"
default-value "None"
exit
characteristic "ISP-Protection" create
value "None"
value "ON"

Page 96

Advanced Configuration Guide

Application Assurance Stateful Firewall

default-value "None"
exit
characteristic "DOS-Protection" create
value "None"
value "ON"
default-value "None"
exit
exit

In the above example:

ASO FW protection allows the operator to select if the subscriber is FW protected or not.

ASO DOS protection refers to if the subscriber is protected from DOS attacks.

ASO ISP protection is different from the above two as it protects the ISP resources by (in
the example that follows) not allowing unsolicited traffic. This should be ON for all
subscribers (it is then arguable if someone needs it to be defined in the ASO list, instead of
merely configuring an AQP to protect ISP resources all the time).

These ASOs are referenced in appProfiles (and later in AQPs) as follows:


configure application-assurance group 2:103 policy
begin
app-profile "Protected" create
divert
characteristic "FW-Protection" value "ON"
characteristic "ISP-Protection" value "ON"
characteristic "DOS-Protection" value "ON"
exit

The above application profile Protected is assigned to subscribers who opted/subscribed to the
firewall protection service; for example sub 1 and sub 2 in the example shown in Figure 18 on
page 96.
Subscribers who are not protected (for example sub 3 in Figure 18) are assigned a different profile:
configure application-assurance group 2:103 policy
begin
app-profile "unProtected" create
divert
characteristic "FW-Protection" value "ON"
characteristic "ISP-Protection" value "ON"
characteristic "DOS-Protection" value "ON"
exit

An alternative method to using application profiles/ASOs to provide differentiated services is to


configure multiple partitions with different AQPs/ session filters. One partition for example will
be for subscribers who are provided with firewall protection, while another is used for subscribers

Advanced Configuration Guide

Page 97

Configuration

who are not protected. This configuration is simpler and provides statistics per partition. This
example however covers the more complex case using ASOs/appProfiles.
Step 2. Flow count policer configuration:
configure application-assurance group 2:203 policer Dos_police_Flow_count type flow-countlimit granularity subscriber create
flow-count 500
exit

The configuration above limits the number of flows a subscriber can have at any time to 500. This
is done to protect against DoS attacks. The value 500 is arbitrary and requires tuning for each
deployment.
configure application-assurance group 2:203 policer Dos_Police_ICMPFlows type flow-countlimit granularity system create
flow-count 5000
exit

This configuration limits the total number of flows that matches the configured AQP matching
condition. It is used for ICMP applications to prevent mass port scanning.
Step 3. Application configuration
The following configuration is standard with AppDB. It is shown here for reference.
configure application-assurance group 2:203 policy begin
application ICMP create
exit
app-filter
entry 1540 create
protocol eq "non_tcp_udp"
ip-protocol-num eq icmp
application "ICMP"
no shutdown
exit
entry 35500 create
protocol eq "non_tcp_udp"
ip-protocol-num eq ipv6-icmp
application "ICMP"
no shutdown
exit

Step 4. AQP configuration:


configure application-assurance group 2:103 policy
begin
app-qos-policy
description "Protecting ISP1 from DoS attacks from subs"
entry 100 create
match

Page 98

Advanced Configuration Guide

Application Assurance Stateful Firewall

traffic-direction subscriber-to-network
characteristic "ISP-Protection" eq "ON"
dst-ip eq 10.10.8.0/24
exit
action
flow-count-limit Dos_police_Flow_count
exit
no shutdown
exit
entry 105 create
description "Protecting ISP2 from DoS attacks from subs"
match
traffic-direction subscriber-to-network
characteristic "ISP-Protection" eq "ON"
dst-ip eq 192.168.0.0/24
exit
action
flow-count-limit Dos_police_Flow_count
exit
no shutdown
exit

These AQPs protect the ISP network by limiting the number of concurrent flows. Dropping
malformed packets is done by entry 130 (later).
To guard against ICMP flooding attacks, a flow count policer (defined earlier) is used as follows:
configure application-assurance group 2:103 policy
begin
app-qos-policy
entry 107 create
match
traffic-direction both
application eq icmp
exit
action
flow-count-limit Dos_Police_ICMPFlows
exit
no shutdown
exit

In order to protect ISP LAN2 from all incoming traffic (unsolicited), the operator configures entry
120.
entry 120 create
match
traffic-direction subscriber-to-network
characteristic ISP-Protection" eq ON"
exit
action
session-filter ProtectISPLan2"
exit
no shutdown
exit

Advanced Configuration Guide

Page 99

Configuration

ProtectISPLan2 session filter drops all unsolicited traffic to LAN2 (highly secure) except for
access to FTP services coming from ISP LAN1. Details of these configurations are shown in
Session-Filter on page 100.
To enable stateful protection for opted-in subs:
configure application-assurance group 2:103 policy
begin
app-qos-policy
entry 110 create
description "FW for managed opted-in subs"
match
traffic-direction network-to-subscriber
characteristic "FW-Protection" eq "ON"
exit
action
session-filter "denyUnsolictedwMgntCntrl "
exit
no shutdown
exit

The above AQP protects opt-in subscribers from unsolicited traffic but still allows unsolicited
traffic from ISP subnets to manage the subscribers network.
Dropping malformed/illegal packets and protecting against DOS attacks is done via entry 130
below.
entry 130 create
match
traffic-direction both
characteristic "DoS-Protection" eq "ON"
exit
action
cut-through-drop
flow-count-limit Dos_police_Flow_count
exit
no shutdown
exit

Step 5. Session-Filter
The following displays session-filter configuration commands.
configure application-assurance group 1:1 session-filter <name> create
description <description>
default-action permit|deny# default=deny
entry n create
description <entry-description>
match
ip-protocol-num <ip-protocol-number>

Page 100

Advanced Configuration Guide

Application Assurance Stateful Firewall

no src-ip <ip4_or_v6-address/mask>
no dst-ip <ip4_or_v6-address/mask>
no src-port {eq|gt|lt} <port-num> #or
range <start-port-num> <end-port-num>
no dst-port {eq|gt|lt} <port-num> #or
range <start-port-num> <end-port-num>
exit
action permit|deny
exit
entry m create
. . .

Advanced Configuration Guide

Page 101

Configuration

Parameters

entry n A session filter can have multiple match-action rules, each of these matchaction rules represent an entry within the session-filter. The entries are executed in order.
If a match is found, within one entry, the subsequent entries within the session-filter are
skipped (not evaluated).

default-action [permit|deny] This action is performed if no match is found for any of


the configured entries within the session-filter. Default is deny.
A deny action will drop the packet and will not allow a flow record to be allocated for
that flow. Note that a drop action within AA AQP will drop the packet but it will still
create flow record.
A permit action will allow the packet to flow through the system. A flow record is
also allocated. Note that the packet may get dropped by other configured AQP actions
(due to header check failures).

description description-string
This configures a text string, up to 80 characters, which can be used to describe the use of
the session-filter.

match Keywords to perform the action specified under the action keyword only if the
conditions in the match section are met.
ip-protocol ip-protocol-number
ip-protocol-number 1..255

Decimal, hexadecimal or binary representation

Supported IANA IP protocol names:


crtp, crudp, egp, eigrp, encap, ether-ip, gre, icmp, idrp, igmp, igp, ip, ipv6, ipv6frag, ipv6-icmp, ipv6-no-nxt, ipv6-opts, ipv6-route, isis, iso-ip, l2tp, ospf-igp,
pim, pnni, ptp, rdp, rsvp, sctp, stp, tcp, udp, vrrp

src-ip/dst-ip ipv4-address/mask
src-ip/dst-ip iv6-address/mask

Source/destination IP address within the packet header.

IPv4 or IPv6 formats are allowed, with prefixes masks.

src-port src-port-numbers
src-port {eq|gt|lt} port-num
eq equal, exact match
gt match port numbers that are greater than the one specified.
lt match port numbers that are smaller than the one specified.
port-num 0..65535 (Applicable to TCP, UDP and SCTP protocols only.)
src-port range start-port-num end-port-num

Page 102

Advanced Configuration Guide

Application Assurance Stateful Firewall

range Keyword- that match port numbers within the specified range:
start-port-num 0..65535
end-port-num 0..65535
dst-port dst-port-number

Same as source port number explained above, but applied against destination port
number.

action deny|permit
deny or permit action is only executed if a match is found.
deny action will drop the packet and will not create a flow record.
permit action will allow the packet to go through (unless another different action is
found that causes it to be dropped).

no entry entry-id
Causes the entry to be deleted.

no session-filter session-filter-name
Causes the session filter to be deleted.

config application-assurance group 1:2


session-filter " denyUnsolictedwMgntCntrl" create
description S-FW opted-in sub allow ISP access"
default-action deny
entry 10 create
description "allow ICMP access from ISP LAN1"
match
ip-protocol-num icmp
src-ip 10.10.8.0/24
exit
action permit
exit
entry 20 create
description "allow ICMP access from ISP LAN2"
match
ip-protocol-num icmp
src-ip 192.168.0.0/24
exit
action permit
exit
entry 30 create
description "allow all TCP (e.g. FTP/telnet)access from ISP LAN2"
match
ip-protocol-num tcp
src-ip 192.168.0.0/24
exit
action permit
entry 40 create
description "allow TCP on port 80 /HTTP access from ISP LAN1"
match
ip-protocol-num tcp
src-ip 10.10.8.0/24
dst-port eq 80
exit

Advanced Configuration Guide

Page 103

Configuration

action permit
exit

This session filter is used to protect systems located in LAN2. It drops all unsolicited traffic except
for FTP coming from LAN1.
configure application-assurance group 1:2
session-filter "protectISPLan2" create
description "S-FW to deny all unsolicited requests to LAN2"
default-action deny
entry 10 create
description "allow ftp access from ISP LAN1"
match
ip-protocol-num tcp
src-ip 10.10.8.0/24
dst-port eq 21
exit
action permit
exit

Show Routine AQP:


*A:PE-1# show application-ass group 2:103 policy app-qos-policy 110
===========================================================
Application QOS Policy Entry 110 (Default Subscriber Policy)
===========================================================
Description : FW for managed opted-in subs
Admin State : in-service
Hits
: 95 flows
Conflicts
: 0 flows
Match :
Traffic Direction
ASO Characteristics
FW-Protection

: network-to-subscriber
:
: eq FW-Protection

Action :
Session Filter
: denyUnsolictedwMgntCntrl
================================================================

Show Routines Session Filter:


*A:PE-1# show application-ass group 2:1 session-filter "denyUnsolictedwMgntCntrl"
===========================================================
AA Session Filter Instance "denyUnsolictedwMgntCntrl"
===========================================================
Description
: S-FW opted-in sub ?allow ISP access
Default Action : deny
AQP Entries
: 110
----------------------------------------------------------Filter Match Criteria

Page 104

Advanced Configuration Guide

Application Assurance Stateful Firewall

----------------------------------------------------------Entry
: 10
Description : allow ICMP access from ISP LAN1
IP Protocol : icmp
Source IP
: 10.10.8.0/24
Action
: permit
Hits
: 3 flows
----------------------------------------------------------Entry
: 20
Description : allow ICMP access from ISP LAN2
IP Protocol : icmp
Source IP
: 192.168.0.0/24
Action
: permit
Hits
: 21 flows
----------------------------------------------------------Entry
: 30
Description : allow TCP access from LAN2
IP Protocol : tcp
Source IP
: 192.168.0.113/32
Action
: permit
Hits
: 50 flows
----------------------------------------------------------Entry
: 40
Description : allow HTTP access from LAN1
IP Protocol : tcp
Source IP
: 10.10.8.0/24
Source Port : eq 80
Action
: permit
Hits
: 2 flows
----------------------------------------------------------No. of entries
: 4
==========================================================

Advanced Configuration Guide

Page 105

Conclusion

Conclusion
The AA stateful packet filtering feature combined with AA Layer 7 classification and control
empowers operators with an advanced, next generation firewall functionality that is integrated
within the SR/ESS. This section focused on traditional stateful and stateless session firewall
functionality.

Page 106

Advanced Configuration Guide

ARP Hosts

In This Chapter
This section describes advanced ARP host configurations.
Topics in this section include:

Applicability on page 108

Summary on page 109

Overview on page 110

Configuration on page 111

Conclusion on page 134

Advanced Configuration Guide

Page 107

Applicability

Applicability
This section describes ARP hosts and is applicable to 7450 ESS, 7750 SR and 7710 SR series and
was tested on SR-OS 7.0 R5. The 7750 SR-c4 is supported from 8.0R4 and higher.

Page 108

Advanced Configuration Guide

ARP Hosts

Summary
In business access area, both DHCP and PPPoE are used. However, it is possible that CPE
network facing interfaces are statically configured. In such cases, the first packet the network on
the user side sees is ARP to the Broadband Service Aggregator (BSA) or Broadband Service
Router (BSR) interface. In order to accommodate such configurations, Alcatel-Lucent Enhanced
Subscriber Management (ESM) feature set supports the ARP host.
In practise this means that authentication, self-provisioning and Service Level Agreement (SLA)
enforcement can be triggered by reception of ARP packets.
The BRAS node will learn the IP-MAC association based on received arp-request packet and will
provision subscriber-hosts based on results from RADIUS authentication, the same way this
would happened through DHCP or PPPoE.
This section provides configuration and troubleshooting commands for arp-hosts. Features
common to other host-types and not unique to arp-hosts are not described in this note. (Not
exhaustive list: RADIUS managed routes, routed subscriber with dynamic BGP peering,
Wholesale/Retail, Managed SAPs configurations, ESM related host limitation mechanisms, host
High-Availability, multi-chassis peer synchronization).
Knowledge of the Alcatel-Lucent Triple Play Service Delivery Architecture (TPSDA) concepts is
assumed throughout this document.

Warning:

Enhanced Subscriber Management and RADIUS authentication are mandatory for the use of
ARP hosts.

Advanced Configuration Guide

Page 109

Overview

Overview
ARP host is supported in bridged CO (VPLS) and routed CO (Subscriber Interface). And it is
triggered by the first arp packet from the host. ARP host is also supported in a wholesale/retail
context and on managed SAPs (MSAP).
The IP and MAC addresses are extracted from the ARP request. They are copied in the accessrequest message send to the RADIUS server:

RADIUS attribute [1] Username = IP address

Alcatel-Lucent VSA [26][27] Client Hardware Address = MAC address

RADIUS will, on successful authentication, reply with an access-accept message on which the
ESM will create the ARP host. ESM string assignment options are out of scope for this scenario.

CPE-4

RADIUS
Server

BSAN-1
CPE-3

CPE-2

sap

sap

sap
CPE-1

sap
BSAN-2

VPLS

sdp

VPRN
PE-1

BSA-1
BSR-1

Bridged-CO
ESM

Routed-CO
ESM
OSSG373

Figure 19: Bridged CO and Routed CO Example

Page 110

Advanced Configuration Guide

ARP Hosts

Configuration
ARP Hosts in a Bridged CO Environment
RADIUS
Server

IPx/MACx
CPE-1

sap
BSAN-2

GW

VPLS

VPRN
PE-1

BSA-1
BSR-1

ARP-Request to
GW BSR-1

ESM

Snoop ARP and Extract IP/MAC


From ARP-Request

Access-Request
USER NAME [1] IPx
VSA [26] 19 Alcatel (6527)
CHADDR [27] MACx

Was
Buffered
at BSA-1

Access-Accept

Create Host and Assign


Session-Timeout

ESM-Strings
Optional-Strings

ARP Request to GW BSR-1


ARP Reply

Install ARP-Reply and Assign ARP-Timout


OSSG374

Figure 20: ARP Hosts in a Bridged CO Environment Example

ARP-host-specific enabling for Bridged CO is achieved by a composite service, VPLS on BSA


node and VPRN/IES on BSR node. RADIUS authentication and subscriber management, which
mandates IP-MAC or NH-MAC type anti-spoofing, are mandatory for ARP hosts.

Advanced Configuration Guide

Page 111

Configuration

configure
service
vpls 2 customer 1 create
description "ARP host - Bridged CO"
sap 1/1/3:1 create
authentication-policy "authentication-1"
anti-spoof ip-mac
sub-sla-mgmt
sub-ident-policy "sub-id-default"
no shutdown
exit
arp-host
no shutdown
exit
exit
spoke-sdp 12:2 create
exit
no shutdown

The RADIUS authentication policy does not require specific parameter settings. The RADIUS
username attribute will contain always the host IP address which makes the authentication policy
parameter user-name-format irrelevant for ARP hosts.
configure
subscriber-mgmt
authentication-policy "authentication-1" create
password ALU
radius-authentication-server
server 1 address 172.16.1.1 secret ALU
exit
re-authentication
# optional if re-authentication is required
accept-authorization-change # optional is RADIUS Disconnect is required
exit

The CPE ARPs are snooped and the first CPE ARP triggers a RADIUS accept-request and
subsequent ARPs will trigger RADIUS re-authentication only if the ARP host configurable minauth-interval is expired and the above re-authentication parameter is set. The initial ARP is only
forwarded to the BSR-1 upon successful RADIUS authentication by means of a RADIUS accessaccept message. The same RADIUS access-accept message and the passing the several sessions
limit checks, triggers the creation of the host.
The BSR-1 node requires a VPRN/IES as part of the composite service. No ARP-host-specific
parameters are required on the BSR-1 for the bridged CO model.

Page 112

Advanced Configuration Guide

ARP Hosts

BSR-1
configure
service
vprn 1 customer 1 create
route-distinguisher 64496:1
auto-bind ldp
vrf-target target:64496
interface "int-BSA1-p2mp-1" create
description "ARP host - Bridged CO"
address 10.2.0.6/29
ip-mtu 1500
spoke-sdp 21:2 create
exit
exit

Advanced Configuration Guide

Page 113

Configuration

ARP Hosts in a Routed CO Environment


Server

IPx/MACx
CPE-1

GW

VPRN
PE-1
BSR-1

ARP-Request

Snoop ARP and Extract IP/MAC


From ARP-Request

ESM
Access-Request
USER NAME [1] IPx
VSA [26] 19 Alcatel (6527)
CHADDR [27] MACx
Access-Accept
ESM

ARP Reply

ESM-Strings
Optional-Strings

Create Host and Assign


Session-Timeout and Update
IP ARP Table

Install ARP-Reply and Assign ARP-Timout


OSSG375

Figure 21: ARP Hosts in a Routed CO Environment Example

ARP-host-specific enabling for routed CO is identical for VPRN and IES services. RADIUS
authentication and subscriber management, which mandates IP-MAC or NH-MAC type antispoofing, are mandatory for ARP hosts.
The initial ARP will, only upon successful RADIUS authentication and passing the several
sessions limit checks, create the ARP host. The ARP reply or update of IP ARP table is not
performed on any unsuccessful RADIUS authentication.

Page 114

Advanced Configuration Guide

ARP Hosts

configure
service
vprn 1 customer 1 create
route-distinguisher 64496:1
auto-bind ldp
vrf-target target:64496
description "ARP host - Routed CO"
address 10.1.0.6/29
group-interface "group-int-1" create
authentication-policy "authentication-1"
sap 1/1/1:1 create
anti-spoof ip-mac
sub-sla-mgmt
sub-ident-policy "sub-id-default"
no shutdown
exit
exit
arp-host
no shutdown
exit
exit

Advanced Configuration Guide

Page 115

Configuration

RADIUS User Configuration Bridged/Routed CO


The username in the RADIUS access request is always the static configured IP address from the
CPE and configured as key in the RADIUS users file. The RADIUS Framed-Route attribute is not
required and is silently ignored (if returned to BSA/BSR node).
"10.1.0.1"

Auth-Type := Local, User-Password == ALU


Alc-Subsc-ID-Str = "arp-host-routed-%{User-name}",
Alc-Subsc-Prof-Str = "sub-profile-1",
Alc-SLA-Prof-Str = "sla-profile-1"

"10.2.0.1"

Auth-Type := Local, User-Password == ALU


Alc-Subsc-ID-Str = "arp-host-bridged-%{User-name}",
Alc-Subsc-Prof-Str = "sub-profile-1",
Alc-SLA-Prof-Str = "sla-profile-1"

Setup and Debugging of ARP Host


Identical methodologies, for bridged or Routed CO, are used to debug/setup and troubleshoot ARP
hosts. Routed CO is used as an example through the rest of this section on ARP hosts.
There are two modes of ARP host debugging: all and dropped-only. The dropped-only mode
shows all cases where the creation of the ARP host will be unsuccessful.
By default all ARP hosts enabled under a service will be monitored. More specific filtering on a
particular IP, MAC or SAP is optional.
All main traps are by default cyclic logged in log-id 99 and can be viewed anytime.
debug service id 1 arp-host mode all

ARP host mandate RADIUS authentication and a separate debug option is available for RADIUS
interaction.
debug radius detail

CPE-3 with static configured IP1 10.1.0.1 sends an ARP to the BSR-1 gateway.
2009/11/27 11:48:23.36 CET MINOR: DEBUG #2001 Base RADIUS
"RADIUS: Access-Request
user 10.1.0.1 policy authentication-1"
13 2009/11/27 11:48:23.35 CET MINOR: DEBUG #2001 Base RADIUS
"RADIUS: Transmit
Access-Request(1) 172.16.1.1:1812 id 10 len 79
USER NAME [1] 8 10.1.0.1
# Always IP-address
PASSWORD [2] 16 2/kDsiOVlrs2FQHK4PR47E
NAS IP ADDRESS [4] 4 192.0.2.2

Page 116

Advanced Configuration Guide

ARP Hosts

VSA [26] 19 Alcatel(6527)


CHADDR [27] 17 00:00:0a:01:00:01

# Always included

2009/11/27 11:48:23.48 CET MINOR: DEBUG #2001 Base RADIUS


"RADIUS: Receive
Access-Accept(2) id 10 len 87 from 172.16.1.1:1812
VSA [26] 19 Alcatel(6527)
SUBSC ID STR [11] 17 arp-host-routed-10.1.0.1
VSA [26] 15 Alcatel(6527)
SUBSC PROF STR [12] 13 sub-profile-1
VSA [26] 15 Alcatel(6527)
SLA PROF STR [13] 13 sla-profile-1
2009/11/27 11:48:23.48 CET MINOR: DEBUG #2001 vprn1 ARP Host
"ARP Host: Created ARP host
VPRN 1, SAP 1/1/1:1
IP: 10.1.0.1
MAC: 00:00:0a:01:00:01
2009/11/27 11:48:23.48 CET WARNING: SVCMGR #2500 Base Subscriber created
"Subscriber arp-host-routed-10.1.0.1 has been created in the system"

The user name in the RADIUS access-request contains the CPEs IP address independent from the
user-name-format defined in authentication policy. The MAC address of the ARP host is included
in the RADIUS access-request as VSA (Alc-Client-Hardware-Addr) independent on the includeradius-attribute mac-address parameter from the authentication policy.
The show service id 1 arp-host command displays all active ARP hosts on this service.
A:BSR-1# show service id 1 arp-host
===============================================================================
ARP host table, service 1
===============================================================================
IP Address
Mac Address
Sap Id
Remaining
MC
Time
Stdby
------------------------------------------------------------------------------10.1.0.1
00:00:0a:01:00:01 1/1/1:1
03h59m59s
------------------------------------------------------------------------------Number of ARP hosts: 1

More specific filters such as sap, ip-address, mac and others can be used to show dedicated ARP
hosts created on the BSR.
A:BSR-1# show service id 1 arp-host ip-address 10.1.0.1 detail
===============================================================================
ARP hosts for service 1
===============================================================================
Service ID
: 1
IP Address
: 10.1.0.1
MAC Address
: 00:00:0a:01:00:01
Subscriber-interface : sub-int-1
Group-interface
: group-int-1
SAP
: 1/1/1:1
Remaining Time
: 03h44m05s
Sub-Ident

: "arp-host-routed-10.1.0.1"

Advanced Configuration Guide

Page 117

Configuration

Sub-Profile-String
SLA-Profile-String
-snipRADIUS-User-Name

: "sub-profile-1"
: "sla-profile-1"
: "10.1.0.1"

Session Timeout (s) : 14400


Start Time
: 11/27/2009 11:48:23
Last Auth
: 11/27/2009 11:48:23
Last Refresh
: 11/27/2009 11:48:23
Persistence Key
: N/A
------------------------------------------------------------------------------Number of ARP hosts : 1

Dynamic created ARP hosts are added as /32 addresses in the routing table marked with protocol
type Sub Mgmt. Routes with this protocol type are not exported into vpn-ipv4 by the default vrftarget policy. A separate vrf-export policy is required to achieve this.
A:BSR-1# show router 1 route-table 10.1.0.0/24 longer
===============================================================================
Route Table (Service: 1)
===============================================================================
Dest Prefix
Type
Proto
Age
Pref
Next Hop[Interface Name]
Metric
------------------------------------------------------------------------------10.1.0.0/29
Local
Local
02d01h32m
0
sub-int-1
0
10.1.0.1/32
Remote Sub Mgmt 00h00m05s
0
[group-int-1]
0

Specific ARP host counters can be shown or cleared using the CLI command show/clear service
id 1 ARP host statistics.
A:BSR-1# show service id 1 arp-host statistics
===============================================================================
ARP host statistics
===============================================================================
Num Active Hosts
: 1
Received Triggers
: 1
Ignored Triggers
: 0
SHCV Checks Forced
: 0
Hosts Created
: 1
Hosts Updated
: 0
Hosts Deleted
: 0

The ARP hosts mandate Enhanced Subscriber managed (ESM) and therefore an anti-spoofing
configuration (IP-MAC or NH-MAC). The anti-spoofing table with active hosts can be viewed
with the command show service id 1 subscriber-hosts.
A:BSR-1# show service id 1 subscriber-hosts
===============================================================================
Subscriber Host table
===============================================================================
Sap
IP Address
MAC Address
PPPoE-SID Origin
Subscriber
-------------------------------------------------------------------------------

Page 118

Advanced Configuration Guide

ARP Hosts

1/1/1:1
10.1.0.1
00:00:0a:01:00:01 N/A
ARP-Host
arp-host-routed-10.1.0.1
------------------------------------------------------------------------------Number of subscriber hosts : 1

An ARP host can be manually deleted from the system using one of the two following methods:

clear service id 1 arp-host

RADIUS disconnect message

Using the first method, clear service id 1 arp-host and omitting any more specific parameter than
ARP host will result in the removal of all ARP hosts in this service. Extra filters like ip-address,
mac or sap-id are used to remove a specific ARP host.
A:BSR-1# *A:BSR-1# clear service id 1 arp-host ?
- arp-host
- arp-host { mac <ieee-address> | sap <sap-id> | ip-address
<ip-address[/mask]> }
- arp-host [port <port-id>] [inter-dest-id <intermediate-destination-id> |
no-inter-dest-id]
A:BSR-1# *A:BSR-1# clear service id

1 arp-host ip-address 10.1.0.1

Using the second method, RADIUS disconnect always result in the removal of a unique host
because nas-port-id and framed-ip-address are mandatory parameters in the RADIUS
disconnect message. This RADIUS disconnect message is used also for other host-types.
nas-port-id = 1/1/1:1
framed-ip-address=10.1.0.1

RADIUS disconnect messages are, for security reasons, rejected by default and are allowed iso
enabled by setting accept-authorization-change parameter in the authentication policy. The
debug radius detail command and show subscriber-mgmt authentication coa-statistics can be
used during troubleshooting.
7 2009/12/05 06:51:35.49 CET MINOR: DEBUG #2001 Base RADIUS
"RADIUS: Receive
Disconnect Request(40) id 140 len 35 from 172.16.1.1
NAS PORT ID [87] 7 1/1/1:1
FRAMED IP ADDRESS [8] 4 10.1.0.1
"
8 2009/12/05 06:51:35.49 CET MINOR: DEBUG #2001 vprn1 ARP Host
"ARP Host: Removed ARP host
VPRN 1, SAP 1/1/1:1
IP: 10.1.0.1
MAC: 00:00:0a:01:00:01
"
9 2009/12/05 06:51:35.49 CET MINOR: DEBUG #2001 Base RADIUS
"RADIUS: Transmit
Disconnect Ack(41) 172.16.1.1:32769 id 140 len 20

Advanced Configuration Guide

Page 119

Configuration

In both cases the ARP host with an IP address is removed from the system and all related state
(such as an anti-spoof filter and an IP ARP entry).

Page 120

Advanced Configuration Guide

ARP Hosts

ARP Host Session Timeout


The ARP host session timeout is a time value between 300 and 14400 seconds and becomes the
remaining time on the moment the first ARP request results in a successful host creation.
The host is removed from the system on the moment the remaining time becomes zero. The reset
of remaining time to session timeout is done by any subsequent arp-request or arp-reply for this
host.
The default assigned session timeout on ARP host creation time is 14400 seconds but this value
can be overruled by the optional RADIUS attribute session-Timeout and not by the node groupinterface arp-timeout parameter.
RADIUS values lower than 300 seconds will be silently adjusted to 300 seconds and values above
14400 seconds are topped silently to 14400 seconds.
"10.1.0.1"

Auth-Type := Local, User-Password == ALU


Alc-Subsc-ID-Str = "arp-host-routed-%{User-name}",
Alc-Subsc-Prof-Str = "sub-profile-1",
Alc-SLA-Prof-Str = "sla-profile-1",
Session-Timeout = 900
# value in seconds

A:BSR-1# show service id 1 arp-host


===============================================================================
ARP host table, service 1
===============================================================================
IP Address
Mac Address
Sap Id
Remaining
MC
Time
Stdby
------------------------------------------------------------------------------10.1.0.1
00:00:0a:01:00:01 1/1/1:1
0h14m59s
------------------------------------------------------------------------------Number of ARP hosts: 1
A:BSR-1# show service id 1 arp-host detail
===============================================================================
ARP hosts for service 1
===============================================================================
Service ID
: 1
IP Address
: 10.1.0.1
MAC Address
: 00:00:0a:01:00:01
Subscriber-interface : sub-int-1
Group-interface
: group-int-1
SAP
: 1/1/1:1
Remaining Time
: 0h14m59s
--snip-Session Timeout (s) : 900
Start Time
: 12/05/2009 07:36:15
Last Auth
: 12/05/2009 07:36:15
Last Refresh
: 12/05/2009 07:40:15
Persistence Key
: N/A
------------------------------------------------------------------------------Number of ARP hosts : 1

Advanced Configuration Guide

Page 121

Configuration

Typical time related parameters of the ARP host are:

Table 4: ARP Host Time-Related Parameters


Parameter

Comment

Session Timeout

Time value in seconds and retrieved by default or by the RADIUS


Accept message and pasted into the remaining time on moment of
ARP host creation or RADIUS re-authentication.

Remaining Time

The remaining time before the ARP host is deleted from the system
(updated each time an arp request/reply is seen for this host).

Start Time

Time and date when this host was created (first ARP received).

Last Auth

Time and date when this host was last RADIUS authenticated.

Last Refresh

Time and date when last ARP was received for this host.

ARP hosts do not have an expiry timer in the ARP table and have type managed.
A:BSR-1# show service id 1 arp 10.1.0.1
===============================================================================
ARP Table
===============================================================================
IP Address
MAC Address
Type
Expiry
Interface
SAP
------------------------------------------------------------------------------10.1.0.1
00:00:0a:01:00:01 Managed 00h00m00s group-int-1
1/1/1:1

An automatic mechanism is foreseen to handle the possible asynchrony between the arp session
timeout values installed on the BSR and the arp timeouts installed on the CPE. This mechanism is
mostly effective in case the timeout on the CPE > timeout BSR. In this latter case, the BSR session
would expire resulting in a host removal with a delete of the corresponding anti-spoof entry
because the CPE ARP request is coming too late. This CPE ARP request will however recreate the
session but requires the complete setup of the host RADIUS authentication included. This
mechanism causes unwanted service interruption for this ARP host.
A better approach, which is implemented in an automatic way, and illustrated in Figure 22 is an
ARP request triggered from the BSR towards the CPE prior to the session timeout. A CPE ARP
reply will then reset the remaining lifetime of the ARP host to the session timeout. If the ARP
reply is received outside the min-auth-interval window and the parameter re-authentication from
the authentication policy is set, than RADIUS re-authentication is executed. This re-authentication
mechanism is described further in the throttling toward the RADIUS section.

Page 122

Advanced Configuration Guide

ARP Hosts

RADIUS
Server

IPx/MACx

GW

CPE-1

VPRN
PE-1
BSR-1

ARP-Request
ESM
Access-Request

t0

Access-Accept
ESM
ARP Reply
ARP-Timeout 4 hrs
Value Decided by CPE

ESM-Strings
Session-Timeout 18000
Radius Access-Request is
Send if t1-t0 > min-authinterval and auth-plcy
re-authentication Set

Create Host and Assign


Session-Timeout=2hrs

ARP Request

Keep Alive is Done at 2/3 of the


Lifetime, With a Variation of
-10% to +10% in Order to
Create Some Jitter

ARP-Reply
Reset Remaining Lifetime
ARP-Host to Session-Timeout

t1

Access-Request
OSSG376

Figure 22: ARP Host Session Timeout Example

This mechanism, also known as automatic Subscriber Host Connectivity Verification (SHCV),
will prevent that the host will be deleted and re-created, resulting in undesired service
interruptions, in case asynchronous CPE-BSR arp session values would be used.
The debug service id 1 host-connectivity-verify command shows the sequence of events and can
be used during troubleshooting. Debugging and ARP host counters show below the automatic
SHCV mechanism with an active CPE.
3 2009/11/28 20:14:08.23 CET MINOR: DEBUG #2001 vprn1 SHCV
"SHCV: Forced Check Scheduled
VPRN 1, SAP 1/1/1:1
ARP host 10.1.0.1 00:00:0a:01:00:01"
4 2009/11/28 20:14:08.23 CET MINOR: DEBUG #2001 vprn1 SHCV
"SHCV: Periodic Check
VPRN 1, SAP 1/1/1:1

Advanced Configuration Guide

Page 123

Configuration

ARP host 10.1.0.1 00:00:0a:01:00:01"


5 2009/11/28 20:14:08.23 CET MINOR: DEBUG #2001 vprn1 SHCV
"SHCV: Received Reply
VPRN 1, SAP 1/1/1:1
ARP host 10.1.0.1 00:00:0a:01:00:01"
6 2009/11/28 20:14:08.23 CET MINOR: DEBUG #2001 vprn1 ARP Host
"ARP Host: Updated ARP host
VPRN 1, SAP 1/1/1:1
IP: 10.1.0.1
MAC: 00:00:0a:01:00:01

A:BSR-1# show service id 1 arp-host statistics


===============================================================================
ARP host statistics
===============================================================================
Num Active Hosts
: 1
Received Triggers
: 2
# arp reply received from host(2)
Ignored Triggers
: 0
SHCV Checks Forced
: 1
# arp request send to arp-host(1)
Hosts Created
: 1
Hosts Updated
: 1
# session-timeout updated (3)
Hosts Deleted
: 0

CPEs that are not active and therefore do not respond on arp-requests as part of the automatic
SHCV check will be rechecked three times with 10 second intervals.
The number of retries and the interval cannot be changed. A trap is generated but the ARP host is
not removed and will remain until the session-timeout expires or until the host will revive. This
mechanism is displayed in Figure 23.

Page 124

Advanced Configuration Guide

ARP Hosts

RADIUS
Server

IPx/MACx

GW

CPE-1

VPRN
PE-1

ARP-Request

BSR-1
ESM
Access-Request
Access-Accept
ESM

ARP-Timeout 4 hrs
Value Decided by CPE

ARP Reply

ESM-Strings
Session-Timeout 18000
Create Host and Assign
Session-Timeout=2hrs

ARP Request
10 secs

ARP Request

10 secs

ARP Request
Session Timeout

Keep Alive is Done at 2/3 of the


Lifetime, With a Variation of
-10% to +10% in Order to
Create Some Jitter

Dont Delete Host

Send Trap
Delete Host
OSSG377

Figure 23: Trap Generation Example

8 2009/11/28 20:29:28.34 CET MINOR: DEBUG #2001 vprn1 SHCV


"SHCV: Forced Check Scheduled
VPRN 1, SAP 1/1/1:1
ARP host 10.1.0.1 00:00:0a:01:00:01"
29 2009/11/28 20:29:28.34 CET MINOR: DEBUG #2001 vprn1 SHCV
"SHCV: Periodic Check
VPRN 1, SAP 1/1/1:1
ARP host 10.1.0.1 00:00:0a:01:00:01"
30 2009/11/28 20:29:38.30 CET MINOR: DEBUG #2001 vprn1 SHCV
"SHCV: Periodic Check
VPRN 1, SAP 1/1/1:1
ARP host 10.1.0.1 00:00:0a:01:00:01"
31 2009/11/28 20:29:48.30 CET MINOR: DEBUG #2001 vprn1 SHCV
"SHCV: Periodic Check
VPRN 1, SAP 1/1/1:1

Advanced Configuration Guide

Page 125

Configuration

ARP host 10.1.0.1 00:00:0a:01:00:01"


32 2009/11/28 20:29:58.30 CET WARNING: SVCMGR #2206 vprn1 Host connectivity lost
"host connectivity lost on 1/1/1:1 in service 1 for inetAddr = 10.1.0.1, chAddr=
00:00:0a:01:00:01."
33 2009/11/28 20:29:58.30 CET MINOR: DEBUG #2001 vprn1 SHCV
"SHCV: Connectivity Lost
VPRN 1, SAP 1/1/1:1
ARP host 10.1.0.1 00:00:0a:01:00:01"configure

Page 126

Advanced Configuration Guide

ARP Hosts

Throttling Toward RADIUS


A new arp-request from the ARP host will trigger RADIUS re-authentication only when the minauth-interval is expired. The minimum RADIUS authentication interval between two consecutive
authentication attempts for the same ARP host is by default 15 minutes but can range between 1
and 6000 minutes.
configure
service
vprn 1 customer 1 create
--snip-arp-host
min-auth-interval 60
no shutdown
exit
exit

# value in minutes

RADIUS
Server

IPx/MACx

GW

CPE-1

VPRN
PE-1

ARP-Request

BSR-1
ESM
Access-Request

t0

Access-Accept
ESM-Strings
ESM
ARP Reply

ARP Request
ARP Request
ARP Request
ARP Request

Update Host
Update Host
Update Host
Update Host

Only if Re-Authentication in
Authentication-Policy Enabled

t1

Radius Access-Request is
Send if t1- t0 > min-authinterval and auth-plcy
re-authentication Set

t1
t1
t1

Access-Request
OSSG378

Figure 24: Throttling Toward RADIUS Example

Advanced Configuration Guide

Page 127

Configuration

A:BSR-1# show service id 1 arp-host detail


===============================================================================
ARP hosts for service 1
===============================================================================
Service ID
: 1
IP Address
: 10.1.0.1
MAC Address
: 00:00:0a:01:00:01
--snip-Session Timeout
Start Time
Last Auth
Last Refresh

Page 128

:
:
:
:

14400
11/27/2009 14:05:07
11/27/2009 14:05:07
11/27/2009 14:40:31

# Timestamp ?arp-host created (first arp)


# Timestamp ?arp-host authenticated (RADIUS)
# Timestamp ?new arp seen from arp-host

Advanced Configuration Guide

ARP Hosts

ARP Host Mobility


In order for ARP host mobility to function, host-connectivity-verification must not be enabled.
This is different compared to DHCP host mobility.
The implementation for routed CO is displayed in Figure 25 and works the same for bridged CO.
The mac-pinning command in routed CO context has no influence on this behavior.

RADIUS
Server
IPx/MACx
CPE-2
SAP-2
IPx/MACx
CPE-1

SAP-1

VPRN
PE-1
BSR-1
Arp-Host Active

ARP Request

New Arp Dropped

ARP Request
10 secs

ARP Request

10 secs

ARP Request

+
Mobility Check Activated
Host-Connectivity-Verify
Param Not Required
Arp-Host-1 Deleted

ARP Request
2

Procedure for New Arp-Host

OSSG379

Figure 25: ARP Host Mobility Example

Advanced Configuration Guide

Page 129

Configuration

ARP Host Persistency


ARP hosts can be made persistent across reboots and do not differ with other host types like
DHCP hosts.
configure system
persistence
subscriber-mgmt
location cf2:
exit
exit

The persistence key and the index into the persistency file are linked to the arp-host on host
creation time.
A:BSR-1# show service id 1 arp-host detail
===============================================================================
ARP hosts for service 1
===============================================================================
Service ID
: 1
IP Address
: 10.1.0.1
MAC Address
: 00:00:0a:01:00:01
--snip-Persistence Key
: 0x00000004

The content of the stored record is viewed with the tools dump persistency command using the
persistency key as a record number.
A:BSR-1# tools dump persistence submgt record 0x00000004
----------------------------------Persistency File Record
----------------------------------Filename
: cf2:\submgmt.005
Key
: 00000004
Last Update : 2009/11/27 13:05:07 (UTC)
Action
: ADD
Data :
Host Type
: ARP host
Service ID
: 1
SAP ID
: 1/1/1:1
IP
: 10.1.0.1
NH MAC
: 00:00:0a:01:00:01
Created
: 2009/11/27 13:05:07 (UTC)
Session Timeout: 14400 (seconds)
Sub-ID
: arp-host-routed-10.1.0.1
Sub-prof-ID
: sub-profile-1
SLA-prof-ID
: sla-profile-1
App-prof-ID
: NULL
ANCP-Str
: NULL
Int-dest-ID
: NULL
Cat-map-str
: NULL
Sub-Id is def : NO
MSap SvcId
: 0
MSap PolicyId : 0
MSap IfIndex
: 0
Managed routes : None

Page 130

Advanced Configuration Guide

ARP Hosts

BgpPrngPlcyAttr: None
Class Attr
: 1 bytes
RADIUS Username: 10.1.0.1

Advanced Configuration Guide

Page 131

Configuration

Session Limitation Options


The maximum number of allowed arp-hosts in a bridged CO model can be configured by the per
SAP parameter host-limit in the range of 1 to 32767.
configure
service
vpls 2
--snip
sap 1/1/3:1
arp-host
host-limit 1
no shutdown
exit
exit
exit

# default value 1

The maximum number of allowed arp-hosts in a routed CO model can be configured by the per
group interface parameter host-limit in the range of 1 to 32767 and/or by the sap-host-limit
parameter.
configure
service
vprn 1
--snip-arp-host
host-limit 1
sap-host-limit 1
no shutdown
exit
exit

# default value
# default value

Warning:

Specific ESM-related host limit mechanisms such as sla-profile host-limit and sub-sla-mgmt
multi-sub-sap apply also for ARP hosts but are not further elaborated in this section.

Page 132

Advanced Configuration Guide

ARP Hosts

Debugging arp-host mode dropped-only indicates the dropped reason and a logging trap is
included in the standard log 99.
2009/11/27 20:45:53.80 CET MINOR: DEBUG #2001 vprn1 ARP Host
"ARP Host: Dropped trigger
VPRN 1, SAP 1/1/1:1
Problem: Interface limit (1) of ARP hosts reached
IP: 10.1.0.2
MAC: 00:00:0a:01:00:02

2009/11/27 20:45:53.81 CET WARNING: SVCMGR #2520 vprn1 ARP Host Population Error
"ARP host table population error on SAP 1/1/1:1 in service 1 - Interface limit (
1) of ARP hosts reached"

Increasing the sap-host-limit to 100 and the host-limit to 2000 results in the following summary:
A:BSR-1# show service id 1 arp-host summary
===================================================================
ARP host Summary, service 1
===================================================================
Interface Name
Used
Provided Admin State
Sap
------------------------------------------------------------------group-int-1
2
2000
inService
1/1/1:1
2
100
------------------------------------------------------------------Interfaces: 1

Advanced Configuration Guide

Page 133

Conclusion

Conclusion
This note provides configuration and troubleshooting commands for dynamic ARP hosts. ARP
hosts can be instantiated in a Layer 2 bridged CO (VPLS) environment as well as in a Layer 3
Routed CO (IES/VPRN subscriber interface) context.

Page 134

Advanced Configuration Guide

Associating Communities with Static


and Aggregate Routes

In This Chapter
This section provides information about associating communities with static and aggregate routes
configurations.
Topics in this section include:

Applicability on page 136

Overview on page 138

Configuration on page 140

Conclusion on page 162

Advanced Configuration Guide

Page 135

Applicability

Applicability
This example is applicable to all the 7750 SR, 7450 ESS in mixed-mode and 7950 XRS series and
was tested on release 11.0R3. There are no pre-requisites for this configuration.

Page 136

Advanced Configuration Guide

Associating Communities with Static and Aggregate

Introduction
Border Gateway Protocol (BGP) Communities are optional, transitive attributes attached to BGP
route prefixes to carry additional information about that route prefix. A number of route prefixes
can have the same community attached such that it can be matched by a route policy. As a result,
the presence of a community value can be used to influence and control route policy.
A BGP community is a 32-bit value that is written as two separate 16 bit numbers separated by a
colon. The first number usually represents the Autonomous System (AS) number that defines or
originates the community whilst the second is set by the network administrator.
Knowledge of RFC 4271 (BGP-4) and RFC 1997 (BGP Communities Attribute) is assumed
throughout this document, as well as knowledge of Multi-Protocol BGP (MP-BGP) and RFC 4364
(BGP/MPLS IP VPNs).

Advanced Configuration Guide

Page 137

Overview

Overview

PE-2

PE-1

CE-1
192.0.2.21

192.168.1.1/30
192.168.7.1/30

192.0.2.2

192.168.3.1/30

192.168.1.2/30

192.0.2.1
192.0.2.22

CE-2

192.168.2.1/30

192.168.4.1/30

192.168.7.2/30
192.0.2.20

AS 64496

RR-1
192.168.3.2/30

192.0.2.3

PE-3

192.168.4.2/30
192.168.5.1/30
192.168.5.2/30

192.168.2.2/30

192.0.2.4

172.16.0.2/30
172.16.0.1/30

PE-4

192.0.2.11

AS 64497

CE-3
al_0290

Figure 26: Network Topology

The network topology is displayed in Figure 26. The setup uses 7750/7450/7710 Service Router
(SR) nodes. PE-1 to PE-4 and the Route Reflector (RR-1) are located in the same Autonomous
System (AS); AS6696. CE-3 is in a separate AS 64497 and peers using eBGP with its directly
connected neighbor, PE-4.
The objectives are:

To configure static-routes in a VPRN in PE-1 with various community values including


well-known communities export them to other PEs within the same AS, and then via
eBGP to CE-3. During this process, the community values for each route will be
examined to ensure that the transitive nature of the attribute is maintained.

To associate a community with an aggregate route that represents a larger number of


composite prefixes. The aggregate will be advertised in place of the composite prefixes.

The following configuration tasks should be completed as a pre-requisite:

Page 138

Full mesh ISIS or OSPF between each of the PE routers and route reflector.

iBGP between the RR and all PEs.

eBGP between PE-4 and CE-3.

Link-layer LDP between each PE.

Advanced Configuration Guide

Associating Communities with Static and Aggregate

Associating Communities with Static and Aggregate Routes


It is possible to add a single community value to a static and aggregate route without using a router
policy.
The community value can be in the 4-byte format comprising of a 2-byte AS value, followed by a
2 byte decimal value, separated by a colon. It can also be the name of a well-know standard
community; no-export, no-advertise, no-export-subconfed.
Any community added can be matched using a route policy.
The purpose of this example is to provision static and aggregate IPv4 route prefixes and associate
a community with each route. These routes are then redistributed into the BGP protocol and
advertised to other BGP speakers.
This is shown for IPv4 routes within a VPRN. Well-known, standard communities will also be
configured to show that the correct behavior is observed.

Advanced Configuration Guide

Page 139

Configuration

Configuration
The first step is to configure an iBGP session between each of the PEs and the Route Reflector
(RR). The address family negotiated between peers is vpn-ipv4.
The configuration for PE-1 is:
configure router bgp
group internal
family vpn-ipv4
type internal
neighbor 192.0.2.20
exit
exit
exit all

The configuration for the other PEs is very similar. The IP addresses can be derived from
Figure 26.
The configuration for the RR is:
configure router bgp
cluster 0.0.0.1
group rr_clients
type internal
family vpn-ipv4
neighbor 192.0.2.1
exit
neighbor 192.0.2.2
exit
neighbor 192.0.2.3
exit
neighbor 192.0.2.4
exit
exit
exit all

On RR-1, show that BGP sessions with each PE are established, and have correctly negotiated the
vpn-ipv4 address family capability.
*B:RR-1# show router bgp summary
===============================================================================
BGP Router ID:192.0.2.20
AS:64496
Local AS:64496
===============================================================================
BGP Admin State
: Up
BGP Oper State
: Up
Total Peer Groups
: 1
Total Peers
: 4
Total BGP Paths
: 10
Total Path Memory
: 1840
Total IPv4 Remote Rts
: 0
Total IPv4 Rem. Active Rts : 0
Total McIPv4 Remote Rts : 0
Total McIPv4 Rem. Active Rts: 0
Total IPv6 Remote Rts
: 0
Total IPv6 Rem. Active Rts : 0
Total IPv4 Backup Rts
: 0
Total IPv6 Backup Rts
: 0

Page 140

Advanced Configuration Guide

Associating Communities with Static and Aggregate

Total Supressed Rts


Total Decay Rts

: 0
: 0

Total Hist. Rts

: 0

Total
Total
Total
Total
Total

:
:
:
:
:

Total VPN Peers

: 0

VPN Peer Groups


VPN Local Rts
VPN-IPv4 Rem. Rts
VPN-IPv6 Rem. Rts
VPN-IPv4 Bkup Rts

Total VPN Supp. Rts


Total VPN Decay Rts

0
0
0
0
0

: 0
: 0

Total VPN-IPv4 Rem. Act. Rts: 0


Total VPN-IPv6 Rem. Act. Rts: 0
Total VPN-IPv6 Bkup Rts
: 0
Total VPN Hist. Rts

: 0

Total L2-VPN Rem. Rts


: 0
Total L2VPN Rem. Act. Rts
: 0
Total MVPN-IPv4 Rem Rts : 0
Total MVPN-IPv4 Rem Act Rts : 0
Total MDT-SAFI Rem Rts : 0
Total MDT-SAFI Rem Act Rts : 0
Total MSPW Rem Rts
: 0
Total MSPW Rem Act Rts
: 0
Total RouteTgt Rem Rts : 0
Total RouteTgt Rem Act Rts : 0
Total McVpnIPv4 Rem Rts : 0
Total McVpnIPv4 Rem Act Rts : 0
Total MVPN-IPv6 Rem Rts : 0
Total MVPN-IPv6 Rem Act Rts : 0
Total FlowIpv4 Rem Rts : 0
Total FlowIpv4 Rem Act Rts : 0
Total FlowIpv6 Rem Rts : 0
Total FlowIpv6 Rem Act Rts : 0
===============================================================================
BGP Summary
===============================================================================
Neighbor
AS PktRcvd InQ Up/Down
State|Rcv/Act/Sent (Addr Family)
PktSent OutQ
------------------------------------------------------------------------------192.0.2.1
64496
14301
0 00h00m04s 0/0/0 (VpnIPv4)
43
0
192.0.2.2
64496
14290
0 00h00m04s 0/0/0 (VpnIPv4)
31
0
192.0.2.3
64496
14292
0 00h00m04s 0/0/0 (VpnIPv4)
34
0
192.0.2.4
64496
14290
0 00h00m04s 0/0/0 (VpnIPv4)
34
0
--------------------------------------------------------------------------------------

Advanced Configuration Guide

Page 141

Configuration

VPRN: IPv4

PE-1

10.100.100.0/24
10.100.101.0/24
10.100.102.0/24
10.100.103.0/24
10.100.104.0/24

CE-1
192.0.2.21

172.16.1.1/30

172.16.1.2/30

192.0.2.1
192.0.2.22

Un-numbered

10.100.105.0/24

CE-2

AS 64496
al_0291

Figure 27: CE Connections for Next-Hops

The VPRN configuration for PE-1 is shown below:


B:PE-1# configure service vprn 3
---------------------------------------------route-distinguisher 64496:3
auto-bind ldp
vrf-target target:64496:3
interface "int-PE-1-CE-1" create
address 172.16.1.1/30
sap 5/1/9:1.0 create
exit
exit
interface "int-PE-1-CE-2" create
unnumbered "loop1"
sap 5/1/10:1.0 create
exit
exit
interface "loop1" create
address 192.0.2.100/32
loopback
exit

LDP is used as the label-switching protocol for next-hop resolution.


The configuration is very similar for the other PEs.
PE-4 is configured with an interface towards CE-3 that supports eBGP, as follows:
A:PE-4# configure service vprn 3
A:PE-4>config>service>vprn# info
---------------------------------------------autonomous-system 64496
route-distinguisher 64496:3
auto-bind ldp
vrf-target target:64496:3

Page 142

Advanced Configuration Guide

Associating Communities with Static and Aggregate

interface "int-PE-4-CE-3" create


address 172.16.0.1/30
sap 2/1/1:3 create
exit
exit
bgp
export "PE-4-VPN-BGP"
group "VPRN-3-ext"
peer-as 64497
neighbor 172.16.0.2
exit
exit
no shutdown
exit
no shutdown

Advanced Configuration Guide

Page 143

Configuration

Static Routes with Communities


A static route has a number of next-hop options direct connected IP address, black-hole, indirect
IP address and interface-name.
Figure 27 shows a pair of Customer Edge (CE) routers connected to PE1. The link to CE-1 is a
numbered link. The link to CE-2 is an un-numbered link. The loopback interface address is used as
a reference address for the un-numbered Ethernet interface.
Beyond CE-1 are a number of /24 subnets. Static routes to these individual subnets are created on
PE-1 using a static route with a next-hop type of interface address or an indirect address. The
indirect address is learned using a static route.
Beyond CE-2 is a single /24 subnet. A static route to this subnet is created using an interface-name
next-hop type.
There are a number of well-known, standard communities:

no-export: the route is not advertised to any external peer. This should be observed in the
route tables of all BGP speakers in the originating AS, but not in those in neighboring
ASs.

no-advertise: the route is not advertised to any peer. This should not be observed in any
router as BGP-learned route.

The requirement for each subnet is

10.100.100.0/24 must not be advertised outside of the AS. This must be associated with
the standard, well-known community no-export. The community value is encoded as
65535:65281 (0xFFFFFF01), but the CLI requires the keyword no-export.

B:PE-1>config>service vprn 4
static-route 10.100.100.0/24 next-hop 172.16.1.2 community no-export

10.100.101.0/24 must be advertised with a community of 64496:101

B:PE-1>config> service vprn 4


static-route 10.100.101.0/24 next-hop 172.16.1.2 community 64496:101

10.100.102.0/24 must not be advertised to any BGP peer. This must be associated with the
standard, well-known community no-advertise. The community value is encoded as
65535:65282 (0xFFFFFF02), but the CLI requires the keyword no-advertise.

B:PE-1>config> service vprn 4


static-route 10.100.102.0/24 next-hop 172.16.1.2 community no-advertise

Page 144

10.100.103.0/24 must be advertised with a community of 64496:103 and a route tag of 10.

Advanced Configuration Guide

Associating Communities with Static and Aggregate

B:PE-1>config> service vprn 4


static-route 10.100.103.0/24 next-hop 172.16.1.2 tag 10 community 64496:103

10.100.104.0/24 must be advertised with a community of 64496:104. It is reachable via


192.0.2.21 which, in turn, is reachable via 172.16.1.2. This is using a static route which
does not need to be advertised hence it is associated with the no-advertise community.

B:PE-1>config> service vprn 4


static-route 10.100.104.0/24 indirect 192.0.2.12 community 64496:104
static-route 192.0.2.12/32 next-hop 172.16.1.2 community no-advertise

10.100.105.0/24 must be advertised with a community of 64496:105. It is reachable via


the un-numbered interface to CE-2.

B:PE-1>config> service vprn 4


static-route 10.100.105.0/24 next-hop "int-PE-1-CE-2" community 64496:105

On PE-1 configure static routes that match the static routes from Figure 27, and the conditions
from above.
Note that the default behavior of a VPRN is to export all static and connected routes into a BGP
labelled route with the appropriate route-target extended community configured in the vrf-target
statement. A single community string can be added using the static-route community commands
shown above. If multiple communities are required, then a VRF-export policy should be used.
This is outside the scope of this note.
Examine the BGP table of PE-1 to establish that routes have been exported correctly in VPN-IPv4
towards RR-1.
*B:PE-1>config>service>vprn# show router bgp neighbor 192.0.2.20 advertised-routes vpnipv4
===============================================================================
BGP Router ID:192.0.2.1
AS:64496
Local AS:64496
===============================================================================
Legend Status codes : u - used, s - suppressed, h - history, d - decayed, * - valid
Origin codes : i - IGP, e - EGP, ? - incomplete, > - best, b - backup
===============================================================================
BGP VPN-IPv4 Routes
===============================================================================
Flag Network
LocalPref
MED
Nexthop
Path-Id
Label
As-Path
------------------------------------------------------------------------------i
64496:3:10.100.100.0/24
100
None
192.0.2.1
None
262133
No As-Path
i
64496:3:10.100.101.0/24
100
None
192.0.2.1
None
262133
No As-Path
i
64496:3:10.100.103.0/24
100
None
192.0.2.1
None
262133

Advanced Configuration Guide

Page 145

Configuration

No As-Path
64496:3:10.100.104.0/24
100
None
192.0.2.1
None
262133
No As-Path
i
64496:3:10.100.105.0/24
100
None
192.0.2.1
None
262133
No As-Path
i
64496:3:172.16.1.0/30
100
None
192.0.2.1
None
262133
No As-Path
i
64496:3:192.0.2.100/32
100
None
192.0.2.1
None
262133
No As-Path
------------------------------------------------------------------------------Routes : 7
===============================================================================
i

Note that there are only seven exported routes. The route prefixes associated with the noadvertise community are not present, as expected.
Examining the BGP table of PE-4 shows the presence of the expected routes, with the correct
community values.
The prefix 10.100.100.0/24 is a member of community no-export. This is correctly advertised to
PE-4.
A:PE-4# show router bgp routes vpn-ipv4 10.100.100.0/24 detail
===============================================================================
BGP Router ID:192.0.2.4
AS:64496
Local AS:64496
===============================================================================
Legend Status codes : u - used, s - suppressed, h - history, d - decayed, * - valid
Origin codes : i - IGP, e - EGP, ? - incomplete, > - best, b - backup
===============================================================================
BGP VPN-IPv4 Routes
===============================================================================
------------------------------------------------------------------------------Original Attributes
Network
Nexthop
Route Dist.
Path Id
From
Res. Nexthop
Local Pref.
Aggregator AS
Atomic Aggr.
AIGP Metric
Connector
Community
Cluster
Originator Id
Fwd Class
Flags
Route Source

Page 146

:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:

10.100.100.0/24
192.0.2.1
64496:3
VPN Label
None
192.0.2.20
n/a
100
Interface Name
None
Aggregator
Not Atomic
MED
None
None
no-export target:64496:3
0.0.0.1
192.0.2.1
Peer Router Id
None
Priority
Used Valid Best IGP
Internal

: 262133

: int-PE-4-PE-1
: None
: None

: 192.0.2.20
: None

Advanced Configuration Guide

Associating Communities with Static and Aggregate

AS-Path
VPRN Imported

: No As-Path
: 3

The prefix 10.100.101.0/24 is a member of community 64496:101. This is correctly advertised to


PE-4.
A:PE-4# show router bgp routes vpn-ipv4 10.100.101.0/24 detail
===============================================================================
BGP Router ID:192.0.2.4
AS:64496
Local AS:64496
===============================================================================
Legend Status codes : u - used, s - suppressed, h - history, d - decayed, * - valid
Origin codes : i - IGP, e - EGP, ? - incomplete, > - best, b - backup
===============================================================================
BGP VPN-IPv4 Routes
===============================================================================
------------------------------------------------------------------------------Original Attributes
Network
Nexthop
Route Dist.
Path Id
From
Res. Nexthop
Local Pref.
Aggregator AS
Atomic Aggr.
AIGP Metric
Connector
Community
Cluster
Originator Id
Fwd Class
Flags
Route Source
AS-Path
VPRN Imported

:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:

10.100.101.0/24
192.0.2.1
64496:3
VPN Label
None
192.0.2.20
n/a
100
Interface Name
None
Aggregator
Not Atomic
MED
None
None
64496:101 target:64496:3
0.0.0.1
192.0.2.1
Peer Router Id
None
Priority
Used Valid Best IGP
Internal
No As-Path
3

: 262133

: int-PE-4-PE-1
: None
: None

: 192.0.2.20
: None

The prefix 10.100.103.0/24 is a member of community 64496:103. This is correctly advertised to


PE-4.
A:PE-4# show router bgp routes vpn-ipv4 10.100.103.0/24 detail
===============================================================================
BGP Router ID:192.0.2.4
AS:64496
Local AS:64496
===============================================================================
Legend Status codes : u - used, s - suppressed, h - history, d - decayed, * - valid
Origin codes : i - IGP, e - EGP, ? - incomplete, > - best, b - backup
===============================================================================
BGP VPN-IPv4 Routes
===============================================================================
------------------------------------------------------------------------------Original Attributes
Network

: 10.100.103.0/24

Advanced Configuration Guide

Page 147

Configuration

Nexthop
Route Dist.
Path Id
From
Res. Nexthop
Local Pref.
Aggregator AS
Atomic Aggr.
AIGP Metric
Connector
Community
Cluster
Originator Id
Fwd Class
Flags
Route Source
AS-Path
VPRN Imported

:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:

192.0.2.1
64496:3
VPN Label
None
192.0.2.20
n/a
100
Interface Name
None
Aggregator
Not Atomic
MED
None
None
64496:103 target:64496:3
0.0.0.1
192.0.2.1
Peer Router Id
None
Priority
Used Valid Best IGP
Internal
No As-Path
3

: 262133

: int-PE-4-PE-1
: None
: None

: 192.0.2.20
: None

The prefix 10.100.104.0/24 is a member of community 64496:104. This is correctly advertised to


PE-4.
A:PE-4# show router bgp routes vpn-ipv4 10.100.104.0/24 detail
===============================================================================
BGP Router ID:192.0.2.4
AS:64496
Local AS:64496
===============================================================================
Legend Status codes : u - used, s - suppressed, h - history, d - decayed, * - valid
Origin codes : i - IGP, e - EGP, ? - incomplete, > - best, b - backup
===============================================================================
BGP VPN-IPv4 Routes
===============================================================================
------------------------------------------------------------------------------Original Attributes
Network
Nexthop
Route Dist.
Path Id
From
Res. Nexthop
Local Pref.
Aggregator AS
Atomic Aggr.
AIGP Metric
Connector
Community
Cluster
Originator Id
Fwd Class
Flags
Route Source
AS-Path
VPRN Imported

Page 148

:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:

10.100.104.0/24
192.0.2.1
64496:3
VPN Label
None
192.0.2.20
n/a
100
Interface Name
None
Aggregator
Not Atomic
MED
None
None
64496:104 target:64496:3
0.0.0.1
192.0.2.1
Peer Router Id
None
Priority
Used Valid Best IGP
Internal
No As-Path
3

: 262133

: int-PE-4-PE-1
: None
: None

: 192.0.2.20
: None

Advanced Configuration Guide

Associating Communities with Static and Aggregate

The prefix 10.100.105.0/24 is a member of community 64496:105. This is correctly advertised to


PE-4.
A:PE-4# show router bgp routes vpn-ipv4 10.100.105.0/24 detail
===============================================================================
BGP Router ID:192.0.2.4
AS:64496
Local AS:64496
===============================================================================
Legend Status codes : u - used, s - suppressed, h - history, d - decayed, * - valid
Origin codes : i - IGP, e - EGP, ? - incomplete, > - best, b - backup
===============================================================================
BGP VPN-IPv4 Routes
===============================================================================
------------------------------------------------------------------------------Original Attributes
Network
Nexthop
Route Dist.
Path Id
From
Res. Nexthop
Local Pref.
Aggregator AS
Atomic Aggr.
AIGP Metric
Connector
Community
Cluster
Originator Id
Fwd Class
Flags
Route Source
AS-Path
VPRN Imported

:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:

10.100.105.0/24
192.0.2.1
64496:3
VPN Label
None
192.0.2.20
n/a
100
Interface Name
None
Aggregator
Not Atomic
MED
None
None
64496:105 target:64496:3
0.0.0.1
192.0.2.1
Peer Router Id
None
Priority
Used Valid Best IGP
Internal
No As-Path
3

: 262133

: int-PE-4-PE-1
: None
: None

: 192.0.2.20
: None

Examine the route table of PE-4 looking specifically at the BGP-learned routes, the same seven
routes are present as valid routes.
A:PE-4# show router 3 route-table protocol bgp-vpn
===============================================================================
Route Table (Service: 3)
===============================================================================
Dest Prefix[Flags]
Type
Proto
Age
Pref
Next Hop[Interface Name]
Metric
------------------------------------------------------------------------------10.100.100.0/24
Remote BGP VPN
07d02h32m 170
192.0.2.1 (tunneled)
0
10.100.101.0/24
Remote BGP VPN
07d02h32m 170
192.0.2.1 (tunneled)
0
10.100.103.0/24
Remote BGP VPN
07d02h32m 170
192.0.2.1 (tunneled)
0
10.100.104.0/24
Remote BGP VPN
07d02h32m 170
192.0.2.1 (tunneled)
0
10.100.105.0/24
Remote BGP VPN
07d02h32m 170
192.0.2.1 (tunneled)
0
172.16.1.0/30
Remote BGP VPN
07d02h32m 170

Advanced Configuration Guide

Page 149

Configuration

192.0.2.1 (tunneled)
0
192.0.2.100/32
Remote BGP VPN
07d02h32m 170
192.0.2.1 (tunneled)
0
------------------------------------------------------------------------------No. of Routes: 7
Flags: L = LFA nexthop available
B = BGP backup route available
n = Number of times nexthop is repeated
===============================================================================

Examine the route table of CE-3 looking specifically at the BGP-learned routes, six routes are
present as valid routes, as expected.
*A:CE-3# show router route-table protocol bgp
===============================================================================
Route Table (Router: Base)
===============================================================================
Dest Prefix[Flags]
Type
Proto
Age
Pref
Next Hop[Interface Name]
Metric
------------------------------------------------------------------------------10.100.101.0/24
Remote BGP
07d01h54m
170
172.16.0.1
0
10.100.103.0/24
Remote BGP
07d01h54m
170
172.16.0.1
0
10.100.104.0/24
Remote BGP
07d01h54m
170
172.16.0.1
0
10.100.105.0/24
Remote BGP
07d01h54m
170
172.16.0.1
0
172.16.1.0/30
Remote BGP
07d01h54m
170
172.16.0.1
0
192.0.2.100/32
Remote BGP
07d01h54m
170
172.16.0.1
0
------------------------------------------------------------------------------No. of Routes: 6
Flags: L = LFA nexthop available
B = BGP backup route available
n = Number of times nexthop is repeated
===============================================================================

The prefix 10.100.100.0/24 is not received from PE-4 as it is a member of the no-export
community.
*A:CE-3# show router bgp routes community 64496:100
===============================================================================
BGP Router ID:192.0.2.11
AS:64497
Local AS:64497
===============================================================================
Legend Status codes : u - used, s - suppressed, h - history, d - decayed, * - valid
Origin codes : i - IGP, e - EGP, ? - incomplete, > - best, b - backup
===============================================================================
BGP IPv4 Routes
===============================================================================
Flag Network
LocalPref
MED
Nexthop
Path-Id
VPNLabel
As-Path
------------------------------------------------------------------------------No Matching Entries Found
===============================================================================

Page 150

Advanced Configuration Guide

Associating Communities with Static and Aggregate

Static route 10.100.101.0/24 is received with the correct community 64496:101.


A:CE-3# show router bgp routes community 64496:101
===============================================================================
BGP Router ID:192.0.2.11
AS:64497
Local AS:64497
===============================================================================
Legend Status codes : u - used, s - suppressed, h - history, d - decayed, * - valid
Origin codes : i - IGP, e - EGP, ? - incomplete, > - best, b - backup
===============================================================================
BGP IPv4 Routes
===============================================================================
Flag Network
LocalPref
MED
Nexthop
Path-Id
VPNLabel
As-Path
------------------------------------------------------------------------------u*>i 10.100.101.0/24
None
None
172.16.0.1
None
64496
------------------------------------------------------------------------------Routes : 1
===============================================================================

Static route 10.100.103.0/24 is received with the correct community 64496:103.


*A:CE-3# show router bgp routes community 64496:103
===============================================================================
BGP Router ID:192.0.2.11
AS:64497
Local AS:64497
===============================================================================
Legend Status codes : u - used, s - suppressed, h - history, d - decayed, * - valid
Origin codes : i - IGP, e - EGP, ? - incomplete, > - best, b - backup
===============================================================================
BGP IPv4 Routes
===============================================================================
Flag Network
LocalPref
MED
Nexthop
Path-Id
VPNLabel
As-Path
------------------------------------------------------------------------------u*>i 10.100.103.0/24
None
None
172.16.0.1
None
64496
------------------------------------------------------------------------------Routes : 1
===============================================================================

Static route 10.100.104.0/24 is received with the correct community 64496:104.


*A:CE-3# show router bgp routes community 64496:104
===============================================================================
BGP Router ID:192.0.2.11
AS:64497
Local AS:64497
===============================================================================

Advanced Configuration Guide

Page 151

Configuration

Legend Status codes : u - used, s - suppressed, h - history, d - decayed, * - valid


Origin codes : i - IGP, e - EGP, ? - incomplete, > - best, b - backup
===============================================================================
BGP IPv4 Routes
===============================================================================
Flag Network
LocalPref
MED
Nexthop
Path-Id
VPNLabel
As-Path
------------------------------------------------------------------------------u*>i 10.100.104.0/24
None
None
172.16.0.1
None
64496
------------------------------------------------------------------------------Routes : 1
===============================================================================

Static route 10.100.105.0/24 is received with the correct community 64496:105.


*A:CE-3# show router bgp routes community 64496:105
===============================================================================
BGP Router ID:192.0.2.11
AS:64497
Local AS:64497
===============================================================================
Legend Status codes : u - used, s - suppressed, h - history, d - decayed, * - valid
Origin codes : i - IGP, e - EGP, ? - incomplete, > - best, b - backup
===============================================================================
BGP IPv4 Routes
===============================================================================
Flag Network
LocalPref
MED
Nexthop
Path-Id
VPNLabel
As-Path
------------------------------------------------------------------------------u*>i 10.100.105.0/24
None
None
172.16.0.1
None
64496
------------------------------------------------------------------------------Routes : 1
===============================================================================

Page 152

Advanced Configuration Guide

Associating Communities with Static and Aggregate

Aggregate Routes with Communities


An aggregate route can be configured to represent a larger number of prefixes. For example, a set
of prefixes 10.101.0.0/24 to 10.101.8.0/24 can be represented as a single aggregate prefix of
10.101.0.0/21.
This is due to the fact that the third octet in the range 0 to 15 can be represented by the 8 bits
00000000 to 00000111. The first 5 bits of this octet are common, along with the previous 2 octets,
giving a prefix where the first 21 bits are common. Therefore the aggregate can be written as
10.101.0.0/21.
In order to illustrate the configuration of an aggregate, consider following.

PE-1

CE-1
192.0.2.21

172.16.1.1/30

172.16.1.2/30

192.0.2.1

10.101.0.0/24
10.101.1.0/24
10.101.2.0/24
10.101.3.0/24
10.101.4.0/24
10.101.5.0/24
10.101.6.0/24
10.101.7.0/24

10.102.0.0/24
10.102.1.0/24
10.102.2.0/24
10.102.3.0/24
10.102.4.0/24
10.102.5.0/24
10.102.6.0/24
10.102.7.0/24

AS 64498
AS 64496
al_0292

Figure 28: CE-1 Connectivity

Figure 28 shows a CE router (CE-1), in AS 64498, that advertises a series of contiguous prefixes
via BGP.

10.101.0.0/24 to 10.101.7.0/24

10.102.0.0/24 to 10.102.7.0/24

Instead of advertising all of these prefixes out of the VPRN towards an external CE, an aggregate
route can be configured that summarizes each set of 8 prefixes and a community can be directly
associated with each aggregate route.
The configuration for a VPRN on PE-1, including the external BGP configuration is as follows:
B:PE-1>config>service>vprn# info
---------------------------------------------autonomous-system 64496
route-distinguisher 64496:4
auto-bind mpls
vrf-target target:64496:4
interface "int-PE-1-CE-1" create

Advanced Configuration Guide

Page 153

Configuration

address 172.16.1.1/30
sap 5/1/9:2.0 create
exit
exit
bgp
group "external"
family ipv4
type external
peer-as 64498
neighbor 172.16.1.2
exit
exit
no shutdown
exit
no shutdown

The neighbor relationship shows:


B:PE-1# show router 4 bgp neighbor
===============================================================================
BGP Neighbor
===============================================================================
------------------------------------------------------------------------------Peer : 172.16.1.2
Group : external
------------------------------------------------------------------------------Peer AS
: 64498
Peer Port
: 59172
Peer Address
: 172.16.1.2
Local AS
: 64496
Local Port
: 179
Local Address
: 172.16.1.1
Peer Type
: External
State
: Established
Last State
: Established
Last Event
: recvKeepAlive
Last Error
: Cease (Connection Collision Resolution)
Local Family
: IPv4
Remote Family
: IPv4
Hold Time
: 90
Keep Alive
: 30
Min Hold Time
: 0
Active Hold Time
: 90
Active Keep Alive
: 30
Cluster Id
: None
Preference
: 170
Num of Update Flaps : 0
Recd. Paths
: 1
IPv4 Recd. Prefixes : 16
IPv4 Active Prefixes : 16
IPv4 Suppressed Pfxs : 0
VPN-IPv4 Suppr. Pfxs : 0
VPN-IPv4 Recd. Pfxs : 0
VPN-IPv4 Active Pfxs : 0
Mc IPv4 Recd. Pfxs. : 0
Mc IPv4 Active Pfxs. : 0
Mc IPv4 Suppr. Pfxs : 0
IPv6 Suppressed Pfxs : 0
IPv6 Recd. Prefixes : 0
IPv6 Active Prefixes : 0
VPN-IPv6 Recd. Pfxs : 0
VPN-IPv6 Active Pfxs : 0
VPN-IPv6 Suppr. Pfxs : 0
L2-VPN Suppr. Pfxs
: 0
L2-VPN Recd. Pfxs
: 0
L2-VPN Active Pfxs
: 0
MVPN-IPv4 Suppr. Pfxs: 0
MVPN-IPv4 Recd. Pfxs : 0
MVPN-IPv4 Active Pfxs: 0
MDT-SAFI Suppr. Pfxs : 0
MDT-SAFI Recd. Pfxs : 0
MDT-SAFI Active Pfxs : 0
Flow-IPv4 Suppr. Pfxs: 0
Flow-IPv4 Recd. Pfxs : 0
Flow-IPv4 Active Pfxs: 0
Rte-Tgt Suppr. Pfxs : 0
Rte-Tgt Recd. Pfxs
: 0
Rte-Tgt Active Pfxs : 0
Backup IPv4 Pfxs
: 0
Backup IPv6 Pfxs
: 0

Page 154

Advanced Configuration Guide

Associating Communities with Static and Aggregate

Mc Vpn Ipv4 Recd. Pf*:


Backup Vpn IPv4 Pfxs :
Input Queue
:
i/p Messages
:
i/p Octets
:
i/p Updates
:
MVPN-IPv6 Suppr. Pfxs:
MVPN-IPv6 Active Pfxs:
Flow-IPv6 Suppr. Pfxs:
Flow-IPv6 Active Pfxs:
TTL Security
:
Graceful Restart
:
Advertise Inactive
:
Advertise Label
:
Auth key chain
:
Disable Cap Nego
:
Flowspec Validate
:
Aigp Metric
:
Local Capability
:
Remote Capability
:
Local AddPath Capabi*:
Remote AddPath Capab*:
:
Import Policy
:
Export Policy
:

0
Mc Vpn Ipv4 Active P*:
0
Backup Vpn IPv6 Pfxs :
0
Output Queue
:
346
o/p Messages
:
6700
o/p Octets
:
2
o/p Updates
:
0
MVPN-IPv6 Recd. Pfxs :
0
0
Flow-IPv6 Recd. Pfxs :
0
Disabled
Min TTL Value
:
Disabled
Stale Routes Time
:
Disabled
Peer Tracking
:
None
n/a
Disabled
Bfd Enabled
:
Disabled
Default Route Tgt
:
Disabled
Split Horizon
:
RtRefresh MPBGP 4byte ASN
MPBGP
Disabled
Send - None
Receive - None
None Specified / Inherited
None Specified / Inherited

0
0
0
346
6688
1
0
0
n/a
n/a
Disabled

Disabled
Disabled
Disabled

------------------------------------------------------------------------------Neighbors : 1

The following output shows that 16 BGP routes are received by PE-1.
B:PE-1# show router 4 bgp routes
===============================================================================
BGP Router ID:192.0.2.1
AS:64496
Local AS:64496
===============================================================================
Legend Status codes : u - used, s - suppressed, h - history, d - decayed, * - valid
Origin codes : i - IGP, e - EGP, ? - incomplete, > - best, b - backup
===============================================================================
BGP IPv4 Routes
===============================================================================
Flag Network
LocalPref
MED
Nexthop
Path-Id
Label
As-Path
------------------------------------------------------------------------------u*>? 10.101.0.0/24
None
None
172.16.1.2
None
64498
u*>? 10.101.1.0/24
None
None
172.16.1.2
None
64498
u*>? 10.101.2.0/24
None
None
172.16.1.2
None
64498
u*>? 10.101.3.0/24
None
None
172.16.1.2
None
64498

Advanced Configuration Guide

Page 155

Configuration

u*>?

10.101.4.0/24
None
None
172.16.1.2
None
64498
u*>? 10.101.5.0/24
None
None
172.16.1.2
None
64498
u*>? 10.101.6.0/24
None
None
172.16.1.2
None
64498
u*>? 10.101.7.0/24
None
None
172.16.1.2
None
64498
u*>? 10.102.0.0/24
None
None
172.16.1.2
None
64498
u*>? 10.102.1.0/24
None
None
172.16.1.2
None
64498
u*>? 10.102.2.0/24
None
None
172.16.1.2
None
64498
u*>? 10.102.3.0/24
None
None
172.16.1.2
None
64498
u*>? 10.102.4.0/24
None
None
172.16.1.2
None
64498
u*>? 10.102.5.0/24
None
None
172.16.1.2
None
64498
u*>? 10.102.6.0/24
None
None
172.16.1.2
None
64498
u*>? 10.102.7.0/24
None
None
172.16.1.2
None
64498
------------------------------------------------------------------------------Routes : 16
===============================================================================

PE-4 also has a VPRN 4 instance configured, so that it will receive the imported BGP routes. The
configuration for PE-4 is:
A:PE-4>config>service>vprn# info
---------------------------------------------autonomous-system 64496
route-distinguisher 64496:4
auto-bind mpls
vrf-target target:64496:4
interface "int-PE-4-CE-3" create
address 172.16.0.5/30
sap 2/1/1:4 create
exit
exit
bgp
group "VPRN-4-ext"
peer-as 64497

Page 156

Advanced Configuration Guide

Associating Communities with Static and Aggregate

neighbor 172.16.0.6
exit
exit
no shutdown
exit
no shutdown

Figure 29 shows the connectivity between PE-4 and CE-3. PE-4 will only forward a summarizing
aggregate route towards CE-3.

PE-4

192.0.2.4

CE-3

172.16.0.5/30

AS 64496

172.16.0.6/30

192.0.2.11

AS 64497
al_0293

Figure 29: CE-3 Connectivity

PE-4 receives labelled BGP route prefixes from PE-1 via the route reflector and installs them in
the FIB for router instance 4:
*A:PE-4>config>service>vprn# show router 4 route-table
===============================================================================
Route Table (Service: 4)
===============================================================================
Dest Prefix[Flags]
Type
Proto
Age
Pref
Next Hop[Interface Name]
Metric
------------------------------------------------------------------------------10.101.0.0/24
Remote BGP VPN
05h12m03s 170
192.0.2.1 (tunneled)
0
10.101.1.0/24
Remote BGP VPN
05h12m03s 170
192.0.2.1 (tunneled)
0
10.101.2.0/24
Remote BGP VPN
05h12m03s 170
192.0.2.1 (tunneled)
0
10.101.3.0/24
Remote BGP VPN
05h12m03s 170
192.0.2.1 (tunneled)
0
10.101.4.0/24
Remote BGP VPN
05h12m03s 170
192.0.2.1 (tunneled)
0
10.101.5.0/24
Remote BGP VPN
05h12m03s 170
192.0.2.1 (tunneled)
0
10.101.6.0/24
Remote BGP VPN
05h12m03s 170
192.0.2.1 (tunneled)
0
10.101.7.0/24
Remote BGP VPN
05h12m03s 170
192.0.2.1 (tunneled)
0
10.102.0.0/24
Remote BGP VPN
05h12m03s 170
192.0.2.1 (tunneled)
0
10.102.1.0/24
Remote BGP VPN
05h12m03s 170

Advanced Configuration Guide

Page 157

Configuration

192.0.2.1 (tunneled)
0
10.102.2.0/24
Remote BGP VPN
05h12m03s 170
192.0.2.1 (tunneled)
0
10.102.3.0/24
Remote BGP VPN
05h12m03s 170
192.0.2.1 (tunneled)
0
10.102.4.0/24
Remote BGP VPN
05h12m03s 170
192.0.2.1 (tunneled)
0
10.102.5.0/24
Remote BGP VPN
05h12m03s 170
192.0.2.1 (tunneled)
0
10.102.6.0/24
Remote BGP VPN
05h12m03s 170
192.0.2.1 (tunneled)
0
10.102.7.0/24
Remote BGP VPN
05h12m03s 170
192.0.2.1 (tunneled)
0
172.16.0.4/30
Local
Local
05h12m27s 0
int-PE-4-CE-3
0
172.16.1.0/30
Remote BGP VPN
05h12m03s 170
192.0.2.1 (tunneled)
------------------------------------------------------------------------------No. of Routes: 18
Flags: L = LFA nexthop available
B = BGP backup route available
n = Number of times nexthop is repeated

Page 158

Advanced Configuration Guide

Associating Communities with Static and Aggregate

The CE-3 configuration for an interface towards PE-4 is as follows:


*A:CE-3>config>service>ies# info
interface "int-CE-3-PE-4-2" create
address 172.16.0.6/30
sap 3/2/1:4 create
exit
exit
no shutdown

The BGP configuration of CE-3:


*A:CE-3>config>router>bgp# info
---------------------------------------------group "ext"
peer-as 64496
neighbor 172.16.0.5
exit
exit

The BGP neighbor state for PE-4:


A:PE-4# show router 4 bgp neighbor 172.16.0.6
===============================================================================
BGP Neighbor
===============================================================================
------------------------------------------------------------------------------Peer : 172.16.0.6
Group : VPRN-4-ext
------------------------------------------------------------------------------Peer AS
: 64497
Peer Port
: 179
Peer Address
: 172.16.0.6
Local AS
: 64496
Local Port
: 50611
Local Address
: 172.16.0.5
Peer Type
: External
State
: Established
Last State
: Active
Last Event
: recvKeepAlive
Last Error
: Unrecognized Error
Local Family
: IPv4
Remote Family
: IPv4
Hold Time
: 90
Keep Alive
: 30
Min Hold Time
: 0
Active Hold Time
: 90

In order to advertise a summarizing aggregate route with an associated community string, an


aggregate route is required. In this case, the 10.101.x.0/24 group of prefixes will be associated
with community 64496:101. The 10.102.x.0/24 group of prefixes will be associated with the
standard community no-export, so that it will not be advertised to any external peer.
The configuration required is:
*A:PE-4>config>service>vprn#

Advanced Configuration Guide

Page 159

Configuration

aggregate 10.101.0.0/21 community 64496:101


aggregate 10.102.0.0/21 community no-export

An export policy is required to allow the advertising of the aggregate route. Note that no
community is applied using this policy.
*A:PE-4>config>router>policy-options# begin
policy-statement "PE-4-VPN-Agg"
entry 10
from
protocol aggregate
exit
action accept
exit
exit
exit
commit

This is applied as an export policy within the group context of the BGP configuration of the
VPRN.
*A:PE-4>config>service>vprn#
bgp
group "VPRN-4-ext"
export "PE-4-VPN-Agg"
exit
no shutdown
exit

The aggregate route 10.101.0.0/21 is received at CE-3 via BGP. The community that was
associated with this prefix is seen 64496:101. Note that the route is seen as an aggregate, with
PE-4 as the aggregating router (192.0.2.4). Note also that the Atomic Aggregate attribute is
present, meaning that PE-4 has not advertised any details of the AS Paths of the composite routes.
*A:CE-3# show router bgp routes 10.101.0.0/21 hunt
===============================================================================
BGP Router ID:192.0.2.11
AS:64497
Local AS:64497
===============================================================================
Legend Status codes : u - used, s - suppressed, h - history, d - decayed, * - valid
Origin codes : i - IGP, e - EGP, ? - incomplete, > - best, b - backup
===============================================================================
BGP IPv4 Routes
===============================================================================
------------------------------------------------------------------------------RIB In Entries
------------------------------------------------------------------------------Network
: 10.101.0.0/21
Nexthop
: 172.16.0.5
Path Id
: None
From
: 172.16.0.5
Res. Nexthop
: 172.16.0.5

Page 160

Advanced Configuration Guide

Associating Communities with Static and Aggregate

Local Pref.
Aggregator AS
Atomic Aggr.
Community
Cluster
Originator Id
Fwd Class
Flags
Route Source
AS-Path

:
:
:
:
:
:
:
:
:
:

None
Interface Name
64496
Aggregator
Atomic
MED
64496:101
No Cluster Members
None
Peer Router Id
None
Priority
Used Valid Best Incomplete
External
64496

: int-CE-3-PE-4-2
: 192.0.2.4
: None

: 192.0.2.4
: None

The aggregate route 10.102.0.0/21 is not received at CE-3, as PE-4 does not advertise it, due to the
fact that it is associated with the no-export community.
*A:CE-3# show router bgp routes 10.102.0.0/21 hunt
===============================================================================
BGP Router ID:192.0.2.11
AS:64497
Local AS:64497
===============================================================================
Legend Status codes : u - used, s - suppressed, h - history, d - decayed, * - valid
Origin codes : i - IGP, e - EGP, ? - incomplete, > - best, b - backup
===============================================================================
BGP IPv4 Routes
===============================================================================
No Matching Entries Found
===============================================================================

Advanced Configuration Guide

Page 161

Conclusion

Conclusion
Community strings can be added to static and aggregate routes. This example shows the
configuration of communities with both static and aggregate routes, together with the associated
show outputs which can be used to verify and troubleshoot them.

Page 162

Advanced Configuration Guide

BGP Anycast

In This Chapter
This section describes advanced BGP anycast configurations.
Topics in this section include:

Applicability on page 164

Summary on page 165

Overview on page 166

Configuration on page 171

Conclusion on page 205

Advanced Configuration Guide

Page 163

Applicability

Applicability
The configuration in this chapter is based on SR OS 9.0R1. The feature is supported on 7750 SRc4/c12, SR-7 and SR-12 in chassis mode d, and 7450 ESS-7 and ESS-12 in mixed-mode.

Page 164

Advanced Configuration Guide

BGP Anycast

Summary
Release 8.0.R4 and higher provide a resiliency mechanism to protect the data flow of Layer 2/
Layer 3 traffic in the event of a complete nodal failure of the PE or ABR routers. The intent is to
allow traffic to continue to flow during the convergence process and as a result reduce the amount
of traffic lost during this process. This is achieved by allowing two designated routers to back each
other up such that both routers store the forwarding information learned from the alternate router
in a secondary forwarding table, also referred to as context-specific label space. In the event that
the primary router fails, the secondary router will continue to forward traffic to the ultimate
destination using the forwarding information stored in the secondary forwarding table (contextspecific label space). This will continue until the rest of the network can converge to use an
alternate route through the network.
BGP anycast can be used in two different scenarios.
1. BGP to BGP label swapping in GRT Where the LDP and BGP labels of an incoming
IP packet will be swapped, and the packet being forwarded towards a destination in the
related region/area.
2. BGP to VRF Where an incoming packet, encapsulated with the redundant BGP
service label will be forwarded towards the related VRF where an (egress) IP lookup will
be performed so that the packet can be forwarded towards the correct CPE.

Advanced Configuration Guide

Page 165

Overview

Overview
GRT
Assume that an access node (or similar) is connected to PE-11, represented by prefix X1/32,
illustrated in Figure 30).
1. PE-11 will advertise a BGP labelled route towards its area border routers (ABRs) with its
own system-IP as next hop (NH) (regular behavior).
2. Both redundant ABR (11 and 12), acting as route reflectors (RRs) for their own region,
will advertise the route X1 towards the RR of the core, with their master anycast (AC)
address as an NH.
3. The RR (of the core) will select the best route out of both, in this case originated from
ABR-12 and reflects the route to all of the ABRs in the core.
4. The redundant ABR-11 will receive this BGP route and marks it as invalid since the NH
will be a local interface, being the slave anycast interface.
5. ABR-11 will, however, install the BGP label in the context specific label space, so that
incoming packets with the BGP label assigned by ABR-12 (step 2) and kept by ABR-11
(following upon the outer LDP label) can be forwarded towards destination X1.
iBGP Update

iBGP Update
NLRIX1 NH AC@ABR-12
is Best Route

Dest IP : RR
Src IP : ABR-11
NLRIX1 NH AC@ABR-11
LBL Y1

RR

System IP @ ABR-11
Master Anycast AC@ABR-11
Slave Anycast AC@ABR-12

ABR
11

RR

System IP @ ABR-11
Master Anycast AC@ABR-11
Slave Anycast AC@ABR-12

ABR
11
PE
11

ABR
12

Dest IP : ABR-11
Src IP : RR
NLRIX1NHAC@ABR-12
LBL Y2

ABR
12

NLRIX1 NH AC@ABR-12
is invalid route, but LBL Y
is installed in a contextspecific label table. If a
packet is received with the
LDP label toward AC@ABR-12
and BGP LBL Y2, the packet
will be forwarded toward
PE-11, where X1 is located.

iBGP Update
Dest IP : RR
Src IP : ABR-12
NLRIX1 NH AC@ABR-12
LBL Y2

System IP @ ABR-12
Master Anycast AC@ABR-12
Slave Anycast AC@ABR-11
OSSG607

Figure 30: BGP Anycast Operation in GRT

Page 166

Advanced Configuration Guide

BGP Anycast

Note that Figure 30 shows that X1 will be advertised by both (redundant) ABRs, each assigning
their master anycast address as the NH. RR will select one of them as best and will reflect the
route towards both ABRs. Only one ABR (ABR-11 in this case) will install the BGP anycast route
towards the destination X1. This is fine since ABR-12 will be selected by the other ABR
(connected to remote regions) in the core as NH for the route towards X1/32, hence ABR-12 will
receive the traffic from other regions towards X1, and if there is a failure on ABR-12 (link/nodal)
traffic will be diverted to ABR-11. ABR-11 can interpret the LDP and BGP labels, which are
advertised by ILDP and the BGP label (in the context-specific label space), which results in
forwarding traffic to X1.

Advanced Configuration Guide

Page 167

Overview

IP-VPN
In case of IP-VPN routes, the scenario is different since unique route distinguisher (RD) will result
in both IP-VPN routes being active at the RR, as illustrated Figure 31.

iBGP Update
RD1:X1 NH AC@ABR-11 and
RD2:X1 NH AC@ABR-12
are BEST routes

Dest IP : RR
Src IP : ABR-11
NLRID1:X1 NH AC@ABR-11
SVC-LBL Y1

RR

System IP @ ABR-11
Master Anycast AC@ABR-11
Slave Anycast AC@ABR-12

RR

iBGP Update
Dest IP : ABR-11
Src IP : RR
NLRI RD2:X1NH AC@ABR-12
LBL Y2

System IP @ ABR-11
Master Anycast AC@ABR-11
Slave Anycast AC@ABR-12

ABR
11

Both routes are invalid on


the ABRs, but both service
labels are installed in
context-specific label table.

ABR
11
CE

ABR
12

ABR
12

iBGP Update
Dest IP : RR
Src IP : ABR-12
NLRIRD2:X1
NH AC@ABR-12
SVC-LBL Y2

iBGP Update
System IP @ ABR-12
Master Anycast AC@ABR-12
Slave Anycast AC@ABR-11

Dest IP : RR
Src IP : ABR-12
NLRIRD2:X1
NH AC@ABR-11
LBL Y1

System IP @ ABR-12
Master Anycast AC@ABR-12
Slave Anycast AC@ABR-11
OSSG608

Figure 31: BGP Anycast Operation with IP-VPN

Page 168

Advanced Configuration Guide

BGP Anycast

Context-Specific Label Space


A key-point of the BGP anycast feature is the presence of a context-specific label space on the
Label Switch Router (LSR)/ABR. Where in normal MPLS scenarios, an LSR selects a free label
from its own label-range, installs this in the Label Forwarding Information Base (LFIB) and
signals this by a control protocol (BGP/LDP/RSVP), the LSR/ABR will now learn a label from a
redundant LSR/ABR and installs this as an ingress label into a dedicated label space. This
mechanism is different from the MPLS mechanisms used to date in the SR OS, which are based on
downstream label allocation.

Data Path in GRT


Figure 32 illustrates the data path from source S to destination X1.

PE-2
ABR
192.0.2.2
PE-1
192.0.2.1

L1 Area
49.0001

L2 Area

192.168.3.0/30

192.168.6.0/30

X1

192.168.25.0/30

192.168.5.0/30
.2

PE-5
ABR
192.0.2.5

PE-3
ABR
192.0.2.3

IP
L2

PE-6
192.0.2.6

192.168.15.0/30

.1

IP
BGP-LBL
LDP-LBL
L2

AC (Master)
L1 Area
49.0002

192.168.4.0/30

192.168.1.0/30
192.168.13.0/30

PE-4
ABR
192.0.2.4

IP
BGP-LBL
LDP-LBL
L2

AC (Slave)

IP
BGP-LBL
LDP-LBL
L2

IP
L2
OSSG609

Figure 32: BGP Anycast Data Path (BGP to BGP Swapping)

An incoming IP packet on PE-1 will be encapsulated in a dual MPLS label packet, where;
1. BGP label will assure the forwarding towards the remote PE, being PE-6 in this case, PE6 is part of the tunnel-table on PE-1, with BGP as MPLS control protocol.
2. LDP label will forward the packet to the anycast address of area 49.0002, where PE-4 is
the master (in normal operations).

Advanced Configuration Guide

Page 169

Overview

3. From PE-4 onwards, both the BGP and LDP labels are swapped, and forwarded out on
the interface towards PE-6.
The data path for IP-VPN routes is described in the IP-VPN routes section.

BGP Control Plane


Additional attention is required for the BGP control plane, where the ABR needs to act as RR for
its related region. This is mandatory since the ABR needs to perform a NHS (next hop self) action
to the BGP routes advertising the system addresses of the PE (or AN) in the region.
Note that different RR hierarchies can be created based upon different address families.

RR

RR
Core

PE-2
ABR
192.0.2.2

RR
Region

PE-4
ABR
192.0.2.4
L2 Area
PE-6
192.0.2.6

PE-1
192.0.2.1
L1 Area
49.0002

L1 Area
49.0001

.1

IBGP

192.168.0.0/30

.2

PE-3
ABR
192.0.2.3

PE-5
ABR
192.0.2.5

RR

RR
OSSG610

Figure 33: BGP Anycast BGP Topology

In this particular case, there is a cluster in the core area with PE-4 acting as RR. PE-4 is RR for 2
different clusters, 1.1.1.1 towards the core and 2.2.2.2 towards the regional PE-6. All other PEs
(PE-2-3-5) in the core act as an RR for their related region.

Page 170

Advanced Configuration Guide

BGP Anycast

Configuration
The following steps must be taken to configure the BGP anycast scenario.
1.
2.
3.
4.
5.

Create the anycast interfaces.


IGP configuration in the MPLS domain.
Enable LDP to assure reach ability of the ABR.
Configure BGP to advertise the system addresses of PE-1 and PE-6 with a BGP label.
Configure a service to set-up end-to-end connectivity.

Anycast Interface
Each ABR will be configured with two anycast addresses, a master and slave address. The
redundant ABR within the same area will be configured with the reverse, as seen in the following
configuration;
On PE-2:
A:PE-2>config>router# info
---------------------------------------------#-------------------------------------------------echo "IP Configuration"
#-------------------------------------------------mh-primary-interface "masterAnycast"
address 10.20.0.1/32
exit
mh-secondary-interface "slaveAnycast"
address 10.30.0.1/32

On PE-3:
*A:PE-3>config>router# info
---------------------------------------------#-------------------------------------------------echo "IP Configuration"
#-------------------------------------------------mh-primary-interface "masterAnycast"
address 10.30.0.1/32
exit
mh-secondary-interface "slaveAnycast"
address 10.20.0.1/32
exit

Both PE-2 and PE-3 will have 10.20.0.1 as one of their anycast addresses, but only PE-2 has it
configured as the master anycast address. Conversely both PE-2 and PE-3 have 10.30.0.1/32 as

Advanced Configuration Guide

Page 171

Configuration

one of their anycast addresses, but only PE3 has it configured as the master anycast address. Both
interfaces will be considered as a kind of virtual interface, with a virtual port-id;
*A:PE-3>config>router# show router interface "masterAnycast" detail | match Port
Port Id
: vport-7
*A:PE-3>config>router#

Both anycast addresses, master and slave will be visible in the GRT (global routing table) of the
PE (ABR);
*A:PE-2>config>router# show router route-table
===============================================================================
Route Table (Router: Base)
===============================================================================
Dest Prefix
Type
Proto
Age
Pref
Next Hop[Interface Name]
Metric
------------------------------------------------------------------------------10.20.0.1/32
Local
Local
01d14h16m
0
masterAnycast
0
10.30.0.1/32
Local
Local
01d14h16m
0
slaveAnycast
0

As similar configuration is performed on PE-4 and PE-5 with the anycast addresses being
(Figure 34):
PE-4: masterAnycast
slaveAnycast
PE-5: masterAnycast
slaveAnycast

=
=
=
=

10.40.0.1/32
10.50.0.1/32
10.50.0.1/32
10.40.0.1/32

Therefore, if PE-4 fails, for example, PE-5 will take over the responsibility for PE-4s master
anycast address (10.40.0.1); this will cause PE-2 and PE-3 to continue to send traffic which is
directed towards the BGP routes with a next hop of 10.40.0.1 (PE-4s masterAnycast address)
thinking its next hop is PE-4 when in reality it is PE-5. The failover initially only involves an IGP
(ISIS) re-convergence, and hence an LDP re-convergence, instead of a BGP re-convergence which
would take a longer time and therefore cause a larger outage (the IGP re-convergence may be
reduced if ECMP or LDP FRR is used and an alternate label is already installed in the LFIB of PE2/PE-3). BGP will subsequently re-converge such that the BGP next hop on PE-2 and PE-3
becomes 10.50.0.1 when they receive the withdraw of PE-4s 10.40.0.1/32 from the RR.

Page 172

Advanced Configuration Guide

BGP Anycast

PE-2:
masterAnycast = 10.20.0.1/32
slaveAnycast = 10.30.0.1/32

L1 Area
49.0001

PE-4:
masterAnycast = 10.40.0.1/32
slaveAnycast = 10.50.0.1/32

PE-2

PE-4

AER
192.0.2.2

AER
192.0.2.4

PE-1

L1 Area
49.0002
PE-6

L2 Area

AER
192.0.2.6

192.0.2.1

PE-3

PE-5

AER
192.0.2.3

AER
192.0.2.5

PE-3:
masterAnycast = 10.30.0.1/32
slaveAnycast = 10.20.0.1/32

PE-5:
masterAnycast = 10.50.0.1/32
slaveAnycast = 10.40.0.1/32
ACG0014

Figure 34: Anycast Address Configuration

Advanced Configuration Guide

Page 173

Configuration

IGP
Since both anycast addresses (master and slave) need to be reachable from the remote ABR and all
remote PEs, they have to be advertised into the IGP (ISIS in this case). This will result in
following ISIS configuration;
*A:PE-2>config>router>isis# info
---------------------------------------------area-id 49.0001
export "remoteABR"
traffic-engineering
interface "system"
passive
exit
interface "masterAnycast"
level-capability level-2
exit
interface "slaveAnycast"
level-capability level-2
exit
interface "int-PE-2-PE-3"
level-capability level-2
interface-type point-to-point
exit
interface "int-PE-2-PE-4"
level-capability level-2
interface-type point-to-point
exit
interface "int-PE-2-PE-1"
level-capability level-1
interface-type point-to-point
exit
---------------------------------------------*A:PE-2>config>router>isis#

Here, notice that the master and slave interface will be part of the Layer 2 area. Both interfaces
will automatically be assigned with the correct ISIS metric, being 10 for the master and 30 for the
slave (default values).
*A:PE-2>config>router>isis# show router isis interface
===============================================================================
ISIS Interfaces
===============================================================================
Interface
Level CircID Oper State
L1/L2 Metric
------------------------------------------------------------------------------system
L1L2 1
Up
0/0
masterAnycast
L2
2
Up
-/10
slaveAnycast
L2
3
Up
-/30

The IGP (ISIS) metric can be configured to a different value if required.

Page 174

Advanced Configuration Guide

BGP Anycast

The ISIS export policy is used to control redistribution of prefixes and essentially serves two
purposes.
1. Ensure that anycast addresses and system IP addresses of other ABRs learned in Layer 2
LSPs through the core (from the perspective of PE-2, this would include PE-4 and PE-5)
are re-advertised to PEs in the same area as Layer 1 LSPs.
2. Ensure that system IP addresses of PEs in the same region as the ABR learned through
L1 LSPs are not advertised into the core as Layer 2 LSPs. The reason for this is that it is
mandatory that a remote ABR has a best route to a remote PE (in a different area)
through BGP and not by an IGP route in the FIB, otherwise it would not advertise the
labeled BGP route toward PEs in its own region.
*A:PE-2>config>router>policy-options# info
---------------------------------------------prefix-list "PE"
prefix 192.0.2.1/32 exact
exit
prefix-list "remoteABR"
prefix 10.40.0.1/32 exact
prefix 10.50.0.1/32 exact
prefix 192.0.2.4/32 exact
prefix 192.0.2.5/32 exact
exit
prefix-list "masterAnycast"
prefix 10.20.0.1/32 exact
exit
policy-statement "remoteABR"
entry 10
from
prefix-list "remoteABR"
exit
action accept
exit
exit
entry 20
description "reject system-ip of own region"
from
prefix-list "PE"
exit
action reject
exit
exit

Advanced Configuration Guide

Page 175

Configuration

LDP
All physical interfaces need to be part of ILDP so that the BGP label can be encapsulated in an
MPLS packet with an LDP label. The configuration on PE-2 looks like the following.
*A:PE-2>config>router>ldp# info
---------------------------------------------export "exp-anycast"
interface-parameters
interface "int-PE-2-PE-3"
exit
interface "int-PE-2-PE-4"
exit
interface "int-PE-2-PE-1"
exit
exit
targeted-session
exit
---------------------------------------------* A:PE-2>config>router>ldp# show router policy "exp-anycast"
entry 10
description "advertise master anycast address"
from
prefix-list "masterAnycast"
exit
to
protocol ldp
exit
action accept
exit
exit
entry 20
description "advertise slave anycast address as well"
from
prefix-list "slaveAnycast"
exit
to
protocol ldp
exit
action accept
exit
exit
A:PE-2>config>router>ldp#

By default, only the system address will be advertised by ILDP; hence the need for the export
policy. This policy will advertise both the master and slave anycast address. The slave address
advertisement is needed in both ABRs so that PE-2 can take over the role from the master (PE-3)
in case of link or node failures (and vice versa).
To verify the LDP bindings, check if PE-2 can reach the remote anycast addresses through LDP,
but not its own master and slave anycast address.

Page 176

Advanced Configuration Guide

BGP Anycast

A:PE-2>config>router>ldp# show router ldp bindings


===============================================================================
LDP LSR ID: 192.0.2.2
===============================================================================
Legend: U - Label In Use, N - Label Not In Use, W - Label Withdrawn
S - Status Signaled Up, D - Status Signaled Down
E - Epipe Service, V - VPLS Service, M - Mirror Service
A - Apipe Service, F - Fpipe Service, I - IES Service, R - VPRN service
P - Ipipe Service, WP - Label Withdraw Pending, C - Cpipe Service
TLV - (Type, Length: Value)
===============================================================================
LDP Prefix Bindings
===============================================================================
Prefix
Peer
IngLbl
EgrLbl EgrIntf/
EgrNextHop
LspId
------------------------------------------------------------------------------10.20.0.1/32
192.0.2.1
262140U
---10.20.0.1/32
192.0.2.4
262140U
---10.30.0.1/32
192.0.2.1
262139U
---10.30.0.1/32
192.0.2.4
262139U
---10.40.0.1/32
192.0.2.1
262143U
262143
--10.40.0.1/32
192.0.2.3
262143U
262135
--10.40.0.1/32
192.0.2.4
-262139 1/1/3:0
192.168.4.2
10.50.0.1/32
192.0.2.1
262130U
262138
--10.50.0.1/32
192.0.2.3
262130N
262142 1/1/2:0
192.168.13.2
10.50.0.1/32
192.0.2.4
-262143
--192.0.2.1/32
192.0.2.1
-262142 1/1/1:0
192.168.2.1
192.0.2.1/32
192.0.2.3
262134U
262132
---

PE-2 can reach the remote anycast addresses 10.40.0.1 and 10.50.0.1. In this case both addresses
are reachable by a different interface. Note that it can be via the same interface as well, due to the
ECMP nature in the (Layer 2 area) square topology, where 10.50.0.1 can be reached via PE-4 as
well as PE-2. There is no outgoing label for 10.20.0.1 and 10.30.0.1 which is to be expected since
they are local addresses on PE-2.
To verify the actual datapath, following OAM command can be used.
*A:PE-2# oam
lsp-trace to
1 192.0.2.4
*A:PE-2# oam
lsp-trace to
1 192.0.2.3
2 192.0.2.5
*A:PE-2#

lsp-trace prefix 10.40.0.1/32


10.40.0.1/32: 0 hops min, 0 hops max, 104 byte packets
rtt=2.02ms rc=3(EgressRtr)
lsp-trace prefix 10.50.0.1/32
10.50.0.1/32: 0 hops min, 0 hops max, 104 byte packets
rtt=2.76ms rc=8(DSRtrMatchLabel)
rtt=3.57ms rc=3(EgressRtr)

Advanced Configuration Guide

Page 177

Configuration

BGP Configuration
The configuration of BGP will be split up in following parts;
1. BGP configuration on the ABR
2. BGP configuration on the RR
3. BGP configuration on the PE

BGP on the ABR


The following BGP configuration is present on PE-2;
*A:PE-2# configure router bgp
*A:PE-2>config>router>bgp# info
---------------------------------------------min-route-advertisement 10
group "region"
description "all PE of the region will peer with this ABR"
family ipv4 vpn-ipv4
type internal
cluster 2.2.2.2
neighbor 192.0.2.1
advertise-label ipv4
exit
exit
group "fullmesh"
description "PE-4 is RR"
family ipv4 vpn-ipv4
type internal
export "exp-anycast-nhs"
neighbor 192.0.2.4
advertise-label ipv4
exit
exit
---------------------------------------------*A:PE-2>config>router>bgp#

The two groups identify the PE in the local region (part of L1 area) and the RR in the core (part of
Layer 2 area).
The export policy will set the next-hop of the IPv4 and IPv4-VPN routes equal to the master
anycast address;
A:PE-2>config>router>bgp# show router policy "exp-anycast-nhs"
entry 10
description "set NH of PE to master anycast"
from
prefix-list "PE"
family ipv4
exit

Page 178

Advanced Configuration Guide

BGP Anycast

to
protocol bgp
exit
action accept
local-preference 150 (*)
next-hop 10.20.0.1
exit
exit
entry 20
description "set NH of IP-VPN routes to master anycast"
from
family vpn-ipv4
exit
to
protocol bgp-vpn
exit
action accept
local-preference 150 (*)
next-hop 10.20.0.1
exit
exit
A:PE-2>config>router>bgp#

(*) optional, not mandatory for functional testing.


For testing purpose, this policy is sufficient. In reality more restrictions will be needed to avoid
obsolete advertisements of routes by the ABR, but this is out-of-scope for this document.

Advanced Configuration Guide

Page 179

Configuration

BGP on the RR
BGP on RR (PE-4) will look like the following;
A:PE-4>config>router>bgp# info
---------------------------------------------vpn-apply-import
vpn-apply-export
min-route-advertisement 1
group "region"
description "all PE of the region will peer with this ABR"
family ipv4 vpn-ipv4
type internal
cluster 4.4.4.4
neighbor 192.0.2.6
advertise-label ipv4
exit
exit
group "fullmesh"
description "RR in cluster 1.1.1.1"
family ipv4 vpn-ipv4
type internal
cluster 1.1.1.1
export "exp-anycast-nhs"
neighbor 192.0.2.2
advertise-label ipv4
exit
neighbor 192.0.2.3
advertise-label ipv4
exit
neighbor 192.0.2.5
advertise-label ipv4
exit
exit
---------------------------------------------A:PE-4>config>router>bgp# show router policy "exp-anycast-nhs"
entry 10
description "set NH of PE to master anycast"
from
prefix-list "PE"
family ipv4
exit
to
protocol bgp
exit
action accept
local-preference 150
next-hop 10.40.0.1
exit
exit
A:PE-4# show router policy prefix-list "PE"
prefix 192.0.2.6/32 exact
prefix 192.168.0.6/32 exact
A:PE-4#

Page 180

Advanced Configuration Guide

BGP Anycast

Where the anycast address is set as the BGP NH in all IPv4 prefixes for all PEs in the attached
area/region. The BGP NH is not set for IP-VPN routes, as this would override the NH in
advertised IP-VPN routes of PE-2 and PE-3 for which PE-4 acts as RRs and should therefore not
modify the NH of the IP-VPN routes.

BGP on the PE
Each PE will have a peering towards each ABR of its own region. In this case PE-1 will peer with
PE-2 and PE-3, which in turn act as RRs so there are no inter-PE peering sessions required within
the region.
*A:PE-1# configure router bgp
*A:PE-1>config>router>bgp# info
---------------------------------------------min-route-advertisement 10
group "abr"
description "peering to ABR, which act as RR"
family ipv4 vpn-ipv4
type internal
export "expbgp"
neighbor 192.0.2.2
advertise-label ipv4
exit
neighbor 192.0.2.3
advertise-label ipv4
exit
exit
---------------------------------------------A:PE-1>config>router>bgp#

The referenced export policy triggers the advertisement of the PE-1 system IP address with a
BGP-label.
A:PE-1# show router policy "expbgp"
entry 10
from
prefix-list "PE"
exit
to
protocol bgp
exit
action accept
exit
exit
A:PE-1# show router policy prefix-list "PE"
prefix 192.0.2.1/32 exact
A:PE-1#

Advanced Configuration Guide

Page 181

Configuration

Data Path Verification


The best way to verify the data path is between both (remote) PEs.
Looking at PE-1, verify the following:
1. Was a BGP route received toward PE-6 with an NH equal to an anycast address?
A:PE-1# show router bgp routes 192.0.2.6/32
===============================================================================
BGP Router ID:192.0.2.1
AS:65536
Local AS:65536
===============================================================================
Legend Status codes : u - used, s - suppressed, h - history, d - decayed, * - valid
Origin codes : i - IGP, e - EGP, ? - incomplete, > - best
===============================================================================
BGP IPv4 Routes
===============================================================================
Flag Network
LocalPref
MED
Nexthop
VPNLabel
As-Path
------------------------------------------------------------------------------u*>i 192.0.2.6/32
150
10
10.40.0.1
No As-Path
*i
192.0.2.6/32
150
10
10.50.0.1
No As-Path
------------------------------------------------------------------------------Routes : 2
===============================================================================
A:PE-1#

Note that both routes are in fact equal from a BGP point of view. If ECMP and (BGP) multipath
would have been set to 2, both routes would be active in the RTM.
2. Can the anycast addresses be reached through LDP?
*A:PE-1# show router ldp bindings prefix 10.40.0.1/32
===============================================================================
LDP LSR ID: 192.0.2.1
===============================================================================
Legend: U - Label In Use, N - Label Not In Use, W - Label Withdrawn
WP - Label Withdraw Pending
===============================================================================
LDP Prefix Bindings
===============================================================================
Prefix
Peer
IngLbl
EgrLbl EgrIntf
EgrNextHop
------------------------------------------------------------------------------10.40.0.1/32
192.0.2.2
262143N
262143 1/1/1:0
192.168.2.2
10.40.0.1/32
192.0.2.3
262143U
262135
--------------------------------------------------------------------------------No. of Prefix Bindings: 2
===============================================================================
*A:PE-1# oam lsp-trace prefix 10.40.0.1/32
lsp-trace to 10.40.0.1/32: 0 hops min, 0 hops max, 104 byte packets

Page 182

Advanced Configuration Guide

BGP Anycast

1 192.0.2.2
2 192.0.2.4
*A:PE-1#

rtt=2.18ms rc=8(DSRtrMatchLabel)
rtt=2.88ms rc=3(EgressRtr)

There are two labels learned and one is active since the shortest path to PE-4 is via PE-2, as seen in
the OAM command.
3. Verify that the ABR has learned the anycast advertisements of the neighboring master.
This is needed to evaluate the incoming labelled packets correctly after failures in the
Layer 2 area (link or node).
On PE-2, observe the presence of the anycast label in the context-specific label space, with a link
to VPRN-id 1. This is described in IP-VPN Routes on page 190.
A:PE-2# show router bgp anycast-label
===============================================================================
BGP Anycast-MH labels
===============================================================================
Secondary-MH-Addr
ABR-Lbl
Cfg-Time VPRN-ID
PE-Addr
PE-Lbl
Rem-Time Ref-Count
------------------------------------------------------------------------------10.30.0.1
262130
30
1
3
===============================================================================
A:PE-2#

On the redundant ABR PE-3, an additional label-mapping is present because the route
192.168.0.1/32 (part of GRT) is received on PE-3 with the anycast NH of PE-2. PE-2 does not
receive this route from PE-3 because the RR (PE-4) has selected the route 192.168.0.1/32 from
PE-2 as the best one, which means that PE-2 will not receive the route to 192.168.0.1/32 with PE3 anycast address as NH.
A:PE-3# show router bgp anycast-label
===============================================================================
BGP Anycast-MH labels
===============================================================================
Secondary-MH-Addr
ABR-Lbl
Cfg-Time VPRN-ID
PE-Addr
PE-Lbl
Rem-Time Ref-Count
------------------------------------------------------------------------------10.20.0.1
262131
30
192.0.2.1
262134
1
10.20.0.1
262133
30
1
3
===============================================================================
A:PE-3#

This command can be used to check the mapping of BGP labels in the context-specific label
space.
More details are provided Deployment Options on page 185.

Advanced Configuration Guide

Page 183

Configuration

4. Verify data path towards PE-6, where some basic CLI commands can be used;
*A:PE-1# show router route-table 192.0.2.6/32
===============================================================================
Route Table (Router: Base)
===============================================================================
Dest Prefix
Type
Proto
Age
Pref
Next Hop[Interface Name]
Metric
------------------------------------------------------------------------------192.0.2.6/32
Remote BGP
00h30m50s
170
10.40.0.1 (tunneled)
0
------------------------------------------------------------------------------No. of Routes: 1
===============================================================================
*A:PE-1#
*A:PE-1# show router fib 1 192.0.2.6/32
===============================================================================
FIB Display
===============================================================================
Prefix
Protocol
NextHop
------------------------------------------------------------------------------192.0.2.6/32
BGP
10.40.0.1 (Transport:LDP)
------------------------------------------------------------------------------Total Entries : 1
------------------------------------------------------------------------------===============================================================================
...
*A:PE-1# show router tunnel-table
===============================================================================
Tunnel Table (Router: Base)
===============================================================================
Destination
Owner Encap TunnelId Pref
Nexthop
Metric
------------------------------------------------------------------------------192.0.2.6/32
bgp
MPLS
10
10.40.0.1
1000
===============================================================================
*A:PE-1# traceroute 192.0.2.6 no-dns
traceroute to 192.0.2.6, 30 hops max, 40 byte packets
1 192.0.2.6
28.9 ms 4.53 ms 5.00 ms
*A:PE-1#

Page 184

Advanced Configuration Guide

BGP Anycast

Deployment Options
There are two main deployment options with BGP anycast.
1. Providing and end-to-end (E2E) MPLS tunnel, between access nodes (ANs) connected to
the PE. In this case, VLLs can be supported between AN over a BGP signalled SDP. This
solves scaling issues and also provides resiliency.
2. Use the anycast address as the NH for IP-VPN routes, which improves NH tracking in
large MPLS domains, where IGP convergence can not contribute to the NH convergence.

E2E MPLS Between Access Nodes


The AN will be simulated by loopback interfaces on PE-1 and PE-6. From a functional point of
view this is equivalent to a connected AN that is not part of the IGP domain.

PE-2
ABR
192.0.2.2

PE-4
ABR
192.0.2.4

Lo1
192.168.0.1/32

Lo1
192.168.0.6/32

L1 Area
49.0001

PE-1
192.0.2.1

L2 Area

.1

PE-3
ABR
192.0.2.3

192.168.0.0/30

L1 Area
49.0002

.2

PE-6
192.0.2.6

PE-5
ABR
192.0.2.5
OSSG615

Figure 35: E2E MPLS Between Access Nodes

The loopback interface Lo1 is not part of the IGP (ISIS) but will be advertised by BGP towards
the ABR with a BGP label. The configuration looks like the following.
*A:PE-1>config>router# info
---------------------------------------------#-------------------------------------------------echo "IP Configuration"
#-------------------------------------------------interface "lo1"
address 192.168.0.1/32
description "simulate an AN (access node) "

Advanced Configuration Guide

Page 185

Configuration

loopback
exit
interface "system"
address 192.0.2.1/32
exit
autonomous-system 64496

BGP Configuration
The BGP configuration on the regional PE will look like the following:
A:PE-1# configure router bgp
A:PE-1>config>router>bgp# info
---------------------------------------------vpn-apply-import
vpn-apply-export
min-route-advertisement 1
group "abr"
description "peering to ABR, which act as RR"
family ipv4 vpn-ipv4
type internal
export "expbgp"
neighbor 192.0.2.2
advertise-label ipv4
exit
neighbor 192.0.2.3
advertise-label ipv4
exit
exit
---------------------------------------------A:PE-1>config>router>bgp# show router policy "expbgp"
entry 10
description "advertise the PE system-ip through BGP"
from
prefix-list "PE"
exit
to
protocol bgp
exit
action accept
local-preference 200
exit
exit
entry 20
description "advertise connect AN through BGP"
from
prefix-list "AN"
exit
to
protocol bgp
exit
action accept
exit
exit

Page 186

Advanced Configuration Guide

BGP Anycast

A:PE-1>config>router>bgp# show router policy prefix-list "AN"


prefix 192.168.0.1/32 exact
A:PE-1>config>router>bgp# show router policy prefix-list "PE"
prefix 192.0.2.1/32 exact
A:PE-1>config>router>bgp#

The prefix list should include all the addresses of connected ANs that need to be reachable through
labelled BGP.
Note that the ABR will also learn the BGP route advertisement of its neighboring ABR and
installs the BGP label accordingly, as shown in Figure 36.

Lo1
192.168.0.1/32

PE-2
ABR
192.0.2.2
BGP Update:
192.168.0.1/32
LBL = 162131

L1 Area
49.0001

PE-1
192.0.2.1

Lo1
192.168.0.1/32

PE-2
ABR
192.0.2.2
L1 Area
49.0001

PE-1
192.0.2.1

BGP Update:
192.168.0.1/32
LBL = 162131

PE-3
ABR
192.0.2.3

IP
262131
LDP-LBL
L2

PE-3
ABR
192.0.2.3

IP
262132
LDP-LBL
L2

A:PE-3# show router bgp anycast-label


=======================================================================
BGP Anycast-NH labels
=======================================================================
Secondary-NH-Addr
ABR-Lbl Cfg-Time VPRN-ID
PE-Addr
PE-Lbl
Rem-Time Ref-Count
----------------------------------------------------------------------10.20.0.1
262132
30
192.0.2.1
262131 1
=======================================================================
A:PE-3#
OSSG611

Figure 36: Data Path with Failing ABR

In case PE-2 fails or becomes unreachable, PE-3 can still recognize the BGP label of the packet
and perform the correct BGP (and LDP) label swap so that the packet will not be dropped and can
continue its way towards the destination.
Note that for every AN a new entry in the BGP anycast-label table will be added. Refer to the
following output.

Advanced Configuration Guide

Page 187

Configuration

BGP anycast for A:PE-3# show router bgp anycast-label


===============================================================================
BGP Anycast-MH labels
===============================================================================
Secondary-MH-Addr
ABR-Lbl
Cfg-Time VPRN-ID
PE-Addr
PE-Lbl
Rem-Time Ref-Count
------------------------------------------------------------------------------10.20.0.1
262131
30
192.0.2.1
262134
1
10.20.0.1
192.0.2.1

262132
262131

30
-

Important note: If an E2E MPLS transport tunnel is needed between PE-1 and PE-6, additional
loopback interfaces need to be created on both PE since the system address cannot be used with
the BGP anycast feature. The reason for this is that on the ABR, the best route towards the PE
system-ip is an IGP route, not a (labeled) BGP route. BGP anycast can only map a BGP label
against another BGP label, not towards an IGP (hence LDP) route1. This is important to keep in
mind, if BGP anycast is deployed in networks where BGP anycast is required for E2E MPLS
tunnels between AN and remote PEs.
Figure 37 illustrates the SDP between PE-1 and PE-6.
PE-2
ABR
192.0.2.2

PE-4
ABR
192.0.2.4

Lo1
192.168.0.1/32

Lo1
192.168.0.6/32

L1 Area
49.0001

System-ip
192.168.2.6/32

PE-1
192.0.2.1

L2 Area

.1

PE-3
ABR
192.0.2.3

192.168.0.0/30

L1 Area
49.0002

System-ip
192.168.2.6/32

PE-6
192.0.2.6

.2

PE-5
ABR
192.0.2.5

SDP
OSSG612

Figure 37: End-to-End Transport Tunnel Using Additional Loopback Interfaces

1. Although PE-1 will advertise the system IP as a BGP-labeled route, it cannot be used for the BGP
anycast feature since the route to system IP of PE-1 in the GRT of PE-2 and PE-3 will always be an
IGP route, which makes it impossible to use the BGP anycast feature since this requires an E2E BGP
tunnel.

Page 188

Advanced Configuration Guide

BGP Anycast

SDP Configuration
The SDP configuration consists of two parts, the service component and LDP component.
In the service context, the SDP will be created with BGP as the tunneling protocol.
*A:PE-1# configure service sdp 100
*A:PE-1>config>service>sdp# info
---------------------------------------------far-end 192.168.0.6
bgp-tunnel
keep-alive
shutdown
exit
no shutdown
---------------------------------------------*A:PE-1>config>service>sdp#

Since the T-LDP session is set up between two loopback interfaces instead of the system IP of PE1 and PE-6, a dedicated configuration is required at the LDP level.
*A:PE-1# show router interface "lo1"
===============================================================================
Interface Table (Router: Base)
===============================================================================
Interface-Name
Adm
Opr(v4/v6) Mode
Port/SapId
IP-Address
PfxState
------------------------------------------------------------------------------lo1
Up
Up/Down
Network loopback
192.168.0.1/32
n/a
------------------------------------------------------------------------------Interfaces : 1
===============================================================================
*A:PE-1#
*A:PE-1# configure router ldp
*A:PE-1>config>router>ldp# info
---------------------------------------------interface-parameters
interface "int-PE-1-PE-2"
exit
interface "int-PE-1-PE-3"
exit
exit
targeted-session
peer 192.168.0.6
local-lsr-id "lo1"
exit
exit
---------------------------------------------*A:PE-1>config>router>ldp#

Note that where the destination address of the T-LDP session is set to the remote loopback address
and the local address is set to the local loopback interface.

Advanced Configuration Guide

Page 189

Configuration

IP-VPN Routes
Important note: In the SR-OS 9.0R1 software release, BGP anycast for IP-VPN routes is only
supported with a RR cluster in the core. A full mesh of iBGP peers or confederations are not
supported in SROS 9.0R1.
The BGP anycast mechanism can also be used to advertise IP-VPN routes. The advertising PE sets
the NH equal to the anycast master address instead of the regular system IP. The configuration is
based upon PE-1 which will now act as a customer edge (CE) device. This can be achieved by
creating a local IP-VPN on PE-1, without any MPLS connectivity, due to the use of a unique RT
(route-target) and hybrid ports towards the ABR2. As such, both PE-2 and PE-3 can advertise the
same route with the AC address as a NH.
Figure 38 illustrates the logical IP-VPN topology.

PE-2
ABR
192.0.2.2

L2 Area

PE-4
ABR
192.0.2.4

eBGP Session PE-CE


PE (IP-VPN)
L1 Area
49.0002

PE-1
192.0.2.1

.1

PE-3
ABR
192.0.2.3

192.168.0.0/30

CE (Local IP-VPN)

PE-6
192.0.2.6

.2

PE-5
ABR
192.0.2.5
OSSG613

Figure 38: IP-VPN with Anycast NH

2. The unique RT and hybrid ports are required for this specific set-up where PE-1 is com-

bined as a regular PE and as CE. The CE functionality is achieved by creating a local


VPRN, and the unique RT will assure that the route is not imported at PE-2 and PE-3 by
MP-BGP. The hybrid port is needed to combine a PE-CE interface and network interface
(MPLS capable) on the same physical port.

Page 190

Advanced Configuration Guide

BGP Anycast

Configure IP-VPN at the PE (PE-2 and PE-3)


The following output displays the VPRN configuration. The change of the next-hop to the BGP
anycast address is done at the BGP group level in this case.
A:PE-2>config>service>vprn# info
---------------------------------------------description "IP-VPN PE, with anycast NH set"
vrf-import "vrfImpPolBgpVpnRts"
vrf-export "adv_vpn"
router-id 192.0.2.2
autonomous-system 64498
route-distinguisher 1:2
auto-bind ldp
vrf-target target:1:1
interface "to_CE" create
address 172.16.2.2/30
sap 1/1/1:1 create
exit
exit
bgp
group "CE"
type external
export "exp_bgp_vpn_rts_to_ce"
peer-as 64499
neighbor 172.16.2.1
exit
exit
exit
no shutdown
---------------------------------------------A:PE-2>config>service>vprn#

A:PE-2>config>service>vprn# show router policy "vrfImpPolBgpVpnRts"


description "Policy From bgpVpn To none"
entry 10
description "Entry 10 - From Prot. bgpVpn To none"
from
protocol bgp-vpn
community "vprn1"
exit
to
exit
action accept
exit
exit
A:PE-2>config>service>vprn# show router policy "adv_vpn"
entry 10
description "local routes"
from
protocol direct
exit
to
protocol bgp-vpn
exit
action accept

Advanced Configuration Guide

Page 191

Configuration

community add "vprn1"


exit
exit
entry 20
description "PE-CE BGP routes"
from
protocol bgp
exit
to
protocol bgp-vpn
exit
action accept
community add "vprn1"
exit
exit
A:PE-2# show router policy community "vprn1"
community "vprn1" members "target:1:1"
A:PE-2#
A:PE-2# show router policy "exp_bgp_vpn_rts_to_ce"
description "Policy From bgpVpn To none"
entry 10
description "Entry 10 - From Prot. bgpVpn To none"
from
protocol bgp-vpn
exit
to
exit
action accept
exit
exit
A:PE-2#

Note that the route distinguisher of VPRN 1 at PE-3 is set to 1:3 instead of 1:2 as on PE-2.
As stated above, the NH will be set to the anycast address in the BGP group at the global level.
*A:PE-2# configure router bgp
*A:PE-2>config>router>bgp# info
---------------------------------------------vpn-apply-export
min-route-advertisement 1
group "region"
description "all PE of the region will peer with this ABR"
family ipv4 vpn-ipv4
type internal
cluster 1.1.1.1
neighbor 192.0.2.1
advertise-label ipv4
exit
exit
group "fullmesh"
description "PE-4 is RR"
family ipv4 vpn-ipv4
type internal
export "exp-anycast-nhs"
neighbor 192.0.2.4
advertise-label ipv4

Page 192

Advanced Configuration Guide

BGP Anycast

exit
exit
---------------------------------------------*A:PE-2>config>router>bgp# show router policy "exp-anycast-nhs"
entry 10
description "set NH of PE to master anycast"
from
prefix-list "PE"
family ipv4
exit
to
protocol bgp
exit
action accept
local-preference 150 (*)
next-hop 10.20.0.1
exit
exit
entry 20
description "set NH of IP-VPN routes to master anycast"
from
family vpn-ipv4
exit
to
protocol bgp-vpn
exit
action accept
local-preference 150 (*)
next-hop 10.20.0.1
exit
exit
*A:PE-2>config>router>bgp#
(*) optional

Advanced Configuration Guide

Page 193

Configuration

Configure IP-VPN at the Remote PE (PE-6)


On PE-6, IP-VPN routes need to be advertised with the address of lo1 as NH, instead of the
regular system-ip. This is required to use a BGP tunnel (and on top of that BGP anycast) to reach
PE-6 from PE-2 and PE-3.
A:PE-6>config>service>vprn# info
---------------------------------------------vrf-import "vrfImpPolBgpVpnRts"
router-id 172.16.6.6
route-distinguisher 1:6
auto-bind mpls
vrf-target target:1:1
interface "lo1" create
address 172.16.6.6/32
loopback
exit
no shutdown
---------------------------------------------A:PE-6>config>service>vprn#

Note that the NH of the IP-VPN routes will be set to 192.168.0.6 instead of the system-ip;
A:PE-6# configure router bgp
A:PE-6>config>router>bgp# info
---------------------------------------------vpn-apply-import
vpn-apply-export
min-route-advertisement 1
outbound-route-filtering
exit
group "abr"
description "peering to ABR, which act as RR"
family ipv4 vpn-ipv4
type internal
export "expbgp"
neighbor 192.0.2.4
advertise-label ipv4
exit
neighbor 192.0.2.5
advertise-label ipv4
exit
exit
---------------------------------------------A:PE-6>config>router>bgp# show router policy
policy
policy-edits
A:PE-6>config>router>bgp# show router policy "expbgp"
entry 10
description "advertise the PE system-ip through BGP"
from
prefix-list "PE"
exit
to
protocol bgp
exit
action accept

Page 194

Advanced Configuration Guide

BGP Anycast

local-preference 200
exit
exit
entry 20
description "advertise connect AN through BGP"
from
prefix-list "AN"
exit
to
protocol bgp
exit
action accept
exit
exit
entry 30
description "set NH for vpn-routes to 192.168.0.6"
from
community "vprn1"
exit
action accept
local-preference 333
next-hop 192.168.0.6
exit
exit
A:PE-6>config>router>bgp# exit all
A:PE-6# show router policy prefix-list "AN"
prefix 192.168.0.6/32 exact
A:PE-6# show router policy prefix-list "PE"
prefix 192.0.2.6/32 exact
A:PE-6#

The local preference is set to 333 for troubleshooting purposes, primarily to find the routes again
more easily.
The NH 192.168.0.6 is a local loopback, and reachable from PE-2 and PE-3 by a BGP tunnel with
the anycast address of PE-4 as NH.
On PE-6:
A:PE-6# show router interface
===============================================================================
Interface Table (Router: Base)
===============================================================================
Interface-Name
Adm
Opr(v4/v6) Mode
Port/SapId
IP-Address
PfxState
------------------------------------------------------------------------------int-PE-6-PE-4
Up
Up/Down
Network 1/1/1:0
192.168.6.2/30
n/a
int-PE-6-PE-5
Up
Up/Down
Network 1/1/3:0
192.168.25.2/30
n/a
lo1
Up
Up/Down
Network loopback
192.168.0.6/32
n/a
system
Up
Up/Down
Network system
192.0.2.6/32
n/a
------------------------------------------------------------------------------Interfaces : 4
===============================================================================

Advanced Configuration Guide

Page 195

Configuration

A:PE-6#

On PE-2 (and PE-3):


A:PE-2# show router tunnel-table
===============================================================================
Tunnel Table (Router: Base)
===============================================================================
Destination
Owner Encap TunnelId Pref
Nexthop
Metric
------------------------------------------------------------------------------10.40.0.1/32
ldp
MPLS
9
192.168.4.2
20
10.50.0.1/32
ldp
MPLS
9
192.168.13.2
30
192.0.2.1/32
ldp
MPLS
9
192.168.2.1
10
192.0.2.3/32
ldp
MPLS
9
192.168.2.1
20
192.0.2.4/32
ldp
MPLS
9
192.168.4.2
10
192.0.2.5/32
ldp
MPLS
9
192.168.13.2
20
192.0.2.6/32
bgp
MPLS
10
10.40.0.1
1000
192.168.0.6/32
bgp
MPLS
10
10.40.0.1
1000
===============================================================================
A:PE-2#

On PE-4 (and PE-5):


The BGP anycast labels are active.
A:PE-4# show router bgp anycast-label
===============================================================================
BGP Anycast-MH labels
===============================================================================
Secondary-MH-Addr
ABR-Lbl
Cfg-Time VPRN-ID
PE-Addr
PE-Lbl
Rem-Time Ref-Count
------------------------------------------------------------------------------10.50.0.1
262132
30
192.0.2.6
262132
1
===============================================================================
A:PE-4#

Page 196

Advanced Configuration Guide

BGP Anycast

Configure IP-VPN at the CE


On PE-1, VPRN 1 is a local IP-VPN acting as CE. The IP-VPN is dual homed towards PE-2 and
PE-3, including EBGP sessions that will advertise the directly connected links toward the PE.
A:PE-1>config>service>vprn# info
---------------------------------------------description "local VPN, simulating CE"
router-id 172.168.1.1
autonomous-system 64499
route-distinguisher 1:1
interface "to_ABR_PE3" create
address 172.16.3.1/30
sap 1/1/3:1 create
exit
exit
interface "to_ABR_PE2" create
address 172.16.2.1/30
sap 1/1/1:1 create
exit
exit
interface "lo1" create
address 172.168.1.1/32
loopback
exit
bgp
min-route-advertisement 1
export "adv_direct"
group "ABR"
type external
peer-as 64498
neighbor 172.16.2.2
exit
neighbor 172.16.3.2
exit
exit
exit
no shutdown
---------------------------------------------A:PE-1>config>service>vprn#

A:PE-1>config>service>vprn# show router policy "adv_direct"


entry 10
description "advertise local interfaces to PE"
from
protocol direct
exit
to
protocol bgp
exit
action accept
exit
exit
A:PE-1>config>service>vprn#

Advanced Configuration Guide

Page 197

Configuration

To verify the BGP peering sessions;


A:PE-1# show router 1 bgp summary
===============================================================================
BGP Router ID:192.0.2.1
AS:64499
Local AS:64499
===============================================================================
BGP Admin State
: Up
BGP Oper State
: Up
Total Peer Groups
: 1
Total Peers
: 2
Total BGP Paths
: 3
Total Path Memory
: 384
Total IPv4 Remote Rts
: 4
Total IPv4 Rem. Active Rts : 0
Total IPv6 Remote Rts
: 0
Total IPv6 Rem. Active Rts : 0
Total Supressed Rts
: 0
Total Hist. Rts
: 0
Total Decay Rts
: 0
===============================================================================
BGP Summary
===============================================================================
Neighbor
AS PktRcvd InQ Up/Down
State|Rcv/Act/Sent (Addr Family)
PktSent OutQ
------------------------------------------------------------------------------172.16.2.2
64498
28695
0 05d23h53m 2/0/3 (IPv4)
28671
0
172.16.3.2
64498
28618
0 06d00h03m 2/0/3 (IPv4)
28611
0
------------------------------------------------------------------------------A:PE-1#

The received routes are not inserted in the FIB since they are already known as local routes.

Page 198

Advanced Configuration Guide

BGP Anycast

Verify Anycast Labels


On PE-2, first check the BGP service label that has been advertised by PE-3 as follows.
A:PE-2# show router bgp routes vpn-ipv4 1:3:172.168.1.1/32
===============================================================================
BGP Router ID:192.0.2.2
AS:64496
Local AS:64496
===============================================================================
Legend Status codes : u - used, s - suppressed, h - history, d - decayed, * - valid
Origin codes : i - IGP, e - EGP, ? - incomplete, > - best
===============================================================================
BGP VPN-IPv4 Routes
===============================================================================
Network
: 172.168.1.1/32
Nexthop
: 10.30.0.1
Route Dist.
: 1:3
VPN Label
: 262130
From
: 192.0.2.4
Res. Nexthop
: n/a
Local Pref.
: 150
Interface Name : slaveAnycast
Aggregator AS : None
Aggregator
: None
Atomic Aggr.
: Not Atomic
MED
: None
Community
: target:1:1
Cluster
: 1.1.1.1
Originator Id : 192.0.2.3
Peer Router Id : 192.0.2.4
Flags
: Invalid Incomplete (*)
AS-Path
: 64499
VPRN Imported : None
------------------------------------------------------------------------------Routes : 1

(*) This means that the NH is resolved to its own local interface. Nevertheless, the service label
will be inserted in the context-specific label space so that incoming packets with this service label
can be linked to VPRN 1.
Notice the loopback route of the CE with label 262130, which is the BGP label that represents
VPRN 1 at PE-3.
A:PE-2# show router bgp anycast-label
===============================================================================
BGP Anycast-MH labels
===============================================================================
Secondary-MH-Addr
ABR-Lbl
Cfg-Time VPRN-ID
PE-Addr
PE-Lbl
Rem-Time Ref-Count
------------------------------------------------------------------------------10.30.0.1
262130
30
1
3
===============================================================================
A:PE-2#

PE-3 will forward the traffic received with BGP service label 262130 towards VPRN 1 where an
egress IP lookup will be performed. In the VRF (FIB of VPRN-id 1) at PE-2, a route toward
172.168.1.1/32 with VPRN 1 at PE-1 as an NH is found.

Advanced Configuration Guide

Page 199

Configuration

A:PE-2# show router 1 route-table


===============================================================================
Route Table (Service: 1)
===============================================================================
Dest Prefix
Type
Proto
Age
Pref
Next Hop[Interface Name]
Metric
------------------------------------------------------------------------------172.16.2.0/30
Local
Local
06d00h35m
0
to_CE
0
172.16.3.0/30
Remote BGP
05h01m41s
170
172.16.2.1
0
172.168.1.1/32
Remote BGP
06d00h35m
170
172.16.2.1
0
------------------------------------------------------------------------------No. of Routes: 3
===============================================================================
A:PE-2#

Page 200

Advanced Configuration Guide

BGP Anycast

Verify Data Path Between VPRN on PE-6 and the CE


At PE-6, a ping and traceroute are performed towards the loopback interface of the CE (VPRN-id
1 at PE-1) with the following results.
A:PE-6# ping router 1 172.168.1.1 source 172.16.6.6
PING 172.168.1.1 56 data bytes
64 bytes from 172.168.1.1: icmp_seq=1 ttl=63 time=3.79ms.
^C
ping aborted by user
---- 172.168.1.1 PING Statistics ---1 packet transmitted, 1 packet received, 0.00% packet loss
round-trip min = 3.79ms, avg = 3.79ms, max = 3.79ms, stddev = 0.000ms
A:PE-6# traceroute no-dns router 1 172.168.1.1 source 172.16.6.6
traceroute to 172.168.1.1 from 172.16.6.6, 30 hops max, 40 byte packets
1 0.0.0.0 * * *
2 172.168.1.1
4.62 ms 8.05 ms 4.28 ms
A:PE-6#

Upstream
From PE-6, the NH of the IP-VPN route will be the anycast address (in this case 10.30.0.1) which
will be reachable through an LDP tunnel.
A:PE-6# show router 1 route-table
===============================================================================
Route Table (Service: 1)
===============================================================================
Dest Prefix
Type
Proto
Age
Pref
Next Hop[Interface Name]
Metric
------------------------------------------------------------------------------172.16.2.0/30
Remote BGP VPN 16h21m20s
170
10.20.0.1 (tunneled)
0
172.16.3.0/30
Remote BGP VPN 16h21m20s
170
10.30.0.1 (tunneled)
0
172.16.6.6/32
Local
Local
10d21h52m
0
lo1
0
172.168.1.1/32
Remote BGP VPN 16h21m20s
170
10.30.0.1 (tunneled)
0
------------------------------------------------------------------------------No. of Routes: 4
===============================================================================
A:PE-6# show router 1 fib 1
===============================================================================
FIB Display
===============================================================================
Prefix
Protocol
NextHop
------------------------------------------------------------------------------172.16.2.0/30
BGP_VPN
10.20.0.1 (VPRN Label:262133 Transport:LDP)
172.16.3.0/30
BGP_VPN
10.30.0.1 (VPRN Label:262130 Transport:LDP)
172.16.6.6/32
LOCAL

Advanced Configuration Guide

Page 201

Configuration

172.16.6.6 (lo1)
172.168.1.1/32
BGP_VPN
10.30.0.1 (VPRN Label:262130 Transport:LDP)
------------------------------------------------------------------------------Total Entries : 4
------------------------------------------------------------------------------===============================================================================
A:PE-6#

A:PE-6# show router ldp bindings prefix 10.30.0.1/32


===============================================================================
LDP LSR ID: 192.0.2.6
===============================================================================
Legend: U - Label In Use, N - Label Not In Use, W - Label Withdrawn
WP - Label Withdraw Pending
===============================================================================
LDP Prefix Bindings
===============================================================================
Prefix
Peer
IngLbl
EgrLbl EgrIntf
EgrNextHop
------------------------------------------------------------------------------10.30.0.1/32
192.0.2.4
262135U
262139
--10.30.0.1/32
192.0.2.5
262135N
262134 1/1/3:0
192.168.25.1
------------------------------------------------------------------------------No. of Prefix Bindings: 2
===============================================================================
A:PE-6#

Downstream
First, verify which PE is selected by the CE to reach the 172.16.6.6/32 (in VPN 1 at PE-6);
A:PE-1# show router 1 route-table
===============================================================================
Route Table (Service: 1)
===============================================================================
Dest Prefix
Type
Proto
Age
Pref
Next Hop[Interface Name]
Metric
------------------------------------------------------------------------------172.16.2.0/30
Local
Local
10d16h54m
0
to_ABR_PE2
0
172.16.3.0/30
Local
Local
10d16h53m
0
to_ABR_PE3
0
172.16.6.6/32
Remote BGP
00h54m07s
170
172.16.2.2
0
172.168.1.1/32
Local
Local
10d16h52m
0
lo1
0
------------------------------------------------------------------------------No. of Routes: 4
===============================================================================
A:PE-1#

In this case, PE-2 is selected as the NH.


At PE-2, the path towards PE-6 is based upon a BGP tunnel with the BGP anycast feature.

Page 202

Advanced Configuration Guide

BGP Anycast

A:PE-2# show router 1 route-table


===============================================================================
Route Table (Service: 1)
===============================================================================
Dest Prefix
Type
Proto
Age
Pref
Next Hop[Interface Name]
Metric
------------------------------------------------------------------------------172.16.2.0/30
Local
Local
06d16h45m
0
to_CE
0
172.16.3.0/30
Remote BGP
21h12m08s
170
172.16.2.1
0
172.16.6.6/32
Remote BGP VPN 00h08m18s
170
192.168.0.6 (tunneled)
0
172.168.1.1/32
Remote BGP
06d16h45m
170
172.16.2.1
0
------------------------------------------------------------------------------No. of Routes: 4
===============================================================================
A:PE-2#
A:PE-2# show router 1 fib 1
===============================================================================
FIB Display
===============================================================================
Prefix
Protocol
NextHop
------------------------------------------------------------------------------172.16.2.0/30
LOCAL
172.16.2.0 (to_CE)
172.16.3.0/30
BGP
172.16.2.1 Indirect (to_CE)
172.16.6.6/32
BGP_VPN
192.168.0.6 (VPRN Label:262134 Transport:BGP)
172.168.1.1/32
BGP
172.16.2.1 Indirect (to_CE)
------------------------------------------------------------------------------Total Entries : 4
------------------------------------------------------------------------------===============================================================================
A:PE-2#
A:PE-2# show router tunnel-table
===============================================================================
Tunnel Table (Router: Base)
===============================================================================
Destination
Owner Encap TunnelId Pref
Nexthop
Metric
------------------------------------------------------------------------------10.40.0.1/32
ldp
MPLS
9
192.168.4.2
20
10.50.0.1/32
ldp
MPLS
9
192.168.13.2
30
192.0.2.1/32
ldp
MPLS
9
192.168.2.1
10
192.0.2.3/32
ldp
MPLS
9
192.168.2.1
20
192.0.2.4/32
ldp
MPLS
9
192.168.4.2
10
192.0.2.5/32
ldp
MPLS
9
192.168.13.2
20
192.0.2.6/32
bgp
MPLS
10
10.40.0.1
1000
192.168.0.6/32
bgp
MPLS
10
10.40.0.1
1000
===============================================================================
A:PE-2#

The end-to-end label stack for the ping will look like the following (in this particular case);

Advanced Configuration Guide

Page 203

Configuration

PE-2
ABR
192.0.2.2

L2 Area

PE-4
ABR
192.0.2.4
PING Towards Loopback
Interface of CE
(Data Path Can Vary)

L1 Area
49.0002

PE-1
192.0.2.1

.1

192.168.0.0/30

PE-3
ABR
192.0.2.3

PE-6
192.0.2.6

.2

PE-5
ABR
192.0.2.5

IP
L2

IP
VPN-LBL
LDP-LBL
L2

IP
L2

IP
VPN-LBL
BGP-LBL
LDP-LBL
L2

Upstream:

Swap

IP
VPN-LBL
LDP-LBL
L2

Downstream:

Swap
Swap

IP
VPN-LBL
BGP-LBL
LDP-LBL
L2

E2E BGP Service Label


LDP Label Towards Anycast NH of PE-3,
Swapped at PE-5 (Acting as Regular
LSR)

E2E BGP Service Label


BGP Label to Reach 192.168.0.6
on PE-6
LDP Label Towards Anycast NH of PE-4,
Swapped with LDP Label Towards
System-ip of PE-6
OSSG614

Figure 39: IP-VPN with Anycast NH, Data Path

Notice that the data path is not symmetric. By modifying BGP attributes, the path can be
influenced so that the upstream and downstream directions follow the same path, but this is out-ofscope for this document.

Page 204

Advanced Configuration Guide

BGP Anycast

Conclusion
BGP anycast provides an end-to-end MPLS reach ability in large MPLS domains, where a single
IGP area cannot be deployed or even when a single IGP is not sufficient.
The feature provides a transport layer which can be used for any kind of service on the 7750 SR.
On top of that, BGP anycast can also be used to advertise redundant IP-VPN routes into large
MPLS domains. In this case, BGP anycast is not offering a redundant transport layer, but
redundancy at the service layer.
The (context-specific label-switching) mechanism where a neighboring anycast ABR will install
advertised labels from its anycast neighbor in the LFIB contributes to a fast convergence after
nodal or link failures.

Advanced Configuration Guide

Page 205

Conclusion

Page 206

Advanced Configuration Guide

BGP Multi-Homing for VPLS Networks

In This Chapter
This section describes BGP Multi-Homing (BGP-MH) for VPLS network configurations.
Topics in this section include:

Applicability on page 208

Summary on page 209

Overview on page 211

Configuration on page 213

Conclusion on page 243

Advanced Configuration Guide

Page 207

Applicability

Applicability
This section is applicable to all of the 7750 SR series (SR-7, SR-12, SR-c4 and SR-c12), 7710 SR,
as well as 7450 ESS (ESS-7 and ESS-12) series in mixed mode. It was tested on release 9.0R1.

Page 208

Advanced Configuration Guide

BGP Multi-Homing for VPLS Networks

Summary
Beginning with SR OS 8.0R1, the SR/ESS portfolio supports the use of Border Gateway Protocol
Multi-Homing for VPLS (hereafter called BGP-MH). BGP-MH is described in draft-ietf-l2vpnvpls-multihoming, BGP based Multi-homing in Virtual Private LAN Service, and provides a
network-based resiliency mechanism (no interaction from the PEs Provider Edge router to
MTU/CEs Multi-tenant Unit/Customer Equipment) that can be applied on access Service Access
Points (SAPs) or network (pseudowires) topologies. The BGP-MH procedures will run between
the PEs and will provide a loop-free topology from the network perspective (only one logical
active path will be provided per VPLS among all the objects SAPs or pseudowires which are part
of the same Multi-Homing site).
Each multi-homing site connected to two or more peers is represented by a site-id (2-bytes long)
which is encoded in the BGP MH Network Layer Reachability Information (NLRI). The BGP
peer holding the active path for a particular multi-homing site will be named as the Designated
Forwarder (DF), whereas the rest of the BGP peers participating in the BGP MH process for that
site will be named as non-DF and will block the traffic (in both directions) for all the objects
belonging to that multi-homing site.
In SR OS 8.0, BGP MH uses the following rules to determine which PE is the DF for a particular
multi-homing site:
1. A BGP MH NLRI with D flag = 0 (multi-homing object up) always takes precedence over a
BGP MH NLRI with D flag = 1 (multi-homing object down). If there is a tie, then:
2. The BGP MH NLRI with the highest BGP LP (Local Preference) wins. If there is a tie, then:
3. The BGP MH NLRI issued from the PE with the lowest PE ID (system address) wins.
The main advantages of using BGP-MH as opposed to other resiliency mechanisms for VPLS are:

Flexibility: BGP-MH uses a common mechanism for access and core resiliency. The
designer has the flexibility of using BGP-MH to control the active/standby status of SAPs,
spoke SDPs, Split Horizon Groups (SHGs) or even mesh SDP bindings.

The standard protocol is based on BGP, a standard, scalable and well-known protocol.

Specific benefits at the access:


It is network-based, independent of the customer CE and, as such, it does not need any
customer interaction to determine the active path. Consequently the operator will
spend less effort on provisioning and will minimize both operation costs and security
risks (in particular, this removes the requirement for spanning tree interaction between
the PE and CE).
Easy load balancing per service (no service fate-sharing) on physical links.

Advanced Configuration Guide

Page 209

Summary

Specific benefits in the core:


It is a network-based mechanism, independent of the MTU resiliency capabilities and
it does not need MTU interaction, therefore operational advantages are achieved as a
result of the use of BGP-MH: less provisioning is required and there will be minimal
risks of loops. In addition, simpler MTUs can be used.
Easy load balancing per service (no service fate-sharing) on physical links.
Less control plane overhead: there is no need for an additional protocol running the
pseudowire redundancy when BGP is already used in the core of the network. BGPMH just adds a separate NLRI in the L2-VPN family (AFI=25, SAFI=65).

The objective of this section is to provide the required guidelines to configure and troubleshoot
BGP-MH for VPLS based on SR OS 8.0R5.
Knowledge of the LDP/BGP VPLS (RFC 4762, Virtual Private LAN Service (VPLS) Using Label
Distribution Protocol (LDP) Signaling, and RFC 4761, Virtual Private LAN Service (VPLS) Using
BGP for Auto-Discovery and Signaling) architecture and functionality is assumed throughout this
document. For further information refer to the relevant Alcatel-Lucent documentation.

Page 210

Advanced Configuration Guide

BGP Multi-Homing for VPLS Networks

Overview
The following network setup will be used throughout the rest of the section.
Note:

IGP ISIS, Level 2 on all routers; area 49.0001

RSVP-TE for transport tunnels

FRR in the core

No protection at the access.

CE-1
10.50.50.1

192.0.2.1

192.0.2.11
1/1/4:500
1/1/3:500

CE-2 1/1/4:500
10.50.50.2

500

500
192.0.2.3

MTU-1
MH site-1

1/1/4:500

PE-1
500

MH site-2

192.0.2.21

192.0.2.2

500

500

CE-3
192.0.2.31
10.50.50.3
1/1/2:503
500
MTU-3

PE-3

MTU-2

1/1/2:504
CE-4
10.50.50.4

PE-2
LDP VPLS

BGP VPLS

LDP VPLS
OSSG600

Figure 40: Network Topology

The setup consists of a three core 7x50 SR/ESS (PE-1, PE-2 and PE-3) and three Multi-Tenant
Unit (MTU) nodes connected to the core. The MTU nodes can also be 7x50 service routers. All
the nodes are running SR OS 8.0R5.
The VPLS service 500 is configured on all the six nodes with the following characteristics:

The core VPLS instances are connected by a full mesh of BGP-signalled pseudowires
(that is, pseudowires among PE-1, PE-2 and PE-3 will be signalled by BGP VPLS).

As depicted in the Figure 40, the MTUs are connected to the BGP VPLS core by TLDP
pseudowires. While MTU-3 is connected to PE-3 by a single pseudowire, MTU-1 and

Advanced Configuration Guide

Page 211

Overview

MTU-2 are dual-homed to PE-1 and PE-2. The following resiliency mechanisms are used
on the dual-homed MTUs:
MTU-1 is dual-connected to PE-1 and PE-2 by an active/standby pseudowire (A/S
pseudowire hereafter).
MTU-2 is dual-connected to PE-1 and PE-2 by two active pseudowires, being one of
them blocked by BGP MH running between PE-1 and PE-2. The PE-1 and PE-2
pseudowires, set up from MTU-2, will be part of the BGP MH site MH-site-2.
MTU-1 and MTU-2 are running BGP MH, being SHG site-1 and sap 1/1/4:500 on
MTU-2 part of the same BGP MH site, MH-site-1.

The CEs are connected to the network in the following way:


CE-1, CE-3 and CE-4 are single-connected to the network
CE-2 is dual connected to MTU-1 and MTU-2.
CE-1 and CE-2 are part of the split-horizon-group (SHG) site-1(saps 1/1/4:500 and 1/
1/3:500 on MTU-1). Assume that CE-1 and CE-2 have a backdoor link between them
so that when MTU-2 is elected as DF, CE1 does not get isolated. This configuration
high-lights the use of a SHG within a site configuration.

For each BGP MH site, MH-site-1 and MH-site-2, the BGP MH process will elect a DF, blocking
the site objects for the non-DF nodes. In other words, based on the specific configuration
explained throughout the section:

Page 212

For MH-site-1, MTU-1 will be elected as the DF. The non-DF-MTU-2 will block the sap
1/1/4:500.

For MH-site-2, PE-1 will be elected as the DF. The non-DF PE-1 will block the spokeSDP to MTU-2.

Advanced Configuration Guide

BGP Multi-Homing for VPLS Networks

Configuration
This section describes all the relevant configuration tasks for the setup shown in figure 1. Note
that the appropriate associated IP/MPLS configuration is out of the scope of this section. In this
particular example the following protocols will be configured beforehand:

ISIS-TE as IGP with all the interfaces being level-2 (OSPF-TE could have been used
instead).

RSVP-TE as the MPLS protocol to signal the transport tunnels (LDP could have been
used instead, but without Fast Re-Route).

LSPs between core PEs will be Fast Re-Route protected (facility bypass tunnels) whereas
LSP tunnels between MTUs and PEs will not be protected1.

Once the IP/MPLS infrastructure is up and running, the specific service configuration including
the support for BGP MH can begin.

Global BGP Configuration


BGP is used in this configuration guide for these purposes:
a. Auto-discovery and signalling of the pseudowires in the core, as per RFC 4761.
b. Exchange of multi-homing site NLRIs and redundancy handling from MTU-2 to the core.
c. Exchange of multi-homing site NLRIs and redundancy handling at the access for CE-1/

CE-2.
A BGP route reflector (RR), PE-3, is used for the reflection of BGP updates corresponding to the
above uses a and b.
A direct peering is established between MTU-1 and MTU-2 for use c. Note that the same RR
could have been used for the three cases, however, like in this example, the designer may choose
to have a direct BGP peering between access devices. The reasons for this are:

By having a direct BGP peering between MTU-1 and MTU-2, the BGP updates do not
have to travel back and forth.

1. Note that the designer can choose whether to protect access link failures by means of
MPLS FRR or A/S pseudowire or BGP MH. While FRR provides a faster convergence
(around 50ms) and stability (it does not impact on the service layer, hence, link failures do
not trigger MAC flush and flooding) some interim inefficiencies can be introduced compared to A/S pseudowire or BGP MH.

Advanced Configuration Guide

Page 213

Configuration

On MTU-1 and MTU-2, BGP is exclusively used for multi-homing, therefore there will
not be more BGP peers for either MTUs and a RR adds nothing in terms of control plane
scalability.

As an example, the following CLI output shows the global BGP configuration required on MTU1. Note that the 192.0.2.21 address will be replaced by the corresponding peer or the RR system
address for PE-1 and PE-2.
A:MTU-1>config>router# info
---------------------------------------------...
autonomous-system 65000
router-id 192.0.2.11
...
bgp
rapid-withdrawal
rapid-update l2-vpn
family l2-vpn
group "Multi-homing"
neighbor 192.0.2.21
type internal
peer-as 65000
exit
exit
exit

In this example, PE-3 is the BGP RR, therefore its BGP configuration will contain a cluster with
all its peers included (PE-1 and PE-2):
A:PE-3>config>router# info
---------------------------------------------...
bgp
rapid-withdrawal
rapid-update l2-vpn
family l2-vpn
group "internal"
cluster 1.1.1.1
neighbor 192.0.2.1
type internal
peer-as 65000
exit
neighbor 192.0.2.2
type internal
peer-as 65000
exit
exit
exit
...

Page 214

Advanced Configuration Guide

BGP Multi-Homing for VPLS Networks

The relevant BGP commands for BGP-MH are in bold. Some considerations about those:

It is required to specify family l2-vpn in the BGP configuration. That statement will allow
the BGP peers to agree on the support for the family AFI=25 (Layer 2 VPN), SAFI=65
(VPLS). This family is used for BGP VPLS as well as for BGP MH and BGP AD.

The rapid-update l2-vpn statement allows BGP MH to send BGP updates immediately
after detecting link failures, without having to wait for the MRAI to send the updates in
batches. This statement is required to guarantee a fast convergence for BGP MH.

Optionally, rapid-withdrawal can also be added. Note that, in the context of BGP MH, this
command is only useful if a particular multi-homing site is cleared2. In that case, a BGP
withdrawal is sent immediately without having to wait for the MRAI.

2. This means removing the BGP-MH site or even to remove the whole VPLS service.

Advanced Configuration Guide

Page 215

Configuration

Service Level Configuration


Once the IP/MPLS infrastructure is configured, including BGP, this section shows the
configuration required at service level (VPLS 500). The focus is on the nodes involved on BGP
MH, that is, MTU-1, MTU-2, PE-1 and PE-2. These nodes are highlighted in Figure 41.

CE-1

192.0.2.1

192.0.2.11

10.50.50.1
1/1/4:500

500

1/1/3:500

CE-2

500
192.0.2.3

MTU-1

1/1/4:500

PE-1

10.50.50.2
MH site-1

MH site-2

CE-3
192.0.2.31

500

500

PE-3

MTU-3

10.50.50.3
1/1/2:503

1/1/2:504
192.0.2.2

192.0.2.21

CE-4
10.50.50.4

1/1/4:500

500

500

MTU-2

PE-2

LDP VPLS

BGP VPLS

LDP VPLS
OSSG640

Figure 41: Nodes Involved in BGP MH

Page 216

Advanced Configuration Guide

BGP Multi-Homing for VPLS Networks

Core PE Service Configuration


The following CLI excerpt shows the service level configuration on PE-1.
A:PE-1>config>service# info
---------------------------------------------...
sdp 111 mpls create
far-end 192.0.2.11
lsp "LSP-PE-1-MTU-1"
path-mtu 8000
keep-alive
shutdown
exit
no shutdown
exit
sdp 121 mpls create
far-end 192.0.2.21
lsp "LSP-PE-1-MTU-2"
path-mtu 8000
keep-alive
shutdown
exit
no shutdown
exit
sdp 1212 mpls create
far-end 192.0.2.2
lsp "LSP-PE-1-PE-2"
signaling bgp # this sdp will transport BGP-signaled pseudowires
path-mtu 8000
keep-alive
shutdown
exit
no shutdown
exit
sdp 1313 mpls create
far-end 192.0.2.3
lsp LSP-PE-1-PE-3
signaling bgp # this sdp will transport BGP-signaled pseudowires
path-mtu 8000
keep-alive
shutdown
exit
no shutdown
exit
...
pw-template 500 use-provisioned-sdp create
exit
...
vpls 500 customer 1 create
split-horizon-group "CORE" create
exit
bgp # BGP context with common parameters for BGP VPLS and BGP MH
route-distinguisher 65000:501
vsi-export "vsi500_export"
vsi-import "vsi500_import"
pw-template-bind 500 split-horizon-group "CORE"

Advanced Configuration Guide

Page 217

Configuration

exit
bgp-vpls # Specific context for BGP VPLS configuration
max-ve-id 65535
ve-name 501
ve-id 501
exit
no shutdown
exit
stp
shutdown
exit
site "MH-site-2" create # BGP MH specific configuration
site-id 2
spoke-sdp 121:500
no shutdown
exit
spoke-sdp 111:500 create
exit
spoke-sdp 121:500 create
exit
no shutdown
exit

Page 218

Advanced Configuration Guide

BGP Multi-Homing for VPLS Networks

The following are general comments about the configuration of service 500:

As it can be seen in the CLI output above for PE-1, there are four provisioned SDPs that
the service VPLS 500 will use in this example. SDP 111 and SDP 121 are tunnels over
which the TLDP FEC128 pseudowires for service 500 will be carried (according to RFC
4762), whereas SDP 1212 and SDP 1313 are the tunnels for the core BGP pseudowires
(based on RFC 4761).

The BGP context provides the general service BGP configuration that will be used by
BGP VPLS and BGP MH:
Route distinguisher (notation chosen is based on <AS_number:500 + node_id>)
VSI export policies are used to add the export route-targets included in all the BGP
updates sent to the BGP peers.
VSI import policies are used to control the NLRIs accepted in the RIB, normally
based on the route-targets.
Both, VSI-export and VSI-import policies can be used to modify attributes like the
Local-Preference (LP) that will be used to influence the BGP MH Designated
Forwarder (DF) election (LP is the second rule in the BGP MH election process, as
previously discussed). The use of these policies will be described later in the section.
The pw-template-bind command maps the previously defined pw-template 500 to
the split-horizon-group CORE. In this way, all the BGP-signalled pseudowires will
be part of this split-horizon-group. Although not shown in this example, the pwtemplate-bind command can also be used to instantiate pseudowires within different
split-horizon-groups, based on different import route-targets3:

A:PE-1# configure service vpls 1 bgp pw-template-bind ?


- pw-template-bind <policy-id> [split-horizon-group <group-name>] [import-rt {extcommunity, ...(upto 5 max)}]
- no pw-template-bind <policy-id>

The BGP-signalled pseudowires (from PE-1 to PE-2 and PE-3) are set up according to the
configuration in the BGP context. Beside those pseudowires, the VPLS 500 also has two
more pseudowires signalled by TLDP: spoke-sdp 111:500 (to MTU-1) and spoke-sdp
121:500 (to MTU-2).

3. Detailed BGP-VPLS configuration is out of the scope of this configuration guide. For more information please, refer to the Alcatel-Lucent SR OS documentation.

Advanced Configuration Guide

Page 219

Configuration

The general BGP MH configuration parameters for a particular multi-homing site are show in the
following output:
*A:PE1> vpls <service-id> [customer <customer-id>][vpn <vpn-id>][m-vpls][b-vpls]
[no] site <site-name> [create] # 32 characters maximum
[no] site-id <site-id-value> # Range: 1..65535
[no]
[no]
[no]
[no]

spoke-sdp sdp-id[:vc-id]
sap <sap-id>
split-horizon-group <group-name>
mesh-sdp-binding

[no] failed-threshold <value|all> # Range:1-1000. Default: all


[no] boot-timer <interval> # Range:0-600. Default: 10
[no] site-activation-timer <interval> # Range:0-100. Default: 2
[no] shutdown

Where:

The site-name is defined by a string with less or equal to 32 characters.

The site-id is an integer that identifies the multi-homing site and is encoded in the BGP
MH NLRI. This ID must be the same one used on the peer node where the same multihoming site is connected to. That is, MH-site-2 must use the same site-id in PE-1 and PE2 (value = 2 in the PE-1 site configuration).

Out of the four potential objects in a site, spoke SDP, SAP, SHG and mesh SDP binding
only one can be used at the time on a particular site. To add more than just one sap/spokesdp to the same site, a split-horizon-group composed of the sap/spoke-sdp objects must be
used in the site configuration. Otherwise, only one object (spoke SDP, SAP, SHG and
mesh SDP binding) is allowed per site. A CLI log message warns the operator of such
fact:

A:PE-1>config>service>vpls>site# mesh-sdp-binding
MINOR: SVCMGR #5855 only one object is allowed per site

Page 220

The failed-threshold command defines how many objects should be down for the site to
be declared down. This command is obviously only valid for multi-object sites (splithorizon-groups and mesh-sdp-bindings). By default, all the objects in a site must be down
for the site to be declared as operationally down.

The boot-timer specifies for how long the service manager waits after a node reboot
before running the MH Procedures. The boot-timer value should be configured to allow
for the BGP sessions to come up and for the NLRI information to be refreshed/exchanged.
In environments with the default BGP MRAI (30 seconds) it is highly recommended to
increase this value (for instance, 120 seconds for a normal configuration). The boot-timer
is only important when a node comes back up and would become the DF.

Advanced Configuration Guide

BGP Multi-Homing for VPLS Networks

The site-activation-timer command defines the amount of time the service manager will
keep the local objects in standby (in the absence of BGP updates from remote PEs) before
running the DF election algorithm to decide whether the site should be unblocked. The
timer is started when one of the following events occurs only if the site is operationally
up:
Manual site activation using the no shutdown command at the site-id level or at
member object(s) level (SAP(s) or pseudowire(s))
Site activation after a failure

The BGP MH election procedures will be resumed upon expiration of this timer or the arrival of a
BGP MH update for the multi-homing site.

The boot-timer and site-activation-timer commands can be provisioned at service level


or at global level. The service level settings have precedence and override the global
configuration. The no form of the commands at global level, sets the value back to the
default values, (10 and 2 seconds, respectively). The no form of the commands at service
level, makes the timers inherit the global values.

*A:PE-1# configure redundancy bgp-multi-homing


- bgp-multi-homing
[no] boot-timer
- Configure BGP multi-homing boot-timer
[no] site-activatio* - Configure BGP multi-homing site activation timer

The shutdown command controls the ADMIN state of the site. Note that each site has
three possible states:
ADMIN state controlled by the shutdown command.
OPERATIONAL state controlled by the operational status of the individual site
objects.
DESIGNATED-FORWARDER (DF) state controlled by the BGP MH election
algorithm.

The following CLI output shows the three states for a BGP MH site:
*A:MTU-2# show service id 500 site "MH-site-1"
===============================================================================
Site Information
===============================================================================
Site Name
: MH-site-1
------------------------------------------------------------------------------Site Id
: 1
Dest
: sap:1/1/4:500
Mesh-SDP Bind
: no
Admin Status
: Enabled
Oper Status
: up
Designated Fwdr
: No
DF UpTime
: 0d 00:00:00 secs
DF Chg Cnt
: 1
Failed Threshold
: default(all)
===============================================================================

Advanced Configuration Guide

Page 221

Configuration

For this example, configure the site MH-site-2 in PE-1, where the site-id is 2 and the object in the
site is spoke-sdp 121:500 (pseudowire established from PE-1 to MTU-2).
The following CLI output shows the service configuration for PE-2. Note that the site-id is 2, that
is, the same value configured in PE-1. The object defined in PE-2s site is spoke-sdp 221:500
(pseudowire established from PE-2 to MTU-2).
A:PE-2>config>service# info
---------------------------------------------...
sdp 211 mpls create
far-end 192.0.2.11
lsp "LSP-PE-2-MTU-1"
path-mtu 8000
keep-alive
shutdown
exit
no shutdown
exit
sdp 221 mpls create
far-end 192.0.2.21
lsp "LSP-PE-2-MTU-2"
path-mtu 8000
keep-alive
shutdown
exit
no shutdown
exit
sdp 2121 mpls create
far-end 192.0.2.1
lsp "LSP-PE-2-PE-1"
signaling bgp # this sdp will transport BGP-signaled pseudowires
path-mtu 8000
keep-alive
shutdown
exit
no shutdown
exit
sdp 2323 mpls create
far-end 192.0.2.3
lsp "LSP-PE-2-PE-3"
signaling bgp # this sdp will transport BGP-signaled pseudowires
path-mtu 8000
keep-alive
shutdown
exit
no shutdown
exit
...
pw-template 500 use-provisioned-sdp create
exit
...
vpls 500 customer 1 create
split-horizon-group "CORE" create
exit
bgp

Page 222

Advanced Configuration Guide

BGP Multi-Homing for VPLS Networks

route-distinguisher 65000:502
vsi-export "vsi500_export"
vsi-import "vsi500_import"
pw-template-bind 500 split-horizon-group "CORE"
exit
bgp-vpls
max-ve-id 65535
ve-name 502
ve-id 502
exit
no shutdown
exit
stp
shutdown
exit
site "MH-site-2" create
site-id 2
spoke-sdp 221:500
no shutdown
exit
spoke-sdp 211:500 create
exit
spoke-sdp 221:500 create
exit
no shutdown
exit
...

Advanced Configuration Guide

Page 223

Configuration

MTU Service Configuration


The following CLI output shows the service level configuration on MTU-1.
A:MTU-1>config>service# info
...
sdp 111 mpls create
far-end 192.0.2.1
lsp "LSP-MTU-1-PE-1"
path-mtu 8000
keep-alive
shutdown
exit
no shutdown
exit
sdp 112 mpls create
far-end 192.0.2.2
lsp "LSP-MTU-1-PE-2"
path-mtu 8000
keep-alive
shutdown
exit
no shutdown
exit
...
vpls 500 customer 1 create
split-horizon-group "site-1" create
exit
bgp
route-distinguisher 65000:511
route-target export target:65000:500 import target:65000:500
exit
stp
shutdown
exit
site "MH-site-1" create
site-id 1
split-horizon-group site-1
no shutdown
exit
endpoint "CORE" create
no suppress-standby-signaling
exit
sap 1/1/3:500 split-horizon-group "site-1" create
eth-cfm
mep 511 domain 1 association 1 direction down
fault-propagation-enable use-if-tlv
ccm-enable
no shutdown
exit
exit
exit
sap 1/1/4:500 split-horizon-group "site-1" create
exit
spoke-sdp 111:500 endpoint "CORE" create
stp

Page 224

Advanced Configuration Guide

BGP Multi-Homing for VPLS Networks

shutdown
exit
precedence primary
exit
spoke-sdp 112:500 endpoint "CORE" create
stp
shutdown
exit
exit
no shutdown
exit

The MTU-1 node is configured with the following characteristics:

The BGP context provides the general BGP parameters for service 500 in MTU-1. Note
that the route-target command is now used instead of the vsi-import and vsi-export
commands. The intend in this example is to configure only the export and import routetargets, and do not need to modify any other attribute. If the local preference are modified
(to influence the DF election), a vsi-policy must be configured.

An A/S pseudowire configuration is used to control the pseudowire redundancy towards


the core.

The multi-homing site, MH-site-1 has a site-id = 1 and a split-horizon-group as an object.


The split-horizon-group site-1 is composed of sap 1/1/3:500 and sap 1/1/4:500. As
previously discussed, the site will not be declared operationally down until the two SAPs
belonging to the site are down. This behavior can be changed by the failed-threshold
command (for instance, in order to bring the site down when only one object has failed
even though the second sap is still up).

Note that, as an example, a Y.1731 MEP with fault-propagation has been defined in sap 1/
1/3:500. As discussed later in the section, this MEP will signal the status of the SAP (as a
result of the BGP MH process) to CE-2.

Advanced Configuration Guide

Page 225

Configuration

The service configuration in MTU-2 is shown below.


A:MTU-2>config>service# info
...
sdp 211 mpls create
far-end 192.0.2.1
lsp "LSP-MTU-2-PE-1"
path-mtu 8000
keep-alive
shutdown
exit
no shutdown
exit
sdp 212 mpls create
far-end 192.0.2.2
lsp "LSP-MTU-2-PE-2"
path-mtu 8000
keep-alive
shutdown
exit
no shutdown
exit
...
vpls 500 customer 1 create
bgp
route-distinguisher 65000:521
route-target export target:65000:500 import target:65000:500
exit
stp
shutdown
exit
site "MH-site-1" create
site-id 1
sap 1/1/4:500
no shutdown
exit
sap 1/1/4:500 create
exit
spoke-sdp 211:500 create
exit
spoke-sdp 212:500 create
exit
no shutdown
exit

Page 226

Advanced Configuration Guide

BGP Multi-Homing for VPLS Networks

Influencing the Designated Forwarder (DF) Decision


As previously explained, assuming that the sites on the two nodes taking part of the same multihoming site are both up, the two tie-breakers for electing the DF are (in this order):
1. Highest LP
2. Lowest PE ID
The LP by default is 100 in all the routers. Under normal circumstances, if the LP in any router is
not changed, MTU-1 will be elected the DF for MH-site-1, whereas PE-1 will be the DF for MHsite-2. Assume in this section that this behavior is changed for MH-site-2 to make PE-2 the DF.
Since changing the system address (to make PE-2s ID the lower of the two IDs) is usually not an
easy task to accomplish, a vsi-export policy in PE-2 is added to modify the LP with which the
MH-site-2 NLRI is announced to PE-1. That policy will change the LP to 150 and as such, since
150 is greater than the default 100 in PE-1, PE-2 will be elected as the DF for MH-site-2. The
configuration of the policy is outlined below:
A:PE-2# admin display-config
...
#-------------------------------------------------echo "Service Configuration"
#-------------------------------------------------...
vpls 500 customer 1 create
...
bgp
route-distinguisher 65000:502
vsi-export "vsi500_export"
vsi-import "vsi500_import"
...
#-------------------------------------------------echo "Policy Configuration"
#-------------------------------------------------policy-options
begin
community "comm_core" members "target:65000:500"
policy-statement "vsi500_export"
entry 10
action accept
community add "comm_core"
local-preference 150
exit
exit
exit
policy-statement "vsi500_import"
entry 10
from
community "comm_core"
exit
action accept
exit
exit

Advanced Configuration Guide

Page 227

Configuration

default-action reject
exit

In PE-1, simply import and export the same route-target without modifying the LP. The
configuration is show below.
A:PE-1# admin display-config
...
#-------------------------------------------------echo "Service Configuration"
#-------------------------------------------------...
vpls 500 customer 1 create
...
bgp
route-distinguisher 65000:501
vsi-export "vsi500_export"
vsi-import "vsi500_import"
...
#-------------------------------------------------echo "Policy Configuration"
#-------------------------------------------------policy-options
begin
community "comm_core" members "target:65000:500"
policy-statement "vsi500_export"
entry 10
action accept
community add "comm_core"
exit
exit
exit
policy-statement "vsi500_import"
entry 10
from
community "comm_core"
exit
action accept
exit
exit
default-action reject
exit

Note that the policy is applied at service 500 level, which means that the LP changes for all the
potential multi-homing sites configured under service 500. Therefore, load balancing can be
achieved on a per-service basis, but not within the same service.
Another important remark is that these policies are applied on the VPLS 500 for all the potential
BGP applications, that is, BGP VPLS, BGP MH and BGP AD. In the example, the LP for the PE2 BGP updates for BGP MH and BGP VPLS will be set to 150 (note that this however has no
impact on BGP VPLS since a given PE cannot receive two BGP VPLS NLRIs with the same VEID, such as a different VE-ID per PE within the same VPLS is required).

Page 228

Advanced Configuration Guide

BGP Multi-Homing for VPLS Networks

Black-hole Avoidance
The 7x50 supports the appropriate MAC flush mechanisms for BGP MH, regardless of the
protocol being used for the pseudowire signaling:

LDP VPLS The PE that contains the old DF site (the site that just experienced a DF>non-DF transition) always sends a LDP MAC flush-all-from-me to all LDP
pseudowires in the VPLS, including the LDP pseudowires associated with the new DF
site. No specific configuration is required.

BGP VPLS The remote BGP VPLS PEs interpret the F bit transitions from 1 to ZERO
as an implicit MAC flush-all-from-me indication. If a BGP update with the flag F=0 is
received from the previous DF PE, the remote PEs perform MAC flush-all-from-me,
flushing all the MACs associated with the pseudowire to the old DF PE. No specific
configuration is required.

Double flushing will not happen as it is expected that between any pair of PEs there will exist only
one type of pseudowires, either BGP or LDP pseudowire, but not both types.
In the example, assuming MTU-1 and PE-1 are the DF nodes:

When MH-site-1 is brought operationally down on MTU-1 (so by default, the two saps
must go down unless the failed-threshold parameter is changed so that the site is down
when only one sap is brought down), MTU-1 will issue a flush-all-from-me message.

When MH-site-2 is brought operationally down on PE-2, a BGP update with F=0 and D=1
is issued by PE-1. PE-2 and PE-3 will receive the update and will flush the MACs learned
on the pseudowire to PE-1.

Advanced Configuration Guide

Page 229

Configuration

CE-1
192.0.2.11 flush-allfrom-me

10.50.50.1
1/1/4:500

500

1/1/3:500

CE-2

flush-allfrom-me

MTU-1

1/1/4:500

192.0.2.1

F bit Transitions 1 ? 0
Are Interpreted As
Flush-All-From-Me

500

BGP Update Site-ID=1


F bit Transition 1 ? 0
192.0.2.3

PE-1

10.50.50.2
MH site-1

MH site-2

CE-3
192.0.2.31

500

500

PE-3
Route Reflector

MTU-3

10.50.50.3
1/1/2:503

1/1/2:504
192.0.2.2

192.0.2.21
1/1/4:500

500

CE-4
10.50.50.4

500

MTU-2

PE-2

LDP VPLS

BGP VPLS

LDP VPLS
OSSG641

Figure 42: MAC Flush for BGP MH

Node failures implicitly trigger a MAC flush on the remote nodes, since the TLDP/BGP session to
the failed node goes down.

Page 230

Advanced Configuration Guide

BGP Multi-Homing for VPLS Networks

Access CE/PE Signalling


BGP MH works at service level, therefore no physical ports are torn down on the non-DF but
rather the objects are brought down operationally, while the physical port will stay up and used for
any other services existing on that port. Due to this reason, there is a need for signalling the
standby status of an object to the remote PE or CE. In SR OS 8.0R1 and higher:

Access PEs running BGP MH on spoke-sdps and elected non-DF, will signal pseudowire
standby status (0x20) to the other end. If no pseudowire status is supported on the remote
MTU, a label withdrawal is performed4. If there is more than one spoke SDP on the site
(part of the same SHG), the signalling is sent for all the pseudowires of the site.

Multi-homed CEs connected through SAPs to the PEs running BGP MH, are signalled by
the PEs using Y.1731 CFM, either by stopping the transmission of CCMs or by sending
CCMs with ISDOWN (interface status down encoding in the interface status TLV).

In this example, down MEPs on MTU-1 sap 1/1/3:500, sap 1/1/4:500 and MTU-2 sap 1/1/4:500
are configured. Figure 43 shows only the MEPs on MTU-1 sap 1/1/3:500 and CE-2. Upon failure
on the MTU-1 site MH-site-1 the MEP 1 will start sending CCMs with interface status down.

CCM With isDOWN

CE-2

192.0.2.11

192.0.2.1
PW Status
0x20

1 500

1/1/3:500

500
192.0.2.3

MTU-1

1/1/4:500

PE-1

10.50.50.2
MH site-1

MH site-2

CE-3
192.0.2.31

500

500

PE-3
Route Reflector

MTU-3

10.50.50.3
1/1/2:503

1/1/2:504
192.0.2.2

192.0.2.21
1/1/4:500

500

CE-4
10.50.50.4

500

MTU-2

PE-2

LDP VPLS

BGP VPLS

LDP VPLS
OSSG642

Figure 43: Access PE/CE Signalling

4. Note that the configure service vpls x spoke-sdp y:z no pw-status-signaling parameter
allows to send a TLDP label-withdrawal instead of pseudowire status bits, even though the
peer supports pseudowire status.

Advanced Configuration Guide

Page 231

Configuration

The CFM configuration required at sap 1/1/3:500 is outlined below5. Down MEPs will be
configured on CE-2 and MTU-2 saps in the same way. Note that fault-propagation-enable useif-tlv must be added. In case the CE does not understand the CCM interface status TLV, the faultpropagation-enable suspend-ccm option can be enabled instead. This will stop the transmission
of CCMs upon site failures.
A:MTU-1>config>service# info
...
vpls 500 customer 1 create
split-horizon-group "site-1" create
exit
...
site "MH-site-1" create
site-id 1
split-horizon-group site-1
no shutdown
exit
...
sap 1/1/3:500 split-horizon-group "site-1" create
eth-cfm
mep 2 domain 1 association 1 direction down
fault-propagation-enable use-if-tlv
ccm-enable
no shutdown
exit
exit
exit

If CE-2 is a service router, upon receiving a CCM with ISDOWN, an alarm will be triggered and
the SAP will be brought down:

56 2010/02/06 15:18:00.62 UTC MINOR: ETH_CFM #2001 Base


"MEP 1/1/2 highest defect is now defMACstatus"
57 2010/02/06 15:18:00.63 UTC MINOR: SVCMGR #2108 vprn502
"Status of interface int-CE2-MTU-1 in service 500 (customer 1) changed to admin=up
oper=down"
58 2010/02/06 15:18:00.63 UTC MINOR: SVCMGR #2203 vprn502
"Status of SAP 1/1/3:500 in service 500 (customer 1) changed to admin=up oper=down
flags=OamDownMEPFault"
59 2010/02/06 15:18:00.63 UTC WARNING: SNMP #2004 vprn500 int-CE2-MTU-1
"Interface int-CE2-MTU-1 is not operational"
*A:CE-2# show service id 500 sap 1/1/3:500
===============================================================================
Service Access Points(SAP)

5. Detailed configuration guidelines for Y.1731 are out of the scope of this configuration guide.

Page 232

Advanced Configuration Guide

BGP Multi-Homing for VPLS Networks

===============================================================================
Service Id
: 500
SAP
: 1/1/3:500
Encap
: q-tag
Description
: (Not Specified)
Admin State
: Up
Oper State
: Down
Flags
: OamDownMEPFault
Multi Svc Site
: None
Last Status Change : 02/06/2010 15:18:01
Last Mgmt Change
: 02/05/2010 12:21:26
===============================================================================

As also depicted in Figure 43, PE-1 will signal pseudowire status standby (code 0x20) when PE-1
goes to non-DF state for MH-site-2 MTU-2 will receive that signalling and, based on the ignorestandby-signaling parameter, will decide whether to send the broadcast, unknown unicast and
multicast (BUM) traffic to PE-1. In case MTU-2 uses in its configuration ignore-standbysignaling. it will be sending BUM traffic on both pseudowires at the same time (which is not
normally desired), ignoring the pseudowire status bits. The following output shows the MTU-2
spoke sdp receiving the pseudowire status signalling. Note that although the spoke SDP stays
operationally up, the peer Pw Bits field shows pwFwdingStandby and MTU-2 will not send any
traffic if the ignore-standby-signaling parameter is disabled.
*A:MTU-2# show service id 500 sdp 211:500 detail
===============================================================================
Service Destination Point (Sdp Id : 211:500) Details
===============================================================================
------------------------------------------------------------------------------Sdp Id 212:500 -(192.0.2.1)
------------------------------------------------------------------------------Description
: (Not Specified)
SDP Id
: 211:500
Type
: Spoke
Spoke Descr
: (Not Specified)
Split Horiz Grp
: (Not Specified)
VC Type
: Ether
VC Tag
: n/a
Admin Path MTU
: 8000
Oper Path MTU
: 8000
Far End
: 192.0.2.1
Delivery
: MPLS
Hash Label
: Disabled
Admin State

: Up

Oper State

: Up

Endpoint
Class Fwding State
Flags
Time to RetryReset
Mac Move
Peer Pw Bits

:
:
:
:
:
:

Precedence

: 4

Retries Left
Blockable Level

: 3
: Tertiary

N/A
Down
None
never
Blockable
pwFwdingStandby

Advanced Configuration Guide

Page 233

Configuration

Operational Groups for BGP-MH


Operational groups (oper-groups in the CLI) introduce the capability of grouping objects into a
generic group object and associating its status to other service endpoints (pseudowires, SAPs, IP
interfaces) located in the same or in different service instances. The operational group status is
derived from the status of the individual components using certain rules specific to the application
using the concept. A number of other service entities, the monitoring objects, can be configured to
monitor the operational group status and to drive their own status based on the oper-group status.
In other words, if the operational group goes down, the monitoring objects will be brought down.
When one of the objects included in the oper-group comes up, the entire group will also come up,
and therefore so will the monitoring objects.
This concept can be used to enhance the BGP-MH solution by avoiding black-holes on the PE
selected as the Designated Forwarder (DF), if the rest of the VPLS endpoints fail (pseudowire
spoke(s)/pseudowire mesh and/or SAP(s)). Figure 44 illustrates the use of oper-groups together
with BGP-MH. On PE-1 (and PE-2) all of the BGP-VPLS pseudowires in the core are configured
under the same oper-group group-1. MH-site-2 is configured as a monitoring object. When the
two BGP-VPLS pseudowires go down, oper-group group-1 will be brought down, therefore MHsite-2 on PE-1 will go down as well (PE-2 will become DF and PE-1 will signal standby to MTU2).

192.0.2.1
192.0.2.11

MTU-1
500

1/1/3:500

CE-2

1/1/4:500

PE-1

PW status
0x20

500

Oper-group 1:
Bgp-vpls PWs

CE-3

192.0.2.3

192.0.2.31

PE-3

10.50.50.2

MTU-3

MH Site-2

MH Site-1

Monitor-opr-group 1

500

500

10.50.50.3
1/1/2:503
1/1/2:504

CE-4
Route Reflector

1/1/4:500

MTU-2

500

500

192.0.2.21

192.0.2.2

LDP VPLS

10.50.50.4

PE-2

BGP VPLS

LDP VPLS
ACG0016

Figure 44: Oper-Groups and BGP-MH

In the example above, this feature provides a solution to avoid a black-hole when PE-1 loses its
connectivity to the core.

Page 234

Advanced Configuration Guide

BGP Multi-Homing for VPLS Networks

Operational groups are configured in two steps:


1. Identify a set of objects whose forwarding state should be considered as a whole group then
group them under an operational group (in this case oper-group group-1, which is
configured in the bgp pw-template-bind context).
2. Associate other existing objects (clients) with the oper-group using the monitor-group
command (configured, in this case, in the site MH-site-2).
The following CLI excerpt shows the commands required (oper-group, monitor-oper-group).
A:PE-1>config>service# info
...
oper-group "group-1" create
...
vpls 500 customer 1 create
split-horizon-group "CORE" create
exit
bgp
route-distinguisher 65000:501
vsi-export "vsi500_export"
vsi-import "vsi500_import"
pw-template-bind 500 split-horizon-group "CORE"
oper-group "group-1"
exit
exit
bgp-vpls
max-ve-id 65535
ve-name 501
ve-id 501
exit
no shutdown
exit
stp
shutdown
exit
site "MH-site-2" create
site-id 2
spoke-sdp 121:500
monitor-oper-group "group-1"
no shutdown
exit
spoke-sdp 111:500 create
exit
spoke-sdp 121:500 create
exit
no shutdown
exit

When all the BGP-VPLS pseudowires go down, oper-group group-1 will go down and therefore
the monitoring object, site MH-site-2, will also go down and PE-2 will then be elected as DF. The
log 99 gives information about this sequence of events:

Advanced Configuration Guide

Page 235

Configuration

30 2012/02/02 17:46:51.58 UTC MINOR: SVCMGR #2542 Base


"Oper-group group-1 changed status to down"
31 2012/02/02 17:46:51.58 UTC MINOR: SVCMGR #2306 Base
"Status of SDP Bind 121:500 in service 500 (customer 1) changed to admin=up oper=do
wn flags="
33 2012/02/02 17:46:51.58 UTC WARNING: SVCMGR #2531 Base BGP-MH
"Service-id 500 site MH-site-2 is not the designated-forwarder"

Note that the process reverts when at least one BGP-VPLS pseudowire comes back up.

Page 236

Advanced Configuration Guide

BGP Multi-Homing for VPLS Networks

Show Commands and Debugging Options


The main command to find out the status of a given site is the show service id x site command. A
detail modifier is available:
*A:MTU-2# show service id 500 site "MH-site-1"
===============================================================================
Site Information
===============================================================================
Site Name
: MH-site-1
------------------------------------------------------------------------------Site Id
: 1
Dest
: sap:1/1/4:500
Mesh-SDP Bind
: no
Admin Status
: Enabled
Oper Status
: up
Designated Fwdr
: No
DF UpTime
: 0d 00:00:00 secs
DF Chg Cnt
: 1
Failed Threshold
: default(all)
===============================================================================
*A:MTU-2#

*A:MTU-2# show service id 500 site "MH-site-1" detail


===============================================================================
Site Information
===============================================================================
Site Name
: MH-site-1
------------------------------------------------------------------------------Site Id
: 1
Dest
: sap:1/1/4:500
Mesh-SDP Bind
: no
Admin Status
: Enabled
Oper Status
: up
Designated Fwdr
: No
DF UpTime
: 0d 00:00:00 secs
DF Chg Cnt
: 1
Boot Timer
: 120 (Ovr)
Timer Remaining : 0d 00:00:01
Site Activation Timer: 10 (Ovr)
Failed Threshold
: default(all)
===============================================================================
*A:MTU-2#

Note that the detail view of the command displays information about the BGP MH timers. The
values are only shown if the global values are overridden by specific ones at service level (and will
be tagged with Ovr if they have been configured at service level). The Timer Remaining field
reflects the count down from the boot/site activation timers down to the moment when this router
tries to become DF again. Again, this is only shown when the global timers have been overridden
by the ones at service level.
It is important to note that the objects on the non-DF site will be brought down operationally and
flagged with StandByForMHProtocol.
*A:MTU-2# show service id 500 sap 1/1/4:500
===============================================================================
Service Access Points(SAP)
===============================================================================
Service Id
: 500

Advanced Configuration Guide

Page 237

Configuration

SAP
: 1/1/4:500
Encap
: q-tag
Description
: (Not Specified)
Admin State
: Up
Oper State
: Down
Flags
: StandByForMHProtocol
Multi Svc Site
: None
Last Status Change : 02/06/2010 14:28:37
Last Mgmt Change
: 02/06/2010 14:21:30
===============================================================================
*A:PE-2# show service id 500 sdp 221:500 detail
===============================================================================
Service Destination Point (Sdp Id : 221:500) Details
===============================================================================
------------------------------------------------------------------------------Sdp Id 221:500 -(192.0.2.21)
------------------------------------------------------------------------------Description
: (Not Specified)
SDP Id
: 221:500
Type
: Spoke
Admin State

: Up

Oper State

Flags

: StandbyForMHProtocol

: Down

The BGP MH routes in the RIB, RIB-IN and RIB-OUT can be shown by using the corresponding
show router bgp routes and show router bgp neighbor x.x.x.x received-routes|advertisedroutes commands. Note that the BGP MH routes are only shown when the operator uses the l2vpn family modifier. Should the operator want to filter only the BGP MH routes out of the l2-vpn
routes, the multi-homing filter has to be added to the show router bgp routes commands.
*A:PE-3# show router bgp routes l2-vpn multi-homing site id 1 detail
===============================================================================
BGP L2VPN-MULTIHOME Routes
===============================================================================
Route Type
: MultiHome
Route Dist.
: 65000:511
Site Id
: 1
Nexthop
: 192.0.2.11
From
: 192.0.2.11
Res. Nexthop
: n/a
Local Pref.
: 100
Interface Name : NotAvailable
Aggregator AS : None
Aggregator
: None
Atomic Aggr.
: Not Atomic
MED
: 0
Community
: target:65000:500 l2-vpn:Encap=19: Flags=-DF: MTU=0
Cluster
: No Cluster Members
Originator Id : None
Peer Router Id : 192.0.2.11
Flags
: Used Valid Best IGP
AS-Path
: No As-Path
Route Type
Route Dist.
Site Id
Nexthop
From
Res. Nexthop
Local Pref.
Aggregator AS

Page 238

:
:
:
:
:
:
:
:

MultiHome
65000:521
1
192.0.2.21
192.0.2.21
n/a
100
None

Interface Name : NotAvailable


Aggregator
: None

Advanced Configuration Guide

BGP Multi-Homing for VPLS Networks

Atomic Aggr.
Community
Cluster
Originator Id
Flags
AS-Path

:
:
:
:
:
:

Not Atomic
MED
: 0
target:65000:500 l2-vpn:Encap=19: Flags=none: MTU=0
No Cluster Members
None
Peer Router Id : 192.0.2.21
Used Valid Best IGP
No As-Path

A new command was added in to show the Layer 2 BGP routes.


*A:PE-1# show service l2-route-table
- l2-route-table [detail] [bgp-ad] [multi-homing] [bgp-vpls]
<detail>
: keyword - display detailed information
*A:PE-1# show service l2-route-table multi-homing
===============================================================================
Services: L2 Multi-Homing Route Information - Summary
===============================================================================
Svc Id
L2-Routes (RD-Prefix)
Next Hop
SiteId
State DF
------------------------------------------------------------------------------500
65000:511
192.0.2.11
1
up(0) set
500
65000:521
192.0.2.21
1
up(0) clear
500
65000:502
192.0.2.2
2
up(0) clear
------------------------------------------------------------------------------No. of L2 Multi-Homing Route Entries: 3
===============================================================================

Finally, in terms of debugging, the recommendation would be to check the following CLI sources:

log-id 99 Provides information about the site object changes and DF changes.

debug router bgp update Shows the BGP updates for BGP MH, including the sent and
received BGP MH NLRIs and flags.

debug router ldp commands Provides information about the pseudowire status bits
being signalled as well as the MAC flush messages.

*A:MTU-1# debug router ldp peer 192.0.2.1 packet init detail


*A:MTU-1# debug router ldp peer 192.0.2.1 packet label detail

As an example, log-id 99 and debug output is displayed below after shutting down MH-site-1on
MTU-1:
*A:MTU-1# configure service vpls 500 sap 1/1/4:500 shutdown
*A:MTU-1# configure service vpls 500 sap 1/1/3:500 shutdown
6047 2010/02/06 14:46:04.05 UTC MINOR: SVCMGR #2203 Base
"Status of SAP 1/1/3:500 in service 500 (customer 1) changed to admin=down oper=down
flags=SapAdminDown "
6046 2010/02/06 14:46:04.05 UTC WARNING: SVCMGR #2531 Base BGP-MH
"Service-id 500 site MH-site-1 is not the designated-forwarder"

Advanced Configuration Guide

Page 239

Configuration

12 2010/02/06 14:46:04.04 UTC MINOR: DEBUG #2001 Base Peer 1: 192.0.2.3


"Peer 1: 192.0.2.3: UPDATE
Peer 1: 192.0.2.3 - Send BGP UPDATE:
Flag: 0x40 Type: 5 Len: 4 Local Preference: 100
Flag: 0xc0 Type: 16 Len: 16 Extended Community:
target:65000:500
l2-vpn:Encap=19: Flags=D: MTU=0
Flag: 0x90 Type: 14 Len: 28 Multiprotocol Reachable NLRI:
Address Family L2VPN
NextHop len 4 NextHop 192.0.2.11
[MH] site-id: 1, RD 65000:511
"
13 2010/02/06 14:46:04.04 UTC MINOR: DEBUG #2001 Base LDP
"LDP: LDP
Send Address Withdraw packet (msgId 434) to 192.0.2.1:0
MAC Flush (All MACs learned from me)
Service FEC EpipePWE3: ENET(5)/500 Group ID = 0 cBit = 0
"
14 2010/02/06 14:46:04.05 UTC MINOR: DEBUG #2001 Base Peer 1: 192.0.2.3
"Peer 1: 192.0.2.3: UPDATE
Peer 1: 192.0.2.3 - Received BGP UPDATE:
Withdrawn Length = 0
Total Path Attr Length = 86
Flag: 0x40 Type: 5 Len: 4 Local Preference: 100
Flag: 0x80 Type: 9 Len: 4 Originator ID: 192.0.2.21
Flag: 0x80 Type: 10 Len: 4 Cluster ID:
1.1.1.1
Flag: 0xc0 Type: 16 Len: 16 Extended Community:
target:65000:500
l2-vpn:Encap=19: Flags=-DF: MTU=0
Flag: 0x90 Type: 14 Len: 28 Multiprotocol Reachable NLRI:
Address Family L2VPN
NextHop len 4 NextHop 192.0.2.21
[MH] site-id: 1, RD 65000:521
"

Note that assuming all the recommended tools are enabled, a DF to non-DF transition can be
shown as well as the corresponding MAC flush messages and related BGP processing.
If MH-site-2 is torn down on PE-1, the debug router bgp update command would allow us to see
two BGP updates from PE-1:

A BGP MH update for site-id 2 with flag D set (since the site is down).

A BGP VPLS update for veid=501 and flag D set. This is due to the fact that there are no
more active objects on the VPLS, besides the BGP pseudowires.

*A:PE-1>config>service>vpls# spoke-sdp 121:500 shutdown


11 2010/02/20 11:21:55.49 UTC MINOR: DEBUG #2001 Base Peer 1: 192.0.2.3
"Peer 1: 192.0.2.3: UPDATE
Peer 1: 192.0.2.3 - Send BGP UPDATE:
Withdrawn Length = 0
Total Path Attr Length = 72
Flag: 0x40 Type: 1 Len: 1 Origin: 0

Page 240

Advanced Configuration Guide

BGP Multi-Homing for VPLS Networks

Flag: 0x40 Type: 2 Len: 0 AS Path:


Flag: 0x80 Type: 4 Len: 4 MED: 0
Flag: 0x40 Type: 5 Len: 4 Local Preference: 100
Flag: 0xc0 Type: 16 Len: 16 Extended Community:
target:65000:500
l2-vpn:Encap=19: Flags=D: MTU=0
Flag: 0x90 Type: 14 Len: 28 Multiprotocol Reachable NLRI:
Address Family L2VPN
NextHop len 4 NextHop 192.0.2.1
[MH] site-id: 2, RD 65000:501
12 2010/02/20 11:21:55.49 UTC MINOR: DEBUG #2001 Base Peer 1: 192.0.2.3
"Peer 1: 192.0.2.3: UPDATE
Peer 1: 192.0.2.3 - Send BGP UPDATE:
Withdrawn Length = 0
Total Path Attr Length = 72
Flag: 0x40 Type: 1 Len: 1 Origin: 0
Flag: 0x40 Type: 2 Len: 0 AS Path:
Flag: 0x80 Type: 4 Len: 4 MED: 0
Flag: 0x40 Type: 5 Len: 4 Local Preference: 100
Flag: 0xc0 Type: 16 Len: 16 Extended Community:
target:65000:500
l2-vpn:Encap=19: Flags=D: MTU=1514
Flag: 0x90 Type: 14 Len: 28 Multiprotocol Reachable NLRI:
Address Family L2VPN
NextHop len 4 NextHop 192.0.2.1
[VPLS] veid: 501, vbo: 497, vbs: 8, label-base: 131032, RD 65000:501

The D flag, sent along with the BGP VPLS update for veid 501, would be seen on the remote core
PEs as though it was a pseudowire status fault (although there is no TLDP running in the core).
*A:PE-2# show service id 500 all | match Flag
Flags
: None
Flags
: None
Flags
: PWPeerFaultStatusBits
Flags
: None

When oper-groups are configured (as previously shown), the following show command helps to
find the operational dependencies between monitoring objects and group objects.
*A:PE-1# show service oper-group "group-1" detail
===============================================================================
Service Oper Group Information
===============================================================================
Oper Group
: group-1
Creation Origin
: manual
Oper Status
: up
Hold DownTime
: 0 secs
Hold UpTime
: 4 secs
Members
: 1
Monitoring
: 1
===============================================================================
===================================================================
Member SDP-Binds for OperGroup: group-1
===================================================================
SdpId
SvcId
Type IP address
Adm
Opr
------------------------------------------------------------------1212:4294967293
500
Bgp* 192.0.2.2
Up
Up
1313:4294967294
500
Bgp* 192.0.2.3
Up
Up

Advanced Configuration Guide

Page 241

Configuration

------------------------------------------------------------------SDP Entries found: 2


===================================================================
* indicates that the corresponding row element may have been truncated.
===============================================================================
Monitoring Sites for OperGroup: group-1
===============================================================================
SvcId
Site
Site-Id
Dest
Admin
Oper Fwdr
------------------------------------------------------------------------------500
MH-site-2
2
sdp:121:500
Enabled up
Yes
------------------------------------------------------------------------------Site Entries found: 1
===============================================================================

Page 242

Advanced Configuration Guide

BGP Multi-Homing for VPLS Networks

Conclusion
The SR OS supports a wide range of service resiliency options as well as the best-of-breed system
level HA and MPLS mechanisms for the access and the core. BGP MH for VPLS completes the
service resiliency toolset by adding a mechanism that has some good advantages over the
alternative solutions:

BGP MH provides a common resiliency mechanism for attachment circuits (SAPs),


pseudowires (spoke SDPs), split horizon groups and mesh bindings

BGP MH is a network-based technique which does not need interaction to the CE or MTU
to which it is providing redundancy to.

The examples used in this section illustrate the configuration of BGP MH for access CEs and
MTUs. Show and debug commands have also been suggested so that the operator can verify and
troubleshoot the BGP MH procedures.

Advanced Configuration Guide

Page 243

Conclusion

Page 244

Advanced Configuration Guide

BGP Virtual Private Wire Services

In This Chapter
This section describes BGP Virtual Private Wire Service (VPWS) configurations.
Topics in this section include:

Applicability on page 246

Overview on page 247

Configuration on page 251

Conclusion on page 276

Advanced Configuration Guide

Page 245

Applicability

Applicability
This example is applicable to all of the 7710, 7450, 7750 SR and 7950 XRS series and was tested
on Release 11.0.R4. There are no prerequisites for this configuration.

Introduction
There are currently two IETF standards for the provisioning of Virtual Private Wire Services
(VPWS). RFC 4447, Pseudowire Setup and Maintenance Using the Label Distribution Protocol
(LDP), describes Label Distribution Protocol (LDP) VPWS, where VPWS pseudowires are
signaled using LDP between Provider Edge (PE) Routers.
RFC 6624, Layer 2 Virtual Private Networks Using BGP for Auto-Discovery and Signaling,
describes the use of Border Gateway Protocol (BGP) for signaling of pseudo-wires between such
PEs.
The purpose of this example is to describe the configuration and troubleshooting for BGP VPWS.

Page 246

Advanced Configuration Guide

BGP Virtual Private Wire Services

Overview
PE-1

192.0.2.1

192.168.14.1/30
192.168.14.2/30

P-4
192.0.2.5

RR-1

192.168.45.1/30
192.168.45.2/30

192.0.2.4

192.168.24.2/30
192.168.24.1/30

192.0.2.2

PE-2

192.168.34.2/30
192.168.34.1/30

192.0.2.3

PE-3
al_0265

Figure 45: Network Topology

The network topology is displayed in Figure 45. The setup uses five Service Router (SR) nodes
located in the same Autonomous System (AS). There are three PE routers connected to a single P
router and a Route Reflector (RR-1) for the AS. The Provider Edge routers are all BGP VPWS
aware. The Provider (P) router is BGP VPWS unaware and also does not take part in the BGP
process.
The following configuration tasks should be completed as a prerequisite:

IS-IS or OSPF should be configured on each of the network interfaces between the PE/P
routers and route reflector.

MPLS should be configured on all interfaces between PE routers and P routers. It is not
required between P-4 and RR-1.

LDP should be configured on interfaces between PE and P routers. It is not required


between P-4 and the RR-1.

RSVP protocol should be configured on interfaces between PE and P routers. It is not


required between P-4 and the RR-1.

Advanced Configuration Guide

Page 247

Overview

BGP VPWS
In this architecture, a VPWS is a collection of two (or three in case of redundancy) BGP VPWS
service instances present on different PEs in a provider network.
The PEs communicate with each other at the control plane level by means of BGP updates
containing BGP VPWS Network Layer Reachability Information (NLRI). Each update contains
enough information for a PE to determine the presence of other BGP VPWS instances on peering
PEs and to set-up pseudowire connectivity for data flow between peers containing the same BGP
VPWS service. Therefore, auto-discovery and pseudowire signaling is achieved using a single
BGP update message.
Each PE with a BGP VPWS instance is identified by a VPWS Edge identifier (VE-ID) and the
presence of other BGP VPWS instances is determined using the exchange of standard BGP
extended community route targets between PEs.
Each PE will advertise, via the route reflector, the presence of its BGP VPWS instance to all other
PEs, along with a block of multiplexer labels (for BGP VPWS there is just one label per block)
that can be used to communicate between each instance, plus a BGP next-hop that determines a
labeled transport tunnel to be used between PEs.
Each BGP VPWS instance is configured with import and export route target extended
communities for topology control, along with VE identification.
The following examples show the configuration of four BGP VPWS scenarios.

Single homed BGP VPWS


using Auto-provisioned SDPs
using Pre-Provisioned SDP

Dual homed BGP VPWS


with Single Pseudowire
with Active/Standby Pseudowire

Page 248

Advanced Configuration Guide

BGP Virtual Private Wire Services

Configuration Tasks
The first step is to configure an MP-iBGP session between each of the PEs and the Route
Reflector.
The configuration for PE-1 is as follows:
configure router
autonomous-system 65536
bgp
group internal
family l2-vpn
peer-as 65536
local-as 65536
neighbor 192.0.2.5
exit
exit
exit
exit

The configuration for the other PE nodes is very similar. The IP addresses can be derived from
Figure 45.
The configuration for the Route Reflector (RR-1) is:
configure router bgp
group internal
type internal
cluster 1.1.1.1
family l2-vpn
peer-as 65536
local-as 65536
neighbor 192.0.2.1
exit
neighbor 192.0.2.2
exit
neighbor 192.0.2.3
exit
exit
exit

On RR-1, show that BGP sessions with each PE are established and have a negotiated l2-vpn
address family capability.
A:RR-1# show router bgp summary
===============================================================================
BGP Router ID:192.0.2.5
AS:65536
Local AS:65536
===============================================================================
BGP Admin State
: Up
BGP Oper State
: Up
Total Peer Groups
: 1
Total Peers
: 3
Total BGP Paths
: 16
Total Path Memory
: 2992
Total IPv4 Remote Rts
: 0
Total IPv4 Rem. Active Rts : 0

Advanced Configuration Guide

Page 249

Overview

Total McIPv4 Remote Rts : 0


Total IPv6 Remote Rts
: 0
Total IPv4 Backup Rts
: 0

Total McIPv4 Rem. Active Rts: 0


Total IPv6 Rem. Active Rts : 0
Total IPv6 Backup Rts
: 0

Total Supressed Rts


Total Decay Rts

: 0
: 0

Total Hist. Rts

: 0

Total
Total
Total
Total
Total

:
:
:
:
:

Total VPN Peers

: 0

VPN Peer Groups


VPN Local Rts
VPN-IPv4 Rem. Rts
VPN-IPv6 Rem. Rts
VPN-IPv4 Bkup Rts

Total VPN Supp. Rts


Total VPN Decay Rts

0
0
0
0
0

: 0
: 0

Total VPN-IPv4 Rem. Act. Rts: 0


Total VPN-IPv6 Rem. Act. Rts: 0
Total VPN-IPv6 Bkup Rts
: 0
Total VPN Hist. Rts

: 0

Total L2-VPN Rem. Rts


: 11
Total L2VPN Rem. Act. Rts
: 0
Total MVPN-IPv4 Rem Rts : 0
Total MVPN-IPv4 Rem Act Rts : 0
Total MDT-SAFI Rem Rts : 0
Total MDT-SAFI Rem Act Rts : 0
Total MSPW Rem Rts
: 0
Total MSPW Rem Act Rts
: 0
Total RouteTgt Rem Rts : 0
Total RouteTgt Rem Act Rts : 0
Total McVpnIPv4 Rem Rts : 0
Total McVpnIPv4 Rem Act Rts : 0
Total MVPN-IPv6 Rem Rts : 0
Total MVPN-IPv6 Rem Act Rts : 0
Total FlowIpv4 Rem Rts : 0
Total FlowIpv4 Rem Act Rts : 0
Total FlowIpv6 Rem Rts : 0
Total FlowIpv6 Rem Act Rts : 0
===============================================================================
BGP Summary
===============================================================================
Neighbor
AS PktRcvd InQ Up/Down
State|Rcv/Act/Sent (Addr Family)
PktSent OutQ
------------------------------------------------------------------------------192.0.2.1
65536
67
0 00h29m03s 4/0/11 (L2VPN)
78
0
192.0.2.2
65536
62
0 00h27m43s 3/0/11 (L2VPN)
72
0
192.0.2.3
65536
62
0 00h29m03s 4/0/11 (L2VPN)
78
0
-------------------------------------------------------------------------------

Page 250

Advanced Configuration Guide

BGP Virtual Private Wire Services

Configuration
Pseudowire Templates
BGP VPWS utilizes pseudowire (PW) templates to dynamically instantiate SDP bindings for a
given service to signal the egress service de-multiplexer labels used by remote PEs to reach the
local PE.
The template determines the signaling parameters of the pseudowire, such as vc-type, vlan-vc-tag,
hash-label, filters, etc. The following parameters are recognized by BGP VPWS; the remainder is
ignored.
The following commands are supported parameters:
config
service
[no] pw-template policy-id [use-provisioned-sdp] [create]
accounting-policy acct-policy-id
no accounting-policy
[no] collect-stats
egress
filter ipv6 ipv6-filter-id
filter ip ip-filter-id
filter mac mac-filter-id
no filter [ip ip-filter-id] [mac mac-filter-id] [ipv6 ipv6-filter-id]
qos network-policy-id port-redirect-group queue-group-name [instance instance-id]
no qos
[no] force-vlan-vc-forwarding
hash-label [signal-capability]
no hash-label
ingress
filter ipv6 ipv6-filter-id
filter ip ip-filter-id
filter mac mac-filter-id
no filter [ip ip-filter-id] [mac mac-filter-id] [ipv6 ipv6-filter-id]
qos network-policy-id fp-redirect-group queue-group-name instance instance-id
no qos
[no] sdp-exclude group-name
[no] sdp-include group-name
vc-type {ether | vlan}
vlan-vc-tag 0..4094
no vlan-vc-tag

Note that:

The encapsulation type in the Layer-2 extended community is either 4 (Ethernet VLAN
tagged mode) or 5 (Ethernet raw mode), depending on the vc-type parameter.

The force-vlan-vc-forwarding function will add a tag (equivalent to vc-type vlan) and
will allow for customer QoS transparency (dot1p+DE bits).

Advanced Configuration Guide

Page 251

Configuration

The MPLS transport tunnel between PEs can be signaled using LDP or RSVP-TE.
LDP-based SDPs can be automatically instantiated or pre-provisioned. RSVP-TE-based SDPs
have to be pre-provisioned. If pre-provisioned pseudowires should be used, the pw-template must
be created with the use-provisioned-sdp parameter.
*A:PE-1# configure service pw-template
- [no] pw-template <policy-id> [use-provisioned-sdp] [create]

Pseudowire Templates for Auto-SDP Creation using LDP


In order to use an LDP transport tunnel for data flow between PEs, it is necessary for link layer
LDP to be configured between all PEs/Ps so that a transport label for each PEs system interface is
available. For example, on PE-1:
A:PE-1# configure router ldp
interface-parameters
interface "PE-1-P-4"
exit
targeted-session
exit

Using this mechanism, SDPs can be auto-instantiated with SDP-ids starting at the higher end of
the SDP numbering range, such as 17407. Any subsequent SDPs created use SDP-ids
decrementing from this value.
A pseudowire template is required. The example below is created using the default values:
A:PE-1# configure service
pw-template 1 create
exit

Pseudowire Templates for Provisioned SDPs using RSVP-TE


RSVP-TE LSPs need to be created between the PE routers on which provisioned SDPs will be
used as prerequisite.
The MPLS interface and LSP configuration for PE-1 are:
A:PE-1# configure router mpls
interface "system"
no shutdown
exit
interface "PE-1-P-4"
no shutdown
exit

Page 252

Advanced Configuration Guide

BGP Virtual Private Wire Services

path "dyn"
no shutdown
exit
lsp "LSP-PE-1-PE-2"
to 192.0.2.2
primary "dyn"
exit
no shutdown
exit
lsp "LSP-PE-1-PE-3"
to 192.0.2.3
primary "dyn"
exit
no shutdown
exit
no shutdown
exit

The MPLS and LSP configuration for PE-2 are similar to that of PE-1 with the appropriate
interfaces and LSP names configured.
To use an RSVP-TE tunnel as transport between PEs, it is necessary to bind the RSVP-TE LSP
between PEs to an SDP.
The SDP creation on PE-1 towards PE-2 is shown below; similar SDPs are required on each PE to
the remote PEs in the service where provisioned SDPs are to be used (only on PE-2 in the example
below).
A:PE-1# configure service sdp 12 mpls create
description "from-PE1"
far-end 192.0.2.2
lsp "LSP-PE-1-PE-2"
signaling bgp
keep-alive
shutdown
exit
no shutdown

Note that the signaling bgp parameter is required. BGP VPWS instances using BGP VPWS
signaling are able to use these SDPs. Conversely, SDPs that are bound to RSVP-based LSPs with
signaling set to the default value of tldp will not be used as SDPs within BGP VPWS.

Advanced Configuration Guide

Page 253

Configuration

Single Homed BGP VPWS using Auto-Provisioned SDPs

PE-1
Ve-id=1
Rd=65551:1
Rt=65551:10

192.0.2.1

Epipe 1
P-4
192.0.2.5
192.0.2.4

192.0.2.2

RR-1
PE-2
Epipe 1
Ve-id=3
Rd=65551:3
Rt=65551:10

192.0.2.3

PE-3
al_0266

Figure 46: Single Homed BGP VPWS using Auto-Provisioned SDPs

Figure 46 shows a schematic of a single homed BGP VPWS between PE-1 and PE-2 where SDPs
are auto-provisioned. In this case, the transport tunnels are LDP signaled.
The following shows the configuration required on PE-1 for a BGP VPWS service using a
pseudowire template configured for auto-provisioning of SDPs.
A:PE-1# configure service
pw-template 1 create
vc-type vlan
exit
epipe 1 customer 1 create
bgp
route-distinguisher 65551:1
route-target export target:65551:10 import target:65551:10
pw-template-binding 1
exit
exit
bgp-vpws
ve-name "PE1"
ve-id 1
exit
remote-ve-name "PE3"
ve-id 3

Page 254

Advanced Configuration Guide

BGP Virtual Private Wire Services

exit
no shutdown
exit
sap 1/1/4:100 create
exit
no shutdown
exit
exit

The bgp context specifies parameters that are required for BGP VPWS.
Within the bgp context, parameters are configured that are used by the neighboring PEs to
determine the membership of a given BGP VPWS; in other words, the auto-discovery of PEs in
the same BGP VPWS, the route-distinguisher is configured, along with the route target extended
communities. Route target communities are used to determine membership of a given BGP
VPWS. Note that the import and export route targets at the BGP level are mandatory. The pwtemplate binding is then applied and its parameters are used for both the routes sent by this PE and
the received routes matching the route target value.
Within the bgp-vpws context, the signaling parameters are also configured. These determine the
service labels required for the data plane of the VPWS instance.
The VPWS Edge ID (VE-ID) is a numerical value assigned to each PE within a BGP VPWS. This
value must be unique for a given BGP VPWS, with the exception of multi-homed scenarios,
where two dual-homed PEs can have the same VE-ID and are distinguishable by the site
preference (or by the tie breaking rules from the multi-homing draft RFC).
It is also worth noting that changes to the pseudowire template are not taken into account once the
pseudowire has been set up (changes of route-target are refreshed though). PW-templates can be
re-evaluated with the tools perform eval-pw-template command. The eval-pw-template checks
if all of the bindings using this pw-template policy are still meant to be used this policy. If the
template has changed and allow-service-impact is TRUE, then the old binding is removed and it is
re-added using the new template.

Advanced Configuration Guide

Page 255

Configuration

VE-ID and BGP Label Allocations


For a point-to-point VPWS, there are only two members within the BGP VPWS service, so only
one label entry is required by each remote service. For dual-homed scenarios, there are two labels
for the redundant site, one from each dual-homed PE.
Each PE allocates a label per BGP VPWS instance for the remote PEs, so it signals blocks with
one label. It achieves this by advertising three parameters in a BGP update message.

A Label Base (LB) which is the lowest label in the block.

A VE Block size (VBS) which is always 1 and cannot be changed.

A VE Base Offset (VBO) corresponding to the first label in the label block.

PE-3 Service Creation


On PE-3 create a BGP VPWS service using pseudowire template 1. PE-3 has been allocated a VEID of 3. For completeness, the pw-template is also shown.
A:PE-3# configure service
pw-template 1 create
vc-type vlan
exit
epipe 1 customer 1 create
bgp
route-distinguisher 65551:3
route-target export target:65551:10 import target:65551:10
pw-template-binding 1
exit
exit
bgp-vpws
ve-name "PE3"
ve-id 3
exit
remote-ve-name "PE1"
ve-id 1
exit
no shutdown
exit
sap 1/1/4:101 create
exit
no shutdown
exit
exit

Page 256

Advanced Configuration Guide

BGP Virtual Private Wire Services

PE-1 Service Operation Verification


Verify that the BGP VPWS service is enabled on PE-1.
A:PE-1# show service id 1 bgp-vpws
===============================================================================
BGP VPWS Information
===============================================================================
Admin State
: Enabled
VE Name
: PE1
VE Id
: 1
PW Template
: 1
Route Dist
: 65551:1
Rte-Target Import
: 65551:10
Rte-Target Export: 65551:10
PW-Template Id
: 1
Import Rte-Tgt
: None
------------------------------------------------------------------------------Remote-Ve Information
------------------------------------------------------------------------------Remote VE Name
: PE3
Remote VE Id
: 3
===============================================================================
A:PE-1#

Verify that the service is operationally up on PE-1.


A:PE-1# show service id 1 base
===============================================================================
Service Basic Information
===============================================================================
Service Id
: 1
Vpn Id
: 0
Service Type
: Epipe
Name
: (Not Specified)
Description
: (Not Specified)
Customer Id
: 1
Creation Origin
: manual
Last Status Change: 04/26/2013 08:07:51
Last Mgmt Change : 04/26/2013 08:07:51
Admin State
: Up
Oper State
: Up
MTU
: 1514
Vc Switching
: False
SAP Count
: 1
SDP Bind Count
: 1
Per Svc Hashing
: Disabled
Force QTag Fwd
: Disabled
------------------------------------------------------------------------------Service Access & Destination Points
------------------------------------------------------------------------------Identifier
Type
AdmMTU OprMTU Adm Opr
------------------------------------------------------------------------------sap:1/1/4:100
q-tag
1578
1578
Up
Up
sdp:17407:4294967293 SB(192.0.2.3)
BgpVpws
0
1552
Up
Up
===============================================================================
A:PE-1#

Advanced Configuration Guide

Page 257

Configuration

The SAP and SDP are all operationally up. Note that the indication SB next to the SDP-id
signify Spoke and BGP.
Further verification can be seen below where the ingress label for PE-3, that is, the labels used by
PE-1 are shown.
A:PE-1# show service id 1 sdp
===============================================================================
Services: Service Destination Points
===============================================================================
SdpId
Type Far End addr
Adm
Opr
I.Lbl
E.Lbl
------------------------------------------------------------------------------17407:4294967293 BVws 192.0.2.3
Up
Up
131070
131070
------------------------------------------------------------------------------Number of SDPs : 1
-------------------------------------------------------------------------------

The following debug output from PE-1 shows the BGP VPWS NLRI update for Epipe 1 sent by
PE-1 to the route reflector (192.0.2.5). This update will then be received by the other PEs.
DEBUG #2001 Base Peer 1: 192.0.2.5
"Peer 1: 192.0.2.5: UPDATE
Peer 1: 192.0.2.5 - Send BGP UPDATE:
Withdrawn Length = 0
Total Path Attr Length = 76
Flag: 0x90 Type: 14 Len: 32 Multiprotocol Reachable NLRI:
Address Family L2VPN
NextHop len 4 NextHop 192.0.2.1
[VPLS/VPWS] veid: 1, vbo: 3, vbs: 1, label-base: 131070, RD 65551:1, csv
: 0x0
Flag: 0x40 Type: 1 Len: 1 Origin: 0
Flag: 0x40 Type: 2 Len: 0 AS Path:
Flag: 0x80 Type: 4 Len: 4 MED: 0
Flag: 0x40 Type: 5 Len: 4 Local Preference: 100
Flag: 0xc0 Type: 16 Len: 16 Extended Community:
target:65551:10
l2-vpn/vrf-imp:Encap=4: Flags=none: MTU=1514: PREF=0
"

Note the presence of the control flags within the extended community which indicate the status of
the BGP VPWS instance.
The control flags are described below:

0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|D|A|F|Z|Z|Z|C|S| (Z = MUST Be Zero)
+-+-+-+-+-+-+-+-+

Page 258

Advanced Configuration Guide

BGP Virtual Private Wire Services

D: access circuit down indicator. D is 1 if all access circuits are down, otherwise D is 0.

A: automatic site id allocation, which is not supported. This is ignored on receipt and set
to 0 on sending.

F: MAC flush indicator, this relates to VPLS. This is set to 0 and ignored on receipt.

C: presence of a control word. Control word usage is not supported. This is set to 0 on
sending (control word not present) and if a non-zero value is received (indicating a control
word is required) the pseudowire will not be created.

S: sequenced delivery. Sequenced delivery is not supported. This is set to 0 on sending (no
sequenced delivery) and if a non-zero value is received (indicating sequenced delivery
required) the pseudowire will not be created.

The BGP VPWS NLRI is based on that defined for BGP VPLS but is extended with a circuit
status vector. The circuit status vector is used to indicate the status of both the SAP and the spokeSDP within the local service. As the VE block size used is 1, the most significant bit in the circuit
status vector TLV value will be set to 1 if either the SAP or spoke-SDP is down; otherwise, it will
be set to 0.
DEBUG #2001 Base Peer 1: 192.0.2.5
"Peer 1: 192.0.2.5: UPDATE
Peer 1: 192.0.2.5 - Send BGP UPDATE:
Withdrawn Length = 0
Total Path Attr Length = 76
Flag: 0x90 Type: 14 Len: 32 Multiprotocol Reachable NLRI:
Address Family L2VPN
NextHop len 4 NextHop 192.0.2.1
[VPLS/VPWS] veid: 1, vbo: 3, vbs: 1, label-base: 131070, RD 65551:1, csv
: 0x80
Flag: 0x40 Type: 1 Len: 1 Origin: 0
Flag: 0x40 Type: 2 Len: 0 AS Path:
Flag: 0x80 Type: 4 Len: 4 MED: 0
Flag: 0x40 Type: 5 Len: 4 Local Preference: 100
Flag: 0xc0 Type: 16 Len: 16 Extended Community:
target:65551:10
l2-vpn/vrf-imp:Encap=4: Flags=D: MTU=1514: PREF=0
"

After shutting down the local SAP, the CSV has the most-significant bit set to 1 (0x80).
The BGP VPWS update can be shown using the following command (note that the SDP-id has
changed from that seen above as the spoke SDP has been re-signaled since the above output):
A:PE-1# show service l2-route-table bgp-vpws detail
===============================================================================
Services: L2 Bgp-Vpws Route Information - Summary
===============================================================================
Svc Id
VeId
PW Temp Id

: 1
: 3
: 1

Advanced Configuration Guide

Page 259

Configuration

RD
: *65551:3
Next Hop
: 192.0.2.3
State (D-Bit) : up(0)
Path MTU
: 1514
Control Word
: 0
Seq Delivery
: 0
Status
: active
Tx Status
: active
CSV
: 0
Preference
: 0
Sdp Bind Id
: 17407:4294967290
===============================================================================

PE-3 Service Operation Verification


Similar to PE-1, the service operation should be validated on PE-3.

Page 260

Advanced Configuration Guide

BGP Virtual Private Wire Services

Single Homed BGP VPWS using Pre-Provisioned SDP


It is possible to configure BGP VPWS instances that use RSVP-TE transport tunnels. In this case,
the SDPs must be created with the MPLS LSPs mapped and with the signaling set to BGP, as the
service labels are signaled using BGP. The pw-template configured within the BGP VPWS
instance must use the keyword use-provisioned-sdp.

PE-1
Ve-id=1
Rd=65551:2211
Rt=65551:22

SDP 12
LSP LSP-PE-1-PE-2
192.0.2.1

Epipe 2

P-4

SDP 21
LSP LSP-PE-2-PE-1

192.0.2.5
192.0.2.4

192.0.2.2

RR-1

Ve-id=2
Rd=65551:2222
Rt=65551:22

PE-2

192.0.2.3

PE-3
al_0267

Figure 47: Single Homed BGP VPWS using Pre-Provisioned SDP

Figure 47 shows a schematic of a BGP VPWS where SDPs are pre-provisioned with RSVP-TE
signaled transport tunnels.
SDP on PE-1
configure service
sdp 12 mpls create
description "from-192.0.2.1"
signaling bgp
far-end 192.0.2.2
lsp "LSP-PE-1-PE-2"
keep-alive
shutdown
exit
no shutdown
exit
exit

Advanced Configuration Guide

Page 261

Configuration

SDP on PE-2
configure service
sdp 21 mpls create
description "from-192.0.2.2"
signaling bgp
far-end 192.0.2.1
lsp "LSP-PE-2-PE-1"
keep-alive
shutdown
exit
no shutdown
exit
exit

To create a spoke SDP within a service that uses the RSVP-TE transport tunnel, a pseudowire
template is required that has the use-provisioned-sdp parameter set.
The pw-template is provisioned on both PEs as follows:
A:PE-1# configure service
pw-template 2 use-provisioned-sdp create
vc-type ether
exit

The following output shows the configuration required for a BGP VPWS service using a
pseudowire template configured for using pre-provisioned RSVP-TE SDPs.
A:PE-1# configure service epipe 2 customer 1 create
bgp
route-distinguisher 65551:2211
route-target export target:65551:22 import target:65551:22
pw-template-binding 2
exit
exit
bgp-vpws
ve-name "PE-1"
ve-id 1
exit
remote-ve-name "PE-2"
ve-id 2
exit
no shutdown
exit
sap 1/1/4:2200 create
exit
no shutdown
exit
exit

Page 262

Advanced Configuration Guide

BGP Virtual Private Wire Services

The route distinguisher and route target extended community values for Epipe 2 are different from
that in Epipe 1. This is to differentiate between the two as their visibility is global within the BGP
domain. The VE-ID values can be reused in each Epipe instance, as long as they are unique within
the instance.
Similarly, on PE-2 the configuration is as seen below, where the VE-ID is 2:
A:PE-2# configure service epipe 2 customer 1 create
bgp
route-distinguisher 65551:2222
route-target export target:65551:22 import target:65551:22
pw-template-binding 2
exit
exit
bgp-vpws
ve-name "PE2"
ve-id 2
exit
remote-ve-name "PE-1"
ve-id 1
exit
no shutdown
exit
sap 1/1/3:200 create
exit
no shutdown
exit

Verify that the service is operationally up on PE-1.


A:PE-1# show service id 2 base
===============================================================================
Service Basic Information
===============================================================================
Service Id
: 2
Vpn Id
: 0
Service Type
: Epipe
Name
: (Not Specified)
Description
: (Not Specified)
Customer Id
: 1
Creation Origin
: manual
Last Status Change: 04/26/2013 12:21:00
Last Mgmt Change : 04/26/2013 12:21:00
Admin State
: Up
Oper State
: Up
MTU
: 1514
Vc Switching
: False
SAP Count
: 1
SDP Bind Count
: 1
Per Svc Hashing
: Disabled
Force QTag Fwd
: Disabled
------------------------------------------------------------------------------Service Access & Destination Points
------------------------------------------------------------------------------Identifier
Type
AdmMTU OprMTU Adm Opr
------------------------------------------------------------------------------sap:1/1/4:2200
q-tag
1578
1578
Up
Up
sdp:12:4294967289 S(192.0.2.2)
BgpVpws
0
1552
Up
Up

Advanced Configuration Guide

Page 263

Configuration

===============================================================================
A:PE-1#

Note that the SDP-id is the pre-provisioned SDP 12.


For completeness, verify the service is operationally up on PE-2.
A:PE-2# show service id 2 base
===============================================================================
Service Basic Information
===============================================================================
Service Id
: 2
Vpn Id
: 0
Service Type
: Epipe
Name
: (Not Specified)
Description
: (Not Specified)
Customer Id
: 1
Creation Origin
: manual
Last Status Change: 04/26/2013 12:16:33
Last Mgmt Change : 04/26/2013 12:16:33
Admin State
: Up
Oper State
: Up
MTU
: 1514
Vc Switching
: False
SAP Count
: 1
SDP Bind Count
: 1
Per Svc Hashing
: Disabled
Force QTag Fwd
: Disabled
------------------------------------------------------------------------------Service Access & Destination Points
------------------------------------------------------------------------------Identifier
Type
AdmMTU OprMTU Adm Opr
------------------------------------------------------------------------------sap:1/1/3:200
q-tag
1578
1578
Up
Up
sdp:21:4294967293 S(192.0.2.1)
BgpVpws
0
1552
Up
Up
===============================================================================
A:PE-2#

Again, the SDP-id used is the pre-provisioned SDP 21.

Page 264

Advanced Configuration Guide

BGP Virtual Private Wire Services

Dual Homed BGP VPWS with Single Pseudowire


For access redundancy, an Epipe using a BGP VPWS service can be configured as dual-homed, as
described in draft-ietf-l2vpn-vpls-multihoming-03. It can be configured with a single pseudowire
setup, where the redundant pseudowire is not created until the initially active pseudowire is
removed.
The diagram below shows a setup where an Epipe is configured on each PE. Site B is dual-homed
to PE-1 and PE-3 with the remote PE-2 connected to site A; each site connection uses a SAP. A
single pseudowire using Ethernet Raw Mode encapsulation connects PE-2 to PE-1 or PE-3 (but
not both at the same time). The pseudowire is signaled using BGP VPWS over a tunnel LSP
between the PEs.
Ve-id=1
Mh-id=1
Site-preference=200
Rd=65551:31
Rt=65551:31

PE-1

192.0.2.1

Epipe 3
Ve-id=3
Rd=65551:32
Rt=65551:31

SAP
P-4
Dual-homed
Site
192.0.2.4

192.0.2.2

SiteB

SiteA
PE-2
SAP

Blocked

192.0.2.3

Ve-id=1
Mh-id=1
Site-preference=10
Rd=65551:33
Rt=65551:31

PE-3
al_0268

Figure 48: Dual Homed BGP VPWS with Single Pseudowire

BGP multi-homing is configured for the dual-homed site B using a site-id=1. The site-preference
on PE-1 is set to 200 and to 10 on PE-3, this ensures that PE-1 will be the sites designated
forwarder and the pseudowire from PE-2 will be created to PE-1 when PE-1 is fully operational
(no pseudowire is created on PE-2 to PE-3). If PE-1 fails, or the multi-homing site fails over to
PE-3, then the pseudowire from PE-2 to PE-1 will be removed and a new pseudowire will be
created from PE-2 to PE-3.

Advanced Configuration Guide

Page 265

Configuration

PE-1 Configuration
A:PE-1# configure service
pw-template 3 create
exit
epipe 3 customer 1 create
bgp
route-distinguisher 65551:31
route-target export target:65551:31 import target:65551:31
pw-template-binding 3
exit
exit
bgp-vpws
ve-name "PE-1"
ve-id 1
exit
remote-ve-name "PE-2"
ve-id 2
exit
no shutdown
exit
site "siteB" create
site-id 1
sap 1/1/4:99
site-preference 200
no shutdown
exit
sap 1/1/4:99 create
exit
no shutdown
exit
exit

PE-3 Configuration
A:PE-3# configure service
pw-template 3 create
exit
epipe 3 customer 1 create
bgp
route-distinguisher 65551:33
route-target export target:65551:31 import target:65551:31
pw-template-binding 3
exit
exit
bgp-vpws
ve-name "PE-3"
ve-id 1
exit
remote-ve-name "PE-2"
ve-id 2
exit
no shutdown
exit
site "siteB" create
site-id 1
sap 1/1/4:99

Page 266

Advanced Configuration Guide

BGP Virtual Private Wire Services

site-preference 10
no shutdown
exit
sap 1/1/4:99 create
exit
no shutdown
exit
exit

Note that in the above configurations, the remote-ve-name for PE-2 uses VE-ID 2 on both PE-1
and PE-3.
PE-2 Configuration
A:PE-2# configure service
pw-template 3 create
exit
epipe 3 customer 1 create
bgp
route-distinguisher 65551:32
route-target export target:65551:31 import target:65551:31
pw-template-binding 3
exit
exit
bgp-vpws
ve-name "PE-2"
ve-id 2
exit
remote-ve-name "PE-1orPE-3"
ve-id 1
exit
no shutdown
exit
sap 1/1/3:99 create
exit
no shutdown
exit
exit

On PE-2, the remote-ve-name is configured as PE-1 or PE-3; this is because both of these PEs are
configured with VE-ID 1.
As a result of this configuration, observe that on PE-2, there are multiple route entries for RouteTarget 65551:31. In the BGP routing table, there are two entries per partner PE, one for the BGPMH update (with site-id=1) and the other for the BGP-VPWS update (with VE-ID=1).
A:PE-2# show router bgp routes l2-vpn rd 65551:31
===============================================================================
BGP Router ID:192.0.2.2
AS:65536
Local AS:65536
===============================================================================
Legend Status codes : u - used, s - suppressed, h - history, d - decayed, * - valid
Origin codes : i - IGP, e - EGP, ? - incomplete, > - best, b - backup

Advanced Configuration Guide

Page 267

Configuration

===============================================================================
BGP L2VPN Routes
===============================================================================
Flag RouteType
Prefix
MED
RD
SiteId
Label
Nexthop
VeId
BlockSize
LocalPref
As-Path
BaseOffset
vplsLabelBa
------------------------------------------------------------------------------u*>i MultiHome
0
65551:31
1
192.0.2.1
200
No As-Path
u*>i VPWS
0
65551:31
192.0.2.1
1
1
200
No As-Path
2
131069
------------------------------------------------------------------------------Routes : 2
===============================================================================

A:PE-2>config>service# show router bgp routes l2-vpn rd 65551:33


===============================================================================
BGP Router ID:192.0.2.2
AS:65536
Local AS:65536
===============================================================================
Legend Status codes : u - used, s - suppressed, h - history, d - decayed, * - valid
Origin codes : i - IGP, e - EGP, ? - incomplete, > - best, b - backup
===============================================================================
BGP L2VPN Routes
===============================================================================
Flag RouteType
Prefix
MED
RD
SiteId
Label
Nexthop
VeId
BlockSize
LocalPref
As-Path
BaseOffset
vplsLabelBa
------------------------------------------------------------------------------u*>i MultiHome
0
65551:33
1
192.0.2.3
10
No As-Path
u*>i VPWS
0
65551:33
192.0.2.3
1
1
10
No As-Path
2
131068
------------------------------------------------------------------------------Routes : 2
===============================================================================
A:PE-2#

The route to PE-1 has the higher site preference, so it is selected as the target for the pseudowire.
A:PE-2# show service l2-route-table bgp-vpws detail
===============================================================================
Services: L2 Bgp-Vpws Route Information - Summary
===============================================================================
Svc Id
: 3
VeId
: 1
PW Temp Id
: 3

Page 268

Advanced Configuration Guide

BGP Virtual Private Wire Services

RD
: *65551:31
Next Hop
: 192.0.2.1
State (D-Bit) : up(0)
Path MTU
: 1514
Control Word
: 0
Seq Delivery
: 0
Status
: active
Tx Status
: active
CSV
: 0
Preference
: 200
Sdp Bind Id
: 17407:4294967289
===============================================================================

After disabling the SAP in the service on PE-1, BGP UPDATE messages are received. The VPLS/
VPWS message received on PE-2 from PE-1 shows in the CSV that the access circuit is down (the
CSV has the most-significant bit set to 1 (0x80)), so PE-2 selects the update from PE-3 to create
the pseudowire. The BGP-MH update received by PE-2 from PE-1 also shows that the local site is
down as indicated by the flags=D.
Note in the debug output below,

BGP MH (multi-homing) entry uses encap-type=19.

BGP VPWS entry uses encap-type=5 (Ethernet raw mode).

DEBUG #2001 Base Peer 1: 192.0.2.5


"Peer 1: 192.0.2.5: UPDATE
Peer 1: 192.0.2.5 - Received BGP UPDATE:
Withdrawn Length = 0
Total Path Attr Length = 90
Flag: 0x90 Type: 14 Len: 32 Multiprotocol Reachable NLRI:
Address Family L2VPN
NextHop len 4 NextHop 192.0.2.1
[VPLS/VPWS] veid: 1, vbo: 2, vbs: 1, label-base: 131069, RD 65551:31, csv: 0x80
Flag: 0x40 Type: 1 Len: 1 Origin: 0
Flag: 0x40 Type: 2 Len: 0 AS Path:
Flag: 0x80 Type: 4 Len: 4 MED: 0
Flag: 0x40 Type: 5 Len: 4 Local Preference: 0
Flag: 0x80 Type: 9 Len: 4 Originator ID: 192.0.2.1
Flag: 0x80 Type: 10 Len: 4 Cluster ID:
1.1.1.1
Flag: 0xc0 Type: 16 Len: 16 Extended Community:
target:65551:31
l2-vpn/vrf-imp:Encap=5: Flags=D: MTU=1514: PREF=200
"
5 2013/04/26 15:30:26.74 UTC MINOR: DEBUG #2001 Base Peer 1: 192.0.2.5
"Peer 1: 192.0.2.5: UPDATE
Peer 1: 192.0.2.5 - Received BGP UPDATE:
Withdrawn Length = 0
Total Path Attr Length = 86
Flag: 0x90 Type: 14 Len: 28 Multiprotocol Reachable NLRI:
Address Family L2VPN
NextHop len 4 NextHop 192.0.2.1
[MH] site-id: 1, RD 65551:31

Advanced Configuration Guide

Page 269

Configuration

Flag: 0x40 Type: 1 Len: 1 Origin: 0


Flag: 0x40 Type: 2 Len: 0 AS Path:
Flag: 0x80 Type: 4 Len: 4 MED: 0
Flag: 0x40 Type: 5 Len: 4 Local Preference: 0
Flag: 0x80 Type: 9 Len: 4 Originator ID: 192.0.2.1
Flag: 0x80 Type: 10 Len: 4 Cluster ID:
1.1.1.1
Flag: 0xc0 Type: 16 Len: 16 Extended Community:
target:65551:31
l2-vpn/vrf-imp:Encap=19: Flags=D: MTU=0: PREF=200
"

The result can be shown on PE-2 as now the spoke SDP is up (active) to PE-3.
A:PE-2# show service l2-route-table bgp-vpws detail
===============================================================================
Services: L2 Bgp-Vpws Route Information - Summary
===============================================================================
Svc Id
: 3
VeId
: 1
PW Temp Id
: 3
RD
: *65551:33
Next Hop
: 192.0.2.3
State (D-Bit) : up(0)
Path MTU
: 1514
Control Word
: 0
Seq Delivery
: 0
Status
: active
Tx Status
: active
CSV
: 0
Preference
: 10
Sdp Bind Id
: 17407:4294967288
===============================================================================

Page 270

Advanced Configuration Guide

BGP Virtual Private Wire Services

Dual Homed BGP VPWS with Active/Standby Pseudowire


The second method for BGP VPWS pseudowire redundancy is an active/standby configuration.
While in the solution with one pseudowire, the redundant nodes use the same VE-ID for the
remote PE and different preferences; in the active/standby solution, the redundant nodes use
different VE-IDs for the remote PE and different preferences. The node connecting to both
pseudowires (PE-2 in this example) has both remote VE-IDs configured. This allows for faster
failover as the standby pseudowire is instantiated in addition to the active pseudowire. If more
than two applicable BGP updates are received, at most one standby pseudowire is created (based
on the BGP VPWS tie breaking rules).
The diagram below shows a setup where an Epipe is configured on each PE. Site B is dual-homed
to PE-1 and PE-3 with the remote PE-2 connected to site A; each site connection uses a SAP. The
active/standby pseudowires using Ethernet Raw Mode encapsulation connect PE-2 to PE-1 and
PE-3. The pseudowires are signaled using BGP VPWS over tunnel LSPs between the PEs.
Ve-id=1
Mh-id=1
Site-preference=200
Rd=65551:41
Rt=65551:41

PE-1

192.0.2.1

Epipe 4
Ve-id=3
Rd=65551:42
Rt=65551:41

SAP
P-4
Dual-homed
Site
192.0.2.4

192.0.2.2

SiteB

SiteA
PE-2
SAP

Blocked
Ve-id=2
Mh-id=1
Site-preference=10
Rd=65551:43
Rt=65551:41

192.0.2.3

PE-3

al_0269

Figure 49: Dual Homed BGP VPWS with Active/Standby Pseudowire

BGP multi-homing is configured for the dual-homed site B using a site-id=1. The site-preference
on PE-1 is set to 200 and to 10 on PE-3; this ensures that PE-1 will be the sites designated
forwarder. The active pseudowire from PE-2 will be created to PE-1 with the standby pseudowire

Advanced Configuration Guide

Page 271

Configuration

being created to PE-3. If PE-1 fails, or the multi-homing site fails over to PE-3, then the
pseudowire from PE-2 to PE-3 will become active (i.e., used as the data path between site A and
B).
PE-1 configuration:
A:PE-1# configure service
pw-template 3 create
exit
epipe 4 customer 1 create
bgp
route-distinguisher 65551:41
route-target export target:65551:41 import target:65551:41
pw-template-binding 3
exit
exit
bgp-vpws
ve-name "PE-1"
ve-id 1
exit
remote-ve-name "PE-2"
ve-id 2
exit
no shutdown
exit
site "siteB" create
site-id 1
sap 1/1/4:44
site-preference 200
no shutdown
exit
sap 1/1/4:44 create
exit
no shutdown
exit
exit

Page 272

Advanced Configuration Guide

BGP Virtual Private Wire Services

PE-3 configuration:
Note that the local VE-ID is 3 (different from previous example).
A:PE-3# configure service
pw-template 3 create
exit
epipe 4 customer 1 create
bgp
route-distinguisher 65551:43
route-target export target:65551:41 import target:65551:41
pw-template-binding 3
exit
exit
bgp-vpws
ve-name "PE-3"
ve-id 3
exit
remote-ve-name "PE-2"
ve-id 2
exit
no shutdown
exit
site "siteB" create
site-id 1
sap 1/1/4:44
site-preference 10
no shutdown
exit
sap 1/1/4:44 create
exit
no shutdown
exit
exit

PE-2 configuration:
Note that there are two remote VE names configured, PE-1 and PE-3 (this is the maximum
number allowed).
A:PE-2# configure service
pw-template 3 create
exit
epipe 4 customer 1 create
bgp
route-distinguisher 65551:42
route-target export target:65551:41 import target:65551:41
pw-template-binding 3
exit
exit
bgp-vpws
ve-name "PE-2"
ve-id 2
exit
remote-ve-name "PE-1"

Advanced Configuration Guide

Page 273

Configuration

ve-id 1
exit
remote-ve-name "PE-3"
ve-id 3
exit
no shutdown
exit
sap 1/1/3:44 create
exit
no shutdown
exit
exit

Compared to the single pseudowire solution, both pseudowires are signaled and up on all PEs. The
pseudowire with the higher preference is forwarding traffic (to PE-1), while the Tx Status on the
other one is set to inactive.
Verified on PE-2:
A:PE-2# show service l2-route-table bgp-vpws detail
===============================================================================
Services: L2 Bgp-Vpws Route Information - Summary
===============================================================================
Svc Id
: 4
VeId
: 1
PW Temp Id
: 3
RD
: *65551:41
Next Hop
: 192.0.2.1
State (D-Bit) : up(0)
Path MTU
: 1514
Control Word
: 0
Seq Delivery
: 0
Status
: active
Tx Status
: active
CSV
: 0
Preference
: 200
Sdp Bind Id
: 17406:4294967286
Svc Id
VeId
PW Temp Id
RD
Next Hop
State (D-Bit)
Path MTU
Control Word
Seq Delivery
Status
Tx Status
CSV
Preference
Sdp Bind Id

:
:
:
:
:
:
:
:
:
:
:
:
:
:

4
3
3
*65551:43
192.0.2.3
up(0)
1514
0
0
active
inactive
0
10
17407:4294967287

The choice of pseudowire to be used to transmit traffic from PE-2 to PE-1 can also be seen in the
endpoint created in the BGP VPWS service. Endpoints are automatically created for the

Page 274

Advanced Configuration Guide

BGP Virtual Private Wire Services

pseudowires within a BGP VPWS service regardless of whether active/standby pseudowires are
used; these endpoints are created with a system generated name that ends with the BGP VPWS
service id.
A:PE-2# show service id 4 endpoint
===============================================================================
Service 4 endpoints
===============================================================================
Endpoint name
: _tmnx_BgpVpws-4
Description
: Automatically created BGP-VPWS endpoint
Creation Origin
: bgpVpws
Revert time
: 0
Act Hold Delay
: 0
Standby Signaling Master
: false
Standby Signaling Slave
: false
Tx Active (SDP)
: 17406:4294967286
Tx Active Up Time
: 0d 00:22:39
Revert Time Count Down
: N/A
Tx Active Change Count
: 2
Last Tx Active Change
: 04/26/2013 16:15:28
------------------------------------------------------------------------------Members
------------------------------------------------------------------------------Spoke-sdp: 17406:4294967286 Prec:4
Oper Status: Up
Spoke-sdp: 17407:4294967287 Prec:4
Oper Status: Up
===============================================================================

Note that the following command has no effect on an automatically created VPWS endpoint.
tools perform service id <service-id> endpoint <endpoint-name> force-switchover

Advanced Configuration Guide

Page 275

Conclusion

Conclusion
BGP VPWS allows the delivery of Layer-2 virtual private wire services to customers where BGP
is commonly used. This example shows the configuration of single and dual-homed BGP VPWS
services together with the associated show output, which can be used to verify and troubleshoot
them.

Page 276

Advanced Configuration Guide

BGP VPLS

In This Chapter
This section describes advanced BGP VPLS configurations.
Topics in this section include:

Applicability on page 278

Summary on page 279

Overview on page 280

Configuration on page 282

Conclusion on page 313

Advanced Configuration Guide

Page 277

Applicability

Applicability
This example is applicable to all of the 7450-ESS, 7750-SR and 7710-SR series and was tested on
release 9.0.r3. There are no pre-requisites for this configuration.

Page 278

Advanced Configuration Guide

BGP VPLS

Summary
There are currently two IETF standards for the provisioning of Virtual Private LAN Services
(VPLS). RFC 4762, Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP)
Signaling, describes Label Distribution Protocol (LDP) VPLS, where VPLS pseudowires are
signaled using LDP between VPLS Provider Edge (PE) routers, either configured manually or
auto-discovered using BGP.
RFC 4761, Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling,
describes the use of Border Gateway Protocol (BGP) for both the auto-discovery of VPLS PEs and
signaling of pseudowires between such PEs.
The purpose of this section is to describe the configuration and troubleshooting for BGP-VPLS.
Knowledge of BGP-VPLS RFC 4761 architecture and functionality is assumed throughout this
section, as well as knowledge of Multi-Protocol BGP.

Advanced Configuration Guide

Page 279

Overview

Overview

RR-1

P-1

192.168.7.2/30
192.0.2.20

192.168.7.1/30

PE-1

192.168.0.1/30
192.168.0.2/30

192.0.2.10

192.168.1.1/30

192.0.2.1

192.168.2.1/30
192.168.2.2/30

192.168.1.2/30

P-2

PE-2

192.168.3.1/30
192.168.3.2/30

192.0.2.11

192.168.4.1/30

192.0.2.2

192.168.5.1/30
192.168.5.2/30

192.168.4.2/30

PE-3

P-3

192.168.6.1/30

192.0.2.3

192.168.6.1/30

192.0.2.12

BGP_VPLS_01

Figure 50: Network Topology

The network topology is displayed in Figure 50. The configuration uses seven 7750/7450/7710
Service Router (SR) nodes located in the same Autonomous System (AS). There are three
Provider Edge (PE) routers, and RR-1 will act as a Route Reflector (RR) for the AS. The PE
routers are all VPLS-aware, the Provider (P) routers are VPLS unaware and do not take part in the
BGP process.
The following configuration tasks should be completed as a pre-requisite:

Page 280

ISIS or OSPF on each of the network interfaces between the PE/P routers and RR.

MPLS should be configured on all interfaces between PE routers and P routers. MPLS is
not required between P-1 and RR-1.

LDP should be configured on interfaces between PE and P routers. It is not required


between P-1 and the RR-1.

The RSVP protocol should be enabled.

Advanced Configuration Guide

BGP VPLS

BGP VPLS
In this architecture a VPLS instance is a collection of local VPLS instances present on a number of
PEs in a provider network. In this context, any VPLS-aware PE is also known as a VPLS Edge
(VE) device.
The PEs communicate with each other at the control plane level by means of BGP updates
containing BGP-VPLS Network Layer Reachability Information (NLRI). Each update contains
enough information for a PE to determine the presence of other local VPLS instances on peering
PEs and to set-up pseudowire connectivity for data flow between peers containing a local VPLS
within the same VPLS instance. Therefore, auto-discovery and pseudowire signaling are achieved
using a single BGP update message.
Each PE within a VPLS instance is identified by a VPLS Edge identifier (ve-id) and the presence
of a VPLS instance is determined using the exchange of standard BGP extended community route
targets between PEs.
Each PE will advertise, via the route reflectors, the presence of each VPLS instance to all other
PEs, along with a block of multiplexer labels that can be used to communicate between such
instances plus a BGP next hop that determines a labelled transport tunnel between PEs.
Each VPLS instance is configured with import and export route target extended communities for
topology control, along with VE identification.

Advanced Configuration Guide

Page 281

Configuration

Configuration
The first step is to configure an MP-iBGP session between each of the PEs and the RR.
The configuration for PE-1 is as follows:
configure router bgp
group internal
family l2vpn
peer-as 65536
neighbor 192.0.2.20
exit
exit
exit all

The configuration for the other PE nodes is very similar. The IP addresses can be derived from
Figure 50.
The configuration for RR-1 is as follows:
configure router bgp
cluster 1.1.1.1
group rr-internal
family l2-vpn
peer-as 65536
neighbor 192.0.2.1
exit
neighbor 192.0.2.2
exit
neighbor 192.0.2.3
exit
exit
exit all

On PE-1, verify that the BGP session with RR-1 is established with address family l2-vpn
capability negotiated:
A:PE-1# show router bgp neighbor 192.0.2.20
===============================================================================
BGP Neighbor
===============================================================================
Peer : 192.0.2.20
Group : internal
------------------------------------------------------------------------------Peer AS
: 65536
Peer Port
: 179
Peer Address
: 192.0.2.20
Local AS
: 65536
Local Port
: 58990
Local Address
: 192.0.2.1
Peer Type
: Internal
State
: Established
Last State
: Active
Last Event
: recvKeepAlive
Last Error
: Cease
Local Family
: L2-VPN

Page 282

Advanced Configuration Guide

BGP VPLS

Remote Family
: IPv4 VPN-IPv4 L2-VPN
Hold Time
: 90
Keep Alive
: 30
Active Hold Time
: 90
Active Keep Alive
: 30
Cluster Id
: None
Preference
: 170
Num of Update Flaps : 9
Recd. Paths
: 13
IPv4 Recd. Prefixes : 0
IPv4 Active Prefixes : 0
IPv4 Suppressed Pfxs : 0
VPN-IPv4 Suppr. Pfxs : 0
VPN-IPv4 Recd. Pfxs : 0
VPN-IPv4 Active Pfxs : 0
Mc IPv4 Recd. Pfxs. : 0
Mc IPv4 Active Pfxs. : 0
Mc IPv4 Suppr. Pfxs : 0
IPv6 Suppressed Pfxs : 0
IPv6 Recd. Prefixes : 0
IPv6 Active Prefixes : 0
VPN-IPv6 Recd. Pfxs : 0
VPN-IPv6 Active Pfxs : 0
VPN-IPv6 Suppr. Pfxs : 0
L2-VPN Suppr. Pfxs
: 0
L2-VPN Recd. Pfxs
: 6
L2-VPN Active Pfxs
: 4
MVPN-IPv4 Suppr. Pfxs: 0
MVPN-IPv4 Recd. Pfxs : 0
MVPN-IPv4 Active Pfxs: 0
MDT-SAFI Suppr. Pfxs : 0
MDT-SAFI Recd. Pfxs : 0
MDT-SAFI Active Pfxs : 0
FLOW-IPV4-SAFI Suppr*: 0
FLOW-IPV4-SAFI Recd.*: 0
FLOW-IPV4-SAFI Activ*: 0
Input Queue
: 0
Output Queue
: 0
i/p Messages
: 2370
o/p Messages
: 2355
i/p Octets
: 46577
o/p Octets
: 44743
i/p Updates
: 21
o/p Updates
: 4
TTL Security
: Disabled
Min TTL Value
: n/a
Graceful Restart
: Disabled
Stale Routes Time
: n/a
Advertise Inactive
: Disabled
Peer Tracking
: Disabled
Advertise Label
: None
Auth key chain
: n/a
Disable Cap Nego
: Disabled
Peer Tracking
: Disabled
Auth key chain
: n/a
Flowspec Validate
: Enabled
L2 VPN Cisco Interop : Disabled
Local Capability
: RtRefresh MPBGP 4byte ASN
Remote Capability
: RtRefresh MPBGP 4byte ASN
Import Policy
: None Specified / Inherited
Export Policy
: None Specified / Inherited
------------------------------------------------------------------------------Neighbors : 1

On RR-1, show that BGP sessions with each PE are established, and have a negotiated the l2-vpn
address family capability.
B:RR-1# show router bgp summary
===============================================================================
BGP Router ID:192.0.2.50
AS:65536
Local AS:65536
===============================================================================
BGP Admin State
: Up
BGP Oper State
: Up
Total Peer Groups
: 1
Total Peers
: 3
Total BGP Paths
: 18
Total Path Memory
: 2352
Total IPv4 Remote Rts
: 0
Total IPv4 Rem. Active Rts : 0
Total IPv6 Remote Rts
: 0
Total IPv6 Rem. Active Rts : 0
Total Supressed Rts
: 0
Total Hist. Rts
: 0
Total Decay Rts
: 0
Total VPN Peer Groups
: 0
Total VPN Local Rts
: 0
Total VPN-IPv4 Rem. Rts : 0

Advanced Configuration Guide

Total VPN Peers

: 0

Total VPN-IPv4 Rem. Act. Rts: 0

Page 283

Configuration

Total VPN-IPv6 Rem. Rts : 0


Total VPN-IPv6 Rem. Act. Rts: 0
Total L2-VPN Rem. Rts
: 15
Total L2VPN Rem. Act. Rts
: 0
Total VPN Supp. Rts
: 0
Total VPN Hist. Rts
: 0
Total VPN Decay Rts
: 0
Total MVPN-IPv4 Rem Rts : 0
Total MVPN-IPv4 Rem Act Rts : 0
Total MDT-SAFI Rem Rts : 0
Total MDT-SAFI Rem Act Rts : 0
Total MSPW Rem Rts
: 0
Total MSPW Rem Act Rts
: 0
Total FlowIpv4 Rem Rts : 0
Total FlowIpv4 Rem Act Rts : 0
===============================================================================
BGP Summary
===============================================================================
Neighbor
AS PktRcvd InQ Up/Down
State|Rcv/Act/Sent (Addr Family)
PktSent OutQ
------------------------------------------------------------------------------192.0.2.1
65536
10477
0 16h43m29s 5/0/15 (L2VPN)
10981
0
192.0.2.2
65536
10776
0 16h43m29s 5/0/15 (L2VPN)
11022
0
192.0.2.3
65536
10819
0 16h43m29s 5/0/15 (L2VPN)
10926
0
-------------------------------------------------------------------------------

Configure a full mesh of RSVP-TE LSPs between PE routers.


The MPLS interface and LSP configuration for PE-1 are:
A:PE-1# configure router mpls
interface "system"
exit
interface "int-PE-1-P-1"
exit
interface "int-PE-1-PE-2"
exit
path "loose"
no shutdown
exit
lsp "LSP-PE-1-PE-2"
to 192.0.2.2
primary "loose"
exit
no shutdown
exit
lsp "LSP-PE-1-PE-3"
to 192.0.2.3
primary "loose"
exit
no shutdown
exit
no shutdown

The MPLS and LSP configuration for PE-2 and PE-3 are similar to that of PE-1 with the
appropriate interfaces and LSP names configured.

Page 284

Advanced Configuration Guide

BGP VPLS

BGP VPLS PE Configuration


Pseudowire Templates
Pseudowire templates are used by BGP to dynamically instantiate SDP bindings, for a given
service, to signal the egress service de-multiplexer labels used by remote PEs to reach the local
PE.
The template determines the signaling parameters of the pseudowire, control word presence,
MAC-pinning, filters etc., plus other usage characteristics such as split horizon groups.
The MPLS transport tunnel between PEs can be signaled using LDP or RSVP-TE.
LDP based pseudowires can be automatically instantiated. RSVP-TE based SDPs have to be preprovisioned.

Pseudowire Templates for Auto-SDP Creation Using LDP


In order to use an LDP transport tunnel for data flow between PEs, it is necessary for link layer
LDP to be configured between all PEs/Ps, so that a transport label for each PEs system interface
is available.
A:PE-1# configure router ldp
interface-parameters
interface "int-PE-1-P-1"
exit
interface "int-PE-1-PE-2"
exit
exit
targeted-session
exit

Using this mechanism SDPs can be auto-instantiated with SDP-ids starting at the higher end of the
SDP numbering range, such as 17407. Any subsequent SDPs created use SDP-ids decrementing
from this value.
A pseudowire template is required containing a split horizon group. Each SDP created with this
template is contained within a split horizon group so that traffic cannot be forwarded between
them.
A:PE-1# configure service
pw-template 1 create
split-horizon-group "vpls-shg"
exit
exit

Advanced Configuration Guide

Page 285

Configuration

The pseudowire template also has the following options available when used for BGP-VPLS:
*A:PE-1# configure service pw-template
[no] controlword
force-vlan-vc-forwarding
vc-type {ether | vlan}

The control word will determine whether the C flag is set in the Layer 2 extended
community and, therefore, if a control word is used in the pseudowire.

The encap type in the Layer 2 extended community is always 19 (VPLS encap), therefore,
the vc-type will always be ether regardless of the configured value on the vc-type.

The force-vlan-vc-forwarding command will add a tag (equivalent to vc-type vlan) and
will allow for customer QoS transparency (dot1p+DE bits).

Pseudowire Templates for Provisioned SDPs using RSVP-TE


To use an RSVP-TE tunnel as transport between PEs, it is necessary to bind the RSVP-TE LSP
between PEs to an SDP.
SDP creation from PE-1 to PE-2 is shown below:
A:PE-1# configure service sdp 33 mpls create
description "from-192.0.2.1-id-33"
far-end 192.0.2.2
lsp "LSP-PE-1-PE-2"
signaling bgp
keep-alive
shutdown
exit
no shutdown

Note that the signaling bgp parameter is required for BGP-VPLS to be able to use this SDP.
Conversely, SDPs that are bound to RSVP-based LSPs with signaling set to the default value of
tldp will not be used as SDPs within BGP-VPLS.

Page 286

Advanced Configuration Guide

BGP VPLS

BGP VPLS Using Auto-Provisioned SDPs

SDP

PE-1
192.0.2.1

RR-1

CE

SDP
192.0.2.20

SDP

PE-3
VPLS 1
192.0.2.3

CE

SDP

SDP

PE-2
SDP

192.0.2.2

CE
BGP_VPLS_02

Figure 51: BGP VPLS Using Auto-Provisioned SDPs

Figure 51 shows a VPLS instance where SDPs are auto-provisioned. In this case, the transport
tunnels are LDP signaled.
The following output shows the configuration required on PE-1 for a BGP-VPLS service using a
pseudowire template configured for auto-provisioning of SDPs.
A:PE-1# configure service vpls 1
bgp
route-distinguisher 65536:1
route-target export target:65536:1 import target:65536:1
pw-template-bind 1
exit
bgp-vpls
max-ve-id 10
ve-name PE-1
ve-id 1
exit
no shutdown
exit
stp
shutdown
exit
sap 1/2/1:1.0 create
exit
no shutdown
exit all

The bgp context specifies parameters which are valid for all of the VPLS BGP applications, such
as BGP-multi-homing, BGP-auto-discovery as well as BGP-VPLS.

Advanced Configuration Guide

Page 287

Configuration

Within the bgp context, parameters are configured that are used by neighboring PEs to determine
membership of a given VPLS instance, such as the auto-discovery of PEs containing the same
VPLS instance; the route-distinguisher is configured, along with the route target extended
communities.
Route target communities are used to determine membership of a given VPLS instance. Note that
the import route target at the BGP level is mandatory. The pseudowire template bind is then
applied by the service manager on the received routes matching the route target value.
Also within the bgp-vpls context, the signaling parameters are configured. These determine the
service labels required for the data plane of the VPLS instance.
The VPLS edge ID (ve-id) is a numerical value assigned to each PE within a VPLS instance. This
value should be unique for a given VPLS instance, no two PEs within the same instance should
have the same ve-id values.
Note that a more specific route target can be applied to a pseudowire template in order to define a
specific pseudowire topology, rather than only a full mesh, using the command within the bgp
context:
pw-template template-id [split-horizon-group groupname] [import-rt import-rt-value (up to 5
max)]
It is also worth noting that changes to the import policies are not taken once the pseudowire has
been setup (changes on route-target are refreshed though). Pseudowire templates can be reevaluated with the command tools perform eval-pw-template. The eval-pw-template command
checks whether all the bindings using this pseudowire template policy are still meant to use this
policy.
If the policy has changed and allow-service-impact is true, then the old binding is removed and it
is re-added with the new template.

Page 288

Advanced Configuration Guide

BGP VPLS

VE-ID and BGP Label Allocations


The choice of ve-id is crucial in ensuring efficient allocation of de-multiplexer labels. The most
efficient choice is for ve-ids to be allocated starting at 1 and incrementing for each PE as the
following section explains.
The max-ve-id value determines the range of the ve-id value that can be configured. If a PE
receives a BGP-VPLS update containing a ve-id with a greater value than the configured max-veid, then the update is dropped and no service labels are installed for this ve-id.
The max-ve-id command also checks the locally-configured ve-id, and prevents a higher value
from being used.
Each PE allocates blocks of labels per VPLS instance to remote PEs, in increments of eight labels.
It achieves this by advertising three parameters in a BGP update message,

A label base (LB) which is the lowest label in the block

A VE Block size (VBS) which is always eight labels, and cannot be changed

A VE base offset (VBO).

This defines a block of labels in the range (LB, LB+1, ..., LB+VBS-1).
As an example, if the label base (LB) = 131055, then the range for the block is 131055 to 131062,
which is exactly eight labels, as per the block size.
(The last label in the block is calculated as 131055+8-1 = 131062)
The label allocated by the PE to each remote PE within the VPLS is chosen from this block and is
determined by its ve-id. In this way, each remote PE has a unique de-multiplexer label for that
VPLS.
To reduce label wastage, contiguous ve-ids in the range (N..N+7) per VPLS should be chosen,
where N>0.
Assuming a collection of PEs with contiguous ve-ids, the following labels will be chosen by PEs
from the label block allocated by PE-1 which has a ve-id =1.

Table 5: VE-IDs and Labels


VE-ID

Label

131056

131057

131058

Advanced Configuration Guide

Page 289

Configuration

Table 5: VE-IDs and Labels (Continued)


VE-ID

Label

131059

131060

131061

131062

This shows that the label allocated to a given PE is (LB+veid-1). The 1 is the VE block offset
(VBO).
This means that the label allocated to a PE router within the VPLS can now be written as (LB +
veid - VBO), which means that (ve-id - VBO) calculation must always be at least zero and be less
than the block size, which is always 8.
For ve-id 8, a label will be allocated from this block.
For the next block of 8 ve-ids (ve-id 9 to ve-id 16) a new block of 8 labels must be allocated, so a
new BGP update is sent, with a new label base, and a block offset of 9.
Table 6 shows how the choice of ve-ids can affect the number of label blocks allocated, and hence
the number of labels:

Table 6: VE-IDs and Number of Labels

Page 290

VE-ID

Block Offset

Labels Allocated

1-8

9-16

17-24

17

25-32

25

33-40

33

41-48

41

49-56

49

Advanced Configuration Guide

BGP VPLS

This shows that the most efficient use of labels occurs when the ve-ids for a set of PEs are chosen
from the same block offset.
Note that if ve-ids are chosen that map to different block offsets, then each PE will have to send
multiple BGP updates to signal service labels. Each PE sends label blocks in BGP updates to each
of its BGP neighbors for all label blocks in which at least one ve-id has been seen by this PE (it
does not advertise label blocks which do not contain an active ve-id, where active ve-id means the
ve-id of this PE or any other PE in this VPLS).
The max-ve-id must be configured first, and determines the maximum value of the ve-id that can
be configured within the PE. The ve-id value cannot be higher than this within the PE
configuration, ve-id <= max-ve-id. Similarly, if the ve-id within a received NLRI is higher than
the max-ve-id value, it will not be accepted as valid consequently the max-ve-id configured on all
PEs must be greater than or equal to any ve-id used in the VPLS.
Only one ve-id value can be configured. If the ve-id value is changed, BGP withdraws the NLRI
and sends a route-refresh.
Note that if the same ve-id is used in different PEs for the same VPLS, a Designated Forwarder
election takes place.
Executing the shutdown command triggers an MP-UNREACH-NLRI from the PE to all BGP
peers
The no shutdown command triggers an MP-REACH-NLRI to the same peers.

Advanced Configuration Guide

Page 291

Configuration

PE-2 Service Creation


On PE-2 create VPLS service using pseudowire template 1. In order to make the label allocation
more efficient, PE-2 has been allocated a ve-id value of 2. For completeness, the pseudowire
template is also shown.
A:PE-2# configure service
pw-template 1 create
split-horizon-group "vpls-shg"
exit
exit
vpls 1 customer 1 create
bgp
route-distinguisher 65536:1
route-target export target:65536:1 import target:65536:1
pw-template-binding 1
exit
exit
bgp-vpls
max-ve-id 10
ve-name PE-2
ve-id 2
exit
no shutdown
exit
stp
shutdown
exit
service-name "VPLS service-174 PE-2 (192.0.2.2)"
sap 1/1/1:1.0 create
exit
no shutdown
exit

Note that the max-ve-id value is set to 10 to allow an increase in the number of PEs that could be
a part of this VPLS instance.

Page 292

Advanced Configuration Guide

BGP VPLS

PE-3 Service Creation


Create VPLS instance on PE-3, using a ve-id value of 3.
B:PE-3# configure service
pw-template 1 create
split-horizon-group "vpls-shg"
exit
exit
vpls 1 customer 1 create
bgp
route-distinguisher 65536:1
route-target export target:65536:1 import target:65536:1
pw-template-binding 1
exit
exit
bgp-vpls
max-ve-id 10
ve-name PE-3
ve-id 3
exit
no shutdown
exit
stp
shutdown
exit
sap 1/1/4:1.0 create
exit
no shutdown
exit

Advanced Configuration Guide

Page 293

Configuration

PE-1 Service Operation Verification


Verify that the BGP-VPLS site is enabled on PE-1
A:PE-1# show service id 1 bgp-vpls
===============================================================================
BGP VPLS Information
===============================================================================
Max Ve Id
: 10
Admin State
: Enabled
VE Name
: PE-1
VE Id
: 1
===============================================================================
A:PE-1

Verify that the service is operationally up on PE-1


A:PE-1# show service id 1 base
===============================================================================
Service Basic Information
===============================================================================
Service Id
: 1
Vpn Id
: 0
Service Type
: VPLS
Name
: VPLS service-174 PE-1 (192.0.2.1)
Description
: (Not Specified)
Customer Id
: 1
Last Status Change: 07/10/2011 17:27:26
Last Mgmt Change : 07/10/2011 17:34:58
Admin State
: Up
Oper State
: Up
MTU
: 1514
Def. Mesh VC Id
: 1
SAP Count
: 1
SDP Bind Count
: 2
Snd Flush on Fail : Disabled
Host Conn Verify : Disabled
Propagate MacFlush: Disabled
Per Svc Hashing
: Disabled
Allow IP Intf Bind: Disabled
Def. Gateway IP
: None
Def. Gateway MAC : None
Temp Flood Time
: Disabled
Temp Flood
: Inactive
Temp Flood Chg Cnt: 0
------------------------------------------------------------------------------Service Access & Destination Points
------------------------------------------------------------------------------Identifier
Type
AdmMTU OprMTU Adm Opr
------------------------------------------------------------------------------sap:1/2/1:1.0
qinq
1522
1522
Up
Up
sdp:17404:4294967288 SB(192.0.2.2)
BgpVpls
0
9190
Up
Up
sdp:17406:4294967292 SB(192.0.2.3)
BgpVpls
0
9190
Up
Up
===============================================================================
A:PE-1#

The SAP and SDPs are all operationally up. Note that the SB flags signify Spoke and BGP.
Further verification can be seen below where the ingress labels for PE-2 and PE-3, the labels
allocated by PE-1, can be seen.
A:PE-1# show service id 1 sdp
===============================================================================

Page 294

Advanced Configuration Guide

BGP VPLS

Services: Service Destination Points


===============================================================================
SdpId
Type IP address
Adm
Opr
I.Lbl
E.Lbl
------------------------------------------------------------------------------17404:4294967288 Bgp* 192.0.2.2
Up
Up
131064
131056
17406:4294967292 Bgp* 192.0.2.3
Up
Up
131065
131056
------------------------------------------------------------------------------Number of SDPs : 2
------------------------------------------------------------------------------A:PE-1#

As can be seen from the following output, a BGP-VPLS NLRI update is sent to the route reflector
(192.0.2.20) and is received by each PE.
The following debug trace from PE-1 shows the BGP NLRI update for VPLS 1 sent by PE-1 to
the route reflector.
DEBUG #2001 Base Peer 1: 192.0.2.20
"Peer 1: 192.0.2.20: UPDATE
Peer 1: 192.0.2.20 - Send BGP UPDATE:
Withdrawn Length = 0
Total Path Attr Length = 72
Flag: 0x40 Type: 1 Len: 1 Origin: 0
Flag: 0x40 Type: 2 Len: 0 AS Path:
Flag: 0x80 Type: 4 Len: 4 MED: 0
Flag: 0x40 Type: 5 Len: 4 Local Preference: 100
Flag: 0xc0 Type: 16 Len: 16 Extended Community:
target:65536:1
l2-vpn:Encap=19: Flags=none: MTU=1514
Flag: 0x90 Type: 14 Len: 28 Multiprotocol Reachable NLRI:
Address Family L2VPN
NextHop len 4 NextHop 192.0.2.1
[VPLS] veid: 1, vbo: 1, vbs: 8, label-base: 131063, RD 65536:1

Note the presence of the control flags within the extended community which indicates the status of
the VPLS instance.
New control flags have been introduced to allow support for BGP multi-homing, D indicates that
all attachment circuits are Down, or the VPLS is shutdown. The flags are used in BGP Multihoming when determining which PEs are designated forwarders.
When flags=none, then all attachment circuits are up. In the example above no flags are present,
but should all SAPs become operationally down, then the following debug would be seen:
DEBUG #2001 Base Peer 1: 192.0.2.20
"Peer 1: 192.0.2.20: UPDATE
Peer 1: 192.0.2.20 - Send BGP UPDATE:
Withdrawn Length = 0
Total Path Attr Length = 72
Flag: 0x40 Type: 1 Len: 1 Origin: 0
Flag: 0x40 Type: 2 Len: 0 AS Path:
Flag: 0x80 Type: 4 Len: 4 MED: 0
Flag: 0x40 Type: 5 Len: 4 Local Preference: 100
Flag: 0xc0 Type: 16 Len: 16 Extended Community:

Advanced Configuration Guide

Page 295

Configuration

target:65536:1
l2-vpn:Encap=19: Flags=D: MTU=1514
Flag: 0x90 Type: 14 Len: 28 Multiprotocol Reachable NLRI:
Address Family L2VPN
NextHop len 4 NextHop 192.0.2.1
[VPLS] veid: 1, vbo: 1, vbs: 8, label-base: 131063, RD 65536:1

The BGP VPLS signaling parameters are also present, namely the ve-id of the PE within the
VPLS instance, the VBO and VBS, and the label base. The target indicates the VPLS instance,
which must be matched against the import route targets of the receiving PEs.
The signaling parameters can be seen within the BGP update with following command:
A:PE-1# show router bgp routes l2-vpn rd 65536:1 hunt
------------------------------------------------------------------------------RIB Out Entries
------------------------------------------------------------------------------Route Type
: VPLS
Route Dist.
: 65536:1
VeId
: 1
Block Size
: 8
Base Offset
: 1
Label Base
: 131063
Nexthop
: 192.0.2.1
To
: 192.0.2.20
Res. Nexthop
: n/a
Local Pref.
: 100
Interface Name : NotAvailable
Aggregator AS : None
Aggregator
: None
Atomic Aggr.
: Not Atomic
MED
: 0
Community
: target:65536:1 l2-vpn:Encap=19: Flags=none: MTU=1514
Cluster
: No Cluster Members
Originator Id : None
Peer Router Id : 192.0.2.20
Origin
: IGP
AS-Path
: No As-Path
------------------------------------------------------------------------------Routes : 4
...
===============================================================================
A:PE-1#

In this configuration example, PE-1 (192.0.2.1) with ve-id =1 has sent an update with base offset
(VBO) =1, block size (VBS) = 8 and label base 131063. This means that labels 131063 (LB) to
131070 (LB+VBS-1) are available as de-multiplexer labels, egress labels to be used to reach PE-1
for VPLS 1.
PE-2 receives this update from PE-1. This is seen as a valid VPLS BGP route from PE-1 through
the route reflector with nexthop 192.0.2.1.
A:PE-2# show router bgp routes l2-vpn rd 65536:1
===============================================================================
BGP Router ID:192.0.2.11
AS:65536
Local AS:65536
===============================================================================
Legend Status codes : u - used, s - suppressed, h - history, d - decayed, * - valid
Origin codes : i - IGP, e - EGP, ? - incomplete, > - best
===============================================================================

Page 296

Advanced Configuration Guide

BGP VPLS

BGP L2VPN Routes


===============================================================================
Flag RouteType
Prefix
MED
RD
SiteId
VPNLabel
Nexthop
VeId
BlockSize
LocalPref
As-Path
BaseOffset
vplsLabelB*
------------------------------------------------------------------------------u*>i VPLS
0
65536:1
192.0.2.1
1
8
100
No As-Path
1
131063
i
VPLS
0
65536:1
192.0.2.2
2
8
100
No As-Path
1
131056
u*>i VPLS
0
65536:1
192.0.2.3
3
8
100
No As-Path
1
131056
------------------------------------------------------------------------------Routes : 3
===============================================================================
A:PE-2#

PE-2 uses this information in conjunction with its own ve-id to calculate the egress label towards
PE-1, using the condition VBO ve-id < (VBO+VBS).
The ve-id of PE-2 is in the Label Block covered by VBO =1, thus,
Label calculation = label base + local ve-id Base offset
= 131063 + 2 -1
egress label used = 131064
This is verified using the following command on PE-2 where the egress label toward PE-1
(192.0.2.1) is 131064.
A:PE-2# show service id 1 sdp
===============================================================================
Services: Service Destination Points
===============================================================================
SdpId
Type IP address
Adm
Opr
I.Lbl
E.Lbl
------------------------------------------------------------------------------17400:4294967236 Bgp* 192.0.2.1
Up
Up
131056
131064
17405:4294967261 Bgp* 192.0.2.3
Up
Up
131058
131057
------------------------------------------------------------------------------B:PE-2#

PE-3 also receives this update from PE-1 by the route reflector. This is seen as a valid VPLS BGP
route from PE-1 with nexthop 192.0.2.1.
B:PE-3# show router bgp routes l2-vpn rd 65536:1
===============================================================================
BGP Router ID:192.0.2.3
AS:65536
Local AS:65536
===============================================================================
Legend -

Advanced Configuration Guide

Page 297

Configuration

Status codes : u - used, s - suppressed, h - history, d - decayed, * - valid


Origin codes : i - IGP, e - EGP, ? - incomplete, > - best
===============================================================================
BGP L2VPN Routes
===============================================================================
Flag RouteType
Prefix
MED
RD
SiteId
VPNLabel
Nexthop
VeId
BlockSize
LocalPref
As-Path
BaseOffset
vplsLabelB*
------------------------------------------------------------------------------u*>i VPLS
0
65536:1
192.0.2.1
1
8
100
No As-Path
1
131063
u*>i VPLS
0
65536:1
192.0.2.2
2
8
100
No As-Path
1
131056
i
VPLS
0
65536:1
192.0.2.3
3
8
100
No As-Path
1
131056
------------------------------------------------------------------------------Routes : 3
===============================================================================
B:PE-3#

The ve-id of PE-3 is also in the label block covered by block offset VBO =1.
Label calculation = label base + local ve-id VBO
= 131063 + 3 -1
Egress label used = 131065
This is verified using the following command on PE-3 where egress label towards 192.0.2.1 is
131065.
B:PE-3# show service id 1 sdp
===============================================================================
Services: Service Destination Points
===============================================================================
SdpId
Type IP address
Adm
Opr
I.Lbl
E.Lbl
------------------------------------------------------------------------------17399:4294967271 Bgp* 192.0.2.1
Up
Up
131056
131065
17404:4294967290 Bgp* 192.0.2.2
Up
Up
131057
131058
------------------------------------------------------------------------------Number of SDPs : 2
------------------------------------------------------------------------------===============================================================================
B:PE-3#

Page 298

Advanced Configuration Guide

BGP VPLS

PE-2 Service Operation Verification


For completeness, verify the service is operationally up on PE-2.
.A:PE-2# show service id 1 base
.===============================================================================
Service Basic Information
===============================================================================
Service Id
: 1
Vpn Id
: 0
Service Type
: VPLS
Name
: VPLS service-174 PE-2 (192.0.2.2)
Description
: (Not Specified)
Customer Id
: 1
Last Status Change: 07/08/2011 22:11:17
Last Mgmt Change : 07/10/2011 22:10:02
Admin State
: Up
Oper State
: Up
MTU
: 1514
Def. Mesh VC Id
: 1
SAP Count
: 1
SDP Bind Count
: 2
Snd Flush on Fail : Disabled
Host Conn Verify : Disabled
Propagate MacFlush: Disabled
Per Svc Hashing
: Disabled
Allow IP Intf Bind: Disabled
Def. Gateway IP
: None
Def. Gateway MAC : None
Temp Flood Time
: Disabled
Temp Flood
: Inactive
Temp Flood Chg Cnt: 0
------------------------------------------------------------------------------Service Access & Destination Points
------------------------------------------------------------------------------Identifier
Type
AdmMTU OprMTU Adm Opr
------------------------------------------------------------------------------sap:1/1/1:1.0
qinq
1522
1522
Up
Up
sdp:17400:4294967236 SB(192.0.2.1)
BgpVpls
0
9190
Up
Up
sdp:17405:4294967261 SB(192.0.2.3)
BgpVpls
0
9190
Up
Up
===============================================================================

Advanced Configuration Guide

Page 299

Configuration

PE-2 De-multiplexer Label Calculation


In the same way that PE-1 allocates a label base (LB), block size (VBS), and base offset (VBO),
PE-2 also allocates the same parameters for PE-1 and PE-3 to calculate the egress service label
required to reach PE-2.
A:PE-2# show router bgp routes l2-vpn rd 65536:1 hunt
------------------------------------------------------------------------------RIB Out Entries
------------------------------------------------------------------------------Route Type
: VPLS
Route Dist.
: 65536:1
VeId
: 2
Block Size
: 8
Base Offset
: 1
Label Base
: 131056
Nexthop
: 192.0.2.2
To
: 192.0.2.20
Res. Nexthop
: n/a
Local Pref.
: 100
Interface Name : NotAvailable
Aggregator AS : None
Aggregator
: None
Atomic Aggr.
: Not Atomic
MED
: 0
Community
: target:65536:1 l2-vpn:Encap=19: Flags=none: MTU=1514
Cluster
: No Cluster Members
Originator Id : None
Peer Router Id : 192.0.2.50
Origin
: IGP
AS-Path
: No As-Path
------------------------------------------------------------------------------Routes : 4
===============================================================================
A:PE-2#

This is verified using the following command on PE-1 to show the egress label towards PE-2
(192.0.2.2) where the egress label towards PE-2 = 131056 + 1 -1 = 131056
A:PE-1# show service id 1 sdp
===============================================================================
Services: Service Destination Points
===============================================================================
SdpId
Type IP address
Adm
Opr
I.Lbl
E.Lbl
------------------------------------------------------------------------------17404:4294967288 Bgp* 192.0.2.2
Up
Up
131064
131056
17406:4294967292 Bgp* 192.0.2.3
Up
Up
131065
131056
------------------------------------------------------------------------------Number of SDPs : 2
------------------------------------------------------------------------------A:PE-1#

This is also verified using the following command on PE-3 to show the egress label towards PE-2
(192.0.2.2) where the egress label towards PE-2 = 131056 + 3 -1 = 131058.
B:PE-3# show service id 1 sdp
===============================================================================
Services: Service Destination Points
===============================================================================
SdpId
Type IP address
Adm
Opr
I.Lbl
E.Lbl
------------------------------------------------------------------------------17399:4294967271 Bgp* 192.0.2.1
Up
Up
131056
131065

Page 300

Advanced Configuration Guide

BGP VPLS

17404:4294967290 Bgp* 192.0.2.2


Up
Up
131057
131058
------------------------------------------------------------------------------Number of SDPs : 2
------------------------------------------------------------------------------B:PE-3#

PE-3 Service Operation Verification


Verify service is operationally up on PE-3:
A:PE-3#show service id 1 base
===============================================================================
Service Basic Information
===============================================================================
Service Id
: 1
Vpn Id
: 0
Service Type
: VPLS
Name
: VPLS service-174 PE-3 (192.0.2.3)
Description
: (Not Specified)
Customer Id
: 1
Last Status Change: 06/24/2011 10:38:26
Last Mgmt Change : 06/26/2011 10:21:33
Admin State
: Up
Oper State
: Up
MTU
: 1514
Def. Mesh VC Id
: 1
SAP Count
: 1
SDP Bind Count
: 2
Snd Flush on Fail : Disabled
Host Conn Verify : Disabled
Propagate MacFlush: Disabled
Per Svc Hashing
: Disabled
Allow IP Intf Bind: Disabled
Def. Gateway IP
: None
Def. Gateway MAC : None
Temp Flood Time
: Disabled
Temp Flood
: Inactive
Temp Flood Chg Cnt: 0
------------------------------------------------------------------------------Service Access & Destination Points
------------------------------------------------------------------------------Identifier
Type
AdmMTU OprMTU Adm Opr
------------------------------------------------------------------------------sap:1/1/4:1.0
qinq
1522
1522
Up
Up
sdp:17399:4294967271 SB(192.0.2.1)
BgpVpls
0
9190
Up
Up
sdp:17404:4294967290 SB(192.0.2.2)
BgpVpls
0
9190
Up
Up
===============================================================================
B:PE-3#
B:PE-3# show service id 1 sdp
===============================================================================
Services: Service Destination Points
===============================================================================
SdpId
Type IP address
Adm
Opr
I.Lbl
E.Lbl
------------------------------------------------------------------------------17399:4294967271 Bgp* 192.0.2.1
Up
Up
131056
131065
17404:4294967290 Bgp* 192.0.2.2
Up
Up
131057
131058
------------------------------------------------------------------------------Number of SDPs : 2
------------------------------------------------------------------------------...
===============================================================================
B:PE-3#

Advanced Configuration Guide

Page 301

Configuration

PE-3 De-Multiplexer Label Verification


PE-3 also allocates the required parameters for PE-1 and PE-2 to calculate the egress service label
required to reach PE-3.
This is verified using the following command on PE-1 to show the egress label towards PE-3
(192.0.2.3) where egress label towards PE-2 = 131056.
A:PE-1# show service id 1 sdp
===============================================================================
Services: Service Destination Points
===============================================================================
SdpId
Type IP address
Adm
Opr
I.Lbl
E.Lbl
------------------------------------------------------------------------------17404:4294967288 Bgp* 192.0.2.2
Up
Up
131064
131056
17406:4294967292 Bgp* 192.0.2.3
Up
Up
131065
131056
------------------------------------------------------------------------------Number of SDPs : 2
------------------------------------------------------------------------------===============================================================================
A:PE-1#

This is also verified using the following command on PE-2 to show the egress label towards PE-3
(192.0.2.3) which is using auto-provisioned SDP 17405.
A:PE-2# show service id 1 sdp
===============================================================================
Services: Service Destination Points
===============================================================================
SdpId
Type IP address
Adm
Opr
I.Lbl
E.Lbl
------------------------------------------------------------------------------17400:4294967236 Bgp* 192.0.2.1
Up
Up
131056
131064
17405:4294967261 Bgp* 192.0.2.3
Up
Up
131058
131057
------------------------------------------------------------------------------Number of SDPs : 2
------------------------------------------------------------------------------A:PE-2#

This example has shown that for VPLS instance with 3 PEs, not all labels allocated by a PE will be
used by remote PEs as de-multiplexor service labels. There will be some wastage of label space,
so there is a necessity to choose ve-ids that keep this waste to a minimum.
The next example will show an even more wasteful use of labels by using random choice of veids.

Page 302

Advanced Configuration Guide

BGP VPLS

BGP VPLS Using Pre-Provisioned SDP


It is possible to configure BGP-VPLS instances that use RSVP-TE transport tunnels. In this case,
the SDP must be created with the MPLS LSPs mapped and with signaling set to BGP, as the
service labels are signaled using BGP. The pseudowire template configured within the BGP-VPLS
instance must use the use-provisioned-sdp keyword.
This example also examines the effect of using ve-ids that are not all within the same contiguous
block.

SDP 42

PE-1
192.0.2.1

RR-1

CE

SDP 33
192.0.2.20

SDP 38

PE-3
VPLS 2
192.0.2.3

CE

SDP 39
SDP 40

PE-2
SDP 41

192.0.2.2

CE
BGP_VPLS_03

Figure 52: BGP VPLS Using Pre-Provisioned SDP

Figure 52 shows an example of a VPLS instance where SDPs are pre-provisioned with LDP
signalled transport tunnels.
SDPs on PE-1
configure service
sdp 33 mpls create
description "from-192.0.2.1-id-33"
far-end 192.0.2.2
lsp "LSP-PE-1-PE-2"
signaling bgp
keep-alive
shutdown
exit
no shutdown
exit
sdp 42 mpls create
description "from-192.0.2.1-id-42"
far-end 192.0.2.3

Advanced Configuration Guide

Page 303

Configuration

lsp "LSP-PE-1-PE-3"
signaling bgp
keep-alive
shutdown
exit
no shutdown
exit
exit

SDPs on PE-2
configure service
sdp 40 mpls create
far-end 192.0.2.1
lsp "LSP-PE-2-PE-1"
signaling bgp
keep-alive
shutdown
exit
no shutdown
exit
sdp 41 mpls create
far-end 192.0.2.3
lsp "LSP-PE-2-PE-3"
signaling bgp
keep-alive
shutdown
exit
no shutdown
exit
exit

SDPs on PE-3
configure service
sdp 38 mpls create
description "from-192.0.2.3-id-38"
far-end 192.0.2.1
lsp "LSP-PE-3-PE-1"
signaling bgp
keep-alive
shutdown
exit
collect-stats
no shutdown
exit
sdp 39 mpls create
description "from-192.0.2.3-id-39"
far-end 192.0.2.2
lsp "LSP-PE-3-PE-2"
signaling bgp
keep-alive
shutdown
exit
collect-stats
no shutdown

Page 304

Advanced Configuration Guide

BGP VPLS

exit
exit

Note that pre-provisioned BGP-SDPs can also be used with BGP-VPLS. For reference, they are
configured as follows:
*B:PE-3>config service sdp 64 mpls create
far-end 192.0.2.2
signaling bgp
keep-alive
shutdown
exit
no shutdown

To create an SDP within a service that uses the RSVP transport tunnel, a pseudowire template is
required that has the use-provisioned-sdp parameter set.
Once again, a split horizon group is included to prevent forwarding between pseudowires.
The pseudowire template must be provisioned on all PEs and looks like:
A:PE-1# configure service
pw-template 3 use-provisioned-sdp create
split-horizon-group "vpls-shg"
exit
exit

The following output shows the configuration required for a BGP-VPLS service using a
pseudowire template configured for using pre-provisioned RSVP-TE SDPs.
A:PE-1# configure service vpls 2 customer 1 create
bgp
route-distinguisher 65536:2
route-target export target:65536:2 import target:65536:2
pw-template-binding 3
exit
exit
bgp-vpls
max-ve-id 100
ve-name PE-1
ve-id 1
exit
no shutdown
exit
stp
shutdown
exit
sap 1/2/1:2.0 create
exit
no shutdown
exit

Advanced Configuration Guide

Page 305

Configuration

Note that the route distinguisher and route target extended community values for VPLS 2 are
different from that in VPLS 1. The ve-id value for PE-1 can be the same as that in VPLS 1, but
these must be different within the same VPLS instance on the other PEs PE-2 should not have
ve-id = 1.
Similarly, on PE-2 the configuration example shows where the ve-id value is 20:
A:PE-2# configure service vpls 2
bgp
route-distinguisher 65536:2
route-target export target:65536:2 import target:65536:2
pw-template-binding 3
exit
exit
bgp-vpls
max-ve-id 100
ve-name PE-2
ve-id 20
exit
no shutdown
exit
stp
shutdown
exit
sap 1/1/1:2.0 create
exit
no shutdown

and on PE-3:
B:PE-3# configure service vpls 2
bgp
route-distinguisher 65536:2
route-target export target:65536:2 import target:65536:2
pw-template-binding 3
exit
exit
bgp-vpls
max-ve-id 100
ve-name PE-3
ve-id 3
exit
no shutdown
exit
stp
shutdown
exit
sap 1/1/4:2.0 create
exit
no shutdown

Verify that the service is operationally up on PE-1.


A:PE-1# show service id 2 base
===============================================================================

Page 306

Advanced Configuration Guide

BGP VPLS

Service Basic Information


===============================================================================
Service Id
: 2
Vpn Id
: 0
Service Type
: VPLS
Name
: (Not Specified)
Description
: (Not Specified)
Customer Id
: 1
Last Status Change: 07/10/2011 17:27:26
Last Mgmt Change : 07/10/2011 20:43:03
Admin State
: Up
Oper State
: Up
MTU
: 1514
Def. Mesh VC Id
: 2
SAP Count
: 1
SDP Bind Count
: 2
Snd Flush on Fail : Disabled
Host Conn Verify : Disabled
Propagate MacFlush: Disabled
Per Svc Hashing
: Disabled
Allow IP Intf Bind: Disabled
Def. Gateway IP
: None
Def. Gateway MAC : None
Temp Flood Time
: Disabled
Temp Flood
: Inactive
Temp Flood Chg Cnt: 0
------------------------------------------------------------------------------Service Access & Destination Points
------------------------------------------------------------------------------Identifier
Type
AdmMTU OprMTU Adm Opr
------------------------------------------------------------------------------sap:1/2/1:2.0
qinq
1522
1522
Up
Up
sdp:33:4294967278 SB(192.0.2.2)
BgpVpls
0
9190
Up
Up
sdp:42:4294967283 SB(192.0.2.3)
BgpVpls
0
9190
Up
Up
===============================================================================
A:PE-1#

Note that the SDP-ids are the pre-provisioned SDPs.


For completeness, verify the service is operationally up on PE-2
A:PE-2# show service id 2 base
===============================================================================
Service Basic Information
===============================================================================
Service Id
: 2
Vpn Id
: 0
Service Type
: VPLS
Name
: (Not Specified)
Description
: (Not Specified)
Customer Id
: 1
Last Status Change: 07/10/2011 00:49:40
Last Mgmt Change : 07/11/2011 01:17:55
Admin State
: Up
Oper State
: Up
MTU
: 1514
Def. Mesh VC Id
: 2
SAP Count
: 1
SDP Bind Count
: 2
Snd Flush on Fail : Disabled
Host Conn Verify : Disabled
Propagate MacFlush: Disabled
Per Svc Hashing
: Disabled
Allow IP Intf Bind: Disabled
Def. Gateway IP
: None
Def. Gateway MAC : None
Temp Flood Time
: Disabled
Temp Flood
: Inactive
Temp Flood Chg Cnt: 0
------------------------------------------------------------------------------Service Access & Destination Points

Advanced Configuration Guide

Page 307

Configuration

------------------------------------------------------------------------------Identifier
Type
AdmMTU OprMTU Adm Opr
------------------------------------------------------------------------------sap:1/1/1:2.0
qinq
1522
1522
Up
Up
sdp:40:4294967226 SB(192.0.2.1)
BgpVpls
0
9190
Up
Up
sdp:41:4294967227 SB(192.0.2.3)
BgpVpls
0
9190
Up
Up
===============================================================================
A:PE-2#

Verify service is operational on PE-3:


B:PE-3# show service id 2 base
===============================================================================
Service Basic Information
===============================================================================
Service Id
: 2
Vpn Id
: 0
Service Type
: VPLS
Name
: (Not Specified)
Description
: (Not Specified)
Customer Id
: 1
Last Status Change: 06/24/2011 13:02:25
Last Mgmt Change : 06/26/2011 13:29:42
Admin State
: Up
Oper State
: Up
MTU
: 1514
Def. Mesh VC Id
: 2
SAP Count
: 1
SDP Bind Count
: 2
Snd Flush on Fail : Disabled
Host Conn Verify : Disabled
Propagate MacFlush: Disabled
Per Svc Hashing
: Disabled
Allow IP Intf Bind: Disabled
Def. Gateway IP
: None
Def. Gateway MAC : None
Temp Flood Time
: Disabled
Temp Flood
: Inactive
Temp Flood Chg Cnt: 0
------------------------------------------------------------------------------Service Access & Destination Points
------------------------------------------------------------------------------Identifier
Type
AdmMTU OprMTU Adm Opr
------------------------------------------------------------------------------sap:1/1/4:2.0
qinq
1522
1522
Up
Up
sdp:38:4294967269 SB(192.0.2.1)
BgpVpls
0
9190
Up
Up
sdp:39:4294967262 SB(192.0.2.2)
BgpVpls
0
9190
Up
Up
===============================================================================
B:PE-3#

Page 308

Advanced Configuration Guide

BGP VPLS

PE-1 De-Multiplexor Label Calculation


In the case of VPLS 1, all ve-ids are in the range of a single label block. In the case of VPLS 2, the
ve-ids are in different blocks, for example, the ve-id 20 is in a different block to ve-ids 1 and 2.
As the label allocation is block-dependent, multiple labels blocks must be advertised by each PE
to encompass this.
Consider PE-1s BGP update NLRIs.
A:PE-1# show router bgp routes l2-vpn rd 65536:2 hunt
===============================================================================
BGP Router ID:192.0.2.1
AS:65536
Local AS:65536
===============================================================================
Legend Status codes : u - used, s - suppressed, h - history, d - decayed, * - valid
Origin codes : i - IGP, e - EGP, ? - incomplete, > - best
===============================================================================
BGP L2VPN Routes
===============================================================================
...
------------------------------------------------------------------------------RIB Out Entries
------------------------------------------------------------------------------Route Type
: VPLS
Route Dist.
: 65536:2
VeId
: 1
Block Size
: 8
Base Offset
: 1
Label Base
: 131055
Nexthop
: 192.0.2.1
To
: 192.0.2.20
Res. Nexthop
: n/a
Local Pref.
: 100
Interface Name : NotAvailable
Aggregator AS : None
Aggregator
: None
Atomic Aggr.
: Not Atomic
MED
: 0
Community
: target:65536:2 l2-vpn:Encap=19: Flags=none: MTU=1514
Cluster
: No Cluster Members
Originator Id : None
Peer Router Id : 192.0.2.50
Origin
: IGP
AS-Path
: No As-Path
Route Type
Route Dist.
VeId
Base Offset
Nexthop
To
Res. Nexthop
Local Pref.
Aggregator AS
Atomic Aggr.
Community
Cluster
Originator Id
Origin
AS-Path

:
:
:
:
:
:
:
:
:
:
:
:
:
:
:

VPLS
65536:2
1
Block Size
: 8
17
Label Base
: 131038
192.0.2.1
192.0.2.20
n/a
100
Interface Name : NotAvailable
None
Aggregator
: None
Not Atomic
MED
: 0
target:65536:2 l2-vpn:Encap=19: Flags=none: MTU=1514
No Cluster Members
None
Peer Router Id : 192.0.2.50
IGP
No As-Path

-------------------------------------------------------------------------------

Advanced Configuration Guide

Page 309

Configuration

Routes : 8
===============================================================================
A:PE-1#

Two NLRIs updates are sent to the route reflector, with the following label parameters
1. LB = 131055, VBS = 8, VBO = 1
2. LB = 131038, VBS = 8, VBO = 17
PE-2 has a ve-id of 20. Applying the condition VBO ve-id < (VBO+VBS)
Update 1: LB = 131055, VBS = 8, VBO = 1
VBO ve-id for ve-id = 20 is TRUE
ve-id < (VBO+VBS) for ve-id = 20 is FALSE.
PE-2 cannot choose a label from this block.
Update 2: LB = 131038, VBS = 8, VBO = 17
VBO ve-id for ve-id = 20 is TRUE
ve-id < (VBO+VBS) for ve-id = 20 is TRUE.
PE-2 chooses label 131038 + 20 - 17 = 131041 (LB + veid - VBO)
The egress label chosen is verified by examining the egress label towards PE-1 (192.0.2.1) on PE2.
A:PE-2# show service id 2 sdp
===============================================================================
Services: Service Destination Points
===============================================================================
SdpId
Type IP address
Adm
Opr
I.Lbl
E.Lbl
------------------------------------------------------------------------------40:4294967226
Bgp* 192.0.2.1
Up
Up
131038
131041
41:4294967227
Bgp* 192.0.2.3
Up
Up
131040
131039
------------------------------------------------------------------------------Number of SDPs : 2
------------------------------------------------------------------------------A:PE-2#

PE-3 has a ve-id of 3. Applying the condition VBO ve-id < (VBO+VBS)
Update 1: LB = 131055, VBS = 8, VBO = 1
VBO ve-id for ve-id = 3 is TRUE
ve-id < (VBO+VBS) for ve-id = 3 is TRUE.
PE-3 chooses label 131055 + 3 - 1 = 131057 (LB + veid - VBO)
Update 2: LB = 131038, VBS = 8, VBO = 17
VBO ve-id for ve-id = 3 is FALSE
ve-id < (VBO+VBS) for ve-id = 3 is FALSE.
PE-3 cannot choose a label from this block.

Page 310

Advanced Configuration Guide

BGP VPLS

The egress label chosen is verified by examining the egress label towards PE-1 (192.0.2.1) on PE3.
B:PE-3# show service id 2 sdp
===============================================================================
Services: Service Destination Points
===============================================================================
SdpId
Type IP address
Adm
Opr
I.Lbl
E.Lbl
------------------------------------------------------------------------------38:4294967269
Bgp* 192.0.2.1
Up
Up
131047
131057
39:4294967262
Bgp* 192.0.2.2
Up
Up
131039
131040
------------------------------------------------------------------------------Number of SDPs : 2
------------------------------------------------------------------------------===============================================================================
B:PE-3#

To illustrate the allocation of label blocks by a PE, against the actual use of the same labels,
consider the following. When BGP updates from each PE signal the multiplexer labels in blocks
of eight, the allocated label values are added to the in-use pool. The label pool of PE-1 can be
verified as per the following output which shows labels used along with the associated protocol:
A:PE-1# show router mpls label 32 131071 in-use
=================================================================
MPLS Labels from 32 to 131071 (In-use)
=================================================================
Label
Label Type
Label Owner
----------------------------------------------------------------131036
dynamic
TLDP
131037
dynamic
TLDP
131038
dynamic
BGP
131039
dynamic
BGP
131040
dynamic
BGP
131041
dynamic
BGP
131042
dynamic
BGP
131043
dynamic
BGP
131044
dynamic
BGP
131045
dynamic
BGP
131046
dynamic
TLDP
131047
dynamic
TLDP
131048
dynamic
RSVP
131049
dynamic
RSVP
131050
dynamic
ILDP
131051
dynamic
ILDP
131052
dynamic
ILDP
131053
dynamic
ILDP
131054
dynamic
ILDP
131055
dynamic
BGP
131056
dynamic
BGP
131057
dynamic
BGP
131058
dynamic
BGP
131059
dynamic
BGP
131060
dynamic
BGP
131061
dynamic
BGP
131062
dynamic
BGP
131063
dynamic
BGP
131064
dynamic
BGP

Advanced Configuration Guide

Page 311

Configuration

131065
dynamic
BGP
131066
dynamic
BGP
131067
dynamic
BGP
131068
dynamic
BGP
131069
dynamic
BGP
131070
dynamic
BGP
131071
dynamic
ILDP
...
=================================================================
A:PE-1#

This shows that 24 labels have been allocated for use by BGP. Of this number, 16 labels have been
allocated for use by PEs within VPLS 2 to communicate with PE-1, the blocks with label base
131038 and with label base 131055.
There are only two neighboring PEs within this VPLS instance, so only two labels will ever be
used in the data plane for traffic destined to PE-1. These are 131041 and 131057. The remaining
labels have no PE with the associated ve-id that can use them.
Once again, this case emphasizes that to reduce label wastage, contiguous ve-ids in the range
(N..N+7) per VPLS should be chosen, where N>0.

Page 312

Advanced Configuration Guide

BGP VPLS

Conclusion
BGP-VPLS allows the delivery of Layer 2 VPN services to customers where BGP is commonly
used. The examples presented in this section show the configuration of BGP-VPLS together with
the associated show outputs which can be used for verification and troubleshooting.

Advanced Configuration Guide

Page 313

Conclusion

Page 314

Advanced Configuration Guide

Bi-Directional Forwarding Detection

In This Chapter
This section provides information about bi-directional forwarding (BFD) detection.
Topics in this section include:

Applicability on page 316

Summary on page 167

Overview on page 317

Configuration on page 319

Conclusion on page 362

Advanced Configuration Guide

Page 315

Applicability

Applicability
This section is applicable to all of the 7x50 and 7710 series but the timing differs among platforms
and these will be indicated. Note that the centralized cpm-np type is only supported by 7750/7450s
equipped with SF/CPM 2 or higher. The information contained in this section has been tested with
Release 8.0.R4.

Page 316

Advanced Configuration Guide

Bi-Directional Forwarding Detection

Overview
Bi-Directional Forwarding Detection (BFD) is a light-weight protocol which provides rapid path
failure detection between two systems. It has been recently published as a series of RFCs (RFC
5880, Bidirectional Forwarding Detection (BFD), to RFC 5884, Bidirectional Forwarding
Detection (BFD) for MPLS Label Switched Paths (LSPs).
If a system running BFD stops receiving BFD messages on an interface, it will determine that
there has been a failure in the path and notifies other protocols associated with the interface. BFD
is useful in situations where two nodes are interconnected through either an optical (DWDM) or
Ethernet network. In both cases, the physical network has numerous extra hops which are not part
of the Layer 3 network and therefore, the Layer 3 nodes are incapable of detecting failures which
occur in the physical network on spans to which the Layer 3 devices are not directly connected.
BFD protocol provides rapid link continuity checking between network devices, and the state of
BFD can be propagated to IP routing protocols to drastically reduce convergence time in cases
where a physical network error occurs in a transport network.
RFC 5880 define two modes of operation for BFD:

Asynchronous mode (supported by ALU routers covered in this section) Uses periodic
BFD control messages to test the path between systems

Demand mode (not supported by ALU router covered in this section)

In addition to the two operational modes, an echo function is defined (ALU routers covered by this
section only support response, looping back received BFD messages to the original sender).
The goal of this section is to describe the configuration and troubleshooting for BFD on a link
between two peers in the following scenarios:

BFD for ISIS

BFD for OSPF

BFD for PIM

BFD for Static route

BFD IES

BFD for RSVP

BFD for T-LDP

BFD support of OSPF CE-PE adjacencies

BFD over IPSec tunnel

BFD over VRRP

Advanced Configuration Guide

Page 317

Overview

Figure 53 provides an overview of the possible BFD implementations and shows all protocols that
can be bound to a BFD session.

BFD Session
Netw or IES
i/f

Supported Protocols:

System i/f

BFD
Session

Transport
Device

Transport
Device

Netw or IES
i/f

OSPF
IS-IS
BGP
PIM
RSVP-TE (not for IES)
Static route

T-LDP
Session
BFD Session
Over IPSEC Tunnel

BFD Session
Over PE-CE i/f
PE
CE

Internet
System i/f

1
2

IES
or
VPN

VPN

OSPF/BGP

ISA

Vpn connectivity
OSSG553

Figure 53: BFD Multi-Scenarios

Page 318

Advanced Configuration Guide

Bi-Directional Forwarding Detection

Configuration
BFD packets are processed both locally (processed on IOM CPU) and centrally (processed on the
CPM).
Starting with Release 8, the CPM is able to centrally generate the BFD packets at a sub second
interval as low as 10 msec. However it should be noted that the BFD state machine is still
implemented in software. It is the BFD packet generation that can be now selectively delegated to
CPM hardware as needed. This is applicable where sub second operational requirements for BFD
or scaling the number of BFD sessions beyond 250 are required.
Centralized sessions are processed:

in software by 7x50 SR-1 and ESS-1, 7710 c4 and c12 and 7x50 equipped with SF/CPM
1.

in hardware by 7x50 equipped with SF/CPM 2 or higher.

Minimum transmitting and receiving Intervals are as follows:

Centralized sessions:
Minimum 300 ms in 7x50 SR-1 and ESS-1, 7710 c4 and c12
Minimum 100 ms in 7x50 equipped with SF/CPM 1 and in every 7x50 up to Release
7.0
Minimum 10 ms in 7x50 equipped with SF/CPM 2 or higher

Local sessions:
Minimum 100 ms

The following applications require BFD to run centrally on the SF/CPM and a centralized session
will be created independently of the type explicitly declared by the user:

BFD for IES/VPRN over Spoke SDP

BFD over LAG and VSM Interfaces

Protocol associations using loopback and system interfaces (e.g. BFD for T-LDP)

BFD over IPSec sessions

BFD sessions associated with multi-hop peering

Advanced Configuration Guide

Page 319

Configuration

Figure 54 shows the most relevant scenarios where BFD centralized sessions are used.

BFD Session
IES/
VPRN

Spoke-SDP

Spoke-SDP

IES/
VPRN

Primary Path
System i/f

BFD Session
Over T-LDP
Session

BFD Session
Over IPSEC Tunnel

Internet
System i/f

BFD Session
Over LAG
IES/
VPRN
Netw
IES/ /IES
i/f
VPRN

Netw /IES
i/f
LAG

LAG

OSSG554

Figure 54: BFD Centralized Sessions

On the other end, when the two peers are directly connected, the BFD session is local by default,
but in a 7x50 equipped with SF/CPM 2 or higher, the user can choose which session (local or
centralized) to implement.
As general rule, the following steps are required to configure and enable a BFD session when
peers are directly connected:
1. Configure BFD parameters on the peering interfaces.
2. Check that the Layer 3 protocol, that is to be bound to BFD, is up and running.
3. Enable BFD under the Layer 3 protocol interface.
Since most of the following procedures share the same first step, it is described only once in the
next paragraph and then referred to in the following paragraphs.

Page 320

Advanced Configuration Guide

Bi-Directional Forwarding Detection

BFD Base Parameter Configuration and Troubleshooting


The reference topology for the generic configuration of BFD over two local peers is shown in
Figure 55.

BFD Parameter Configuration


Tx, Rx Intervals
Multiplier
Type
i/f PE-1-PE-2
Port 1/1/1
192.168.1.1

Transport
Device

Transport
Device

i/f PE-2-PE-1
Port 1/1/1
192.168.1.2

OSSG555

Figure 55: BFD Interface Configuration

To configure BFD between two peers, the user should firstly enable base level BFD on interfaces
between PE-1 and PE-2.
On PE1:
configure
router
interface PE-1-PE-2
address 192.168.1.1/30
port 1/1/1
bfd 100 receive 100 multiplier 3
exit
exit
exit

On PE2:
configure
router
interface PE-2-PE-1
address 192.168.1.2/30
port 1/1/1
bfd 100 receive 100 multiplier 3
exit
exit
exit

Advanced Configuration Guide

Page 321

Configuration

The following show commands are used to verify the BFD configuration on the router interfaces
on PE1 and PE2.
On PE1:
A:PE1# show router bfd interface
===============================================================================
BFD Interface
===============================================================================
Interface name
Tx Interval
Rx Interval
Multiplier
------------------------------------------------------------------------------PE-1-PE-2
100
100
3
------------------------------------------------------------------------------No. of BFD Interfaces: 1
===============================================================================
A:PE1#

On PE2:
A:PE2# show router bfd interface
===============================================================================
BFD Interface
===============================================================================
Interface name
Tx Interval
Rx Interval
Multiplier
------------------------------------------------------------------------------PE-2-PE-1
100
100
3
------------------------------------------------------------------------------No. of BFD Interfaces: 1
===============================================================================
A:PE2#

Note that, BFD being an asynchronous protocol, it is possible to configure different tx and rx
intervals on the two peers. This is because BFD rx/tx interval values are signaled in the BFD
packets while establishing the BFD session.
In 7x50s equipped with SF/CPM 2 or higher, configurable BFD parameters are as follows:
bfd <transmit-interval> [receive <receive-interval>] [multiplier <multiplier>] [echoreceive <echo-interval>] [type <cpm-np>]
no bfd
<transmit-interval>
<receive-interval>
<multiplier>
<echo-interval>
<cpm-np>

:
:
:
:
:

[10..100000] in milliseconds
[10..100000] in milliseconds
[3..20]
[100..100000] in milliseconds
keyword - use CPM network processor

Note that it is possible to force the BFD session to be centrally managed by the CPM hardware.

Page 322

Advanced Configuration Guide

Bi-Directional Forwarding Detection

As regards the echo function, it is possible to set the minimum echo receive interval, in
milliseconds, for the BFD session. The default value is 100 ms.
If a BFD session is running, it is possible to modify its parameters but to change its type the
session must be previously shut down manually. Note that this causes the upper layer protocols
bound to it to be brought down as well.
configure
router
interface PE-2-PE-1
bfd 10 receive 10 multiplier 3 type cpm-np
exit
exit
exit

Forcing a centralized session in the case of directly connected peers can be useful when:

Lower Tx and Rx intervals are requested (up to 10 ms instead of 100 ms supported by


local sessions)

There are no more available local sessions

Max limit of 500 packet per second per IOM has been reached

Advanced Configuration Guide

Page 323

Configuration

The instructions illustrated in following paragraphs are required to complete the configuration and
enable BFD.
The BFD session should come up. To verify it, execute a show router bfd session command
(bound to OSPF in the following example).
A:PE1# show router bfd session
===============================================================================
BFD Session
===============================================================================
Interface
State
Tx Intvl Rx Intvl Multipl
Remote Address
Protocol
Tx Pkts
Rx Pkts
Type
------------------------------------------------------------------------------PE-1-PE-2
Up (3)
100
100
3
192.168.1.2
ospf
165
174
iom
------------------------------------------------------------------------------No. of BFD sessions: 1
===============================================================================
A:PE1#

If the command gives a negative output, troubleshoot it by firstly checking that the protocol that is
bound to it is up: for instance, check the OSPF neighbor adjacency as shown in following
example.
A:PE-1# show router ospf neighbor
===============================================================================
OSPF Neighbors
===============================================================================
Interface-Name
Rtr Id
State
Pri RetxQ
TTL
------------------------------------------------------------------------------PE-1-PE-2
192.0.2.1
Full
1
0
34
------------------------------------------------------------------------------...
===============================================================================
A:PE-1#

Then check whether a BFD resource limit has been reached (maximum number of local/
centralized sessions or maximum number of packet per second per IOM).
If the overloaded limit is the maximum supported number of sessions, the cause is shown by logid 99. In the reported example, the maximum number of sessions per slot has been reached.
A:PE-2# show log log-id 99
===============================================================================
Event Log 99
===============================================================================
Description : Default System Log
Memory Log contents [size=500
next event=7845 (wrapped)]
7844 2010/10/02 16:43:30.21 UTC MINOR: VRTR #2020 Base 192.168.1.1
BFD Session on node 192.168.1.1 has been deleted.
7843 2010/10/02 16:43:30.21 UTC MAJOR: VRTR #2013 Base Max supported sessions reached
The number of BFD sessions on slot 1 has exceeded 250, constrained by maxSessionsPerSlot

Page 324

Advanced Configuration Guide

Bi-Directional Forwarding Detection

In this case, when one of the running sessions is manually removed or goes down, then the
additional configured session will come up. If the limit reached is local (on IOM) it is possible to
bring up the session by re-configuring it as centralized, by changing the type.
To check if IOM CPU is able to start more local BFD sessions, execute a show router BFD
session summary command.
A:PE2# show router bfd session summary
=============================
BFD Session Summary
=============================
Termination
Session Count
----------------------------central
0
cpm-np
1
iom, slot 1
250
iom, slot 2
0
iom, slot 3
0
iom, slot 4
0
iom, slot 5
0
Total
251
=============================

If the show router bfd session command reports that the BFD session is down, the check the BFD
peer's configuration and state.
The following log 99 output reports PE-1 logs after a misconfiguration of PE-2 (disabling BFD on
the OSPF interface).
As soon as BFD is shutdown on the OSPF interface PE-2-PE-1 of PE-2, the BFD session in PE-1
goes to the down state, then the OSPF adjacency is brought down for approximately 2.8 secs and
finally the OSPF state goes back to full, while the BFD session stays in down state.
This state will last until BFD is re-enabled on PE-2 interface.
A:PE-1# show log log-id 99
===============================================================================
Event Log 99
===============================================================================
Description : Default System Log
Memory Log contents [size=500
next event=7 (not wrapped)]
6 2010/10/02 08:47:35.91 UTC WARNING: OSPF #2002 Base VR: 1 OSPFv2 (0)
LCL_RTR_ID 192.0.2.1: Neighbor 192.0.2.2 on PE-1-PE-2 router state changed to full (event
EXC_DONE)
5 2010/10/02 08:47:35.91 UTC MINOR: VRTR #2021 Base 192.168.1.2
BFD: The protocols using BFD session on node 192.168.1.2 have changed.
4 2010/10/02 08:47:33.10 UTC WARNING: OSPF #2002 Base VR: 1 OSPFv2 (0)
LCL_RTR_ID 192.0.2.1: Neighbor 192.0.2.2 on PE-1-PE-2 router state changed to down (event
BFD_DOWN)
3 2010/10/02 08:47:33.10 UTC MINOR: VRTR #2021 Base 192.168.1.2
BFD: The protocols using BFD session on node 192.168.1.2 have changed.

Advanced Configuration Guide

Page 325

Configuration

2 2010/10/02 08:47:33.10 UTC MAJOR: VRTR #2012 Base 192.168.1.2


BFD: Local Discriminator 4009 BFD session to node 192.168.1.2 is down due to noHeartBeat

A:PE-1# show router bfd session


===============================================================================
BFD Session
===============================================================================
Interface
State
Tx Intvl Rx Intvl Multipl
Remote Address
Protocols
Tx Pkts
Rx Pkts
Type
------------------------------------------------------------------------------PE-1-PE-2
Down (1)
100
100
3
192.168.1.2
ospf2
10
0
iom

The 2nd column reports the current BFD session state. Possible values are:

0 AdminDown

1 Down

2 Init

3 Up

The show router bfd session src <ip-address> detail command can help in debugging the BFD
session.
A:PE-1# show router bfd session src 192.168.1.1 detail
===============================================================================
BFD Session
===============================================================================
Remote Address : 192.168.1.2
Admin State
: Up
Oper State
: Up (3)
Protocols
: ospf2 pim isis static
Rx Interval
: 100
Tx Interval
: 100
Multiplier
: 3
Echo Interval
: 0
Recd Msgs
: 24046
Sent Msgs
: 25723
Up Time
: 0d 00:40:05
Up Transitions
: 1
Down Time
: None
Down Transitions : 0
Version Mismatch : 0
Forwarding Information
Local Discr
: 4002
Local State
: Up (3)
Local Diag
: 0 (None)
Local Mode
: Async
Local Min Tx
: 100
Local Mult
: 3
Last Sent
: 10/08/2010 20:30:27
Local Min Rx
: 100
Type
: iom
Remote Discr
: 4001
Remote State
: Up (3)
Remote Diag
: 0 (None)
Remote Mode
: Async
Remote Min Tx : 100
Remote Mult
: 3
Last Recv
: 10/08/2010 20:30:27
Remote Min Rx
: 100
===============================================================================

Page 326

Advanced Configuration Guide

Bi-Directional Forwarding Detection

BFD for IS-IS


The goal of this section is to configure BFD on a network interlink between two 7750 nodes that
are IS-IS peers. The topology referred to in this paragraph is shown in Figure 56.

BFD Session
i/f PE-1-PE-2
Port 1/1/1
192.168.1.1

Transport
Device

Transport
Device

i/f PE-2-PE-1
Port 1/1/1
192.168.1.2

ISIS
OSSG556

Figure 56: BFD for ISIS

For the base BFD configuration, please refer to BFD Base Parameter Configuration and
Troubleshooting on page 321.
Apply BFD on the ISIS Interfaces.
On PE1:
configure
router
isis
interface PE-1-PE-2
bfd-enable ipv4
exit
exit
exit
exit

On PE2:
configure
router
isis
interface PE-2-PE-1
bfd-enable ipv4
exit
exit
exit
exit

Advanced Configuration Guide

Page 327

Configuration

Finally, verify that the BFD session is operational between PE1 and PE2.
On PE1:
A:PE1# show router bfd session
===============================================================================
BFD Session
===============================================================================
Interface
State
Tx Intvl Rx Intvl Multipl
Remote Address
Protocol
Tx Pkts
Rx Pkts
Type
------------------------------------------------------------------------------PE-1-PE-2
Up (3)
100
100
3
192.168.1.2
isis
165
174
iom
------------------------------------------------------------------------------No. of BFD sessions: 1
===============================================================================
A:PE1#

On PE2:
A:PE2# show router bfd session
===============================================================================
BFD Session
===============================================================================
Interface
State
Tx Intvl Rx Intvl Multipl
Remote Address
Protocol
Tx Pkts
Rx Pkts
Type
------------------------------------------------------------------------------PE-2-PE-1
Up (3)
100
100
3
192.168.1.1
isis
496
487
iom
------------------------------------------------------------------------------No. of BFD sessions: 1
===============================================================================
A:PE2#

Page 328

Advanced Configuration Guide

Bi-Directional Forwarding Detection

BFD for OSPF


The goal of this section is to configure BFD on a network interlink between two 7750 nodes that
are OSPF peers.
For this scenario, the topology is shown in Figure 57.

BFD Session
i/f PE-1-PE-2
Port 1/1/1
192.168.1.1

Transport
Device

Transport
Device

i/f PE-2-PE-1
Port 1/1/1
192.168.1.2

OSPF
OSSG557

Figure 57: BFD for OSPF

For the base BFD configuration, refer to BFD Base Parameter Configuration and Troubleshooting
on page 321.
Apply BFD on the OSPF Interfaces.
On PE1:
configure
router
ospf
interface PE-1-PE-2
bfd-enable
exit
exit
exit
exit

On PE2:
configure
router
ospf
interface PE-2-PE-1
bfd-enable
exit

Advanced Configuration Guide

Page 329

Configuration

exit
exit
exit

Verify that the BFD session is operational between PE1 and PE2.
On PE1:
A:PE1# show router bfd session
===============================================================================
BFD Session
===============================================================================
Interface
State
Tx Intvl Rx Intvl Multipl
Remote Address
Protocol
Tx Pkts
Rx Pkts
Type
------------------------------------------------------------------------------PE-1-PE-2
Up (3)
100
100
3
192.168.1.2
ospf
170
179
iom
------------------------------------------------------------------------------No. of BFD sessions: 1
===============================================================================
A:PE1#

On PE2:
A:PE2# show router bfd session
===============================================================================
BFD Session
===============================================================================
Interface
State
Tx Intvl Rx Intvl Multipl
Remote Address
Protocol
Tx Pkts
Rx Pkts
Type
------------------------------------------------------------------------------PE-2-PE-1
Up (3)
100
100
3
192.168.1.1
ospf
501
492
iom
------------------------------------------------------------------------------No. of BFD sessions: 1
===============================================================================
A:PE2#

Page 330

Advanced Configuration Guide

Bi-Directional Forwarding Detection

BFD for PIM


Since the implementation of PIM uses an Interior Gateway Protocol (IGP) in order to determine its
Reverse Path Forwarding (RPF) tree, BFD configuration to support PIM will require BFD
configuration of both the IGP protocol and the PIM protocol. Let's assume that IGP protocol is
OSPF and that the starting configuration is as described in the previous section.
In this paragraph, configure and enable BFD for PIM on the same interfaces that were previously
configured with BFD for OSPF, in reference to the topology shown in Figure 58.

Same BFD Session Bound


To Both OSPF and PIM
i/f PE-1-PE-2
Port 1/1/1
192.168.1.1

Transport
Device

Transport
Device

i/f PE-2-PE-1
Port 1/1/1
192.168.1.2

OSPF and PIM


OSSG558

Figure 58: BFD for OSPF and PIM

Since BFD has been already configured on the router interfaces, let's start by applying BFD on the
PIM Interface.
On PE1:
configure
router
pim
interface PE-1-PE-2
bfd-enable
exit
exit
exit
exit

Advanced Configuration Guide

Page 331

Configuration

On PE2:
configure
router
pim
interface PE-2-PE-1
bfd-enable
exit
exit
exit
exit

The final step is to verify whether the BFD Session is operational between PE1 and PE2 for PIM.
On PE1:
A:PE1# show router bfd session
===============================================================================
BFD Session
===============================================================================
Interface
State
Tx Intvl Rx Intvl Multipl
Remote Address
Protocol
Tx Pkts
Rx Pkts
Type
------------------------------------------------------------------------------PE-1-PE-2
Up (3)
100
100
3
192.168.1.2
ospf2 pim
3874
3845
iom
------------------------------------------------------------------------------No. of BFD sessions: 1
===============================================================================
A:PE1#

On PE2:
A:PE2# show router bfd session
===============================================================================
BFD Session
===============================================================================
Interface
State
Tx Intvl Rx Intvl Multipl
Remote Address
Protocol
Tx Pkts
Rx Pkts
Type
------------------------------------------------------------------------------PE-1-PE-2
Up (3)
100
100
3
192.168.1.1
ospf2 pim
3137
3145
iom
------------------------------------------------------------------------------No. of BFD sessions: 1
===============================================================================
A:PE2#

Page 332

Advanced Configuration Guide

Bi-Directional Forwarding Detection

BFD for Static Routes


The following procedures will go through the necessary steps to configure the base level BFD
configuration and then apply BFD to the static routes between PE1 and PE2, referring to topology
shown in Figure 59.

BFD Session Bound


To Static Routes

10.1.1.0/24

i/f PE-1-PE-2
Port 1/1/1
192.168.1.1

Transport
Device

Transport
Device

i/f PE-2-PE-1
10.1.2.0/24
Port 1/1/1
192.168.1.2

192.168.1.0/30
OSSG559

Figure 59: BFD for Static Routes

First, create the static routes for the remote networks both in PE-1 and PE-2.
On PE1:
configure
router
static-route 10.1.2.0/24 next-hop 192.168.1.2
exit
exit

On PE2:
configure
router
static-route 10.1.1.0/24 next-hop 192.168.1.1
exit
exit

Advanced Configuration Guide

Page 333

Configuration

Next, verify that static routes are populated in the routing table.
On PE1:
A:PE1# show router route-table
===============================================================================
Route Table (Router: Base)
===============================================================================
Dest Prefix
Type
Proto
Age
Pref
Next Hop[Interface Name]
Metric
------------------------------------------------------------------------------10.1.2.0/24
Remote Static
00h20m55s
5
192.168.1.2
1

On PE2:
A:PE2# show router route-table
===============================================================================
Route Table (Router: Base)
===============================================================================
Dest Prefix
Type
Proto
Age
Pref
Next Hop[Interface Name]
Metric
------------------------------------------------------------------------------10.1.1.0/24
Remote Static
00h21m15s
5
192.168.1.1
1

The next step is to configure the base level BFD on PE1 and PE2.
Refer to paragraph BFD Base Parameter Configuration and Troubleshooting on page 321.
Then apply BFD to the static routing entries using the BFD interfaces as next-hop.
On PE1:
configure
router
static-route 10.1.2.0/24 next-hop 192.168.1.2 bfd-enable
exit
exit

On PE2:
configure
router
static-route 10.1.1.0/24 next-hop 192.168.1.1 bfd-enable
exit
exit

Page 334

Advanced Configuration Guide

Bi-Directional Forwarding Detection

Note that BFD cannot be enabled if the next hop is indirect or the blackhole keyword is specified.
Finally, show the BFD session status.
On PE1:
A:PE1# show router bfd session
===============================================================================
BFD Session
===============================================================================
Interface
State
Tx Intvl Rx Intvl Multipl
Remote Address
Protocol
Tx Pkts
Rx Pkts
Type
------------------------------------------------------------------------------PE-1-PE-2
Up (3)
100
100
3
192.168.1.2
static
699
661
iom
------------------------------------------------------------------------------No. of BFD sessions: 1
===============================================================================

On PE2:
A:PE2# show router bfd session
===============================================================================
BFD Session
===============================================================================
Interface
State
Tx Intvl Rx Intvl Multipl
Remote Address
Protocol
Tx Pkts
Rx Pkts
Type
------------------------------------------------------------------------------PE-2-PE-1
Up (3)
100
100
3
192.168.1.1
static
691
729
iom
------------------------------------------------------------------------------No. of BFD sessions: 1
===============================================================================

Advanced Configuration Guide

Page 335

Configuration

BFD for IES


The goal of this section is to configure BFD for one IES service over a spoke SDP.
The IES service is configured in both 7750 nodes, PE1 and PE2, and their interfaces are connected
by spoke SDP's. The topology is shown in Figure 60.

BFD Session Over Spoke-SDP


IES 2
i/f IES_PE-1-PE-2

Spoke-SDP
1020:1

MPLS

IES 2
Spoke-SDP i/f IES_PE-2-PE-1
2010:1

OSSG560

Figure 60: BFD for IES over Spoke SDP

Note that in this scenario BFD is run between the IES interfaces independent of the SDP/LSP
paths.
The first step is to configure the IES service on both nodes.
On PE-1:
configure
service
ies 2 customer 1 create
interface IES_PE-1-PE-2 create
address 192.168.3.1/30
spoke-sdp 1020:1 create
exit
exit
no shutdown
exit
exit
exit

Page 336

Advanced Configuration Guide

Bi-Directional Forwarding Detection

On PE-2:
configure
service
ies 2 customer 1 create
interface IES_PE-2-PE-1 create
address 192.168.3.2/30
spoke-sdp 2010:1 create
exit
exit
no shutdown
exit
exit
exit

The next step is to add the IES interfaces to the OSPF area domain.
On PE-1:
configure
router
ospf
traffic-engineering
area 0.0.0.0
interface IES-PE-1-PE-2
exit
exit
exit
exit
exit

On PE-2:
configure
router
ospf
traffic-engineering
area 0.0.0.0
interface IES-PE-2-PE-1
exit
exit
exit
exit
exit

Advanced Configuration Guide

Page 337

Configuration

Then verify that OSPF and the services are up using show commands on both routers.
On PE-1:
A:PE-1# show service id 1 base
===============================================================================
Service Basic Information
===============================================================================
Service Id
: 2
Vpn Id
: 0
Service Type
: IES
Customer Id
: 1
Last Status Change: 09/30/2010 08:09:22
Last Mgmt Change : 09/30/2010 08:08:31
Admin State
: Up
Oper State
: Up
SAP Count
: 0
...
===============================================================================
A:PE-1#
A:PE-1# show router ospf neighbor
===============================================================================
OSPF Neighbors
===============================================================================
Interface-Name
Rtr Id
State
Pri RetxQ
TTL
------------------------------------------------------------------------------IES-PE-1-PE-2
192.0.2.2
Full
1
0
34
------------------------------------------------------------------------------===============================================================================
A:PE-1#

On PE-2:
A:PE-2# show service id 2 base
===============================================================================
Service Basic Information
===============================================================================
Service Id
: 2
Vpn Id
: 0
Service Type
: IES
Customer Id
: 1
Last Status Change: 09/30/2010 08:16:50
Last Mgmt Change : 09/30/2010 08:16:50
Admin State
: Up
Oper State
: Up
SAP Count
: 0
...
===============================================================================
A:PE-2#
A:PE-2# show router ospf neighbor
===============================================================================
OSPF Neighbors
===============================================================================
Interface-Name
Rtr Id
State
Pri RetxQ
TTL
------------------------------------------------------------------------------IES-PE-2-PE-1
192.0.2.1
Full
1
0
33
------------------------------------------------------------------------------...
===============================================================================
A:PE-2#

Page 338

Advanced Configuration Guide

Bi-Directional Forwarding Detection

Then configure BFD on the IES interfaces.


On PE-1:
configure service ies 2
interface IES-PE-1-PE-2
bfd 100 receive 100 multiplier 3
exit
no shutdown
exit

On PE-2:
configure service ies 2
interface IES-PE-2-PE-1
bfd 100 receive 100 multiplier 3
exit
no shutdown
exit

Finally, enable BFD on the interfaces under OSPF area 0.


On PE-1:
A:PE-1# configure router ospf area 0.0.0.0 interface IES-PE-1-PE-2 bfd-enable

On PE-2:
A:PE-2# configure router ospf area 0.0.0.0 interface IES-PE-2-PE-1 bfd-enable

Note that in case of BFD over spoke SDP, a centralized BFD session is created even if a physical
link exists between the two nodes. In fact, the next output shows that BFD session type is cpm-np.
This is because the spoke SDP is terminated at the CPM. This is also true for BFD running over
LAG bundles.
The cpm-np type only exists in 7x50 SR/ESS systems equipped with SF/CPM 2 or higher. When
other network elements run centralized BFD sessions like this one, the BFD type is shown as
central.
A:PE-1# show router bfd session
===============================================================================
BFD Session
===============================================================================
Interface
State
Tx Intvl Rx Intvl Multipl
Remote Address
Protocols
Tx Pkts
Rx Pkts
Type
------------------------------------------------------------------------------IES-PE-1-PE-2
Up (3)
100
100
3
192.168.3.2
ospf2
N/A
N/A
cpm-np
------------------------------------------------------------------------------No. of BFD sessions: 1

Advanced Configuration Guide

Page 339

Configuration

A:PE-2# show router bfd session


===============================================================================
BFD Session
===============================================================================
Interface
State
Tx Intvl Rx Intvl Multipl
Remote Address
Protocols
Tx Pkts
Rx Pkts
Type
------------------------------------------------------------------------------IES-PE-2-PE-1
Up (3)
100
100
3
192.168.3.1
ospf2
N/A
N/A
cpm-np
------------------------------------------------------------------------------No. of BFD sessions: 1

Note that in the case of centralized BFD sessions, transmitted and received packet counters are not
shown.

Page 340

Advanced Configuration Guide

Bi-Directional Forwarding Detection

BFD for RSVP


The goal of this section is to configure BFD between two RSVP interfaces configured in two 7750
nodes.
For this scenario, the topology is shown in Figure 61.

BFD Session for RSVP

RSVP i/f
PE-1-PE-2

LSP-PE-2-PE-1

LSP-PE-1-PE-2

RSVP i/f
PE-2-PE-1

RSVP-TE
OSSG561

Figure 61: BFD for RSVP

To enable the BFD session between the two RSVP peers, the user should follow these steps:
First, configure BFD on interfaces between PE-1 and PE-2 as described in BFD Base Parameter
Configuration and Troubleshooting on page 321.
Next, configure MPLS, creating the path, the LSP and the interfaces within MPLS (and RSVP).
On PE-1:
configure router
mpls
interface system
exit
interface PE-1-PE-2
exit
exit
rsvp
interface system
exit
interface PE-1-PE-2
exit
no shutdown
exit
mpls
path dyn
no shutdown
exit

Advanced Configuration Guide

Page 341

Configuration

lsp LSP-PE-1-PE-2
to 192.0.1.2
cspf
primary dyn
exit
no shutdown
exit
no shutdown
exit
exit

On PE-2:
configure router
mpls
interface system
exit
interface PE-2-PE-1
exit
exit
rsvp
interface system
exit
interface PE-2-PE-1
exit
no shutdown
exit
mpls
path dyn
no shutdown
exit
lsp LSP-PE-2-PE-1
to 192.0.1.1
cspf
primary dyn
exit
no shutdown
exit
no shutdown
exit
exit

Page 342

Advanced Configuration Guide

Bi-Directional Forwarding Detection

Next, verify that the RSVP session is up.


A:PE-1# show router rsvp session
===============================================================================
RSVP Sessions
===============================================================================
From
To
Tunnel LSP
Name
State
ID
ID
------------------------------------------------------------------------------192.0.2.2
192.0.2.1
2
516
LSP-PE-2-PE-1::dyn
Up
192.0.2.1
192.0.2.2
1
61446 LSP-PE-1-PE-2::dyn
Up
------------------------------------------------------------------------------Sessions : 2
===============================================================================
A:PE-1#

Then, apply BFD on the RSVP Interfaces.


On PE1:
configure
router
rsvp
interface PE-1-PE-2
bfd-enable
exit
no shutdown
exit
exit
exit

On PE2:
configure
router
rsvp
interface PE-2-PE-1
bfd-enable
exit
no shutdown
exit
exit
exit

Advanced Configuration Guide

Page 343

Configuration

Finally, verify that the BFD session is operational between PE1 and PE2.
On PE1:
===============================================================================
BFD Session
===============================================================================
Interface
State
Tx Intvl Rx Intvl Multipl
Remote Address
Protocols
Tx Pkts
Rx Pkts
Type
------------------------------------------------------------------------------PE-1-PE-2
Up (3)
100
100
3
192.168.1.2
rsvp
31515
31506
iom
------------------------------------------------------------------------------No. of BFD sessions: 1
===============================================================================

On PE2:
===============================================================================
BFD Session
===============================================================================
Interface
State
Tx Intvl Rx Intvl Multipl
Remote Address
Protocols
Tx Pkts
Rx Pkts
Type
------------------------------------------------------------------------------PE-2-PE-1
Up (3)
100
100
3
192.168.1.1
rsvp
31563
31572
iom
------------------------------------------------------------------------------No. of BFD sessions: 1
===============================================================================

Page 344

Advanced Configuration Guide

Bi-Directional Forwarding Detection

BFD for T-LDP


BFD tracking of an LDP session associated with a T-LDP adjacency allows for faster detection of
the liveliness of the session by registering the transport address of an LDP session with a BFD
session.
The goal of this paragraph is to configure BFD for T-LDP, referring to the scheme shown in
Figure 62.

BFD Session

System i/f
192.0.2.2/32

System i/f
192.0.2.1/32

T-LDP
OSSG562

Figure 62: BFD for T-LDP

The parameters used for the BFD session are configured under the loopback interface
corresponding to the LSR-ID (by default, the LSR-ID matches the system interface address).
configure
router
interface system
address 192.0.2.1/32
bfd 3000 receive 3000 multiplier 3
exit
exit
exit

By enabling BFD for a selected targeted session, the state of that session is tied to the state of the
underlying BFD session between the two nodes.
When using BFD over other links with the ability to reroute, such as spoke-SDPs, the interval and
multiplier values configuring BFD should be set to allow sufficient time for the underlying
network to re-converge before the associated BFD session expires. A general rule of thumb should

Advanced Configuration Guide

Page 345

Configuration

be that the expiration time (interval * multiplier) is three times the convergence time for the IGP
network between the two endpoints of the BFD session.
Before enabling BFD, ensure that the T-LDP session is up.
On PE-1:
B:PE-1# show router ldp session
==============================================================================
LDP Sessions
==============================================================================
Peer LDP Id
Adj Type
State
Msg Sent Msg Recv Up Time
-----------------------------------------------------------------------------192.0.2.2
Targeted
Established
35
41
0d 00:02:50
-----------------------------------------------------------------------------==============================================================================

On PE-2:
B:PE-2# show router ldp session
==============================================================================
LDP Sessions
==============================================================================
Peer LDP Id
Adj Type
State
Msg Sent Msg Recv Up Time
-----------------------------------------------------------------------------192.0.2.1
Targeted
Established
27
23
0d 00:01:32
-----------------------------------------------------------------------------==============================================================================

Then, enable the BFD session.


configure
router
ldp
targeted-session
peer 192.0.2.2
bfd-enable
exit
exit
exit
exit
exit

Note that the loopback interface can be used to source BFD sessions to many peers in the network.
Finally, check that the BFD session is up.
On PE-1:
A:PE-1# show router bfd session
===============================================================================
BFD Session
===============================================================================
Interface
State
Tx Intvl Rx Intvl Multipl

Page 346

Advanced Configuration Guide

Bi-Directional Forwarding Detection

Remote Address
Protocols
Tx Pkts
Rx Pkts
Type
------------------------------------------------------------------------------system
Up (3)
100
100
3
192.0.2.2
ldp
N/A
N/A
cpm-np

On PE-2:
A:PE-1# show router bfd session
===============================================================================
BFD Session
===============================================================================
Interface
State
Tx Intvl Rx Intvl Multipl
Remote Address
Protocols
Tx Pkts
Rx Pkts
Type
------------------------------------------------------------------------------system
Up (3)
100
100
3
192.0.2.1
ldp
N/A
N/A
cpm-np

When the T-LDP session comes up, a centralized BFD session is always created even if the local
interface has a direct link to the peer.

Advanced Configuration Guide

Page 347

Configuration

BFD Support of OSPF PE-CE Adjacencies


This feature, introduced with Release 8.0, extends BFD support to OSPF within a VPRN context
when OSPF is used as the PE-CE protocol. In this section, the topology shown in Figure 63.

BFD Session Over PE-CE Interface

VPRN 1
I/f PE-1-CE-1
172.16.0.1/24

OSPF Area 0.0.0.0


Sap 1/1/2:1

172.16.0.0/24

Network Port
1/1/2:1

I/f PE-1-CE-1
172.16.0.2/24

OSSG563

Figure 63: BFD for OSPF PE-CE I/F

First, configure the VPRN service interface PE-1-CE-1 on PE-1 with BFD parameters.
config
service
vprn 1 customer 1 create
route-distinguisher 1:1
vrf-target target:1:1
interface PE-1-CE-1 create
address 172.16.0.1/24
bfd 100 receive 100 multiplier 3
sap 1/1/1:1 create
exit
exit
ospf
area 0.0.0.0
interface PE-1-CE-1
exit
exit
exit
no shutdown
exit
exit
exit

Page 348

Advanced Configuration Guide

Bi-Directional Forwarding Detection

Next, configure the router interface on CE-1 and add it to the OSPF area 0 domain.
configure
router
interface CE-1-PE-1
address 172.16.0.2/24
port 1/1/1:1
bfd 100 receive 100 multiplier 3
exit
ospf
area 0.0.0.0
interface CE-1-PE-1
exit
exit
exit
exit
exit

Then, ensure that OSPF adjacency is up.


On PE-1:
A:PE-1>config>service>vprn# show router 1 ospf neighbor
===============================================================================
OSPF Neighbors
===============================================================================
Interface-Name
Rtr Id
State
Pri RetxQ
TTL
------------------------------------------------------------------------------PE-1-CE-1
192.0.2.5
Full
1
2
33
------------------------------------------------------------------------------No. of Neighbors: 1
===============================================================================

On CE-1:
A:CE-1# show router ospf neighbor
===============================================================================
OSPF Neighbors
===============================================================================
Interface-Name
Rtr Id
State
Pri RetxQ
TTL
------------------------------------------------------------------------------CE-1-PE-1
192.0.2.1
Full
1
0
31
------------------------------------------------------------------------------No. of Neighbors: 1
===============================================================================

Advanced Configuration Guide

Page 349

Configuration

Then, enable BFD on the PE-1-CE-1 interface on PE-1.


configure service vprn 1 ospf area 0.0.0.0 interface PE-1-CE-1 bfd-enable

Enable BFD on the CE-1-PE-1 interface on CE-1.


configure router ospf area 0.0.0.0 interface CE-1-PE-1 bfd-enable

Finally, check that the BFD sessions are up in both PE-1 and CE-1.
A:PE-1# show router 1 bfd session
===============================================================================
BFD Session
===============================================================================
Interface
State
Tx Intvl Rx Intvl Multipl
Remote Address
Protocols
Tx Pkts
Rx Pkts
Type
------------------------------------------------------------------------------PE-1-CE-1
Up (3)
100
100
3
172.16.0.2
ospf2
6331
6340
iom
------------------------------------------------------------------------------No. of BFD sessions: 1

A:CE-1# show router bfd session


===============================================================================
BFD Session
===============================================================================
Interface
State
Tx Intvl Rx Intvl Multipl
Remote Address
Protocols
Tx Pkts
Rx Pkts
Type
------------------------------------------------------------------------------CE-1-PE-1
Up (3)
100
100
3
172.16.0.1
ospf2
6691
6682
iom
------------------------------------------------------------------------------No. of BFD sessions: 1

Page 350

Advanced Configuration Guide

Bi-Directional Forwarding Detection

BFD within IPSec Tunnels


The ability to assign a BFD session to a given static LAN-to-LAN IPSec tunnel that provides
heart-beat mechanism for fast failure detection has been introduced in Release.8.0.
IPSec needs a Multiservice Integrated Service Adapter (MS-ISA) installed, so this scenario is only
applicable to 7750 SR-7/12 equipped with IOM-2 or 3.
In this section, the topology is shown in Figure 64.

Interface Private-ipsec
192.168.2.254/24
Interface Public-ipsec
192.168.2.1/24
Interface to Internet
192.168.1.1/24

ISA-IPsec
SAP ipsec-1.public:1

SAP ipsec-1.private:1

VPRN 2
BFD Session
Loopback i/f
172.16.2.1/32

10.1.1.0/24
172.16.1.1

Private Service
t1

Internet

t2

10.1.2.0/24

t3
172.16.1.2

IPsec Tunnel
IES/
VPRN 1

Public Service

OSSG564

Figure 64: BFD Sessions within IPSec Tunnels

The first step is to configure MS-ISA card as type isa-tunnel.


configure
card 1
card-type iom3-xp
mda 1
mda-type isa-tunnel
exit
mda 2
mda-type m10-1gb-sfp-b
exit
exit
exit

Advanced Configuration Guide

Page 351

Configuration

Next, instantiate the tunnels t1, t2 and t3 from the private service (in this example, VPRN 2) to the
peers passing through the public service (in this example VPRN 1, but it could be instead an IES).
Since the configuration of IPSec tunnels is out of the scope of this section, only relevant command
lines are reported to configure the interfaces shown in Figure 64.
configure service
vprn 1 customer 1 create
route-distinguisher 1:1
interface toInternet create
address 192.168.1.1/24
sap 1/2/1 create
exit
exit
interface public-ipsec create
address 192.168.2.1/24
sap tunnel-1.public:1 create
exit
exit
no shutdown
exit
vprn 2 customer 1 create
ipsec
security-policy 1 create
entry 10 create
local-ip 192.168.3.1/32
remote-ip any
exit
exit
exit
route-distinguisher 1:2
interface private-ipsec tunnel create
sap tunnel-1.private:1 create
ipsec-tunnel t1 create
local-gateway-address 192.168.2.254 peer 172.16.1.1 delivery-service 1
exit
exit
ipsec-tunnel t2 create
local-gateway-address 192.168.2.254 peer 172.16.1.2 delivery-service 1
exit
exit
ipsec-tunnel t3 create
local-gateway-address 192.168.2.254 peer 172.16.1.2 delivery-service 1
exit
exit
exit
exit
interface loop create
address 172.16.2.1/32
loopback
exit
static-route 10.1.1.0/24 ipsec-tunnel t1
static-route 10.1.2.0/24 ipsec-tunnel t2 metric 1
static-route 10.1.2.0/24 ipsec-tunnel t3 metric 5
no shutdown

Page 352

Advanced Configuration Guide

Bi-Directional Forwarding Detection

Then configure the BFD parameters within loopback interface loop (refer to BFD Base Parameter
Configuration and Troubleshooting on page 321).
configure service vprn 2
interface loop
bfd 100 receive 100 multiplier 3
exit
exit
And finally enable BFD within the tunnels.
configure service
vprn 2
interface private-ipsec tunnel
sap tunnel-1.private:1
ipsec-tunnel t1
bfd-enable service 2 interface loop dst-ip 172.16.1.1
exit
ipsec-tunnel t2
bfd-enable service 2 interface loop dst-ip 172.16.1.2
bfd-designate
exit
ipsec-tunnel t3
bfd-enable service 2 interface loop dst-ip 172.16.1.2
exit all

The BFD-enable parameters are as follows:

service <service-id> Specifies the service-id where the BFD session resides.

interface <interface-name> Specifies the name of the interface used by the BFD
session.

dst-ip <ip-address> Specifies the destination address to be used for the BFD session.

The following statements are to be taken into consideration to correctly configure BFD in this
environment:

BFD over IPSec sessions are centralized, managed by the hardware on the CPM.

Only BFD over static lan-to-lan tunnel is supported in Release 8.0 (not dynamic).

Only one BFD session is allowed between a given source/destination address pair.

Each tunnel can be associated to only one BFD session but multiple tunnels can be
associated to the same BFD session.

In case of multiple tunnels sharing the same BFD session, one IPSec tunnel carries BFD
traffic: the BFD-DESIGNATED tunnel.

Referring to Figure 64 and to the above configuration, the tunnels t2 and t3 share the same BFDsession. Tunnel t2 is the bfd-designated tunnel, the BFD session runs within it and the other tunnel
t3 shares its BFD session. If the BFD session goes down, the system will bring down both the
designated tunnel t2 and the associated tunnel t3.

Advanced Configuration Guide

Page 353

Configuration

The state machine in Figure 65 shows the decision process in case of shared BFD sessions.

Start

Warning
Message

False:
Down or Init

Bfd-designated
Flag

True
Sys Brings
Tunnel Up

False
Corresponding BFD
Session UP

False
Bfd Session Down

True
True

No Action

Sys Brings Down


Associated
Ipsec Tunnels
OSSG565

Figure 65: Logic for Shared BFD Sessions

Page 354

Advanced Configuration Guide

Bi-Directional Forwarding Detection

BFD for VRRP


This feature assigns a BFD session to provide a heart-beat mechanism for the given VRRP/SRRP
instance. It should be noted that there can be only one BFD session assigned to any given VRRP/
SRRP instance, but there can be multiple SRRP/VRRP sessions using the same BFD session.
In this section, the topology is shown in Figure 66.

PE-3
.3

.3

10.2.3.0/24

.2

PE-2

10.1.3.0/24

1/1/2
1/1/1

1/1/2
10.1.2.0/24

BFD Session

.2
VRID 10 (Backup)
192.168.1.1
VRID 30 (Master)
192.168.1.2

PE-1

1/1/1
.1

.2
IES 10
vrrp_ies_PE2
sap 1/1/3:10

.1

IES 10
vrrp_ies_PE1
sap 1/1/3:10
.1

VRRP

LAN 192.168.1.0

VRID 10 (Master)
192.168.1.1
VRID 30 (Backup)
192.168.1.2

OSSG566

Figure 66: BFD for VRRP

First, create the LAN subnet. Two PE routers are connected by IES or VPRN services (in
following examples IES 10 is created in both routers).
On PE-1:
configure service ies 10 customer 1 create
interface vrrp_ies_PE1 create
address 192.168.1.1/24
sap 1/1/3:10 create
exit
exit

Advanced Configuration Guide

Page 355

Configuration

no shutdown
exit

On PE-2:
configure service ies 10 customer 1 create
interface vrrp_ies_PE2 create
address 192.168.1.2/24
sap 1/1/3:10 create
exit
exit
no shutdown
exit

Verify that the IES services are operational (show service service-using) and verify that you can
ping the remote interface IP address.
Next, configure the VRRP parameters for both PE-1 and PE-2, enable VRRP on the IES interface
that connects to the 192.168.1.0/24 subnet.
In this section, the configurations are shown for the VRRP owner mode for master but any other
scenario for VRRP can be configured (non owner mode for master).
In the following examples two VRRP instances are created on the 192.168.1.0/24 subnet:
VRID = 10

Master (owner) = PE-1


Backup = PE-2
VRRP IP = 192.168.1.1
VRID = 30
Master (owner) = PE-2
Backup = PE-1
VRRP IP = 192.168.1.2
Host 1 is configured with default gateway = 192.168.1.1
Host 2 is configured with default gateway = 192.168.1.2

On PE-1:
configure service ies 10 interface vrrp_ies_PE1
vrrp 10 owner
backup 192.168.1.1
exit
vrrp 30
backup 192.168.1.2
ping-reply
telnet-reply
ssh-reply
exit

Page 356

Advanced Configuration Guide

Bi-Directional Forwarding Detection

On PE-2:
configure service ies 10 interface vrrp_ies_PE2
vrrp 10
backup 192.168.1.1
ping-reply
telnet-reply
ssh-reply
exit
vrrp 30 owner
backup 192.168.1.2
exit

To bind the VRRP instances with a BFD session, add the following command under any VRRP
instance: bfd-enable service-id interface interface-name dst-ip ip-address.
Note that the IES service-id must be declared where the interface is configured.
On PE-1:
configure service ies 10 interface vrrp_ies_PE1
vrrp 10 owner
bfd-enable 10 interface vrrp_ies_PE1 dst-ip 192.168.1.2
exit
vrrp 30
bfd-enable 10 interface vrrp_ies_PE1 dst-ip 192.168.1.2
exit

On PE-2:
configure service ies 10 interface vrrp_ies_PE2
vrrp 10 owner
bfd-enable 10 interface vrrp_ies_PE2 dst-ip 192.168.1.1
exit
vrrp 30
bfd-enable 10 interface vrrp_ies_PE2 dst-ip 192.168.1.1
exit

The parameters used for the BFD are set by the BFD command under the IP interface.
Note that unlike the previous scenarios, the user can enter the commands above, enabling the BFD
session, even if the specified interface (vrrp_ies_PE1) has not been configured with BFD
parameters.
If it has not been configured yet, the BFD session will be initiated only after the following
configuration.

Advanced Configuration Guide

Page 357

Configuration

On PE-1:
configure service ies 10 interface vrrp_ies_PE1
bfd 1000 receive 1000 multiplier 3

On PE-2:
configure service ies 10 interface vrrp_ies_PE2
bfd 1000 receive 1000 multiplier 3

Finally, verify that the BFD session is up (for instance on PE-1):


A:PE1>show router bfd session src 192.168.1.1 detail
===============================================================================
BFD Session
===============================================================================
Remote Address : 192.168.1.2
Admin State
: Up
Oper State
: Up (3)
Protocols
: vrrp
Rx Interval
: 100
Tx Interval
: 100
Multiplier
: 3
Echo Interval
: 0
Recd Msgs
: 7404
Sent Msgs
: 7412
Up Time
: 0d 00:04:26
Up Transitions
: 2
Down Time
: None
Down Transitions : 1
Version Mismatch : 0
Forwarding Information
Local Discr
: 4006
Local State
: Up (3)
Local Diag
: 1 (Detect time expired) Local Mode
: Async
Local Min Tx
: 100
Local Mult
: 3
Last Sent
: 12/14/2010 17:44:34
Local Min Rx
: 100
Type
: iom
Remote Discr
: 4003
Remote State
: Up (3)
Remote Diag
: 1 (Detect time expired) Remote Mode
: Async
Remote Min Tx : 100
Remote Mult
: 3
Last Recv
: 12/14/2010 17:44:34
Remote Min Rx
: 100
===============================================================================

This session is shared by all the VRRP instances configured between the specified interfaces.
When BFD is configured in a VRRP instance, the following command gives details of BFD
related to every instance:
show router vrrp instance interface vrrp_ies_PE1
===============================================================================
VRRP Instances for interface vrrp_ies_PE1
===============================================================================
------------------------------------------------------------------------------VRID 10

Page 358

Advanced Configuration Guide

Bi-Directional Forwarding Detection

------------------------------------------------------------------------------Owner
: Yes
VRRP State
: Master
Primary IP of Master: 192.168.1.1 (Self)
Primary IP
: 192.168.1.1
Standby-Forwarding: Disabled
VRRP Backup Addr
: 192.168.1.1
Admin State
: Up
Oper State
: Up
Up Time
: 12/14/2010 16:47:47 Virt MAC Addr
: 00:00:5e:00:01:0a
Auth Type
: None
Config Mesg Intvl
: 1
In-Use Mesg Intvl : 1
Base Priority
: 255
In-Use Priority
: 255
Init Delay
: 0
Init Timer Expires: 0.000 sec
Creation State
: Active
------------------------------------------------------------------------------BFD Interface
------------------------------------------------------------------------------Service ID
: 10
Interface Name
: vrrp_ies_PE1
Src IP
: 192.168.1.1
Dst IP
: 192.168.1.2
Session Oper State : connected
------------------------------------------------------------------------------Master Information
------------------------------------------------------------------------------Primary IP of Master: 192.168.1.1 (Self)
Addr List Mismatch : No
Master Priority
: 255
Master Since
: 12/14/2010 16:47:47
------------------------------------------------------------------------------Masters Seen (Last 32)
------------------------------------------------------------------------------Primary IP of Master
Last Seen
Addr List Mismatch
Msg Count
------------------------------------------------------------------------------192.168.1.1
12/14/2010 16:47:47
No
0
192.168.1.2
12/14/2010 17:39:57
No
5
------------------------------------------------------------------------------Statistics
------------------------------------------------------------------------------Become Master
: 7
Master Changes
: 7
Adv Sent
: 347577
Adv Received
: 5
Pri Zero Pkts Sent : 6
Pri Zero Pkts Rcvd: 0
Preempt Events
: 0
Preempted Events : 0
Mesg Intvl Discards : 0
Mesg Intvl Errors : 0
Addr List Discards : 0
Addr List Errors : 0
Auth Type Mismatch : 0
Auth Failures
: 0
Invalid Auth Type
: 0
Invalid Pkt Type : 0
IP TTL Errors
: 0
Pkt Length Errors : 0
Total Discards
: 0
------------------------------------------------------------------------------VRID 30
------------------------------------------------------------------------------Owner
: No
VRRP State
: Backup
Primary IP of Master: 192.168.1.2 (Other)
Primary IP
: 192.168.1.1
Standby-Forwarding: Disabled
VRRP Backup Addr
: 192.168.1.2
Admin State
: Up
Oper State
: Up
Up Time
: 12/14/2010 17:39:49 Virt MAC Addr
: 00:00:5e:00:01:1e
Auth Type
: None
Config Mesg Intvl
: 1
In-Use Mesg Intvl : 1
Master Inherit Intvl: No

Advanced Configuration Guide

Page 359

Configuration

Base Priority
: 100
In-Use Priority
: 100
Policy ID
: n/a
Preempt Mode
: Yes
Ping Reply
: Yes
Telnet Reply
: Yes
SSH Reply
: Yes
Traceroute Reply : No
Init Delay
: 0
Init Timer Expires: 0.000 sec
Creation State
: Active
------------------------------------------------------------------------------BFD Interface
------------------------------------------------------------------------------Service ID
: 10
Interface Name
: vrrp_ies_PE1
Src IP
: 192.168.1.1
Dst IP
: 192.168.1.2
Session Oper State : connected
------------------------------------------------------------------------------Master Information
------------------------------------------------------------------------------Primary IP of Master: 192.168.1.2 (Other)
Addr List Mismatch : No
Master Priority
: 255
Master Since
: 12/14/2010 17:39:57
Master Down Interval: 3.609 sec (Expires in 3.000 sec)
------------------------------------------------------------------------------Masters Seen (Last 32)
------------------------------------------------------------------------------Primary IP of Master
Last Seen
Addr List Mismatch
Msg Count
------------------------------------------------------------------------------192.168.1.1
12/14/2010 17:39:57
No
0
192.168.1.2
12/14/2010 17:54:03
No
342583
------------------------------------------------------------------------------Statistics
------------------------------------------------------------------------------Become Master
: 6
Master Changes
: 11
Adv Sent
: 4441
Adv Received
: 342583
Pri Zero Pkts Sent : 1
Pri Zero Pkts Rcvd: 0
Preempt Events
: 0
Preempted Events : 5
Mesg Intvl Discards : 0
Mesg Intvl Errors : 0
Addr List Discards : 0
Addr List Errors : 338989
Auth Type Mismatch : 0
Auth Failures
: 0
Invalid Auth Type
: 0
Invalid Pkt Type : 0
IP TTL Errors
: 0
Pkt Length Errors : 0
Total Discards
: 0
===============================================================================

Finally, for troubleshooting: it could be that the BFD session between the two IP interfaces is up
but (in one or both peers) the command show router vrrp instance interface interface-name
gives the following output regarding BFD for one or more VRID's.
-------------------------------------------------------------------------------BFD Interface
------------------------------------------------------------------------------Service ID
: None
Interface Name
: vrrp_ies_PE2
Src IP
: 0.0.0.0
Dst IP
: 192.168.1.1
Session Oper State : notConfigured
---------------------------------------------------------------------------------

Page 360

Advanced Configuration Guide

Bi-Directional Forwarding Detection

To fix this, check that BFD has been correctly configured for the VRRP istances.
For instance, in the following example, the cause of the misconfiguration is that the IES service-id
is not declared in the bfd-enable command:
configure service ies 10 interface vrrp_ies_PE2
vrrp 10 owner
bfd-enable interface vrrp_ies_PE2 dst-ip 192.168.1.1
exit

Advanced Configuration Guide

Page 361

Conclusion

Conclusion
BFD is a light-weight protocol which provides rapid path failure detection between two systems
and it is useful in situations where the physical network has numerous intervening hops which are
not part of the Layer 3 network.
BFD is linked to a protocol state. For BFD session to be established, the prerequisite condition is
that the protocol to which the BFD is linked must be operationally active. Once the BFD session is
established, the state of the protocol to which BFD is tied to is then determined based on the BFD
sessions state. This means that if the BFD session goes down, the corresponding protocol will be
brought down.
In this section every scenario where BFD could be implemented has been described, including the
configuration, show output and troubleshooting hints.

Page 362

Advanced Configuration Guide

Bridged CO

In This Chapter
This section provides information about Bridged CO model of Triple Play Service Delivery
Architecture (TPSDA).
Topics in this section include:

Applicability on page 364

Overview on page 366

Configuration on page 372

Conclusion on page 403

Advanced Configuration Guide

Page 363

Applicability

Applicability
This section is applicable to the 7750 SR, 7710 SR and 7450 ESS series and was tested on SROS 7.0 R4. Chassis mode B or higher must be used. The 7750 SR-c4 is supported from 8.0R4 and
higher. This note is related only to the use of IPv4 DHCP hosts.

Page 364

Advanced Configuration Guide

Bridged CO

Summary
This section provides information about basic technology, network topology and configuration
examples which are used in Bridged CO model of Triple Play Service Delivery Architecture
(TPSDA). Regardless of aggregation technologies which are used by customers Alcatel-Lucent
offers flexible and easy to use methodology to manage DHCP subscribers in Layer 2 domain and
distribute subscriber management intelligence across multiple nodes.
Knowledge of the Alcatel-Lucent Triple Play Service Delivery Architecture (TPSDA) concepts is
assumed throughout this section.

Advanced Configuration Guide

Page 365

Overview

Overview
Bridged CO is a basic TPSDA model and implies that access nodes are united in one Layer 2
aggregation network and VPLS is used as a primary technology for these purposes. This fact
allows the use of subscriber management functionality on BSA nodes. Bridged CO network
topology is shown in Figure 67.

DSL,
GPON

VPLS

BSAN

IES/
VPRN

BSA
BSR

Internet

RADIUS
DHCP

Aggregation
Network

VoIP

Video Server

Services
Network
OSSG441

Figure 67: Bridged CO Network Topology

Following types of nodes are defined in Bridged CO model:

Broadband Service Access Node (BSAN) Access node connected to Layer 2 domain to
aggregate all traffic from subscribers (IP DSLAM, ethernet switch).

Broadband Services Aggregator (BSA) Layer 2 node, which is capable for subscriber
management in VPLS service (7450 ESS).

Broadband Service Router (BSR) Layer 3 node, which is capable for routing and
service allocation (7750 SR).

As any model, Bridged CO introduces several key concepts that must be determined in advance.
Major ones are presented in Figure 68 and include:

Page 366

Subscriber A set of hosts belonging to a single connection line (switch port, DSL line)

Subscriber host Unique customer device (could be PC, IP phone, STB, routed CPE).

Subscriber-profile Configured entity which defines the aggregate QoS for all hosts
within a subscriber context.

SLA-profile Configured entity which defines QoS policies and filters for a subset of
hosts within a subscriber context.

Advanced Configuration Guide

Bridged CO

Subscriber identification policy Configured entity which defines the python script for
dynamic subscriber host identification

Authentication policy Configured entity which defines the RADIUS servers to use for
dynamic subscriber host identification

Subscriber identification string 32 characters identification string which uniquely


identifies a subscriber on a node.

Interface

SAP-1
(HSI)

Sub-1
Sub-2

SAP-2
(VoIP)

Sub-1
Sub-2

SAP-3
(Video)

Sub-1
Sub-2

Subscriber

Scheduler

Scheduler
BSA

Subscriber Host

Subscriber SAP

SLA Profile

Subscriber Profile
OSSG447

Figure 68: Key Concepts of Bridged CO Model

For normal operation each subscriber has to get several parameters / attributes:

Subscriber-ID Attribute, which uniquely identifies subscriber on the node and used as
index key in subscriber database

IP parameters Attributes, which allows host to get access to services

Subscriber profile and SLA Profile for subscriber host ?a set of filters and QoS
policies.

Lease time Period when subscriber parameters are kept in subscriber database on the
node.

Advanced Configuration Guide

Page 367

Overview

There are several methods how to get each of these parameters:

Static

Python scripts

RADIUS

DHCP

Each of the subscriber parameters could be defined in several ways simultaneously. In this case
use the following algorithm for selecting:
Step 1. For subscriber profile
Step 1.1 A lookup in the subscriber-explicit-map is performed with the sub-ident string

returned by the Python script, RADIUS or statically configured. If a matching


entry is found, the sub-profile-name (if defined) is taken. If no entry was found
go to Step 1.2.
A:BSA>config>subscr-mgmt# info
explicit-subscriber-map
entry key "Sub-1" sub-profile "sub-profile-1" sla-profile "sla-profile-1"

Step 1.2 If a sub-ident-policy is defined on the SAP, a lookup is done on its sub-profile-

map with the sub-profile string from the script. The sub-profile-name is taken
from the entry. If no entry was found go to Step 1.3.
A:BSA>config>service>vpls>sap# info
sub-sla-mgmt
sub-ident-policy "sub-ident-policy-1"
A:BSA>config>subscr-mgmt# info
sub-ident-policy "sub-ident-policy-1" create
sub-profile-map
entry key "sub-1" sub-profile "sub-profile-1"

Step 1.3 If provisioned, the sub-profile-name is taken from the def-sub-profile attribute

on the SAP. If no entry was found go to Step 1.4.


A:BSA>config>service>vpls>sap# info
sub-sla-mgmt
def-sub-profile "sub-profile-1"

Step 1.4 If a sub-profile with the name default is provisioned. If no entry was found

DHCP Ack is dropped.


A:BSA>config>subscr-mgmt# info
sub-profile "default" create

Page 368

Advanced Configuration Guide

Bridged CO

Sub-ident string is returned by Python script, RADIUS or statically configured

Found
Correspondence in
subscriber-explicit-map

NO

Found
Correspondence in
sub-profile-map
on SAP

YES

NO

YES

Found
Correspondence in
def-sub-profile
on SAP

NO

YES

Found
Sub-profile
with name
default
YES

NO

Accept and use


Reject
DHCP
Ack
OSSG451

Figure 69: Flow Chart for Subscriber-Profile Identification Algorithm

Step 2.

For SLA profile

Step 2.1 The sla-profile-name is taken from the sub-ident string (returned by the Python

script, RADIUS or statically configured) in the subscriber-explicit-map. If no


entry was found go to Step 2.2.
A:BSA>config>subscr-mgmt# info
explicit-subscriber-map
entry key "Sub-1" sub-profile "sub-profile-1" sla-profile "sla-profile-1"

Step 2.2 A lookup with the sla-profile string from the script is done in the sla-profile-map

of the sub-profile found earlier. The corresponding sla-profile-name is used. If


no entry was found go to Step 2.3:
A:BSA>config>subscr-mgmt# info
sub-profile "sub-profile-1" create
sla-profile-map
entry key "sla-1" sla-profile "sla-profile-1"

Step 2.3 The sla-profile-name is taken from sla-profile-map of the sub-ident-policy

configured on the SAP. The corresponding sla-profile-name is used. If no entry


was found go to Step 2.4.
A:BSA>config>service>vpls>sap# info
sub-sla-mgmt
sub-ident-policy "sub-ident-policy-1"
A:BSA>config>subscr-mgmt# info
sub-ident-policy "sub-ident-policy-1" create
sla-profile-map
entry key "sla-1" sla-profile "sla-profile-1"

Advanced Configuration Guide

Page 369

Overview

Step 2.4 The sla-profile-name is taken from the def-sla-profile attribute on the SAP. If no

entry was found DHCP Ack is dropped.


A:BSA>config>service>vpls>sap# info
sub-sla-mgmt
def-sla-profile "sla-profile-1"

Sla-profile string is returned by Python script, RADIUS or statically configured

Found
Correspondence in
sub-indent string in
subscriber-explicit-map

YES

NO

Found
Correspondence in
sub-profile-map
of sub-profile
found earlier

NO

YES

Found
Correspondence in
sla-profile-map
of sub-ident-policy
on SAP

NO

Found
Correspondence in
def-sla-profile
on SAP

YES

NO

YES

Accept and use


Reject
DHCP
Ack
OSSG452

Figure 70: Flowchart for SLA-Profile Identification Algorithm

Note: static configuration has priority over RADIUS configuration and RADIUS has priority over
DHCP/Python scripts.
Note: each host can have different SLA-profile, while sub-profile applies to whole subscriber. The
last definition of sub-profile will force all previously defined hosts to change their sub-profile.
Bridged CO supports typical access node connection models, such as:

One VLAN per service (ESM for subscriber differentiation and SAP for service)

One VLAN per subscriber (SAP for subscriber differentiation and QoS flag for service)

One VLAN per access node (ESM for subscriber differentiation and QoS flag for service)

Each of these modes has its pros and cons, but this is out of scope of this document.
This configuration guide focuses on configuration of one subscriber with three different hosts.
VLAN per service is used as mode of subscriber aggregation and mixed RADIUS and DHCP as
subscriber identification method. IP termination is done in IES service of BSR.

Page 370

Advanced Configuration Guide

Bridged CO

Correlation of BSA/BSR services and subscriber hosts is presented in Table 7.


Table 7: Correlation of Hosts and BSA/BSR Services
BSA (Service/Features)

BSR (Service/Features)

Host-1
ca:00:0c:54:00:08

VPLS-100
DHCP proxy server
SAP/SDP DHCP snoop
Sub-Ident origin via RADIUS
Sla/Sub-profiles via RADIUS
IP options via RADIUS

IES-100

Host-2
ca:01:08:10:00:08

VPLS-200
SAP/SDP DHCP snoop
Sub-Ident origin through RADIUS
Sla/Sub-profiles through RADIUS
IP options through DHCP

IES-200
DHCP relay

Host-3
ca:02:02:d0:00:08

VPLS-300
SAP/SDP DHCP snoop
Sub-Ident origin through DHCP
Sla/Sub-profiles through DHCP
IP options through DHCP

IES-300
DHCP relay

Different methods of authentication and address allocation were chosen for demonstration
purposes. The customer is not limited to one method and can use a combination of methods as
presented in this guide.
The following entities should be configured in advanced. Refer to the appropriate platform user
guide for specific information. See Preface on page 23 for a list of documents.

Basic router configuration (interfaces, routing protocols, MPLS)

External RADIUS server

External/Local DHCP server

Advanced Configuration Guide

Page 371

Configuration

Configuration
A sample topology is presented in Figure 71

RADIUS
Video Server
SAP 1/1/1

IES/
VPRN

VPLS
BSA

VoIP

BSR
Internet
VLAN 100

VPLS100

spoke-sdp

IES100

VLAN 200

VPLS200

spoke-sdp

IES200

VLAN 300

VPLS300

spoke-sdp

IES300
OSSG446

Figure 71: Sample Topology

Bridged CO model requires certain techniques and features to be used on different nodes. Major
methods are presented in Figure 72.

Interface DHCP
Loopback
SAP

DHCP
Host

DHCP Client

DHCP Snoop
DHCP Proxy
L2 DHCP Relay

SDP

Interface

VPLS

IES

BSA

BSR

DHCP Snoop

DHCP Relay

Local DHCP
Server

RADIUS

RADIUS

OSSG442

Figure 72: Functionality of Each Node

Page 372

Advanced Configuration Guide

Bridged CO

The following configuration steps are required:


Step 1. On BSA
Step 1.1 Configure subscriber management profiles
Step 1.1.1 Configure sla profiles
Step 1.1.2 Configure subscriber profiles
Step 1.1.3 Configure subscriber identification policies
Step 1.1.4 Configure authentication and accounting policies if required
Step 1.2 Configure VPLS service
Step 1.2.1 Configure split horizon group
Step 1.2.2 Configure SAP
Step 1.2.2.1 Configure anti-spoofing filters
Step 1.2.2.2 Configure DHCP snooping
Step 1.2.2.3 Configure optional parameters (lease split, L2 DHCP relay agent,

etc.)
Step 1.2.2.4 In case of RADIUS authentication apply authentication policy
Step 1.2.2.5 Configure ESM
Step 1.2.3 Configure SDP
Step 1.2.3.1 Configure DHCP snooping
Step 2.

On BSR

Step 2.1 Configure IES service


Step 2.1.1 Configure IP interface
Step 2.1.1.1 Configure DHCP relay agent if required

Advanced Configuration Guide

Page 373

Configuration

Basic ESM Configuration on BSA


Subscriber management is enabled on BSA in Bridged CO model. A relevant configuration is
presented below. SLA and subscriber profiles show the default configurations. The authentication
policy appeals to RADIUS server 192.0.2.5. The subscriber identification policy is configured to
use DHCP Option 254 to transfer custom attributes (subscriber-id, sla-profile, sub-profile, etc.)
A:BSA>config>subscr-mgmt# info
authentication-policy "auth-policy-1" create
password password-1
radius-authentication-server
router "management"
server 1 address 192.0.2.5 secret ALU
exit
include-radius-attribute
circuit-id
remote-id
nas-port-id
nas-identifier
exit
exit
sla-profile "sla-profile-1" create
exit
sla-profile "sla-profile-2" create
exit
sla-profile "sla-profile-3" create
exit
sla-profile "sla-profile-default" create
exit
sub-profile "sub-profile-1" create
exit
sub-profile "sub-profile-default" create
exit
sub-ident-policy "sub-ident-policy-1" create
sub-profile-map
use-direct-map-as-default
exit
sla-profile-map
use-direct-map-as-default
exit
strings-from-option 254
exit

The string-from-option 254 command is shared in-built dhcp-server of BSR. Using this option,
the DHCP server could transmit subscriber identification options such the subscriber-id, slaprofile-string, and sub-profile-string.

Page 374

Advanced Configuration Guide

Bridged CO

BSA/BSR Configuration for Host-1 Operation


The test subscriber has three hosts. Host-1 gets all necessary information from RADIUS server.
Table 8: BSA/BSR Configuration for Host-1 Operation
BSA
(Service/Features)

Host-1
ca:00:0c:54:00:08

VPLS-100
DHCP proxy server
SAP/SDP DHCP snoop
Sub-Ident origin through RADIUS
Sla/Sub-profiles through RADIUS
IP options through RADIUS

BSR
(Service/Features)

IES-100

In this case BSA takes role of DHCP proxy with DHCP server emulation. DHCP snooping on the
SAP must be enabled. Anti-spoofing filters on the SAP must be enabled. An authentication policy
must be applied on the SAP.
vpls 100 customer 1 create
split-horizon-group "RSHG-1" residential-group create
exit
--snip-sap 1/1/4:100 split-horizon-group "RSHG-1" create
dhcp
snoop
lease-populate 400
proxy-server
emulated-server 10.0.1.253
no shutdown
exit
no shutdown
exit
authentication-policy "auth-policy-1"
anti-spoof ip-mac
sub-sla-mgmt
def-sub-id string "default-subscriber"
def-sub-profile "sub-profile-default"
def-sla-profile "sla-profile-default"
sub-ident-policy "sub-ident-policy-1"
no shutdown
exit
exit
spoke-sdp 12:100 create
exit
no shutdown
exit

Advanced Configuration Guide

Page 375

Configuration

On BSR IES-100, the service is configured with a pure IP interface, which plays role of DG for
host-1.
ies 100 customer 1 create
interface "int-host-1" create
address 10.0.1.254/24
spoke-sdp 21:100 create
exit
exit
no shutdown
exit

BSA/BSR Configuration for Host-2 Operation


The test subscriber has three hosts. Host-2 gets subscriber-id and sla/sub-profiles information from
RADIUS server and IP options from DHCP server.
Table 9: BSA/BSR Configuration for Host-2 Operation
BSA
(Service/Features)

Host-2
ca:01:08:10:00:08

VPLS-200
SAP/SDP DHCP snoop
Sub-Ident origin through RADIUS
Sla/Sub-profiles through RADIUS
IP options through DHCP

BSR
(Service/Features)

IES-200
DHCP relay

DHCP snooping on the SAP and SDP must be enabled. Anti-spoofing filters on the SAP must be
enabled.
vpls 200 customer 1 create
split-horizon-group "RSHG-1" residential-group create
exit
--snip-sap 1/1/4:200 split-horizon-group "RSHG-1" create
dhcp
snoop
lease-populate 400
no shutdown
exit
authentication-policy "auth-policy-1"
anti-spoof ip-mac
sub-sla-mgmt
def-sub-id string "default-subscriber"
def-sub-profile "sub-profile-default"

Page 376

Advanced Configuration Guide

Bridged CO

def-sla-profile "sla-profile-default"
sub-ident-policy "sub-ident-policy-1"
no shutdown
exit
exit
spoke-sdp 12:200 create
dhcp
snoop
exit
exit
no shutdown
exit

On BSR IES-200, the service is configured with an IP interface which as the DG for Host-2.
DHCP relay must be configured to transform broadcast DHCP discover message into unicast and
send it to DHCP server for processing.
ies 200 customer 1 create
interface "int-host-2" create
address 10.0.2.254/24
dhcp
server 192.0.2.4
trusted
no shutdown
exit
spoke-sdp 21:200 create
exit
exit
no shutdown
exit

Advanced Configuration Guide

Page 377

Configuration

BSA/BSR Configuration for Host-3 Operation


The test subscriber has three hosts. Host-3 receives all necessary information from the DHCP
server.
Table 10: BSA/BSR Configuration for Host-3 Operation
BSA
(Service/Features)

Host-3
ca:02:02:d0:00:08

VPLS-300
* SAP/SDP DHCP snoop
* Sub-Ident origin through DHCP
* Sla/Sub-profiles through DHCP
* IP options through DHCP

BSR
(Service/Features)

IES-300
* DHCP relay

DHCP snooping on the SAP and SDP must be enabled. Anti-spoofing filters on the SAP must be
enabled.
vpls 300 customer 1 create
split-horizon-group "RSHG-1" residential-group create
exit
---- snip --sap 1/1/4:300 split-horizon-group "RSHG-1" create
dhcp
snoop
lease-populate 400
no shutdown
exit
anti-spoof ip-mac
sub-sla-mgmt
def-sub-id string "default-subscriber"
def-sub-profile "sub-profile-default"
def-sla-profile "sla-profile-default"
sub-ident-policy "sub-ident-policy-1"
no shutdown
exit
exit
spoke-sdp 12:300 create
dhcp
snoop
exit
exit
no shutdown
exit

Page 378

Advanced Configuration Guide

Bridged CO

On BSR IES-300, the service is configured with IP interface, which plays role of DG for host-3.
DHCP relay must be configured to transform broadcast DHCP discover message into unicast and
send it to DHCP server for processing.
ies 300 customer 1 create
interface "int-host-3" create
address 10.0.3.254/24
dhcp
server 192.0.2.4
trusted
no shutdown
exit
spoke-sdp 21:300 create
exit
exit
no shutdown
exit

Advanced Configuration Guide

Page 379

Configuration

RADIUS Configuration Bridged CO


The username in the RADIUS access request is configurable and could be one of the following
formats1:

mac MAC Source Address of the DHCP DISCOVER message

circuit-id Taken from option 82 in the received DHCP message. If no circuit-id can be
found, the DHCP-msg is rejected.

tuple Concatenation of MAC source address and circuit-ID

ascii-converted-circuit-id Identical to circuit-id, but the user name will be sent to the
RADIUS server as a string of hex digits

ascii-converted-tuple Identical to tuple, but the circuit-id part of the user name will be
sent to the RADIUS server as a string of hex digits

Note: Refer to IPv4 DHCP Hosts on page 979 for detailed information about how to use different
options.
A:BSA>config>subscr-mgmt>auth-plcy# user-name-format
- user-name-format <format> [append domain-name]
- no user-name-format
<format>

: mac|circuit-id|tuple|ascii-converted-circuit-id|
ascii-converted-tuple

For simplicity, MAC format is used in this guide.


There are two hosts configured in the users file on RADIUS server:

a:00:0c:54:00:08 The mac address of host-1 host [VPLS/IES 100]. For host-1 all
necessary parameters are returned: subscriber-id, sla/sub-profiles, IP parameters and lease
time.

a:01:08:10:00:08 The mac address of host-2 host [VPLS/IES 200]. For host-2 only
subscriber-id, sla/sub-profiles are returned, while ip parameters and lease time are
returned from DHCP server.

ca:00:0c:54:00:08 Auth-Type := Local, User-Password == "password-1"


Alc-Subsc-ID-Str = "sub-id-1",
Alc-Subsc-Prof-Str == "sub-profile-1",
Alc-SLA-Prof-Str == "sla-profile-1",
Framed-IP-Address = 10.0.1.1,
Framed-IP-Netmask = 255.255.255.0,
Alc-Default-Router = 10.0.1.254,
Session-Timeout = 6000
ca:01:08:10:00:08 Auth-Type := Local, User-Password == "password-1"
Alc-Subsc-ID-Str = "sub-id-1",
Alc-Subsc-Prof-Str == "sub-profile-1",
Alc-SLA-Prof-Str == "sla-profile-2"

Page 380

Advanced Configuration Guide

Bridged CO

Local DHCP Server Configuration Bridged CO


In the setup local DHCP server is used with reference to local user database.
A:BSR>config>router>dhcp# info
local-dhcp-server "dhcp-server-1" create
user-db "user-db-1"
pool "pool-1" create
subnet 10.0.2.0/24 create
exit
subnet 10.0.3.0/24 create
exit
exit
no shutdown
exit

Note: Subnets must be configured, even if all IP parameters are returned from local user DB.
Without this option, DHCP server do not return IP parameters.
The local user database is configured on BSR. Identification is done via MAC address of a host,
which is taken from DHCP-Discover message. There are several possibilities to identify DHCP
host. match-list command is used for this purpose.
*A:BSR>config>subscr-mgmt>loc-user-db>dhcp#
match-list
- no match-list
- match-list <dhcp-match-type-1> [<dhcpmatch-type-2>...(up to 4 max)]
<dhcp-match-type>

: circuit-id|mac|option60|remote-id|sap-id|service-id|
string|system-id

There are two hosts configured:

a:01:08:10:00:08 mac address of host-2 [VPLS/IES 200]. DHCP returns ip address,


subnet mask and default route.

a:02:02:d0:00:08 mac address of host-3 [VPLS/IES 300]. DHCP returns all necessary
parameters: subscriber-id, sla/sub-profiles and all ip options.

A:BSR>config>subscr-mgmt# info
local-user-db "user-db-1" create
dhcp
match-list mac
host "host-2" create
host-identification
mac ca:01:08:10:00:08
exit
address 10.0.2.1
options
subnet-mask 255.255.255.0
default-router 10.0.2.254
exit

Advanced Configuration Guide

Page 381

Configuration

no shutdown
exit
host "host-3" create
host-identification
mac ca:02:02:d0:00:08
exit
address 10.0.3.1
identification-strings 254 create
subscriber-id "sub-id-1"
sla-profile-string "sla-profile-3"
sub-profile-string "sub-profile-1"
exit
options
subnet-mask 255.255.255.0
default-router 10.0.3.254
exit
no shutdown
exit
exit
no shutdown
exit

Page 382

Advanced Configuration Guide

Bridged CO

Setup Procedures and Debugging


Subscriber/Host Verification
The initialization of all active subscribers and hosts can be shown using the how service activesubscribers command. Different options can be used to filter the output of the command.
A:BSA# show service active-subscribers
===============================================================================
Active Subscribers
===============================================================================
------------------------------------------------------------------------------Subscriber sub-id-1 (sub-profile-1)
------------------------------------------------------------------------------------------------------------------------------------------------------------(1) SLA Profile Instance sap:1/1/4:100 - sla:sla-profile-1
------------------------------------------------------------------------------IP Address
MAC Address
PPPoE-SID Origin
------------------------------------------------------10.0.1.1
ca:00:0c:54:00:08 N/A
DHCP
------------------------------------------------------------------------------(2) SLA Profile Instance sap:1/1/4:200 - sla:sla-profile-2
------------------------------------------------------------------------------IP Address
MAC Address
PPPoE-SID Origin
------------------------------------------------------10.0.2.1
ca:01:08:10:00:08 N/A
DHCP
------------------------------------------------------------------------------(3) SLA Profile Instance sap:1/1/4:300 - sla:sla-profile-3
------------------------------------------------------------------------------IP Address
MAC Address
PPPoE-SID Origin
------------------------------------------------------10.0.3.1
ca:02:02:d0:00:08 N/A
DHCP
------------------------------------------------------------------------------Number of active subscribers : 1
===============================================================================
A:BSA#

Hierarchy of subscriber hosts is represented in a convenient form using following command.


A:BSA# show service active-subscribers hierarchy
===============================================================================
Active Subscriber hierarchy
===============================================================================
-- sub-id-1 (sub-profile-1)
|
|-- sap:1/1/4:100 - sla:sla-profile-1
|
|
|
|-- 10.0.1.1 - ca:00:0c:54:00:08 - N/A (DHCP)
|
|
|
|-- sap:1/1/4:200 - sla:sla-profile-2
|
|
|
|-- 10.0.2.1 - ca:01:08:10:00:08 - N/A (DHCP)
|
|

Advanced Configuration Guide

Page 383

Configuration

|
|-|
|
|

sap:1/1/4:300 - sla:sla-profile-3
|
|-- 10.0.3.1 - ca:02:02:d0:00:08 - N/A (DHCP)
|

Host-1 Setup Debug


The Host-1 setup process is shown in Figure 73.
Interface DHCP
DHCP
Loopback

SAP

Host 1

DHCP Client

SDP

Interface

VPLS

IES

BSA

BSR

DHCP Snoop
DHCP Proxy
L2 DHCP Relay

RADIUS

RADIUS

DHCP-DISCOVER
RADIUS-ACCESS-REQUEST
RADIUS-ACCESS-ACCEPT
DHCP-OFFER
DHCP-REQUEST
DHCP-ACK
OSSG443

Figure 73: Host-1 Setup Process

Host-1 sends DHCP discover message in VLAN 100 to BSA. BSA plays role of DHCP proxy
server and transforms DHCP discover into RADIUS access-request message. After receiving
RADIUS access-accept BSA transforms it to DHCP Ack message. Session setup process could be
represented using debug commands:
A:BSA# debug service id 100 dhcp mode egr-ingr-and-dropped
A:BSA# debug service id 100 dhcp detail-level medium
A:BSA# debug radius detail
18 2009/12/15 06:31:56.63 UTC MINOR: DEBUG #2001 Base SVCMGR
"SVCMGR: RX DHCP Packet
VPLS 100, SAP 1/1/4:100
BootRequest to UDP port 67
ciaddr: 0.0.0.0
yiaddr: 0.0.0.0
siaddr: 0.0.0.0
giaddr: 0.0.0.0
chaddr: ca:00:0c:54:00:08
xid: 0xd42

Page 384

Advanced Configuration Guide

Bridged CO

DHCP options:
[53] Message type: Discover
--snip-"
19 2009/12/15 06:31:56.63 UTC MINOR: DEBUG #2001 management RADIUS
"RADIUS: Access-Request
user ca:00:0c:54:00:08 policy auth-policy-1"
20 2009/12/15 06:31:56.63 UTC MINOR: DEBUG #2001 management RADIUS
"RADIUS: Transmit
Access-Request(1) 192.0.2.5:1812 id 69 len 85
USER NAME [1] 17 ca:00:0c:54:00:08
PASSWORD [2] 16 lkhSVrFePQ0A0Xc4ZyMwMk
NAS IP ADDRESS [4] 4 192.0.2.1
NAS PORT TYPE [61] 4 Ethernet(15)
NAS PORT ID [87] 9 1/1/4:100
NAS IDENTIFIER [32] 3 BSA
"
21 2009/12/15 06:31:56.73 UTC MINOR: DEBUG #2001 management RADIUS
"RADIUS: Receive
Access-Accept(2) id 69 len 108 from 138.203.18.79:1812
VSA [26] 10 Alcatel(6527)
SUBSC ID STR [11] 8 sub-id-1
VSA [26] 15 Alcatel(6527)
SUBSC PROF STR [12] 13 sub-profile-1
VSA [26] 15 Alcatel(6527)
SLA PROF STR [13] 13 sla-profile-1
FRAMED IP ADDRESS [8] 4 10.0.1.1
FRAMED IP NETMASK [9] 4 255.255.255.0
VSA [26] 6 Alcatel(6527)
DEFAULT ROUTER [18] 4 10.0.1.254
SESSION TIMEOUT [27] 4 6000
"
22 2009/12/15 06:31:56.73 UTC MINOR: DEBUG #2001 Base SVCMGR
"SVCMGR: TX DHCP Packet
VPLS 100, SAP 1/1/4:100
BootReply to UDP port 68
ciaddr: 0.0.0.0
yiaddr: 10.0.1.1
siaddr: 10.0.1.253
giaddr: 0.0.0.0
chaddr: ca:00:0c:54:00:08
xid: 0xd42
DHCP options:
[53] Message type: Offer
--snip-"
23 2009/12/15 06:31:57.57 UTC MINOR: DEBUG #2001 Base SVCMGR
"SVCMGR: RX DHCP Packet
VPLS 100, SAP 1/1/4:100
BootRequest to UDP port 67
ciaddr: 0.0.0.0
yiaddr: 0.0.0.0
siaddr: 0.0.0.0
giaddr: 0.0.0.0
chaddr: ca:00:0c:54:00:08
xid: 0xd42
DHCP options:
[53] Message type: Request
--snip-"

Advanced Configuration Guide

Page 385

Configuration

24 2009/12/15 06:31:57.57 UTC MINOR: DEBUG #2001 Base SVCMGR


"SVCMGR: TX DHCP Packet
VPLS 100, SAP 1/1/4:100
BootReply to UDP port 68
ciaddr: 0.0.0.0
yiaddr: 10.0.1.1
siaddr: 10.0.1.253
giaddr: 0.0.0.0
chaddr: ca:00:0c:54:00:08
xid: 0xd42
DHCP options:
[53] Message type: Ack
--snip

The number of snooped/forwarded/dropped/proxied DHCP packets can be checked using the


show service id 100 dhcp statistics command.
A:BSA# show service id 100 dhcp statistics
=====================================================
DHCP Statistics, service 100
=====================================================
Client Packets Snooped
: 2
Client Packets Forwarded
: 0
Client Packets Dropped
: 0
Client Packets Proxied (RADIUS)
: 2
Client Packets Proxied (Lease-Split) : 0
Server Packets Snooped
: 0
Server Packets Forwarded
: 0
Server Packets Dropped
: 0
DHCP RELEASEs Spoofed
: 0
DHCP FORCERENEWs Spoofed
: 0
=====================================================
A:BSA#

Connectivity of Host-1could be checked with the show service id 100 subscriber-hosts


command. Different options can be used to filter output of the command.
A:BSA# show service id 100 subscriber-hosts detail
===============================================================================
Subscriber Host table
===============================================================================
Sap
IP Address
MAC Address
PPPoE-SID Origin
Subscriber
------------------------------------------------------------------------------1/1/4:100
10.0.1.1
ca:00:0c:54:00:08 N/A
DHCP
sub-id-1
------------------------------------------------------------------------------Sub Profile
: sub-profile-1
SLA Profile
: sla-profile-1
App Profile
: N/A
------------------------------------------------------------------------------Number of subscriber hosts : 1

The DHCP lease state can be checked with the show service id 100 dhcp lease-state command.
Different options can be used to filter output of a command.

Page 386

Advanced Configuration Guide

Bridged CO

A:BSA# show service id 100 dhcp lease-state detail


===============================================================================
DHCP lease states for service 100
===============================================================================
Service ID
: 100
IP Address
: 10.0.1.1
Client HW Address
: ca:00:0c:54:00:08
SAP
: 1/1/4:100
Remaining Lifetime
: 01h33m41s
Persistence Key
: N/A
Sub-Ident
: "sub-id-1"
Sub-Profile-String
: "sub-profile-1"
SLA-Profile-String
: "sla-profile-1"
--snip-Sub-Ident origin
: Radius
Strings origin
: Radius
Lease Info origin
: Radius
--snip-Radius User-Name
: "ca:00:0c:54:00:08"
------------------------------------------------------------------------------Number of lease states : 1
===============================================================================
A:BSA#

Advanced Configuration Guide

Page 387

Configuration

Host-2 Setup Debug


Host-1 setup process is displayed in Figure 74.

Interface DHCP
DHCP
Loopback

SAP

Host 2

SDP

Interface

VPLS
BSA

DHCP Client

DHCP Snoop
DHCP Proxy
L2 DHCP Relay
DHCP-DISCOVER

RADIUS

IES
BSR

DHCP Snoop

DHCP Relay

Local DHCP
Server

RADIUS

DHCP
Snoop
RADIUS-ACCESS-REQUEST
RADIUS-ACCESS-ACCEPT
DHCP-DISCOVER

DHCP-DISCOVER

DHCP-OFFER

DHCP-OFFER

DHCP-OFFER

DHCP-REQUEST

DHCP-REQUEST

DHCP-REQUEST

DHCP-ACK

DHCP-ACK

DHCP-ACK

DHCP
Snoop
OSSG444

Figure 74: Host-2 Setup Process

Host-2 sends DHCP discover message in VLAN 200 to BSA. Host-2 is authenticated through
RADIUS and gets subscriber-id, sla/sub-profiles. DHCP Discover message is flooded in VPLS
service and reaches IP interface on BSA, where DHCP relay is configured. Session setup process
could be represented using debug commands:
A:BSA# debug service id 200 dhcp mode egr-ingr-and-dropped
A:BSA# debug service id 200 dhcp detail-level medium
A:BSA#
*A:BSA#
18 2009/12/15 13:00:36.28 UTC MINOR: DEBUG #2001 Base SVCMGR
"SVCMGR: RX DHCP Packet
VPLS 200, SAP 1/1/4:200
BootRequest to UDP port 67
ciaddr: 0.0.0.0
yiaddr: 0.0.0.0
siaddr: 0.0.0.0
giaddr: 0.0.0.0
chaddr: ca:01:08:10:00:08
xid: 0xfc8
DHCP options:
[53] Message type: Discover

Page 388

Advanced Configuration Guide

Bridged CO

--snip-19 2009/12/15 13:00:36.28 UTC MINOR: DEBUG #2001 management RADIUS


"RADIUS: Access-Request
user ca:01:08:10:00:08 policy auth-policy-1"
20 2009/12/15 13:00:36.28 UTC MINOR: DEBUG #2001 management RADIUS
"RADIUS: Transmit
Access-Request(1) 192.0.2.5:1812 id 80 len 85
USER NAME [1] 17 ca:01:08:10:00:08
PASSWORD [2] 16 .czdppt/0qAsqKqStbvnV.
NAS IP ADDRESS [4] 4 192.0.2.1
NAS PORT TYPE [61] 4 Ethernet(15)
NAS PORT ID [87] 9 1/1/4:200
NAS IDENTIFIER [32] 3 BSA
"
21 2009/12/15 13:00:36.34 UTC MINOR: DEBUG #2001 management RADIUS
"RADIUS: Receive
Access-Accept(2) id 80 len 78 from 138.203.18.79:1812
VSA [26] 10 Alcatel(6527)
SUBSC ID STR [11] 8 sub-id-1
VSA [26] 15 Alcatel(6527)
SUBSC PROF STR [12] 13 sub-profile-1
VSA [26] 15 Alcatel(6527)
SLA PROF STR [13] 13 sla-profile-2
"
22 2009/12/15 13:00:36.34 UTC MINOR: DEBUG #2001 Base SVCMGR
"SVCMGR: TX DHCP Packet
flooding in VPLS 200
BootRequest to UDP port 67
ciaddr: 0.0.0.0
yiaddr: 0.0.0.0
siaddr: 0.0.0.0
giaddr: 0.0.0.0
chaddr: ca:01:08:10:00:08
xid: 0xfc8
DHCP options:
[53] Message type: Discover
--snip--"
23 2009/12/15 13:00:36.35 UTC MINOR: DEBUG #2001 Base SVCMGR
"SVCMGR: RX DHCP Packet
VPLS 200, spoke-sdp 12:200
BootReply to UDP port 68
ciaddr: 0.0.0.0
yiaddr: 10.0.2.1
siaddr: 192.0.2.4
giaddr: 0.0.0.0
chaddr: ca:01:08:10:00:08
xid: 0xfc8
DHCP options:
[53] Message type: Offer
--snip--"
24 2009/12/15 13:00:36.34 UTC MINOR: DEBUG #2001 Base SVCMGR
"SVCMGR: TX DHCP Packet
VPLS 200, SAP 1/1/4:200
BootReply to UDP port 68
ciaddr: 0.0.0.0

Advanced Configuration Guide

yiaddr: 10.0.2.1

Page 389

Configuration

siaddr: 192.0.2.4
giaddr: 0.0.0.0
chaddr: ca:01:08:10:00:08
xid: 0xfc8
DHCP options:
[53] Message type: Offer
--snip--"
25 2009/12/15 13:00:36.46 UTC MINOR: DEBUG #2001 Base SVCMGR
"SVCMGR: RX DHCP Packet
VPLS 200, SAP 1/1/4:200
BootRequest to UDP port 67
ciaddr: 0.0.0.0
yiaddr: 0.0.0.0
siaddr: 0.0.0.0
giaddr: 0.0.0.0
chaddr: ca:01:08:10:00:08
xid: 0xfc8
DHCP options:
[53] Message type: Request
--snip--"
26 2009/12/15 13:00:36.46 UTC MINOR: DEBUG #2001 Base SVCMGR
"SVCMGR: TX DHCP Packet
flooding in VPLS 200
BootRequest to UDP port 67
ciaddr: 0.0.0.0
yiaddr: 0.0.0.0
siaddr: 0.0.0.0
giaddr: 0.0.0.0
chaddr: ca:01:08:10:00:08
xid: 0xfc8
DHCP options:
[53] Message type: Request
--snip--"
27 2009/12/15 13:00:36.47 UTC MINOR: DEBUG #2001 Base SVCMGR
"SVCMGR: RX DHCP Packet
VPLS 200, spoke-sdp 12:200
BootReply to UDP port 68
ciaddr: 0.0.0.0
yiaddr: 10.0.2.1
siaddr: 192.0.2.4
giaddr: 0.0.0.0
chaddr: ca:01:08:10:00:08
xid: 0xfc8
DHCP options:
[53] Message type: Ack
--snip--"
28 2009/12/15 13:00:36.46 UTC MINOR: DEBUG #2001 Base SVCMGR
"SVCMGR: TX DHCP Packet
VPLS 200, SAP 1/1/4:200
BootReply to UDP port 68
ciaddr: 0.0.0.0
yiaddr: 10.0.2.1
siaddr: 192.0.2.4
giaddr: 0.0.0.0
chaddr: ca:01:08:10:00:08
xid: 0xfc8
DHCP options:
[53] Message type: Ack
--snip--"

Page 390

Advanced Configuration Guide

Bridged CO

DHCP relay is enabled in service IES-200 on BSR.


A:BSR# debug router ip dhcp mode egr-ingr-and-dropped
A:BSR#
*A:BSR#
17 2009/12/15 13:00:36.34 UTC MINOR: DEBUG #2001 Base PIP
"PIP: DHCP
instance 1 (Base), interface index 6 (int-host-2),
received DHCP Boot Request on Interface int-host-2 (1/1/2) Port 67
H/W Type: Ethernet(10Mb) H/W Address Length: 6
ciaddr: 0.0.0.0
yiaddr: 0.0.0.0
siaddr: 0.0.0.0
giaddr: 0.0.0.0
chaddr: ca:01:08:10:00:08
xid: 0xfc8
DHCP options:
[53] Message type: Discover
--snip--"
18 2009/12/15 13:00:36.34 UTC MINOR: DEBUG #2001 Base PIP
"PIP: DHCP
instance 1 (Base),
transmitted DHCP Boot Request to 192.0.2.4 Port 67
H/W Type: Ethernet(10Mb) H/W Address Length: 6
ciaddr: 0.0.0.0
yiaddr: 0.0.0.0
siaddr: 0.0.0.0
giaddr: 10.0.2.254
chaddr: ca:01:08:10:00:08
xid: 0xfc8
DHCP options:
[53] Message type: Discover
--snip--"
19 2009/12/15 13:00:36.35 UTC MINOR: DEBUG #2001 Base PIP
"PIP: DHCP
instance 1 (Base),
received DHCP Boot Reply on 192.0.2.4 Port 67
H/W Type: Ethernet(10Mb) H/W Address Length: 6
ciaddr: 0.0.0.0
yiaddr: 10.0.2.1
siaddr: 192.0.2.4
giaddr: 10.0.2.254
chaddr: ca:01:08:10:00:08
xid: 0xfc8
DHCP options:
[53] Message type: Offer
--snip--"
20 2009/12/15 13:00:36.35 UTC MINOR: DEBUG #2001 Base PIP
"PIP: DHCP
instance 1 (Base), interface index 6 (int-host-2),
transmitted DHCP Boot Reply to Interface int-host-2 (spoke-21:200) Port 68
H/W Type: Ethernet(10Mb) H/W Address Length: 6
ciaddr: 0.0.0.0
yiaddr: 10.0.2.1
siaddr: 192.0.2.4
giaddr: 0.0.0.0
chaddr: ca:01:08:10:00:08
xid: 0xfc8
DHCP options:
[53] Message type: Offer

Advanced Configuration Guide

Page 391

Configuration

--snip--"
21 2009/12/15 13:00:36.47 UTC MINOR: DEBUG #2001 Base PIP
"PIP: DHCP
instance 1 (Base), interface index 6 (int-host-2),
received DHCP Boot Request on Interface int-host-2 (1/1/2) Port 67
H/W Type: Ethernet(10Mb) H/W Address Length: 6
ciaddr: 0.0.0.0
yiaddr: 0.0.0.0
siaddr: 0.0.0.0
giaddr: 0.0.0.0
chaddr: ca:01:08:10:00:08
xid: 0xfc8
DHCP options:
[53] Message type: Request
--snip--"
22 2009/12/15 13:00:36.47 UTC MINOR: DEBUG #2001 Base PIP
"PIP: DHCP
instance 1 (Base),
transmitted DHCP Boot Request to 192.0.2.4 Port 67
H/W Type: Ethernet(10Mb) H/W Address Length: 6
ciaddr: 0.0.0.0
yiaddr: 0.0.0.0
siaddr: 0.0.0.0
giaddr: 10.0.2.254
chaddr: ca:01:08:10:00:08
xid: 0xfc8
DHCP options:
[53] Message type: Request
--snip--"
23 2009/12/15 13:00:36.47 UTC MINOR: DEBUG #2001 Base PIP
"PIP: DHCP
instance 1 (Base),
received DHCP Boot Reply on 192.0.2.4 Port 67
H/W Type: Ethernet(10Mb) H/W Address Length: 6
ciaddr: 0.0.0.0
yiaddr: 10.0.2.1
siaddr: 192.0.2.4
giaddr: 10.0.2.254
chaddr: ca:01:08:10:00:08
xid: 0xfc8
DHCP options:
[53] Message type: Ack
--snip--"
24 2009/12/15 13:00:36.47 UTC MINOR: DEBUG #2001 Base PIP
"PIP: DHCP
instance 1 (Base), interface index 6 (int-host-2),
transmitted DHCP Boot Reply to Interface int-host-2 (spoke-21:200) Port 68
H/W Type: Ethernet(10Mb) H/W Address Length: 6
ciaddr: 0.0.0.0
yiaddr: 10.0.2.1
siaddr: 192.0.2.4
giaddr: 0.0.0.0
chaddr: ca:01:08:10:00:08
xid: 0xfc8
DHCP options:
[53] Message type: Ack
--snip--

Page 392

Advanced Configuration Guide

Bridged CO

The number of snooped/forwarded/dropped/proxied DHCP packets could be checked using the


show service id 200 dhcp statistics command.
A:BSA# show service id 200 dhcp statistics
=====================================================
DHCP Statistics, service 200
=====================================================
Client Packets Snooped
: 2
Client Packets Forwarded
: 2
Client Packets Dropped
: 0
Client Packets Proxied (RADIUS)
: 0
Client Packets Proxied (Lease-Split) : 0
Server Packets Snooped
: 2
Server Packets Forwarded
: 2
Server Packets Dropped
: 0
DHCP RELEASEs Spoofed
: 0
DHCP FORCERENEWs Spoofed
: 0
=====================================================
A:BSA#

The connectivity of Host-2 can be verified with the show service id 200 subscriber-hosts
command. Different options can be used to filter output of the command.
A:BSA# show service id 200 subscriber-hosts detail
===============================================================================
Subscriber Host table
===============================================================================
Sap
IP Address
MAC Address
PPPoE-SID Origin
Subscriber
------------------------------------------------------------------------------1/1/4:200
10.0.2.1
ca:01:08:10:00:08 N/A
DHCP
sub-id-1
------------------------------------------------------------------------------Sub Profile
: sub-profile-1
SLA Profile
: sla-profile-2
App Profile
: N/A
------------------------------------------------------------------------------Number of subscriber hosts : 1
===============================================================================
A:BSA#

Advanced Configuration Guide

Page 393

Configuration

DHCP lease state can be verified with the show service id 200 dhcp lease-state command.
Different options can be used to filter output of the command.
A:BSA# show service id 200 dhcp lease-state detail
===============================================================================
DHCP lease states for service 200
===============================================================================
Service ID
: 200
IP Address
: 10.0.2.1
Client HW Address
: ca:01:08:10:00:08
SAP
: 1/1/4:200
Remaining Lifetime
: 09d23h44m
Persistence Key
: N/A
Sub-Ident
: "sub-id-1"
Sub-Profile-String
: "sub-profile-1"
SLA-Profile-String
: "sla-profile-2"
--snip-Sub-Ident origin
: Radius
Strings origin
: Radius
Lease Info origin
: DHCP
--snip-Radius User-Name
: "ca:01:08:10:00:08"
------------------------------------------------------------------------------Number of lease states : 1
===============================================================================
A:BSA#

Page 394

Advanced Configuration Guide

Bridged CO

Host-3 Setup Debug


The Host-3 setup process is presented in Figure 75.
Interface DHCP
DHCP
Loopback

SAP

Host 3

DHCP Client

DHCP Snoop
DHCP Proxy
L2 DHCP Relay

SDP

Interface

VPLS

IES

BSA

BSR

DHCP Snoop

DHCP Relay

DHCP
Snoop
DHCP-DISCOVER

DHCP-DISCOVER

RADIUS

Local DHCP
Server

DHCP-DISCOVER

DHCP-OFFER

DHCP-OFFER

DHCP-OFFER

DHCP-REQUEST

DHCP-REQUEST

DHCP-REQUEST

DHCP-ACK

DHCP-ACK

DHCP-ACK

RADIUS

DHCP
Snoop
OSSG445

Figure 75: Host-3 Setup Process

Host-3 sends DHCP a discover message in VLAN 300 to BSA. Host-3 receives all parameters
from the DHCP server using pre-configured Option 254. A DHCP discover message is flooded in
VPLS service and reaches IP interface on BSA where DHCP relay is configured. The session
setup process can be represented using debug commands.
A:BSA# debug service id 300 dhcp mode egr-ingr-and-dropped
A:BSA# debug service id 300 dhcp detail-level medium
*A:BSA#
33 2009/12/15 13:02:34.39 UTC MINOR: DEBUG #2001 Base SVCMGR
"SVCMGR: RX DHCP Packet
VPLS 300, SAP 1/1/4:300
BootRequest to UDP port 67
ciaddr: 0.0.0.0
yiaddr: 0.0.0.0
siaddr: 0.0.0.0
giaddr: 0.0.0.0
chaddr: ca:02:02:d0:00:08
xid: 0x2a6
DHCP options:
[53] Message type: Discover
--snip-"
34 2009/12/15 13:02:34.38 UTC MINOR: DEBUG #2001 Base SVCMGR
"SVCMGR: TX DHCP Packet
flooding in VPLS 300
BootRequest to UDP port 67

Advanced Configuration Guide

Page 395

Configuration

ciaddr: 0.0.0.0
yiaddr: 0.0.0.0
siaddr: 0.0.0.0
giaddr: 0.0.0.0
chaddr: ca:02:02:d0:00:08
xid: 0x2a6
DHCP options:
[53] Message type: Discover
--snip-"
35 2009/12/15 13:02:34.40 UTC MINOR: DEBUG #2001 Base SVCMGR
"SVCMGR: RX DHCP Packet
VPLS 300, spoke-sdp 12:300
BootReply to UDP port 68
ciaddr: 0.0.0.0
yiaddr: 10.0.3.1
siaddr: 192.0.2.4
giaddr: 0.0.0.0
chaddr: ca:02:02:d0:00:08
xid: 0x2a6
DHCP options:
[53] Message type: Offer
--snip-"
36 2009/12/15 13:02:34.40 UTC MINOR: DEBUG #2001 Base SVCMGR
"SVCMGR: TX DHCP Packet
VPLS 300, SAP 1/1/4:300
BootReply to UDP port 68
ciaddr: 0.0.0.0
yiaddr: 10.0.3.1
siaddr: 192.0.2.4
giaddr: 0.0.0.0
chaddr: ca:02:02:d0:00:08
xid: 0x2a6
DHCP options:
[53] Message type: Offer
--snip-"
37 2009/12/15 13:02:34.52 UTC MINOR: DEBUG #2001 Base SVCMGR
"SVCMGR: RX DHCP Packet
VPLS 300, SAP 1/1/4:300
BootRequest to UDP port 67
ciaddr: 0.0.0.0
yiaddr: 0.0.0.0
siaddr: 0.0.0.0
giaddr: 0.0.0.0
chaddr: ca:02:02:d0:00:08
xid: 0x2a6
DHCP options:
[53] Message type: Request
--snip-"
38 2009/12/15 13:02:34.52 UTC MINOR: DEBUG #2001 Base SVCMGR
"SVCMGR: TX DHCP Packet
flooding in VPLS 300
BootRequest to UDP port 67
ciaddr: 0.0.0.0
yiaddr: 0.0.0.0
siaddr: 0.0.0.0
giaddr: 0.0.0.0
chaddr: ca:02:02:d0:00:08
xid: 0x2a6
DHCP options:
[53] Message type: Request
--snip--

Page 396

Advanced Configuration Guide

Bridged CO

"
39 2009/12/15 13:02:34.53 UTC MINOR: DEBUG #2001 Base SVCMGR
"SVCMGR: RX DHCP Packet
VPLS 300, spoke-sdp 12:300
BootReply to UDP port 68
ciaddr: 0.0.0.0
yiaddr: 10.0.3.1
siaddr: 192.0.2.4
giaddr: 0.0.0.0
chaddr: ca:02:02:d0:00:08
xid: 0x2a6
DHCP options:
[53] Message type: Ack
--snip-"
40 2009/12/15 13:02:34.53 UTC MINOR: DEBUG #2001 Base SVCMGR
"SVCMGR: TX DHCP Packet
VPLS 300, SAP 1/1/4:300
BootReply to UDP port 68
ciaddr: 0.0.0.0
yiaddr: 10.0.3.1
siaddr: 192.0.2.4
giaddr: 0.0.0.0
chaddr: ca:02:02:d0:00:08
xid: 0x2a6
DHCP options:
[53] Message type: Ack
--snip--

DHCP relay is enabled in service IES-300 on the BSR.


A:BSR# debug router ip dhcp mode egr-ingr-and-dropped
*A:BSR#
29 2009/12/15 13:02:34.39 UTC MINOR: DEBUG #2001 Base PIP
"PIP: DHCP
instance 1 (Base), interface index 7 (int-VoD),
received DHCP Boot Request on Interface int-VoD (1/1/2) Port 67
H/W Type: Ethernet(10Mb) H/W Address Length: 6
ciaddr: 0.0.0.0
yiaddr: 0.0.0.0
siaddr: 0.0.0.0
giaddr: 0.0.0.0
chaddr: ca:02:02:d0:00:08
xid: 0x2a6
DHCP options:
[53] Message type: Discover
--snip-30 2009/12/15 13:02:34.39 UTC MINOR: DEBUG #2001 Base PIP
"PIP: DHCP
instance 1 (Base),
transmitted DHCP Boot Request to 192.0.2.4 Port 67
H/W Type: Ethernet(10Mb) H/W Address Length: 6
ciaddr: 0.0.0.0
yiaddr: 0.0.0.0
siaddr: 0.0.0.0
giaddr: 10.0.3.254
chaddr: ca:02:02:d0:00:08
xid: 0x2a6
DHCP options:
[53] Message type: Discover
--snip-"

Advanced Configuration Guide

Page 397

Configuration

31 2009/12/15 13:02:34.39 UTC MINOR: DEBUG #2001 Base PIP


"PIP: DHCP
instance 1 (Base),
received DHCP Boot Reply on 192.0.2.4 Port 67
H/W Type: Ethernet(10Mb) H/W Address Length: 6
ciaddr: 0.0.0.0
yiaddr: 10.0.3.1
siaddr: 192.0.2.4
giaddr: 10.0.3.254
chaddr: ca:02:02:d0:00:08
xid: 0x2a6
DHCP options:
[53] Message type: Offer
--snip-"
32 2009/12/15 13:02:34.39 UTC MINOR: DEBUG #2001 Base PIP
"PIP: DHCP
instance 1 (Base), interface index 7 (int-VoD),
transmitted DHCP Boot Reply to Interface int-VoD (spoke-21:300) Port 68
H/W Type: Ethernet(10Mb) H/W Address Length: 6
ciaddr: 0.0.0.0
yiaddr: 10.0.3.1
siaddr: 192.0.2.4
giaddr: 0.0.0.0
chaddr: ca:02:02:d0:00:08
xid: 0x2a6
DHCP options:
[53] Message type: Offer
--snip-"
33 2009/12/15 13:02:34.53 UTC MINOR: DEBUG #2001 Base PIP
"PIP: DHCP
instance 1 (Base), interface index 7 (int-VoD),
received DHCP Boot Request on Interface int-VoD (1/1/2) Port 67
H/W Type: Ethernet(10Mb) H/W Address Length: 6
ciaddr: 0.0.0.0
yiaddr: 0.0.0.0
siaddr: 0.0.0.0
giaddr: 0.0.0.0
chaddr: ca:02:02:d0:00:08
xid: 0x2a6
DHCP options:
[53] Message type: Request
--snip-"
34 2009/12/15 13:02:34.53 UTC MINOR: DEBUG #2001 Base PIP
"PIP: DHCP
instance 1 (Base),
transmitted DHCP Boot Request to 192.0.2.4 Port 67
H/W Type: Ethernet(10Mb) H/W Address Length: 6
ciaddr: 0.0.0.0
yiaddr: 0.0.0.0
siaddr: 0.0.0.0
giaddr: 10.0.3.254
chaddr: ca:02:02:d0:00:08
xid: 0x2a6
DHCP options:
[53] Message type: Request
--snip-"
35 2009/12/15 13:02:34.53 UTC MINOR: DEBUG #2001 Base PIP
"PIP: DHCP
instance 1 (Base),

Page 398

Advanced Configuration Guide

Bridged CO

received DHCP Boot Reply on 192.0.2.4 Port 67


H/W Type: Ethernet(10Mb) H/W Address Length: 6
ciaddr: 0.0.0.0
yiaddr: 10.0.3.1
siaddr: 192.0.2.4
giaddr: 10.0.3.254
chaddr: ca:02:02:d0:00:08
xid: 0x2a6
DHCP options:
[53] Message type: Ack
--snip-36 2009/12/15 13:02:34.53 UTC MINOR: DEBUG #2001 Base PIP
"PIP: DHCP
instance 1 (Base), interface index 7 (int-VoD),
transmitted DHCP Boot Reply to Interface int-VoD (spoke-21:300) Port 68
H/W Type: Ethernet(10Mb) H/W Address Length: 6
ciaddr: 0.0.0.0
yiaddr: 10.0.3.1
siaddr: 192.0.2.4
giaddr: 0.0.0.0
chaddr: ca:02:02:d0:00:08
xid: 0x2a6
DHCP options:
[53] Message type: Ack
--snip--"

The number of snooped/forwarded/dropped/proxied DHCP packets can be verified with the using
show service id 300 dhcp statistics command.
A:BSA# show service id 300 dhcp statistics
=====================================================
DHCP Statistics, service 300
=====================================================
Client Packets Snooped
: 2
Client Packets Forwarded
: 2
Client Packets Dropped
: 0
Client Packets Proxied (RADIUS)
: 0
Client Packets Proxied (Lease-Split) : 0
Server Packets Snooped
: 2
Server Packets Forwarded
: 2
Server Packets Dropped
: 0
DHCP RELEASEs Spoofed
: 0
DHCP FORCERENEWs Spoofed
: 0
=====================================================
A:BSA#

The connectivity of Host-3 can be verified with the show service id 300 subscriber-hosts
command. Different options can be used to filter output of a command.
A:BSA# show service id 300 subscriber-hosts detail
===============================================================================
Subscriber Host table
===============================================================================
Sap
IP Address
MAC Address
PPPoE-SID Origin
Subscriber
-------------------------------------------------------------------------------

Advanced Configuration Guide

Page 399

Configuration

1/1/4:300
10.0.3.1
ca:02:02:d0:00:08 N/A
DHCP
sub-id-1
------------------------------------------------------------------------------Sub Profile
: sub-profile-1
SLA Profile
: sla-profile-3
App Profile
: N/A
------------------------------------------------------------------------------Number of subscriber hosts : 1
===============================================================================
A:BSA#

The DHCP lease state could be checked with the show service id 300 dhcp lease-state command.
Different options can be used to filter output of a command.
A:BSA# show service id 300 dhcp lease-state detail
===============================================================================
DHCP lease states for service 300
===============================================================================
Service ID
: 300
IP Address
: 10.0.3.1
Client HW Address
: ca:02:02:d0:00:08
SAP
: 1/1/4:300
Remaining Lifetime
: 09d23h52m
Persistence Key
: N/A
Sub-Ident
: "sub-id-1"
Sub-Profile-String
: "sub-profile-1"
SLA-Profile-String
: "sla-profile-3"
--snip-Sub-Ident origin
: DHCP
Strings origin
: DHCP
Lease Info origin
: DHCP
--snip-Radius User-Name
: ""
------------------------------------------------------------------------------Number of lease states : 1
===============================================================================
A:BSA#

Page 400

Advanced Configuration Guide

Bridged CO

Advanced Topics
Limiting Number of Subscribers
This topic is discussed in DHCP hosts. Refer to IPv4 DHCP Hosts on page 979 for detailed
information.
vpls 100 customer 1 create
--snip-sap 1/1/4:100 split-horizon-group "RSHG-1" create
--snip-sub-sla-mgmt
--snip-multi-sub-sap 2

Limiting Number of Lease States


This topic is discussed in DHCP hosts. Refer to IPv4 DHCP Hosts on page 979 for detailed
information.
vpls 100 customer 1 create
--snip-sap 1/1/4:100 split-horizon-group "RSHG-1" create
dhcp
lease-populate 400

Limiting Number of Host Per SLA-Profile


This topic is discussed in DHCP hosts. Refer to IPv4 DHCP Hosts on page 979 for detailed
information.
subscriber-mgmt
sla-profile "sla-profile-1" create
host-limit 1 [remove-oldest]

Advanced Configuration Guide

Page 401

Configuration

Subscriber Host Connectivity Verification


This topic is discussed in DHCP hosts. Refer to IPv4 DHCP Hosts on page 979 for detailed
information.
vpls 100 customer 1 create
sap 1/1/4:100 split-horizon-group "RSHG-1" create
host-connectivity-verify source-ip 10.1.0.253 source-mac 1e:54:ff:00:00:00
interval 1 action remove

A:BSA# show service id 100 host-connectivity-verify statistics


===============================================================================
Host connectivity check statistics
===============================================================================
Svc
SapId/
DestIp
Timestamp
Time since Oper
Id
SdpId
Address
last-reply/conn-lost
Reply/Lost State
------------------------------------------------------------------------------100
1/1/4:100
10.0.1.1
12/15/2009 09:04:06
0d 00:00:11 Up
------------------------------------------------------------------------------1 host-connectivity states : 1 Up / 0 Down / 0 Retry pending
===============================================================================
A:BSA#

Lease Split
This topic is discussed in DHCP hosts. Refer to IPv4 DHCP Hosts on page 979 for detailed
information.
vpls 100 customer 1 create
--snip-sap 1/1/4:100 split-horizon-group "RSHG-1" create
dhcp
proxy-server
lease-time hrs 1

DHCP Option 82
This topic is discussed in DHCP hosts. Refer to IPv4 DHCP Hosts on page 979 for detailed
information.

Page 402

Advanced Configuration Guide

Bridged CO

Conclusion
This note provides configuration and troubleshooting commands for Bridged CO model.

Advanced Configuration Guide

Page 403

Conclusion

Page 404

Advanced Configuration Guide

Class Fair Hierarchical Policing for


SAPs

In This Chapter
This section provides information to configure Class Fair Hierarchical Policing for SAPs.
Topics in this section include:

Applicability on page 406

Summary on page 407

Overview on page 408

Configuration on page 419

Conclusion on page 448

Advanced Configuration Guide

Page 405

Applicability

Applicability
The information in this note is applicable to all of the Alcatel-Lucent 7x50 platforms and is
focused on the FP2 chipset, which is used in the IOM3-XP/IMMs and in the 7750 SRc-12/4. The
configuration was tested on release 9.0R1. There are no specific pre-requisites for this
configuration.

Page 406

Advanced Configuration Guide

Class Fair Hierarchical Policing for SAPs

Summary
The Quality of Service (QoS) features of the 7x50 platforms provide traffic control with both
shaping and policing.
Shaping is achieved using a queue; packets are placed on the queue and a scheduler removes
packets from the queue at a given rate. This provides an upper bound to the traffic rate sent,
thereby protecting down stream devices from bursts. However, shaping can introduce latency and
jitter as packets are delayed in the queue. Packets can be dropped when the queue is full or
statistically when weighted random early discard is applied. Configuration of shaping on the 7x50
is described in QoS Architecture and Basic Operation on page 1693.
Policing is another mechanism for controlling traffic rates but it does not introduce latency/jitter.
This is achieved using a token bucket mechanism which drops certain packets from the traffic. A
common disadvantage of policing implementations is that they are usually applicable to a single
level of traffic priority and have no way to fairly share capacity between multiple streams at the
same priority level. Alcatel-Lucents Class Fair Hierarchical Policing (CFHP) addresses these
problems by implementing a four level prioritized policing hierarchy which also provides
weighted fairness for traffic at a given priority.
Regardless of whether shaping or policing is being used, the preceding QoS classification and
subsequent packet marking functionality is similar for both and is covered in more detail in QoS
Architecture and Basic Operation on page 1693.
This note describes the configuration and operation of CFHP when applied to Service Access
Points (SAPs). It is also possible to use CFHP for subscribers in a Triple Play Service Delivery
Architecture (TPSDA) environment but it is beyond the scope of this note.

Advanced Configuration Guide

Page 407

Overview

Overview
Policers
CFHP can be used both for ingress and egress QoS. The basic element is a policer which can apply
both a committed information rate (CIR) and peak information rate (PIR) to a traffic flow
(determined by the ingress classification). Traffic is directed to a policer by assigning a forwarding
class (FC) to the policer.
To describe the operation of a policer we will use a token bucket model, this is shown in
Figure 76.
Conforming
Packet

Offered packets

Non-conforming
Packet

Tokens
If the bucket depth is below
this level when the next packet
arrives, that packet is conforming.

Non-conforming
Tokens

Maximum
Burst
Threshold

Current
burst level

Conforming Tokens

Policed Rate
OSSG513

Figure 76: Policer Token Bucket Model

The policer is modeled by a bucket being filling with tokens which represent the bytes in the
packets passing through the policer. The bucket drains at a given rate (the policed rate) and if the
token (byte) arrival rate exceeds the drain rate then the bucket will fill. The bucket has a maximum
depth, defined by a maximum burst threshold. If tokens for a packet arrive in the bucket when the
current burst level of tokens is below the maximum burst threshold then the packet is considered
to be conforming and all of its tokens are accepted into the bucket. If a packets tokens arrive when
the current burst level has exceeded the maximum burst threshold then none its tokens are
accepted into the bucket and the packet is considered to be non-conforming (in the representation,
these tokens over-flow into a waste bin).

Page 408

Advanced Configuration Guide

Class Fair Hierarchical Policing for SAPs

Table 11 shows an example of the two possibilities.


Table 11: Burst Levels
Maximum burst threshold = 2000 tokens (bytes)
Policed rate 2 Mbps = 250000 bytes/sec (250 tokens/ms)
Arrival
Time

Packet Size

Current Burst
Level

Conforming
Packet

New Burst
Level

T0

1024

1500

Yes

1500 + 1024 = 2524

T0 + 1ms

128

2524 - 250 = 2274

No

2274

When the first packet arrives the current burst level is below the maximum burst threshold so it is
conforming, however, when the second packet arrives the current burst level is above the
maximum burst threshold so it is non-conforming.
An important aspect of the implementation of hierarchical policing is the ability of a policer
bucket to have multiple burst thresholds. The tokens for each arriving packet are only compared
against a single threshold relating to the characteristics of packet. These burst thresholds allow
specific granular QoS control.

Advanced Configuration Guide

Page 409

Overview

Policer Buckets
A policer uses up to 3 buckets depending on its configuration. A PIR bucket to control the traffic
rate which is always used though its rate could be max, there can be an optional CIR bucket if a
CIR rate is defined for dynamically profiling (in-profile/out-of-profile) packets, finally there may
be a fair information rate (FIR) bucket used to maintain traffic fairness in a hierarchical policing
scenario when multiple child policers are configured at the same parent priority level.
The PIR bucket is drained at the PIR rate and has two burst thresholds, one for high burst priority
traffic (defined by the maximum burst size (MBS)) and a second for low burst priority traffic
(defined by the MBS minus high-prio-only), see Figure 77. The traffic burst priority is determined
at ingress by the configured priority of either high or low, and at the egress by the profile state of
the packets (in-profile=high, out-of-profile=low). Note that by default all FCs are low burst
priority. If a packet conforms at the PIR bucket (its tokens enter the bucket) then the packet is
forwarded, otherwise the packet is discarded. Discarding logically results in the packets tokens
not being placed into the CIR, FIR or parent policer buckets.

All Packets
Discarded

Tokens From
Offered Packets
Action at Bucket Depth

Thresholds

All Packets Discarded


High Burst Priority Packets Forwarded
Low Burst Priority Packets Discarded

High-Prio-Only
MBS

High and Low Burst Priority


Packets Forwarded
Low Priority
Packets Discarded

PIR Rate
OSSG515

Figure 77: Peak Information Rate (PIR) Bucket

The CIR bucket is drained at the CIR rate and has one configurable burst threshold (defined by the
committed burst size (CBS)). At the ingress, if the bucket level is below this threshold traffic is
determined to be in-profile so the only action of the CIR bucket is to set the state of dynamically
profiled packets to be either in-profile or out-of-profile. At the egress, re-profiling only affects
Dot1P and DEI (Layer 2) egress marking (if the frame is double tagged, only the outer VLAN tag
is remarked).
The CBS threshold is used when operating in color-blind mode, the profile of incoming packets is
undefined and dynamically set based on the current burst level in the CIR bucket compared to the
CBS threshold. It is also possible to operate (simultaneously) in color-aware mode, where the
classification of incoming packets is used to explicitly determine whether a packet is in-profile or
out-of-profile. For color-aware mode, the CIR bucket does not change the packet profile state.

Page 410

Advanced Configuration Guide

Class Fair Hierarchical Policing for SAPs

In order to ensure that the overall amount of in-profile traffic takes into account both the explicit
and dynamic in-profile packets, tokens from the explicit in-profile packets are allowed to fill the
bucket above the CBS threshold. By doing this, dynamically profiled packets are only marked as
in-profile after the token level representing dynamically in-profile and explicit in-profile packets
have fallen below the CBS threshold (as the bucket drains). Note that explicitly marked out-ofprofile packets remain out-of-profile, so the bottom of the bucket can be considered to be an
implicit burst threshold for these packets. This is shown in Figure 78.
Tokens From
Offered Packets
Thresholds

Action at Bucket Depth


Undefined Packets Marked Out-of-profile
Explicit In-profile Packets Remain In-profile
Explicit Out-of-profile Packets Remain Out-of-profile
Undefined Packets Marked In-profile
Explicit In-profile Packets Remain In-profile
Explicit Out-of-profile Packets Remain out-of-profile

CIR Rate

CBS

Threshold
For Explicit
Profile-out

Dynamic Out-of-profile
Packets Do Not Fill The Bucket
Explicit Out-of-profile
Packets Do Not Fill The Bucket
OSSG516

Figure 78: Committed Information Rate (CIR) Bucket

As the depths of the PIR and CIR buckets (MBS and CBS, respectively) are configured
independently it is possible to have, for example, the CBS to be larger than the MBS (which is not
possible for a queue). This could result in traffic being discarded because it is non-conforming at
the PIR bucket but would have been conforming at the CIR bucket. Conversely, if the CBS is
smaller than the MBS and the PIR=CIR traffic can be forwarded as out-of-profile, which would
not be the case with a queue.
The FIR bucket is controlled by the system and is only used in hierarchical policing scenarios to
determine a childs fair access to the available capacity at a parent priority level relative to other
children at the same level. This bucket is only used when there is more than one child policer
assigned to a given parent policer priority level. The drain rate of the FIR bucket is dynamically
set proportionally to the weight configured for the child. This is shown in Figure 79.

Advanced Configuration Guide

Page 411

Overview

Unfair Packets Do
Not Fill The Bucket

Tokens From
Offered Packets
Action at Bucket Depth

Thresholds

Packets Marked Unfair


FIR
Threshold

Packets Marked Fair

FIR Rate
(Proportional to Child Relative Weight)
OSSG517

Figure 79: Fair Information Rate (FIR) Bucket

Page 412

Advanced Configuration Guide

Class Fair Hierarchical Policing for SAPs

Hierarchical Policing
Policers can be used standalone or with a parent policer to provide hierarchical policing. Up to
four stages can be configured in the hierarchy: the child policer, tier 1 and 2 intermediate arbiters,
and a root arbiter (which is associated with the parent policer). The arbiters are logical entities that
distribute bandwidth at a particular tier to their children in a priority level order, see Figure 80.
This may result in the drain rates for the child policer buckets being modified, so each child
policer PIR and CIR bucket has an administrative rate value (what it is configured to) and an
operational rate value (the current operating rate) based on the bandwidth distribution by the
parent arbiters.
Each stage in the hierarchy connects to its parent at a priority level and a weight. There are eight
available priorities which are serviced in a strict order (8 to 1, highest to lowest, respectively). The
weight is used to define relative fairness when multiple children are configured in the same
priority level. Note that the child access to parent policer burst capacity is governed by the level at
which the child ultimately connects into the root arbiter, not by its connection level at any
intermediate arbiters.

Advanced Configuration Guide

Page 413

Overview

Child
Policers

FC

Priority Level 1
Threshold in Root
Parent Policer

Parent
Policer

Strict Priority

WFO

PL8
PL7

WFO

PL2
PL1

WFO
WFO
WFO

Strict Priority

PL8
PL4
PL1

WFO
WFO

FC

PL2
PL7
WFO
WFO
WFO

FC

Priority Level 4
Threshold in Root
Parent Policer

Root
Arbiter

PL4

Strict Priority

PL8
PL4
PL1

WFO
WFO

Strict Priority

PL8
PL4

WFO
WFO

FC

PL2
PL7
WFO
WFO
WFO

Strict Priority

PL4

PL8
PL1
PL1

WFO

FC
Priority Level 8
Threshold in Root
Parent Policer

PL2
PL7
WFO
WFO
WFO

WFO

FC

Tier 1
Arbiters

CIR

PL2
PL7
WFO
WFO
WFO

PIR

Tier 2
Arbiters

Weighted
Fair Output

FC

FC

OSSG518

Figure 80: Policer and Arbiter Hierarchy

The final configuration aspect to consider is the parent policer, specifically its multiple thresholds
and how they relate to the child policers. See Figure 81.
There are 8 priority levels at the parent policer, each having an associated discard-fair and discardunfair threshold.
The discard-fair threshold is the upper burst limit for all tokens (consequently, all packets) at the
given priority, all traffic at a given priority level is discarded when its tokens arrive with this
threshold being exceeded. The discard-fair thresholds enable prioritization at the parent policer by
having the burst capacity for each priority threshold be larger (or equal) to those of lower
priorities. For example, referring to Figure 81, the priority 6 (P6) discard-fair threshold is larger
than the priority 5 (P5) discard-fair threshold with the result that even if the priority 5 and below
traffic is overloading the parent policer, the priority 6 traffic has burst capacity available in order
to allow some of its packets to conform and get forwarded through the parent policer.

Page 414

Advanced Configuration Guide

Class Fair Hierarchical Policing for SAPs

Note that if a packet is discarded at the parent policer, the discard needs to be reflected in the
associated child policer, this is achieved by also logically removing the related tokens from the
child policer buckets.
Root arbiter allocates
bandwidth to children
in priority order

Child
Policers
CIR

FC

Priority:
Level 8

FC

Priority:
Level 6

PL8

P5 Discard
fair
Strict Priority

WFO

PL6

Priority:
Level 2

WFO

FC

FIR
Weight 2

PL5

Proportional
To Weight

WFO

FC

FIR
Weight 4

PL2

FIR
Weight 1

Priority:
Level 5

WFO

FC

P5 Discard
unfair
P4/P3 Discard
(un)fair
P2 Discard fair
P2 Discard
unfair
P1 Discard
(un)fair

Proportional
To Weight

FC

Priority
Discard
Thresholds

P7/P6
Discard
(un)fair

FIR
Weight 3
Proportional
To Weight

Parent
Policer

P8 Discard
(un)fair

PL1

FC

Root
Arbiter

WFO

PIR

FIR
Weight 1

Priority:
Level 1

FC

Policed
Rate

OSSG519

Figure 81: Parent Policer and Root Arbiter

Each priority also has a discard-unfair threshold which discards only unfair traffic of that priority,
remembering that fair and unfair are determined by the FIR bucket based on the relative weights
of the children.
By default, if there are no children configured at a given priority level then both its discard-fair
and discard-unfair thresholds are set to zero bytes above the previous prioritys discard-fair
threshold.

Advanced Configuration Guide

Page 415

Overview

If there is only a single child at a priority level, the discard-fair will be greater than the previous
prioritys discard-fair value (by an amount equal to the maximum of the min-thresh-separation and
the mbs-contribution, see below) but the discard-unfair will be the same as the previous prioritys
discard-fair threshold (there is no need for a fairness function when there is only a single child at
that priority).
If there is more than one child at a priority level, the discard-unfair threshold will be greater than
the previous prioritys discard-fair threshold by min-thresh-separation (see below) and the discardfair threshold will be adjusted upwards by an amount equal to mbs-contribution minus min-threshseparation.
The result can be summarized as follows:

With no children at a priority level, the discard fair and unfair thresholds match the values
of the previous priority.

If there are at least two children at a priority level, the discard-unfair burst capacity equals
min-thresh-separation.

The burst capacity for a given priority level with at least one child equals the mbscontribution, unless this is less than min-thresh-separation in which case the min-threshseparation is used.

The burst tolerance for each threshold is its own burst capacity plus the sum of the burst capacities
of all lower thresholds. Referring to Figure 81, the total burst capacity for priority 6 is the sum of
the burst capacities for priorities 1 to 6. Note that the burst for a given FC is normally controlled
by the burst allowed at the child PIR threshold, not by the parent policer.
As the burst capacity at the parent policer for a given priority level can change when adding or
removing children at lower priority levels, a parameter (fixed) is available per priority threshold
which causes the discard-fair and discard-unfair thresholds to be non-zero and so greater than the
previous prioritys thresholds, calculated as above, even when there are no children at that priority
level. An exception to this is when the mbs-contribution is set to zero with the fixed parameter
configured, in which case both the discard unfair and fair for that priority level are set to zero
bytes above the previous levels thresholds (which results in the corresponding traffic being
dropped).
A specific configuration and associated show output is included below to highlight the different
threshold options described above.
The QoS example shown in Figure 82 is used to describe the configuration of CFHP.

Page 416

Advanced Configuration Guide

Class Fair Hierarchical Policing for SAPs

Real
Time

Child Policer 5
Parent = Root Level 5

Parent Policer

fc = EF
PIR=10
Data
Gold

Root
Arbiter

CIR=10

Tokens From
Offered
Packets

Child Policer 4
Parent = Arbiter Level 2 - Weight 25

Arbiter

Child Policer 2

fc = L2
PIR=60
Best
Effort

CIR=20

Strict Priority

P3

Rate
60M
WFO

Parent = Arbiter Level 2 - Weight 50

WFO

FIR

P1

CIR=20

WFO

PIR=60

Strict Priority

Parent = Arbiter Level 2 - Weight 25

Priority
Discard
Thresholds
Priority 5:
Discard Fair

Child Policer 3

fc = AF

Data
Bronze

WFO

Tier 1

FIR

P2

Data
Silver

CIR=20

P5

fc = L1
PIR=60

Parent Policer

Priority 3:
Discard Fair
Priority 3:
Discard Unfair
Priority 1:
Discard Fair

FIR

Child Policer 1

Policed max-rate
100M

Parent = Root Level 1

fc = BE
PIR=100

CIR=0
OSSG520

Figure 82: Configuration Example

Five classes of services are accepted, each with a specific CIR and PIR. The data classes, bronze,
silver and gold (L2/AF/L1), have a relative weighting of 50/25/25 at priority Level 2 of an
intermediate arbiter which is constrained to 60Mbps. At the parent policer, the real time traffic
(EF) is defined at level 5, with the data classes at Level 3 and a best effort class (BE) at Level 1.
The overall traffic is constrained to 100Mbps at the parent policer. Only unicast traffic is policed
in this example.
This example focuses on ingress policing, however, the configuration of policers, arbiters and the
parent policer at the egress is almost identical to that at the ingress, the only difference being the
particular statistics that can be collected.
There is a difference between ingress and egress policing in terms of how the ingress traffic
accesses the switch fabric and the egress traffic access the port after it has been policed. In both
cases, unicast access is enabled through a set of policer-output-queues, which are shared-queues at
the ingress and queue-groups at the egress (at the egress, user defined queue-groups can be used).
It is also possible to use a single service queue to access the egress port. Ingress multipoint traffic
accesses the switch fabric using the Ingress Multicast Path Management (IMPM) queues.

Advanced Configuration Guide

Page 417

Overview

This is shown in Figure 83 on an IOM3-XP (other line cards have the same logic).

MDA

MDA
Traffic Flow

IOM3-XP

IOM3-XP
Ingress
Policing

Shared
Queues
IMPM
Queues

Switch
Fabric

Egress
Policing

QueueGroups
Single
Queue

MDA

MDA

OSSG521

Figure 83: Post Policing Queues

The differences between the ingress and egress policing configuration will be high-lighted in the
associated sections.

Page 418

Advanced Configuration Guide

Class Fair Hierarchical Policing for SAPs

Configuration
To achieve the QoS shown in Figure 82, configure a SAP-ingress QoS policy to define the child
policers and a policer-control-policy to define the intermediate arbiter and the root arbiter/parent
policer. As this example is for ingress, the unicast traffic will pass through a set of shared queues
called policer-output-queues, which could be modified if required.

Policers
Policers control the CIR and PIR rates for each of the traffic classes and are defined in a SAPingress QoS policy. The focus here are parameters related to policing.
The configuration of a child (or standalone) policer is similar to that of a queue.
config>qos>sap-ingress# policer policer-id [create]
description description-string
adaptation-rule [pir {max | min | closest}] [cir {max | min | closest}]
stat-mode {no-stats|minimal|offered-profile-no-cir|
offered-priority-no-cir|offered-profile-cir|offered-priority-cir|
offered-total-cir|offered-limited-profile-cir}
rate {max | kilobits-per-second} [cir {max | kilobits-per-second}]
percent-rate pir-percent [cir cir-percent]
mbs size [bytes | kilobytes]
cbs size [bytes | kilobytes]
high-prio-only [default | percent-of-mbs]
parent {root | arbiter-name} [level level] [weight weight-within-level]
packet-byte-offset {add bytes | subtract bytes}

Parameters:

description This configures a text string, up to 80 characters, which can be used to


describe the use of the policy.

adaptation-rule The hardware supports distinct values for the rates. This parameter tells
the system how the rate configured should be mapped onto the possible hardware values.
min results in the next higher hardware value being used, max results in the next lower
hardware value being used and closest results in the closest available hardware value
being used. As can be seen, it is possible to set the adaptation-rule independently for the
CIR and PIR.
Default: closest

stat-mode This defines the traffic statistics collected by the policer, summarized in
Table 12.

Advanced Configuration Guide

Page 419

Configuration

Table 12: Policer stat-mode


stat-mode

Ingress

Egress

no-stats

Neither policer nor parent arbiter


account are required.

Neither policer nor parent arbiter


accounting are required.

minimal (default)

Basic policer accounting (default).

Basic policer accounting (default).

offered-profileno-cir

All ingress packets are either inprofile or out-of-profile.

Accounting for egress offered profile is


required. No visibility for CIR profile
state output.

offered-priorityno-cir

Ingress packet burst priority


accounting is the primary
requirement.

N/A

offered-limitedprofile-cir

Ingress color-aware profiling is in use


but packets are not being classified as
in-profile.

N/A

offered-profilecir

Ingress color-aware profiling is in use


and packets are undefined or
classified as out-of-profile or inprofile.

offered-prioritycir

Ingress policer is used in color-blind


mode and ingress packet priority and
CIR state output accounting is
needed.

offered-total-cir

Ingress priority and ingress profile


accounting is not needed. CIR
profiling is in use.

Egress profile reclassification is


performed.

N/A

Offered profile visibility is not required


(such as, all offered packets have the
same profile) and CIR profiling is in use.

Counter resources needed


for this stat mode

Page 420

rate and cir The rate defines the PIR and the cir defines the CIR, both are in Kbps. The
parameters rate and percent-rate are mutually exclusive and will overwrite each other
when configured in the same policy.
Range: PIR=1 to 20,000,000 Kbps or max ; CIR=0 to 20,000,000 Kbps or max
Default: rate(PIR)=max ; cir=0

percent-rate and cir The percent-rate defines the PIR and the cir defines the CIR with
their values being a percentage of the maximum policer rate of 20Gbps. The parameters
rate and percent-rate are mutually exclusive and will overwrite each other when

Advanced Configuration Guide

Class Fair Hierarchical Policing for SAPs

configured in the same policy.


Range: pir-percent = [0.01..100.00]; cir-percent = [0.00..100.00]
Default: pir-percent = 100; cir-percent = 0.00

mbs and cbs The mbs defines the MBS for the PIR bucket and the cbs defines the CBS
for the CIR bucket, both can be configured in bytes or kilobytes.
Note that the PIR MBS applies to high burst priority packets (these are packets whose
classification match criteria is configured with priority high at the ingress and are inprofile packets at the egress).
Range: mbs=0 to 4194304 bytes; cbs=0 to 4194304 bytes
Note: mbs=0 prevents any traffic from being forwarded.
Default: mbs=10ms of traffic or 64KB if PIR=max; cbs=10ms of traffic or 64KB if
CIR=max

high-prio-only This defines a second burst threshold within the PIR bucket to give a
maximum burst size for low burst priority packets (these are packets whose classification
match criteria is configured with priority low at the ingress and are out-of-profile packets
at the egress). It is configured as a percentage of the MBS.
Default: 10%

parent This parameter is used when hierarchical policing is being performed and points
to the parent arbiter (which could be the root arbiter or an intermediate arbiter), giving the
level to which this policer connects to its parent arbiter and its relative weight compared to
other children at the same level. Note that for a child policer to be associated with a
parent, its stat-mode cannot be no-stats.
Range: level=1 to 8; weight=1 to 100
Default: level=1; weight=1

packet-byte-offset This changes the packet size used for accounting purposes, both in
terms of the CIR and PIR rates and what is reported in the statistics. The change can either
add or subtract a number of bytes. For example:
To have the policer work on Layer 2 frame size including inter-frame gap and
preamble, add 20 bytes.
To have the policer work on IP packet size instead of the default layer 2 frame size,
subtract the encapsulation overhead:
14 bytes L2 + 4bytes VLAN ID + 4 bytes FCS = 22 bytes
Range: add-bytes=0 to 31; sub-bytes=1 to 32
Default: add-bytes=0; sub-bytes=0

A FC must be assigned to the policer in order for the policer to be instantiated (allocating a
hardware policer).
By default, any unicast traffic assigned to the FC at the ingress will be processed by the policer,
non-unicast traffic would continue to use the multipoint queue. At the egress all traffic assigned to
the FC is processed by the policer (as there is no distinction between unicast and non-unicast
traffic at the egress).

Advanced Configuration Guide

Page 421

Configuration

If required, non-unicast traffic can be policed in IES/VPRN and VPLS services at the ingress
(note: all Epipe traffic is treated as unicast). Within an IES/VPRN service, multicast traffic can be
assigned to a specific ingress policer on a PIM enabled IP interface. When the service is VPLS,
broadcast, unknown unicast and multicast traffic can be individually assigned to ingress policers.
In each of these cases, the policers used could be separate from the unicast policer, resulting in the
instantiation of additional hardware policers, or a single policer could be used for multiple traffic
types (this differs from the queuing implementation where separate queue types are used for
unicast and non-unicast traffic).
config>qos>sap-ingress>fc#
broadcast-policer <policer-id>
unknown-policer <policer-id>
multicast-policer <policer-id>

As mentioned above, the ingress policed unicast traffic passes through a set of shared-queues
(policer-output-queues) to access the switch fabric with the multipoint traffic using the IMPM
queues.
When policers are required at the egress, a SAP-egress policy is used. The configuration of the
policers is almost identical to that used in the SAP-ingress policy, the only difference being the
available stat-modes (as shown above).
At the egress, the policed traffic can also be directed to a specific queue-group (instead of the
default policer-output-queues) and to a specific queue within that queue-group, as follows:
config>qos>sap-egress>fc# policer <policer-id> [group <queue-group-name> [queue
<queueid>]]

It is also possible to direct the egress policed traffic to a single service queue if specific egress
queuing is required, as follows:
config>qos>sap-egress>fc# policer <policer-id> queue <queue-id>

Multiple egress policers in a SAP-egress policy can use the same local queue and other forwarding
classes can directly use the same local queue that is being used by policers.

Page 422

Advanced Configuration Guide

Class Fair Hierarchical Policing for SAPs

Parent Policer and Arbiters


The parent policer and its associated root arbiter, together with the tier 1 and 2 arbiters, are
configured within a policer-control-policy.
config>qos# policer-control-policy policy-name [create]
description description-string
root
max-rate {kilobits-per-second | max}
priority-mbs-thresholds
min-thresh-separation size [bytes|kilobytes]
priority level
mbs-contribution size [bytes|kilobytes] [fixed]
tier 1
arbiter arbiter-name [create]
description escription-string
rate {kilobits-per-second|max}
parent root [level priority-level] [weight weight-within-level]
tier 2
arbiter arbiter-name [create]
description description-string
rate {kilobits-per-second | max}
parent {root|arbiter-name} [level priority-level] [weight weight-within-level]

Parameters:

description This configures a text string, up to 80 characters, which can be used to


describe the use of the policy.

root This section defines the configuration of the parent policer and the root arbiter.
max-rate This defines the policed rate of the parent policer, the rate at which the
bucket is drained. It is defined in Kbps with an option to use max, in which case the
maximum possible rate is used.
Range: 1 to 20,000,000Kbps or max
Default: max
priority-mbs-thresholds
This section defines the thresholds used for the 8 priorities available in the parent
policer.

min-thresh-separation This defines the minimum separation between any two


active thresholds in the parent policer in units of bytes or kilobytes.
It should be set to a value greater than the maximum packet size used for traffic
passing through the policer. This ensures that a single packet arriving in the parent
policer will not cause the depth of tokens to cross two burst thresholds, if this did
happen it would result in the prioritization failing as a given priority level could
be starved of burst capacity by a lower priority traffic.

Advanced Configuration Guide

Page 423

Configuration

This parameter is also used as the burst capacity for each priority levels unfair
packets.
Range: 0 to 4194304 bytes
Default: 1536 bytes

mbs-contribution This is normally used to define the amount of packet burst


capacity required at the parent policer for a particular priority level with at least
one child, keeping in mind that the total capacity is the sum of this plus that of all
lower thresholds. The actual burst capacity used depends also on the setting of
min-thresh-separation, as described earlier. This permits the tuning of the burst
capacity at the parent for any children at a given priority level. A conservative
setting would ensure that the burst at the parent policer for a given priority is the
sum of the bursts of all children at that priority. Less conservative settings could
use a lower value and assume some level of oversubscription.
The use of the fixed parameter causes both the fair and unfair discard thresholds
to be non-zero even when there are no children assigned to this priority level
(unless the mbs-contribution is set to zero).
Range: 0 to 4194304
Default: 8192 bytes
The relationship between these two parameters is shown in Figure 84.

with > 1 child


Maximum of mbs-contribution and 2xmin-threshold-separation
with 1 child
Maximum of mbs-contribution and min-threshold-separation
or zero
if no children without fixed parameter, or mbs-contribution=0
with fixed parameter

Parent Policer

Priority Discard
Thresholds

Discard Fair-n
Discard Unfair-n
Priority-(n-1)

min-threshold-separation
or zero
if <2 children without fixed parameter
or mbs-contribution =0

Policed
Rate
OSSG523

Figure 84: Parent Policer Thresholds

tier
This section defines the configuration of any intermediate tier 1 or 2 arbiters.

Page 424

Advanced Configuration Guide

Class Fair Hierarchical Policing for SAPs

arbiter
This specifies the name of the arbiter.

description This configures a text string, up to 80 characters, which can be


used to describe the use of the policy.

rate This defines the rate of the arbiter, it is the maximum rate at which the
arbiter will distribute burst capacity to its children. It is defined in Kbps with an
option to use max, in which case the maximum possible rate is used.
Range: 1 to 20,000,000Kbps or max
Default: max

parent This parameter is used when hierarchical policing is being performed


and points to the parent arbiter (which could be the root arbiter or a tier 1 arbiter),
giving the level to which this arbiter connects to its parent arbiter and its relative
weight compared to other children at the same level.
Range: level=1 to 8; weight=1 to 100
Default: level=1; weight=1

Advanced Configuration Guide

Page 425

Configuration

Access to Switch Fabric and Egress Port


After the traffic has been processed by the policers it must pass through a set of queues in order to
access the switch fabric at the ingress or the port at the egress.
For the ingress unicast traffic, there is a set of shared-queues (one queue per FC for each possible
switch fabric destination) called policer output queues. Note that only their queue characteristics
can be configured, the FC to queue mapping is fixed. Also, the PIR/CIR rates only affect the
packet scheduling, they do not alter the packet profile state. The details of shared-queues are
beyond the scope of this note.
config>qos# shared-queue "policer-output-queues"
description description-string
fc <fc-name> [create]
broadcast-queue <queue-id>
multicast-queue <queue-id>
queue <queue-id>
unknown-queue <queue-id>
queue queue-id [queue-type] [multipoint] [create]
cbs percent
mbs percent
high-prio-only percent
pool pool-name
rate percent [cir percent]

Multipoint traffic uses the IMPM queues to access the switch fabric. For the egress to the port,
either a queue-group or a single service queue is used. There is a default queue-group called
policer-output-queues or a user configured queue-group can also be used.
As mentioned above, when a policer is assigned to a specific queue-group (default or user defined)
it is optionally possible to configure explicitly the queue to be used. Within the queue-group it is
also possible to redirect a FC for policed traffic to a specific queue, using the FC parameter. The
preference of the FC to queue mapping is (in order, highest to lowest):
1. Explicitly configured in SAP-egress FC definition
2. Mapped using FC parameter within queue-group definition
3. Default is to use queue 1
config>qos>qgrps>egr# queue-group queue-group-name [create]
description description-string
queue queue-id [queue-type] [create]
adaptation-rule [pir adaptation-rule] [cir adaptation-rule]
burst-limit size [bytes|kilobytes]
cbs size-in-kbytes
high-prio-only percent
mbs size [bytes|kilobytes]
parent scheduler-name [weight weight] [level level] [cir-weight cir-weight]
[cir-level cir-level]
percent-rate pir-percent [cir cir-percent]

Page 426

Advanced Configuration Guide

Class Fair Hierarchical Policing for SAPs

pool pool-name
port-parent [weight weight] [level level] [cir-weight cir-weight]
[cir-level cir-level]
rate pir-rate [cir cir-rate]
xp-specific
wred-queue [policy slope-policy-name]
fc fc-name [create]
queue queue-id

The default policer-output-queues queue-group consists of two queues; queue 1 being best-effort
and queue 2 being expedite. The lowest four FCs (BE, L2, AF, L1) are assigned to queue 1 and the
highest four queues (H2, EF, H1, NC) are assigned to queue 2. It may be important to change the
queue 2 definition in the queue-group to have CIR=PIR when there are other best-effort queues
using a non-zero CIR on the same egress port. This ensures that the policed traffic using queue 2
will be scheduled before any other best-effort within CIR traffic. It also results in the queue CBS
being non-zero, allowing the queue 2 traffic access to reserved buffer space.
A:PE-1>config>qos# queue-group-templates egress queue-group "policer-output-queues"
A:PE-1>cfg>qos>qgrps>egr>qgrp# info detail
---------------------------------------------description "Default egress policer output queues."
queue 1 best-effort create
no parent
no port-parent
adaptation-rule pir closest cir closest
rate max cir 0
cbs default
mbs default
high-prio-only default
no pool
xp-specific
no wred-queue
exit
no burst-limit
exit
queue 2 expedite create
no parent
no port-parent
adaptation-rule pir closest cir closest
rate max cir 0
cbs default
mbs default
high-prio-only default
no pool
xp-specific
no wred-queue
exit
no burst-limit
exit
fc af create
queue 1
exit
fc be create
queue 1
exit

Advanced Configuration Guide

Page 427

Configuration

fc ef create
queue 2
exit
fc h1 create
queue 2
exit
fc h2 create
queue 2
exit
fc l1 create
queue 1
exit
fc l2 create
queue 1
exit
fc nc create
queue 2
exit

The remaining details of queue-groups are beyond the scope of this section.

Page 428

Advanced Configuration Guide

Class Fair Hierarchical Policing for SAPs

Applying the SAP Ingress and Policer Control Policy


The SAP ingress policy and policer control policy are both applied under the associated SAP.
After applying these, it is possible to override the configuration of specific policers and/or the
policer control policy. This is shown below. The parameter values are the same as detailed for the
policies, as above.
config>service><service>#
sap sap-id [create]
[ingress|egress]
qos policy-id
policer-control-policy policy-name
policer-override
policer policer-id [create]
cbs size [bytes|kilobytes]
mbs size [bytes|kilobytes]
packet-byte-offset {add add-bytes | subtract sub-bytes}
rate {rate | max} [cir {max | rate}
percent-rate <pir-percent> [cir <cir-percent>]
stat-mode stat-mode
policer-control-override [create]
max-rate {rate | max}
priority-mbs-thresholds
min-thresh-separation size [bytes | kilobytes]
priority level
mbs-contribution size [bytes | kilobytes]

The SAP ingress policy and policer control policy required for the configuration example in
Figure 82 is shown below.
#-------------------------------------------------echo "QoS Policy Configuration"
#-------------------------------------------------qos
policer-control-policy "cfhp-1" create
root
max-rate 100000
exit
tier 1
arbiter "a3" create
parent "root" level 3
rate 60000
exit
exit
exit
sap-ingress 10 create
queue 1 create
exit
queue 11 multipoint create
exit
policer 1 create
stat-mode offered-total-cir
parent "root"
rate 100000

Advanced Configuration Guide

Page 429

Configuration

high-prio-only 0
exit
policer 2 create
stat-mode offered-total-cir
parent "a3" level 2 weight 50
rate 60000 cir 20000
high-prio-only 0
exit
policer 3 create
stat-mode offered-total-cir
parent "a3" level 2 weight 25
rate 60000 cir 20000
high-prio-only 0
exit
policer 4 create
stat-mode offered-total-cir
parent "a3" level 2 weight 25
rate 60000 cir 20000
high-prio-only 0
exit
policer 5 create
stat-mode offered-total-cir
parent "root" level 5
rate 10000 cir 10000
high-prio-only 0
exit
fc "af" create
policer 3
exit
fc "be" create
policer 1
exit
fc "ef" create
policer 5
exit
fc "l1" create
policer 4
exit
fc "l2" create
policer 2
exit
dot1p 1 fc "be"
dot1p 2 fc "l2"
dot1p 3 fc "af"
dot1p 4 fc "l1"
dot1p 5 fc "ef"
exit

Traffic is classified based on dot1p values, each of which is assigned to an individual FC which in
turn is assigned to a policer. The policer rates are configured as required for the example with an
appropriate stat-mode. Default values are used for the policer burst thresholds. As all FCs are low
burst priority by default, the high-prio-only has been set to zero in order to allow the traffic to use
all of the MBS available at the PIR bucket.
Policers 2, 3 and 4 are parented to the arbiter a3 with the required weights and at a single level
(Level 2). In this example it does not matter which level of a3 is used to parent these policers,

Page 430

Advanced Configuration Guide

Class Fair Hierarchical Policing for SAPs

the important aspect is the level at which a3 is parented to the root. Consequently, these policers
use the Level 3 parent policer thresholds (not the level they are parented on aa3 not Level 2).
Arbiter a3 has a rate of 60Mbps so that its children cannot exceed this rate (except up to the
burst tolerances).
Policers 1 and 5 are directly parented to the root arbiter, together with tier 1 arbiter a3.
The total capacity for the 5 traffic streams is constrained to 100Mbps by the parent policer, again
with the default burst tolerances at the root arbiter.
The SAP-ingress and policer-control-policies are applied to a SAP within an Epipe.
#-------------------------------------------------echo "Service Configuration"
#-------------------------------------------------service
epipe 1 customer 1 create
sap 1/1/3:1 create
ingress
policer-control-policy "cfhp-1"
qos 10
exit
exit
sap 1/1/4:1 create
exit
no shutdown
exit
exit

Advanced Configuration Guide

Page 431

Configuration

The following configuration is used to highlight the relative thresholds in the parent policer when
a priority level has 0, 1 or 2 associated children, both with and without using the fixed parameter.
-------------------------------------------------echo "QoS Policy Configuration"
#-------------------------------------------------qos
policer-control-policy "cfhp-2" create
root
max-rate 100000
priority-mbs-thresholds
min-thresh-separation 256 bytes
priority 1
mbs-contribution 1 kilobytes
exit
priority 2
mbs-contribution 1 kilobytes
exit
priority 3
mbs-contribution 1 kilobytes
exit
priority 4
mbs-contribution 1 kilobytes fixed
exit
priority 5
mbs-contribution 1 kilobytes fixed
exit
priority 6
mbs-contribution 1 kilobytes fixed
exit
exit
exit
exit
sap-ingress 20 create
queue 1 create
exit
queue 11 multipoint create
exit
policer 1 create
parent "root" level 2
exit
policer 2 create
parent "root" level 3
exit
policer 3 create
parent "root" level 3
exit
policer 4 create
parent "root" level 5
exit
policer 5 create
parent "root" level 6
exit
policer 6 create
parent "root" level 6
exit
fc "af" create

Page 432

Advanced Configuration Guide

Class Fair Hierarchical Policing for SAPs

policer 3
exit
fc "be" create
policer 1
exit
fc "ef" create
policer 6
exit
fc "h2" create
policer 5
exit
fc "l1" create
policer 4
exit
fc "l2" create
policer 2
exit
exit
#-------------------------------------------------echo "Service Configuration"
#-------------------------------------------------service
epipe 2 customer 1 create
sap 1/1/3:2 create
ingress
policer-control-policy "cfhp-2"
qos 20
exit
exit
sap 1/1/4:2 create
exit
no shutdown
exit

A policer-control-policy can also be applied under a multi-service site (MSS) so that the
hierarchical policing applies to traffic on multiple SAPs, potentially from different services. The
MSS can only be assigned to a port, which could be a LAG, but it is not possible to assign an MSS
to a card. When MSS are used, policer overrides are not supported.
config>service><service>#
service
customer customer-id [create]
multi-service-site customer-site-name [create]
assignment port port-id
egress
policer-control-policy name
ingress
policer-control-policy name
service-type
sap sap-id
multi-service-site customer-site-name
ingress
qos policy-id
egress
qos policy-id

Advanced Configuration Guide

Page 433

Configuration

Show Output
After configuring the example as described in the previous section, steady state traffic was sent
through the Epipe to overload each of the policers and the show output below was collected. This
output focuses on the policer and arbiter details.
The following shows the policers on the SAP and their current state.
A:PE-1# show qos policer sap 1/1/3:1
===============================================================================
Policer Information (Summary), Slot 1
===============================================================================
------------------------------------------------------------------------------Name
FC-Maps
MBS
HP-Only A.PIR
A.CIR
Direction
CBS
Depth
O.PIR
O.CIR
O.FIR
------------------------------------------------------------------------------1->1/1/3:1->1
Ingress
be
124 KB
0 KB
100000
0
0 KB
82
30000
0
30000
1->1/1/3:1->2
Ingress
l2
76 KB
0 KB
60000
20000
25 KB
77846
30000
20000
30000
1->1/1/3:1->3
Ingress
af
76 KB
0 KB
60000
20000
25 KB
77824
15000
15000
15000
1->1/1/3:1->4
Ingress
l1
76 KB
0 KB
60000
20000
25 KB
77868
15000
15000
15000
1->1/1/3:1->5
Ingress
ef
12800 B
0 KB
10000
10000
12800 B
12834
10000
10000
10000
===============================================================================
A:PE-1#

The output above shows the configured values for the policers, e.g. PIR and CIR, together with
their operational (current) state, such as PIR, CIR and FIR. The depth of each of the PIR buckets is
also shown.
The detailed state of each policer can be seen by adding the parameter detail. The following is the
output for policer 3.
A:PE-1# show qos policer sap 1/1/3:1 ingress detail
...
===============================================================================
Policer Info (1->1/1/3:1->3), Slot 1
===============================================================================
Policer Name
: 1->1/1/3:1->3
Direction
: Ingress
Fwding Plane
: 1
FC-Map
: af
Depth PIR
: 77842 Bytes
Depth CIR
: 25618 Bytes
Depth FIR
: 77842 Bytes
MBS
: 76 KB
CBS
: 25 KB
Hi Prio Only
: 0 KB
Pkt Byte Offset
: 0

Page 434

Advanced Configuration Guide

Class Fair Hierarchical Policing for SAPs

Admin PIR
: 60000 Kbps
Admin CIR
: 20000 Kbps
Oper PIR
: 15000 Kbps
Oper CIR
: 15000 Kbps
Oper FIR
: 15000 Kbps
Stat Mode
: offered-total-cir
PIR Adaption
: closest
CIR Adaption
: closest
Parent Arbiter Name: a3
------------------------------------------------------------------------------Arbiter Member Information
------------------------------------------------------------------------------Offered Rate
: 45800 Kbps
Level
: 2
Weight
: 25
Parent PIR
: 15000 Kbps
Parent FIR
: 15000 Kbps
Consumed
: 15000 Kbps
------------------------------------------------------------------------------===============================================================================...
A:PE-1#

Notice that the above output shows the depth of the PIR, CIR and FIR buckets together with their
operational rates. This can be used to explain the operation of the policers in this example and is
discussed later in this section.
The stat-mode of offered-total-cir configured on policer 3 results in these statistics being collected.
A:PE-1# show service id 1 sap 1/1/3:1 stats
===============================================================================
...
------------------------------------------------------------------------------Sap per Policer stats
------------------------------------------------------------------------------Packets
Octets
Ingress Policer 1 (Stats mode: offered-total-cir)
Off. All
: 2690893
172217152
Dro. InProf
: 0
0
Dro. OutProf
: 967465
61917760
For. InProf
: 0
0
For. OutProf
: 1723428
110299392
Ingress Policer 2 (Stats mode: offered-total-cir)
Off. All
: 2690988
172223232
Dro. InProf
: 0
0
Dro. OutProf
: 909492
58207488
For. InProf
: 1178507
75424448
For. OutProf
: 602989
38591296
...

Advanced Configuration Guide

Page 435

Configuration

The following output is included for reference and shows the statistics which are collected for
each of the ingress and egress stat-modes.
PE-1# show service id 2 sap 1/1/1:2 stats
...
------------------------------------------------------------------------------Sap per Policer stats
------------------------------------------------------------------------------Packets
Octets
Ingress Policer 1 (Stats mode: no-stats)
Ingress Policer 2 (Stats mode: minimal)
Off. All
: 0
For. All
: 0
Dro. All
: 0

0
0
0

Ingress Policer 3 (Stats mode: offered-profile-no-cir)


Off. InProf
: 0
0
Off. OutProf
: 0
0
For. InProf
: 0
0
For. OutProf
: 0
0
Dro. InProf
: 0
0
Dro. OutProf
: 0
0
Ingress Policer 4 (Stats mode: offered-priority-no-cir)
Off. HiPrio
: 0
0
Off. LowPrio
: 0
0
For. HiPrio
: 0
0
For. LoPrio
: 0
0
Dro. HiPrio
: 0
0
Dro. LowPrio
: 0
0
Ingress Policer 5 (Stats mode: offered-profile-cir)
Off. InProf
: 0
0
Off. OutProf
: 0
0
Off. Uncolor
: 0
0
For. InProf
: 0
0
For. OutProf
: 0
0
Dro. InProf
: 0
0
Dro. OutProf
: 0
0
Ingress Policer 6 (Stats mode: offered-priority-cir)
Off. HiPrio
: 0
0
Off. LowPrio
: 0
0
For. InProf
: 0
0
For. OutProf
: 0
0
Dro. InProf
: 0
0
Dro. OutProf
: 0
0
Ingress Policer 7 (Stats mode: offered-total-cir)
Off. All
: 0
0
For. InProf
: 0
0
For. OutProf
: 0
0
Dro. InProf
: 0
0
Dro. OutProf
: 0
0
Ingress Policer 8 (Stats mode: offered-limited-profile-cir)

Page 436

Advanced Configuration Guide

Class Fair Hierarchical Policing for SAPs

Off.
Off.
For.
For.
Dro.
Dro.

OutProf
Uncolor
InProf
OutProf
InProf
OutProf

:
:
:
:
:
:

0
0
0
0
0
0

0
0
0
0
0
0

Egress Policer 1 (Stats mode: no-stats)


Egress Policer 2 (Stats mode: minimal)
Off. All
: 0
For. All
: 0
Dro. All
: 0

0
0
0

Egress Policer 3 (Stats mode: offered-profile-no-cir)


Off. InProf
: 0
0
Off. OutProf
: 0
0
For. InProf
: 0
0
For. OutProf
: 0
0
Dro. InProf
: 0
0
Dro. OutProf
: 0
0
Egress Policer 4 (Stats mode: offered-profile-cir)
Off. InProf
: 0
0
Off. OutProf
: 0
0
Off. Uncolor
: 0
0
For. InProf
: 0
0
For. OutProf
: 0
0
Dro. InProf
: 0
0
Dro. OutProf
: 0
0
Egress Policer 5 (Stats mode: offered-total-cir)
Off. All
: 0
0
For. InProf
: 0
0
For. OutProf
: 0
0
Dro. InProf
: 0
0
Dro. OutProf
: 0
0
===============================================================================

Advanced Configuration Guide

Page 437

Configuration

It is possible to show the policer-control-policy details and the SAPs with which it is associated, as
shown here.
A:PE-1# show qos policer-control-policy cfhp-1
===============================================================================
QoS Policer Control Policy
===============================================================================
Policy-Name
: cfhp-1
Description
: (Not Specified)
Min Threshold Sep : Def
------------------------------------------------------------------------------Priority MBS Thresholds
------------------------------------------------------------------------------Priority
MBS Contribution
------------------------------------------------------------------------------1
none
2
none
3
none
4
none
5
none
6
none
7
none
8
none
------------------------------------------------------------------------------Tier/Arbiter
Lvl/Wt
Rate
Parent
------------------------------------------------------------------------------root
N/A
100000
None
1 a3
3/1
60000
root
===============================================================================
A:PE-1# show qos policer-control-policy "cfhp-1" association
===============================================================================
QoS Policer Control Policy
===============================================================================
Policy-Name
: cfhp-1
Description
: (Not Specified)
------------------------------------------------------------------------------Associations
------------------------------------------------------------------------------Service-Id
: 1 (Epipe)
Customer-Id
: 1
- SAP : 1/1/3:1 (Ing)
===============================================================================
A:PE-1

Page 438

Advanced Configuration Guide

Class Fair Hierarchical Policing for SAPs

The following command shows the policer hierarchy, including the child policers and their
relationship to the intermediate arbiter (a3) and the root arbiter. It can be used to monitor the status
of the child policers in the hierarchy. The output shows the assigned, offered and consumed
capacity for each policer.
A:PE-1# show qos policer-hierarchy sap 1/1/3:1
===============================================================================
Policer Hierarchy - Sap 1/1/3:1
===============================================================================
Ingress Policer Control Policy : cfhp-1
Egress Policer Control Policy :
------------------------------------------------------------------------------root (Ing)
|
| slot(1)
|
|--(A) : a3 (Sap 1/1/3:1)
|
|
|
|--(P) : Policer 1->1/1/3:1->4
|
|
|
|
|
|
[Level 2 Weight 25]
|
|
|
Assigned PIR:15000
Offered:45800
|
|
|
Consumed:15000
|
|
|
|
|
|
Assigned FIR:15000
|
|
|
|--(P) : Policer 1->1/1/3:1->3
|
|
|
|
|
|
[Level 2 Weight 25]
|
|
|
Assigned PIR:15000
Offered:45800
|
|
|
Consumed:15000
|
|
|
|
|
|
Assigned FIR:15000
|
|
|
|--(P) : Policer 1->1/1/3:1->2
|
|
|
|
|
|
[Level 2 Weight 50]
|
|
|
Assigned PIR:30000
Offered:45800
|
|
|
Consumed:30000
|
|
|
|
|
|
Assigned FIR:30000
|
|--(P) : Policer 1->1/1/3:1->5
|
|
|
|
[Level 5 Weight 1]
|
|
Assigned PIR:10000
Offered:10000
|
|
Consumed:10000
|
|
|
|
Assigned FIR:10000
|
|--(P) : Policer 1->1/1/3:1->1
|
|
|
|
[Level 1 Weight 1]
|
|
Assigned PIR:30000
Offered:45800
|
|
Consumed:30000
|
|
|
|
Assigned FIR:30000

Advanced Configuration Guide

Page 439

Configuration

root (Egr)
|
No Active Members Found on slot 1
===============================================================================
A:PE-1#

The complete information about the policer hierarchy can be seen by adding the detail parameter,
as shown below, with alternative parameters to select more specific information.

root-detail Rates, depth and thresholds for the root arbiter.

thresholds CBS, MBS and high-prio-only thresholds with associated rates of child
policers.

priority-info Discard-fair and discard-unfair thresholds, with number of associated


children, for each of the root priority levels.

depth Parent policer and child PIR buckets depth, with PIR and FIR rate information.

arbiter Specific information of a given arbiter.

port For use with LAGs in different line cards or using adapt-qos link.

The output adds a good representation of the root arbiter thresholds, indicating the priority levels,
discard-unfair and discard-fair thresholds, and how many child policers are associated with each
level. It also includes the current depth of the child policer PIR buckets and the parent policer
bucket.
A:PE-1# show qos policer-hierarchy sap 1/1/3:1 detail
===============================================================================
Policer Hierarchy - Sap 1/1/3:1
===============================================================================
Ingress Policer Control Policy : cfhp-1
Egress Policer Control Policy :
------------------------------------------------------------------------------Legend :
(*) real-time dynamic value
(w) Wire rates
------------------------------------------------------------------------------root (Ing)
|
| slot(1)
|
MaxPIR:100000
|
ConsumedByChildren:100000
|
OperPIR:100000
OperFIR:100000
|
|
DepthPIR:8111 bytes
| Priority 8
|
Oper Thresh Unfair:17408
Oper Thresh Fair:25600
|
Association count:0
| Priority 7
|
Oper Thresh Unfair:17408
Oper Thresh Fair:25600
|
Association count:0
| Priority 6
|
Oper Thresh Unfair:17408
Oper Thresh Fair:25600

Page 440

Advanced Configuration Guide

Class Fair Hierarchical Policing for SAPs

|
Association count:0
| Priority 5
|
Oper Thresh Unfair:17408
Oper Thresh Fair:25600
|
Association count:1
| Priority 4
|
Oper Thresh Unfair:9728
Oper Thresh Fair:17408
|
Association count:0
| Priority 3
|
Oper Thresh Unfair:9728
Oper Thresh Fair:17408
|
Association count:3
| Priority 2
|
Oper Thresh Unfair:0
Oper Thresh Fair:8192
|
Association count:0
| Priority 1
|
Oper Thresh Unfair:0
Oper Thresh Fair:8192
|
Association count:1
|
|--(A) : a3 (Sap 1/1/3:1)
|
|
MaxPIR:60000
|
|
ConsumedByChildren:60000
|
|
OperPIR:60000
OperFIR:60000
|
|
|
|
[Level 3 Weight 1]
|
|
Assigned PIR:60000
Offered:60000
|
|
Consumed:60000
|
|
|
|
Assigned FIR:60000
|
|
|
|--(P) : Policer 1->1/1/3:1->4
|
|
|
MaxPIR:60000
MaxCIR:20000
|
|
|
CBS:25600
MBS:77824
|
|
|
HiPrio:0
|
|
|
Depth:77876
|
|
|
|
|
|
OperPIR:15000
OperCIR:15000
|
|
|
OperFIR:15000
|
|
|
PacketByteOffset:0
|
|
|
StatMode: offered-total-cir
|
|
|
|
|
|
[Level 2 Weight 25]
|
|
|
Assigned PIR:15000
Offered:45800
|
|
|
Consumed:15000
|
|
|
|
|
|
Assigned FIR:15000
|
|
|
|--(P) : Policer 1->1/1/3:1->3
|
|
|
MaxPIR:60000
MaxCIR:20000
|
|
|
CBS:25600
MBS:77824
|
|
|
HiPrio:0
|
|
|
Depth:77834
|
|
|
|
|
|
OperPIR:15000
OperCIR:15000
|
|
|
OperFIR:15000
|
|
|
PacketByteOffset:0
|
|
|
StatMode: offered-total-cir
|
|
|
|
|
|
[Level 2 Weight 25]
|
|
|
Assigned PIR:15000
Offered:45800
|
|
|
Consumed:15000

Advanced Configuration Guide

Page 441

Configuration

|
|
|
|
|
|
Assigned FIR:15000
|
|
|
|--(P) : Policer 1->1/1/3:1->2
|
|
|
MaxPIR:60000
MaxCIR:20000
|
|
|
CBS:25600
MBS:77824
|
|
|
HiPrio:0
|
|
|
Depth:77848
|
|
|
|
|
|
OperPIR:30000
OperCIR:20000
|
|
|
OperFIR:30000
|
|
|
PacketByteOffset:0
|
|
|
StatMode: offered-total-cir
|
|
|
|
|
|
[Level 2 Weight 50]
|
|
|
Assigned PIR:30000
Offered:45800
|
|
|
Consumed:30000
|
|
|
|
|
|
Assigned FIR:30000
|
|--(P) : Policer 1->1/1/3:1->5
|
|
MaxPIR:10000
MaxCIR:10000
|
|
CBS:12800
MBS:12800
|
|
HiPrio:0
|
|
Depth:12854
|
|
|
|
OperPIR:10000
OperCIR:10000
|
|
OperFIR:10000
|
|
PacketByteOffset:0
|
|
StatMode: offered-total-cir
|
|
|
|
[Level 5 Weight 1]
|
|
Assigned PIR:10000
Offered:10000
|
|
Consumed:10000
|
|
|
|
Assigned FIR:10000
|
|--(P) : Policer 1->1/1/3:1->1
|
|
MaxPIR:100000
MaxCIR:0
|
|
CBS:0
MBS:126976
|
|
HiPrio:0
|
|
Depth:135
|
|
|
|
OperPIR:30000
OperCIR:0
|
|
OperFIR:30000
|
|
PacketByteOffset:0
|
|
StatMode: offered-total-cir
|
|
|
|
[Level 1 Weight 1]
|
|
Assigned PIR:30000
Offered:45800
|
|
Consumed:30000
|
|
|
|
Assigned FIR:30000

root (Egr)
|
No Active Members Found on slot 1

Page 442

Advanced Configuration Guide

Class Fair Hierarchical Policing for SAPs

===============================================================================
A:PE-1#

The output above gives the depth of the parent policer, which can be used with the output below to
explain the operation of the policing in this example.
A:PE-1# show
Policer Info
Depth PIR
Depth FIR
Admin PIR
Oper PIR
Oper FIR
Offered Rate
Parent PIR
Consumed
Policer Info
Depth PIR
Depth FIR
Admin PIR
Oper PIR
Oper FIR
Offered Rate
Parent PIR
Consumed
Policer Info
Depth PIR
Depth FIR
Admin PIR
Oper PIR
Oper FIR
Offered Rate
Parent PIR
Consumed
Policer Info
Depth PIR
Depth FIR
Admin PIR
Oper PIR
Oper FIR
Offered Rate
Parent PIR
Consumed
Policer Info
Depth PIR
Depth FIR
Admin PIR
Oper PIR
Oper FIR
Offered Rate
Parent PIR
Consumed
A:PE-1#

qos policer sap 1/1/3:1 detail | match expression "Slot | Bytes | Kbps"
(1->1/1/3:1->1), Slot 1
: 153 Bytes
Depth CIR
: 0 Bytes
: 153 Bytes
: 100000 Kbps
Admin CIR
: 0 Kbps
: 30000 Kbps
Oper CIR
: 0 Kbps
: 30000 Kbps
: 45800 Kbps
: 30000 Kbps
Parent FIR
: 30000 Kbps
: 30000 Kbps
(1->1/1/3:1->2), Slot 1
: 77828 Bytes
Depth CIR
: 25624 Bytes
: 77828 Bytes
: 60000 Kbps
Admin CIR
: 20000 Kbps
: 30000 Kbps
Oper CIR
: 20000 Kbps
: 30000 Kbps
: 45800 Kbps
: 30000 Kbps
Parent FIR
: 30000 Kbps
: 30000 Kbps
(1->1/1/3:1->3), Slot 1
: 77858 Bytes
Depth CIR
: 25634 Bytes
: 77858 Bytes
: 60000 Kbps
Admin CIR
: 20000 Kbps
: 15000 Kbps
Oper CIR
: 15000 Kbps
: 15000 Kbps
: 45800 Kbps
: 15000 Kbps
Parent FIR
: 15000 Kbps
: 15000 Kbps
(1->1/1/3:1->4), Slot 1
: 77838 Bytes
Depth CIR
: 25614 Bytes
: 77838 Bytes
: 60000 Kbps
Admin CIR
: 20000 Kbps
: 15000 Kbps
Oper CIR
: 15000 Kbps
: 15000 Kbps
: 45800 Kbps
: 15000 Kbps
Parent FIR
: 15000 Kbps
: 15000 Kbps
(1->1/1/3:1->5), Slot 1
: 12814 Bytes
Depth CIR
: 12814 Bytes
: 12814 Bytes
: 10000 Kbps
Admin CIR
: 10000 Kbps
: 10000 Kbps
Oper CIR
: 10000 Kbps
: 10000 Kbps
: 10000 Kbps
: 10000 Kbps
Parent FIR
: 10000 Kbps
: 10000 Kbps

From the output above, it can be seen that the offered rate for policers 1-4 is 45800Kbps, in fact it
is the same for policer 5 but this is capped at the admin PIR rate, 10000Kbps.

Advanced Configuration Guide

Page 443

Configuration

The depth of the parent policer is only 8111 bytes, so this is not causing any discarding of priority
2-5 traffic at the parent policer as their discard thresholds are all above this value. Therefore the
drops in policers 2-5 are all occurring in the child policers.
Policer 5 is consuming all of its operational capacity (PIR, CIR and FIR), and it can be seen that
the level of the PIR bucket is 12814 bytes, which is slightly above its MBS of 12800 bytes. The
level of the PIR bucket will oscillate around the MBS value as tokens are added to exceed the
threshold (causing discards) then the draining reduces the level to just below the threshold
(allowing forwarding).
Policers 2-4 are functioning in the same way as policer 5, as can be seen from their PIR bucket
levels (levels are 77828 bytes with MBS of 77824), resulting in the PIR buckets constraining the
rates of the traffic through these policers. This is happening because the arbiter a3 is distributing
its 60000Kbps in the configured ratio to these policers, which changes the operational PIR to
30000Kbps for policer 2 and 15000Kbps for policers 3 and 4, all being below the offered traffic
rate. A similar effect can be seen with the CIR rates and bucket depths, as the operational CIR rate
of policer 2 has reached its administrative value with those of policer 3 and 4 being constrained by
the operational PIR. The CIR bucket depths are just above the CBS, again this will oscillate
causing traffic to both in-profile and out-of-profile. As this is steady state traffic, the operational
FIR rates for these policers have settled to match their operational PIR rates.
Policer 1 is also discarding traffic at the PIR bucket but it is also discarding traffic at the parent
policer. This can be seen by the fact that policer 1 PIR depth is nowhere near its MBS whereas the
parent policer level is just below the priority 1 discard-fair threshold. The level of the parent
policer bucket will oscillate around this threshold causing policer 1 traffic to be discarded, which
in turn is reflected back into the level of tokens in the policer 1 PIR bucket.
As this example is based on ingress unicast policing, the traffic exits the policers and then accesses
the switch fabric using a set of shared-queue (policer-output-queues). The parameters for these
queues can be seen using the following show command.
A:PE-1# show qos shared-queue "policer-output-queues" detail
===============================================================================
QoS Shared Queue Policy
===============================================================================
------------------------------------------------------------------------------Shared Queue Policy (policer-output-queues)
------------------------------------------------------------------------------Policy
: policer-output-queues
Description
: Default Policer Output Shared Queue Policy
------------------------------------------------------------------------------Queue CIR
PIR
CBS
MBS
HiPrio Multipoint Pool-Name
------------------------------------------------------------------------------1
0
100
1
50
10
FALSE
2
25
100
3
50
10
FALSE
3
25
100
10
50
10
FALSE
4
25
100
3
25
10
FALSE
5
100
100
10
50
10
FALSE
6
100
100
10
50
10
FALSE
7
10
100
3
25
10
FALSE

Page 444

Advanced Configuration Guide

Class Fair Hierarchical Policing for SAPs

8
9
10
11
12
13
14
15
16

10
0
25
25
25
100
100
10
10

100
100
100
100
100
100
100
100
100

3
1
3
10
3
10
10
3
3

25
50
50
50
25
50
50
25
25

10
10
10
10
10
10
10
10
10

FALSE
TRUE
TRUE
TRUE
TRUE
TRUE
TRUE
TRUE
TRUE

------------------------------------------------------------------------------FC
UCastQ
MCastQ
BCastQ UnknownQ
------------------------------------------------------------------------------be
1
9
9
9
l2
2
10
10
10
af
3
11
11
11
l1
4
12
12
12
h2
5
13
13
13
ef
6
14
14
14
h1
7
15
15
15
nc
8
16
16
16
------------------------------------------------------------------------------Associations
------------------------------------------------------------------------------Service : 1
SAP : 1/1/3:1
===============================================================================
A:PE-1#

For egress policing, policed traffic can access the exit port by a queue-group, the default being
called policer-output-queues. The following shows the parameters for these queues.
A:PE-1# show qos queue-group "policer-output-queues" detail
===============================================================================
QoS Queue-Group Ingress
===============================================================================
===============================================================================
QoS Queue-Group Egress
===============================================================================
------------------------------------------------------------------------------QoS Queue Group
------------------------------------------------------------------------------Group-Name
: policer-output-queues
Description
: Default egress policer output queues.
------------------------------------------------------------------------------Q CIR Admin PIR Admin CBS
HiPrio PIR Lvl/Wt
Parent
BurstLimit(B)
CIR Rule PIR Rule MBS
CIR Lvl/Wt
Wred-Queue
Slope
Named-Buffer Pool
------------------------------------------------------------------------------1 0
max
def
def
1/1
None
default
closest
closest
def
0/1
disabled
default
(not-assigned)
2 0
max
def
def
1/1
None
default
closest
closest
def
0/1
disabled
default

Advanced Configuration Guide

Page 445

Configuration

(not-assigned)
===============================================================================
Queue Group Ports (access)
===============================================================================
Port
Sched Pol
Acctg Pol Stats
Description
------------------------------------------------------------------------------1/1/3
0
No
1/1/4
0
No
------------------------------------------------------------------------------===============================================================================
Queue Group Ports (network)
===============================================================================
Port
Sched Pol
Acctg Pol Stats
Description
------------------------------------------------------------------------------No Matching Entries
===============================================================================
Queue Group Sap FC Maps
===============================================================================
Sap Policy
FC Name
Queue Id
------------------------------------------------------------------------------No Matching Entries
===============================================================================
A:PE-1#

The following output shows the relative thresholds in the parent policer when a priority level has
0, 1 or 2 associated children, both with and without using the fixed parameter.
A:PE-1# show qos policer-hierarchy sap 1/1/3:2 ingress priority-info
===============================================================================
Policer Hierarchy - Sap 1/1/3:2
===============================================================================
Ingress Policer Control Policy : cfhp-2
------------------------------------------------------------------------------root (Ing)
|
| slot(1)
| Priority 8
|
Oper Thresh Unfair:4352
Oper Thresh Fair:5120
|
Association count:0
| Priority 7
|
Oper Thresh Unfair:4352
Oper Thresh Fair:5120
|
Association count:0
| Priority 6
|
Oper Thresh Unfair:4352
Oper Thresh Fair:5120
|
Association count:2 fixed
| Priority 5
|
Oper Thresh Unfair:3328
Oper Thresh Fair:4096
|
Association count:1 fixed
| Priority 4
|
Oper Thresh Unfair:2304
Oper Thresh Fair:3072
|
Association count:0 fixed
| Priority 3

Page 446

Advanced Configuration Guide

Class Fair Hierarchical Policing for SAPs

|
|
|
|
|
|
|
|

Oper Thresh
Association
Priority 2
Oper Thresh
Association
Priority 1
Oper Thresh
Association

Unfair:1280
count:2

Oper Thresh Fair:2048

Unfair:0
count:1

Oper Thresh Fair:1024

Unfair:0
count:0

Oper Thresh Fair:0

===============================================================================
A:PE-1#

Where

Priority Level 1 has no children so both its fair and unfair thresholds are 0.

Priority Level 2 has one child so its unfair threshold is 0 and its fair threshold is at the
configured mbs-contribution [1024 bytes] (given that this is larger than the min-threshseparation).

Priority Level 3 has two children so its unfair threshold is equal to the min-threshseparation plus the fair threshold of priority 2 [256+1024=1280 bytes]. Its fair threshold is
effectively the mbs-contribution plus the fair threshold of priority 2 [1024+1024=2048
bytes] (given that the mbs-contribution is larger than 2x min-thresh-separation).

Priorities 4, 5 and 6 have the fixed parameter configured. Even though priority 4 has no
children, priority 5 has only one child and priority 6 has two children, all three priorities
have the same incremental values for their unfair and fair discard threshold. This result in
Priority 4s unfair threshold being equal to the min-thresh-separation plus the fair
threshold of priority 3 [256+2048=2304 bytes]. Its fair threshold is effectively the
mbs-contribution plus the fair threshold of priority 3 [1024+2048=3072 bytes] (given
that the mbs-contribution is larger than 2x min-thresh-separation).
Priority 5s unfair threshold being equal to the min-thresh-separation plus the fair
threshold of priority 4 [256+3072=3328 bytes]. Its fair threshold is effectively the
mbs-contribution plus the fair threshold of priority 4 [1024+3072=4096 bytes] (given
that the mbs-contribution is larger than 2x min-thresh-separation).
Priority 6s unfair threshold being equal to the min-thresh-separation plus the fair
threshold of priority 5 [256+4096=4352 bytes]. Its fair threshold is effectively the
mbs-contribution plus the fair threshold of priority 5 [1024+4096=5120 bytes] (given
that the mbs-contribution is larger than 2x min-thresh-separation).

Note that the above parameter values were chosen to exactly match available hardware values to
simplify the output.

Advanced Configuration Guide

Page 447

Conclusion

Conclusion
This note has described the configuration of Class Fair Hierarchical Policing for SAPs. This
hardware policing provides low latency ingress and egress prioritized traffic control with the
ability to provide fairness between child policers at the same parent policer priority level.

Page 448

Advanced Configuration Guide

Carrier Supporting Carrier IP VPNs

In This Chapter
This section provides information about carrier supporting carrier IP VPN configurations.
Topics in this section include:

Applicability on page 450

Overview on page 451

Configuration on page 453

Conclusion on page 474

Advanced Configuration Guide

Page 449

Applicability

Applicability
This example is applicable to the following platforms: 7950 XRS, 7750 SR-7/12, 7450 ESS-6/7/
12 and 7450 SR-c4/c12.
When a 7450 operating in mixed-mode, a 7750, or a 7950 is deployed as a CSC-PE (refer to
Figure 85) all its network interfaces and all its CSC VPRN interfaces must be configured on FP2
or higher hardware.
The configuration in this guide was tested with release 11.0R1.

Page 450

Advanced Configuration Guide

Carrier Supporting Carrier IP VPNs

Overview
Carrier Supporting Carrier (CSC) is a solution that allows one service provider (the Customer
Carrier) to use the IP VPN service of another service provider (the Super Carrier) for some or all
of its backbone transport. RFC 4364 defines a Carrier Supporting Carrier solution for BGP/MPLS
IP VPNs that uses MPLS at the interconnection points between the two service providers to
provide a scalable and secure solution.
A simplified CSC network topology is shown in Figure 85. A CSC deployment involves the
following types of devices:
CE Customer premises equipment dedicated to one particular business/enterprise.
PE Edge router managed and operated by the Customer Carrier that connects to CEs to provide
business VPN or Internet services.
CSC-CE Peering router managed and operated by the Customer Carrier that is connected to
CSC-PEs for purposes of using the associated CSC IP VPN services for backbone transport. The
CSC-CE may attach directly to CEs if it is also configured to be a PE for business VPN services.
CSC-PE A PE router managed and operated by the Super Carrier that supports one or more
CSC IP VPN services possibly in addition to other traditional PE services.

AS 64496
AS 64511

192.0.2.251
SVC

192.0.2.1
CSC
VPRN BASE

BASE

Super Backbone

192.0.2.252

192.0.2.2

CSC
BASE VPRN

BASE

SVC

CE-2

CE-1
CSC-CE-1

CSC-PE-1

CSC-PE-2

CSC-CE-2
al_0311

Figure 85: CSC Network Topology

In the CSC solution the CSC-CE and CSC-PE are directly connected by a link that supports
MPLS. The CSC-CE distributes an MPLS label for every /32 IPv4 prefix it and any downstream
PE uses as a BGP next-hop in routes associated with services offered by the Customer Carrier.
Note that BGP must be used as the label distribution protocol between CSC-CE and CSC-PE if
the latter device is a 7x50. Typically the Customer Carrier and Super Carrier operate as two
different Autonomous Systems (AS) and therefore BGP, more specifically EBGP, is the best label
distribution protocol even if other options are available. In release 11.0R1 the BGP session

Advanced Configuration Guide

Page 451

Overview

between CSC-CE and CSC-PE must be single-hop EBGP (not IBGP, not multi-hop EBGP, not
confed-EBGP) if either device is a 7x50.
In a 7x50 CSC-PE the interface to a CSC-CE is a special type of IP/MPLS interface that belongs
to a VPRN configured for CSC mode. This special type of interface is called a CSC VPRN
interface throughout the remainder of this example. The CSC VPRN interface has many of the
same characteristics as a network interface of the base router but its association with a VRF
ensures that the traffic and control plane routes of the Customer Carrier are kept separate from
other services.
When a 7x50 CSC-PE receives a labelled-IPv4 route (with label L1, next-hop N1) from a CSC-CE
BGP peer the following actions take place in the CSC-PE:
1. The BGP route is installed into the routing table of the CSC VPRN (assuming the BGP route
is the best route to the destination).
2. If the BGP route matches the VRF export policy it is advertised to core MP-BGP peers as a
VPN-IPv4 route. The advertised label value is changed to L2.
3. BGP programs the line cards with an MPLS forwarding entry that swaps L2 for L1 and sends
the MPLS packet over the CSC VPRN interface associated with next-hop N1.
When a 7x50 CSC-PE receives a VPN-IPv4 route (with label L2, next-hop N2) the following
actions take place in the CSC-PE:
1. If the VPN-IPv4 route matches the VRF import policy of a CSC VPRN it is installed into the
routing table of that CSC VPRN.
2. If the imported (BGP-VPN) route matches the BGP export policy associated with a CSC-CE
BGP peer it is advertised to that peer as a labelled-IPv4 route. The advertised label value is
changed to L3.
3. BGP programs the line cards with an MPLS forwarding entry that swaps L3 for L2 and sends
the packet inside the MPLS tunnel to next-hop N2.
Once a CSC-CE has learned a labelled-IPv4 route for a remote CSC-CE and vice versa the two
CSC-CEs can setup a BGP session between themselves and exchange VPN routes over this
session if they are both PEs with services. Typically this BGP session will be an IBGP session
because the local and remote CSC-CEs belong to the same Autonomous System (AS). The Layer
2 VPN and Layer 3 VPN routes exchanged by the CSC-CEs are resolved by the labelled-IPv4
routes they have for each others /32 IPv4 address.

Page 452

Advanced Configuration Guide

Carrier Supporting Carrier IP VPNs

Configuration
This section will walk through the steps to configure the CSC solution shown in Figure 85. Note
that the IPv4 addresses in Figure 85 are the system IP addresses of the routers.
Step 1.

Configure CSC-CE-1.

This example assumes that CSC-CE-1 is a PE router with Layer 2 and Layer 3 VPN services that
must extend across the CSC VPN service; assume that there are no further downstream PEs in AS
64496. The configuration of one such Layer 3 VPN service in CSC-CE-1 is shown below:
A:csc-ce-1>config>service>vprn# info
---------------------------------------------route-distinguisher 64496:1
auto-bind mpls
vrf-target target:64496:1
...
no shutdown
---------------------------------------------A:csc-ce-1>config>service>vprn#

For brevity the above configuration sample omits commands related to SAP IP interfaces, spokeSDP IP interfaces, PE-CE routing protocols, QoS, IP filters, etc.
The base routing instance of the CSC-CE should be configured with the appropriate router-ID and
autonomous-system number and the system interface should be given an IPv4 address (usually the
same as the router-id). The interface to CSC-PE-1 should then be created and configured. The base
router configuration of CSC-CE-1 is shown below:
*A:csc-ce-1>config>router# info
---------------------------------------------#-------------------------------------------------echo "IP Configuration"
#-------------------------------------------------interface "int-csc-ce-1-to-csc-pe-1"
address 192.168.0.1/30
port 1/1/1
no shutdown
exit
interface "system"
address 192.0.2.1/32
no shutdown
exit
autonomous-system 64496
router-id 192.0.2.1
---------------------------------------------*A:csc-ce-1>config>router#

Advanced Configuration Guide

Page 453

Configuration

BGP should be configured as the control plane protocol running on the interface to CSC-PE-1, as
shown below:
*A:csc-ce-1>config>router>bgp# info
---------------------------------------------group "csc-pe"
peer-as 64511
neighbor 192.168.0.2
family ipv4
export "static-to-bgp"
advertise-label ipv4
split-horizon
exit
exit
no shutdown
---------------------------------------------*A:csc-ce-1>config>router>bgp#

Note the following about the BGP configuration of CSC-CE-1:

The peer type is EBGP (peer-as is different from the locally configured autonomoussystem)

The transport for the EBGP session is IPv4 (the neighbor address is an IPv4 address)

The advertise-label ipv4 command causes MP-BGP negotiation of the address family for
AFI=1 and SAFI=4 (IPv4 NLRI with MPLS labels), as can be observed from the
following debug trace (using the command debug router bgp open) of the OPEN
message from CSC-CE-1.

2 2013/07/10 09:29:34.36 EST MINOR: DEBUG #2001 Base BGP


"BGP: OPEN
Peer 1: 192.168.0.2 - Send (Passive) BGP OPEN: Version 4
AS Num 64496: Holdtime 90: BGP_ID 192.0.2.1: Opt Length 16
Opt Para: Type CAPABILITY: Length = 14: Data:
Cap_Code MP-BGP: Length 4
Bytes: 0x0 0x1 0x0 0x4
Cap_Code ROUTE-REFRESH: Length 0
Cap_Code 4-OCTET-ASN: Length 4
Bytes: 0x0 0x0 0xfb 0xf0
"

The split-horizon command is optional. It prevents a best BGP route from the CSC-PE peer from
being re-advertised back to that peer.
The export command applies a BGP export policy to the session. The configuration of the policy
is shown below:
*A:csc-ce-1>config>router>policy-options# info
---------------------------------------------prefix-list "system-ip"
prefix 192.0.2.1/32 exact
exit
policy-statement "static-to-bgp"

Page 454

Advanced Configuration Guide

Carrier Supporting Carrier IP VPNs

entry 10
from
protocol direct
prefix-list "system-ip"
exit
action accept
exit
exit
default-action reject
exit
---------------------------------------------*A:csc-ce-1>config>router>policy-options#

The effect of the BGP export policy is to advertise the system IP address of CSC-CE-1 as a
labelled-IPv4 BGP route towards the CSC-PE(s).
Step 2.

Configure CSC service on CSC-PE-1.

CSC-PE-1 must be configured with a VPRN in carrier-carrier-vpn mode in order to provide


CSC service to CSC-CE-1. The entire configuration of the VPRN is shown below:
A:csc-pe-1>config>service>vprn# info
---------------------------------------------carrier-carrier-vpn
router-id 192.0.2.251
autonomous-system 64511
route-distinguisher 64511:1
auto-bind mpls
vrf-target target:64511:1
network-interface "csc-pe-1-to-csc-ce-1" create
address 192.168.0.2/30
port 1/1/1
no shutdown
exit
bgp
group "csc-ce"
as-override
export "bgp-vpn-routes"
peer-as 64496
neighbor 192.168.0.1
family ipv4
advertise-label ipv4
split-horizon
exit
exit
no shutdown
exit
no shutdown
---------------------------------------------A:csc-pe-1>config>service>vprn#

Note the following about the VPRN configuration of CSC-PE-1:

Advanced Configuration Guide

Page 455

Configuration

The carrier-carrier-vpn command is mandatory. It cannot be configured if the VPRN


currently has any SAP or spoke-SDP access interfaces configured; they must first be
shutdown if necessary and then deleted.

*A:csc-pe-1>config>service>vprn# carrier-carrier-vpn
INFO: PIP #1195 Cannot toggle carrier-carrier-vpn - service interfaces present
*A:csc-pe-1>config>service>vprn#

The auto-bind command should be set appropriately for the type of transport desired to
other CSC-PEs, but note that GRE is not supported.

A:csc-pe-1>config>service>vprn# auto-bind gre


MINOR: SVCMGR #1538 auto-bind config not supported - carrier-carrier vprn
A:csc-pe-1>config>service>vprn#

The interface to CSC-CE-1 must be a network-interface. A network-interface can be


associated with an entire Ethernet port (as shown in the example above), a VLAN subinterface of an Ethernet port, an entire LAG or a VLAN sub-interface of a LAG. In all
cases the associated Ethernet ports must be configured in network or hybrid mode and
must reside on FP2 or higher based cards/systems.

Note the following about the BGP configuration of the CSC VPRN service in CSC-PE-1:

The peer type is EBGP (peer-as is different from the locally configured autonomoussystem).

The transport for the EBGP session is IPv4 (the neighbor address is an IPv4 address).

The advertise-label ipv4 command causes MP-BGP negotiation of the address family for
AFI=1 and SAFI=4 (IPv4 NLRI with MPLS labels).

The split-horizon command is optional. It prevents a best BGP route from the CSC-CE
peer from being re-advertised back to that peer.

The as-override command replaces CSC-CE-1s AS number (64496) with CSC-PE-1s


AS number (64511) in the AS_PATH attribute of routes advertised to CSC-CE-1. Without
this configuration CSC-CE-1 may reject routes originated by CSC-CE-2 as invalid due to
an AS-path loop.

The export command applies a BGP export policy to the session. The configuration of the
policy is shown below:

*A:csc-pe-1>config>router>policy-options# info
---------------------------------------------policy-statement "bgp-vpn-routes"
entry 10
from
protocol bgp-vpn
exit
action accept
exit
exit
default-action reject
exit
----------------------------------------------

Page 456

Advanced Configuration Guide

Carrier Supporting Carrier IP VPNs

*A:csc-pe-1>config>router>policy-options#

The effect of the BGP export policy is to re-advertise VPN-IPv4 routes imported into the CSC
VPRN (and used for forwarding) to CSC-CE-1.
Step 3.

Verify exchange of routes between CSC-CE-1 and CSC-PE-1.

When Steps 1 and 2 have been completed properly CSC-CE-1 should now be advertising the
labelled-IPv4 route for its system IP address to CSC-PE-1. This can be checked from the
perspective of CSC-CE-1 as shown below:
*A:csc-ce-1# show router bgp routes 192.0.2.1/32 hunt
===============================================================================
BGP Router ID:192.0.2.1
AS:64496
Local AS:64496
===============================================================================
Legend Status codes : u - used, s - suppressed, h - history, d - decayed, * - valid
Origin codes : i - IGP, e - EGP, ? - incomplete, > - best, b - backup
===============================================================================
BGP IPv4 Routes
===============================================================================
------------------------------------------------------------------------------RIB In Entries
------------------------------------------------------------------------------------------------------------------------------------------------------------RIB Out Entries
------------------------------------------------------------------------------Network
: 192.0.2.1/32
Nexthop
: 192.168.0.1
Path Id
: None
To
: 192.168.0.2
Res. Nexthop
: n/a
Local Pref.
: n/a
Interface Name : NotAvailable
Aggregator AS : None
Aggregator
: None
Atomic Aggr.
: Not Atomic
MED
: None
AIGP Metric
: None
Connector
: None
Community
: No Community Members
Cluster
: No Cluster Members
Originator Id : None
Peer Router Id : 192.0.2.251
IPv4 Label
: 262142
Origin
: IGP
AS-Path
: 64496
------------------------------------------------------------------------------Routes : 1
===============================================================================
*A:csc-ce-1#

Note that CSC-CE-1 has advertised a label value of 262142 with the prefix.

Advanced Configuration Guide

Page 457

Configuration

The following output shows the received route from the perspective of CSC-PE-1:
*A:csc-pe-1# show router 1 bgp routes 192.0.2.1/32 hunt
===============================================================================
BGP Router ID:192.0.2.251
AS:64511
Local AS:64511
===============================================================================
Legend Status codes : u - used, s - suppressed, h - history, d - decayed, * - valid
Origin codes : i - IGP, e - EGP, ? - incomplete, > - best, b - backup
===============================================================================
BGP IPv4 Routes
===============================================================================
------------------------------------------------------------------------------RIB In Entries
------------------------------------------------------------------------------Network
: 192.0.2.1/32
Nexthop
: 192.168.0.1
Path Id
: None
From
: 192.168.0.1
Res. Nexthop
: 192.168.0.1
Local Pref.
: None
Interface Name : csc-pe-1-to-csc-ce-1
Aggregator AS : None
Aggregator
: None
Atomic Aggr.
: Not Atomic
MED
: None
AIGP Metric
: None
Connector
: None
Community
: No Community Members
Cluster
: No Cluster Members
Originator Id : None
Peer Router Id : 192.0.2.1
Fwd Class
: None
Priority
: None
IPv4 Label
: 262142
Flags
: Used Valid Best IGP
Route Source
: External
AS-Path
: 64496
------------------------------------------------------------------------------RIB Out Entries
------------------------------------------------------------------------------------------------------------------------------------------------------------Routes : 1
===============================================================================
*A:csc-pe-1#

Page 458

Advanced Configuration Guide

Carrier Supporting Carrier IP VPNs

Step 4.

Configure core connectivity for CSC-PE-1.

The next step is to configure the base router instance of CSC-PE-1 so that it can exchange VPNIPv4 routes with CSC-PE-2 (and potentially other CSC-PEs). At a minimum this requires:

Router-id and autonomous-system configuration.

Network interface creation and configuration, including assignment of an IPv4 address to


the system interface.

Configuration of the IGP protocol. In this example IS-IS is used.

Configuration of the LDP protocol (optional).

Configuration of RSVP LSPs used to reach remote CSC-PE devices (optional).

Configuration of the BGP protocol.

These elements of the base router configuration of CSC-PE-1 are shown below:
*A:csc-pe-1>config>router# info
---------------------------------------------#-------------------------------------------------echo "IP Configuration"
#-------------------------------------------------interface "csc-pe-1-to-csc-pe-2"
address 192.168.1.1/30
port 1/2/1
no shutdown
exit
interface "system"
address 192.0.2.251/32
no shutdown
exit
autonomous-system 64511
router-id 192.0.2.251
#-------------------------------------------------echo "ISIS Configuration"
#-------------------------------------------------isis
level-capability level-2
area-id 49.01
level 2
wide-metrics-only
exit
interface "system"
level-capability level-2
passive
no shutdown
exit
interface "csc-pe-1-to-csc-pe-2"
level-capability level-2
interface-type point-to-point
level 2
metric 100
exit
no shutdown

Advanced Configuration Guide

Page 459

Configuration

exit
no shutdown
exit
#-------------------------------------------------echo "LDP Configuration"
#-------------------------------------------------ldp
interface-parameters
interface "csc-pe-1-to-csc-pe-2"
exit
exit
targeted-session
exit
no shutdown
exit
#-------------------------------------------------echo "BGP Configuration"
#-------------------------------------------------bgp
group "core"
peer-as 64511
neighbor 192.0.2.252
family vpn-ipv4
exit
exit
no shutdown
exit
---------------------------------------------*A:csc-pe-1>config>router#

Note the following about the BGP configuration of the base router in CSC-PE-1:

The peer type is IBGP (peer-as is the same as the locally configured autonomoussystem).

The transport for the IBGP session is IPv4 (the neighbor address is an IPv4 address).

The family vpn-ipv4 command causes MP-BGP negotiation of the address family for
AFI=1 and SAFI=128, as can be observed from the following debug trace of the OPEN
message from CSC-PE-1.

1 2013/07/10 10:02:40.31 EST MINOR: DEBUG #2001 Base BGP


"BGP: OPEN
Peer 1: 192.0.2.252 - Send (Passive) BGP OPEN: Version 4
AS Num 64511: Holdtime 90: BGP_ID 192.0.2.251: Opt Length 16
Opt Para: Type CAPABILITY: Length = 14: Data:
Cap_Code MP-BGP: Length 4
Bytes: 0x0 0x1 0x0 0x80
Cap_Code ROUTE-REFRESH: Length 0
Cap_Code 4-OCTET-ASN: Length 4
Bytes: 0x0 0x0 0xfb 0xff
"

Page 460

Advanced Configuration Guide

Carrier Supporting Carrier IP VPNs

Step 5.

Configure core connectivity for CSC-PE-2

The next step is to configure the base router instance of CSC-PE-2 so that it can exchange VPNIPv4 routes with CSC-PE-1 (and potentially other CSC-PEs). At a minimum this requires:

Router-id and autonomous-system configuration.

Network interface creation and configuration, including assignment of an IPv4 address to


the system interface.

Configuration of the IGP protocol. In this example IS-IS is used.

Configuration of the LDP protocol (optional).

Configuration of RSVP LSPs used to reach remote CSC-PE devices (optional).

Configuration of the BGP protocol.

These elements of the base router configuration of CSC-PE-2 are shown below:
A:csc-pe-2>config>router# info
---------------------------------------------#-------------------------------------------------echo "IP Configuration"
#-------------------------------------------------interface "csc-pe-2-to-csc-pe-1"
address 192.168.1.2/30
port 1/1/1
no shutdown
exit
interface "system"
address 192.0.2.252/32
no shutdown
exit
autonomous-system 64511
router-id 192.0.2.252
#-------------------------------------------------echo "ISIS Configuration"
#-------------------------------------------------isis
level-capability level-2
area-id 49.01
level 2
wide-metrics-only
exit
interface "system"
level-capability level-2
passive
no shutdown
exit
interface "csc-pe-2-to-csc-pe-1"
level-capability level-2
interface-type point-to-point
level 2
metric 100
exit
no shutdown

Advanced Configuration Guide

Page 461

Configuration

exit
no shutdown
exit
#-------------------------------------------------echo "LDP Configuration"
#-------------------------------------------------ldp
interface-parameters
interface "csc-pe-2-to-csc-pe-1"
exit
exit
targeted-session
exit
no shutdown
exit
#-------------------------------------------------echo "BGP Configuration"
#-------------------------------------------------bgp
group "core"
cluster 192.0.2.252
peer-as 64511
neighbor 192.0.2.251
family vpn-ipv4
split-horizon
exit
exit
no shutdown
exit
---------------------------------------------A:csc-pe-2>config>router#

Note the following about the BGP configuration of the base router in CSC-PE-2:

Page 462

The peer type is IBGP (peer-as is the same as the locally configured autonomoussystem).

The transport for the IBGP session is IPv4 (the neighbor address is an IPv4 address).

The family vpn-ipv4 command causes MP-BGP negotiation of the address family for
AFI=1 and SAFI=128.

The cluster command configures CSC-PE-2 as a route reflector for clients in the BGP
group called core. This is not required and in a more typical deployment the route
reflector would be a separate router from any CSC-PE.

Advanced Configuration Guide

Carrier Supporting Carrier IP VPNs

Step 6.

Configure CSC service on CSC-PE-2.

CSC-PE-2 must be configured with a VPRN in carrier-carrier-vpn mode in order to provide


CSC service to CSC-CE-2. The entire configuration of the VPRN is shown below:
A:csc-pe-2>config>service>vprn# info
---------------------------------------------carrier-carrier-vpn
router-id 192.0.2.252
autonomous-system 64511
route-distinguisher 64511:2
auto-bind mpls
vrf-target target:64511:1
network-interface "csc-pe-2-to-csc-ce-2" create
address 192.168.2.1/30
port 1/1/2
no shutdown
exit
bgp
group "csc-ce"
as-override
export "bgp-vpn-routes"
peer-as 64496
neighbor 192.168.2.2
family ipv4
advertise-label ipv4
split-horizon
exit
exit
no shutdown
exit
no shutdown
---------------------------------------------A:csc-pe-2>config>service>vprn#

Note the following about the VPRN configuration of CSC-PE-2:

The carrier-carrier-vpn command is mandatory. It cannot be configured if the VPRN


currently has any SAP or spoke-SDP access interfaces configured; they must first be
shutdown if necessary and then deleted.

The auto-bind command should be set appropriately for the type of transport desired to
other CSC-PEs, but note that GRE is not supported.

The interface to CSC-CE-2 must be a network-interface. A network-interface can be


associated with an entire Ethernet port (as shown in the example above), a VLAN subinterface of an Ethernet port, an entire LAG or a VLAN sub-interface of a LAG. In all
cases the associated Ethernet ports must be configured in network or hybrid mode and
must reside on FP2 or higher based cards/systems.

Advanced Configuration Guide

Page 463

Configuration

Note the following about the BGP configuration of the CSC VPRN service in CSC-PE-2:

The peer type is EBGP (peer-as is different from the locally configured autonomoussystem).

The transport for the EBGP session is IPv4 (the neighbor address is an IPv4 address).

The advertise-label ipv4 command causes MP-BGP negotiation of the address family for
AFI=1 and SAFI=4 (IPv4 NLRI with MPLS labels).

The split-horizon command is optional. It prevents a best BGP route from the CSC-CE
peer from being re-advertised back to that peer.

The as-override command replaces CSC-CE-2s AS number (64496) with CSC-PE-2s


AS number (64511) in the AS_PATH attribute of routes advertised to CSC-CE-2. Without
this configuration CSC-CE-2 may reject routes originated by CSC-CE-1 as invalid due to
an AS-path loop.

The export command applies a BGP export policy to the session. The configuration of the
policy is shown below:

*A:csc-pe-2>config>router>policy-options# info
---------------------------------------------policy-statement "bgp-vpn-routes"
entry 10
from
protocol bgp-vpn
exit
action accept
exit
exit
default-action reject
exit
---------------------------------------------*A:csc-pe-2>config>router>policy-options#

The effect of the BGP export policy is to re-advertise VPN-IPv4 routes imported into the CSC
VPRN (and used for forwarding) to CSC-CE-2.

Page 464

Advanced Configuration Guide

Carrier Supporting Carrier IP VPNs

Step 7.

Verify exchange of routes between CSC-PE-1 and CSC-PE-2.

When the preceding steps have been completed properly CSC-PE-1 should now be advertising the
labelled-IPv4 route for 192.0.2.1/32 (the system IP address of CSC-CE-1) to CSC-PE-2. This can
be checked from the perspective of CSC-PE-1 as shown below:
*A:csc-pe-1>config>router# show router bgp routes vpn-ipv4 192.0.2.1/32 hunt
===============================================================================
BGP Router ID:192.0.2.251
AS:64511
Local AS:64511
===============================================================================
Legend Status codes : u - used, s - suppressed, h - history, d - decayed, * - valid
Origin codes : i - IGP, e - EGP, ? - incomplete, > - best, b - backup
===============================================================================
BGP VPN-IPv4 Routes
===============================================================================
------------------------------------------------------------------------------RIB In Entries
------------------------------------------------------------------------------------------------------------------------------------------------------------RIB Out Entries
------------------------------------------------------------------------------Network
: 192.0.2.1/32
Nexthop
: 192.0.2.251
Route Dist.
: 64511:1
VPN Label
: 262137
Path Id
: None
To
: 192.0.2.252
Res. Nexthop
: n/a
Local Pref.
: 100
Interface Name : NotAvailable
Aggregator AS : None
Aggregator
: None
Atomic Aggr.
: Not Atomic
MED
: None
AIGP Metric
: None
Connector
: None
Community
: target:64511:1
Cluster
: No Cluster Members
Originator Id : None
Peer Router Id : 192.0.2.252
Origin
: IGP
AS-Path
: 64496
------------------------------------------------------------------------------Routes : 1
===============================================================================
*A:csc-pe-1>config>router#

Note that CSC-PE-1 has advertised a label value of 262137 with the prefix.
The following output shows the received route from the perspective of CSC-PE-2:
A:csc-pe-2# show router bgp routes vpn-ipv4 192.0.2.1/32 hunt
===============================================================================
BGP Router ID:192.0.2.252
AS:64511
Local AS:64511
===============================================================================
Legend Status codes : u - used, s - suppressed, h - history, d - decayed, * - valid
Origin codes : i - IGP, e - EGP, ? - incomplete, > - best, b - backup
===============================================================================

Advanced Configuration Guide

Page 465

Configuration

BGP VPN-IPv4 Routes


===============================================================================
------------------------------------------------------------------------------RIB In Entries
------------------------------------------------------------------------------Network
: 192.0.2.1/32
Nexthop
: 192.0.2.251
Route Dist.
: 64511:1
VPN Label
: 262137
Path Id
: None
From
: 192.0.2.251
Res. Nexthop
: n/a
Local Pref.
: 100
Interface Name : csc-pe-2-to-csc-pe-1
Aggregator AS : None
Aggregator
: None
Atomic Aggr.
: Not Atomic
MED
: None
AIGP Metric
: None
Connector
: None
Community
: target:64511:1
Cluster
: No Cluster Members
Originator Id : None
Peer Router Id : 192.0.2.251
Fwd Class
: None
Priority
: None
Flags
: Used Valid Best IGP
Route Source
: Internal
AS-Path
: 64496
VPRN Imported : 1
------------------------------------------------------------------------------RIB Out Entries
------------------------------------------------------------------------------------------------------------------------------------------------------------Routes : 1
===============================================================================
A:csc-pe-2#

Also note the label swap entries that BGP programmed in the line cards of CSC-PE-1 based on the
received labelled-IPv4 route from CSC-CE-1 (Label Origin = ExtCarCarVpn) and the advertised
VPN-IPv4 route to CSC-PE-2:
*A:csc-pe-1# show router bgp inter-as-label
===============================================================================
BGP Inter-AS labels
===============================================================================
NextHop
Received
Advertised
Label
Label
Label
Origin
------------------------------------------------------------------------------192.168.0.1
262142
262137
ExtCarCarVpn
------------------------------------------------------------------------------Total Labels allocated:
1
===============================================================================
*A:csc-pe-1#

Page 466

Advanced Configuration Guide

Carrier Supporting Carrier IP VPNs

Step 8.

Configure CSC-CE-2.

This example assumes that CSC-CE-2 is a PE router with Layer 2 and Layer 3 VPN services that
must extend across the CSC VPN service. The configuration of one such Layer 3 VPN service in
CSC-CE-2 is shown below:
A:csc-ce-2>config>service>vprn# info
---------------------------------------------route-distinguisher 64496:2
auto-bind mpls
vrf-target target:64496:1
...
no shutdown
---------------------------------------------A:csc-ce-2>config>service>vprn#

For brevity, the above configuration sample omits commands related to SAP IP interfaces, spokeSDP IP interfaces, PE-CE routing protocols, QoS, IP filters, etc.
The base routing instance of CSC-CE-2 should be configured with the appropriate router-ID and
autonomous-system number and the system interface should be given an IPv4 address (usually the
same as the router-id). The interface to CSC-PE-2 should then be created and configured. The base
router configuration of CSC-CE-2 is shown below:
A:csc-ce-2>config>router# info
---------------------------------------------#-------------------------------------------------echo "IP Configuration"
#-------------------------------------------------interface "int-csc-ce-2-to-csc-pe-2"
address 192.168.2.2/30
port 1/2/1
no shutdown
exit
interface "system"
address 192.0.2.2/32
no shutdown
exit
autonomous-system 64496
router-id 192.0.2.2
---------------------------------------------A:csc-ce-2>config>router#

BGP should be configured as the control plane protocol running on the interface to CSC-PE-2 as
shown below:
A:csc-ce-2>config>router>bgp# info
---------------------------------------------group "csc-pe"
peer-as 64511
neighbor 192.168.2.1
family ipv4

Advanced Configuration Guide

Page 467

Configuration

export "static-to-bgp"
advertise-label ipv4
split-horizon
exit
exit
no shutdown
---------------------------------------------A:csc-ce-2>config>router>bgp#

Note the following about the BGP configuration of CSC-CE-2:

The peer type is EBGP (peer-as is different from the locally configured autonomoussystem).

The transport for the EBGP session is IPv4 (the neighbor address is an IPv4 address).

The advertise-label ipv4 command causes MP-BGP negotiation of the address family for
AFI=1 and SAFI=4 (IPv4 NLRI with MPLS labels).

The split-horizon command is optional. It prevents a best BGP route from the CSC-PE
peer from being re-advertised back to that peer.

The export command applies a BGP export policy to the session. The configuration of the
policy is shown below:

A:csc-ce-2>config>router>policy-options# info
---------------------------------------------prefix-list "system-ip"
prefix 192.0.2.2/32 exact
exit
policy-statement "static-to-bgp"
entry 10
from
protocol direct
prefix-list "system-ip"
exit
action accept
exit
exit
default-action reject
exit
---------------------------------------------A:csc-ce-2>config>router>policy-options#

The effect of the BGP export policy is to advertise the system IP address of CSC-CE-2 as a
labelled-IPv4 BGP route towards CSC-PE-2.

Page 468

Advanced Configuration Guide

Carrier Supporting Carrier IP VPNs

Step 9.

Verify exchange of routes between CSC-PE-2 and CSC-CE-2.

When the preceding steps have been completed properly CSC-PE-2 should now be advertising the
labelled-IPv4 route for 192.0.2.1/32 to CSC-CE-2. This can be checked from the perspective of
CSC-PE-2 as shown below:
A:csc-pe-2# show router 1 bgp routes ipv4 192.0.2.1/32 hunt
===============================================================================
BGP Router ID:192.0.2.252
AS:64511
Local AS:64511
===============================================================================
Legend Status codes : u - used, s - suppressed, h - history, d - decayed, * - valid
Origin codes : i - IGP, e - EGP, ? - incomplete, > - best, b - backup
===============================================================================
BGP IPv4 Routes
===============================================================================
------------------------------------------------------------------------------RIB In Entries
------------------------------------------------------------------------------------------------------------------------------------------------------------RIB Out Entries
------------------------------------------------------------------------------Network
: 192.0.2.1/32
Nexthop
: 192.168.2.1
Path Id
: None
To
: 192.168.2.2
Res. Nexthop
: n/a
Local Pref.
: n/a
Interface Name : NotAvailable
Aggregator AS : None
Aggregator
: None
Atomic Aggr.
: Not Atomic
MED
: None
AIGP Metric
: None
Connector
: None
Community
: target:64511:1
Cluster
: No Cluster Members
Originator Id : None
Peer Router Id : 192.0.2.2
IPv4 Label
: 262139
Origin
: IGP
AS-Path
: 64511 64511
------------------------------------------------------------------------------Routes : 1
===============================================================================
A:csc-pe-2#

Note that CSC-PE-2 has advertised a label value of 262139 with the prefix.
The following output shows the received route from the perspective of CSC-CE-2:
A:csc-ce-2# show router bgp routes ipv4 192.0.2.1/32 hunt
===============================================================================
BGP Router ID:192.0.2.2
AS:64496
Local AS:64496
===============================================================================
Legend Status codes : u - used, s - suppressed, h - history, d - decayed, * - valid
Origin codes : i - IGP, e - EGP, ? - incomplete, > - best, b - backup

Advanced Configuration Guide

Page 469

Configuration

===============================================================================
BGP IPv4 Routes
===============================================================================
------------------------------------------------------------------------------RIB In Entries
------------------------------------------------------------------------------Network
: 192.0.2.1/32
Nexthop
: 192.168.2.1
Path Id
: None
From
: 192.168.2.1
Res. Nexthop
: 192.168.2.1
Local Pref.
: None
Interface Name : int-csc-ce-2-to-csc-p*
Aggregator AS : None
Aggregator
: None
Atomic Aggr.
: Not Atomic
MED
: None
AIGP Metric
: None
Connector
: None
Community
: target:64511:1
Cluster
: No Cluster Members
Originator Id : None
Peer Router Id : 192.0.2.252
Fwd Class
: None
Priority
: None
IPv4 Label
: 262139
Flags
: Used Valid Best IGP
Route Source
: External
AS-Path
: 64511 64511
------------------------------------------------------------------------------RIB Out Entries
------------------------------------------------------------------------------------------------------------------------------------------------------------Routes : 1
===============================================================================
* indicates that the corresponding row element may have been truncated.
A:csc-ce-2#

Also note the label swap entries that BGP programmed in the line cards of CSC-PE-2 based on the
received VPN-IPv4 routes from CSC-PE-1 (Label Origin = Internal) and the advertised labelledIPv4 routes to CSC-CE-2:
A:csc-pe-2# show router 1 bgp inter-as-label
===============================================================================
BGP Inter-AS labels
===============================================================================
NextHop
Received
Advertised
Label
Label
Label
Origin
------------------------------------------------------------------------------192.0.2.251
262137
262139
Internal
192.0.2.251
262143
262137
Internal
------------------------------------------------------------------------------Total Labels allocated:
2
===============================================================================
A:csc-pe-2#

In the above output the first entry for NextHop 192.0.2.251 corresponds to the prefix 192.0.2.1/32;
recall from Step 7 that CSC-PE-2 received the VPN-IPv4 route with label value 262137 and it can
be seen from this step that it re-advertised the route to CSC-CE-2 with label value 262139.

Page 470

Advanced Configuration Guide

Carrier Supporting Carrier IP VPNs

Step 10. Setup BGP session between CSC-CE-1 AND CSC-CE-2.

The final step in the setup of the CSC solution shown in Figure 1 is the creation of a BGP session
between CSC-CE-1 and CSC-CE-2 so that they can exchange routes belonging to VPN services
they support. The configuration of this BGP session from the perspective of CSC-CE-1 is shown
below:
*A:csc-ce-1>config>router>bgp# info
---------------------------------------------group "csc-ce"
peer-as 64496
neighbor 192.0.2.2
family vpn-ipv4
exit
exit
no shutdown
---------------------------------------------*A:csc-ce-1>config>router>bgp#

The configuration of the BGP session from the perspective of CSC-CE-2 is very similar, as shown
below.
A:csc-ce-2>config>router>bgp# info
---------------------------------------------group "csc-ce"
peer-as 64496
neighbor 192.0.2.1
family vpn-ipv4
exit
exit
no shutdown
---------------------------------------------A:csc-ce-2>config>router>bgp#

Note the following about the configuration of the BGP session between CSC-CE-1 and CSC-CE2:

The peer type is IBGP (peer-as is the same as the locally configured autonomoussystem).

The transport for the IBGP session is IPv4 (the neighbor address is an IPv4 address).

The family vpn-ipv4 command causes MP-BGP negotiation of the address family for
AFI=1 and SAFI=128.

Advanced Configuration Guide

Page 471

Configuration

Step 11. Verify exchange of routes between CSC-CE-1 and CSC-CE-2.

When the preceding steps have been completed properly CSC-PE-2 should now be able to
advertise a VPN-IPv4 route for some IP prefix (for example 10.14.30.0/24) to CSC-CE-2. This
can be checked from the perspective of CSC-CE-2 as shown below:
A:csc-ce-2>config>router>bgp# show router bgp routes vpn-ipv4 10.14.30.0/24 hunt
===============================================================================
BGP Router ID:192.0.2.2
AS:64496
Local AS:64496
===============================================================================
Legend Status codes : u - used, s - suppressed, h - history, d - decayed, * - valid
Origin codes : i - IGP, e - EGP, ? - incomplete, > - best, b - backup
===============================================================================
BGP VPN-IPv4 Routes
===============================================================================
------------------------------------------------------------------------------RIB In Entries
------------------------------------------------------------------------------Network
: 10.14.30.0/24
Nexthop
: 192.0.2.1
Route Dist.
: 64496:1
VPN Label
: 262143
Path Id
: None
From
: 192.0.2.1
Res. Nexthop
: n/a
Local Pref.
: 100
Interface Name : NotAvailable
Aggregator AS : None
Aggregator
: None
Atomic Aggr.
: Not Atomic
MED
: None
AIGP Metric
: None
Connector
: None
Community
: target:64496:1
Cluster
: No Cluster Members
Originator Id : None
Peer Router Id : 192.0.2.1
Fwd Class
: None
Priority
: None
Flags
: Used Valid Best IGP
Route Source
: Internal
AS-Path
: No As-Path
VPRN Imported : 1
------------------------------------------------------------------------------RIB Out Entries
------------------------------------------------------------------------------------------------------------------------------------------------------------Routes : 1
===============================================================================
A:csc-ce-2>config>router>bgp#

It is also possible to check that CSC-CE-2 has properly installed the above VPN-IPv4 route into
the routing table of the importing VPRN service, as shown below.
A:csc-ce-2>config>router>bgp# show router 1 route-table
===============================================================================
Route Table (Service: 1)
===============================================================================
Dest Prefix[Flags]
Type
Proto
Age
Pref
Next Hop[Interface Name]
Metric

Page 472

Advanced Configuration Guide

Carrier Supporting Carrier IP VPNs

------------------------------------------------------------------------------10.14.30.0/24
Remote BGP VPN
00h36m03s 170
192.0.2.1 (tunneled)
0
------------------------------------------------------------------------------No. of Routes: 2
Flags: L = LFA nexthop available
B = BGP backup route available
n = Number of times nexthop is repeated
===============================================================================
* indicates that the corresponding row element may have been truncated.
A:csc-ce-2>config>router>bgp#

Advanced Configuration Guide

Page 473

Conclusion

Conclusion
Carrier Supporting Carrier is a scalable and secure solution for using an infrastructure IP VPN to
transport traffic between dispersed CSC-CE devices belonging to an ISP or other service provider.
Many different topology models are supported by the 7x50. This guide has explored one
simplified configuration that can serve as the basis for more complicated setups.

Page 474

Advanced Configuration Guide

Deterministic Large Scale NAT44

In This Chapter
This section provides information about deterministic large scale NAT44 configurations.
Topics in this section include:

Applicability on page 476

Overview on page 477

Configuration on page 481

Conclusion on page 514

Advanced Configuration Guide

Page 475

Applicability

Applicability
This example is applicable to 7750 SR systems and 7450 ESS systems in mixed mode equipped
with an MS-ISA on an IOM3-XP/XP-b using chassis mode B, C or D.
The configuration was tested on release 11.0R3.

Page 476

Advanced Configuration Guide

Deterministic Large Scale NAT44

Overview
Deterministic Network Address Translation (NAT) is a mode of operation where mappings
between the NAT subscriber and the outside IP address and port range are allocated at the time of
configuration.
In deterministic NAT for Large Scale NAT IPv4-to-IPv4 (LSN44) subscribers, each LSN44
subscriber is permanently mapped to an outside IP address and a dedicated (deterministic) portblock based on a specific algorithm.
Logging is not needed in this case as the reverse mapping can be obtained using the reverse of the
above algorithm.
A deterministic LSN44 subscriber can have only one deterministic port-block that can (optionally)
be extended by one or multiple dynamic port-blocks in case all ports in deterministic port-block
are exhausted.
In case an LSN44 subscriber has been assigned both deterministic and dynamic port blocks,
logging for the dynamic port-block allocation/de-allocation is required.
A scalable logging solution for dynamic port-blocks is achievable using RADIUS or IPFIX.
Logging for dynamic port-blocks is out of the scope of this example.

Outside
IPs

Deterministic Blocks
0

1023

IP1_x

WK
Range

PF
Range

Outside
Range x IP2_x

WK
Range

PF
Range

IP3_x

WK
Range

PF
Range

IP1_y

WK
Range

PF
Range

IP2_y

WK
Range

PF
Range

Outside
Range y

(Optional)
Dynamic Blocks
65,535

Well Known Static Port


Port Range Forwarding
Range

Inside Prefix A
IP1_A
IP2_A
IP3_A
...
Inside Prefix B
IP1_B
IP2_B
IP3_B
...

al_0333

Figure 86: Deterministic NAT Mapping

Advanced Configuration Guide

Page 477

Overview

Algorithm
The deterministic NAT algorithm makes a predictable mapping between the (inside IP, routing
instance) and the (outside IP, routing instance, deterministic port block).
The algorithm is revertive, meaning that a given (outside IP, routing instance, deterministic port
block) will derive a given (Inside IP, Routing Instance).
The algorithm is loosely based on the draft RFC draft-donley-behave-deterministic-cgn-00.txt,
which allows for the dynamic expansion of the port-blocks once the ports in the original
deterministic port-block are exhausted.

2
1

3
(Inside IP, Routing Instance)

Deterministic
NAT Algorithm
3

Fwd Mapping
Inverse Mapping

(Outside IP, Routing Instance, Deterministic Port Block)


al_0334

Figure 87: Deterministic NAT Algorithm

Page 478

Advanced Configuration Guide

Deterministic Large Scale NAT44

Deterministic Mapping
Any inside prefix in any routing instance can be mapped to any pool in any routing instance.
In deterministic NAT, prefixes from multiple routing instances can be mapped to the same outside
pool, also prefixes from a single inside routing instance can be selectively mapped to different
outside pools.
Inside

Outside
Deterministic NAT
Prefix-a
Prefix-b
Prefix-c

Base Router*

Pool-a

VPRN-I*
Prefix-d

Pool-b

Prefix-e

Pool-c
Base Router*

VPRN-O*

Prefix-f

Pool-d

Prefix-g

* Routing-Based NAT cannot be used if inside/outside routing instances are the same
al_0335

Figure 88: Deterministic Mapping: Inside -> Outside Routing Instances

Advanced Configuration Guide

Page 479

Overview

Mapping Rules
A deterministic LSN44 subscriber is mapped to only one deterministic block which can further be
extended to multiple dynamic blocks if ports within the deterministic block are exhausted.
The subscriber-limit is the number of subscribers that can be deterministically mapped to an
outside IP address (i.e. compression ratio) and MUST be a power of 2.
The total number of deterministic ports (DetP) per outside IP address is determined by the number
of subscribers per outside IP address and the number of deterministic ports per subscriber.
The remaining ports (DynP) beyond the deterministic port range up to 65535 will be dedicated for
dynamic use when a deterministic block is exhausted.
Every host using an inside prefix is guaranteed one dedicate block in the deterministic port ranges.
If the inside prefix length is m < 32-n, where 2^n=subscriber-limit, then the prefix must be broken
into pieces so that all hosts (subscriber-limit) in each piece maps exactly to one outside IP address.

For example, if there is an inside prefix 192.168.0.0/23, here m=23; and the subscriberlimit is also set to 256, then n=8. This results in 23 < 24 (32-8) and so this inside prefix
has to be broken into 2 pieces, in other words this inside prefix will fit into 2 outside IP
addresses, each of 256 port-blocks.

In case that the prefix length is m 32-n, where 2^n=subscriber-limit, then all hosts from the
configured prefix are mapped to the same outside IP.

For example, if there is an inside prefix 192.168.1.0/25, here m=25 and there can be at
most 128 hosts, and the subscriber-limit is set to 256, then n=8. This results in 25 > 24
(32-8), so definitely 128 hosts can fit in one outside IP as there are 256 available portblocks, in other words this inside prefix will fit into one outside IP where 128 blocks have
been used out of the 256 port-blocks available, and the rest (256-128) are wasted.

Overbooking of the outside address pool is not supported in deterministic NAT.


DetP
0
Outside IP

1023

DynP

65,535

WK Port Range PF Port Range


Deterministic Port Ranges

Dynamic Port Ranges


al_0351

Figure 89: Deterministic Mapping: Outside IP Port-Blocks/Ranges

Page 480

Advanced Configuration Guide

Deterministic Large Scale NAT44

Configuration

Tester Port 1

3/2/1

MS-ISA
MS-ISA

BNG-1

3/2/2

Tester Port 2

al_0336

Figure 90: Test Topology

Configuration Pre-Requisites
Chassis mode, card, and MDA configuration.
configure
system
chassis-mode d
exit all
configure
card 3
card-type iom3-xp
mda 1
mda-type isa-bb
no shutdown
exit
no shutdown
exit
card 4
card-type iom3-xp
mda 1
mda-type isa-bb
no shutdown
exit
no shutdown
exit all

Note: Private address ranges are used in outside pools within this example but normally public
address ranges would be used.

Advanced Configuration Guide

Page 481

Configuration

Configure a NAT group


Create the nat-group, and add the MS-ISAs created above to the nat-group; up to 10 MS-ISAs of
type isa-bb can be configured under the nat-group.
configure isa
nat-group 1 create
active-mda-limit 2
mda 3/1
mda 4/1
no shutdown
exit all

Configuration Commands
A NAT outside pool is configured using the following command:
configure {router | service vprn <service-id>}
nat
outside
pool <nat-pool-name> [nat-group <nat-group-id> type <pool-type> create]
port-reservation {blocks <num-blocks> | ports <num-ports>}
port-forwarding-range <range-end>
subscriber-limit <subscriber-limit>
deterministic
port-reservation <num-ports>
exit
address-range <start-ip-address> <end-ip-address> create
exit
exit
exit
exit

where:
nat-pool-name Specifies the name of the NAT pool up to 32 characters max.
nat-group-id Specifies the NAT group ID. The values are 1 4.
pool-type Species the pool type (large-scale).
num-blocks Specifies the number of port-blocks per IP address. Setting num-blocks to one (1)
for large scale NAT will enable 1:1 NAT for IP addresses in this pool The values are 1 64512
num-ports Specifies the number of ports per block. The values are 1 32256
range-end Specifies the end of the port range available for port forwarding. The values are
1023 65535

Page 482

Advanced Configuration Guide

Deterministic Large Scale NAT44

subscriber-limit Specifies the maximum number of subscribers per IP address.


A power of 2 (2^n) number for deterministic NAT
[1,2,4,8,16,32,64,128,256,512,1024,2048, 4096, 8192,16348, 32768]
1..65535 for non-deterministic NAT
default: 65535 for non-deterministic
num-ports Specifies the number of ports in a deterministic port block that is allocated and
dedicated to a single subscribers during the configuration phase. The values are 1..65535
start-ip-address Specifies the beginning IP address in a.b.c.d form.
end-ip-address Specifies the ending IP address in a.b.c.d. form.
Notes:
When the subscriber-limit equals 1, each subscriber is mapped to a single outside IP
address, though the NAPT (port translation) function is still performed.
1:1 NAT mode in combination with deterministic NAT is not supported.

A NAT policy is configured using the following command:


configure service nat
nat-policy <nat-policy-name> [create]
block-limit <[1..40]>
pool <nat-pool-name> {router <router-instance> | service-name <service-name>}
exit

where:
nat-policy-name Specifies the NAT policy name up to 32 characters max.
block-limit The max number of deterministic plus dynamic port blocks that can be assigned to a
single inside IP address. In other words, the maximum number of dynamic port blocks that
can be assigned to an inside IP address when the deterministic port block is exhausted equals
(block-limit - 1).
nat-pool-name Specifies the NAT pool name up to 32 characters max.
router-instance Specifies the router instance the pool belongs to, either by router name or
service ID. : <router-name>|<service-id>
The router name values are Base or service-id [1..2147483647]
service-name Specifies the name of the service up to 64 characters max.

Advanced Configuration Guide

Page 483

Configuration

A NAT inside prefix is configured using the following command:


configure [router| service vprn <service-id>]
nat
inside
deterministic
classic-lsn-max-subscriber-limit <max>
prefix <ip-prefix/length> subscriber-type <nat-sub-type> nat-policy <nat-policyname> create
map start <lsn-sub-address> end <lsn-sub-address> to <outside-ip-address>
no shutdown
exit
exit
exit
exit

where:
max The power of 2 (2^n) number that must match the largest subscriber limit number in a
deterministic pool referenced from this inside routing instance. The range for this command is the
same as the subscriber-limit command under the pool hierarchy. The values are 1,2,4,8 2768
ip-prefix/length A prefix on the inside encompassing subscribers that will be deterministically
mapped to an outside IP address and port block in the corresponding pool.
<ip-prefix/ip-pref*> <ipv4-prefix>/<ipv4-prefix-length> |
<ipv6-prefix>/<ipv6-prefix-length>
<ipv4-prefix>
a.b.c.d (host bits must be 0)
<ipv4-prefix-length>
[0..32]
<ipv6-prefix>
x:x:x:x:x:x:x:x (eight 16-bit pieces)
x:x:x:x:x:x:d.d.d.d
x - [0..FFFF]H
d - [0..255]D
<ipv6-prefix-length>
[0..128]
<nat-sub-type>:
classic-lsn-sub
<nat-policy-name>
Specifies a NAT policy name up to 32 characters in length.

classic-lsn-max-subscriber-limit:
Should be greater than the largest subscriber-limit of all pools referenced by the NAT
policies within the corresponding inside routing instance.
Must be configured before any inside prefix configuration.
Must be 2^n and affects the ingress hashing of deterministic subscribers and also nondeterministic subscribers in case both are configured under the same inside router
instance.

Page 484

Advanced Configuration Guide

Deterministic Large Scale NAT44

Three cases are now configured to demonstrate the use of deterministic and dynamic port-block
usage:

Case 1 on page 486: Mapping multiple prefixes from the same VRF into the same outside
pool.

Case 2 on page 496: Mapping multiple prefixes from the same VRF into different outside
pools.

Case 3 on page 503: Mapping overlapping prefixes from different VRFs into the same
outside pool.

In each case all of the traffic is NATed.

Advanced Configuration Guide

Page 485

Configuration

Case 1
Configured with:

Mapping multiple prefixes from the same VRF into the same outside pool.

NAT all traffic.

Inside

Outside
Deterministic NAT
Base Router
10.0.0.0/24
nat-pool-1

VPRN-15001
10.10.4.0/22

al_0337

Figure 91: Case 1

The NAT outside pool is configured as follows:


configure router nat
outside
pool "nat-pool-1" nat-group 1 type large-scale create
port-reservation ports 180
port-forwarding-range 4023
subscriber-limit 128
deterministic
port-reservation 300
exit
address-range 192.168.0.1 192.168.0.100 create
exit
no shutdown
exit all

The NAT policy is configured as follows:


configure service nat
nat-policy "nat-policy-1" create
block-limit 4
pool "nat-pool-1" router Base
exit all

Page 486

Advanced Configuration Guide

Deterministic Large Scale NAT44

The NAT inside prefix is configured as follows:


configure service vprn 15001 nat
inside
destination-prefix 0.0.0.0/0
deterministic
classic-lsn-max-subscriber-limit 256
prefix 10.0.0.0/24 subscriber-type classic-lsn-sub
nat-policy "nat-policy-1" create
map start 10.0.0.0 end 10.0.0.255 to 192.168.0.1
no shutdown
exit
prefix 10.10.4.0/22 subscriber-type classic-lsn-sub
nat-policy "nat-policy-1" create
map start 10.10.4.0 end 10.10.7.255 to 192.168.0.3
no shutdown
exit all

Notes:

The classic-lsn-max-subscriber-limit value should be greater or equal to the largest


subscriber-limit of all pools referenced by NAT policies within the corresponding inside
routing instance. It must be 2^n and affects ingress hashing of deterministic subscribers.

map statements are automatically created when the prefix is created and it is no
shutdown.

Show commands

Prefix 10.0.0.0/24
Since the subscriber-limit is 128 in this case, the 10.0.0.0/24 prefix will be broken into
two smaller prefixes each of /25, each will be mapped into a specific outside IP
address.
To show Large Scale NAT (LSN) hosts for inside routing instance 15001 for the first
/25 prefix and the mapping to which outside IP, the following command can be used:

show router 15001 nat lsn-hosts inside-ip-prefix 10.0.0.0/25


===============================================================================
Large-Scale NAT hosts for router 15001
===============================================================================
Inside IP
Out-Router
Outside IP
------------------------------------------------------------------------------10.0.0.0
Base
192.168.0.1
10.0.0.1
Base
192.168.0.1
<snip>
10.0.0.127
Base
192.168.0.1
------------------------------------------------------------------------------No. of hosts: 128
===============================================================================

Advanced Configuration Guide

Page 487

Configuration

To show LSN hosts for the inside routing instance 15001 for the second /25 prefix and the
mapping to which outside IP, the following command can be used:
show router 15001 nat lsn-hosts inside-ip-prefix 10.0.0.128/25
===============================================================================
Large-Scale NAT hosts for router 15001
===============================================================================
Inside IP
Out-Router
Outside IP
------------------------------------------------------------------------------10.0.0.128
Base
192.168.0.2
10.0.0.129
Base
192.168.0.2
<snip>
10.0.0.255
Base
192.168.0.2
------------------------------------------------------------------------------No. of hosts: 128
===============================================================================

To show LSN blocks on the outside routing instance Base for the first inside IP within 10.0.0.0/
24 prefix, the following command can be used:
show router nat lsn-blocks inside-ip 10.0.0.0
===============================================================================
Large-Scale NAT blocks for Base
===============================================================================
192.168.0.1 [4024..4323]
Pool
: nat-pool-1
Policy
: nat-policy-1
Started
: 2013/07/21 09:30:20
Inside router
: vprn15001
Inside IP address
: 10.0.0.0
------------------------------------------------------------------------------Number of blocks: 1
===============================================================================

To show LSN blocks on the outside routing instance Base for the last inside IP within 10.0.0.0/
24 prefix, the following command can be used:
show router nat lsn-blocks inside-ip 10.0.0.255
===============================================================================
Large-Scale NAT blocks for Base
===============================================================================
192.168.0.2 [42124..42423]
Pool
: nat-pool-1
Policy
: nat-policy-1
Started
: 2013/07/21 09:30:20
Inside router
: vprn15001
Inside IP address
: 10.0.0.255
------------------------------------------------------------------------------Number of blocks: 1
===============================================================================

Page 488

Advanced Configuration Guide

Deterministic Large Scale NAT44

Prefix 10.10.4.0/22

Since the subscriber-limit is 128 in this case, the 10.10.4.0/22 prefix will be
broken into 8 smaller prefixes each of /25, each will be mapped into a specific
outside IP address.

To show LSN hosts for the inside routing instance 15001 for the first /25 prefix
and the mapping to which outside IP, the following command can be used:

show router 15001 nat lsn-hosts inside-ip-prefix 10.10.4.0/25


===============================================================================
Large-Scale NAT hosts for router 15001
===============================================================================
Inside IP
Out-Router
Outside IP
------------------------------------------------------------------------------10.10.4.0
Base
192.168.0.3
10.10.4.1
Base
192.168.0.3
<snip>
10.10.4.127
Base
192.168.0.3
------------------------------------------------------------------------------No. of hosts: 128
===============================================================================

To show LSN hosts for the inside routing instance 15001 for the last /25 prefix and the mapping to
which outside IP, the following command can be used:
show router 15001 nat lsn-hosts inside-ip-prefix 10.10.7.128/25
===============================================================================
Large-Scale NAT hosts for router 15001
===============================================================================
Inside IP
Out-Router
Outside IP
------------------------------------------------------------------------------10.10.7.128
Base
192.168.0.10
10.10.7.129
Base
192.168.0.10
<snip>
10.10.7.255
Base
192.168.0.10
------------------------------------------------------------------------------No. of hosts: 128
===============================================================================

To show LSN blocks on the outside routing instance Base for the first inside IP within 10.10.4.0/
24 prefix, the following command can be used:
show router nat lsn-blocks inside-ip 10.10.4.0
===============================================================================
Large-Scale NAT blocks for Base
===============================================================================
192.168.0.3 [4024..4323]
Pool
: nat-pool-1
Policy
: nat-policy-1

Advanced Configuration Guide

Page 489

Configuration

Started
Inside router
Inside IP address

: 2013/07/21 09:30:20
: vprn15001
: 10.10.4.0

------------------------------------------------------------------------------Number of blocks: 1
===============================================================================

To show LSN blocks on the outside routing instance Base for the last inside IP within 10.10.4.0/24
prefix, the following command can be used:
show router nat lsn-blocks inside-ip 10.10.7.255
===============================================================================
Large-Scale NAT blocks for Base
===============================================================================
192.168.0.10 [42124..42423]
Pool
: nat-pool-1
Policy
: nat-policy-1
Started
: 2013/07/21 09:30:26
Inside router
: vprn15001
Inside IP address
: 10.10.7.255
------------------------------------------------------------------------------Number of blocks: 1
===============================================================================

Page 490

Advanced Configuration Guide

Deterministic Large Scale NAT44

Mapping results
According to this configuration, each inside IP address has one deterministic block of 300 ports
and can have up to three dynamic blocks (block-limit = 4) each of 180 ports, allowing a maximum
of 300+3*180 = 840 flows.

128 Det Port


Blocks Per
Outside IP
0

Inside Range 10.0.0.0/24:


10.0.0.0/25
10.0.0.128/25

1023

4023

192.168.0.1

WK Range PF Range

192.168.0.2

WK Range PF Range

192.168.0.3

WK Range PF Range

Inside Range 10.10.4.0/22:


10.10.4.0/25
10.10.4.128/25

192.168.0.4

WK Range PF Range

10.10.7.128/25

192.168.0.10

WK Range PF Range

192.168.0.100 WK Range PF Range 300 300 300

42,423

300

Deterministic Port Ranges

65,535

180 180 180 180

180 180

Dynamic Port Ranges

al_0338

Figure 92: Case 1 Results

Sending Flows

BNG-1

UDP Flows
SRC-IP:10.0.0.1
SRC-Port:32000-32xxx

VPRN
15001

al_0339

Figure 93: Case 1 Flows

Advanced Configuration Guide

Page 491

Configuration

For the inside IP 10.0.0.1 several UDP flows will be sent and both the deterministic and dynamic
blocks mappings will be verified.
When sending UDP flows 300 Flows

All flows are mapped to a single deterministic block since the number of ports in a
deterministic block is 300.

There is no logging; since no dynamic blocks are used, and only the deterministic block is
used.

To show LSN blocks on the outside routing instance Base and the outside ports allocated
for the inside IP 10.0.0.1, the following command can be used:

show router nat lsn-blocks inside-ip 10.0.0.1


===============================================================================
Large-Scale NAT blocks for Base
===============================================================================
192.168.0.1 [4324..4623]
Pool
: nat-pool-1
Policy
: nat-policy-1
Started
: 2013/07/21 09:30:20
Inside router
: vprn15001
Inside IP address
: 10.0.0.1
------------------------------------------------------------------------------Number of blocks: 1
===============================================================================

When increasing number of flows such that : 301 Flows 480

In addition to the deterministic block (300 ports), there will be an extension by 1 dynamic
block of 180 ports (port-reservation=180).

Logging occurs for the dynamic port-block.

To show LSN blocks on the outside routing instance Base and the outside ports allocated
for the inside IP 10.0.0.1, the following command can be used:

show router nat lsn-blocks inside-ip 10.0.0.1


===============================================================================
Large-Scale NAT blocks for Base
===============================================================================
192.168.0.1 [4324..4623]
Pool
: nat-pool-1
Policy
: nat-policy-1
Started
: 2013/07/21 09:30:20
Inside router
: vprn15001
Inside IP address
: 10.0.0.1
192.168.0.1 [42424..42603]
Pool
Policy
Started

Page 492

: nat-pool-1
: nat-policy-1
: 2013/07/21 09:33:21

Advanced Configuration Guide

Deterministic Large Scale NAT44

Inside router
: vprn15001
Inside IP address
: 10.0.0.1
------------------------------------------------------------------------------Number of blocks: 2
===============================================================================

Logging is verified using Log 99 (in case event-control nat events are generated) which shows the
mapping details to the new dynamic block as follows:
137 2013/07/21 09:33:21.90 UTC MINOR: NAT #2012 Base NAT
"{1} Map 192.168.0.1 [42424-42603] MDA 4/1 -- 276824065 classic-lsn-sub vprn15001
10.0.0.1 at 2013/07/21 09:33:21"

When increasing number of flows such that: 481 Flows 660

In addition to the deterministic block (300 ports), there will be an extension by 2 dynamic
blocks of 180 ports each.

Logging occurs for the dynamic port-blocks.

To show LSN blocks on the outside routing instance Base and the outside ports allocated
for the inside IP 10.0.0.1, the following command is used:

show router nat lsn-blocks inside-ip 10.0.0.1


===============================================================================
Large-Scale NAT blocks for Base
===============================================================================
192.168.0.1 [4324..4623]
Pool
: nat-pool-1
Policy
: nat-policy-1
Started
: 2013/07/21 09:30:20
Inside router
: vprn15001
Inside IP address
: 10.0.0.1
192.168.0.1 [42424..42603]
Pool
Policy
Started
Inside router
Inside IP address

:
:
:
:
:

nat-pool-1
nat-policy-1
2013/07/21 09:33:21
vprn15001
10.0.0.1

192.168.0.1 [42604..42783]
Pool
: nat-pool-1
Policy
: nat-policy-1
Started
: 2013/07/21 09:35:44
Inside router
: vprn15001
Inside IP address
: 10.0.0.1
------------------------------------------------------------------------------Number of blocks: 3
===============================================================================

Advanced Configuration Guide

Page 493

Configuration

Logging is verified using Log 99 (in case event-control nat events are generated) which shows the
mapping details to the new dynamic block as follows:
138 2013/07/21 09:35:44.20 UTC MINOR: NAT #2012 Base NAT
"{2} Map 192.168.0.1 [42604-42783] MDA 4/1 -- 276824065 classic-lsn-sub vprn15001
10.0.0.1 at 2013/07/21 09:35:44"

When increasing number of flows such that :661 Flows 840

In addition to the deterministic block (300 ports), there will be an extension by 3 dynamic
blocks of 180 ports each.

Logging occurs for the dynamic port-blocks.

To show LSN blocks on the outside routing instance Base and the outside ports
allocated for the inside IP 10.0.0.1, the following command can be used:

show router nat lsn-blocks inside-ip 10.0.0.1


===============================================================================
Large-Scale NAT blocks for Base
===============================================================================
192.168.0.1 [4324..4623]
Pool
: nat-pool-1
Policy
: nat-policy-1
Started
: 2013/07/21 09:30:20
Inside router
: vprn15001
Inside IP address
: 10.0.0.1
192.168.0.1 [42424..42603]
Pool
Policy
Started
Inside router
Inside IP address

:
:
:
:
:

nat-pool-1
nat-policy-1
2013/07/21 09:33:21
vprn15001
10.0.0.1

192.168.0.1 [42604..42783]
Pool
Policy
Started
Inside router
Inside IP address

:
:
:
:
:

nat-pool-1
nat-policy-1
2013/07/21 09:35:44
vprn15001
10.0.0.1

192.168.0.1 [42784..42963]
Pool
: nat-pool-1
Policy
: nat-policy-1
Started
: 2013/07/21 09:37:08
Inside router
: vprn15001
Inside IP address
: 10.0.0.1
------------------------------------------------------------------------------Number of blocks: 4
===============================================================================

Page 494

Advanced Configuration Guide

Deterministic Large Scale NAT44

Logging is verified using Log 99 (in case event-control nat events are generated) which shows the
mapping details to the new dynamic block as follows:
139 2013/07/21 09:37:08.10 UTC MINOR: NAT #2012 Base NAT
"{3} Map 192.168.0.1 [42784-42963] MDA 4/1 -- 276824065 classic-lsn-sub vprn15001
10.0.0.1 at 2013/07/21 09:37:08"

When increasing number of flows such that :Flows > 840

No more extension by dynamic blocks (block-limit = 4) allowed.

Any flows more than 840 will be dropped and the relevant NAT statistics incremented.

To verify NAT statistics, firstly check the NAT group/member and MS-ISA associated
with the outside IP 192.168.0.1/32:

show router route-table 192.168.0.1/32


===============================================================================
Route Table (Router: Base)
===============================================================================
Dest Prefix[Flags]
Type
Proto
Age
Pref
Next Hop[Interface Name]
Metric
------------------------------------------------------------------------------192.168.0.1/32
Remote NAT
00h07m50s 0
NAT outside to mda 4/1
0
------------------------------------------------------------------------------No. of Routes: 1
Flags: L = LFA nexthop available
B = BGP backup route available
n = Number of times nexthop is repeated
===============================================================================

To check which group/member does this MS-ISA belong to, the following command can be used:
show isa nat-group 1 members
===============================================================================
ISA Group 1 members
===============================================================================
Group Member
State
Mda Addresses Blocks
Se-% Hi Se-Prio
------------------------------------------------------------------------------1
1
active
3/1 4
1024
< 1 N 0
1
2
active
4/1 6
1536
< 1 N 0
------------------------------------------------------------------------------No. of members: 2
===============================================================================

To verify relevant statistics for this NAT group/member, the following command can be used:
show isa nat-group 1 member 2 statistics | match "no ip or port"
no ip or port
: 2135

Advanced Configuration Guide

Page 495

Configuration

Case 2
Configured with:

Mapping multiple prefixes from the same VRF into different outside pools.

NAT all traffic.

Inside

Outside
Deterministic NAT

10.1.0.0/23

nat-pool-2

VPRN-15001

VPRN-15002

10.2.0.0/22

nat-pool-3

al_0340

Figure 94: Case 2

The NAT outside pools are configured as follows:


configure service vprn 15002 nat
outside
pool "nat-pool-2" nat-group 1 type large-scale create
port-reservation ports 80
subscriber-limit 256
deterministic
port-reservation 180
exit
address-range 192.168.2.1 192.168.2.200 create
exit
no shutdown
exit
pool "nat-pool-3" nat-group 1 type large-scale create
port-reservation ports 120
port-forwarding-range 4023
subscriber-limit 64
deterministic
port-reservation 840
exit
address-range 192.168.3.1 192.168.3.200 create
exit
no shutdown
exit all

Page 496

Advanced Configuration Guide

Deterministic Large Scale NAT44

The NAT policies are configured as follows:


configure service nat
nat-policy "nat-policy-2" create
block-limit 4
pool "nat-pool-2" router 15002
exit
nat-policy "nat-policy-3" create
block-limit 2
pool "nat-pool-3" router 15002
exit
exit all

The NAT inside prefix is configured as follows:


configure service vprn 15001 nat
inside
destination-prefix 0.0.0.0/0
deterministic
classic-lsn-max-subscriber-limit 256
prefix 10.1.0.0/23 subscriber-type classic-lsn-sub
nat-policy "nat-policy-2" create
map start 10.1.0.0 end 10.1.1.255 to 192.168.2.1
no shutdown
exit
prefix 10.2.0.0/22 subscriber-type classic-lsn-sub
nat-policy "nat-policy-3" create
map start 10.2.0.0 end 10.2.3.255 to 192.168.3.1
no shutdown
exit all

Show commands

Prefix 10.1.0.0/23
Since the subscriber-limit is 256 in this case, the 10.1.0.0/23 prefix will be broken into
two smaller prefixes each of /24, each will be mapped into a specific outside IP
address.
To show Large Scale NAT (LSN) hosts for the inside routing instance 15001 for the
first /24 prefix and the mapping to which outside IP, the following command can be
used:

show router 15001 nat lsn-hosts inside-ip-prefix 10.1.0.0/24


===============================================================================
Large-Scale NAT hosts for router 15001
===============================================================================
Inside IP
Out-Router
Outside IP
------------------------------------------------------------------------------10.1.0.0
15002
192.168.2.1

Advanced Configuration Guide

Page 497

Configuration

10.1.0.1
15002
192.168.2.1
<snip>
10.1.0.255
15002
192.168.2.1
------------------------------------------------------------------------------No. of hosts: 256
===============================================================================

To show LSN hosts for the inside routing instance 15001 for the second /24 prefix and the
mapping to which outside IP, the following command can be used:
show router 15001 nat lsn-hosts inside-ip-prefix 10.1.1.0/24
===============================================================================
Large-Scale NAT hosts for router 15001
===============================================================================
Inside IP
Out-Router
Outside IP
------------------------------------------------------------------------------10.1.1.0
15002
192.168.2.2
10.1.1.1
15002
192.168.2.2
<snip>
10.1.1.255
15002
192.168.2.2
------------------------------------------------------------------------------No. of hosts: 256
===============================================================================

To show LSN blocks on the outside routing instance 15002 for the first inside IP within 10.1.0.0/
23 prefix, the following command can be used:
show router 15002 nat lsn-blocks inside-ip 10.1.0.0
===============================================================================
Large-Scale NAT blocks for vprn15002
===============================================================================
192.168.2.1 [1024..1203]
Pool
: nat-pool-2
Policy
: nat-policy-2
Started
: 2013/07/21 09:55:49
Inside router
: vprn15001
Inside IP address
: 10.1.0.0
------------------------------------------------------------------------------Number of blocks: 1
===============================================================================

To show LSN blocks on the outside routing instance 15002 for the last inside IP within 10.1.0.0/23
prefix, the following command can be used:
show router 15002 nat lsn-blocks inside-ip 10.1.1.255
===============================================================================
Large-Scale NAT blocks for vprn15002
===============================================================================
192.168.2.2 [46924..47103]
Pool
: nat-pool-2
Policy
: nat-policy-2
Started
: 2013/07/21 09:55:49
Inside router
: vprn15001
Inside IP address
: 10.1.1.255

Page 498

Advanced Configuration Guide

Deterministic Large Scale NAT44

------------------------------------------------------------------------------Number of blocks: 1
===============================================================================

Prefix 10.2.0.0/22
Since the subscriber-limit is 64 in this case, the 10.2.0.0/22 prefix will be broken into
16 smaller prefixes each of /26, each will be mapped into a specific outside IP
address.
To show LSN hosts for the inside routing instance 15001 for the first /26 prefix and
the mapping to which outside IP, the following command can be used:

show router 15001 nat lsn-hosts inside-ip-prefix 10.2.0.0/26


===============================================================================
Large-Scale NAT hosts for router 15001
===============================================================================
Inside IP
Out-Router
Outside IP
------------------------------------------------------------------------------10.2.0.0
15002
192.168.3.1
10.2.0.1
15002
192.168.3.1
<snip>
10.2.0.63
15002
192.168.3.1
------------------------------------------------------------------------------No. of hosts: 64
===============================================================================

To show LSN hosts for the inside routing instance 15001 for last /26 prefix and mapping to which
outside IP, the following command can be used:
show router 15001 nat lsn-hosts inside-ip-prefix 10.2.3.192/26
===============================================================================
Large-Scale NAT hosts for router 15001
===============================================================================
Inside IP
Out-Router
Outside IP
------------------------------------------------------------------------------10.2.3.192
15002
192.168.3.16
10.2.3.193
15002
192.168.3.16
<snip>
10.2.3.255
15002
192.168.3.16
------------------------------------------------------------------------------No. of hosts: 64
===============================================================================

Advanced Configuration Guide

Page 499

Configuration

To show LSN blocks on the outside routing instance 15002 for the first inside IP within 10.2.0.0/
22 prefix, the following command can be used:
show router 15002 nat lsn-blocks inside-ip 10.2.0.0
===============================================================================
Large-Scale NAT blocks for vprn15002
===============================================================================
192.168.3.1 [4024..4863]
Pool
: nat-pool-3
Policy
: nat-policy-3
Started
: 2013/07/21 09:56:23
Inside router
: vprn15001
Inside IP address
: 10.2.0.0
------------------------------------------------------------------------------Number of blocks: 1
===============================================================================

To show LSN blocks on the outside routing instance 15002 for the last inside IP within 10.2.0.0/22
prefix, the following command can be used:
show router 15002 nat lsn-blocks inside-ip 10.2.3.255
===============================================================================
Large-Scale NAT blocks for vprn15002
===============================================================================
192.168.3.16 [56944..57783]
Pool
: nat-pool-3
Policy
: nat-policy-3
Started
: 2013/07/21 09:56:23
Inside router
: vprn15001
Inside IP address
: 10.2.3.255
------------------------------------------------------------------------------Number of blocks: 1
===============================================================================

Page 500

Advanced Configuration Guide

Deterministic Large Scale NAT44

Mapping results

Prefix 10.1.0.0/23
According to this configuration, each inside IP address has one deterministic block of
180 ports and can have up to three dynamic blocks (block-limit =4) each of 80 ports,
allowing a maximum of 180+3*80 = 420 flows.

Prefix 10.2.0.0/22
According to this configuration, each inside IP address has one deterministic block of
840 ports, and can have up to one dynamic block (block-limit =2) of 120 ports,
allowing a maximum of 840+120 = 960 flows.

256 Det Port


Blocks Per
Outside IP
0

Inside Range 10.1.0.0/23:


10.1.0.0/24
10.1.1.0/24

192.168.2.1

WK Range

192.168.2.2

WK Range

192.168.2.3

WK Range

192.168.2.4

WK Range

1023

192.168.2.200 WK Range 180 180 180

47,103

180

80

Deterministic Port Ranges

65,535

80

80

80

80

80

Dynamic Port Ranges

al_0341

Figure 95: Case 2 Prefix 10.1.0.0/23 Results

Advanced Configuration Guide

Page 501

Configuration

64 Det Port
Blocks Per
Outside IP
Inside Range 10.2.0.0/22:
10.2.0.0/26
10.2.0.64/26
10.2.0.128/26

10.2.3.192/26

1023

192.168.3.1

WK Range PF Range

192.168.3.2

WK Range PF Range

192.168.3.3

WK Range PF Range

192.168.3.16

WK Range PF Range

4023

192.168.3.200 WK Range PF Range 840 840 840

57,783

840

Deterministic Port Ranges

65,535

120 120 120 120

120 120

Dynamic Port Ranges

al_0342

Figure 96: Case 2 Prefix 10.2.0.0/22 Results

Page 502

Advanced Configuration Guide

Deterministic Large Scale NAT44

Case 3
Configured with:

Mapping overlapping prefixes from different VRFs into the same outside pool.

NAT all traffic.

Inside

Outside
10.5.0.0/20

Deterministic NAT

VPRN-15001

Base Router

nat-pool-4
10.5.0.0/27
VPRN-15002

al_0343

Figure 97: Case 3

The NAT outside pool is configured as follows:


configure router nat
outside
pool "nat-pool-4" nat-group 1 type large-scale create
port-reservation ports 461
port-forwarding-range 4023
subscriber-limit 64
deterministic
port-reservation 500
exit
address-range 192.168.4.1 192.168.4.100 create
exit
no shutdown
exit all

The NAT policy is configured as follows:


configure service nat
nat-policy "nat-policy-4" create
block-limit 4
pool "nat-pool-4" router Base
exit all

The NAT inside prefix is configured as follows:

Advanced Configuration Guide

Page 503

Configuration

configure service vprn 15001 nat


inside
destination-prefix 0.0.0.0/0
deterministic
classic-lsn-max-subscriber-limit 256
prefix 10.5.0.0/20 subscriber-type classic-lsn-sub
nat-policy "nat-policy-4" create
map start 10.5.0.0 end 10.5.15.255 to 192.168.4.1
no shutdown
exit all
configure service vprn 15002 nat
inside
destination-prefix 0.0.0.0/0
deterministic
classic-lsn-max-subscriber-limit 128
prefix 10.5.0.0/27 subscriber-type classic-lsn-sub
nat-policy "nat-policy-4" create
map start 10.5.0.0 end 10.5.0.31 to 192.168.4.65
no shutdown
exit all

Show commands

Prefix 10.5.0.0/20 (VPRN 15001)


Since the subscriber-limit is 64 in this case, the 10.5.0.0/20 prefix will be broken into
64 smaller prefixes each of /26, each will be mapped into a specific outside IP
address.
To show Large Scale NAT (LSN) hosts for the inside routing instance 15001 for the
first /26 prefix and the mapping to which outside IP, the following command can be
used:

show router 15001 nat lsn-hosts inside-ip-prefix 10.5.0.0/26


===============================================================================
Large-Scale NAT hosts for router 15001
===============================================================================
Inside IP
Out-Router
Outside IP
------------------------------------------------------------------------------10.5.0.0
Base
192.168.4.1
10.5.0.1
Base
192.168.4.1
<snip>
10.5.0.63
Base
192.168.4.1
------------------------------------------------------------------------------No. of hosts: 64
===============================================================================

To show Large Scale NAT (LSN) hosts for the inside routing instance 15001 for the last
/26 prefix and mapping to which outside IP, the following command can be used:
show router 15001 nat lsn-hosts inside-ip-prefix 10.5.15.192/26
===============================================================================

Page 504

Advanced Configuration Guide

Deterministic Large Scale NAT44

Large-Scale NAT hosts for router 15001


===============================================================================
Inside IP
Out-Router
Outside IP
------------------------------------------------------------------------------10.5.15.192
Base
192.168.4.64
10.5.15.193
Base
192.168.4.64
<snip>
10.5.15.255
Base
192.168.4.64
------------------------------------------------------------------------------No. of hosts: 64
===============================================================================

To show LSN blocks on the outside routing instance Base for the first inside IP within 10.5.0.0/20
prefix, the following command can be used:
show router nat lsn-blocks inside-ip 10.5.0.0 inside-router 15001
===============================================================================
Large-Scale NAT blocks for Base
===============================================================================
192.168.4.1 [4024..4523]
Pool
: nat-pool-4
Policy
: nat-policy-4
Started
: 2013/07/21 10:18:39
Inside router
: vprn15001
Inside IP address
: 10.5.0.0
------------------------------------------------------------------------------Number of blocks: 1
===============================================================================

To show LSN blocks on the outside routing instance Base for the last inside IP within 10.5.0.0/20
prefix, the following command can be used:
show router nat lsn-blocks inside-ip 10.5.15.255 inside-router 15001
===============================================================================
Large-Scale NAT blocks for Base
===============================================================================
192.168.4.64 [35524..36023]
Pool
: nat-pool-4
Policy
: nat-policy-4
Started
: 2013/07/21 10:18:39
Inside router
: vprn15001
Inside IP address
: 10.5.15.255
------------------------------------------------------------------------------Number of blocks: 1
===============================================================================

Advanced Configuration Guide

Page 505

Configuration

Prefix 10.5.0.0/27 (VPRN 15002)


Since the subscriber-limit is 64 in this case, the 10.5.0.0/27 prefix will be mapped into
one outside IP address.
To show LSN hosts for the inside routing instance 15002 for the 10.5.0.0/27 prefix
and the mapping to which outside IP, the following command can be used:

show router 15002 nat lsn-hosts inside-ip-prefix 10.5.0.0/27


===============================================================================
Large-Scale NAT hosts for router 15002
===============================================================================
Inside IP
Out-Router
Outside IP
------------------------------------------------------------------------------10.5.0.0
Base
192.168.4.65
10.5.0.1
Base
192.168.4.65
<snip>
10.5.0.31
Base
192.168.4.65
------------------------------------------------------------------------------No. of hosts: 32
===============================================================================

To show LSN blocks on the outside routing instance 15002 for the first inside IP within 10.5.0.0/
27 prefix, the following command can be used:
show router nat lsn-blocks inside-ip 10.5.0.0 inside-router 15002
===============================================================================
Large-Scale NAT blocks for Base
===============================================================================
192.168.4.65 [4024..4523]
Pool
: nat-pool-4
Policy
: nat-policy-4
Started
: 2013/07/21 10:19:40
Inside router
: vprn15002
Inside IP address
: 10.5.0.0
------------------------------------------------------------------------------Number of blocks: 1
===============================================================================

To show LSN blocks on the outside routing instance 15002 for the last inside IP within 10.5.0.0/27
prefix, the following command can be used:
show router nat lsn-blocks inside-ip 10.5.0.31 inside-router 15002
===============================================================================
Large-Scale NAT blocks for Base
===============================================================================
192.168.4.65 [19524..20023]
Pool
: nat-pool-4
Policy
: nat-policy-4
Started
: 2013/07/21 10:19:40
Inside router
: vprn15002
Inside IP address
: 10.5.0.31
------------------------------------------------------------------------------Number of blocks: 1
===============================================================================

Page 506

Advanced Configuration Guide

Deterministic Large Scale NAT44

Mapping results

According to this configuration, each inside IP address within VPRN 15001 has one
deterministic block of 500 ports and can have up to three dynamic blocks (block-limit =4)
each of 461 ports, allowing a maximum of 500+3*461 = 1883 flows.

According to this configuration each inside IP address within VPRN 15002 has one
deterministic block of 500 ports and can have up to three dynamic blocks (block-limit =4)
each of 461 ports, allowing a maximum of 500+3*461 = 1383 flows.

For VPRN 15002, since the number of LSN subscribers (32) is less than the number of
deterministic blocks (64), then 32 deterministic blocks will be wasted, specifically 32*500
= 16,000 ports will be wasted which is not good in terms of capacity planning.

64 Det Port
Blocks Per
Outside IP
VPRN 15001
Inside Range 10.5.0.0/20:
10.5.0.0/26
10.5.0.64/26
10.5.0.128/26

1023

192.168.4.1

WK Range PF Range

192.168.4.2

WK Range PF Range

192.168.4.3

WK Range PF Range

192.168.4.64
192.168.4.65

WK Range PF Range
WK Range PF Range

4023

36,023

10.5.15.192/26
VPRN 15002
Inside Range 10.5.0.0/27:
10.5.0.0/27

32 Wasted Det Port Blocks

192.168.4.100 WK Range PF Range 500 500 500

500

Deterministic Port Ranges

461 461 461 461

461 461

Dynamic Port Ranges

al_0344

Figure 98: Case 3 Results

Advanced Configuration Guide

Page 507

Configuration

Inverse Mapping
In deterministic LSN44, the inside IP addresses are mapped to outside IP addresses and
corresponding port-blocks based on deterministic algorithm. The inverse mapping that reveals the
subscriber identity behind the NAT is based on the reversal of this algorithm.
Inverse mappings can be done either online or offline:

Online Locally on the 7x50 node, via CLI (MIB)

Offline Externally, via a Python Script. The purpose of such an offline approach is to
provide fast queries without accessing the 7x50.

Offline Approach
7x50
CLI
(MIB)

Python
Script
ftp/tftp

External Server
(with Python Installed)

Online Approach
al_0345

Figure 99: Inverse Mapping Approach

Page 508

Advanced Configuration Guide

Deterministic Large Scale NAT44

Online Approach
A tools command is available which shows the reverse mapping (outside to inside) for
deterministic NAT instead of using logging.
tools dump nat deterministic-mapping outside-ip <ipv4-address> router <router-instance>
outside-port <[1..65535]>
<ipv4-address>
<router-instance>

: a.b.c.d
: <router-name>|<service-id>
router-name
- "Base"
service-id
- [1..2147483647]

Using Case 3 as an example:


To obtain (inside IP, inside routing instance) the inverse mapping for a specific (outside IP, outside
routing instance, outside port) is done as follows:
tools dump nat deterministic-mapping outside-ip 192.168.4.1 router "Base" outside-port
4024
classic-lsn-sub inside router 15001 ip 10.5.0.0 -- outside router Base ip 192.168.4.1 port
4024 at Sun Jul 21 10:32:44 UTC 2013

tools dump nat deterministic-mapping outside-ip 192.168.4.65 router "Base" outside-port


4024
classic-lsn-sub inside router 15002 ip 10.5.0.0 -- outside router Base ip 192.168.4.65
port 4024 at Sun Jul 21 10:33:38 UTC 2013

Advanced Configuration Guide

Page 509

Configuration

Offline Approach
The purpose of such an offline approach is to provide fast queries without the need to directly
query the 7x50.
This is achieved by generating and exporting a Python script for reverse querying, which is a
manual operation that needs to be repeated every time there is configuration change in
deterministic NAT.
The script is exported (manually) to the external system.
To configure remote the location for the Python script the following command is used:
configure service nat deterministic-script location <remote-url>

remote-url A remote location where the script is stored:


[{ftp://|tftp://}<login>:<pswd>@ <remote-locn>/][<file-path>]
Maximum length is 180 characters.
Once the script location is specified, the script can be exported to that location using the following
command:
admin nat save-deterministic-script

Using the following command the status of the script can be checked, and whether it is necessary
to re-save (export) the script or not:
show service nat deterministic-script
===============================================================================
Deterministic NAT script data
===============================================================================
Location
: ftp://*:*@10.10.10.10/pub/python/deterministicnat.py
Save needed
: no
Last save result
: success
Last save time
: 2013/07/21 10:35:36
===============================================================================

The external system must have Python scripting language installed with the following modules:
getopt, math, os, socket, and sys.
The Python script can then be run on the external server; the parameters are as follows:
user@external-server$./deterministic-nat.py
Usage: deterministic-nat.py {{DIRECTION PARAMS} | -h[elp] }
where DIRECTION := { -f[orward] | -b[ackward] }
where PARAMS := { -s[ervice] -a[ddress] -p[ort] }

Page 510

Advanced Configuration Guide

Deterministic Large Scale NAT44

where deterministic-nat.py is the name of the python script previously exported.


Example usage:
A forward query
user@external-server$./deterministic-nat.py -f -s 15001 -a 10.0.0.1
classic-lsn-sub has public ip address 192.168.0.1 from service 0 and is using ports [4324
- 4623]

A reverse query
user@external-server$./deterministic-nat.py -b -s 0 -a 192.168.0.1 -p 4325
classic-lsn-sub has private ip address 10.0.0.1 from service 15001

Advanced Configuration Guide

Page 511

Configuration

Simultaneous Support of Deterministic and Non-Deterministic


NAT
Deterministic NAT can be used simultaneously with non-deterministic NAT within the same
inside routing instance. However, they cannot share the same pool.
An outside pool can be only deterministic (although expandable by dynamic ports blocks) or nondeterministic at any given time (a non-deterministic pool is a pool that contains dynamic portblocks only).
The following show a configuration using deterministic NAT simultaneously with nondeterministic NAT.
The NAT outside pools are configured as follows:
configure router nat
outside
pool "nat-pool-1" nat-group 1 type large-scale create
port-reservation ports 180
port-forwarding-range 4023
subscriber-limit 128
deterministic
port-reservation 300
exit
address-range 192.168.0.1 192.168.0.100 create
exit
no shutdown
exit
pool "nat-pool-Non-Deterministic" nat-group 1
type large-scale create
address-range 192.168.7.1 192.168.7.100 create
exit
no shutdown
exit all

The NAT policies are configured as follows:


configure service nat
nat-policy "nat-policy-1" create
block-limit 4
pool "nat-pool-1" router Base
exit
nat-policy "nat-policy-Non-Deterministic" create
pool "nat-pool-Non-Deterministic" router Base
exit all

Page 512

Advanced Configuration Guide

Deterministic Large Scale NAT44

The NAT inside prefixes are configured as follows:


configure service vprn 15001
nat
inside
destination-prefix 0.0.0.0/0
deterministic
classic-lsn-max-subscriber-limit 128
prefix 10.0.0.0/24 subscriber-type classic-lsn-sub
nat-policy "nat-policy-1" create
map start 10.0.0.0 end 10.0.0.255 to 192.168.0.1
no shutdown
exit
exit
nat-policy "nat-policy-Non-Deterministic"
exit all

In this example, the inside IP prefixes that do not match any of the deterministic prefixes will be
NATed using a non-deterministic pool.

192.0.2.1

BNG-1

500 UDP Flows


SRC-IP: 10.7.0.1
3/2/1
SRC-Port: 1024-1523

al_0339

Figure 100: Sending flows: Det + non-Det NAT

To check which NAT pool/NAT policy is used for NATing the inside IP 10.7.0.1, the following
command can be used:
show router nat lsn-blocks inside-ip 10.7.0.1
===============================================================================
Large-Scale NAT blocks for Base
===============================================================================
192.168.7.50 [1024..1527]
Pool
: nat-pool-Non-Deterministic
Policy
: nat-policy-Non-Deterministic
Started
: 2013/07/21 10:59:59
Inside router
: vprn15001
Inside IP address
: 10.7.0.1
------------------------------------------------------------------------------Number of blocks: 1
===============================================================================

Advanced Configuration Guide

Page 513

Conclusion

Conclusion
This example provides the commands required for configuring deterministic LSN44 NAT. Both
deterministic as well as non-deterministic NAT are supported, with simultaneous operation being
possible.
Inverse query can be done online or offline to retrieve the NAT mappings. Logging is not needed
as long as there are no dynamic blocks assigned to LSN44 subscriber.

Page 514

Advanced Configuration Guide

Distributed CPU Protection

In This Chapter
This section describes Distributed CPU Protection (DCP) configurations.
Topics in this section include:

Applicability on page 516

Overview on page 517

Configuration on page 518

Conclusion on page 540

Advanced Configuration Guide

Page 515

Applicability

Applicability
This Distributed CPU Protection (DCP) configuration example was created using the 7750 SRc12 platform but is equally applicable to the following platforms: 7750 SR-7/12, 7450 ESS-6/7/
12, 7750 SR-c4/c12 and 7950 XRS. DCP is not supported on the 7750 SR-1, 7450 ESS-1 or 7710
SR platforms.
DCP operates on the line cards and requires line cards with the FP2 or greater hardware (for
example, IOM3-XP, IMMs and C-XMAs).
The configuration was tested on release 11.0R1.

Page 516

Advanced Configuration Guide

Distributed CPU Protection

Overview
SR OS provides several rate limiting mechanisms to protect the CPM/CFM processing resources
of the router:

CPU Protection: A centralized rate limiting function that operates on the CPM to limit
traffic destined to the CPUs.

Distributed CPU Protection: A control traffic rate limiting protection mechanism for the
CPM/CFM that operates on the line cards (hence distributed). CPU protection protects
the CPU of the node that it is configured on from a DOS attack by limiting the amount of
traffic coming in from one of its ports and destined to the CPM (to be processed by its
CPU) using a combination of the configurable limits.

The goal of this example is to familiarize the reader with the configuration and use of Distributed
CPU Protection. A simple and controlled setup is used to illustrate how the protection behaves
and how to use the tools provided for the feature.
External testing equipment (tester) is used to send control traffic of various protocols at various
rates to the router in order to exercise DCP. Log events and show routines are examined to
explain the indications that the router provides to an operator.

Advanced Configuration Guide

Page 517

Configuration

Configuration
The test topology is shown in Figure 1. A Gigabit Ethernet link is used between the Tester and the
router.

7750 SR-c12
(PE-1)

Port 1/1/4
Interface int-pe1-to-tester

Tester

al_0279

Figure 1: Test Topology

The basic configuration of the mda, port, interface and a security event log on the
router is shown below.

Step 1.

*A:PE-1# configure card 1 mda 1


*A:PE-1>config>card>mda# info
---------------------------------------------mda-type m5-1gb-sfp-b
no shutdown
---------------------------------------------*A:PE-1>config>card>mda# exit all
*A:PE-1# configure port 1/1/4
*A:PE-1>config>port# info
---------------------------------------------ethernet
exit
no shutdown
---------------------------------------------*A:PE-1>config>port# exit all
*A:PE-1# configure router interface "int-pe1-to-tester"
*A:PE-1>config>router>if# info
---------------------------------------------address 192.168.10.1/24
port 1/1/4
no shutdown
---------------------------------------------*A:PE-1>config>router>if# exit all
*A:PE-1# configure log log-id 15
*A:PE-1>config>log>log-id# info
----------------------------------------------

Page 518

Advanced Configuration Guide

Distributed CPU Protection

from security
to memory 1024
----------------------------------------------

This example was developed on a 7750 SR-c12 platform but it is equally applicable to other
platforms such as the 7750 SR-7/12. If other platforms, such as the 7750 SR-7/12 that support
centralized CPU Protection, are used to explore Distributed CPU Protection then the centralized
CPU Protection should be disabled (for the purposes of this example) so that it does not interfere
with reproducing the same results as described below. In a normal production network CPU
Protection and DCP are complimentary and can be used together. To disable centralized CPU
Protection for the purposes of reproducing the results below please ensure that:

protocol-protection is disabled.

All rates in all polices (including any default polices) are configure to max.

Step 2.

In order to activate DCP a policy is created and assigned to the interface.

The first policy that is used in this example is used to simply count protocol packets to see
that they are indeed flowing from the tester to the router and being extracted and
indentified.
The dcp-policy-count policy is configured as follows:
*A:PE-1# configure system security dist-cpu-protection
*A:PE-1>config>sys>security>dist-cpu-protection# info
---------------------------------------------policy "dcp-policy-count" create
description "Static policers with rate 0 for counting packets"
static-policer "sp-arp" create
rate packets 0 within 1
exit
static-policer "sp-icmp" create
rate packets 0 within 1
exit
static-policer "sp-igmp" create
rate packets 0 within 1
exit
protocol arp create
enforcement static "sp-arp"
exit
protocol icmp create
enforcement static "sp-icmp"
exit
protocol igmp create
enforcement static "sp-igmp"
exit
exit

For the dcp-policy-count policy configuration:

Advanced Configuration Guide

Page 519

Configuration

The policy contains three static policers: sp-arp, sp-icmp and sp-igmp. These policers are
then used by the three configured protocols that are part of the policy: arp, icmp and igmp.

The list of protocols that are applicable to DCP are as follows: arp, dhcp, http-redirect,
icmp, igmp, mld, ndis, pppoe-pppoa, all-unspecified, mpls-ttl, bfd-cpm, bgp, eth-cfm, isis,
ldp, ospf, pim and rsvp. The all-unspecified protocol is a special catch-all. Please see
the 7750 SR OS System Management Guide for more details.

This policy instantiates three permanent (static) policers for every object (for example,
interface) that the policy is associated with.

The three protocols each reference their own static policer so each protocol will be
independently rate limited. A single static policer can also be used to rate limit multiple
protocols but that capability is not used in this example.

The rate is set to 0 which means all packets will be considered as non-conformant to the
policer. This configuration is used to provide counters of protocol packets. The DCP
counters provide the count of packets exceeding the policing parameters since the given
policer was previously declared as conformant or newly instantiated. A rate of zero
ensures that the policer will never be declared as conformant and hence will never reset
the counters.

The exceed-action is not configured and takes the default value of none. The log-events
parameter is not configured and is enabled by default. That means the policer will notify
the operator when the first packet arrives but will not discard or mark any packets.

Step 3.

Assign the dcp-policy-count to the interface:

*A:PE-1# configure router interface "int-pe1-to-tester"


*A:PE-1>config>router>if# dist-cpu-protection "dcp-policy-count"

Examine some log and status on the router to get a baseline (no traffic is flowing
from the tester to the router at this point). Notice that the cpu utilization is fairly low with
an overall Idle of 96% and no task groups at more than 5% capacity usage. Future example
output from this show routine will be snipped to only show relevant and interesting lines.

Step 4.

*A:PE-1# show system cpu


===============================================================================
CPU Utilization (Sample period: 1 second)
===============================================================================
Name
CPU Time
CPU Usage
Capacity
(uSec)
Usage
------------------------------------------------------------------------------BFD
0
0.00%
0.00%
BGP
28,779
0.32%
0.47%
BGP PE-CE
0
0.00%
0.00%
CFLOWD
7,384
0.08%
0.38%
Cards & Ports
65,941
0.73%
5.35%
DHCP Server
55
~0.00%
~0.00%
ICC
1,195
0.01%
0.06%
IGMP/MLD
1,883
0.02%
0.12%

Page 520

Advanced Configuration Guide

Distributed CPU Protection

IMSI Db Appl
120
~0.00%
~0.00%
IOM
132,522
1.47%
3.11%
IP Stack
7,666
0.08%
0.39%
IS-IS
1,415
0.01%
0.07%
ISA
11,988
0.13%
0.43%
LDP
496
~0.00%
0.04%
Logging
185
~0.00%
0.01%
MBUF
0
0.00%
0.00%
MPLS/RSVP
6,219
0.06%
0.48%
MSCP
0
0.00%
0.00%
MSDP
0
0.00%
0.00%
Management
4,077
0.04%
0.13%
OAM
10,311
0.11%
0.44%
OSPF
661
~0.00%
0.05%
PIM
0
0.00%
0.00%
RIP
0
0.00%
0.00%
RTM/Policies
0
0.00%
0.00%
Redundancy
7,641
0.08%
0.51%
SNMP Daemon
0
0.00%
0.00%
Services
3,965
0.04%
0.09%
Stats
0
0.00%
0.00%
Subscriber Mgmt
7,437
0.08%
0.44%
System
57,081
0.63%
3.49%
Traffic Eng
0
0.00%
0.00%
VRRP
1,918
0.02%
0.09%
WEB Redirect
77
~0.00%
~0.00%
------------------------------------------------------------------------------Total
8,965,427
100.00%
Idle
8,605,657
95.98%
Usage
359,770
4.01%
Busiest Core Utilization
134,481
13.49%
===============================================================================

The DCP feature is reporting no violations for interfaces on card 1.


*A:PE-1# tools dump security dist-cpu-protection violators enforcement interface card 1
===============================================================================
Distributed Cpu Protection Current Interface Enforcer Policer Violators
===============================================================================
Interface
Policer/Protocol
Hld Rem
------------------------------------------------------------------------------------------------------------------------------------------------------------Violators on Slot-1 Fp-1
------------------------------------------------------------------------------------------------------------------------------------------------------------[S]-Static [D]-Dynamic [M]-Monitor
------------------------------------------------------------------------------===============================================================================

There are no security log events.


*A:PE-1# show log log-id 15
===============================================================================
Event Log 15
===============================================================================
Description : (Not Specified)
Memory Log contents [size=1024
next event=1 (not wrapped)]

Advanced Configuration Guide

Page 521

Configuration

The detailed DCP status for the interface shows all three policers are currently in the conform
state.
*A:PE-1# show router interface "int-pe1-to-tester" dist-cpu-protection
===============================================================================
Interface "int-pe1-to-tester" (Router: Base)
===============================================================================
Distributed CPU Protection Policy : dcp-policy-count
------------------------------------------------------------------------------Statistics/Policer-State Information
===============================================================================
------------------------------------------------------------------------------Static Policer
------------------------------------------------------------------------------Policer-Name
: sp-arp
Card/FP
: 1/1
Policer-State
: Conform
Protocols Mapped
: arp
Exceed-Count
: 0
Detec. Time Remain : 0 seconds
Hold-Down Remain.
: none
Policer-Name
Card/FP
Protocols Mapped
Exceed-Count
Detec. Time Remain

:
:
:
:
:

sp-icmp
1/1
icmp
0
0 seconds

Policer-State

: Conform

Hold-Down Remain.

: none

Policer-Name
: sp-igmp
Card/FP
: 1/1
Policer-State
: Conform
Protocols Mapped
: igmp
Exceed-Count
: 0
Detec. Time Remain : 0 seconds
Hold-Down Remain.
: none
------------------------------------------------------------------------------------------------------------------------------------------------------------Local-Monitoring Policer
------------------------------------------------------------------------------No entries found
------------------------------------------------------------------------------------------------------------------------------------------------------------Dynamic-Policer (Protocol)
------------------------------------------------------------------------------No entries found
------------------------------------------------------------------------------===============================================================================

Page 522

Advanced Configuration Guide

Distributed CPU Protection

Configure the tester to send ARP, ICMP and IGMP traffic to the router using the
following rates:

Step 5.

ARP: 2 packets per second (pps)

ICMP: 4 pps

IGMP: 8 pps

Here are some tips for how to configure the tester to send protocol packets that will be recognized
by the router:

ARP:
Set the MAC destination address to FF-FF-FF-FF-FF-FF
Use an ARP Request format

ICMP:
Use an icmp type of 8 (echo request, such as ping).
Set the MAC destination address equal to the MAC address of the receiving port. The
MAC address of port 1/1/4 can be seen in the output of show port 1/1/4 as the
Configured Address.
Set the IP destination address to 192.168.10.1 and the IP source address to
192.168.10.2.

IGMP:
Set the MAC destination address equal to the MAC address of the receiving port. The
MAC address of port 1/1/4 can be seen in the output of show port 1/1/4 as the
Configured Address.
Set the IP destination address to 224.0.0.2 and the IP source address to 0.0.0.0.
Set the IGMP version to 2, make the IGMP message type a Membership Query to
Group 0.

Also ensure that the tester interleaves the three streams of protocol packets such that it schedules
them independently in an interleaved fashion, not serially.

Advanced Configuration Guide

Page 523

Configuration

7750 SR-c12
(PE-1)

$53
,&03

&RQILJXUHG
5DWH SSV

,*03

Tester
Tester Sending:
SSV$53
SSV,&03
SSV,*03

al_0280

Figure 2: Count Traffic with DCP Policy Count

Step 6.

Notice that DCP now reports some violations of the policy against the interface.

*A:PE-1# tools dump security dist-cpu-protection violators enforcement interface card 1


===============================================================================
Distributed Cpu Protection Current Interface Enforcer Policer Violators
===============================================================================
Interface
Policer/Protocol
Hld Rem
------------------------------------------------------------------------------------------------------------------------------------------------------------Violators on Slot-1 Fp-1
------------------------------------------------------------------------------int-pe1-to-tester
sp-arp
[S] none
int-pe1-to-tester
sp-icmp
[S] none
int-pe1-to-tester
sp-igmp
[S] none
------------------------------------------------------------------------------[S]-Static [D]-Dynamic [M]-Monitor
------------------------------------------------------------------------------===============================================================================

After a few seconds the DCP exceed-count values can be seen incrementing.
Note the following details:

Page 524

Exceed-Count is non-zero. This will continue incrementing and will never reset since the
rate configured in the DCP policy is zero.

The Policer-State is Exceed. The policers have detected that the protocol is nonconformant to the configured rate.

Detec. Time Remain stays at 29 seconds. This countdown timer is automatically reset to
30 seconds every time a policer is detected as non-conformant (which will be continually
when the rate is set to 0 and packets of that protocol are being received).

Advanced Configuration Guide

Distributed CPU Protection

*A:PE-1# show router interface "int-pe1-to-tester" dist-cpu-protection


===============================================================================
Interface "int-pe1-to-tester" (Router: Base)
===============================================================================
Distributed CPU Protection Policy : dcp-policy-count
------------------------------------------------------------------------------Statistics/Policer-State Information
===============================================================================
------------------------------------------------------------------------------Static Policer
------------------------------------------------------------------------------Policer-Name
: sp-arp
Card/FP
: 1/1
Policer-State
: Exceed
Protocols Mapped
: arp
Exceed-Count
: 72
Detec. Time Remain : 29 seconds
Hold-Down Remain.
: none
Policer-Name
Card/FP
Protocols Mapped
Exceed-Count
Detec. Time Remain

:
:
:
:
:

sp-icmp
1/1
icmp
144
29 seconds

Policer-State

: Exceed

Hold-Down Remain.

: none

Policer-Name
: sp-igmp
Card/FP
: 1/1
Policer-State
: Exceed
Protocols Mapped
: igmp
Exceed-Count
: 290
Detec. Time Remain : 29 seconds
Hold-Down Remain.
: none
------------------------------------------------------------------------------[snip]

Step 7.

Keep the tester running.

Now a DCP policy that enforces protocol rates using static policers will be applied to the
interface. First, the policy is created:
*A:PE-1# configure system security dist-cpu-protection
*A:PE-1>config>sys>security>dist-cpu-protection# policy "dcp-static-policy-1" create
description "Static policers for arp, icmp and igmp"
static-policer "sp-arp" create
rate packets 10 within 1
exceed-action discard
exit
static-policer "sp-icmp" create
rate packets 20 within 1
exceed-action discard
exit
static-policer "sp-igmp" create
rate packets 10 within 1
exceed-action discard
exit
protocol arp create
enforcement static "sp-arp"
exit
protocol icmp create
enforcement static "sp-icmp"
exit
protocol igmp create

Advanced Configuration Guide

Page 525

Configuration

enforcement static "sp-igmp"


exit
exit

For the dcp-static-policy-1 policy configuration, note that a few parameters are different than in
the previously created dcp-policy-count policy:

The rates are set to low (but non-zero) values.

The exceed-action is configured such that packets are dropped once the rate is exceeded.

Now assign the policy to the test interface:


*A:PE-1# configure router interface "int-pe1-to-tester"
*A:PE-1>config>router>if# dist-cpu-protection "dcp-static-policy-1"
*A:PE-1>config>router>if# exit all
*A:PE-1# show system security dist-cpu-protection policy "dcp-static-policy-1" association
===============================================================================
Distributed CPU Protection Policy
===============================================================================
Policy Name : dcp-static-policy-1
Description : Static policers for arp, icmp and igmp
------------------------------------------------------------------------------Associations
------------------------------------------------------------------------------SAP associations
------------------------------------------------------------------------------None
Managed SAP associations
------------------------------------------------------------------------------None
Interface associations
------------------------------------------------------------------------------Router-Name : Base
int-pe1-to-tester
------------------------------------------------------------------------------Number of interfaces : 1
===============================================================================

Page 526

Advanced Configuration Guide

Distributed CPU Protection

Increase the rate of IGMP packets that the tester is sending to 1000pps (keep ARP
and ICMP at 2pps and 4pps).

Step 8.

7750 SR-c12
(PE-1)

$53

5DWH SSV
,&03
,*03

Tester
Tester Sending:
SSV$53
SSV,&03
SSV,*03

5DWH SSV
5DWH SSV

al_0281

Figure 3: Limit Traffic with dcp-static-policy-1

Notice that the system has identified a violation of the DCP rates for the igmp
policer.

Step 9.

*A:PE-1# tools dump security dist-cpu-protection violators enforcement interface card 1


===============================================================================
Distributed Cpu Protection Current Interface Enforcer Policer Violators
===============================================================================
Interface
Policer/Protocol
Hld Rem
------------------------------------------------------------------------------------------------------------------------------------------------------------Violators on Slot-1 Fp-1
------------------------------------------------------------------------------int-pe1-to-tester
sp-igmp
[S] none
------------------------------------------------------------------------------[S]-Static [D]-Dynamic [M]-Monitor
------------------------------------------------------------------------------===============================================================================

After a few minutes the violation will be indicated as a log event. This delay is due to the design of
DCP. In order to support large scale operation of DCP, and also to avoid overload conditions, a
polling process is used to monitor state changes in the policers and to gather violations. This
means there can be a delay between when an event occurs in the data plane and when the relevant
state change or event notification occurs towards an operator, but in the meantime the policers are
still operating and protecting the control plane.
*A:PE-1# show log log-id 15
===============================================================================
Event Log 15
===============================================================================
Description : (Not Specified)

Advanced Configuration Guide

Page 527

Configuration

Memory Log contents

[size=1024

next event=11

(not wrapped)]

10 2013/04/18 17:31:54.58 EDT WARNING: SECURITY #2066 Base DCPUPROT


"Non conformant network_if "int-pe1-to-tester" on fp 1/1 detected at 04/18/2013 17:31:33.
Policy "dcp-static-policy-1". Policer="sp-igmp"(static). Excd count=135"
[snip]

The status of DCP on the interface also shows the igmp policer as being in an Exceed state:
*A:PE-1# show router interface "int-pe1-to-tester" dist-cpu-protection
===============================================================================
Interface "int-pe1-to-tester" (Router: Base)
===============================================================================
Distributed CPU Protection Policy : dcp-static-policy-1
------------------------------------------------------------------------------Statistics/Policer-State Information
===============================================================================
------------------------------------------------------------------------------Static Policer
------------------------------------------------------------------------------Policer-Name
: sp-arp
Card/FP
: 1/1
Policer-State
: Conform
Protocols Mapped
: arp
Exceed-Count
: 0
Detec. Time Remain : 0 seconds
Hold-Down Remain.
: none
Policer-Name
Card/FP
Protocols Mapped
Exceed-Count
Detec. Time Remain

:
:
:
:
:

sp-icmp
1/1
icmp
0
0 seconds

Policer-State

: Conform

Hold-Down Remain.

: none

Policer-Name
: sp-igmp
Card/FP
: 1/1
Policer-State
: Exceed
Protocols Mapped
: igmp
Exceed-Count
: 19031
Detec. Time Remain : 29 seconds
Hold-Down Remain.
: none
------------------------------------------------------------------------------[snip]

The CPU utilization of the IGMP task group is not impacted since DCP is discarding packets that
are non-conformant to the configure rate.
*A:PE-1# show system cpu
===============================================================================
CPU Utilization (Sample period: 1 second)
===============================================================================
Name
CPU Time
CPU Usage
Capacity
(uSec)
Usage
------------------------------------------------------------------------------BFD
0
0.00%
0.00%
[snip]
IGMP/MLD
1,883
0.02%
0.12%
IMSI Db Appl
120
~0.00%
~0.00%
IOM
132,522
1.47%
3.11%
IP Stack
7,666
0.08%
0.39%

Page 528

Advanced Configuration Guide

Distributed CPU Protection

IS-IS
1,415
0.01%
0.07%
ISA
11,988
0.13%
0.43%
LDP
496
~0.00%
0.04%
[snip]
WEB Redirect
77
~0.00%
~0.00%
------------------------------------------------------------------------------Total
8,965,427
100.00%
Idle
8,605,657
95.98%
Usage
359,770
4.01%
Busiest Core Utilization
134,481
13.49%
===============================================================================

Step 10. Remove the DCP policy from the interface and see the CPU utilization goes up for

the IGMP task group.


*A:PE-1# configure router interface "int-pe1-to-tester"
*A:PE-1>config>router>if# no dist-cpu-protection
*A:PE-1>config>router>if# /show system cpu
===============================================================================
CPU Utilization (Sample period: 1 second)
===============================================================================
Name
CPU Time
CPU Usage
Capacity
(uSec)
Usage
------------------------------------------------------------------------------BFD
0
0.00%
0.00%
[snip]
IGMP/MLD
82,142
0.91%
8.14%
IMSI Db Appl
98
~0.00%
~0.00%
IOM
129,851
1.45%
3.15%
IP Stack
196,549
2.19%
19.35%
IS-IS
1,484
0.01%
0.07%
ISA
11,765
0.13%
0.42%
LDP
449
~0.00%
0.04%
[snip]
WEB Redirect
102
~0.00%
0.01%
------------------------------------------------------------------------------Total
8,948,806
100.00%
Idle
8,259,903
92.30%
Usage
688,903
7.69%
Busiest Core Utilization
210,435
21.16%
===============================================================================

Step 11. Increase the rate of IGMP traffic from the tester to 5000 pps. See the CPU

utilization increase further.


*A:PE-1# show system cpu
===============================================================================
CPU Utilization (Sample period: 1 second)
===============================================================================
Name
CPU Time
CPU Usage
Capacity
(uSec)
Usage
------------------------------------------------------------------------------BFD
0
0.00%
0.00%
[snip]
IGMP/MLD
417,124
4.65%
41.78%
IMSI Db Appl
82
~0.00%
~0.00%
IOM
133,029
1.48%
2.92%

Advanced Configuration Guide

Page 529

Configuration

IP Stack
935,491
10.43%
93.45%
IS-IS
1,343
0.01%
0.06%
ISA
12,350
0.13%
0.45%
LDP
394
~0.00%
0.03%
[snip]
WEB Redirect
116
~0.00%
0.01%
------------------------------------------------------------------------------Total
8,966,128
100.00%
Idle
6,972,962
77.77%
Usage
1,993,166
22.22%
Busiest Core Utilization
484,748
48.65%
===============================================================================

Step 12. Reinstall the DCP policy to the interface and see the CPU utilization drop.
*A:PE-1# configure router interface "int-pe1-to-tester"
*A:PE-1>config>router>if# dist-cpu-protection "dcp-static-policy-1"
*A:PE-1>config>router>if# exit all
*A:PE-1# show system cpu
===============================================================================
CPU Utilization (Sample period: 1 second)
===============================================================================
Name
CPU Time
CPU Usage
Capacity
(uSec)
Usage
------------------------------------------------------------------------------BFD
0
0.00%
0.00%
[snip]
IGMP/MLD
2,058
0.02%
0.10%
IMSI Db Appl
48
~0.00%
~0.00%
IOM
135,148
1.50%
3.04%
IP Stack
7,851
0.08%
0.47%
IS-IS
1,398
0.01%
0.07%
ISA
11,730
0.13%
0.43%
LDP
299
~0.00%
0.02%
[snip]
WEB Redirect
71
~0.00%
~0.00%
------------------------------------------------------------------------------Total
8,975,262
100.00%
Idle
8,611,593
95.94%
Usage
363,669
4.05%
Busiest Core Utilization
136,669
13.70%
===============================================================================

Step 13. Stop the tester from sending packets, wait a few minutes and then note the status of

the system.
There are no longer any violations of any enforcement policers on any interfaces on card 1.
*A:PE-1# tools dump security dist-cpu-protection violators enforcement interface card 1
===============================================================================
Distributed Cpu Protection Current Interface Enforcer Policer Violators
===============================================================================
Interface
Policer/Protocol
Hld Rem
------------------------------------------------------------------------------------------------------------------------------------------------------------Violators on Slot-1 Fp-1

Page 530

Advanced Configuration Guide

Distributed CPU Protection

------------------------------------------------------------------------------------------------------------------------------------------------------------[S]-Static [D]-Dynamic [M]-Monitor


------------------------------------------------------------------------------===============================================================================

The IGMP policer is indicated as conformant in the log events.


*A:PE-1# show log log-id 15
===============================================================================
Event Log 15
===============================================================================
Description : (Not Specified)
Memory Log contents [size=1024
next event=7 (not wrapped)]
[snip]
12 2013/04/18 17:42:12.43 EDT WARNING: SECURITY #2072 Base DCPUPROT
"Network_if "int-pe1-to-tester" on fp 1/1 newly conformant at 04/18/2013 17:41:57:27. Policy "dcp-static-policy-1". Policer="sp-igmp"(static). Excd count=316418"
[snip]

The interface DCP details show all policers as conformant.


*A:PE-1# show router interface "int-pe1-to-tester" dist-cpu-protection
===============================================================================
Interface "int-pe1-to-tester" (Router: Base)
===============================================================================
Distributed CPU Protection Policy : dcp-static-policy-1
------------------------------------------------------------------------------Statistics/Policer-State Information
===============================================================================
------------------------------------------------------------------------------Static Policer
------------------------------------------------------------------------------Policer-Name
: sp-arp
Card/FP
: 1/1
Policer-State
: Conform
Protocols Mapped
: arp
Exceed-Count
: 0
Detec. Time Remain : 0 seconds
Hold-Down Remain.
: none
Policer-Name
Card/FP
Protocols Mapped
Exceed-Count
Detec. Time Remain

:
:
:
:
:

sp-icmp
1/1
icmp
0
0 seconds

Policer-State

: Conform

Hold-Down Remain.

: none

Policer-Name
: sp-igmp
Card/FP
: 1/1
Policer-State
: Conform
Protocols Mapped
: igmp
Exceed-Count
: 0
Detec. Time Remain : 0 seconds
Hold-Down Remain.
: none
------------------------------------------------------------------------------[snip]

Advanced Configuration Guide

Page 531

Configuration

An optional hold-down can be used in the configuration of the exceed-action of the policers in
order to apply the exceed-action for a defined period (even if the policer goes conformant again
during that period). The hold-down could be used, for example, to discard all packets associated
with a policer for one hour after a violation is detected. An indefinite period is also supported
which enforces discard or marking until the operator clears the policer with the tools perform
security dist-cpu-protection release-hold-down command.
Step 14. The next scenario explored in this example is the use of DCP dynamic enforcement.

In order to use dynamic enforcement policers, a number of dynamic policers must be allocated to
the DCP pool for the particular card being used.
*A:PE-1# configure card 1 fp dist-cpu-protection
*A:PE-1>config>card>fp>d-cpu-prot# info
---------------------------------------------dynamic-enforcement-policer-pool 1000
----------------------------------------------

The number allocated should be greater than the maximum number of dynamic policers expected
to be in use on the card at one time. A conservative (large) number could be selected at first, and
then the following show command can give data to help tune the pool to a smaller size over time:
*A:PE-1# show card 1 fp 1 dist-cpu-protection
===============================================================================
Card : 1 Forwarding Plane(FP) : 1
===============================================================================
Dynamic Enforcement Policer Pool : 1000
------------------------------------------------------------------------------------------------------------------------------------------------------------Statistics Information
------------------------------------------------------------------------------Dynamic-Policers Currently In Use
: 0
Hi-WaterMark Hit Count
: 0
Hi-WaterMark Hit Time
: 04/20/2013 08:16:24 UTC
Dynamic-Policers Allocation Fail Count : 0
------------------------------------------------------------------------------===============================================================================

If the dynamic-enforcement-policer-pool is too small then when a local-monitoring-policer detects


violating traffic, the dynamic enforcement policers will not be able to be instantiated. A log event
will warn the operator when the pool is nearly exhausted.
A sample dynamic enforcement policy is created as follows:
*A:PE-1# configure system security dist-cpu-protection
*A:PE-1>config>sys>security>dist-cpu-protection# policy "dcp-dynamic-policy-1" create
description "Dynamic policing policy"
local-monitoring-policer "local-mon" create
description "Monitor for arp, icmp, igmp
and all-unspecified"
rate packets 100 within 10
exit

Page 532

Advanced Configuration Guide

Distributed CPU Protection

protocol arp create


enforcement dynamic "local-mon"
dynamic-parameters
rate packets 20 within 10
exceed-action discard
exit
exit
protocol icmp create
enforcement dynamic "local-mon"
dynamic-parameters
rate packets 20 within 10
exceed-action discard
exit
exit
protocol igmp create
enforcement dynamic "local-mon"
dynamic-parameters
rate packets 20 within 10
exceed-action discard
exit
exit
protocol all-unspecified create
enforcement dynamic "local-mon"
dynamic-parameters
rate packets 100 within 10
exceed-action discard
exit
exit

Advanced Configuration Guide

Page 533

Configuration

For the dcp-dynamic-policy-1 policy configuration:

The policy contains no static policers. Per-protocol enforcement policers will be


instantiated dynamically but only if triggered by a violation of the local-monitoringpolicer.

A local-monitoring-policer is configured for the policy. The configured rate determines


the rate of arriving protocol packets at which the policy will trigger the automatic
instantiation of dynamic per-protocol policers for the interface.

Four protocols are configured and they are all associated with the local-monitoringpolicer. The all-unspecified protocol will include all other extracted control packets on the
interface.

Each protocol has its own configured dynamic rates that will be used by the dynamic
enforcement policers if they are instantiated. Note these rates are lower than previous
scenarios (the within parameter is 10 seconds instead of 1 second).

When this DCP policy is associated with an interface, only a single policer (the localmonitoring-policer) will be instantiated (statically/permanently). The per-protocol
dynamic policers are only instantiated when there is a violation of the local-monitoringpolicer.

The policy is then associated with the interface:


*A:PE-1# configure router interface "int-pe1-to-tester"
*A:PE-1>config>router>if# dist-cpu-protection "dcp-dynamic-policy-1"

Step 15. Configure the tester to send:

Page 534

1pps of ARP

4pps of ICMP

1000pps of IGMP

Advanced Configuration Guide

Distributed CPU Protection

Start the tester.


7750 SR-c12
(PE-1)
ARP

Rate = 100
Packets within
10 Seconds

ICMP
IGMP

Tester

All-unspecified

al_0282

Figure 4: Dynamic Policing Local Monitor

In Figure 4, the dynamic policers have not been instantiated yet.


Step 16. The local-monitoring-policer will become non-conforming since the aggregate

arrival rate of arp+icmp+igmp+all-unspecified packets is greater than the configured localmonitoring-policer rate of 100 packets within 10 seconds. Dynamic enforcement policers
will then be instantiated.

7750 SR-c12
(PE-1)

Tester

ARP

Tester Sending:
SSV$53
SSV,&03
SSV,*03

ICMP
IGMP
All-unspecified

Rate = 20
Packets within
10 Seconds
Rate = 100
Packets within
10 Seconds
al_0283

Figure 5: Dynamic Policers Instantiated

Advanced Configuration Guide

Page 535

Configuration

The ICMP and IGMP dynamic policers will see violations since their dynamic rates are being
exceeded.
*A:PE-1# tools dump security dist-cpu-protection violators enforcement interface card 1
===============================================================================
Distributed Cpu Protection Current Interface Enforcer Policer Violators
===============================================================================
Interface
Policer/Protocol
Hld Rem
------------------------------------------------------------------------------------------------------------------------------------------------------------Violators on Slot-1 Fp-1
------------------------------------------------------------------------------int-pe1-to-tester
icmp
[D] none
int-pe1-to-tester
igmp
[D] none
------------------------------------------------------------------------------[S]-Static [D]-Dynamic [M]-Monitor
------------------------------------------------------------------------------===============================================================================

The arp and all-unspecified dynamic policers were instantiated but will be counting down their
detection time (if this show command is issued within 30 seconds of the attack starting).
*A:PE-1# show router interface "int-pe1-to-tester" dist-cpu-protection
===============================================================================
Interface "int-pe1-to-tester" (Router: Base)
===============================================================================
Distributed CPU Protection Policy : dcp-dynamic-policy-1
------------------------------------------------------------------------------Statistics/Policer-State Information
===============================================================================
------------------------------------------------------------------------------Static Policer
------------------------------------------------------------------------------No entries found
------------------------------------------------------------------------------------------------------------------------------------------------------------Local-Monitoring Policer
------------------------------------------------------------------------------Policer-Name
: local-mon
Card/FP
: 1/1
Policer-State
: Exceed
Protocols Mapped
: arp, icmp, igmp, all-unspecified
Exceed-Count
: 1097
All Dyn-Plcr Alloc. : True
------------------------------------------------------------------------------------------------------------------------------------------------------------Dynamic-Policer (Protocol)
------------------------------------------------------------------------------Protocol(Dyn-Plcr) : arp
Card/FP
: 1/1
Protocol-State
: Conform
Exceed-Count
: 0
Detec. Time Remain : 5 seconds
Hold-Down Remain.
: none
Dyn-Policer Alloc. : True
Protocol(Dyn-Plcr)
Card/FP
Exceed-Count

Page 536

: icmp
: 1/1
: 31

Protocol-State

: Exceed

Advanced Configuration Guide

Distributed CPU Protection

Detec. Time Remain


Dyn-Policer Alloc.

: 28 seconds
: True

Protocol(Dyn-Plcr)
Card/FP
Exceed-Count
Detec. Time Remain
Dyn-Policer Alloc.

:
:
:
:
:

igmp
1/1
23867
29 seconds
True

Hold-Down Remain.

: none

Protocol-State

: Exceed

Hold-Down Remain.

: none

Protocol(Dyn-Plcr) : all-unspecified
Card/FP
: 1/1
Protocol-State
: Conform
Exceed-Count
: 0
Detec. Time Remain : 5 seconds
Hold-Down Remain.
: none
Dyn-Policer Alloc. : True
------------------------------------------------------------------------------===============================================================================

After 30 seconds have passed, the Detec. Time Remain for arp and all-unspecified will simply
read 0 (zero).
After a few minutes the log events will be collected indicating a non-conformance was seen.
*A:PE-1# show log log-id 15
===============================================================================
Event Log 15
===============================================================================
Description : (Not Specified)
Memory Log contents [size=1024
next event=3 (not wrapped)]
2 2013/04/20 08:56:59.37 EDT WARNING: SECURITY #2067 Base DCPUPROT
"Non conformant network_if "int-pe1-to-tester" on fp 1/1 detected at 04/20/2013 08:52:28.
Policy "dcp-dynamic-policy-1". Policer="icmp"(dynamic). Excd count=2"
1 2013/04/20 08:56:59.37 EDT WARNING: SECURITY #2067 Base DCPUPROT
"Non conformant network_if "int-pe1-to-tester" on fp 1/1 detected at 04/20/2013 08:52:22.
Policy "dcp-dynamic-policy-1". Policer="igmp"(dynamic). Excd count=27"

Step 17. Stop the tester.

The dynamic policer detection timers will start counting down since they are no longer
seeing violating packets.
*A:PE-1# show router interface "int-pe1-to-tester" dist-cpu-protection
===============================================================================
Interface "int-pe1-to-tester" (Router: Base)
===============================================================================
Distributed CPU Protection Policy : dcp-dynamic-policy-1
------------------------------------------------------------------------------Statistics/Policer-State Information
===============================================================================
------------------------------------------------------------------------------Static Policer
------------------------------------------------------------------------------No entries found
-------------------------------------------------------------------------------------------------------------------------------------------------------------

Advanced Configuration Guide

Page 537

Configuration

Local-Monitoring Policer
------------------------------------------------------------------------------Policer-Name
: local-mon
Card/FP
: 1/1
Policer-State
: Exceed
Protocols Mapped
: arp, icmp, igmp, all-unspecified
Exceed-Count
: 1097
All Dyn-Plcr Alloc. : True
------------------------------------------------------------------------------------------------------------------------------------------------------------Dynamic-Policer (Protocol)
------------------------------------------------------------------------------Protocol(Dyn-Plcr) : arp
Card/FP
: 1/1
Protocol-State
: Conform
Exceed-Count
: 0
Detec. Time Remain : 0 seconds
Hold-Down Remain.
: none
Dyn-Policer Alloc. : True
Protocol(Dyn-Plcr)
Card/FP
Exceed-Count
Detec. Time Remain
Dyn-Policer Alloc.

:
:
:
:
:

icmp
1/1
511
14 seconds
True

Protocol(Dyn-Plcr)
Card/FP
Exceed-Count
Detec. Time Remain
Dyn-Policer Alloc.

:
:
:
:
:

igmp
1/1
345550
18 seconds
True

Protocol-State

: Exceed

Hold-Down Remain.

: none

Protocol-State

: Exceed

Hold-Down Remain.

: none

Protocol(Dyn-Plcr) : all-unspecified
Card/FP
: 1/1
Protocol-State
: Conform
Exceed-Count
: 0
Detec. Time Remain : 0 seconds
Hold-Down Remain.
: none
Dyn-Policer Alloc. : True
------------------------------------------------------------------------------===============================================================================

After 30 seconds there are no more violators.


*A:PE-1# tools dump security dist-cpu-protection violators enforcement interface card 1
===============================================================================
Distributed Cpu Protection Current Interface Enforcer Policer Violators
===============================================================================
Interface
Policer/Protocol
Hld Rem
------------------------------------------------------------------------------------------------------------------------------------------------------------Violators on Slot-1 Fp-1
------------------------------------------------------------------------------------------------------------------------------------------------------------[S]-Static [D]-Dynamic [M]-Monitor
------------------------------------------------------------------------------===============================================================================

Page 538

Advanced Configuration Guide

Distributed CPU Protection

The dynamic policer pool Hi-WaterMark for card 1 fp 1 shows 4 since the highest number of
dynamic policers allocated at any one time on the card/fp was 4.
*A:PE-1# show card 1 fp 1 dist-cpu-protection
===============================================================================
Card : 1 Forwarding Plane(FP) : 1
===============================================================================
Dynamic Enforcement Policer Pool : 1000
------------------------------------------------------------------------------------------------------------------------------------------------------------Statistics Information
------------------------------------------------------------------------------Dynamic-Policers Currently In Use
: 0
Hi-WaterMark Hit Count
: 4
Hi-WaterMark Hit Time
: 04/20/2013 08:52:22 UTC
Dynamic-Policers Allocation Fail Count : 0
------------------------------------------------------------------------------===============================================================================

A few minutes later the log events indicate that the flood has ended.
*A:PE-1# show log log-id 15
===============================================================================
Event Log 15
===============================================================================
Description : (Not Specified)
Memory Log contents [size=1024
next event=5 (not wrapped)]
4 2013/04/20 09:01:59.39 EDT WARNING: SECURITY #2073 Base DCPUPROT
"Network_if "int-pe1-to-tester" on fp 1/1 newly conformant at 04/20/2013 08:58:39. Policy
"dcp-dynamic-policy-1". Policer="igmp"(dynamic). Excd count=345550"
3 2013/04/20 09:01:59.39 EDT WARNING: SECURITY #2073 Base DCPUPROT
"Network_if "int-pe1-to-tester" on fp 1/1 newly conformant at 04/20/2013 08:58:35. Policy
"dcp-dynamic-policy-1". Policer="icmp"(dynamic). Excd count=511"

Advanced Configuration Guide

Page 539

Conclusion

Conclusion
Distributed CPU Protection (DCP) offers a powerful rate limiting function for control protocol
traffic that is extracted from the data path and sent to the CPM.
This example has demonstrated how to configure DCP on an interface and what indications SR
OS provides to the operator during a potential attack or misconfiguration.
DCP can also be deployed in scenarios where per-SAP-per-protocol rate limiting is useful, such as
for subscriber management in a subscriber per-vlan scenario. A DCP policy can be assigned to an
MSAP policy on a Broadband Network Gateway, for example, to limit traffic related to certain
protocols and to discard certain protocols. When deployed in a subscriber management scenario,
DCP can help isolate SAPs (subscribers) from each other and even isolate protocols from each
other within an individual SAP (subscriber). Many of the same concepts introduced in this
example are applicable when DCP is deployed in a subscriber management application.

Page 540

Advanced Configuration Guide

ESMv4: PPPoE Hosts

In This Chapter
This section describes advanced IPv4 Enhanced Subscriber Management (ESM) PPPoE host
configurations.
Topics in this section include:

Applicability on page 542

Summary on page 543

Overview on page 544

Configuration on page 557

Conclusion on page 590

Advanced Configuration Guide

Page 541

Applicability

Applicability
This note is applicable for 7750 SR-C12, SR-7/12 and 7710 on IOM2 and higher and was tested
on release 7.0R5 and describes support of PPP termination and aggregation (PTA) hosts. L2TPhosts are out of scope. Routed CO is supported on 7450 ESS-7 or ESS-12 in mixed-mode since
8.0R1.
This note is related only to the use of IPv4 hosts.
PPPoE has been supported since Release 6.0.
The 7750 SR-c4 is supported from 8.0R4 and higher.
PPPoE hosts are only supported in a Routed CO model (IES or VPRN) using Ethernet SAPs with
null, dot1q or QinQ encapsulation.
PPPoE hosts are also supported in external loop/VSM if there is Layer 2 aggregation.

Page 542

Advanced Configuration Guide

ESMv4: PPPoE Hosts

Summary
The delivery of services to residential customers encompassing voice, video and data is covered
by Alcatel-Lucents Triple Play Service Delivery Architecture (TPSDA).
In the TPSDA, a subscriber is defined as a collection of hosts pertaining to a single access
connection (for example, DSL line) and identified by a subscriber identifier. A subscriber host is
an end user terminal within the subscriber home (PC, set-top box, home gateway) that is identified
in the network with a unique (IP address/MAC address) tuple for IPoE or (PPPoE session ID;
MAC address) tuple for PPPoE.
The following host types are distinguished:
Static hosts

ip-mac

ip-only

Dynamic hosts

ARP-host

DHCP-host

PPPoE-host

This section provides configuration and troubleshooting commands for PPPoE-hosts and will use
a local user database (LUDB) for host authentication and ESM (Enhanced Subscriber
Management) string assignments.
The IP information in this note is retrieved from a Local DHCP server.
The authentication, IP information and ESM strings can come all from a LUDB, a RADIUS
server, a (local) DHCP server, or any combination of them. These combinations are out of scope.
Knowledge of the Alcatel-Lucent TPSDA concept is assumed throughout this document.

Advanced Configuration Guide

Page 543

Overview

Overview
PPPoE Hosts in a Routed CO Environment
The network topology for a Routed CO environment is displayed in Figure 6.

Simulated
Local DHCP server/local DB

ESM
BSAN

BSR-1

OSSG448

Figure 6: Routed CO Network Topology

The following configuration tasks should already be configured and are not detailed or explained
in this section. Refer to the appropriate user guide.

Basic service router configuration (system interface, IGP, MPLS, BGP)

Routed CO service topology: VPRN or IES service with subscriber- and group-interface
on BSR-1

ESM

LUDB (Local User Data Base)

Local (DHCP) Dynamic Host Configuration Protocol) server

This section focuses on PPPoE hosts instantiated in a VPRN service subscriber-interface on BSR1 (Routed CO). Note that in case of Routed CO, it is also possible to instantiate the PPPoE hosts in
the Base routing instance using an IES service.

Page 544

Advanced Configuration Guide

ESMv4: PPPoE Hosts

Review of the PPPoE Protocol


PPPoE, Point-to-Point Protocol over Ethernet, is a network protocol for encapsulating PPP frames
inside Ethernet frames. The protocol is described as an informational RFC 2516, A Method for
Transmitting PPP Over Ethernet (PPPoE), and is based on RFC 1661, The Point-to-Point
Protocol (PPP),which provides a standard method for transporting multi-protocol data-grams over
point-to-point links.
PPP includes three main components:

A method for encapsulating multi-protocol datagrams.

A link control protocol (LCP) for establishing, configuring, and testing the data-link
connection.

A family of network control protocols (NCP) for establishing and configuring different
network-layer protocols.

Ethernet networks are packet-based and have no concept of a connection or circuit. By using
PPPoE, users can virtually dial from one machine to another over an Ethernet network; establish a
point to point connection between them and then transport data packets over the connection.
In a typical wire-line solution with broadband access, PPPoE is used between a client (PC or
modem) and a Network Access Server (NAS) (also called Broadband Network Gateway (BNG) or
Broadband Service Router (BSR)) through an access node, like a Broadband Service Access Node
(BSAN).
PPPoE consists of two phases, the Discovery Stage and the Session Stage.

Discovery Stage
The discovery phase offers a stateless client-server model. When the Discovery Stage completes,
both peers know the PPPoE SESSION_ID and the peer's Ethernet address, which together
uniquely define the PPPoE session. There are four steps in the Discovery Stage:
Step 1. PPPoE Active Discovery Initiation (PADI)

Initiation (Host broadcast) This broadcast packet is used by the client to search for an
active server (BNG/BSR/NAS) providing access to a service.
Note: Additional attributes on the PADI message could be added if a BSAN is situated
between the client and the BRAS.
Step 2. PPPoE Active Discovery Offer (PADO)

Access concentrator unicast If the access server can provide the service it will respond with
a unicast PADO to signal the client it may request connectivity.

Advanced Configuration Guide

Page 545

Overview

Multiple servers may respond and the client may choose a server to connect.
Step 3. PPPoE Active Discovery Request (PADR):

Host unicast After the client receives a PADO it will send a PADR unicast packet to
connect to a server.
Step 4. PPPoE Active Discovery Session-Confirmation (PADS)

Access concentrator unicast A server will respond to the client with this unicast packet to
establish the session and provide the session-id. Once the PADS was provided the Session
Stage begins.
Note: Discovery PPPoE Ethernet frames have the ETHER_TYPE field set to the value
0x8863.

Page 546

Advanced Configuration Guide

ESMv4: PPPoE Hosts

PPPoE Tags
IANA has set up a registry of PPPoE tag values (16-bit values). PPPoE tag values already in use
are specified as reserved values as shown in Table 1. All other tag values between 0 and 65535 are
to be assigned by IANA
Table 1: Reserved PPPoE Tags
Tag Value

0x0000

Tag Name

End-Of-List

257 0x0101

Service-Name

258 0x0102

AC-Name

259 0x0103

Host-Uniq

260 0x0104

AC-Cookie

261 0x0105

Vendor-Specific

262 0x0106

Credits

263 0x0107

Metrics

264 0x0108

Sequence Number

272 0x0110

Relay-Session-Id

273 0x0111

HURL

274 0x0112

MOTM

288 0x0120

PPP-Max-Payload

289 0x0121

IP_Route_Add

513 0x0201

Service-Name-Error

514 0x0202

AC-System-Error

515 0x0203

Generic-Error

Explanations for some PPPoE tags (RFC 2516) are shown in the PPPoE discovery debugs
messages.
0x0101 Service-Names This tag indicates that a service name follows. The tag_value is an
UTF-8 string that is not null terminated. When the tag_length is zero this tag is used to indicate
that any service is acceptable. Examples of the use of the service-name tag are to indicate an ISP
name or a class or quality of service.
(0x0102) AC-Names This tag indicates that a string follows which uniquely identifies this
particular Access Concentrator unit from all others. It may be a combination of trademark, model,

Advanced Configuration Guide

Page 547

Overview

and serial id information, or simply an UTF-8 rendition of the MAC address of the box. It is not
null terminated.
(0x0103) Host-Uniq This tag is used by a host to uniquely associate an access concentrator
response (PADO or PADS) to a particular host request (PADI or PADR). The tag_value is binary
data of any value and length that the host chooses. It is not interpreted by the Access Concentrator.
The host may include a host-uniq tag in a PADI or PADR. If the access concentrator receives this
tag, it must include the tag unmodified in the associated PADO or PADS response.
(0x0104) AC-Cookie This tag is used by the access concentrator to aid in protecting against
denial of service attacks. The access concentrator may include this tag in a PADO packet.
If a host receives this tag, it must return the tag unmodified in the following PADR. The tag_value
is binary data of any value and length and is not interpreted by the host.

Simulated
Local DHCP Server/Local DB

ESM
BSAN

PADI, Session ID: 0x0000


PPPoE tag: option: 0x101, 0x103

Discovery Stage

PADO, Session ID: 0x0000


PPPoE tag: option: 0x101, 0x102, 0x103, 0x104

BSR-1

PPPoE enabled under froup


interface with ludb-1

PADR, Session ID: 0x0000


PPPoE tag: option; 0x101, 0x102, 0x103, 0x104
PADS, Session ID: 0x0001
PPPoE tag: option: 0x101, 0x102, 0x103

Figure 7: Discovery Stage Messages

Page 548

Advanced Configuration Guide

ESMv4: PPPoE Hosts

Session Stage
This next stage after Discovery is called the Session Stage. Once the MAC address of the peer is
known and a session-id is exchanged, the two end points have all the information needed to start
building a point-to-point connection over Ethernet and exchange packets over the connection.
This stage can be divided into to the following sections:

Setup on page 549

Maintenance on page 555

Termination on page 556

Setup
PPP Link Control Protocol (LCP)
Both the NAS and the user open the PPP session based on LCP packets. All post-discovery PPPoE
Ethernet frames have the ETHER_TYPE field set to the value 0x8864.
Authentication method and the MRU are negotiated during this phase.
RFC 2516 mandates a maximum negotiated Maximum Receive Unit (MRU) of 1492.
RFC 4638, Accommodating a Maximum Transit Unit/Maximum Receive Unit (MTU/MRU)
Greater Than 1492 in the Point-to-Point Protocol over Ethernet (PPPoE), relaxes this restriction
and allows a maximum negotiated MRU greater than 1492 to minimize fragmentation in nextgeneration broadband networks.
The 7750 implementation follows RFC 4638 when the client implements these extensions.
LCP uses config_request and config_ack/nack to negotiate parameters:

LCP goes to final state opened when configure-ack is send & received.

The own options are proposed in configure request.

Advanced Configuration Guide

Page 549

Overview

There are three cases for the LCP negations parameters:

Peer supports the options and his content.


Peer will agree and send config-ack.

Peer does not support an option


Peer will send configure-reject with the option that is not supported.
Resend of configure-request without that option.
Peer agrees and sends config-ack.

Peer does support the option but not the content.


Peer will send config-nack with the option and his new content.
Resend of configure-request with same options but new content.
Peer agrees and sends config-ack.

Table 2: LCP and IPCP Code


Code

Page 550

Packet Type

Configure-Request

Configure-Ack

Configure-Nak

Configure-Reject

Terminate-Request

Terminate-Ack

Code-Reject

Protocol-Reject

Echo-Request

10

Echo-Reply

11

Discard-Request

12

Identification

13

Time-Remaining

14

Reset-request CCP

15

Reset-Ack

CCP

Advanced Configuration Guide

ESMv4: PPPoE Hosts

Simulated
Local DHCP Server/Local DB

ESM
BSAN

BSR-1

PADI, Session ID: 0x0000


PPPoE tag: option: 0x101, 0x103

Discovery Stage

PADO, Session ID: 0x0000


PPPoE tag: option: 0x101, 0x102, 0x103, 0x104

pppoe Enabled Under Group


Interface With ludb-1

PADR, Session ID: 0x0000


PPPoE tag: option; 0x101, 0x103
PADS, Session ID: 0x0000
PPPoE tag: option: 0x101, 0x102, 0x103

Figure 8: LCP Phase Messages

Advanced Configuration Guide

Page 551

Overview

Authentication Phase
The client authenticates itself through PAP (PPP Password Authentication Protocol) or CHAP
(Challenge Handshake Authentication Protocol) to check for access permission.For the CHAP
authentication, the BSR initiates the authentication as shown in Figure 9.
Note: The password as a hashed output on the link and plain text in a RADIUS Access-Request
message.

Simulated

Local DHCP server/local DB

ESM
BSAN
Random-y
user-psw
sid x
MDS

Hash
User-name
Sid x

BSR-1

(1) Challange
Name BSR
sid x
Random-y

Name BSR
Session id x
Random-y
(2) Response

(3) Success

Hash
User-name
Sid x

Lookup
User-name

user-psw
Random-y
sid x

(4) Failure
MDS

Hash = ? Hash
OSSG454

Figure 9: CHAP Handshaking Overview Process

Page 552

Advanced Configuration Guide

ESMv4: PPPoE Hosts

For PAP the client initiates the authentication as shown in Figure 10.
Note: The password is sent as plain text on the link and hashed in a RADIUS Access-Request
message.

Simulated

Local DHCP server/local DB

ESM
BSAN
peer-id: name user
password: user-psw

BSR-1

(1) Auth-request
name user
user-psw

Check in the database


name user = name user
user psw = user psw

(2) Auth-ack login ok


(3) Auth-nack login incorrect
OSSG455

Figure 10: PAP Overview Process

Advanced Configuration Guide

Page 553

Overview

Network-Layer Protocol Phase (PPP IPCP Opening Phase)


At this stage the user requests an IP address to be used for data transmission. During this
negotiation the client will also receive a Domain Name Server (DNS), NBNS (Netbios Name
Server) address, etc. if they are requested.

Simulated

Local DHCP server/local DB

ESM
BSAN

BSR-1

IPCP Configure-request, Session ID: 0x0001, ID=198 [3]


IP address: 10.2.0.254
IPCP Configure-request, Session ID: 0x0001, ID=1 [3]
IP address: 0.0.0.0

Session
Stage:
IPCP

IPCP Configure-ack, Session ID: 0x0001, ID=106 [3]


IP address: 10.2.0.254
IPCP Configure-nack, Session ID: 0x0001, ID=1 [3]
IP address: 10.2.0.82
IPCP Configure-request, Session ID: 0x0001, ID=2 [3]
IP address: 10.2.0.82
IPCP Configure-ack, Session ID: 0x0001, ID=2 [3]
IP address: 10.2.0.82
OSSG456

Figure 11: IPCP Phase Messages

Page 554

Advanced Configuration Guide

ESMv4: PPPoE Hosts

Maintenance
PPP uses keepalives in order to maintain the integrity of the connection. This keepalive
mechanism uses an echo-request that is sent to remote PPP peer, following which the remote PPP
peer should respond with an echo-reply. The connection is considered down if x-numbers of echoreply are missed. Both sides can initiate keepalives which run independently.

Simulated

Local DHCP server/local DB

ESM
BSAN

BSR-1

Link Control Protocol, Echo-request,


Session ID:0x001 Value
Link Control Protocol, Echo-request,
Session ID:0x001 Value

Session
Keepalive

Link Control Protocol, Echo-reply,


Session ID:0x001 Value
Link Control Protocol, Echo-reply,
Session ID:0x001 Value
OSSG457

Figure 12: Keepalive Messages

Advanced Configuration Guide

Page 555

Overview

Termination
Link Termination Phase
A PPPoE session can be terminated by either the client or by the BRAS and consists of a
Terminate-request followed by a PADT.

Simulated

Local DHCP server/local DB

ESM
BSAN

BSR-1

Terminate-request, Session ID: 0x001 Value

Termination
Link Termination
Phase

Terminate-ack, Session ID: 0x001 Value


PADT, Session ID: 0x001 Value
PADT, Session ID: 0x001 Value
OSSG458

Figure 13: Link Termination Phase

Page 556

Advanced Configuration Guide

ESMv4: PPPoE Hosts

Configuration
PPPoE Host Session: Set-Up, Operation and Release
Enable PPPoE termination under the group-interface context.
Enable the local user database under the PPPoE node of the group-interface.
B:BSR-1# configure service vprn 1
subscriber-interface "sub-int-1" create
address 10.2.0.254/16
group-interface "group-int-1" create
sap 1/1/3:1 create
sub-sla-mgmt
sub-ident-policy "sub-id-default"
no shutdown
exit
exit
pppoe
user-db "ludb-1"
no shutdown
exit
exit
exit
no shutdown

The local user database is configured with the following parameters.


*A:BSR-1>config>subscr-mgmt# info
---------------------------------------------local-user-db "ludb-1" create
pppoe
match-list username
host "user1" create
host-identification
username "user1@domain1"
exit
address pool "pool-1"
password chap "KG35KPbV/9zoZpmco.h0nXFfa0QqZdsT" hash2
identification-strings 254 create
subscriber-id "PPPoE-host-user1@domain1"
sla-profile-string "sla-profile-1"
sub-profile-string "sub-profile-1"
exit
no shutdown
exit

Advanced Configuration Guide

Page 557

Configuration

A local DHCP server will be used as a source for the IP addressing of the PPPoE host.
*A:BSR-1>config>service>vprn# info
---------------------------------------------dhcp
local-dhcp-server "server-1" create
use-gi-address
pool "pool-1" create
subnet 10.2.0.0/16 create
exclude-addresses 10.2.0.254 10.2.0.255
address-range 10.2.0.1 10.2.0.253
exit
exit
no shutdown
exit
exit

The PPPoE policy configuration.

A:BSR-1# configure subscriber-mgmt pppoe-policy "pppoe-policy-1" create


*A:BSR-1>config>subscr-mgmt>pppoe-policy$ info detail
---------------------------------------------no description
no disable-cookies
keepalive 30 hold-up-multiplier 3
no pado-delay
no ppp-initial-delay
no ppp-mtu
max-sessions-per-mac 1
no reply-on-padt
ppp-authentication pref-chap
ppp-chap-challenge-length min 32 max 64
ppp-options
exit

The PPPoE policy defines the parameters which are used in the establishment of the PPPoE
session such as:

Disable-cookies This parameter disables the use of cookies.

Keepalive This command defines the keepalive interval and the number of keepalives
that can be missed before the session is declared down for this PPPoE policy.
[10 300] seconds: Specifies the keepalive interval in seconds.
hold-up-multiplier [1 5]: Specifies the number of keepalives that can be missed.

PADO-delay This parameter configures the delay timeout before sending a PPPoE
Active Discovery Offer (PADO) packet.
[1 30] deciseconds

PPP-mtu This parameter configures the maximum PPP MTU size.


[512 9212]: possible values for MTU size.

Page 558

Advanced Configuration Guide

ESMv4: PPPoE Hosts

Max-sessions-per-mac This parameter sets the maximum PPPoE sessions that can be
opened for the given MAC address.
[1 63]: possible PPPoE sessions per MAC address.

Reply-on-PADT Some of the PPPoE clients expect reply on PPPoE Active Discovery
Terminate (PADT) message before the context of the session is cleared up. To support
such client, a command enabling reply to PADT is provided.
[Default] no reply-on-padt

PPP-options This parameter enables the context to configure PPP options which is not
supported by default

These parameters will be explained later in details according to its existence in which PPPoE
phase.
Notes:

The default policy cannot be modified nor deleted.

Multiple PPPoE policies may be configured.

* The PPPoE policy is defined within the PPPoE context under the group interface.
*A:BSR-1>config>service>vprn# info
------------------------------------------------snip--subscriber-interface "sub-int-1" create
address 10.2.0.254/16
group-interface "group-int-1" create
--snip--pppoe
pppoe-policy "pppoe-policy-1"
---snip---

Troubleshooting the PPPoE discovery messages (PADI, PADO, PADR, PADS and PADT) is done
with PPPoE debugging:
*A:BSR-1# debug service id 1 pppoe packet discovery ?
- discovery [padi] [pado] [padr] [pads] [padt]
- no discovery
<padi>
<pado>
<padr>
<pads>
<padt>

Advanced Configuration Guide

:
:
:
:
:

keyword
keyword
keyword
keyword
keyword

debug
debug
debug
debug
debug

PADI
PADO
PADR
PADS
PADT

packets
packets
packets
packets
packets

Page 559

Configuration

For example:
*A:BSR-1# show debug
debug
service
id 1
pppoe
packet
mode egr-ingr-and-dropped
detail-level medium
discovery
ppp
dhcp-client
exit

To display the debugging information, a dedicated log should be created:


*A:BSR-1# configure log
log-id 1
from debug-trace
to session
exit

Page 560

Advanced Configuration Guide

ESMv4: PPPoE Hosts

Discovery Stage
The following is an example of PPPoE (PADI discovery packet) debug log output:
"PPPoE: RX Packet
VPRN 1, SAP 1/1/3:1
DMAC: ff:ff:ff:ff:ff:ff
SMAC: 00:00:67:14:01:02
Ether Type: 0x8863 (Discovery)
PPPoE Header:
Version: 1
Type
: 1
Code
: 0x09 (PADI)
Session-Id: 0x0000 (0)
Length : 65
PPPoE Tags:
[0x0101] Service-Name: "AGILENT"
[0x0103] Host-Uniq: len = 4, value = 00 14 00 00
[0x0105] Vendor-Specific: vendor-id = 0x0de9 (ADSL Forum)
[0x01] Agent-Circuit-Id: "circuit10"
[0x02] Agent-Remote-Id: "remote10"
[0x81] Actual-Upstream: 64
[0x82] Actual-Downstream: 64
[0x90] Access-Loop-Encap: 01 01 00

PPPoE Policy Parameters


Service name The client can ask a particular service. Empty means that any service is
acceptable. The service name can indicate an ISP name, class, QoS.
PPPoE: RX Packet
VPRN 1, SAP 1/1/3:1
DMAC: ff:ff:ff:ff:ff:ff
SMAC: 00:00:67:14:01:02
Ether Type: 0x8863 (Discovery)
PPPoE Header:
Version: 1
Code
: 0x09 (PADI)
Length : 65

Type
: 1
Session-Id: 0x0000 (0)

PPPoE Tags:
[0x0101] Service-Name: "AGILENT"

Advanced Configuration Guide

Page 561

Configuration

The BSR echoes the service name from the PADI message. Empty means that any service is
acceptable.
112 2010/01/07 17:29:32.07 UTC MINOR: DEBUG #2001 vprn1 PPPoE
"PPPoE: TX Packet
VPRN 1, SAP 1/1/3:1
DMAC: 00:00:67:14:01:02
SMAC: 00:03:fa:90:f8:6a
Ether Type: 0x8863 (Discovery)
PPPoE Header:
Version: 1
Code
: 0x07 (PADO)
Length : 48

Type
: 1
Session-Id: 0x0000 (0)

PPPoE Tags:
[0x0101] Service-Name: "AGILENT"

Host-Uniq The host can include a unique tag of any length inserted In PADI or PADR.The AC
should echo back this tag in the PADO or PADS.
"PPPoE: RX Packet
VPRN 1, SAP 1/1/3:1
DMAC: ff:ff:ff:ff:ff:ff
SMAC: 00:00:67:14:01:02
Ether Type: 0x8863 (Discovery)
PPPoE Header:
Version: 1
Type
: 1
Code
: 0x09 (PADI)
Session-Id: 0x0000 (0)
Length : 65
PPPoE Tags:
[0x0101] Service-Name: "AGILENT"
[0x0103] Host-Uniq: len = 4, value = 00 14 00 00

The following parameters can optionally be added to the PADI by the PPPoE intermediate agent
(BSAN):
Vendor-specific information

Page 562

Agent-Circuit-Id

Agent-Remote-Id

Access-loop-Encapsulation

Access loop characteristics (actual-upstream, actual-downstream)

Advanced Configuration Guide

ESMv4: PPPoE Hosts

The debug output:


111 2010/01/07 17:29:32.07 UTC MINOR: DEBUG #2001 vprn1 PPPoE
"PPPoE: RX Packet
VPRN 1, SAP 1/1/3:1
DMAC: ff:ff:ff:ff:ff:ff
SMAC: 00:00:67:14:01:02
Ether Type: 0x8863 (Discovery)
PPPoE Header:
Version: 1
Code
: 0x09 (PADI)
Length : 53

Type
: 1
Session-Id: 0x0000 (0)

PPPoE Tags:
[0x0101] Service-Name: "AGILENT"
[0x0103] Host-Uniq: len = 4, value = 00 14 00 00
[0x0105] Vendor-Specific: vendor-id = 0x0de9 (ADSL Forum)
[0x01] Agent-Circuit-Id: "circuit10"
[0x02] Agent-Remote-Id: "remote10"
[0x81] Actual-Upstream: 64
[0x82] Actual-Downstream: 64
[0x90] Access-Loop-Encap: 01 01 00

The cookies can be displayed in the PADO message. This tag of any value and length may be
included by the AC and is echoed back by the client to the AC in the next PADR .
112 2010/01/07 17:29:32.07 UTC MINOR: DEBUG #2001 vprn1 PPPoE
"PPPoE: TX Packet
VPRN 1, SAP 1/1/3:1
DMAC: 00:00:67:14:01:02
SMAC: 00:03:fa:90:f8:6a
Ether Type: 0x8863 (Discovery)
PPPoE Header:
Version: 1
Code
: 0x07 (PADO)
Length : 48

Type
: 1
Session-Id: 0x0000 (0)

PPPoE Tags:
[0x0101] Service-Name: "AGILENT"
[0x0102] AC-Name: "BSR-1"
[0x0103] Host-Uniq: len = 4, value = 00 14 00 00
[0x0104] AC-Cookie: len = 16, value = d7 91 cd b7 3e 51 76 d6 03 0a f2 68 8c
da ba 74

Advanced Configuration Guide

Page 563

Configuration

AC-name Identifies the string that uniquely identifies the access concentrator (AC).

112 2010/01/07 17:29:32.07 UTC MINOR: DEBUG #2001 vprn1 PPPoE


"PPPoE: TX Packet
VPRN 1, SAP 1/1/3:1
DMAC: 00:00:67:14:01:02
SMAC: 00:03:fa:90:f8:6a
Ether Type: 0x8863 (Discovery)
PPPoE Header:
Version: 1
Code
: 0x07 (PADO)
Length : 48

Type
: 1
Session-Id: 0x0000 (0)

PPPoE Tags:
[0x0101] Service-Name: "AGILENT"
[0x0102] AC-Name: "BSR-1"

When disable-cookies is configured, the use of cookies will be disabled, when omitted the nodisable-cookies will be used.
*A:BSR-1>config>subscr-mgmt>pppoe-policy# info
---------------------------------------------disable-cookies

The cookies are encoded back by the client in the next PADR message.
PPPoE hosts are authenticated based on username-password information (PAP/CHAP
authentication) or on information embedded in the PADI message PADI authentication).
ppp-chap-challenge length

The min and max values for the ppp-chap-challenge are defined when enabling ppp-chapchallenge length. When omitted, a min of 32 and max of 64 are used.
*A:BSR-1# configure subscriber-mgmt pppoe-policy "pppoe-policy-1" ppp-chap-challengelength ?
- ppp-chap-challenge-length min <minimum-length> max <maximum-length>
- no ppp-chap-challenge-length
<minimum-length>
: [8..64]
<maximum-length>
: [8..64]

Page 564

Advanced Configuration Guide

ESMv4: PPPoE Hosts

Local User Database Authentication


With this authentication method, the clients PPPoE session is authenticated locally on the BRAS
without any constraint of an external radius server.
The local user database is configured with the following parameters.
*A:BSR-1>config>subscr-mgmt# info
---------------------------------------------local-user-db "ludb-1" create
pppoe
match-list username
host "user1" create
host-identification
username "user1@domain1"
exit
address pool "pool-1"
password chap "KG35KPbV/9zoZpmco.h0nXFfa0QqZdsT" hash2
identification-strings 254 create
subscriber-id "PPPoE-host-user1@domain1"
sla-profile-string "sla-profile-1"
sub-profile-string "sub-profile-1"
exit
no shutdown
exit

Example: PADI authentication through LUDB.


*A:BSR-1# configure subscriber-mgmt local-user-db "ludb-1" pppoe match-list ?
- no match-list
- match-list <pppoe-match-type-1> [<pppoe-match-type-2>...(up to 3 max)]
<pppoe-match-type>

: circuit-id|mac|remote-id|service-name|username

To complete the discovery phase, the server must provide a session-id to the client and we allocate
always session-id 1 for different MACs.
Note: in VLAN per service model (N: 1 VLAN) where the MACs are the same and the PPPoE
interworking will be done at the BSAN.
*A:BSR-1# show service id 1 pppoe session
===============================================================================
PPPoE sessions for svc-id 1
===============================================================================
Sap Id
Mac Address
Sid Up Time
IP/L2TP-Id
Type
------------------------------------------------------------------------------1/1/3:1
00:00:67:14:01:02 1
0d 23:05:40
10.2.0.46
Local
------------------------------------------------------------------------------Number of sessions : 1

Advanced Configuration Guide

Page 565

Configuration

The 7750 has the possibility to delay the sending of the PADO message to the client. This feature
could be used if the client is dual homed to 2 BSRs? and is explained later in the document.
When PADO-delay is configured, the configured value equals the delay timeout before sending
PADO, when omitted the PADO-delay value of 0 msec will be used.
*A:BSR-1>config>subscr-mgmt>pppoe-policy# pado-delay ?
- no pado-delay
- pado-delay <deci-seconds>
<deci-seconds>

Page 566

: [1..30]

Advanced Configuration Guide

ESMv4: PPPoE Hosts

Session Stage

lcp
During the link establishment phase client and server negotiate options and need to come to an
agreement on these options. Options that are unknown by the peer are rejected whereas known
options with unknown content are nackd. In the later case the peer needs to resend the same
option but with another content. In case of a reject the peer should remove that option. An Ack
will be send if there is a full agreement.
One of the more important options that is exchanged is the maximum receive unit (MRU) and the
authentication protocol that will be used later in the authentication phase. The first option, the
MRU value (minus overhead) is sent from the BSR towards the client and is the lowest value
between the port MTU and the optional configured ppp-mtu in the ppp-policy.
RFC 2516 mandates a maximum negotiated Maximum Receive Unit (MRU) of 1492 but RFC
4638 relaxes this restriction and allows a maximum negotiated MRU greater than 1492 to
minimize fragmentation in next-generation broadband networks. The 7750 SR and 7710 SR
implementation follows RFC 4638 when the client implements these extensions.
If a PPPoE client wants to use MRU>1492 in the LCP-config request it should include the pppmax-payload tag with the higher MTU value in the initial PADI message.
*A:BSR-1# configure subscriber-mgmt pppoe-policy "pppoe-policy-1" ppp-mtu ?
- no ppp-mtu
- ppp-mtu <mtu-bytes>
<mtu-bytes>

: [512..9212]

PPPoE debug output.


134 2010/01/07 21:04:10.30 UTC MINOR: DEBUG #2001 vprn1 PPPoE
"PPPoE: TX Packet
VPRN 1, SAP 1/1/3:1
DMAC: 00:00:67:13:01:02
SMAC: 00:03:fa:90:f8:6a
Ether Type: 0x8864 (Session)
PPPoE Header:
Version: 1
Code
: 0x00
Length : 21

Type
: 1
Session-Id: 0x0001 (1)

PPP:
Protocol : 0xc021 (LCP)
Code
: 1 (Configure-Request)
Identifier: 5
Length

: 19

Options:
[1] MRU: 1492
---snip--

Advanced Configuration Guide

Page 567

Configuration

The second important option, the authentication method used in the authentication phase is
exchanged between client and server and can be PAP or CHAP authentication. The authentication
method is not exchanged when PADI authentication is done. PADI authentication means that the
BSR will authenticate the user based on parameters in the PADI message. Authentication based on
PADI and PAP/CHAP is possible.
Debug output example for CHAP authentication protocol.
137 2010/01/07 21:04:10.30 UTC MINOR: DEBUG #2001 vprn1 PPPoE
"PPPoE: RX Packet
VPRN 1, SAP 1/1/3:1
DMAC: 00:03:fa:90:f8:6a
SMAC: 00:00:67:13:01:02
Ether Type: 0x8864 (Session)
PPPoE Header:
Version: 1
Code
: 0x00
Length : 21

Type
: 1
Session-Id: 0x0001 (1)

PPP:
Protocol : 0xc021 (LCP)
Code
: 2 (Configure-Ack)
Identifier: 5
Length

: 19

Options:
[3] Authentication-Protocol: 0xc223 (CHAP), Algorithm = 5 (MD5)
[5] Magic-Number: 0x60363318

Debug output example for PAP authentication protocol.


46 2010/01/13 10:59:45.71 UTC MINOR: DEBUG #2001 vprn1 PPPoE
"PPPoE: RX Packet
VPRN 1, SAP 1/1/3:1
DMAC: 00:03:fa:90:f8:6a
SMAC: 00:00:67:13:01:02
Ether Type: 0x8864 (Session)
PPPoE Header:
Version: 1
Code
: 0x00
Length : 20

Type
: 1
Session-Id: 0x0001 (1)

PPP:
Protocol : 0xc021 (LCP)
Code
: 2 (Configure-Ack)
Identifier: 160
Length

: 18

Options:
[1] MRU: 1492
[3] Authentication-Protocol: 0xc023 (PAP)
[5] Magic-Number: 0x37df4db2
"

Page 568

Advanced Configuration Guide

ESMv4: PPPoE Hosts

Fallback case chap->pap

For user authentication, with pap-chap-access, always try CHAP first; if that doesn't succeed, try
PAP.
The option to be used first (CHAP/PAP) is defined when enabling the ppp-authentication. When
omitted, CHAP is preferred always.
*A:BSR-1# configure subscriber-mgmt pppoe-policy "pppoe-policy-1" ppp-authentication ?
- no ppp-authentication
- ppp-authentication {pap|chap|pref-chap}
<pap|chap|pref-chap> : keywords

PPPoE clients that implement undocumented options also require an agreement on those unknown
options. By default, the 7750 SR will reject unknown options but the ppp-option feature in the
pppoe-policy allows for support of undocumented client LCP or IPCP options. If the received
LCP or IPCP option matches the configured options in the pppoe-policy an ack will be send
instead of a reject.
*A:BSR-1# configure subscriber-mgmt pppoe-policy "pppoe-policy-1" ppp-options customoption ?
- custom-option <protocol> <option-number> address <ip-address>
- custom-option <protocol> <option-number> hex <hex-string>
- custom-option <protocol> <option-number> string <ascii-string>
- no custom-option <protocol> <option-number>
<protocol>
<option-number>
<ip-address>
<ascii-string>
<hex-string>

:
:
:
:
:

lcp|ipcp
[0..255]
a.b.c.d
[127 chars max]
[0x0..0xFFFFFF...(max 254 hex nibbles)]

Troubleshooting the PPPoE LCP session messages is done with PPPoE debugging:
*A:BSR-1>debug>service>id>pppoe>packet# ppp ?
- no ppp
- ppp [lcp] [pap] [chap] [ipcp]
<lcp>
<pap>
<chap>
<ipcp>

Advanced Configuration Guide

:
:
:
:

keyword
keyword
keyword
keyword

debug
debug
debug
debug

LCP packets
PAP packets
CHAP packets
IPCP packets

Page 569

Configuration

Authentication

The 7750/7710 BSR supports three main methods for PPPoE authentication.

PADI or PAP/CHAP authentication through RADIUS

PADI or PAP/CHAP authentication through a LUDB

PADI authentication via LUDB then PAP/CHAP pre-authentication through RADIUS

DHCP server authentication will not be explained in this section because this is more
authorization than authentication
The flow chart of the PPPoE host authentication process is shown in Figure 14.

Perform LCB
PAP/CHAP
authentication
and append data
Auth-method
= none

IP addr
available?

N
PPPoE
auth-method
pap-chap?

Perform RADIUS
PAP/CHAP
authentication
and append data

N
Perform RADIUS

PPPoE
auth-method
PADI?

N
Perform DHCP
request
and append
data

Y PADI/DISCOVER
authentication
and append data

Sufficient
data
available?

Y
Authplcy
on group
interface?

Request

Matchlist
contains
username?

Append default
ESM strings

LUDB on
group
interface?

Sufficient
data
available?

N
Perform LDB
PADI/DISCOVER
authentication
(and append data
for PPPoE host)

LDB home
entry contains
authplcy?

PADI LUDB New 7.0

N
Y

Instantiate

auth-method
pap-chap configured
in auth plcy?

Drop

Retail
N

Pre-Auth
New 7.0

Drop
OSSG460

Figure 14: Authentication Flow Chart

Page 570

Advanced Configuration Guide

ESMv4: PPPoE Hosts

PPPoE users get authenticated via the LUDB if this LUDB is configured under the groupinterface.

*A:BSR-1>config>service>vprn>sub-if>grp-if>pppoe# info
---------------------------------------------user-db "ludb-1"

Users get authenticated via RADIUS if we have an authentication-policy under the same
group-interface. RADIUS has precedence if both are configured.

*A:BSR-1>config>service>vprn>sub-if>grp-if# info
---------------------------------------------authentication-policy "auth-1"
pppoe
user-db "ludb-1"
exit

Users that get authenticated via the LUDB can still go to RADIUS if we move the
authentication-policy from the group-interface to the LUDB.

A:BSR-1>config>subscr-mgmt>loc-user-db>pppoe>host# info
------------------------------------------------snip--auth-policy "auth-1"
no shutdown

This last mechanism is called pre-authentication and could be used to pick up parameters like
pado-delay or checking some variables such as circuit-id, remote-id from the LUDB during
discovery phase but use RADIUS for PAP/CHAP authentication.
*A:BSR-1>config>subscr-mgmt>loc-user-db>pppoe>host# host-identification ?
[no]
[no]
[no]
[no]
[no]

circuit-id
mac
remote-id
service-name
username

Configure
Configure
Configure
Configure
Configure

the
the
the
the
the

circuit id of this host


MAC address of this host
remote id of this host
service name of this host
user name of this host

Both RADIUS and LUDB support PADI or PAP/CHAP authentication.

PPPoE users that are authenticated through the LUDB and have in the LUDB a match-list
other than username will get authenticated based on PADI parameters like mac, circuitid, remote-id.

*A:BSR-1>config>subscr-mgmt>loc-user-db>pppoe# match-list ?
- no match-list
- match-list <pppoe-match-type-1> [<pppoe-match-type-2>...(up to 3 max)]
<pppoe-match-type>

Advanced Configuration Guide

: circuit-id|mac|remote-id|service-name|username

Page 571

Configuration

PPPoE users that have in the LUDB a match-list equal to username will use the PAP/
CHAP authentication method.

*A:BSR-1>config>subscr-mgmt# info
---------------------------------------------local-user-db "ludb-1" create
pppoe
match-list username
host "user1" create
host-identification
username "user1@domain1"
exit
address pool "pool-1"
password chap "KG35KPbV/9zoZpmco.h0nXFfa0QqZdsT" hash2
---snip---

PPPoE users that are authenticated through RADIUS and have in the authentication
policy, a pppoe-access-method equal to PADI will use the mac or circuit-id information
from the PADI in their request to RADIUS.

*A:BSR-1>config>subscr-mgmt>auth-plcy$ pppoe-access-method ?
- pppoe-access-method {none|padi|pap-chap}
- no pppoe-access-method

The selection for mac or circuit-id can be altered via the parameter user-name-format.

*A:BSR-1>config>subscr-mgmt>auth-plcy$ user-name-format ?
- user-name-format <format> [append domain-name]
- no user-name-format
<format>

: mac|circuit-id|tuple|ascii-converted-circuit-id|
ascii-converted-tuple

PPPoE users that are authenticated through RADIUS and have in the authentication policy a
pppoe-access-method equal to pap-chap use the username from the authentication phase in their
request to RADIUS. The parameter user-name-format is irrelevant in this last case.

Page 572

Advanced Configuration Guide

ESMv4: PPPoE Hosts

RADIUS Authentication
When authentication is provided through RADIUS, two methods can be used to authenticate the
PPPoE session.

PADI authentication

PAP/CHAP authentication

The RADIUS policy specifies what parameters are provided in the RADIUS access-request
message.
The following parameters can be configured:

Circuit-id: Provided through the PADI/PADR PPPoE relay vendor specific tag as
specified in TR-101 of the DSL Forum.

Remote-id: Provided through the PADI/PADR PPPoE relay vendor specific tag as
specified in TR-101 of the DSL Forum.

NAS-port-id: SAP ID on which the PPPoE session terminates (e.g. 1/1/3:1).

NAS-identifier: System name of the NAS or BNG.

PPPoE-service-name: Provided through the PPPoE PADI packet.

access-loop-options: Provided through the PAD/PADR PPPoE extensions as specified in


TR-101 of the DSL Forum.

The option to use PADI authentication or PAP/CHAP authentication is selected with the following
configuration in the RADIUS policy:
*A:BSR>config>subscr-mgmt>auth-plcy# pppoe-access-method ?
- pppoe-access-method {none|padi|pap-chap}
- no pppoe-access-method

When PADI authentication is used for PPPoE termination the MAC address or the PPPoE relay
tag (Circuit-ID) or a combination of MAC address and circuit ID can be used to identify the
subscriber in the RADIUS server.
To determine the iinformation to use in the RADIUS Access-Request message is configured in the
RADIUS policy using the following command:
*A:BSR >config>subscr-mgmt>auth-plcy# user-name-format ?
- user-name-format <format>
- no user-name-format
<format>
tuple

Advanced Configuration Guide

: mac|circuit-id|tuple|ascii-converted-circuit-id|ascii-converted-

Page 573

Configuration

Local User Database Authentication


A second authentication option for PPPoE termination is to use the local user database of the BSR
7750/ 7710 for PAP/CHAP authentication (this option will be used in this note). With this
authentication method the clients PPPoE session is authenticated locally on the BSR without any
constraint of an external radius server.
The local user database is configured with the following parameters:
*A:BSR-1>config>subscr-mgmt# info
---------------------------------------------local-user-db "ludb-1" create
pppoe
match-list username
host "user1" create
host-identification
username "user1@domain1"
exit
address pool "pool-1"
password chap "KG35KPbV/9zoZpmco.h0nXFfa0QqZdsT" hash2
identification-strings 254 create
subscriber-id "PPPoE-host-user1@domain1"
sla-profile-string "sla-profile-1"
sub-profile-string "sub-profile-1"
exit
no shutdown

With this authentication method, authentication can be provided by the username/password.


To enable the local authentication method, the local user database is configured under the PPPoE
node of the group-interface as shown below.
*A:BSR-1>config>service>vprn>sub-if>grp-if# info
------------------------------------------------snip--pppoe
---snip-user-db "ludb-1"
no shutdown

To check LUDB parameters for the PPPoE hosts.


*A:BSR-1# show subscriber-mgmt local-user-db ludb-1 pppoe-host user1
===============================================================================
PPPoE Host "user1"
===============================================================================
Admin State
: Up
---snip--User Name
: user1@domain1
Matched Objects

Page 574

: userName

Advanced Configuration Guide

ESMv4: PPPoE Hosts

Address
:
Password Type
:
---snip--Identification Strings
Subscriber Id
:
SLA Profile String :
Sub Profile String :
---snip--

pool "pool-1"
CHAP
(option 254)
PPPoE-host-user1@domain1
sla-profile-1
sub-profile-1

To debug the LUDB.


*A:BSR-1# debug subscriber-mgmt local-user-db "ludb-1" detail
- detail {all|failed}
- no detail

DHCP Client Authentication


A third authentication method for PPPoE termination is to perform PPPoE to DHCP
transformation (where the 7750 SR acts as a DHCP client on behalf of the PPP session) and to use
a DHCP server for session authentication. This method is useful when a similar authentication is
used for DHCP based clients.
The PPPoE to DHCP authentication method can provide authentication on the basis of MAC
address, circuit ID or remote ID.

ipcp

IP and DNS information can be obtained from different sources like LUDB and RADIUS for fixed
IP addressing or (local) DHCP for dynamic ip-pool management.
DNS and IP-addressing should come from the same source and are ipcp rejected if they are not .
If IP information is returned from a DHCP server. PPPoE options such as the DNS name are
retrieved from the DHCP ACK and provided to the PPPoE client.

Advanced Configuration Guide

Page 575

Configuration

Local DHCP Server


In this note, a local DHCP server will be used as a source for the IP addressing of the PPPoE host.
*A:BSR-1>config>service>vprn# info
---------------------------------------------dhcp
local-dhcp-server "server-1" create
use-gi-address
pool "pool-1" create
subnet 10.2.0.0/16 create
exclude-addresses 10.2.0.254 10.2.0.255
address-range 10.2.0.1 10.2.0.253
exit
exit
no shutdown
exit

To check the DHCP server summary:


*A:BSR-1# show router 1 dhcp local-dhcp-server server-1 summary
===============================================================================
DHCP server server-1 router 1
===============================================================================
Admin State
: inService
Operational State
: inService
---snip--------------------------------------------------------------------------------Pool name : pool-1
------------------------------------------------------------------------------Subnet
Free
Stable
Declined
Offered
Rem-pend
------------------------------------------------------------------------------10.2.0.0/16
252
1
0
0
0
Totals for pool
252
1
0
0
0
------------------------------------------------------------------------------Totals for server

252

------------------------------------------------------------------------------Associations
Admin
------------------------------------------------------------------------------local-dhcp-server-1
Up
===============================================================================
*A:BSR-1#

Page 576

Advanced Configuration Guide

ESMv4: PPPoE Hosts

To debug the DHCP server:


*A:BSR-1# show debug
debug
router "1"
ip
dhcp
detail-level medium
mode egr-ingr-and-dropped
exit

Keepalive

The keepalive timer (defined in seconds) and the hold-up-multiplier are defined when enabling
keepalives. When omitted, a 30 sec keepalvie timer and 3 hold-up-multipliers are used.
*A:BSR-1# configure subscriber-mgmt pppoe-policy "pppoe-policy-1"
- keepalive <seconds> [hold-up-multiplier <multiplier>]
- no keepalive
<seconds>
: [10..300]
<multiplier>
: [1..5]

keepalive ?

[10-300] seconds: interval between LCP Echo Requests


hold-up-multiplier [1-5] : Number of missed replies before the PPPoE session is considered dead.

Advanced Configuration Guide

Page 577

Configuration

To check the keepalive statistics:


*A:BSR-1# show service id 1 pppoe session session-id 1 mac 00:00:67:14:01:02 statistics
===============================================================================
PPPoE sessions for svc-id 1
===============================================================================
Sap Id
Mac Address
Sid Up Time
IP/L2TP-Id
Type
------------------------------------------------------------------------------1/1/3:1
00:00:67:14:01:02 1
0d 04:31:37
10.2.0.37
Local
Packet Type
Received
Transmitted
--------------------------------------------------------------------------------snip-LCP Echo-Request
543
1086
LCP Echo-Reply
1086
543

The 7750/7710 BSR supports an optimised implementation of keepalive mechanism; this is a


mechanism where client and/or server can check the aliveness of the peer. This LCP echo-request
is sent on expiration of a timer, derived from the configured pppoe-policy keepalive value.
An LCP echo reply is returned to the client after a LCP echo request is received and the above
timer on the BSR is reset to the initial keepalive value.
The above mechanism results in an optimised mechanism if the keepalive timers from the client
are smaller than the configured values on the BSR.
The client or BSR will terminate the session with a PADT if no LCP echo-reply is received within
the time specified by the hold-up-multiplier.
Example for Echo Request from BSR and Echo Reply from the PPPoE host.
Ethernet II, Src: TimetraN_90:f8:6a (00:03:fa:90:f8:6a), Dst: Soft*Rit_14:01:02
(00:00:67:14:01:02)
802.1Q Virtual LAN, PRI: 5, CFI: 0, ID: 1
PPP-over-Ethernet Session
Point-to-Point Protocol
PPP Link Control Protocol
Code: Echo Request (0x09)
Identifier: 0x01
Length: 8
Magic number: 0x2e538af6
No.

Time
4 30.000280

Source
TimetraN_90:f8:6a

Destination
Soft*Rit_14:01:02

Protocol Info
PPP LCP Echo Reply

Ethernet II, Src: TimetraN_90:f8:6a (00:03:fa:90:f8:6a), Dst: Soft*Rit_14:01:02


(00:00:67:14:01:02)
802.1Q Virtual LAN, PRI: 5, CFI: 0, ID: 1
PPP-over-Ethernet Session
Point-to-Point Protocol
PPP Link Control Protocol
Code: Echo Reply (0x0a)

Page 578

Advanced Configuration Guide

ESMv4: PPPoE Hosts

Identifier: 0x0b
Length: 8
Magic number: 0x2e538af6

Advanced Configuration Guide

Page 579

Configuration

To check the PPPoE session for a particular service, use the show service id <service-id> pppoe
session command. Detailed output as well as additional output filtering is available:
*A:BSR-1# show service id 1 pppoe session ?
- session [interface <ip-int-name|ip-address> | sap <sap-id>] [type
<pppoe-session-type>] [session-id <session-id>] [mac <ieee-address>]
[ip-address <ip-address[/mask]>] [port <port-id>] [no-inter-dest-id |
inter-dest-id <intermediate-destination-id>] [detail|statistics]
*A:BSR-1# show service id 1 pppoe session detail
===============================================================================
PPPoE sessions for svc-id 1
===============================================================================
Sap Id
Mac Address
Sid Up Time
IP/L2TP-Id
Type
------------------------------------------------------------------------------1/1/3:1
00:00:67:14:01:02 1
0d 04:34:44
10.2.0.37
Local
LCP State
IPCP State
PPP MTU
PPP Auth-Protocol
PPP User-Name

:
:
:
:
:

Opened
Opened
1492
CHAP
user2@domain1

Subscriber-interface : sub-int-1
Group-interface
: group-int-1
Subscriber Origin
Strings Origin
IPCP Info Origin

: Local-User-Db
: Local-User-Db
: DHCP

Subscriber
Sub-Profile-String
SLA-Profile-String
ANCP-String
Int-Dest-Id
App-Profile-String
Category-Map-Name

:
:
:
:
:
:
:

"PPPoE-host-user2@domain1"
"sub-profile-1"
"sla-profile-1"
""
""
""
""

Primary DNS
Secondary DNS
Primary NBNS
Secondary NBNS
Address-Pool

:
:
:
:
:

N/A
N/A
N/A
N/A
"pool-1"

Circuit-Id
Remote-Id
Service-Name

: circuit10
: remote10
: AGILENT

Session-Timeout
: N/A
Radius Class
:
Radius User-Name
:
------------------------------------------------------------------------------Number of sessions : 1

Page 580

Advanced Configuration Guide

ESMv4: PPPoE Hosts

An event will be generated when a PPPoE host has been created in the system.
424 2010/01/07 15:28:37.64 UTC WARNING: SVCMGR #2500 Base Subscriber created
"Subscriber PPPoE-host-user1@domain1 has been created in the system"

The PPPoE host will appear in the subscriber-host table for the service with origin set to PPPoE.
B:BSR-1# show service id 1 subscriber-hosts
===============================================================================
Subscriber Host table
===============================================================================
Sap
IP Address
MAC Address
PPPoE-SID Origin
Subscriber
Fwding state
------------------------------------------------------------------------------1/1/3:1
10.2.0.52
00:00:64:02:01:02 1
PPPoE
PPPoE-host-user1@do*
Fwding
------------------------------------------------------------------------------Number of subscriber hosts : 1

A host route (/32) for its IP address is inserted in the routing table towards the appropriate groupinterface.
*A:BSR-1# show router 1 route-table
===============================================================================
Route Table (Service: 1)
===============================================================================
Dest Prefix
Type
Proto
Age
Pref
Next Hop[Interface Name]
Metric
------------------------------------------------------------------------------10.2.0.0/16
Local
Local
03d06h17m
0
sub-int-1
0
10.2.0.37/32
Remote Sub Mgmt 04h35m43s
0
[group-int-1]
0
13.13.13.0/24
Remote BGP VPN 01d22h40m
170
192.0.2.3
0
172.16.0.1/32
Local
Local
11d00h19m
0
local-dhcp-server-1
0
------------------------------------------------------------------------------No. of Routes: 4
===============================================================================
*A:BSR-1#

Advanced Configuration Guide

Page 581

Configuration

To advertise the PPPoE host subnets to other protocol/network, a policy statement should be
defined with using from protocol direct.
*A:BSR-1>config>router>policy-options# info
---------------------------------------------policy-statement "policy-1"
entry 10
from
protocol direct
---snip---

Terminate

Some of the PPPoE clients expect reply on PADT message before the context of the session is
cleared up. To support such client, a command enabling reply to PADT is configured.
When reply-on-padt is configured, the BSR will reply with PADT message, when omitted no
PADT will be sent from the BSR as a reply on the clients PADT.
*A:BSR-1#configure subscriber-mgmt pppoe-policy "pppoe-policy-1"
reply-on-padt

The pppoe debug output:


77 2010/01/07 20:31:50.32 UTC MINOR: DEBUG #2001 vprn1 PPPoE
"PPPoE: TX Packet
VPRN 1, SAP 1/1/3:1
DMAC: 00:00:67:13:01:02
SMAC: 00:03:fa:90:f8:6a
Ether Type: 0x8863 (Discovery)
PPPoE Header:
Version: 1
Code
: 0xa7 (PADT)
Lengt

Type
: 1
Session-Id: 0x0001 (1)

A PPPoE host can be manually deleted from the system using following clear command:
*A:BSR-1# clear service id 1 pppoe session
- session all [no-padt]
- session interface <ip-int-name|ip-address> [mac <ieee-address> [session-id
<session-id>]] [type <pppoe-session-type>][ip-address <ip-address[/mask]>]
[port <port-id>] [no-inter-dest-id | inter-dest-id
<intermediate-destination-id>] [no-padt]
- session sap-id <sap-id> [mac <ieee-address> [session-id <session-id>]]
[type <pppoe-session-type>] [ip-address <ip-address[/mask]>] [port
<port-id>] [no-inter-dest-id | inter-dest-id
<intermediate-destination-id>] [no-padt]
*A:BSR-1# clear service id 1 pppoe session sap-id 1/1/3:1 mac 00:00:67:14:01:02

Page 582

Advanced Configuration Guide

ESMv4: PPPoE Hosts

Several examples are displayed:

Admin Reset Use the clear command or a RADIUS Disconnect Request.


TERMINATE CAUSE [49] 4 Admin Reset(6)

User Request User disconnects the session.


TERMINATE CAUSE [49] 4 User Request(1)

Accounting OFF
When accounting policy has been removed from sap/interface/sub-profile.
vprn service which is transporting accounting information has been shutdown.
The last RADIUS accounting server has been removed from already applied
accounting policy.
TERMINATE CAUSE [49] 4 NAS Request(10)

PPPoE keepalive timeout


TERMINATE CAUSE [49] 4 Lost Carrier(2)

RADIUS session timeout

Advanced Configuration Guide

Page 583

Configuration

PPPoE Hosts Advanced Topics


QoS Aspects
VLAN based downstream PPPoE control traffic is generated by default with dot1p value 7 .This
value can be overruled with the following commands:
In case of the PPPoE hosts instantiated in the Base routing instance using an IES service.
*B:BSR-1#configure router sgt-qos application pppoe dot1p 5 [0..7]

In case of the PPPoE hosts instantiated in a VPRN service subscriber-interface.


*B:BSR-1#configure service vprn 1 sgt-qos application pppoe dot1p 5

[0..7]

The show router sgt-qos command displays the configured and default DSCP and default dot1p
values per application. Since PPPoE is a Layer 2 protocol we will see only the dot1p settings. The
default dot1p value none corresponds with value 7.
*A:BSR-1# show router 1 sgt-qos application pppoe
===============================================================================
Dot1p Application Values
===============================================================================
Application
Dot1p Value
Default Dot1p Value
------------------------------------------------------------------------------pppoe
7
none
====================================================================
*A:BSR-1#

Page 584

Advanced Configuration Guide

ESMv4: PPPoE Hosts

Limiting the Number of PPPoE Hosts


The maximum number of PPPoE sessions can be controlled by the parameters session-limit, sapsession-limit, host-limit, multi-sub-sap limit and max-sessions-per mac.
session-limit The maximum number of PPPoE sessions for an IES/VPRN group-interface is
defined when enabling session-limit. When omitted, a single PPPoE session is allowed.
B:BSR-1> configure service vprn 1
---snip-group-interface group-int-1
pppoe
session-limit 1
exit

A trap is generated when trying to instantiate a new pppoe session while the configured number of
sessions is reached. Note that the discovery phase is completed before the check on the sessionlimit is performed.
"PPPoE session failure on SAP 1/1/3:1 in service 1 - Reached the interface session limit
(1) for "group-int-1""
PPPoE debug output:
"PPPoE: Dropped Packet
VPRN 1, SAP 1/1/3:1
Problem: Reached the interface session limit (1) for "group-int-1"sap-session-limit
:

The maximum number of pppoe sessions per SAP for an IES/VPRN group-interface is defined
when enabling sap-session-limit. When omitted, a single pppoe session per SAP is allowed:
B:BSR-1> configure service vprn 1
---snip-group-interface group-int-1
pppoe
sap-session-limit 1
exit

A trap is generated when trying to instantiate a new PPPoE session while the configured number
of the sessions per sap is reached.
"PPPoE session failure on SAP 1/1/3:1 in service 1 - Reached the per-SAP session limit
(1) for "group-int-1""

PPPoE debug output:


"PPPoE: Dropped Packet
VPRN 1, SAP 1/1/3:1
Problem: Reached the per-SAP session limit (1) for "group-int-1"

max-sessions-per-mac

Advanced Configuration Guide

Page 585

Configuration

The BSR 7750/7710 implementation defines a unique PPPoE session based on the PPPoE
SESSION_ID and the clients MAC address.
The maximum number of PPPoE sessions per mac is defined when enabling max-sessions-permac. When omitted, a single PPPoE session per mac is allowed.
*B:BSR-1> configure
subscriber-mgmt
pppoe-policy "pppoe-policy-1"
max-sessions-per-mac 63
exit

Although the command is max-session-per-mac, actually it means the maximum number of


supported sessions-per-MAC-per-SAP especially in N: 1 VLAN model.
A trap is generated when trying to instantiate a new PPPoE session per the same mac while the
configured number of max-sessions-per-mac is reached.
"PPPoE session failure on SAP 1/1/3:1 in service 1 - Reached the maximum number (1) of
PPPoE sessions for MAC 00:00:67:13:01:02"

Host-limit

The maximum number of PPPoE hosts is defined when enabling host-limit. When omitted, a
single host is allowed.
*B:BSR-1> configure
subscr-mgmt
sla-profile "sla-profile-1"
host-limit 10
exit
exit

If the configured host-limit is reached for a subscriber, access is denied for a new host, and an
event is generated.
"PPPoE session failure on SAP 1/1/3:1 in service 1 - subscriber PPPoE-hostuser1@domain1 sla-profile sla-profile-1, host-limit (1) exceeded"

Note: An optional parameter remove-oldestcan be specified behind the host-limit. In this case the
new host is accepted and the old one will be removed.
B:BSR-1> configure
subscr-mgmt
sla-profile "sla-profile-1"
host-limit 10 remove-oldest
exit
exit

Page 586

Advanced Configuration Guide

ESMv4: PPPoE Hosts

multi-sub-sap

This parameter defines the maximum number of subscribers (dynamic and static) that can be
simultaneously active on this SAP.
When omitted, a single PPPoE session per sap is allowed (no multi-sub-sap).
*B:BSR-1> configure service vprn 1
---snip--group-interface "group-int-1" create
sap 1/1/3:1 create
sub-sla-mgmt
multi-sub-sap 100
exit

A trap is generated when trying to instantiate a new PPPoE session while the configured number
of the multi-sub-sap is reached.
"PPPoE session failure on SAP 1/1/3:1 in service 1 - Number of subscribers exceeds the
configured multi-sub-sap limit (1)"

Advanced Configuration Guide

Page 587

Configuration

Redundancy
Redundancy for PPPoE sessions can be used for load balancing the sessions between the 2 BSRs.
PADO-delays (which can come from RADIUS, LUDB, and policy) is using to achieve that.
The redundant BSRs need different IP subnets, and upon failure the PPP sessions will need to be
re-established.
Because PADI messages are broadcast on a multi-access network, all BSRs on that network will
reply with a PADO to the initiator.
The PADR and PADS are sent in unicast to the MAC address from the first received PADO
message.
In order to allow control over the NAS/BSR selection for a given PPPoE session the 7750 and
7710 offer the ability to delay the PADO message. Due to the fact that PPPoE clients select the
NAS/BSR for further communication based on the first PADO message that arrives, this
functionality provides control over the NAS/BSR who gets selected for a given PPPoE session.
On top if for some reason a NAS/BSR, without PADO delay configured in the PPPoE policy, does
not reply on PADI messages to the client another NAS/BSR with a PADO delay configured will
reply based on the time configured and ultimately the PPPoE session will be established with the
PADO delayed NAS/BSR.
Active
pado-delay = 0

Simulated
PADI

BSAN

BSR-1

Standby
PADI
pado-delay = 30
BSR-2
OSSG459

Figure 15: Pado-Delay Scenario

Page 588

Advanced Configuration Guide

ESMv4: PPPoE Hosts

To check the pado-delay value.


*A:BSR-1# show subscriber-mgmt pppoe-policy pppoe-policy-1
===============================================================================
PPPoE Policy "pppoe-policy-1"
===============================================================================
Description
: (Not Specified)
Last Mgmt Change
: 01/11/2010 11:21:01
PPP-mtu
: N/A
Keepalive Interval
: 10s
Keepalive Multiplier : 1
Disable AC-Cookies
: No
PADO Delay
: 3000msec
Max Sessions-Per-Mac : 63
Reply-On-PADT
: No
PPP-Authentication
: pref-CHAP
PPP-CHAP Challenge
: 32 - 64
---snip---

High Availability
The PPPoE session state is HA: the session state is synchronised to the standby CPM. When the
active CPM fails, all PPPoE hosts stay active without service interruption.

Advanced Configuration Guide

Page 589

Conclusion

Conclusion
This section provides configuration and troubleshooting commands for PPPoE hosts in a Layer 3
Routed CO (IES/VPRN subscriber interface) context.

Page 590

Advanced Configuration Guide

ESM IPv4: Multicast with Redirection

In This Chapter
This section describes ESM IPv4 multicast with redirection configurations.
Topics in this section include:

Applicability on page 592

Overview on page 593

Configuration on page 595

Conclusion on page 627

Advanced Configuration Guide

Page 591

Applicability

Applicability
This example is applicable to all 7750 SR-12 with IOM3-XP and IMMs, and needs chassis mode c
as a minimum. This is also supported on 7450 ESS chassis in mixed mode and also on 7750 SRc4/12 platform.
The configuration was tested on release 11.0R1 and covers both IPoE and PPPoE subscribers.

Page 592

Advanced Configuration Guide

ESM IPv4: Multicast with Redirection

Overview
Alcatel-Lucents Triple Play Service Delivery Architecture (TPSDA) allows operators to integrate
High Speed Internet (HSI), voice, and video services within a single network infrastructure. The
goal of this example is to walk through a TPSDA multicast architecture with redirection. The
topics are divided into the following sections:

ESM (Enhanced Subscriber management) multicast baseline configuration

Single BNG with redirection

SRRP BNG configuration with static SAP

IPoE ESM multicast configuration

PPPoE ESM multicast configuration

Subscriber Routed Redundancy Protocol (SRRP)


Multi-Chassis Synchronization (MCS) walk through

The network topology displayed in Figure 1 shows a typical TPSDA setup. It consists of three
7750s and a single 7450. Two 7750s are configured as Broadband Network Gateways (BNGs) and
the third 7750 is configured as a P router. The 7450 is used as an aggregation switch to aggregate
all subscribers. In ESM IPv4: Multicast with SRRP on page 629, multicast is directly distributed
to a subscriber through a subscriber SAP. This example walks through another popular model
which redirects all multicast streams to a common routed interface for all subscribers. When
multicast is put on the common routed interface, one single copy of a multicast stream is delivered
to multiple subscribers. In this model, per-subscriber replication of multicast streams is done on an
access node or on the aggregation network in order to minimize the bandwidth consumed by the
multicast traffic in access/aggregation.

Advanced Configuration Guide

Page 593

Overview

Aggregation
Switch (Agg-1)

MC-LAG
with SRRP

Multicast
Source

BNG-1
7750 SR

P Router (P-1)

IES
7450

7750 SR

IES
Subscribers

BNG-2
7750 SR
IPoE/PPPoE Session
l 0270

Figure 16: Network Topology Overview

Figure 16 shows two BNGs configured with SRRP to provide redundancy. The P router is
connected to the multicast source and is connected to both BNGs. The connections between the
BNGs and the P router, and the multicast source and the P router, are also running PIM to provide
multicast delivery. On the access side, the two BNGs are connected to an aggregation switch via
MC-LAG aggregating the traffic for both PPPoE and IPoE subscribers. The BNGs facing the
subscriber side are IGMP aware and will respond to any subscribers IGMP requests.
There are two requirements for a subscriber to receive multicast streams. First, the ESM groupinterface must have IGMP enabled. Second, the customization of each subscribers subscriber
profile to allow them to receive multicast streams. When both requirements are met, the BNG will
process the subscribers IGMP messages, otherwise, IGMP messages are simply dropped. All
customer premise device (CPE) IGMP messages are aggregated via the 7450 and passed onto the
BNGs. Since the BNGs are running SRRP, the SRRP master is the only BNG processing and
answering the IGMP messages. Protocol Independent Multicast (PIM) is then used between the
BNG and the P router to request the multicast streams. If PIM is successful in retrieving the
multicast group, the multicast stream is forwarded towards the individual subscribers. This is the
typical multicast delivery for TPSDA.

Page 594

Advanced Configuration Guide

ESM IPv4: Multicast with Redirection

Configuration
This example builds on the ESM multicast foundation discussed in ESM IPv4: Multicast with
SRRP on page 629. It starts with a single BNG setup with redirection.

ESM Multicast Interface Redirection


Figure 17 shows a popular ESM multicast model that redirects all multicast streams to a dedicated
router interface. When configuring a redirected interface be aware that:
1. Redirection between Global Routing Table (GRT) interfaces and VPRN interfaces is not supported

GRT interfaces are interfaces that reside in the base router or in an IES.

2. Redirection can be performed between interfaces in the GRT or between the interfaces in any
VPRN (even different VPRNs).
The following steps start with a simple ESM multicast configuration for BNG, without redirection.

1/1/10

1/1/2

Redirect
Interface

IES
1

Group 239.255.1.1
SRC 192.168.4.2

IGMP

Host Session
al_0271

Figure 17: Single BNG Setup with Multicast Redirection

Below is the BNG-1 configuration without multicast redirection. Subscribers are


located in the 10.0.0.0/8 subnet. The multicast stream (S,G) is (192.168.4.2, 239.255.1.1).
The local DHCP server is also on BNG-1.

Step 1.

*A:BNG-1>config>router>info
#-------------------------------------------------echo "Local DHCP Server Configuration"
#-------------------------------------------------dhcp

Advanced Configuration Guide

Page 595

Configuration

local-dhcp-server "dhcp-local-server" create


use-gi-address scope pool
pool "pool-1" create
subnet 10.0.0.0/8 create
options
subnet-mask 255.0.0.0
default-router 10.255.255.254
exit
address-range 10.0.0.10 10.0.0.254
exit
exit
no shutdown
exit
exit
#-------------------------------------------------echo "IP Configuration"
#-------------------------------------------------interface "dhcp-lb1"
address 192.168.0.1/32
loopback
local-dhcp-server dhcp-local-server
no shutdown
exit
*A:BNG-1>config>service>ies# info
---------------------------------------------description "BNG-1"
interface int-multicast-source" create
address 192.168.4.1/30
sap 1/1/2 create
no shutdown
exit
exit
subscriber-interface "sub-int-1" create
address 10.255.255.254/8
group-interface "group-int-1" create
srrp-enabled-routing
dhcp
server 192.168.0.1
gi-address 10.255.255.254
lease-populate 10
no shutdown
exit
authentication-policy "auth-policy-1"
sap 1/1/5:4 create
sub-sla-mgmt
multi-sub-sap 10
no shutdown
exit
exit
pppoe
no shutdown
exit
exit
exit
*A:BNG-1>config>router# info
interface "system"
address 192.0.2.1/32

Page 596

Advanced Configuration Guide

ESM IPv4: Multicast with Redirection

no shutdown
exit
igmp
group-interface group-int-1
no shutdown
exit
exit
pim
interface "int-multicast-source"
no shutdown
rp
static
address 192.0.2.1
group-prefix 224.0.0.0/4
exit
exit
exit
*A:BNG-1> config subscr-mgmt
igmp-policy "igmp-policy-1" create
exit
exit all
sub-profile "multicast-profile-1" create
igmp-policy "igmp-policy-1"
exit all

Configure a router interface to redirect all multicast streams to, and then include the
router interface in IGMP.

Step 2.

*A:BNG-1> config>service>ies# info


---------------------------------------------interface "redirected" create
address 192.168.10.1/30
sap 1/1/10 create
exit
exit
*A:BNG-1>config>router# info
igmp
interface "redirected"
----------------------------------------------

Define a router redirection policy. This will redirect every (S,G) towards the
redirected interface.

Step 3.

*A:BNG-1> config>router>policy-options# info


---------------------------------------------policy-statement "mcast_redirect_if"
default-action accept
multicast-redirection fwd-service 1 "redirected"
exit

Advanced Configuration Guide

Page 597

Configuration

exit

Step 4.

Apply the redirection policy created above in the igmp policy.

*A:BNG-1> config>subscr-mgmt>igmp-policy# info


---------------------------------------------redirection-policy "mcast_redirect_if"
----------------------------------------------

From this point on all multicast streams will be redirected to the redirected interface.
Now send an IGMPv3 join message and then use the show router igmp group command to verify
that all multicast streams are redirected. In this example IGMPv3 is used with an (S,G) of
(192.168.4.2, 239.255.1.1). The host has the IP address 10.0.0.10. Below is the output for PPPoE
and for IPoE subscribers, shown separately.
Step 5a. Redirection with PPPoE subscribers: Viewing the multicast groups. In the PPPoE

case, the multicast (S,G) shows up on both the redirected interface and the host.
*A:BNG-1> show router igmp group
===============================================================================
IGMP Interface Groups
===============================================================================
(192.168.4.2,239.255.1.1)
Up Time : 0d 00:00:04
Fwd List : redirected
===============================================================================
IGMP Host Groups
===============================================================================
(192.168.4.2,239.255.1.1)
Fwd List : 10.0.0.10
Up Time : 0d 00:00:04
===============================================================================
IGMP SAP Groups
===============================================================================
------------------------------------------------------------------------------(*,G)/(S,G) Entries : 2
===============================================================================

Step 5b. Redirection with IPoE subscribers: Viewing the multicast groups. In the IPoE case,

the multicast (S,G) shows up on both the redirected interface and the SAP.
*A:BNG-1> show router igmp group
===============================================================================
IGMP Interface Groups
===============================================================================
(192.168.4.2,239.255.1.1)
Up Time : 0d 00:00:04
Fwd List : redirected
===============================================================================
IGMP Host Groups
===============================================================================
===============================================================================
IGMP SAP Groups

Page 598

Advanced Configuration Guide

ESM IPv4: Multicast with Redirection

===============================================================================
(192.168.4.2,239.255.1.1)
Fwd List : 10.0.0.10
Up Time : 0d 00:00:04
------------------------------------------------------------------------------(*,G)/(S,G) Entries : 2
===============================================================================

Now the redirected interface is the only interface sending out multicast streams. The first
command shows that the group interface does not register any multicast group (Num-Groups=0).
The second command displays all multicast group are registered against the redirected interface
(Num-Groups=1).
*A:BNG-1> show router igmp group-interface
===============================================================================
IGMP Group-Interfaces
===============================================================================
FwdSvc Group-Interface
Adm/Opr-State
Import-Policy
SAP
Adm/Opr-Version
Num-Groups
------------------------------------------------------------------------------1
group-int-1
Up/Up
none
1/1/2
3/3
0
------------------------------------------------------------------------------Group-Interfaces = 1, SAPs = 1
===============================================================================
*A:BNG-1> show router igmp interface
===============================================================================
IGMP Interfaces
===============================================================================
Interface
Adm Oper Querier
Cfg/Opr Num
Policy
Version Groups
------------------------------------------------------------------------------redirected
Up
Up
192.168.10.1
3/3
1
none
------------------------------------------------------------------------------Interfaces : 1
===============================================================================

Advanced Configuration Guide

Page 599

Configuration

Debug facilities can be used to troubleshoot multicast redirection issues. The output below shows
the multicast is redirected to a regular routed interface after an IGMP join.
7017 2013/05/24 09:27:50.65 EST MINOR: DEBUG #2001 ies1 IGMP[9]
"IGMP[9]: RX-PKT
[013 00:25:03.310] IGMP host 10.0.0.10 V3 PDU: 10.0.0.10 -> 224.0.0.22 pduLen
20
Type: V3 REPORT maxrespCode 0x0 checkSum 0xddf6
Num Group Records: 1
Group Record 0
Type: ALW_NEW_SRCS, AuxDataLen 0, Num Sources 1
Mcast Addr: 239.255.1.1
Source Address List
192.168.4.2
"
7018 2013/05/24 09:27:50.65 EST MINOR: DEBUG #2001 ies1 IGMP[ies1 inst 9
]
"IGMP[ies1 inst 9]: igmpIfGroupAdd
Adding 239.255.1.1 to IGMP host 10.0.0.10 database"
7019 2013/05/24 09:27:50.65 EST MINOR: DEBUG #2001 ies1 IGMP[ies1 inst 9
]
"IGMP[ies1 inst 9]: igmpProcessGroupRec
Process group rec ALW_NEW_SRCS received on host 10.0.0.10 for group 239.255.1.1 i
n mode INCLUDE. Num srcs 1"
7020 2013/05/24 09:27:50.66 EST MINOR: DEBUG #2001 ies1 IGMP[ies1 inst 9
]
"IGMP[ies1 inst 9]: igmpIfSrcAdd
Adding i/f source entry for host 10.0.0.10 (192.168.4.2,239.255.1.1) to IGMP fwdList
Database, redir if interface redirected [ifIndex 13]"

The output below shows what happens when an IGMP leave message is sent so that the multicast
stream is no longer being forwarded.
7024 2013/05/24 09:29:29.85 EST MINOR: DEBUG #2001 ies1 IGMP[9]
"IGMP[9]: RX-PKT
[013 00:26:42.510] IGMP host 10.0.0.10 V3 PDU: 10.0.0.10 -> 224.0.0.22 pduLen
20
Type: V3 REPORT maxrespCode 0x0 checkSum 0xdcf6
Num Group Records: 1
Group Record 0
Type: BLK_OLD_SRCS, AuxDataLen 0, Num Sources 1
Mcast Addr: 239.255.1.1
Source Address List
192.168.4.2
"
7025 2013/05/24 09:29:29.85 EST MINOR: DEBUG #2001 ies1 IGMP[ies1 inst 9
]
"IGMP[ies1 inst 9]: igmpProcessGroupRec
Process group rec BLK_OLD_SRCS received on host 10.0.0.10 for group 239.255.1.1 i
n mode INCLUDE. Num srcs 1"

Page 600

Advanced Configuration Guide

ESM IPv4: Multicast with Redirection

7026 2013/05/24 09:29:29.85 EST MINOR: DEBUG #2001 ies1 IGMP[ies1 inst 9
]
"IGMP[ies1 inst 9]: igmpProcessIfSrcTimerExp
Source Timer expired for IGMP host 10.0.0.10 (192.168.4.2,239.255.1.1)"
7027 2013/05/24 09:29:29.85 EST MINOR: DEBUG #2001 ies1 IGMP[ies1 inst 9
]
"IGMP[ies1 inst 9]: igmpIfSrcDel
Deleting i/f source entry for host 10.0.0.10 (192.168.4.2,239.255.1.1) from IGMP Dat
abase. DeleteFromAvl: 1 Redir 0"
7028 2013/05/24 09:29:29.85 EST MINOR: DEBUG #2001 ies1 IGMP[ies1 inst 9
]
"IGMP[ies1 inst 9]: igmpIfGroupDel
Deleting 239.255.1.1 from IGMP host 10.0.0.10 database"
7029 2013/05/24 09:29:29.85 EST MINOR: DEBUG #2001 ies1 IGMP MCS[9]
"IGMP MCS[9]: TX-MCS Data (GlblDel)
host 10.0.0.10
Key Type: HostGroup, Len: 13, Host : 10.0.0.10, Grp Addr: 239.255.1.1
Data Type: Group, Len: 16, Ver: 0, RecType: 1, Compat Mode: 3,
Num Fwd Srcs: 0, Num Blk Srcs: 0
"
7030 2013/05/24 09:29:29.85 EST MINOR: DEBUG #2001 ies1 IGMP[ies1 inst 9
]
"IGMP[ies1 inst 9]: igmpMcsDelIfGroup
Deleting MCS entry for host 10.0.0.10, group 239.255.1.1, Glb"

Advanced Configuration Guide

Page 601

Configuration

ESM SRRP with MC-LAG


Figure 18 shows a numbered SRRP setup with MC-LAG SAPs serving both IPoE and PPPoE
subscribers. ESM IPv4: Multicast with SRRP on page 629 covers the configuration of regular
SRRP SAPs, consequently this example provides configuration guidelines to use a different type
of SAP: SRRP MC-LAG SAPs. Note that redirection on SRRP SAPs without MC-LAG is also
supported. The configuration of the RADIUS server is out of the scope of this example.
RADIUS
Server

Agg-1

P Router

BNG-1
SRRP
10.255.255.254

10.255.255.253

1/1/2
1/1/1

1/1/2

IES

1/1/5

dhcp-local-server
10.1.1.1

1/1/2
1/1/3

LAG
1/1/3

SDP
192.168.1.1

MC-LAG
192.168.3.1/30
192.168.1.2

1/1/5

10.255.255.252

SDP

IES
BNG-2

1/1/2

On BNG 1 and 2, Port 1/1/5


VLAN 4 is for data path
VLAN 4094 is the
redirected interface
Redirect interface uses
192.168.10.0/24
al_0272

Figure 18: Network Topology with MC-LAG

The baseline configuration for BNG-1 is shown below without any IGMP configuration. The
configuration begins with the MC-LAG configuration. ESM is configured in an IES service but it
is also possible to configure ESM in a VPRN. The redirection interface must be in the same
routing instance as the group-interface, this applies to both regular SRRP SAPs and MC-LAG
SAPs. In the following example, the MC-LAG is lag-1, customer data traffic is using VLAN 4,
MC-LAG control traffic is using VLAN 5, and the redirected multicast streams are using VLAN
4094.
A:BNG-1>config>lag# info
---------------------------------------------mode access
encap-type dot1q
port 1/1/5 priority 1
lacp active administrative-key 32768

Page 602

Advanced Configuration Guide

ESM IPv4: Multicast with Redirection

no shutdown
A:BNG-1>config>redundancy# info
---------------------------------------------multi-chassis
peer 192.0.2.2 create
mc-lag
lag 1 lacp-key 1 system-id 00:00:00:00:00:01 system-priority 100
no shutdown
exit
sync
igmp
srrp
sub-mgmt ipoe pppoe
port lag-1 create
range 4-4 sync-tag "mclagdata"
range 5-5 sync-tag "mclagcontrol"
exit
no shutdown
exit
no shutdown
exit
exit
A:BNG-1>config>service>ies# info
---------------------------------------------description "BNG-1"
redundant-interface "MClink-BNG-1-BNG-2" create
address 192.168.1.0/31
ip-mtu 1500
spoke-sdp 1:1 create
no shutdown
exit
exit
interface int-BNG-1-P-1" create
address 192.168.2.1/30
sap 1/1/2 create
no shutdown
exit
exit
interface "lag-redirected" create
address 192.168.10.253/24
vrrp 1
backup 192.168.10.254
exit
sap lag-1:4094 create
exit
exit
subscriber-interface "sub-int-1" create
address 10.255.255.253/8 gw-ip-address 10.255.255.254 track-srrp 1
group-interface "group-int-1" create
dhcp
server 192.168.0.1
gi-address 10.255.255.253
lease-populate 10
no shutdown
exit
authentication-policy "auth-policy-1"
redundant-interface "MClink-BNG-1-BNG-2"

Advanced Configuration Guide

Page 603

Configuration

sap lag-1:1 create


sub-sla-mgmt
def-sub-id use-sap-id
def-sub-profile "multicast-profile-1"
def-sla-profile "sla-profile-1"
sub-ident-policy "sub-ident-policy-1"
multi-sub-sap 10
no shutdown
exit
exit
sap lag-1:5 create
exit
srrp 4 create
message-path lag-1:5
priority 200
no shutdown
exit
pppoe
no shutdown
exit
exit
exit
*A:BNG-1>config>router# info
#-------------------------------------------------echo "IP Configuration"
#-------------------------------------------------interface "int-BNG-1-BNG-2"
address 192.168.6.1/30
port 1/1/1:1
no shutdown
exit
interface "system"
address 192.0.2.1/32
bfd 100 receive 100 multiplier 3
no shutdown
exit
autonomous-system 65536
#-------------------------------------------------echo "OSPFv2 Configuration"
#-------------------------------------------------ospf
traffic-engineering
area 0.0.0.0
interface "system"
no shutdown
exit
interface "int-BNG-1-BNG-2"
interface-type point-to-point
metric 10000
no shutdown
exit
interface "sub-int-1"
no shutdown
exit
interface "int-BNG-1-P-1"
no shutdown
exit
interface "lag-redirected"

Page 604

Advanced Configuration Guide

ESM IPv4: Multicast with Redirection

no shutdown
exit
exit
exit
pim
interface int-to_P_router
exit

The baseline configuration for BNG-2 is shown below without IGMP configuration. The default
SRRP priority for BNG-2 is lower than the SRRP priority for BNG-1 and hence BNG-2 will be in
standby mode.
A:BNG-2>config>lag# info
---------------------------------------------mode access
encap-type dot1q
port 1/1/5 priority 1
lacp active administrative-key 32768
no shutdown
A:BNG-2>config>redundancy# info
---------------------------------------------multi-chassis
peer 192.0.2.1 create
mc-lag
lag 1 lacp-key 1 system-id 00:00:00:00:00:01 system-priority 100
no shutdown
exit
sync
igmp
srrp
sub-mgmt ipoe pppoe
port lag-1 create
range 4-4 sync-tag "mclagdata"
range 5-5 sync-tag "mclagcontrol"
exit
no shutdown
exit
no shutdown
exit
exit

A:BNG-2>config>service>ies# info
---------------------------------------------description "BNG SRRP1"
redundant-interface "MClink-BNG-1-BNG-2" create
address 192.168.1.1/31
ip-mtu 1500
spoke-sdp 1:1 create
no shutdown
exit
exit
interface "lag-redirected" create
address 192.168.10.252/24

Advanced Configuration Guide

Page 605

Configuration

vrrp 2
backup 192.168.10.254
exit
sap lag-1:4094 create
exit
exit
interface int-BNG-2-P-1" create
address 192.168.3.1/30
sap 1/1/2 create
no shutdown
exit
exit
subscriber-interface "sub-int-1" create
address 10.255.255.252/8 gw-ip-address 10.255.255.254 track-srrp 1
group-interface "group-int-1" create
dhcp
server 192.168.0.1
lease-populate 10
gi-address 10.255.255.252
no shutdown
exit
authentication-policy "auth-policy-1"
redundant-interface "MClink-BNG-1-BNG-2"
sap lag-1:4 create
sub-sla-mgmt
def-sub-id use-sap-id
def-sub-profile "multicast-profile-1"
def-sla-profile "sla-profile-1"
sub-ident-policy "sub-ident-policy-1"
multi-sub-sap 10
no shutdown
exit
exit
sap lag-1:5 create
exit
srrp 1 create
message-path lag-1:5
no shutdown
exit
pppoe
no shutdown
exit
exit
exit
*A:BNG-2>config>router# info
#-------------------------------------------------echo "IP Configuration"
#-------------------------------------------------interface "int-BNG-2-BNG-1"
address 192.168.6.1/30
port 1/1/1:1
no shutdown
exit
interface "system"
address 192.0.2.2/32
bfd 100 receive 100 multiplier 3
no shutdown

Page 606

Advanced Configuration Guide

ESM IPv4: Multicast with Redirection

exit
autonomous-system 65536
#-------------------------------------------------echo "OSPFv2 Configuration"
#-------------------------------------------------ospf
traffic-engineering
area 0.0.0.0
interface "system"
no shutdown
exit
interface "int-BNG-2-BNG-1"
interface-type point-to-point
metric 10000
no shutdown
exit
interface "sub-int-1"
no shutdown
exit
interface "lag-redirected"
no shutdown
exit
interface "int-BNG-2-P-1"
no shutdown
exit
exit
exit
pim
interface int-BNG-2-P-1
exit

The baseline configuration for the 7450 aggregation switch is shown below. It has a LAG interface
configured. There are two VPLSs. The first is VPLS 1 which is used to receive all redirected
multicast traffic on VLAN 4094. The second is VPLS 2 which is responsible for passing all
subscriber traffic on VLAN 4.
A:Agg-1>config>lag# info
---------------------------------------------mode access
encap-type dot1q
port 1/1/2
port 1/1/3
lacp active administrative-key 1
no shutdown
*A:Agg-1>config>service>info
vpls 1 customer 1 create
sap lag-1:4094 create
no shutdown
exit
sap 1/1/1:4094 create
no shutdown
exit
no shutdown
exit

Advanced Configuration Guide

Page 607

Configuration

*A:Agg-1>config>service>info
vpls 2 customer 1 create
sap lag-1:4 create
no shutdown
exit
sap 1/1/1:4 create
no shutdown
exit
no shutdown
exit

The baseline configuration for the P router is shown below. It is now responsible for DHCP
address assignment (moved from BNG-1 in the previous configuration to allow for redundant
operations in case of failure of either BNG-1 or BNG-2) and is also attached to the multicast
source.
*A:P-router>config>router>info
#-------------------------------------------------echo "Local DHCP Server Configuration"
#-------------------------------------------------dhcp
local-dhcp-server "dhcp-local-server" create
use-gi-address scope pool
pool "pool-01" create
subnet 10.0.0.0/8 create
options
subnet-mask 255.0.0.0
default-router 10.255.255.254
exit
address-range 10.0.0.10 10.0.0.254
exit
exit
no shutdown
exit
exit
#-------------------------------------------------echo "IP Configuration"
#-------------------------------------------------interface "dhcp-lb1"
address 192.168.0.1/32
loopback
local-dhcp-server dhcp-local-server
no shutdown
exit
interface int-P-1-BNG-1"
address 192.168.2.2/30
port 1/1/2
no shutdown
exit
interface int-P-1-BNG-2"
address 192.168.3.2/30
port 1/1/3
no shutdown
exit
interface "P-1-multicast-source"
address 192.168.4.1/30

Page 608

Advanced Configuration Guide

ESM IPv4: Multicast with Redirection

port 1/1/1
no shutdown
exit
interface "system"
address 192.0.2.3/32
no shutdown
exit
#-------------------------------------------------ospf
area 0.0.0.0
interface "system"
no shutdown
exit
interface int-P-1-BNG-1"
no shutdown
exit
interface int-P-1-BNG-2"
no shutdown
exit
interface P-1-multicast-source"
no shutdown
exit
exit
exit
pim
interface int-P-1-BNG-1"
exit
interface int-P-1-BNG-2"
exit
interface P-1-multicast-source"
exit
exit

Advanced Configuration Guide

Page 609

Configuration

Enable IGMP on Group Interface and Redirect Interface on the


BNGs
The configuration below shows how to add the group-interface and redirect interface to IGMP. If
ESM is configured in a VPRN, each VPRN will have its own IGMP instance. Remember to apply
the following configuration to both BNG-1 and BNG-2.
*A:BNG-1>config>router>igmp# info
---------------------------------------------group-interface "group-int-1"
no shutdown
exit
interface "lag-redirected"
no shutdown
exit

Next, the IGMP policy is configured to redirect all multicast to a dedicated interface. The
following configuration outlines the steps necessary to enable multicast redirection.
Define a router redirection policy. This will redirect every (S,G) towards the
redirected interface.

Step 1.

*A:BNG-1> config>router>policy-options# info


---------------------------------------------policy-statement "mcast_redirect_if"
default-action accept
multicast-redirection fwd-service 1 "lag-redirected"
exit
exit

Step 2.

Apply the redirection policy to the igmp-policy.

*A:BNG-1> config>subscr-mgmt>igmp-policy# info


---------------------------------------------redirection-policy "mcast_redirect_if"
----------------------------------------------

Add multi-chassis synchronization of the redirected interface. This will


synchronize the IGMP state on this MC-LAG interface.

Step 3.

*A:BNG-1>config>redundancy# info
---------------------------------------------multi-chassis
peer 192.0.2.2 create
sync
port lag-1 create
range 4-4 sync-tag "mclagdata"
range 5-5 sync-tag "mclagcontrol"
range 4094-4094 sync-tag "mclagmulticast"
igmp
srrp

Page 610

Advanced Configuration Guide

ESM IPv4: Multicast with Redirection

sub-mgmt ipoe pppoe


exit
no shutdown

Advanced Configuration Guide

Page 611

Configuration

ESM IGMP IPoE walkthrough


With the baseline configuration applied, the BNG is ready to process IGMP messages and deliver
multicast streams to the subscribers through the redirected interface. Figure 4 shows the message
flow for IPoE subscribers requesting and receiving multicast traffic. The key points are
highlighted in the dotted box:

The group-interface and redirect interface must have IGMP enabled.

The subscriber must be associated with an IGMP-policy via sub-profile.


SRRP State:
Master
IES

Subscriber

BNG-1

Agg-1

IGMPv3 Report
grp: 239.255.1.1
src: 192.168.4.2

P-1

Multicast Server

PPPoE Subscriber Created

Must have
1) IGMP Configured Group Interface
2) Subscriber Must Have IGMP-Policy
PIM Join
(192.168.4.2.239.255.1.1)

Multicast Packet:
Eth 01:00:5e:ff:01:01
IP 239.255.1.1
Multicast Packet:
Eth 01:00:5e:ff:01:01
IP 239.255.1.1

Multicast Packet:
Eth 01:00:5e:ff:01:01
IP 239.255.1.1

PIM Join
(192.168.4.2.239.255.1.1)
Multicast Packet:
Eth 01:00:5e:ff:01:01
IP 239.255.1.1

Redirected to Interface
Specified in IGMP Policy

al_0273

Figure 19: IPoE Multicast Message Flow

To verify the (ESM enabled) group-interface and the redirect interface are ready for multicast, use
the show commands as indicated below. Remember the IES service ID is 1, the group-interface
name is group-int-1 and the interface name is lag-redirected.
Step 1.

Verify if the group-interface and redirected interface have IGMP enabled.

*A:BNG-1> show router igmp group-interface


===============================================================================
IGMP Group-Interfaces
===============================================================================

Page 612

Advanced Configuration Guide

ESM IPv4: Multicast with Redirection

FwdSvc Group-Interface
Adm/Opr-State
Import-Policy
SAP
Adm/Opr-Version
Num-Groups
------------------------------------------------------------------------------1
group-int-1
Up/Up
none
lag-1:4
3/3
0
------------------------------------------------------------------------------Group-Interfaces = 1, SAPs = 1
===============================================================================
*A:BNG-1> show router igmp interface
===============================================================================
IGMP Interfaces
===============================================================================
Interface
Adm Oper Querier
Cfg/Opr Num
Policy
Version Groups
------------------------------------------------------------------------------lag-redirected
Up
Down 0.0.0.0
3/3
0
none
------------------------------------------------------------------------------Interfaces : 1
===============================================================================

Ensure the subscriber is associated with an IGMP-policy. Since the IGMP-policy


is associated with a subscriber-profile, verification of an IGMP-policy is performed via the
sub-profile.

Step 2.

*A:BNG-1> show subscriber-mgmt sub-profile "multicast-profile-1"


===============================================================================
Subscriber Profile multicast-profile-1
===============================================================================
Description
: (Not Specified)
I. Sched. Policy : N/A
E. Sched. Policy : N/A
E. Agg Rate Limit: Max
I. Policer Ctrl. : N/A
E. Policer Ctrl. : N/A
Q Frame-Based Ac*: Disabled
Acct. Policy
: N/A
Collect Stats
: Disabled
Rad. Acct. Pol. : N/A
Dupl. Acct. Pol. : N/A
ANCP Pol.
: N/A
HostTrk Pol.
: N/A
IGMP Policy
: igmp-policy-1
Sub. MCAC Policy : N/A
NAT Policy
: N/A
Def. Encap Offset: none
Encap Offset Mode: none
Avg Frame Size
: N/A
Preference
: 5
------------------------------------------------------------------------------HSMDA-2
------------------------------------------------------------------------------I. Qos Policy
: 1
E. Qos Policy
: 1
E. Agg Rate Limit: Max
E. WRR Policy
: N/A
Pkt Byte Offset : add 0*
------------------------------------------------------------------------------Last Mgmt Change : 05/14/2013 10:12:49
===============================================================================
* indicates that the corresponding row element may have been truncated.

Advanced Configuration Guide

Page 613

Configuration

After the verification, the BNGs are ready to deliver multicast streams. Next, initiate an IGMP
report from a subscriber requesting a multicast channel. In this example, IGMPv3 with SSM is
used. If the IPoE subscriber is receiving multicast through the subscriber SAP then the IGMP
group will be associated with the SAP. Since redirection is used, the IGMP group is associated
with the redirected interface instead. The output below shows that when an IGMP message is
received and processed, an (S,G) binding is associated with the redirected interface. The example
uses an IGMPv3 SSM message requesting (192.168.4.2, 239.255.1.1). The subscriber IP address
is 10.0.0.2.
*A:BNG-1> show router igmp group
===============================================================================
IGMP Interface Groups
===============================================================================
(192.168.4.2,239.255.1.1)
Up Time : 0d 00:00:12
Fwd List : lag-redirected
===============================================================================
IGMP Host Groups
===============================================================================
(192.168.4.2,239.255.1.1)
Fwd List : 10.0.0.2
Up Time : 0d 00:00:12
===============================================================================
IGMP SAP Groups
===============================================================================
------------------------------------------------------------------------------(*,G)/(S,G) Entries : 2
===============================================================================

Next, verify the individual subscribers and their IGMP information. First verify the IGMP policy
related to the subscriber.
*A:BNG-1> show service active-subscribers igmp detail
===============================================================================
Active Subscribers Detail
===============================================================================
Subscriber
IGMP-Policy
HostAddr
GrpItf
NumGroups
GrpAddr
Type
Up-Time
Mode
SrcAddr
Type
Blk/Fwd
------------------------------------------------------------------------------video_user_01
igmp-policy-1
10.0.0.2
sub-int-1
1
239.255.1.1
Dynamic
0d 00:01:26
Include
192.168.4.2
Dynamic
Fwd
------------------------------------------------------------------------------Number of Subscribers : 1
===============================================================================

Since the IGMP-policy controls bandwidth, interoperability and restricts multicast groups, it is
useful to view what is defined in the IGMP-policy if the subscriber fails to receive multicast
streams.

Page 614

Advanced Configuration Guide

ESM IPv4: Multicast with Redirection

*A:BNG-1> show subscriber-mgmt igmp-policy "igmp-policy-1"


===============================================================================
IGMP Policy igmp-02
===============================================================================
Import Policy
:
Admin Version
: 3
Num Subscribers
: 1
Host Max Group
: No Limit
Host Max Sources
: No Limit
Host Max Group Sources
: No Limit
Fast Leave
: yes
Redirection Policy
: mcast_redirect_if
Per Host Replication
: no
Egress Rate Modify
: no
Mcast Reporting Destination Name
:
Mcast Reporting Admin State
: Disabled
===============================================================================

Below is a command to view the (S,G)s that all subscribers are requesting. Notice that the
operational status for the host is not forwarding (notFwding), this is because multicast is not
delivered directly over the subscriber SAP. All multicast traffic is delivered over the redirected
interface instead.
*A:BNG-1> show router igmp hosts detail
===============================================================================
IGMP Host 10.0.0.2
===============================================================================
Oper Status
: notFwding MacAddress
: 00:00:10:10:10:12
Oper version
: 3
Subscriber
: video_user_01
Num Groups
: 1
GrpItf
: sub-int-1
Max Grps Till Now: 1
IGMP-Policy
: igmp-policy-1
PPPoE SessionId : N/A
FwdSvcId
: 1
Max Srcs Allow*: No Limit
Max Grps Allowed : No Limit
Max Grp Srcs A*: No Limit
------------------------------------------------------------------------------IGMP Group
------------------------------------------------------------------------------Group Address
: 239.255.1.1
Up Time
: 0d 00:02:38
Expires
: Not running
Mode
: Include
V1 Host Timer
: Not running
Type
: Dynamic
V2 Host Timer
: Not running
Compat Mode: IGMP Version 3
Redir.SvcId
: 1
Redir.Intf : lag-redirected
----------------------------------------------------------Source Address
Expires
Type
Fwd/Blk
----------------------------------------------------------192.168.4.2
0d 00:01:42
Dynamic
Fwd
------------------------------------------------------------------------------Hosts : 1
===============================================================================

Advanced Configuration Guide

Page 615

Configuration

ESM IGMP PPPoE Walkthrough


The same baseline configuration is used for PPPoE subscriber. Figure 20 shows the message flow
for delivery of multicast streams to PPPoE subscribers.
SRRP State:
Master
IES
Subscriber

BNG-1

Agg-1

P-1

Multicast Server

PPPoE Subscriber Created


Src MAC: 00:00:00:00:00:01

IGMPv3 Report
grp: 239.255.1.1
src-lp: 192.168.4.2

Must have
1) IGMP Configured Group Interface and Redirect Interface
2) Subscriber Must Have IGMP-Policy
PIM Join
(192.168.4.2.239.255.1.1)

Multicast Packet:
Eth 01:00:5e:ff:01:01
IP 239.255.1.1
Multicast Packet:
Eth 01:00:5e:ff:01:01
IP 239.255.1.1

Multicast Packet:
Eth 01:00:5e:ff:01:01
IP 239.255.1.1

PIM Join
(192.168.4.2.239.255.1.1)
Multicast Packet:
Eth 01:00:5e:ff:01:01
IP 239.255.1.1

Redirected to Interface
Specified in IGMP Policy

al_0274

Figure 20: PPPoE Multicast Flow

The important items are highlighted in the dotted box. By default, PPPoE subscribers receive
multicast streams via Ethernet unicast over subscriber SAPs. PPPoE does not have a multicast
mechanism and requires all data traffic to be unicasted. However, because multicast streams are
redirected, the streams are sent as multicast at both Layers 2 and 3 (the Layer 2 header will have a
multicast destination MAC address and the Layer 3 header will have a multicast destination IP
address).
Verify the IGMP on the group-interface. It shows very little difference from the IPoE group
interface. No multicast streams are delivered directly over the subscriber SAP group-interface.
*A:BNG-1> show router igmp group-interface detail
===============================================================================
IGMP Group-Interfaces
===============================================================================
FwdSvc/Grp-Intf
: 1/group-int-1
Admin-Status
: Up
Oper-Status
: Up

Page 616

Advanced Configuration Guide

ESM IPv4: Multicast with Redirection

Import-Policy
: none
Subnet-Check
: Enabled
Router-Alert-Check : Enabled
Sub-Hosts-Only
: Enabled
MCAC Policy Name
:
MCAC Const Adm St : Enable
MCAC Max Unconst BW: no limit
MCAC Max Mand BW
: no limit
MCAC In use Mand BW: 0
MCAC Avail Mand BW : unlimited
MCAC In use Opnl BW: 0
MCAC Avail Opnl BW : unlimited
------------------------------------------------------------------------------SAP
: lag-1:4
Admin/Oper version: 3/3
Num Groups
: 0
Max Groups Allowed: No Limit
Max Groups Till Now: 0
Max Sources Allow*: No Limit
Max Grp Srcs Allo*: No Limit
------------------------------------------------------------------------------Group-Interfaces = 1, SAPs = 1
===============================================================================
* indicates that the corresponding row element may have been truncated.

All multicast streams should be delivered over the redirected interface. The output below shows
the IGMP group for a PPPoE subscriber and also that the multicast stream is associated with the
redirected interface. The (S,G) is (192.168.4.2, 239.255.1.1) and the subscriber IP address is
10.0.0.2.
*A:BNG-1> show router igmp group
===============================================================================
IGMP Interface Groups
===============================================================================
(192.168.4.2,239.255.1.1)
Up Time : 0d 00:05:15
Fwd List : lag-redirected
===============================================================================
IGMP Host Groups
===============================================================================
(192.168.4.2,239.255.1.1)
Fwd List : 10.0.0.2
Up Time : 0d 00:05:15
===============================================================================
IGMP SAP Groups
===============================================================================
------------------------------------------------------------------------------(*,G)/(S,G) Entries : 2
===============================================================================

The following output shows all the subscribers and the (S,G)s they have joined. Note that there is
only one PPPoE subscriber and the multicast stream is redirected.
*A:BNG-1> show router igmp hosts detail
===============================================================================
IGMP Host 10.0.0.2
===============================================================================
Oper Status
: Up
MacAddress
: 52:e0:50:bd:00:00
Oper version
: 3
Subscriber
: user-ppp-1
Num Groups
: 1
GrpItf
: group-int-1
Max Grps Till Now: 1
IGMP-Policy
: igmp-policy-1
PPPoE SessionId : 1
Next query time: 0d 00:01:47
FwdSvcId
: 1
Max Srcs Allow*: No Limit
Max Grps Allowed : No Limit
Max Grp Srcs A*: No Limit
-------------------------------------------------------------------------------

Advanced Configuration Guide

Page 617

Configuration

IGMP Group
------------------------------------------------------------------------------Group Address
: 239.255.1.1
Up Time
: 0d 00:00:36
Expires
: Not running
Mode
: Include
V1 Host Timer
: Not running
Type
: Dynamic
V2 Host Timer
: Not running
Compat Mode: IGMP Version 3
Redir.SvcId
: 1
Redir.Intf : lag-redirected
----------------------------------------------------------Source Address
Expires
Type
Fwd/Blk
----------------------------------------------------------192.168.4.2
0d 00:04:03
Dynamic
Fwd
------------------------------------------------------------------------------Hosts : 1
===============================================================================
* indicates that the corresponding row element may have been truncated.

To view the (S,G)s of a single subscriber, use the following command.


*A:BNG-1> show service active-subscribers igmp subscriber "user-ppp-1" detail
===============================================================================
Active Subscribers Detail
===============================================================================
Subscriber
IGMP-Policy
HostAddr
GrpItf
NumGroups
GrpAddr
Type
Up-Time
Mode
SrcAddr
Type
Blk/Fwd
------------------------------------------------------------------------------user-ppp-1
igmp-policy-1
10.0.0.2
group-int-1
1
239.255.1.1
Dynamic
0d 00:02:07
Include
192.168.4.2
Dynamic
Fwd
------------------------------------------------------------------------------Number of Subscribers : 1
===============================================================================

Page 618

Advanced Configuration Guide

ESM IPv4: Multicast with Redirection

ESM IGMP MCS


The BNGs are configured with SRRP for both IPoE and PPPoE subscribers. This provides stateful
redundancy when the master BNG fails. The SRRP master BNG will be the only BNG processing
and answering IGMP messages, while the standby BNG synchronizes the state information of all
subscribers via MCS in real time. In the event of a failure, the standby takes over and starts
processing all IGMP messages. As the standby BNG has the full state information of all
subscribers, including the (S,G)s they have joined, PIM starts sending joins for those (S,G)s
immediately after failover. Restoration of all multicast streams happens quickly and relies on the
PIM configuration and the underlying routing infrastructure. Note that the PIM command non-drattract-traffic can be used to reduce the failover outage by attracting multicast to the non
designated PIM router.
The following output shows the items that are synchronized between the BNGs. To reduce the
ESM multicast restoration time, it is important that all subscriber related data (IPoE, PPPoE,
SRRP and IGMP) are kept in sync. BNG-1 has system IP address 192.0.2.1 and BNG-2 has
system IP address 192.0.2.2.
*A:BNG-1> show redundancy multi-chassis sync peer 192.0.2.2 detail
===============================================================================
Multi-chassis Peer Table
===============================================================================
Peer
------------------------------------------------------------------------------Peer IP Address
: 192.0.2.2
Description
: (Not Specified)
Authentication
: Disabled
Source IP Address
: 192.0.2.1
Admin State
: Enabled
------------------------------------------------------------------------------Sync-status
------------------------------------------------------------------------------Client Applications
: IGMP SUBMGMT-IPOE SUBMGMT-PPPOE SRRP
Sync Admin State
: Up
Sync Oper State
: Up
DB Sync State
: inSync
Num Entries
: 15
Lcl Deleted Entries
: 0
Alarm Entries
: 0
Rem Num Entries
: 15
Rem Lcl Deleted Entries : 0
Rem Alarm Entries
: 0
===============================================================================
MCS Application Stats
===============================================================================
Application
: igmp
Num Entries
: 1
Lcl Deleted Entries
: 0
Alarm Entries
: 0
------------------------------------------------------------------------------Rem Num Entries
: 1
Rem Lcl Deleted Entries : 0
Rem Alarm Entries
: 0

Advanced Configuration Guide

Page 619

Configuration

------------------------------------------------------------------------------Application
: subMgmtIpoe
Num Entries
: 1
Lcl Deleted Entries
: 0
Alarm Entries
: 0
------------------------------------------------------------------------------Rem Num Entries
: 1
Rem Lcl Deleted Entries : 0
Rem Alarm Entries
: 0
------------------------------------------------------------------------------Application
: srrp
Num Entries
: 14
Lcl Deleted Entries
: 0
Alarm Entries
: 0
------------------------------------------------------------------------------Rem Num Entries
: 14
Rem Lcl Deleted Entries : 0
Rem Alarm Entries
: 0
------------------------------------------------------------------------------Application
: subMgmtPppoe
Num Entries
: 1
Lcl Deleted Entries
: 0
Alarm Entries
: 0
------------------------------------------------------------------------------Rem Num Entries
: 1
Rem Lcl Deleted Entries : 0
Rem Alarm Entries
: 0
------------------------------------------------------------------------------===============================================================================

To check the details of the sync data across the BNGs, a tools command giving a detailed
description of the IGMP information synced across MCS can be used.
*A:BNG-1> tools dump redundancy multi-chassis sync-database application igmp detail
If no entries are present for an application, no detail will be displayed.
FLAGS LEGEND: ld - local delete; da - delete alarm; pd - pending global delete
Peer Ip 192.0.2.2

Application IGMP
Sap-id
Client Key
SyncTag
DLen Flags
timeStamp
deleteReason code and description
------------------------------------------------------------------------------lag-1:4094
Host=10.0.0.2, HostGroup=239.255.1.1
mclagdata
20
-- -- -- 07/03/2013 15:20:49
0x0
lag-1:4
Group=239.255.1.1
mclagmulticast
20
-- -- -- 07/03/2013 15:20:49
0x0
The following totals are for:
peer ip ALL, port/lag ALL, sync-tag ALL, application IGMP
Valid Entries:
2

Page 620

Advanced Configuration Guide

ESM IPv4: Multicast with Redirection

Locally Deleted Entries:


0
Locally Deleted Alarmed Entries: 0
Pending Global Delete Entries:
0

Advanced Configuration Guide

Page 621

Configuration

ESM IGMP Debug


Debug facilities allow for real-time monitoring of events happening on the system. This includes
tools for debugging ESM multicast streams.
First enable the required debug on the system, then send an IGMP message to join a multicast
group (S,G). The message used in this example is an IGMPv3 message with SSM.
Below is the debug information for an ESM IGMP report message at packet level.
debug
router
igmp
packet mode egr-ingr-and-dropped
exit
exit
2977 2013/05/23 13:01:45.43 EST MINOR: DEBUG #2001 IGMP[9]
"IGMP[9]: RX-PKT
[012 03:58:58.090] IGMP host 10.0.0.2 V3 PDU: 10.0.0.2 -> 224.0.0.22 pduLen
20
Type: V3 REPORT maxrespCode 0x0 checkSum 0xddf7
Num Group Records: 1
Group Record 0
Type: ALW_NEW_SRCS, AuxDataLen 0, Num Sources 1
Mcast Addr: 239.255.1.1
Source Address List
192.168.4.2
"

Below is the debug information for an ESM IGMP host. Notice the multicast stream is redirected
to the LAG interface and that an MCS entry is installed for the new IGMP group.
debug
router
igmp
host "10.0.0.2"
exit
exit

9 2013/07/03 15:26:32.74 EST MINOR: DEBUG #2001 ies1 IGMP[ies1 inst 9]


"IGMP[ies1 inst 9]: igmpIfGroupAdd
Adding 239.255.1.1 to IGMP host 10.0.0.2 database"
10 2013/07/03 15:26:32.74 EST MINOR: DEBUG #2001 ies1 IGMP[ies1 inst 9]
"IGMP[ies1 inst 9]: igmpProcessGroupRec
Process group rec ALW_NEW_SRCS received on host 10.0.0.2 for group 239.255.1.1 i
n mode INCLUDE. Num srcs 1"
11 2013/07/03 15:26:32.74 EST MINOR: DEBUG #2001 ies1 IGMP[ies1 inst 9]
"IGMP[ies1 inst 9]: igmpIfSrcAdd
Adding i/f source entry for host 10.0.0.2 (192.168.4.2,239.255.1.1) to IGMP fwdList

Page 622

Advanced Configuration Guide

ESM IPv4: Multicast with Redirection

Database, redir if interface lag-redirected [ifIndex 16]"


12 2013/07/03 15:26:32.73 EST MINOR: DEBUG #2001 ies1 IGMP[ies1 inst 9]
"IGMP[ies1 inst 9]: igmpMcsAddIfGroup
Building MCS entry for host 10.0.0.2, group 239.255.1.1"

Below is the debug information for ESM IGMP when MCS sync is enabled. The MCS sends a
sync message for the redirect interface.
debug
router
igmp
mcs "lag-redirected"
exit
exit

20 2013/07/03 15:28:26.20 EST MINOR: DEBUG #2001 ies1 IGMP MCS[9]


"IGMP MCS[9]: TX-MCS Data
interface lag-redirected [ifIndex 16]
Key Type: Group, Len: 9, Grp Addr: 239.255.1.1
Data Type: Group, Len: 20, Ver: 0, RecType: 1, Compat Mode: 3,
Num Fwd Srcs: 1, Num Blk Srcs: 0
Fwd Sources:
192.168.4.2
"
21 2013/07/03 15:28:26.20 EST MINOR: DEBUG #2001 ies1 IGMP MCS[9]
"IGMP MCS[9]: TX-MCS Data
interface lag-redirected [ifIndex 16]
Key Type: Group, Len: 9, Grp Addr: 239.255.1.1
Data Type: Group, Len: 20, Ver: 0, RecType: 1, Compat Mode: 3,
Num Fwd Srcs: 1, Num Blk Srcs: 0
Fwd Sources:
192.168.4.2
"

The corresponding debug information for ESM IGMP MCS sync on BNG-2 looks as follows:
2 2013/07/03 20:30:24.97 UTC MINOR: DEBUG #2001 ies1 IGMP MCS[5]
"IGMP MCS[5]: RX-MCS Data
interface lag-redirected [ifIndex 15]
Key Type: Group, Len: 9, Grp Addr: 239.255.1.1
Data Type: Group, Len: 20, Ver: 0, RecType: 1, Compat Mode: 3,
Num Fwd Srcs: 1, Num Blk Srcs: 0
Fwd Sources:
192.168.4.2
"

Advanced Configuration Guide

Page 623

Configuration

The same debug commands can be used for viewing IGMP leave messages. Below is the debug
information for an ESM IGMP leave at the packet level. The leave report message received over
the subscriber SAP results in the multicast stream being stopped on the redirected interface, after
ensuring no other CPE devices still require the multicast streams (by means of a query).
debug
router
igmp
packet mode egr-ingr-and-dropped
exit
exit

37 2013/07/03 15:32:10.05 EST MINOR: DEBUG #2001 ies1 IGMP[9]


"IGMP[9]: RX-PKT
[001 03:23:17.050] IGMP host 10.0.0.2 V3 PDU: 10.0.0.2 -> 224.0.0.22 pduLen
20
Type: V3 REPORT maxrespCode 0x0 checkSum 0xddf3
Num Group Records: 1
Group Record 0
Type: BLK_OLD_SRCS, AuxDataLen 0, Num Sources 1
Mcast Addr: 239.255.1.1
Source Address List
192.168.4.2
"
38 2013/07/03 15:32:10.05 EST MINOR: DEBUG #2001 ies1 IGMP[9]
"IGMP[9]: TX-PKT
[001 03:23:17.050] IGMP interface lag-redirected [ifIndex 16] V3 PDU: 192.168.10.253
-> 239.255.1.1 pduLen 16
Type: QUERY maxrespCode 0xa checkSum 0xf26d
GroupAddr: 239.255.1.1
S bit 0, QRV 2, Encoded-QQIC 125, NumSources 1
Source Address List:
192.168.4.2
"
39 2013/07/03 15:32:11.36 EST MINOR: DEBUG #2001 ies1 IGMP[9]
"IGMP[9]: TX-PKT
[001 03:23:18.370] IGMP interface lag-redirected [ifIndex 16] V3 PDU: 192.168.10.253
-> 239.255.1.1 pduLen 16
Type: QUERY maxrespCode 0xa checkSum 0xf26d
GroupAddr: 239.255.1.1
S bit 0, QRV 2, Encoded-QQIC 125, NumSources 1
Source Address List:
192.168.4.2
"

Page 624

Advanced Configuration Guide

ESM IPv4: Multicast with Redirection

Below is the debug information for an ESM IGMP host showing various IGMP events. The MCS
also signals the removal of the IGMP entry in the database.
debug
router
igmp
host "192.168.0.10"
exit
exit
44 2013/07/03 15:33:06.00 EST MINOR: DEBUG #2001 ies1 IGMP[ies1 inst 9]
"IGMP[ies1 inst 9]: igmpProcessGroupRec
Process group rec BLK_OLD_SRCS received on host 10.0.0.2 for group 239.255.1.1 i
n mode INCLUDE. Num srcs 1"
45 2013/07/03 15:33:06.00 EST MINOR: DEBUG #2001 ies1 IGMP[ies1 inst 9]
"IGMP[ies1 inst 9]: igmpProcessIfSrcTimerExp
Source Timer expired for IGMP host 10.0.0.2 (192.168.4.2,239.255.1.1)"
46 2013/07/03 15:33:06.00 EST MINOR: DEBUG #2001 ies1 IGMP[ies1 inst 9]
"IGMP[ies1 inst 9]: igmpIfSrcDel
Deleting i/f source entry for host 10.0.0.2 (192.168.4.2,239.255.1.1) from IGMP Data
base. DeleteFromAvl: 1 Redir 0"
47 2013/07/03 15:33:06.00 EST MINOR: DEBUG #2001 ies1 IGMP[ies1 inst 9]
"IGMP[ies1 inst 9]: igmpIfGroupDel
Deleting 239.255.1.1 from IGMP host 10.0.0.2 database"
48 2013/07/03 15:33:05.99 EST MINOR: DEBUG #2001 ies1 IGMP[ies1 inst 9]
"IGMP[ies1 inst 9]: igmpMcsDelIfGroup
Deleting MCS entry for host 10.0.0.2, group 239.255.1.1, Glb"
49 2013/07/03 15:33:05.99 EST MINOR: DEBUG #2001 ies1 IGMP[ies1 inst 9]
"IGMP[ies1 inst 9]: igmpMcsDelIfGroup
Deleting MCS entry for host 10.0.0.2, group 239.255.1.1, Glb"
50 2013/07/03 15:33:06.00 EST MINOR: DEBUG #2001 ies1 IGMP[ies1 inst 9]
"IGMP[ies1 inst 9]: igmpMcsDelIfGroup
Deleting MCS entry for host 10.0.0.2, group 239.255.1.1, Glb"

The debug information when MCS removes the entry on BNG-1 is shown below. Notice MCS
also triggers the backup BNG to remove the multicast stream.
debug
router
igmp
mcs "group-int-1"
exit
exit
69 2013/07/03 15:34:42.43 EST MINOR: DEBUG #2001 ies1 IGMP MCS[9]
"IGMP MCS[9]: TX-MCS Data
interface lag-redirected [ifIndex 16]
Key Type: Group, Len: 9, Grp Addr: 239.255.1.1
Data Type: Group, Len: 20, Ver: 0, RecType: 1, Compat Mode: 3,

Advanced Configuration Guide

Page 625

Configuration

Num Fwd Srcs: 1, Num Blk Srcs: 0


Fwd Sources:
192.168.4.2
"
70 2013/07/03 15:34:42.43 EST MINOR: DEBUG #2001 ies1 IGMP MCS[9]
"IGMP MCS[9]: TX-MCS Data
interface lag-redirected [ifIndex 16]
Key Type: Group, Len: 9, Grp Addr: 239.255.1.1
Data Type: Group, Len: 20, Ver: 0, RecType: 1, Compat Mode: 3,
Num Fwd Srcs: 1, Num Blk Srcs: 0
Fwd Sources:
192.168.4.2
"
71 2013/07/03 15:34:44.36 EST MINOR: DEBUG #2001 ies1 IGMP MCS[9]
"IGMP MCS[9]: TX-MCS Data (GlblDel)
interface lag-redirected [ifIndex 16]
Key Type: Group, Len: 9, Grp Addr: 239.255.1.1
Data Type: Group, Len: 16, Ver: 0, RecType: 1, Compat Mode: 3,
Num Fwd Srcs: 0, Num Blk Srcs: 0
"
72 2013/07/03 15:34:44.37 EST MINOR: DEBUG #2001 ies1 IGMP MCS[9]
"IGMP MCS[9]: TX-MCS Data (GlblDel)
interface lag-redirected [ifIndex 16]
Key Type: Group, Len: 9, Grp Addr: 239.255.1.1
Data Type: Group, Len: 16, Ver: 0, RecType: 1, Compat Mode: 3,
Num Fwd Srcs: 0, Num Blk Srcs: 0
"

The debug information on BNG-2 shows the sync message received over MCS for the removal of
the multicast (S,G).
13 2013/07/03 20:34:44.37 UTC MINOR: DEBUG #2001 ies1 IGMP MCS[5]
"IGMP MCS[5]: RX-MCS Data
interface lag-redirected [ifIndex 15]
Key Type: Group, Len: 9, Grp Addr: 239.255.1.1
Data Type: Group, Len: 20, Ver: 0, RecType: 1, Compat Mode: 3,
Num Fwd Srcs: 1, Num Blk Srcs: 0
Fwd Sources:
192.168.4.2
"

Page 626

Advanced Configuration Guide

ESM IPv4: Multicast with Redirection

Conclusion
Multicast is an essential part of Triple Play Services. The SR 7750 TPSDA solution is much more
than a baseline multicast delivery, it includes individual subscriber awareness and offers a full
state redundancy option. Subscriber awareness allows for fine tuning of subscriber multicast
settings and for troubleshooting on a per subscriber basis. Full state redundancy reduces failover
time and ensures high availability of multicast services. This example provided a complete
configuration walk through of both the IPoE and PPPoE SRRP model with redirection. All
multicast streams can be redirected to a dedicated interface for all subscribers to receive.

Advanced Configuration Guide

Page 627

Conclusion

Page 628

Advanced Configuration Guide

ESM IPv4: Multicast with SRRP

In This Chapter
This section describes ESM IPv4 multicast with SRRP configurations.
Topics in this section include:

Applicability on page 630

Overview on page 631

Configuration on page 633

Conclusion on page 661

Advanced Configuration Guide

Page 629

Applicability

Applicability
This example is applicable to all 7750 SR-12 with IOM3-XP and IMMs, and needs chassis mode c
as a minimum. This is also supported on 7450 ESS chassis in mixed-mode and 7750 SR-c4/12
platform.
The configuration was tested on release 11.0R1 and covers both IPoE and PPPoE subscribers.

Page 630

Advanced Configuration Guide

ESM IPv4: Multicast with SRRP

Overview
Alcatel-Lucents Triple Play Service Delivery Architecture (TPSDA) has allowed operators to
integrate High Speed Internet (HSI), voice, and video services within a single network
infrastructure. The goal of this section is to walk through the configuration of a redundant TPSDA
multicast architecture and the configuration of advanced multicast filters. The topics are divided
into the following sections:

Enhanced Subscriber Management (ESM) multicast baseline configuration


IGMP configuration on ESM group interface
ESM IGMP-policy configuration

PPPoE ESM multicast configuration

IPoE ESM multicast configuration

IGMP Subscriber Router Redundancy Protocol (SRRP)


Multi-Chassis Synchronization (MCS) walkthrough

Advanced ESM IGMP configurations


Filter list

The network topology displayed in Figure 21 shows a typical TPSDA setup. It consists of three
7750s and a single 7450. Two 7750s are configured as Broadband Network Gateways (BNGs) and
the third 7750 is configured as a P router. The 7450 is used as an aggregation switch to aggregate
all subscribers.

Aggregation
Switch (Agg-1)

BNG-1
7750 SR

Multicast
Source
P Router (P-1)

IES
7450

7750 SR
SRRP

IES
Subscribers

BNG-2
7750 SR
IPoE/PPPoE Session
al_0261

Figure 21: Network Topology Overview

Advanced Configuration Guide

Page 631

Overview

Both BNGs are configured with SRRP to provide redundancy. Note that SRRP is only used for
redundancy purposes. SRRP is not mandatory for supporting multicast. The P router is connected
to the multicast source and to the network side of both BNGs. The connections between the BNGs
and the P router are also running PIM to provide multicast delivery. On the access side, the two
BNGs are connected to an aggregation switch which aggregates the traffic originating from both
PPPoE and IPoE subscribers. The BNGs are IGMP capable and will respond to subscribers
IGMP requests.
There are two requirements to enable multicast delivery using ESM. First, the ESM group
interface must have IGMP enabled. Second, the ESM subscribers must be configured with an
IGMP-policy to receive multicast. When both requirements are met, the BNG will process the
subscribers IGMP messages, otherwise, IGMP messages are simply ignored and dropped. All
customer premise device (CPE) IGMP messages are aggregated via the 7450 and passed to the
BNGs. Since the BNGs are running SRRP, the SRRP master is the only BNG processing and
answering the IGMP messages. Protocol Independent Multicasting (PIM) is then used between the
BNG and the P router to request the multicast content. If PIM is successful in retrieving the
multicast group, the multicast stream is forwarded towards the subscribers. This is the typical
multicast delivery model for TPSDA.

Page 632

Advanced Configuration Guide

ESM IPv4: Multicast with SRRP

Configuration
This section expects a basic knowledge of ESM.

ESM SRRP Configuration Overview


Figure 22 shows the addressing scheme used in the setup. The example uses numbered SRRP
subscriber interfaces with static SAPs serving both IPoE and PPPoE subscribers. The
configuration of the RADIUS server is out of the scope of this example.

RADIUS
Server

(Agg-1)
SSRP
10.255.255.254
10.255.255.253
1/1/1

1/1/2

1/1/5

P-1
7750 SR

BNG-1
SDP
192.168.2.0/30

IES

1/1/2

1/1/3

Subscriber

1/1/2

DHCP Local Server


10.1.1.1

1/1/3

192.168.1.0/30
192.168.3.0/30

1/1/5
10.255.255.252

1/1/2

IES

On BNG 1 and 2, Port 1/1/5


VLAN 4 is for Data Path
VLAN 5 is for SRRP Control Packet

BNG-2
SDP

al_0262

Figure 22: Network Topology Used for the Testing

Advanced Configuration Guide

Page 633

Configuration

The baseline configuration for BNG-1 is shown below without any IGMP configuration. The
subscriber-interface is configured in an IES, though it is also possible to configure the subscriberinterface in a VPRN. OSPF and PIM are also provisioned to provide routing and multicast
capabilities. The SRRP configuration with priority 100 ensures BNG-1 is the master when both
BNGs are active as the SRRP priority for BNG-2 is lower.
*A:BNG-1>config>service>ies# info
---------------------------------------------description "BNG-1"
redundant-interface "MClink-BNG-1-BNG-2" create
address 192.168.1.0/31
ip-mtu 1500
spoke-sdp 1:1 create
no shutdown
exit
exit
interface "Int-BNG-1-P-1" create
address 192.168.2.1/30
sap 1/1/2 create
no shutdown
exit
exit
subscriber-interface "sub-int-1" create
address 10.255.255.253/8 gw-ip-address 10.255.255.254 track-srrp 1
group-interface "group-int-1" create
dhcp
server 192.168.0.1
lease-populate 10
client-applications dhcp ppp
gi-address 10.255.255.253
no shutdown
exit
authentication-policy "auth-policy-1"
redundant-interface "MClink-BNG-1-BNG-2"
sap 1/1/5:4 create
sub-sla-mgmt
def-sub-id use-sap-id
def-sub-profile "multicast-profile-1"
def-sla-profile "sla-profile-1"
sub-ident-policy "sub-ident-policy-1"
multi-sub-sap 10
no shutdown
exit
exit
sap 1/1/5:5 create
exit
srrp 1 create
message-path 1/1/5:5
priority 100
no shutdown
exit
pppoe
no shutdown
exit
exit
exit

Page 634

Advanced Configuration Guide

ESM IPv4: Multicast with SRRP

A:BNG-1>config>router# info
ospf
traffic-engineering
area 0.0.0.0
interface "system"
no shutdown
exit
interface "int-BNG-1-BNG-2"
interface-type point-to-point
metric 10000
no shutdown
exit
interface "sub-int-1"
no shutdown
exit
interface "int-BNG-1-P-1"
no shutdown
exit
exit
exit
pim
interface "nt-BNG-1-P-1
exit
no shutdown

The baseline configuration for BNG-2 is shown below without any IGMP configuration. The
default SRRP priority for BNG-2 is lower than the SRRP priority for BNG-1 and hence BNG-2
will be in standby mode.
*A:BNG-2>config>service>ies# info
---------------------------------------------description "BNG-2"
redundant-interface "MClink-BNG-2-BNG-1" create
address 192.168.1.1/31
ip-mtu 1500
spoke-sdp 1:1 create
no shutdown
exit
exit
interface "int-BNG-2-P-1" create
address 192.168.3.1/30
sap 1/1/2 create
no shutdown
exit
exit
subscriber-interface "sub-int-1" create
address 10.255.255.252/8 gw-ip-address 10.255.255.254 track-srrp 1
group-interface "group-int-1" create
dhcp
server 192.168.0.1
lease-populate 10
client-applications dhcp ppp
gi-address 10.255.255.252
no shutdown
exit
authentication-policy "auth-policy-1"
redundant-interface "MClink-BNG-2-BNG-1"

Advanced Configuration Guide

Page 635

Configuration

sap 1/1/5:4 create


sub-sla-mgmt
def-sub-id use-sap-id
def-sub-profile "multicast-profile-1"
def-sla-profile "sla-profile-1"
sub-ident-policy "sub-ident-policy-1"
multi-sub-sap 10
no shutdown
exit
exit
sap 1/1/5:5 create
exit
srrp 1 create
message-path 1/1/5:5
no shutdown
exit
pppoe
no shutdown
exit
exit
exit
*A:BNG-2>config>router# info
ospf
traffic-engineering
area 0.0.0.0
interface "system"
no shutdown
exit
interface "int-BNG-2-BNG-1"
interface-type point-to-point
metric 10000
no shutdown
exit
interface "sub-int-1"
no shutdown
exit
interface "int-BNG-2-P-1"
no shutdown
exit
exit
exit
pim
interface "int-BNG-2-P-1"
exit
no shutdown
exit

Page 636

Advanced Configuration Guide

ESM IPv4: Multicast with SRRP

The baseline configuration for the 7450 aggregation switch is shown below. Two VPLS services
are configured. The first VPLS, VPLS 1, is responsible for passing the SRRP control traffic over
VLAN 5. The second VPLS, VPLS 2, is responsible for passing all subscriber data traffic over
VLAN 4.
*A:Agg-1>config>service>info
vpls 1 customer 1 create
sap 1/1/2:5 create
no shutdown
exit
sap 1/1/3:5 create
no shutdown
exit
no shutdown
exit
vpls 2 customer 1 create
sap 1/1/2:4 create
no shutdown
exit
sap 1/1/3:4 create
no shutdown
exit
sap 1/1/1:4 create
no shutdown
exit
no shutdown
exit

The baseline configuration on the P router is shown below. The P router has a local DHCP server
configured and performs the DHCP address assignment. It is also attached to the multicast source
and uses PIM to deliver multicast streams.
*A:P-1>config>router>info
#-------------------------------------------------echo "Local DHCP Server Configuration"
#-------------------------------------------------dhcp
local-dhcp-server "dhcp-local-server" create
use-gi-address scope pool
pool "pool-1" create
subnet 10.0.0.0/8 create
options
subnet-mask 255.0.0.0
default-router 10.255.255.254
exit
address-range 10.0.0.10 10.0.0.254
exit
exit
no shutdown
exit
exit
#-------------------------------------------------echo "IP Configuration"
#-------------------------------------------------interface "dhcp-lb1"
address 192.168.0.1/32

Advanced Configuration Guide

Page 637

Configuration

loopback
local-dhcp-server "dhcp-local-server
no shutdown
exit
interface "int-P-1-BNG-1"
address 192.168.2.2/30
port 1/1/2
no shutdown
exit
interface "int-P-1-BNG-2"
address 192.168.3.2/30
port 1/1/3
no shutdown
exit
interface "P-1-multicast-source"
address 192.168.4.1/30
port 1/1/1
no shutdown
exit
interface "system"
address 192.0.2.3/32
no shutdown
exit
#-------------------------------------------------ospf
area 0.0.0.0
interface "system"
no shutdown
exit
interface "int-P-1-BNG-1"
no shutdown
exit
interface "int-P-1-BNG-2"
no shutdown
exit
interface "P-1-multicast-source"
no shutdown
exit
exit
exit
pim
interface "int-P-1-BNG-1"
exit
interface "int-P-1-BNG-2"
exit
interface "P-1-multicast-source"
exit
exit

Page 638

Advanced Configuration Guide

ESM IPv4: Multicast with SRRP

Enable IGMP on Group Interfaces


The configuration below adds the group interface to IGMP. If the subscriber-interface is
configured in a VPRN, each VPRN will have its individual IGMP instance. Add the groupinterface to the IGMP instance.
*A:BNG-1>config>router>igmp# info
---------------------------------------------group-interface "group-int-1"
no shutdown
exit

Placing the group-interface into IGMP is the first step required to deliver multicast content. The
options available in this IGMP context can be classified into two categories:
1. Bandwidth and multicast group management
2. Interoperability
[no] disable-router* - Enable/disable the IGMP router alert check option
[no] import
- Import a policy to filter IGMP packets
[no] max-groups
- Configure the maximum number of groups for this
group-interface
[no] max-grp-sources - Configure the maximum number of group sources for this
group-interface
[no] max-sources
- Configure the maximum number of sources for this
group-interface
[no] mcac
+ Configure multicast CAC policy and constraints for this
interface
[no] shutdown
- Administratively enable/disable the interface
[no] sub-hosts-only - Enable/disable the IGMP traffic from known hosts only
[no] subnet-check
- Enable/disable local subnet checking for IGMP
[no] version
- Configure the version of IGMP

The bandwidth and multicast group management options are:

Import Used for white-listing or black-listing multicast groups in the IGMP control
plane. More configuration detail is offered in a later section.

Max-groups Controls the maximum number of groups (channels) allowed on the group
interface.

Max-sources Controls the maximum number of sources of the multicast streams on a


group interface.

Max-grp-sources Specifies the maximum number of multicast group and source pairs
for a group-interface.

MCAC Multicast Connection Admission Control (MCAC) is a bandwidth


management feature to control the amount of multicast content a group interface is
allowed to receive. It can also be applied at subscriber level to offer a hierarchical control.
Multicast bandwidth can be controlled on a per subscriber basis.

Advanced Configuration Guide

Page 639

Configuration

The interoperability options available are:

Router alert enable or disable router alert processing.

Sub-hosts-only Only subscriber originated IGMP messages are accepted and anything
else is ignored. Sometimes, IGMP message might not arrive directly from the subscriber.
For example, an aggregation switch or DSLAM residing between the CPE and the BNG
might perform IGMP proxy. The switch/DSLAM will insert its own source IP-address in
place of the subscriber.
It should be noted that, when an IGMP proxy is used, the identity of the subscriber is lost
(since the original source IP of the IGMP message is replaced).

Subnet-check IGMP messages will be checked against the group interface subnet. All
IGMP messages with a source address that is not in the local subnet are dropped.

Version The RFCs define 3 versions of IGMP, all of them are supported by SROS.
It must be noted that when subscribers are sending IGMPv1 or v2 in a bridged LAN,
suppression of IGMP messages can occur. If an IGMP host detects the presence of another
host reporting for the same multicast group, it will suppress its own IGMP report message
and silently receive the multicast stream. When IGMP messages are suppressed, the BNG
might not be able to account for the real multicast bandwidth consumption of each
subscriber. IGMPv3, on the other hand, forces all hosts to send IGMP reports. This
guarantees that the BNG identifies each subscribers IGMP request.

Page 640

Advanced Configuration Guide

ESM IPv4: Multicast with SRRP

ESM IGMP Policy


In addition to enabling IGMP on the group interface, the subscriber must be allowed to receive
multicast content through an IGMP policy. For this purpose, the IGMP-policy is associated with
the subscribers subscriber-profile. Therefore during authentication, either RADIUS, the local user
database (LUDB), or the default-sub-profile should return a sub-profile with an IGMP policy. The
provisioning requires two steps:
Step 1:

Create the IGMP policy.

*A:BNG-1> config subscr-mgmt


igmp-policy "igmp-policy-1" create
exit

Step 2:

Add the IGMP policy to a subscriber-profile.

*A:BNG-1> config subscr-mgmt


sub-prof "multicast-profile-1"
igmp-policy "igmp-policy-1"

The above configuration is the minimum requirement for a subscriber to receive multicast
streams. The different options inside an IGMP policy are:
[no]
[no]
[no]
[no]
[no]
[no]
[no]
[no]
[no]
[no]

description
egress-rate-mo*
fast-leave
import
max-num-groups
max-num-grp-so*
max-num-sources
mcast-reporting
per-host-repli*
redirection-po*
static
[no] version

+
+
-

Description for the IGMP policy


Configure the egress rate modification
Enable/disable IGMP fast-leave processing
Specify the import policy to filter IGMP packets
Configure the max number of multicast groups
Configure the max number of multicast group sources
Configure the max number of multicast sources
Configure the mcast reporting
Enable/disable IGMP per-host-replication processing
Specify the IGMP redirection policy
Add/remove IGMP static group membership
Configure the version of IGMP

Again, two groups of options are available: the bandwidth and multicast group management
options, and the interoperability options.
Bandwidth and multicast group management options:

Import Used for white-listing and black-listing multicast groups. This allows the
import policy to be defined per subscriber.

Max-num-group Limits the maximum multicast groups for the group interface. This
limits the groups per subscriber.

Max-num-sources Limits the maximum multicast sources for the group interface. This
limits the sources per subscriber.

Advanced Configuration Guide

Page 641

Configuration

Max-num-grp-sources Limits the maximum multicast group and source pairs for the
group interface.

Egress-rate-modify This feature adjusts the subscriber queue bandwidth according to


multicast consumption. It is used in conjunction with MCAC. An MCAC policy defines
the bandwidth consumption per multicast group. As a subscriber joins a multicast group,
the bandwidth of the multicast channel is subtracted from the subscriber queue bandwidth.
The remaining bandwidth is what the subscriber can use for all other services.

Interoperability options:

Fast-leave Enables the router to withdraw the multicast group quickly when receiving
an IGMP leave message without any last query. This should be used in a subscriber per
SAP (dot1q or qinq) model.

Static This allows the provisioning of static multicast groups that the subscriber will
receive regardless of any IGMP report. The static multicast group can be Source Specific
Multicast (SSM) based.

Per-host-replication SR OS has the capability to replicate a multicast source per


subscriber. For example, if 10 subscribers are requesting the same multicast group, then
10 multicast streams are replicated and delivered individually to each subscriber. PPPoE
requires service delivery to be point to point. To achieve this, the Ethernet header
destination address is the subscribers source MAC. The IP layer destination remains as
the multicast group that the subscriber requested. For IPoE, without per-host replication,
the standard multicast MAC representing the multicast group is used as the destination
MAC address when delivering the multicast content to the subscribers. When per-host
replication is used for IPoE subscribers, the destination MAC address will be the hosts
own MAC address and the IP destination will remain as the multicast group that the
subscriber is interested in. The multicast content is then delivered to the subscriber via
MAC learning as a unicast stream.
It should be noted that when per-host-replication is enabled, all multicast content will be
using the subscriber queues. It is no longer necessary to use egress-rate-modify as
mentioned above.

Page 642

Redirection-policy Another popular model for multicast deployment is to redirect all


multicast content to another interface instead of sending the content directly to the
subscriber. All subscribers use a common VLAN to receive the multicast content.

Advanced Configuration Guide

ESM IPv4: Multicast with SRRP

ESM IGMP IPoE Walkthrough


With the baseline configuration applied, the BNG is ready to process IGMP messages and deliver
multicast. Figure 23 shows a flow for IPoE subscribers requesting and receiving multicast traffic.
The key items are highlighted in dotted box:
1. The ESM group-interface must have IGMP enabled
2. The subscriber must be associated with an IGMP-policy via sub-profile.
The subscriber sends an IGMPv3 report using (192.168.4.2, 239.255.1.1).
SRRP State:
Master
IES
Subscriber

BNG-1

Agg-1

IGMPv3 Report
grp: 239.1.255.1
src-lp: 192.168.4.2

P-1

Multicast Server

IPoE Subscriber

Must have
1) IGMP Configured Group Interface
2) Subscriber Must Have IGMP-Policy
PIM Join
(192.168.4.2.239.255.1.1)
PIM Join
(192.168.4.2.239.255.1.1)

Multicast Packet:
Eth 01:00:5e:ff:01:01
IP 239.255.1.1

Multicast Packet:
Eth 01:00:5e:ff:01:01
IP 239.255.1.1

Multicast Packet:
Eth 01:00:5e:ff:01:01
IP 239.255.1.1

Multicast Packet:
Eth 01:00:5e:ff:01:01
IP 239.255.1.1

al_0263

Figure 23: IPoE Subscriber Multicast Flow

To verify that the group interface is ready for multicast, use the show command as indicated
below. Remember that the IES service id is 1 and the group-interface name is group-int-1.
Step 1:

Verify if the group-interface has IGMP enabled.

*A:BNG-1> show router igmp group-interface


===============================================================================
IGMP Group-Interfaces
===============================================================================

Advanced Configuration Guide

Page 643

Configuration

FwdSvc Group-Interface
Adm/Opr-State
Import-Policy
SAP
Adm/Opr-Version
Num-Groups
------------------------------------------------------------------------------1
group-int-1
Up/Up
none
1/1/5:4
3/3
0
------------------------------------------------------------------------------Group-Interfaces = 1, SAPs = 1
===============================================================================

Step 2:

Ensure the subscriber is associated with an IGMP-policy. Since the IGMP-policy is


associated with a subscriber-profile, verifying the IGMP-policy is achieved via subprofile.

*A:BNG-1> show subscriber-mgmt sub-profile "multicast-profile-1"


===============================================================================
Subscriber Profile multicast-profile-1
===============================================================================
Description
: (Not Specified)
I. Sched. Policy : N/A
E. Sched. Policy : N/A
E. Agg Rate Limit: Max
I. Policer Ctrl. : N/A
E. Policer Ctrl. : N/A
Q Frame-Based Ac*: Disabled
Acct. Policy
: N/A
Collect Stats
: Disabled
Rad. Acct. Pol. : N/A
Dupl. Acct. Pol. : N/A
ANCP Pol.
: N/A
HostTrk Pol.
: N/A
IGMP Policy
: igmp-policy-1
Sub. MCAC Policy : N/A
NAT Policy
: N/A
Def. Encap Offset: none
Encap Offset Mode: none
Avg Frame Size
: N/A
Preference
: 5
------------------------------------------------------------------------------HSMDA-2
------------------------------------------------------------------------------I. Qos Policy
: 1
E. Qos Policy
: 1
E. Agg Rate Limit: Max
E. WRR Policy
: N/A
Pkt Byte Offset : add 0*
------------------------------------------------------------------------------Last Mgmt Change : 05/14/2013 10:12:49
===============================================================================
* indicates that the corresponding row element may have been truncated.

After the verification, the BNGs are ready to deliver multicast content.
First, initiate an IGMP report from a subscriber requesting a multicast channel. In this example,
IGMPv3 SSM is used. IPoE by default replicates per-SAP. If the IGMP message was successfully
received and processed, an (S,G) binding will be associated with the subscriber SAP.
In this case, the IGMPv3 SSM message requests (192.168.4.2, 239.255.1.1). The subscriber host
is assigned an IP address of 10.0.0.24. To verify the IGMP message was successfully processed,
check that the (S,G) is learned on the IGMP instance. The example below shows a successful
IGMP message processed by the BNG, the (S,G) is registered against the subscriber SAP.

Page 644

Advanced Configuration Guide

ESM IPv4: Multicast with SRRP

*A:BNG-1> show router igmp group


===============================================================================
IGMP Interface Groups
===============================================================================
===============================================================================
IGMP Host Groups
===============================================================================
===============================================================================
IGMP SAP Groups
===============================================================================
(192.168.4.2,239.255.1.1)
Fwd List : 1/1/5:4
Up Time : 0d 00:00:08
------------------------------------------------------------------------------(*,G)/(S,G) Entries : 1
===============================================================================

For more IGMP details on the group interface, including maximum multicast groups and
bandwidth management, use the following command:
*A:BNG-1> show router igmp group-interface detail
===============================================================================
IGMP Group-Interfaces
===============================================================================
FwdSvc/Grp-Intf
: 1/group-int-1
Admin-Status
: Up
Oper-Status
: Up
Import-Policy
: none
Subnet-Check
: Disabled
Router-Alert-Check : Enabled
Sub-Hosts-Only
: Disabled
MCAC Policy Name
:
MCAC Const Adm St : Enable
MCAC Max Unconst BW: no limit
MCAC Max Mand BW
: no limit
MCAC In use Mand BW: 0
MCAC Avail Mand BW : unlimited
MCAC In use Opnl BW: 0
MCAC Avail Opnl BW : unlimited
------------------------------------------------------------------------------SAP
: 1/1/5:4
Admin/Oper version: 3/3
Num Groups
: 1
Max Groups Allowed: No Limit
Max Groups Till Now: 1
Max Sources Allow*: No Limit
Max Grp Srcs Allo*: No Limit
------------------------------------------------------------------------------Group-Address
: 239.255.1.1
Up Time
: 0d 00:04:05
Expires
: N/A
Mode
: include
V1 Host Timer
: Not running
Type
: dynamic
V2 Host Timer
: Not running
Compat Mode
: IGMP Version 3
-----------------------------------------------------------------GrpSrc-Address
Expires
Type
Fwd/Blk
-----------------------------------------------------------------192.168.4.2
0d 00:03:50
dynamic
Fwd
------------------------------------------------------------------------------Group-Interfaces = 1, SAPs = 1
===============================================================================
* indicates that the corresponding row element may have been truncated.

If the subscriber fails to receive multicast traffic, check if the subscriber has an associated IGMP
policy with the following command. If the subscriber entry is missing, make sure the subscriber
has a sub-profile that is tied to an IGMP-policy.

Advanced Configuration Guide

Page 645

Configuration

*A:BNG-1> show service active-subscribers igmp detail


===============================================================================
Active Subscribers Detail
===============================================================================
Subscriber
IGMP-Policy
HostAddr
GrpItf
NumGroups
GrpAddr
Type
Up-Time
Mode
SrcAddr
Type
Blk/Fwd
------------------------------------------------------------------------------Subscriber-1
igmp-policy-1
------------------------------------------------------------------------------Number of Subscribers : 1

Another possibility for failing to receive multicast traffic could be due to the control mechanisms
inside the IGMP-policy such as: bandwidth control, multicast groups restrictions, and
interoperability options. Use the following command to view the IGMP policy configured control
parameters.
*A:BNG-1> show subscriber-mgmt igmp-policy "igmp-policy-1"
===============================================================================
IGMP Policy igmp-policy-1
===============================================================================
Import Policy
:
Admin Version
: 3
Num Subscribers
: 0
Host Max Group
: No Limit
Host Max Sources
: No Limit
Host Max Group Sources
: No Limit
Fast Leave
: yes
Redirection Policy
:
Per Host Replication
: no
Egress Rate Modify
: no
Mcast Reporting Destination Name
:
Mcast Reporting Admin State
: Disabled
===============================================================================

Below is a command to view the (S,G)s that all subscribers are requesting. Since the system has
only one subscriber, this example only shows one host.
*A:BNG-1> show router igmp hosts detail
===============================================================================
IGMP Host 10.0.0.24
===============================================================================
Oper Status
: Up
MacAddress
: 00:00:10:10:10:11
Oper version
: 3
Subscriber
: Subscriber-1
Num Groups
: 1
GrpItf
: group-int-1
Max Grps Till Now: 1
IGMP-Policy
: igmp-policy-1
PPPoE SessionId : N/A
Next query time: 0d 00:01:52
FwdSvcId
: 1
Max Srcs Allow*: No Limit
Max Grps Allowed : No Limit
Max Grp Srcs A*: No Limit
------------------------------------------------------------------------------IGMP Group
------------------------------------------------------------------------------Group Address
: 239.255.1.1
Up Time
: 0d 00:02:46
Expires
: Not running
Mode
: Include

Page 646

Advanced Configuration Guide

ESM IPv4: Multicast with SRRP

V1 Host Timer
: Not running
Type
: Dynamic
V2 Host Timer
: Not running
Compat Mode: IGMP Version 3
Redir.SvcId
: N/A
Redir.Intf : N/A
----------------------------------------------------------Source Address
Expires
Type
Fwd/Blk
----------------------------------------------------------192.168.4.2
0d 00:04:09
Dynamic
Fwd
------------------------------------------------------------------------------Hosts : 1

To check for an individual subscriber and its requested (S,G)s, the following command can be
used.
*A:BNG-1> show service active-subscribers igmp subscriber "Subscriber-2" detail
===============================================================================
Active Subscribers Detail
===============================================================================
Subscriber
IGMP-Policy
HostAddr
GrpItf
NumGroups
GrpAddr
Type
Up-Time
Mode
SrcAddr
Type
Blk/Fwd
------------------------------------------------------------------------------Subscriber-1
igmp-policy-1
10.0.0.24
group-int-1
1
239.255.1.1
Dynamic
0d 00:01:26
Include
192.168.4.2
Dynamic
Fwd
------------------------------------------------------------------------------Number of Subscribers : 1
===============================================================================

Advanced Configuration Guide

Page 647

Configuration

ESM IGMP PPPoE Walkthrough


IGMP message processing and delivery of multicast content for PPPoE subscribers is considered
next. Figure 24 shows the message flow for multicast content delivery to PPPoE subscribers.
SRRP State:
Master
IES
Subscriber

Agg-1

P-1

BNG-1

Multicast Server

PPPoE Subscriber Created


Src MAC: 00:00:00:00:00:01

IGMPv3 Report
grp: 239.255.1.1
src-lp: 192.168.4.2

Must have
1) IGMP Configured Group Interface
2) Subscriber Must Have IGMP-Policy
PIM Join
(192.168.4.2.239.255.1.1)
PIM Join
(192.168.4.2.239.255.1.1)

Unicast Packet:
Eth 00:00:00:00:00:01
IP 239.255.1.1

Unicast Packet:
Eth 00:00:00:00:00:01
IP 239.255.1.1

Multicast Packet:
Eth 01:00:5e:ff:01:01
IP 239.255.1.1

Multicast Packet:
Eth 01:00:5e:ff:01:01
IP 239.255.1.1

al_0264

Figure 24: PPPoE Multicast Flow

As stated earlier, the important configuration aspects are highlighted in the dotted box. The main
difference between IPoE subscribers and PPPoE subscribers is the multicast data path. PPPoE
subscribers receive multicast content via Ethernet unicast while IPoE subscribers receive multicast
content via Ethernet multicast. PPPoE natively does not have a multicast mechanism and requires
all data traffic to be unicasted. Even if the subscribers are on the same SAP, multicast content is
replicated per subscriber. To achieve this, the IP header indicates a multicast address while the
Ethernet header destination MAC address is changed to the subscribers MAC address.
Step 1:

Verify the group interface. It is very similar to the output for the IPoE group
interface.

*A:BNG-1> show router igmp group-interface detail


===============================================================================
IGMP Group-Interfaces

Page 648

Advanced Configuration Guide

ESM IPv4: Multicast with SRRP

===============================================================================
FwdSvc/Grp-Intf
: 1/group-int-1
Admin-Status
: Up
Oper-Status
: Up
Import-Policy
: none
Subnet-Check
: Enabled
Router-Alert-Check : Enabled
Sub-Hosts-Only
: Enabled
MCAC Policy Name
:
MCAC Const Adm St : Enable
MCAC Max Unconst BW: no limit
MCAC Max Mand BW
: no limit
MCAC In use Mand BW: 0
MCAC Avail Mand BW : unlimited
MCAC In use Opnl BW: 0
MCAC Avail Opnl BW : unlimited
------------------------------------------------------------------------------SAP
: 1/1/5:4
Admin/Oper version: 3/3
Num Groups
: 0
Max Groups Allowed: No Limit
Max Groups Till Now: 0
Max Sources Allow*: No Limit
Max Grp Srcs Allo*: No Limit
------------------------------------------------------------------------------Group-Interfaces = 1, SAPs = 1
===============================================================================
* indicates that the corresponding row element may have been truncated.

Next an IGMPv3 message is sent towards the BNG. The (S,G) is (192.168.4.2, 239.255.1.1). The
PPPoE subscriber is assigned an IP address of 10.0.0.12.
The output below shows the key difference between a PPPoE subscriber and an IPoE subscriber.
PPPoE multicast content is replicated per host and not per SAP. This output shows this clearly as
the multicast group is associated with the host and not with the SAP.
*A:BNG-1> show router igmp group
===============================================================================
IGMP Interface Groups
===============================================================================
===============================================================================
IGMP Host Groups
===============================================================================
(192.168.4.2,239.255.1.1)
Fwd List : 10.0.0.12
Up Time : 0d 17:19:08
===============================================================================
IGMP SAP Groups
===============================================================================
------------------------------------------------------------------------------(*,G)/(S,G) Entries : 1
===============================================================================

The next command shows all of the subscribers and all the (S,G)s joined. In this case there is only
one PPPoE subscriber.
*A:BNG-1> show router igmp hosts detail
===============================================================================
IGMP Host 10.0.0.12
===============================================================================
Oper Status
: Up
MacAddress
: 52:e0:50:bd:00:00
Oper version
: 3
Subscriber
: User-ppp-1
Num Groups
: 1
GrpItf
: group-int-1
Max Grps Till Now: 1
IGMP-Policy
: igmp-policy-1
PPPoE SessionId : 1
Next query time: 0d 00:01:47

Advanced Configuration Guide

Page 649

Configuration

FwdSvcId
: 1
Max Grps Allowed : No Limit

Max Srcs Allow*: No Limit


Max Grp Srcs A*: No Limit

------------------------------------------------------------------------------IGMP Group
------------------------------------------------------------------------------Group Address
: 239.255.1.1
Up Time
: 0d 00:00:36
Expires
: Not running
Mode
: Include
V1 Host Timer
: Not running
Type
: Dynamic
V2 Host Timer
: Not running
Compat Mode: IGMP Version 3
Redir.SvcId
: N/A
Redir.Intf : N/A
----------------------------------------------------------Source Address
Expires
Type
Fwd/Blk
----------------------------------------------------------192.168.4.2
0d 00:04:03
Dynamic
Fwd
------------------------------------------------------------------------------Hosts : 1
===============================================================================
* indicates that the corresponding row element may have been truncated.

To view each individual subscriber and their respective (S,G)s, use the command below.
*A:BNG-1> show service active-subscribers igmp subscriber "user02" detail
===============================================================================
Active Subscribers Detail
===============================================================================
Subscriber
IGMP-Policy
HostAddr
GrpItf
NumGroups
GrpAddr
Type
Up-Time
Mode
SrcAddr
Type
Blk/Fwd
------------------------------------------------------------------------------User-ppp-1
igmp-policy-1
10.0.0.12
group-int-1
1
239.255.1.1
Dynamic
0d 00:02:07
Include
192.168.4.2
Dynamic
Fwd
------------------------------------------------------------------------------Number of Subscribers : 1
===============================================================================

Page 650

Advanced Configuration Guide

ESM IPv4: Multicast with SRRP

ESM IGMP MCS


The BNGs are configured with SRRP for both IPoE and PPPoE subscribers. This provides stateful
redundancy when the master BNG fails. The master BNG will be the only one processing and
answering IGMP messages. The standby BNG does not perform any IGMP processing and
receives updates through MCS for all subscribers in real time. In the event of a failure, the standby
will become active and starts processing all IGMP messages. The standby will also immediately
trigger PIM joins for all of the subscriberss (S,G)s. This is all possible because the standby is
always synchronized with the master BNG prior to the failover. Restoration of all multicast
channels should happen quickly after the failover and depends on both the PIM configuration and
the underlying routing infrastructure.
The key parameters for MCS for ESM multicast are: syncing of subscribers (ipoe, pppoe), SRRP
and IGMP. Below is the redundancy configuration for BNG-1 and BNG-2.
*A:BNG-1>config>redundancy# info
---------------------------------------------multi-chassis
peer 192.0.2.2 create
sync
igmp
srrp
sub-mgmt ipoe pppoe
port 1/1/5 create
range 4-4 sync-tag "sub"
range 5-5 sync-tag "srrp"
exit
no shutdown
exit
no shutdown
exit
exit

The following command displays the number of entries being synced across the BNGs.
*A:BNG-1> show redundancy multi-chassis sync peer 192.0.2.2 detail
===============================================================================
Multi-chassis Peer Table
===============================================================================
Peer
------------------------------------------------------------------------------Peer IP Address
: 192.0.2.2
Description
: (Not Specified)
Authentication
: Disabled
Source IP Address
: 192.0.2.1
Admin State
: Enabled
------------------------------------------------------------------------------Sync-status
------------------------------------------------------------------------------Client Applications
: IGMP SUBMGMT-IPOE SUBMGMT-PPPOE SRRP
Sync Admin State
: Up
Sync Oper State
: Up

Advanced Configuration Guide

Page 651

Configuration

DB Sync State
: inSync
Num Entries
: 15
Lcl Deleted Entries
: 0
Alarm Entries
: 0
Rem Num Entries
: 15
Rem Lcl Deleted Entries : 0
Rem Alarm Entries
: 0
===============================================================================
MCS Application Stats
===============================================================================
Application
: igmp
Num Entries
: 1
Lcl Deleted Entries
: 0
Alarm Entries
: 0
------------------------------------------------------------------------------Rem Num Entries
: 1
Rem Lcl Deleted Entries : 0
Rem Alarm Entries
: 0
------------------------------------------------------------------------------Application
: subMgmtIpoe
Num Entries
: 1
Lcl Deleted Entries
: 0
Alarm Entries
: 0
------------------------------------------------------------------------------Rem Num Entries
: 1
Rem Lcl Deleted Entries : 0
Rem Alarm Entries
: 0
------------------------------------------------------------------------------Application
: srrp
Num Entries
: 14
Lcl Deleted Entries
: 0
Alarm Entries
: 0
------------------------------------------------------------------------------Rem Num Entries
: 14
Rem Lcl Deleted Entries : 0
Rem Alarm Entries
: 0
------------------------------------------------------------------------------Application
: subMgmtPppoe
Num Entries
: 1
Lcl Deleted Entries
: 0
Alarm Entries
: 0
------------------------------------------------------------------------------Rem Num Entries
: 1
Rem Lcl Deleted Entries : 0
Rem Alarm Entries
: 0
------------------------------------------------------------------------------===============================================================================

Page 652

Advanced Configuration Guide

ESM IPv4: Multicast with SRRP

To check the details of the synchronized data across the BNGs, use the command below. It
provides a detailed description of the IGMP information synced across MCS.
*A:BNG-1> tools dump redundancy multi-chassis sync-database application igmp detail
If no entries are present for an application, no detail will be displayed.
FLAGS LEGEND: ld - local delete; da - delete alarm; pd - pending global delete
Peer Ip 192.0.2.2

Application IGMP
Sap-id
Client Key
SyncTag
DLen Flags
timeStamp
deleteReason code and description
------------------------------------------------------------------------------1/1/5:4
Host=10.0.0.10, HostGroup=239.255.1.1
sub
20
-- -- -- 05/23/2013 13:05:31
0x0
The following totals are for:
peer ip ALL, port/lag ALL, sync-tag ALL, application IGMP
Valid Entries:
1
Locally Deleted Entries:
0
Locally Deleted Alarmed Entries: 0
Pending Global Delete Entries:
0

Advanced Configuration Guide

Page 653

Configuration

ESM IGMP Debug


There are many debug features for ESM multicast. Debug allows real-time monitoring of all
events happening on the system and can assist operators with troubleshooting. First enable debug
on the system, then send an IGMP message to join a multicast group (S,G). Again the IGMP
message used in this case is IGMPv3 with SSM. Below is the debug information for ESM IGMP
at packet level.
debug
router
igmp
packet mode egr-ingr-and-dropped
exit
exit
2977 2013/05/23 13:01:45.43 EST MINOR: DEBUG #2001 IGMP[9]
"IGMP[9]: RX-PKT
[012 03:58:58.090] IGMP host 10.0.0.10 V3 PDU: 10.0.0.10 -> 224.0.0.22 pduLen
20
Type: V3 REPORT maxrespCode 0x0 checkSum 0xddf7
Num Group Records: 1
Group Record 0
Type: ALW_NEW_SRCS, AuxDataLen 0, Num Sources 1
Mcast Addr: 239.255.1.1
Source Address List
192.168.4.2
"

Below is the debug information for ESM IGMP at host level and the associated IGMP events.
debug
router
igmp
host "10.0.0.10"
exit
exit
2978 2013/05/23 13:01:45.43 EST MINOR: DEBUG #2001 ies1 IGMP[ies1 inst 9
]
"IGMP[ies1 inst 9]: igmpIfGroupAdd
Adding 239.255.1.1 to IGMP host 10.0.0.10 database"
2979 2013/05/23 13:01:45.43 EST MINOR: DEBUG #2001 ies1 IGMP[ies1 inst 9
]
"IGMP[ies1 inst 9]: igmpProcessGroupRec
Process group rec ALW_NEW_SRCS received on host 10.0.0.10 for group 239.255.1.1 i
n mode INCLUDE. Num srcs 1"
2980 2013/05/23 13:01:45.43 EST MINOR: DEBUG #2001 ies1 IGMP[ies1 inst 9
]
"IGMP[ies1 inst 9]: igmpIfSrcAdd
Adding i/f source entry for host 10.0.0.10 (192.168.4.2,239.255.1.1) to IGMP fwdList
Database, redir if N/A"

Page 654

Advanced Configuration Guide

ESM IPv4: Multicast with SRRP

Below is the debug information for ESM IGMP if MCS synchronization is enabled.
debug
router
igmp
mcs "group-int-1"
exit
exit

2981 2013/05/23 13:01:45.44 EST MINOR: DEBUG #2001 ies1 IGMP[ies1 inst 9
]
"IGMP[ies1 inst 9]: igmpMcsAddIfGroup
Building MCS entry for host 10.0.0.10, group 239.255.1.1"

The same debug commands can be used for viewing subscribers IGMP leave messages. Below is
the debug information for ESM IGMP at packet level.
debug
router
igmp
packet mode egr-ingr-and-dropped
exit
exit
2982 2013/05/23 13:02:23.75 EST MINOR: DEBUG #2001 ies1 IGMP[9]
"IGMP[9]: RX-PKT
[012 03:59:36.410] IGMP host 10.0.0.10 V3 PDU: 10.0.0.10 -> 224.0.0.22 pduLen
20
Type: V3 REPORT maxrespCode 0x0 checkSum 0xdcf7
Num Group Records: 1
Group Record 0
Type: BLK_OLD_SRCS, AuxDataLen 0, Num Sources 1
Mcast Addr: 239.255.1.1
Source Address List
192.168.4.2

Below is the debug information for ESM IGMP at host level and the associated IGMP events.
debug
router
igmp
host "10.0.0.10"
exit
exit
2983 2013/05/23 13:02:23.75 EST MINOR: DEBUG #2001 ies1 IGMP[ies1 inst 9
]
"IGMP[ies1 inst 9]: igmpProcessGroupRec
Process group rec BLK_OLD_SRCS received on host 10.0.0.10 for group 239.255.1.1 i
n mode INCLUDE. Num srcs 1"
2984 2013/05/23 13:02:23.75 EST MINOR: DEBUG #2001 ies1 IGMP[ies1 inst 9
]
"IGMP[ies1 inst 9]: igmpProcessIfSrcTimerExp

Advanced Configuration Guide

Page 655

Configuration

Source Timer expired for IGMP host 10.0.0.10 (192.168.4.2,239.255.1.1)"


2985 2013/05/23 13:02:23.75 EST MINOR: DEBUG #2001 ies1 IGMP[ies1 inst 9
]
"IGMP[ies1 inst 9]: igmpIfSrcDel
Deleting i/f source entry for host 10.0.0.10 (192.168.4.2,239.255.1.1) from IGMP Dat
abase. DeleteFromAvl: 1 !Redir 0"
2986 2013/05/23 13:02:23.75 EST MINOR: DEBUG #2001 ies1 IGMP[ies1 inst 9
]
"IGMP[ies1 inst 9]: igmpIfGroupDel
Deleting 239.255.1.1 from IGMP host 10.0.0.10 database"

The debug information when MCS removes the entry on the standby BNG is shown below.
debug
router
igmp
mcs "group-int-1"
exit
exit
2987 2013/05/23 13:02:23.75 EST MINOR: DEBUG #2001 ies1 IGMP[ies1 inst 9
]
"IGMP[ies1 inst 9]: igmpMcsDelIfGroup
Deleting MCS entry for host 10.0.0.10, group 239.255.1.1, Glb"
2988 2013/05/23 13:02:23.75 EST MINOR: DEBUG #2001 ies1 IGMP[ies1 inst 9
]
"IGMP[ies1 inst 9]: igmpMcsDelIfGroup
Deleting MCS entry for host 10.0.0.10, group 239.255.1.1, Glb"
2989 2013/05/23 13:02:23.75 EST MINOR: DEBUG #2001 ies1 IGMP[ies1 inst 9
]
"IGMP[ies1 inst 9]: igmpMcsDelIfGroup
Deleting MCS entry for host 10.0.0.10, group 239.255.1.1, Glb"

Page 656

Advanced Configuration Guide

ESM IPv4: Multicast with SRRP

IGMP Control Plane Filters


IGMP control plane filtering can be applied at the router level and/or subscriber level (IGMPpolicy). The filter list contains multicast groups (S,G) and is provisioned at the router level in the
policy-options context. The filter can be applied either as a black-list or a white-list.
Step 1:

Provision a prefix list for the multicast group (G). The configuration below is an
example showing the various options possible for the prefix list. The only one used
in this configuration is the prefix 239.255.1.1/32.

*A:BNG-1> config>router>policy-options#
prefix-list "igmp-prefix-list-1"
prefix 239.255.1.1/32 exact
prefix 239.255.2.0/24 longer
prefix 239.255.3.0/24 prefix-length-range 24-25
prefix 239.255.4.0/24 through 25
exit

Step 2a:

Option 1 white-list, used below.

Provision a router policy. In the example below a white-list is configured, allowing only the prefix
list specified and reject everything else. Source-address configuration is also possible for IGMP
v3 (S,G).
*A:BNG-1> config>router>policy-options#
policy-statement "igmp-white-list-1"
entry 10
from
group-address "igmp-prefix-list-1"
source-address 192.168.4.2
exit
action accept
exit
exit
default-action reject
exit

Step 2b:

Option 2 black-list, not used below.

Provision a router policy. Here, a black-list is configured, denying the prefix list and accepting
everything else. Again, source-address configuration is also possible for IGMP v3 (S,G).
*A:BNG-1> config>router>policy-options#
policy-statement "igmp-black-list-1"
entry 10
from
group-address "igmp-prefix-list-1"
source-address 192.168.4.2
exit
action reject
exit
exit
default-action accept

Advanced Configuration Guide

Page 657

Configuration

exit

Step 3a:

Hierarchical filter, group-interface.

The filter can be applied in two places. First, at router/group-interface level, this will apply to all
subscribers connected to the group interface.
*A:BNG-1> config>router
igmp
group-interface "group-int-1"
import "igmp-white-list-1"
no shutdown
exit
no shutdown
exit

Step 3b:

Hierarchical filter, subscriber level.

The group-interface filter takes precedence over the subscriber level filter. After the groupinterface applies its filter against the incoming IGMP messages, the individual subscriber defined
IGMP filters will be applied to the remaining IGMP messages.
*A:BNG-1> config>subscr-mgmt>igmp-policy# info
---------------------------------------------import "igmp-white-list-1"

Use the debug command to verify that the policy is performing correctly for the host. Note that
group 239.255.1.2 is not in the white-list and so is dropped.
debug
router
igmp
group-interface "group-int-1"
host "10.0.0.10"
packet mode egr-ingr-and-dropped
mcs
exit
exit

3310 2013/05/23 14:51:55.69 EST MINOR: DEBUG #2001 ies1 IGMP[9]


"IGMP[9]: RX-PKT
[012 05:49:08.350] IGMP host 10.0.0.10 V3 PDU: 10.0.0.10 -> 224.0.0.22 pduLen
20
Type: V3 REPORT maxrespCode 0x0 checkSum 0xe1f6
Num Group Records: 1
Group Record 0
Type: MODE_IS_INCL, AuxDataLen 0, Num Sources 1
Mcast Addr: 239.255.1.2
Source Address List
192.168.4.2
"
3311 2013/05/23 14:51:55.69 EST MINOR: DEBUG #2001 ies1 IGMP[ies1 inst 9

Page 658

Advanced Configuration Guide

ESM IPv4: Multicast with SRRP

]
"IGMP[ies1 inst 9]: igmpParseV3Report
IGMP V3 policy DROP on host 10.0.0.10, from host 10.0.0.10, grpAddr 239.255.1.2,
srcAddr 192.168.4.2"

Advanced Configuration Guide

Page 659

Configuration

IGMP Data Plane Filters


IGMP data plane filter utilize the ip-filter defined in the sla-profile. Again the filter can be used as
a black-list or a white-list.
Step 1:

Configure an ip-filter. Below is an example of a black-list filter.

*A:BNG-1> config>filter>ip-filter$ info


---------------------------------------------default-action forward
entry 1 create
match
dst-ip 239.255.1.1/32
exit
action drop
exit

Step 2:

Apply the configured ip filter into an sla-profile. Since multicast content is sent
towards the subscriber, it is applied to the sla-profile egress.

*A:BNG-1> config>subscr-mgmt>sla-prof# info


---------------------------------------------egress
ip-filter 1
exit
exit
----------------------------------------------

To view the statistics of the filter applied to the subscribers use the following command.
*A:BNG-1> show filter ip 1 counters
===============================================================================
IP Filter
===============================================================================
Filter Id
: 1
Applied
: Yes
Scope
: Template
Def. Action
: Forward
Radius Ins Pt: n/a
CrCtl. Ins Pt: n/a
RadSh. Ins Pt: n/a
Entries
: 1
Description : (Not Specified)
------------------------------------------------------------------------------Filter Match Criteria : IP
------------------------------------------------------------------------------Entry
: 1
Ing. Matches : 0 pkts
Egr. Matches : 0 pkts
===============================================================================

Page 660

Advanced Configuration Guide

ESM IPv4: Multicast with SRRP

Conclusion
Multicast is an essential part of Triple Play Services. The SR 7750 TPSDA solution offers much
more than a baseline multicast delivery, it includes individual subscriber awareness and a full state
redundancy option. Subscriber awareness allows for the fine tuning of each subscribers multicast
experience and also for troubleshooting on a per subscriber basis. Full state redundancy reduces
failover time and ensures high availability of the services offered. This example provides a
complete configuration walkthrough of both the IPoE and PPPoE SRRP models.
For operators wanting to further control and restrict individual subscribers multicast content,
ESM has a comprehensive set of both control path filtering and data path filtering.

Advanced Configuration Guide

Page 661

Conclusion

Page 662

Advanced Configuration Guide

ESMv6: IPoE Dual Stack Hosts

In This Chapter
This section describes IPoE dual stack hosts for ESMv6 configurations.
Topics in this section include:

Applicability on page 664

Summary on page 665

Overview on page 666

Configuration on page 674

Conclusion on page 705

Advanced Configuration Guide

Page 663

Applicability

Applicability
This section describes ESMv6: IPoE dual stack hosts and is applicable to 7750 SR series (SR-7,
SR-12, SR-c4 and SR-c12) as well as 7450 ESS series in mixed mode and was tested on SR-OS
8.0R4.
This section focuses on IPoE IPv6. IPv4 configuration is shown for completeness and is described
in more detail in IPv4 DHCP Hosts on page 979.

Pre-requisites
Configuring IPoE dual stack hosts for ESMv6 are dependent on the following.

Page 664

IOM3-XP or IMM required for subscriber and network interfaces

Chassis-mode C or higher

Routed CO (IES/VPRN service) with Enhanced Subscriber Management (ESM)

VLAN per subscriber (1:1 vlan)

Routed Gateway (RG) in the home

Advanced Configuration Guide

ESMv6: IPoE Dual Stack Hosts

Summary
In this section, the configuration, operation and troubleshooting of IPoE dual stack hosts in a
routed home gateway environment is explained. Focus is on the Enhanced Subscriber
Management for IPv6 (ESMv6) part where DHCPv6 is used for IPv6 address assignment. In the
BNG, authentication, authorization and IPv6 prefix configuration for an IPoE IPv6 host can be
done by a local user database or RADIUS.

Advanced Configuration Guide

Page 665

Overview

Overview
IPoE Dual Stack Hosts
An IPoE dual stack subscriber may support both IPv4 and IPv6 simultaneously. The dual stack
hosts share a common subscriber identification policy and have a common SLA- and Subscriberprofile.
IPoE IPv4 and IPv6 hosts operate independently as they are set up through different protocols,
DHCPv4 and DHCPv6 respectively. Table 3 and Table 4 show the valid combinations of
authentication, authorization and address assignment in the BNG for both address families.

Table 3: Valid Combinations for RADIUS Authenticated Hosts


Authentication and authorization
(Subscriber ID and strings)

IP address assignment
(prefix, prefix length, gateway, DNS, etc.)

IPv6 host

RADIUS

RADIUS

IPv4 host

Static host

Static host

RADIUS

RADIUS or DHCPv4

Table 4: Valid Combinations for LUDB Authenticated Hosts


Authentication and authorization (Subscriber ID and strings)

IP address assignment (prefix, prefix


length, gateway, DNS)

IPv6 host

LUDB

LUDB

IPv4 host

Static host

Static host

Python/DHCPv4

DHCPv4

SAP defaults

DHCPv4

LUDB

LUDB or local DHCPv4 server

Page 666

Advanced Configuration Guide

ESMv6: IPoE Dual Stack Hosts

For an IPoE dual stack subscriber, up to three different types of subscriber hosts can be
instantiated.

dual stack
subscriber

DHCPv4

subscriber-id
sla-profile
sub-profile

DHCPv6

IPv4 host

IPv6 wan host


IPv6 pd host

Figure 25: IPoE Dual Stack Subscriber Hosts

IPoE dual stack subscriber hosts are initially supported in a vlan/subscriber (1:1) routed CO model
and with a Routed Gateway (RG). The IPv6 IPoE hosts must support DHCPv6.

Advanced Configuration Guide

Page 667

Overview

Dual Stack IPoE Routed Gateway Service


In the dual stack IPoE Routed Gateway service, the RG in the home network obtains an IPv4
address through the DHCPv4 protocol and an IPv6 Prefix Delegation (PD) prefix and/or wan-host
IPv6 address through the DHCPv6 protocol. The Broadband Network Gateway (BNG)
authenticates and authorizes both sessions independently.
In the home network, the dual stack RG performs Network Address Translation (NAT) for IPv4,
using the assigned IPv4 address as outside address. A global unique IPv6 prefix per subscriber is
delegated by the BNG to the RG for use in the home network. The RG can use Stateless Address
Auto Configuration (SLAAC) or DHCPv6 to allocate IPv6 addresses from this so called Prefix
Delegation (PD) prefix to the devices in the home network. The wan-host IPv6 address is used by
the RG on the wan side (network facing). In case of an unnumbered RG, no wan-host address is
obtained.
Dual Stack
Home Network

IPv4@
IPv6@
IPv4@
IPv6@
IPv4@

Dual Stack
Access and Aggregation
Dual Stack
Routed
Gateway

RADIUS DHCPv4
Server Server

Dual Stack
BNG
BSAN

NAT
IPv6
PDprefix

IPv4@

IPoE

IPv6@
wan-host

IPv6@

PE-1

BNG-1
DHCP discover

RADIUS access request

DHCP offer

DHCPv4 private IPv4@ (NAT)

DHCPv4 assign public


IPv4@

RADIUS access accept


DHCP discover

DHCP request
DHCP ack

DHCP discover

DHCPv6 - assign global unique IPv6@


wan-host (IA-NA) and global unique
prefix (IA-PD) for use in the home

DHCP offer
DHCP request
DHCP ack
DHCP6 solicit

RADIUS access request


RADIUS access accept

SLAAC or DHCPv6 global unique IPv6@


in PD prefix range

DHCP6 advertise
DHCP6 request
DHCP6 reply

Router Advertisement
ICMP6 Neighbor Solicitation (DAD)

Installs default route

Duplicate Address
Detection (DAD)

Router Advertisement

Figure 26: Dual Stack IPoE Routed Gateway Service

Page 668

Advanced Configuration Guide

ESMv6: IPoE Dual Stack Hosts

Recap of the DHCPv6 Protocol


The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) is defined in RFC 3315, Dynamic
Host Configuration Protocol for IPv6 (DHCPv6). The protocol enables DHCPv6 servers to pass
configuration parameters such as IPv6 network addresses to IPv6 nodes.
DHCPv6 uses the Identity Association (IA) option to assign IPv6 addresses or prefixes. Two
different IA types will be used in this section:

Identity Association for Non-temporary Address (IA-NA) defined in RFC 3315.


Used for wan-host IPv6 address assignment.
Option : IA_NA (3), Length : 40
IAID : 1
Time1: 1800 seconds
Time2: 2880 seconds
Option : IAADDR (5), Length : 24
Address : 2001:DB8:B001:101::1
Preferred Lifetime : 3600 seconds
Valid Lifetime
: 86400 seconds

Identity Association for Prefix Delegation (IA-PD), defined in RFC3633.


Used for prefix delegation assignment (for an explanation on prefix delegation, see Prefix
Delegation on page 673)

Option : IA_PD (25), Length : 41


IAID : 1
Time1: 1800 seconds
Time2: 2880 seconds
Option : IAPREFIX (26), Length : 25
Prefix : 2001:DB8:A001:100::/56
Preferred Lifetime : 3600 seconds
Valid Lifetime
: 86400 seconds

Advanced Configuration Guide

Page 669

Overview

The DHCPv6 lease process is outlined in Figure 27 and Figure 28.


DHCPv6 Server

Client

Solicit

SA=FE80::...(client), DA=FF02::1:2
Options: ClientId, IA-NA, Option Request (DNS-Servers)
SA=FE80::...(server), DA=FE80::... (client)
Options: ServerId, ClientID, DNS-Servers, IA-NA (IAID, IAADDR)

Request

Advertise
Initial
Binding

SA=FE80::...(client), DA=FF02::1:2
Options: ServerId, ClientID, IA-NA, Option Request (DNS-Servers)
SA=FE80::...(server), DA=FE80::... (client)
Options: ServerId, ClientID, DNS-Servers, IA-NA (IAID, IAADDR)

Reply

Figure 27: DHCPv6 Lease Process (Part A)

A DHCPv6 client, sends a SOLICIT message to locate servers to the All DHCPv6 Relay Agents
and Servers link-scoped multicast address (FF02::1:2), using its link-local address as source
address. The DHCPv6 client includes in the SOLICIT message its ClientID, Identity Associations
(IA) to request IPv6 address or prefix allocation and optionally an Option Request option.
Any on-link DHCPv6 server responds with a unicasted ADVERTISE message using the link local
addresses. The server includes in the ADVERTISE message the ClientID, its ServerID, IPv6
addresses and/or prefixes in Identity Associations (IA) and options containing the requested
configuration parameters.
The DHCPv6 client selects an ADVERTISE message and sends a REQUEST message to the All
DHCPv6 Relay Agents and Servers link-scoped multicast address. It includes its ClientID, the
ServerID of the corresponding DHCPv6 server, Identity Associations (IA) to request IPv6 address
or prefix allocation and optionally an Option Request option.
Upon receipt of a valid REQUEST message, the DHCPv6 server with corresponding ServerID,
sends a unicast REPLY message using the link local addresses. The REPLY contains the ClientID
and ServerID, IPv6 addresses and/or prefixes in Identity Associations (IA) and options containing
the requested configuration options.
The DHCPv6 client should perform Duplicate Address Detection (DAD) on the addresses in any
IA it received in the REPLY before using that address for traffic.

Page 670

Advanced Configuration Guide

ESMv6: IPoE Dual Stack Hosts

Client

T1
Expired

DHCPv6 Server

SA=FE80::...(client), DA=FF02::1:2

Renew

Options: ClientId, ServerId, IA-NA (IAID, IAADDR)


renew

SA=FE80::...(server), DA=FE80::... (client)


Options: ServerId, ClientID, IA-NA (IAID, IAADDR)

T2
Expired

Reply

SA=FE80::...(client), DA=FF02::1:2

Rebind

Options: ClientID, IA-NA (IAID, IAADDR)


SA=FE80::...(server), DA=FE80::... (client)
Options: ServerId, ClientID, IA-NA (IAID, IAADDR)

Time

rebind
Reply

SA=FE80::...(client), DA=FF02::1:2

Release

Options: ClientID, ServerId, IA-NA, (IAID, IAADDR)


SA=FE80::...(server), DA=FE80::... (client)
Options: ServerId, ClientID, IA-NA (IAID, IAADDR), Status Code

release
Reply

Figure 28: DHCPv6 Lease Process (Part B)

Upon expiration of the renew timer T1 associated with the Identity Association option, the
DHCPv6 client sends a RENEW to the All DHCPv6 Relay Agents and Servers link-scoped
multicast address to request an extension of the lifetime of an address. It includes its ClientID, the
ServerID of the DHCPv6 server that originally provided the address and Identity Associations
(IA) containing the IPv6 address or prefix for which an extension of the lifetime is requested.
Upon expiration of the rebind timer T2 associated with the Identity Association option ( no
response received to the RENEW), the DHCPv6 client sends a REBIND to the All DHCPv6 Relay
Agents and Servers link-scoped multicast address to request an extension of the lifetime of an
address. It includes its ClientID and Identity Associations (IA) containing the IPv6 address or
prefix for which n extension of the lifetime is requested.
If a DHCPv6 client no longer uses one or more of the assigned addresses or prefixes, it sends a
RELEASE message to the server that assigned the address or prefix. The server acknowledges
with a REPLY message and includes a status code (for example, success).
If the DHCPv6 server sends a Server Unicast Option, then the DHCPv6 client should unicast the
REQUEST, RENEW, RELEASE and DECLINE messages to the server using the IPv6 address
specified in the option. The 7750 SR DHCPv6 proxy-server does not include the Server Unicast
Option.

Advanced Configuration Guide

Page 671

Overview

The DHCPv6 client should perform Duplicate Address Detection (DAD) on each of the addresses
assigned through DHCPv6, before using that address for traffic. The DHCPv6 client uses
Neighbor Solicitation for this purpose as described in RFC 4862, IPv6 Stateless Address
AutoConfiguration.
Unlike DHCPv4, DHCPv6 does not provide a default route. In IPv6, default routers are learned
via Router Advertisements (see Enable Router Advertisements on page 682).

Page 672

Advanced Configuration Guide

ESMv6: IPoE Dual Stack Hosts

Prefix Delegation
Prefix Delegation (PD) is a mechanism for automated delegation of IPv6 prefixes using DHCPv6.
A delegating router delegates a long-lived IPv6 prefix to a requesting router. The delegating router
does not require knowledge about the topology of the links in the network to which the prefixes
will be assigned.

RA
2001:db8:a001:100::/56

2001:DB8:A001::/48

PD

PD
RA

2001:db8:a001:200::/56

Delegating
Router

Requesting
Router

Figure 29: Prefix Delegation

In the context of ESM IPv6, the BNG is acting as delegating router (DHCPv6 server) and the
Routed Gateway in the home as requesting router (DHCPv6 client). The DHCPv6 option Identity
Association for Prefix Delegation (IA-PD) (Figure 29) is used to assign the IPv6 prefix.
Note that the mechanism through which a requesting router (routed gateway) assigns IPv6
addresses on its interfaces (home network) is arbitrary and can be based upon SLAAC (as shown
in Figure 29) or DHCPv6.

Advanced Configuration Guide

Page 673

Configuration

Configuration
ESMv6 for IPoE is applicable in a Routed CO environment. The two scenarios below show a
minimal configuration to enable dual stack subscribers in a VPRN service context.
Notes:

ESM IPv6 specific parts are highlighted.

There are no subscriber QoS policies defined (out of scope for this section)

Scenario 1
RADIUS authentication and authorization (later referenced as RADIUS).
A:BNG-1# configure subscriber-mgmt
A:BNG-1>config>subscr-mgmt# info
---------------------------------------------authentication-policy "radius-1" create
description "Radius authentication policy"
password <encrypted password>
radius-authentication-server
router "Base"
server 1 address 172.16.1.1 secret <encrypted secret>
exit
exit
sla-profile "sla-profile-1" create
exit
sub-profile "sub-profile-1" create
exit
sub-ident-policy "sub-ident-1" create
sub-profile-map
use-direct-map-as-default
exit
sla-profile-map
use-direct-map-as-default
exit
exit
---------------------------------------------A:BNG-1>config>subscr-mgmt# exit all

A:BNG-1# configure service vprn 1


A:BNG-1>config>service>vprn# info
---------------------------------------------vrf-import "import-1"
route-distinguisher 64496:1
auto-bind ldp
vrf-target export target:64496:1
subscriber-interface "sub-int-1" create
address 10.1.255.254/16
dhcp

Page 674

Advanced Configuration Guide

ESMv6: IPoE Dual Stack Hosts

gi-address 10.1.255.254
exit
group-interface "group-int-1" create
description "radius authentication and authorization"
ipv6
router-advertisements
managed-configuration
no shutdown
exit
dhcp6
proxy-server
no shutdown
exit
exit
exit
dhcp
server 172.16.0.1
trusted
lease-populate 10
no shutdown
exit
authentication-policy "radius-1"
sap 1/1/2:1 create
sub-sla-mgmt
sub-ident-policy "sub-ident-1"
multi-sub-sap 10
no shutdown
exit
exit
exit
ipv6
delegated-prefix-len 56
subscriber-prefixes
prefix 2001:DB8:A001::/48 pd
prefix 2001:DB8:B001:100::/56 wan-host
exit
exit
exit
service-name "dual-stack"
no shutdown
---------------------------------------------A:BNG-1>config>service>vprn#

Advanced Configuration Guide

Page 675

Configuration

Scenario 2
Local User Database for authentication and authorization (later referenced as LUDB).
*A:BNG-1# configure subscriber-mgmt
*A:BNG-1>config>subscr-mgmt# info
---------------------------------------------sla-profile "sla-profile-1" create
exit
sub-profile "sub-profile-1" create
radius-accounting-policy "aaa-policy"
exit
sub-ident-policy "sub-ident-1" create
sub-profile-map
use-direct-map-as-default
exit
sla-profile-map
use-direct-map-as-default
exit
strings-from-option 254
exit
local-user-db "ludb-1" create
dhcp
match-list mac
host "host-1" create
host-identification
mac 00:0a:bc:00:00:01
exit
address gi-address
identification-strings 254 create
subscriber-id "sub-1"
sla-profile-string "sla-profile-1"
sub-profile-string "sub-profile-1"
exit
options
subnet-mask 255.255.0.0
default-router 10.1.255.254
exit
ipv6-address 2001:DB8:B001:101::1
ipv6-prefix 2001:DB8:A001:100::/56
no shutdown
exit
exit
no shutdown
exit
---------------------------------------------*A:BNG-1>config>subscr-mgmt# exit all

A:BNG-1# configure service vprn 1


A:BNG-1>config>service>vprn# info
---------------------------------------------dhcp
local-dhcp-server "dhcp-s1" create
user-db "ludb-1"
use-gi-address
pool "pool-1" create

Page 676

Advanced Configuration Guide

ESMv6: IPoE Dual Stack Hosts

subnet 10.1.0.0/16 create


options
subnet-mask 255.255.0.0
default-router 10.1.255.254
exit
address-range 10.1.0.1 10.1.0.255
exit
exit
no shutdown
exit
exit
vrf-import "import-1"
route-distinguisher 64496:1
auto-bind ldp
vrf-target export target:64496:1
interface "dhcp-s1" create
address 192.0.2.1/32
local-dhcp-server "dhcp-s1"
loopback
exit
subscriber-interface "sub-int-1" create
address 10.1.255.254/16
dhcp
gi-address 10.1.255.254
exit
group-interface "group-int-2" create
description "Local user database authentication and authorization"
ipv6
router-advertisements
managed-configuration
no shutdown
exit
dhcp6
user-db "ludb-1"
proxy-server
no shutdown
exit
exit
exit
dhcp
server 192.0.2.1
trusted
lease-populate 10
no shutdown
exit
sap 1/1/2:2 create
sub-sla-mgmt
sub-ident-policy "sub-ident-1"
multi-sub-sap 10
no shutdown
exit
exit
exit
ipv6
delegated-prefix-len 56
subscriber-prefixes
prefix 2001:DB8:A001::/48 pd
prefix 2001:DB8:B001:100::/56 wan-host
exit

Advanced Configuration Guide

Page 677

Configuration

exit
exit
service-name "dual-stack"
no shutdown
---------------------------------------------A:BNG-1>config>service>vprn#

Page 678

Advanced Configuration Guide

ESMv6: IPoE Dual Stack Hosts

Configuring IPv6 Subscriber Prefixes


Applies to both scenarios RADIUS and LUDB.
IPv6 subscriber prefixes must be defined at the subscriber-interface <sub-int-name> ipv6
subscriber-prefixes context. Three types of prefixes can be configured:

wan-host Prefix from which the IPv6 addresses are assigned that are to be used on the
Routed Gateway WAN interface (network facing).

pd Prefix from which the IPv6 Prefix Delegation prefixes are assigned that are to be
used by the Routed Gateway for allocation in the home network (LAN interfaces).

pd wan-host (both) Prefix from which both IPv6 addresses (wan-host) and IPv6 Prefix
Delegation prefixes (pd) can be assigned. This requires that the delegated prefix length is
set to 64 bits.

A subscriber prefix length must be between /32 and /63.


Subscriber prefixes are subnetted in fixed length subnets that are assigned to subscriber hosts:

/64 for wan-host subscriber prefixes


A /128 IPv6 address is assigned to the subscriber host. Broadband Forum standards
requires a /64 prefix per subscriber even when used for WAN interfaces and thus the full
/64 subnet gets associated with the subscriber host [ref. WT-177 - IPv6 in the context of
TR-101]. Two subscriber hosts cannot get an IPv6 address from the same /64 subnet.

/delegated-prefix-len (/48..64) for pd subscriber prefixes


The delegated prefix length is configured in the subscriber-interface <sub-int-name>
ipv6 context. The recommended value by Broadband Forum standards is /56 (default =
/64) [ref. WT-177 - IPv6 in the context of TR-101]. The configured length applies to all
pd subscriber prefixes on a subscriber-interface.

Table 5 provides an overview of the subscriber-prefix parameters that apply:


Table 5: Applicable Subscriber-Prefix Parameters
Subscriber
prefix type

Subscriber
prefix length

DHCPv6 option

Must be subnetted as

wan-host

/32..63

IA-NA

/64 (assigned as /128)

pd

/32..63 (*)

IA-PD

/delegated-prefix-len

(*) must be smaller than configured delegated prefix length

Advanced Configuration Guide

Page 679

Configuration

Enable DHCPv6 Proxy Server


Applies to RADIUS and LUDB scenarios.
An IPv6 IPoE subscriber host initiates a DHCPv6 session to request its configuration data (IPv6
addresses and/or IPv6 PD prefixes, DNS servers). Upon receipt of a DHCPv6 SOLICIT message,
the BNG authenticates the IPv6 subscriber host and obtains its configuration information from a
RADIUS server or local user database. A DHCPv6 proxy server in the BNG maintains the
DHCPv6 session with the IPv6 IPoE subscriber host.
The DHCPv6 proxy server must be enabled in the subscriber-interface <sub-int-name> groupinterface <group-int-name> ipv6 dhcp6 proxy-server context. The default is shutdown.
service
vprn 1 customer 1 create
subscriber-interface "sub-int-1" create
group-interface "group-int-1" create
ipv6
dhcp6
proxy-server
renew-timer 1800
rebind-timer 2880
valid-lifetime 86400
preferred-lifetime 3600
client-applications dhcp
no shutdown
exit

#
#
#
#
#

default
default
default
default
default

When enabled, the DHCPv6 proxy server by default allows IPv6 IPoE hosts to authenticate
(configured with client-applications dhcp. Additionally, you can enable support for IPv6 PPPoE
hosts. See ESMv6: PPPoE Dual Stack Hosts on page 707.
A number of timers associated with IPv6 addresses and IPv6 prefixes within DHCPv6 Identity
Associations can be configured in the DHCPv6 proxy server.
RFC 4862 defines two timers associated with graceful degradation of address bindings:

Page 680

Preferred lifetime The length of time that a valid address is preferred (the time until
deprecation). When the preferred lifetime expires, the address becomes deprecated and its
use should be discouraged for new sessions.

Valid lifetime The length of time an address remains in the valid state (the time until
invalidation). The valid lifetime must be greater than or equal to the preferred lifetime.
When the valid lifetime expires, the address becomes invalid.

Advanced Configuration Guide

ESMv6: IPoE Dual Stack Hosts

RFC 3315 (DHCPv6) defines two timers associated with an Identity Association (IA) option that
give the servers explicit control over when a client recontacts the server about a specific IA:

T1 (renew) The time at which the client contacts the server from which the addresses/
prefix in the IA were obtained to extend the lifetimes of the addresses/prefix assigned to
the IA

T2 (rebind) The time at which the client contacts any available server to extend the
lifetimes of the addresses/prefixes assigned to the IA;

These timers are common for all DHCPv6 sessions in a group-interface and cannot be configured
from RADIUS nor local user database.
Tentative
(DAD in
Progress)

Valid
Invalid
(Use Forbidden)

Deprecated
(Use Discouraged)

Preferred
(Unrestricted Use)

Time
Address
Assigned to
Interface

T2 (rebind)

T1 (renew)

Preferred
Lifetime

Valid
Lifetime

i.e., dhcp6
proxy-server
lease time

Figure 30: IPv6 Address/Prefix Timers

When violating the following rule, the default timers will be used:

renew timer rebind timer preferred lifetime valid lifetime

Table 6: Timer Parameters


Timer

Use

Default

Range

T1

Renew timer

1800s (30 min)

0..604800s (7 days)

T2

Rebind timer

2880s (48 min)

0..1209600s (14 days)

3600s (1hr)

300..4294967295s

86400s (24 hrs)

300..4294967295s

preferred-lifetime
valid-lifetime

DHCPv6 lease time

If the DHCPv6 lease is not renewed by the client before the DHCPv6 lease timer expires, then the
subscriber host is deleted from the system. In other words, beyond the valid lifetime, subscriber
traffic from/to the associated IPv6 addresses is dropped.

Advanced Configuration Guide

Page 681

Configuration

Enable Router Advertisements


Applies to both scenarios RADIUS and LUDB.
In IPv6, default routers are automatically installed via the router discovery mechanism.
Unsolicited Router Advertisements (RA) must explicitly be enabled on a group interface. The
default is shutdown.
service
vprn 1 customer 1 create
subscriber-interface "sub-int-1" create
group-interface "group-int-1" create
ipv6
router-advertisements
managed-configuration
no shutdown
exit

Note that the managed-configuration flag is set for consistency only. It tells the hosts that
addresses are available by DHCPv6. However, as described in the Security section later (see
Security on page 699), the host cannot rely on this flag because DHCPv6 must be initiated by the
host before the BNG sends RAs.
Additional parameters that can be configured with respect to the router advertisements (defaults
are shown):
service
vprn 1 customer 1 create
subscriber-interface "sub-int-1" create
group-interface "group-int-1" create
ipv6
router-advertisements
shutdown
current-hop-limit 64
no managed-configuration
max-advertisement 1800
min-advertisement 900
no mtu
no other-stateful-configuration
prefix-options
no autonomous
preferred-lifetime 3600
valid-lifetime 86400
exit
reachable-time 0
retransmit-time 0
router-lifetime 4500
exit

Page 682

Advanced Configuration Guide

ESMv6: IPoE Dual Stack Hosts

Table 7: Router Advertisements Parameters


Parameter

Description (RFC 4861,


Neighbor Discovery for IP version 6 (IPv6))

Value Range
(default)

current-hop-limit

The default value that should be placed in the Hop Count field
of the IP header for outgoing IP packets. A value of zero
means unspecified (by this router); the RG picks its own value.

0..255 (64)

managedconfiguration

Managed address configuration flag. When set, it indicates that


addresses are available through DHCPv6

(no)

max-advertisement

Unsolicited Router Advertisements are not strictly periodic:


the interval between subsequent transmissions is randomized
to reduce the probability of synchronization with the
advertisements from other routers on the same link. Whenever
a multicast advertisement is sent from an interface, the timer is
reset to a uniformly distributed random value between the
interface's configured MinRtrAdvInterval and
MaxRtrAdvInterval.

900..1800 s (1800)

mtu

Routers can advertise an MTU for hosts to use on the link.

1280..9212 bytes (no)

other-statefulconfiguration (not
applicable for IPoE)

Other configuration flag. When set, it indicates that other


configuration information is available through DHCPv6.
(DNS). Can be ignored if managed address configuration flag
is enabled

(no)

prefix-options:
autonomous (not
applicable for IPoE)

Autonomous address-configuration flag. When set indicates


that this prefix can be used for stateless address
autoconfiguration (SLAAC)

(no)

prefix-options:
preferred-lifetime
(not applicable for
IPoE)

The length of time in seconds that addresses generated from


the prefix via stateless address autoconfiguration (SLAAC)
remain preferred

0..4294967295
(3600)

prefix-options: validlifetime (not


applicable for IPoE)

The length of time in seconds that the prefix is valid for the
purpose of on-link determination. (also used by SLAAC)

0..4294967295
(86400)

min-advertisement

Advanced Configuration Guide

900..1350 s (900)

Page 683

Configuration

Table 7: Router Advertisements Parameters (Continued)


Parameter

Description (RFC 4861,


Neighbor Discovery for IP version 6 (IPv6))

Value Range
(default)

reachable-time

The time that a node assumes a neighbor is reachable after


having received a reachability confirmation. Used by the
Neighbor Unreachability Detection algorithm. A value of zero
means unspecified (by this router); the RG picks its own value.

0..3600000 ms (0)

retransmit-time

The time between retransmitted Neighbor Solicitation


messages. Used by address resolution and the Neighbor
Unreachability Detection algorithm. A value of zero means
unspecified (by this router); the RG picks its own value.

0..1800000 ms (0)

router-lifetime

The lifetime associated with the default router in units of


seconds.

2700..9000 s (4500)

Page 684

Advanced Configuration Guide

ESMv6: IPoE Dual Stack Hosts

RADIUS Authentication and Authorization


Applies to scenario 1 RADIUS only.
The RADIUS authentication and authorization configuration for IPoE IPv6 subscriber host is no
different from an IPv4 subscriber host:
subscriber-mgmt
authentication-policy "radius-1" create
description "Radius authentication policy"
password <hashed password> hash2
radius-authentication-server
router "Base"
server 1 address 172.16.1.1 secret <hashed secret> hash2
exit
exit
vprn 1 customer 1 create
subscriber-interface "sub-int-1" create
group-interface "group-int-1" create
authentication-policy "radius-1"

Additional RADIUS AVPs that are applicable for IPoE IPv6 subscriber hosts are listed in Table 8.

Table 8: RADIUS AVPs


RADIUS AVP

Type

Purpose

Alc-IPv6-Address
[26-6527-99]

ipv6addr

maps to IA_NA of DHCPv6 (RG WAN interface


address)

Alc-Ipv6-Primary-Dns
[26-6527-105]

ipv6addr

maps to DNS Recursive Name Server option


(RFC 3646, DNS Configuration options for
Dynamic Host Configuration Protocol for IPv6
(DHCPv6)) in DHCPv6

Alc-Ipv6-Secondary-Dns
[26-6527-106]

ipv6addr

maps to DNS Recursive Name Server option


(RFC 3646) in DHCPv6

Delegated-IPv6-Prefix
[123]

ipv6prefix

maps to IA_PD for prefix delegation (RFC 3633,


IPv6 Prefix Options for Dynamic Host
Configuration Protocol (DHCP) version 6) in
DHCPv6

Advanced Configuration Guide

Page 685

Configuration

A sample FreeRADIUS users record to authenticate a dual stack IPoE subscriber:


00:0a:bc:00:00:01

Auth-Type := Local, Cleartext-Password := "password"


Alc-Subsc-ID-Str = "sub-1",
Alc-Subsc-Prof-Str = "sub-profile-1",
Alc-SLA-Prof-Str = "sla-profile-1",
Alc-IPv6-Address = 2001:db8:b001:101::1,
Delegated-IPv6-Prefix = 2001:db8:a001:100::/56,
Alc-Ipv6-Primary-DNS = 2001:db8:dddd:1::1,
Alc-Ipv6-Secondary-DNS = 2001:db8:dddd:2::1

Note the FreeRADIUS Server 2.0.0 and greater has full support for both IPv6 attributes and IPv6
network packets.
The IPv6 address/prefix related timers can be configured in the dhcp6 proxy-server context (see
Enable DHCPv6 Proxy Server on page 680).

Page 686

Advanced Configuration Guide

ESMv6: IPoE Dual Stack Hosts

Local User Database Authentication and Authorization


Applies to scenario 2 LUDB only.
The configuration example below focuses on the IPv6 host configuration. The details for local
user database host matching and IPv4 host specific parameters are out of scope for this section.
subscriber-mgmt
local-user-db "ludb-1" create
dhcp
match-list mac
host "host-1" create
host-identification
mac 00:0a:bc:00:00:01
exit
address gi-address
identification-strings 254 create
subscriber-id "sub-1"
sla-profile-string "sla-profile-1"
sub-profile-string "sub-profile-1"
exit
options
subnet-mask 255.255.0.0
default-router 10.1.255.254
exit
ipv6-address 2001:DB8:B001:101::1
ipv6-prefix 2001:DB8:A001:100::/56
no shutdown
exit
exit
no shutdown
exit
exit

# IPv4 host

# IPv4 host
# IPv4 host
# IPv6 host
# IPv6 host

vprn 1 customer 1 create


subscriber-interface "sub-int-1" create
group-interface "group-int-2" create
ipv6
dhcp6
user-db "ludb-1"

Next to the identification strings that are common between IPv4 and IPv6 hosts, there are two
specific IPv6 host related parameters to be configured:

Advanced Configuration Guide

Page 687

Configuration

Table 9: Local User Database Parameters


local-user-db CLI parameter

Purpose

ipv6-address

Maps to IA_NA of DHCPv6 (RG WAN interface address)

ipv6-prefix

Maps to IA_PD for prefix delegation (RFC 3633) in DHCPv6

The IPv6 address/prefix related timers can be configured in the dhcp6 proxy-server context (see
Enable DHCPv6 Proxy Server on page 680).
Note that DNSv6 server information cannot be configured in the local user database scenario. The
DNSv6 server information should either be manually configured on the host or a DNSv4 server
should be used instead.

Page 688

Advanced Configuration Guide

ESMv6: IPoE Dual Stack Hosts

DHCP and DHCP6 Lease State


Applies to both scenarios RADIUS and LUDB.
The DHCP lease state is an internal database structure that keeps track of the DHCP host states.
The DHCP lease state enables subscriber management functions (for example, per subscriber QoS
and accounting) and security functions (for example, dynamic anti-spoof filtering) on the DHCP
host.
The DHCP lease information for a specific host is extracted from the DHCPv4 ack message in
case of DHCPv4 and from the DHCPv6 reply message in case of DHCPv6
Typical information stored in the DHCP lease state includes (partial table; additional data can be
stored for managed SAPs, wholesale-retail).

Table 10: DHCP Lease State Information


Parameter

Comment

Service ID

Service where the DHCP host is connected.

IP Address

IPv4 or IPv6 address of the DHCP host.

Client HW Address

Ethenet MAC address of the DHCP host.

Subscriber-interface
(Routed CO only)

Subscriber interface name where the DHCP host is instantiated.

Group-interface
(Routed CO only)

Group interface name where the DHCP host is instantiated.

SAP

SAP where the DHCP hosts is connected.

Remaining Lifetime

The remaining time before the DHCP host is deleted from the
system (updated each time a DHCP renew/rebind occurs).

Persistence Key

Lookup key for this host in the persistency file.

Sub-Ident

ESM: Subscriber ID of the DHCP host.

Sub-Profile-String

ESM: Subscriber profile string of the DHCP host.

SLA-Profile-String

ESM: SLA profile string of the DHCP host.

App-Profile-String

ESM: Application profile string of the DHCP host.

Lease ANCP-String

ESM: ANCP string for this DHCP host.

Lease Int Dest Id

ESM: Internal destination ID for this DHCP host.

Advanced Configuration Guide

Page 689

Configuration

Table 10: DHCP Lease State Information (Continued)


Parameter

Page 690

Comment

Category-Map-Name

ESM: Volume and Time based accounting.

Dhcp6 ClientId (DUID)

DHCPv6 client unique identifier.

Dhcp6 IAID

Identity Association ID chosen by the client.

Dhcp6 IAID Type

Identity Association type: prefix (PD) or non-temporary (wanhost).

Dhcp6 Client Ip

Link local IPv6 address of the host.

Sub-Ident origin

ESM: Origin for the Subscriber ID for this host (None, DHCP,
RADIUS).

Strings origin

ESM: Origin for the ESM strings for this host (None, DHCP,
RADIUS).

Lease Info origin

ESM: Origin for the IP configuration for this host (None, DHCP,
RADIUS).

Ip-Netmask

The IP netmask for this DHCP host.

Broadcast-Ip-Addr

The broadcast IP address for this host.

Default-Router

The default gateway for this host.

Primary-Dns

The primary DNS server for this host.

Secondary-Dns

The secondary DNS server for this host.

Primary-Nbns

The primary NetBIOS name server for this host.

Secondary-Nbns

The secondary NetBIOS name server for this host.

ServerLeaseStart

Time and date that the lease for this host started (first DHCP ack
received).

ServerLastRenew

Time and date that the lease for this host was last renewed.

ServerLeaseEnd

Time and date that the lease for this host will expire.

Session-Timeout

Lease time specified by the DHCP server.

DHCP Server Addr

IP address of the DHCP server that allocated the lease for this
host.

Advanced Configuration Guide

ESMv6: IPoE Dual Stack Hosts

Table 10: DHCP Lease State Information (Continued)


Parameter

Comment

Circuit Id

DHCP Relay Agent information option 82 Circuit ID content.

Remote Id

DHCP Relay Agent information option 82 Remote ID content.

RADIUS User-Name

ESM: Username used in the RADIUS authentication access


request.

DHCPv4 lease state population is enabled by default on a group-interface with DHCP configured
as no shutdown. The number of DHCPv4 leases allowed on the group-interface must be
configured with the lease-populate option (by default a single DHCPv4 host is allowed per groupinterface).
DCHPv6 lease state population is enabled by default on a group-interface with DHCP6 proxyserver configured as no shutdown. The number of DHCPv6 leases (hosts) cannot be limited per
group-interface.
configure
service
vprn 1 customer 1 create
subscriber-interface "sub-int-1" create
group-interface "group-int-1" create
ipv6
dhcp6
proxy-server
no shutdown
exit
exit
exit
dhcp
server 172.16.0.1
trusted
lease-populate 10
no shutdown
exit

To check the DHCPv4 or DHCPv6 lease state for a particular service, use the following
commands (detailed output as well as additional output filtering is available):
*A:BNG-1# show service id 1 dhcp lease-state ?
- lease-state [wholesaler <service-id>] [sap <sap-id>|sdp <sdp-id:vc-id>|
interface <interface-name>|ip-address <ip-address[/mask]>|chaddr
<ieee-address>|mac <ieee-address>|{[port <port-id>] [no-inter-dest-id |
inter-dest-id <inter-dest-id>]}] [detail]

Advanced Configuration Guide

Page 691

Configuration

*A:BNG-1# show service id 1 dhcp6 lease-state detail


===============================================================================
DHCP lease states for service 1
===============================================================================
Service ID
: 1
IP Address
: 2001:DB8:A001:100::/56
Client HW Address
: 00:0a:bc:00:00:01
Subscriber-interface : sub-int-1
Group-interface
: group-int-1
SAP
: 1/1/2:1
Remaining Lifetime
: 23h59m49s
Persistence Key
: 0x0000004d
Sub-Ident
:
Sub-Profile-String
:
SLA-Profile-String
:
App-Profile-String
:
Lease ANCP-String
:
Lease Int Dest Id
:
Category-Map-Name
:
Dhcp6 ClientId (DUID):
Dhcp6 IAID
:
Dhcp6 IAID Type
:
Dhcp6 Client Ip
:
Primary-Dns
:
Secondary-Dns
:
Sub-Ident origin
Strings origin
Lease Info origin

"sub-1"
"sub-profile-1"
"sla-profile-1"
""
""
""
""
00010001133ebdd2000c29c851ca
1
prefix
FE80::20A:BCFF:FE00:1
2001:DB8:DDDD:1::1
2001:DB8:DDDD:2::1

: Radius
: Radius
: Radius

ServerLeaseStart
: 09/02/2010 16:13:11
ServerLastRenew
: 09/02/2010 16:13:11
ServerLeaseEnd
: 09/03/2010 16:13:11
Radius User-Name
: "00:0a:bc:00:00:01"
------------------------------------------------------------------------------Service ID
: 1
IP Address
: 2001:DB8:B001:101::1/128
Client HW Address
: 00:0a:bc:00:00:01
Subscriber-interface : sub-int-1
Group-interface
: group-int-1
SAP
: 1/1/2:1
Remaining Lifetime
: 23h59m49s
Persistence Key
: 0x0000004c
Sub-Ident
:
Sub-Profile-String
:
SLA-Profile-String
:
App-Profile-String
:
Lease ANCP-String
:
Lease Int Dest Id
:
Category-Map-Name
:
Dhcp6 ClientId (DUID):
Dhcp6 IAID
:
Dhcp6 IAID Type
:
Dhcp6 Client Ip
:
Primary-Dns
:
Secondary-Dns
:

Page 692

"sub-1"
"sub-profile-1"
"sla-profile-1"
""
""
""
""
00010001133ebdd2000c29c851ca
1
non-temporary
FE80::20A:BCFF:FE00:1
2001:DB8:DDDD:1::1
2001:DB8:DDDD:2::1

Advanced Configuration Guide

ESMv6: IPoE Dual Stack Hosts

Sub-Ident origin
Strings origin
Lease Info origin

: Radius
: Radius
: Radius

ServerLeaseStart
: 09/02/2010 16:13:11
ServerLastRenew
: 09/02/2010 16:13:11
ServerLeaseEnd
: 09/03/2010 16:13:11
Radius User-Name
: "00:0a:bc:00:00:01"
------------------------------------------------------------------------------Number of lease states : 2
===============================================================================
*A:BNG-1#

Advanced Configuration Guide

Page 693

Configuration

Operation
An IPoE dual stack subscriber in a numbered Routed Gateway scenario consumes three subscriber
host entries:

IPv4 host DHCPv4 session based

IPv6 wan-host DHCPv6 session based

IPv6 Prefix Delegation host DHCPv6 session based

*A:BNG-1# show service active-subscribers


===============================================================================
Active Subscribers
===============================================================================
------------------------------------------------------------------------------Subscriber sub-1 (sub-profile-1)
------------------------------------------------------------------------------------------------------------------------------------------------------------(1) SLA Profile Instance sap:1/1/2:1 - sla:sla-profile-1
------------------------------------------------------------------------------IP Address
MAC Address
PPPoE-SID Origin
-------------------------------------------------------10.1.0.3
00:0a:bc:00:00:01 N/A
DHCP
2001:DB8:A001:100::/56
00:0a:bc:00:00:01 N/A
IPoE-DHCP6
2001:DB8:B001:101::1/128
00:0a:bc:00:00:01 N/A
IPoE-DHCP6
------------------------------------------------------------------------------Number of active subscribers : 1
===============================================================================
*A:BNG-1#

The optional hierarchy parameter for the active-subscribers display provides a top-down level
overview for this subscriber:
*A:BNG-1# show service active-subscribers hierarchy
===============================================================================
Active Subscriber hierarchy
===============================================================================
-- sub-1 (sub-profile-1)
|
|-- sap:1/1/2:1 - sla:sla-profile-1
|
|
|
|-- 10.1.0.3
|
|
00:0a:bc:00:00:01 - N/A (DHCP)
|
|
|
|-- 2001:DB8:A001:100::/56
|
|
00:0a:bc:00:00:01 - N/A (IPoE-DHCP6)
|
|
|
|-- 2001:DB8:B001:101::1/128
|
|
00:0a:bc:00:00:01 - N/A (IPoE-DHCP6)

Page 694

Advanced Configuration Guide

ESMv6: IPoE Dual Stack Hosts

===============================================================================
A:BNG-1#

The total number (sum) of IPv4 and IPv6 hosts per subscriber can be limited in the corresponding
sla-profile with the host-limit parameter:
subscriber-mgmt
sla-profile "sla-profile-1" create
host-limit 3
exit

To display the IPv4/IPv6 routing table for dual stack hosts:


A:BNG-1# show router 1 route-table ipv4 protocol sub-mgmt
===============================================================================
Route Table (Service: 1)
===============================================================================
Dest Prefix
Type
Proto
Age
Pref
Next Hop[Interface Name]
Metric
------------------------------------------------------------------------------10.1.0.3/32
Remote Sub Mgmt 00h01m44s
0
[group-int-1]
0
------------------------------------------------------------------------------No. of Routes: 1
===============================================================================
A:BNG-1#

A:BNG-1# show router 1 route-table ipv6 protocol sub-mgmt


===============================================================================
IPv6 Route Table (Service: 1)
===============================================================================
Dest Prefix
Type
Proto
Age
Pref
Next Hop[Interface Name]
Metric
------------------------------------------------------------------------------2001:DB8:A001:100::/56
Remote Sub Mgmt 00h01m50s
0
[group-int-1]
0
2001:DB8:B001:101::1/128
Remote Sub Mgmt 00h01m50s
0
[group-int-1]
0
------------------------------------------------------------------------------No. of Routes: 2
===============================================================================
A:BNG-1#

Advanced Configuration Guide

Page 695

Configuration

Troubleshooting
Apart from the show commands in this section, use the following commands to troubleshoot a
dual stack host session:

Default system log:

A:BNG-1# show log log-id 99

Use appropriate filtering to reduce the output if needed.

Debug:

debug
router "1"
ip
dhcp

# DHCPv4
detail-level medium
mode egr-ingr-and-dropped

exit
dhcp6
# DHCPv6
mode egr-ingr-and-dropped
detail-level high
# needed to see the option content
exit
exit
local-dhcp-server dhcp-s1
detail-level medium
mode egr-ingr-and-dropped
exit
exit
subscriber-mgmt
local-user-db ludb-1
detail all
exit
exit
radius detail

# local dhcp server

# local user database

# RADIUS

exit

Note that additional filtering (such as only DHCPv6 debug for particular interface) may be needed
to prevent flooding of debug messages.

Page 696

Advanced Configuration Guide

ESMv6: IPoE Dual Stack Hosts

Protocol statistics:

DHCPv4 stats:
A:BNG-1# show router 1 dhcp statistics
====================================================================
DHCP Global Statistics (Service: 1)
====================================================================
Rx Packets
: 3192
Tx Packets
: 3177
Rx Malformed Packets
: 0
Rx Untrusted Packets
: 0
Client Packets Discarded
: 0
Client Packets Relayed
: 737
Client Packets Snooped
: 860
Client Packets Proxied (RADIUS)
: 0
Client Packets Proxied (Lease-Split) : 0
Server Packets Discarded
: 15
Server Packets Relayed
: 733
Server Packets Snooped
: 847
DHCP RELEASEs Spoofed
: 0
DHCP FORCERENEWs Spoofed
: 0
====================================================================
A:BNG-1#

DHCPv6 stats:
*A:BNG-1# show router 1 dhcp6 statistics
===========================================================================
DHCP6 statistics (Router: 1)
===========================================================================
Msg-type
Rx
Tx
Dropped
--------------------------------------------------------------------------1 SOLICIT
3
0
0
2 ADVERTISE
0
3
0
3 REQUEST
3
0
0
4 CONFIRM
0
0
0
5 RENEW
313
0
6
6 REBIND
0
0
0
7 REPLY
0
312
0
8 RELEASE
2
0
0
9 DECLINE
0
0
0
10 RECONFIGURE
0
0
0
11 INFO_REQUEST
0
0
0
12 RELAY_FORW
0
0
0
13 RELAY_REPLY
0
0
0
--------------------------------------------------------------------------Dhcp6 Drop Reason Counters :
--------------------------------------------------------------------------1 Dhcp6 oper state is not Up on src itf
0
2 Dhcp6 oper state is not Up on dst itf
0
3 Relay Reply Msg on Client Itf
0
4 Hop Count Limit reached
0
5 Missing Relay Msg option, or illegal msg type
0

Advanced Configuration Guide

Page 697

Configuration

6 Unable to determine destination client Itf


0
7 Out of Memory
0
8 No global Pfx on Client Itf
0
9 Unable to determine src Ip Addr
0
10 No route to server
0
11 Subscr. Mgmt. Update failed
6
12 Received Relay Forw Message
0
13 Packet too small to contain valid dhcp6 msg
0
14 Server cannot respond to this message
0
15 No Server Id option in msg from server
0
16 Missing or illegal Client Id option in client msg
0
17 Server Id option in client msg
0
18 Server DUID in client msg does not match our own
0
19 Client sent message to unicast while not allowed
0
20 Client sent message with illegal src Ip address
0
21 Client message type not supported in pfx delegation
0
22 Nbr of addrs or pfxs exceeds allowed max (128) in msg
0
23 Unable to resolve client's mac address
0
24 The Client was assigned an illegal address
0
25 Illegal msg encoding
0
26 Client message not supported
0
27 IA options in info request
0
28 No IA option in client msg
0
29 No addresses in confirm msg
0
===========================================================================
A:BNG-1#

RADIUS stats:
*A:BNG-1# show subscriber-mgmt authentication "radius-1" statistics
===============================================================================
Authentication Policy Statistics
===============================================================================
------------------------------------------------------------------------------Policy name
: radius-1
subscriber packets authenticated
: 16
subscriber packets rejected
: 0
------------------------------------------------------------------------------radius server
requests requests requests requests
requests requests
idx IP-address
accepted rejected no reply md5 failed pending send failed
------------------------------------------------------------------------------1 172.16.1.1
16
0
0
0
0
0
===============================================================================
A:BNG-1#

Page 698

Advanced Configuration Guide

ESMv6: IPoE Dual Stack Hosts

Advanced Topics
Security
Downstream Router Advertisements
When a SAP is bound to a subscriber/group-interface which has IPv6 enabled, there will be no
initial downstream Router Advertisement (RA) message sent. If a SAP is shared by multiple
subscribers, it would be possible for an unauthenticated host to receive the RA.
Instead the RAs are sent in unicast to allow per-host IPv6 link configuration. This requires the host
information (MAC address and link-local IPv6 address) to be known. Hence for IPoE, until a
DHCPv6 session is bound, no unsolicited or solicited RAs are send.

Processing of Neighbor Discovery Messages


Processing of Neighbor Discovery messages: Neighbor Advertisements (NA), Neighbor
Solicitations (NS) and Router Solicitations (RS).
Neighbor discovery messages are not processed prior to IPoE IPv6 host authentication to avoid
DoS attacks consuming CPU resources. This implies that an IPoE host should initiate the
DHCPv6 session without link information and knowledge of routers on the link as required by the
Broadband Forum standards (ref. TR-124 issue 2 Functional Requirements for Broadband
Residential Gateway Devices). This is not a problem as the DHCPv6 solicit/request messages are
sent to a well-known multicast address with direct link-layer mapping.
After DHCP host authentication, Neighbor Discovery messages will not result in a neighbor cache
entry. Instead a managed neighbor cache entry is created based on the DHCPv6 lease state. This
managed neighbor cache entry cannot be displayed. The above mechanism prevents DoS attacks
from poisoning the neighbor cache with bogus entries.
Router advertisements in response to a router solicitation are internally throttled so that they are
not sent more often than once every three seconds.

Advanced Configuration Guide

Page 699

Configuration

Anti-spoof Filters
For each authenticated IPoE IPv6 host, an anti-spoof filter entry is created that allows upstream
traffic with exact match on the tuple {masked source IP, source MAC}. Traffic from
unauthenticated hosts is silently dropped.

1:1 VLAN Model


This model implicitly enforces security in the Access/Aggregation network as there is a clean
separation of the subscriber traffic in a dedicated C-VLAN from the home network up to the BNG.

Page 700

Advanced Configuration Guide

ESMv6: IPoE Dual Stack Hosts

Managed SAPs
To allow the creation of managed SAPs in a dual stack environment, both DHCPv4 discover and
DHCPv6 solicit messages received on a capture SAP should trigger RADIUS authentication:
service
vpls 2 customer 1 create
sap 1/1/2:* capture-sap create
trigger-packet dhcp dhcp6
authentication-policy "radius-1"
exit
no shutdown
exit

A full description of the managed SAP functionality is out of the scope of this section.

RADIUS Change of Authorization (CoA)


The only CoA action that is allowed for IPoE IPv6 hosts is a change of ESM strings (SLA-profile,
subscriber-profile, application-profile, etc). Creation of a new IPv6 host or forcing a DHCPv6
renew is not supported.
Only a single address attribute (Framed-IP-Address, Delegated-IPv6-Prefix or Alc-IPv6-Address)
may be given in a single request. When host-accounting is enabled, only the host specific
accounting session IDs (Acct-Session-Id) can be used. This means that to change for example the
sla-profile for all three hosts of a dual stack subscriber, three CoA messages should be sent.
A full description of the RADIUS CoA functionality is out of the scope of this section.

Accounting
There are no separate accounting statistics available for IPv4 and IPv6 traffic unless they are
mapped in a different Forwarding Class/queue.
In RADIUS accounting, host-accounting could be enabled to see the IPv4 and IPv6 host
instantiations separately: an accounting start/stop is generated for each individual subscriber host.
The actual accounting data is included in the interim updates and accounting stop message for the
sla-profile instance.
A full description of the accounting functionality is out of the scope of this section.

Advanced Configuration Guide

Page 701

Configuration

Lease State Persistency


A DHCPv4/DHCPv6 (hereafter referred to as DHCP) session does not have a keep-alive
mechanism to detect unavailability. A new DHCP session set-up is only attempted after expiration
of the DHCP lease time. A node reboot causing the loss of DHCP lease state and the
corresponding anti-spoof filters could therefore result in unacceptable long service outages.
The DHCP lease state can be made persistent across node reboots: DHCP lease state is restored
from a persistency file stored on the compact flash file system. As a result, DHCP sessions will
only loose connectivity during the time of reboot without being completely disconnected.
To activate the DHCP lease state persistency:
configure
system
persistence
subscriber-mgmt
description "DHCP lease state persistency"
location cf2:
exit
exit

A dedicated persistency file will be created on the specified compact flash file system. The file is
initialized to store the maximum number of allowed hosts; its size is fixed to avoid file system
space problems during operations.
*A:BNG-1# file dir cf2:
Volume in drive cf2 on slot A has no label.
Volume in drive cf2 on slot A is formatted as FAT32.
Directory of cf2:\
09/02/2010

01:27p
1 File(s)
0 Dir(s)

536871424 submgmt.006
536871424 bytes.
1558183424 bytes free.

Each time the DHCP session is renewed, the persistency file is updated together with the lease
state. If the file update fails, an event is generated to indicate that persistency can not be
guaranteed.
The content of the persistency file may vary between different SR-OS software releases. When
upgrading, the persistency file is automatically upgraded to the new format. To downgrade the
persistency file to a lower SR-OS release version, use the following command:

Page 702

Advanced Configuration Guide

ESMv6: IPoE Dual Stack Hosts

*A:BNG-1# tools perform subscriber-mgmt downgrade ?


- downgrade target-version <target> [reboot]
<target>

<reboot>

: The version you want to downgrade to


8.0 (current) - submgmt.006
7.0
- submgmt.005
6.0
- submgmt.004
5.0
- submgmt.003
4.0
- submgmt.pst
: reboot system after successful conversion

The content of the persistency file can be looked at using the following commands:
*A:BNG-1# show service id 1 dhcp6 lease-state detail
===============================================================================
DHCP lease states for service 1
===============================================================================
Service ID
: 1
IP Address
: 2001:DB8:A001:100::/56
Client HW Address
: 00:0a:bc:00:00:01
Subscriber-interface : sub-int-1
Group-interface
: group-int-1
SAP
: 1/1/2:1
Remaining Lifetime
: 23h49m47s
Persistence Key
: 0x0000004d
- - - snip - - *A:BNG-1# tools dump persistence submgt record 0x0000004d
----------------------------------Persistency File Record
----------------------------------Filename
: cf2:\submgmt.006
Key
: 0000004d
Last Update : 2010/09/02 16:13:12 (UTC)
Action
: ADD
Data :
Host Type
: IpV6 node address
Service ID
: 1
SAP ID
: 1/1/2:1
IP
: 2001:DB8:A001:100::/56
NH MAC
: 00:0a:bc:00:00:01
Created
: 2010/09/02 16:13:11 (UTC)
Session Timeout: 0 (seconds)
Sub-ID
: sub-1
Sub-prof-ID
: sub-profile-1
SLA-prof-ID
: sla-profile-1
App-prof-ID
: NULL
ANCP-Str
: NULL
Int-dest-ID
: NULL
Cat-map-str
: NULL
Sub-Id is def : NO
Int-dest is def: YES
Address Origin : 1
SubId Origin
: 1
Strings Origin : 1

Advanced Configuration Guide

Page 703

Configuration

RADIUS Fallback:
Managed routes :
BgpPrngPlcyAttr:
Class Attr
:
Radius Username:
Pri. IPv6 DNS :
Sec. IPv6 DNS :

Page 704

NO
None
None
1 bytes
00:0a:bc:00:00:01
2001:DB8:DDDD:1::1
2001:DB8:DDDD:2::1

Advanced Configuration Guide

ESMv6: IPoE Dual Stack Hosts

Conclusion
This section provides configuration, operation and troubleshooting commands for dual stack IPoE
subscribers on Routed Gateways. Focus is on the ESMv6 part where DHCPv6 is used for IPv6
address assignment on the RG network interface (wan host) and for allocation of an IPv6 prefix
delegation prefix for use in the home network (pd host). In the BNG, authentication, authorization
and IPv6 prefix configuration for an IPoE IPv6 host is done by a local user database or RADIUS.

Advanced Configuration Guide

Page 705

Conclusion

Page 706

Advanced Configuration Guide

ESMv6: PPPoE Dual Stack Hosts

In This Chapter
This section describes ESMv6 PPPoE dual stack host configurations.
Topics in this section include:

Applicability on page 708

Overview on page 709

Configuration on page 713

Conclusion on page 742

Advanced Configuration Guide

Page 707

Applicability

Applicability
This section is applicable to all of the 7750 SR series (SR-7, SR-12, SR-c4 and SR-c12) as well as
7450 ESS (ESS-7 and ESS-12) series in mixed mode. It was tested on release 8.0R4.

Pre-requisites:

IOM3-XP or IMM required for subscriber and network interfaces

Chassis-mode C

Routed CO (IES/VPRN service) with Enhanced Subscriber Management (ESM)

Bridged or routed home gateway

Note: The focus of this section is on PPPoE IPv6. IPv4 configuration is shown for completeness.

Page 708

Advanced Configuration Guide

ESMv6: PPPoE Dual Stack Hosts

Overview
PPPoE Dual Stack
A PPPoE dual stack subscriber may support both IPv4 and IPv6 simultaneously. The dual stack
hosts share a common subscriber identification policy and have a common sla-profile and
subscriber-profile and are linked together through one PPPoE session.
For PPPoE dual stack hosts, one subscriber host entry is created for the IPv4 and one for the IPv6
address family.

1 PPPoE session

1 IPv4 host

Subscriber
Sla-profile-1
Sub-profile-1

1 IPv6 host
OSSG580

Figure 31: PPPoE Dual Stack Hosts

ESM for IPv6 is supported with RADIUS as backend authentication, address assignment and
authorization.
PPPoE dual stack subscriber-hosts are supported through bridged or routed home gateways. It is
mandatory to retrieve IPv6 address information in both models from RADIUS, whereas the IPv4
address information can be retrieved by DHCPv4 or RADIUS.

Advanced Configuration Guide

Page 709

Overview

Dual Stack PPPoE Bridged Gateway Service


In the dual stack PPPoE host service, the PPPoE session is initiated directly from a dual stack host
device or PC within the home network. PPPoE is used to carry IPv6 and (optionally) IPv4 traffic
from the device to the Broadband Remote Access Server (BRAS), also called Broadband Network
Gateway (BNG).
Unlike the Routed Gateway application examples (see later), no IPv6 prefix delegation occurs in
the bridged gateway service, instead, a global unicast address prefix (/64) is advertised using
Router Advertisements (RAs) directly to the PPPoE interface on the host.
The device addresses are self-assigned through Stateless Auto Configuration (SLAAC). where
SLAAC makes use of ICMPv6 router-advertisements to announce these IPv6 prefixes. The
SLAAC prefixes have a mandatory length of /64.
Because of limited device support for DHCPv6, only SLAAC is used for address assignment in
this model.
This application is targeted at operators who currently use a bridging modem in the customer
premise and who want to incrementally add IPv6 capability without a change of the modem on the
customer site.

Dual-stack
Host

Bridged
Gateway

IPv4@
IPv6@

IPv4@
IPv6/64 prefix

IPCP

RA (ICMPv6)

IES
VRF

BNG
PPPoE Session
OSSG581

Figure 32: Dual Stack PPPoE Bridged Gateway Service Example

Page 710

Advanced Configuration Guide

ESMv6: PPPoE Dual Stack Hosts

Dual Stack PPPoE Routed Gateway Service


The dual stack PPPoE Routed Gateway (RG) service runs over a dual stack PPPoE session
between a dual stack router and BNG. It allows operators of existing PPPoE networks (with either
PPPoE to the RG or PPPoA with translation to PPPoE in the DSLAM) to deploy IPv6 services in
conjunction with an existing IPv4 service.
As a RG is provided, a unique subscriber IPv6 prefix is delegated to the dual stack router for use
within the home network. DHCPv6 is used to provide prefix delegation (PD). No RG WAN IPv6
address assignment is supported in this model. The dual stack router does not perform any NAT
for IPv6 traffic.

IPv4@
IPv6@

Dual-stack
Host
IPv4@
IPv6@

Routed
Gateway
(RG)

IPv4@
IPv6 PD-prefix

IPCP

NATv4
IPv4@

DHCPv6
RA
DHCPv6

IES
VRF

BNG
PPPoE Session

Requesting
Router

Delegating
Router
OSSG582

Figure 33: Dual Stack PPPoE Routed Gateway Service Example

Advanced Configuration Guide

Page 711

Overview

SLAAC
The IPv6 stateless auto configuration (SLAAC) mechanism requires no manual configuration of
hosts, minimal configuration of routers, and no additional servers (such as DHCP). The stateless
mechanism allows a host to generate its own addresses using a combination of locally available
information and information advertised by routers. Routers advertise /64 prefixes, by an ICMPv6
router advertisement, that identify the subnet(s) associated with a link, while hosts generate a 64bit interface identifier that uniquely identifies an interface on a subnet. An address is formed by
combining the two.

DHCPv6
The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) is defined in RFC 3315. The
protocol enables DHCPv6 servers to pass configuration parameters such as IPv6 network
addresses or DNSv6 addresses to IPv6 nodes.
For further information on DHCPv6, refer to ESMv6: IPoE Dual Stack Hosts on page 663,

Prefix Delegation
Prefix Delegation (PD) is a mechanism for automated delegation of IPv6 prefixes using DHCPv6.
A delegating router delegates a long-lived IPv6 prefix to a requesting router. The delegating router
does not require knowledge about the topology of the links in the network to which the prefixes
will be assigned
For further information on Prefix Delegation, refer to ESMv6: IPoE Dual Stack Hosts on page
663.

Page 712

Advanced Configuration Guide

ESMv6: PPPoE Dual Stack Hosts

Configuration
ESMv6 for PPPoE is applicable in a Routed CO environment. Details of non-specific dual stack
configurations like authentication-policies, sla-profile, subscriber-profile, accounting-policies and
QoS policies are out of scope for this section.
The minimal RADIUS authentication configuration and ESM string configuration is just added for
completeness.
A:BNG-1#
configure subscriber-mgmt
authentication-policy "radius-1"
description "Radius authentication policy"
password ALU
radius-authentication-server
router "Base"
server 1 address 172.16.1.1 secret ALU
exit
PPPoE-access-method pap-chap
exit

A:BNG-1#
configure subscriber-mgmt
sla-profile "sla-profile-1"
exit
sub-profile "sub-profile-1"
exit
sub-ident-policy "sub-ident-1"
sub-profile-map
use-direct-map-as-default
exit
sla-profile-map
use-direct-map-as-default
exit
exit

Advanced Configuration Guide

Page 713

Configuration

Service
Dual Stack PPPoE for Bridged Gateway
Figure 34 shows the message flow for a dual stack PPPoE host behind a bridged gateway
corresponding with the configured service.
RADIUS
Dual Stack
PPPoE Host

Dual Stack
BNG-1

Bridged
Gateway

BSAN

IPv4@

ES 1

IPv6@

10.1.0.254
2001:DB8:C001:100::/56 wan-host

PE-1

PADI/PADO/PADR/PADS
LCP Configuration Req/Ack
CHAP Challenge/Response
RADIUS Access Request
RADIUS Access Accept
CHAP Authentication Successful

FRAMED IP ADDRESS 10.1.0.1

NCP

FRAMED IPV6 PREFIX 2001:DB8:C001:101::/64

IPCP Configuration Req/Ack


10.1.0.1

IPv6CP Configuration Req/Ack

Interface-id
SLAAC
ICMPv6 Router Solicitation

10.1.0.254

Alc-IPv6-Primary-DNS 2001:db8:dddd:1::1
Alc-IPv6-Secondary-DNS 2001:db8:dddd:2::1

Interface-id

ICMPv6 Router Advertisement


Default GW
PREFIX 2001:DB8:C001:101::/64
DHCP6 Information Request

DHCPv6

Option 23 : DNS Recursive Name Server

DHCP6 Reply
DNS 2001:db8:dddd:1::1
DNS 2001:db8:dddd:2::1
OSSG583

Figure 34: Message Flow for a Dual Stack PPPoE Host

For dual stack PPPoE, the BNG initiates the IPv6CP protocol to the client during the session setup
phase if the appropriate attributes have been returned by the RADIUS server on authentication.
The RADIUS attribute that indicates the setup of a dual stack PPPoE host in bridged mode is
framed-ipv6-prefix which should contain a /64 prefix for the client. When a PPPoE host has

Page 714

Advanced Configuration Guide

ESMv6: PPPoE Dual Stack Hosts

successfully completed the IPv6CP negotiation, the BNG will transmit an RA to the PPPoE host
containing the prefix and any other option that is configured. The host can request optional IPv6
DNS server information from the BNG by sending a DHCPv6 information-request.
The following example shows a minimal configuration to enable dual stack subscribers in an IES
service context with the ESM IPv6-specific parts in bold and is discussed in Dual Stack PPPoE
Routed Gateway Service on page 711.
A:BNG-1#
configure service ies 1
subscriber-interface "sub-int-1"
address 10.1.0.254/16
group-interface "group-int-1"
ipv6
router-advertisements
prefix-options
autonomous
exit
no shutdown
exit
dhcp6
proxy-server
client-applications pppoe
no shutdown
exit
exit
exit
authentication-policy "radius-1"
sap 1/1/4:301
sub-sla-mgmt
sub-ident-policy "sub-ident-1"
multi-sub-sap 10
no shutdown
exit
exit
PPPoE
no shutdown
exit
exit
ipv6
subscriber-prefixes
prefix 2001:DB8:C001:100::/40 wan-host
exit
exit
exit
no shutdown
exit

### length [/32../63]

IPv6 subscriber prefixes must be defined at the subscriber-interface <sub-int-name> ipv6


subscriber-prefixes context.
Three types of prefixes can be configured where wan-host is required for this bridged gateway
scenario and pd is used for dual stack PPPoE routed gateways.

Advanced Configuration Guide

Page 715

Configuration

wan-host Prefix from which the IPv6 addresses are assigned (by DHCPv6 IA_NA) for
the IPoEv6 routed gateway WAN interface (network facing) or a prefix from which /64
prefixes are assigned for the PPPoE (by RA SLAAC) hosts in the bridged gateway model.

pd Prefix from which the IPv6 prefix delegation prefixes are assigned that are to be
used by the IPoEv6 or PPPoEv6 routed gateway for allocation in the home network (LAN
interfaces).

pd wan-host (both) Prefix from which both IPv6 addresses (wan-host) and IPv6 prefix
delegation prefixes (pd) can be assigned. This requires that the delegated prefix length is
set to 64 bits.

Table 11 and Table 12 provide an overview of the subscriber-prefix parameters that apply and an
example of subscriber prefix subnetting for SLAAC.

Table 11: Subscriber Prefix Parameters


Subscriber
Prefix Type

wan-host

Prefix Length

/32..63

DHCPv6
Option

N/A

SLAAC

yes

RADIUS AVP

[97]FramedIPv6-Prefix

Must be
sub netted as

/64

Table 12: Subscriber Prefix Subnetting for SLAAC


Subscriber prefix

2001:db8:c001:100::/56

2001:db8:c001:200::/56

Page 716

Framed-IPv6-Prefix

2001:db8:c001:101::/64
2001:db8:c001:102::/64
2001:db8:c001:103::/64
<snip>
2001:db8:c001:1FF::/64
2001:db8:c001:201::/64
2001:db8:c001:202::/64
2001:db8:c001:203::/64
<snip>
2001:db8:c001:2FF::/64

Hosts

pppoev6-host-1
pppoev6-host-2
pppoev6-host-3
<snip>
pppoev6-host-256
PPPoEv6-host-257
PPPoEv6-host-258
PPPoEv6-host-259
<snip>
PPPoEv6-host-512

Advanced Configuration Guide

ESMv6: PPPoE Dual Stack Hosts

Dual Stack PPPoE for Routed Gateway


Figure 35 shows the message flow for a dual stack PPPoE host behind a routed gateway
corresponding with the configured service.
Radius
Dual Stack
Home
Network

Dual Stack
PPPoE Routed
Gateway

Dual Stack
BNG-1
BSAN

NAT
IPv4@

IPv4@

IES 1

IPv6@
DHCP discover
DHCP offer

10.1.0.254
2001:DB8:D001::/48

PADI/PADO/PADR/PADS

DHCP request

PE-1

LCP Configuration Req/Ack

DHCP ack

CHAP Challenge/Response
Radius Access Request

DHCPv4 private IPv4@ (NAT)

CHAP Authentication Successful

FRAMED IP ADDRESS 10.1.0.2

IPCP Configuration Req/Ack


10.1.0.2

10.1.0.254

IPv6CP Configuration Req/Ack


Interface-id

Interface-id

ICMPv6 Router Solicitation


DHCP6 solicit
Option 25 : IA-PD
Option 23 : DNS recursive name server
DHCP6 advertise

DHCPv6

Radius Access Accept

IA-PD 2001:DB8:D001:100::/56
DNS 2001:db8:dddd:1::1
DNS 2001:db8:dddd:2::1
DHCP6 request

Delegated-IPv6-Prefix
2001:DB8:D001:100::/56
Alc-IPv6-Primary-DNS
2001:db8:dddd:1::1
Alc-IPv6-Secondary-DNS
2001:db8:dddd:2::1

Reply on Router- Solicitation

! is done only after successful


DHCPv6 host setup

DHCP6 reply

SLAAC or DHCPv6

ICMPv6 Router Advertisement

ICMPv6 RA

Default GW
OSSG677

Figure 35: Dual Stack PPPoE for Routed Gateway

Initially, a PPPoE routed gateway follows the same procedure as a dual stack PPPoE host. The
BNG receives a prefix from RADIUS (in this case through a delegated-ipv6-prefix attribute),
which is used as a trigger to initiate the IPv6CP protocol to the client. The prefix that is offered to
the client should have the same prefix length as configured under the subscriber interface ipv6
node (delegated-prefix length).This length should be between 48 and 64 bits, inclusive.
After the IPv6CP protocol has completed the client must run the DHCPv6 protocol over its PPPoE
tunnel to receive a delegated prefix (IA_PD) and optionally IPv6 DNS server information.
This delegated prefix can then be subdivided by the client and distributed over its downstream
interfaces. During DHCPv6, no extra RADIUS request will be made; the information is stored

Advanced Configuration Guide

Page 717

Configuration

during the initial PPPoE authentication until the client starts DHCPv6. Only after DHCPv6 has
completed will the IPv6 subscriber host be instantiated and the BNG will start sending RAs if
configured. (It is a mandatory requirement for the BNG to send RAs which makes the enabling of
router-advertisements under the group-level a mandatory parameter). The router advertisements
do not contain any prefix information, which has already been provided by DHCPv6, but it is used
as an indication to the client that its default gateway should be the BNG sourcing this RA.
A:BNG-1#
configure service ies 1
subscriber-interface "sub-int-1"
address 10.1.0.254/16
group-interface "group-int-1"
ipv6
router-advertisements
no shutdown
exit
dhcp6
proxy-server
client-applications pppoe
no shutdown
exit
exit
exit
authentication-policy "radius-1"
sap 1/1/4:301
sub-sla-mgmt
sub-ident-policy "sub-ident-1"
multi-sub-sap 10
no shutdown
exit
exit
PPPoE
no shutdown
exit
exit
ipv6
delegated-prefix-len 56
subscriber-prefixes
prefix 2001:DB8:D001::/48 pd
exit
exit
exit
no shutdown

IPv6 subscriber prefixes must be defined at the subscriber-interface <sub-int-name> ipv6


subscriber-prefixes context.
Refer to Dual Stack PPPoE Bridged Gateway Service on page 710.

Page 718

Advanced Configuration Guide

ESMv6: PPPoE Dual Stack Hosts

Subscriber prefixes are subnetted in fixed length subnets that are assigned to subscriber hosts:

/delegated-prefix-len (/48..64) for p subscriber prefixes

The delegated prefix length is configured in the subscriber-interface <sub-int-name> ipv6


context. The recommended value is /56 (default = /64). The configured length applies to all pd
subscriber prefixes on a subscriber-interface.
Table 13 and Table 14 provide an overview of the subscriber-prefix parameters that apply and an
example of prefix subnetting for delegated-prefix-length /56.

Table 13: Subscriber-Prefix Parameters


Subscriber
Prefix Type

pd

Prefix Length

/48..64 *

DHCPv6 Option

IA-PD

SLAAC

N/A

RADIUS AVP

[123] DelegatedIPv6-Prefix

Must be
sub netted as

/delegatedprefix-len

*Must be smaller than configured delegated prefix length.

Table 14: Prefix Subnetting for delegated-prefix-length /56


Subscriber Prefix and /56
delegated-prefix-len

2001:db8:d001::/48

Framed-IPv6-Prefix

2001:db8:d001:100::/56

Hosts

Responsibility Home
Gateway (HGW)
Responsibility HGW
Responsibility HGW

2001:db8:d001:200::/56

Responsibility HGW
Responsibility HGW
Responsibility HGW

<snip>

--

2001:db8:d001:FF00::/56

Responsibility HGW
Responsibility HGW
Responsibility HGW

<snip>

Advanced Configuration Guide

--

--

Page 719

Configuration

Table 14: Prefix Subnetting for delegated-prefix-length /56 (Continued)


Subscriber Prefix and /56
delegated-prefix-len

2001:db8:d002::/48

Framed-IPv6-Prefix

2001:db8:d002:100::/56

Hosts

Responsibility HGW
Responsibility HGW
Responsibility HGW

2001:db8:d002:200::/56

Responsibility HGW
Responsibility HGW
Responsibility HGW

<snip>

--

2001:db8:d002:FF00::/56

Responsibility HGW
Responsibility HGW
Responsibility HGW

Page 720

Advanced Configuration Guide

ESMv6: PPPoE Dual Stack Hosts

RADIUS
The DHCPv6 proxy server mandates the use of RADIUS for PPPoE IPv6 subscriber host
authentication and authorization. The configuration is no different from an IPv4 subscriber host:
A:BNG-1#
configure subscriber-mgmt
authentication-policy "radius-1"
description "Radius authentication policy"
password <hashed password> hash2
radius-authentication-server
router "Base"
server 1 address 172.16.1.1 secret ALU
exit
exit
A:BNG-1#
configure service ies 1 customer 1
subscriber-interface "sub-int-1"
group-interface "group-int-1"
authentication-policy "radius-1"

Notice that for dual stack subscribers, it is mandatory to retrieve the IPv6 configuration
information through RADIUS. IPv4 configuration information can come from RADIUS or from a
different source (like the local user database or DHCPv4 server).
Additional RADIUS Attribute Value pairs (AVPs) that are applicable for PPPoE IPv6 subscriber
hosts are listed in the following section.

Table 15: RADIUS AVPs


RADIUS AVP

Type

Purpose

Framed-IPv6-Prefix [97]

ipv6prefix

Maps to SLAAC (RFC 4862) /64 Prefixinformation in ICMPv6 RA.

Delegated-IPv6-Prefix [123]

ipv6prefix

Maps to IA_PD for prefix delegation (RFC


3633) in DHCPv6

Alc-Ipv6-Primary-Dns [266527-105]

ipv6addr

Maps to DNS recursive name server option


(RFC 3646) in DHCPv6

Alc-Ipv6-Secondary-Dns [266527-106]

ipv6addr

Maps to DNS recursive name server option


(RFC 3646) in DHCPv6

Advanced Configuration Guide

Page 721

Configuration

Dual Stack PPPoE for Bridged Gateway


The following shows a sample of a FreeRADIUS user record to authenticate a dual stack PPPoE
subscriber for a bridged gateway:
"pppoev6-host1@isp1.com" Cleartext-Password := "ALU"
Framed-IP-Address = 10.1.0.1,
Framed-IP-Netmask = 255.255.255.0,
Alc-Subsc-ID-Str = "%{User-name}",
Alc-Subsc-Prof-Str = "sub-profile-1",
Alc-SLA-Prof-Str = "sla-profile-1",
Framed-IPv6-Prefix = "2001:db8:c001:0101::/64",
Alc-IPv6-Primary-DNS = "2001:db8:dddd:1::1",
Alc-IPv6-Secondary-DNS = "2001:db8:dddd:2::1"

Dual Stack PPPoE for Routed Gateway


The following shows a sample of a FreeRADIUS user record to authenticate a dual stack PPPoE
subscriber for a routed gateway:
"PPPoEv6-gw1@isp1.com"
Cleartext-Password := "ALU"
Framed-IP-Address = 10.1.0.2,
Framed-IP-Netmask = 255.255.255.0,
Alc-Subsc-ID-Str = "%{User-name}",
Alc-Subsc-Prof-Str = "sub-profile-1",
Alc-SLA-Prof-Str = "sla-profile-1",
Delegated-IPv6-Prefix = "2001:db8:d001:0100::/56",
Alc-IPv6-Primary-DNS = "2001:db8:dddd:1::1",
Alc-IPv6-Secondary-DNS = "2001:db8:dddd:2::1"

A RADIUS users configuration with multiple delegated-ipv6-prefixes for the same dual stack
PPPoE host will result in a single DHCPv6 advertise message sent by the BNG with a single
IA_PD option and single IA-Prefix. The other RADIUS configured delegated-IPv6-prefixes are
silently dropped by the BNG.

Page 722

Advanced Configuration Guide

ESMv6: PPPoE Dual Stack Hosts

Router Advertisements
ICMPv6 router advertisements have two major functions.

Default router function for hosts (applicable for IPoEv6 and PPPoEv6)

Address auto-configuration for hosts aka SLAAC (applicable for PPPoEv6 only)

Unsolicited RA must explicitly be enabled on a group interface (default shutdown) and are
refreshed with a pseudo random timer. The boundaries of this random timer are configurable with
the min-advertisement parameter (minimum with default set to 900s) and max-advertisement
(maximum with default set to 1800s).
A:BNG-1#
configure service ies 1 customer 1
subscriber-interface "sub-int-1"
group-interface "group-int-1"
ipv6
router-advertisements
max-advertisement 1800
min-advertisement 900
no shutdown
exit

# Default 30 min
# Default 15 min

The router-advertisements router-lifetime parameter (default 4500 sec) specifies how long the
host is allowed to use the originator of the RA as default gateway. This timer is configurable
between 2700 and 9000 seconds.
Configuring a smaller router-advertisements router-life timer than the router-advertisements
min-advertisement timer results in a dual stack PPPoE host without a default gateway.
A:BNG-1#
configure service ies 1 customer 1
subscriber-interface "sub-int-1"
group-interface "group-int-1"
ipv6
router-advertisements
router-lifetime 4500
no shutdown
exit

# Default 1h 15min

The prefix-options autonomous parameter below specifies whether or not offered RADIUS IPv6
prefix can be used for stateless address configuration (SLAAC). The prefix-options lifetime
parameter defines how long the host is allowed to use this prefix. Configuring a smaller prefixoption valid-lifetime than the router-advertisements min-advertisement timer results in host
traffic being sourced with the link-local address instead of global unique IPv6 address.

Advanced Configuration Guide

Page 723

Configuration

A:BNG-1#
configure service ies 1 customer 1
subscriber-interface "sub-int-1"
group-interface "group-int-1"
ipv6
router-advertisements
prefix-options
autonomous
preferred-lifetime 3600
valid-lifetime 86400
exit
no shutdown
exit

# Required for SLAAC


# Default 1 hour
# Default 24 hour

The following is a snapshot from an ICMPv6 RA message with default timer settings with a focus
on the SLAAC function.
Internet Control Message Protocol v6
Type: 134 (Router advertisement)
<snip>
ICMPv6 Option (Prefix information)
Type: Prefix information (3)
Length: 32
Prefix length: 64
Flags: 0x40
1... .... = on link
.1.. .... = Auto
..0. .... = Not router address
...0 .... = Not site prefix
Valid lifetime: 86400
Preferred lifetime: 3600
Prefix: 2001:DB8:C001:101::

Page 724

# Auto-Configuration flag

# Default value 24 hour


# Default value 1 hour
# SLAAC prefix

Advanced Configuration Guide

ESMv6: PPPoE Dual Stack Hosts

SLAAC-related parameters are listed in Table 16:


Table 16: SLAAC-Related Parameters
Parameter

Description (RFC-4861)

Value Range
(Default)

prefix-options:
autonomous

Autonomous address-configuration flag.


When set indicates that this prefix can be used
for stateless address auto configuration
(SLAAC)

(no)

prefix-options:
preferred-lifetime

The length of time in seconds that the


addresses generated from the prefix through
stateless address auto configuration (SLAAC)
remains preferred.

0..4294967295 s
(3600s) 1hour

prefix-options: validlifetime

The length of time in seconds that the prefix is


valid for the purpose of on-link determination.

0..4294967295 s
(86400s) 24hours

Note that additional router advertisements parameters common to PPPoEv6 and IPoEv6 are listed
and explained in ESMv6: IPoE Dual Stack Hosts on page 663.
For dual stack PPPoE hosts the default values, as shown in the following output, can be used.
Timer values equal to zero (reachable-time and retransmit-time) causes the host to use its own
timers for that function. The reachable-time is used by the host for
Neighbor_Unreachable_Detection (NUD) whereas the retransmit-time is used by the host for
Duplicate_Address_Detection (DAD). DAD is normally only performed by dual stack IPoE hosts
and not by dual stack PPPoE hosts.
A:BNG-1#
configure service ies 1 customer 1
subscriber-interface "sub-int-1"
group-interface "group-int-1"
ipv6
router-advertisements
current-hop-limit 64
no managed-configuration
no mtu
no other-stateful-configuration
reachable-time 0
retransmit-time 0
exit

Advanced Configuration Guide

#
#
#
#
#
#

default
default
default
default
default
default

value
value
value
value
value
value

Page 725

Configuration

DHCPv6 Proxy Server


Dual Stack PPPoE for Bridged Gateway
This dual stack PPPoE host uses SLAAC for address assignment and does not require DHCPv6
for this assignment. The 7750 SR however does not support DNSv6 information through the RA
DNS Option (RFC 5006, IPv6 Router Advertisement Option for DNS Configuration) which forces
the use of DHCPv6 information requests and replies to retrieve the DNSv6 information. The
DHCPv6 proxy server must be enabled (the default is shutdown) and PPPoE defined as clientapplication (default=dhcp only). No lease state is kept for this DNSv6 information and therefore it
is known as Stateless DHCPv6.
A:BNG-1#
configure service ies 1 customer 1
subscriber-interface "sub-int-1"
group-interface "group-int-1"
ipv6
dhcp6
proxy-server
client-applications PPPoE
no shutdown

Dual Stack PPPoE for Routed Gateway


An IPv6 PPPoE routed gateway initiates, after successful IPv6CP negotiation, a DHCPv6 session
to request its configuration data (IPv6 PD prefixes, DNS servers). A DHCPv6 proxy server in the
BNG maintains the DHCPv6 session with the IPv6 PPPoE subscriber host. The DHCPv6 proxy
server must be enabled (the default is shutdown) and PPPoE defined as client-application
(default=dhcp only).
A:BNG-1#
configure service ies 1 customer 1
subscriber-interface "sub-int-1"
group-interface "group-int-1"
ipv6
dhcp6
proxy-server
renew-timer 1800
rebind-timer 2880
valid-lifetime 86400
preferred-lifetime 3600
client-applications pppoe
no shutdown
exit

Page 726

#
#
#
#

default
default
default
default

Advanced Configuration Guide

ESMv6: PPPoE Dual Stack Hosts

Note that a number of timers associated with IPv6 addresses and IPv6 prefixes within DHCPv6
identity associations can be configured in the DHCPv6 proxy server. These timers are valid for
IPoEv6 and PPPoEv6 sessions and are listed and further explained in ESMv6: IPoE Dual Stack
Hosts on page 663.
There is never RADIUS re-authentication for dual stack PPPoE routed gateways on DHCPv6
renewals as indicated in Figure 36.

RADIUS
Dual Stack
Home
Network

Dual Stack PPPoE


Routed Gateway

IPv4@

Dual Stack
BNG-1
BSAN

IPv4@

IES 1

IPv6@

10.1.0.254
2001:DB8:D001::/48
CHAP Challenge/Response

PE-1

RADIUS Access Request


RADIUS Access Accept

CHAP Authentication Successful


IPCP / IPv6CP

DHCP6 Solicit
DHCP6 Advertise
DHCP6 Request
DHCP6 Reply
Renew-timer
DHCP6 Renew

There is never
re-authentication
for PPPoEv6 hosts.

DHCP6 Reply

OSSG584

Figure 36: DHCPv6 Renewals

Advanced Configuration Guide

Page 727

Configuration

DHCPv6 Lease State


The DHCPv6 lease state is an internal database structure that keeps track of the DHCPv6 host
states. The DHCP lease information for a specific host is extracted from the DHCPv6 reply
message in case of DHCPv6. Stateful (with lease state) DHCPv6 is applicable for dual stack
PPPoE on routed gateway where Stateless (without lease state) DHCPv6 is optional and
applicable for dual stack PPPoE on bridged gateways.
For more information on DHCPV6 lease states, see ESMv6: IPoE Dual Stack Hosts on page 663.

Page 728

Advanced Configuration Guide

ESMv6: PPPoE Dual Stack Hosts

Operation
Dual Stack PPPoE for Bridged Gateway
A PPPoEv6 dual stack subscriber scenario for a bridged home gateway consumes two subscriber
host entries sharing a common subscriber.

IPv4 host-addressing by IPCP

IPv6 wan-host addressing by SLAAC

A:BNG-1# show service active-subscribers subscriber "pppoev6-host1@isp1.com"


============================================================
Active Subscribers
============================================================
----------------------------------------------------------Subscriber pppoev6-host1@isp1.com (sub-profile-1)
-----------------------------------------------------------(1) SLA Profile Instance sap:1/1/4:301 - sla:sla-profile-1
----------------------------------------------------------IP Address
MAC Address
PPPoE-SID
Origin
-------------------------------------------------------10.1.0.1
00:0c:29:54:30:bf
1
IPCP
2001:DB8:C001:101::/64
00:0c:29:54:30:bf
1
PPP-SLAAC
-----------------------------------------------------------Number of active subscribers: 1

The hierarchy parameter for active-subscribers gives a top level down overview for this
subscriber.
A:BNG-1# show service active-subscribers hierarchy subscriber "pppoev6-host1@isp1.com"
============================================================================
Active Subscriber hierarchy
============================================================================
-- pppoev6-host1@isp1.com (sub-profile-1)
|
|-- sap:1/1/4:301 - sla:sla-profile-1
|
|
|
|-- 10.1.0.1
|
|
00:0c:29:54:30:bf - 1 (IPCP)
|
|
|
|-- 2001:DB8:C001:101::/64
|
|
00:0c:29:54:30:bf - 1 (PPP-SLAAC)
|
|
============================================================================
A:BNG-1#

Advanced Configuration Guide

Page 729

Configuration

IPCP and IPv6CP are in an opened state for the dual stack PPPoE session and it is mandatory that
their origin is RADIUS, as shown below.
A:BNG-1# show service id 1 PPPoE session ip-address 10.1.0.1 detail
==================================================================
PPPoE sessions for svc-id 1
==================================================================
Sap Id
Mac Address
Sid
Up Time
Type
IP/L2TP-Id/Interface-Id
----------------------------------------------------------------1/1/4:301
00:0c:29:54:30:bf 1
0d 00:04:03
Local
10.1.0.1
81:35:1D:7C:1F:3F:8B:41
LCP State
IPCP State
IPv6CP State
PPP MTU
PPP Auth-Protocol
PPP User-Name

:
:
:
:
:
:

Opened
Opened
Opened
1492
CHAP
pppoev6-host1@isp1.com

Subscriber-interface : sub-int-1
Group-interface
: group-int-1
Subscriber Origin
Strings Origin
IPCP Info Origin
IPv6CP Info Origin

:
:
:
:

Radius
Radius
Radius
Radius

Subscriber
Sub-Profile-String
SLA-Profile-String

: "pppoev6-host1@isp1.com"
: "sub-profile-1"
: "sla-profile-1"

<snip>
IPv6 Prefix
IPv6 Del.Pfx.
Primary IPv6 DNS
Secondary IPv6 DNS

:
:
:
:

2001:DB8:C001:101::/64
N/A
2001:DB8:DDDD:1::1
2001:DB8:DDDD:2::1

#SLAAC

<snip>
--------------------------------------------------------Number of sessions
: 1

Page 730

Advanced Configuration Guide

ESMv6: PPPoE Dual Stack Hosts

The IPv6 routing table for dual stack hosts is displayed using the protocol keyword sub-mgmt.
A:BNG-1# show router route-table ipv6 protocol sub-mgmt
============================================================================
IPv6 Route Table (Router: Base)
============================================================================
Dest Prefix
Type
Proto
Age
Pref
Next Hop[Interface Name]
Metric
---------------------------------------------------------------------------2001:DB8:C001:101::/64
Remote Sub Mgmt 00h20m01s
0
[group-int-1]
0

Advanced Configuration Guide

Page 731

Configuration

DNSv6
DNSv6 information, in a dual stack PPPoE bridged gateway model, is optionally retrieved through
stateless DHCPv6 information requests. Debugging is done through debug commands or/and
observation by statistics counters.
Request and Reply:
00 2010/07/23 14:16:40.01 IST MINOR: DEBUG #2001 Base TIP
"TIP: DHCP6_PKT
Incoming DHCP6 Msg : INFO_REQUEST (11)
on itf group-int-1
Trans Id : 0xcef3f0
Option : CLIENTID (1), Length : 14
LLT : HwTyp=0001,T=322878930,LL=000c29c851ca
00010001133ebdd2000c29c851ca
Option : ELAPSED_TIME (8), Length : 2
Time : 100 seconds
Option : ORO (6), Length : 4
Requested Option : DNS_NAME_SRVR (23)

101 2010/07/23 14:16:40.02 IST MINOR: DEBUG #2001 Base TIP


"TIP: DHCP6_PKT
Outgoing DHCP6 Msg : REPLY (7)
to itf group-int-1
Trans Id : 0xcef3f0
Option : SERVERID (2), Length : 10
LL : HwTyp=0001,LL=24b1ff000000
0003000124b1ff000000
Option : CLIENTID (1), Length : 14
LLT : HwTyp=0001,T=322878930,LL=000c29c851ca
00010001133ebdd2000c29c851ca
Option : DNS_NAME_SRVR (23), Length : 32
Server : 2001:DB8:DDDD:1::1
# retrieved from radius
Server : 2001:DB8:DDDD:2::1
# retrieved from RADIUS

Page 732

Advanced Configuration Guide

ESMv6: PPPoE Dual Stack Hosts

DHCPv6 statistics
A:BNG-1# clear router dhcp6 statistics
A:BNG-1# show router dhcp6 statistics
===========================================================================
DHCP6 statistics (Router: Base)
===========================================================================
Msg-type
Rx
Tx
Dropped
--------------------------------------------------------------------------1 SOLICIT
0
0
0
2 ADVERTISE
0
0
0
3 REQUEST
0
0
0
4 CONFIRM
0
0
0
5 RENEW
0
0
0
6 REBIND
0
0
0
7 REPLY
0
1
0
8 RELEASE
0
0
0
9 DECLINE
0
0
0
10 RECONFIGURE
0
0
0
11 INFO_REQUEST
1
0
0
12 RELAY_FORW
0
0
0
13 RELAY_REPLY
0
0
0

Entries, for dual stack PPPoE subscribers, in the IPv4 ARP and/or IPv6 neighbor cache table are
counted as internal entries and are shown from the summary parameter.
A:BNG-1# show router arp summary
======================================
ARP Table Summary (Router: Base)
======================================
Local ARP Entries
: 0
Static ARP Entries
: 0
Dynamic ARP Entries : 0
Managed ARP Entries : 0
Internal ARP Entries : 1
--------------------------------------No. of ARP Entries
: 1
A:BNG-1# show router neighbor summary
=======================================
Neighbor Table Summary (Router: Base)
=======================================
Static Nbr Entries
: 0
Dynamic Nbr Entries
: 0
Managed Nbr Entries
: 0
Internal Nbr Entries
: 1
---------------------------------------No. of Neighbor Entries : 1

Advanced Configuration Guide

Page 733

Configuration

Dual Stack PPPoE for Routed Gateway


A PPPoEv6 dual stack subscriber scenario for a routed CPE consumes two subscriber host entries
sharing a common subscriber.

IPv4 host addressing through IPCP

IPv6 pd addressing through DHCPv6

A:BNG-1#
show service active-subscribers subscriber "PPPoEv6-rgw1@isp1.com"
============================================================================
Active Subscribers
============================================================================
---------------------------------------------------------------------------Subscriber PPPoEv6-rgw1@isp1.com (sub-profile-1)
---------------------------------------------------------------------------(1) SLA Profile Instance sap:1/1/4:301 - sla:sla-profile-1
---------------------------------------------------------------------------IP Address
MAC Address
PPPoE-SID Origin
----------------------------------------------------------10.1.0.2
00:0c:29:54:30:bf 1
IPCP
2001:DB8:D001:100::/56
00:0c:29:54:30:bf 1
PPP-DHCP6
-----------------------------------------------------------Number of active subscribers: 1

The hierarchy parameter for active-subscribers gives a top level down overview for this
subscriber.
A:BNG-1#
show service active-subscribers hierarchy subscriber "PPPoEv6-rgw1@isp1.com"
============================================================================
Active Subscriber hierarchy
============================================================================
-- PPPoEv6-rgw1@isp1.com (sub-profile-1)
|
|-- sap:1/1/4:301 - sla:sla-profile-1
|
|
|
|-- 10.1.0.2
|
|
00:0c:29:54:30:bf - 1 (IPCP)
|
|
|
|-- 2001:DB8:D001:100::/56
|
|
00:0c:29:54:30:bf - 1 (PPP-DHCP6)
===========================================================================

Page 734

Advanced Configuration Guide

ESMv6: PPPoE Dual Stack Hosts

IPCP and IPv6CP are in an opened state for the dual stack PPPoE session and it is mandatory that
their origin is RADIUS, as shown below.
A:BNG-1# show service id 1 PPPoE session ip-address 10.1.0.2 detail
==================================================================
PPPoE sessions for svc-id 1
==================================================================
Sap Id
Mac Address
Sid
Up Time
Type
IP/L2TP-Id/Interface-Id
----------------------------------------------------------------1/1/4:301
00:0c:29:54:30:bf 1
0d 00:05:23
Local
10.1.0.2
B5:4B:0D:D7:69:9E:CD:7F
LCP State
IPCP State
IPv6CP State
PPP MTU
PPP Auth-Protocol
PPP User-Name

:
:
:
:
:
:

Opened
Opened
Opened
1492
CHAP
PPPoEv6-rgw1@isp1.com

Subscriber-interface : sub-int-1
Group-interface
: group-int-1
Subscriber Origin
Strings Origin
IPCP Info Origin
IPv6CP Info Origin

:
:
:
:

Radius
Radius
Radius
Radius

Subscriber
Sub-Profile-String
SLA-Profile-String

: "PPPoEv6-rgw1@isp1.com"
: "sub-profile-1"
: "sla-profile-1"

<snip>
IPv6 Prefix
: N/A
IPv6 Del.Pfx.
: 2001:DB8:D001:100::/56
#IA-PD
Primary IPv6 DNS
: 2001:DB8:DDDD:1::1
Secondary IPv6 DNS
: 2001:DB8:DDDD:2::1
<snip>
--------------------------------------------------------Number of sessions
: 1

The IPv6 routing table for dual stack hosts is displayed using the protocol keyword sub-mgmt.
A:BNG-1# show router route-table ipv6 protocol sub-mgmt
============================================================================
IPv6 Route Table (Router: Base)
============================================================================
Dest Prefix
Type
Proto
Age
Pref
Next Hop[Interface Name]
Metric
---------------------------------------------------------------------------2001:DB8:D001:100::/56
Remote Sub Mgmt 00h06m45s
0
[group-int-1]

Advanced Configuration Guide

Page 735

Configuration

DNSv6
DNSv6 information, in a dual stack PPPoE routed gateway model, is optionally retrieved by
stateful DHCPv6 information requests. Debugging is done through debug commands or/and
observation by statistics counters.
Solicit and Advertise
171 2010/07/23 15:01:18.24 IST MINOR: DEBUG #2001 Base TIP
"TIP: DHCP6_PKT
Incoming DHCP6 Msg : SOLICIT (1)
on itf group-int-1
Trans Id : 0xb6f6f1
Option : CLIENTID (1), Length : 14
LLT : HwTyp=0001,T=322878930,LL=000c29c851ca
00010001133ebdd2000c29c851ca
Option : IA_PD (25), Length : 12
IAID : 1
Time1: 4294967295 seconds
Time2: 4294967295 seconds
Option : ELAPSED_TIME (8), Length : 2
Time : 100 seconds
Option : ORO (6), Length : 4
Requested Option : DNS_NAME_SRVR (23)
172 2010/07/23 15:01:18.23 IST MINOR: DEBUG #2001 Base TIP
"TIP: DHCP6_PKT
Outgoing DHCP6 Msg : ADVERTISE (2)
to itf group-int-1
Trans Id : 0xb6f6f1
Option : SERVERID (2), Length : 10
LL : HwTyp=0001,LL=24b1ff000000
0003000124b1ff000000
Option : CLIENTID (1), Length : 14
LLT : HwTyp=0001,T=322878930,LL=000c29c851ca
00010001133ebdd2000c29c851ca
Option : DNS_NAME_SRVR (23), Length : 32
Server : 2001:DB8:DDDD:1::1
Server : 2001:DB8:DDDD:2::1
Option : IA_PD (25), Length : 41
IAID : 1
Time1: 1800 seconds
Time2: 2880 seconds
Option : IAPREFIX (26), Length : 25
Prefix : 2001:DB8:D001:100::/56
Preferred Lifetime : 3600 seconds
Valid Lifetime
: 86400 seconds

Page 736

Advanced Configuration Guide

ESMv6: PPPoE Dual Stack Hosts

Request and Reply


3 2010/07/23 15:01:20.24 IST MINOR: DEBUG #2001 Base TIP
"TIP: DHCP6_PKT
Incoming DHCP6 Msg : REQUEST (3)
on itf group-int-1
Trans Id : 0x1c52e7
Option : CLIENTID (1), Length : 14
LLT : HwTyp=0001,T=322878930,LL=000c29c851ca
00010001133ebdd2000c29c851ca
Option : IA_PD (25), Length : 12
IAID : 1
Time1: 4294967295 seconds
Time2: 4294967295 seconds
Option : ELAPSED_TIME (8), Length : 2
Time : 300 seconds
Option : ORO (6), Length : 4
Requested Option : DNS_NAME_SRVR (23)
Option : SERVERID (2), Length : 10
LL : HwTyp=0001,LL=24b1ff000000
0003000124b1ff000000
176 2010/07/23 15:01:20.25 IST MINOR: DEBUG #2001 Base TIP
"TIP: DHCP6_PKT
Outgoing DHCP6 Msg : REPLY (7)
to itf group-int-1
Trans Id : 0x1c52e7
Option : SERVERID (2), Length : 10
LL : HwTyp=0001,LL=24b1ff000000
0003000124b1ff000000
Option : CLIENTID (1), Length : 14
LLT : HwTyp=0001,T=322878930,LL=000c29c851ca
00010001133ebdd2000c29c851ca
Option : DNS_NAME_SRVR (23), Length : 32
Server : 2001:DB8:DDDD:1::1
Server : 2001:DB8:DDDD:2::1
Option : IA_PD (25), Length : 41
IAID : 1
Time1: 1800 seconds
Time2: 2880 seconds
Option : IAPREFIX (26), Length : 25
Prefix : 2001:DB8:D001:100::/56
Preferred Lifetime : 3600 seconds
Valid Lifetime
: 86400 seconds

Advanced Configuration Guide

Page 737

Configuration

DHCPv6 statistics:
A:BNG-1# clear router dhcp6 statistics
A:BNG-1# show router dhcp6 statistics
===========================================================================
DHCP6 statistics (Router: Base)
===========================================================================
Msg-type
Rx
Tx
Dropped
--------------------------------------------------------------------------1 SOLICIT
1
0
0
2 ADVERTISE
0
1
0
3 REQUEST
1
0
0
4 CONFIRM
0
0
0
5 RENEW
0
0
0
6 REBIND
0
0
0
7 REPLY
0
1
0
8 RELEASE
0
0
0
9 DECLINE
0
0
0
10 RECONFIGURE
0
0
0
11 INFO_REQUEST
0
0
0
12 RELAY_FORW
0
0
0
13 RELAY_REPLY
0
0
0

Page 738

Advanced Configuration Guide

ESMv6: PPPoE Dual Stack Hosts

Debugging
To troubleshoot a PPPoE dual stack host session, use:

Log-id 99: Default system log and use appropriate filtering to reduce the output if needed.

A:BNG-1# show log log-id 99

Debug PPPoE

A:BNG-1# show debug


debug
service
id 1
PPPoE
packet
mode egr-ingr-and-dropped
detail-level high
discovery
ppp
dhcp-client
exit
exit
exit
exit

Debug radius

A:BNG-1# show debug


debug
radius detail
exit

Debug dhcpv6

A:BNG-1# show debug


debug
router "Base"
ip
dhcp6
mode egr-ingr-and-dropped
detail-level high
exit
exit
exit
exit

Advanced Configuration Guide

Page 739

Configuration

DHCPv6 and PPPoE protocol statistics:

A:BNG-1# show router dhcp6 statistics


A:BNG-1# show service id 1 PPPoE session statistics

Page 740

Advanced Configuration Guide

ESMv6: PPPoE Dual Stack Hosts

Advanced Topics
RADIUS COA
For dual stack PPPoE subscriber hosts, RADIUS-triggered mid-session change or/and session
terminations identify the subscriber host to be changed by the same prefix that was originally
returned from RADIUS or by the host-session-id (If RADIUS accounting host-accounting is
enabled and the accounting session-id format equals number. Changing either the IPv4 or IPv6
information will result in both the v4 and v6 subscriber hosts being modified. Further elaboration
on accounting is out of scope in this document.

IPv6CP Interface ID
IPv6CP negotiates, unlike ipv4-addresses in IPv4CP, only interface-ids (interface-id: The last 64
bits of an IPv6 address is the interface identifier that is unique to the 64-bit prefix of the IPv6
address and is usually derived from the link-layer or MAC address).
Dual stack PPPoE subscribers and the BNG exchange their interface-ids during this NCP phase.
For ESM subscriber-interfaces on the BNG the interface-id is derived from the chassis-mac
address.

The BNG will nack the PPPoE hosts IPv6CP configuration request if the dual stack
PPPoE host negotiates an interface-id equal zero or an interface-id equal to the BNG
interface ID. In that scenario the BNG offers in the IPv6CP nack message a suitable
interface ID with following format:

Table 17: IPv6CP Nack Message Format


1

SAP ID

Last 2 bytes MAC


host

Session ID

The BNG terminates the session if the dual stack PPPoE hosts nacks its IPv6CP
configuration request and offers something else to the BNG.

Advanced Configuration Guide

Page 741

Conclusion

Conclusion
This note provides configuration and troubleshooting commands for dual stack PPPoE subscribers
on bridged or routed gateways. SLAAC is used as IPv6 address assignment for bridged gateways
and stateful DHCPv6 prefix-delegation is used for address assignment for on routed gateways. No
RG WAN IPv6 address assignment is supported in this latter model.
DNSv6 addressing on a bridged gateway is retrieved by stateless DHCPv6 (information request
and reply) and it is mandatory that all IPv6 address information is retrieved through RADIUS.

Page 742

Advanced Configuration Guide

Flexible Authentication Model in ESM

In This Chapter
This section provides information about Flexible Authentication Models in ESM.
Topics in this section include:

Applicability on page 744

Overview on page 745

Configuration on page 747

Conclusion on page 788

Advanced Configuration Guide

Page 743

Applicability

Applicability
This example is applicable to Routed Central Office (RCO) model on 7750 SR-7/12/12e, 7750
SR-c4/12 and 7450 ESS 7/12 in mixed-mode with IOM3-XP or IMM.
The configuration was tested on release 11.0R2 in a single-homed scenario.

Page 744

Advanced Configuration Guide

Flexible Authentication Model in ESM

Overview
The flexible authentication model for IPoE and PPPoE subscribers allows for mixing of
configuration parameters obtained during the authentication phase from different sources: LUDB,
RADIUS or Local User Database (LUDB), RADIUS or DHCP options that can be populated via a
custom Python script. In case the same parameter is available from multiple sources, a priority
mechanism is enforced whereby the parameter received from a higher priority source overrides the
parameters received from the lower priority source in the following priority LUDB to RADIUS to
Python.
In this example we will configure a dual-stack IPoE and a dual stack PPPoE host using 4 different
methods to obtain their configuration parameters. The setup will utilize a single 7x50 BNG node
with a locally configured DHCP server and LUDB as well as an external RADIUS server.
Subscriber hosts are instantiated on managed (dynamic) SAPs.
The subscriber configuration parameters are in general divided into two categories:

IP addressing parameters of the host IPv4/v6 address/prefix, DNS servers, IPv4


default-gateway, IPv4 subnet-mask, IPv4/v6 address pool name, DHCPv4/v6 lease times,
etc.

Non IP addressing parameters of the host Subscriber hosts strings are used to associate
the subscriber-host with the desired level of service (sub/sla-profiles, inter-dest-id string,
etc); managed routes are used for routing purposes to/from the host; etc.

The following four scenarios will be examined:


1. DHCP relay case (IP address is assigned via local DHCP server) with NO authentication. See
page 751.
2. DHCP relay case (IP address is assigned via local DHCP server) with LUDB + RADIUS
authentication. See page 759.
RADIUS provides: sub/sla-profile strings and a framed IPv4 route.
LUDB provides: IP address pool, inter-dest-id string for Vport assignment, msap-defaults
(routing context parameters and msap-policy).
3. IP proxy case (IP address is assigned via RADIUS) with LUDB + RADIUS authentication.
page 769
RADIUS provides: IP addresses1 and related parameters (DNS server, IPv4 defaultgateway, etc), inter-dest-id string for Vport assignment and a framed route.
LUDB provides: sub/sla-profile strings and msap-defaults (routing context parameters
and msap-policy).
4. IP proxy case (IP address is assigned via LUDB) with LUDB + RADIUS authentication.
page 778
1.

IPv6 lease-times are provided under the group-interface.

Advanced Configuration Guide

Page 745

Overview

RADIUS provides: sub/sla-profile strings and a framed IPv4 route.


LUDB provides IP addresses and related parameters (DNS server, IPv4 default-gateway,
etc), inter-dest-id string for Vport assignment and msap-defaults (routing context
parameters and msap-policy).
In cases 2-4, the domain-name alu-domain is appended to the IPoE and PPPoE username in
LUDB, just before RADIUS authentication takes place.

Page 746

Advanced Configuration Guide

Flexible Authentication Model in ESM

Configuration
The topology is shown in Figure 37.
RADIUS
Server

1/1/10
DHCPv4/6 (LDRA),
PPPoEv4/6
Client Simulator

DHCPv4/6 Server
V4: 10.10.1.1
V6: 2001:db8::1/128
1/1/5

7750 BNG

LUDB

al_0260

Figure 37: Topology

There is a common part of the configuration that applies uniformly across all four examined
scenarios. This common part is outlined below and will not be repeated again when we describe
more specific cases. It is assumed that the more specific cases also contain this common part of the
configuration.

Advanced Configuration Guide

Page 747

Configuration

Common Configuration Examples


Access Ethernet Port with QinQ Encapsulation
The following output displays a configuration example.
configure port 1/1/5
ethernet
mode access
encap-type qinq
exit
no shutdown

Capture SAP
A capture SAP is used to dynamically detect the VLAN id(s) in incoming DHCP/PPPoE packets
(triggering packets) and conditionally instantiate the managed (dynamic) SAP. LUDB must be
configured under the capture SAP to authorize the user accessing the capture SAP. The LUDB
may contain additional parameters needed to setup the subscriber, it can point the subscriber to the
RADIUS server for additional parameters or it may contain a default subscriber-host entry without
any configuration parameters.
In this case the msap-defaults under the capture SAP is used to select the routing context where
the msap is created. msap-defaults can be also configured in the LUDB or be supplied via
RADIUS.
PPPoE policy and msap policy are used to define PPPoE and SAP level parameters. Since the
(dynamic) SAP does not exist at the time when the initial DHCP/PPPoE packets are received, the
PPPoE/SAP level parameters are taken from the PPPoE/msap policy under the capture SAP. For
example, those parameters are used in the PPP PADx/LCP/Authentication setup phase, they define
default subscriber host strings, maximum number of subscriber hosts per SAP, the anti-spoofing
mode, etc.
configure service vpls 2
sap 1/1/5:17.* capture-sap create
description "open DHCP model testing"
trigger-packet dhcp dhcp6 pppoe
dhcp-user-db "open-dhcp"
dhcp6-user-db "open-dhcp"
pppoe-policy "pppoe_pol"
pppoe-user-db "open-dhcp"
msap-defaults
group-interface "open-auth"
policy "msaps"
service 10
exit
exit

Page 748

Advanced Configuration Guide

Flexible Authentication Model in ESM

auto-sub-id
The auto-sub-id-key command can be used in situations where the more specific subscriber-id
string is not returned from LUDB or RADIUS. In this case, the auto subscriber-id for IPoE hosts is
set to the circuit-id while for PPPoE hosts the auto subscriber-id is set to the circuit-id plus
session-id separated by the |delimiter which is inserted by default.
configure subscriber-mgmt auto-sub-id-key
ipoe-sub-id-key circuit-id
ppp-sub-id-key circuit-id session-id

PPPoE Policy
There is a maximum of PPPoE sessions per MAC on a managed SAP. The default is 1 but is
increased here to 10.
configure subscriber-mgmt ppp-policy "pppoe_pol"
ppp-mtu 1400
max-sessions-per-mac 10

MSAP Policy
The MSAP policy defines the anti-spoofing mode which is in this particular example set to nexthop MAC (nh-mac). It also defines the default subscriber management parameters in case they are
not supplied via LUDB or RADIUS.
configure subscriber-mgmt msap-policy <msap-policy-name> create
sub-sla-mgmt
def-sub-id use-auto-id
def-sub-profile "default-sub-profile"
def-sla-profile "default-sla"
sub-ident-policy "sub_ident_pol"
multi-sub-sap limit 500
exit
ies-vprn-only-sap-parameters
anti-spoof nh-mac
exit

Advanced Configuration Guide

Page 749

Configuration

subscriber-interface Configuration
The following output displays a subscriber interface configuration.
configure service vprn 10
subscriber-interface "sub-int-1" create
allow-unmatching-subnets
address 10.12.0.1/24
ipv6
delegated-prefix-len 56
allow-unmatching-prefixes
exit
group-interface "open-auth" create
ipv6
router-advertisements
managed-configuration
no shutdown
exit
dhcp6
user-db "open-dhcp"
exit
exit
arp-populate
dhcp
trusted
lease-populate 1000
user-db "open-dhcp"
exit
pppoe
policy "pppoe_pol"
session-limit 1000
sap-session-limit 1000
user-db "open-dhcp"
no shutdown
exit

Support for un-numbered2 IPv4 clients.


Default gateway for IPv4 numbered clients.
Fixed delegated prefix length for IA-PD.
Support for un-numbered IPv6 clients.

Hint to the client to use DHCPv6.


Enabling Router-Advertisements.

Must be the same as under the capture-sap.

ARP table is populated based on the lease-state table.


Accept DHCP packets on this group-interface.
Max number of DHCPv4 clients on this grp-intf.
Must be the same as under the capture-sap.

Must be the same as under the capture-sap.

2. numbered/unnumbered subscriber-hosts. Refer to the DHCP/PPPoE clients whose assigned IP


address is outside of any IP subnet/prefix configured under the subscriber-interface.

Page 750

Advanced Configuration Guide

Flexible Authentication Model in ESM

Specific Configuration Parts


DHCP Relay Case with No Authentication
The IP address is assigned via local DHCP server. The LUDB is accessed even in the scenario
without authentication. There must be a default host LUDB entry present that will match on any
value specified in the match-list criteria. The LUDB is accessed from the capture SAP (part of the
common configuration).
configure subscriber-mgmt local-user-db "open-dhcp" create
dhcp
match-list circuit-id
Host matching based on circuit-id in DHCP packets.
host "default" create
no shutdown
exit
exit
ppp
match-list username
Host matching based on PPPoE username.
host "default" create force-ipv6cp
Explicitly enabled IPCPv6.
no shutdown
exit
exit
no shutdown

Once the routing context (service id and group-interface) is determined as defined under the
capture SAP defaults (part of the common configuration), the DHCP/PPPoE requests are served
according to the group-interface configuration. The IP address request is relayed to the DHCPv4/
v6 server. Since the LUDB does not provide a pool name, the gi-address and the link-address is
used by the DHCP relay/server to select the pool from which the IP address will be assigned.
configure service vprn 10 subscriber-interface
auth" create
ipv6
dhcp6
relay
link-address 2001:DB8:1::
server 2001:DB8::1
client-applications dhcp ppp
no shutdown
exit
exit
exit
dhcp
server 10.10.1.1
client-applications dhcp ppp
gi-address 10.12.0.1
no shutdown
exit

Advanced Configuration Guide

"sub-int-1" group-interface "open-

DHCPv6 relay configuration.


DHCPv6 server IPv6 address.

DHCPv4 server IP address.

Page 751

Configuration

DHCPv4/v6 servers are locally configured in the 7x50 and attached to a loopback interface.
configure service vprn 10 interface "loop-dhcp-srvr"
address 10.10.1.1/24IPv4
Address to which is DHCPv4 server attached.
ipv6
address 2001:DB8::1/128
IPv6 address to which is DHCPv6 server attached.
local-dhcp-server "v6"
Attaching DHCPv6 server to the loopback intf.
exit
local-dhcp-server "local"
Attaching DHCPv4 server to the loopback intf.
loopback

In the local DHCP servers two pools are defined:

LUDB To be used for IP address assignment when LUDB returns the pool name.

Gi-addr To be used when gi-address/link-address are used to select the pool for IP
address assignment.

Lease times for IPv4 and IPv6 are configured in the local DHCP server which is used only in the
relay case (when the IP address is supplied via DHCP server and not through RADIUS or the
LUDB).
configure service vprn 10
dhcp
local-dhcp-server "local" create
use-gi-address
The gi-address can be used to select the pool.
use-pool-from-client
The pool name can be explicitly provided.
pool "ludb" create
The pool used when LUDB provides the pool name.
options
dns-server 172.16.16.16 172.16.16.17
lease-time hrs 1
DHCPv4 lease time.
exit
subnet 10.10.0.0/24 create
options
subnet-mask 255.255.255.0
default-router 10.10.0.1
exit
address-range 10.10.0.100 10.10.0.200
exit
exit
pool "gi-addr" create
Pool selected based on the gi-address.
options
dns-server 172.16.16.16 172.16.16.17
lease-time hrs 1
DHCPv4 lease time.
exit
subnet 10.12.0.0/24 create
options
subnet-mask 255.255.255.0
default-router 10.12.0.1
exit
address-range 10.12.0.100 10.12.0.200
exit
exit
no shutdown
exit

Page 752

Advanced Configuration Guide

Flexible Authentication Model in ESM

exit
dhcp6
local-dhcp-server "v6" create
use-link-address
use-pool-from-client
pool "ludb" create
prefix 2001:DB8:10::/48 pd wan-host create
preferred-lifetime min 30
rebind-timer min 20
renew-timer min 15
valid-lifetime hrs 1
DHCPv6 lease time.
options
dns-server 2001:DB8::1000 2001:DB8::1001
exit
exit
exit
pool "gi-addr" create
prefix 2001:DB8:30::/48 pd wan-host create
preferred-lifetime min 30
rebind-timer min 20
renew-timer min 15
valid-lifetime hrs 1
DHCPv6 lease time.
options
dns-server 2001:DB8::1000 2001:DB8::1001
exit
exit
exit
no shutdown

Default sub/sla-profiles, from the msap-policy, are used (part of the common configuration).
configure subscriber-mgmt sla-profile "default-sla"
description "default SLA profile"
host-limit 3
configure subscriber-mgmt sub-profile "default-sub-profile"
description "default SUB profile"
egress
agg-rate-limit 1000
exit

Advanced Configuration Guide

Page 753

Configuration

Show Commands
The following command shows that the default sub/sla-profiles are in use, that the IP addresses are
selected from the gi-addr pool in local DHCP server and that the subscriber-id is set to circuit-id
for the IPoE subscriber-host and to username|session-id combination for the PPPoE subscriberhost.
A:BNG-1# show service active-subscribers
===============================================================================
Active Subscribers
===============================================================================
------------------------------------------------------------------------------Subscriber open-dhcp (default-sub-profile)
------------------------------------------------------------------------------------------------------------------------------------------------------------(1) SLA Profile Instance sap:[1/1/5:17.10] - sla:default-sla
------------------------------------------------------------------------------IP Address
MAC Address
PPPoE-SID Origin
-------------------------------------------------------10.12.0.101
00:00:65:17:10:01 N/A
DHCP
2001:DB8:30::1/128
00:00:65:17:10:01 N/A
IPoE-DHCP6
2001:DB8:30:100::/56
00:00:65:17:10:01 N/A
IPoE-DHCP6
------------------------------------------------------------------------------Subscriber open-pppoe|2 (default-sub-profile)
------------------------------------------------------------------------------------------------------------------------------------------------------------(1) SLA Profile Instance sap:[1/1/5:17.11] - sla:default-sla
------------------------------------------------------------------------------IP Address
MAC Address
PPPoE-SID Origin
-------------------------------------------------------10.12.0.100
00:00:65:17:11:02 2
IPCP
2001:DB8:30:1::1/128
00:00:65:17:11:02 2
PPP-DHCP6
2001:DB8:30:200::/56
00:00:65:17:11:02 2
PPP-DHCP6
------------------------------------------------------------------------------Number of active subscribers : 2

Page 754

Advanced Configuration Guide

Flexible Authentication Model in ESM

The following command shows more details about the subscriber-host, such as the groupinterface, address origin, acct-session-id, etc. Even though there are only two dual-stack hosts (one
IPoE and one PPPoE), each of them has 3 IP addresses that show up as different hosts.
For the purpose of brevity, the output for only two IP hosts are shown, one with an IPv4 address
and one with an IPv6 address. The remaining IP addresses/prefixes are not shown since the output
follows the same logic.
A:BNG-1# show service id 10 subscriber-hosts detail
=============================================================
Subscriber Host table
=============================================================
Sap
Subscriber
IP Address
MAC Address
PPPoE-SID Origin
Fwding State
------------------------------------------------------------[1/1/5:17.10]
open-dhcp
10.12.0.101
00:00:65:17:10:01
N/A
DHCP
Fwding
------------------------------------------------------------Subscriber-interface : sub-int-1
Group-interface
: open-auth
Sub Profile
: default-sub-profile
SLA Profile
: default-sla
App Profile
: N/A
Egress Q-Group
: policer-output-queues
Egress Vport
: N/A
Acct-Session-Id
: D897FF0000000F51DBC5A7
Acct-Q-Inst-Session-Id: D897FF0000001051DBC5A7
Address Origin
: DHCP
OT HTTP Rdr IP-FltrId : N/A
OT HTTP Rdr Status
: N/A
OT HTTP Rdr Fltr Src : N/A
------------------------------------------------------------[1/1/5:17.11]
open-pppoe|2
2001:DB8:30:1::1/128
00:00:65:17:11:02
2
PPP-DHCP6
Fwding
------------------------------------------------------------Subscriber-interface : sub-int-1
Group-interface
: open-auth
Sub Profile
: default-sub-profile
SLA Profile
: default-sla
App Profile
: N/A
Egress Q-Group
: policer-output-queues
Egress Vport
: N/A
Acct-Session-Id
: D897FF0000001351DBC5BA
Acct-Q-Inst-Session-Id: D897FF0000000E51DBC59C
Address Origin
: DHCP
OT HTTP Rdr IP-FltrId : N/A
OT HTTP Rdr Status
: N/A
OT HTTP Rdr Fltr Src : N/A
------------------------------------------------------------Number of subscriber hosts : 6
The remaining 4 hosts are not shown here
=============================================================

Advanced Configuration Guide

Page 755

Configuration

The following command shows that there are no sub/sla-profile strings assigned to the subscriber.
Instead the default sub/sla-profiles from the msap-policy are used.
The IP address is assigned by the DHCP server which also supplied the def-gw information, DNS
servers, the net-mask and the lease time.
The circuit-id and the subscriber-id are set to the same value.
A:BNG-1# show service id 10 dhcp lease-state detail
===============================================================================
DHCP lease states for service 10
===============================================================================
Service ID
: 10
IP Address
: 10.12.0.101
Client HW Address
: 00:00:65:17:10:01
Subscriber-interface : sub-int-1
Group-interface
: open-auth
SAP
: [1/1/5:17.10]
Up Time
: 0d 00:04:01
Remaining Lease Time : 0d 00:56:00
Remaining SessionTime: N/A
Persistence Key
: N/A
Sub-Ident
Sub-Profile-String
SLA-Profile-String
App-Profile-String
Lease ANCP-String
Lease Int Dest Id
Category-Map-Name

:
:
:
:
:
:
:

Lease Info origin

: DHCP

Ip-Netmask
Broadcast-Ip-Addr
Default-Router
Primary-Dns
Secondary-Dns
Primary-Nbns
Secondary-Nbns

:
:
:
:
:
:
:

255.255.255.0
N/A
10.12.0.1
172.16.16.16
172.16.16.17
N/A
N/A

ServerLeaseStart
ServerLastRenew
ServerLeaseEnd
Session-Timeout
Lease-Time
DHCP Server Addr

:
:
:
:
:
:

07/09/2013 01:11:19
07/09/2013 01:11:19
07/09/2013 02:11:19
N/A
0d 01:00:00
10.10.1.1

"open-dhcp"
""
""
""
""
""
""

Relay Agent Information


Circuit Id
: open-dhcp
Remote Id
: ipoe-v6
Radius User-Name
: ""
------------------------------------------------------------------------------Number of lease states : 1
===============================================================================

Page 756

Advanced Configuration Guide

Flexible Authentication Model in ESM

Then there is a similar command used for DHCPv6 lease-state details.


For the purpose of brevity, the output for only two IPv6 leases is shown. The remaining two IPv6
leases are not shown since the output follows the same logic.
A:BNG-1# show service id 10 dhcp6 lease-state detail
===============================================================================
DHCP lease states for service 10
===============================================================================
Service ID
: 10
IP Address
: 2001:DB8:30::1/128
Client HW Address
: 00:00:65:17:10:01
Subscriber-interface : sub-int-1
Group-interface
: open-auth
SAP
: [1/1/5:17.10]
Up Time
: 0d 00:44:50
Remaining Lease Time : 0d 00:45:10
Remaining SessionTime: N/A
Persistence Key
: N/A
Sub-Ident
:
Sub-Profile-String
:
SLA-Profile-String
:
App-Profile-String
:
Lease ANCP-String
:
Lease Int Dest Id
:
Category-Map-Name
:
Dhcp6 ClientId (DUID):
Dhcp6 IAID
:
Dhcp6 IAID Type
:
Dhcp6 Client Ip
:
Primary-Dns
:
Secondary-Dns
:
Pool Name
:
Dhcp6 Server Addr
:
Dhcp6 ServerId (DUID):
Dhcp6 InterfaceId
:
Dhcp6 RemoteId
:
Lease Info origin

"open-dhcp"
""
""
""
""
""
""
00030001000065171001
0
non-temporary
FE80::200:65FF:FE17:1001
N/A
N/A
""
2001:DB8::1
00030001d897ff000000
open-dhcp
0000ipoe-v6

: DHCP

ServerLeaseStart
: 07/09/2013 01:11:28
ServerLastRenew
: 07/09/2013 01:41:28
ServerLeaseEnd
: 07/09/2013 02:41:28
One hour lease time.
Session-Timeout
: N/A
Radius User-Name
: ""
------------------------------------------------------------------------------Service ID
: 10
IP Address
: 2001:DB8:30:1::1/128
Client HW Address
: 00:00:65:17:11:02
Subscriber-interface : sub-int-1
Group-interface
: open-auth
SAP
: [1/1/5:17.11]
Up Time
: 0d 00:44:40
Remaining Lease Time : 0d 00:45:20
Remaining SessionTime: N/A
Persistence Key
: N/A

Advanced Configuration Guide

Page 757

Configuration

Sub-Ident
:
Sub-Profile-String
:
SLA-Profile-String
:
App-Profile-String
:
Lease ANCP-String
:
Lease Int Dest Id
:
Category-Map-Name
:
Dhcp6 ClientId (DUID):
Dhcp6 IAID
:
Dhcp6 IAID Type
:
Dhcp6 Client Ip
:
Primary-Dns
:
Secondary-Dns
:
Pool Name
:
Dhcp6 Server Addr
:
Dhcp6 ServerId (DUID):
Dhcp6 InterfaceId
:
Dhcp6 RemoteId
:
Lease Info origin

"open-pppoe|2"
""
""
""
""
""
""
00030001000065171102
0
non-temporary
FE80::200:65FF:FE17:1102
N/A
N/A
""
2001:DB8::1
00030001d897ff000000
open-pppoe
N/A

: DHCP

ServerLeaseStart
: 07/09/2013 01:11:38
ServerLastRenew
: 07/09/2013 01:41:38
ServerLeaseEnd
: 07/09/2013 02:41:38
Session-Timeout
: N/A
Radius User-Name
: ""
------------------------------------------------------------------------------Number of lease states : 4
The remaining 2 leases are not shown here.
===============================================================================

Page 758

Advanced Configuration Guide

Flexible Authentication Model in ESM

DHCP Relay Case with LUDB + RADIUS Authentication


IP address is assigned via local DHCP server.

RADIUS provides sub/sla-profile strings and a framed IPv4 route.

LUDB provides IP address pool, inter-dest-id string for Vport assignment, msap-defaults
(routing context parameters and msap-policy).

Vport aggregate rate limit and the port scheduler are now added to the physical port. The Vport is
associated with the subscriber through the inter-dest-id string obtained via LUDB.
configure port 1/1/5
ethernet
mode access
encap-type qinq
egress-scheduler-policy "port"
access
egress
vport "open-dhcp" create
agg-rate-limit 500
host-match dest "open-auth-vport" create
exit
exit
exit
no shutdown
exit

The LUDB is used to assign the IP pool name (pool-name = ludb) and the inter-dest-id string
(inter-dest-id = open-auth-vport) to the subscriber. The pool name is carried to the DHCP server
via custom DHCP options [(82,9,13) in DHCPv4 and (17,1->wan_pool and 2->pfx_pool) in
DHCPv6].
The domain name alu-domain is appended to the username (circuit-id = open-dhcp or username =
open-pppoe) before an Access-Request message is sent to the RADIUS server which is configured
in the authentication policy open-dhcp.
The inter-dest-id string taken from the LUDB is passed to the subscriber management module in
the 7x50 via DHCP option 254 in DHCP ACK/Reply.
configure subscriber-mgmt local-user-db "open-dhcp"
local-user-db "open-dhcp" create
dhcp
match-list circuit-id
host "open-dhcp" create
host-identification
circuit-id string "open-dhcp"
exit
address pool "ludb"
auth-policy "open-dhcp"
auth-domain-name "alu-domain"
identification-strings 254 create
inter-dest-id "open-auth-vport"

Advanced Configuration Guide

Page 759

Configuration

exit
msap-defaults
group-interface "open-auth"
policy "msaps"
service 10
exit
ipv6-wan-address-pool "ludb"
ipv6-delegated-prefix-pool "ludb"
no shutdown
exit
exit
ppp
match-list circuit-id username
host "open-ppp" create
host-identification
username "open-pppoe"
exit
auth-policy "open-dhcp"
address pool "ludb"
password chap "ALU" hash2
identification-strings 254 create
inter-dest-id "open-auth-vport"
exit
msap-defaults
group-interface "open-auth"
policy "msaps"
service 10
exit
ipv6-delegated-prefix-pool "ludb"
ipv6-wan-address-pool "ludb"
no shutdown
exit
exit
no shutdown
exit

The inter-dest-id string taken from the LUDB is passed to the subscriber management module in
the 7x50 via DHCPv4/v6 option 254 that is specified in the subscriber identification policy.
configure subscriber-mgmt sub-ident-policy "sub_ident_pol"
strings-from-option 254

The RADIUS server is defined in the authentication policy. The domain name can be appended to
the PPPoE subscriber host directly via the authentication-policy while for IPoE subscribers, the
domain name is appended via the authentication-policy in conjunction with the LUDB. This can
be verified in the output (shown later) of the show service id 10 dhcp lease-state detail and show
service id 10 dhcp6 lease-state detail commands (on the radius user-name line).
configure subscriber-mgmt authentication-policy "open-dhcp"
password "ALU" hash2
ppp-user-name append "alu-domain"
radius-authentication-server
server 1 address X.Y.Z.W secret "ALU" hash2
exit
user-name-format circuit-id append
pppoe-access-method pap-chap

Page 760

Advanced Configuration Guide

Flexible Authentication Model in ESM

The RADIUS user configuration file uses the domain-name extension, as inserted by the 7x50
BNG, to authenticate the user:
open-dhcp@alu-domain
Cleartext-Password := "ALU"
Alc-Subsc-Prof-Str = rad-sub,
Subscriber profile string.
Alc-SLA-Prof-Str = rad-sla,
SLA profile string.
Framed-Route = "192.168.1.0/24 0.0.0.0" Managed IPv4 route.
Fall-Through = No

open-pppoe@alu-domain Cleartext-Password := "ALU"


Alc-Subsc-Prof-Str = rad-sub,
Alc-SLA-Prof-Str = rad-sla,
Framed-Route = "192.168.2.0/24 0.0.0.0",
Fall-Through = No

DHCPv4/v6 servers are locally configured in the 7x50 and attached to a loopback interface:
configure service vprn 10 interface "loop-dhcp-srvr"
address 10.10.1.1/24
IPv4 address to which is DHCPv4 server attached.
ipv6
address 2001:DB8::1/128
IPv6 address to which is DHCPv6 server attached.
local-dhcp-server "v6"
Attaching DHCPv6 server to the loopback intf.
exit
local-dhcp-server "local"
Attaching DHCPv4 server to the loopback intf.

loopback

Group-interface configuration. Note that common parts of the configuration as defined earlier, still
apply:
configure service vprn 10 subscriber-interface "sub-int-1" group-interface "open-auth"
dhcp6
user-db "open-dhcp"
relay
DHCPv6 relay configuration.
link-address 2001:DB8:30::
server 2001:DB8::1
client-applications dhcp ppp
no shutdown
exit
exit
dhcp
DHCPv4 relay configuration.
option
no circuit-id
7x50 will not insert its own circuit-id.
no remote-id
7x50 will not insert its own remote-id.
vendor-specific-option
pool-name
exit
exit
server 10.10.1.1
client-applications dhcp ppp
no shutdown
exit

exit

Advanced Configuration Guide

Page 761

Configuration

Lease times for IPv4 and IPv6 are configured in the local DHCP server. Lease times under the
local DHCP server are used only in the relay case (when IP address is supplied via DHCP server
and NOT RADIUS or LUDB). In the proxy case the lease times can be obtained via LUDB,
RADIUS or group-interface.
configure service vprn 10
dhcp
local-dhcp-server "local" create
use-gi-address
gi-address can be used to select the pool.
use-pool-from-client
pool name can be explicitly provided.
pool "ludb" create
pool used when LUDB provides the pool name.
options
dns-server 172.16.16.16 172.16.16.17
lease-time hrs 1
exit
subnet 10.10.0.0/24 create
options
subnet-mask 255.255.255.0
default-router 10.10.0.1
exit
address-range 10.10.0.100 10.10.0.200
exit
exit
pool "gi-addr" create
pool selected based on the gi-address.
options
dns-server 172.16.16.16 172.16.16.17
lease-time hrs 1
exit
subnet 10.12.0.0/24 create
options
subnet-mask 255.255.255.0
default-router 10.12.0.1
exit
address-range 10.12.0.100 10.12.0.200
exit
exit
no shutdown
exit
exit
dhcp6
local-dhcp-server "v6" create
use-link-address
use-pool-from-client
pool "ludb" create
prefix 2001:DB8:10::/48 pd wan-host create
preferred-lifetime min 30
rebind-timer min 20
renew-timer min 15
valid-lifetime hrs 1
options
dns-server 2001:DB8::1000 2001:DB8::1001
exit
exit
exit
pool "gi-addr" create
prefix 2001:DB8:30::/48 pd wan-host create
preferred-lifetime min 30
rebind-timer min 20

Page 762

Advanced Configuration Guide

Flexible Authentication Model in ESM

renew-timer min 15
valid-lifetime hrs 1
options
dns-server 2001:DB8::1000 2001:DB8::1001
exit
exit
exit
no shutdown
exit
exit

RADIUS sub/sla-profiles supplied via RADIUS are used:


configure subscriber-mgmt sla-profile "rad-sla"
description "sla-profile obtained via RADIUS"
host-limit 100
egress
qos 10 vport-scheduler
exit
ip-filter 10
exit
exit
configure subscriber-mgmt sub-profile "rad-sub"
description "sub-profile obtained via RADIUS"
egress
agg-rate-limit 15000
exit
exit

Advanced Configuration Guide

Page 763

Configuration

Show Commands
The following command shows that the rad-sub/sla-profiles, as supplied via RADIUS, are in use.
The IP addresses are selected from the pool-name LUDB in the local DHCP server. The
subscriber-id is circuit-id for IPoE subscriber-host and the username|session-id combination for
PPPoE subscriber host.
A:BNG-1#show service active-subscribers
===============================================================================
Active Subscribers
===============================================================================
------------------------------------------------------------------------------Subscriber open-dhcp (rad-sub)
------------------------------------------------------------------------------------------------------------------------------------------------------------(1) SLA Profile Instance sap:[1/1/5:17.10] - sla:rad-sla
------------------------------------------------------------------------------IP Address
MAC Address
PPPoE-SID Origin
-------------------------------------------------------10.10.0.101
00:00:65:17:10:01 N/A
DHCP
2001:DB8:10:1::1/128
00:00:65:17:10:01 N/A
IPoE-DHCP6
2001:DB8:10:200::/56
00:00:65:17:10:01 N/A
IPoE-DHCP6
------------------------------------------------------------------------------Subscriber open-pppoe|3 (rad-sub)
------------------------------------------------------------------------------------------------------------------------------------------------------------(1) SLA Profile Instance sap:[1/1/5:17.11] - sla:rad-sla
------------------------------------------------------------------------------IP Address
MAC Address
PPPoE-SID Origin
-------------------------------------------------------10.10.0.100
00:00:65:17:11:02 3
IPCP
2001:DB8:10::1/128
00:00:65:17:11:02 3
PPP-DHCP6
2001:DB8:10:100::/56
00:00:65:17:11:02 3
PPP-DHCP6
------------------------------------------------------------------------------Number of active subscribers : 2

-------------------------------------------------------------------------------

Page 764

Advanced Configuration Guide

Flexible Authentication Model in ESM

The following command shows more details about the subscriber-host, such as the groupinterface, vport, address origin, acct-session-id, etc. Vport is selected based on the inter-dest-id
string supplied via the LUDB.
For the purpose of brevity, the output for only two IP addresses hosts is shown, one with an IPv4
address and one with an IPv6 address. The remaining IP addresses/prefixes are not shown since
the output follows the same logic.
A:BNG-1# show service id 10 subscriber-hosts detail
=============================================================
Subscriber Host table
=============================================================
Sap
Subscriber
IP Address
MAC Address
PPPoE-SID Origin
Fwding State
------------------------------------------------------------[1/1/5:17.10]
open-dhcp
10.10.0.101
00:00:65:17:10:01
N/A
DHCP
Fwding
------------------------------------------------------------Subscriber-interface : sub-int-1
Group-interface
: open-auth
Sub Profile
: rad-sub
SLA Profile
: rad-sla
App Profile
: N/A
Egress Q-Group
: policer-output-queues
Egress Vport
: open-dhcp
Acct-Session-Id
: D897FF0000000551D308B2
Acct-Q-Inst-Session-Id: D897FF0000000651D308B2
Address Origin
: DHCP
OT HTTP Rdr IP-FltrId : N/A
OT HTTP Rdr Status
: N/A
OT HTTP Rdr Fltr Src : N/A
------------------------------------------------------------[1/1/5:17.11]
open-pppoe|3
2001:DB8:10::1/128
00:00:65:17:11:02
3
PPP-DHCP6
Fwding
------------------------------------------------------------Subscriber-interface : sub-int-1
Group-interface
: open-auth
Sub Profile
: rad-sub
SLA Profile
: rad-sla
App Profile
: N/A
Egress Q-Group
: policer-output-queues
Egress Vport
: open-dhcp
Acct-Session-Id
: D897FF0000000351D308AF
Acct-Q-Inst-Session-Id: D897FF0000000251D308A9
Address Origin
: DHCP
OT HTTP Rdr IP-FltrId : N/A
OT HTTP Rdr Status
: N/A
OT HTTP Rdr Fltr Src : N/A
-------------------------------------------------------------

Advanced Configuration Guide

Page 765

Configuration

The following command shows that the subscriber identity is set to circuit-id (plus session-id) as
instructed by auto-sub-id-key command (subscriber-id string is not returned via the LUDB or
RADIUS). The lease times are set to 1h as defined in the DHCP server. The username passed to
RADIUS is a circuit-id or a username appended by the alu-dmain domain name.
A:BNG-1# show service id 10 dhcp lease-state detail
===============================================================================
DHCP lease states for service 10
===============================================================================
Service ID
: 10
IP Address
: 10.10.0.101
Client HW Address
: 00:00:65:17:10:01
Subscriber-interface : sub-int-1
Group-interface
: open-auth
SAP
: [1/1/5:17.10]
Up Time
: 0d 00:12:45
Remaining Lease Time : 0d 00:47:16
Remaining SessionTime: N/A
Persistence Key
: N/A
Sub-Ident
Sub-Profile-String
SLA-Profile-String
App-Profile-String
Lease ANCP-String
Lease Int Dest Id
Category-Map-Name

:
:
:
:
:
:
:

"open-dhcp"
"rad-sub"
"rad-sla"
""
""
"open-auth-vport"
""

Lease Info origin

: DHCP

Ip-Netmask
Broadcast-Ip-Addr
Default-Router
Primary-Dns
Secondary-Dns
Primary-Nbns
Secondary-Nbns

:
:
:
:
:
:
:

255.255.255.0
N/A
10.10.0.1
172.16.16.16
172.16.16.17
N/A
N/A

ServerLeaseStart
ServerLastRenew
ServerLeaseEnd
Session-Timeout
Lease-Time
DHCP Server Addr

:
:
:
:
:
:

07/02/2013 10:06:58
07/02/2013 10:06:58
07/02/2013 11:06:58
N/A
0d 01:00:00
10.10.1.1

Relay Agent Information


Circuit Id
: open-dhcp
Remote Id
: ipoe-v6
Radius User-Name
: "open-dhcp@alu-domain"
Managed Routes
: 192.168.1.0/24
installed
------------------------------------------------------------------------------Number of lease states : 1

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

Page 766

Advanced Configuration Guide

Flexible Authentication Model in ESM

For the purpose of brevity the output for only two IPv6 leases is shown. The remaining two IPv6
leases are not shown since the output follows the same logic.
A:BNG-1# show service id 10 dhcp6 lease-state detail
===============================================================================
DHCP lease states for service 10
===============================================================================
Service ID
: 10
IP Address
: 2001:DB8:10::1/128
Client HW Address
: 00:00:65:17:11:02
Subscriber-interface : sub-int-1
Group-interface
: open-auth
SAP
: [1/1/5:17.11]
Up Time
: 0d 00:13:00
Remaining Lease Time : 0d 00:47:00
Remaining SessionTime: N/A
Persistence Key
: N/A
Sub-Ident
:
Sub-Profile-String
:
SLA-Profile-String
:
App-Profile-String
:
Lease ANCP-String
:
Lease Int Dest Id
:
Category-Map-Name
:
Dhcp6 ClientId (DUID):
Dhcp6 IAID
:
Dhcp6 IAID Type
:
Dhcp6 Client Ip
:
Primary-Dns
:
Secondary-Dns
:
Pool Name
:
Dhcp6 Server Addr
:
Dhcp6 ServerId (DUID):
Dhcp6 InterfaceId
:
Dhcp6 RemoteId
:
Lease Info origin

"open-pppoe|3"
"rad-sub"
"rad-sla"
""
""
"open-auth-vport"
""
00030001000065171102
0
non-temporary
FE80::200:65FF:FE17:1102
N/A
N/A
"ludb"
2001:DB8::1
00030001d897ff000000
open-pppoe
N/A

: DHCP

ServerLeaseStart
: 07/02/2013 10:06:55
ServerLastRenew
: 07/02/2013 10:06:55
ServerLeaseEnd
: 07/02/2013 11:06:55
Session-Timeout
: N/A
Radius User-Name
: "open-pppoe@alu-domain"
------------------------------------------------------------------------------Service ID
: 10
IP Address
: 2001:DB8:10:1::1/128
Client HW Address
: 00:00:65:17:10:01
Subscriber-interface : sub-int-1
Group-interface
: open-auth
SAP
: [1/1/5:17.10]
Up Time
: 0d 00:12:52
Remaining Lease Time : 0d 00:47:08
Remaining SessionTime: N/A
Persistence Key
: N/A
Sub-Ident
Sub-Profile-String

: "open-dhcp"
: "rad-sub"

Advanced Configuration Guide

Page 767

Configuration

SLA-Profile-String
:
App-Profile-String
:
Lease ANCP-String
:
Lease Int Dest Id
:
Category-Map-Name
:
Dhcp6 ClientId (DUID):
Dhcp6 IAID
:
Dhcp6 IAID Type
:
Dhcp6 Client Ip
:
Primary-Dns
:
Secondary-Dns
:
Pool Name
:
Dhcp6 Server Addr
:
Dhcp6 ServerId (DUID):
Dhcp6 InterfaceId
:
Dhcp6 RemoteId
:
Lease Info origin

"rad-sla"
""
""
"open-auth-vport"
""
00030001000065171001
0
non-temporary
FE80::200:65FF:FE17:1001
N/A
N/A
"ludb"
2001:DB8::1
00030001d897ff000000
open-dhcp
0000ipoe-v6

: DHCP

ServerLeaseStart
: 07/02/2013 10:07:03
ServerLastRenew
: 07/02/2013 10:07:03
ServerLeaseEnd
: 07/02/2013 11:07:03
Session-Timeout
: N/A
Radius User-Name
: "open-dhcp@alu-domain"
-------------------------------------------------------------------------------

Page 768

Advanced Configuration Guide

Flexible Authentication Model in ESM

IP Proxy Case with LUDB + RADIUS Authentication


IP address is assigned via RADIUS.

RADIUS provides IP addresses3 and related parameters (DNS server, IPv4 defaultgateway, etc), inter-dest-id string for Vport assignment and a framed route.

LUDB provides sub/sla-profile strings and msap-defaults (routing context parameters and
msap-policy).

Vport aggregate rate limit and the port scheduler are now added to the physical port. The Vport is
associated with the subscriber through the inter-dest-id string obtained via the LUDB.
configure port 1/1/5
ethernet
mode access
encap-type qinq
egress-scheduler-policy "port"
access
egress
vport "open-dhcp" create
agg-rate-limit 500
host-match dest "open-auth-vport" create
exit
exit
exit
no shutdown
exit

The LUDB is used to assign the sub/sla-profile strings.


The domain name alu-domain is appended to the username (circuit-id = open-dhcp or username =
open-pppoe) before an Access-Request is sent to the RADIUS server that is configured in the
authentication policy open-dhcp.

3.

IPv6 lease-times are provided under the group-interface.

Advanced Configuration Guide

Page 769

Configuration

local-user-db "open-dhcp" create


ipoe
match-list circuit-id
host "open-dhcp" create
host-identification
circuit-id string "open-dhcp"
exit
auth-policy "open-dhcp"
auth-domain-name "alu-domain"
identification-strings 254 create
sla-profile-string "ludb-sla"
sub-profile-string "ludb-sub"
exit
msap-defaults
group-interface "open-auth"
policy "msaps"
service 10
exit
no shutdown
exit
exit
ppp
match-list circuit-id mac username
host "open-ppp" create
host-identification
username "open-pppoe"
exit
auth-policy "open-dhcp"
password chap "ALU" hash2
identification-strings 254 create
sla-profile-string "ludb-sla"
sub-profile-string "ludb-sub"
exit
msap-defaults
group-interface "open-auth"
policy "msaps"
service 10
exit
no shutdown
exit
exit
no shutdown
exit

Page 770

Advanced Configuration Guide

Flexible Authentication Model in ESM

RADIUS is defined in the authentication-policy. The domain name can be appended to the
PPPoE subscriber host directly via authentication-policy, while for IPoE subscribers the domain
name is appended via authentication-policy in conjunction with LUDB.
configure subscriber-mgmt authentication-policy "open-dhcp"
password "ALU" hash2
ppp-user-name append "alu-domain"
radius-authentication-server
server 1 address X.Y.Z.W secret "ALU" hash2
exit
user-name-format circuit-id append
pppoe-access-method pap-chap

The RADIUS user configuration file uses the domain extension as inserted by the 7x50 BNG node
to authenticate the user. The inter-dest-id string and the host IP address are provided by the
RADIUS server (proxy case) along with other IP addressing parameters.
The IPv4 lease time (30 minutes) for IPv4 addresses are provided by the RADIUS server, while
the lease time (30 minutes) for IPv6 addresses/prefixes are configured under the group-interface.
open-dhcp@alu-domain Cleartext-Password := "ALU"
Alc-Int-Dest-Id-Str = open-auth-vport,
Framed-IP-Address = 10.10.0.230,
Framed-IP-Netmask = 255.255.255.0,
Alc-Default-Router = 10.10.0.1,
Alc-Lease-Time = 1800,
Client-DNS-Pri = 172.16.20.20,
Client-DNS-Sec = 172.16.20.21,
Alc-IPv6-Address = 2001:db8::100,
Delegated-IPv6-Prefix = 2001:DB8:40:100::/56,
Alc-IPv6-Primary-Dns = 2001:DB8::2000,
Alc-Ipv6-Secondary-Dns = 2001:DB8::2001,
Framed-Route = "192.168.1.0/24 0.0.0.0",
Fall-Through = No
open-pppoe@alu-domain Cleartext-Password := "ALU"
Alc-Int-Dest-Id-Str = open-auth-vport,
Framed-IP-Address = 10.10.0.231,
Framed-IP-Netmask = 255.255.255.255,
Client-DNS-Pri = 172.16.20.20,
Client-DNS-Sec = 172.16.20.21,
Alc-IPv6-Address = 2001:db8:0:1::100,
Delegated-IPv6-Prefix = 2001:DB8:40:200::/56,
Alc-IPv6-Primary-Dns = 2001:DB8::2000,
Alc-Ipv6-Secondary-Dns = 2001:DB8::2001,
Framed-Route = "192.168.2.0/24 0.0.0.0",
Fall-Through = No

Advanced Configuration Guide

Page 771

Configuration

The group-interface configuration is shown below. Note that common parts of the configuration as
defined earlier still apply.
configure service vprn 10 subscriber-interface "sub-int-1" group-interface "open-auth"
create
ipv6
dhcp6
proxy-server
renew-timer min 7
rebind-timer min 10
valid-lifetime min 30
preferred-lifetime min 15
client-applications dhcp ppp
no shutdown
exit
exit
exit
dhcp
proxy-server
emulated-server 10.12.0.1
no shutdown
exit
no shutdown
exit
exit

RADIUS sub/sla-profiles supplied via the LUDB are used:


configure subscriber-mgmt sla-profile "ludb-sla"
description "sla-profile obtained via LUDB"
host-limit 100
egress
qos 10 vport-scheduler
exit
ip-filter 10
exit
config>subscr-mgmt# sub-profile "ludb-sub"
description "sub-profile obtained via LUDB"
egress
agg-rate-limit 15000
exit

Page 772

Advanced Configuration Guide

Flexible Authentication Model in ESM

Show Commands
The following command shows that the LUDB-sub/sla-profiles, as supplied via LUDB, are in use.
The IP addresses are supplied via the RADIUS server. The subscriber-id is auto-generated (not
returned via LUDB or RADIUS) and it is set to circuit-id for the IPoE subscriber-host, and to the
username|session-id combination for PPPoE subscriber host.
*A:BNG-1# show service active-subscribers
===============================================================================
Active Subscribers
===============================================================================
------------------------------------------------------------------------------Subscriber open-dhcp (ludb-sub)
------------------------------------------------------------------------------------------------------------------------------------------------------------(1) SLA Profile Instance sap:[1/1/5:17.10] - sla:ludb-sla
------------------------------------------------------------------------------IP Address
MAC Address
PPPoE-SID Origin
-------------------------------------------------------10.10.0.230
00:00:65:17:10:01 N/A
DHCP
2001:DB8::100/128
00:00:65:17:10:01 N/A
IPoE-DHCP6
2001:DB8:40:100::/56
00:00:65:17:10:01 N/A
IPoE-DHCP6
------------------------------------------------------------------------------Subscriber open-pppoe|12 (ludb-sub)
------------------------------------------------------------------------------------------------------------------------------------------------------------(1) SLA Profile Instance sap:[1/1/5:17.11] - sla:ludb-sla
------------------------------------------------------------------------------IP Address
MAC Address
PPPoE-SID Origin
-------------------------------------------------------10.10.0.231
00:00:65:17:11:02 12
IPCP
2001:DB8::1:0:0:0:100/128
00:00:65:17:11:02 12
PPP-DHCP6
2001:DB8:40:200::/56
00:00:65:17:11:02 12
PPP-DHCP6
------------------------------------------------------------------------------Number of active subscribers : 2
-------------------------------------------------------------------------------

Advanced Configuration Guide

Page 773

Configuration

The following command shows more details about the subscriber-host, such as the groupinterface, vport, address origin, acct-session-id, etc. Vport is selected based on the inter-dest-id
string supplied via RADIUS.
For the purpose of brevity, the output for only two hosts is shown, one with IPv4 address and one
with IPv6 prefix. The remaining IP addresses/prefixes are not shown since the output follows the
same logic.
*A:BNG-1# show service id 10 subscriber-hosts detail
=============================================================
Subscriber Host table
=============================================================
Sap
Subscriber
IP Address
MAC Address
PPPoE-SID Origin
Fwding State
------------------------------------------------------------[1/1/5:17.10]
open-dhcp
10.10.0.230
00:00:65:17:10:01
N/A
DHCP
Fwding
------------------------------------------------------------Subscriber-interface : sub-int-1
Group-interface
: open-auth
Sub Profile
: ludb-sub
SLA Profile
: ludb-sla
App Profile
: N/A
Egress Q-Group
: policer-output-queues
Egress Vport
: open-dhcp
Acct-Session-Id
: D897FF0000004751D31B6E
Acct-Q-Inst-Session-Id: D897FF0000004851D31B6E
Address Origin
: AAA
OT HTTP Rdr IP-FltrId : N/A
OT HTTP Rdr Status
: N/A
OT HTTP Rdr Fltr Src : N/A
------------------------------------------------------------[1/1/5:17.11]
open-pppoe|12
2001:DB8:40:200::/56
00:00:65:17:11:02
12
PPP-DHCP6
Fwding
------------------------------------------------------------Subscriber-interface : sub-int-1
Group-interface
: open-auth
Sub Profile
: ludb-sub
SLA Profile
: ludb-sla
App Profile
: N/A
Egress Q-Group
: policer-output-queues
Egress Vport
: open-dhcp
Acct-Session-Id
: D897FF0000004651D31B6B
Acct-Q-Inst-Session-Id: D897FF0000004451D31B65
Address Origin
: AAA
OT HTTP Rdr IP-FltrId : N/A
OT HTTP Rdr Status
: N/A
OT HTTP Rdr Fltr Src : N/A
------------------------------------------------------------Number of subscriber hosts : 6
The remaining 4 hosts are not shown here.
=============================================================

Page 774

Advanced Configuration Guide

Flexible Authentication Model in ESM

The following command shows that the subscriber identity is set to circuit-id (plus session-id) as
instructed by the auto-sub-id-key command (the subscriber-id string is not returned via LUDB or
RADIUS). The lease times are set to 30 minutes as defined by RADIUS for IPv4 addresses and by
the group-interface for IPv6 addresses/prefixes (proxy-case). The username passed to RADIUS is
the circuit-id or username appended to the alu-dmain domain name.
The origin of the lease is RADIUS.
*A:BNG-1# show service id 10 dhcp lease-state detail
===============================================================================
DHCP lease states for service 10
===============================================================================
Service ID
: 10
IP Address
: 10.10.0.230
Client HW Address
: 00:00:65:17:10:01
Subscriber-interface : sub-int-1
Group-interface
: open-auth
SAP
: [1/1/5:17.10]
Up Time
: 0d 00:02:24
Remaining Lease Time : 0d 00:27:37
Remaining SessionTime: N/A
Persistence Key
: N/A
Sub-Ident
Sub-Profile-String
SLA-Profile-String
App-Profile-String
Lease ANCP-String
Lease Int Dest Id
Category-Map-Name

:
:
:
:
:
:
:

"open-dhcp"
"ludb-sub"
"ludb-sla"
""
""
"open-auth-vport"
""

Lease Info origin

: Radius

Ip-Netmask
Broadcast-Ip-Addr
Default-Router
Primary-Dns
Secondary-Dns
Primary-Nbns
Secondary-Nbns

:
:
:
:
:
:
:

255.255.255.0
10.10.0.255
10.10.0.1
172.16.20.20
172.16.20.21
N/A
N/A

ServerLeaseStart
ServerLastRenew
ServerLeaseEnd
Session-Timeout
Lease-Time
DHCP Server Addr

:
:
:
:
:
:

07/02/2013 11:26:54
07/02/2013 11:26:54
07/02/2013 11:56:54
N/A
0d 00:30:00
N/A

Relay Agent Information


Circuit Id
: open-dhcp
Remote Id
: ipoe-v6
Radius User-Name
: "open-dhcp@alu-domain"
Managed Routes
: 192.168.1.0/24
installed
------------------------------------------------------------------------------Number of lease states : 1
===============================================================================

Advanced Configuration Guide

Page 775

Configuration

For the purpose of brevity, the output for only two IPv6 prefixes are shown. The remaining two
IPv6 leases are not shown since the output follows the same logic.
*A:BNG-1# show service id 10 dhcp6 lease-state detail
===============================================================================
DHCP lease states for service 10
===============================================================================
Service ID
: 10
IP Address
: 2001:DB8:40:100::/56
Client HW Address
: 00:00:65:17:10:01
Subscriber-interface : sub-int-1
Group-interface
: open-auth
SAP
: [1/1/5:17.10]
Up Time
: 0d 00:02:32
Remaining Lease Time : 0d 00:27:28
Remaining SessionTime: N/A
Persistence Key
: N/A
Sub-Ident
:
Sub-Profile-String
:
SLA-Profile-String
:
App-Profile-String
:
Lease ANCP-String
:
Lease Int Dest Id
:
Category-Map-Name
:
Dhcp6 ClientId (DUID):
Dhcp6 IAID
:
Dhcp6 IAID Type
:
Dhcp6 Client Ip
:
Primary-Dns
:
Secondary-Dns
:
Pool Name
:
Dhcp6 Server Addr
:
Dhcp6 ServerId (DUID):
Dhcp6 InterfaceId
:
Dhcp6 RemoteId
:
Lease Info origin

"open-dhcp"
"ludb-sub"
"ludb-sla"
""
""
"open-auth-vport"
""
00030001000065171001
0
prefix
FE80::200:65FF:FE17:1001
2001:DB8::2000
2001:DB8::2001
""
N/A
N/A
open-dhcp
0000ipoe-v6

: Radius

ServerLeaseStart
: 07/02/2013 11:26:58
ServerLastRenew
: 07/02/2013 11:26:58
ServerLeaseEnd
: 07/02/2013 11:56:58
Session-Timeout
: N/A
Radius User-Name
: "open-dhcp@alu-domain"
------------------------------------------------------------------------------Service ID
: 10
IP Address
: 2001:DB8:40:200::/56
Client HW Address
: 00:00:65:17:11:02
Subscriber-interface : sub-int-1
Group-interface
: open-auth
SAP
: [1/1/5:17.11]
Up Time
: 0d 00:02:39
Remaining Lease Time : 0d 00:27:21
Remaining SessionTime: N/A
Persistence Key
: N/A
Sub-Ident
Sub-Profile-String

Page 776

: "open-pppoe|12"
: "ludb-sub"

Advanced Configuration Guide

Flexible Authentication Model in ESM

SLA-Profile-String
:
App-Profile-String
:
Lease ANCP-String
:
Lease Int Dest Id
:
Category-Map-Name
:
Dhcp6 ClientId (DUID):
Dhcp6 IAID
:
Dhcp6 IAID Type
:
Dhcp6 Client Ip
:
Primary-Dns
:
Secondary-Dns
:
Pool Name
:
Dhcp6 Server Addr
:
Dhcp6 ServerId (DUID):
Dhcp6 InterfaceId
:
Dhcp6 RemoteId
:
Lease Info origin

"ludb-sla"
""
""
"open-auth-vport"
""
00030001000065171102
0
prefix
FE80::200:65FF:FE17:1102
2001:DB8::2000
2001:DB8::2001
""
N/A
N/A
open-pppoe
N/A

: Radius

ServerLeaseStart
: 07/02/2013 11:26:51
ServerLastRenew
: 07/02/2013 11:26:51
ServerLeaseEnd
: 07/02/2013 11:56:51
Session-Timeout
: N/A
Radius User-Name
: "open-pppoe@alu-domain"
------------------------------------------------------------------------------Number of lease states : 4
The remaining two not shown in this output.
===============================================================================

Advanced Configuration Guide

Page 777

Configuration

IP Proxy Case with LUDB + RADIUS Authentication


P address is assigned via LUDB.

RADIUS provides sub/sla-profile strings and a framed IPv4 route.

LUDB provides IP addresses4 and related parameters (DNS server, IPv4 default-gateway,
etc), inter-dest-id string for Vport assignment and msap-defaults (routing context
parameters and msap-policy).

Vport aggregate rate limit and the port scheduler are now added to the physical port. The Vport is
associated with the subscriber through the inter-dest-id string obtained via the LUDB.
configure port 1/1/5
ethernet
mode access
encap-type qinq
egress-scheduler-policy "port"
access
egress
vport "open-dhcp" create
agg-rate-limit 500
host-match dest "open-auth-vport" create
exit
exit
exit
no shutdown

exit

The LUDB is used to assign the inter-dest-id string, host IP addresses and IP addressing
parameters. The DHCP lease time for IPv4 addresses is set to 15 minutes in the LUDB while lease
times for IPv6 addresses/prefixes is set under the group-interface (set to 30 minutes).
Domain name alu-domain is appended to the username (circuit-id = open-dhcp or username =
open-pppoe) before an Access-Request is sent to the RADIUS server that is configured in the
authentication-policy open-dhcp.
local-user-db "open-dhcp" create
dhcp
match-list circuit-id
host "open-dhcp" create
host-identification
circuit-id string "open-dhcp"
exit
address 10.10.0.230
auth-policy "open-dhcp"
auth-domain-name "alu-domain"
identification-strings 254 create
inter-dest-id "open-auth-vport"
exit

4. IPv6 lease-times are provided under the group-interface.

Page 778

Advanced Configuration Guide

Flexible Authentication Model in ESM

msap-defaults
group-interface "open-auth"
policy "msaps"
service 10
exit
options
subnet-mask 255.255.255.0
default-router 10.10.0.254
dns-server 172.16.20.20 172.16.20.21
lease-time min 15
exit
options6
dns-server 2001:DB8::2000 2001:DB8::2001
exit
ipv6-address 2001:DB8::100
ipv6-delegated-prefix 2001:DB8:40:100::/56
no shutdown
exit
exit

RADIUS is defined in the authentication-policy. The domain name can be appended to the PPPoE
subscriber host directly via authentication-policy while for IPoE subscribers, the domain name is
appended via authentication policy in conjunction with LUDB.
configure subscriber-mgmt authentication-policy "open-dhcp"
password "ALU" hash2
ppp-user-name append "alu-domain"
radius-authentication-server
server 1 address X.Y.Z.W secret "ALU" hash2
exit
user-name-format circuit-id append
pppoe-access-method pap-chap

The RADIUS user configuration file uses the domain extension as inserted by the 7x50 to
authenticate the user.
open-dhcp@alu-domain
Cleartext-Password := "ALU"
Alc-Subsc-Prof-Str = rad-sub,
Alc-SLA-Prof-Str = rad-sla,
Framed-Route = "192.168.1.0/24 0.0.0.0",
Fall-Through = No
open-pppoe@alu-domain Cleartext-Password := "ALU"
Alc-Subsc-Prof-Str = rad-sub,
Alc-SLA-Prof-Str = rad-sla,
Framed-Route = "192.168.2.0/24 0.0.0.0",
Fall-Through = No

Advanced Configuration Guide

Page 779

Configuration

The group interface configuration is shown below. Note that common parts of the configuration as
defined earlier still apply.
configure service vprn 10 subscriber-interface "sub-int-1" group-interface "open-auth"
create
ipv6
dhcp6
proxy-server
renew-timer min 7
rebind-timer min 10
valid-lifetime min 30
preferred-lifetime min 15
client-applications dhcp ppp
no shutdown
exit
exit
exit
dhcp
proxy-server
emulated-server 10.12.0.1
no shutdown
exit
no shutdown
exit
exit

RADIUS sub/sla-profiles supplied by RADIUS are defined as:


configure subscriber-mgmt sla-profile "rad-sla"
description "sla-profile obtained via LUDB"
host-limit 100
egress
qos 10 vport-scheduler
exit
ip-filter 10
exit
configure subscriber-mgmt sub-profile "rad-sub"
description "sub-profile obtained via LUDB"
egress
agg-rate-limit 15000
exit

Page 780

Advanced Configuration Guide

Flexible Authentication Model in ESM

Show Commands
The following command shows that the rad-sub/sla-profiles, as provided by RADIUS, are in use.
The IP addresses are provided by LUDB. The subscriber-id is auto-generated (not returned via the
LUDB or RADIUS) and it is set to circuit-id for IPoE subscriber-host(s) and to username|sessionid combination for PPPoE subscriber host(s).
*A:BNG-1# show service active-subscribers
===============================================================================
Active Subscribers
===============================================================================
------------------------------------------------------------------------------Subscriber open-dhcp (rad-sub)
------------------------------------------------------------------------------------------------------------------------------------------------------------(1) SLA Profile Instance sap:[1/1/5:17.10] - sla:rad-sla
------------------------------------------------------------------------------IP Address
MAC Address
PPPoE-SID Origin
-------------------------------------------------------10.10.0.230
00:00:65:17:10:01 N/A
DHCP
2001:DB8::100/128
00:00:65:17:10:01 N/A
IPoE-DHCP6
2001:DB8:40:100::/56
00:00:65:17:10:01 N/A
IPoE-DHCP6
------------------------------------------------------------------------------Subscriber open-pppoe|1 (rad-sub)
------------------------------------------------------------------------------------------------------------------------------------------------------------(1) SLA Profile Instance sap:[1/1/5:17.11] - sla:rad-sla
------------------------------------------------------------------------------IP Address
MAC Address
PPPoE-SID Origin
-------------------------------------------------------10.10.0.231
00:00:65:17:11:02 1
IPCP
2001:DB8::1:0:0:0:100/128
00:00:65:17:11:02 1
PPP-DHCP6
2001:DB8:40:200::/56
00:00:65:17:11:02 1
PPP-DHCP6
------------------------------------------------------------------------------Number of active subscribers : 2

-------------------------------------------------------------------------------

Advanced Configuration Guide

Page 781

Configuration

The following command shows more details about the subscriber-host, such as the groupinterface, vport, address origin, acct-session-id, etc. Vport is selected based on the inter-dest-id
string as supplied via RADIUS.
For the purpose of brevity, the output for only two hosts is shown, one with IPv4 address and one
with IPv6 prefix. The remaining IP addresses/prefixes are not shown since the output follows the
same logic.
*A:BNG-1# show service id 10 subscriber-hosts detail
=============================================================
Subscriber Host table
=============================================================
Sap
Subscriber
IP Address
MAC Address
PPPoE-SID Origin
Fwding State
------------------------------------------------------------[1/1/5:17.10]
open-dhcp
10.10.0.230
00:00:65:17:10:01
N/A
DHCP
Fwding
------------------------------------------------------------Subscriber-interface : sub-int-1
Group-interface
: open-auth
Sub Profile
: rad-sub
SLA Profile
: rad-sla
App Profile
: N/A
Egress Q-Group
: policer-output-queues
Egress Vport
: open-dhcp
Acct-Session-Id
: D897FF0000000051D48D5A
Acct-Q-Inst-Session-Id: D897FF0000000151D48D5A
Address Origin
: LUDB
OT HTTP Rdr IP-FltrId : N/A
OT HTTP Rdr Status
: N/A
OT HTTP Rdr Fltr Src : N/A
------------------------------------------------------------[1/1/5:17.11]
open-pppoe|1
2001:DB8:40:200::/56
00:00:65:17:11:02
1
PPP-DHCP6
Fwding
------------------------------------------------------------Subscriber-interface : sub-int-1
Group-interface
: open-auth
Sub Profile
: rad-sub
SLA Profile
: rad-sla
App Profile
: N/A
Egress Q-Group
: policer-output-queues
Egress Vport
: open-dhcp
Acct-Session-Id
: D897FF0000000851D48D66
Acct-Q-Inst-Session-Id: D897FF0000000651D48D61
Address Origin
: LUDB
OT HTTP Rdr IP-FltrId : N/A
OT HTTP Rdr Status
: N/A
OT HTTP Rdr Fltr Src : N/A
------------------------------------------------------------Number of subscriber hosts : 6
The remaining 4 hosts are not shown here.
=============================================================

Page 782

Advanced Configuration Guide

Flexible Authentication Model in ESM

The following command shows that the subscriber identity is set to circuit-id (plus session-id) as
instructed by the auto-sub-id-key command (the subscriber-id string is not returned via the
LUDB or RADIUS). The DHCPv4 lease time is set to set to 15 minutes as defined by the LUDB.
The DHCPv6 lease times are set to 30 minutes as configured under the group-interface. The
username passed to RADIUS is the circuit-id or username appended by the alu-dmain domain
name.
The origin of the lease is RADIUS.
*A:BNG-1# show service id 10 dhcp lease-state detail
===============================================================================
DHCP lease states for service 10
===============================================================================
Service ID
: 10
IP Address
: 10.10.0.230
Client HW Address
: 00:00:65:17:10:01
Subscriber-interface : sub-int-1
Group-interface
: open-auth
SAP
: [1/1/5:17.10]
Up Time
: 0d 00:02:09
Remaining Lease Time : 0d 00:12:51
Remaining SessionTime: N/A
Persistence Key
: N/A
Sub-Ident
Sub-Profile-String
SLA-Profile-String
App-Profile-String
Lease ANCP-String
Lease Int Dest Id
Category-Map-Name

:
:
:
:
:
:
:

"open-dhcp"
"rad-sub"
"rad-sla"
""
""
"open-auth-vport"
""

Lease Info origin

: UserDb

Ip-Netmask
Broadcast-Ip-Addr
Default-Router
Primary-Dns
Secondary-Dns
Primary-Nbns
Secondary-Nbns

:
:
:
:
:
:
:

255.255.255.0
10.10.0.255
10.10.0.254
172.16.20.20
172.16.20.21
N/A
N/A

ServerLeaseStart
ServerLastRenew
ServerLeaseEnd
Session-Timeout
Lease-Time
DHCP Server Addr

:
:
:
:
:
:

07/03/2013 13:45:14
07/03/2013 13:45:14
07/03/2013 14:00:14
N/A
0d 00:15:00
N/A

Relay Agent Information


Circuit Id
: open-dhcp
Remote Id
: ipoe-v6
Radius User-Name
: "open-dhcp@alu-domain"
Managed Routes
: 192.168.1.0/24
installed
------------------------------------------------------------------------------Number of lease states : 1
===============================================================================

Advanced Configuration Guide

Page 783

Configuration

For the purpose of brevity, the output for only two IPv6 leases is shown. The remaining two IPv6
leases are not shown since the output follows the same logic.
*A:BNG-1# show service id 10 dhcp6 lease-state detail
===============================================================================
DHCP lease states for service 10
===============================================================================
Service ID
: 10
IP Address
: 2001:DB8::100/128
Client HW Address
: 00:00:65:17:10:01
Subscriber-interface : sub-int-1
Group-interface
: open-auth
SAP
: [1/1/5:17.10]
Up Time
: 0d 00:02:17
Remaining Lease Time : 0d 00:27:43
Remaining SessionTime: N/A
Persistence Key
: N/A
Sub-Ident
:
Sub-Profile-String
:
SLA-Profile-String
:
App-Profile-String
:
Lease ANCP-String
:
Lease Int Dest Id
:
Category-Map-Name
:
Dhcp6 ClientId (DUID):
Dhcp6 IAID
:
Dhcp6 IAID Type
:
Dhcp6 Client Ip
:
Primary-Dns
:
Secondary-Dns
:
Pool Name
:
Dhcp6 Server Addr
:
Dhcp6 ServerId (DUID):
Dhcp6 InterfaceId
:
Dhcp6 RemoteId
:
Lease Info origin

"open-dhcp"
"rad-sub"
"rad-sla"
""
""
"open-auth-vport"
""
00030001000065171001
0
non-temporary
FE80::200:65FF:FE17:1001
2001:DB8::2000
2001:DB8::2001
""
N/A
N/A
open-dhcp
0000ipoe-v6

: UserDb

ServerLeaseStart
: 07/03/2013 13:45:17
ServerLastRenew
: 07/03/2013 13:45:17
ServerLeaseEnd
: 07/03/2013 14:15:17
Session-Timeout
: N/A
Radius User-Name
: "open-dhcp@alu-domain"
------------------------------------------------------------------------------Service ID
: 10
IP Address
: 2001:DB8:40:200::/56
Client HW Address
: 00:00:65:17:11:02
Subscriber-interface : sub-int-1
Group-interface
: open-auth
SAP
: [1/1/5:17.11]
Up Time
: 0d 00:02:09
Remaining Lease Time : 0d 00:27:51
Remaining SessionTime: N/A
Persistence Key
: N/A
Sub-Ident
Sub-Profile-String

Page 784

: "open-pppoe|1"
: "rad-sub"

Advanced Configuration Guide

Flexible Authentication Model in ESM

SLA-Profile-String
:
App-Profile-String
:
Lease ANCP-String
:
Lease Int Dest Id
:
Category-Map-Name
:
Dhcp6 ClientId (DUID):
Dhcp6 IAID
:
Dhcp6 IAID Type
:
Dhcp6 Client Ip
:
Primary-Dns
:
Secondary-Dns
:
Pool Name
:
Dhcp6 Server Addr
:
Dhcp6 ServerId (DUID):
Dhcp6 InterfaceId
:
Dhcp6 RemoteId
:
Lease Info origin

"rad-sla"
""
""
"open-auth-vport"
""
00030001000065171102
0
prefix
FE80::200:65FF:FE17:1102
2001:DB8::2000
2001:DB8::2001
""
N/A
N/A
open-pppoe
N/A

: UserDb

ServerLeaseStart
: 07/03/2013 13:45:26
ServerLastRenew
: 07/03/2013 13:45:26
ServerLeaseEnd
: 07/03/2013 14:15:26
Session-Timeout
: N/A
Radius User-Name
: "open-pppoe@alu-domain"
------------------------------------------------------------------------------Number of lease states : 4
The remaining lease states are not shown here.
===============================================================================

Advanced Configuration Guide

Page 785

Configuration

Troubleshooting Commands
The following output shows the debugging commands which can be used to troubleshoot
problems with the different authentication models.
*A:BNG-1# show debug
debug
router "Base"
radius
server-address X.Y.Z.Y
packet-type authentication
detail-level medium
exit
exit
router "10"
ip
dhcp
detail-level high
mode egr-ingr-and-dropped
exit
dhcp6
mode egr-ingr-and-dropped
detail-level high
exit
exit
local-dhcp-server "local"
detail-level high
mode egr-ingr-and-dropped
exit
local-dhcp-server "v6"
detail-level high
mode egr-ingr-and-dropped
exit
exit
mirror-source 100
port 1/1/5 egress ingress
no shutdown
exit
service
id 2
dhcp
mode egr-ingr-and-dropped
detail-level high
sap 1/1/5:17.*
exit
dhcp6
mode all
detail-level medium
sap 1/1/5:17.*
exit
ppp
packet
mode dropped-only
detail-level high
discovery
ppp
dhcp-client

Page 786

Advanced Configuration Guide

Flexible Authentication Model in ESM

exit
exit
exit
id 10
ppp
packet
mode egr-ingr-and-dropped
detail-level high
discovery
ppp
dhcp-client
exit
exit
exit
exit
subscriber-mgmt
local-user-db open-dhcp
detail all
exit
exit
exit

Advanced Configuration Guide

Page 787

Conclusion

Conclusion
The flexible authentication model allows access to various sources (LUDB, RADIUS, and
Python) of subscriber parameters during the subscriber establishment phase. This model can be
utilized for IPoE, PPPoE or L2TP subscribers in IES or VPRN services (including a wholesale/
retail VRF model). A typical use case would be in a wholesale/retail environment where the
wholesaler enforces its own rules via the LUDB before it passes the authentication request to the
retailers RADIUS server.

Page 788

Advanced Configuration Guide

Full IGP Shortcuts

In This Chapter
This section provides information about full IGP shortcuts.
Topics in this section include:

Applicability on page 790

Overview on page 791

Configuration on page 794

Conclusion on page 831

Advanced Configuration Guide

Page 789

Applicability

Applicability
The information in this section is applicable to all 7750 and 7710 SR series and all 7450 platforms
when the feature is not related to BGP and was tested on release 8.0R4. There are no other prerequisites for this configuration.

Page 790

Advanced Configuration Guide

Full IGP Shortcuts

Overview
Interior Gateway Protocols (IGPs) are routing protocols that operate inside an Autonomous
System (AS). An AS is a network domain that is managed under a single administration. Because
the scope of operation of an IGP is usually within an AS, IGPs are also called intra-AS protocols.
The purpose of an IGP is to provide reachability information to destination nodes that are inside
the domain. IGPs can be one or more of a variety of protocols, including dynamic routing
protocols such as RIP version 1 or 2, OSPF, and IS-IS.
IGPs such as OSPF and IS-IS are link-state protocols that use an SPF algorithm to compute the
shortest path tree to all nodes in a network. The results of such computations can be represented by
the destination node, next-hop address, and output interface, where the output interface is a
physical interface. Optionally, MPLS (Multiprotocol Label Switching) LSPs (Label Switched
Paths) can be used to be included in the SPF algorithm on the node performing the calculations, as
LSPs behave as logical interfaces directly connected to remote nodes in the network. Because the
SPF algorithm treats the LSPs in the same way as a physical interface (being a potential output
interface), the computation results could be to select a destination node together with an output
LSP, using the LSP as a shortcut through the network to the destination node.
Figure 38 shows a normal SPF tree sourced by PE-1 (Provider Edge-1).

PE-2

PE-4

PE-1

PE-6

PE-3

PE-5

OSSG624

Figure 38: Normal SPF Tree Sourced by PE-1

Advanced Configuration Guide

Page 791

Overview

If there is an LSP that connects PE-1 to PE-5, and IGP shortcuts are configured on PE-1, the SPF
tree will be as shown in Figure 39.

PE-2

PE-4

PE-1

PE-6

LSP

PE-

1-P

ES
PE-5

OSSG625

Figure 39: SPF Tree Sourced by PE-1 Using LSP Shortcuts

IGP shortcuts are enabled on a per router basis; SPF computations are independent and irrelevant
to other routers, so there is no need to enable shortcuts globally.
IGP shortcuts are supported on 7750, 7710, and 7450 (note that BGP related shortcuts are not
supported on 7450):
LDP shortcuts for static, IS-IS, OSPF and BGP
RSVP-TE shortcuts for static, IS-IS, OSPF, BGP
LDP and RSVP-TE LSP shortcut for BGP NH resolution within a VRF (auto-bind)
The network topology used in this example is displayed in Figure 40. The setup consists of 6
7750/7710 Service Routers. There is a single Autonomous System and a single IGP area, as IGP
Shortcuts only work in a single area. The following configuration tasks should be done up front:
IS-IS or OSPF in all interfaces within the AS (configuration has been done using ISIS but there is no difference if the feature is configured using OSPF).
LDP and RSVP in all interfaces within the AS.

Page 792

Advanced Configuration Guide

Full IGP Shortcuts

Lb: 172.16.2.1/32
Sys: 192.0.2.2/32

.2

PE-2

Lb: 172.16.4.1/32
Sys: 192.0.2.4/32

192.168.24.0/30
.1

1/1/4:1

.2

PE-4
.1

192.168.12.0/30
1/1/1:1

.1
Lb: 172.16.1.1/32
Sys: 192.0.2.1/32

.1 1/1/3:1

.1

192.168.46.0/30
1/1/2:1
.2

192.168.45.0/30

PE-1

1/1/2:1

PE-6

1/1/2:1
192.168.23.0/30

.1

1/1/1:1

.2

PE-3

.2
1/1/4:1
192.168.56.0/30
1/1/1:1
.1

.2 1/1/2:1

192.168.13.0/30
.2

Sys: 192.0.2.6/32
Lb: 172.16.6.1/32

.1

1/1/4:1

.2

PE-5

192.168.35.0/30
Lb: 172.16.3.1/32
Sys: 192.0.2.3/32

Lb: 172.16.5.1/32
Sys: 192.0.2.5/32
OSSG623

Figure 40: Tested Network Topology

Note: In all figures, Lb stands for Loopback and Sys stands for System IP addresses.

Advanced Configuration Guide

Page 793

Configuration

Configuration
The first step is to configure the IGP (IS-IS) in all nodes, where IS-IS redistributes route
reachability to all routers. To facilitate IS-IS configuration, all routers are L2-L1 capable within
the same IS-IS area-id so there is only a single topology area in the network (all routers share the
same topology). The configuration for PE-2 is displayed below.
*A:PE-2#configure router
#-------------------------------------------------echo "IP Configuration"
#-------------------------------------------------interface "int-PE-2-PE-1"
address 192.168.12.2/30
port 1/1/1:1
exit
interface "int-PE-2-PE-3"
address 192.168.23.1/30
port 1/1/2:1
exit
interface "int-PE-2-PE-4"
address 192.168.24.1/30
port 1/1/4:1
exit
interface "system"
address 192.0.2.2/32
exit
#-------------------------------------------------echo "ISIS Configuration"
#-------------------------------------------------isis
area-id 49.0001
traffic-engineering
interface "system"
passive
exit
interface "int-PE-2-PE-1"
interface-type point-to-point
exit
interface "int-PE-2-PE-3"
interface-type point-to-point
exit
interface "int-PE-2-PE-4"
interface-type point-to-point
exit
exit

The configuration for the rest of nodes is very similar. The IP addresses can be derived from
Figure 40.

Page 794

Advanced Configuration Guide

Full IGP Shortcuts

The Global Route Table (GRT) is displayed below.


*A:PE-2# show router route-table
===============================================================================
Route Table (Router: Base)
===============================================================================
Dest Prefix
Type
Proto
Age
Pref
Next Hop[Interface Name]
Metric
------------------------------------------------------------------------------192.0.2.1/32
Remote ISIS
16h07m38s
15
192.168.12.1
10
192.0.2.2/32
Local
Local
16h15m08s
0
system
0
192.0.2.3/32
Remote ISIS
16h11m32s
15
192.168.23.2
10
192.0.2.4/32
Remote ISIS
16h03m59s
15
192.168.24.2
10
192.0.2.5/32
Remote ISIS
16h00m18s
15
192.168.23.2
20
192.0.2.6/32
Remote ISIS
16h03m59s
15
192.168.24.2
20
192.168.12.0/30
Local
Local
16h14m56s
0
int-PE-2-PE-1
0
192.168.13.0/30
Remote ISIS
16h07m38s
15
192.168.12.1
20
192.168.23.0/30
Local
Local
16h14m56s
0
int-PE-2-PE-3
0
192.168.24.0/30
Local
Local
16h04m23s
0
int-PE-2-PE-4
0
192.168.35.0/30
Remote ISIS
16h00m18s
15
192.168.23.2
20
192.168.45.0/30
Remote ISIS
00h21m29s
15
192.168.24.2
20
192.168.46.0/30
Remote ISIS
16h03m59s
15
192.168.24.2
20
192.168.56.0/30
Remote ISIS
16h00m18s
15
192.168.23.2
30
------------------------------------------------------------------------------No. of Routes: 14
===============================================================================

Advanced Configuration Guide

Page 795

Configuration

LDP and RSVP Shortcuts


Interface Label Distribution Protocol (iLDP) is enabled in all interfaces (except system interfaces,
which is not allowed) in all routers. The configuration in all nodes is similar and the IP addresses
are derived from Figure 40. The following displays the configuration of PE-4.
A:PE-4>configure router ldp
interface-parameters
interface "int-PE-4-PE-2"
exit
interface "int-PE-4-PE-5"
exit
interface "int-PE-4-PE-6"
exit
exit
targeted-session
exit

With iLDP enabled, PE-4 establishes iLDP sessions with its directly connected neighbors, as
shown below.
*A:PE-4# show router ldp session
==============================================================================
LDP Sessions
==============================================================================
Peer LDP Id
Adj Type
State
Msg Sent Msg Recv Up Time
-----------------------------------------------------------------------------192.0.2.2:0
Link
Established
276
275
0d 00:12:23
192.0.2.5:0
Link
Established
2629
2632
0d 02:01:20
192.0.2.6:0
Link
Established
225
226
0d 00:10:06
-----------------------------------------------------------------------------No. of Sessions: 3
==============================================================================

Reviewing the tunnel table, which shows LSPs, the command shows that there is an LSP to every
router. The reason is that LDP is DU (Downstream Unsolicited) by default, so for every system
address (which is used by iLDP as transport address by default) there is an LSP, where the
preference is 9 for LDP, and the metric is 10 per hop (metric is inherited from the IGP), as shown
below. Destination to PE-1 and PE-2 metric is 20 because there are two hops in between (PE-4 is
two hops away from PE-1 and PE-2).
*A:PE-4# show router tunnel-table
===============================================================================
Tunnel Table (Router: Base)
===============================================================================
Destination
Owner Encap TunnelId Pref
Nexthop
Metric
------------------------------------------------------------------------------192.0.2.1/32
ldp
MPLS
9
192.168.24.1
20
192.0.2.2/32
ldp
MPLS
9
192.168.24.1
10
192.0.2.3/32
ldp
MPLS
9
192.168.24.1
20
192.0.2.5/32
ldp
MPLS
9
192.168.45.2
10

Page 796

Advanced Configuration Guide

Full IGP Shortcuts

192.0.2.6/32
ldp
MPLS
9
192.168.46.2
10
===============================================================================

In order to configure RSVP shortcuts, RSVP should be enabled in all interfaces where traffic
engineering is required. For simplicity, RSVP is configured in all interfaces of the network,
including system interfaces. The configuration for PE-6 is displayed below.
*A:PE-6#configure router
mpls
interface "system"
exit
interface "int-PE-6-PE-5"
exit
interface "int-PE-6-PE-4"
exit
exit
rsvp
interface "system"
exit
interface "int-PE-6-PE-5"
exit
interface "int-PE-6-PE-4"
exit
no shutdown
exit

The configuration for the rest of nodes is very similar. The IP addresses can be derived from
Figure 40. Because there are no RSVP LSPs configured yet, the tunnel-table has no RSVP LSPs
and only contains LDP LSPs.

Advanced Configuration Guide

Page 797

Configuration

LDP Static Route (IP Tunneled in LDP Tunnel)


LDP LSP shortcut for static routes resolution allows forwarding of IPv4 packets to resolved static
routes using an LDP LSP instead of using a regular IP next-hop.
The configuration defines a static route pointing to the destination PE (remote loopback, which is
an indirect next hop in the example), and explicitly indicates that it should use LDP rather than
IGP. Taking PE-1 and PE-6 as an example, two loopback interfaces are configured (172.16.X.1/
32), where X = PE number, and a static-route is defined according to the explanation above. The
following shows the configuration on PE-1.
*A:PE-1>config router
#-------------------------------------------------echo "IP Configuration"
#-------------------------------------------------interface "int-PE-1-PE-2"
address 192.168.12.1/30
port 1/1/2:1
exit
interface "int-PE-1-PE-3"
address 192.168.13.1/30
port 1/1/1:1
exit
interface "loopback"
address 172.16.1.1/32
loopback
exit
interface "system"
address 192.0.2.1/32
exit
#-------------------------------------------------echo "Static Route Configuration"
#-------------------------------------------------static-route 172.16.6.1/32 indirect 192.0.2.6 ldp disallow-igp

Reviewing the GRT or FIB (Forwarding Database), note that there are two new entries with the
two configured loopbacks. One entry is associated with protocol local (local loopback on the PE),
and the other entry is protocol static, where the next hop is reached using a LDP LSP.
*A:PE-1# show router fib 1
===============================================================================
FIB Display
===============================================================================
Prefix
Protocol
NextHop
------------------------------------------------------------------------------172.16.1.1/32
LOCAL
172.16.1.1 (loopback)
172.16.6.1/32
STATIC
192.0.2.6 (Transport:LDP)
* Truncated info

Page 798

Advanced Configuration Guide

Full IGP Shortcuts

The next output is to test that a ping sourced by PE-1 loopback is able to reach PE-6, and a
traceroute to demonstrate that the traffic is following the LDP LSP. The ping and traceroute
commands cannot follow the IGP because the static-route command states that the IGP is
disallowed (also, the loopback interfaces are not enabled on IS-IS).
*A:PE-1# ping 172.16.6.1 source 172.16.1.1
PING 172.16.6.1 56 data bytes
64 bytes from 172.16.6.1: icmp_seq=1 ttl=64
64 bytes from 172.16.6.1: icmp_seq=2 ttl=64
64 bytes from 172.16.6.1: icmp_seq=3 ttl=64
64 bytes from 172.16.6.1: icmp_seq=4 ttl=64
64 bytes from 172.16.6.1: icmp_seq=5 ttl=64

time=4.08ms.
time=3.80ms.
time=4.77ms.
time=3.85ms.
time=3.83ms.

---- 172.16.6.1 PING Statistics ---5 packets transmitted, 5 packets received, 0.00% packet loss
round-trip min = 3.80ms, avg = 4.07ms, max = 4.77ms, stddev = 0.371ms
*A:PE-1# traceroute 172.16.6.1 source 172.16.1.1
traceroute to 172.16.6.1 from 172.16.1.1, 30 hops max, 40 byte packets
1 0.0.0.0 * * *
2 0.0.0.0 * * *
3 172.16.6.1 (172.16.6.1)
4.64 ms 9.87 ms 5.84 ms

With the traceroute command, there are three hops from PE-1 to PE-6. There is no information
regarding IP for the first two hops because the traffic is encapsulated in an MPLS LDP. The reason
why the hops are displayed even when there is an MPLS LSP tunnel is because by default, the SR
router propagates (copies) the Time to Live (TTL) from the IP header in the MPLS header.
However, a service provider might not be interested to show how many MPLS hops (nodes) there
are in the network if a traceroute command is executed from outside the network by an external
router. To disallow it, no propagate commands are needed in the LDP configuration, as shown
below.
*A:PE-1#config router ldp
no shortcut-local-ttl-propagate
no shortcut-transit-ttl-propagate
interface-parameters
interface "int-PE-1-PE-2"
exit
interface "int-PE-1-PE-3"
exit
exit
targeted-session
exit

After the TTL propagation is disabled, the hops are not displayed any longer when running the
traceroute command.
*A:PE-1# traceroute 172.16.6.1 source 172.16.1.1
traceroute to 172.16.6.1 from 172.16.1.1, 30 hops max, 40 byte packets
1 172.16.6.1 (172.16.6.1)
5.08 ms 4.73 ms 4.77 ms

Advanced Configuration Guide

Page 799

Configuration

RSVP Static Route (IP Tunneled in RSVP Tunnel)


RSVP-TE LSP shortcut for static routes resolution allows forwarding of IPv4 packets to resolved
static routes using an RSVP-TE LSP instead of using a regular IP next-hop.
The configuration defines a static route pointing to a destination PE (remote loopback, which is an
indirect next hop in the example), and explicitly indicates that it should use RSVP rather than IGP.
Taking PE-6 and PE-2 as an example, two loopback interfaces are configured (172.16.X.1/32),
where X = PE number, and a static-route is defined according to the explanation above. The
following shows the configuration on PE-6.
*A:PE-6>config router
#-------------------------------------------------echo "IP Configuration"
#-------------------------------------------------interface "int-PE-6-PE-4"
address 192.168.46.2/30
port 1/1/2:1
exit
interface "int-PE-6-PE-5"
address 192.168.56.2/30
port 1/1/4:1
exit
interface "loopback"
address 172.16.6.1/32
loopback
exit
interface "system"
address 192.0.2.6/32
exit
#-------------------------------------------------echo "Static Route Configuration"
#-------------------------------------------------static-route 172.16.1.1/32 indirect 192.0.2.1 rsvp-te disallow-igp

Also, an RSVP LSP needs to be configured with destination PE-1 system interface:
*A:PE-6>config router mpls
interface "system"
exit
interface "int-PE-6-PE-5"
exit
interface "int-PE-6-PE-4"
exit
path "p"
no shutdown
exit
lsp "LSP-PE-6-PE-1"
to 192.0.2.1
primary "p"
exit
no shutdown
exit
no shutdown

Page 800

Advanced Configuration Guide

Full IGP Shortcuts

Reviewing the LSP tunnel table, observe that there is an RSVP LSP created:
*A:PE-6>config>router# show router tunnel-table
===============================================================================
Tunnel Table (Router: Base)
===============================================================================
Destination
Owner Encap TunnelId Pref
Nexthop
Metric
------------------------------------------------------------------------------192.0.2.1/32
rsvp MPLS 1
7
192.168.56.1
30
===============================================================================

Note that the default RSVP preference is 7 (more preferred than LDP, which is 9) and the metric
reflects that this LSP spans 3 hops.
The RSVP LSP is used to resolve the next hop (PE-1 system address) in the static route (the LSP
used is identified with the Tunnel ID, in this case 1), hence the GRT is modified with the following
entry:
*A:PE-6# show router route-table
===============================================================================
Route Table (Router: Base)
===============================================================================
Dest Prefix
Type
Proto
Age
Pref
Next Hop[Interface Name]
Metric
------------------------------------------------------------------------------172.16.1.1/32
Remote Static
00h09m55s
5
192.0.2.1 (tunneled:RSVP:1)
1
*Truncated info
------------------------------------------------------------------------------No. of Routes: 16
===============================================================================

Same as LDP shortcut with static route example, running a traceroute between PE-6 and PE-1
when TTL propagation is disabled (in this case, TTL propagation commands are configured in the
config>router>mpls context), the output is the following:
*A:PE-6# traceroute 172.16.1.1 source 172.16.6.1
traceroute to 172.16.1.1 from 172.16.6.1, 30 hops max, 40 byte packets
1 172.16.1.1 (172.16.1.1)
4.71 ms 24.7 ms 17.2 ms

Note that shortcuts using a statically configured LSP can also be created with the rsvp-te
parameter as above.

Advanced Configuration Guide

Page 801

Configuration

LDP Shortcut for IGP Route Resolution


LDP shortcut for IGP route resolution allows forwarding of packets using an LDP LSP over all
network interfaces in the system that participate in the IS-IS and OSPF routing protocols. The
default is to disable the LDP shortcut across all interfaces in the node.
When LDP shortcut is enabled, LDP populates the RTM (Route Table Manager) with next-hop
entries corresponding to all prefixes for which it activated an LDP Forwarding Equivalence Class
(FEC). For a given prefix, two route entries are populated in RTM. One corresponds to the LDP
shortcut next-hop and has an owner of LDP. The other one is the regular IP next-hop. The LDP
shortcut next-hop always has preference over the regular IP next-hop for forwarding user packets
and specified control packets over a given outgoing interface to the route next-hop.
Once LDP has activated a FEC for a given prefix and programmed RTM, it also programs the
ingress tunnel table in the IOM with the LDP tunnel information.
When an IPv4 packet is received on an ingress network interface, a subscriber Internet Enhanced
Service (IES) interface, or a regular IES interface, the lookup of the packet by the ingress IOM
will result in the packet being sent labeled with the label stack corresponding to the Next Hop
Label Forwarding Entry (NHLFE) of the LDP LSP when the preferred RTM entry corresponds to
an LDP shortcut. If the preferred RTM entry corresponds to an IP next-hop, the IPv4 packet is
forwarded unlabeled.

Handling of Control Packets


All control plane packets will not see the LDP shortcut route entry in RTM with the exception of
the following control packets which will be forwarded over an LDP shortcut when enabled:

A locally generated or in transit ICMP ping and trace route of an IGP route. The transit
message appears as a user packet to the ingress LER node.

A locally generated response to a received ICMP ping or trace route message.

All other control plane packets that require an RTM lookup and have knowledge of which
destination is reachable over the LDP shortcut will continue to be forwarded over the IP next-hop
route in RTM.

Page 802

Advanced Configuration Guide

Full IGP Shortcuts

Handling of Multicast Packets


LDP shortcuts apply to unicast FEC types and are used for forwarding IP unicast packets in the
data path. LDP shortcuts are not visible to any other application, except ping and traceroute
packets generated and responded to by CPM.
IP multicast packets forwarded over an mLDP P2MP LSP make use of a multicast FEC and thus
cannot make use of the LDP unicast shortcut.

ECMP Considerations
When ECMP is enabled and multiple equal-cost next-hops exist for the IGP route, the ingress
IOM will spray the packets for this route based on hashing routine currently supported for IPv4
packets. When the preferred RTM entry corresponds to an LDP shortcut route, spraying will be
performed across the multiple next-hops for the LDP FEC. The FEC next-hops can either be direct
link LDP neighbors or T-LDP (Targeted LDP) neighbors reachable over RSVP LSPs in the case of
LDP-over-RSVP but not both. This is as per ECMP for LDP in existing implementation. When the
preferred RTM entry corresponds to a regular IP route, spraying will be performed across regular
IP next-hops for the prefix. Spraying across regular IP next-hops and LDP-shortcut next-hops
concurrently is not supported.
The configuration of IGP LDP shortcuts is straightforward, and only applies to the node where
there is interest to provision the LDP shortcut. In the network example, only PE-1 is provisioned
with LDP shortcuts, as shown below.
*A:PE-1#config router ldp-shortcut

Now, all tunnel LSPs that resolve an IGP next hop will replace the IP next hops, as depicted in the
following displays:
*A:PE-1>config>router# show router route-table
===============================================================================
Route Table (Router: Base)
===============================================================================
Dest Prefix
Type
Proto
Age
Pref
Next Hop[Interface Name]
Metric
------------------------------------------------------------------------------192.0.2.1/32
Local
Local
23h57m47s
0
system
0
192.0.2.2/32
Remote LDP
00h00m04s
9
192.168.12.2 (tunneled)
10
192.0.2.3/32
Remote LDP
00h00m04s
9
192.168.13.2 (tunneled)
10
192.0.2.4/32
Remote LDP
00h00m04s
9
192.168.12.2 (tunneled)
20
192.0.2.5/32
Remote LDP
00h00m04s
9
192.168.13.2 (tunneled)
20
192.0.2.6/32
Remote LDP
00h00m04s
9

Advanced Configuration Guide

Page 803

Configuration

192.168.12.2 (tunneled)
30
192.168.12.0/30
Local
Local
23h57m33s
0
int-PE-1-PE-2
0
192.168.13.0/30
Local
Local
02h40m29s
0
int-PE-1-PE-3
0
192.168.23.0/30
Remote ISIS
02h30m22s
15
192.168.12.2
20
192.168.24.0/30
Remote ISIS
23h53m58s
15
192.168.12.2
20
192.168.35.0/30
Remote ISIS
02h40m28s
15
192.168.13.2
20
192.168.45.0/30
Remote ISIS
02h30m22s
15
192.168.12.2
30
192.168.46.0/30
Remote ISIS
23h53m53s
15
192.168.12.2
30
192.168.56.0/30
Remote ISIS
02h40m28s
15
192.168.13.2
30
------------------------------------------------------------------------------No. of Routes: 14
*A:PE-1>config>router#
*A:PE-1>config>router# show router fib 1
===============================================================================
FIB Display
===============================================================================
Prefix
Protocol
NextHop
------------------------------------------------------------------------------192.0.2.1/32
LOCAL
192.0.2.1 (system)
192.0.2.2/32
LDP
192.0.2.2 (Transport:LDP)
192.0.2.3/32
LDP
192.0.2.3 (Transport:LDP)
192.0.2.4/32
LDP
192.0.2.4 (Transport:LDP)
192.0.2.5/32
LDP
192.0.2.5 (Transport:LDP)
192.0.2.6/32
LDP
192.0.2.6 (Transport:LDP)
192.168.12.0/30
LOCAL
192.168.12.0 (int-PE-1-PE-2)
192.168.13.0/30
LOCAL
192.168.13.0 (int-PE-1-PE-3)
192.168.23.0/30
ISIS
192.168.12.2 (int-PE-1-PE-2)
192.168.24.0/30
ISIS
192.168.12.2 (int-PE-1-PE-2)
192.168.35.0/30
ISIS
192.168.13.2 (int-PE-1-PE-3)
192.168.45.0/30
ISIS
192.168.12.2 (int-PE-1-PE-2)
192.168.46.0/30
ISIS
192.168.12.2 (int-PE-1-PE-2)
192.168.56.0/30
ISIS
192.168.13.2 (int-PE-1-PE-3)
------------------------------------------------------------------------------Total Entries : 14

Page 804

Advanced Configuration Guide

Full IGP Shortcuts

Only applying LDP IGP shortcuts on PE-1 implies that IP traffic from PE-1 to any of the system
addresses of the rest of nodes will use the LDP shortcut, however, the traffic replied from any PE
back to PE-1 will be native IP since IGP shortcuts have not been provisioned in those.

Advanced Configuration Guide

Page 805

Configuration

RSVP Shortcut for IGP Route Resolution


RSVP LSP shortcut for IGP route resolution allows forwarding of packets to IGP learned routes
using an RSVP LSP. The use of RSVP shortcut for resolving IGP routes is enabled at the IS-IS
routing protocol level or at the OSPF routing protocol instance level, and will instruct IS-IS and
OSPF to include RSVP LSPs originating on this node and terminating on the router-id of a remote
node as direct links. RSVP LSPs with a destination address corresponding to an interface address
of a remote node are automatically not considered by IS-IS or OSPF. It is possible to exclude a
specific RSVP LSP from being used as a shortcut for resolving IGP routes (config router mpls lsp
lsp_name no igp-shortcut). By default, rsvp-shortcut is disabled in all IGP instances.
RSVP LSPs are included in the IGP SPF computation with the following characteristics:

RSVP LSP is modeled like a point-to-point link IP interface and its metric is used in the
computation of the shortest path of IGP routes

Next-hop and interface will include the NHLFE of the shortcut LSP when the IGP path
cost using the RSVP LSP is the best.

Shortcuts are not used when destination RSVP LSP is in a different IGP area. In addition, IGP
adjacencies across an RSVP LSP are not supported.
Also, the SPF in OSPF or IS-IS will only use RSVP LSPs as IGP shortcuts or as endpoints for
LDP-over-RSVP. These applications of RSVP LSPs are mutually exclusive at the IGP instance
level. If the user enables both options at the IGP instance level, then the shortcut application takes
precedence when the LSP level configuration has both options enabled. Next display shows the
configuration:
*A:PE>config>router>isis/ospf
- rsvp-shortcut
- ldp-over-rsvp
*A:PE>config>router>mpls>lsp#
- igp-shortcut
- ldp-over-rsvp include
- to router-id

To enable RSVP shortcuts, there are some rules to follow:

Page 806

Routing Instance (OSPF or IS-IS) takes precedence over LSP

RSVP shortcut takes precedence over LDPoRSVP

Advanced Configuration Guide

Full IGP Shortcuts

Table 18 provides the outcome of the configuration of the LDPoRSVP and RSVP shortcut or LDP
shortcut options at both the IGP instance level and at the LSP level:

Table 18: Shortcut Options


Instance
Shortcut-Enbl
LDP/RSVP-Enbl

Instance
Shortcut-Enbl
LDP/RSVP-Dis

Instance
Shortcut-Dis
LDP/RSVP-Enbl

Instance
Shortcut-Dis
LDP/RSVP-Dis

Tunnel Shortcut-Enbl
LDP/RSVP-Enbl

Shortcut
(Override case)

Shortcut
(Override case)

LDP/RSVP

None

Tunnel Shortcut-Enbl
LDP/RSVP-Dis

Shortcut

Shortcut

None

None

Tunnel Shortcut-Dis
LDP/RSVP-Enbl

LDP/RSVP

None

LDP/RSVP

None

Tunnel Shortcut-Dis
LDP/RSVP-Dis

None

None

None

None

Because RSVP shortcuts can coexist with LDP shortcuts or IP next hops, SPF computation and
path selection follows the procedures in RFC 3906:

SPF picks the RSVP shortcut next-hop if there is an RSVP LSP directly to that address
regardless of the path cost compared to the IGP next-hop.

SPF picks the RSVP shortcut next-hop or the IGP next-hop based on path lowest cost if
there is an IGP path to the prefix that does not go via the tail-end of the LSP.

If the IGP next-hop is picked, then it can be an LDP shortcut next-hop or a regular IP
next-hop. The LDP shortcut next-hop always has preference over the regular IP next-hop

Advanced Configuration Guide

Page 807

Configuration

Handling of Control Packets


All control plane packets which require a RTM lookup and whose destination is reachable over the
RSVP shortcut will be forwarded over the shortcut. This is because RTM keeps a single route
entry for each prefix except if there is ECMP over different outgoing interfaces. Interface bound
control packets are not impacted by the RSVP shortcut since RSVP LSPs with a destination
address different than the router-id are not included by IGP in its SPF calculation.
Note: RSVP hop-by-hop Path messages will try to use the shortcut and consequently LSPs without
cspf enabled, or that use a loose/empty hop path, will not come up. However, LSPs with cspf
enabled or using a strict hop path will come up. This is because in the former case the RTM lookup
to get the next hop will result in using the shortcut and so the path messages will be sent directly to
the destination of the LSP, where they will be dropped. With CSPF enabled, the next-hop (and the
entire path) is provided by CSPF and the path messages are sent unlabeled to the directly
connected neighbor which corresponds to the next-hop of the destination of the LSP. Similar
processing occurs if a strict hop path is used, as is the case in the next example.

Handling of Multicast Packets


IP multicast packets cannot be forwarded over an RSVP shortcut, they can only be forwarded over
an RSVP P2MP LSP. However, as RSVP shortcut routes appear in RTM and are seen by all
applications when they are the best route, if the reverse path forwarding check for the source of the
multicast packet matches an RSVP shortcut route, the check will fail. Therefore the multicast
source must have its own (static or other IGP instance) route reachability in the presence of
shortcuts.

Page 808

Advanced Configuration Guide

Full IGP Shortcuts

ECMP Considerations
When ECMP is enabled and multiple equal-cost paths exist for the IGP route, the ingress IOM
will spray the packets for this route based on the hashing routine currently supported for IPv4
packets.
The configuration of RSVP LSP shortcuts is straightforward, and only applies to the node where
there is interest to provision the RSVP shortcut. Two LSPs, from PE-6 to PE-1 and from PE-1 to
PE-6, with strict hops, are provisioned according to Figure 41, as shown below.

Lb: 172.16.2.1/32
Sys: 192.0.2.2/32

.2

PE-2

Lb: 172.16.4.1/32
Sys: 192.0.2.4/32

192.168.24.0/30
.1

1/1/4:1

.2

PE-4
.1

192.168.12.0/30
.1
Lb: 172.16.1.1/32
Sys: 192.0.2.1/32

.1 1/1/3:1

.1

1/1/1:1

192.168.46.0/30
1/1/2:1
.2

192.168.45.0/30

PE-1

1/1/2:1

PE-6

1/1/2:1
192.168.23.0/30

.1

1/1/1:1

.2

.2
1/1/4:1
192.168.56.0/30
1/1/1:1
.1

.2 1/1/2:1

192.168.13.0/30
.2

Sys: 192.0.2.6/32
Lb: 172.16.6.1/32

.1

PE-3

1/1/4:1

.2

PE-5

192.168.35.0/30
Lb: 172.16.3.1/32
Sys: 192.0.2.3/32

Lb: 172.16.5.1/32
Sys: 192.0.2.5/32
OSSG626

Figure 41: LSPs between PE-1 and PE-6

The configuration on PE-1 and PE-6 is similar (replacing the IP addresses), so only the
configuration in PE-6 is shown:
*A:PE-6#config router isis
area-id 49.0001
traffic-engineering
rsvp-shortcut
advertise-tunnel-link
interface "system"
passive
exit

Advanced Configuration Guide

Page 809

Configuration

interface "int-PE-6-PE-5"
interface-type point-to-point
exit
interface "int-PE-6-PE-4"
interface-type point-to-point
exit
exit
*A:PE-6#config router mpls
path "PE-1"
hop 1 192.0.2.5
hop 2 192.0.2.3
hop 3 192.0.2.2
hop 4 192.0.2.1
no shutdown
exit
lsp "LSP-PE-6-PE-1"
to 192.0.2.1
primary "PE-1"
exit
no shutdown
exit
no shutdown
exit

strict
strict
strict
strict

The GRT output shows the change in the next hop, using an RSVP shortcut:
*A:PE-6# show router route-table
===============================================================================
Route Table (Router: Base)
===============================================================================
Dest Prefix
Type
Proto
Age
Pref
Next Hop[Interface Name]
Metric
------------------------------------------------------------------------------172.16.6.1/32
Local
Local
21h40m00s
0
loopback
0
192.0.2.1/32
Remote ISIS
00h00m07s
15
192.0.2.1 (tunneled:RSVP:1)
65535
192.0.2.2/32
Remote ISIS
00h00m07s
15
192.168.46.1
20
192.0.2.3/32
Remote ISIS
01d22h34m
15
192.168.56.1
20
192.0.2.4/32
Remote ISIS
01d22h42m
15
192.168.46.1
10
192.0.2.5/32
Remote ISIS
07d22h10m
15
192.168.56.1
10
192.0.2.6/32
Local
Local
07d22h12m
0
system
0
192.168.12.0/30
Remote ISIS
00h00m07s
15
192.168.46.1
30
192.168.13.0/30
Remote ISIS
00h00m07s
15
192.168.56.1
30
192.168.23.0/30
Remote ISIS
00h00m07s
15
192.168.46.1
30
192.168.24.0/30
Remote ISIS
01d22h42m
15
192.168.46.1
20
192.168.35.0/30
Remote ISIS
07d22h10m
15
192.168.56.1
20
192.168.45.0/30
Remote ISIS
01d01h14m
15

Page 810

Advanced Configuration Guide

Full IGP Shortcuts

192.168.46.1
20
192.168.46.0/30
Local
Local
03d08h47m
0
int-PE-6-PE-4
0
192.168.56.0/30
Local
Local
07d22h11m
0
int-PE-6-PE-5
0
------------------------------------------------------------------------------No. of Routes: 15

The RSVP LSP in the output has a metric of 65535, as the second of the following bullets applies
in the RSVP LSP metric determination in current implementation:

A dynamic empty path non-CSPF LSP has a metric equal to the path IGP cost.

A dynamic strict/loose path non-CSPF LSP has the maximum metric (65535).

A dynamic CSPF LSP has a metric equal to the path IGP cost. If the user enabled the use
of the TE metric on this LSP, then the metric for the LSP is the maximum (65535).

A static LSP has an infinite metric (65535).

Manual and dynamic bypass LSPs have the maximum metric (65535)

The LSP metric can be changed, as covered in next section Advertising RSVP LSP Tunnel Links
in the IGP.

Advanced Configuration Guide

Page 811

Configuration

Advertising RSVP LSP Tunnel Links in the IGP


If configured, an RSVP LSP shortcut can also be advertised into the IGP similar to regular links
such that other routers in the network can include it into their SPF computations. An LSP must
exist in the reverse direction in order for the advertised link to pass the bi-directional link check
and be usable by other routers in the network. However, this is not required for the node which
originates the LSP. The LSP is advertised as an unnumbered point-to-point link and the link LSP/
LSA has no Traffic Engineering opaque sub-TLVs as per RFC 3906, Calculating Interior Gateway
Protocol (IGP) Routes Over Traffic Engineering Tunnels.
Reusing the RSVP IGP shortcuts set up (PE-1 and PE-6 RSVP IGP shortcut example as shown in
Figure 41), the outcome was a route linked with an RSVP LSP as next hop, as seen below:
*A:PE-6# show router route-table
===============================================================================
Route Table (Router: Base)
===============================================================================
Dest Prefix
Type
Proto
Age
Pref
Next Hop[Interface Name]
Metric
------------------------------------------------------------------------------192.0.2.1/32
Remote ISIS
00h00m07s
15
192.0.2.1 (tunneled:RSVP:1)
65535
* Truncated info
0
------------------------------------------------------------------------------No. of Routes: 15

The route tunnelled through RSVP has a metric of 65535, so it is not used by PE-6 GRT to reach
any other routes since the metric is very high. After enabling OSPF/IS-IS to use shortcuts as
tunnel links in the configuration, PE-1 and PE-6 have a direct connection through the RSVP LSP
(as a virtual link). This configuration command must be executed in both routers, although for
simplicity only PE-6 is displayed:
*A:PE-6#config router isis
advertise-tunnel-link

Checking GRT on PE-4, it displays the route to reach PE-1 (192.0.2.1/32) with a metric of 20 via
PE-2 as next-hop. Although now PE-6 is announcing the RSVP LSP-PE-6-PE-1 to the other
routers, the LSP shortcut is not used by PE-4 because the metric to reach PE-6 (10) plus the metric
of the LSP shortcut from PE-6 to PE-1 (metric 65536) is greater than 20.
*A:PE-4# show router route-table
===============================================================================
Route Table (Router: Base)
===============================================================================
Dest Prefix
Type
Proto
Age
Pref
Next Hop[Interface Name]
Metric
------------------------------------------------------------------------------192.0.2.1/32
Remote ISIS
05h55m29s
15
192.168.24.1
20
192.0.2.2/32
Remote ISIS
02d04h33m
15
192.168.24.1
10

Page 812

Advanced Configuration Guide

Full IGP Shortcuts

192.0.2.3/32
Remote ISIS
01d07h09m
15
192.168.24.1
20
192.0.2.4/32
Local
Local
02d04h37m
0
system
0
192.0.2.5/32
Remote ISIS
01d12h50m
15
192.168.45.2
10
192.0.2.6/32
Remote ISIS
05h51m47s
15
192.168.46.2
10
192.168.12.0/30
Remote ISIS
02d04h33m
15
192.168.24.1
20
192.168.13.0/30
Remote ISIS
05h55m29s
15
192.168.24.1
30
192.168.23.0/30
Remote ISIS
02d04h33m
15
192.168.24.1
20
192.168.24.0/30
Local
Local
02d04h37m
0
int-PE-4-PE-2
0
192.168.35.0/30
Remote ISIS
01d12h50m
15
192.168.45.2
20
192.168.45.0/30
Local
Local
01d12h50m
0
int-PE-4-PE-5
0
192.168.46.0/30
Local
Local
02d04h37m
0
int-PE-4-PE-6
0
192.168.56.0/30
Remote ISIS
01d07h09m
15
192.168.45.2
20
------------------------------------------------------------------------------No. of Routes: 14
===============================================================================

If the metric of the LSP LSP-PE-6-PE-1 is modified to a value between 1 and 9, there is a better
metric (less than 20) so that PE-4 will change the next hop via PE-6. See the following displays,
first the metric of the LSP is modified to 9:
*A:PE-6#config router mpls
lsp "LSP-PE-6-PE-1" metric 9

And checking PE-4s GRT the next hop to reach PE-1 has changed, from next-hop PE-2 to nexthop PE-6 (hence, using the LSP shortcut), and the metric is 19 (10 to reach PE-6 plus metric 9 of
the LSP PE-6-PE-1 shortcut):
*A:PE-4# show router route-table
===============================================================================
Route Table (Router: Base)
===============================================================================
Dest Prefix
Type
Proto
Age
Pref
Next Hop[Interface Name]
Metric
------------------------------------------------------------------------------192.0.2.1/32
Remote ISIS
00h00m10s
15
192.168.46.2
19
* Truncated info
------------------------------------------------------------------------------No. of Routes: 14
===============================================================================

Advanced Configuration Guide

Page 813

Configuration

Because the metric of the LSP shortcut was modified to a value of 9, when displaying the GRT of
PE-6 it is noted that the next hops of several routes have changed and are also using the shortcut
LSP PE-6-PE-1 because the metric is better than regular IS-IS.
*A:PE-6# show router route-table
===============================================================================
Route Table (Router: Base)
===============================================================================
Dest Prefix
Type
Proto
Age
Pref
Next Hop[Interface Name]
Metric
------------------------------------------------------------------------------172.16.6.1/32
Local
Local
01d03h55m
0
loopback
0
192.0.2.1/32
Remote ISIS
00h02m58s
15
192.0.2.1 (tunneled:RSVP:1)
9
192.0.2.2/32
Remote ISIS
00h02m58s
15
192.0.2.1 (tunneled:RSVP:1)
19
192.0.2.3/32
Remote ISIS
06h11m33s
15
192.168.56.1
20
192.0.2.4/32
Remote ISIS
06h11m33s
15
192.168.46.1
10
192.0.2.5/32
Remote ISIS
06h11m33s
15
192.168.56.1
10
192.0.2.6/32
Local
Local
08d04h27m
0
system
0
192.168.12.0/30
Remote ISIS
00h02m58s
15
192.0.2.1 (tunneled:RSVP:1)
19
192.168.13.0/30
Remote ISIS
00h02m58s
15
192.0.2.1 (tunneled:RSVP:1)
19
192.168.23.0/30
Remote ISIS
00h02m58s
15
192.0.2.1 (tunneled:RSVP:1)
29
192.168.24.0/30
Remote ISIS
06h11m33s
15
192.168.46.1
20
192.168.35.0/30
Remote ISIS
06h11m33s
15
192.168.56.1
20
192.168.45.0/30
Remote ISIS
06h11m33s
15
192.168.46.1
20
192.168.46.0/30
Local
Local
03d15h03m
0
int-PE-6-PE-4
0
192.168.56.0/30
Local
Local
08d04h27m
0
int-PE-6-PE-5
0
------------------------------------------------------------------------------No. of Routes: 15
===============================================================================

Page 814

Advanced Configuration Guide

Full IGP Shortcuts

Rules Determining the Installation of Shortcuts into RTM


Although it was already mentioned in the RSVP-TE LSP shortcut for IGP route resolution section,
the rules determining how shortcuts are installed into RTM are (sorted by higher priority):
1. RSVP shortcut
2. LDP shortcut
3. IGP route with regular IP next-hop.
The implementation is compliant with the RFC3906 Calculating Interior Gateway Protocol (IGP)
Routes.
To check the rules, the network configuration is iLDP in all interfaces with LDP shortcuts enabled,
there is also an RSVP LSP from PE-6 to PE-3 available but RSVP shortcuts are disabled. The
topology is shown in Figure 42.

Lb: 172.16.2.1/32
Sys: 192.0.2.2/32

.2

PE-2

.1

192.168.12.0/30

Lb: 172.16.1.1/32
Sys: 192.0.2.1/32

.1

1/1/1:1

.1
1/1/2:1

1/1/2:1

PE-1

.2

192.168.23.0/30
.1

1/1/1:1

.2

.2

192.168.13.0/30
.2

.1

PE-3

1/1/4:1

.2

PE-5

PE-6

Sys: 192.0.2.6/32
Lb: 172.16.6.1/32

.2
1/1/4:1
192.168.56.0/30
1/1/1:1
.1

192.168.35.0/30
Lb: 172.16.3.1/32
Sys: 192.0.2.3/32

Lb: 172.16.5.1/32
Sys: 192.0.2.5/32
OSSG665

Figure 42: Network Topology to Verify Installation of Shortcuts into RTM

Displaying relevant information in PE-6, the routes are:


*A:PE-6>config>router# show router route-table
===============================================================================
Route Table (Router: Base)
===============================================================================

Advanced Configuration Guide

Page 815

Configuration

Dest Prefix
Type
Proto
Age
Pref
Next Hop[Interface Name]
Metric
------------------------------------------------------------------------------172.16.6.1/32
Local
Local
01d16h00m
0
loopback
0
192.0.2.1/32
Remote LDP
00h00m11s
9
192.168.56.1 (tunneled)
30
192.0.2.2/32
Remote LDP
00h00m11s
9
192.168.56.1 (tunneled)
30
192.0.2.3/32
Remote LDP
00h00m11s
9
192.168.56.1 (tunneled)
20
192.0.2.5/32
Remote LDP
00h23m35s
9
192.168.56.1 (tunneled)
10
192.0.2.6/32
Local
Local
08d16h32m
0
system
0
192.168.12.0/30
Remote ISIS
00h00m11s
15
192.168.56.1
40
192.168.13.0/30
Remote ISIS
00h00m11s
15
192.168.56.1
30
192.168.23.0/30
Remote ISIS
00h00m11s
15
192.168.56.1
30
192.168.35.0/30
Remote ISIS
18h16m26s
15
192.168.56.1
20
192.168.56.0/30
Local
Local
08d16h31m
0
int-PE-6-PE-5
0
------------------------------------------------------------------------------No. of Routes: 11
===============================================================================

And the tunnel table shows the LSPs available for the shortcuts, and hence used in the GRT for
LDP (but not for RSVP):
*A:PE-6>config>router# show router tunnel-table
===============================================================================
Tunnel Table (Router: Base)
===============================================================================
Destination
Owner Encap TunnelId Pref
Nexthop
Metric
------------------------------------------------------------------------------192.0.2.1/32
ldp
MPLS
9
192.168.56.1
30
192.0.2.2/32
ldp
MPLS
9
192.168.56.1
30
192.0.2.3/32
rsvp MPLS 2
7
192.168.56.1
20
192.0.2.3/32
ldp
MPLS
9
192.168.56.1
20
192.0.2.5/32
ldp
MPLS
9
192.168.56.1
10
===============================================================================

So far, LDP shortcuts are preferred over IGP next-hops for system addresses (router-id). After
enabling RSVP shortcuts under ISIS context (config>router>isis>rsvp-shortcut), the changes in
the GRT are:
*A:PE-6>config>router# show router route-table next-hop-type tunneled
===============================================================================
Route Table (Router: Base)
===============================================================================

Page 816

Advanced Configuration Guide

Full IGP Shortcuts

Dest Prefix
Type
Proto
Age
Pref
Next Hop[Interface Name]
Metric
------------------------------------------------------------------------------192.0.2.1/32
Remote IS-IS
00h00m03s
15
192.0.2.3 (tunneled:RSVP:2)
30
192.0.2.2/32
Remote ISIS
00h00m03s
15
192.0.2.3 (tunneled:RSVP:2)
30
192.0.2.3/32
Remote ISIS
00h00m03s
15
192.0.2.3 (tunneled:RSVP:2)
20
192.0.2.5/32
Remote LDP
00h25m35s
9
192.168.56.1 (tunneled)
10
192.168.12.0/30
Remote ISIS
00h00m03s
15
192.0.2.3 (tunneled:RSVP:2)
40
192.168.13.0/30
Remote ISIS
00h00m03s
15
192.0.2.3 (tunneled:RSVP:2)
30
192.168.23.0/30
Remote ISIS
00h00m03s
15
192.0.2.3 (tunneled:RSVP:2)
30
------------------------------------------------------------------------------No. of Routes: 7
===============================================================================

The GRT shows that PE-6 is using a LDP shortcut to reach PE-5, but is using the RSVP shortcut to
reach not only PE-3 system address, but also PE-1 and PE-2 routes (including all interfaces) which
were behind the RSVP LSP shortcut.
In summary, the behavior is:

When resolving a prefix, SPF picks the RSVP shortcut next-hop if there is an RSVP LSP
directly to that address regardless of the path cost compared to the IGP next-hop. If
multiple RSVP LSPs to that address exist and all have the same lowest metric, ECMP is
performed over the LSP shortcut paths.

SPF also picks the RSVP LSP shortcut if both the LSP path and the IGP path to the prefix
are via the tail-end of LSP. This is regardless of the path cost compared to the IGP nexthop. If paths over multiple RSVP shortcuts have the same lowest cost, ECMP is
performed over all of them up to the maximum ECMP paths configured on the node.

Advanced Configuration Guide

Page 817

Configuration

LDP/RSVP LSP Shortcut for BGP NH Resolution


LDP/RSVP LSP shortcut for BGP NH resolution allows forwarding of IPv4 packets to routes
resolved via a BGP next-hop using an LDP/RSVP LSP instead of using a regular IP next-hop. In
the network topology of Figure 40 on page 793, two BGP peers are configured on PE-3 and PE-6,
initially without any shortcuts enabled under bgp context. Also, one static route is configured in
each PE, that will be redistributed into BGP. The relevant configuration on PE-3 is the following:
*A:PE-3#config router
interface "static-route"
address 172.16.33.1/30
port 1/1/3:33
exit
autonomous-system 65536
static-route 10.10.10.0/24 next-hop 172.16.33.2
policy-options
begin
policy-statement "static-routes"
description "export static-routes for I-BGP"
entry 10
from
protocol static
exit
to
protocol bgp
exit
action accept
next-hop-self
exit
exit
exit
commit
exit
bgp
export "static-routes"
group "ibgp"
type internal
neighbor 192.0.2.6
exit
exit
exit

Page 818

Advanced Configuration Guide

Full IGP Shortcuts

Checking the static route received on PE-6 via BGP, the next-hop is PE-3 system address:
*A:PE-6>config>router# show router bgp routes 10.10.10.0/24 detail
===============================================================================
BGP Router ID:192.0.2.6
AS:65000
Local AS:65536
===============================================================================
Legend Status codes : u - used, s - suppressed, h - history, d - decayed, * - valid
Origin codes : i - IGP, e - EGP, ? - incomplete, > - best
===============================================================================
BGP IPv4 Routes
===============================================================================
------------------------------------------------------------------------------Original Attributes
Network
Nexthop
From
Res. Nexthop
Local Pref.
Aggregator AS
Atomic Aggr.
Community
Cluster
Originator Id
Flags
AS-Path

:
:
:
:
:
:
:
:
:
:
:
:

10.10.10.0/24
192.0.2.3
192.0.2.3
192.0.2.3
100
Interface Name
None
Aggregator
Not Atomic
MED
No Community Members
No Cluster Members
None
Peer Router Id
Used Valid Best Incomplete
No As-Path

: int-PE-6-PE-5
: None
: None

: 192.0.2.3

Modified Attributes
Network
Nexthop
From
Res. Nexthop
Local Pref.
Aggregator AS
Atomic Aggr.
Community
Cluster
Originator Id
Flags
AS-Path

:
:
:
:
:
:
:
:
:
:
:
:

10.10.10.0/24
192.0.2.3
192.0.2.3
192.0.2.3
100
Interface Name
None
Aggregator
Not Atomic
MED
No Community Members
No Cluster Members
None
Peer Router Id
Used Valid Best Incomplete
No As-Path

: int-PE-6-PE-5
: None
: None

: 192.0.2.3

------------------------------------------------------------------------------------------------------------------------------------------------------------Routes : 1

Advanced Configuration Guide

Page 819

Configuration

The BGP peering configuration possibilities are LDP, RSVP, or MPLS (it chooses RSVP if
available, if not LDP), and also disabling of IGP is allowed (meaning that unless there is a
shortcut, the BGP peering will not fall back to IGP):
*A:PE-6>config>router>bgp# igp-shortcut
- igp-shortcut {ldp|rsvp-te|mpls} [disallow-igp]
- no igp-shortcut
<ldp|rsvp-te|mpls>
<disallow-igp>

: keywords
: keyword

When enabling LDP shortcuts (config>router>bgp>igp-shortcut ldp) on PE-6, the output


changes showing the detail of the received BGP route:
*A:PE-6>config>router# show router bgp routes ipv4 detail
===============================================================================
BGP Router ID:192.0.2.6
AS:65000
Local AS:65536
===============================================================================
Legend Status codes : u - used, s - suppressed, h - history, d - decayed, * - valid
Origin codes : i - IGP, e - EGP, ? - incomplete, > - best
===============================================================================
BGP IPv4 Routes
===============================================================================
------------------------------------------------------------------------------Original Attributes
Network
Nexthop
From
Res. Nexthop
Local Pref.
Aggregator AS
Atomic Aggr.
Community
Cluster
Originator Id
Flags
AS-Path

:
:
:
:
:
:
:
:
:
:
:
:

10.10.10.0/24
192.0.2.3
192.0.2.3
192.168.56.1 (LDP)
100
Interface Name
None
Aggregator
Not Atomic
MED
No Community Members
No Cluster Members
None
Peer Router Id
Used Valid Best Incomplete
No As-Path

: int-PE-6-PE-5
: None
: None

: 192.0.2.3

Modified Attributes
Network
: 10.10.10.0/24
Nexthop
: 192.0.2.3
From
: 192.0.2.3
Res. Nexthop
: 192.168.56.1 (LDP)
Local Pref.
: 100
Interface Name : int-PE-6-PE-5
Aggregator AS : None
Aggregator
: None
Atomic Aggr.
: Not Atomic
MED
: None
Community
: No Community Members
Cluster
: No Cluster Members
Originator Id : None
Peer Router Id : 192.0.2.3
Flags
: Used Valid Best Incomplete
AS-Path
: No As-Path
------------------------------------------------------------------------------Routes : 1

Page 820

Advanced Configuration Guide

Full IGP Shortcuts

The command displays the next hop resolution using LDP, as well as the GRT output command:
*A:PE-6# show router route-table next-hop-type tunneled
===============================================================================
Route Table (Router: Base)
===============================================================================
Dest Prefix
Type
Proto
Age
Pref
Next Hop[Interface Name]
Metric
------------------------------------------------------------------------------10.10.10.0/24
Remote BGP
00h07m51s
170
192.0.2.3 (tunneled)
0
------------------------------------------------------------------------------No. of Routes: 1
===============================================================================

The following example shows the output if an RSVP LSP was enabled from PE-6 to PE-3:
*A:PE-6#config router mpls
---------------------------------------------no shortcut-local-ttl-propagate
no shortcut-transit-ttl-propagate
interface "system"
exit
interface "int-PE-6-PE-5"
exit
interface "int-PE-6-PE-4"
exit
path "p"
no shutdown
exit
lsp "LSP-PE-6-PE-3"
to 192.0.2.3
cspf
primary "p"
exit
no shutdown
exit
no shutdown

After the LSP LSP-PE-6-PE-3 is up and running:


*A:PE-6>config>router# show router mpls lsp "LSP-PE-6-PE-3" path detail
LSP LSP-PE-6-PE-3 Path p
------------------------------------------------------------------------------LSP Name
: LSP-PE-6-PE-3
Path LSP ID : 49190
From
: 192.0.2.6
To
: 192.0.2.3
Adm State
: Up
Oper State : Up
Path Name
: p
Path Type
: Primary
Path Admin : Up
Path Oper
: Up
OutInterface: 1/1/4:1
Out Label
: 131067
Path Up Time: 0d 00:03:32
Path Dn Time: 0d 00:00:00
Retry Limit : 0
Retry Timer : 30 sec
RetryAttempt: 0
NextRetryIn : 0 sec
SetupPriori*: 7
Hold Priori*: 0
Preference : n/a
Bandwidth
: No Reservation
Oper Bw
: 0 Mbps

Advanced Configuration Guide

Page 821

Configuration

Hop Limit
: 255
Backup CT
: None
MainCT Retry: n/a
Rem
:
Oper CT
: 0
Record Route: Record
Oper MTU
: 9194
Adaptive
: Enabled
Include Grps:
None
Path Trans : 39
Failure Code: noError
ExplicitHops:
No Hops Specified
Actual Hops :
192.168.56.2(192.0.2.6)
-> 192.168.56.1(192.0.2.5)
-> 192.168.35.1(192.0.2.3)
ComputedHops:
192.168.56.2
-> 192.168.56.1
ResigEligib*: False
LastResignal: n/a

Class Type

: 0

MainCT Retry: 0
Limit
:
Record Label:
Neg MTU
:
Oper Metric :
Exclude Grps:
None
CSPF Queries:
Failure Node:

Record
9194
20

3
n/a

Record Label
Record Label
Record Label

: N/A
: 131067
: 131070

-> 192.168.35.1
CSPF Metric : 20

And when config>router>bgp>igp-shortcut mpls is enabled, the display shows that the BGP
peer is reached using an RSVP LSP (switched from LDP to RSVP since RSVP is preferred):
*A:PE-6>config>router>bgp# show router route-table next-hop-type tunneled
===============================================================================
Route Table (Router: Base)
===============================================================================
Dest Prefix
Type
Proto
Age
Pref
Next Hop[Interface Name]
Metric
------------------------------------------------------------------------------10.10.10.0/24
Remote BGP
00h00m10s
170
192.0.2.3 (tunneled:RSVP:2)
0
------------------------------------------------------------------------------No. of Routes: 1
===============================================================================

If the RSVP LSP goes down (*A:PE-6>config>router# mpls lsp "lsp-pe-6-pe-3" shutdown)
with config>router>bgp>igp-shortcut mpls enabled, it reverts back to LDP:
*A:PE-6# show router bgp routes 10.10.10.0/24 detail
===============================================================================
BGP Router ID:192.0.2.6
AS:65000
Local AS:65536
===============================================================================
Legend Status codes : u - used, s - suppressed, h - history, d - decayed, * - valid
Origin codes : i - IGP, e - EGP, ? - incomplete, > - best
===============================================================================
BGP IPv4 Routes
===============================================================================
------------------------------------------------------------------------------Original Attributes

Page 822

Advanced Configuration Guide

Full IGP Shortcuts

Network
Nexthop
From
Res. Nexthop
Local Pref.
Aggregator AS
Atomic Aggr.
Community
Cluster
Originator Id
Flags
AS-Path

:
:
:
:
:
:
:
:
:
:
:
:

10.10.10.0/24
192.0.2.3
192.0.2.3
192.168.56.1 (LDP)
100
Interface Name
None
Aggregator
Not Atomic
MED
No Community Members
No Cluster Members
None
Peer Router Id
Used Valid Best Incomplete
No As-Path

: int-PE-6-PE-5
: None
: None

: 192.0.2.3

Modified Attributes
Network
Nexthop
From
Res. Nexthop
Local Pref.
Aggregator AS
Atomic Aggr.
Community
Cluster
Originator Id
Flags
AS-Path

:
:
:
:
:
:
:
:
:
:
:
:

10.10.10.0/24
192.0.2.3
192.0.2.3
192.168.56.1 (LDP)
100
Interface Name
None
Aggregator
Not Atomic
MED
No Community Members
No Cluster Members
None
Peer Router Id
Used Valid Best Incomplete
No As-Path

: int-PE-6-PE-5
: None
: None

: 192.0.2.3

------------------------------------------------------------------------------------------------------------------------------------------------------------Routes : 1

If the config is using config>router>bgp>igp-shortcut>mplsvdisallow-igp, if neither LDP nor


RSVP LSPs are available, the remote route received with BGP is removed from the GRT although
the BGP peer session remains up, so a detail in the BGP route indicates that the next hop is
Unresolved:
*A:PE-6# show router bgp routes 10.10.10.0/24 detail
===============================================================================
BGP Router ID:192.0.2.6
AS:65000
Local AS:65536
===============================================================================
Legend Status codes : u - used, s - suppressed, h - history, d - decayed, * - valid
Origin codes : i - IGP, e - EGP, ? - incomplete, > - best
===============================================================================
BGP IPv4 Routes
===============================================================================
------------------------------------------------------------------------------Original Attributes
Network
Nexthop
From
Res. Nexthop
Local Pref.
Aggregator AS

:
:
:
:
:
:

10.10.10.0/24
192.0.2.3
192.0.2.3
Unresolved
100
None

Advanced Configuration Guide

Interface Name : int-PE-6-PE-5


Aggregator
: None

Page 823

Configuration

Atomic Aggr.
Community
Cluster
Originator Id
Flags
AS-Path

:
:
:
:
:
:

Not Atomic
MED
: None
No Community Members
No Cluster Members
None
Peer Router Id : 192.0.2.3
Invalid Incomplete Nexthop-Unresolved
No As-Path

Modified Attributes
Network
Nexthop
From
Res. Nexthop
Local Pref.
Aggregator AS
Atomic Aggr.
Community
Cluster
Originator Id
Flags
AS-Path

:
:
:
:
:
:
:
:
:
:
:
:

10.10.10.0/24
192.0.2.3
192.0.2.3
Unresolved
100
Interface Name :
None
Aggregator
:
Not Atomic
MED
:
No Community Members
No Cluster Members
None
Peer Router Id :
Invalid Incomplete Nexthop-Unresolved
No As-Path

int-PE-6-PE-5
None
None

192.0.2.3

------------------------------------------------------------------------------------------------------------------------------------------------------------Routes : 1

Because the route is Unresolved, it does not appear in the GRT:


*A:PE-6# show router route-table
===============================================================================
Route Table (Router: Base)
===============================================================================
Dest Prefix
Type
Proto
Age
Pref
Next Hop[Interface Name]
Metric
------------------------------------------------------------------------------20.20.20.0/24
Remote Static
03d06h45m
5
172.16.66.2
1
172.16.6.1/32
Local
Local
05d00h03m
0
loopback
0
172.16.66.0/30
Local
Local
03d06h45m
0
static-route
0
192.0.2.1/32
Remote ISIS
03d06h34m
15
192.168.56.1
30
192.0.2.2/32
Remote ISIS
03d07h52m
15
192.168.46.1
20
192.0.2.3/32
Remote ISIS
03d06h34m
15
192.168.56.1
20
192.0.2.4/32
Remote ISIS
03d07h53m
15
192.168.46.1
10
192.0.2.5/32
Remote ISIS
04d02h20m
15
192.168.56.1
10
192.0.2.6/32
Local
Local
12d00h36m
0
system
0
192.168.12.0/30
Remote ISIS
03d07h52m
15
192.168.46.1
30
192.168.13.0/30
Remote ISIS
03d06h34m
15
192.168.56.1
30
192.168.23.0/30
Remote ISIS
03d07h52m
15

Page 824

Advanced Configuration Guide

Full IGP Shortcuts

192.168.46.1
30
192.168.24.0/30
Remote ISIS
03d07h53m
15
192.168.46.1
20
192.168.35.0/30
Remote ISIS
04d02h20m
15
192.168.56.1
20
192.168.45.0/30
Remote ISIS
03d07h53m
15
192.168.46.1
20
192.168.46.0/30
Local
Local
03d07h54m
0
int-PE-6-PE-4
0
192.168.56.0/30
Local
Local
12d00h35m
0
int-PE-6-PE-5
0
------------------------------------------------------------------------------No. of Routes: 17

Advanced Configuration Guide

Page 825

Configuration

LDP/RSVP-TE LSP Shortcut for BGP NH Resolution Within a VRF


LDP/RSVP LSP shortcut for BGP NH resolution within a VPRN (Virtual Private Routed
Network), also known as auto-bind, allows a VPRN service to automatically resolve the BGP
next-hop, for VPRN routes, to a GRE or MPLS LSP. Having said that, there are three possible
mechanisms to provide transport tunnels for the forwarding of traffic between PE routers within a
RFC 4364, BGP/MPLS IP Virtual Private Networks (VPNs), network, which are:

RSVP-TE protocol to create tunnel LSPs between PE routers

LDP protocol to create tunnel LSP's between PE routers

GRE tunnels between PE routers

These transport tunneling mechanisms provide the flexibility of using dynamically created LSPs
where the service tunnels are automatically bound (the auto-bind feature), and the ability to
provide certain VPN services with their own transport tunnels by explicitly binding SDPs if
desired. When the auto-bind is used, all services among PEs traverse the same LSPs and do not
allow alternate tunneling mechanisms (like GRE) or the ability to craft sets of LSP's with
bandwidth reservations for specific customers as is available with explicit SDPs for the service.
The configuration is:
A:PE>config>service>vprn# auto-bind
- auto-bind {ldp|gre|rsvp-te|mpls}
- no auto-bind
<ldp|gre|rsvp-te|m*> : keywords

Parameter Descriptions:
ldp Specifies LDP based LSPs should be used to resolve the BGP next-hop for VPRN routes in
an associated VPRN instance.
gre Specifies GRE to be used to resolve the BGP next-hop for VPRN routes in an associated
VPRN instance. GRE is out of the scope regarding shortcuts, so please refer to 7750/7710
documentation for further details.
rsvp-te Specifies RSVP-TE LSPs should be used to resolve the BGP next-hop for VPRN
routes in an associated VPRN instance.
mpls Chooses an existing RSVP-TE LSP if available, otherwise use LDP
In all cases, if an explicit spoke-sdp is specified in the VPRN, it is always preferred over
automatically selected tunnels (even if the SDP is down -the route becomes inactive- there is no
fallback to the automatic selection).

Page 826

Advanced Configuration Guide

Full IGP Shortcuts

The network is configured according to the topology shown in Figure 6. Four PEs (PE-1, PE-2,
PE-4 and PE-5) are connected forming a meshed IPVPN (named VPRN 1) with autobind-mpls,
using a route reflector on PE-3 for MPBGP peering. All PE-s have LDP tunnels enabled so as a
minimum all can establish LDP shortcut tunnels among themselves. In order to have not only LDP
but also RSVP-TE LSPs and static SDPs (using an RSVP LSP) in the network, a mix of tunneling
methods is configured. For the sake of simplicity, a closer view on PE-2 only, provides all details
about the shortcuts created by auto-bind. PE-2 has a static SDP (RSVP based) with PE-1, an
RSVP LSP with PE-4, and an LDP LSP with PE-5. Every PE have a CE connected, so each PE
has an interface connected to the CE and a static route to a CE LAN (although redistribution
routing policies are needed, they are not shown for simplicity).
172.16.22.0/24

172.16.44.0/24

CE-2

CE-4
.2
172.16.2.0/32
.1

.2
172.16.4.0/32
.1
Sys: 192.0.2.4/32

Sys: 192.0.2.2/32

RSVP

VPRN1
.2

VPRN1

192.168.24.0/30
.1
.2

SDP

.1

PE-2
.1
172.16.11.0/24

172.16.1.0/24

VPRN1

1/1/1:1

.1

.1

LDP

192.168.12.0/30

CE-1

Sys: 192.0.2.6/32
.2

MPBGP
192.168.45.0/30

MPBGP
.2

192.168.46.0/30

PE-4

192.168.23.0/30

.1
MPBGP

PE-1
Sys: 192.0.2.1/32

.2

.1

192.168.13.0/30

RR
.2

.2

.2

192.168.56.0/30

MPBGP
.1

.2

VPRN1
.1

192.168.35.0/30
Sys: 192.0.2.3/32

PE-6

PE-3

PE-5

Sys: 192.0.2.5/32

.1
172.16.5.0/24
.2

CE-5

172.16.55.0/24
OSSG627

Figure 43: Shortcuts Within a VRF Topology Network

Advanced Configuration Guide

Page 827

Configuration

On PE-2, the following output shows the configuration of VPRN1:


A:PE-2#config service vprn 1 customer 1 create
vrf-import "VPN1-import"
vrf-export "VPN1-export"
route-distinguisher 65002:1
auto-bind mpls
interface "to-ce2" create
address 172.16.2.1/24
sap 1/1/3:1 create
exit
exit
static-route 172.16.22.0/24 next-hop 172.16.2.2
spoke-sdp 1 create
exit
no shutdown

As previously mentioned, regarding IPVPN meshed connectivity, the configuration shows that
there is a static SDP 1 (pointing to PE-1), and the rest of the configuration is just auto-bind mpls.
On PE-2, checking the GRT, the connectivity towards the other PEs in the network can be verified:
A:PE-2# show router 1 route-table
===============================================================================
Route Table (Service: 1)
===============================================================================
Dest Prefix
Type
Proto
Age
Pref
Next Hop[Interface Name]
Metric
------------------------------------------------------------------------------172.16.1.0/24
Remote BGP VPN 19h23m31s
170
192.0.2.1 (tunneled)
0
172.16.2.0/24
Local
Local
22h15m20s
0
to-ce2
0
172.16.4.0/24
Remote BGP VPN 19h18m08s
170
192.0.2.4 (tunneled:RSVP:5)
0
172.16.5.0/24
Remote BGP VPN 19h34m31s
170
192.0.2.5 (tunneled)
0
172.16.11.0/24
Remote BGP VPN 19h23m31s
170
192.0.2.1 (tunneled)
0
172.16.22.0/24
Remote Static
22h15m20s
5
172.16.2.2
1
172.16.44.0/24
Remote BGP VPN 19h18m08s
170
192.0.2.4 (tunneled:RSVP:5)
0
172.16.55.0/24
Remote BGP VPN 19h34m31s
170
192.0.2.5 (tunneled)
0
------------------------------------------------------------------------------No. of Routes: 8

Page 828

Advanced Configuration Guide

Full IGP Shortcuts

Observe that there are eight routes since every PE has two routes (one direct interface and a static
route), so six routes are received from other PEs via MPBGP. The GRT can be understood by
looking at the tunnel table (active LSPs for remote system-ids):
A:PE-2# show router tunnel-table
===============================================================================
Tunnel Table (Router: Base)
===============================================================================
Destination
Owner Encap TunnelId Pref
Nexthop
Metric
------------------------------------------------------------------------------192.0.2.1/32
sdp
MPLS 1
5
192.0.2.1
0
192.0.2.1/32
rsvp MPLS 3
7
192.168.12.1
10
192.0.2.1/32
ldp
MPLS
9
192.168.12.1
10
192.0.2.3/32
ldp
MPLS
9
192.168.23.2
10
192.0.2.4/32
rsvp MPLS 5
7
192.168.24.2
10
192.0.2.4/32
ldp
MPLS
9
192.168.24.2
10
192.0.2.5/32
ldp
MPLS
9
192.168.23.2
20
192.0.2.6/32
ldp
MPLS
9
192.168.24.2
20

In the tunnel-table show command, it can be seen that there is an entry per LSP per remote PE.
PE-2 has three possibilities to reach PE-1 (192.0.2.1): an SDP Tunnel ID 1 with preference 5, an
RSVP Tunnel ID 3 with preference 7, and an LDP LSP with preference 9; because SDP Tunnel ID
1 has the lowest preference, it is the chosen option. PE-2 has two possibilities to reach PE-4
(192.0.2.4): an RSVP Tunnel ID 5 with preference 7 and an LDP LSP with preference 9; hence
RSVP is preferred over LDP. PE-2 only has one option to reach PE-5 (192.0.2.5) using an LDP
LSP. Note how Preference and Metric are used for best tunnel selection:

SDP has lowest (best) preference, followed by RSVP then by LDP

If preference is the same, lowest metric is selected (ECMP is possible with LDP)

Because the GRT output did not show the details of the tunneling, displaying the FIB on router
VPRN 1 provides clearer information:
A:PE-2# show router 1 fib 1
===============================================================================
FIB Display
===============================================================================
Prefix
Protocol
NextHop
------------------------------------------------------------------------------172.16.1.0/24
BGP_VPN
192.0.2.1 (VPRN Label:131064 Transport:SDP:1)
172.16.2.0/24
LOCAL
172.16.2.0 (to-ce2)
172.16.4.0/24
BGP_VPN
192.0.2.4 (VPRN Label:131065 Transport:RSVP LSP:5)
172.16.5.0/24
BGP_VPN
192.0.2.5 (VPRN Label:131062 Transport:LDP)
172.16.11.0/24
BGP_VPN
192.0.2.1 (VPRN Label:131064 Transport:SDP:1)
172.16.22.0/24
STATIC
172.16.2.2 (to-ce2)
172.16.44.0/24
BGP_VPN

Advanced Configuration Guide

Page 829

Configuration

192.0.2.4 (VPRN Label:131065 Transport:RSVP LSP:5)


172.16.55.0/24
BGP_VPN
192.0.2.5 (VPRN Label:131062 Transport:LDP)
------------------------------------------------------------------------------Total Entries : 8
-------------------------------------------------------------------------------

The FIB shows the chosen transport tunneling, specifying SDP ID, RSVP Tunnel ID, and LDP. As
already mentioned, the FIB shows that to reach PE-1, PE-2 uses SDP 1 (via a explicitly configured
SDP); to reach PE-4, it uses RSVP Tunnel 5 (bound using auto-bind mpls, because there is an
RSVP LSP available and RSVP is preferred versus LDP); and finally, to reach PE-5, it uses LDP
(bound using auto-bind mpls, no Tunnel ID in LDP).
As static SDP tunnels are preferred over dynamic tunnels (RSVP or LDP auto-bind), when the
static SDP 1 goes down with config>service>sdp 1>shutdown (there is no fallback to dynamic
tunneling), the routes associated are removed from the active ones:
*A:PE-2# show router 1 fib 1
===============================================================================
FIB Display
===============================================================================
Prefix
Protocol
NextHop
------------------------------------------------------------------------------172.16.2.0/24
LOCAL
172.16.2.0 (to-ce2)
172.16.4.0/24
BGP_VPN
192.0.2.4 (VPRN Label:131065 Transport:RSVP LSP:5)
172.16.5.0/24
BGP_VPN
192.0.2.5 (VPRN Label:131062 Transport:LDP)
172.16.22.0/24
STATIC
172.16.2.2 (to-ce2)
172.16.44.0/24
BGP_VPN
192.0.2.4 (VPRN Label:131065 Transport:RSVP LSP:5)
172.16.55.0/24
BGP_VPN
192.0.2.5 (VPRN Label:131062 Transport:LDP)
------------------------------------------------------------------------------Total Entries : 6
-------------------------------------------------------------------------------

Page 830

Advanced Configuration Guide

Full IGP Shortcuts

Conclusion
Full IGP shortcuts set of features allows a complete variety of shortcuts in IP, MPLS and IPVPN
scenarios to customers who want use new options for building routing topologies. Because IGP
shortcuts are enabled on a per router basis, SPF computations are independent and irrelevant to
other routers, so there is no need to enable shortcuts globally. This network example shows the
configuration of full IGP shortcuts together with the associated show output which can be used for
verification and troubleshooting.

Advanced Configuration Guide

Page 831

Conclusion

Page 832

Advanced Configuration Guide

G.8032 Ethernet Ring Protection


Single Ring Topology

In This Chapter
This section describes advanced G.8032 Ethernet ring protection single ring topology
configurations.
Topics in this section include:

Applicability on page 834

Overview on page 835

Configuration on page 838

Conclusion on page 855

Advanced Configuration Guide

Page 833

Applicability

Applicability
This example is applicable to 7750 SR-7/12 and 7450 ESS-7/12 with IOM3-XP or IMM but is not
supported in 7750 SR-1, 7450 ESS-1, 7710 SR, 7750-c4/12 or IOM-2 or lower.
The configuration was tested on release 8.0R7 which covers a single ring topology case only.

Page 834

Advanced Configuration Guide

G.8032 Ethernet Ring Protection Single Ring Topology

Overview
G.8032 Ethernet ring protection is supported for SAPs within a PBB VPLS (I/B-component), a
routed VPLS (R-VPLS) or a normal VPLS service.
ITU-T G.8032 specifies protection switching mechanisms and protocol for Ethernet layer network
(ETH) Ethernet rings. Ethernet rings can provide wide-area multipoint connectivity more
economically due to their reduced number of links. The mechanisms and protocol defined in ITUT G.8032 achieve highly reliable and stable protection and never form loops, which would
negatively affect network operation and service availability. Each ring node is connected to
adjacent nodes participating in the same ring using two independent links. A ring link is bounded
by two adjacent nodes and a port for a ring link is called a ring port. The minimum number of
nodes on a ring is two.
The fundamentals of this ring protection switching architecture are:

The principle of loop avoidance and

The utilization of learning, forwarding, and address table mechanisms defined in the
Ethernet flow forwarding function (ETH_FF) (control plane).

Loop avoidance in the ring is achieved by guaranteeing that, at any time, traffic may flow on all
but one of the ring links. This particular link is called the Ring Protection Link (RPL) and under
normal conditions this link is blocked, not used for traffic. One designated node, the RPL owner, is
responsible to block traffic over the RPL. Under a ring failure condition, the RPL owner is
responsible to unblock the RPL, allowing the RPL to be used for traffic. The protocol ensures that
even without an RPL owner defined, one link will be blocked. The event of a ring failure results in
protection switching of the traffic. This is achieved under the control of the ETH_FF functions on
all ring nodes. A Ring Automatic Protection Switching (R-APS) protocol is used to coordinate the
protection actions over the ring. The protection switching mechanisms and protocol supports a
multi-ring/ladder network that consists of connected Ethernet rings, however, multi-ring/ladder
networks are not supported in the tested version of the software.

Advanced Configuration Guide

Page 835

Overview

Ring Protection Mechanism

Ring status change on failure


Idle -> link failure -> protection ->recovery -> idle

Re-use existing ETH OAM


Monitoring: ETH Continuity Check messages
Failure Notification: Y.1731 Signal Failure

Forwarding database MAC flush on ring status change

RPL (Ring Protection Link)


Defines blocked link in idle status

Figure 44 shows a ring of six nodes, with the RPL owner on the top right. One link of the RPL
owner is designated to be the RPL and will be blocked in order to prevent a loop. Schematics of
the physical and logical topologies are also shown.
When an RPL owner and RPL end are configured, the associated link will be the RPL when the
ring is fully operational and so be blocked by the RPL owner. If a different ring link fails then the
RPL will be unblocked by the RPL owner. When the failed link recovers, it will initially be
blocked by one of its adjacent nodes. The adjacent node sends an R-APS message across the ring
to indicate the error is cleared and after a configurable time, if reversion is enabled, the RPL will
revert to being blocked with all other links unblocked. This ensures that the ring topology when
fully operational is predictable.
If a specific RPL owner is not configured, then the last link to become active will be blocked and
the ring will remain in this state until another link fails. Clearly, this operation makes the selection
of the blocked link non-deterministic.

Page 836

Advanced Configuration Guide

G.8032 Ethernet Ring Protection Single Ring Topology

RPL End
ETH-CC

ETH-CC

ETH-CC

RPL
Owner

ETH-CC
RPL

ETH-CC

ETH-CC

ETH-CC

ETH-CC
ETH-CC

ETH-CC

ETH-CC

RPL

Physical Topology

ETH-CC

Logical Topology
OSSG619

Figure 44: G.8032 Operation and Topologies

The protection protocol uses a specific control VLAN, with the associated data VLANs taking
their forwarding state from the control VLAN.

Advanced Configuration Guide

Page 837

Configuration

Configuration
The test topology is shown in Figure 45.

Ring Node 101


4/1/12

Ring Node 102

4/1/14

(RPL Owner)

4/1/12
(RPL end)

ETH-Ring(s)

4/1/13

Tester

10/1/14

10/1/13

Ring Node 103


Control Channel: VPLS 10, Tag 1
Data Channel: VPLS 100, Tag 100
OSSG620

** Control Channel: VPLS 10, Tag 1


** Data Channel: VPLS 100, Tag 100

Figure 45: Test Topology

The Eth-Ring configuration commands are shown below.


configure eth-ring <ring-index>
ccm-hold-time {[down <down-timeout>] [up <up-timeout>]}
description <description-string>
guard-time <time>
node-id <xx:xx:xx:xx:xx:xx or xx-xx-xx-xx-xx-xx>
path {a|b} <port-id> raps-tag <qtag[.<qtag>]>
description <description-string>
eth-cfm
mep <mep-id> domain <md-index> association <ma-index>
...
rpl-end
shutdown
revert-time <time>
rpl-node {owner|nbr}
shutdown

Page 838

Advanced Configuration Guide

G.8032 Ethernet Ring Protection Single Ring Topology

Parameters:

ring-index This is the number by which the ring is referenced. The values are 1 to128.

ccm-hold-time {[down <down-timeout>] [up <up-timeout>]}


down This command specifies the timer which controls the delay between detecting
that ring path is down and reporting it to the G.8032 protection module. If a non-zero
value is configured, the CPM will wait for the time specified in the value parameter before
reporting it to the G.8032 protection module. Note that this parameter applies only to ring
path CCM. It does NOT apply to the ring port link state. To dampen ring port link state
transitions, use the hold-time parameter from the physical member port. This is useful if
the underlying path between two nodes is going across an optical system which
implements its own protection.
up This command specifies the timer which controls the delay between detecting that
ring path is up and reporting it to the G.8032 protection module. If a non-zero value is
configured, the CPM will wait for the time specified in the value parameter before
reporting it to the G.8032 protection module. Note that this parameter applies only to ring
path CCM. It does not apply to the member port link state. To dampen member port link
state transitions, use the hold-time parameter from the physical member port.
Values:
<down-timeout>:

[0..5000] in deciseconds - Default: 0

<up-timeout>:

[0..5000] in deciseconds - Default: 20

description <description-string> This configures a text string, up to 80 characters,


which can be used to describe the use of the eth-ring.

guard-time <time> The forwarding method, in which R-APS messages are copied and
forwarded at every Ethernet ring node, can result in a message corresponding to an old
request, that is no longer relevant, being received by Ethernet ring nodes. Reception of an
old R-APS message may result in erroneous ring state interpretation by some Ethernet
ring nodes. The guard timer is used to prevent Ethernet ring nodes from acting upon
outdated R-APS messages and prevents the possibility of forming a closed loop.
Messages are not forwarded when the guard-timer is running.
Values: [1..20] in deciseconds - Default: 5
1 decisecond = 100ms

node-id <xx:xx:xx:xx:xx:xx or xx-xx-xx-xx-xx-xx> This allows the node identifier to


be explicitly configured. By default the chassis MAC is used.

path {a|b} <port-id> raps-tag <qtag[.<qtag>]> This parameter defines the paths around
the ring, of which there are two in different directions on the ring: an a path and a b path.

Advanced Configuration Guide

Page 839

Configuration

In addition it configures the encapsulation used for the R-APS messages on the ring.
These can be either single or double tagged.
description <description-string> This configures a text string, up to 80 characters,
which can be used to describe the use of the path.
eth-cfm Configures the associated Ethernet CFM parameters.

mep <mep-id> domain <md-index> association <ma-index> The MEP defined


under the path is used for the G.8032 protocol messages, which are based on
IEEE 802.1ag/Y.1731 CFM frames.

rpl-end When configured, this path is expected to be one end of the RPL. This
parameter must be configured in conjunction with the rpl-node.
shutdown This command shuts down the path.

revert-time <time> This command configures the revert time for an Eth-Ring. Revert
time is the time that the RPL will wait before returning to blocked state. Configuring no
revert-time disables reversion, effectively setting it to zero.
Values: [60..720] in seconds - Default: 300

Page 840

rpl-node {owner|nbr} A node can be designated as either the owner of the RPL, in
which case this node is responsible for the RPL, or the nbr, in which case this node is
expected to be the neighbor to the RPL owner across the RPL. The nbr is optional and is
included to be compliant with the specification. This parameter must be configured in
conjunction with the rpl-node parameter.

shutdown This command shuts down the ring.

Advanced Configuration Guide

G.8032 Ethernet Ring Protection Single Ring Topology

Before you start


To configure R-APS, there should be at least 2 VPLS services for 1 Eth-Ring instance, one for the
control channel and the other (or more) for data channel(s). The control channel is used for R-APS
signaling while data channel is for user data traffic. The state of the data channels is inherited from
the state of the control channel.
Step 0:

Configuring the encapsulation for each ring port

Eth-Ring needs R-APS Tag to send/receive G.8032 signaling. To configure a control channel, an
access SAP configuration is required on each path a/b port. The SAP configuration follows that of
the port and must be either Dot1q or QinQ, consequently the control and data packets are either
single tagged or double tagged. This release does not support a single tagged control channel with
double tagged data traffic. Also, eth-ring on LAGs is not supported in this release.
In this example single tags are used so the commands for ring node 101 are
*B:101#
*B:101#
*B:101#
*B:101#

Step 1:

configure
configure
configure
configure

port
port
port
port

4/1/12
4/1/14
4/1/12
4/1/14

ethernet
ethernet
ethernet
ethernet

mode access
mode access
encap-type dot1q
encap-type dot1q

Configuring ETH-CFM

Configuring Eth-CFM domain, association and MEP is required before configuring Ethernet Ring.
The domain format should be none and association name should be icc-based (Y.1731). The
minimum CCM interval for 7750/7450 is 10ms. The eth-ring MEP requires sub-second CCM
interval (10ms or 100ms) to be configured.
Note that the MEPs used for R-APS control normally will have CCM configured on the control
channel path MEPs for failure detection. Alternatively, detecting a failure of the ring may be
achieved by running EFM at the port level if CCM is not possible at 100ms or 10ms. Loss-ofsignal, in conjunction with other OAM, is applicable only when the nodes are directly connected.
Figure 46 shows the Ethernet CFM configuration used here.

Advanced Configuration Guide

Page 841

Configuration

4/1/1

Ring Node 101

4/1/12

4/1/14

4/1/12

MEP111
ring1_101_102

MEP112

Ring Node 102


4/1/1

MEP121

ETH-Ring(s)

MEP122

4/1/13

ring1_101_103

Tester

ring1_102_103

MEP113

MEP123

10/1/14

10/1/13

Ring Node 103

10/1/1
OSSG621

Figure 46: Ethernet CFM Configuration

The configuration of each node is as follows.


Ring node 101
B:101>config>eth-cfm# info
---------------------------------------------domain 1 format none level 3
association 1 format icc-based name "ring1_101_102"
ccm-interval 10ms
remote-mepid 112
exit
association 2 format icc-based name "ring1_101_103"
ccm-interval 10ms
remote-mepid 113
exit
exit
---------------------------------------------B:101>config>eth-cfm#

Page 842

Advanced Configuration Guide

G.8032 Ethernet Ring Protection Single Ring Topology

Ring node 102


B:102>config>eth-cfm# info
---------------------------------------------domain 1 format none level 3
association 1 format icc-based name "ring1_101_102"
ccm-interval 10ms
remote-mepid 111
exit
association 2 format icc-based name "ring1_102_103"
ccm-interval 10ms
remote-mepid 123
exit
exit
---------------------------------------------B:102>config>eth-cfm#

Ring node 103


A:103>config>eth-cfm# info
---------------------------------------------domain 1 format none level 3
association 1 format icc-based name "ring1_101_103"
ccm-interval 10ms
remote-mepid 121
exit
association 2 format icc-based name "ring1_102_103"
ccm-interval 10ms
remote-mepid 122
exit
exit
---------------------------------------------A:103>config>eth-cfm#

Step 2. Configuring Eth-Ring

Two paths should be configured to form ring. In this example, VLAN tag 1 in the ring is used as
control channel for R-APS signaling.
Ring node 101
B:101>config# eth-ring 1
B:101>config>eth-ring# info
---------------------------------------------path a 4/1/12 raps-tag 1
eth-cfm
mep 111 domain 1 association 1
ccm-enable
control-mep
no shutdown
exit
exit
no shutdown

Advanced Configuration Guide

Page 843

Configuration

exit
path b 4/1/14 raps-tag 1
eth-cfm
mep 121 domain 1 association 2
ccm-enable
control-mep
no shutdown
exit
exit
no shutdown
exit
no shutdown
---------------------------------------------B:101>config>eth-ring#

It is mandatory to configure a MEP under the path otherwise this error will be displayed.
*B101>config>eth-ring>path# no shutdown
INFO: ERMGR #1001 Not permitted - must configure eth-cfm MEP first

Note that while MEPs are mandatory, enabling CCMs on the MEPs under the paths as a failure
detection mechanism is optional. To omit the failure detecting CCMs, it would be necessary to
remove the ccm-enable from under the path MEPs and to remove the remote-mepids from under
the eth-cfm associations on all nodes.
Ring node 102
B:102>config# eth-ring 1
B:102>config>eth-ring# info
---------------------------------------------revert-time 60
rpl-node owner
path a 4/1/12 raps-tag 1
rpl-end
eth-cfm
mep 112 domain 1 association 1
ccm-enable
control-mep
no shutdown
exit
exit
no shutdown
exit
path b 4/1/13 raps-tag 1
eth-cfm
mep 122 domain 1 association 2
ccm-enable
control-mep
no shutdown
exit
exit
no shutdown
exit
no shutdown

Page 844

Advanced Configuration Guide

G.8032 Ethernet Ring Protection Single Ring Topology

---------------------------------------------B:102>config>eth-ring#

In order to define the RPL, node 102 has been configured as the RPL owner and path a as the RPL
end. The link between nodes 101 and 102 will be the RPL with node 102 blocking that link when
the ring is fully operational.
It is not permitted to configure a path as an RPL end without having configured the node on this
ring to be either the RPL owner or nbr otherwise the following error message is reported.
*B:102>config>eth-ring# path a rpl-end
INFO: ERMGR #1001 Not permitted - path-type rpl-end is not consistent with eth-ring 'rplnode' type

Ring node 103


A:103>config# eth-ring 1
A:103>config>eth-ring# info
---------------------------------------------path a 10/1/14 raps-tag 1
eth-cfm
mep 113 domain 1 association 1
ccm-enable
control-mep
no shutdown
exit
exit
no shutdown
exit
path b 10/1/13 raps-tag 1
eth-cfm
mep 123 domain 1 association 2
ccm-enable
control-mep
no shutdown
exit
exit
no shutdown
exit
no shutdown
---------------------------------------------A:103>config>eth-ring#

Until you attach the Ethernet Ring instance to the service (VPLS in this case), the ring operational
status is down and all forwarding status of each port is blocked. This prevents operator from
creating a loop by mis-configuration. This state can be seen on ring node 101 as follows
*B:101# show eth-ring 1
===============================================================================
Ethernet Ring 1 Information
===============================================================================
Description
: (Not Specified)
Admin State
: Up
Oper State
: Down
Node ID
: 00:16:4d:aa:70:b6

Advanced Configuration Guide

Page 845

Configuration

Guard Time
Max Revert Time
CCM Hold Down Time
APS Tx PDU

Defect Status

:
5 deciseconds
RPL Node
: rplNone
: 300 seconds
Time to Revert
: N/A
:
0 centiseconds CCM Hold Up Time :
20 deciseconds
: Request State: 0xB
Sub-Code
: 0x0
Status
: 0x20 ( BPR )
Node ID
: 00:16:4d:aa:70:b6
:

------------------------------------------------------------------------------Ethernet Ring Path Summary


------------------------------------------------------------------------------Path Port
Raps-Tag
Admin/Oper
Type
Fwd State
------------------------------------------------------------------------------a 4/1/12
1
Up/Down
normal
blocked
b 4/1/14
1
Up/Down
normal
blocked
===============================================================================
*B:101#

Step 3. Adding Eth-Ring SAP to the control channel service

Path a and b defined in the eth-ring must be added as SAPs into a VPLS service (standard VPLS in
this example) using the eth-ring parameter. The SAP encapsulation values must match the values
of the raps-tag configured for the associated path.
G.8032 uses the same raps-tag value on all nodes on the ring, as is configured in this example.
However, the 7x50 implementation relaxes this constraint by requiring the tag to match only on
adjacent nodes.
Ring node 101
B:101>config# service vpls 10
B:101>config>service>vpls# info
---------------------------------------------stp
shutdown
exit
sap 4/1/12:1 eth-ring 1 create
stp
shutdown
exit
exit
sap 4/1/14:1 eth-ring 1 create
stp
shutdown
exit
exit
no shutdown
---------------------------------------------B:101>config>service>vpls#

Page 846

Advanced Configuration Guide

G.8032 Ethernet Ring Protection Single Ring Topology

Ring node 102


B:102>config# service vpls 10
B:102>config>service>vpls# info
---------------------------------------------stp
shutdown
exit
sap 4/1/12:1 eth-ring 1 create
stp
shutdown
exit
exit
sap 4/1/13:1 eth-ring 1 create
stp
shutdown
exit
exit
no shutdown
---------------------------------------------B:102>config>service>vpls#

Ring node 103


A:103>config# service vpls 10
A:103>config>service>vpls# info
---------------------------------------------stp
shutdown
exit
sap 10/1/13:1 eth-ring 1 create
stp
shutdown
exit
exit
sap 10/1/14:1 eth-ring 1 create
stp
shutdown
exit
exit
no shutdown
---------------------------------------------A:103>config>service>vpls#

Advanced Configuration Guide

Page 847

Configuration

Note that you cannot add a normal SAP or SDP in control channel VPLS, only SAPs with an ethring parameter can be added. Trying to add a SAP without this parameter into control channel
VPLS will result in the message below being displayed.
*B:101>config>service>vpls# sap 4/1/1:1 create
MINOR: SVCMGR #1322 Service contains an Ethernet ring control SAP

Now the Eth-Ring is operationally up and the RPL is blocking successfully on ring node 102 port
4/1/12, as expected from RPL owner/end configuration. This can be seen using the following
show commands.
An overview of all of the ring(s) can be shown using the following commands, in this case on
node 102.
First, the ETH ring status.
B:102# show eth-ring status
===============================================================================
Ethernet Ring (Status information)
===============================================================================
Ring
Admin Oper
Path Information
MEP Information
ID
State State Path
Tag
State
Ctrl-MEP CC-Intvl Defects
------------------------------------------------------------------------------1
Up
Up
a - 4/1/12
1
Up
Yes
10ms
----b - 4/1/13
1
Up
Yes
10ms
----===============================================================================
Ethernet Tunnel MEP Defect Legend:
R = Rdi, M = MacStatus, C = RemoteCCM, E = ErrorCCM, X = XconCCM
B:102#

Now, the output with the ring and path forwarding states.
B:102# show eth-ring
===============================================================================
Ethernet Rings (summary)
===============================================================================
Ring
Admin Oper
Paths Summary
Path States
ID
State State
a
b
------------------------------------------------------------------------------1
Up
Up
a - 4/1/12
1
b - 4/1/13
1
B
U
===============================================================================
Ethernet Ring Summary Legend:
B - Blocked
U - Unblocked
B:102#

Page 848

Advanced Configuration Guide

G.8032 Ethernet Ring Protection Single Ring Topology

The specific ring information on each node can be shown as follows.


Ring node 101
B:101# show eth-ring 1
===============================================================================
Ethernet Ring 1 Information
===============================================================================
Description
: (Not Specified)
Admin State
: Up
Oper State
: Up
Node ID
: 00:16:4d:aa:70:b6
Guard Time
:
5 deciseconds
RPL Node
: rplNone
Max Revert Time
: 300 seconds
Time to Revert
: N/A
CCM Hold Down Time :
0 centiseconds CCM Hold Up Time :
20 deciseconds
APS Tx PDU
: N/A
Defect Status
:
------------------------------------------------------------------------------Ethernet Ring Path Summary
------------------------------------------------------------------------------Path Port
Raps-Tag
Admin/Oper
Type
Fwd State
------------------------------------------------------------------------------a 4/1/12
1
Up/Up
normal
unblocked
b 4/1/14
1
Up/Up
normal
unblocked
===============================================================================
B:101#

Ring node 102


B:102# show eth-ring 1
===============================================================================
Ethernet Ring 1 Information
===============================================================================
Description
: (Not Specified)
Admin State
: Up
Oper State
: Up
Node ID
: 00:23:3e:7a:be:50
Guard Time
:
5 deciseconds
RPL Node
: rplOwner
Max Revert Time
:
60 seconds
Time to Revert
: N/A
CCM Hold Down Time :
0 centiseconds CCM Hold Up Time :
20 deciseconds
APS Tx PDU
: Request State: 0x0
Sub-Code
: 0x0
Status
: 0xC0 ( RB DNF )
Node ID
: 00:23:3e:7a:be:50
Defect Status
:
------------------------------------------------------------------------------Ethernet Ring Path Summary
------------------------------------------------------------------------------Path Port
Raps-Tag
Admin/Oper
Type
Fwd State
------------------------------------------------------------------------------a 4/1/12
1
Up/Up
rplEnd
blocked
b 4/1/13
1
Up/Up
normal
unblocked
===============================================================================
B:102#

Note the indication in the above that node 102 is the RPL owner and that port 4/1/12 is an RPL
end. The revert-time is also shown to be the configured value.

Advanced Configuration Guide

Page 849

Configuration

When a revert is pending, the Time to Revert will show the number of seconds remaining before
the revert occurs, as below.
B:102# show eth-ring 1
===============================================================================
Ethernet Ring 1 Information
===============================================================================
Description
: (Not Specified)
Admin State
: Up
Oper State
: Up
Node ID
: 00:23:3e:7a:be:50
Guard Time
:
5 deciseconds
RPL Node
: rplOwner
Max Revert Time
:
60 seconds
Time to Revert
:
58 seconds
CCM Hold Down Time :
0 centiseconds CCM Hold Up Time :
20 deciseconds
APS Tx PDU
: N/A
Defect Status
:
------------------------------------------------------------------------------Ethernet Ring Path Summary
------------------------------------------------------------------------------Path Port
Raps-Tag
Admin/Oper
Type
Fwd State
------------------------------------------------------------------------------a 4/1/12
1
Up/Up
rplEnd
unblocked
b 4/1/13
1
Up/Up
normal
unblocked
===============================================================================
B:102#

On reversion, the following console message is logged.


B:102#
1 2011/03/14 09:31:01.00 UTC MINOR: ERING #2001 Base eth-ring-1
"Eth-Ring 1 path 0 changed fwd state to blocked"

Ring node 103


A:103# show eth-ring 1
===============================================================================
Ethernet Ring 1 Information
===============================================================================
Description
: (Not Specified)
Admin State
: Up
Oper State
: Up
Node ID
: 00:03:fa:12:87:a7
Guard Time
:
5 deciseconds
RPL Node
: rplNone
Max Revert Time
: 300 seconds
Time to Revert
: N/A
CCM Hold Down Time :
0 centiseconds CCM Hold Up Time :
20 deciseconds
APS Tx PDU
: N/A
Defect Status
:
------------------------------------------------------------------------------Ethernet Ring Path Summary
------------------------------------------------------------------------------Path Port
Raps-Tag
Admin/Oper
Type
Fwd State
------------------------------------------------------------------------------a 10/1/14 1
Up/Up
normal
unblocked
b 10/1/13 1
Up/Up
normal
unblocked
===============================================================================
A:103#

Page 850

Advanced Configuration Guide

G.8032 Ethernet Ring Protection Single Ring Topology

Finally, the details of an individual path can be shown.


B:102# show eth-ring 1 path b
===============================================================================
Ethernet Ring 1 Path Information
===============================================================================
Description
: (Not Specified)
Port
: 4/1/13
Raps-Tag
: 1
Admin State
: Up
Oper State
: Up
Path Type
: normal
Fwd State
: unblocked
Fwd State Change : 03/14/2011 08:02:14
APS Rx PDU
: Request State: 0x0
Sub-Code
: 0x0
Status
: 0x00 ( )
Node ID
: 00:03:fa:12:87:a7
------------------------------------------------------------------------------Eth-Cfm MEP Configuration Information
------------------------------------------------------------------------------Md-index
: 1
Direction
: Down
Ma-index
: 2
Admin
: Enabled
MepId
: 122
CCM-Enable
: Enabled
LowestDefectPri
: macRemErrXcon
HighestDefect
: none
Defect Flags
: None
Mac Address
: 00:03:fa:1b:b9:96 ControlMep
: True
CcmLtmPriority
: 7
CcmTx
: 0
CcmSequenceErr
: 0
Fault Propagation : disabled
Eth-1Dm Threshold : 3(sec)
Eth-Ais:
: Disabled
Eth-Tst:
: Disabled
LbRxReply
: 0
LbRxBadOrder
: 0
LbRxBadMsdu
: 0
LbTxReply
: 0
LbNextSequence
: 1
LtNextSequence
: 1
LtRxUnexplained
: 0
===============================================================================
B:102#

Step 4. Configuring the user data channel VPLS service

The user data channels are created on a separate VPLS. Tag 100 and VPLS 100 are used here. The
ring data channels must be on the same ports as the corresponding control channels configured
above. The access into the data services can use SAPs and/or SDPs.
Ring node 101
*B:101# configure service vpls 100
*B:101>config>service>vpls# info
---------------------------------------------stp
shutdown
exit
sap 4/1/1:100 create
stp
shutdown
exit
exit

Advanced Configuration Guide

Page 851

Configuration

sap 4/1/12:100 eth-ring 1 create


stp
shutdown
exit
exit
sap 4/1/14:100 eth-ring 1 create
stp
shutdown
exit
exit
no shutdown
---------------------------------------------*B:101>config>service>vpls#

Ring node 102


B:102# configure service vpls 100
B:102>config>service>vpls# info
---------------------------------------------stp
shutdown
exit
sap 4/1/1:100 create
exit
sap 4/1/12:100 eth-ring 1 create
stp
shutdown
exit
exit
sap 4/1/13:100 eth-ring 1 create
stp
shutdown
exit
exit
no shutdown
---------------------------------------------B:102>config>service>vpls#

Ring node 103


*A:103# configure service vpls 100
*A:103>config>service>vpls# info
---------------------------------------------stp
shutdown
exit
sap 10/1/1:100 create
exit
sap 10/1/13:100 eth-ring 1 create
stp
shutdown
exit
exit
sap 10/1/14:100 eth-ring 1 create
stp
shutdown

Page 852

Advanced Configuration Guide

G.8032 Ethernet Ring Protection Single Ring Topology

exit
exit
no shutdown
---------------------------------------------*A:103>config>service>vpls#

All of the SAPs which are configured to use ETH rings can be shown, using node 101 as an
example.
B:101# show service sap-using eth-ring
===============================================================================
Service Access Points (Ethernet Ring)
===============================================================================
SapId
SvcId
Eth-Ring Path Admin Oper Blocked Control/
State State
Data
------------------------------------------------------------------------------4/1/12:1
10
1
a
Up
Up
No
Ctrl
4/1/14:1
10
1
b
Up
Up
No
Ctrl
4/1/12:100
100
1
a
Up
Up
No
Data
4/1/14:100
100
1
b
Up
Up
No
Data
------------------------------------------------------------------------------Number of SAPs : 4
===============================================================================
B:101#

To see an example of the console messages on a ring failure, when the unblocked port (4/1/13) on
node 2 is shutdown the following messages are displayed.
B:102# configure port 4/1/13 shutdown
2 2011/03/14 09:38:07.28 UTC WARNING: SNMP #2004 Base 4/1/13
"Interface 4/1/13 is not operational"
3 2011/03/14 09:38:07.28 UTC MINOR: ERING #2001 Base eth-ring-1
"Eth-Ring 1 path 1 changed fwd state to blocked"
4 2011/03/14 09:38:07.28 UTC MINOR: ERING #2001 Base eth-ring-1
"Eth-Ring 1 path 0 changed fwd state to unblocked"
5 2011/03/14 09:38:07.28 UTC WARNING: SYSTEM #2006 Base PORT
"tmnxPortTable: Port 4/1/13 configuration modified"
*B:102#
6 2011/03/14 09:38:07.29 UTC MAJOR: SVCMGR #2210 Base
"Processing of an access port state change event is finished and the status of a
ll affected SAPs on port 4/1/13 has been updated."
7 2011/03/14 09:38:07.32 UTC MINOR: ETH_CFM #2001 Base
"MEP 1/2/122 highest defect is now defRemoteCCM"
*B:102#

To help with troubleshooting, the tools dump eth-ring <ring-index> command will display path
information, the internal state of the control protocol, related statistics information and up to the

Advanced Configuration Guide

Page 853

Configuration

last 16 protocol events (including messages sent and received, and the expiration of timers). There
is an associated parameter to clear the event information in this output when the command is
entered. The following is an example of the output on node 102 with port 4/1/13 active.
B:102# tools dump eth-ring 1
ringId 1 (Up/Up): numPaths 2 nodeId 00:23:3e:7a:be:50
path-a, port 4/1/12 (Up), tag 1.0(Up) status (Up/Up/Blk)
cc: Dn/Up 3/3, time 000 00:20:35.930, fwdStateChg: 1
path-b, port 4/1/13 (Up), tag 1.0(Up) status (Up/Up/Fwd)
cc: Dn/Up 2/2, time 000 00:01:25.790, fwdStateChg: 2
FsmState= IDLE, Rpl = Owner, revert = 60 s, guard = 5 ds
Defects =
Running Timers = PduReTx
lastTxPdu = 0x00c0 Nr(RB DNF )
path-a Rpl, RxId(I)= 00:16:4d:aa:70:b6, rx(F)= 0x0020 Nr, cmd= None
path-b Normal, RxId(I)= 00:03:fa:12:87:a7, rx(F)= 0x0000 Nr, cmd= None
DebugInfo: aPathSts 1, bPathSts 1, pm - assert 0 clear 0
RxRaps: ok 5 nok 0 self 454, TmrExp - wtr 1(1), grd 1, wtb 0
Flush: cnt 3 start 000 00:20:37.100 end 000 00:20:37.100 Out 0 Ack 1
Now: 000 00:39:22.370 , softReset: No - noTx 0
Seq Event
===
000
001
002
003
004
005
006
007
008
009

RxInfo(Path: NodeId-Bytes)
state:TxInfo (Bytes)
Dir
===== ============================== =====
aAdd
PROT: 0xb000 Sf
Tx-->
bAdd
PROT: 0xb020 Sf
Tx-->
bUp
PROT: 0xb040 Sf(DNF )
Tx-->
pdu B: 00:03:fa:12:87:a7-0xb040 Sf(DNF )
PROT: 0xb040 Sf(DNF )
Rx<-pdu A: 00:16:4d:aa:70:b6-0xb020 Sf
PROT: 0xb040 Sf(DNF )
Rx<-pdu A: 00:16:4d:aa:70:b6-0xb060 Sf(DNF )
PROT: 0xb040 Sf(DNF )
Rx<-pdu B: 00:03:fa:12:87:a7-0x0000 Nr
PROT: 0xb040 Sf(DNF )
Rx<-pdu A: 00:16:4d:aa:70:b6-0x0020 Nr
PROT: 0xb040 Sf(DNF )
Rx<-aUp
PEND: 0x0000 Nr
Tx-->
xWtr
IDLE: 0x00c0 Nr(RB DNF )
Tx-->

pA pB
Time
=== === ================
Blk --- 000 00:01:24.840
Blk Blk 000 00:01:25.010
Blk Fwd 000 00:01:27.780
Blk Fwd 000 00:01:27.840
Blk Fwd 000 00:20:37.100
Blk Fwd 000 00:20:37.900
Blk Fwd 000 00:20:38.040
Blk Fwd 000 00:20:38.100
Blk Fwd 000 00:20:38.380
Blk Fwd 000 00:21:53.780

B:102#

Page 854

Advanced Configuration Guide

G.8032 Ethernet Ring Protection Single Ring Topology

Conclusion
Ethernet ring APS provides optimal solution for designing native Ethernet service with ring
topology. This protocol is becoming popular as it provides simple configuration, operation and
guaranteed fast protection time. 7x50 also has a flexible encapsulation that allows Dot1q, QinQ or
even PBB for the ring traffic. It could be utilized on various services such as mobile backhaul,
business VPN access, aggregation and core.

Advanced Configuration Guide

Page 855

Conclusion

Page 856

Advanced Configuration Guide

Ingress Multicast Path Management

In This Chapter
This section provides information about Ingress Multicast Path Management (IMPM).
Topics in this section include:

Applicability on page 858

Summary on page 859

Overview on page 860

Configuration on page 865

Conclusion on page 900

Advanced Configuration Guide

Page 857

Applicability

Applicability
The information in this section is applicable to all Alcatel-Lucent 7x50 platforms configured with
IOM1/2, IOM3-XP and IMMs line cards, but not to the SR-1, ESS-1, 7710 SR c-4/12 or the 7750
SR c-4/12. The configuration was tested on release 9.0R6. There are no pre-requisites for this
configuration.

Page 858

Advanced Configuration Guide

Ingress Multicast Path Management

Summary
Ingress Multicast Path Management (IMPM) optimizes the IPv4 and IPv6 multicast capacity on
the applicable systems with the goal of achieving the maximum system-wide IP multicast
throughput. It controls the delivery of IPv4/IPv6 routed multicast groups and of VPLS (IGMP and
PIM) snooped IPv4 multicast groups, which usually relate to the distribution of IP TV channels.
A description is also included of the use of IMPM resources by point-to-multipoint LSP IP
multicast traffic, and policed ingress routed IP multicast or VPLS broadcast, unknown or multicast
traffic. The system capacity for these traffic types can be increased even with IMPM disabled.

Advanced Configuration Guide

Page 859

Overview

Overview
IMPM introduces the concept of paths on a line card (IOM/IMM) which connect to planes on the
chassis switch fabric (Figure 47).
IMPM monitors the ingress rate of IP multicast channels (S,G1 multicast streams) on line card
paths and optimizes the use of the capacity of each switch fabric plane. Its goal is to forward as
many channels as possible through the system in order to make maximum use of the switch fabric
planes without incurring multicast packet loss. IMPM achieves this by moving entire multicast
channels between the line card paths, and therefore between switch fabric planes, to achieve an
optimal packing of channels onto path/planes. These actions take into consideration the total
ingress multicast traffic being received by all line cards with IMPM enabled and a configured
preference of each channel.

Ingress Forwarding
Complex

PATHS

Egress Forwarding
Complex

Switch Fabric
Plane

Ingress Forwarding
Complex
Plane

Egress Forwarding
Complex

PATHS

Ingress Forwarding
Complex

Plane
Egress Forwarding
Complex

PATHS

OSSG725

Figure 47: IOM/IMM Paths Connecting to Switch Fabric Planes

There are three types of path: primary, secondary and ancillary paths (the ancillary path is specific
to the IOM1/2 and is discussed in Ancillary Path on page 880).

1. S,G refers to an individual multicast stream by referencing the source (S) and multicast group (G)
used by the steam.

Page 860

Advanced Configuration Guide

Ingress Multicast Path Management

When a new channel is received on a line card for which there is an egress join, its traffic is
initially placed on to a secondary path by default. IMPM monitors the channels traffic rate and,
after an initial monitoring period, can move the channel to another path (usually a primary path)
on which sufficient capacity exists for the channel. IMPM constantly monitors all of the ingress
channels and therefore keeps a picture of the current usage of all the line card paths and switch
fabric planes. As new channels arrive, IMPM assigns them onto available capacity, which may
involve moving existing channels between paths (and planes). If a channel stops, IMPM will be
aware that more capacity is now available. If the traffic rate of any channel(s) changes, IMPM will
continue to optimize the use of the path/planes.
In the case where there is insufficient plane capacity available for all ingress channels, entire
channel(s) are blackholed (dropped) rather than allowing a random degradation across all
channels. This action is based on a configurable channel preference with the lowest preference
channel being dropped first. If path/plane capacity becomes available, then the blackholed
channel(s) can be re-instated.

Paths and Planes


Each path connects to one plane on the switch fabric which is then used to replicate multicast
traffic to the egress line cards. Further replication can occur on the egress line card but this is not
related to IMPM so is not discussed.
Each plane has a physical connection to every line card and operates in full duplex mode allowing
the possibility for traffic received on a plane from one line card path to be sent to every other line
card, and back to the ingress line card (note that traffic is actually only sent to the line cards where
it may exit). Therefore a given plane interconnects all line cards which allow ingress multipoint
traffic from a line card with a path connected to this plane to be sent to multiple egress line cards.
Traffic could be sent by only one line card, or by multiple line cards simultaneously, on to a given
plane. The total amount of traffic on a path or plane cannot exceed the capacity of that path or
plane, respectively.
There could be more planes available on the switch fabrics than paths on the line cards.
Conversely, there could be more total line card paths than planes available on the switch fabrics. In
the latter case, the system distributes the paths as equally as possible over the available planes and
multiple paths would be assigned to a given0 plane. Note that multiple paths of either type
(primary or secondary) can terminate on a given plane.
The number of paths available per line card depends on the type of line card used whereas the
number of planes on a system depends on the chassis type, the chassis mode (a, b, c, d) and the
number of installed switch fabrics.
To clarify these concepts, consider a system with the following hardware installed.

Advanced Configuration Guide

Page 861

Overview

A:PE-1# show card


===============================================================================
Card Summary
===============================================================================
Slot
Provisioned
Equipped
Admin
Operational
Comments
Card-type
Card-type
State
State
------------------------------------------------------------------------------6
iom3-xp
iom3-xp
up
up
7
imm8-10gb-xfp
imm8-10gb-xfp
up
up
8
iom3-xp
iom3-xp
up
up
A
sfm4-12
sfm4-12
up
up/active
B
sfm4-12
sfm4-12
up
up/standby
===============================================================================
A:PE-1#

Output 1 shows the mapping of paths to switch fabric planes.


A:PE-1# show system switch-fabric high-bandwidth-multicast
===============================================================================
Switch Fabric
===============================================================================
Cap:
Planes:
Slot/Mda Min Max Hbm Grp Hi | Lo
------------------------------------------------------------------------------6/1
100% 100% No 0
1 0 3 4 5 6 7 8 9 10 11 12 13 14 15 | 16
7/1
100% 100% No 0
19 17 20 21 22 23 24 25 26 27 28 29 30 31 32 | 33
8/1
100% 100% No 0
35 34 36 37 38 39 40 41 42 43 44 45 46 47 0 | 1
A
100% 100% No 0
2 | 2
B
100% 100% No 0
2 | 2
===============================================================================
A:PE-1#

Output 1: Paths and Planes in Chassis Mode d

This system has two SF/CPM4s and is using chassis mode d, this creates 24 planes per SF/CPM4
to give a total of 48 planes which are numbered 0-47. The IOM3-XP/IMMs have 16 paths each
which are connected to different planes. The SF/CPM4s together use a single plane and an
additional plane (18, which is not in the output above) is used by the system itself. As there are
more paths (3x16=48) in this configuration than available planes (48-2[system planes 2,18]=46),
some planes are shared by multiple paths, namely planes 0 and 1. Note that the path to plane
mapping can change after a reboot or after changing hardware.
The following output shows the equivalent information if an IOM2 is added to this configuration
in slot 5. In order for the IOM2 to be recognized, the system must be changed to use chassis mode
a, b or c.
A:PE-1# show card
===============================================================================
Card Summary
===============================================================================
Slot
Provisioned
Equipped
Admin
Operational
Comments
Card-type
Card-type
State
State
-------------------------------------------------------------------------------

Page 862

Advanced Configuration Guide

Ingress Multicast Path Management

5
iom2-20g
iom2-20g
up
up
6
iom3-xp
iom3-xp
up
up
7
imm8-10gb-xfp
imm8-10gb-xfp
up
up
8
iom3-xp
iom3-xp
up
up
A
sfm4-12
sfm4-12
up
up/active
B
sfm4-12
sfm4-12
up
up/standby
===============================================================================
A:PE-1#

The following output shows the mapping of the line card paths to the switch fabric planes with the
IOM2 installed.
A:PE-1# show system switch-fabric high-bandwidth-multicast
===============================================================================
Switch Fabric
===============================================================================
Cap:
Planes:
Slot/Mda Min Max Hbm Grp Hi | Lo
------------------------------------------------------------------------------5/1
100% 100% No 0
1 | 0
5/2
100% 100% No 0
4 | 3
6/1
100% 100% No 0
6 5 7 8 9 10 11 12 13 14 15 0 1 3 4 | 5
7/1
100% 100% No 0
7 6 8 9 10 11 12 13 14 15 0 1 3 4 5 | 6
8/1
100% 100% No 0
8 7 9 10 11 12 13 14 15 0 1 3 4 5 6 | 7
A
100% 100% No 0
2 | 2
B
100% 100% No 0
2 | 2
===============================================================================
A:PE-1#

Output 2: Paths and Planes in Chassis Mode a/b/c

Now that the system is not in chassis mode d, in fact it is in mode a (but the output would be the
same in modes b or c) the SF/CPM4s each create 8 planes giving a total of 16, numbered 0-15.
One plane (2) is used by the SF/CPM4s, leaving 15 (0-1,3-15) planes for connectivity to the line
card paths. Each IOM2 forwarding complex has 2 paths, so the paths of the IOM2 in slot 5 are
using planes 0 and 1, and 3 and 4. Note that there are now fewer planes available and more paths,
so there is more sharing of planes between paths than when chassis mode d was used.

IMPM Managed Traffic


IMPM manages IPv4/IPv6 routed multicast traffic and VPLS (IGMP and PIM) snooped IPv4
multicast traffic, traffic that matches a <*,G> or a <S,G> multicast record in the ingress
forwarding table. It manages IP multicast traffic on a bud LSR when using point-to-multipoint
(P2MP) LSPs but it does not manage IP protocol control traffic or traffic using multipoint-shared
queuing. Traffic being managed by IMPM involves IMPM monitoring and potentially moving the
related channels between paths/planes. The unmanaged traffic rates are also monitored and taken
into account in the IMPM algorithm.

Advanced Configuration Guide

Page 863

Overview

Care should be taken when using the mrouter-port configuration in a VPLS service. This creates a
(*,*) multicast record and consequently all multicast channels that are not delivered locally to a
non-mrouter port will be treated by IMPM as a single channel.

Page 864

Advanced Configuration Guide

Ingress Multicast Path Management

Configuration
This section covers:

IMPM on an IOM3-XP/IMM on page 868

IMPM on an IOM1/2 on page 878

IMPM Not Enabled on page 881

Prerequisites
As IMPM operates on IPv4/IPv6 routed or VPLS IGMP/PIM snooped IPv4 multicast traffic, some
basic multicast configuration must be enabled. This section uses routed IP multicast in the global
routing table which requires IP interfaces to be configured with PIM and IGMP. The configuration
uses a PIM rendezvous point and static IGMP joins. The following is an example of the complete
configuration of one interface.
configure
router
interface "int-IOM3-1"
address 172.16.6.254/24
port 6/2/1
exit
igmp
interface "int-IOM3-1"
static
group 239.255.0.1
starg
exit
exit
exit
no shutdown
exit
pim
interface "int-IOM3-1"
exit
rp
static
address 192.0.2.1
group-prefix 239.255.0.0/16
exit
exit
exit
no shutdown
exit
exit

Advanced Configuration Guide

Page 865

Configuration

One interface is configured on each line card configured in the system, as shown in the following
output, but omitting their IGMP and PIM configuration.
configure
router
interface "int-IMM8"
address 172.16.3.254/24
port 7/2/1
exit
interface "int-IOM2"
address 172.16.1.254/24
port 5/2/1
exit
interface "int-IOM3-1"
address 172.16.2.254/24
port 6/2/1
exit
interface "int-IOM3-2"
address 172.16.4.254/24
port 8/2/1
exit
exit

Page 866

Advanced Configuration Guide

Ingress Multicast Path Management

Configuring IMPM
The majority of the IMPM configuration is performed under the mcast-management CLI nodes
and consists of:
a. The bandwidth-policy for characteristics relating to the IOM/IMM paths. This is applied on
an IOM3-XP/IMM fp2, or an IOM1/2 MDA, under ingress mcast-path-management, with a
bandwidth-policy named default being applied by default.
IOM1/2
config# card slot-number mda mda-slot
ingress
mcast-path-management
bandwidth-policy policy-name

IOM3-XP/IMM
config# card slot-number fp [1]
ingress
mcast-path-management
bandwidth-policy policy-name

b. The multicast-info policy for information related to the channels and how they are handled
by the system. To facilitate provisioning, parameters can be configured under a three level
hierarchy with each level overriding the configuration of its predecessor:
Bundle: a group of channels
Channel: a single channel or a non-overlapping range of channels
Source-override: channels from a specific sender
config# mcast-management multicast-info-policy policy-name [create]
bundle bundle-name [create]
channel ip-address [ip-address] [create]
source-override ip-address [create]

This policy is applied where the channel enters the system, so under router or service (vpls
or vprn); the latter allows the handling of channels to be specific to a service, even if
multiple services use overlapping channel addresses.
config# router multicast-info-policy policy-name
config# service vpls service-id multicast-info-policy policy-name
config# service vprn service-id multicast-info-policy policy-name

A default multicast-info-policy is applied to the above when IMPM is enabled.


c. The chassis-level node configures the information relating to the switch fabric planes.
config# mcast-management chassis-level

2. fp is the system term for a forwarding complex on an IOM3-XP/IMM.

Advanced Configuration Guide

Page 867

Configuration

In addition, the command hi-bw-mcast-src (under an IOM3-XP/IMM fp or an IOM1/2 MDA) can


be used to control the path to plane mapping among forwarding complexes.

IMPM on an IOM3-XP/IMM
IMPM is enabled on IOM3-XP/IMMs on under the card/fp CLI node as follows
config# card slot-number fp 1 ingress mcast-path-management no shutdown

IOM3-XP/IMM Paths
16 paths are available on an IOM3-XP/IMM when IMPM is enabled which can be either primary
paths or secondary paths. By default the 16 paths are divided into 15 primary paths and 1
secondary path, as can be seen using the following command with IMPM enabled only on slot 6
(this corresponds to the plane assignment in Output 1):
*A:PE-1# tools dump mcast-path-mgr cpm
McPathMgr[6][0]: 0xf33b0a00
PATH:
Type SGs
InUseBW
AvailBW
TotalBw
P
1
0
P
1
0
P
1
0
P
1
0
P
1
0
P
1
0
P
1
0
P
1
0
P
1
0
P
1
0
P
1
0
P
1
0
P
1
0
P
1
0
P
1
0
S
1
0
B
0
0
*A:PE-1#

PLANE:
ID
SGs
1
1
0
1
3
1
4
1
5
1
6
1
7
1
8
1
9
1
10
1
11
1
12
1
13
1
14
1
15
1
16
1
-

InUseBW
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
-

AvailBW
2000000
2000000
2000000
2000000
2000000
2000000
2000000
2000000
2000000
2000000
2000000
2000000
2000000
2000000
2000000
1800000
-

TotalBw
2000000
2000000
2000000
2000000
2000000
2000000
2000000
2000000
2000000
2000000
2000000
2000000
2000000
2000000
2000000
1800000
-

Output 3: Paths/Planes on IOM3-XP/IMM

The left side of the output displays information about the paths (type {P=primary, s=secondary or
B=blackholed}, number of S,Gs and bandwidth in use (the path bandwidth cannot be set on an
IOM3-XP/IMM, so the path available and total bandwidth always shows - )) and the right side
displays similar information about the associated planes (this will be a combination of the
information for all paths connected to this plane). Note that one SG is always present on each path;
this is used by the system and relates to the unmanaged traffic.

Page 868

Advanced Configuration Guide

Ingress Multicast Path Management

The primary/secondary paths are also highlighted in the planes section of Output 1, the primary
paths being connected to the planes on the left of the | and the secondary paths to its right. There
is a default primary path and a default secondary path; these correspond to the left-most plane and
right-most plane for each line card, respectively.
Primary paths are used by:

Expedited IES, VPLS and VPRN service ingress non-managed multipoint traffic (using
the SAP based queues). This uses the default primary path.

Expedited network ingress non-managed multipoint traffic (using the network interface
queues). This uses the default primary path.

Managed multicast explicit path primary channels (using the primary paths managed
multipoint queue)

All managed multicast dynamic path channels when the primary paths or multicast planes
are not at their limit (using the primary paths managed multipoint queue)

Highest preference managed multicast dynamic path channels when the primary paths or
multicast planes are at their limit (using the primary paths managed multipoint queue)

Non-managed P2MP LSP IP multicast traffic. This does not require IMPM to be enabled,
so is discussed later in IMPM Not Enabled on page 881.

Non-managed expedited ingress policed multipoint traffic. This does not require IMPM to
be enabled, so is discussed in IMPM Not Enabled on page 881.

Secondary paths are used by:

Best-Effort IES, VPLS and VPRN service ingress non-managed multipoint traffic (using
the SAP based queues). This uses the default secondary path.

Best-Effort network ingress non-managed traffic (using the network interface multipoint
queues). This uses the default secondary path.

Managed multicast explicit path secondary channels (using the secondary paths managed
multipoint queue)

Lower preference managed multicast dynamic path channels when the primary paths or
multicast planes are at their limit (using the secondary paths managed multipoint queue)

Non-managed best-effort ingress policed multipoint traffic. This does not require IMPM
to be enabled, so is discussed in IMPM Not Enabled on page 881.

When IMPM is enabled, the managed traffic does not use the standard multipoint queues but
instead is placed onto a separate set of shared queues which are associated with the 16 paths.
These queues are instantiated in an access ingress pool (called MC Path Mgmt, see show output
section) which exists by default (this pool can be used even when IMPM is not enabled see
section IMPM not enabled). Statistics relating to traffic on these queues are reflected back to the
standard ingress multipoint queues for accounting and troubleshooting purposes. Note that non-

Advanced Configuration Guide

Page 869

Configuration

managed traffic continues to use the standard ingress multipoint queues, with the exception of
P2MP LSP IP multicast traffic and policed multipoint traffic.
The size of the pool by default is 10% of the total ingress pool size, the reserved CBS is 50% of
the pool and the default slope policy is applied. Care should be taken when changing the size of
this pool as this would affect the size of other ingress pools on the line card.
config# mcast-management bandwidth-policy policy-name [create]
mcast-pool percent-of-total percent-of-buffers
resv-cbs percent-of-pool
slope-policy policy-name

It is possible to configure the parameters for the queues associated with both the primary and
secondary paths, and also the number of secondary paths available, within the bandwidth-policy.
config# mcast-management bandwidth-policy policy-name create
t2-paths
primary-path
queue-parameters
cbs percentage
hi-priority-only percent-of-mbs
mbs percentage
secondary-path
number-paths number-of-paths [dual-sfm number-of-paths]
queue-parameters
cbs percentage
hi-priority-only percent-of-mbs
mbs percentage

The number of primary paths is 16 minus the number of secondary paths (at least one of each type
must exist). The number-paths parameter specifies the number of secondary paths when only one
switch fabric is active, while the dual-sfm parameter specifies the same value when two switch
fabrics are active.
Packets are scheduled out of the path/multicast queue as follows:

Traffic sent on primary paths is scheduled at multicast high priority while that on
secondary paths is scheduled at multicast low priority.

For managed traffic, the standard ingress forwarding class/prioritization is not used,
instead IMPM managed traffic prioritization is based on a channels preference (described
in Channel Prioritization and Blackholing Control on page 877). Egress scheduling is
unchanged.

Congestion handling (packet acceptance into the path/multicast queue):

Page 870

For non-managed traffic, this is based on the standard mechanism, namely the packets
enqueuing priority is used to determine whether the packet is accepted into the path
multipoint queue depending on the queue mbs/cbs and the pool shared-buffers/reservedbuffers/WRED.

Advanced Configuration Guide

Ingress Multicast Path Management

For managed traffic, the congestion handling is based upon the channels preference (described
later) and the channels cong-priority-threshold which is configured in the multicast-info-policy
(here under a bundle).
config# mcast-management multicast-info-policy policy-name [create]
bundle bundle-name [create]
cong-priority-threshold preference-level

When the preference of a channel is lower than the cong-priority-threshold setting, the traffic is
treated as low enqueuing priority, when it is equal to or higher than the cong-priority-threshold it
is treated as high enqueuing priority. The default cong-priority-threshold is 4.

IOM3-XP/IMM Planes
The capacity per plane for managed traffic is by default 2Gbps for a primary path and 1.8Gbps for
a secondary path. The logic behind a reduced default on the secondary is to leave capacity for new
streams in case the default secondary is fully used by managed streams.
The plane capacities can be configured as follows, note that this command configures the plane
bandwidth associated with primary/secondary paths as seen by each line card, the TotalBw on the
right side of Output 3:
config# mcast-management chassis-level
per-mcast-plane-limit megabits-per-second [secondary megabits-per-second]
[dual-sfm megabits-per-second [secondary-dual-sfm megabits-per-second]]

The first parameter defines the capacity for a primary path, the second a secondary path and the
dual-sfm configures these capacities when two switch fabrics are active. The maximum plane
capacity is 4Gbps but for the release used here it should only be configured on 7750 SR-12 or
7450 ESS-12 systems populated with SF/CPM4(s) and 100G FP IMMs; for all other hardware
combinations the maximum should be 2Gbps. Note that secondary plane capacity cannot be
higher than that of the primary plane.
These values can be tuned to constrain the amount of managed multicast traffic in favour of nonmanaged multicast and unicast traffic.
On the IOM3-XP/IMM line cards there is no separate control of the line card path capacity, the
capacity is only constrained by the plane.

IOM3-XP/IMM Path to Plane Mapping


By default all fps (line cards for IOM3-XP/IMM) are configured into the default (zero) group as
seen in Output 1 and the system distributes the paths as equally as possible over the available

Advanced Configuration Guide

Page 871

Configuration

planes. This default works well if there is a low volume of multicast traffic (compared to the plane
capacity), or if there is a higher volume multicast entering only one line card where the ingress
capacity does not exceed that provided by the planes the line card is connected to.
If there are more paths than planes and, for example, there is a high bandwidth multicast channel
entering two different line cards it could happen that both line cards select the same plane for two
paths that are used. This would result in one of the channels being blackholed if the plane capacity
is exceeded, effectively reducing the available multicast capacity from that line card. In order to
avoid this situation, it is possible to configure the paths in to different groups and the system will
attempt to use different planes for each group.
Output 1 and Output 2 show examples of how the paths are mapped to planes.
In both cases there are more paths than planes so some planes are shared by multiple paths. The
following command provides control of this mapping.
config# card slot-number fp [1]
hi-bw-mcast-src [alarm] [group group-id] [default-paths-only]

If an fp is configured into a non-zero group (range: 1 to 32), the system will attempt to assign
dedicate planes to its paths compared to other line cards in different non-zero groups. This action
is dependent on there being sufficient planes available. If two line cards are assigned to the same
group, they will be assigned the same planes. The default-paths-only parameter performs the
assignment optimization only for the default primary and secondary paths and is only applicable to
IOM3-XP/IMMs. The alarm keyword causes an alarm to be generated if some planes are still
shared with fps in a different group.
An example of the use of this command is shown later.
Note: When VPLS IGMP and PIM snooped traffic is forwarded to a spoke or mesh SDP, by
default it is sent by the switch fabric to all line card forwarding complexes on which there is a
network IP interface. This is due to the dynamic nature of the way that a spoke or mesh SDP is
associated with one or more egress network IP interfaces. If there is an active spoke/mesh SDP for
the VPLS service on the egress forwarding complex, the traffic will be flooded on that spoke/mesh
SDP, otherwise it will be dropped on the egress forwarding complex. This can be optimized by
configuring an inclusion list under the spoke or mesh SDP defining which MDAs this traffic
should be flooded to.
config>service>vpls# [spoke-sdp|mesh-sdp] sdp-id:vc-id egress
mfib-allowed-mda-destinations
[no] mda mda-id

The switch fabric flooding domain for this spoke or mesh SDP is made up only of the MDAs that
have been added to the list. An empty list implies the default behavior.
It is important to ensure that the spoke or mesh SDP can only be established across the MDAs
listed, for example by using RSVP with an explicit path.

Page 872

Advanced Configuration Guide

Ingress Multicast Path Management

IMPM Operation on IOM3-XP/IMM


This section covers:

Principle of Operation on page 873

Monitoring Traffic Rates on page 874

Channel Prioritization and Blackholing Control on page 877

Principle of Operation
Where IMPM is enabled, it constantly monitors the line cards for ingress managed traffic.
When a new channel arrives it will be placed by default on to the default secondary path. IMPM
determines the ingress point for the channel and then monitors the traffic of the channel within its
monitoring period in order to calculate the rate of the channel. The system then searches the
multicast paths/planes attached to the line card for available bandwidth. If there is sufficient
capacity on such a path/plane, the channel is moved to that plane. Planes corresponding to primary
paths are used first, when there is no capacity available on any primary path/plane a secondary
path/plane is used (unless the channel is explicitly configured onto a specific path type see the
following description).
If the required bandwidth is unavailable, the system will then look for any channels that ingress
this or other line cards that could be moved to a different multicast plane in order to free up
capacity for the new channel. Any channel that is currently mapped to a multicast plane available
to the ingress line card is eligible to be moved to a different multicast plane.
If an eligible existing channel is found, whether on this or another line card, that existing channel
is moved without packet loss to a new multicast plane. If necessary, this process can be repeated
resulting in multiple channels being moved. The new multicast channel is then mapped to the
multicast plane previously occupied by the moved channels, again this normally is using a primary
path.
If no movable channel is found, then lower preference channel(s) on any ingress line card that
share multicast planes with the ingress line card of the new channel can be blackholed to free up
capacity for the new channel. It is also possible to both blackhole some channels and move other
channels in order to free up the required capacity. If no lower preference channel is found and no
suitable channel moves are possible, the new channel will be blackholed.
If required, channels can be explicitly configured to be on either a primary or secondary path. This
can be done for a bundle of channels, for example
config# mcast-management multicast-info-policy policy-name [create]
bundle bundle-name [create]
explicit-sf-path {primary|secondary|ancillary}

Advanced Configuration Guide

Page 873

Configuration

Note that the ancillary path is not applicable to the IOM3-XP/IMM line cards, however, it is
discussed in the section relating to the IOM1/2. If a channel on an IOM3-XP/IMM is configured
onto the ancillary path it will use a primary path instead.
One secondary path on an IOM3-XP/IMM is used as a default startup path for new incoming
channels. If a large amount of new channel traffic could be received within the monitoring period,
it is possible that the plane associated with the default secondary path is over loaded before IMPM
has time to monitor the channels traffic rate and move the channels to a primary path (and a plane
with available capacity). This can be alleviated by configuring the following command:
config# mcast-management chassis-level
round-robin-inactive-records

When round-robin-inactive-records is enabled, the system redistributes new channels (which are
referenced by inactive S,G records) among all available line card multicast (primary, secondary)
paths and their switch fabric planes.

Monitoring Traffic Rates


The monitored traffic rate is the averaged traffic rate measured over a monitoring period. The
monitoring period used depends on the total number of channels seen by IMPM, the minimum is a
1 second interval and the maximum a 10 seconds interval.
The way in which the system reacts to the measured rate can be tuned using the following
command:
config# mcast-management multicast-info-policy policy-name [create]
bundle bundle-name [create]
bw-activity {use-admin-bw|dynamic [falling-delay seconds]}
[black-hole-rate kbps]

The default is to use the dynamic bandwidth rate, in which case a channels active traffic rate is
determined based on the measured monitored rates. IMPM then makes a decision of how to
process the channel as follows.
If the channel was un-managed, IMPM will attempt to place the channel on a path/plane with
sufficient available bandwidth.
If the channel was already managed, IMPM determines the highest monitored traffic rate (within a
given monitoring period) in a sliding window defined by the falling-delay. This highest chosen
monitored rate is then used to re-assess the placement of the channel on the path/planes; this may
cause IMPM to move the channel. This mechanism prevents the active rate for a channel being
reduced due to a momentarily drop in traffic rate. The default value for falling-delay is 30 seconds,
with a range of 10-3600 seconds.

Page 874

Advanced Configuration Guide

Ingress Multicast Path Management

The above logic is shown in Figure 48 (for simplicity, the falling-delay is exactly twice the
monitoring period). It can be seen that the active rate used when the traffic rate decreases follows
the highest monitored rate in any falling-delay period.
Dynamic Bandwidth Rate Management

Blackholed

Ingress
Channel
Traffic
Rate

Blackhole
Rate

Monitored
Rate

Active
Rate Used

Monitoring
Period

Falling-delay

Sliding Window

Time
OSSG726

Figure 48: Dynamic Bandwidth Rate Management

By using the sliding window of monitored rate measurements in the dynamic bandwidth
measurement mode, IMPM delays releasing capacity for a channel in its calculations when the
channels rate has been reduced. This allows IMPM to ignore temporary fluctuations in a
channels rate. It is possible to tune this for cases where the reduction in a channels rate is large by
using the falling-percent-reset parameter. The default for the falling-percent-reset is 50%. Setting
this to 100% effectively disables it.
config# mcast-management bandwidth-policy policy-name create
falling-percent-reset percent-of-highest

When the monitored rate falls by a percentage which is greater or equal to falling-percent-reset,
the rate used by IMPM is immediately set to this new monitored rate. This allows IMPM to react
faster to significant reductions in a channels rate while at the same time avoiding too frequent
reallocations due to normal rate fluctuations. An example of the falling-percent-reset is shown in
Figure 49. In the last two monitoring periods, it can be seen that the active rate used is equal to the
monitored rate in the previous periods, and not the higher rate in the previous falling-delay
window.

Advanced Configuration Guide

Page 875

Configuration

Ingress
Channel
Traffic
Rate

Drop > falling-percent-reset

Drop > falling-percent-reset

Monitoring
Period

Falling-delay

Monitored
Rate

Active
Rate Used

Sliding Window

Time
OSSG727

Figure 49: Falling-Percent-Reset

The rate management can be further tuned based on the expectation that the channel bandwidth
will fluctuate around a given rate. When the bw-activity is set to use-admin-bw within the
multicast-info-policy, the following parameters come into play.
config# mcast-management multicast-info-policy policy-name [create]
bundle bundle-name [create]
admin-bw kbps
config# mcast-management bandwidth-policy policy-name create
admin-bw-threshold kilo-bits-per-second

IMPM will use the rate configured for the admin-bw if the monitored rate is above the admin-bwthreshold but below or equal to the admin-bw in the sliding window of the falling-delay.
Whenever the monitored rate is below the admin-bw-threshold or above the admin-bw, IMPM
uses the dynamic rate management mechanism. The admin-bw-threshold needs to be smaller than
the admin-bw, with the latter being non-zero. This is shown in Figure 50 (for simplicity, the
falling-delay is exactly twice the monitoring period). It can be seen that while the monitored rate
stays between the admin-bw-threshold and the admin-bw, the active rate used is set to the adminbw.

Page 876

Advanced Configuration Guide

Ingress Multicast Path Management

Monitored
Rate

admin-bw Rate Management

Active
Rate Used
Blackhole
Rate
Blackholed

Ingress
Channel
Traffic
Rate

admin-bw

admin-bw
Threshold

Monitoring
Period

Falling-delay

Sliding Window

Time
OSSG728

Figure 50: Admin-Bw Rate Management

Finally, IMPM also takes into consideration the unmanaged traffic rate on the primary and
secondary paths associated with SAP/network interface queues when determining the available
capacity on these paths/planes. This is achieved by constantly monitoring the rate of this traffic on
these queues and including this rate in the path/plane capacity usage. IMPM must be enabled on
the ingress card of the unmanaged traffic otherwise it will not be monitored.

Channel Prioritization and Blackholing Control


IMPM decides which channels will be forwarded and which will be dropped based on a
configured channel preference. The preference value can be in the range 0-7, with 7 being the
most preferred and the default value being 0.
When there is insufficient capacity on the paths/planes to support all ingress multipoint traffic,
IMPM uses the channel preferences to determine which channels should be forwarded and which
should be blackholed (dropped).
This is an important distinction compared to the standard forwarding class packet prioritization;
by using a channel preference, an entire channel is either forwarded or blackholed, this allows
IMPM to avoid congestion having a small impact on multiple channels at the cost of entire
channels being lost.

Advanced Configuration Guide

Page 877

Configuration

The channel preference is set within the multicast-info-policy, for example at the bundle level,
with the settable values being 1-7:
config# mcast-management multicast-info-policy policy-name [create]
bundle bundle-name [create]
preference preference-level

The channel preference is also used for congestion control in the line card path queues see
congestion handling in the section on IOM3-XP/IMM Paths above.
Blackhole protection can also be enabled using the bw-activity command, shown above in the
Monitoring traffic rates section. Regardless of which rate monitoring mechanism is used, a
channel can be blackholed if the monitored rate exceeds the black-hole-rate, in which case the
channel will be put immediately on the blackhole list and its packets dropped at ingress. This
channel will no longer consume line card path or switch fabric capacity. The intention of this
parameter is to provide a protection mechanism in case channels consume more bandwidth than
expected which could adversely affect other channels.
The black-hole-rate can range from 0 to 40000000kbps, with no black-hole-rate by default. This
protection is shown in the last monitoring period of both Figure 2 and Figure 4. Note that it will
take a falling-delay period in which the channels rate is always below the black-hole-rate in order
for the channel to be re-instated unless the reduction in the rate is above the falling-percent-reset.

IMPM on an IOM1/2
As most of the principles when using IMPM on an IOM1/2 compared to on an IOM3-XP/IMM are
the same and are described above, this section focuses only on the difference between the two.
Note that an IOM1 and IOM2 have two independent 10G forwarding complexes; in both cases
there is a single MDA per forwarding complex, consequently some aspects of IMPM are
configured under the mda CLI node.
IMPM is enabled on an IOM1/2 under the MDA CLI node as follows:
config# card slot-number mda mda-slot ingress mcast-path-management no shutdown

IOM1/2 Paths
Each forwarding complex has three paths: one primary and one secondary path, and another type
called the ancillary path which is IOM1/2 specific. The paths can be seen using the following
command with IMPM enabled only on slot 5 MDA 1 and MDA 2 (referenced as [0] and [1]
respectively):
A:PE-1# tools dump mcast-path-mgr cpm

Page 878

Advanced Configuration Guide

Ingress Multicast Path Management

McPathMgr[5][0]: 0xf33b0a00
PATH:
Type SGs
InUseBW
AvailBW
P
1
0
2000000
S
1
0
1500000
A
0
0
5000000
B
0
0
McPathMgr[5][1]: 0xf33b3198
PATH:
Type SGs
InUseBW
AvailBW
P
1
0
2000000
S
1
0
1500000
A
0
0
5000000
B
0
0
A:PE-1#

TotalBw
2000000
1500000
5000000
-

PLANE:
ID
SGs
1
1
0
1
-

InUseBW
0
0
-

AvailBW
2000000
1800000
-

TotalBw
2000000
1800000
-

TotalBw
2000000
1500000
5000000
-

PLANE:
ID
SGs
4
1
3
1
-

InUseBW
0
0
-

AvailBW
2000000
1800000
-

TotalBw
2000000
1800000
-

Output 4: Paths/Planes on IOM1/2

The primary and secondary paths function as on the IOM3-XP/IMM, specifically for:

Traffic usage.

Associated queues instantiated in the ingress MC Path Mgmt ingress pool.

Packet scheduling.

Congestion handling.

The queue parameters can be configured within the bandwidth-policy in a similar way to the
IOM3-XP/IMM (note that the IOM3-XP/IMM equivalent for this is under the t2-paths CLI node).
The bandwidth-policy is then applied under the respective MDA.
config# mcast-management bandwidth-policy policy-name create
primary-path
queue-parameters
cbs percentage
hi-priority-only percent-of-mbs
mbs percentage
secondary-path
queue-parameters
cbs percentage
hi-priority-only percent-of-mbs
mbs percentage

The IOM1/2 allows capacity control on the paths themselves, which is not possible on the IOM3XP/IMM. This is achieved using the following commands.
config# mcast-management bandwidth-policy policy-name create
primary-path
path-limit megabits-per-second
secondary-path
path-limit megabits-per-second

Advanced Configuration Guide

Page 879

Configuration

The maximum path-limit for both the primary and secondary path is 2Gbps with a default of
2Gbps for the primary path and 1.5Gbps for the secondary path. The capability to set a path limit
for the IOM1/2 can be seen when comparing Output 3 with Output 4; in the latter the AvailBW
and TotalBw for the PATH shows the path limit.
In addition to setting the path limits in the bandwidth-policy, they can also be overridden on a
given MDA.
config# card slot-number mda mda-slot
ingress
mcast-path-management
primary-override
path-limit megabits-per-second
secondary-override
path-limit megabits-per-second

The achievable capacity will be the minimum of the paths path-limit and the planes per-mcastplane-limit.
Ancillary Path

The ancillary path


The ancillary path allows managed multicast traffic to be forwarded through the switch fabric as
unicast and so is not constrained to the path or plane capacities. This is achieved using ingress
replication, in order to send a channel to multiple destination forwarding complexes (DFCs), the
ingress forwarding complex creates and forwards one copy of each packet to each DFC connected
to the switch fabric.
However, the total replication capacity available for the ancillary path is constrained to 5G to
prevent it impacting the unicast or primary/secondary path capacities. This means that the total
amount of ancillary capacity usable can be calculated from (note that the first copy sent is not
included in this capacity, hence the -1):
5Gbps/(number_of_switch_fabric_DFCs 1)
Taking an example shown later, if some channels ingress an IOM2 and egress 2 IOM3-XP (1 DFC
each) and 1 IMM8 (1 DFC) to give a total of 3 egress DFCs, then total ancillary capacity available
is
5Gbps/(3-1) = 2.5Gbps.
This would allow, for example, approximately 250 channels at 10Mbps each to use the ancillary
path.
Due to the relationship between ancillary capacity and number of DFCs, the system will prefer the
ancillary path as default whenever a channel enters an IOM1/2 and egresses on up to 3 DFCs. If
there are 4 or more egress DFCs for the channel, then the primary path is preferred. The
determination is performed on a per channel basis.

Page 880

Advanced Configuration Guide

Ingress Multicast Path Management

The configuration parameters relating to the primary and secondary paths are also available for the
ancillary path.
config# mcast-management bandwidth-policy policy-name create
ancillary-path
queue-parameters
cbs percentage
hi-priority-only percent-of-mbs
mbs percentage
config# mcast-management bandwidth-policy policy-name create
ancillary-path
path-limit megabits-per-second
config# card slot-number mda mda-slot
ingress
mcast-path-management
ancillary-override
path-limit megabits-per-second

IOM1/2 Planes
The capacity per plane for managed traffic is by default 2Gbps for a primary path and 1.8Gbps for
a secondary path. Note that the default IOM1/2 secondary path limit is 1.5Gbps. A maximum of
2Gbps should be configured for either path type using the per-mcast-plane-limit (as shown for the
IOM3-XP/IMM) when an IOM1/2 is being used with IMPM.
As the ancillary path does not use the switch fabric planes, there is no associated plane limit.

IOM1/2 Path to Plane Mapping


The hi-bw-mcast-src command function is the same for IOM1/2 line cards as for IOM3-XP/IMM
line cards, as described above.

IMPM Operation on IOM1/2


This is exactly the same as the operation as for the IOM3-XP/IMM, see above.

IMPM Not Enabled


When IMPM is not enabled most multipoint traffic on an IOM1/2 and IOM3-XP/IMM can use
only one primary path and one secondary path per forwarding complex. When ingress multipoint
arrives it is placed on a multipoint queue and these queues are connected either to a primary path
(if the queue is expedited) or a secondary path (if the queue is best-effort) depending on the

Advanced Configuration Guide

Page 881

Configuration

ingress QOS classification applied. Standard ingress forwarding class/scheduling prioritization is


used.
The capacity of the primary and secondary paths is 2Gbps, unless the system is a 7750 SR-12 or
7450 ESS-12 populated with SF/CPM4(s) and 100G FP IMMs in which case the capacity is
4Gbps.
In Output 1 and Output 2, the primary path is associated with the left-most plane and the
secondary path is associated with the right-most plane for each line card.
There are exceptions to the above on the IOM3-XP/IMM line cards for

Point-to-multipoint LSP IP multicast traffic

Policed ingress routed IP multicast or VPLS broadcast, unknown or multicast traffic

Point-to-Multipoint (P2MP) LSP IP Multicast Traffic


IMPM will manage traffic on a P2MP LSP for any IP multicast channel that is delivered locally,
for example, the system is a bud LSR. However, non-managed P2MP LSP IP multicast traffic will
also make use of the primary paths, regardless of whether IMPM is enabled or not.
For each primary queue created in the MC IMPM Path pool, an additional queue is created to
carry non-managed P2MP LSP IP multicast traffic. The non-managed P2MP LSP IP multicast
traffic is automatically distributed across all primary paths based on a modulo N function of the 10
least significant bits of channel destination group address, where N is the number of primary
paths. Note that the number of primary paths can be changed with IMPM enabled or disabled by
applying a bandwidth-policy which sets the number of secondary paths.

Policed Ingress Routed IP Multicast or VPLS Broadcast, Unknown Or Multicast Traffic


Routed IP multicast or VPLS broadcast, unknown or multicast traffic passing through ingress
hardware policers on the IOM3-XP/IMM can also use the IMPM managed queues, with IMPM
enabled or disabled. If this traffic is best-effort (forwarding classes BE, L2, AF, L1) it will use the
secondary paths, if it is expedited (forwarding classes H2, EF, H1, NC) it will use the primary
paths. Note that this traffic uses the shared ingress policer-output-queues which have a fixed
forwarding class to queue mapping).
When IMPM is not enabled, this traffic is non-managed and 1 secondary path plus 15 primary
paths are available (the default). Consequently, extra capacity is only available for the expedited
traffic, which could use up to 15 planes worth of switch fabric capacity. If extra capacity is
required for best-effort traffic, a bandwidth-policy allocating more secondary paths can applied to
the line card even without IMPM being enabled.

Page 882

Advanced Configuration Guide

Ingress Multicast Path Management

The policed ingress routed IP or VPLS broadcast, unknown or multicast traffic is distributed
across the paths using a standard LAG hash algorithm (as described in the LAG and ECMP
Hashing section in the Interface Configuration guide).
For both of these exceptions, it is recommended to reduce the managed traffic primary/secondary
plane limits (using per-mcast-plane-limit) in order to allow for the non-managed traffic.

Advanced Configuration Guide

Page 883

Configuration

Show Output
This section includes the show output related to IMPM. The first part covers generic output and
uses IOM3-XP/IMMs and chassis mode d. The second part includes an IOM2 and so uses chassis
mode a.

IOM3-XP/IMM and Generic Output


The system has an IOM3-XP in slots 6 and 8, with an IMM8 is slot 7.
A:PE-1# show card
===============================================================================
Card Summary
===============================================================================
Slot
Provisioned
Equipped
Admin
Operational
Comments
Card-type
Card-type
State
State
------------------------------------------------------------------------------6
iom3-xp
iom3-xp
up
up
7
imm8-10gb-xfp
imm8-10gb-xfp
up
up
8
iom3-xp
iom3-xp
up
up
A
sfm4-12
sfm4-12
up
up/active
B
sfm4-12
sfm4-12
up
up/standby
===============================================================================
A:PE-1#

The status of IMPM on a given card can be shown as follows:


*A:PE-1# show card 6 detail
===============================================================================
Card 6
===============================================================================
Slot
Provisioned
Equipped
Admin
Operational
Comments
Card-type
Card-type
State
State
------------------------------------------------------------------------------6
iom3-xp
iom3-xp
up
up
FP 1 Specific Data
hi-bw-mc-srcEgress Alarm
hi-bw-mc-srcEgress Group
mc-path-mgmt Admin State
Ingress Bandwidth Policy

:
:
:
:

2
0
In Service
default

IMPM is enabled on the fp, it is using the default bandwidth-policy and is using the default hi-bwmcast-src group (0).

Page 884

Advanced Configuration Guide

Ingress Multicast Path Management

The MC Path Mgmt pool is created by default with the default settings.
*A:PE-1# show pools 6/1
===============================================================================
===============================================================================
Type
Id
App.
Pool Name
Actual ResvCBS PoolSize
Admin ResvCBS
------------------------------------------------------------------------------MDA
6/1
Acc-Ing MC Path Mgmt
18816
37632
50%
===============================================================================
*A:PE-1#

The default bandwidth-policy can be shown, giving the default parameters for the MC Path Pool
and the associated queues.
*A:PE-1# show mcast-management bandwidth-policy "default" detail
===============================================================================
Bandwidth Policy Details
===============================================================================
------------------------------------------------------------------------------Policy
: default
------------------------------------------------------------------------------Admin BW Thd
: 10 kbps
Falling Percent RST: 50
Mcast Pool Total
: 10
Mcast Pool Resv Cbs: 50
Slope Policy
: default
Primary
Limit
: 2000 mbps
Cbs
: 5.00
Mbs
: 7.00
High Priority
: 10
Secondary
Limit
: 1500 mbps
Cbs
: 30.00
Mbs
: 40.00
High Priority
: 10
Ancillary
Limit
: 5000 mbps
Cbs
: 65.00
Mbs
: 80.00
High Priority
: 10
T2-Primary
Cbs
: 5.00
Mbs
: 7.00
High Priority
: 10
T2-Secondary
Cbs
: 30.00
Mbs
: 40.00
High Priority
: 10
Paths(Single/Dual) : 1/1
===============================================================================
Bandwidth Policies : 1
===============================================================================
*A:PE-1#

The defaults for the multicast-info-policy can be seen in configuration mode.


*A:PE-1# configure mcast-management
*A:PE-1>config>mcast-mgmt# info detail
---------------------------------------------multicast-info-policy "default" create
no description
bundle "default" create

Advanced Configuration Guide

Page 885

Configuration

no cong-priority-threshold
no description
no ecmp-opt-threshold
no admin-bw
no preference
no keepalive-override
no explicit-sf-path
bw-activity dynamic falling-delay 30
no primary-tunnel-interface
exit
exit

The paths/planes on an IOM3-XP/IMM can be shown here for card 6.


*A:PE-1# tools dump mcast-path-mgr cpm
McPathMgr[6][0]: 0xf33b0a00
PATH:
Type SGs
InUseBW
AvailBW
TotalBw
P
1
0
P
1
0
P
1
0
P
1
0
P
1
0
P
1
0
P
1
0
P
1
0
P
1
0
P
1
0
P
1
0
P
1
0
P
1
0
P
1
0
P
1
0
S
1
0
B
0
0
*A:PE-1#

PLANE:
ID
SGs
4
1
3
1
5
1
6
1
7
1
8
1
9
1
10
1
11
1
12
1
13
1
14
1
15
1
16
1
0
1
1
1
-

InUseBW
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
-

AvailBW
2000000
2000000
2000000
2000000
2000000
2000000
2000000
2000000
2000000
2000000
2000000
2000000
2000000
2000000
2000000
1800000
-

TotalBw
2000000
2000000
2000000
2000000
2000000
2000000
2000000
2000000
2000000
2000000
2000000
2000000
2000000
2000000
2000000
1800000
-

Notice the plane total bandwidth is by default 2000Mbps for the primary paths and 1800Mbps for
the secondary path, as can also be seen using this output.
*A:PE-1# show mcast-management chassis
===============================================================================
Chassis Information
===============================================================================
BW per MC plane
Single SFM Dual SFM
------------------------------------------------------------------------------Primary Path
2000
2000
Secondary Path
1800
1800
------------------------------------------------------------------------------MMRP Admin Mode
Disabled
MMRP Oper Mode
Disabled
Round Robin Inactive Records Disabled
===============================================================================
*A:PE-1#

Page 886

Advanced Configuration Guide

Ingress Multicast Path Management

The Round Robin Inactive Records is disabled. The MMRP (Multiple MAC Registration
Protocol) modes relate to the use of the MC Path Mgmt queues for MMRP traffic. When this is
enabled, normal IMPM behavior is suspended so it is not in the scope of this configuration note.
A single channel (239.255.0.2) is now sent into interface int-IOM3-1 on port 6/2/1 with static
IGMP joins on interfaces int-IMM8, int-IOM3-1 and int-IOM3-2. The current forwarding rate can
be seen.
*A:PE-1# show router pim group detail
===============================================================================
PIM Source Group ipv4
===============================================================================
Group Address
: 239.255.0.2
Source Address
: 172.16.2.1
RP Address
: 192.0.2.1
Flags
: spt, rpt-prn-des
Type
: (S,G)
MRIB Next Hop
: 172.16.2.1
MRIB Src Flags
: direct
Keepalive Timer Exp: 0d 00:03:14
Up Time
: 0d 00:00:16
Resolved By
: rtable-u
Up JP State
Up JP Rpt

: Joined
: Pruned

Register State
: Pruned
Reg From Anycast RP: No

Up JP Expiry
: 0d 00:00:00
Up JP Rpt Override : 0d 00:00:00
Register Stop Exp

: 0d 00:00:59

Rpf Neighbor
: 172.16.2.1
Incoming Intf
: int-IOM3-1
Outgoing Intf List : int-IMM8, int-IOM3-1, int-IOM3-2
Curr Fwding Rate
Forwarded Packets
Forwarded Octets
Spt threshold
Admin bandwidth

:
:
:
:
:

9873.0 kbps
18017
24899494
0 kbps
1 kbps

Discarded Packets : 0
RPF Mismatches
: 0
ECMP opt threshold : 7

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

From the two sets of output below it can be seen that this is using the default primary path and
switch fabric plane 4.
*A:PE-1# tools dump mcast-path-mgr cpm
McPathMgr[6][0]: 0xf33b0a00
PATH:
Type SGs
InUseBW
AvailBW
TotalBw
P
2
9895
P
1
0
P
1
0
P
1
0
P
1
0
P
1
0
P
1
0
P
1
0
P
1
0
P
1
0
-

Advanced Configuration Guide

PLANE:
ID
SGs
4
2
3
1
5
1
6
1
7
1
8
1
9
1
10
1
11
1
12
1

InUseBW
9895
0
0
0
0
0
0
0
0
0

AvailBW
1990105
2000000
2000000
2000000
2000000
2000000
2000000
2000000
2000000
2000000

TotalBw
2000000
2000000
2000000
2000000
2000000
2000000
2000000
2000000
2000000
2000000

Page 887

Configuration

P
1
P
1
P
1
P
1
P
1
S
1
B
0
*A:PE-1#

0
0
0
0
0
0
0

13
14
15
16
0
1
-

1
1
1
1
1
1
-

0
0
0
0
0
0
-

2000000
2000000
2000000
2000000
2000000
1800000
-

2000000
2000000
2000000
2000000
2000000
1800000
-

*A:PE-1# show system switch-fabric high-bandwidth-multicast


===============================================================================
Switch Fabric
===============================================================================
Cap:
Planes:
Slot/Mda Min Max Hbm Grp Hi | Lo
------------------------------------------------------------------------------6/1
100% 100% No 0
4 3 5 6 7 8 9 10 11 12 13 14 15 16 0 | 1
7/1
100% 100% No 0
19 17 20 21 22 23 24 25 26 27 28 29 30 31 32 | 33
8/1
100% 100% No 0
35 34 36 37 38 39 40 41 42 43 44 45 46 47 0 | 1
A
100% 100% No 0
2 | 2
B
100% 100% No 0
2 | 2
===============================================================================
*A:PE-1#

The information about the channel can be seen using this command.
*A:PE-1# show mcast-management
channel [router router-instance|vpls service-id|service-name service-name]
[mda slot[/mda]]
[group ip-address [source ip-address]]
[path path-type]
[detail]

The output for the channel being sent is as follows.


*A:PE-1# show mcast-management channel
===============================================================================
Multicast Channels
===============================================================================
Legend : D - Dynamic E - Explicit
===============================================================================
Source Address
Slot/Cpx Current-Bw Path
D/E
Group Address
Highest-Bw Plane
------------------------------------------------------------------------------172.16.2.1
6/1
9873
Primary
D
239.255.0.2
9873
4
===============================================================================
Multicast Channels : 1
===============================================================================
*A:PE-1#

Page 888

Advanced Configuration Guide

Ingress Multicast Path Management

*A:PE-1# show mcast-management channel detail


===============================================================================
Multicast Channels
===============================================================================
------------------------------------------------------------------------------Source Address
: 172.16.2.1
Group Address
: 239.255.0.2
------------------------------------------------------------------------------Slot/Complex
: 6/1
Current Bw
: 9873 kbps
Dynamic/Explicit
: Dynamic
Current Path
: Primary
Oper Admin Bw
: 0 kbps
Current Plane
: 4
Ing last highest
: 9873
Preference
: 0
Black-hole rate
: None
Ing sec highest
: 9873
Time remaining
: 30 seconds
Blackhole
: No
===============================================================================
Multicast Channels : 1
===============================================================================
*A:PE-1#

The channel is using the dynamic bandwidth activity measurement and the current bandwidth, last
highest and second last highest rates are shown (which are the same as this traffic is from a traffic
generator).
The Time remaining is the time remaining in the current falling-delay period. This is reset to the
falling-delay every time the last highest bandwidth gets updated, when it reaches zero the value of
last highest bandwidth will be replaced with second highest bandwidth and the second highest
bandwidth will be set to the value of current bandwidth.
The Oper Admin Bw displays the value used for the admin-bw for this channel.
A subset of this information can be seen using this tools command.
*A:PE-1# tools dump mcast-path-mgr channels slot 6
===============================================================================
Slot: 6 Complex: 0
===============================================================================
Source address
CurrBw
Plane PathType Path Pref
Group address
PathBw
Repl Exp
BlkHoleBw
------------------------------------------------------------------------------172.16.2.1
9873
4
primary
0
0
239.255.0.2
9873
2
none
0
Unmanaged traffic
0
4
primary
0
8
slot: 6 cmplx: 0 path: 0
0
0
none
0
Unmanaged traffic
0
3
primary
1
8
slot: 6 cmplx: 0 path: 1
0
0
none
0
Unmanaged traffic
0
5
primary
2
8
slot: 6 cmplx: 0 path: 2
0
0
none
0
Unmanaged traffic
0
6
primary
3
8
slot: 6 cmplx: 0 path: 3
0
0
none
0
Unmanaged traffic
0
7
primary
4
8
slot: 6 cmplx: 0 path: 4
0
0
none
0
Unmanaged traffic
0
8
primary
5
8
slot: 6 cmplx: 0 path: 5
0
0
none
0
Unmanaged traffic
0
9
primary
6
8
slot: 6 cmplx: 0 path: 6
0
0
none
0

Advanced Configuration Guide

Page 889

Configuration

Unmanaged traffic
slot: 6 cmplx: 0
Unmanaged traffic
slot: 6 cmplx: 0
Unmanaged traffic
slot: 6 cmplx: 0
Unmanaged traffic
slot: 6 cmplx: 0
Unmanaged traffic
slot: 6 cmplx: 0
Unmanaged traffic
slot: 6 cmplx: 0
Unmanaged traffic
slot: 6 cmplx: 0
Unmanaged traffic
slot: 6 cmplx: 0
Unmanaged traffic
slot: 6 cmplx: 0
*A:PE-1#

path: 7
path: 8
path: 9
path: 10
path: 11
path: 12
path: 13
path: 14
path: 15

0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0

10
0
11
0
12
0
13
0
14
0
15
0
16
0
0
0
1
0

primary
none
primary
none
primary
none
primary
none
primary
none
primary
none
primary
none
primary
none
secondary
none

7
0
8
0
9
0
10
0
11
0
12
0
13
0
14
0
15
0

8
8
8
8
8
8
8
8
8

The bandwidth activity monitoring is now changed to use an admin-bw of 12Mbps with a
blackhole rate of 15Mbps.
*A:PE-1# configure mcast-management
*A:PE-1>config>mcast-mgmt# info
---------------------------------------------bandwidth-policy "bandwidth-policy-1" create
admin-bw-threshold 8000
exit
multicast-info-policy "multicast-info-policy-1" create
bundle "default" create
exit
bundle "bundle-1" create
channel "239.255.0.1" "239.255.0.16" create
admin-bw 12000
bw-activity use-admin-bw black-hole-rate 15000
exit
exit
exit
---------------------------------------------*A:PE-1>config>mcast-mgmt# exit all

*A:PE-1# show mcast-management channel group 239.255.0.2 detail


===============================================================================
Multicast Channels
===============================================================================
------------------------------------------------------------------------------Source Address
: 172.16.2.1
Group Address
: 239.255.0.2
------------------------------------------------------------------------------Slot/Complex
: 6/1
Current Bw
: 9873 kbps
Dynamic/Explicit
: Dynamic
Current Path
: Primary
Oper Admin Bw
: 12000 kbps
Current Plane
: 4
Ing last highest
: 12000
Preference
: 0
Black-hole rate
: 15000 kbps
Ing sec highest
: 12000
Time remaining
: 30 seconds
Blackhole
: No

Page 890

Advanced Configuration Guide

Ingress Multicast Path Management

===============================================================================
Multicast Channels : 1
===============================================================================
*A:PE-1#

*A:PE-1# tools dump mcast-path-mgr cpm


McPathMgr[6][0]: 0xf33b0a00
PATH:
Type SGs
InUseBW
AvailBW
TotalBw
P
2
12000
P
1
0
P
1
0
P
1
0
P
1
0
P
1
0
P
1
0
P
1
0
P
1
0
P
1
0
P
1
0
P
1
0
P
1
0
P
1
0
P
1
0
S
1
0
B
0
0
*A:PE-1#

PLANE:
ID
SGs
4
2
3
1
5
1
6
1
7
1
8
1
9
1
10
1
11
1
12
1
13
1
14
1
15
1
16
1
0
1
1
1
-

InUseBW
12000
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
-

AvailBW
1988000
2000000
2000000
2000000
2000000
2000000
2000000
2000000
2000000
2000000
2000000
2000000
2000000
2000000
2000000
1800000
-

TotalBw
2000000
2000000
2000000
2000000
2000000
2000000
2000000
2000000
2000000
2000000
2000000
2000000
2000000
2000000
2000000
1800000
-

Now the system treats the channel as though it is using 12Mbps capacity even though its current
rate has not changed.
If the rate is increased above the blackhole rate, the channel is blackholed and an alarm is
generated.
*A:PE-1#
11 2011/10/21 01:40:13.21 UTC MINOR: MCPATH #2001 Base Black-hole-rate is reached
"Channel (172.16.2.1,239.255.0.2) for vRtr instance 1 slot/cplx 6/1 has been blackholed."
*A:PE-1# show mcast-management channel group 239.255.0.2 detail
===============================================================================
Multicast Channels
===============================================================================
------------------------------------------------------------------------------Source Address
: 172.16.2.1
Group Address
: 239.255.0.2
------------------------------------------------------------------------------Slot/Complex
: 6/1
Current Bw
: 19458 kbps
Dynamic/Explicit
: Dynamic
Current Path
: Blackhole
Oper Admin Bw
: 12000 kbps
Current Plane
: N/A
Ing last highest
: 19480
Preference
: 0
Black-hole rate
: 15000 kbps
Ing sec highest
: 19469
Time remaining
: 23 seconds
Blackhole
: Yes
===============================================================================
Multicast Channels : 1
===============================================================================
*A:PE-1#
*A:PE-1# tools dump mcast-path-mgr cpm

Advanced Configuration Guide

Page 891

Configuration

McPathMgr[6][0]: 0xf33b0a00
PATH:
Type SGs
InUseBW
AvailBW
P
1
0
P
1
0
P
1
0
P
1
0
P
1
0
P
1
0
P
1
0
P
1
0
P
1
0
P
1
0
P
1
0
P
1
0
P
1
0
P
1
0
P
1
0
S
1
0
B
1
19480
*A:PE-1#

TotalBw
-

PLANE:
ID
SGs
4
1
3
1
5
1
6
1
7
1
8
1
9
1
10
1
11
1
12
1
13
1
14
1
15
1
16
1
0
1
1
1
-

InUseBW
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
-

AvailBW
2000000
2000000
2000000
2000000
2000000
2000000
2000000
2000000
2000000
2000000
2000000
2000000
2000000
2000000
2000000
1800000
-

TotalBw
2000000
2000000
2000000
2000000
2000000
2000000
2000000
2000000
2000000
2000000
2000000
2000000
2000000
2000000
2000000
1800000
-

The output displayed above shows an alarm generated for a channel being blackholed due to the
channel rate reaching the configured black-hole-rate. The example output below is an alarm for a
channel being blackholed due to insufficient bandwidth being available to it.
7 2011/10/22 21:53:43.54 UTC MINOR: MCPATH #2001 Base No bandwidth available
"Channel (172.16.2.1,239.255.0.2) for vRtr instance 1 slot/cplx 6/1 has been blackholed."

Note that the following alarm relates to a dummy channel used to account for the unmanaged
traffic. However, this traffic is never actually blackholed.
6 2011/10/21 00:27:58.00 UTC MINOR: MCPATH #2002 Base
"Channel (0.0.0.0,0.6.0.0) for unknown value (2) instance 0 slot/cplx 6/1 is no longer
being blackholed."

Alarms are also generated when all paths of a given type reach certain thresholds.
For primary and secondary paths, the two path range limit thresholds are

Full: less than 5% capacity is available


9 2011/10/24 22:53:27.02 UTC MINOR: MCPATH #2003 Base
"The available bandwidth on secondary path on slot/cplx 6/1 has reached its maximum
limit."

Not full: more than 10% of the path capacity is available.


10 2011/10/24 22:53:48.02 UTC MINOR: MCPATH #2004 Base
"The available bandwidth on secondary path on slot/cplx 6/1 is within range limits."

Page 892

Advanced Configuration Guide

Ingress Multicast Path Management

A maximum of one alarm is generated for each event (blackhole start/stop, path full/not full)
within a 3 second period. So, for example, if multiple channels are blackholed within the same 3
second period only one alarm will be generated (for the first event).
The effect of using the hi-bw-mcast-src command is illustrated below. Firstly, line card 6 is
configured into group 1.
*A:PE-1# configure card 6 fp hi-bw-mcast-src group 1 alarm
*A:PE-1# show system switch-fabric high-bandwidth-multicast
===============================================================================
Switch Fabric
===============================================================================
Cap:
Planes:
Slot/Mda Min Max Hbm Grp Hi | Lo
------------------------------------------------------------------------------6/1
100% 100% Yes 1
4 3 5 6 7 8 9 10 11 12 13 14 15 16 0 | 1
7/1
100% 100% No 0
19 17 20 21 22 23 24 25 26 27 28 29 30 31 32 | 33
8/1
100% 100% No 0
35 34 36 37 38 39 40 41 42 43 44 45 46 47 0 | 1
A
100% 100% No 0
2 | 2
B
100% 100% No 0
2 | 2
===============================================================================
*A:PE-1#

The plane assignment has not changed (though it is possible that the system could re-arrange the
planes used by card 6) and there are still planes (0,1) shared between card 6 and card 8.
Now card 8 is configured into group 2 (note that IMPM is only enabled on card 6 here).
*A:PE-1# configure card 8 fp hi-bw-mcast-src group 2 alarm
*A:PE-1# show system switch-fabric high-bandwidth-multicast
===============================================================================
Switch Fabric
===============================================================================
Cap:
Planes:
Slot/Mda Min Max Hbm Grp Hi | Lo
------------------------------------------------------------------------------6/1
100% 100% Yes 1
4 3 5 6 7 8 9 10 11 12 13 14 15 16 0 | 1
7/1
100% 100% No 0
19 17 20 21 22 23 24 25 26 27 28 29 30 31 32 | 33
8/1
100% 100% Yes 2
35 34 36 37 38 39 40 41 42 43 44 45 46 47 17 | 19
A
100% 100% No 0
2 | 2
B
100% 100% No 0
2 | 2
===============================================================================
*A:PE-1#

There are no longer planes shared between cards 6 and 8.


If card 7 is configured into group 3, the following is seen.
*A:PE-1# configure card 7 fp hi-bw-mcast-src group 3 alarm
*A:PE-1#
7 2011/10/21 00:35:50.95 UTC MINOR: CHASSIS #2052 Base Mda 6/1
"Class MDA Module : Plane shared by multiple multicast high bandwidth taps"
8 2011/10/21 00:35:50.95 UTC MINOR: CHASSIS #2052 Base Mda 6/2

Advanced Configuration Guide

Page 893

Configuration

"Class MDA Module : Plane shared by multiple multicast high bandwidth taps"
9 2011/10/21 00:35:50.97 UTC MINOR: CHASSIS #2052 Base Mda 7/1
"Class MDA Module : Plane shared by multiple multicast high bandwidth taps"
10 2011/10/21 00:35:50.97 UTC MINOR: CHASSIS #2052 Base Mda 7/2
"Class MDA Module : Plane shared by multiple multicast high bandwidth taps"

*A:PE-1# show system switch-fabric high-bandwidth-multicast


===============================================================================
Switch Fabric
===============================================================================
Cap:
Planes:
Slot/Mda Min Max Hbm Grp Hi | Lo
------------------------------------------------------------------------------6/1
100% 100% Yes 1
4 3 5 6 7 8 9 10 11 12 13 14 15 16 0 | 1
7/1
100% 100% Yes 3
21 20 22 23 24 25 26 27 28 29 30 31 32 33 0 | 1
8/1
100% 100% Yes 2
35 34 36 37 38 39 40 41 42 43 44 45 46 47 17 | 19
A
100% 100% No 0
2 | 2
B
100% 100% No 0
2 | 2
===============================================================================
*A:PE-1#

There are insufficient planes to allow each card/group to have dedicated planes. Planes 0 and 1 are
still shared between cards 6 and 7, generating the associated alarms.
A common example of the use of the hi-bw-mcast-src command would be when cards 6 and 8
have uplink ports on which high bandwidth multicast channels could be received. It would be
desired to have these cards use different planes. To achieve this, card 7 could be configured into
group 1, as follows.
*A:PE-1# configure card 7 fp hi-bw-mcast-src group 1 alarm
*A:PE-1# show system switch-fabric high-bandwidth-multicast
===============================================================================
Switch Fabric
===============================================================================
Cap:
Planes:
Slot/Mda Min Max Hbm Grp Hi | Lo
------------------------------------------------------------------------------6/1
100% 100% Yes 1
4 3 5 6 7 8 9 10 11 12 13 14 15 16 0 | 1
7/1
100% 100% Yes 1
4 3 5 6 7 8 9 10 11 12 13 14 15 16 0 | 1
8/1
100% 100% Yes 2
35 34 36 37 38 39 40 41 42 43 44 45 46 47 17 | 19
A
100% 100% No 0
2 | 2
B
100% 100% No 0
2 | 2
===============================================================================
*A:PE-1#

Now it can be seen that card 7 shares the same planes as card 6, but more importantly card 6 has
no planes in common with card 8.

Page 894

Advanced Configuration Guide

Ingress Multicast Path Management

Note that when traffic is received on card 6, it will also be seen on the same plane (not path) on
card 7. In the example below, traffic can be seen on plane 4 which is used by both cards 6 and 7,
but only card 6 has non-zero InUseBW path capacity.
*A:PE-1# tools dump mcast-path-mgr cpm
McPathMgr[6][0]: 0xf33b0a00
PATH:
Type SGs
InUseBW
AvailBW
TotalBw
P
2
9707
P
1
0
...
McPathMgr[7][0]: 0xf33b3198
PATH:
Type SGs
InUseBW
AvailBW
TotalBw
P
1
0
P
1
0
-

PLANE:
ID
SGs
4
3
3
2

InUseBW
9707
0

AvailBW
1990293
2000000

TotalBw
2000000
2000000

PLANE:
ID
SGs
4
3
3
2

InUseBW
9707
0

AvailBW
1990293
2000000

TotalBw
2000000
2000000

When IMPM managed traffic is received on SAPs (in an IES, VPLS or VPRN service) it can be
seen against a specific queue counter (Off. Managed) in the SAP stats. The following output
shows where sap 7/2/1:3 belongs to a VPLS service using igmp-snooping. A similar counter is not
available for policer statistics.
*A:PE-1# show service id 2 sap 7/2/1:3 stats
===============================================================================
Service Access Points(SAP)
===============================================================================
------------------------------------------------------------------------------Sap per Queue stats
------------------------------------------------------------------------------Packets
Octets
Ingress Queue 1 (Unicast) (Priority)
Off. HiPrio
: 0
0
Off. LoPrio
: 0
0
Dro. HiPrio
: 0
0
Dro. LoPrio
: 0
0
For. InProf
: 0
0
For. OutProf
: 0
0
Ingress Queue 11 (Multipoint) (Priority)
Off. HiPrio
: 0
Off. LoPrio
: 0
Off. Managed
: 149410
Dro. HiPrio
: 0
Dro. LoPrio
: 0
For. InProf
: 149410
For. OutProf
: 0

0
0
209771640
0
0
209771640
0

Egress Queue 1
For. InProf
: 0
0
For. OutProf
: 0
0
Dro. InProf
: 0
0
Dro. OutProf
: 0
0
===============================================================================
*A:PE-1#

Advanced Configuration Guide

Page 895

Configuration

IOM1/2 Specific Output


The system is configured with the following cards and is in chassis mode a. As can be seen, an
IOM2 is in slot 5.
A:PE-1# show card
===============================================================================
Card Summary
===============================================================================
Slot
Provisioned
Equipped
Admin
Operational
Comments
Card-type
Card-type
State
State
------------------------------------------------------------------------------5
iom2-20g
iom2-20g
up
up
6
iom3-xp
iom3-xp
up
up
7
imm8-10gb-xfp
imm8-10gb-xfp
up
up
8
iom3-xp
iom3-xp
up
up
A
sfm4-12
sfm4-12
up
up/active
B
sfm4-12
sfm4-12
up
up/standby
===============================================================================
A:PE-1#

IMPM is enabled on MDA 1 and 2 of the IOM2 in slot 5, with a primary, secondary and ancillary
path.
A:PE-1# show mcast-management mda
===============================================================================
MDA Summary
===============================================================================
S/C Policy
Type
In-use-Bw
Admin
------------------------------------------------------------------------------5/1 default
Primary
0 Kbps
up
default
Secondary
0 Kbps
up
default
Ancillary
0 Kbps
up
5/2 default
Primary
0 Kbps
up
default
Secondary
0 Kbps
up
default
Ancillary
0 Kbps
up
6/2 default
Primary
0 Kbps
down
default
Secondary
0 Kbps
down
default
Ancillary
0 Kbps
down
7/1 default
Primary
0 Kbps
down
default
Secondary
0 Kbps
down
default
Ancillary
0 Kbps
down
7/2 default
Primary
0 Kbps
down
default
Secondary
0 Kbps
down
default
Ancillary
0 Kbps
down
8/2 default
Primary
0 Kbps
down
default
Secondary
0 Kbps
down
default
Ancillary
0 Kbps
down
===============================================================================
A:PE-1#

Page 896

Advanced Configuration Guide

Ingress Multicast Path Management

The path/plane usage can be shown.


*A:PE-1# show system switch-fabric high-bandwidth-multicast
===============================================================================
Switch Fabric
===============================================================================
Cap:
Planes:
Slot/Mda Min Max Hbm Grp Hi | Lo
------------------------------------------------------------------------------5/1
100% 100% No 0
1 | 0
5/2
100% 100% No 0
4 | 3
6/1
100% 100% No 0
6 5 7 8 9 10 11 12 13 14 15 0 1 3 4 | 5
7/1
100% 100% No 0
7 6 8 9 10 11 12 13 14 15 0 1 3 4 5 | 6
8/1
100% 100% No 0
8 7 9 10 11 12 13 14 15 0 1 3 4 5 6 | 7
A
100% 100% No 0
2 | 2
B
100% 100% No 0
2 | 2
===============================================================================
*A:PE-1#

*A:PE-1# tools dump mcast-path-mgr cpm


McPathMgr[5][0]: 0xf33b0a00
PATH:
Type SGs
InUseBW
AvailBW
TotalBw
P
1
0
2000000
2000000
S
1
0
1500000
1500000
A
0
0
5000000
5000000
B
0
0
McPathMgr[5][1]: 0xf33b3198
PATH:
Type SGs
InUseBW
AvailBW
TotalBw
P
1
0
2000000
2000000
S
1
0
1500000
1500000
A
0
0
5000000
5000000
B
0
0
*A:PE-1#

PLANE:
ID
SGs
1
1
0
1
-

InUseBW
0
0
-

AvailBW
2000000
1800000
-

TotalBw
2000000
1800000
-

PLANE:
ID
SGs
4
1
3
1
-

InUseBW
0
0
-

AvailBW
2000000
1800000
-

TotalBw
2000000
1800000
-

The path range limit alarm thresholds for the ancillary path are

Full: less than 2% capacity is available

Not full: more than 4% of the path capacity is available.

A single channel (239.255.0.1) is now sent into interface int-IOM2 on port 5/2/1 with static IGMP
joins on interfaces int-IMM8, int-IOM3-1 and int-IOM3-2. The current forwarding rate can be
seen.
*A:PE-1# show router pim group 239.255.0.1 detail
===============================================================================
PIM Source Group ipv4
===============================================================================
Group Address
: 239.255.0.1
Source Address
: 172.16.1.1
RP Address
: 192.0.2.1
Flags
: spt, rpt-prn-des
Type
: (S,G)
MRIB Next Hop
: 172.16.1.1

Advanced Configuration Guide

Page 897

Configuration

MRIB Src Flags


Up Time

: direct
: 0d 00:07:45

Keepalive Timer Exp: 0d 00:02:44


Resolved By
: rtable-u

Up JP State
Up JP Rpt

: Joined
: Pruned

Up JP Expiry
: 0d 00:00:00
Up JP Rpt Override : 0d 00:00:00

Register State
: Pruned
Reg From Anycast RP: No

Register Stop Exp

: 0d 00:00:32

Rpf Neighbor
: 172.16.1.1
Incoming Intf
: int-IOM2
Outgoing Intf List : int-IMM8, int-IOM3-1, int-IOM3-2
Curr Fwding Rate
: 9734.8 kbps
Forwarded Packets : 591874
Discarded Packets : 0
Forwarded Octets
: 817969868
RPF Mismatches
: 0
Spt threshold
: 0 kbps
ECMP opt threshold : 7
Admin bandwidth
: 1 kbps
-------------------------------------------------------------------------------

As there are only 3 ( <4) DFCs, the ancillary path is used.


*A:PE-1# show mcast-management channel
===============================================================================
Multicast Channels
===============================================================================
Legend : D - Dynamic E - Explicit
===============================================================================
Source Address
Slot/Cpx Current-Bw Path
D/E
Group Address
Highest-Bw Plane
------------------------------------------------------------------------------172.16.1.1
5/2
9729
Ancillary D
239.255.0.1
9740
===============================================================================
Multicast Channels : 1
===============================================================================
*A:PE-1#

*A:PE-1# show mcast-management channel detail


===============================================================================
Multicast Channels
===============================================================================
------------------------------------------------------------------------------Source Address
: 172.16.1.1
Group Address
: 239.255.0.1
------------------------------------------------------------------------------Slot/Complex
: 5/2
Current Bw
: 9729 kbps
Dynamic/Explicit
: Dynamic
Current Path
: Ancillary
Oper Admin Bw
: 0 kbps
Current Plane
: N/A
Ing last highest
: 9740
Preference
: 0
Black-hole rate
: None
Ing sec highest
: 9740
Time remaining
: 27 seconds
Blackhole
: No
===============================================================================
Multicast Channels : 1
===============================================================================
*A:PE-1#

Page 898

Advanced Configuration Guide

Ingress Multicast Path Management

If another join caused this traffic to be switched via an additional DFC, the system would place the
channel on the primary path.
The ancillary path being used can also be seen as follows.
*A:PE-1# tools dump mcast-path-mgr cpm
McPathMgr[5][0]: 0xf33b0a00
PATH:
Type SGs
InUseBW
AvailBW
TotalBw
P
1
0
2000000
2000000
S
1
0
1500000
1500000
A
0
0
5000000
5000000
B
0
0
McPathMgr[5][1]: 0xf33b3198
PATH:
Type SGs
InUseBW
AvailBW
TotalBw
P
1
0
2000000
2000000
S
1
0
1500000
1500000
A
1
19480
4980520
5000000
B
0
0
*A:PE-1#

PLANE:
ID
SGs
1
1
0
1
-

InUseBW
0
0
-

AvailBW
2000000
1800000
-

TotalBw
2000000
1800000
-

PLANE:
ID
SGs
4
1
3
1
-

InUseBW
0
0
-

AvailBW
2000000
1800000
-

TotalBw
2000000
1800000
-

Note that the bandwidth shown on the ancillary path on the second MDA is approximately two
times that of the ingress traffic, this matches the algorithm described earlier for the ancillary path.
This can also be seen in the next output, there is the original channel traffic plus two replications
(Repl).
*A:PE-1# tools dump mcast-path-mgr channels
===============================================================================
Slot: 5 Complex: 0
===============================================================================
Source address
CurrBw
Plane PathType Path Pref
Group address
PathBw
Repl Exp
BlkHoleBw
------------------------------------------------------------------------------Unmanaged traffic
0
1
primary
0
8
slot: 5 cmplx: 0 path: 0
0
0
none
0
Unmanaged traffic
0
0
secondary 1
8
slot: 5 cmplx: 0 path: 1
0
0
none
0
===============================================================================
Slot: 5 Complex: 1
===============================================================================
Source address
CurrBw
Plane PathType Path Pref
Group address
PathBw
Repl Exp
BlkHoleBw
------------------------------------------------------------------------------172.16.1.1
9740
48
ancillary 16
0
239.255.0.1
19480
2
none
0
Unmanaged traffic
0
4
primary
0
8
slot: 5 cmplx: 1 path: 0
0
0
none
0
Unmanaged traffic
0
3
secondary 1
8
slot: 5 cmplx: 1 path: 1
0
0
none
0
*A:PE-1#

Advanced Configuration Guide

Page 899

Conclusion

Conclusion
This section has described the configuration of Ingress Multicast Path Management which
optimizes IPv4 and IPv6 multicast capacity to achieve the maximum system-wide IP multicast
throughput. It can be used for both routed IPv4/IPv6 and VPLS (IGMP and PIM) snooped IPv4
multicast groups, which usually relate to the distribution of IP TV channels.

Page 900

Advanced Configuration Guide

Inter-Area TE Point-to-Point LSPs

In This Chapter
This section describes inter-area TE point-to-point LSP configurations.
Topics in this section include:

Applicability on page 902

Summary on page 903

Overview on page 905

Configuration on page 907

Conclusion on page 925

Advanced Configuration Guide

Page 901

Applicability

Applicability
Inter-Area Traffic Engineering (TE) point-to-point (P2P) LSPs are supported on all 7x50
platforms, including the 7710 and 7750 SR-c4/12. This feature is supported on all IOM/IMM
types. The configuration was tested on release 11.0R4.

Page 902

Advanced Configuration Guide

Inter-Area TE Point-to-Point LSPs

Summary
MPLS TE is implemented on a wide scale in current ISP networks to steer traffic across the
backbone to facilitate efficient use of available bandwidth between the routers and to guarantee
fast convergence in case a link or node fails.
Previously, the MPLS TE designs allowed for TE LSPs that are confined to only a single IGP area/
level. This is due to the fact that the head-end has information in the TE database of only the local
area (OSPF) or level (ISIS).

Inter-Area TE LSP Based On Explicit Route Expansion


To be able to support Inter Area MPLS traffic engineering, the design needs to be extended. InterArea TE LSP based on Explicit route Object (ERO) expansion allows for the head-end to calculate
the ERO path within its own area/level and keep the remaining ABRs of other areas/levels as loose
hops in the ERO path. On receiving a PATH message with a loose hop ERO, based on local
configuration each ABR does a partial Constrained Shortest Path First (CSPF) calculation to the
next ABR or full CSPF to reach the final destination.
Automatic selection of ABRs is supported, in this way the head-end node can work with an empty
primary path. When the to field of an LSP definition is in a different area/level than the head-end
node, CSPF will automatically compute the segment to the exit ABR router which advertised the
prefix and which is currently the best path for resolving the prefix in Route Table Manager (RTM).

ABR Protection
Link and Node protection within the respective areas are supported through the TE capabilities of
the IGP and RSVP in each area. To support ABR node protection, a bypass is required from the
Point of Local Repair (PLR; node prior to ABR) to the Merge Point (MP; next-hop node to ABR).
Two methods are possible: dynamic ABR protection and static ABR protection. Static ABR
protection uses Manual Bypass Tunnels (MBTs), statically configured by the operator between
PLR and MP.
For dynamic ABR protection, node ID propagation and signaling of an Exclude Route (XRO)
object in RSVP PATH messages must both be supported.
Since the description of the RRO Node ID sub-object in RFC 4561 (Definition of a Record Route
Object (RRO) Node-Id Sub-Object) is not clear about the format of the included node-address (S),
interface-address (I) and label (L), the system is programmed to understand multiple formats: IL,
SL, ISL, SIL, SLI, ILSL and SLIL. The system uses the SLIL (node-adddress, label, interfaceaddress, label) format to include the node-ID itself.

Advanced Configuration Guide

Page 903

Summary

XRO object inclusion (RFC 4874, Exclude Routes - Extension to Resource ReserVation ProtocolTraffic Engineering) in bypass RSVP PATH messages is required to exclude the protected ABR
from the bypass path. The XRO object is filled in with ABRs system IP address.

Page 904

Advanced Configuration Guide

Inter-Area TE Point-to-Point LSPs

Overview
AREA 0

P-4
AREA 1

192.168.24.0/30 .2

PE-2

.2

192.0.2.2 .1

.1

192.168.48.0/30

.1

192.168.34.0/30

192.168.23.0/30

.2

192.168.13.0/30

.2

.2
.1

192.168.36.0/30

192.168.57.0/30

192.168.109.0/30

.2
192.168.79.0/30

P-7

.2
.1

.1

192.168.67.0/30

.2 192.0.2.6 .1

.2 192.0.2.3 .1

.1

.2

P-6
.1

192.0.2.9
.2

192.168.68.0/30 192.168.78.0/30

192.168.26.0/30

PE-3

.1

192.168.105.0/30

192.0.2.8
.2

.1

PE-9
.2

.1

192.168.58.0/30

P-8

.2

192.168.46.0/30

192.0.2.1

192.168.59.0/30

192.0.2.5 .1

.1

.1

.1

.1

PE-1

.2

192.0.2.4 .1

192.168.12.0/30 .2

AREA 2

P-5

192.168.45.0/30

.2 192.0.2.7 .1

.2

PE-10

.2

192.168.107.0/30
.2 192.0.2.10
al_0352

Figure 51: Inter-Area TE LSP Setup

The setup in this section contains 10 nodes in three areas. Figure 51 shows the physical topology
of the setup.

AREA 0

P-4
AREA 1

.2

PE-2

192.0.2.4 .1

.2

.1

PE-1

.1

.2

192.0.2.2 .1

AREA 2

P-5
.2

1000

PE-9

192.0.2.5 .1

.1

.1

.1

.1

.2

192.0.2.9

.1

.1

.2

.1

.2

192.0.2.1

P-8

.2

192.0.2.8
.2

.1

.2

10

PE-3

.2

.2
.1

.2

P-6
.1

.2 192.0.2.6 .1

.2 192.0.2.3 .1

.2
.1
1000

P-7
.1

.2 192.0.2.7 .1

.2

.2

PE-10

.2 192.0.2.10
al_0353

Figure 52: Inter-Area TE LSP Path

Advanced Configuration Guide

Page 905

Overview

Figure 52 shows the LSP path intended to be setup through the network. An empty MPLS path is
used. At the head-end node (PE-1), the destination address (PE-10) is learned via ABR node P-4
and ABR node P-5.

Page 906

Advanced Configuration Guide

Inter-Area TE Point-to-Point LSPs

Configuration
The assumption is made that following base configuration has been implemented on the PEs:

Cards, MDAs and ports configured

Interfaces configured

IGP areas configured and converged

Traffic Engineering configured for the IGP

MPLS and RSVP configured on all links in the network

OSPF or ISIS can be configured as the IGP; OSPF is used here.


*A:PE-1# show router ospf opaque-database
===============================================================================
OSPF Opaque Link State Database (Type : All)
===============================================================================
Type Id
Link State Id
Adv Rtr Id
Age Sequence
Cksum
------------------------------------------------------------------------------Area 0.0.0.1
1.0.0.1
192.0.2.1
357 0x800000ef 0xb622
Area 0.0.0.1
1.0.0.2
192.0.2.1
619 0x800001dc 0xc193
Area 0.0.0.1
1.0.0.3
192.0.2.1
461 0x800001dd 0xe42
Area 0.0.0.1
1.0.0.1
192.0.2.2
1434 0x800000f5 0xae22
Area 0.0.0.1
1.0.0.2
192.0.2.2
498 0x800001e8 0x85c3
Area 0.0.0.1
1.0.0.3
192.0.2.2
285 0x800001e3 0x92a2
Area 0.0.0.1
1.0.0.4
192.0.2.2
428 0x800001e7 0xd854
Area 0.0.0.1
1.0.0.5
192.0.2.2
713 0x800001e9 0x7ba8
Area 0.0.0.1
1.0.0.1
192.0.2.3
424 0x800000f1 0xba18
Area 0.0.0.1
1.0.0.2
192.0.2.3
763 0x800001e3 0xcb7f
Area 0.0.0.1
1.0.0.3
192.0.2.3
183 0x800001e5 0x6ac8
Area 0.0.0.1
1.0.0.4
192.0.2.3
294 0x800001e4 0x6fab
Area 0.0.0.1
1.0.0.5
192.0.2.3
763 0x800001ea 0xa04
Area 0.0.0.1
1.0.0.1
192.0.2.4
4
0x800000ed 0xc60e
Area 0.0.0.1
1.0.0.5
192.0.2.4
1395 0x800001e1 0x9a97
Area 0.0.0.1
1.0.0.6
192.0.2.4
1030 0x800001e1 0x3dde
Area 0.0.0.1
1.0.0.1
192.0.2.6
1367 0x800000ee 0xcc03
Area 0.0.0.1
1.0.0.5
192.0.2.6
535 0x800001e2 0xbd58
Area 0.0.0.1
1.0.0.6
192.0.2.6
709 0x800001de 0xf1f
------------------------------------------------------------------------------No. of Opaque LSAs: 19
===============================================================================

The output above shows the opaque database of PE-1. The information is only about routers that
are part of area 0.0.0.1. PE-1 cannot calculate an end-to-end CSPF path to node PE-10 since this
would require TE topology information from area 0.0.0.0 and area 0.0.0.2.
Each node announces its router-ID and each attached link that is part of that area, hence the 19
opaque LSAs in area 0.0.0.1.
Note in Figure 52 that the LSP should pass through node PE-3 and node P-8. In order to prefer a
dynamic path from PE-1 to P-4 via PE-3 rather than through PE-2, it is necessary to configure on

Advanced Configuration Guide

Page 907

Configuration

PE-1 a lower IGP metric on the interface to PE-3 (the default metric is derived from the interface
speed; in this case the metric is 100 by default).
*A:PE-1>config>router>ospf# area 1 interface "int-PE-1-PE-3" metric 10

Similarly, in the core, the IGP metric between P-4 <=> P-5 and P-6 <=> P-7 is increased to force the
LSP to pass the core P-8 node.
*A:P-4>config>router>ospf# area 0 interface "int-P-4-P-5" metric 1000
*A:P-6>config>router>ospf# area 0 interface "int-P-6-P-7" metric 1000

Page 908

Advanced Configuration Guide

Inter-Area TE Point-to-Point LSPs

MPLS Path Configuration


Since automatic ABR selection is performed, an empty MPLS path is enough on the head-end
node PE-1. Using an empty MPLS path will ease the provisioning process and brings consistency
since this empty MPLS path can be used for both intra and inter-area/level type LSPs.
*A:PE-1# configure router mpls
*A:PE-1>config>router>mpls# path "path-PE-10" no shutdown

MPLS LSP Configuration


Configure an LSP on PE-1 to PE-10 and include the previously created MPLS path as primary
path. Enable CSPF and Fast Reroute (FRR) facility on the LSP.
*A:PE-1>config>router>mpls#
*A:PE-1>config>router>mpls#
*A:PE-1>config>router>mpls#
*A:PE-1>config>router>mpls#
*A:PE-1>config>router>mpls#
*A:PE-1>config>router>mpls#

lsp
lsp
lsp
lsp
lsp

"LSP-PE-1-PE-10"
"LSP-PE-1-PE-10"
"LSP-PE-1-PE-10"
"LSP-PE-1-PE-10"
"LSP-PE-1-PE-10"

to 192.0.2.10
cspf
fast-reroute facility
primary "path-PE-10" no shutdown
no shutdown

At this stage the LSP is in an operational Down state with a failure code of
noCspfRouteToDestination.
In order to get around the intra-area CSPF confinement, enable the ERO-expansion feature on all
possible ABR nodes.
*A:P-4# configure router mpls cspf-on-loose-hop
*A:P-6# configure router mpls cspf-on-loose-hop
*A:P-7# configure router mpls cspf-on-loose-hop
*A:P-5# configure router mpls cspf-on-loose-hop

Note that cspf-on-loose-hop is only required if FRR or TE parameters are configured on the LSP.
If any of these parameters is configured on the LSP and one of the ABRs along the path is not
configured with cspf-on-loose-hop, the LSP will stay operationally down with Failure Code:
badNode and an indication of the interface address of the Failure Node.
*A:PE-1# show
...
From
:
Adm State
:

Failure Code:

router mpls lsp "LSP-PE-1-PE-10" path detail


192.0.2.1
Up

To
Oper State

: 192.0.2.10
: Down

badNode

Failure Node: 192.168.24.2

The LSP path can also contain other strict and/or loose hops. Note however that cspf-on-loose-hop
must be configured under MPLS whenever loose hops are configured in the MPLS path. This

Advanced Configuration Guide

Page 909

Configuration

command is needed to trigger ERO expansion and is only required for inter-area LSPs on all
possible ABR nodes and all nodes not belonging to the ingress area (namely, the same area as the
iLER) which have a loose hop reference in the MPLS path. However, for simplicity it can be
configured on all nodes without having a negative effect.
The following trace shows the ERO calculation on the head-end to the first ABR.
*A:PE-1# debug router rsvp packet path detail
2 2013/08/20 16:29:20.89 UTC MINOR: DEBUG #2001 Base RSVP
"RSVP: PATH Msg
Send PATH From:192.0.2.1, To:192.0.2.10
TTL:255, Checksum:0x88f3, Flags:0x0
Session
- EndPt:192.0.2.10, TunnId:2, ExtTunnId:192.0.2.1
SessAttr
- Name:LSP-PE-1-PE-10::path-PE-10
SetupPri:7, HoldPri:0, Flags:0x17
RSVPHop
- Ctype:1, Addr:192.168.13.1, LIH:3
TimeValue - RefreshPeriod:30
SendTempl - Sender:192.0.2.1, LspId:56852
SendTSpec - Ctype:QOS, CDR:0.000 bps, PBS:0.000 bps, PDR:infinity
MPU:20, MTU:1564
LabelReq
- IfType:General, L3ProtID:2048
RRO
- IpAddr:192.168.13.1, Flags:0x0
ERO
- IPv4Prefix 192.168.13.2/32, Strict
IPv4Prefix 192.168.34.2/32, Strict
IPv4Prefix 192.0.2.10/32, Loose
FRRObj
- SetupPri:7, HoldPri:0, HopLimit:16, BW:0.000 bps, Flags:0x2
ExcAny:0x0, IncAny:0x0, IncAll:0x0
"

On the P-4 ABR the ERO is expanded to include the nodes of area 0.0.0.0 of which P-4 is also
part. The RRO contains all the hops the PATH message has passed so far.
*A:P-4# debug router rsvp packet path detail
11 2013/08/20 08:54:40.97 UTC MINOR: DEBUG #2001 Base RSVP
"RSVP: PATH Msg
Send PATH From:192.0.2.1, To:192.0.2.10
TTL:253, Checksum:0x176f, Flags:0x0
Session
- EndPt:192.0.2.10, TunnId:2, ExtTunnId:192.0.2.1
SessAttr
- Name:LSP-PE-1-PE-10::path-PE-10
SetupPri:7, HoldPri:0, Flags:0x17
RSVPHop
- Ctype:1, Addr:192.168.48.1, LIH:4
TimeValue - RefreshPeriod:30
SendTempl - Sender:192.0.2.1, LspId:56852
SendTSpec - Ctype:QOS, CDR:0.000 bps, PBS:0.000 bps, PDR:infinity
MPU:20, MTU:1564
LabelReq
- IfType:General, L3ProtID:2048
RRO
- IpAddr:192.168.48.1, Flags:0x0
IpAddr:192.168.34.1, Flags:0x0
IpAddr:192.168.13.1, Flags:0x0
ERO
- IPv4Prefix 192.168.48.2/32, Strict
IPv4Prefix 192.168.58.1/32, Strict
IPv4Prefix 192.0.2.10/32, Loose
FRRObj
- SetupPri:7, HoldPri:0, HopLimit:16, BW:0.000 bps, Flags:0x2
ExcAny:0x0, IncAny:0x0, IncAll:0x0
"

Page 910

Advanced Configuration Guide

Inter-Area TE Point-to-Point LSPs

Finally, the P-5 ABR will expand the ERO to the final destination PE-10:
*A:P-5# debug router rsvp packet path detail
4 2013/08/20 08:25:04.70 UTC MINOR: DEBUG #2001 Base RSVP
"RSVP: PATH Msg
Send PATH From:192.0.2.1, To:192.0.2.10
TTL:251, Checksum:0xbfcd, Flags:0x0
Session
- EndPt:192.0.2.10, TunnId:2, ExtTunnId:192.0.2.1
SessAttr
- Name:LSP-PE-1-PE-10::path-PE-10
SetupPri:7, HoldPri:0, Flags:0x17
RSVPHop
- Ctype:1, Addr:192.168.105.1, LIH:5
TimeValue - RefreshPeriod:30
SendTempl - Sender:192.0.2.1, LspId:56852
SendTSpec - Ctype:QOS, CDR:0.000 bps, PBS:0.000 bps, PDR:infinity
MPU:20, MTU:1564
LabelReq
- IfType:General, L3ProtID:2048
RRO
- IpAddr:192.168.105.1, Flags:0x0
IpAddr:192.168.58.2, Flags:0x0
IpAddr:192.168.48.1, Flags:0x0
IpAddr:192.168.34.1, Flags:0x0
IpAddr:192.168.13.1, Flags:0x0
ERO
- IPv4Prefix 192.168.105.2/32, Strict
FRRObj
- SetupPri:7, HoldPri:0, HopLimit:16, BW:0.000 bps, Flags:0x2
ExcAny:0x0, IncAny:0x0, IncAll:0x0
"

The MPLS LSP is now operational up and the LSP path can be shown in detail on the head-end,
PE-1:
*A:PE-1# show router mpls lsp "LSP-PE-1-PE-10" path detail
===============================================================================
MPLS LSP LSP-PE-1-PE-10 Path (Detail)
===============================================================================
Legend :
@ - Detour Available
# - Detour In Use
b - Bandwidth Protected
n - Node Protected
s - Soft Preemption
S - Strict
L - Loose
A - ABR
===============================================================================
------------------------------------------------------------------------------LSP LSP-PE-1-PE-10 Path path-PE-10
------------------------------------------------------------------------------LSP Name
: LSP-PE-1-PE-10
Path LSP ID : 56852
From
: 192.0.2.1
To
: 192.0.2.10
Adm State
: Up
Oper State : Up
Path Name
: path-PE-10
Path Type
: Primary
Path Admin : Up
Path Oper
: Up
OutInterface: 1/1/1
Out Label
: 131071
Path Up Time: 0d 01:05:21
Path Dn Time: 0d 00:00:00
Retry Limit : 0
Retry Timer : 30 sec
RetryAttempt: 0
NextRetryIn : 0 sec
Adspec
CSPF
Least Fill
FRR

:
:
:
:

Disabled
Enabled
Disabled
Enabled

Advanced Configuration Guide

Oper
Oper
Oper
Oper

Adspec :
CSPF
:
LeastF*:
FRR
:

Disabled
Enabled
Disabled
Enabled

Page 911

Configuration

FRR NodePro*:
FR Hop Limit:
FR Prop Adm*:
Prop Adm Grp:
Inter-area :

Enabled
16
Disabled
Disabled
True

Oper
Oper
Oper
Oper

FRR NP :
FRHopL*:
FRProp*:
PropAG :

Enabled
16
Disabled
Disabled

Neg MTU
:
Bandwidth
:
Hop Limit
:
Record Route:
Record Label:
SetupPriori*:
Hold Priori*:
Class Type :
Backup CT
:
MainCT Retry:
Rem
:
MainCT Retry:
Limit
:
Include Grps:
None
Exclude Grps:
None

1560
No Reservation
255
Record
Record
7
0
0
None
n/a

Oper
Oper
Oper
Oper
Oper
Oper
Oper
Oper

MTU
:
Bw
:
HopLim*:
RecRou*:
RecLab*:
SetupP*:
HoldPr*:
CT
:

1560
0 Mbps
255
Record
Record
7
0
0

0
Oper InclGr*:
None
Oper ExclGr*:
None

Adaptive
: Enabled
Oper Metric : 110
Preference : n/a
Path Trans : 21
CSPF Queries: 11
Failure Code: noError
Failure Node: n/a
ExplicitHops:
No Hops Specified
Actual Hops :
192.168.13.1 (192.0.2.1) @ n
Record Label
: N/A
-> 192.168.13.2 (192.0.2.3) @ n
Record Label
: 131071
-> 192.168.34.2 (192.0.2.4) @ n
Record Label
: 131071
-> 192.0.2.8 (192.0.2.8) @ n
Record Label
: 131070
-> 192.168.48.2 @ n
Record Label
: 131070
-> 192.0.2.5 (192.0.2.5) @
Record Label
: 131071
-> 192.168.58.1 @
Record Label
: 131071
-> 192.0.2.10 (192.0.2.10)
Record Label
: 131071
-> 192.168.105.2
Record Label
: 131071
ComputedHops:
192.168.13.1(S)
-> 192.168.13.2(S)
-> 192.168.34.2(SA)
-> 192.0.2.10(L)
ResigEligib*: False
LastResignal: n/a
CSPF Metric : 110
===============================================================================
* indicates that the corresponding row element may have been truncated.

Page 912

Advanced Configuration Guide

Inter-Area TE Point-to-Point LSPs

ABR Node Protection


At this stage, the LSP is configured with facility FRR protection; link and node protection will be
offered within each area. Dynamic ABR node protection requires the setup of a bypass tunnel
from the PLR (node just upstream of the ABR) to the MP (node just downstream of the ABR).
Two things are required for this:
Firstly, the PLR node (part of area x) needs to know the system IP address of MP node (part of
area y) to setup the bypass. For this reason, the node-ID of the MP is included in the RESV
message so that the PLR can link the manual bypass tunnel to the primary path to protect the ABR.
Secondly, the other ABR node receiving the RSVP bypass PATH message for the protected ABR
needs to do an ERO expansion towards MP node. For this reason, the XRO object is included in
the RSVP bypass PATH message, containing the node-ID of the protected ABR. As an example, a
bypass PATH message is shown below on node PE-3.
The XRO object includes the system IP address of the protected ABR node (P-4) and the ERO
object has MP node (P-8) as loose destination:
*A:PE-3# debug router rsvp packet path detail
13 2013/08/20 07:56:10.87 UTC MINOR: DEBUG #2001 Base RSVP
"RSVP: PATH Msg
Send PATH From:192.0.2.3, To:192.0.2.8
TTL:17, Checksum:0x907f, Flags:0x0
Session
- EndPt:192.0.2.8, TunnId:61445, ExtTunnId:192.0.2.3
SessAttr
- Name:bypass-node192.0.2.4
SetupPri:7, HoldPri:0, Flags:0x2
RSVPHop
- Ctype:1, Addr:192.168.36.1, LIH:3
TimeValue - RefreshPeriod:30
SendTempl - Sender:192.0.2.3, LspId:10
SendTSpec - Ctype:QOS, CDR:0.000 bps, PBS:0.000 bps, PDR:infinity
MPU:20, MTU:1564
LabelReq
- IfType:General, L3ProtID:2048
RRO
- IpAddr:192.168.36.1, Flags:0x0
ERO
- IPv4Prefix 192.168.36.2/32, Strict
IPv4Prefix 192.0.2.8/32, Loose
XRO
- IPv4Prefix: 192.0.2.4/32, Attribute: Node, LBit: Exclude
AdSpec
- General BreakBit:0, NumISHops:0, PathBwEstimate:0
MinPathLatency:4294967295, CompPathMTU:1564
Controlled BreakBit:0
"

Advanced Configuration Guide

Page 913

Configuration

Node-ID Inclusion in the RESV Message


P-8 will be the MP for the bypass of ABR P-4 and PE-10 will be the MP for the bypass of ABR P5. So P-8 and PE-10 need to include their node-ID in the RESV message, inside the Record Route
Object (RRO).
*A:P-8# configure router rsvp node-id-in-rro include
*A:PE-10# configure router rsvp node-id-in-rro include

The default is node-id-in-rro exclude. As an example, the RESV message received on PLR node
(PE-3) is shown below. The RRO contains the MP node (P-8) information in SLIL format:
*A:PE-3# debug router rsvp packet resv detail
18 2013/08/20 08:08:05.39 UTC MINOR: DEBUG #2001 Base RSVP
"RSVP: RESV Msg
Send RESV From:192.168.13.2, To:192.168.13.1
TTL:255, Checksum:0x31f7, Flags:0x0
Session
- EndPt:192.0.2.10, TunnId:2, ExtTunnId:192.0.2.1
RSVPHop
- Ctype:1, Addr:192.168.13.2, LIH:3
TimeValue - RefreshPeriod:30
Style
- SE
FlowSpec
- Ctype:QOS, CDR:0.000 bps, PBS:0.000 bps, PDR:infinity
MPU:20, MTU:1560, RSpecRate:0, RSpecSlack:0
FilterSpec - Sender:192.0.2.1, LspId:56852, Label:131071
RRO
-
SystemIp:192.0.2.8, Flags:0x29
Label:131070, Flags:0x1
InterfaceIp:192.168.48.2, Flags:0x9
Label:131070, Flags:0x1

""

Page 914

Advanced Configuration Guide

Inter-Area TE Point-to-Point LSPs

Bypass Configuration For ABR Protection


Since dynamic ABR protection is supported and used in this example, no explicit MBTs are
configured to protect the ABRs. Each PLR first checks if an MBT tunnel exists between PLR and
MP matching the constraints and protecting the ABR. If no MBT is available, the PLR will signal
a bypass tunnel in a dynamic way towards MP node.
Figure 53 shows the two dynamic ABR node protections that are signalled for this LSP.

AREA 0

P-4
AREA 1

PE-2

PE-1

.1

.2

192.0.2.2 .1
.1

.2

192.0.2.4 .1

.2

AREA 2

P-5

.2

PE-9

192.0.2.5 .1

.1

.1

.1

.2

.1

192.0.2.9

.1

.2

.1

.2

192.0.2.1

P-8

.1

.2

MP 192.0.2.8 PLR
.2

.1

PE-3

.2

PLR .1
.2 192.0.2.3 .1

.2

.2

P-6
.1

.2 192.0.2.6 .1

.2

.2
.1

P-7
.1

.2 192.0.2.7 .1

.2

.2

PE-10

MP
.2 192.0.2.10
al_0354

Figure 53: ABR Protection

Figure 54 shows the complete picture of all the FRR protections and indicates each node/link
protection in the setup.

Advanced Configuration Guide

Page 915

Configuration

AREA 0

P-4
AREA 1

PE-2

.1

.1

.2

192.0.2.2 .1

PE-1

.2

192.0.2.4 .1

.2

AREA 2

P-5

.2

PE-9

192.0.2.5 .1
3

.1

.1

.1

.1

.2

192.0.2.9

.1

.2

.1

.2

192.0.2.1

P-8

.1

.2

192.0.2.8
.2

.1

PE-3

.2

.2
.1

.2 192.0.2.3 .1

.2

P-6
.1

.2 192.0.2.6 .1

.2

.2
.1

P-7

4
.2

.1

.2 192.0.2.7 .1

.2

PE-10

.2 192.0.2.10
al_0355

Figure 54: Protection of All Nodes/Links Along the LSP Path

This can be seen in the detailed show output of the LSP path:
*A:PE-1# show router mpls lsp "LSP-PE-1-PE-10" path detail

LSP Name
: LSP-PE-1-PE-10
Path LSP ID :
From
: 192.0.2.1
To
:
Adm State
: Up
Oper State :
Path Name
: path-PE-10
Path Type
:
Path Admin : Up
Path Oper
:

Inter-area : True

Actual Hops :
192.168.13.1 (192.0.2.1) @ n
(1)
Record Label
-> 192.168.13.2 (192.0.2.3) @ n
(2)
Record Label
-> 192.168.34.2 (192.0.2.4) @ n
(3)
Record Label
-> 192.0.2.8 (192.0.2.8) @ n
(4)
Record Label
-> 192.168.48.2 @ n
(4)
Record Label
-> 192.0.2.5 (192.0.2.5) @
(5)
Record Label
-> 192.168.58.1 @
(5)
Record Label
-> 192.0.2.10 (192.0.2.10)
Record Label
-> 192.168.105.2
Record Label

56852
192.0.2.10
Up
Primary
Up

:
:
:
:
:
:
:
:
:

N/A
131071
131071
131070
131070
131071
131071
131071
131071

Note that there are two entries for P-8, P-5 and PE-10 in the Actual Hops section in the previous
output: one for the interface IP address and one for the system IP address. This is a consequence of
configuring node-id-in-rro include on P-8, P-5 and PE-10.

Page 916

Advanced Configuration Guide

Inter-Area TE Point-to-Point LSPs

Note: The node-id-in-rro include command is not mandatory for this example on ABR node P-5
but to be future save (for example, to cover cases where a new LSP is established in the network
and P-5 acts as an MP node while the corresponding PLR node for that new LSP is in another
area), this RSVP command can be enabled on all possible MP nodes in the network.
The details of the bypass tunnel can be shown with the following command:
*A:PE-3# show router mpls bypass-tunnel protected-lsp detail
===============================================================================
MPLS Bypass Tunnels (Detail)
===============================================================================
------------------------------------------------------------------------------bypass-node192.0.2.4
------------------------------------------------------------------------------To
: 192.0.2.8
State
: Up
Out I/F
: 1/1/4
Out Label
: 131070
Up Time
: 0d 01:41:04
Active Time
: n/a
Reserved BW
: 0 Kbps
Protected LSP Count : 1
Type
: Dynamic
Setup Priority : 7
Hold Priority
: 0
Class Type
: 0
Exclude Node
: 192.0.2.4
Inter-Area
: True
Computed Hops
:
192.168.36.1(S)
Egress Admin Groups : None
-> 192.168.36.2(SA)
Egress Admin Groups : None
-> 192.0.2.8(L)
Egress Admin Groups : None
Actual Hops
:
192.168.36.1 (192.0.2.3)
Record Label
: N/A
-> 192.168.36.2 (192.0.2.6)
Record Label
: 131070
-> 192.0.2.8 (192.0.2.8)
Record Label
: 131069
-> 192.168.68.2
Record Label
: 131069
Protected LSPs LSP Name
: LSP-PE-1-PE-10::path-PE-10
From
: 192.0.2.1
To
Avoid Node/Hop : 192.0.2.4
Downstream Label
Bandwidth
: 0 Kbps

: 192.0.2.10
: 131070

The LSP could be further protected with one or more additional secondary paths, pre-signaled or
not, but this is outside the scope of this example.
When a link or node failure occurs along the LSP path, FRR protection kicks in and end-to-end
path re-optimization is executed: a PATHERR message is forwarded to the head-end. Upon
receiving the PATHERR message the head-end calculates a new path.

Advanced Configuration Guide

Page 917

Configuration

Admin Groups
To support admin-groups for inter-area LSPs, the ingress node (PE-1) must propagate the admingroups within the Session Attribute object (SA) of the PATH message so that the ABRs along the
path receive the Admin Group restrictions they have to take into account when further expanding
the ERO in the PATH message.
In Figure 55 the LSP path avoids the link between P-4 and P-8. This will be done by assigning
admin group red to the link between P-4 and P-8 and then configuring the LSP to exclude the
admin group red.

AREA 0

P-4
AREA 1

.2

PE-2

.1

.1

.2

192.0.2.2 .1

PE-1

1000

192.0.2.4 .1

.2

AREA 2

P-5
.2

PE-9

192.0.2.5 .1

.1

.1

.1

.1

.2

192.0.2.9

.1

.2

.1

.2

192.0.2.1

P-8

.1

.2

192.0.2.8
.2

.1

.2

10

PE-3

.2

.2
.1

.2 192.0.2.3 .1

.2

P-6
.1

.2 192.0.2.6 .1

.2
.1
1000

P-7
.1

.2 192.0.2.7 .1

.2

.2

PE-10

.2 192.0.2.10
al_0356

Figure 55: Admin Group Example

Page 918

Advanced Configuration Guide

Inter-Area TE Point-to-Point LSPs

Admin Group Configuration


On P-4, configure admin group red and assign a group value to it (in the example value 11 is used,
but this can be any value between 0 and 31). Assign admin group red to the link to P-8.
*A:P-4# configure router mpls
*A:P-4>config>router>mpls# admin-group "red" 11
*A:P-4>config>router>mpls# interface "int-P-4-P-8" admin-group "red"

Note that this admin-group configuration is required on all nodes in this example.
*A:Px# configure router mpls admin-group "red" 11

On PE-1, change the LSP configuration as follows:


*A:PE-1>config>router>mpls# info
---------------------------------------------admin-group "red" 11

path "path-PE-10"
no shutdown
exit
lsp "LSP-PE-1-PE-10"
to 192.0.2.10
cspf
exclude "red"
propagate-admin-group
fast-reroute facility
exit
no shutdown
exit
no shutdown
----------------------------------------------

Note the propagate-admin-group command is required to include the admin group properties in
the SA object of the PATH message. Admin-group value is mapped to a 32-bitmap. In this
example, value 11 means that the 12th bit is set, which means in binary 100000000000 or hex
0x800.
*A:PE-1# debug router rsvp packet path detail
48 2013/08/20 18:41:05.89 UTC MINOR: DEBUG #2001 Base RSVP
"RSVP: PATH Msg
Send PATH From:192.0.2.1, To:192.0.2.10
TTL:255, Checksum:0x80db, Flags:0x0
Session
- EndPt:192.0.2.10, TunnId:2, ExtTunnId:192.0.2.1
SessAttr
- Name:LSP-PE-1-PE-10::path-PE-10
SetupPri:7, HoldPri:0, Flags:0x17
Ctype:RA, ExcAny:0x800, IncAny:0x0, IncAll:0x0
RSVPHop
- Ctype:1, Addr:192.168.13.1, LIH:3
TimeValue - RefreshPeriod:30
SendTempl - Sender:192.0.2.1, LspId:56858
SendTSpec - Ctype:QOS, CDR:0.000 bps, PBS:0.000 bps, PDR:infinity

Advanced Configuration Guide

Page 919

Configuration

LabelReq
RRO
ERO

FRRObj

MPU:20, MTU:1564
- IfType:General, L3ProtID:2048
- IpAddr:192.168.13.1, Flags:0x0
- IPv4Prefix 192.168.13.2/32, Strict
IPv4Prefix 192.168.34.2/32, Strict
IPv4Prefix 192.0.2.10/32, Loose
- SetupPri:7, HoldPri:0, HopLimit:16, BW:0.000 bps, Flags:0x2
ExcAny:0x0, IncAny:0x0, IncAll:0x0

"

The two sets of output below show that when P-4 expands the ERO it now excludes the link to
node P-8 for the path calculation and the path is setup through P-6, P-8 and P-5.
*A:P-4# debug router rsvp packet path detail
9 2013/08/20 11:16:08.94 UTC MINOR: DEBUG #2001 Base RSVP
"RSVP: PATH Msg
Send PATH From:192.0.2.1, To:192.0.2.10
TTL:253, Checksum:0xef94, Flags:0x0
Session
- EndPt:192.0.2.10, TunnId:2, ExtTunnId:192.0.2.1
SessAttr
- Name:LSP-PE-1-PE-10::path-PE-10
SetupPri:7, HoldPri:0, Flags:0x17
Ctype:RA, ExcAny:0x800, IncAny:0x0, IncAll:0x0

ERO
- IPv4Prefix 192.168.46.2/32, Strict
IPv4Prefix 192.168.68.2/32, Strict
IPv4Prefix 192.168.58.1/32, Strict
IPv4Prefix 192.0.2.10/32, Loose

*A:PE-1# show router mpls lsp "LSP-PE-1-PE-10" path detail

LSP Name
: LSP-PE-1-PE-10
Path LSP ID :
From
: 192.0.2.1
To
:
Adm State
: Up
Oper State :
Path Name
: path-PE-10
Path Type
:
Path Admin : Up
Path Oper
:

Actual Hops :
192.168.13.1 (192.0.2.1) @ n
Record Label
-> 192.168.13.2 (192.0.2.3) @ n
Record Label
-> 192.168.34.2 (192.0.2.4) @ n
Record Label
-> 192.0.2.6 (192.0.2.6) @ n
Record Label
-> 192.168.46.2 @ n
Record Label
-> 192.0.2.8 (192.0.2.8) @
Record Label
-> 192.168.68.2 @
Record Label
-> 192.0.2.5 (192.0.2.5) @
Record Label
-> 192.168.58.1 @
Record Label
-> 192.0.2.10 (192.0.2.10)
Record Label
-> 192.168.105.2
Record Label

Page 920

56858
192.0.2.10
Up
Primary
Up

:
:
:
:
:
:
:
:
:
:
:

N/A
131071
131071
131071
131071
131071
131071
131071
131071
131071
131071

Advanced Configuration Guide

Inter-Area TE Point-to-Point LSPs

Shared Risk Link Groups (SRLG)


Shared Risk Link Groups are also supported in the context of inter-area TE LSPs. SRLGs refer to
situations where links in a network share a common fiber (or a common physical attribute). If one
link fails, other links in the group may fail as well. Links in the group have a shared risk.
The MPLS TE SRLG feature enhances backup tunnel path selection so that a backup tunnel
avoids using links that are in the same SRLG as interfaces the backup tunnel is protecting.
Consider the setup in Figure 56, where an inter-area LSP is setup from PE-1 to PE-10 and the path
goes through P-8 because of a lower IGP metric. To protect against a node failure of P-8, P-4
(PLR) would normally setup an FRR backup directly to P-5 (MP), because of the lower IGP
metric (P-4 to P-5:1000) compared to the IGP traffic via P-6 (P-4 to P-6 to P-7 to P-5:1200).
However, imagine that in this setup the P-4 <=> P-5 link and the P-4 <=> P-8 links are part of the
same transmission bundle. In this case a cut of that fiber bundle will bring down both the primary
and the backup path.
This can be avoided by configuring these two links in the same SRLG group and enabling srlg-frr
strict on P-4. In that case the backup will be setup via P-6 as indicated by the dotted line in
Figure 56

Belonging to Same SRLG

AREA 0

P-4
AREA 1

.2

PE-2

192.0.2.4 .1

.2

.1

PE-1

.1

.2

192.0.2.2 .1

AREA 2

P-5
.2

1000

PE-9

192.0.2.5 .1

.1

.1

.1

.1

.2

192.0.2.9

.1

.1

.2

.1

.2

192.0.2.1

P-8

.2

192.0.2.8
.2

.1

.2

10

PE-3

.2

.2
.1

.2

P-6
.1

.2 192.0.2.6 .1

.2 192.0.2.3 .1

.2
.1
1000

P-7
.1

.2 192.0.2.7 .1

.2

.2

PE-10

.2 192.0.2.10
al_0357

Figure 56: Share Risk Link Groups

Advanced Configuration Guide

Page 921

Configuration

SRLG Configuration
On P-4 configure an SRLG group and add the link to P-5 and the link to P-8 to this SRLG group
and enable srlg-frr strict.
*A:P-4# configure router mpls
*A:P-4>config>router>mpls# srlg-group "bundle-red" value 1
*A:P-4>config>router>mpls# interface "int-P-4-P-5" srlg-group "bundle-red"
*A:P-4>config>router>mpls# interface "int-P-4-P-8" srlg-group "bundle-red"
*A:P-4>config>router>mpls#
*A:P-4>config>router>mpls# srlg-frr strict

Note that the srlg-group configuration is required on all nodes that use srlg groups and on the ABR
used by the inter-area TE LSP.
*A:Px# configure router mpls

srlg-group "bundle-red" value 1

LSP Configuration
Remove the admin group restriction from the LSP.
*A:P-4# configure router mpls
*A:PE-1>config>router>mpls# info
---------------------------------------------
lsp "PE-10"
to 192.0.2.10
cspf
cspf-to-first-loose
fast-reroute facility
exit
primary "path-PE-10"
exit
no shutdown

Now check the LSP path on PE-1 and verify that FRR protection is in place.
*A:PE-1# show router mpls lsp "LSP-PE-1-PE-10" path detail
===============================================================================
MPLS LSP LSP-PE-1-PE-10 Path (Detail)
===============================================================================
Legend :
@ - Detour Available
# - Detour In Use
b - Bandwidth Protected
n - Node Protected
s - Soft Preemption
S - Strict
L - Loose
A - ABR
===============================================================================
------------------------------------------------------------------------------LSP LSP-PE-1-PE-10 Path path-PE-10
-------------------------------------------------------------------------------

Page 922

Advanced Configuration Guide

Inter-Area TE Point-to-Point LSPs

LSP Name
:
From
:
Adm State
:
Path Name
:
Path Admin :
OutInterface:
Path Up Time:
Retry Limit :
RetryAttempt:

LSP-PE-1-PE-10
192.0.2.1
Up
path-PE-10
Up
1/1/1
0d 00:15:26
0
0

Path LSP ID :
To
:
Oper State :
Path Type
:
Path Oper
:
Out Label
:
Path Dn Time:
Retry Timer :
NextRetryIn :

56864
192.0.2.10
Up
Primary
Up
131071
0d 00:00:00
30 sec
0 sec

Adspec
:
CSPF
:
Least Fill :
FRR
:
FRR NodePro*:
FR Hop Limit:
FR Prop Adm*:
Prop Adm Grp:
Inter-area :

Disabled
Enabled
Disabled
Enabled
Enabled
16
Disabled
Disabled
True

Oper
Oper
Oper
Oper
Oper
Oper
Oper
Oper

Adspec :
CSPF
:
LeastF*:
FRR
:
FRR NP :
FRHopL*:
FRProp*:
PropAG :

Disabled
Enabled
Disabled
Enabled
Enabled
16
Disabled
Disabled

Neg MTU
:
Bandwidth
:
Hop Limit
:
Record Route:
Record Label:
SetupPriori*:
Hold Priori*:
Class Type :
Backup CT
:
MainCT Retry:
Rem
:
MainCT Retry:
Limit
:
Include Grps:
None
Exclude Grps:
None

1560
No Reservation
255
Record
Record
7
0
0
None
n/a

Oper
Oper
Oper
Oper
Oper
Oper
Oper
Oper

MTU
:
Bw
:
HopLim*:
RecRou*:
RecLab*:
SetupP*:
HoldPr*:
CT
:

1560
0 Mbps
255
Record
Record
7
0
0

Adaptive
: Enabled
Preference : n/a
Path Trans : 31
Failure Code: noError
ExplicitHops:
No Hops Specified
Actual Hops :
192.168.13.1 (192.0.2.1) @ n
-> 192.168.13.2 (192.0.2.3) @ n
-> 192.168.34.2 (192.0.2.4) @ n
-> 192.0.2.8 (192.0.2.8) @ n
-> 192.168.48.2 @ n
-> 192.0.2.5 (192.0.2.5) @
-> 192.168.58.1 @
-> 192.0.2.10 (192.0.2.10)
-> 192.168.105.2
ComputedHops:
192.168.13.1(S)
-> 192.168.13.2(S)
-> 192.168.34.2(SA)
-> 192.0.2.10(L)

Advanced Configuration Guide

Oper InclGr*:
None
Oper ExclGr*:
None
Oper Metric : 110
CSPF Queries: 17
Failure Node: n/a

Record
Record
Record
Record
Record
Record
Record
Record
Record

Label
Label
Label
Label
Label
Label
Label
Label
Label

:
:
:
:
:
:
:
:
:

N/A
131071
131071
131071
131071
131071
131071
131070
131070

Page 923

Configuration

ResigEligib*: False
LastResignal: n/a
CSPF Metric : 110
===============================================================================

On P-4 check the SRLG configuration and verify that the backup is setup via P-6 rather than via P5.
*A:P-4# show router mpls srlg-group
===============================================================================
MPLS Srlg Groups
===============================================================================
Group Name
Group Value
Interfaces
------------------------------------------------------------------------------bundle-red
1
int-P-4-P-5
int-P-4-P-8
------------------------------------------------------------------------------No. of Groups: 1
===============================================================================

*A:P-4# show router mpls bypass-tunnel protected-lsp detail


===============================================================================
MPLS Bypass Tunnels (Detail)
===============================================================================
------------------------------------------------------------------------------bypass-node192.0.2.8
------------------------------------------------------------------------------To
: 192.168.57.1
State
: Up
Out I/F
: 1/1/5
Out Label
: 131068
Up Time
: 0d 00:21:37
Active Time
: n/a
Reserved BW
: 0 Kbps
Protected LSP Count : 1
Type
: Dynamic
Setup Priority : 7
Hold Priority
: 0
Class Type
: 0
Exclude Node
: None
Inter-Area
: False
Computed Hops
:
192.168.46.1(S)
Egress Admin Groups : None
-> 192.168.46.2(S)
Egress Admin Groups : None
-> 192.168.67.2(S)
Egress Admin Groups : None
-> 192.168.57.1(S)
Egress Admin Groups : None
Actual Hops
:
192.168.46.1 (192.0.2.4)
Record Label
: N/A
-> 192.168.46.2 (192.0.2.6)
Record Label
: 131068
-> 192.168.67.2 (192.0.2.7)
Record Label
: 131069
-> 192.168.57.1 (192.0.2.5)
Record Label
: 131070
Protected LSPs LSP Name
: LSP-PE-1-PE-10::path-PE-10
From
: 192.0.2.1
To
: 192.0.2.10
Avoid Node/Hop : 192.0.2.8
Downstream Label
: 131071
Bandwidth
: 0 Kbps
===============================================================================

Page 924

Advanced Configuration Guide

Inter-Area TE Point-to-Point LSPs

Conclusion
Inter-area TE P2P LSPs can be setup based on ERO expansion. With this feature the head-end
does a partial CSPF calculation to its local ABR. This ABR, on receiving a PATH message with a
loose hop ERO, does a partial CSPF calculation to the next ABR or full CSPF to reach the final
destination.
FRR protection within the area is available. FRR node protection of the ABR is possible through
an MBT on the PLR (node just upstream of the ABR) to the MP (node just downstream of the
ABR) or through a dynamically signaled bypass tunnel on the PLR. Dynamic ABR node
protection requires that the node-ID of the MP node is propagated in the RESV message and that
an XRO object is included in the bypass PATH message which makes it possible for the ABR to
calculate a path to MP node.
TE features like BW, path prioritization, path pre-emption, graceful shutdown are supported, as
well as propagation of the session attribute with affinity along the LSP path (admin groups) and
SRLG.

Advanced Configuration Guide

Page 925

Conclusion

Page 926

Advanced Configuration Guide

Inter-AS Model C for VLL

In This Chapter
This section describes advanced inter-AS model C for VLL configurations.
Topics in this section include:

Applicability on page 928

Overview on page 929

Configuration on page 931

Conclusion on page 947

Advanced Configuration Guide

Page 927

Applicability

Applicability
This configuration note is applicable to all of the 7750 SR, 7710 SR and 7450 ESS series
(including mixed mode). The information was tested with SROS 8.0 R4.

Page 928

Advanced Configuration Guide

Inter-AS Model C for VLL

Overview
SR OS 8.0R1 adds the support for RFC 3107, Carrying Label Information in BGP-4, including
VLL/VPLS. Starting with SR-OS 8.0R4, BGP SDPs have been extended and now can also be
used with PBB-VPLS services.
ISPs are looking for mechanisms to implement the VLL/VPLS outside an autonomous system
(AS). A service provider may have inter-AS operation as a consequence of delivering interprovider VLL/VPLS or because they use multiple ASs as a result of acquisitions and merges.
The objective of this example is to describe the interconnection of VLL services across multiple
ASs.

Advanced Configuration Guide

Page 929

Overview

Network Setup
Figure 57 shows the network setup used.

Core Inter-AS
IS-IS 49.0001
MPLS/LDP AS 64501
VLL
CE-1
PE-3

IS-IS
49.0001
MPLS/LDP
AS 64500

IS-IS
49.0001
MPLS/LDP
AS 64502

PE-9

PE-1

PE-7

VLL

CE-2

PE-5

al_0126

Figure 57: Network Setup - Inter-AS Model C for VLL

The network topology displayed in Figure 57 consists of three sites in different ASs with each site
using 7750 SRs.
In AS 64500, there are PE-3 and PE-1, AS 64501 has PE-9 and AS 64502 has PE-7 and PE-5.
There is a business customer with two remote locations, Site A and Site B, with customer edge
(CE) devices CE-1 connected to the AS 64500 via PE-3 and CE-2 connected to the AS 64502 via
PE-5. A VLL service is configured between PE-3 and PE-5 to connect site A and site B together.

Core Inter-AS
IS-IS 49.0001
MPLS/LDP AS 64501
VLL
CE-1
PE-3

IS-IS
49.0001
MPLS/LDP
AS 64500

192.0.2.3

PE-9

PE-1

PE-7

192.0.2.9

192.0.2.1

192.0.2.7

LDP
iBGP LBL

eBGP LBL

IS-IS
49.0001
MPLS/LDP
AS 64502

eBGP LBL

VLL

CE-2

PE-5
192.0.2.5

LDP

Transport
Signaling

iBGP LBL

Service
Signaling

TLDP
al_0127

Figure 58: Inter-AS Model C for VLL

Page 930

Advanced Configuration Guide

Inter-AS Model C for VLL

Configuration
This section describes all of the relevant configuration tasks for the detailed setup shown in the
Figure 59. In this particular example the following protocols are assumed to be already
configured.

IS-IS as the IGP with all the nodes being level Layer1/Layer 2.

LDP as the MPLS protocol to signal the transport tunnels.

iBGP within each AS with family IPv4.

Core Inter-AS
AS 64501

AS 64500
1/1/3

192.168.4.0/30

VLL

CE-1

.1
1/1/2

192.168.1.0/30

.2
1/1/2

.2
1/1/3

PE-3

PE-1

192.0.2.3

192.0.2.1

AS 64502

192.168.2.0/30

.1
1/1/3

.1
1/1/4

PE-9
192.0.2.9

192.168.3.0/30

.2
1/1/3

.2
1/1/1

.1
VLL
1/1/1

PE-7

PE-5

192.0.2.7

192.0.2.5

1/1/3

CE-2

al_0128

Figure 59: Network Setup Configuration

Advanced Configuration Guide

Page 931

Configuration

BGP Configuration
The following CLI output shows the BGP configuration iBGP and eBGP required for the PE
routers to implement VLL Inter-AS.
The configuration on PE-9 in AS 64501 is displayed below:
configure router
bgp
rapid-withdrawal
min-route-advertisement 1
group "ebgp"
family ipv4
type external
local-as 64501
neighbor 192.168.1.2
peer-as 64500
advertise-label ipv4
exit
neighbor 192.168.2.2
peer-as 64502
advertise-label ipv4
exit
exit
exit

The advertise-label ipv4 statement must be configured so that MPLS labels are carried with IPv4
NLRIs.
The configuration of PE-1 in AS 64500 is displayed below:
configure router
bgp
rapid-withdrawal
min-route-advertisement 1
group "ebgp"
family ipv4
type external
export "export-systems"
neighbor 192.168.1.1
peer-as 64501
advertise-label ipv4
exit
exit
group "ibgp"
family ipv4
type internal
local-as 64500
neighbor 192.0.2.3
next-hop-self
advertise-label ipv4
exit
exit
exit

Page 932

Advanced Configuration Guide

Inter-AS Model C for VLL

The configuration of PE-7 in AS 64502 is displayed below:


configure router
bgp
rapid-withdrawal
min-route-advertisement 1
export "export-systems"
group "ebgp"
family ipv4
type external
local-as 64502
neighbor 192.168.2.1
peer-as 64501
advertise-label ipv4
exit
exit
group "ibgp"
family ipv4
type internal
local-as 64502
neighbor 192.0.2.5
next-hop-self
advertise-label ipv4
exit
exit
exit

To complement the BGP setup, the configurations of PE-3 and PE-5 (the PEs to which the CEs are
connected in AS 64500 and AS 64502), respectively, are displayed below:
PE-3:
configure router
bgp
rapid-withdrawal
min-route-advertisement 1
group "ibgp"
family ipv4
type internal
local-as 64500
neighbor 192.0.2.1
next-hop-self
advertise-label ipv4
exit
exit
exit

PE-5:
configure router
bgp
rapid-withdrawal
min-route-advertisement 1
group "ibgp"
family ipv4

Advanced Configuration Guide

Page 933

Configuration

type internal
local-as 64502
neighbor 192.0.2.7
next-hop-self
advertise-label ipv4
exit
exit
exit

Page 934

Advanced Configuration Guide

Inter-AS Model C for VLL

Policy Configuration
The export policy on the PE-1 and PE-7 peering determines the system addresses leaked to the
remote AS. It is worth noting here that it is important to modify the default origin attribute from
incomplete to IGP in dual-homing scenarios otherwise the iBGP route will be always preferred
over the eBGP route.
This is the configuration on PE-1:
configure router
policy-options
begin
prefix-list "pe-systems-as64500"
prefix 192.0.2.1/32 exact
prefix 192.0.2.3/32 exact
exit
policy-statement "export-systems"
entry 10
from
prefix-list "pe-systems-as64500"
exit
action accept
origin igp
exit
exit
exit
commit
exit

This is the configuration on PE-7:


configure router
policy-options
begin
prefix-list "pe-systems-as64502"
prefix 192.0.2.5/32 exact
prefix 192.0.2.7/32 exact
exit
policy-statement "export-systems"
entry 10
from
prefix-list "pe-systems-as64502"
exit
action accept
origin igp
exit
exit
exit
commit
exit

Advanced Configuration Guide

Page 935

Configuration

Service Configuration
Once BGP is configured, the configuration requires the service to be defined (Epipe 1). The focus
here is a VLL service (noting that it is also possible to have a similar configuration with VPLS
services).
The following CLI shows the service level configuration on PE-3:
configure
service
customer 1 create
description "Default customer"
exit
sdp 35 mpls create
far-end 192.0.2.5
bgp-tunnel
keep-alive
shutdown
exit
no shutdown
exit
epipe 1 customer 1 create
description "Tunnel to PE-5"
sap 1/1/3:1 create
exit
spoke-sdp 35:1 create
exit
no shutdown
exit
exit

The following CLI shows the service level configuration on PE-5:


configure
service
customer 1 create
description "Default customer"
exit
sdp 53 mpls create
far-end 192.0.2.3
bgp-tunnel
keep-alive
shutdown
exit
no shutdown
exit
epipe 1 customer 1 create
description "Tunnel to PE-3"
sap 1/1/3:1 create
exit
spoke-sdp 53:1 create
exit
no shutdown
exit
exit

Page 936

Advanced Configuration Guide

Inter-AS Model C for VLL

Show Commands and Troubleshooting


On PE-3 we have BGP tunnels to the remote AS system addresses that are using LDP as a
transport mechanism and the configuration of end-to-end SDPs over which TLDP service labels
are exchanged.
The following output shows the SDP and LDP information:
*A:PE-3# show service sdp
==============================================================================
Services: Service Destination Points
==============================================================================
SdpId
Adm MTU Opr MTU IP address
Adm Opr
Deliver
Signal
-----------------------------------------------------------------------------35
0
1552
192.0.2.5
Up
Up
BGP
TLDP
-----------------------------------------------------------------------------Number of SDPs : 1
-----------------------------------------------------------------------------==============================================================================

*A:PE-3# show service service-using


===============================================================================
Services
===============================================================================
ServiceId
Type
Adm Opr CustomerId Service Name
------------------------------------------------------------------------------1
Epipe
Up
Up
1
2147483648
IES
Up
Down 1
_tmnx_InternalIesService
------------------------------------------------------------------------------Matching Services : 2
------------------------------------------------------------------------------===============================================================================

*A:PE-3# show router ldp session


==============================================================================
LDP Sessions
==============================================================================
Peer LDP Id
Adj Type
State
Msg Sent Msg Recv Up Time
-----------------------------------------------------------------------------192.0.2.1:0
Link
Established
1351
1351
0d 01:02:08
192.0.2.5:0
Targeted
Established
123
123
0d 00:10:42
-----------------------------------------------------------------------------No. of Sessions: 2
==============================================================================

The route-table shows that the system IP address of PE-5 is reachable using a BGP tunnel:
*A:PE-3# show router route-table
===============================================================================
Route Table (Router: Base)
===============================================================================
Dest Prefix
Type
Proto
Age
Pref

Advanced Configuration Guide

Page 937

Configuration

Next Hop[Interface Name]


Metric
------------------------------------------------------------------------------192.0.2.1/32
Remote ISIS
01h03m07s
15
192.168.4.2
10
192.0.2.3/32
Local
Local
01h12m03s
0
system
0
192.0.2.5/32
Remote BGP
00h21m22s
170
192.0.2.1 (tunneled)
0
192.0.2.7/32
Remote BGP
00h21m22s
170
192.0.2.1 (tunneled)
0
192.168.4.0/30
Local
Local
01h10m50s
0
int-PE-3-PE-1
0
------------------------------------------------------------------------------No. of Routes: 5
===============================================================================

The tunnel-table below shows the details of the LDP, SDP and BGP tunnels. This is followed by
the service details, noting that Epipe 1 is using SDP 3. A ping is used to show that there is IP
connectivity from PE-3 to the system IP address of PE-5:
*A:PE-3# show router tunnel-table
===============================================================================
Tunnel Table (Router: Base)
===============================================================================
Destination
Owner Encap TunnelId Pref
Nexthop
Metric
------------------------------------------------------------------------------192.0.2.1/32
ldp
MPLS
9
192.168.4.2
10
192.0.2.5/32
sdp
MPLS 35
5
192.0.2.5
0
192.0.2.5/32
bgp
MPLS
10
192.0.2.1
1000
192.0.2.7/32
bgp
MPLS
10
192.0.2.1
1000
===============================================================================

*A:PE-3# show service id 1 base


===============================================================================
Service Basic Information
===============================================================================
Service Id
: 1
Vpn Id
: 0
Service Type
: Epipe
Name
: (Not Specified)
Description
: Tunnel to PE-5
Customer Id
: 1
Last Status Change: 09/03/2011 17:23:17
Last Mgmt Change : 09/03/2011 17:22:11
Admin State
: Up
Oper State
: Up
MTU
: 1514
Vc Switching
: False
SAP Count
: 1
SDP Bind Count
: 1
Per Svc Hashing
: Disabled
Force QTag Fwd
: Disabled
------------------------------------------------------------------------------Service Access & Destination Points
------------------------------------------------------------------------------Identifier
Type
AdmMTU OprMTU Adm Opr
------------------------------------------------------------------------------sap:1/1/3:1
q-tag
1518
1518
Up
Up
sdp:35:1 S(192.0.2.5)
Spok
0
1552
Up
Up

Page 938

Advanced Configuration Guide

Inter-AS Model C for VLL

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

*A:PE-3# ping 192.0.2.5


PING 192.0.2.5 56 data bytes
64 bytes from 192.0.2.5: icmp_seq=1
64 bytes from 192.0.2.5: icmp_seq=2
64 bytes from 192.0.2.5: icmp_seq=3
64 bytes from 192.0.2.5: icmp_seq=4
64 bytes from 192.0.2.5: icmp_seq=5

ttl=64
ttl=64
ttl=64
ttl=64
ttl=64

time=3.20ms.
time=3.72ms.
time=3.92ms.
time=3.59ms.
time=3.54ms.

---- 192.0.2.5 PING Statistics ---5 packets transmitted, 5 packets received, 0.00% packet loss
round-trip min = 3.20ms, avg = 3.59ms, max = 3.92ms, stddev = 0.235ms

The same commands on PE-5 are shown below:


*A:PE-5# show service sdp
==============================================================================
Services: Service Destination Points
==============================================================================
SdpId
Adm MTU Opr MTU IP address
Adm Opr
Deliver
Signal
-----------------------------------------------------------------------------53
0
1552
192.0.2.3
Up
Up
BGP
TLDP
-----------------------------------------------------------------------------Number of SDPs : 1
-----------------------------------------------------------------------------==============================================================================

*A:PE-5# show service service-using


===============================================================================
Services
===============================================================================
ServiceId
Type
Adm Opr CustomerId Service Name
------------------------------------------------------------------------------1
Epipe
Up
Up
1
2147483648
IES
Up
Down 1
_tmnx_InternalIesService
------------------------------------------------------------------------------Matching Services : 2
------------------------------------------------------------------------------===============================================================================

*A:PE-5# show router ldp session


==============================================================================
LDP Sessions
==============================================================================
Peer LDP Id
Adj Type
State
Msg Sent Msg Recv Up Time
-----------------------------------------------------------------------------192.0.2.3:0
Targeted
Established
331
332
0d 00:29:46
192.0.2.7:0
Link
Established
1253
1255
0d 00:57:44
-----------------------------------------------------------------------------No. of Sessions: 2
==============================================================================

Advanced Configuration Guide

Page 939

Configuration

*A:PE-5# show router route-table


===============================================================================
Route Table (Router: Base)
===============================================================================
Dest Prefix
Type
Proto
Age
Pref
Next Hop[Interface Name]
Metric
------------------------------------------------------------------------------192.0.2.1/32
Remote BGP
00h42m30s
170
192.0.2.7 (tunneled)
0
192.0.2.3/32
Remote BGP
00h42m30s
170
192.0.2.7 (tunneled)
0
192.0.2.5/32
Local
Local
00h58m27s
0
system
0
192.0.2.7/32
Remote ISIS
00h56m41s
15
192.168.3.2
10
192.168.3.0/30
Local
Local
00h57m28s
0
int-PE5-PE7
0
------------------------------------------------------------------------------No. of Routes: 5
===============================================================================

*A:PE-5# show router tunnel-table


===============================================================================
Tunnel Table (Router: Base)
===============================================================================
Destination
Owner Encap TunnelId Pref
Nexthop
Metric
------------------------------------------------------------------------------192.0.2.1/32
bgp
MPLS
10
192.0.2.7
1000
192.0.2.3/32
sdp
MPLS 53
5
192.0.2.3
0
192.0.2.3/32
bgp
MPLS
10
192.0.2.7
1000
192.0.2.7/32
ldp
MPLS
9
192.168.3.2
10
===============================================================================
*A:PE-5#

*A:PE-5# show service id 1 base


===============================================================================
Service Basic Information
===============================================================================
Service Id
: 1
Vpn Id
: 0
Service Type
: Epipe
Name
: (Not Specified)
Description
: Tunnel to PE-3
Customer Id
: 1
Last Status Change: 09/03/2011 17:23:22
Last Mgmt Change : 09/03/2011 17:23:22
Admin State
: Up
Oper State
: Up
MTU
: 1514
Vc Switching
: False
SAP Count
: 1
SDP Bind Count
: 1
Per Svc Hashing
: Disabled
Force QTag Fwd
: Disabled
------------------------------------------------------------------------------Service Access & Destination Points
------------------------------------------------------------------------------Identifier
Type
AdmMTU OprMTU Adm Opr
------------------------------------------------------------------------------sap:1/1/3:1
q-tag
1518
1518
Up
Up

Page 940

Advanced Configuration Guide

Inter-AS Model C for VLL

sdp:53:1 S(192.0.2.3)
Spok
0
1552
Up
Up
===============================================================================
*A:PE-5# ping 192.0.2.3
PING 192.0.2.3 56 data bytes
64 bytes from 192.0.2.3: icmp_seq=1
64 bytes from 192.0.2.3: icmp_seq=2
64 bytes from 192.0.2.3: icmp_seq=3
64 bytes from 192.0.2.3: icmp_seq=4
64 bytes from 192.0.2.3: icmp_seq=5

ttl=64
ttl=64
ttl=64
ttl=64
ttl=64

time=3.45ms.
time=3.74ms.
time=4.40ms.
time=3.85ms.
time=4.93ms.

---- 192.0.2.3 PING Statistics ---5 packets transmitted, 5 packets received, 0.00% packet loss
round-trip min = 3.45ms, avg = 4.07ms, max = 4.93ms, stddev = 0.530ms

On PE-5, the BGP route to the system IP address of PE-3 can been seen with a next hop of PE-7:
*A:PE-5# show router bgp routes
===============================================================================
BGP Router ID:192.0.2.5
AS:64502
Local AS:64502
===============================================================================
Legend Status codes : u - used, s - suppressed, h - history, d - decayed, * - valid
Origin codes : i - IGP, e - EGP, ? - incomplete, > - best
===============================================================================
BGP IPv4 Routes
===============================================================================
Flag Network
LocalPref
MED
Nexthop
VPNLabel
As-Path
------------------------------------------------------------------------------u*>i 192.0.2.1/32
100
None
192.0.2.7
64501 64500
u*>i 192.0.2.3/32
100
None
192.0.2.7
64501 64500
*i
192.0.2.5/32
100
10
192.0.2.7
No As-Path
*i
192.0.2.7/32
100
None
192.0.2.7
No As-Path
------------------------------------------------------------------------------Routes : 4
===============================================================================

Advanced Configuration Guide

Page 941

Configuration

Again on PE-5, the FIB on slot 1 shows that the system IP address of PE-3 is reachable using BGP
over an LDP transport to PE-7:
*A:PE-5# show router fib 1
===============================================================================
FIB Display
===============================================================================
Prefix
Protocol
NextHop
------------------------------------------------------------------------------192.0.2.1/32
BGP
192.0.2.7 (Transport:LDP)
192.0.2.3/32
BGP
192.0.2.7 (Transport:LDP)
192.0.2.5/32
LOCAL
192.0.2.5 (system)
192.0.2.7/32
ISIS
192.168.3.2 (int-PE5-PE7)
192.168.3.0/30
LOCAL
192.168.3.0 (int-PE5-PE7)
------------------------------------------------------------------------------Total Entries : 5
------------------------------------------------------------------------------===============================================================================

The show commands on PE-9 router in AS 64501 are as follows:


*A:PE-9# show router bgp summary
===============================================================================
BGP Router ID:192.0.2.9
AS:64501
Local AS:64501
===============================================================================
BGP Admin State
: Up
BGP Oper State
: Up
Total Peer Groups
: 1
Total Peers
: 2
Total BGP Paths
: 6
Total Path Memory
: 752
Total IPv4 Remote Rts
: 4
Total IPv4 Rem. Active Rts : 4
Total IPv6 Remote Rts
: 0
Total IPv6 Rem. Active Rts : 0
Total Supressed Rts
: 0
Total Hist. Rts
: 0
Total Decay Rts
: 0
Total VPN Peer Groups
: 0
Total VPN Peers
: 0
Total VPN Local Rts
: 0
Total VPN-IPv4 Rem. Rts : 0
Total VPN-IPv4 Rem. Act. Rts: 0
Total VPN-IPv6 Rem. Rts : 0
Total VPN-IPv6 Rem. Act. Rts: 0
Total L2-VPN Rem. Rts
: 0
Total L2VPN Rem. Act. Rts
: 0
Total VPN Supp. Rts
: 0
Total VPN Hist. Rts
: 0
Total VPN Decay Rts
: 0
Total MVPN-IPv4 Rem Rts : 0
Total MVPN-IPv4 Rem Act Rts : 0
Total MDT-SAFI Rem Rts : 0
Total MDT-SAFI Rem Act Rts : 0
===============================================================================
BGP Summary
===============================================================================
Neighbor
AS PktRcvd InQ Up/Down
State|Rcv/Act/Sent (Addr Family)
PktSent OutQ
------------------------------------------------------------------------------192.168.1.2

Page 942

Advanced Configuration Guide

Inter-AS Model C for VLL

64500

128
132

0 01h01m22s 2/2/2 (IPv4)


0

192.168.2.2
64502

113
0 00h53m31s 2/2/2 (IPv4)
117
0
===============================================================================

*A:PE-9# show router bgp routes


===============================================================================
BGP Router ID:192.0.2.9
AS:64501
Local AS:64501
===============================================================================
Legend Status codes : u - used, s - suppressed, h - history, d - decayed, * - valid
Origin codes : i - IGP, e - EGP, ? - incomplete, > - best
===============================================================================
BGP IPv4 Routes
===============================================================================
Flag Network
LocalPref
MED
Nexthop
VPNLabel
As-Path
------------------------------------------------------------------------------u*>i 192.0.2.1/32
None
None
192.168.1.2
64500
u*>i 192.0.2.3/32
None
10
192.168.1.2
64500
u*>i 192.0.2.5/32
None
10
192.168.2.2
64502
u*>i 192.0.2.7/32
None
None
192.168.2.2
64502
------------------------------------------------------------------------------Routes : 4
===============================================================================

*A:PE-9# show router bgp inter-as-label


===============================================================================
BGP Inter-AS labels
===============================================================================
NextHop
Received
Advertised
Label
Label
Label
Origin
------------------------------------------------------------------------------192.168.1.2
131068
131069
External
192.168.1.2
131069
131070
External
192.168.2.2
131066
131067
External
192.168.2.2
131067
131068
External
===============================================================================

*A:PE-9# show router route-table


===============================================================================
Route Table (Router: Base)
===============================================================================
Dest Prefix
Type
Proto
Age
Pref
Next Hop[Interface Name]
Metric

Advanced Configuration Guide

Page 943

Configuration

------------------------------------------------------------------------------192.0.2.1/32
Remote BGP
00h35m46s
170
192.168.1.2
0
192.0.2.3/32
Remote BGP
00h35m46s
170
192.168.1.2
0
192.0.2.5/32
Remote BGP
00h31m56s
170
192.168.2.2
0
192.0.2.7/32
Remote BGP
00h31m56s
170
192.168.2.2
0
192.0.2.9/32
Local
Local
01h08m18s
0
system
0
192.168.1.0/30
Local
Local
01h07m10s
0
int-PE-9-PE-1
0
192.168.2.0/30
Local
Local
01h06m27s
0
int-PE-9-PE-7
0
------------------------------------------------------------------------------No. of Routes: 7
===============================================================================

The commands on PE-1 are shown below:


*A:PE-1# show router bgp summary
===============================================================================
BGP Router ID:192.0.2.1
AS:64500
Local AS:64500
===============================================================================
BGP Admin State
: Up
BGP Oper State
: Up
Total Peer Groups
: 2
Total Peers
: 2
Total BGP Paths
: 5
Total Path Memory
: 612
Total IPv4 Remote Rts
: 2
Total IPv4 Rem. Active Rts : 2
Total IPv6 Remote Rts
: 0
Total IPv6 Rem. Active Rts : 0
Total Supressed Rts
: 0
Total Hist. Rts
: 0
Total Decay Rts
: 0
Total VPN Peer Groups
: 0
Total VPN Peers
: 0
Total VPN Local Rts
: 0
Total VPN-IPv4 Rem. Rts : 0
Total VPN-IPv4 Rem. Act. Rts: 0
Total VPN-IPv6 Rem. Rts : 0
Total VPN-IPv6 Rem. Act. Rts: 0
Total L2-VPN Rem. Rts
: 0
Total L2VPN Rem. Act. Rts
: 0
Total VPN Supp. Rts
: 0
Total VPN Hist. Rts
: 0
Total VPN Decay Rts
: 0
Total MVPN-IPv4 Rem Rts : 0
Total MVPN-IPv4 Rem Act Rts : 0
Total MDT-SAFI Rem Rts : 0
Total MDT-SAFI Rem Act Rts : 0
===============================================================================
BGP Summary
===============================================================================
Neighbor
AS PktRcvd InQ Up/Down
State|Rcv/Act/Sent (Addr Family)
PktSent OutQ
------------------------------------------------------------------------------192.0.2.3
64500
137
0 01h06m58s 0/0/2 (IPv4)
138
0
192.168.1.1
64501
119
0 00h57m29s 2/2/2 (IPv4)
121
0
===============================================================================

Page 944

Advanced Configuration Guide

Inter-AS Model C for VLL

*A:PE-1# show router bgp inter-as-label


===============================================================================
BGP Inter-AS labels
===============================================================================
NextHop
Received
Advertised
Label
Label
Label
Origin
------------------------------------------------------------------------------192.168.1.1
131067
131067
External
192.168.1.1
131068
131066
External
192.0.2.1
0
131069
Edge
192.0.2.3
0
131068
Internal
===============================================================================

*A:PE-1# show router route-table


===============================================================================
Route Table (Router: Base)
===============================================================================
Dest Prefix
Type
Proto
Age
Pref
Next Hop[Interface Name]
Metric
------------------------------------------------------------------------------192.0.2.1/32
Local
Local
01h12m22s
0
system
0
192.0.2.3/32
Remote ISIS
01h09m14s
15
192.168.4.1
10
192.0.2.5/32
Remote BGP
00h27m29s
170
192.168.1.1
0
192.0.2.7/32
Remote BGP
00h27m29s
170
192.168.1.1
0
192.168.1.0/30
Local
Local
01h10m05s
0
int-PE-3-PE-9
0
192.168.4.0/30
Local
Local
01h11m15s
0
int-PE-1-PE-3
0
------------------------------------------------------------------------------No. of Routes: 6
===============================================================================

The show commands on PE-7:


*A:PE-7# show router bgp summary
===============================================================================
BGP Router ID:192.0.2.7
AS:64502
Local AS:64502
===============================================================================
BGP Admin State
: Up
BGP Oper State
: Up
Total Peer Groups
: 2
Total Peers
: 2
Total BGP Paths
: 5
Total Path Memory
: 612
Total IPv4 Remote Rts
: 2
Total IPv4 Rem. Active Rts : 2
Total IPv6 Remote Rts
: 0
Total IPv6 Rem. Active Rts : 0
Total Supressed Rts
: 0
Total Hist. Rts
: 0
Total Decay Rts
: 0
Total
Total
Total
Total
Total
Total
Total

VPN Peer Groups


VPN Local Rts
VPN-IPv4 Rem. Rts
VPN-IPv6 Rem. Rts
L2-VPN Rem. Rts
VPN Supp. Rts
VPN Decay Rts

Advanced Configuration Guide

:
:
:
:
:
:
:

0
0
0
0
0
0
0

Total VPN Peers


Total
Total
Total
Total

: 0

VPN-IPv4 Rem. Act. Rts:


VPN-IPv6 Rem. Act. Rts:
L2VPN Rem. Act. Rts
:
VPN Hist. Rts
:

0
0
0
0

Page 945

Configuration

Total MVPN-IPv4 Rem Rts : 0


Total MDT-SAFI Rem Rts : 0

Total MVPN-IPv4 Rem Act Rts : 0


Total MDT-SAFI Rem Act Rts : 0

===============================================================================
BGP Summary
===============================================================================
Neighbor
AS PktRcvd InQ Up/Down
State|Rcv/Act/Sent (Addr Family)
PktSent OutQ
------------------------------------------------------------------------------192.0.2.5
64502
104
0 00h49m52s 0/0/4 (IPv4)
108
0
192.168.2.1
64501
118
0 00h56m44s 2/2/2 (IPv4)
120
0
===============================================================================

*A:PE-7# show router bgp routes


===============================================================================
BGP Router ID:192.0.2.7
AS:64502
Local AS:64502
===============================================================================
Legend Status codes : u - used, s - suppressed, h - history, d - decayed, * - valid
Origin codes : i - IGP, e - EGP, ? - incomplete, > - best
===============================================================================
BGP IPv4 Routes
===============================================================================
Flag Network
LocalPref
MED
Nexthop
VPNLabel
As-Path
------------------------------------------------------------------------------u*>i 192.0.2.1/32
None
None
192.168.2.1
64501 64500
u*>i 192.0.2.3/32
None
None
192.168.2.1
64501 64500
------------------------------------------------------------------------------Routes : 2
===============================================================================

*A:PE-7# show router bgp inter-as-label


===============================================================================
BGP Inter-AS labels
===============================================================================
NextHop
Received
Advertised
Label
Label
Label
Origin
------------------------------------------------------------------------------192.168.2.1
131069
131069
External
192.168.2.1
131070
131068
External
192.0.2.5
0
131066
Internal
192.0.2.7
0
131067
Edge
===============================================================================

Page 946

Advanced Configuration Guide

Inter-AS Model C for VLL

Conclusion
The BGP tunnel based SDP binding is allowed for VLL and VPLS services, including PBB-VPLS
in SROS 8.0R4. Using RFC 3107, it is possible to implement inter-AS Model C VLLs.
The examples used in this section illustrates the configuration of VLL Inter-AS for access CE
sites. Troubleshooting commands also have been shown so an operator can verify all the
procedures.

Advanced Configuration Guide

Page 947

Conclusion

Page 948

Advanced Configuration Guide

IP/GRE Termination

In This Chapter
This section describes advanced IP/GRE termination configurations.
Topics in this section include:

Applicability on page 950

Summary on page 951

Overview on page 952

Configuration on page 955

Conclusion on page 977

Advanced Configuration Guide

Page 949

Applicability

Applicability
This note is applicable only to 7750 SR-7 and SR-12 systems and was tested on release 9.0R8. IP/
GRE tunnel termination requires an MS-ISA equipped on IOM2-20g or IOM3-XP. IP/GRE is not
supported in a 7450 ESS (even with mixed mode) or 7710 SR chassis. Also it is not supported by
the MS-ISA-E (the non-encrypted version of the MS-ISA).
Note: The following syntax changes were introduced in release 10.0R8 with the support for IP-inIP tunneling:
1. The definition for a GRE tunnel before 10.0R8 was:
interface "int-gre-tunnel" tunnel create
sap tunnel-1.private:1 create
gre-tunnel "gre-tunnel-1" to 10.0.0.2 create

From 10.0R8 onward, the gre-tunnel parameter has been replaced by the ip-tunnel parameter
together with a sub-parameter gre-header to identify this to be a GRE tunnel. In addition, the to
ip-address parameter has been deprecated and replaced with the sub-parameter dest-ip.
The above configuration becomes:
interface "int-gre-tunnel" tunnel create
sap tunnel-1.private:1 create
ip-tunnel "gre-tunnel-1" create
dest-ip 10.0.0.2
gre-header

2. The show gre tunnel command has been replaced by the show ip tunnel command.

Page 950

Advanced Configuration Guide

IP/GRE Termination

Summary
The 7x50 previously only supported GRE SDP tunnels which use pseudowire encapsulation.
Starting with SR-OS 8.0R5, the 7750 SR-7 and SR-12 support tunneling IPv4 packets in an IPv4
GRE tunnel. A common use case is remote access to a VPRN over a public IP network because IP/
GRE tunneling allows encapsulated packets to follow a path based on the outer IP header which is
useful when the inner IP packet cannot or should not be forwarded natively over this path.
This section provides configuration and troubleshooting commands for IP/GRE termination.

Advanced Configuration Guide

Page 951

Overview

Overview
Generic Routing Encapsulation (GRE) allows packets of one protocol, the payload protocol, to be
encapsulated by packets of another protocol called the delivery protocol. A GRE packet has an
Outer Delivery Header, GRE Header and Payload Packet (Figure 60).

0 1 2 3 4 5 6 7 8 9 10 1 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31

IPv4 Header (20 bytes)


C-bit(0)

TTL 255

Reserved (0)
Ver(0)
Checksum (Optional)

Outer Delivery
Header 20 bytes

Protocol 0x2F
Protocol Type 0x0800 (IP)
Reserved 1 (Optional)

IPv4 or IPv6 Payload Packet

GRE Header
4 bytes
Payload Packet
al_0132

Figure 60: GRE Packet Format

The following information discusses the outer delivery and GRE header for outgoing traffic.

Outer Delivery header


The source address in the IPv4 delivery header is the configured source address.
The destination address in the IPv4 delivery header is the configured remote-ip (or
backup-remote-ip) address.
The IP protocol value in the IPv4 delivery header is 0x02F or 47 (GRE).
The DSCP in the IPv4 Outer Delivery header is:

Set to the value configured for the tunnel.

Otherwise, the DSCP value from the Payload Packet is copied into the Outer
Delivery header.

The TTL in the IPv4 Outer Delivery header is set to 255.

GRE Header
The Checksum (C) bit in the GRE header is set to 0 (no checksum present).
The version in the GRE header is 0.
The protocol type in the GRE header is 0x0800 for IPv4.

Page 952

Advanced Configuration Guide

IP/GRE Termination

The following information discusses the outer delivery and GRE header for incoming traffic:

Outer Delivery header


If the packet is a fragment (More Fragments=1, non-zero fragment offset), it is
dropped.
If the Checksum (C) bit in the GRE header is set then the included checksum is
validated; if the checksum is incorrect, the packet is discarded.
If the version in the GRE header is not 0 the packet is discarded.
If the source/destination address pair in the IPv4 delivery header is any other
combination the packet is dropped.

GRE Header
If the Checksum (C) bit in the GRE header is set then the included checksum is
validated; if the checksum is incorrect the packet is discarded.
If the version in the GRE header is not 0 the packet is discarded.

7750 SR-12/SR-7 Implementation


Encapsulation, de-encapsulation and other datapath operations related to IP/GRE are handled by
the isa-tunnel MDA.
Note that for GRE tunnels configured as SDPs (which are not covered by this section), no isatunnel MDA is required.

ISA-Tunnel

VPRN/IES

VPRN/IES

ISA-Tunnel

Internet

VPRN/IES

VPRN/IES

ISA-Tunnel
al_0133

Figure 61: 7x50 Implementation

From SR-OS 8.0R5, the 7750 SR-7 and SR-12 supports the IP/GRE tunnels with static routes and
BGP only. IPv6, BFD, OSPF, IS-IS, RIP and multicast are not supported.

Advanced Configuration Guide

Page 953

Overview

From SR-OS 9.0R1, IP/GRE tunnels have been enhanced by adding the support of OSPFv2 and
BFD on private tunnel interfaces (used with static routes, OSPFv2 or BGP) and GRE protection
by tunneling into an IPSec tunnel.
ISA-Tunnel

VPRN/IES

GRE-Tunnel

VPRN/IES

ISA-Tunnel

Internet

VPRN/IES

IPsec-Tunnel

VPRN/IES

GRE-Tunnel
al_0134

Figure 62: IP/GRE over IPSec Tunnel

Page 954

Advanced Configuration Guide

IP/GRE Termination

Configuration
Tunnel ISA MDA
From SR-OS 8.0 R5, the isa-tunnel MDA supports IP/GRE and IPSec tunnels.
*A:PE-1#configure card 1 mda 1 mda-type "isa-tunnel"

To check the MDA configuration:


*A:PE-1# show mda
=========================================================
MDA Summary
=========================================================
Slot Mda
Provisioned
Equipped
Admin
Operational
Mda-type
Mda-type
State
State
--------------------------------------------------------snip1
2
isa-tunnel
isa-ms
up
up

Tunnel Groups and Tunnel Group Restrictions


The first step of the GRE tunnel configuration is to configure a tunnel-group.
*A:PE-1# configure isa tunnel-group ?
- tunnel-group <tunnel-group-id> [create]
- no tunnel-group <tunnel-group-id>
<tunnel-group-id>
<create>

: [1..16]
: keyword - mandatory while creating an entry.

Chassis-mode B or higher is required.


*A:PE-11# configure isa tunnel-group 1 create
MINOR: IPSECGRPMGR #1008 Chassis mode B or higher is required

A tunnel group can have one tunnel-ISA designated primary and optionally one tunnel-ISA
designated backup. When a GRE tunnel is created it is assigned to the primary tunnel-ISA in its
tunnel group. If the primary tunnel-ISA fails, the backup tunnel-ISA (if not already claimed by
another tunnel-group) takes over for the failed card.
*A:PE-1>config>isa>tunnel-grp#
[no] backup
- Configure ISA-Tunnel-Group backup ISA
[no] description
- Configure the ISA group description
[no] primary
- Configure ISA-Tunnel-Group primary ISA
[no] shutdown
- Administratively enable/disable an ISA-Tunnel-Group

Advanced Configuration Guide

Page 955

Configuration

A:PE-1>config>isa# info
---------------------------------------------tunnel-group 1 create
primary 1/2
backup 2/1
no shutdown
exit
----------------------------------------------

The failed tunnels are re-established using a cold-standby on the backup tunnel-ISA (cold standby
means the backup tunnel-ISA has no state or configuration information about the tunnels prior to
the failure).
A tunnel-ISA cannot be primary for more than one tunnel group.
*A:PE-1>config>isa>tunnel-grp# primary 1/2
MINOR: IPSECGRPMGR #1003 The specified MDA is primary in another Tunnel Group

A tunnel-ISA cannot be primary in one tunnel group and backup in another tunnel group.
*A:PE-1>config>isa>tunnel-grp# backup 1/2
MINOR: IPSECGRPMGR #1003 The specified MDA is primary in another Tunnel Group

To check the isa tunnel-group:


*A:PE-1# show isa tunnel-group
============================================================
ISA Tunnel Groups
============================================================
Tunnel
PrimaryIsa
BackupIsa
ActiveIsa Admin
Oper
GroupId
State
State
-----------------------------------------------------------1
1/2
2/1
1/2
Up
Up

To check the number of the GRE tunnels:


*A:PE-1# show gre tunnel count
----------------------------GRE Tunnels: 1

To check all gre-tunnels:


*A:PE-1# show gre tunnel
===============================================================================
GRE Tunnels
===============================================================================
TunnelName
LocalAddress
SvcId
Admn
SapId
RemoteAddress
DlvrySvcId Oper
To
Bkup RemAddr
DSCP
Oper Rem Addr
------------------------------------------------------------------------------gre-tunnel-1
192.168.1.1
1
Up

Page 956

Advanced Configuration Guide

IP/GRE Termination

tunnel-1.private:1
192.168.0.1
2
Up
10.0.0.2
None
192.168.0.1
protected-gre-tunnel
192.168.4.1
3
Up
tunnel-1.private:5
192.168.3.1
3
Up
10.0.0.5
None
192.168.3.1
------------------------------------------------------------------------------GRE Tunnels: 2
===============================================================================

To check the detailed tunnel information:


*A:PE-1# show gre tunnel "gre-tunnel-1"
===============================================================================
GRE Tunnel Configuration Detail
===============================================================================
Service Id
: 1
Sap Id
: tunnel-1.private:1
Tunnel Name
: gre-tunnel-1
Description
: None
Target Address
: 10.0.0.2
Delivery Service : 2
Admin State
: Up
Oper State
: Up
Source Address
: 192.168.1.1
Oper Remote Addr : 192.168.0.1
Remote Address
: 192.168.0.1
Backup Address
:
DSCP
: None
Oper Flags
: None
===============================================================================
GRE Tunnel Statistics: gre-tunnel-1
===============================================================================
Errors Rx
: 0
Errors Tx
: 0
Pkts Rx
: 7
Pkts Tx
: 7
Bytes Rx
: 532
Bytes Tx
: 364
Key Ignored Rx
: 0
Too Big Tx
: 0
Seq Ignored Rx
: 0
Vers Unsup. Rx
: 0
Invalid Chksum Rx: 0
Loops Rx
: 0

Advanced Configuration Guide

Page 957

Configuration

Interfaces
The interface toward the Internet (or WAN):

Can be a network interface or VPRN/IES interface.

Provide IP reachability.

The tunnel public interface:

Can be an IES or VPRN interface.

Represents the public side of the tunnel-ISA.

The delivery VPRN/IES service (the service connected to the Internet) must have at least one IP
interface associated with a public tunnel SAP in order to receive and process GRE encapsulated
packets.
The public tunnel SAP type has the format tunnel-id.private|public:tag (where the id corresponds
to the tunnel group) as shown in the following example.
*A:PE-1>config>service>ies>if# sap ?
tunnel-id

- tunnel-<id>.<private|public>:<tag>

*A:PE-1>config>service>ies# info
---------------------------------------------interface "int-tunnel-public" create
address 192.168.1.2/30
tos-marking-state untrusted
sap tunnel-1.public:1 create
exit
exit
no shutdown

Mask /32 is not supported on the public tunnel.


*A:PE-1>config>service>ies# interface "tunnel-public" sap tunnel-1.public:1 create
INFO: PIP #1288 Cannot bind when there are /32 or /128 addresses configured

The tunnel private interface:

Page 958

Can be an IES or VPRN interface.

Represents the private side of the tunnel-ISA.

Advanced Configuration Guide

IP/GRE Termination

The private tunnel SAP has the format tunnel-id.private|public:tag (where the id corresponds to
the tunnel-group) as shown in the following CLI example where an unprotected GRE tunnel is
configured under the SAP.
*A:PE-1>config>service>vprn>if# sap ?
tunnel-id

- tunnel-<id>.<private|public>:<tag>

*A:PE-1>config>service>vprn# info
-----------------------------------------------------------------snip-interface "int-gre-tunnel" tunnel create
address 10.0.0.1/30
ip-mtu 1476
bfd 100 receive 100 multiplier 3
sap tunnel-1.private:1 create
gre-tunnel "gre-tunnel-1" to 10.0.0.2 create
---snip---

It is not mandatory to have the same tag (internal dot1q) in private and public GRE tunnels.
sap tunnel-1.private:1 <=> sap tunnel-1.public:2

Advanced Configuration Guide

Page 959

Configuration

Unprotected GRE Tunnel Configuration


To associate an unprotected GRE tunnel with a private tunnel SAP the gre-tunnel command is
configured under the SAP context.
*A:PE-1>config>service>vprn# info
-----------------------------------------------------------------snip-interface "gre-tunnel" tunnel create
address 10.0.0.1/30
ip-mtu 1476
sap tunnel-1.private:1
gre-tunnel "gre-tunnel" to 10.0.0.2
---snip---

The to keyword followed by the private IP address of the remote tunnel endpoint is mandatory.
If this remote IP address is not within the subnet of the local private endpoint then the tunnel will
not come up.
Under the gre-tunnel command, configure the following parameters:

The source address of the GRE tunnel. This is the source IPv4 address of GRE
encapsulated packets sent by the delivery service. It must be an address in the subnet of
the associated public tunnel SAP interface.

The remote IP address. If this address is reachable in the delivery service (there is a route)
then this is the destination IPv4 address of GRE encapsulated packets sent by the delivery
service.

The backup remote IP address. If the remote IP address of the tunnel is not reachable then
this is the destination IPv4 address of GRE encapsulated packets sent by the delivery
service.

The delivery service. This is the identifier or name of the IES or VPRN service where
GRE encapsulated packets are injected and terminated. The delivery service can be the
same service where the private tunnel SAP interface resides.

The DSCP marking in the outer IP header of GRE encapsulated packets. If this is not
configured then the default copies the DSCP from the inner IP header to the outer IP
header.

*A:PE-1>config>service>vprn# info
-----------------------------------------------------------------snip-interface "gre-tunnel" tunnel create
address 10.0.0.1/30
ip-mtu 1476
bfd 100 receive 100 multiplier 3
sap tunnel-1.private:1 create

Page 960

Advanced Configuration Guide

IP/GRE Termination

gre-tunnel "gre-tunnel-1" to 10.0.0.2 create


source 192.168.1.1
remote-ip 192.168.0.1
delivery-service 2
dscp af22
no shutdown
exit

A private tunnel SAP can have only one GRE tunnel (per SAP).

*A:PE-1>config>service>vprn>if>sap# gre-tunnel "gre-tunnel-2" to 10.0.0.2 create


MINOR: SVCMGR #5120 Only one GRE tunnel allowed per SAP

Advanced Configuration Guide

Page 961

Configuration

IP/GRE Tunneling via Static Route


A static route can reference the GRE tunnel directly (by next-hop IP address) or the GRE tunnel
can be the resolved next-hop for an indirect static route (Figure 63).

Site A

Site B
PE-2

PE-1
Public IP
Network

VPRN

IP VPN
Service Provider

VPRN

GRE Tunnel
al_0135

Figure 63: GRE for Remote Access to a VPRN Service

The details of both ends on the GRE tunnel, at site A and PE-1, are shown in Figure 64.

ISA-Tunnel

ISA-Tunnel

Tunnel src IP:


192.168.0.1/30

sap tunnel-1.private:200
10.0.0.2/30

VPRN 1

Tunnel src IP:


192.168.1.1/30

sap tunnel-1.public:1
192.168.0.2/30

IES 2

sap tunnel-1.public:1
192.168.1.2/30
Internet

IES 2

sap tunnel-1.private:1
10.0.0.1/30

VPRN 1

al_0136

Figure 64: IP/GRE Tunneling via Static Route

The following shows the configuration of PE-1.


A:PE-1# configure service vprn 1
A:PE-1>config>service>vprn# info
---------------------------------------------route-distinguisher 64496:1
vrf-target target:64496:1
interface "int-gre-tunnel" tunnel create
address 10.0.0.1/30
ip-mtu 1476

Page 962

Advanced Configuration Guide

IP/GRE Termination

sap tunnel-1.private:1 create


gre-tunnel "gre-tunnel-1" to 10.0.0.2 create
source 192.168.1.1
remote-ip 192.168.0.1
delivery-service 2
no shutdown
exit
exit
exit
static-route 172.16.1.1/32 next-hop 10.0.0.2

To check the static route status:


*A:PE-1# show router 1 static-route
===============================================================================
Static Route Table (Service: 1) Family: IPv4
===============================================================================
Prefix
Tag
Met
Pref Type Act
Next Hop
Interface
------------------------------------------------------------------------------172.16.1.1/32
0
1
5
NH
Y
10.0.0.2
int-gre-tunnel
------------------------------------------------------------------------------No. of Static Routes: 1

Advanced Configuration Guide

Page 963

Configuration

IP/GRE Tunneling via BGP Peering


In this section, the configuration has BGP running inside the GRE tunnel (the only supported
routing protocol in SR-OS 8.0R5).
*A:PE-1>config>service>vprn# info
---------------------------------------------router-id 192.0.2.2
autonomous-system 64496
route-distinguisher 64496:1
vrf-target target:64496:1
interface "int-gre-tunnel" tunnel create
address 10.0.0.1/30
ip-mtu 1476
sap tunnel-1.private:1 create
gre-tunnel "gre-tunnel-1" to 10.0.0.2 create
source 192.168.1.1
remote-ip 192.168.0.1
delivery-service 2
no shutdown
exit
exit
static-route 172.16.1.1/32 next-hop 10.0.0.2
bgp
local-as 64496
router-id 192.0.2.2
group "group-1"
type internal
local-as 64496
local-address 172.32.1.1
neighbor 172.16.1.1
exit
exit
no shutdown
exit

It is mandatory to configure the autonomous-system under the VPRN otherwise the BGP
neighboring will not be established.
To check the BGP status:
*A:PE-1# show router 1 bgp neighbor
===============================================================================
BGP Neighbor
===============================================================================
Peer : 172.16.1.1
Group : group-1
------------------------------------------------------------------------------Peer AS
: 64496
Peer Port
: 179
Peer Address
: 172.16.1.1
Local AS
: 64496
Local Port
: 49554
Local Address
: 172.32.1.1
Peer Type
: Internal
State
: Established
Last State
: Active
---snip---

Page 964

Advanced Configuration Guide

IP/GRE Termination

IP/GRE Tunneling via OSPFv2 Peering


From SR-OS 9.0R1, OSPFv2 can be run on IES and VPRN IP interfaces associated with private
GRE tunnel SAPs.
All OSPF features are supported including area 0 and non-area 0 support, virtual links,
authentication, BFD, configurable protocol timers.
*A:PE-1>config>service>vprn# info
---------------------------------------------router-id 192.0.2.2
route-distinguisher 64496:1
vrf-target target:64496:1
interface "int-gre-tunnel" tunnel create
address 10.0.0.1/30
ip-mtu 1476
bfd 100 receive 100 multiplier 3
sap tunnel-1.private:1 create
gre-tunnel "gre-tunnel-1" to 10.0.0.2 create
source 192.168.1.1
remote-ip 192.168.0.1
delivery-service 2
no shutdown
exit
exit
exit
ospf
area 0.0.0.0
interface "int-gre-tunnel"
exit
interface "int-CE-1"
interface-type point-to-point
exit
exit
exit
no shutdown

To check the OSPF status:


*A:PE-1# show router 1 ospf neighbor
===============================================================================
OSPF Neighbors
===============================================================================
Interface-Name
Rtr Id
State
Pri RetxQ
TTL
Area-Id
------------------------------------------------------------------------------int-gre-tunnel
192.0.2.1
Full
1
0
30
0.0.0.0
------------------------------------------------------------------------------No. of Neighbors: 1
===============================================================================

Advanced Configuration Guide

Page 965

Configuration

To check the OSPF routes:


*A:PE-1# show router 1 route-table protocol ospf
===============================================================================
Route Table (Service: 1)
===============================================================================
Dest Prefix[Flags]
Type
Proto
Age
Pref
Next Hop[Interface Name]
Metric
------------------------------------------------------------------------------172.16.1.1/32
Remote OSPF
00h04m58s
10
10.0.0.2
10
-------------------------------------------------------------------------------

Page 966

Advanced Configuration Guide

IP/GRE Termination

IP/GRE Tunneling Protection using IPSec Tunnel Mode


To provide protection against the potential threats (such as spoofing) the GRE packets can be
encrypted and authenticated using IPSec.
In SR-OS 9.0R1 GRE packets receive IPSec protection by forwarding them, after encapsulation
by one tunnel-ISA, into an IPSec tunnel supported by another (or the same) tunnel-ISA.
Note that when configuring GRE protection by an IPSec tunnel:

A GRE tunnel and its protecting IPSec tunnel may belong to the same or different tunnelgroups (the same tunnel-group is assumed in the example below).

A GRE tunnel and its protecting IPSec tunnel may be assigned to the same tunnel-ISA (if
they belong to the same tunnel-group) or different tunnel-ISAs.

A single IPSec tunnel can protect one or more GRE tunnels in addition to other IP traffic
that meets the IPSec security policy.

The private IPSec tunnel SAP interface and public GRE tunnel SAP interface are always
part of the same VPRN. The private GRE tunnel SAP interface can be part of this same
VPRN or a different VPRN.

In the following example the GRE tunnel and its protecting IPSec tunnel belong to the same tunnel
group.

Router CE-1

10.0.0.8

VRPN 3

Router PE-1

IES 4

IES 4

192.168.3.2

Tunnel
Group 1

10.1.1.2

10.0.0.6

Tunnel
Group 1

10.2.2.2

IPsec Tunnel (Public Side)


IPsec Tunnel (Private Side)
GRE Tunnel
Tunnel Group 1

1/2

VRPN 3
192.168.4.2

Tunnel Group 1

Public SAP
Private SAP

1/2
al_0137

Figure 65: Example GRE over IPSec Tunnel

Advanced Configuration Guide

Page 967

Configuration

IPSec Configuration
An ike-policy and ipsec-transform must be configured as shown below.
*A:PE-1>config>ipsec# info
---------------------------------------------ike-policy 1 create
dh-group 5
exit
ipsec-transform 1 create
esp-encryption-algorithm aes256
exit
----------------------------------------------

The public/private side of the GRE tunnel and the private side of the IPSec tunnel are in the same
VPRN, as shown in the following configuration example.
*A:PE-1# configure service vprn 3
*A:PE-1>config>service>vprn# info
---------------------------------------------ipsec
security-policy 1 create
entry 1 create
local-ip 192.168.4.0/24
remote-ip 192.168.3.0/24
exit
exit
exit
route-distinguisher 64496:3
vrf-target target:64496:3
interface "int-private-ipsec-1" tunnel create
sap tunnel-1.private:3 create
ipsec-tunnel "ipsec-tunnel-for-gre-tunnel" create
security-policy 1
local-gateway-address 10.2.2.1 peer 10.1.1.1 delivery-service 4
dynamic-keying
ike-policy 1
pre-shared-key "ALU"
transform 1
exit
no shutdown
exit
exit
exit
interface "int-public-gre-1" create
address 192.168.4.2/24
sap tunnel-1.public:4 create
exit
exit
interface "int-private-gre-1" tunnel create
address 10.0.0.6/30
sap tunnel-1.private:5 create
gre-tunnel "protected-gre-tunnel" to 10.0.0.5 create
source 192.168.4.1
remote-ip 192.168.3.1
delivery-service 3

Page 968

Advanced Configuration Guide

IP/GRE Termination

no shutdown
exit
exit
exit
static-route 192.168.3.0/24 ipsec-tunnel "ipsec-tunnel-for-gre-tunnel"
no shutdown

The following displays a configuration example of the public side of the IPSec tunnel:
*A:PE-1>config>service>ies# info
---------------------------------------------interface "public-ipsec-1" create
address 10.2.2.2/24
tos-marking-state untrusted
sap tunnel-1.public:3 create
exit
exit

To check the GRE tunnel:


*A:PE-1# show gre tunnel
===============================================================================
GRE Tunnels
===============================================================================
TunnelName
LocalAddress
SvcId
Admn
SapId
RemoteAddress
DlvrySvcId Oper
To
Bkup RemAddr
DSCP
Oper Rem Addr
------------------------------------------------------------------------------protected-gre-tunnel
192.168.4.1
3
Up
tunnel-1.private:5
192.168.3.1
3
Up
10.0.0.5
None
192.168.3.1
-------------------------------------------------------------------------------

To check the GRE tunnel info:


*A:PE-1# show gre tunnel "gre-tunnel-1"
===============================================================================
GRE Tunnel Configuration Detail
===============================================================================
Service Id
: 1
Sap Id
: tunnel-1.private:1
Tunnel Name
: gre-tunnel-1
Description
: None
Target Address
: 10.0.0.2
Delivery Service : 2
Admin State
: Up
Oper State
: Up
Source Address
: 192.168.1.1
Oper Remote Addr : 192.168.0.1
Remote Address
: 192.168.0.1
Backup Address
:
DSCP
: None
Oper Flags
: None
===============================================================================
GRE Tunnel Statistics: gre-tunnel-1
===============================================================================
Errors Rx
: 0
Errors Tx
: 0
Pkts Rx
: 9164
Pkts Tx
: 14176
Bytes Rx
: 703812
Bytes Tx
: 750429

Advanced Configuration Guide

Page 969

Configuration

Key Ignored Rx
: 0
Seq Ignored Rx
: 0
Vers Unsup. Rx
: 0
Invalid Chksum Rx: 0
Loops Rx
: 0

Too Big Tx

: 0

By default the IPSec tunnel is down if it is not used by any traffic.


*A:PE-1# show ipsec tunnel
===============================================================================
IPsec Tunnels
===============================================================================
TunnelName
LocalAddress
SvcId
Admn
Keying
SapId
RemoteAddress
DlvrySvcId
Oper
Sec
Plcy
------------------------------------------------------------------------------ipsec-tunnel-for-gre-tunnel
10.2.2.1
3
Up
Dynamic
tunnel-1.private:3
10.1.1.1
4
Down
1
-------------------------------------------------------------------------------

Once it is used by any traffic the status will be changed to be up.


*A:PE-1# ping
PING 10.0.0.5
64 bytes from
64 bytes from
64 bytes from
64 bytes from
64 bytes from

router 3 10.0.0.5
56 data bytes
10.0.0.5: icmp_seq=1
10.0.0.5: icmp_seq=2
10.0.0.5: icmp_seq=3
10.0.0.5: icmp_seq=4
10.0.0.5: icmp_seq=5

ttl=64
ttl=64
ttl=64
ttl=64
ttl=64

time=4.64ms.
time=4.54ms.
time=4.42ms.
time=5.01ms.
time=4.40ms.

To check the IPSec tunnel:


*A:PE-1# show ipsec tunnel
===============================================================================
IPsec Tunnels
===============================================================================
TunnelName
LocalAddress
SvcId
Admn
Keying
SapId
RemoteAddress
DlvrySvcId
Oper
Sec
Plcy
------------------------------------------------------------------------------ipsec-tunnel-for-gre-tunnel
10.2.2.1
3
Up
Dynamic
tunnel-1.private:3
10.1.1.1
4
Up
1
------------------------------------------------------------------------------IPsec Tunnels: 1
===============================================================================

Page 970

Advanced Configuration Guide

IP/GRE Termination

BFD Support on Private Tunnel Interfaces


The SR-OS 9.0R1 introduces support for BFD on IP interfaces associated with private GRE tunnel
SAPs. The BFD state of the interface can be used by static routes, OSPFv2 and/or BGP configured
on the interface. It is not used to trigger a switch over to the backup remote IP address of the GRE
tunnel.
The following displays a static-route example:
*A:PE-1>config>service>vprn# info
---------------------------------------------router-id 192.0.2.2
route-distinguisher 64496:1
vrf-target target:64496:1
interface "int-gre-tunnel" tunnel create
address 10.0.0.1/30
ip-mtu 1476
bfd 100 receive 100 multiplier 3
sap tunnel-1.private:1 create
gre-tunnel "gre-tunnel-1" to 10.0.0.2 create
source 192.168.1.1
remote-ip 192.168.0.1
delivery-service 2
no shutdown
exit
exit
exit
static-route 172.16.1.1/32 next-hop 10.0.0.2 bfd-enable

To check the BFD session:


*A:PE-1# show router 1 bfd session
===============================================================================
BFD Session
===============================================================================
Interface
State
Tx Intvl Rx Intvl Multipl
Remote Address
Protocols
Tx Pkts
Rx Pkts
Type
------------------------------------------------------------------------------gre-tunnel
Up (3)
100
100
3
10.0.0.2
static
N/A
N/A
cpm-np
------------------------------------------------------------------------------No. of BFD sessions: 1
===============================================================================

Advanced Configuration Guide

Page 971

Configuration

The following displays an OSPF example:


*A:PE-1>config>service>vprn# info
---------------------------------------------router-id 192.0.2.2
route-distinguisher 64496:1
vrf-target target:64496:1
interface "int-gre-tunnel" tunnel create
address 10.0.0.1/30
ip-mtu 1476
bfd 100 receive 100 multiplier 3
sap tunnel-1.private:1 create
gre-tunnel "gre-tunnel-1" to 10.0.0.2 create
source 192.168.1.1
remote-ip 192.168.0.1
delivery-service 2
no shutdown
exit
exit
exit
ospf
area 0.0.0.0
interface "int-gre-tunnel"
bfd-enable
exit
---snip--

To check the BFD session:


*A:PE-1# show router 1 bfd session
===============================================================================
BFD Session
===============================================================================
Interface
State
Tx Intvl Rx Intvl Multipl
Remote Address
Protocols
Tx Pkts
Rx Pkts
Type
------------------------------------------------------------------------------int-gre-tunnel
Up (3)
100
100
3
10.0.0.2
ospf2
N/A
N/A
cpm-np
-------------------------------------------------------------------------------

The following displays a BGP example:


*A:PE-1>config>service>vprn# info
---------------------------------------------router-id 192.0.2.2
autonomous-system 64496
route-distinguisher 64496:1
vrf-target target:64496:1
interface "int-gre-tunnel" tunnel create
address 10.0.0.1/30
ip-mtu 1476
bfd 100 receive 100 multiplier 3
sap tunnel-1.private:1 create
gre-tunnel "gre-tunnel-1" to 10.0.0.2 create
source 192.168.1.1
remote-ip 192.168.0.1

Page 972

Advanced Configuration Guide

IP/GRE Termination

delivery-service 2
no shutdown
exit
exit
exit
static-route 172.16.1.1/32 next-hop 10.0.0.2
bgp
local-as 64496
router-id 192.0.2.2
group "group-1"
type internal
local-as 64496
local-address 172.32.1.1
neighbor 172.16.1.1
bfd-enable
exit
exit
no shutdown
exit

To check the BFD session:


*A:PE-1# show router 1 bfd session
===============================================================================
BFD Session
===============================================================================
Interface
State
Tx Intvl Rx Intvl Multipl
Remote Address
Protocols
Tx Pkts
Rx Pkts
Type
------------------------------------------------------------------------------int-CE-1
Up (3)
100
100
3
172.16.1.1
bgp
N/A
N/A
cpm-np
------------------------------------------------------------------------------No. of BFD sessions: 1
===============================================================================

Advanced Configuration Guide

Page 973

Configuration

IP/GRE Termination Advanced Topics


DSCP Value of Outer Delivery Header

Default behavior The DSCP value from the Payload header is copied into the outer
GRE header. This is a one to one copy and no QoS classifications are required. It is
performed when no DSCP value is configured under the private gre-tunnel.

Non Default behavior DSCP is configured under the private SAP (example below
using af41).

interface "gre-tunnel" tunnel create


address 10.0.0.1/30
sap tunnel-1.private:200 create
gre-tunnel "gre-tunnel" to 10.0.0.2
source 192.168.11.2
remote-ip 192.168.10.2
delivery-service 21
dscp af41

The log filter output: TOS=88 (DSCP=af41) in the public network.


Maximum entries configured : 1000
Number of entries logged
: 2
2010/12/13 18:26:15 Ip Filter: 10:10 Desc:
SAP: 1/1/1 Direction: Egress Action: Forward
Src MAC: 1c-2c-01-01-00-01 Dst MAC: 1c-2d-01-01-00-01 EtherType: 0800
Src IP: 192.168.11.2 Dst IP: 192.168.10.2 Flags: 0 TOS: 88 TTL: 254

IP-MTU
It is possible to configure the IP MTU of a private tunnel SAP interface. This sets the maximum IP
packet size payload (including IP header) that can be sent into the tunnel (it applies to the packet
size before the tunnel encapsulation is added).
vprn 1 customer 1 create
router-id 172.17.1.1
autonomous-system 650000
route-distinguisher 65000:1
interface "gre-tunnel" tunnel
address 10.0.0.1/30
ip-mtu 1476
sap tunnel-1.private:201

Page 974

Advanced Configuration Guide

IP/GRE Termination

When an IPv4 packet needs to be forwarded to the tunnel and is larger than IP MTU bytes:

If the DF bit is clear, the payload packet is IP fragmented to the MTU size prior to tunnel
encapsulation.

If the DF bit is set, the payload packet is discarded.

The IP-MTU range supported is from 512 to 9000 bytes.


To display information about the tunnel operational MTU.
*A:PE-1# show router 1 interface
IP Oper MTU
: 1476

"gre-tunnel" detail | match MTU


ICMP Mask Reply
: True

Statistics and Accounting


Collect-stats can be configured under public and private SAPs.
For Public SAPs:
*A:PE-1>config>service>ies>if# sap tunnel-1.public:2 collect-stats

For Private SAPs:


*A:PE-1>config>service>vprn>if# sap tunnel-1.private:2 collect-stats

Filtering, Policing and QoS


An ip-filter and QoS policy can be applied to the ingress and egress traffic of the private and
public SAPS.
Public SAPs:
*A:PE-1>config>service>vprn>if# info
------------------------------------------------snip--sap tunnel-1.private:1 create
ingress
qos 10
filter ip 1
exit
egress
qos 10
filter ip 1
exit

Advanced Configuration Guide

Page 975

Configuration

Private SAPs:
*A:PE-1>config>service>ies>if# info
---------------------------------------------address 192.168.1.2/30
tos-marking-state untrusted
sap tunnel-1.public:1 create
ingress
qos 10
filter ip 1
exit
egress
qos 10
filter ip 1
exit

Mirroring
The public and private SAPs can be mirrored.
*A:PE-1# show debug
debug
mirror-source 99
sap tunnel-1.private:3 egress ingress
sap tunnel-1.public:1 egress ingress
no shutdown
exit
exit

Page 976

Advanced Configuration Guide

IP/GRE Termination

Conclusion
This section provides configuration and show commands for IP/GRE termination.

Advanced Configuration Guide

Page 977

Conclusion

Page 978

Advanced Configuration Guide

IPv4 DHCP Hosts

In This Chapter
This section provides information about IPv4 DHCP host configurations.
Topics in this section include:

Applicability on page 980

Summary on page 981

Overview on page 982

Configuration on page 986

Conclusion on page 1022

Advanced Configuration Guide

Page 979

Applicability

Applicability
This section is applicable to the 7450 ESS, 7750 SR and 7710 SR series and was tested on SR-OS
7.0 R6. The 7750 SR-c4 is supported from 8.0R4 and higher. This note is related only to the use of
IPv4.
For Bridged CO, configuration and troubleshooting commands are taken from a 7450 ESS
(typically positioned as BSA); this functionality is also available on 7750 SR and 7710 SR.
For Routed CO, configuration and troubleshooting commands are taken from a 7750 SR; this
functionality is also available on 7710 SR. Routed CO is supported on 7450 ESS-7 or ESS-12 in
mixed-mode since 8.0R1.

Page 980

Advanced Configuration Guide

IPv4 DHCP Hosts

Summary
In the Triple Play Service Delivery Architecture (TPSDA), a subscriber is defined as a collection
of hosts pertaining to a single access connection (such as a DSL line) and identified by a
subscriber identifier. A subscriber host is an end user terminal within the subscriber home (for
example, a PC, set-top box, home gateway) that is identified in the network with a unique (IP
address; MAC address) tuple for IPoE or (PPPoE session ID; MAC address) tuple for PPPoE.
Following host types are distinguished:

Static hosts
ip-mac
ip-only

Dynamic hosts
ARP-host
DHCP-host
PPPoE-host

This section provides configuration and troubleshooting commands for DHCP-hosts.


Knowledge of the Alcatel-Lucent Triple Play Service Delivery Architecture (TPSDA) concepts is
assumed throughout this document.

Advanced Configuration Guide

Page 981

Overview

Overview
The network topology for a Bridged CO environment is displayed in Figure 66 and for a Routed
CO environment in Figure 67.

RADIUS Server
DHCP Server

DSL,
GPON

DHCP
Host
BSA-1

BSAN
L2 DHCP
Relay Agent

DHCP
Client

BSR-1
DHCP
Snooping

PE-1

DHCP
Relay Agent

DHCP
Server

L2 DHCP
Relay Agent
DHCP
Proxy
OSSG388

Figure 66: Bridged CO Network Topology

RADIUS Server
DHCP Server

DSL,
GPON

DHCP
Host
BSAN

DHCP
Client

L2 DHCP
Relay Agent

PE-1

BSR-1
DHCP
Relay Agent

DHCP
Server

DHCP
Proxy
OSSG394

Figure 67: Routed CO Network Topology

Page 982

Advanced Configuration Guide

IPv4 DHCP Hosts

Following configuration tasks should be done first and are not detailed in this configuration note:

Basic service router configurations such as system interface, IGP, MPLS, BGP.

Bridged CO service topology: VPLS on BSA-1, terminated in a VPRN or IES service on


BSR-1.

Routed CO service topology: VPRN or IES service with subscriber and group interface on
BSR-1.

External DHCP server: Server configuration and connectivity in the VPRN or base router
instance.

External RADIUS server: server configuration and connectivity in the VPRN or base
router instance (Enhanced Subscriber Management (ESM) only).

This section focuses on DHCP hosts instantiated in a VPLS service on BSA-1 (Bridged CO) or in
a VPRN service subscriber interface on BSR-1 (Routed CO). Note that in case of Routed CO, it is
also possible to instantiate the DHCP hosts in the base routing instance using an IES service.
Most of the DHCP host functionality is available with Basic Subscriber Management (BSM).
When ESM is required, it is explicitly stated in the section.

Advanced Configuration Guide

Page 983

Overview

Review of the DHCP Protocol


The DHCP protocol is used by a DHCP server to dynamically assign IP addresses and other
optional configuration parameters to DHCP clients. These parameters are leased by the DHCP
server for a duration specified by the lease time.
The DHCP lease process is outlined in Figure 68.
RADIUS Server
DHCP Server
Gateway IP Address
(gi-address)

DHCP Client Subnet


DSL,
GPON

BSAN
DHCP
Client

L2 DHCP
Relay Agent

BSA-1

PE-1

BSR-1

L2 DHCP
Relay Agent

DHCP
Relay Agent

DHCP
Server

DHCP-DISCOVER

Initial
Binding

DHCP-OFFER
DHCP-REQUEST
DHCP-ACK
DHCP-REQUEST

Renew
Release

DHCP-ACK
DHCP-RELEASE

= DHCP Option 82 - Relay


Agent Information Insertion
(Optional)

= L3 Broadcast; Can Also


Be L2 Broadcast If The
DHCP Client Sets The
Broadcastg Flag In The
Discover/Request Message

= Unicast

OSSG389

Figure 68: DHCP Lease Process

When a DHCP client boots, a DHCP discover message is broadcasted on the local subnet (dest-ip
= 255.255.255.255).
A DHCP server in the local subnet responds with a unicast DHCP offer message containing the
your ip address field as well as other configuration parameters in the option fields (such as subnet
mask, default gateway, DNS server IP addresses, lease time, etc.).
The DHCP client responds with a DHCP request message to accept the parameters specified in the
DHCP offer. The DHCP request is also broadcasted on the local subnet.

Page 984

Advanced Configuration Guide

IPv4 DHCP Hosts

The DHCP server acknowledges the DHCP request with a unicast DHCP ack message.
When the DHCP client receives a DHCP ack from the server, it is said to be in the bound state.
When half of the lease time has expired, the DHCP client tries to renew the lease. It will send a
unicast DHCP request message to the DHCP server. The DHCP server will reply to the request
with a unicast DHCP ack to the client.
If the renew failed, a rebind is attempted by default at 7/8 of the lease time. It will send a broadcast
DHCP request message.
Before disconnecting from the local subnet, a DHCP client may return its lease by sending a
DHCP release message to the DHCP server.
In case there is no DHCP server in the subnet of the DHCP client, a DHCP relay agent is needed to
forward the broadcast DHCP discover/request messages on behalf of the DHCP client to a DHCP
server located on a different subnet. The DHCP relay agent will add the gateway IP address field
to the messages and send them as unicast to the DHCP server IP address. The DHCP server in this
case will respond by unicast to the DHCP relay agent. The DHCP relay agent forwards the DHCP
server messages as broadcast on the DHCP client subnet.

Advanced Configuration Guide

Page 985

Configuration

Configuration
DHCP Snooping
DHCP client packets (discover, request, release) must be snooped (intercepted and sent to the
control plane for further processing) to allow for DHCP Option 82 insertion, RADIUS or local
user database authentication and releasing the DHCP host session state.
For Bridged CO, DHCP snooping must be enabled explicitly on the subscriber SAP:
Bridged CO
configure
service
vpls 1 customer 1 create
- - - snip - - sap 1/1/2:1 split-horizon-group "rshg-1" create
description "sub-1"
dhcp
snoop
no shutdown
exit
exit

DHCP server packets (offer, ack, nak, etc.) must be snooped to allow for DHCP Option 82
removal, lease state population and/or ESM functions.
For Bridged CO, DHCP snooping must be enabled explicitly on all SDPs and/or SAPs that
provide connectivity to the DHCP server:
Bridged CO:
configure
service
vpls 1 customer 1 create
- - - snip - - spoke-sdp 1:1 create
dhcp
snoop
exit
exit

For Routed CO, DHCP snooping is implicitly enabled by configuring a DHCP relay agent (DHCP
Relay Agent on page 987): All DHCP messages received on a routed network interface will be
snooped (for example, intercepted and sent to the control plane for further processing).

Page 986

Advanced Configuration Guide

IPv4 DHCP Hosts

DHCP Relay Agent


For Bridged CO, the DHCP relay agent function is configured at the IP edge (BSR):
Bridged CO:
configure
service
vprn 1 customer 1 create
- - - snip - - interface "int-BSA1-p2mp-1" create
description "Bridged CO"
address 10.1.0.254/16
dhcp
server 172.16.0.1
trusted
gi-address 10.1.0.254
no shutdown
exit
ip-mtu 1500
spoke-sdp 1:1 create
exit
exit

For Routed CO, the DHCP relay agent function must be configured at BSR-1 group-interface
level where the DHCP host will be instantiated:
Routed CO:
configure
service
vprn 1 customer 1 create
- - - snip - - subscriber-interface "sub-int-1" create
description "Routed CO"
address 10.2.0.254/16
group-interface "group-int-1" create
dhcp
server 172.16.0.1
trusted
gi-address 10.2.0.254
no shutdown
exit

The server IP address should point to the DHCP server and must be reachable in the same routing
instance as where the (subscriber-)interface is defined.
The trusted command makes the interface a trusted interface to allow Option 82 insertion by a
Layer 2 DHCP relay agent (see DHCP Options (Relay Agent Information) on page 989).

Advanced Configuration Guide

Page 987

Configuration

The gi-address must be a local configured IP address on the (subscriber-)interface. The relayed
DHCP messages to the DHCP server will have the outgoing interface IP address as source IP
address. To change the default behavior and use the configured gi-address as source IP address,
specify the optional src-ip-addr flag:
CLI Syntax: gi-address 10.2.0.254 src-ip-addr

A Layer 2 DHCP relay agent (such as BSAN or BSA) can add DHCP Option 82 information and
leave the gi-address field to 0.0.0.0. The gi-address is the gateway IP address, filled in by the
DHCP relay agent. An incoming DHCP discover with Option 82 present and gi-address field =
0.0.0.0 will be dropped by the DHCP relay agent according the RFC. The Rx Untrusted Packets
and client Packets Discarded counters are increased in the DHCP statistics.
Output from DHCP debug log on BSR-1:
DROPPED DHCP Boot Request on Interface group-int-1 (1/1/3:1) Port 67
Problem: message is received from an untrusted client

Therefore, the DHCP relay agent should be configured as trusted to allow DHCP Option 82
insertion by a Layer 2 DHCP relay agent.

Page 988

Advanced Configuration Guide

IPv4 DHCP Hosts

DHCP Options (Relay Agent Information)


In Bridged CO, when DHCP snooping is enabled on a VPLS SAP, DHCP Option 82 relay agent
information can be altered or added on an incoming DHCP discover/request. This is sometimes
referred to as a Layer 2 DHCP relay agent function.
In Routed CO, a DHCP relay agent can alter or add the DHCP Option 82 relay agent information
on an incoming DHCP discover/request.
Supported DHCP Option 82 sub-options and their format are listed in Table 19:
Table 19: Supported DHCP Option 82 Sub-Options
Option 82 Sub-Option
Opt82 [1] Circuit ID (Routed
CO)

Format

Example

ifindex 32 bit virtual router ID followed by a 32


bit ifindex in hex

00 00 00 02 00 00 00 04

sap-id [sap id in ascii]

1/1/3:1

ascii3-tuple [system-name|service-id|groupinterface|sap-id]

Opt82 [1] Circuit ID (Bridged


CO)

Opt82 [2] Remote ID (Bridged


and Routed CO)

Opt82 [9] Vendor Specific


(Bridged and Routed CO)

Opt82 [9] Vendor Specific


(Routed CO)

vlan-ascii-tuple [system-name|service-id|groupinterface|dot1p|vlan-id]

BSR-1|1|group-int-1|0|1

ascii-tuple [system-name|service-id|sap-id]

BSA-1|1|1/1/2:1

vlan-ascii-tuple [system-name|service-id|sap-id
|dot1p|vlan-id]

BSA-1|1|1/1/2:1|0|1

MAC [client hw address in hex]

fe fd 00 02 45 00

string (max. 32 chars)

Opt-82 [2] Remote ID

[1] system-id [hostname in ascii]

BSA-1 or BSR-1

[2] client-mac-address [client hw address in hex]

fe fd 00 02 45 00

[3] service-id

[4] sap-id [sap id in ascii]

1/1/2:1

[5] string (max. 32 chars)

Opt-82 [9] [5] string

[13] pool-name [dhcp pool name from Radius/


Local User DB in ascii

dhcp-pool-1

Advanced Configuration Guide

Page 989

Configuration

Note: The application for Option 82 Circuit-ID format vlan-ascii-tuple is to preserve the Dot1p
marking of DHCP packets in the downstream direction (DHCP server to client). The dot1p value
of the incoming DHCP discover/request is recorded as part of the Option 82 Circuit ID. The
outgoing DHCP offer/ack packets are marked with the Dot1p value found as part of the Circuit ID
echoed by the DHCP server.
Possible actions on incoming DHCP discover/request:

Replace:
At ingress:
If present, remove all the Option 82 information from the incoming DHCP discover/
request. Insert the configured DHCP options before forwarding to the DHCP relay agent
or DHCP server
At egress:
Remove all Option 82 information from the incoming DHCP offer/ack before forwarding
to the client.

Bridged CO:
configure
service
vpls 1 customer 1 create
- - - snip - - sap 1/1/2:1 split-horizon-group "rshg-1" create
dhcp
snoop
option
action replace
circuit-id
remote-id string "Opt-82 [2] - Remote ID"
vendor-specific-option
system-id
client-mac-address
service-id
sap-id
string "Opt-82 [9][5] - Vendor

Routed CO:
configure
service
vprn 1 customer 1 create
- - - snip - - subscriber-interface "sub-int-1" create
description "Routed CO"
address 10.2.0.254/16
group-interface "group-int-1" create
dhcp
option
action replace
circuit-id
remote-id string "Opt-82 [2] Remote ID"

Page 990

Advanced Configuration Guide

IPv4 DHCP Hosts

vendor-specific-option
system-id
client-mac-address
pool-name
service-id
sap-id
string "Opt-82 [9][5] string"
exit
exit
server 172.16.0.1
trusted
gi-address 10.2.0.254
no shutdown
exit

Drop:
Drop all incoming DHCP discover/request with Option 82 information present.
The Client Packets Dropped counter is increased in the DHCP statistics:
Bridged CO:
A:BSA-1# show service id 1 dhcp statistics
=====================================================
DHCP Statistics, service 1
=====================================================
Client Packets Snooped
: 130
Client Packets Forwarded
: 125
Client Packets Dropped
: 5
Client Packets Proxied (RADIUS)
: 0
Client Packets Proxied (Lease-Split) : 0
Server Packets Snooped
: 64
Server Packets Forwarded
: 64
Server Packets Dropped
: 0
DHCP RELEASEs Spoofed
: 0
DHCP FORCERENEWs Spoofed
: 0
=====================================================
A:BSA-1#

Routed CO:
*A:BSR-1# show router 1 dhcp statistics

or
*A:BSR-1# show service id 1 dhcp statistics
========================================================
DHCP Global Statistics, service 1
========================================================
Rx Packets
: 28469
Tx Packets
: 28402
Rx Malformed Packets
: 0
Rx Untrusted Packets
: 4

Advanced Configuration Guide

Page 991

Configuration

Client Packets Discarded


: 4
Client Packets Relayed
: 14251
Client Packets Snooped
: 12
Client Packets Proxied (RADIUS)
: 0
Client Packets Proxied (Lease-Split) : 0
Server Packets Discarded
: 0
Server Packets Relayed
: 14191
Server Packets Snooped
: 7
DHCP RELEASEs Spoofed
: 0
DHCP FORCERENEWs Spoofed
: 0
========================================================
*A:BSR-1#

Output from the DHCP debug log:


Bridged CO BSA-1 VPLS service:
"SVCMGR: Dropped DHCP Packet
VPLS 1, SAP 1/1/2:1
Problem: port config doesn't allow BOOTP/DHCP packets with Option 82"

Routed CO BSR-1 VPRN service:


"PIP: DHCP
instance 2 (1), interface index 4 (group-int-1),
DROPPED DHCP Boot Request on Interface group-int-1 (1/1/3:1) Port 67
Problem: action drop is configured and packet contains Option 82

Incoming DHCP discover/request without Option 82 information will be forwarded to


(Bridged CO) or processed by (Routed CO) the DHCP relay agent as is, ignoring the
configured options.

Bridged CO:
configure
service
vpls 1 customer 1 create
- - - snip - - sap 1/1/2:1 split-horizon-group "rshg-1" create
dhcp
snoop
option
action drop
exit
no shutdown
exit

Page 992

Advanced Configuration Guide

IPv4 DHCP Hosts

Routed CO:
configure
service
vprn 1 customer 1 create
- - - snip - - subscriber-interface "sub-int-1" create
description "Routed CO"
address 10.2.0.254/16
group-interface "group-int-1" create
dhcp
option
action drop
exit
server 172.16.0.1
trusted
gi-address 10.2.0.254
no shutdown
exit

Advanced Configuration Guide

Page 993

Configuration

Keep (default):

At ingress Incoming DHCP discover/request without Option 82 information will be


forwarded to (Bridged CO) or processed by (Routed CO) the DHCP relay agent as is,
ignoring any configured option.

At ingress for incoming DHCP discover/request with Option 82 information present


Configured vendor specific options will be merged with the existing Option 82
information before sending to (Routed CO) or processing by (Routed CO) the DHCP
relay agent. Configured Circuit ID and Remote ID options will be ignored.

At egress Remove Option 82 vendor specific information from the incoming DHCP
offer/ack before forwarding to the client. Other existing DHCP Option 82 information is
kept.

Bridged CO:
configure
service
vpls 1 customer 1 create
- - - snip - - sap 1/1/2:1 split-horizon-group "rshg-1" create
dhcp
snoop
option
action keep
exit
no shutdown
exit

Routed CO:
configure
service
vprn 1 customer 1 create
- - - snip - - subscriber-interface "sub-int-1" create
description "Routed CO"
address 10.2.0.254/16
group-interface "group-int-1" create
dhcp
option
action keep
exit
server 172.16.0.1
trusted
gi-address 10.2.0.254
no shutdown
exit

Page 994

Advanced Configuration Guide

IPv4 DHCP Hosts

DHCP Lease State


The DHCP lease state is an internal database structure that keeps track of the DHCP host states.
The DHCP lease state enables subscriber management functions (per-subscriber QoS and
accounting) and security functions (dynamic anti-spoof filtering) on the DHCP host.
The DHCP lease information for a specific host is extracted from the DHCP ack message.
Table 20 displays some typical information stored in the DHCP lease state. The table does not
display all information: additional data is added for managed SAPs, DHCPv6, etc.

Table 20: Information in DHCP Lease State


Parameter

Comment

Service ID

Service where the DHCP host is connected

IP Address

IP address of the DHCP host

Client HW Address

Ethenet MAC address of the DHCP host

Subscriber-interface
(Routed CO only)

Subscriber interface name where the DHCP host is instantiated

Group-interface (Routed
CO only)

Group interface name where the DHCP host is instantiated

SAP

SAP where the DHCP hosts is connected

Remaining Lifetime

The remaining time before the DHCP host is deleted from the system
(updated each time a DHCP renew/rebind occurs)

Persistence Key

Lookup key for this host in the persistency file (see further)

Sub-Ident

ESM: Subscriber ID of the DHCP host

Sub-Profile-String

ESM: Subscriber profile string of the DHCP host

SLA-Profile-String

ESM: SLA profile string of the DHCP host

App-Profile-String

ESM: Application profile string of the DHCP host

Lease ANCP-String

ESM: ANCP string for this DHCP host

Lease Int Dest Id

ESM: Internal destination ID for this DHCP host

Category-Map-Name

ESM: Volume and Time based accounting

Sub-Ident origin

ESM: Origin for the Subscriber ID for this host (None, DHCP,
RADIUS, etc.)

Strings origin

ESM: Origin for the ESM strings for this host (None, DHCP, RADIUS,
etc.)

Advanced Configuration Guide

Page 995

Configuration

Table 20: Information in DHCP Lease State (Continued)


Parameter

Page 996

Comment

Lease Info origin

ESM: Origin for the IP configuration for this host (None, DHCP,
RADIUS, etc.)

Ip-Netmask

The IP netmask for this DHCP host

Broadcast-Ip-Addr

The broadcast IP address for this host

Default-Router

The default gateway for this host

Primary-Dns

The primary DNS server for this host

Secondary-Dns

The secondary DNS server for this host

Primary-Nbns

The primary NetBIOS name server for this host

Secondary-Nbns

The secondary NetBIOS name server for this host

ServerLeaseStart

Time and date that the lease for this host started (first DHCP ack
received)

ServerLastRenew

Time and date that the lease for this host was last renewed

ServerLeaseEnd

Time and date that the lease for this host will expire

Session-Timeout

Lease time specified by the DHCP server

DHCP Server Addr

IP address of the DHCP server that allocated the lease for this host

Circuit Id

DHCP Relay Agent information Option 82 Circuit ID content

Remote Id

DHCP Relay Agent information Option 82 Remote ID content

RADIUS User-Name

ESM: Username used in the RADIUS authentication access request

Advanced Configuration Guide

IPv4 DHCP Hosts

For Bridged CO, the population of the DHCP lease state must be enabled through configuration.
The number of leases allowed on the VPLS SAP must be specified. When omitted, a single DHCP
host is allowed per SAP.
Bridged CO:
configure
service
vpls 1 customer 1 create
- - - snip - - sap 1/1/2:1 split-horizon-group "rshg-1" create
dhcp
snoop
lease-populate 10
no shutdown
exit

For Routed CO, DHCP lease state population is enabled by default on a group interface with
DHCP configured as no shutdown The number of leases allowed on the group-interface must be
configured (by default a single DHCP host is allowed per group-interface):
Routed CO:
configure
service
vprn 1 customer 1 create
- - - snip - - subscriber-interface "sub-int-1" create
description "Routed CO"
address 10.2.0.254/16
group-interface "group-int-1" create
dhcp
server 172.16.0.1
trusted
lease-populate 10
gi-address 10.2.0.254
no shutdown
exit

To check the DHCP lease state for a particular service, use the show service id service-id dhcp
lease-state command. Detailed output as well as additional output filtering is available:
Bridged CO:
A:BSA-1# show service id 1 dhcp lease-state ?
- lease-state [sap <sap-id>|sdp <sdp-id:vc-id>|interface
<interface-name>ip-address <ip-address[/mask]>|chaddr <ieee-address>|mac
<ieee-address>|{[port <port-id>] [no-inter-dest-id | inter-dest-id
<inter-dest-id>]}] [detail]

Advanced Configuration Guide

Page 997

Configuration

Routed CO:
*A:BSR-1# show service id 1 dhcp lease-state ?
- lease-state [wholesaler <service-id>] [sap <sap-id>|sdp <sdp-id:vc-id>|
interface <interface-name>|ip-address <ip-address[/mask]>|chaddr
<ieee-address>|mac <ieee-address>|{[port <port-id>] [no-inter-dest-id |
inter-dest-id <inter-dest-id>]}] [detail]
Bridged CO
*A:BSA-1# show service id 1 dhcp lease-state detail
===============================================================================
DHCP lease states for service 1
===============================================================================
Service ID
: 1
IP Address
: 10.1.0.100
Client HW Address
: fe:fd:00:02:45:00
SAP
: 1/1/2:1
Remaining Lifetime
: 00h09m50s
Persistence Key
: 0x00000001
Sub-Ident
Sub-Profile-String
SLA-Profile-String
App-Profile-String
Lease ANCP-String
Lease Int Dest Id
Category-Map-Name

:
:
:
:
:
:
:

""
""
""
""
""
""
""

Sub-Ident origin
Strings origin
Lease Info origin

: None
: None
: DHCP

Ip-Netmask
Broadcast-Ip-Addr
Default-Router
Primary-Dns
Secondary-Dns
Primary-Nbns
Secondary-Nbns

:
:
:
:
:
:
:

255.255.0.0
N/A
10.1.0.254
N/A
N/A
N/A
N/A

ServerLeaseStart
ServerLastRenew
ServerLeaseEnd
Session-Timeout
DHCP Server Addr

:
:
:
:
:

11/20/2009 14:00:18
11/20/2009 14:00:18
11/20/2009 14:10:18
0d 00:10:00
172.16.0.1

Relay Agent Information


Circuit Id
: BSA-1|1|1/1/2:1
Remote Id
: Opt-82 [2] - Remote ID
Radius User-Name
: ""
------------------------------------------------------------------------------Number of lease states : 1
===============================================================================
*A:BSA-1#

Page 998

Advanced Configuration Guide

IPv4 DHCP Hosts

Routed CO:
*A:BSR-1# show service id 1 dhcp lease-state detail
===============================================================================
DHCP lease states for service 1
===============================================================================
Service ID
: 1
IP Address
: 10.2.0.100
Client HW Address
: fe:fd:00:02:45:00
Subscriber-interface : sub-int-1
Group-interface
: group-int-1
SAP
: 1/1/3:1
Remaining Lifetime
: 00h09m48s
Persistence Key
: N/A
Sub-Ident
Sub-Profile-String
SLA-Profile-String
App-Profile-String
Lease ANCP-String
Lease Int Dest Id
Category-Map-Name

:
:
:
:
:
:
:

""
""
""
""
""
""
""

Sub-Ident origin
Strings origin
Lease Info origin

: None
: None
: DHCP

Ip-Netmask
Broadcast-Ip-Addr
Default-Router
Primary-Dns
Secondary-Dns
Primary-Nbns
Secondary-Nbns

:
:
:
:
:
:
:

255.255.0.0
N/A
10.2.0.254
N/A
N/A
N/A
N/A

ServerLeaseStart
ServerLastRenew
ServerLeaseEnd
Session-Timeout
DHCP Server Addr

:
:
:
:
:

11/26/2009 18:03:24
11/26/2009 18:03:24
11/26/2009 18:13:24
0d 00:10:00
172.16.0.1

Relay Agent Information


Circuit Id
: Circuit-ID sub-1
Remote Id
: Remote-ID sub-1
Radius User-Name
: ""
------------------------------------------------------------------------------Number of lease states : 1
===============================================================================
*A:BSR-1#

Advanced Configuration Guide

Page 999

Configuration

DHCP Host Session: Set-up, Operation and Release


Snooping the DHCP communication between a DHCP client and a DHCP relay agent/server
facilitates the DHCP host instantiation: Upon the reception of a DHCP ack message from the
server, the DHCP lease state is populated. With ESM enabled, a DHCP host is also instantiated.
The DHCP host will appear in the subscriber-host table for the service with origin set to ?HCP?
Bridged CO:
*A:BSA-1# show service id 1 subscriber-hosts
===============================================================================
Subscriber Host table
===============================================================================
Sap
IP Address
MAC Address
PPPoE-SID Origin
Subscriber
------------------------------------------------------------------------------1/1/2:1
10.1.0.100
fe:fd:00:02:45:00 N/A
DHCP
sub-1
------------------------------------------------------------------------------Number of subscriber hosts : 1
===============================================================================
*A:BSA-1#

Routed CO
*A:BSR-1# show service id 1 subscriber-hosts
===============================================================================
Subscriber Host table
===============================================================================
Sap
IP Address
MAC Address
PPPoE-SID Origin
Subscriber
Fwding state
------------------------------------------------------------------------------1/1/3:1
10.2.0.100
fe:fd:00:02:45:00 N/A
DHCP
N/A
Fwding
------------------------------------------------------------------------------Number of subscriber hosts : 1
===============================================================================
*A:BSA-1#

If ESM is enabled, the subscriber-host will also appear in the active subscriber table:
Routed CO:
A:BSR-1# show service active-subscribers
===============================================================================
Active Subscribers
===============================================================================
------------------------------------------------------------------------------Subscriber sub-1 (sub-profile-1)
------------------------------------------------------------------------------------------------------------------------------------------------------------(1) SLA Profile Instance sap:1/1/3:1 - sla:sla-profile-1
------------------------------------------------------------------------------IP Address
MAC Address
PPPoE-SID Origin

Page 1000

Advanced Configuration Guide

IPv4 DHCP Hosts

------------------------------------------------------10.2.0.100
fe:fd:00:02:45:00 N/A
DHCP
------------------------------------------------------------------------------Number of active subscribers : 1
===============================================================================
*A:BSA-1#

Troubleshooting the DHCP session set-up is done with DHCP debugging:


Bridged CO:
*A:BSA-1# debug service id 1 dhcp ?
- dhcp
- no dhcp
[no]
[no]
[no]
[no]
[no]

detail-level
mac
mode
sap
sdp

Configure
Show DHCP
Configure
Show DHCP
Show DHCP

the DHCP tracing detail level


packets for a particular MAC address
the DHCP tracing mode
packets for a particular SAP
packets for a particular SDP

Routed CO:
*A:BSR-1# debug router 1 ip dhcp ?
- dhcp [interface <ip-int-name>]
- dhcp mac <ieee-address>
- dhcp sap <sap-id>
- no dhcp [interface <ip-int-name>]
- no dhcp mac <ieee-address>
- no dhcp sap <sap-id>
- - - snip - - [no] detail-level
- Configure the DHCP tracing detail level
[no] mode
- Configure the DHCP tracing model

For example:
Bridged CO:
*A:BSA-1# show debug
debug
service
id 1
dhcp
mode egr-ingr-and-dropped
detail-level medium
exit
exit
exit
exit

Advanced Configuration Guide

Page 1001

Configuration

Routed CO:
*A:BSR-1# show debug
debug
router "1"
ip
dhcp
detail-level medium
mode egr-ingr-and-dropped
exit
exit
exit
exit

Note: The example above will log all DHCP packets on the service. When thousands of DHCP
hosts are active, more granular filtering is required: for example look only to dropped packets or
look only to packets from a particular MAC address.
To display the debugging information, a dedicated log should be created:
*A:BSA-1# configure log
*A:BSA-1>config>log# info
---------------------------------------------log-id 1
description "Send debug log to the current telnet/ssh session"
from debug-trace
to session
exit
---------------------------------------------*A:BSA-1#

The following shows sample DHCP debug log output (detail-level medium):
Bridged CO:
28 2009/11/23 12:53:05.28 CET MINOR: DEBUG #2001 Base SVCMGR
"SVCMGR: TX DHCP Packet
VPLS 1, SAP 1/1/2:1
BootReply to UDP port 68
ciaddr: 0.0.0.0
yiaddr: 10.1.0.100
siaddr: 0.0.0.0
giaddr: 0.0.0.0
chaddr: fe:fd:00:02:45:00
xid: 0x6b230c18
DHCP options:
[82] Relay agent information: len = 25
[1] Circuit-id: MyCircuitID
[2] Remote-id: MyRemoteID
[53] Message type: Ack
[54] DHCP server addr: 172.16.0.1
[51] Lease time: 1200
[1] Subnet mask: 255.255.0.0
[3] Router: 10.1.0.254
[255] End
"

Page 1002

Advanced Configuration Guide

IPv4 DHCP Hosts

During the lifetime of a DHCP host, the DHCP lease state is updated in the system: for example,
the remaining lifetime after a DHCP renew. To check lease details from the DHCP host during its
lifetime, consult the DHCP lease state details:
*A:BSA-1# show service id 1 dhcp lease-state detail
- - - snip - - # see above for a sample output

If the remaining lifetime timer expires before the DHCP session is renewed or rebound, the DHCP
lease state is cleared. If ESM is enabled, the DHCP host is removed from the system.
A DHCP host can be manually deleted from the system using following clear command:
*A:BSA-1# clear service id 1 dhcp lease-state ?
- lease-state [no-dhcp-release]
- lease-state [port <port-id>] [inter-dest-id <intermediate-destination-id>]
[no-dhcp-release]
- lease-state [port <port-id>] no-inter-dest-id [no-dhcp-release]
- lease-state ip-address <ip-address[/mask]> [no-dhcp-release]
- lease-state mac <ieee-address> [no-dhcp-release]
- lease-state sap <sap-id> [no-dhcp-release]
- lease-state sdp <sdp-id:vc-id> [no-dhcp-release]
*A:BSA-1# clear service id 1 dhcp lease-state ip-address 10.1.0.100

The DHCP lease state is deleted and all related state (such as, anti-spoof filter, ARP table entry). If
ESM is enabled, the DHCP host is removed from the system. Optionally, a DHCP release is sent
to the DHCP server to notify that the IP address can be released. This is reflected in the DHCP
statistics in the DHCP RELEASEs Spoofed counter. Use the no-dhcp-release flag in the clear
command if no DHCP release is to be sent when issuing the clear command.
To display a summary overview of the DHCP configuration on a particular service:
Bridged CO:
*A:BSA-1# show service id 1 dhcp summary
=======================================================================
DHCP Summary, service 1
=======================================================================
Sap/Sdp
Snoop Used/
Arp Reply
Info
Admin
Provided
Agent
Option
State
----------------------------------------------------------------------sap:1/1/2:1
Yes
1/2
Yes
Keep
Up
sap:1/1/2:2
Yes
0/1
Yes
Keep
Up
sdp:1:1
Yes
N/A
N/A
N/A
N/A
----------------------------------------------------------------------Number of Entries : 3
----------------------------------------------------------------------=======================================================================
*A:BSA-1#

Advanced Configuration Guide

Page 1003

Configuration

Routed CO:
*A:BSR-1# show service id 1 dhcp summary
===============================================================================
DHCP Summary, service 1
===============================================================================
Interface Name
Arp
Used/
Info
Admin
SapId/Sdp
Populate Provided
Option State
------------------------------------------------------------------------------group-int-1
No
1/2
Keep
Up
------------------------------------------------------------------------------Interfaces: 2
===============================================================================
*A:BSA-1#

The Used/Provided field indicates the number of active versus the number of allowed DHCP
leases on the SAP, SDP or interface.
To check the DHCP statistics, use the following command:
Bridged CO:
*A:BSA-1# show service id 1 dhcp statistics
=====================================================
DHCP Statistics, service 1
=====================================================
Client Packets Snooped
: 474
Client Packets Forwarded
: 474
Client Packets Dropped
: 0
Client Packets Proxied (RADIUS)
: 0
Client Packets Proxied (Lease-Split) : 0
Server Packets Snooped
: 472
Server Packets Forwarded
: 469
Server Packets Dropped
: 3
DHCP RELEASEs Spoofed
: 0
DHCP FORCERENEWs Spoofed
: 0
=====================================================
*A:BSA-1#

Routed CO:
*A:BSR-1# show router 1 dhcp statistics
====================================================================
DHCP Global Statistics (Service: 1)
====================================================================
Rx Packets
: 28532
Tx Packets
: 28450
Rx Malformed Packets
: 0
Rx Untrusted Packets
: 4
Client Packets Discarded
: 20
Client Packets Relayed
: 14259
Client Packets Snooped
: 29
Client Packets Proxied (RADIUS)
: 0
Client Packets Proxied (Lease-Split) : 0
Server Packets Discarded
: 0
Server Packets Relayed
: 14199

Page 1004

Advanced Configuration Guide

IPv4 DHCP Hosts

Server Packets Snooped


: 21
DHCP RELEASEs Spoofed
: 1
DHCP FORCERENEWs Spoofed
: 0
====================================================================
*A:BSA-1#

Note additional filtering can be done to retrieve DHCP statistics per SAP, SDP or interface.
To clear the DHCP statistics:
Bridged CO:
*A:BSA-1# clear service id 1 dhcp statistics ?
- statistics [sap <sap-id> | sdp <sdp-id:vc-id> | interface <ip-int-name|
ip-address>]

Routed CO:
*A:BSR-1# clear router 1 dhcp statistics
- statistics [<ip-int-name|ip-address>]
<ip-int-name|ip-ad*> : ip-int-name
ip-address

Advanced Configuration Guide

- 32 chars max
- a.b.c.d

Page 1005

Configuration

DHCP Hosts Advanced Topics


High Availability
The DHCP lease state supports High Availability (HA): the lease state is synchronized to the
standby CPM. When the active CPM fails, all DHCP hosts stay active without service
interruption.

DHCP Lease State Persistency


A DHCP session does not have a keep-alive mechanism to detect unavailability. A new DHCP
session set up is only attempted after expiration of the DHCP lease time. A node reboot causing
the loss of DHCP lease state and the corresponding anti-spoof filters could therefore result in
unacceptable long service outages.
The DHCP lease state can be made persistent across node reboots: DHCP lease state is restored
from a persistency file stored on the compact flash file system. As a result, DHCP sessions will
only loose connectivity during the time of reboot without being completely disconnected.
To activate the DHCP lease state persistency:
configure
system
persistence
subscriber-mgmt
description "DHCP lease state persistency"
location cf2:
exit
exit

A dedicated persistency file will be created on the specified compact flash file system. The file is
initialized to store the maximum number of allowed hosts; its size is fixed to avoid file system
space problems during operations.
*A:BSA-1# file dir cf2:
Volume in drive cf2 on slot A has no label.
Volume in drive cf2 on slot A is formatted as FAT32.
Directory of cf2:\
11/23/2009

Page 1006

02:01p
1 File(s)
0 Dir(s)

536871424 submgmt.005
536871424 bytes.
1558183424 bytes free.

Advanced Configuration Guide

IPv4 DHCP Hosts

Each time a DHCP ack is received from the DHCP server, the persistency file is updated together
with the lease state. If the file update fails, an event is generated to indicate that persistency can
not be guaranteed.
The content of the persistency file may vary between different SR-OS software releases. When
upgrading, the persistency file is automatically upgraded to the new format. To downgrade the
persistency file to a lower SR-OS release version, use the following command:
*A:BSA-1# tools perform subscriber-mgmt downgrade ?
- downgrade target-version <target> [reboot]
<target>

<reboot>

: The version you want to downgrade to


7.0 (current) - submgmt.005
6.0
- submgmt.004
5.0
- submgmt.003
4.0
- submgmt.pst
: reboot system after successful conversion

The content of the persistency file can be looked at using the following command:
*A:BSA-1# show service id 1 dhcp lease-state sap 1/1/2:2 detail
===============================================================================
DHCP lease states for service 1
===============================================================================
Service ID
: 1
IP Address
: 10.1.0.99
Client HW Address
: fe:fd:00:02:46:00
SAP
: 1/1/2:2
Remaining Lifetime
: 00h07m17s
Persistence Key
: 0x00000005
- - - snip - - ===============================================================================
*A:BSA-1#

*A:BSA-1# tools dump persistence submgt record 0x00000005


----------------------------------Persistency File Record
----------------------------------Filename
: cf2:\submgmt.005
Key
: 00000005
Last Update : 2009/11/23 14:58:17 (UTC)
Action
: UPDATE
Data :
Host Type
: DHCP lease state
Service ID
: 1
SAP ID
: 1/1/2:2
IP
: 10.1.0.99
CHADDR
: fe:fd:00:02:46:00
NH MAC
: fe:fd:00:02:46:00
Srvr Lse Start : 2009/11/23 14:30:02 (UTC)
Srvr Last Renew: 2009/11/23 14:58:17 (UTC)
Srvr Lse End
: 2009/11/23 15:08:17 (UTC)
Srvr Addr
: 172.16.0.1
Option82
: 10 bytes
Option60
: 0 bytes
Sub-ID
: NULL

Advanced Configuration Guide

Page 1007

Configuration

Sub-prof-ID
: NULL
SLA-prof-ID
: NULL
App-prof-ID
: NULL
ANCP-Str
: NULL
Int-dest-ID
: NULL
Cat-map-str
: NULL
Dhcp6 Pfx len : 32
Dhcp6 CfgPfxLen: 0
Dhcp6 Client Id: NULL
Dhcp6 Iaid
: 0
Dhcp6 Iaid Typ : 0
Dhcp6 Client Mg: ::
Sub-Id is def : NO
MSap SvcId
: 0
MSap PolicyId : 0
MSap IfIndex
: 0
Managed routes : None
BgpPrngPlcyAttr: None
Class Attr
: 0 bytes
Radius Username:
===============================================================================
*A:BSA-1#

Page 1008

Advanced Configuration Guide

IPv4 DHCP Hosts

Limiting the Number of DHCP Hosts


The maximum number of DHCP lease state entries for a VPLS SAP or IES/VPRN (group-)
interface is defined when enabling the lease-populate. When omitted, a single DHCP host is
allowed:
configure
service
vpls 1 customer 1 create
- - - snip - - sap 1/1/2:2 split-horizon-group "rshg-1" create
dhcp
snoop
lease-populate 10
no shutdown
exit

When trying to instantiate a new DHCP host while the configured number of leases is reached, the
DHCP ack is dropped (DHCP debug log output):
13 2009/11/23 15:35:27.85 CET MINOR: DEBUG #2001 Base SVCMGR
"SVCMGR: Dropped DHCP Packet
VPLS 1, SAP 1/1/2:10
Problem: lease-populate limit (10) exceeded on SAP 1/1/2:2
- - - snip - - -

The following event is generated:


158 2009/11/23 15:35:27.86 CET WARNING: DHCP #2002 Base Maximum number of lease states*
"Lease state for (CiAddr = 10.1.0.98, ChAddr = fe:fd:00:02:47:00, leaseTime = 600) was not
stored because the number of DHCP lease states on SAP 1/1/2:2 in service 1 has reached its
upper limit"

With ESM enabled, the following limits also apply:

sla-profile host-limit This parameter defines the maximum number of dynamic


subscriber hosts per subscriber for this sla-profile. Static hosts are not counted in the hostlimit.

configure
subscriber-mgmt
sla-profile "sla-profile-1" create
host-limit 2

If the configured host-limit is reached for a subscriber, access is denied for a new host, an event is
generated and the corresponding DHCP ack message is dropped:
866 2009/11/25 12:04:04.42 CET WARNING: DHCP #2005 Base Lease State Population Error
"Lease state table population error on SAP 1/1/2:1 in service 1 - subscriber sub-1 sla-profile sla-profile-1, host-limit (2) exceeded"

Advanced Configuration Guide

Page 1009

Configuration

Note: An optional parameter remove-oldest can be specified behind the host-limit. In this ca se,
the new host is accepted and the DHCP lease state for the oldest host (with the least remaining
lease time) is cleared. A DHCP release is sent to the DHCP server.

multi-sub-sap This parameter defines the maximum number of subscribers (dynamic


and static) that can be simultaneously active on this SAP. By default only a single
subscriber is allowed (no multi-sub-sap).

Bridged CO:
configure
service
vpls 1 customer 1 create
sap 1/1/2:1 split-horizon-group "rshg-1" create
sub-sla-mgmt
multi-sub-sap 2

Routed CO:
configure
service
vprn 1 customer 1 create
subscriber-interface "sub-int-1" create
group-interface "group-int-1" create
sap 1/1/3:1 create
sub-sla-mgmt
multi-sub-sap 2

If the limit is reached, a new subscriber will be denied access, an event is generated and the
corresponding DHCP ack message is dropped:
1404 2009/11/25 13:20:03.47 CET WARNING: DHCP #2005 Base Lease State Population Error
"Lease state table population error on SAP 1/1/2:1 in service 1 - Number of subscribers
exceeds the configured multi-sub-sap limit (2)"

Page 1010

Advanced Configuration Guide

IPv4 DHCP Hosts

DHCP Host Connectivity Verification


Because the DHCP protocol does not have a keep-alive mechanism and IP address renewal is not
frequent enough, alternative mechanisms are needed to track reachability of DHCP hosts.
1. Subscriber Host Connectivity Verification (SHCV)
The first alternative is called Subscriber Host Connectivity Verification (SHCV). A periodic
unicast ARP is sent to the DHCP host. The connectivity test is failed:
If for X consecutive unicast ARP requests no ARP reply is received within the specified
retry-timeout ([10 60] seconds, default 10). The number of retries (X-1) is specified by
the retry-count ([2 29], default 2). Hence, the minimum 3 unicast ARP requests are
send before connectivity is lost.
If the ARP reply contains an inconsistent IP/MAC compared with the local DHCP lease
state
For a failed connectivity test, an event is raised and optionally the DHCP lease state is
removed from the system: cleaning up of all related resources (e.g. anti-spoof table) and
sending a DHCP release to the DHCP server. When ESM is enabled, the DHCP host is
removed as well in this case.
The interval for the periodic checks can be configured between 1 and 6000 minutes. If not
specified, the default value of 10 minutes will be used.
The maximum time for DHCP host connectivity loss detection in this case is:
( (host-connectivity-verify interval) + ( (retry-count) * (retry-timeout) ) )

Advanced Configuration Guide

Page 1011

Configuration

RADIUS Server
DHCP Server

DSL,
GPON

DHCP
Host
BSA-1

BSAN
DHCP
Client

L2 DHCP
Relay Agent

PE-1

BSR-1
DHCP
Proxy

DHCP
Relay Agent

DHCP
Server

DHCP-DISCOVER
DHCP-OFFER
DHCP-REQUEST
DHCP-ACK

ESM

ARP request (SSHCV Periodic Check)

Successful
SHCV Check

ARP reply

SHCV
Statistics
Updated

SHCV
Interval

ARP request (SHCV Periodic Check)

Host Disconnects
Without Sending
DHCP-Release

ARP request (SHCV Periodic Check)

SHCV retry-timeout

ARP request (SHCV Periodic Check)

SHCV retry-timeout
SHCV retry-timeout

First Retry
Last Retry Defined
By Retry-Count

Host Connectivity Lost Event

SHCV
Statistics
Updated

= RADIUS Authentication And Authorization


(Optional)

ESM = ESM Subscriber Management


Update (Optional)
OSSG392

Figure 69: Subscriber Host Connectivity Verification

*A:BSA-1>config>service>vpls>sap# host-connectivity-verify ?
- host-connectivity-verify source-ip <ip-address> [source-mac
<ieee-address>] [interval <interval>] [action {remove|alarm}] [timeout
<retry-timeout>] [retry-count <count>]
<ip-address>
<ieee-address>
<interval>
<{remove|alarm}>
<retry-timeout>
<count>

Page 1012

:
:
:
:
:
:

a.b.c.d
xx:xx:xx:xx:xx:xx or xx-xx-xx-xx-xx-xx
[1..6000] minutes
keywords
[10..60] seconds
[2..29]

Advanced Configuration Guide

IPv4 DHCP Hosts

Bridged CO:
configure
service
vpls 1 customer 1 create
sap 1/1/2:2 split-horizon-group "rshg-1" create
host-connectivity-verify source-ip 0.0.0.0 interval 1 action remove
exit

Note: the configured source IP should be an unused unique IP address in the DHCP client subnet
or alternatively use source-ip 0.0.0.0. As the host-connectivity-verify application is sending a
unicast ARP to the DHCP host, its ARP table is updated with the configured source-ip and sourcemac (chassis MAC if not configured). If you would use an existing IP address, the DHCP host
ARP table gets poisoned, breaking the connectivity to that host.
Routed CO:
configure
service
vprn 1 customer 1 create
subscriber-interface "sub-int-1" create
group-interface "group-int-1" create
host-connectivity-verify interval 1 action alarm

Note: the source IP is not configurable. The source-ip used in the unicast ARP is fixed to the local
subscriber interface address in the subnet of the DHCP hosts that is checked for connectivity.
To verify the result of the connectivity check:
*A:BSA-1# show service id 1 host-connectivity-verify statistics
===============================================================================
Host connectivity check statistics
===============================================================================
Svc
SapId/
DestIp
Timestamp
Time since Oper
Id
SdpId
Address
last-reply/conn-lost
Reply/Lost State
------------------------------------------------------------------------------1
1/1/2:2
10.1.0.99
11/23/2009 17:26:45
0d 00:00:44 Up
------------------------------------------------------------------------------1 host-connectivity states : 1 Up / 0 Down / 0 Retry pending
===============================================================================
*A:BSA-1#

In case the connectivity is lost with the host, following event is generated:
836 2009/11/23 17:28:24.74 CET WARNING: SVCMGR #2206 Base Host connectivity lost
"host connectivity lost on 1/1/2:2 in service 1 for inetAddr = 10.1.0.99,
chAddr=fe:fd:00:02:46:00."

Advanced Configuration Guide

Page 1013

Configuration

With action alarm, the lease-state is not removed in case the connectivity is lost with the host. The
event is still generated and the statistics show:
*A:BSA-1# show service id 1 host-connectivity-verify statistics
===============================================================================
Host connectivity check statistics
===============================================================================
Svc
SapId/
DestIp
Timestamp
Time since Oper
Id
SdpId
Address
last-reply/conn-lost
Reply/Lost State
------------------------------------------------------------------------------1
1/1/2:2
10.1.0.99
11/23/2009 17:38:28
0d 00:01:42 Down
------------------------------------------------------------------------------1 host-connectivity states : 0 Up / 1 Down / 0 Retry pending
===============================================================================
*A:BSA-1#

Event in case of restored connectivity:


839 2009/11/23 17:41:07.74 CET WARNING: SVCMGR #2207 Base Host connectivity restored
"host connectivity restored on 1/1/2:2 in service 1, for inetAddr = 10.1.0.99,
chAddr=fe:fd:00:02:46:00."

Connectivity to a DHCP host can also be checked using an OAM command:


*A:BSA-1# oam host-connectivity-verify service 1 sap 1/1/2:2
==============================================================================
Triggering host connectivity verify for service 1 sap 1/1/2:2 ...
Waiting 3 seconds ...
===============================================================================
Host connectivity check statistics
===============================================================================
Svc
SapId/
DestIp
Timestamp
Time since Oper
Id
SdpId
Address
last-reply/conn-lost
Reply/Lost State
------------------------------------------------------------------------------1
1/1/2:2
10.1.0.99
------------------------------------------------------------------------------1 host-connectivity states : 0 Up / 0 Down / 1 Retry pending
===============================================================================
*A:BSA-1#

Note that in this case, no action is triggered. If the connectivity test is successful, the hostconnectivity-verify statistics are updated with the new timestamp last-reply. If the connectivity
test fails, the host-connectivity state becomes Retry Pending (oper state unknown) until an
automatic test is scheduled again in the next interval.

Page 1014

Advanced Configuration Guide

IPv4 DHCP Hosts

To troubleshoot host-connectivity-verify, enable following debug log (additional filtering is


possible on ip address, mac address and/or SAP):
debug
service
id 1
host-connectivity-verify
exit
exit
exit
exit

Advanced Configuration Guide

Page 1015

Configuration

DHCP Lease Split


The second alternative is using a DHCP proxy server with the lease-split option.
A finer granularity of DHCP lease time is used between the DHCP client and the DHCP proxy
server than between the DHCP proxy server and the DHCP server.
The maximum time for DHCP host connectivity loss detection in this case is the configured
DHCP lease-split lease time.
DHCP communication is snooped between the DHCP client and DHCP server. In the DHCP ack
message, the offered lease-time from the DHCP server is replaced with the configured DHCP
proxy server lease-split lease time. Note that the lease time is only updated if the configured leasesplit lease time is less than half of the original lease time value. The minimum value for the proxy
server lease-split lease time is 5 minutes. When the DHCP client renews the DHCP session, the
DHCP proxy server sends a DHCP ack on behalf of the DHCP server as long as the next renew
time is earlier than half of the DHCP server expiry time for this session. With ESM enabled,
RADIUS re-authentication will occur only when the DHCP request must be sent to the DHCP
server. In other words, configuring a DHCP proxy with lease-split does not put extra load on the
RADIUS server.
In the example below, the DHCP server offers a lease time of 960 seconds. The lease time in the
offer sent to DHCP client will be updated with the lease time of 300 seconds as configured in the
DHCP proxy server lease-split on BSA-1.
Bridged CO:
configure
service
vpls 1 customer 1 create
sap 1/1/2:2 split-horizon-group "rshg-1" create
dhcp
proxy-server
lease-time min 5
no shutdown
exit

Routed CO:
configure
service
vprn 1 customer 1 create
subscriber-interface "sub-int-1" create
group-interface "group-int-1" create
dhcp
proxy-server
lease-time min 5
no shutdown
exit

Page 1016

Advanced Configuration Guide

IPv4 DHCP Hosts

Note: the emulated server address in the DHCP proxy-server configuration does not have to be
configured for lease-split operation. This parameter is needed for an alternative use of the DHCP
proxy server: RADIUS based IP configuration of a subscriber host. This is out of the scope of this
configuration note.
If DHCP lease split is operational for a DHCP host, it will be shown in the Remaining Lifetime
field of the detailed lease-state output. Note that the Session Timeout field is the original offered
lease time from the DHCP server.
*A:BSA-1# show service id 1 dhcp lease-state detail
===============================================================================
DHCP lease states for service 1
===============================================================================
Service ID
: 1
IP Address
: 10.1.0.99
Client HW Address
: fe:fd:00:02:46:00
SAP
: 1/1/2:2
Remaining Lifetime
: 00h04m26s (Lease Split)
Persistence Key
: 0x0000000e
Sub-Ident
Sub-Profile-String
SLA-Profile-String
App-Profile-String
Lease ANCP-String
Lease Int Dest Id
Category-Map-Name

:
:
:
:
:
:
:

""
""
""
""
""
""
""

Sub-Ident origin
Strings origin
Lease Info origin

: None
: None
: DHCP

Ip-Netmask
Broadcast-Ip-Addr
Default-Router
Primary-Dns
Secondary-Dns
Primary-Nbns
Secondary-Nbns

:
:
:
:
:
:
:

255.255.0.0
N/A
10.1.0.254
N/A
N/A
N/A
N/A

ServerLeaseStart
ServerLastRenew
ServerLeaseEnd
Session-Timeout
DHCP Server Addr

:
:
:
:
:

11/23/2009 17:38:27
11/24/2009 15:27:57
11/24/2009 15:37:57
0d 00:10:00
172.16.0.1

Relay Agent Information


Circuit Id
: UML246
RADIUS User-Name
: ""
------------------------------------------------------------------------------Number of lease states : 1
===============================================================================
*A:BSA-1#

Advanced Configuration Guide

Page 1017

Configuration

RADIUS Server
DHCP Server

DSL,
GPON

DHCP
Host
BSAN

DHCP
Client

L2 DHCP
Relay Agent

BSA-1

PE-1

BSR-1
DHCP
Proxy

DHCP
Relay Agent

DHCP
Server

DHCP-DISCOVER
DHCP-OFFER

Initial
Binding

DHCP-REQUEST

ESM
DHCP-ACK
[51] Lease Time: 300

Update lease-time.

DHCP-REQUEST

Renew
In 150s

150s passed and next renew in 150s


-> no need to renew server yet.

DHCP-ACK
[51] Lease Time: 300

300s passed and next renew in 150s


-> no need to renew server yet.

DHCP-REQUEST
DHCP-ACK
[51] Lease Time: 300

ESM

= DHCP Option 82 - Relay Agent


Information Insertion (Optional)

Next Renew
Expected In
480s

450s passed and next renew in 150s


-> time to renew server !
DHCP-REQUEST

DHCP-REQUEST

DHCP-ACK
[51] Lease Time: 300

DHCP-ACK
[51] Lease Time: 960

DHCP-ACK
[51] Lease Time: 960
Update lease-time.

ESM = ESM Subscriber Management


Update (Optional)
OSSG390

Figure 70: DHCP Proxy Server: Lease Split Operation

When the DHCP client disconnects without sending a DHCP release in the network, the DHCP
lease state in the BSA/BSR will be removed only when the DHCP lease time expires. With DHCP
proxy server lease-split, the DHCP client disconnection can be sped up. In the example below, the
DHCP client disconnection is detected in less than 5 minutes (lease-split lease time) while it
would have taken up to 16 minutes without the lease-split. Note that the values are illustrative; in
reality the DHCP lease times will be higher.

Page 1018

Advanced Configuration Guide

IPv4 DHCP Hosts

RADIUS Server
DHCP Server

DSL,
GPON

DHCP
Host
BSAN

DHCP
Client

L2 DHCP
Relay Agent

BSA-1
BSR-1
DHCP
Proxy

PE-1

DHCP
Relay Agent

DHCP
Server

DHCP-DISCOVER
DHCP-OFFER

Initial
Binding

DHCP-REQUEST

ESM
Renew
In 150s

DHCP-ACK
[51] Lease Time: 300
DHCP-REQUEST
DHCP-ACK
[51] Lease Time: 300

DHCP-ACK
[51] Lease Time: 960
Update lease-time.
150s passed and next renew in 150s
-> no need to renew server yet.

Next Renew Expected in 150s


Host Disconnects
Without Sending
DHCP-Release

Next Renew
Expected In
480s

DHCP-RELEASE

After 300s: DHCP Lease


Time Expired
Clean Up Lease State
Send DHCP Release
= RADIUS Authentication And Authorization
(Optional)

ESM = ESM Subscriber Management


Update (Optional)
OSSG391

Figure 71: DHCP Proxy Server: Lease Split Operation, DHCP Client Disconnected

Advanced Configuration Guide

Page 1019

Configuration

DHCP Host Mobility


A field technician verifying DSLAM operation often connects and disconnects from different
ports rapidly. This will require the node to clear its own DHCP host state, the DHCP server? state
as well as flush MAC addresses learned within the VPLS network or clear ARP entries from the
routing instance.
A DHCP request comes in on SAP2. On SAP1 there exists a lease state with the same Client
Hardware address. The packet is dropped and a forced SHCV check verifies the existing lease
state on SAP1. Three consecutive checks are launched with a timeout of 10 seconds. If the host
indeed moved form SAP1 to SAP2, the connectivity check will fail on SAP1. The existing lease
state is deleted and a DHCP release message is sent to the DHCP server. Any subsequent DHCP
session setup will proceed as normal.
RADIUS Server
DHCP Server
DHCP
Host
Circuit 1

SAP1

DSL,
GPON

SAP2

Circuit 2
BSAN
DHCP
Client

Circuit 2
Circuit 2
Circuit 2
Circuit 2
Circuit 2
Circuit 2

L2 DHCP
Relay Agent
DHCP-DISCOVER
DHCP-OFFER
DHCP-REQUEST

Forced Connectivity Check


Forced Connectivity Check
Forced Connectivity Check

BSA-1

PE-1

BSR-1
DHCP
Proxy

DHCP
Relay Agent

DHCP
Server

SAP2
SAP2
SAP2
SAP2
SAP2
SAP2

Host No
Longer
Connected

Dropped DHCP Boot Request


Problem: Conflict With Lease on SAP1

Three consecutive Connectivity Checks


are launched with an interval of 10 seconds.
Connectivity Lost if no reply is received
within 30s (three checks with timeout of
10 seconds each):
clean up lease state
send DHCP release
DHCP
Host
SAP1

DHCP-RELEASE

Circuit 2
Circuit 2

DHCP-REQUEST
DHCP-ACK

SAP2
SAP2
DHCP
Host
OSSG393

Figure 72: DHCP Host Mobility

Page 1020

Advanced Configuration Guide

IPv4 DHCP Hosts

Note that for host mobility to function, host-connectivity-verification must be enabled. Next to
periodic connectivity checks, it also enables forced checks triggered by moving hosts.
For Bridged CO, host-connectivity-verify must be enabled on the SAPs. When no interval is
specified, it will default to 10 minutes for the periodic connectivity checks.
Bridged CO:
configure
service
vpls 1 customer 1 create
sap 1/1/2:1 split-horizon-group "rshg-1" create
host-connectivity-verify source-ip 10.1.0.253
exit
sap 1/1/2:2 split-horizon-group "rshg-1" create
host-connectivity-verify source-ip 10.1.0.253
exit

Note: the configured source-ip should be an unused unique ip address in the DHCP client subnet
or alternatively use source-ip 0.0.0.0. As the host-connectivity-verify application is sending a
unicast ARP to the DHCP host, its ARP table is updated with the configured source-ip and sourcemac (chassis MAC if not configured). If you would use an existing IP address, the DHCP host
ARP table gets poisoned, breaking the connectivity to that host.
For Routed CO, host-connectivity-verify must be enabled on the group-interface. When no
interval is specified, it will default to 10 minutes for the periodic connectivity checks.
Routed CO:
configure
service
vprn 1 customer 1 create
subscriber-interface "sub-int-1" create
group-interface "group-int-1" create
host-connectivity-verify

Note: the source IP address is not configurable. The source-ip used in the unicast ARP is fixed to
the local subscriber interface address in the subnet of the DHCP hosts that is checked for
connectivity.

Advanced Configuration Guide

Page 1021

Conclusion

Conclusion
This section provides configuration and troubleshooting commands for dynamic DHCP hosts.
DHCP hosts can be instantiated in a Layer 2 bridged CO (VPLS) environment as well as in a
Layer 3 Routed CO (IES/VPRN subscriber interface) context.

Page 1022

Advanced Configuration Guide

LDP over RSVP Using OSPF as IGP

In This Chapter
This section provides information about Label Distribution protocol (LDP) over Resource
Reservation Protocol for Traffic Engineering (RSVP-TE), also called LDPoRSVP, that uses RSVP
Label Switched Paths (LSPs) as a transport vehicle to carry the packets using LDP LSPs.
Topics in this section include:

Applicability on page 1024

Overview on page 1025

Configuration on page 1027

Additional Topics on page 1050

Conclusion on page 1057

Advanced Configuration Guide

Page 1023

Applicability

Applicability
This section is applicable to all of the 7750, 7450 and 7710 SR series. Tested on release 7.0R5. No
pre-requisites are required. The 7750 SR-c4 is supported from 8.0R4 and higher.

Page 1024

Advanced Configuration Guide

LDP over RSVP Using OSPF as IGP

Overview
Introduction
Only user packets are tunneled over the RSVP LSPs, targeted LDP (T-LDP) control messages are
still sent unlabeled using the IGP shortest path. Since LDP does not have traffic engineering (TE)
and fast reroute (FRR) convergence below 50 ms, it can now benefit from these two RSVP-TE
features.
The main advantage of LDPoRSVP is seen in large networks. A full mesh of intra-area RSVP
LSPs between PE nodes (which in some cases is not scalable) is not needed anymore. While an
LER may not have that many tunnels, any transit node will potentially have thousands of LSPs,
and if each transit node also has to deal with detours tunnels or bypass tunnels, this number can
make the LSR overly burdened.
LDPoRSVP feature can be configured in an intra-area domain and an inter-area domain. Any
router in a given area can be a stitching point for LDP over RSVP. LDPoRSVP introduces a new
tunnel type, tunnel-in-tunnel (in addition to the existing LDP tunnel type and RSVP tunnel type).
If multiple tunnel types match the destination PE Forwarding Equivalence Class (FEC) lookup,
LDP will prefer an LDP tunnel over an LDPoRSVP tunnel by default.
First, it is important to understand how LDP FEC resolution is working (with LDPoRSVP
enabled). A more detailed explanation can be found later on in this section. The ingress LER
receives an LDP label message including a FEC with prefix P and label L from peer A by a T-LDP
session. LDP tries to resolve prefix P by performing a lookup in the Routing Table Manager
(RTM). The result of this is a next-hop (NH) to the destination PE, either an intra-area PE (intraarea context) or an ABR (inter-area context). When the NH matches the targeted LDP peer, LDP
performs a second lookup for that NH in the Tunnel Table Manager (TTM) which returns a user
configured RSVP LSP with the best metric. If there are more than one configured RSVP LSP with
the best metric, LDP selects the first available RSVP LSP. If all user configured RSVP LSPs are
down, no more action is taken. If the user did not configure any RSVP LSPs under the T-LDP
context, the lookup in TTM will return the first available RSVP LSP which terminates on the ABR
(inter-area) or intra-area PE with the lowest metric.
If the lookup in TTM results in no RSVP LSP, the system can fall back to link-level LDP (iLDP),
In that way, it is possible that the NH is reachable using iLDP. Accordingly, the egress label will
be installed on the ingress LER.

Advanced Configuration Guide

Page 1025

Overview

OSPF Area 0.0.0.1

OSPF Area 0.0.0.0

OSPF Area 0.0.0.2

PE-2 1/1/3
1/1/3 P-4 1/1/1
1/1/1 P-3 1/1/3
1/1/3 PE-4
192.0.2.2 .1 192.168.28.0/30 .2 192.0.2.8 .1 192.168.78.0/30 .2 192.0.2.7 .2 192.168.47.0/30 .1 192.0.2.4
192.168.58.0/30

192.168.67.0/30

PE-1 1/1/3

1/1/3 P-1 1/1/2


1/1/2 P-2 1/1/4
1/1/5 PE-3
.1 192.168.15.0/30 .2
.1 192.168.56.0/30 .2
.1
.2 192.0.2.3
192.168.36.0/30
192.0.2.6
192.0.2.5
192.0.2.1

OSSG369

Figure 73: Initial Topology

OSPF area 0.0.0.1 and OSPF area 0.0.0.2 should be seen as two metro areas, connected to each
other via a core area, represented by OSPF backbone area (area 0.0.0.0). Therefore, P-1/P-2/P-3
and P-4 are all acting as area border routers (ABRs). LDPoRSVP principles will be shown for
intra-area PE communication (PE-1 <=> PE-2) and inter-area communication (PE-1 <=> PE-3).

Page 1026

Advanced Configuration Guide

LDP over RSVP Using OSPF as IGP

Configuration
Step 1.

Configuring the IP/MPLS network.

The system addresses and IP interface addresses are configured according to Figure 73 on page
1026. An interior gateway protocol (IGP) is needed to distribute routing information on all PEs. In
this case, the IGP is OSPF using the backbone area (area 0.0.0.0) in the core and normal areas
(area 0.0.0.1 and area 0.0.0.2) in the two metro regions, connected towards the backbone area via
ABRs. A configuration example is shown below for PE-1 and P-1. A similar configuration can be
derived for the other P and PE nodes.
A:PE-1# configure router ospf
traffic-engineering
area 0.0.0.1
interface "system"
exit
interface "int-PE-1-P-1"
interface-type point-to-point
exit
exit
A:P-1# configure router ospf
traffic-engineering
area 0.0.0.0
interface "int-P-1-P-2"
interface-type point-to-point
exit
interface "int-P-1-P-4"
interface-type point-to-point
exit
exit
area 0.0.0.1
interface "int-P-1-PE-1"
interface-type point-to-point
exit
exit

Since fast reroute will be enabled on the RSVP LSPs in the core area, traffic engineering is needed
on the IGP. By doing this, OSPF will generate opaque LSAs which are collected in a traffic
engineering database (TED), separate from the traditional OSPF topology database. OSPF
interfaces are setup as type point-to-point to improve convergence, no DR/BDR election process is
performed.1
On all nodes originating/terminating a T-LDP session, an explicit ldp-over-rsvp parameter must
be configured to enable this OSPF instance for LDPoRSVP. In the example, this becomes.
A:PE-[1..4]# configure router ospf ldp-over-rsvp
A:P-[1..4]# configure router ospf ldp-over-rsvp

1.Convergence is out of the scope of this document.

Advanced Configuration Guide

Page 1027

Configuration

To verify that OSPF neighbors are up (state null, show router ospf neighbor) is performed. To
check if IP interface addresses/subnets are known on all PEs, show router route-table or show
router fib IOM-card-slot will display the content of the forwarding information base (FIB).
A:PE-1# show router ospf neighbor
===============================================================================
OSPF Neighbors
===============================================================================
Interface-Name
Rtr Id
State
Pri RetxQ
TTL
------------------------------------------------------------------------------int-PE-1-P-1
192.0.2.5
Full
1
0
36
------------------------------------------------------------------------------No. of Neighbors: 1
===============================================================================
A:PE-1#

A:PE-1# show router route-table


===============================================================================
Route Table (Router: Base)
===============================================================================
Dest Prefix
Type
Proto
Age
Pref
Next Hop[Interface Name]
Metric
------------------------------------------------------------------------------192.0.2.1/32
Local
Local
02h42m42s
0
system
0
192.0.2.2/32
Remote OSPF
02h42m26s
10
192.168.15.2
3000
192.0.2.3/32
Remote OSPF
02h42m26s
10
192.168.15.2
3000
192.0.2.4/32
Remote OSPF
02h41m55s
10
192.168.15.2
4000
192.0.2.5/32
Remote OSPF
02h42m27s
10
192.168.15.2
1000
192.0.2.6/32
Remote OSPF
02h42m26s
10
192.168.15.2
2000
192.0.2.7/32
Remote OSPF
02h42m10s
10
192.168.15.2
3000
192.0.2.8/32
Remote OSPF
02h42m25s
10
192.168.15.2
2000
192.168.15.0/30
Local
Local
02h42m32s
0
int-PE-1-P-1
0
192.168.28.0/30
Remote OSPF
02h42m10s
10
192.168.15.2
3000
192.168.36.0/30
Remote OSPF
02h42m26s
10
192.168.15.2
3000
192.168.47.0/30
Remote OSPF
02h42m10s
10
192.168.15.2
4000
192.168.56.0/30
Remote OSPF
02h42m27s
10
192.168.15.2
2000
192.168.58.0/30
Remote OSPF
02h42m27s
10
192.168.15.2
2000
192.168.67.0/30
Remote OSPF
02h42m26s
10
192.168.15.2
3000
192.168.78.0/30
Remote OSPF
02h42m10s
10
192.168.15.2
3000
------------------------------------------------------------------------------No. of Routes: 16

Page 1028

Advanced Configuration Guide

LDP over RSVP Using OSPF as IGP

===============================================================================
A:PE-1#
A:PE-1# show router fib 1
===============================================================================
FIB Display
===============================================================================
Prefix
Protocol
NextHop
------------------------------------------------------------------------------192.0.2.1/32
LOCAL
192.0.2.1 (system)
192.0.2.2/32
OSPF
192.168.15.2 (int-PE-1-P-1)
192.0.2.3/32
OSPF
192.168.15.2 (int-PE-1-P-1)
192.0.2.4/32
OSPF
192.168.15.2 (int-PE-1-P-1)
192.0.2.5/32
OSPF
192.168.15.2 (int-PE-1-P-1)
192.0.2.6/32
OSPF
192.168.15.2 (int-PE-1-P-1)
192.0.2.7/32
OSPF
192.168.15.2 (int-PE-1-P-1)
192.0.2.8/32
OSPF
192.168.15.2 (int-PE-1-P-1)
192.168.15.0/30
LOCAL
192.168.15.0 (int-PE-1-P-1)
192.168.28.0/30
OSPF
192.168.15.2 (int-PE-1-P-1)
192.168.36.0/30
OSPF
192.168.15.2 (int-PE-1-P-1)
192.168.47.0/30
OSPF
192.168.15.2 (int-PE-1-P-1)
192.168.56.0/30
OSPF
192.168.15.2 (int-PE-1-P-1)
192.168.58.0/30
OSPF
192.168.15.2 (int-PE-1-P-1)
192.168.67.0/30
OSPF
192.168.15.2 (int-PE-1-P-1)
192.168.78.0/30
OSPF
192.168.15.2 (int-PE-1-P-1)
------------------------------------------------------------------------------Total Entries : 16
------------------------------------------------------------------------------===============================================================================
A:PE-1#

Advanced Configuration Guide

Page 1029

Configuration

The next step in the process of setting up the IP/MPLS network, is enabling the IP interfaces in the
MPLS and RSVP context on all involved nodes (PE and P nodes). By default, the system interface
is put automatically within the MPLS/RSVP context. When an interface is put in the MPLS
context, the system also copies it into the RSVP context. Explicit enabling of MPLS and RSVP
context is done by the no shutdown command. The following output displays the MPLS/RSVP
configuration for PE-1.
A:PE-1# configure router mpls no shutdown
A:PE-1# configure router rsvp no shutdown
A:PE-1# configure router mpls
interface "system"
exit
interface "int-PE-1-P-1"
exit
no shutdown
A:PE-1# configure router rsvp
interface "system"
exit
interface "int-PE-1-P-1"
exit
no shutdown

Page 1030

Advanced Configuration Guide

LDP over RSVP Using OSPF as IGP

Step 2.
Configure the RSVP LSPs. In both metro areas RSVP LSPs are setup from all PEs
towards the ABRs, no intra-area PE-PE RSVP LSPs are needed. In the core/backbone, a full RSVP
LSP mesh is required. To simplify the RSVP LSP configuration, no fast reroute is enabled on the
RSVP LSPs in the metro areas, only in the backbone area. All RSVP paths are set up as strict. As
an example, the configuration commands for PE-1 and P-1 node will look like the following output.
A:PE-1# configure router mpls
...
path "p-pe1-p1"
hop 1 192.168.15.2 strict
no shutdown
exit
path "p-pe1-p1-p4"
hop 1 192.168.15.2 strict
hop 2 192.168.58.2 strict
no shutdown
exit
lsp "LSP-PE-1-P-1"
to 192.0.2.5
primary "p-pe1-p1"
exit
no shutdown
exit
lsp "LSP-PE-1-P-4"
to 192.0.2.8
primary "p-pe1-p1-p4"
exit
no shutdown
exit
no shutdown
A:P-1# configure router mpls
...
path "p-p1-p2"
hop 1 192.168.56.2
no shutdown
exit
path "p-p1-p4"
hop 1 192.168.58.2
no shutdown
exit
path "p-p1-p2-p3"
hop 1 192.168.56.2
hop 2 192.168.67.2
no shutdown
exit
path "p-p1-pe1"
hop 1 192.168.15.1
no shutdown
exit
path "p-p1-p4-pe2"
hop 1 192.168.58.2
hop 2 192.168.28.1
no shutdown
exit
lsp "LSP-P-1-PE-1"
to 192.0.2.1
primary "p-p1-pe1"

Advanced Configuration Guide

strict

strict

strict
strict

strict

strict
strict

Page 1031

Configuration

exit
no shutdown
exit
lsp "LSP-P-1-PE-2"
to 192.0.2.2
primary "p-p1-p4-pe2"
exit
no shutdown
exit
lsp "LSP-P-1-P-2"
to 192.0.2.6
cspf
fast-reroute facility
exit
primary "p-p1-p2"
exit
no shutdown
exit
lsp "LSP-P-1-P-3"
to 192.0.2.7
cspf
fast-reroute facility
exit
primary "p-p1-p2-p3"
exit
no shutdown
exit
lsp "LSP-P-1-P-4"
to 192.0.2.8
cspf
fast-reroute facility
exit
primary "p-p1-p4"
exit
no shutdown
exit
no shutdown

Page 1032

Advanced Configuration Guide

LDP over RSVP Using OSPF as IGP

To display the state of RSVP LSPs, several show commands can be used. A command to show the
TTM is show router tunnel-table with parameter rsvp to reference to RSVP LSP signaling
protocol. By default, an RSVP LSP has preference 7.
A:PE-1# show router mpls lsp
===============================================================================
MPLS LSPs (Originating)
===============================================================================
LSP Name
To
Fastfail
Adm
Opr
Config
------------------------------------------------------------------------------LSP-PE-1-P-1
192.0.2.5
No
Up
Up
LSP-PE-1-P-4
192.0.2.8
No
Up
Up
------------------------------------------------------------------------------LSPs : 2
===============================================================================
A:PE-1#
A:PE-1# show router tunnel-table
===============================================================================
Tunnel Table (Router: Base)
===============================================================================
Destination
Owner Encap TunnelId Pref
Nexthop
Metric
------------------------------------------------------------------------------192.0.2.5/32
rsvp MPLS 1
7
192.168.15.2
65535
192.0.2.8/32
rsvp MPLS 131
7
192.168.15.2
65535
===============================================================================
A:PE-1#

A:P-1# show router mpls lsp


===============================================================================
MPLS LSPs (Originating)
===============================================================================
LSP Name
To
Fastfail
Adm
Opr
Config
------------------------------------------------------------------------------LSP-P-1-PE-1
192.0.2.1
No
Up
Up
LSP-P-1-P-2
192.0.2.6
Yes
Up
Up
LSP-P-1-P-3
192.0.2.7
Yes
Up
Up
LSP-P-1-P-4
192.0.2.8
Yes
Up
Up
LSP-P-1-PE-2
192.0.2.2
No
Up
Up
------------------------------------------------------------------------------LSPs : 5
===============================================================================
A:PE-1#

A:P-1# show router tunnel-table


===============================================================================
Tunnel Table (Router: Base)
===============================================================================
Destination
Owner Encap TunnelId Pref
Nexthop
Metric
------------------------------------------------------------------------------192.0.2.1/32
rsvp MPLS 1
7
192.168.15.1
65535
192.0.2.2/32
rsvp MPLS 269
7
192.168.58.2
65535
192.0.2.6/32
rsvp MPLS 7
7
192.168.56.2
1000
192.0.2.7/32
rsvp MPLS 11
7
192.168.56.2
2000

Advanced Configuration Guide

Page 1033

Configuration

192.0.2.8/32
rsvp MPLS 13
7
192.168.58.2
1000
===============================================================================
A:PE-1#

By default, the metric for strict LSPs configured without constrained shortest path first (CSPF)
(RSVP LSPs in metro areas) is infinite (value = 65535). The LSP metric for CSPF LSPs (RSVP
LSPs in the core are a) follows the IGP cost. LSP metrics can be explicitly set on the LSP level,
see also in the additional topics section.
A:P[E]-[1..4]# configure router mpls lsp <lsp-name> metric [0..65535]

Note that whenever an RSVP LSP comes up, it is, by default, eligible for LDPoRSVP, meaning
that RSVP will signal to the relevant IGP (OSPF in this case) that the LSP should be included in
the IGP/SPF run. The destination of the LSP (192.0.2.5) will be considered as a potential endpoint
in the FEC resolution. With the info detail command, all default settings of a context are shown.
A:PE-1# configure router mpls lsp "LSP-PE-1-P-1"
A:PE-1>config>router>mpls>lsp# info detail
to 192.0.2.5
...
ldp-over-rsvp include
...
A:PE-1# show router mpls lsp LSP-PE-1-P-1 detail
===============================================================================
MPLS LSPs (Originating) (Detail)
===============================================================================
------------------------------------------------------------------------------Type : Originating
------------------------------------------------------------------------------LSP Name
: LSP-PE-1-P-1
LSP Tunnel ID : 1
From
: 192.0.2.1
To
: 192.0.2.5
Adm State
: Up
Oper State
: Up
...
LdpOverRsvp : Enabled
VprnAutoBind
: Enabled
...
===============================================================================
A:PE-1#

To make an RSVP LSP ineligible for LDPoRSVP, use the exclude command.
A:PE-1# configure router mpls lsp <LSP-name> ldp-over-rsvp exclude

Page 1034

Advanced Configuration Guide

LDP over RSVP Using OSPF as IGP

Step 3.
Create T-LDP sessions according to RSVP LSPs. It is a must that when configuring an
RSVP LSP eligible for LDPoRSVP, also a T-LDP session is initiated. This must be done on all PE
and P nodes.
A:PE-1# configure router ldp
=============================================================================
targeted-session
peer 192.0.2.5
exit
peer 192.0.2.8
exit
exit
=============================================================================
A:PE-1#

A:PE-1# show router ldp session


=============================================================================
LDP Sessions
=============================================================================
Peer LDP Id
Adj Type
State
Msg Sent Msg Recv Up Time
----------------------------------------------------------------------------192.0.2.5:0
Targeted
Established
3216
3217
0d 04:53:52
192.0.2.8:0
Targeted
Established
3220
3222
0d 04:53:54
----------------------------------------------------------------------------No. of Sessions: 2
=============================================================================
A:PE-1#

Advanced Configuration Guide

Page 1035

Configuration

Enable LDPoRSVP. This is done using the tunneling keyword inside the T-LDP
session context. Configuration is needed on all PE and ABR nodes.

Step 4.

A:PE-1# configure router ldp


=============================================================================
targeted-session
peer 192.0.2.5
tunneling
exit
exit
peer 192.0.2.8
tunneling
exit
exit
exit
=============================================================================
A:PE-1#

As a result of the tunneling command, LDPoRSVP process (FEC resolving) is initiated. As


already stated in the introduction, FEC resolution is a three-step process. First run an SPF
calculation to the destination, then select an endpoint(s) as close to that destination followed by a
tunnel(s) to that endpoint. The next two steps go more into detail on this FEC resolution process.
Step 5 will handle inter-area FEC resolving and Step 6 will handle intra-area FEC resolving.

Page 1036

Advanced Configuration Guide

LDP over RSVP Using OSPF as IGP

Step 5.

Inter-area FEC resolving (ingress LER is PE-1, egress LER is PE-3)

Step 5.1

Verification endpoint nodes and associated RSVP tunnels.

The first thing to do in the inter-area FEC resolving process is PE-1 performs an SPF calculation
towards PE-3 with the purpose to search for an eligible endpoint, as close as possible to PE-3. An
endpoint is eligible when a T-LDP session exists between PE-1 and the endpoint node, tunneling is
configured on the endpoint node, PE-1 received a label for the destination FEC from the endpoint
and an RSVP LSP exists between PE-1 and endpoint node that can be used for LDPoRSVP.
Endpoint node in OSPF area 1 can be either P-1 or P-4 (only those nodes have a T-LDP session
towards PE-1). With show router ldp bindings prefix 192.0.2.3/32 active, it can be concluded
that P-1 will be the endpoint node.
A:PE-1# show router ldp bindings prefix 192.0.2.3/32 active
===============================================================================
Legend: (S) - Static
===============================================================================
LDP Prefix Bindings (Active)
===============================================================================
Prefix
Op
IngLbl
EgrLbl
EgrIntf/LspId EgrNextHop
------------------------------------------------------------------------------192.0.2.3/32
Push
-131060
LspId 1
192.0.2.5
192.0.2.3/32
Swap 131063
131060
LspId 1
192.0.2.5
------------------------------------------------------------------------------No. of Prefix Bindings: 2
===============================================================================
A:PE-1#

A:PE-1# show router mpls lsp detail


===============================================================================
MPLS LSPs (Originating) (Detail)
===============================================================================
------------------------------------------------------------------------------Type : Originating
------------------------------------------------------------------------------LSP Name
: LSP-PE-1-P-1
LSP Tunnel ID : 1
...
===============================================================================
A:PE-1#

A:PE-1# show router tunnel-table


===============================================================================
Tunnel Table (Router: Base)
===============================================================================
Destination
Owner Encap TunnelId Pref
Nexthop
Metric
------------------------------------------------------------------------------...
192.0.2.5/32
rsvp MPLS 1
7
192.168.15.2
65535
...
===============================================================================
A:PE-1#

Advanced Configuration Guide

Page 1037

Configuration

Endpoint node in OSPF area 0 can be either P-2,P-3 or P-4 (only those nodes have a T-LDP
session towards P-1). With show router ldp bindings prefix 192.0.2.3/32 active, it can be
concluded that P-2 will be the endpoint node.
A:P-1# show router ldp bindings prefix 192.0.2.3/32 active
===============================================================================
Legend: (S) - Static
===============================================================================
LDP Prefix Bindings (Active)
===============================================================================
Prefix
Op
IngLbl
EgrLbl
EgrIntf/LspId EgrNextHop
------------------------------------------------------------------------------192.0.2.3/32
Push
-131070
LspId 7
192.0.2.6
192.0.2.3/32
Swap 131060
131070
LspId 7
192.0.2.6
------------------------------------------------------------------------------No. of Prefix Bindings: 2
===============================================================================
A:P-1#

A:P-1# show router mpls lsp detail


===============================================================================
MPLS LSPs (Originating) (Detail)
===============================================================================
...
------------------------------------------------------------------------------Type : Originating
------------------------------------------------------------------------------LSP Name
: LSP-P-1-P-2
LSP Tunnel ID : 7
...
===============================================================================
A:P-1#

A:P-1# show router tunnel-table


===============================================================================
Tunnel Table (Router: Base)
===============================================================================
Destination
Owner Encap TunnelId Pref
Nexthop
Metric
------------------------------------------------------------------------------...
192.0.2.6/32
rsvp MPLS 7
7
192.168.56.2
1000
...
===============================================================================
A:P-1#

On P-2 node, the same commands can be repeated for the final destination node (PE-3). Also
there, an RSVP LSP towards PE-3 will be used as transport tunnel for user packets.
A:P-2# show router ldp bindings prefix 192.0.2.3/32 active
===============================================================================
Legend: (S) - Static
===============================================================================
LDP Prefix Bindings (Active)
===============================================================================

Page 1038

Advanced Configuration Guide

LDP over RSVP Using OSPF as IGP

Prefix
Op
IngLbl
EgrLbl
EgrIntf/LspId EgrNextHop
------------------------------------------------------------------------------192.0.2.3/32
Push
-131071
LspId 5
192.0.2.3
192.0.2.3/32
Swap 131070
131071
LspId 5
192.0.2.3
------------------------------------------------------------------------------No. of Prefix Bindings: 2
===============================================================================
A:P-2#

A:P-2# show router mpls lsp detail


...
------------------------------------------------------------------------------Type : Originating
------------------------------------------------------------------------------LSP Name
: LSP-P-2-PE-3
LSP Tunnel ID : 5
...
A:P-2# show router tunnel-table
===============================================================================
Tunnel Table (Router: Base)
===============================================================================
Destination
Owner Encap TunnelId Pref
Nexthop
Metric
------------------------------------------------------------------------------...
192.0.2.3/32
rsvp MPLS 5
7
192.168.36.2
65535
...
===============================================================================
A:P-2#

P-1 node and P-2 node act as stitching nodes to stitch RSVP LSPs. P-1 will stitch LSP-PE-1-P1and LSP-P-1-P2 together while P-2 node will stitch LSP-P-1-P-2 and LSP-P-2-PE-3 together.
When the endpoints are defined, one corresponding RSVP LSP to those endpoints will be chosen
(when ECMP=1). Selection criteria are as follows. When RSVP LSPs are configured under the TLDP tunneling command (maximum 4), the one with the lowest LSP metric will be selected.
When no RSVP LSPs are configured under the T-LDP tunneling command, LDP checks TTM for
all available RSVP LSPs. The RSVP LSP with the least metric and operational state up will be
selected.

Advanced Configuration Guide

Page 1039

Configuration

Traffic verification using a VPRN service.

Step 5.2
10.0.2.0/24

CE-2

.2 172.16.2.0/30
SAP 1/1/6:1
.1

OSPF Area 0.0.0.1

OSPF Area 0.0.0.0

OSPF Area 0.0.0.2

PE-2 1/1/3
1/1/3 P-4 1/1/1
1/1/1 P-3 1/1/3
1/1/3 PE-4
192.0.2.2 .1 192.168.28.0/30 .2 192.0.2.8 .1 192.168.78.0/30 .2 192.0.2.7 .2 192.168.47.0/30 .1 192.0.2.4
192.168.58.0/30

VPRN 1

192.168.67.0/30

1/1/3 P-1 1/1/2


1/1/2 P-2 1/1/4
1/1/5 PE-3
PE-1 1/1/3
192.0.2.1 .1 192.168.15.0/30 .2 192.0.2.5 .1 192.168.56.0/30 .2 192.0.2.6 .1 192.168.36.0/30 .2 192.0.2.3
.1

.1
SAP 1/1/1:1

SAP 1/1/6:1

172.16.1.0/30

172.16.3.0/30
.2

.2

CE-1
10.0.1.0/24

CE-3

AS 64496

10.0.1.0/24
OSSG370

Figure 74: VPRN 1 with LDPoRSVP and No Intra-Area PE Connectivity

VPRN service 1 is setup between three PE nodes (PE-1/PE-2 and PE-3) using the auto-bind ldp
command. See also Figure 74 for the exact addressing scheme.
A:PE-1# configure service vprn 1
autonomous-system 64496
route-distinguisher 64496:1
auto-bind ldp
vrf-target target:64496:1
interface "towards-CE-1" create
address 172.16.1.1/30
sap 1/1/1:1 create
exit
exit
static-route 10.0.1.0/24 next-hop 172.16.1.2
no shutdown

Page 1040

Advanced Configuration Guide

LDP over RSVP Using OSPF as IGP

In order to distribute VPRN information (vpn-ipv4 routes and VPRN service labels) across the
service provider network, multi-protocol BGP (MP-BGP) is needed. MP-BGP is configured on
PE-1/PE-2 and PE-3 with P-1 (192.0.2.5) acting as route reflector (RR). In this way no full BGP
mesh between the three PE-nodes is needed, only a BGP peering towards RR.
A:PE-1# configure router bgp
group "internal"
family ipv4 vpn-ipv4
type internal
neighbor 192.0.2.5
exit
exit
no shutdown
A:P-1# configure router bgp
group "internal"
family ipv4 vpn-ipv4
type internal
cluster 1.1.1.1
neighbor 192.0.2.1
exit
neighbor 192.0.2.2
exit
neighbor 192.0.2.3
exit
exit

If user traffic is monitored between PE-1 (ingress LER) and PE-3 (egress LER) three labels should
be seen. The outer label is the transport label (distributed using RSVP protocol), the inner label is
the service label (distributed using MP-BGP). LDPoRSVP will add an extra MPLS label between
transport and service label (distributed using LDP). This middle label is used to tell the endpoint
nodes (P-1 and P-2 acting as ABR) what to do.
Translated into show commands for traffic ingresssing port 1/1/3 on P-1 node (PE-1<=>P-1 link):
Transport label 131064is added as the top RSVP label on each user packet
A:PE-1# show router rsvp session lsp-name LSP-PE-1-P-1::p-pe1-p1 detail
===============================================================================
RSVP Sessions (Detailed)
===============================================================================
------------------------------------------------------------------------------LSP : LSP-PE-1-P-1::p-pe1-p1
------------------------------------------------------------------------------From
: 192.0.2.1
To
: 192.0.2.5
Tunnel ID
: 1
LSP ID
: 1536
Style
: SE
State
: Up
Session Type
: Originate
In Interface
: n/a
Out Interface : 1/1/3
In Label
: n/a
Out Label
: 131064
Previous Hop
: n/a
Next Hop
: 192.168.15.2
...
===============================================================================
A:PE-1#

Advanced Configuration Guide

Page 1041

Configuration

LDPoRSVP label 131060 is added as the middle LDP label on each user packet
A:PE-1# show router ldp bindings prefix 192.0.2.3/32 active
===============================================================================
Legend: (S) - Static
===============================================================================
LDP Prefix Bindings (Active)
===============================================================================
Prefix
Op
IngLbl
EgrLbl
EgrIntf/LspId EgrNextHop
------------------------------------------------------------------------------192.0.2.3/32
Push
-131060
LspId 1
192.0.2.5
192.0.2.3/32
Swap 131063
131060
LspId 1
192.0.2.5
------------------------------------------------------------------------------No. of Prefix Bindings: 2
===============================================================================
A:PE-1#

Service label 1310702 is added as the inner MP-BGP label on each user packet
A:PE-1# show router bgp neighbor 192.0.2.5 received-routes vpn-ipv4
===============================================================================
BGP Router ID:192.0.2.1
AS:64496
Local AS:64496
===============================================================================
Legend Status codes : u - used, s - suppressed, h - history, d - decayed, * - valid
Origin codes : i - IGP, e - EGP, ? - incomplete, > - best
===============================================================================
BGP VPN-IPv4 Routes
===============================================================================
Flag Network
LocalPref
MED
Nexthop
VPNLabel
As-Path
------------------------------------------------------------------------------...
u*>i 64496:1:172.16.3.0/30
100
None
192.0.2.3
131070
No As-Path
===============================================================================
A:PE-1#

2.This label will not change at endpoint nodes (P-1 and P-2). Ingress LER (PE-1) will push the service
label to the user packet while the egress LER (PE-3) will pop the service label.

Page 1042

Advanced Configuration Guide

LDP over RSVP Using OSPF as IGP

Translated into show commands for traffic ingresssing port 1/1/2 on P-2 node (P-1<=>P-2 link):
Transport label 131062 is added as the top RSVP label on each user packet.
A:P-1# show router rsvp session lsp-name LSP-P-1-P-2::p-p1-p2 detail
===============================================================================
RSVP Sessions (Detailed)
===============================================================================
------------------------------------------------------------------------------LSP : LSP-P-1-P-2::p-p1-p2
------------------------------------------------------------------------------From
: 192.0.2.5
To
: 192.0.2.6
Tunnel ID
: 7
LSP ID
: 48128
Style
: SE
State
: Up
Session Type
: Originate
In Interface
: n/a
Out Interface : 1/1/2
In Label
: n/a
Out Label
: 131062
Previous Hop
: n/a
Next Hop
: 192.168.56.2
...
===============================================================================
A:PE-1#

LDPoRSVP label 131070 is added as the middle LDP label on each user packet.
A:P-1# show router ldp bindings prefix 192.0.2.3/32 active
===============================================================================
Legend: (S) - Static
===============================================================================
LDP Prefix Bindings (Active)
===============================================================================
Prefix
Op
IngLbl
EgrLbl
EgrIntf/LspId EgrNextHop
------------------------------------------------------------------------------192.0.2.3/32
Push
-131070
LspId 7
192.0.2.6
192.0.2.3/32
Swap 131060
131070
LspId 7
192.0.2.6
------------------------------------------------------------------------------No. of Prefix Bindings: 2
===============================================================================
A:P-1#

Service label 131070 is added as the inner MP-BGP label on each user packet.
Translated into show commands for traffic ingresssing port 1/1/5 on PE-3 node (P-2<=>PE-3
link).
Transport label 131066 is added as the top RSVP label on each user packet.
A:P-2# show router rsvp session lsp-name LSP-P-2-PE-3::p-p2-pe3 detail
===============================================================================
RSVP Sessions (Detailed)
===============================================================================
LSP : LSP-P-2-PE-3::p-p2-pe3
------------------------------------------------------------------------------From
: 192.0.2.6
To
: 192.0.2.3

Advanced Configuration Guide

Page 1043

Configuration

Tunnel ID
: 5
LSP ID
: 54272
Style
: SE
State
: Up
Session Type
: Originate
In Interface
: n/a
Out Interface : 1/1/4
In Label
: n/a
Out Label
: 131066
...
===============================================================================
A:P-2#

LDPoRSVP label 131068 is added as the middle LDP label on each user packet.
A:P-2# show router ldp bindings prefix 192.0.2.3/32 active
===============================================================================
Legend: (S) - Static
===============================================================================
LDP Prefix Bindings (Active)
===============================================================================
Prefix
Op
IngLbl
EgrLbl
EgrIntf/LspId EgrNextHop
------------------------------------------------------------------------------192.0.2.3/32
Push
-131071
LspId 5
192.0.2.3
192.0.2.3/32
Swap 131070
131071
LspId 5
192.0.2.3
------------------------------------------------------------------------------No. of Prefix Bindings: 2
===============================================================================
A:P-2#

Service label 131070 is added as the inner MP-BGP label on each user packet.

Page 1044

Advanced Configuration Guide

LDP over RSVP Using OSPF as IGP

Step 6.

Intra-area FEC resolving (ingress LER is PE-1, egress LER is PE-2).

Step 6.1

Verification endpoint node and associated RSVP tunnel.

The first thing to do in the intra-area FEC resolving process is PE-1 performs an SPF calculation
towards PE-2 with the purpose to search for an eligible endpoint, as close as possible to PE-2. An
endpoint is eligible when a T-LDP session exists between PE-1 and the endpoint node, tunneling is
configured on the endpoint node, PE-1 received a label for the destination FEC from the endpoint
and an RSVP LSP exists between PE-1 and endpoint node that can be used for LDPoRSVP.
First endpoint node in OSPF area 1 can be either P-1 or P-4 (only those nodes have a T-LDP
session towards PE-1). With show router ldp bindings prefix 192.0.2.2/32 active it can be
concluded that P-1 will be the endpoint node.
A:PE-1# show router ldp bindings prefix 192.0.2.2/32 active
===============================================================================
Legend: (S) - Static
===============================================================================
LDP Prefix Bindings (Active)
===============================================================================
Prefix
Op
IngLbl
EgrLbl
EgrIntf/LspId EgrNextHop
------------------------------------------------------------------------------192.0.2.2/32
Push
-131066
LspId 1
192.0.2.5
192.0.2.2/32
Swap 131064
131066
LspId 1
192.0.2.5
------------------------------------------------------------------------------No. of Prefix Bindings: 2
===============================================================================
A:PE-1#

A:PE-1# show router mpls lsp detail


===============================================================================
MPLS LSPs (Originating) (Detail)
===============================================================================
------------------------------------------------------------------------------Type : Originating
------------------------------------------------------------------------------LSP Name
: LSP-PE-1-P-1
LSP Tunnel ID : 1
...
===============================================================================
A:PE-1#
A:PE-1# show router tunnel-table
===============================================================================
Tunnel Table (Router: Base)
===============================================================================
Destination
Owner Encap TunnelId Pref
Nexthop
Metric
------------------------------------------------------------------------------...
192.0.2.5/32
rsvp MPLS 1
7
192.168.15.2
65535
...
===============================================================================
A:PE-1#

Advanced Configuration Guide

Page 1045

Configuration

On P-1 node, the same commands can be repeated for the final destination node (PE-2). Also
there, an RSVP LSP towards PE-2 will be used as transport tunnel for user packets can be seen.
A:P-1# show router ldp bindings prefix 192.0.2.2/32 active
===============================================================================
Legend: (S) - Static
===============================================================================
LDP Prefix Bindings (Active)
==============================================================================
Prefix
Op
IngLbl
EgrLbl
EgrIntf/LspId EgrNextHop
------------------------------------------------------------------------------192.0.2.2/32
Push
-131071
LspId 269
192.0.2.2
192.0.2.2/32
Swap 131066
131071
LspId 269
192.0.2.2
------------------------------------------------------------------------------No. of Prefix Bindings: 2
===============================================================================
A:PE-1#

A:PE-1# show router mpls lsp detail


===============================================================================
MPLS LSPs (Originating) (Detail)
===============================================================================
...
------------------------------------------------------------------------------Type : Originating
------------------------------------------------------------------------------LSP Name
: LSP-P-1-PE-2
LSP Tunnel ID : 269
...
===============================================================================
A:PE-1#

A:P-1# show router tunnel-table


===============================================================================
Tunnel Table (Router: Base)
===============================================================================
Destination
Owner Encap TunnelId Pref
Nexthop
Metric
------------------------------------------------------------------------------...
192.0.2.2/32
rsvp MPLS 269
7
192.168.58.2
65535
...
===============================================================================
A:PE-1#

P-1 node act as a stitching node to stitch RSVP LSPs. P-1 will stitch LSP-PE-1-P-1 and LSP-P-1PE2 together.
When the endpoint node (P-1) is defined, the corresponding RSVP LSP to this endpoint will be
chosen. Selection criteria are as follows (when ECMP=1). When RSVP LSPs are configured
under the T-LDP tunneling command (maximum 4), the one with the lowest LSP metric will be
selected. When no RSVP LSPs are configured under the T-LDP tunneling command, LDP checks
TTM for all available RSVP LSPs. The RSVP LSP with the least metric and operational state up
will be selected.

Page 1046

Advanced Configuration Guide

LDP over RSVP Using OSPF as IGP

Step 6.2

Traffic verification using a VPRN service (see Figure 74 on page 1040).

If user traffic between PE-1 (ingress LER) and PE-2 (egress LER) is monitored, three labels are
seen. The outer one is the transport label (distributed using RSVP protocol), the inner one is the
service label (distributed using MP-BGP). LDPoRSVP will add an extra MPLS label between
transport and service label (distributed using LDP). This middle label is used to tell the endpoint
node (P-1) what to do.
Translated into show commands for traffic ingresssing port 1/1/3 on P-1 node (PE-1<=>P-1 link):
Transport label 131064 is added as the top RSVP label on each user packet.
A:PE-1# show router rsvp session lsp-name LSP-PE-1-P-1::p-pe1-p1 detail
===============================================================================
RSVP Sessions (Detailed)
===============================================================================
LSP : LSP-PE-1-P-1::p-pe1-p1
------------------------------------------------------------------------------From
: 192.0.2.1
To
: 192.0.2.5
Tunnel ID
: 1
LSP ID
: 1536
Style
: SE
State
: Up
Session Type
: Originate
In Interface
: n/a
Out Interface : 1/1/3
In Label
: n/a
Out Label
: 131064
Previous Hop
: n/a
Next Hop
: 192.168.15.2
...
===============================================================================
A:PE-1#

LDPoRSVP label 131066 is added as the middle LDP label on each user packet.
A:PE-1# show router ldp bindings prefix 192.0.2.2/32 active
===============================================================================
Legend: (S) - Static
===============================================================================
LDP Prefix Bindings (Active)
===============================================================================
Prefix
Op
IngLbl
EgrLbl
EgrIntf/LspId EgrNextHop
------------------------------------------------------------------------------192.0.2.2/32
Push
-131066
LspId 1
192.0.2.5
192.0.2.2/32
Swap 131064
131066
LspId 1
192.0.2.5
------------------------------------------------------------------------------No. of Prefix Bindings: 2
===============================================================================
A:PE-1#

Advanced Configuration Guide

Page 1047

Configuration

Service label 131070 is added as the inner MP-BGP label on each user packet3.
A:PE-1# show router bgp neighbor 192.0.2.5 received-routes vpn-ipv4
===============================================================================
BGP Router ID:192.0.2.1
AS:64496
Local AS:64496
===============================================================================
Legend Status codes : u - used, s - suppressed, h - history, d - decayed, * - valid
Origin codes : i - IGP, e - EGP, ? - incomplete, > - best
===============================================================================
BGP VPN-IPv4 Routes
===============================================================================
Flag Network
LocalPref
MED
Nexthop
VPNLabel
As-Path
------------------------------------------------------------------------------u*>i 64496:1:10.0.2.0/24
100
None
192.0.2.2
131070
No As-Path
?
No As-Path
u*>i 64496:1:172.16.2.0/30
100
None
192.0.2.2
131070
No As-Path
...
------------------------------------------------------------------------------Routes : 4
===============================================================================
A:PE-1#

Translated into show commands for traffic ingresssing port 1/1/3 on PE-2 node (PE-2<=>P-4
link):
Transport label 131064 is added as the top RSVP label on each user packet.
A:P-1# show router mpls lsp LSP-P-1-PE-2 path detail4
===============================================================================
MPLS LSP LSP-P-1-PE-2 Path (Detail)
===============================================================================
Legend :
@ - Detour Available
# - Detour In Use
b - Bandwidth Protected
n - Node Protected
s - Soft Preemption
===============================================================================
------------------------------------------------------------------------------LSP LSP-P-1-PE-2 Path p-p1-p4-pe2
------------------------------------------------------------------------------LSP Name
: LSP-P-1-PE-2
Path LSP ID : 6144

3. This label will not change at endpoint node (P-1). Ingress LER (PE-1) will push the service label to
the user packet while the egress LER (PE-2) will pop the service label.
4. show router rsvp session lsp-name LSP-P-1-PE-2::p-p1-p4-pe2 detail cannot be used since it only
shows the outgoing RSVP label towards P-4 node. On P-4 node, RSVP transport label 131057 will be
swapped into RSVP transport label 131064 for the link P-4 <=> PE-2.

Page 1048

Advanced Configuration Guide

LDP over RSVP Using OSPF as IGP

From
:
Adm State
:
Path Name
:
Path Admin :
OutInterface:

192.0.2.5
Up
p-p1-p4-pe2
Up
1/1/4

To
Oper State
Path Type
Path Oper
Out Label

:
:
:
:
:

192.0.2.2
Up
Primary
Up
131057

ExplicitHops:
192.168.58.2
-> 192.168.28.1
Actual Hops :
192.168.58.1(192.0.2.5)
Record Label
: N/A
-> 192.168.58.2(192.0.2.8)
Record Label
: 131057
-> 192.168.28.1
Record Label
: 131064
...
===============================================================================
A:PE-1#

LDPoRSVP label 131071 is added as the middle LDP label on each user packet.
A:P-1# show router ldp bindings prefix 192.0.2.2/32 active
===============================================================================
Legend: (S) - Static
===============================================================================
LDP Prefix Bindings (Active)
===============================================================================
Prefix
Op
IngLbl
EgrLbl
EgrIntf/LspId EgrNextHop
------------------------------------------------------------------------------192.0.2.2/32
Push
-131071
LspId 269
192.0.2.2
192.0.2.2/32
Swap 131066
131071
LspId 269
192.0.2.2
------------------------------------------------------------------------------No. of Prefix Bindings: 2
===============================================================================
A:PE-1#

Service label 131070 is added as the inner MP-BGP label on each user packet.

Advanced Configuration Guide

Page 1049

Configuration

Additional Topics
Command: prefer-tunnel-in-tunnel
If the next-hop router advertised the same FEC over link-level LDP (iLDP), LDP will prefer the
iLDP tunnel by default unless the user explicitly changed the default preference using the prefertunnel-in-tunnel command. In this case an LDPoRSVP tunnel will have precedence.
Until now in this example, no RSVP LSPs are configured inside the ldp targeted-session peer
tunneling context. Therefore, two additional strict non-cspf RSVP LSPs are added between
ingress LER PE-1 node and egress LER P-1 node. Both LSPs will have an explicit metric setting
and will be applied inside the ldp tunneling context. On the Layer 3 interface between PE-1 and
P-1 node, iLDP is enabled.
A:PE-1# configure router ldp
interface-parameters
interface "int-PE-1-P-1"
exit
exit
A:P-1# configure router ldp
interface-parameters
interface "int-P-1-PE-1"
exit
exit
A:PE-1# configure router mpls
...
path "p-pe1-p1"
hop 1 192.168.15.2 strict
no shutdown
exit
...
lsp "LSP-PE-1-P-1-metric100"
to 192.0.2.5
metric 100
primary "p-pe1-p1"
exit
exit
lsp "LSP-PE-1-P-1-metric200"
to 192.0.2.5
metric 200
primary "p-pe1-p1"
exit
exit
no shutdown
A:PE-1# configure router ldp
...
targeted-session
peer 192.0.2.5
tunneling
lsp "LSP-PE-1-P-1-metric100"

Page 1050

Advanced Configuration Guide

LDP over RSVP Using OSPF as IGP

lsp "LSP-PE-1-P-1-metric200"
exit
exit
...
exit

TTM on PE-1 node will look like this:


A:PE-1# show router tunnel-table
===============================================================================
Tunnel Table (Router: Base)
===============================================================================
Destination
Owner Encap TunnelId Pref
Nexthop
Metric
------------------------------------------------------------------------------192.0.2.5/32
rsvp MPLS 1
7
192.168.15.2
65535
192.0.2.5/32
rsvp MPLS 2
7
192.168.15.2
100
192.0.2.5/32
rsvp MPLS 3
7
192.168.15.2
200
192.0.2.5/32
ldp
MPLS 9
192.168.15.2
1000
...
===============================================================================
A:PE-1#

Four LSPs are setup towards P-1 node, three RSVP LSPs and one LDP LSP. Tunnel ID 1 is a
reference to LSP-PE-1-P-1. Tunnel ID 2 is a reference to LSP-PE-1-P-1-metric100. Tunnel ID 3 is
a reference to LSP-PE-1-P-1-metric200 and owner LDP is a reference to iLDP.
Taken into account the FEC resolution rules, iLDP will win (no LDPoRSVP tunnel will be used).
A:PE-1# show router ldp bindings prefix 192.0.2.5/32 active
===============================================================================
Legend: (S) - Static
===============================================================================
LDP Prefix Bindings (Active)
===============================================================================
Prefix
Op
IngLbl
EgrLbl
EgrIntf/LspId EgrNextHop
------------------------------------------------------------------------------192.0.2.5/32
Push
-131071
1/1/3
192.168.15.2
192.0.2.5/32
Swap 131067
131071
1/1/3
192.168.15.2
------------------------------------------------------------------------------No. of Prefix Bindings: 2
===============================================================================
A:PE-1#

This behavior can be changed by setting the prefer-tunnel-in-tunnel command in the LDP
context. Now, the LDPoRSVP tunnel with the best (= lowest) metric is taken.
A:PE-1# configure router ldp prefer-tunnel-in-tunnel
A:PE-1# show router ldp bindings prefix 192.0.2.5/32 active
===============================================================================
Legend: (S) - Static
===============================================================================
LDP Prefix Bindings (Active)
===============================================================================

Advanced Configuration Guide

Page 1051

Configuration

Prefix
Op
IngLbl
EgrLbl
EgrIntf/LspId EgrNextHop
------------------------------------------------------------------------------192.0.2.5/32
Push
-131071
LspId 2
192.0.2.5
192.0.2.5/32
Swap 131067
131071
LspId 2
192.0.2.5
------------------------------------------------------------------------------No. of Prefix Bindings: 2
===============================================================================
A:PE-1#

A:PE-1# show router mpls lsp detail


===============================================================================
MPLS LSPs (Originating) (Detail)
===============================================================================
------------------------------------------------------------------------------Type : Originating
------------------------------------------------------------------------------LSP Name
: LSP-PE-1-P-1-metric100
LSP Tunnel ID : 2
...
===============================================================================
A:PE-1#

If LSP-PE-1-P-1-metric 100 is shutdown, LSP-PE-1-P-1-metric 200 will becomes active.


A:PE-1# configure router mpls lsp LSP-PE-1-P-1-metric100 shutdown
A:PE-1# show router ldp bindings prefix 192.0.2.5/32 active
===============================================================================
Legend: (S) - Static
===============================================================================
LDP Prefix Bindings (Active)
===============================================================================
Prefix
Op
IngLbl
EgrLbl
EgrIntf/LspId EgrNextHop
------------------------------------------------------------------------------192.0.2.5/32
Push
-131071
LspId 3
192.0.2.5
192.0.2.5/32
Swap 131067
131071
LspId 3
192.0.2.5
------------------------------------------------------------------------------No. of Prefix Bindings: 2
===============================================================================
A:PE-1#

A:PE-1# show router mpls lsp detail


===============================================================================
MPLS LSPs (Originating) (Detail)
===============================================================================
------------------------------------------------------------------------------Type : Originating
------------------------------------------------------------------------------LSP Name
: LSP-PE-1-P-1-metric200
LSP Tunnel ID : 3
...
===============================================================================
A:PE-1#

Page 1052

Advanced Configuration Guide

LDP over RSVP Using OSPF as IGP

If LSP-PE-1-P-1-metric 200 is shutdown, iLDP resumes.


A:PE-1# configure router mpls lsp LSP-PE-1-P-1-metric200 shutdown
A:PE-1# show router ldp bindings prefix 192.0.2.5/32 active
===============================================================================
Legend: (S) - Static
===============================================================================
LDP Prefix Bindings (Active)
===============================================================================
Prefix
Op
IngLbl
EgrLbl
EgrIntf/LspId EgrNextHop
------------------------------------------------------------------------------192.0.2.5/32
Push
-131071
1/1/3
192.168.15.2
192.0.2.5/32
Swap 131067
131071
1/1/3
192.168.15.2
------------------------------------------------------------------------------No. of Prefix Bindings: 2
===============================================================================
A:PE-1#

Advanced Configuration Guide

Page 1053

Configuration

Intra-PE connectivity will change LDPoRSVP behavior.


Refer to Figure 75. In the two metro areas, both of the intra PEs are physically connected with
each other. Compared with the previous figures, PE-1 node is directly connected to PE-2 and PE-3
node is directly connected to PE-4 (up to the OSPF level).

10.0.2.0/24

CE-2
.2

172.16.2.0/30
SAP 1/1/6:1

.1

OSPF Area 0.0.0.1

OSPF Area 0.0.0.0

OSPF Area 0.0.0.2

PE-2 1/1/3
1/1/3 P-4 1/1/1
1/1/1 P-3 1/1/3
1/1/3 PE-4
192.168.5.0/30
.2
.1
.1
.2
.2
.1 192.0.2.4
192.168.2.0/30
192.168.7.0/30
192.0.2.2
192.0.2.8
192.0.2.7
1/1/2

1/1/2

.2

1/1/4

192.168.9.0/30
.1

1/1/4

.2

1/1/2

192.168.3.0/30
.1

VPRN 1
1/1/3

.2
192.168.0.0/30
.1

1/1/4

.2

192.168.8.0/30
1/1/3 .1

1/1/3 P-1 1/1/2


1/1/2 P-2 1/1/4
1/1/5 PE-3
PE-1 1/1/3
192.0.2.1 .1 192.168.4.0/30 .2 192.0.2.5 .1 192.168.1.0/30 .2 192.0.2.6 .1 192.168.6.0/30 .2 192.0.2.3
.1

.1
SAP 1/1/1:1

SAP 1/1/6:1

172.16.1.0/30

172.16.3.0/30

.2

.2

CE-1
10.0.1.0/24

CE-3
AS 64496

10.0.3.0/24
OSSG372

Figure 75: VPRN 1 with LDPoRSVP and Intra-Area PE Connectivity

The SPF path calculation on PE-1 towards destination (PE-2) will not point anymore to P-1 node
(as was seen before) but will point directly to PE-2 (shortest, least IGP metric). As a conclusion it
can be said that when possible intra-area endpoint node(s) are not part of the calculated SPF path,
LDPoRSVP will be not be preferred anymore. For this situation it is advisable to configure iLDP
on the intra-PE interfaces to have a fall back mechanism.
Translated into configuration commands on PE-1/PE-2 node, this becomes:
A:PE-1# configure router interface int-PE-1-PE-2
address 192.168.12.1/30
port 1/1/2
A:PE-2# configure router interface int-PE-1-PE-2
address 192.168.12.2/30
port 1/1/2
A:PE-1# configure router ospf
...
area 0.0.0.1

Page 1054

Advanced Configuration Guide

LDP over RSVP Using OSPF as IGP

...
interface "int-PE-1-PE-2"
interface-type point-to-point
exit
exit
A:PE-2# configure router ospf
...
area 0.0.0.1
...
interface "int-PE-2-PE-1"
interface-type point-to-point
exit
exit

From the moment iLDP is configured, an LDP LSP is setup. Intra-area PE traffic will flow over
this LDP LSP.
A:PE-1# configure router ldp
interface-parameters
interface "int-PE-1-PE-2"
exit
exit
A:PE-2# configure router ldp
interface-parameters
interface "int-PE-2-PE-1"
exit
exit
A:PE-1# show router tunnel-table 192.0.2.2/32
===============================================================================
Tunnel Table (Router: Base)
===============================================================================
Destination
Owner Encap TunnelId Pref
Nexthop
Metric
------------------------------------------------------------------------------192.0.2.2/32
ldp
MPLS
9
192.168.12.2
1000
===============================================================================
A:PE-1#

If user traffic is monitored, between PE-1 (ingress LER) and PE-2 (egress LER) only two labels
are seen. The outer one is the transport label (distributed using LDP protocol), the inner one is the
service label (distributed using MP-BGP). No LDPoRSVP label is present anymore. Translated
into show commands for traffic ingresssing port 1/1/2 on PE-2 node (PE-1<=>PE-2 link):

Advanced Configuration Guide

Page 1055

Configuration

Transport label 131071 is added as the top LDP label on each user packet.
A:PE-1# show router ldp bindings prefix 192.0.2.2/32 active
===============================================================================
Legend: (S) - Static
===============================================================================
LDP Prefix Bindings (Active)
===============================================================================
Prefix
Op
IngLbl
EgrLbl
EgrIntf/LspId EgrNextHop
------------------------------------------------------------------------------192.0.2.2/32
Push
-131071
1/1/2
192.168.12.2
192.0.2.2/32
Swap 131063
131071
1/1/2
192.168.12.2
------------------------------------------------------------------------------No. of Prefix Bindings: 2
===============================================================================
A:PE-1#

Service label 131070 is added as the inner MP-BGP label on each user packet.
A:PE-1# show router bgp neighbor 192.0.2.5 received-routes vpn-ipv4
===============================================================================
BGP Router ID:192.0.2.1
AS:64496
Local AS:64496
===============================================================================
Legend Status codes : u - used, s - suppressed, h - history, d - decayed, * - valid
Origin codes : i - IGP, e - EGP, ? - incomplete, > - best
===============================================================================
BGP VPN-IPv4 Routes
===============================================================================
Flag Network
LocalPref
MED
Nexthop
VPNLabel
As-Path
------------------------------------------------------------------------------u*>i 64496:1:10.0.2.0/24
100
None
192.0.2.2
131070
No As-Path
...
u*>i 64496:1:172.16.2.0/30
100
None
192.0.2.2
131070
No As-Path
===============================================================================
A:PE-1#

Page 1056

Advanced Configuration Guide

LDP over RSVP Using OSPF as IGP

Conclusion
LDPoRSVP allows tunneling of user packets towards an LDP far-end destination inside an RSVP
LSP (with the benefits of RSVP LSPs, fast-reroute (FRR) and traffic engineering (TE)). The main
application of this feature is for deployment of MPLS based services, for example, VPRN, VLL
and VPLS services, in large networks where a full mesh of LSPs reaches the limits of scalability.

Advanced Configuration Guide

Page 1057

Conclusion

Page 1058

Advanced Configuration Guide

LDP VPLS using BGP-Auto Discovery

In This Chapter
This section provides information about LDP VPLS using BGP-Auto Discovery.
Topics in this section include:

Applicability on page 1060

Summary on page 1061

Overview on page 1062

Configuration on page 1064

Conclusion on page 1089

Advanced Configuration Guide

Page 1059

Applicability

Applicability
This section is applicable to all of the 7450 ESS, 7750 SR and 7710 SR series and was tested on
release SR-OS 9.0 R3. There are no pre-requisites for this configuration.

Page 1060

Advanced Configuration Guide

LDP VPLS using BGP-Auto Discovery

Summary
MPLS-based Virtual Private LAN Services (VPLS) may have many different provisioning models
to allow the signalling of pseudowires between PE routers containing VPLS instances.
Network Management System (NMS) provisioning using LDP Signalling is a well understood
method of provisioning of Layer 2 VPLS services as is described in RFC 4762. This relies on the
provisioning of pseudowires between VPLS instances using Label Distribution Protocol (LDP)
signalling with a common virtual circuit (VC) identifier within the label mapping message to
instantiate pseudowires.
Border Gateway Protocol (BGP) Auto Discovery (RFC 6074) is an alternative method of
provisioning of Layer 2 Provider Edge routers containing VPLS service instances to those
described above where PEs in a common VPLS instance are automatically discovered using BGP
Auto Discovery (BGP-AD) techniques.
Each PE router advertises the presence of VPLS instances to other PE routers using defined
parameters within a BGP update message.
LDP is used as the pseudowire signalling protocol and relies on the auto-discovery of VPLS
endpoints to instantiate pseudowires instead of manually provisioning virtual circuits. Locally
configured parameters, along with BGP learned parameters, are used to determine local and
remote VPLS endpoints, which are used by LDP to signal service labels to peer routers.
Knowledge of BGP-Auto-discovery RFC 6074 architecture and functionality, RFC 4447 Pseudowire Set-up using Label Distribution Protocol is assumed throughout this section, as well as
knowledge of Multi-Protocol BGP (MP-BGP).

Advanced Configuration Guide

Page 1061

Overview

Overview

P-1

PE-1

192.0.2.10

RR-1

192.0.2.1

192.0.2.20
192.168.7.2/30

192.168.0.1/30

192.168.7.1/30

192.168.0.2/30

192.168.1.1/30

192.168.2.1/30
192.168.1.2/30

P-2

192.168.2.2/30

PE-2

192.168.3.1/30

192.0.2.11

192.0.2.2

192.168.3.2/30

192.168.4.1/30

192.168.5.1/30
192.168.4.2/30

192.168.5.2/30

192.168.6.1/30
192.168.6.1/30

PE-3

P-3

192.0.2.3

192.0.2.12

ACG0001

Figure 76: Network Topology

The network topology is displayed in Figure 76. The setup uses seven 7750/7450/7710 Service
Router (SR) nodes located in the same Autonomous System (AS). There are three PEs and RR-1
will act as a Route Reflector for the AS. The Provider Edge routers are all VPLS aware; The
Provider (P) routers are VPLS unaware and do not take part in the BGP process. A full mesh
VPLS between PE-1, PE-2 and PE-3 is described.
The following configuration tasks should be completed as a pre-requisite:

Page 1062

ISIS or OSPF should be enabled on all network interfaces between each of the PE/P
routers and route reflector.

MPLS should be configured on all interfaces between PE and P routers; MPLS is not
required between P-1 and RR-1.

LDP should be configured on interfaces between PE and P routers. It is not required


between P-1 and RR-1.

RSVP protocol is disabled by default, so the RSVP protocol should be enabled.

Advanced Configuration Guide

LDP VPLS using BGP-Auto Discovery

BGP-AD
In this architecture a VPLS service is a collection of local VPLS Instances present on a number of
PEs in a provider network. In this context, VPLS-aware devices are PE routers. Each VPLS
instance has a unique identifier known as the VPLS identifier (VPLS-id). All PEs that have this
VPLS instance present will have a common VPLS-id configured.
Each VPLS instance within a PE contains a Virtual Switching Instance (VSI). The VPLS
attachment circuits and pseudowires are associated with the VSI. Each VSI within a given VPLS
has a unique identifier called the VSI identifier (VSI-id) and is a concatenation of the VPLS-id
plus an IP address, usually the system IP address.
The PEs communicate with each other at the control plane level by means of BGP updates
containing BGP Layer 2 Network Layer Reachability Information (NLRI). Each update contains
enough information for a PE to determine the presence of other local VPLS instances on peering
PEs. In turn, this allows peer PE routers to setup pseudowire connectivity using LDP signaling for
data flow between peers containing a local VPLS within the same VPLS instances.
Each update contains parameters usually associated with Multi-Protocol BGP updates:

NLRI encoded as route-target (usually the VPLS-id) and PE system address

Next-Hop The system IP address of the sending PE router.

Extended communities Contains the route target extended community and the VPLS-id
as community values.

Each VPLS instance is configured with import and export route target extended communities to
create the required pseudowire topology by controlling the distribution of each NLRI.
The purpose of this section is to describe the provisioning of a VPLS instance across three PE
routers. A full mesh of pseudowires interconnects the VSI of each PE within the VPLS instance. A
single attachment circuit is also configured on each VSI.

Advanced Configuration Guide

Page 1063

Configuration

Configuration
The first step is to configure an MP-iBGP session using the L2VPN address family between each
of the PEs and the route reflector.
The configuration for PE-1 is:
configure router bgp
group rr
family l2vpn
type internal
neighbor 192.0.2.20
exit
exit
exit all

The configuration for the other PE nodes is identical. The IP addresses can be derived from
Figure 76.
Configuration for route reflector is:
configure router bgp
cluster 1.1.1.2
group rr_clients
family l2-vpn
type internal
neighbor 192.0.2.1
exit
neighbor 192.0.2.2
exit
neighbor 192.0.2.3
exit
exit
exit all

On PE-1, verify that the BGP session with RR-1 is established with address family l2-vpn
capability negotiated:
A:PE-1# show router bgp neighbor 192.0.2.20
===============================================================================
BGP Neighbor
===============================================================================
------------------------------------------------------------------------------Peer : 192.0.2.20
Group : internal
------------------------------------------------------------------------------Peer AS
: 65536
Peer Port
: 179
Peer Address
: 192.0.2.20
Local AS
: 65536
Local Port
: 58990
Local Address
: 192.0.2.1
Peer Type
: Internal
State
: Established
Last State
: Active
Last Event
: recvKeepAlive

Page 1064

Advanced Configuration Guide

LDP VPLS using BGP-Auto Discovery

Last Error
:
Local Family
:
Remote Family
:
Hold Time
:
Active Hold Time
:
Cluster Id
:
Preference
:
Recd. Paths
:
IPv4 Recd. Prefixes :
IPv4 Suppressed Pfxs :
VPN-IPv4 Recd. Pfxs :
Mc IPv4 Recd. Pfxs. :
Mc IPv4 Suppr. Pfxs :
IPv6 Recd. Prefixes :
VPN-IPv6 Recd. Pfxs :
VPN-IPv6 Suppr. Pfxs :
L2-VPN Recd. Pfxs
:
MVPN-IPv4 Suppr. Pfxs:
MVPN-IPv4 Active Pfxs:
MDT-SAFI Recd. Pfxs :
FLOW-IPV4-SAFI Suppr*:
FLOW-IPV4-SAFI Recd.*:
Input Queue
:
i/p Messages
:
i/p Octets
:
i/p Updates
:
TTL Security
:
Graceful Restart
:
Advertise Inactive
:
Advertise Label
:
Auth key chain
:
Disable Cap Nego
:
Auth key chain
:
Flowspec Validate
:
Local Capability
:
Remote Capability
:
Import Policy
:
Export Policy
:

Cease
L2-VPN
L2-VPN
90
Keep Alive
:
90
Active Keep Alive
:
None
170
Num of Update Flaps :
13
0
IPv4 Active Prefixes :
0
VPN-IPv4 Suppr. Pfxs :
0
VPN-IPv4 Active Pfxs :
0
Mc IPv4 Active Pfxs. :
0
IPv6 Suppressed Pfxs :
0
IPv6 Active Prefixes :
0
VPN-IPv6 Active Pfxs :
0
L2-VPN Suppr. Pfxs
:
6
L2-VPN Active Pfxs
:
0
MVPN-IPv4 Recd. Pfxs :
0
MDT-SAFI Suppr. Pfxs :
0
MDT-SAFI Active Pfxs :
0
0
FLOW-IPV4-SAFI Activ*:
0
Output Queue
:
2370
o/p Messages
:
46577
o/p Octets
:
21
o/p Updates
:
Disabled
Min TTL Value
:
Disabled
Stale Routes Time
:
Disabled
Peer Tracking
:
None
n/a
Disabled
Peer Tracking
:
n/a
Enabled
L2 VPN Cisco Interop :
RtRefresh MPBGP 4byte ASN
RtRefresh MPBGP 4byte ASN
None Specified / Inherited
None Specified / Inherited

30
30
9
0
0
0
0
0
0
0
0
4
0
0
0
0
0
2355
44743
4
n/a
n/a
Disabled

Disabled
Disabled

------------------------------------------------------------------------------Neighbors : 1

Advanced Configuration Guide

Page 1065

Configuration

On RR-1, show that BGP sessions with each PE are established, and have correctly negotiated the
l2-vpn address family capability.
B:RR-1# show router bgp summary
===============================================================================
BGP Router ID:192.0.2.20
AS:65536
Local AS:65536
===============================================================================
BGP Admin State
: Up
BGP Oper State
: Up
Total Peer Groups
: 1
Total Peers
: 3
Total BGP Paths
: 18
Total Path Memory
: 2352
Total IPv4 Remote Rts
: 0
Total IPv4 Rem. Active Rts : 0
Total IPv6 Remote Rts
: 0
Total IPv6 Rem. Active Rts : 0
Total Supressed Rts
: 0
Total Hist. Rts
: 0
Total Decay Rts
: 0
Total
Total
Total
Total
Total
Total
Total
Total
Total
Total
Total

VPN Peer Groups


VPN Local Rts
VPN-IPv4 Rem. Rts
VPN-IPv6 Rem. Rts
L2-VPN Rem. Rts
VPN Supp. Rts
VPN Decay Rts
MVPN-IPv4 Rem Rts
MDT-SAFI Rem Rts
MSPW Rem Rts
FlowIpv4 Rem Rts

:
:
:
:
:
:
:
:
:
:
:

0
0
0
0
15
0
0
0
0
0
0

Total VPN Peers

: 0

Total
Total
Total
Total

VPN-IPv4 Rem. Act. Rts:


VPN-IPv6 Rem. Act. Rts:
L2VPN Rem. Act. Rts
:
VPN Hist. Rts
:

0
0
0
0

Total
Total
Total
Total

MVPN-IPv4 Rem Act Rts


MDT-SAFI Rem Act Rts
MSPW Rem Act Rts
FlowIpv4 Rem Act Rts

0
0
0
0

:
:
:
:

===============================================================================
BGP Summary
===============================================================================
Neighbor
AS PktRcvd InQ Up/Down
State|Rcv/Act/Sent (Addr Family)
PktSent OutQ
------------------------------------------------------------------------------192.0.2.1
65536
10477
0 16h43m29s 5/0/15 (L2VPN)
10981
0
192.0.2.2
65536
10776
0 16h43m29s 5/0/15 (L2VPN)
11022
0
192.0.2.3
65536
10819
0 16h43m29s 5/0/15 (L2VPN)
10926
0
-------------------------------------------------------------------------------

Page 1066

Advanced Configuration Guide

LDP VPLS using BGP-Auto Discovery

A full mesh of RSVP Label Switched Paths (LSPs) is configured between the PE routers. For
reference, the MPLS interface configuration and LSPs for PE-1 to PE-2 and PE-3 is:
A:PE-1# configure router mpls
interface "system"
exit
interface "int-PE-1-P-1"
exit
interface "int-PE-1-PE-2"
exit
path "loose"
no shutdown
exit
lsp "LSP-PE-1-PE-2"
to 192.0.2.2
primary "loose"
exit
no shutdown
exit
lsp "LSP-PE-1-PE-3"
to 192.0.2.3
primary "loose"
exit
no shutdown
exit
no shutdown

Advanced Configuration Guide

Page 1067

Configuration

VPLS PE Configuration
Pseudowire-Templates
Pseudowire templates are used by BGP to dynamically instantiate Service Distribution Point
(SDP) bindings, for a given service they are used to signal the egress service de-multiplexor labels
used by remote PEs to reach the local PE.
The template determines the signalling parameters of the pseudowire, control word presence, plus
other usage characteristics such as Split Horizon Groups, MAC-pinning, filters, etc.
The MPLS transport tunnel between PE routers can be signalled using either LDP or RSVP.
LDP based pseudowires can be automatically instantiated. RSVP based SDPs have to be preprovisioned.

Pseudowire Templates for Auto-SDP Creation using LDP


In order to use an LDP transport tunnel for data flow between PEs, it is necessary for link layer
LDP to be configured between all PEs/Ps so that a transport label for each PEs system interface
address is available. Using this mechanism SDPs can be auto-instantiated with SDP ids starting at
17407. Any subsequent SDPs created use SDP-ids decrementing from this value.
A pseudowire template is required which may contain a split-horizon group. Each SDP created
with this template is contained within the configured split horizon group so that traffic cannot be
forwarded between them.
A:PE-1# configure service
pw-template 1 create
split-horizon-group "vpls-shg"
exit
exit

A pseudowire template can also be created that does not contain a split-horizon group. The split
horizon group can then be specified when the pw-template is included within the service.
A:PE-1# configure service
pw-template 2 create
exit

Page 1068

Advanced Configuration Guide

LDP VPLS using BGP-Auto Discovery

Pseudowire Templates for Provisioned SDPs using RSVP


To use an RSVP tunnel as transport between PEs, it is necessary to bind the RSVP LSPs to the
SDPs between each PE.
SDP Creation from PE-1 to PE-2
A:PE-1# configure service sdp 43 mpls create
description "from-192.0.2.1-id-33"
far-end 192.0.2.2
lsp "LSP-PE-1-PE-2"
keep-alive
shutdown
exit
no shutdown

To create an SDP within a service that uses the RSVP transport tunnel, a pseudowire template is
required that has the use-provisioned-sdp parameter.
A:PE-1# configure service
pw-template 3 use-provisioned-sdp create
exit
exit

Advanced Configuration Guide

Page 1069

Configuration

VPLS BGP-AD using Auto-Provisioned SDPs


PE-1
192.0.2.1

RR-1
192.0.2.20

VPLS-ID 65536:6
VSI-192.0.2.1

CE

SDP

PE-3

SDP
SDP

CE

VPLS 3
VPLS-ID 65536:6
VSI-192.0.2.3

SDP
SDP

CE

SDP

VPLS-ID 65536:6
VSI-192.0.2.2

PE-2
ACG0002

Figure 77: VPLS Instance with Auto-Provisioned SDPs

Figure 77 shows a schematic of a VPLS instance where the SDPs are auto-provisioned. SDPs are
instantiated by a PE router using LDP signalling upon receipt of BGP Auto-discovery (BGP-AD)
updates from peer PE routers.
PE-1 Configuration:
The following output shows the configuration required for a VPLS service using a pseudowire
template configured for auto-provisioning of SDPs.
A:PE-1# configure service vpls 3 customer 1 create
bgp
route-distinguisher 65536:3
route-target export target:65536:3 import target:65536:3
pw-template-binding 2 split-horizon-group "vpls-shg"
import-rt "target:65536:3"
exit
exit
bgp-ad
vpls-id 65536:3
vsi-id
prefix 192.0.2.1
exit
no shutdown
exit
stp
shutdown
exit
sap 1/2/1:3.0 create
exit
no shutdown

Page 1070

Advanced Configuration Guide

LDP VPLS using BGP-Auto Discovery

Within the bgp context, the pseudowire template is referenced which can be linked to a splithorizon-group and an import route-target, if required.
Within the bgp-ad context, the signalling parameters are configured. These are two parameters
used by each PE to determine the presence of a given VPLS instance on a PE router. In turn, these
are translated into endpoint identifiers for LDP signalling of pseudowires. As previously
discussed, these parameters are:

VPLS-id - a unique identifier of the VPLS instance. Each PE that is a member of a VPLS
must share the same VPLS-id. This is inserted as an extended community value in the
format AS:n. In this case, the VPLS-id for VPLS 3 is 65536:3. This is a mandatory
parameter and if it is not configured it is not possible to enable bgp-ad using no shutdown.

Virtual Switching Instance (VSI) prefix This identifies a specific instance of the VPLS.
This must be unique within the VPLS instance, and is encoded using the 4 byte dotted
decimal notation. Generally the system address is used as the VSI prefix. If this parameter
is not configured, then the system address is used automatically.

The VPLS-id and VSI prefix for VPLS 3 on each PE is shown in Figure 77.
The VPLS-id and VSI prefix are concatenated to form a unique VSI-id. In this case, PE-1 has a
VSI-id of 65536:3:192.0.2.1. This uniquely identifies the VPLS instance on each individual PE
and is advertised as an L2 VPN BGP update.
A BGP-AD update is transmitted to all other PEs via the Route Reflector as follows:
A:PE-1# show router bgp routes l2-vpn rd 65536:3 hunt
------------------------------------------------------------------------------RIB Out Entries
------------------------------------------------------------------------------Route Type
: AutoDiscovery
Route Dist.
: 65536:3
Prefix
: 192.0.2.1
Nexthop
: 192.0.2.1
To
: 192.0.2.20
Res. Nexthop
: n/a
Local Pref.
: 100
Interface Name : NotAvailable
Aggregator AS : None
Aggregator
: None
Atomic Aggr.
: Not Atomic
MED
: 0
Community
: target:65536:3 l2-vpn:65536:3
Cluster
: No Cluster Members
Originator Id : None
Peer Router Id : 192.0.2.20
Origin
: IGP
AS-Path
: No As-Path
------------------------------------------------------------------------------Routes : 1

The BGP update shown above is transmitted by PE-1 and has route type Auto Discovery.
In this L2 VPN update, the VPLS-id is encoded as the L2VPN extended community.

Advanced Configuration Guide

Page 1071

Configuration

The VSI is seen as the prefix. This combination forms the VSI-id and uniquely identifies the
VPLS instance within this PE router.
The nexthop is also encoded as the local system IP address, which allows remote PEs to identify a
suitable transport tunnel to PE-1 and for the targeted-LDP peer for instantiating the SDP.
As can be seen within the update, the VPLS-id is also used to determine the route target extended
community and the route distinguisher.
PE-2 Configuration
On PE-2 create a VPLS Service using pseudowire template 1, with VPLS-id 65536:3 and VSI-id
prefix 192.0.2.2 (system IP address).
A:PE-2# configure service vpls 3 customer 1 create
bgp
route-distinguisher 65536:3
route-target export target:65536:3 import target:65536:3
pw-template-binding 3 split-horizon-group "vpls-shg"
import-rt "target:65536:3"
exit
bgp-ad
vpls-id 65536:3
vsi-id
prefix 192.0.2.2
exit
no shutdown
exit
stp
shutdown
exit
sap 1/1/1:3.0 create
exit
no shutdown
exit

PE-3 Configuration
Create a VPLS Instance on PE-3: VPLS-id is the same as that of PE-1 and PE-2, with VSI-id of
192.0.2.3 (system IP address).
B:PE-3# configure service vpls 3 customer 1 create
bgp
route-distinguisher 65536:3
route-target export target:65536:3 import target:65536:3
pw-template-binding 3 split-horizon-group "vpls-shg"
import-rt
"target:65536:3"
exit
bgp-ad
vpls-id 65536:3
vsi-id
prefix 192.0.2.3
exit
no shutdown

Page 1072

Advanced Configuration Guide

LDP VPLS using BGP-Auto Discovery

exit
stp
shutdown
exit
sap 1/1/3:3.0 create
exit
no shutdown
exit

PE-1 Service Operation Verification


Verify that the service is operationally up on PE-1.
A:PE-1# show service id 3 base
===============================================================================
Service Basic Information
===============================================================================
Service Id
: 3
Vpn Id
: 0
Service Type
: VPLS
Name
: (Not Specified)
Description
: (Not Specified)
Customer Id
: 1
Last Status Change: 07/20/2011 14:54:24
Last Mgmt Change : 07/20/2011 14:54:21
Admin State
: Up
Oper State
: Up
MTU
: 1514
Def. Mesh VC Id
: 3
SAP Count
: 1
SDP Bind Count
: 2
Snd Flush on Fail : Disabled
Host Conn Verify : Disabled
Propagate MacFlush: Disabled
Per Svc Hashing
: Disabled
Allow IP Intf Bind: Disabled
Def. Gateway IP
: None
Def. Gateway MAC : None
Temp Flood Time
: Disabled
Temp Flood
: Inactive
Temp Flood Chg Cnt: 0
------------------------------------------------------------------------------BGP Auto-discovery Information
------------------------------------------------------------------------------Admin State
: Up
Vpls Id
: 65536:3
Route Dist
: 65536:3
Prefix
: 192.0.2.1
Rte-Target Import : 65536:3
Rte-Target Export : 65536:3
Vsi-Import
: None
Vsi-Export
: None
PW-Template Id
: 1
PW-Template SHG
: None
Oper Group
: None
Import Rte-Tgt
: None
------------------------------------------------------------------------------------------------------------------------------------------------------------Service Access & Destination Points
------------------------------------------------------------------------------Identifier
Type
AdmMTU OprMTU Adm Opr
------------------------------------------------------------------------------sap:1/2/1:3.0
qinq
1522
1522
Up
Up
sdp:17385:4294967240 SB(192.0.2.3)
BgpAd
0
9190
Up
Up
sdp:17386:4294967241 SB(192.0.2.2)
BgpAd
0
9190
Up
Up

Advanced Configuration Guide

Page 1073

Configuration

===============================================================================
A:PE-1#

As seen from the output, the service is operationally up, with the SAPs and SDPs also up. The SB
flag indicates that the SDP is of type spoke BGP.
BGP is used to discover the VPLS endpoints and exchange network reachability information. LDP
is used to signal the pseudowires between the PEs.
LDP signalling occurs when each PE has discovered the endpoints of the VPLS instance. This
compares with the use of the provisioned virtual-circuit IDs used in an NMS provisioned VPLS
instances as per RFC 4762.
Verification of the ability of PE-1 to reach the other PE routers with VSIs within the VPLS
instance can be seen from the Layer 2 routing table as follows:
A:PE-1#show service l2-route-table bgp-ad
========================================================================
Services: L2 Route Information - Summary
========================================================================
Svc Id
L2-Routes (RD-Prefix)
Next Hop
Origin
Sdp Bind Id
PW Temp Id
-----------------------------------------------------------------------3
*65536:3-192.0.2.2
192.0.2.2
BGP-L2
17387:4294967243
1
3
*65536:3-192.0.2.3
192.0.2.3
BGP-L2
17386:4294967242
1
-----------------------------------------------------------------------No. of L2 Route Entries: 2
========================================================================

This output shows the presence of the signalled pseudowire SDPs. SDPs from PE-1 to PE-2 and
PE-3 are signalled using LDP Forwarding Equivalence Class (FEC) Element 129.
Each PE router uses targeted LDP to signal the local and remote endpoints. If there is an endpoint
match, then SDPs are instantiated. This compares with the use of LDP for NMS provisioned
SDPs, which uses virtual-circuit IDs to signal pseudowires using LDP FEC Element 128.
In order to signal the SDPs, the following parameters are required:
1. Attachment Group Identifier (AGI): this is used to carry the VPLS-id of the local PE router
VPLS instance. The VPLS-id must be the same for all PEs in the same VPLS instance.
2. Source Attachment Individual Identifier (SAII) and Target Attachment Individual Identifier
(TAII): These use AII type 1 (RFC 4446) and are used to carry the NRLI (VSI-id minus the
RD) of the remote PE router VPLS instance.
The AGI for each PE must be identical. SAII and TAII must be different.

Page 1074

Advanced Configuration Guide

LDP VPLS using BGP-Auto Discovery

The following shows the service LDP bindings for VPLS 3 on PE-1:
A:PE-1# show router ldp bindings service-id 3
===============================================================================
LDP LSR ID: 192.0.2.1
===============================================================================
Legend: U - Label In Use, N - Label Not In Use, W - Label Withdrawn
S - Status Signaled Up, D - Status Signaled Down
E - Epipe Service, V - VPLS Service, M - Mirror Service
A - Apipe Service, F - Fpipe Service, I - IES Service, R - VPRN service
P - Ipipe Service, WP - Label Withdraw Pending, C - Cpipe Service
TLV - (Type, Length: Value)
===============================================================================
LDP Service FEC 128 Bindings
===============================================================================
Type
VCId
SvcId
SDPId
Peer
IngLbl EgrLbl LMTU RMTU
------------------------------------------------------------------------------No Matching Entries Found
===============================================================================
===============================================================================
LDP Service FEC 129 Bindings
===============================================================================
AGI
SAII
TAII
Type
SvcId
SDPId
Peer
IngLbl EgrLbl LMTU RMTU
------------------------------------------------------------------------------1,8:020A000100000003
192.0.2.1
192.0.2.2
V-Eth
3
R. Src
192.0.2.2
131046U 131047S 1500 1500
1,8:020A000100000003
V-Eth

192.0.2.1
192.0.2.3
R. Src
192.0.2.3

131037U 131035S 1500 1500

------------------------------------------------------------------------------No. of FEC 129s: 2

This shows the two T-LDP bindings for PE-1 towards PE-2 and PE-3 for VPLS 3.
The AGI entry 1, 8:020A000100000003 is the direct encoding from the AGI TLV within the TLD
FEC 129 Element as described by the following:
type 1, length 8, Variable (VPLS-id) 020A000100000003 = 65536:3
SAII Local system IP address 192.0.2.1
TAII Remote system IP address 192.0.2.2 or 192.0.2.3
The ingress and egress labels can also be seen from the SDP bindings from the service:
A:PE-1# show service id 3 sdp
===============================================================================
Services: Service Destination Points
===============================================================================
SdpId
Type IP address
Adm
Opr
I.Lbl
E.Lbl

Advanced Configuration Guide

Page 1075

Configuration

------------------------------------------------------------------------------17385:4294967240 Bgp* 192.0.2.3


Up
Up
131037
131035
17386:4294967241 Bgp* 192.0.2.2
Up
Up
131046
131047
------------------------------------------------------------------------------Number of SDPs : 2
-------------------------------------------------------------------------------

The SDPs are auto-provisioned SDPs, like SDP 17386 towards PE-2 and 17385 towards PE-3.
The label bindings from the SDP and LDP binding outputs are identical.

Page 1076

Advanced Configuration Guide

LDP VPLS using BGP-Auto Discovery

PE-2 Service Operation Verification


For completeness, verify the service is operationally up on PE-2.
A:PE-2# show service id 3 base
===============================================================================
Service Basic Information
===============================================================================
Service Id
: 3
Vpn Id
: 0
Service Type
: VPLS
Name
: (Not Specified)
Description
: (Not Specified)
Customer Id
: 1
Last Status Change: 07/18/2011 17:14:41
Last Mgmt Change : 07/20/2011 14:54:24
Admin State
: Up
Oper State
: Up
MTU
: 1514
Def. Mesh VC Id
: 3
SAP Count
: 1
SDP Bind Count
: 2
Snd Flush on Fail : Disabled
Host Conn Verify : Disabled
Propagate MacFlush: Disabled
Per Svc Hashing
: Disabled
Allow IP Intf Bind: Disabled
Def. Gateway IP
: None
Def. Gateway MAC : None
Temp Flood Time
: Disabled
Temp Flood
: Inactive
Temp Flood Chg Cnt: 0
------------------------------------------------------------------------------BGP Auto-discovery Information
------------------------------------------------------------------------------Admin State
: Up
Vpls Id
: 65536:3
Route Dist
: 65536:3
Prefix
: 192.0.2.2
Rte-Target Import : 65536:3
Rte-Target Export : 65536:3
Vsi-Import
: None
Vsi-Export
: None
PW-Template Id
: 1
PW-Template SHG
: None
Oper Group
: None
Import Rte-Tgt
: None
------------------------------------------------------------------------------------------------------------------------------------------------------------Service Access & Destination Points
------------------------------------------------------------------------------Identifier
Type
AdmMTU OprMTU Adm Opr
------------------------------------------------------------------------------sap:1/1/1:3.0
qinq
1522
1522
Up
Up
sdp:17381:4294967187 SB(192.0.2.1)
BgpAd
0
9190
Up
Up
sdp:17382:4294967190 SB(192.0.2.3)
BgpAd
0
9190
Up
Up
===============================================================================
A:PE-2#

A:PE-2# show router ldp bindings service-id 3


===============================================================================
LDP LSR ID: 192.0.2.2
===============================================================================
Legend: U - Label In Use, N - Label Not In Use, W - Label Withdrawn
S - Status Signaled Up, D - Status Signaled Down

Advanced Configuration Guide

Page 1077

Configuration

E - Epipe Service, V - VPLS Service, M - Mirror Service


A - Apipe Service, F - Fpipe Service, I - IES Service, R - VPRN service
P - Ipipe Service, WP - Label Withdraw Pending, C - Cpipe Service
TLV - (Type, Length: Value)
===============================================================================
LDP Service FEC 128 Bindings
===============================================================================
Type
VCId
SvcId
SDPId
Peer
IngLbl EgrLbl LMTU RMTU
------------------------------------------------------------------------------No Matching Entries Found
===============================================================================
===============================================================================
LDP Service FEC 129 Bindings
===============================================================================
AGI
SAII
TAII
Type
SvcId
SDPId
Peer
IngLbl EgrLbl LMTU RMTU
------------------------------------------------------------------------------1,8:020A000100000003
192.0.2.2
192.0.2.1
V-Eth
3
R. Src
192.0.2.1
131047U 131046S 1500 1500
1,8:020A000100000003
V-Eth

192.0.2.2
192.0.2.3
R. Src
192.0.2.3

131049U 131044S 1500 1500

------------------------------------------------------------------------------No. of FEC 129s: 2


===============================================================================
A:PE-2#

A:PE-2# show service id 3 sdp


===============================================================================
Services: Service Destination Points
===============================================================================
SdpId
Type IP address
Adm
Opr
I.Lbl
E.Lbl
------------------------------------------------------------------------------17381:4294967187 Bgp* 192.0.2.1
Up
Up
131047
131046
17382:4294967190 Bgp* 192.0.2.3
Up
Up
131049
131044
------------------------------------------------------------------------------Number of SDPs : 2
------------------------------------------------------------------------------A:PE-2#

Page 1078

Advanced Configuration Guide

LDP VPLS using BGP-Auto Discovery

PE-3 Service Operation Verification


Verify service is operationally up on PE-3.
B:PE-3# show service id 3 base
===============================================================================
Service Basic Information
===============================================================================
Service Id
: 3
Vpn Id
: 0
Service Type
: VPLS
Name
: (Not Specified)
Description
: (Not Specified)
Customer Id
: 1
Last Status Change: 07/16/2011 12:07:43
Last Mgmt Change : 07/20/2011 14:54:24
Admin State
: Up
Oper State
: Up
MTU
: 1514
Def. Mesh VC Id
: 3
SAP Count
: 1
SDP Bind Count
: 2
Snd Flush on Fail : Disabled
Host Conn Verify : Disabled
Propagate MacFlush: Disabled
Per Svc Hashing
: Disabled
Allow IP Intf Bind: Disabled
Def. Gateway IP
: None
Def. Gateway MAC : None
Temp Flood Time
: Disabled
Temp Flood
: Inactive
Temp Flood Chg Cnt: 0
------------------------------------------------------------------------------BGP Auto-discovery Information
------------------------------------------------------------------------------Admin State
: Up
Vpls Id
: 65536:3
Route Dist
: 65536:3
Prefix
: 192.0.2.3
Rte-Target Import : 65536:3
Rte-Target Export : 65536:3
Vsi-Import
: None
Vsi-Export
: None
PW-Template Id
: 1
PW-Template SHG
: None
Oper Group
: None
Import Rte-Tgt
: None
------------------------------------------------------------------------------------------------------------------------------------------------------------Service Access & Destination Points
------------------------------------------------------------------------------Identifier
Type
AdmMTU OprMTU Adm Opr
------------------------------------------------------------------------------sap:1/1/3:3.0
qinq
1522
1522
Up
Up
sdp:17382:4294967224 SB(192.0.2.1)
BgpAd
0
9190
Up
Up
sdp:17383:4294967228 SB(192.0.2.2)
BgpAd
0
9190
Up
Up
===============================================================================
B:PE-3#

Advanced Configuration Guide

Page 1079

Configuration

B:PE-3# show service l2-route-table bgp-ad


========================================================================
Services: L2 Route Information - Summary
========================================================================
Svc Id
L2-Routes (RD-Prefix)
Next Hop
Origin
Sdp Bind Id
PW Temp Id
-----------------------------------------------------------------------3
*65536:3-192.0.2.1
192.0.2.1
BGP-L2
17382:4294967224
1
3
*65536:3-192.0.2.2
192.0.2.2
BGP-L2
17383:4294967228
1
-----------------------------------------------------------------------No. of L2 Route Entries: 2

B:PE-3# show router ldp bindings service-id 3


===============================================================================
LDP LSR ID: 192.0.2.3
===============================================================================
Legend: U - Label In Use, N - Label Not In Use, W - Label Withdrawn
S - Status Signaled Up, D - Status Signaled Down
E - Epipe Service, V - VPLS Service, M - Mirror Service
A - Apipe Service, F - Fpipe Service, I - IES Service, R - VPRN service
P - Ipipe Service, WP - Label Withdraw Pending, C - Cpipe Service
TLV - (Type, Length: Value)
===============================================================================
LDP Service FEC 128 Bindings
===============================================================================
Type
VCId
SvcId
SDPId
Peer
IngLbl EgrLbl LMTU RMTU
------------------------------------------------------------------------------No Matching Entries Found
===============================================================================
===============================================================================
LDP Service FEC 129 Bindings
===============================================================================
AGI
SAII
TAII
Type
SvcId
SDPId
Peer
IngLbl EgrLbl LMTU RMTU
------------------------------------------------------------------------------1,8:020A000100000003
192.0.2.3
192.0.2.1
V-Eth
3
R. Src
192.0.2.1
131035U 131037S 1500 1500
1,8:020A000100000003

192.0.2.3
192.0.2.2
V-Eth
3
R. Src
192.0.2.2
131044U 131049S 1500 1500
------------------------------------------------------------------------------No. of FEC 129s: 2
===============================================================================
B:PE-3#

B:PE-3# show service id 3 sdp


===============================================================================
Services: Service Destination Points
===============================================================================
SdpId
Type IP address
Adm
Opr
I.Lbl
E.Lbl
------------------------------------------------------------------------------17382:4294967224 Bgp* 192.0.2.1
Up
Up
131035
131037

Page 1080

Advanced Configuration Guide

LDP VPLS using BGP-Auto Discovery

17383:4294967228 Bgp* 192.0.2.2


Up
Up
131044
131049
------------------------------------------------------------------------------Number of SDPs : 2
------------------------------------------------------------------------------===============================================================================
* indicates that the corresponding row element may have been truncated.

Advanced Configuration Guide

Page 1081

Configuration

BGP AD using Pre-Provisioned SDPs


It is possible to configure BGP-AD instances that use RSVP transport tunnels. In this case, the
LSPs and SDPs must be manually created.
PE-1
VPLS-ID 65536:6
VSI-192.0.2.1

RR1
192.0.2.20

CE

SDP 44

PE-3
VPLS-ID 65536:6
VSI-192.0.2.3

SDP 43

SDP 47

CE

VPLS 4
SDP 48
SDP 45

CE
SDP 46

PE-2
VPLS-ID 65536:6
VSI-192.0.2.2

ACG0003

Figure 78: VPLS Instance using Pre-Provisioned SDPs

Figure 78 shows a VPLS instance configured across three Provider Edge routers as before.
The SDP configurations for the three PEs are shown below:
SDPs on PE-1
configure service
sdp 43 mpls create
far-end 192.0.2.2
lsp "LSP-PE-1-PE-2"
keep-alive
shutdown
exit
no shutdown
exit
sdp 44 mpls create
far-end 192.0.2.3
lsp "LSP-PE-1-PE-3"
keep-alive
shutdown
exit
no shutdown
exit
exit

Page 1082

Advanced Configuration Guide

LDP VPLS using BGP-Auto Discovery

SDPs on PE-2
configure service
sdp 45 mpls create
far-end 192.0.2.1
lsp "LSP-PE-2-PE-1"
keep-alive
shutdown
exit
no shutdown
exit
sdp 46 mpls create
far-end 192.0.2.3
lsp "LSP-PE-2-PE-3"
keep-alive
shutdown
exit
no shutdown
exit
exit

SDPs on PE-3
configure service
sdp 47 mpls create
far-end 192.0.2.1
lsp "LSP-PE-3-PE-1"
keep-alive
shutdown
exit
collect-stats
no shutdown
exit
sdp 48 mpls create
far-end 192.0.2.2
lsp "LSP-PE-3-PE-2"
keep-alive
shutdown
exit
no shutdown
exit
exit

Advanced Configuration Guide

Page 1083

Configuration

The pw-template that is to be used within each VPLS instance must be provisioned on all PEs and
must use the keyword use-provisioned-sdp. The pw-template looks like:
A:PE-1# configure service
pw-template 3 use-provisioned-sdp create
exit
exit

This configuration must be repeated on both PE-2 and PE-3.


The following output shows the configuration required for a VPLS service using a pseudowire
template configured for pre-provisioned RSVP SDPs.
A:PE-1# configure service vpls 4 customer 1 create
bgp
route-distinguisher:65536:4
route-target export target:65536:4 import target:65536:4
pw-template-binding 3 split-horizon-group "vpls-shg"
import-rt "target:65536:4"
exit
exit
bgp-ad
vpls-id 65536:4
vsi-id
prefix 192.0.2.1
exit
no shutdown
exit
stp
shutdown
exit
sap 1/1/3:4.0 create
exit
no shutdown

Similarly, on PE-2 the configuration is shown below:


A:PE-2# configure service vpls 4 customer 1 create
bgp
route-distinguisher:65536:4
route-target export target:65536:4 import target:65536:4
pw-template-binding 3 split-horizon-group "vpls-shg"
import-rt "target:65536:4"
exit
exit
bgp-ad
vpls-id 65536:4
vsi-id
prefix 192.0.2.2
exit
no shutdown
exit
stp
shutdown

Page 1084

Advanced Configuration Guide

LDP VPLS using BGP-Auto Discovery

exit
sap 1/1/1:4.0 create
exit
no shutdown

On PE-3:
B:PE-3# config service vpls 4 customer 1 create
bgp
route-distinguisher:65536:4
route-target export target:65536:4 import target:65536:4
pw-template-binding 3 split-horizon-group "vpls-shg"
import-rt "target:65536:4"
exit
exit
bgp-ad
vpls-id 65536:4
vsi-id
prefix 192.0.2.3
exit
no shutdown
exit
stp
shutdown
exit
sap 1/1/4:4.0 create
exit
no shutdown

Verify that the service is operationally up on PE-1.


A:PE-1# show service id 4 base
===============================================================================
Service Basic Information
===============================================================================
Service Id
: 4
Vpn Id
: 0
Service Type
: VPLS
Name
: (Not Specified)
Description
: (Not Specified)
Customer Id
: 1
Last Status Change: 07/19/2011 14:16:10
Last Mgmt Change : 07/21/2011 12:21:34
Admin State
: Up
Oper State
: Up
MTU
: 1514
Def. Mesh VC Id
: 4
SAP Count
: 1
SDP Bind Count
: 2
Snd Flush on Fail : Disabled
Host Conn Verify : Disabled
Propagate MacFlush: Disabled
Per Svc Hashing
: Disabled
Allow IP Intf Bind: Disabled
Def. Gateway IP
: None
Def. Gateway MAC : None
Temp Flood Time
: Disabled
Temp Flood
: Inactive
Temp Flood Chg Cnt: 0
------------------------------------------------------------------------------BGP Auto-discovery Information
-------------------------------------------------------------------------------

Advanced Configuration Guide

Page 1085

Configuration

Admin State
Route Dist
Rte-Target Import
Vsi-Import
Vsi-Export

:
:
:
:
:

Up
65536:4
65536:4
None
None

Vpls Id
: 65536:4
Prefix
: 192.0.2.1
Rte-Target Export : 65536:4

PW-Template Id
: 2
PW-Template SHG
: None
Oper Group
: None
Import Rte-Tgt
: None
------------------------------------------------------------------------------------------------------------------------------------------------------------Service Access & Destination Points
------------------------------------------------------------------------------Identifier
Type
AdmMTU OprMTU Adm Opr
------------------------------------------------------------------------------sap:1/1/3:4.0
qinq
1522
1522
Up
Up
sdp:43:4294967238 SB(192.0.2.2)
BgpAd
0
9190
Up
Up
sdp:44:4294967239 SB(192.0.2.3)
BgpAd
0
9190
Up
Up
===============================================================================
A:PE-1#

Note that the SDP identifiers are the pre-provisioned SDPs, i.e. SDP 43 and 44.
For completeness, verify the service is operationally up on PE-2.
A:PE-2# show service id 4 base
===============================================================================
Service Basic Information
===============================================================================
Service Id
: 4
Vpn Id
: 0
Service Type
: VPLS
Name
: (Not Specified)
Description
: (Not Specified)
Customer Id
: 1
Last Status Change: 07/21/2011 12:21:50
Last Mgmt Change : 07/21/2011 12:21:50
Admin State
: Up
Oper State
: Up
MTU
: 1514
Def. Mesh VC Id
: 4
SAP Count
: 1
SDP Bind Count
: 2
Snd Flush on Fail : Disabled
Host Conn Verify : Disabled
Propagate MacFlush: Disabled
Per Svc Hashing
: Disabled
Allow IP Intf Bind: Disabled
Def. Gateway IP
: None
Def. Gateway MAC : None
Temp Flood Time
: Disabled
Temp Flood
: Inactive
Temp Flood Chg Cnt: 0
------------------------------------------------------------------------------BGP Auto-discovery Information
------------------------------------------------------------------------------Admin State
: Up
Vpls Id
: 65536:4
Route Dist
: 65536:4
Prefix
: 192.0.2.3
Rte-Target Import : 65536:4
Rte-Target Export : 65536:4
Vsi-Import
: None
Vsi-Export
: None
PW-Template Id

Page 1086

: 2

PW-Template SHG

: None

Advanced Configuration Guide

LDP VPLS using BGP-Auto Discovery

Oper Group
: None
Import Rte-Tgt
: None
------------------------------------------------------------------------------------------------------------------------------------------------------------Service Access & Destination Points
------------------------------------------------------------------------------Identifier
Type
AdmMTU OprMTU Adm Opr
------------------------------------------------------------------------------sap:1/1/1:4.0
qinq
1522
1522
Up
Up
sdp:45:4294967185 SB(192.0.2.1)
BgpAd
0
9190
Up
Up
sdp:46:4294967186 SB(192.0.2.3)
BgpAd
0
9190
Up
Up
===============================================================================
A:PE-2#

Verify service is operational on PE-3.


B:PE-3# show service id 4 base
===============================================================================
Service Basic Information
===============================================================================
Service Id
: 4
Vpn Id
: 0
Service Type
: VPLS
Name
: (Not Specified)
Description
: (Not Specified)
Customer Id
: 1
Last Status Change: 07/21/2011 12:20:21
Last Mgmt Change : 07/21/2011 12:21:34
Admin State
: Up
Oper State
: Up
MTU
: 1514
Def. Mesh VC Id
: 4
SAP Count
: 1
SDP Bind Count
: 2
Snd Flush on Fail : Disabled
Host Conn Verify : Disabled
Propagate MacFlush: Disabled
Per Svc Hashing
: Disabled
Allow IP Intf Bind: Disabled
Def. Gateway IP
: None
Def. Gateway MAC : None
Temp Flood Time
: Disabled
Temp Flood
: Inactive
Temp Flood Chg Cnt: 0
------------------------------------------------------------------------------BGP Auto-discovery Information
------------------------------------------------------------------------------Admin State
: Up
Vpls Id
: 65536:4
Route Dist
: 65536:4
Prefix
: 192.0.2.2
Rte-Target Import : 65536:4
Rte-Target Export : 65536:4
Vsi-Import
: None
Vsi-Export
: None
PW-Template Id
: 2
PW-Template SHG
: None
Oper Group
: None
Import Rte-Tgt
: None
------------------------------------------------------------------------------------------------------------------------------------------------------------Service Access & Destination Points
------------------------------------------------------------------------------Identifier
Type
AdmMTU OprMTU Adm Opr
-------------------------------------------------------------------------------

Advanced Configuration Guide

Page 1087

Configuration

sap:1/1/3:4.0
qinq
1522
1522
Up
Up
sdp:47:4294967223 SB(192.0.2.1)
BgpAd
0
9190
Up
Up
sdp:48:4294967222 SB(192.0.2.2)
BgpAd
0
9190
Up
Up
===============================================================================
B:PE-3#

Page 1088

Advanced Configuration Guide

LDP VPLS using BGP-Auto Discovery

Conclusion
BGP-Auto discovery coupled with LDP pseudowire signalling allows the delivery of L2 VPN
services to customers where BGP is commonly used. This example shows the configuration of
BGP-Auto discovery together with the associated show outputs which can be used for verification
and troubleshooting.

Advanced Configuration Guide

Page 1089

Conclusion

Page 1090

Advanced Configuration Guide

Managed SAPs with Routed CO

In This Chapter
This section provides information about Managed SAPs with Routed CO.
Topics in this section include:

Applicability on page 1092

Overview on page 1093

Configuration on page 1096

Conclusion on page 1122

Advanced Configuration Guide

Page 1091

Applicability

Applicability
This section is applicable to the 7750 SR7/12 with IOM2 or higher (for BRAS functionality) with
Chassis mode B or higher (for Routed Central Office (CO) model) and the 7710/7750 SR-c12 and
was tested on release 7.0R5. Routed CO is supported on 7450 ESS-7 or ESS-12 in mixed-mode
since 8.0R1. The 7750 SR-c4 is supported from 8.0R4 and higher.
This note is related only to the use of IPv4.
MSAPs are also supported with Bridged CO model and on the 7450, however, applicable
configuration information is beyond the scope of this document.

Page 1092

Advanced Configuration Guide

Managed SAPs with Routed-CO

Overview
Managed Service Access Point (MSAP) allows the use of policies and a SAP template for the
creation of a SAP. As part of the MSAP feature, individual SAPs are created along with the
subscriber host with minimal configuration on the BRAS node. Creation of a managed SAP is
triggered by a DHCP-DISCOVER and/or a PPPoE-PADI message. In this case, the authentication
response message not only returns the subscriber host attributes, but also the managed SAP policy
and service ID.These latter two parameters are used by the system to create the subscriber SAP
with default settings as indicated in the managed SAP policy and then assigning it to the
corresponding VPN service. In this model, each subscriber is defined with its own VLAN. This
feature uses authentication mechanisms supported by the node to create a SAP.
When enabled, receiving a triggering packet initiates RADIUS authentication that provides a
service context. The authentication, together with the service context for this request, creates a
managed SAP.
The VLAN is the same as the triggering packet. This SAP behaves as a regular SAP but its
configuration is not user editable and not maintained in the configuration file. The managed SAP
remains active as long as the session is active.
Knowledge of Alcatel-Lucent TPSDA (Triple Play Service Delivery Architecture) and
functionality is assumed throughout this document.
The network topology is displayed in Figure 79. The configuration consists of one 7750 SR-7
acting as a BNG with BRAS functionality.

Capture SAP
1/2/2:*
PPPoE
Clients

172.16.1.1

RADIUS-1

VRF
DSLAM

VPLS
BNG-1
192.0.2.1

OOB_Mgmt IP
172.30.1.34
OSSG412

Figure 79: Network Topology

Advanced Configuration Guide

Page 1093

Overview

Capture SAP
A capture SAP is used to capture triggering packetsand initiate RADIUS authentication. This SAP
is defined in a similar way to a default SAP but does not forward traffic.
A capture SAP and default SAP cannot be configured at the same time for a single port with the
dot1q encapsulation or for a single port:topq combination with qinq encapsulation. Managed
SAPs and regular SAPs can co-exist on the same port and in the same service.
The capture SAP is used if a more specific match for the Q or Q-in-Q tags is not found by the
traffic classification on the IOM. If a capturing SAP is defined, triggering packets are sent to the
CPM. Non-triggering packets captured by the capturing SAP are dropped.
The following are examples for supported modes:
SAP 1/2/2:*

for dot1Q

SAP 1/2/2:Q1.* for QinQ (where Q1 > 0)


The MSAP created will have a single tag (for dot1q) or both q-tags (for qinq) that arrived in the
original packet if authenticated by RADIUS.
While MSAPs are supported in both routed CO and bridged CO Triple Play Service Delivery
Archicture (TPSDA) models, the triggering SAP must be created in a VPLS service.

Triggering Packets
DHCP discover (or requests if re-authentication is configured) for DHCP clients. The managed
SAP lifetime is defined by the lease time.
PPPoE PADI for the PPPoE client. The MSAP lifetime is defined by the session time. The MSAP
is installed after the IP address is provided.
ARP packets as trigger packets within a capture SAP. ARP trigger packets can be used for static IP
hosts. The managed SAP lifetime is defined by the ARP entry lifetime and is subject to the same
ARP entry refresh mechanisms as other ARP entries.
All trigger types can be combined on a SAP supporting DHCP, PPPoE and ARP hosts. In this
chapter, PPPoE client is used.

Page 1094

Advanced Configuration Guide

Managed SAPs with Routed-CO

RADIUS Authentication and Vendor Specifc Attributes (VSAs) for


MSAP
An MSAP is created in the service-id context that is returned from RADIUS. The RADIUS
attribute Alc-MSAP-Serv-Id refers to the service in which the MSAP is created.
In a Routed CO scenario, the MSAP is created in a group-interface context. The group-interface
name is returned from RADIUS attribute Alc-MSAP-Interface and must exist in the provided
service for the MSAP to be installed.
The MSAP parameters are defined in the creation policy. The policy name is returned from
RADIUS in the attribute Alc-MSAP-Policy in order for the MSAP to be created.

Advanced Configuration Guide

Page 1095

Configuration

Configuration
Configure RADIUS Authentication Policy authentication-1
The following output shows a RADIUS authentication policy configuration defining
authentication-1.
configure subscriber-mgmt
authentication-policy "authentication-1" create
radius-authentication-server
source-address 172.30.1.34
router "management"
server 1 address 172.16.1.1 secret ALU
exit
pppoe-access-method pap-chap
include-radius-attribute
remote-id
nas-identifier
mac-address
exit
exit
exit

Where, management routing instance and the out-of-band and IP address 172.30.1.34 are used as a
source address to communicate authentication messages between the BNG and the RADIUS
server. The RADIUS server IP address is 172.16.1.1. Up to five servers can be configured. When
having multiple servers two possible access algorithms can be configured to access the list of
RADIUS servers, direct or round-robin.
The value of secret is ALU which is case sensitive and must be configured on Clients.conf file on
the RADIUS server in advance. Up to 20 characters in length are possible.
The authentication method used in our example is PAP/CHAP, so the pap-chap value is used for
the pppoe-access-method.
The users remote-id and mac-address are sent as well the nas-identifier into the access request
message towards the RADIUS.
By default, the RADIUS authentication messages are send over port 1812 but can be overridden
by adding an explicit port setting to the server command.
configure subscriber-mgmt
authentication-policy "authentication-1" create
radius-authentication-server
server 1 address 172.16.1.1 secret ALU port <value>

Page 1096

Advanced Configuration Guide

Managed SAPs with Routed-CO

Configure a RADIUS Accounting Policy


This example configures radius-accounting-policy "accounting-1".
configure subscriber-mgmt
radius-accounting-policy "accounting-1" create
update-interval 10
include-radius-attribute
framed-ip-addr
subscriber-id
circuit-id
remote-id
nas-port-id
nas-identifier
sub-profile
sla-profile
user-name
exit
session-id-format number
use-std-acct-attributes
radius-accounting-server
router "management"
server 1 address 172.16.1.1 secret ALU
exit
exit
exit

Where, accounting updates are sent every 10 mins (the default update-interval is 5 minutes). The
accounting session-id-format in this example is a number (40 HEX character string).
SESSION ID [44] 40 000000010241000000000064000000034B090B2D

Whereas, session-id-format <description> can be used in this case. The session-id-format is as


follows:
<subscriber>@<sapid>@<SLA-profile>_<creation-time>
SESSION ID [44] 50 user1@1/2/2:100@sla-profile-2M_2009/11/22 11:56:25

Since use-std-acct-attributes are used, only the total number of octets/packets in ingress and egress
directions are sent.
ALU VSAs are used for accounting, in such case, a detailed accounting values for each queue (in
case multiple queues for the subscriber can be used) and the in-profile, out-profile values as well.
This feature can be enabled by adding no use-std-acct-attribute, which is the default.
By default, the RADIUS accounting messages are send over port 1813 but can be overridden by
adding an explicit port setting in addition to the server command.

Advanced Configuration Guide

Page 1097

Configuration

configure subscriber-mgmt
radius-accounting-policy accounting-1 create
radius-authentication-server
server 1 address 172.16.1.1 secret ALU port <value>

Page 1098

Advanced Configuration Guide

Managed SAPs with Routed-CO

Configure an QoS SAP Ingress Policy


Configure QoS SAP ingress policy where shaping and SAP egress policy performs shaping and
remarking. Values for dot1p and dscp are used as examples.
configure qos
sap-ingress 20 create
description "64K_upstream"
queue 1 create
rate 64
exit
exit
sap-ingress 30 create
description "128K_upstream"
queue 1 create
rate 128
exit
exit
sap-ingress 40 create
description "256K_upstream"
queue 1 create
rate 256
exit
exit
sap-ingress 50 create
description "512K_upstream"
queue 1 create
rate 512
exit
exit
sap-egress 20 create
description "256K_downstream"
queue 1 create
rate 256
exit
fc be create
queue 1
dot1p 5
dscp ef
exit
exit
sap-egress 30 create
description "512K_downstream"
queue 1 create
rate 512
exit
fc be create
queue 1
dot1p 4
dscp af21
exit
exit
sap-egress 40 create
description "1M_downstream"
queue 1 create
rate 1024
exit

Advanced Configuration Guide

Page 1099

Configuration

fc be create
queue 1
dot1p 5
dscp ef
exit
exit
sap-egress 50 create
description "2M_downstream"
queue 1 create
rate 2048
exit
fc be create
queue 1
dot1p 3
dscp cs1
exit
exit
exit

Page 1100

Advanced Configuration Guide

Managed SAPs with Routed-CO

Configure Enhanced Subscriber Management Parameters


Four SLA profiles are configured where the downstream speed is four times the upstream speed
and the SLA profile will be named with the downstream speed.
Also, a subscriber profile will be configured to initiate RADIUS accounting and doing SLA
profile mapping.
configure subscriber-mgmt
sla-profile "sla-profile-1M" create
ingress
qos 40 shared-queuing
exit
exit
egress
qos 40
exit
no qos-marking-from-sap
exit
exit
sla-profile "sla-profile-256K" create
ingress
qos 20 shared-queuing
exit
exit
egress
qos 20
exit
no qos-marking-from-sap
exit
exit
sla-profile "sla-profile-2M" create
ingress
qos 50 shared-queuing
exit
exit
egress
qos 50
exit
no qos-marking-from-sap
exit
exit
sla-profile "sla-profile-512K" create
ingress
qos 30 shared-queuing
exit
exit
egress
qos 30
exit
no qos-marking-from-sap
exit
exit
sub-profile "sub-profile-default" create
radius-accounting-policy "accounting-1"
sla-profile-map

Advanced Configuration Guide

Page 1101

Configuration

use-direct-map-as-default
exit
exit
sub-ident-policy "sub-id-default" create
sub-profile-map
use-direct-map-as-default
exit
sla-profile-map
use-direct-map-as-default
exit
exit
exit

Page 1102

Advanced Configuration Guide

Managed SAPs with Routed-CO

Configure an MSAP Policy


MSAP policies contain the configuration template (parameters) to be used for MSAP creation and
the necessary information to complete the subscriber identification process.
The MSAP policy that will be used is either returned by RADIUS in the access-accept message
during authentication phase if this MSAP policy is already configured under subscriber
management context, or else the default MSAP policy will be used instead.
configure subscriber-mgmt
msap-policy "msap-ISP1" create
sub-sla-mgmt
def-sub-id use-sap-id
def-sub-profile "sub-profile-default"
def-sla-profile "sla-profile-512K"
sub-ident-policy "sub-id-default"
single-sub-parameters
profiled-traffic-only
exit
exit
exit
msap-policy "msap-default" create
sub-sla-mgmt
def-sub-id use-sap-id
def-sub-profile "sub-profile-default"
def-sla-profile "sla-profile-256K"
sub-ident-policy "sub-id-default"
single-sub-parameters
profiled-traffic-only
exit
exit
exit
exit

If managed routes are required for a certain subscriber, add the following command under msappolicy. The default anti-spoof is ip-mac. Managed routes are out of the scope of this document.
configure subscriber-mgmt
msap-policy "msap-ISP1" create
ies-vprn-only-sap-parameters
anti-spoof nh-mac
exit
exit

Advanced Configuration Guide

Page 1103

Configuration

Configure a VPLS Service with a Capture SAP


Configure a VPLS service with capture SAP and define the triggering packet types. The triggerpacket and authentication-policy commands are mandatory within the capture SAP.
Additionally, the cpu-protection command can be added to enable CPU protection policies
configure service vpls 1
description "VPLS for Capture SAPs"
stp
shutdown
exit
sap 1/2/2:* capture-sap create
description "capture SAP for MSAP creation on port 1/2/2"
default-msap-policy "msap-default"
trigger-packet dhcp pppoe arp
authentication-policy "authentication-1"
exit
no shutdown
exit

Verify the details of capture SAP:


A:BNG-1# show service id 1 sap 1/2/2:* detail
===============================================================================
Service Access Points(SAP)
===============================================================================
Service Id
: 1
SAP
: 1/2/2:*
Encap
: q-tag
Description
: capture SAP for MSAP creation on port 1/2/2
Admin State
: Up
Oper State
: Up
Flags
: None
Multi Svc Site
: None
Last Status Change : 11/23/2009 09:33:44
Last Mgmt Change
: 11/23/2009 09:33:44
Sub Type
: capture
Triggers
: dhcp pppoe arp
---snip--Egr MCast Grp
:
Auth Policy
: authentication-1
PPPoE Policy
: default
---snip--------------------------------------------------------------------------------Sap Statistics
------------------------------------------------------------------------------Last Cleared Time
: N/A
Packets
Octets
Forwarding Engine Stats
Dropped
: 6
1536
DHCP Capture Stats
Received
Redirected
Dropped

: 0
: 0
: 0

PPPoE Capture Stats

Page 1104

Advanced Configuration Guide

Managed SAPs with Routed-CO

Received
Redirected
Dropped

: 10
: 0
: 0

ARP Capture Stats


Received
: 0
Redirected
: 0
Dropped
: 0
------------------------------------------------------------------------------Sap per Queue stats
------------------------------------------------------------------------------Packets
Octets
No entries found
===============================================================================
A:BNG-1#

Note that the dropped packets are those that are non triggering packets. Also, there are no SAP
queues instantiated for a capture SAP.

Advanced Configuration Guide

Page 1105

Configuration

Configuration Scenario Routed CO/VLAN-Per-Subscriber


(PPPOE)
The following output shows a Routed CO configuration example.
configure service vprn 2
route-distinguisher 65000:2
subscriber-interface "sub-int-1" create
address 10.255.255.254/8
group-interface "group-int-1" create
description "ROUTED CO MSAP VLAN X"
authentication-policy "authentication-1"
pppoe
session-limit 2000
no shutdown
exit
exit
exit
no shutdown
exit

Note that the number of PPPoE sessions can be controlled under a group interface by applying the
pppoe session-limit command.
Initially, since no MSAPs are present, the operational state of both the subscriber interface and
group interface context are down.
A:BNG-1# show router 2 interface
===============================================================================
Interface Table (Service: 2)
===============================================================================
Interface-Name
Adm
Opr(v4/v6) Mode
Port/SapId
IP-Address
PfxState
------------------------------------------------------------------------------group-int-1
Up
Down/-VPRN G* n/a
sub-int-1
Up
Down/-VPRN S* subscriber
10.255.255.254/8
n/a
------------------------------------------------------------------------------Interfaces : 2
===============================================================================
A:BNG-1#

Page 1106

Advanced Configuration Guide

Managed SAPs with Routed-CO

To allow the subscriber interface to consider this group interface to be operationally enabled
without any active SAPs, the following command can be added to the configuration (this would be
useful in order to propagate the subnet interface address into a routing protocol) :
configure service vprn 2
subscriber-interface "sub-int-1" create
group-interface "group-int-1" create
oper-up-while-empty
A:BNG-1# show router 2 interface
===============================================================================
Interface Table (Service: 2)
===============================================================================
Interface-Name
Adm
Opr(v4/v6) Mode
Port/SapId
IP-Address
PfxState
------------------------------------------------------------------------------group-int-1
Up
Down/-VPRN G* n/a
sub-int-1
Up
Up/-VPRN S* subscriber
10.255.255.254/8
n/a
------------------------------------------------------------------------------Interfaces : 2
===============================================================================
A:BNG-1#

Note that the status of group interface once the first MSAP is created.

Advanced Configuration Guide

Page 1107

Configuration

Configure RADIUS User Files


The following entry is an example of a user entry in a RADIUS users file for FreeRadius server.
"user1@ISP1.com"

Cleartext-Password := "user1_pass"
Alc-Subsc-ID-Str := "%{ADSL-Agent-Remote-Id}",
Alc-SLA-Prof-Str == "sla-profile-2M",
Alc-MSAP-Serv-ID = 2,
Alc-MSAP-Policy == "msap-ISP1",
Alc-MSAP-Interface == "group-int-1",
Framed-IP-Address = 10.255.0.1,
Alc-Primary-DNS = 67.138.54.100,
Alc-Secondary-DNS = 207.225.209.66

So when the PPPoE user sends the correct username and password, the RADIUS will accept the
access message and returns the correct VPRN service id 2, the correct group interface group-int-1
the MSAP policy to use msap-ISP1.
In case there are no MSAP policy returned from RADIUS, the default MSAP policy sap-default
under the capture SAP will be used instead.
In the above entry, the PPPoE user will have its IP address and DNS assigned by RADIUS as well.
The DNS values are examples for public Free DNSs.

Page 1108

Advanced Configuration Guide

Managed SAPs with Routed-CO

Connect PPPoE user1


Connect PPPoE user1, initiate a PPPoE session on VLAN 1 and verify PPPoE session
establishment.
A:BNG-1# show service id 2 pppoe session
===============================================================================
PPPoE sessions for svc-id 2
===============================================================================
Sap Id
Mac Address
Sid Up Time
IP/L2TP-Id
Type
------------------------------------------------------------------------------[1/2/2:1]
00:00:86:1c:79:a1 1
0d 00:05:32
10.255.0.1
Local
------------------------------------------------------------------------------Number of sessions : 1
===============================================================================
A:BNG-1#

The PPPoE session is established successfully and the user obtained the IP and subscriber strings
from the RADIUS.
In order to differentiate between the MSAP and the normal SAP, the MSAP will be shown
between square brackets [1/2/2:1] in the show commands

Advanced Configuration Guide

Page 1109

Configuration

Verify Subscriber Values


Verify subscriber values returned from RADIUS for user1.
A:BNG-1# show service id 2 pppoe session ip-address 10.255.0.1 detail
===============================================================================
PPPoE sessions for svc-id 2
===============================================================================
Sap Id
Mac Address
Sid Up Time
IP/L2TP-Id
Type
------------------------------------------------------------------------------[1/2/2:1]
00:00:86:1c:79:a1 1
0d 00:09:12
10.255.0.1
Local
LCP State
IPCP State
PPP MTU
PPP Auth-Protocol
PPP User-Name

:
:
:
:
:

Opened
Opened
1492
CHAP
user1@ISP1.com

Subscriber-interface : sub-int-1
Group-interface
: group-int-1
Subscriber Origin
Strings Origin
IPCP Info Origin

: Radius
: Radius
: Radius

Subscriber
Sub-Profile-String
SLA-Profile-String
ANCP-String
Int-Dest-Id
App-Profile-String
Category-Map-Name

:
:
:
:
:
:
:

"user1"
""
"sla-profile-2M"
""
""
""
""

Primary DNS
Secondary DNS
Primary NBNS
Secondary NBNS
Address-Pool

:
:
:
:
:

67.138.54.100
207.225.209.66
N/A
N/A
N/A

Circuit-Id
Remote-Id
Service-Name

: DSLAM1_1/1/1/1:0.35
: user1
:

Session-Timeout
: N/A
Radius Class
:
Radius User-Name
: user1@ISP1.com
------------------------------------------------------------------------------Number of sessions : 1
===============================================================================
A:BNG-1#

Page 1110

Advanced Configuration Guide

Managed SAPs with Routed-CO

Check the Actual Values


Check the actual values used by user1, subscriber profile, SLA profile, VPRN and group interface
association, the subscriber queues statistics and others.
A:BNG-1# show service active-subscribers subscriber user1 detail
===============================================================================
Active Subscribers
===============================================================================
Subscriber user1 (sub-profile-default)
------------------------------------------------------------------------------I. Sched. Policy : N/A
E. Sched. Policy : N/A
E. Agg Rate Limit: Max
Q Frame-Based Ac*: Disabled
Acct. Policy
: N/A
Collect Stats
: Disabled
Rad. Acct. Pol. : accounting-1
Dupl. Acct. Pol. : N/A
ANCP Pol.
: N/A
HostTrk Pol.
: N/A
Sub. ANCP-String : "user1"
Sub. Int Dest Id : ""
Host Trk Rate Adj: N/A
------------------------------------------------------------------------------(1) SLA Profile Instance
- sap:[1/2/2:1] (VPRN 2 - group-int-1)
- sla:sla-profile-2M
------------------------------------------------------------------------------Description
: (Not Specified)
Host Limit
: No Limit
Ingress Qos-Policy
: 50
Egress Qos-Policy : 50
Ingress Queuing Type : Shared-queuing
Ingress Filter-Id
: N/A
Egress Filter-Id : N/A
Ingress Report-Rate : N/A
Egress Report-Rate
: N/A
Egress Remarking
: from SLA Profile Qos
Credit Control Pol. : N/A
------------------------------------------------------------------------------------------------------------------------------------------------------------IP Address
MAC Address
PPPoE-SID Origin
------------------------------------------------------10.255.0.1
00:00:86:1c:79:a1 1
PPPoE
----------------------------------------------------------------------SLA Profile Instance statistics
----------------------------------------------------------------------Packets
Octets
Off. HiPrio
: 0
0
Off. LowPrio
: 0
0
Off. Uncolor
: 0
0
Queueing Stats (Ingress QoS Policy 50)
Dro. HiPrio
: 0
Dro. LowPrio
: 0
For. InProf
: 0
For. OutProf
: 0

Advanced Configuration Guide

0
0
0
0

Page 1111

Configuration

Queueing Stats (Egress QoS Policy 50)


Dro. InProf
: 0
Dro. OutProf
: 0
For. InProf
: 14
For. OutProf
: 0

0
0
896
0

----------------------------------------------------------------------SLA Profile Instance per Queue statistics


----------------------------------------------------------------------Packets
Octets
Ingress Queue 1 (Unicast) (Priority)
Off. HiPrio
: 0
0
Off. LowPrio
: 0
0
Off. Uncolor
: 0
0
Dro. HiPrio
: 0
0
Dro. LowPrio
: 0
0
For. InProf
: 0
0
For. OutProf
: 0
0
Egress Queue 1
Dro. InProf
: 0
0
Dro. OutProf
: 0
0
For. InProf
: 14
896
For. OutProf
: 0
0
===============================================================================
A:BNG-1#

Where, the subscriber id is user1, subscriber profile is sub-profile-default (note that the RADIUS
did not return subscriber profile string, so the system will use the def-sub-profile configured
under the msap-policy msap-ISP1.
Another command can also be used to show less detail in a hierarchical form.
A:BNG-1# show service active-subscribers subscriber user1 hierarchy
===============================================================================
Active Subscriber hierarchy
===============================================================================
-- user1 (sub-profile-default)
|
|-- sap:[1/2/2:1] - sla:sla-profile-2M
|
|
|
|-- 10.255.0.1 - 00:00:86:1c:79:a1 - 1 (PPPoE)
|
|
===============================================================================
A:BNG-1#

Page 1112

Advanced Configuration Guide

Managed SAPs with Routed-CO

Verify the state of the group interface is now up.


A:BNG-1# show router 2 interface
===============================================================================
Interface Table (Service: 2)
===============================================================================
Interface-Name
Adm
Opr(v4/v6) Mode
Port/SapId
IP-Address
PfxState
------------------------------------------------------------------------------group-int-1
Up
Up/-VPRN G* 1/2/2
sub-int-1
Up
Up/-VPRN S* subscriber
10.255.255.254/8
n/a
------------------------------------------------------------------------------Interfaces : 2
===============================================================================
A:BNG-1#

Verify the capture service id (VPLS), capture SAP and the msap policy used to created user1 and
the SAP sub type
A:BNG-1# show service id 2 sap 1/2/2:1 detail
===============================================================================
Service Access Points(SAP)
===============================================================================
Service Id
: 2
SAP
: 1/2/2:1
Encap
: q-tag
Description
: Managed SAP - Capture Svc 1 1/2/2:*
Admin State
: Up
Oper State
: Up
Flags
: None
Multi Svc Site
: None
Last Status Change : 11/19/2009 10:23:25
Last Mgmt Change
: 11/23/2009 09:41:21
Sub Type
: managed
Capture Service Id : 1
Capture SAP
: 1/2/2:*
MSAP Policy
: msap-ISP1
Dot1Q Ethertype
: 0x8100
QinQ Ethertype
: 0x8100
Split Horizon Group: (Not Specified)
---snip--===============================================================================
A:BNG-1#

The sub type shows managed for MSAPs, whereas regular for normal saps ( a SAP created
manually under a group-interface).

Advanced Configuration Guide

Page 1113

Configuration

MSAP with Redundant Configurations


MSAPs are High Availability (HA) enabled (there is no service impact following a CPM failover).
In addition, the MSAPs are also stored in the subscriber management persistence file (if enabled),
allowing the MSAPs to be recreated after a reboot.
MSAPs can be used in dual-homed BNG scenarios with multi-chassis LAG, multi-chassis ring and
subscriber router redundancy protocol.

MSAP QoS Notes

MSAP is always created with default QoS policies.

*A:BNG-1# show service id 2 sap 1/2/2:1 detail


---snip--------------------------------------------------------------------------------QOS
------------------------------------------------------------------------------Ingress qos-policy : 1
Egress qos-policy : 1
Shared Q plcy
: default
Multipoint shared : Disabled
I. Sched Pol
: (Not Specified)
E. Sched Pol
: (Not Specified)
---snip--------------------------------------------------------------------------------*A:BNG-1#

Page 1114

Advanced Configuration Guide

Managed SAPs with Routed-CO

QoS Egress Remarking


In order to have remarking for egress traffic for MSAP taken from SLA profile, use no qosmarking-from-sap command.
configure subscriber-mgmt
...
sla-profile "sla-profile-512K" create
ingress
qos 30 shared-queuing
exit
exit
egress
qos 30
exit
no qos-marking-from-sap
exit
exit

By default, the egress QoS marking for subscriber-host traffic is derived from the SAP-egress QoS
policy associated with the corresponding SAP rather than the SLA profile associated with the
corresponding subscriber-host. As a consequence, no egress QoS marking (for example, dot1p
marking was set to 0, DSCP/PREC field is unchanged) is performed for traffic transmitted on an
MSAP because per default, SAP-egress policy one (1) was attached to every MSAP.

Advanced Configuration Guide

Page 1115

Configuration

Queue Optimization
Shared queuing can be used to optimize queues on ingress direction.
configure subscriber-mgmt
...
sla-profile "sla-profile-512K" create
ingress
qos 30 shared-queuing
exit
exit

The SAP queues will not be instantiated when using the following option in the msap-policy.
configure subscriber-mgmt
msap-policy "msap-ISP1" create
sub-sla-mgmt
single-sub-parameters
profiled-traffic-only
exit
exit
exit

Page 1116

Advanced Configuration Guide

Managed SAPs with Routed-CO

Configuration Tips
The authentication policy used in the capture SAP must be the same as the policy used for the
managed SAP.
The managed SAP will not be created if the group-interface name returned from RADIUS points
to a different authentication policy other than the policy defined by the capture SAP.
configure service vpls 1
--snip--sap 1/2/2:* capture-sap create
--snip-authentication-policy "authentication-1"
exit
no shutdown
exit
configure service vprn 2
---snip--group-interface "group-int-1" create
authentication-policy "authentication-2"
---snip
exit
exit
no shutdown
exit

This can be seen in log 99


854 2009/11/23 11:55:29.14 UTC WARNING: PPPOE #2001 Base PPPoE session failure
"PPPoE session failure on SAP 1/2/2:* in service 1 - [00:00:86:1c:79:a1,1,user1@ISP1.com]
cannot create msap in svc 2 (itf:"group-int-1"): Svc 2 Interface "group-int-1" authentication policy different than on capture sap"
853 2009/11/23 11:55:29.14 UTC MINOR: SVCMGR #2214 Base Managed SAP creation failure
"The system could not create a Managed SAP. Capturing SAP:1/2/2:*, service:1. Description:
cannot create msap in svc 2 (itf:"group-int-1"): Svc 2 Interface "group-int-1" authentication policy different than on capture sap"

On the 7750 SR, enable debug for PPPoE and RADIUS packets to help in case there is a problem
in session establishment.
debug
service
id 1
pppoe
packet
mode egr-ingr-and-dropped
detail-level medium
discovery
ppp
exit

Advanced Configuration Guide

Page 1117

Configuration

exit
exit
id 2
pppoe
packet
mode egr-ingr-and-dropped
detail-level medium
discovery
ppp
exit
exit
exit
exit
radius detail
exit
configure log log-id 1
from debug-trace
to session
exit

Disconnect/connect user1 then check the RADIUS access request/accept and accounting messages
from the debug output
30 2009/11/23 09:41:20.37 UTC MINOR: DEBUG #2001 management RADIUS
"RADIUS: Access-Request
user user1@ISP1.com policy authentication-1"
31 2009/11/23 09:41:20.37 UTC MINOR: DEBUG #2001 management RADIUS
"RADIUS: Transmit
Access-Request(1) 172.16.1.1:1812 id 7 len 183
USER NAME [1] 14 user1@ISP1.com
NAS IP ADDRESS [4] 4 172.30.1.34
SERVICE TYPE [6] 4 Framed(2)
FRAMED PROTOCOL [7] 4 PPP(1)
CHAP PASSWORD [3] 17 1 0x5f800711a77fd6520b6fb61c40d21d62
CHAP CHALLENGE [60] 49 0x1a581b8e77d7f5b80cb363a3dff4ca5ff056d93cc942789b5cb
5ba80ec8bd207e3ee955bc68c155240f7f69fecc17f5d97
VSA [26] 7 DSL(3561)
AGENT REMOTE ID [2] 5 user1
NAS PORT TYPE [61] 4 PPPoEoVLAN(33)
NAS PORT ID [87] 7 1/2/2:1
NAS IDENTIFIER [32] 4 BNG-1
VSA [26] 19 Alcatel(6527)
CHADDR [27] 17 00:00:86:1c:79:a1
"
32 2009/11/23 09:41:20.45 UTC MINOR: DEBUG #2001 management RADIUS
"RADIUS: Receive
Access-Accept(2) id 7 len 133 from 172.16.1.1:1812
VSA [26] 7 Alcatel(6527)
SUBSC ID STR [11] 5 user1
VSA [26] 16 Alcatel(6527)
SLA PROF STR [13] 14 sla-profile-2M
VSA [26] 6 Alcatel(6527)
MSAP SERVICE ID [31] 4 2

Page 1118

Advanced Configuration Guide

Managed SAPs with Routed-CO

VSA [26] 11 Alcatel(6527)


MSAP POLICY [32] 9 msap-ISP1
VSA [26] 13 Alcatel(6527)
MSAP INTERFACE [33] 11 group-int-1
FRAMED IP ADDRESS [8] 4 10.255.0.1
VSA [26] 6 Alcatel(6527)
PRIMARY DNS [9] 4 67.138.54.100
VSA [26] 6 Alcatel(6527)
SECONDARY DNS [10] 4 207.225.209.66

The 7750 sends also accounting request message to the RADIUS accounting server
215 2009/11/23 13:19:52.52 UTC MINOR: DEBUG #2001 management RADIUS
"RADIUS: Accounting Request
policy accounting-1"
216 2009/11/23 13:19:52.52 UTC MINOR: DEBUG #2001 management RADIUS
"RADIUS: Transmit
Accounting-Request(4) 172.16.1.1:1813 id 161 len 219
STATUS TYPE [40] 4 Start(1)
NAS IP ADDRESS [4] 4 172.30.1.34
USER NAME [1] 14 user1@ISP1.com
SERVICE TYPE [6] 4 Framed(2)
FRAMED PROTOCOL [7] 4 PPP(1)
FRAMED IP ADDRESS [8] 4 10.255.0.1
NAS IDENTIFIER [32] 4 PE34
SESSION ID [44] 40 000000010241000000000001000000084B0A8BF8
EVENT TIMESTAMP [55] 4 1258982392
NAS PORT TYPE [61] 4 PPPoEoVLAN(33)
NAS PORT ID [87] 7 1/2/2:1
VSA [26] 28 DSL(3561)
AGENT CIRCUIT ID [1] 19 DSLAM1_1/1/1/1:0.35
AGENT REMOTE ID [2] 5 user1
VSA [26] 44 Alcatel(6527)
SUBSC ID STR [11] 5 user1
SUBSC PROF STR [12] 19 sub-profile-default
SLA PROF STR [13] 14 sla-profile-2M
"

After 10 mins (update interval) the 7750 sends accounting Interim updates with the same session
ID including the counter values for total input and output octets/packets for user1
223 2009/11/23 13:29:08.61 UTC MINOR: DEBUG #2001 management RADIUS
"RADIUS: Accounting Request
policy accounting-1"
224 2009/11/23 13:29:08.61 UTC MINOR: DEBUG #2001 management RADIUS
"RADIUS: Transmit
Accounting-Request(4) 172.16.1.1:1813 id 162 len 249
STATUS TYPE [40] 4 Interim-Update(3)
NAS IP ADDRESS [4] 4 172.30.1.34
USER NAME [1] 14 user1@ISP1.com
SERVICE TYPE [6] 4 Framed(2)
FRAMED PROTOCOL [7] 4 PPP(1)
FRAMED IP ADDRESS [8] 4 10.255.0.1

Advanced Configuration Guide

Page 1119

Configuration

NAS IDENTIFIER [32] 4 PE34


SESSION ID [44] 40 000000010241000000000001000000084B0A8BF8
SESSION TIME [46] 4 556
EVENT TIMESTAMP [55] 4 1258982948
NAS PORT TYPE [61] 4 PPPoEoVLAN(33)
NAS PORT ID [87] 7 1/2/2:1
VSA [26] 28 DSL(3561)
AGENT CIRCUIT ID [1] 19 DSLAM1_1/1/1/1:0.35
AGENT REMOTE ID [2] 5 user1
VSA [26] 44 Alcatel(6527)
SUBSC ID STR [11] 5 user1
SUBSC PROF STR [12] 19 sub-profile-default
SLA PROF STR [13] 14 sla-profile-2M
INPUT PACKETS [47] 4 0
INPUT OCTETS [42] 4 0
OUTPUT PACKETS [48] 4 10
OUTPUT OCTETS [43] 4 640
"

To verify the MSAP policies and associations of MSAPs created


*A:BNG-1# show subscriber-mgmt msap-policy
===============================================================================
Managed SAP Policies
===============================================================================
Name
Num
Description
MSAPs
------------------------------------------------------------------------------msap-ISP1
1
(Not Specified)
msap-default
0
(Not Specified)
------------------------------------------------------------------------------Number of MSAP Policies : 2
Number of MSAPs
: 1
===============================================================================
*A:BNG-1#
*A:BNG-1# show subscriber-mgmt msap-policy msap-ISP1 association
===============================================================================
MSAP Policy Associations
===============================================================================
Service-Id : 2 (VPRN)
- SAP : [1/2/2:1]
------------------------------------------------------------------------------Number of associated MSAPs: 1
===============================================================================
*A:BNG-1#

Page 1120

Advanced Configuration Guide

Managed SAPs with Routed-CO

To check all MSAPs created and associations to services


*A:BNG-1# show service sap-using msap
===============================================================================
Service Access Points
===============================================================================
PortId
SvcId
Ing. Ing.
Egr. Egr.
Adm Opr
QoS
Fltr
QoS
Fltr
------------------------------------------------------------------------------[1/2/2:1]
2
1
none
1
none
Up
Up
------------------------------------------------------------------------------Number of SAPs : 1
------------------------------------------------------------------------------[<sap-id>] indicates a Managed SAP
------------------------------------------------------------------------------===============================================================================
*A:BNG-1#

It is possible to use a tools command to update an exisiting MSAP when a specific msap-policy
has changed.
A:BNG-1# tools perform subscriber-mgmt eval-msap ?
- eval-msap { policy <msap-policy-name< | msap <sap-id> }
<msap-policy-name>
<sap-id>

:
:

[32 chars max]


<port-id|lag-id>:qtag1
<port-id|lag-id>:qtag1.qtag2

To delete an MSAP
A:BNG-1# clear service id 2 msap 1/2/2:1
867 2009/11/23 12:37:25.21 UTC INDETERMINATE: LOGGER #2010 Base Clear SVCMGR
"Clear function clearSvcIdMsap has been run with parameters: svc-id="2" sap-id="1/2/2:1".
The completion result is: success. Additional error text, if any, is: "

To delete all MSAPs associated with a certain MSAP policy


A:BNG-1# clear service id 2 msap-policy msap-ISP1
879 2009/11/23 12:55:28.06 UTC INDETERMINATE: LOGGER #2010 Base Clear SVCMGR
"Clear function clearSvcIdMsapPlcy has been run with parameters: svc-id="2" policyname="msap-ISP1". The completion result is: success. Additional error text, if any, is: "

Advanced Configuration Guide

Page 1121

Conclusion

Conclusion
MSAP allows dynamic creation of SAPs which results in :

Page 1122

Less provisioning

Less possibility for introducing provisioning errors

Reduced configuration file.

Advanced Configuration Guide

MPLS LDP FRR using ISIS as IGP

In This Chapter
This section describes MPLS LDP FRR using ISIS as the IGP.
Topics in this section include:

Applicability on page 1124

Summary on page 1125

Configuration on page 1126

Conclusion on page 1145

Advanced Configuration Guide

Page 1123

Applicability

Applicability
MPLS Label Distribution Protocol Fast Re-Route (LDP FRR) is supported on all 7x50 platforms
including the 7710 SR and 7710 SR c-4/12 or the 7750 SR c-4/12. This feature is supported on all
IOM/IMMs and MDA/CMA types that support network interfaces from 9.0R4 and higher. This
feature was tested on release 9.0R6. There are no pre-requisites for this configuration.

Page 1124

Advanced Configuration Guide

MPLS LDP FRR using ISIS as IGP

Summary
LDP FRR improves convergence in case of a single link or single node failure in the network.
Convergence times will be in the order of 10s of milliseconds. This is important to some
application services (like VoIP) which are sensitive to traffic loss when running over the MPLS
network.
Without using FRR, link and/or node failures inside an MPLS LDP network result in traffic loss in
the order of 100s of milliseconds. The reason for that is that LDP depends on the convergence of
the underlying IGP (IS-IS sending LSPs in this case). After IGP convergence, LDP itself needs to
compute new primary next-hop Label Forwarding Entries (NHLFEs) for all affected Forwarding
Equivalence Classes (FECs). Finally, the different Label Forwarding Information Bases (LFIBs)
are updated.
When FRR is configured on a node, the node pre-computes primary NHLFEs for all FECs and in
addition it will pre-compute backup NHLFEs for all FECs. The backup NHLFE corresponds to
the label received for the same FEC from a Loop-Free Alternate (LFA) next-hop (see also RFC
5286, Basic Specification for IP Fast Reroute: Loop-Free Alternates). Both primary NHLFEs and
backup NHLFEs are programmed in the IOM/IMM which makes it possible to converge very
quickly.

Implementation
The 7x50 software has implemented Inequality 1 (link criterion) and Inequality 3 (node criterion)
of RFC 5286. Similar to the Shortest Path Tree (SPT) computation that is part of standard linkstate routing functionality, also the LFA next-hop computation is based on the IGP metric.
The underlying LFA formulas appear in the following format:
Inequality 1:

SP(backup NHR, D) < {SP(backup NHR, S) + SP(S, D)}]

Inequality 3:

[SP(backup NHR, D) < {SP(backup NHR, PN) + SP(PN, D)}]

With SP = shortest IGP metric path, NHR = next-hop router, D = destination, S =


source node or upstream node doing the actual LFA next-hop computation and PN = protected
node. Inequality 3 rule is stricter than Inequality 1 rule. See Additional Topics on page 1139 for a
practical example on these formulas.

Advanced Configuration Guide

Page 1125

Configuration

Configuration
This section provide information to configure:

Configuring the IP/MPLS network. on page 1126

Enabling LDP FRR and verify with show commands. on page 1129

Enable a synchronization timer between IGP and LDP protocol. on page 1134

Data path verification using a Layer 2/VLL service. on page 1134

192.0.2.2/32

1/1/2
0
3
/
.2
2.0

.2

1/1/2
1/1/5
19

2.1

68

.13

1/1/1 .2

.0/

30

.2

1/1/4

PE-4

1/1/1
.2 .1 1/1/2

1/1/3 .1

1/1/5

192.168.45.0/30

.1
92

PE-1
.1

192.168.24.0/30

192.168.23.0/30

.1

1/1/4
.1

.1

68

192.0.2.1/32

PE-2

192.0.2.4/32

/30

4.0

.3
68

2.1

19

.2 1/1/2

.1
1/1/3

PE-3

.1
1/1/5

192.168.35.0/30

192.0.2.3/32

.2
1/1/1

PE-5

192.0.2.5/32
OSSG719

Figure 80: Initial Topology


Step 1. Configuring the IP/MPLS network.

The system addresses and IP interface addresses are configured according to Figure 80. An
interior gateway protocol (IGP) is needed to distribute routing information on all PEs. In our case,
the IGP is IS-IS where each PE is acting as a Level 2 router. A configuration example is shown for
PE-1. Similar configurations can be derived for the other PEs.
*A:PE-1# configure router isis
level-capability level-2
level 2
wide-metrics-only
exit
interface "system"
exit
interface "int-PE-1-PE-2"

Page 1126

Advanced Configuration Guide

MPLS LDP FRR using ISIS as IGP

interface-type point-to-point
exit
interface "int-PE-1-PE-3"
interface-type point-to-point
exit
no shutdown

IS-IS interfaces are setup as type point-to-point to improve convergence since no DR/BDR
election process is done. To verify that IS-IS adjacencies are up, show router isis adjacency is
performed. To check if IP interface addresses/subnets are known on all PEs, show router routetable or show router fib slot-number will display the content of the forwarding information base
(FIB).
A:PE-1# show router isis adjacency
===============================================================================
ISIS Adjacency
===============================================================================
System ID
Usage State Hold Interface
MT Enab
------------------------------------------------------------------------------PE-2
L2
Up
26
int-PE-1-PE-2
No
PE-3
L2
Up
28
int-PE-1-PE-3
No
------------------------------------------------------------------------------Adjacencies : 2
===============================================================================
A:PE-1#

A:PE-1# show router route-table


===============================================================================
Route Table (Router: Base)
===============================================================================
Dest Prefix[Flags]
Type
Proto
Age
Pref
Next Hop[Interface Name]
Metric
------------------------------------------------------------------------------192.0.2.1/32
Local
Local
01h07m21s
0
system
0
192.0.2.2/32
Remote ISIS
00h15m19s
18
192.168.12.2
10
192.0.2.3/32
Remote ISIS
00h12m58s
18
192.168.13.2
10
192.0.2.4/32
Remote ISIS
00h13m16s
18
192.168.12.2
20
192.0.2.5/32
Remote ISIS
00h11m21s
18
192.168.13.2
20
192.168.12.0/30
Local
Local
00h18m25s
0
int-PE-1-PE-2
0
192.168.13.0/30
Local
Local
00h18m10s
0
int-PE-1-PE-3
0
192.168.23.0/30
Remote ISIS
00h15m09s
18
192.168.12.2
20
192.168.24.0/30
Remote ISIS
00h15m04s
18
192.168.12.2
20
192.168.34.0/30
Remote ISIS
00h14m13s
18
192.168.13.2
20
192.168.35.0/30
Remote ISIS
00h14m05s
18
192.168.13.2
20
192.168.45.0/30
Remote ISIS
00h13m09s
18

Advanced Configuration Guide

Page 1127

Configuration

192.168.12.2
30
------------------------------------------------------------------------------No. of Routes: 12
Flags: L = LFA nexthop available
B = BGP backup route available
n = Number of times nexthop is repeated
===============================================================================
A:PE-1#
A:PE-1# show router fib 1
===============================================================================
FIB Display
===============================================================================
Prefix
Protocol
NextHop
------------------------------------------------------------------------------192.0.2.1/32
LOCAL
192.0.2.1 (system)
192.0.2.2/32
ISIS
192.168.12.2 (int-PE-1-PE-2)
192.0.2.3/32
ISIS
192.168.13.2 (int-PE-1-PE-3)
192.0.2.4/32
ISIS
192.168.12.2 (int-PE-1-PE-2)
192.0.2.5/32
ISIS
192.168.13.2 (int-PE-1-PE-3)
192.168.12.0/30
LOCAL
192.168.12.0 (int-PE-1-PE-2)
192.168.13.0/30
LOCAL
192.168.13.0 (int-PE-1-PE-3)
192.168.23.0/30
ISIS
192.168.12.2 (int-PE-1-PE-2)
192.168.24.0/30
ISIS
192.168.12.2 (int-PE-1-PE-2)
192.168.34.0/30
ISIS
192.168.13.2 (int-PE-1-PE-3)
192.168.35.0/30
ISIS
192.168.13.2 (int-PE-1-PE-3)
192.168.45.0/30
ISIS
192.168.12.2 (int-PE-1-PE-2)
------------------------------------------------------------------------------Total Entries : 12
------------------------------------------------------------------------------===============================================================================
A:PE-1#

Initially, the default IS-IS Level 2 metric is applied on all interfaces (value 10).
*A:PE-1# show router isis status | match "L2 Default Metric"
L2 Default Metric
: 10

The next step in the process of setting up the IP/MPLS network is setting up interface-LDP
sessions on all interfaces.
*A:PE-1# configure router ldp
interface-parameters
interface "int-PE-1-PE-2"
exit

Page 1128

Advanced Configuration Guide

MPLS LDP FRR using ISIS as IGP

interface "int-PE-1-PE-3"
exit
exit
targeted-session
exit

There is now a full mesh of LDP LSPs setup between all PEs system interfaces. As an example,
the tunnel-table on PE-1 will look like this:
*A:PE-1# show router tunnel-table
===============================================================================
Tunnel Table (Router: Base)
===============================================================================
Destination
Owner Encap TunnelId Pref
Nexthop
Metric
------------------------------------------------------------------------------192.0.2.2/32
ldp
MPLS
9
192.168.12.2
10
192.0.2.3/32
ldp
MPLS
9
192.168.13.2
10
192.0.2.4/32
ldp
MPLS
9
192.168.12.2
20
192.0.2.5/32
ldp
MPLS
9
192.168.13.2
20
===============================================================================
*A:PE-1#

Note that the LDP LSP metric follows the IGP cost. Optionally, LSP metrics can be applied but
this is out of the scope for this configuration note.
Step 2. Enabling LDP FRR and verify with show commands.

Since LDP FRR is using LFA next-hop pre-computation by the IGP (as described in RFC 5286),
the IGP CLI configuration will look like this:
*A:PE-1# configure router isis loopfree-alternate
*A:PE-1# show router isis status | match "Loopfree"
Loopfree-Alternate
: Enabled

After enabling LFA inside the IGP context, FRR needs to be enabled within the LDP context:
*A:PE-1# configure router ldp fast-reroute
*A:PE-1# show router ldp status | match "FRR"
FRR
: Enabled

After these two CLI settings, the software pre-computes for each LDP FEC in the network both a
primary and a backup NHLFE and uploads it to the IOM/IMM. The primary NHLFE corresponds
to the label of the FEC received from the primary next-hop as per standard LDP resolution of the
FEC prefix in Routing Table Manager (RTM). The backup NHLFE corresponds to the label
received for the same FEC from an LFA next-hop.
Note: For point-to-point interfaces, when multiple LFA next-hops are found for a given primary
next-hop, the following selection algorithms are used:

Advanced Configuration Guide

Page 1129

Configuration

It will pick the node-protect type in favor of the link-protect type.

If there is more than one LFA next-hop within the selected type, then it will pick one
based on the least cost.

If more than one LFA next-hop with the same cost, SPF will select the first one. This is
not a deterministic selection and will vary following each SPF calculation.

Several show commands are possible to display LFA information:

The show router isis statistics command displays the number of LFA runs on a specific
node.
*A:PE-1# show router isis statistics
LFA Statistics
LFA Runs

: 6

The show router isis lfa-coverage command performs a mathematical calculation


between the number of nodes and IPv4/IPv6 routes in the network versus present LFA
next-hop protections. In our network (see Figure 80) all IS-IS links have a default Level 2
metric of 10. This results in all four nodes and all IS-IS routes learned by PE1 being 100%
LFA protected (link or node). Refer to the following output.
*A:PE-1# show router isis lfa-coverage
===============================================================================
LFA Coverage
===============================================================================
Topology
Level
Node
IPv4
IPv6
------------------------------------------------------------------------------IPV4 Unicast
L1
0/0(0%)
9/9(100%)
0/0(0%)
IPV4 Unicast
L2
4/4(100%)
9/9(100%)
0/0(0%)
===============================================================================

The show router isis spf lfa detail command gives you a reference to LFA protection
type (link or node).
*A:PE-1# show router isis spf lfa detail
===============================================================================
Path Table
===============================================================================
Level 2
------------------------------------------------------------------------------Node
: PE-2.00
Metric
: 10
Interface : int-PE-1-PE-2
SNPA
: n/a
Nexthop
: PE-2

Page 1130

LFA intf : int-PE-1-PE-3


LFA nh
: PE-3

LFA Metric : 20
LFA type
: linkProtection

Node
: PE-3.00
Interface : int-PE-1-PE-3
Nexthop
: PE-3

Metric
SNPA

: 10
: n/a

Advanced Configuration Guide

MPLS LDP FRR using ISIS as IGP

LFA intf : int-PE-1-PE-2


LFA nh
: PE-2

LFA Metric : 20
LFA type
: linkProtection

Node
: PE-4.00
Interface : int-PE-1-PE-2
Nexthop
: PE-2

Metric
SNPA

LFA intf : int-PE-1-PE-3


LFA nh
: PE-3

LFA Metric : 20
LFA type
: nodeProtection

Node
: PE-5.00
Interface : int-PE-1-PE-3
Nexthop
: PE-3

Metric
SNPA

LFA intf : int-PE-1-PE-2


LFA nh
: PE-2

: 20
: n/a

: 20
: n/a

LFA Metric : 30
LFA type
: linkProtection

===============================================================================
*A:PE-1#

Note: On PE-1, 192.0.2.4/32 or PE-4 has a primary SPF next-hop pointing towards PE-2
(int-PE-1-PE-2) and an LFA next-hop pointing towards PE-3 (int-PE-1-PE-3). Using
Inequality 3 formula on PE-1 for prefix 192.0.2.4/32 (= PE-4), this becomes:
Inequality 3:
[SP(backup NHR, D) < {SP(backup NHR, PN) + SP(PN, D)}] or
[SP (PE-3, PE-4) < {SP (PE-3, PE-2) + SP(PE-2, PE-4)} or
[10 < {10 + 10}]
This means that Inequality 3 is met. The calculated LFA next-hop for prefix 192.0.2.4/32
on PE-1 is node-protecting PE-2, see Figure 81 for a graphical representation.

Advanced Configuration Guide

Page 1131

Configuration

SPF, metric 10

192.0.2.2/32

1/1/5
.1

L2
-m
2.1 etri
c
68
.13 10
.0/
30

19

1/1/1 .2
.2
1/1/4

.2
1/1/1

.2 .1 1/1/2

0
c1

i
etr
, m 10
A
LF tric
30
e
.0/
-m
34
L2 68.
2.1
19

LFA, metric 10

1/1/2

1/1/5

L2-metric 10
192.168.24.0/30

L2-metric 10

.1

1/1/4
.1

10
.2
ic
etr .0/30
m
1/1/3 .1
L2 68.12
2.1
19

L2-metric 10

192.0.2.1/32

PN

192.168.23.0/30

1/1/2

LFA, metric 10

,
PF

10

192.168.45.0/30

ic

tr
me

192.0.2.4/32

LFA, metric 10

.2 1/1/2

.1
1/1/3

Backup
NHR
192.0.2.3/32

.1
1/1/5

L2-metric 10
192.168.35.0/30

.2
1/1/1

PE-5

192.0.2.5/32
OSSG720

Figure 81: LFA Computation, Inequality 3 for Prefix PE-4 (D) on PE1 (S)

The show router route-table command adds an L flag as reference that the associated
prefix is having also an LFA next-hop available. For detailed interface address
information used by the LFA calculation use the show router route-table alternative or
show router isis alternative command. The output on PE-1 for PE-4 will look like this:
*A:PE-1# show router route-table 192.0.2.4
===============================================================================
Route Table (Router: Base)
===============================================================================
Dest Prefix[Flags]
Type
Proto
Age
Pref
Next Hop[Interface Name]
Metric
------------------------------------------------------------------------------192.0.2.4/32 [L]
Remote ISIS
02h22m24s
18
192.168.12.2
20
------------------------------------------------------------------------------No. of Routes: 1
Flags: L = LFA nexthop available
B = BGP backup route available
n = Number of times nexthop is repeated
===============================================================================
*A:PE-1#

*A:PE-1# show router route-table alternative 192.0.2.4


===============================================================================
Route Table (Router: Base)
===============================================================================
Dest Prefix[Flags]
Type
Proto
Age
Pref
Next Hop[Interface Name]
Metric
Alt-NextHop
Alt-Metric
------------------------------------------------------------------------------192.0.2.4/32
Remote ISIS
02h22m03s
18

Page 1132

Advanced Configuration Guide

MPLS LDP FRR using ISIS as IGP

192.168.12.2
20
192.168.13.2 (LFA)
20
------------------------------------------------------------------------------No. of Routes: 1
Flags: Backup = BGP backup route LFA = Loop-Free Alternate nexthop
n = Number of times nexthop is repeated
===============================================================================
*A:PE-1#

*A:PE-1# show router isis routes 192.0.2.4 alternative


===============================================================================
Route Table
===============================================================================
Prefix[Flags]
Metric
Lvl/Typ
Ver.
SysID/Hostname
NextHop
MT
AdminTag
Alt-Nexthop
Alt-Metric Alt-Type
------------------------------------------------------------------------------192.0.2.4/32
20
2/Int.
37
PE-2
192.168.12.2
0
0
192.168.13.2 (LFA)
20
nodeProtection
------------------------------------------------------------------------------No. of Routes: 1
Flags: LFA = Loop-Free Alternate nexthop
===============================================================================
*A:PE-1#

The show router ldp bindings command displays the Label Information Base (LIB). A
BU flag is present in case the associated label is used as backup NHLFE for the given
prefix 1. As an example, a display on PE-1 for prefix PE-4 will look like this:
*A:PE-1# show router ldp bindings prefix 192.0.2.4/32
===============================================================================
LDP LSR ID: 192.0.2.1
===============================================================================
Legend: U - Label In Use, N - Label Not In Use, W - Label Withdrawn
WP - Label Withdraw Pending, BU - Alternate Next-hop for Fast Re-Route
===============================================================================
LDP Prefix Bindings
===============================================================================
Prefix
IngLbl
EgrLbl
EgrIntf
EgrNextHop
Peer
------------------------------------------------------------------------------192.0.2.4/32
131068N
131068
1/1/2
192.168.12.2
192.0.2.2
192.0.2.4/32
131068U
131068BU
1/1/5
192.168.13.2
192.0.2.3
------------------------------------------------------------------------------No. of Prefix Bindings: 2
===============================================================================

1. This is only possible because 7x50 LDP implementation is using liberal retention mode which
means that every label mapping received by a peer is retained regardless of whether the LSR is the
next-hop for the advertised mapping.

Advanced Configuration Guide

Page 1133

Configuration

The show router ldp bindings active command displays the Label Forwarding
Information Base (LFIB). Also the BU flag is present and in addition a reference to the
label action itself: pop for eLER, push for iLER and swap for LSR.
*A:PE-1# show router ldp bindings prefix 192.0.2.4/32 active
===============================================================================
Legend: (S) - Static
(M) - Multi-homed Secondary Support
(B) - BGP Next Hop (BU) - Alternate Next-hop for Fast Re-Route
===============================================================================
LDP Prefix Bindings (Active)
===============================================================================
Prefix
Op
IngLbl
EgrLbl
EgrIntf/LspId EgrNextHop
------------------------------------------------------------------------------192.0.2.4/32
Push
-131068
1/1/2
192.168.12.2
192.0.2.4/32
Swap 131068
131068
1/1/2
192.168.12.2
192.0.2.4/32
Push
-131068BU 1/1/5
192.168.13.2
192.0.2.4/32
Swap 131068
131068BU 1/1/5
192.168.13.2
------------------------------------------------------------------------------No. of Prefix Active Bindings: 4

Step 3. Enable a synchronization timer between IGP and LDP protocol.

Within an MPLS network using LDP it is common practise to enable a synchronization timer
between LDP and the IGP. Also when LDP FRR is enabled, a situation can occur in which a
synchronization timer between IGP and LDP will help: the revert scenario. When the interface for
the previous primary next-hop is restored, IGP may re-converge before LDP completed the FEC
exchange with its neighbor over that interface. This may cause LDP to de-program the LFA nexthop from the FEC and blackhole traffic.
In order to avoid these situations, it is recommended to first enable IGP-LDP synchronization on
the LDP interface. The time is expressed in seconds and can have a value between 1 and 1800
seconds. Translated into configuration commands, this becomes:
*A:PE-1# configure router interface "int-PE-1-PE-2" ldp-sync-timer 10
*A:PE-1# configure router interface "int-PE-1-PE-3" ldp-sync-timer 10

When this timer is enabled, it means that when an interface is restored again, the IGP will
advertise this link in the network with an infinite metric. The ldp-sync-timer is started, LDP
adjacencies are brought up together with a label exchange. After the ldp-sync-timer expires, the
normal metric is advertised in the network again.
Step 4. Data path verification using a Layer 2/VLL service.

Traffic generator ports are connected towards PE-1 and PE-5 for data verification. On top of this,
the IS-IS Level 2 metric value on interface PE-4<=>PE-5 is decreased to the value 5, (see
Figure 82). On PE-1 and PE-5, MPLS LDP based SDPs are created.
*A:PE-1# configure service sdp 5
far-end 192.0.2.5
ldp

Page 1134

Advanced Configuration Guide

MPLS LDP FRR using ISIS as IGP

keep-alive
shutdown
exit
no shutdown
*A:PE-1# configure service epipe 1
service-mtu 1450
sap 1/1/3:1 create
exit
spoke-sdp 5:1 create
no shutdown
exit
no shutdown

192.0.2.2/32

1/1/5
L2
-m
2.1 etri
c
68
.13 10
.0/
30
131064
19

131070

L2-metric 10

1/1/2

.1

L2-metric 10
192.168.24.0/30

1/1/1 .2

1/1/4

PE-3

192.0.2.3/32

.2

PE-4

.2 .1 1/1/2

10 0
tric .0/3
e
-m
34
L2 68.
.1
2
19

.1
1/1/5

Epipe 1
L2-metric 10
192.168.35.0/30

131071
131070

.2 1/1/2

.1
1/1/3

.2

1/1/5

1/1/1

192.168.23.0/30

LFA, metric 10

.1

PE-1

1/1/4
.1

10
.2
ic
etr .0/30
m
1/1/3 .1
L2 68.12
2.1
19

192.0.2.1/32
sap 1/1/3:1

PE-2

L2-metric 10

1/1/2

192.168.45.0/30

131063
131070

192.0.2.4/32

131067
131070

sap 1/1/3:1
.2
1/1/1

131071
131070

PE-5

192.0.2.5/32
OSSG721

Figure 82: Data Verification, Direction PE-1 => PE-5 Using VLL Service

In this setup, PE-3 is node-protected for PE-5 prefix on PE-1:


*A:PE-1# show router isis spf lfa detail
===============================================================================
Path Table
===============================================================================
Level 2
------------------------------------------------------------------------------?
Node
: PE-5.00
Metric
: 20
Interface : int-PE-1-PE-3
SNPA
: n/a
Nexthop
: PE-3
LFA intf : int-PE-1-PE-2
LFA nh
: PE-2

LFA Metric : 25
LFA type
: nodeProtection

===============================================================================
*A:PE-1#

Advanced Configuration Guide

Page 1135

Configuration

*A:PE-1# show router isis routes alternative 192.0.2.5


===============================================================================
Route Table
===============================================================================
Prefix[Flags]
Metric
Lvl/Typ
Ver.
SysID/Hostname
NextHop
MT
AdminTag
Alt-Nexthop
Alt-Metric Alt-Type
------------------------------------------------------------------------------192.0.2.5/32
20
2/Int.
29
PE-3
192.168.13.2
0
0
192.168.12.2 (LFA)
25
nodeProtection
------------------------------------------------------------------------------No. of Routes: 1
Flags: LFA = Loop-Free Alternate nexthop
===============================================================================
*A:PE-1#

In normal conditions, MPLS traffic from PE-1 towards PE-5 over epipe 1 will have two MPLS
labels: 1) outer (transport) label given by LDP protocol, swapped on each intermediate LSR and 2)
inner (service) label given by T-LDP, the same end-to-end. Refer to the following show
commands.
T-LDP service label: 131070
*A:PE-1# show router ldp bindings service-id 1
===============================================================================
LDP Service FEC 128 Bindings
===============================================================================
Type
VCId
SvcId
SDPId
Peer
IngLbl EgrLbl LMTU RMTU
------------------------------------------------------------------------------E-Eth 1
1
5
192.0.2.5
131070U 131070S 1436 1436
------------------------------------------------------------------------------No. of VC Labels: 1
===============================================================================
*A:PE-1#

Transport LDP label between PE-1 and PE-3 for prefix 192.0.2.5/32: 131064.
*A:PE-1# show router ldp bindings active prefix 192.0.2.5/32
===============================================================================
Legend: (S) - Static
(M) - Multi-homed Secondary Support
(B) - BGP Next Hop (BU) - Alternate Next-hop for Fast Re-Route
===============================================================================
LDP Prefix Bindings (Active)
===============================================================================
Prefix
Op
IngLbl
EgrLbl
EgrIntf/LspId EgrNextHop
-------------------------------------------------------------------------------

Page 1136

192.0.2.5/32

Push

--

131063BU

1/1/2

192.168.12.2

192.0.2.5/32
...

Push

--

131064

1/1/5

192.168.13.2

Advanced Configuration Guide

MPLS LDP FRR using ISIS as IGP

Transport LDP label between PE-3 and PE-5 for prefix 192.0.2.5/32: 131071
*A:PE-3# show router ldp bindings active prefix 192.0.2.5/32
===============================================================================
Legend: (S) - Static
(M) - Multi-homed Secondary Support
(B) - BGP Next Hop (BU) - Alternate Next-hop for Fast Re-Route
===============================================================================
LDP Prefix Bindings (Active)
===============================================================================
Prefix
Op
IngLbl
EgrLbl
EgrIntf/LspId EgrNextHop
------------------------------------------------------------------------------192.0.2.5/32
...

Swap 131064

131071

1/1/5

192.168.35.2

When PE-3 reboots, PE-1 performs an immediate swap to LFA next-hop for prefix 192.0.2.5/32
bypassing PE-3. The service label remains the same, only the transport labels can change on the
network ports PE-1 <=> PE-2, PE-2 <=> PE-4 and PE-4 <=> PE-52. Refer to the following show
commands.
T-LDP service label: 131070
*A:PE-1# show router ldp bindings service-id 1
===============================================================================
LDP Service FEC 128 Bindings
===============================================================================
Type
VCId
SvcId
SDPId
Peer
IngLbl EgrLbl LMTU RMTU
------------------------------------------------------------------------------E-Eth 1
1
5
192.0.2.5
131070U 131070S 1436 1436
------------------------------------------------------------------------------No. of VC Labels: 1
===============================================================================
*A:PE-1#

Transport LDP label between PE-1 and PE-2 for prefix 192.0.2.5/32. The same label (previously
tagged as BU) as before node failure: 131063
*A:PE-1# show router ldp bindings active prefix 192.0.2.5/32
===============================================================================
Legend: (S) - Static
(M) - Multi-homed Secondary Support
(B) - BGP Next Hop (BU) - Alternate Next-hop for Fast Re-Route
===============================================================================
LDP Prefix Bindings (Active)
===============================================================================
Prefix
Op
IngLbl
EgrLbl
EgrIntf/LspId EgrNextHop
------------------------------------------------------------------------------192.0.2.5/32
Push
-131063
1/1/2
192.168.12.2

2. LDP FRR MPLS label stack will never contain more than two labels. This is different when compared to RSVP-TE FRR facility mode which uses a three-label MPLS stack.

Advanced Configuration Guide

Page 1137

Configuration

Transport LDP label between PE-2 and PE-4 for prefix 192.0.2.5/32: 131067
*A:PE-2# show router ldp bindings active prefix 192.0.2.5/32
===============================================================================
Legend: (S) - Static
(M) - Multi-homed Secondary Support
(B) - BGP Next Hop (BU) - Alternate Next-hop for Fast Re-Route
===============================================================================
LDP Prefix Bindings (Active)
===============================================================================
Prefix
Op
IngLbl
EgrLbl
EgrIntf/LspId EgrNextHop
------------------------------------------------------------------------------192.0.2.5/32
Swap 131063
131067
1/1/4
192.168.24.2

Transport LDP label between PE-4 and PE-5 for prefix 192.0.2.5/32: 131071
*A:PE-4# show router ldp bindings active prefix 192.0.2.5/32
===============================================================================
Legend: (S) - Static
(M) - Multi-homed Secondary Support
(B) - BGP Next Hop (BU) - Alternate Next-hop for Fast Re-Route
===============================================================================
LDP Prefix Bindings (Active)
===============================================================================
Prefix
Op
IngLbl
EgrLbl
EgrIntf/LspId EgrNextHop
------------------------------------------------------------------------------192.0.2.5/32

Page 1138

Swap 131067

131071

1/1/2

192.168.45.2

Advanced Configuration Guide

MPLS LDP FRR using ISIS as IGP

Additional Topics
Metric Change
Suppose that the IS-IS Level 2 metric between PE-2 and PE-3 changes to 30, no 100% LFA
coverage is no longer possible. Translated into configuration commands, this becomes:
*A:PE-3# configure router isis interface "int-PE-3-PE-2" level 2 metric 30
*A:PE-2# configure router isis interface "int-PE-2-PE-3" level 2 metric 30

On PE-1, Inequality 3 formula will find LFA next-hop coverages for prefix PE-4 and PE-5.
Inequality formula 1 will find LFA next-hop coverages for prefix PE-4, PE-5 and the subnet
between PE-4 and PE-5.
*A:PE-3# configure router isis interface "int-PE-3-PE-2" level 2 metric 30
*A:PE-2# configure router isis interface "int-PE-2-PE-3" level 2 metric 30

Both inequality formulas are visualized in Figure 83 and Figure 84 for prefix 192.0.2.5/32 (= PE5) on PE-1 acting as the source node for LFA next-hop computation.

Advanced Configuration Guide

Page 1139

Configuration

192.0.2.2/32

.1

1/1/5

L2-metric 10
192.168.24.0/30

10 0
tric .0/3
e
-m
34
L2 68.
2.1
9
1

.2 1/1/2

.1
1/1/3
.1
1/1/5

LFA, metric 10

L2
-m
2.1 etri
1/1/1 .2
c
68
LF
.13 10
A,
.2
.
0
SP
me
/30
F,
t
me ric 1
0
tric
1/1/4
PN
10
19

L2-metric 10

1/1/5
.1

.2 .1 1/1/2
192.168.45.0/30

1/1/2

PE-4

.2
1/1/1

192.168.23.0/30

LFA, metric 30

.1

L2-metric 30

10
.2
ic
etr .0/30
m
1/1/3 .1
L2 68.12
2.1
19

192.0.2.1/32

1/1/4

Backup
NHR

1/1/2

192.0.2.4/32

LFA, metric 10

L2-metric 10
192.168.35.0/30

.2
1/1/1

LFA, metric 10
SPF, metric 10

192.0.2.3/32

192.0.2.5/32
OSSG722

Figure 83: LFA Computation, Inequality 3 for Prefix PE-5 (D) on PE-1 (S)

192.0.2.2/32

Backup
NHR

1/1/4
.1

1/1/5

L2-metric 10
192.168.24.0/30

A
LF

.1
1/1/2

S
1/1/5
.1

L2
-m
2.1 etri
1/1/1 .2
c
68
LF
.13 10
A,
.2
.
0/3
SP
me
0
F,
t
me ric 1
0
tric
1/1/4 PE-3
10
19

PE-4

1/1/1
.2 .1 1/1/2

192.168.23.0/30

192.0.2.1/32

L2-metric 30

10
.2
ic
etr .0/30
m
1/1/3 .1
L2 68.12
2.1
19

.2

10 0
tric 0/3
me .34.
L2 68
2.1
19

.2 1/1/2

.1
1/1/3
.1
1/1/5

L2-metric 10
192.168.35.0/30

LFA, metric 10

1/1/2

L2-metric 10

10

192.168.45.0/30

tric

e
,m

192.0.2.4/32

LFA, metric 10

.2
1/1/1

LFA, metric 10
SPF, metric 10

192.0.2.3/32

192.0.2.5/32
OSSG723

Figure 84: LFA Computation, Inequality 1 for Prefix PE-5 (D) on PE-1 (S)

Page 1140

Advanced Configuration Guide

MPLS LDP FRR using ISIS as IGP

Inequality 3 formula: [SP(backup NHR, D) < {SP(backup NHR, PN) + SP(PN, D)}]
For a node LFA next-hop calculation of prefix 192.0.2.5/32 (D) on PE-1, the above formula
translated into text becomes:
[shortest path from backup next-hop router (PE-2) towards destination (PE-5) must be smaller
than {shortest path from backup next-hop router (PE-2) towards protected node (PE-3) + shortest
path from protected node (PE-3) to destination (PE-5)}].
The shortest path from backup next-hop router (PE-2) towards destination (PE-5) is going over
PE-4, using IS-IS Level 2 metric 10 for interface PE-2 <=> PE-4 and IS-IS Level 2 metric 10 for
interface PE-4 <=> PE-5. The shortest path from backup next-hop router (PE-2) towards protected
node (PE-3) uses IS-IS Level 2 metric 30 for interface PE-2 <=> PE-3. The shortest path from
protected node (PE-3) to destination (PE-5) uses IS-IS Level 2 metric 10 for interface PE-3 <=>
PE-5. A concise example is displayed below.
Prefix 192.0.2.5/32 : SP (PE-2, PE-5)<SP (PE-2, PE-3) + SP (PE-3, PE-5)
10 + 10 <
30 + 10 => OK

Inequality 1 formula: [SP(backup NHR, D) < {SP(backup NHR, S) + SP(S, D)}]


For a link LFA next-hop calculation of prefix 192.0.2.5/32 (D) on PE-1, the formula translated
displayed above into text becomes:
[shortest path from backup next-hop router (PE-2) towards destination (PE-5) must be smaller
than {shortest path from backup next-hop router (PE-2) towards source (PE-1) + shortest path
from source (PE-1) to destination (PE-5)}].
The shortest path from backup next-hop router (PE-2) towards destination (PE-5) is going over
PE-4, using IS-IS Level 2 metric 10 for interface PE-2 <=> PE-4 and IS-IS Level 2 metric 10 for
interface PE-4 <=> PE-5. The shortest path from backup next-hop router (PE-2) towards source
(PE-1) uses IS-IS Level 2 metric 10 for interface PE-2 <=> PE-1. The shortest path from source
(PE-1) to destination (PE-5) follows the normal SPF calculation, going over PE-3, using IS-IS
Level 2 metric 10 for interface PE-1 <=> PE-3 and IS-IS Level 2 metric 10 for interface PE-3 <=>
PE-5. Written more concisely:
Prefix 192.0.2.5/32 : SP (PE-2, PE-5)<SP (PE-2, PE-1) + SP (PE-1, PE-5)
10 + 10 <
10 + (10 + 10)=> OK

For completion, all the other Inequality 1 calculations on PE-1 are given:
Prefix 192.0.2.2/32: SP (PE-3, PE-2) <SP (PE-3, PE-1) + SP (PE-1, PE-2)
30
<
10 + 10
=> NOK
Prefix 192.0.2.3/32: SP (PE-2, PE-3)<SP (PE-2, PE-1) + SP (PE-1, PE-3)
30
<
10 + 10
=> NOK
Prefix 192.0.2.4/32 : SP (PE-3, PE-4)<SP (PE-3, PE-1) + SP (PE-1, PE-2)
10
<
10 + 10
=> OK
Prefix 192.168.23.0/30 : SP (PE-3, D)<SP (PE-3, PE-1) + SP (PE-1, D)
30
<
10 + 10
=> NOK
Prefix 192.168.24.0/30 : SP (PE-3, D)<SP (PE-3, PE-1) + SP (PE-1, D)

Advanced Configuration Guide

Page 1141

Configuration

30 + 10<
Prefix 192.168.34.0/30 : SP
30 + 10<
Prefix 192.168.35.0/30 : SP
30 + 10<
Prefix 192.168.45.0/30 : SP
10 + 10<

10 + (10 + 10)=> NOK


(PE-2, D)<SP (PE-2, PE-1) + SP (PE-1, D)
10 + (10 + 10)=> NOK
(PE-2, D)<SP (PE-2, PE-1) + SP (PE-1, D)
10 + (10 + 10)=> NOK
(PE-3, D)<SP (PE-3, PE-1) + SP (PE-1, D)
10 + (10 + 10 + 10)=> OK

As shown, only three are valid. On the 7x50, a summary command exists for LFA coverage on the
router:
*A:PE-1# show router isis lfa-coverage
===============================================================================
LFA Coverage
===============================================================================
Topology
Level
Node
IPv4
IPv6
------------------------------------------------------------------------------IPV4 Unicast
L1
0/0(0%)
3/9(33%)
0/0(0%)
IPV4 Unicast
L2
2/4(50%)
3/9(33%)
0/0(0%)
===============================================================================
*A:PE-1#

Page 1142

Advanced Configuration Guide

MPLS LDP FRR using ISIS as IGP

IS-IS Overload Bit


As stated in RFC 3137, OSPF Stub Router Advertisement, sometimes it is desirable not to have a
router used as a transit node. For those cases, it is also desirable not to have that router used as
transit node during the LFA next-hop computation. Within IS-IS protocol this is achieved by
setting the overload bit. When other routers detect that this bit is set, they will only use this router
for packets destined to the overloaded router's directly connected networks and IP prefixes.
As an example, setting of the IS-IS overload condition for a specific time on PE-2 provides
following result on PE-1:
*A:PE-2# configure router isis
##
##
##

overload timeout 60
possible value 60 ..1800
or
infinity without a timeout value

*A:PE-1# show router isis lfa-coverage


===============================================================================
LFA Coverage
===============================================================================
Topology
Level
Node
IPv4
IPv6
------------------------------------------------------------------------------IPV4 Unicast
L1
0/0(0%)
3/9(33%)
0/0(0%)
IPV4 Unicast
L2
1/4(25%)
3/9(33%)
0/0(0%)
===============================================================================
*A:PE-2#

*A:PE-1>config>router>isis# show router route-table alternative


===============================================================================
Route Table (Router: Base)
===============================================================================
Dest Prefix[Flags]
Type
Proto
Age
Pref
Next Hop[Interface Name]
Metric
Alt-NextHop
Alt-Metric
------------------------------------------------------------------------------192.0.2.2/32
192.168.12.2
192.168.13.2 (LFA)

Remote

ISIS

00h04m19s
10
20

18

192.168.23.0/30
192.168.12.2
192.168.13.2 (LFA)
192.168.24.0/30
192.168.12.2
192.168.13.2 (LFA)

Remote

ISIS

18

Remote

ISIS

00h04m19s
20
30
00h04m19s
20
30

18

------------------------------------------------------------------------------No. of Routes: 12
Flags: Backup = BGP backup route LFA = Loop-Free Alternate nexthop
n = Number of times nexthop is repeated
===============================================================================
*A:PE-1>config>router>isis#

Advanced Configuration Guide

Page 1143

Configuration

*A:PE-1# show router isis routes alternative


===============================================================================
Route Table
===============================================================================
Prefix[Flags]
Metric
Lvl/Typ
Ver.
SysID/Hostname
NextHop
MT
AdminTag
Alt-Nexthop
Alt-Metric Alt-Type
------------------------------------------------------------------------------192.0.2.2/32
10
2/Int.
43
PE-2
192.168.12.2
0
0
192.168.13.2 (LFA)
20
linkProtection
192.168.23.0/30
20
2/Int.
43
PE-2
192.168.12.2
0
0
192.168.13.2 (LFA)
30
linkProtection
192.168.24.0/30
20
2/Int.
43
PE-2
192.168.12.2
0
0
192.168.13.2 (LFA)
30
linkProtection
------------------------------------------------------------------------------No. of Routes: 12
Flags: LFA = Loop-Free Alternate nexthop
===============================================================================
*A:PE-1#

On PE-1, only three Inequality 1 calculations are possible. Refer to the previous show commands.
SPF, metric 10

192.0.2.2/32

.1

L2
-m
2.1 etri
1/1/1 .2
c
68
LF
.13 10
A,
.2
.0/
me
30
tric
10
1/1/4 Backup
19

NHR
192.0.2.3/32

.2

PE-4

1/1/1
.2 .1 1/1/2
L2-metric 10

1/1/5

1/1/5

L2-metric 10
192.168.24.0/30

.2
ic
/30
etr
-m .12.0
2
1/1/3 .1
L
68
2.1
19

1/1/2

1/1/4
.1

10

L2-metric 10

.1

PE-2

192.168.23.0/30

192.0.2.1/32

1/1/2

LFA, metric 10

F,
SP

10

10 0
ic
3
etr 4.0/
m
3
L2 68.
2.1
19

192.168.45.0/30

ic

tr
me

192.0.2.4/32

LFA, metric 10

.2 1/1/2

.1
1/1/3
.1
1/1/5

L2-metric 10
192.168.35.0/30

.2
1/1/1

PE-5

192.0.2.5/32
OSSG724

Figure 85: IS-IS Overload on PE-2, Inequality 1 for 192.168.24.0/30 (D) on PE-1 (S)

[SP(backup NHR, D) < {SP(backup NHR, S) + SP(S, D)}]


SP (PE-3, D)< SP (PE-3, PE-1) + SP (PE-1, D)
10 + 10 <
10 + (10 + 10)=> OK

Page 1144

Advanced Configuration Guide

MPLS LDP FRR using ISIS as IGP

Conclusion
In production MPLS networks where FRR needs to be deployed, a trade off must be made
between RSVP-TE FRR versus LDP FRR. The two main advantages of using LDP FRR
compared to RSVP FRR are simple configuration and LFA next-hop calculation is a local
decision, which means no interoperability issues when working in a multi-vendor environment.
The main disadvantage of using LDP FRR is that LFA next-hop calculation has to deal with
source-route paradigm (inequality formulas exclude a path going over the original source router).

Advanced Configuration Guide

Page 1145

Conclusion

Page 1146

Advanced Configuration Guide

Multicast in a VPN I

In This Chapter
This section provides information about multicast in a VPRN service.
Topics in this section include:

Applicability on page 1148

Summary on page 1149

Overview on page 1152

Configuration on page 1155

Conclusion on page 1203

Advanced Configuration Guide

Page 1147

Applicability

Applicability
This section is applicable to all of the 7750 and 7710 SR series and was tested on release 7.0R5.
There are no pre-requisites for this configuration. This is supported on 7450 ESS-7 or ESS-12 in
mixed-mode since 8.0R1. The 7750 SR-c4 is supported from 8.0R4 and higher.

Page 1148

Advanced Configuration Guide

Multicast in a VPN I

Summary
Multicast VPN (MVPN) architectures describe a set of VRFs that support the transport of
multicast traffic across a provider network.
Draft-rosen-vpn-mcast-08.txt (herein referred to as Draft-Rosen) describes the use of multicast
distribution trees (MDT) established between PEs within a given VRF. Each VRF required its own
tree. Customer edge routers form Protocol Independent Multicast (PIM) adjacencies with the PE,
and PE-PE PIM adjacencies are formed across the multicast tree. PIM signaling and data streams
are transported across the MDT. There are a number of limitations with the Draft-Rosen
implementation including, but not limited to:

Draft Rosen requires a set of MDTs per VPN, which requires a PIM state per MDT. There
is no option to aggregate MDT across multiple VPNs

Customer signaling, PE discovery and Data MDT signaling are all PIM-based. There is no
mechanism available to decouple these. Thus there is an incongruency between Unicast
and multicast VPNs using Draft-Rosen
There is no mechanism for using MPLS to encapsulate multicast traffic in the VPN.
GRE is the only encapsulation method available in Draft-Rosen.
Draft-Rosen multicast trees are signalled using PIM only. MVPN allows the use of
mLDP, RSVP P2MP LSPs.
PE to PE protocol exchanges for Draft-Rosen is achieved using PIM only. MVPN
allows for the use of BGP signaling as per unicast Layer 3 VPNs.

Next Generation MVPN addresses these limitations by extending the idea of the per-VRF tree, by
introducing the idea of Provider Multicast Service Interfaces (PMSI). These are equivalent to the
default MDTs of Draft-Rosen in that they support control plane traffic (customer multicast
signaling), and the data MDTs which carry multicast data traffic streams between PEs within a
multicast VRF.
Next Generation MVPN allows the decoupling of the mechanism required to create a multicast
VPN, such as PE auto-discovery (which PEs are members of which VPN), PMSI signaling
(creation of tunnels between PEs) and customer multicast signaling (multicast signaling IGMP/
PIM received from customer edge routers). Two types of PMSI exist:

Inclusive (I-PMSI): contains all the PEs for a given MVPN.

Selective (S-PMSI): contains only a subset of PEs of a given MVPN.

Knowledge of MPLS-VPN RFC 4364, BGP/MPLS IP Virtual Private Networks (VPNs),


architecture and functionality, as well as an understanding of multicast protocols, is assumed
throughout.

Advanced Configuration Guide

Page 1149

Summary

This chapter provides configuration details required to implement the parts of Next Generation
MVPN shown in Table 21.

Table 21: Next Generation MVPN Components


Provider Multicast Domain
I-PMSI

Autodiscovery

C-MCAST

S-PMSI Creation

PIM
ASM

PIM

PIM join/leave

PIM SSM with S-PMSI


join TLV

PIM
ASM

BGP A/D

PIM join/leave

PIM SSM with S-PMSI


join TLV

Customer Multicast Domain


PE-based RP
X

Anycast RP
on PE
X

PIM SSM
X
X

The first section of this chapter describes the common configuration required for each PE within
the provider multicast domain regardless of the MVPN PE auto-discovery or customer signaling
methods. This includes IGP and VPRN service configuration.
Following the common configuration, specific MVPN configuration required for the
configuration for the provider multicast domain using PIM Any Source Multicast (ASM) with
auto-discovery based on PIM or BGP auto-discovery (A/D), PIM used for the customer multicast
signaling and PIM Source Specific Multicast (SSM) used for the S-PMSI creation are described.
The customer domain configuration covers the following three cases:
1. PIM ASM with the Rendezvous Point (RP) in the provider PE
2. PIM ASM using anycast RP on the provider RPs
3. PIM SSM
Other possible options, not covered in this section but are discussed in the 7750 SR/7710 SR/7450
ESS OS Routing Protocols Guide:

The use of PIM SSM for the provider multicast I-PMSI.

The use of BGP for the customer multicast signaling in the provider multicast domain.

The provider S-PMSI creation through BGP S-PMSI A/D.

The use of the customer RP based in the customer CE.

The use of mLDP and RSVP p2mp LSPs for the I/S-PMSI was not available in release 7.0.
The Multicast in a VPRN II example in Multicast in a VPN II on page 1205 introduces features
that were not supported in Release 7.0R5. It provides configuration details to implement:

Page 1150

Advanced Configuration Guide

Multicast in a VPN I

Multicast LDP (mLDP) and RSVP-TE Point to Multi-point (P2MP) for building customer
trees (C-trees) which are using MPLS instead of PIM techniques.

MVPN source redundancy

MDT AFI/SAFI (to fully interoperate with Cisco networks).

IETF

References
BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs, draft-ietfl3vpn-2547bis-mcast-bgp-05.txt
Multicast in MPLS/BGP IP VPNs, draft-ietf-l3vpn-2547bis-mcast-07.txt

7750 SR/7710 SR/7450 ESS OS Services Guide

Advanced Configuration Guide

Page 1151

Overview

Overview

Multicast Sources

Multicast
Receiver A

ASM 225.0.0.1
SSM 232.0.0.1
PE-1

PE-2

.254 vprn1

192.0.2.1 192.0.2.2 vprn1

AS 64497

.2
192.168.1.0/24 CE-1 172.16.255.252/30
.1

.253

AS 64498
.2
172.16.254.252/30 CE-2 192.168.2.0/24
.254

.253

.1

AS 64496

192.168.3.0/24 CE-3 172.16.253.252/30


.1
.2

Multicast
Receiver B

.253

.254

vprn1

192.0.2.3 192.0.2.4

PE-3

vprn1

172.16.252.252/30 CE-4 192.168.4.0/24


.254

.253

.1

PE-4

Multicast
Receiver C

AS 64499

.2

AS 64500

OSSG461

Figure 86: Network Topology

The network topology is displayed in Figure 86. The setup consists of four SR 7750s acting as
Provider Edge (PE) routers within a single Autonomous System (AS).
Full mesh ISIS or OSPF in each AS
LDP on all interfaces in each AS (RSVP could also be used)
MP-iBGP sessions between the PE routers in each AS (Route Reflectors (RRs) could
also be used).
Layer 3-VPN on all PEs with identical route targets, in the form AS-no: vprn-serviceid
Connected to each PE is a single 7750 acting as a Customer Edge (CE) router. CE-1 has a
multicast sources connected, and PEs 2 to 4 each have a single receiver connected which will
receive the multicast streams from the source. In this document, each receiver is both IGMPv2 and
IGMPv3 capable. If the customer domain multicast signaling plane uses Source Specific

Page 1152

Advanced Configuration Guide

Multicast in a VPN I

Multicasting (SSM), then an IGMPv3 receiver is configured; if Any Source Multicasting (ASM)
is used, the receiver is IGMPv2 capable.
If the receiver is IGMPv3 capable, it will issue IGMPv3 reports that will include a list of required
source addresses. The receiver will join the 232.0.0.1 multicast group.
If the receiver is only IGMPv2 capable, then it will issue IGMPv2 reports which do not specify a
source of the group. In this case a Rendezvous Point is required within the PIM control plane of
the multicast VRF which is source-aware. In this case, the receiver will join the 225.0.0.1
multicast group.
When the receiver wishes to become a member of any group, the source address of the group must
be known to the CE. As a result the source address must be IP reachable by each CE, so it is
advertised by CE-1 to the PEs with attachment circuits in VPRN1 using BGP.
Static routes are then configured on the receiver CEs to achieve IP reachability to the source
address of multicast groups. In the case of PIM ASM, any RP that is configured must also be
reachable from the CE.

Advanced Configuration Guide

Page 1153

Overview

Multicast VPN Overview


Multicast traffic from the source is streamed towards router CE-1. Receivers connected to PE-2,
PE-3 and PE-4 are interested in joining this multicast group.
CEs 1 to 4 are PIM enabled routers, which form a PIM adjacency with nearest PE. The PIM
adjacencies between PEs across the Provider network are achieved using I-PMSIs. I-PMSIs carry
PIM control messages between PEs. Data plane traffic is transported across the I-PMSI until a
configured bandwidth threshold is reached. A Selective PMSI is then signaled that carries data
plane traffic. This threshold can be as low as 1kb/second and must be explicitly configured along
with the S-PMSI multicast group. An S-PMSI per customer group per VPRN is configured. If no
S-PMSI and threshold is configured, data traffic will continue to be forwarded across the provider
network within the I-PMSI.

Page 1154

Advanced Configuration Guide

Multicast in a VPN I

Configuration
The configuration is divided into the following sections:

Provider Common Configuration


PE Global Configuration
PE VPRN Configuration

PE VPRN Multicast Configuration


Auto-Discovery within Provider Domain using PIM
PIM Autodiscovery: Customer Signaling using PIM

PIM Any Source Multicasting with RP at the provider PE

PIM Any Source Multicasting with Anycast RP at the provider PE

PIM Source Specific Multicasting


BGP Autodiscovery: PE VPRN Multicast Configuration
Data Path Using Selective-PMSIs

Provider Common Configuration


This section describes the common configuration required for each PE within the Provider
multicast domain, regardless of the MVPN PE auto-discovery or customer signaling methods.
This includes IGP and VPRN service configuration.
The configuration tasks can be summarized as follows:

PE global configuration. This includes configuration of the Interior Gateway Protocol


(IGP) (ISIS or OSPF); configuration of link layer LDP between PEs; configuration of
iBGP between PEs, to facilitate VPRN route learning; configuration of PIM.

VPRN configuration on PEs. This includes configuration of basic VPRN parameters


(route-distinguisher, route target communities); configuration of attachment circuits
towards CEs; configuration of VRF routing protocol and any policies towards CE.

VRF PIM and MVPN parameters I-PMSI

CE configuration.

Advanced Configuration Guide

Page 1155

Configuration

PE Global Configuration
Step 1. On each of the PE routers, configure the appropriate router interfaces, OSPF (or ISIS)

and link layer LDP. For clarity in the following configuration steps, only the configuration
For PE-1 is shown. PE-2, PE-3 and PE-4 are similar.
A:PE-1>config router
interface "int-pe1-pe2"
address 192.168.1.1/30
port 1/1/1
exit
interface "int-pe1-pe3"
address 192.168.2.1/30
port 1/1/2
exit
interface "system"
address 192.0.2.1/32
exit
autonomous-system 64496
ospf
area 0.0.0.0
interface "system"
exit
interface "int-pe1-pe2"
interface-type point-to-point
exit
interface "int-pe1-pe3"
interface-type point-to-point
exit
exit
exit
ldp
interface-parameters
interface "int-pe1-pe2"
exit
interface "int-pe1-pe3"
exit
exit
targeted-session
exit
exit

Page 1156

Advanced Configuration Guide

Multicast in a VPN I

Step 2. Verify that OSPF adjacencies are formed and that LDP peer sessions are formed.
A:PE-1# show router ospf neighbor
===============================================================================
OSPF Neighbors
===============================================================================
Interface-Name
Rtr Id
State
Pri RetxQ
TTL
------------------------------------------------------------------------------int-pe1-pe2
192.0.2.2
Full
1
0
31
int-pe1-pe3
192.0.2.3
Full
1
0
37
------------------------------------------------------------------------------No. of Neighbors: 2
===============================================================================

A:PE-1 # show router ldp session


=============================================================================
LDP Sessions
=============================================================================
Peer LDP Id
Adj Type
State
Msg Sent Msg Recv Up Time
----------------------------------------------------------------------------192.0.2.2:0
Link
Established
8651
8651
0d 06:38:44
192.0.2.3:0
Link
Established
8697
8694
0d 06:40:20
----------------------------------------------------------------------------No. of Sessions: 2
=============================================================================
A:PE-1 #

Step 3. Configure BGP between the PEs for VPRN routing.


A:PE-1> configure router
bgp
group "internal"
family vpn-ipv4
peer-as 64496
neighbor 192.0.2.2
exit
neighbor 192.0.2.3
exit
neighbor 192.0.2.4
exit
exit
exit

Advanced Configuration Guide

Page 1157

Configuration

Step 4. Verify that BGP peer relationship is established.


A:PE-1# show router bgp summary
===============================================================================
BGP Router ID:192.0.2.1
AS:64496
Local AS:64496
===============================================================================
BGP Admin State
: Up
BGP Oper State
: Up
Total Peer Groups
: 1
Total Peers
: 3
Total BGP Paths
: 14
Total Path Memory
: 1800
Total IPv4 Remote Rts
: 0
Total IPv4 Rem. Active Rts : 0
Total IPv6 Remote Rts
: 0
Total IPv6 Rem. Active Rts : 0
Total Supressed Rts
: 0
Total Hist. Rts
: 0
Total Decay Rts
: 0
Total VPN Peer Groups
: 2
Total VPN Peers
: 2
Total VPN Local Rts
: 4
Total VPN-IPv4 Rem. Rts : 3
Total VPN-IPv4 Rem. Act. Rts: 3
Total VPN-IPv6 Rem. Rts : 0
Total VPN-IPv6 Rem. Act. Rts: 0
Total L2-VPN Rem. Rts
: 0
Total L2VPN Rem. Act. Rts
: 0
Total VPN Supp. Rts
: 0
Total VPN Hist. Rts
: 0
Total VPN Decay Rts
: 0
Total MVPN-IPv4 Rem Rts : 0
Total MVPN-IPv4 Rem Act Rts : 0
===============================================================================
BGP Summary
===============================================================================
Neighbor
AS PktRcvd InQ Up/Down
State|Rcv/Act/Sent (Addr Family)
PktSent OutQ
------------------------------------------------------------------------------192.0.2.2
64496
9429
0 01d02h39m 1/1/4 (VpnIPv4)
9477
0
192.0.2.3
64496
9435
0 01d02h39m 1/1/4 (VpnIPv4)
9494
0
192.0.2.4
64496
9431
0 01d02h39m 1/1/4 (VpnIPv4)
9457
0
===============================================================================
A:PE-1#

Page 1158

Advanced Configuration Guide

Multicast in a VPN I

Step 5. Enable PIM on all network interfaces, including the system interface. This allows the

signaling of PMSIs that transport PIM signaling within each VRF.


Step 6. As each I-PMSI will signalled using PIM ASM, a rendezvous point (RP) is required

within the global PIM configuration. A static RP used and PE-1 is selected. All PEs must
be configured with this RP address.
A:PE-1> Configure router
pim
interface "system"
exit
interface "int-pe1-pe2"
exit
interface "int-pe1-pe3"
exit
rp
static
address 192.0.2.1
group-prefix 239.255.0.0/16
exit
exit
bsr-candidate
shutdown
exit
rp-candidate
shutdown
exit
exit
exit

Step 7. Verify PIM neighbor relationship


A:PE-1# show router pim neighbor
===============================================================================
PIM Neighbor ipv4
===============================================================================
Interface
Nbr DR Prty
Up Time
Expiry Time
Hold Time
Nbr Address
------------------------------------------------------------------------------int-pe1-pe2
1
0d 23:21:04
0d 00:01:15
105
192.168.1.2
int-pe1-pe3
1
0d 23:22:40
0d 00:01:34
105
192.168.2.2
------------------------------------------------------------------------------Neighbors : 2
===============================================================================
A:PE-1#

Advanced Configuration Guide

Page 1159

Configuration

PE VPRN Configuration
A VPRN (VPRN 1) is created on each PE. This will be the multicast VPRN. PE-1 will be the PE
containing the attachment circuit towards CE-1. CE-1 will be the CE nearest the source. PE-2, PE3 and PE-4 will contain attachment circuits towards CE-2, CE-3 and CE-4 respectively. Each CE
will have a receiving host attached.
Step 1. Create VPRN 1 on each PE, containing a route-distinguisher and vrf-target of

64496:1. The autonomous system number is 64496. Use auto-bind LDP for next hop tunnel
route resolution.
A:PE-1>config>service>vprn# info
---------------------------------------------autonomous-system 64496
route-distinguisher 64496:1
auto-bind ldp
vrf-target target:64496:1
...
---------------------------------------------A:PE-1>config>service>vprn#

Step 2. Create an attachment circuit interface towards the CE.


configure service vprn 1
interface "int-pe1-ce1" create
address 172.16.255.254/30
sap 1/1/4:1 create
exit
exit

Step 3. The source address of the multicast stream will need to be reachable by all routers

(PEs and CEs) within the VPN. This will be advertised within BGP from the CE to the PE.
Create a BGP peering relationship with the CE.
configure service vprn 1
bgp
group "external"
type external
peer-as 64497
neighbor 172.16.255.253
exit
exit
exit

Step 4. On CE-1, create a VPRN to support the connection of the source to the CE and to

connect the CE to the PE. Two attachment circuits are required, as well as a BGP peering
relationship with the PE. This uses a default address family of ipv4.
(NB a pair of IES services could also be used to provide the attachment circuits)

Page 1160

Advanced Configuration Guide

Multicast in a VPN I

*A:CE-1>config service vprn 1


autonomous-system 64497
route-distinguisher 64497:1
interface "int-ce1-pe1" create
address 172.16.255.253/30
sap 1/1/1:1 create
exit
exit
interface "to-source" create
address 192.168.1.1/24
sap 1/1/3:1 create
exit
exit
bgp
group "external"
type external
peer-as 64496
neighbor 172.16.255.254
exit
exit
exit
no shutdown
---------------------------------------------*A:CE-1>config>service>vprn#

Advanced Configuration Guide

Page 1161

Configuration

Step 5. Verify PE-CE BGP peer relationship on CE-1 and PE-1:


*A:CE-1# show router 1 bgp summary
===============================================================================
BGP Router ID:192.0.2.5
AS:64497
Local AS:64497
===============================================================================
BGP Admin State
: Up
BGP Oper State
: Up
Total Peer Groups
: 1
Total Peers
: 1
Total BGP Paths
: 3
Total Path Memory
: 412
Total IPv4 Remote Rts
: 2
Total IPv4 Rem. Active Rts : 2
Total IPv6 Remote Rts
: 0
Total IPv6 Rem. Active Rts : 0
Total Supressed Rts
: 0
Total Hist. Rts
: 0
Total Decay Rts
: 0
===============================================================================
BGP Summary
===============================================================================
Neighbor
AS PktRcvd InQ Up/Down
State|Rcv/Act/Sent (Addr Family)
PktSent OutQ
------------------------------------------------------------------------------172.16.255.254
64496
10709
0 22h18m21s 2/2/1 (IPv4)
10696
0
===============================================================================
*A:CE-1#

A:PE-1# show router 1 bgp summary


===============================================================================
BGP Router ID:192.0.2.1
AS:64496
Local AS:64496
===============================================================================
BGP Admin State
: Up
BGP Oper State
: Up
Total Peer Groups
: 1
Total Peers
: 1
Total BGP Paths
: 4
Total Path Memory
: 520
Total IPv4 Remote Rts
: 1
Total IPv4 Rem. Active Rts : 0
Total IPv6 Remote Rts
: 0
Total IPv6 Rem. Active Rts : 0
Total Supressed Rts
: 0
Total Hist. Rts
: 0
Total Decay Rts
: 0
===============================================================================
BGP Summary
===============================================================================
Neighbor
AS PktRcvd InQ Up/Down
State|Rcv/Act/Sent (Addr Family)
PktSent OutQ
------------------------------------------------------------------------------172.16.255.253
64497
10699
0 22h22m38s 1/0/2 (IPv4)
10721
0
===============================================================================
A:PE-1#

Page 1162

Advanced Configuration Guide

Multicast in a VPN I

Step 6. In order for the CE connecting to the source to be advertised within BGP, a route

policy is required. The subnet containing the multicast source is 192.168.1.0/24, so a


prefix-list can be used to define a match, and then used within a route policy to inject into
BGP.
A:CE-1>config>router>policy-options# info
---------------------------------------------prefix-list "source"
prefix 192.168.1.0/24 exact
exit
policy-statement "policy-1"
entry 10
from
prefix-list "source"
exit
to
protocol bgp
exit
action accept
exit
exit
exit
---------------------------------------------A:CE-1>config>router>policy-options#

Step 7. Apply policy as an export policy within BGP context


A:CE-1# configure service vprn 1 bgp
export "policy-1"
group "external"
type external
peer-as 64496
neighbor 172.16.255.254
exit
exit

This results in the 192.168.1.0/24 subnet being seen in the BGP RIB_OUT on CE-1
A:CE-1# show router 1 bgp routes 192.168.1.0/24 hunt
===============================================================================
BGP Router ID:192.0.2.5
AS:64497
Local AS:64497
===============================================================================
Legend Status codes : u - used, s - suppressed, h - history, d - decayed, * - valid
Origin codes : i - IGP, e - EGP, ? - incomplete, > - best
===============================================================================
BGP IPv4 Routes
===============================================================================
------------------------------------------------------------------------------RIB In Entries
------------------------------------------------------------------------------------------------------------------------------------------------------------RIB Out Entries

Advanced Configuration Guide

Page 1163

Configuration

------------------------------------------------------------------------------Network
: 192.168.1.0/24
Nexthop
: 172.16.255.253
To
: 172.16.255.254
Res. Nexthop
: n/a
Local Pref.
: n/a
Interface Name : NotAvailable
Aggregator AS : None
Aggregator
: None
Atomic Aggr.
: Not Atomic
MED
: None
Community
: No Community Members
Cluster
: No Cluster Members
Originator Id : None
Peer Router Id : 192.0.2.1
Origin
: Incomplete
AS-Path
: 64497
------------------------------------------------------------------------------Routes : 1
===============================================================================
A:CE-1#

It is also seen in the PE-1 VRF 1 FIB:


A:PE-1# show router 1 route-table
===============================================================================
Route Table (Service: 1)
===============================================================================
Dest Prefix
Type
Proto
Age
Pref
Next Hop[Interface Name]
Metric
------------------------------------------------------------------------------172.16.253.252/30
Remote BGP VPN 00h07m30s
170
192.0.2.3
0
172.16.254.252/30
Remote BGP VPN 01d01h30m
170
192.0.2.2
0
172.16.255.252/30
Local
Local
22h48m52s
0
int-pe1-ce1
0
192.168.1.0/24
Remote BGP
00h09m44s
170
172.16.255.253
0
------------------------------------------------------------------------------No. of Routes: 4
===============================================================================
A:PE-1#

Page 1164

Advanced Configuration Guide

Multicast in a VPN I

This prefix will also be automatically advertised within the BGP VPRN to all other PEs, and will
be installed in VRF 1.
For example, on PE-2:
*A:PE-2# show router 1 route-table
===============================================================================
Route Table (Service: 1)
===============================================================================
Dest Prefix
Type
Proto
Age
Pref
Next Hop[Interface Name]
Metric
------------------------------------------------------------------------------172.16.253.252/30
Remote BGP VPN 00h09m52s
170
192.0.2.3
0
172.16.254.252/30
Local
Local
01d01h33m
0
int-pe2-ce2
0
172.16.255.252/30
Remote BGP VPN 00h51m26s
170
192.0.2.1
0
192.168.1.0/24
Remote BGP VPN 00h11m48s
170
192.0.2.1
0
------------------------------------------------------------------------------No. of Routes: 4
===============================================================================
*A:PE-2#

Each CE containing the Multicast Receivers must be able to reach the source. The following
output shows the VPRN configuration of CE-2 containing an interface towards PE-2 and an
interface towards Receiver A (RX-A). A static route will suffice and is configured with next hop
of the PE-2 PE-CE interface.
---------------------------------------------autonomous-system 64498
route-distinguisher 64498:1
interface "RX-A" create
address 192.2.1.1/24
sap 1/1/4:1 create
exit
exit
interface "int-ce2-pe2" create
address 172.16.254.253/30
sap 1/1/1:1 create
exit
exit
static-route 192.168.1.0/24 next-hop 172.16.254.254

Advanced Configuration Guide

Page 1165

Configuration

PE VPRN Multicast Configuration


This section gives details of the VPRN configuration that allows the support of multicasting.
Sub-sections include:
1. Autodiscovery This is the mechanism by which each PE advertises the presence of a
MVPN to other PEs. This can be achieved using PIM or using BGP. This section covers PIM
autodiscovery (autodiscovery using BGP is shown later)
2. Customer Domain signaling This discusses the mechanism of transporting customer signaling
3. Data Plane connectivity This is the signaling of S-PMSIs within the provider domain to
carry each individual customer multicast stream.
This note discusses the PIM and BGP autodiscovery mechanisms in detail. For each of these, there
is an example of customer domain signaling. For completion, a single example of S-PMSI creation
is also shown.

Auto-Discovery within Provider Domain Using PIM


Each PE advertises its membership of a multicast VPN using PIM through the configuration of an
Inclusive PMSI (I-PMSI). This is a multicast group that is common to each VPRN. The
configuration for PE 1 and 2 is shown in the following outputs:
*A:PE-1# configure service vprn 1
---------------------------------------------mvpn
provider-tunnel
inclusive
pim asm 239.255.255.1
exit
exit
exit
exit
no shutdown
...
---------------------------------------------*A:PE-1#

*A:PE-2# configure service vprn 1


---------------------------------------------mvpn
provider-tunnel
inclusive
pim asm 239.255.255.1
exit
exit
exit

Page 1166

Advanced Configuration Guide

Multicast in a VPN I

exit
no shutdown
...
---------------------------------------------*A:PE-2#

The multicast group address used for the PMSI must be the same on all PEs for this VPRN
instance.
Verify that PIM in the Global routing table (GRT) has signalled the I-PMSIs.
For the PE acting as the RP for global PIM:
A:PE-1# show router pim group
===============================================================================
PIM Groups ipv4
===============================================================================
Group Address
Type
Spt Bit Inc Intf
No.Oifs
Source Address
RP
------------------------------------------------------------------------------239.255.255.1
(*,G)
3
*
192.0.2.1
239.255.255.1
(S,G)
spt
system
3
192.0.2.1
192.0.2.1
239.255.255.1
(S,G)
spt
int-pe1-pe2
2
192.0.2.2
192.0.2.1
239.255.255.1
(S,G)
spt
int-pe1-pe3
2
192.0.2.3
192.0.2.1
------------------------------------------------------------------------------Groups : 4
===============================================================================
A:PE-1#

This shows an incoming (S,G) join from all other PEs within the multicast VRF, plus an outgoing
(*,G) join to the same PEs.
All other PEs will have the following PIM groups.
A:PE-2# show router pim group
===============================================================================
PIM Groups ipv4
===============================================================================
Group Address
Type
Spt Bit Inc Intf
No.Oifs
Source Address
RP
------------------------------------------------------------------------------239.255.255.1
(*,G)
int-pe2-pe1
1
*
192.0.2.1
239.255.255.1
(S,G)
spt
system
2
192.0.2.2
192.0.2.1
------------------------------------------------------------------------------Groups : 2
===============================================================================

Advanced Configuration Guide

Page 1167

Configuration

A:PE-2#

This shows an (S,G) join towards the RP at 192.0.2.1, plus a (*,G) join from RP. These represent
the outgoing and incoming PIM interfaces for the VRF.
This results in a series of PIM neighbors through the I-PMSIs within the VRF, which are
maintained using PIM hellos.
A:PE-1# show router 1 pim neighbor
===============================================================================
PIM Neighbor ipv4
===============================================================================
Interface
Nbr DR Prty
Up Time
Expiry Time
Hold Time
Nbr Address
------------------------------------------------------------------------------int-pe1-ce1
1
1d 02:07:04
0d 00:01:35
105
172.16.255.253
1-mt-239.255.255.1
1
2d 00:37:32
0d 00:01:23
105
192.0.2.2
1-mt-239.255.255.1
1
2d 00:37:12
0d 00:01:31
105
192.0.2.3
------------------------------------------------------------------------------Neighbors :3
===============================================================================
A:PE-1#

Page 1168

Advanced Configuration Guide

Multicast in a VPN I

PIM Auto-Discovery: Customer Signaling using PIM


Consider now how the signaling plane of the customer domain is dealt with at the provider
domain.
The customer domain configuration covers the following three cases:
1. PIM ASM with the RP in the provider PE.
2. PIM ASM using anycast RP on the provider RPs.
3. PIM SSM.

PIM Any Source Multicasting with RP at the Provider PE


As each PE connects to a CE which will be part of the multicast VRF, it is necessary to enable
PIM on each interface containing an attachment circuit towards a CE, and to configure the I-PMSI
multicast tunnel for the VRF.
There is a requirement for an RP, as customer multicast signaling will be PIM-ASM.
The RP for the customer multicast will be on PE-2. In order to facilitate this, a loopback interface
is created (called RP within the VPRN 1 context of PE-2, and will be advertised to all PEs. It must
also be a PIM enabled interface.
On PE-2 (the RP):
*A:PE-2# configure service vprn 1
*A:PE-2>config>service>vprn# info
---------------------------------------------autonomous-system 64496
route-distinguisher 64496:1
auto-bind ldp
vrf-target target:64496:1
interface "int-pe2-ce2" create
address 172.16.254.254/30
sap 1/1/3:1 create
exit
exit
interface "rp" create
address 10.2.3.4/32
loopback
exit
pim
interface "int-pe2-ce2"
exit
interface "rp"
exit
rp
static

Advanced Configuration Guide

Page 1169

Configuration

group-prefix 224.0.0.0/8
exit
exit
no shutdown

The RP must also be configured on each of the PEs and also each CE.
On each of the PEs, the configuration displays as follows:
A:PE-1#configure service vprn 1
pim
interface "int-pe1-ce1"
exit
rp
static
address 10.2.3.4
group-prefix 224.0.0.0/8
exit
exit
no shutdown

Customer Edge Router Multicast Configuration


Each CE router will have a PIM neighbor peer relationship with its nearest PE.
The CE router (CE-1) containing the source will have PIM enabled on the interface connected to
the source. It will also have a static RP entry, as the incoming sources need to be registered with
the RP.
A:CE-1# configure service vprn 1
autonomous-system 64497
route-distinguisher 64497:1
interface "int-ce1-pe1" create
address 172.16.255.253/30
sap 1/1/1:1 create
exit
exit
interface "to-source" create
address 192.168.1.1/24
sap 1/1/3:1 create
exit
exit
pim
interface "int-ce1-pe1"
exit
interface "to-source"
exit
rp
static
address 10.2.3.4
group-prefix 224.0.0.0/8

Page 1170

Advanced Configuration Guide

Multicast in a VPN I

exit
exit
exit
no shutdown

The CE containing the receivers will have IGMP enabled on the interface connected to the
receivers. Once again, there needs to be an RP configured, as the router needs to issue PIM joins to
the RP.
A:CE-2# configure service vprn 1
autonomous-system 64498
route-distinguisher 64498:1
interface "RX-A" create
address 192.2.1.1/24
sap 1/1/4:1 create
exit
exit
interface "int-ce2-pe2" create
address 172.16.254.253/30
sap 1/1/1:1 create
exit
exit
static-route 192.168.1.0/24 next-hop 172.16.254.254
static-route 10.0.0.0/8 next-hop 172.16.254.254
igmp
interface "RX-A"
exit
exit
pim
interface "int-ce2-pe2"
exit
rp
static
address 10.2.3.4
group-prefix 224.0.0.0/8
exit
exit
exit
no shutdown

Advanced Configuration Guide

Page 1171

Configuration

Traffic Flow
The source sends a multicast stream using group address 225.0.0.1 towards CE-1. As the group
matches the group address in the static RP configuration, the router sends a register join towards
the RP. At this time, no receivers are interested in the group, so there are no entries in the Outgoing
Interface List (OIL), and the number of outgoing interfaces (OIFs) is zero.
The PIM status of CE-1 within VPN 1 is as follows:
A:CE-1# show router 1 pim group
===============================================================================
PIM Groups ipv4
===============================================================================
Group Address
Type
Spt Bit Inc Intf
No.Oifs
Source Address
RP
------------------------------------------------------------------------------225.0.0.1
(S,G)
to-source
0
192.168.1.2
10.2.3.4
------------------------------------------------------------------------------Groups : 1
===============================================================================
A:CE-1#

The receiver A connected to CE-2, wishes to join the group 225.0.0.1, and so sends in an IGMPv2
report towards CE-2. CE-2 recognizes the report, which contains no source.
A:CE-2# show router 1 igmp group
===============================================================================
IGMP Groups
===============================================================================
(*,225.0.0.1)
Up Time : 0d 00:00:33
Fwd List : RX-A
------------------------------------------------------------------------------(*,G)/(S,G) Entries : 1
===============================================================================
A:CE-1#

CE-2 is not aware of the source of the group so initiates a (*,G) PIM join towards the RP.
At the RP, a (*,G) join is received
A:PE-2# show router 1 pim group 225.0.0.1 type starg detail
===============================================================================
PIM Source Group ipv4
===============================================================================
Group Address
: 225.0.0.1
Source Address
: *
RP Address
: 10.2.3.4
Flags
:
Type
: (*,G)
MRIB Next Hop
:
MRIB Src Flags
: self
Keepalive Timer
: Not Running
Up Time
: 0d 00:15:41
Resolved By
: rtable-u

Page 1172

Advanced Configuration Guide

Multicast in a VPN I

Up JP State
Up JP Rpt

: Joined
: Not Joined StarG

Up JP Expiry
: 0d 00:00:18
Up JP Rpt Override : 0d 00:00:00

Rpf Neighbor
:
Incoming Intf
:
Outgoing Intf List : int-pe2-ce2
Curr Fwding Rate
: 0.0 kbps
Forwarded Packets : 0
Discarded Packets : 0
Forwarded Octets
: 0
RPF Mismatches
: 0
Spt threshold
: 0 kbps
ECMP opt threshold : 7
Admin bandwidth
: 1 kbps
------------------------------------------------------------------------------Groups : 1

The RP can now forward traffic from itself towards CE-2, as the outgoing interface is seen as intpe2-ce2.
CE-2 is now able to determine the source from the traffic stream, so it initiates a Reverse Path
Forwarding (RPF) lookup of the source address in the route table, and issues an (S,G) PIM join
towards the source.
The join is propagated across the provider network, from PE-2 towards PE-1 which is the resolved
RPF next hop for the source.
A:PE-1# show router 1 pim group detail
===============================================================================
PIM Source Group ipv4
===============================================================================
Group Address
: 225.0.0.1
Source Address
: 192.168.1.2
RP Address
: 172.16.254.254
Flags
: spt
Type
: (S,G)
MRIB Next Hop
: 172.16.255.253
MRIB Src Flags
: remote
Keepalive Timer Exp: 0d 00:01:43
Up Time
: 0d 00:08:47
Resolved By
: rtable-u
Up JP State
Up JP Rpt

: Joined
: Not Joined StarG

Up JP Expiry
: 0d 00:00:13
Up JP Rpt Override : 0d 00:00:00

Register State
: No Info
Reg From Anycast RP: No
Rpf Neighbor
: 172.16.255.253
Incoming Intf
: int-pe1-ce1
Outgoing Intf List : 1-mt-239.255.255.1
Curr Fwding Rate
: 33.6 kbps
Forwarded Packets : 52214
Discarded Packets : 0
Forwarded Octets
: 2192988
RPF Mismatches
: 0
Spt threshold
: 0 kbps
ECMP opt threshold : 7
Admin bandwidth
: 1 kbps
------------------------------------------------------------------------------Groups : 1

Advanced Configuration Guide

Page 1173

Configuration

Note that the outgoing interface is the I-PMSI.


The join is received by CE-1, which contains the subnet of the source.
CE-1 now recognizes the multicast group as a valid stream. This becomes the root of the shortest
path tree for the group.
A:CE-1# show router 1 pim group
===============================================================================
PIM Groups ipv4
===============================================================================
Group Address
Type
Spt Bit Inc Intf
No.Oifs
Source Address
RP
------------------------------------------------------------------------------225.0.0.1
(S,G)
spt
to-source
1
192.168.1.2
------------------------------------------------------------------------------Groups : 1
===============================================================================
A:CE-1#

For completion, consider a second receiver B interested in group 225.0.0.1. The IGMP V2 report
is translated into a (*,G) PIM join at CE-3 towards the RP.
A:CE-3# show router 1 pim group type starg
===============================================================================
PIM Groups ipv4
===============================================================================
Group Address
Type
Spt Bit Inc Intf
No.Oifs
Source Address
RP
------------------------------------------------------------------------------225.0.0.1
(*,G)
int-ce3-pe3
1
*
10.2.3.4
------------------------------------------------------------------------------Groups : 1

Page 1174

Advanced Configuration Guide

Multicast in a VPN I

At the RP (PE-2), there is now a second interface in the OIL,


A:PE-2# show router 1 pim group 225.0.0.1 type starg detail
===============================================================================
PIM Source Group ipv4
===============================================================================
Group Address
: 225.0.0.1
Source Address
: *
RP Address
: 10.2.3.4
Flags
:
Type
: (*,G)
MRIB Next Hop
:
MRIB Src Flags
: self
Keepalive Timer
: Not Running
Up Time
: 0d 00:24:38
Resolved By
: rtable-u
Up JP State
Up JP Rpt

: Joined
: Not Joined StarG

Up JP Expiry
: 0d 00:00:21
Up JP Rpt Override : 0d 00:00:00

Rpf Neighbor
:
Incoming Intf
:
Outgoing Intf List : int-pe2-ce2, 1-mt-239.255.255.1
Curr Fwding Rate
: 0.0 kbps
Forwarded Packets : 0
Discarded Packets : 0
Forwarded Octets
: 0
RPF Mismatches
: 0
Spt threshold
: 0 kbps
ECMP opt threshold : 7
Admin bandwidth
: 1 kbps
------------------------------------------------------------------------------Groups : 1

The second interface is the I-PMSI, which is the multicast tunnel towards all other PEs. At PE-3,
the (*,G) join has the I-PMSI as an incoming interface, and the PE-CE interface as the outgoing
interface.
A:PE-3# show router 1 pim group type starg detail
===============================================================================
PIM Source Group ipv4
===============================================================================
Group Address
: 225.0.0.1
Source Address
: *
RP Address
: 10.2.3.4
Flags
:
Type
: (*,G)
MRIB Next Hop
: 192.0.2.2
MRIB Src Flags
: remote
Keepalive Timer
: Not Running
Up Time
: 0d 00:04:10
Resolved By
: rtable-u
Up JP State
Up JP Rpt

: Joined
: Not Joined StarG

Up JP Expiry
: 0d 00:00:50
Up JP Rpt Override : 0d 00:00:00

Rpf Neighbor
: 192.0.2.2
Incoming Intf
: 1-mt-239.255.255.1
Outgoing Intf List : int-pe3-ce3
Curr Fwding Rate
Forwarded Packets
Forwarded Octets
Spt threshold

Advanced Configuration Guide

:
:
:
:

0.0 kbps
1
42
0 kbps

Discarded Packets : 0
RPF Mismatches
: 0
ECMP opt threshold : 7

Page 1175

Configuration

Admin bandwidth
: 1 kbps
------------------------------------------------------------------------------Groups : 1
===============================================================================
A:PE-3#

Once again, as the CE receives traffic from the group, it can use the source address in the packet to
initiate an (S,G) join towards the source ?it joins the shortest path tree
A:CE-3# show router 1 pim group type sg detail
===============================================================================
PIM Source Group ipv4
===============================================================================
Group Address
: 225.0.0.1
Source Address
: 192.168.1.2
RP Address
: 10.2.3.4
Flags
: spt
Type
: (S,G)
MRIB Next Hop
: 172.16.253.254
MRIB Src Flags
: remote
Keepalive Timer Exp: 0d 00:02:44
Up Time
: 0d 00:07:48
Resolved By
: rtable-u
Up JP State
Up JP Rpt

: Joined
: Not Pruned

Up JP Expiry
: 0d 00:00:12
Up JP Rpt Override : 0d 00:00:00

Register State
: No Info
Reg From Anycast RP: No
Rpf Neighbor
: 172.16.253.254
Incoming Intf
: int-ce3-pe3
Outgoing Intf List : RX-B
Curr Fwding Rate
: 16.9 kbps
Forwarded Packets : 23303
Discarded Packets : 0
Forwarded Octets
: 978726
RPF Mismatches
: 0
Spt threshold
: 0 kbps
ECMP opt threshold : 7
Admin bandwidth
: 1 kbps
------------------------------------------------------------------------------Groups : 1
===============================================================================
A:CE-3#

Page 1176

Advanced Configuration Guide

Multicast in a VPN I

PIM Any Source Multicasting with Anycast RP at the Provider PE


The network topology is displayed in Figure 87. The setup consists of 4 x 7750s acting as Provide
Edge (PE) routers within a single Autonomous System (AS).

Anycast RP
10.2.3.5/32

Multicast Source
225.0.0.1

PE-1

PE-2

.254 vprn1

192.0.2.1 192.0.2.2 vprn1

AS 64497

.2
192.168.1.0/24 CE-1 172.16.255.252/30
.1

.253

Multicast
Receiver A

AS 64498
.2
172.16.254.252/30 CE-2 192.168.2.0/24
.254

.253

.1

AS 64496

192.168.3.0/24 CE-3 172.16.253.252/30


.1
.2

.253

.254

vprn1
PE-3

Multicast
Receiver B

192.0.2.3 192.0.2.4

vprn1

172.16.252.252/30 CE-4 192.168.4.0/24


.254

.253

.1

PE-4

Multicast
Receiver C
Anycast RP
10.2.3.5/32

AS 64499

.2

AS 64500

OSSG462

Figure 87: Network Topology for Anycast RP

Connected to each PE is a single 7750 acting as a Customer Edge (CE) router. CE-1 has a single
multicast source connected, and PEs 2 to 4 each have a single receiver connected which will
receive the multicast stream from the source. In this section, each receiver is IGMPv2 capable, and
so will issue IGMPv2 reports. A Rendezvous Point is required by the C-signaling plane to resolve
each (*,G) group state into an (S,G) state. In this case, two RPs are chosen to form an Anycast set
to resolve each (*,G) group into an (S,G) state.
Multicast traffic from the source group 225.0.0.1 is streamed toward router CE-1. Receivers
connected to PE-2, PE-3 and PE-4 are interested in joining this multicast group.

Advanced Configuration Guide

Page 1177

Configuration

Anycast RP - PE VPRN Configuration


As each PE contains a CE which will be part of the multicast VRF, it is necessary to enable PIM
on each interface containing an attachment circuit towards a CE, and to configure the I-PMSI
multicast tunnel for the VRF.
As previously stated, there is a requirement for an RP, as Customer Multicast signaling will be
PIM-ASM and IGMPv2.
In this case, an Anycast RP will be used. This is configured on PE-2 and PE-3, and an anycast set
is created.
As each PE contains a CE which will be part of the multicast VRF, it is necessary to enable PIM
on each interface containing an attachment circuit towards a CE, and to configure the I-PMSI
multicast tunnel for the VRF.
The following output shows the VPRN configuration for PE-2 containing the RP and anycast RP
configuration:
A:PE-2#configure service vprn 1
interface "rp" create
address 10.2.3.5/32
loopback
exit
interface "lo1" create
address 10.0.0.2/32
loopback
exit
pim
interface "int-pe2-ce2"
#Attachment circuit towards CE
exit
interface "rp"
#RP interface
exit
interface "lo1"
#loopback interface for inter RP communication
exit
rp
static
address 10.2.3.5
group-prefix 225.0.0.0/8
exit
exit
anycast 10.2.3.5
#Anycast RP IP address
rp-set-peer 10.0.0.2
#IP address of THIS router
rp-set-peer 10.0.0.3
#IP address of peer router
exit
exit
exit
mvpn
provider-tunnel
inclusive
pim asm 239.255.255.1
exit
exit

Page 1178

Advanced Configuration Guide

Multicast in a VPN I

exit
exit
no shutdown

Similarly, the VPRN configuration for PE-3 is:


A:PE-3#configure service vprn 1
interface "rp" create
address 10.2.3.5/32
loopback
exit
interface "lo1" create
address 10.0.0.3/32
loopback
exit
pim
interface "int-pe3-ce3" #Attachment circuit towards CE
exit
interface "rp"
#RP interface
exit
interface "lo1"
#loopback interface for inter RP communication
exit
rp
static
address 10.2.3.5
group-prefix 225.0.0.0/8
exit
exit
anycast 10.2.3.5
#Anycast RP IP address
rp-set-peer 10.0.0.2
#IP address of THIS router
rp-set-peer 10.0.0.3
#IP address of peer router
exit
exit
exit
mvpn
provider-tunnel
inclusive
pim asm 239.255.255.1
exit
exit
exit
exit
no shutdown

As previously stated, there is a requirement for an RP, as customer multicast signaling will be
PIM-ASM and IGMPv2.
In this case, an anycast RP will be used. This is configured on PE-2 and PE-, and an anycast set is
created.
The anycast address will be 10.2.3.5/32 and is created as an interface called rp on both PE-2 and
PE-3.

Advanced Configuration Guide

Page 1179

Configuration

An additional loopback interface, called lo1 is created on each VPRN on PEs containing the
anycast address. These are used as source addresses for communication between the routers within
the RP set. These addresses will be automatically advertised to all PEs as vpn-ipv4 addresses, and
will be installed in the VRF 1 forwarding table of all PEs containing VPRN 1.
Note: All routers containing RP must have their own loopback address included in the RP set as
well as all peer routers.
The multicast group address used for the Inclusive PMSI is chosen to be 239.255.255.1 and must
be the same on all PEs for this VPRN instance. This is analogous to the MDT within the DraftRosen implementation.
Verify that PIM in the global routing table (GRT) has signalled the I-PMSIs.
For the PE acting as the RP for global PIM:
A:PE-1# show router pim group
===============================================================================
PIM Groups ipv4
===============================================================================
Group Address
Type
Spt Bit Inc Intf
No.Oifs
Source Address
RP
------------------------------------------------------------------------------239.255.255.1
(*,G)
3
*
192.0.2.1
239.255.255.1
(S,G)
spt
system
3
192.0.2.1
192.0.2.1
239.255.255.1
(S,G)
spt
int-pe1-pe2
2
192.0.2.2
192.0.2.1
239.255.255.1
(S,G)
spt
int-pe1-pe3
2
192.0.2.3
192.0.2.1
------------------------------------------------------------------------------Groups : 4
===============================================================================
A:PE-1#

Page 1180

Advanced Configuration Guide

Multicast in a VPN I

All other PEs will have:


===============================================================================
PIM Groups ipv4
===============================================================================
Group Address
Type
Spt Bit Inc Intf
No.Oifs
Source Address
RP
------------------------------------------------------------------------------239.255.255.1
(*,G)
int-pe2-pe1
1
*
192.0.2.1
239.255.255.1
(S,G)
spt
system
2
192.0.2.2
192.0.2.1
------------------------------------------------------------------------------Groups : 2
===============================================================================

This shows a (S,G) join towards the RP at 192.0.2.1, plus a (*,G) join from RP. These represent
the outgoing and incoming PIM interfaces for the VRF.
This results in a series of PIM neighbors through the I-PMSIs within the VRF, which are
maintained using PIM hellos.
A:PE-1# show router 1 pim neighbor
===============================================================================
PIM Neighbor ipv4
===============================================================================
Interface
Nbr DR Prty
Up Time
Expiry Time
Hold Time
Nbr Address
------------------------------------------------------------------------------int-pe1-ce1
1
1d 02:07:04
0d 00:01:35
105
172.16.255.253
1-mt-239.255.255.1
1
2d 00:37:32
0d 00:01:23
105
192.0.2.2
1-mt-239.255.255.1
1
2d 00:37:12
0d 00:01:31
105
192.0.2.3
------------------------------------------------------------------------------Neighbors : 3
===============================================================================
A:PE-1#

Advanced Configuration Guide

Page 1181

Configuration

Verify PIM RP set:


*A:PE-2# show router 1 pim anycast
===============================================================================
PIM Anycast RP Entries ipv4
===============================================================================
Anycast RP
Anycast RP Peer
------------------------------------------------------------------------------10.2.3.5
10.0.0.2
10.0.0.3
------------------------------------------------------------------------------PIM Anycast RP Entries : 2
===============================================================================
*A:PE-2#

Anycast RP Customer Edge Router Multicast Configuration


Each CE router will have a PIM neighbor peer relationship with its nearest PE.
The CE router (CE-1) containing the source will have PIM enabled on the interface connected to
the source.
A:CE-1# configure service vprn 1
autonomous-system 64497
route-distinguisher 64497:1
interface "int-ce1-pe1" create
address 172.16.255.253/30
sap 1/1/1:1 create
exit
exit
interface "to-source" create
address 192.168.1.1/24
sap 1/1/3:1 create
exit
exit
pim
interface "int-ce1-pe1"
exit
interface "to-source"
exit
rp
static
address 10.2.3.5
group-prefix 225.0.0.0/8
exit
exit
no shutdown

Page 1182

Advanced Configuration Guide

Multicast in a VPN I

The CE containing the receivers will have IGMP enabled on the interface connected to the
receivers.
A:CE-2# configure service vprn 1
autonomous-system 64498
route-distinguisher 64498:1
interface "to-104/2" create
address 192.168.2.1/24
sap 1/1/4:1 create
exit
exit
interface "int-ce2-pe2" create
address 172.16.254.253/30
sap 1/1/1:1 create
exit
exit
static-route 0.0.0.0/0 next-hop 172.16.254.254
igmp
interface "RX-A"
exit
exit
no shutdown

Advanced Configuration Guide

Page 1183

Configuration

Traffic Flow
Anycast RP
10.2.3.5/32

Multicast Source
225.0.0.1

.2
192.168.1.0/24

Multicast
Receiver A

Register
PE1

CE1

.1

PE2

172.16.255.252/30

172.16.254.252/30

.254 vprn1

.253

192.0.2.1 192.0.2.2 vprn1

.254

CE2

.253

.2
192.168.1.0/24
.1

1
t

AS 64496

Se

RP

t-

as

c
ny

192.168.3.0/24

CE3

.2

172.16.253.252/30
.253

.1

Multicast
Receiver B

.254

vprn1

192.0.2.3 192.0.2.4

PE3

vprn1

172.16.252.252/30
.254

CE4

.253

192.168.4.0/24
.1

PE4

Multicast
Receiver C
Anycast RP
10.2.3.5/32
OSSG465

Figure 88: IGMP and PIM Control Messaging Schematic

Figure 88 shows the sequence of IGMP and PIM control messaging.


1. The source multicasts a stream with group address 225.0.0.1 towards CE-1.
2. CE-1 matches the group with the group address prefix in the static RP configuration and
sends a register message towards the RP.
A:CE-1# show router 1 pim group detail
===============================================================================
PIM Source Group ipv4
===============================================================================
Group Address
: 225.0.0.1
Source Address
: 192.168.1.2
RP Address
: 10.2.3.5
Flags
:
Type
: (S,G)
MRIB Next Hop
: 192.168.1.2
MRIB Src Flags
: direct
Keepalive Timer Exp: 0d 00:03:19
Up Time
: 0d 00:00:10
Resolved By
: rtable-u
Up JP State
Up JP Rpt

: Not Joined
: Not Joined StarG

Register State
: Pruned
Reg From Anycast RP: No
Rpf Neighbor

Page 1184

Up JP Expiry
: 0d 00:00:00
Up JP Rpt Override : 0d 00:00:00
Register Stop Exp

: 0d 00:00:38

: 192.168.1.2

Advanced Configuration Guide

Multicast in a VPN I

Incoming Intf
: to-source
Outgoing Intf List :
Curr Fwding Rate
: 0.0 kbps
Forwarded Packets : 292
Discarded Packets : 0
Forwarded Octets
: 12264
RPF Mismatches
: 0
Spt threshold
: 0 kbps
ECMP opt threshold : 7
Admin bandwidth
: 1 kbps
------------------------------------------------------------------------------Groups : 1
===============================================================================
A:CE-1#

The register message is sent to the nearest RP, the RP with the lowest IGP cost.
As the Register is sent through PE-1, it is PE-1 that determines which RP will receive the
message.
A:PE-1# show router 1 route-table 10.2.3.5/32
===============================================================================
Route Table (Service: 1)
===============================================================================
Dest Prefix
Type
Proto
Age
Pref
Next Hop[Interface Name]
Metric
------------------------------------------------------------------------------10.2.3.5/32
Remote BGP VPN 19h49m49s
170
192.0.2.2
0
------------------------------------------------------------------------------No. of Routes: 1
===============================================================================
A:PE-1#

The PE which will receive the register is 192.0.2.2 PE-2. The PIM group status on PE-2 is:
*A:PE-2# show router 1 pim group
===============================================================================
PIM Groups ipv4
===============================================================================
Group Address
Type
Spt Bit Inc Intf
No.Oifs
Source Address
RP
------------------------------------------------------------------------------225.0.0.1
(S,G)
1-mt-239.255.* 0
192.168.1.2
10.2.3.5
------------------------------------------------------------------------------Groups : 1
===============================================================================
*A:PE-2#

Advanced Configuration Guide

Page 1185

Configuration

This shows that RP is aware of the (S,G) status of the group 225.1.1.1, and becomes a root of a
shared tree for this group. Note that the Outgoing Interface List (OIL) is empty.
3. PE-2 will now send a register message to all other RPs within the anycast set. In this case to
PE-3 (which has VPRN 1 containing address 10.0.0.3).
The PIM status of the group 225.0.0.1 on PE-3 is:
A:PE-3# show router 1 pim group
===============================================================================
PIM Groups ipv4
===============================================================================
Group Address
Type
Spt Bit Inc Intf
No.Oifs
Source Address
RP
------------------------------------------------------------------------------225.0.0.1
(S,G)
1-mt-239.255.* 0
192.168.1.2
10.2.3.4
------------------------------------------------------------------------------Groups : 1
===============================================================================
* indicates that the corresponding row element may have been truncated.
A:PE-3#

Now both PEs within the RP set for VPRN have an (S,G) state for 225.0.0.1.
4. The receiver B, wishes to join the group 225.0.0.1, and so sends in an IGMPv2 report
towards CE-3. CE-3 recognizes the report, but has no PIM state for this group.
5. It sends a PIM join towards the RP, in this case the nearest RP will be PE-3.
PE-3 already has (S,G) state for this group, so will forward traffic towards receiver B.
6. CE-3 does a Reverse Path Forwarding (RPF) lookup of the source address in the route table,
and issues a PIM join towards the source.
The join is propagated across the provider network, towards PE-1 which is the resolved RPF next
hop for the source.
A:CE-3# show router 1 pim group type sg detail
===============================================================================
PIM Source Group ipv4
===============================================================================
Group Address
: 225.0.0.1
Source Address
: 192.168.1.2
RP Address
: 10.2.3.5
Flags
: spt
Type
: (S,G)
MRIB Next Hop
: 172.16.253.254
MRIB Src Flags
: remote
Keepalive Timer Exp: 0d 00:02:04
Up Time
: 0d 00:01:28
Resolved By
: rtable-u
Up JP State
Up JP Rpt

Page 1186

: Joined
: Not Pruned

Up JP Expiry
: 0d 00:00:32
Up JP Rpt Override : 0d 00:00:00

Advanced Configuration Guide

Multicast in a VPN I

Register State
: No Info
Reg From Anycast RP: No
Rpf Neighbor
: 172.16.253.254
Incoming Intf
: int-ce3-pe3
Outgoing Intf List : RX-B
Curr Fwding Rate
: 16.8 kbps
Forwarded Packets : 3920
Discarded Packets : 0
Forwarded Octets
: 164640
RPF Mismatches
: 0
Spt threshold
: 0 kbps
ECMP opt threshold : 7
Admin bandwidth
: 1 kbps
------------------------------------------------------------------------------Groups : 1
===============================================================================
A:CE-3#

The join is received by CE-1, which contains the subnet of the source.
CE-1 now recognizes the multicast group as a valid stream. This becomes the root of the shortest
path tree for the group.
A:CE-1# show router 1 pim group
===============================================================================
PIM Groups ipv4
===============================================================================
Group Address
Type
Spt Bit Inc Intf
No.Oifs
Source Address
RP
------------------------------------------------------------------------------225.0.0.1
(S,G)
spt
to-source
1
192.168.1.2
------------------------------------------------------------------------------Groups : 1
===============================================================================
A:CE-1#

Advanced Configuration Guide

Page 1187

Configuration

PIM Source-Specific Multicasting


There is no requirement for an RP, as customer multicast signaling will be PIM-SSM. The
Multicast group address used for the PMSI must be the same on all PEs for this VPRN instance.

Multicast
Receiver A

Multicast Source
232.0.0.1

.2

AS 64497
CE1

192.1.1.0/24
.1

PE1

AS 64498

PE2

172.16.255.252/30
.253

172.16.254.252/30

.254 vprn1

192.0.2.1 192.0.2.2 vprn1

.254

CE2

.253

.2
192.168.2.0/24
.1

AS 64496

192.168.3.0/24

CE3

.1
.2

Multicast
Receiver B

172.16.253.252/30
.253

.254

vprn1
PE3

192.0.2.3 192.0.2.4

vprn1

172.16.252.252/30
.254

.253

CE4

192.168.4.0/24
.1

Multicast
Receiver C

PE4

AS 64499

AS 64500
OSSG463

Figure 89: PIM SSM in Customer Signaling Plane

The following output shows the VPRN configuration for PIM and MVPN for PE-1.
A:PE-1#configure service vprn 1
pim
interface "int-pe1-ce1"
exit
mvpn
provider-tunnel
inclusive
pim asm 239.255.255.1
exit
exit
exit
exit
no shutdown

Page 1188

Advanced Configuration Guide

Multicast in a VPN I

There is a similar configuration required for each of the other PEs. Verify that PIM in the Global
routing table (GRT) has signalled the I-PMSIs.
For the PE acting as the RP for global PIM:
A:PE-1# show router pim group
===============================================================================
PIM Groups ipv4
===============================================================================
Group Address
Type
Spt Bit Inc Intf
No.Oifs
Source Address
RP
------------------------------------------------------------------------------239.255.255.1
(*,G)
3
*
192.0.2.1
239.255.255.1
(S,G)
spt
system
3
192.0.2.1
192.0.2.1
239.255.255.1
(S,G)
spt
int-pe1-pe2
2
192.0.2.2
192.0.2.1
239.255.255.1
(S,G)
spt
int-pe1-pe3
2
192.0.2.3
192.0.2.1
------------------------------------------------------------------------------Groups : 4
===============================================================================
A:PE-1#

All other PEs will have:


A:PE-2# show router pim group
===============================================================================
PIM Groups ipv4
===============================================================================
Group Address
Type
Spt Bit Inc Intf
No.Oifs
Source Address
RP
------------------------------------------------------------------------------239.255.255.1
(*,G)
int-pe2-pe1
1
*
192.0.2.1
239.255.255.1
(S,G)
spt
system
2
192.0.2.2
192.0.2.1
------------------------------------------------------------------------------Groups : 2
===============================================================================
A:PE-2#

This shows a (S,G) join towards the RP at 192.0.2.1, plus a (*,G) join from RP. These represent
the outgoing and incoming PIM interfaces for the VRF.
This results in a series of PIM neighbors through the I-PMSIs within the VRF, which are
maintained using PIM hellos.
A:PE-1# show router 1 pim neighbor
===============================================================================
PIM Neighbor ipv4
===============================================================================
Interface
Nbr DR Prty
Up Time
Expiry Time
Hold Time

Advanced Configuration Guide

Page 1189

Configuration

Nbr Address
------------------------------------------------------------------------------int-pe1-ce1
1
1d 02:07:04
0d 00:01:35
105
172.16.255.253
1-mt-239.255.255.1
1
2d 00:37:32
0d 00:01:23
105
192.0.2.2
1-mt-239.255.255.1
1
2d 00:37:12
0d 00:01:31
105
192.0.2.3
------------------------------------------------------------------------------Neighbors : 3
===============================================================================
A:PE-1#

PIM SSM Customer Edge Router Multicast Configuration


Each CE router will have a PIM neighbor peer relationship with its nearest PE.
The CE router (CE-1) containing the source will have PIM enabled on the interface connected to
the source.
A:CE-1# configure service vprn 1
autonomous-system 64497
route-distinguisher 64497:1
interface "int-ce1-pe1" create
address 172.16.255.253/30
sap 1/1/1:1 create
exit
exit
interface "to-source" create
address 192.168.1.1/24
sap 1/1/3:1 create
exit
exit
pim
interface "int-ce1-pe1"
exit
interface "to-source"
exit
no shutdown

Page 1190

Advanced Configuration Guide

Multicast in a VPN I

The CE containing the receivers will have IGMP enabled on the interface connected to the
receivers and PIM on the interface facing the PE.
A:CE-2# configure service vprn 1
autonomous-system 64498
route-distinguisher 64498:1
interface "RX-A" create
address 192.2.1.1/24
sap 1/1/4:1 create
exit
exit
interface "int-ce2-pe2" create
address 172.16.254.253/30
sap 1/1/1:1 create
exit
exit
static-route 192.168.1.0/24 next-hop 172.16.254.254
igmp
interface "RX-A"
exit
exit
pim
interface "int-ce2-pe2"
exit
no shutdown

Advanced Configuration Guide

Page 1191

Configuration

Traffic Flow
The source multicasts a stream towards CE-1. As there is no receiver interested in the group at this
time, there are no outgoing interfaces, so the Outgoing Interface List (OIL) is empty.
A:CE-1# show router 1 pim group
===============================================================================
PIM Groups ipv4
===============================================================================
Group Address
Type
Spt Bit Inc Intf
No.Oifs
Source Address
RP
------------------------------------------------------------------------------232.0.0.1
(S,G)
to-104/1
0
192.168.1.2
------------------------------------------------------------------------------Groups : 1
================================================================================
A:CE-1#

The receiver A, wishes to join the group 232.0.0.1, and so sends in an IGMPv3 report towards CE2. CE-2 recognizes the report, which contains the source 192.168.1.2 in the INCLUDE filter list.
A:CE-2# show router 1 igmp group
===============================================================================
IGMP Groups
===============================================================================
(192.168.1.2,232.0.0.1)
Up Time : 0d 00:00:33
Fwd List : to-104/2
------------------------------------------------------------------------------(*,G)/(S,G) Entries : 1
===============================================================================
A:CE-2#

CE-2 does a RPF lookup of the source address in the route table, and issues a PIM join towards the
source.
The join is propagated across the provider network, towards PE-1 which is the resolved RPF next
hop for the source.
A:PE-1# show router 1 pim group detail
===============================================================================
PIM Source Group ipv4
===============================================================================
Group Address
: 232.0.0.1
Source Address
: 192.168.1.2
RP Address
: 172.16.254.254
Flags
: spt
Type
: (S,G)
MRIB Next Hop
: 172.16.255.253
MRIB Src Flags
: remote
Keepalive Timer Exp: 0d 00:01:43
Up Time
: 0d 00:08:47
Resolved By
: rtable-u
Up JP State
Up JP Rpt

Page 1192

: Joined
: Not Joined StarG

Up JP Expiry
: 0d 00:00:13
Up JP Rpt Override : 0d 00:00:00

Advanced Configuration Guide

Multicast in a VPN I

Register State
: No Info
Reg From Anycast RP: No
Rpf Neighbor
: 172.16.255.253
Incoming Intf
: int-pe1-ce1
Outgoing Intf List : 1-mt-239.255.255.1
Curr Fwding Rate
: 33.6 kbps
Forwarded Packets : 52214
Discarded Packets : 0
Forwarded Octets
: 2192988
RPF Mismatches
: 0
Spt threshold
: 0 kbps
ECMP opt threshold : 7
Admin bandwidth
: 1 kbps
------------------------------------------------------------------------------Groups : 1

Note that the outgoing interface is the I-PMSI.


The join is received by CE-1, which contains the subnet of the source.
CE-1 now recognizes the multicast group as a valid stream. This becomes the root of the shortest
path tree for the group.
A:CE-1# show router 1 pim group
===============================================================================
PIM Groups ipv4
===============================================================================
Group Address
Type
Spt Bit Inc Intf
No.Oifs
Source Address
RP
------------------------------------------------------------------------------232.0.0.1
(S,G)
spt
to-source
1
192.168.1.2
------------------------------------------------------------------------------Groups : 1
===============================================================================
A:CE-1#

Advanced Configuration Guide

Page 1193

Configuration

PE BGP Auto-Discovery
Discovery of multicast-enabled Virtual Private Networks (MVPNs) can also be achieved using
BGP. To this end, any PE that is a member of a Multicast VPN will advertise this using a BGP
Multi-protocol Reachable Next-Hop Router Layer Information (NRLI) update that is sent to all
PEs within the AS. This update will contain an Intra-AS I-PMSI auto-discovery Route type, also
known as an Intra-AD. These use an address family, mvpn-ipv4, so each PE must be configured to
originate and accept such updates.
This is achieved in the global routing table within the BGP context.
A:PE-1#configure router bgp
group "internal"
family vpn-ipv4 mvpn-ipv4
peer-as 64496
neighbor 192.0.2.2
exit
neighbor 192.0.2.3
exit
neighbor 192.0.2.4
exit
exit

This allows each BGP speaker to advertise its capabilities within a BGP Open message.
When the peers become established, the address family capabilities should look like the following:
A:PE-1# show router bgp summary
===============================================================================
BGP Router ID:192.0.2.1
AS:64496
Local AS:64496
===============================================================================
BGP Admin State
: Up
BGP Oper State
: Up
Total Peer Groups
: 1
Total Peers
: 3
Total BGP Paths
: 15
Total Path Memory
: 1932
Total IPv4 Remote Rts
: 0
Total IPv4 Rem. Active Rts : 0
Total IPv6 Remote Rts
: 0
Total IPv6 Rem. Active Rts : 0
Total Supressed Rts
: 0
Total Hist. Rts
: 0
Total Decay Rts
: 0
Total VPN Peer Groups
: 1
Total VPN Peers
: 1
Total VPN Local Rts
: 2
Total VPN-IPv4 Rem. Rts : 7
Total VPN-IPv4 Rem. Act. Rts: 6
Total VPN-IPv6 Rem. Rts : 0
Total VPN-IPv6 Rem. Act. Rts: 0
Total L2-VPN Rem. Rts
: 0
Total L2VPN Rem. Act. Rts
: 0
Total VPN Supp. Rts
: 0
Total VPN Hist. Rts
: 0
Total VPN Decay Rts
: 0
Total MVPN-IPv4 Rem Rts : 3
Total MVPN-IPv4 Rem Act Rts : 3
===============================================================================
BGP Summary
===============================================================================
Neighbor
AS PktRcvd InQ Up/Down
State|Rcv/Act/Sent (Addr Family)
PktSent OutQ

Page 1194

Advanced Configuration Guide

Multicast in a VPN I

------------------------------------------------------------------------------192.0.2.2
64496
26629
0 07d01h59m 3/3/1 (VpnIPv4)
26737
0
1/1/1 (MvpnIpv4)
192.0.2.3
64496
26647
0 07d01h59m 3/2/1 (VpnIPv4)
26728
0
1/1/1 (MvpnIpv4)
192.0.2.4
64496
26632
0 07d01h59m 1/1/1 (VpnIPv4)
26685
0
1/1/1 (MvpnIpv4)
===============================================================================
A:PE-1#

Advanced Configuration Guide

Page 1195

Configuration

BGP Auto-Discovery PE VPRN Multicast Configuration


As each PE contains a CE which will be part of the multicast VRF, it is necessary to enable PIM
on each interface containing an attachment circuit towards a CE, and to configure the I-PMSI
multicast tunnel for the VRF.
In order for the BGP routes to be accepted into the VRF, a route-target community is required (vrftarget). This is configured in the configure service vprn 1 mvpn context and, in this case, is set to
the same value as the unicast vrf-target, the vrf-target community as the configure service vprn 1
vrf-target context.
On each PE, A VPRN instance is configured as follows
A:PE-2# configure service vprn 1
autonomous-system 64496
route-distinguisher 64496:1
auto-bind ldp
vrf-target target:64496:1
interface "int-pe2-ce2" create
address 172.16.254.254/30
sap 1/1/3:1 create
exit
exit
pim
interface "int-pe2-ce2"
exit
mvpn
auto-discovery
provider-tunnel
inclusive
pim asm 239.255.255.1
exit
exit
exit
vrf-target unicast
exit
exit
no shutdown

The multicast group address used for the PMSI must be the same on all PEs for this VPRN
instance.
The presence of auto-discovery will initiate BGP updates between the PEs that contain an MVPN,
such as Intra-AD MVPN routes, are generated and advertised to each peer
A:PE-1# show router bgp routes mvpn-ipv4
===============================================================================
BGP Router ID:192.0.2.1
AS:64496
Local AS:64496
===============================================================================
Legend Status codes : u - used, s - suppressed, h - history, d - decayed, * - valid
Origin codes : i - IGP, e - EGP, ? - incomplete, > - best
===============================================================================

Page 1196

Advanced Configuration Guide

Multicast in a VPN I

BGP MVPN-IPv4 Routes


===============================================================================
Flag RouteType
OriginatorIP
LocalPref
MED
RD
SourceAS
VPNLabel
Nexthop
SourceIP
As-Path
GroupIP
------------------------------------------------------------------------------u*>i Intra-Ad
192.0.2.2
100
0
64496:1
192.0.2.2
No As-Path
u*>i Intra-Ad
192.0.2.3
100
0
64496:1
192.0.2.3
No As-Path
u*>i Intra-Ad
192.0.2.4
100
0
64496:1
192.0.2.4
No As-Path
------------------------------------------------------------------------------Routes : 3
===============================================================================
*A:PE-1#

This shows that PE-1 has received an Intra-AD route from each of the other PEs, each of which
has multicast VPRN 1 configured.
Examining one of the Intra-AD routes from PE-2 shows that the route-target community matches
the unicast VRF-target (64496:1), and also that the PMSI tree has a multicast group address of
239.255.255.1, which matches the I-PMSI group configuration on PE-1.

Advanced Configuration Guide

Page 1197

Configuration

A:PE-1# show router bgp routes mvpn-ipv4 type intra-ad originator-ip 192.0.2.2 detail
===============================================================================
BGP Router ID:192.0.2.1
AS:64496
Local AS:64496
===============================================================================
Legend Status codes : u - used, s - suppressed, h - history, d - decayed, * - valid
Origin codes : i - IGP, e - EGP, ? - incomplete, > - best
===============================================================================
BGP MVPN-IPv4 Routes
===============================================================================
Route Type
: Intra-Ad
Route Dist.
: 64496:1
Originator IP : 192.0.2.2
Nexthop
: 192.0.2.2
From
: 192.0.2.2
Res. Nexthop
: 0.0.0.0
Local Pref.
: 100
Interface Name : NotAvailable
Aggregator AS : None
Aggregator
: None
Atomic Aggr.
: Not Atomic
MED
: 0
Community
: target:64496:1
Cluster
: No Cluster Members
Originator Id : None
Peer Router Id : 192.0.2.2
Flags
: Used Valid Best IGP
AS-Path
: No As-Path
------------------------------------------------------------------------------PMSI Tunnel Attribute :
Tunnel-type
: PIM-SM Tree
Flags
: Local Info not Required
MPLS Label
: 0x0
Sender
: 192.0.2.2
P-Group
: 239.255.255.1
------------------------------------------------------------------------------------------------------------------------------------------------------------Routes : 1
===============================================================================
A:PE-1#

Verify that PIM in the global routing table (GRT) has signalled the I-PMSIs.
For the PE acting as the RP for global PIM:
A:PE-1# show router pim group
===============================================================================
PIM Groups ipv4
===============================================================================
Group Address
Type
Spt Bit Inc Intf
No.Oifs
Source Address
RP
------------------------------------------------------------------------------239.255.255.1
(*,G)
3
*
192.0.2.1
239.255.255.1
(S,G)
spt
system
3
192.0.2.1
192.0.2.1
239.255.255.1
(S,G)
spt
int-pe1-pe2
2
192.0.2.2
192.0.2.1
239.255.255.1
(S,G)
spt
int-pe1-pe3
2
192.0.2.3
192.0.2.1
------------------------------------------------------------------------------Groups : 4
===============================================================================

Page 1198

Advanced Configuration Guide

Multicast in a VPN I

A:PE-1#

This shows an incoming (S,G) join from all other PEs within the multicast VRF, plus an outgoing
(*,G) join to the same PEs.
All other PEs will have the following PIM groups
A:PE-2# show router pim group
===============================================================================
PIM Groups ipv4
===============================================================================
Group Address
Type
Spt Bit Inc Intf
No.Oifs
Source Address
RP
------------------------------------------------------------------------------239.255.255.1
(*,G)
int-pe2-pe1
1
*
192.0.2.1
239.255.255.1
(S,G)
spt
system
2
192.0.2.2
192.0.2.1
------------------------------------------------------------------------------Groups : 2
===============================================================================
A:PE-2#

This shows a (S,G) join towards the RP at 192.0.2.1, plus a (*,G) join from RP. These represent
the outgoing and incoming PIM interfaces for the VRF.
This results in a series of PIM neighbors through the I-PMSIs within the VRF. As the neighbors
were discovered using BGP (rather than with PIM as per Draft-Rosen), there are no PIM hellos
exchanged.
A:PE-1# show router 1 pim neighbor
===============================================================================
PIM Neighbor ipv4
===============================================================================
Interface
Nbr DR Prty
Up Time
Expiry Time
Hold Time
Nbr Address
------------------------------------------------------------------------------int-pe1-ce1
1
1d 01:18:59
0d 00:01:24
105
172.16.255.253
1-mt-239.255.255.1
1
1d 01:18:22
never
65535
192.0.2.2
1-mt-239.255.255.1
1
1d 01:18:59
never
65535
192.0.2.3
1-mt-239.255.255.1
1
1d 01:18:59
never
65535
192.0.2.4
------------------------------------------------------------------------------Neighbors : 4
===============================================================================
*A:PE-1#

Advanced Configuration Guide

Page 1199

Configuration

BGP Auto-Discovery Customer Signaling Domain


As the customer signaling is independent from the provider PE discovery mechanism, all of the
customer signaling techniques described when using PIM for auto-discovery within provider
domain are also applicable when using BGP for auto-discovery, namely

Page 1200

PIM Any Source Multicasting with RP at the provider PE

PIM Any Source Multicasting with Anycast RP at the provider PE

PIM Source Specific Multicasting

Advanced Configuration Guide

Multicast in a VPN I

Data Path Using Selective PMSI


When a configurable data threshold for a multicast group has been exceeded, multicast traffic
across the Provider network can be switched to a selective PMSI (S-PMSI).
This has to be configured as a separate group and must contain a threshold which, if exceeded, will
see a new PMSI signalled by the PE nearest the source, and traffic switched onto the S-PMSI.
*A:PE-1# configure service vprn 1
mvpn
provider-tunnel
inclusive
pim asm 239.255.255.1
exit
exit
selective
data-threshold 232.0.0.0/8 1
pim-ssm 232.255.1.0/24
exit
exit
exit
no shutdown

This shows that when the traffic threshold for multicast groups covered by the range 232.0.0.0/8
exceeds 1kbps between a pair of PEs, then an S-PMSI is signalled between the PEs. This is a
separate multicast tunnel over which traffic in the given group now flows.
*A:PE-1# show router 1 pim s-pmsi detail
===============================================================================
PIM Selective provider tunnels
===============================================================================
Md Source Address : 192.0.2.1
Md Group Address
: 232.255.1.14
Number of VPN SGs : 1
Uptime
: 0d 00:00:12
MT IfIndex
: 16395
VPN Group Address : 232.0.0.1
VPN Source Address : 192.168.1.2
State
: TX Joined
Mdt Threshold
: 1
Join Timer
: 0d 00:00:47
Holddown Timer
: 0d 00:00:47
===============================================================================
PIM Selective provider tunnels Interfaces : 1
===============================================================================
*A:PE-1#

In this example, the (S,G) group is (192.168.1.2, 225.0.0.1). As the data rate has exceeded the
configured MDT threshold of 1kbps, a new provider tunnel with a group address of 232.255.1.14
has been signalled and now carries the multicast stream.

Advanced Configuration Guide

Page 1201

Configuration

The TX Joined state indicates that the S-PMSI has been sourced at this PE PE-1.
Comparing this to PE-3, where a receiver is connected through a CE indicates that it has received
a join to connect the S-PMSI.
*A:PE-3# show router 1 pim s-pmsi detail
===============================================================================
PIM Selective provider tunnels
===============================================================================
Md Source Address : 192.0.2.1
Md Group Address
: 232.255.1.14
Number of VPN SGs : 1
Uptime
: 0d 00:05:13
MT IfIndex
: 24576
Egress Fwding Rate : 52.8 kbps
VPN Group Address : 232.0.0.1
VPN Source Address : 192.168.1.2
State
: RX Joined
Expiry Timer
: 0d 00:02:31
===============================================================================
PIM Selective provider tunnels Interfaces : 1
...
===============================================================================
*A:PE-3#

Page 1202

Advanced Configuration Guide

Multicast in a VPN I

Conclusion
This note provides configuration on how to configure multicast within a VPRN with next
generation multicast VPN techniques. Specifically, discovery of multicast VPNs using PIM and
BGP auto-discovery mechanisms are describer with a number of ASM and SSM signaling
techniques within the customer domain.

Advanced Configuration Guide

Page 1203

Conclusion

Page 1204

Advanced Configuration Guide

Multicast in a VPN II

In This Chapter
This section provides information about multicast in a VPRN service.
Topics in this section include:

Applicability on page 1206

Summary on page 1207

Overview on page 1209

Configuration on page 1211

Conclusion on page 1260

Advanced Configuration Guide

Page 1205

Applicability

Applicability
This section is applicable to all 7750 SR platforms and to 7450 ESS platforms when configured in
mixed-mode. It was tested on release 9.0R5. The features are supported with IOM2, IOM3-XP
and IMMs, and need chassis mode C or higher. There are no other pre-requisites for this
configuration.

Page 1206

Advanced Configuration Guide

Multicast in a VPN II

Summary
Multicast VPN (MVPN) or Next Generation IP Multicast in an IP-VPN (NG-MVPNs)
architectures describe a set of VRFs (Virtual Routing and Forwarding) or VPRNs (Virtual Private
Routed Networks) that support the transport of multicast traffic across a provider network.
MVPNs are defined in draft-ietf-l3vpn-2547bis-mcast-10.txt, Multicast in MPLS/BGP IP VPNs,
and in draft-ietf-l3vpn-2547bis-mcast-bgp-08.txt, BGP Encodings and Procedures for Multicast
in MPLS/BGP IP VPN.
Initial MVPN deployments were originally based on Draft-Rosen (draft-rosen-vpn-mcast-08.txt)
which described the protocols and procedures required to support an IP Multicast VPN. There are
a number of limitations with the Draft-Rosen implementation including, but not limited to:

Draft-Rosen requires a set of multicast distribution trees (MDTs) per VPN, which requires
a PIM state per MDT. There is no option to aggregate MDT across multiple VPNs

Customer signaling, initially PE discovery and Data MDT signaling, were all PIM-based
as there was no mechanism available to decouple these. Now, PE discovery is supported
using a BGP MDT Address Family Identifier/Subsequent Address Family Identifier (AFI/
SAFI), however, the data MDT still needs PIM.

There is no mechanism for using MPLS to encapsulate multicast traffic in the VPN. GRE
is the only encapsulation method available in Draft-Rosen.

Draft-Rosen multicast trees are signaled using PIM only. MVPN allows the use of mLDP
and RSVP P2MP LSPs.

PE to PE protocol exchanges for Draft-Rosen is achieved using PIM only. MVPN allows
for the use of BGP signaling as per unicast Layer 3 VPNs.

NG-MVPN addresses these limitations by extending the idea of the per-VRF tree by introducing
the idea of Provider Multicast Service Interfaces (PMSIs). These are equivalent to the default
MDTs of Draft-Rosen. NG-MVPN allows the decoupling of the mechanisms required to create a
multicast VPN, such as PE auto-discovery (which PEs are members of which VPN), PMSI
signaling (creation of tunnels between PEs) and customer multicast signaling (multicast signaling
IGMP/PIM received from customer edge routers). Two types of PMSI exist:

Inclusive (I-PMSI) Contains all the PEs for a given MVPN, I-PMSI is the default
multicast data path between all PEs of the same VPN.

Selective (S-PMSI) Contains only a subset of PEs of a given MVPN, used to optimize
multicast stream distribution to only the PEs with active receivers for those streams.

The Multicast in a VPN Isection onpage 1147 contains the VPN configuration required for the
provider multicast domain using PIM Any Source Multicast (ASM) with auto-discovery based on
PIM or BGP auto-discovery (A/D), PIM used for the customer multicast signaling and PIM
Source Specific Multicast (SSM) used for the S-PMSI creation. The customer domain
configuration covers the following cases:

Advanced Configuration Guide

Page 1207

Summary

PIM ASM with the Rendezvous Point (RP) in the provider PE

PIM ASM using anycast RP on the provider RPs

PIM SSM

This section introduces some of the features that were not supported at the time of writing of the
Multicast in a VPRN I (Release 7.0). It provides configuration details to implement:

Multicast LDP (mLDP) and RSVP-TE Point to Multipoint (P2MP) for building customer
trees (C-trees) which are using MPLS instead of PIM techniques.

MVPN source redundancy.

MDT AFI/SAFI (to fully interoperate with Cisco networks).

Note that PIM SSM is the only case addressed in this example, other PIM customer domain
configurations are out of the scope, for more information refer to Multicast in a VPN I on page
1147

Page 1208

Advanced Configuration Guide

Multicast in a VPN II

Overview
The network topology is displayed in Figure 90. The setup consists of four 7750 SRs acting as
Provider Edge (PE) routers within a single Autonomous System (AS).

Full mesh ISIS in the AS (OSPF could be used instead)

LDP on all interfaces in each AS (RSVP could be used instead)

MP-iBGP sessions between the PE routers in the AS (Route Reflectors (RRs) could also
be used).

Layer 3 VPN on all PEs with identical route targets, in the form AS-number: vprn-serviceid

Connected to each PE is a single 7750 SR acting as a Customer Edge (CE) router. CE-1 has a
multicast source connected, and PEs 2 to 4 each have a single receiver connected which will
receive the multicast streams from the source. In this setup, each receiver is IGMPv3 capable. If
the receiver is IGMPv3 capable, it will issue IGMPv3 reports that may include a list of required
source addresses.
System IP: 192.0.2.1/32

System IP: 192.0.2.3/32

PE-1

PE-3

System IP: 192.0.2.11/32

CE-1

192.168.13.0/30
1/1/3

1/1/1
.1

CE-3

.2

.1

Source

System IP: 192.0.2.13/32


1/1/1

Receiver

.1
192.168.12.0/30

192.168.34.0/30

AS 64496
1/1/2
.2

System IP: 192.0.2.12/32

CE-2

1/1/2
.2
192.168.24.0/30
1/1/3

1/1/1
.1

Receiver

PE-2
System IP: 192.0.2.2/32

System IP: 192.0.2.14/32


1/1/1

CE-4

.2

PE-4

Receiver

System IP: 192.0.2.4/32


MVPNII_01

Figure 90: Network Topology

When the receiver wishes to become a member of any group, the source address of the group must
be known to the CE. As a result the source address must be IP reachable by each CE, so it is
advertised by CE-1 to the PEs with attachment circuits in VPRN using BGP. Static routes are then
configured on the receiver CEs to achieve IP reachability to the source address of the multicast
group.

Advanced Configuration Guide

Page 1209

Overview

Multicast traffic from the source is streamed towards router CE-1. Receivers connected to PE-2,
PE-3 and PE-4 are interested in joining this multicast group.
CEs 1 to 4 are PIM enabled routers, which form a PIM adjacency with nearest PE. Between the
PEs across the provider network there are no PIM adjacencies since BGP auto-discovery and BGP
signalling are used. Selective PMSI using mLDP or RSVP P2MP are out of the scope of this
section. Selective PMSI using PIM SSM is supported but cannot be used when I-PMSI is mLDP
or RSVP with R9.0. I-PMSI and S-PMSI must use same tunnelling technology, either PIM/GRE
or mLDP or RSVP P2MP.

Page 1210

Advanced Configuration Guide

Multicast in a VPN II

Configuration
The configuration is divided into the following sections:

Provider Common Configuration


PE Global Configuration

PE VPRN Configuration and PE VPRN Multicast Configuration for NG-MVPN


PMSI using mLDP
PMSI using RSVP-TE
UMH (Upstream Multicast Hop)

PE VPRN Configuration and PE VPRN Multicast Configuration for Draft-Rosen using


MDT AFI SAFI
Auto discovery using BGP MDT AFI SAFI as per Draft-Rosen version 9 with MDT
using PIM SSM

Provider Common Configuration


PE Global Configuration
This section describes the common configuration required for each PE within the provider
multicast domain, regardless of the MVPN PE auto-discovery or customer signaling methods.
This includes Interior Gateway Protocol (IGP) and VPRN service configuration.
The configuration tasks can be summarized as follows:

PE global configuration.
This includes configuration of the IGP (ISIS will be used); configuration of link layer
LDP between PEs (LDP will be used here as the method to interconnect VPRNs);
configuration of iBGP between PEs to facilitate VPRN route learning.

VPRN configuration on the PEs.


This includes configuration of basic VPRN parameters (route-distinguisher, route target
communities), configuration of attachment circuits towards CEs, configuration of VRF
routing protocol and any routing policies.

PIM within the VRF and MVPN parameters I-PMSI

CE configuration.

Advanced Configuration Guide

Page 1211

Configuration

Step 1. Configure the interfaces, the IGP (ISIS) in all PE nodes (where ISIS redistributes route

reachability to all routers) and LDP in the interfaces (link layer LDP). To facilitate the ISIS
configuration, all routers are Level2-Level1 capable within the same ISIS area-id, so there
is only a single topology area in the network (all routers share the same topology). The
configuration for PE-2 is displayed below.
PE-2>configure router
interface "int-PE-2-PE-1"
address 192.168.12.2/30
port 1/1/2:1
exit
interface "int-PE-2-PE-4"
address 192.168.24.1/30
port 1/1/3:1
exit
interface "system"
address 192.0.2.2/32
exit
autonomous-system 64496
isis
area-id 49.0001
traffic-engineering
interface "system"
passive
exit
interface "int-PE-2-PE-1"
interface-type point-to-point
exit
interface "int-PE-2-PE-4"
interface-type point-to-point
exit
no shutdown
exit
ldp
interface-parameters
interface "int-PE-2-PE-1"
exit
interface "int-PE-2-PE-4"
exit
exit
targeted-session
exit

The configuration for the rest of nodes is similar. The IP addresses can be derived from Figure 90.

Page 1212

Advanced Configuration Guide

Multicast in a VPN II

Step 2. Verify that ISIS adjacencies and LDP peer sessions are formed.
*A:PE-1# show router isis adjacency
===============================================================================
ISIS Adjacency
===============================================================================
System ID
Usage State Hold Interface
MT Enab
------------------------------------------------------------------------------PE-2
L1L2 Up
30
int-PE-1-PE-2
No
PE-3
L1L2 Up
24
int-PE-1-PE-3
No
------------------------------------------------------------------------------Adjacencies : 2
===============================================================================
*A:PE-1# show router ldp session
==============================================================================
LDP Sessions
==============================================================================
Peer LDP Id
Adj Type
State
Msg Sent Msg Recv Up Time
-----------------------------------------------------------------------------192.0.2.2:0
Both
Established
235
237
0d 00:08:57
192.0.2.3:0
Both
Established
237
245
0d 00:08:58
-----------------------------------------------------------------------------No. of Sessions: 2

Advanced Configuration Guide

Page 1213

Configuration

Step 3. Configure iBGP full mesh between the PEs for VPRN routing (Route Reflectors could

also be an option).
*A:PE-1>config>router>bgp# info
---------------------------------------------min-route-advertisement 1
rapid-withdrawal
rapid-update mvpn-ipv4 mdt-safi
group "internal"
family vpn-ipv4 mvpn-ipv4 mdt-safi
type internal
neighbor 192.0.2.2
exit
neighbor 192.0.2.3
exit
neighbor 192.0.2.4
exit
exit
no shutdown
----------------------------------------------

Note that the families configured under the group internal are vpn-ipv4, mvpn-ipv4 and mdt-safi,
since the three families are referenced in this chapter.
Note that the mdt-safi parameter is not needed for NG-MVPN (mLDP/RSVP scenarios) and is
only required for Draft-Rosen with MDT AFI SAFI.
Rapid withdrawal (configured on all PEs) disables the Minimum Route Advertisement Interval
(MRAI) interval on sending BGP withdrawals. Rapid update (configured for MVPN-IPv4 and
MDT AFI/SAFI address families) disables the MRAI interval on sending BGP update messages
for the address family MVPN-IPv4 and MDT AFI/SAFI).
Step 4. Verify that BGP peer relationships are established.
*A:PE-1# show router bgp summary
===============================================================================
BGP Router ID:192.0.2.1
AS:64496
Local AS:64496
===============================================================================
BGP Admin State
: Up
BGP Oper State
: Up
Total Peer Groups
: 1
Total Peers
: 3
* Truncated info
===============================================================================
BGP Summary
===============================================================================
Neighbor
AS PktRcvd InQ Up/Down
State|Rcv/Act/Sent (Addr Family)
PktSent OutQ
------------------------------------------------------------------------------192.0.2.2
64496
28
0 00h12m04s 4/4/3 (VpnIPv4)
29
0
1/1/1 (MvpnIpv4)
0/0/0 (MdtSafi)
192.0.2.3
64496
27
0 00h12m11s 2/2/3 (VpnIPv4)

Page 1214

Advanced Configuration Guide

Multicast in a VPN II

30

1/1/1 (MvpnIpv4)
0/0/0 (MdtSafi)

192.0.2.4
64496

0 00h12m04s 2/2/3 (VpnIPv4)


0
2/2/1 (MvpnIpv4)
0/0/0 (MdtSafi)
-------------------------------------------------------------------------------

Advanced Configuration Guide

30
29

Page 1215

Configuration

PE VPRN Configuration and PE VPRN Multicast Configuration


A VPRN is created on each PE per service (the different services using mLDP, RSVP-TE and
AFI/SAFI with PIM), these are the multicast VPRNs. PE-1 is the PE containing the attachment
circuit towards CE-1. CE-1 is the CE nearest to the source. PE-2, PE-3 and PE-4 contain
attachment circuits towards CE-2, CE-3 and CE-4 respectively. Each CE has a receiving host
attached.

PMSI using mLDP


Figure 91 shows the details of the topology for VPRN 1.

192.168.1.1/24

AS 64499

CE-1
VPRN1

.2

PE-1

PE-3

Loopback: 172.16.1.1/32

Loopback: 172.16.1.3/32

1/1/1:1
172.16.11.0/30
e-BGP

.1

VPRN1

1/1/3

.1

Source

1/1/2

AS 64402

CE-2

RX-2

.1

VPRN1

VPRN1

.2

1/1/1:1
172.16.33.0/30
.1

STATIC

STATIC

CE-3
.2

VPRN1

.1

AS 64496

VPRN1

.1

Loopback: 172.16.1.2/32

1/1/1:1
172.16.44.0/30

VPRN1

1/1/3

PE-2

RX-3

1/1/2

.2
1/1/1:1
172.16.22.0/30

AS 64403

.1

PE-4

STATIC

AS 64404

CE-4
.2

VPRN1

RX-4

Loopback: 172.16.1.4/32
MVPNII_02

Figure 91: VPRN 1 Topology used for mLDP

Page 1216

Advanced Configuration Guide

Multicast in a VPN II

Unicast
Step 1. Create VPRN 1 on each PE, containing a route-distinguisher of 64496:10X (where X=

number of PE) and vrf-target of 64496:100. The autonomous system number is 64496. For
the next hop tunnel route resolution to connect the VPRNs between PEs, manually
configured spoke SDPs are created (note that other methods like auto-bind LDP, RSVP-TE
or auto-bind MPLS could also be used). LDP was already enabled in the overview section.
*A:PE-1>config>service# info
---------------------------------------------customer 1 create
description "Default customer"
exit
sdp 12 mpls create
far-end 192.0.2.2
ldp
keep-alive
shutdown
exit
no shutdown
exit
sdp 13 mpls create
far-end 192.0.2.3
ldp
keep-alive
shutdown
exit
no shutdown
exit
sdp 14 mpls create
far-end 192.0.2.4
ldp
keep-alive
shutdown
exit
no shutdown
exit
vprn 1 customer 1 create
description "mLDP"
autonomous-system 64496
route-distinguisher 64496:101
vrf-target target:64496:100
spoke-sdp 12 create
no shutdown
exit
spoke-sdp 13 create
no shutdown
exit
spoke-sdp 14 create
no shutdown
exit

Advanced Configuration Guide

Page 1217

Configuration

Step 2. Create an attachment circuit interface towards the CE and a loopback (the loopback is

not mandatory but it is configured to aid troubleshooting the routers).


PE-1>configure service vprn 1
interface "loopback" create
address 172.16.1.1/32
loopback
exit
interface "int-PE-1-CE-1" create
address 172.16.11.1/30
sap 1/1/1:1 create
exit
exit

Step 3. The source address of the multicast stream will need to be reachable by all routers

(PEs and CEs) within the VPN. This will be advertised within BGP from CE-1 to PE-1.
Create a BGP peering relationship with the CE.
PE-1>configure service vprn 1
bgp
group "external"
type external
peer-as 64499
neighbor 172.16.11.2
exit
exit
no shutdown
exit

Step 4. On CE-1, create a VPRN to support the connection of the source to CE-1 and to

connect CE-1 to PE-1. Two attachment circuits are required as well as a BGP peering
relationship with the PE. This uses a default BGP address family of ipv4.
A:CE-1>config>service>vprn# info
---------------------------------------------autonomous-system 64499
route-distinguisher 64499:1
interface "int-CE-1-PE-1" create
*Truncated info
interface "source" create
*Truncated info
exit
bgp
export "source"
group "external"
type external
peer-as 64496
neighbor 172.16.11.1
exit
exit
no shutdown
exit
no shutdown
----------------------------------------------

Page 1218

Advanced Configuration Guide

Multicast in a VPN II

Step 5. In order for the subnet on the CE connecting to the source to be advertised within

BGP, a route policy is required. The subnet containing the multicast source is 192.168.1.0/
24, so a prefix-list can be used to define a match, and then used within a route policy to
inject into BGP. In this example, only the host (/32) of the source is advertised.
A:CE-1>config>router# info
* Truncated info
policy-options
begin
prefix-list "source"
prefix 192.168.1.1/32 exact
exit
policy-statement "source"
entry 10
from
prefix-list "source"
exit
to
protocol bgp
exit
action accept
exit
exit
exit
commit
exit
--------------------------------------------

Step 6. Check that the route is seen in PE-1:


*A:PE-1>config>service# show router 1 route-table
===============================================================================
Route Table (Service: 1)
===============================================================================
Dest Prefix[Flags]
Type
Proto
Age
Pref
Next Hop[Interface Name]
Metric
------------------------------------------------------------------------------* Truncated info
192.168.1.1/32
Remote BGP
00h04m15s
170
172.16.11.2
0
------------------------------------------------------------------------------No. of Routes: 10
Flags: L = LFA nexthop available
B = BGP backup route available
n = Number of times nexthop is repeated
===============================================================================

This prefix will also be automatically advertised within the BGP VPRN to all other PEs, and will
be installed in VRF 1.
For example, on PE-4, the source 192.168.1.1/32 is received via BGP VPN with a next-hop of PE1 (192.0.2.1):
*A:PE-4>config>service>vprn# show router 1 route-table
===============================================================================

Advanced Configuration Guide

Page 1219

Configuration

Route Table (Service: 1)


===============================================================================
Dest Prefix[Flags]
Type
Proto
Age
Pref
Next Hop[Interface Name]
Metric
------------------------------------------------------------------------------* Truncated info
192.168.1.1/32
Remote BGP VPN 00h00m05s
170
192.0.2.1 (tunneled)
0
------------------------------------------------------------------------------No. of Routes: 10
Flags: L = LFA nexthop available
B = BGP backup route available
n = Number of times nexthop is repeated
===============================================================================

Each CE containing a multicast receiver must be able to reach the source. As an example on CE-2,
a static route will suffice and is configured with next hop of the PE-2 PE-CE interface.
A:CE-2# configure service vprn 1
...
static-route 192.168.1.1/32 next-hop 172.16.22.1

After Steps 1 to 6, all required unicast routing is provisioned. The following sections show the
configuration of the multicast in the VPRN.

Page 1220

Advanced Configuration Guide

Multicast in a VPN II

Auto-Discovery and mLDP PMSI Establishment


The MP-BGP based auto-discovery is implemented with a new address family defined in RFC
4760 MP_REACH_NRLI/MP_UNREACH_NRLI attributes, with AFI 1 (IPv4) or 2 (IPv6) SAFI
5 (temporary value assigned by IANA). This is the mechanism by which each PE advertises the
presence of an MVPN to other PEs. This can be achieved using PIM (like in Draft-Rosen) or using
BGP. With the default parameter, BGP is automatically chosen because the PMSIs are mLDP and
PIM is not an option in this case. Any PE that is a member of an MVPN will advertise to the other
PEs using a BGP Multi-protocol Reachable Next-Hop Router Layer Information (NRLI) update
that is sent to all PEs within the AS. This update will contain an Intra-AS I-PMSI auto-discovery
Route type, also known as an Intra-AD. These use an address family mvpn-ipv4, so each PE must
be configured to originate and accept such updates (note this was done earlier when configuring
the families).
At this step (auto-discovery), the information about the PMSI is exchanged but the PMSI is not
instantiated.
As each PE contains a CE which will be part of the multicast VRF, it is necessary to enable PIM
on each interface containing the attachment circuit towards a CE, and to configure the I-PMSI
multicast tunnel for the VRF. Note that S-PMSIs are not supported for mLDP with the 9.0R5
software release. In order for the BGP routes to be accepted into the VRF, a route-target
community is required (vrf-target). This is configured in the configure service vprn 1 mvpn
context and, in this case is set to the same value as the unicast vrf-target (the vrf-target community
as the configure service vprn 1 vrf-target context).
On each PE, a VPRN instance is configured as follows:
A:PE-4# configure service vprn 1
...?
pim
interface "loopback"
exit
interface "int-PE-4-CE-4"
exit
rp
static
exit
bsr-candidate
shutdown
exit
rp-candidate
shutdown
exit
exit
no shutdown
exit
mvpn
auto-discovery default
c-mcast-signaling bgp
exit
provider-tunnel
inclusive

Advanced Configuration Guide

Page 1221

Configuration

mldp
no shutdown
exit
exit
exit
vrf-target unicast
exit
exit

When PIM SSM is used, the configuration always shows RP static with no RP entries (this is
enabled by default when PIM is provisioned). In order for the BGP routes to be accepted into the
VRF, a route-target community is required (vrf-target). Although it is not mandatory for the mvpn
target to be equal to the unicast target, the recommendation is to use vrf-target unicast to avoid
configuration mistakes and extra complexity.
The status of VPRN 1 on PE-1 is shown with the following output:
*A:PE-1# show router 1 mvpn
===============================================================================
MVPN 1 configuration data
===============================================================================
signaling
: Bgp
auto-discovery
: Default
UMH Selection
: Highest-Ip
intersite-shared
: Enabled
vrf-import
: N/A
vrf-export
: N/A
vrf-target
: unicast
C-Mcast Import RT : target:192.0.2.1:2
ipmsi
i-pmsi P2MP AdmSt

: ldp
: Up

s-pmsi
: none
data-delay-interval: 3 seconds
enable-asm-mdt
: N/A
===============================================================================

The following shows a debug of an Intra-AD BGP update message received by PE-1 that was sent
by PE-2. The message contains the PMSI tunnel type to be used (LDP P2MP LSP), LSP
identification (root node, opaque value) and the type of BGP update (Type: Intra-AD Len: 12 RD:
64496:102 Orig: 192.0.2.2):
A 4 2011/10/06 01:25:42.81 UTC MINOR: DEBUG #2001 Base Peer 1: 192.0.2.2
"Peer 1: 192.0.2.2: UPDATE
Peer 1: 192.0.2.2 - Received BGP UPDATE:
Withdrawn Length = 0
Total Path Attr Length = 91
Flag: 0x40 Type: 1 Len: 1 Origin: 0
Flag: 0x40 Type: 2 Len: 0 AS Path:
Flag: 0x80 Type: 4 Len: 4 MED: 0
Flag: 0x40 Type: 5 Len: 4 Local Preference: 100
Flag: 0xc0 Type: 8 Len: 4 Community:
no-export
Flag: 0xc0 Type: 16 Len: 8 Extended Community:
target:64496:100

Page 1222

Advanced Configuration Guide

Multicast in a VPN II

Flag: 0xc0 Type: 22 Len: 22 PMSI:


Tunnel-type LDP P2MP LSP (2)
Flags [Leaf not required]
MPLS Label 0
Root-Node 192.0.2.2, LSP-ID 0x2001
Flag: 0x90 Type: 14 Len: 23 Multiprotocol Reachable NLRI:
Address Family MVPN_IPV4
NextHop len 4 NextHop 192.0.2.2
Type: Intra-AD Len: 12 RD: 64496:102 Orig: 192.0.2.2
"

The set up has four PEs, so every PE should see each others peer Intra-AD route; the output below
shows the routes received in PE-1:
*A:PE-1# show router bgp routes mvpn-ipv4 type intra-ad
===============================================================================
BGP Router ID:192.0.2.1
AS:64496
Local AS:64496
===============================================================================
Legend Status codes : u - used, s - suppressed, h - history, d - decayed, * - valid
Origin codes : i - IGP, e - EGP, ? - incomplete, > - best, b - backup
===============================================================================
BGP MVPN-IPv4 Routes
===============================================================================
Flag RouteType
OriginatorIP
LocalPref
MED
RD
SourceAS
VPNLabel
Nexthop
SourceIP
As-Path
GroupIP
------------------------------------------------------------------------------u*>i Intra-Ad
192.0.2.2
100
0
64496:102
192.0.2.2
No As-Path
u*>i Intra-Ad
192.0.2.3
100
0
64496:103
192.0.2.3
No As-Path
u*>i Intra-Ad
192.0.2.4
100
0
64496:104
192.0.2.4
No As-Path
------------------------------------------------------------------------------Routes : 3
===============================================================================

The detailed output of the Intra-AD received from PE-2 shows the Tunnel-Type LDP P2MP LSP
(LSP-ID is 8193), the originator id (192.0.2.2), and the route-distinguisher (64496:102):
*A:PE-1# show router bgp routes mvpn-ipv4 type intra-ad detail
===============================================================================
BGP Router ID:192.0.2.1
AS:64496
Local AS:64496
===============================================================================
Legend Status codes : u - used, s - suppressed, h - history, d - decayed, * - valid
Origin codes : i - IGP, e - EGP, ? - incomplete, > - best, b - backup
===============================================================================
BGP MVPN-IPv4 Routes

Advanced Configuration Guide

Page 1223

Configuration

===============================================================================
Route Type
: Intra-Ad
Route Dist.
: 64496:102
Originator IP : 192.0.2.2
Nexthop
: 192.0.2.2
From
: 192.0.2.2
Res. Nexthop
: 0.0.0.0
Local Pref.
: 100
Interface Name : NotAvailable
Aggregator AS : None
Aggregator
: None
Atomic Aggr.
: Not Atomic
MED
: 0
Community
: no-export target:64496:100
Cluster
: No Cluster Members
Originator Id : None
Peer Router Id : 192.0.2.2
Flags
: Used Valid Best IGP
Route Source
: Internal
AS-Path
: No As-Path
VPRN Imported : 1
------------------------------------------------------------------------------PMSI Tunnel Attribute :
Tunnel-type
: LDP P2MP LSP
Flags
: Leaf not required
MPLS Label
: 0
Root-Node
: 192.0.2.2
LSP-ID
: 8193
-------------------------------------------------------------------------------

Because of the receiver-driven nature of mLDP, mLDP P2MP LSPs are setup unsolicited from the
leaf PEs towards the head-end PE. The leaf PEs discover the head-end PE via I-PMSI/S-PMSI AD routes. The Tunnel Identifier carried in the PMSI attribute is used as the P2MP Forwarding
Equivalence Class (FEC) Element. The Tunnel Identifier consists of the head-end PEs address,
along with a Generic LSP Identifier value. The Generic LSP Identifier value is automatically
generated by the head-end PE. The previous show command displays the PMSI information with
the detail of the Root-Node (192.0.2.2) and the LSP-ID (8193). The PMSI was created after
receiving the A-D message from PE-2, where the following excerpt from the previous debug
shows the same information (x2001 in HEX is equal to 8193 in decimal).
Flag: 0xc0 Type: 22 Len: 22 PMSI:
Tunnel-type LDP P2MP LSP (2)
Flags [Leaf not required]
MPLS Label 0
Root-Node 192.0.2.2, LSP-ID 0x2001

Once the mLDP P2MP LSPs are created, the I-PMSI is instantiated in the core:
*A:PE-1# show router 1 pim neighbor
===============================================================================
PIM Neighbor ipv4
===============================================================================
Interface
Nbr DR Prty
Up Time
Expiry Time
Hold Time
Nbr Address
------------------------------------------------------------------------------int-PE-1-CE-1
1
0d 01:21:30
0d 00:01:16
105
172.16.11.2
mpls-if-73729
1
0d 01:21:03
never
65535
192.0.2.2
mpls-if-73730
1
0d 01:20:47
never
65535

Page 1224

Advanced Configuration Guide

Multicast in a VPN II

192.0.2.3
mpls-if-73731
1
0d 01:20:32
never
65535
192.0.2.4
------------------------------------------------------------------------------Neighbors : 4
===============================================================================
*A:PE-1# show router 1 pim tunnel-interface
===============================================================================
PIM Interfaces ipv4
===============================================================================
Interface
Adm Opr DR Prty
Hello Intvl Mcast Send
DR
------------------------------------------------------------------------------mpls-if-73728
Up
Up
N/A
N/A
N/A
192.0.2.1
mpls-if-73729
Up
Up
N/A
N/A
N/A
192.0.2.2
mpls-if-73730
Up
Up
N/A
N/A
N/A
192.0.2.3
mpls-if-73731
Up
Up
N/A
N/A
N/A
192.0.2.4
------------------------------------------------------------------------------Interfaces : 4
===============================================================================

Every PE has created an I-PMSI to the other PEs. Checking the mLDP P2MP LSPs that are
originated, transit, or destination to PE-1:
*A:PE-1# show router ldp bindings fec-type p2mp active p2mp-id 8193 root 192.0.2.1
===============================================================================
LDP P2MP Bindings (Active)
===============================================================================
P2MP-Id
RootAddr
Interface
Op
IngLbl
EgrLbl EgrIntf/
EgrNextHop
LspId
------------------------------------------------------------------------------8193
192.0.2.1
73728
Push
-262137 1/1/2:1
192.168.12.2
8193
192.0.2.1
73728
Push
-262137 1/1/3:1
192.168.13.2
8193
192.0.2.2
73729
Pop
262137
---8193
192.0.2.2
73729
Swap
262137
262136 1/1/3:1
192.168.13.2
8193
192.0.2.3
73730
Swap
262142
262136 1/1/2:1
192.168.12.2
8193
192.0.2.3
73730
Pop
262142
---8193
192.0.2.4
73731
Pop
262136
---------------------------------------------------------------------------------No. of P2MP Active Bindings: 7
===============================================================================

The two first entries in the output show the P2MP LSP where PE-1 is the root headend (Push). The
other two entries (Swap and Pop) correspond with transit and leaf for the P2MP LSPs originated

Advanced Configuration Guide

Page 1225

Configuration

by the other PEs. The command shows a P2MP-ID (8193) with an interface 73728 (matches with
the show router 1 pim tunnel interface being the PIM interface created from PE-1) with two
egress interfaces pointing to PE-2 and PE-3.
A similar command executed on PE-2 shows:
*A:PE-2# show router ldp bindings fec-type p2mp p2mp-id 8193 root 192.0.2.1 active
===============================================================================
LDP P2MP Bindings (Active)
===============================================================================
P2MP-Id
RootAddr
Interface
Op
IngLbl
EgrLbl EgrIntf/
EgrNextHop
LspId
------------------------------------------------------------------------------8193
192.0.2.1
73729
Pop
262137
---8193
192.0.2.1
73729
Swap
262137
262135 1/1/3:1
192.168.24.2
* Truncated info
------------------------------------------------------------------------------No. of P2MP Active Bindings: 7
===============================================================================

On PE-2, the first entry shows that PE-2 is a leaf of the P2MP LSP tree created by PE-1 (ingress
label is 262137 which was the egress label to reach PE-2 and is popped). However, the second
entry shows that PE-2 is transit for the P2MP LSP going to PE-4 (ingress label 262137, egress
label 262135 next hop PE-4).
The same command on PE-4 shows:
*A:PE-4# show router ldp bindings active fec-type p2mp p2mp-id 8193 root 192.0.2.1
===============================================================================
LDP P2MP Bindings (Active)
===============================================================================
P2MP-Id
RootAddr
Interface
Op
IngLbl
EgrLbl EgrIntf/
EgrNextHop
LspId
------------------------------------------------------------------------------8193
192.0.2.1
73731
Pop
262135
---* Truncated info
------------------------------------------------------------------------------No. of P2MP Active Bindings: 5
===============================================================================

In the first entry the root is PE-1 and the action is Pop, being the ingress label 262135, showing
that this is another leaf for the P2MP LSP started on PE-1.
To complete the information, checking on PE-3, the first entry there is a Pop where the root is PE1, and the ingress label is 262137:
*A:PE-3# show router ldp bindings active fec-type p2mp p2mp-id 8193 root 192.0.2.1

Page 1226

Advanced Configuration Guide

Multicast in a VPN II

===============================================================================
LDP P2MP Bindings (Active)
===============================================================================
P2MP-Id
RootAddr
Interface
Op
IngLbl
EgrLbl EgrIntf/
EgrNextHop
LspId
------------------------------------------------------------------------------8193
192.0.2.1
73729
Pop
262137
---* Truncated info
------------------------------------------------------------------------------No. of P2MP Active Bindings: 5
===============================================================================

As a summary, each root PE has a P2MP LSP with three leaves (the other PEs) and they are also
transit points to the P2MP LSPs created in the other PEs. As an additional check, an OAM ping
can show the different leaves that a P2MP LSP has:
*A:PE-1# oam p2mp-lsp-ping ldp 8193 sender-addr 192.0.2.1 detail
P2MP identifier 8193: 88 bytes MPLS payload
===============================================================================
Leaf Information
===============================================================================
From
RTT
Return Code
------------------------------------------------------------------------------192.0.2.2
=3.03ms
EgressRtr(3)
192.0.2.4
=5.17ms
EgressRtr(3)
192.0.2.3
=33.1ms
EgressRtr(3)
===============================================================================
Total Leafs responded = 3
round-trip min/avg/max = 3.03 / 13.8 / 33.1 ms
Responses based on return code:
EgressRtr(3)=3

An easy way to see the path that the LDP P2MP LSP follows for a specific leaf is the following
command (such as LDP trace from PE-1 to PE-4):
*A:PE-1# oam ldp-treetrace prefix 192.0.2.4/32
ldp-treetrace for Prefix 192.0.2.4/32:
192.168.24.2, ttl =
2 dst =
Hops:
192.168.12.2

127.1.0.255 rc = EgressRtr status = Done

ldp-treetrace discovery state: Done


ldp-treetrace discovery status: ' OK '
Total number of discovered paths: 1
Total number of failed traces: 0

The command shows that on PE-4 there is an active leaf of the P2MP LSP, and that there is an
intermediate hop on PE-2.

Advanced Configuration Guide

Page 1227

Configuration

Traffic Flow
The receiver RX-4, connected to CE-4, wishes to join the group 232.1.1.1 with source 192.168.1.1
and so sends an IGMPv3 report towards CE-4. CE-4 recognizes the report and sends a PIM join
towards the source, hence it reaches PE-1 where the source is connected to through CE-1. The
output below shows the debug seen on PE-4, where the PIM join is received from CE-4 and a BGP
update Source Join is sent to all PEs (note that only the update sent to PE-1 is shown).
11 2011/10/13 15:41:30.83 UTC MINOR: DEBUG #2001 vprn1 PIM[Instance 2 vprn1]
"PIM[Instance 2 vprn1]: pimJPProcessSG
pimJPProcessSG: (S,G)-> (192.168.1.1,232.1.1.1) type <S,G>, i/f int-PE-4-CE-4, u
pNbr 172.16.44.1 isJoin 1 isRpt 0 holdTime 210"
12 2011/10/13 15:41:30.83 UTC MINOR: DEBUG #2001 vprn1 PIM[Instance 2 vprn1]
"PIM[Instance 2 vprn1]: pimJPPrintFsmEvent
PIM JP Downstream: State NoInfo Event RxJoin, (S,G) (192.168.1.1,232.1.1.1) grou
pType <S,G>"
13 2011/10/13 15:41:30.83 UTC MINOR: DEBUG #2001 vprn1 PIM[Instance 2 vprn1]
"PIM[Instance 2 vprn1]: pimJPPrintFsmEvent
PIM JP Upstream: State NotJoined Event JoinDesiredTrue, (S,G) (192.168.1.1,232.1
.1.1) groupType <S,G>"
14 2011/10/13 15:41:30.83 UTC MINOR: DEBUG #2001 vprn1 PIM[Instance 2 vprn1]
"PIM[Instance 2 vprn1]: pimSGUpJoinDesiredTrue
No upstream interface. pSG (192.168.1.1,232.1.1.1) rpfType 3"
15 2011/10/13 15:41:30.83 UTC MINOR: DEBUG #2001 vprn1 PIM[Instance 2 vprn1]
"PIM[Instance 2 vprn1]: pimSGUpJoinDesiredTrue
pim 2 sg_type 2 refetch route type SPMSI pendingFetchMask 0x8"
16 2011/10/13 15:41:30.83 UTC MINOR: DEBUG #2001 vprn1 PIM[Instance 2 vprn1]
"PIM[Instance 2 vprn1]: pimSGUpJoinDesiredTrue
No upstream interface. pSG 0x5578f87c, (192.168.1.1,232.1.1.1) rpfType 3"
17 2011/10/13 15:41:30.83 UTC MINOR: DEBUG #2001 vprn1 PIM[Instance 2 vprn1]
"PIM[Instance 2 vprn1]: pimJPPrintFsmEvent
PIM JP Upstream: State Joined Event MribChange, (S,G) (192.168.1.1,232.1.1.1) gr
oupType <S,G>"
18 2011/10/13 15:41:30.83 UTC MINOR: DEBUG #2001 vprn1 PIM[Instance 2 vprn1]
"PIM[Instance 2 vprn1]: pimSGUpStateJMribChange
pSG 0x5578f87c, (192.168.1.1,232.1.1.1), type <S,G> oldMribNhopIp 0.0.0.0 oldRpf
NbrIp 0.0.0.0, oldRpfType NONE oldRpfIf 0 rptMribNhopIp 0.0.0.0, rptRpfNbrIp 0.0
.0.0 rtmReason 32"
19 2011/10/13 15:41:30.83 UTC MINOR: DEBUG #2001 vprn1 PIM[Instance 2 vprn1]
"PIM[Instance 2 vprn1]: pimSGUpStateJMribChange
pSG 0x5578f87c, (192.168.1.1,232.1.1.1), type <S,G> newMribNhopIp 192.0.2.1 newR
pfNbrIp 192.0.2.1 newRpfType REMOTE newRpfIf 73731"
20 2011/10/13 15:41:30.83 UTC MINOR: DEBUG #2001 Base Peer 1: 192.0.2.1
"Peer 1: 192.0.2.1: UPDATE
Peer 1: 192.0.2.1 - Send BGP UPDATE:
Withdrawn Length = 0
Total Path Attr Length = 69
Flag: 0x40 Type: 1 Len: 1 Origin: 0

Page 1228

Advanced Configuration Guide

Multicast in a VPN II

Flag: 0x40 Type: 2 Len: 0 AS Path:


Flag: 0x80 Type: 4 Len: 4 MED: 0
Flag: 0x40 Type: 5 Len: 4 Local Preference: 100
Flag: 0xc0 Type: 16 Len: 8 Extended Community:
target:192.0.2.1:2
Flag: 0x90 Type: 14 Len: 33 Multiprotocol Reachable NLRI:
Address Family MVPN_IPV4
NextHop len 4 NextHop 192.0.2.4
Type: Source-Join Len:22 RD: 64496:101 SrcAS: 64496 Src: 192.168.1.1 Grp
: 232.1.1.1
"

The following debug shows that PE-1 receives the BGP update Source Join with source
192.168.1.1 and group 232.1.1.1 and sends a PIM join towards CE-1:
57 2011/10/14 02:06:58.22 UTC MINOR: DEBUG #2001 Base Peer 1: 192.0.2.4
"Peer 1: 192.0.2.4: UPDATE
Peer 1: 192.0.2.4 - Received BGP UPDATE:
Withdrawn Length = 0
Total Path Attr Length = 69
Flag: 0x40 Type: 1 Len: 1 Origin: 0
Flag: 0x40 Type: 2 Len: 0 AS Path:
Flag: 0x80 Type: 4 Len: 4 MED: 0
Flag: 0x40 Type: 5 Len: 4 Local Preference: 100
Flag: 0xc0 Type: 16 Len: 8 Extended Community:
target:192.0.2.1:2
Flag: 0x90 Type: 14 Len: 33 Multiprotocol Reachable NLRI:
Address Family MVPN_IPV4
NextHop len 4 NextHop 192.0.2.4
Type: Source-Join Len:22 RD: 64496:101 SrcAS: 64496 Src: 192.168.1.1 Grp
: 232.1.1.1
"
58 2011/10/14 02:06:58.22 UTC MINOR: DEBUG #2001 vprn1 PIM[Instance 2 vprn1]
"PIM[Instance 2 vprn1]: pimJPProcessSG
pimJPProcessSG: (S,G)-> (192.168.1.1,232.1.1.1) type <S,G>, i/f mpls-if-73728, u
pNbr 192.0.2.1 isJoin 1 isRpt 0 holdTime 65535"
59 2011/10/14 02:06:58.22 UTC MINOR: DEBUG #2001 vprn1 PIM[Instance 2 vprn1]
"PIM[Instance 2 vprn1]: pimJPPrintFsmEvent
PIM JP Downstream: State NoInfo Event RxJoin, (S,G) (192.168.1.1,232.1.1.1) grou
pType <S,G>"
60 2011/10/14 02:06:58.22 UTC MINOR: DEBUG #2001 vprn1 PIM[Instance 2 vprn1]
"PIM[Instance 2 vprn1]: pimJPPrintFsmEvent
PIM JP Upstream: State NotJoined Event JoinDesiredTrue, (S,G) (192.168.1.1,232.1
.1.1) groupType <S,G>"
61 2011/10/14 02:06:58.22 UTC MINOR: DEBUG #2001 vprn1 PIM[Instance 2 vprn1]
"PIM[Instance 2 vprn1]: pimSGUpJoinDesiredTrue
pim 2 sg_type 2 refetch route type SPMSI pendingFetchMask 0x8"
62 2011/10/14 02:06:58.22 UTC MINOR: DEBUG #2001 vprn1 PIM[Instance 2 vprn1]
"PIM[Instance 2 vprn1]: pimSendJoinPrunePdu
pimSendJoinPrunePdu: if 3, adj 172.16.11.2"
63 2011/10/14 02:06:58.22 UTC MINOR: DEBUG #2001 vprn1 PIM[Instance 2 vprn1]

Advanced Configuration Guide

Page 1229

Configuration

"PIM[Instance 2 vprn1]: pimSGEncodeGroupSet


pimEncodeGroupSet: encoding groupset for group 232.1.1.1, numJoinedSrcs 1, numPr
unedSrcs 0"
64 2011/10/14 02:06:58.22 UTC MINOR: DEBUG #2001 vprn1 PIM[Instance 2 vprn1]
"PIM[Instance 2 vprn1]: pimSGEncodeGroupSet
pimEncodeGroupSet: Encoding Join for source 192.168.1.1"
65 2011/10/14 02:06:58.22 UTC MINOR: DEBUG #2001 vprn1 PIM[Instance 2 vprn1]
"PIM[Instance 2 vprn1]: pimSGEncodeGroupSet
pimEncodeGroupSet: num joined srcs 1, num pruned srcs 0"
66 2011/10/14 02:06:58.22 UTC MINOR: DEBUG #2001 vprn1 PIM[Instance 2 vprn1]
"PIM[Instance 2 vprn1]: pimSendJoinPrunePdu
pimSendJoinPrunePdu2: sending JP PDU with 1 groups."

The BGP update source join received by PE-1 is displayed with the command:
*A:PE-1# show router bgp routes mvpn-ipv4 type source-join
===============================================================================
BGP Router ID:192.0.2.1
AS:64496
Local AS:64496
===============================================================================
Legend Status codes : u - used, s - suppressed, h - history, d - decayed, * - valid
Origin codes : i - IGP, e - EGP, ? - incomplete, > - best, b - backup
===============================================================================
BGP MVPN-IPv4 Routes
===============================================================================
Flag RouteType
OriginatorIP
LocalPref
MED
RD
SourceAS
VPNLabel
Nexthop
SourceIP
As-Path
GroupIP
------------------------------------------------------------------------------u*>i Source-Join
100
0
64496:101
64496
192.0.2.4
192.168.1.1
No As-Path
232.1.1.1
------------------------------------------------------------------------------Routes : 1
===============================================================================

To verify the traffic: on PE-1 there is a group 232.1.1.1 with source 192.168.1.1, the Reverse Path
Forwarding (RPF) is CE-1, the multicast traffic is flowing from CE-1 to PE-1 using int-PE-1-CE1 and the outgoing interface is using the PMSI mLDP mpls-if-73728.
*A:PE-1# show router 1 pim group detail
===============================================================================
PIM Source Group ipv4
===============================================================================
Group Address
: 232.1.1.1
Source Address
: 192.168.1.1
RP Address
: 0
Flags
:
Type
: (S,G)
MRIB Next Hop
: 172.16.11.2
MRIB Src Flags
: remote
Keepalive Timer
: Not Running
Up Time
: 0d 00:12:04
Resolved By
: rtable-u

Page 1230

Advanced Configuration Guide

Multicast in a VPN II

Up JP State
Up JP Rpt

: Joined
: Not Joined StarG

Up JP Expiry
: 0d 00:00:56
Up JP Rpt Override : 0d 00:00:00

Register State
: No Info
Reg From Anycast RP: No
Rpf Neighbor
: 172.16.11.2
Incoming Intf
: int-PE-1-CE-1
Outgoing Intf List : mpls-if-73728
Curr Fwding Rate
: 0.0 kbps
Forwarded Packets : 0
Discarded Packets : 0
Forwarded Octets
: 0
RPF Mismatches
: 0
Spt threshold
: 0 kbps
ECMP opt threshold : 7
Admin bandwidth
: 1 kbps
------------------------------------------------------------------------------Groups : 1
===============================================================================

On PE-4, the same (S,G) arrives in the incoming interface mpls-if-73731 and the outgoing
interface is int-PE-4-CE-4.
*A:PE-4# show router 1 pim group detail
===============================================================================
PIM Source Group ipv4
===============================================================================
Group Address
: 232.1.1.1
Source Address
: 192.168.1.1
RP Address
: 0
Flags
:
Type
: (S,G)
MRIB Next Hop
: 192.0.2.1
MRIB Src Flags
: remote
Keepalive Timer
: Not Running
Up Time
: 0d 00:15:44
Resolved By
: rtable-u
Up JP State
Up JP Rpt

: Joined
: Not Joined StarG

Up JP Expiry
: 0d 00:00:16
Up JP Rpt Override : 0d 00:00:00

Register State
: No Info
Reg From Anycast RP: No
Rpf Neighbor
: 192.0.2.1
Incoming Intf
: mpls-if-73731
Outgoing Intf List : int-PE-4-CE-4
Curr Fwding Rate
Forwarded Packets
Forwarded Octets
Spt threshold
Admin bandwidth

:
:
:
:
:

0.0 kbps
0
0
0 kbps
1 kbps

Discarded Packets : 0
RPF Mismatches
: 0
ECMP opt threshold : 7

When the receiver is not interested in the channel group any more, the receiver RX-4 sends an
IGMPv3 leave, PE-4 sends a PIM prune translated to a BGP MP_UNREACH NLRI to all PEs.
Note that, as mentioned before, rapid withdrawals are sent without waiting for the mrai (note that
for simplicity, only one BGP update is shown in the output debug).

Advanced Configuration Guide

Page 1231

Configuration

33 2011/10/13 16:20:17.74 UTC MINOR: DEBUG #2001 vprn1 PIM[Instance 2 vprn1]


"PIM[Instance 2 vprn1]: pimJPProcessSG
pimJPProcessSG: (S,G)-> (192.168.1.1,232.1.1.1) type <S,G>, i/f int-PE-4-CE-4, u
pNbr 172.16.44.1 isJoin 0 isRpt 0 holdTime 210"
34 2011/10/13 16:20:17.74 UTC MINOR: DEBUG #2001 vprn1 PIM[Instance 2 vprn1]
"PIM[Instance 2 vprn1]: pimJPPrintFsmEvent
PIM JP Downstream: State Joined Event RxPrune, (S,G) (192.168.1.1,232.1.1.1) gro
upType <S,G>"
35 2011/10/13 16:20:17.74 UTC MINOR: DEBUG #2001 vprn1 PIM[Instance 2 vprn1]
"PIM[Instance 2 vprn1]: pimJPPrintFsmEvent
PIM JP Downstream: State PrunePending Event PrunePendTimerExp, (S,G) (192.168.1.
1,232.1.1.1) groupType <S,G>"
36 2011/10/13 16:20:17.74 UTC MINOR: DEBUG #2001 vprn1 PIM[Instance 2 vprn1]
"PIM[Instance 2 vprn1]: pimJPPrintFsmEvent
PIM JP Upstream: State Joined Event JoinDesiredFalse, (S,G) (192.168.1.1,232.1.1
.1) groupType <S,G>"
37 2011/10/13 16:20:17.74 UTC MINOR: DEBUG #2001 Base Peer 1: 192.0.2.2
"Peer 1: 192.0.2.2: UPDATE
Peer 1: 192.0.2.2 - Send BGP UPDATE:
Withdrawn Length = 0
Total Path Attr Length = 31
Flag: 0x90 Type: 15 Len: 27 Multiprotocol Unreachable NLRI:
Address Family MVPN_IPV4
Type: Source-Join Len:22 RD: 64496:101 SrcAS: 64496 Src: 192.168.1.1 Grp
: 232.1.1.1
"

Page 1232

Advanced Configuration Guide

Multicast in a VPN II

PMSI using RSVP-TE


Figure 92 shows the details of the topology for VPRN 2.

192.168.2.1/24

AS 64499

CE-1
VPRN2

.2

PE-1

PE-3

Loopback: 172.16.2.1/32

Loopback: 172.16.2.3/32

1/1/1:2
172.16.12.0/30
e-BGP

.1

VPRN2

.1

VPRN2

1/1/3

1/1/1:2
172.16.34.0/30
.1

STATIC

AS 64403

CE-3
.2

VPRN2

Source

1/1/2

AS 64402

CE-2

RX-2

VPRN2

.2

AS 64496

1/1/2

.2
1/1/1:2
172.16.23.0/30

VPRN2

.1

STATIC

1/1/3

Loopback: 172.16.2.2/32

1/1/1:2
172.16.42.0/30

VPRN2

.1

PE-2

RX-3

STATIC

PE-4

AS 64404

CE-4
.2

VPRN2

RX-4

Loopback: 172.16.2.4/32
MVPNII_03

Figure 92: VPRN 2 Topology used for RSVP-TE P2MP

Unicast
For the sake of simplicity, check Steps 1 to 6 in PMSI using mLDP on page 1216 for VPRN 2
creation information. The same steps are repeated for RSVP using for provisioning the details that
appear in Figure 92. The result is the configuration in all the PEs, taking as an example PE-1:
*A:PE-1>config>service>vprn# info
---------------------------------------------description "P2MP RSVP"
autonomous-system 64496
route-distinguisher 64496:201
vrf-target target:64496:200
interface "loopback" create
address 172.16.2.1/32
loopback
exit
interface "int-PE-1-CE-1" create
address 172.16.12.1/30
sap 1/1/1:2 create
exit
exit
bgp
group "external"

Advanced Configuration Guide

Page 1233

Configuration

type external
peer-as 64499
neighbor 172.16.12.2
exit
exit
no shutdown
exit
spoke-sdp 12 create
no shutdown
exit
spoke-sdp 13 create
no shutdown
exit
spoke-sdp 14 create
no shutdown
exit
no shutdown
----------------------------------------------

In addition to the unicast, because RSVP is the signalling protocol to establish the P2MP LSPs,
RSVP is configured on the interfaces. In addition, to use P2MP RSVP an LSP template is needed.
The template defines the characteristics of the LSP to be created, for example, make-before-break,
bandwidth, administrative groups, cspf, specific paths, etc. A basic template is used here. TE
parameters specified in the template are commonly used in each RSVP PATH message for each of
the branches of the P2MP RSVP LSP. The template is used in the mvpn context within the VPRN
configuration (see Auto-Discovery and RSVP PMSI Establishment on page 1235). The resignal
timer for P2MP is configured to the minimum value of sixty minutes (60 10080 minutes):
*A:PE-1>config>router>mpls# info
---------------------------------------------p2mp-resignal-timer 60
interface "system"
exit
interface "int-PE-1-PE-2"
exit
interface "int-PE-1-PE-3"
exit
path "empty"
no shutdown
exit
lsp-template "vrf2" p2mp
default-path "empty"
cspf
fast-reroute facility
exit
no shutdown
exit
no shutdown
----------------------------------------------

Page 1234

Advanced Configuration Guide

Multicast in a VPN II

Auto-Discovery and RSVP PMSI Establishment


The MP-BGP based auto-discovery is implemented with a new address family defined in RFC
4760 MP_REACH_NRLI/MP_UNREACH_NRLI attributes, with AFI 1 (IPv4) or 2 (IPv6) SAFI
5 (temporary value assigned by IANA). This is the mechanism by which each PE advertises the
presence of an MVPN to other PEs. This can be achieved using PIM (like in Draft-Rosen) or using
BGP. With the default parameter, BGP is automatically chosen because the PMSIs are RSVP and
PIM is not an option in this case. Any PE that is a member of an MVPN will advertise to the other
PEs using a BGP Multi-protocol Reachable Next-Hop Router Layer Information (NRLI) update
that is sent to all PEs within the AS. This update will contain an Intra-AS I-PMSI auto-discovery
Route type, also known as an Intra-AD. These use an address family mvpn-ipv4, so each PE must
be configured to originate and accept such updates (note this was done earlier when configuring
the families).
At this step (auto-discovery), the information about the PMSI is exchanged but the PMSI is not
instantiated.
As each PE contains a CE which will be part of the multicast VRF, it is necessary to enable PIM
on each interface containing the attachment circuit towards a CE, and to configure the I-PMSI
multicast tunnel for the VRF. Note that S-PMSIs are not supported for RSVP with the 9.0R5
software release. In order for the BGP routes to be accepted into the VRF a route-target
community is required (vrf-target). Although it is not mandatory for the mVPN target to be equal
to the unicast target, the recommendation is to use vrf-target unicast to avoid configuration
mistakes and extra complexity.
On each PE, a VPRN instance is configured as follows:
*A:PE-1>config>service>vprn# info
---------------------------------------------pim
interface "loopback"
exit
interface "int-PE-1-CE-1"
exit
rp
static
exit
bsr-candidate
shutdown
exit
rp-candidate
shutdown
exit
exit
no shutdown
exit
mvpn
auto-discovery default
c-mcast-signaling bgp
provider-tunnel
inclusive
rsvp

Advanced Configuration Guide

Page 1235

Configuration

lsp-template vrf2
no shutdown
exit
exit
exit
vrf-target unicast
exit
exit

The status of VPRN 2 on PE-1 is shown with the following output:


*A:PE-1>config>service>vprn# show router 2 mvpn
===============================================================================
MVPN 2 configuration data
===============================================================================
signaling
: Bgp
auto-discovery
: Default
UMH Selection
: Highest-Ip
intersite-shared
: Enabled
vrf-import
: N/A
vrf-export
: N/A
vrf-target
: unicast
C-Mcast Import RT : target:192.0.2.1:3
ipmsi
i-pmsi P2MP AdmSt

: rsvp vrf2
: Up

s-pmsi
: none
data-delay-interval: 3 seconds
enable-asm-mdt
: N/A
===============================================================================

The following shows a debug of an Intra-AD BGP update message received by PE-1 that was sent
by PE-4. The message contains the PMSI tunnel-type to be used (RSVP P2MP LSP), the P2MP
LSP ID (encoded as extended Tunnel ID and P2MP-ID carried in the RSVP Session object), and
the type of BGP update (Type: Intra-AD Len: 12 RD: 64496:204 Orig: 192.0.2.4):
41 2011/10/07 00:49:09.46 UTC MINOR: DEBUG #2001 Base Peer 1: 192.0.2.4
"Peer 1: 192.0.2.4: UPDATE
Peer 1: 192.0.2.4 - Received BGP UPDATE:
Withdrawn Length = 0
Total Path Attr Length = 86
Flag: 0x40 Type: 1 Len: 1 Origin: 0
Flag: 0x40 Type: 2 Len: 0 AS Path:
Flag: 0x80 Type: 4 Len: 4 MED: 0
Flag: 0x40 Type: 5 Len: 4 Local Preference: 100
Flag: 0xc0 Type: 8 Len: 4 Community:
no-export
Flag: 0xc0 Type: 16 Len: 8 Extended Community:
target:64496:200
Flag: 0xc0 Type: 22 Len: 17 PMSI:
Tunnel-type RSVP-TE P2MP LSP (1)
Flags [Leaf not required]
MPLS Label 0
P2MP-ID 0x2, Tunnel-ID: 61441, Extended-Tunnel-ID 192.0.2.4
Flag: 0x90 Type: 14 Len: 23 Multiprotocol Reachable NLRI:
Address Family MVPN_IPV4
NextHop len 4 NextHop 192.0.2.4

Page 1236

Advanced Configuration Guide

Multicast in a VPN II

Type: Intra-AD Len: 12 RD: 64496:204 Orig: 192.0.2.4


"

The set up has four PEs, so every PE should see the others peer Intra-AD route; the output below
shows the routes received in PE-1:
*A:PE-1# show router bgp routes mvpn-ipv4 type intra-ad
===============================================================================
BGP Router ID:192.0.2.1
AS:64496
Local AS:64496
===============================================================================
Legend Status codes : u - used, s - suppressed, h - history, d - decayed, * - valid
Origin codes : i - IGP, e - EGP, ? - incomplete, > - best, b - backup
===============================================================================
BGP MVPN-IPv4 Routes
===============================================================================
Flag RouteType
OriginatorIP
LocalPref
MED
RD
SourceAS
VPNLabel
Nexthop
SourceIP
As-Path
GroupIP
------------------------------------------------------------------------------u*>i Intra-Ad
192.0.2.2
100
0
64496:202
192.0.2.2
No As-Path
u*>i Intra-Ad
192.0.2.3
100
0
64496:203
192.0.2.3
No As-Path
u*>i Intra-Ad
192.0.2.4
100
0
64496:204
192.0.2.4
No As-Path
------------------------------------------------------------------------------Routes : 3
===============================================================================

The detailed output of the Intra-AD received from PE-4 shows the Tunnel-Type RSVP-TE P2MP
LSP (P2MP-ID is 2), the originator id (192.0.2.4), and the route-distinguisher (64496:204):
*A:PE-1# show router bgp routes mvpn-ipv4 type intra-ad originator-ip 192.0.2.4 detail
===============================================================================
BGP Router ID:192.0.2.1
AS:64496
Local AS:64496
===============================================================================
Legend Status codes : u - used, s - suppressed, h - history, d - decayed, * - valid
Origin codes : i - IGP, e - EGP, ? - incomplete, > - best, b - backup
===============================================================================
BGP MVPN-IPv4 Routes
===============================================================================
Route Type
: Intra-Ad
Route Dist.
: 64496:204
Originator IP : 192.0.2.4
Nexthop
: 192.0.2.4
From
: 192.0.2.4
Res. Nexthop
: 0.0.0.0

Advanced Configuration Guide

Page 1237

Configuration

Local Pref.
: 100
Interface Name : NotAvailable
Aggregator AS : None
Aggregator
: None
Atomic Aggr.
: Not Atomic
MED
: 0
Community
: no-export target:64496:200
Cluster
: No Cluster Members
Originator Id : None
Peer Router Id : 192.0.2.4
Flags
: Used Valid Best IGP
Route Source
: Internal
AS-Path
: No As-Path
VPRN Imported : 2
------------------------------------------------------------------------------PMSI Tunnel Attribute :
Tunnel-type
: RSVP-TE P2MP LSP
Flags
: Leaf not required
MPLS Label
: 0
P2MP-ID
: 2
Tunnel-ID
: 61441
Extended-Tunne*: 192.0.2.4
-------------------------------------------------------------------------------

For the I-PMSI, the headend PE firstly discovers all the leaf PEs via I-PMSI A-D routes, it then
signals the P2MP LSP to all the leaf PEs using RSVP-TE (subsequently adding or removing S2L
(source to leaf) paths as PEs are added or removed from the MVPN). Note that RSVP-TE SPMSIs are not supported in the tested release 9.0R5.
As in the mLDP case, the demarcation of the domains are in the PE. The PE router participates in
both the customer multicast domain and the providers multicast domain. The customers CEs are
limited to a multicast adjacency with the multicast instance on the PE created to support that
specific customers IP-VPN. This way, customers are isolated from the providers core multicast
domain and other customer multicast domains while the providers core P routers only participate
in the providers multicast domain and are isolated from all customerss multicast domains. Ctrees to P-tunnels bindings are also discovered using BGP routes, instead of PIM join TLVs.
MVPN c-multicast routing information is exchanged between PEs by using c-multicast routes that
are carried using MCAST-VPN NLRIs.
Once the RSVP-TE P2MP LSPs are created, the I-PMSI is instantiated in the core:
*A:PE-1# show router 2 pim neighbor
===============================================================================
PIM Neighbor ipv4
===============================================================================
Interface
Nbr DR Prty
Up Time
Expiry Time
Hold Time
Nbr Address
------------------------------------------------------------------------------int-PE-1-CE-1
1
0d 00:42:20
0d 00:01:34
105
172.16.12.2
mpls-if-73741
1
0d 00:42:20
never
65535
192.0.2.2
mpls-if-73742
1
0d 00:42:20
never
65535
192.0.2.3
mpls-if-73743
1
0d 00:42:20
never
65535
192.0.2.4
------------------------------------------------------------------------------Neighbors : 4
===============================================================================

Page 1238

Advanced Configuration Guide

Multicast in a VPN II

*A:PE-1# show router 2 pim tunnel-interface


===============================================================================
PIM Interfaces ipv4
===============================================================================
Interface
Adm Opr DR Prty
Hello Intvl Mcast Send
DR
------------------------------------------------------------------------------mpls-if-73740
Up
Up
N/A
N/A
N/A
192.0.2.1
mpls-if-73741
Up
Up
N/A
N/A
N/A
192.0.2.2
mpls-if-73742
Up
Up
N/A
N/A
N/A
192.0.2.3
mpls-if-73743
Up
Up
N/A
N/A
N/A
192.0.2.4
------------------------------------------------------------------------------Interfaces : 4

The following command displays the PMSIs created on a PE, taking PE-3 as an example:
*A:PE-3# tools dump router 2 mvpn provider-tunnels
===============================================================================
MVPN 2 Inclusive Provider Tunnels Originating
===============================================================================
ipmsi (RSVP)
P2MP-ID Tunl-ID Ext-Tunl-ID
------------------------------------------------------------------------------vrf2-2-73732
2
61440
192.0.2.3
===============================================================================
MVPN 2 Selective Provider Tunnels Originating
===============================================================================
spmsi (RSVP)
P2MP-ID Tunl-ID Ext-Tunl-ID
------------------------------------------------------------------------------No Tunnels Found
------------------------------------------------------------------------------===============================================================================
MVPN 2 Inclusive Provider Tunnels Terminating
===============================================================================
ipmsi (RSVP)
P2MP-ID Tunl-ID Ext-Tunl-ID
------------------------------------------------------------------------------mpls-if-73737
2
61452
192.0.2.1
mpls-if-73734
2
61440
192.0.2.2
mpls-if-73735
2
61441
192.0.2.4
===============================================================================
MVPN 2 Selective Provider Tunnels Terminating
===============================================================================
spmsi (RSVP)
P2MP-ID Tunl-ID Ext-Tunl-ID
------------------------------------------------------------------------------No Tunnels Found
-------------------------------------------------------------------------------

Advanced Configuration Guide

Page 1239

Configuration

Every PE has created an I-PMSI to the other PEs. As an example, PE-1 has established an LSP
with name vrf2-2-73740 and PE-2, PE-3 and PE-4 as leaves. Note that the S2L path is empty as
the template did not have any S2L path configured for simplicity.
*A:PE-1# show router mpls p2mp-lsp detail
===============================================================================
MPLS P2MP LSPs (Originating) (Detail)
===============================================================================
------------------------------------------------------------------------------Type : Originating
------------------------------------------------------------------------------LSP Name
: vrf2-2-73740
LSP Type
: P2mpAutoLsp
LSP Tunnel ID : 61452
From
: 192.0.2.1
Adm State
: Up
Oper State
: Up
LSP Up Time : 0d 00:48:03
LSP Down Time : 0d 00:00:00
Transitions : 1
Path Changes
: 2
Retry Limit : 0
Retry Timer
: 30 sec
Signaling
: RSVP
Resv. Style
: SE
Hop Limit
: 255
Negotiated MTU : n/a
Adaptive
: Enabled
ClassType
: 0
FastReroute : Enabled
Oper FR
: Enabled
FR Method
: Facility
FR Hop Limit
: 16
FR Bandwidth: 0 Mbps
FR Node Protect: Disabled
FR Object
: Enabled
CSPF
: Enabled
ADSPEC
: Disabled
Metric
: Disabled
Use TE metric : Disabled
Include Grps:
Exclude Grps
:
None
None
Least Fill : Disabled
Auto BW
:
LdpOverRsvp :
IGP Shortcut:
BGPTransTun :
Oper Metric :
Prop Adm Grp:

Disabled
Disabled
Disabled
Disabled
Disabled
Disabled

VprnAutoBind
BGP Shortcut

: Disabled
: Disabled

CSPFFirstLoose : Disabled

P2MPInstance: 2
P2MP-Inst-type : Primary
S2l-Name
: empty
To
: 192.0.2.2
S2l-Name
: empty
To
: 192.0.2.3
S2l-Name
: empty
To
: 192.0.2.4
===============================================================================

Checking the RSVP-TE P2MP LSPs that are originated, transit, or destination to PE-1, the show
command allows filtering by type, in this case showing the originated LSPs only:
*A:PE-1# show router mpls p2mp-info type originate
===============================================================================
MPLS P2MP LSPs (Originate)
===============================================================================
------------------------------------------------------------------------------S2L vrf2-2-73740::empty
------------------------------------------------------------------------------Source IP Address
: 192.0.2.1
Tunnel ID
: 61452
P2MP ID
: 2
Lsp ID
: 38402

Page 1240

Advanced Configuration Guide

Multicast in a VPN II

S2L Name
: vrf2-2-73740::empty
To
: 192.0.2.2
Out Interface
: 1/1/2:1
Out Label
: 262138
Num. of S2ls
: 2
------------------------------------------------------------------------------S2L vrf2-2-73740::empty
------------------------------------------------------------------------------Source IP Address
: 192.0.2.1
Tunnel ID
: 61452
P2MP ID
: 2
Lsp ID
: 38402
S2L Name
: vrf2-2-73740::empty
To
: 192.0.2.3
Out Interface
: 1/1/3:1
Out Label
: 262128
Num. of S2ls
: 1
------------------------------------------------------------------------------S2L vrf2-2-73740::empty
------------------------------------------------------------------------------Source IP Address
: 192.0.2.1
Tunnel ID
: 61452
P2MP ID
: 2
Lsp ID
: 38402
S2L Name
: vrf2-2-73740::empty
To
: 192.0.2.4
Out Interface
: 1/1/2:1
Out Label
: 262138
Num. of S2ls
: 2
------------------------------------------------------------------------------P2MP Cross-connect instances : 3
===============================================================================

Following the path of the S2L from PE-1 to PE-4 (third entry S2L vrf2-2-73740), the outgoing
interface is 1/1/2 that connects PE-1 to PE-2, so the LSP goes to PE-4 via PE-2.
*A:PE-2# show router mpls p2mp-info type transit
===============================================================================
MPLS P2MP LSPs (Transit)
===============================================================================
------------------------------------------------------------------------------S2L vrf2-2-73740::empty
------------------------------------------------------------------------------Source IP Address
: 192.0.2.1
Tunnel ID
: 61452
P2MP ID
: 2
Lsp ID
: 38402
S2L Name
: vrf2-2-73740::empty
To
: 192.0.2.4
Out Interface
: 1/1/3:1
Out Label
: 262136
Num. of S2ls
: 1
------------------------------------------------------------------------------S2L vrf2-2-73732::empty
------------------------------------------------------------------------------Source IP Address
: 192.0.2.4
Tunnel ID
: 61441
P2MP ID
: 2
Lsp ID
: 17924
S2L Name
: vrf2-2-73732::empty
To
: 192.0.2.1
Out Interface
: 1/1/2:1
Out Label
: 262133
Num. of S2ls
: 1
------------------------------------------------------------------------------P2MP Cross-connect instances : 2
===============================================================================

As transit, PE-2 shows that there is an LSP coming from PE-1 (vrf2-2-73740) and the outgoing
interface is 1/1/3 that connects PE-2 with PE-4.

Advanced Configuration Guide

Page 1241

Configuration

Using the same command with a different filter on PE-4, 3 P2MP LSPs are terminated, one from
each remote PE (PE-1, PE-2 and PE-3). On PE-4, an S2L vrf2-2-73740 from 192.0.2.1 and P2MP
ID = 2 is traced.
*A:PE-4# show router mpls p2mp-info type terminate
===============================================================================
MPLS P2MP LSPs (Terminate)
===============================================================================
------------------------------------------------------------------------------S2L vrf2-2-73740::empty
------------------------------------------------------------------------------Source IP Address
: 192.0.2.1
Tunnel ID
: 61452
P2MP ID
: 2
Lsp ID
: 38402
S2L Name
: vrf2-2-73740::empty
To
: 192.0.2.4
In Interface
: 1/1/3:1
In Label
: 262136
Num. of S2ls
: 1
------------------------------------------------------------------------------S2L vrf2-2-73732::empty
------------------------------------------------------------------------------Source IP Address
: 192.0.2.2
Tunnel ID
: 61440
P2MP ID
: 2
Lsp ID
: 8196
S2L Name
: vrf2-2-73732::empty
To
: 192.0.2.4
In Interface
: 1/1/3:1
In Label
: 262132
Num. of S2ls
: 1
------------------------------------------------------------------------------S2L vrf2-2-73732::empty
------------------------------------------------------------------------------Source IP Address
: 192.0.2.3
Tunnel ID
: 61440
P2MP ID
: 2
Lsp ID
: 59396
S2L Name
: vrf2-2-73732::empty
To
: 192.0.2.4
In Interface
: 1/1/2:1
In Label
: 262142
Num. of S2ls
: 2
------------------------------------------------------------------------------P2MP Cross-connect instances : 3
===============================================================================

The following output shows P2MP LSP on PE-1 with more detail:
*A:PE-1# show router mpls p2mp-lsp "vrf2-2-73740" p2mp-instance "2" s2l "empty" detail
===============================================================================
MPLS LSP vrf2-2-73740 S2L empty (Detail)
===============================================================================
Legend :
@ - Detour Available
# - Detour In Use
b - Bandwidth Protected
n - Node Protected
S - Strict
L - Loose
s - Soft Preemption
===============================================================================
------------------------------------------------------------------------------LSP vrf2-2-73740 S2L empty
------------------------------------------------------------------------------LSP Name
: vrf2-2-73740
S2l LSP ID : 38402
P2MP ID
: 2
S2l Grp Id : 1
Adm State
: Up
Oper State : Up
S2l State: : Active
:
S2L Name
: empty
To
: 192.0.2.2
S2l Admin
: Up
S2l Oper
: Up

Page 1242

Advanced Configuration Guide

Multicast in a VPN II

OutInterface: 1/1/2:1
Out Label
: 262138
S2L Up Time : 0d 01:22:50
S2L Dn Time : 0d 00:00:00
RetryAttempt: 0
NextRetryIn : 0 sec
S2L Trans
: 2
CSPF Queries: 2
Failure Code: noError
Failure Node: n/a
ExplicitHops:
No Hops Specified
Actual Hops :
192.168.12.1(192.0.2.1) @
Record Label
: N/A
-> 192.168.12.2(192.0.2.2)
Record Label
: 262138
ComputedHops:
192.168.12.1(S)
-> 192.168.12.2(S)
LastResignal: n/a
------------------------------------------------------------------------------LSP vrf2-2-73740 S2L empty
------------------------------------------------------------------------------LSP Name
: vrf2-2-73740
S2l LSP ID : 38402
P2MP ID
: 2
S2l Grp Id : 2
Adm State
: Up
Oper State : Up
S2l State: : Active
:
S2L Name
: empty
To
: 192.0.2.3
S2l Admin
: Up
S2l Oper
: Up
OutInterface: 1/1/3:1
Out Label
: 262128
S2L Up Time : 0d 01:22:50
S2L Dn Time : 0d 00:00:00
RetryAttempt: 0
NextRetryIn : 0 sec
S2L Trans
: 2
CSPF Queries: 2
Failure Code: noError
Failure Node: n/a
ExplicitHops:
No Hops Specified
Actual Hops :
192.168.13.1(192.0.2.1) @
Record Label
: N/A
-> 192.168.13.2(192.0.2.3)
Record Label
: 262128
ComputedHops:
192.168.13.1(S)
-> 192.168.13.2(S)
LastResignal: n/a
------------------------------------------------------------------------------LSP vrf2-2-73740 S2L empty
------------------------------------------------------------------------------LSP Name
: vrf2-2-73740
S2l LSP ID : 38402
P2MP ID
: 2
S2l Grp Id : 3
Adm State
: Up
Oper State : Up
S2l State: : Active
:
S2L Name
: empty
To
: 192.0.2.4
S2l Admin
: Up
S2l Oper
: Up
OutInterface: 1/1/2:1
Out Label
: 262138
S2L Up Time : 0d 01:22:54
S2L Dn Time : 0d 00:00:00
RetryAttempt: 0
NextRetryIn : 0 sec
S2L Trans
: 3
CSPF Queries: 3
Failure Code: noError
Failure Node: n/a
ExplicitHops:
No Hops Specified
Actual Hops :
192.168.12.1(192.0.2.1) @
Record Label
: N/A
-> 192.168.12.2(192.0.2.2) @
Record Label
: 262138
-> 192.168.24.2(192.0.2.4)
Record Label
: 262136
ComputedHops:
192.168.12.1(S)
-> 192.168.12.2(S)
-> 192.168.24.2(S)
LastResignal: n/a
===============================================================================

Advanced Configuration Guide

Page 1243

Configuration

The last entry, vrf2-2-73740, provides the details of the S2L traced earlier, displaying the different
hops (PE-1, PE-2, and PE-3), the fast reroute protection (link protection is supported only) and the
labels used (262138 from PE-1 to PE-2, 262136 from PE-2 to PE-4). Note that on PE-1, although
only one has been shown, both links PE-1 to PE-3 and PE-1 to PE-2 are fast reroute protected.
If any of the protected links between PE-1 and PE-2 or PE-3 are broken, fast reroute will be
initiated. The protected bypass hops are displayed with the following command:
*A:PE-1# show router mpls bypass-tunnel protected-lsp p2mp detail
===============================================================================
MPLS Bypass Tunnels (Detail)
===============================================================================
------------------------------------------------------------------------------bypass-link192.168.12.2
------------------------------------------------------------------------------To
: 192.168.24.1
State
: Up
Out I/F
: 1/1/3:1
Out Label
: 262132
Up Time
: 0d 00:08:19
Active Time
: n/a
Reserved BW
: 0 Kbps
Protected LSP Count : 3
Type
: P2mp
Setup Priority : 7
Hold Priority
: 0
Class Type
: 0
Actual Hops
:
192.168.13.1(S)
-> 192.168.13.2(S)
-> 192.168.34.2(S)
-> 192.168.24.1(S)
Protected LSPs LSP Name
: vrf2-2-73740::empty
From
: 192.0.2.1
To
Avoid Node/Hop : 192.168.12.2
Downstream Label
Bandwidth
: 0 Kbps
LSP Name
From
Avoid Node/Hop
Bandwidth

:
:
:
:

vrf2-2-73740::empty
192.0.2.1
To
192.168.12.2
Downstream Label
0 Kbps

: 192.0.2.2
: 262138

: 192.0.2.4
: 262138

LSP Name
: vrf2-2-73732::empty
From
: 192.0.2.3
To
: 192.0.2.2
Avoid Node/Hop : 192.168.12.2
Downstream Label
: 262137
Bandwidth
: 0 Kbps
------------------------------------------------------------------------------bypass-link192.168.13.2
------------------------------------------------------------------------------To
: 192.168.34.1
State
: Up
Out I/F
: 1/1/2:1
Out Label
: 262131
Up Time
: 0d 00:08:10
Active Time
: n/a
Reserved BW
: 0 Kbps
Protected LSP Count : 2
Type
: P2mp
Setup Priority : 7
Hold Priority
: 0
Class Type
: 0
Actual Hops
:
192.168.12.1(S)
-> 192.168.12.2(S)
-> 192.168.24.2(S)
-> 192.168.34.1(S)
Protected LSPs LSP Name
: vrf2-2-73740::empty

Page 1244

Advanced Configuration Guide

Multicast in a VPN II

From
Avoid Node/Hop
Bandwidth

: 192.0.2.1
: 192.168.13.2
: 0 Kbps

To
Downstream Label

: 192.0.2.3
: 262128

LSP Name
: vrf2-2-73732::empty
From
: 192.0.2.2
To
: 192.0.2.3
Avoid Node/Hop : 192.168.13.2
Downstream Label
: 262127
Bandwidth
: 0 Kbps
===============================================================================

Advanced Configuration Guide

Page 1245

Configuration

Traffic Flow
The receiver RX-4, connected to CE-4, wishes to join the group 232.2.2.2 with source 192.168.2.1
and so sends an IGMPv3 report towards CE-4. CE-4 recognizes the report and sends a PIM join
towards the source, hence it reaches PE-1 where the source is connected to through CE-1. The
output below shows the debug seen on PE-4, where the PIM join is received from CE-4 and a BGP
update Source Join is sent to all PEs (note that only the update sent to PE-1 is shown).
40 2011/10/13 19:02:20.42 UTC MINOR: DEBUG #2001 vprn2 PIM[Instance 3 vprn2]
"PIM[Instance 3 vprn2]: pimJPProcessSG
pimJPProcessSG: (S,G)-> (192.168.2.1,232.2.2.2) type <S,G>, i/f int-PE-4-CE-4, u
pNbr 172.16.42.1 isJoin 1 isRpt 0 holdTime 210"
41 2011/10/13 19:02:20.42 UTC MINOR: DEBUG #2001 vprn2 PIM[Instance 3 vprn2]
"PIM[Instance 3 vprn2]: pimJPPrintFsmEvent
PIM JP Downstream: State NoInfo Event RxJoin, (S,G) (192.168.2.1,232.2.2.2) grou
pType <S,G>"
42 2011/10/13 19:02:20.42 UTC MINOR: DEBUG #2001 vprn2 PIM[Instance 3 vprn2]
"PIM[Instance 3 vprn2]: pimJPPrintFsmEvent
PIM JP Upstream: State NotJoined Event JoinDesiredTrue, (S,G) (192.168.2.1,232.2
.2.2) groupType <S,G>"
43 2011/10/13 19:02:20.42 UTC MINOR: DEBUG #2001 vprn2 PIM[Instance 3 vprn2]
"PIM[Instance 3 vprn2]: pimSGUpJoinDesiredTrue
No upstream interface. pSG (192.168.2.1,232.2.2.2) rpfType 3"
44 2011/10/13 19:02:20.42 UTC MINOR: DEBUG #2001 vprn2 PIM[Instance 3 vprn2]
"PIM[Instance 3 vprn2]: pimSGUpJoinDesiredTrue
pim 3 sg_type 2 refetch route type SPMSI pendingFetchMask 0x8"
45 2011/10/13 19:02:20.42 UTC MINOR: DEBUG #2001 vprn2 PIM[Instance 3 vprn2]
"PIM[Instance 3 vprn2]: pimSGUpJoinDesiredTrue
No upstream interface. pSG 0x5578f87c, (192.168.2.1,232.2.2.2) rpfType 3"
46 2011/10/13 19:02:20.42 UTC MINOR: DEBUG #2001 vprn2 PIM[Instance 3 vprn2]
"PIM[Instance 3 vprn2]: pimJPPrintFsmEvent
PIM JP Upstream: State Joined Event MribChange, (S,G) (192.168.2.1,232.2.2.2) gr
oupType <S,G>"
47 2011/10/13 19:02:20.42 UTC MINOR: DEBUG #2001 vprn2 PIM[Instance 3 vprn2]
"PIM[Instance 3 vprn2]: pimSGUpStateJMribChange
pSG 0x5578f87c, (192.168.2.1,232.2.2.2), type <S,G> oldMribNhopIp 0.0.0.0 oldRpf
NbrIp 0.0.0.0, oldRpfType NONE oldRpfIf 0 rptMribNhopIp 0.0.0.0, rptRpfNbrIp 0.0
.0.0 rtmReason 32"
48 2011/10/13 19:02:20.41 UTC MINOR: DEBUG #2001 vprn2 PIM[Instance 3 vprn2]
"PIM[Instance 3 vprn2]: pimSGUpStateJMribChange
pSG 0x5578f87c, (192.168.2.1,232.2.2.2), type <S,G> newMribNhopIp 192.0.2.1 newR
pfNbrIp 192.0.2.1 newRpfType REMOTE newRpfIf 73737"
49 2011/10/13 19:02:20.41 UTC MINOR: DEBUG #2001 Base Peer 1: 192.0.2.1
"Peer 1: 192.0.2.1: UPDATE
Peer 1: 192.0.2.1 - Send BGP UPDATE:
Withdrawn Length = 0
Total Path Attr Length = 69
Flag: 0x40 Type: 1 Len: 1 Origin: 0

Page 1246

Advanced Configuration Guide

Multicast in a VPN II

Flag: 0x40 Type: 2 Len: 0 AS Path:


Flag: 0x80 Type: 4 Len: 4 MED: 0
Flag: 0x40 Type: 5 Len: 4 Local Preference: 100
Flag: 0xc0 Type: 16 Len: 8 Extended Community:
target:192.0.2.1:3
Flag: 0x90 Type: 14 Len: 33 Multiprotocol Reachable NLRI:
Address Family MVPN_IPV4
NextHop len 4 NextHop 192.0.2.4
Type: Source-Join Len:22 RD: 64496:201 SrcAS: 64496 Src: 192.168.2.1 Grp
: 232.2.2.2
"

The following debug shows that PE-1 receives the BGP update Source Join with source
192.168.2.1 and group 232.2.2.2 and sends a PIM join towards CE-1:
67 2011/10/14 05:11:35.06 UTC MINOR: DEBUG #2001 Base Peer 1: 192.0.2.4
"Peer 1: 192.0.2.4: UPDATE
Peer 1: 192.0.2.4 - Received BGP UPDATE:
Withdrawn Length = 0
Total Path Attr Length = 69
Flag: 0x40 Type: 1 Len: 1 Origin: 0
Flag: 0x40 Type: 2 Len: 0 AS Path:
Flag: 0x80 Type: 4 Len: 4 MED: 0
Flag: 0x40 Type: 5 Len: 4 Local Preference: 100
Flag: 0xc0 Type: 16 Len: 8 Extended Community:
target:192.0.2.1:3
Flag: 0x90 Type: 14 Len: 33 Multiprotocol Reachable NLRI:
Address Family MVPN_IPV4
NextHop len 4 NextHop 192.0.2.4
Type: Source-Join Len:22 RD: 64496:201 SrcAS: 64496 Src: 192.168.2.1 Grp
: 232.2.2.2
"
68 2011/10/14 05:11:35.05 UTC MINOR: DEBUG #2001 vprn2 PIM[Instance 3 vprn2]
"PIM[Instance 3 vprn2]: pimJPProcessSG
pimJPProcessSG: (S,G)-> (192.168.2.1,232.2.2.2) type <S,G>, i/f mpls-if-73740, u
pNbr 192.0.2.1 isJoin 1 isRpt 0 holdTime 65535"
69 2011/10/14 05:11:35.06 UTC MINOR: DEBUG #2001 vprn2 PIM[Instance 3 vprn2]
"PIM[Instance 3 vprn2]: pimJPPrintFsmEvent
PIM JP Downstream: State NoInfo Event RxJoin, (S,G) (192.168.2.1,232.2.2.2) grou
pType <S,G>"
70 2011/10/14 05:11:35.06 UTC MINOR: DEBUG #2001 vprn2 PIM[Instance 3 vprn2]
"PIM[Instance 3 vprn2]: pimJPPrintFsmEvent
PIM JP Upstream: State NotJoined Event JoinDesiredTrue, (S,G) (192.168.2.1,232.2
.2.2) groupType <S,G>"
71 2011/10/14 05:11:35.06 UTC MINOR: DEBUG #2001 vprn2 PIM[Instance 3 vprn2]
"PIM[Instance 3 vprn2]: pimSGUpJoinDesiredTrue
pim 3 sg_type 2 refetch route type SPMSI pendingFetchMask 0x8"
72 2011/10/14 05:11:35.06 UTC MINOR: DEBUG #2001 vprn2 PIM[Instance 3 vprn2]
"PIM[Instance 3 vprn2]: pimSendJoinPrunePdu
pimSendJoinPrunePdu: if 3, adj 172.16.12.2"
73 2011/10/14 05:11:35.06 UTC MINOR: DEBUG #2001 vprn2 PIM[Instance 3 vprn2]

Advanced Configuration Guide

Page 1247

Configuration

"PIM[Instance 3 vprn2]: pimSGEncodeGroupSet


pimEncodeGroupSet: encoding groupset for group 232.2.2.2, numJoinedSrcs 1, numPr
unedSrcs 0"
74 2011/10/14 05:11:35.05 UTC MINOR: DEBUG #2001 vprn2 PIM[Instance 3 vprn2]
"PIM[Instance 3 vprn2]: pimSGEncodeGroupSet
pimEncodeGroupSet: Encoding Join for source 192.168.2.1"
75 2011/10/14 05:11:35.05 UTC MINOR: DEBUG #2001 vprn2 PIM[Instance 3 vprn2]
"PIM[Instance 3 vprn2]: pimSGEncodeGroupSet
pimEncodeGroupSet: num joined srcs 1, num pruned srcs 0"
76 2011/10/14 05:11:35.05 UTC MINOR: DEBUG #2001 vprn2 PIM[Instance 3 vprn2]
"PIM[Instance 3 vprn2]: pimSendJoinPrunePdu
pimSendJoinPrunePdu2: sending JP PDU with 1 groups."
77 2011/10/14 05:12:34.76 UTC MINOR: DEBUG #2001 vprn2 PIM[Instance 3 vprn2]
"PIM[Instance 3 vprn2]: pimJPPrintFsmEvent
PIM JP Upstream: State Joined Event JTTimerExp, (S,G) (192.168.2.1,232.2.2.2) gr
oupType <S,G>"
78 2011/10/14 05:12:34.76 UTC MINOR: DEBUG #2001 vprn2 PIM[Instance 3 vprn2]
"PIM[Instance 3 vprn2]: pimSendJoinPrunePdu
pimSendJoinPrunePdu: if 3, adj 172.16.12.2"
79 2011/10/14 05:12:34.76 UTC MINOR: DEBUG #2001 vprn2 PIM[Instance 3 vprn2]
"PIM[Instance 3 vprn2]: pimSGEncodeGroupSet
pimEncodeGroupSet: encoding groupset for group 232.2.2.2, numJoinedSrcs 1, numPr
unedSrcs 0"
80 2011/10/14 05:12:34.76 UTC MINOR: DEBUG #2001 vprn2 PIM[Instance 3 vprn2]
"PIM[Instance 3 vprn2]: pimSGEncodeGroupSet
pimEncodeGroupSet: Encoding Join for source 192.168.2.1"
81 2011/10/14 05:12:34.77 UTC MINOR: DEBUG #2001 vprn2 PIM[Instance 3 vprn2]
"PIM[Instance 3 vprn2]: pimSGEncodeGroupSet
pimEncodeGroupSet: num joined srcs 1, num pruned srcs 0"
82 2011/10/14 05:12:34.77 UTC MINOR: DEBUG #2001 vprn2 PIM[Instance 3 vprn2]
"PIM[Instance 3 vprn2]: pimSendJoinPrunePdu
pimSendJoinPrunePdu2: sending JP PDU with 1 groups."

Page 1248

Advanced Configuration Guide

Multicast in a VPN II

The BGP update source join received by PE-1 is displayed with the following command:
*A:PE-1# show router bgp routes mvpn-ipv4 type source-join
===============================================================================
BGP Router ID:192.0.2.1
AS:64496
Local AS:64496
===============================================================================
Legend Status codes : u - used, s - suppressed, h - history, d - decayed, * - valid
Origin codes : i - IGP, e - EGP, ? - incomplete, > - best, b - backup
===============================================================================
BGP MVPN-IPv4 Routes
===============================================================================
Flag RouteType
OriginatorIP
LocalPref
MED
RD
SourceAS
VPNLabel
Nexthop
SourceIP
As-Path
GroupIP
------------------------------------------------------------------------------u*>i Source-Join
100
0
64496:201
64496
192.0.2.4
192.168.2.1
No As-Path
232.2.2.2
------------------------------------------------------------------------------Routes : 1
===============================================================================

To verify the traffic: on PE-1 there is a group 232.2.2.2 with source 192.168.2.1, the RPF is CE-1,
and the multicast traffic is flowing from CE-1 to PE-1 using int-PE-1-CE-1 and the outgoing
interface is using the PMSI RSVP mpls-if-73740.
*A:PE-1# show router 2 pim group detail
===============================================================================
PIM Source Group ipv4
===============================================================================
Group Address
: 232.2.2.2
Source Address
: 192.168.2.1
RP Address
: 0
Flags
:
Type
: (S,G)
MRIB Next Hop
: 172.16.12.2
MRIB Src Flags
: remote
Keepalive Timer
: Not Running
Up Time
: 0d 00:10:48
Resolved By
: rtable-u
Up JP State
Up JP Rpt

: Joined
: Not Joined StarG

Up JP Expiry
: 0d 00:00:12
Up JP Rpt Override : 0d 00:00:00

Register State
: No Info
Reg From Anycast RP: No
Rpf Neighbor
: 172.16.12.2
Incoming Intf
: int-PE-1-CE-1
Outgoing Intf List : mpls-if-73740
Curr Fwding Rate
Forwarded Packets
Forwarded Octets
Spt threshold

:
:
:
:

0.0 kbps
0
0
0 kbps

Advanced Configuration Guide

Discarded Packets : 0
RPF Mismatches
: 0
ECMP opt threshold : 7

Page 1249

Configuration

Admin bandwidth
: 1 kbps
------------------------------------------------------------------------------Groups : 1
===============================================================================

On PE-4, the same (S,G) arrives in the incoming interface mpls-if-73737 and the outgoing
interface is int-PE-4-CE-4.
*A:PE-4# show router 2 pim group detail
===============================================================================
PIM Source Group ipv4
===============================================================================
Group Address
: 232.2.2.2
Source Address
: 192.168.2.1
RP Address
: 0
Flags
:
Type
: (S,G)
MRIB Next Hop
: 192.0.2.1
MRIB Src Flags
: remote
Keepalive Timer
: Not Running
Up Time
: 0d 00:12:40
Resolved By
: rtable-u
Up JP State
Up JP Rpt

: Joined
: Not Joined StarG

Up JP Expiry
: 0d 00:00:19
Up JP Rpt Override : 0d 00:00:00

Register State
: No Info
Reg From Anycast RP: No
Rpf Neighbor
: 192.0.2.1
Incoming Intf
: mpls-if-73737
Outgoing Intf List : int-PE-4-CE-4
Curr Fwding Rate
: 0.0 kbps
Forwarded Packets : 0
Discarded Packets : 0
Forwarded Octets
: 0
RPF Mismatches
: 0
Spt threshold
: 0 kbps
ECMP opt threshold : 7
Admin bandwidth
: 1 kbps
------------------------------------------------------------------------------Groups : 1
===============================================================================

When the receiver is not interested in the channel group any more, the receiver RX-4 sends an
IGMPv3 leave, PE-4 sends a PIM prune translated to a BGP MP_UNREACH NLRI to all PEs.
Note that, as mentioned before, rapid withdrawals are sent without waiting for the mrai (note that
for simplicity, only one BGP update is shown in the output debug).
92 2011/10/13 19:16:36.67 UTC MINOR: DEBUG #2001 vprn2 PIM[Instance 3 vprn2]
"PIM[Instance 3 vprn2]: pimJPProcessSG
pimJPProcessSG: (S,G)-> (192.168.2.1,232.2.2.2) type <S,G>, i/f int-PE-4-CE-4, u
pNbr 172.16.42.1 isJoin 0 isRpt 0 holdTime 210"
93 2011/10/13 19:16:36.67 UTC MINOR: DEBUG #2001 vprn2 PIM[Instance 3 vprn2]
"PIM[Instance 3 vprn2]: pimJPPrintFsmEvent
PIM JP Downstream: State Joined Event RxPrune, (S,G) (192.168.2.1,232.2.2.2) gro
upType <S,G>"
94 2011/10/13 19:16:36.67 UTC MINOR: DEBUG #2001 vprn2 PIM[Instance 3 vprn2]

Page 1250

Advanced Configuration Guide

Multicast in a VPN II

"PIM[Instance 3 vprn2]: pimJPPrintFsmEvent


PIM JP Downstream: State PrunePending Event PrunePendTimerExp, (S,G) (192.168.2.
1,232.2.2.2) groupType <S,G>"
95 2011/10/13 19:16:36.67 UTC MINOR: DEBUG #2001 vprn2 PIM[Instance 3 vprn2]
"PIM[Instance 3 vprn2]: pimJPPrintFsmEvent
PIM JP Upstream: State Joined Event JoinDesiredFalse, (S,G) (192.168.2.1,232.2.2
.2) groupType <S,G>"
96 2011/10/13 19:16:36.67 UTC MINOR: DEBUG #2001 Base Peer 1: 192.0.2.1
"Peer 1: 192.0.2.1: UPDATE
Peer 1: 192.0.2.1 - Send BGP UPDATE:
Withdrawn Length = 0
Total Path Attr Length = 31
Flag: 0x90 Type: 15 Len: 27 Multiprotocol Unreachable NLRI:
Address Family MVPN_IPV4
Type: Source-Join Len:22 RD: 64496:201 SrcAS: 64496 Src: 192.168.2.1 Grp
: 232.2.2.2
"

MVPN Source Redundancy


So far, the multicast traffic has been streamed towards router CE-1 from a single source. For
redundancy purposes, the source can be redundant (two sources attached to different CEs that
connect to a pair of PEs). To simulate the redundancy, CE-1 has been connected to both PE-1 and
PE-2, using VPRN 2, and ECMP (Equal Cost Multi Path) is configured with the value of 2 in all
PEs. With this configuration, any PE is able to reach the source through PE-1 and PE-2. The (S,G)
is the same as the one used in P2MP RSVP TE (192.168.2.1, 232.2.2.2). Figure 93 shows the
VPRN 2 topology with the source redundancy.

192.168.2.1/24

AS 64499

CE-1
VPRN2

.2

PE-1

PE-3

Loopback: 172.16.2.1/32

Loopback: 172.16.2.3/32

1/1/1:2
172.16.12.0/30
e-BGP

.1

VPRN2

.1

VPRN2

1/1/3

AS 64403

1/1/1:2
172.16.34.0/30
.1

STATIC

CE-3
.2

VPRN2

Source
1/1/1:4
172.16.15.0/30

AS 64402

CE-2

RX-2

VPRN2

.2

RX-3

e-BGP
1/1/2

AS 64496

1/1/2

.2
1/1/1:2
172.16.23.0/30

VPRN2

.1

STATIC

VPRN2

1/1/3

PE-2
Loopback: 172.16.2.2/32

AS 64404

1/1/1:2
172.16.42.0/30

.1
.1

STATIC

CE-4
.2

PE-4

VPRN2

RX-4

Loopback: 172.16.2.4/32
MVPNII_04

Figure 93: VPRN 2 Topology used for MVPN Source Redundancy

Advanced Configuration Guide

Page 1251

Configuration

The configuration change with respect to the previous section (P2MP RSVP-TE PMSIs) is an
additional interface created in both CE-1 and PE-2 (int-CE-1-PE-2 on CE-1 and int-PE-2-CE-1 on
PE-2), the addition of these interfaces to pim and also the creation an e-BGP session between the
two routers. The following is the configuration on PE-2 (CE-1 configuration changes are not
displayed for brevity).
*A:PE-2>config>service>vprn# info
---------------------------------------------description "P2MP RSVP"
ecmp 2
autonomous-system 64496
route-distinguisher 64496:202
vrf-target target:64496:200
interface "loopback" create
address 172.16.2.2/32
loopback
exit
interface "int-PE-2-CE-2" create
address 172.16.23.1/30
sap 1/1/1:2 create
exit
exit
interface "int-PE-2-CE-1" create
address 172.16.16.1/30
sap 1/1/4:2 create
exit
exit
bgp
group "external"
type external
peer-as 64499
neighbor 172.16.16.2
exit
exit
no shutdown
exit
pim
interface "loopback"
exit
interface "int-PE-2-CE-2"
exit
interface "int-PE-2-CE-1"
exit
rp
static
exit
bsr-candidate
shutdown
exit
rp-candidate
shutdown
exit
exit
no shutdown
exit
mvpn
auto-discovery default
c-mcast-signaling bgp

Page 1252

Advanced Configuration Guide

Multicast in a VPN II

provider-tunnel
inclusive
rsvp
lsp-template vrf2
no shutdown
exit
exit
exit
vrf-target unicast
exit
exit
spoke-sdp 12 create
no shutdown
exit
spoke-sdp 23 create
no shutdown
exit
spoke-sdp 24 create
no shutdown
exit
no shutdown
----------------------------------------------

Checking the routes on PE-4, the source is reachable through PE-1 and PE-2 as ECMP is set to 2.
Note that if the configuration of the VPRN is provisioned with autobind-mpls instead of static
spoke-SDPs, the command ignore-nh-metric is also needed.
*A:PE-4# show router 2 route-table
===============================================================================
Route Table (Service: 2)
===============================================================================
Dest Prefix[Flags]
Type
Proto
Age
Pref
Next Hop[Interface Name]
Metric
------------------------------------------------------------------------------* Truncated info
192.168.2.1/32
Remote BGP VPN 00h19m55s
170
192.0.2.1 (tunneled)
0
192.168.2.1/32
Remote BGP VPN 00h19m55s
170
192.0.2.2 (tunneled)
0
------------------------------------------------------------------------------No. of Routes: 11
Flags: L = LFA nexthop available
B = BGP backup route available
n = Number of times nexthop is repeated
===============================================================================

When PE-4 receives a c-join/prune, PE-4 needs to find the upstream multicast hop for the (S,G).
This is the Upstream Multihop Selection (UMH) and is configurable. The values are highest-ip,
hash-based and tunnel-status.
*A:PE-4>config>service>vprn>mvpn# umh-selection
- no umh-selection
- umh-selection {highest-ip|hash-based|tunnel-status}

Advanced Configuration Guide

Page 1253

Configuration

The default is highest-ip, which is the selection of the highest /32 IP addresses (in this set up, PE2 is preferred versus PE-1). A BGP c-join is sent with the route target equal to the VRF import
extended community distributed by PE-2 for the subnet of the source (see PE-4 debug show
below).
* Truncated info
12 2011/10/14 08:42:53.87 UTC MINOR: DEBUG #2001 vprn2 PIM[Instance 3 vprn2]
"PIM[Instance 3 vprn2]: pimSGUpStateJMribChange
pSG 0x5578f87c, (192.168.2.1,232.2.2.2), type <S,G> newMribNhopIp 192.0.2.2 newR
pfNbrIp 192.0.2.2 newRpfType REMOTE newRpfIf 73741"
13 2011/10/14 08:42:53.87 UTC MINOR: DEBUG #2001 Base Peer 1: 192.0.2.2
"Peer 1: 192.0.2.2: UPDATE
Peer 1: 192.0.2.2 - Send BGP UPDATE:
Withdrawn Length = 0
Total Path Attr Length = 69
Flag: 0x40 Type: 1 Len: 1 Origin: 0
Flag: 0x40 Type: 2 Len: 0 AS Path:
Flag: 0x80 Type: 4 Len: 4 MED: 0
Flag: 0x40 Type: 5 Len: 4 Local Preference: 100
Flag: 0xc0 Type: 16 Len: 8 Extended Community:
target:192.0.2.2:3
Flag: 0x90 Type: 14 Len: 33 Multiprotocol Reachable NLRI:
Address Family MVPN_IPV4
NextHop len 4 NextHop 192.0.2.4
Type: Source-Join Len:22 RD: 64496:202 SrcAS: 64496 Src: 192.168.2.1 Grp
: 232.2.2.2
"

The second option is hash-based, where the UMH is selected (both PEs are potentially possible
UMHs) after hashing the streams source and group addresses. For this example, PE-2 is also
preferred.
The third option, tunnel-status, is based on the status of the P2MP RSVP tunnel (not available in
mLDP or PIM). The roots PE-1 and PE-2 are sending BFD messages to the leaf PE-4 (in fact this
is UFD, unidirectional forwarding detection). PE-4s c-join for the (S,G) is sent to both PE-1 and
PE-2, and in return the traffic is forwarded from both PE-1 and PE-2 for the c-group onto the IPMSI; hence PE-4 receives two copies of the c-(S,G) stream. By configuration, the stream from
the primary PE-1 is selected by PE-4 to be forwarded to receiver RX-4. If BFD messages are no
longer received over the primary P2MP LSP, then stream from the standby PE-2 is selected and
forwarded to the receiver.
The configuration on PE-1 and PE-2 is similar and is as follows (only PE-2 is shown):
PE-2>configure service vprn 2
mvpn
auto-discovery default
c-mcast-signaling bgp
umh-selection tunnel-status
provider-tunnel
inclusive
rsvp
lsp-template vrf2
enable-bfd-root 100

Page 1254

Advanced Configuration Guide

Multicast in a VPN II

no shutdown
exit
exit
exit
vrf-target unicast
exit
exit

PE-1 and PE-2 are root. On PE-4 BFD is configured as leaf and the primary PE (PE-1) and backup
PE (PE-2) are also provisioned:
PE-4>configure service vprn 2
mvpn
auto-discovery default
c-mcast-signaling bgp
umh-selection tunnel-status
umh-pe-backup
umh-pe 192.0.2.1 standby 192.0.2.2
exit
provider-tunnel
inclusive
rsvp
lsp-template vrf2
enable-bfd-leaf
no shutdown
exit
exit
exit
vrf-target unicast
exit
exit

This BFD (UFD) configuration on the root establishes a session with the leaf where BFD packets
are only transmitted:
*A:PE-1>config>service>vprn# show router 2 bfd session
===============================================================================
BFD Session
===============================================================================
Interface
State
Tx Intvl Rx Intvl Multipl
Remote Address
Protocols
Tx Pkts
Rx Pkts
Type
------------------------------------------------------------------------------mpls-if-73747
Up (3)
100
0
3
127.0.0.0
pim
9955
0
central
------------------------------------------------------------------------------No. of BFD sessions: 1

On PE-4, two BFD sessions are received, one from each root (note that BFD packets are only
received):
*A:PE-4>config>service>vprn# show router 2 bfd session
===============================================================================
BFD Session
===============================================================================

Advanced Configuration Guide

Page 1255

Configuration

Interface
State
Tx Intvl Rx Intvl Multipl
Remote Address
Protocols
Tx Pkts
Rx Pkts
Type
------------------------------------------------------------------------------mpls-if-73747
Up (3)
0
100
3
192.0.2.1
pim
0
681
central
mpls-if-73748
Up (3)
0
100
3
192.0.2.2
pim
0
470
central
------------------------------------------------------------------------------No. of BFD sessions: 2
===============================================================================

PE-4 delivers the multicast traffic from the primary configured UMH, PE-1. If, as an example of a
failure condition, PE-1 goes down (reboot), PE-4 will switch to the PE-2 P2MP LSP.

MDT AFI SAFI


In the Draft-Rosen up to version 6, the default MDT is PIM Spare Mode only, and there is no autodiscovery mechanism available. From SR-OS Release 7.0 and beyond, it is possible to configure
PIM SSM with auto-discovery, using AFI 1 and SAFI 5. The Draft-Rosen version 7 allows use of
MDT PIM SM or SSM, and auto-discovery based on AFI 1 and SAFI 66 to distribute the default
MDT. Draft-Rosen version 9 adds a new MDT NLRI. The SR-OS has added the capability and
support of MDT SAFI as specified in draft-nalawade-idr-mdt-safi-03 and draft-rosen-vpn-mcast15.
MDT SAFI is used to discover PEs in a specific MVPN, so that PIM SSM can be used for default
MDT. The basic idea is the same as MVPN BGP auto-discovery, but it uses a different BGP SAFI.
BGP messages in which AFI=1 and SAFI=66 are "MDT-SAFI" messages. The NLRI format is 8byte-RD:IPv4-address followed by the MDT group address. The IPv4 address identifies the PE
that originated this route and the RD identifies a VRF in that PE. The group address must be an
IPv4 multicast group address and is used to build the P-tunnels.
All PEs attached to a given MVPN must specify the same group-address. MDT-SAFI routes do
not carry RTs and the group address is used to associate a received MDT-SAFI route with a VRF.
MDT SAFI can only be used when the implicit provider tunnel is PIM GRE based with a specific
IPv4 group address.
Note: For additional information on the use of PIM PMSIs, refer to Multicast in a VPN I on page
1147.
Figure 94 shows the topology of VPRN 3.

Page 1256

Advanced Configuration Guide

Multicast in a VPN II

192.168.3.1/24

AS 64499

CE-1
VPRN3

.2

PE-1

PE-3

Loopback: 172.16.3.1/32

Loopback: 172.16.3.3/32

1/1/1:3
172.16.13.0/30
e-BGP

.1

VPRN3

.1

VPRN3

1/1/3

AS 64403

1/1/1:3
172.16.35.0/30
.1

STATIC

CE-3
.2

VPRN3

Source

1/1/2

AS 64402

CE-2

RX-2

VPRN3

.2

AS 64496

1/1/2

.2
1/1/1:3
172.16.24.0/30

.1

STATIC

VPRN3

1/1/3

PE-2
Loopback: 172.16.3.2/32

AS 64404

1/1/1:3
172.16.43.0/30

.1
VPRN3

RX-3

.1

STATIC

CE-4
.2

PE-4

VPRN3

RX-4

Loopback: 172.16.3.4/32
MVPNII_05

Figure 94: VPRN 3 Topology used for MVPN Source Redundancy

In this scenario, there is no MPLS based PMSI, there is PIM in the core for the control plane and
the data traffic is GRE encapsulated. PIM needs to be configured in the base router on interface
system and on the other interfaces pointing to other PEs. PIM is used for c-signaling. In addition,
auto-discovery is provisioned to use mdt-safi and a PIM SSM inclusive PMSI with address
239.1.1.1 as the default MDT. The configuration, in all PEs, is like the following on PE-4:
*A:PE-4>config router
pim
interface "system"
exit
interface "int-PE-4-PE-2"
exit
interface "int-PE-4-PE-3"
exit
rp
static
exit
bsr-candidate
shutdown
exit
rp-candidate
shutdown
exit
exit
no shutdown
exit
*A:PE-4>config service vprn 3
description "PIM SSM"
autonomous-system 64496

Advanced Configuration Guide

Page 1257

Configuration

route-distinguisher 64496:304
vrf-target target:64496:300
interface "loopback" create
address 172.16.3.4/32
loopback
exit
interface "int-PE-4-CE-4" create
address 172.16.43.1/30
sap 1/1/1:3 create
exit
exit
pim
interface "loopback"
exit
interface "int-PE-4-CE-4"
exit
rp
static
exit
bsr-candidate
shutdown
exit
rp-candidate
shutdown
exit
exit
no shutdown
exit
mvpn
auto-discovery mdt-safi
provider-tunnel
inclusive
pim ssm 239.1.1.1
exit
exit
exit
vrf-target unicast
exit
exit
spoke-sdp 14 create
no shutdown
exit
spoke-sdp 24 create
no shutdown
exit
spoke-sdp 34 create
no shutdown
exit
no shutdown

Page 1258

Advanced Configuration Guide

Multicast in a VPN II

The following debug output shows a BGP update with MDT AFI SAFI:
2 2011/10/14 16:48:14.58 UTC MINOR: DEBUG #2001 Base Peer 1: 192.0.2.1
"Peer 1: 192.0.2.1: UPDATE
Peer 1: 192.0.2.1 - Send BGP UPDATE:
Withdrawn Length = 0
Total Path Attr Length = 62
Flag: 0x40 Type: 1 Len: 1 Origin: 0
Flag: 0x40 Type: 2 Len: 0 AS Path:
Flag: 0x80 Type: 4 Len: 4 MED: 0
Flag: 0x40 Type: 5 Len: 4 Local Preference: 100
Flag: 0xc0 Type: 16 Len: 8 Extended Community:
target:64496:300
Flag: 0x90 Type: 14 Len: 26 Multiprotocol Reachable NLRI:
Address Family MDT-SAFI
NextHop len 4 NextHop 192.0.2.4
[MDT-SAFI] Addr 192.0.2.4, Group 239.1.1.1, RD 64496:304

Advanced Configuration Guide

Page 1259

Conclusion

Conclusion
This chapter provides information to configure multicast within a VPRN with next generation
multicast VPN techniques. Specifically, the use of MPLS I-PMSIs (mLDP and P2MP RSVP-TE),
MVPN source redundancy and the complete set of features needed to interoperate with DraftRosen in live deployments are covered.

Page 1260

Advanced Configuration Guide

Multi-Chassis Endpoint for VPLS Active/


Standby Pseudowire

In This Chapter
This section provides information about multi-chassis endpoint for VPLS active/standby
pseudowire.
Topics in this section include:

Applicability on page 1262

Overview on page 1263

Configuration on page 1267

Conclusion on page 1291

Advanced Configuration Guide

Page 1261

Applicability

Applicability
The examples covered in this section are applicable to all 7x50 and 7710 SR series and were tested
on Release 7.0.R6. The 7750 SR-c4 is supported from 8.0R4 and higher.
Multi-chassis endpoint peers must be the same chassis type.

Page 1262

Advanced Configuration Guide

Multi-Chassis Endpoint for VPLS Active/Standby

Overview
When implementing a large VPLS, one of the limiting factors is the number of T-LDP sessions
required for the full mesh of SDPs. Mesh SDPs are required between all PEs participating in the
VPLS with a full mesh of T-LDP sessions.
This solution is not scalable, as the number of sessions grows more rapidly than the number of
participating PEs. Several options exist to reduce the number of T-LDP sessions required in a large
VPLS.
The first option is hierarchical VPLS (H-VPLS) with spoke SDPs. By using spoke SDPs between
two clouds of fully meshed PEs, any-to-any T-LDP sessions for all participating PEs are not
required.
However, if spoke SDP redundancy is required, STP must be used to avoid a loop in the VPLS.
Management VPLS can be used to reduce the number of STP instances and separate customer and
STP traffic (Figure 95).

Metro 1

Mesh

Mesh

Spoke

STP
Running in
M-VPLS

Metro 2

Spoke
Blocked
OSSG432

Figure 95: H-VPLS with STP

VPLS pseudowire redundancy provides H-VPLS redundant spoke connectivity. The active spoke
is in forwarding state, while the standby spoke is in blocking state. Hence, STP is not needed
anymore to break the loop, as illustrated in Figure 96.
However, the PE implementing the active and standby spokes represents a single point of failure
in the network.

Advanced Configuration Guide

Page 1263

Overview

Forwarding

Mesh

Active Spoke

Metro 1

Metro 2

Standby Spoke
Blocking RX + TX
OSSG433

Figure 96: VPLS Pseudowire Redundancy

Multi-chassis endpoint for VPLS active/standby pseudowire expands on the VPLS pseudowire
redundancy and allows the removal of the single point of failure.
There is only one spoke in forwarding state, all standby spokes are in blocking state. Mesh and
square resiliency are supported.
A mesh resiliency can protect against simultaneous node failure in the core and in the MC-EP
(double failure), but requires more SDPs (and thus more T-LDP sessions). Mesh resiliency is
illustrated in Figure 97.
Forwarding

Mesh

Mesh

Metro 1

MC-EP

Active Spoke

Metro 2

Standby
Spokes

Blocking RX + TX
OSSG434

Figure 97: Multi-Chassis Endpoint with Mesh Resiliency

Page 1264

Advanced Configuration Guide

Multi-Chassis Endpoint for VPLS Active/Standby

A square resiliency provides single failure node protection, and requires less SDPs (and thus less
T-LDP sessions). Square resiliency is illustrated in Figure 98.
Forwarding

Mesh

Mesh

Metro 1

MC-EP

Active Spoke

Metro 2

Standby Spoke

Blocking RX + TX
OSSG435

Figure 98: Multi-Chassis Endpoint with Square Resiliency

Advanced Configuration Guide

Page 1265

Overview

Network Topology
PE-3
192.0.2.3

PE-1
192.0.2.1

Mesh

Spoke Act

PE-6
192.0.2.6
Spoke Stby

Mesh

Sp

ok

PE-5
192.0.2.5

PE-8
192.0.2.8

St

VPLS 1

y
tb

ke

MC-EP

Mesh

Mesh

MC-EP

VPLS 2

Mesh

by

VPLS 3

o
Sp
Mesh

Spoke Stby

PE-4
192.0.2.4

Spoke Act

PE-2
192.0.2.2

Mesh

PE-7
192.0.2.7
OSSG431

Figure 99: Network Topology

The network topology is displayed in Figure 99.


The setup consists of:

Two core nodes (PE-1 and PE-2), and three nodes for each metro area (PE-3, PE-4, PE-5
and PE-6, PE-7, PE-8, respectively).

VPLS 1 is the core VPLS, used to interconnect the two metro areas represented by VPLS
2 and VPLS 3.

VPLS 2 will be connected to the core VPLS in mesh resiliency.

VPLS 3 will be connected to the core VPLS in square resiliency.

Note that three separate VPLS identifiers are used for clarity, however, the same identifier could
be used for each. For interoperation, only the same VC-ID is required to be used on both ends of
the spoke SDPs.
The following configuration tasks should be done first:

Page 1266

ISIS or OSPF throughout the network.

RSVP or LDP-signalled LSPs over the paths used for mesh/spoke SDPs.

Advanced Configuration Guide

Multi-Chassis Endpoint for VPLS Active/Standby

Configuration
SDP Configuration
On each PE, SDPs are created to match the topology described in Figure 99.
The convention for the SDP naming is: XY where X is the originating node and Y the target node.
An example of the SDP configuration in PE-3 (using LDP):
configure service
sdp 31 mpls create
far-end 192.0.2.1
ldp
keep-alive
shutdown
exit
no shutdown
exit
sdp 32 mpls create
far-end 192.0.2.2
ldp
keep-alive
shutdown
exit
no shutdown
exit
sdp 34 mpls create
far-end 192.0.2.4
ldp
keep-alive
shutdown
exit
no shutdown
exit
sdp 35 mpls create
far-end 192.0.2.5
ldp
keep-alive
shutdown
exit
no shutdown
exit
exit

Advanced Configuration Guide

Page 1267

Configuration

Verification of the SDPs on PE-3:


A:PE-3# show service sdp
===============================================================================
Services: Service Destination Points
===============================================================================
SdpId
Adm MTU
Opr MTU
IP address
Adm Opr
Deliver Signal
------------------------------------------------------------------------------31
0
1556
192.0.2.1
Up
Up
LDP
TLDP
32
0
1556
192.0.2.2
Up
Up
LDP
TLDP
34
0
1556
192.0.2.4
Up
Up
LDP
TLDP
35
0
1556
192.0.2.5
Up
Up
LDP
TLDP
------------------------------------------------------------------------------Number of SDPs : 4
------------------------------------------------------------------------------===============================================================================
A:PE-3#

Page 1268

Advanced Configuration Guide

Multi-Chassis Endpoint for VPLS Active/Standby

Full Mesh VPLS Configuration


Next, three fully meshed VPLs services are configured.

VPLS 1 is the core VPLS, on PE-1 and PE-2

VPLS 2 is the metro 1 VPLS, on PE-3, PE-4 and PE-5

VPLS 3 is the metro 2 VPLS, on PE-6, PE-7 and PE-8

On PE-1 (similar configuration on PE-2):


configure service
vpls 1 customer 1 create
description "core VPLS"
stp
shutdown
exit
mesh-sdp 12:1 create
exit
no shutdown
exit
exit

On PE-3 (similar configuration on PE-4 and PE-5):


configure service
description "Metro 1 VPLS"
vpls 2 customer 1 create
stp
shutdown
exit
mesh-sdp 34:2 create
exit
mesh-sdp 35:2 create
exit
no shutdown
exit
exit

On PE-6 (similar configuration on PE-7 and PE-8):


configure service
description "Metro 2 VPLS"
vpls 3 customer 1 create
stp
shutdown
exit
mesh-sdp 67:3 create
exit
mesh-sdp 68:3 create

Advanced Configuration Guide

Page 1269

Configuration

exit
no shutdown
exit
exit

Verification of the VPLS

The service must be operationally up.

All mesh SDPs must be up in the VPLS service.

On PE-6 (similar on other nodes):


A:PE-6# show service id 3 base
===============================================================================
Service Basic Information
===============================================================================
Service Id
: 3
Vpn Id
: 0
Service Type
: VPLS
Description
: (Not Specified)
Customer Id
: 1
Last Status Change: 12/03/2009 14:05:31
Last Mgmt Change : 12/03/2009 14:05:17
Admin State
: Up
Oper State
: Up
MTU
: 1514
Def. Mesh VC Id
: 3
SAP Count
: 0
SDP Bind Count
: 3
Snd Flush on Fail : Disabled
Host Conn Verify : Disabled
Propagate MacFlush: Disabled
Def. Gateway IP
: None
Def. Gateway MAC : None
------------------------------------------------------------------------------Service Access & Destination Points
------------------------------------------------------------------------------Identifier
Type
AdmMTU OprMTU Adm Opr
------------------------------------------------------------------------------sdp:67:3 M(192.0.2.7)
n/a
0
1556
Up
Up
sdp:68:3 M(192.0.2.8)
n/a
0
1556
Up
Up
===============================================================================
A:PE-6#

Page 1270

Advanced Configuration Guide

Multi-Chassis Endpoint for VPLS Active/Standby

Multi-Chassis Configuration
Multi-chassis will be configured on the MC peers PE-3, PE-4 and PE-6, PE-7. The peer system
address is configured, and mc-endpoint will be enabled.
On PE-3 (similar configuration on PE-4, PE-6 and PE-7):
configure redundancy
multi-chassis
peer 192.0.2.4 create
mc-endpoint
no shutdown
exit
no shutdown
exit
exit
exit

Verification of the multi-chassis synchronization:


If the multi-chassis synchronization fails, both nodes will fall back to single-chassis mode. In that
case, two spoke SDPs could become active at the same time. It is important to verify the multichassis synchronization before enabling the redundant spoke SDPs.
A:PE-3# show redundancy multi-chassis mc-endpoint peer 192.0.2.4
===============================================================================
Multi-Chassis MC-Endpoint
===============================================================================
Peer Addr
: 192.0.2.4
Peer Name
:
Admin State
: up
Oper State
: up
Last State chg : 12/03/2009 14:08:45 Source Addr
: 0.0.0.0
System Id
: 26:54:ff:00:00:00
Sys Priority
: 0
Keep Alive Intvl: 10
Hold on Nbr Fail
: 3
Passive Mode
: disabled
Psv Mode Oper
: No
Boot Timer
: 300
BFD
: disabled
Last update
: 12/08/2009 09:17:41 MC-EP Count
: 1
===============================================================================
A:PE-3#

Advanced Configuration Guide

Page 1271

Configuration

Mesh Resiliency Configuration


PE-3 and PE-4 will be connected to the core VPLS in mesh resiliency.

First an endpoint is configured.

The no suppress-standby-signaling is needed to block the standby spoke SDP.

The multi-chassis endpoint peer is configured. The mc-endpoint ID must match between
the two peers.

On PE-3 (similar on PE-4):


configure service
vpls 2 customer 1 create
endpoint "core" create
no suppress-standby-signaling
mc-endpoint 1
mc-ep-peer 192.0.2.4
exit
exit
exit

Two spoke SDPs are configured on each peer of the multi-chassis to the two nodes of the core
VPLS (mesh resiliency). Each spoke SDP refers to the endpoint core.
The precedence is defined on the spoke SDPs as follows:

Spoke SDP 31 on PE-3 will be active. It is configured as primary (= precedence 0).

Spoke SDP 32 on PE-3 will be the first backup. It is configured with precedence 1.

Spoke SDP 41 on PE-4 will be the second backup. It is configured with precedence 2.

Spoke SDP 42 on PE-4 will be the third backup. It is configured with precedence 3.

On PE-3 (similar on PE-4):


configure service
vpls 2 customer 1 create
spoke-sdp 31:1 endpoint "core" create
stp
shutdown
exit
precedence primary
exit
spoke-sdp 32:1 endpoint "core" create
stp
shutdown
exit
precedence 1
exit
exit
exit

Page 1272

Advanced Configuration Guide

Multi-Chassis Endpoint for VPLS Active/Standby

Verification of the spoke SDPs:


On PE-3 and PE-4, the spoke SDPs must be up.
A:PE-3# show service id 2 sdp
===============================================================================
Services: Service Destination Points
===============================================================================
SdpId
Type IP address
Adm
Opr
I.Lbl
E.Lbl
------------------------------------------------------------------------------31:1
Spok 192.0.2.1
Up
Up
131059
131062
32:1
Spok 192.0.2.2
Up
Up
131064
131067
34:2
Mesh 192.0.2.4
Up
Up
131068
131067
35:2
Mesh 192.0.2.5
Up
Up
131063
131063
------------------------------------------------------------------------------Number of SDPs : 4
------------------------------------------------------------------------------===============================================================================
A:PE-3#

The endpoints on PE-3 and PE-4 can be verified. One spoke SDP is in Tx-Active mode (31 on PE1 because it is configured as primary).
A:PE-3# show service id 2 endpoint core | match "Tx Active"
Tx Active
: 31:1
Tx Active Up Time
: 0d 00:03:04
Tx Active Change Count
: 15
Last Tx Active Change
: 12/08/2009 15:24:54

There is no active spoke SDP on PE-4.


A:PE-4# show service id 2 endpoint | match "Tx Active"
Tx Active
: none
Tx Active Up Time
: 0d 00:00:00
Tx Active Change Count
: 18

Advanced Configuration Guide

Page 1273

Configuration

On PE-1 and PE-2, the spoke SDPs are operationally up.


A:PE-1# show service id 1 sdp
===============================================================================
Services: Service Destination Points
===============================================================================
SdpId
Type IP address
Adm
Opr
I.Lbl
E.Lbl
------------------------------------------------------------------------------12:1
Mesh 192.0.2.2
Up
Up
131060
131060
13:1
Spok 192.0.2.3
Up
Up
131062
131059
14:1
Spok 192.0.2.4
Up
Up
131063
131060
------------------------------------------------------------------------------Number of SDPs : 3
------------------------------------------------------------------------------A:PE-1#

However, because pseudowire signaling has been enabled, only one spoke SDP will be active, the
others are set in standby.
On PE-1, spoke SDP 13 is active (no pseudowire bit signalled from PE-3).
And the spoke SDP 14 is signalled in standby by PE-4.
A:PE-1#
Peer Pw
A:PE-1#
Peer Pw

show service id 1 sdp 13:1 detail | match "Peer Pw Bits"


Bits
: None
show service id 1 sdp 14:1 detail | match "Peer Pw Bits"
Bits
: pwFwdingStandby

On PE-2, both spoke SDPs are signalled in standby.


A:PE-2#
Peer Pw
A:PE-2#
Peer Pw

show service id 1 sdp 23:1 detail | match "Peer Pw Bits"


Bits
: pwFwdingStandby
show service id 1 sdp 24:1 detail | match "Peer Pw Bits"
Bits
: pwFwdingStandby

There is one active and three standby spoke SDPs.

Page 1274

Advanced Configuration Guide

Multi-Chassis Endpoint for VPLS Active/Standby

Square Resiliency Configuration


PE-6 and PE-7 will be connected to the core VPLS in square resiliency.

First an endpoint is configured.

The no suppress-standby-signaling is needed to block the standby spoke SDP.

The multi-chassis endpoint peer is configured. The mc-endpoint ID must match between
the two peers.

On PE-7 (similar on PE-6):


configure service
vpls 3 customer 1 create
endpoint "core" create
no suppress-standby-signaling
mc-endpoint 1
mc-ep-peer 192.0.2.6
exit
exit
exit
exit

One spoke SDP is configured on each peer of the multi-chassis to one node of the core VPLS
(square resiliency). Each spoke SDP refers to the endpoint core.
The precedence will be defined on the spoke SDPs as follows:

Spoke SDP 72 on PE-7 will be active. It is configured as primary (= precedence 0)

Spoke SDP 61 on PE-6 will be the first backup. It is configured with precedence 1.

On PE-7 (similar on PE-6):


configure service
vpls 3 customer 1 create
spoke SDP 72:1 endpoint "core" create
stp
shutdown
exit
precedence primary
exit
exit
exit

Advanced Configuration Guide

Page 1275

Configuration

Verification of the spoke SDPs.


On PE-6 and PE-7, the spoke SDPs must be up.
A:PE-7# show service id 3 sdp
===============================================================================
Services: Service Destination Points
===============================================================================
SdpId
Type IP address
Adm
Opr
I.Lbl
E.Lbl
------------------------------------------------------------------------------72:1
Spok 192.0.2.2
Up
Up
131063
131062
76:3
Mesh 192.0.2.6
Up
Up
131062
131064
78:3
Mesh 192.0.2.8
Up
Up
131068
131066
------------------------------------------------------------------------------Number of SDPs : 3
------------------------------------------------------------------------------===============================================================================
A:PE-7#

The endpoints on PE-7 and PE-6 can be verified. One spoke SDP is in Tx-Active mode (72 on PE7 because it is configured as primary).
A:PE-7# show service id 3 endpoint | match "Tx Active"
Tx Active
: 72:1
Tx Active Up Time
: 0d 04:19:01
Tx Active Change Count
: 3
Last Tx Active Change
: 12/08/2009 11:02:10

There are no active spoke SDP on PE-6.


A:PE-6# show service id 3 endpoint | match "Tx Active"
Tx Active
: none
Tx Active Up Time
: 0d 00:00:00
Tx Active Change Count
: 2
Last Tx Active Change
: 12/08/2009 11:17:31

The output shows that on PE-1, spoke SDP 16 is signalled with peer in standby mode.
A:PE-1# show service id 1 sdp 16:1 detail | match "Peer Pw Bits"
Peer Pw Bits
: pwFwdingStandby

Page 1276

Advanced Configuration Guide

Multi-Chassis Endpoint for VPLS Active/Standby

On PE-2, the spoke SDP 27 is signalled with peer active (no pseudowire bits).
A:PE-2# show service id 1 sdp 27:1 detail | match "Peer Pw Bits"
Peer Pw Bits
: None

There is one active and one standby spoke SDPs.

Advanced Configuration Guide

Page 1277

Configuration

Additional Parameters
Multi-Chassis
Peer Failure Detection
The default mechanism is based on the keepalives exchanged between the peers.
A:PE-3# configure redundancy multi-chassis peer 192.0.2.4 mc-endpoint
[no] hold-on-neighb* - Configure hold time applied on neighbor failure
[no] keep-alive-int* - Configure keep alive interval for this MC-Endpoint

Keep-alive-interval is the interval at which keepalives are sent to the MC peer. It is set in tenths of
a second from 5 to 500), with a default value of 5.
Hold-on-neighbor-failure is the number of keep-alive-intervals that the node will wait for a packet
from the peer before assuming it has failed. After this interval, the node will revert to single
chassis behavior. It can be set from 2 to 25 with a default value of 3.

BFD Session
BFD is another peer failure mechanism. It can be used to speed up the convergence in case of peer
loss.
A:PE-3# configure redundancy multi-chassis peer 192.0.2.4 mc-endpoint
[no] bfd-enable
- Configure BFD

It is using the centralized BFD session. BFD must be enabled on the system interface.
configure router
interface "system"
address 192.0.2.3/32
bfd 100 receive 100 multiplier 3
exit
exit

Page 1278

Advanced Configuration Guide

Multi-Chassis Endpoint for VPLS Active/Standby

Verification of the BFD session


A:PE-3# show router bfd session
===============================================================================
BFD Session
===============================================================================
Interface
State
Tx Intvl Rx Intvl Mult
Remote Address
Protocol
Tx Pkts
Rx Pkts
------------------------------------------------------------------------------system
Up (3)
100
100
3
192.0.2.4
mcep
65
65
------------------------------------------------------------------------------No. of BFD sessions: 1
===============================================================================
A:PE-3#

Boot Timer
A:PE-3# configure redundancy multi-chassis peer 192.0.2.4 mc-endpoint
[no] boot-timer
- Configure boot timer interval

The boot-timer command specifies the time after a reboot that the node will try to establish a
connection with the MC peer before assuming a peer failure. In case of failure, the node will revert
to single chassis behavior.

System Priority
A:PE-3# configure redundancy multi-chassis peer 192.0.2.4 mc-endpoint
[no] system-priority - Configure system priority

The system priority influences the selection of the MC master. The lowest priority node will
become the master.
In case of equal priorities, the lowest system-id (=chassis MAC address) will become the master.

Advanced Configuration Guide

Page 1279

Configuration

VPLS Endpoint and Spoke SDP


Ignore Standby Pseudowire Bits
A:PE-1# configure service vpls 1 spoke-sdp 14:1
ignore-standby-signaling

The peer pseudowire status bits are ignored and traffic is forwarded over the spoke SDP.
It can speed up convergence for multicast traffic in case of spoke SDP failure.
Traffic sent over the standby spoke SDP will be discarded by the peer.
In this topology, if the ignore-standby-signaling command is enabled on PE-1, it sends MC
traffic to PE-3 and PE-4 (and to PE-6). If PE-3 fails, PE-4 can start forwarding traffic in the VPLS
as soon as it detects PE-3 being down. There is no signaling needed between PE-1 and PE-4.

Block-on-Mesh-Failure
A:PE-3# configure service vpls 2 endpoint core
block-on-mesh-failure

In case a PE loses all the mesh SDPs of a VPLS, it should block the spoke SDPs to the core VPLS,
and inform the MC-EP peer who can activate one of its spoke SDPs.
If block-on-mesh-failure is enabled, the PE will signal all the pseudowires of the endpoint in
standby.
In this topology, if PE3 does not have any valid mesh SDP to the VPLS 2 mesh, it will set the
spoke SDPs under endpoint core in standby.
When block-on-mesh-failure is activated under an endpoint, it is automatically set under the spoke
SDPs belonging to this endpoint.
A:PE-3>config>service>vpls# info
---------------------------------------------endpoint "core" create
exit
spoke-sdp 31:1 endpoint "core" create
precedence primary
exit
spoke-sdp 32:1 endpoint "core" create
precedence 1
exit
mesh-sdp 34:2 create
exit
mesh-sdp 35:2 create

Page 1280

Advanced Configuration Guide

Multi-Chassis Endpoint for VPLS Active/Standby

exit
no shutdown
---------------------------------------------A:PE-3>config>service>vpls# endpoint core block-on-mesh-failure
A:PE-3>config>service>vpls# info
---------------------------------------------endpoint "core" create
block-on-mesh-failure
exit
spoke-sdp 31:1 endpoint "core" create
block-on-mesh-failure
precedence primary
exit
spoke-sdp 32:1 endpoint "core" create
block-on-mesh-failure
precedence 1
exit
mesh-sdp 34:2 create
exit
mesh-sdp 35:2 create
exit
no shutdown
---------------------------------------------A:PE-3>config>service>vpls#

Advanced Configuration Guide

Page 1281

Configuration

Precedence
A:PE-3# configure service vpls 2 spoke-sdp 31:1
[no] precedence
- Configure the spoke-sdp precendence

The precedence is used to indicate in which order the spoke SDPs should be used. The value is
from 0 to 4 (0 being primary), the lowest having higher priority. The default value is 4.

Revert-Time
A:PE-3# configure service vpls 2 endpoint core
[no] revert-time
- Configure the time to wait before reverting to primary
spoke-sdp

If the precedence is equal between the spoke SDPs, there is no revertive behavior. Changing the
precedence of a spoke SDP will not trigger a revert. The default is no revert.

MAC-Flush Parameters
When a spoke SDP goes from standby to active (due to the active spoke SDP failure), the node
will send a flush-all-but-mine message.
After a restoration of the spoke SDP, a new flush-all-but-mine message will be sent.
A node configured with propagate MAC flush will forward the flush messages received on the
spoke-SDP to its other mesh/spoke SDPs.
A:PE-1# configure service vpls 1
propagate-mac-flush

A node configured with send flush on failure will send a flush-all-from-me message when one
of its SDPs goes down.
A:PE-1# configure service vpls 1
send-flush-on-failure

Page 1282

Advanced Configuration Guide

Multi-Chassis Endpoint for VPLS Active/Standby

Failure Scenarios
For the subsequent failure scenarios, the configuration of the nodes is as described in the
Configuration on page 1267.

Core Node Failure


When the Core Node PE-1 fails, the spoke SDPs from PE-3 and PE-4 go down.
Because the spoke SDP 31 between PE-3 and PE-4 was active, the MC master (PE-3 in this case)
will select the next best spoke SDP, which will be 32 between PE-3 and PE-2 (precedence 1). See
Figure 100.

PE-1

MC-EP

PE-3

PE-4

PE-2
OSSG436

Figure 100: Core Node Failure

A:PE-3# show service id 2 endpoint


===============================================================================
Service 2 endpoints
===============================================================================
Endpoint name
: core
Description
: (Not Specified)
Revert time
: 0
Act Hold Delay
: 0
Ignore Standby Signaling
: false
Suppress Standby Signaling
: false
Block On Mesh Fail
: false
Multi-Chassis Endpoint
: 1
MC Endpoint Peer Addr
: 192.0.2.4
Psv Mode Active
: No
Tx Active
: 32:1
Tx Active Up Time
: 0d 00:01:45
Tx Active Change Count
: 19
Last Tx Active Change
: 12/08/2009 16:09:07

Advanced Configuration Guide

Page 1283

Configuration

------------------------------------------------------------------------------Members
------------------------------------------------------------------------------Spoke-sdp: 31:1 Prec:0
Oper Status: Down
Spoke-sdp: 32:1 Prec:1
Oper Status: Up
===============================================================================
A:PE-3#

A:PE-4# show service id 2 endpoint


===============================================================================
Service 2 endpoints
===============================================================================
Endpoint name
: core
Description
: (Not Specified)
Revert time
: 0
Act Hold Delay
: 0
Ignore Standby Signaling
: false
Suppress Standby Signaling
: false
Block On Mesh Fail
: false
Multi-Chassis Endpoint
: 1
MC Endpoint Peer Addr
: 192.0.2.3
Psv Mode Active
: No
Tx Active
: none
Tx Active Up Time
: 0d 00:00:00
Tx Active Change Count
: 21
Last Tx Active Change
: 12/08/2009 16:08:12
------------------------------------------------------------------------------Members
------------------------------------------------------------------------------Spoke-sdp: 41:1 Prec:2
Oper Status: Down
Spoke-sdp: 42:1 Prec:3
Oper Status: Up
===============================================================================
A:PE-4#

Page 1284

Advanced Configuration Guide

Multi-Chassis Endpoint for VPLS Active/Standby

Multi-Chassis Node Failure


PE-1

MC-EP

PE-3

PE-4

PE-2
OSSG437

Figure 101: Multi-Chassis Node Failure

When the multi-chassis node PE-3 fails, both spoke SDPs from PE-3 go down.
PE-4 reverts to single chassis mode and selects the best spoke SDP, which will be 41 between PE4 and PE-1 (precedence 2). See Figure 101.
A:PE-4# show redundancy multi-chassis mc-endpoint peer 192.0.2.3
===============================================================================
Multi-Chassis MC-Endpoint
===============================================================================
Peer Addr
: 192.0.2.3
Peer Name
:
Admin State
: up
Oper State
: down
Last State chg : 12/08/2009 15:41:58 Source Addr
: 0.0.0.0
System Id
: 1e:28:ff:00:00:00
Sys Priority
: 0
Keep Alive Intvl: 10
Hold on Nbr Fail
: 3
Passive Mode
: disabled
Psv Mode Oper
: No
Boot Timer
: 300
BFD
: disabled
Last update
: 12/08/2009 15:05:08 MC-EP Count
: 1
===============================================================================
A:PE-4#

A:PE-4# show service id 2 endpoint


===============================================================================
Service 2 endpoints
===============================================================================
Endpoint name
: core
Description
: (Not Specified)
Revert time
: 0
Act Hold Delay
: 0
Ignore Standby Signaling
: false
Suppress Standby Signaling
: false
Block On Mesh Fail
: false
Multi-Chassis Endpoint
: 1
MC Endpoint Peer Addr
: 192.0.2.3

Advanced Configuration Guide

Page 1285

Configuration

Psv Mode Active


: No
Tx Active
: 41:1
Tx Active Up Time
: 0d 00:00:13
Tx Active Change Count
: 19
Last Tx Active Change
: 12/08/2009 15:41:58
------------------------------------------------------------------------------Members
------------------------------------------------------------------------------Spoke-sdp: 41:1 Prec:2
Oper Status: Up
Spoke-sdp: 42:1 Prec:3
Oper Status: Up
===============================================================================
A:PE-4#

Page 1286

Advanced Configuration Guide

Multi-Chassis Endpoint for VPLS Active/Standby

Multi-Chassis Communication Failure


If the multi-chassis communication is interrupted, both nodes will revert to single chassis mode.
To simulate a communication failure between the two nodes, define a static route on PE-3 that will
black-hole the system address of PE-4.
A:PE-3# configure router
A:PE-3>config>router# static-route 192.0.2.4/32 black-hole

Verify that the MC synchronization is down.


A:PE-4# show redundancy multi-chassis mc-endpoint peer 192.0.2.3
===============================================================================
Multi-Chassis MC-Endpoint
===============================================================================
Peer Addr
: 192.0.2.3
Peer Name
:
Admin State
: up
Oper State
: down
Last State chg : 12/11/2009 15:12:25 Source Addr
: 0.0.0.0
System Id
: 1e:28:ff:00:00:00
Sys Priority
: 0
Keep Alive Intvl: 10
Hold on Nbr Fail
: 3
Passive Mode
: disabled
Psv Mode Oper
: No
Boot Timer
: 300
BFD
: disabled
Last update
: 12/08/2009 15:05:08 MC-EP Count
: 1
===============================================================================
A:PE-4#

The spoke SDPs are active on PE-3 and on PE-4.


A:PE-3# show service id 2 endpoint | match "Tx Active"
Tx Active
: 31:1
Tx Active Up Time
: 1d 23:29:04
Tx Active Change Count
: 20
Last Tx Active Change
: 12/09/2009 15:50:22
A:PE-4# show service id 2 endpoint | match "Tx Active"
Tx Active
: 42:1
Tx Active Up Time
: 0d 00:06:27
Tx Active Change Count
: 23

This can potentially cause a loop in the system. The Passive Mode on page 1288 explains how to
avoid this loop.

Advanced Configuration Guide

Page 1287

Configuration

Passive Mode
As in Multi-Chassis Communication Failure on page 1287, if there is a failure in the multi-chassis
communication, both nodes will assume that the peer is down and will revert to single-chassis
mode. This can create loops because two spoke SDPs can become active.
One solution is to synchronize the two core nodes, and configure them in passive mode. See
Figure 102.
In passive mode, both peers will stay dormant as long as one active spoke SDP is signalled from
the remote end. If more than one spoke SDP becomes active, the MC-EP algorithm will select the
best SDP. All other spoke SDPs are blocked locally (in Rx and Tx directions). There is no
signaling sent to the remote PEs.
If one peer is configured in passive mode, the other peer will be forced to passive mode as well.
The no suppress-standby-signaling and no ignore-standby-signaling commands are required.

PE-4

PE-1

MC-EP Passive

MC-EP

PE-3

PE-2
OSSG438

Figure 102: Multi-Chassis Passive Mode

Page 1288

Advanced Configuration Guide

Multi-Chassis Endpoint for VPLS Active/Standby

The following output shows the multi-chassis configuration on PE-1 (similar on PE-2).
A:PE-1# configure redundancy
multi-chassis
peer 192.0.2.2 create
mc-endpoint
no shutdown
passive-mode
exit
no shutdown
exit
exit

The following output shows the VPLS spoke SDPs configuration on PE-1 (similar on PE-2)
A:PE-1# configure service vpls 1
endpoint "metro1" create
no suppress-standby-signaling
mc-endpoint 1
mc-ep-peer 192.0.2.2
exit
exit
spoke-sdp 13:1 endpoint "metro1" create
stp
shutdown
exit
exit
spoke-sdp 14:1 endpoint "metro1" create
stp
shutdown
exit
exit

To simulate a communication failure between the two nodes, a static route is defined on PE-3 that
will black-hole the system address of PE-4.
A:PE-3# configure router
A:PE-3>config>router# static-route 192.0.2.4/32 black-hole

The spoke SDPs are active on PE-3 and on PE-4.


A:PE-3# show service id 2 endpoint | match "Tx Active"
Tx Active
: 31:1
Tx Active Up Time
: 1d 23:29:04
Tx Active Change Count
: 20
Last Tx Active Change
: 12/09/2009 15:50:22
A:PE-4# show service id 2 endpoint | match "Tx Active"
Tx Active
: 42:1
Tx Active Up Time
: 0d 00:06:27
Tx Active Change Count
: 23

Advanced Configuration Guide

Page 1289

Configuration

PE-1 and PE-2 have blocked one spoke SDP which avoids a loop in the VPLS.
A:PE-1# show service id 1 endpoint metro1 | match "Tx Active"
Tx Active
: none
Tx Active Up Time
: 0d 00:00:00
Tx Active Change Count
: 4
Last Tx Active Change
: 12/11/2009 15:44:35
A:PE-2# show service id 1 endpoint metro1 | match "Tx Active"
Tx Active
: 24:1
Tx Active Up Time
: 0d 00:02:39
Tx Active Change Count
: 1
Last Tx Active Change
: 12/11/2009 15:44:35

The passive nodes do not set the pseudowire status bits; hence, the nodes PE-3 and PE-4 are not
aware that one spoke SDP is blocked.

Page 1290

Advanced Configuration Guide

Multi-Chassis Endpoint for VPLS Active/Standby

Conclusion
Multi-chassis endpoint for VPLS active/standby pseudowire allows the building of hierarchical
VPLS without single point of failure, and without requiring STP to avoid loops.
Care must be taken to avoid loops. The multi-chassis peer communication is important and should
be possible on different interfaces.
Passive mode can be a solution to avoid loops in case of multi-chassis communication failure.

Advanced Configuration Guide

Page 1291

Conclusion

Page 1292

Advanced Configuration Guide

Multi-Chassis APS and Pseudowire


Redundancy Interworking

In This Chapter
This section describes multi-chassis APS and pseudowire redundancy interworking.
Topics in this section include:

Applicability on page 1294

Overview on page 1295

Configuration on page 1298

Conclusion on page 1314

Advanced Configuration Guide

Page 1293

Applicability

Applicability
Multi-chassis Automatic Protection Switching (MC-APS) is supported on 7x50 platforms
including 7710. The configuration in this chapter was tested on release 6.0R2 and includes the use
of the ATM ports. Refer to the Release Notes for information about support of ATM (and other)
MDAs on various platforms as well as MC-APS restrictions.

Page 1294

Advanced Configuration Guide

Multi-Chassis APS and Pseudowire Redundancy

Overview
MC-APS
MC-APS is an extension to the APS feature to provide not only link redundancy but also node
level redundancy. It can protect against nodal failure by configuring the working circuit of an APS
group on one node while configuring the protect circuit of the same APS group on a different
node.
The two nodes connect to each other with an IP link that is used to establish a signaling path
between them. The relevant APS groups in both the working and protection routers must have
same group ID and working circuit, and the protect circuit must have compatible configurations
(such as the same speed, framing, and port-type). Signaling is provided using the direct connection
between the two service routers. A heartbeat protocol can be used to add robustness to the
interaction between the two routers.
Signaling functionality includes support for:

APS group matching between service routers.

Verification that one side is configured as a working circuit and the other side is
configured as the protect circuit. In case of a mismatch, a trap (incompatible-neighbor) is
generated.

Change in working circuit status is sent from the working router to keep the protection
router in sync.

Protection router, based on K1/K2 byte data, member circuit status, and external request,
selects the active circuit and informs the working router to activate or de-activate the
working circuit.

Advanced Configuration Guide

Page 1295

Overview

Pseudowire Redundancy
Pseudowire (PW) redundancy provides the ability to protect a pseudowire with a pre-provisioned
pseudowire and to switch traffic over to the secondary standby pseudowire in case of a SAP and/or
network failure condition. Normally, pseudowires are redundant by the virtue of the SDP
redundancy mechanism. For instance, if the SDP is an RSVP LSP and is protected by a secondary
standby path and/or by Fast-Reroute paths, the pseudowire is also protected.
However, there are a few of applications in which SDP redundancy does not protect the end-toend pseudowire path when there are two different destination 7x50 PE nodes for the same VLL
service. The main use case is the provisioning of dual-homing of a CPE or access node to two
7x50 PE nodes located in different POPs. The other use case is the provisioning of a pair of active
and standby BRAS nodes, or active and standby links to the same BRAS node, to provide service
resiliency to broadband service subscribers.

Network Topology
The setup in this section contains two access nodes and 4 PE nodes. The access nodes can be any
ATM switches that support 1+1 bi-directional APS. Figure 103 shows the physical topology of the
setup. Figure 104 shows the use of both MC-APS in the access network and pseudowire
redundancy in the core network to provide a resilient end-to-end VLL service.

System IP
192.0.2.1
Active

.2

192.168.13.0/30

.2

PE-1

PE-3

.1

MSAN

1+1 APS

192.168.12.0/30

System IP
192.0.2.2
PE-2

Standby

.1

192.168.34.0/30

.2
Standby

System IP
192.0.2.3

1+1 APS

MSAN

.2
.1

192.168.24.0/30

.2

System IP
192.0.2.4

Active

PE-4
OSSG628

Figure 103: MC-APS Network Topology

Page 1296

Advanced Configuration Guide

Multi-Chassis APS and Pseudowire Redundancy

TLDP
Aggregation
Node
Active

Active

Standby

PE-1

PE-3

1+1 APS

Inter-chassis
PW for VLL
Standby

Standby

Aggregation
Node

Standby

Standby

Active
MSAN

Aggregation
Node

Inter-chassis
PW for VLL

1+1 APS

Aggregation
Node

Active

MSAN

Active

Standby

Active

PE-2

PE-4
OSSG629

TLDP

Active

MSAN

1+1 APS

Standby

Aggregation
Node

Aggregation
Node

PE-1

PE-3

Inter-chassis
PW for VLL

Inter-chassis
PW for VLL

1+1 APS

Aggregation
Node

Aggregation
Node

Active

PE-2

PE-4

Standby

MSAN

OSSG630

Figure 104: Access Node and Network Resilience

Advanced Configuration Guide

Page 1297

Configuration

Configuration
The following configuration should be completed on the PEs before configuring MC-APS:

Cards, MDAs and ports

Interfaces

IGP configured and converged

MPLS

SDPs configured between all PE routers

For the IGP, OSPF or IS-IS can be used. MPLS or GRE can be used for the transport tunnels. For
MPLS, LDP or RSVP protocols can be used for signaling MPLS labels. In this example OSPF and
LDP are used. The following commands can be used to check if OSPF has converged and to make
sure the SDPs are up (for example, on PE-1):
A:PE-1# show router route-table
===============================================================================
Route Table (Router: Base)
===============================================================================
Dest Prefix
Type
Proto
Age
Pref
Next Hop[Interface Name]
Metric
------------------------------------------------------------------------------192.0.2.1/32
Local
Local
00h40m53s
0
system
0
192.0.2.2/32
Remote OSPF
00h41m57s
10
192.168.12.2
100
192.0.2.3/32
Remote OSPF
00h40m12s
10
192.168.13.2
100
192.0.2.4/32
Remote OSPF
00h42m53s
10
192.168.12.2
100
192.168.12.0/30
Local
Local
00h43m15s
0
int-pe1-pe2
0
192.168.13.0/30
Local
Local
00h42m10s
0
int-pe1-pe3
0
192.168.24.0/30
Remote OSPF
00h43m50s
10
192.168.12.2
200
192.168.34.0/30
Remote OSPF
00h42m51s
10
192.168.13.2
200
------------------------------------------------------------------------------No. of Routes: 8
===============================================================================
*A:PE-1#
A:PE-1# show service sdp
==============================================================================
Services: Service Destination Points
==============================================================================
SdpId
Adm MTU Opr MTU IP address
Adm Opr
Deliver
Signal
-----------------------------------------------------------------------------12
0
1556
192.0.2.2
Up
Up
LDP
TLDP
13
0
1556
192.0.2.3
Up
Up
LDP
TLDP
14
0
1556
192.0.2.4
Up
Up
LDP
TLDP
------------------------------------------------------------------------------

Page 1298

Advanced Configuration Guide

Multi-Chassis APS and Pseudowire Redundancy

Number of SDPs : 3
------------------------------------------------------------------------------===============================================================================
*A:PE-1#

Step 1.

APS configuration on MSANs

The access nodes can be any ATM switches that support 1+1 bi-directional APS. Here is an
example on 7670RSP (Routing Switching Platform).
Alcatel[RW]>
Alcatel[RW]>
Alcatel[RW]>
Alcatel[RW]>
Alcatel[RW]>

configure
port 1-6-1-1
options protection type 1+1
options protection switching bidirect
options protection
(Standby)

#
Type
Status
1-6-1-1
STM1_IR8
OK
Protection Group Contains:
Protection Port
: 1-6-1-1
(Standby)
Working Port
: 1-5-1-1
Protection Type
: 1+1
Switching Type
: Non-Revertive
Switching Mode
: Bi-directional
Wait-To-Restore Timer : 5 minute(s)

Step 2.

Name

MC-APS configuration on PE-1 and PE-2

Assuming the link between MSAN and PE-1 is working circuit and the link between MSAN and
PE-2 is protection circuit.
Configure APS on the PE-1 port. Specify the system IP address of neighbor node (PE-2) and
working-circuit.
*A:PE-1>config>port 2/1/1# info
---------------------------------------------sonet-sdh
exit
no shutdown---------------------------------------------*A:PE-1>config>port 2/1/1#
*A:PE-1>config>port aps-1# info
---------------------------------------------aps
neighbor 192.0.2.2
working-circuit 2/1/1
exit
sonet-sdh
path
atm
exit
no shutdown
exit
exit
no shutdown

Advanced Configuration Guide

Page 1299

Configuration

---------------------------------------------*A:PE-1>config>port aps-1#

Configure APS on the PE-2 port. Specify the system IP address of neighbor node (PE-1) and
protect-circuit instead of working-circuit.
*A:PE-2>config>port 2/1/1# info
---------------------------------------------sonet-sdh
exit
no shutdown---------------------------------------------*A:PE-2>config>port 2/1/1#
*A:PE-2>config>port aps-1# info
---------------------------------------------aps
neighbor 192.0.2.1
protect-circuit 2/1/1
exit
sonet-sdh
path
atm
exit
no shutdown
exit
exit
no shutdown
---------------------------------------------*A:PE-2>config>port aps-1#

The following parameters can be configured under APS optionally.

Page 1300

advertise-interval This command specifies the time interval, in 100s of milliseconds,


between 'I am operational' messages sent by both protect and working circuits to their
neighbor for multi-chassis APS.

hold-time This command specifies how much time can pass, in 100s of milliseconds,
without receiving an advertise packet from the neighbor before the multi-chassis signaling
link is considered not operational.

revert-time This command configures the revert-time timer to determine how long to
wait before switching back to the working circuit after that circuit has been restored into
service.

switching-mode This command configures the switching mode for the APS port
including bi-directional and uni-directional modes.

Advanced Configuration Guide

Multi-Chassis APS and Pseudowire Redundancy

Step 3.

Verify the APS status on PE-1.

*A:PE-1# show port aps-1


===============================================================================
SONET/SDH Interface
===============================================================================
Description
: APS Group
Interface
: aps-1
Speed
: oc3
Admin Status
: up
Oper Status
: up
Physical Link
: Yes
Loopback Mode
: none
Single Fiber Mode : No
Clock Source
: node
Framing
: sonet
Last State Change : 09/08/2010 12:37:42
Port IfIndex
: 1358987264
Last Cleared Time : N/A
J0 String
: 0x01
Section Trace Mode
: byte
Rx S1 Byte
: 0x00
Rx K1/K2 Byte
: 0x00/0x00
Rx J0 String (Hex) : 81 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Cfg Alarm
: loc lais lrdi ss1f lb2er-sd lb2er-sf slof slos lrei
Alarm Status
:
Hold time up
: 500 milliseconds
Hold time down
: 200 milliseconds
===============================================================================
Port Statistics
===============================================================================
Input
Output
------------------------------------------------------------------------------Packets
8671498
4814981
Discards
0
0
Unknown Proto Discards
0
===============================================================================
*A:PE-1#

Step 4.

Verify the MC-APS status and parameters on PE-1 and PE-2

*A:PE-1# show aps detail


===============================================================================
APS Group: aps-1
===============================================================================
Description
: APS Group
Group Id
: 1
Active Circuit
: 2/1/1
Admin Status
: Up
Oper Status
: Up
Working Circuit
: 2/1/1
Protection Circuit
: N/A
Switching-mode
: Bi-directional
Switching-arch
: 1+1
Revertive-mode
: Non-revertive
Revert-time (min)
:
Rx K1/K2 byte
: N/A
Tx K1/K2 byte
: N/A
Current APS Status : OK
Multi-Chassis APS : Yes
Neighbor
: 192.0.2.2
Control link state : Up
Advertise Interval : 1000 msec
Hold time
: 3000 msec
Mode mismatch Cnt : 0
Channel mismatch Cnt : 0
PSB failure Cnt
: 0
FEPL failure Cnt
: 0
------------------------------------------------------------------------------APS Working Circuit - 2/1/1
------------------------------------------------------------------------------Admin Status
: Up
Oper Status
: Up
Current APS Status : OK
No. of Switchovers
: 0
Last Switchover
: None
Switchover seconds
: 0

Advanced Configuration Guide

Page 1301

Configuration

Signal Degrade Cnt : 1


Signal Failure Cnt
: 0
Last Switch Cmd
: N/A
Last Exercise Result : N/A
Tx L-AIS
: None
===============================================================================
*A:PE-1#

Detailed parameters of the APS configuration on PE-1 can be verified, shown above. The admin/
oper status of APS group 1 shows up/up. K1/K2 byte shows N/A as APS 1+1 exchanges that
information through protection circuit.
The admin/oper status of the working circuit (the link between MSAN and PE-1) is up/up.
*A:PE-2# show aps detail
===============================================================================
APS Group: aps-1
===============================================================================
Description
: APS Group
Group Id
: 1
Active Circuit
: N/A
Admin Status
: Up
Oper Status
: Up
Working Circuit
: N/A
Protection Circuit
: 1/2/1
Switching-mode
: Bi-directional
Switching-arch
: 1+1
Revertive-mode
: Non-revertive
Revert-time (min)
:
Rx K1/K2 byte
: 0x00/0x05 (No-Req on Protect)
Tx K1/K2 byte
: 0x00/0x05 (No-Req on Protect)
Current APS Status : OK
Multi-Chassis APS : Yes
Neighbor
: 192.0.2.1
Control link state : Up
Advertise Interval : 1000 msec
Hold time
: 3000 msec
Mode mismatch Cnt : 0
Channel mismatch Cnt : 0
PSB failure Cnt
: 0
FEPL failure Cnt
: 1
------------------------------------------------------------------------------APS Working Circuit - Neighbor
------------------------------------------------------------------------------Admin Status
: N/A
Oper Status
: N/A
Current APS Status : OK
No. of Switchovers
: 0
Last Switchover
: None
Switchover seconds
: 0
Signal Degrade Cnt : 1
Signal Failure Cnt
: 1
Last Switch Cmd
: No Cmd
Last Exercise Result : Unknown
Tx L-AIS
: None
------------------------------------------------------------------------------APS Protection Circuit - 1/2/1
------------------------------------------------------------------------------Admin Status
: Up
Oper Status
: Up
Current APS Status : OK
No. of Switchovers
: 0
Last Switchover
: None
Switchover seconds
: 0
Signal Degrade Cnt : 1
Signal Failure Cnt
: 0
Last Switch Cmd
: No Cmd
Last Exercise Result : Unknown
Tx L-AIS
: None
===============================================================================
*A:PE-2

Page 1302

Advanced Configuration Guide

Multi-Chassis APS and Pseudowire Redundancy

Detailed parameters of the APS configuration on PE-2 can be verified, as above. The admin/oper
status of APS group 1 shows up/up. Both Rx and Tx of the K1/K2 byte are in the status of 0x00/
0x05 (No-Req on Protect) as there is no failure or force-switchover request.
The admin/oper status of the protection circuit (the link between MSAN and PE-2) is up/up.
Step 5.

MC-APS configuration on PE-3 and PE-4

The MC-APS configuration on PE-3 and PE-4 is similar to the configuration on PE-1 and PE-2.
Configure the working circuit on PE-4 and the protection circuit on PE-3.
Step 6.

Pseudowire configuration

Configure an Apipe service on every PE and create endpoints x and y. Associate the SAPs and
spoke SDPs with the endpoints, as shown in Figure 105.

PE-1
Apipe
X Y
SDP
APS SAP
Active
SDP

MSAN

PE-3
Apipe
X Y
SDP
SAP APS
SDP

Standby

1+1 APS

1+1 APS

Standby

SDP
APS SAP

SDP
X Y

Apipe
PE-2

SDP

MSAN

Active

SAP APS
SDP
X Y
Apipe
PE-4
OSSG631

Figure 105: Association of SAPs/SDPs and Endpoints

*A:PE-1>config>service>apipe# info
---------------------------------------------endpoint "x" create
exit
endpoint "y" create
exit
sap aps-1:0/32 endpoint "x" create
exit
spoke-sdp 13:1 endpoint "y" create

Advanced Configuration Guide

Page 1303

Configuration

exit
spoke-sdp 14:1 endpoint "y" create
exit
no shutdown
---------------------------------------------*A:PE-1>config>service>apipe#

Syntax ps-1:0/32 above specifies the APS group and VPI/VCI of the ATM circuit (aps-id:vpi/vci).
Likewise, an Apipe service, endpoints, SAPs and spoke SDPs must be configured on the other PE
routers.
Step 7.

Pseudowire verification

*A:PE-1# show service service-using


===============================================================================
Services
===============================================================================
ServiceId
Type
Adm Opr
CustomerId
Last Mgmt Change
------------------------------------------------------------------------------1000
Apipe
Up
Up
1
08/09/2010 09:55:23
------------------------------------------------------------------------------Matching Services : 1
------------------------------------------------------------------------------===============================================================================
*A:PE-1#

*A:PE-2# show service service-using


===============================================================================
Services
===============================================================================
ServiceId
Type
Adm Opr
CustomerId
Last Mgmt Change
------------------------------------------------------------------------------1000
Apipe
Up
Down
1
08/09/2010 09:55:55
------------------------------------------------------------------------------Matching Services : 1
------------------------------------------------------------------------------===============================================================================
*A:PE-2#

*A:PE-3# show service service-using


===============================================================================
Services
===============================================================================
ServiceId
Type
Adm Opr
CustomerId
Last Mgmt Change
------------------------------------------------------------------------------1000
Apipe
Up
Down
1
08/09/2010 09:56:12
------------------------------------------------------------------------------Matching Services : 1
------------------------------------------------------------------------------===============================================================================
*A:PE-3#

*A:PE-4# show service service-using

Page 1304

Advanced Configuration Guide

Multi-Chassis APS and Pseudowire Redundancy

===============================================================================
Services
===============================================================================
ServiceId
Type
Adm Opr
CustomerId
Last Mgmt Change
------------------------------------------------------------------------------1000
Apipe
Up
Up
1
08/09/2010 09:56:45
------------------------------------------------------------------------------Matching Services : 1
------------------------------------------------------------------------------===============================================================================
*A:PE-4#

Note that only the Apipe services on PE-1 and PE-4 show as up but they are down on PE-2 and
PE-3 as the APS configuration on these nodes is in protection status.
Step 8.

Verify SDP status

An example on PE-2:
*A:PE-2# show service id 1 sdp 23:1 detail
===============================================================================
Service Destination Point (Sdp Id : 23:1) Details
===============================================================================
------------------------------------------------------------------------------Sdp Id 23:1 -(192.0.2.3)
------------------------------------------------------------------------------Description
: (Not Specified)
SDP Id
:23:1
Type
: Spoke
Split Horiz Grp
: (Not Specified)
VC Type
: Ether
VC Tag
: n/a
Admin Path MTU
: 0
Oper Path MTU
: 1556
Far End
: 192.0.2.3
Delivery
: LDP
Admin State
Acct. Pol
Ingress Label
Ingr Mac Fltr
Ingr ip Fltr
Ingr ipv6 Fltr
Admin ControlWord
Admin BW(Kbps)
Last Status Change
Last Mgmt Change
Endpoint
Class Fwding State
Flags
Peer Pw Bits
Peer Fault Ip
Peer Vccv CV Bits
Peer Vccv CC Bits

:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:

Up
Oper State
: Up
None
Collect Stats
: Disabled
131070
Egress Label
: 131070
n/a
Egr Mac Fltr
: n/a
n/a
Egr ip Fltr
: n/a
n/a
Egr ipv6 Fltr
: n/a
Not Preferred
Oper ControlWord : False
0
Oper BW(Kbps)
: 0
08/09/2010 15:13:15
Signaling
: TLDP
08/07/2010 09:41:08
Force Vlan-Vc
: Disabled
y
Precedence
: 4
Down
None
lacIngressFault lacEgressFault pwFwdingStandby
None
lspPing
mplsRouterAlertLabel

KeepAlive Information :
Admin State
: Disabled
Hello Time
: 10
Max Drop Count
: 3
Statistics

Advanced Configuration Guide

Oper State
Hello Msg Len
Hold Down Time

: Disabled
: 0
: 10

Page 1305

Configuration

I. Fwd. Pkts.
: 0
I. Dro. Pkts.
: 0
E. Fwd. Pkts.
: 0
E. Fwd. Octets
: 0
------------------------------------------------------------------------------Number of SDPs : 1
------------------------------------------------------------------------------===============================================================================
*A:PE-2#

Peer Pw Bits shows the status of the pseudowire on peer node. In this example, the remote node
(PE-3) is sending lacIngressFault lacEgressFault pwFwdingStandby flags. This is because the
Apipe service on PE-3 is down because the MC-APS is in protection status.
In case of failure, the access link can be protected by MC-APS. An MPLS network failure can be
protected by pseudowire redundancy. Node failure can be protected by the combination of MCAPS and pseudowire redundancy.
Step 9.

Inter-Chassis Backup (ICB) pseudowire configuration.

Configuring Inter-Chassis Backup (ICB) is optional. It can reduce traffic impact by forwarding
traffic on ICB spoke SDPs during MC-APS switchover. The ICB spoke SDP cannot be added to
the endpoint if the SAP is not part of an MC-APS (or MC-LAG) instance. Conversely, a SAP
which is not part of a MC-APS (or MC-LAG) instance cannot be added to an endpoint which
already has an ICB spoke SDP. Forwarding between ICBs is blocked on the same node. The user
has to explicitly indicate the spoke SDP is actually an ICB at creation time. Figure 5 shows some
setup examples where ICBs are required.
Note that after configuring ICB spoke SDPs the Apipe will be in admin/oper up/up status on all
PE routers.
Configure ICB SDPs and associate them to endpoints is shown in Figure 106.

Page 1306

Advanced Configuration Guide

Multi-Chassis APS and Pseudowire Redundancy

PE-1
Apipe

PE-3
Apipe

X Y
SDP
APS SAP
Active
SDP
SDP SDP

MSAN

1+1 APS

ICB Spoke-SDP

SDP
Standby

X Y
SDP
SAP APS
SDP
SDP SDP

1+1 APS

ICB Spoke-SDP

SDP
SDP

APS SAP

SDP
X Y

Apipe
PE-2

SDP

Standby

MSAN

SDP

SDP

Active
SAP APS

SDP
X Y

Apipe
PE-4
OSSG632

Figure 106: ICB Spoke SDPs and Association with the Endpoints

Two ICB spoke SDPs must be configured in the Apipe service on each PE router, one in each
endpoint. The same SDP IDs can be used for the ICBs since the far-end will be the same.
However, the vc-id must be different. The ICB spoke SDPs must cross,i.e. one end should be
associated with endpoint x and the other end (on the other PE) should be associated with endpoint
y.
An ICB is always the last forwarding resort. Only one spoke SDPs will be forwarding. If there is
an ICB and a MC-APS SAP in an endpoint, the ICB will only forward if the SAP goes down. If an
ICB resides in an endpoint together with other spoke SDPs the ICB will only forward if there is no
other active spoke SDP.
The following shows the configuration with ICB on each PE:
*A:PE-1>config>service>apipe# info
---------------------------------------------endpoint "x" create
exit
endpoint "y" create
exit
sap aps-1:0/32 endpoint "x" create
exit
spoke-sdp 13:1 endpoint "y" create
exit
spoke-sdp 14:1 endpoint "y" create
exit
spoke-sdp 12:1 endpoint "x" icb create
exit
spoke-sdp 12:2 endpoint "y" icb create
exit

Advanced Configuration Guide

Page 1307

Configuration

no shutdown
---------------------------------------------*A:PE-1>config>service>apipe

*A:PE-2>config>service>apipe# info
---------------------------------------------endpoint "x" create
exit
endpoint "y" create
exit
sap aps-1:0/32 endpoint "x" create
exit
spoke-sdp 23:1 endpoint "y" create
exit
spoke-sdp 24:1 endpoint "y" create
exit
spoke-sdp 21:1 endpoint "y" icb create
exit
spoke-sdp 21:2 endpoint "x" icb create
exit
no shutdown
---------------------------------------------*A:PE-2>config>service>apipe#

*A:PE-3>config>service>apipe# info
---------------------------------------------endpoint "x" create
exit
endpoint "y" create
exit
sap aps-1:0/32 endpoint "y" create
exit
spoke-sdp 31:1 endpoint "x" create
exit
spoke-sdp 32:1 endpoint "x" create
exit
spoke-sdp 34:1 endpoint "x" icb create
exit
spoke-sdp 34:2 endpoint "y" icb create
exit
no shutdown
---------------------------------------------*A:PE-3>config>service>apipe#

*A:PE-4>config>service>apipe# info
---------------------------------------------endpoint "x" create
exit
endpoint "y" create
exit
sap aps-1:0/32 endpoint "y" create
exit
spoke-sdp 41:1 endpoint "x" create
exit
spoke-sdp 42:1 endpoint "x" create
exit

Page 1308

Advanced Configuration Guide

Multi-Chassis APS and Pseudowire Redundancy

spoke-sdp 43:1 endpoint "y" icb create


exit
spoke-sdp 43:2 endpoint "x" icb create
exit
no shutdown
---------------------------------------------*A:PE-4>config>service>apipe#

Step 10. Verification of active objects for each endpoint

The following command shows which objects are configured for each endpoint and which is the
active object at this moment:
*A:PE-1# show service id 1000 endpoint
------------------------------------------------------------------------------Service Endpoints
------------------------------------------------------------------------------Endpoint name
: x
Revert time
: 0
Act Hold Delay
: 0
Ignore Standby Signaling
: false
Suppress Standby Signaling
: true
Tx Active
: aps-1:0/32
Tx Active Up Time
: 0d 02:01:19
Revert Time Count Down
: N/A
Tx Active Change Count
: 8
Last Tx Active Change
: 08/09/2010 02:24:18
------------------------------------------------------------------------------Members
------------------------------------------------------------------------------SAP
: aps-1:0/32
Spoke-sdp
: 12:1 Precedence:4 (icb)
===============================================================================
Endpoint name
: y
Revert time
: 0
Act Hold Delay
: 0
Ignore Standby Signaling
: false
Suppress Standby Signaling
: true
Tx Active
: 14:1
Tx Active Up Time
: 0d 03:16:08
Revert Time Count Down
: N/A
Tx Active Change Count
: 1
Last Tx Active Change
: 08/09/2010 02:23:18
------------------------------------------------------------------------------Members
------------------------------------------------------------------------------Spoke-sdp
: 12:2 Precedence:4 (icb)
Spoke-sdp
: 13:1 Precedence:4
Spoke-sdp
: 14:1 Precedence:4
===============================================================================
*A:PE-1#

Note that on PE-1 both the SAP and the spoke SDP 14:1 are active. The other objects do not
forward traffic.

Advanced Configuration Guide

Page 1309

Configuration

Step 11. Other types of setups

The following figures show other setups that combine MC-APS and pseudowire redundancy.
PE-1
Apipe
1+1 APS

X Y
APS SAP
SAP APS

MSAN

SDP

MSAN

MC-APS

ICB Spoke-SDP

SDP
APS SAP
X Y
Apipe
PE-2
OSSG634

PE-1
Apipe
X Y
APS SAP

MSAN

MC-APS

SDP

SDP

ICB Spoke-SDP
Spoke-SDP
PE-2
Apipe
APS SAP SDP

SAP APS
Y SDP

Spoke-SDP

MC-APS

ICB Spoke-SDP

MSAN

PE-3
Apipe
SDP SDP

SAP APS

X Y
OSSG635

Figure 107: Additional Setup Example 1

Page 1310

Advanced Configuration Guide

Multi-Chassis APS and Pseudowire Redundancy

PE-1
Apipe

Active

X Y
APS SAP
SDP
SDP

MSAN

MC-APS

Spoke-SDP

SDP

ICB Spoke-SDP

SDP
Standby

PE-3
Apipe
X Y
SAP APS
SDP

1+1 APS
MSAN

SDP

Spoke-SDP

SDP

APS SAP
SDP
X Y
Apipe
PE-2
OSSG636

PE-1
Apipe

Active

X Y
APS SAP
SDP

PE-3
Apipe
Spoke-SDP

X Y
SAP APS
SDP

1+1 APS
MSAN

SDP

MSAN

MC-APS

ICB Spoke-SDP

SDP
Standby

APS SAP
X Y
Apipe
PE-2
OSSG637

Figure 108: Additional Setup Example 2 (Part 1)

Advanced Configuration Guide

Page 1311

Configuration

PE-3
Apipe
X Y
SDP
SAP APS
SDP
SDP SDP
Spoke-SDP
PE-1
Apipe
X Y
APS SAP

ICB Spoke-SDP

SAP
SAP
SDP
SDP

SDP
SDP

Spoke-SDP

SDP

MSAN

MC-APS

MSAN

SDP

SAP APS
X Y
Apipe
PE-4

Spoke-SDP
MSAN

MC-APS

Spoke-SDP

MC-APS
Spoke-SDP

APS SAP
X Y
Apipe
PE-2

SAP
SAP
SDP
SDP

X Y
SDP
SAP APS
SDP
SDP SDP

Spoke-SDP

Spoke-SDP

PE-5
Apipe

Spoke-SDP

ICB Spoke-SDP
SDP
SDP
SDP

SDP

SAP APS
X Y
Apipe
PE-6
OSSG638

Figure 109: Additional Setup Example 2 (Part 2)

Page 1312

Advanced Configuration Guide

Multi-Chassis APS and Pseudowire Redundancy

Forced Switchover
MC-APS convergence can be forced with the tools perform aps command:
*A:PE-1# tools perform aps force
- force <aps-id> {protect|working}
<aps-id>

<protect|working>

: aps-<group-id>
aps
group-id
: keyword

- keyword
- [1..64]

After the forced switchover it is important to clear the forced switchover:


*A:PE1# tools perform aps clear
- clear <aps-id> {protect|working}
<aps-id>

<protect|working>

Advanced Configuration Guide

: aps-<group-id>
aps
group-id
: protect|working

- keyword
- [1..64]

Page 1313

Conclusion

Conclusion
In addition to Multi-Chassis LAG, Multi-Chassis APS provides a solution for both network
redundancy and access node redundancy. It supports ATM VLL and Ethernet VLL with ATM
SAP. Access links and PE nodes are protected by APS and the MPLS network is protected by
pseudowire redundancy/FRR. With this feature, Alcatel-Lucent can provide resilient end-to-end
solutions.

Page 1314

Advanced Configuration Guide

Multi-Chassis IPSec Redundancy

In This Chapter
This section provides information about multi-chassis IPSec redundancy configurations.
Topics in this section include:

Applicability on page 1316

Overview on page 1317

Configuration on page 1319

Conclusion on page 1352

Advanced Configuration Guide

Page 1315

Applicability

Applicability
This feature is applicable to 7750 SR-7/12/12e with IOM3-XP or IMMs and chassis mode D and
the 7450 ESS-6/7/12 with IOM3-XP or IMM in mixed mode.
The configuration was tested on release 10.0R8.

Page 1316

Advanced Configuration Guide

Multi-Chassis IPSec Redundancy

Overview
Multi-Chassis IPSec redundancy (MC-IPSec) is a stateful inter-chassis IPSec failover mechanism.
IPSec tunnel states are synchronized between the master and standby chassis. A tunnel-group
failure on the master or a master chassis failure could trigger MC-IPSec failover to the standby
chassis.
The following are some highlights of this feature:

IKEv2 only

Multi-active tunnel-group only

The granularity of failover is tunnel-group, which means a specific tunnel-group could


failover to the standby chassis independent of other tunnel-groups on the master chassis

Supports both static and dynamic LAN-to-LAN tunnel

This feature has the following building blocks:

Master election
MIMP (MC-IPSec Mastership Protocol) runs between chassis to elect master, MIMP
run for each tunnel-group independently

Synchronization
MCS (Multi-Chassis Synchronization) syncs IPSec states between chassis

Routing
MC-IPSec-aware routing attracts traffic to the master chassis
Shunting support
MC-IPSec aware VRRP

Advanced Configuration Guide

Page 1317

Overview

Master

Routing Adv/VRRP

Public Network

MCS

Routing Adv

Shunt

Routing Adv/VRRP

MIMP

Private Network

Routing Adv

Standby

al_0297

Figure 110: MC-IPSec Architecture

The fundamentals of MC-IPSec are:

Page 1318

Only the master processes ESP and IKE traffic. If the standby receives traffic, it could
shunt it to the master if possible. The traffic will be discarded if the standby fails to shunt
the traffic.

Same local gateway address should be provisioned on both chassis.

MC-IPSec does not synchronize configurations.

MC-IPSec aware routing attracts traffic to the master in both public and private service.
This is achieved by exporting the corresponding IPSec routes to the routing protocol via a
route policy and setting a different routing metric according to the MC-IPSec state.

In case of a Layer 2 public network, MC-IPSec aware VRRP could be used to trigger
VRRP switchover upon MC-IPSec switchover.

MCS syncs IPSec states between chassis so that existing IPSec tunnels do not need to be
re-established upon switchover.

MIMP elects mastership between two chassis, and it could also detect chassis failure and
tunnel-group failure; a central BFD session could be bound to the MIMP to achieve fast
chassis failure detection.

Advanced Configuration Guide

Multi-Chassis IPSec Redundancy

Configuration
The test topology is shown in Figure 111.
Sys: 192.0.2.1

SeGW-1
172.16.1.252/24
1/1/2

192.168.254.1/30
1/1/4

1/1/3
192.168.255.1/30
Sys: 192.0.2.3
IPsec tunnel addr:
10.10.10.1

CE-1

S-1

P-1
1/1/2

172.16.1.100/24
1/1/2
1/1/4

int-loopback-1:
192.168.1.1/32

VRRP 10 Backup Addr:


172.16.1.254
IPsec GW addr:
10.10.20.1

192.168.254.2/30
1/1/1
192.168.253.2/30
1/1/2

1/1/3

int-loopback-1:
192.168.2.1/32
192.168.255.2/30
1/1/3
CE-1: IPsec Client
S-1: VPLS Switch
SeGW-1/SeGW-2: Master and
Standby Security Gateway
P-1: Core Router

172.16.1.253/24
1/1/2

192.168.253.1/30
1/1/5

SeGW-2

al_0296

Figure 111: Test Topology

Test setup:

An IPSec tunnel is initiated by CE-1 and terminated on the master of SeGW-1/SeGW-2.

IES 1 and VPRN 2 are the public and private services, respectively, on SeGW-1/SeGW-2/
CE-1.

VPRN 2 is also configured on P-1.

Static LAN-to-LAN tunnel with pre-shared key.

Local VPLS service 100 on S-1 to simulate a layer2 switch.

VRRP 10 between SeGW-1 and SeGW-2 to provide a backup address 192.168.1.254,


which is also the default next-hop for CE-1.

VRRP policy 1 is bound to VRRP 10 to change the in-use priority upon MC-IPSec
switchover.

OSPF is the IGP running in the base routing instance between SeGW-1, SeGW-2 and P-1.

Advanced Configuration Guide

Page 1319

Configuration

MP-BGP is running between SeGW-1, SeGW-2 and P-1 for exchanging VPRN 2s routes.

A ping between loopback interface address: 192.168.1.1 on CE-1 and 192.168.2.1 on P-1
in VPRN 2 is used to verify the connectivity over the IPSec tunnel.

The MC-IPSec configuration commands are shown below.


config>redundancy>multi-chassis>
peer <ip-address> [create]
sync
ipsec
tunnel-group <tunnel-group-id> sync-tag <tag-name> [create]
mc-ipsec
bfd-enable
discovery-interval <interval-1> [boot <interval-2>]
hold-on-neighbor-failure <multiplier>
keep-alive-interval <interval>
tunnel-group <tunnel-group-id> [create]
peer-group <tunnel-group-id>
priority <priority>
shutdown
config>router>policy-options>policy-statement>entry>from>
state ipsec-master-with-peer|ipsec-non-master|ipsec-master-without-peer
protocol ipsec
config>service>ies>if>
config>service>vprn>if>
static-tunnel-redundant-next-hop <ip-address>
dynamic-tunnel-redundant-next-hop <ip-address>
config>isa>tunnel-grp>
ipsec-responder-only
config>vrrp>policy>priority-event>
mc-ipsec-non-forwarding <tunnel-grp-id>
hold-clear <seconds>
hold-set <seconds>
priority <priority-level> explicit

Parameters:

Page 1320

peer <ip-address> [create] This command creates or enters a multi-chassis peer. The
peers address by default is the peers system address. This can be changed on the peer
using the config>redundancy>multi-chassis>peer>source-address command.

sync>ipsec This command enables MCS to synchronize IPSec states.

tunnel-group <tunnel-group-id> sync-tag <tag-name> [create] This command


enables MCS to synchronize the IPSec states of the specified tunnel-group.The sync-tag
parameter is use to match peers tunnel-group. The tunnel-group states with same sync-tag
on both chassis will be synced.

mc-ipsec This command enters the multi-chassis IPSec configuration context.

Advanced Configuration Guide

Multi-Chassis IPSec Redundancy

bfd-enable This command enables tracking a central BFD session, if the BFD session
goes down, then the system considers the peer is down and changes the mc-ipsec status of
the configured tunnel-group accordingly.
The BFD session uses the source address of MCS as its source address and the MCS peer
address as the destination address. Other BFD parameters are configured with the bfd
command on the interface that the MCS source address resides on.
Configuration of this command is optional.

discovery-interval <interval-1> [boot <interval-2>] This command specifies the time


interval that the tunnel-group stays in Discovery state. Interval-1 is used as discoveryinterval when a new tunnel-group is added to multi-chassis redundancy (mp-ipsec);
interval-2 is used as discovery-interval after system boot-up, it is optional, and when it is
not specified, interval-1s value will be used. Both intervals have a default value of 300
seconds.

hold-on-neighbor-failure <multiplier> This command specifies the number of keepalive failures before considering the peer to be down. Default is 3.

keep-alive-interval <interval> This command specifies the time interval of the


mastership election protocol keep-alive packets. Default value is 1 seconds, range: 0.5 ~
50 seconds.

tunnel-group <tunnel-group-id> [create] This command enables multi-chassis


redundancy for the specified tunnel-group, or enters an already configured tunnel-group
context. The configured tunnel-groups could failover independently.

peer-group <tunnel-group-id> This command specifies the corresponding tunnelgroup id on the peer node. The peer tunnel-group id is not necessary equal to local tunnelgroup id.

priority <priority> This command specifies the local priority of the tunnel-group, this
is used to elect a master, where the higher number wins. If the priorities are the same, then
the peer which has more active ISAs wins; if priority and the number of active ISAs are
same, then the peer with higher IP address wins. Default value is 100, range: 0..255

shutdown This command disables the multi-chassis redundancy for the specified
tunnel-group

state ipsec-master-with-peer|ipsec-non-master|ipsec-master-without-peer These


commands specify the mc-ipsec state in a from statement of a route policy entry.
ipsec-master-with-peer: The corresponding tunnel-group is Master with peer reachable.
ipsec-master-without-peer: The corresponding tunnel-group is Master with peer
unreachable.
ipsec-non-master: The corresponding tunnel-group is not Master.

protocol ipsec This command specifies the IPSec as protocol in a from statement of
a route policy entry. protocol ipsec means the /32 local gateway routes (of both static and
dynamic tunnels) and reverse route of dynamic tunnel.

static-tunnel-redundant-next-hop <ip-address>
dynamic-tunnel-redundant-next-hop <ip-address> This command specifies the

Advanced Configuration Guide

Page 1321

Configuration

redundant next-hop address on a public or private IPSec interface (with public or private
tunnel-sap) for a static/dynamic IPSec tunnel. The specified next-hop address will be used
by the standby node to shunt traffic to the master in case it receives any traffic.
The next-hop address will be resolved in the routing table of the corresponding service.
Notes:
Shunting is supported over:
Directly connected SAP
Spoke SDP terminated IP interface
Shunting over auto-bind tunnel is not supported.
Shunting will not work if the tunnel-group is down.

ipsec-responder-only With this command configured, the system will only act as IKE
responder except for the automatic CHILD_SA rekey upon MC-IPSec switchover.
This command is required for MC-IPSec support of static LAN-to-LAN tunnel

Page 1322

mc-ipsec-non-forwarding <tunnel-grp-id> This command creates a new VRRP


policy priority event: mc-ipsec-non-forwarding. It will be triggered whenever the
specified tunnel-group enters non-forwarding state.

hold-clear <seconds> This command configures hold time before clearing the event.
Default value is 0 seconds. Range: 0..86400 seconds

hold-set <seconds> This command configures hold time before setting the event.
Default value is 0 seconds. Range: 0..86400 seconds

priority <priority-level> explicit This command sets the VRRP in-use priority to the
configured value upon the event. Default value is 0, range: 0..254

Advanced Configuration Guide

Multi-Chassis IPSec Redundancy

Before starting

The system time of SeGW-1 and SeGW-2 must be the same. Otherwise, this feature will
not work. Using a time sync protocol like NTP/SNTP is the recommended method.

SeGW-1 and SeGW-2 must be IP reachable in the base routing instance because both
MCS and MIMP run in the base routing instance.

Step 0: Configure CE-1.

IES 1 and VPRN 2 are the public and private service.

A static default route points to the VRRP backup address 172.16.1.254.

Static IPSec tunnel tunnel-1 with local address 10.10.10.1 and remote address
10.10.20.1.

A loopback interface in VPRN 2 with address 192.168.1.1/32, which is used as source


address for the ping traffic in later step.
The ping traffic is used to test the connectivity between CE-1 and P-1 over IPSec
tunnel tunnel-1.

#-------------------------------------------------echo "Router (Network Side) Configuration"


#-------------------------------------------------router
interface "int-CE1-S1"
address 172.16.1.100/24
port 1/1/2
no shutdown
exit
interface "system"
no shutdown
exit
autonomous-system 64496
#-------------------------------------------------echo "Static Route Configuration"
#-------------------------------------------------static-route 0.0.0.0/0 next-hop 172.16.1.254
#-------------------------------------------------echo "IPsec Configuration"
#-------------------------------------------------ipsec
ike-policy 1 create
ike-version 2
dpd
exit
ipsec-transform 1 create
exit
exit
#-------------------------------------------------echo "Service Configuration"
#--------------------------------------------------

Advanced Configuration Guide

Page 1323

Configuration

service
ies 1 customer 1 create
interface "int-IPsec-Public-1" create
address 10.10.10.254/24
tos-marking-state untrusted
sap tunnel-1.public:1 create
exit
exit
no shutdown
exit
vprn 2 customer 1 create
ipsec
security-policy 1 create
entry 10 create
local-ip 192.168.1.1/32
remote-ip 192.168.2.1/32
exit
exit
exit
route-distinguisher 64496:2
interface "int-loopback-1" create
address 192.168.1.1/32
loopback
exit
interface "int-IPsec-private-1" tunnel create
sap tunnel-1.private:1 create
ipsec-tunnel "tunnel-1" create
security-policy 1
local-gateway-address 10.10.10.1 peer 10.10.20.1
delivery-service 1
dynamic-keying
ike-policy 1
pre-shared-key "ALU"
transform 1
exit
no shutdown
exit
exit
exit
static-route 192.168.2.1/32 ipsec-tunnel "tunnel-1"
no shutdown
exit
exit

Step 1.

Configure S-1.

A local VPLS service 3 to simulate a layer2 switch between CE-1, SeGW-1 and SeGW-2.
vpls 3 customer 1 create
stp
shutdown
exit
sap 1/1/2 create
exit
sap 1/1/3 create
exit
sap 1/1/4 create

Page 1324

Advanced Configuration Guide

Multi-Chassis IPSec Redundancy

exit
no shutdown
exit

Step 2.

Configure P-1

P-1 simulates the core network router, which connects to both SeGW-1 and SeGW-2.

A loopback interface with address 192.168.2.1/32 in VPRN 2 is the destination address of


the ping traffic from CE-1.

MP-BGP session between P-1 and SeGW-1/SeGW-2 to receive 192.168.1.1/32 route in


VPRN 2.

GRE spoke SDPs to connect to SeGW-1 and SeGW-2.

#-------------------------------------------------echo "Router (Network Side) Configuration"


#-------------------------------------------------router
interface "int-P1-SeGW1"
address 192.168.254.2/30
port 1/1/1
no shutdown
exit
interface "int-P1-SeGW2"
address 192.168.253.2/30
port 1/1/2
no shutdown
exit
interface "system"
address 192.0.2.3/32
no shutdown
exit
autonomous-system 64496
#-------------------------------------------------echo "OSPFv2 Configuration"
#-------------------------------------------------ospf
area 0.0.0.0
interface "system"
no shutdown
exit
interface "int-P1-SeGW1"
no shutdown
exit
interface "int-P1-SeGW2"
no shutdown
exit
exit
exit
#-------------------------------------------------echo "Service Configuration"
#-------------------------------------------------service
sdp 200 create

Advanced Configuration Guide

Page 1325

Configuration

far-end 192.0.2.1
signaling off
keep-alive
shutdown
exit
no shutdown
exits
sdp 300 create
far-end 192.0.2.2
signaling off
keep-alive
shutdown
exit
no shutdown
exit
vprn 2 customer 1 create
route-distinguisher 64496:2
vrf-target target:64496:2
interface "int-loopback-1" create
address 192.168.2.1/32
loopback
exit
spoke-sdp 200 create
description "SDP to SeGW-1"
exit
spoke-sdp 300 create
description "SDP to SeGW-2"
exit
no shutdown
exit
exit
#-------------------------------------------------echo "BGP Configuration"
#-------------------------------------------------bgp
group "MPBGP"
family vpn-ipv4
peer-as 64496
neighbor 192.0.2.1
exit
neighbor 192.0.2.2
exit
exit
no shutdown
exit
exit

Page 1326

Advanced Configuration Guide

Multi-Chassis IPSec Redundancy

Step 3.

Configure IPSec tunnel on SeGW-1.

The tunnel-group must be in multi-active mode before MC-IPSec can be enabled for it.

Interface "int-Redundant-1" is a spoke-sdp terminated interface, which is used for


shunting.

SDP 100 and 200 are the GRE SDP towards SeGW-2 and P-1.

IPSec tunnel tunnel-1 is the tunnel to CE-1; both SeGW-1 and SeGW-2 use same local
gateway address: 10.10.20.1.

#-------------------------------------------------echo "ISA Configuration"


#-------------------------------------------------isa
tunnel-group 1 create
ipsec-responder-only
multi-active
mda 1/2
no shutdown
exit
exit
#-------------------------------------------------echo "Router (Network Side) Configuration"
#-------------------------------------------------router
interface "int-SeGW1-P1"
address 192.168.254.1/30
port 1/1/4
no shutdown
exit
interface "int-SeGW1-SeGW2"
address 192.168.255.1/30
port 1/1/3
no shutdown
exit
interface "system"
address 192.0.2.1/32
bfd 100 receive 100 multiplier 3
no shutdown
exit
autonomous-system 64496
#-------------------------------------------------echo "Static Route Configuration"
#-------------------------------------------------static-route 10.10.10.0/24 next-hop 172.16.1.100
#-------------------------------------------------echo "OSPFv2 Configuration"
#-------------------------------------------------ospf
area 0.0.0.0
interface "system"
no shutdown
exit
interface "int-SeGW1-SeGW2"
no shutdown
exit

Advanced Configuration Guide

Page 1327

Configuration

interface "int-SeGW1-P1"
no shutdown
exit
exit
exit
#-------------------------------------------------echo "IPsec Configuration"
#-------------------------------------------------ipsec
ike-policy 1 create
ike-version 2
ipsec-lifetime 7200
isakmp-lifetime 172800
exit
ipsec-transform 1 create
exit
exit
#-------------------------------------------------echo "Service Configuration"
#-------------------------------------------------service
sdp 100 create
signaling off
far-end 192.0.2.2
keep-alive
shutdown
exit
no shutdown
exit
sdp 200 create
signaling off
far-end 192.0.2.3
keep-alive
shutdown
exit
no shutdown
exit
ies 1 customer 1 create
interface "int-SeGW1-S1" create
address 172.16.1.252/24
vrrp 10
backup 172.16.1.254
priority 200
policy 1
ping-reply
exit
sap 1/1/2 create
exit
exit
interface "int-IPsec-Public-1" create
address 10.10.20.254/24
tos-marking-state untrusted
sap tunnel-1.public:1 create
exit
static-tunnel-redundant-next-hop 192.168.255.2
exit
no shutdown
exit
vprn 2 customer 1 create

Page 1328

Advanced Configuration Guide

Multi-Chassis IPSec Redundancy

ipsec
security-policy 1 create
entry 10 create
local-ip 192.168.2.1/32
remote-ip 192.168.1.1/32
exit
exit
exit
vrf-export "IPsec-to-MPBGP"
route-distinguisher 64496:2
vrf-target target:64496:2
interface "int-IPsec-Private-1" tunnel create
sap tunnel-1.private:1 create
ipsec-tunnel "tunnel-1" create
security-policy 1
local-gateway-address 10.10.20.1 peer 10.10.10.1
delivery-service 1
dynamic-keying
ike-policy 1
pre-shared-key "ALU"
transform 1
exit
no shutdown
exit
exit
static-tunnel-redundant-next-hop 192.168.20.2
exit
interface "int-Redundant-1" create
address 192.168.20.1/30
spoke-sdp 100:20 create
ingress
vc-label 2049
exit
egress
vc-label 2048
exit
no shutdown
exit
exit
static-route 192.168.1.1/32 ipsec-tunnel "tunnel-1"
spoke-sdp 100 create
description "SDP to SeGW-2"
exit
spoke-sdp 200 create
description "SDP to P-1"
exit
no shutdown
exit
exit

Advanced Configuration Guide

Page 1329

Configuration

Step 4.

Enable MC-IPSec for tunnel-group 1 on SeGW-1

Create a multi-chassis peer for SeGW-2 by using SeGW-2s system address.

Enable MCS for IPSec and tunnel-group 1.

Enable MC-IPSec for tunnel-group with a configured priority 200.

Bind a central BFD session to MC-IPSec from system interface.

*A:SeGW-1>config>redundancy# info
---------------------------------------------multi-chassis
peer 192.0.2.2 create
sync
ipsec
tunnel-group 1 sync-tag "tag-1" create
no shutdown
exit
mc-ipsec
bfd-enable
tunnel-group 1 create
peer-group 1
priority 200
no shutdown
exit
exit
no shutdown
exit
exit
---------------------------------------------*A:SeGW-1>config>router# info
---------------------------------------------interface "system"
address 192.0.2.1/32
bfd 100 receive 100 multiplier 3
no shutdown
exit

Page 1330

Advanced Configuration Guide

Multi-Chassis IPSec Redundancy

Step 5.

Configure MC-IPSec aware routing on SeGW-1.

Export static route 192.168.1.1/32 in VPRN 2 to P-1 by using route-policy "IPsec-toMPBGP".

Set the local preference of the 192.168.1.1/32 according to the MC-IPSec state:
ipsec-master-with-peer: 200
ipsec-non-master:100
ipsec-master-without-peer: 200
State ipsec-master-without-peer could be used to attract traffic to the designated master
in case of Dual Master (meaning two chassis lose the MIMP connection in base routing
instance). In this example, SeGW-1 has local preference 200 and SeGW-2 has local
preference 100 for ipsec-master-without-peer.

Apply the policy IPsec-to-MPBGP in VPRN 2.

#-------------------------------------------------echo "Policy Configuration"


#-------------------------------------------------policy-options
begin
prefix-list "CE1-Internal"
prefix 192.168.1.1/32 exact
exit
community "vprn2" members "target:64496:2"
policy-statement "IPsec-to-MPBGP"
entry 10
from
prefix-list "CE1-Internal"
state ipsec-master-with-peer
exit
action accept
community add "vprn2"
local-preference 200
exit
exit
entry 20
from
prefix-list "CE1-Internal"
state ipsec-non-master
exit
action accept
community add "vprn2"
local-preference 100
exit
exit
entry 30
from
prefix-list "CE1-Internal"
state ipsec-master-without-peer
exit
action accept
community add "vprn2"
local-preference 200

Advanced Configuration Guide

Page 1331

Configuration

exit
exit
default-action accept
community add "vprn2"
exit
exit
commit
exit
#-------------------------------------------------echo "BGP Configuration"
#-------------------------------------------------bgp
group "MPBGP"
family vpn-ipv4
peer-as 64496
neighbor 192.0.2.2
exit
neighbor 192.0.2.3
exit
exit
no shutdown
exit
exit
---------------------------------------------A:SeGW-1>config>service>
vprn 2 customer 1 create
vrf-export "IPsec-to-MPBGP"

Page 1332

Advanced Configuration Guide

Multi-Chassis IPSec Redundancy

Step 6.

Configure MC-IPSec-aware VRRP on SeGW-1.

VRRP instance needs to be in preempt mode.

Use mc-ipsec-non-forwarding priority event to lower the in-use VRRP priority upon
MC-IPSec switchover, which makes sure VRRP and MC-IPSec have the same master.

Apply the vrrp-policy on interface "int-SeGW1-S1" of IES 1.


This is only needs to be configured on the designated VRRP master, in this case,
SeGW-1.

*A:SeGW-1>config>vrrp# info
---------------------------------------------policy 1
priority-event
mc-ipsec-non-forwarding 1
priority 50 explicit
exit
exit
exit
---------------------------------------------*A:SeGW-1>config>service>ies# info
---------------------------------------------interface "int-SeGW1-S1" create
address 172.16.1.252/24
vrrp 10
backup 172.16.1.254
priority 200
policy 1
ping-reply
exit
sap 1/1/2 create
exit
exit

Advanced Configuration Guide

Page 1333

Configuration

Step 7.

Repeat Step 3 to Step 5 on SeGW-2.

#-------------------------------------------------echo "ISA Configuration"


#-------------------------------------------------isa
tunnel-group 1 create
ipsec-responder-only
multi-active
mda 1/2
no shutdown
exit
exit
#-------------------------------------------------echo "Redundancy Configuration"
#-------------------------------------------------redundancy
multi-chassis
peer 192.0.2.1 create
sync
ipsec
tunnel-group 1 sync-tag "tag-1" create
no shutdown
exit
mc-ipsec
bfd-enable
tunnel-group 1 create
peer-group 1
priority 150
no shutdown
exit
exit
no shutdown
exit
exit
exit
#-------------------------------------------------echo "Router (Network Side) Configuration"
#-------------------------------------------------router
interface "int-SeGW2-P1"
address 192.168.253.1/30
port 1/1/5
no shutdown
exit
interface "int-SeGW2-SeGW1"
address 192.168.255.2/30
port 1/1/3
no shutdown
exit
interface "system"
address 192.0.2.2/32
bfd 100 receive 100 multiplier 3
no shutdown
exit
autonomous-system 64496
#--------------------------------------------------

Page 1334

Advanced Configuration Guide

Multi-Chassis IPSec Redundancy

echo "Static Route Configuration"


#-------------------------------------------------static-route 10.10.10.0/24 next-hop 172.16.1.100
#-------------------------------------------------echo "OSPFv2 Configuration"
#-------------------------------------------------ospf
area 0.0.0.0
interface "system"
no shutdown
exit
interface "int-SeGW2-SeGW1"
no shutdown
exit
interface "int-SeGW2-P1"
no shutdown
exit
exit
exit
#-------------------------------------------------echo "IPsec Configuration"
#-------------------------------------------------ipsec
ike-policy 1 create
ike-version 2
ipsec-lifetime 7200
isakmp-lifetime 172800
exit
ipsec-transform 1 create
exit
exit
#-------------------------------------------------echo "Service Configuration"
#-------------------------------------------------service
sdp 100 create
far-end 192.0.2.1
signaling off
keep-alive
shutdown
exit
no shutdown
exit
sdp 300 create
far-end 192.0.2.3
signaling off
keep-alive
shutdown
exit
no shutdown
exit
ies 1 customer 1 create
interface "int-SeGW2-S1" create
address 172.16.1.253/24
vrrp 10
backup 172.16.1.254
ping-reply
exit

Advanced Configuration Guide

Page 1335

Configuration

sap 1/1/2 create


exit
exit
interface "int-IPsec-Public-1" create
address 10.10.20.254/24
tos-marking-state untrusted
sap tunnel-1.public:1 create
exit
static-tunnel-redundant-next-hop 192.168.255.1
exit
no shutdown
exit
vprn 2 customer 1 create
ipsec
security-policy 1 create
entry 10 create
local-ip 192.168.2.1/32
remote-ip 192.168.1.1/32
exit
exit
exit
vrf-export "IPsec-to-MPBGP"
route-distinguisher 64496:2
vrf-target target:64496:2
interface "int-IPsec-Private-1" tunnel create
sap tunnel-1.private:1 create
ipsec-tunnel "tunnel-1" create
security-policy 1
local-gateway-address 10.10.20.1 peer 10.10.10.1
delivery-service 1
dynamic-keying
ike-policy 1
pre-shared-key "ALU"
transform 1
exit
no shutdown
exit
exit
static-tunnel-redundant-next-hop 192.168.20.1
exit
interface "int-Redundant-1" create
address 192.168.20.2/30
spoke-sdp 100:20 create
ingress
vc-label 2048
exit
egress
vc-label 2049
exit
no shutdown
exit
exit
static-route 192.168.1.1/32 ipsec-tunnel "tunnel-1"
spoke-sdp 100 create
description "SDP to SeGW-1"
exit
spoke-sdp 300 create
description "SDP to P-1"
exit

Page 1336

Advanced Configuration Guide

Multi-Chassis IPSec Redundancy

no shutdown
exit
exit
#-------------------------------------------------echo "Router (Service Side) Configuration"
#-------------------------------------------------router
#-------------------------------------------------echo "Policy Configuration"
#-------------------------------------------------policy-options
begin
prefix-list "CE1-Internal"
prefix 192.168.1.1/32 exact
exit
community "vprn2" members "target:64496:2"
policy-statement "IPsec-to-MPBGP"
entry 10
from
prefix-list "CE1-Internal"
state ipsec-master-with-peer
exit
action accept
community add "vprn2"
local-preference 200
exit
exit
entry 20
from
prefix-list "CE1-Internal"
state ipsec-non-master
exit
action accept
community add "vprn2"
local-preference 100
exit
exit
entry 30
from
prefix-list "CE1-Internal"
state ipsec-master-without-peer
exit
action accept
community add "vprn2"
local-preference 100
exit
exit
default-action accept
community add "vprn2"
exit
exit
commit
exit
#-------------------------------------------------echo "BGP Configuration"
#-------------------------------------------------bgp
group "MPBGP"
family vpn-ipv4

Advanced Configuration Guide

Page 1337

Configuration

peer-as 64496
neighbor 192.0.2.1
exit
neighbor 192.0.2.3
exit
exit
no shutdown
exit
exit

Page 1338

Advanced Configuration Guide

Multi-Chassis IPSec Redundancy

Step 8.

Verify the MC-IPSec status on SeGW-1 and SeGW-2.

Verify that SeGW-1 is the master and SeGW-2 is the standby for tunnel-group 1 because
SeGW-1 has higher priority 200.

Verify that SeGW-1 is the VRRP 10 master and SeGW-2 is the backup.

A:SeGW-1# show redundancy multi-chassis mc-ipsec peer 192.0.2.2


===============================================================================
Multi-Chassis MC-IPsec
===============================================================================
Peer Name
: (Not Specified)
Peer Addr
: 192.0.2.2
Keep Alive Intvl: 1.0 secs
Hold on Nbr Fail
: 3
Discovery Intvl : 300 secs
Discovery Boot Intvl : 300 secs
BFD
: Enable
Last update
: 05/13/2013 21:37:10
======================================================================
Multi-Chassis IPsec Multi Active Tunnel-Group Table
======================================================================
ID
Peer Group
Priority Admin State
Mastership
---------------------------------------------------------------------1
1
200
Up
master
---------------------------------------------------------------------Multi Active Tunnel Group Entries found: 1
======================================================================
===============================================================================

A:SeGW-2# show redundancy multi-chassis mc-ipsec peer 192.0.2.1


===============================================================================
Multi-Chassis MC-IPsec
===============================================================================
Peer Name
: (Not Specified)
Peer Addr
: 192.0.2.1
Keep Alive Intvl: 1.0 secs
Hold on Nbr Fail
: 3
Discovery Intvl : 300 secs
Discovery Boot Intvl : 300 secs
BFD
: Enable
Last update
: 05/13/2013 21:53:16
======================================================================
Multi-Chassis IPsec Multi Active Tunnel-Group Table
======================================================================
ID
Peer Group
Priority Admin State
Mastership
---------------------------------------------------------------------1
1
150
Up
standby
---------------------------------------------------------------------Multi Active Tunnel Group Entries found: 1
======================================================================
===============================================================================

A:SeGW-1# show router vrrp instance


===============================================================================
VRRP Instances
===============================================================================
Interface Name
VR Id Own Adm State
Base Pri
Msg Int
IP
Opr Pol Id
InUse Pri Inh Int

Advanced Configuration Guide

Page 1339

Configuration

------------------------------------------------------------------------------int-SeGW1-S1
10
No Up
Master
200
1
IPv4
Up
1
200
No
Backup Addr: 172.16.1.254
------------------------------------------------------------------------------Instances : 1
===============================================================================

A:SeGW-2# show router vrrp instance


===============================================================================
VRRP Instances
===============================================================================
Interface Name
VR Id Own Adm State
Base Pri
Msg Int
IP
Opr Pol Id
InUse Pri Inh Int
------------------------------------------------------------------------------int-SeGW2-S1
10
No Up
Backup
100
1
IPv4
Up
n/a
100
No
Backup Addr: 172.16.1.254
------------------------------------------------------------------------------Instances : 1
===============================================================================

Page 1340

Advanced Configuration Guide

Multi-Chassis IPSec Redundancy


.
Step 9.

Trigger the tunnel-1 setup on CE-1 via sending pings.

A:CE-1# ping router 2 192.168.2.1


PING 192.168.2.1 56 data bytes
64 bytes from 192.168.2.1: icmp_seq=1
64 bytes from 192.168.2.1: icmp_seq=2
64 bytes from 192.168.2.1: icmp_seq=3
64 bytes from 192.168.2.1: icmp_seq=4
64 bytes from 192.168.2.1: icmp_seq=5

ttl=63
ttl=63
ttl=63
ttl=63
ttl=63

time=4.58ms.
time=4.54ms.
time=5.27ms.
time=5.26ms.
time=5.04ms.

---- 192.168.2.1 PING Statistics ---5 packets transmitted, 5 packets received, 0.00% packet loss
round-trip min = 4.54ms, avg = 4.94ms, max = 5.27ms, stddev = 0.318ms
A:CE-1# show ipsec tunnel
===============================================================================
IPsec Tunnels
===============================================================================
TunnelName
LocalAddress
SvcId
Admn
Keying
SapId
RemoteAddress
DlvrySvcId
Oper
Sec
Plcy
------------------------------------------------------------------------------tunnel-1
10.10.10.1
2
Up
Dynamic
tunnel-1.private:1
10.10.20.1
1
Up
1
------------------------------------------------------------------------------IPsec Tunnels: 1
===============================================================================

Advanced Configuration Guide

Page 1341

Configuration

Step 10. Verify that the tunnel status on SeGW-1/SeGW-2 is up.

Verify that MCS database is in-sync, so the tunnel status is up on both chassis.

Verify P-1 receives two 192.168.1.1/32 VPN-IPv4 routes, the route from SeGW-1 has
local preference 200, and the one from SeGW-2 has 100.

A:SeGW-1# show ipsec tunnel


===============================================================================
IPsec Tunnels
===============================================================================
TunnelName
LocalAddress
SvcId
Admn
Keying
SapId
RemoteAddress
DlvrySvcId
Oper
Sec
Plcy
------------------------------------------------------------------------------tunnel-1
10.10.20.1
2
Up
Dynamic
tunnel-1.private:1
10.10.10.1
1
Up
1
------------------------------------------------------------------------------IPsec Tunnels: 1
===============================================================================

A:SeGW-2# show ipsec tunnel


===============================================================================
IPsec Tunnels
===============================================================================
TunnelName
LocalAddress
SvcId
Admn
Keying
SapId
RemoteAddress
DlvrySvcId
Oper
Sec
Plcy
------------------------------------------------------------------------------tunnel-1
10.10.20.1
2
Up
Dynamic
tunnel-1.private:1
10.10.10.1
1
Up
1
-------------------------------------------------------------------------------

A:SeGW-2# show redundancy multi-chassis sync


===============================================================================
Multi-chassis Peer Table
===============================================================================
Peer
------------------------------------------------------------------------------Peer IP Address
: 192.0.2.1
Description
: (Not Specified)
Authentication
: Disabled
Source IP Address
: 192.0.2.2
Admin State
: Enabled
------------------------------------------------------------------------------Sync-status
------------------------------------------------------------------------------Client Applications
: IPsec
Sync Admin State
: Up
Sync Oper State
: Up
DB Sync State
: inSync
Num Entries
: 2
Lcl Deleted Entries
: 0
Alarm Entries
: 0
Rem Num Entries
: 2
Rem Lcl Deleted Entries : 0

Page 1342

Advanced Configuration Guide

Multi-Chassis IPSec Redundancy

Rem Alarm Entries


: 0
===============================================================================
===============================================================================

A:P-1# show router bgp routes vpn-ipv4


===============================================================================
BGP Router ID:192.0.2.3
AS:64496
Local AS:64496
===============================================================================
Legend Status codes : u - used, s - suppressed, h - history, d - decayed, * - valid
Origin codes : i - IGP, e - EGP, ? - incomplete, > - best, b - backup
===============================================================================
BGP VPN-IPv4 Routes
===============================================================================
Flag Network
LocalPref
MED
Nexthop
Path-Id
VPNLabel
As-Path
------------------------------------------------------------------------------u*>i 64496:2:192.168.1.1/32
200
None
192.0.2.1
None
262143
No As-Path
*i
64496:2:192.168.1.1/32
100
None
192.0.2.2
None
262143
No As-Path
u*>i 64496:2:192.168.20.0/30
100
None
192.0.2.1
None
262143
No As-Path
*>i
64496:2:192.168.20.0/30
100
None
192.0.2.2
None
262143
No As-Path
------------------------------------------------------------------------------Routes : 4
===============================================================================

Advanced Configuration Guide

Page 1343

Configuration

Step 11.

Trigger MC-IPSec switchover by shutting down the MS-ISA.

Verify the VRRP/MC-IPSec state on SeGW-1 is master, SeGW-2 is backup/


standby.

Shutdown the MS-ISA on SeGW-1, which is currently Master.

Verify that the MC-IPSec state of tunnel-group 1 on SeGW-1 becomes notEligible,


SeGW-2 becomes master.
Note: notEligible means the tunnel-group is down, refer to the SR OS MS-ISA Guide for
details description of MIMP states.

Verify that the VRRP state on SeGW-1 becomes backup and SeGW-2 becomes
master. This is triggered by MC-IPSec switchover, configured via mc-ipsec-nonforwarding event in vrrp-policy 1.

A:SeGW-1# show redundancy multi-chassis mc-ipsec peer 192.0.2.2


===============================================================================
Multi-Chassis MC-IPsec
===============================================================================
Peer Name
: (Not Specified)
Peer Addr
: 192.0.2.2
Keep Alive Intvl: 1.0 secs
Hold on Nbr Fail
: 3
Discovery Intvl : 300 secs
Discovery Boot Intvl : 300 secs
BFD
: Enable
Last update
: 05/13/2013 21:37:10
======================================================================
Multi-Chassis IPsec Multi Active Tunnel-Group Table
======================================================================
ID
Peer Group
Priority Admin State
Mastership
---------------------------------------------------------------------1
1
200
Up
master
---------------------------------------------------------------------Multi Active Tunnel Group Entries found: 1
======================================================================
===============================================================================

*A:SeGW-1# show router vrrp instance


===============================================================================
VRRP Instances
===============================================================================
Interface Name
VR Id Own Adm State
Base Pri
Msg Int
IP
Opr Pol Id
InUse Pri Inh Int
------------------------------------------------------------------------------int-SeGW1-S1
10
No Up
Master
200
1
IPv4
Up
1
200
No
Backup Addr: 172.16.1.254
------------------------------------------------------------------------------Instances : 1
===============================================================================

A:SeGW-2# show redundancy multi-chassis mc-ipsec peer 192.0.2.1


===============================================================================
Multi-Chassis MC-IPsec

Page 1344

Advanced Configuration Guide

Multi-Chassis IPSec Redundancy

===============================================================================
Peer Name
: (Not Specified)
Peer Addr
: 192.0.2.1
Keep Alive Intvl: 1.0 secs
Hold on Nbr Fail
: 3
Discovery Intvl : 300 secs
Discovery Boot Intvl : 300 secs
BFD
: Enable
Last update
: 05/13/2013 21:53:16
======================================================================
Multi-Chassis IPsec Multi Active Tunnel-Group Table
======================================================================
ID
Peer Group
Priority Admin State
Mastership
---------------------------------------------------------------------1
1
150
Up
standby
---------------------------------------------------------------------Multi Active Tunnel Group Entries found: 1
======================================================================
===============================================================================

A:SeGW-2# show router vrrp instance


===============================================================================
VRRP Instances
===============================================================================
Interface Name
VR Id Own Adm State
Base Pri
Msg Int
IP
Opr Pol Id
InUse Pri Inh Int
------------------------------------------------------------------------------int-SeGW2-S1
10
No Up
Backup
100
1
IPv4
Up
n/a
100
No
Backup Addr: 172.16.1.254
------------------------------------------------------------------------------Instances : 1
===============================================================================
*A:SeGW-1# configure card 1 mda 2 shutdown

*A:SeGW-1# show redundancy multi-chassis mc-ipsec peer 192.0.2.2


===============================================================================
Multi-Chassis MC-IPsec
===============================================================================
Peer Name
: (Not Specified)
Peer Addr
: 192.0.2.2
Keep Alive Intvl: 1.0 secs
Hold on Nbr Fail
: 3
Discovery Intvl : 300 secs
Discovery Boot Intvl : 300 secs
BFD
: Enable
Last update
: 05/13/2013 21:37:10
======================================================================
Multi-Chassis IPsec Multi Active Tunnel-Group Table
======================================================================
ID
Peer Group
Priority Admin State
Mastership
---------------------------------------------------------------------1
1
200
Up
notEligible
---------------------------------------------------------------------Multi Active Tunnel Group Entries found: 1
======================================================================
===============================================================================

*A:SeGW-1# show router vrrp instance

Advanced Configuration Guide

Page 1345

Configuration

===============================================================================
VRRP Instances
===============================================================================
Interface Name
VR Id Own Adm State
Base Pri
Msg Int
IP
Opr Pol Id
InUse Pri Inh Int
------------------------------------------------------------------------------int-SeGW1-S1
10
No Up
Backup
200
1
IPv4
Up
1
50
No
Backup Addr: 172.16.1.254
------------------------------------------------------------------------------Instances : 1
===============================================================================

A:SeGW-2# show redundancy multi-chassis mc-ipsec peer 192.0.2.1


===============================================================================
Multi-Chassis MC-IPsec
===============================================================================
Peer Name
: (Not Specified)
Peer Addr
: 192.0.2.1
Keep Alive Intvl: 1.0 secs
Hold on Nbr Fail
: 3
Discovery Intvl : 300 secs
Discovery Boot Intvl : 300 secs
BFD
: Enable
Last update
: 05/13/2013 21:53:16
======================================================================
Multi-Chassis IPsec Multi Active Tunnel-Group Table
======================================================================
ID
Peer Group
Priority Admin State
Mastership
---------------------------------------------------------------------1
1
150
Up
master
---------------------------------------------------------------------Multi Active Tunnel Group Entries found: 1
======================================================================
===============================================================================

A:SeGW-2# show router vrrp instance


===============================================================================
VRRP Instances
===============================================================================
Interface Name
VR Id Own Adm State
Base Pri
Msg Int
IP
Opr Pol Id
InUse Pri Inh Int
------------------------------------------------------------------------------int-SeGW2-S1
10
No Up
Master
100
1
IPv4
Up
n/a
100
No
Backup Addr: 172.16.1.254
------------------------------------------------------------------------------Instances : 1
===============================================================================

Page 1346

Advanced Configuration Guide

Multi-Chassis IPSec Redundancy

Step 12. Trigger the MC-IPSec switchover by rebooting SeGW-1.

Restore state as in Step 10 (before the MC-IPSec switchover).


Note: The MC-IPSec switchover could be triggered manually with the tools perform
redundancy multi-chassis mc-ipsec force-switchover tunnel-group 1 command.

Verify the VRRP/MC-IPSec state on SeGW-1 is master, SeGW-2 is backup/


standby.

Reboot SeGW-1 which is the current Master.

Verify the MC-IPSec state of tunnel-group 1 on SeGW-2 becomes eligible during


SeGW-1 rebooting.

Verify the VRRP state on SeGW-2 becomes master during SeGW-1 reboot.

After SeGW-1 comes up, verify MC-IPSec state of tunnel-group 1 is discovery initially,
and then becomes standby;
Note: The discovery state means system has not established the MIMP session with
peer yet.

Verify the MC-IPSec state of tunnel-group 1 on SeGW-2 becomes master when SeGW1 becomes standby.

After SeGW-1 comes up, verify the VRRP state is backup.

*A:SeGW-1# show redundancy multi-chassis mc-ipsec peer 192.0.2.2


===============================================================================
Multi-Chassis MC-IPsec
===============================================================================
Peer Name
: (Not Specified)
Peer Addr
: 192.0.2.2
Keep Alive Intvl: 1.0 secs
Hold on Nbr Fail
: 3
Discovery Intvl : 300 secs
Discovery Boot Intvl : 300 secs
BFD
: Enable
Last update
: 05/13/2013 21:37:10
======================================================================
Multi-Chassis IPsec Multi Active Tunnel-Group Table
======================================================================
ID
Peer Group
Priority Admin State
Mastership
---------------------------------------------------------------------1
1
200
Up
master
---------------------------------------------------------------------Multi Active Tunnel Group Entries found: 1
======================================================================
===============================================================================

*A:SeGW-1# show router vrrp instance


===============================================================================
VRRP Instances
===============================================================================
Interface Name
VR Id Own Adm State
Base Pri
Msg Int
IP
Opr Pol Id
InUse Pri Inh Int
-------------------------------------------------------------------------------

Advanced Configuration Guide

Page 1347

Configuration

int-SeGW1-S1

10
IPv4

No

Up
Up

Master
1

200
200

1
No

Backup Addr: 172.16.1.254


------------------------------------------------------------------------------Instances : 1
===============================================================================

A:SeGW-2# show redundancy multi-chassis mc-ipsec peer 192.0.2.1


===============================================================================
Multi-Chassis MC-IPsec
===============================================================================
Peer Name
: (Not Specified)
Peer Addr
: 192.0.2.1
Keep Alive Intvl: 1.0 secs
Hold on Nbr Fail
: 3
Discovery Intvl : 300 secs
Discovery Boot Intvl : 300 secs
BFD
: Enable
Last update
: 05/13/2013 21:53:16
======================================================================
Multi-Chassis IPsec Multi Active Tunnel-Group Table
======================================================================
ID
Peer Group
Priority Admin State
Mastership
---------------------------------------------------------------------1
1
150
Up
standby
---------------------------------------------------------------------Multi Active Tunnel Group Entries found: 1
======================================================================
===============================================================================

A:SeGW-2# show router vrrp instance


===============================================================================
VRRP Instances
===============================================================================
Interface Name
VR Id Own Adm State
Base Pri
Msg Int
IP
Opr Pol Id
InUse Pri Inh Int
------------------------------------------------------------------------------int-SeGW2-S1
10
No Up
Backup
100
1
IPv4
Up
n/a
100
No
Backup Addr: 172.16.1.254
------------------------------------------------------------------------------Instances : 1
===============================================================================

A:SeGW-1# admin reboot


Are you sure you want to reboot (y/n)? y
A:SeGW-2# show redundancy multi-chassis mc-ipsec peer 192.0.2.1
===============================================================================
Multi-Chassis MC-IPsec
===============================================================================
Peer Name
: (Not Specified)
Peer Addr
: 192.0.2.1
Keep Alive Intvl: 1.0 secs
Hold on Nbr Fail
: 3
Discovery Intvl : 300 secs
Discovery Boot Intvl : 300 secs
BFD
: Enable
Last update
: 05/13/2013 21:53:16
======================================================================

Page 1348

Advanced Configuration Guide

Multi-Chassis IPSec Redundancy

Multi-Chassis IPsec Multi Active Tunnel-Group Table


======================================================================
ID
Peer Group
Priority Admin State
Mastership
---------------------------------------------------------------------1
1
150
Up
eligible
---------------------------------------------------------------------Multi Active Tunnel Group Entries found: 1
======================================================================
===============================================================================

A:SeGW-2# show router vrrp instance


===============================================================================
VRRP Instances
===============================================================================
Interface Name
VR Id Own Adm State
Base Pri
Msg Int
IP
Opr Pol Id
InUse Pri Inh Int
------------------------------------------------------------------------------int-SeGW2-S1
10
No Up
Master
100
1
IPv4
Up
n/a
100
No
Backup Addr: 172.16.1.254
------------------------------------------------------------------------------Instances : 1
===============================================================================

<SeGW-1 comes up>


A:SeGW-1# show redundancy multi-chassis mc-ipsec peer 192.0.2.2
===============================================================================
Multi-Chassis MC-IPsec
===============================================================================
Peer Name
: (Not Specified)
Peer Addr
: 192.0.2.2
Keep Alive Intvl: 1.0 secs
Hold on Nbr Fail
: 3
Discovery Intvl : 300 secs
Discovery Boot Intvl : 300 secs
BFD
: Enable
Last update
: 05/13/2013 22:08:27
======================================================================
Multi-Chassis IPsec Multi Active Tunnel-Group Table
======================================================================
ID
Peer Group
Priority Admin State
Mastership
---------------------------------------------------------------------1
1
200
Up
discovery
---------------------------------------------------------------------Multi Active Tunnel Group Entries found: 1
======================================================================
===============================================================================
A:SeGW-1#
A:SeGW-1#
A:SeGW-1# show redundancy multi-chassis mc-ipsec peer 192.0.2.2
===============================================================================
Multi-Chassis MC-IPsec
===============================================================================
Peer Name
: (Not Specified)
Peer Addr
: 192.0.2.2
Keep Alive Intvl: 1.0 secs
Hold on Nbr Fail
: 3
Discovery Intvl : 300 secs
Discovery Boot Intvl : 300 secs

Advanced Configuration Guide

Page 1349

Configuration

BFD
: Enable
Last update
: 05/13/2013 22:08:27
======================================================================
Multi-Chassis IPsec Multi Active Tunnel-Group Table
======================================================================
ID
Peer Group
Priority Admin State
Mastership
---------------------------------------------------------------------1
1
200
Up
standby
---------------------------------------------------------------------Multi Active Tunnel Group Entries found: 1
======================================================================
===============================================================================

A:SeGW-1# show router vrrp instance


===============================================================================
VRRP Instances
===============================================================================
Interface Name
VR Id Own Adm State
Base Pri
Msg Int
IP
Opr Pol Id
InUse Pri Inh Int
------------------------------------------------------------------------------int-SeGW1-S1
10
No Up
Backup
200
1
IPv4
Up
1
50
No
Backup Addr: 172.16.1.254
------------------------------------------------------------------------------Instances : 1
===============================================================================

A:SeGW-2# show redundancy multi-chassis mc-ipsec peer 192.0.2.1


===============================================================================
Multi-Chassis MC-IPsec
===============================================================================
Peer Name
: (Not Specified)
Peer Addr
: 192.0.2.1
Keep Alive Intvl: 1.0 secs
Hold on Nbr Fail
: 3
Discovery Intvl : 300 secs
Discovery Boot Intvl : 300 secs
BFD
: Enable
Last update
: 05/13/2013 21:53:16
======================================================================
Multi-Chassis IPsec Multi Active Tunnel-Group Table
======================================================================
ID
Peer Group
Priority Admin State
Mastership
---------------------------------------------------------------------1
1
150
Up
master
---------------------------------------------------------------------Multi Active Tunnel Group Entries found: 1
======================================================================
===============================================================================

Page 1350

Advanced Configuration Guide

Multi-Chassis IPSec Redundancy

Configuration Guidelines
The following is a list of configuration and operational guidelines that the user should follow for
MC-IPSec:

To avoid high CPU load and issues in some complex cases, the following are suggestions
for configuring IKEv2 lifetime:
1. Both IKE_SA and CHILD_SA lifetime on MC-IPSec chassis (SeGW-1 and SeGW-2)
should be around 3 times larger than on the IPSec peer (CE-1).
2. With the first rule, the lifetime of the side with smaller lifetime should NOT be too small
(these being the default values):
IKE_SA: >= 86400 seconds
CHILD_SA: >= 3600 seconds
3. With the first rule, on the side with smaller lifetime, the IKE_SA lifetime should be at
least 3 times larger than CHILD_SA lifetime.

IKE protocol is the control plane of IPSec, so IKE packet should be treated as high QoS
priority in end-to-end path of public service.
On public interface, a sap-ingress qos policy should be configured to ensure IKE
packet gets high QoS priority.

Configure responder-only under tunnel-group for static LAN-to-LAN tunnel.

Enable DPD (Dead Peer Detection) on peer side, configure no dpd on MC-IPSec
chassis side.

Direct and redundant physical link between MC-IPSec chassis should be configured with
enough bandwidth for MCS and shunting traffic, and proper QoS configuration to make
sure the MIMP/MCS packet treated as high priority traffic.

System time must be same on both MC-IPSec chassis.

Check and make sure the protection status is "nominal" on both chassis before you do a
controlled switchover. Protection status could be displayed via command show
redundancy multi-chassis mc-ipsec peer <addr>.

Wait at least 5 minutes between two consecutive switchovers if possible to prevent a


second switchover happening before the standby is ready to take over mastership.

Advanced Configuration Guide

Page 1351

Conclusion

Conclusion
MC-IPSec provides a stateful multi-chassis IPSec redundancy solution. This is very important in a
carrier grade network, especially in applications like mobile backhaul where high value 3G/4G
mobile service run over IPSec tunnels.

Page 1352

Advanced Configuration Guide

Multi-Chassis LAG and Pseudowire


Redundancy Interworking

In This Chapter
This section provides information about Multi-Chassis Link Aggregation (MC-LAG) and
pseudowire redundancy interworking.
Topics in this section include:

Applicability on page 1354

Overview on page 1355

Configuration on page 1358

Conclusion on page 1379

Advanced Configuration Guide

Page 1353

Applicability

Applicability
This feature is supported on all 7x50 platforms including the 7710 SR. MC-LAG is supported only
on Ethernet MDAs, and this only for access ports (the given LAG group must be in access mode).
The configuration was tested on release 7.0R5. The 7750 SR-c4 is supported from 8.0R4 and
higher.

Page 1354

Advanced Configuration Guide

Multi-Chassis LAG and Pseudowire Redundancy

Overview
MC-LAG
MC-LAG is an extension to the LAG feature to provide not only link redundancy but also nodelevel redundancy. This feature provides an Alcatel-Lucent added value solution which is not
defined in any IEEE standard.
A proprietary messaging between redundant-pair nodes supports coordinating the LAG
switchover.
Multi-chassis LAG supports LAG switchover coordination: one node connected to two redundantpair peer nodes with the LAG. During the LACP negotiation, the redundant-pair peer nodes act
like a single node using active/stand-by signaling to ensure that only links of one peer node is used
at a time.

Pseudowire Redundancy
Pseudowire (PW) redundancy provides the ability to protect a pseudowire with a pre-provisioned
pseudowire and to switch traffic over to the secondary standby pseudowire in case of a SAP and/or
network failure condition. Normally, pseudowires are redundant by the virtue of the SDP
redundancy mechanism. For instance, if the SDP is an RSVP LSP and is protected by a secondary
standby path and/or by Fast-Reroute paths, the pseudowire is also protected.
However, there are a few of applications in which SDP redundancy does not protect the end-toend pseudowire path when there are two different destination 7x50 PE nodes for the same VLL
service. The main use case is the provision of dual-homing of a CPE or access node to two 7x50
PE nodes located in different POPs. The other use case is the provisioning of a pair of active and
standby BRAS nodes, or active and standby links to the same BRAS node, to provide service
resiliency to broadband service subscribers.

Advanced Configuration Guide

Page 1355

Overview

Network Topology

192.0.2.3

192.0.2.1
1/1/1

PE-1

LAG

1/1/1

1/1/2

.1

1/1/4

192.168.13.0/30

1/1/3
.2

.1

1/1/3

PE-3
1/1/1

LAG

1/1/2 .1
1/1/1

CE-1

1/1/2
172.16.12.1/30
1/1/3

192.168.12.0/30

172.16.12.2/30

CE-2

1/1/2
.2

1/1/4

192.168.34.0/30

1/1/1

1/1/2 .2

1/1/1
192.0.2.4

192.0.2.2

PE-2
1/1/2

192.168.24.0/30

.2
1/1/3

PE-4

1/1/1

OSSG380

Figure 112: MC-LAG Network Topology

This section describes a setup which contains 2 CE and 4 PE nodes. The CE nodes can be any
routing/switching device that support the OUT_OF_SYNC signaling as described in IEEE
Standard 802.3-2005 section 3 section 43.6.1. Figure 112 shows the physical topology of the
setup.
Figure 113 shows the use of both MC-LAG in the access network and pseudowire redundancy in
the core network to provide a resilient end-to-end VLL service between CE1 and CE2.

Page 1356

Advanced Configuration Guide

Multi-Chassis LAG and Pseudowire Redundancy

TLDP
PE-1

PE-3
Active

Active

Standby

Active

LAG

LAG

Inter-chassis
PW for VLL

CE-1

Inter-chassis
PW ICE VLL
Standby

Standby

Standby

Standby

CE-2

Active
Active

PE-2

Standby

Active

PE-4

TLDP
PE-1

PE-3

Active

Standby

LAG

CE-1

LAG

Inter-chassis
PW ICE VLL

Inter-chassis
PW ICE VLL

Standby

PE-2

PE-4

CE-2

Active

OSSG381

Figure 113: Network Resiliency

Note in Figure 113 that when an SDP is in standby it sends the pseudowire status bit
pwFwdingStandby to its peer.

Advanced Configuration Guide

Page 1357

Configuration

Configuration
It is assumed that the following base configuration has been implemented on the PEs:

Cards, MDAs and ports

Interfaces

IGP configured and converged

MPLS

SDPs configured between all PE routers

Note that either OSPF and IS-IS can be used as the IGP. Both LDP or RSVP can be used for
signaling the transport MPLS labels. Alternatively, GRE can be used for the transport tunnels.
It does not matter if the SDPs are using LDP, RSVP or GRE. RSVP has the added value of
offering FRR to get faster convergence in the core. In this example OSPF and LDP are used.
The following commands can be used to check if OSPF has converged and to make sure the SDPs
are up (for example, on PE-1):
*A:PE-1# show router route-table
===============================================================================
Route Table (Router: Base)
===============================================================================
Dest Prefix
Type
Proto
Age
Pref
Next Hop[Interface Name]
Metric
------------------------------------------------------------------------------192.0.2.1/32
Local
Local
00h29m42s
0
system
0
192.0.2.2/32
Remote OSPF
00h28m37s
10
192.168.12.2
100
192.0.2.3/32
Remote OSPF
00h27m53s
10
192.168.13.2
100
192.0.2.4/32
Remote OSPF
00h27m02s
10
192.168.12.2
200
192.168.12.0/30
Local
Local
00h29m42s
0
int-PE-1-PE-2
0
192.168.13.0/30
Local
Local
00h29m42s
0
int-PE-1-PE-3
0
192.168.24.0/30
Remote OSPF
00h28m37s
10
192.168.12.2
200
192.168.34.0/30
Remote OSPF
00h27m53s
10
192.168.13.2
200
------------------------------------------------------------------------------No. of Routes: 8
===============================================================================
*A:PE-1#

Page 1358

Advanced Configuration Guide

Multi-Chassis LAG and Pseudowire Redundancy

*A:PE-1# show service sdp


===============================================================================
Services: Service Destination Points
===============================================================================
SdpId
Adm MTU
Opr MTU
IP address
Adm Opr
Deliver Signal
------------------------------------------------------------------------------12
0
1556
192.0.2.2
Up
Up
LDP
TLDP
13
0
1556
192.0.2.3
Up
Up
LDP
TLDP
14
0
1556
192.0.2.4
Up
Up
LDP
TLDP
------------------------------------------------------------------------------Number of SDPs : 3
------------------------------------------------------------------------------===============================================================================
*A:PE-1#

Advanced Configuration Guide

Page 1359

Configuration

Step 1.

MC-LAG configuration.

LAG configuration on CEs. Note that this is only included for completeness of the example, any
CE device could be used.
Auto-negotiation must be switched off or set to limited on all ports that will be included into the
LAG.
Configure LACP on the LAG. At least one side of the LAG must be configured in active mode.
*A:CE1#
*A:CE1#
*A:CE1#
*A:CE1#
*A:CE1#

Step 1.1

configure
configure
configure
configure
configure

port 1/1/[1..4] ethernet autonegotiate limited


port 1/1/[1..4] no shut
lag 1 port 1/1/1 1/1/2 1/1/3 1/1/4
lag 1 lacp active
lag 1 no shutdown

LAG configuration on PEs.

The PE ports connected to the CEs must be configured as access ports since they will be used in
the redundant pseudowire service. The LAG must also be configured in mode access.
Note that the LAG encapsulation type (null | dot1q | qinq) must match the port encapsulation type
of the LAG members.
Auto-negotiation must be switched off or configured to limited.
Configure LACP on the LAG. At least 1 side of the LAG (PE or CE) must be configured in active
mode.
*A:PE1#
*A:PE1#
*A:PE1#
*A:PE1#
*A:PE1#
*A:PE1#
*A:PE1#

Page 1360

configure
configure
configure
configure
configure
configure
configure

port 1/1/[1..2] ethernet autonegotiate limited


port 1/1/[1..2] ethernet mode access
port 1/1/[1..2] no shut
lag 1 mode access
lag 1 port 1/1/1 1/1/2
lag 1 lacp active
lag 1 no shutdown

Advanced Configuration Guide

Multi-Chassis LAG and Pseudowire Redundancy

Step 1.2

MC-LAG configuration on PE1 and PE2

The redundant PEs must act as 1 virtual node toward the CE. They have to be able to communicate
the same LACP parameters to the CE side.
The following parameters uniquely identify a LAG instance:

lacp-key

system-id

system-priority

These three parameters must be configured with the same value on both redundant PEs.
Configure multi-chassis redundancy with a peering session (which operates by an IP connection
using UDP destination port 1025) toward the redundant PE system address and enable MC-LAG
redundancy. The peering session can be configured with MD5 authentication.
*A:PE-1>config>redundancy>multi-chassis# info
---------------------------------------------peer 192.0.2.2 create
authentication-key "441dO/0RgDhHgzYwpOCTK9zbKjv4GZ/z" hash2
mc-lag
lag 1 lacp-key 1 system-id 00:00:00:00:00:01 system-priority 100
no shutdown
exit
no shutdown
exit
---------------------------------------------*A:PE-1>config>redundancy>multi-chassis#

*A:PE-2>config>redundancy>multi-chassis# info
---------------------------------------------peer 192.0.2.1 create
authentication-key "441dO/0RgDg2CA0JlyzVNQBoRc327b1j" hash2
mc-lag
lag 1 lacp-key 1 system-id 00:00:00:00:00:01 system-priority 100
no shutdown
exit
no shutdown
exit
---------------------------------------------*A:PE-2>config>redundancy>multi-chassis#

Advanced Configuration Guide

Page 1361

Configuration

Step 1.3

MC-LAG verification.

Verify MC peers showing that the authentication and admin state are enabled.
*A:PE-1# show redundancy multi-chassis sync
===============================================================================
Multi-chassis Peer Table
===============================================================================
Peer
------------------------------------------------------------------------------Peer IP Address
: 192.0.2.2
Description
: (Not Specified)
Authentication
: Enabled
Source IP Address
: 192.0.2.1
Admin State
: Enabled
------------------------------------------------------------------------------Sync: Not-configured
------------------------------------------------------------------------------===============================================================================
*A:PE-1#

Step 1.4

Verify MC-LAG peer status and LAG parameters.

*A:PE-1# show redundancy multi-chassis mc-lag peer 192.0.2.2


===============================================================================
Multi-Chassis MC-Lag Peer 192.0.2.2
===============================================================================
Last State chg : 11/01/2009 11:07:48
Admin State
: Up
Oper State
: Up
KeepAlive
: 10 deci-seconds
Hold On Ngbr Failure : 3
------------------------------------------------------------------------------Lag Id Lacp Key Remote Lag Id System Id
Sys Prio Last State Changed
------------------------------------------------------------------------------1
1
1
00:00:00:00:00:01 100
11/01/2009 11:06:08
------------------------------------------------------------------------------Number of LAGs : 1
===============================================================================
*A:PE-1#

Note that there is a fixed keepalive timer of 1 second. The hold-on-neighbor-failure multiplier
command indicates the interval that the standby node will wait for packets from the active node
before assuming a redundant-neighbor failure. The hold-on-neighbor-failure multiplier
command is configurable (2-25) in the config>redundancy>multi-chassis>peer>mc-lag
context. The standby node will also assume a redundant-neighbor failure when there is no route
available to the redundant-neighbor.
In this example the lag-id is 1 on both redundant PEs. This is not mandatory. If the lag-id on PE-2
is, for example 2, the following should be configured on PE-1:
*A:PE-1# configure redundancy multi-chassis
*A:PE-1>config>redundancy>multi-chassis# peer 192.0.2.2 mc-lag lag 1 remote-lag 2 lacp-key
1 system-id 00:00:00:00:00:01 system-priority 100

Page 1362

Advanced Configuration Guide

Multi-Chassis LAG and Pseudowire Redundancy

Step 1.5

Verify MC-LAG status

*A:PE-1# show lag 1


===============================================================================
Lag Data
===============================================================================
Lag-id
Adm
Opr
Port-Threshold
Up-Link-Count
MC Act/Stdby
------------------------------------------------------------------------------1
up
up
0
2
active
===============================================================================
*A:PE-1#

*A:PE-2# show lag 1


===============================================================================
Lag Data
===============================================================================
Lag-id
Adm
Opr
Port-Threshold
Up-Link-Count
MC Act/Stdby
------------------------------------------------------------------------------1
up
down
0
0
standby
===============================================================================
*A:PE-2#

In this case the LAG on PE-1 is active (operationally up) whereas the LAG on PE-2 is standby
(operationally down).
The selection criteria by default is highest number of links and priority. In this example the
number of links and the priority of the links is the same on both redundant PEs. Whichever PEs
LAG gets the operational status up first will be the active.
LAG ports of one PE could be preferred over the other PE by configuring port priority (for
example, the following command lowers the priority of the LAG ports on PE-1, thus giving this
LAG higher preference).
*A:PE1# configure lag 1 port 1/1/1 1/1/2 priority 10

Note that the selection criteria can be configured as highest-count or highest-weight (the default is
highest count). If highest-weight is configured (or in case the number of active MC-LAG links are
the same on both MC-LAG PEs), the sum of the weights of the LAG members is considered. The
weight of an individual LAG member is calculated as 65535 priority (the default is 32768).

Advanced Configuration Guide

Page 1363

Configuration

Step 1.6

Verify detailed MC-LAG status on PE-1

*A:PE-1# show lag 1 detail


===============================================================================
LAG Details
===============================================================================
Description
: N/A
------------------------------------------------------------------------------Details
------------------------------------------------------------------------------Lag-id
: 1
Mode
: access
Adm
: up
Opr
: up
Thres. Exceeded Cnt : 1
Port Threshold
: 0
Thres. Last Cleared : 11/01/2009 11:06:10
Threshold Action
: down
Dynamic Cost
: false
Encap Type
: null
Configured Address : 1e:51:ff:00:01:41
Lag-IfIndex
: 1342177281
Hardware Address
: 1e:51:ff:00:01:41
Adapt Qos
: distribute
Hold-time Down
: 0.0 sec
Port Type
: standard
Per FP Ing Queuing : disabled
LACP
: enabled
Mode
: active
LACP Transmit Intvl : fast
LACP xmit stdby
: enabled
Selection Criteria : highest-count
Slave-to-partner
: disabled
Number of sub-groups: 1
Forced
: System Id
: 1e:51:ff:00:00:00
System Priority
: 32768
Admin Key
: 32768
Oper Key
: 1
Prtr System Id
: 1e:50:ff:00:00:00
Prtr System Priority : 32768
Prtr Oper Key
: 32768
MC Peer Address
: 192.0.2.2
MC Peer Lag-id
: 1
MC System Id
: 00:00:00:00:00:01
MC System Priority
: 100
MC Admin Key
: 1
MC Active/Standby
: active
MC Lacp ID in use
: true
MC extended timeout : false
MC Selection Logic : peer decided
MC Config Mismatch : no mismatch
------------------------------------------------------------------------------Port-id
Adm
Act/Stdby Opr
Primary
Sub-group
Forced Prio
------------------------------------------------------------------------------1/1/1
up
active
up
yes
1
10
1/1/2
up
active
up
1
10
------------------------------------------------------------------------------Port-id
Role
Exp
Def
Dist Col
Syn
Aggr Timeout Activity
------------------------------------------------------------------------------1/1/1
actor
No
No
Yes
Yes
Yes
Yes
Yes
Yes
1/1/1
partner
No
No
Yes
Yes
Yes
Yes
Yes
Yes
1/1/2
actor
No
No
Yes
Yes
Yes
Yes
Yes
Yes
1/1/2
partner
No
No
Yes
Yes
Yes
Yes
Yes
Yes
===============================================================================
*A:PE-1#

After changing the LAG port priorities the LAG on PE-1 is in up/up state and the ports are in up/
active/up status. This show command also displays actor and partner bits set in the LACP
messages.

Page 1364

Advanced Configuration Guide

Multi-Chassis LAG and Pseudowire Redundancy

Step 1.7

MC-LAG configuration on PE-3 and PE-4.

The MC-LAG configuration on PE-3 and PE-4 is similar to the configuration on PE-1 and PE-2.
In this case the priority of the LAG port on PE-4 is lowered to obtain the behavior in Figure 113
where LAG on PE-1 and PE-4 is active.
Step 1.8

Pseudowire configuration.

Configure an Epipe service on every PE and create endpoints x and y (the endpoint names can be
any text string). Traffic can only be forwarded between two endpoints, for example, it is not
possible for objects associated with the same endpoint to forward traffic to each other.
Associate the SAPs and spoke SDPs with the endpoints like shown in Figure 114.

PE-1
epipe
X Y SDP
LAG

PE-3
epipe
Y
SDP X

SAP

SAP
SDP

SDP

LAG

MC-LAG

MC-LAG

CE-1

CE-2

PE-4

PE-2
SDP

LAG

SDP

LAG
SAP

SAP

X Y
epipe

SDP

SDP

X Y
epipe

OSSG382

Figure 114: Association of SAPs/SDPs and Endpoints

Advanced Configuration Guide

Page 1365

Configuration

*A:PE-1>config>service>epipe# info
---------------------------------------------endpoint "x" create
exit
endpoint "y" create
exit
sap lag-1 endpoint "x" create
exit
spoke-sdp 13:1 endpoint "y" create
exit
spoke-sdp 14:1 endpoint "y" create
exit
no shutdown
---------------------------------------------*A:PE-1>config>service>epipe#

Likewise, an Epipe service, endpoints, SAPs and spoke SDPs must be configured on the other PE
routers.

Page 1366

Advanced Configuration Guide

Multi-Chassis LAG and Pseudowire Redundancy

Step 1.9

Pseudowire verification.

*A:PE-1# show service service-using


===============================================================================
Services
===============================================================================
ServiceId
Type
Adm
Opr
CustomerId
Last Mgmt Change
------------------------------------------------------------------------------1
Epipe
Up
Up
1
11/01/2009 11:55:13
------------------------------------------------------------------------------Matching Services : 1
------------------------------------------------------------------------------===============================================================================
*A:PE-1#

*A:PE-2# show service service-using


===============================================================================
Services
===============================================================================
ServiceId
Type
Adm
Opr
CustomerId
Last Mgmt Change
------------------------------------------------------------------------------1
Epipe
Up
Down
1
11/01/2009 11:55:38
------------------------------------------------------------------------------Matching Services : 1
------------------------------------------------------------------------------==============================================================================
*A:PE-2#

*A:PE-3# show service service-using


===============================================================================
Services
===============================================================================
ServiceId
Type
Adm
Opr
CustomerId
Last Mgmt Change
------------------------------------------------------------------------------1
Epipe
Up
Down
1
11/01/2009 10:56:10
------------------------------------------------------------------------------Matching Services : 1
------------------------------------------------------------------------------===============================================================================
*A:PE-3#

*A:PE-4# show service service-using


===============================================================================
Services
===============================================================================
ServiceId
Type
Adm
Opr
CustomerId
Last Mgmt Change
------------------------------------------------------------------------------1
Epipe
Up
Up
1
11/01/2009 11:01:07
------------------------------------------------------------------------------Matching Services : 1
------------------------------------------------------------------------------===============================================================================
*A:PE-4#

Advanced Configuration Guide

Page 1367

Configuration

The Epipe service on PE-2 and PE-3 is down and up on PE-1 and PE-4. This reflects the standby
behavior shown in Figure 113. Note that after configuring ICB spoke SDPs (described later in this
document) the Epipe will be in up/up status on all PE routers.

Page 1368

Advanced Configuration Guide

Multi-Chassis LAG and Pseudowire Redundancy

Step 1.10 Verify SDP status

Peer pseudowire bits indicate the status of the pseudowire on the peer. Here is an example taken
on PE-2:
*A:PE-2# show service id 1 sdp 23:1 detail
===============================================================================
Service Destination Point (Sdp Id : 23:1) Details
===============================================================================
------------------------------------------------------------------------------Sdp Id 23:1 -(192.0.2.3)
------------------------------------------------------------------------------Description
: (Not Specified)
SDP Id
: 23:1
Type
: Spoke
Split Horiz Grp
: (Not Specified)
VC Type
: Ether
VC Tag
: n/a
Admin Path MTU
: 0
Oper Path MTU
: 1556
Far End
: 192.0.2.3
Delivery
: LDP
Admin State
Acct. Pol
Ingress Label
Ing mac Fltr
Ing ip Fltr
Ing ipv6 Fltr
Admin ControlWord
Admin BW(Kbps)
Last Status Change
Last Mgmt Change
Endpoint
Class Fwding State
Flags
Peer Pw Bits
Peer Fault Ip
Peer Vccv CV Bits
Peer Vccv CC Bits

:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:

Up
Oper State
: Up
None
Collect Stats
: Disabled
131070
Egress Label
: 131070
n/a
Egr mac Fltr
: n/a
n/a
Egr ip Fltr
: n/a
n/a
Egr ipv6 Fltr
: n/a
Not Preferred
Oper ControlWord : False
0
Oper BW(Kbps)
: 0
11/01/2009 11:01:50
Signaling
: TLDP
10/29/2009 17:14:13
Force Vlan-Vc
: Disabled
y
Precedence
: 4
Down
None
lacIngressFault lacEgressFault pwFwdingStandby
None
lspPing
mplsRouterAlertLabel

KeepAlive Information :
Admin State
: Disabled
Hello Time
: 10
Max Drop Count
: 3

Oper State
Hello Msg Len
Hold Down Time

: Disabled
: 0
: 10

Statistics
:
I. Fwd. Pkts.
: 0
I. Dro. Pkts.
: 0
E. Fwd. Pkts.
: 0
E. Fwd. Octets
: 0
------------------------------------------------------------------------------Number of SDPs : 1
------------------------------------------------------------------------------===============================================================================
*A:PE-2#

Advanced Configuration Guide

Page 1369

Configuration

In this example, the remote side of the SDP is sending lacIngressFault lacEgressFault
pwFwdingStandby flags. This is because the Epipe service on PE-3 is down because the MC-LAG
is in standby/down status.
Link and node protection can be tested. The access links are protected by the MC-LAG, the PE
routers are protected by the combination of MC-LAG/pseudowire redundancy. The SDPs can be
protected by FRR in the case of RSVP-TE.
Revertive behavior is expected when different MC-LAG port priorities are configured or if the
number of MC-LAG ports is different on the MC-LAG peers: convergence takes place when the
active PE fails and convergence takes place again when that PE is online again.
In case of revertive behavior MC-LAG convergence might take less time than the setup of the
spoke SDPs, thus creating a temporary blackhole. To avoid this situation its best to configure
hold-time up on the LAG ports. In that case the ports are kept in a down state for a configured
period of time after the node has rebooted. This is done to ensure that the SDPs are operationally
up when the MC-LAG convergence takes place. hold-time up is expressed in seconds.
*A:PE-1# configure port 1/1/1 ethernet hold-time up 50
*A:PE-1# configure port 1/1/2 ethernet hold-time up 50

Step 1.11 Inter-Chassis Backup (ICB) pseudowire configuration.

Note that in this setup the configuration of ICBs is optional. It can be used to speed up
convergence by forwarding in-flight packets during MC-LAG transition. Figure 116 shows some
setup examples where ICBs are required. ICBs cannot be configured at endpoints where the other
object is a standard SAP, only MC-LAG SAPs and pseudowires are allowed with ICBs.
Configure ICB SDPs and associate them to endpoints like shown in Figure 115.

Page 1370

Advanced Configuration Guide

Multi-Chassis LAG and Pseudowire Redundancy

LAG

SDP

MC-LAG

CE-1

PE-1
epipe
Y SDP
SAP X
SDP SDP

PE-3
epipe
Y SAP
SDP X

ICB Spoke-SDP

SDP SDP SDP

X Y
epipe

MC-LAG

ICB Spoke-SDP

SDP

CE-2

SDP SDP SDP

LAG
SAP

LAG

SDP SDP SDP

SDP

X Y SAP
epipe

PE-2

LAG

PE-4
OSSG383

Figure 115: ICB Spoke SDPs and Their Association with the Endpoints

Two ICB spoke SDPs must be configured in the Epipe service on each PE router, one in each
endpoint. Different SDP IDs can be used for the ICBs (as opposed to the regular pseudowires) but
this is not necessary since the far-end will be the same. The vc-id must be different however.
The ICB spoke SDPs must cross, one end should be associated with endpoint x and the other end
(on the other PE) should be associated with endpoint y. Note that after configuring the ICB spoke
SDPs the Epipe service will be up/up on all four PE routers.
Only one spoke SDPs will be forwarding. If there is an ICB and a MC-LAG SAP in an endpoint
the ICB will only forward if the SAP goes down. If an ICB resides in an endpoint together with
other spoke SDPs the ICB will only forward if there is no other active spoke SDP.
The following output shows the complete Epipe service configuration on each PE:
*A:PE-1>config>service>epipe# info
---------------------------------------------endpoint "x" create
exit
endpoint "y" create
exit
sap lag-1 endpoint "x" create
exit
spoke-sdp 13:1 endpoint "y" create
exit
spoke-sdp 14:1 endpoint "y" create
exit
spoke-sdp 12:1 endpoint "x" icb create

Advanced Configuration Guide

Page 1371

Configuration

exit
spoke-sdp 12:2 endpoint "y" icb create
exit
no shutdown
---------------------------------------------*A:PE-1>config>service>epipe

*A:PE-2>config>service>epipe# info
---------------------------------------------endpoint "x" create
exit
endpoint "y" create
exit
sap lag-1 endpoint "x" create
exit
spoke-sdp 23:1 endpoint "y" create
exit
spoke-sdp 24:1 endpoint "y" create
exit
spoke-sdp 21:1 endpoint "y" icb create
exit
spoke-sdp 21:2 endpoint "x" icb create
exit
no shutdown
---------------------------------------------*A:PE-2>config>service>epipe#

*A:PE-3>config>service>epipe# info
---------------------------------------------endpoint "x" create
exit
endpoint "y" create
exit
sap lag-1 endpoint "y" create
exit
spoke-sdp 31:1 endpoint "x" create
exit
spoke-sdp 32:1 endpoint "x" create
exit
spoke-sdp 34:1 endpoint "x" icb create
exit
spoke-sdp 34:2 endpoint "y" icb create
exit
no shutdown
---------------------------------------------*A:PE-3>config>service>epipe#

*A:PE-4>config>service>epipe# info
---------------------------------------------endpoint "x" create
exit
endpoint "y" create
exit
sap lag-1 endpoint "y" create
exit
spoke-sdp 41:1 endpoint "x" create

Page 1372

Advanced Configuration Guide

Multi-Chassis LAG and Pseudowire Redundancy

exit
spoke-sdp 42:1 endpoint "x" create
exit
spoke-sdp 43:1 endpoint "y" icb create
exit
spoke-sdp 43:2 endpoint "x" icb create
exit
no shutdown
---------------------------------------------*A:PE-4>config>service>epipe#

Advanced Configuration Guide

Page 1373

Configuration

Step 1.12 Verification of active objects for each endpoint.

The following command shows which objects are configured for each endpoint and which is the
active object at this moment:
*A:PE-1# show service id 1 endpoint
===============================================================================
Service 1 endpoints
===============================================================================
Endpoint name
: x
Description
: (Not Specified)
Revert time
: 0
Act Hold Delay
: 0
Ignore Standby Signaling
: false
Suppress Standby Signaling
: true
Block On Mesh Fail
: false
Tx Active
: lag-1
Tx Active Up Time
: 0d 01:30:25
Revert Time Count Down
: N/A
Tx Active Change Count
: 2
Last Tx Active Change
: 11/01/2009 11:06:10
------------------------------------------------------------------------------Members
------------------------------------------------------------------------------SAP
: lag-1
Oper Status: Up
Spoke-sdp: 12:1 Prec:4 (icb)
Oper Status: Up
===============================================================================
Endpoint name
: y
Description
: (Not Specified)
Revert time
: 0
Act Hold Delay
: 0
Ignore Standby Signaling
: false
Suppress Standby Signaling
: true
Block On Mesh Fail
: false
Tx Active
: 14:1
Tx Active Up Time
: 0d 01:30:48
Revert Time Count Down
: N/A
Tx Active Change Count
: 3
Last Tx Active Change
: 11/01/2009 11:05:48
------------------------------------------------------------------------------Members
------------------------------------------------------------------------------Spoke-sdp: 12:2 Prec:4 (icb)
Oper Status: Up
Spoke-sdp: 13:1 Prec:4
Oper Status: Up
Spoke-sdp: 14:1 Prec:4
Oper Status: Up
===============================================================================
*A:PE-1#

Note that on PE-1 the SAP and the spoke SDP 14:1 are active. The other objects do not forward
traffic.

Page 1374

Advanced Configuration Guide

Multi-Chassis LAG and Pseudowire Redundancy

Step 1.13 Other types of setups.

Figure 116 and Figure 117 shows other setups that combine MC-LAG and pseudowire
redundancy.
PE-1
epipe
LAG

LAG

MC-LAG

MC-LAG

ICB Spoke-SDP

CE-1

LAG

= SDP

ICB Spoke-SDP

X Y
epipe
PE-2

LAG

= SAP

LAG
MC-LAG

LAG

LAG
MC-LAG

LAG

PE-1
epipe
X Y

ICB Spoke-SDP

CE-1

LAG

CE-2

Spoke-SDP

X Y
epipe
PE-2

PE-1
epipe
X Y

Note: ICB parameter not required


on PE-1 and PE-3 but used
for consitency.

ICB Spoke-SDP

CE-1

CE-2

Spoke-SDP
PE-2
epipe

LAG
MC-LAG

LAG
Spoke-SDP

ICB Spoke-SDP

CE-2

PE-3
epipe
X Y

LAG

OSSG384

Figure 116: Additional Setup Example 1

Advanced Configuration Guide

Page 1375

Configuration

PE-1
epipe
MC-LAG

LAG

ICB Spoke-SDP

CE-1

SpokeSDP

PE-3
epipe
X

LAG

Y
CE-2

ICB Spoke-SDP
Spoke-SDP

X Y
epipe
PE-2

LAG

= SDP
= SAP

PE-1
epipe
MC-LAG

CE-1

LAG

ICB Spoke-SDP

SpokeSDP

PE-3
epipe
X

LAG

Y
CE-2

ICB Spoke-SDP

X Y
epipe
PE-2

LAG

PE-3
epipe

PE-1
epipe
X

DP

LAG

e-S
Spok

MC-LAG

Spok

ICB
Spoke-SDP

e-SD

ICB Spoke-SDP

CE-2

Sp

ok

e-

SD

X Y
epipe
PE-4

SD

e-

ok

Sp

MCD-LAG

DP

CE-1

PE-5
epipe

ok
e

-S

Sp

PE-2
epipe

P
SD

e-

ok

LAG

LAG

Sp

MC-LAG

e-SD

Spok

Spok

ICB
Spoke-SDP

ICB Spoke-SDP

CE-3

e-SD

P
X Y
epipe
PE-6

LAG

OSSG386

Figure 117: Additional Setup Example 2

Page 1376

Advanced Configuration Guide

Multi-Chassis LAG and Pseudowire Redundancy

MC-LAG in VPLS Services


MC-LAG can also be configured in VPLS services. When the MC-LAG converges the PE that
moves to standby state for the MC-LAG will send out an LDP address withdrawal message to all
peers configured in the VPLS service. Both types of SDPs (spoke and mesh) support this feature.
The PE peers will then flush all the MAC addresses learned through the PE that sent the LDP
MAC address withdrawal message.
Since a VPLS service is a multipoint service, pseudowire redundancy is not required. The MCLAG redundancy configuration is identical.

Advanced Configuration Guide

Page 1377

Configuration

Forced Switchover
MC-LAG convergence can be forced with tools perform lag command:
*A:PE-1# tools perform lag force
- force all-mc {active|standby}
- force lag-id <lag-id> [sub-group <sub-group-id>] {active|standby}
- force peer-mc <peer-ip-address> {active|standby}
<lag-id>
<sub-group-id>
<all-mc>
<peer-ip-address>
<active|standby>

:
:
:
:
:

[1..200]
[1..16]
keyword
a.b.c.d
keywords

After the forced switchover it is important to clear the forced switchover:


*A:PE1# tools perform lag clear-force
- clear-force all-mc
- clear-force lag-id <lag-id> [sub-group <sub-group-id>]
- clear-force peer-mc <ip-address>
<lag-id>
<sub-group-id>
<all-mc>
<ip-address>

Page 1378

:
:
:
:

[1..200]
[1..16]
keyword
a.b.c.d

Advanced Configuration Guide

Multi-Chassis LAG and Pseudowire Redundancy

Conclusion
MC-LAG is an Alcatel added value redundancy feature that offers fast access link convergence in
Epipe and VPLS services for CE devices that support standard LACP. PE node convergence for
VPLS services is enhanced by using LDP address withdrawal messages to flush the FDB on the
PE peers. PE node convergence for Epipes is guaranteed by using pseudowire redundancy.

Advanced Configuration Guide

Page 1379

Conclusion

Page 1380

Advanced Configuration Guide

Multi-Chassis Ring Layer 2 with


Enhanced Subscriber Management

In This Chapter
This section provides information about MC-Ring Layer 2 with Enhanced Subscriber
Management (ESM).
Topics in this section include:

Applicability on page 1382

Summary on page 1383

Overview on page 1384

Configuration on page 1389

Conclusion on page 1413

Advanced Configuration Guide

Page 1381

Applicability

Applicability
These configuration notes are applicable to all of the 7450, 7750 and 7710 SR series and was
tested on Release 7.0R5. The 7750 SR-c4 is supported from 8.0R4 and higher.
MC-Ring L2 with Enhanced Subscriber Management (ESM) was introduced in SR OS 6.0. There
are no other pre-requisites for the 7450, 7750 and 7710 SR this configuration.

Page 1382

Advanced Configuration Guide

Multi-Chassis Ring Layer 2 with Enhanced Subscriber

Summary
Multi-Chassis Ring (MC-ring) is an extension for dual homing support in TPSDA (Triple Play
Service Delivery Architecture) networks based on Layer 2-CO (Layer 2 Central Office) model.
The extension addresses networks where multiple access nodes (for example, DSLAMs, GPON
OLT) are connected in a single ring.
MC-ring Layer 2 ESM is considered an extension or evolution for ring topologies of the MultiChassis LAG dual-homing solution used for directly connected access nodes.
MC-ring Layer 2 CO is documented in the Triple Play Enhanced Subscriber Management / Dual
Homing section of the Triple Play Guide.

Advanced Configuration Guide

Page 1383

Overview

Overview
MC-Ring
Figure 118 shows a typical ring-based configuration of network model based on the Layer-2 CO
model.
Individual rings of access nodes are aggregated at the Broadband Service Aggregator (BSA) level
in one (or multiple) Virtual Private LAN Service (VPLS) service(s). At higher aggregation levels,
Broadband Service Router (BSR) individual BSAs are connected to Layer-3 interface (Internet
Enhanced Service (IES) or Virtual Private Routed Network (VPRN)) by means of spoke-SDP
(Service Distribution Point) termination. Every Layer 3 interface at the BSR level aggregates all
subscribers in one or more subnets. ESM is performed in the BSAs.

IP/MPLS
Core
BSR-1

BSR-2

VRF

VRF
VRRP

Spoke-sdp

Spoke-sdp
mesh-sdp

BSA-1

BSA-2
MCS

OSSG424

Figure 118: MC-Ring Layer 2 CO Dual Homing

The key functional components of the MC-Ring Layer 2 CO dual-homing redundancy solution
are:
1. Mirroring of the subscriber state between the two BSAs performing subscriber management
using the multi-chassis synchronization (MCS) protocol (BSA-1 and BSA-2 in Figure 118).
2. Ring control between the two BSAs, using the following mechanisms:

Page 1384

Advanced Configuration Guide

Multi-Chassis Ring Layer 2 with Enhanced Subscriber

In-band bi-directional forwarding detection (BFD) between the BSAs over the ring to
monitor ring integrity and detect failures. A BFD session between BSA-1 and BSA-2 runs
through the access ring using a dedicated IES/VPRN interface configured on both BSAs.
This connection uses a separate VLAN throughout the ring (access nodes provide
transparent bridging for this VLAN).

Out-of-band communication between the BSA nodes to exchange information about the
reachability of individual access nodes, and to verify the configuration consistency of the
ring. The information on configuration is synchronized through MCS (this use of MCS is
related to, but independent to, MCS for subscriber-state synchronization mentioned
above).

3. Ring Node Connectivity Verification (RNCV). Each BSA uses RNCV to detect the reachability of individual Access Nodes. It is used after a ring failure to determine which BSA
should handle the traffic of each Access Node. RNCV uses ARP requests to ping individual ANs, which must be configured with an IP address for this purpose.
4. Per-subscriber attribute (intermediate destination ID) for the BSA to know the Access Node
each subscriber is connected to (assigned through RADIUS or DHCP/Python).
5. VRRP in the BSRs to provide a redundant default gateway to the CPEs/Home Gateways.
BSRs do not perform any subscriber management functions.
The operation of dual homing at the BSA level will be covered based on two underlying
mechanisms.

Advanced Configuration Guide

Page 1385

Overview

MC-Ring Layer 2 CO Operation


To describe the functional behavior and operation of the dual-homing concept in a ring, it is best to
sub-divide the description into the following three parts:

Steady-state operation with ring fully closed

Transition to ring-broken state

Transition from ring-broken to steady state operation

Steady-State Operation of Dual-Homed Ring


Figure 119 illustrates the detailed operation of the dual-homed ring. The steady-state is achieved
under following conditions:

Both nodes are configured in a consistent way

The MCS peering relation is up

In-Band Ring Control Connection (IB-RCC) is in an operationally UP state. Note that this
connection is set-up using BFD session between IP interfaces on BSA-1 and BSA-2

Spoke-sdp

Spoke-sdp
mesh-sdp

path-a

BSA-1

BSA-2

MCS

path-b

RNCV
RNCV

RNCV
BFD
Session

OSSG425

Figure 119: Dual homing Under Steady-State Condition

Under the above conditions, the ring is fully closed and every access node (the ring-node) has two
possible paths toward the VPLS core. Figure 119 refers to them as path-a and path-b. In order to
avoid the loop created by the ring, only one of the paths may be used by any given ring-node for
any given VLAN. The assignment of the individual VLANs to path-a or path-b, respectively, has

Page 1386

Advanced Configuration Guide

Multi-Chassis Ring Layer 2 with Enhanced Subscriber

to be provisioned on both BSAs in a consistent manner. The BSA with a lower IP address in the
interface used for BFD will be the master for the VLANs associated with path-a and standby for
the VLANs associated with path-b.
The following summarizes the behavior of the master and standby BSA for a given path (a or b)
and the VLANs configured for that path:
Master BSA for the VLANs/SAPs associated with a given path (a or b):

SAPs associated with the path are operationally up and FDB entries for sub-hosts point to
the corresponding SAP

Master BSA for a path performs RNCV checks to all ring nodes. RNCV failures trigger an
alarm but do not trigger a switchover

The ARP reply agent replies to ARP requests for subscriber-hosts associated with ringnodes for which the BSA is master

Standby BSA:

All SAPs associated with the path for which the BSA is standby will be operationally
down and all FDB entries of subscriber hosts associated with those SAPs will point
towards an SDP connecting to the master BSA.

Broken-Ring Operation and the Transition to this State


Figure 120 illustrates the scenario with the broken ring (link failure or ring-node failure). This
state is reached under following conditions:

Both nodes are configured in a consistent way

The MCS peering relation is up

IB-RCC is in operationally down state

In this situation, every ring node has only one access path towards the VPLS core and hence the
path-a and path-b notion has no real meaning in this situation.
From a functional point of view, both BSAs are now the master for the ring-nodes they can reach.
For all hosts behind unreachable ring-nodes, the corresponding subscriber host FDB (Forwarding
DataBase) entries will point to SDP pointing to the other head-end ring PE.

Advanced Configuration Guide

Page 1387

Overview

Spoke-sdp

Spoke-sdp
mesh-sdp

path-a

BSA-1

BSA-2

path-b

MCS

OSSG426

Figure 120: Broken Ring State

Transition from Broken to Closed Ring State


MC-ring operates in a revertive mode. This means that whenever the ring connectivity is restored,
the BSA with the lower IP address in the IB-RCC communication channel will become master of
path-a and slave for ring-b with vice versa operations on the other BSA.
The actions in this case are straightforward. After restoration of BFD session, the master
functionality is assumed by respective BSAs. The FDB tables are updated according to the master/
standby role of the given BSA and FDB population messages will be sent accordingly.

Page 1388

Advanced Configuration Guide

Multi-Chassis Ring Layer 2 with Enhanced Subscriber

Configuration
CE-1
172.16.0.1
CE-2

PE-1

172.16.0.2

192.0.2.1

192.168.0.0/30

192.168.9.0/30

192.168.1.0/30

PE-3
192.0.2.3

192.168.0.0/30

192.168.4.0/30

192.168.2.0/30

PE-5
192.0.2.5

PE-4

PE-2

CE-3

192.0.2.2

172.16.0.3

192.168.3.0/30

192.168.5.0/30

192.0.2.4

CE-4
172.16.0.4

BTV-client
DSLAM-simulator

BTV-server
DHCP-server
OSSG427

Figure 121: Network Topology

The network topology is displayed in Figure 121. The setup consists of two BSA nodes (PE-1 and
PE-2), two BSR nodes (PE-3, PE-4) and another PE router (PE-5). A setup with one BSR node
and two BSA nodes can also be used, but in this example, two (2) BSR nodes were used to show
the typical Layer 2-CO setup with VRRP and Protocol Independent Multicast (PIM) on the BSRs.
The access ring consists of four CE nodes.

Advanced Configuration Guide

Page 1389

Configuration

Base Topology
This section assumes that the following base configuration has been implemented on the PE:

Cards, MDAs and ports configured

Interfaces configured

IGP (Interior Gateway Protocol) configured and converged LDP (Label Distribution
Protocol) configured on the interfaces between PE-3-PE-1, PE-1-PE-2 and PE-2-PE-4

T-LDP (Targeted-LDP) configured on PE-1, PE-2, PE-3, PE-4

SDPs configured between PE-3-PE-1, PE-1-PE-2 and PE-2-PE-4

Note that you can choose between OSPF and IS-IS as the IGP. Both LDP and RSVP (Resource
Reservation Protocol) can be used for signaling the transport MPLS labels. Alternatively, GRE
(Generic Routing Encapsulation) can be used for the transport tunnels. In this example, OSPF is
configured and LDP SDPs are used.
7750 SR routers are used as ring-nodes to simulate Access Nodes. Ring-nodes can be any L2
device that support VLANs and have the ability to connect an IP interface to one VLAN (required
for RNCV).

NTP Configuration
Time must be the same on the redundant NSAs (PE-1 and PE-2); otherwise, the lease times will be
different on both nodes. NTP can be used:
configure system time
ntp
server 10.30.30.30 prefer
no shutdown
exit
exit all

MC-Ring Configuration
Configure a VPLS service on the CE routers for the In-Band Ring Control connection (BFD
packets between PE-1 and PE-2 traversing the ring). This VPLS service will also be used for
RNCV. Note that an Epipe service can also be used in case the service is only used for BFD. In
that case, a separate service is required for the RNCV.
In this example, QinQ encapsulation is used and BFD and RNCV packets will use VLAN tag 1.
Note that dot1q encapsulation can also be used.

Page 1390

Advanced Configuration Guide

Multi-Chassis Ring Layer 2 with Enhanced Subscriber

The configuration of CE-1 is shown below. A similar configuration is required on the other CE
routers.
configure
port 1/1/1
ethernet
mode access
encap-type qinq
exit
no shutdown
exit
port 1/1/2
ethernet
mode access
encap-type qinq
exit
no shutdown
exit
service
vpls 1 customer 1 create
interface "lo1" create
address 172.16.0.1/24
exit
sap 1/1/1:1.0 create
exit
sap 1/1/2:1.0 create
exit
no shutdown
exit
exit all

An interface lo1 is created in the VPLS. This interface will be used for RNCV.
On the BSA nodes (PE-1 and PE-2), configure an IES services that will originate BFD and RNCV
messages. On PE-1:
configure
port 1/1/1
ethernet
mode access
encap-type qinq
exit
no shutdown
exit
service
ies 1 customer 1 create
interface "bfd-rncv1" create
address 172.16.0.251/24
bfd 100 receive 100 multiplier 3
sap 1/1/1:1.0 create
exit
exit
no shutdown
exit
exit all

Advanced Configuration Guide

Page 1391

Configuration

On PE-2:
configure
port 1/1/2
ethernet
mode access
encap-type qinq
exit
no shutdown
exit
service
ies 1 customer 1 create
interface "bfd-rncv1" create
address 172.16.0.252/24
bfd 100 receive 100 multiplier 3
sap 1/1/2:1.0 create
exit
exit
no shutdown
exit
exit all

In-Band Ring Control Connection BFD is always originated on an IES or VPRN service on the
BSA nodes. RNCV messages can be originated from the same IES/VPRN service or from a
separate service.
Configure Multi-Chassis Synchronization (MCS) on the BSA nodes. Enable MCS for igmpsnooping, mc-ring and sub-mgmt. The configuration of PE-1 is shown below. The configuration
of PE-2 is similar.
configure redundancy multi-chassis peer 192.0.2.2 create
sync
igmp-snooping
mc-ring
sub-mgmt
port 1/1/1 sync-tag "l2ring1" create
exit
no shutdown
exit
no shutdown
exit all

Add the MC-ring configuration on the BSA nodes and link the Ring Control Connection BFD
session to the IES service created before.
configure redundancy multi-chassis peer 192.0.2.2 create
mc-ring
ring "l2ring1" create
in-band-control-path
service-id 1
interface "bfd-rncv1"
dst-ip 172.16.0.252
exit
no shutdown
exit

Page 1392

Advanced Configuration Guide

Multi-Chassis Ring Layer 2 with Enhanced Subscriber

exit
no shutdown
exit all

Note that the ring name is exactly the same as the sync-tag already configured.
At this moment, the MC-ring should be up:
A:PE-1# show redundancy multi-chassis mc-ring peer 192.0.2.2 ring l2ring1 detail
===============================================================================
Multi-Chassis MC-Ring Detailed Information
===============================================================================
Peer
: 192.0.2.2
Ring Type
: Layer 2
Sync Tag
: l2ring1
Port ID
: 1/1/1
Admin State
: inService
Oper State
: connected
Admin Change
: 11/05/2009 21:17:54
Oper Change
: 11/05/2009 21:17:54
Failure Reason : None
Control B Path : No
------------------------------------------------------------------------------In Band Control Path
------------------------------------------------------------------------------Service ID
: 1
Interface Name : bfd-rncv1
Oper State
: connected
Dest IP
: 172.16.0.252
Src IP
: 172.16.0.251
...

Next, configure under MCS the ring nodes on PE-1 and PE-2. This configuration will be used for
the RNCV. The ring node configuration for CE-1 is shown below:
configure redundancy multi-chassis peer 192.0.2.2 mc-ring ring l2ring1
ring-node "CE-1" create
connectivity-verify
dst-ip 172.16.0.1
interval 1
service-id 1
vlan 1
no shutdown
exit
exit
exit all

Advanced Configuration Guide

Page 1393

Configuration

Note that the interval parameter is the interval used to check the reachability of the CE nodes
(configurable from 1 to 6000 minutes). A BFD failure will also be a trigger for a reachability
check.
The configuration on PE-2 is identical and the configuration of the other ring nodes is similar..
Configure VLAN 3 to take path-b (default is path-a).
configure redundancy multi-chassis peer 192.0.2.2 mc-ring ring l2ring1
path-b
range 3-3
exit
exit all

MC-Ring Verification
Verify that MCS is up and running:
A:PE-1# show redundancy multi-chassis all
===============================================================================
Multi-Chassis Peers
===============================================================================
Peer IP
Src IP
Auth
Peer Admin
MC-Ring Oper MC-EP Adm
MCS Admin
MCS Oper
MCS State MC-LAG Adm
MC-LAG Oper
------------------------------------------------------------------------------192.0.2.2
192.0.2.1
None
Enabled
inService
-Enabled
Enabled
inSync
Disabled
Disabled
===============================================================================

The output shows that MCS is administrative and operational up and that both peers are
synchronized. MC-ring is operational in service.

The following output shows more detailed information about the configured ring:
A:PE-1# show redundancy multi-chassis mc-ring peer 192.0.2.2 ring l2ring1 detail
===============================================================================
Multi-Chassis MC-Ring Detailed Information
===============================================================================
Peer
: 192.0.2.2
Ring Type
: Layer 2
Sync Tag
: l2ring1
Port ID
: 1/1/1
Admin State
: inService
Oper State
: connected
Admin Change
: 11/05/2009 21:22:29
Oper Change
: 11/05/2009 21:22:29
Failure Reason : None
Control B Path : No
------------------------------------------------------------------------------In Band Control Path

Page 1394

Advanced Configuration Guide

Multi-Chassis Ring Layer 2 with Enhanced Subscriber

------------------------------------------------------------------------------Service ID
: 1
Interface Name : bfd-rncv1
Oper State
: connected
Dest IP
: 172.16.0.252
Src IP
: 172.16.0.251
Debounce State : inService
Debounce Max
: 10 s
Debounce Guard : 60 s
------------------------------------------------------------------------------VLAN Managed Range
------------------------------------------------------------------------------full range
------------------------------------------------------------------------------VLAN Map B Path Provisioned
------------------------------------------------------------------------------range 3-3
------------------------------------------------------------------------------VLAN Map Excluded Path Provisioned
------------------------------------------------------------------------------no range
------------------------------------------------------------------------------VLAN Map B Path Operational
------------------------------------------------------------------------------range 3-3
------------------------------------------------------------------------------VLAN Map Excluded Path Operational
------------------------------------------------------------------------------no range

The output above shows that the ring l2ring1 on port 1/1/1 is in service and connected. Ring-node
Connectivity Check (BFD) is running on interface bfd-rncv1 in service 1. All VLANs on port 1/
1/1 use path-a (default) except VLAN 3, which uses path-b.
The BSA peer with the lower IP address (the master) will put the SAPs configured for path-a in
operational up state while the SAPs configured in path-b will be put in operational down state. The
other BSA peer will do the reverse. This is done to prevent loops in the ring.
Note that no VLANs are configured to be excluded from the paths. If a VLAN is configured to be
excluded from the paths, the respective SAPs of this VLAN on both BSA nodes will be
operationally up.
Check which ring-nodes are configured and connected:
A:PE-1# show redundancy multi-chassis mc-ring peer 192.0.2.2 ring l2ring1 ring-node
==============================================================================
MC-Ring Node entries
==============================================================================
Name
Loc Oper St.
Failure Reason
In Use
Rem Oper St.
-----------------------------------------------------------------------------CE-1
connected
None
No
notTested
CE-2
connected
None
No
notTested
CE-3
connected
None

Advanced Configuration Guide

Page 1395

Configuration

No
notTested
CE-4
connected
None
No
notTested
-----------------------------------------------------------------------------No. of MC-Ring Node entries: 4
==============================================================================
A:PE-1#

The output above shows that four ring-nodes are connected. Only the master will send RNCV
messages to the ring-nodes. As soon as a ring failure occurs, the BFD session goes down and both
BSA nodes send out RNCV messages to see which ring-nodes are connected. Note that when the
reachability of the CE nodes is determined, the RNCV messages will be sent at a continuous
interval (see above).
More detail about each ring-node can be provided with following command:
A:PE-1# show redundancy multi-chassis mc-ring peer 192.0.2.2 ring l2ring1 ring-node CE-1
detail
===============================================================================
Multi-Chassis MC-Ring Node Detailed Information
===============================================================================
Peer
: 192.0.2.2
Sync Tag
: l2ring1
Node Name
: CE-1
Oper State Loc : connected
Oper State Rem : notTested
In Use
: False
Admin Change
: 11/05/2009 21:21:30
Oper Change
: 11/05/2009 21:22:32
Failure Reason : None
------------------------------------------------------------------------------Ring Node Connectivity Verification
------------------------------------------------------------------------------Admin State
: inService
Service ID
: 1
Encap Value
: 1
Dest IP
: 172.16.0.1
Src IP
: None
Interval
: 1 minutes
Src MAC
: None
===============================================================================
A:PE-1#

Page 1396

Advanced Configuration Guide

Multi-Chassis Ring Layer 2 with Enhanced Subscriber

Unicast Services Configuration


Figure 122 shows the logical setup of the services that will be created. Note that a mesh SDP is
used between PE-1 and PE-2. A spoke SDP could also be used.

CE-1
VPLS

BFD
RNCV
PE-1

PE-3

= SAP

IES
SpokeSDP
CE-2

= SDP

IES

VPLS

VPLS
PE-5

Mesh-SDP

VRRP

CE-3
VPLS
PE-2

SpokeSDP

PE-4
IES

VPLS
CE-4

IES

VPLS

DHCP-server

DHCP-server
BFD RNCV
OSSG428

Figure 122: Unicast Services Logical Topology

In this setup, two unicast services (VPLS 2 and VPLS 3) are created. VPLS 2 uses path-a and
VPLS 3 uses path-b.
The services use a mesh SDP between PE-1 and PE-2 and a spoke-SDP between PE-1/PE-3 and
another spoke SDP between PE-2/PE-4. On PE-3 and PE-4 a spoke SDP terminated IES is
configured with a VRRP default gateway address. The VRRP packets are switched through the
BSAs.
IGMP snooping and ESM are configured on both services. ESM is required since the BSA node
must know which ring-node each subscriber is connected to. In this setup, the intermediate
destination identifier (int_dest_id) will be returned by Option 254 in x Dynamic Host Control
Protocol (DHCP). ESM configuration details are outside the scope of this document. Refer to the
appropriate platform OS Triple Play Guide.

Advanced Configuration Guide

Page 1397

Configuration

The following output shows the configuration of VPLS 2 on PE-1:


configure service
vpls 2 customer 1 create
description "VLAN_2"
split-horizon-group "RSHG" residential-group create
exit
sap 1/1/1:2.* split-horizon-group "RSHG" create
dhcp
snoop
lease-populate 10
no shutdown
exit
anti-spoof ip-mac
sub-sla-mgmt
def-sub-profile "initial"
def-sla-profile "initial"
sub-ident-policy "speedy"
multi-sub-sap 10
no shutdown
exit
exit
mesh-sdp 12:2 create
dhcp
snoop
exit
exit
spoke-sdp 13:2 create
dhcp
snoop
exit
exit
no shutdown
exit
exit all

The configuration of VPLS 3 is similar. The configuration of VPLS 2 and 3 are similar on PE-2.
The output below shows the subscriber management configuration on PE-1. Similar configuration
is required on PE-2.
configure subscriber-mgmt
sla-profile "initial" create
exit
sub-profile "initial" create
exit
sub-ident-policy "speedy" create
strings-from-option 254
exit
exit all

Page 1398

Advanced Configuration Guide

Multi-Chassis Ring Layer 2 with Enhanced Subscriber

Also, configure VLAN 2 and 3 on all the ring-nodes. This configuration is straightforward. Below
is an example of the VLAN 2 configuration on CE-1. In this example, the client is connect to port
1/1/3 and should send packets with an outer tag of 2:
configure service
vpls 2 customer 1
sap 1/1/1:2.*
exit
sap 1/1/2:2.*
exit
sap 1/1/3:2.*
exit
no shutdown
exit
exit all

create
create
create
create

In the example, VLAN 2.* and 3.* is used to allow for transparent transport of the customer
VLAN.
The IES service where VPLS 2 terminates looks like this on BSR PE-3:
configure service
ies 2 customer 1 create
interface "VLAN_2" create
address 10.0.2.3/24
dhcp
server 10.10.10.10
trusted
no shutdown
exit
ip-mtu 1500
vrrp 2
backup 10.0.2.254
ping-reply
exit
local-proxy-arp
spoke-sdp 31:2 create
exit
exit
no shutdown
exit
exit all

And on PE-4:
configure service
ies 2 customer 1 create
interface "VLAN_2" create
address 10.0.2.4/24
dhcp
server 10.10.10.10
trusted
no shutdown
exit
ip-mtu 1500
vrrp 2

Advanced Configuration Guide

Page 1399

Configuration

backup 10.0.2.254
ping-reply
exit
local-proxy-arp
spoke-sdp 42:2 create
exit
exit
no shutdown
exit
exit all

Notice that the ip-mtu must be set to match the vc-mtu signaled by the other side of the spokeSDP. Otherwise, the service will be operationally down with a ServiceMTUMismatch.
Note also in the configuration that DHCP relay is done by configuring a DHCP server under the
IES interface.
The configuration of IES 3 on PE-3 and PE-4 is similar..
On PE-5 an IES interface is configured to the DHCP-server. The interface is configured with a
Dot1Q encapsulated port because this port will be also be used for an interface to the multicast
server.
configure service
ies 2 customer 1 create
interface "dhcp-server" create
address 192.168.6.1/30
sap 1/1/3:2 create
exit
exit
no shutdown
exit
exit all

Page 1400

Advanced Configuration Guide

Multi-Chassis Ring Layer 2 with Enhanced Subscriber

Unicast Services Verification


Request an IP address on VLAN 2 on CE-1. On BSA routers PE-1 and PE-2 following DHCP info
can be checked:
A:PE-1# show service id 2 dhcp lease-state
===============================================================================
DHCP lease state table, service 2
===============================================================================
IP Address
Mac Address
Sap/Sdp Id
Remaining Lease
MC
LifeTime
Origin
Stdby
------------------------------------------------------------------------------10.0.2.107
00:00:64:01:01:02 1/1/1:2.*
09d07h38m DHCP
------------------------------------------------------------------------------Number of lease states : 1
===============================================================================

ESM show commands can be used to obtain the subscriber identity, IP address, MAC address and
SLA-profile:
A:PE-1# show service active-subscribers
===============================================================================
Active Subscribers
===============================================================================
------------------------------------------------------------------------------Subscriber subscriber_1_vlan_2 (initial)
------------------------------------------------------------------------------------------------------------------------------------------------------------(1) SLA Profile Instance sap:1/1/1:2.* - sla:initial
------------------------------------------------------------------------------IP Address
MAC Address
PPPoE-SID Origin
------------------------------------------------------10.0.2.107
00:00:64:01:01:02 N/A
DHCP
------------------------------------------------------------------------------Number of active subscribers : 1
===============================================================================

The following command gives more information about a specific subscriber:


A:PE-1# show service active-subscribers subscriber subscriber_1_vlan_2 detail
===============================================================================
Active Subscribers
===============================================================================
------------------------------------------------------------------------------Subscriber subscriber_1_vlan_2 (initial)
------------------------------------------------------------------------------I. Sched. Policy : N/A
E. Sched. Policy : N/A
E. Agg Rate Limit: Max
Q Frame-Based Ac*: Disabled
Acct. Policy
: N/A
Collect Stats
: Disabled
Rad. Acct. Pol. : N/A
Dupl. Acct. Pol. : N/A

Advanced Configuration Guide

Page 1401

Configuration

ANCP Pol.
: N/A
HostTrk Pol.
: N/A
Sub. ANCP-String : "subscriber_1_vlan_2"
Sub. Int Dest Id : "CE-1"
Host Trk Rate Adj: N/A
------------------------------------------------------------------------------(1) SLA Profile Instance
- sap:1/1/1:2.* (VPLS 2)
- sla:initial
------------------------------------------------------------------------------Description
: (Not Specified)
Host Limit
: No Limit
Ingress Qos-Policy
: 1
Egress Qos-Policy : 1
Ingress Queuing Type : Service-queuing
Ingress Filter-Id
: N/A
Egress Filter-Id : N/A
Ingress Report-Rate : N/A
Egress Report-Rate
: N/A
Egress Remarking
: from Sap Qos
Credit Control Pol. : N/A
------------------------------------------------------------------------------------------------------------------------------------------------------------IP Address
MAC Address
PPPoE-SID Origin
------------------------------------------------------10.0.2.107
00:00:64:01:01:02 N/A
DHCP

The output above gives more details about which ring-node the customer is connected to (Sub. Int
Dest Id : CE-1), which QoS policies are applied, statistics of each queue,

MCS Verification
Check if the two redundant peers are in sync and check the detailed MCS info:
A:PE-1# show redundancy multi-chassis sync peer 192.0.2.2
===============================================================================
Multi-chassis Peer Table
===============================================================================
Peer
------------------------------------------------------------------------------Peer IP Address
: 192.0.2.2
Description
: (Not Specified)
Authentication
: Disabled
Source IP Address
: 192.0.2.1
Admin State
: Enabled
------------------------------------------------------------------------------Sync-status
------------------------------------------------------------------------------Client Applications
: IGMPSnooping SUBMGMT RING
Sync Admin State
: Up
Sync Oper State
: Up
DB Sync State
: inSync
Num Entries
: 11
Lcl Deleted Entries
: 0
Alarm Entries
: 0
Rem Num Entries
: 11
Rem Lcl Deleted Entries : 0

Page 1402

Advanced Configuration Guide

Multi-Chassis Ring Layer 2 with Enhanced Subscriber

Rem Alarm Entries


: 0
===============================================================================
MCS Application Stats
===============================================================================
Application
: igmp
Num Entries
: 0
Lcl Deleted Entries
: 0
Alarm Entries
: 0
------------------------------------------------------------------------------Rem Num Entries
: 0
Rem Lcl Deleted Entries : 0
Rem Alarm Entries
: 0
------------------------------------------------------------------------------Application
: igmpSnooping
Num Entries
: 0
Lcl Deleted Entries
: 0
Alarm Entries
: 0
------------------------------------------------------------------------------Rem Num Entries
: 0
Rem Lcl Deleted Entries : 0
Rem Alarm Entries
: 0
------------------------------------------------------------------------------Application
: subMgmt
Num Entries
: 1
Lcl Deleted Entries
: 0
Alarm Entries
: 0
------------------------------------------------------------------------------Rem Num Entries
: 1
Rem Lcl Deleted Entries : 0
Rem Alarm Entries
: 0
------------------------------------------------------------------------------Application
: srrp
Num Entries
: 0
Lcl Deleted Entries
: 0
Alarm Entries
: 0
------------------------------------------------------------------------------Rem Num Entries
: 0
Rem Lcl Deleted Entries : 0
Rem Alarm Entries
: 0
------------------------------------------------------------------------------Application
: mcRing
Num Entries
: 10
Lcl Deleted Entries
: 0
Alarm Entries
: 0
------------------------------------------------------------------------------Rem Num Entries
: 10
Rem Lcl Deleted Entries : 0
Rem Alarm Entries
: 0
------------------------------------------------------------------------------Application
: mldSnooping
Num Entries
: 0
Lcl Deleted Entries
: 0
Alarm Entries
: 0
------------------------------------------------------------------------------Rem Num Entries
: 0
Rem Lcl Deleted Entries : 0
Rem Alarm Entries
: 0
------------------------------------------------------------------------------Application
: dhcpServer

Advanced Configuration Guide

Page 1403

Configuration

Num Entries
: 0
Lcl Deleted Entries
: 0
Alarm Entries
: 0
------------------------------------------------------------------------------Rem Num Entries
: 0
Rem Lcl Deleted Entries : 0
Rem Alarm Entries
: 0
------------------------------------------------------------------------------Application
: subHostTrk
Num Entries
: 0
Lcl Deleted Entries
: 0
Alarm Entries
: 0
------------------------------------------------------------------------------Rem Num Entries
: 0
Rem Lcl Deleted Entries : 0
Rem Alarm Entries
: 0
------------------------------------------------------------------------------===============================================================================
A:PE-1#

The output shows that both MCS peers are in sync and that entries are populated for MC-ring and
Subscriber Management (DHCP lease states).
Notice that the lease states are also populated on PE-2:
A:PE-2# show service id 2 dhcp lease-state
===============================================================================
DHCP lease state table, service 2
===============================================================================
IP Address
Mac Address
Sap/Sdp Id
Remaining Lease
MC
LifeTime
Origin
Stdby
------------------------------------------------------------------------------10.0.2.107
00:00:64:01:01:02 1/1/2:2.*
09d06h16m DHCP
Yes
------------------------------------------------------------------------------Number of lease states : 1
===============================================================================
A:PE-2#

The output is similar to the output on PE-1 except that on PE-2 the flag MC-Stdby is set to yes,
which implies that this node is in standby mode for this VLAN.
This can be verified by looking at the status of the SAP on PE-1 and PE-2. On PE-1 the SAP is
operationally up:
A:PE-1# show service id 2 sap 1/1/1:2.*
===============================================================================
Service Access Points(SAP)
===============================================================================
Service Id
: 2
SAP
: 1/1/1:2.*
Encap
: qinq
QinQ Dot1p
: Default
Description
: (Not Specified)
Admin State
: Up
Oper State
: Up
Flags
: None
Multi Svc Site
: None
Last Status Change : 11/06/2009 17:17:26

Page 1404

Advanced Configuration Guide

Multi-Chassis Ring Layer 2 with Enhanced Subscriber

Last Mgmt Change


: 11/04/2009 22:51:15
===============================================================================

On PE-2 the situation is different:


A:PE-2# show service id 2 sap 1/1/2:2.*
===============================================================================
Service Access Points(SAP)
===============================================================================
Service Id
: 2
SAP
: 1/1/2:2.*
Encap
: qinq
QinQ Dot1p
: Default
Description
: (Not Specified)
Admin State
: Up
Oper State
: Down
Flags
: StandByForMcRing
Multi Svc Site
: None
Last Status Change : 11/06/2009 18:07:30
Last Mgmt Change
: 11/04/2009 23:43:16
===============================================================================

Notice that the SAP on PE-2 is operationally down and that a flag is set: StandByForMcRing.
The situation is reversed for VLAN 3 since it was configured for path-b; here the SAP on PE-1 is
operationally down and the SAP on PE-2 is operationally up.

Ring Failure Verification


In case a ring failure occurs (either ring link failure or ring-node failure), the IB-RCC BFD session
between PE-1 and PE-2 will go down and both nodes will put the SAP in operational up state.
Break the link between CE-2 and CE-1.
Observe that the ring is now in a broken state:
A:PE-1# show redundancy multi-chassis mc-ring peer 192.0.2.2
==============================================================================
MC-Ring entries
==============================================================================
Sync Tag
Oper State
Failure Reason
-----------------------------------------------------------------------------l2ring1
broken
None
-----------------------------------------------------------------------------No. of MC-Ring entries: 1
==============================================================================

Advanced Configuration Guide

Page 1405

Configuration

The following command shows the BSA to ring nodes connections:


A:PE-1# show redundancy multi-chassis mc-ring peer 192.0.2.2 ring l2ring1 ring-node
==============================================================================
MC-Ring Node entries
==============================================================================
Name
Loc Oper St.
Failure Reason
In Use
Rem Oper St.
-----------------------------------------------------------------------------CE-1
connected
None
Yes
disconnected
CE-2
disconnected
None
No
connected
CE-3
disconnected
None
No
connected
CE-4
disconnected
None
No
connected
-----------------------------------------------------------------------------No. of MC-Ring Node entries: 4
==============================================================================

The output shows that CE-1 is connected to PE-1. CE-2, CE-3 and CE4 are connected to PE-2.
Notice that the SAPs on both PE-1 and PE-2 are now operationally up. This can be checked with
the show service id 2 sap 1/1/1:2.* command on PE1 and the show service id 2 sap 1/1/2:2.*
command on PE2.
Following the ring failure, the BSA nodes send a MAC address withdrawal message to all the SDP
peers configured in the VPLS.

Page 1406

Advanced Configuration Guide

Multi-Chassis Ring Layer 2 with Enhanced Subscriber

Multicast Service Configuration


In general, BTV (Broadcast TV) services are delivered to the DSLAM on a different VLAN using
a different VPLS service. The DSLAM can send/relay IGMP group membership messages if it
wants to receive a multicast stream. At the BSA level (PE-1 and PE-2), IGMP snooping is
configured. At the BSR level (PE-3, PE-4) and the PE where the video source is located, PIM is
configured and IGMP is configured on the IES service facing the BSA ring. The BSA ring
consists of concatenated spoke SDPs. The spoke SDP ring is not closed between PE-3 and PE-4 to
avoid a loop. Figure 123 shows the logical setup for the multicast service with a MC-ring.

CE-1
VPLS

BFD
RNCV
PE-1

= SDP

PE-3

= SAP

IES
SpokeSDP
CE-2

IES

VPLS

VPLS
PE-5

Spoke-SDP

PIM

CE-3
VPLS
PE-2

SpokeSDP

PE-4
IES

VPLS
CE-4

IES

VPLS

BTV Client

BTV-server
BFD RNCV
OSSG429

Figure 123: Multicast Service Logical Setup

Configure an interface to the multicast server on PE-5:


configure service
ies 3 customer 1 create
interface "mcast-server" create
address 192.168.7.1/30
sap 1/1/3:3 create
exit
exit
no shutdown

Advanced Configuration Guide

Page 1407

Configuration

exit
exit all

Configure a VPLS service on PE-1 and PE-2. The configuration on PE-1 is shown below. The
VPLS configuration on PE-2 is similar.
configure service
vpls 4 customer 1 create
description "Multicast VLAN"
igmp-snooping
no shutdown
exit
sap 1/1/1:4.* create
exit
spoke-sdp 12:4 create
igmp-snooping
mrouter-port
exit
exit
spoke-sdp 13:4 create
igmp-snooping
mrouter-port
exit
exit
no shutdown
exit
exit all

Notice that igmp-snooping has been enabled and that the spoke SDPs are configured as mrouterports in order to forward the IGMP joins to the BSRs.
Configure a spoke SDP terminated IES service on PE-3:
configure service
ies 4 customer 1 create
interface "btv-dst" create
address 10.0.4.3/24
ip-mtu 1500
spoke-sdp 31:4 create
exit
exit
no shutdown
exit
exit all

On PE-4:
configure service
ies 4 customer 1 create
interface "btv-dst" create
address 10.0.4.4/24
ip-mtu 1500
spoke-sdp 42:4 create
exit
exit
no shutdown

Page 1408

Advanced Configuration Guide

Multi-Chassis Ring Layer 2 with Enhanced Subscriber

exit
exit all

Notice that also here the ip-mtu must be configured to bring the service up. The ip-mtu is
required to have an MTU match on the spoke SDP between the IES service and the VPLS service.
Configure PIM on PE-3, PE-4 and PE-5. The configuration on PE-3 is shown below. The PIM
configuration on PE-4 and PE-5 is similar.
configure router pim
interface "system"
exit
interface "int-PE-3-PE-4"
priority 10
exit
interface "int-PE-3-PE-5"
exit
interface "btv-dst"
exit
rp
static
address 192.0.2.5
group-prefix 224.0.0.0/4
exit
exit
exit
exit all

Note that PE-5 is statically configured as the RP. This is just an example. Different configurations
can be used.
Configure IGMP on PE-3/PE-4:
configure router igmp interface btv-dst no shutdown

The service should also be configured on all ring nodes. Below, the configuration on CE-2 is
shown. Similar configurations are required on the other ring-nodes.
configure service
vpls 4 customer 1
sap 1/1/1:4.*
exit
sap 1/1/2:4.*
exit
sap 1/1/3:4.*
exit
no shutdown
exit
exit all

Advanced Configuration Guide

create
create
create
create

Page 1409

Configuration

Multicast Service Verification


Configure the multicast server to send one or more multicast streams. Have the BTV client
connected to CE-2 send an IGMP join message for this multicast stream.
On the BSA routers (PE-1/PE-2), IGMP snooping can be checked:
A:PE-1# show service id 4 mfib
===============================================================================
Multicast FIB, Service 4
===============================================================================
Source Address Group Address
Sap/Sdp Id
Svc Id
Fwd/Blk
------------------------------------------------------------------------------*
*
sdp:12:4
Local
Fwd
sdp:13:4
Local
Fwd
*
225.1.1.1
sap:1/1/1:4.*
Local
Fwd
sdp:12:4
Local
Fwd
sdp:13:4
Local
Fwd
------------------------------------------------------------------------------Number of entries: 2
===============================================================================

On PE-3/PE-4 the IGMP groups can be checked:


A:PE-3# show router igmp group
===============================================================================
IGMP Groups
===============================================================================
(*,225.1.1.1)
Up Time : 0d 00:01:03
Fwd List : btv-dst
------------------------------------------------------------------------------(*,G)/(S,G) Entries : 1
===============================================================================

Following command shows that the MCS peers are synchronized and that there is one IGMP entry
on both peers:
A:PE-1# show redundancy multi-chassis sync peer 192.0.2.2 detail
===============================================================================
Multi-chassis Peer Table
===============================================================================
Peer
------------------------------------------------------------------------------Peer IP Address
: 192.0.2.2
Description
: (Not Specified)
Authentication
: Disabled
Source IP Address
: 192.0.2.1
Admin State
: Enabled
------------------------------------------------------------------------------Sync-status
------------------------------------------------------------------------------Client Applications
: IGMPSnooping SUBMGMT RING
Sync Admin State
: Up
Sync Oper State
: Up
DB Sync State
: inSync

Page 1410

Advanced Configuration Guide

Multi-Chassis Ring Layer 2 with Enhanced Subscriber

Num Entries
: 12
Lcl Deleted Entries
: 0
Alarm Entries
: 0
Rem Num Entries
: 12
Rem Lcl Deleted Entries : 0
Rem Alarm Entries
: 0
===============================================================================
MCS Application Stats
===============================================================================
Application
: igmp
Num Entries
: 1
Lcl Deleted Entries
: 0
Alarm Entries
: 0
------------------------------------------------------------------------------Rem Num Entries
: 1
Rem Lcl Deleted Entries : 0
Rem Alarm Entries
: 0

Notice that the MFIB on PE-2 has also been updated:


A:PE-2# show service id 4 mfib
===============================================================================
Multicast FIB, Service 4
===============================================================================
Source Address Group Address
Sap/Sdp Id
Svc Id
Fwd/Blk
------------------------------------------------------------------------------*
*
sdp:21:4
Local
Fwd
sdp:24:4
Local
Fwd
*
225.1.1.1
sap:1/1/2:4.*
Local
Fwd
sdp:21:4
Local
Fwd
sdp:24:4
Local
Fwd
------------------------------------------------------------------------------Number of entries: 2
===============================================================================
A:PE-2#

The SAP on PE-2 is down to avoid duplicated traffic and loops:


A:PE-2# show service id 4 sap 1/1/2:4.*
===============================================================================
Service Access Points(SAP)
===============================================================================
Service Id
: 4
SAP
: 1/1/2:4.*
Encap
: qinq
QinQ Dot1p
: Default
Description
: (Not Specified)
Admin State
: Up
Oper State
: Down
Flags
: StandByForMcRing
Multi Svc Site
: None
Last Status Change : 11/06/2009 18:56:25
Last Mgmt Change
: 11/04/2009 23:43:16
===============================================================================

If a failure occurs in the ring-node, the IB-RCC BFD session between PE-1 and PE-2 will go
down and the SAP on both PE-1 and PE-2 will be put in operational up state.

Advanced Configuration Guide

Page 1411

Configuration

Configuration Notes
RNCV (used for ring-node connectivity check) and BFD (used for ring control connection) can
either run on the same VLAN in the same IES or VPRN service or can run on different VLAN.
MCS for IGMP or DHCP states on a MC-ring requires ESM since the BSA nodes must know
which ring node a subscriber is connected to in case a ring failure occurs. The ring-node name is
returned through a Python script, a RADIUS server or through a local user database. This string
(int_dest_id) must match one of the ring nodes defined in the redundancy configuration.
Convergence time after a ring failure should be 3 * BFD timer + MCS convergence time.
Convergence time after a BSA failure should be likewise.
Note that a debounce timer runs on the MC-ring peers. After a ring failure, the MC-ring converges
immediately (after the BFD session times out) and the debounce timer is started. After the ring is
fixed and the BFD session is up the MC-ring converges immediately again. If another ring failure
occurs before the debounce timer expires, convergence will be slowed down by two (2) seconds. If
a third ring failure occurs before the debounce timer expires, four second delays are introduced. In
case of a fourth failure, an eight second delay is introduced. 200 seconds of delay is the maximum.
The debounce timer can be configured under the MC-ring.

Page 1412

Advanced Configuration Guide

Multi-Chassis Ring Layer 2 with Enhanced Subscriber

Conclusion
This section covers an extension of dual homing support in TPSDA networks based on Layer 2
CO model. The extension addresses networks where multiple access nodes (for example,
DSLAMs) are connected in a single ring. The examples show the use of a ring with four access
nodes in a ring. The behavior is described in normal operation and in case a failure occurs in the
access ring.

Advanced Configuration Guide

Page 1413

Conclusion

Page 1414

Advanced Configuration Guide

Multi-Segment Pseudowire Routing

In This Chapter
This section describes advanced multi-segment pseudowire routing configurations.
Topics in this section include:

Applicability on page 1416

Summary on page 1417

Overview on page 1418

Configuration on page 1421

Conclusion on page 1467

Advanced Configuration Guide

Page 1415

Applicability

Applicability
This section is applicable to all of the 7750, 7450 and 7710 SR series and was tested on release
10.0R4. There are no specific pre-requisites for this configuration.

Page 1416

Advanced Configuration Guide

Multi-Segment Pseudowire Routing

Summary
Starting with SROS 9.0R3, the SR/ESS portfolio supports the use of Multi-Segment Pseudowire
(MS-PW) routing for Epipe services. MS-PW routing is described in draft-ietf-pwe3-dynamic-mspw, also known as Dynamic Placement of MS-PW and it is an extension of the procedures
proposed in RFC 6073 (static MS-PW) to enable multi-segment pseudowires to be dynamically
placed. Ultimately MS-PW Routing provides the capability of setting up MS-PWs without
provisioning the S-PE (Switching PEs).
This configuration note will go through the configuration process required to setup MS-PW
routing and will provide two configuration examples typically deployed in Service Providers: MSPW within the same Autonomous System (AS) and MS-PW across two different AS. Different
configuration options are tested and described in each example.

Advanced Configuration Guide

Page 1417

Overview

Overview
From a data plane perspective, MS-PW Routing does not introduce any changes with respect to
the existing MS-PW architecture. However from the control plane perspective, MS-PW Routing
brings a new information model and set of procedures to set up a MS-PW. These are the building
blocks defined by the MS-PW Routing feature:

A new information model is introduced for dynamic MS-PW based on the FEC129,
Attachment Individual Identifier (AII) Type 2. Note that static MS-PW uses FEC128
while VPLS with BGP-AD uses FEC129, but with AII Type 1 instead.
FEC129 is suitable for applications where the local PE with a SAII (Source
Attachment Individual Identifier) must automatically learn the remote TAII (Target
Attachment Individual Identifier), normally through BGP, before launching the LDP
mapping message for the pseudowire setup. The following figure shows the FEC129
structure:

G.Pwid
(0x81)
AGI Type

C Pw Type Pw Info Length


Length

Value

AGI Value (Cont.)


All Type

Length

Value

SAII Value (Cont.)


All Type

Length

Value

TAII Value (Cont.)


ACG0004A

Figure 124: FEC129 Structure

The Attachment Group Identifier (AGI) is not used in dynamic MS-PW signaling. In
VPLS, it typically carries the instance identifier. It is zero in dynamic MS-PWs.
The SAII and TAII (or pseudowire end-point identifiers) are encoded in FEC129 and
can have two different formats: AII Type 1 or AII Type 2.

Page 1418

AII Type 1 is composed of a fixed 32-bit value unique on the local PE. This AII Type is
used by VPLS when BGP-AD is needed.

AII Type 2 is composed of GID:prefix:AC-ID (Global-ID:prefix:Attachment-Circuit-ID)


and allows summarization for scalability in large networks. The GID is normally derived
from the AS number, the prefix from the node system address and the AC-ID is the local
pseudowire end-point identifier. The combination of the three identifiers gives us a
globally unique 96-bit AII value. In general, the same global ID and prefix are assigned
for all ACs belonging to the same T-PE. This is not a strict requirement though.

Advanced Configuration Guide

Multi-Segment Pseudowire Routing

All Type=2

Length

Global ID

Global ID (Cont.)

Prefix

Prefix (Cont.)

AC ID

AC ID (Cont.)
ACG0004B

Figure 125: AII Type 2 Format

A MS-PW routing table must be built in all the T-PEs and S-PEs through one of the
following two mechanisms:
Multi-Protocol BGP (MP-BGP), using a new NLRI and a new SAFI (pseudowire
routing SAFI=6, with AFI=25 L2VPN). The FEC129 AII Type 2 global values are
mapped in the pseudowire routing NLRI and advertised by BGP. In the tested release,
SROS only supports an NLRI comprising a Length, RD, Global ID and 32-bit Prefix,
that is, the AC ID is not included in the advertised NLRI. The AC ID is not included
as indicated in the draft-ietf-pwe3-dynamic-ms-pw since the source T-PE knows by
provisioning the AC ID on the terminating T-PE to use in signaling. Hence, there is no
need to advertise a fully qualified 96 bit address on a per pseudowire Attachment
Circuit basis. Only the T-PE Global ID, Prefix, and prefix length needs to be
advertised as part of well known BGP procedures. This also minimizes the amount
of routing information that is advertised in BGP to only what is necessary to reach the
far-end T-PE.

Length
Route Distinguisher (8 bytes)
Global ID
Global ID

Prefix

Prefix

AC ID

AC ID
ACG0004C

Figure 126: Pseudowire Routing NLRI (the AC ID is always zero)

Static routes, configurable via CLI

Advanced Configuration Guide

Page 1419

Overview

Once the MS-PW routing table is populated, Targeted LDP (TLDP) will make use of it to
signal the MS-PW all the way from the originating T-PE to the terminating T-PE as well
as in the reverse direction. The following methods will be used:
At the originating T-PE1, a longest-match lookup will be performed in the pseudowire
routing table for the configured TAII. Based on the lookup outcome, a label mapping
message will be sent to the Next Signaling Hop (NSH).
At the intermediate S-PEs and terminating T-PE, a longest-match lookup between the
TAII Type 2 included in the TLDP signaling message and entries installed in the
pseudowire routing table will be performed.
Alternatively to the pseudowire routing table lookup, TLDP can also use explicit
routing, as per section 7.4.2 of draft-ietf-pwe3-dyn-ms-pw. If that is the case, a path
must be configured at the T-PEs. The originating T-PE will include an ERO (Explicit
Route Object) in the TLDP label mapping, containing all the S-PE hops specified in
the configured path. Each S-PE along the path will remove its own entry from the
ERO and will forward the label mapping message to the next hop.

The SROS, starting from R9.0R3, supports the information model and all the methods described
above:

Dynamic placement through MP-BGP, with the pseudowire routing NLRI

Static routes

Explicit paths

In addition to the above, the following features are supported on dynamic MS-PW:

Auto-configuration of spoke SDPs at T-PE (if enabled on a T-PE, there is no need for
configuring the TAII of the remote T-PE. Refer to Active/Passive Signaling and AutoConfiguration on page 1434. The auto-configuration is typically used in hub-and-spoke
scenarios. The TAII would only be configured on the spoke T-PE while the TAII would be
automatically provisioned on the hub T-PE if the auto-config parameter is added.

OAM using vccv-ping and vccv-trace

Pseudowire redundancy

Control word

Hash label (if the chassis dependency requirements are met)

Standby-signaling-master and standby-signaling-slave commands

Filters

1. The originating T-PE will be the T-PE initiating the MS-PW signaling. Refer to the Active/Passive
Signaling and Auto-Configuration section for further information.

Page 1420

Advanced Configuration Guide

Multi-Segment Pseudowire Routing

Configuration
The following flow-chart shows the configuration process to be followed when setting up MS-PW
routing. Base IGP and MPLS configuration is assumed to be in place before these configuration
tasks can be carried out.

Enable pw-routing and


configure spe-address
and local-prefixes

Build the PW routing table

Configure spoke-sdp-fecs

Strict Path

Preference
Order

Static Routes

MP-BGP
ACG0015

Figure 127: Configuration Flow Chart

The following subsections review these three steps, including all the options in detail.

Pseudowire Routing Enablement on page 1422

Building the Pseudowire Routing Table on page 1425

Spoke-SDP-FEC Timers on page 1436

Advanced Configuration Guide

Page 1421

Configuration

Pseudowire Routing Enablement


The first step in the configuration is to enable pw-routing and configure the required pw-routing
basic parameters: the spe-address (in S-PEs and T-PEs) and the local-prefix/prefixes (only
required in T-PEs). A new pw-routing context has been added from 9.0R3 onward. The following
CLI example shows the configuration of the spe-address and local-prefixes.
A:PE-1>config>service# info
---------------------------------------------pw-routing
spe-address 65536:192.0.2.1
local-prefix 65536:192.0.2.1 create
advertise-bgp route-distinguisher 65536:11 community 65535:11
advertise-bgp route-distinguisher 65536:12 community 65535:12
exit
local-prefix 65536:192.0.2.11 create
advertise-bgp route-distinguisher 65536:11 community 65535:11
exit
exit

In order to enable support for MS-PW routing on a 7x50 node, a single, globally unique, S-PE ID
(known as the spe-address) is first configured under config>service>pw-routing on each 7x50 to
be used as a T-PE or S-PE. The S-PE address has the format global-id:prefix. It is not possible to
configure any local prefixes used for pseudowire routing or to configure spoke SDPs using
dynamic MS-PWs at a T-PE unless an S-PE address has already been configured. The S-PE
address is used as the address of a node when populating the switching point TLV in the LDP label
mapping message and the pseudowire status notification sent for faults at an S-PE. The following
CLI output shows the spe-address configuration format:
A:PE-1# configure service pw-routing spe-address
- no spe-address
- spe-address <global-id:prefix>
<global-id:prefix>

: <global-id>:{<prefix>|<ipaddress>}
global-id - [1..4294967295]
prefix
- [1..4294967295]
ipaddress - a.b.c.d

Where:

<global-id> is normally the 2 or 4-byte ASN identifying the network (although nothing
prevents the operator from configuring any value here)

<prefix> is normally the nodes system address (although any value in ip address or
decimal format can be used)

If an S-PE is capable of Dynamic MS-PW signaling, but is not assigned with an S-PE address,
then on receiving a Dynamic MS-PW label mapping message the S-PE will return a Label Release
with the "LDP_RESOURCES_UNAVAILABLE" (0x38)" status code. Note that the S-PE address

Page 1422

Advanced Configuration Guide

Multi-Segment Pseudowire Routing

cannot be changed unless the dynamic MS-PW configuration is completely removed; therefore it
is recommended to configure the spe-address carefully and keep it for the life of the services.
The second basic pw-routing context parameter is the local-prefix:
A:PE-1# configure service pw-routing local-prefix
- local-prefix <local-prefix> [create]
- no local-prefix <local-prefix>
<local-prefix>

: <global-id>:<ip-addr>|<raw-prefix>
ip-addr
- a.b.c.d
raw-prefix
- [1..4294967295]
global-id
- [1..4294967295]

[no] advertise-bgp

- Configure BGP advertisement

One or more local (Layer 2) prefixes (up to a maximum of 16), which are formatted in the style of
<global-id>:<ipv4-address>, are supported. A local prefix identifies a T-PE in the pseudowire
routing domain. When using explicit paths or static-routes, the definition of the local-prefix (or
local-prefixes) without any further attribute is enough. However, when BGP is used, the advertisebgp parameter along with a route-distinguisher (RD) value and an optional BGP community is
required.
A:PE-1# configure service pw-routing local-prefix 65536:192.0.2.1 advertise-bgp
- advertise-bgp route-distinguisher <rd> [community <community>]
- no advertise-bgp route-distinguisher <rd>
<rd>

<community>

:<ip-addr:comm-val>|<2byte-asnumber:ext-comm-val>|
<4byte-asnumber:comm-val>
ip-addr
- a.b.c.d
comm-val
- [0..65535]
2byte-asnumber - [1..65535]
ext-comm-val
- [0..4294967295]
4byte-asnumber - [1..4294967295]
: <asnumber:comm-val>
asnumber - [1..65535]
comm-val - [0..65535]

Up to four unique RDs (and communities) can be configured per each local-prefix. Different RDs
for the same prefix allow the operator to advertise the same prefix coming from up to four
different next-signaling hops (NSH). Route-Reflectors would reflect the four routes in that case,
whereas only one would be reflected should the same RD be used.
*A:PE1>config>service>pw-routing>local-prefix# info
---------------------------------------------advertise-bgp route-distinguisher 400:20
advertise-bgp route-distinguisher 500:3
advertise-bgp route-distinguisher 600:300
advertise-bgp route-distinguisher 700:100
---------------------------------------------*A:PE1>config>service>pw-routing>local-prefix# advertise-bgp route-distinguisher 800:200
MINOR: SVCMGR #6072 Maximum number of RD's has been reached

Advanced Configuration Guide

Page 1423

Configuration

For each local prefix, BGP then advertises each global ID/prefix tuple and unique RD and
community (if configured) using the MS-PW NLRI, based on the aggregated FEC129 AII Type 2
and the Layer 2 VPN/PW routing AFI/SAFI 25/6, to each BGP neighbor, subject to local BGP
policies.

Page 1424

Advanced Configuration Guide

Multi-Segment Pseudowire Routing

Building the Pseudowire Routing Table


Once the spe-address and the local-prefix(es) have been configured and before configuring the
Epipe service itself on the T-PE nodes, we need to populate the pseudowire routing table in all the
participating T-PE and S-PE nodes, so that TLDP knows what the Next Signaling Hop (NSH) is
and sends LDP Label Mapping messages.
The pseudowire routing table will be populated with local prefixes, static-routes and BGP routes,
where the static-routes have preference over the BGP-learned routes. The pseudowire routing
table can be overridden by the explicit paths, should the operator want to configure them.
Therefore, when TLDP signals an LDP Label Mapping for a given TAII, it will:

First check if there is an explicit path configured for that spoke-sdp-fec.

Otherwise it will look up the TAII prefix into the pseudowire routing table, where static
routes take precedence over BGP routes.

An aggregation scheme, similar to that used for classless IPv4 addresses, can be employed in the
pseudowire routing table, where a longest match is used to find a route. Except for the default
pseudowire route, which is encoded with a 0 mask, masks included in the pw-routing table are:

/64 for regular prefixes, including a global-id and prefix (as previously mentioned, note
that the AC-ID is not included in the BGP NLRI).

/96 for local prefixes, including the AC-ID, as well as global-id and prefix.

Each S-PE and T-PE must have a pseudowire routing table that contains a reference to the TLDP
session to use to signal to a set of next hop S-PEs to reach a given T-PE (or the T-PE if that is the
next hop). For VLLs, this table contains aggregated AII Type 2 FECs and may be populated with
routes that are learned through MP-BGP or that are statically configured.

Advanced Configuration Guide

Page 1425

Configuration

Explicit Paths
A set of default explicit routes to a remote T-PE prefix may be configured on a T-PE under
config>services>pw-routing using the path name command. Explicit paths are used to populate
the explicit route TLV used by MS-PW TLDP signaling. Only strict (fully qualified) explicit paths
are supported. Note that it is possible to configure explicit paths independently of the
configuration of BGP or static routing.
The following CLI excerpt shows an explicit path example for a MS-PW following the PE-1-PE3-PE-5-PE-2 path (see the diagram in Figure 128). The IP addresses are the system addresses of
all the S-PE and T-PE along the path (except for PE-1).
A:PE-1>config>service>pw-routing>path# info
---------------------------------------------hop 1 192.0.2.3
hop 2 192.0.2.5
hop 3 192.0.2.2
no shutdown
----------------------------------------------

Static Routes
In addition to support for BGP routing, static MS-PW routes may also be configured using the
config>services>pw-routing>static-route command. Each static route comprises of the target TPE Global-ID and prefix, and the IP address of the TLDP session to the next hop S-PE or T-PE
that should be used:
A:PE-1# configure service pw-routing static-route
- no static-route <route-name>
- static-route <route-name>
<route-name>

: <global-id>:<prefix>:<next-hop-ip_addr>
global-id
- 0..4294967295
prefix
- a.b.c.d|0..4294967295
ip_addr
- a.b.c.d

If a static route <global-id>:<prefix> is set to 0, then this represents the default route.
A:PE-1>config>service>pw-routing# info
---------------------------------------------...
static-route 0:0.0.0.0:192.0.2.3
static-route 0:0.0.0.0:192.0.2.4
...

Page 1426

Advanced Configuration Guide

Multi-Segment Pseudowire Routing

Note that, even though you can configure several default-routes, only one default route is added to
the pseudowire routing table. The following command shows the pseudowire routing table content
where only one default route (out of the two previously configured ones) is added. The default
route added to the pseudowire routing table is the first valid route added to the configuration.
A:PE-1# show service pw-routing route-table all-routes
===============================================================================
Service PW L2 Routing Information
===============================================================================
AII-Type2/Prefix-Len
Next-Hop
Owner Age
Route-Distinguisher
Community
Best
------------------------------------------------------------------------------0:0.0.0.0:0/0
192.0.2.3
static 19h11m57s
0:0
0:0
yes
...

If a static route exists to a given T-PE, then this is used in preference to any BGP route that may
exist.

Advanced Configuration Guide

Page 1427

Configuration

BGP Routes
As already mentioned, the dynamic advertisement of the pseudowire routes is enabled for each
prefix and RD using the advertise-bgp command in the config>services>pw-routing>localprefix context. Note that a BGP export policy is also required in order to export MS-PW routes in
MP-BGP. This can be done using a default policy matching all the MS-PW routes, such as the
following:
A:PE-1>config>router>policy-options# info
---------------------------------------------policy-statement "export_ms-pw"
entry 10
from
family ms-pw
exit
action accept
exit
exit
exit
A:PE-1>config>router>bgp# info
---------------------------------------------group "region"
family ms-pw
type internal
export "export_ms-pw"
neighbor 192.0.2.3
exit
neighbor 192.0.2.4
exit
exit
no shutdown
----------------------------------------------

MS-PW routes advertised/received can be debugged and shown on the log sessions (debug router
bgp update). Note that a new address family and NLRI are used to distribute the MS-PW
prefixes:
49 2004/11/03 01:21:23.41 UTC MINOR: DEBUG #2001 Base Peer 1: 192.0.2.4
"Peer 1: 192.0.2.4: UPDATE
Peer 1: 192.0.2.4 - Send BGP UPDATE:
Withdrawn Length = 0
Total Path Attr Length = 51
Flag: 0x40 Type: 1 Len: 1 Origin: 2
Flag: 0x40 Type: 2 Len: 0 AS Path:
Flag: 0x40 Type: 5 Len: 4 Local Preference: 100
Flag: 0xc0 Type: 8 Len: 4 Community:
65535:12
Flag: 0x90 Type: 14 Len: 26 Multiprotocol Reachable NLRI:
Address Family MSPW
NextHop len 4 NextHop 192.0.2.1
[MSPW] rd: 65536:12, global-id 65536, prefix 192.0.2.1,ac-id 0, preflen 128"

Page 1428

Advanced Configuration Guide

Multi-Segment Pseudowire Routing

MS-PW BGP routes can also be displayed in the pseudowire routing table along with the staticroutes and the local-prefixes.
*A:PE-1# show service pw-routing route-table
===============================================================================
Service PW L2 Routing Information
===============================================================================
AII-Type2/Prefix-Len
Next-Hop
Owner Age
Route-Distinguisher
Community
Best
------------------------------------------------------------------------------0:0.0.0.0:0/0
192.0.2.3
static 19h32m08s
0:0
0:0
yes
65536:192.0.2.1:0/64
192.0.2.1
local 01d17h56m
0:0
0:0
yes
65536:192.0.2.1:0/64
192.0.2.1
local 01d17h56m
65536:11
65535:11
yes
65536:192.0.2.1:0/64
192.0.2.1
local 01d17h56m
65536:12
65535:12
yes
65536:192.0.2.2:0/64
192.0.2.4
bgp
01d15h11m
65536:22
65535:12
yes
65536:192.0.2.11:0/64
192.0.2.1
local 01d13h02m
0:0
0:0
yes
65536:192.0.2.11:0/64
192.0.2.1
local 01d13h02m
65536:11
65535:11
yes
65536:192.0.2.12:0/64
192.0.2.1
local 01d12h57m
0:0
0:0
yes
65536:192.0.2.12:0/64
192.0.2.1
local 01d12h56m
65536:12
65535:12
yes
65536:192.0.2.13:0/64
192.0.2.1
local 19h39m31s
0:0
0:0
yes
65536:192.0.2.14:0/64
192.0.2.1
local 19h39m13s
0:0
0:0
yes
65536:192.0.2.21:0/64
192.0.2.3
bgp
01d12h59m
65536:21
65535:11
yes
65536:192.0.2.22:0/64
192.0.2.4
bgp
01d12h56m
65536:22
65535:12
yes
65536:192.0.2.23:0/64
192.0.2.3
static 19h06m21s
0:0
0:0
yes
65536:192.0.2.24:0/64
192.0.2.4
static 19h06m13s
0:0
0:0
yes
------------------------------------------------------------------------------Entries found: 15
===============================================================================

It is important to note that if there are two (or more) equal cost BGP MS-PW routes with identical
<global-ID:prefix> and different RDs in the RIB they are both tagged as best/used and both will
be added to the pseudowire routing table, however only the one with a higher RD will be shown as
Best and as a result of that, only that one will be used by TLDP for the NSH. The following CLI
output shows an example of two equal cost MS-PW routes. The route 65536:192.0.2.2 with RD
65536:21 and RD 65536:22 are tagged as best/used (u*>):
*A:PE-1# show router bgp routes ms-pw aii-type2 65536:192.0.2.2:0
===============================================================================
BGP Router ID:192.0.2.1
AS:65536
Local AS:65536
===============================================================================

Advanced Configuration Guide

Page 1429

Configuration

Legend Status codes : u - used, s - suppressed, h - history, d - decayed, * - valid


Origin codes : i - IGP, e - EGP, ? - incomplete, > - best, b - backup
===============================================================================
BGP MSPW Routes
===============================================================================
Flag Network
RD
Nexthop
AII-Type2/Preflen
As-Path
------------------------------------------------------------------------------u*>? 65536:192.0.2.2
65536:21
192.0.2.3
65536:192.0.2.2:0/64
No As-Path
*?
65536:192.0.2.2
65536:21
192.0.2.4
65536:192.0.2.2:0/64
No As-Path
u*>? 65536:192.0.2.2
65536:22
192.0.2.4
65536:192.0.2.2:0/64
No As-Path
*?
65536:192.0.2.2
65536:22
192.0.2.3
65536:192.0.2.2:0/64
No As-Path
------------------------------------------------------------------------------Routes : 4
===============================================================================

However, only the one with RD 65536:22 (higher RD) is added as Best to the pseudowire
routing table and TLDP will use 192.0.2.4 as the NSH:
*A:PE-1# show service pw-routing route-table all-routes
===============================================================================
Service PW L2 Routing Information
===============================================================================
AII-Type2/Prefix-Len
Next-Hop
Owner Age
Route-Distinguisher
Community
Best
------------------------------------------------------------------------------...
65536:192.0.2.2:0/64
192.0.2.3
bgp
01d15h21m
65536:21
65535:11
no
65536:192.0.2.2:0/64
192.0.2.4
bgp
01d15h21m
65536:22
65535:12
yes
...

How does the 7x50 SR/ESS TLDP process select the NSH (Next-Signaling Hop) for two identical
<global-ID:prefix/RD> tuples?
In case the originating T-PE or any intermediate S-PE receives two (or more) equal cost MS-PW
routes with the same RD but from different Next-Hops, all the MS-PW routes will be added to the
MS-PW routing table. The following output shows two MS-PW routes with the same <globalID:prefix/RD> but different NH. Both are added to the MS-PW routing table as Best.
*A:PE-1# show service pw-routing route-table all-routes
===============================================================================
Service PW L2 Routing Information
===============================================================================

Page 1430

Advanced Configuration Guide

Multi-Segment Pseudowire Routing

AII-Type2/Prefix-Len
Next-Hop
Owner Age
Route-Distinguisher
Community
Best
------------------------------------------------------------------------------...
65536:192.0.2.2:0/64
192.0.2.3
bgp
01d15h21m
65536:21
65535:21
yes
65536:192.0.2.2:0/64
192.0.2.4
bgp
01d15h21m
65536:21
65535:21
yes
...

If that is the case, TLDP will pick up the NSH out of an ECMP hashing algorithm applied to the
<global-ID:prefix:AC-ID> for the SAII and the TAII of the pseudowires pointing at the same
prefix. The output of that hashing algorithm will determine what the NSH will be for a given
spoke-sdp-fec.
When path diversity for an active and a standby pseudowire (hot standby pseudowire redundancy)
is desired and the two pseudowires of the same Epipe end-point are pointing at the same remote
<global-ID:prefix> coming from two different NHs, the operator has to make sure TLDP chooses
a different NSH for the standby pseudowire. Only in that case hot standby pseudowire redundancy
can be achieved. As a rule of thumb, if the SAII/TAII of the active and standby pseudowires are
separated by 16 or more AC-ID values, TLDP will select a different NSH for both pseudowires.
For example:

Given the following SAII/TAII AC-ID values for the active/standby pseudowires on the
originating T-PE, TLDP will select the same NSH:
Active pseudowire: saii-type2 65536:192.0.2.1:1, taii-type2 65536:192.0.2.2:1
Standby pseudowire: saii-type2 65536:192.0.2.1:2, taii-type2
65536:192.0.2.2:2

However, the following SAII/TAII AC-ID values for the active/standby pseudowires on
the originating T-PE will allow the ECMP hashing algorithm to make TLDP select
different NSHs for the active and the standby pseudowires:
Active pseudowire: saii-type2 65536:192.0.2.1:1, taii-type2 65536:192.0.2.2:1
Standby pseudowire: saii-type2 65536:192.0.2.1:16, taii-type2
65536:192.0.2.2:16

Other AC-ID values greater than 16 (for the standby pseudowire) would also have achieved next
hop diversity.

Advanced Configuration Guide

Page 1431

Configuration

Configuring Dynamic Pseudowires on the T-PEs


Before any LDP signaling can take place, note that T-LDP sessions must be explicitly configured
on T-PEs and S-PEs.
One or more spoke-SDPs may be configured for distributed Epipe VLL services. Dynamic MSPWs use FEC129 (also known as the Generalized ID FEC) with Attachment Individual Identifier
(AII) Type 2 to identify the pseudowire, as opposed to FEC128 (also known as the PW ID FEC)
used for traditional single segment pseudowires and for pseudowire switching. FEC129 spokeSDPs are configured under the spoke-sdp-fec command in the CLI. Note that spoke-sdp-fecs (or
FEC129 spoke-SDPs) are by default fec-type 129 and aii-type 2 (those are the only values
supported for spoke-sdp-fecs in the release 10.0R4). Spoke-sdp-fecs can be part of an endpoint
and even an ICB (Inter-Chassis Backup) pseudowire.
*A:PE-1>config>service>epipe# spoke-sdp-fec
- no spoke-sdp-fec <spoke-sdp-fec-id>
- spoke-sdp-fec <spoke-sdp-fec-id> [fec <fec-type>] [aii-type <aii-type>] [create]
- spoke-sdp-fec <spoke-sdp-fec-id> no-endpoint
- spoke-sdp-fec <spoke-sdp-fec-id> [fec <fec-type>] [aii-type <aii-type>] [create] endpoint <name> [icb]
<spoke-sdp-fec-id>
<fec-type>
<aii-type>
<name>
<icb>

:
:
:
:
:

[1..4294967295]
[129..130]
[1..2]
[32 chars max]
keyword - configure spoke-sdp as inter-chassis backup

FEC129 AII Type 2 uses a Source Attachment Individual Identifier (SAII) and a Target
Attachment Individual Identifier (TAII) to identify the ends of a pseudowire at the T-PE. The SAII
identifies the local end, while the TAII identifies the remote end. The SAII and TAII are each
structured as follows:

Page 1432

Global-ID: this is a 4 byte identifier that uniquely identifies an operator or the local
network. Normally this matches the ASN

Prefix: a 4-byte prefix, which should correspond to one of the local prefixes assigned
under pw-routing

AC-ID: a 4-byte identifier for this end of the pseudowire. This should be locally unique
within the scope of the global-id:prefix

Advanced Configuration Guide

Multi-Segment Pseudowire Routing

In terms of the SDP tunnel being used by each spoke-sdp-fec, pw-routing chooses the MS-PW
path in terms of the sequence of S-PEs to use to reach a given T-PE. It does not select the SDP to
use on each hop, which is instead determined at signaling time. When a label mapping is sent for a
given pseudowire segment, an LDP SDP will be used to reach the next-hop S-PE/T-PE if such an
SDP exists. If not, and an RFC 3107 labeled BGP SDP is available, then that will be used2.
Otherwise, the label mapping will fail and a label release will be sent.
The following CLI output shows one example of two spoke-sdp-fecs belonging to an endpoint:
*A:PE-1>config>service>epipe# info
---------------------------------------------description "ms-pw epipe with bgp - using 2 prefixes"
endpoint "CORE" create
description "end-point for epipe A/S PW redundancy"
revert-time 10
standby-signaling-master
exit
sap ccag-1.b:2 create
exit
spoke-sdp-fec 21 fec 129 aii-type 2 create endpoint CORE
precedence primary
pw-template-bind 1
saii-type2 65536:192.0.2.11:1
taii-type2 65536:192.0.2.21:1
no shutdown
exit
spoke-sdp-fec 22 fec 129 aii-type 2 create endpoint CORE
pw-template-bind 1
saii-type2 65536:192.0.2.12:1
taii-type2 65536:192.0.2.22:1
no shutdown
exit
no shutdown
----------------------------------------------

These are all of the options available under the spoke-sdp-fec context:
*A:PE-1# configure service epipe 1 spoke-sdp-fec
- no spoke-sdp-fec <spoke-sdp-fec-id>
- spoke-sdp-fec <spoke-sdp-fec-id> [fec <fec-type>] [aii-type <aii-type>] [create]
- spoke-sdp-fec <spoke-sdp-fec-id> no-endpoint
- spoke-sdp-fec <spoke-sdp-fec-id> [fec <fec-type>] [aii-type <aii-type>] [create] endpoint <name> [icb]
<spoke-sdp-fec-id>
<fec-type>
<aii-type>
<name>
<icb>

:
:
:
:
:

[1..4294967295]
[129..130]
[1..2]
[32 chars max]
keyword - configure spoke-sdp as inter-chassis backup

2. Note that RSVP SDPs might be picked at the T-PE through the use of pw-template <policy-id> [useprovisioned-sdp], however there is no way to select an RSVP SDP on an S-PE.

Advanced Configuration Guide

Page 1433

Configuration

[no] auto-config
- Configure auto-configuration
[no] path
- Configure path-name
[no] precedence
- Configure precedence
[no] pw-template-bi* - Configure Pseudo-Wire template-binding policy
[no] retry-count
- Configure retry count
[no] retry-timer
- Configure retry timer
[no] saii-type2
- Configure Source Attachment Individual Identifier (SAII)
[no] shutdown
- Administratively enable/disable the spoke SDP FEC binding
signaling
- Configure Spoke-SDP FEC signaling
[no] standby-signal* - Enable PW standby-signaling slave
[no] taii-type2
- Configure Target Attachment Individual Identifier (TAII)

Active/Passive Signaling and Auto-Configuration


When an MS-PW is signaled, each T-PE might independently initiate signaling of the MS-PW.
This could result in a different path being used in each direction of the pseudowire. To avoid this
situation one of the T-PE will start the pseudowire signaling (active role), while the other T-PE
waits to receive the LDP label mapping message before sending the LDP label mapping message
for the reverse direction of the pseudowire (passive role).
By default, the T-PE with SAII>TAII will have the active role and will send the label mapping
first:
*A:PE2>config>service>epipe# spoke-sdp-fec 21 shutdown
*A:PE2>config>service>epipe# info
---------------------------------------------spoke-sdp-fec 21 fec 129 aii-type 2 create
saii-type2 65536:192.0.2.21:1
taii-type2 65536:192.0.2.11:1
exit
no shutdown
---------------------------------------------*A:PE2>config>service>epipe# spoke-sdp-fec 21 no shutdown
49 2011/07/28 02:50:59.88 UTC MINOR: DEBUG #2001 Base LDP
"LDP: LDP
Send Label Mapping packet (msgId 26) to 192.0.2.3:0
50 2011/07/28 02:50:59.97 UTC MINOR: DEBUG #2001 Base LDP
"LDP: LDP
Recv Label Mapping packet (msgId 30) from 192.0.2.3:0

This default behavior can be modified by the signaling command. When set to master, the T-PE
will send a label mapping message regardless of the SAII and TAII. By default the parameter is set
to auto (which means the T-PE will trigger label mapping if SAII>TAII).
*A:PE-1# configure service epipe 1 spoke-sdp-fec 21 signaling
- signaling <signaling>
<signaling>

Page 1434

: auto|master

Advanced Configuration Guide

Multi-Segment Pseudowire Routing

The MS-PW routing implementation on the 7x50 supports single-sided auto-provisioning. This
allows it to have hub T-PEs where the TAII is not required to be configured and as such
simplifies the provisioning. In this case, the spoke T-PE PWs would be configured with specific
SAII and TAII as well as signaling master, whereas the hub T-PE PWs would be configured with
only the SAII and the auto-config parameter. When the auto-config attribute is set for a spoke-sdpfec, the T-PE always passively waits for the label mapping to be received before issuing a label
mapping message (since it does not know the TAII beforehand). This is a CLI example for a hub
T-PE spoke-sdp-fec:
*A:PE2>config>service>epipe# info
---------------------------------------------spoke-sdp-fec 21 fec 129 aii-type 2 create
auto-config
saii-type2 65536:192.0.2.21:1
exit
no shutdown
----------------------------------------------

Advanced Configuration Guide

Page 1435

Configuration

Spoke-SDP-FEC Timers
MS-PW routing provides a few timers that can be configured at the global pw-routing level or at
each specific spoke-sdp-fec level:
*A:PE1>config>service>pw-routing# info
------------------------------------------boot-timer 20
retry-timer 40
retry-count 50
*A:PE1>config>service>epipe# info
-------------------------------------------spoke-sdp-fec 3 fec 129 aii-type 2 create
retry-timer 10
retry-count 10

Where:

Boot-timer (the default is 10 seconds with values 0 600 seconds allowed): Configures a
hold-off timer for MS-PW routing advertisements and signaling that is used at boot time.
This timer helps to make sure all the network infrastructure is up and running before
setting up the PWs.

Retry-timer (the default is 30 seconds with values 10 480 seconds allowed): The
exponential back-off timer that determines the interval between consecutive retries to reestablish a spoke-SDP. The configured value gives the initial retry time. The attempt fails
if a label withdrawal is received. If configured at global and spoke-sdp-fec level, the latter
overrides the value set by the global settings.

Retry-count (the default 30 with values 10 10000): Specifies the number of attempts
the system should make to re-establish the spoke-SDP after it has failed. After each
successful attempt, the counter is reset to zero. When the specified number is reached, no
more attempts are made and the spoke-sdp is put into the shutdown state. Use the no
shutdown command to bring up the path after the retry limit is exceeded. It is present at
the pw-routing level as well as the spoke-SDP level. If configured at global and spokesdp-fec level, the latter overrides the value set by the global settings.

The usual endpoint level timers are also available for MS-PW routing:
Revert-time <time-value|infinite> (default is 0, values 0-600 sec): configures the time
to wait before reverting to the primary spoke-sdp-fec.
Active-hold-delay (the default is 0, values 0 60 deci-seconds): It specifies that the
node will delay sending the T-LDP status bits for VLL endpoint when the MC-LAG
transitions the LAG subgroup which hosts the SAP from active to standby (MC-Ring
or MC-APS are supported too) or when any object in the endpoint, i.e. SAP, ICB, or
regular spoke SDP, transitions from up to down operational state. The active-holddelay range starts from 1 (in units of deci-sec) via CLI, and the only way to get the
default value of zero is to use the no active-hold-delay command

Page 1436

Advanced Configuration Guide

Multi-Segment Pseudowire Routing

Standby Signaling
Just as with a regular endpoint with regular spoke-sdps, there can also be standby-signalingmaster and standby-signaling-slave parameters for spoke-sdp-fecs.
The standby-signaling-master command is configured under the end-point context and makes sure
that standby signaling (TLDP pseudowire status bits 0x20) is sent for the selected standby
pseudowire. It cannot be set if SAPs have been configured at the end-point (for MC-LAG/Ring/
APS or ICB).
*A:PE1>config>service>epipe>endpoint# info
---------------------------------------------standby-signaling-master
*A:PE1>config>service>epipe>endpoint# standby-signaling-master
MINOR: SVCMGR #3805 The command is not allowed in an endpoint with sap

The standby-signaling-slave can be configured at endpoint or spoke-sdp-fec level (if the spokesdp-fec is not part of an endpoint) but never on both at the same time:
*A:PE1>config>service>epipe>endpoint# info
---------------------------------------------standby-signaling-slave
*A:PE1>config>service>epipe>spoke-sdp-fec# standby-signaling-slave
MINOR: SVCMGR #2031 Sdp-bind is in an explicit endpoint
*A:PE1>config>service>epipe# info
---------------------------------------------sap 1/1/3:3 create
exit
spoke-sdp-fec 11 fec 129 aii-type 2 create
standby-signaling-slave

When this parameter is configured, the node will block the transmit forwarding direction of a
spoke SDP based on the pseudowire standby bit received from a TLDP peer.

Advanced Configuration Guide

Page 1437

Configuration

Spoke-SDP-FEC Templates and Filters


PW-templates are the way to configure the control word for this type of pseudowire as well as
ingress/egress filters (ipv4/mac/ipv6). In regards to filters, it is important to note that they are only
supported on the T-PEs, since there is no provisioning of a pw-template (or Epipe at all) on the SPEs.
*A:PE1# configure service pw-template 1
*A:PE1>config>service>pw-template# info
---------------------------------------------controlword
egress
filter ip 1
exit
*A:PE1>config>service>epipe# info
-----------------------------------------------snip-spoke-sdp-fec 11 fec 129 aii-type 2 create endpoint CORE
pw-template-bind 1

Note that pw-template changes (just like for VPLS with BGP-AD or BGP-VPLS) are not
automatically propagated. A tools perform command is provided to evaluate and distribute the
changes at the service level to one or all the services that use that template (if the service ID is
omitted, then all the services will be updated).
*A:PE1# tools perform service id 6 eval-pw-template 1 allow-service-impact

Intra-AS MS-PW Routing


This section provides a configuration example for an intra-AS scenario. The following network
setup will be used for this section.

Page 1438

Advanced Configuration Guide

Multi-Segment Pseudowire Routing

192.0.2.7

P-1

192.0.2.8

P-2

BGP RR

ISIS L2

192.0.2.3

192.0.2.4

PE-3

PE-4

PE-5

192.0.2.5

PE-6

192.0.2.6

BGP RR
NH Self
ISIS L1

192.0.2.1

PE-1

PE-2

192.0.2.2

BGP
1/1/3

1/1/3

CE-1
172.16.0.1

CE-2
172.16.0.2
ACG0008

Figure 128: Intra-AS MS-PW Network Topology

Multiple MS-PW routing Epipes are configured between PE-1 and PE-2, with PE-3, PE-4, PE-5
and PE-6 being S-PE routers. P-1 and P-2 will be pure P routers from a data plane perspective.
All the PEs are pre-configured with ISIS as the IGP, as shown in the figure: PE-1 and PE-2 are
level-1 routers, P-1 and P-2 are level-2 only routers and the rest of the routers are level-1/level-2.
Link level LDP is also pre-configured on all the network interfaces and targeted LDP is
configured between PE-1 and PE-3/PE-4, between PE-2 and PE-5/PE-6 and among PE-3, PE-4,
PE-5 and PE-6. There is no targeted LDP sessions configured on P-1 and P-2.
As outlined in Figure 127, the configuration is a three-step process where the pw-routing context
is configured first, then the required configuration so that routing tables get populated accordingly
and finally the services themselves.

Advanced Configuration Guide

Page 1439

Configuration

MS-PW using BGP Routing


In this sub-section, Epipe 2 will be configured between PE-1 and PE-2, where TLDP will use the
BGP routes populated in the MS-PW routing table to signal the MS-PW.
The first step is the provisioning of the pw-routing context on all the T-PEs and S-PEs. The speaddress will be configured on all the T-PEs and S-PEs (that is, all the routers except for P-1 and P2) using the ASN as the global-id and the system address as the prefix. On PE-1 and PE-2 (only)
we will configure the prefixes used for setting up Epipe 2. Note that two prefixes are configured
per T-PE so that pseudowire redundancy with path diversity for the standby pseudowire can be
carried out. The spe-address and local-prefixes for the T-PEs are shown below. Note that the
advertise-bgp parameter is required since we are using BGP here.
*A:PE-1>config>service>pw-routing# info
---------------------------------------------spe-address 65536:192.0.2.1
local-prefix 65536:192.0.2.11 create
advertise-bgp route-distinguisher 65536:11 community 65535:11
exit
local-prefix 65536:192.0.2.12 create
advertise-bgp route-distinguisher 65536:12 community 65535:12
exit
*A:PE-2>config>service>pw-routing# info
---------------------------------------------spe-address 65536:192.0.2.2
local-prefix 65536:192.0.2.21 create
advertise-bgp route-distinguisher 65536:21 community 65535:11
exit
local-prefix 65536:192.0.2.22 create
advertise-bgp route-distinguisher 65536:22 community 65535:12
exit

The second step is the configuration of BGP.


As depicted in Figure 128, BGP is enabled in all the routers. Note that the middle routers (PE-3,
PE-4 and PE-5, PE-6) are BGP route-reflectors for PE-1 and PE-2 and they reflect MS-PW routes
while changing the next-hop to their own system address. This is required so that TLDP knows
where to send the label mapping message for a particular prefix. P-1 and P-2 are regular RRs
reflecting routes among all the S-PEs. The BGP configuration of PE-1, PE-3, PE-4 and a P-1 is
shown below. Similar commands are configured on the other PEs depending on their T-PE, S-PE
or RR function.

Page 1440

Advanced Configuration Guide

Multi-Segment Pseudowire Routing

The T-PEs have dual-homed BGP sessions to the S-PEs. Example for PE-1:
*A:PE-1>config>router>bgp# info
---------------------------------------------enable-peer-tracking
rapid-withdrawal
group "region"
family ms-pw
type internal
export "export_ms-pw"
neighbor 192.0.2.3
exit
neighbor 192.0.2.4
exit
exit
no shutdown
---------------------------------------------*A:PE-1>config>router>bgp# show router policy "export_ms-pw"
entry 10
from
family ms-pw
exit
action accept
exit
exit

The S-PEs are reflecting routes and also changing the NH and Local Preference based on the
communities accordingly, so that pseudowire diversity can be ensured.
A:PE-3>config>router>bgp# info
---------------------------------------------rapid-withdrawal
group "core"
family ms-pw
type internal
export "export_ms-pw_ABR-to-core"
neighbor 192.0.2.7
exit
neighbor 192.0.2.8
exit
exit
group "region"
family ms-pw
type internal
enable-peer-tracking
cluster 3.3.3.3
export "export_ms-pw_ABR-to-region"
neighbor 192.0.2.1
exit
exit
no shutdown
---------------------------------------------A:PE-3>config>router>bgp# show router policy "export_ms-pw_ABR-to-core"
entry 10
from
protocol bgp
community "65535:11"

Advanced Configuration Guide

Page 1441

Configuration

family ms-pw
exit
action accept
local-preference 150
next-hop-self
exit
exit
entry 20
from
protocol bgp
community "65535:12"
family ms-pw
exit
action accept
local-preference 100
next-hop-self
exit
exit
A:PE-3>config>router>bgp# show router policy "export_ms-pw_ABR-to-region"
entry 10
from
protocol bgp
community "65535:11"
family ms-pw
exit
action accept
local-preference 150
next-hop-self
exit
exit
entry 20
from
protocol bgp
community "65535:12"
family ms-pw
exit
action accept
local-preference 100
next-hop-self
exit
exit

The second S-PE to which PE-1 is connected has the following BGP configuration:
A:PE-4>config>router>bgp# info
---------------------------------------------enable-peer-tracking
rapid-withdrawal
group "core"
family ms-pw
type internal
export "export_ms-pw_ABR-to-core"
neighbor 192.0.2.7
exit
neighbor 192.0.2.8
exit
exit
group "region"

Page 1442

Advanced Configuration Guide

Multi-Segment Pseudowire Routing

family ms-pw
type internal
enable-peer-tracking
cluster 4.4.4.4
export "export_ms-pw_ABR-to-region"
neighbor 192.0.2.1
exit
exit
no shutdown
---------------------------------------------A:PE-4>config>router>bgp# show router policy "export_ms-pw_ABR-to-core"
entry 10
from
protocol bgp
community "65535:12"
family ms-pw
exit
action accept
local-preference 150
next-hop-self
exit
exit
entry 20
from
protocol bgp
community "65535:11"
family ms-pw
exit
action accept
local-preference 100
next-hop-self
exit
exit
A:PE-4>config>router>bgp# show router policy "export_ms-pw_ABR-to-region"
entry 10
from
protocol bgp
community "65535:12"
family ms-pw
exit
action accept
local-preference 150
next-hop-self
exit
exit
entry 20
from
protocol bgp
community "65535:11"
family ms-pw
exit
action accept
local-preference 100
next-hop-self
exit
exit

Advanced Configuration Guide

Page 1443

Configuration

Finally this is the BGP configuration for P-1, a pure RR.


A:P-1>config>router>bgp# info
---------------------------------------------enable-peer-tracking
rapid-withdrawal
group "core"
family ms-pw
type internal
cluster 1.1.1.1
neighbor 192.0.2.3
exit
neighbor 192.0.2.4
exit
neighbor 192.0.2.5
exit
neighbor 192.0.2.6
exit
exit
no shutdown
----------------------------------------------

After BGP is properly configured and the BGP update exchange takes place, the RIBs are properly
populated and the required prefixes uploaded into the MS-PW routing table. An example for PE1s RIB and pseudowire routing table is provided below.
*A:PE-1# show router bgp routes ms-pw
===============================================================================
BGP Router ID:192.0.2.1
AS:65536
Local AS:65536
===============================================================================
Legend Status codes : u - used, s - suppressed, h - history, d - decayed, * - valid
Origin codes : i - IGP, e - EGP, ? - incomplete, > - best, b - backup
===============================================================================
BGP MSPW Routes
===============================================================================
Flag Network
RD
Nexthop
AII-Type2/Preflen
As-Path
------------------------------------------------------------------------------u*>? 65536:192.0.2.21
65536:21
192.0.2.3
65536:192.0.2.21:0/64
No As-Path
*?
65536:192.0.2.21
65536:21
192.0.2.4
65536:192.0.2.21:0/64
No As-Path
u*>? 65536:192.0.2.22
65536:22
192.0.2.4
65536:192.0.2.22:0/64
No As-Path
*?
65536:192.0.2.22
65536:22
192.0.2.3
65536:192.0.2.22:0/64
No As-Path
?
------------------------------------------------------------------------------Routes : 16
===============================================================================
*A:PE-1# show service pw-routing route-table

Page 1444

Advanced Configuration Guide

Multi-Segment Pseudowire Routing

===============================================================================
Service PW L2 Routing Information
===============================================================================
AII-Type2/Prefix-Len
Next-Hop
Owner Age
Route-Distinguisher
Community
Best
------------------------------------------------------------------------------65536:192.0.2.11:0/64
192.0.2.1
local 02d13h58m
65536:11
65535:11
yes
65536:192.0.2.12:0/64
192.0.2.1
local 02d13h53m
65536:12
65535:12
yes
65536:192.0.2.21:0/64
192.0.2.3
bgp
02d13h56m
65536:21
65535:11
yes
65536:192.0.2.22:0/64
192.0.2.4
bgp
02d13h53m
65536:22
65535:12
yes
------------------------------------------------------------------------------Entries found: 15
===============================================================================

It is important to note that the two prefixes advertised by PE-2 are properly learned by PE-1
through two different next hops. Now, use each one with a different pseudowire and make sure
that the active and standby pseudowires follow different paths in the network.
Once the routes are installed in the MS-PW routing table, configure the services on PE-1 and PE2.
*A:PE-1# configure service epipe 2
*A:PE-1>config>service>epipe# info
---------------------------------------------description "ms-pw epipe with bgp - using 2 prefixes"
endpoint "CORE" create
description "end-point for epipe A/S PW redundancy"
revert-time 10
standby-signaling-master
exit
sap 1/1/3:2 create
exit
spoke-sdp-fec 21 fec 129 aii-type 2 create endpoint CORE
precedence primary
pw-template-bind 1
saii-type2 65536:192.0.2.11:1
taii-type2 65536:192.0.2.21:1
no shutdown
exit
spoke-sdp-fec 22 fec 129 aii-type 2 create endpoint CORE
pw-template-bind 1
saii-type2 65536:192.0.2.12:1
taii-type2 65536:192.0.2.22:1
no shutdown
exit
no shutdown
*A:PE-2# configure service epipe 2
*A:PE-2>config>service>epipe# info
---------------------------------------------description "ms-pw epipe with bgp - using 2 prefixes"

Advanced Configuration Guide

Page 1445

Configuration

endpoint "CORE" create


description "end-point for epipe A/S PW redundancy"
revert-time 10
exit
sap 1/1/3:2 create
exit
spoke-sdp-fec 21 fec 129 aii-type 2 create endpoint CORE
precedence primary
pw-template-bind 1
saii-type2 65536:192.0.2.21:1
taii-type2 65536:192.0.2.11:1
no shutdown
exit
spoke-sdp-fec 22 fec 129 aii-type 2 create endpoint CORE
pw-template-bind 1
saii-type2 65536:192.0.2.22:1
taii-type2 65536:192.0.2.12:1
no shutdown
exit
no shutdown
----------------------------------------------

The following command can be executed to check that the service and spoke-sdp-fecs are up:
*A:PE-1# show service id 2 base
===============================================================================
Service Basic Information
===============================================================================
Service Id
: 2
Vpn Id
: 0
Service Type
: Epipe
Name
: (Not Specified)
Description
: ms-pw epipe with bgp - using 2 prefixes
Customer Id
: 1
Last Status Change: 11/03/2004 06:13:10
Last Mgmt Change : 11/03/2004 06:13:52
Admin State
: Up
Oper State
: Up
MTU
: 1514
Vc Switching
: False
SAP Count
: 1
SDP Bind Count
: 2
Per Svc Hashing
: Disabled
Force QTag Fwd
: Disabled
------------------------------------------------------------------------------Service Access & Destination Points
------------------------------------------------------------------------------Identifier
Type
AdmMTU OprMTU Adm Opr
------------------------------------------------------------------------------sap:1/1/3:2
q-tag
1518
1518
Up
Up
sdp:17406:4294967287 SB(192.0.2.3)
MS-PW
0
1974
Up
Up
sdp:17407:4294967286 SB(192.0.2.4)
MS-PW
0
1974
Up
Up
===============================================================================

Note that the sdp-binding identifiers and sdp identifiers are automatically generated by the system.

Page 1446

Advanced Configuration Guide

Multi-Segment Pseudowire Routing

Use vccv-trace to check that the spoke-sdp-fecs for the active and standby pseudowires follow
different and disjoint paths:
*A:PE-1# oam vccv-trace spoke-sdp-fec 21
VCCV-TRACE with 120 bytes of MPLS payload
1 192.0.2.3 rtt=1.75ms rc=8(DSRtrMatchLabel)
2 192.0.2.5 rtt=5.38ms rc=8(DSRtrMatchLabel)
3 192.0.2.2 rtt=8.34ms rc=3(EgressRtr)
*A:PE-1# oam vccv-trace spoke-sdp-fec 22
VCCV-TRACE with 120 bytes of MPLS payload
1 192.0.2.4 rtt=1.80ms rc=8(DSRtrMatchLabel)
2 192.0.2.6 rtt=5.48ms rc=8(DSRtrMatchLabel)
3 192.0.2.2 rtt=7.83ms rc=3(EgressRtr)

Advanced Configuration Guide

Page 1447

Configuration

MS-PW using Static Routing


In this sub-section, Epipe 3 will be configured between PE-1 and PE-2, where TLDP will use
static-routes in the MS-PW routing table to signal the MS-PW.
On PE-1 and PE-2 (only) we will configure the prefixes used for setting up Epipe 3. Those could
be the same as used for Epipe 2, however we will use different ones in this example. Note that the
no advertise-bgp parameter is required now. The static routes for each remote prefix are also
configured. Since we will also have pseudowire redundancy for Epipe 3, two prefixes with staticroutes pointing at different next-hops will be used:
*A:PE-1>config>service>pw-routing# info
---------------------------------------------spe-address 65536:192.0.2.1
local-prefix 65536:192.0.2.13 create
exit
local-prefix 65536:192.0.2.14 create
exit
static-route 65536:192.0.2.23:192.0.2.3
static-route 65536:192.0.2.24:192.0.2.4
*A:PE-2>config>service>pw-routing# info
---------------------------------------------spe-address 65536:192.0.2.2
local-prefix 65536:192.0.2.23 create
exit
local-prefix 65536:192.0.2.24 create
exit
static-route 65536:192.0.2.13:192.0.2.5
static-route 65536:192.0.2.14:192.0.2.6

It is important to note that static-routes are also required at all S-PEs along the path (keeping the
path diversity for the prefixes as well) and for both directions:
A:PE-3>config>service>pw-routing# info
---------------------------------------------spe-address 65536:192.0.2.3
static-route 65536:192.0.2.13:192.0.2.1
static-route 65536:192.0.2.23:192.0.2.5
---------------------------------------------A:PE-4>config>service>pw-routing# info
---------------------------------------------spe-address 65536:192.0.2.4
static-route 65536:192.0.2.14:192.0.2.1
static-route 65536:192.0.2.24:192.0.2.6
----------------------------------------------

Page 1448

Advanced Configuration Guide

Multi-Segment Pseudowire Routing

Finally, once the MS-PW routing tables are properly populated, the services can be configured and
brought up:
*A:PE-1>config>service>epipe# info
---------------------------------------------description "ms-pw epipe with static routes"
endpoint "CORE" create
description "end-point for epipe A/S PW redundancy"
revert-time 10
standby-signaling-master
exit
sap 1/1/3:3 create
exit
spoke-sdp-fec 31 fec 129 aii-type 2 create endpoint CORE
precedence primary
pw-template-bind 1
saii-type2 65536:192.0.2.13:31
taii-type2 65536:192.0.2.23:31
no shutdown
exit
spoke-sdp-fec 32 fec 129 aii-type 2 create endpoint CORE
pw-template-bind 1
saii-type2 65536:192.0.2.14:32
taii-type2 65536:192.0.2.24:32
no shutdown
exit
no shutdown
---------------------------------------------*A:PE-2>config>service>epipe# info
---------------------------------------------description "ms-pw epipe with bgp - using 2 prefixes"
endpoint "CORE" create
description "end-point for epipe A/S PW redundancy"
revert-time 10
standby-signaling-master
exit
sap 1/1/3:2 create
exit
spoke-sdp-fec 21 fec 129 aii-type 2 create endpoint CORE
precedence primary
pw-template-bind 1
saii-type2 65536:192.0.2.21:1
taii-type2 65536:192.0.2.11:1
no shutdown
exit
spoke-sdp-fec 22 fec 129 aii-type 2 create endpoint CORE
pw-template-bind 1
saii-type2 65536:192.0.2.22:1
taii-type2 65536:192.0.2.12:1
no shutdown
exit
no shutdown

Check the status and path of the spoke-sdp-fecs with the proper show commands and oam vccvtrace/ping commands (see previous sub-section).

Advanced Configuration Guide

Page 1449

Configuration

MS-PW using Explicit Paths


In this sub-section, Epipe 4 will be configured between PE-1 and PE-2, where TLDP will use
explicit paths to signal the MS-PW, overriding the information given by the MS-PW routing table.
Although this mode requires the specific configuration of the hops, one by one, the configuration
is only done on the T-PEs, as opposed to the static-routes where all the S-PEs must be configured
with static routes (a mixed of static-routes and BGP routes can coexist). The local-prefixes shown
for Epipe 3 will be re-used here for Epipe 4.
Now path-1 and path-2 will be configured hop by hop, using diverse paths. Note that all the S-PE
nodes as well as the terminating T-PE must be included in the path.
*A:PE-1>config>service>pw-routing# info
---------------------------------------------spe-address 65536:192.0.2.1
local-prefix 65536:192.0.2.13 create
exit
local-prefix 65536:192.0.2.14 create
exit
path "path-1" create
hop 1 192.0.2.3
hop 2 192.0.2.5
hop 3 192.0.2.2
no shutdown
exit
path "path-2" create
hop 1 192.0.2.4
hop 2 192.0.2.6
hop 3 192.0.2.2
no shutdown
exit
---------------------------------------------*A:PE-2>config>service>pw-routing# info
---------------------------------------------spe-address 65536:192.0.2.2
local-prefix 65536:192.0.2.23 create
exit
local-prefix 65536:192.0.2.24 create
exit
path "path-1" create
hop 1 192.0.2.5
hop 2 192.0.2.3
hop 3 192.0.2.1
no shutdown
exit
path "path-2" create
hop 1 192.0.2.6
hop 2 192.0.2.4
hop 3 192.0.2.1
no shutdown
exit

Page 1450

Advanced Configuration Guide

Multi-Segment Pseudowire Routing

And now, those paths must be specified when configuring the Epipe:
*A:PE-1>config>service>epipe# info
---------------------------------------------description "ms-pw epipe with explicit paths"
endpoint "CORE" create
description "end-point for epipe A/S PW redundancy"
revert-time 10
standby-signaling-master
exit
sap 1/1/3:4 create
exit
spoke-sdp-fec 41 fec 129 aii-type 2 create endpoint CORE
precedence primary
pw-template-bind 1
saii-type2 65536:192.0.2.13:41
taii-type2 65536:192.0.2.23:41
path "path-1"
no shutdown
exit
spoke-sdp-fec 42 fec 129 aii-type 2 create endpoint CORE
saii-type2 65536:192.0.2.14:42
taii-type2 65536:192.0.2.24:42
path "path-2"
no shutdown
exit
no shutdown
---------------------------------------------*A:PE-2>config>service>epipe# info
---------------------------------------------description "ms-pw epipe with explicit paths"
endpoint "CORE" create
description "end-point for epipe A/S PW redundancy"
revert-time 10
exit
sap 1/1/3:4 create
exit
spoke-sdp-fec 41 fec 129 aii-type 2 create endpoint CORE
precedence primary
pw-template-bind 1
saii-type2 65536:192.0.2.23:41
taii-type2 65536:192.0.2.13:41
path "path-1"
no shutdown
exit
spoke-sdp-fec 42 fec 129 aii-type 2 create endpoint CORE
saii-type2 65536:192.0.2.24:42
taii-type2 65536:192.0.2.14:42
path "path-2"
no shutdown
exit
no shutdown
----------------------------------------------

Now, check the status and path of the spoke-sdp-fecs with the proper show commands and oam
vccv-trace/ping commands (see previous sub-section).

Advanced Configuration Guide

Page 1451

Configuration

Inter-AS MS-PW Routing


This section provides a configuration example for an inter-AS scenario, using BGP tunnels
between ASBRs and BGP as the MS-PW routing mechanism. The following network setup will
be used in this section.
Transport
Tunneling

LDP

LDP

eBGP

192.0.2.3

192.0.2.7

PE-3

PE-7

RR

192.0.2.8

eBGP

192.0.2.6

iBGP

PE-8

PE-6
1

iBGP

iBGP

AS65536

SAII 65536:192.0.2.11:1
TAII 65537:192.0.2.6:1

iBGP

SAII 65537:192.0.2.6:1
TAII 65536:192.0.2.11:1

1/1/2

AS65537
iBGP

iBGP

ICBs

Active
PE-1

PE-4

CE-1
172.16.0.1

eBGP

PE-5
1

192.0.2.1

192.0.2.4
SAII 65536:192.0.2.12:1
TAII 65537:192.0.2.5:1

MC-LAG
1/1/2

1/1/1

192.0.2.5
SAII 65537:192.0.2.5:1
TAII 65536:192.0.2.12:1

PE-2
1/1/1

CE-2
192.0.2.2

172.16.0.2
ACG0010

Figure 129: Inter-AS MS-PW Network Topology

In this example, only one Epipe is configured (Epipe 1, using MS-PW BGP routing). The T-PEs
are PE-1, PE-5 and PE-6. PE-7, PE-8 and PE-4 are S-PEs.
A/S pseudowire redundancy together with MC-LAG at one end will be used, as depicted in the
diagram. ICB (Inter-chassis Backup) spoke SDPs between PE-5 and PE-6 are required in order to
forward the in-flight packets while MC-LAG and A/S pseudowire are converging, in case of
network failures. Those ICBs will also be signalled following the MS-PW routing procedures.
The network setup in the figure is pre-configured with the following settings:

Page 1452

There are two AS (65536 and 65537) which are connected by two ASBR pairs (PE-7/PE4 and PE-8/PE-5) running eBGP between them. These eBGP sessions will be used to
exchange ipv4-label (to setup the transport BGP-LBL tunnel, according to the RFC 3107)
and MS-PW NLRIs.

Within AS65536, PE-3 is used as an RR to reflect the MS-PW routes. In AS65537 there is
a full mesh of iBGP sessions to distribute the MS-PW routes.

ISIS is used within each AS.

Advanced Configuration Guide

Multi-Segment Pseudowire Routing

LDP is used as a transport MPLS signalling protocol within each AS and a BGP tunnel
will be used between the ASBRs (note that MS-PW routing supports LDP or BGP tunnels
as transport).

A redundant MC-LAG access to PE-6 and PE-5 is configured.

The next section will go through the configuration required to set up a redundant Epipe between
CE-1 and CE-2, by combining A/S pseudowire in the network and MC-LAG at the access.

MS-PW using BGP Routing


Epipe 1 will be configured at the end of this section, including the active and redundant
pseudowires from PE-1 to PE-5/PE-6, as well as the required ICBs and SAPs at the access.
As discussed, the first step is the provisioning of the pw-routing context. Again, the spe-address
must be provisioned in all T-PEs and S-PEs whereas prefixes are mandatory only on the T-PEs
involved in the service. The following CLI output shows the prefixes configured on PE-1, PE-5
and PE-6. Note that two prefixes are needed in PE-1 in order to make sure that active and standby
pseudowires follow disjoint paths.
*A:PE-1>config>service>pw-routing# info
---------------------------------------------spe-address 65536:192.0.2.1
local-prefix 65536:192.0.2.11 create
advertise-bgp route-distinguisher 65536:11 community 65535:11
exit
local-prefix 65536:192.0.2.12 create
advertise-bgp route-distinguisher 65536:12 community 65535:12
exit
exit
*A:PE-5>config>service>pw-routing# info
---------------------------------------------spe-address 65537:192.0.2.5
local-prefix 65537:192.0.2.5 create
advertise-bgp route-distinguisher 65537:5 community 65535:5
exit
*A:PE-6>config>service>pw-routing# info
---------------------------------------------spe-address 65537:192.0.2.6
local-prefix 65537:192.0.2.6 create
advertise-bgp route-distinguisher 65537:6 community 65535:6
exit

Advanced Configuration Guide

Page 1453

Configuration

Once the spe-addresses and prefixes have been provisioned, BGP must be configured accordingly.
An example of the configuration at PE-1 and PE-6 is shown below. Note that a simple BGP
export-policy is used to export all the local MS-PW prefixes.
#-------------------------------------------------# PE-1 BGP related configuration
#-------------------------------------------------#-------------------------------------------------echo "Policy Configuration"
#-------------------------------------------------policy-options
begin
policy-statement "export_ms-pw"
entry 10
from
family ms-pw
exit
action accept
exit
exit
exit
commit
exit
#-------------------------------------------------echo "BGP Configuration"
#-------------------------------------------------bgp
min-route-advertisement 1
rapid-withdrawal
group "intra-AS"
family ms-pw
type internal
export "export_ms-pw"
neighbor 192.0.2.3
exit
exit
no shutdown
exit
exit
#-------------------------------------------------# PE-6 BGP related configuration
#-------------------------------------------------#-------------------------------------------------echo "Policy Configuration"
#-------------------------------------------------policy-options
begin
policy-statement "export_ms-pw"
entry 10
from
family ms-pw
exit
action accept
exit
exit

Page 1454

Advanced Configuration Guide

Multi-Segment Pseudowire Routing

exit
commit
exit
#-------------------------------------------------echo "BGP Configuration"
#-------------------------------------------------bgp
min-route-advertisement 1
enable-peer-tracking
rapid-withdrawal
group "intra-AS"
family ms-pw
type internal
export "export_ms-pw"
neighbor 192.0.2.5
exit
neighbor 192.0.2.8
exit
exit
no shutdown
exit
exit

At the ASBR, the BGP policies are a little more complex since the following tasks must be
accomplished:

ASBR ipv4 system addresses must be exported to the peer ASBR to establish the RFC
3107 BGP tunnel between ASBRs.

BGP export policies must be used so that MS-PW NLRI exchange can be controlled and
attributes like MED (towards the remote AS) and/or local-preference (towards the local
AS) can be modified.

Finally, BGP import policies must also be used to modify the MS-PW route NH (nexthops) since the TLDP next signaling hop must match a peer TLDP system address

As an example of ASBR BGP configuration, PE-4 and PE-7 are shown below.
Note that the prefixes 65536:192.0.2.11 and 65537:192.0.2.6 must be preferred in the PE-7/PE-8
pair whereas the prefixes 65536:192.0.2.12 and 65537:192.0.2.5 must be preferred in the PE-4/
PE-5 pair, so that the pseudowires are established as depicted in Figure 129. The preference can be
propagated by using the BGP MED (use the local preference (LP) within the AS (LP is not
relevant to eBGP)). The following CLI excerpt shows an example of how to modify MED and LP,
as well as changing the NH with an import policy.
#-------------------------------------------------# PE-4 BGP related configuration
#-------------------------------------------------#-------------------------------------------------echo "Policy Configuration"
#-------------------------------------------------policy-options
begin

Advanced Configuration Guide

Page 1455

Configuration

prefix-list "system"
prefix 192.0.2.4/32 exact
exit
community "65535:5" members "65535:5"
community "65535:6" members "65535:6"
community "65535:11" members "65535:11"
community "65535:12" members "65535:12"
policy-statement "ASBR to ASBR"
entry 10
from
protocol bgp
community "65535:12"
family ms-pw
exit
action accept
origin igp
metric set 50
exit
exit
entry 20
from
protocol bgp
community "65535:11"
family ms-pw
exit
action accept
origin igp
metric set 100
exit
exit
exit
policy-statement "ASBR to region"
entry 10
from
protocol bgp
community "65535:5"
family ms-pw
exit
action accept
origin igp
local-preference 150
next-hop-self
exit
exit
entry 20
from
protocol bgp
community "65535:6"
family ms-pw
exit
action accept
origin igp
next-hop-self
exit
exit
exit
policy-statement "export_ipv4_system"
entry 10
from

Page 1456

Advanced Configuration Guide

Multi-Segment Pseudowire Routing

prefix-list "system"
exit
action accept
origin igp
exit
exit
exit
policy-statement "import ms-pw NH change"
entry 10
from
protocol bgp
family ms-pw
exit
action accept
next-hop 192.0.2.5
exit
exit
exit
commit
exit
#-------------------------------------------------echo "BGP Configuration"
#-------------------------------------------------bgp
min-route-advertisement 1
enable-peer-tracking
rapid-withdrawal
group "inter-AS"
family ipv4 ms-pw
type external
import "import ms-pw NH change"
export "export_ipv4_system" "ASBR to ASBR"
local-as 65536
peer-as 65537
neighbor 192.168.45.2
advertise-label ipv4
exit
exit
group "intra-AS"
family ms-pw
type internal
export "ASBR to region"
neighbor 192.0.2.3
exit
exit
no shutdown
exit
exit
#-------------------------------------------------# PE-7 BGP related configuration
#-------------------------------------------------#-------------------------------------------------echo "Policy Configuration"
#-------------------------------------------------policy-options
begin
prefix-list "system"

Advanced Configuration Guide

Page 1457

Configuration

prefix 192.0.2.7/32 exact


exit
community "65535:5" members "65535:5"
community "65535:6" members "65535:6"
community "65535:11" members "65535:11"
community "65535:12" members "65535:12"
policy-statement "ASBR to ASBR"
entry 10
from
protocol bgp
community "65535:11"
family ms-pw
exit
action accept
origin igp
metric set 50
exit
exit
entry 20
from
protocol bgp
community "65535:12"
family ms-pw
exit
action accept
origin igp
metric set 100
exit
exit
exit
policy-statement "ASBR to region"
entry 10
from
protocol bgp
community "65535:6"
family ms-pw
exit
action accept
origin igp
local-preference 150
next-hop-self
exit
exit
entry 20
from
protocol bgp
community "65535:5"
family ms-pw
exit
action accept
origin igp
next-hop-self
exit
exit
exit
policy-statement "export_ipv4_system"
entry 10
from
prefix-list "system"

Page 1458

Advanced Configuration Guide

Multi-Segment Pseudowire Routing

exit
action accept
origin igp
exit
exit
exit
policy-statement "import ms-pw NH change"
entry 10
from
protocol bgp
family ms-pw
exit
action accept
next-hop 192.0.2.8
exit
exit
exit
commit
exit
#-------------------------------------------------echo "BGP Configuration"
#-------------------------------------------------bgp
min-route-advertisement 1
enable-peer-tracking
rapid-withdrawal
transport-tunnel mpls
group "inter-AS"
family ipv4 ms-pw
type external
import "import ms-pw NH change"
export "export_ipv4_system" "ASBR to ASBR"
local-as 65536
peer-as 65537
neighbor 192.168.78.2
advertise-label ipv4
exit
exit
group "intra-AS"
family ms-pw
type internal
export "ASBR to region"
neighbor 192.0.2.3
exit
exit
no shutdown
exit
exit

PE-5 and PE-8 have similar configurations to the one shown above. Note that PE-5 is a T-PE as
well as an ASBR, therefore a local MS-PW prefix must be exported as opposed to only remote
prefixes (that is, some export entries for the local MS-PW routes will not contain protocol bgp in
the matching criteria).

Advanced Configuration Guide

Page 1459

Configuration

After BGP is properly configured and the updates get exchanged, the RIBs are populated and the
prefixes uploaded onto the MS-PW routing table as shown below for PE-1 and PE-6.
*A:PE-1# show router bgp routes ms-pw
===============================================================================
BGP Router ID:192.0.2.1
AS:65536
Local AS:65536
===============================================================================
===============================================================================
BGP MSPW Routes
===============================================================================
Flag Network
RD
Nexthop
AII-Type2/Preflen
As-Path
------------------------------------------------------------------------------u*>i 65537:192.0.2.5
65537:5
192.0.2.4
65537:192.0.2.5:0/64
65537
u*>i 65537:192.0.2.6
65537:6
192.0.2.7
65537:192.0.2.6:0/64
65537
------------------------------------------------------------------------------Routes : 4

*A:PE-1# show service pw-routing route-table


===============================================================================
Service PW L2 Routing Information
===============================================================================
AII-Type2/Prefix-Len
Next-Hop
Owner Age
Route-Distinguisher
Community
Best
------------------------------------------------------------------------------65536:192.0.2.11:0/64
192.0.2.1
local 30d22h25m
0:0
0:0
yes
65536:192.0.2.11:0/64
192.0.2.1
local 30d22h24m
65536:11
65535:11
yes
65536:192.0.2.12:0/64
192.0.2.1
local 30d22h19m
0:0
0:0
yes
65536:192.0.2.12:0/64
192.0.2.1
local 30d22h19m
65536:12
65535:12
yes
65537:192.0.2.5:0/64
192.0.2.4
bgp
02h43m25s
65537:5
65535:5
yes
65537:192.0.2.6:0/64
192.0.2.7
bgp
02h45m49s
65537:6
65535:6
yes
------------------------------------------------------------------------------Entries found: 6
===============================================================================
*A:PE-1#

*A:PE-6# show router bgp routes ms-pw


===============================================================================
BGP Router ID:192.0.2.6
AS:65537
Local AS:65537
===============================================================================
===============================================================================
BGP MSPW Routes
===============================================================================
Flag Network
RD
Nexthop
AII-Type2/Preflen

Page 1460

Advanced Configuration Guide

Multi-Segment Pseudowire Routing

As-Path
------------------------------------------------------------------------------u*>i 65536:192.0.2.11
65536:11
192.0.2.8
65536:192.0.2.11:0/64
65536
u*>i 65536:192.0.2.12
65536:12
192.0.2.5
65536:192.0.2.12:0/64
65536
u*>i 65537:192.0.2.5
65537:5
192.0.2.5
65537:192.0.2.5:0/64
No As-Path
------------------------------------------------------------------------------Routes : 3
===============================================================================
*A:PE-6#

*A:PE-6# show service pw-routing route-table


===============================================================================
Service PW L2 Routing Information
===============================================================================
AII-Type2/Prefix-Len
Next-Hop
Owner Age
Route-Distinguisher
Community
Best
------------------------------------------------------------------------------65536:192.0.2.11:0/64
192.0.2.8
bgp
02h52m08s
65536:11
65535:11
yes
65536:192.0.2.12:0/64
192.0.2.5
bgp
02h38m51s
65536:12
65535:12
yes
65537:192.0.2.5:0/64
192.0.2.5
bgp
02h38m51s
65537:5
65535:5
yes
65537:192.0.2.6:0/64
192.0.2.6
local 28d02h16m
0:0
0:0
yes
65537:192.0.2.6:0/64
192.0.2.6
local 28d02h16m
65537:6
65535:6
yes
------------------------------------------------------------------------------Entries found: 5
===============================================================================
*A:PE-6#

As can be seen in the show commands, the two PE-1 prefixes are learned on PE-5 and PE-6
through different and disjoint paths, and the PE-5 and PE-6 prefixes are learned by PE-1 through
two different and disjoint paths.
The last step is the service configuration on the three T-PEs, as shown below. Note that TLDP
sessions must have been previously and explicitly configured between the T-PEs and S-PEs (i.e.,
between PE-1 and PE-4/7, between PE-4 and PE-5, PE-7 and PE-8 and between PE-6 and PE-5/
8).
#-------------------------------------------------# PE-1 Service related configuration
#-------------------------------------------------#-------------------------------------------------echo "Service Configuration"
#-------------------------------------------------service
customer 1 create

Advanced Configuration Guide

Page 1461

Configuration

description "Default customer"


exit
pw-template 1 create
controlword
exit
epipe 1 customer 1 create
description "ms-pw epipe with bgp, inter-AS, MC-LAG redundancy"
endpoint "CORE" create
description "end-point for epipe A/S PW redundancy"
exit
sap 1/1/1:1 create
exit
spoke-sdp-fec 11 fec 129 aii-type 2 create endpoint CORE
precedence primary
pw-template-bind 1
saii-type2 65536:192.0.2.11:1
taii-type2 65537:192.0.2.6:1
no shutdown
exit
spoke-sdp-fec 12 fec 129 aii-type 2 create endpoint CORE
pw-template-bind 1
saii-type2 65536:192.0.2.12:1
taii-type2 65537:192.0.2.5:1
no shutdown
exit
no shutdown
exit
#-------------------------------------------------# PE-5 Service related configuration
#-------------------------------------------------#-------------------------------------------------echo "Service Configuration"
#-------------------------------------------------service
customer 1 create
description "Default customer"
exit
pw-template 1 create
controlword
exit
epipe 1 customer 1 create
description "ms-pw epipe with bgp, inter-AS, MC-LAG redundancy"
endpoint "CORE" create
description "end-point for epipe A/S PW redundancy"
exit
endpoint "ACCESS" create
exit
sap lag-1:1 endpoint "ACCESS" create
exit
spoke-sdp-fec 11 fec 129 aii-type 2 create endpoint CORE
pw-template-bind 1
saii-type2 65537:192.0.2.5:1
taii-type2 65536:192.0.2.12:1
no shutdown
exit
spoke-sdp-fec 12 fec 129 aii-type 2 create endpoint CORE icb

Page 1462

Advanced Configuration Guide

Multi-Segment Pseudowire Routing

pw-template-bind 1
saii-type2 65537:192.0.2.5:2
taii-type2 65537:192.0.2.6:2
no shutdown
exit
spoke-sdp-fec 13 fec 129 aii-type 2 create endpoint ACCESS icb
pw-template-bind 1
saii-type2 65537:192.0.2.5:3
taii-type2 65537:192.0.2.6:3
no shutdown
exit
no shutdown
exit
exit
#-------------------------------------------------# PE-6 Service related configuration
#-------------------------------------------------#-------------------------------------------------echo "Service Configuration"
#-------------------------------------------------service
customer 1 create
description "Default customer"
exit
pw-template 1 create
controlword
exit
epipe 1 customer 1 create
description "ms-pw epipe with bgp, inter-AS, MC-LAG redundancy"
endpoint "CORE" create
description "end-point for epipe A/S PW redundancy"
exit
endpoint "ACCESS" create
exit
sap lag-1:1 endpoint "ACCESS" create
exit
spoke-sdp-fec 11 fec 129 aii-type 2 create endpoint CORE
pw-template-bind 1
saii-type2 65537:192.0.2.6:1
taii-type2 65536:192.0.2.11:1
no shutdown
exit
spoke-sdp-fec 12 fec 129 aii-type 2 create endpoint CORE icb
pw-template-bind 1
saii-type2 65537:192.0.2.6:3
taii-type2 65537:192.0.2.5:3
no shutdown
exit
spoke-sdp-fec 13 fec 129 aii-type 2 create endpoint ACCESS icb
pw-template-bind 1
saii-type2 65537:192.0.2.6:2
taii-type2 65537:192.0.2.5:2
no shutdown
exit
no shutdown
exit
exit

Advanced Configuration Guide

Page 1463

Configuration

The following show commands can be executed to check the status of the Epipe 1 and the
pseudowire status signaling received:
*A:PE-1# show service id 1 base
===============================================================================
Service Basic Information
===============================================================================
Service Id
: 1
Vpn Id
: 0
Service Type
: Epipe
Name
: (Not Specified)
Description
: ms-pw epipe with bgp, inter-AS, MC-LAG redundancy
Customer Id
: 1
Last Status Change: 12/04/2004 03:01:49
Last Mgmt Change : 12/04/2004 03:42:43
Admin State
: Up
Oper State
: Up
MTU
: 1514
Vc Switching
: False
SAP Count
: 1
SDP Bind Count
: 2
Per Svc Hashing
: Disabled
Force QTag Fwd
: Disabled
------------------------------------------------------------------------------Service Access & Destination Points
------------------------------------------------------------------------------Identifier
Type
AdmMTU OprMTU Adm Opr
------------------------------------------------------------------------------sap:1/1/1:1
q-tag
1518
1518
Up
Up
sdp:17405:4294967279 SB(192.0.2.7)
MS-PW
0
1974
Up
Up
sdp:17406:4294967280 SB(192.0.2.4)
MS-PW
0
1974
Up
Up

*A:PE-1# show service id 1 endpoint


===============================================================================
Service 1 endpoints
===============================================================================
Endpoint name
: CORE
Description
: end-point for epipe A/S PW redundancy
Revert time
: 0
Act Hold Delay
: 0
Standby Signaling Master
: false
Standby Signaling Slave
: false
Tx Active (SDP-FEC)
: 11
Tx Active Up Time
: 2d 23:17:51
Revert Time Count Down
: N/A
Tx Active Change Count
: 4
Last Tx Active Change
: 12/04/2004 03:42:43
------------------------------------------------------------------------------Members
------------------------------------------------------------------------------Sdp-fec: 11 Prec:0
Oper Status: Up
Sdp-fec: 12 Prec:4
Oper Status: Up
===============================================================================
===============================================================================

Page 1464

Advanced Configuration Guide

Multi-Segment Pseudowire Routing

Note that PE-5 will have the MC-LAG standby interface and as such the SAP will be operationally
down and will drive the standby signaling to the remote T-PEs:
*A:PE-5# show service id 1 base
===============================================================================
Service Basic Information
===============================================================================
Service Id
: 1
Vpn Id
: 0
Service Type
: Epipe
Name
: (Not Specified)
Description
: ms-pw epipe with bgp, inter-AS, MC-LAG redundancy
Customer Id
: 1
Last Status Change: 11/18/2011 17:12:04
Last Mgmt Change : 11/18/2011 17:13:11
Admin State
: Up
Oper State
: Up
MTU
: 1514
Vc Switching
: False
SAP Count
: 1
SDP Bind Count
: 3
Per Svc Hashing
: Disabled
Force QTag Fwd
: Disabled
------------------------------------------------------------------------------Service Access & Destination Points
------------------------------------------------------------------------------Identifier
Type
AdmMTU OprMTU Adm Opr
------------------------------------------------------------------------------sap:lag-1:1
q-tag
1518
1518
Up
Down
sdp:17402:4294967245 SB(192.0.2.6)
MS-PW
0
1974
Up
Up
sdp:17402:4294967246 SB(192.0.2.6)
MS-PW
0
1974
Up
Up
sdp:17403:4294967247 SB(192.0.2.4)
MS-PW
0
1974
Up
Up
===============================================================================
*A:PE-5# show service id 1 all | match Flag
Flags
: None
Flags
: None
Flags
: None
Flags
: PortOperDown StandByForMcProtocol

The following commands are useful on the S-PEs in order to find the PWs automatically created
as well as the SDPs automatically used for those PWs.
*A:PE-7# show service sdp-using
===============================================================================
SDP Using
===============================================================================
SvcId
SdpId
Type
Far End
Opr S* I.Label E.Label
------------------------------------------------------------------------------2147483647 17406:4294967294
MS-PW
192.0.2.1
Up
131064
131065
2147483647 17407:4294967295
MS-PW
192.0.2.8
Up
131065
131068
------------------------------------------------------------------------------Number of SDPs : 2
------------------------------------------------------------------------------===============================================================================

As it can be seen above, two PWs (type MS-PW) have been automatically created over two also
automatically created SDPs: 17406 and 17407. SDP 17406 is built over an LDP tunnel whereas
SDP 17407 runs over a BGP tunnel.

Advanced Configuration Guide

Page 1465

Configuration

*A:PE-7# show router tunnel-table


===============================================================================
Tunnel Table (Router: Base)
===============================================================================
Destination
Owner Encap TunnelId Pref
Nexthop
Metric
------------------------------------------------------------------------------192.0.2.1/32
sdp
MPLS 17406
5
192.0.2.1
0
192.0.2.1/32
ldp
MPLS
9
192.168.47.1
20
192.0.2.3/32
ldp
MPLS
9
192.168.37.1
10
192.0.2.4/32
ldp
MPLS
9
192.168.47.1
10
192.0.2.8/32
sdp
MPLS 17407
5
192.0.2.8
0
192.0.2.8/32
bgp
MPLS
10
192.168.78.2
1000
*A:PE-7# show service sdp 17406 detail | match "Active LSP"
Mixed LSP Mode
: Enabled
Active LSP Type

: LDP

*A:PE-7# show service sdp 17407 detail | match "Active LSP"


Mixed LSP Mode
: Enabled
Active LSP Type

: BGP

In addition to all of the recommended show commands, vccv-ping and vccv-trace are two
extremely useful commands in this environment. vccv-trace can even help to trace the traffic
going through the ICBs under failure situations.

Page 1466

Advanced Configuration Guide

Multi-Segment Pseudowire Routing

Conclusion
Service Providers are always seeking highly scalable VLL services that can be deployed with the
lowest operational cost. The SR OS supports MS-PW routing according to the draft-ietf-pwe3dynamic-ms-pw. MS-PW routing allows the Service Provider to deploy ELINE services without
having to provision services in the core of the network. In other words, MS-PW enables end-point
provisioning in highly scalable seamless MPLS networks, through the use of BGP. Alternatively,
static MS-PW routes or explicit paths can also be used.
The examples used in this section illustrate the configuration of MS-PW routing in intra-AS and
inter-AS scenarios. Show and OAM commands have also been suggested so that the operator can
verify and troubleshoot the MS-PW routing paths and procedures.

Advanced Configuration Guide

Page 1467

Conclusion

Page 1468

Advanced Configuration Guide

Multicast VPN: Sender-Only,


Receiver-Only

In This Chapter
This section provides information about multicast VPN sender-only and receiver-only
configurations.
Topics in this section include:

Applicability on page 1470

Summary on page 1471

Overview on page 1472

Overview on page 1472

Conclusion on page 1522

Advanced Configuration Guide

Page 1469

Applicability

Applicability
This example is applicable to 7950 XRS, 7750 all variants, 7750 SR c4/12 and 7450 mixed mode
systems. Chassis mode C or higher must be used. The configuration was tested on release 11.0R3.

Page 1470

Advanced Configuration Guide

Multicast VPN: Sender-Only, Receiver-Only

Summary
This example covers a basic technology overview, the network topology and configuration
examples which are used for the Multicast VPN (MVPN) sender-only, receiver-only feature.
Knowledge of the Alcatel-Lucent multicast and Layer 3 VPNs concepts are assumed throughout
this document.

Advanced Configuration Guide

Page 1471

Overview

Overview
By default, if multiple PE nodes form a peering relationship with a common MVPN instance then
each PE node originates a multicast tree locally towards the remaining PE nodes that are members
of this MVPN instance. This behavior creates a full mesh of Inclusive-Provider Multicast Service
Interfaces (I-PMSIs) across all PE nodes in the MVPN.

Mcast
Source

Sender + Receiver

Sender + Receiver

PE-3

PE-2

VRF

Mcast
Source

VRF

PMSI

PMSI

Receiver

PMSI

VRF

Receiver
PE-1
Sender + Receiver
al_0327

Figure 130: Default PMSI Hierarchy

It is often a case that a given MVPN has many sites with multicast receivers, but only a few sites
that host either both receivers and sources, or sources only.
The MVPN sender-only/receiver-only feature optimizes control and data plane resources by
preventing unnecessary I-PMSI meshing when a given PE hosts multicast sources only, or
multicast receivers only, for a given MVPN. An example of such an optimization is presented in
Figure 131.

Page 1472

Advanced Configuration Guide

Multicast VPN: Sender-Only, Receiver-Only

Mcast
Source

Sender Only

Receiver Only

PE-3

PE-2

VRF

VRF

Receiver

PMSI

VRF

Receiver
PE-1
Receiver Only

al_0329

Figure 131: Optimized PMSI Structure

The general rules to follow are:

For PE nodes that host only multicast sources for a given MVPN, operators can now block
PEs, through configuration, from joining I-PMSIs from other PEs in this MVPN.

For PE nodes that host only multicast receivers for a given MVPN, operators can now
block PEs, through configuration, to set-up a local I-PMSI to other PEs in this MVPN.

MVPN sender-only/receiver-only is supported with next generation-MVPN for both IPv4 and
IPv6 customer multicast using:

IPv4 RSVP-TE provider tunnels

IPv4 LDP provider tunnels

Note: Extra attention should be given to the Bootstrap Router/Rendezvous Point (BSR/RP)
placement when sender-only/receiver-only is enabled:

The RP should be at sender-receiver or sender-only site so that (*,G)1 traffic can be sent
over the tunnel

The BSR should be deployed at the sender-receiver site.

The BSR can be at a sender-only site if the RPs are at the same site.

1.

*,G refers to an individual multicast stream indicating any source (*) and the multicast group (G) used by the
stream.

Advanced Configuration Guide

Page 1473

Configuration

Configuration
The test topology is shown in Figure 132.

3/1/10

Mcast
Source

Sender Only

Receiver Only

PE-3

PE-2

VRF

1/1/1

1/1/1

VRF

2/2/1

Receiver
3/1/4

Mcast
Source

3/1/1

2/1/5
2/1/1

VRF

3/1/1
2/1/1

Receiver
PE-1
Sender + Receiver

al_0330

Figure 132: Test Topology

To configure the sender-only/receiver-only feature the following configuration command is used:


*A:PE>config>service>vprn>mvpn# mdt-type
- mdt-type {sender-only|receiver-only|sender-receiver}
- no mdt-type

sender-receiver is the default option and is visible using the info detail command.
This command restricts the MVPN instance per PE node to a specific role and provides an option
to configure either a sender-only or receiver-only mode per PE node per service.
Parameters:
sender-only MVPN has only senders connected to PE node.
receiver-only MVPN has only receivers connected to PE node.
sender-receiver MVPN has both sender and receivers connected to PE node.

Page 1474

Advanced Configuration Guide

Multicast VPN: Sender-Only, Receiver-Only

Considerations:

Two general approaches for building MVPNs will be covered in detail in this example:
Point-to-multipoint (P2MP) RSVP MVPNs
Multicast LDP (mLDP) MVPNs

IPv4 and IPv6 multicast streaming are used for every MVPN at the same time.

Basic principles of an MVPN including I-PMSI, S-PMSI, mLDP and P2MP RSVP are
covered in the Multicast in a VPN I on page 1147 and chapters of this guide.

PIM SSM is used for IPv4/IPv6 Customer (C)-multicast groups.

Advanced Configuration Guide

Page 1475

Configuration

RSVP-Based MVPN Configuration


Step 0. Configure a basic MVPN using P2MP RSVP as a transport protocol for C-multicast

groups. For this setup PE-1 and PE-2 are configured to receive the following multicast
groups:

IPv4 group 232.0.0.1 source 172.16.3.1

IPv6 group FF3E::8000:1 source 2001:DB8:3::1

Step 1.

Configure the MDT type for the MVPN.

Based on the test topology, PE-3 is configured as sender-only for the MVPN.
*A:PE-3>config>service>vprn# info
--------------------------------------------description "RSVP based MVPN"
<snip>
interface "int-mcast-source" create
description "10G STC port 12/2"
address 172.16.3.2/30
ipv6
address 2001:DB8:3::2/127
exit
sap 3/1/10:3.1001 create
exit
exit
pim
no ipv6-multicast-disable
apply-to all
rp
static
exit
bsr-candidate
shutdown
exit
rp-candidate
shutdown
exit
exit
no shutdown
exit
mvpn
auto-discovery default
c-mcast-signaling bgp
mdt-type sender-only
provider-tunnel
inclusive
rsvp
lsp-template "mvpn-p2mp-lsp"
no shutdown
exit
exit
exit
vrf-target unicast
exit

Page 1476

Advanced Configuration Guide

Multicast VPN: Sender-Only, Receiver-Only

exit
service-name "RSVP based MVPN"
<snip>

Based on the test topology PE-2 is configured as receiver-only for the MVPN. PE-2 has also
static joins for the IPv4 and IPv6 multicast groups:

group 232.0.0.1,source 172.16.3.1

group FF3E::8000:1, source 2001:DB8:3::1

*A:PE-2>config>service>vprn# info
---------------------------------------------description "RSVP based MVPN"
<snip>
interface "int-mcast-receiver" create
description "10G STC port 10/2"
address 172.16.2.2/30
ipv6
address 2001:DB8:2::2/127
exit
sap 2/2/1:3.1001 create
exit
exit
igmp
interface "int-mcast-receiver"
static
group 232.0.0.1
source 172.16.3.1
exit
exit
no shutdown
exit
no shutdown
exit
mld
interface "int-mcast-receiver"
static
group FF3E::8000:1
source 2001:DB8:3::1
exit
exit
no shutdown
exit
no shutdown
exit
pim
no ipv6-multicast-disable
rp
static
exit
bsr-candidate
shutdown
exit
rp-candidate
shutdown
exit

Advanced Configuration Guide

Page 1477

Configuration

exit
no shutdown
exit
mvpn
auto-discovery default
c-mcast-signaling bgp
mdt-type receiver-only
provider-tunnel
inclusive
rsvp
lsp-template "mvpn-p2mp-lsp"
no shutdown
exit
exit
exit
vrf-target unicast
exit
exit
service-name "RSVP based MVPN"
<snip>

Based on the test topology, PE-1 is configured as sender-receiver (default) for the MVPN. PE-1
has also static joins for the IPv4 and IPv6 multicast groups:

group 232.0.0.1,source 172.16.3.1

group FF3E::8000:1, source 2001:DB8:3::1

*A:PE-1>config>service>vprn# info
---------------------------------------------description "RSVP based MVPN"
<snip>
interface "int-mcast-receiver" create
description "10G STC port 10/1"
address 172.16.1.2/30
ipv6
address 2001:DB8:1::2/127
exit
sap 2/1/1:3.1001 create
exit
exit
igmp
interface "int-mcast-receiver"
static
group 232.0.0.1
source 172.16.3.1
exit
exit
no shutdown
exit
no shutdown
exit
mld
interface "int-mcast-receiver"
static
group FF3E::8000:1
source 2001:DB8:3::1

Page 1478

Advanced Configuration Guide

Multicast VPN: Sender-Only, Receiver-Only

exit
exit
no shutdown
exit
no shutdown
exit
pim
no ipv6-multicast-disable
apply-to all
rp
static
exit
bsr-candidate
shutdown
exit
rp-candidate
shutdown
exit
exit
no shutdown
exit
mvpn
auto-discovery default
c-mcast-signaling bgp
provider-tunnel
inclusive
rsvp
lsp-template "mvpn-p2mp-lsp"
no shutdown
exit
exit
exit
vrf-target unicast
exit
exit
service-name "RSVP based MVPN"
no shutdown

Note: The PIM instance must be shutdown before the mdt-type is modified; this leads to a
multicast service disruption. Trying to change the mdt-type with PIM instance active will result in
the message below being displayed.
*A:PE-1>config>service>vprn>mvpn# mdt-type sender-only
MINOR: PIM #1100 PIM instance must be shutdown before changing this configuration

Advanced Configuration Guide

Page 1479

Configuration

RSVP-Based MVPN Verification and Debugging


MDT-Type Verification
The status of the MVPN can be checked using the show>router <service-number> mvpn
command:
PE-1 output:
A:PE-1# show router 1 mvpn
===============================================================================
MVPN 1 configuration data
===============================================================================
signaling
: Bgp
auto-discovery
: Default
UMH Selection
: Highest-Ip
intersite-shared
: Enabled
vrf-import
: N/A
vrf-export
: N/A
vrf-target
: unicast
C-Mcast Import RT : target:192.0.2.1:3
ipmsi
i-pmsi P2MP AdmSt
i-pmsi Tunnel Name
enable-bfd-root
Mdt-type

:
:
:
:
:

rsvp mvpn-p2mp-lsp
Up
mvpn-p2mp-lsp-1-73741
false
enable-bfd-leaf
sender-receiver

: false

s-pmsi
: none
data-delay-interval: 3 seconds
enable-asm-mdt
: N/A
===============================================================================

PE-2 output:
A:PE-2# show router 1 mvpn
===============================================================================
MVPN 1 configuration data
===============================================================================
signaling
: Bgp
auto-discovery
: Default
UMH Selection
: Highest-Ip
intersite-shared
: Enabled
vrf-import
: N/A
vrf-export
: N/A
vrf-target
: unicast
C-Mcast Import RT : target:192.0.2.2:1905
ipmsi
i-pmsi P2MP AdmSt
i-pmsi Tunnel Name
enable-bfd-root
Mdt-type

:
:
:
:
:

rsvp mvpn-p2mp-lsp
Up
mpls-virt-if-640323
false
receiver-only

enable-bfd-leaf

: false

s-pmsi
: none
data-delay-interval: 3 seconds

Page 1480

Advanced Configuration Guide

Multicast VPN: Sender-Only, Receiver-Only

enable-asm-mdt
: N/A
===============================================================================

PE-3 output:
*A:PE-3# show router 1 mvpn
===============================================================================
MVPN 1 configuration data
===============================================================================
signaling
: Bgp
auto-discovery
: Default
UMH Selection
: Highest-Ip
intersite-shared
: Enabled
vrf-import
: N/A
vrf-export
: N/A
vrf-target
: unicast
C-Mcast Import RT : target:192.0.2.3:2086
ipmsi
i-pmsi P2MP AdmSt
i-pmsi Tunnel Name
enable-bfd-root
Mdt-type

:
:
:
:
:

rsvp mvpn-p2mp-lsp
Up
mvpn-p2mp-lsp-1-73741
false
enable-bfd-leaf
sender-only

: false

s-pmsi
: none
data-delay-interval: 3 seconds
enable-asm-mdt
: N/A
===============================================================================

Advanced Configuration Guide

Page 1481

Configuration

BGP Verification and Debugging


When the MDT type is changed, the BGP signaling is slightly modified in order to achieve the
signaling optimization.
The PE router does not include the PMSI part in Intra-AD BGP messages when the MVPN is
configured with mdt-type as receiver-only. The message flow is presented in Figure 133.

Mcast
Source

Sender Only

Receiver Only

SR-3

SR-2

VRF

VRF

Receiver
BGP Intra-AD (no PMSI)
BGP Intra-AD
P2mp RSVP Setup
BGP Source-Join
BGP Source-AD
al_0331a

Figure 133: RSVP-Based BGP Message Flow Between PE-2 and PE-3

The BGP debug output below is taken from PE-2 and demonstrates the message flow between PE2 and PE-3 for MVPN-IPv4 address family.
Note that there is no PMSI part in debug message 62, but the PMSI part is present in message 57,
which is sent by PE-3 (sender-only).
57 2013/10/21 16:58:09.43 CEST MINOR: DEBUG #2001 Base Peer 1: 192.0.2.3
"Peer 1: 192.0.2.3: UPDATE
Peer 1: 192.0.2.3 - Received BGP UPDATE:
Withdrawn Length = 0
Total Path Attr Length = 86
Flag: 0x90 Type: 14 Len: 23 Multiprotocol Reachable NLRI:
Address Family MVPN_IPV4
NextHop len 4 NextHop 192.0.2.3
Type: Intra-AD Len: 12 RD: 64500:103 Orig: 192.0.2.3
Flag: 0x40 Type: 1 Len: 1 Origin: 0
Flag: 0x40 Type: 2 Len: 0 AS Path:
Flag: 0x80 Type: 4 Len: 4 MED: 0
Flag: 0x40 Type: 5 Len: 4 Local Preference: 100
Flag: 0xc0 Type: 8 Len: 4 Community:
no-export
Flag: 0xc0 Type: 16 Len: 8 Extended Community:
target:64500:1

Page 1482

Advanced Configuration Guide

Multicast VPN: Sender-Only, Receiver-Only

Flag: 0xc0 Type: 22 Len: 17 PMSI:


Tunnel-type RSVP-TE P2MP LSP (1)
Flags [Leaf not required]
MPLS Label 0
P2MP-ID 0x7919, Tunnel-ID: 62688, Extended-Tunnel-ID 192.0.2.3
"
62 2013/10/21 16:58:10.35 CEST MINOR: DEBUG #2001 Base Peer 1: 192.0.2.3
"Peer 1: 192.0.2.3: UPDATE
Peer 1: 192.0.2.3 - Send BGP UPDATE:
Withdrawn Length = 0
Total Path Attr Length = 66
Flag: 0x90 Type: 14 Len: 23 Multiprotocol Reachable NLRI:
Address Family MVPN_IPV4
NextHop len 4 NextHop 192.0.2.2
Type: Intra-AD Len: 12 RD: 64500:102 Orig: 192.0.2.2
Flag: 0x40 Type: 1 Len: 1 Origin: 0
Flag: 0x40 Type: 2 Len: 0 AS Path:
Flag: 0x80 Type: 4 Len: 4 MED: 0
Flag: 0x40 Type: 5 Len: 4 Local Preference: 100
Flag: 0xc0 Type: 8 Len: 4 Community:
no-export
Flag: 0xc0 Type: 16 Len: 8 Extended Community:
target:64500:1
"
67 2013/10/21 16:58:10.65 CEST MINOR: DEBUG #2001 Base Peer 1: 192.0.2.3
"Peer 1: 192.0.2.3: UPDATE
Peer 1: 192.0.2.3 - Send BGP UPDATE:
Withdrawn Length = 0
Total Path Attr Length = 69
Flag: 0x90 Type: 14 Len: 33 Multiprotocol Reachable NLRI:
Address Family MVPN_IPV4
NextHop len 4 NextHop 192.0.2.2
Type: Source-Join Len:22 RD: 64500:103 SrcAS: 64500 Src: 172.16.3.1
Grp: 232.0.0.1
Flag: 0x40 Type: 1 Len: 1 Origin: 0
Flag: 0x40 Type: 2 Len: 0 AS Path:
Flag: 0x80 Type: 4 Len: 4 MED: 0
Flag: 0x40 Type: 5 Len: 4 Local Preference: 100
Flag: 0xc0 Type: 16 Len: 8 Extended Community:
target:192.0.2.3:2086
"
72 2013/10/21 16:58:11.31 CEST MINOR: DEBUG #2001 Base Peer 1: 192.0.2.3
"Peer 1: 192.0.2.3: UPDATE
Peer 1: 192.0.2.3 - Received BGP UPDATE:
Withdrawn Length = 0
Total Path Attr Length = 65
Flag: 0x90 Type: 14 Len: 29 Multiprotocol Reachable NLRI:
Address Family MVPN_IPV4
NextHop len 4 NextHop 192.0.2.3
Type: Source-AD Len: 18 RD: 64500:103 Src: 172.16.3.1 Grp: 232.0.0.1
Flag: 0x40 Type: 1 Len: 1 Origin: 0
Flag: 0x40 Type: 2 Len: 0 AS Path:
Flag: 0x80 Type: 4 Len: 4 MED: 0
Flag: 0x40 Type: 5 Len: 4 Local Preference: 100
Flag: 0xc0 Type: 16 Len: 8 Extended Community:
target:64500:1

Advanced Configuration Guide

Page 1483

Configuration

"

Similar behavior is observed for IPv6 multicast. The BGP debug output below is taken from PE-2
and demonstrates the message flow between PE-2 and PE-3 for the MVPN-IPv6 address family.
Note that there is no PMSI part in debug message 63.
58 2013/10/21 16:58:09.42 CEST MINOR: DEBUG #2001 Base Peer 1: 192.0.2.3
"Peer 1: 192.0.2.3: UPDATE
Peer 1: 192.0.2.3 - Received BGP UPDATE:
Withdrawn Length = 0
Total Path Attr Length = 86
Flag: 0x90 Type: 14 Len: 23 Multiprotocol Reachable NLRI:
Address Family MVPN_IPV6
NextHop len 4 NextHop 192.0.2.3
Type: Intra-AD Len: 12 RD: 64500:103 Orig: 192.0.2.3
Flag: 0x40 Type: 1 Len: 1 Origin: 0
Flag: 0x40 Type: 2 Len: 0 AS Path:
Flag: 0x80 Type: 4 Len: 4 MED: 0
Flag: 0x40 Type: 5 Len: 4 Local Preference: 100
Flag: 0xc0 Type: 8 Len: 4 Community:
no-export
Flag: 0xc0 Type: 16 Len: 8 Extended Community:
target:64500:1
Flag: 0xc0 Type: 22 Len: 17 PMSI:
Tunnel-type RSVP-TE P2MP LSP (1)
Flags [Leaf not required]
MPLS Label 0
P2MP-ID 0x7919, Tunnel-ID: 62688, Extended-Tunnel-ID 192.0.2.3
"
63 2013/10/21 16:58:10.34 CEST MINOR: DEBUG #2001 Base Peer 1: 192.0.2.3
"Peer 1: 192.0.2.3: UPDATE
Peer 1: 192.0.2.3 - Send BGP UPDATE:
Withdrawn Length = 0
Total Path Attr Length = 66
Flag: 0x90 Type: 14 Len: 23 Multiprotocol Reachable NLRI:
Address Family MVPN_IPV6
NextHop len 4 NextHop 192.0.2.2
Type: Intra-AD Len: 12 RD: 64500:102 Orig: 32.1.13.184
Flag: 0x40 Type: 1 Len: 1 Origin: 0
Flag: 0x40 Type: 2 Len: 0 AS Path:
Flag: 0x80 Type: 4 Len: 4 MED: 0
Flag: 0x40 Type: 5 Len: 4 Local Preference: 100
Flag: 0xc0 Type: 8 Len: 4 Community:
no-export
Flag: 0xc0 Type: 16 Len: 8 Extended Community:
target:64500:1
"

66 2013/10/21 16:58:10.65 CEST MINOR: DEBUG #2001 Base Peer 1: 192.0.2.3


"Peer 1: 192.0.2.3: UPDATE
Peer 1: 192.0.2.3 - Send BGP UPDATE:
Withdrawn Length = 0
Total Path Attr Length = 93
Flag: 0x90 Type: 14 Len: 57 Multiprotocol Reachable NLRI:

Page 1484

Advanced Configuration Guide

Multicast VPN: Sender-Only, Receiver-Only

Address Family MVPN_IPV6


NextHop len 4 NextHop 192.0.2.2
Type: Source-Join Len: 46 RD: 64500:103 SrcAS: 64500 Src: 2001:DB8:3
::1 Grp: FF3E::8000:1
Flag: 0x40 Type: 1 Len: 1 Origin: 0
Flag: 0x40 Type: 2 Len: 0 AS Path:
Flag: 0x80 Type: 4 Len: 4 MED: 0
Flag: 0x40 Type: 5 Len: 4 Local Preference: 100
Flag: 0xc0 Type: 16 Len: 8 Extended Community:
target:192.0.2.3:2086
"
71 2013/10/21 16:58:11.30 CEST MINOR: DEBUG #2001 Base Peer 1: 192.0.2.3
"Peer 1: 192.0.2.3: UPDATE
Peer 1: 192.0.2.3 - Received BGP UPDATE:
Withdrawn Length = 0
Total Path Attr Length = 89
Flag: 0x90 Type: 14 Len: 53 Multiprotocol Reachable NLRI:
Address Family MVPN_IPV6
NextHop len 4 NextHop 192.0.2.3
Type: Source-AD Len: 42 RD: 64500:103 Src: 2001:DB8:3::1 Grp: FF3E
::8000:1
Flag: 0x40 Type: 1 Len: 1 Origin: 0
Flag: 0x40 Type: 2 Len: 0 AS Path:
Flag: 0x80 Type: 4 Len: 4 MED: 0
Flag: 0x40 Type: 5 Len: 4 Local Preference: 100
Flag: 0xc0 Type: 16 Len: 8 Extended Community:
target:64500:1
"

The PE router does not change its BGP behavior when the MVPN is configured with mdt-type as
sender-only. The message flow is presented in Figure 134.

Mcast
Source

Sender Only

Sender + Receiver

SR-3

SR-1

VRF

VRF

Receiver
BGP Intra-AD
P2mp RSVP Setup
BGP Source-Join
BGP Source-AD
al_0331

Figure 134: RSVP-Based BGP Message Flow Between PE-1 and PE-3

Advanced Configuration Guide

Page 1485

Configuration

The BGP debug output below is taken from PE-1 and demonstrates the message flow between PE1 and PE-3 for the MVPN-IPv4 address family.
Note that the PMSI part is present in debug message 107, which is sent by PE-3 (sender-only).
107 2013/10/21 16:58:09.43 CEST MINOR: DEBUG #2001 Base Peer 1: 192.0.2.3
"Peer 1: 192.0.2.3: UPDATE
Peer 1: 192.0.2.3 - Received BGP UPDATE:
Withdrawn Length = 0
Total Path Attr Length = 86
Flag: 0x90 Type: 14 Len: 23 Multiprotocol Reachable NLRI:
Address Family MVPN_IPV4
NextHop len 4 NextHop 192.0.2.3
Type: Intra-AD Len: 12 RD: 64500:103 Orig: 192.0.2.3
Flag: 0x40 Type: 1 Len: 1 Origin: 0
Flag: 0x40 Type: 2 Len: 0 AS Path:
Flag: 0x80 Type: 4 Len: 4 MED: 0
Flag: 0x40 Type: 5 Len: 4 Local Preference: 100
Flag: 0xc0 Type: 8 Len: 4 Community:
no-export
Flag: 0xc0 Type: 16 Len: 8 Extended Community:
target:64500:1
Flag: 0xc0 Type: 22 Len: 17 PMSI:
Tunnel-type RSVP-TE P2MP LSP (1)
Flags [Leaf not required]
MPLS Label 0
P2MP-ID 0x7919, Tunnel-ID: 62688, Extended-Tunnel-ID 192.0.2.3
"
109 2013/10/21 16:58:10.35 CEST MINOR: DEBUG #2001 Base Peer 1: 192.0.2.3
"Peer 1: 192.0.2.3: UPDATE
Peer 1: 192.0.2.3 - Send BGP UPDATE:
Withdrawn Length = 0
Total Path Attr Length = 86
Flag: 0x90 Type: 14 Len: 23 Multiprotocol Reachable NLRI:
Address Family MVPN_IPV4
NextHop len 4 NextHop 192.0.2.1
Type: Intra-AD Len: 12 RD: 64500:101 Orig: 192.0.2.1
Flag: 0x40 Type: 1 Len: 1 Origin: 0
Flag: 0x40 Type: 2 Len: 0 AS Path:
Flag: 0x80 Type: 4 Len: 4 MED: 0
Flag: 0x40 Type: 5 Len: 4 Local Preference: 100
Flag: 0xc0 Type: 8 Len: 4 Community:
no-export
Flag: 0xc0 Type: 16 Len: 8 Extended Community:
target:64500:1
Flag: 0xc0 Type: 22 Len: 17 PMSI:
Tunnel-type RSVP-TE P2MP LSP (1)
Flags [Leaf not required]
MPLS Label 0
P2MP-ID 0x7919, Tunnel-ID: 62342, Extended-Tunnel-ID 192.0.2.1
"
116 2013/10/21 16:58:11.30 CEST MINOR: DEBUG #2001 Base Peer 1: 192.0.2.3
"Peer 1: 192.0.2.3: UPDATE
Peer 1: 192.0.2.3 - Send BGP UPDATE:
Withdrawn Length = 0
Total Path Attr Length = 69

Page 1486

Advanced Configuration Guide

Multicast VPN: Sender-Only, Receiver-Only

Flag: 0x90 Type: 14 Len: 33 Multiprotocol Reachable NLRI:


Address Family MVPN_IPV4
NextHop len 4 NextHop 192.0.2.1
Type: Source-Join Len:22 RD: 64500:103 SrcAS: 64500 Src: 172.16.3.1
Grp: 232.0.0.1
Flag: 0x40 Type: 1 Len: 1 Origin: 0
Flag: 0x40 Type: 2 Len: 0 AS Path:
Flag: 0x80 Type: 4 Len: 4 MED: 0
Flag: 0x40 Type: 5 Len: 4 Local Preference: 100
Flag: 0xc0 Type: 16 Len: 8 Extended Community:
target:192.0.2.3:2086
"
120 2013/10/21 16:58:11.31 CEST MINOR: DEBUG #2001 Base Peer 1: 192.0.2.3
"Peer 1: 192.0.2.3: UPDATE
Peer 1: 192.0.2.3 - Received BGP UPDATE:
Withdrawn Length = 0
Total Path Attr Length = 65
Flag: 0x90 Type: 14 Len: 29 Multiprotocol Reachable NLRI:
Address Family MVPN_IPV4
NextHop len 4 NextHop 192.0.2.3
Type: Source-AD Len: 18 RD: 64500:103 Src: 172.16.3.1 Grp: 232.0.0.1
Flag: 0x40 Type: 1 Len: 1 Origin: 0
Flag: 0x40 Type: 2 Len: 0 AS Path:
Flag: 0x80 Type: 4 Len: 4 MED: 0
Flag: 0x40 Type: 5 Len: 4 Local Preference: 100
Flag: 0xc0 Type: 16 Len: 8 Extended Community:
target:64500:1
"

Similar behavior is observed for IPv6 multicast.


The BGP debug output below is taken from PE-1 and demonstrates the message flow between PE1 and PE-3 for the MVPN-IPv6 address family.
Note: The PMSI part is present in debug message 108, which is sent by PE-3 (sender-only).
108 2013/10/21 16:58:09.43 CEST MINOR: DEBUG #2001 Base Peer 1: 192.0.2.3
"Peer 1: 192.0.2.3: UPDATE
Peer 1: 192.0.2.3 - Received BGP UPDATE:
Withdrawn Length = 0
Total Path Attr Length = 86
Flag: 0x90 Type: 14 Len: 23 Multiprotocol Reachable NLRI:
Address Family MVPN_IPV6
NextHop len 4 NextHop 192.0.2.3
Type: Intra-AD Len: 12 RD: 64500:103 Orig: 192.0.2.3
Flag: 0x40 Type: 1 Len: 1 Origin: 0
Flag: 0x40 Type: 2 Len: 0 AS Path:
Flag: 0x80 Type: 4 Len: 4 MED: 0
Flag: 0x40 Type: 5 Len: 4 Local Preference: 100
Flag: 0xc0 Type: 8 Len: 4 Community:
no-export
Flag: 0xc0 Type: 16 Len: 8 Extended Community:
target:64500:1
Flag: 0xc0 Type: 22 Len: 17 PMSI:
Tunnel-type RSVP-TE P2MP LSP (1)
Flags [Leaf not required]

Advanced Configuration Guide

Page 1487

Configuration

MPLS Label 0
P2MP-ID 0x7919, Tunnel-ID: 62688, Extended-Tunnel-ID 192.0.2.3
"
110 2013/10/21 16:58:10.34 CEST MINOR: DEBUG #2001 Base Peer 1: 192.0.2.3
"Peer 1: 192.0.2.3: UPDATE
Peer 1: 192.0.2.3 - Send BGP UPDATE:
Withdrawn Length = 0
Total Path Attr Length = 86
Flag: 0x90 Type: 14 Len: 23 Multiprotocol Reachable NLRI:
Address Family MVPN_IPV6
NextHop len 4 NextHop 192.0.2.1
Type: Intra-AD Len: 12 RD: 64500:101 Orig: 192.0.2.1
Flag: 0x40 Type: 1 Len: 1 Origin: 0
Flag: 0x40 Type: 2 Len: 0 AS Path:
Flag: 0x80 Type: 4 Len: 4 MED: 0
Flag: 0x40 Type: 5 Len: 4 Local Preference: 100
Flag: 0xc0 Type: 8 Len: 4 Community:
no-export
Flag: 0xc0 Type: 16 Len: 8 Extended Community:
target:64500:1
Flag: 0xc0 Type: 22 Len: 17 PMSI:
Tunnel-type RSVP-TE P2MP LSP (1)
Flags [Leaf not required]
MPLS Label 0
P2MP-ID 0x7919, Tunnel-ID: 62342, Extended-Tunnel-ID 192.0.2.1
"
118 2013/10/21 16:58:11.31 CEST MINOR: DEBUG #2001 Base Peer 1: 192.0.2.3
"Peer 1: 192.0.2.3: UPDATE
Peer 1: 192.0.2.3 - Send BGP UPDATE:
Withdrawn Length = 0
Total Path Attr Length = 93
Flag: 0x90 Type: 14 Len: 57 Multiprotocol Reachable NLRI:
Address Family MVPN_IPV6
NextHop len 4 NextHop 192.0.2.1
Type: Source-Join Len: 46 RD: 64500:103 SrcAS: 64500 Src: 2001:DB8:3
::1 Grp: FF3E::8000:1
Flag: 0x40 Type: 1 Len: 1 Origin: 0
Flag: 0x40 Type: 2 Len: 0 AS Path:
Flag: 0x80 Type: 4 Len: 4 MED: 0
Flag: 0x40 Type: 5 Len: 4 Local Preference: 100
Flag: 0xc0 Type: 16 Len: 8 Extended Community:
target:192.0.2.3:2086
"
121 2013/10/21 16:58:11.31 CEST MINOR: DEBUG #2001 Base Peer 1: 192.0.2.3
"Peer 1: 192.0.2.3: UPDATE
Peer 1: 192.0.2.3 - Received BGP UPDATE:
Withdrawn Length = 0
Total Path Attr Length = 89
Flag: 0x90 Type: 14 Len: 53 Multiprotocol Reachable NLRI:
Address Family MVPN_IPV6
NextHop len 4 NextHop 192.0.2.3
Type: Source-AD Len: 42 RD: 64500:103 Src: 2001:DB8:3::1 Grp: FF3E
::8000:1
Flag: 0x40 Type: 1 Len: 1 Origin: 0
Flag: 0x40 Type: 2 Len: 0 AS Path:
Flag: 0x80 Type: 4 Len: 4 MED: 0

Page 1488

Advanced Configuration Guide

Multicast VPN: Sender-Only, Receiver-Only

Flag: 0x40 Type: 5 Len: 4 Local Preference: 100


Flag: 0xc0 Type: 16 Len: 8 Extended Community:
target:64500:1
"

The BGP routing table of each router is populated accordingly.


PE-1 (sender-receiver) has two Intra-Ad messages from PE-2 and PE-3 and one Source-Ad from
PE-3.
*A:PE-1# show router bgp routes mvpn-ipv4
===============================================================================
BGP Router ID:192.0.2.1
AS:64500
Local AS:64500
===============================================================================
Legend Status codes : u - used, s - suppressed, h - history, d - decayed, * - valid
Origin codes : i - IGP, e - EGP, ? - incomplete, > - best, b - backup
===============================================================================
BGP MVPN-IPv4 Routes
===============================================================================
Flag RouteType
OriginatorIP
LocalPref
MED
RD
SourceAS
Label
Nexthop
SourceIP
As-Path
GroupIP
------------------------------------------------------------------------------u*>i Intra-Ad
192.0.2.2
100
0
64500:102
192.0.2.2
No As-Path
u*>i Intra-Ad
192.0.2.3
100
0
64500:103
192.0.2.3
No As-Path
u*>i Source-Ad
100
0
64500:103
192.0.2.3
172.16.3.1
No As-Path
232.0.0.1
------------------------------------------------------------------------------Routes : 3
===============================================================================

PE-2 (receiver-only) has two Intra-Ad messages from PE-1 and PE-3 and one Source-Ad from
PE-3.
*A:PE-2#
show router bgp routes mvpn-ipv4
===============================================================================
BGP Router ID:192.0.2.2
AS:64500
Local AS:64500
===============================================================================
Legend Status codes : u - used, s - suppressed, h - history, d - decayed, * - valid
Origin codes : i - IGP, e - EGP, ? - incomplete, > - best, b - backup
===============================================================================
BGP MVPN-IPv4 Routes

Advanced Configuration Guide

Page 1489

Configuration

===============================================================================
Flag RouteType
OriginatorIP
LocalPref
MED
RD
SourceAS
Label
Nexthop
SourceIP
As-Path
GroupIP
------------------------------------------------------------------------------u*>i Intra-Ad
192.0.2.1
100
0
64500:101
192.0.2.1
No As-Path
u*>i Intra-Ad
192.0.2.3
100
0
64500:103
192.0.2.3
No As-Path
u*>i Source-Ad
100
0
64500:103
192.0.2.3
172.16.3.1
No As-Path
232.0.0.1
------------------------------------------------------------------------------Routes : 3
===============================================================================

PE-3 (sender-only) has two Intra-Ad and two Source-Join messages from PE-1 and PE-2.
*A:PE-3#
show router bgp routes mvpn-ipv4
===============================================================================
BGP Router ID:192.0.2.3
AS:64500
Local AS:64500
===============================================================================
Legend Status codes : u - used, s - suppressed, h - history, d - decayed, * - valid
Origin codes : i - IGP, e - EGP, ? - incomplete, > - best, b - backup
===============================================================================
BGP MVPN-IPv4 Routes
===============================================================================
Flag RouteType
OriginatorIP
LocalPref
MED
RD
SourceAS
Label
Nexthop
SourceIP
As-Path
GroupIP
------------------------------------------------------------------------------u*>i Intra-Ad
192.0.2.1
100
0
64500:101
192.0.2.1
No As-Path
u*>i Intra-Ad
192.0.2.2
100
0
64500:102
192.0.2.2
No As-Path
u*>i Source-Join
100
0
64500:103
64500
192.0.2.1
172.16.3.1
No As-Path
232.0.0.1
*>i
Source-Join
100
0
64500:103
64500
192.0.2.2
172.16.3.1
No As-Path
232.0.0.1
------------------------------------------------------------------------------Routes : 4

Page 1490

Advanced Configuration Guide

Multicast VPN: Sender-Only, Receiver-Only

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

Advanced Configuration Guide

Page 1491

Configuration

RSVP Verification and Debugging


When BGP intra-AD messages are exchanged every PE starts to build multicast tunnels based on
the following criteria:

PE nodes which are configured as sender-only for a given MVPN do not join P2MP LSPs
from other PEs in this MVPN.

PE nodes which are configured as receiver-only for a given MVPN do not originate P2MP
LSPs to other PEs in this MVPN.

The RSVP session can be checked with the show>router>rsvp>session command:


PE-1 (192.0.2.1) has two originating LSPs towards PE-2 (192.0.2.2) and PE-3 (192.0.2.3) and one
incoming LSP from PE-3 (mdt-type sender-only).
*A:PE-1#show router rsvp session
===============================================================================
RSVP Sessions
===============================================================================
From
To
Tunnel LSP
Name
State
ID
ID
------------------------------------------------------------------------------192.0.2.1
192.0.2.2
62342 52224 mvpn-p2mp-lsp-1-73741::* Up
192.0.2.1
192.0.2.3
62342 52224 mvpn-p2mp-lsp-1-73741::* Up
192.0.2.3
192.0.2.1
62688 39424 mvpn-p2mp-lsp-1-73741::* Up

PE-2 (192.0.2.2) has two incoming LSPs from PE-1 (192.0.2.1) and PE-3 (192.0.2.3) and no
originating LSPs due to the fact that PE-2 has mdt-type receiver-only.
*A:PE-2#show router rsvp session
===============================================================================
RSVP Sessions
===============================================================================
From
To
Tunnel LSP
Name
State
ID
ID
------------------------------------------------------------------------------192.0.2.1
192.0.2.2
62342 52224 mvpn-p2mp-lsp-1-73741::* Up
192.0.2.3
192.0.2.2
62688 39424 mvpn-p2mp-lsp-1-73741::* Up

PE-3 (192.0.2.3) has two originating LSPs towards PE-2 (192.0.2.2) and PE-1 (192.0.2.1) and one
incoming LSP from PE-1 (mdt-type sender-receiver).
Theoretically there is no need for the LSP from PE-1 towards PE-3 as PE-3 is a sender-only; this
minor limitation should be taken into account during planning phase.
*A:PE-3#show router rsvp session
===============================================================================
RSVP Sessions
===============================================================================
From
To
Tunnel LSP
Name
State

Page 1492

Advanced Configuration Guide

Multicast VPN: Sender-Only, Receiver-Only

ID
ID
------------------------------------------------------------------------------192.0.2.1
192.0.2.3
62342 52224 mvpn-p2mp-lsp-1-73741::* Up
192.0.2.3
192.0.2.1
62688 39424 mvpn-p2mp-lsp-1-73741::* Up
192.0.2.3
192.0.2.2
62688 39424 mvpn-p2mp-lsp-1-73741::* Up

Additional details about originating P2MP paths can be found using the following command:
show>router>mpls p2mp-lsp <lsp name> p2mp-instance <service number> s2l
PE-1 output:
*A:PE-1# show router mpls p2mp-lsp "mvpn-p2mp-lsp-1-73741" p2mp-instance "1" s2l
===============================================================================
MPLS LSP mvpn-p2mp-lsp-1-73741 S2L
===============================================================================
------------------------------------------------------------------------------LSP Name
: mvpn-p2mp-lsp-1-73741
P2MP ID
: 1
Adm State
: Up
Oper State : Up
P2MPInstance: 1
Inst-type
: Primary
Adm State
: Up
Oper State : PartialInService
------------------------------------------------------------------------------S2l Name
To
Next Hop
Adm Opr
------------------------------------------------------------------------------mvpn-p2mp-path
192.0.2.2
192.168.12.1
Up
Up
mvpn-p2mp-path
192.0.2.3
192.168.13.1
Up
Up

PE-2 output:
*A:PE-2# show router mpls p2mp-lsp
===============================================================================
MPLS P2MP LSPs (Originating)
===============================================================================
LSP Name
Tun
Fastfail Adm Opr
Id
Config
------------------------------------------------------------------------------No Matching Entries Found
===============================================================================

PE-3 output:
A:PE-# show router mpls p2mp-lsp "mvpn-p2mp-lsp-1-73741" p2mp-instance "1" s2l
===============================================================================
MPLS LSP mvpn-p2mp-lsp-1-73741 S2L
===============================================================================
------------------------------------------------------------------------------LSP Name
: mvpn-p2mp-lsp-1-73741
P2MP ID
: 1
Adm State
: Up
Oper State : Up
P2MPInstance: 1
Inst-type
: Primary
Adm State
: Up
Oper State : PartialInService
------------------------------------------------------------------------------S2l Name
To
Next Hop
Adm Opr
------------------------------------------------------------------------------mvpn-p2mp-path
192.0.2.1
192.168.13.0
Up
Up

Advanced Configuration Guide

Page 1493

Configuration

mvpn-p2mp-path

Page 1494

192.0.2.2

192.168.23.0

Up

Up

Advanced Configuration Guide

Multicast VPN: Sender-Only, Receiver-Only

Multicast Stream Verification


The status of the multicast groups/streams can be verified using show>router <sid>>pim group
detail ipv6 command:
There is an IPv4 receiver connected to PE-1. An I-PMSI is used as the incoming interface and the
physical interface where the receiver is connected is used as the outgoing interface.
A:PE-1#show router 1 pim group detail
===============================================================================
PIM Source Group ipv4
===============================================================================
Group Address
: 232.0.0.1
Source Address
: 172.16.3.1
RP Address
: 0
Advt Router
: 192.0.2.3
Flags
:
Type
: (S,G)
MRIB Next Hop
: 192.0.2.3
<snip>
Rpf Neighbor
: 192.0.2.3
Incoming Intf
: mpls-if-73743
Outgoing Intf List : int-mcast-receiver
Curr Fwding Rate
<snip>

: 85636.0 kbps

There is an IPv4 receiver connected to PE-2. An I-PMSI is used as the incoming interface and the
physical interface where the receiver is connected is used as the outgoing interface.
A:PE-2# show router 1 pim group detail
===============================================================================
PIM Source Group ipv4
===============================================================================
Group Address
: 232.0.0.1
Source Address
: 172.16.3.1
RP Address
: 0
Advt Router
: 192.0.2.3
Flags
:
Type
: (S,G)
MRIB Next Hop
: 192.0.2.3
<snip>
Rpf Neighbor
: 192.0.2.3
Incoming Intf
: mpls-if-73753
Outgoing Intf List : int-mcast-receiver
Curr Fwding Rate
<snip>

: 85624.6 kbps

There is an IPv4 sender connected to PE-3. An I-PMSI is used as the outgoing interface and the
physical interface where sender is connected is used as the incoming interface.
A:PE-3#show router 1 pim group detail

Advanced Configuration Guide

Page 1495

Configuration

===============================================================================
PIM Source Group ipv4
===============================================================================
Group Address
: 232.0.0.1
Source Address
: 172.16.3.1
RP Address
: 0
Advt Router
: 192.0.2.3
Flags
:
Type
: (S,G)
MRIB Next Hop
: 172.16.3.1
<snip>
Rpf Neighbor
: 172.16.3.1
Incoming Intf
: int-mcast-source
Outgoing Intf List : mpls-if-73741
Curr Fwding Rate
<snip>

: 85625.0 kbps

Similar behavior is observed for IPv6 multicast.


There is an IPv6 receiver connected to PE-1. An I-PMSI is used as the incoming interface and the
physical interface where the receiver is connected is used as the outgoing interface.
A:PE-1#show router 1 pim group detail ipv6
===============================================================================
PIM Source Group ipv6
===============================================================================
Group Address
: FF3E::8000:1
Source Address
: 2001:DB8:3::1
RP Address
: 0
Advt Router
: 192.0.2.3
Flags
:
Type
: (S,G)
MRIB Next Hop
: 192.0.2.3
<snip>
Rpf Neighbor
: 192.0.2.3
Incoming Intf
: mpls-if-73743
Outgoing Intf List : int-mcast-receiver
Curr Fwding Rate
<snip>

: 2140.5 kbps

There is an IPv6 receiver connected to PE-2. An I-PMSI is used as the incoming interface and the
physical interface where the receiver is connected is used as the outgoing interface.
A:PE-2# show router 1 pim group detail ipv6
===============================================================================
PIM Source Group ipv6
===============================================================================
Group Address
: FF3E::8000:1
Source Address
: 2001:DB8:3::1
RP Address
: 0
Advt Router
: 192.0.2.3
Flags
:
Type
: (S,G)
MRIB Next Hop
: 192.0.2.3
<snip>
Rpf Neighbor
: 192.0.2.3

Page 1496

Advanced Configuration Guide

Multicast VPN: Sender-Only, Receiver-Only

Incoming Intf
: mpls-if-73753
Outgoing Intf List : int-mcast-receiver
Curr Fwding Rate
<snip>

: 2139.4 kbps

There is an IPv6 sender connected to PE-3. An I-PMSI is used as the outgoing interface and the
physical interface where the sender is connected is used as the incoming interface.
A:PE-3# show router 1 pim group detail ipv6
===============================================================================
PIM Source Group ipv6
===============================================================================
Group Address
: FF3E::8000:1
Source Address
: 2001:DB8:3::1
RP Address
: 0
Advt Router
: 192.0.2.3
Flags
:
Type
: (S,G)
MRIB Next Hop
: 2001:DB8:3::1
<snip>
Rpf Neighbor
: 2001:DB8:3::1
Incoming Intf
: int-mcast-source
Outgoing Intf List : mpls-if-73741
Curr Fwding Rate
<snip>

: 2140.5 kbps

Advanced Configuration Guide

Page 1497

Configuration

mLDP-Based MVPN Configuration


Step 0: Configure a basic MVPN using mLDP as a transport protocol for C-multicast groups.

PE-1 and PE-2 have static joins for the IPv4/IPv6 multicast groups:

group 232.0.0.1,source 172.16.3.1

group FF3E::8000:1, source 2001:DB8:3::1

Step 1.

Configure the MDT type for the MVPN.

Based on the test topology PE-3 is configured as sender-only for MVPN:


*A:PE-3>config>service>vprn# info
---------------------------------------------description "mLDP based MVPN"
<snip>
interface "int-mcast-source" create
description "10G STC port 12/2"
address 172.16.3.2/30
ipv6
address 2001:DB8:3::2/126
exit
sap 3/1/10:3.1002 create
exit
exit
pim
no ipv6-multicast-disable
apply-to all
rp
static
exit
bsr-candidate
shutdown
exit
rp-candidate
shutdown
exit
exit
no shutdown
exit
mvpn
auto-discovery default
c-mcast-signaling bgp
mdt-type sender-only
provider-tunnel
inclusive
mldp
no shutdown
exit
exit
exit
vrf-target unicast
exit

Page 1498

Advanced Configuration Guide

Multicast VPN: Sender-Only, Receiver-Only

exit
service-name "mLDP based MVPN"
spoke-sdp 10132 create
exit
no shutdown
<snip>

Based on the test topology, PE-2 is configured as receiver-only for the MVPN. PE-2 has also
static joins for the IPv4 and IPv6 multicast groups:

group 232.0.0.1,source 172.16.3.1

group FF3E::8000:1, source 2001:DB8:3::1

*A:PE-2>config>service>vprn# info
---------------------------------------------description "mLDP based MVPN"
<snip>
interface "int-mcast-receiver" create
description "10G STC port 10/2"
address 172.16.2.2/30
ipv6
address 2001:DB8:2::2/126
exit
sap 2/2/1:3.1002 create
exit
exit
igmp
interface "int-mcast-receiver"
static
group 232.0.0.1
source 172.16.3.1
exit
exit
no shutdown
exit
no shutdown
exit
mld
interface "int-mcast-receiver"
static
group FF3E::8000:1
source 2001:DB8:3::1
exit
exit
no shutdown
exit
no shutdown
exit
pim
no ipv6-multicast-disable
apply-to all
rp
static
exit
bsr-candidate
shutdown

Advanced Configuration Guide

Page 1499

Configuration

exit
rp-candidate
shutdown
exit
exit
no shutdown
exit
mvpn
auto-discovery default
c-mcast-signaling bgp
mdt-type receiver-only
provider-tunnel
inclusive
mldp
no shutdown
exit
exit
exit
vrf-target unicast
exit
exit
service-name "mLDP based MVPN"
<snip>

Based on the test topology, PE-1 is configured as sender-receiver (default) for the MVPN. PE-1
has also static joins for the IPv4 and IPv6 multicast groups:

group 232.0.0.1,source 172.16.3.1

group FF3E::8000:1, source 2001:DB8:3::1

*A:PE-1>config>service>vprn# info
---------------------------------------------description "mLDP based MVPN"
<snip>
interface "int-mcast-receiver" create
description "10G STC port 10/1"
address 172.16.1.2/30
ipv6
address 2001:DB8:1::2/126
exit
sap 2/1/1:3.1002 create
exit
exit
igmp
interface "int-mcast-receiver"
static
group 232.0.0.1
source 172.16.3.1
exit
exit
no shutdown
exit
no shutdown
exit
mld
interface "int-mcast-receiver"

Page 1500

Advanced Configuration Guide

Multicast VPN: Sender-Only, Receiver-Only

static
group FF3E::8000:1
source 2001:DB8:3::1
exit
exit
no shutdown
exit
no shutdown
exit
pim
no ipv6-multicast-disable
apply-to all
rp
static
exit
bsr-candidate
shutdown
exit
rp-candidate
shutdown
exit
exit
no shutdown
exit
mvpn
auto-discovery default
c-mcast-signaling bgp
provider-tunnel
inclusive
mldp
no shutdown
exit
exit
exit
vrf-target unicast
exit
exit
service-name "mLDP based MVPN"

Note: The PIM instance must be shutdown before the mdt-type is modified; this leads to multicast
service disruption. Trying to change mdt-type with the PIM instance active will result in the
message below being displayed.
*A:PE-1>config>service>vprn>mvpn# mdt-type sender-only
MINOR: PIM #1100 PIM instance must be shutdown before changing this configuration

Advanced Configuration Guide

Page 1501

Configuration

mLDP-Based MVPN Verification and Debugging


MDT-Type Verification
The status of the MVPN can be checked using the following command:
show router <service-number> mvpn

PE-1 output:
*A:PE-1# show router 2 mvpn
===============================================================================
MVPN 2 configuration data
===============================================================================
signaling
: Bgp
auto-discovery
: Default
UMH Selection
: Highest-Ip
intersite-shared
: Enabled
vrf-import
: N/A
vrf-export
: N/A
vrf-target
: unicast
C-Mcast Import RT : target:192.0.2.1:2
ipmsi
i-pmsi P2MP AdmSt
i-pmsi Tunnel Name
Mdt-type

:
:
:
:

ldp
Up
mpls-if-73734
sender-receiver

s-pmsi
: none
data-delay-interval: 3 seconds
enable-asm-mdt
: N/A
===============================================================================

PE-2 output:
A:PE-2# show router 2 mvpn
===============================================================================
MVPN 2 configuration data
===============================================================================
signaling
: Bgp
auto-discovery
: Default
UMH Selection
: Highest-Ip
intersite-shared
: Enabled
vrf-import
: N/A
vrf-export
: N/A
vrf-target
: unicast
C-Mcast Import RT : target:192.0.2.2:1906
ipmsi
i-pmsi P2MP AdmSt
i-pmsi Tunnel Name
Mdt-type

:
:
:
:

ldp
Up
mpls-virt-if-640321
receiver-only

s-pmsi
: none
data-delay-interval: 3 seconds
enable-asm-mdt
: N/A
===============================================================================

Page 1502

Advanced Configuration Guide

Multicast VPN: Sender-Only, Receiver-Only

PE-3 output:
*A:PE-3# show router 2 mvpn
===============================================================================
MVPN 2 configuration data
===============================================================================
signaling
: Bgp
auto-discovery
: Default
UMH Selection
: Highest-Ip
intersite-shared
: Enabled
vrf-import
: N/A
vrf-export
: N/A
vrf-target
: unicast
C-Mcast Import RT : target:192.0.2.3:2087
ipmsi
i-pmsi P2MP AdmSt
i-pmsi Tunnel Name
Mdt-type

:
:
:
:

ldp
Up
mpls-if-73752
sender-only

s-pmsi
: none
data-delay-interval: 3 seconds
enable-asm-mdt
: N/A
===============================================================================

BGP Verification and Debugging


When the MDT type is changed the BGP signaling is slightly modified in order to achieve the
signaling optimization. The PE router does not include the PMSI part in Intra-AD BGP messages
when the MVPN is configured with mdt-type as receiver-only.
The message flow is presented in Figure 135.

Mcast
Source

Sender Only

Receiver Only

SR-3

SR-2

VRF

VRF

Receiver
BGP Intra-AD (no PMSI)
BGP Intra-AD
BGP Source-Join
BGP Source-AD
al_0332

Advanced Configuration Guide

Page 1503

Configuration

Figure 135: mLDP-Based BGP Message Flow Between PE-2 and PE-3

In order to demonstrate the BGP message flow sequence the following initialization steps are
taken:
0. Bring down the VPRN service, PIM protocol in a VPRN and IGMP/MLD protocol. As a
result the state of all signaling protocols is cleared.
1. Bring up the VPRN service. BGP exchanges unicast routing information.
2. Bring up the IPv4 PIM protocol. BGP exchanges IPv4 multicast routing information in order
to build the PMSI infrastructure.
3. Bring up IGMP and add a static IGMP join where it is applicable. BGP exchanges IPv4 multicast routing information in order to propagate the multicast traffic to the receiver.
4. Bring up the IPv6 PIM protocol. BGP exchanges IPv6 multicast routing information in order
to build the PMSI infrastructure.
5. Bring up MLD and add a static MLD join where it is applicable. BGP exchanges IPv6 multicast routing information in order to propagate the multicast traffic to the receiver.
The BGP debug below is taken from PE-2 and demonstrates the message flow between PE-2 and
PE-3. VPN-IPv4 and VPN-IPv6 updates are not present in this output.
Step 0: Bring down service and protocols to clear the state of all signalling protocols.
*A:PE-2>config>service>vprn#
*A:PE-2>config>service>vprn#
*A:PE-2>config>service>vprn#
*A:PE-2>config>service>vprn#
*A:PE-2>config>service>vprn#

shutdown
pim shutdown
igmp shutdown
mld shutdown
pim ipv6-multicast-disable

Enable the VPRN service on PE-2. PE-2 immediately receives Intra-AD messages
from PE-3 because the remote VPRN service is already enabled for IPv4 and IPv6
multicast propagation.

Step 1.

*A:PE-2>config>service>vprn# no shutdown
*A:PE-2>config>service>vprn#
4099 2013/10/25 13:43:04.45 CEST MINOR: DEBUG #2001 Base Peer 1: 192.0.2.3
"Peer 1: 192.0.2.3: UPDATE
Peer 1: 192.0.2.3 - Received BGP UPDATE:
Withdrawn Length = 0
Total Path Attr Length = 91
Flag: 0x90 Type: 14 Len: 23 Multiprotocol Reachable NLRI:
Address Family MVPN_IPV4
NextHop len 4 NextHop 192.0.2.3
Type: Intra-AD Len: 12 RD: 64500:203 Orig: 192.0.2.3
Flag: 0x40 Type: 1 Len: 1 Origin: 0
Flag: 0x40 Type: 2 Len: 0 AS Path:
Flag: 0x80 Type: 4 Len: 4 MED: 0
Flag: 0x40 Type: 5 Len: 4 Local Preference: 100

Page 1504

Advanced Configuration Guide

Multicast VPN: Sender-Only, Receiver-Only

Flag: 0xc0 Type: 8 Len: 4 Community:


no-export
Flag: 0xc0 Type: 16 Len: 8 Extended Community:
target:64500:2
Flag: 0xc0 Type: 22 Len: 22 PMSI:
Tunnel-type LDP P2MP LSP (2)
Flags [Leaf not required]
MPLS Label 0
Root-Node 192.0.2.3, LSP-ID 0x2001
"
4100 2013/10/25 13:43:04.46 CEST MINOR: DEBUG #2001 Base Peer 1: 192.0.2.3
"Peer 1: 192.0.2.3: UPDATE
Peer 1: 192.0.2.3 - Received BGP UPDATE:
Withdrawn Length = 0
Total Path Attr Length = 91
Flag: 0x90 Type: 14 Len: 23 Multiprotocol Reachable NLRI:
Address Family MVPN_IPV6
NextHop len 4 NextHop 192.0.2.3
Type: Intra-AD Len: 12 RD: 64500:203 Orig: 192.0.2.3
Flag: 0x40 Type: 1 Len: 1 Origin: 0
Flag: 0x40 Type: 2 Len: 0 AS Path:
Flag: 0x80 Type: 4 Len: 4 MED: 0
Flag: 0x40 Type: 5 Len: 4 Local Preference: 100
Flag: 0xc0 Type: 8 Len: 4 Community:
no-export
Flag: 0xc0 Type: 16 Len: 8 Extended Community:
target:64500:2
Flag: 0xc0 Type: 22 Len: 22 PMSI:
Tunnel-type LDP P2MP LSP (2)
Flags [Leaf not required]
MPLS Label 0
Root-Node 192.0.2.3, LSP-ID 0x2001
"

Enable only PIM IPv4 for the service on PE-2. PE-2 immediately sends Intra-AD
messages to PE-3. Note: there is no PMSI part present in debug message 4101.

Step 2.

*A:PE-2>config>service>vprn# pim no shutdown


*A:PE-2>config>service>vprn#
4101 2013/10/25 13:43:16.34 CEST MINOR: DEBUG #2001 Base Peer 1: 192.0.2.3
"Peer 1: 192.0.2.3: UPDATE
Peer 1: 192.0.2.3 - Send BGP UPDATE:
Withdrawn Length = 0
Total Path Attr Length = 66
Flag: 0x90 Type: 14 Len: 23 Multiprotocol Reachable NLRI:
Address Family MVPN_IPV4
NextHop len 4 NextHop 192.0.2.2
Type: Intra-AD Len: 12 RD: 64500:202 Orig: 192.0.2.2
Flag: 0x40 Type: 1 Len: 1 Origin: 0
Flag: 0x40 Type: 2 Len: 0 AS Path:
Flag: 0x80 Type: 4 Len: 4 MED: 0
Flag: 0x40 Type: 5 Len: 4 Local Preference: 100
Flag: 0xc0 Type: 8 Len: 4 Community:
no-export
Flag: 0xc0 Type: 16 Len: 8 Extended Community:
target:64500:2

Advanced Configuration Guide

Page 1505

Configuration

"

Bring up IGMP and add a static IGMP join for the service on a PE-2. PE-2
immediately sends a source-join message to PE-3 and receives a source-AD message from
PE-3.

Step 3.

*A:PE-2>config>service>vprn# igmp shutdown


*A:PE-2>config>service>vprn# igmp interface "int-mcast-receiver" static group 232.0.0.1
source 172.16.3.1
*A:PE-2>config>service>vprn#
4102 2013/10/25 13:43:25.36 CEST MINOR: DEBUG #2001 Base Peer 1: 192.0.2.3
"Peer 1: 192.0.2.3: UPDATE
Peer 1: 192.0.2.3 - Send BGP UPDATE:
Withdrawn Length = 0
Total Path Attr Length = 69
Flag: 0x90 Type: 14 Len: 33 Multiprotocol Reachable NLRI:
Address Family MVPN_IPV4
NextHop len 4 NextHop 192.0.2.2
Type: Source-Join Len:22 RD: 64500:203 SrcAS: 64500 Src: 172.16.3.1
Grp: 232.0.0.1
Flag: 0x40 Type: 1 Len: 1 Origin: 0
Flag: 0x40 Type: 2 Len: 0 AS Path:
Flag: 0x80 Type: 4 Len: 4 MED: 0
Flag: 0x40 Type: 5 Len: 4 Local Preference: 100
Flag: 0xc0 Type: 16 Len: 8 Extended Community:
target:192.0.2.3:2087
"
4103 2013/10/25 13:43:25.36 CEST MINOR: DEBUG #2001 Base Peer 1: 192.0.2.3
"Peer 1: 192.0.2.3: UPDATE
Peer 1: 192.0.2.3 - Received BGP UPDATE:
Withdrawn Length = 0
Total Path Attr Length = 65
Flag: 0x90 Type: 14 Len: 29 Multiprotocol Reachable NLRI:
Address Family MVPN_IPV4
NextHop len 4 NextHop 192.0.2.3
Type: Source-AD Len: 18 RD: 64500:203 Src: 172.16.3.1 Grp: 232.0.0.1
Flag: 0x40 Type: 1 Len: 1 Origin: 0
Flag: 0x40 Type: 2 Len: 0 AS Path:
Flag: 0x80 Type: 4 Len: 4 MED: 0
Flag: 0x40 Type: 5 Len: 4 Local Preference: 100
Flag: 0xc0 Type: 16 Len: 8 Extended Community:
target:64500:2
"

Enable PIM IPv6 for the service on PE-2. PE-2 immediately sends Intra-AD
messages to PE-3.

Step 4.

*A:PE-2>config>service>vprn# pim no ipv6-multicast-disable


*A:PE-2>config>service>vprn#
4104 2013/10/25 13:43:47.36 CEST MINOR: DEBUG #2001 Base Peer 1: 192.0.2.3
"Peer 1: 192.0.2.3: UPDATE
Peer 1: 192.0.2.3 - Send BGP UPDATE:
Withdrawn Length = 0

Page 1506

Advanced Configuration Guide

Multicast VPN: Sender-Only, Receiver-Only

Total Path Attr Length = 66


Flag: 0x90 Type: 14 Len: 23 Multiprotocol Reachable NLRI:
Address Family MVPN_IPV6
NextHop len 4 NextHop 192.0.2.2
Type: Intra-AD Len: 12 RD: 64500:202 Orig: 32.1.13.184
Flag: 0x40 Type: 1 Len: 1 Origin: 0
Flag: 0x40 Type: 2 Len: 0 AS Path:
Flag: 0x80 Type: 4 Len: 4 MED: 0
Flag: 0x40 Type: 5 Len: 4 Local Preference: 100
Flag: 0xc0 Type: 8 Len: 4 Community:
no-export
Flag: 0xc0 Type: 16 Len: 8 Extended Community:
target:64500:2
"

Bring up MLD and add a static MLD join for the service on a PE-2. PE-2
immediately sends a source-join message to PE-3 and receives a source-AD message from
PE-3.

Step 5.

*A:PE-2>config>service>vprn# mld shutdown


*A:PE-2>config>service>vprn# mld interface "int-mcast-receiver" static group FF3E::8000:1
source 2001:DB8:3::1
*A:PE-2>config>service>vprn#
4105 2013/10/25 13:43:54.36 CEST MINOR: DEBUG #2001 Base Peer 1: 192.0.2.3
"Peer 1: 192.0.2.3: UPDATE
Peer 1: 192.0.2.3 - Send BGP UPDATE:
Withdrawn Length = 0
Total Path Attr Length = 93
Flag: 0x90 Type: 14 Len: 57 Multiprotocol Reachable NLRI:
Address Family MVPN_IPV6
NextHop len 4 NextHop 192.0.2.2
Type: Source-Join Len: 46 RD: 64500:203 SrcAS: 64500 Src: 2001:DB8:3
::1 Grp: FF3E::8000:1
Flag: 0x40 Type: 1 Len: 1 Origin: 0
Flag: 0x40 Type: 2 Len: 0 AS Path:
Flag: 0x80 Type: 4 Len: 4 MED: 0
Flag: 0x40 Type: 5 Len: 4 Local Preference: 100
Flag: 0xc0 Type: 16 Len: 8 Extended Community:
target:192.0.2.3:2087
"
4106 2013/10/25 13:43:54.36 CEST MINOR: DEBUG #2001 Base Peer 1: 192.0.2.3
"Peer 1: 192.0.2.3: UPDATE
Peer 1: 192.0.2.3 - Received BGP UPDATE:
Withdrawn Length = 0
Total Path Attr Length = 89
Flag: 0x90 Type: 14 Len: 53 Multiprotocol Reachable NLRI:
Address Family MVPN_IPV6
NextHop len 4 NextHop 192.0.2.3
Type: Source-AD Len: 42 RD: 64500:203 Src: 2001:DB8:3::1 Grp: FF3E
::8000:1
Flag: 0x40 Type: 1 Len: 1 Origin: 0
Flag: 0x40 Type: 2 Len: 0 AS Path:
Flag: 0x80 Type: 4 Len: 4 MED: 0
Flag: 0x40 Type: 5 Len: 4 Local Preference: 100
Flag: 0xc0 Type: 16 Len: 8 Extended Community:

Advanced Configuration Guide

Page 1507

Configuration

target:64500:2

The same information can be gathered using the following show commands.
show>router>bgp>neighbor <peer> advertised-routes [mvpn-ipv4|mvpn-ipv6]
show>router>bgp>neighbor <peer> received-routes [mvpn-ipv4|mvpn-ipv6]

PE-2 output for the advertised routes for the mvpn-ipv4 address family.
*A:PE-2# show router bgp neighbor 192.0.2.3 advertised-routes mvpn-ipv4
===============================================================================
BGP MVPN-IPv4 Routes
===============================================================================
Flag RouteType
OriginatorIP
LocalPref
MED
RD
SourceAS
Label
Nexthop
SourceIP
As-Path
GroupIP
------------------------------------------------------------------------------i
Intra-Ad
192.0.2.2
100
0
64500:202
192.0.2.2
No As-Path
i
Source-Join
100
0
64500:203
64500
192.0.2.2
172.16.3.1
No As-Path
232.0.0.1
------------------------------------------------------------------------------Routes : 2
===============================================================================

PE-2 output for the advertised routers for the mvpn-ipv6 address family.
*A:PE-2# show router bgp neighbor 192.0.2.3 advertised-routes mvpn-ipv6
===============================================================================
BGP MVPN-IPv6 Routes
===============================================================================
Flag RouteType
OriginatorIP
LocalPref
MED
RD
SourceAS
Label
Nexthop
SourceIP
As-Path
GroupIP
------------------------------------------------------------------------------i
Intra-Ad
32.1.13.184
100
0
64500:202
192.0.2.2
No As-Path
i
Source-Join
100
0
64500:203
64500
192.0.2.2
2001:DB8:3::1
No As-Path
FF3E::8000:1
------------------------------------------------------------------------------Routes : 2
===============================================================================

Page 1508

Advanced Configuration Guide

Multicast VPN: Sender-Only, Receiver-Only

PE-2 output for the received routes for the mvpn-ipv4 address family.
*A:PE-2# show router bgp neighbor 192.0.2.3 received-routes mvpn-ipv4
===============================================================================
BGP MVPN-IPv4 Routes
===============================================================================
Flag RouteType
OriginatorIP
LocalPref
MED
RD
SourceAS
Label
Nexthop
SourceIP
As-Path
GroupIP
------------------------------------------------------------------------------u*>i Intra-Ad
192.0.2.3
100
0
64500:203
192.0.2.3
No As-Path
u*>i Source-Ad
100
0
64500:203
192.0.2.3
172.16.3.1
No As-Path
232.0.0.1
------------------------------------------------------------------------------Routes : 2
===============================================================================

PE-2 output for the received routes for the mvpn-ipv6 address family.
*A:PE-2# show router bgp neighbor 192.0.2.3 received-routes mvpn-ipv6
===============================================================================
BGP MVPN-IPv6 Routes
===============================================================================
Flag RouteType
OriginatorIP
LocalPref
MED
RD
SourceAS
Label
Nexthop
SourceIP
As-Path
GroupIP
------------------------------------------------------------------------------u*>i Intra-Ad
192.0.2.3
100
0
64500:203
192.0.2.3
No As-Path
u*>i Source-Ad
100
0
64500:203
192.0.2.3
2001:DB8:3::1
No As-Path
FF3E::8000:1
------------------------------------------------------------------------------Routes : 2
===============================================================================

The PE router does not change the BGP behavior when the MVPN is configured with mdt-type as
sender-only. A schematic of the message flow is presented in Figure 136.

Advanced Configuration Guide

Page 1509

Configuration

Sender Only

Sender + Receiver

SR-3

SR-1

Mcast
Source

VRF

VRF

Receiver
BGP Intra-AD
BGP Source-Join
BGP Source-AD
al_0332

Figure 136: mLDP-Based BGP Message Flow Between PE-1 and PE-3

In order to demonstrate the BGP message flow sequence the following initialization steps are
taken:
0. Bring down VPRN service, PIM protocol in a VPRN and IGMP/MLD protocol. As a result
the state of all signaling protocols is cleared.
1. Bring up the VPRN service. BGP exchanges unicast routing information.
2. Bring up the IPv4 PIM protocol. BGP exchanges IPv4 multicast routing information in order
to build PMSI infrastructure.
3. Bring up IGMP and add a static IGMP join where it is applicable. BGP exchanges IPv4 multicast routing information in order to propagate the multicast traffic to the receiver.
4. Bring up the IPv6 PIM protocol. BGP exchanges IPv6 multicast routing information in order
to build the PMSI infrastructure.
5. Bring up MLD and add a static MLD join where it is applicable. BGP exchanges IPv6 multicast routing information in order to propagate the multicast traffic to the receiver.
The BGP debug output below is taken from PE-1 and demonstrates the message flow between PE1 and PE-3.
Note: The PMSI part is present in debug messages 7584 and 7585, which are sent by PE-3
(sender-only).
Step 0: Bring down service and protocols to clear the state of all signalling protocols.
*A:PE-1>config>service>vprn#
*A:PE-1>config>service>vprn#
*A:PE-1>config>service>vprn#
*A:PE-1>config>service>vprn#
*A:PE-1>config>service>vprn#

Page 1510

shutdown
pim shutdown
igmp shutdown
mld shutdown
pim ipv6-multicast-disable

Advanced Configuration Guide

Multicast VPN: Sender-Only, Receiver-Only

Enable the VPRN service on PE-1. PE-1 immediately receives Intra-AD messages
from PE-3 because the remote VPRN service is already enabled for IPv4 and IPv6
multicast propagation. The PMSI attribute is present in both messages.

Step 1.

*A:PE-1>config>service>vprn# no shutdown
7584 2013/10/25 13:15:30.73 CEST MINOR: DEBUG #2001 Base Peer 1: 192.0.2.3
"Peer 1: 192.0.2.3: UPDATE
Peer 1: 192.0.2.3 - Received BGP UPDATE:
Withdrawn Length = 0
Total Path Attr Length = 91
Flag: 0x90 Type: 14 Len: 23 Multiprotocol Reachable NLRI:
Address Family MVPN_IPV4
NextHop len 4 NextHop 192.0.2.3
Type: Intra-AD Len: 12 RD: 64500:203 Orig: 192.0.2.3
Flag: 0x40 Type: 1 Len: 1 Origin: 0
Flag: 0x40 Type: 2 Len: 0 AS Path:
Flag: 0x80 Type: 4 Len: 4 MED: 0
Flag: 0x40 Type: 5 Len: 4 Local Preference: 100
Flag: 0xc0 Type: 8 Len: 4 Community:
no-export
Flag: 0xc0 Type: 16 Len: 8 Extended Community:
target:64500:2
Flag: 0xc0 Type: 22 Len: 22 PMSI:
Tunnel-type LDP P2MP LSP (2)
Flags [Leaf not required]
MPLS Label 0
Root-Node 192.0.2.3, LSP-ID 0x2001
"
7585 2013/10/25 13:15:30.73 CEST MINOR: DEBUG #2001 Base Peer 1: 192.0.2.3
"Peer 1: 192.0.2.3: UPDATE
Peer 1: 192.0.2.3 - Received BGP UPDATE:
Withdrawn Length = 0
Total Path Attr Length = 91
Flag: 0x90 Type: 14 Len: 23 Multiprotocol Reachable NLRI:
Address Family MVPN_IPV6
NextHop len 4 NextHop 192.0.2.3
Type: Intra-AD Len: 12 RD: 64500:203 Orig: 192.0.2.3
Flag: 0x40 Type: 1 Len: 1 Origin: 0
Flag: 0x40 Type: 2 Len: 0 AS Path:
Flag: 0x80 Type: 4 Len: 4 MED: 0
Flag: 0x40 Type: 5 Len: 4 Local Preference: 100
Flag: 0xc0 Type: 8 Len: 4 Community:
no-export
Flag: 0xc0 Type: 16 Len: 8 Extended Community:
target:64500:2
Flag: 0xc0 Type: 22 Len: 22 PMSI:
Tunnel-type LDP P2MP LSP (2)
Flags [Leaf not required]
MPLS Label 0
Root-Node 192.0.2.3, LSP-ID 0x2001
"

Enable PIM IPv4 only for the service on PE-1. PE-1 immediately sends Intra-AD
messages to PE-3.

Step 2.

Advanced Configuration Guide

Page 1511

Configuration

*A:PE-1>config>service>vprn# pim no shutdown


*A:PE-1>config>service>vprn#
7586 2013/10/25 13:16:43.72 CEST MINOR: DEBUG #2001 Base Peer 1: 192.0.2.3
"Peer 1: 192.0.2.3: UPDATE
Peer 1: 192.0.2.3 - Send BGP UPDATE:
Withdrawn Length = 0
Total Path Attr Length = 91
Flag: 0x90 Type: 14 Len: 23 Multiprotocol Reachable NLRI:
Address Family MVPN_IPV4
NextHop len 4 NextHop 192.0.2.1
Type: Intra-AD Len: 12 RD: 64500:201 Orig: 192.0.2.1
Flag: 0x40 Type: 1 Len: 1 Origin: 0
Flag: 0x40 Type: 2 Len: 0 AS Path:
Flag: 0x80 Type: 4 Len: 4 MED: 0
Flag: 0x40 Type: 5 Len: 4 Local Preference: 100
Flag: 0xc0 Type: 8 Len: 4 Community:
no-export
Flag: 0xc0 Type: 16 Len: 8 Extended Community:
target:64500:2
Flag: 0xc0 Type: 22 Len: 22 PMSI:
Tunnel-type LDP P2MP LSP (2)
Flags [Leaf not required]
MPLS Label 0
Root-Node 192.0.2.1, LSP-ID 0x2001
"

Page 1512

Advanced Configuration Guide

Multicast VPN: Sender-Only, Receiver-Only

Bring up IGMP and add a static IGMP join for the service on a PE-1. PE-1
immediately sends a source-join message to PE-3 and receives a source-AD message from
PE-3.

Step 3.

*A:PE-1>config>service>vprn# igmp no shutdown


*A:PE-1>config>service>vprn# igmp interface "int-mcast-receiver" static group 232.0.0.1
source 172.16.3.1
7587 2013/10/25 13:17:19.68 CEST MINOR: DEBUG #2001 Base Peer 1: 192.0.2.3
"Peer 1: 192.0.2.3: UPDATE
Peer 1: 192.0.2.3 - Send BGP UPDATE:
Withdrawn Length = 0
Total Path Attr Length = 69
Flag: 0x90 Type: 14 Len: 33 Multiprotocol Reachable NLRI:
Address Family MVPN_IPV4
NextHop len 4 NextHop 192.0.2.1
Type: Source-Join Len:22 RD: 64500:203 SrcAS: 64500 Src: 172.16.3.1
Grp: 232.0.0.1
Flag: 0x40 Type: 1 Len: 1 Origin: 0
Flag: 0x40 Type: 2 Len: 0 AS Path:
Flag: 0x80 Type: 4 Len: 4 MED: 0
Flag: 0x40 Type: 5 Len: 4 Local Preference: 100
Flag: 0xc0 Type: 16 Len: 8 Extended Community:
target:192.0.2.3:2087
"
7588 2013/10/25 13:17:20.43 CEST MINOR: DEBUG #2001 Base Peer 1: 192.0.2.3
"Peer 1: 192.0.2.3: UPDATE
Peer 1: 192.0.2.3 - Received BGP UPDATE:
Withdrawn Length = 0
Total Path Attr Length = 65
Flag: 0x90 Type: 14 Len: 29 Multiprotocol Reachable NLRI:
Address Family MVPN_IPV4
NextHop len 4 NextHop 192.0.2.3
Type: Source-AD Len: 18 RD: 64500:203 Src: 172.16.3.1 Grp: 232.0.0.1
Flag: 0x40 Type: 1 Len: 1 Origin: 0
Flag: 0x40 Type: 2 Len: 0 AS Path:
Flag: 0x80 Type: 4 Len: 4 MED: 0
Flag: 0x40 Type: 5 Len: 4 Local Preference: 100
Flag: 0xc0 Type: 16 Len: 8 Extended Community:
target:64500:2
"

Enable PIM IPv6 for the service on PE-1. PE-1 immediately sends Intra-AD
messages to PE-3.

Step 4.

*A:PE-1>config>service>vprn# pim no ipv6-multicast-disable


*A:PE-1>config>service>vprn#
7589 2013/10/25 13:18:42.72 CEST MINOR: DEBUG #2001 Base Peer 1: 192.0.2.3
"Peer 1: 192.0.2.3: UPDATE
Peer 1: 192.0.2.3 - Send BGP UPDATE:
Withdrawn Length = 0
Total Path Attr Length = 91
Flag: 0x90 Type: 14 Len: 23 Multiprotocol Reachable NLRI:
Address Family MVPN_IPV6

Advanced Configuration Guide

Page 1513

Configuration

NextHop len 4 NextHop 192.0.2.1


Type: Intra-AD Len: 12 RD: 64500:201 Orig: 192.0.2.1
Flag: 0x40 Type: 1 Len: 1 Origin: 0
Flag: 0x40 Type: 2 Len: 0 AS Path:
Flag: 0x80 Type: 4 Len: 4 MED: 0
Flag: 0x40 Type: 5 Len: 4 Local Preference: 100
Flag: 0xc0 Type: 8 Len: 4 Community:
no-export
Flag: 0xc0 Type: 16 Len: 8 Extended Community:
target:64500:2
Flag: 0xc0 Type: 22 Len: 22 PMSI:
Tunnel-type LDP P2MP LSP (2)
Flags [Leaf not required]
MPLS Label 0
Root-Node 192.0.2.1, LSP-ID 0x2001
"

Bring up MLD and add a static MLD join for the service on a PE-1. PE-1
immediately sends a source-join message to PE-3 and receives a source-AD message from
PE-3.

Step 5.

*A:PE-1>config>service>vprn# mld no shutdown


*A:PE-1>config>service>vprn# mld interface "int-mcast-receiver" static group FF3E::8000:1
source 2001:DB8:3::1
7590 2013/10/25 13:18:57.68 CEST MINOR: DEBUG #2001 Base Peer 1: 192.0.2.3
"Peer 1: 192.0.2.3: UPDATE
Peer 1: 192.0.2.3 - Send BGP UPDATE:
Withdrawn Length = 0
Total Path Attr Length = 93
Flag: 0x90 Type: 14 Len: 57 Multiprotocol Reachable NLRI:
Address Family MVPN_IPV6
NextHop len 4 NextHop 192.0.2.1
Type: Source-Join Len: 46 RD: 64500:203 SrcAS: 64500 Src: 2001:DB8:3
::1 Grp: FF3E::8000:1
Flag: 0x40 Type: 1 Len: 1 Origin: 0
Flag: 0x40 Type: 2 Len: 0 AS Path:
Flag: 0x80 Type: 4 Len: 4 MED: 0
Flag: 0x40 Type: 5 Len: 4 Local Preference: 100
Flag: 0xc0 Type: 16 Len: 8 Extended Community:
target:192.0.2.3:2087
"
7591 2013/10/25 13:18:58.43 CEST MINOR: DEBUG #2001 Base Peer 1: 192.0.2.3
"Peer 1: 192.0.2.3: UPDATE
Peer 1: 192.0.2.3 - Received BGP UPDATE:
Withdrawn Length = 0
Total Path Attr Length = 89
Flag: 0x90 Type: 14 Len: 53 Multiprotocol Reachable NLRI:
Address Family MVPN_IPV6
NextHop len 4 NextHop 192.0.2.3
Type: Source-AD Len: 42 RD: 64500:203 Src: 2001:DB8:3::1 Grp: FF3E
::8000:1
Flag: 0x40 Type: 1 Len: 1 Origin: 0
Flag: 0x40 Type: 2 Len: 0 AS Path:
Flag: 0x80 Type: 4 Len: 4 MED: 0
Flag: 0x40 Type: 5 Len: 4 Local Preference: 100
Flag: 0xc0 Type: 16 Len: 8 Extended Community:

Page 1514

Advanced Configuration Guide

Multicast VPN: Sender-Only, Receiver-Only

target:64500:2
"

The same information can be gathered using the following show commands.
show router bgp neighbor <peer> advertised-routes [mvpn-ipv4|mvpn-ipv6]
show router bgp neighbor <peer> received-routes [mvpn-ipv4|mvpn-ipv6]
PE-1 output for the advertised routes for the mvpn-ipv4 address family.
*A:PE-1# show router bgp neighbor 192.0.2.3 advertised-routes mvpn-ipv4
===============================================================================
BGP MVPN-IPv4 Routes
===============================================================================
Flag RouteType
OriginatorIP
LocalPref
MED
RD
SourceAS
Label
Nexthop
SourceIP
As-Path
GroupIP
------------------------------------------------------------------------------i
Intra-Ad
192.0.2.1
100
0
64500:201
192.0.2.1
No As-Path
i
Source-Join
100
0
64500:203
64500
192.0.2.1
172.16.3.1
No As-Path
232.0.0.1
------------------------------------------------------------------------------Routes : 2
===============================================================================

PE-1 output for the advertised routes for the mvpn-ipv6 address family.
*A:PE-1# show router bgp neighbor 192.0.2.3 advertised-routes mvpn-ipv6
===============================================================================
BGP MVPN-IPv6 Routes
===============================================================================
Flag RouteType
OriginatorIP
LocalPref
MED
RD
SourceAS
Label
Nexthop
SourceIP
As-Path
GroupIP
------------------------------------------------------------------------------i
Intra-Ad
192.0.2.1
100
0
64500:201
192.0.2.1
No As-Path
i
Source-Join
100
0
64500:203
64500
192.0.2.1
2001:DB8:3::1
No As-Path
FF3E::8000:1
------------------------------------------------------------------------------Routes : 2
===============================================================================

Advanced Configuration Guide

Page 1515

Configuration

PE-1 output for the received routes for the mvpn-ipv4 address family.
A:PE-1# show router bgp neighbor 192.0.2.3 received-routes mvpn-ipv4
===============================================================================
BGP MVPN-IPv4 Routes
===============================================================================
Flag RouteType
OriginatorIP
LocalPref
MED
RD
SourceAS
Label
Nexthop
SourceIP
As-Path
GroupIP
------------------------------------------------------------------------------u*>i Intra-Ad
192.0.2.3
100
0
64500:203
192.0.2.3
No As-Path
u*>i Source-Ad
100
0
64500:203
192.0.2.3
172.16.3.1
No As-Path
232.0.0.1
------------------------------------------------------------------------------Routes : 2
===============================================================================

PE-1 output for the received routes for the mvpn-ipv6 address family.
A:PE-1# show router bgp neighbor 192.0.2.3 received-routes mvpn-ipv6
===============================================================================
BGP MVPN-IPv6 Routes
===============================================================================
Flag RouteType
OriginatorIP
LocalPref
MED
RD
SourceAS
Label
Nexthop
SourceIP
As-Path
GroupIP
------------------------------------------------------------------------------u*>i Intra-Ad
192.0.2.3
100
0
64500:203
192.0.2.3
No As-Path
u*>i Source-Ad
100
0
64500:203
192.0.2.3
2001:DB8:3::1
No As-Path
FF3E::8000:1
------------------------------------------------------------------------------Routes : 2
===============================================================================

Page 1516

Advanced Configuration Guide

Multicast VPN: Sender-Only, Receiver-Only

LDP Verification and Debugging


When BGP intra-AD messages are exchanged every PE starts to build a multicast tunnel based on
the following criteria:
PE nodes which are configured as sender-only do not distribute mLDP Forward Equivalence
Classes (FECs) to remote PEs for this MVPN.
PE nodes which configured as receiver-only do not include the PMSI part for intra-AD messages
and remote PEs do not send mLDP FECs for this MVPN.
LDP bindings can be verified using the following command:
show router ldp bindings fec-type p2mp
PE-1 (192.0.2.1) has one ingress FEC and one egress FEC due to the fact that PE-1 has the default
mdt-type sender-receiver.
*A:PE-1# show router ldp bindings fec-type p2mp
===============================================================================
LDP LSR ID: 192.0.2.1
===============================================================================
Legend: U - Label In Use, N - Label Not In Use, W - Label Withdrawn
WP - Label Withdraw Pending, BU - Alternate For Fast Re-Route
===============================================================================
LDP Generic P2MP Bindings
===============================================================================
P2MP-Id
RootAddr
Interface
Peer
IngLbl
EgrLbl EgrIntf/
EgrNextHop
LspId
------------------------------------------------------------------------------8193
192.0.2.1
73734
192.0.2.2
-256033 3/1/1
192.168.12.1
8193
73735

192.0.2.3
192.0.2.3

261935U

--

--

--

------------------------------------------------------------------------------No. of Generic P2MP Bindings: 2

PE-2 (192.0.2.2) has two ingress FECs due to the fact that PE-2 has mdt-type receiver-only.
A:PE-2# show router ldp bindings fec-type p2mp
===============================================================================
LDP LSR ID: 192.0.2.2
===============================================================================
Legend: U - Label In Use, N - Label Not In Use, W - Label Withdrawn
WP - Label Withdraw Pending, BU - Alternate For Fast Re-Route
===============================================================================
LDP Generic P2MP Bindings
===============================================================================
P2MP-Id
RootAddr
Interface
Peer
IngLbl
EgrLbl EgrIntf/
EgrNextHop

Advanced Configuration Guide

Page 1517

Configuration

LspId
------------------------------------------------------------------------------8193
192.0.2.1
73733
192.0.2.1
256033U
---8193
73732

192.0.2.3
192.0.2.3

256034U

--

--

--

------------------------------------------------------------------------------No. of Generic P2MP Bindings: 2

PE-3 (192.0.2.3) has two egress FECs due to the fact that PE-3 has mdt-type sender-only.
*A:PE-3# show router ldp bindings fec-type p2mp
===============================================================================
LDP LSR ID: 192.0.2.3
===============================================================================
Legend: U - Label In Use, N - Label Not In Use, W - Label Withdrawn
WP - Label Withdraw Pending, BU - Alternate For Fast Re-Route
===============================================================================
LDP Generic P2MP Bindings
===============================================================================
P2MP-Id
RootAddr
Interface
Peer
IngLbl
EgrLbl EgrIntf/
EgrNextHop
LspId
------------------------------------------------------------------------------8193
192.0.2.3
73752
192.0.2.1
-261935 3/1/4
192.168.13.0
8193
73752

192.0.2.3
192.0.2.2

--

256034 1/1/1

192.168.23.0

------------------------------------------------------------------------------No. of Generic P2MP Bindings: 2

Page 1518

Advanced Configuration Guide

Multicast VPN: Sender-Only, Receiver-Only

Multicast Stream Verification


Status of multicast group/stream can be verified using the following command
show router <sid> pim group detail [ipv6]
There is IPv4 receiver connected to PE-1. I-PMSI is used as incoming interface and physical
interface where receiver is connected is used as outgoing.
A:PE-1# show router 2 pim group detail
===============================================================================
PIM Source Group ipv4
===============================================================================
Group Address
: 232.0.0.1
Source Address
: 172.16.3.1
RP Address
: 0
Advt Router
: 192.0.2.3
Flags
:
Type
: (S,G)
MRIB Next Hop
: 192.0.2.3
<snip>
Rpf Neighbor
: 192.0.2.3
Incoming Intf
: mpls-if-73735
Outgoing Intf List : int-mcast-receiver
Curr Fwding Rate
<snip>

: 85614.0 kbps

There is IPv4 receiver connected to PE-2. I-PMSI is used as incoming interface and physical
interface where receiver is connected is used as outgoing.
A:PE-2# show router 2 pim group detail
===============================================================================
PIM Source Group ipv4
===============================================================================
Group Address
: 232.0.0.1
Source Address
: 172.16.3.1
RP Address
: 0
Advt Router
: 192.0.2.3
Flags
:
Type
: (S,G)
MRIB Next Hop
: 192.0.2.3
<snip>
Rpf Neighbor
: 192.0.2.3
Incoming Intf
: mpls-if-73732
Outgoing Intf List : int-mcast-receiver
Curr Fwding Rate
<snip>

: 85615.1 kbps

Advanced Configuration Guide

Page 1519

Configuration

There is IPv4 sender connected to PE-3. I-PMSI is used as outgoing interface and physical
interface where sender is connected is used as incoming.
*A:PE-3# show router 2 pim group detail
===============================================================================
PIM Source Group ipv4
===============================================================================
Group Address
: 232.0.0.1
Source Address
: 172.16.3.1
RP Address
: 0
Advt Router
: 192.0.2.3
Flags
:
Type
: (S,G)
MRIB Next Hop
: 172.16.3.1
<snip>
Rpf Neighbor
: 172.16.3.1
Incoming Intf
: int-mcast-source
Outgoing Intf List : mpls-if-73752
Curr Fwding Rate
<snip>

: 85638.1 kbps

Similar behavior is observed for IPv6 multicast.


There is an IPv6 receiver connected to PE-1. An I-PMSI is used as the incoming interface and the
physical interface where the receiver is connected is used as the outgoing interface.
A:PE-1# show router 2 pim group detail ipv6
===============================================================================
PIM Source Group ipv6
===============================================================================
Group Address
: FF3E::8000:1
Source Address
: 2001:DB8:3::1
RP Address
: 0
Advt Router
: 192.0.2.3
Flags
:
Type
: (S,G)
MRIB Next Hop
: 192.0.2.3
<snip>
Rpf Neighbor
: 192.0.2.3
Incoming Intf
: mpls-if-73735
Outgoing Intf List : int-mcast-receiver
Curr Fwding Rate
<snip>

: 2140.5 kbps

There is an IPv6 receiver connected to PE-2. An I-PMSI is used as the incoming interface and the
physical interface where the receiver is connected is used as the outgoing interface.
A:PE-2# show router 2 pim group detail ipv6
===============================================================================
PIM Source Group ipv6
===============================================================================
Group Address
: FF3E::8000:1
Source Address
: 2001:DB8:3::1

Page 1520

Advanced Configuration Guide

Multicast VPN: Sender-Only, Receiver-Only

RP Address
Advt Router
Flags
MRIB Next Hop
<snip>
Rpf Neighbor
Incoming Intf
Outgoing Intf List

: 0
: 192.0.2.3
:
: 192.0.2.3

Curr Fwding Rate


<snip>

: 2140.5 kbps

Type

: (S,G)

: 192.0.2.3
: mpls-if-73732
: int-mcast-receiver

There is an IPv6 sender connected to PE-3. An I-PMSI is used as the outgoing interface and the
physical interface where the sender is connected is used as the incoming interface.
*A:PE-3# show router 2 pim group detail ipv6
===============================================================================
PIM Source Group ipv6
===============================================================================
Group Address
: FF3E::8000:1
Source Address
: 2001:DB8:3::1
RP Address
: 0
Advt Router
: 192.0.2.3
Flags
:
Type
: (S,G)
MRIB Next Hop
: 2001:DB8:3::1
<snip>
Rpf Neighbor
: 2001:DB8:3::1
Incoming Intf
: int-mcast-source
Outgoing Intf List : mpls-if-73752
Curr Fwding Rate
<snip>

: 2140.5 kbps

Advanced Configuration Guide

Page 1521

Conclusion

Conclusion
The sender-only/receiver-only feature provides significant signaling optimization in the core
network for RSVP and LDP protocols and is recommended to be used when such functionality is
required. The following are required before implementing this feature in the network:

Page 1522

MDT-types sender-only, receiver-only and sender-receiver are enabled per MVPN.

The default mdt-type is sender-receiver mode for backward compatibility.

This is purely a control plane feature and there are no hardware dependencies, except for
requiring chassis mode C or later.

Draft Rosen or MDT-SAFI based MVPNs are not supported.

IPv4 and IPv6 C-signaling are supported.

mLDP and RSVP demonstrate slightly different behavior due to the nature of each
protocol.

mLDP provides a better optimization than RSVP in all cases, as mLDP does not initiate
LSPs to sender-only routers.

Advanced Configuration Guide

MVPN: Inter-AS Option B

In This Chapter
This section provides information about MVPN: Inter-AS Option B configurations.
Topics in this section include:

Applicability on page 1524

Overview on page 1525

Configuration on page 1533

Conclusion on page 1548

Advanced Configuration Guide

Page 1523

Applicability

Applicability
This example is applicable to 7950 XRS, 7750 all variants, 7750 SR c4/12, 7450 mixed mode
systems. Chassis mode C or D must be used. The configuration was tested on Release 11.0 R3.

Overview
This configuration note covers a basic technology overview, the network topology and
configuration examples which are used for Multicast VPN Inter-AS option B.
Knowledge of the Alcatel-Lucent multicast and Layer 3 VPNs concepts are assumed throughout
this document.

Page 1524

Advanced Configuration Guide

MVPN: Inter-AS Option B

Overview
The Inter-AS MVPN feature allows the setup of Multicast Distribution Trees that span multiple
Autonomous Systems.

AS 64501

AS 64502

PE-1
Mcast
Source

P-3

VRF

P-2

ASBR

PE-5

ASBR

VRF

Receiver
al_0312

Figure 137: General Topology for Inter-AS MVPN

This example covers Draft-Rosen Inter-AS support (Option-B). Inter-AS Option B is supported
for PIM SSM with Draft-Rosen MVPN using Multicast Distribution Tree (MDT) Subsequent
Address Family (SAFI), using the BGP Connector attribute and PIM RPF vector.

AS 64501
PE-1
Mcast
Source

AS 64502
P-3

VRF

P-2

ASBR

PE-5

ASBR

VRF

Receiver
iBGP

eBGP

iBGP

PIM

PIM

PIM
al_0314

Figure 138: Protocols Used for Inter-AS MVPN

The following assumptions are made:

PE-1 is named sender PE because the multicast source is directly connected to this
router.

PE-5 is named receiver PE because multicast receiver is directly connected to this


router.

Advanced Configuration Guide

Page 1525

Overview

P-2 and P-3 are named ASBR routers according to Inter-AS model.

The multicast receiver and source can be indirectly connected to PE routers via CE routers, but for
the core multicast distribution these variations are conceptually the same. For simplicity, the PE
and P router configurations will be provided.
There are several challenges which have to be solved in order to make complete inter-as solution
operational:
Challenge 1:
In case of Inter-AS MVPN Option B, routing information towards the source PE is not available in
a remote AS domain since IGP routes are not exchanged between ASs.
As a result a PIM-P Join would never be sent upstream (from the receiver PE to the sender PE in a
different AS). However, the PIM-P join has to be propagated from PE-5 to PE-1. Therefore a
solution is required to issue PIM-P Join and perform RPF.
Solution:
Use a PIM RPFV (Reverse Path Forwarding (RPF) vector) to segment the PIM-P propagation. In
this example there are three segments:

PE-5 -> ASBR P-2

ASBR P-2 -> ASBR P-3

ASBR P-3 -> PE-1

The RPF vector is added to a PIM join at the PE router when the following option is enabled:
*A:PE-5>config>router>pim# rpfv
- no rpfv [mvpn]
- rpfv mvpn
<mvpn>
: Proxy RPF vector for inter-AS rosen mvpn

mvpn enables mvpn RPF vector processing for Inter-AS Option B MVPN based on RFC 5496
and RFC 6513. If a core RPF vector is received, it will be dropped before a message is
processed.
All routers which are used for multicast traffic transportation must have this option enabled to
allow RPF Vector processing. If the option is not enabled, the RPF Vector is dropped and the PIM
Join is processed as if the PIM Vector is not present.
Details about RPF Vector can be found in the following RFCs: 5496, 5384, 6513.

Page 1526

Advanced Configuration Guide

MVPN: Inter-AS Option B

Challenge 2:
With Inter-AS MVPN Option B, the BGP next-hop is modified by the local and remote ASBRs
during re-advertisement of VPNv4 routes. When the BGP next-hop is changed, information
regarding the originator of the prefix is lost when the advertisement reaches the receiver PE node.
Therefore a solution is required to do a successful RPF check for the VPN source at receiver
VPRN.
Note: This challenge does not apply to Model C since in Model C the BGP next-hop for VPN
routes is not updated.
Solution:
A new transitive BGP attribute - Connector - is used to advertise an address of a sender PE node
which is carried inside VPNv4 update. The BGP connector attribute allows the sender PE address
information to be available to the receiver PE so that a receiver PE is able to associate VPNv4
advertisement to the corresponding source PE.
Inter-AS Option B will work when the following criteria are met:

Draft-rosen MVPN is used with PIM SSM

BGP MDT-SAFI address family is used

PIM RPF Vector is configured

BGP Connector attribute is used for vpn-ipv4 updates

SR OS inter-AS Option B is designed to be standard compliant based on the following RFCs:

RFC 5384, The Protocol Independent Multicast (PIM) Join Attribute Format

RFC 5496, The Reverse Path Forwarding (RPF) Vector TLV

RFC 6513, Multicast in MPLS/BGP IP VPNs

Advanced Configuration Guide

Page 1527

Overview

Three global signaling stages can be identified when Inter-AS MVPN is configured:
Stage 1: BGP core signalling

AS 64501
PE-1
Mcast
Source

AS 64502
P-3

VRF

P-2

ASBR

PE-5

ASBR

VRF

Receiver
BGP VPN-IPv4
+ Connector Attribute

BGP VPN-IPv4
+ Connector Attribute

BGP VPN-IPv4
+ Connector Attribute

BGP MDT-SAFI

BGP MDT-SAFI

BGP MDT-SAFI
al_0315

Figure 139: BGP Signalling Steps

The sender PE sends VPN-IPv4 and MDT-SAFI BGP updates for this particular MVPN:

Every ASBR propagates VPN-IPv4 and MDT-SAFI BGP updates:


Next-Hop (NH) attribute is modified every time
Connector attribute stays untouched

When this stage is completed, all routers have necessary information:

Page 1528

to start PIM signaling in the core network (PIM-P) to prepare the Default MDT

to start PIM signaling of customers multicast streams (PIM-C) inside VPN

Advanced Configuration Guide

MVPN: Inter-AS Option B

Stage 2: Core PIM signaling

AS 64501
PE-1
Mcast
Source

AS 64502
P-3

VRF

P-2

ASBR

PE-5

ASBR

VRF

Receiver

PIM Join SSM

PIM Join SSM


+ RPF Vector

PIM Join SSM


+ RPF Vector
al_0319

Figure 140: PIM-P Signalling Steps for Default MDT

PE-5 determines the reverse Path to the source based on the RPF Vector (ASBR P-2 IP address)
and not based on the IP address of the multicast source (PE-1) which is unknown to it.
PE-5 inserts an RPF vector and sends a PIM-P Join to the immediate next-hop to reach ASBR P-2.
Intermediate P-routers (if present) do not change the RPF vector.
P-2 finds itself in RPF Vector and has to make a decision based on MDT-SAFI BGP table:

P-2 determines the reverse path to the multicast source based on the RPF Vector (ASBR
P-3 IP address).

If the multicast source and NH do not match, P-2 has to use RPFV.

P-2 modifies the PIM-P Join received from PE-5 with ASBR P-3s IP address as the
upstream (taken from Next-hop MDT-SAFI NLRI).

P-3 can match the source IP with the NH in BGP MDT-SAFI. Therefore there is no need
for RPF Vector to be used.

P-3 removes the RPF vector and sends a normal PIM-P join towards PE-1.

When this stage is completed, the default MDT is established for this MVPN and PE routers have
the necessary information to start PIM signaling inside VPRN (PIM-C).

Advanced Configuration Guide

Page 1529

Overview

Stage 3: Customer PIM signaling

AS 64501
PE-1
Mcast
Source

VRF

AS 64502
P-3

P-2

ASBR

ASBR

PE-5

VRF

Receiver

PIM-C Join SSM


al_0322

Figure 141: PIM-C Signalling

A PIM-C Join is sent to the source PE using the existing tunnel infrastructure to the RPF neighbor
PE-1 provided by the BGP connector attribute of the vpn-ipv4 route of the multicast source.
When this stage is completed, the customer multicast flows throughout the network in a Default
MDT.

Page 1530

Advanced Configuration Guide

MVPN: Inter-AS Option B

Stage 41: The Multicast stream threshold is reached.


AS 64501
PE-1
Mcast
Source

AS 64502
P-3

VRF

P-2

ASBR

PE-5

ASBR

VRF

Receiver

PIM Join SSM

PIM Join SSM


+ RPF Vector

PIM Join SSM


+RPF Vector
al_0317b

Figure 142: PIM-P Signalling Steps for Data MDT

The process is similar to the Default MDT setup:

PE-5 determines reverse path to the source based on the RPF Vector (ASBR P-2s IP
address) and not based on IP address of the multicast source (PE-1) which is unknown to
it.

PE-5 inserts an RPF vector and sends a PIM-P Join to the immediate next-hop to reach
ASBR P-2.

Intermediate P-routers (if present) do not change RPF vector.

P-2 finds itself in the RPF Vector and has to make a decision based on the MDT-SAFI
BGP table:
P-2 determines reverse path to the multicast source based on the RPF Vector (ASBR
P-3s IP address).
If the multicast source and NH do not match, P-2 has to use the RPFV.
P-2 modifies the PIM-P Join received from PE-5 with ASBR P-3s IP address as
upstream (taken from Next-hop MDT-SAFI NLRI).

P-3 can match the source IP with the NH in the BGP MDT-SAFI. Therefore there is no
need for RPF Vector to be used.

P-3 removes the RPF vector and sends a normal PIM-P join towards PE-1.

When this optional stage is completed, the customer multicast flows in a dedicated Data MDT.

1.
This stage is optional and applicable when S-PMSI instance and S-PMSI threshold are
configured.

Advanced Configuration Guide

Page 1531

Overview

Known interoperability issues:


The SR OS implementation was also designed to interoperate with Cisco routers Inter-AS
implementations that do not fully comply with the RFC 5384 and RFC5496.
When the following option is enabled:
configure router pim rpfv mvpn

Cisco routers need to be configured to include RD in an RPF vector using the following command
for interoperability:
ip multicast vrf <name> rpf proxy rd vector

Page 1532

Advanced Configuration Guide

MVPN: Inter-AS Option B

Configuration
The test topology is shown in Figure 143.

AS 64501
PE-1
Mcast
Source

1/1/1

VRF

AS 64502
P-3

1/1/4
.1

1/1/1
.2

ASBR

P-2
1/1/2
.2

192.168.13.x/30

1/1/4
.1

ASBR

PE-5
1/1/1
.2

192.168.23.x/30

1/1/1
.1

VRF

1/1/4

192.168.25.x/30

Receiver
al_0313

Figure 143: Test Topology Details

The following parameters are used in the test scenario:

VPRN 1 is used

Customer multicast group is 232.0.0.0/8

Default MDT multicast group is 239.255.0.1

Data MDT multicast group is 239.255.1.0/24

Multicast source is 172.16.1.1

PE-x routers have system IP addresses 192.0.2.x

P-x routers have system IP addresses 192.0.2.x

Interface between Router A and B has IP address 192.168.AB.x

Global BGP configuration for PE-1 router using the family mdt-safi with an iBGP neighbor to P3. System interface IP address is used for iBGP session.
configure
router
bgp
group iBGP"
family vpn-ipv4 mdt-safi
type internal
neighbor 192.0.2.3
next-hop-self
exit
exit

Global BGP configuration for P-3 router using the family mdt-safi with an iBGP neighbor to PE-1
and an eBGP neighbor to P-2. System interface IP address is used for iBGP session and network
interface IP address is used for eBGP session.

Advanced Configuration Guide

Page 1533

Configuration

configure router bgp


enable-inter-as-vpn
group eBGP"
family vpn-ipv4 mdt-safi
neighbor 192.168.23.1
type external
peer-as 64502
exit
exit
group iBGP"
family vpn-ipv4 mdt-safi
neighbor 192.0.2.1
next-hop-self
type internal
exit
exit

Global BGP configuration for P-2 router using the family mdt-safi with an iBGP neighbor to PE-5
and an eBGP neighbor to P-3. System interface IP address is used for iBGP session and network
interface IP address is used for eBGP session.
configure router bgp
enable-inter-as-vpn
group eBGP"
family vpn-ipv4 mdt-safi
neighbor 192.168.23.2
type external
peer-as 64501
exit
exit
group "iBGP"
family vpn-ipv4 mdt-safi
neighbor 192.0.2.5
next-hop-self
type internal
exit
exit

Global BGP configuration for PE-5 router using the family mdt-safi with an iBGP neighbor to P2. System interface IP address is used for iBGP session.
configure
router
bgp
group "iBGP"
family vpn-ipv4 mdt-safi
type internal
neighbor 192.0.2.2
next-hop-self
exit
exit

Global PIM configuration for ALL routers.

Page 1534

Advanced Configuration Guide

MVPN: Inter-AS Option B

configure router pim


rpf-table both
apply-to non-ies
rp
static
exit
bsr-candidate
shutdown
exit
rp-candidate
shutdown
exit
exit
no shutdown
rpfv mvpn

VPRN configuration for PE routers.


PE-x>config>service>vprn# info
---------------------------------------------<snip>
mvpn
auto-discovery mdt-safi
c-mcast-signaling pim
inclusive
pim ssm 239.255.0.1
exit
exit
selective
data-threshold 232.0.0.0/8 1
pim-ssm 239.255.1.0/24
exit
exit
vrf-target unicast
exit
exit

Advanced Configuration Guide

Page 1535

Configuration

MVPN Verification and Debugging


BGP Core Signalling

AS 64501

AS 64502

PE-1
Mcast
Source

P-3

VRF

P-2

ASBR

PE-5

ASBR

VRF

Receiver
BGP VPN-IPv4
Connector: RD 1:1,
Egress-router: 192.0.2.1

BGP VPN-IPv4
Connector: RD 1:1,
Egress-router: 192.0.2.1

BGP VPN-IPv4
Connector: RD 1:1,
Egress-router: 192.0.2.1

BGP MDT-SAFI
Addr: 192.0.2.1,
Group: 239.255.0.1,
RD: 1:1
NH: 192.0.2.1

BGP MDT-SAFI
Addr: 192.0.2.1,
Group: 239.255.0.1,
RD: 1:1
NH: 192.168.23.2

BGP MDT-SAFI
Addr: 192.0.2.1,
Group: 239.255.0.1,
RD: 1:1
NH: 2.2.2.2

al_0318

Figure 144: BGP Signalling Steps

On PE-1, the debug router bgp update output shows the BGP update messages which are sent to
P-3. The VPN-IPv4 update contains a connector attribute and the MDT-SAFI update is used for
signalling multicast group 239.255.0.1.
"Peer 1: 192.0.2.3: UPDATE
Peer 1: 192.0.2.3 - Send BGP UPDATE:
Withdrawn Length = 0
Total Path Attr Length = 95
Flag: 0x90 Type: 14 Len: 49 Multiprotocol Reachable NLRI:
Address Family VPN_IPV4
NextHop len 12 NextHop 192.0.2.1
172.16.1.0/30 RD 1:1 Label 262142
192.0.2.1/32 RD 1:1 Label 262142
Flag: 0x40 Type: 1 Len: 1 Origin: 0
Flag: 0x40 Type: 2 Len: 0 AS Path:
Flag: 0x40 Type: 5 Len: 4 Local Preference: 100
Flag: 0xc0 Type: 16 Len: 8 Extended Community:
target:1:1
Flag: 0xc0 Type: 20 Len: 14 Connector:
RD 1:1, Egress-router 192.0.2.1
"Peer 1: 192.0.2.3: UPDATE
Peer 1: 192.0.2.3 - Send BGP UPDATE:
Withdrawn Length = 0
Total Path Attr Length = 62
Flag: 0x90 Type: 14 Len: 26 Multiprotocol Reachable NLRI:
Address Family MDT-SAFI
NextHop len 4 NextHop 192.0.2.1

Page 1536

Advanced Configuration Guide

MVPN: Inter-AS Option B

[MDT-SAFI] Addr 192.0.2.1, Group 239.255.0.1, RD 1:1


Flag: 0x40 Type: 1 Len: 1 Origin: 0
Flag: 0x40 Type: 2 Len: 0 AS Path:
Flag: 0x80 Type: 4 Len: 4 MED: 0
Flag: 0x40 Type: 5 Len: 4 Local Preference: 100
Flag: 0xc0 Type: 16 Len: 8 Extended Community:
target:1:1

On P-3, the debug router bgp update output shows the BGP update messages which are sent to
P-2. The VPN-IPv4 update contains an unmodified connector attribute and the MDT-SAFI update
is used for signalling multicast group 239.255.0.1.
"Peer 1: 192.168.23.1: UPDATE
Peer 1: 192.168.23.1 - Send BGP UPDATE:
Withdrawn Length = 0
Total Path Attr Length = 126
Flag: 0x90 Type: 14 Len: 81 Multiprotocol Reachable NLRI:
Address Family VPN_IPV4
NextHop len 12 NextHop 192.168.23.2
192.0.2.4/32 RD 1:1 Label 262142
192.0.2.1/32 RD 1:1 Label 262142
172.16.1.0/30 RD 1:1 Label 262142
Flag: 0x40 Type: 1 Len: 1 Origin: 0
Flag: 0x40 Type: 2 Len: 6 AS Path:
Type: 2 Len: 1 < 64501 >
Flag: 0xc0 Type: 16 Len: 8 Extended Community:
target:1:1
Flag: 0xc0 Type: 20 Len: 14 Connector:
RD 1:1, Egress-router 192.0.2.1
"Peer 1: 192.168.23.1: UPDATE
Peer 1: 192.168.23.1 - Send BGP UPDATE:
Withdrawn Length = 0
Total Path Attr Length = 54
Flag: 0x90 Type: 14 Len: 26 Multiprotocol Reachable NLRI:
Address Family MDT-SAFI
NextHop len 4 NextHop 192.168.23.2
[MDT-SAFI] Addr 192.0.2.1, Group 239.255.0.1, RD 1:1
Flag: 0x40 Type: 1 Len: 1 Origin: 0
Flag: 0x40 Type: 2 Len: 6 AS Path:
Type: 2 Len: 1 < 64501 >
Flag: 0xc0 Type: 16 Len: 8 Extended Community:
target:1:1

On P-2, the debug router bgp update output shows the BGP update messages which are sent to
PE-5. The VPN-IPv4 update contains an unmodified connector attribute and the MDT-SAFI
update is used for signalling multicast group 239.255.0.1.
"Peer 1: 192.0.2.5: UPDATE
Peer 1: 192.0.2.5 - Send BGP UPDATE:
Withdrawn Length = 0
Total Path Attr Length = 133
Flag: 0x90 Type: 14 Len: 81 Multiprotocol Reachable NLRI:
Address Family VPN_IPV4
NextHop len 12 NextHop 192.0.2.2

Advanced Configuration Guide

Page 1537

Configuration

192.0.2.4/32 RD 1:1 Label 262142


172.16.1.0/30 RD 1:1 Label 262142
192.0.2.1/32 RD 1:1 Label 262142
Flag: 0x40 Type: 1 Len: 1 Origin: 0
Flag: 0x40 Type: 2 Len: 6 AS Path:
Type: 2 Len: 1 < 64501 >
Flag: 0x40 Type: 5 Len: 4 Local Preference: 100
Flag: 0xc0 Type: 16 Len: 8 Extended Community:
target:1:1
Flag: 0xc0 Type: 20 Len: 14 Connector:
RD 1:1, Egress-router 192.0.2.1
"Peer 1: 192.0.2.5: UPDATE
Peer 1: 192.0.2.5 - Send BGP UPDATE:
Withdrawn Length = 0
Total Path Attr Length = 61
Flag: 0x90 Type: 14 Len: 26 Multiprotocol Reachable NLRI:
Address Family MDT-SAFI
NextHop len 4 NextHop 192.0.2.2
[MDT-SAFI] Addr 192.0.2.1, Group 239.255.0.1, RD 1:1
Flag: 0x40 Type: 1 Len: 1 Origin: 0
Flag: 0x40 Type: 2 Len: 6 AS Path:
Type: 2 Len: 1 < 64501 >
Flag: 0x40 Type: 5 Len: 4 Local Preference: 100
Flag: 0xc0 Type: 16 Len: 8 Extended Community:
target:1:1

The BGP tables on PE1 and PE-5 are updated accordingly. The most interesting aspect here is
MDT-SAFI routes received.
PE-5 has one MDT-SAFI update received from PE-1. The next-hop was modified accordingly to
Option-B model.
*A:PE-5# show router bgp neighbor 192.0.2.2 received-routes mdt-safi
===============================================================================
BGP Router ID:192.0.2.5
AS:64502
Local AS:64502
===============================================================================
Legend Status codes : u - used, s - suppressed, h - history, d - decayed, * - valid
Origin codes : i - IGP, e - EGP, ? - incomplete, > - best, b - backup
===============================================================================
BGP MDT-SAFI Routes
===============================================================================
Flag Network
LocalPref
MED
Nexthop
Group-Addr
Label
As-Path
------------------------------------------------------------------------------u*>i 1:1:192.0.2.1
100
None
192.0.2.2
239.255.0.1
64501

PE-1 has one MDT-SAFI update received from PE-5. The next-hop was modified accordingly to
Option-B model.

Page 1538

Advanced Configuration Guide

MVPN: Inter-AS Option B

*A:PE-1# show router bgp neighbor 192.0.2.4 received-routes mdt-safi


===============================================================================
BGP Router ID:192.0.2.1
AS:64501
Local AS:64501
===============================================================================
Legend Status codes : u - used, s - suppressed, h - history, d - decayed, * - valid
Origin codes : i - IGP, e - EGP, ? - incomplete, > - best, b - backup
===============================================================================
BGP MDT-SAFI Routes
===============================================================================
Flag Network
LocalPref
MED
Nexthop
Group-Addr
Label
As-Path
------------------------------------------------------------------------------u*>i 1:5:192.0.2.5
100
None
192.0.2.4
239.255.0.1
64502

Advanced Configuration Guide

Page 1539

Configuration

Core PIM Signalling


AS 64501
PE-1
Mcast
Source

AS 64502
P-3

VRF

P-2

ASBR

PE-5

ASBR

VRF

Receiver

PIM Join SSM


Source: 192.0.2.1
Group: 239.255.1.1
RD: 1:1
NH: 192.168.13.1
RPFV: True

PIM Join SSM


Source: 192.0.2.1
Group: 239.255.1.1
RD: 1:1
NH: 192.168.23.2
RPFV: True

PIM Join SSM


Source: 192.0.2.1
Group: 239.255.1.1
RD: 1:1
NH: 192.168.25.2
RPFV: True
al_0323

Figure 145: PIM-P Signalling Steps for Default MDT

On PE-5, the debug router pim packet jp output shows the PIM join/prune message which is
sent to P-2. This message contains the original source of the multicast traffic (PE-1: 192.0.2.1) and
the RPF Vector (P-2: 192.0.2.2).
"PIM[Instance 1 Base]: Join/Prune
[007 14:55:54.020] PIM-TX ifId 3 ifName int-PE5-P2 -> 224.0.0.13 Length: 48
PIM Version: 2 Msg Type: Join/Prune Checksum: 0x8b5e
Upstream Nbr IP : 192.168.25.2 Resvd: 0x0, Num Groups 1, HoldTime 210
Group: 239.255.0.1/32 Num Joined Srcs: 1, Num Pruned Srcs: 0
Join Srcs:
192.0.2.1/32 Flag S <S,G> JA={rpfvMvpn 192.0.2.2 1:1}

On P-2, the debug router pim packet jp output shows the PIM join/prune message which is
propagated to P-3. The source of multicast traffic is untouched while the RPF Vector is modified
for Inter-AS propagation.
"PIM[Instance 1 Base]: Join/Prune
[001 12:25:19.590] PIM-TX ifId 4 ifName int-P2-P3 -> 224.0.0.13 Length: 48
PIM Version: 2 Msg Type: Join/Prune Checksum: 0x835e
Upstream Nbr IP : 192.168.23.2 Resvd: 0x0, Num Groups 1, HoldTime 210
Group: 239.255.0.1/32 Num Joined Srcs: 1, Num Pruned Srcs: 0
Join Srcs:
192.0.2.1/32 Flag S <S,G> JA={rpfvMvpn 192.168.23.2 1:1}

On P-3, the debug router pim packet jp output shows the PIM join/prune message which is
propagated to P-3. The source of multicast traffic is untouched while the RPF Vector is not present
anymore.
"PIM[Instance 1 Base]: Join/Prune

Page 1540

Advanced Configuration Guide

MVPN: Inter-AS Option B

[001 12:25:16.000] PIM-TX ifId 2 ifName int-P3-PE1 -> 224.0.0.13 Length: 34


PIM Version: 2 Msg Type: Join/Prune Checksum: 0xd694
Upstream Nbr IP : 192.168.13.1 Resvd: 0x0, Num Groups 1, HoldTime 210
Group: 239.255.0.1/32 Num Joined Srcs: 1, Num Pruned Srcs: 0
Join Srcs:
192.0.2.1/32 Flag S <S,G>

As a result of this signaling, Default MDT is established between the two ASs. This can be
checked with show router pim group command.
The PE-1 output shows the active multicast groups which are used as Default MDT.
*A:PE-1#show router pim group
===============================================================================
PIM Groups ipv4
===============================================================================
Group Address
Type
Spt Bit Inc Intf
No.Oifs
Source Address
RP
Inc Intf(S)
------------------------------------------------------------------------------239.255.0.1
(S,G)
spt
system
2
192.0.2.1
239.255.0.1
(S,G)
spt
int-PE1-P3
1
192.0.2.5

The PE-5 output shows active multicast groups which are used as Default MDT:
*A:PE-5# show router pim group
===============================================================================
PIM Groups ipv4
===============================================================================
Group Address
Type
Spt Bit Inc Intf
No.Oifs
Source Address
RP
Inc Intf(S)
------------------------------------------------------------------------------239.255.0.1
(S,G)
spt
int-PE5-P2
1
192.0.2.1
239.255.0.1
(S,G)
spt
system
2
192.0.2.5

The detailed information about the PIM-P group shows that the Default MDT is used to deliver
traffic. Key parameters such as correct the incoming/outgoing interfaces and non-zero flow rate
allow this conclusion to be made.
PE-5 has the incoming interface int-PE5-P2, outgoing interface system and flow rate of 5.4
kbps.
*A:PE-5#
show router pim group detail
Group Address
: 239.255.0.1
Source Address
: 192.0.2.1
RP Address
: 0
Advt Router
: 192.0.2.2
Upstream RPFV Nbr : 192.168.25.2
RPFV Type
: Mvpn 1:1
RPFV Proxy
Flags

: spt

Advanced Configuration Guide

Type

: 192.0.2.2
: (S,G)

Page 1541

Configuration

MRIB Next Hop


: 192.168.25.2
MRIB Src Flags
: remote
Keepalive Timer Exp: 0d 00:03:00
Up Time
: 0d 04:57:13

Resolved By

Up JP State
Up JP Rpt

Up JP Expiry
: 0d 00:00:47
Up JP Rpt Override : 0d 00:00:00

: Joined
: Not Joined StarG

: rtable-u

Register State
: No Info
Reg From Anycast RP: No
Rpf Neighbor
: 192.168.25.2
Incoming Intf
: int-PE5-P2
Outgoing Intf List : system
Curr Fwding Rate
Forwarded Packets
Forwarded Octets
Spt threshold
Admin bandwidth

:
:
:
:
:

5.4 kbps
178895
11814210
0 kbps
1 kbps

Discarded Packets : 0
RPF Mismatches
: 0
ECMP opt threshold : 7

PE-1 has incoming the interface system, outgoing interfaces system, int-PE1-P and flow rate
of 3.4 kbps.
A:PE-1# show router pim group detail
Group Address
: 239.255.0.1
Source Address
: 192.0.2.1
RP Address
: 0
Advt Router
: 192.0.2.1
Flags
: spt
MRIB Next Hop
:
MRIB Src Flags
: self
Keepalive Timer Exp: 0d 00:03:30
Up Time
: 0d 23:02:04
Up JP State
Up JP Rpt

: Joined
: Not Joined StarG

Type

: (S,G)

Resolved By

: rtable-m

Up JP Expiry
: 0d 00:00:56
Up JP Rpt Override : 0d 00:00:00

Register State
: No Info
Reg From Anycast RP: No
Rpf Neighbor
:
Incoming Intf
: system
Outgoing Intf List : system, int-PE1-P3
Curr Fwding Rate
Forwarded Packets
Forwarded Octets
Spt threshold
Admin bandwidth

Page 1542

:
:
:
:
:

3.4 kbps
826316
34805244
0 kbps
1 kbps

Discarded Packets : 0
RPF Mismatches
: 0
ECMP opt threshold : 7

Advanced Configuration Guide

MVPN: Inter-AS Option B

Customer PIM Signalling

AS 64501
PE-1
Mcast
Source

VRF

AS 64502
P-3

P-2

ASBR

ASBR

PE-5

VRF

Receiver

PIM Join SSM


Source: 172.16.1.1
Group: 232.0.0.1
Upstream N: 192.0.2.1
al_0321

Figure 146: PIM-C Signalling

The PIM-C Join is sent to the sender PE using the existing tunnel infrastructure.
On PE-5, the debug router 1 pim packet jp output shows the PIM join/prune message which is
sent to PE-1 using PMSI interface 1-mt-239.255.0.1 inside VPRN 1. All of this information and
more can be found in the output of the debug command.
49 2013/05/02 11:23:32.11 UTC MINOR: DEBUG #2001 vprn1 PIM[Instance 9 vprn1]
"PIM[Instance 9 vprn1]: Join/Prune
[006 04:23:58.880] PIM-TX ifId 16390 ifName 1-mt-239.255.0.1 -> 224.0.0.13 Len
gth: 34
PIM Version: 2 Msg Type: Join/Prune Checksum: 0xdbed
Upstream Nbr IP : 192.0.2.1 Resvd: 0x0, Num Groups 1, HoldTime 210
Group: 232.0.0.1/32 Num Joined Srcs: 1, Num Pruned Srcs: 0
Join Srcs:
172.16.1.1/32 Flag S <S,G>

The detailed information about the PIM-C group for a particular VPRN shows that default MDT is
used to deliver traffic. For this purpose the show router 1 pim group detail command is used.
Key parameters such as the correct multicast group, correct incoming/outgoing interfaces and
non-zero flow rate allow this conclusion to be made.
PE-1 has the incoming interface int-source, outgoing interface 1-mt-239.255.0.1 and flow rate
of 3.5 kbps.
*A:PE-1#show router 1 pim group detail
Group Address
: 232.0.0.1
Source Address
: 172.16.1.1
RP Address
: 192.0.2.4
Advt Router
: 192.0.2.4
Flags
: spt
MRIB Next Hop
: 172.16.1.1

Advanced Configuration Guide

Type

: (S,G)

Page 1543

Configuration

MRIB Src Flags


: remote
Keepalive Timer Exp: 0d 00:03:22
Up Time
: 0d 06:39:09

Resolved By

Up JP State
Up JP Rpt

Up JP Expiry
: 0d 00:00:50
Up JP Rpt Override : 0d 00:00:00

: Joined
: Not Pruned

: rtable-u

Register State
: No Info
Reg From Anycast RP: No
Rpf Neighbor
: 172.16.1.1
Incoming Intf
: int-source
Outgoing Intf List : 1-mt-239.255.0.1
Curr Fwding Rate
Forwarded Packets
Forwarded Octets
Spt threshold
Admin bandwidth

:
:
:
:
:

3.5 kbps
239467
10057614
0 kbps
1 kbps

Discarded Packets : 0
RPF Mismatches
: 0
ECMP opt threshold : 7

PE-5 has the incoming interface 1-mt-239.255.0.1, outgoing interface int-receiver and flow
rate of 3.5 kbps.
*A:PE-5 show router 1 pim group detail
Group Address
: 232.0.0.1
Source Address
: 172.16.1.1
RP Address
: 192.0.2.4
Advt Router
: 192.0.2.2
Flags
: spt
MRIB Next Hop
: 192.0.2.1
MRIB Src Flags
: remote
Keepalive Timer Exp: 0d 00:02:24
Up Time
: 0d 00:01:10
Up JP State
Up JP Rpt

: Joined
: Not Joined StarG

Type

: (S,G)

Resolved By

: rtable-u

Up JP Expiry
: 0d 00:00:58
Up JP Rpt Override : 0d 00:00:00

Register State
: No Info
Reg From Anycast RP: No
Rpf Neighbor
: 192.0.2.1
Incoming Intf
: 1-mt-239.255.0.1
Outgoing Intf List : int-receiver
Curr Fwding Rate
Forwarded Packets
Forwarded Octets
Spt threshold
Admin bandwidth

Page 1544

:
:
:
:
:

3.4 kbps
649
27258
0 kbps
1 kbps

Discarded Packets : 0
RPF Mismatches
: 0
ECMP opt threshold : 7

Advanced Configuration Guide

MVPN: Inter-AS Option B

When Multicast Stream Threshold is Reached

AS 64501
PE-1
Mcast
Source

AS 64502
P-3

VRF

P-2

ASBR

PE-5

ASBR

VRF

Receiver

PIM Join SSM


Source: 192.0.2.1
Group: 239.255.1.1
RD: 1:1
NH: 192.168.13.1
RPFV: True

PIM Join SSM


Source: 192.0.2.1
Group: 239.255.1.1
RD: 1:1
NH: 192.168.23.2
RPFV: True

PIM Join SSM


Source: 192.0.2.1
Group: 239.255.1.1
RD: 1:1
NH: 192.168.25.2
RPFV: True
al_0320a

Figure 147: PIM-P Signalling Steps for Data MDT

On PE-5, the debug router pim packet jp output shows the PIM join/prune message which is
sent to P-2. This message contains the original source of multicast traffic (PE-1: 192.0.2.1) and the
RPF Vector (P-2: 192.0.2.2). Note a new multicast group (239.255.1.1) which is signalled for
purposes of the Data MDT.
"PIM[Instance 1 Base]: Join/Prune
[000 09:48:16.140] PIM-TX ifId 3 ifName int-PE5-P2 -> 224.0.0.13 Length: 48
PIM Version: 2 Msg Type: Join/Prune Checksum: 0x3aae
Upstream Nbr IP : 192.168.25.2 Resvd: 0x0, Num Groups 1, HoldTime 210
Group: 239.255.1.1/32 Num Joined Srcs: 1, Num Pruned Srcs: 0
Join Srcs:
192.0.2.1/32 Flag S <S,G> JA={rpfvMvpn 192.0.2.2 1:1}

On P-2, the debug router pim packet jp output shows the PIM join/prune message which is
propagated to P-3. The source of multicast traffic is untouched while the RPF Vector is modified
for Inter-AS propagation.
"PIM[Instance 1 Base]: Join/Prune
[001 22:30:36.630] PIM-TX ifId 4 ifName int-P2-P3 -> 224.0.0.13 Length: 48
PIM Version: 2 Msg Type: Join/Prune Checksum: 0x32ae
Upstream Nbr IP : 192.168.23.2 Resvd: 0x0, Num Groups 1, HoldTime 210
Group: 239.255.1.1/32 Num Joined Srcs: 1, Num Pruned Srcs: 0
Join Srcs:
192.0.2.1/32 Flag S <S,G> JA={rpfvMvpn 192.168.23.2 1:1}

On P-3, the debug router pim packet jp output shows the PIM join/prune message which is
propagated to P-3. The source of multicast traffic is untouched while the RPF Vector is not present
anymore.

Advanced Configuration Guide

Page 1545

Configuration

"PIM[Instance 1 Base]: Join/Prune


[001 22:30:32.770] PIM-TX ifId 2 ifName int-P3-PE1 -> 224.0.0.13 Length: 34
PIM Version: 2 Msg Type: Join/Prune Checksum: 0x85e4
Upstream Nbr IP : 192.168.13.1 Resvd: 0x0, Num Groups 1, HoldTime 210
Group: 239.255.1.1/32 Num Joined Srcs: 1, Num Pruned Srcs: 0
Join Srcs:
192.0.2.1/32 Flag S <S,G>

As a result of this signaling, the Data MDT is established between the two ASs. This can be
checked with show router pim group command.
The PE-1 output shows an additional multicast group (239.255.1.3), which was created in the
global routing table (GRT).
*A:PE-1# show router pim group
===============================================================================
PIM Groups ipv4
===============================================================================
Group Address
Type
Spt Bit Inc Intf
No.Oifs
Source Address
RP
Inc Intf(S)
------------------------------------------------------------------------------239.255.0.1
(S,G)
spt
system
2
192.0.2.1
239.255.0.1
(S,G)
spt
int-PE1-P3
1
192.0.2.5
239.255.1.3
(S,G)
system
1
192.0.2.1

The PE-5 output shows an additional multicast group (239.255.1.3), which was created in the
GRT.
*A:PE-5# show router pim group
===============================================================================
PIM Groups ipv4
===============================================================================
Group Address
Type
Spt Bit Inc Intf
No.Oifs
Source Address
RP
Inc Intf(S)
------------------------------------------------------------------------------239.255.0.1
(S,G)
spt
int-PE5-P2
1
192.0.2.1
239.255.0.1
(S,G)
spt
system
2
192.0.2.5
239.255.1.3
(S,G)
int-PE5-P2
1
192.0.2.1

The detailed information about the PIM group in a VPRN shows that the Data MDT is used to
receive traffic instead of Default MDT.
The PE-5 output for multicast groups in a VPRN 1 has slightly changed: new line Incoming
SPMSI Intf was added. This indicates that the S-PMSI instance and dedicated Data MDT are
used for this particular multicast group. The non-zero rate for the multicast flow is also an
indication that multicast traffic is forwarded.

Page 1546

Advanced Configuration Guide

MVPN: Inter-AS Option B

*A:PE-5#show router 1 pim group detail


===============================================================================
PIM Source Group ipv4
===============================================================================
Group Address
: 232.0.0.1
Source Address
: 172.16.1.1
RP Address
: 192.0.2.4
Advt Router
: 192.0.2.2
Flags
: spt
Type
: (S,G)
MRIB Next Hop
: 192.0.2.1
MRIB Src Flags
: remote
Keepalive Timer Exp: 0d 00:01:10
Up Time
: 0d 00:30:21
Resolved By
: rtable-u
Up JP State
Up JP Rpt

: Joined
: Not Joined StarG

Up JP Expiry
: 0d 00:00:40
Up JP Rpt Override : 0d 00:00:00

Register State
: No Info
Reg From Anycast RP: No
Rpf Neighbor
:
Incoming Intf
:
Incoming SPMSI Intf:
Outgoing Intf List :

192.0.2.1
1-mt-239.255.0.1
1-mt-239.255.0.1*
int-receiver

Curr Fwding Rate


Forwarded Packets
Forwarded Octets
Spt threshold
Admin bandwidth

3.4 kbps
18187
763854
0 kbps
1 kbps

:
:
:
:
:

Discarded Packets : 0
RPF Mismatches
: 0
ECMP opt threshold : 7

The show router 1 pim s-pmsi detail command can also be used to verify existence of the SPMSI instance for the VPRN 1. The output is short, but very informative: the multicast group
inside VPRN, multicast source IP, multicast group which is used for S-PMSI tunneling and current
flow rate can be found.
*A:PE-5#show router 1 pim s-pmsi detail
===============================================================================
PIM Selective provider tunnels
===============================================================================
Md Source Address : 192.0.2.1
Md Group Address
: 239.255.1.1
Number of VPN SGs : 1
Uptime
: 0d 00:29:57
MT IfIndex
: 24580
Egress Fwding Rate : 3.4 kbps
VPN Group Address : 232.0.0.1
VPN Source Address : 172.16.1.1
State
: RX Joined
Expiry Timer
: 0d 00:02:23

Advanced Configuration Guide

Page 1547

Conclusion

Conclusion
Inter-AS MVPN offers flexibility for the operators who can use it to provide additional value
added services to their customers. Before implementing this feature in the network the following
are required:

Page 1548

The RPF vector must be enabled on every router for inter-AS MVPN.

Can be used only with Draft-Rosen mVPN with PIM SSM and MDT SAFI.

Advanced Configuration Guide

NAT in Combination with ESM

In This Chapter
This section provides information about Network Address Translation (NAT) in combination with
Enhanced Subscriber Management (ESM).
Topics in this section include:

Applicability on page 1550

Overview on page 1551

Configuration on page 1554

Conclusion on page 1574

Advanced Configuration Guide

Page 1549

Applicability

Applicability
This example is applicable to 7750 SR-7 and SR-12 and was tested on release 8.0R6. It is required
to have at least one Multi-Service ISA (MS-ISA) card equipped in an IOM3-XP. Chassis mode B
or higher is required.
The Alcatel-Lucent 7750 SR-7 and SR-12 supports Source Network Address and Port Translation
(SNAPT aka N:1) and Source Network Address Translation (SNAT aka 1:1) to provide continuity
of legacy IPv4 services during the migration to native IPv6.
The 7750 SR-7SR-/12 can operate in two different modes known as:

Large Scale NAT

Layer 2-Aware NAT = NAT in combination with Enhanced Subscriber Management


(ESM)

This configuration note is restricted to the Layer 2-Aware NAT.

Page 1550

Advanced Configuration Guide

NAT in Combination with ESM

Overview
Layer 2-Aware NAT performs source address and port translation as commonly deployed for
shared Internet access. The 7750 SR with NAT is used to provide consumer broadband or business
Internet customers access to IPv4 internet resources with a shared pool of IPv4 addresses, such as
may occur with the IPv4 exhaustion.
TCP/UDP connections use ports for multiplexing, with 65536 ports available for every IP address.
Whenever many hosts are trying to share a single public IP address there is a chance of port
collision where two different hosts may use the same source port for a connection. The resultant
collision is avoided in SNAPT devices by translating the source port and tracking this in a stateful
manner. All SNAPT devices are stateful in nature and must monitor connection establishment and
traffic to maintain translation mappings.
In most circumstances, SNAPT requires the inside host to establish a connection to the public
Internet host or server before a mapping and translation will occur. With the initial outbound IP
packet, the SNAPT knows the inside IP, inside port, remote IP, remote port and protocol. L2Aware NAT will also take into account the subscriber identification string. With this information
the SNAPT device can select an IP and port combination (referred to as outside IP and outside
port) from its pool of addresses and create a unique mapping for this flow of data.
Any traffic returned from the server will use the outside IP and outside port in the destination IP/
port fields matching the unique NAT mapping. The mapping then provides the inside IP and inside
port for translation.

Public Internet
Client

Residential
Gateway

Inside

Server

7750 SR

Outside
OSSG596

Figure 148: Network Address Translation Overview

Advanced Configuration Guide

Page 1551

Overview

L2-Aware NAT supports the following ESM hosts:

IP over Ethernet (IPoE)

PPP over Ethernet (PPPoE)

L2TP Network Server (LNS)

L2-Aware NAT is not supported on static- or arp-hosts.


L2-Aware NAT makes the differentiation between two interfaces. The inside interface, towards the
residential gateway and the outside interface, towards the public network, as seen in Figure 1. The
outside IP needs to be a public IP address.
NAT is supported in the base and VPRN routing contexts. NAT can originate in a VPRN routing
context and exit through a base or VPRN routing context. L2-Aware NAT allows reusing IP
address towards residential customers.
A typical flow-session will be recorded using the following fields:

Subscriber identification string

Inside IP

Outside IP

Inside port

Outside port

Inside VRFid

Outside VRFid

This configuration note will focus on the NAT configuration and functionality. For completeness
other configuration will be given, but not explained in detail. Two IPoE clients will be set up with
the same IP address inside one VPRN. One PPPoE client will be set up inside a different VPRN as
the public VPRN.

Page 1552

Advanced Configuration Guide

NAT in Combination with ESM

Server Functionality Behind NAT


Applications which operate as servers (such as HTTP, SMTP, etc) or Peer-to-Peer (P2P)
applications can have difficulty when operating behind an SNAPT because traffic from the
Internet can reach the NAT without a mapping in place.
Different methods can be employed to overcome this, including:

Port forwarding

STUN support

Application Layer Gateways (ALG)

The 7750 SR supports all three methods following the best-practice RFC for TCP (RFC 5382,
NAT Behavioral Requirements for TCP ) and UDP (RFC 4787, Network Address Translation
(NAT) Behavioral Requirements for Unicast UDP ). Port Forwarding setup, supported in this
release through SNMP only, allows servers which operate on well-known ports <1024 (such as
HTTP and SMTP) to request the appropriate outside port for permanent allocation.
STUN is facilitated by the support of Endpoint-Independent Filtering and Endpoint-Independent
Mapping (RFC 4787) in the NAT device, allowing STUN-capable applications to detect the NAT
and allow inbound P2P connections for that specific application. Many new voice over IP clients
and instant messaging chat applications are STUN capable.
Application Layer Gateways (ALG) allow the NAT to monitor the application running over TCP
or UDP and make appropriate changes in the NAT translations accordingly. The 7750 SR has an
FTP ALG enabled following the recommendation of RFC 5382, NAT Behavioral Requirements
for TCP.

Advanced Configuration Guide

Page 1553

Configuration

Configuration
Hardware Configuration
L2-aware NAT is implemented today in the 7750-SR7 and SR12 using the MS-ISA MDA hosted
in an IOM3-XP. The MS-ISA card is a multi-purpose MDA which can be used for multiple
applications like LNS, video (FCC/RET/VQE), AA (application assurance/DPI), tunneling (GRE/
IPSEC), etc. This approach allows re-deploying the same hardware in a different software
configuration for other purposes once the IPv4 to IPv6 transition is completed.
For L2-Aware NAT, configure the MS-ISA as an ISA-BB (BroadBand) MDA which allows
running L2-aware NAT, LNS and carrier grade-NAT (CG-NAT) simultaneously on the configured
MDA. CG-NAT or large scale NAT is set-up independently of ESM subscriber hosts.
configure card 1
card-type iom3-xp
...
mda 2
mda-type isa-bb
exit
exit all

An ISA NAT-group needs to be created. A NAT-group can host up to 6 MDA(s) for load-sharing
or providing resilience when an MS-ISA fails. Multiple NAT groups can be created to achieve
hardware separation between e.g. residential and business customers.
configure isa nat-group 1
description "L2 Aware NAT Group"
active-mda-limit 1
mda 1/2
no shutdown
exit all

The active-mda-limit controls the number of MS-ISA MDAs which can be used as active
members of the NAT group. Each active card will be assigned sessions/flows and will process
traffic. The backup cards are cold standby; they are used only in case of a failure of one (or more)
of the active cards. Load balancing over the active cards is done using the source ip address in the
upstream, and the outside destination IP in the downstream direction. Public IP address pools are
assigned to a specific card, thus resulting in both upstream and downstream traffic flowing
through the same MS-ISA card.
All MS-ISA cards (active + backup) need to be configured under the ISA NAT group.

Page 1554

Advanced Configuration Guide

NAT in Combination with ESM

Service Configuration
SAP
1/1/3:81

IPoE 1

VPRN 1

SAP
1/1/3:82

10.0.0.2/32

Subscriber Interface 1
Group Interface 1

IPoE 2
10.0.0.2/32

VPRN-1

NAT
VPRN 2

172.16.0.2

Server
7750 SR

Subscriber Interface 2
Group Interface 2

SAP
1/1/3:111

PPPoE 1
10.0.1.2/32

Inside

Outside
NAT IP@ = 10.255.0.1
OSSG597

Figure 149: Setup Topology

The setup used for this note is depicted in Figure 149 and Figure 150. There are three clients:
1. IPoE_1 going to SAP 1/1/3:81 in VPRN 1 (NAT to VPRN 1)
2. IPoE_2 going to SAP 1/1/3:82 in VPRN 1 (NAT to VPRN 1)
3. PPPoE_1 going to SAP 1/1/3:111 in VPRN 2 (NAT to VPRN 1)

SAP 1/1/3:81
SAP 1/1/3:82

VPRN 1

VPRN 1
Server

SAP 1/1/3:111

VPRN 2

Network Address Translation

Inside

Outside
OSSG598

Figure 150: Simplified Routing Topology

Advanced Configuration Guide

Page 1555

Configuration

Initial Service and Enhanced Subscriber Management Configuration


The initial service and ESM configuration is given below for VPRN 1. This VPRN contains
subscriber interface sub-int-1 with group interface group-int-ipoe-cpe, in routed central office
(CO). There are two SAPs under the group interface, 1/1/3:81 and 1/1/3:82. The subscribers are IP
over Ethernet subscribers. Upon receiving a DHCP request the subscriber will first be
authenticated using radius authentication. A DHCP emulation server is configured under the
group interface.
configure service vprn 1
route-distinguisher 64500:1
vrf-target target:64500:1
interface "int-PE-1-servers" create
address 172.16.0.1/30
sap 1/1/4:110 create
exit
exit
subscriber-interface "sub-int-1" create
address 10.0.0.254/24
dhcp
gi-address 10.0.0.254 src-ip-addr
exit
group-interface "group-int-ipoe-cpe" create
arp-populate
dhcp
proxy-server
emulated-server 10.0.0.254
lease-time hrs 1
no shutdown
exit
trusted
lease-populate 10
gi-address 10.0.0.254 src-ip-addr
no shutdown
exit
authentication-policy "radiusAuth"
sap 1/1/3:81 create
sub-sla-mgmt
sub-ident-policy "sub-ident-all"
multi-sub-sap 10
no shutdown
exit
exit
sap 1/1/3:82 create
sub-sla-mgmt
sub-ident-policy "sub-ident-all"
multi-sub-sap 10
no shutdown
exit
exit
exit
exit
no shutdown
exit all

Page 1556

Advanced Configuration Guide

NAT in Combination with ESM

All parameters are returned by the radius server, including all ESM strings as well as IP address,
mask, default gateway and session timeout.
The RADIUS user configuration is given below. The userss mac-address is used to authenticate
the IPoE of PPPoE sessions.
00:0c:29:9d:10:2d

00:0c:29:34:cc:74

Cleartext-Password := "admin"
Alc-Subsc-ID-Str = "ipoe_sub_00:0c:29:9d:10:2d",
Alc-SLA-Prof-Str = "sla-profile-nat",
Alc-Subsc-Prof-Str = "sub-profile-nat",
Framed-IP-Address = 10.0.0.2,
Framed-IP-Netmask = 255.255.255.0,
Alc-Default-Router = 10.0.0.254,
Session-Timeout = 3600
Cleartext-Password := "admin"
Alc-Subsc-ID-Str = "ipoe_sub_00:0c:29:34:cc:74",
Alc-SLA-Prof-Str = "sla-profile-nat",
Alc-Subsc-Prof-Str = "sub-profile-nat",
Framed-IP-Address = 10.0.0.2,
Framed-IP-Netmask = 255.255.255.0,
Alc-Default-Router = 10.0.0.254,
Session-Timeout = 3600

00:0c:29:1d:44:34 Auth-Type := Local, User-Password == "admin"


Alc-Subsc-ID-Str = "pppoe_sub_%{User-Name}",
Alc-SLA-Prof-Str = "sla-profile-nat",
Alc-Subsc-Prof-Str = "sub-profile-nat",
Framed-IP-Address = 10.0.1.2,
Framed-IP-Netmask = 255.255.255.0,
Alc-Default-Router = 10.0.1.254

The subscriber management policies are as follows.


configure subscriber-mgmt
authentication-policy "radiusPPP" create
password "B7O7GD4VdMqISRo2VWbZqn14IyuUXUDb" hash2
radius-authentication-server
router "management"
server 1 address 172.16.40.108 secret "j3VRf4lH1u1XI/RJOb4LkE" hash2
exit
exit
authentication-policy "radiusAuth" create
password "2VL2PrE6sZJRQPY6ipW7ifwOFyEsqb/k" hash2
radius-authentication-server
router "management"
server 1 address 172.16.15.58 secret "j3VRf4lH1u./Gx3thvq7Tk" hash2
exit
exit
sla-profile "sla-profile-nat" create
exit
sub-profile "sub-profile-nat" create
exit
sub-ident-policy "sub-ident-all" create
sub-profile-map
use-direct-map-as-default
exit

Advanced Configuration Guide

Page 1557

Configuration

sla-profile-map
use-direct-map-as-default
exit
exit
exit all

The initial service and ESM configuration is given below for VPRN 2. This VPRN contains
subscriber interface sub-int-2 with group interface group-int-pppoe-cpe, in routed CO. There is
one SAP under the group interface, 1/1/3:111. The subscribers are PPP over Ethernet, using radius
as authentication method.
configure service vprn 2
route-distinguisher 64500:2
vrf-target target:64500:2
subscriber-interface "sub-int-2" create
address 10.0.1.254/24
group-interface "group-int-pppoe-cpe" create
authentication-policy "radiusPPP"
sap 1/1/3:111 create
sub-sla-mgmt
sub-ident-policy "sub-ident-all"
multi-sub-sap 10
no shutdown
exit
exit
pppoe
session-limit 10
sap-session-limit 10
no shutdown
exit
exit
exit
no shutdown
exit all

Page 1558

Advanced Configuration Guide

NAT in Combination with ESM

Successful Creation of a NAT Subscriber


When a subscriber-host is created and a NAT-policy is defined, its inside IP address should fall
within the L2-Aware range (see next section). If this is not the case the subscriber-host creation
will fail. As mentioned before NAT is not supported on static-hosts. The subscriber-host creation
is shown in Figure 151. If the subscriber-host does not get an inside or outside IP address, it would
not be able to communicate with any servers on the outside.

Create ESM Host

IP Within
L2-aware
Range?

Yes

Yes

Static Host?

NAT-policy
Defined?

Yes

No

No

Yes

NAT-policy
Defined?

No

Allow Create
Normal Host

Create Refused

No

Allow Create
NAT Host
OSSG599

Figure 151: Subscriber-Host Creation Flow

Advanced Configuration Guide

Page 1559

Configuration

NAT Inside Configuration


The residential gateway subnets which are to be NATed need to be configured under the nat inside
L2-Aware context. For this configuration note all subscribers belonging to VPRN 1 will be
allocated an address in subnet 10.0.0.0/24. All subscribers belonging to VPRN 2 will be allocated
an IP address in subsnet 10.0.1.0/24. Hosts in these services within these subnets will be subject to
L2-Aware NAT if they have the correct nat-policy in their subscriber profile.
The actual address configured here will act as the local IP address of the system. Hosts connected
to the inside service will be able to ARP for this address. To verify connectivity, a host can also
ping the address. This address is typically used as next hop of the default route of a L2-Aware
host.
configure service vprn 1
nat
inside
l2-aware
address 10.0.0.254/24
exit
exit
exit
exit all
configure service vprn 2
nat
inside
l2-aware
address 10.0.1.254/24
exit
exit
exit
exit all

Page 1560

Advanced Configuration Guide

NAT in Combination with ESM

NAT Outside Configuration


The NAT outside pool needs to be configured on the VPRN facing the outside world, e.g. the
public internet. The NAT outside pool controls the NAT type, which in this case is l2-aware, and
the NAT group to send the traffic to.
These addresses will be used to as source addresses for all packets in the upstream direction
(toward the public internet) and as destination address for all packets in the downstream direction.
configure service vprn 1
nat
outside
pool "nat-outside-pool-1" nat-group 1 type l2-aware create
port-reservation blocks 128
address-range 10.255.0.1 10.255.0.10 create
exit
no shutdown
exit
exit
exit
exit all

The port-reservation command specifies the number of port-blocks (blocks of consecutive usable
port numbers) per IP address. In this configuration, each public IP address is subdivided into 128
port blocks which can be used for NAT, that results in 504 public ports per block.

Advanced Configuration Guide

Page 1561

Configuration

Binding Inside NAT, Outside NAT and ESM Host


In order to bind the inside part of the NAT with the outside part a nat-policy needs to be created,
under the service nat level. The outside nat-pool, which is associated with the VPRN instance in
this example, and outside IP addresses, is configured under the nat-policy.
configure service nat
nat-policy "nat-l2aware-vprn1" create
pool "nat-outside-pool-1" router 1
exit

This nat-policy is then associated to the different subscribers by means of the subscriber profile.
The ESM host traffic will be diverted to the NAT device.
configure subscriber-mgmt sub-profile "sub-profile-nat"
nat-policy "nat-l2aware-vprn1"
exit all

The nat-policy also controls the following parameters:


Filtering Two filtering modes are available, endpoint-independent (default configuration) and
address-and-port dependent filtering. The filtering behavior will control which upstream packets
are transmitted (based on the existing sessions). If endpoint-independent filtering is configured,
any outside host/port can use mappings the NAT has created to send traffic to the inside. If
address-and-port-dependent filtering is selected, only packets from the same destination and port
which created the mapping will be processed.
Port limits A number of ports can be reserved for prioritized sessions. A session is considered
as a priority-session depending on its forwarding class. High and low watermarks can be
configured to trigger alarms based on the port usage.
The reserved resources mean that if the resources get down to the level that there is only the
reserved amount left, this leftover can only be used by priority sessions, not taking into account
the amount of priority sessions already set up at that point.
Example: By default each host is assigned 504 outside ports. 100 of these ports can be reserved for
the EF and H1 forwarding classes. As soon as any given host reaches 404 utilized outside ports,
the remaining 100 will only be used for EF or H1 sessions.
Priority sessions The forwarding classes for which the sessions should be prioritized in terms of
port or session assignment can be configured here. Multiple forwarding classes can be configured.
Session limits A maximum number of sessions can be configured for each subscriber
associated with this nat-policy. A number of sessions can be reserved for prioritized sessions.
Sessions are prioritized based on forwarding class. High and low watermarks can be configured to
trigger alarms based on the session usage.

Page 1562

Advanced Configuration Guide

NAT in Combination with ESM

Notes:

The reserved sessions and reserved ports are not the same. A user can have many
applications contacting the same destination. Many different source ports will be used,
therefore many different outside ports. A user can have one application contacting many
different destinations. The same source port, but many different destination IP addresses
will be used. Only one outside port is consumed, but many sessions exist.

It is possible to configure a reserved ports session-limit on the nat-group as well. In case


both per Layer 2 aware host and per nat-group limits are configured the most restrictive
will be enforced.

Timeouts Several timeouts can be configured.


icmp-query: Timeout applied to an ICMP query session.
tcp-established: The idle timeout applied to a TCP session in the established state.
tcp-syn: The timeout applied to a TCP session in the SYN state.
tcp-time-wait: Time-wait assassination is enabled by default to quickly remove TCP
mappings in the time-wait state.
tcp-transitory: The idle timeout applied to a TCP session in a transitory state. TCP
transition between SYN and Open.
udp: All udp streams (with exceptions of udp-initial and udp-dns).
udp-initial: UDP mapping timeout applied to new sessions. Applicable when only 1
UDP packet is sent.
udp-dns: Only traffic to destination UDP port 53

Advanced Configuration Guide

Page 1563

Configuration

Advanced Topics
RADIUS Accounting
RADIUS accounting is extended with a new attribute, nat-port-range, reporting the NAT port
range in use by the subscriber. In order to configure RADIUS accounting, first the RADIUS
accounting policy must be created.
configure subscriber-mgmt radius-accounting-policy "nat-accounting" create
update-interval 5
include-radius-attribute
mac-address
nat-port-range
subscriber-id
exit
radius-accounting-server
router "management"
server 1 address 172.16.15.58 secret "j3VRf4lH1u./Gx3thvq7Tk" hash2
exit
exit all

The configuration specifies which attributes to include in the radius accounting messages towards
the configured server. The update interval is specified in minutes. Every 5 minutes an update will
be sent to the radius accounting server.
Then this RADIUS accounting policy must be attached to the subscriber profile.
configure subscriber-mgmt sub-profile "sub-profile-nat"
nat-policy "nat-l2aware-vprn1"
radius-accounting-policy "nat-accounting"

Page 1564

Advanced Configuration Guide

NAT in Combination with ESM

Hardware Resource Monitoring


It is possible to define watermarks to monitor the actual usage of sessions and/or ports. For each
watermark, a high and a low value have to be set (as a percentage). Once the high value is reached,
a notification will be sent. As soon as the usage drops below the low watermark, another
notification (trap) will be sent.
Watermarks can be defined on nat-group, pool and policy level.

Nat-group Watermarks can be configured to monitor the total number of sessions on an


MDA

configure isa nat-group 1


session-limits
watermarks high 90 low 80
exit
exit all

Pool Watermarks can be configured to monitor the total number of blocks in use in a
pool

configure service vprn 1 nat outside pool "nat-outside-pool-1"


watermarks high 90 low 80
exit all

Policy In the policy it is possible to define watermarks on session and port usage. The
usage per subscriber will be monitored.

configure service nat nat-policy "nat-l2aware-vprn1"


port-limits
watermarks high 90 low 80
exit
session-limits
watermarks high 90 low 80
exit
exit all

Advanced Configuration Guide

Page 1565

Configuration

Outside IP Address Range Management


From an operational point of view it may be required to unprovision an outside IP address range.
To that end, the drain has been introduced. If configured, no new sessions will be set up using this
address-range. Existing mappings will cease to exist only when the session ends (tcp fin, fin ack,
ack) or other timeout mechanism.
configure service vprn 1
nat
outside
pool "nat-outside-pool-1" nat-group 1 type l2-aware create
port-reservation blocks 128
address-range 10.255.0.1 10.255.0.10 create
drain
exit
no shutdown
exit
exit
exit
exit all

When all sessions have drained the address-range can be unprovisioned.

Quality of Service
NAT is fully transparent in terms of quality of service. The quality of service is determined on
ingress into the service router. A forwarding class is assigned to each packet and is retained
throughout the whole router.
For L2-aware NAT a virtual port exists on the carrier IOM, nat-in-l2. This port is modelled as a
network port with per FC queues both on ingress and egress. On network-ingress per destination
queues are implemented, making sure head of line blocking cannot happen.

Page 1566

Advanced Configuration Guide

NAT in Combination with ESM

Operation
The MS-ISA card should be in operational up state.
A:PE-1# show mda
===============================================================================
MDA Summary
===============================================================================
Slot Mda
Provisioned
Equipped
Admin
Operational
Mda-type
Mda-type
State
State
------------------------------------------------------------------------------1
1
m20-1gb-xp-sfp
m20-1gb-xp-sfp
up
up
2
isa-bb
isa-ms
up
up
===============================================================================
A:PE-1#

The NAT group should be configured, with at least one pool of outside IP addresses associated
with it.
A:PE-1# show isa nat-group 1
===============================================================================
ISA NAT Group 1
===============================================================================
L2 Aware NAT Group
Admin state
: inService
Operational state : inService
Active MDA limit : 1
Reserved sessions : 0
High Watermark (%): (Not Specified)
Low Watermark (%) : (Not Specified)
Last Mgmt Change : 01/18/2011 13:27:40
===============================================================================
===============================================================================
ISA NAT Group 1 members
===============================================================================
Group Member
State
Mda Addresses Blocks
Se-% Hi Se-Prio
------------------------------------------------------------------------------1
1
active
1/2 1
3
< 1 N 0
------------------------------------------------------------------------------No. of members: 1
===============================================================================

Advanced Configuration Guide

Page 1567

Configuration

The following table describes the show isa nat-group output fields.
Field

Description

Group

This is the group-id

Member

All members will be listed with associated parameters

State

The operational state of each member

MDA

The MDA position of the member

Addresses

The number of outside ip addresses assigned to the member

Blocks

The number of allocated port-blocks

Se-%

The actual session usage in percentage

Hi

High watermark reached (Y/N)

Se-Prio

The configured number of priority sessions

A:PE-1# show isa nat-group 1 associations


===============================================================================
ISA NAT Group 1 pool associations
===============================================================================
Pool
Router
------------------------------------------------------------------------------nat-outside-pool-1
vprn1
------------------------------------------------------------------------------No. of pools: 1
===============================================================================

The subscriber-hosts should be created correctly.


A:PE-1# show service id 1 subscriber-hosts
=============================================================
Subscriber Host table
=============================================================
Sap
Subscriber
IP Address
MAC Address
PPPoE-SID Origin
Fwding State
------------------------------------------------------------1/1/3:81
ipoe_sub_00:0c:29:9d:10:2d
10.0.0.2
00:0c:29:9d:10:2d
N/A
DHCP
Fwding
1/1/3:82
ipoe_sub_00:0c:29:34:cc:74
10.0.0.2
00:0c:29:34:cc:74
N/A
DHCP
Fwding
------------------------------------------------------------Number of subscriber hosts : 2
=============================================================

Page 1568

Advanced Configuration Guide

NAT in Combination with ESM

A:PE-1# show service id 2 subscriber-hosts


=============================================================
Subscriber Host table
=============================================================
Sap
Subscriber
IP Address
MAC Address
PPPoE-SID Origin
Fwding State
------------------------------------------------------------1/1/3:111
pppoe_sub_00:0c:29:1d:44:34
10.0.1.2
00:0c:29:1d:44:34
1
IPCP
Fwding
------------------------------------------------------------Number of subscriber hosts : 1
=============================================================

The associated L2-Aware NAT subscriber-hosts are visible from CLI. The associated group,
member and ports can be viewed using this command.
A:PE-1# show service nat l2-aware-subscribers
===============================================================================
Layer-2-Aware NAT subscribers
===============================================================================
Subscriber
Policy
Group/Member
Outside IP
Router
Ports
------------------------------------------------------------------------------ipoe_sub_00:0c:29:34:cc:74
nat-l2aware-vprn1
1/1
10.255.0.1
1
1024-1527
ipoe_sub_00:0c:29:9d:10:2d
nat-l2aware-vprn1
1/1
10.255.0.1
1
1528-2031
pppoe_sub_00:0c:29:1d:44:34
nat-l2aware-vprn1
1/1
10.255.0.1
1
2032-2535
------------------------------------------------------------------------------No. of subscribers: 3
===============================================================================

A:PE-1# show service active-subscribers


===============================================================================
Active Subscribers
===============================================================================
------------------------------------------------------------------------------Subscriber ipoe_sub_00:0c:29:34:cc:74 (sub-profile-nat)
------------------------------------------------------------------------------NAT Policy: nat-l2aware-vprn1
Outside IP: 10.255.0.1 (vprn1)
Ports
: 1024-1527
------------------------------------------------------------------------------------------------------------------------------------------------------------(1) SLA Profile Instance sap:1/1/3:82 - sla:sla-profile-nat
------------------------------------------------------------------------------IP Address
MAC Address
PPPoE-SID Origin
-------------------------------------------------------10.0.0.2
00:0c:29:34:cc:74 N/A
DHCP

Advanced Configuration Guide

Page 1569

Configuration

------------------------------------------------------------------------------Subscriber ipoe_sub_00:0c:29:9d:10:2d (sub-profile-nat)


------------------------------------------------------------------------------NAT Policy: nat-l2aware-vprn1
Outside IP: 10.255.0.1 (vprn1)
Ports
: 1528-2031
------------------------------------------------------------------------------------------------------------------------------------------------------------(1) SLA Profile Instance sap:1/1/3:81 - sla:sla-profile-nat
------------------------------------------------------------------------------IP Address
MAC Address
PPPoE-SID Origin
-------------------------------------------------------10.0.0.2
00:0c:29:9d:10:2d N/A
DHCP
------------------------------------------------------------------------------Subscriber pppoe_sub_00:0c:29:1d:44:34 (sub-profile-nat)
------------------------------------------------------------------------------NAT Policy: nat-l2aware-vprn1
Outside IP: 10.255.0.1 (vprn1)
Ports
: 2032-2535
------------------------------------------------------------------------------------------------------------------------------------------------------------(1) SLA Profile Instance sap:1/1/3:111 - sla:sla-profile-nat
------------------------------------------------------------------------------IP Address
MAC Address
PPPoE-SID Origin
-------------------------------------------------------10.0.1.2
00:0c:29:1d:44:34 1
IPCP
------------------------------------------------------------------------------Number of active subscribers : 3
===============================================================================

Traffic arriving on the 7750 SR from the outside should be routed to the correct MS-ISA card
(=NAT device).
The route table of VPRN 1 indicates that all traffic towards publicly visible IP addresses are
routed to the NAT device, group 1 member 1. In other words all packets coming from the outside
towards the 10.255.0.1 to 10.255.0.10 IP addresses are sent to the NAT device.
A:PE-1# show router 1 route-table
===============================================================================
Route Table (Service: 1)
===============================================================================
Dest Prefix
Type
Proto
Age
Pref
Next Hop[Interface Name]
Metric
------------------------------------------------------------------------------10.0.0.0/24
Local
Local
04d18h09m
0
sub-int-1
0
10.255.0.1/32
Remote Static
04d23h15m
5
NAT outside: group 1 member 1
1
10.255.0.2/31
Remote Static
04d23h15m
5
NAT outside: group 1 member 1
1

Page 1570

Advanced Configuration Guide

NAT in Combination with ESM

10.255.0.4/30
Remote Static
04d23h15m
5
NAT outside: group 1 member 1
1
10.255.0.8/31
Remote Static
04d23h15m
5
NAT outside: group 1 member 1
1
10.255.0.10/32
Remote Static
04d23h15m
5
NAT outside: group 1 member 1
1
172.16.0.0/30
Local
Local
04d22h44m
0
int-PE-1-servers
0
------------------------------------------------------------------------------No. of Routes: 7
===============================================================================

A:PE-1# show router 2 route-table


===============================================================================
Route Table (Service: 2)
===============================================================================
Dest Prefix
Type
Proto
Age
Pref
Next Hop[Interface Name]
Metric
------------------------------------------------------------------------------10.0.1.0/24
Local
Local
03d20h14m
0
sub-int-2
0
------------------------------------------------------------------------------No. of Routes: 1
===============================================================================

Individual sessions are viewed through a tools dump command.


*A:PE-1# tools dump nat sessions
===============================================================================
Matched 6 sessions on Slot #1 MDA #2
===============================================================================
Owner
: L2-aware Subscr pppoe_sub_00:0c:29:1d:44:34
Router
: 2
Flow Type
: TCP
Timeout (sec)
: 7408
Inside IP Addr
: 10.0.1.2
Inside Port
: 1065
Outside IP Addr
: 10.255.0.1
Outside Port
: 2037
Foreign IP Addr
: 172.16.0.2
Foreign Port
: 21
------------------------------------------------------------------------------Owner
: L2-aware Subscr pppoe_sub_00:0c:29:1d:44:34
Router
: 2
Flow Type
: ICMP
Timeout (sec)
: 59
Inside IP Addr
: 10.0.1.2
Inside Identifier
: 512
Outside IP Addr
: 10.255.0.1
Outside Identifier : 2034
Foreign IP Addr
: 172.16.0.2
------------------------------------------------------------------------------Owner
: L2-aware Subscr ipoe_sub_00:0c:29:9d:10:2d
Router
: 3
Flow Type
: ICMP
Timeout (sec)
: 59
Inside IP Addr
: 10.0.0.2
Inside Identifier
: 1024
Outside IP Addr
: 10.255.0.1
Outside Identifier : 1536
Foreign IP Addr
: 172.16.0.2
------------------------------------------------------------------------------Owner
: L2-aware Subscr ipoe_sub_00:0c:29:9d:10:2d
Router
: 3
Flow Type
: TCP
Timeout (sec)
: 7369
Inside IP Addr
: 10.0.0.2
Inside Port
: 1070
Outside IP Addr
: 10.255.0.1
Outside Port
: 1538

Advanced Configuration Guide

Page 1571

Configuration

Foreign IP Addr
: 172.16.0.2
Foreign Port
: 21
------------------------------------------------------------------------------Owner
: L2-aware Subscr ipoe_sub_00:0c:29:34:cc:74
Router
: Base
Flow Type
: TCP
Timeout (sec)
: 7439
Inside IP Addr
: 10.0.0.2
Inside Port
: 1035
Outside IP Addr
: 10.255.0.1
Outside Port
: 1043
Foreign IP Addr
: 172.16.0.2
Foreign Port
: 80
------------------------------------------------------------------------------Owner
: L2-aware Subscr ipoe_sub_00:0c:29:34:cc:74
Router
: Base
Flow Type
: ICMP
Timeout (sec)
: 59
Inside IP Addr
: 10.0.0.2
Inside Identifier
: 512
Outside IP Addr
: 10.255.0.1
Outside Identifier : 1034
Foreign IP Addr
: 172.16.0.2
------------------------------------------------------------------------------===============================================================================

The resources on the MS-ISA can also be viewed through a tools dump command.
A:PE-1# tools dump nat isa resources mda 1/2
Resource Usage for Slot #1 Mda #2:
| Total
| Allocated | Free
-------------------------------+------------+------------+-----------Flows |
4194304 |
0 |
4194304
Policies |
256 |
1 |
255
Port-ranges |
262144 |
3 |
262144
Ports | 201326592 |
0 | 201326592
IP-addresses |
1024 |
1 |
1024
Large-scale hosts |
131072 |
0 |
131072
L2-aware subscribers |
65536 |
3 |
65536
L2-aware hosts |
65536 |
3 |
65536
Delayed ICMP's |
200 |
0 |
200
FTP ALG session |
65536 |
0 |
65536

The alarm configuration can be verified for the NAT related traps.
A:PE-1# show log event-control "nat"
=======================================================================
Log Events
=======================================================================
Application
ID#
Event Name
P
g/s
Logged
Dropped
----------------------------------------------------------------------2001 tmnxNatPlL2AwBlockUsageHigh
WA gen
1
0
2002 tmnxNatIsaMemberSessionUsageHigh WA gen
0
0
2003 tmnxNatPlLsnMemberBlockUsageHigh WA gen
0
0
2004 tmnxNatLsnSubIcmpPortUsageHigh
WA gen
0
0
2005 tmnxNatLsnSubUdpPortUsageHigh
WA gen
0
0
2006 tmnxNatLsnSubTcpPortUsageHigh
WA gen
0
0
2007 tmnxNatL2AwSubIcmpPortUsageHigh WA gen
0
0
2008 tmnxNatL2AwSubUdpPortUsageHigh
WA gen
0
0
2009 tmnxNatL2AwSubTcpPortUsageHigh
WA gen
0
0
2010 tmnxNatL2AwSubSessionUsageHigh
WA gen
0
0
2011 tmnxNatLsnSubSessionUsageHigh
WA gen
0
0

Page 1572

Advanced Configuration Guide

NAT in Combination with ESM

2012 tmnxNatPlBlockAllocationLsn
MI sup
0
0
2013 tmnxNatPlBlockAllocationL2Aw
MI sup
0
9
2014 tmnxNatResourceProblemDetected
MI gen
0
0
2015 tmnxNatResourceProblemCause
MI gen
0
0
=======================================================================

RADIUS accounting information can be verified using the debug router radius detail command.
1 2011/01/19 18:35:22.25 CAT MINOR: DEBUG #2001 management RADIUS
"RADIUS: Accounting Request
policy nat-accounting"
2 2011/01/19 18:35:22.25 CAT MINOR: DEBUG #2001 management RADIUS
"RADIUS: Transmit
Accounting-Request(4) 172.16.15.58:1813 id 5 len 295
STATUS TYPE [40] 4 Interim-Update(3)
NAS IP ADDRESS [4] 4 172.16.15.96
SESSION ID [44] 71 ipoe_sub_00:0c:29:9d:10:2d@1/1/3:81@sla-profile-nat_2011/
01/18 14:10:09
SESSION TIME [46] 4 95113
EVENT TIMESTAMP [55] 4 1295454922
VSA [26] 172 Alcatel(6527)
SUBSC ID STR [11] 26 ipoe_sub_00:0c:29:9d:10:2d
SUBSC NAT PORT RANGE [121] 27 10.255.0.1 1528-2031 router 1
CHADDR [27] 17 00:0c:29:9d:10:2d
INPUT_INPROF_OCTETS_64 [19] 10 0x00010000000000000000
INPUT_OUTPROF_OCTETS_64 [20] 10 0x0001000000000076e86e
INPUT_INPROF_PACKETS_64 [23] 10 0x00010000000000000000
INPUT_OUTPROF_PACKETS_64 [24] 10 0x0001000000000001733c
OUTPUT_INPROF_OCTETS_64 [21] 10 0x0001000000000076ea5c
OUTPUT_OUTPROF_OCTETS_64 [22] 10 0x00010000000000000000
OUTPUT_INPROF_PACKETS_64 [25] 10 0x0001000000000001733d
OUTPUT_OUTPROF_PACKETS_64 [26] 10 0x00010000000000000000

Advanced Configuration Guide

Page 1573

Conclusion

Conclusion
L2-Aware NAT allows the delivery of an IPv4 NAT service to ESM subscribers.
This chapter shows the configuration of L2-Aware NAT together with the associated show outputs
which can be used verify and troubleshoot it.

Page 1574

Advanced Configuration Guide

PBB-Epipe

In This Chapter
This section provides information about Provider Backbone Bridging (PBB) Ethernet Virtual
Leased Line in an MPLS-based network which is applicable to all of the 7750 SR, 7450 ESS and
7710 SR routers.
Topics in this section include:

Applicability on page 1576

Overview on page 1577

Configuration on page 1579

Conclusion on page 1598

Advanced Configuration Guide

Page 1575

Applicability

Applicability
This section is applicable to all 7750 SR, 7450 ESS and 7710 SR series and was tested on release
8.0R1. There are no specific prerequisites required. The 7750 SR-c4 is supported from 8.0R4 and
higher.

Page 1576

Advanced Configuration Guide

PBB-Epipe

Overview
The draft-ietf-l2vpn-pbb-vpls-pe-model-00, Extensions to VPLS PE model for Provider Backbone
Bridging, describes the PBB-VPLS model supported by the SR OS 7.0. This model expands the
VPLS PE model to support PBB as defined by the IEEE 802.1ah.
The PBB model is organized around a B-component (backbone instance) and an I-component
(customer instance). In the Alcatel-Lucents implementation of the PBB model, the use of an
Epipe as I-component is allowed for point-to-point services. Multiple I-VPLS and Epipe services
can be all mapped to the same B-VPLS (backbone VPLS instance).
The use of Epipe scales the ELINE services as no MAC switching, learning or replication is
required in order to deliver the point-to-point service. All packets ingressing the customer SAP are
PBB-encapsulated and unicasted through the B-VPLS tunnel using the backbone destination
MAC of the remote PBB PE. All the packets ingressing the B-VPLS destined for the Epipe are
PBB de-encapsulated and forwarded to the customer SAP.
Some use cases for PBB-Epipe are:

Get a more efficient and scalable solution for point-to-point services:


Up to 8K VPLS services / box are supported (including I-VPLS or B-VPLS) and
using I-VPLS for point-to-point services takes VPLS resources as well as unnecessary
customer MAC learning. A better solution is to connect a PBB-Epipe to a B-VPLS
instance, where there is no customer MAC switching/learning.

Take advantage of the pseudowire aggregation in the M:1 model:


Many Epipe services may use only a single service and set of pseudowire over the
backbone.

Have a uniform provisioning model for both point-to-point (Epipe) and multipoint
(VPLS) services.
Using the PBB-Epipe, the core MPLS/pseudowire infrastructure does not need to be
modified: the new Epipe inherits the existing pseudowire and MPLS structure already
configured on the B-VPLS and there is no need for configuring new tunnels or
pseudowire switching instances at the core.

Knowledge of the PBB-VPLS architecture and functionality on the service router family is
assumed throughout this section. For additional information, refer to the relevant Alcatel-Lucent
user documentation.

Advanced Configuration Guide

Page 1577

Overview

The following network setup will be used throughout the rest of the chapter.

192.0.2.1

CE-5

192.0.2.11

B-VPLS instance

Epipe instance

B
192.0.2.3

MTU-1

192.0.2.31

PE-1
192.0.2.2

CE-6

MTU-2

L3
C-Eth

3
B

L3
C-Eth
I-TAG
B-Eth
MPLS
MPLS
L2

B
4

192.0.2.21

CE-7

MTU-3
B

PE-3

PE-2
L3
C-Eth
I-TAG
B-Eth
MPLS
MPLS
L2

L3
C-Eth
I-TAG
B-Eth
MPLS
MPLS
L2

L3
C-Eth
OSSG338

Figure 152: Network Topology

The setup consists of a three 7x50 SR/ESS (PE-1, PE-2 and PE-3) core and three Multi-Tenant
Unit (MTU) nodes connected to the core. The MTU nodes can be either 7x50 or 7710 Service
Routers running SR OS 7.0. A backbone VPLS instance (B-VPLS 101) will be defined in all the
six nodes, whereas two Epipe services will be defined as illustrated in Figure 152 (Epipe 3 in
nodes MTU-1 and MTU-3, Epipe 4 in nodes MTU-2 and MTU-3). Those Epipe services will be
multiplexed into the common B-VPLS 101, using the I-Service ID (ISID) field within the I-TAG
as the demultiplexer field required at the egress MTU to differentiate each specific customer. Note
that I-VPLS and Epipe services can be mapped to the same B-VPLS.
The B-VPLS domain constitutes a H-VPLS network itself, with spoke SDPs from the MTUs to
the core PE layer. Active/standby (A/S) spoke SDPs can be used from the MTUs to the PEs (like
in the MTU-1 and MTU-2 cases) or single non-redundant spoke SDPs (like MTU-3).
The protocol stack being used along the path between the CEs is represented in Figure 152.

Page 1578

Advanced Configuration Guide

PBB-Epipe

Configuration
This section describes all the relevant PBB-Epipe configuration tasks for the setup shown in
Figure 152. Note that the appropriate B-VPLS and associated IP/MPLS configuration is out of the
scope of this document. In this particular example the following protocols will be configured
beforehand in the core:

ISIS-TE as IGP with all the interfaces being level-2. Alternatively OSPF could have been
used.

RSVP-TE as the MPLS protocol to signal the transport tunnels.

LSPs between core PEs will be fast re-route protected (facility bypass tunnels) whereas
LSP tunnels between MTUs and PEs will not be protected.

The protection between MTU-1, MTU-2 and PE-1, PE-2 will be based on the A/S
pseudowire protection configured in the B-VPLS.

BGP is configured for auto-discovery, BGP-AD (Layer 2 VPN family), since FEC 129
will be used to establish the pseudowires between PEs in the core (FEC 128 between
MTU and PE nodes).

Once the IP/MPLS infrastructure is up and running, the service configuration tasks described in
the following sections can be implemented.

Advanced Configuration Guide

Page 1579

Configuration

PBB Epipe Service Configuration


In this particular example, the Epipes 3 and 4 are using the B-VPLS 101 in the core. The same BVPLS which is multiplexing the Epipe services into a common service provider infrastructure can
also be used to connect the I-VPLS instances existing in the network for multipoint services.

CE-5
(MTU-3)

192.0.2.11

172.16.1.5

00:11

192.0.2.1

172.16.57.0/24
1/1/2:5 1/1/4:5

MTU-1

00:01
1/1/1

1/1/1

192.168.4.0/30

1/1/2

B
192.168.2.0/30

1/1/2

PE-1
1/1/1
192.168.1.0/30
192.168.5.0/30

CE-6
(MTU-3)
172.16.1.6
172.16.68.0/24
1/1/4:6 1/1/4:6

MTU-2

1/1/1

1/1/1

Epipe instance

CE-7
(MTU-1)
172.16.1.7

192.0.2.31
00:31
1/1/3

1/1/1

192.168.8.0/30

PE-3
192.168.3.0/30

B
4
MTU-3

192.0.2.2
00:02

00:03

1/1/2

1/1/3

192.0.2.21
00:21
1/1/2
1/1/2
192.168.7.0/30

B-VPLS instance

192.0.2.3

1/1/3

192.168.6.0/30

1/1/2:7
1/1/4:7
172.16.57.0/24
1/1/2:8

1/1/4:8

172.16.68.0/24

CE-8
(MTU-1)
172.16.1.8

1/1/4

PE-2

OSSG346

Figure 153: Setup Detailed View

Page 1580

Advanced Configuration Guide

PBB-Epipe

B-VPLS and PBB Configuration


First, configure the B-VPLS instance that will carry the PBB traffic. There is no specific
requirement on the B-VPLS to support Epipes. The following CLI output shows the B-VPLS
configuration on MTU-1 and PE-1.
A:MTU-1>config>service# info
---------------------------------------------...
vpls 101 customer 1 b-vpls create
service-mtu 2000
pbb
source-bmac 00:11:11:11:11:11
exit
stp
shutdown
exit
mrp
no shutdown
exit
endpoint "core" create
no suppress-standby-signaling
exit
spoke-sdp 111:101 endpoint "core" create
stp
shutdown
exit
precedence primary
exit
spoke-sdp 112:101 endpoint "core" create
stp
shutdown
exit
exit
no shutdown
exit
---------------------------------------------A:MTU-1>config>service#

A:PE-1>config>service# info
---------------------------------------------...
pw-template 1 use-provisioned-sdp create
split-horizon-group "CORE"
exit
exit
vpls 101 customer 1 b-vpls create
service-mtu 2000
pbb
source-bmac 00:01:01:01:01:01
exit
bgp-ad
vpls-id 65000:101
route-target export target:65000:101 import target:65000:101
pw-template-bind 1
no shutdown

Advanced Configuration Guide

Page 1581

Configuration

exit
stp
shutdown
exit
mrp
no shutdown
exit
no shutdown
exit
---------------------------------------------A:PE-1>config>service#

The relevant B-VPLS commands are in bold.


Note that the statement b-vpls is given at creation time and therefore it cannot be added to an
existing regular VPLS instance. Besides the b-vpls statement, the B-VPLS is a regular VPLS
instance in terms of configuration, with the following exceptions:

The B-VPLS service MTU must be at least 18 bytes greater than the Epipe MTU of the
multiplexed instances. In this example, the I-VPLS instances will have the default service
MTU (1514 bytes) hence any MTU equal or greater than 1532 bytes must be configured.
In this particular example, a MTU of 2000 bytes is configured in the B-VPLS instance
throughout the network.

The source B-MAC is the MAC that will be used as a source when the PBB traffic is
originated from that node. Note that you can configure a source B-MAC per B-VPLS
instance (if there are more than one B-VPLS) or a common source B-MAC that will be
shared by all the B-VPLS instances in the node. The way to configure a common B-MAC
is shown below:

A:MTU-1>config>service# info
---------------------------------------------pbb
source-bmac 00:11:11:11:11:11
...
---------------------------------------------A:MTU-1>config>service#

The following considerations will be taken into account when configuring the B-VPLS:

B-VPLS SAPs:
Ethernet DOT1Q and NULL encapsulations are supported
Default SAP types are blocked in the CLI for the B-VPLS SAP

Page 1582

Advanced Configuration Guide

PBB-Epipe

B-VPLS SDPs:
For MPLS, both mesh and spoke SDPs with split horizon groups are supported.
Similar to regular pseudowire, the outgoing PBB frame on an SDP (for example,
Bpseudowire) contains a BVID Qtag only if the pseudowire type is Ethernet VLAN
(vc-type=vlan). If the pseudowire type is Ethernet (vc-type=ether), the BVID qtag is
stripped before the frame goes out.
BGP-AD is supported in the B-VPLS, therefore, spoke SDPs in the B-VPLS can be
signalled using FEC 128 or FEC 129. In this example, BGP-AD and FEC 129 are
used. A split-horizon group has been configured to emulate the behavior of mesh
SDPs in the core.

While MMRP is useful to optimize the flooding in the B-VPLS domain and build a
flooding tree on a per I-VPLS basis, it does not have any effect for Epipes since the
destination B-MAC used for Epipes is always the destination B-MAC configured in the
Epipe and never the group B-MAC corresponding to the IS-ID.

If a local Epipe instance is associated with the B-VPLS, local frames originated or
terminated on local Epipe(s) are PBB encapsulated or de-encapsulated using the PBB
Etype provisioned under the related port or SDP component.

By default, the PBB Etype is 0x88e7 (which is the standard one defined in the 802.1ah, indicating
that there is an I-TAG in the payload) but this PBB Etype can be changed if required due to
interoperability reasons. This is the way to change it at port and/or SDP level:
A:MTU-1# configure port 1/1/1 ethernet pbb-etype
- pbb-etype <0x0600..0xffff>
- no pbb-etype
<0x0600..0xffff>

: [1536..65535] - accepts in decimal or hex

A:MTU-1# configure service sdp 111 pbb-etype


- no pbb-etype [<0x0600..0xffff>]
- pbb-etype <0x0600..0xffff>
<0x0600..0xffff>

: [1536..65535] - accepts in decimal or hex

The following commands are useful to check the actual PBB etype.
A:MTU-1# show service sdp 111 detail | match PBB
Bw BookingFactor
: 100
PBB Etype

: 0x88e7

A:MTU-1# show port 1/1/1 | match PBB


PBB Ethertype
: 0x88e7

Advanced Configuration Guide

Page 1583

Configuration

Before the next step, the Epipe configuration, the operator can optionally configure MAC names
under the PBB context. MAC names will simplify the Epipe provisioning later on and in case of
any change on the remote node MAC address, only one configuration modification is required as
opposed as one change per affected Epipe (potentially thousands of Epipes which are terminated
onto the same remote node). The MAC names are configured under the service PBB CLI context:
*A:MTU-1# configure service pbb mac-name
- mac-name <name> <ieee-address>
- no mac-name <name>
<name>
<ieee-address>

: 32 char max
: xx:xx:xx:xx:xx:xx or xx-xx-xx-xx-xx-xx

*A:MTU-1>config>service# info
---------------------------------------------pbb
source-bmac 00:11:11:11:11:11
mac-name "MTU-1" 00:11:11:11:11:11
mac-name "MTU-2" 00:21:21:21:21:21
mac-name "MTU-3" 00:31:31:31:31:31
exit

Page 1584

Advanced Configuration Guide

PBB-Epipe

Epipe Configuration
Once the common B-VPLS is configured, the next step is the provisioning of the customer Epipe
instances. For PBB-Epipes, the I-component or Epipe is composed of an I-SAP and a PBB tunnel
endpoint which points to the backbone destination MAC address (B-DA).
The following outputs show the relevant CLI configuration for the two Epipe instances
represented in Figure 153 on page 1580. The Epipe instances are configured on the MTU devices,
whereas the core PEs are kept as customer-unaware nodes.
The following output shows the relevant Epipe commands on MTU-3.
*A:MTU-3>config>service# info
---------------------------------------------pbb
source-bmac 00:31:31:31:31:31
mac-name "MTU-1" 00:11:11:11:11:11
mac-name "MTU-2" 00:21:21:21:21:21
mac-name "MTU-3" 00:31:31:31:31:31 # It is not required to configure its own
MAC address
exit
...
epipe 3 customer 1 create
description "pbb epipe number 3"
pbb-tunnel 101 backbone-dest-mac "MTU-1" isid 3
sap 1/1/2:7 create
exit
no shutdown
exit
epipe 4 customer 1 create
description "pbb epipe number 4"
pbb-tunnel 101 backbone-dest-mac "MTU-2" isid 4
sap 1/1/2:8 create
exit
no shutdown
exit
---------------------------------------------*A:MTU-3>config>service#

Advanced Configuration Guide

Page 1585

Configuration

The following output shows the relevant commands on MTU-1 and MTU-2.
*A:MTU-1>config>service# info
---------------------------------------------epipe 3 customer 1 create
description "pbb epipe number 3"
pbb-tunnel 101 backbone-dest-mac "MTU-3" isid 3
sap 1/1/4:5 create
exit
no shutdown
exit
...
---------------------------------------------*A:MTU-1>config>service#

*A:MTU-2>config>service# info
---------------------------------------------epipe 4 customer 1 create
description "pbb epipe number 4"
pbb-tunnel 101 backbone-dest-mac "MTU-3" isid 4
sap 1/1/4:6 create
exit
no shutdown
exit
...
---------------------------------------------*A:MTU-2>config>service#

All Ethernet SAPs supported by a regular Epipe are also supported in the PBB Epipe. Note that
spoke SDPs are not supported in PBB-Epipes, for example, no spoke SDP is allowed when pbbtunnels are configured on the Epipe.
The PBB tunnel links the SAP configured to the B-VPLS 101 existing in the core. The following
parameters are accepted in the PBB tunnel configuration:
*A:MTU-2>config>service>epipe# pbb-tunnel
- pbb-tunnel <service-id> backbone-dest-mac <mac-name> isid <ISID>
- no pbb-tunnel
- pbb-tunnel <service-id> backbone-dest-mac <ieee-address> isid <ISID>
<service-id>
<mac-name>
<ieee-address>
<ISID>

:
:
:
:

[1..2147483647]
32 char max
xx:xx:xx:xx:xx:xx or xx-xx-xx-xx-xx-xx
[0..16777215]

Where:

Page 1586

The service-id matches the B-VPLS ID.

The backbone-dest-mac can be given by a MAC name (as in this configuration example)
or the MAC itself. It is recommended to use MAC names, as explained in the previous
section.

The IS ID must be specified.

Advanced Configuration Guide

PBB-Epipe

Flood Avoidance in PBB-Epipes


As already discussed in the previous section, when provisioning a PBB Epipe, the remote
backbone-dest-mac must be explicitly configured on the PBB tunnel so that the ingress PBB
node can build the 802.1ah encapsulation.
If the configured remote backbone-destination-mac is not known in the local FDB, the Epipe
customer frames will be 802.1ah encapsulated and flooded into the B-VPLS until the MAC is
learned. As previously discussed, MMRP does not help to minimize the flooding because the PBB
Epipes always use the configured backbone-destination-mac for flooding traffic as opposed to
the group B-MAC derived from the ISID.
Flooding could be indefinably prolonged in the following cases:

Configuration mistake of the backbone-destination-mac. The service will not work but
the operator will not detect the mistake since the customer traffic is not dropped at the
source node. Every single frame is turned into an unknown unicast PBB frame and hence
flooded into the B-VPLS domain.

Change the backbone-smac in the remote PE B-VPLS instance.

There is only unidirectional traffic in the Epipe service. In this case, the backbone-destmac will never be learned in the local SFIB and the frames will always be flooded into the
B-VPLS domain.

The remote node owning the backbone-destination-mac simply goes down.

In any of those cases, the operator can easily check whether the PBB Epipe is flooding into the BVPLS domain, just by looking at the flood flag in the following command output:
*A:MTU-1# show service id 3 base
===============================================================================
Service Basic Information
===============================================================================
Service Id
: 3
Vpn Id
: 0
Service Type
: Epipe
Description
: pbb epipe number 3
Customer Id
: 1
Last Status Change: 12/01/2009 19:30:33
Last Mgmt Change : 11/30/2009 20:57:01
Admin State
: Up
Oper State
: Up
MTU
: 1514
Vc Switching
: False
SAP Count
: 1
SDP Bind Count
: 0
------------------------------------------------------------------------------Service Access & Destination Points
------------------------------------------------------------------------------Identifier
Type
AdmMTU OprMTU Adm Opr
------------------------------------------------------------------------------sap:1/1/4:5
q-tag
1518
1518
Up
Up
------------------------------------------------------------------------------PBB Tunnel Point

Advanced Configuration Guide

Page 1587

Configuration

------------------------------------------------------------------------------B-vpls
Backbone-dest-MAC Isid
AdmMTU OperState Flood Oper-dest-MAC
------------------------------------------------------------------------------101
MTU-3
3
2000
Up
Yes
00:31:31:31:31:31
------------------------------------------------------------------------------Last Status Change: 11/30/2009 21:16:53
Last Mgmt Change:
11/30/2009 21:16:53
===============================================================================
*A:MTU-1#

In this particular example, the PBB Epipe 3 is flooding into the B-VPLS 101, as the flood flag
indicates. The operator can also confirm that the operational destination B-MAC for the pbbtunnel, MTU-3, has not been learned in the B-VPLS FDB:
*A:MTU-1# show service id 101 fdb pbb
======================================================================
Forwarding Database, b-Vpls Service 101
======================================================================
MAC
Source-Identifier
iVplsMACs Epipes
Type/Age
---------------------------------------------------------------------No Matching Entries
======================================================================
*A:MTU-1#

Page 1588

Advanced Configuration Guide

PBB-Epipe

Flooding Cases 1 and 2 Wrong backbone-dest-mac


Flooding cases 1 and 2 should be fixed after detecting the flooding (see previous commands) and
checking the FDBs and PBB tunnel configurations.

Flooding Case 3 Unidirectional Traffic: Virtual MEP and CCM


Configuration
For flooding case 3 (unidirectional traffic), Alcatel-Lucent recommends the use of ETH-CFM
(802.1ag/Y.1731 Connectivity Fault Management) virtual Maintenance End Points (MEPs). By
defining a virtual MEP per node terminating a PBB-Epipe, configuring the MEP mac-address to
be the source-bmac value and activating continuity check messages (ccm) we achieve a twofold
effect:

The pbb-tunnel backbone-destination-mac will always be learnt at the local FDB, as


long as the remote virtual MEP is active and sending cc messages. As a result, there will
not be flooding even if we have unidirectional traffic.

An automatic proactive OAM mechanism exists to detect failures on remote nodes, which
ultimately cause unnecessary flooding in the B-VPLS domain.

In the following network example, the virtual MEPs in B-VPLS 101: MEP11, MEP21 and MEP31
are configured.

192.0.2.1

CE-5

192.0.2.11
172.16.57.0/24
1/1/2:5 1/1/4:5

00:01

00:11

172.16.1.5

MTU-1

1/1/1

1/1/1

192.168.4.0/30

1/1/2

B
192.168.2.0/30

1/1/2

PE-1
1/1/1
192.168.1.0/30
192.168.5.0/30

172.16.1.6
172.16.68.0/24
1/1/4:6 1/1/4:6

192.0.2.21
00:21
1/1/2
1/1/2
192.168.7.0/30

1/1/1

1/1/1

MTU-2

00:02

Epipe instance
CE-7

172.16.1.7

192.0.2.31

00:03

1/1/2

1/1/3

00:31
1/1/3

1/1/1

192.168.8.0/30

B
4
MTU-3

192.0.2.2

CE-6

B-VPLS instance

192.0.2.3

1/1/3

192.168.6.0/30

PE-3

1/1/2:7
1/1/4:7
172.16.57.0/24
1/1/2:8

1/1/4:8

172.16.68.0/24

CE-8
172.16.1.8

192.168.3.0/30
1/1/4

PE-2

OSSG347

Figure 154: Virtual MEPs for Flooding Avoidance

Advanced Configuration Guide

Page 1589

Configuration

The following configuration example uses MTU-1. This CLI configuration needed for the virtual
MEP11:
# General ETH-CFM configuration required for vMEP11
*A:MTU-1>config>eth-cfm# info
---------------------------------------------domain 1 format none level 3
association 1 format icc-based name "B-VPLS-000101"
bridge-identifier 101
exit
remote-mepid 21
remote-mepid 31
exit
exit
# Actual virtual MEP configuration.
*A:MTU-1>config>service>vpls# info
---------------------------------------------...
eth-cfm
mep 11 domain 1 association 1
ccm-enable
mac-address 00:11:11:11:11:11
no shutdown
exit
exit
...
---------------------------------------------*A:MTU-1>config>eth-cfm#

Note that the MAC address configured for the MEP11 matches the MAC address configured as
the source-bmac on MTU-1, which is the backbone-destination-mac configured on the Epipe 3
pbb-tunnel on MTU-3:
*A:MTU-1>config>service# info
---------------------------------------------pbb
source-bmac 00:11:11:11:11:11
mac-name "MTU-1" 00:11:11:11:11:11
mac-name "MTU-2" 00:21:21:21:21:21
mac-name "MTU-3" 00:31:31:31:31:31
exit
---------------------------------------------*A:MTU-1>config>service#

*A:MTU-3>config>service# info
---------------------------------------------pbb
source-bmac 00:31:31:31:31:31
mac-name "MTU-1" 00:11:11:11:11:11
mac-name "MTU-2" 00:21:21:21:21:21
mac-name "MTU-3" 00:31:31:31:31:31
exit
epipe 3 customer 1 create
description "pbb epipe number 3"

Page 1590

Advanced Configuration Guide

PBB-Epipe

pbb-tunnel 101 backbone-dest-mac "MTU-1" isid 3


sap 1/1/2:7 create
exit
no shutdown
exit
---------------------------------------------*A:MTU-3>config>service#

Once MEP11 has been configured, check that MTU-3 is receiving cc messages from MEP11 with
the following command:
*A:MTU-3# show eth-cfm mep 31 domain 1 association 1 all-remote-mepids
===========================================================================
Eth-CFM Remote-Mep Table
===========================================================================
R-mepId Rx CC Rx Rdi Port-Tlv If-Tlv Peer Mac Addr
CCM status since
--------------------------------------------------------------------------11
True
False Absent
Absent 00:11:11:11:11:11 12/02/2009 11:41:30
21
True
False Absent
Absent 00:21:21:21:21:21 12/02/2009 11:33:57
===========================================================================
*A:MTU-3#

As a result of the cc messages coming from MEP11, the MTU-1 MAC is permanently learned in
the B-VPLS 101 FDB on node MTU-3, and no flooding exists:
*A:MTU-3# show service id 101 fdb pbb
======================================================================
Forwarding Database, b-Vpls Service 101
======================================================================
MAC
Source-Identifier
iVplsMACs Epipes
Type/Age
---------------------------------------------------------------------00:11:11:11:11:11 sdp:33:101
0
1
L/0
00:21:21:21:21:21 sdp:33:101
0
1
L/0
======================================================================
*A:MTU-3#

*A:MTU-3# show service id 3 base


===============================================================================
Service Basic Information
===============================================================================
Service Id
: 3
Vpn Id
: 0
Service Type
: Epipe
Description
: pbb epipe number 3
Customer Id
: 1
Last Status Change: 12/01/2009 19:30:25
Last Mgmt Change : 12/01/2009 12:25:02
Admin State
: Up
Oper State
: Up
MTU
: 1514
Vc Switching
: False
SAP Count
: 1
SDP Bind Count
: 0
------------------------------------------------------------------------------Service Access & Destination Points
------------------------------------------------------------------------------Identifier
Type
AdmMTU OprMTU Adm Opr
------------------------------------------------------------------------------sap:1/1/2:7
q-tag
1518
1518
Up
Up
-------------------------------------------------------------------------------

Advanced Configuration Guide

Page 1591

Configuration

PBB Tunnel Point


------------------------------------------------------------------------------B-vpls
Backbone-dest-MAC Isid
AdmMTU OperState Flood Oper-dest-MAC
------------------------------------------------------------------------------101
MTU-1
3
2000
Up
No
00:11:11:11:11:11
------------------------------------------------------------------------------Last Status Change: 12/01/2009 12:25:02
Last Mgmt Change:
12/01/2009 12:25:02
===============================================================================
*A:MTU-3#

Page 1592

Advanced Configuration Guide

PBB-Epipe

Flooding Case 4 Remote Node Failure


If the node owner of the backbone-dest-mac fails or gets isolated, the node where the PBB Epipe
is initiated will not detect the failure; that is, if MTU-1 fails, the Epipe 3 remote end will also fail
but MTU-3 will not detect the failure and as a result of that, MTU-3 will flood the traffic to the
network (flooding will occur after MTU-1 MAC is removed from the B-VPLS FDBs, due to either
the B-VPLS flushing mechanisms or aging).
In order to avoid/reduce flooding in this case, the following mechanisms are recommended:

Provision virtual MEPs in the B-VPLS instances terminating PBB Epipes, as already
explained. This will guarantee there is no unknown B-MAC unicast being flooded under
normal operation.

CCM timers should be provisioned based on how long the service provider is willing to
accept flooding.

*A:MTU-3# configure eth-cfm domain 1 association 1 ccm-interval


- ccm-interval {interval}
- no ccm-interval
<interval>
: {1|10|60|600} - default 10 seconds

From 8.0R1 onward, it is possible to provision discard-unknown in the B-VPLS on the


MTUs, i.e. MTU-1, MTU-2 and MTU-3, so that flooded traffic due to the destination
MAC being unknown in the B-VPLS is discarded immediately at the MTU. Note that it is
important to configure this in conjunction with the CC messages from the virtual MEPs to
ensure that the remote B-MACs are learned in both directions. If for any reason the
remote B-MACs are not in the MTU B-VPLS, no traffic will be forwarded at all on the
PBB-Epipe.

As soon as the MTU node recovers, it will start sending CC messages and the backbonemac will be learned on the backbone and MTU nodes again.

*A:PE-1# configure service vpls 101 discard-unknown


*A:PE-2# configure service vpls 101 discard-unknown
*A:PE-3# configure service vpls 101 discard-unknown

With the recommended configuration in place, in case MTU-1 fails, the backbone-dest-mac
configured on the pbb-tunnel for Epipe 3 on MTU-3 will be removed from the B-VPLS 101 on all
the nodes (either by MAC flush mechanisms on the B-VPLS or by aging). From that point on,
traffic originated from CE-7 will be discarded at MTU-3 and wont be flooded further.
As soon as MTU-1 comes back up, MEP11 will start sending CCM and as such the MTU-1 MAC
will be learnt throughout the B-VPLS 101 domain and in particular in PE-1, PE-3 and MTU-3
(note that CCM PDUs use a multicast address). From the moment MTU-1 MAC is known on the
backbone nodes and MTU-3, the traffic wont be discarded any more, but forwarded to MTU-1.

Advanced Configuration Guide

Page 1593

Configuration

PBB-Epipe Show Commands


The following commands can help to check the PBB Epipe configuration and their related
parameters.
*A:MTU-1# show service id 101 base # this is the B-VPLS
===============================================================================
Service Basic Information
===============================================================================
Service Id
: 101
Vpn Id
: 0
Service Type
: b-VPLS
Description
: (Not Specified)
Customer Id
: 1
Last Status Change: 12/02/2009 19:00:16
Last Mgmt Change : 12/02/2009 19:00:16
Admin State
: Up
Oper State
: Up
MTU
: 2000
Def. Mesh VC Id
: 101
SAP Count
: 0
SDP Bind Count
: 2
Snd Flush on Fail : Disabled
Host Conn Verify : Disabled
Propagate MacFlush: Disabled
Oper Backbone Src : 00:11:11:11:11:11
Use SAP B-MAC
: disabled
i-Vpls Count
: 0
Epipe Count
: 1
------------------------------------------------------------------------------Service Access & Destination Points
------------------------------------------------------------------------------Identifier
Type
AdmMTU OprMTU Adm Opr
------------------------------------------------------------------------------sdp:111:101 S(192.0.2.1)
n/a
8000
8000
Up
Up
sdp:112:101 S(192.0.2.2)
n/a
8000
8000
Up
Up
===============================================================================
*A:MTU-1#

*A:MTU-1# show service id 3 base # this is the Epipe


===============================================================================
Service Basic Information
===============================================================================
Service Id
: 3
Vpn Id
: 0
Service Type
: Epipe
Description
: pbb epipe number 3
Customer Id
: 1
Last Status Change: 12/02/2009 19:00:16
Last Mgmt Change : 11/30/2009 20:57:01
Admin State
: Up
Oper State
: Up
MTU
: 1514
Vc Switching
: False
SAP Count
: 1
SDP Bind Count
: 0
------------------------------------------------------------------------------Service Access & Destination Points
------------------------------------------------------------------------------Identifier
Type
AdmMTU OprMTU Adm Opr
------------------------------------------------------------------------------sap:1/1/4:5
q-tag
1518
1518
Up
Up
------------------------------------------------------------------------------PBB Tunnel Point

Page 1594

Advanced Configuration Guide

PBB-Epipe

------------------------------------------------------------------------------B-vpls
Backbone-dest-MAC Isid
AdmMTU OperState Flood Oper-dest-MAC
------------------------------------------------------------------------------101
MTU-3
3
2000
Up
No
00:31:31:31:31:31
------------------------------------------------------------------------------Last Status Change: 12/02/2009 19:00:16
Last Mgmt Change:
11/30/2009 21:16:53
===============================================================================
*A:MTU-1#

The following command shows all the Epipe instances multiplexed into a particular B-VPLS and
its status.
*A:MTU-1# show service id 101 epipe
===============================================================================
Related Epipe services for b-Vpls service 101
===============================================================================
Epipe SvcId
Oper ISID
Admin
Oper
------------------------------------------------------------------------------3
3
Up
Up
------------------------------------------------------------------------------Number of Entries : 1
------------------------------------------------------------------------------===============================================================================
*A:MTU-1#

To check the virtual MEP information, show the local virtual MEPs configured on the node:
*A:MTU-1# show eth-cfm cfm-stack-table virtual
========================================================================
CFM Virtual Stack Table
========================================================================
Service
Level Dir Md-index
Ma-index
Mep-id Mac-address
-----------------------------------------------------------------------101
3
Up
1
1
11
00:11:11:11:11:11
========================================================================
*A:MTU-1#

Advanced Configuration Guide

Page 1595

Configuration

The following command shows all the information related to the remote MEPs configured in the
association, for example, the remote virtual MEPs configured in MTU-2 and MTU-3:
*A:MTU-1# show eth-cfm mep 11 domain 1 association 1 all-remote-mepids
===========================================================================
Eth-CFM Remote-Mep Table
===========================================================================
R-mepId Rx CC Rx Rdi Port-Tlv If-Tlv Peer Mac Addr
CCM status since
--------------------------------------------------------------------------21
True
False Absent
Absent 00:21:21:21:21:21 12/02/2009 19:00:22
31
True
False Absent
Absent 00:31:31:31:31:31 12/02/2009 19:00:21
===========================================================================
*A:MTU-1#

The following command shows the detail information and status of the local virtual MEP
configured in MTU-1:
*A:MTU-1# show eth-cfm mep 11 domain 1 association 1
------------------------------------------------------------------------------Mep Information
------------------------------------------------------------------------------Md-index
: 1
Direction
: Up
Ma-index
: 1
Admin
: Enabled
MepId
: 11
CCM-Enable
: Enabled
SvcId
: 101
FngState
: fngReset
ControlMep
: False
LowestDefectPri
: macRemErrXcon
HighestDefect
: none
Defect Flags
: None
Mac Address
: 00:11:11:11:11:11
CcmLtmPriority
: 7
CcmTx
: 2873
CcmSequenceErr
: 0
Eth-1Dm Threshold : 3(sec)
Eth-Ais:
: Disabled
Eth-Tst:
: Disabled
CcmLastFailure Frame:
None
XconCcmFailure Frame:
None
------------------------------------------------------------------------------*A:MTU-1#

Page 1596

Advanced Configuration Guide

PBB-Epipe

When there is a failure on a remote Epipe node, as discussed, the source node keeps sending
traffic. The 802.1ag/Y.1731 virtual MEP configured can help to detect and troubleshoot the
problem. For instance, when a failure happens in MTU-3 (node goes down or the B-VPLS
instance is shut down), the virtual MEP show commands will show the following information:
*A:MTU-1# show eth-cfm mep 11 domain 1 association 1
------------------------------------------------------------------------------Mep Information
------------------------------------------------------------------------------Md-index
: 1
Direction
: Up
Ma-index
: 1
Admin
: Enabled
MepId
: 11
CCM-Enable
: Enabled
SvcId
: 101
FngState
: fngDefectReported
ControlMep
: False
LowestDefectPri
: macRemErrXcon
HighestDefect
: defRemoteCCM
Defect Flags
: bDefRDICCM bDefRemoteCCM
Mac Address
: 00:11:11:11:11:11
CcmLtmPriority
: 7
CcmTx
: 2934
CcmSequenceErr
: 0
Eth-1Dm Threshold : 3(sec)
Eth-Ais:
: Disabled
Eth-Tst:
: Disabled
CcmLastFailure Frame:
None
XconCcmFailure Frame:
None
------------------------------------------------------------------------------*A:MTU-1#

The bDefRemoteCCMdefect flag clearly shows that there is a remote MEP in the association
which has stopped sending CCMs. In order to find out which node is affected, look at the
following output:
*A:MTU-1# show eth-cfm mep 11 domain 1 association 1 all-remote-mepids
===========================================================================
Eth-CFM Remote-Mep Table
===========================================================================
R-mepId Rx CC Rx Rdi Port-Tlv If-Tlv Peer Mac Addr
CCM status since
--------------------------------------------------------------------------21
True
True
Absent
Absent 00:21:21:21:21:21 12/02/2009 19:00:22
31
False False Absent
Absent 00:00:00:00:00:00 12/02/2009 19:47:37
===========================================================================
*A:MTU-1#

CCMs are no longer received from virtual MEP 31 (the one defined in MTU-3) and since 12/02/
2009 19:47:37. This conveys which node has failed and when.

Advanced Configuration Guide

Page 1597

Conclusion

Conclusion
Point-to-Point Ethernet services can use the same operational model followed by PBB VPLS for
multipoint services. In other words, Epipes can be linked to the same B-VPLS domain being used
by I-VPLS instances and use the existing H-VPLS network infrastructure in the core. The use of
PBB Epipes reduces dramatically the number of services and pseudowires in the core and
therefore allows the service provider to scale the number of ELINE services in the network.
The example used in this document shows the configuration of the PBB Epipes as well as all the
related features which are required for this environment. Show commands have also been
suggested so that the operator can verify and troubleshoot the service.

Page 1598

Advanced Configuration Guide

PBB-VPLS

In This Chapter
This section provides information about Provider Backbone Bridging (PBB) in an MPLS-based
network.
Topics in this section include:

Applicability on page 1600

Overview on page 1602

Configuration on page 1603

Conclusion on page 1638

Advanced Configuration Guide

Page 1599

Applicability

Applicability
This chapter is applicable to the 7750 SR, 710 SR and 7450 ESS series and was tested on Release
8.0.R6. Note that from 8.0R6 onward, the MAC notification and use-sap-bmac features no longer
require chassis-mode D, however, a network-mode D (described in the Access Dual-Homing and
MAC-notification section) is required .1

1.Although it can be used in an MPLS-based PBB network as explained in this document, the MAC notification feature for dual-homed access is normally used in native PBB networks.

Page 1600

Advanced Configuration Guide

PBB-VPLS

Summary
The draft-ietf-l2vpn-pbb-vpls-pe-model-00, Extensions to LDP Signaling for PBB-VPLS,
describes the PBB-VPLS model supported by the SR OS 7.0. This model expands the VPLS PE
model to support PBB as defined by the IEEE 802.1ah.
PBB-VPLS combines the best of the PBB and VPLS technologies to deliver the most scalable
multi-point Layer-2 VPN in the market. PBB-VPLS inherits all the benefits derived from MPLS
(for example, sub-50ms FRR protection, traffic engineering, no need for MSTP in the backbone)
while greatly increasing the scalability of the network by providing MAC hiding, service
multiplexing and pseudowire aggregation.
The SR OS 7.0 PBB-VPLS implementation also includes support for:

MMRP (Multiple MAC Registration Protocol, application within IEEE 802.1ak) for flood
containment in the backbone instances, as specified in Section 6 of the draft-ietf-l2vpnpbb-vpls-pe-model.

Extensions to LDP signaling for PBB-VPLS, according to draft-balus-l2vpn-pbb-ldp-ext00. These extensions will avoid network blackhole issues, as described in the Section 3 of
the mentioned draft.

The objective of this section is to provide the required guidelines to configure and troubleshoot a
PBB-VPLS network based on SR OS 7.0.
Knowledge of the VPLS and H-VPLS (RFC 4762, Virtual Private LAN Service (VPLS) Using
Label Distribution Protocol (LDP) Signaling) architecture and functionality is assumed
throughout this document. The most relevant concepts will be briefly explained throughout the
document, taking the network setup shown in the next section as an example. For further
information, refer to the relevant Alcatel-Lucent documentation.

Advanced Configuration Guide

Page 1601

Overview

Overview
The following network setup will be used throughout the rest of the chapter.

192.0.2.1

CE-1

192.0.2.11

1
2

192.0.2.3

MTU-1
MC-LAG

MTU-2

L3
C-Eth

L3
C-Eth
I-TAG
B-Eth
MPLS
MPLS
L2

I-VPLS Instance
192.0.2.31

CE-3

1
192.0.2.2

PE-1
B

B
2

192.0.2.21

B-VPLS Instance

B
CE-2

MTU-3
B

PE-3

CE-4

PE-2
L3
C-Eth
I-TAG
B-Eth
MPLS
MPLS
L2

L3
C-Eth
I-TAG
B-Eth
MPLS
MPLS
L2

L3
C-Eth
OSSG356

Figure 155: Network Topology

The setup consists of a three 7x50 SR/ESS (PE-1, PE-2 and PE-3) core and three MTU (MultiTenant Unit) nodes connected to the core. The MTU nodes can be either 7x50 or 7710 Service
Routers running SR OS 7.0. A backbone VPLS instance (B-VPLS 100) will be defined in all the
six nodes, whereas a few customer I-VPLS instances will be defined on the three MTU nodes.
Those I-VPLS instances will be multiplexed into the common B-VPLS, using the ISID field
within the I-TAG as the demultiplexer field at the egress MTU to differentiate each specific
customer.
The B-VPLS domain constitutes a H-VPLS network itself, with spoke SDPs from the MTUs to
the core PE layer. Active/standby spoke SDPs can be used from the MTUs to the PEs (for
example, in the MTU-1 and MTU-2 cases) or single non-redundant spoke SDPs (for example,
MTU-3). CE-2 is dual-connected to the service provider network through MC-LAG.
The protocol stack being used along the path between the CEs is represented in Figure 155.

Page 1602

Advanced Configuration Guide

PBB-VPLS

Configuration
This section describes all the relevant PBB-VPLS configuration tasks for the setup showed in
Figure 155. Note that the appropriate associated IP/MPLS configuration is out of the scope of this
document. In this particular example, the following protocols will be configured beforehand:

ISIS-TE as IGP with all the interfaces being Level-2 (OSPF-TE could have been used
instead).

RSVP-TE as the MPLS protocol to signal the transport tunnels (LDP could have been
used instead, but without fast re-route).

LSPs between core PEs will be fast re-route protected (facility bypass tunnels) whereas
LSP tunnels between MTUs and PEs will not be protected.

The protection between MTU-1, MTU-2 and PE-1, PE-2 will be based on the A/S
pseudowire protection configured in the B-VPLS.

BGP is configured for auto-discovery (Layer 2-vpn family), since FEC 129 will be used
for the pseudowires between PEs in the core.

Once the IP/MPLS infrastructure is up and running, the service configuration tasks described in
the following sections can be implemented.

Advanced Configuration Guide

Page 1603

Configuration

PBB-VPLS M:1 Service Configuration


This section explains the process to configure PBB-VPLS services in a M:1 fashion, M being the
number of customer I-VPLS services multiplexed into the same B-VPLS instance (instance 100).
An alternative configuration is 1:1, where each customer I-VPLS has its own B-VPLS. MTU-1
and PE-1 will be picked to show the relevant CLI configuration commands. Note that the bold
digits separated by colons 00:xx are abbreviations for the backbone MAC addresses.
CE-1
(MTU-3)

192.0.2.1

172.16.1.1 172.16.13.0/24 192.0.2.11


1/1/2:1 1/1/4:1
1/1/3

00:01

00:11

1/1/3

1/1/1

1/1/1

192.168.4.0/30

2
1/1/2
MTU-1
CE-2
172.16.24.0/24
(MTU-3)
192.168.6.0/30

192.168.2.0/30

1/1/2

PE-1
1/1/1
192.168.1.0/30

MTU-2

1/1/1

1/1/1

Epipe instance

00:02

00:31
1/1/3

1/1/1

192.168.8.0/30

B
2

CE-3
(MTU-1)
172.16.1.3

192.0.2.31

MTU-3

192.0.2.2

1/1/4

00:03

1/1/2

1/1/3

192.0.2.21
00:21
1/1/2
1/1/2
192.168.7.0/30

B-VPLS instance

192.0.2.3

1/1/3

172.16.1.2

192.168.5.0/30

B
B

1/1/2:3
1/1/4:3
172.16.13.0/24
1/1/2:4

1/1/4:4

172.16.24.0/24

PE-3
192.168.3.0/30

CE-4
(MTU-1)
172.16.1.4

1/1/4

PE-2

OSSG358

Figure 156: MTU-1 and PE-1 Nodes as Configuration Examples

Page 1604

Advanced Configuration Guide

PBB-VPLS

B-VPLS Configuration
The first step is to configure the B-VPLS instance that will carry the PBB traffic. The following
CLI outputs show the B-VPLS configuration.
Configuration examples:
A:MTU-1>config>service# info
---------------------------------------------onfigure
service
vpls 100 customer 1 b-vpls create
service-mtu 2000
pbb
source-bmac 00:11:11:11:11:11
exit
stp
shutdown
exit
mrp
no shutdown
exit
endpoint "core" create
no suppress-standby-signaling
exit
spoke-sdp 111:100 endpoint "core" create
stp
shutdown
exit
precedence primary
exit
spoke-sdp 112:100 endpoint "core" create
stp
shutdown
exit
exit
no shutdown
exit
A:PE-1>config>service# info
---------------------------------------------onfigure
service
pw-template 1 use-provisioned-sdp create
split-horizon-group "CORE"
exit
exit
vpls 100 customer 1 b-vpls create
service-mtu 2000
pbb
source-bmac 00:01:01:01:01:01
exit
bgp-ad
vpls-id 65000:100
route-target export target:65000:100 import target:65000:100
pw-template-bind 1
no shutdown

Advanced Configuration Guide

Page 1605

Configuration

exit
stp
shutdown
exit
mrp
no shutdown
exit
no shutdown
exit

The relevant B-VPLS commands are in bold.


Note that the statement b-vpls is given at creation time and therefore it cannot be added to a
regular existing VPLS instance. Besides the b-vpls statement, the B-VPLS is a regular VPLS
instance in terms of configuration, with the following exceptions:

The B-VPLS service MTU must be at least 18 bytes greater than the I-VPLS MTU of the
multiplexed instances. In this example, the I-VPLS instances will have the default service
MTU (1500 bytes); hence, any MTU equal or greater than 1518 bytes must be configured.
In this particular example, a MTU of 2000 bytes is configured in the B-VPLS instance
throughout the network.

The source B-MAC is the MAC that will be sourced when the PBB traffic is originated
from that node. Note that you can configure a source B-MAC per B-VPLS instance (if
there are more than one B-VPLS) or a common source B-MAC that will be shared by all
the B-VPLS instances in the box. If no specific source B-MAC is provisioned, the system
MAC address is used as the source B-MAC. Note that when using the Access MultiHoming feature for Native PBB, the source-bmac must be a configured one and never the
chassis mac address. The way to configure a common B-MAC for all the B-VPLS
instances is shown below:

A:MTU-1>config>service# info
---------------------------------------------pbb
source-bmac 00:11:11:11:11:11

The following considerations will be taken into account when configuring the B-VPLS:

B-VPLS SAPs:
Ethernet dot1q and null encapsulations are supported
Default SAP (:*) types are blocked in the CLI for the B-VPLS SAP

Page 1606

Advanced Configuration Guide

PBB-VPLS

B-VPLS SDPs:
For MPLS, both mesh and spoke SDPs with split horizon groups are supported.
Similar to regular pseudowires, the outgoing PBB frame on an SDP (for example, Bpseudowire) contains a BVID qtag only if the pseudowire type is Ethernet VLAN. If
the pseudowire type is Ethernet, the BVID qtag is stripped before the frame goes out.
BGP-AD is supported in the B-VPLS; therefore, spoke SDPs in the B-VPLS can be
signaled using FEC 128 or FEC 129. In this example, BGP-AD and FEC 129 are
used. A split-horizon group has been configured to emulate the behavior of meshSDPs in the core.

If a local I-VPLS instance is associated with the B-VPLS, local frames originated/
terminated on local I-VPLS(s) are PBB encapsulated/de-encapsulated using the PBB
etype provisioned under the related port or SDP component.

By default, the PBB etype is 0x88e7 (which is the standard one defined in 802.1ah for the I-TAG)
but this PBB etype can be changed if required due to interoperability reasons. This is the way to
change it at port and/or SDP level:
A:MTU-1# configure port 1/1/1 ethernet pbb-etype
- pbb-etype <0x0600..0xffff>
- no pbb-etype
<0x0600..0xffff>

: [1536..65535] - accepts in decimal or hex

A:MTU-1# configure service sdp 111 pbb-etype


- no pbb-etype [<0x0600..0xffff>]
- pbb-etype <0x0600..0xffff>
<0x0600..0xffff>

: [1536..65535] - accepts in decimal or hex

The following commands are useful to check the actual PBB etype.
A:MTU-1# show service sdp 111 detail | match PBB
Bw BookingFactor
: 100
PBB Etype

: 0x88e7

A:MTU-1# show port 1/1/1 | match PBB


PBB Ethertype
: 0x88e7

Advanced Configuration Guide

Page 1607

Configuration

I-VPLS Configuration
Once the common B-VPLS is configured, the next step is to provision of the customer I-VPLS
instances. The following outputs show the relevant CLI configuration for the two I-VPLS
instances represented in Figure 156. The I-VPLS instances are configured on the MTU devices,
whereas the core PEs are kept as customer-unaware nodes.
vpls 1 customer 1 i-vpls create
backbone-vpls 100
exit
stp
shutdown
exit
sap 1/1/4:1 create
exit
no shutdown
exit
vpls 2 customer 1 i-vpls create
backbone-vpls 100:2
exit
stp
shutdown
exit
sap lag-1 create
exit
no shutdown
exit

The relevant I-VPLS commands are in bold.


Note that the statement i-vpls is given at creation time and therefore it cannot be added to a regular
existing VPLS instance. After creating the I-VPLS instance, it has to be linked to its
corresponding transport B-VPLS instance. That link is given by the backbone-vpls b-vpls:isid
command. If no ISID (20 bit customer identification in the ITAG) is specified, the system will take
the ISID from the VPLS instance identifier.
The following considerations will be taken into account when configuring the I-VPLS:

I-VPLS SAPs:
SAPs can be defined on ports with any Ethernet encapsulation type (null, dot1q and
qinq)
The I-VPLS SAPs can coexist on the same port with SAPs for other business services,
for exmple, VLL and VPLS SAPs.

I-VPLS SDPs:
GRE and MPLS SDPs are supported.
No mesh-SDPs are supported, only spoke SDP. Mesh-SDPs can be emulated by using
split horizon groups.

Page 1608

Advanced Configuration Guide

PBB-VPLS

Existing SAP processing rules still apply for the I-VPLS case; the SAP encapsulation definition on
Ethernet ingress ports defines which VLAN tags are used to determine the service that the packet
belongs to:

Null encapsulation defined on ingress Any VLAN tags are ignored and the packet goes
to a default service for the SAP;

Dot1q encapsulation defined on ingress only first VLAN tag is considered;

QinQ encapsulation defined on ingress both VLAN tags are considered; wildcard for
the inner VLAN tag is supported.

For dot1q/qinq encapsulations, traffic encapsulated with VLAN tags for which there is no
definition is discarded.

Note that any VLAN tag used for service selection on the I-SAP is stripped before the
PBB encapsulation is added. Appropriate VLAN tags are added at the remote PBB PE
when sending the packet out on the egress SAP.

Up to 8000 VPLS instances can be defined per system. That number includes I-VPLS, B-VPLS
and regular VPLS.

Advanced Configuration Guide

Page 1609

Configuration

MMRP for Flooding Optimization


When the M:1 model is used (as in this example), any I-VPLS broadcast/multicast/unknown
frame is flooded throughout the B-VPLS domain regardless of the nodes where the originating IVPLS is defined. In other words, in our example in Figure 155, any broadcast/multicast/unknown
frame coming from CE-1 would be flooded in the B domain and would reach PE-2 and MTU-2,
even though that traffic only needs to go to PE-3 and MTU-3. In order to build customer-based
flooding trees and optimize the flooding, MMRP (Multiple MAC Registration Protocol) must be
configured on the B-VPLS.
MMRP can be enabled with its default settings just by executing a mrp no shutdown command:
A:PE-1>config>service# info
---------------------------------------------<snip>
vpls 100 customer 1 b-vpls create
service-mtu 2000
pbb
source-bmac 00:01:01:01:01:01
exit
bgp-ad
vpls-id 65000:100
route-target export target:65000:100 import target:65000:100
pw-template-bind 1
no shutdown
exit
stp
shutdown
exit
mrp
no shutdown
exit
no shutdown
exit
----------------------------------------------

There are certain B-VPLS MRP settings that can be modified. These are the default values:
*A:MTU-1>config>service>vpls>mrp# info detail
---------------------------------------------no attribute-table-size
attribute-table-low-wmark 90
attribute-table-high-wmark 95
no flood-time
no shutdown
---------------------------------------------*A:MTU-1>config>service>vpls>mrp#

Page 1610

Advanced Configuration Guide

PBB-VPLS

These four attributes can be changed in order to control the number of MMRP attributes per BVPLS and optimize the convergence time in case of failures in the B-VPLS:

Controlling the number of attributes per B-VPLS

The MMRP exchanges create one entry per attribute (group B-MAC ) in the B-VPLS where
MMRP protocol is running. When the first registration is received for an attribute, an MFIB entry
is created for it. The attribute-table-size allows the user to control the number of MMRP attributes
(group B-MACs) created on a per B-VPLS basis, between 1 and 2048. Based on the configured
size, high and low watermarks can be set (in percentage) so that alarms can be triggered upon
exceeding the watermarks. This ensures that no B-VPLS will take up all the resources from the
total pool. The maximum number of attributes per B-VPLS is 2048 and 4000 can be configured
globally on the system.

Optimizing the convergence time

Assuming that MMRP is used in a certain B-VPLS, under failure conditions the time it takes for
the B-VPLS forwarding to resume may depend on the data plane and control plane convergence
plus the time it takes for MMRP exchanges to stabilize the flooding trees on a per ISID basis. In
order to minimize the convergence time, the PBB SR OS implementation offers the selection of a
mode where B-VPLS forwarding reverts for a short time to flooding so that MMRP has enough
time to converge. This mode can be selected through configuration using the flood-time value
command where value represents the amount of time in seconds (between 3 and 600) that flooding
will be enabled. If this behavior is selected, the forwarding plane starts with B-VPLS flooding for
a configurable time period, then it reverts back to the MFIB entries installed by MMRP. The
following B-VPLS events initiate the switch from per I-VPLS (MMRP) MFIB entries to BVPLS
flooding:
Reception or local triggering of a TCN (Spanning Tree Topology Change
Notification)
B-SAP failure
Failure of a B-SDP binding
Pseudowire activation in a primary/standby H-VPLS resiliency solution
SF/CPM switchover due to STP reconvergence
The IEEE 802.1ak standard, which defines MRP, requires the implementation of different state
machines with associated timers that can be tuned. A full MRP participant maintains the following
state machines:

Registrar state machine

Applicant state machine

LeaveAll state machine

PeriodicTransmission state machine

Advanced Configuration Guide

Page 1611

Configuration

The two first state machines are maintained for each attribute in which the participant is interested,
while the two latter are global to all the attributes.
The job of the registrar function is to record declarations of the attribute made by other
participants on the LAN. A registrar does not send any protocol messages, as the applicant looks
after the interests of all would-be participants.
The job of the applicant is twofold: on one hand to ensure that this participants declaration is
correctly registered by other participants registrars, and on the other hand to prompt other
participants to register again after one withdraws a declaration.
The associated timers can be tuned on a per SAP/SDP basis:
*A:MTU-1>config>service>vpls# spoke-sdp 111:100 mrp
- mrp
[no] join-time
[no] leave-all-time
[no] leave-time
[no] periodic-time
[no] periodic-timer

- Configure timer value in 10th of seconds for sending


join-messages
- Configure timer value in 10th of seconds for
refreshing all attributes
- Configure timer value in 10th of seconds to hold
attribute in leave-state
- Configure timer value in 10th of seconds for
re-transmission of attribute declarations
- Control re-transmission of attribute declarations

*A:MTU-1>config>service>vpls# spoke-sdp 111:100 mrp


*A:MTU-1>config>service>vpls>spoke-sdp>mrp# info detail
---------------------------------------------join-time 2
leave-time 30
leave-all-time 100 # Default Values
periodic-time 10
no periodic-timer
---------------------------------------------*A:MTU-1>config>service>vpls>spoke-sdp>mrp#

A brief description of the MRP SAP/SDP attributes follow:

Page 1612

Join-time This command controls the interval between transmit opportunities that are
applied to the applicant state machine. An instance of this join period timer is required on
a per-port, per-MRP participant basis. For additional information, refer to IEEE 802.1ak2007 section 10.7.4.1.

Leave-time This command controls the period of time that the registrar state machine
will wait in the leave state before transitioning to the MT state when it is removed. An
instance of the timer is required for each state machine that is in the leave state. The leave
period timer is set to the value leave-time when it is started. A registration is normally in
in state where there is an MFIB entry and traffic being forwarded. When a leave all is
performed (periodically around every 10-15 seconds per SAP/SDP binding see leaveall-time-below), a node sends a message to its peer indicating a leave all is occurring and
puts all of its registrations in leave state. The peer refreshes its registrations based on the

Advanced Configuration Guide

PBB-VPLS

leave all PDU it receives and sends a PDU back to the originating node with the state of
all its declarations. Refer to IEEE 802.1ak-2007 section 10.7.4.2.

Leave-all-time This command controls the frequency with which the leaveall state
machine generates leaveall PDUs. The timer is required on a per-port, per-MRP
participant basis. The leave all period timer is set to a random value, T, in the range
leavealltime<T<1.5*leave-all-time when it is started. Refer to IEEE 802.1ak-2007,
section 10.7.4.3.

Periodic-time This command controls the frequency the periodic transmission state
machine generates periodic events if the periodic transmission timer is enabled. The timer
is required on a per-port basis. The periodic transmission timer is set to one second when
it is started.

Periodic-timer This command enables or disables the periodic transmission timer.

The following command shows the MRP configuration and statistics on a per SAP/SDP basis
within the B-VPLS:
*A:MTU-1# show service id 100 all | match post-lines 10 MRP
Sdp Id 111:100 MRP Information
-----------------------------------------------------------------------------Join Time
: 0.2 secs
Leave Time
: 3.0 secs
Leave All Time
: 10.0 secs
Periodic Time
: 1.0 secs
Periodic Enabled
: false
Rx Pdus
: 24884
Tx Pdus
: 22834
Dropped Pdus
: 0
Rx New Event
: 0
Rx Join-In Event : 47946
Rx In Event
: 1344
Rx Join Empty Evt : 460
Rx Empty Event
: 1
Rx Leave Event
: 2
Tx New Event
: 0
Tx Join-In Event : 45483
SDP MMRP Information
-----------------------------------------------------------------------------MAC Address
Registered
Declared
-----------------------------------------------------------------------------01:1e:83:00:00:01 Yes
Yes
01:1e:83:00:00:02 Yes
Yes
-----------------------------------------------------------------------------Number of MACs=2 Registered=2 Declared=2
-----------------------------------------------------------------------------Sdp Id 112:100 MRP Information
-----------------------------------------------------------------------------Join Time
: 0.2 secs
Leave Time
: 3.0 secs
Leave All Time
: 10.0 secs
Periodic Time
: 1.0 secs
Periodic Enabled
: false
Rx Pdus
: 0
Tx Pdus
: 0
Dropped Pdus
: 0
Rx New Event
: 0
Rx Join-In Event : 0
Rx In Event
: 0
Rx Join Empty Evt : 0
Rx Empty Event
: 0
Rx Leave Event
: 0
Tx New Event
: 0
Tx Join-In Event : 0
SDP MMRP Information
-----------------------------------------------------------------------------MAC Address
Registered
Declared
------------------------------------------------------------------------------

Advanced Configuration Guide

Page 1613

Configuration

Number of MACs=0 Registered=0 Declared=0


-----------------------------------------------------------------------------Number of SDPs : 2
-----------------------------------------------------------------------------MRP Information
------------------------------------------------------------------------------Admin State
: Up
Failed Register Cnt: 0
Max Attributes
: 2048
Attribute Count
: 2
Attr High Watermark: 95%
Attr Low Watermark : 90%
Flood Time
: Off
-----------------------------------------------------------------------------Related i-Vpls services for b-Vpls service 100
-----------------------------------------------------------------------------*A:MTU-1#

The following command is also useful to check the MRP configuration and status.
*A:MTU-1# show service id 100 mrp
-----------------------------------------------------------------------------MRP Information
-----------------------------------------------------------------------------Admin State
: Up
Failed Register Cnt: 0
Max Attributes
: 2048
Attribute Count
: 2
Attr High Watermark: 95%
Attr Low Watermark : 90%
Flood Time
: Off
-----------------------------------------------------------------------------*A:MTU-1#

In the example we are using throughout the document, as soon as MMRP is enabled, an optimized
flooding tree will be built for the ISID 1, since the I-VPLS 1 is only defined in MTU-1 and MTU3, but not MTU-2. A good way to track the flooding tree for a particular ISID is the following
command:
*A:MTU-1# show service id 100 mmrp mac
------------------------------------------------------------------------------SAP/SDP
MAC Address
Registered Declared
------------------------------------------------------------------------------sdp:111:100
01:1e:83:00:00:01 Yes
Yes
sdp:111:100
01:1e:83:00:00:02 Yes
Yes
------------------------------------------------------------------------------A:MTU-2# show service id 100 mmrp mac
------------------------------------------------------------------------------SAP/SDP
MAC Address
Registered Declared
------------------------------------------------------------------------------sdp:212:100
01:1e:83:00:00:01 Yes
No
sdp:212:100
01:1e:83:00:00:02 Yes
No
------------------------------------------------------------------------------*A:MTU-1#

The group B-MAC ending in 01 corresponds to the I-VPLS 1 whereas the one ending in 02 to the
I-VPLS 2. Note that MMRP PDUs for the two attributes are sent throughout the loop-tree
topology (not over STP blocked ports or standby spoke SDPs and observing the split horizon
rules). The two attributes are registered on every B-VPLS virtual port; however, the tree is only
built on those ports where the attribute is also declared, and not only registered . For instance, the
spoke-sdp 212:100 in MTU-2 will not be part of the ISID 1 or ISID 2 flooding trees. Neither

Page 1614

Advanced Configuration Guide

PBB-VPLS

attribute is declared since: I-VPLS 1 doesnt exist on MTU-2 and I-VPLS 2 is operationally down
on MTU-2 (MC-LAG SAP is in standby state hence the I-VPLS down).
Note that as soon as a group B-MAC attribute is registered on a particular port, an MFIB entry is
added for that B-MAC on that port, regardless of the declaration state for that attribute on the port.
For instance, neither B-MAC is declared on MTU-2 however the two MFIB entries are created as
soon as the attributes are registered:
A:MTU-2# show service id 100 mfib
===============================================================================
Multicast FIB, Service 100
===============================================================================
Source Address Group Address
Sap/Sdp Id
Svc Id
Fwd/Blk
------------------------------------------------------------------------------*
01:1E:83:00:00:01
b-sdp:212:100
Local
Fwd
*
01:1E:83:00:00:02
b-sdp:212:100
Local
Fwd
------------------------------------------------------------------------------Number of entries: 2
===============================================================================
*A:MTU-1#

Advanced Configuration Guide

Page 1615

Configuration

MAC Flush: Avoiding Blackholes


Both the I-VPLS and B-VPLS components inherit the MAC flush capabilities of a regular VPLS
clearing the related C-MAC and respectively B-MAC FIBs. All types of MAC flush flush-allbut-mine and flush-all-from-me are supported together with the related CLI. In addition to these
features, some extensions have been added so that MAC flush can be triggered on the B-VPLS
based on some events happening on the I-VPLS. The following diagram shows a potential
scenario where blackholes can occur if the proper configuration is not added.

00:01
00:11
1
1/1/3

CE-2

1/1/3

1/1/4

2
MTU-1

1/1/1

1/1/2

1/1/1

1/1/4

PE-1

B
00:02

MTU-2

1/1/1

1/1/3

1/1/1

1
B
2

1/1/2

1/1/3

Epipe instance
00:31

1/1/1

1/1/4

3
00:03

1/1/3

1/1/2

B-VPLS instance

1/1/2

00:22:0..0

00:21

B
B

1/1/2:4

1/1/4:4

MTU-3
PE-3

CE-4
172.16.1.4

1/1/2
1/1/1

1/1/4

PE-2

OSSG360

Figure 157: Blackhole

Under normal conditions the I-VPLS 2 FIB on MTU-3 shows that CE-2 MAC address is learnt
through B-MAC 00:11 (MTU-1s B-MAC):
A:MTU-3# show service id 2 fdb pbb
=============================================================================
Forwarding Database, i-Vpls Service 2
=============================================================================
MAC
Source-Identifier
B-Svc
b-Vpls MAC
Type/Age
----------------------------------------------------------------------------00:22:00:00:00:00 b-sdp:33:100
100
00:11:11:11:11:11 L/0
00:44:00:00:00:00 sap:1/1/2:4
100
N/A
L/0
=============================================================================
A:MTU-3#

When a failure happens in the CE-2 MC-LAG active link, the link to MTU-2 takes over. However,
the FIB on MTU-3 still points at MTU-1s B-MAC and that will still be the B-MAC used in the
PBB encapsulation. Therefore a blackhole occurs until either bidirectional traffic is sent or the FIB
aging timer expires.

Page 1616

Advanced Configuration Guide

PBB-VPLS

The following command will solve the blackhole:


*A:MTU-1>config>service>vpls# info
---------------------------------------------send-bvpls-flush all-from-me
backbone-vpls 100:2
exit
stp
shutdown
exit
sap lag-1 create
exit
no shutdown
---------------------------------------------*A:MTU-1>config>service>vpls# send-bvpls-flush
- send-bvpls-flush {[all-but-mine] [all-from-me]}
- no send-bvpls-flush
<all-but-mine>
<all-from-me>

: keyword
: keyword

By enabling send-bvpls-flush all-from-me on I-VPLS 2, a failure on the MC-LAG active link on


I-VPLS 2 will trigger a LDP MAC flush flush-all-from-me into the B-VPLS that will flush the
FIB in MTU-3 for I-VPLS 2, avoiding the blackhole. A MC-LAG failure is emulated below:
*A:MTU-1# configure lag 1 shutdown
3 2010/04/01 01:47:53.49 UTC MINOR: DEBUG #2001 Base LDP
"LDP: LDP
Send Address Withdraw packet (msgId 20844) to 192.0.2.1:0
MAC Flush (All MACs learned from me)
Service FEC EpipePWE3: ENET(5)/100 Group ID = 0 cBit = 0
Number of PBB-BMACs = 1
BMAC 1 = 00:11:11:11:11:11
Number of PBB-ISIDs = 1
ISID 1 = 2
Number of Path Vectors : 1
Path Vector( 1) = 192.0.2.11
"
A:MTU-3#
3 2010/04/01 01:47:58.63 UTC MINOR: DEBUG #2001 Base LDP
"LDP: LDP
Recv Address Withdraw packet (msgId 20844) from 192.0.2.3:0
MAC Flush (All MACs learned from me)
Service FEC EpipePWE3: ENET(5)/100 Group ID = 0 cBit = 0
Number of PBB-BMACs = 1
BMAC 1 = 00:11:11:11:11:11
Number of PBB-ISIDs = 1
ISID 1 = 2
Number of Path Vectors : 3
Path Vector( 1) = 192.0.2.11
Path Vector( 2) = 192.0.2.1
Path Vector( 3) = 192.0.2.3
"
# Immediately after receiving the MAC flush, the CE-2 MAC is flushed and re-learnt but this
time linked to the B-MAC 00:21, which is the MTU-2 B-MAC

Advanced Configuration Guide

Page 1617

Configuration

show service id 2 fdb pbb


=============================================================================
Forwarding Database, i-Vpls Service 2
=============================================================================
MAC
Source-Identifier
B-Svc
b-Vpls MAC
Type/Age
----------------------------------------------------------------------------00:44:00:00:00:00 sap:1/1/2:4
100
N/A
L/0
=============================================================================
A:MTU-3# show service id 2 fdb pbb
=============================================================================
Forwarding Database, i-Vpls Service 2
=============================================================================
MAC
Source-Identifier
B-Svc
b-Vpls MAC
Type/Age
----------------------------------------------------------------------------00:22:00:00:00:00 b-sdp:33:100
100
00:21:21:21:21:21 L/3
00:44:00:00:00:00 sap:1/1/2:4
100
N/A
L/0
=============================================================================

The following I-VPLS events are propagated into the B-VPLS depending on the flush-all-butmine or flush-all-from-me keywords used in the configuration:
If the flush-all-but-mine keyword is configured (positive flush), the following events in the IVPLS trigger a MAC flush into the B-VPLS:
1. TCN event in one or more of the related I-VPLS/M-VPLS.
2. Pseudowire/SDP binding activation with active/standby pseudowire (standby to active or
down to up).
3. Reception of an LDP MAC withdraw flush-all-but-mine in the related I-VPLS.
If the flush-all-from-me keyword is configured (negative flush) the following events in the IVPLS trigger a MAC flush into the B-VPLS:
1. MC-LAG active link failure (in our example).
2. Failure of a local SAP requires send-flush-on-failure to be enabled in I-VPLS.
3. Failure of a local pseudowire/SDP binding requires send-flush-on-failure to be enabled in
I-VPLS.
4. Reception of an LDP MAC withdraws flush-all-from-me in the related I-VPLS.
In addition to this and regardless of what type, MAC flush has been optimized to avoid flushing in
the core PEs, flushing only the C-MACs mapped to a certain B-MAC (belonging to a specific
ISID FIB) and the ability to indicate to core PEs which messages should always be forwarded
endpoint-to-endpoint towards all PBB PEs regardless of the propagate-mac-flush setting in BVPLS. All of this is implemented without the need of any additional CLI commands and it is part
of draft-balus-l2vpn-pbb-ldp-ext-00.

Page 1618

Advanced Configuration Guide

PBB-VPLS

Another extension supported to avoid blackholes within this mixed of I- and B-VPLS
environments is the block-on-mesh-failure feature in PBB. When the VPLS mesh exists only in IVPLS or in B-VPLS, and the block-on-mesh-failure feature is enabled, the regular VPLS behavior
will apply (when all the mesh SDPs go down an LDP notification with pseudowire status bits =
0x01 - Pseudo Wire Not Forwarding is sent over the spoke SDPs). When the active/standby
pseudowire resiliency is implemented in I-VPLS such that the PBB PE performs the role of a PErs, the B-VPLS core replaces the pseudowire (SDP binding) mesh. The block-on-meshnotification (LDP notification indicating pseudowire not forwarding) will be sent to the MTUs
only when the related B-VPLS is operationally down. The B-VPLS core is operationally down
only when all of its SAPs and SDPs are down.
The final feature that can be enabled in an I-VPLS with CLI is the send-flush-on-bvpls-failure
feature.
*A:PE-1>config>service>vpls# send-flush-on-bvpls-failure
- no send-flush-on-bvpls-failure
- send-flush-on-bvpls-failure

# only valid for I-VPLS

This feature is required to avoid blackholes when there is a full-mesh of pseudowires in the IVPLS domain and the B-VPLS instance can go operationally down. The following figure shows a
typical scenario where this feature is needed (normally when PBB-VPLS and multi-chassis end
point are combined together).

B-VPLS Goes
Operationally Down

B-VPLS instance

Epipe instance

flush-all-from-me
1

MTU-1
PE-1

1
B

B
2
MTU-3

MTU-2

PE-3

PE-2
OSSG361

Figure 158: Send Flush on BVPLS Failure Example

Advanced Configuration Guide

Page 1619

Configuration

Access Dual-Homing and MAC Notification


Although this section is focused on PBB in a MPLS based network, Alcatel-Lucent PBB
implementation also allows the operator to use a native Ethernet infrastructure in the PBB core.
Native Ethernet tunneling can be emulated using Ethernet SAPs to interconnect the related BVPLS instances. In those cases, there is no LDP signaling available; hence, there is no MAC flush
sent when the active link in a multi-homed access device fails.
The SR OS supports a mechanism to avoid potential blackholes in native Ethernet PBB networks.
In addition to the source B-MAC associated with each B-VPLS, an additional B-MAC is
associated with each MC-LAG supporting Multi-homed I-VPLS SAPs. The nodes that are in a
multi-homed MC-LAG configuration share a common B-MAC on the related MC-LAG
interfaces. When the mac-notification no shutdown command is executed, an Ethernet CFM
notification message is sent from the node holding the active link. That message will be flooded in
the B-VPLS domain using the MC-LAG SAP B-MAC as the source MAC address. The remote
nodes will learn the customer MAC addresses behind the MC-LAG and will link them to this new
SAP B-MAC. MC-LAG will keep track of the active link for each particular LAG associated to a
SAP B-MAC. Should MC-LAG detect any new active link in a node, a new CFM notification
message will be flooded from the new active node.
The following caveats and considerations must be taken into account:

The MAC notification for access dual-homed devices is only supported in network mode
D.
All network ports and B-SAPs must reside on slots populated with either an IOM3XP or IMM. All other SAPs may reside on any IOM or IMM populated slot. This is
enforced by the CLI.
MC-LAG SAPs must be on IOM3-XP/IMM.
Other SAPs may be on IOM1/IOM2 (non-PBB services, PBB Epipe SAP with no
other SAP on local MC-LAG, PBB I-VPLS SAPs even if some of the other I-SAPs
are on the MC-LAG).
This is automatically applicable to the 7750 SR-c4/12.

Only MC-LAG is supported as dual-home mechanism.

This mechanism is supported for native PBB and/or MPLS-based PBB-VPLS. Although
it is mostly beneficial when native PBB is used in the core, it can also help to optimize the
re-learning process in a MPLS-based core in case of MC-LAG failures, in addition to the
existing LDP MAC flush procedures.

The example of this configuration shows the setup being used in this configuration example.
MAC-notification will be configured in MTU-1 and MTU-2 for the dual-homed CE-2.
The first step is to configure the sap-bmac that will be used for the mac-notification messages. The
source-bmac-lsb (source backbone MAC least significant bits) command has been added to the
mc-lag branch so that the operator can decide the two last octets to be used in the sap-bmac. Those

Page 1620

Advanced Configuration Guide

PBB-VPLS

two last octets can be derived from the lacp-key (if the use-lacp-key statement is used) or can be
specifically defined.
A:MTU-1>config>redundancy>mc>peer>mc-lag#
- lag <lag-id> lacp-key <admin-key> system-id <system-id> [remote-lag
<remote-lag-id>] system-priority <system-priority> source-bmac-lsb
use-lacp-key
- lag <lag-id> lacp-key <admin-key> system-id <system-id> [remote-lag
<remote-lag-id>] system-priority <system-priority> source-bmac-lsb
<MAC-Lsb>
- lag <lag-id> lacp-key <admin-key> system-id <system-id> [remote-lag
<remote-lag-id>] system-priority <system-priority>
- no lag <lag-id>
<lag-id>
<admin-key>
<system-id>
<remote-lag-id>
<system-priority>
<MAC-Lsb>

:
:
:
:
:
:

[1..200]
[1..65535]
xx:xx:xx:xx:xx:xx
- xx [00..FF]
[1..200]
[1..65535]
[1..65535] or xx-xx or xx:xxe must be D and above

There must be a different sap-bmac per MC-LAG. The use of the lacp-key as a default for two
least significant octets makes the operations simpler. In our example, the sap-bmac last two octets
will come from the lacp-key:
A:MTU-1>config>redundancy>mc>peer>mc-lag# info
---------------------------------------------lag 1 lacp-key 15 system-id 00:00:00:00:00:01 system-priority 65535
source-bmac-lsb use-lacp-key
no shutdown
----------------------------------------------

Therefore, the sap-bmac will be formed in the following way:


[4 first bytes of the source bmac + 2 bytes from source-bmac-lsb]

Finally, enable the mac-notification and instruct the b-vpls to use the sap-bmac at service level:
A:MTU-1>config>service# info
---------------------------------------------pbb
source-bmac 00:11:11:11:11:11
mac-name "MTU-1" 00:11:11:11:11:11
mac-name "MTU-2" 00:22:22:22:22:22
mac-name "MTU-3" 00:31:31:31:31:31
exit
<snip>
vpls 2 customer 1 i-vpls create
send-bvpls-flush all-from-me
backbone-vpls 100:2
exit
stp
shutdown

Advanced Configuration Guide

Page 1621

Configuration

exit
sap lag-1 create
exit
no shutdown
exit
vpls 100 customer 1 b-vpls create
service-mtu 2000
pbb
source-bmac 00:aa:aa:aa:aa:aa
use-sap-bmac
exit
mac-notification
no shutdown
exit
stp
shutdown
exit
mrp
no shutdown
exit
endpoint "core" create
no suppress-standby-signaling
exit
spoke-sdp 111:100 endpoint "core" create
stp
shutdown
exit
precedence primary
exit
spoke-sdp 112:100 endpoint "core" create
stp
shutdown
exit
exit
no shutdown
exit

The mac-notification command activates the described mechanism and has the following
parameters:
A:MTU-1# configure service vpls 100 mac-notification
- mac-notification
[no] count
[no] interval
[no] shutdown

- Configure count for MAC-notification messages


- Configure interval for MAC-notification messages
- Configure admin state for MAC-notification messages

Where:

Page 1622

interval <value> controls how often the subsequent MAC notification messages are sent.
Default = 100 ms. Required values: 100 ms 10 sec, in increments of 100 ms.

count <value> controls how often the MAC notification messages are sent. Default = 3.
Range: 1-10.

Advanced Configuration Guide

PBB-VPLS

Note that the count and interval parameters can also be configured at the service context. The
settings configured at the B-VPLS service context take precedence though.
A:MTU-1# configure service mac-notification
- mac-notification
[no] count
[no] interval

- Configure count for MAC-notification messages


- Configure interval for MAC-notification messages

The use-sap-bmac statement enables (on a per B-VPLS basis) the use of the source B-MAC
allocated to the multi-homed SAPs (assigned to the MC-LAG) in the related I-VPLS service
(could be Epipe service as well). Note that the command will fail if the value of the source-bmac
assigned to the B-VPLS is the hardware (chassis) B-MAC. In other words, the source-bmac must
be a configured one. The use-sap-bmac statement is by default off.
As soon as the mac-notification no shutdown command is executed, an Ethernet CFM
notification message is sent from MTU-1, which is the node where the active MC-LAG link
resides. The CFM message will have the source mac 00:aa:aa:aa:00:0f (4 first bytes of the
configured source bmac + 2 bytes from the configured source-bmac-lsb, which is 15 in hex) and
will be flooded throughout the B-VPLS domain. Should the link between CE-2 and MTU-1 fail,
the MC-LAG protocol will activate the redundant link and MTU-2 will immediately issue a CFM
message with the shared sourced sap-bmac that will be flooded in the B-VPLS domain.

PBB and IGMP Snooping


IGMP snooping can be enabled on I-VPLS SAPs and SDPs (it cannot be enabled on B-VPLS).
The 7x50/7710 can keep track of IGMP joins received over individual B-SDPs or B-SAPs, and it
starts flooding the Multicast Group (and only the multicast group) to ALL B-components (using
the Group B-MAC for I-SID) as soon as the first IGMP join for that Multicast Group is received in
one of the B-SxP components.
The first IGMP join message received over the local B-VPLS will add all the B-VPLS SAP/SDP
components into the related multicast table associated with the I-VPLS context. When the querier
is connected to a remote I-VPLS instance, over the B-VPLS infrastructure, its location is
identified by the B-VPLS SDP/SAP on which the query was received and also by the source BMAC address used in the PBB header for the query message, the B-MAC associated with the BVPLS instance on the remote PBB PE.
The following excerpt shows an I-VPLS with IGMP snooping enabled and some static groups
added on a SAP. Note that we are also configuring the location of the querier by adding the BMAC where the querier is connected to (in this example MTU-3) and adding the two B-VPLS
spoke-sdps as mrouter ports (note that the B-VPLS mrouter ports are added under the I-VPLS
backbone-vpls context).

Advanced Configuration Guide

Page 1623

Configuration

The mac-name command translates MACs into strings so that the names can be used instead of
typing the entire MAC address every time needed.
*A:MTU-1>config>service>pbb# info
---------------------------------------------mac-name "MTU-1" 00:11:11:11:11:11
mac-name "MTU-2" 00:22:22:22:22:22
mac-name "MTU-3" 00:31:31:31:31:31
---------------------------------------------*A:MTU-1>config>service>vpls# info
---------------------------------------------send-flush-on-failure
send-flush-on-bvpls-failure
send-bvpls-flush all-from-me
backbone-vpls 100
igmp-snooping
mrouter-dest "MTU-3"
exit
sdp 111:100
igmp-snooping
mrouter-port
exit
exit
sdp 112:100
igmp-snooping
mrouter-port
exit
exit
exit
stp
shutdown
exit
igmp-snooping
no shutdown
exit
sap 1/1/4:1 create
igmp-snooping
static
group 228.0.0.1
starg
exit
group 228.0.0.2
starg
exit
group 239.0.0.1
source 172.16.99.99
exit
exit
exit
exit
no shutdown
---------------------------------------------*A:MTU-1>config>service>pbb# i

Page 1624

Advanced Configuration Guide

PBB-VPLS

As in regular VPLS instances, mrouter ports are added to all the multicast groups:
*A:MTU-1> show service id 1 mfib
===============================================================================
Multicast FIB, Service 1
===============================================================================
Source Address Group Address
Sap/Sdp Id
Svc Id
Fwd/Blk
------------------------------------------------------------------------------*
*
b-sdp:111:100
100
Fwd
b-sdp:112:100
100
Fwd
*
228.0.0.1
sap:1/1/4:1
Local
Fwd
b-sdp:111:100
100
Fwd
b-sdp:112:100
100
Fwd
*
228.0.0.2
sap:1/1/4:1
Local
Fwd
b-sdp:111:100
100
Fwd
b-sdp:112:100
100
Fwd
172.16.99.99
239.0.0.1
sap:1/1/4:1
Local
Fwd
b-sdp:111:100
100
Fwd
b-sdp:112:100
100
Fwd
------------------------------------------------------------------------------Number of entries: 4
===============================================================================

Note that when the show service id x mfib command is issued in a B-VPLS, the group B-MAC
entries are shown, whereas when the same command is issued in a I-VPLS, the IGMP (S,G) and
(*,G) entries for the I and B components are shown if IGMP snooping is enabled.

Advanced Configuration Guide

Page 1625

Configuration

MMRP Policies and ISID-Based Filtering for PBB Inter-Domain Expansion


As discussed in the MMRP for Flooding Optimization on page 1610, MMRP is used in the
backbone VPLS instances to build per I-VPLS flooding trees. Each I-VPLS has an associated
group B-MAC in the B-VPLS, which is derived from the ISID, and is advertised by MMRP
throughout the whole B-VPLS context, regardless of whether a certain I-VPLS is present in one or
all the B-VPLS PEs.
In an inter-domain environment, the same B-VPLS can be defined in different domains and as
such MMRP will advertise all the group B-MACs in every domain, wasting resources in all the
PEs no matter if a particular ISID, and hence its group B-MAC, are not required in one of the
domains. When MMRP is enabled in a particular PE, data plane and control plane resources are
consumed and they must be taken into consideration when designing PBB-VPLS networks:

Control plane MRRP processing takes CPU cycles and the number of attributes that can
be advertised is not unlimited

Data plane each group B-MAC registration takes one MFIB entry (the MFIB is shared
between MMRP and IGMP/PIM snooping)

From 8.0R1, the 7x50 SR/ESS supports MMRP policies and ISID-based filters so that control
plane and data plane resources can be saved when I-VPLS instances are not defined in all the
domains.
The following figure illustrates an example of usage for MMRP policies and ISID-based filters
that will be configured in this section. Domain 1 and domain 2 will have a range of local
ISIDs each and a range of inter-domain ISIDs:

Domain 1 local ISIDs: from 1 to 100

Domain 2 local ISIDs: from 101 to 200

Inter-domain ISIDs: from 1000 to 2000

By applying the MMRP policies indicated in the figure, domain 1 attributes will be prevented
from being declared and registered in domain 2 and vice versa, domain 2 attributes from being
declared and registered in domain 1. The egress mac-filters will drop any traffic sourced from a
local ISID preventing it to be transmitted to the remote domain.

Page 1626

Advanced Configuration Guide

PBB-VPLS

MTU-1
1

mrp_policy_3
mac-filter 3 (isid-based)
DOMAIN 1

DOMAIN 2

200

1000

spoke-sdp 13:1

B
MTU-2

PE-3

PE-1

B
1000

spoke-sdp 31:1

MTU-3

mrp_policy_1
mac-filter 1 (isid-based)
OSSG667

Figure 159: Inter-Domain B-VPLS and MMRP Policies/ISID-Based Filters Example

MMRP Policies
The following output shows the MMRP policy configuration in node PE-1. This policy will block
any registration/declaration except those for ISIDs 1000-2000. Note that packets will be compared
against the configured matching ISIDs as long as the pbb-etype matches the one configured on the
port or SDP.
*A:PE-1>config>service>mrp# info
---------------------------------------------mrp-policy "mrp_policy_1" create
default-action block
description "allow-inter-domain-isids"
entry 10 create
action allow
match
isid 1000 to 2000
exit
exit
exit
----------------------------------------------

Once the MMRP policy is configured, it must be applied on the corresponding SAP or sdpbinding. Note that an mrp-policy can be applied to a B-VPLS SAP, B-VPLS spoke-sdp or B-VPLS
mesh-sdp:
*A:PE-1>config>service>vpls# info
---------------------------------------------service-mtu 2000
stp
shutdown

Advanced Configuration Guide

Page 1627

Configuration

exit
mrp
no shutdown
exit
...
spoke-sdp 13:1 create
mrp
mrp-policy "mrp_policy_1"
exit
exit
...
no shutdown
----------------------------------------------

In the same way, mrp_policy_3 will be configured in PE-3.


Some additional considerations about the MMRP policies:

Different entries within the same mrp-policy can have overlapping ISID ranges. The
entries will be evaluated in the order of their IDs and the first match will cause the
implementation to execute the associated action for that entry and then to exit the mrppolicy.

If no ISID is specified in the match condition then:


If the action is end-station, no entry is added and the action is block.
If the action is different from end-station, every ISID is considered for that action.

The mrp-policy specifies either a forward or a drop action for the group B-MAC attributes
associated with the ISIDs specified in the match criteria.

*A:PE-1>config>serv>mrp>mrp-policy>entry# action ?
- action <action>
- no action
<action>

: none|block|allow|end-station

Note that there is an additional action called end-station. This action specifies that an
end-station emulation is present on the SAP/SDP-binding where the policy has been
applied. The matching ISIDs will not get declared/registered in the SAP/SDP-binding
(just like the block action), however those attributes will get mapped as static MMRP
entries on the SAP/SDP-binding, which implicitly get instantiated in the data plane as
MFIB entries associated with that SAP/SDP-binding for the related group B-MAC. When
the action is end-station, the default-action must be block:

*A:PE-3>config>serv>mrp>mrp-policy# default-action allow


MINOR: SVCMGR #5904 Mrp-policy default-action must be block when end-station action exists

Page 1628

The end-station action can be used in the inter-domain gateways when, for instance, we
do not want MMRP control plane exchanges between domains. The following output
shows how to define the static MMRP entries 1000-2000 in PE-3 without receiving any
declaration for any of those attributes or having any of those locally configured.

Advanced Configuration Guide

PBB-VPLS

*A:PE-3# configure service mrp mrp-policy "mrp_policy_3"


*A:PE-3>config>serv>mrp>mrp-policy# info
---------------------------------------------default-action block
entry 10 create
action end-station
match
isid 1000 to 2000
exit
exit
---------------------------------------------*A:PE-3# show service id 8 mfib
===============================================================================
Multicast FIB, Service 8
===============================================================================
Source Address Group Address
Sap/Sdp Id
Svc Id
Fwd/Blk
------------------------------------------------------------------------------*
01:1E:83:00:03:E8
b-sdp:32:8
Local
Fwd
*
01:1E:83:00:03:E9
b-sdp:32:8
Local
Fwd
*
01:1E:83:00:03:EA
b-sdp:32:8
Local
Fwd
*
01:1E:83:00:03:EB
b-sdp:32:8
Local
Fwd
*
01:1E:83:00:03:EC
b-sdp:32:8
Local
Fwd
*
01:1E:83:00:03:ED
b-sdp:32:8
Local
Fwd
...
*
01:1E:83:00:07:CB
b-sdp:32:8
Local
Fwd
*
01:1E:83:00:07:CC
b-sdp:32:8
Local
Fwd
*
01:1E:83:00:07:CD
b-sdp:32:8
Local
Fwd
*
01:1E:83:00:07:CE
b-sdp:32:8
Local
Fwd
*
01:1E:83:00:07:CF
b-sdp:32:8
Local
Fwd
*
01:1E:83:00:07:D0
b-sdp:32:8
Local
Fwd
------------------------------------------------------------------------------Number of entries: 1001
===============================================================================
*A:PE-3#

The mrp-policy can be applied to multiple B-VPLS services as long as the scope of the
policy is template (the scope can also be exclusive).

Any changes made to the existing policy will be applied immediately to all services where
this policy is applied. For this reason, when many changes are required on a mrp-policy, it
is recommended that the policy be copied to a work-in-progress policy. That work-inprogress policy can be modified until complete and then written over the original mrppolicy. You can use the config mrp-policy copy command to work with the policies in
this manner. The renum command can also help to change the entries sequence order.

*A:PE-3# configure service mrp copy


- copy <src-mrp-policy> to <dst-mrp-policy>
<src-mrp-policy>
<dst-mrp-policy>

: [32 chars max]


: [32 chars max]

*A:PE-3# configure service mrp mrp-policy "mrp_policy_3" renum

Advanced Configuration Guide

Page 1629

Configuration

- renum <src-entry-id> to <dst-entry-id>


<src-entry-id>
<dst-entry-id>

: [1..65535]
: [1..65535]

The no form of the mrp-policy command deletes the mrp-policy. An mrp policy cannot
be deleted until it is removed from all the SAPs/SDP-bindings where it is applied.

ISID-based filters
The MMRP policies help to control the exchange of group B-MAC attributes across domains.
Based on the registration state of a specific group B-MAC on a SAP/SDP-binding, the broadcast/
unknown-unicast/multicast traffic for a particular I-VPLS will be allowed or dropped. However,
if we want to avoid that ANY local ISID packet is flooded to the remote B-VPLS domain, we also
need to filter at the data plane all the packets tagged with the local ISIDs at the gateway PEs. ISIDbased filters will prevent the local ISIDs from sending any packet with unicast B-MAC to the
remote domain. This is particularly useful for PBB-epipe services across domains, where all the
frames use unicast B-MACs and MMRP policies cannot help since they only act on group B-MAC
packets.
The following CLI output shows how to configure an ISID-based filter that drops all the traffic
sourced from the local ISIDs on PE-1 (note that the default action is drop and it does not show up
in the configuration).
*A:PE-1>config>filter# info
---------------------------------------------mac-filter 1 create
description "drop_local_isids"
type isid
entry 10 create
match
isid 1000 to 2000
exit
log 101
action forward
exit
exit
----------------------------------------------

Once the filter is configured, it must be applied on a B-VPLS SAP or SDP-binding and always at
egress.
*A:PE-1>config>service>vpls# info
---------------------------------------------service-mtu 2000
stp
shutdown
exit
mrp
no shutdown
exit

Page 1630

Advanced Configuration Guide

PBB-VPLS

...
spoke-sdp 13:1 create
egress
filter mac 1
exit
mrp
mrp-policy "mrp_policy_1"
exit
exit
...
no shutdown
----------------------------------------------

Some additional comments about ISID-based filters:

The type isid statement must be added before introducing any ISID in the match
command, otherwise the system will show an error:

*A:PE-1>config>filter>mac-filter>entry$ match isid 1000 to 2000


MINOR: FILTER #1533 Can not set ISID values when filter type is not 'isid'
*A:pe-1>config>filter>mac-filter$ type isid
MINOR: FILTER #1561 Cannot change filter type when filter contains entries

Once the operator sets the type isid, the filter cannot be applied at ingress. Only egress
ISID-based filters are allowed:

*A:PE-1>config>service>vpls>mesh-sdp# ingress filter mac 1


MINOR: SVCMGR #2050 Can not apply filter of type 'isid' on ingress

Like any filter or MMRP policy, the filter can be applied to multiple B-VPLS services as
long as the scope of the policy is template (the scope can also be exclusive).

The following command shows the filter configuration and packets that have matched the
filter (field Egr. Matches):

*A:PE-1# show filter mac 1


===============================================================================
Mac Filter
===============================================================================
Filter Id
: 1
Applied
: Yes
Scope
: Template
Def. Action
: Drop
Entries
: 1
Type
: isid
Description : drop_local_isids
------------------------------------------------------------------------------Filter Match Criteria : Mac
------------------------------------------------------------------------------Entry
: 10
FrameType
: Ethernet
Description : (Not Specified)
Log Id
: 101
ISID
: 1000..2000
Match action: Forward
Next Hop
: Not Specified
Ing. Matches: 0 pkts
Egr. Matches: 4 pkts (728 bytes)

Advanced Configuration Guide

Page 1631

Configuration

===============================================================================
*A:PE-1#

Like any other filter, the matching packets can be logged. An example follows (not that
the Ethertype is 0x88e7, which is the default standard etype for PBB):

*A:PE-1# show filter log 101


===============================================================================
Filter Log
===============================================================================
Admin state : Enabled
Description : Default filter log
Destination : Memory
Wrap
: Enabled
------------------------------------------------------------------------------Maximum entries configured : 1000
Number of entries logged
: 4
2010/12/29 20:53:30 Mac Filter: 1:10 Desc:
Interface: to2 Direction: Egress Action: Forward
Src MAC: 00-11-11-11-11-11 Dst MAC: 01-1e-83-00-03-e8 EtherType: 88e7
Hex: 00 00 03 e8 ff ff ff ff ff ff 26 d9 ff 00 00 00
08 00 45 00 00 a8 00 00 40 00 01 11 f8 43 01 01
01 01 7f 00 00 00 c0 09 0d af 00 94 da b8 00 01
2010/12/29 20:53:31 Mac Filter: 1:10 Desc:
Interface: to2 Direction: Egress Action: Forward
Src MAC: 00-11-11-11-11-11 Dst MAC: 01-1e-83-00-03-e8
Hex: 00 00 03 e8 ff ff ff ff ff ff 26 d9 ff 00 00 00
08 00 45 00 00 a8 00 00 40 00 02 11 f7 43 01 01
01 01 7f 00 00 00 c0 09 0d af 00 94 c7 de 00 01

Page 1632

EtherType: 88e7

Advanced Configuration Guide

PBB-VPLS

B-VPLS and I-VPLS Show and Debug Commands


The following commands can help to check the B-VPLS and I-VPLS configuration and their
related parameters.
*A:MTU-1# show service id 100 base # B-VPLS
===============================================================================
Service Basic Information
===============================================================================
Service Id
: 100
Vpn Id
: 0
Service Type
: b-VPLS
Description
: (Not Specified)
Customer Id
: 1
Last Status Change: 04/01/2010 02:45:27
Last Mgmt Change : 04/01/2010 02:40:26
Admin State
: Up
Oper State
: Up
MTU
: 2000
Def. Mesh VC Id
: 100
SAP Count
: 0
SDP Bind Count
: 2
Snd Flush on Fail : Disabled
Host Conn Verify : Disabled
Propagate MacFlush: Disabled
Oper Backbone Src : 00:11:11:11:11:11
Use SAP B-MAC
: disabled
i-Vpls Count
: 2
Epipe Count
: 0
------------------------------------------------------------------------------Service Access & Destination Points
------------------------------------------------------------------------------Identifier
Type
AdmMTU OprMTU Adm Opr
------------------------------------------------------------------------------sdp:111:100 S(192.0.2.1)
n/a
8000
8000
Up
Up
sdp:112:100 S(192.0.2.2)
n/a
8000
8000
Up
Up
===============================================================================
*A:MTU-1#

*A:MTU-1# show service id 1 base


# I-VPLS
===============================================================================
Service Basic Information
===============================================================================
Service Id
: 1
Vpn Id
: 0
Service Type
: i-VPLS
Description
: (Not Specified)
Customer Id
: 1
Last Status Change: 04/01/2010 00:14:58
Last Mgmt Change : 04/01/2010 03:07:23
Admin State
: Up
Oper State
: Up
MTU
: 1514
Def. Mesh VC Id
: 1
SAP Count
: 1
SDP Bind Count
: 0
Snd Flush on Fail : Enabled
Host Conn Verify : Disabled
Propagate MacFlush: Disabled
b-Vpls Id
: 100
Oper ISID
: 1
b-Vpls Status
: Up
Snd Flush in bVpls: All-from-me
Flsh On bVpls Fail: enabled
Prop Flsh fr bVpls: disabled
------------------------------------------------------------------------------Service Access & Destination Points
-------------------------------------------------------------------------------

Advanced Configuration Guide

Page 1633

Configuration

Identifier
Type
AdmMTU OprMTU Adm Opr
------------------------------------------------------------------------------sap:1/1/4:1
q-tag
1518
1518
Up
Up
===============================================================================
*A:MTU-1#

The following command shows all the I-VPLS instances multiplexed into a particular B-VPLS.
*A:MTU-1# show service id 100 i-vpls
===============================================================================
Related i-Vpls services for b-Vpls service 100
===============================================================================
i-Vpls SvcId
Oper ISID
Admin
Oper
------------------------------------------------------------------------------1
1
Up
Up
2
2
Up
Up
------------------------------------------------------------------------------Number of Entries : 2
------------------------------------------------------------------------------===============================================================================
*A:MTU-1#

Some useful commands to check the I and B VPLS FIBs correlating C-MACs and B-MACs:
*A:MTU-1# show service id 1 fdb pbb
=============================================================================
Forwarding Database, i-Vpls Service 1
=============================================================================
MAC
Source-Identifier
B-Svc
b-Vpls MAC
Type/Age
----------------------------------------------------------------------------00:11:00:00:00:00 sap:1/1/4:1
100
N/A
L/0
00:33:00:00:00:00 b-sdp:111:100
100
00:31:31:31:31:31 L/0
=============================================================================
*A:MTU-1#

*A:MTU-1# show service id 100 fdb pbb


======================================================================
Forwarding Database, b-Vpls Service 100
======================================================================
MAC
Source-Identifier
iVplsMACs Epipes
Type/Age
---------------------------------------------------------------------00:31:31:31:31:31 sdp:111:100
2
0
L/0
24:7f:ff:00:00:00 sdp:111:100
0
0
L/0
======================================================================
*A:MTU-1#

Page 1634

Advanced Configuration Guide

PBB-VPLS

If mac-names are used in the configuration, the following commands can help to show the
translations:
A:MTU-1# show service pbb mac-name
=====================================================================
MAC Name Table
=====================================================================
MAC-Name
MAC-Address
--------------------------------------------------------------------MTU-1
00:11:11:11:11:11
MTU-2
00:21:21:21:21:21
MTU-3
00:31:31:31:31:31
=====================================================================
*A:MTU-1#

A:MTU-1# show service pbb mac-name MTU-3 detail


=====================================================================
Services Using MAC name='MTU-3' addr='00:31:31:31:31:31'
=====================================================================
Svc-Id
ISID
--------------------------------------------------------------------3
3
1
N/A
--------------------------------------------------------------------Number of services: 2
=====================================================================
*A:MTU-1#

The following command shows the base MAC notification parameters as well as the source BMAC configured at the service PBB level. Note that those values are overridden by any potential
mac-notification or source B-MAC values configured under the B-VPLS service context.
A:MTU-1# show service pbb base
======================================================================
PBB MAC Information
======================================================================
MAC-Notif Count
: 3
MAC-Notif Interval
: 1
Source BMAC
: 00:11:11:11:11:11
======================================================================
*A:MTU-1#

If mac-notification is used in a particular B-VPLS, the configured least significant bits for the sapbmac on a particular MC-LAG can be shown by using the detailed view of the show lag
command:
A:MTU-1# show lag 1 detail
===============================================================================
LAG Details
===============================================================================
Description
: N/A
------------------------------------------------------------------------------Details

Advanced Configuration Guide

Page 1635

Configuration

------------------------------------------------------------------------------Lag-id
: 1
Mode
: access
Adm
: up
Opr
: up
<snip>
MC Peer Address
: 192.0.2.21
MC Peer Lag-id
: 1
MC System Id
: 00:00:00:00:00:01
MC System Priority
: 65535
MC Admin Key
: 15
MC Active/Standby
: active
MC Lacp ID in use
: true
MC extended timeout : false
MC Selection Logic : local master decided
MC Config Mismatch : no mismatch
Source BMAC LSB
: use-lacp-key
Oper Src BMAC LSB
: 00:0f
<snip>

The following commands allow the operator to check the LDP label mapping, label withdrawal,
messages and also the MAC-flush messages for regular VPLS, for I-VPLS and B-VPLS including
the PBB extensions and TLVs.
*A:MTU-1# show debug
debug
router "Base"
ldp
peer 192.0.2.1
event
exit
packet
init detail
label detail
exit
exit
peer 192.0.2.2
event
exit
packet
init detail
label detail
exit
exit
exit
exit
exit

Page 1636

Advanced Configuration Guide

PBB-VPLS

The following debug commands can help the operator to troubleshoot MMRP.
*A:MTU-1# debug service id 100 mrp
- mrp
- no mrp
all-events
[no] applicant-sm
[no] leave-all-sm
[no] mmrp-mac
[no] mrpdu
[no] periodic-sm
[no] registrant-sm
[no] sap
[no] sdp

Advanced Configuration Guide

- Enable/disable MRP
- Enable/disable MRP
machine changes
- Enable/disable MRP
machine changes
- Enable/disable MRP
address
- Enable/disable MRP
- Enable/disable MRP
machine changes
- Enable/disable MRP
machine changes
- Enable/disable MRP
- Enable/disable MRP

debugging for all events


debugging for applicant state
debugging for leave all state
debugging for a particular MAC
debugging for Rx/Tx MRP PDUs
debugging for periodic state
debugging for registrant state
debugging for a particular SAP
debugging for a particular SDP

Page 1637

Conclusion

Conclusion
PBB-VPLS allows the service providers to scale VPLS services by multiplexing customer I-VPLS
instances into one or more B-VPLS instances. This multiplexing dramatically reduces the number
of services, pseudowires and MAC addresses in the core and therefore allows the service provider
to scale Layer-2 multipoint networks and provide services across international backbones.
The example used in this section shows the configuration of the customer and backbone VPLS
instances as well as all the related features which are required for this environment. Show and
debug commands have also been suggested so that the operator can verify and troubleshoot the
service.

Page 1638

Advanced Configuration Guide

Point-to-Point LSPs

In This Chapter
This section provides information about point-to-point LSPs (static, LDP and RSVP-TE).
Topics in this section include:

Applicability on page 1640

Overview on page 1641

Configuration on page 1645

Conclusion on page 1666

Advanced Configuration Guide

Page 1639

Applicability

Applicability
This configuration note is applicable to all of the 7750, 7450, and 7710 SR and ESS series. It was
tested on release 8.0R4. There are no pre-requisites or conditions on the hardware for this
configuration.

Page 1640

Advanced Configuration Guide

Point-to-Point LSPs

Overview
Due to the connectionless nature of the network layer protocol IP, packets travel through the
network on a hop-by-hop basis with routing decisions made at each node. As a result, hyper
aggregation of data on certain links may occur and it may impact the providers ability to provide
guaranteed service levels across the network end-to-end. To address these shortcomings, MPLS
(Multiprotocol Label Switching) was developed. The technology provides the capability to
establish connection oriented paths, called Label Switched Paths (LSPs), over a connectionless
(IP) network. The LSP offers a mechanism to engineer network traffic independently from the
underlying network routing protocol (mostly IP) to improve the network resiliency and recovery
options and to permit delivery of new services that are not readily supported by conventional IP
routing techniques (Layer 2 IP VPNs). These benefits are essential for todays communication
network explaining the wide deployment base of the MPLS technology.
RFC 3031, Multiprotocol Label Switching Architecture, specifies the MPLS architecture while
this document describes the configuration and troubleshooting of point-to-point LSPs on AlcatelLucent SR and ESS series routers.

Packet Forwarding
As a packet of a connectionless network layer protocol travels from one router to the next, each
router in the network makes an independent forwarding decision by performing the following
basic tasks: first analyzing the packets header, then referencing the local routing table to find the
longest match based on the destination address in the IP header, and finally sending out the packet
on the selected interface. In other terms, the first function partitions the entire set of possible
packets into a set of Forwarding Equivalence Classes (FECs). All packets associated to a
particular FEC will be forwarded along the same logical path to the same destination. The second
function maps each FEC to a next hop destination router. Each router along the packets path
performs these actions.
On the other hand, in MPLS the assignment of a particular packet to a particular FEC is done just
once, as the packet enters the network. In turn the FEC is mapped to an LSP, which is presignalled prior to any data flowing. An MPLS label, representing the FEC to which the packet is
assigned, is attached to the packet (push operation) and once labelled the packet is forwarded to
the next hop router along that LSP path. At subsequent hops, there is no further analysis of the
packet's network layer header. Instead, the label is used as an index into a table which specifies the
next hop and a new label. The old label is replaced with the new label (swap operation), and the
packet is forwarded to its next hop. At the MPLS network egress, the label is removed from the
packet (POP operation). If this router is the final destination (based on the remaining packet), the
packet is handed to the receiving application (such as a VPLS domain). If this router is not the
final destination of the packet, the packet will be sent into a new MPLS tunnel or forwarded by
conventional IP forwarding towards the Layer 3 destination.

Advanced Configuration Guide

Page 1641

Overview

Terminology
LSR

LSR

PUSH

POP
LSP Tunnel

ILER

eLER

LSR
SWAP
IP Data
IP Header
Data Link

IP

IP Data
MPLS Header A
IP Header
Data Link

IP Data
MPLS Header B
IP Header
Data Link

IP Data
MPLS Header C
IP Header
Data Link

MPLS

IP Data
IP Header
Data Link

IP

Figure 160: Generic MPLS Network, MPLS Label Operations

Figure 160 depicts a general network topology clarifying the MPLS-related terms. A Label Edge
Router (LER) is a device at the edge of an MPLS network, with at least one interface outside the
MPLS domain. A router is usually defined as an LER based on its position relative to a particular
LSP. The MPLS router at the head-end of an LSP is called the ingress Label Edge Router (iLER).
The MPLS router at the tail-end of an LSP is called the egress Label Edge Router (eLER). The
iLER receives unlabeled packets from outside the MPLS domain then applies MPLS labels to the
packets and forwards the labelled packets into the MPLS domain. The eLER receives labelled
packets from the MPLS domain then removes the labels and forwards unlabeled packets outside
the MPLS domain. Note that Release 8.0 added the ability for the eLER to signal an implicit-null
label (numeric value 3). This informs the previous hop to send MPLS packets without an outer
label and so is known as penultimate hop popping (PHP). This is also available when using static
LSPs.
A Label Switching Router (LSR) is a device internal to an MPLS network, with all interfaces
inside the MPLS domain. These devices switch labelled packets inside the MPLS domain. In the
core of the network, LSR ignore the packets network layer (IP) header and simply forward the
packet using the MPLS label swapping mechanism.
A single LSP is uni-directional. In common practice, because the bi-directional nature of most
traffic flows is implied, the term LSP often is used to define the pair of LSPs that enable the
bidirectional flow. For ease of terminology and discussion however, the LSP in this document is
referred to as a single entity.

Page 1642

Advanced Configuration Guide

Point-to-Point LSPs

LSP Establishment
Prior to packet forwarding, the LSP must be established. In order to do so, labels need to be
distributed for the path. Labels are usually distributed by a downstream router in the upstream
direction (relative to the data flow). There are a number of ways used for label distribution.

The label distribution can be done manually by the network administrator by configuring
static LSPs. Although a high control level of the labels in use is achieved, the LSP cannot
enjoy the resilience and recovery functionality the dynamic label signaling protocols can
offer.

LDP (RFC 5036, LDP Specification) can be considered as an extension to the network
IGP. As routers become aware of new destination networks, they advertise labels in the
upstream direction that will allow upstream routers to reach the destination.

RSVP-TE (RFC 3209, RSVP-TE: Extensions to RSVP for LSP Tunnels) can also be used
to signal LSPs across the network. RSVP-TE is used for traffic engineering when the
ingress router wishes to create an LSP with specific constraints beyond the best route
chosen by the IGP. RSVP-TE identifies the specific path desired for the LSP and may
include resource requirements for the path.

The most important benefit of the label swapping mechanism RSVP-TE is its ability to map any
type of user traffic to a LSP that has been specifically engineered to satisfy user traffic
requirements. Customized LSPs may be created based on hop count or bandwidth requirements.
They can even be routed through specific network links or nodes, as specified by the ingress node.
This offers service providers precise control over the flow of traffic in their networks and results in
a network that operates more efficiently and provides more predictable and scalable services.

Advanced Configuration Guide

Page 1643

Overview

Testbed Topology
The network topology is displayed in Figure 161. The setup consists of six 7750 nodes located in a
single autonomous system.

192.168.1.1/30
PE-1
192.0.2.1

1/1/1

192.168.1.2/30
1/1/1

192.168.5.1/30
PE-2
192.0.2.2

1/1/2

192.168.5.2/30
1/1/1

PE-3
192.0.2.3

1/1/2 192.168.2.1/30

192.168.4.1/30 1/1/3

192.168.7.1/30 1/1/2

1/1/1 192.168.2.2/30

192.168.4.2/30 1/1/1

192.168.7.2/30 1/1/1

192.168.3.1/30
1/1/2
PE-4
192.0.2.4

192.168.3.2/30

192.168.6.1/30

1/1/2

1/1/3

192.168.6.2/30
1/1/2
PE-6
192.0.2.6

PE-5
192.0.2.5

OSSG422

Figure 161: MPLS Testbed Topology

Page 1644

Advanced Configuration Guide

Point-to-Point LSPs

Configuration
As a general pre-requisite for the configuration of MPLS LSPs, a correctly working IGP is
required1; either OSPF or IS-IS can be used for this purpose.
For LSPs that are set up manually or using RSVP-TE, the first step is to enable MPLS on:

All network interfaces that will be used to carry LSPs

System IP address

For manually configured LSPs, any interface used by the static LSP must be added into the MPLS
protocol instance, even though RSVP is not actually used to signal labels. For router PE-1 this
results in the following configuration:
A:PE-1# configure router mpls
A:PE-1>config>router>mpls# info
---------------------------------------------interface "system"
exit
interface "int-PE-1-PE-2"
exit
interface "int-PE-1-PE-4"
exit
no shutdown
---------------------------------------------A:PE-1>config>router>mpls#

1. Static and strict path LPSs do not need an IGP.

Advanced Configuration Guide

Page 1645

Configuration

Manually Configured LSPs


As an example, a static LSP will be created starting from PE-1, running over PE-2 and PE-5, then
terminating on PE-6 as depicted in Figure 162.

192.168.1.1/30
PE-1
192.0.2.1

1/1/1

192.168.1.2/30
1/1/1

192.168.5.1/30
PE-2
192.0.2.2

1/1/2

192.168.5.2/30
1/1/1

PE-3
192.0.2.3

1/1/2 192.168.2.1/30

192.168.4.1/30 1/1/3

192.168.7.1/30 1/1/2

1/1/1 192.168.2.2/30

192.168.4.2/30 1/1/1

192.168.7.2/30 1/1/1

192.168.3.1/30
1/1/2
PE-4
192.0.2.4

192.168.3.2/30

192.168.6.1/30

1/1/2

1/1/3

192.168.6.2/30
1/1/2
PE-6
192.0.2.6

PE-5
192.0.2.5

OSSG423

Figure 162: Static LSP Running Over PE-1 PE-2 PE-5 PE-6

For each node verify the available labels prior to beginning the configuration and verify the
acceptable label range for use with static configurations.
A:PE-1# show router mpls label-range
==============================================================================
Label Ranges
==============================================================================
Label Type
Start Label
End Label
Aging
Total Available
-----------------------------------------------------------------------------Static-lsp
32
1023
992
Static-svc
2048
18431
16384
Dynamic
32768
131071
0
98304
==============================================================================
A:PE-1#

Page 1646

Advanced Configuration Guide

Point-to-Point LSPs

The label range for static LSPs extends from the value 32 to 1023. To ensure the labels have not
already been allocated to another configuration, use the command:
A:PE-1# show router mpls label 32 1023 in-use
================================================================
MPLS Labels from 32 to 1023 (In-use)
================================================================
Label
Label Type
Label Owner
------------------------------------------------------------------------------------------------------------------------------In-use labels (Owner: All) in specified range
: 0
In-use labels in entire range
: 0
================================================================
A:PE-1#

As no LSPs are currently originating, passing through, or terminating in the node, no labels are in
use and any label from the range 32 to 1023 is available for the static LSP. For the originating
router PE-1, the label 100 will be used for the push operation on the interface towards PE-2.
Static LSPs are configured within the MPLS configuration context, but do not rely on dynamic
label signaling.
The configuration of the MPLS static LSP head-end PE-1 contains:

The system IP address of the destination router PE-6 (to).

A push operation of the label 100.

The interface address facing the current node of the next hop along the static path, which
is PE-2 (nexthop).

A:PE-1# configure router mpls static-lsp "PE-1-PE-6"


A:PE-1>config>router>mpls>static-lsp$ to 192.0.2.6
A:PE-1>config>router>mpls>static-lsp$ push 100 nexthop 192.168.1.2
A:PE-1>config>router>mpls>static-lsp$ no shutdown
A:PE-1>config>router>mpls>static-lsp$ exit all

The transit LSRs (PE-2 and PE-5) perform swap operations and forward the packet to the
manually defined next-hop. On the LSR under the context of the interface on which the incoming
LSP arrives, the correct label is selected (label-map) and in this context a swap operation with a
new label and the new next hop (nexthop) is entered.
A:PE-2>config>router>mpls# interface int-PE-2-PE-1
A:PE-2>config>router>mpls>if# label-map 100
A:PE-2>config>router>mpls>if>label-map$ swap 150 nexthop 192.168.4.2
A:PE-2>config>router>mpls>if>label-map$ no shutdown
A:PE-2>config>router>mpls>if>label-map$ exit all
A:PE-5# configure router mpls interface int-PE-5-PE-2
A:PE-5>config>router>mpls>if$ label-map 150

Advanced Configuration Guide

Page 1647

Configuration

A:PE-5>config>router>mpls>if>label-map$ swap 200 nexthop 192.168.6.2


A:PE-5>config>router>mpls>if>label-map$ no shutdown
A:PE-5>config>router>mpls>if>label-map$ back

The terminating router PE-6 performs a POP operation and forwards the now unlabeled packets
external to the MPLS domain.
A:PE-6>config>router>mpls# interface int-PE-6-PE-5
A:PE-6>config>router>mpls>if$ label-map 200
A:PE-6>config>router>mpls>if>label-map$ pop
A:PE-6>config>router>mpls>if>label-map$ no shutdown
A:PE-6>config>router>mpls>if>label-map$ exit all

To verify the operational status of the static LSP configuration the show router mpls static-lsp
command is used on the iLER. A static LSP is considered to be operationally up when only its
next-hop is reachable. Since there is no check whether the end-to-end LSP path is up (the LSP
connectivity to the eLER is never verified), it can be the static LSP path is broken while the iLER
displays an operational enabled LSP.
A:PE-1# show router mpls static-lsp
===============================================================================
MPLS Static LSPs (Originating)
===============================================================================
LSP Name
To
Next Hop
Out Label Up/Down Time
Adm Opr
ID
Out Port
------------------------------------------------------------------------------PE-1-PE-6
192.0.2.6
192.168.1.2
100
0d 00:01:50
Up
Up
2
1/1/1
------------------------------------------------------------------------------LSPs : 1
===============================================================================
A:PE-1#

On the LSR the transit keyword is added to the command


A:PE-2# show router mpls static-lsp transit
===============================================================================
MPLS Static LSPs (Transit)
===============================================================================
In Label
In Port
Out Label
Out Port
Next Hop
Adm
Opr
------------------------------------------------------------------------------100
1/1/1
150
1/1/3
192.168.4.2
Up
Up
------------------------------------------------------------------------------LSPs : 1
===============================================================================
A:PE-2#

A:PE-5# show router mpls static-lsp transit


===============================================================================
MPLS Static LSPs (Transit)

Page 1648

Advanced Configuration Guide

Point-to-Point LSPs

===============================================================================
In Label
In Port
Out Label
Out Port
Next Hop
Adm
Opr
------------------------------------------------------------------------------150
1/1/1
200
1/1/3
192.168.6.2
Up
Up
------------------------------------------------------------------------------LSPs : 1
===============================================================================
A:PE-5#

And, on the terminating router (eLER), the keyword terminate is added.


A:PE-6# show router mpls static-lsp terminate
===============================================================================
MPLS Static LSPs (Terminate)
===============================================================================
In Label
In Port
Out Label
Out Port
Next Hop
Adm
Opr
------------------------------------------------------------------------------200
1/1/2
n/a
n/a
n/a
Up
Up
------------------------------------------------------------------------------LSPs : 1
===============================================================================
A:PE-6#

Advanced Configuration Guide

Page 1649

Configuration

To track the label action associated with the static LSP configuration, the show router mpls
interface label-map command can be used on all LSRs and eLERs (not iLER).
A:PE-2# show router mpls interface label-map
===============================================================================
MPLS Interfaces (Label-Map)
===============================================================================
In Label In I/F
Out Label Out I/F
Next Hop
Type
Adm Opr
------------------------------------------------------------------------------100
1/1/1
150
1/1/3
192.168.4.2
Static
Up
Up
------------------------------------------------------------------------------Interfaces : 1
===============================================================================
A:PE-2#

A:PE-6# show router mpls interface label-map


===============================================================================
MPLS Interfaces (Label-Map)
===============================================================================
In Label In I/F
Out Label Out I/F
Next Hop
Type
Adm Opr
------------------------------------------------------------------------------200
1/1/2
n/a
n/a
n/a
Static
Up
Up
------------------------------------------------------------------------------Interfaces : 1
===============================================================================
A:PE-6#

The show router mpls status command is used to verify each of the LSP types, the number
configured and whether they originate on, transit through or terminate on the router.
A:PE-1# show router mpls status
===============================================================================
MPLS Status
===============================================================================
Admin Status
: Up
Oper Status
: Up
Oper Down Reason
: n/a
FR Object
: Enabled
Resignal Timer
: Disabled
Hold Timer
: 1 seconds
Next Resignal
: N/A
Srlg Frr
: Disabled
Srlg Frr Strict
: Disabled
Dynamic Bypass
: Enabled
User Srlg Database : Disabled
Least Fill Min Thd.: 5 percent
LeastFill ReoptiThd: 10 percent
Sec FastRetryTimer : Disabled
LSP Counts
Originate
Transit
Terminate
------------------------------------------------------------------------------Static LSPs
1
0
0
Dynamic LSPs
0
0
0
Detour LSPs
0
0
0
===============================================================================
A:PE-1#

Page 1650

Advanced Configuration Guide

Point-to-Point LSPs

PHP can be used with static LSPs. This is achieved by configuring the penultimate LER to swap
the incoming label to implicit-null instead of a specific label value (the label-map must be
shutdown to add the swap command).
A:PE-5# configure router mpls interface
A:PE-5>config>router>mpls>if$ label-map
A:PE-5>config>router>mpls>if>label-map$
A:PE-5>config>router>mpls>if>label-map$
A:PE-5>config>router>mpls>if>label-map$

int-PE-5-PE-2
150
swap implicit-null-label nexthop 192.168.6.2
no shutdown
back

The previous configuration will cause PE-5 to pop the top label from the incoming labelled frame
received from PE-2 and send it to PE-6 without adding another outer label. The result can be seen
from the following command (note that label 3 is never actually pushed onto a frame).
A:PE-5# show router mpls static-lsp transit
===============================================================================
MPLS Static LSPs (Transit)
===============================================================================
In Label
In Port
Out Label
Out Port
Next Hop
Adm
Opr
------------------------------------------------------------------------------150
1/1/1
3
1/1/3
192.168.6.2
Up
Up
------------------------------------------------------------------------------LSPs : 1
===============================================================================

If the traffic arriving at PE-5 was IP with a single label then it would arrive at PE-6 as unlabeled IP
traffic.
If the static LSP spans a single hop (PE-1 to PE-2) the ingress LER would push the implicit-null
instead of using a swap.
A:PE-1# configure router mpls static-lsp PE-1-PE-2
A:PE-1>config>router>mpls>static-lsp$ to 192.0.2.2
A:PE-1>config>router>mpls>static-lsp$ push implicit-null-label nexthop 192.168.1.2
A:PE-1>config>router>mpls>static-lsp$ no shutdown
A:PE-1>config>router>mpls>static-lsp$ exit all

In this case, no MPLS action (swap or pop) is required for this LSP on PE-2 with respect to this
LSP.

Advanced Configuration Guide

Page 1651

Configuration

LDP
LDP is a simple label distribution protocol with basic MPLS functionality (no traffic engineering
and usually no recovery options). It relies on the underlying routing information provided by an
IGP in order to forward labelled packets. Each LDP configured LSR will originate a label for its
system address and a label for each FEC for which it has a next-hop that is external to the MPLS
domain, without the explicit need to create the LSPs. When deviations from this default behavior
are desired, import and export policies can be applied.
The configuration is as simple as enabling the LDP protocol instance and adding all network
interfaces, for each node. As an example the configuration on node PE-1 is displayed below;
similar configurations apply on the other nodes.
A:PE-1# configure router ldp
A:PE-1>config>router>ldp$ interface-parameters
A:PE-1>config>router>ldp>if-params$ interface int-PE-1-PE-2
A:PE-1>config>router>ldp>if-params>if$ back
A:PE-1>config>router>ldp>if-params# interface int-PE-1-PE-4
A:PE-1>config>router>ldp>if-params>if$ back
A:PE-1>config>router>ldp>if-params# back

The show router ldp discover and show router ldp session commands can be used to verify the
LDP peers and sessions. The adjacency type (AdjType) needs to be Link while the state should be
Estab(lished).
A:PE-1# show router ldp discovery
===============================================================================
LDP Hello Adjacencies
===============================================================================
Interface Name
Local Addr
Peer Addr
AdjType State
------------------------------------------------------------------------------int-PE-1-PE-2
192.0.2.1
192.0.2.2
Link
Estab
int-PE-1-PE-4
192.0.2.1
192.0.2.4
Link
Estab
------------------------------------------------------------------------------No. of Hello Adjacencies: 2
===============================================================================
A:PE-1#

A:PE-1# show router ldp session


=============================================================================
LDP Sessions
=============================================================================
Peer LDP Id
Adj Type
State
Msg Sent Msg Recv Up Time
----------------------------------------------------------------------------192.0.2.2:0
Link
Established
157
158
0d 00:06:56
192.0.2.4:0
Link
Established
33
34
0d 00:01:12
----------------------------------------------------------------------------No. of Sessions: 2
=============================================================================

Page 1652

Advanced Configuration Guide

Point-to-Point LSPs

A:PE-1#

The show router ldp bindings command displays the contents of the LIB (Label Information
Base) and should contain all labels locally generated (IngLbl) and those received from any LDP
neighbors (EgrLbl), whether they are in use or not.
A:PE-1# show router ldp bindings
===============================================================================
LDP LSR ID: 192.0.2.1
===============================================================================
Legend: U - Label In Use, N - Label Not In Use, W - Label Withdrawn
S - Status Signaled Up, D - Status Signaled Down
E - Epipe Service, V - VPLS Service, M - Mirror Service
A - Apipe Service, F - Fpipe Service, I - IES Service, R - VPRN service
P - Ipipe Service, WP - Label Withdraw Pending, C - Cpipe Service
TLV - (Type, Length: Value)
===============================================================================
LDP Prefix Bindings
===============================================================================
Prefix
Peer
IngLbl
EgrLbl EgrIntf/
EgrNextHop
LspId
------------------------------------------------------------------------------192.0.2.1/32
192.0.2.2
131071U
---192.0.2.1/32
192.0.2.4
131071U
---192.0.2.2/32
192.0.2.2
-131071 1/1/1
192.168.1.2
192.0.2.2/32
192.0.2.4
131070U
131063
--192.0.2.3/32
192.0.2.2
131068N
131067 1/1/1
192.168.1.2
192.0.2.3/32
192.0.2.4
131068U
131062
--192.0.2.4/32
192.0.2.2
131065U
131065
--192.0.2.4/32
192.0.2.4
-131065 1/1/2
192.168.2.2
192.0.2.5/32
192.0.2.2
131069N
131069 1/1/1
192.168.1.2
192.0.2.5/32
192.0.2.4
131069U
131061
--192.0.2.6/32
192.0.2.2
131067N
131068 1/1/1
192.168.1.2
192.0.2.6/32
192.0.2.4
131067U
131060
--------------------------------------------------------------------------------No. of Prefix Bindings: 12
===============================================================================
...
A:PE-1#

The show router ldp bindings active command displays all labels and the associated label action
used for label switching packets.
A:PE-1# show router ldp bindings active
===============================================================================
Legend: (S) - Static
===============================================================================
LDP Prefix Bindings (Active)
===============================================================================
Prefix
Op
IngLbl
EgrLbl
EgrIntf/LspId EgrNextHop
------------------------------------------------------------------------------192.0.2.1/32
Pop 131071
---192.0.2.2/32
Push
-131071
1/1/1
192.168.1.2
192.0.2.2/32
Swap 131070
131071
1/1/1
192.168.1.2
192.0.2.3/32
Push
-131067
1/1/1
192.168.1.2

Advanced Configuration Guide

Page 1653

Configuration

192.0.2.3/32
Swap 131068
131067
1/1/1
192.168.1.2
192.0.2.4/32
Push
-131065
1/1/2
192.168.2.2
192.0.2.4/32
Swap 131065
131065
1/1/2
192.168.2.2
192.0.2.5/32
Push
-131069
1/1/1
192.168.1.2
192.0.2.5/32
Swap 131069
131069
1/1/1
192.168.1.2
192.0.2.6/32
Push
-131068
1/1/1
192.168.1.2
192.0.2.6/32
Swap 131067
131068
1/1/1
192.168.1.2
------------------------------------------------------------------------------No. of Prefix Bindings: 11
===============================================================================
A:PE-1#

In order to signal PHP with LDP, implicit-null must be configured on the eLER.
A:PE-6# configure router ldp implicit-null-label

The implicit-null is signalled immediately, all related labels are withdrawn and re-advertised with
the label 3. The new label would show up on PE-5 as a swap from the ingress label to an egress
label of 3. If the traffic arriving at PE-5 was IP with a single label then it would arrive at PE-6 as
unlabeled IP traffic.

Page 1654

Advanced Configuration Guide

Point-to-Point LSPs

Import and Export Policies


The default label handling behavior is to originate label bindings for the system address and to
propagate all FECs received. If this is not the desired behavior, an import/export policy can be
applied. An export policy may be configured to control the set of LDP label bindings advertised
by the LER (sending to LDP peers). As such, export policies are used to include additional FECs
rather than filtering FECs from those advertised. An import policy can be used to control for
which FECs a router will generate labels (accepting from LDP peers). This functionality is not
unique to LDP; it can be used for RSVP-TE, OSPF, and IS-IS as well as others.
By default no labels are generated for directly connected (local) interfaces. To change this
behavior, an export policy is created and applied to the LDP instance. There is no configuration
difference in defining an import and export policy.
A policy starts with the keyword begin contains a list of entries (of which each has a number), and
ends with the keyword commit. An entry typically contains matching criteria (however, it is not
required in such cases where everything matches) and a corresponding action. Entries without an
action are considered incomplete and are rendered inactive. When executing the policy, the router
executes the specified action on the first matching statement; it does not process any further
matches. For this reason, entries must be sequenced correctly from most to least specific.
The configuration of the LDP export policy for local interfaces is given below.
A:PE-1# configure router policy-options
A:PE-1>config>router>policy-options# begin
A:PE-1>config>router>policy-options# policy-statement LDP-export
A:PE-1>config>router>policy-options>policy-statement$ entry 10
A:PE-1>config>router>policy-options>policy-statement>entry$ from protocol direct
A:PE-1>config>router>policy-options>policy-statement>entry# action accept
A:PE-1>config>router>policy-options>policy-statement>entry>action# back
A:PE-1>config>router>policy-options>policy-statement>entry# back
A:PE-1>config>router>policy-options>policy-statement# back
A:PE-1>config>router>policy-options# commit
A:PE-1>config>router>policy-options# exit all

Advanced Configuration Guide

Page 1655

Configuration

There are 11 active LDP bindings before applying the export policy.
A:PE-1# show router ldp bindings active
===============================================================================
Legend: (S) - Static
===============================================================================
LDP Prefix Bindings (Active)
===============================================================================
Prefix
Op
IngLbl
EgrLbl
EgrIntf/LspId EgrNextHop
------------------------------------------------------------------------------192.0.2.1/32
Pop 131071
---192.0.2.2/32
Push
-131071
1/1/1
192.168.1.2
192.0.2.2/32
Swap 131070
131071
1/1/1
192.168.1.2
192.0.2.3/32
Push
-131069
1/1/1
192.168.1.2
192.0.2.3/32
Swap 131069
131069
1/1/1
192.168.1.2
192.0.2.4/32
Push
-131065
1/1/2
192.168.2.2
192.0.2.4/32
Swap 131068
131065
1/1/2
192.168.2.2
192.0.2.5/32
Push
-131067
1/1/1
192.168.1.2
192.0.2.5/32
Swap 131067
131067
1/1/1
192.168.1.2
192.0.2.6/32
Push
-131066
1/1/1
192.168.1.2
192.0.2.6/32
Swap 131066
131066
1/1/1
192.168.1.2
------------------------------------------------------------------------------No. of Prefix Bindings: 11
===============================================================================
A:PE-1#

The LDP export or import policy is applied to the LDP instance on the router, respectively, with
the export or import keyword.
A:PE-1# configure router ldp export LDP-export

When the export policy is applied, the active LDP binding table has two additional entries: the
local interfaces of PE-1.
A:PE-1# show router ldp bindings active
===============================================================================
Legend: (S) - Static
===============================================================================
LDP Prefix Bindings (Active)
===============================================================================
Prefix
Op
IngLbl
EgrLbl
EgrIntf/LspId EgrNextHop
------------------------------------------------------------------------------192.0.2.1/32
Pop 131071
---192.0.2.2/32
Push
-131071
1/1/1
192.168.1.2
192.0.2.2/32
Swap 131070
131071
1/1/1
192.168.1.2
192.0.2.3/32
Push
-131069
1/1/1
192.168.1.2
192.0.2.3/32
Swap 131069
131069
1/1/1
192.168.1.2
192.0.2.4/32
Push
-131065
1/1/2
192.168.2.2
192.0.2.4/32
Swap 131068
131065
1/1/2
192.168.2.2
192.0.2.5/32
Push
-131067
1/1/1
192.168.1.2
192.0.2.5/32
Swap 131067
131067
1/1/1
192.168.1.2

Page 1656

Advanced Configuration Guide

Point-to-Point LSPs

192.0.2.6/32
Push
-131066
1/1/1
192.168.1.2
192.0.2.6/32
Swap 131066
131066
1/1/1
192.168.1.2
192.168.1.0/30
Pop 131065
---192.168.2.0/30
Pop 131064
---------------------------------------------------------------------------------No. of Prefix Bindings: 13
===============================================================================
A:PE-1#

Advanced Configuration Guide

Page 1657

Configuration

RSVP-TE
RSVP-TE, an extension of the original RSVP protocol, has two major benefits adding to the basic
MPLS functionality. The first benefit is traffic engineering, which allows the ingress router to
create an LSP with specific constraints beyond the best route chosen by the IGP. The second
benefit is improved network resiliency and shorter service interruption times when a link or node
fails in the network.
In this section, an RSVP-TE based LSP is established from PE-1 to PE-6, starting with a simple
LSP with no specific TE constraints. Although the Fast Reroute (FRR), admin groups, hop limit
restriction, and bandwidth reservation features could be implemented, the usage of these features
is beyond the scope of this document.
Like the configuration of static LSPs, the MPLS instance needs to be enabled on each router and
all network interfaces facing the MPLS domain as well as the system interface. When adding
interfaces to the MPLS instance they are automatically added to the RSVP instance as well, but
the instance itself is still in an administrative shutdown state. The next step is to enable the RSVP
instance on all routers in the MPLS network. As a result all interfaces facing the MPLS domain as
well as the system interface are added to the MPLS and RSVP instance and both instances are in a
no shutdown state. For PE-1 this comes to:
A:PE-1# configure router rsvp
A:PE-1>config>router>rsvp# no shutdown
A:PE-1>config>router>rsvp# info
---------------------------------------------interface "system"
exit
interface "int-PE-1-PE-2"
exit
interface "int-PE-1-PE-4"
exit
no shutdown
---------------------------------------------A:PE-1>config>router>rsvp#

Strict or loose path On the iLER first the definition of a path is required. A path is a sequence of
MPLS routers (hops) through which the LSP -using that path- has to pass. It is not uniquely bound
to a particular LSP; it can be used by any LSP originating in that node. A hop in a path can be
strict or loose: strict or loose meaning that the LSP must take either a direct path from the previous
hop router to this router (strict) or can traverse through other routers (loose). The hops missing in
the loose path definition are created by calculating the IGP shortest path. A third possibility is an
entirely empty path implying not a single node is required to be present in the LSP path and the
shortest path from the IGP is used to define the LSP path. The use of other techniques, such as the
use of admin groups or shared risk link groups, are not covered in this document. Three paths are
configured below, respectively:

Page 1658

Advanced Configuration Guide

Point-to-Point LSPs

1. Only strict hops

2. Mixed strict and loose hops


3. Completely loose path
To find a valid path, the last hop in the path sequence needs to be the system IP or an interface
address of the terminating router (eLER). The IP addresses in the hop command can be the nodes
system IP addresses or its interface addresses. However, it is recommended to use the system IP
addresses as this allows more flexibility when finding new paths in failover scenarios (because the
upstream node could use any of multiple paths to the system address, where specifying the
interface address would restrict the upstream node to a single entry-point).
A:PE-1# configure router mpls path "strict_path"
A:PE-1>config>router>mpls>path$ hop 1 192.0.2.2 strict
A:PE-1>config>router>mpls>path$ hop 2 192.0.2.5 strict
A:PE-1>config>router>mpls>path$ hop 3 192.0.2.6 strict
A:PE-1>config>router>mpls>path$ no shutdown
A:PE-1# configure router mpls
A:PE-1>config>router>mpls# path
A:PE-1>config>router>mpls>path$
A:PE-1>config>router>mpls>path$
A:PE-1>config>router>mpls>path$

"loose_path"
hop 1 192.0.2.5 loose
hop 2 192.0.2.6 strict
no shutdown

A:PE-1# configure router mpls path "completely_loose_path"


A:PE-1>config>router>mpls>path$ no shutdown

The paths can be checked with the show router mpls path command.
A:PE-1# show router mpls path
===============================================================================
MPLS Path:
===============================================================================
Path Name
Adm Hop Index
IP Address
Strict/Loose
------------------------------------------------------------------------------strict_path
Up
1
192.0.2.2
Strict
2
192.0.2.5
Strict
3
192.0.2.6
Strict
loose_path

Up

1
2

192.0.2.5
192.0.2.6

Loose
Strict

completely_loose_path

Up

no hops

n/a

n/a

------------------------------------------------------------------------------Paths : 3
===============================================================================
A:PE-1#

Advanced Configuration Guide

Page 1659

Configuration

Simple RSVP LSP


The configuration of a simple LSP using RSVP signaling contains at least on the iLER:

System IP address of the terminating node (to)

Path the LSP will take to the eLER (primary)

Administratively enabled (no shutdown)

A:PE-1>configure router mpls lsp "lsp-PE-1-PE-6_simple"


A:PE-1>config>router>mpls>lsp# to 192.0.2.6
A:PE-1>config>router>mpls>lsp# primary "strict_path"
A:PE-1>config>router>mpls>lsp# no shutdown

The nodes through which the LSP will pass (LSRs and eLER) require no additional configuration:
enabling MPLS (and automatically RSVP together with it) on their interfaces suffices.
An overview of all LSPs configured on a particular node is given by the show router mpls lsp
command. More details about a particular LSP can be retrieved by adding the keyword detail to
the previous command.
A:PE-1# show router mpls lsp
===============================================================================
MPLS LSPs (Originating)
===============================================================================
LSP Name
To
Fastfail
Adm
Opr
Config
------------------------------------------------------------------------------lsp-PE-1-PE-6_simple
192.0.2.6
No
Up
Up
------------------------------------------------------------------------------LSPs : 1
===============================================================================
A:PE-1#

A:PE-1# show router mpls lsp lsp-PE-1-PE-6_simple detail


===============================================================================
MPLS LSPs (Originating) (Detail)
===============================================================================
------------------------------------------------------------------------------Type : Originating
------------------------------------------------------------------------------LSP Name
: lsp-PE-1-PE-6_simple
LSP Tunnel ID : 4
From
: 192.0.2.1
To
: 192.0.2.6
Adm State
: Up
Oper State
: Up
LSP Up Time : 0d 00:07:33
LSP Down Time : 0d 00:00:00
Transitions : 5
Path Changes
: 5
Retry Limit : 0
Retry Timer
: 30 sec
Signaling
: RSVP
Resv. Style
: SE
Hop Limit
: 255
Negotiated MTU : 1564
Adaptive
: Enabled
ClassType
: 0
FastReroute : Disabled
Oper FR
: Disabled
CSPF
: Disabled
ADSPEC
: Disabled

Page 1660

Advanced Configuration Guide

Point-to-Point LSPs

Metric
:
Include Grps:
None
Type
:
LdpOverRsvp :
Oper Metric :

RegularLsp
Enabled
65535

Exclude Grps
None
Least Fill
VprnAutoBind

:
: Disabled
: Enabled

Primary(a) : strict_path
Up Time
: 0d 00:07:33
Bandwidth
: 0 Mbps
===============================================================================
A:PE-1#

In order to signal PHP with RSVP, implicit-null must be configured on the eLER (RSVP must be
shutdown to perform this command).
A:PE-6# configure router rsvp implicit-null-label

The implicit-null is signalled after re-enabling RSVP and would show up on PE-5 as an egress
label of 3.
The use of implicit-null can also be enabled/disabled on a per interface basis (either RSVP, or the
interface within RSVP, must be shutdown to perform this change).
A:PE-6>config>router>rsvp# interface int-PE-6-PE-5
A:PE-6>config>router>rsvp>if# implicit-null-label
- implicit-null-label {<enable|disable>}
- no implicit-null-label

If the traffic arriving at PE-5 was IP with a single label then it would arrive at PE-6 as unlabeled IP
traffic.

Manual Resignal
Instead of waiting for the resignal timer to expire, one can manually trigger the resignal process.
The command includes both the LSP name and path to resignal:
A:PE-1# tools perform router mpls resignal lsp lsp-PE-1-PE-6_simple path strict_path

Advanced Configuration Guide

Page 1661

Configuration

LSP OAM
The LSP diagnostics are modelled after ICMP echo request/reply which provides a mechanism to
detect data plane failures in MPLS LSPs. For a given FEC, LSP ping verifies whether the packet
reaches the egress label edge router (LER). While in LSP traceroute mode, the packet is sent to the
control plane of each transit label switched router (LSR) which performs various checks to see if it
is actually a transit LSR for the path.
A:PE-1# oam lsp-ping lsp-PE-1-PE-6_simple
LSP-PING lsp-PE-1-PE-6_simple: 92 bytes MPLS payload
Seq=1, send from intf int-PE-1-PE-2, reply from 192.0.2.6
udp-data-len=32 ttl=255 rtt=3.21ms rc=3 (EgressRtr)
---- LSP lsp-PE-1-PE-6_simple PING Statistics ---1 packets sent, 1 packets received, 0.00% packet loss
round-trip min = 3.21ms, avg = 3.21ms, max = 3.21ms, stddev = 0.000ms
A:PE-1# oam lsp-trace lsp-PE-1-PE-6_simple
lsp-trace to lsp-PE-1-PE-6_simple: 0 hops min, 0 hops max, 116 byte packets
1 192.0.2.2 rtt=11.9ms rc=8(DSRtrMatchLabel)
2 192.0.2.3 rtt=6.35ms rc=8(DSRtrMatchLabel)
3 192.0.2.6 rtt=4.85ms rc=3(EgressRtr)

Page 1662

Advanced Configuration Guide

Point-to-Point LSPs

Debug Tools
A wide range of debug tools are available which can be tuned to the specific information of
importance for a certain troubleshooting task. In the debug router mpls context, the LSP object to
trace or monitor can be selected by the following parameters:

LSP name

Source address of the LSP ( the from parameter in the LSP definition)

Termination point of the LSP ( the to parameter in the LSP definition)

Tunnel ID of the LSP

LSP ID

A:PE-1# debug router mpls


- mpls [lsp <lsp-name>] [sender <source-address>] [endpoint
<endpoint-address>] [tunnel-id <tunnel-id>] [lsp-id <lsp-id>]
- no mpls
<lsp-name>
<source-address>
<endpoint-address>
<tunnel-id>
<lsp-id>

:
:
:
:
:

[80 chars max]


a.b.c.d
a.b.c.d
[0..4294967295]
[1..65535]

[no] event

+ Enable/disable debugging for specific MPLS events

In the debug command tree, the MPLS event type can be selected (tracing must be enabled):
A:PE-1# debug router mpls lsp lsp-PE-1-PE-6_simple event
- event
- no event
[no]
[no]
[no]
[no]
[no]
[no]
[no]

all
frr
iom
lsp-setup
mbb
misc
xc

Enable/disable
Enable/disable
Enable/disable
Enable/disable
Enable/disable
Enable/disable
Enable/disable

debugging
debugging
debugging
debugging
debugging
debugging
debugging

for
for
for
for
for
for
for

MPLS
MPLS
MPLS
MPLS
MPLS
MPLS
MPLS

all
frr
iom
lsp setup
mbb
misc
xc

As an example, the all keyword is entered, logging all MPLS events related to the selected LSP:
A:PE-1# debug router mpls lsp lsp-PE-1-PE-6_simple event all

Advanced Configuration Guide

Page 1663

Configuration

The last step is to create a log container which will gather all MPLS debugging information
according to the criteria set in the debug context. The from debug-trace parameter must be
configured but there are several options where the different captured entries will be stored:
console, a syslog server, SNMP, local file on the compact flash card, a temporary circular memory
buffer, or the telnet/SSH session from which you are logged into the node.
The log containers ID is just a local number without any other significance.
A:PE-1# configure log log-id 2
A:PE-1>config>log>log-id# from debug-trace
A:PE-1>config>log>log-id# to
- to console
- to file <log-file-id>
- to memory [<size>]
- to session
- to snmp [<size>]
- to syslog <syslog-id>
<console>
<syslog-id>
<snmp>
<log-file-id>
<memory>
<size>
<session>

:
:
:
:
:
:
:

keyword - specifies
[1..10]
keyword - specifies
[1..99]
keyword - specifies
[50..1024]
keyword - specifies

console as destination
SNMP as destination
memory as destination
telnet session as destination

For this example, the temporary buffer (with adjustable size) is chosen and the log container is
enabled (no shutdown).
A:PE-1>config>log>log-id# to memory
A:PE-1>config>log>log-id# no shutdown

All MPLS events related to the selected LSP are stored in the location (memory) specified. The
content of this log container can be viewed through the show log log-id 2 command.
A:PE-1# show log log-id 2
===============================================================================
Event Log 2
===============================================================================
Description : (Not Specified)
Memory Log contents [size=100
next event=13 (not wrapped)]
12 2010/01/29 17:30:06.78 UTC MINOR: DEBUG #2001 Base MPLS
"MPLS: RTM
Update traffic-engineering information for interface index 2
Oper state Up, Admin group bitmap 0x0, Max bandwidth 125000000Bps
Max reservable bandwidth 125000000Bps, Available bandwidth 0Bps"
11 2010/01/29 17:30:06.77 UTC MINOR: DEBUG #2001 Base MPLS

Page 1664

Advanced Configuration Guide

Point-to-Point LSPs

"MPLS: ICC
Set protect group 127, protect instance 3, use protected yes"
10 2010/01/29 17:30:00.82 UTC MINOR: DEBUG #2001 Base MPLS
"MPLS: RTM
Process RT Internal Unreg event for Pref 192.0.2.2/32"
...

Advanced Configuration Guide

Page 1665

Conclusion

Conclusion
MPLS provides the capability to establish connection oriented paths over a connectionless
network. The LSP offers a mechanism to engineer network traffic on constraint-based paths rather
than the IGP shortest path. This can greatly improve network resiliency. In this section, the
configuration of several LSP features is given together with the associated show output which can
be used to verify and troubleshoot.

Page 1666

Advanced Configuration Guide

Pseudowire QoS

In This Chapter
This section describes pseudowire QoS configurations.
Topics in this section include:

Applicability on page 1668

Overview on page 1669

Configuration on page 1674

Conclusion on page 1691

Advanced Configuration Guide

Page 1667

Applicability

Applicability
This example is applicable to the 7950 XRS-16c/20, 7750 SR-7/12, 7750 SR-c4/12 and 7450 ESS6/6v/7/12 platforms when all network IP interfaces are on IOM3-XP/IMM (FP2 and above)
hardware.
The configuration was tested on release 11.0R4. There are no other specific pre-requisites for this
configuration.

Page 1668

Advanced Configuration Guide

Pseudowire QoS

Overview
A pseudowire (PW) provides a virtual connection across an IP or MPLS network between services
configured on provider edge (PE) devices. From SR OS R10. OR 1, it is possible to provide
specific QoS to either a single pseudowire or a multiple pseudowires. This is supported for the
following:

SDP
MPLS
GRE

Epipe
Including vc-switching and dynamic MS-PW
PBB-epipe
BGP-VPWS (from 11.0R1)

VPLS
Mesh and spoke SDP
LDP signaled pseudowires
BGP-AD signaled pseudowires
I-VPLS, B-VPLS
BGP-VPLS

Spoke termination on IES/VPRN (both Epipe and Ipipe)

Apipe (from R10.0R4)

Cpipe (from R10.0R4)

Fpipe (from R10.0R4)

Ipipe (from R10.0R4)

It is supported at ingress on both Ethernet and POS/TDM ports on an IOM3-XP/IMM and only on
Ethernet ports at egress.
Bandwidth control is achieved using queue-groups which are implemented per FP (flexpath) at the
ingress and per port at the egress (these being relative to the data path through the system), as
shown in Figure 163 and Figure 164, respectively.

Advanced Configuration Guide

Page 1669

Overview

Both Spoke and Mesh SDPs


Single
PW QoS
Multiple PW QoS
to Same PE
SAP Service

Spoke-SDP

SAP Service

Spoke-SDP

FP
Queue-group
Queue-group

SAP Service

Mesh-SDP

SAP Service

Spoke-SDP

Service

Spoke-SDP

Queue-group
Spoke-SDP

Multiple PW QoS
to Different PEs

al_0245

Figure 163: Ingress PW QoS

Both Spoke and Mesh SDPs


Single
PW QoS
Multiple PW QoS
to Same PE
SAP Service

Spoke-SDP

SAP Service

Spoke-SDP

SAP Service

Mesh-SDP

SAP Service

Spoke-SDP

Service

Spoke-SDP

Port
Queue-group
Queue-group

Port
Queue-group

Spoke-SDP

Multiple PW QoS
to Different PEs

al_0246

Figure 164: Egress PW QoS

Page 1670

Advanced Configuration Guide

Pseudowire QoS

Bandwidth control is applied independently for ingress and egress, and can be set up for a single
pseudowire or for multiple pseudowires where the remote services are located on a single PE or on
multiple PEs.
It is possible to benefit from Hierarchical QoS which can be configured under the queue-groups,
but this is beyond the scope of this example.
The ingress and egress classification and egress marking is configured by applying a network QoS
policy to each pseudowire.

Ingress QoS
Ingress QoS is achieved using a queue group which is applied to an ingress FP on a card. Queue
groups applied to an FP can only contain policers, not queues. The network QoS policy applied to
the pseudowire redirects forwarding classes (FCs) to the individual queue group (unicast or
multipoint) policers. The actual queue group to be used is defined separately to the network QoS
policy, thereby allowing the network QoS policies to be independent from the queue groups used
and therefore both are reusable.
Ingress bandwidth control does not take into account the outer Ethernet header, the MPLS labels/
control word or GRE headers, or the FCS of the incoming frame. The configuration allows an
offset to be added or subtracted from the received frame size in order to change the actual length
used for the bandwidth control.
For example: if the same ingress rate is configured on a pseudowire (without a control word) and a
dot1q SAP, what packet-byte-offset needs to be used on the pseudowire in order to achieve the
same throughput as on the SAP?

SAP The following shows the bytes in the frame that are used by default on a policer
for the rate at a SAP ingress.
6B

6B

4B

2B

xxxxB

4B

Source
MAC

Dest.
MAC

802.1Q

Ether
Type

Payload

CRC/FCS
al_0247

VPLS Pseudowire For a tagged (vc-type vlan) pseudowire, it would be necessary to


add 4 bytes using the packet-byte-offset applied to the ingress policer in order to achieve
the same throughput as on the SAP. This compensates for the omission of the FCS that is
included on the SAP and so needs to be added.

Advanced Configuration Guide

Page 1671

Overview

6B

6B

2B

4B

4B

6B

6B

4B

2B

xxxxB

4B

Source
MAC

Dest.
MAC

Ether
Type

Tun MPLS
Label

VC MPLS
Label

Source
MAC

Dest.
MAC

802.1Q

Ether
Type

Payload

CRC/FCS
al_0248

VPRN Pseudowire For an Ipipe (vc-type ipipe) pseudowire, it would be necessary to


add 22 bytes using the packet-byte-offset to the ingress policer to achieve the same
throughput as on the SAP. This compensates for the omission of the source and
destination MAC addresses (12 bytes), Ether type (2 bytes), VLAN tag (4 bytes) and the
FCS (4 bytes) that are included on the SAP and so needs to be added.
6B

6B

2B

4B

4B

xxxxB

4B

Source
MAC

Dest.
MAC

Ether
Type

Tun MPLS
Label

VC MPLS
Label

Payload

CRC/FCS
al_0249

The ingress classification is configured in the ingress section of the network QoS policy and is
based on the outer encapsulation header only, the outer Ethernet header (dot1p/DE), MPLS labels
(EXP) or GRE headers (DSCP). At an egress LER, the ler-use-dscp is applicable only to IES and
VPRN pseudowires.

Egress QoS
Egress QoS is achieved using a queue group which is applied to an egress port. Queue groups
applied to a port can contain both policers and queues. The network QoS policy applied to the
pseudowire redirects forwarding classes (FCs) to the individual queue group policers/queues. The
actual queue group to be used is defined separately to the network QoS policy, thereby allowing
the network QoS policies to be independent from the queue groups used and therefore both are
reusable.
Egress bandwidth control does takes into account the outer Ethernet header, MPLS labels/control
word or GRE headers, and the FCS of the outgoing frame. The configuration allows an offset to be
added or subtracted from the sent frame size in order to affect the actual length used for the
bandwidth control.
For example, if the same egress rate is configured on a pseudowire (without a control word) and a
dot1q SAP, what packet-byte-offset needs to be used on the pseudowire in order to achieve the
same throughput as on the SAP?

Page 1672

SAP The following shows the bytes in the frame that are used by default on a policer/
queue at a SAP egress.

Advanced Configuration Guide

Pseudowire QoS

6B

6B

4B

2B

xxxxB

4B

Source
MAC

Dest.
MAC

802.1Q

Ether
Type

Payload

CRC/FCS
al_0250

VPLS Pseudowire For a tagged (vc-type vlan) pseudowire, it would be necessary to


subtract 22 bytes using the packet-byte-offset applied to the egress policer/queue applied
to achieve the same throughput as on the SAP. This compensates for the MPLS header
(source and destination MAC addresses (12 bytes), Ether type (2 bytes), two labels (8
bytes)) that is not included on the SAP and needs to be subtracted.

6B

6B

2B

4B

4B

6B

6B

4B

2B

xxxxB

4B

Source
MAC

Dest.
MAC

Ether
Type

Tun MPLS
Label

VC MPLS
Label

Source
MAC

Dest.
MAC

802.1Q

Ether
Type

Payload

CRC/FCS
al_0251

VPRN Pseudowire For an Ipipe (vc-type ipipe) pseudowire, it would be necessary to


subtract 4 bytes using the packet-byte-offset applied to the egress policer/queue applied to
achieve the same throughput as on the SAP. This compensates for the MPLS header
(source and destination MAC addresses (12 bytes), Ether type (2 bytes), two labels (8
bytes)) that is not included on the SAP so is subtracted, and the source and destination
MAC addresses (12 bytes), dot1q header (4 bytes) and Ether type (2 bytes) of the SAP
frame which needs to be added. This results in subtracting 4 bytes.
6B

6B

2B

4B

4B

xxxxB

4B

Source
MAC

Dest.
MAC

Ether
Type

Tun MPLS
Label

VC MPLS
Label

Payload

CRC/FCS
al_0252

The egress classification and marking is configured in the egress section of the network QoS
policy. DSCP/prec egress reclassification is supported from release R10.0R4 for IES and VPRN
spoke SDPs. The egress marking affects the outer encapsulation header, the outer Ethernet header
(dot1p/DE), MPLS labels (EXP) or GRE headers (DSCP).

Advanced Configuration Guide

Page 1673

Configuration

Configuration
The configuration of pseudowire QoS is described using an Epipe pseudowire. The topology is
shown in Figure 165.

PE-1

PE-2
Ingress Traffic
Single PW

SAP

Epipe

Spoke-SDP

Card 7 FP 1
Ingress
queue-group

Epipe

Port 7/1/2
Egress
queue-group
Egress Traffic

al_0253

Figure 165: Example Epipe Pseudowire Topology

The following pre-requisite configuration is assumed to be in place:

Hardware provisioning

IP address and routing

MPLS protocols

SDP

Epipe service, including the SAP

SAP QoS policies

Traffic is sent across a virtual leased line between PE-1 and PE-2 using Epipes with a pseudowire
configured as a spoke SDP on each PE. The QoS is applied to the pseudowire at the ingress and
egress of PE-1.
The following configuration is required for applying pseudowire QoS:

Page 1674

Create the ingress and egress queue groups.


These contain the ingress policer and egress policer/queue definitions.

Advanced Configuration Guide

Pseudowire QoS

Create an instance of the ingress queue group on the ingress FP and instance of the egress
queue group on the port that will be used for the pseudowire traffic.

Create a network QoS policy to redirect the traffic to the ingress and egress queue groups,
and to perform the ingress classification and egress marking.

Apply the network QoS policy, together with the reference to the ingress and egress queue
group instances, to the spoke SDP representing the pseudowire.

The traffic consists of two bidirectional flows, one in FC BE and one in FC EF. At the ingress of
the pseudowire, each FC is assigned to its own policer, whereas at the egress of the pseudowire,
FC BE is assigned to a queue and FC EF is assigned to a policer.
Although this example makes use of both ingress and egress queue groups, the focus is
pseudowire QoS, so the full details of queue group configuration are not covered.

Create the Ingress and Egress Queue Groups


Queue groups are created using templates, which are separate for ingress and egress. The
following shows the queue group templates configured.
configure qos
queue-group-templates
ingress
queue-group "ingress-queue-group" create
policer 1 create
rate 6000
packet-byte-offset add 4
exit
policer 2 create
rate 4000
packet-byte-offset add 4
exit
exit
exit
egress
queue-group "egress-queue-group" create
queue 1 best-effort create
rate 6000
xp-specific
packet-byte-offset subtract 22
exit
exit
policer 1 create
rate 4000
packet-byte-offset subtract 22
exit
exit
exit
exit

Advanced Configuration Guide

Page 1675

Configuration

The ingress queue group has two policers associated with it; policer 1 will be used for the FC BE
traffic and policer 2 will be used for the FC EF traffic. The configuration of policers in an ingress
queue group is the same as that in a sap-ingress QoS policy, with the exception that the percentrate is not supported within the queue group.
In order to achieve the same ingress throughput as that when applying the same rates to policers on
a dot1q tagged SAP, the packet-byte-offset adds 4 bytes to the packet length for both policers.
The egress queue group has one queue (queue 1) that will be used for the FC BE traffic and one
policer (policer 1) that will be used for the FC EF traffic. The configuration of policers in an
egress queue group is the same as that in a sap-egress QoS policy, with the exception that the
percent-rate is not supported within the queue group. The configuration of queues in an egress
queue group is the same as in a sap-egress QoS policy, with the exception that the avg-frameoverhead is not supported within the queue group.
In order to achieve the same egress throughput as that when applying the same rates to policers/
queues on a dot1q tagged SAP, the packet-byte-offset subtracts 22 bytes from the packet length for
both the policer and queue.
Rates have been configured such that the ingress and egress capacity of the BE traffic is 6Mb/s
and 4Mb/s for the EF traffic.

Create the Ingress FP and Egress Port Queue Group Instances


The queue group templates are then applied as individual instances to the ingress FP and egress
port; using instances allows the reuse of the same template.
Below is the ingress FP configuration. From a QoS perspective, it is also possible to configure a
policer-control-policy under the ingress queue group in order to perform hierarchical policing.
From R11.0R4, the configuration supports overrides for both the policer-control-policy
parameters and some of the queue group policer parameters.
configure
card 7
card-type imm5-10gb-xfp
mda 1
no shutdown
exit
fp 1
ingress
network
queue-group "ingress-queue-group" instance 1 create
exit
exit
exit
exit
no shutdown
exit

Page 1676

Advanced Configuration Guide

Pseudowire QoS

Below is the egress port configuration. From a QoS perspective, it is also possible to configure
under the egress queue group a policer-control-policy in order to perform hierarchical policing, a
scheduler-policy in order to perform hierarchical shaping and overrides for some of the queue
group queue parameters.
configure
port 7/1/2
ethernet
network
egress
queue-group "egress-queue-group" instance 1 create
exit
exit
exit
exit
no shutdown
exit

If there are redundant network interfaces over which the pseudowire traffic can enter or exit the
system, it is necessary to configure any ingress FP and egress port queue groups consistently
across all possible interfaces to be used by the pseudowire to ensure the QoS is always applied. If
a queue group configuration was omitted, the pseudowire would not be subject to the QoS defined
in that queue group.
If a LAG is used, the system only allows the egress port queue group to be added or removed from
the LAG primary port, thereby keeping the LAG configuration consistent. However, this is not
possible at the ingress as the queue-group is applied at the FP, so it is necessary to ensure that the
ingress queue group is applied consistently on all FPs corresponding to the configured LAG.

Advanced Configuration Guide

Page 1677

Configuration

Create the Network QoS Policy


A network QoS policy is created to redirect ingress and egress traffic to the respective queue
groups, and perform ingress classification (in this example).
The redirection to the queue group policer/queue is performed per FC.
At ingress, traffic can be redirected to policers (being the same or different policers) based on the
traffic type. Unicast traffic is redirected to a policer specified by the policer command and will use
the ingress shared policer-output-queues to access the switch fabric. All multipoint traffic is
redirected to the policer specified by the multicast-policer command (for example with a
pseudowire configured in a VPLS service, all broadcast, unknown and multicast traffic will use
this policer). The multipoint traffic accesses the switch fabric using the Ingress Multicast Path
Management queues. It is possible to individually redirect one traffic type (unicast or multipoint)
within an FC to a queue group policer while allowing the other traffic type to use default network
queues.
At egress, traffic can be redirected to a queue or to a policer. The policed traffic will exit the egress
port using one of the default network queues (with the queue chosen by FC assignment) or
optionally can use a queue in the egress queue group if configured in the port-redirect-group
command following the policer parameter.
Any FC not redirected to a queue-group, will continue to use the regular default network ingress
and egress queues.
The syntax for the FC redirection is as follows.
config# qos
network <network-policy-id> [create]
ingress
fc <fc-name>
fp-redirect-group multicast-policer <policer-id>
fp-redirect-group policer <policer-id>
egress
fc <fc-name>
port-redirect-group {queue <queue-id>|
policer <policer-id> [queue <queue-id>]}

The required commands are shown below.


configure qos
network 10 create
ingress
lsp-exp 5 fc ef profile in
fc be
fp-redirect-group policer 1
exit
fc ef
fp-redirect-group policer 2

Page 1678

Advanced Configuration Guide

Pseudowire QoS

exit
exit
egress
fc be
port-redirect-group queue 1
exit
fc ef
port-redirect-group policer 1
exit
exit
exit

At ingress, the FC BE and FC EF traffic are redirected to the two policers in the queue-group
applied to the FP. At egress, the two FCs are redirected to the queue and policer in the queue group
applied to the egress port.
The ingress classification required here is for the traffic which is received with exp=5 to be in FC
EF.

Apply Network QoS Policy with Queue Group Instances to the


Spoke SDP
To apply the QoS to the pseudowire, the following commands can be used, dependent on the
service type.
config# service {apipe|cpipe|epipe|fpipe|ipipe} <service-id>
spoke-sdp <sdp-id:vc-id>
ingress
qos <network-policy-id> fp-redirect-group <queue-group-name>
instance <instance-id>
egress
qos <network-policy-id> port-redirect-group <queue-group-name> instance <instanceid>

config# service {ies|vprn} <service-id>


interface <ip-int-name>
spoke-sdp <sdp-id:vc-id>
ingress
qos <network-policy-id> fp-redirect-group <queue-group-name> instance <instance-id>
egress
qos <network-policy-id> port-redirect-group <queue-group-name>
instance <instance-id>

config# service vpls <service-id>


{spoke-sdp|mesh-sdp} <sdp-id:vc-id>
ingress
qos <network-policy-id> fp-redirect-group <queue-group-name> instance <instance-id>
egress
qos <network-policy-id> port-redirect-group <queue-group-name>
instance <instance-id>

Advanced Configuration Guide

Page 1679

Configuration

For services using BGP auto-discovery to signal the pseudowire, the QoS configuration is
included in the pseudowire template.
config# service pw-template <policy-id>
ingress
qos <network-policy-id> fp-redirect-group <queue-group-name> instance <instance-id>
egress
qos <network-policy-id> port-redirect-group <queue-group-name>
instance <instance-id>

To propagate changes in a pw-template to existing BGP-AD pseudowires, it is necessary to use the


following command:
tools perform service eval-pw-template policy-id

Note that the allow-service-impact parameter is not required for changing the ingress or egress
QoS definition as these do not affect the operational state of the pseudowire.
QoS applied directly to a pseudowire, using the above commands, takes precedence over any QoS
applied to the network interface (using a network QoS policy with or without queue group
redirection).
Note that each time a pseudowire uses a network egress port queue group an FP resource is
allocated. This only requires that the pseudowire egress QoS is configured with a port-redirectgroup, and will occur even if there are no FCs redirected using a port-redirect-group within the
configured network QoS policy. The resources used can be seen using the tools dump systemresources command and is listed under Egr Network Queue Group Mappings which is part of the
total for the Dynamic Service Entries .
As an Epipe is used in this example, QoS is configured directly under a spoke SDP.
configure service
epipe 1 customer 1 create
spoke-sdp 1:1 vc-type vlan create
ingress
qos 10 fp-redirect-group "ingress-queue-group" instance 1
exit
egress
qos 10 port-redirect-group "egress-queue-group" instance 1
exit
no shutdown
exit
no shutdown
exit

The created network QoS policy is applied at both ingress and egress, with the ingress referencing
the ingress queue group instance applied to the FP and the egress referencing the egress queue
group instance applied to the port.

Page 1680

Advanced Configuration Guide

Pseudowire QoS

Show Output
The configured ingress queue group can be shown, including the details of the configured policers
and where it is applied.
*A:PE-1# show qos queue-group "ingress-queue-group" ingress detail
===============================================================================
QoS Queue-Group Ingress
===============================================================================
------------------------------------------------------------------------------QoS Queue Group
------------------------------------------------------------------------------Group-Name
: ingress-queue-group
Description
: (Not Specified)
------------------------------------------------------------------------------...
===============================================================================
Queue Group FP Maps
===============================================================================
Card Num
Fp Num
Instance
Type
------------------------------------------------------------------------------7
1
1
Network
------------------------------------------------------------------------------Entries found: 1
------------------------------------------------------------------------------===============================================================================
Queue Group Policer
===============================================================================
Policer Id
: 1
Description
: (Not Specified)
PIR Adptn
: closest
CIR Adptn
: closest
Parent
: none
Level
: 1
Weight
: 1
Adv. Cfg Plcy: none
Admin PIR
: 6000
Admin CIR
: 0
CBS
: def
MBS
: def
Hi Prio Only
: def
Pkt Offset
: 4
Profile Capped : Disabled
StatMode
: minimal
===============================================================================
Policer Id
: 2
Description
: (Not Specified)
PIR Adptn
: closest
CIR Adptn
: closest
Parent
: none
Level
: 1
Weight
: 1
Adv. Cfg Plcy: none
Admin PIR
: 4000
Admin CIR
: 0
CBS
: def
MBS
: def
Hi Prio Only
: def
Pkt Offset
: 4
Profile Capped : Disabled
StatMode
: minimal

Advanced Configuration Guide

Page 1681

Configuration

Similar information can be shown for the egress queue group, including the details of the
configured queue and policer and again where it is applied.
*A:PE-1# show qos queue-group "egress-queue-group" egress detail
===============================================================================
QoS Queue-Group Egress
===============================================================================
------------------------------------------------------------------------------QoS Queue Group
------------------------------------------------------------------------------Group-Name
: egress-queue-group
Description
: (Not Specified)
------------------------------------------------------------------------------Q CIR Admin PIR Admin CBS
HiPrio PIR Lvl/Wt
Parent
BurstLimit(B)
CIR Rule PIR Rule MBS
CIR Lvl/Wt
Wred-Queue
Slope
Named-Buffer Pool
Adv Config Policy Name
------------------------------------------------------------------------------1 0
6000
def
def
1/1
None
default
closest
closest
def
0/1
disabled
default
(not-assigned)
(not-assigned)
...
===============================================================================
Queue Group Ports (network)
===============================================================================
Port
Sched Pol
Policer-Ctrl-Pol Acctg Pol Stats Description QGrp-Instance
------------------------------------------------------------------------------7/1/2
No
1
------------------------------------------------------------------------------...
===============================================================================
Queue Group Policer
===============================================================================
Policer Id
: 1
Description
: (Not Specified)
PIR Adptn
: closest
CIR Adptn
: closest
Parent
: none
Level
: 1
Weight
: 1
Adv. Cfg Plcy: none
Admin PIR
: 4000
Admin CIR
: 0
CBS
: def
MBS
: def
Hi Prio Only
: def
Pkt Offset
: -22
Profile Capped : Disabled
StatMode
: minimal
...

Page 1682

Advanced Configuration Guide

Pseudowire QoS

The following command shows where the ingress queue group has been applied.
*A:PE-1# show qos queue-group ingress association
===============================================================================
QoS Queue-Group Ingress
===============================================================================
...
------------------------------------------------------------------------------QoS Queue Group
------------------------------------------------------------------------------Group-Name
: ingress-queue-group
Description
: (Not Specified)
...
===============================================================================
Queue Group FP Maps
===============================================================================
Card Num
Fp Num
Instance
Type
------------------------------------------------------------------------------7
1
1
Network
------------------------------------------------------------------------------Entries found: 1
------------------------------------------------------------------------------...
===============================================================================

A similar command shows where the egress queue group has been applied.
*A:PE-1# show qos queue-group egress association
===============================================================================
QoS Queue-Group Egress
===============================================================================
------------------------------------------------------------------------------QoS Queue Group
------------------------------------------------------------------------------Group-Name
: egress-queue-group
Description
: (Not Specified)
...
===============================================================================
Queue Group Ports (network)
===============================================================================
Port
Sched Pol
Policer-Ctrl-Pol Acctg Pol Stats Description QGrp-Instance
------------------------------------------------------------------------------7/1/2
No
1
------------------------------------------------------------------------------...
===============================================================================

Advanced Configuration Guide

Page 1683

Configuration

The ingress queue group applied to the FP on card 7 can be shown.


*A:PE-1# show card 7 fp 1 ingress queue-group "ingress-queue-group" instance 1
mode network
===============================================================================
Card:7 Net.QGrp: ingress-queue-group Instance: 1
===============================================================================
Group Name
: ingress-queue-group
Description
: (Not Specified)
Pol Ctl Pol
: None
Acct Pol
: None
Collect Stats : disabled

In order to show the details of the policers in the ingress FP queue group, the following command
can be used.
*A:PE-1# show qos policer card 7 fp 1 queue-group "ingress-queue-group" instance 1 network
detail
===============================================================================
Policer Info (Net-FPQG-1-ingress-queue-group:1->1), Slot 7
===============================================================================
Policer Name
: Net-FPQG-1-ingress-queue-group:1->1
Direction
: Ingress
Fwding Plane
: 1
Depth PIR
: 0 Bytes
Depth CIR
: 0 Bytes
Depth FIR
: 0 Bytes
MBS
: 7680 B
CBS
: 0 KB
Hi Prio Only
: 768 B
Pkt Byte Offset
: 4
Admin PIR
: 6000 Kbps
Admin CIR
: 0 Kbps
Oper PIR
: 6000 Kbps
Oper CIR
: 0 Kbps
Oper FIR
: 6000 Kbps
Stat Mode
: minimal
PIR Adaption
: closest
CIR Adaption
: closest
Adv.Cfg Plcy
: None
Profile Capped
: disabled
Parent Arbiter Name: (Not Specified)
------------------------------------------------------------------------------Arbiter Member Information
------------------------------------------------------------------------------Offered Rate
: 0 Kbps
Level
: 0
Weight
: 0
Parent PIR
: 0 Kbps
Parent FIR
: 0 Kbps
Consumed
: 0 Kbps
------------------------------------------------------------------------------===============================================================================
Policer Info (Net-FPQG-1-ingress-queue-group:1->2), Slot 7
===============================================================================
Policer Name
: Net-FPQG-1-ingress-queue-group:1->2
Direction
: Ingress
Fwding Plane
: 1
Depth PIR
: 0 Bytes
Depth CIR
: 0 Bytes
Depth FIR
: 0 Bytes
MBS
: 5 KB
CBS
: 0 KB
Hi Prio Only
: 512 B
Pkt Byte Offset
: 4
Admin PIR
: 4000 Kbps
Admin CIR
: 0 Kbps
Oper PIR
: 4000 Kbps
Oper CIR
: 0 Kbps
Oper FIR
: 4000 Kbps
Stat Mode
: minimal
PIR Adaption
: closest
CIR Adaption
: closest
Adv.Cfg Plcy
: None
Profile Capped
: disabled

Page 1684

Advanced Configuration Guide

Pseudowire QoS

Parent Arbiter Name: (Not Specified)


------------------------------------------------------------------------------Arbiter Member Information
------------------------------------------------------------------------------Offered Rate
: 0 Kbps
Level
: 0
Weight
: 0
Parent PIR
: 0 Kbps
Parent FIR
: 0 Kbps
Consumed
: 0 Kbps
------------------------------------------------------------------------------===============================================================================
Network Interface Association
------------------------------------------------------------------------------No Association Found.
------------------------------------------------------------------------------------------------------------------------------------------------------------SDP Association
------------------------------------------------------------------------------Policer Info (1->1:1->10), Slot 7
------------------------------------------------------------------------------SDP Association Count : 1
-------------------------------------------------------------------------------

The details of the queue and policer in the egress queue group applied to port 7/1/2 can also be
shown.
*A:PE-1# show port 7/1/2 queue-group egress "egress-queue-group" network instance 1
===============================================================================
Ethernet port 7/1/2 Network Egress queue-group
===============================================================================
Group Name
: egress-queue-group Instance-Id
: 1
Description
: (Not Specified)
Sched Policy : None
Acct Pol
: None
Collect Stats : disabled
Agg. Limit
: -1
Queues
------------------------------------------------------------------------------Queue-Group
: egress-queue-group Instance-Id
: 1
Queue-Id
: 1
Description
: (Not Specified)
Admin PIR
: 6000*
Admin CIR
: 0*
PIR Rule
: closest*
CIR Rule
: closest*
CBS
: def*
MBS
: def*
Hi Prio
: def*
Policers
------------------------------------------------------------------------------Queue-Group
: egress-queue-group Instance-Id
: 1
Policer-Id
: 1
Description
: (Not Specified)
Admin PIR
: 4000*
Admin CIR
: 0*
PIR Rule
: closest*
CIR Rule
: closest*
CBS
: def*
MBS
: def*
Hi Prio
: def*
* means the value is inherited

Advanced Configuration Guide

Page 1685

Configuration

The network QoS policy can be shown with the details of the configured FC redirection and
ingress classification used on the pseudowire.
*A:PE-1# show qos network 10 detail
===============================================================================
QoS Network Policy
===============================================================================
------------------------------------------------------------------------------Network Policy (10)
------------------------------------------------------------------------------Policy-id
: 10
Remark
: False
Forward Class
: be
Profile
: Out
LER Use DSCP
: False
Description
: (Not Specified)
...
------------------------------------------------------------------------------LSP EXP Bit Map
Forwarding Class
Profile
------------------------------------------------------------------------------5
ef
In
...
------------------------------------------------------------------------------Egress Forwarding Class Mapping
------------------------------------------------------------------------------FC Value
: 0
FC Name
: be
- DSCP Mapping
Out-of-Profile
: be
In-Profile
: be
...
DE Mark
: None
Redirect Grp Q
: 1
Redirect Grp Plcr: None
...
FC Value
...
DE Mark
Redirect Grp Q

: 5
:
:

FC Name
None
None

: ef

Redirect Grp Plcr:

------------------------------------------------------------------------------Ingress Forwarding Class Mapping


------------------------------------------------------------------------------FC Value
: 0
FC Name
: be
Redirect UniCast Plcr
: 1
Redirect MultiCast Plcr : None
...
FC Value
Redirect UniCast Plcr
...

Page 1686

: 5
: 2

FC Name
: ef
Redirect MultiCast Plcr : None

Advanced Configuration Guide

Pseudowire QoS

The details of the configuration of the pseudowire QoS can be seen when showing the details of
the SDP within the Epipe service.
*A:PE-1# show service id 1 sdp 1:1 detail
===============================================================================
Service Destination Point (Sdp Id : 1:1) Details
===============================================================================
------------------------------------------------------------------------------Sdp Id 1:1 -(192.0.2.2)
------------------------------------------------------------------------------Description
: (Not Specified)
SDP Id
: 1:1
Type
: Spoke
Spoke Descr
: (Not Specified)
VC Type
: VLAN
VC Tag
: 0
Admin Path MTU
: 0
Oper Path MTU
: 9190
Delivery
: MPLS
Far End
: 192.0.2.2
Tunnel Far End
: 192.0.2.2
LSP Types
: LDP
Hash Label
: Disabled
Hash Lbl Sig Cap : Disabled
Oper Hash Label
: Disabled
Admin State
...
Ingress Qos Policy
Ingress FP QGrp
Ing FP QGrp Inst

: Up

Oper State

: Up

: 10
: ingress-queue-group
: 1

Egress Qos Policy : 10


Egress Port QGrp : egress-queue*
Egr Port QGrp Inst: 1

The usage of the Egr Network Queue Group Mappings out of the total number of Dynamic
Service Entries can be seen with the following command. Only one egress QoS pseudowire
redirection has been configured.
*A:PE-1# tools dump system-resources
Resource Manager info at 005 m 07/31/13 13:11:03.355:
Hardware Resource Usage for Slot #7, CardType imm5-10gb-xfp, Cmplx #0:
|
Total
| Allocated |
Free
-------------------------------+-----------+-----------+-----------...
Dynamic Service Entries |
65535|
1|
65534
Subscriber Hosts |
|
0|
Encap Group Members |
|
0|
Egr Network Queue Group Mappings |
|
1|

It is possible to show the statistics on the ingress FP queue group used by the pseudowire.
*A:PE-1# show card 7 fp 1 ingress queue-group "ingress-queue-group" instance 1 mode network statistics
===============================================================================
Card:7 Net.QGrp: ingress-queue-group Instance: 1
===============================================================================
Group Name
: ingress-queue-group
Description
: (Not Specified)
Pol Ctl Pol
: None
Acct Pol
: None

Advanced Configuration Guide

Page 1687

Configuration

Collect Stats : disabled


------------------------------------------------------------------------------Statistics
------------------------------------------------------------------------------Packets
Octets
Ing.
Off.
Dro.
For.

Policer:
All
All
All

Grp: ingress-queue-group (Stats mode: minimal)


:
184275
23587200
:
36801
4710528
:
147474
18876672

Ing.
Off.
Dro.
For.

Policer:
All
All
All

Grp: ingress-queue-group (Stats mode: minimal)


:
184274
23587072
:
85955
11002240
:
98319
12584832

Similar statistics can be shown for the egress port queue group used by the pseudowire.
*A:PE-1# show port 7/1/2 queue-group egress "egress-queue-group" network statistics
instance 1
------------------------------------------------------------------------------Ethernet port 7/1/2 Network Egress queue-group
------------------------------------------------------------------------------Packets
Octets
Egress Queue: 1
Group: egress-queue-group
Instance-Id: 1
In Profile forwarded : 0
0
In Profile dropped
: 0
0
Out Profile forwarded : 150989
19326592
Out Profile dropped
: 37123
4751744
Egress Policer: 1 Group: egress-queue-group
Stats mode: minimal
Off. All
: 188421
Dro. All
: 87894
For. All
: 100527

Instance-Id: 1
24117888
11250432
12867456

Monitor commands are available to see the statistics (and rates on egress port queue group). As an
example, the following shows the utilization on the queue and policer in the egress queue-group.
*A:PE-1# monitor port 7/1/2 queue-group "egress-queue-group" instance 1 egress network
egress-queue 1 repeat 1 rate
===============================================================================
Monitor Port Queue-Group Egress Network Queue Statistics
===============================================================================
------------------------------------------------------------------------------At time t = 0 sec (Base Statistics)
------------------------------------------------------------------------------Packets
Octets
In Profile forwarded : 0
0
In Profile dropped
: 0
0
Out Profile forwarded : 299113
38286464
Out Profile dropped
: 74155
9491840
------------------------------------------------------------------------------At time t = 11 sec (Mode: Rate)
-------------------------------------------------------------------------------

Page 1688

Advanced Configuration Guide

Pseudowire QoS

Packets/sec

Octets/sec

% Port
Util.

In Profile forwarded : 0
0
0.00
In Profile dropped
: 0
0
0.00
Out Profile forwarded : 5863
750436
0.06
Out Profile dropped
: 1466
187609
0.01
===============================================================================

*A:PE-1# monitor port 7/1/2 queue-group "egress-queue-group" instance 1 egress network


policer 1 repeat 1 rate
===============================================================================
Monitor Port Queue-Group Egress Network Policer Statistics
===============================================================================
------------------------------------------------------------------------------At time t = 0 sec (Base Statistics)
------------------------------------------------------------------------------Packets
Octets
Off. All
Dro. All
For. All

: 454750
: 212181
: 242569

58208000
27159168
31048832

------------------------------------------------------------------------------At time t = 11 sec (Mode: Rate)


------------------------------------------------------------------------------Packets/sec
Octets/sec
% Port
Util.
Off. All
: 7326
937716
0.07
Dro. All
: 3419
437609
0.03
For. All
: 3907
500108
0.04
===============================================================================
*A:PE-1#

As mentioned, the egress policer (FC EF) traffic exits the egress port by default using the related
network queue on the port. This can be seen below.
*A:PE-1# show port 7/1/2 detail
===============================================================================
Ethernet Interface
===============================================================================
Description
: 10-Gig Ethernet
Interface
: 7/1/2
Oper Speed
: 10 Gbps
Link-level
: Ethernet
Config Speed
: N/A
Admin State
: up
Oper Duplex
: full
Oper State
: up
Config Duplex
: N/A
...
===============================================================================
Queue Statistics
===============================================================================
------------------------------------------------------------------------------...
Egress Queue 6
Packets
Octets
In Profile forwarded :
0
0
In Profile dropped
:
0
0

Advanced Configuration Guide

Page 1689

Configuration

Out Profile forwarded :


Out Profile dropped
:

102381
0

15357150
0

The throughput achieved using the above configuration can be verified in the traffic generator
output. Port 202/1 is connected to PE-1 and port 204/1 is connected to PE-2.

Page 1690

Advanced Configuration Guide

Pseudowire QoS

Conclusion
This example has shown the configuration and monitoring of pseudowire QoS, providing a
powerful QoS solution for pseudowire applications. QoS can be applied independently to the
ingress and/or egress of a single pseudowire or multiple pseudowires.

Advanced Configuration Guide

Page 1691

Conclusion

Page 1692

Advanced Configuration Guide

QoS Architecture and Basic


Operation

In This Chapter
This section provides information about QoS architecture and basic operation.
Topics in this section include:

Applicability on page 1694

Overview on page 1695

Configuration on page 1696

Conclusion on page 1735

Advanced Configuration Guide

Page 1693

Applicability

Applicability
The information in this section is applicable to all of the Alcatel-Lucent 7x50 platforms and is
focused on the FP2 chipset, which is used in the IOM3-XP/IMM and in the 7750 SR-c12/4. The
configuration was tested on release 9.0R3.

Page 1694

Advanced Configuration Guide

QoS Architecture and Basic Operation

Overview
The 7x50 platforms provide an extensive Quality of Service (QoS) capability for service provider
solutions. QoS is a system behavior to treat different traffic with different amounts of resources,
including buffer memory and queue serving time.
By allocating system resources with certain degrees of guarantee, the bandwidth can be used more
efficiently and more controllably. Lack of buffer memory leads to packet drop, while a smaller
amount of queue serving time normally means longer delay for the packet and may cause buffer
memory to be completely consumed and eventually also lead to packet drop.
In a single box system, such as the 7x50 platforms, different types of traffic contend for the same
resources at several major points, such as the ingress to the switch fabric and the egress out of a
physical port. In a multi-node network, QoS is achieved on hop by hop basis. Thus, QoS needs to
be configured individually but with the consistency across the whole network.
This note is focused on the configuration of the basic QoS, namely the use of queues to shape
traffic at the ingress and egress of the system. More sophisticated aspects will be referenced where
appropriate but their details are beyond the scope of this note. Other topics not included are
Hierarchical QoS scheduling, egress port-scheduler, queue-groups, named buffer pools, WREDper-queue, LAGs, high scale MDA, QoS for ATM/FR and Enhanced Subscriber Management.

QoS Components
QoS consists of four main components:

Classification

Buffering (enqueuing)

Scheduling (dequeuing)

Remarking

These are also the fundamental building blocks of the QoS implementation in the 7x50. Ingress
packets, classified by various rules, belong to one of eight Forwarding Classes (FC). A FC can be
viewed a set of packets which are treated in a similar manner within the system (have the same
priority level and scheduling behavior). Each FC has a queue associated with it and each queue
has a set of parameters controlling how buffer memory is allocated for packets; if a packet is
enqueued (placed on the queue) a scheduler will control the way the packet gets dequeued
(removed from the queue) relative to other queues. When a packet exits an egress port, a
remarking action can be taken to guarantee the next downstream device will properly handle the
different types of traffic.

Advanced Configuration Guide

Page 1695

Configuration

Configuration
Policies
QoS policies are used to control how traffic is handled at distinct points in the service delivery
model within the device. There are different types of QoS policies catering to the different QoS
needs at each point. QoS policies only take effect when applied to a relevant entity (Service
Access Point (SAP) or network port/interface) so by default can be seen as templates with each
application instantiating a new set of related resources.
The following QoS policies are discussed:

Ingress/egress QoS Policies For classification, queue attributes and remarking.

Slope policies Define the RED slope definitions.

Scheduler policies Determine how queues are scheduled (only the default scheduling is
included here).

Access Network and Hybrid Ports


The system has two different types of interfaces: access and network.

A network interface will classify packets received from the network core at ingress and
remark packets sent to the core at egress. Aggregated differentiated service QoS is
performed on network ports, aggregating traffic from multiple services into a set of
queues per FC.

An access interface connects to one or more customer devices; it receives customer


packets, classifies them into different FCs at ingress and remarks packets according to
FCs at egress. Since an access interface needs application awareness, it has many more
rules to classify the ingress packets. Access and network also differ in how buffer memory
is handled, as will be made clear when discussing the buffer management. Here the QoS is
performed per SAP.

Access interfaces (SAPs) are configured on access ports and network interfaces are configured on
network ports. A third type of port is available, the hybrid port, which supports both access and
network interfaces on the same port.
Hybrid ports are only supported on Ethernet ports and optionally with a single-chassis LAG. They
must be configured to use VLANs (either single (dot1q encapsulation) or double (QinQ
encapsulation) tagging) with each VLAN mapping to either the access or network part of the port.
This allows the classification to associated incoming traffic with the correct port type and service.

Page 1696

Advanced Configuration Guide

QoS Architecture and Basic Operation

Note that port based traffic, such as LACP, CCM and EFM, uses a system queue on an access port
but the default network queues on a hybrid port.
Customer traffic follows the path shown below:
[service ingress network egress] [network ingress network egress] [network ingress service egress]
ingress PE
transit P
egress PE

The network administrator needs to make sure that QoS is configured correctly at each point using
the appropriate QoS policies (Figure 166).

SAP

Service QoS Policies

SAP

Customer Satisfaction
Define and Secure Customer SLA

Service
Ingress

Network
Egress

Core Network

Network
Ingress

Service
Egress

Profitable Business
Optimize Network Resources

PE

Network QoS Policies

PE
OSSG398

Figure 166: Service and Network QoS Policies

Advanced Configuration Guide

Page 1697

Configuration

Service Ingress QoS Policy


The SAP ingress policies are created under the qos node of the CLI and require a unique identifier
(from 1 to 65535). The default sap-ingress policy has identifier 1.

Classification
Services can be delineated at the SAP ingress by

A physical port (null encapsulated) or

An encapsulation on the physical port, for example a VLAN ID on an Ethernet port or a


DLCI on a Frame Relay port.

The following configuration is an example of an IES service created with an IP interface on


VLAN 2 of port 3/2/10 (IOM 3, MDA 2, port 10) and has SAP ingress QoS policy 10 applied.
configure service
ies 1 customer 1 create
interface "int-access" create
address 192.168.1.1/30
sap 3/2/10:2 create
ingress
qos 10
exit
exit
exit
no shutdown
exit

As traffic enters the port, the service can be identified by the VLAN tag (and unwanted packets
dropped). The ingress service QoS policy applied to the SAP maps traffic to FCs, and thus to
queues, and sets the enqueuing priority. Mapping flows to FCs is controlled by comparing each
packet to the match criteria in the QoS policy. The match criteria that can be used in ingress QoS
policies can be combinations of those listed in Table 22. Note that when a packet matches two
criteria (802.1p priority and DSCP) it is the lowest precedence value that is used to map the packet
to the FC.

Page 1698

Advanced Configuration Guide

QoS Architecture and Basic Operation

Table 22: SAP Ingress Classification Match Criteria


Match
Precedence
1

2
3
4
5
6

Match Criteria

MAC fields match criteria:


Frame type [802dot3|802dot2llc|802dot2-snap|ethernetII|atm]
ATM VCI value
IEEE 802.1p value/mask
Source MAC address/mask
Destination MAC address/mask
EtherType value
IEEE 802.2 LLC SSAP value/
mask
IEEE 802.2 LLC DSAP value/
mask
IEEE 802.3 LLC SNAP OUI
zero or non-zero value
IEEE 802.3 LLC SNAP PID
value
Note: For an ingress QoS policy, either IP match criteria or MAC match criteria can be defined,
not both.
DSCP
IP precedence
LSP EXP
IEEE 802.1p priority and/or Drop Eligibility Indicator (DEI)
Default forwarding class for non-matching traffic
IPv4 fields match criteria:
Destination IP address/
prefix
Destination port/range
DSCP value
IP fragment
Protocol type (TCP, UDP,
etc.)
Source port/range
Source IP address/prefix

IPv6 fields match criteria:


Destination IP address/
prefix
Destination port/range
DSCP value
Next header
Source port/range
Source IP address/prefix

It is possible to match MAC criteria on VPLS/Epipe SAPs and IP criteria on IP interface SAPs.
However, it is also possible to classify on MAC criteria on an IP interface SAP and conversely to
classify on IP criteria on VPLS/Epipe SAPs. When MPLS labeled traffic is received on a VPLS/
Epipe SAP, it is possible to match on either of the LSP EXP bits (outer label) or the MAC criteria.
A SAP can be configured to have no VLAN tag (null encapsulated), one VLAN tag (dot1q
encapsulated) or two VLAN tags (QinQ encapsulated). The configuration allows the selection of
which VLAN tag to match against for the 802.1p bits, using the keyword match-qinq-dot1p with
the keyword top or bottom.
The following example configuration shows match QinQ traffic with dot1p value 1 in the top
VLAN tag entering the QinQ SAP in Epipe service 1 and assign it to FC af using queue 2.

Advanced Configuration Guide

Page 1699

Configuration

configure qos
sap-ingress 10 create
queue 2 create
exit
fc "af" create
queue 2
exit
dot1p 1 fc "af"
exit
exit
configure service
epipe 1 customer 1 create
sap 1/1/1:100.1 create
ingress
qos 10
match-qinq-dot1p top
exit
exit
no shutdown
exit

Page 1700

Advanced Configuration Guide

QoS Architecture and Basic Operation

The classification of traffic using the default, top and bottom keyword parameters is summarized
in Table 23. Note that a TopQ SAP is a QinQ SAP where only the outer (top) VLAN tag is
explicitly specified (sap 1/1/1:10.* or sap 1/1/1:10.0).

Table 23: QinQ Dot1p Bit Classification


Port/SAP Type

Existing Packet Tags

Pbits Used for Match


Default

Match Top

Match Bottom

Null

None

None

None

None

Null

Dot1P (VLAN-ID 0)

Dot1P PBits

Dot1P PBits

Dot1P PBits

Null

Dot1Q

Dot1Q PBits

Dot1Q PBits

Dot1Q PBits

Null

TopQ BottomQ

TopQ PBits

TopQ PBits

BottomQ PBits

Null

TopQ (No BottomQ)

TopQ PBits

TopQ PBits

TopQ PBits

Dot1Q

None (Default SAP)

None

None

None

Dot1Q

Dot1P (Default SAP


VLAN-ID 0)

Dot1P PBits

Dot1P PBits

Dot1P PBits

Dot1Q

Dot1Q

Dot1Q PBits

Dot1Q PBits

Dot1Q PBits

QinQ/TopQ

TopQ

TopQ PBits

TopQ PBits

TopQ PBits

QinQ/TopQ

TopQ BottomQ

TopQ PBits

TopQ PBits

BottomQ PBits

QinQ/QinQ

TopQ BottomQ

BottomQ PBits

TopQ PBits

BottomQ Pbits

The Drop Eligibility Indicator (DEI)1 bit can be used to indicate the in/out profile state of the
packet, this will be covered later in the discussion on profile mode.
Note that ingress traffic with a local destination (for example, OSPF hellos) is classified by the
system automatically and uses a set of dedicated system queues.

1. IEEE 802.1ad-2005 and IEEE 802.1ah (PBB)

Advanced Configuration Guide

Page 1701

Configuration

After the traffic has been classified, the next step is to assign it to a given FC. There are 8 predefined FCs within the system which are shown in Table 24 (note that the FC identifiers are
keywords and do not have a fixed relationship with the associated Differentiated Services Code
Points (DSCP)).

Table 24: Forwarding classes


FC
Identifier

FC Name

Default Scheduling
Priority

NC

Network Control

Expedited

H1

High-1

Expedited

EF

Expedited

Expedited

H2

High-2

Expedited

L1

Low-1

Best Effort

AF

Assured

Best Effort

L2

Low-2

Best Effort

BE

Best Effort

Best Effort

When a FC is configured for a classification, it must first be created in the configuration. One of
the FCs can be also configured to be the default in case there is no explicit classification match
and by default this FC is be.
Normally, once traffic is assigned to a FC at the ingress it remains in that FC throughout its time
within the system. Re-classification of IP traffic at a SAP egress is possible, but is beyond the
scope of this note.
Packets also have a state of being in-profile or out-of-profile which represents their drop
precedence within the system, therefore there can be up to 8 distinct per hop behavior (PHB)
classes with two drop precedences.

Page 1702

Advanced Configuration Guide

QoS Architecture and Basic Operation

Buffering (Enqueuing)
Once a packet is assigned to a certain forwarding class, it will try to get a buffer in order to be
enqueued. Whether the packet can get a buffer is determined by the instantaneous buffer
utilization and several attributes of the queue (such as Maximum Burst Size (MBS), Committed
Burst Size (CBS) and high-prio-only) that will be discussed in more detail later in this chapter. If a
packet cannot get a buffer for whatever reason, the packet will get dropped immediately.
As traffic is classified at the SAP ingress it is also assigned an enqueuing priority, which can be
high or low. This governs the likelihood of a packet being accepted into a buffer and so onto a
queue, and is managed using the queues high-priority-only parameter and the buffer pools
weighted random early detection (WRED) slope policies. Traffic having a high enqueuing priority
has more chance of getting a buffer than traffic with low enqueuing priority. The enqueuing
priority is specified with the classification using the parameter priority, and a default enqueuing
priority can be configured, its default being low.
Enqueuing priority is a property of a packet and should not to be confused with scheduling
priority, expedited or best-effort, which is a property of a queue.
The following configuration shows an example with all packets with dot1p value 3 are classified
as ef and have their enqueuing priority set to high, all other packets are classified as af with a low
enqueuing priority.
configure qos
sap-ingress 10 create
fc "af" create
exit
fc "ef" create
exit
dot1p 3 fc "ef" priority high
default-fc "af"
default-priority low # this is the default
exit

Each forwarding class is associated with at most one unicast queue. In the case of a VPLS service,
each FC can also be assigned a single multipoint queue at ingress, or for more granular control,
separate queues for broadcast, multicast and unknown traffic. Since each queue maintains
forward/drop statistics, it allows the network operator to easily track unicast, broadcast, multicast
and unknown traffic load per forwarding class. Separate multicast queues can also be assigned for
IES/VPRN services which have IP multicast enabled.
This results in an Epipe SAP having up to 8 ingress queues, an IES/VPRN SAP having up to 16
ingress queues and a VPLS SAP having up to 32 ingress queues. Each queue has a locally
significant (to the policy) identifier, which can be from 1 to 32.
The default SAP ingress QoS policy (id=1) has two queues; queue 1 for unicast traffic and queue
11 for multipoint traffic, and is assigned to every ingress SAP at service creation time. Equally,
when a new (non-default) SAP ingress policy is created, queue 1 and queue 11 are automatically
created with the default FC (BE) assigned to both. Additional queues must be created before being

Advanced Configuration Guide

Page 1703

Configuration

assigned to a FC, with multipoint queues requiring the multipoint keyword. When a SAP ingress
policy is applied to a SAP, physical hardware queues on the IOM are allocated for each queue with
a FC assigned (if no QoS policy is explicitly configured, the default policy is applied). Multipoint
queues within the SAP ingress policy are ignored when applied to an Epipe SAP or an IES/VPRN
SAP which is not configured for IP multicast.
The mechanism described here uses a separate set of queues per SAP. For cases where per-SAP
queuing is not required it is possible to use port based queues, known as queue-groups, which
reduces the number of queues required.

Scheduling (Dequeuing)
A queue has a priority which effects the relative scheduling of packets from it compared to other
queues. There are two queue priorities: expedite and best-effort, with expedited being the higher.
When creating a queue, one of these priorities can be configured thereby explicitly setting the
queues priority. Alternatively the default is auto-expedite in which case the queues priority is
governed by the FCs assigned to it, as shown in Table 24. If there is a mix of expedited and besteffort FCs assigned, the queue is deemed to be best-effort.
The following configuration displays an example that ensures that EF traffic is treated as
expedited by assigning it to new unicast and multicast queues.
configure qos
sap-ingress 10 create
queue 3 expedite create
exit
queue 13 multipoint expedite create
exit
fc ef create
queue 3
multicast-queue 13
exit
default-fc "ef"
exit

Once a packet gets a buffer and is queued, it will wait to be served and sent through the switch
fabric to its destination port by the hardware scheduler. There are two scheduler priorities:
expedited or best-effort, corresponding to the queues priority. The expedited hardware schedulers
are used to enforce priority access to internal switch fabric destinations with expedited queues
normally having a higher preference than best-effort queues. Queues of the same priority get
equally serviced in round robin fashion by the associated scheduler.
When a queue gets its turn to be serviced, the scheduler will use the operational Peak Information
Rate (PIR) and Committed Information Rate (CIR) attributes of the queue to determine what to do
with the packet.

Page 1704

The scheduler does not allow queues to exceed their configured PIR. If the packet arrival
rate for a given queue is higher than the rate at which it is drained, the queue will fill. If

Advanced Configuration Guide

QoS Architecture and Basic Operation

the queue size (in Kbytes) reaches its defined MBS all subsequent packets will be
discarded, this is known as tail drop.

If the dequeue rate is below the operational CIR, the packet will be forwarded and marked
as in-profile.

If the dequeue rate is below the operational PIR but higher than the CIR, the packet will
be forwarded but marked as out-of-profile.

Out-of-profile packets have a higher probability of being dropped when there is congestion
somewhere in the downstream path. Packets that are marked with out-of-profile will also be
treated differently at the network egress and service egress.
These marking actions are known as color marking (green for in-profile and yellow for out-ofprofile). Using the default queue setting of priority-mode, as described above, the in/out-ofprofile state of a packet is determined from the queue scheduling state (within CIR or above CIR,
as described later) at the time that the packet is dequeued. An alternative queue mode is profilemode.

Profile Mode
A queue is created with profile mode when the aim is that the in/out-of-profile state of packets is
determined by the QoS bits of the incoming packets, this is known as color-aware (as opposed to
color-unaware for priority mode).
As part of the classification, the profile state of the packets is explicitly configured. To provide
granular control, it is possible to configure FC sub-classes with each having a different profile
state, while inheriting the other parameters from their parent FC (for example the queue, in order
to avoid out of order packets). The FC subclasses are named fc.sub-class, where sub-class is a text
string up to 29 characters (though normally the words in and out are used for clarity). Any traffic
classified without an explicit profile state is treated as if the queue were in priority mode.
When using the profile mode, the DEI in the Ethernet header can be used to classify a packet as inprofile (DEI=0) or out-of-profile (DEI=1).
The following configuration shows traffic with dot1p 3 is set to in-profile, dotp1p 2 to out-ofprofile and the profile state of dot1p 0 depends on the scheduling state of the queue.
configure qos
sap-ingress 20 create
queue 2 profile-mode create
exit
fc "af" create
queue 2
exit
fc "af.in" create
profile in
exit
fc "af.out" create

Advanced Configuration Guide

Page 1705

Configuration

profile out
exit
dot1p 0 fc "af"
dot1p 2 fc "af.out"
dot1p 3 fc "af.in"
exit

The difference between a queue configured in priority (default) and profile mode is summarized in
Table 25 (within/above CIR is described later).

Table 25: Queue Priority vs. Profile Mode


Priority Mode

Profile Mode

Packet In-Profile/
Out-of-Profile state

Determined by state of the queue at


scheduling time.
Within CIR In Profile
Above CIR Out Profile

Explicitly stated in FC or subclass


classification.
If not, then defaults tostate of the queue at
scheduling time

Packet High/Low
Enqueuing Priority

Explicitly stated in FC classification. If


not then defaults to Low priority

Always follows state of in-profile/out-ofprofile determined above


In-profile = High Priority
Out-Profile = Low Priority
If not set = High Priority

Page 1706

Advanced Configuration Guide

QoS Architecture and Basic Operation

Remarking
Remarking at the service ingress is possible when using an IES or VPRN service. The DSCP/
precedence field can be remarked for in-profile (in-remark) and out-of-profile (out-remark)
traffic as defined above for queues in either priority mode or profile mode. If configured for other
services, the remarking is ignored. If remarking is performed at the service ingress, then the traffic
is not subject to any egress remarking on the same system.
The following configuration displays an example classifying traffic to 10.0.0.0/8 as FC ef inprofile and remark its DSCP to ef.
configure qos
sap-ingress 300 create
queue 2 profile-mode create
exit
fc ef" create
queue 2
profile in
in-remark dscp ef
exit
ip-criteria
entry 10 create
match
dst-ip 10.0.0.0/8
exit
action fc ef"
exit
exit
exit

Advanced Configuration Guide

Page 1707

Configuration

Service Egress QoS Policy


The service egress uses a SAP egress QoS policy to define how FCs map to queues and how a
packet of a given FC is remarked. SAP egress policies are created in the CLI qos context and
require a unique identifier (from 1 to 65535). The default SAP egress policy has identifier 1.
Once a service packet is delivered to the egress SAP, it has following attributes:

Forwarding class, determined from classification at the ingress of the node.

High/low enqueuing priority, which corresponds directly to the in/out-of-profile state


from the service ingress or network ingress.

Similar to the service ingress enqueuing process, it is possible that a packet can not get a buffer
and thus gets dropped. Once on an egress queue, a packet is scheduled from the queue based on
priority of the queue (expedited or best-effort) and the scheduling state with respect to the CIR/
PIR rates (note that the profile state of the packet [in/out] is not modified here). Egress queues do
not have a priority/profile mode and have no concept of multipoint.
Only one queue exists in the default SAP egress QoS policy (id=1) and also when a new sapegress policy is created, this being queue 1 which is used for both unicast traffic and multipoint
traffic. All FCs are assigned to this queue unless otherwise explicitly configured to a different
configured queue. When a SAP egress policy is applied to a SAP, physical hardware queues on the
IOM are allocated for each queue with FC assigned (if no QoS policy is explicitly configured, the
default policy is applied).
As mentioned earlier, re-classification of IP traffic at a SAP egress is possible.
Traffic originated by the system (known as self generated traffic) has its FC and marking
configured under router/sgt-qos (for the base routing) or under service/vprn/sgt-qos (for a VPRN
service). This is beyond the scope of this note.

Page 1708

Advanced Configuration Guide

QoS Architecture and Basic Operation

Remarking
At the service egress, the dot1p/DEI can be remarked for any service per FC with separate
marking for in/out-of-profile if required. The DEI bit can also be forced to a specific value (using
the de-mark force command). When no dot1p/de-mark is configured, the ingress dot1p/DEI is
preserved; if the ingress was un-tagged the dot1p/DEI bit is set to 0.
The following configuration shows a remark example with different FCs with different dot1p
values. FC af also differentiates between in/out-of-profile and then remarks the DEI bit
accordingly based on the packets profile.
configure qos
sap-egress 10 create
queue 1 create
rate 20000
exit
queue 2 create
rate 10000 cir 5000
exit
queue 3 create
rate 2000 cir 2000
exit
fc af create
queue 2
dot1p in-profile 3 out-profile 2
de-mark
exit
fc be create
queue 1
dot1p 0
exit
fc ef create
queue 3
dot1p 5
exit
exit

If QinQ encapsulation is used, the default is to remark both tags in the same way. However it is
also possible to remark only the top tag using the qinq-mark-top-only parameter configured
under the SAP egress.
The following configuration shows a remark example with only the dot1p/DEI bits in top tag of a
QinQ SAP.
configure service
vpls 2 customer 1 create
sap 1/1/11:2.2 create
egress
qos 20
qinq-mark-top-only
exit
exit
exit

Advanced Configuration Guide

Page 1709

Configuration

For IES and VPRN services, the DSCP/precedence field can be remarked in the same way as at
the service ingress, namely based on the in/out-of-profile state of the packets (and only if no
ingress remarking was performed).
The following configuration shows DSCP values for FC af based on in/out-of-profile traffic.
configured qos
sap-egress 20 create
queue 2 create
fc af create
queue 2
dscp in-profile af41 out-profile 43
exit
exit

Page 1710

Advanced Configuration Guide

QoS Architecture and Basic Operation

Network Ports
The QoS policies relating to the network ports are divided into a network and a network-queue
policy. The network policy covers the ingress classification into FCs and the egress remarking
based on FCs, while the network-queue policy covers the queues/parameters and the FC to queue
mapping. The logic behind this is that there is only one set of queues provisioned on a network
port, whereas the use of these queues is configured per network IP interface. This in turn
determines where the two policies can be applied. Note that network ports are used for IP routing
and switching, and for GRE/MPLS tunneling.

Network QoS Policy


The network QoS policy has an ingress section and an egress section. It is created under the qos
node of the CLI and requires a unique identifier (from 1 to 65535). The default network policy has
identifier 1. Network QoS policies are applied to IP interfaces configured on a network port.
The following configuration show an example to apply different network QoS policies to two
network interfaces.
configure router
interface "int-network-1"
address 192.168.0.1/30
port 1/1/11:1
qos 28
exit
interface "int-network-2"
address 192.168.0.5/30
port 1/1/12
qos 18
exit
exit

Classification
The ingress section defines the classification rules for IP/MPLS packets received on a network IP
interface. The rules for classifying traffic are based on the incoming QoS bits (Dot1p, DSCP, EXP
[MPLS experimental bits]). The order in which classification occurs relative to these fields is:
1. EXP (for MPLS packets) or DSCP (for IP packets)
Dot1p/DEI bit 2
2. default action (default= fc be profile out)

2. Note that network ports do not support QinQ encapsulation.

Advanced Configuration Guide

Page 1711

Configuration

The configuration specifies the QoS bits to match against the incoming traffic together with the
FC and profile (in/out) to be used (it is analogous to the SAP profile-mode in that the profile of the
traffic is determined from the incoming traffic, rather than the CIR configured on the queue). A
default-action keyword configures a default FC and profile state.
For tunneled traffic (GRE or MPLS), the match is based on the outer encapsulation header unless
the keyword ler-use-dscp is configured. In this case, traffic received on the router terminating the
tunnel that is to be routed to the base router or a VPRN destination is classified based on the
encapsulated packet DSCP value (assuming it is an IP packet) rather than its EXP bits.
Note that Release 8.0 added the ability for an egress LER to signal an implicit-null label (numeric
value 3). This informs the previous hop to send MPLS packets without an outer label and so is
known as penultimate hop popping (PHP). This can result in MPLS traffic being received at the
termination of an LSP without any MPLS labels. In general, this would only be the case for IP
encapsulated traffic, in which case the egress LER would need to classify the incoming traffic
using IP criteria.

Remarking
The egress section of the network policy defines the remarking of the egress packets, there is no
remarking possible at the network ingress. The egress remarking is configured per FC and can set
the related dot1p/DEI (explicitly or dependant on in/out-of-profile), DSCP (dependent on in/outof-profile) and EXP (dependent on in/out-of-profile).
The traffic exiting a network port is either tunneled (in GRE or MPLS) or IP routed.
For tunneled traffic exiting a network port, the remarking3 applies to the DSCP/EXP bits in any
tunnel encapsulation headers (GRE/MPLS) pushed4 onto the packet by this system, together with
the associated dot1p/DEI bits if the traffic has an outer VLAN tag. Note that for MPLS tunnels,
the EXP bits in the entire label stack are remarked.
For VPLS/Epipe services there is no additional remarking possible. However, for IES/VPRN/
base-routing traffic the remarking capabilities at the network egress are different at the first
network egress (egress on the system on which the traffic entered by a SAP ingress) and
subsequent network egress in the network (egress on the systems on which the traffic entered
through another network interface).
At the first network egress, the DSCP of the routed/tunneled IP packet can be remarked but this is
dependent on two configuration settings:

3.
4.

Page 1712

Strictly speaking this is marking (as opposed to remarking) as the action is adding QoS information
rather than changing it.
A new outer encapsulation header is pushed onto traffic at each MPLS transit label switched router as
part of the label swap operation.

Advanced Configuration Guide

QoS Architecture and Basic Operation

The trusted state of the ingress (service/network) interface and

The remarking keyword in the network QoS policy at the network egress. The
configuration combinations are summarized in Table 26.

This is in addition to the remarking of any encapsulation headers and, as stated earlier, is not
performed if the traffic was remarked at the service ingress.
For traffic exiting a subsequent network egress in the network, only the IP routed traffic can be
remarked, again this is dependent on the ingress trusted state and egress remarking parameter.
There is one addition to the above to handle the marking for IP-VPN Option-B in order to remark
the EXP, DSCP and dot1p/DEI bits at a network egress, this being remarking force. Without this,
only the EXP and dot1p/DEI bits are remarked. Note that this does not apply to label switched
path traffic switched at a label switched router.
Table 26: Network QoS Policy DSCP Remarking
Ingress

IES

Network

VPRN

Trusted State

Remarking Configuration

Marking Performed

Untrusted
(default)

remarking

Yes

no remarking (default)

Yes

Trusted

remarking

Yes

no remarking (default)

No

remarking

Yes

no remarking (default)

Yes

Trusted
(default)

remarking

Yes

no remarking (default)

No

Untrusted

remarking

Yes

no remarking (default)

Yes

remarking

No

no remarking (default)

No

Untrusted

Trusted
(default)

The following configuration shows a ingress network classification for DSCP EF explicitly, with a
default action for the remainder of the traffic and use the DSCP from the encapsulated IP packet if
terminating a tunnel. Remark the DSCP values for FC af and ef and remark all traffic (except
incoming VPRN traffic) at the egress. Apply this policy to a network interface.

Advanced Configuration Guide

Page 1713

Configuration

configure qos
network 20 create
ingress
default-action fc af profile out
ler-use-dscp
dscp ef fc ef profile in
exit
egress
remarking
fc af
no dscp-in-profile
dscp-out-profile af13
lsp-exp-in-profile 6
lsp-exp-out-profile 5
exit
fc ef
dscp-in-profile af41
exit
exit
exit
exit
configure router
interface "int-network-3"
address 192.168.0.9/30
port 1/1/3
qos 20
exit

The following configuration shows the trusted IES interface.


configure service
ies 1 customer 1 create
interface "int-access" create
address 192.168.1.1/30
tos-marking-state trusted
sap 1/1/10:1 create
exit
exit
no shutdown
exit

The network QoS egress section also contains the configuration for the use of port-based queues
by queue-groups which are out of scope of this note.

Page 1714

Advanced Configuration Guide

QoS Architecture and Basic Operation

Network Queue Policy


The network queue QoS policy defines the queues and their parameters together with the FC to
queue mapping. The policies are named, with the default policy having the name default and are
applied under config>card>mda>network>ingress for the network ingress queues and under
Ethernet: config>port>ethernet>network, POS: config>port>sonet-sdh>path>network,
TDM: config>port>tdm>e3 | ds3>network for the egress.
The following configuration shows an ingress and egress network-queue policy.
configure card 1
card-type iom3-xp
mda 1
mda-type m20-1gb-xp-sfp
network
ingress
queue-policy "network-queue-1"
exit
exit
exit
exit
configure port 1/1/11
ethernet
encap-type dot1q
network
queue-policy "network-queue-1"
exit
exit
no shutdown
exit

There can be up to 16 queues configured in a network-queue policy, each with a queue-type of


best-effort, expedite or auto-expedite. A new network-queue policy contains two queues, queue 1
for unicast traffic and queue 9 for multipoint traffic and by default all FCs are mapped to these
queues. Note that there is no differentiation for broadcast, multicast and unknown traffic. If the
policy is applied to the egress then any multipoint queues are ignored. As there are 8 FCs, there
would be up to 8 unicast queues and 8 multipoint queues, resulting in 16 ingress queues and 8
egress queues. Normally the network queue configuration is symmetric (the same queues/FCmapping at the ingress and egress).
The following configuration defines a network-queue policy with FC af and ef assigned to queues
2 and 3 for unicast traffic, and queue 9 for multipoint traffic.
configure qos
network-queue "network-queue-1" create
queue 1 create
mbs 50
high-prio-only 10
exit
queue 2 create
exit

Advanced Configuration Guide

Page 1715

Configuration

queue 3 create
exit
queue 9 multipoint create
mbs 50
high-prio-only 10
exit
fc af create
multicast-queue 9
queue 2
exit
fc ef create
multicast-queue 9
queue 3
exit
exit

Page 1716

Advanced Configuration Guide

QoS Architecture and Basic Operation

Summary of Network Policies


Figure 167 displays the default network policies with respect to classification, FC to queue
mapping and remarking.

Network Policy (Ingress)

Network Queue Policy

Network Policy (Egress)

EXP 7, nc2

In
NC
Out

In
NC
Out

Q8/Q16

NC

In
Out

EXP 7, nc2

EXP6, nc1

In
Out

H1

In
Out

H1

Q7/Q15

H1

In
Out

EXP6, nc1

EXP 5, ef

In
Out

EF

In
Out

EF

Q6/Q14

EF

In
Out

EXP 5, ef

EXP 4, af41
af42, af43

In
Out

H2

In
Out

H2

Q5/Q13

H2

In
Out

EXP 4, af41
EXP 4, af42

af21, af31
af22, af23, af32, af33

In
Out

L1

In
Out

L1

Q4/Q12

L1

In
Out

EXP 3, af21
EXP 2, af22

EXP 3, af11
EXP 2, af12, af13

In
Out

AF

In
Out

AF

Q3/Q11

AF

In
Out

EXP 3, af11
EXP 2, af12

EXP 1, cs1

In
Out

L2

In
Out

L2

Q2/Q10

L2

In
Out

EXP 1, cs1

Q1/Q9

BE

In
Out

EXP 0, be

EXP 0, be

In
BE
Out

In
BE
Out

OSSG399

Figure 167: Visualization of Default Network Policies

Advanced Configuration Guide

Page 1717

Configuration

Queue Management
The policies described so far define queues but not the characteristics of those queues which
determine how they behave. This section describes the detailed configuration associated with
these queues. There are two aspects:

Enqueuing packets onto a queue

buffer pools

queue sizing

Weight Random Early Detection (WRED)

Dequeuing packets from a queue

queue rates

scheduling

Enqueuing Packets: Buffer Pools


The packet buffer space is divided equally between ingress and egress. Beyond that, by default
there is one pool for network ingress per FP25/IOM, with one pool per access ingress port and one
pool per access/network egress port. This is shown in Figure 168. This segregation provides
isolation against buffer starvation between the separate pools. An additional ingress pool exists for
managed multicast traffic (the multicast path management pool) but this is beyond the scope of
this note.
The buffer management can be modified using named buffer pools and/or WRED-per-queue pools
which are out of scope of this note.

5.

Page 1718

The FP2 chipset is used in the IOM3-XP/IMM and in the 7750 SR-c 12/4.

Advanced Configuration Guide

QoS Architecture and Basic Operation

Ingress

Egress

Multicast Path
Management Pool
Port x/1/1

Access Pool

Port x/1/1

Access Pool

Port x/1/2

Access Pool

Port x/1/2

Access Pool

Port x/1/3

Network Pool

Port x/1/4

Network Pool

Port x/2/1

Port x/2/1

Network Pool

Port x/2/2

Port x/2/2

Network Pool

Port x/1/3
Port x/1/4
Network Pool
(Shared)
Queues Are Created
Within A Buffer Pool

Port x/2/3

Access Pool

Port x/2/3

Access Pool

Port x/2/4

Access Pool

Port x/2/4

Access Pool

IOM
Port x/1/1 (Access)
Port x/1/2 (Access)
Port x/1/3 (Network)
Port x/1/4(Network)

MDA 1

FP2
Port x/2/1 (Network)
Port x/2/2 (Network)
Port x/2/3 (Access)
Port x/2/4 (Access)

Fabric
Access

Switch
Fabric

MDA 2

OSSG400

Figure 168: Default Buffer Pools

The size of the pools is based on the MDA type and the speed/type (access or network) of each
port. Buffer space is allocated in proportion to the active bandwidth of each port, which is
dependant on:

The actual speed of the port

Bandwidth for configured channels only (on channelized cards)

Zero for ports without queues configured

This calculation can be tuned separately for ingress and egress, without modifying the actual port
speed, using the port/modify-buffer-allocation-rate. Note that changing the ports egress-rate will
also modify its buffer sizes.

Advanced Configuration Guide

Page 1719

Configuration

The following configuration changes the relative size for the ingress/egress buffer space on port 1/
1/10 to 50% of the default.
configure port 1/1/10
modify-buffer-allocation-rate
ing-percentage-of-rate 50
egr-percentage-of-rate 50
exit

Each of the buffer pools created is further divided into a section of reserved buffers and another of
shared buffers, see Figure 170. The amount of reserved buffers is calculated differently for
network and access pools. For network pools, the default is approximately the sum of the CBS
(committed burst size) values defined for all of the queues within the pool. The reserved buffer
size can also be statically configured to a percentage of the full pool size (ingress:
config>card>mda>network>ingress>pool; egress: config>port>network>egress>pool). For
access pools, the default reserved buffer size is 30% of the full pool size and can be set statically to
an explicit value (ingress: config>port>access>ingress>pool; egress:
config>port>access>egress>pool).
The following configuration sets the reserved buffer size to 50% of the egress pool space.
configure port 1/1/10
network
egress
pool
resv-cbs 50
exit
exit
exit
exit
configure port 1/1/11
access
egress
pool
resv-cbs 50
exit
exit
exit
exit

Both the total buffer and the reserved buffer sizes are allocated in blocks (discrete values of
Kbytes). The pool sizes can be seen using the show pools command.
It is possible to configure alarms to be triggered when the usage of the reserved buffers in the
buffer pools reaches a certain percentage. Two alarm percentages are configurable, amber and red,
amber-alarm-threshold <percentage> and red-alarm-threshold <percentage>. The percentage
range is 1 1000.

Page 1720

The percentage for the red must be at least as large as that for the amber.

The alarms are cleared when the reserved CBS drops below the related threshold.

Advanced Configuration Guide

QoS Architecture and Basic Operation

When the amber alarm is enabled, dynamic reserved buffer sizing can be used; after the
amber alarm is triggered the reserved buffer size is increased or decreased depending on
the CBS usage. This requires a non-default resv-cbs to be configured together with a step
and max value for the amber-alarm-action parameters. As the reserved CBS usage
increases above the amber alarm percentage, the reserved buffer size is increased in
increments defined by the step, up to a maximum of the max. If the CBS usage decreases,
the reserved buffer size is reduced in steps down to its configured size.

As the reserved buffer size changes, alarms will continue to be triggered at the same color
(amber or red) indicating the new reserved buffer size. Note that the pool sizing is checked
at intervals, so it can take up to one minute for the alarms and pool re-sizing to occur.

The following displays a configuration for access ingress and egress pools.
configure port 1/1/1
access
ingress
pool
amber-alarm-threshold 25
red-alarm-threshold 50
resv-cbs 20 amber-alarm-action step 5 max 50
exit
exit
egress
pool
amber-alarm-threshold 25
red-alarm-threshold 25
resv-cbs 20 amber-alarm-action step 5 max 50
exit
exit
exit

The following is an example alarm that is triggered when the amber percentage has been exceeded
and the reserved buffer size has increased from 20% to 25%:
19 2011/12/20 16:38:14.94 UTC MINOR: PORT #2050 Base Resv CBS Alarm
"Amber Alarm: CBS over Amber threshold: ObjType=port Owner=1/1/1 Type=accessEgre
ss Pool=default NamedPoolPolicy= Old ResvSize=13824 ResvSize=16128 SumOfQ ResvSi
ze=3744 Old ResvCBS=20 New ResvCBS=25"

When a port is configured to be a hybrid port, its buffer space is divided into an access portion and
a network portion. The split by default is 50:50 but it can be configured on a per port basis.
configure port 1/1/1
ethernet
mode hybrid
encap-type dot1q
exit
hybrid-buffer-allocation
ing-weight access 70 network 30
egr-weight access 70 network 30
exit

Advanced Configuration Guide

Page 1721

Configuration

Enqueuing Packets: Queue Sizing


Queue sizes change dynamically when packets are added to a queue faster than they are removed,
without any traffic the queue depth is zero. When packets arrive for a queue there will be request
for buffer memory which will result in buffers being allocated dynamically from the buffer pool
that the queue belongs to.
A queue has three buffer size related attributes: MBS, CBS and high-prio-only, which affect
packets only during the enqueuing process.

Maximum Burst Size (MBS) defines the maximum buffer size that a queue can use. If the
actual queue depth is equal to the MBS, any incoming packet will not be able to get a
buffer and the packet will be dropped. This is defined in bytes or Kbytes for access queues
with a minimum of 3Kbytes and a default of 10ms of the PIR. It is a fractional percentage
(xx.xx%) of pool size for network queues with defaults varying dependant on the queue
(see default network-queue policy for default values). The MBS setting is the main factor
determining the packet latency through a system when packets experience congestion.

Committed Burst Size (CBS) defines the maximum guaranteed buffer size for an
incoming packet. This buffer space is effectively reserved for this queue as long as the
CBS is not oversubscribed (i.e. the sum of the CBS for all queues using this pool does not
exceed its reserved buffer pool size). The CBS is defined in Kbytes with a minimum of
3Kbytes and a default of 10ms of the CIR. It is a fractional percentage (xx.xx%) of pool
size for network queues with defaults varying dependant on the queue (see default
network-queue policy for default values). Regardless of what is configured, the CBS
attained will never be larger than the MBS. The only case where CBS could be configured
larger than MBS is for queues on LAGs, as in some cases the CBS is shared among the
LAG ports (LAG QoS is not covered in this document).

High-prio-only. As a queue can accept both high and low enqueuing priority packets, a
high enqueuing priority packet should have a higher probability to get a buffer. High-prioonly is a way to achieve this. Within the MBS, high-prio-only defines that a certain
amount of buffer space will be exclusively available for high enqueuing priority packets.
At network ingress and all egress buffering, high corresponds to in-profile and low to outof-profile. At service ingress, enqueuing priority is part of the classification. The highprio-only is defined as a percentage of the MBS, with the default being 10%. Note that a
queue being used only for low priority/out-of-profile packets would normally have this set
to zero. The high-prio-only could be considered to be an MBS for low enqueuing/out-ofprofile packets.

As with the buffer pools, the MBS, CBS and high-prio-only values attained are based on a number
of discrete values (not always an increment of 3Kbytes). The values for these parameters can be
seen using the show pools command.
As packets are added to a queue they will use the available CBS space, in which case they are
placed in the reserved portion in the buffer pool. Once the CBS is exhausted, packets use the

Page 1722

Advanced Configuration Guide

QoS Architecture and Basic Operation

shared buffer pool space up to high-prio-only threshold (for out-of-profile packets) or the
maximum MBS size (for in-profile packets).
The following configuration shows a queue with a specific MBS, CBS and disable high-prio-only.
configure qos
sap-ingress 10 create
queue 1 create
mbs 10000
cbs 100
high-prio-only 0
exit
exit

Advanced Configuration Guide

Page 1723

Configuration

Enqueuing Packets: Weight Random Earlier Detection (WRED)


In order to gracefully manage the use of the shared portion of the buffer pool, WRED can be
configured on that part of the pool, and therefore applies to all queues in the shared pool as it fills.
WRED is a congestion avoidance mechanism designed for TCP traffic. This note will only focus
on the configuration of WRED. WRED-per-queue is an option to have WRED apply on a per
egress queue basis, but is not covered here.
WRED is configured by a slope-policy which contains two WRED slope definitions, a high-slope
which applies WRED to high enqueuing priority/in-profile packets and a low-slope which applies
WRED to low enqueuing priority/out-of-profile packets. Both have the standard WRED
parameters: start average (start-avg), maximum average (max-avg) and maximum probability
(max-prob), and can be enabled or disabled individually. The WRED slope characteristics are
shown in Figure 169.

Discard Probability

No Discard

Random Disc

3
4

max-avg

max-prob

All Discard

start-avg

4
3

Average Shared Buffer Utilization

Figure 169: WRED Slope Characteristics

A time-average-factor parameter can be configured per slope-policy which determines the


sensitivity of the WRED algorithm to shared buffer utilization fluctuations (the smaller the value
makes the average buffer utilization more reactive to changes in the instantaneous buffer
utilization). The slope-policy is applied on a network port under
config>card>mda>network>ingress>pool and port>network>egress>pool and on an access
port under config>port>access>ingress>pool and config>port>access>egress>pool.

Page 1724

Advanced Configuration Guide

QoS Architecture and Basic Operation

WRED is usually configured for assured and best-effort service traffic with premium traffic not
typically being subject to WRED as it is always given preferential treatment and should never be
dropped.
The following configuration defines a WRED slope policy and apply it to an ingress access port.
configure qos
slope-policy "slope1" create
high-slope
start-avg 80
max-avg 100
max-prob 100
no shutdown
exit
low-slope
max-avg 100
start-avg 80
max-prob 100
no shutdown
exit
time-average-factor 12
exit
exit
configure port 1/1/10
access
ingress
pool
slope-policy "slope1"
exit
exit
exit
exit

The queue sizing parameters and buffer pools layout is shown in Figure 170.

Advanced Configuration Guide

Page 1725

Configuration

MBS
(Max Size of Queue)
Max

Queue
High
Priority
Only

Max Size of Queue for Low


Enqueuing Priority Packets

CBS reserved

WRED
100%

Buffer
Pool

Discard
Probability

Low
Prio

0%
0%

High
Prio

100%

Average Buffer
Utilisation

Shared Buffers

Reserved
Buffers
OSSG402

Figure 170: Buffer Pools and Queue Sizing

Page 1726

Advanced Configuration Guide

QoS Architecture and Basic Operation

Dequeuing Packets: Queue Rates


A queue has two rate attributes: PIR and CIR. These affect packets only during the dequeue
process.

PIR If the instantaneous dequeue rate of a queue reaches this rate, the queue is no
longer served. Excess packets will be discarded eventually when the queue reaches its
MBS/high-prio-only sizes. The PIR for access ports can be set in Kb/s with a default of
max or as a percentage (see below). For network ports it is set as a percentage of
390000Kb/s for ingress queues and of the port speed for egress queues, both with a default
of 100%.

CIR This is used to determine whether an ingress packet is in-profile or out-of-profile


at the SAP ingress. It is also used by the scheduler in that queues operating within their
CIRs will be served ahead of queues operating above their CIRs. The CIR for access ports
can be set in Kb/s with a default of zero or as a percentage (see below). For network ports
it is set as a percentage of 390000Kb/s for ingress queues and of the port speed for egress
queues, with defaults varying dependant on the queue.

A percentage rate can be used in the sap-ingress and sap-egress policies, and can be defined
relative to the local-limit (the parent scheduler rate) or the port-limit (the rate of the port on which
the SAP is configured, including any egress-rate configured). The parameters rate and percent-rate
are mutually exclusive and will overwrite each other when configured in the same policy. The
example below shows a percent-rate configured as a port-limit.
config>qos#
qos
sap-egress 10 create
queue 1 create
percent-rate 50.00 cir 10.00 port-limit
exit

The PIR and CIR rates are shown in Figure 171.


The queues operate at discrete rates supported by the hardware. If a configured rate does not
match exactly one of the hardware rates an adaptation rule can be configured to control whether
the rate is rounded up or down or set to the closest attainable value. The actual rate used can be
seen under the operational PIR/CIR (O.PIR/O.CIR) in the show pools command output.
The following configuration shows a queue with a PIR, CIR and adaptation rule.
configure qos
sap-ingress 20 create
queue 2 create
adaptation-rule pir max cir min
rate 10000 cir 5000
exit
exit

Advanced Configuration Guide

Page 1727

Configuration

By default, the rates apply to packet bytes based on packet accounting, which for Ethernet
includes the Layer 2 frame plus the FCS. An alternative is frame accounting which adds the
Ethernet inter-frame gap, preamble and start frame delimiter.

Page 1728

Advanced Configuration Guide

QoS Architecture and Basic Operation

Dequeuing Packets: Scheduling


Once a packet is placed on a queue, it is always dequeued from the queue by a scheduler. The
scheduling order of the queues dynamically changes depending on whether a queue is currently
operating below or above its CIR, with expedited queues being serviced before best-effort queues.
This results in a default scheduling order of (in strict priority).
1. Expedited queues operating below CIR
2. Best-effort queues operating below CIR
3. Expedited queues operating above CIR
4. Best-effort queues operating above CIR
This is displayed in Figure 171.
The scheduling order can be explicitly configured using hierarchical QoS (with a scheduler-policy
or port-scheduler-policy) which is out of scope of this section.

Expedited
QS < CIR

Minimum
Guaranteed
Scheduling Rate

CIR

PIR

Max. Scheduling Rate


Queue Is Not Served
If Rate > PIR

QS > CIR

Packets
Out-of-pocket
Packets
In-profile

1
2

Packets
Dropped

Best Effort

Strict
Priority

4
QS < CIR

Queue State (QS)

QS > CIR

OSSG403

Figure 171: Scheduling (Dequeuing Packets from the Queue)

The overall QoS actions at both the ingress and egress IOMs are shown in Figure 172.

Advanced Configuration Guide

Page 1729

Configuration

Ingress IOM

Egress IOM

Queue State: Packet Colour


Buffer
Shared Reserved

Classify into FC
based on packet
QOS bits and/or
packet header
(ip/mac).

Q2

aboveCIR: OUT-profile
within CIR: IN-profile

Q1

aboveCIR: OUT-profile
within CIR: IN-profile

Queue is either
expedited or
best-effort
priority.

Buffer in queue
based on FC to
queue mapping,
enqueuing
priority, queue
depth and
WRED.

Expedited
withinCIR
Best-effort
withinCIR
Expedited
aboveCIR
Best-effort
aboveCIR

Scheduled
through switch
fabric.

Colour packet
based on
withinCIR->
IN-profile or
aboveCIR->
OUT-of-profile.

FC
NC
H1
EF
H2
L1
AF
L2
BE

aboveCIR
within CIR

Q6

Q5

aboveCIR
within CIR

Q4

aboveCIR
within CIR

Still in
FC EF.

Expedited
withinCIR
Best-effort
withinCIR
Expedited
aboveCIR
Best-effort
aboveCIR

Queue is either
expedited or
best-effort
priority.

Buffer in queue
based on FC to
queue mapping,
in/out-profile,
queue depth
and WRED.

Marking

aboveCIR: OUT-profile
within CIR: IN-profile

Q3

Switch Fabric

FC
NC
Packet
H1
EF
SAP 1/1/1 H2
L1
AF
L2
BE

Queue State
Buffer
Shared Reserved

Port 1/2/1

Scheduled to
port with
marking
applied.

Packet NOT
reColoured.

OSSG406

Figure 172: IOM QoS Overview

Page 1730

Advanced Configuration Guide

QoS Architecture and Basic Operation

Show Output
The following displays show command output for:

SAP queue statistics

port queue statistics

access-ingress pools

The show pools command output for network-ingress and network/access-egress is similar to that
of access-ingress and is not included here.

SAP Queue Statistics


The output below shows an example of the ingress and egress statistics on a SAP for an IES
service (without multicast enabled, hence no ingress multicast queue). There are two ingress
queues, one being in priority mode and the other in profile mode. An explanation of the statistics
is given for each entry.
B:PE-1# show service id 1 sap 1/1/10:1 stats
....
-------------------------------------------------------Sap per Queue stats
-------------------------------------------------------Packets
Octets

Buffer
acceptance:
Based on sap-ingress classification
fail
pass

tail drop (MBS), WRED high-slope, out of shared buffers


tail drop (high-prio-only), WRED low-slope, out of shared buffers
packets forwarded while queue was operating withinCIR
packets forwarded while queue was operating aboveCIR

Based on sap-ingress classification


fail
pass

pass
fail

tail drop (high-prio-only), WRED low-slope, out of shared buffers


tail drop (MBS), WRED high-slope, out of shared buffers
ColorIn packets or Uncolor while queue was operating withinCIR
ColorOut packets or Uncolor while queue was operating aboveCIR
packets with profile state = InProfile (determined at ingress)
Packets with profile state = OutOfProfile (determined at ingress)
tail drop (MBS), WRED high-slope, out of shared buffers
tail drop (high-prio-only), WRED low-slope, out of shared buffers

Advanced Configuration Guide

Ingress Queue 1 (Unicast) (Priority)


Off. HiPrio
: 0
Off. LoPrio
: 19022
Dro. HiPrio
: 0
Dro. LoPrio
: 17783
For. InProf
: 548
For. OutProf
: 691

0
4869632
0
4552448
140288
176896

Ingress Queue 2 (Unicast) (Profile)


Off. ColorIn
: 29439
Off. ColorOut
: 0
Off. Uncolor
: 0
Dro. ColorOut
: 0
Dro. ColorIn & Uncolor: 16193
For. InProf
: 17098
For. OutProf
: 0

7536384
0
0
0
4145408
4377088
0

Egress Queue 1
For. InProf
: 0
0
For. OutProf
: 48461
12406016
Dro. InProf
: 0
0
Dro. OutProf
: 0
0
========================================================

Page 1731

Configuration

Port Queue Statistics


This output shows an example of the ingress and egress network port statistics. There are two
unicast ingress queues (1 and 2) and one multicast ingress queue (9) with two egress queues. An
explanation of the statistics is given for each entry.

Buffer
acceptance:
pass
packets classified as InProfile at network-ingress
fail tail drop (MBS), WRED high-slope, out of shared buffers
pass
packets classified as OutOfProfile at network-ingress
fail
tail drop (high-prio-only), WRED low-slope,
out of shared buffers

pass
packets classified as InProfile at network-ingress
fail tail drop (MBS), WRED high-slope, out of shared buffers
pass
packets classified as OutOfProfile at network-ingress
fail
tail drop (high-prio-only), WRED low-slope,
out of shared buffers

Page 1732

B:PE-1# show port 1/1/11 detail


....
===============================================================
Queue Statistics
===============================================================
--------------------------------------------------------------Ingress Queue 1
Packets
Octets
In Profile forwarded :
0
0
In Profile dropped
:
0
0
Out Profile forwarded :
16305
4174080
Out Profile dropped
:
0
0
Ingress Queue 2
Packets
Octets
In Profile forwarded :
0
0
In Profile dropped
:
0
0
Out Profile forwarded :
0
0
Out Profile dropped
:
0
0
Ingress Queue 9
Packets
Octets
In Profile forwarded :
0
0
In Profile dropped
:
0
0
Out Profile forwarded :
0
0
Out Profile dropped
:
0
0
Egress Queue 1
Packets
Octets
In Profile forwarded :
490
125440
In Profile dropped
:
0
0
Out Profile forwarded :
603
154368
Out Profile dropped
:
0
0
Egress Queue 2
Packets
Octets
In Profile forwarded :
0
0
In Profile dropped
:
0
0
Out Profile forwarded :
0
0
Out Profile dropped
:
0
0
===============================================================
B:PE-1#

Advanced Configuration Guide

QoS Architecture and Basic Operation

Access-Ingress Pools
This output shows an example of the default pools output for access-ingress. It includes the pools
sizes, WRED information and queue parameters for each queue in the pool.
For this particular output, queue 3 on SAP 1/1/10:1 is being over-loaded which is causing its
queue depth to be 6858Kbytes, made up of 5853Kbytes from the shared pool (in use) and
1008Kbytes from the reserved pool (in use). The output shows the pool total in usage as
6861Kbytes and the queue depth 3Kbytes less at 6858Kbytes, this is simply due to the dynamics
of the buffer allocation which uses a sliding-window mechanism and may therefore not always
be perfectly aligned.
It can be seen that the high and low WRED slopes are both enabled and their instantaneous drop
probability is shown 100% and their start/max averages are 5088Kbytes and 5856Kbytes,
respectively this shows that the reserved portion of the buffer pool on this port is exhausted
causing WRED to drop the packets for this queue.
The admin and operational PIR on the overloaded queues is 10Mb/s with CIR values of zero.
B:PE-1# show pools 1/1/10 access-ingress
===============================================================================
Pool Information
===============================================================================
Port
: 1/1/10
Application
: Acc-Ing
Pool Name
: default
Resv CBS
: Sum
------------------------------------------------------------------------------Queue-Groups
------------------------------------------------------------------------------------------------------------------------------------------------------------Utilization
State
Start-Avg
Max-Avg
Max-Prob
------------------------------------------------------------------------------High-Slope
Up
80%
100%
100%
Low-Slope
Up
80%
100%
100%
Time Avg Factor
Pool Total
Pool Shared

: 12
: 8448 KB
: 5856 KB

Pool Resv

: 2592 KB

High Slope Start Avg : 5088 KB


Low Slope Start Avg : 5088 KB

High slope Max Avg : 5856 KB


Low slope Max Avg : 5856 KB

Pool Total In Use


Pool Shared In Use
WA Shared In Use

Pool Resv In Use

: 6861 KB
: 5853 KB
: 5853 KB

: 1008 KB

Hi-Slope Drop Prob


: 100
Lo-Slope Drop Prob : 100
------------------------------------------------------------------------------Name
Tap
FC-Maps
MBS
HP-Only A.PIR
A.CIR
CBS
Depth
O.PIR
O.CIR
------------------------------------------------------------------------------28->1/1/10:28->3
1/*
af
10176
0
10000
0
1008
0
10000
0

Advanced Configuration Guide

Page 1733

Configuration

28->1/1/10:28->1
1/*

be l2 l1 h2
h1 nc

1224
0

144
0

1000000
Max

0
0

MCast

be l2 af l1
h2 ef h1 nc

1224
0

144
0

1000000
Max

0
0

1/*

be l2 l1 h2
h1 nc

1224
0

144
0

1000000
Max

0
0

1/*

af

10176
1008

0
6858

10000
10000

0
0

1/*

ef

1224
0

144
0

1000000
Max

0
0

1/*

ef

28->1/1/10:28->11

1->1/1/10:1->1

1->1/1/10:1->3

1->1/1/10:1->2

28->1/1/10:28->2
1224
144
1000000 0
0
0
Max
0
===============================================================================
B:PE-1#

Page 1734

Advanced Configuration Guide

QoS Architecture and Basic Operation

Conclusion
This note has described the basic QoS functionality available on the Alcatel-Lucent 7x50
platforms, specifically focused on the FP2 chipset. This comprises of the use of queues to shape
traffic at the ingress and egress of the system and the classification, buffering, scheduling and
remarking of traffic on both access, network and hybrid ports.

Advanced Configuration Guide

Page 1735

Conclusion

Page 1736

Advanced Configuration Guide

RADIUS-Triggered Dynamic Data


Service Provisioning

In This Chapter
This section describes advanced RADIUS-triggered dynamic data service provisioning
configurations.
Topics in this section include:

Applicability on page 1738

Overview on page 1739

Configuration on page 1742

Conclusion on page 1781

Advanced Configuration Guide

Page 1737

Applicability

Applicability
This example is applicable to all 7750 SR-7/12 and 7450 ESS-7/12 in mixed mode with multicore
CPM (CPM-3 and later) and ESM capability.
This feature is not supported on the 7950 XRS, 7750 SR-1, 7450 in pure ESS-mode or 7710 SR.
The configuration was tested on release 11.0R2.

Page 1738

Advanced Configuration Guide

RADIUS-Triggered Dynamic Data Service Provision-

Overview
RADIUS-triggered dynamic data services enables a zero touch, single-ended provisioning model
for business services on the basis of Enhanced Subscriber Management functionality.
Triggered by the authentication of a single or dual stack PPPoE session or single stack IPv4 host
as the control channel from the business CPE, parameters are passed in a RADIUS Access
Accept or Change of Authorization (CoA) message to set up one or multiple Layer-2 or Layer-3
data services.
This concept removes the need to have an Operations Support System (OSS) responsible for the
service provisioning and is particularly beneficial in a highly dynamic network environment,
where physical network topologies especially in the access change frequently. With a regular
service provisioning, frequent changes would be hard to keep track of. In the RADIUS-based
model the service gets instantiated wherever it pops-up in the network. Even planned customer
moves to a different office would not require advanced notifications and lead times but could be
instantaneous, assuming the pure physical connectivity is given.
A variation of the current service offering will only require one or a few modified service
parameters in the RADIUS user database and does not require timely and costly IT changes (for
RADIUS those service parameters are just attributes; the RADIUS server does not check the
logic). This speeds up the time-to-market for new service offerings, which is another big
advantage.
Taking this logic to its full extent, it becomes immediately clear that the managed business CPE
terminating the carrier service (and being responsible for the PPP or DHCP control channel) also
needs to be provisioned in the most flexible way. Through the control channel or a dedicated
management channel instantiated as the first dynamic data service, the business CPE should get its
full configuration from a configuration server via a pre-populated configuration file. The details of
the CPE provisioning are outside of the scope of this example and therefore not discussed further.
As the whole approach is centered around the principle of highly flexible in a highly dynamic
environment, it is naturally required to maintain as little state information about connections in
the RADIUS parameter attributes as possible. For example, fixed remote peer IP-addresses for the
SDPs used in a VPLS service in the RADIUS parameter lists would remove all the flexibility and
would not allow access services to be moved dynamically. As such the allowed data services for
this functionality focuses on those types where a control protocol like BGP is used to exchange
VPN membership information. Dynamic data services supported in this release include local
Epipe VLL services, Epipe VLL services with dynamic Multi-Segment PseudoWires (MS-PWs)
(FEC129), VPLS services with BGP-AD PWs, IES, and VPRN services.
A Python script interface adds a flexible abstraction layer so that only the business user specific
service parameters (service type, IP address, QoS and filter parameters, etc.) are required from
RADIUS and are then used in a CLI template to set up the target service.

Advanced Configuration Guide

Page 1739

Overview

The setup sequence is shown in Figure 173 with the example of a VPLS service.
RADIUS

3 Access-accept with Service Information


for Trigger Session (IP@, Assign to DCN, etc.)
and Service Information for Dynamic Data Service
(VPLS, SAP-VLAN, QoS, Filters, MAC-limit, etc.)

2 Access-request with
All User Credentials

5 Send Accounting Information


BNG

for Trigger Session and


Data Channel

1 PPP or DHCP Control Channel


Session on VLAN x

123

DCN

7
123

Create Service Instance 4


and SAP on VLAN y
BNG

Advertise New Service

6 Via BGP-AD

Auto.create
SDPs
123

BNG
al_0286

Figure 173: Principle Model of Dynamic Data Services

1. Business CPE initiates a PPP or DHCP control channel session. This session is important
to let the BNG and RADIUS understand the existence of a new access circuit and the location of the service endpoint.
2. BNG sends an Access-Request with all user credentials to RADIUS.
3. RADIUS replies using an Access-Accept with attributes for the PPP/DHCP control channel
and attributes for the dynamic data service (Service-type, SAP-VLAN, QoS, Filter, etc.).
4. BNG creates a dynamic data service instance (if it is first access-circuit for this service) and
a SAP, thus completing the service configuration.
5. BNG sends an Accounting Start for PPP/DHCP control channel session and also for the
dynamic data service session (and subsequently interim accountings and accounting stop for
both).
6. BNG advertises VPLS instance-ID (123) via BGP-AD to other PEs/BNGs.
7. PEs/BNGs with same service instance will auto-establish SDPs to the BNG.
The result is a fully functional service which is the same as a traditionally configured service.
The lifetime of the dynamic data services are bound to the existence of the control channel
session. If, for whatever reason, the control channel session is torn down all associated dynamic
data services will also be terminated.
Dynamic data service SAPs have to be located on dot1q or qinq encapsulated Ethernet ports and
can be part of a LAG.

Page 1740

Advanced Configuration Guide

RADIUS-Triggered Dynamic Data Service Provision-

Both XML accounting and RADIUS accounting can be enabled on a dynamic data service SAP.
The RADIUS accounting data can be sent to up to two different RADIUS servers.
There is a strict separation of services created by dynamic service provisioning and services
created via the CLI or through other standard mechanisms (5620 SAM, SNMP). It is therefore not
allowed to:

create a dynamic services object in a local provisioned CLI/SNMP context (e.g. create a
dynamic SAP in a local provisioned VPLS).

create a local provisioned object in a dynamic service context (e.g. create a SAP via CLI/
SNMP in a dynamic VPLS service).

change parameters in a local provisioned CLI/SNMP context using the dynamic services
model (change system name with dynamic services provisioning).

change parameters with the CLI/SNMP in a dynamically created context.

delete a local provisioned object using dynamic provisioning model.

delete a dynamic provisioning object using the CLI/SNMP.

create a reference to a dynamic services object in a local provisioned CLI/SNMP context


(reference to dynamic interface in router ospf)

A special command exists to overcome some of the above rules. This command is designed to
ease Python script creation and testing and not for normal operations. This is discussed in
Configuration on page 1742.

Advanced Configuration Guide

Page 1741

Configuration

Configuration
It is assumed that the reader is familiar with the regular Enhanced Subscriber Management (ESM)
functionality as well as with general service related configurations. Furthermore certain
knowledge about Python programming is also assumed.
The test topology is shown in Figure 174.
RADIUS

172.31.1.2

Remote PE
MSAP

HG or Test Device
to Generate PPP
or DHCP Session

BNG
192.0.2.1
al_0287

Figure 174: Test Topology

The pure service setup can be tested with a single node acting as BNG. However an Epipe service
between two nodes will not normally become status up with only one endpoint in an up state. As
such, for packets should be sent through the established dynamic data service, a remote PE could
also be configured. The remote PE could have its data service configured in a regular fashion,
meaning via CLI/SNMP or 5620 SAM.
The required functionality on the BNG is divided into multiple building blocks. The following
sections discuss each building block in detail.

Page 1742

Advanced Configuration Guide

RADIUS-Triggered Dynamic Data Service Provision-

Control Channel

Dyn Serv Policy

CLI Snippets

RADIUS Attributes

Python Script

RADIUS Accounting
al_0288

Figure 175: Building Blocks of Dynamic Data Services

Based on a PPP or DHCP control session, RADIUS will return the required parameters for the
dynamic data service via dedicated Vendor Specific Attributes (VSAs). The existence of those
attributes in the RADIUS Accept message will trigger the relaying of the parameters relating to
those attributes towards the Python script defined in the dynamic service policy, which will
process them to generate the regular CLI output for the various service types (IES, VPRN, Epipe,
VPLS).
For efficiency and flexibility the Python script needs to be structured into different parts per
service which then reference each other internally. Those parts are called snippets.
Finally, as the services are initiated from RADIUS, RADIUS accounting messages per dynamic
data service will be sent to the RADIUS server as a necessary feedback mechanism to inform the
RADIUS server about a successful or failed service setup.
Building Block: Control Channel
The configuration to authenticate and instantiate a dynamic data service control channel is
identical to a residential Enhanced Subscriber Management (ESM) configuration. Examples for
this can be found in other sections of the advanced configuration guide and will not be covered
here in detail.
Building Block: Dynamic Services Policy
The dynamic services parameters are configured under the configure service dynamic-services
CLI context. The following output shows two policy examples.
configure service dynamic-services
dynamic-services-policy "dynamic-services-1" create
accounting-1
server-policy "radius-server-policy-1"
update-interval min 5
exit
accounting-2
server-policy "radius-server-policy-2"

Advanced Configuration Guide

Page 1743

Configuration

stats-type time
update-interval min 5
update-interval-jitter absolute 10
exit
cli-user "dynuser"
description "Dynamic Service Policy #1"
sap-limit 4000
script-policy "script-policy-1"
exit
dynamic-services-policy "dynamic-services-2" create
accounting-1
server-policy "radius-server-policy-2"
stats-type volume-time
update-interval min 30
update-interval-jitter absolute 20
exit
accounting-2
server-policy "radius-server-policy-2"
stats-type time
update-interval min 5
update-interval-jitter absolute 10
exit
cli-user "dynuser"
description "Dynamic Service Policy #2"
sap-limit 100
script-policy "script-policy-2"
exit
service-range 1000 10000
timers
setup-timeout access-accept 3
exit

Details of each command and the possible parameters can be found in the SR OS Triple Play
Guide in the RADIUS Triggered Dynamic Data Services section.
On the top command level under the dynamic-services sub-tree there are three options:

dynamic-services-policy

service-range

timers

The setup-timeout value under timers is used to limit the maximum delay allowed for a dynamic
data service setup. In addition, it also protects the node during times where there is a high load on
the CPU. If a requested dynamic data service cannot be established in the specified time the
request will be dropped.
Dynamic data services are not preferred over regular ESM subscribers. As such, given a BNG
with a mix of residential ESM subscribers and business customers with dynamic data services, all
compete for the same CPU resources to establish the connections.
However, dynamic data services are expected to have a very long lifetime compared to potentially
very dynamic lifetimes for residential subscribers. In a regular operating mode the amount of

Page 1744

Advanced Configuration Guide

RADIUS-Triggered Dynamic Data Service Provision-

additional setup requests for dynamic data services should be relatively small. Only in the event of
a node reboot will all users again compete to gain access, where longer setup-times are inevitable.
The service-range value reserves a certain amount of service IDs for the use of dynamic data
services. The configured range is no longer available for regular provisioned services configured
via the CLI/SNMP.
The dynamic-services-policy contains a CLI-user identifier, SAP-limits, accounting parameters
and reference to a Python script policy which is used when creating a dynamic data service.
Multiple dynamic services policies can be created to enable different profiles to be used for
different users/customers or services (as an example, two different departments within the service
provider, one responsible for Layer 2 services, one for Layer 3 services). The policy used for a
dynamic data service is determined from the Alc-Dyn-Serv-Policy [26-6527-167] RADIUS
attribute. If the attribute is not present and a policy named default exists, then the default policy is
used, otherwise the dynamic data service creation fails.
Up to two accounting server policies can be defined. This allows the use of separate RADIUS
accounting servers independent from the accounting servers used for residential services. The
parameters defined in the accounting sections are the default values which are used if no specific
values are sent via RADIUS VSAs.
As the service is established via RADIUS, a feedback mechanism towards RADIUS is most likely
required which would be at least RADIUS start and stop messages per service/session. In addition
performance counters (with a fixed set of parameters) can also be included in the RADIUS
messages. It is also possible to use the standard service-accounting under the service instance and
remove any counters from the RADIUS accounting messages.
The specification of a CLI user allows linking of the dynamic data service to a specific userprofile. In addition, this facilitates limiting of the scope of allowed service configurations even
further, based on the specified context under the user profile.
The CLI-user needs to be configured locally on the node and needs to have a local user profile
(remote authorization via TACACS/RADIUS is not possible).
The radius-script-policy is configured under the configure aaa CLI context.
configure aaa
radius-script-policy "script-policy-2
action-on-fail passthrough
primary
script-url "cf3:/scripts/dyn_services.py"
no shutdown
exit
secondary
script-url ftp://*:*@10.255.137.80/scripts/dyn_services.py"
no shutdown
exit
exit
exit

Advanced Configuration Guide

Page 1745

Configuration

The parameters are no different to what have been defined generally for the use of Python
scripting on the BNG.
When the very first session request arrives, the Python script is loaded into memory and executed.
For all subsequent session requests the script is executed without the need for a reload. It is
possible for both primary and secondary locations to be FTP sites (the small transfer delay for the
first session is acceptable), however, it is recommended to have a compact-flash (cf1 or cf2) as the
primary location and a remote location as backup.
Building Block: RADIUS Attributes
A series of Alcatel-Lucent vendor specific attributes (VSAs) have been defined to setup, teardown
or modify dynamic data services from RADIUS.
The VSAs and their meaning are as follows:

Alc-Dyn-Serv-SAP-Id [26-6527-164], type string


This attribute identifies the dynamic service SAP. The format can be any valid Ethernet
SAP format (dot1q or qinq encapsulation), including LAGs. A wildcard (#) can be
specified for the port field and optionally for one of the tag fields of a qinq interface. To
define the dynamic data service SAP-ID, the wildcard fields are replaced with the
corresponding field from the Control Channel SAP-ID.
Examples: 1/2/7:10.100 or #:#.100

Alc-Dyn-Serv-Script-Action [26-6527-166], type integer


A mandatory VSA in a COA to the control channel accounting session ID or the
accounting session ID of the dynamic data service (only applicable for modify or
teardown). Tells the system what script action is required: setup, modify or teardown of a
dynamic data service.
Values: 1=setup, 2=modify, 3=teardown

Alc-Dyn-Serv-Policy [26-6527-167], type string


Specifies the dynamic service policy to use for provisioning the dynamic service. The
policy must be configured in the configure service dynamic-services dynamic-servicespolicy < dynsrv-policy-name> CLI context.

Alc-Dyn-Serv-Script-Params [26-6527-165], type string


This VSA contains parameters that can be used by the Python script to setup or modify a
dynamic data service. The parameters can be split into multiple instances of the same
attribute, linked together by the same tag, that is, the parameters can cross an attribute
boundary. The concatenation of all Alc-Dyn-Serv-Script-Params attributes with the
same tag in a single message must be formatted as function-key = {dictionary} where
function-key specifies which Python functions will be called and {dictionary} contains
the actual parameters in a Python dictionary structure format.

Page 1746

Advanced Configuration Guide

RADIUS-Triggered Dynamic Data Service Provision-

Example: business_1 = { 'as_id' : '100', 'comm_id' : '200', 'if_name' : 'itf1', 'ipv4_address'


: '172.16.1.1', 'egr_ip_filter' : '100' , 'routes' : [{'to' : '172.16.100.0/24', 'next-hop' :
'172.16.1.2'}, {'to' : '172.16.200.0/24', 'next-hop' : '172.16.1.2'}]}
The above example shows each parameter with a keyword and the associated value.
Alternatively only the parameter values can be sent with a pre-defined (and always
constant) sequence.
Example: business_1 = {t: '100', '200', 'itf1', '172.16.1.1', '100', '172.16.100.0/24',
'172.16.1.2', '172.16.200.0/24', '172.16.1.2'}.

Alc-Dyn-Serv-Acct-Interim-Ivl-1 [26-6527-168], type integer


This VSA defines the number of seconds between each accounting interim update
message for the primary accounting server. It overrides the local configured updateinterval value in the dynamic services policy accounting-1 CLI context. A value of 0
(zero) corresponds to no accounting interim update messages. A value [1..299] seconds is
rounded to 300s (min. CLI value) and a value above 15552000 seconds (180 days,
maximum CLI value) is rounded to the maximum CLI value.
Range = 0 | [300 - 15552000].

Alc-Dyn-Serv-Acct-Interim-Ivl-2 [26-6527-169], type integer


Same function and values as Alc-Dyn-Serv-Acct-Interim-Ivl-1 [26-6527-168], for the
second accounting server. It overrides the locally configured update-interval value in
the dynamic services policy accounting-2 CLI context.

Alc-Dyn-Serv-Acct-Stats-Type-1 [26-6527-170], type integer


Enable or disable dynamic data service accounting to the primary accounting server and
specify the type of statistics that should be reported: volume and time or time only. It
overrides the locally configured value in the dynamic services policy accounting-1 CLI
context.
Values: 1=off, 2=volume-time, 3=time

Alc-Dyn-Serv-Acct-Stats-Type-2 [26-6527-171], type integer


Enable or disable dynamic data service accounting to the secondary accounting server and
specify the type of statistics that should be reported: volume and time or time only. It
overrides the locally configured stats-type value in the dynamic services policy
accounting-2 CLI context.
Values: 1=off, 2=volume-time, 3=time

All VSAs are tagged to enable manipulation of up to 32 (tag values 0..31) dynamic data services in
a single RADIUS message. VSAs with an identical tag belong to the same dynamic data service.
The use of the VSAs in RADIUS Access-Accept, CoA and Disconnect Messages is detailed in
Table 27. An Access-Accept message can only contain dynamic data service setup requests. A
CoA can be used to setup, modify or terminate a dynamic data service. A Disconnect Message can
only be used to terminate a dynamic data service.

Advanced Configuration Guide

Page 1747

Configuration

Table 27: Dynamic Service Attribute List for Setup, Modify and Teardown
Access
Accept

Disc.
Message

CoA

Comment

Attribute Name
Setup

Setup

Modify

Teardown

N/A

Acct-Session-Id of the
Control Channel or in case
of a CoA: any other valid
CoA key for ESM hosts/
sessions.

Alc-Dyn-Serv-SAP-Id

M(*)

M(*)

M(*)

N/A

Identifies the dynamic data


service

Alc-Dyn-Serv-ScriptParams

M(*)

M(*)

N/A

N/A

For a Modify, the script


parameters represent the
new parameters required for
the change.

Alc-Dyn-Serv-ScriptAction

M(*)

M(*)

M(*)

N/A

Must be setup if specified


in an access-accept.

Alc-Dyn-Serv-Policy

N/A

The default policy used


when not specified for
create.
In CoA, must be same as
used for Setup if Specified
for Modify or Teardown.

Alc-Dyn-Serv-AcctInterim-Ivl-1

X(**)

X(**)

N/A

Alc-Dyn-Serv-AcctInterim-Iv2

X(**))

X(**))

N/A

Alc-Dyn-Serv-Acct-StatsType-1

X(**)

X(**))

N/A

Alc-Dyn-Serv-Acct-StatsType-2

X(**))

X(**))

N/A

Acct-Session-Id

Teardown

M = Mandatory, O= Optional, X = May not, N/A = Not Applicable (ignored)


(*) = CoA Nakd, if not specified (Error Cause: 402 - Missing Attribute)
(**) = CoA Nakd if specified (Error Cause:405 - Unsupported Service)

Page 1748

Advanced Configuration Guide

RADIUS-Triggered Dynamic Data Service Provision-

To summarize, Table 28 shows resulting dynamic service script actions as function of the
RADIUS message (Access-Accept, CoA or DM) and the target (Control Channel or Dynamic
Service SAP).

Table 28: Dynamic Service Actions on Control- and Data-Channel


Target

Control
Channel

Dynamic
Service

RADIUS
Message
Access-Accept

Dynamic Service Script


Action

Comments

Setup

Up to 32 dynamic data services in single message.


Alc-Dyn-Serv-Script-Action VSA optional.

Modify/Teardown

Not supported.

CoA
(acct-session-id or
any other valid
CoA key for ESM
hosts/sessions)

Create/Modify/
Teardown

Cannot be mixed with session/post parameter changes in the


same RADIUS message (results in CoA NAK).
Up to 32 dynamic data services in single message.
Alc-Dyn-Serv-Script-Action VSA mandatory.

Disconnect

N/A

Teardown the Control Channel session and all associated


dynamic data services.

CoA
(acct-session-id of
the dynamic data
service sap)

Modify/Teardown

Only single dynamic data service per message (AcctSession-Id).


Alc-Dyn-Serv-Script-Action VSA mandatory.

Setup

Not supported.

N/A

Teardown the corresponding dynamic data service.

Disconnect
(acct-session-id of
the dynamic data
service sap)

Advanced Configuration Guide

Page 1749

Configuration

Building Block: Python Script


Dynamic data services scripts are built using a Python script engine. The following dedicated
functions are available in the alc.dyn module:

dyn.reference(function-key, reference-id string, dictionary)


This function creates a dynamic reference to another function in the script. This function
eases the creation of N:1 relationships in the script. For more information about use cases,
see Building Block: CLI Snippets on page 1753. The function-key specifies the key in the
action dictionary to find the corresponding setup/modify/teardown function calls.
The reference-id (typically derived from a parameter specified from RADIUS, for
example: service-name) specifies a unique instance string that identifies this reference.
The dictionary specifies a dictionary with parameters that can be used in the parent
function to generate CLI script output.

dyn.action(d)
When called, the dyn.action will take the function-key string specified in the Alc-DynServ-Script-Params attribute, and perform a lookup in the specified dictionary d to find
the corresponding Python function to execute. The format of the dictionary is d = {key-1 :
(Setup-1, Modify-1, Revert-1, Teardown-1), , key-n : (Setup-n, Modify-n, Revert-n,
Teardown-n) }. If the function-key matches, for example, key-1 and the corresponding
Alc-Dyn-Script-Action is setup, then the function specified as Setup-1 will be
executed. Setup and teardown functions are mandatory. Modify and revert functions are
optional. If a modify function is defined, a corresponding revert function must also be
defined. If no modify/revert function is required, the keyword None should be used
instead.

dyn.add_cli(string)
This function is used to generate CLI output in the Python script. The use of dyn.add_cli
() allows the specification of strings spanning multiple lines, which drastically
improves the readability of the script.
A subset of all available CLI commands is currently enabled for dynamic data services.
The command tools dump service dynamic-services command-list provides a complete
overview of all available CLI nodes for dynamic data services. In the allowed nodes
section, all CLI nodes are listed that can be navigated to and where attributes can be
modified. The pass through nodes section shows CLI nodes that can be navigated to but
no attribute changes are allowed. For example, it is not allowed to change the autonomous
system of a router (configure router autonomous-system <autonomous-system>) because
configure router is a pass through node. However, you can navigate to configure
router, because you can add a static route: /configure router static-route 0.0.0.0/0 nexthop 192.168.1.1 is part of the allowed nodes.

Page 1750

Advanced Configuration Guide

RADIUS-Triggered Dynamic Data Service Provision-

dyn.select_free_id(service-id)
This function is used to select a free service ID within the service ID range defined under
dynamic-services context. An automatic assignment of the service id is one option, but it
is also possible to provide the service id as one of the parameters in the Alc-Dyn-ServScript-Params list from RADIUS.
The service-ID is a node-internal attribute. As such it is valid to let the node select the ID
itself. However, in a network with multiple BNGs and a single customer service spanning
two or more BNGs, a network administrator may actually prefer to use the same serviceid for this customer service on all nodes for better visibility, which cannot be guaranteed if
the automatic option is chosen. 5620 SAM is also using the service-ID as one attribute in
addition to others to discover service-entities across the whole network. If SAM is in use
for general management and service assurance, it is advised to manually specify the
service-ID and not to use the automatic selection.
In any case, the administrator needs to make a choice between the automatic ID
assignment and the specific assignment for all dynamic data services, as a mix between
both is not recommended.
When the automatic assignment is chosen, there is no binding/memory of a service ID
to a provisioned service, which means a service that may have service ID xyz initially
may get another service ID the next time it comes up. In other words, as soon as a service
is disconnected, the service ID is freed up for the next activated service.

dyn.get_sap()
This function returns the value of the evaluation of the Alc-Dyn-Serv-SAP-Id attribute
as a string. Wildcards (#) in the Alc-Dyn-Serv-SAP-Id are replaced with the
corresponding port/vlan information of the control channel SAP-ID. So if, for example,
the Alc-Dyn-Serv-SAP-Id contains #:#.1 and the control channel SAP ID is 1/1/
5:100.100, the resulting SAP for the data service would be 1/1/5:100.1.

dyn.get_circuit_id()
This function returns a string which is equal to the Control Channel Circuit-ID (from the
DHCP relay agent option 82 or PPP tags). This function may be useful, for example, to
use the circuit id in the SAP description.

dyn.get_remote_id()
This function returns a string which is equal to the Control Channel Remote-ID (from the
DHCP relay agent option 82 or PPP tags). This function may be useful, for example, to
use the remote id in the SAP description.

Advanced Configuration Guide

Page 1751

Configuration

In addition to the RADIUS dictionary, the node will also store service-related parameters in a
service-specific dictionary. The information in the RADIUS messages or in the stored dictionary
are used for the various functions as outlined in Table 29:

Table 29: Function and Dictionary Relationship


Function Name

Input

Returns

setup dynsvc(rd*)

rd: radius dictionary in the parameter


list in Alc-Dyn-Serv-Script-Params.
VSA Passed to setup function.

A dictionary that will be stored for the


lifetime of the dynamic service (sd).

modify_dynsvc(rd,sd**)

rd: radius dictionary in the parameter


list in Alc-Dyn-Serv-Script-Params.
VSA passed to modify function.
sd: previously stored dictionary of the
setup/previous modify functions.

Updated stored dictionary (sd)

revert_dynsvc(rd, sd)

rd: radius dictionary in the parameter


list in Alc-Dyn-Serv-Script-Params.
VSA passed to revert function.
sd: previously stored dictionary of the
setup/previous modify function.

The function does not return (store)


any information. The previously
stored dictionary (sd) is kept.

teardown_dynsvc(sd)

sd: previously stored dictionary by


the setup function or a previous
modify function are passed to the
teardown function.

The function does not return (store)


any information. The stored
dictionary (sd) is deleted.

(*) rd = radius dictionary


(**) sd = stored dictionary. sd is required for modifies, reverts and teardowns.

Page 1752

Advanced Configuration Guide

RADIUS-Triggered Dynamic Data Service Provision-

Building Block: CLI Snippets


Building Block: CLI Snippets

The necessary functional parts of a service configuration cannot typically be put into one large
script (one single actionable function). This is best described with a small and simple example:
Imagine a single script where the setup action creates both the service instance and the SAP, and
the teardown action removes the service instance and the SAP. For a service with just one SAP per
service instance this may work fine, however, in a multi SAP service like a VPLS this will cause
problems, especially during the service teardown action. This is because if multiple SAPs have
been instantiated in a single service, the disconnect of just one SAP would trigger the teardown
action which would try to remove the SAP (still ok) but then would try to remove the service
instance. This action would fail as other SAPs still exist in the service. As such the script
execution would fail.
It is therefore necessary to structure the whole required configuration into individual actionable
pieces which are referenced by each other with specific reference-IDs. Those actionable pieces are
called snippets.
Referenced snippets may or may not be executed depending on whether the functional instance
exists already or not. As shown on the left of the picture below, the action to create a SAP
references the creation of a service and then to the creation of a customer. For the very first
business site to come up all three snippets will be executed. For any further business site to come
up in the same service the script to create the SAP will be executed, the referenced service script
and subsequently the customer script will not be executed again as those instances already exist.
The same logic applies during the teardown action. Only when the last SAP in a service is
removed is the service-instance itself removed, and potentially also the customer (unless it too is
associated with other services).

Advanced Configuration Guide

Page 1753

Configuration

setup_A

setup_A
Interface/
SAP

snippet A

Allowed since
reference to
different functions
can have same
reference-ids

id1

snippet A

id1

id2

L1

L1

id1
L1
setup_B

id1
setup_B
Service

Ref
count

Ref
count

L1

L1

snippet B

Allowed since
reference to
same function
have different
reference-ids

snippet B

Not allowed since


references to the
same function
must have different
reference-ids

setup_E
Ref
count

id1
snippet E

L2
setup_C

id1

id1

Ref
count

L2

snippet C

setup_C
Customer

Ref
count

id1
snippet C

Only 2
sequential dynamic
references allowed
(3 hierarchy levels)

L3
setup_D
L2

Ref
count

snippet D

dynamic reference
id1

reference id1

L1 level 1
invalid
dynamic reference
al_0289

Figure 176: Hierarchy of Snippets

The implementation supports a three level hierarchy of snippets for high flexibility as shown in the
picture. A reference to the fourth level as shown on the right side would result in an error.
Furthermore, snippets can be scaled horizontally, so from one level multiple references to other
snippets are possible. An example for that would be the creation of a SAP triggers the creation of
a service as well as the creation of an Ethernet CFM association for that SAP.
Identifiers are needed for the referencing. The same identifier can be used on the horizontal
level, but not on the vertical level between the same pair of snippets, also shown above.
Snippets are heavily used in the service examples in Bringing it all together on page 1756 where
the logic and the referencing are described with real data.
Building Block: RADIUS Accounting
As dynamic data services are instantiated through RADIUS, it is also typically required to provide
feedback to the RADIUS server for service establishment and teardown. This is achieved via
RADIUS accounting records for the dynamic data channels in addition to the accounting messages
for the PPP or DHCP control channel.

Page 1754

Advanced Configuration Guide

RADIUS-Triggered Dynamic Data Service Provision-

Up to two dedicated accounting destinations can be defined within the dynamic services policy.
Thus, the accounting for the dynamic data services can be handled by an independent set of
accounting servers (from the accounting for general ESM subscribers). But the same servers can
also be used.
Each dynamic data service has its own accounting start/stop/interim messages based on a unique
accounting session ID. In addition, the accounting packets contain a multi-session ID which is
identical to the accounting session ID of the control channel and is therefore displayed in show
commands as Acct-Session-ID-Ctrl as shown below.
A:BNG-1# show service dynamic-services saps summary
===============================================================================
Dynamic Services SAP's summary
===============================================================================
SAP
Acct-Session-ID
Acct-Session-ID-Ctrl
------------------------------------------------------------------------------3/2/1:4.3
D6E559000000B951668AEB D6E559000000B851668AEB
3/2/2:1.1
D6E559000000C75166CFF4 D6E559000000C45166CFF4
3/2/2:1.2
D6E559000000C85166CFF4 D6E559000000C45166CFF4
3/2/2:1.3
D6E559000000C95166CFF4 D6E559000000C45166CFF4
3/2/2:1.4
D6E559000000CA5166CFF4 D6E559000000C45166CFF4
------------------------------------------------------------------------------No. of SAP's: 5
===============================================================================

The Accounting Session ID (in the centre above) is the one for the dynamic data service itself, the
one on the right is from the control-channel. The above example clearly shows that the last 4
dynamic services all belong to the same control channel, as they all have the same Acct-SessionID-Ctrl.
If the accounting stats-type is set to volume-time, the interim and stop accounting messages will
also contain counters for the data traffic through the service. With the accounting stats-type
time, no counters are included, only session time is reported.
As a dynamic data service is functionally no different from a regular data service, traffic volumes
can also be gathered by assigning accounting policies within the service for file-based XML
accounting.

Advanced Configuration Guide

Page 1755

Configuration

Bringing it all together


Bringing it all together

This section gives examples of all of the above parameters and will also cover show, log and
debug information.
In the given example, a single user in the database has four different associated data services. Not
only are the data service types all different, but also other aspects of the parameter set, this has an
effect on how the data is entered in the RADIUS VSAs and how the Python script is constructed.
More detail is given below. The different models for specifying parameters are presented to show
the flexibility. An operator typically chooses a single model and uses that for all its services.
As all of the information for these four services will potentially be sent in one RADIUS message,
the VSAs need to be tagged so that the BNG can link the appropriate VSAs to each other and
differentiate the services. For better visibility, the different sections in the RADIUS users file are
displayed with bold black and dark grey text.
The freeradius users file format is used for this example.

Page 1756

Advanced Configuration Guide

RADIUS-Triggered Dynamic Data Service Provision-

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.

"subscriber12@domain2.com" Cleartext-Password := "ALU"


Alc-Subsc-ID-Str := "pppoe-user12",
Framed-IP-Address = 10.2.1.200,
Alc-Dyn-Serv-SAP-Id:1 = "#:#.1",
Alc-Dyn-Serv-Script-Params:1 = "business_epipe={'t':('EPipeCustomerName','CustomerName-Circuit-1','3','3','64496',
'192.0.2.5','192.0.2.1','3333')}",
Alc-Dyn-Serv-Policy:1 = "dynamic-services-2",
Alc-Dyn-Serv-SAP-Id:2 += "#:#.2",
Alc-Dyn-Serv-Script-Params:2 += "business_vprn={'t':('9999',
'VPRN-CustomerName','64497','100000','CustomerName-Circuit1','172.16.10.1/30','3','1','3','2','172.16.100.0/24',
'172.16.10.2','100')}",
Alc-Dyn-Serv-Acct-Interim-Ivl-1:2 += "600",
Alc-Dyn-Serv-Acct-Interim-Ivl-2:2 += "0",
Alc-Dyn-Serv-Policy:2 += "dynamic-services-2",
Alc-Dyn-Serv-SAP-Id:3 += "#:#.3",
Alc-Dyn-Serv-Script-Params:3 += "business_vpls={'inst':
'VPLS-CustomerName','if_name':'CustomerName-Circuit-1','ing_qos':'3',
'egr_qos':'3','imp_comm_val':'10000','exp_comm_val':'10000',
'rt':'64498','rd':'64498'}",
Alc-Dyn-Serv-Policy:3 += "dynamic-services-2",
Alc-Dyn-Serv-Acct-Interim-Ivl-1:3 += "0",
Alc-Dyn-Serv-Acct-Interim-Ivl-2:3 += "0",
Alc-Dyn-Serv-Acct-Stats-Type-1:3 += off,
Alc-Dyn-Serv-Acct-Stats-Type-2:3 += off,
Alc-Dyn-Serv-SAP-Id:4 += "#:#.4",
Alc-Dyn-Serv-Script-Params:4 += "business_ies={'t':
('IES-CustomerName','CustomerName-Circuit-1','172.16.11.1/30',
'2001:db8:5100:1000::1/64','5','1','1','6','2','2','5','25',
'cfm-Mep-to-CPE','100',",
Alc-Dyn-Serv-Script-Params:4 += "[{'to':'172.16.110.0/24',
'n-h':'172.16.11.2'},{'to':'2001:db8:bbbb::/56',
'n-h':'2001:db8:5100:1000::2'}])}",
Alc-Dyn-Serv-Policy:4 += "dynamic-services-2",
Alc-Dyn-Serv-Acct-Interim-Ivl-1:4 += "600",
Alc-Dyn-Serv-Acct-Interim-Ivl-2:4 += "0",
Alc-Dyn-Serv-Acct-Stats-Type-1:4 += "3",
Alc-Dyn-Serv-Acct-Stats-Type-2:4 += "2",

The first section (lines 1 3) shows a minimal parameter set for the (PPP) control channel. As
the focus of this example is on the dynamic data services, all default parameters will be used for
the control-session which are defined under the msap.
The second section (lines 4 8, attributes with tag :1) shows a possible parameter set for an
Epipe service. Only the absolutely minimum set of VSAs is used (see Table 27, Dynamic Service
Attribute List for Setup, Modify and Teardown, on page 1748). Furthermore, all service
parameters are listed without keywords in a pre-defined order. No service ID number is specified
in Alc-Dyn-Serv-Script-Params, hence the Python script should dynamically select the next free
ID.

Advanced Configuration Guide

Page 1757

Configuration

The third section (lines 9 16, attributes with tag :2) shows a possible parameter set for a
VPRN service. A few more VSAs are defined, thus some of the default parameters in the dynamic
service policy are overwritten for this service. The first entry in the Alc-Dyn-Serv-ScriptParams attribute specifies the Service-ID number for this service, so the Python script should not
select a service ID automatically. Furthermore, static-routing information towards the CPE is
added as normal attributes at the end of the list.
The fourth section (line 17 26, attributes with tag :3) shows a possible parameter set for a
VPLS service. Notice the difference with the first two services in the Alc-Dyn-Serv-ScriptParams part: now all parameters are given their specific keyword. As such, the sequence of those
parameters is not important. The effect on the Python script is shown further down.
The fifth section (lines 27 39, attributes with tag :4) finally shows a possible parameter set
for an IES service. All of the required parameters for this service do not fit into a single Alc-DynServ-Script-Params attribute anymore (limited to 247 bytes). As is shown, multiple VSAs can be
concatenated by simply splitting the attributes. It is important that the order in which the
different Alc-Dyn-Serv-Script-Params attributes with the same tag is received can be
guaranteed. Furthermore the second appearance of this VSA shows a different way of
provisioning static-routing information towards the CPE.
To better understand the details it is necessary to take a closer look into the active Python script.
The first important part is the section with the dynamic actions.
-snipd = {
"vprn": (setup_vprn, None, None, teardown_vprn),
"ies": (setup_ies, None, None, teardown_ies),
"vpls": (setup_vpls, None, None, teardown_vpls),
"epipe": (setup_epipe, None, None, teardown_epipe),
"ethcfm" : (setup_ethcfm_domain, None, None, teardown_ethcfm_domain),
"business_vprn" : (setup_business_vprn, None, None, teardown_business_vprn),
"business_ies" : (setup_business_ies, None, None, teardown_business_ies),
"business_vpls" : (setup_business_vpls, None, None, teardown_business_vpls),
"business_epipe" : (setup_business_epipe, modify_business_epipe,
revert_business_epipe, teardown_business_epipe)}
dyn.action(d)

The function-key string specified at the start of the Alc-Dyn-Serv-Script-Params (for example
Alc-Dyn-Serv-Script-Params:1 = business_epipe={}) has a 1:1 mapping with the keys of the
dictionary d in the highlighted section of the above sample (for example d = { ,
"business_epipe" : ()}. For services, different values for setup, modify, revert and teardown are
given which point to other sections in the Python script (see below). Setup and teardown functions
are mandatory, whereas modify and revert functions are optional.
In the unbolded text of the previous example, there are other actions defined that are not contained
in the RADIUS attributes (for example d = { "vprn": () , ). Those actions are referenced by
the four main functions.

Page 1758

Advanced Configuration Guide

RADIUS-Triggered Dynamic Data Service Provision-

In the next part, there is more detail presented in each service example and maps it to the
corresponding Python function.
It is advisable to read through all examples, as only the deltas between each service are explicitly
explained.
Example 1 Epipe service
# copy of the RADIUS attributes from above
-snipAlc-Dyn-Serv-SAP-Id:1 = "#:#.1",
Alc-Dyn-Serv-Script-Params:1 = "business_epipe={'t':
('EPipe-CustomerName','CustomerName-Circuit-1','3','3','64496'
,'192.0.2.5','192.0.2.1','3333')}",
Alc-Dyn-Serv-Policy:1 = "dynamic-services-2",
-snip# Python-part
d = {
-snip"business_epipe" : (setup_business_epipe, modify_business_epipe,
revert_business_epipe, teardown_business_epipe)
dyn.action(d)
-snipdef setup_business_epipe(d):
keys = ('inst', 'if_name', 'ing_qos', 'egr_qos', 'as', 'remote_ip',
'local_ip', 'glb_svc_id')
d = dict(zip(keys, d['t']))
ref_d = dyn.reference("epipe", d['inst'], d)
d['svc_id'] = ref_d['svc_id']
d['sap_id'] = dyn.get_sap()
dyn.add_cli("""
configure
service
epipe %(svc_id)s
sap %(sap_id)s create
description "%(if_name)s"
ingress
qos %(ing_qos)s
exit
egress
qos %(egr_qos)s
exit
exit
spoke-sdp-fec %(svc_id)s fec 129 aii-type 2 create
pw-template-bind 2
saii-type2 %(as)s:%(local_ip)s:%(glb_svc_id)s
taii-type2 %(as)s:%(remote_ip)s:%(glb_svc_id)s
no shutdown
exit
exit
exit
exit
""" % d)
return d
def setup_epipe(d):

Advanced Configuration Guide

Page 1759

Configuration

d['svc_id'] = dyn.select_free_id("service-id")
dyn.add_cli("""
configure
service
epipe %(svc_id)s customer 1 create
service-name "%(inst)s"
description "%(inst)s"
no shutdown
exit
exit
exit
""" % d)
return {'svc_id':d['svc_id']}
def teardown_epipe(d):
dyn.add_cli("""
configure
service
epipe %(svc_id)s
shutdown
exit
no epipe %(svc_id)s
exit
exit
""" % d)
def teardown_business_epipe(d):
dyn.add_cli("""
configure
service
epipe %(svc_id)s
sap %(sap_id)s
shutdown
exit
spoke-sdp-fec %(svc_id)s
shutdown
exit
no sap %(sap_id)s
no spoke-sdp-fec %(svc_id)s
exit
exit
exit
""" % d)
-snip-

Based on the dictionary specified in the dyn.action(d) call, the function definition
setup_business_epipe in the Python script corresponds with the function that will be called if the
function-key business-epipe is specified in the Alc-Dyn-Serv-Script-Params attribute as
dictionary name and if a setup action is required. The dictionary containing the parameters in the
RADIUS VSA Alc-Dyn-Serv-Script-Params has a single key-value pair, with the parameters
stored in a tuple. The individual parameters cannot be identified with a keyword hence the order in
which they are specified in the RADIUS VSA should match the order in which they are extracted
in the Python script. The first two lines in this part of the script extract the parameters out of the
array t and link them to unique keywords, which are used for the rest of the script.

Page 1760

Advanced Configuration Guide

RADIUS-Triggered Dynamic Data Service Provision-

The parameter inst is important in this logic, as it defines whether access circuits belong to the
same service-instance or different instances (the RADIUS VSAs for two SAPs belonging to the
same service therefore need to have the same inst value). If you look at the CLI of the
setup_business_epipe function, you can see that it creates the SAP and all related attributes, but
not the service itself. It is the ref_d = dyn.reference("epipe", d['inst'], d) that references a part in
the script to create the actual service-instance. The referenced function is found by using the first
parameter in the dyn.reference call (epipe) as a function-key lookup in the dictionary specified
in the dyn.action(d) and finding the corresponding setup function: d = { , "epipe" : (setup_epipe,
), }. The second parameter (d['inst']) is used as unique identification of the service
instance. The last parameter (d) is a dictionary with parameters that can be used by the
references function. When the first customer endpoint with a new inst name comes up, the
service itself gets created.
By looking at def setup_epipe(d): the first line d['svc_id'] = dyn.select_free_id("service-id")
of the script automatically picks a free service-id out of the range defined in the dynamic service
policy, as no service ID was provided in the RADIUS parameters. The rest of this function creates
the service instance. Service attributes that were provided by RADIUS and are placed in a service
specific dictionary are available to this function via the third parameter in the dyn.reference call.
The newly generated service ID is returned to the calling script by the return
{'svc_id':d['svc_id']} command at the end of the function. The service specific dictionary (as
explained in the Python Script Building Block) is updated with the appropriate information.
Back to def setup_business_epipe(d):, the service ID together with the SAP ID and the
parameters from the Alc-Dyn-Serv-Script-Params VSA are used to create the appropriate CLI
code for the SAP and the SDP within the service.
Similar to the setup, there is also a teardown part for both service and SAP. The teardown function
is called either through the termination of the control-channel, through a COA with Alc-DynScript-Action = teardown or through a disconnect message. The CLI for the teardown script must
be written in the correct sequence as applied by the SR OS CLI logic so that SAP(s) and service(s)
are removed in the correct order.
Example 2 VPRN service
RADIUS-part from above
-snipAlc-Dyn-Serv-SAP-Id:2 += "#:#.2",
Alc-Dyn-Serv-Script-Params:2 += "business_vprn={'t':
('9999','VPRN-CustomerName','64497','100000',
'CustomerName-Circuit-1','172.16.10.1/30','3','1','3','2',
'172.16.100.0/24','172.16.10.2','100')}",
Alc-Dyn-Serv-Acct-Interim-Ivl-1:2 += "600",
Alc-Dyn-Serv-Acct-Interim-Ivl-2:2 += "0",
Alc-Dyn-Serv-Policy:2 += "dynamic-services-2",
-snipPython-part
d = {
-snip"business_vprn" : (setup_business_vprn, None, None, teardown_business_vprn)

Advanced Configuration Guide

Page 1761

Configuration

dyn.action(d)
-snipdef setup_business_vprn(d):
keys = ('svc_id', 'inst', 'as_id', 'comm_id', 'if_name', 'ipv4_address',
'ing_qos', 'ing_ip_filter', 'egr_qos', 'egr_ip_filter', 'lan_pfx',
'nxt_hop', 'metric')
d = dict(zip(keys, d['t']))
ref_d = dyn.reference("vprn", d['inst'], d)
d['sap_id'] = dyn.get_sap()
dyn.add_cli("""
configure
service
vprn %(svc_id)s
interface "%(if_name)s" create
address %(ipv4_address)s
urpf-check mode strict
sap %(sap_id)s create
ingress
qos %(ing_qos)s
filter ip %(ing_ip_filter)s
exit
egress
qos %(egr_qos)s
filter ip %(egr_ip_filter)s
exit
exit
exit
exit
exit
router
static-route %(lan_pfx)s next-hop %(nxt_hop)s metric %(metric)s
exit
exit
""" % d)
return d
def setup_vprn(d):
dyn.add_cli("""
configure
service
vprn %(svc_id)s customer 1 create
service-name "%(inst)s"
description "%(inst)s"
autonomous-system %(as_id)s
route-distinguisher %(as_id)s:%(comm_id)s
auto-bind mpls
vrf-target target:%(as_id)s:%(comm_id)s
no shutdown
exit
exit
exit
""" % d)
return {'svc_id':d['svc_id']}
def teardown_vprn(d):
dyn.add_cli("""
configure
service
vprn %(svc_id)s

Page 1762

Advanced Configuration Guide

RADIUS-Triggered Dynamic Data Service Provision-

shutdown
exit
no vprn %(svc_id)s
exit
exit
""" % d)
def teardown_business_vprn(d):
dyn.add_cli("""
configure
router
no static-route %(lan_pfx)s next-hop %(nxt_hop)s
exit
service
vprn %(svc_id)s
interface "%(if_name)s"
sap %(sap_id)s
shutdown
exit
no sap %(sap_id)s
shutdown
exit
no interface "%(if_name)s"
exit
exit
exit
""" % d)
-snip-

In this example of a VPRN service two additional RADIUS VSAs are used to overwrite the
accounting interim update intervals for the two RADIUS Accounting servers that are specified in
the dynamic services policy. The Stats-Type configuration (time or volume-time) is obtained from
the dynamic services policy as no RADIUS VSA is provided for that.
The beginning of the setup_business_vprn definition is identical to the earlier Epipe service
example. This time a service identifier is provided as part of the parameter list. The referenced
function to create the VPRN service (def setup_vprn) does not need the line to auto-generate the
service ID.
At the end of the setup-procedure there is a basic example to add static-route information in case
they are needed for PE-CE communication. Later on, in the IES service example, a more flexible
alternative is shown.

Example 3 VPLS service


RADIUS-part from above
-snipAlc-Dyn-Serv-SAP-Id:3 += "#:#.3",
Alc-Dyn-Serv-Script-Params:3 += "business_vpls={'inst':
'VPLS-CustomerName','if_name':'CustomerName-Circuit-1','ing_qos':'3',
'egr_qos':'3','imp_comm_val':'10000','exp_comm_val':'10000',
'rt':'64498','rd':'64498'}",

Advanced Configuration Guide

Page 1763

Configuration

Alc-Dyn-Serv-Policy:3 += "dynamic-services-2",
Alc-Dyn-Serv-Acct-Interim-Ivl-1:3 += "0",
Alc-Dyn-Serv-Acct-Interim-Ivl-2:3 += "0",
Alc-Dyn-Serv-Acct-Stats-Type-1:3 += off,
Alc-Dyn-Serv-Acct-Stats-Type-2:3 += off,
-snipPython-part
d = {
-snip"business_vpls" : (setup_business_vpls, None, None, teardown_business_vpls)
-snipdef setup_business_vpls(d):
ref_d = dyn.reference("vpls", d['inst'], d)
d['svc_id'] = ref_d['svc_id']
d['sap_id'] = dyn.get_sap()
dyn.add_cli("""
configure
service
vpls %(svc_id)s
sap %(sap_id)s create
description "%(if_name)s"
ingress
qos %(ing_qos)s
exit
egress
qos %(egr_qos)s
exit
collect-stats
accounting-policy 10
exit
exit
exit
exit
""" % d)
return d
def setup_vpls(d):
d['svc_id'] = dyn.select_free_id("service-id")
dyn.add_cli("""
configure
service
vpls %(svc_id)s customer 1 create
service-name "%(inst)s"
description "%(inst)s"
bgp
route-distinguisher %(rd)s:%(exp_comm_val)s
route-target export target:%(rt)s:%(exp_comm_val)s
import target:%(rt)s:%(imp_comm_val)s
pw-template-binding 1
exit
exit
bgp-ad
vpls-id %(rt)s:%(exp_comm_val)s
no shutdown
exit
no shutdown
exit
exit

Page 1764

Advanced Configuration Guide

RADIUS-Triggered Dynamic Data Service Provision-

exit
""" % d)
return {'svc_id':d['svc_id']}
def teardown_vpls(d):
dyn.add_cli("""
configure
service
vpls %(svc_id)s
shutdown
bgp-ad
shutdown
exit
no bgp-ad
bgp
no pw-template-binding 1
exit
exit
no vpls %(svc_id)s
exit
exit
""" % d)
def teardown_business_vpls(d):
dyn.add_cli("""
configure
service
vpls %(svc_id)s
sap %(sap_id)s
shutdown
exit
no sap %(sap_id)s
exit
exit
exit
""" % d)
-snip-

In the VPLS example the Alc-Dyn-Serv-Acct-Stats-Type is set to off for both RADIUS
accounting destinations, meaning RADIUS accounting is switched off, even if it is enabled in the
dynamic data services policy. In the script you can see that this service uses XML-accounting on
the SAP instead (collect-stats and accounting-policy 10).
The dictionary containing the parameters in the RADIUS VSA Alc-Dyn-Serv-Script-Params
has a key-value pair for each parameter. In the Python script the individual parameters can be
identified immediately with the dictionary key. The order in which they are specified in the
RADIUS VSA does not have to be strictly defined. The drawback of this approach is that the
length of the parameter VSA increases. A single parameter VSA is limited to a length of 246 bytes
and the total length of all parameter VSAs for a single service is limited to 1000 bytes.
Example 4 IES service
RADIUS-part from above
-snip-

Advanced Configuration Guide

Page 1765

Configuration

Alc-Dyn-Serv-SAP-Id:4 += "#:#.4",
Alc-Dyn-Serv-Script-Params:4 += "business_ies={'t':
('IES-CustomerName','CustomerName-Circuit-1','172.16.11.1/30',
'2001:db8:5100:1000::1/64','5','1','1','6','2','2','5','25',
'cfm-Mep-to-CPE','100',",
Alc-Dyn-Serv-Script-Params:4 += "[{'to':'172.16.110.0/24',
'n-h':'172.16.11.2'},{'to':'2001:db8:bbbb::/56',
'n-h':'2001:db8:5100:1000::2'}])}",
Alc-Dyn-Serv-Policy:4 += "dynamic-services-2",
Alc-Dyn-Serv-Acct-Interim-Ivl-1:4 += "600",
Alc-Dyn-Serv-Acct-Interim-Ivl-2:4 += "0",
Alc-Dyn-Serv-Acct-Stats-Type-1:4 += "3",
Alc-Dyn-Serv-Acct-Stats-Type-2:4 += "2",
-snipPython-part
d = {
-snip"business_ies" : (setup_business_ies, None, None, teardown_business_ies)
-snipdef setup_business_ies(d):
keys = ('inst', 'if_name', 'ipv4_address', 'ipv6_address', 'ing_qos',
'ing_ip_filter', 'ing_ipv6_filter', 'egr_qos', 'egr_ip_filter',
'egr_ipv6_filter', 'ing_bw', 'egr_bw', 'cfm_assoc_id', 'metric',
'routes')
d = dict(zip(keys, d['t']))
ref_d = dyn.reference("ies", d['inst'], d)
d['svc_id'] = ref_d['svc_id']
d['sap_id'] = dyn.get_sap()
d['cfm_domain'] = 1
ref_d_cfm = dyn.reference("ethcfm", str(d['cfm_domain']), d)
dyn.add_cli("""
configure
eth-cfm
domain %(cfm_domain)s
association %(svc_id)s format string name "%(cfm_assoc_id)s"
bridge-identifier %(svc_id)s
exit
ccm-interval 1
remote-mepid 2
exit
exit
exit
service
ies %(svc_id)s
interface "%(if_name)s" create
address %(ipv4_address)s
urpf-check mode strict
cflowd interface both
ipv6
address %(ipv6_address)s
urpf-check mode strict
exit
sap %(sap_id)s create
description "%(if_name)s"
ingress
scheduler-policy "Business Services"
scheduler-override
scheduler "root-t1" create

Page 1766

Advanced Configuration Guide

RADIUS-Triggered Dynamic Data Service Provision-

rate %(ing_bw)s000
exit
exit
qos %(ing_qos)s
filter ip %(ing_ip_filter)s
filter ipv6 %(ing_ipv6_filter)s
exit
egress
qos %(egr_qos)s
filter ip %(egr_ip_filter)s
filter ipv6 %(egr_ip_filter)s
agg-rate-limit %(egr_bw)s000 queue-frame-based-accounting
exit
collect-stats
accounting-policy 10
eth-cfm
mep 1 domain %(cfm_domain)s association %(svc_id)s direction down
ccm-enable
no shutdown
exit
exit
exit
urpf-check
exit
exit
exit
exit
router
""" % d)
for route in d['routes']:
dyn.add_cli("""
static-route %s next-hop %s metric %s tag 80
"""% (route["to"], route["n-h"], d['metric']))
dyn.add_cli("""
exit
exit
""" % d)
return d
def setup_ies(d):
d['svc_id'] = dyn.select_free_id("service-id")
dyn.add_cli("""
configure
service
ies %(svc_id)s customer 1 create
service-name "%(inst)s"
description "%(inst)s"
no shutdown
exit
exit
exit
""" % d)
return {'svc_id':d['svc_id']}
def setup_ethcfm_domain(d):
dyn.add_cli("""
configure
eth-cfm
domain %(cfm_domain)s format none level 1

Advanced Configuration Guide

Page 1767

Configuration

exit
exit
exit
""" % d)
return {'cfm_domain':d['cfm_domain']}
def teardown_ethcfm_domain(d):
dyn.add_cli("""
configure
eth-cfm
no domain %(cfm_domain)s
exit
exit
""" % d)
def teardown_ies(d):
dyn.add_cli("""
configure
service
ies %(svc_id)s
shutdown
exit
no ies %(svc_id)s
exit
exit
""" % d)
def teardown_business_ies(d):
dyn.add_cli("""
configure
router
""")
for route in d['routes']:
dyn.add_cli("""
no static-route %s next-hop %s
"""% (route["to"], route["n-h"]))
dyn.add_cli("""
exit
exit
""")
dyn.add_cli("""
configure
service
ies %(svc_id)s
interface "%(if_name)s"
sap %(sap_id)s
shutdown
eth-cfm
mep 1 domain %(cfm_domain)s association %(svc_id)s
shutdown
exit
no mep 1 domain %(cfm_domain)s association %(svc_id)s
exit
exit
no sap %(sap_id)s
shutdown
exit
no interface "%(if_name)s"
exit

Page 1768

Advanced Configuration Guide

RADIUS-Triggered Dynamic Data Service Provision-

exit
eth-cfm
domain %(cfm_domain)s
association %(svc_id)s
no bridge-identifier %(svc_id)s
exit
no association %(svc_id)s
exit
exit
exit
""" % d)
-snip-

The IES example has the most attributes. The maximum length of a tagged RADIUS VSA is 246
bytes. If the amount of data is too big to fit into one attribute, simply add a second or third one in
the syntax shown above in the RADIUS part. There is no need to separate the attributes exactly at
246 bytes; it can be cut at any position in the list (preferably between two attributes for better
readability). Note also that all the parameter VSAs that belong to the same service should have the
same tag (:4 in this example).
In case of multiple parameter VSAs, the order in which they are specified is important and must be
guaranteed as the concatenation of all the attributes must result in a Python dictionary in the form:
dictionary-name = {}. The Python script is not aware that multiple attributes were used.
Another difference to the previous examples is that there is not only a reference to the function for
the service creation, but also a similar reference to a function for Ethernet Connectivity Fault
Management (CFM). Considering that you may want to put all of the Eth-CFM endpoints under
the same domain within unique associations, the Eth-CFM domain needs to be created first and
torn down as last.
Finally, a different way to provide static-route information is shown at the end of the
setup_business_ies definition (starting with for route in d['routes']:). Also note the difference
in how this information is implemented at the end of the Alc-Dyn-Serv-Script-Params list. The
static routes themselves are defined as a dictionary and thus as many routes as required can be
added with this method. Compare this to the VPRN example where a more basic mechanism was
used.
As outlined before, dynamic data services can be triggered during the Access-Accept for the
control channel but also through a CoA to the control channel Accounting Session ID.

Example 5 modify an Epipe service using CoA


So far the focus was on service establishment and teardown. It is also possible to change a running
dynamic data service using the modify function. This will be explained with the previously
configured Epipe service.
RADIUS attributes in the COA message

Advanced Configuration Guide

Page 1769

Configuration

Acct-Session-Id = D6E559000000BD5166BF34 #
Alc-Dyn-Serv-SAP-Id:1 = "#:#.1",
Alc-Dyn-Serv-Script-Params:1 = "business_epipe={'ing_qos':'4','egr_qos':'4'}",
Alc-Dyn-Serv-Script-Action:1 = modify,
Alc-Dyn-Serv-Policy:1 = "dynamic-services-2",

Python-part
d = {
-snip"business_epipe" : (setup_business_epipe, modify_business_epipe, revert_business_epipe,
teardown_business_epipe)}
dyn.action(d)
-snipdef modify_business_epipe(d, sd):
sd['ing_qos'] = d['ing_qos']
sd['egr_qos'] = d['egr_qos']
dyn.add_cli("""
configure
service
epipe %(svc_id)s
sap %(sap_id)s
ingress
qos %(ing_qos)s
exit
egress
qos %(egr_qos)s
exit
exit
exit
exit
exit
"""% sd)
return sd
def revert_business_epipe(d, sd):
dyn.add_cli("""
configure
service
epipe %(svc_id)s
sap %(sap_id)s
ingress
qos %(ing_qos)s
exit
egress
qos %(egr_qos)s
exit
exit
exit
exit
exit
""" % sd)
-snip-

Through the function-key in the parameter list (Alc-Dyn-Serv-Script-Params:1 =


"business_epipe= ) and the action attribute of modify (Alc-Dyn-Serv-Script-Action:1 =
modify), the script will identify the relevant routine to be invoked for the modification

Page 1770

Advanced Configuration Guide

RADIUS-Triggered Dynamic Data Service Provision-

(modify_business_epipe). If a modify function is defined, there must also be a definition for a


revert function. A revert function cannot be initiated from RADIUS, but it is automatically
executed to restore the initial configuration in case the modify script execution fails.
A modify action for an existing service is triggered with a CoA message. For this CoA, either the
Accounting Session ID (ASID) of the control channel or the Accounting Session ID of the
dynamic data channel can be used. In case the ASID of the control channel is used, the Alc-DynServ-SAP-Id can contain wildcards, as the appropriate port and VLAN information will be taken
from the control channel. If the ASID of the dynamic data channel itself is used, the Alc-DynServ-SAP-Id needs to be fully specified, without wildcards. Otherwise the script execution will
fail.
For a modify action, the Alc-Dyn-Serv-Script-Params only contains the parameters to be
changed and does not need any further service identifying information. The service is identified
based on the ASID and the Alc-Dyn-Serv-SAP-Id. Parameters which have been previously
received by the setup or an earlier modify function are available in the stored dictionary (sd).
Those are combined with the dictionary in the RADIUS message (d). Service modifications which
relate to subsequent modifications, or for the service teardown, need to be updated in the stored
dictionary so that they can be used in those later actions. This is achieved by the return sd
command.
As with manual provisioned services, the new QoS settings from our example take effect
immediately.
A dynamic data service can also be disconnected using a RADIUS Disconnect Message
containing the Accounting Session ID of the dynamic data service, or indirectly via a RADIUS
Disconnect Message containing the Accounting Session ID of the control channel which would
result in a teardown of all associated dynamic data services.
Debugging
It is obvious that the Python scripts need extensive testing in the lab before they are deployed in
the field. This testing may require a number of iterations: write the script, testing, verification,
improvement and testing again. Every time there is a change in the Python script the node needs to
reload the script. This is achieved by a shutdown and no shutdown of the active script using the
command:
configure aaa radius-script-policy <script-policy-name> <primary/secondary> shutdown
configure aaa radius-script-policy <script-policy-name> <primary/secondary> no shutdown
Testing the script may result in some problems if certain aspects may not work as expected (see
also debug functions later in this section). It can be that a dynamically created service cannot be
removed properly because the teardown script contains errors and the whole service, or fragments
of that service, may still exist on the node.
Dynamic data services cannot be edited in normal CLI mode as it may potentially make a later
removal of that service through the script impossible. For troubleshooting there is a procedure to

Advanced Configuration Guide

Page 1771

Configuration

manipulate those services during the testing phase, thus avoiding the need to reboot the box to
clear the state. The enable-dynamic-services-config command allows for the editing dynamic
services just like normal services. As this is an action that should only be executed by authorized
personnel, the activation of this command is protected by the use of a password, defined under
configure system security password dynsvc-password.
The show users command has been extended to visualize the respective mode ('D' indicates a user
is in dynamic service edit mode). A user in dynamic services edit mode cannot modify regular
services.
no enable-dynamic-services-config returns the user to normal mode.
To support the creation and the troubleshooting during the test phase the SR OS debug functions
have been extended extensively to allow for a detailed review of what is happening in the script
and on the CLI.
debug
debug
debug
debug
debug
debug
debug
debug
debug
debug
debug
debug
debug
debug
debug
debug
debug
debug
debug
debug
debug
debug

dynamic-services
dynamic-services
dynamic-services
dynamic-services
dynamic-services
dynamic-services
dynamic-services
dynamic-services
dynamic-services
dynamic-services
dynamic-services
dynamic-services
dynamic-services
dynamic-services
dynamic-services
dynamic-services
dynamic-services
dynamic-services
dynamic-services
dynamic-services
dynamic-services
dynamic-services

scripts
scripts
scripts
scripts
scripts
scripts
scripts
scripts
scripts
scripts
scripts
scripts
scripts
scripts
scripts
scripts
scripts
scripts
scripts
scripts
scripts

event
event cli
event errors
event executed-cmd
event state-change
event warnings
instance
instance event
instance event cli
instance event errors
instance event executed-cmd
instance event state-change
instance event warnings
script
script event
script event cli
script event errors
script event executed-cmd
script event state-change
script event warnings

It is advised to enable all debug options when starting and then remove more and more debugs
options as the script becomes more complete and stable. The debug output gives clear indications
about errors in the script or its execution in case something goes wrong.
An additional aid is the use of print commands in the Python script itself for certain attributes
during the execution of the script. The print output will appear in the debug log. Print commands
in the Python script should only be used during the testing phase and not in the normal operations
mode.
The following command allows the execution of a dynamic services Python script without the
need for RADIUS interaction:

Page 1772

Advanced Configuration Guide

RADIUS-Triggered Dynamic Data Service Provision-

tools perform service dynamic-services evaluate-script sap <sap-id> control-session <acctsession-id> action <script-action> [dynsvc-policy <name>]
show service dynamic-services script statistics provides general statistics about script
execution.
show service dynamic-services script snippets displays the individual service configuration
parts and allows to check if all snippets are actually referenced (the counter will increment/
decrement with every function call).
In the case of a failed script action a SAP may not be deleted properly and it remains in the
configuration as an orphaned object. show service dynamic-services saps orphaned displays
orphaned objects.
An orphaned object no longer has any references, which can be seen using show service
dynamic-services root-objects where the snippet name and snippet instance is set to N/A.
Complete setup flow example
To finalize the section about the interaction between RADIUS and the Python script, the complete
setup flow for the Epipe example is shown using extracts from the debug output (any missing
sequence numbers in the flow below are simple acknowledge messages from RADIUS and are left
out to focus on the important information). The debug settings to be used for this output are the
following.
*A:BNG-1# show debug
debug
router "Base"
radius
packet-type authentication accounting coa
detail-level medium
exit
exit
router "management"
radius
packet-type authentication accounting coa
detail-level medium
exit
exit
dynamic-services
scripts
event
cli
exit
instance "dynamic-services-1"
event
cli
exit
exit
exit
exit
exit

Advanced Configuration Guide

Page 1773

Configuration

The first sequence in the flow is the Access-Request to the RADIUS server for the control
channel. The information provided is that configured as part of the regular ESM configuration.
9 2013/04/12 20:47:23.73 UTC MINOR: DEBUG #2001 Base RADIUS
"RADIUS: Transmit
Access-Request(1) 172.31.1.2:1812 id 70 len 206 vrid 1 pol authentication-2
USER NAME [1] 24 subscriber12@domain2.com
NAS IP ADDRESS [4] 4 192.0.2.1
SERVICE TYPE [6] 4 Framed(2)
FRAMED PROTOCOL [7] 4 PPP(1)
CHAP PASSWORD [3] 17 1 0xd4b73e0a17c0ad7f03c19bc1db5c291d
CHAP CHALLENGE [60] 41
0x620fa5f8be193d2066f6abad96c7de2df03986e3421f9733220d9520137b0bf40b30edc9c92bea30a2
VSA [26] 29 DSL(3561)
AGENT CIRCUIT ID [1] 13 circuit-id-12
AGENT REMOTE ID [2] 12 remote-id-12
NAS PORT ID [87] 11 3/2/2:1.100
CALLING STATION ID [31] 17 00:00:64:01:02:03
NAS IDENTIFIER [32] 5 BNG-1
NAS PORT TYPE [61] 4 PPPoEoQinQ(34)

If the subscriber can be authenticated and authorized, RADIUS responds with an Access-Accept
containing attributes for both the control channel and the dynamic data service.
10 2013/04/12 20:47:23.73 UTC MINOR: DEBUG #2001 Base RADIUS
"RADIUS: Receive
Access-Accept(2) id 70 len 211 from 172.31.1.2:1812 vrid 1 pol authentication-2
VSA [26] 14 Alcatel(6527)
SUBSC ID STR [11] 12 pppoe-user12
FRAMED IP ADDRESS [8] 4 10.2.1.200
VSA [26] 8 Alcatel(6527)
DYN SERV SAP ID [164] 6 1 #:#.1
VSA [26] 118 Alcatel(6527)
DYN SERV SCRIPT PARAMS [165] 116 1 business_epipe={'t':('EPipe-CustomerName','CustomerName-Circuit-1','3','3','64496','192.0.2.5','192.0.2.1','3333')}
VSA [26] 21 Alcatel(6527)
DYN SERV POLICY [167] 19 1 dynamic-services-2

The existence of the Dyn Serv VSAs in the response triggers the BNG to start the execution of the
Python script, but first the control channel session is completely established and an accounting
start message is send to RADIUS. This is a standard accounting message for ESM subscribers.
11 2013/04/12 20:47:23.75 UTC MINOR: DEBUG #2001 Base RADIUS
"RADIUS: Transmit
Accounting-Request(4) 172.31.1.2:1813 id 108 len 191 vrid 1 pol accounting-2
STATUS TYPE [40] 4 Start(1)
NAS IP ADDRESS [4] 4 192.0.2.1
SERVICE TYPE [6] 4 Framed(2)
FRAMED PROTOCOL [7] 4 PPP(1)
FRAMED IP ADDRESS [8] 4 10.2.1.200
FRAMED IP NETMASK [9] 4 255.255.255.255
NAS IDENTIFIER [32] 5 BNG-1
SESSION ID [44] 22 D6E559000000D2516872DB
MULTI SESSION ID [50] 22 D6E559000000D3516872DB

Page 1774

Advanced Configuration Guide

RADIUS-Triggered Dynamic Data Service Provision-

EVENT TIMESTAMP [55] 4 1365799643


NAS PORT TYPE [61] 4 PPPoEoQinQ(34)
NAS PORT ID [87] 11 3/2/2:1.100
VSA [26] 29 DSL(3561)
AGENT CIRCUIT ID [1] 13 circuit-id-12
AGENT REMOTE ID [2] 12 remote-id-12
VSA [26] 14 Alcatel(6527)
SUBSC ID STR [11] 12 pppoe-user12
"

Next, the creation of the dynamic data service starts. As this is the first SAP for this service, the
script which we reviewed above first creates the service instance.
12 2013/04/12 20:47:23.74 UTC MINOR: DEBUG #2001 Base dyn-script cli 1/1
"dyn-script cli 1/1: epipe:EPipe-CustomerName(cli 172 dict 0->31)
configure
service
epipe 1000 customer 1 create
service-name "EPipe-CustomerName"
description "EPipe-CustomerName"
no shutdown
exit
exit
exit
"

Next, the SAP and the SDP are created within this service by the main function.
14 2013/04/12 20:47:23.74 UTC MINOR: DEBUG #2001 Base dyn-script cli 1/1
"dyn-script cli 1/1: business_epipe:3/2/2:1.1(cli 418 dict 0->308)
configure
service
epipe 1000
sap 3/2/2:1.1 create
description "CustomerName-Circuit-1"
ingress
qos 3
exit
egress
qos 3
exit
exit
spoke-sdp-fec 1000 fec 129 aii-type 2 create
pw-template-bind 2
saii-type2 64496:192.0.2.1:3333
taii-type2 64496:192.0.2.5:3333
no shutdown
exit
exit
exit
exit
"

Advanced Configuration Guide

Page 1775

Configuration

The service is created and is now active. As two RADIUS accounting destinations are configured
in the dynamic services policy a RADIUS Accounting-Start message is sent to each destination to
indicate the service is up.
16 2013/04/12 20:47:23.76 UTC MINOR: DEBUG #2001 Base RADIUS
"RADIUS: Transmit
Accounting-Request(4) 172.31.1.2:1813 id 252 len 294 vrid 1 pol radius-server-policy-2
STATUS TYPE [40] 4 Start(1)
NAS IP ADDRESS [4] 4 192.0.2.1
SESSION ID [44] 22 D6E559000000D4516872DB
NAS PORT ID [87] 9 3/2/2:1.1
DELAY TIME [41] 4 0
NAS IDENTIFIER [32] 5 BNG-1
EVENT TIMESTAMP [55] 4 1365799643
MULTI SESSION ID [50] 22 D6E559000000D1516872DB
USER NAME [1] 24 subscriber12@domain2.com
VSA [26] 29 DSL(3561)
AGENT CIRCUIT ID [1] 13 circuit-id-12
AGENT REMOTE ID [2] 12 remote-id-12
VSA [26] 117 Alcatel(6527)
DYN SERV SCRIPT PARAMS [165] 115 business_epipe={'t':('EPipe-CustomerName','CustomerName-Circuit-1','3','3','64496','192.0.2.5','192.0.2.1','3333')}
"
15 2013/04/12 20:47:23.76 UTC MINOR: DEBUG #2001 Base RADIUS
"RADIUS: Transmit
Accounting-Request(4) 172.31.1.2:1813 id 251 len 294 vrid 1 pol radius-server-policy-2
STATUS TYPE [40] 4 Start(1)
NAS IP ADDRESS [4] 4 192.0.2.1
SESSION ID [44] 22 D6E559000000D4516872DB
NAS PORT ID [87] 9 3/2/2:1.1
DELAY TIME [41] 4 0
NAS IDENTIFIER [32] 5 BNG-1
EVENT TIMESTAMP [55] 4 1365799643
MULTI SESSION ID [50] 22 D6E559000000D1516872DB
USER NAME [1] 24 subscriber12@domain2.com
VSA [26] 29 DSL(3561)
AGENT CIRCUIT ID [1] 13 circuit-id-12
AGENT REMOTE ID [2] 12 remote-id-12
VSA [26] 117 Alcatel(6527)
DYN SERV SCRIPT PARAMS [165] 115 business_epipe={'t':('EPipe-CustomerName','CustomerName-Circuit-1','3','3','64496','192.0.2.5','192.0.2.1','3333')}
"

For both RADIUS accounting destinations the interim accounting updates are also configured.
21 2013/04/12 20:51:46.69 UTC MINOR: DEBUG #2001 Base RADIUS
"RADIUS: Transmit
Accounting-Request(4) 172.31.1.2:1813 id 173 len 511 vrid 1 pol radius-server-policy-1
STATUS TYPE [40] 4 Interim-Update(3)
NAS IP ADDRESS [4] 4 192.0.2.1
SESSION ID [44] 22 D6E559000000D4516872DB
NAS PORT ID [87] 9 3/2/2:1.1
DELAY TIME [41] 4 0
NAS IDENTIFIER [32] 5 BNG-1
EVENT TIMESTAMP [55] 4 1365799906
SESSION TIME [46] 4 125174
MULTI SESSION ID [50] 22 D6E559000000D1516872DB

Page 1776

Advanced Configuration Guide

RADIUS-Triggered Dynamic Data Service Provision-

USER NAME [1] 23 subscriber12@domain2.com


VSA [26] 27 DSL(3561)
AGENT CIRCUIT ID [1] 12 circuit-id-12
AGENT REMOTE ID [2] 11 remote-id-12
VSA [26] 241 Alcatel(6527)
DYN SERV SCRIPT PARAMS [165] 115 business_epipe={'t':('EPipe-CustomerName','CustomerName-Circuit-1','3','3','64496','192.0.2.5','192.0.2.1','3333')}
INPUT_INPROF_OCTETS_64 [19] 10 0x00010000000000000000
INPUT_OUTPROF_OCTETS_64 [20] 10 0x00010000000000000000
INPUT_INPROF_PACKETS_64 [23] 10 0x00010000000000000000
INPUT_OUTPROF_PACKETS_64 [24] 10 0x00010000000000000000
INPUT_HIGH_OCTETS_OFFER_64 [73] 10 0x00010000000000000000
INPUT_LOW_PACK_OFFER_64 [76] 10 0x00010000000000000000
INPUT_HIGH_PACK_OFFER_64 [75] 10 0x00010000000000000000
INPUT_LOW_OCTETS_OFFER_64 [74] 10 0x00010000000000000000
INPUT_UNC_PACK_OFFER_64 [78] 10 0x00010000000000000000
INPUT_UNC_OCTETS_OFFER_64 [77] 10 0x00010000000000000000
INPUT_HIGH_PACK_DROP_64 [71] 10 0x00010000000000000000
INPUT_LOW_PACK_DROP_64 [72] 10 0x00010000000000000000
INPUT_HIGH_OCTETS_DROP_64 [69] 10 0x00010000000000000000
INPUT_LOW_OCTETS_DROP_64 [70] 10 0x00010000000000000000
OUTPUT_INPROF_OCTETS_64 [21] 10 0x0001000000000000033c
VSA [26] 84 Alcatel(6527)
OUTPUT_OUTPROF_OCTETS_64 [22] 10 0x00010000000000000000
OUTPUT_INPROF_PACKETS_64 [25] 10 0x0001000000000000000b
OUTPUT_OUTPROF_PACKETS_64 [26] 10 0x00010000000000000000
OUTPUT_INPROF_PACK_DROP_64 [81] 10 0x00010000000000000000
OUTPUT_OUTPROF_PACK_DROP_64 [82] 10 0x00010000000000000000
OUTPUT_INPROF_OCTS_DROP_64 [83] 10 0x00010000000000000000
OUTPUT_OUTPROF_OCTS_DROP_64 [84] 10 0x00010000000000000000
"
19 2013/04/12 20:48:56.69 UTC MINOR: DEBUG #2001 Base RADIUS
"RADIUS: Transmit
Accounting-Request(4) 172.31.1.2:1813 id 253 len 241 vrid 1 pol radius-server-policy-2
STATUS TYPE [40] 4 Interim-Update(3)
NAS IP ADDRESS [4] 4 192.0.2.1
SESSION ID [44] 22 D6E559000000D4516872DB
NAS PORT ID [87] 9 3/2/2:1.1
DELAY TIME [41] 4 0
NAS IDENTIFIER [32] 5 BNG-1
EVENT TIMESTAMP [55] 4 1365799736
SESSION TIME [46] 4 125004
MULTI SESSION ID [50] 22 D6E559000000D1516872DB
USER NAME [1] 23 subscriber12@domain2.com
VSA [26] 27 DSL(3561)
AGENT CIRCUIT ID [1] 12 circuit-id-12
AGENT REMOTE ID [2] 11 remote-id-12
VSA [26] 61 Alcatel(6527)
DYN SERV SCRIPT PARAMS [165] 115 business_epipe={'t':('EPipe-CustomerName','CustomerName-Circuit-1','3','3','64496','192.0.2.5','192.0.2.1','3333')}
"

The Stats-Type in the dynamic service policy (or obtained via RADIUS in a VSA) defines what
information is sent back to the accounting server (per server). In this example one was set to StatsType time and the other to volume-time. The first accounting message displays the content of
volume-time. A full set of statistics counters per service class are provided for the dynamic

Advanced Configuration Guide

Page 1777

Configuration

service. This is equivalent to the extended accounting statistics also provided in the ESM context.
The second accounting message shows the content of time. No volume statistics counters are
provided in this case.
Once the dynamic data services are instantiated they can be displayed with the regular show
commands.
A:BNG-1# show service service-using
===============================================================================
Services
===============================================================================
ServiceId
Type
Adm Opr CustomerId Service Name
------------------------------------------------------------------------------1
VPLS
Up
Up
1
VPLS_For_Capture_SAPs
2
VPRN
Up
Up
1
VPRN_Control_Channel
3
VPRN
Up
Up
1
VPRN_REsidential_Subs
4
IES
Up
Up
1
10
VPRN
Up
Up
1
99
Mirror
Up
Up
1
500
Mirror
Up
Up
1
[1000]
Epipe
Up
Up
1
EPipe-CustomerName
[1001]
VPLS
Up
Up
1
VPLS-CustomerName
[1002]
IES
Up
Up
1
IES-CustomerName
[5000]
IES
Up
Up
1
IES-5000
[9999]
VPRN
Up
Up
1
VPRN-CustomerName
10001
VPLS
Up
Up
1
10002
Epipe
Up
Up
1
-snip------------------------------------------------------------------------------Matching Services : 20
------------------------------------------------------------------------------Dynamic Services : 5, indicated by [<svc-id>]
------------------------------------------------------------------------------===============================================================================

The dynamically created services are shown in the standard service list with their service IDs
between brackets. It is possible to filter only the dynamic services using the origin dyn-script
option.
A:BNG-1# show service service-using origin dyn-script
===============================================================================
Services
===============================================================================
ServiceId
Type
Adm Opr CustomerId Service Name
------------------------------------------------------------------------------[1000]
Epipe
Up
Up
1
EPipe-CustomerName
[1001]
VPLS
Up
Up
1
VPLS-CustomerName
[1002]
IES
Up
Up
1
IES-CustomerName
[5000]
IES
Up
Up
1
IES-5000
[9999]
VPRN
Up
Up
1
VPRN-CustomerName
------------------------------------------------------------------------------Matching Services : 5
------------------------------------------------------------------------------Dynamic Services : 5, indicated by [<svc-id>]
-------------------------------------------------------------------------------

Page 1778

Advanced Configuration Guide

RADIUS-Triggered Dynamic Data Service Provision-

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

Similarly, the active SAPs can also be shown with the regular command.
A:BNG-1# show service sap-using
===============================================================================
Service Access Points
===============================================================================
PortId
SvcId
Ing. Ing.
Egr. Egr.
Adm Opr
QoS
Fltr
QoS
Fltr
------------------------------------------------------------------------------3/2/1:*.100
1
1
none
1
none
Up
Up
3/2/1:*.200
1
1
none
1
none
Up
Up
3/2/2:*.100
1
1
none
1
none
Up
Up
[3/2/1:4.100]
2
1
none
1
none
Up
Up
[3/2/2:1.100]
2
1
none
1
none
Up
Up
3/2/2:1000.1000
2
1
none
1
none
Up
Up
[3/2/1:2.200]
3
1
none
1
none
Up
Up
[3/2/1:3.200]
3
1
none
1
none
Up
Up
3/2/1:1001.1001
3
1
none
1
none
Up
Up
3/2/2:500.500
3
1
none
1
none
Up
Up
3/2/2:100.100
4
1
none
1
none
Up
Up
3/2/2:99.99
99
1
none
1
none
Up
Up
[3/2/2:1.1]
[1000]
3
none
3
none
Up
Up
[3/2/2:1.3]
[1001]
3
none
3
none
Up
Up
[3/2/2:1.4]
[1002]
5
ip4+ip6 6
ip4+i* Up
Up
[3/2/1:4.3]
[5000]
1
none
1
none
Up
Up
[3/2/2:1.2]
[9999]
3
ip4
3
ip4
Up
Up
3/2/1:99.99
10001
1
none
1
none
Up
Up
3/2/19:100
10001
1
none
1
none
Up
Up
3/2/20:100
10001
1
none
1
none
Up
Up
-snip------------------------------------------------------------------------------Number of SAPs : 31
------------------------------------------------------------------------------Number of Managed SAPs : 4, indicated by [<sap-id>]
------------------------------------------------------------------------------Number of Dynamic Service SAPs : 5, indicated by [<sap-id>] [<svc-id>]
------------------------------------------------------------------------------===============================================================================
* indicates that the corresponding row element may have been truncated.

The description at the end of this show command explains how the dynamic services SAPs are
displayed. Note that there are managed SAPs created for the control channel as well as dynamic
data services SAPs.
If only the SAPs for dynamic data services should be displayed, the command show service sapusing dyn-script can be used.
A:BNG-1# show service sap-using dyn-script
===============================================================================
Service Access Points
===============================================================================
PortId
SvcId
Ing. Ing.
Egr. Egr.
Adm Opr
QoS
Fltr
QoS
Fltr

Advanced Configuration Guide

Page 1779

Configuration

------------------------------------------------------------------------------[3/2/2:1.1]
[1000]
3
none
3
none
Up
Up
[3/2/2:1.3]
[1001]
3
none
3
none
Up
Up
[3/2/2:1.4]
[1002]
5
ip4+ip6 6
ip4+i* Up
Up
[3/2/1:4.3]
[5000]
1
none
1
none
Up
Up
[3/2/2:1.2]
[9999]
3
ip4
3
ip4
Up
Up
------------------------------------------------------------------------------Number of SAPs : 5
------------------------------------------------------------------------------Number of Dynamic Service SAPs : 5, indicated by [<sap-id>] [<svc-id>]
------------------------------------------------------------------------------===============================================================================
* indicates that the corresponding row element may have been truncated.

Page 1780

Advanced Configuration Guide

RADIUS-Triggered Dynamic Data Service Provision-

Conclusion
RADIUS-based dynamic data services provide an innovative way for business service
provisioning. They are created both automatically and instantaneously.
It removes the need for comprehensive integration tasks into the existing IT environment for
service provisioning and therefore speeds up the introduction of new service offerings, and thus
new revenue streams for the customer.

Advanced Configuration Guide

Page 1781

Conclusion

Page 1782

Advanced Configuration Guide

Routed CO

In This Chapter
This section provides information about Routed Central Office (Routed CO) configurations.
Topics in this section include:

Applicability on page 1784

Summary on page 1785

Overview on page 1786

Configuration on page 1789

Conclusion on page 1829

Advanced Configuration Guide

Page 1783

Applicability

Applicability
This example is applicable to the 7750 SR and SR-c series as well as the 7450 ESS series in mixed
mode and was tested on SR-OS 11.0.R4. Chassis mode C or higher must be used.

Page 1784

Advanced Configuration Guide

Routed CO

Summary
In the Routed Central Office (Routed CO) model, subscriber management features are
implemented on a Layer 3 subscriber interface, available in a VPRN or an IES service. Compared
to regular Layer 3 interfaces, a subscriber-interface supports multiple SAPs, see later.
Customer originated traffic enters an Access Node (AN) and can be aggregated via either a Layer
2 or a Layer 3 aggregation network before being handled by a Broadband Network Gateway
(BNG). Alternatively, an AN can be directly connected to the BNG.
Routed CO supports numbered, unnumbered and hybrid (combined numbered/unnumbered)
subscriber interface configurations.
Enhanced Subscriber Management (ESM) is not mandatory for IPoEv4 in Routed CO, but is
mandatory for PPPoE and all IPoEv6 scenarios.
The numbered and unnumbered scenarios in this example use an IES service with:

Dual Stack IPoEv4 + IPoEv6

Single stack PPPoEv4

General knowledge of Alcatel-Lucents Triple Play Service Delivery Architecture is assumed


throughout this section. Refer to the 7x50 SR OS Triple Play Guide.

Advanced Configuration Guide

Page 1785

Overview

Overview
The Routed CO model offers through the subscriber and group interface construct:

Flexible subnet management


Subnets can be shared across multiple access nodes.

Support for different deployment models, for example:


VLAN/service model.
VLAN/subscriber model.
VLAN/service/subscriber model.
VLAN/access node model.

Per group-interface load balancing in multi-chassis redundancy configurations.


Redundancy is out of the scope of this example.

The components needed in the Routed CO model are depicted in Figure 177.
For the Routed CO model two interface types are needed:

First, one or more subscriber interfaces must be created.

Second, one or more group interfaces must be created within the subscriber interface
context.

1/1/1
SAP1
SAP2

GRP I/F A

SUB I/F A

SAP3
RGW

AN1

SAPX

IES/VRPN

subnet-A
...
subnet-X
GRP I/F B
Core

1/1/2

Not Allowed

subnet-AA
...
subnet-XX

SAP1
RGW

SAP2

R1

SUB I/F A

GRP I/F X

AN2
al_0380

BNG

Figure 177: Components of the Routed CO Model

Page 1786

Advanced Configuration Guide

Routed CO

Subscriber Interface
A subscriber interface is a set of one or more group interfaces and identified by name.
A subscriber interface is created under an IES or VPRN service context, and supports up to 256
subnets (sum of IPv4 subnets and IPv6 prefixes).
Three types of subscriber interface configurations are available:

Numbered subscriber interface.

Unnumbered subscriber interface.

Hybrid subscriber interface (numbered and unnumbered combined).

Subnet/Prefix Assignment
For the numbered scenario, the subscriber interface is configured with

One or more IPv4 subnets.

One or more IPv6 subscriber prefixes:


For WAN-hosts, using the DHCPv6 Identity Association for Non-temporary
Addresses (IA_NA) option or Stateless Address Auto Configuration (SLAAC) and
the prefix length is /64.
For Prefix Delegation-hosts (PD-hosts), using the DHCPv6 Identity Association for
Prefix Delegation (IA_PD) option and the prefix length is defined by the Delegated
Prefix Length (DPL).

This allows for subscriber-host address assignment in these subnets/prefixes only.


For the unnumbered scenario, the subscriber interface is configured with:

IPv4:
No IPv4 subnets.
The keyword unnumbered plus an interface in the same routing instance (for
example the system interface). The IP address of the interface referenced in the
unnumbered command is used in IPCP negotiation.

IPv6:
No IPv6 prefixes.
allow-unmatching-prefixes.

This allows for subscriber-host address assignment in any subnet/prefix. For IPv4, the keywords
unnumbered and allow-unmatching-subnets are mutually exclusive.

Advanced Configuration Guide

Page 1787

Overview

For the hybrid scenario the subscriber interface is configured with:

One or more IPv4 subnets and/or IPv6 subscriber prefixes.

For IPv4: the keyword allow-unmatching-subnets.

For IPv6: the keyword allow-unmatching-prefixes.

This allows for both subscriber-host address assignment within and outside of these subnets/
prefixes.

Host IP Reachability
For the numbered scenario, host IP reachability requires:

Adding the subscriber interfaces to the Interior Gateway Protocol (IGP).

Or an export policy matching the subscriber interface subnets/prefixes.

For the unnumbered scenario, host IP reachability requires:

An export policy matching the addresses of all individual subscriber hosts (from protocol
sub-mgmt).

For the hybrid scenario, host IP reachability requires:

An export policy matching both the subscriber interface subnets/prefixes as well as all
individual subscriber hosts addresses.

Detailed examples of numbered/unnumbered/hybrid scenarios, including host IP reachability are


included below.

Group Interface
A group interface is a set of one or more SAPs belonging to the same port and identified by name.

Page 1788

Advanced Configuration Guide

Routed CO

Configuration
This section covers:

The definition of subscriber and group interfaces.

A description of the numbered, unnumbered and hybrid scenarios.

Options ensuring host IP reachability throughout the network.

Subscriber Interface
The configuration of the subscriber interface appears as follows.
configure
service
ies 1
subscriber-interface "sub-int-1" create
address 10.1.1.254/24
address 10.1.2.254/24
ipv6
delegated-prefix-len 56
link-local-address FE80::EA:48:FF
subscriber-prefixes
prefix 2001:DB8:101::/48 wan-host
prefix 2001:DB8:102::/48 pd
prefix 2001:DB8:F101::/48 wan-host
prefix 2001:DB8:F102::/48 pd
exit
exit
exit
subscriber-interface "sub-int-2" create
address 10.2.1.254/24
address 10.2.2.254/24
ipv6
delegated-prefix-len 56
link-local-address FE80::EA:48:FF
subscriber-prefixes
prefix 2001:DB8:201::/48 wan-host
prefix 2001:DB8:202::/48 pd
prefix 2001:DB8:F201::/48 wan-host
prefix 2001:DB8:F202::/48 pd
exit
exit
exit

Notice that once a subnet/prefix is assigned to a subscriber interface, the subnet/prefix is tied to
that interface, meaning that the same subnet/prefix cannot be used on another subscriber interface
or regular interface in the same routing instance. When using VPRN for the Routed CO model,
overlapping subnets/prefixes are allowed when on different VPRN services.

Advanced Configuration Guide

Page 1789

Configuration

As long as no group interfaces are configured within the subscriber interface context, the
subscriber interfaces are in the operationally down state as shown in the following output. The
subscriber-interfaces, sub-int-1 and sub-int-2, are operational down since no group-interfaces have
been assigned at this stage.
*A:BNG# show router "Base" interface
===============================================================================
Interface Table (Router: Base)
===============================================================================
Interface-Name
Adm
Opr(v4/v6) Mode
Port/SapId
IP-Address
PfxState
------------------------------------------------------------------------------sub-int-1
Up
Down/Down
IES Sub subscriber
10.1.1.254/24
n/a
10.1.2.254/24
n/a
2001:DB8:101::/48
INACCESSIBLE
2001:DB8:102::/48
INACCESSIBLE
2001:DB8:F101::/48
INACCESSIBLE
2001:DB8:F102::/48
INACCESSIBLE
FE80::EA:48:FF/64
INACCESSIBLE
sub-int-2
Up
Down/Down
IES Sub subscriber
10.2.1.254/24
n/a
10.2.2.254/24
n/a
2001:DB8:201::/48
INACCESSIBLE
2001:DB8:202::/48
INACCESSIBLE
2001:DB8:F201::/48
INACCESSIBLE
2001:DB8:F202::/48
INACCESSIBLE
FE80::EA:48:FF/64
INACCESSIBLE
system
Up
Up/Up
Network system
192.0.2.75/32
n/a
2001:DB8::75/128
PREFERRED
toDHCP-1
Up
Up/Up
Network loopback
10.11.11.1/32
n/a
2001:DB8::11/128
PREFERRED
FE80::E84B:FFFF:FE00:0/64
PREFERRED
toRADIUS-1
Up
Up/Down
Network 1/1/10
192.168.202.75/24
n/a
------------------------------------------------------------------------------Interfaces : 5
===============================================================================
*A:BNG#

The corresponding IPv4 routing table looks as follows.


*A:BNG# show router "Base" route-table ipv4
===============================================================================
Route Table (Router: Base)
===============================================================================
Dest Prefix[Flags]
Type
Proto
Age
Pref
Next Hop[Interface Name]
Metric
------------------------------------------------------------------------------10.11.11.1/32
Local
Local
00h30m12s 0
toDHCP-1
0
192.0.2.75/32
Local
Local
00h30m12s 0
system
0
192.168.202.0/24
Local
Local
00h29m54s 0
toRADIUS-1
0

Page 1790

Advanced Configuration Guide

Routed CO

------------------------------------------------------------------------------No. of Routes: 3
Flags: L = LFA nexthop available
B = BGP backup route available
n = Number of times nexthop is repeated
===============================================================================
*A:BNG#

The corresponding IPv6 routing table looks as follows.


*A:BNG# show router "Base" route-table ipv6
===============================================================================
IPv6 Route Table (Router: Base)
===============================================================================
Dest Prefix[Flags]
Type
Proto
Age
Pref
Next Hop[Interface Name]
Metric
------------------------------------------------------------------------------2001:DB8::11/128
Local
Local
00h30m19s 0
toDHCP-1
0
2001:DB8::75/128
Local
Local
00h30m21s 0
system
0
------------------------------------------------------------------------------No. of Routes: 2
Flags: L = LFA nexthop available
B = BGP backup route available
n = Number of times nexthop is repeated
===============================================================================
*A:BNG#

No subscriber interface subnets/prefixes are present in the IPv4 and the IPv6 routing table as the
subscriber interfaces are operational down.

Advanced Configuration Guide

Page 1791

Configuration

Group Interface
A group interface is created under the subscriber-interface hierarchy.
configure
service
ies 1
subscriber-interface "sub-int-1" create
group-interface "grp-int-1-1" create
ipv6
exit
sap 1/1/1:111 create
exit
sap 1/1/1:112 create
exit
exit
group-interface "grp-int-1-2" create
ipv6
exit
sap 1/1/1:121 create
exit
exit
exit
subscriber-interface "sub-int-2" create
group-interface "grp-int-2-1" create
ipv6
exit
sap 1/1/2:211 create
exit
exit
group-interface "grp-int-2-2" create
ipv6
exit
sap 1/1/3:221 create
exit
sap 1/1/3:222 create
exit
exit
exit
exit

Static SAPs are created manually under the group-interface context. Managed SAPs (MSAPs) are
dynamically created when a trigger packet (DHCP, DHCPv6, ARP, PPPoE) is successfully
authenticated, which eliminates the provisioning of static SAPs. The creation and use of capture
and managed SAPs (MSAPs) is explained in the example on Managed SAPs with Routed CO on
page 1091.

Page 1792

Advanced Configuration Guide

Routed CO

A group interface is operationally up when at least one of its statically configured SAPs is
operationally up or when no static SAPs are configured while the parameter oper-up-whileempty under the group-interface context is enabled. The following output shows all group
interfaces are operationally up.
*A:BNG# show router "Base" interface ipv4
===============================================================================
Interface Table (Router: Base)
===============================================================================
Interface-Name
Adm
Opr(v4/v6) Mode
Port/SapId
IP-Address
PfxState
------------------------------------------------------------------------------grp-int-1-1
Up
Up/Up
IES Grp 1/1/1
grp-int-1-2
Up
Up/Up
IES Grp 1/1/1
grp-int-2-1
Up
Up/Up
IES Grp 1/1/2
grp-int-2-2
Up
Up/Up
IES Grp 1/1/3
sub-int-1
Up
Up/Up
IES Sub subscriber
10.1.1.254/24
n/a
10.1.2.254/24
n/a
sub-int-2
Up
Up/Up
IES Sub subscriber
10.2.1.254/24
n/a
10.2.2.254/24
n/a
system
Up
Up/Up
Network system
192.0.2.75/32
n/a
toDHCP-1
Up
Up/Up
Network loopback
10.11.11.1/32
n/a
toRADIUS-1
Up
Up/Down
Network 1/1/10
192.168.202.75/24
n/a
------------------------------------------------------------------------------Interfaces : 9
===============================================================================
*A:BNG#

The IPv4 routing table includes the subnets configured on the subscriber-interfaces.
*A:BNG# show router "Base" route-table ipv4
===============================================================================
Route Table (Router: Base)
===============================================================================
Dest Prefix[Flags]
Type
Proto
Age
Pref
Next Hop[Interface Name]
Metric
------------------------------------------------------------------------------10.1.1.0/24
Local
Local
00h25m32s 0
sub-int-1
0
10.1.2.0/24
Local
Local
00h25m32s 0
sub-int-1
0
10.2.1.0/24
Local
Local
00h25m32s 0
sub-int-2
0
10.2.2.0/24
Local
Local
00h25m32s 0
sub-int-2
0
10.11.11.1/32
Local
Local
01h01m53s 0
toDHCP-1
0
192.0.2.75/32
Local
Local
01h01m53s 0
system
0
192.168.202.0/24
Local
Local
01h01m36s 0
toRADIUS-1
0

Advanced Configuration Guide

Page 1793

Configuration

------------------------------------------------------------------------------No. of Routes: 7
Flags: L = LFA nexthop available
B = BGP backup route available
n = Number of times nexthop is repeated
===============================================================================
*A:BNG#

For IPv6, the interface table looks as follows.


*A:BNG# show router "Base" interface ipv6
===============================================================================
Interface Table (Router: Base)
===============================================================================
Interface-Name
Adm
Opr(v4/v6) Mode
Port/SapId
IP-Address
PfxState
------------------------------------------------------------------------------grp-int-1-1
Up
Up/Up
IES Grp 1/1/1
grp-int-1-2
Up
Up/Up
IES Grp 1/1/1
grp-int-2-1
Up
Up/Up
IES Grp 1/1/2
grp-int-2-2
Up
Up/Up
IES Grp 1/1/3
sub-int-1
Up
Up/Up
IES Sub subscriber
2001:DB8:101::/48
PREFERRED
2001:DB8:102::/48
PREFERRED
2001:DB8:F101::/48
PREFERRED
2001:DB8:F102::/48
PREFERRED
FE80::EA:48:FF/64
PREFERRED
sub-int-2
Up
Up/Up
IES Sub subscriber
2001:DB8:201::/48
PREFERRED
2001:DB8:202::/48
PREFERRED
2001:DB8:F201::/48
PREFERRED
2001:DB8:F202::/48
PREFERRED
FE80::EA:48:FF/64
PREFERRED
system
Up
Up/Up
Network system
2001:DB8::75/128
PREFERRED
toDHCP-1
Up
Up/Up
Network loopback
2001:DB8::11/128
PREFERRED
FE80::E84B:FFFF:FE00:0/64
PREFERRED
toRADIUS-1
Up
Up/Down
Network 1/1/10
------------------------------------------------------------------------------Interfaces : 9
===============================================================================
*A:BNG# #

The IPv6 routing table includes the prefixes configured on the subscriber interfaces.
*A:BNG# show router "Base" route-table ipv6
===============================================================================
IPv6 Route Table (Router: Base)
===============================================================================
Dest Prefix[Flags]
Type
Proto
Age
Pref
Next Hop[Interface Name]
Metric
------------------------------------------------------------------------------2001:DB8::11/128
Local
Local
14d04h08m 0
toDHCP-1
0
2001:DB8::75/128
Local
Local
14d04h08m 0

Page 1794

Advanced Configuration Guide

Routed CO

system
0
2001:DB8:101::/48
Local
Local
14d03h10m 0
sub-int-1
0
2001:DB8:102::/48
Local
Local
14d03h10m 0
sub-int-1
0
2001:DB8:201::/48
Local
Local
14d03h08m 0
sub-int-2
0
2001:DB8:202::/48
Local
Local
14d03h08m 0
sub-int-2
0
2001:DB8:F101::/48
Local
Local
14d03h10m 0
sub-int-1
0
2001:DB8:F102::/48
Local
Local
14d03h10m 0
sub-int-1
0
2001:DB8:F201::/48
Local
Local
14d03h08m 0
sub-int-2
0
2001:DB8:F202::/48
Local
Local
14d03h08m 0
sub-int-2
0
------------------------------------------------------------------------------No. of Routes: 10
Flags: L = LFA nexthop available
B = BGP backup route available
n = Number of times nexthop is repeated
===============================================================================
*A:BNG#

Advanced Configuration Guide

Page 1795

Configuration

Numbered Scenario
Figure 178 depicts the numbered scenario outlined below, including the connecting subscribers
and subscriber hosts. Subscribers sub-11 and sub-44 are using PPPv4 hosts, and subscribers sub22 and sub-33 are using dual stack DHCP hosts. Their VLANs and the MAC addresses are
shown, as are the IP addresses and prefixes assigned once they are connected.
PPPoEv4(sub11@domain.com)
sub-11
00:00:00:11:11:11
10.1.1.11

IPoEv4v6
sub-22
00:00:00:22:22:22

1/1/1
1/1/1:111
grp-int-1-1

10.1.1.12
2001:db8:102:200:/56

IPoEv4v6
sub-33
00:00:00:33:33:33
10.1.1.13
2001:db8:102:300:/56

sub-int-1

IES 1

1/1/1:112

2001:db8:101:1::1/128

10.1.1.254/24
10.1.2.254/24
2001:db8:101::/48
2001:db8:102::/48

1/1/1:121

v4
v6

grp-int-1-2
1/1/1:122
1/1/2

2001:db8:101:2::1/128
1/1/2:211
grp-int-2-1

sub-int-2

1/1/2:212
PPPoEv4(sub44@domain.com)
sub-44
00:00:00:44:44:44

10.2.1.254/24
10.2.2.254/24
2001:db8:201::/48
2001:db8:202::/48

1/1/3
1/1/3:221

10.2.2.11

v4
v6

grp-int-2-2
1/1/3:222

BNG

al_0381

Figure 178: Numbered Scenario For IES 1

Page 1796

Advanced Configuration Guide

Routed CO

The configuration for the numbered scenario is shown below. Only the configuration items
specific to the numbered scenario are shown.
In the numbered scenario the subscriber interfaces have following configuration:

IPv4
Subnets.
no allow-unmatching-subnets.
no unnumbered.

IPv6
A delegated prefix length.
subscriber prefixes.
no allow-unmatching-prefixes.

configure
service
ies 1
subscriber-interface "sub-int-1" create
address 10.1.1.254/24
address 10.1.2.254/24
ipv6
delegated-prefix-len 56
link-local-address FE80::EA:4B:FF
subscriber-prefixes
prefix 2001:DB8:101::/48 wan-host
prefix 2001:DB8:102::/48 pd
exit
exit
group-interface "grp-int-1-1" create
ipv6
--- snip --exit
arp-populate
dhcp
--- snip --lease-populate 100
no shutdown
exit
authentication-policy "auth-pol-1"
local-proxy-arp
sap 1/1/1:111 create
anti-spoof ip-mac
sub-sla-mgmt
--- snip --exit
exit
sap 1/1/1:112 create
anti-spoof ip-mac
sub-sla-mgmt
--- snip --exit

Advanced Configuration Guide

Page 1797

Configuration

exit
pppoe
--- snip --no shutdown
exit
exit
group-interface "grp-int-1-2" create
ipv6
--- snip --exit
arp-populate
dhcp
--- snip --lease-populate 100
no shutdown
exit
authentication-policy "auth-pol-1"
local-proxy-arp
sap 1/1/1:121 create
anti-spoof ip-mac
sub-sla-mgmt
--- snip --exit
exit
sap 1/1/1:122 create
anti-spoof ip-mac
sub-sla-mgmt
--- snip --exit
exit
pppoe
--- snip --no shutdown
exit
exit
exit
subscriber-interface "sub-int-2" create
address 10.2.1.254/24
address 10.2.2.254/24
ipv6
delegated-prefix-len 56
link-local-address FE80::EA:4B:FF
subscriber-prefixes
prefix 2001:DB8:201::/48 wan-host
prefix 2001:DB8:202::/48 pd
exit
exit
group-interface "grp-int-2-1" create
ipv6
--- snip --exit
arp-populate
dhcp
--- snip --lease-populate 100
no shutdown
exit
authentication-policy "auth-pol-1"
local-proxy-arp

Page 1798

Advanced Configuration Guide

Routed CO

sap 1/1/2:211 create


anti-spoof ip-mac
sub-sla-mgmt
--- snip --exit
exit
sap 1/1/2:212 create
anti-spoof ip-mac
sub-sla-mgmt
--- snip --exit
exit
pppoe
--- snip --no shutdown
exit
exit
group-interface "grp-int-2-2" create
ipv6
--- snip --exit
arp-populate
dhcp
--- snip --lease-populate 100
no shutdown
exit
authentication-policy "auth-pol-1"
local-proxy-arp
sap 1/1/3:221 create
anti-spoof ip-mac
sub-sla-mgmt
--- snip --exit
exit
sap 1/1/3:222 create
anti-spoof ip-mac
sub-sla-mgmt
--- snip --exit
exit
pppoe
--- snip --no shutdown
exit
exit
exit
no shutdown

Advanced Configuration Guide

Page 1799

Configuration

The following parameters are mandatory for the routed CO model:

lease-populate DHCPv4 lease state population is enabled by default on a groupinterface with DHCPv4 configured as no shutdown. The number of leases allowed on the
group-interface must be configured. By default one single DHCPv4 host is allowed per
group-interface. This parameter enables the creation of an ESM host table entry for each
DHCPv4 lease. For DHCPv6 the ESM host table entry creation is implicit: no CLI
parameter is required.

arp-populate The ARP table is populated with dynamically learned entries from the
DHCP lease state table or static entries from the static host table. The BNG does not send
downstream ARPs for those managed ARP table entries.

local-proxy-arp Enables user to user traffic in a split-horizon environment. The BNG


responds with its own MAC address to ARP requests targeting subnets configured on the
subscriber interface. If the ARP request is targeting a host of the same subscriber on the
same SAP, the ARP request is silently discarded. This prevents traffic within a single
bridged home to be attracted to the BNG. Local-proxy-arp is enabled by default.

anti-spoof Checks the source MAC and/or source IP of the upstream subscriber traffic.
This parameter is configured at the SAP level with values ip-mac (default), ip or nh-mac.
With ESM enabled, anti-spoof must include the source mac (values ip-mac or nh-mac).

Optional settings are:

Page 1800

description Can be used to assign a descriptive text to the item and used for
administrative reasons.

delayed-enable To be used in redundant configurations. It is expressed in seconds and


defines the additional time the BNG waits before the interface is enabled.

Advanced Configuration Guide

Routed CO

Verification
The interfaces on the BNG are listed using following command. Notice that all subscriber and
group interfaces are operational up for IPv4 and IPv6.
A:BNG# show router "Base" interface
===============================================================================
Interface Table (Router: Base)
===============================================================================
Interface-Name
Adm
Opr(v4/v6) Mode
Port/SapId
IP-Address
PfxState
------------------------------------------------------------------------------grp-int-1-1
Up
Up/Up
IES Grp 1/1/1
grp-int-1-2
Up
Up/Up
IES Grp 1/1/1
grp-int-2-1
Up
Up/Up
IES Grp 1/1/2
grp-int-2-2
Up
Up/Up
IES Grp 1/1/3
sub-int-1
Up
Up/Up
IES Sub subscriber
10.1.1.254/24
n/a
10.1.2.254/24
n/a
2001:DB8:101::/48
PREFERRED
2001:DB8:102::/48
PREFERRED
FE80::EA:48:FF/64
PREFERRED
sub-int-2
Up
Up/Up
IES Sub subscriber
10.2.1.254/24
n/a
10.2.2.254/24
n/a
2001:DB8:201::/48
PREFERRED
2001:DB8:202::/48
PREFERRED
FE80::EA:48:FF/64
PREFERRED
system
Up
Up/Up
Network system
192.0.2.75/32
n/a
2001:DB8::75/128
PREFERRED
toDHCP-1
Up
Up/Up
Network loopback
10.11.11.1/32
n/a
2001:DB8::11/128
PREFERRED
FE80::E84B:FFFF:FE00:0/64
PREFERRED
toR1
Up
Up/Up
Network 1/1/12
192.168.12.1/24
n/a
2001:DEAD::1/64
PREFERRED
FE80::E84B:FFFF:FE00:0/64
PREFERRED
toRADIUS-1
Up
Up/Down
Network 1/1/10
192.168.202.75/24
n/a
------------------------------------------------------------------------------Interfaces : 10
===============================================================================
A:BNG#

Successfully created hosts have forwarding state Fwding. Hosts not in the Fwding state cannot
forward any data.
A:BNG# show service id 1 subscriber-hosts
=============================================================
Subscriber Host table
=============================================================
Sap
Subscriber
IP Address

Advanced Configuration Guide

Page 1801

Configuration

MAC Address
PPPoE-SID Origin
Fwding State
------------------------------------------------------------1/1/1:111
sub-11
10.1.1.11
00:00:00:11:11:11
1
IPCP
Fwding
1/1/1:112
sub-22
10.1.1.12
00:00:00:22:22:22
N/A
DHCP
Fwding
1/1/1:112
sub-22
2001:DB8:101:1::1/128
00:00:00:22:22:22
N/A
IPoE-DHCP6
Fwding
1/1/1:112
sub-22
2001:DB8:102:200::/56
00:00:00:22:22:22
N/A
IPoE-DHCP6
Fwding
1/1/1:122
sub-33
10.1.1.13
00:00:00:33:33:33
N/A
DHCP
Fwding
1/1/1:122
sub-33
2001:DB8:101:2::1/128
00:00:00:33:33:33
N/A
IPoE-DHCP6
Fwding
1/1/1:122
sub-33
2001:DB8:102:300::/56
00:00:00:33:33:33
N/A
IPoE-DHCP6
Fwding
1/1/3:222
sub-44
10.2.2.11
00:00:00:44:44:44
1
IPCP
Fwding
------------------------------------------------------------Number of subscriber hosts : 8
=============================================================
A:BNG#

The list of active subscribers can be displayed as follows.


A:BNG# show service active-subscribers
===============================================================================
Active Subscribers
===============================================================================
------------------------------------------------------------------------------Subscriber sub-11 (sub-prof-1)
------------------------------------------------------------------------------------------------------------------------------------------------------------(1) SLA Profile Instance sap:1/1/1:111 - sla:sla-prof-1
------------------------------------------------------------------------------IP Address
MAC Address
PPPoE-SID Origin
-------------------------------------------------------10.1.1.11
00:00:00:11:11:11 1
IPCP
------------------------------------------------------------------------------Subscriber sub-22 (sub-prof-1)
------------------------------------------------------------------------------------------------------------------------------------------------------------(1) SLA Profile Instance sap:1/1/1:112 - sla:sla-prof-1
------------------------------------------------------------------------------IP Address
MAC Address
PPPoE-SID Origin
-------------------------------------------------------10.1.1.12

Page 1802

Advanced Configuration Guide

Routed CO

00:00:00:22:22:22 N/A
DHCP
2001:DB8:101:1::1/128
00:00:00:22:22:22 N/A
IPoE-DHCP6
2001:DB8:102:200::/56
00:00:00:22:22:22 N/A
IPoE-DHCP6
------------------------------------------------------------------------------Subscriber sub-33 (sub-prof-1)
------------------------------------------------------------------------------------------------------------------------------------------------------------(1) SLA Profile Instance sap:1/1/1:122 - sla:sla-prof-1
------------------------------------------------------------------------------IP Address
MAC Address
PPPoE-SID Origin
-------------------------------------------------------10.1.1.13
00:00:00:33:33:33 N/A
DHCP
2001:DB8:101:2::1/128
00:00:00:33:33:33 N/A
IPoE-DHCP6
2001:DB8:102:300::/56
00:00:00:33:33:33 N/A
IPoE-DHCP6
------------------------------------------------------------------------------Subscriber sub-44 (sub-prof-1)
------------------------------------------------------------------------------------------------------------------------------------------------------------(1) SLA Profile Instance sap:1/1/3:222 - sla:sla-prof-1
------------------------------------------------------------------------------IP Address
MAC Address
PPPoE-SID Origin
-------------------------------------------------------10.2.2.11
00:00:00:44:44:44 1
IPCP
------------------------------------------------------------------------------Number of active subscribers : 4
------------------------------------------------------------------------------A:BNG#

Manually cross-referencing the SAPs from this output with the actual configuration shows the
following for IPv4, and is depicted in Figure 178.

Sub-11 and sub-22 are connected to the same subscriber and group interface (sub-int-1
and grp-int-1-1) but via different SAPs (1/1/1:111 and 1/1/1:112) and are sharing the same
IPv4 subnet.

Sub-33 is also connected to the same subscriber interface (sub-int-1) but via a different
group-interface (grp-int-1-2). Sub-33 shares the same IPv4 subnet as sub-11 and sub-12,
showing that the same subnet is shared across multiple group-interfaces.

Sub-44 is connected to a different subscriber and group interface, and does not share a
subnet with the other subscribers.

Advanced Configuration Guide

Page 1803

Configuration

An alternative way to find where, for example, subscriber sub-33 is connected is shown below.
*A:BNG# show service active-subscribers subscriber "sub-33" detail
===============================================================================
Active Subscribers
===============================================================================
------------------------------------------------------------------------------Subscriber sub-11 (sub-prof-1)
------------------------------------------------------------------------------I. Sched. Policy : N/A
---

snip ---

Oper-Rate-Limit : Maximum
* indicates that the corresponding row element may have been truncated.
------------------------------------------------------------------------------(1) SLA Profile Instance
- sap:1/1/1:112 (IES 1 - grp-int-1-2)
- sla:sla-prof-1
------------------------------------------------------------------------------Description
: (Not Specified)
---

snip ---

An alternative to find where, for example, IP address 10.1.1.13 is connected is shown below.
*A:BNG# show service id 1 dhcp lease-state ip-address 10.1.1.13 detail
===============================================================================
DHCP lease states for service 1
===============================================================================
Service ID
: 1
IP Address
: 10.1.1.13
Client HW Address
: 00:00:00:33:33:33
Subscriber-interface : sub-int-1
Group-interface
: grp-int-1-2
SAP
: 1/1/1:122
--- snip --Sub-Ident
Sub-Profile-String
SLA-Profile-String
App-Profile-String

:
:
:
:

"sub-33"
"sub-prof-1"
"sla-prof-1"
""

--- snip --DHCP Server Addr


: 10.11.11.1
Radius User-Name
: "00:00:00:33:33:33"
------------------------------------------------------------------------------Number of lease states : 1
===============================================================================
*A:BNG#

Page 1804

Advanced Configuration Guide

Routed CO

For IPv6, the situation is as follows:

Sub-22 and sub-33 are connected to the same subscriber interface (sub-int-1) but to
different group interfaces. Both subscribers share the same IPv6 prefix for prefixdelegation (PD) and wan-host.

With these subscriber hosts connected, the IPv4 routing table (RIB) for the base router looks as
follows.
*A:BNG# show router "Base" route-table ipv4
===============================================================================
Route Table (Router: Base)
===============================================================================
Dest Prefix[Flags]
Type
Proto
Age
Pref
Next Hop[Interface Name]
Metric
------------------------------------------------------------------------------10.1.1.0/24
Local
Local
02h25m15s 0
sub-int-1
0
10.1.1.11/32
Remote Sub Mgmt 02h25m10s 0
[grp-int-1-1]
0
10.1.1.12/32
Remote Sub Mgmt 00h49m52s 0
[grp-int-1-1]
0
10.1.1.13/32
Remote Sub Mgmt 00h47m40s 0
[grp-int-1-2]
0
10.1.2.0/24
Local
Local
02h25m15s 0
sub-int-1
0
10.2.1.0/24
Local
Local
02h25m15s 0
sub-int-2
0
10.2.2.0/24
Local
Local
02h25m15s 0
sub-int-2
0
10.2.2.11/32
Remote Sub Mgmt 02h25m10s 0
[grp-int-2-2]
0
10.11.11.1/32
Local
Local
02h25m33s 0
toDHCP-1
0
192.0.2.75/32
Local
Local
02h25m33s 0
system
0
192.0.2.76/32
Remote ISIS
02h24m43s 15
192.168.12.2
10
192.168.12.0/24
Local
Local
02h25m15s 0
toR1
0
192.168.202.0/24
Local
Local
02h25m15s 0
toRADIUS-1
0
------------------------------------------------------------------------------No. of Routes: 13
Flags: L = LFA nexthop available
B = BGP backup route available
n = Number of times nexthop is repeated
===============================================================================
*A:BNG#

The IPv6 routing table (RIB) for the base router displays as follows.
*A:BNG# show router "Base" route-table ipv6
===============================================================================
IPv6 Route Table (Router: Base)
===============================================================================
Dest Prefix[Flags]
Type
Proto
Age
Pref

Advanced Configuration Guide

Page 1805

Configuration

Next Hop[Interface Name]


Metric
------------------------------------------------------------------------------2001:DB8::11/128
Local
Local
02h27m23s 0
toDHCP-1
0
2001:DB8::75/128
Local
Local
02h27m24s 0
system
0
2001:DB8::76/128
Remote ISIS
02h26m32s 15
FE80::E84C:FFFF:FE00:0-"toR1"
10
2001:DB8:101::/48
Local
Local
02h27m06s 0
sub-int-1
0
2001:DB8:101:1::1/128
Remote Sub Mgmt 01h13m43s 0
[grp-int-1-1]
0
2001:DB8:101:2::1/128
Remote Sub Mgmt 01h13m25s 0
[grp-int-1-2]
0
2001:DB8:102::/48
Local
Local
02h27m06s 0
sub-int-1
0
2001:DB8:102:200::/56
Remote Sub Mgmt 01h13m43s 0
[grp-int-1-1]
0
2001:DB8:102:300::/56
Remote Sub Mgmt 01h13m25s 0
[grp-int-1-2]
0
2001:DB8:201::/48
Local
Local
02h27m06s 0
sub-int-2
0
2001:DB8:202::/48
Local
Local
02h27m06s 0
sub-int-2
0
2001:DEAD::/64
Local
Local
02h27m05s 0
toR1
0
------------------------------------------------------------------------------No. of Routes: 12
Flags: L = LFA nexthop available
B = BGP backup route available
n = Number of times nexthop is repeated
===============================================================================
*A:BNG#

The corresponding IPv4 FIB on card 1 looks as follows.


*A:BNG# show router "Base" fib 1 ipv4
===============================================================================
FIB Display
===============================================================================
Prefix
Protocol
NextHop
------------------------------------------------------------------------------10.1.1.0/24
LOCAL
10.1.1.0 (sub-int-1)
10.1.2.0/24
LOCAL
10.1.2.0 (sub-int-1)
10.2.1.0/24
LOCAL
10.2.1.0 (sub-int-2)
10.2.2.0/24
LOCAL
10.2.2.0 (sub-int-2)
10.11.11.1/32
LOCAL
10.11.11.1 (toDHCP-1)
192.0.2.75/32
LOCAL
192.0.2.75 (system)
192.0.2.76/32
ISIS
192.168.12.2 (toR1)
192.168.12.0/24
LOCAL
192.168.12.0 (toR1)

Page 1806

Advanced Configuration Guide

Routed CO

192.168.202.0/24
LOCAL
192.168.202.0 (toRADIUS-1)
------------------------------------------------------------------------------Total Entries : 9
------------------------------------------------------------------------------===============================================================================
*A:BNG#

The corresponding IPv6 FIB on card 1 is as follows.


*A:BNG# show router "Base" fib 1 ipv6
===============================================================================
FIB Display
===============================================================================
Prefix
Protocol
NextHop
------------------------------------------------------------------------------2001:DB8::11/128
LOCAL
2001:DB8::11 (toDHCP-1)
2001:DB8::75/128
LOCAL
2001:DB8::75 (system)
2001:DB8::76/128
ISIS
FE80::E84C:FFFF:FE00:0 (toR1)
2001:DB8:101::/48
LOCAL
2001:DB8:101:: (sub-int-1)
2001:DB8:102::/48
LOCAL
2001:DB8:102:: (sub-int-1)
2001:DB8:201::/48
LOCAL
2001:DB8:201:: (sub-int-2)
2001:DB8:202::/48
LOCAL
2001:DB8:202:: (sub-int-2)
2001:DEAD::/64
LOCAL
2001:DEAD:: (toR1)
------------------------------------------------------------------------------Total Entries : 8
------------------------------------------------------------------------------===============================================================================
*A:BNG#

The addresses of the individual subscriber hosts show up in the RIB but they do not show up in the
FIB.

/32 for IPv4-hosts.

/DPL (Delegated Prefix Length) for IPv6 DP hosts, /56 in this example.

/128 or /64 for IPv6 wan host.

Downstream traffic is forwarded based on a subscriber host table lookup. For specific network
designs, subscriber host IPv4 addresses can optionally be included in the FIB with the populatehost-routes statement added to the subnet configuration. This is out of scope of this example.

Advanced Configuration Guide

Page 1807

Configuration

Unnumbered Scenario
Figure 179 depicts the unnumbered scenario outlined below, including the connecting subscribers
and subscriber hosts. Sub-11 and sub-44 are using single stack PPPoEv4 hosts, and sub-22 and
sub-33 are using dual stack DHCP hosts. Their VLANs and the MAC addresses are shown, as are
the IP addresses and prefixes assigned once they are connected.
PPPoEv4(sub11@domain.com)
sub-11
00:00:00:11:11:11
10.1.1.101

IPoEv4v6
sub-22
00:00:00:22:22:22

1/1/1
1/1/1:111
grp-int-1-1

10.2.2.1
2001:db8:102::/56

2001:db8:101::1/128

IPoEv4v6
sub-33
00:00:00:33:33:33
10.2.2.2
2001:db8:102:100:/56

1/1/1:112

sub-int-1

IES 1

unnumbered system
allow-unmatching-prefixes

1/1/1:121
grp-int-1-2
1/1/1:122
1/1/2

2001:db8:101::1/128
1/1/2:211
grp-int-2-1
1/1/2:212

PPPoEv4(sub44@domain.com)
sub-44
00:00:00:44:44:44

sub-int-2
unnumbered system
allow-unmatching-prefixes

1/1/3
1/1/3:221

10.1.1.102

grp-int-2-2
1/1/3:222

BNG

al_0382

Figure 179: Unnumbered Scenario for IES 1

The configuration for the unnumbered scenario is show below. Only the configuration items
specific to the unnumbered scenario are shown.

Page 1808

Advanced Configuration Guide

Routed CO

In the unnumbered scenario the subscriber interfaces have following properties:

IPv4:
No subnets configured.
unnumbered, with an IPv4 interface or an IPv4 address used for IPCP negotiation.
no allow-unmatching-subnets.

IPv6:
No subscriber prefixes configured.
allow-unmatching-prefixes.

configure
service
ies 1
subscriber-interface "sub-int-1" create
unnumbered "system"
ipv6
delegated-prefix-len 56
allow-unmatching-prefixes
link-local-address FE80::EA:4B:FF
exit
group-interface "grp-int-1-1" create
ipv6
--- snip --exit
arp-populate
dhcp
--- snip --lease-populate 100
no shutdown
exit
authentication-policy "auth-pol-1"
sap 1/1/1:111 create
anti-spoof ip-mac
sub-sla-mgmt
--- snip --exit
exit
sap 1/1/1:112 create
anti-spoof ip-mac
sub-sla-mgmt
--- snip --exit
exit
pppoe
--- snip --no shutdown
exit
exit
group-interface "grp-int-1-2" create
ipv6
--- snip --exit
arp-populate
dhcp

Advanced Configuration Guide

Page 1809

Configuration

--- snip --lease-populate 100


no shutdown
exit
authentication-policy "auth-pol-1"
sap 1/1/1:121 create
anti-spoof ip-mac
sub-sla-mgmt
--- snip --exit
exit
sap 1/1/1:122 create
anti-spoof ip-mac
sub-sla-mgmt
--- snip --exit
exit
pppoe
--- snip --no shutdown
exit
exit
exit
subscriber-interface "sub-int-2" create
unnumbered "system"
ipv6
delegated-prefix-len 56
allow-unmatching-prefixes
link-local-address FE80::EA:4B:FF
exit
group-interface "grp-int-2-1" create
ipv6
--- snip --exit
arp-populate
dhcp
--- snip --lease-populate 100
no shutdown
exit
authentication-policy "auth-pol-1"
sap 1/1/2:211 create
anti-spoof ip-mac
sub-sla-mgmt
--- snip --exit
exit
sap 1/1/2:212 create
anti-spoof ip-mac
sub-sla-mgmt
--- snip --exit
exit
pppoe
--- snip --no shutdown
exit
exit
group-interface "grp-int-2-2" create

Page 1810

Advanced Configuration Guide

Routed CO

ipv6
--- snip --exit
arp-populate
dhcp
--- snip --lease-populate 100
no shutdown
exit
authentication-policy "auth-pol-1"
sap 1/1/3:221 create
anti-spoof ip-mac
sub-sla-mgmt
--- snip --exit
exit
sap 1/1/3:222 create
sub-sla-mgmt
anti-spoof ip-mac
sub-sla-mgmt
--- snip --exit
exit
exit
pppoe
--- snip --no shutdown
exit
exit
exit
no shutdown

The same mandatory and optional settings as for the numbered scenario apply.

Advanced Configuration Guide

Page 1811

Configuration

Verification
The interfaces on the BNG are listed using following command. Notice that all subscriber and
group interfaces are operational up for IPv4 and IPv6.
A:BNG# show router "Base" interface
===============================================================================
Interface Table (Router: Base)
===============================================================================
Interface-Name
Adm
Opr(v4/v6) Mode
Port/SapId
IP-Address
PfxState
------------------------------------------------------------------------------grp-int-1-1
Up
Up/Up
IES Grp 1/1/1
grp-int-1-2
Up
Up/Up
IES Grp 1/1/1
grp-int-2-1
Up
Up/Up
IES Grp 1/1/2
grp-int-2-2
Up
Up/Up
IES Grp 1/1/3
lb-pool4-1
Up
Up/Down
Network loopback
10.1.1.254/24
n/a
lb-pool4-2
Up
Up/Down
Network loopback
10.1.2.254/24
n/a
lb-pool4-3
Up
Up/Down
Network loopback
10.2.1.254/24
n/a
lb-pool4-4
Up
Up/Down
Network loopback
10.2.2.254/24
n/a
sub-int-1
Up
Up/Up
IES Sub subscriber
Unnumbered If[system]
n/a
FE80::EA:4B:FF/64
PREFERRED
sub-int-2
Up
Up/Up
IES Sub subscriber
Unnumbered If[system]
n/a
FE80::EA:4B:FF/64
PREFERRED
system
Up
Up/Up
Network system
192.0.2.75/32
n/a
2001:DB8::75/128
PREFERRED
toDHCP-1
Up
Up/Up
Network loopback
10.11.11.1/32
n/a
2001:DB8::11/128
PREFERRED
FE80::E84B:FFFF:FE00:0/64
PREFERRED
toR1
Up
Up/Down
Network 1/1/12
192.168.12.1/24
n/a
toRADIUS-1
Up
Up/Down
Network 1/1/10
192.168.202.75/24
n/a
------------------------------------------------------------------------------Interfaces : 14
===============================================================================
A:BNG#

Page 1812

Advanced Configuration Guide

Routed CO

Successfully created hosts have forwarding state Fwding. Hosts not in the Fwding state cannot
forward any data.
*A:BNG# show service id 1 subscriber-hosts
=============================================================
Subscriber Host table
=============================================================
Sap
Subscriber
IP Address
MAC Address
PPPoE-SID Origin
Fwding State
------------------------------------------------------------1/1/1:111
sub-11
10.1.1.101
00:00:00:11:11:11
1
IPCP
Fwding
1/1/1:122
sub-22
10.2.2.1
00:00:00:22:22:22
N/A
DHCP
Fwding
1/1/1:122
sub-22
2001:DB8:101::1/128
00:00:00:22:22:22
N/A
IPoE-DHCP6
Fwding
1/1/1:122
sub-22
2001:DB8:102::/56
00:00:00:22:22:22
N/A
IPoE-DHCP6
Fwding
1/1/2:211
sub-33
10.2.2.2
00:00:00:33:33:33
N/A
DHCP
Fwding
1/1/2:211
sub-33
2001:DB8:101:1::1/128
00:00:00:33:33:33
N/A
IPoE-DHCP6
Fwding
1/1/2:211
sub-33
2001:DB8:102:100::/56
00:00:00:33:33:33
N/A
IPoE-DHCP6
Fwding
1/1/2:212
sub-44
10.1.1.102
00:00:00:44:44:44
1
IPCP
Fwding
------------------------------------------------------------Number of subscriber hosts : 8
=============================================================
*A:BNG#

A variant of the show service active-subscribers command shows the subscriber hierarchy.
*A:BNG# show service active-subscribers hierarchy
===============================================================================
Active Subscriber hierarchy
===============================================================================
-- sub-11 (sub-prof-1)
|
|-- sap:1/1/1:111 - sla:sla-prof-1
|
|
|
|-- 10.1.1.101
|
|
00:00:00:11:11:11 - 1 (IPCP)
|
|
-- sub-22 (sub-prof-1)
|

Advanced Configuration Guide

Page 1813

Configuration

|-|
|
|
|
|
|
|
|
|
|

sap:1/1/1:122 - sla:sla-prof-1
|
|-- 10.2.2.1
|
00:00:00:22:22:22 - N/A (DHCP)
|
|-- 2001:DB8:101::1/128
|
00:00:00:22:22:22 - N/A (IPoE-DHCP6)
|
|-- 2001:DB8:102::/56
|
00:00:00:22:22:22 - N/A (IPoE-DHCP6)
|

-- sub-33 (sub-prof-1)
|
|-- sap:1/1/2:211 - sla:sla-prof-1
|
|
|
|-- 10.2.2.2
|
|
00:00:00:33:33:33 - N/A (DHCP)
|
|
|
|-- 2001:DB8:101:1::1/128
|
|
00:00:00:33:33:33 - N/A (IPoE-DHCP6)
|
|
|
|-- 2001:DB8:102:100::/56
|
|
00:00:00:33:33:33 - N/A (IPoE-DHCP6)
|
|
-- sub-44 (sub-prof-1)
|
|-- sap:1/1/2:212 - sla:sla-prof-1
|
|
|
|-- 10.1.1.102
|
|
00:00:00:44:44:44 - 1 (IPCP)
|
|
===============================================================================
*A:BNG#

Manually cross-referencing the SAPs from this output with the actual configuration shows the
following for IPv4, and is represented in Figure 179.

Sub-11 and sub-44 share the same IPv4 subnet even though they are connected to different
subscriber interfaces.

Sub-22 and sub-33 share the same subnet even though they are connected to different
subscriber interfaces.

For IPv6 the situation is as follows:

Sub-22 and sub-33 are in different subscriber interfaces and do not share IPv6 prefixes in
this example.

With these subscriber hosts are connected, the IPv4 RIB for the base router looks as follows.
A:BNG# show router "Base" route-table ipv4
===============================================================================
Route Table (Router: Base)
===============================================================================

Page 1814

Advanced Configuration Guide

Routed CO

Dest Prefix[Flags]
Type
Proto
Age
Pref
Next Hop[Interface Name]
Metric
------------------------------------------------------------------------------10.1.1.0/24
Local
Local
00h49m42s 0
lb-pool4-1
0
10.1.1.101/32
Remote Sub Mgmt 00h23m24s 0
[grp-int-1-1]
0
10.1.1.102/32
Remote Sub Mgmt 00h02m32s 0
[grp-int-2-1]
0
10.1.2.0/24
Local
Local
00h49m42s 0
lb-pool4-2
0
10.2.1.0/24
Local
Local
00h49m42s 0
lb-pool4-3
0
10.2.2.0/24
Local
Local
00h49m42s 0
lb-pool4-4
0
10.2.2.1/32
Remote Sub Mgmt 00h27m18s 0
[grp-int-1-2]
0
10.2.2.2/32
Remote Sub Mgmt 00h27m10s 0
[grp-int-2-1]
0
10.11.11.1/32
Local
Local
00h49m42s 0
toDHCP-1
0
192.0.2.75/32
Local
Local
00h49m42s 0
system
0
192.0.2.76/32
Remote ISIS
00h41m48s 15
192.168.12.2
10
192.168.12.0/24
Local
Local
00h49m24s 0
toR1
0
192.168.202.0/24
Local
Local
00h49m24s 0
toRADIUS-1
0
------------------------------------------------------------------------------No. of Routes: 13
Flags: L = LFA nexthop available
B = BGP backup route available
n = Number of times nexthop is repeated
===============================================================================
A:BNG#

The IPv6 RIB for the base router looks as follows.


.A:BNG# show router "Base" route-table ipv6
===============================================================================
IPv6 Route Table (Router: Base)
===============================================================================
Dest Prefix[Flags]
Type
Proto
Age
Pref
Next Hop[Interface Name]
Metric
------------------------------------------------------------------------------2001:DB8::11/128
Local
Local
01h03m27s 0
toDHCP-1
0
2001:DB8::75/128
Local
Local
00h06m34s 0
system
0
2001:DB8:101::1/128
Remote Sub Mgmt 00h36m12s 0
[grp-int-1-2]
0
2001:DB8:101:1::1/128
Remote Sub Mgmt 00h35m58s 0
[grp-int-2-1]
0
2001:DB8:102::/56
Remote Sub Mgmt 00h36m12s 0
[grp-int-1-2]
0
2001:DB8:102:100::/56
Remote Sub Mgmt 00h35m58s 0
[grp-int-2-1]
0
-------------------------------------------------------------------------------

Advanced Configuration Guide

Page 1815

Configuration

No. of Routes: 6
Flags: L = LFA nexthop available
B = BGP backup route available
n = Number of times nexthop is repeated
===============================================================================
A:BNG# #

The corresponding IPv4 FIB on card 1 looks as follows.


A:BNG# show router "Base" fib 1 ipv4
===============================================================================
FIB Display
===============================================================================
Prefix
Protocol
NextHop
------------------------------------------------------------------------------10.1.1.0/24
LOCAL
10.1.1.0 (lb-pool4-1)
10.1.1.101/32
LOCAL
10.1.1.101 (sub-int-1)
10.1.1.102/32
LOCAL
10.1.1.102 (sub-int-2)
10.1.2.0/24
LOCAL
10.1.2.0 (lb-pool4-2)
10.2.1.0/24
LOCAL
10.2.1.0 (lb-pool4-3)
10.2.2.0/24
LOCAL
10.2.2.0 (lb-pool4-4)
10.2.2.1/32
LOCAL
10.2.2.1 (sub-int-1)
10.2.2.2/32
LOCAL
10.2.2.2 (sub-int-2)
10.11.11.1/32
LOCAL
10.11.11.1 (toDHCP-1)
192.0.2.75/32
LOCAL
192.0.2.75 (system)
192.0.2.76/32
ISIS
192.168.12.2 (toR1)
192.168.12.0/24
LOCAL
192.168.12.0 (toR1)
192.168.202.0/24
LOCAL
192.168.202.0 (toRADIUS-1)
------------------------------------------------------------------------------Total Entries : 13
------------------------------------------------------------------------------===============================================================================
A:BNG#

Page 1816

Advanced Configuration Guide

Routed CO

The corresponding IPv6 FIB on card 1 looks as follows:


A:BNG# show router "Base" fib 1 ipv6
===============================================================================
FIB Display
===============================================================================
Prefix
Protocol
NextHop
------------------------------------------------------------------------------2001:DB8::11/128
LOCAL
2001:DB8::11 (toDHCP-1)
2001:DB8::75/128
LOCAL
2001:DB8::75 (system)
2001:DB8:101::1/128
LOCAL
2001:DB8:101::1 (sub-int-1)
2001:DB8:101:1::1/128
LOCAL
2001:DB8:101:1::1 (sub-int-2)
2001:DB8:102::/56
LOCAL
2001:DB8:102:: (sub-int-1)
2001:DB8:102:100::/56
LOCAL
2001:DB8:102:100:: (sub-int-2)
------------------------------------------------------------------------------Total Entries : 6
------------------------------------------------------------------------------===============================================================================
A:BNG#

The addresses of the individual subscriber hosts appear in the RIB and the FIB, which is the main
difference with the numbered model. The forwarding plane here needs the individual addresses to
forward the traffic towards the individual subscriber hosts.

Advanced Configuration Guide

Page 1817

Configuration

Hybrid Scenario
An alternative to the scenarios described above does exist in the form of a mixed numbered/
unnumbered (hybrid) scenario as depicted in Figure 180.
The subscriber interface is configured with

One or more IPv4 subnets and/or IPv6 subscriber prefixes.

For IPv4: the keyword allow-unmatching-subnets.

For IPv6: the keyword allow-unmatching-prefixes.

No explicit configuration is shown as it is a mix of the numbered and the unnumbered scenario
described above, and as such the behavior is mixed.

1/1/1
1/1/1:111
grp-int-1-1

IES 1

sub-int-1

1/1/1:112

1/1/1:121
grp-int-1-2
1/1/1:122

allow-unmatching-subnets
10.1.1.254/24
10.1.2.254/24
allow-unmatching-prefixes
2001:db8:101::/48
2001:db8:102::/48

v4
v6

1/1/2
1/1/2:211
grp-int-2-1

sub-int-2

1/1/2:212
1/1/3
1/1/3:221
grp-int-2-2

allow-unmatching-subnets
10.2.1.254/24
10.2.2.254/24
allow-unmatching-prefixes
2001:db8:201::/48
2001:db8:202::/48

v4
v6

1/1/3:222

BNG

al_0383

Figure 180: Hybrid Configuration

Page 1818

Advanced Configuration Guide

Routed CO

Host IP Reachability
To ensure reachability to the individual subscriber hosts, the subnets and prefixes of the subscriber
interfaces/subscriber hosts need to be distributed to other routers in the network.
Three options are available:

Without an export policy.

With an export policy using, for example, from protocol direct.

With an export policy using, for example, from protocol sub-mgmt.

Option 1 No Export Policy


The key properties for the first option are:

Subscriber interface subnets and prefixes are distributed into the network by adding the
subscriber interfaces as passive interfaces to the routing protocol.

It is used in combination with IGP based route distribution.

It works with the numbered model only.

In this option the BNG uses IS-IS as IGP and no export policy is needed.
configure
router
isis
area-id 48.0001
multi-topology
ipv6-unicast
exit
interface "system"
no shutdown
exit
interface "sub-int-1"
passive
no shutdown
exit
interface "sub-int-2"
passive
no shutdown
exit
interface "toR1"
interface-type point-to-point
no shutdown
exit
no shutdown
exit

Advanced Configuration Guide

Page 1819

Configuration

The corresponding IPv4 RIB on router R1 (from Figure 177) lists the subscriber-interface subnets,
not the individual subscriber host addresses.
A:R1# show router "Base" route-table ipv4
===============================================================================
Route Table (Router: Base)
===============================================================================
Dest Prefix[Flags]
Type
Proto
Age
Pref
Next Hop[Interface Name]
Metric
------------------------------------------------------------------------------10.1.1.0/24
Remote ISIS
00h14m11s 15
192.168.12.1
20
10.1.2.0/24
Remote ISIS
00h14m11s 15
192.168.12.1
20
10.2.1.0/24
Remote ISIS
00h14m05s 15
192.168.12.1
20
10.2.2.0/24
Remote ISIS
00h14m05s 15
192.168.12.1
20
192.0.2.75/32
Remote ISIS
00h14m17s 15
192.168.12.1
10
192.0.2.76/32
Local
Local
62d21h22m 0
system
0
192.168.12.0/24
Local
Local
05d04h43m 0
toBNG
0
------------------------------------------------------------------------------No. of Routes: 7
Flags: L = LFA nexthop available
B = BGP backup route available
n = Number of times nexthop is repeated
===============================================================================
A:R1#

The corresponding IPv6 RIB on router R1 lists the subscriber-interface prefixes, not the individual
subscriber host addresses/prefixes.
A:R1# show router "Base" route-table ipv6
===============================================================================
IPv6 Route Table (Router: Base)
===============================================================================
Dest Prefix[Flags]
Type
Proto
Age
Pref
Next Hop[Interface Name]
Metric
------------------------------------------------------------------------------2001:DB8::75/128
Remote ISIS
00h04m25s 15
FE80::E84B:FFFF:FE00:0-"toBNG"
10
2001:DB8::76/128
Local
Local
02d05h54m 0
system
0
2001:DB8:101::/48
Remote ISIS
00h04m25s 15
FE80::E84B:FFFF:FE00:0-"toBNG"
20
2001:DB8:102::/48
Remote ISIS
00h04m25s 15
FE80::E84B:FFFF:FE00:0-"toBNG"
20
2001:DB8:201::/48
Remote ISIS
00h04m25s 15
FE80::E84B:FFFF:FE00:0-"toBNG"
20
2001:DB8:202::/48
Remote ISIS
00h04m25s 15
FE80::E84B:FFFF:FE00:0-"toBNG"
20
2001:DEAD::/64
Local
Local
01h42m18s 0
toBNG
0
------------------------------------------------------------------------------No. of Routes: 7

Page 1820

Advanced Configuration Guide

Routed CO

Flags: L = LFA nexthop available


B = BGP backup route available
n = Number of times nexthop is repeated
===============================================================================
A:R1#

Alternatively the same result can be achieved with OSPF/OSPFv3.

Option 2 Export Policy (from protocol direct)


The key properties for the second option are:

Subscriber interface subnets and prefixes are distributed into the network by applying an
export policy.

It is most typically used in combination with BGP based route distribution.

It works with the numbered model only.

The following export policy is used for this example.


configure
router
policy-options
policy-statement "local-subnets-out"
entry 10
from
protocol direct
exit
action accept
exit
exit
exit

In this option the BNG relies on BGP using the policy local-subnets-out as an export policy. The
neighbor address is the IPv4 system address of router R1.
configure
router
autonomous-system 65536
bgp
group "grp-1"
family ipv4 ipv6
export "local-subnets-out"
peer-as 65536
neighbor 192.0.2.76
advertise-label ipv6
exit
exit
no shutdown
exit

Advanced Configuration Guide

Page 1821

Configuration

The following command shows the IPv4 routes advertised by applying the local-subnets-out
policy. The subscriber interface subnets are advertised, as are some other local subnets.
*A:BNG# show router bgp neighbor 192.0.2.76 advertised-routes ipv4
===============================================================================
BGP Router ID:192.0.2.75
AS:65536
Local AS:65536
===============================================================================
Legend Status codes : u - used, s - suppressed, h - history, d - decayed, * - valid
Origin codes : i - IGP, e - EGP, ? - incomplete, > - best, b - backup
===============================================================================
BGP IPv4 Routes
===============================================================================
Flag Network
LocalPref
MED
Nexthop
Path-Id
Label
As-Path
------------------------------------------------------------------------------i
10.1.1.0/24
100
None
192.0.2.75
None
No As-Path
i
10.1.2.0/24
100
None
192.0.2.75
None
No As-Path
i
10.2.1.0/24
100
None
192.0.2.75
None
No As-Path
i
10.2.2.0/24
100
None
192.0.2.75
None
No As-Path
i
10.11.11.1/32
100
None
192.0.2.75
None
No As-Path
i
192.0.2.75/32
100
None
192.0.2.75
None
No As-Path
i
192.168.12.0/24
100
None
192.0.2.75
None
No As-Path
i
192.168.202.0/24
100
None
192.0.2.75
None
No As-Path
------------------------------------------------------------------------------Routes : 8
===============================================================================
*A:BNG#

The same applies for IPv6.


*A:BNG# show router bgp neighbor 192.0.2.76 advertised-routes ipv6
===============================================================================
BGP Router ID:192.0.2.75
AS:65536
Local AS:65536
===============================================================================
Legend Status codes : u - used, s - suppressed, h - history, d - decayed, * - valid
Origin codes : i - IGP, e - EGP, ? - incomplete, > - best, b - backup
===============================================================================
BGP IPv6 Routes

Page 1822

Advanced Configuration Guide

Routed CO

===============================================================================
Flag Network
LocalPref
MED
Nexthop
Path-Id
Label
As-Path
------------------------------------------------------------------------------i
2001:DB8::11/128
100
None
::FFFF:C000:24B
None
2
No As-Path
i
2001:DB8::75/128
100
None
::FFFF:C000:24B
None
2
No As-Path
i
2001:DB8:101::/48
100
None
::FFFF:C000:24B
None
2
No As-Path
i
2001:DB8:102::/48
100
None
::FFFF:C000:24B
None
2
No As-Path
i
2001:DB8:201::/48
100
None
::FFFF:C000:24B
None
2
No As-Path
i
2001:DB8:202::/48
100
None
::FFFF:C000:24B
None
2
No As-Path
i
2001:DEAD::/64
100
None
::FFFF:C000:24B
None
2
No As-Path
------------------------------------------------------------------------------Routes : 7
===============================================================================
*A:BNG#

The corresponding IPv4 RIB on router R1 lists the subscriber-interface subnets, not the individual
subscriber host addresses. Notice the list also includes other routes local to the BNG.
*A:R1# show router "Base" route-table ipv4
===============================================================================
Route Table (Router: Base)
===============================================================================
Dest Prefix[Flags]
Type
Proto
Age
Pref
Next Hop[Interface Name]
Metric
------------------------------------------------------------------------------10.1.1.0/24
Remote BGP
00h13m34s 170
192.168.12.1
0
10.1.2.0/24
Remote BGP
00h13m34s 170
192.168.12.1
0
10.2.1.0/24
Remote BGP
00h13m34s 170
192.168.12.1
0
10.2.2.0/24
Remote BGP
00h13m34s 170
192.168.12.1
0
10.11.11.1/32
Remote BGP
00h13m34s 170
192.168.12.1
0
192.0.2.75/32
Remote ISIS
00h15m38s 15
192.168.12.1
10
192.0.2.76/32
Local
Local
03h11m54s 0
system
0
192.168.12.0/24
Local
Local
03h11m25s 0
toBNG
0

Advanced Configuration Guide

Page 1823

Configuration

192.168.202.0/24
Remote BGP
00h13m34s 170
192.168.12.1
0
------------------------------------------------------------------------------No. of Routes: 9
Flags: L = LFA nexthop available
B = BGP backup route available
n = Number of times nexthop is repeated
===============================================================================
*A:R1#

The corresponding IPv6 RIB on router R1 lists the subscriber-interface prefixes, not the individual
subscriber host addresses/prefixes. They are tunneled through the IPv4 core.
*A:R1# show router "Base" route-table ipv6
===============================================================================
IPv6 Route Table (Router: Base)
===============================================================================
Dest Prefix[Flags]
Type
Proto
Age
Pref
Next Hop[Interface Name]
Metric
------------------------------------------------------------------------------2001:DB8::11/128
Remote BGP
00h00m49s 170
192.0.2.75 (tunneled)
0
2001:DB8::75/128
Remote ISIS
00h54m05s 15
FE80::E84B:FFFF:FE00:0-"toBNG"
10
2001:DB8::76/128
Local
Local
05h18m12s 0
system
0
2001:DB8:101::/48
Remote BGP
00h00m49s 170
192.0.2.75 (tunneled)
0
2001:DB8:102::/48
Remote BGP
00h00m49s 170
192.0.2.75 (tunneled)
0
2001:DB8:201::/48
Remote BGP
00h00m49s 170
192.0.2.75 (tunneled)
0
2001:DB8:202::/48
Remote BGP
00h00m49s 170
192.0.2.75 (tunneled)
0
2001:DEAD::/64
Local
Local
05h17m42s 0
toBNG
0
------------------------------------------------------------------------------No. of Routes: 8
Flags: L = LFA nexthop available
B = BGP backup route available
n = Number of times nexthop is repeated
===============================================================================
*A:R1# #

The same export policy can be used in combination with IGP based route distribution. However,
when IGP based route distribution is needed option 1 is the preferred method.

Page 1824

Advanced Configuration Guide

Routed CO

Option 3 Export Protocol (from protocol sub-mgmt)


The key properties for the third option are:

Host addresses and prefixes are distributed into the network by applying an export policy.

It is most typically used in combination with BGP based route distribution, as IGP based
route distribution does not scale for a large number of subscribers.

It is most typically used for the unnumbered model, and in some cases for the numbered
model.

The following export policy is used for this option.


configure
router
policy-options
policy-statement "subsc-hosts-out"
entry 10
from
protocol sub-mgmt
exit
action accept
exit
exit
exit

In this option the BNG relies on BGP using the policy subsc-hosts-out as an export policy.
configure
router
autonomous-system 65536
bgp
group "grp-1"
family ipv4 ipv6
export "subsc-hosts-out"
peer-as 65536
neighbor 192.0.2.76
advertise-label ipv6
exit
exit
no shutdown
exit

Advanced Configuration Guide

Page 1825

Configuration

The following command shows the IPv4 routes advertised by applying the subsc-hosts-out policy.
Now the subscriber host addresses are advertised individually.
*A:BNG# show router bgp neighbor 192.0.2.76 advertised-routes ipv4
===============================================================================
BGP Router ID:192.0.2.75
AS:65536
Local AS:65536
===============================================================================
Legend Status codes : u - used, s - suppressed, h - history, d - decayed, * - valid
Origin codes : i - IGP, e - EGP, ? - incomplete, > - best, b - backup
===============================================================================
BGP IPv4 Routes
===============================================================================
Flag Network
LocalPref
MED
Nexthop
Path-Id
Label
As-Path
------------------------------------------------------------------------------?
10.1.1.101/32
100
0
192.0.2.75
None
No As-Path
?
10.1.1.102/32
100
0
192.0.2.75
None
No As-Path
?
10.2.2.1/32
100
0
192.0.2.75
None
No As-Path
?
10.2.2.2/32
100
0
192.0.2.75
None
No As-Path
------------------------------------------------------------------------------Routes : 4
===============================================================================
*A:BNG#

For IPv6, the host addresses and prefixes are advertised.


*A:BNG# show router bgp neighbor 192.0.2.76 advertised-routes ipv6
===============================================================================
BGP Router ID:192.0.2.75
AS:65536
Local AS:65536
===============================================================================
Legend Status codes : u - used, s - suppressed, h - history, d - decayed, * - valid
Origin codes : i - IGP, e - EGP, ? - incomplete, > - best, b - backup
===============================================================================
BGP IPv6 Routes
===============================================================================
Flag Network
LocalPref
MED
Nexthop
Path-Id
Label
As-Path
------------------------------------------------------------------------------?
2001:DB8:101::1/128
100
0
::FFFF:C000:24B
None
2
No As-Path
?
2001:DB8:101:1::1/128
100
0
::FFFF:C000:24B
None
2
No As-Path

Page 1826

Advanced Configuration Guide

Routed CO

2001:DB8:102::/56
100
0
::FFFF:C000:24B
None
2
No As-Path
?
2001:DB8:102:100::/56
100
0
::FFFF:C000:24B
None
2
No As-Path
------------------------------------------------------------------------------Routes : 4
===============================================================================
*A:BNG#

The corresponding IPv4 RIB on router R1 looks as follows. Notice the individual host addresses
do appear.
A:R1# show router route-table ipv4
===============================================================================
Route Table (Router: Base)
===============================================================================
Dest Prefix[Flags]
Type
Proto
Age
Pref
Next Hop[Interface Name]
Metric
------------------------------------------------------------------------------10.1.1.101/32
Remote BGP
00h40m49s 170
192.168.12.1
0
10.1.1.102/32
Remote BGP
00h19m53s 170
192.168.12.1
0
10.2.2.1/32
Remote BGP
00h44m49s 170
192.168.12.1
0
10.2.2.2/32
Remote BGP
00h44m17s 170
192.168.12.1
0
192.0.2.75/32
Remote ISIS
00h59m41s 15
192.168.12.1
10
192.0.2.76/32
Local
Local
01h22m11s 0
system
0
192.168.12.0/24
Local
Local
01h21m42s 0
toBNG
0
------------------------------------------------------------------------------No. of Routes: 7
Flags: L = LFA nexthop available
B = BGP backup route available
n = Number of times nexthop is repeated
===============================================================================
A:R1#

The corresponding IPv6 RIB on router R1 looks as follows. Notice the individual host addresses
and prefixes are distributed in this case.
A:R1# show router route-table ipv6
===============================================================================
IPv6 Route Table (Router: Base)
===============================================================================
Dest Prefix[Flags]
Type
Proto
Age
Pref
Next Hop[Interface Name]
Metric
------------------------------------------------------------------------------2001:DB8::76/128
Local
Local
01h22m16s 0
system
0
2001:DB8:101::1/128
Remote BGP
00h36m40s 170
192.0.2.75 (tunneled)
0

Advanced Configuration Guide

Page 1827

Configuration

2001:DB8:101:1::1/128
Remote BGP
00h36m40s 170
192.0.2.75 (tunneled)
0
2001:DB8:102::/56
Remote BGP
00h36m40s 170
192.0.2.75 (tunneled)
0
2001:DB8:102:100::/56
Remote BGP
00h36m40s 170
192.0.2.75 (tunneled)
0
2001:DEAD::/64
Local
Local
01h21m47s 0
toBNG
0
------------------------------------------------------------------------------No. of Routes: 6
Flags: L = LFA nexthop available
B = BGP backup route available
n = Number of times nexthop is repeated
===============================================================================
A:R1#

Page 1828

Advanced Configuration Guide

Routed CO

Conclusion
This example explains how to configure and use the Routed CO model. The subscriber and the
group interfaces were configured for the numbered, unnumbered and hybrid scenario, showing the
flexibility of the Routed CO model in terms of subnet/prefix assignment as well as the impact on
the forwarding and the reachability to and from the subscriber hosts.

Advanced Configuration Guide

Page 1829

Conclusion

Page 1830

Advanced Configuration Guide

RSVP Signalled Point-to-Multipoint LSPs

In This Chapter
This section provides information about RSVP signaled point-to-multipoint LSPs.
Topics in this section include:

Applicability on page 1832

Overview on page 1833

Configuration on page 1835

Conclusion on page 1876

Advanced Configuration Guide

Page 1831

Applicability

Applicability
This feature is applicable to all of the 7750 and 7710 SR series (except SR-1). Tested on release
7.0R5. On all nodes involved with the LSP, at least chassis mode C is required. This means that
modular systems should be equipped with IOM-2 linecards or higher. This is supported on 7450
ESS-7 or ESS-12 in mixed-mode since 8.0R1. The 7750 SR-c4 is supported from 8.0R4 and
higher.

Page 1832

Advanced Configuration Guide

RSVP Signalled Point-to-Multipoint LSPs

Overview
Point-to-MultiPoint (P2MP) MPLS label switched path (LSP) allows the source of multicast
traffic to forward packets to one or many multicast receivers over a network without requiring a
multicast protocol, such as PIM, to be configured in the network. A P2MP LSP tree is established
in the control plane which path consists of a head-end node, one or many branch and BUD nodes,
and the leaf nodes. Packets injected by the head-end node are replicated in the data plane at the
branching nodes before they are delivered to the leaf nodes.
Similar to point-to-point (P2P) LSPs, also P2MP LSPs are unidirectional, originating on a headend node (the ingress LER) and terminating on one or more leaf node(s) (the egress LER(s)).
Initially, RSVP is used as signaling protocol. A P2MP LSP is modeled as a set of root-to-leaf sub
LSPs (S2L). Each S2L is modeled as a point-to-point LSP in the control plane. This means that
each S2L has its own PATH/RESV messages. This is called the de-aggregated method.
The forwarding of multicast packets to the LSP tree is based on static multicast routes initially but
will evolve to BGP based VPN routes in the future. Forwarding multicast packets is initially done
over P2MP RSVP LSPs in the base router instance but will evolve to VPRNs.
RSVP signalled P2MP LSPs can have fast reroute (FRR) enabled, the facility method (one-tomany) with link protection is supported.

Advanced Configuration Guide

Page 1833

Overview

PE-1 1/1/1
182.0.2.1 .1 192.168.9.0/30

.2

MC-source

1/1/3 .1 .1 1/1/2
192.168.12.0/30

192.168.13.0/30

1/1/3 .2

.2 1/1/3

PE-2 1/1/4
182.0.2.2 .1

192.168.23.0/30

1/1/2 .1

.1 1/1/1

192.168.24.0/30

192.168.35.0/30

1/1/2 .2

.2 1/1/1

PE-4 1/1/3
182.0.2.4 .1

192.168.45.0/30

1/1/4 .1

192.168.57.0/30

1/1/5 .2

MC-client2

1/1/2 PE-5
.2 182.0.2.5
.1 1/1/3

192.168.46.0/30

1/1/6 PE-6 1/1/3


.2 192.168.11.0/30 .1 182.0.2.6 .1

1/1/4 PE-3
.2 182.0.2.3

.2 1/1/3

192.168.67.0/30

1/1/4 PE-7 1/1/6


.2 182.0.2.7 .1 192.168.10.0/30 .2

MC-client1
OSSG362

Figure 181: P2MP Network Topology

Page 1834

Advanced Configuration Guide

RSVP Signalled Point-to-Multipoint LSPs

Configuration
The following sections describe the tasks you must perform to configure RSVP signaled point-tomultipoint LSPs.

Configuring the IP/MPLS Network


After configuring the cards and MDAs, the correct chassis-mode must be set (C or higher) on all
MPLS nodes along the P2MP LSP.
A:PE-[1..7]# configure system chassis-mode c
A:PE-[1..7]# show chassis | match chassis mode
Admin chassis mode
: c
Oper chassis mode
: c

The system addresses and L3 interface addresses are configured according to Figure 181. An
interior gateway protocol (IGP) is needed to distribute routing information on all PEs. In our case,
the IGP is OSPF using the backbone area (area 0.0.0.0). A configuration example is shown for
PE-1. A similar configuration is needed on all 7 PEs
A:PE-1# configure router
interface "int-PE-1-PE-2"
address 192.168.12.1/30
port 1/1/3
exit
interface "int-PE-1-PE-3"
address 192.168.13.1/30
port 1/1/2
exit
interface "system"
address 192.0.2.1/32
exit
A:PE-1# configure router
ospf
traffic-engineering
area 0.0.0.0
interface "system"
exit
interface "int-PE-1-PE-3"
interface-type point-to-point
exit
interface "int-PE-1-PE-2"
interface-type point-to-point
exit
exit
exit

Advanced Configuration Guide

Page 1835

Configuration

Since fast reroute (FRR) will be enabled on the P2MP LSP, traffic engineering (TE) is needed on
the IGP. By doing this, OSPF will generate opaque LSAs which are collected in a traffic
engineering database (TED), separate from the traditional OSPF topology database. OSPF
interfaces are setup as type point-to-point to improve convergence, no DR/BDR election process
is done.1
In our example on PE-1, the interface towards the multicast source is configured as an IES service.
This could have been on a router interface instead.
Similar IES services are configured on PE-7 and PE-6 for multicast client 1 and multicast client 2.
A:PE-1 # configure service

ies 1 customer 1 create


interface "to-MC-source" create
address 192.168.9.1/30
sap 1/1/1 create
exit
exit
no shutdown
exit
A:PE-7# configure service

ies 1 customer 1 create


interface "to-MC-client1" create
address 192.168.10.1/30
sap 1/1/6 create
exit
exit
no shutdown
exit
A:PE-6# configure service

ies 1 customer 1 create


interface "to-MC-client2" create
address 192.168.11.1/30
sap 1/1/6 create
exit
exit
no shutdown
exit

1.

Page 1836

Convergence is out of the scope of this configuration note.

Advanced Configuration Guide

RSVP Signalled Point-to-Multipoint LSPs

To verify that OSPF neighbors are up (state Full), show router ospf neighbor is performed. To
check if L3 interface addresses/subnets are known on all PEs, show router route-table or show
router fib iom-card-slot will display the content of the forwarding information base (FIB).
A:PE-1# show router ospf neighbor
===============================================================================
OSPF Neighbors
===============================================================================
Interface-Name
Rtr Id
State
Pri RetxQ
TTL
------------------------------------------------------------------------------int-PE-1-PE-3
192.0.2.3
Full
1
0
36
int-PE-1-PE-2
192.0.2.2
Full
1
0
32
------------------------------------------------------------------------------No. of Neighbors: 2
===============================================================================
A:PE-1# show router route-table
===============================================================================
Route Table (Router: Base)
===============================================================================
Dest Prefix
Type
Proto
Age
Pref
Next Hop[Interface Name]
Metric
------------------------------------------------------------------------------192.0.2.1/32
Local
Local
15d04h27m
0
system
0
192.0.2.2/32
Remote OSPF
01d22h28m
10
192.168.12.2
10000
192.0.2.3/32
Remote OSPF
01d22h27m
10
192.168.13.2
1000
192.0.2.4/32
Remote OSPF
01d22h24m
10
192.168.13.2
3000
192.0.2.5/32
Remote OSPF
01d22h24m
10
192.168.13.2
2000
192.0.2.6/32
Remote OSPF
01d22h23m
10
192.168.13.2
4000
192.0.2.7/32
Remote OSPF
01d22h22m
10
192.168.13.2
5000
192.168.12.0/30
Local
Local
01d22h31m
0
int-PE-1-PE-2
0
192.168.13.0/30
Local
Local
01d22h31m
0
int-PE-1-PE-3
0
192.168.23.0/30
Remote OSPF
01d22h27m
10
192.168.13.2
11000
192.168.24.0/30
Remote OSPF
01d22h24m
10
192.168.13.2
13000
192.168.35.0/30
Remote OSPF
01d22h26m
10
192.168.13.2
2000
192.168.45.0/30
Remote OSPF
01d22h24m
10
192.168.13.2
3000
192.168.46.0/30
Remote OSPF
01d22h24m
10
192.168.13.2
4000
192.168.57.0/30
Remote OSPF
01d22h24m
10
192.168.13.2
12000
192.168.67.0/30
Remote OSPF
01d22h23m
10
192.168.13.2
5000
------------------------------------------------------------------------------No. of Routes: 16
===============================================================================

Advanced Configuration Guide

Page 1837

Configuration

A:PE-1# show router fib 1


===============================================================================
FIB Display
===============================================================================
Prefix
Protocol
NextHop
------------------------------------------------------------------------------192.0.2.1/32
LOCAL
192.0.2.1 (system)
192.0.2.2/32
OSPF
192.168.12.2 (int-PE-1-PE-2)
192.0.2.3/32
OSPF
192.168.13.2 (int-PE-1-PE-3)
192.0.2.4/32
OSPF
192.168.13.2 (int-PE-1-PE-3)
192.0.2.5/32
OSPF
192.168.13.2 (int-PE-1-PE-3)
192.0.2.6/32
OSPF
192.168.13.2 (int-PE-1-PE-3)
192.0.2.7/32
OSPF
192.168.13.2 (int-PE-1-PE-3)
192.168.12.0/30
LOCAL
192.168.12.0 (int-PE-1-PE-2)
192.168.13.0/30
LOCAL
192.168.13.0 (int-PE-1-PE-3)
192.168.23.0/30
OSPF
192.168.13.2 (int-PE-1-PE-3)
192.168.24.0/30
OSPF
192.168.13.2 (int-PE-1-PE-3)
192.168.35.0/30
OSPF
192.168.13.2 (int-PE-1-PE-3)
192.168.45.0/30
OSPF
192.168.13.2 (int-PE-1-PE-3)
192.168.46.0/30
OSPF
192.168.13.2 (int-PE-1-PE-3)
192.168.57.0/30
OSPF
192.168.13.2 (int-PE-1-PE-3)
192.168.67.0/30
OSPF
192.168.13.2 (int-PE-1-PE-3)
------------------------------------------------------------------------------Total Entries : 16
------------------------------------------------------------------------------===============================================================================

Page 1838

Advanced Configuration Guide

RSVP Signalled Point-to-Multipoint LSPs

The next step in the process of setting up a P2MP LSP, is enabling our L3 interfaces in the MPLS
and RSVP context on all involved PE nodes (PE-1 <=> PE-7). By default, the system interface is
put automatically within the MPLS/RSVP context. When an interface is put in the MPLS context,
7x50 copies it also in the RSVP context. Explicit enabling of MPLS and RSVP context is done by
the no shutdown command. Below you can find the MPLS/RSVP configuration for PE-1.
A:PE-1# configure router mpls no shutdown
A:PE-1# configure router rsvp no shutdown
A:PE-1# configure router mpls
interface "system"
exit
interface "int-PE-1-PE-3"
exit
interface "int-PE-1-PE-2"
exit
no shutdown
A:PE-1# configure router rsvp
interface "system"
exit
interface "int-PE-1-PE-3"
exit
interface "int-PE-1-PE-2"
exit
no shutdown

Advanced Configuration Guide

Page 1839

Configuration

PE-1 1/1/1
Ingress LER
(head-end) 182.0.2.1 .1 192.168.9.0/30

227.1.1.1
.2

MC-source

1/1/3 .1 .1 1/1/2
192.168.12.0/30

192.168.13.0/30

1/1/3 .2

Transit LSR

.2 1/1/3

PE-2 1/1/4
182.0.2.2 .1

192.168.23.0/30

1/1/2 .1

192.168.35.0/30

1/1/2 .2

.2 1/1/1

PE-4 1/1/3
182.0.2.4 .1

192.168.45.0/30

1/1/4 .1

Egress LER
(leaf)

Transit LSR

192.168.57.0/30

1/1/5 .2

MC-client2

1/1/2 PE-5
.2 182.0.2.5
.1 1/1/3

192.168.46.0/30

1/1/6 PE-6 1/1/3


.2 192.168.11.0/30 .1 182.0.2.6 .1

Transit LSR

.1 1/1/1

192.168.24.0/30

Transit LSR

1/1/4 PE-3
.2 182.0.2.3

Bypass for S2L-path


to 192.0.2.7

.2 1/1/3

192.168.67.0/30

1/1/4 PE-7 1/1/6


.2 182.0.2.7 .1 192.168.10.0/30 .2

MC-client1

Egress LER
(leaf)
OSSG363

Figure 182: P2MP LSP LSP-p2mp-1

Page 1840

Advanced Configuration Guide

RSVP Signalled Point-to-Multipoint LSPs

Configuring P2MP RSVP LSP


See Figure 182 for a description of configuring PSMP LSPs.
A P2MP LSP (LSP-p2mp-1) will be setup from PE-1 acting as head-end node and PE-6 and PE-7
acting as leaf nodes. Because FRR is enabled, Constrained Shortest Path First (CSPF) is enabled
to do route calculations on the traffic engineering database (TED). FRR method facility is used
without node protection, facility stands for one-to-many meaning that one bypass tunnel can
protect a set of primary LSPs with similar backup constraints. When a link failure occurs on one of
the active S2L paths, the Point of Local Repair (PLR) node will push an additional MPLS label on
the incoming MPLS packet before sending it into the bypass tunnel downstream towards the
merge point (MP) node.
In the first example, OSPF (our IGP) will do the path calculation to the two destinations (PE-6 and
PE-7). The intermediate hops of the LSP are dynamically assigned by OSPF best route selection,
thus S2L paths follows the IGP least cost path. For this, an MPLS path loose is configured without
specifying any strict/loose hops.
A:PE-1# configure router mpls

path "loose"
no shutdown
exit

Creation of the P2MP LSP itself is done on the ingress LER or head-end node (PE-1 in our
example) and can be seen in following CLI output. P2MP name is LSP-p2mp-1. A create time
keyword p2mp-lsp is added in addition to the P2MP name to make a distinction in configuration
between normal point-to-point LSPs and point-to-multipoint LSPs. A primary P2MP instance is
initiated using the primary-p2mp-instance keyword accompanied with the P2MP instance name
p-LSP-p2mp-1. Within this primary P2MP instance, the different S2Ls are defined using the s2lpath keyword. Be aware that the same MPLS path name can be used for different S2Ls as long as
the destination is different (to command).
A:PE-1# configure router mpls

lsp "LSP-p2mp-1" p2mp-lsp


cspf
fast-reroute facility
no node-protect
exit
primary-p2mp-instance "p-LSP-p2mp-1"
s2l-path "loose" to 192.0.2.6
exit
s2l-path "loose" to 192.0.2.7
exit
exit
no shutdown
exit
no shutdown

Advanced Configuration Guide

Page 1841

Configuration

On the head-end LER node of the P2MP LSP, several show commands can be used. First set of
show commands are used to verify the administrative and operational state of the P2MP LSP and
his different S2L paths (including FRR bypass information). In our example, LSP-p2mp-1
P2MP LSP has two active S2L paths towards leaf node PE-6 and leaf node PE-7
A:PE-1# show router mpls p2mp-lsp
===============================================================================
MPLS P2MP LSPs
===============================================================================
LSP Name
P2mp-ID
Fastfail
Adm
Opr
Config
------------------------------------------------------------------------------LSP-p2mp-1
0
Yes
Up
Up
------------------------------------------------------------------------------LSPs : 1
===============================================================================

A:PE-1# show router mpls p2mp-lsp LSP-p2mp-1 detail


===============================================================================
MPLS P2MP LSPs (Originating) (Detail)
===============================================================================
------------------------------------------------------------------------------Type : Originating
------------------------------------------------------------------------------LSP Name
: LSP-p2mp-1
LSP Tunnel ID : 11
From
: 192.0.2.1
To
: 0.0.0.0
Adm State
:
LSP Up Time :
Transitions :
Retry Limit :
Signaling
:
Hop Limit
:
Adaptive
:
FastReroute :
FR Method
:
FR Bandwidth:
FR Object
:
CSPF
:
Metric
:
Include Grps:
None
Type
:
LdpOverRsvp :
Oper Metric :

Up
0d 00:08:20
1
0
RSVP
255
Enabled
Enabled
Facility
0 Mbps
Enabled
Enabled
Disabled

P2mpLsp
Disabled
Disabled

Oper State
:
LSP Down Time :
Path Changes
:
Retry Timer
:
Resv. Style
:
Negotiated MTU :
ClassType
:
Oper FR
:
FR Hop Limit
:
FR Node Protect:
ADSPEC
Use TE metric
Exclude Grps
None
Least Fill
VprnAutoBind

Up2
0d 00:00:00
1
30 sec
SE
n/a
0
Enabled
16
Disabled

: Disabled
: Disabled
:
: Disabled
: Disabled

P2MPInstance: p-LSP-p2mp-1
P2MP-Inst-type : Primary
S2l-Name
: loose
To
: 192.0.2.6
S2l-Name
: loose
To
: 192.0.2.7
===============================================================================

2.

Page 1842

As long as one S2L path is operationally up (show router mpls p2mp-lsp lsp-name p2mp-instance
instance-name) , the Oper State of the P2MP LSP is Up.

Advanced Configuration Guide

RSVP Signalled Point-to-Multipoint LSPs

A:PE-1# show router mpls p2mp-info


===============================================================================
MPLS P2MP Cross Connect Information
===============================================================================
------------------------------------------------------------------------------Source IP Address
: 192.0.2.1
Tunnel ID
: 11
P2MP ID
: 0
Lsp ID
: 27648
S2L Name
: LSP-p2mp-1::loose
To
: 192.0.2.6
Out Interface
: 1/1/2
Out Label
: 131068
Num. of S2ls
: 2
------------------------------------------------------------------------------S2L LSP-p2mp-1::loose
------------------------------------------------------------------------------Source IP Address
: 192.0.2.1
Tunnel ID
: 11
P2MP ID
: 0
Lsp ID
: 27648
S2L Name
: LSP-p2mp-1::loose
To
: 192.0.2.7
Out Interface
: 1/1/2
Out Label
: 131068
Num. of S2ls
: 2
------------------------------------------------------------------------------P2MP Cross-connect instances : 2
===============================================================================
A:PE-1# show router mpls p2mp-lsp LSP-p2mp-1 p2mp-instance p-LSP-p2mp-1
===============================================================================
MPLS P2MP Instance (Originating)
===============================================================================
------------------------------------------------------------------------------Type : Originating
------------------------------------------------------------------------------LSP Name
: LSP-p2mp-1
LSP Tunnel ID : 11
P2MP ID
: 0
Adm State
: Up
Oper State
: Up
P2MPInstance: p-LSP-p2mp-1
P2MP-Inst-type : Primary
P2MP Inst Id: 3
P2MP Lsp Id
: 27648
Inst Admin : Up
Inst Oper
: Up
Inst Up Time: 0d 00:12:14
Inst Dn Time
: 0d 00:00:00
Hop Limit
: 255
Adaptive
: Enabled
Record Route: Record
Record Label
: Record
Include Grps:
Exclude Grps
:
None
None
Bandwidth
: No Reservation
Oper Bw
: 0 Mbps
S2l-Name
: loose
To
: 192.0.2.6
S2l Admin
: Up
S2l Oper
: Up
S2l-Name
: loose
To
: 192.0.2.7
S2l Admin
: Up
S2l Oper
: Up
------------------------------------------------------------------------------P2MP instances : 1
===============================================================================

Advanced Configuration Guide

Page 1843

Configuration

FRR information can be displayed in detail for each S2L path. From this moment onward, we will
only focus on the S2L path towards PE-7. As you can see in the show command, link protection is
present for links PE-1 <=> PE-3, PE-3 <=> PE-5 and PE-5 <=> PE-7 (@-reference inside show
command).
A:PE-1# show router mpls p2mp-lsp LSP-p2mp-1 p2mp-instance p-LSP-p2mp-1 s2l loose to
192.0.2.7 detail
===============================================================================
MPLS LSP LSP-p2mp-1 S2L loose (Detail)
===============================================================================
Legend :
@ - Detour Available
# - Detour In Use
b - Bandwidth Protected
n - Node Protected
s - Soft Preemption
===============================================================================
------------------------------------------------------------------------------LSP LSP-p2mp-1 S2L loose
------------------------------------------------------------------------------LSP Name
: LSP-p2mp-1
S2l LSP ID : 27652
P2MP ID
: 0
S2l Grp Id : 2
Adm State
: Up
Oper State : Up
S2l State: : Active
:
S2L Name
: loose
To
: 192.0.2.7
S2l Admin
: Up
S2l Oper
: Up
OutInterface: 1/1/2
Out Label
: 131071
S2L Up Time : 0d 00:26:40
S2L Dn Time : 0d 00:00:00
RetryAttempt: 0
NextRetryIn : 0 sec
S2L Trans
: 3
CSPF Queries: 3
Failure Code: noError
Failure Node: n/a
ExplicitHops:
No Hops Specified
Actual Hops :
192.168.13.1(192.0.2.1) @
Record Label
: N/A
-> 192.168.13.2(192.0.2.3) @
Record Label
: 131071
-> 192.168.35.2(192.0.2.5) @
Record Label
: 131071
-> 192.168.57.2(192.0.2.7)
Record Label
: 131068
ComputedHops:
192.168.13.1
-> 192.168.13.2
-> 192.168.35.2
-> 192.168.57.2
LastResignal: n/a
===============================================================================

More in detail, show router mpls bypass-tunnel can be used. Actual Hops gives you the explicit
hops of the bypass tunnel used to avoid link PE-1 <=> PE-3. On PE-1 node the MPLS path PE-1
<=> PE-2 <=> PE-3 is followed (see also Figure 182).
A:PE-1# show router mpls bypass-tunnel protected-lsp p2mp detail
===============================================================================
MPLS Bypass Tunnels (Detail)
===============================================================================
------------------------------------------------------------------------------bypass-link192.168.13.2
------------------------------------------------------------------------------To
: 192.168.23.2
State
: Up
Out I/F
: 1/1/3
Out Label
: 131064
Up Time
: 1d 23:25:14
Active Time
: n/a

Page 1844

Advanced Configuration Guide

RSVP Signalled Point-to-Multipoint LSPs

Reserved BW
:
Type
:
SetupPriority
:
Class Type
:
Actual Hops
:
192.168.12.1

0 Kbps
P2mp
7
0
-> 192.168.12.2

Protected LSPs LSP Name


: LSP-p2mp-1::loose
From
: 192.0.2.1
Avoid Node/Hop : 192.168.13.2
Bandwidth
: 0 Kbps

Protected LSP Count : 3


Hold Priority

: 0

-> 192.168.23.2

To
Downstream Label

: 192.0.2.7
: 131071

On PE-3 node the MPLS path PE-3 <=> PE-2 <=> PE-4 <=> PE-5 is followed (see Figure 182 on
page 1840) to avoid link PE-3 <=> PE-5.
A:PE-3# show router mpls bypass-tunnel protected-lsp p2mp detail
===============================================================================
MPLS Bypass Tunnels (Detail)
===============================================================================
------------------------------------------------------------------------------bypass-link192.168.35.2
------------------------------------------------------------------------------To
: 192.168.45.2
State
: Up
Out I/F
: 1/1/4
Out Label
: 131071
Up Time
: 1d 23:28:31
Active Time
: n/a
Reserved BW
: 0 Kbps
Protected LSP Count : 3
Type
: P2mp
SetupPriority
: 7
Hold Priority
: 0
Class Type
: 0
Actual Hops
:
192.168.23.2
-> 192.168.23.1
-> 192.168.24.2
-> 192.168.45.2
Protected LSPs LSP Name
: LSP-p2mp-1::loose
From
: 192.0.2.1
Avoid Node/Hop : 192.168.35.2
Bandwidth
: 0 Kbps

To
Downstream Label

: 192.0.2.7
: 131071

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

A similar output can be seen on PE-5 node also. The MPLS path PE-5 <=> PE-4 <=> PE-6 <=>
PE-7 is followed (see also Figure 182).
On the transit LSRs and egress LER/leaf node (see also Figure 182), the show router mpls p2mpinfo command can be used. Attached is the show command on PE-3 node included for S2L path to
192.0.2.7. Similar outputs are possible for PE-5 and PE-7 node.
A:PE-3# show router mpls p2mp-info type transit
===============================================================================
MPLS P2MP LSPs (Transit)
===============================================================================
------------------------------------------------------------------------------S2L LSP-p2mp-1::loose
-------------------------------------------------------------------------------

Advanced Configuration Guide

Page 1845

Configuration

Source IP Address
: 192.0.2.1
Tunnel ID
: 11
P2MP ID
: 0
Lsp ID
: 27652
S2L Name
: LSP-p2mp-1::loose
To
: 192.0.2.7
Out Interface
: 1/1/1
Out Label
: 131071
Num. of S2ls
: 1
------------------------------------------------------------------------------P2MP Cross-connect instances : 1
===============================================================================

Page 1846

Advanced Configuration Guide

RSVP Signalled Point-to-Multipoint LSPs

Mapping Multicast Traffic


To map multicast traffic into the LSP tree from the head-end node until leaf node, PIM and IGMP
configurations are needed on the head-end node (PE-1) and leaf nodes (PE-6 and PE-7) of the
P2MP RSVP LSP. The intermediate nodes (transit LSR, branch LSR and BUD LSR) do not need
any explicit configuration for that.

Head-end Node (Ingress LER)


PIM must be enabled on the interface towards the MC source and PIM must be enabled on the
tunnel interface. A tunnel interface should be seen as an internal representation of a specific P2MP
LSP. Creation is done within the PIM context using the tunnel-interface rsvp-p2mp command
followed by the P2MP LSP name. Translated into configuration commands, this becomes :
A:PE-1# configure router pim

interface "to-MC-source"
exit
tunnel-interface rsvp-p2mp LSP-p2mp-1

In the data path, when a multicast packet is received on an interface a successful Reverse Path
Forwarding (RPF) check must be done for the source address otherwise the packet will be
dropped.
Besides enabling PIM on the tunnel interface also IGMP is enabled to do a static <S,G> or <*,G>
join of a multicast group address (227.1.1.1 in our example) to the tunnel interface/P2MP LSP. Be
aware that there is always a one-to-one mapping between <S,G> or <*,G> and a tunnel interface/
P2MP LSP. In our example a < S,G > will be configured. A <*,G> join scenario is included in
Additional Topics on page 1854.
A:PE-1# configure router igmp

tunnel-interface rsvp-p2mp "LSP-p2mp-1"


static
group 227.1.1.1
source 192.168.9.2
exit
exit
exit

Advanced Configuration Guide

Page 1847

Configuration

The show router pim tunnel-interface command shows you the admin state of the tunnel
interface and an association to an internal local ifindex (73730 in the example).
A:PE-1# show router pim tunnel-interface
===============================================================================
PIM Tunnel-Interfaces
===============================================================================
LSP
Sender Addr
IfIndex Oper
------------------------------------------------------------------------------LSP-p2mp-1
None
73730
Up
------------------------------------------------------------------------------Interfaces : 2
===============================================================================

With show router igmp group you see the configured <S,G> entry and outgoing interface (=
tunnel interface), represented by mpls-if-73730.
A:PE-1# show router igmp group 227.1.1.1
===============================================================================
IGMP Groups
===============================================================================
(192.168.9.2,227.1.1.1)
Up Time : 0d 00:06:27
Fwd List : mpls-if-73730
------------------------------------------------------------------------------(*,G)/(S,G) Entries : 1
===============================================================================

At this moment in time, users can verify if multicast traffic is using P2MP LSP at the head-end
node using the show router pim group group-address detail command
A:PE-1# show router pim group 227.1.1.1 detail
===============================================================================
PIM Source Group ipv4
===============================================================================
Group Address
: 227.1.1.1
Source Address
: 192.168.9.2
RP Address
: 192.0.2.1
Flags
: spt
Type
: (S,G)
MRIB Next Hop
: 192.168.9.2
MRIB Src Flags
: direct
Keepalive Timer Exp: 0d 00:03:29
Up Time
: 0d 00:08:59
Resolved By
: rtable-u
Up JP State
Up JP Rpt

: Joined
: Not Joined StarG

Register State
: Join
Reg From Anycast RP: No

Up JP Expiry
: 0d 00:00:00
Up JP Rpt Override : 0d 00:00:00
Register Stop Exp

: 0d 00:00:00

Discarded Packets

: 0

Rpf Neighbor
: 192.168.9.2
Incoming Intf
: to-MC-source
Outgoing Intf List : mpls-if-73730
Curr Fwding Rate
Forwarded Packets

Page 1848

: 14.7 kbps
: 649

Advanced Configuration Guide

RSVP Signalled Point-to-Multipoint LSPs

Forwarded Octets
: 29854
RPF Mismatches
: 0
Spt threshold
: 0 kbps
ECMP opt threshold : 7
Admin bandwidth
: 1 kbps
------------------------------------------------------------------------------Groups : 1
===============================================================================

Leaf Node (Egress LER)


In the PIM context, the same tunnel interface must be created as the head-end node with in
addition an explicit reference to the head-end system address, translated into the sender
systemIP_head-end_node parameter.
A:PE-7# configure router pim
tunnel-interface rsvp-p2mp LSP-p2mp-1 sender 192.0.2.1

The show router pim tunnel-interface command shows you the admin state of the tunnel
interface and an association to an internal local ifindex (73730 in our example, by coincidence the
same ifindex as the one on the head-end node/PE-1).
A:PE-7# show router pim tunnel-interface
===============================================================================
PIM Tunnel-Interfaces
===============================================================================
LSP
Sender Addr
If Index Oper
------------------------------------------------------------------------------LSP-p2mp-1
192.0.2.1
73730
Up
------------------------------------------------------------------------------Interfaces : 1
===============================================================================

The main goal on the leaf node(s) is to get traffic off the P2MP LSP/tunnel interface. This is done
using a multicast information policy (multicast-info-policy). Inside this MC policy, a range of
multicast group addresses must be defined under a bundle context (bundle1) in order to see traffic
(channel) . Also inside the bundle context, the P2MP LSP is presented by the tunnel interface
(primary-tunnel-interface). Translated into configuration commands, this becomes :
A:PE-7# configure mcast-management
multicast-info-policy "p2mp-pol" create
bundle "bundle1" create
primary-tunnel-interface rsvp-p2mp LSP-p2mp-1 sender 192.0.2.1
channel "227.1.1.1" "227.1.1.1" create
exit
exit
bundle "default" create
exit
exit

Advanced Configuration Guide

Page 1849

Configuration

Note: The channel command must be seen as a range command with a start-mc-group-address and
an end-mc-group-address. In our example, only one MC group address, 227.1.1.1 is seen.
The configured multicast information policy must be applied to the base router instance.
A:PE-7# configure router multicast-info-policy p2mp-pol

On the leaf node (PE-7/PE-6), MC clients are connected. IGMP is enabled on those MC clients
with a static <S,G> join to redirect MC traffic downstream to the MC client. Translated into
configuration commands, this becomes :
A:PE-7 # configure router igmp

interface "to-MC-client1"
static
group 227.1.1.1
source 192.168.9.2
exit
exit
exit

With show router igmp group you see the configured <S,G> entry and outgoing interface (= toMC-client1).
A:PE-7# show router igmp group 227.1.1.1
===============================================================================
IGMP Groups
===============================================================================
(192.168.9.2,227.1.1.1)
Up Time : 0d 00:00:43
Fwd List : to-MC-client1
------------------------------------------------------------------------------(*,G)/(S,G) Entries : 1
===============================================================================

Now, users can verify if multicast traffic is sent to MC client using the show router pim group
group-address detail command
A:PE-7# show router pim group 227.1.1.1 detail
===============================================================================
PIM Source Group ipv4
===============================================================================
Group Address
: 227.1.1.1
Source Address
: 192.168.9.2
RP Address
: 0
Flags
:
Type
: (S,G)
MRIB Next Hop
:
MRIB Src Flags
: remote
Keepalive Timer
: Not Running
Up Time
: 0d 00:27:43
Resolved By
: unresolved
Up JP State

Page 1850

: Joined

Up JP Expiry

: 0d 00:00:17

Advanced Configuration Guide

RSVP Signalled Point-to-Multipoint LSPs

Up JP Rpt

: Not Joined StarG

Up JP Rpt Override : 0d 00:00:00

Register State
: No Info
Reg From Anycast RP: No
Rpf Neighbor
:
Incoming Intf
: mpls-if-73730
Outgoing Intf List : to-MC-client1
Curr Fwding Rate
: 14.7 kbps
Forwarded Packets : 66340
Discarded Packets : 0
Forwarded Octets
: 3051640
RPF Mismatches
: 0
Spt threshold
: 0 kbps
ECMP opt threshold : 7
Admin bandwidth
: 1 kbps
------------------------------------------------------------------------------Groups : 1
===============================================================================

Advanced Configuration Guide

Page 1851

Configuration

OAM Tool
P2P LSP operation and maintenance (OAM) commands (oam lsp-ping and oam lsp-trace) are
extended for P2MP LSP. The user can instruct the head-end node to generate an P2MP LSP ping
or a P2MP LSP trace by entering the command oam p2mp-lsp-ping or oam p2mp-lsp-trace.
The P2MP OAM extensions are defined in draft-ietf-mpls-p2mp-lsp-ping.
For P2MP LSP ping, the echo request is sent on the active P2MP instance and is replicated in the
data path over all branches of the P2MP LSP instance. By default, all egress LER nodes which are
leaves of the P2MP LSP instance will reply. Echo reply messages can be reduced by configuring
the s2l-dest-address (a maximum of up to five egress nodes in a single run of the OAM
command). Replies are sent by IP.
A:PE-1# oam p2mp-lsp-ping
- p2mp-lsp-ping <lsp-name> [p2mp-instance <instance-name> [s2l-dest-address
<ip-address> [...(upto 5 max)]]] [fc <fc-name> [profile {in|out}]] [size
<octets>] [ttl <label-ttl>] [timeout <timeout>] [detail]
<lsp-name>
<instance-name>
<ip-address>
<profile>
<fc-name>
<octets>
<label-ttl>
<timeout>
<detail>

:
:
:
:
:
:
:
:
:

[32 chars max]


[32 chars max]
ipv4 address
a.b.c.d - Up to 5 addresses permitted
in|out - Default: out
be|l2|af|l1|h2|ef|h1|nc - Default: be
[92|97..9198]- Default: 92
[1..255] - Default: 255
[1..120] seconds - Default: 10
keyword - displays detailed information

A:PE-1# oam p2mp-lsp-ping LSP-p2mp-1 detail


P2MP LSP LSP-p2mp-1: 92 bytes MPLS payload
===============================================================================
S2L Information
===============================================================================
From
RTT
Return Code
------------------------------------------------------------------------------192.0.2.6
=3.35ms
EgressRtr(3)
192.0.2.7
=6.14ms
EgressRtr(3)
===============================================================================
Total S2L configured/up/responded = 2/2/2,
round-trip min/avg/max = 3.35 / 4.74 / 6.14 ms
Responses based on return code:
EgressRtr(3)=2

Note: Return codes are based on RFC4379, with value 3 => replying router is an egress for the
FEC at stack-depth.
P2MP LSP trace allows the user to trace the path of a single S2L path of a P2MP LSP from headend node to leaf node. By the use of the downstream mapping TLV, each node along the S2L path

Page 1852

Advanced Configuration Guide

RSVP Signalled Point-to-Multipoint LSPs

can fill in the appropriate flags : B or E flag. B-flag is set when responding node is a branch LSR,
E-flag is set when responding node is an egress LER.
A:PE-1# oam p2mp-lsp-trace
- p2mp-lsp-trace <lsp-name> p2mp-instance <instance-name> s2l-dest-address
<ip-address> [fc <fc-name> [profile {in|out}]] [size <octets>] [max-fail
<no-response-count>] [probe-count <probes-per-hop>] [min-ttl
<min-label-ttl>] [max-ttl <max-label-ttl>] [timeout <timeout>] [interval
<interval>] [detail]
<lsp-name>
<instance-name>
<ip-address>
<fc-name>
<profile>
<octets>
<no-response-count>
<probes-per-hop>
<min-label-ttl>
<max-label-ttl>
<timeout>
<detail>

:
:
:
:
:
:
:
:
:
:
:
:

[32 chars max]


[32 chars max]
ipv4 address
a.b.c.d
be|l2|af|l1|h2|ef|h1|nc - Default: be
in|out - Default: out
[128..9198] - Default: 128
[1..10] - Default: 5
[1..10] - Default: 1
[1..255] - Default: 1
[1..255] - Default: 30
[1..60] seconds
keyword - displays detailed information

A:PE-1# oam p2mp-lsp-trace LSP-p2mp-1 p2mp-instance p-LSP-p2mp-1 s2l-dest-address


192.0.2.7 detail
P2MP LSP LSP-p2mp-1: 128 bytes MPLS payload
P2MP Instance p-LSP-p2mp-1, S2L Egress 192.0.2.7
1
2
3

192.0.2.3 rtt=4.87 ms rc=8(DSRtrMatchLabel)


DS 1: IfAddr 192.168.35.2 MRU=1500 label=131064 proto=4(RSVP-TE) B/E flags:0/0
192.0.2.5 rtt=8.02 ms rc=8(DSRtrMatchLabel)
DS 1: IfAddr 192.168.57.2 MRU=1500 label=131066 proto=4(RSVP-TE) B/E flags:0/0
192.0.2.7 rtt=4.44 ms rc=3(EgressRtr)

Note: Return codes are based on RFC4379, with value 8 => label switched at stack-depth.
Meaning it is an transit LSR, doing MPLS label swapping. No B or E flag is set.

Advanced Configuration Guide

Page 1853

Configuration

Additional Topics
<*,G> IGMP join iso <S,G> IGMP join
In the Head-end Node (Ingress LER) on page 1847 and Leaf Node (Egress LER) on page 1849
steps, a source specific IGMP join (<S,G> join) was used at the head-end node and leaf nodes.
Another possibility is to use a source unknown or starg IGMP join (<*,G> join). When doing the
latter, a rendezvous point (RP) must be defined in the PIM network. The RP allows multicast data
flows between sources and receivers to meet at a predefined network location (in our example,
loopback address of PE-1 node). It must be seen as an intermediate device to establish a multicast
flow.
RP can be defined in a dynamic way (BSR protocol) or a static way. In our example we choose the
static way meaning that on all involved PIM nodes, the RP address will be statically configured.
The following output shows translated in configuration commands.
A:PE-1/PE-6/PE-7# configure router pim

rp
static
address 192.0.2.1
group-prefix 227.1.1.1/32
exit
exit

exit

The group-prefix a mandatory keyword is specified and references a group address or group
address range for which this rendez-vous point will be used.
A:PE-1/PE-6/PE-7# show router pim rp
===============================================================================
PIM RP Set ipv4
===============================================================================
Group Address
Hold Expiry
RP Address
Type
Prio Time Time
------------------------------------------------------------------------------227.1.1.1/32
192.0.2.1
Static
1
N/A N/A
------------------------------------------------------------------------------Group Prefixes : 1
===============================================================================

As previously mentioned, the configuration of the <*,G> IGMP join is done on the head-end node
(PE-1) and leaf nodes (PE-6 and PE-7)
A:PE-1# configure router igmp
tunnel-interface rsvp-p2mp "p-to-mp-1"
static

Page 1854

Advanced Configuration Guide

RSVP Signalled Point-to-Multipoint LSPs

group 227.1.1.1
starg
exit
exit
exit
A:PE-6# configure router igmp
interface "to-MC-client2"
static
group 227.1.1.1
starg
exit
exit
exit
A:PE-7# configure router igmp
interface "to-MC-client1"
static
group 227.1.1.1
starg
exit
exit
exit

The same previous show command can be used to verify the multicast traffic on head-end node
and leaf nodes, show router igmp group 227.1.1.1 and show router pim group 227.1.1.1 detail.
A:PE-7# show router pim group 227.1.1.1 detail
===============================================================================
PIM Source Group ipv4
===============================================================================
Group Address
: 227.1.1.1
Source Address
: *
RP Address
: 192.0.2.1
Flags
:
Type
: (*,G)
MRIB Next Hop
:
MRIB Src Flags
: remote
Keepalive Timer
: Not Running
Up Time
: 0d 00:05:29
Resolved By
: unresolved
Up JP State
Up JP Rpt

: Joined
: Not Joined StarG

Up JP Expiry
: 0d 00:00:30
Up JP Rpt Override : 0d 00:00:00

Rpf Neighbor
:
Incoming Intf
: mpls-if-73730
Outgoing Intf List : to-MC-client1
Curr Fwding Rate
: 14.7 kbps
Forwarded Packets : 12163
Discarded Packets : 0
Forwarded Octets
: 559498
RPF Mismatches
: 0
Spt threshold
: 0 kbps
ECMP opt threshold : 7
Admin bandwidth
: 1 kbps
------------------------------------------------------------------------------Groups : 1
===============================================================================

Advanced Configuration Guide

Page 1855

Configuration

Influence IGP Metric


Suppose that the IGP metric is increased on all links pointing to/from PE-2 and on the link
between PE-5 andPE-7.
A:PE-1# configure router ospf area 0 interface int-PE-1-PE-2 metric 10000
A:PE-2# configure router ospf area 0 interface int-PE-2-PE-4 metric 10000
A:PE-2# configure router ospf area 0 interface int-PE-2-PE-3 metric 10000
A:PE-2# configure router ospf area 0 interface int-PE-2-PE-1 metric 10000
A:PE-3# configure router ospf area 0 interface int-PE-3-PE-2 metric 10000
A:PE-4# configure router ospf area 0 interface int-PE-4-PE-2 metric 10000
A:PE-5# configure router ospf area 0 interface int-PE-5-PE-7 metric 10000
A:PE-7# configure router ospf area 0 interface int-PE-7-PE-5 metric 10000

The existing P2MP LSP LSP-p2mp-1 will not take into account these new constraints. The two
S2L paths (one loose towards PE-6 and another one loose towards PE-7) are calculated using the
default OSPF metric of 1000. What we can do to trigger MPLS to re-compute the S2L paths, is
configure a p2mp-resignal-timer on the head-end node inside the global MPLS context. In this
way, each time this timer expires (in our example, every 60 minutes), MPLS will trigger CSPF to
re-compute the whole set of S2L paths of all active P2MP instance. MPLS performs a global
make-before-break (MBB) and moves each S2L sub-LSP in the instance into its new path using a
new P2MP LSP ID if the global MBB is successful. show router mpls status gives you an
indication when the P2MP resignal timer will expire and which types of LSPs are setup on the
node.
A:PE-1# configure router mpls p2mp-resignal-timer 60
A:PE-1# show router mpls status
===============================================================================
MPLS Status
===============================================================================
Admin Status
: Up
Oper Status
: Up
Oper Down Reason
: n/a
FR Object
: Enabled
Resignal Timer
: Disabled
Hold Timer
: 1 seconds
Next Resignal
: N/A
Srlg Frr
: Disabled
Srlg Frr Strict
: Disabled
Dynamic Bypass
: Enabled
User Srlg Database : Disabled
Least Fill Min Thd.: 5 percent
LeastFill ReoptiThd: 10 percent
P2mp Resignal Timer: 60 minutes
Sec FastRetryTimer : Disabled

P2mp Next Resignal : 6 minutes

LSP Counts
Originate
Transit
Terminate
------------------------------------------------------------------------------
===============================================================================

Page 1856

Advanced Configuration Guide

RSVP Signalled Point-to-Multipoint LSPs

As an alternative the user can also perform a manual resignal of a P2MP instance on the head-end
node using a tools command.
A:PE-1# tools perform router mpls resignal p2mp-lsp LSP-p2mp-1 p2mp-instance p-p-to-mp-1
A:PE-1# tools perform router mpls resignal p2mp-delay 0

PE-1 1/1/1
Ingress LER
(head-end) 182.0.2.1 .1 192.168.9.0/30

227.1.1.1
.2

MC-source

1/1/3 .1 .1 1/1/2
192.168.12.0/30

.2 1/1/3

PE-2 1/1/4
182.0.2.2 .1

192.168.23.0/30

1/1/2 .1

.2 1/1/1

PE-4 1/1/3
192.168.45.0/30

1/1/4 .1

BUD LSR

Transit LSR

192.168.57.0/30

1/1/5 .2

MC-client2

1/1/2 PE-5
.2 182.0.2.5
.1 1/1/3

192.168.46.0/30

1/1/6 PE-6 1/1/3


.2 192.168.11.0/30 .1 182.0.2.6 .1

Transit LSR

192.168.35.0/30

1/1/2 .2

182.0.2.4 .1

1/1/4 PE-3
.2 182.0.2.3
.1 1/1/1

192.168.24.0/30

Transit LSR

Metric 10000

192.168.13.0/30

1/1/3 .2

.2 1/1/3

192.168.67.0/30

1/1/4 PE-7 1/1/6


.2 182.0.2.7 .1 192.168.10.0/30 .2

MC-client1

Egress LER
(leaf)
OSSG364

Figure 183: P2MP LSP p-to-mp-1 with Metric Change

After an instantaneous tools resignal command with executed with no delay (p2mp-delay 0), the
S2L paths can be verified will be according to Figure 183. PE-6 node is acting now as BUD LSR
node (iso egress LER before)
A:PE-1# show router mpls p2mp-lsp LSP-p2mp-1 p2mp-instance p-LSP-p2mp-1 s2l loose to
192.0.2.7 detail

LSP Name
: LSP-p2mp-1
S2l LSP ID : 27658
P2MP ID
: 0
S2l Grp Id : 2
Adm State
: Up
Oper State : Up
S2l State: : Active
:
S2L Name
: loose
To
: 192.0.2.7
S2l Admin
: Up
S2l Oper
: Up
OutInterface: 1/1/2
Out Label
: 131065
S2L Up Time : 0d 02:14:31
S2L Dn Time : 0d 00:00:00

Advanced Configuration Guide

Page 1857

Configuration

RetryAttempt: 0
NextRetryIn : 0 sec
S2L Trans
: 6
CSPF Queries: 6
Failure Code: noError
Failure Node: n/a
ExplicitHops:
No Hops Specified
Actual Hops :
192.168.13.1(192.0.2.1) @
Record Label
: N/A
-> 192.168.13.2(192.0.2.3) @
Record Label
: 131065
-> 192.168.35.2(192.0.2.5) @
Record Label
: 131062
-> 192.168.45.1(192.0.2.4) @
Record Label
: 131061
-> 192.168.46.2(192.0.2.6) @
Record Label
: 131065
-> 192.168.67.2(192.0.2.7)
Record Label
: 131063
ComputedHops:
192.168.13.1
-> 192.168.13.2
-> 192.168.35.2
-> 192.168.45.1
-> 192.168.46.2
-> 192.168.67.2
LastResignal: n/a
==================================================================
A:PE-1#
A:PE-1# show router mpls p2mp-lsp LSP-p2mp-1 p2mp-instance p-LSP-p2mp-1 s2l loose to
192.0.2.6 detail

LSP Name
: LSP-p2mp-1
S2l LSP ID : 27658
P2MP ID
: 0
S2l Grp Id : 1
Adm State
: Up
Oper State : Up
S2l State: : Active
:
S2L Name
: loose
To
: 192.0.2.6
S2l Admin
: Up
S2l Oper
: Up
OutInterface: 1/1/2
Out Label
: 131065
S2L Up Time : 0d 02:22:00
S2L Dn Time : 0d 00:00:00
RetryAttempt: 0
NextRetryIn : 0 sec
S2L Trans
: 6
CSPF Queries: 6
Failure Code: noError
Failure Node: n/a
ExplicitHops:
No Hops Specified
Actual Hops :
192.168.13.1(192.0.2.1) @
Record Label
: N/A
-> 192.168.13.2(192.0.2.3) @
Record Label
: 131065
-> 192.168.35.2(192.0.2.5) @
Record Label
: 131062
-> 192.168.45.1(192.0.2.4) @
Record Label
: 131061
-> 192.168.46.2(192.0.2.6)
Record Label
: 131065
ComputedHops:
192.168.13.1
-> 192.168.13.2
-> 192.168.35.2
-> 192.168.45.1
-> 192.168.46.2
LastResignal: n/a
==================================================================
A:PE-1#

An oam p2mp-lsp-trace command toward PE-7 will now set the E flag on PE-6 since that PE acts
also as an egress LER node.
A:PE-1# oam p2mp-lsp-trace LSP-p2mp-1 p2mp-instance p-LSP-p2mp-1 s2l-dest-address
192.0.2.7 detail
P2MP LSP LSP-p2mp-1: 128 bytes MPLS payload
P2MP Instance p-LSP-p2mp-1, S2L Egress 192.0.2.7

Page 1858

Advanced Configuration Guide

RSVP Signalled Point-to-Multipoint LSPs

1
2
3
4
5

192.0.2.3 rtt=3.08 ms rc=8(DSRtrMatchLabel)


DS 1: IfAddr 192.168.35.2 MRU=1500 label=131062
192.0.2.5 rtt=3.56 ms rc=8(DSRtrMatchLabel)
DS 1: IfAddr 192.168.45.1 MRU=1500 label=131061
192.0.2.4 rtt=11.6 ms rc=8(DSRtrMatchLabel)
DS 1: IfAddr 192.168.46.2 MRU=1500 label=131065
192.0.2.6 rtt=4.84 ms rc=8(DSRtrMatchLabel)
DS 1: IfAddr 192.168.67.2 MRU=1500 label=131063
192.0.2.7 rtt=6.05 ms rc=3(EgressRtr)

proto=4(RSVP-TE) B/E flags:0/0


proto=4(RSVP-TE) B/E flags:0/0
proto=4(RSVP-TE) B/E flags:0/0
proto=4(RSVP-TE) B/E flags:0/1

As a next step, the S2L path towards PE-7 is changed from loose to a strict direct MPLS path
(strict-to-PE-7). In that way, OSPF is not calculating anymore the shortest path to the leaf node.
A:PE-1# configure router mpls

path "strict-to-PE-7"
hop 10 192.168.13.2 strict
hop 20 192.168.35.2 strict
hop 30 192.168.57.2 strict
no shutdown
exit

Before applying this new S2L path to the existing P2MP LSP (LSP-p2mp-1), the existing S2L
path towards PE-7 must be removed.
A:PE-1# configure router mpls lsp "LSP-p2mp-1" primary-p2mp-instance "p-LSP-p2mp-1" s2lpath "loose" to 192.0.2.7 shutdown
A:PE-1# configure router mpls lsp "LSP-p2mp-1" primary-p2mp-instance "p-LSP-p2mp-1" no
s2l-path "loose" to 192.0.2.7
A:PE-1# configure router mpls lsp "LSP-p2mp-1" primary-p2mp-instance "p-LSP-p2mp-1" s2lpath "strict-to-PE-7" to 192.0.2.7

Advanced Configuration Guide

Page 1859

Configuration

PE-1 1/1/1
Ingress LER
(head-end) 182.0.2.1 .1 192.168.9.0/30

227.1.1.1
.2

MC-source

1/1/3 .1 .1 1/1/2
192.168.12.0/30
1/1/3 .2

.2 1/1/3

PE-2 1/1/4
182.0.2.2 .1

192.168.23.0/30

1/1/2 .1

.2 1/1/1

PE-4 1/1/3
192.168.45.0/30

1/1/4 .1

Egress LER
(leaf)

Branch LSR

192.168.57.0/30

1/1/5 .2

MC-client2

1/1/2 PE-5
.2 182.0.2.5
.1 1/1/3

192.168.46.0/30

1/1/6 PE-6 1/1/3


.2 192.168.11.0/30 .1 182.0.2.6 .1

Transit LSR

192.168.35.0/30

1/1/2 .2

182.0.2.4 .1

1/1/4 PE-3
.2 182.0.2.3
.1 1/1/1

192.168.24.0/30

Transit LSR

Metric 10000

192.168.13.0/30

.2 1/1/3

192.168.67.0/30

1/1/4 PE-7 1/1/6


.2 182.0.2.7 .1 192.168.10.0/30 .2

MC-client1

Egress LER
(leaf)
OSSG365

Figure 184: P2MP LSP LSP-p2mp-1 with Strict S2L Path Towards PE-7

As a consequence of this, only the S2l Grp Id has changed while S2L LSP ID remains the same
as before. Now, S2L paths can be verified according to Figure 184. PE-5 is acting now as branch
LSR node (iso transit LSR before).
A:PE-1# show router mpls p2mp-lsp LSP-p2mp-1 p2mp-instance p-LSP-p2mp-1 s2l strict-to-PE-7
to 192.0.2.7 detail
===============================================================================
MPLS LSP LSP-p2mp-1 S2L strict-to-PE-7 (Detail)
===============================================================================
Legend :
@ - Detour Available
# - Detour In Use
b - Bandwidth Protected
n - Node Protected
s - Soft Preemption
===============================================================================
------------------------------------------------------------------------------LSP LSP-p2mp-1 S2L strict-to-PE-7
------------------------------------------------------------------------------LSP Name
: LSP-p2mp-1
S2l LSP ID : 27658
P2MP ID
: 0
S2l Grp Id : 3
Adm State
: Up
Oper State : Up
S2l State: : Active
:
S2L Name
: strict-to-PE-7
To
: 192.0.2.7
S2l Admin
: Up
S2l Oper
: Up
OutInterface: 1/1/2
Out Label
: 131065
S2L Up Time : 0d 00:01:04
S2L Dn Time : 0d 00:00:00

Page 1860

Advanced Configuration Guide

RSVP Signalled Point-to-Multipoint LSPs

RetryAttempt: 0
NextRetryIn : 0 sec
S2L Trans
: 1
CSPF Queries: 1
Failure Code: noError
Failure Node: n/a
ExplicitHops:
192.168.13.2
-> 192.168.35.2
-> 192.168.57.2
Actual Hops :
192.168.13.1(192.0.2.1) @
Record Label
: N/A
-> 192.168.13.2(192.0.2.3) @
Record Label
: 131065
-> 192.168.35.2(192.0.2.5) @
Record Label
: 131062
-> 192.168.57.2(192.0.2.7)
Record Label
: 131068
ComputedHops:
192.168.13.1
-> 192.168.13.2
-> 192.168.35.2
-> 192.168.57.2
LastResignal: n/a
===============================================================================

An oam p2mp-lsp-trace command towards PE-7 will now set the B flag on PE-5 since that
became a branch LSR now.
A:PE-1# oam p2mp-lsp-trace LSP-p2mp-1 p2mp-instance p-LSP-p2mp-1 s2l-dest-address
192.0.2.7 detail
P2MP LSP LSP-p2mp-1: 128 bytes MPLS payload
P2MP Instance p-LSP-p2mp-1, S2L Egress 192.0.2.7
1
2
3

192.0.2.3 rtt=2.67 ms rc=8(DSRtrMatchLabel)


DS 1: IfAddr 192.168.35.2 MRU=1500 label=131062 proto=4(RSVP-TE) B/E flags:0/0
192.0.2.5 rtt=3.35 ms rc=8(DSRtrMatchLabel)
DS 1: IfAddr 192.168.57.2 MRU=1500 label=131068 proto=4(RSVP-TE) B/E flags:1/0
192.0.2.7 rtt=5.35 ms rc=3(EgressRtr)

Advanced Configuration Guide

Page 1861

Configuration

Intelligent Remerge
Intelligent remerge protects users from receiving duplicate multicast during convergence. It also
protects against duplicate traffic in case of badly designed S2L paths. Initially, three cases exist for
which intelligent remerge is implemented.
Case 1
When the paths of two different S2Ls of the same P2MP LSP instance have Ingress Label Maps
(ILMs) on different ports but go out on the same Next-hop Label Forwarding Entry (NHLFE).

PE-1 1/1/1
Ingress LER
(head-end) 182.0.2.1 .1 192.168.9.0/30

227.1.1.1
.2

MC-source

1/1/3 .1 .1 1/1/2
192.168.12.0/30

.2 1/1/3

PE-2 1/1/4
182.0.2.2 .1

192.168.23.0/30

1/1/2 .1

192.168.35.0/30

1/1/2 .2

.2 1/1/1

PE-4 1/1/3
192.168.45.0/30

1/1/4 .1

Intelligent Re-merge
192.168.57.0/30

1/1/5 .2

MC-client2

Egress LER
(leaf)

1/1/2 PE-5
.2 182.0.2.5
.1 1/1/3

192.168.46.0/30

1/1/6 PE-6 1/1/3


.2 192.168.11.0/30 .1 182.0.2.6 .1

1/1/4 PE-3
.2 182.0.2.3
.1 1/1/1

192.168.24.0/30

182.0.2.4 .1

Metric 10000

192.168.13.0/30

1/1/3 .2

.2 1/1/3

192.168.67.0/30

1/1/4 PE-7 1/1/6


.2 182.0.2.7 .1 192.168.10.0/30 .2

MC-client1

Egress LER
(leaf)
OSSG366

Figure 185: Intelligent Remerge, Case 1

On the head-end node (PE-1), a new P2MP LSP (LSP-p2mp-2) will be created with two strict
direct MPLS paths (strict-to-PE-7 and strict-to-PE-6). See Figure 185 for detailed address
information. Intelligent re-merge is performed at node PE-5.

Page 1862

Advanced Configuration Guide

RSVP Signalled Point-to-Multipoint LSPs

A:PE-1# configure router mpls

path "strict-to-PE-7"
hop 10 192.168.13.2 strict
hop 20 192.168.35.2 strict
hop 30 192.168.57.2 strict
no shutdown
exit
path "strict-to-PE-6"
hop 10 192.168.12.2 strict
hop 20 192.168.24.2 strict
hop 30 192.168.45.2 strict
hop 40 192.168.57.2 strict
hop 50 192.168.67.1 strict
no shutdown
exit

lsp "LSP-p2mp-2" p2mp-lsp


primary-p2mp-instance "p-LSP-p2mp-2"
s2l-path "strict-to-PE-7" to 192.0.2.7
exit
s2l-path "strict-to-PE-6" to 192.0.2.6
exit
exit
no shutdown
exit
no shutdown
A:PE-1# show router mpls p2mp-lsp LSP-p2mp-2 p2mp-instance p-LSP-p2mp-2
===============================================================================
MPLS P2MP Instance (Originating)
===============================================================================
------------------------------------------------------------------------------Type : Originating
------------------------------------------------------------------------------LSP Name
: LSP-p2mp-2
LSP Tunnel ID : 13
P2MP ID
: 0
Adm State
: Up
Oper State
: Up
P2MPInstance: p-LSP-p2mp-2
P2MP-Inst-type : Primary
P2MP Inst Id: 4
P2MP Lsp Id
: 22016
Inst Admin : Up
Inst Oper
: Up
Inst Up Time: 0d 00:01:56
Inst Dn Time
: 0d 00:00:00
Hop Limit
: 255
Adaptive
: Enabled
Record Route: Record
Record Label
: Record
Include Grps:
Exclude Grps
:
None
None
Bandwidth
: No Reservation
Oper Bw
: 0 Mbps
S2l-Name
: strict-to-PE-7
To
: 192.0.2.7
S2l Admin
: Up
S2l Oper
: Up
S2l-Name
: strict-to-PE-6
To
: 192.0.2.6
S2l Admin
: Up
S2l Oper
: Up
------------------------------------------------------------------------------P2MP instances : 1
===============================================================================

Advanced Configuration Guide

Page 1863

Configuration

To verify that PE-5 node is not sending duplicate multicast traffic downstream towards PE-7 while
it receives two incoming multicast streams, a new tunnel interface and a new static <S,G> IGMP
join will be configured on head-end node (PE-1) and leaf nodes (PE-6 and PE-7). Also on the leaf
nodes, an extension to the existing multicast information policy is needed. Translated into
configuration commands, this becomes
A:PE-1# configure router pim tunnel-interface rsvp-p2mp LSP-p2mp-2
A:PE-1# configure router igmp

tunnel-interface rsvp-p2mp "LSP-p2mp-2"


static
group 227.2.2.2
source 192.168.9.2

A:PE-6# configure router pim tunnel-interface rsvp-p2mp LSP-p2mp-2 sender 192.0.2.1


A:PE-6# configure router igmp interface to-MC-client2 static group 227.2.2.2 source
192.168.9.2
A:PE-6# configure mcast-management
multicast-info-policy "p2mp-pol" create
bundle "bundle2" create
primary-tunnel-interface rsvp-p2mp LSP-p2mp-2 sender 192.0.2.1
channel "227.2.2.2" "227.2.2.2" create
exit
exit
A:PE-7# configure router pim tunnel-interface rsvp-p2mp LSP-p2mp-2 sender 192.0.2.1
A:PE-7# configure router igmp interface to-MC-client1 static group 227.2.2.2 source
192.168.9.2
A:PE-7# configure mcast-management
multicast-info-policy "p2mp-pol" create
bundle "bundle2" create
primary-tunnel-interface rsvp-p2mp LSP-p2mp-2 sender 192.0.2.1
channel "227.2.2.2" "227.2.2.2" create
exit
exit

Page 1864

Advanced Configuration Guide

RSVP Signalled Point-to-Multipoint LSPs

For verification of incoming/outgoing multicast traffic at PE-5 node, the monitor command is
used.
A:PE-5# monitor port 1/1/1 1/1/2 1/1/3 rate interval 3 repeat 100
===============================================================================
Monitor statistics for Ports
===============================================================================
Input
Output
------------------------------------------------------------------------------
------------------------------------------------------------------------------At time t = 12 sec (Mode: Rate)
------------------------------------------------------------------------------Port 1/1/1
------------------------------------------------------------------------------Octets
2714
50
Packets
40
0
Errors
0
0
Utilization (% of port capacity)
0.02
~0.00
Port 1/1/2
------------------------------------------------------------------------------Octets
2769
50
Packets
40
0
Errors
0
0
Utilization (% of port capacity)
0.02
~0.00
Port 1/1/3
------------------------------------------------------------------------------Octets
21
2714
Packets
0
40
Errors
0
0
Utilization (% of port capacity)
~0.00
0.02

As a conclusion we can say that two incoming multicast streams are seen at PE-5 node (port 1/1/2
and port 1/1/1) and only one outgoing multicast stream (port 1/1/3) is sent. No traffic duplication
is seen.

Advanced Configuration Guide

Page 1865

Configuration

Case 2
When two paths of the same S2L have ILMs on different incoming ports and go out on the same
NHLFE. This is the case when we perform make-before-break (MBB) on an S2L path due to
graceful shutdown or global revertive. This is only a temporary situation since the original path
will be torn down.

PE-1 1/1/1
Ingress LER
(head-end) 182.0.2.1 .1 192.168.9.0/30

227.1.1.1
.2

MC-source

1/1/3 .1 .1 1/1/2
192.168.12.0/30

192.168.13.0/30

1/1/3 .2

Metric 10000
.2 1/1/3

PE-2 1/1/4
182.0.2.2 .1

192.168.23.0/30

1/1/2 .1

Before Graceful
Shut of PE-3

1/1/4 PE-3
.2 182.0.2.3

After Graceful
Shut of PE-3

.1 1/1/1

192.168.24.0/30
1/1/2 .2

192.168.35.0/30
.2 1/1/1

PE-4 1/1/3
182.0.2.4 .1

192.168.45.0/30

1/1/2 PE-5
.2 182.0.2.5
.1 1/1/3

Intelligent Re-merge
192.168.57.0/30
.2 1/1/3

PE-7 1/1/6
182.0.2.7 .1 192.168.10.0/30 .2

MC-client1

Egress LER
(leaf)
OSSG367

Figure 186: Intelligent Remerge, Case 2

For this test, only one MC-client will be looked at (the one connected to head-end node PE-7). On
PE-4 and PE-7 nodes, port 1/1/4 will be shutdown to isolate PE-6. On the head-end node (PE-1), a
new P2MP LSP (LSP-p2mp-3) will be created with one loose MPLS path (loose). See Figure 185
for detailed address information. Also in this case, intelligent re-merge is performed at node PE-5.
A:PE-1# configure router mpls

path "loose"
no shutdown
exit

lsp "LSP-p2mp-3" p2mp-lsp


primary-p2mp-instance "p-LSP-p2mp-3"
s2l-path "loose" to 192.0.2.7

Page 1866

Advanced Configuration Guide

RSVP Signalled Point-to-Multipoint LSPs

exit
exit
no shutdown
exit
no shutdown
A:PE-1# show router mpls p2mp-lsp LSP-p2mp-3 p2mp-instance p-LSP-p2mp-3 s2l loose to
192.0.2.7 detail
===============================================================================
MPLS LSP LSP-p2mp-3 S2L loose (Detail)
===============================================================================
Legend :
@ - Detour Available
# - Detour In Use
b - Bandwidth Protected
n - Node Protected
s - Soft Preemption
===============================================================================
------------------------------------------------------------------------------LSP LSP-p2mp-3 S2L loose
------------------------------------------------------------------------------LSP Name
: LSP-p2mp-3
S2l LSP ID : 17410
P2MP ID
: 0
S2l Grp Id : 5
Adm State
: Up
Oper State : Up
S2l State: : Active
:
S2L Name
: loose
To
: 192.0.2.7
S2l Admin
: Up
S2l Oper
: Up
OutInterface: 1/1/2
Out Label
: 131069
S2L Up Time : 0d 00:00:27
S2L Dn Time : 0d 00:00:00
RetryAttempt: 0
NextRetryIn : 0 sec
S2L Trans
: 3
CSPF Queries: 0
Failure Code: noError
Failure Node: n/a
ExplicitHops:
No Hops Specified
Actual Hops :
192.168.13.1(192.0.2.1)
Record Label
: N/A
-> 192.168.13.2(192.0.2.3)
Record Label
: 131069
-> 192.168.35.2(192.0.2.5)
Record Label
: 131068
-> 192.168.57.2(192.0.2.7)
Record Label
: 131071
LastResignal: n/a
===============================================================================

Advanced Configuration Guide

Page 1867

Configuration

In a normal situation, the P2MP LSP would follow the nodes PE-1, PE-3, PE-5 and PE-7. This can
be verified with MC traffic. Therefore, a new tunnel interface and a new static <S,G> IGMP join
will be configured on head-end node (PE-1) and leaf node (PE-7). On the leaf node, an extension
to the existing multicast information policy is needed. Translated into configuration commands,
this becomes
A:PE-1# configure router pim tunnel-interface rsvp-p2mp LSP-p2mp-3
A:PE-1# configure router igmp

tunnel-interface rsvp-p2mp "LSP-p2mp-3"


static
group 227.3.3.3
source 192.168.9.2
A:PE-7# configure router pim tunnel-interface rsvp-p2mp LSP-p2mp-3 sender 192.0.2.1
A:PE-7# configure router igmp interface to-MC-client1 static group 227.3.3.3 source
192.168.9.2
A:PE-7# configure mcast-management
multicast-info-policy "p2mp-pol" create
bundle "bundle3" create
primary-tunnel-interface rsvp-p2mp LSP-p2mp-3 sender 192.0.2.1
channel "227.3.3.3" "227.3.3.3" create
exit
exit
A:PE-5# monitor port 1/1/1 1/1/2 1/1/3 rate interval 3 repeat 999
===============================================================================
Monitor statistics for Ports
===============================================================================
Input
Output
------------------------------------------------------------------------------
------------------------------------------------------------------------------At time t = 231 sec (Mode: Rate)
------------------------------------------------------------------------------Port 1/1/1
------------------------------------------------------------------------------Octets
2714
108
Packets
40
1
Errors
0
0
Utilization (% of port capacity)
0.02
~0.00
------------------------------------------------------------------------------Port 1/1/2
------------------------------------------------------------------------------Octets
50
50
Packets
0
0
Errors
0
0
Utilization (% of port capacity)
~0.00
~0.00
Port 1/1/3
------------------------------------------------------------------------------Octets
81
2801

Page 1868

Advanced Configuration Guide

RSVP Signalled Point-to-Multipoint LSPs

Packets
Errors
Utilization (% of port capacity)

1
0
~0.00

40
0
0.02

Now, perform an RSVP graceful shut on PE-3 node. Global revertive is triggered on head-end
node (PE-1). A new MPLS path will be calculated (see dotted line in Figure 185). For a few
seconds, the old path and new path are active (two incoming MC streams on PE-5 node). PE-5
node is doing intelligent re-merge, not sending duplicate multicast traffic downstream towards PE7:
A:PE-3# configure router rsvp graceful-shutdown
A:PE-5# monitor port 1/1/1 1/1/2 1/1/3 rate interval 3 repeat 999
===============================================================================
Monitor statistics for Ports
===============================================================================
Input
Output
------------------------------------------------------------------------------
------------------------------------------------------------------------------At time t = 31 sec (Mode: Rate)
------------------------------------------------------------------------------Port 1/1/1
------------------------------------------------------------------------------Octets
2714
108
Packets
40
1
Errors
0
0
Utilization (% of port capacity)
0.02
~0.00
------------------------------------------------------------------------------Port 1/1/2
------------------------------------------------------------------------------Octets
2714
108
Packets
40
1
Errors
0
0
Utilization (% of port capacity)
~0.00
~0.00
Port 1/1/3
------------------------------------------------------------------------------Octets
81
2801
Packets
1
40
Errors
0
0
Utilization (% of port capacity)
~0.00
0.02

No traffic duplication is seen.

Advanced Configuration Guide

Page 1869

Configuration

Case 3
When a bypass is active on the S2L path and the new global revertive path of the same S2L arrives
on the same incoming interface as the original path (interface flapped) at the FRR merge point
node. The implementation recognizes this specific case and will signal a different label from the
original S2L path coming on that same interface.

PE-1 1/1/1
Ingress LER
(head-end) 182.0.2.1 .1 192.168.9.0/30

227.1.1.1
.2

MC-source

1/1/3 .1 .1 1/1/2
192.168.12.0/30

Before Linkfailure PE-3PE-5

192.168.13.0/30

1/1/3 .2

.2 1/1/3

PE-2 1/1/4
182.0.2.2 .1

192.168.23.0/30

1/1/2 .1

After Global Revertive And


Port 1/1/1 on PE-3 Still Down

1/1/4 PE-3
.2 182.0.2.3

Bypass for PE-3PE-5 Link

.1 1/1/1

192.168.24.0/30
1/1/2 .2

192.168.35.0/30
.2 1/1/1

PE-4 1/1/3
182.0.2.4 .1

192.168.45.0/30

1/1/2 PE-5
.2 182.0.2.5
.1 1/1/3

Intelligent Re-merge
192.168.57.0/30
.2 1/1/3

PE-7 1/1/6
182.0.2.7 .1 192.168.10.0/30 .2

MC-client1

Egress LER
(leaf)
OSSG368

Figure 187: Intelligent Remerge, Case 3

For this test, all the non-default OSPF metrics are removed from the interfaces. Only one MCclient will be looked at (the one connected to head-end node PE-7). On PE-4 and PE-7 node, port
1/1/4 will be shutdown to isolate PE-6. On the head-end node (PE-1), a new P2MP LSP (LSPp2mp-4) will be created with one loose MPLS path (loose) and FRR enabled. See Figure 187 for
detailed address information. Also in this case, intelligent re-merge is performed at node PE-5.
A:PE-1# configure router mpls

path "loose"
no shutdown
exit

lsp "LSP-p2mp-4" p2mp-lsp

Page 1870

Advanced Configuration Guide

RSVP Signalled Point-to-Multipoint LSPs

cspf
fast-reroute facility
no node-protect
exit
primary-p2mp-instance "p-LSP-p2mp-4"
s2l-path "loose" to 192.0.2.7
exit
exit
no shutdown
exit
no shutdown
A:PE-1# show router mpls p2mp-lsp LSP-p2mp-4 p2mp-instance p-LSP-p2mp-4 s2l loose to
192.0.2.7 detail
===============================================================================
MPLS LSP LSP-p2mp-4 S2L loose (Detail)
===============================================================================
Legend :
@ - Detour Available
# - Detour In Use
b - Bandwidth Protected
n - Node Protected
s - Soft Preemption
===============================================================================
------------------------------------------------------------------------------LSP LSP-p2mp-4 S2L loose
------------------------------------------------------------------------------LSP Name
: LSP-p2mp-4
S2l LSP ID : 39940
P2MP ID
: 0
S2l Grp Id : 4
Adm State
: Up
Oper State : Up
S2l State: : Active
:
S2L Name
: loose
To
: 192.0.2.7
S2l Admin
: Up
S2l Oper
: Up
OutInterface: 1/1/2
Out Label
: 131069
S2L Up Time : 0d 00:00:31
S2L Dn Time : 0d 00:00:00
RetryAttempt: 0
NextRetryIn : 0 sec
S2L Trans
: 1
CSPF Queries: 1
Failure Code: noError
Failure Node: n/a
ExplicitHops:
No Hops Specified
Actual Hops :
192.168.13.1(192.0.2.1) @
Record Label
: N/A
-> 192.168.13.2(192.0.2.3) @
Record Label
: 131069
-> 192.168.35.2(192.0.2.5)
Record Label
: 131069
-> 192.168.57.2(192.0.2.7)
Record Label
: 131070
ComputedHops:
192.168.13.1
-> 192.168.13.2
-> 192.168.35.2
-> 192.168.57.2
LastResignal: n/a
===============================================================================

Advanced Configuration Guide

Page 1871

Configuration

In the normal situation, the P2MP LSP follows the nodes PE-1, PE-3, PE-5 and PE-7. This can be
verified with MC traffic. Therefore, a new tunnel interface and a new static <S,G> IGMP join will
be configured on head-end node (PE-1) and leaf node (PE-7). On the leaf node, an extension to the
existing multicast information policy is needed. Translated into configuration commands, this
becomes:
A:PE-1# configure router pim tunnel-interface rsvp-p2mp LSP-p2mp-4
A:PE-1# configure router igmp

tunnel-interface rsvp-p2mp "LSP-p2mp-4"


static
group 227.4.4.4
source 192.168.9.2
A:PE-7# configure router pim tunnel-interface rsvp-p2mp LSP-p2mp-4 sender 192.0.2.1
A:PE-7# configure router igmp interface to-MC-client1 static group 227.4.4.4 source
192.168.9.2
A:PE-7# configure mcast-management
multicast-info-policy "p2mp-pol" create
bundle "bundle4" create
primary-tunnel-interface rsvp-p2mp LSP-p2mp-4 sender 192.0.2.1
channel "227.4.4.4" "227.4.4.4" create
exit
exit
A:PE-5# monitor port 1/1/1 1/1/2 1/1/3 rate interval 3 repeat 999
===============================================================================
Monitor statistics for Ports
===============================================================================
Input
Output
------------------------------------------------------------------------------
------------------------------------------------------------------------------At time t = 3 sec (Mode: Rate)
------------------------------------------------------------------------------Port 1/1/1
------------------------------------------------------------------------------Octets
2737
21
Packets
40
0
Errors
0
0
Utilization (% of port capacity)
0.02
~0.00
Port 1/1/2
------------------------------------------------------------------------------Octets
21
21
Packets
0
0
Errors
0
0
Utilization (% of port capacity)
~0.00
~0.00
Port 1/1/3
------------------------------------------------------------------------------Octets
21
2714
Packets
0
40

Page 1872

Advanced Configuration Guide

RSVP Signalled Point-to-Multipoint LSPs

Errors
Utilization (% of port capacity)

0
~0.00

0
0.02

Now we do an link failure on PE-3 <=> PE-5 interface.


A:PE-3# configure port 1/1/1 shutdown

As a consequence of this, traffic will be flowing over the bypass link (see also Figure 187 + #
symbol in next show command).
A:PE-1# show router mpls p2mp-lsp LSP-p2mp-4 p2mp-instance p-LSP-p2mp-4 s2l loose to
192.0.2.7 detail
===============================================================================
MPLS LSP LSP-p2mp-4 S2L loose (Detail)
===============================================================================
Legend :
@ - Detour Available
# - Detour In Use
b - Bandwidth Protected
n - Node Protected
s - Soft Preemption
===============================================================================
------------------------------------------------------------------------------LSP LSP-p2mp-4 S2L loose
------------------------------------------------------------------------------LSP Name
: LSP-p2mp-4
S2l LSP ID : 39940
P2MP ID
: 0
S2l Grp Id : 4
Adm State
: Up
Oper State : Up
S2l State: : Active
:
S2L Name
: loose
To
: 192.0.2.7
S2l Admin
: Up
S2l Oper
: Up
OutInterface: 1/1/2
Out Label
: 131069
S2L Up Time : 0d 00:04:21
S2L Dn Time : 0d 00:00:00
RetryAttempt: 0
NextRetryIn : 0 sec
S2L Trans
: 1
CSPF Queries: 1
Failure Code: tunnelLocallyRepaired
Failure Node: 192.0.2.3
ExplicitHops:
No Hops Specified
Actual Hops :
192.168.13.1(192.0.2.1) @
Record Label
: N/A
-> 192.168.13.2(192.0.2.3) @ #
Record Label
: 131069
-> 192.168.35.2(192.0.2.5)
Record Label
: 131069
-> 192.168.57.2(192.0.2.7)
Record Label
: 131070
ComputedHops:
192.168.13.1
-> 192.168.13.2
-> 192.168.35.2
-> 192.168.57.2
LastResignal: n/a
In Prog MBB :
MBB Type
: GlobalRevert
NextRetryIn : 1 sec
Started At : 11/13/2009 14:46:50
RetryAttempt: 0
FailureCode: noError
Failure Node: n/a
===============================================================================

In the meantime, PE-3 will trigger a global revertive action (sending PATHerr message) towards
the head-end node (PE-1).
A:PE-1# show router mpls p2mp-lsp LSP-p2mp-4 p2mp-instance p-LSP-p2mp-4 s2l loose to
192.0.2.7 detail
===============================================================================

Advanced Configuration Guide

Page 1873

Configuration

MPLS LSP LSP-p2mp-4 S2L loose (Detail)


===============================================================================
Legend :
@ - Detour Available
# - Detour In Use
b - Bandwidth Protected
n - Node Protected
s - Soft Preemption
===============================================================================
------------------------------------------------------------------------------LSP LSP-p2mp-4 S2L loose
------------------------------------------------------------------------------LSP Name
: LSP-p2mp-4
S2l LSP ID : 39940
P2MP ID
: 0
S2l Grp Id : 5
Adm State
: Up
Oper State : Up
S2l State: : Active
:
S2L Name
: loose
To
: 192.0.2.7
S2l Admin
: Up
S2l Oper
: Up
OutInterface: 1/1/3
Out Label
: 131071
S2L Up Time : 0d 00:06:44
S2L Dn Time : 0d 00:00:00
RetryAttempt: 0
NextRetryIn : 0 sec
S2L Trans
: 2
CSPF Queries: 2
Failure Code: noError
Failure Node: n/a
ExplicitHops:
No Hops Specified
Actual Hops :
192.168.12.1(192.0.2.1) @
Record Label
: N/A
-> 192.168.12.2(192.0.2.2)
Record Label
: 131071
-> 192.168.24.2(192.0.2.4)
Record Label
: 131071
-> 192.168.45.2(192.0.2.5)
Record Label
: 131071
-> 192.168.57.2(192.0.2.7)
Record Label
: 131070
ComputedHops:
192.168.12.1
-> 192.168.12.2
-> 192.168.24.2
-> 192.168.45.2
-> 192.168.57.2
LastResignal: n/a
Last MBB
:
MBB Type
: GlobalRevert
MBB State
: Success
Ended At
: 11/13/2009 14:47:23
===============================================================================

Page 1874

Advanced Configuration Guide

RSVP Signalled Point-to-Multipoint LSPs

For some time, PE-5 will receive two incoming MC streams (both arriving on port 1/1/2). One
from bypass path (PE-3 => PE-2 => PE-4 => PE-5) and one from new MPLS path ( PE-1 => PE2 => PE-4 => PE-5 => PE-7). Port 1/1/3 on PE-5 performs intelligent remerge, only one MC
stream is sent downstream towards leaf node PE-7.
A:PE-5# monitor port 1/1/1 1/1/2 1/1/3 rate interval 3 repeat 999
===============================================================================
Monitor statistics for Ports
===============================================================================
Input
Output
------------------------------------------------------------------------------
------------------------------------------------------------------------------At time t = 39 sec (Mode: Rate)
------------------------------------------------------------------------------Port 1/1/1
------------------------------------------------------------------------------Octets
0
261
Packets
0
1
Errors
0
0
Utilization (% of port capacity)
0.00
~0.00
Port 1/1/2
------------------------------------------------------------------------------Octets
5540
393
Packets
80
2
Errors
0
0
Utilization (% of port capacity)
0.04
~0.00
Port 1/1/3
------------------------------------------------------------------------------Octets
128
3041
Packets
1
40
Errors
0
0
Utilization (% of port capacity)
~0.00
0.02
-------------------------------------------------------------------------------

Advanced Configuration Guide

Page 1875

Conclusion

Conclusion
Looking to the configuration point of view, a P2MP LSP is only configured on the head-end node
of that P2MP LSP, no explicit configuration is needed on the transit LSRs, branch LSRs, BUD
LSRs and egress LERs/leaf nodes.
Since PIM protocol is only needed on the head-end node and leaf node(s), we can work in a PIMfree core network. Although convergence is not covered in this configuration note, failures in the
core will be resolved by MPLS (in case of FRR, traffic loss < 50ms is expected). This is a major
improvement compared to PIM convergence.

Page 1876

Advanced Configuration Guide

Shared Risk Link Groups


for RSVP-Based LSP

In This Chapter
This section provides information about Shared Risk Link Groups for RSVP-Based LSPs.
Topics in this section include:

Applicability on page 1878

Overview on page 1879

Configuration on page 1881

Conclusion on page 1898

Advanced Configuration Guide

Page 1877

Applicability

Applicability
This feature is applicable to all of the 7750, 7450 and 7710 SR series. Tested on release 7.0R5. No
pre-requisite are needed. The 7750 SR-c4 is supported from 8.0R4 and higher.

Page 1878

Advanced Configuration Guide

Shared Risk Link Groups for RSVP-Based LSP

Overview
Introduction
Shared Risk Link Groups (SRLG) is a feature which allows the user to establish a backup
secondary LSP (label switched path) path or a FRR (fast-reroute) LSP path which is disjoint from
the path of the primary LSP. Links which are members of the same SRLG represent resources
which share the same risk. For example, fiber links sharing the same conduit or multiple
wavelengths sharing the same fiber.
A typical application of the SRLG feature is to provide an automatic placement of secondary
backup LSPs or FRR bypass/detour LSPs that minimizes the probability of fate sharing with the
path of the primary LSP.
SRLG groups are used to determine which links belong to the same SRLG. The mechanism is
similar to MPLS admin groups. To advertise SRLG, the information is part of the IGP TE
parameters in an opaque LSA (link state advertisement). The SRLG is advertised in a new Shared
Risk Link Group TLV (type 138) in IS-IS (RFC 4205, Intermediate System to Intermediate System
(IS-IS) Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)). It is
advertised in a new SRLG sub-TLV (type 16) of the existing Link TLV in OSPF (RFC 4203,
OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS).
For FRR a choice can be made on what to do when no FRR tunnel can be found with the SRLG
constraints. No FRR tunnel might be signalled or a FRR tunnel might be signalled not taking the
SRLG constraints into account.

Advanced Configuration Guide

Page 1879

Overview

SRLG
Figure 188 displays the initial topography for this section.
CE-4

CE-3

1/1/1
.1

1/1/1
192.168.1.0/30

192.168.5.0/30

.1

.2
PE-3
192.0.2.3

1/1/3 .1

192.168.2.0/30

1/1/2 .1

192.168.7.0/30

192.168.4.0/30

1/1/1 .2

1/1/2 .2

1/1/2

P-4

1/1/3

PE-2
192.0.2.2

1/1/2 .1

PE-4
192.0.2.4

1/1/2

.2

PE-1
192.0.2.1

P-1

.1

1/1/1
192.168.3.0/30

.2

1/1/1 .2

1/1/4
PE-5
192.0.2.5

.1

1/1/4
192.168.6.0/30

PE-4

.2

PE-6
192.0.2.6

P-6

OSSG413

Figure 188: Initial Topology

A single IGP area (IS-IS in this case) with traffic engineering enabled is required for the SRLG
feature to work properly.
When OSPF is used as the IGP, the functionality is similar.

Page 1880

Advanced Configuration Guide

Shared Risk Link Groups for RSVP-Based LSP

Configuration
Step 1. Configuring the IP/MPLS network.

This is part of the general P2P LSP configuration. For more details check the related
configurations of the PE-nodes.
In addition, ECMP is set to 2, instead of the default value 1 in order to highlight the application of
SRLG in the final example.
A:PE-1# configure router ecmp 2
A:PE-1#

2. Define the SRLG groups, and link them to the related MPLS interfaces.
There are 2 SRLG groups defined, named blue and grey. On following drawing the related IP/
MPLS interfaces are indicated.

1/1/1
.1

1/1/1

192.168.1.0/30

1/1/2

.2

PE-1
192.0.2.1

.1

1/1/3

192.168.5.0/30

.2

PE-2
192.0.2.2

1/1/2 .1

PE-3
192.0.2.3

1/1/3 .1

1/1/2 .1

SRLG
Blue
192.168.2.0/30

192.168.4.0/30

1/1/1 .2

192.168.7.0/30

1/1/2 .2

1/1/2
PE-4
192.0.2.4

SRLG
Grey

.1

1/1/1

192.168.3.0/30

.2

1/1/1 .2

1/1/4
PE-5
192.0.2.5

.1

192.168.6.0/30

1/1/4
.2

PE-6
192.0.2.6

Figure 189: SRLG Topology

From configuration point of view, both SRLG groups must be configured on all nodes as follows.
A:PE-2# /configure router mpls srlg-group blue value 1
*A:PE-2# /configure router mpls srlg-group grey value 2

The IP/MPLS interfaces need to be linked to the related SRLG group, which is a uni-directional
indicator, applying only at the egress direction; hence, it needs to be configured on both sides of

Advanced Configuration Guide

Page 1881

Configuration

the IP/MPLS interface. For example on PE-1, the interface to PE-2 is part of srlg-group blue.
Note that an interface can be part of multiple SRLG groups similar to the admin-group
functionality.
*A:PE-1>config>router>mpls# info
---------------------------------------------admin-group "green" 1
admin-group "red" 2
srlg-group "blue" value 1
srlg-group "grey" value 2
interface "system"
exit
interface "int-PE-1-PE-2"
admin-group "green"
exit
interface "int-PE-1-PE-4"
admin-group "red"
exit
*A:PE-1>config>router>mpls# interface "int-PE-1-PE-2"
*A:PE-1>config>router>mpls>if# srlg-group blue

The same must done on PE-2, PE-3, PE-5 and PE-6. Afterwards, verify the MPLS configuration
for example on PE-2, where the SRLG groups are linked to the interfaces, admin-groups are
configured in parallel to indicate that both can be configured and will work independently.
*A:PE-2>config>router>mpls# info
---------------------------------------------admin-group "green" 1
admin-group "red" 2
srlg-group "blue" value 1
srlg-group "grey" value 2
interface "system"
exit
interface "int-PE-2-PE-1"
admin-group "green"
srlg-group "blue"
exit
interface "int-PE-2-PE-3"
admin-group "green"
srlg-group "grey"
exit
interface "int-PE-2-PE-5"
srlg-group "blue"
exit
no shutdown
---------------------------------------------A:PE-2>config>router>mpls#

Some useful show commands to verify the SRLG configuration.


To show all SRLG groups on the node and the related interfaces:
A:PE-2# show router mpls srlg-group
===============================================================================
MPLS Srlg Groups
===============================================================================

Page 1882

Advanced Configuration Guide

Shared Risk Link Groups for RSVP-Based LSP

Group Name
Group Value
Interfaces
------------------------------------------------------------------------------blue
1
int-PE-2-PE-1
int-PE-2-PE-5
grey
2
int-PE-2-PE-3
------------------------------------------------------------------------------No. of Groups: 2
===============================================================================
A:PE-2#

In the list of MPLS interfaces, admin groups and SRLG groups are indicated.
A:PE-2# show router mpls interface
==============================================================================
MPLS Interfaces
==============================================================================
Interface
Port-id
Adm
Opr
TE-metric
-----------------------------------------------------------------------------system
system
Up
Up
None
Admin Groups
None
int-PE-2-PE-1
1/1/1
Up
Up
None
Admin Groups
green
Srlg Groups
blue
int-PE-2-PE-3
1/1/2
Up
Up
None
Admin Groups
green
Srlg Groups
grey
int-PE-2-PE-5
1/1/3
Up
Up
None
Admin Groups
None
Srlg Groups
blue
-----------------------------------------------------------------------------Interfaces : 4
==============================================================================
A:PE-2#

Advanced Configuration Guide

Page 1883

Configuration

To verify the SRLG groups in the IGP TE database, the following command can be used. The
output can be sizable extensive but searching on the SRLG groups name will lead to the correct
interface(s).
As an example we will look to the link-state advertisements of PE-2 (on PE-1 in this case), and we
see that the SRLG information is linked to the IP interfaces in a dedicated (TE-)TLV.
A:PE-1# show router isis database PE-2.00-00 detail
===============================================================================
ISIS Database
===============================================================================
Displaying Level 1 database
------------------------------------------------------------------------------LSP ID
: PE-2.00-00
Level
: L1
Sequence : 0x17
Checksum : 0xcc3b
Lifetime : 732
Version
: 1
Pkt Type : 18
Pkt Ver
: 1
Attributes: L1L2
Max Area : 3
SysID Len : 6
Used Len : 508
Alloc Len : 508
TLVs :
TE SRLGs
:
SRLGs : PE-1.00
Lcl Addr : 192.168.1.2
Rem Addr : 192.168.1.1
Num SRLGs
: 1
1
TE SRLGs
:
SRLGs : PE-3.00
Lcl Addr : 192.168.5.1
Rem Addr : 192.168.5.2
Num SRLGs
: 1
2
TE SRLGs
:
SRLGs : PE-5.00
Lcl Addr : 192.168.4.1
Rem Addr : 192.168.4.2
Num SRLGs
: 1
1
===============================================================================
A:PE-1#

Page 1884

Advanced Configuration Guide

Shared Risk Link Groups for RSVP-Based LSP

On-Line Verification
An on-line verification can be done by a tools perform CLI command. This will trigger a real
CSPF call to the IGP TE database, and the result will be an ERO object which can potentially be
used to set-up a CSPF based LSP.
The following shows the command syntax.
*A:PE-1# tools perform router mpls cspf
- cspf to <ip-addr> [from <ip-addr>] [bandwidth <bandwidth>] [include-bitmap
<bitmap>] [exclude-bitmap <bitmap>] [hop-limit <limit>] [exclude-address
<excl-addr> [<excl-addr>...(upto 8 max)]] [use-te-metric] [strict-srlg]
[srlg-group <grp-id>...(upto 8 max)] [exclude-node <excl-node-id>
[<excl-node-id>..(upto 8 max)]] [skip-interface <interface-name>]
[ds-class-type <class-type>] [cspf-reqtype <req-type>] [least-fill-min-thd
<thd>] [setup-priority <val>] [hold-priority <val>]
<ip-addr>
<bandwidth>
<bitmap>
<limit>
<excl-addr>
<use-te-metric>
<strict-srlg>
<grp-id>
<excl-node-id>
<interface-name>
<class-type>
<req-type>
<thd>
<priority>

: a.b.c.d
: [1..100000] in Mbps
: [0..4294967295] - accepted in decimal, hex(0x) or
binary(0b)
: [1..255]
: a.b.c.d (outbound interface)
: keyword
: keyword
: [0..4294967295]
: [a.b.c.d]
: [max 32 chars]
: [0..7]
: all|random|least-fill : keywords
: [1..100]
: [0..7]

*A:PE-1#

Where the relevant parameters are:

to Defines the far-end address of the LSP. This is the system-address of the destination
LER

srlg-group Specifies which SRLG groups should be avoided while building the path to
the destination (ERO object)

strict-srlg Indicates whether the SRLG group is a strict requirement or not. When this
parameter is given, only paths without traversing the SRLG will be displayed.

Advanced Configuration Guide

Page 1885

Configuration

An example:
On PE-1 a CSPF calculation is made with PE-3 as destination, without any SRLG restrictions, this
will look like the following output:
*A:PE-1# tools perform router mpls cspf to 192.0.2.3
Req CSPF for all ECMP paths
from: this node to: 192.0.2.3 w/(no Diffserv) class: 0 , setup Priority 7, Hold Priority 0 TE Class: 7
CSPF Path
To
: 192.0.2.3
Path 1
: (cost 20)
Start: 192.0.2.1
Egr:
192.168.1.1
Egr:
192.168.5.1
End:
192.0.2.3

-> Ingr:
-> Ingr:

192.168.1.2
192.168.5.2

(met 10)
(met 10)

*A:PE-1#

Given a restriction on srlg-group blue (grp-id =1), the result is as follows.


*A:PE-1# tools perform router mpls cspf to 192.0.2.3 srlg-group 1
Req CSPF for all ECMP paths
from: this node to: 192.0.2.3 w/(no Diffserv) class: 0 , setup Priority 7, Hold Priority 0 TE Class: 7
CSPF Path
To
: 192.0.2.3
Path 1
: (cost 40)
Start: 192.0.2.1
Egr:
192.168.2.1
Egr:
192.168.3.1
Egr:
192.168.6.1
1 SRLGs: 2
Egr:
192.168.7.2
End:
192.0.2.3

-> Ingr:
-> Ingr:
-> Ingr:

192.168.2.2
192.168.3.2
192.168.6.2

(met 10)
(met 10)
(met 10)

-> Ingr:

192.168.7.1

(met 10)

*A:PE-1#

The path will be through PE-4, PE-5 and PE-6.


When a strict restriction is requested on srlg-group grey, no valid CSPF path towards the
destination can be found. Removing the strict restriction results in a successful return of CSPF.
*A:PE-1# tools perform router mpls cspf to 192.0.2.3 srlg-group 2 strict-srlg
Req CSPF for all ECMP paths
from: this node to: 192.0.2.3 w/(no Diffserv) class: 0 , setup Priority 7, Hold Priority 0 TE Class: 7
MINOR: CLI No CSPF path to "192.0.2.3" with specified constraints.
*A:PE-1# tools perform router mpls cspf to 192.0.2.3 srlg-group 2
Req CSPF for all ECMP paths

Page 1886

Advanced Configuration Guide

Shared Risk Link Groups for RSVP-Based LSP

from: this node to: 192.0.2.3 w/(no Diffserv) class: 0 , setup Priority 7, Hold Priority 0 TE Class: 7
CSPF Path
To
: 192.0.2.3 (NOT SRLG DISJOINT)
Path 1
: (cost 20)
Start: 192.0.2.1
Egr:
192.168.1.1
-> Ingr:
192.168.1.2
1 SRLGs: 1
Egr:
192.168.5.1
-> Ingr:
192.168.5.2
1 SRLGs: 2
End:
192.0.2.3

(met 10)
(met 10)

*A:PE-1#

The best practice for debugging is to enable debug-tracing on the CSPF process, with following
command.
A:PE-1# debug router isis cspf

Advanced Configuration Guide

Page 1887

Configuration

SRLG for FRR


The fast-reroute mechanism used here is facility link-protection. The SRLG feature is independent
of the FRR type and works for all combinations (facility versus one-to-on, link versus node
protection).
Step 1. Configure an LSP.

An LSP from PE-1 to PE-3 will be created, CSPF based.

1/1/1
.1

1/1/1
192.168.1.0/30

.2

PE-1
192.0.2.1

.1

1/1/3
192.168.5.0/30

.2

PE-2
192.0.2.2

1/1/2 .1

PE-3
192.0.2.3

1/1/3 .1

192.168.2.0/30

1/1/2 .1

192.168.7.0/30

192.168.4.0/30

1/1/1 .2

1/1/2 .2

1/1/2
PE-4
192.0.2.4

1/1/2

.1

1/1/1
192.168.3.0/30

.2

1/1/1 .2

1/1/4
PE-5
192.0.2.5

.1

1/1/4
192.168.6.0/30

.2

PE-6
192.0.2.6
OSSG414

Figure 190: Path Primary RSVP_TE LSP

The configuration of the LSP lsp-PE-1-PE-6-FRR-facility-link is based on an empty path, with


FRR facility link protection enabled.
*A:PE-1>config>router>mpls# lsp lsp-PE-1-PE-6_FRR_facility-link
*A:PE-1>config>router>mpls>lsp# info
---------------------------------------------to 192.0.2.3
cspf
fast-reroute facility
no node-protect
exit
primary "prim"
exit
no shutdown
---------------------------------------------*A:PE-1>config>router>mpls>lsp#

Page 1888

Advanced Configuration Guide

Shared Risk Link Groups for RSVP-Based LSP

To verify the primary path, oam lsp-trace command can be used, checking the intermediate
nodes.
*A:PE-1# oam lsp-trace lsp-PE-1-PE-6_FRR_facility-link detail
lsp-trace to lsp-PE-1-PE-6_FRR_facility-link: 0 hops min, 0 hops max, 116 byte packets
1 192.0.2.2 rtt=4.32ms rc=8(DSRtrMatchLabel)
DS 1: IfAddr 192.168.5.2 MRU=1500 label=131071 proto=4(RSVP-TE)
2 192.0.2.3 rtt=11.6ms rc=3(EgressRtr)
*A:PE-1#

To check if the bypass tunnels are up and running, an indication (@)can be found in the detail
output of show router mpls ls <x> path detail as seen in the following output.
*A:PE-1# show router mpls lsp lsp-PE-1-PE-6_FRR_facility-link path detail
===============================================================================
MPLS LSP lsp-PE-1-PE-6_FRR_facility-link Path (Detail)
===============================================================================
Legend :
@ - Detour Available
# - Detour In Use
b - Bandwidth Protected
n - Node Protected
s - Soft Preemption
===============================================================================
------------------------------------------------------------------------------LSP lsp-PE-1-PE-6_FRR_facility-link Path prim
------------------------------------------------------------------------------LSP Name
: lsp-PE-1-PE-6_FRR_facility-link
Path LSP ID : 12288
From
: 192.0.2.1
To
: 192.0.2.3
Adm State
: Up
Oper State : Up
Path Name
: prim
Path Type
: Primary
Path Admin : Up
Path Oper
: Up
OutInterface: 1/1/1
Out Label
: 131071
Path Up Time: 0d 00:04:18
Path Dn Time: 0d 00:00:00
Retry Limit : 0
Retry Timer : 30 sec
RetryAttempt: 0
NextRetryIn : 0 sec
SetupPriori*: 7
Hold Priori*: 0
Bandwidth
: No Reservation
Oper Bw
: 0 Mbps
Hop Limit
: 255
Class Type : 0
Record Route: Record
Record Label: Record
Oper MTU
: 1496
Neg MTU
: 1496
Adaptive
: Enabled
Oper Metric : 20
Include Grps:
Exclude Grps:
None
None
Path Trans : 1
CSPF Queries: 1
Failure Code: noError
Failure Node: n/a
ExplicitHops:
No Hops Specified
Actual Hops :
192.168.1.1(192.0.2.1) @
Record Label
: N/A
-> 192.168.1.2(192.0.2.2) @
Record Label
: 131071
-> 192.168.5.2(192.0.2.3)
Record Label
: 131071
ComputedHops:
192.168.1.1
-> 192.168.1.2
-> 192.168.5.2
ResigEligib*: False
LastResignal: n/a
CSPF Metric : 20
===============================================================================
* indicates that the corresponding row element may have been truncated.
*A:PE-1#

Advanced Configuration Guide

Page 1889

Configuration

The expected path(s) followed by the bypass tunnels are shown in Figure 191.
Primary

1/1/1
.1

1/1/1

192.168.1.0/30

1/1/2

.2

PE-1
192.0.2.1

.1

1/1/3

192.168.5.0/30

.2

PE-2
192.0.2.2

1/1/2 .1

PE-3
192.0.2.3

1/1/3 .1

1/1/2 .1

SRLG
Blue
192.168.4.0/30

192.168.2.0/30

1/1/1 .2

1/1/2 .2

1/1/2
PE-4
192.0.2.4

192.168.7.0/30

.1

192.168.3.0/30

1/1/1
.2

1/1/1 .2

1/1/4
PE-5
192.0.2.5

.1

1/1/4

192.168.6.0/30

.2

PE-6
192.0.2.6

Figure 191: SRLG for FRR Path With and Without SRLG

To verify the data path on the point of local repair (PLR), the next CLI commands can be used.
*A:PE-1# show router mpls bypass-tunnel detail
===============================================================================
MPLS Bypass Tunnels (Detail)
===============================================================================
------------------------------------------------------------------------------bypass-link192.168.1.2
------------------------------------------------------------------------------To
: 192.168.4.1
State
: Up
Out I/F
: 1/1/2
Out Label
: 131071
Up Time
: 0d 00:06:34
Active Time
: n/a
Reserved BW
: 0 Kbps
Protected LSP Count : 1
Type
: Dynamic
SetupPriority
: 7
Hold Priority
: 0
Class Type
: 0
Actual Hops
:
192.168.2.1
-> 192.168.2.2
-> 192.168.3.2
-> 192.168.4.1
===============================================================================
*A:PE-1#

The SRLG restriction is not taken into account at this moment at PLR PE-1. The actual hops are
PE-4, PE-5 and PE-3 visualized by the dashed path in Figure 191.

Page 1890

Advanced Configuration Guide

Shared Risk Link Groups for RSVP-Based LSP

To take the SRLG restrictions into account, additional configuration is needed for MPLS.
*A:PE-1>config>router>mpls# info
---------------------------------------------admin-group "green" 1
admin-group "red" 2
srlg-group "blue" value 1
srlg-group "grey" value 2
srlg-group "red" value 3
interface "system"
exit
*A:PE-1>config>router>mpls# srlgsrlg-database
srlg-frr
srlg-group
*A:PE-1>config>router>mpls# srlg-frr
- no srlg-frr
- srlg-frr [strict]
<strict>
: keyword

*A:PE-1>config>router>mpls# srlg-frr strict


*A:PE-1>config>router>mpls# info
---------------------------------------------admin-group "green" 1
admin-group "red" 2
srlg-frr strict
srlg-group "blue" value 1
srlg-group "grey" value 2
srlg-group "red" value 3
interface "system"
exit
*A:PE-1>config>router>mpls#

The option strict should only be taken if the logical topology allows this. In other words, one must
be sure that an alternative path is possible which avoids SRLG-groups.
After applying the SRLG FRR feature, the related LSP needs to be resignaled in order to set up the
bypass tunnel with the new constraints.
*A:PE-1# tools perform router mpls resignal lsp lsp-PE-1-PE-6_FRR_facility-link path prim
*A:PE-1#

Advanced Configuration Guide

Page 1891

Configuration

This can be verified with previous commands.


*A:PE-1# show router mpls bypass-tunnel detail
===============================================================================
MPLS Bypass Tunnels (Detail)
===============================================================================
------------------------------------------------------------------------------bypass-link192.168.1.2
------------------------------------------------------------------------------To
: 192.168.5.1
State
: Up
Out I/F
: 1/1/2
Out Label
: 131071
Up Time
: 0d 00:06:53
Active Time
: n/a
Reserved BW
: 0 Kbps
Protected LSP Count : 1
Type
: Dynamic
SetupPriority
: 7
Hold Priority
: 0
Class Type
: 0
Actual Hops
:
192.168.2.1
-> 192.168.2.2
-> 192.168.3.2
-> 192.168.6.2
-> 192.168.7.1
-> 192.168.5.1
===============================================================================
*A:PE-1#

This path is represented by the dotted line in previous figure, taking the SRLG constraints into
account.

Page 1892

Advanced Configuration Guide

Shared Risk Link Groups for RSVP-Based LSP

SRLG for Standby Path


Where SRLG groups will be constraints for bypass tunnels, they will also be a constraint to set-up
a secondary path. Looking at the following picture, we expect the secondary path to follow the
dotted-line instead of passing over the direct link between PE-5 and PE-2.
Primary

1/1/1
.1

1/1/1

192.168.1.0/30

1/1/2

.2

PE-1
192.0.2.1

.1

192.168.5.0/30

1/1/3
.2

PE-2
192.0.2.2

1/1/2 .1

PE-3
192.0.2.3

1/1/3 .1

1/1/2 .1

SRLG
Blue
192.168.4.0/30

192.168.2.0/30

1/1/1 .2

1/1/2 .2

1/1/2
PE-4
192.0.2.4

192.168.7.0/30

.1

1/1/1

192.168.3.0/30

.2

1/1/1 .2

1/1/4
PE-5
192.0.2.5

.1

192.168.6.0/30

1/1/4
.2

PE-6
192.0.2.6

Figure 192: SRLG for Secondary Path

The configuration of the LSP will need a specific indication at the level of the secondary path to
enable the restriction on the srlg-groups.
*A:PE-1# configure router mpls lsp "lsp-PE-1-PE-2-srlg"
*A:PE-1>config>router>mpls>lsp# info
---------------------------------------------to 192.0.2.2
cspf
primary "prim"
exit
secondary "secon"
standby
srlg
exit
no shutdown
---------------------------------------------*A:PE-1>config>router>mpls>lsp#

Where both paths are empty paths, the ERO object creation solely relies on CPSF without any
specific hop.

Advanced Configuration Guide

Page 1893

Configuration

To verify the datapath, the detailed output of the show router mpls command can be used, as well
as the lsp-trace OAM command. This output shows both ERO objects of the primary and
secondary path.
*A:PE-1# show router mpls lsp "lsp-PE-1-PE-2-srlg" path detail
===============================================================================
MPLS LSP lsp-PE-1-PE-2-srlg Path (Detail)
===============================================================================
Legend :
@ - Detour Available
# - Detour In Use
b - Bandwidth Protected
n - Node Protected
s - Soft Preemption
===============================================================================
------------------------------------------------------------------------------LSP lsp-PE-1-PE-2-srlg Path prim
------------------------------------------------------------------------------Actual Hops :
192.168.1.1(192.0.2.1)
Record Label
: N/A
-> 192.168.1.2(192.0.2.2)
Record Label
: 131066
ComputedHops:
192.168.1.1
-> 192.168.1.2
------------------------------------------------------------------------------LSP lsp-PE-1-PE-2-srlg Path secon
------------------------------------------------------------------------------Actual Hops :
192.168.2.1(192.0.2.1)
Record Label
: N/A
-> 192.168.2.2(192.168.2.4)
Record Label
: 131070
-> 192.168.3.2(192.0.2.5)
Record Label
: 131069
-> 192.168.6.2(192.0.2.6)
Record Label
: 131070
-> 192.168.7.1(192.0.2.3)
Record Label
: 131069
-> 192.168.5.1(192.0.2.2)
Record Label
: 131069
ComputedHops:
192.168.2.1
-> 192.168.2.2
-> 192.168.3.2
-> 192.168.6.2
-> 192.168.7.1
-> 192.168.5.1
Srlg
: Enabled
SrlgDisjoint: True
ResigEligib*: False
LastResignal: n/a
CSPF Metric : 50
===============================================================================
* indicates that the corresponding row element may have been truncated.
*A:PE-1#

Page 1894

Advanced Configuration Guide

Shared Risk Link Groups for RSVP-Based LSP

The lsp-trace command can be used for secondary path as well. The intermediate LSRs and the
MPLS labels used can be clearly seen.
*A:PE-1# oam lsp-trace lsp-PE-1-PE-2-srlg path secon detail
lsp-trace to lsp-PE-1-PE-2-srlg: 0 hops min, 0 hops max, 116 byte packets
1 192.168.2.4 rtt=1.33ms rc=8(DSRtrMatchLabel)
DS 1: IfAddr 192.168.3.2 MRU=1500 label=131069 proto=4(RSVP-TE)
2 192.0.2.5 rtt=1.78ms rc=8(DSRtrMatchLabel)
DS 1: IfAddr 192.168.6.2 MRU=1500 label=131070 proto=4(RSVP-TE)
3 192.0.2.6 rtt=2.46ms rc=8(DSRtrMatchLabel)
DS 1: IfAddr 192.168.7.1 MRU=1500 label=131069 proto=4(RSVP-TE)
4 192.0.2.3 rtt=2.60ms rc=8(DSRtrMatchLabel)
DS 1: IfAddr 192.168.5.1 MRU=1500 label=131069 proto=4(RSVP-TE)
5 192.0.2.2 rtt=2.60ms rc=3(EgressRtr)
*A:PE-1#

Advanced Configuration Guide

Page 1895

Configuration

SRLG Database
In case not all IP/MPLS routers in the area support SRLG, a static SRLG database can be created
on the systems which will be used as an additional constraint when performing the CSPF
calculation to define the path.
An example can be seen Figure 193 where an additional SRLG group (red) is locally on PE-1,
with information related to the interface between PE-4 and PE-5.
SRLG-database
Red

1/1/1

1/1/1

.1 192.168.1.0/30

1/1/2

.2

PE-1
192.0.2.1

.1

1/1/3

192.168.5.0/30

.2

PE-2
192.0.2.2

1/1/2 .1

PE-3
192.0.2.3

1/1/3 .1

1/1/2 .1

SRLG
Blue
192.168.4.0/30

192.168.2.0/30

1/1/1 .2

192.168.7.0/30

1/1/2 .2

1/1/2
PE-4
192.0.2.4

SRLG
Grey

.1

1/1/1
192.168.3.0/30 .2

1/1/1 .2

1/1/4
PE-5
192.0.2.5

.1

192.168.6.0/30

1/1/4
.2

PE-6
192.0.2.6

Figure 193: SRLG Database Example

*A:PE-1>config>router>mpls# info
---------------------------------------------admin-group "green" 1
admin-group "red" 2
srlg-group "blue" value 1
srlg-group "grey" value 2
srlg-group "red" value 3
interface "system"
exit
interface "int-PE-1-PE-2"
admin-group "green"
srlg-group "blue"
exit
interface "int-PE-1-PE-4"
admin-group "red"
exit

Page 1896

Advanced Configuration Guide

Shared Risk Link Groups for RSVP-Based LSP

srlg-database
router-id 192.0.2.4
interface 192.168.3.1 srlg-group "red"
no shutdown
exit
router-id 192.0.2.5
interface 192.168.3.2 srlg-group "red"
no shutdown
exit
exit

Note that this information is only local and will only have effect on CSPF calculations on PE-1,
not on the other nodes.
When a CSPF calculation is done for a path from PE-1 to PE-5, the result will be two equal-cost
paths. When adding the srlg-group red as a restriction, only a single path will be found, passing
PE-2.

Advanced Configuration Guide

Page 1897

Conclusion

Conclusion
Interpreting the SLRG information into the TE database makes it possible to protect an LSP even
when multiple IP/MPLS interfaces fail as a result of an underlying transmission failure.
Transmission failures can occur quiet often since not all transmission links are 1:1 protected.
SRLG groups in MPLS provide a very dynamic and simple way to assure LSP FRR path
protection on every PLR throughout the followed LSP path. The SRLG groups are also taken into
account when defining the ERO for secondary paths, at least if the configured secondary path is
empty.
For interoperability reasons the SRLG-database is available, as systems can link interface to an
SRLG with interconnecting systems that do not support the SRLG feature; hence they can not
advertise the SRLG information through the IGP.
Note that the creation and maintenance of an SRLG database requires operational effort and
systems that do not support SRLG will never take any SRLG information into account during
CSPF calculation for the creation of FRR bypass or detour tunnels.

Page 1898

Advanced Configuration Guide

Shortest Path Bridging for MAC

In This Chapter
This section describes advanced shortest path bridging for MAC configurations.
Topics in this section include:

Applicability on page 1900

Overview on page 1901

Configuration on page 1903

Conclusion on page 1933

Advanced Configuration Guide

Page 1899

Applicability

Applicability
The example presented in this section is applicable to the 7950 XRS, 7750 SR-c4/c12, 7750 SR-7/
12 and 7450 ESS-6/6v/7/12, and requires IOM3-XP/IMM or higher-based line cards. It is not
supported in 7750 SR-1, 7450 ESS-1, 7710 SR or IOM-2 or lower-based line cards.
The configuration was tested on release 11.0R4. Shortest Path Bridging for MAC (SPBM) is
supported from 10.0R4. SPB Static MAC, static I-service Instance Identifiers (ISIDs) and ISIDpolicies for SPB are supported from 11.0R4 onwards.

Page 1900

Advanced Configuration Guide

Shortest Path Bridging for MAC

Overview
SPB enables a next generation control plane for Provider Backbone Bridges (PBB) and PBBVPLS that adds the stability and efficiency of link state to unicast and multicast services (I-VPLS
and Epipes). In addition, SPBM provides resiliency, load-balancing and multicast optimization
without the need for any other control plane in the B-VPLS (for example, there is no need for
Spanning Tree or G.8032 or MMRP).
SPBM exploits the complete knowledge of backbone addressing, which is a key consequence of
the PBB hierarchy, by advertising and distributing the Backbone MACs (BMACs) through a linkstate protocol, namely IS-IS. An immediate effect of this is that the old flood-and-learn can at
last be turned off in the backbone and every B-VPLS node in the network will know what
destination BMAC addresses are expected and valid. As a result of that, receiving an unknown
unicast BMAC on a B-VPLS SAP/PW is indicative of an error, whereupon the frame is discarded
(due to the Reverse Path Forwarding Check RPFC performed in SPBM) instead of flooded.
Furthermore, SPBM allows condensing all the relevant information distribution (unicast and
multicast) into a single control protocol: IS-IS.
SPBM can be easily enabled on the existing B-VPLS instances being used for multiplexing IVPLS/Epipe services, providing the benefits summarized below:

Per-service flood containment (for I-VPLS services) without the need for an additional
protocol such as MMRP.

Loop avoidance in the B-VPLS domain without the need for MSTP or other technologies.

No unknown BMAC flooding in the B-VPLS domain.

No need for MAC notification mechanisms or vMEPs in the B-VPLS to update the BVPLS Forwarding Data Bases (FDBs) (vMEPs can still be configured though for OAM
purposes).

Some other characteristics of the SPB implementation in the SR OS are listed below:

The SR OS SPB implementation always uses Multi-Topology (MT) topology instance


zero. However, up to four logical instances (that is, SPB instances in different B-VPLS
services) are supported if different topologies are required for different services.

Area addresses are not used and SPB is assumed to be a single area. SPB must be
consistently configured on nodes in the system. SPB Regions information and IS-IS hello
logic that detect mismatched configuration are not supported. IS-IS area is always zero.

SPB uses All-Intermediate-Systems 09-00-2B-00-00-05 destination MAC to


communicate.

SPB Source ID is always zero.

SPB uses a separate instance of IS-IS from the base IP IS-IS. IS-IS for SPB is configured
in the SPB context under the B-VPLS component. Up to four ISIS-SPB instances are

Advanced Configuration Guide

Page 1901

Overview

supported, where the instance identifier can be any number between 1024 and 2047. The
instance number is not in TLVs.

Two ECT-ALGORITHMs (IEEE 802.1aq Equal Cost Tree Algorithms) per SPB instance
are supported: low-path-id and high-path-id algorithms.

SPB Link State Protocol Data Units (Link State Packets) contain BMACs, ISIDs (for
multicast services) and link and metric information for an IS-IS database.
Epipe ISIDs are not distributed in SR OS SPB allowing high scalability of PBB
Epipes.
I-VPLS ISIDs are distributed in SR OS SPB and the respective multicast group
addresses (composed of PBB-OUI plus ISID) are automatically populated in a
manner that provides automatic pruning of multicast to the subset of the multicast tree
that supports an I-VPLS with a common ISID. This replaces the function of MMRP
and is more efficient than MMRP.

Page 1902

Multiple ISIS-SPB adjacencies between two nodes are not supported as per the IEEE
802.1aq standard specification. If multiple links between two nodes exist, LAG must be
used.

Advanced Configuration Guide

Shortest Path Bridging for MAC

Configuration
This section will describe the configuration of SPBM on the 7x50 as well as the available
troubleshooting commands.

Basic SPBM Configuration


Figure 194 shows the topology used as an example of a basic SPBM configuration.

Multicast Designated Bridge


CE-331

PE-63
192.0.2.63

PE-65
192.0.2.65

I-VPLS 11

9:11 1:11

PE-67
192.0.2.67

11

10

10

B-VPLS Instance

I-Instance

10

ST ISID 11

12

9:12 1:12
CE-312
Epipe 12

I-VPLS 11
11

9:11

CE-611

1:11

11

10

10

1:11 9:11

10
12

I-VPLS 11

PE-66
192.0.2.66

CE-411

PE-69
192.0.2.69

1:12 9:12
CE-412
Epipe 12

PE-64
192.0.2.64

al_0275

Figure 194: Basic SPBM Topology

Assume the following protocols and objects are configured beforehand:

The six PEs shown in Figure 194 are running IS-IS for the global routing table with all the
interfaces being Level-2.

LDP is used as the MPLS protocol to signal transport tunnel labels.

LDP SDPs are configured among the six PEs, in the way it is depicted in Figure 194
(dashed lines and bold lines among PEs).

Once the network infrastructure is properly running, the actual service configuration can be
carried out. In the example, B-VPLS 10 will provide backbone connectivity for the services IVPLS 11 and Epipe 12.

Advanced Configuration Guide

Page 1903

Configuration

The SPBM configuration is only relevant to the B-VPLS instance and can be added to an existing
B-VPLS, assuming that such a B-VPLS does not contain any non-SPB-compatible configuration
parameters. The following parameters are not supported in SPB-enabled B-VPLS instances:

mesh-sdps (only SAPs or spoke-sdps are supported in SPB-enabled B-VPLS)

Spanning Tree Protocol (STP)

Split-Horizon Groups

Non-conditional Static-macs (configured under sap/spoke-sdps, see section about static


BMAC configuration)

G.8032

Propagate-mac-flush and send-flush-on-failure

Maximum number of macs (max-nbr-mac-addr)

Bridge Protocol Data Unit (BPDU) translation

Layer-2 Protocol Termination (L2PT)

Mac-pinning

Oper-groups

Mac-move

Any BGP, BGP-AD (BGP Autodiscovery) or BGP-VPLS (BGP Virtual Private LAN
Services) parameters

Endpoints

Local/remote age

Mac-notification

Mac-protect

Mesh-sdps

Multiple MAC Registration Protocol (MMRP)

Provider-tunnel

Temporary flooding

Assuming all the parameters mentioned above are not configured in the B-VPLS (B-VPLS 10 in
the example), SPBM can be enabled. The SPBM parameters are all configured under the
config>service>vpls(b-vpls)>spb and config>service>vpls(b-vpls)>spoke-sdp/sap>spb
contexts:
*A:PE-63# configure service vpls 10 spb ?
- no spb
- spb [<isis-instance>] [fid <fid>] [create]
<isis-instance>
: [1024..2047]
<fid>
: [1..4095]
level
+ Configure SPB level information
[no] lsp-lifetime
- Configure LSP lifetime

Page 1904

Advanced Configuration Guide

Shortest Path Bridging for MAC

[no] lsp-wait
[no] overload
[no] overload-on-bo*
boot up
[no] shutdown
[no] spf-wait

- Configure ISIS LSP wait times


- Configure the local router so that it appears to be overloaded
- Configure the local router so that it appears to be overloaded at
- Administratively enable or disable the operation of ISIS
- Configure ISIS SPF wait times

*A:PE-63# configure service vpls 10 spoke-sdp 35:10 spb ?


- no spb
- spb [create]
<create>
: keyword
level
+ Configure SPB level information
[no] lsp-pacing-int* - Configure the interval between LSP packets are sent from the interface
[no] retransmit-int* - Configure the minimum interval between LSP packets retransmission
for the given interface
[no] shutdown
- Administratively Enable/disable the interface
*A:PE-63# configure service vpls 10 spoke-sdp 35:10 spb level 1 ?
- level <[1..1]>
[no] hello-interval - Configure hello-interval for this interface
[no] hello-multipli* - Configure hello-multiplier for this level
[no] metric
- Configure IS-IS interface metric for IPv4 unicast

The parameters configured under the spb context refer to the SPB IS-IS and they should be
configured following the same considerations as for the IS-IS base instance:

spb [<isis-instance>] [fid <fid>] [create]


<isis-instance> identifies the SPB ISIS process. Up to four different ISIS SPB
processes can be run in a system (range 1024 to 2047).
<fid> or forwarding identifier identifies the standard SPBM B-VID which is signaled
in IS-IS with each advertised BMAC. Each B-VPLS has a single configurable FID.

spb>lsp-lifetime <seconds>

: [350..65535]

spb>lsp-wait <lsp-wait> [<lsp-initial-wait> [<lsp-second-wait>]]


<lsp-wait>

: [1..120] seconds

<initial-wait>

: [0..100] seconds

<second-wait>

: [1..100] seconds

spb>overload

spb>overload-on-boot

spb>spf-wait <spf-wait> [<spf-initial-wait> [<spf-second-wait>]]


<spf-wait>

: [1..120] seconds

<initial-wait>

: [10..100000] milliseconds

<second-wait>

Advanced Configuration Guide

: [1..100000] - milliseconds

Page 1905

Configuration

spoke-sdp/sap>spb>lsp-pacing-interval <milli-seconds>

: [0..65535]

spoke-sdp/sap>spb>retransmit-interval <seconds>

: [1..65535]

spoke-sdp/sap>spb>level 1>hello-interval <seconds>


spoke-sdp/sap>spb>level 1>hello-multiplier <multiplier>

: [1..20000]
: [2..100]

In the same way lsp-wait (initial-wait) and spf-wait (initial wait) can be tuned in the base router
IS-IS instance to minimize the convergence time (to 0 and 10 respectively), the equivalent SPB
IS-IS parameters should also be adjusted so that failover time is minimized at the service level.
The following parameters are specific to SPBM (note that only IS-IS level 1 is supported for
SPB):

spb>level 1>bridge-priority <bridge-priority>

: [0..15]

This parameter will influence the election of the Multicast Designated bridge through
which all the ST (Single Trees) for the multicast traffic will be established. The
default value will be lowered on that node where the Multicast Designated bridge
function is desired, normally because that node is the best connected node. Note that
in the example of this document, PE-65 is the Multicast Designated bridge for BVPLS 10 and therefore, PE-65 will be the root of the STs for the I-VPLS instances in
that B-VPLS. Default value = 8.

spb>level 1>ect-algorithm fid-range <fid-range> {low-path-id|high-path-id}


This command defines the ect-algorithm used and the FIDs assigned. Two algorithms
are supported: low-path-id and high-path-id. They can provide the required path
diversity for an efficient load balancing in the B-VPLS. Default = fid-range 1-4095
low-path-id

spb>level 1>forwarding-tree-topology unicast {spf|st}


This command configures the type of tree that will be used for unicast traffic: shortest
path tree or single tree. The multicast traffic (that encapsulated I-VPLS broadcast,
unicast and multicast (BUM) traffic always uses the ST path (Single Tree path). Note
that using SPF for unicast traffic can produce some packet re-ordering for unicast
traffic compared to BUM traffic as different trees are used, therefore, when the BVPLS transports I-VPLS traffic and the unicast and multicast trees do not follow the
same path, it is recommended to use ST paths for unicast and multicast. Default value
= spf.

spoke-sdp/sap>spb>level 1>metric <ipv4-metric>

: [1..16777215]

This command configures the metric for each SPB interface (spoke-SDP or SAP).
This value helps influence the SPF calculation in order to pick a certain path for the
traffic to a remote system BMAC. Note that when the SPB link metric advertised by
two peers is different, the maximum value is chosen according to the RFC 6329.
Default metric = 10.

Page 1906

Advanced Configuration Guide

Shortest Path Bridging for MAC

As an example, the following CLI output shows the relevant configuration of PE-63 and PE-65
(the Multicast Designated Bridge). SPB has to be created and enabled (no shutdown) at B-VPLS
service level first and then created and enabled under each and every SAP/spoke-sdp in the BVPLS. Non-SPB-enabled SAPs/spoke-sdps can exist in the SPB B-VPLS only if conditional
static-macs are configured for them (refer to Static BMACs and Static ISIDs Configuration on
page 1923). Note that, as for regular B-VPLS services, the service-mtu has to be changed from the
default value (1500) to a number 18-bytes greater than the I-VPLS service-mtu in order to allow
for the PBB encapsulation.
*A:PE-63>config>service# info
---------------------------------------------pbb
source-bmac 00:00:00:ca:fe:63
mac-name "PE-63" 00:00:00:ca:fe:63
mac-name "PE-64" 00:00:00:ca:fe:64
mac-name "PE-65" 00:00:00:ca:fe:65
mac-name "PE-66" 00:00:00:ca:fe:66
mac-name "PE-67" 00:00:00:ca:fe:67
mac-name "PE-69" 00:00:00:ca:fe:69
exit
...
vpls 10 customer 1 b-vpls create
service-mtu 2000
stp
shutdown
exit
spb 1024 fid 10 create
overload-on-boot timeout 60
spf-wait 2 50 100
lsp-wait 8 0 1
no shutdown
exit
spoke-sdp 35:10 create
spb create
no shutdown
exit
no shutdown
exit
spoke-sdp 36:10 create
spb create
no shutdown
exit
no shutdown
exit
no shutdown
exit
vpls 11 customer 1 i-vpls create
pbb
backbone-vpls 10
exit
exit
stp
shutdown
exit
sap 1/1/1:11 create
exit
no shutdown

Advanced Configuration Guide

Page 1907

Configuration

exit
epipe 12 customer 1 create
pbb
tunnel 10 backbone-dest-mac "PE-64" isid 12
exit
sap 1/1/1:12 create
exit
no shutdown
exit

As discussed, the bridge-priority will influence the election of the Multicast Designated Bridge.
By making PE-65s bridge-priority zero, it ensures that PE-65 becomes the root of all the STs for
B-VPLS 10 as long as the priority for the rest of the PEs is larger than zero. In case of a tie, the PE
owning the lowest system BMAC will be elected as Multicast Designated Bridge. Figure 194
shows the ST for I-VPLS 11 (see a thicker continuous line representing the ST). Note that PE-65 is
the root of the ST tree.
*A:PE-65>config>service# info
---------------------------------------------pbb
source-bmac 00:00:00:ca:fe:65
mac-name "PE-63" 00:00:00:ca:fe:63
mac-name "PE-64" 00:00:00:ca:fe:64
mac-name "PE-65" 00:00:00:ca:fe:65
mac-name "PE-66" 00:00:00:ca:fe:66
mac-name "PE-67" 00:00:00:ca:fe:67
mac-name "PE-69" 00:00:00:ca:fe:69
exit
...
vpls 10 customer 1 b-vpls create
service-mtu 2000
stp
shutdown
exit
spb 1024 fid 10 create
level 1
bridge-priority 0
exit
overload-on-boot timeout 60
spf-wait 2 50 100
lsp-wait 8 0 1
no shutdown
exit
spoke-sdp 53:10 create
spb create
no shutdown
exit
no shutdown
exit
spoke-sdp 56:10 create
spb create
no shutdown
exit
no shutdown
exit
spoke-sdp 57:10 create

Page 1908

Advanced Configuration Guide

Shortest Path Bridging for MAC

spb create
no shutdown
exit
no shutdown
exit
spoke-sdp 59:10 create
spb create
no shutdown
exit
no shutdown
exit
no shutdown
exit

The rest of the nodes will be configured accordingly. Note that SPB instance 1024 will set up SPF
(Shortest Path First) trees for unicast traffic and a ST (Single Tree) per ISID with PE-65 as the
root-bridge (since it has the lowest bridge-priority) for BUM traffic. The ect-algorithm chosen for
the B-VPLS FID (10) is the low-path-id (default one).
Once SPBM is configured as discussed above on all the six nodes, the six system BMACs and the
ISID 11 will be advertised by SPB IS-IS.
The following show commands can help understand the IS-IS configuration for SPB 1024 and the
BMACs populated by IS-IS:

show service id spb base: provides the SPB configuration and parameters for a particular
SPB B-VPLS.

show service id 10 spb fdb: provides the B-VPLS FDB that has been populated by IS-IS,
for the unicast and multicast entries.

*A:PE-63# show service id 10 spb base


===============================================================================
Service SPB Information
===============================================================================
Admin State
: Up
Oper State
: Up
ISIS Instance
: 1024
FID
: 10
Bridge Priority
: 8
Fwd Tree Top Ucast : spf
Fwd Tree Top Mcast : st
Bridge Id
: 80:00.00:00:00:ca:fe:63
Mcast Desig Bridge : 00:00.00:00:00:ca:fe:65
===============================================================================
ISIS Interfaces
===============================================================================
Interface
Level CircID Oper State
L1/L2 Metric
------------------------------------------------------------------------------sdp:35:10
L1
65536
Up
10/sdp:36:10
L1
65537
Up
10/------------------------------------------------------------------------------Interfaces : 2
===============================================================================
FID ranges using ECT Algorithm
------------------------------------------------------------------------------1-4095
low-path-id
===============================================================================

Advanced Configuration Guide

Page 1909

Configuration

*A:PE-63# show service id 10 spb fdb


==============================================================================
User service FDB information
==============================================================================
MAC Addr
UCast Source
State
MCast Source
State
-----------------------------------------------------------------------------00:00:00:ca:fe:64 35:10
ok
35:10
ok
00:00:00:ca:fe:65 35:10
ok
35:10
ok
00:00:00:ca:fe:66 36:10
ok
35:10
ok
00:00:00:ca:fe:67 35:10
ok
35:10
ok
00:00:00:ca:fe:69 35:10
ok
35:10
ok
-----------------------------------------------------------------------------Entries found: 5
==============================================================================

It can be seen above that the unicast (SPF) tree and the multicast (ST) tree differ with respect to
PE-66.
The following commands help check the unicast and multicast topology for B-VPLS 10:

show service id 10 spb routes provides a detailed view of the unicast and multicast routes
computed by SPF. As shown below, the SPB unicast and multicast routes match on PE-65
since this node is the Multicast Designated Bridge. Unicast and multicast routes will differ
on most other nodes.

show service id 10 spb mfib and show service id 10 mfib shows information of the
MFIB entries generated in the B-VPLS as well as the outgoing interface (OIF) associated
with those MFIB entries.

*A:PE-65# show service id 10 spb routes


================================================================
MAC Route Table
================================================================
FID MAC Addr
Ver.
Metric
NextHop If
SysID
---------------------------------------------------------------Fwd Tree: unicast
---------------------------------------------------------------10
00:00:00:ca:fe:63
3
10
sdp:53:10
PE-63
10
00:00:00:ca:fe:64
9
20
sdp:57:10
PE-67
10
00:00:00:ca:fe:66
4
10
sdp:56:10
PE-66
10
00:00:00:ca:fe:67
8
10
sdp:57:10
PE-67
10
00:00:00:ca:fe:69
12
10
sdp:59:10
PE-69
Fwd Tree: multicast
---------------------------------------------------------------10
00:00:00:ca:fe:63
3
10
sdp:53:10
PE-63
10
00:00:00:ca:fe:64
9
20
sdp:57:10
PE-67

Page 1910

Advanced Configuration Guide

Shortest Path Bridging for MAC

10

00:00:00:ca:fe:66
15
10
sdp:56:10
PE-66
10
00:00:00:ca:fe:67
8
10
sdp:57:10
PE-67
10
00:00:00:ca:fe:69
12
10
sdp:59:10
PE-69
---------------------------------------------------------------No. of MAC Routes: 10
================================================================
================================================================
ISID Route Table
================================================================
FID ISID
Ver.
NextHop If
SysID
---------------------------------------------------------------10
11
16
sdp:53:10
PE-63
sdp:56:10
PE-66
sdp:57:10
PE-67
---------------------------------------------------------------No. of ISID Routes: 1
================================================================

*A:PE-65# show service id 10 spb mfib


===============================================================================
User service MFIB information
===============================================================================
MAC Addr
ISID
Status
------------------------------------------------------------------------------01:1E:83:00:00:0B 11
Ok
------------------------------------------------------------------------------Entries found: 1
===============================================================================
A:PE-65# show service id 10 mfib
===============================================================================
Multicast FIB, Service 10
===============================================================================
Source Address Group Address
Sap/Sdp Id
Svc Id
Fwd/Blk
------------------------------------------------------------------------------*
01:1E:83:00:00:0B
b-sdp:53:10
Local
Fwd
b-sdp:56:10
Local
Fwd
b-sdp:59:10
Local
Fwd
------------------------------------------------------------------------------Number of entries: 1
===============================================================================

Advanced Configuration Guide

Page 1911

Configuration

SPB Multicast Trees (STs) are pruned for each particular I-VPLS ISID, based on the
advertisement of I-VPLS ISIDs in SPB IS-IS by each individual PE. Multicast B-VPLS traffic not
belonging to any particular I-VPLS follows the Default Tree. The Default Tree is an ST for the BVPLS which is not pruned and therefore reaches all the PE nodes in the B-VPLS. For instance,
Ethernet-CFM CCM messages sent from vMEPs configured on the SPB B-VPLS will use the
default tree. The default tree does not consume MFIB entries and can be checked in each node
through the use of the following command:
*A:PE-69# tools dump service id 10 spb default-multicast-list
saps : { }
spoke-sdps : { 95:10 }

As it can be noted above, PE-69 is not part of the tree for I-VPLS 11. However, as with any SPB
node part of B-VPLS 10, PE-69 is part of the default tree. Refer to Configuration of ISID-Policies
in SPB B-VPLS on page 1928 to see more use-cases for the Default Tree.
The following tools commands allow the operator to easily see the forwarding path (unicast and
multicast) followed by the traffic to a remote node, with the aggregate metric from the source.
*A:PE-63# tools dump service id 10 spb fid 10 forwarding-path destination PE-64 forwarding-tree unicast
Hop
0
1
2
3

BridgeId
PE-63
PE-65
PE-67
PE-64

Metric From Src


0
10
20
30

*A:PE-63# tools dump service id 10 spb fid 10 forwarding-path destination PE-64 forwarding-tree multicast
Hop
0
1
2
3

BridgeId
PE-63
PE-65
PE-67
PE-64

Metric From Src


0
10
20
30

In large networks or networks where IP multicast, PBB and PBB-SPB services coexist, the data
plane MFIB entries is a hardware resource that should be periodically checked. The tools dump
service vpls-mfib-stats shows the total number of hardware MFIB entries (40k entries, in chassismode d) and the entries being used by IP multicast or PBB (MMRP or SPB). The tools dump
service vpls-pbb-mfib-stats shows the breakdown between MFIB entries populated by MMRP or
by SPB and the individual limits, system-wide and per service:
*A:PE-65# tools dump service vpls-mfib-stats
Service Manager VPLS MFIB info at 004 09:44:57.010:
Statistics last cleared at 000 00:00:00.000
Statistic

Page 1912

Count

Advanced Configuration Guide

Shortest Path Bridging for MAC

---------------------------------+------------HW limit SG entries |


40959# total number of MFIB entries
Current SG entries |
2
Limit Non PBB SG entries |
16383# IP Multicast MFIB limit
Current Non PBB SG entries |
0
...
*A:PE-65# tools dump service vpls-pbb-mfib-stats detail
Service Manager VPLS PBB MFIB statistics at 004 09:45:13.860:
Usage per Service
ServiceId
MFIB User
Count
------------+--------------+------10
spb
1
30
spb
1
------------+--------------+------Total
2
MMRP
Current Usage
:
System Limit
:
Per Service Limit :

0
8191 Full, 40959 ESOnly
2048 Full, 8192 ESOnly

SPB
Current Usage
:
System Limit
:
Per Service Limit :

2
8191
8191

Finally the following debug commands can help monitor the SPB IS-IS process and the protocol
PDU exchanges:

debug service id <svcId> spb

debug service id <svcId> spb adajacency

debug service id <svcId> spb interface

debug service id <svcId> spb l2db

debug service id <svcId> spb lsdb

debug service id <svcId> spb packet <detail>

debug service id <svcId> spb spf

Advanced Configuration Guide

Page 1913

Configuration

Control and User B-VPLS Configuration


The SR OS implementation of SPB allows a single SPB IS-IS instance to control the paths and
FDBs of many B-VPLS instances. This is done by using the control B-VPLS, user B-VPLS and
fate-sharing concepts.
The control B-VPLS will be SPB-enabled and configured with all the related SPB IS-IS
parameters. Although the control B-VPLS might or might not have I-VPLS/Epipes directly
attached, it must be configured on all the nodes where SPB forwarding is expected to be active.
SPB uses the logical instance and a Forwarding ID (FID) to identify SPB locally on the node. That
FID must be consistently configured on all the nodes where the B-VPLS exists. User B-VPLS are
other instances of B-VPLS that are usually configured to separate the traffic for manageability
reasons, QoS or ECT different treatment.
Figure 195 illustrates the control B-VPLS (B-VPLS 20) and user B-VPLS (B-VPLS 21) concept
(in this case there is only one user B-VPLS but there might be many B-VPLS sharing fate with the
same control B-VPLS). Note that both B-VPLS must share the same topology and both B-VPLS
must share exactly the same interfaces. The user B-VPLS, which is linked to the control B-VPLS
by its FID, follows (that is, inherits the state of) the control B-VPLS but may use a different ECT
path in case of equal metric paths, like in this example: FID 20, that is, the control B-VPLS,
follows the low-path-id ECT, whereas FID 21, for example, the user B-VPLS, follows the highpath-id ECT.

PE-63
192.0.2.63

PE-65
192.0.2.65

PE-67
192.0.2.67

20

20

20

21

21

B-VPLS Instance

I-Instance

Control B-VPLS

21

211

9:211 1:211
CE-3211
Epipe 211

FID 20 SPF
FID 21 SPF

20

20
21

20

21

21
211

PE-66
192.0.2.66

PE-69
192.0.2.69

1:211 9:211
CE-4211
Epipe 211

PE-64
192.0.2.64

al_0276

Figure 195: Control and User B-VPLS Test Topology

Page 1914

Advanced Configuration Guide

Shortest Path Bridging for MAC

The configurations of B-VPLSs 20 and 21, on PE-63 and PE-65, are shown below. The spbmcontrol-vpls 20 fid 21 in B-VPLS 21 command associates FID 21 to the user B-VPLS and links
the B-VPLS to its control B-VPLS 20.
*A:PE-63>config>service# info
---------------------------------------------...
vpls 20 customer 1 b-vpls create
service-mtu 2000
stp
shutdown
exit
spb 1025 fid 20 create
level 1
ect-algorithm fid-range 21-4095 high-path-id
exit
no shutdown
exit
spoke-sdp 35:20 create
spb create
no shutdown
exit
no shutdown
exit
spoke-sdp 36:20 create
spb create
no shutdown
exit
no shutdown
exit
no shutdown
exit
vpls 21 customer 1 b-vpls create
service-mtu 2000
stp
shutdown
exit
spbm-control-vpls 20 fid 21
spoke-sdp 35:21 create
no shutdown
exit
spoke-sdp 36:21 create
no shutdown
exit
no shutdown
exit
epipe 211 customer 1 create
pbb
tunnel 21 backbone-dest-mac "PE-64" isid 211
exit
sap 1/1/1:211 create
exit
no shutdown
exit
...
*A:PE-65>config>service# info
----------------------------------------------

Advanced Configuration Guide

Page 1915

Configuration

...
vpls 20 customer 1 b-vpls create
service-mtu 2000
stp
shutdown
exit
spb 1025 fid 20 create
level 1
ect-algorithm fid-range 21-4095 high-path-id
exit
no shutdown
exit
spoke-sdp 53:20 create
spb create
no shutdown
exit
no shutdown
exit
spoke-sdp 56:20 create
spb create
no shutdown
exit
no shutdown
exit
spoke-sdp 57:20 create
spb create
no shutdown
exit
no shutdown
exit
spoke-sdp 59:20 create
spb create
no shutdown
exit
no shutdown
exit
no shutdown
exit
vpls 21 customer 1 b-vpls create
service-mtu 2000
stp
shutdown
exit
spbm-control-vpls 20 fid 21
spoke-sdp 53:21 create
no shutdown
exit
spoke-sdp 56:21 create
no shutdown
exit
spoke-sdp 57:21 create
no shutdown
exit
spoke-sdp 59:21 create
no shutdown
exit
no shutdown
exit

Page 1916

Advanced Configuration Guide

Shortest Path Bridging for MAC

If there is a mismatch between the topology of a user B-VPLS and its control B-VPLS, only the
user B-VPLS links and nodes that are in common with the control B-VPLS will function.
User B-VPLS instances supporting only unicast services (PBB-Epipes) may share the FID with
the other B-VPLS (control or user). This is a configuration shortcut that reduces the LSP
advertisement size for B-VPLS services but results in the same separation for forwarding between
the B-VPLS services. In the case of PBB-Epipes only BMACs are advertised per FID but BMACs
are populated per B-VPLS in the FIB. If I-VPLS services are to be supported on a B-VPLS that BVPLS must have an independent FID.
Note that although user B-VPLS 21 does not have any SPB setting (other than the spbm-controlvpls) the spoke-sdps use the same SDPs as the parent control B-VPLS 20. The show service id
<user b-vpls> spb fate-sharing command shows the control spoke-sdp/saps that control the user
spoke-sdp/saps.
*A:PE-63# show service id 21 spb fate-sharing
===============================================================================
User service fate-shared sap/sdp-bind information
===============================================================================
Control
Control Sap/
FID
User
User Sap/
SvcId
SdpBind
SvcId
SdpBind
------------------------------------------------------------------------------20
35:20
21
21
35:21
20
36:20
21
21
36:21
===============================================================================

Advanced Configuration Guide

Page 1917

Configuration

SPBM Access Resiliency Configuration


The following example shows how to configure an I-VPLS/Epipe attached to an SPB-enabled BVPLS when access resiliency is used.
In the tested SR OS release, multi-chassis LAG (MC-LAG) is the only resiliency mechanism
supported for PBB-Epipes. The MC-LAG active node will advertise the MC-LAG BMAC (or sapbmac) in SPB IS-IS. In case of failure, when the standby node takes over it will advertise the MCLAG sap-bmac. Note that without SPB, the MC-LAG solution for PBB-Epipe required the use of
mac-notification and periodic mac-notification. SPB provides a faster and more efficient solution
without the need for any extra mac-notification mechanism. In the example described in this
section, Epipe 31 uses MC-LAG access resiliency to get connected to the B-VPLS 30 on nodes
PE-65 and PE-66.
As far as I-VPLS access resiliency is concerned, the same mechanisms supported for regular BVPLS are supported for SPB-enabled B-VPLS, except for G.8032, which is not supported in the
tested SR OS release. A very important aspect of the I-VPLS resiliency is a proper mac-flush
propagation when there is a failure at the I-VPLS access links.
If the SPB-enabled B-VPLS uses B-SAPs for its connectivity to the backbone, there is no such a
mac-flush propagation (since there is no TLDP). In this case, if MC-LAG is used and there is an
MC-LAG switchover, the new active chassis will keep using the same source BMAC, such as the
sap-bmac, and it will advertise it in the B-VPLS domain so that the remote FDBs can be properly
updated. No mac-flush is required in this case.
When the B-VPLS uses spoke-sdps for its backbone connectivity, the traditional LDP MAC flush
propagation mechanisms and commands can be used as follows:

Page 1918

send-flush-on-failure works as expected when SPB is used at the B-VPLS. When


configured, a flush-all-from-me event is triggered upon a SAP or spoke-sdp failure in the
I-VPLS.

send-bvpls-flush works as expected when SPB is used at the B-VPLS. Two variants are
configurable: all-from-me/all-but-mine. Any I-VPLS SAP/spoke-sdp failure is propagated
to the I-VPLS on the peers to flush their respective customer MACs (CMACs). It works
only in conjunction with send-flush-on-failure configuration on I-VPLS. The associated
ISID list is passed along with the LDP mac-flush message, which is flushed/retained
according to the all-from-me/all-but-me flag.

send-flush-on-bvpls-failure works as expected when SPB is used at the B-VPLS. A local


B-VPLS failure is propagated to the I-VPLS, which then triggers a LDP mac-flush if it
has any spoke-sdp on it.

propagate-mac-flush-from-bvpls does no work when SPB is used at the B-VPLS (since


failures within the B-VPLS are handled by SPB) and its configuration is blocked.

Advanced Configuration Guide

Shortest Path Bridging for MAC

In the example described later in this section, I-VPLS 32 uses active/standby spoke-sdp resiliency
to get connected to the B-VPLS 30 on nodes PE-67 and PE-69.

CE-331

Epipe 31

9:31 1:31

PE-63
192.0.2.63

PE-65
192.0.2.65

31

CE-332

B-VPLS Instance

I-Instance

30

32

3:31

I-VPLS 32

9:32

30

31

32

Epipe 31

3:31

CE-431

I-VPLS 32

30
9:32 1:32

PE-67
192.0.2.67

1:31

MTU-64

4:31

MC-LAG
3:31

31

30

30

PE-66
192.0.2.66

PE-69
192.0.2.69

Epipe 31

32

Active/
Standby PW

I-VPLS 32

VPLS 32 1:32 9:32


CE-432
PE-64
192.0.2.64
al_0277

Figure 196: Access Resiliency Test Topology

As an example of MC-LAG connectivity, the Epipe 31 configuration is shown below. Just like for
regular PBB-VPLS, a sap-bmac is used as source BMAC for the Epipe traffic from PE-65/66 to
PE-63. A sap-bmac is a virtual BMAC formed from the configured source-bmac plus the MCLAG LACP-KEY (if configured this way) and owned by the MC-LAG active chassis. The
following CLI output shows the configuration of MC-LAG as well as the generation of the sapbmac. Once it is properly configured and the MC-LAG and Epipe are up and running, SPB IS-IS
will distribute the sap-bmac throughout the B-VPLS, as it does for the system BMACs and OAM
vMEP MACs. In this example, PE-65 is the MC-LAG active node, hence the sap-bmac for Epipe
31 is generated from PE-65.
*A:PE-65>config>redundancy# info
---------------------------------------------multi-chassis
peer 192.0.2.66 create
mc-lag
lag 1 lacp-key 1 system-id 00:00:00:00:65:66
system-priority 65535 source-bmac-lsb use-lacp-key
no shutdown
exit
no shutdown
exit
exit
---------------------------------------------*A:PE-65>config>service# info
---------------------------------------------pbb

Advanced Configuration Guide

Page 1919

Configuration

source-bmac 00:00:00:ca:fe:65
mac-name "PE-63" 00:00:00:ca:fe:63
mac-name "PE-64" 00:00:00:ca:fe:64
mac-name "PE-65" 00:00:00:ca:fe:65
mac-name "PE-66" 00:00:00:ca:fe:66
mac-name "PE-67" 00:00:00:ca:fe:67
mac-name "PE-69" 00:00:00:ca:fe:69
exit
...
vpls 30 customer 1 b-vpls create
service-mtu 2000
pbb
use-sap-bmac
exit
stp
shutdown
exit
spb 1026 fid 30 create
level 1
bridge-priority 0
exit
no shutdown
exit
spoke-sdp 53:30 create
spb create
no shutdown
exit
no shutdown
exit
spoke-sdp 56:30 create
spb create
no shutdown
exit
no shutdown
exit
spoke-sdp 57:30 create
spb create
no shutdown
exit
no shutdown
exit
spoke-sdp 59:30 create
spb create
no shutdown
exit
no shutdown
exit
no shutdown
exit
epipe 31 customer 1 create
pbb
tunnel 30 backbone-dest-mac "PE-63" isid 31
exit
sap lag-1:31 create
exit
no shutdown
exit
...

Page 1920

Advanced Configuration Guide

Shortest Path Bridging for MAC

*A:PE-66# show service id 30 spb fdb


==============================================================================
User service FDB information
==============================================================================
MAC Addr
UCast Source
State
MCast Source
State
-----------------------------------------------------------------------------00:00:00:ca:00:01 65:30
ok
65:30
ok
00:00:00:ca:fe:63 63:30
ok
65:30
ok
00:00:00:ca:fe:65 65:30
ok
65:30
ok
00:00:00:ca:fe:67 67:30
ok
65:30
ok
00:00:00:ca:fe:69 69:30
ok
65:30
ok
-----------------------------------------------------------------------------Entries found: 5
==============================================================================

The configuration for I-VPLS 32 on nodes PE-64 and PE-67 is shown below.
A:PE-64>config>service>vpls# info
---------------------------------------------stp
shutdown
exit
endpoint "CORE" create
no suppress-standby-signaling
exit
sap 1/1/1:32 create
exit
spoke-sdp 47:32 endpoint "CORE" create
stp
shutdown
exit
precedence primary
no shutdown
exit
spoke-sdp 49:32 endpoint "CORE" create
stp
shutdown
exit
no shutdown
exit
no shutdown
---------------------------------------------*A:PE-67>config>service# info
---------------------------------------------...
vpls 30 customer 1 b-vpls create
service-mtu 2000
stp
shutdown
exit
spb 1026 fid 30 create
no shutdown
exit
spoke-sdp 75:30 create
spb create
no shutdown
exit
no shutdown

Advanced Configuration Guide

Page 1921

Configuration

exit
spoke-sdp 76:30 create
spb create
no shutdown
exit
no shutdown
exit
spoke-sdp 79:30 create
spb create
no shutdown
exit
no shutdown
exit
no shutdown
exit
vpls 32 customer 1 i-vpls create
send-flush-on-failure
pbb
backbone-vpls 30
exit
send-bvpls-flush all-from-me
send-flush-on-bvpls-failure
exit
stp
shutdown
exit
spoke-sdp 74:32 create
no shutdown
exit
no shutdown
exit

As discussed, send-flush-on-failure and send-bvpls-flush all-from-me are configured in the IVPLS. When the active spoke-sdp goes down on PE-67, a flush-all-from-me message will be
propagated through the backbone and will flush the corresponding CMACs associated to the IVPLS 32 in node PE-63. MAC flush-all-from-me messages are automatically propagated in the
core up to the remote I-VPLS 32 on node PE-63 (there is no need for any propagate-mac-flush in
the intermediate nodes). Note that the send-flush-on-bvpls-failure command works as expected.
The command propagate-mac-flush-from-bvpls is never used when the B-VPLS is SPB-enabled
(the command is not allowed).

Page 1922

Advanced Configuration Guide

Shortest Path Bridging for MAC

Static BMACs and Static ISIDs Configuration


From 11.0R4 onwards, SR OS supports the interworking between SPB-enabled B-VPLS and nonSPB B-VPLS instances. With the addition of this feature, SPB networks can be connected to nonSPB capable nodes, for example third party vendor PBB switches or 7210 SAS nodes. This is
possible through the use of conditional static BMACs and static ISIDs on the nodes doing the
interworking function. Conditional static BMACs and static ISIDs can be associated to non-SPB
B-VPLS SAPs or spoke-sdps.
The following example shows an SPB-enabled B-VPLS (40) on nodes PE-65, PE-66, PE-67 and
PE-69. Node PE-63 supports PBB, but not SPB and it is connected by a MC-LAG to nodes PE-67
and PE-69. Services I-VPLS 41 and Epipe 42 have end-points on node PE-63. In this example,
nodes PE-67 and PE-69 are acting as interworking nodes. They will be configured with the
BMAC of PE-63 so that the MC-LAG active node advertises the non-SPB capable node BMAC
into SPB IS-IS. The BMAC will be configured as a conditional static BMAC so that a given SPB
node, such as PE-67 or 69, will only advertise PE-63s BMAC if its connection to PE-63 is active.
Besides the conditional static BMAC, nodes PE-67/69 should advertise the I-VPLS ISIDs defined
in PE-63. Note that Epipe ISIDs are not advertised in SPB IS-IS, therefore it is not necessary to
create a static ISID for Epipe 42.

CE-541

PE-65
192.0.2.65

I-VPLS 41

9:41 1:41

41

9:42 1:42

40

42

2:40
MC-LAG

41

41

40

40

PE-66
192.0.2.66

PE-69
192.0.2.69

CE-341

1:41 9:41

40
42

6:40

Epipe 42

9:41 1:41

CE-641

I-VPLS 41

5:40

40
CE-542

PE-64
192.0.2.64

PE-67
192.0.2.67

1:42 9:42

Epipe 42

CE-342

B-VPLS Instance

I-Instance

2:40

I-VPLS 41

al_0278

Figure 197: Access Resiliency Test Topology

The commands to configure conditional static BMACs and static ISIDs are shown below.
*A:PE-67# configure service vpls 40 static-mac mac ?
- mac <ieee-address> [create] sap <sap-id> [monitor {fwd-status}]
- no mac <ieee-address>
- mac <ieee-address> [create] spoke-sdp <sdp-id:vc-id> [monitor {fwd-status}]

Advanced Configuration Guide

Page 1923

Configuration

*A:PE-67# configure service vpls 40 sap lag-1:40 static-isid range


- no range <range-id>
- range <range-id> isid <isid-value> [to <isid-value>] [create]
<range-id>
<isid-value>
<create>

: [1..8191]
: [1..16777215]
: keyword

Note that the monitor fwd-status attribute identifies this to be a conditional MAC and is
mandatory for static BMACs. This parameter instructs the 7x50 to advertise the BMAC only if the
corresponding SAP/spoke-sdp is in forwarding state.
The configuration of the conditional static BMAC and static ISID is shown below.
*A:PE-67>config>service # info
---------------------------------------------...
vpls 40 customer 1 b-vpls create
service-mtu 2000
stp
shutdown
exit
spb 1027 fid 40 create
spf-wait 10 10 1000
no shutdown
exit
sap lag-1:40 create
static-isid
range 1 create isid 41
exit
exit
spoke-sdp 75:40 create
spb create
no shutdown
exit
no shutdown
exit
spoke-sdp 76:40 create
spb create
no shutdown
exit
no shutdown
exit
spoke-sdp 79:40 create
spb create
no shutdown
exit
no shutdown
exit
static-mac
mac 00:00:00:ca:fe:63 create sap lag-1:40 monitor fwd-status
exit
no shutdown
exit
---------------------------------------------*A:PE-69>config>service# info
...

Page 1924

Advanced Configuration Guide

Shortest Path Bridging for MAC

vpls 40 customer 1 b-vpls create


service-mtu 2000
stp
shutdown
exit
spb 1027 fid 40 create
spf-wait 10 10 1000
no shutdown
exit
sap lag-1:40 create
static-isid
range 1 create isid 41
exit
exit
spoke-sdp 95:40 create
spb create
no shutdown
exit
no shutdown
exit
spoke-sdp 96:40 create
spb create
no shutdown
exit
no shutdown
exit
spoke-sdp 97:40 create
spb create
no shutdown
exit
no shutdown
exit
static-mac
mac 00:00:00:ca:fe:63 create sap lag-1:40 monitor fwd-status
exit
no shutdown
exit
----------------------------------------------

Bear in mind that the configuration of the conditional static BMAC is different from the legacy
static-mac command, configured within the sap/sdp-binding context. The latter static-mac is not
conditional and it is always added to the FDB. The conditional static BMAC is added to the FDB
based on the SAP/sdp-binding state (note that the conditional static BMAC is tagged in the FDB
as CStatic, for Conditional Static).
*A:PE-67# show lag 1
===============================================================================
Lag Data
===============================================================================
Lag-id
Adm
Opr
Port-Threshold
Up-Link-Count
MC Act/Stdby
------------------------------------------------------------------------------1
up
up
0
1
active
===============================================================================

*A:PE-67# show service id 40 fdb pbb

Advanced Configuration Guide

Page 1925

Configuration

=======================================================================
Forwarding Database, b-Vpls Service 40
=======================================================================
MAC
Source-Identifier
iVplsMACs Epipes
Type/Age
----------------------------------------------------------------------00:00:00:ca:fe:63 sap:lag-1:40
0
0
CStatic
00:00:00:ca:fe:65 sdp:75:40
0
0
Spb
00:00:00:ca:fe:66 sdp:76:40
0
0
Spb
00:00:00:ca:fe:69 sdp:79:40
0
0
Spb
=======================================================================

*A:PE-69# show lag 1


===============================================================================
Lag Data
===============================================================================
Lag-id
Adm
Opr
Port-Threshold
Up-Link-Count
MC Act/Stdby
------------------------------------------------------------------------------1
up
down
0
0
standby
===============================================================================

*A:PE-69# show service id 40 fdb pbb


=======================================================================
Forwarding Database, b-Vpls Service 40
=======================================================================
MAC
Source-Identifier
iVplsMACs Epipes
Type/Age
----------------------------------------------------------------------00:00:00:ca:fe:63 sdp:97:40
0
0
Spb
00:00:00:ca:fe:65 sdp:95:40
0
0
Spb
00:00:00:ca:fe:66 sdp:96:40
0
0
Spb
00:00:00:ca:fe:67 sdp:97:40
0
0
Spb
=======================================================================

The static-isid command identifies a set of ISIDs for I-VPLS services that are external to SPBM.
These ISIDs are advertised as supported locally on this node unless altered by an isid-policy.
Although the example above shows the use of the static-isid associated to a MC-LAG SAP,
regular SAPs or spoke SDPs are also supported. ISIDs declared in this way become part of the
ISID multicast and consume MFIBs. Multiple SPBM static-isid ranges are allowed under a SAP/
spoke SDP. ISIDs are advertised as if they were attached to the local BMAC. Only remote I-VPLS
ISIDs need to be defined. In the MFIB, the backbone group MACs are then associated with the
active SAP or spoke SDP.
Once the conditional static BMAC for PE-63 and the static-isid 41 (for I-VPLS 41) are configured
as discussed, the advertised BMAC and ISID can be checked in the remote SPB nodes:
*A:PE-66# show service id 40 spb fdb
==============================================================================
User service FDB information
==============================================================================
MAC Addr
UCast Source
State
MCast Source
State
-----------------------------------------------------------------------------00:00:00:ca:fe:63 67:40
ok
65:40
ok
00:00:00:ca:fe:65 65:40
ok
65:40
ok
00:00:00:ca:fe:67 67:40
ok
65:40
ok

Page 1926

Advanced Configuration Guide

Shortest Path Bridging for MAC

00:00:00:ca:fe:69 69:40
ok
65:40
ok
-----------------------------------------------------------------------------Entries found: 4
==============================================================================

*A:PE-66# show service id 40 spb mfib


===============================================================================
User service MFIB information
===============================================================================
MAC Addr
ISID
Status
------------------------------------------------------------------------------01:1E:83:00:00:29 41
Ok
------------------------------------------------------------------------------Entries found: 1
===============================================================================

*A:PE-66# show service id 40 mfib


===============================================================================
Multicast FIB, Service 40
===============================================================================
Source Address Group Address
Sap/Sdp Id
Svc Id
Fwd/Blk
------------------------------------------------------------------------------*
01:1E:83:00:00:29
b-sdp:65:40
Local
Fwd
------------------------------------------------------------------------------Number of entries: 1
===============================================================================

Note that the group address terminates in hex 29, which corresponds to ISID 41.
The configured static-isids can be displayed with the following command (a range 41-100 has
been added to the sap lag-1:40 to demonstrate this output):
*A:PE-69># show service id 40 sap lag-1:40 static-isids
===================================
Static Isid Entries
===================================
Entry
Range
----------------------------------1
41-100
===================================

Advanced Configuration Guide

Page 1927

Configuration

Configuration of ISID-Policies in SPB B-VPLS


ISID policies are an optional aspect of SPBM which allow additional control of the advertisement
of ISIDs and creation of MFIB entries for I-VPLS (Epipe services do not trigger ISID
advertisements or the creation of MFIB entries). By default, if no ISID-policies are used, SPBM
automatically advertises and populates MFIB entries for I-VPLS and static-isids. ISID-policies
can be used on any SPB-enabled node with locally defined I-VPLS instances or static-isids. The
isid-policy parameters are shown below:
*A:PE-67>config>service>vpls# isid-policy entry ?
- entry <range-entry-id> [create]
- no entry <range-entry-id>
<range-entry-id>
<create>

: [1..8191]
: keyword

[no] advertise-local - Configure local advertisement of the range


[no] range
- Configure ISID range for the entry
[no] use-def-mcast
- Use default multicast tree to propogate ISID range

Where:

advertise-local defines whether the local ISIDs (I-VPLS ISIDs linked to the B-VPLS) or
static ISIDs contained in the configured range are advertised in SPBM.

use-def-mcast controls whether the ISIDs contained in the range use MFIB entries (if no
use-def-mcast is used) or just the default tree which does not use any MFIB entry.

The isid-policy becomes active as soon as it is defined, as opposed to other policies in SR OS,
which require the policy itself to be applied within the configuration.
The typical use of ISID-policies is to reduce the number of ISIDs being advertised and/or to save
MFIB space (in deployments where MFIB space is shared with MMRP and IP Multicast). The use
of ISID-policies is recommended for I-VPLS where most of the traffic is unicast or for I-VPLS
where the ISID end-points are present in all the Backbone Edge Bridges (BEBs) of the SPB
network. In both cases, advertising ISIDs or consuming MFIB entries for those I-VPLSs has little
value since no multicast (first case) or the default tree (second case) are as efficient as using MFIB
entries.
The following configuration example will use the test topology in Figure 197. In this case, the
objective of the isid-policy will be to use the default tree for all the I-VPLS services with ISIDs
between 41 and 100, excluding the range 80-90. The following example shows the policy
configuration in PE-67. Note that the same policy will be configured in the rest of the SPB nodes,
that is, PE-65, PE-66 and PE-69.

Page 1928

Advanced Configuration Guide

Shortest Path Bridging for MAC

*A:PE-67>config>service# vpls 40
*A:PE-67>config>service>vpls# info
---------------------------------------------service-mtu 2000
stp
shutdown
exit
spb 1027 fid 40 create
spf-wait 10 10 1000
no shutdown
exit
isid-policy
entry 10 create
range 80 to 90
exit
entry 20 create
use-def-mcast
no advertise-local
range 41 to 79
exit
entry 30 create
use-def-mcast
no advertise-local
range 91 to 100
exit
exit
sap lag-1:40 create
static-isid
range 1 create isid 41 to 100
exit
exit
spoke-sdp 75:40 create
spb create
no shutdown
exit
no shutdown
exit
spoke-sdp 76:40 create
spb create
no shutdown
exit
no shutdown
exit
spoke-sdp 79:40 create
spb create
no shutdown
exit
no shutdown
exit
static-mac
mac 00:00:00:ca:fe:63 create sap lag-1:40 monitor fwd-status
exit
no shutdown
----------------------------------------------

Advanced Configuration Guide

Page 1929

Configuration

Note that the no advertise-local option can only be configured if the use-def-mcast option is also
configured.
*A:PE-67>config>service>vpls>isid-policy>entry# no advertise-local
MINOR: SVCMGR #7855 Cannot set AdvLocal for entry - advertise-local or use-def-mcast
option must be specified

Overlapping ISID values can be configured as long as the actions are consistent for the same ISID.
Conflicting actions are shown in the CLI.
*A:PE-67>config>service>vpls>isid-policy>entry# use-def-mcast
MINOR: SVCMGR #7854 Cannot set UseDefMctree for entry - Conflicting Actions with Entry-20

The isid-policy configured for B-VPLS 40 in all the four nodes makes the SPB network to use the
default tree for ISIDs 41-79 and 91-100 and not advertise those ISIDs in SPB IS-IS even if the
ISID is locally defined (as in the case for ISIDs 41-100 in PE-67). As discussed in Basic SPBM
Configuration on page 1903, the default tree path can be checked from each node by using the
tools dump service id 40 spb default-multicast-list command.
Due to entry 10 in the policy, ISIDs 80-90 will be advertised by PE-67 (active MC-LAG node).
However, nodes PE-65 and PE-66 will not create any MFIB entry for those ISIDs until the
corresponding I-VPLS ISIDs are locally created (or configured through static-isids). The
following command executed on PE-65 proves that ISIDs 80-90 are indeed being advertised by
PE-67:
*A:PE-65# show service id 40 spb database detail
===============================================================================
ISIS Database
===============================================================================
Displaying Level 1 database
------------------------------------------------------------------------------LSP ID
: PE-65.00-00
Level
: L1
...
------------------------------------------------------------------------------LSP ID
: PE-66.00-00
Level
: L1
...
------------------------------------------------------------------------------LSP ID
: PE-67.00-00
Level
: L1

MT Capability :
TLV Len
: 56
MT ID
: 0
SPBM Service ID:
Sub TLV Len
: 52
BMac Addr
: 00:00:00:ca:fe:67
Base VID
: 40
ISIDs
:
80
Flags:TR
81
Flags:TR
82
Flags:TR

Page 1930

Advanced Configuration Guide

Shortest Path Bridging for MAC

83
84
85
86
87
88
89
90

Flags:TR
Flags:TR
Flags:TR
Flags:TR
Flags:TR
Flags:TR
Flags:TR
Flags:TR

...
------------------------------------------------------------------------------LSP ID
: PE-69.00-00
Level
: L1
...
Level (1) LSP Count : 4
===============================================================================

The mfib parameter in the show service id 40 sap static-isids mfib command can help
understand the state of the MFIB entries added (or not) by the configured static-isid. The
following possible states can be shown:

If the static-isid is configured and programmed in the mfib the status is shown as:
ok

If the static-isid is not configured and not programmed in the mfib, the reasons can be
(order of priority):
useDefMCTree - isid policy is applied on the service for the isid.
sysMFibLimit - system mfib limit has been exceeded
addPending - adding pending due to processing delays

If the static-isid is not configured but present in the mfib:


delPending - cleanup pending due to processing delays.

The following examples show some of these possible states:


*A:PE-69# show service id 40 sap lag-1:40 static-isids mfib
===================================
ISID Detail
===================================
ISID
Status
----------------------------------<<snip>>
80
ok
81
ok
<<snip>>
41
useDefMCTree
42
useDefMCTree
<<snip>>
8292
sysMFibLimit
8293
sysMFibLimit
<<snip>>
9253
addPending
9254
addPending
<<snip>>

Advanced Configuration Guide

Page 1931

Configuration

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

Page 1932

Advanced Configuration Guide

Shortest Path Bridging for MAC

Conclusion
SR OS supports an efficient SPBM implementation in the context of a B-VPLS, where system
BMACs, vMEP OAM BMACs and SAP-BMACs are advertised in SPB IS-IS. SPBM provides a
simple solution where no other control plane protocol is required in the B-VPLS to take care of the
resiliency, load-balancing and multicast optimization. The SPBM implementation in the SR OS
provides scale optimization through the use of control and user B-VPLSs, allows the interworking
between SPB networks and PBB networks, as well as the optimization of the MFIB resources and
advertisement of ISIDs through the use of ISID-policies.

Advanced Configuration Guide

Page 1933

Conclusion

Page 1934

Advanced Configuration Guide

Spoke Termination for IPv6-6VPE

In This Chapter
This section provides information about spoke termination for IPv6-6VPE.
Topics in this section include:

Applicability on page 1936

Overview on page 1937

Configuration on page 1940

Conclusion on page 1965

Advanced Configuration Guide

Page 1935

Applicability

Applicability
Spoke termination for IPv6 is applicable to all of the 7750 SR family, plus 7450 ESS in mixedmode. Chassis modes B (with mixed mode enabled), C or D need to be enabled to support IPv6
and VPNv6 address families. Spoke termination for IPv6 is supported for both IES and 6VPE
services and has been tested for this note on 6VPE on 7750 SR-OS R9.0.

Page 1936

Advanced Configuration Guide

Spoke Termination for IPv6-6VPE

Overview
RFC 4659, BGP-MPLS IP Virtual Private Network (VPN) Extension for IPv6 VPN, standardized
the use of an IPv6 over IPv4 tunneling scheme. The 7750 SR supports the standardized IPv6 over
IPv4 tunneling scheme for VPRN services using Multi-Protocol Border Gateway Protocol (MPBGP), also known as 6VPE. The 7750 SR also supports pseudowire termination by a VPRN from
an Epipe Virtual Leased Line (VLL) or VPLS spoke SDP where the pseudowire can be given IPv6
addresses and run IPV6 protocols. In the example used in this section, any advertisements across
the Multi-Protocol Labeled Service (MPLS) network between Virtual Private Routed Network
(VPRN) Provider Edge (PE) devices will use 6VPE. The goal of this section is to list
configuration guidelines for IPv6 spoke termination to a VPRN over an Epipe VLL and
transporting IPv6 packets over 6VPE tunnels between PE devices.
This solution is to be used where a service provider is providing VPRN services built on a
transport network whose Interior Gateway Protocol (IGP) is using IPv4 addressing on the network
interfaces. The customers CE and the service providers PE must support IPv6 pseudowires, IPv6
interfaces and in addition, the service provider also be able to support the advertisements of IPv6
prefixes between CE-PE peerings and between the transport PE routers using MP-BGP. The
advertisement of IPv6 prefixes across the MPLS network and the transport of IPv6 traffic is
tunneled using 6VPE.
The VPRN PE has the ability to support spoke termination of Epipe VLL services on access with
IPv6 addressing between the CE and VPRN PE. The functions of IPv6 spoke termination on
VPRN services have the same functionality as VPRN IPv4 spoke termination prior to R8.0.
The example in Figure 198 illustrates a CE device that connects to a VPRN PE on an IPv6
interface addressing using spoke termination.

Advanced Configuration Guide

Page 1937

Overview

IPv6
Spoke-SDP
IPv6
Interfaces

IPv6
Interfaces

IP-VPN

IP/MPLS

6VPE

VLL
EPIPE
CE-1

VPRN

PE-1

VPRN

PE-2

CE-2

PE-3

OSSG591

Figure 198: Spoke Termination for IPv6

CE-1 is connected to the VPRN service on PE-2, using IPv6 interfaces. CE-1 reaches PE-2 by
connecting to PE-1. PE-1 uses an Epipe VLL for transport to the VPRN on the PE-2. The
connectivity between PE-1s VLL service and PE-2s VPRN service is using spoke termination
with IPv6 addressing on the PE-2s spoke-service distribution point (spoke SDP) interface.
SAP
Network Advertised
2001:DB8:3000::/64

Network Advertised
2001:DB8:4000::/64

Spoke-SDP

IP-VPN

IP/MPLS
AS-64500

6VPE
AS-64500

VLL
EPIPE

VPRN

VPRN

AS-65500
CE-1

PE-1

PE-2

Address
2001:DB8:1000::1/64
Address
2001:DB8:1000::2/64

MP-eBGP

CE-2

PE-3
Address
2001:DB8:2000::1/64

MP-iBGP

Address
2001:DB8:2000::2/64

MP-eBGP
OSSG592

Figure 199: IPv6 Addressing and IPv6 Prefixes

Figure 199 shows the overall IPv6 addressing from interfaces to prefixes advertised from CE-1
and CE-2 across the VPRN network.

Page 1938

Link between CE-1 and PE-2: 2001:DB8:1000::/64

Link between CE-2 and PE-3: 2001:DB8:2000::/64

Advertised Prefix from CE-1: 2001:DB8:3000::/64

Advertised Prefix from CE-2: 2001:DB8:4000::/64

Advanced Configuration Guide

Spoke Termination for IPv6-6VPE

PE-2 has an MP-eBGP session with CE-1 to receive and advertise IPv6 routes. PE-2 also has an
MP-iBGP peering session with PE-3 to use 6VPE to tunnel IPv6 routes and traffic to and from PE3. PE-3 has an IPv6 SAP interface to CE-2 and uses MP-eBGP to advertise and receive routes to/
from CE-2 (no spoke-termination). PE-3s configuration will also be included to provide examples
of the end-to-end VPRN service using a 6VPE model.
This network topology will illustrate the use of spoke termination using IPv6 interfaces and the
tunneling of IPv6 traffic over 6VPE MPLS network.

Advanced Configuration Guide

Page 1939

Configuration

Configuration
First is to configure and establish an MPLS network where the VPRN service can use 6VPE to
tunnel traffic across the IPv4 IGP.

SAP
Spoke-SDP

PE-1

Address
2001:DB8:1000::2/64

IP/MPLS

CE-1
EPIPE
192.0.2.1

PE-2

VPRN

192.0.2.2

192.0.2.3
OSSG594

Address
2001:DB8:1000::1/64

Figure 200: MP-BGP VPNv6

PE-2 and PE-3 in Figure 200 are edge routers running VPRN Services on access with IPv6
Interfaces. The MPLS network is configured using IPv4 link addressing. Interior Border Gateway
Protocol (iBGP) peerings need to be established with MP-BGP for VPN-IPv6 address families
between PE-2 and PE-3.
A:PE-2>config>router>bgp# info
hold-time 10
router-id 192.0.2.3
group iBGP_AS65500
description iBGP_peerings_AS65500
family vpn-ipv6
peer-as 65500
local-address 192.0.2.3
neighbor 192.0.2.4
description PE-3
exit
exit

A:PE-3>config>router>bgp# info
hold-time 10
router-id 192.0.2.4
group iBGP_AS65500
description iBGP_peerings_AS65500
family vpn-ipv6
peer-as 65500

Page 1940

Advanced Configuration Guide

Spoke Termination for IPv6-6VPE

local-address 192.0.2.4
neighbor 192.0.2.3
description PE-2
exit
exit

Configuring family vpn-ipv6 between VPRN PE edge routers in BGP turns on the functionality of
MP-BGP for the Layer 3 VPNs supporting the customers IPv6 Addressing (6VPE).
Verify BGP sessions for VPN-IPv6 address families between the PE-2 and PE-3.
A:PE-2# show router bgp neighbor 192.0.2.4
BGP Neighbor
Peer : 192.0.2.4
Group : iBGP_AS65500
Peer AS
Peer Address
Local AS
Local Address
Peer Type
State
Last Event
Last Error
Local Family
Remote Family

:
:
:
:
:
:
:
:
:
:

65500
192.0.2.4
65500
192.0.2.3
Internal
Established
recvKeepAlive
Cease
VPN-Ipv6
VPN-Ipv6

Peer Port

: 49521

Local Port

: 179

Last State

: Established

A:PE-3# show router bgp neighbor 192.0.2.3


BGP Neighbor
Peer : 192.0.2.3
Group : iBGP_AS65500
Peer AS
Peer Address
Local AS
Local Address
Peer Type
State
Last Event
Last Error
Local Family
Remote Family

:
:
:
:
:
:
:
:
:
:

Advanced Configuration Guide

65500
192.0.2.3
65500
192.0.2.4
Internal
Established
recvKeepAlive
Cease
VPN-Ipv6
VPN-Ipv6

Peer Port

: 179

Local Port

: 49521

Last State

: Active

Page 1941

Configuration

Now that you have established MP-BGP sessions for VPN-IPv6 address-family, 6VPE tunnel
support is provided between PE-2 and PE-3.

SAP
Spoke-SDP

PE-1

PE-2

EPIPE
192.0.2.1

Address
2001:DB8:1000::2/64

IP/MPLS

CE-1

192.0.2.2

VPRN
192.0.2.3
OSSG594

Address
2001:DB8:1000::1/64

Figure 201: Spoke Termination for IPv6 Addressing

Figure 201 illustrates the model for spoke termination for IPv6 using VPRN services. CE-1 is
configured with IPv6 addressing on the access interface facing the VPRN service. CE-1s access is
backhauled to the VPRN service on PE-2 using Epipe VLL with spoke termination. Only Epipe
VLL is supported for IPv6 spoke termination within the VPRN in R8.0. The configuration of the
Epipe VLL on PE-1 is shown below:
A:PE-1>config>service# info
customer 1 create
description Default customer
exit
sdp 40 mpls create
far-end 192.0.2.3
ldp
keep-alive
shutdown
exit
no shutdown
exit
epipe 1 customer 1 create
sap 1/1/4 create
exit
spoke-sdp 40:1 create
exit
no shutdown
exit

The example above is taken from PE-1 which has been configured using the Epipe VLL service
with a SAP interface facing the customer and a spoke SDP facing PE-2. The spoke SDP is
terminated into the customers VPRN service on PE-2.

Page 1942

Advanced Configuration Guide

Spoke Termination for IPv6-6VPE

PE-2 is now ready to be configured for the IPv6 spoke SDP. Review the possible IPv6 options for
spoke SDP interfaces on the CLI for VPRN Services (compliant to RFC 4213, Basic Transition
Mechanisms for IPv6 Hosts and Routers <draft-ietf-v6ops-mech-v2-07.txt> ):

Interface spoke SDP (IPv6 options only)

A:PE-2>config>service>vprn$ interface <interface> create


A:PE-2>config>service>vprn>if$
[no] ipv6
+ Enables/Configures IPv6 for a VPRN interface
A:PE-2>config>service>vprn>if$ ipv6
[no] address
[no] dhcp6-relay
[no] dhcp6-server
icmp6
[no] link-local-address
[no] local-proxy-nd
[no] neighbor
[no] proxy-nd-policy
[no] vrrp

IPv6 address

A:PE-2>config>service>vprn>if>ipv6# address
- address <ipv6-address/prefix-length> [eui-64] [preferred]
- no address <ipv6-address/prefix-length>
<ipv6-address/pref*> : ipv6-address

<eui-64>
<preferred>

x:x:x:x:x:x:x:x (eight 16-bit pieces)


x:x:x:x:x:x:d.d.d.d
x [0..FFFF]H
d [0..255]D
prefix-length [1..128]
: keyword
: keyword

DHCPv6 relay parameters for the VPRN service

A:PE-2>config>service>vprn>if>ipv6>dhcp6-relay# info detail


shutdown
no description
no lease-populate
no neighbor-resolution
option
no interface-id
no remote-id
exit
no source-address
no server

DHCPv6 server parameters for the VPRN service

A:PE-2>config>service>vprn>if>ipv6>dhcp6-server# info detail


prefix-delegation
shutdown
exit
max-nbr-of-leases 8000

Advanced Configuration Guide

Page 1943

Configuration

ICMPv6

A:PE-2>config>service>vprn>if>ipv6>icmp6# info detail


packet-too-big 100 10
param-problem 100 10
redirects 100 10
time-exceeded 100 10
unreachables 100 10

Link-local-addressing, for the VPRN interface. Link-local addressing by default is


assigned dynamically. Use this command if you would like to add a static link-localaddress.

A:PE-2>config>service>vprn>if>ipv6# link-local-address
- link-local-address <ipv6-address> [preferred]
- no link-local-address
<ipv6-address>

: ipv6-address

<preferred>

: keyword

- x:x:x:x:x:x:x:x
x:x:x:x:x:x:d.d.d.d
x [0..FFFF]H
d [0..255]D

Neighbor

* IPv6 to MAC address mapping on the VRPN Interface


A:PE-2>config>service>vprn>if>ipv6# neighbor
- neighbor <ipv6-address> <mac-address>
- no neighbor <ipv6-address>
<ipv6-address>

<mac-address>

: x:x:x:x:x:x:x:x
(eight 16-bit pieces)
x:x:x:x:x:x:d.d.d.d
x [0..FFFF]H
d [0..255]D
prefix-length [1..128]
: xx:xx:xx:xx:xx:xx or xx-xx-xx-xx-xx-xx

Enabling Local Proxy Neighbor Discovery

A:PE-2>config>service>vprn>if>ipv6# local-proxy-nd
- local-proxy-nd
- no local-proxy-nd

VRRP

A:PE-2>config>service>vprn>if>ipv6# vrrp <virtual-router-id> [owner]


priority 100
no policy
preempt
master-int-inherit
no ping-reply
no telnet-reply
no traceroute-reply
no standby-forwarding
no mac
no init-delay

Page 1944

Advanced Configuration Guide

Spoke Termination for IPv6-6VPE

message-interval 1
no shutdown

PE-2 configuration for the VPRN service with IPv6 interface (spoke SDP) in reference to
Figure 201:
*A:PE-2>config>service>vprn# info
router-id 192.0.2.6
autonomous-system 65500
route-distinguisher 65500:1
auto-bind ldp
vrf-target target:65500:1
interface loopback create
address 192.0.2.6/32
loopback
exit
interface Spoke_to_PE-1 create
ipv6
address 2001:DB8:1000::2/64
exit
spoke-sdp 40:1 create
exit
exit
bgp
router-id 192.0.2.6
group CE-1-PE-2-spoke
family ipv6
local-as 65500
peer-as 64500
local-address 2001:DB8:1000::2
neighbor 2001:DB8:1000::1
as-override
type external
export PE-2-BGP-CE-1
exit
exit
exit
no shutdown
*A:PE-2>config>router>policy-options# info
policy-options
begin
prefix-list "PE-2-CE-1"
prefix 2001:DB8:4000::/64 exact
exit
policy-statement "PE-2-BGP-CE-1"
entry 10
from
prefix-list "PE-2-CE-1"
exit
action accept
exit
exit
exit
commit
exit

Advanced Configuration Guide

Page 1945

Configuration

In the prior configuration example, PE-2 has been configured with an IPv6 spoke SDP (spoke
termination) with interface spoke_to_PE-1. The VPRN configuration has also been set up for MPeBGP peering to CE-1 through the IPv6 spoke interface. The MP-eBGP peering will be receiving
and advertising IPv6 prefixes from/to CE-1. Route policy configuration has been included to show
how IPv6 routes are advertised to CE-1 from PE-2 (policy-statement PE-2-BGP-CE-1).
On PE-1, verification that the Epipe VLL is established with the SAP facing CE-1 and spoke SDP
facing VPRN on PE-2 can be seen as follows:
A:PE-1# show service id 1 all
Service Detailed Information
Service Id
:
Service Type
:
Name
:
Description
:
Customer Id
:
Last Status Change:
Last Mgmt Change :
Admin State
:
MTU
:
Vc Switching
:
SAP Count
:
Per Svc Hashing
:
Force Qtag Fwd
:

1
Vpn Id
Epipe
(Not Specified)
(Not Specified)
1
05/17/2010 21:45:56
05/17/2010 21:38:10
Up
Oper State
1514
False
1
SDP Bind Count
Disabled
Disabled

: 0

: Up

: 1

Service Destination Points(SDPs)


Sdp Id 40:1
Description
SDP Id
Spoke Descr
VC Type
Admin Path MTU
Far End
Hash Label

-(192.0.2.3)
: (Not Specified)
: 40:1
: (Not Specified)
: Ether
: 1514
: 192.0.2.3
: Disabled

Admin State
:
Acct. Pol
:
Ingress Label
:
Ingr Mac Fltr-Id
:
Ingr IP Fltr-Id
:
Ingr Ipv6 Fltr-Id :
Admin ControlWord :
Admin BW(Kbps)
:
Last Status Change :
Last Mgmt Change
:
Endpoint
:
Class Fwding State :
Flags
:
Peer Pw Bits
:
Peer Fault Ip
:
Peer Vccv CV Bits :
Peer Vccv CC Bits :
Application Profile:

Page 1946

Up
None
131069
n/a
n/a
n/a
Not Preferred
0
05/17/2010 21:45:56
05/17/2010 21:38:10
N/A
Down
None
None
None
lspPing
mplsRouterAlertLabel
None

Type

: Spoke

VC Tag
Oper Path MTU
Delivery

: n/a
: 1514
: LDP

Oper State
Collect Stats
Egress Label
Egr Mac Fltr-Id
Egr IP Fltr-Id
Egr Ipv6 Fltr-Id
Oper ControlWord
Oper BW(Kbps)
Signaling
Force Vlan-Vc
Precedence

:
:
:
:
:
:
:
:
:
:
:

Up
Disabled
131069
n/a
n/a
n/a
False
0
TLDP
Disabled
4

Advanced Configuration Guide

Spoke Termination for IPv6-6VPE

KeepAlive Information :
Admin State
: Disabled
Hello Time
: 10
Max Drop Count
: 3
Statistics
I. Fwd. Pkts.
I. Fwd. Octs.
E. Fwd. Pkts.
.
...
.
SAP 1/1/4

:
: 231915
: 21994828
: 231914

Service Id
:
SAP
:
Description
:
Admin State
:
Flags
:
Multi Svc Site
:
Last Status Change :
Last Mgmt Change
:
Sub Type
:
Dot1Q Ethertype
:
Split Horizon Group:

1
1/1/4
(Not Specified)
Up
None
None
05/17/2010 21:37:57
05/17/2010 21:07:20
regular
0x8100
(Not Specified)

LLF Admin State


Admin MTU
Ingr IP Fltr-Id
Ingr Mac Fltr-Id
Ingr Ipv6 Fltr-Id
tod-suite
Ing Agg Rate Limit
Endpoint
Q Frame-Based Acct
Vlan-translation

Down
9212
n/a
n/a
n/a
None
max
N/A
Disabled
None

:
:
:
:
:
:
:
:
:
:

Acct. Pol
: None
Application Profile: None

Oper State
Hello Msg Len
Hold Down Time

: Disabled
: 0
: 10

I. Dro. Pkts.
I. Dro. Octs.
E. Fwd. Octets

: 0
: 0
: 21992191

Encap

: null

Oper State

: Up

QinQ Ethertype

: 0x8100

LLF Oper State


:
Oper MTU
:
Egr IP Fltr-Id
:
Egr Mac Fltr-Id
:
Egr Ipv6 Fltr-Id :
qinq-pbit-marking :
Egr Agg Rate Limit:

Collect Stats

Clear
9212
n/a
n/a
n/a
both
max

: Disabled

Sap Statistics
Last Cleared Time

: N/A

Packets
Forwarding Engine Stats
Dropped
: 0
Off. HiPrio
: 0
Off. LowPrio
: 231919
Off. Uncolor
: 0
Queueing Stats(Ingress QoS Policy 1)
Dro. HiPrio
: 0
Dro. LowPrio
: 0
For. InProf
: 0
For. OutProf
: 231919

Octets
0
0
22920335
0

0
0
0
22920335

Queueing Stats(Egress QoS Policy 1)

Advanced Configuration Guide

Page 1947

Configuration

Dro.
Dro.
For.
For.

InProf
OutProf
InProf
OutProf

:
:
:
:

0
0
231920
0

0
0
22922995
0

Now, proceed to verify that the spoke termination on PE-2 in the VPRN using IPv6 addressing is
established in an up/up state:
A:PE-2# show service id 1 all
Service Detailed Information
Service Id
:
Service Type
:
Name
:
Description
:
Customer Id
:
Last Status Change:
Last Mgmt Change :
Admin State
:

1
Vpn Id
VPRN
(Not Specified)
(Not Specified)
1
05/17/2010 21:42:52
05/17/2010 21:45:59
Up
Oper State

: 0

Route Dist.
AS Number
ECMP
Max Ipv4 Routes
Max Ipv6 Routes
Ignore NH Metric
Hash Label
Vrf Target
Vrf Import
Vrf Export
MVPN Vrf Target
MVPN Vrf Import
MVPN Vrf Export

:
:
:
:
:
:
:
:
:
:
:
:
:

65500:1
65500
Enabled
No Limit
No Limit
Disabled
Disabled
target:65500:1
None
None
None
None
None

VPRN Type
Router Id
ECMP Max Routes
Auto Bind

:
:
:
:

SAP Count

: 0

SDP Bind Count

: 1

: Up
regular
192.0.2.6
1
LDP

Service Destination Points(SDPs)


Sdp Id 40:1
Description
SDP Id
Spoke Descr
VC Type
Admin Path MTU
Far End

-(192.0.2.2)
: (Not Specified)
: 40:1
: (Not Specified)
: n/a
: 1514
: 192.0.2.2

Admin State
Acct. Pol
Ingress Label
Ingr Mac Fltr-Id
Ingr IP Fltr-Id
Ingr Ipv6 Fltr-Id
Admin ControlWord
Last Status Change
Last Mgmt Change

Page 1948

:
:
:
:
:
:
:
:
:

Up
None
131069
n/a
n/a
n/a
Not Preferred
05/17/2010 21:45:59
05/17/2010 21:45:59

Type

: Spoke

VC Tag
Oper Path MTU
Delivery

: n/a
: 1514
: LDP

Oper State
Collect Stats
Egress Label
Egr Mac Fltr-Id
Egr IP Fltr-Id
Egr Ipv6 Fltr-Id
Oper ControlWord
Signaling

:
:
:
:
:
:
:
:

Up
Disabled
131069
n/a
n/a
n/a
False
n/a

Advanced Configuration Guide

Spoke Termination for IPv6-6VPE

Class Fwding State :


Flags
:
Peer Pw Bits
:
Peer Fault Ip
:
Peer Vccv CV Bits :
Peer Vccv CC Bits :
Application Profile:

Down
None
None
None
lspPing
mplsRouterAlertLabel
None

KeepAlive Information :
Admin State
: Disabled
Hello Time
: 10
Max Drop Count
: 3

Oper State
Hello Msg Len
Hold Down Time

: Disabled
: 0
: 10

Statistics
I. Fwd. Pkts.
I. Fwd. Octs.
E. Fwd. Pkts.

I. Dro. Pkts.
I. Dro. Octs.
E. Fwd. Octets

: 0
: 0
: 22042904

:
: 0
: 0
: 232421

Number of SDPs : 1
Service Access Points
No Sap Associations
Service Interfaces
Interface
If Name
Admin State
Protocols
IP Addr/mask
IGP Inhibit
Description

:
:
:
:
:
:

loopback
Up
None
192.0.2.6/32
Disabled
N/A

:
:
:
:
:
:
:
:
:
:
:
:
:
:

(Not Specified)
2
05/17/2010 21:48:08
loopback
Trusted
False
68:64:ff:00:00:00
1500
Disabled
None
None
system
disabled
0

Oper (v4/v6)

: Up/Down

Address Type
: Primary
Broadcast Address : Host-ones

Details
Description
If Index
Last Oper Chg
Port Id
TOS Marking
SNTP B.Cast
MAC Address
IP Oper MTU
Arp Populate
Cflowd
LdpSyncTimer
LSR Load Balance
uRPF Chk
uRPF Fail Bytes

Proxy ARP Details


Rem Proxy ARP
: Disabled
Policies
: none

Virt. If Index
Global If Index

: 2
: 384

If Type

: VPRN

Arp Timeout
ICMP Mask Reply
Host Conn Verify

: 14400
: True
: Disabled

uRPF Chk Fail Pkts: 0

Local Proxy ARP

: Disabled

Proxy Neighbor Discovery Details


Local Pxy ND
: Disabled
Policies
: none

Advanced Configuration Guide

Page 1949

Configuration

DHCP no local server


DHCP Details
Description : (Not Specified)
Admin State
: Down
Lease Populate
: 0
Gi-Addr
: 192.0.2.6*
Gi-Addr as Src Ip : Disabled
* = inferred gi-address from interface IP address
Action

: Keep

Trusted

: Disabled

Lease Populate
Nbr Resolution
Remote Id

: 0
: Disabled
: Disabled

DHCP Proxy Details


Admin State
: Down
Lease Time
: N/A
Emul. Server
: Not configured
Subscriber Authentication Details
Auth Policy
: None
DHCP6 Relay Details
Description
:
Admin State
:
Oper State
:
If-Id Option
:
Src Addr
:

(Not Specified)
Down
Down
None
Not configured

DHCP6 Server Details


Admin State
: Down
ICMP Details
Redirects
: Number - 100
Unreachables : Number - 100
TTL Expired : Number - 100
IPCP
Peer
Peer
Peer

Max. Lease States : 8000

Time (seconds)
Time (seconds)
Time (seconds)

- 10
- 10
- 10

Address Extension Details


IP Addr
: Not configured
Pri DNS Addr : Not configured
Sec DNS Addr : Not configured

Interface
If Name
Admin State
Protocols
Ipv6 Addr
Ipv6 Addr
Description

: Spoke_to_PE-1
: Up
Oper (v4/v6)
: None
: 2001:DB8:1000::2/64
: FE80::6A64:FFFF:FE00:0/64
: N/A

: Down/Up
PREFERRED
PREFERRED

Details
Description
If Index
Last Oper Chg
SDP Id

:
:
:
:

(Not Specified)
3
Virt. If Index
05/17/2010 21:42:42 Global If Index
spoke-40:1

Spoke-SDP Details
Admin State
: Up
Hash Label
: Disabled
Peer Fault Ip
: None

Page 1950

Oper State

: 3
: 383

: Up

Advanced Configuration Guide

Spoke Termination for IPv6-6VPE

Peer Pw Bits
Peer Vccv CV Bits
Peer Vccv CC Bits
Flags
TOS Marking
SNTP B.Cast
MAC Address
IP Oper MTU
Arp Populate
Cflowd
LdpSyncTimer
LSR Load Balance
uRPF Chk
uRPF Fail Bytes

:
:
:
:
:
:
:
:
:
:
:
:
:
:

None
lspPing
mplsRouterAlertLabel
None
Trusted
False
68:64:ff:00:00:00
1500
Disabled
None
None
system
disabled
0

Proxy ARP Details


Rem Proxy ARP
: Disabled
Policies
: none

If Type

: VPRN

Arp Timeout
ICMP Mask Reply
Host Conn Verify

: 14400
: True
: Disabled

uRPF Chk Fail Pkts: 0

Local Proxy ARP

: Disabled

Proxy Neighbor Discovery Details


Local Pxy ND
: Disabled
Policies
: none
DHCP no local server
DHCP Details
Description : (Not Specified)
Admin State
: Down
Gi-Addr
: Not configured
Action
: Keep

Lease Populate
: 0
Gi-Addr as Src Ip : Disabled
Trusted
: Disabled

DHCP Proxy Details


Admin State
: Down
Lease Time
: N/A
Emul. Server
: Not configured
Subscriber Authentication Details
Auth Policy
: None
DHCP6 Relay Details
Description
:
Admin State
:
Oper State
:
If-Id Option
:
Src Addr
:

(Not Specified)
Down
Down
None
Not configured

DHCP6 Server Details


Admin State
: Down
ICMP Details
Redirects
: Number - 100
Unreachables : Number -100
TTL Expired : Number -100
IPCP
Peer
Peer
Peer

Lease Populate
Nbr Resolution
Remote Id

: 0
: Disabled
: Disabled

Max. Lease States : 8000

Time (seconds)
Time (seconds)
Time (seconds)

- 10
- 10
- 10

Address Extension Details


IP Addr
: Not configured
Pri DNS Addr : Not configured
Sec DNS Addr : Not configured

Advanced Configuration Guide

Page 1951

Configuration

VPLS Sites
Site

Site-Id

Dest

Mesh-SDP

Admin

Oper

Fwdr

No Matching Entries

It is important to note the following from PE-2 show service output above:

VPRN service is in an admin/oper up/up state

Spoke SDP is established to PE-1 (192.0.2.2) admin/oper up/up (IPv6) state.


IPv6 interface is established and its IPv6 address is preferred (2001:DB8:1000::2/64)
IPv6 link local address has been dynamically assigned and preferred
(FE80::6A64:FFFF:FE00:0/64).
This output also lists other IPv6 fields that can be checked if configured: DHCP6relay, DHCP6 server, etc.

After verification of the services (Epipe, VPRN), verify MP-eBGP peering connectivity (through
IPv6 interfaces) on the VPRN between PE-2 and CE-1.
A:PE-2# show router 1 bgp neighbor
BGP Neighbor
Peer : 2001:DB8:1000::1
Group : CE-1-PE-2-spoke
Peer AS
:
Peer Address
:
Local AS
:
Local Address
:
Peer Type
:
State
:
Last Event
:
Last Error
:
Local Family
:
Remote Family
:
Hold Time
:
Active Hold Time
:
Cluster Id
:
Preference
:
Recd. Paths
:
Ipv4 Recd. Prefixes :
Ipv4 Suppressed Pfxs :
VPN-Ipv4 Recd. Pfxs :
Mc Ipv4 Recd. Pfxs. :
Mc Ipv4 Suppr. Pfxs :
Ipv6 Recd. Prefixes :
VPN-Ipv6 Recd. Pfxs :
VPN-Ipv6 Suppr. Pfxs :
L2-VPN Recd. Pfxs
:
MVPN-Ipv4 Suppr. Pfxs:

Page 1952

64500
Peer Port
2001:DB8:1000::1
65500
Local Port
2001:DB8:1000::2
External
Established
Last State
recvKeepAlive
Unrecognized Error
Ipv6
Ipv6
90
Keep Alive
10
Active Keep Alive
None
170
Num of Update Flaps
1
0
Ipv4 Active Prefixes
0
VPN-Ipv4 Suppr. Pfxs
0
VPN-Ipv4 Active Pfxs
0
Mc Ipv4 Active Pfxs.
0
Ipv6 Suppressed Pfxs
1
Ipv6 Active Prefixes
0
VPN-Ipv6 Active Pfxs
0
L2-VPN Suppr. Pfxs
0
L2-VPN Active Pfxs
0
MVPN-Ipv4 Recd. Pfxs

: 179
: 49723

: Active

: 30
: 3
: 0
:
:
:
:
:
:
:
:
:
:

0
0
0
0
0
1
0
0
0
0

Advanced Configuration Guide

Spoke Termination for IPv6-6VPE

MVPN-Ipv4 Active Pfxs:


MDT-SAFI Recd. Pfxs :
Input Queue
:
i/p Messages
:
i/p Octets
:
i/p Updates
:
TTL Security
:
Graceful Restart
:
Advertise Inactive
:
Advertise Label
:
Auth key chain
:
Bfd Enabled
:
Local Capability
:
Remote Capability
:
Import Policy
:
Export Policy
:

0
MDT-SAFI Suppr. Pfxs
0
MDT-SAFI Active Pfxs
0
Output Queue
109157
o/p Messages
2074060
o/p Octets
1
o/p Updates
Disabled
Min TTL Value
Disabled
Stale Routes Time
Disabled
Peer Tracking
None
n/a
Disabled
RtRefresh MPBGP 4byte ASN
RtRefresh MPBGP 4byte ASN
None Specified / Inherited
PE-2-BGP-CE-1

:
:
:
:
:
:
:
:
:

0
0
0
109704
2084468
1
n/a
n/a
Disabled

Neighbors : 1

It is important to note that not only is the MP-eBGP session on the VPRN established but that the
MP-BGP capabilities are supported (locally and remotely).
Finally, the following configuration is an example of the VPRN service on PE-3 with SAP
interfaces to CE-2, with MP-eBGP peering configured.

VPRN

Address
2001:DB8:2000::1/64

PE-3

Address
2001:DB8:2000::2/64

SAP

CE-2
OSSG595

Figure 202: PE-3 VPRN with SAP to CE-2

Advanced Configuration Guide

Page 1953

Configuration

A:PE-3>config>service>vprn# info
router-id 192.0.2.7
autonomous-system 65500
route-distinguisher 65500:1
auto-bind ldp
vrf-target target:65500:1
interface loopback create
address 192.0.2.7/32
loopback
exit
interface "int-PE-3-CE-2" create
ipv6
address 2001:DB8:2000::1/64
exit
sap 1/1/2 create
exit
exit
bgp
router-id 192.0.2.7
group CE-2-PE-3
family ipv6
local-as 65500
peer-as 64500
local-address 2001:DB8:2000::1
neighbor 2001:DB8:2000::2
as-override
type external
export "PE-3-BGP-CE-2"
exit
exit
exit
no shutdown
A:PE3>config>router>policy-options# info
policy-options
begin
prefix-list "PE-3-CE-2"
prefix 2001:DB8:3000::/64 exact
exit
policy-statement "PE-3-BGP-CE-2"
entry 10
from
prefix-list "PE-3-CE-2"
exit
action accept
exit
exit
exit
commit
exit

The IPv6 configuration options for the SAP interface (int-PE-3-CE-2) are similar to those in the
above example for the spoke SDP on PE-2. PE-3 BGP export policy (PE-3-BGP-CE-2) is also
similar to the example for PE-2 in advertising the learned IPv6 route to CE-2.

Page 1954

Advanced Configuration Guide

Spoke Termination for IPv6-6VPE

Verification of the configuration of the VPRN service and MP-eBGP peering connectivity to CE-2
is shown below:
A:PE-3# show service id 1 all
Service Detailed Information
Service Id
:
Service Type
:
Name
:
Description
:
Customer Id
:
Last Status Change:
Last Mgmt Change :
Admin State
:

1
Vpn Id
VPRN
(Not Specified)
(Not Specified)
1
05/19/2010 14:10:48
05/19/2010 14:10:48
Up
Oper State

: 0

Route Dist.
AS Number
ECMP
Max Ipv4 Routes
Max Ipv6 Routes
Ignore NH Metric
Hash Label
Vrf Target
Vrf Import
Vrf Export
MVPN Vrf Target
MVPN Vrf Import
MVPN Vrf Export

:
:
:
:
:
:
:
:
:
:
:
:
:

65500:1
65500
Enabled
No Limit
No Limit
Disabled
Disabled
target:65500:1
None
None
None
None
None

VPRN Type
Router Id
ECMP Max Routes
Auto Bind

:
:
:
:

SAP Count

: 1

SDP Bind Count

: 0

: Up
regular
192.0.2.7
1
LDP

Service Destination Points(SDPs)


No Matching Entries
Service Access Points
SAP 1/1/2
Service Id
:
SAP
:
Description
:
Admin State
:
Flags
:
Multi Svc Site
:
Last Status Change :
Last Mgmt Change
:
Sub Type
:
Dot1Q Ethertype
:
Split Horizon Group:

1
1/1/2
(Not Specified)
Up
None
None
05/19/2010 11:20:22
05/19/2010 14:16:54
regular
0x8100
(Not Specified)

Admin MTU
Ingr IP Fltr-Id
Ingr Mac Fltr-Id
Ingr Ipv6 Fltr-Id
tod-suite
Ing Agg Rate Limit

9212
n/a
n/a
n/a
None
max

:
:
:
:
:
:

Advanced Configuration Guide

Encap

: null

Oper State

: Up

QinQ Ethertype

: 0x8100

Oper MTU
:
Egr IP Fltr-Id
:
Egr Mac Fltr-Id
:
Egr Ipv6 Fltr-Id :
qinq-pbit-marking :
Egr Agg Rate Limit:

9212
n/a
n/a
n/a
both
max

Page 1955

Configuration

Q Frame-Based Acct : Disabled


Acct. Pol

: None

Collect Stats

: Disabled

Anti Spoofing

: None

Avl Static Hosts


Tot Static Hosts

: 0
: 0

Calling-Station-Id : n/a
Application Profile: None
Sap Statistics
Last Cleared Time

: N/A

Packets
Forwarding Engine Stats
Dropped
: 0
Off. HiPrio
: 0
Off. LowPrio
: 0
Off. Uncolor
: 0

Octets
0
0
0
0

Queueing Stats(Ingress QoS Policy 1)


Dro. HiPrio
: 0
Dro. LowPrio
: 0
For. InProf
: 0
For. OutProf
: 0

0
0
0
0

Queueing Stats(Egress
Dro. InProf
Dro. OutProf
For. InProf
For. OutProf

0
0
14042605
0

QoS Policy 1)
: 0
: 0
: 141983
: 0

Service Interfaces
Interface
If Name
Admin State
Protocols
IP Addr/mask
IGP Inhibit
Description

:
:
:
:
:
:

loopback
Up
None
192.0.2.7/32
Disabled
N/A

:
:
:
:
:
:
:
:
:
:
:
:
:
:

(Not Specified)
2
05/19/2010 14:12:24
loopback
Trusted
False
68:67:ff:00:00:00
1500
Disabled
None
None
system
disabled
0

Oper (v4/v6)

: Up/Down

Address Type
: Primary
Broadcast Address : Host-ones

Details
Description
If Index
Last Oper Chg
Port Id
TOS Marking
SNTP B.Cast
MAC Address
IP Oper MTU
Arp Populate
Cflowd
LdpSyncTimer
LSR Load Balance
uRPF Chk
uRPF Fail Bytes

Page 1956

Virt. If Index
Global If Index

: 2
: 384

If Type

: VPRN

Arp Timeout
ICMP Mask Reply
Host Conn Verify

: 14400
: True
: Disabled

uRPF Chk Fail Pkts: 0

Advanced Configuration Guide

Spoke Termination for IPv6-6VPE

Proxy ARP Details


Rem Proxy ARP
: Disabled
Policies
: none

Local Proxy ARP

: Disabled

Proxy Neighbor Discovery Details


Local Pxy ND
: Disabled
Policies
: none
DHCP no local server
DHCP Details
Description : (Not Specified)
Admin State
: Down
Lease Populate
: 0
Gi-Addr
: 192.0.2.7*
Gi-Addr as Src Ip : Disabled
* = inferred gi-address from interface IP address
Action

: Keep

Trusted

: Disabled

Lease Populate
Nbr Resolution
Remote Id

: 0
: Disabled
: Disabled

DHCP Proxy Details


Admin State
: Down
Lease Time
: N/A
Emul. Server
: Not configured
Subscriber Authentication Details
Auth Policy
: None
DHCP6 Relay Details
Description
:
Admin State
:
Oper State
:
If-Id Option
:
Src Addr
:

(Not Specified)
Down
Down
None
Not configured

DHCP6 Server Details


Admin State
: Down
ICMP Details
Redirects
: Number -100
Unreachables : Number -100
TTL Expired : Number -100
IPCP
Peer
Peer
Peer

Max. Lease States : 8000

Time (seconds)
Time (seconds)
Time (seconds)

- 10
- 10
- 10

Address Extension Details


IP Addr
: Not configured
Pri DNS Addr : Not configured
Sec DNS Addr : Not configured

Interface
If Name
Admin State
Protocols
Ipv6 Addr
Ipv6 Addr
Description

: int-PE-3-CE-2
: Up
Oper (v4/v6)
: None
: 2001:DB8:2000::1/64
: FE80::6A67:FFFF:FE00:0/64
: N/A

: Down/Up
PREFERRED
PREFERRED

Details
Description

: (Not Specified)

Advanced Configuration Guide

Page 1957

Configuration

If Index
Last Oper Chg
SAP Id
TOS Marking
SNTP B.Cast
MAC Address
IP Oper MTU
Arp Populate
Cflowd
LdpSyncTimer
LSR Load Balance
uRPF Chk
uRPF Fail Bytes

:
:
:
:
:
:
:
:
:
:
:
:
:

3
05/19/2010 14:13:01
1/1/2
Trusted
False
68:67:01:01:00:02
9198
Disabled
None
None
system
disabled
0

Proxy ARP Details


Rem Proxy ARP
: Disabled
Policies
: none

Virt. If Index
Global If Index

: 3
: 383

If Type

: VPRN

Arp Timeout
ICMP Mask Reply
Host Conn Verify

: 14400
: True
: Disabled

uRPF Chk Fail Pkts: 0

Local Proxy ARP

: Disabled

Proxy Neighbor Discovery Details


Local Pxy ND
: Disabled
Policies
: none
DHCP no local server
DHCP Details
Description : (Not Specified)
Admin State
: Down
Gi-Addr
: Not configured
Action
: Keep

Lease Populate
: 0
Gi-Addr as Src Ip : Disabled
Trusted
: Disabled

DHCP Proxy Details


Admin State
: Down
Lease Time
: N/A
Emul. Server
: Not configured
Subscriber Authentication Details
Auth Policy
: None
DHCP6 Relay Details
Description
:
Admin State
:
Oper State
:
If-Id Option
:
Src Addr
:

(Not Specified)
Down
Down
None
Not configured

DHCP6 Server Details


Admin State
: Down
ICMP Details
Redirects
: Number -100
Unreachables : Number -100
TTL Expired : Number -100
IPCP
Peer
Peer
Peer

Page 1958

Lease Populate
Nbr Resolution
Remote Id

: 0
: Disabled
: Disabled

Max. Lease States : 8000

Time (seconds)
Time (seconds)
Time (seconds)

- 10
- 10
- 10

Address Extension Details


IP Addr
: Not configured
Pri DNS Addr : Not configured
Sec DNS Addr : Not configured

Advanced Configuration Guide

Spoke Termination for IPv6-6VPE

At this point, VPRN access using spoke termination for IPv6 with MP-eBGP peering on PE-2,
towards CE-1, has been established. VPRN access using a SAP with MP-eBGP peering on PE-3,
towards CE-1, has also been established. MP-iBGP, providing 6VPE, has been configured and
built between PE-2 and PE-3 across the MPLS Network. Now, propagate the advertisements of the
IPv6 prefixes learned on PE-2 from CE-1 (2001:DB8:3000::/64) and on PE-3 from CE-2
(2001:DB8:4000::/64) across the MPLS network using MP-iBGP (6VPE).
Perform verification on PE-2 of routes learned and advertised to CE-1.
A:PE-2# show router bgp summary
BGP Router ID:192.0.2.3
AS:65500

Local AS:65500

BGP Admin State


Total Peer Groups
Total BGP Paths
Total Ipv4 Remote Rts
Total Ipv6 Remote Rts
Total Supressed Rts
Total Decay Rts

:
:
:
:
:
:
:

Up
1
6
0
0
0
0

BGP Oper State


Total Peers
Total Path Memory
Total Ipv4 Rem. Active Rts
Total Ipv6 Rem. Active Rts
Total Hist. Rts

:
:
:
:
:
:

Total
Total
Total
Total
Total
Total
Total
Total
Total

:
:
:
:
:
:
:
:
:

1
1
0
1
0
0
0
0
0

Total VPN Peers

: 1

VPN Peer Groups


VPN Local Rts
VPN-Ipv4 Rem. Rts
VPN-Ipv6 Rem. Rts
L2-VPN Rem. Rts
VPN Supp. Rts
VPN Decay Rts
MVPN-Ipv4 Rem Rts
MDT-SAFI Rem Rts

Total
Total
Total
Total

VPN-Ipv4 Rem. Act. Rts:


VPN-Ipv6 Rem. Act. Rts:
L2VPN Rem. Act. Rts
:
VPN Hist. Rts
:

Up
1
752
0
0
0

0
1
0
0

Total MVPN-Ipv4 Rem Act Rts : 0


Total MDT-SAFI Rem Act Rts : 0

BGP Summary
Neighbor
AS PktRcvd InQ Up/Down
PktSent OutQ

State|Rcv/Act/Sent (Addr Family)

192.0.2.4
65500

72529
72550

0 01d23h54m 1/1/1 (VpnIPv6)


0

The above output shows the BGP Neighbor of CE-1 (192.0.2.4) and that PE-2 has received and
learned an IPv6 prefix.
A:PE-2# show router 1 bgp routes ipv6
BGP Router ID:192.0.2.6
AS:65500
Legend
Status codes
Origin codes

Local AS:65500

: u - used, s - suppressed, h - history, d - decayed, * - valid


: I - IGP, e - EGP, ? - incomplete, > - best

BGP Ipv6 Routes


Flag

Network
Nexthop

Advanced Configuration Guide

LocalPref

MED
VPNLabel

Page 1959

Configuration

As-Path
u*>?

2001:DB8:3000::/64
2001:DB8:1000::1
64500

None

None
-

Routes : 1

The output above of the VPRNs BGP route-table for the IPv6 address-family lists the valid and
best route for 2001:DB8:3000::/64 with a BGP next hop of 2001:DB8:1000::1 (CE-1).
A:PE-2# show router 1 bgp neighbor 2001:DB8:1000::1 advertised-routes ipv6
BGP Router ID:192.0.2.6
Legend
Status codes
Origin codes

AS:65500

Local AS:65500

: u - used, s - suppressed, h - history, d - decayed, * - valid


: I - IGP, e - EGP, ? - incomplete, > - best

BGP Ipv6 Routes


Flag

Network
Nexthop
As-Path

LocalPref

MED
VPNLabel

2001:DB8:4000::/64
2001:DB8:1000::2
65500 65500

n/a

None
-

Routes : 1

The above output taken from PE-2 shows the advertised IPv6 prefix of 2001:DB8:4000::/64,
originated and advertised from CE-2 to PE-3.
A:PE-2# show router bgp routes vpn-ipv6
BGP Router ID:192.0.2.3
AS:65500
Legend
Status codes
Origin codes

Local AS:65500

: u - used, s - suppressed, h - history, d - decayed, * - valid


: I - IGP, e - EGP, ? - incomplete, > - best

BGP VPN-Ipv6 Routes


Flag

Network
Nexthop
As-Path

LocalPref

MED
VPNLabel

u*>?

65500:1:2001:DB8:4000::/64
::FFFF:C000:204
64500

100

None
131068

Routes : 1

Page 1960

Advanced Configuration Guide

Spoke Termination for IPv6-6VPE

PE-2 in the previous output has learned of prefix 2001:DB8:4000::/64 as an MP-BGP VPN-IPv6
route, with the VRF route-target of 65500:1 from PE-3.
In the output below PE-2 is advertising the VPN-IPv6 route of 2001:DB8:3000::/64 that was
learned from CE-1 across the MP-iBGP Session to PE-3.
A:PE-2# show router bgp neighbor 192.0.2.4 advertised-routes vpn-ipv6
BGP Router ID:192.0.2.3
AS:65500
Local AS:65500
Legend
Status codes
Origin codes

: u - used, s - suppressed, h - history, d - decayed, * - valid


: I - IGP, e - EGP, ? - incomplete, > - best

BGP VPN-Ipv6 Routes


Flag

Network
Nexthop
As-Path

LocalPref

MED
VPNLabel

65500:1:2001:DB8:3000::/64
::FFFF:C000:203
64500

100

None
131068

Routes : 1

Advanced Configuration Guide

Page 1961

Configuration

Verify VPN-IPv6 routes on PE-3.


A:PE-3# show router bgp routes vpn-ipv6
BGP Router ID:192.0.2.4
AS:65500
Legend
Status codes
Origin codes

Local AS:65500

: u - used, s - suppressed, h - history, d - decayed, * - valid


: I - IGP, e - EGP, ? - incomplete, > - best

BGP VPN-Ipv6 Routes


Flag

Network
Nexthop
As-Path

LocalPref

MED
VPNLabel

u*>?

65500:1:2001:DB8:3000::/64
::FFFF:C000:203
64500

100

None
131068

Routes : 1

The output above, taken from PE-3, lists the VPN-IPv6 route that is being learned from PE-2,
namely 2001:DB8:3000::/64.
The output show below lists the advertised VPN-IPv6 route of 2001:DB8:4000::/64 from PE-3 to
PE-2.
A:PE-3# show router bgp neighbor 192.0.2.3 advertised-routes vpn-ipv6
BGP Router ID:192.0.2.4
AS:65500
Local AS:65500
Legend
Status codes : u - used, s - suppressed, h - history, d - decayed, * - valid
Origin codes : I - IGP, e - EGP, ? - incomplete, > - best
BGP VPN-Ipv6 Routes
Flag

Network
Nexthop
As-Path

LocalPref

MED
VPNLabel

65500:1:2001:DB8:4000::/64
::FFFF:C000:204
64500

100

None
131068

Routes : 1

Verify IPv6 prefixes learned and advertised between PE-3 and CE-2.
A:PE-3# show router 1 bgp routes ipv6
BGP Router ID:192.0.2.7
AS:65500
Legend
Status codes
Origin codes

Page 1962

Local AS:65500

: u - used, s - suppressed, h - history, d - decayed, * - valid


: I - IGP, e - EGP, ? - incomplete, > - best

Advanced Configuration Guide

Spoke Termination for IPv6-6VPE

BGP Ipv6 Routes


Flag

Network
Nexthop
As-Path

LocalPref

u*> 2001:DB8:4000::/64
2001:DB8:2000::2
64500

None

MED
VPNLabel

None
-

Routes : 1

From the PE-3 output above shows the IPv6 prefix of 2001:DB8:4000::/64 learned from CE-2.
The output below verifies the advertisement of IPv6 prefix 2001:DB8:3000::/64 to CE-2.
A:PE-3# show router 1 bgp neighbor 2001:DB8:2000::2 advertised-routes ipv6
BGP Router ID:192.0.2.7
AS:65500
Local AS:65500
Legend
Status codes
Origin codes

: u - used, s - suppressed, h - history, d - decayed, * - valid


: I - IGP, e - EGP, ? - incomplete, > - best

BGP Ipv6 Routes


Flag

Network
Nexthop
As-Path

LocalPref

MED
VPNLabel

2001:DB8:3000::/64
2001:DB8:2000::1
65500 65500

n/a

None
-

Routes : 1

Perform the final verification of CE-1 and CE-2 showing that IPv6 routes for AS-64500 have been
received and are valid across the VPRN service.
A:CE-1# show router bgp routes ipv6
BGP Router ID:192.0.2.1
AS:64500
Legend
Status codes
Origin codes

Local AS:64500

: u - used, s - suppressed, h - history, d - decayed, * - valid


: I - IGP, e - EGP, ? - incomplete, > - best

BGP Ipv6 Routes


Flag

Network
Nexthop
As-Path

LocalPref

MED
VPNLabel

u*>?

2001:DB8:4000::/64
2001:DB8:1000::2
65500 65500

None

None
-

Advanced Configuration Guide

Page 1963

Configuration

Routes : 1

A:CE-2# show router bgp routes ipv6


BGP Router ID:192.0.2.5
AS:64500
Legend
Status codes
Origin codes

Local AS:64500

: u - used, s - suppressed, h - history, d - decayed, * - valid


: I - IGP, e - EGP, ? - incomplete, > - best

BGP Ipv6 Routes


Flag

Network
Nexthop
As-Path

LocalPref

MED
VPNLabel

u*>?

2001:DB8:3000::/64
2001:DB8:2000::1
65500 65500

None

None
-

Routes : 1

Page 1964

Advanced Configuration Guide

Spoke Termination for IPv6-6VPE

Conclusion
Spoke termination for IPv6-6VPE extends the use of spoke terminated interfaces from an EPIPE
VLL into a VPRN service using IPv6 interfaces on the access. Supporting the requirement of IPv6
interfaces, routing of IPv6 prefixes and the use of 6VPE for IPv6 tunnelling over an IPv4 network
allows the 7750 SR to provide capabilities to support the growth of IPv6 architectures. This
chapter provides examples of this feature with show commands for guidance.

Advanced Configuration Guide

Page 1965

Conclusion

Page 1966

Advanced Configuration Guide

Subscriber Redundancy for Routed-CO

In This Chapter
This section provides information about Subscriber Redundancy for Routed-CO (SRRP).
Topics in this section include:

Applicability on page 1968

Summary on page 1969

Overview on page 1970

Configuration on page 1972

Conclusion on page 2000

Advanced Configuration Guide

Page 1967

Applicability

Applicability
These configuration notes are applicable for the 7750 SR-c12, SR-7/12 and 7710 series and was
tested on SR-OS 7.0 R5. This is supported on 7450 ESS-7 or ESS-12 in mixed-mode since 8.0R1.
The 7750 SR-c4 is supported from 8.0R4 and higher.
This note is related only to the use of IPv4.
Configuration and troubleshooting commands were taken from a 7750 SR-7.

Page 1968

Advanced Configuration Guide

Subscriber Redundancy for Routed-CO

Summary
This section focuses on the delivery of redundant services in an Enhanced Subscriber management
(ESM) Routed-CO environment using IES (Internet Enhanced Service) or VPRN (Virtual Private
Routed Network).
It is applicable to delivering high speed Internet (HSI), voice-over-IP (VoIP) and video-ondemand (VoD) to subscribers.
Redundancy is provided at two levels:

system redundancy

network redundancy

The system redundancy is based on the high availability features of the 7750/7710 SRs, such as
component redundancy (power, fans, control processor modules etc.) and software redundancy
(service and protocol redundancy and non-stop-routing), which are not discussed here.
The network redundancy for subscriber access in an ESM Routed-CO environment requires that
each BSAN (Broadband Service Access Node) is dual-homed to two 7750/7710 SRs either in a
point-to-point fashion with the BSANs having direct physical connectivity to the 7750/7710 SRs,
or by having Layer-2 aggregation between the BSANs and the 7750/7710 SRs.
This connection will operate in a master-slave relationship providing both link and system
redundancy for the subscribers on the BSAN when accessing the configured services.
Subscriber redundancy for Routed-CO aims to minimize the outage due to a failure.
This chapter provides configuration and troubleshooting commands for SRRP with static-host ipmac.
Knowledge of the TPSDA (Triple Play Service Delivery Architecture) concepts is assumed
throughout this document.

Advanced Configuration Guide

Page 1969

Overview

Overview
There are three components on the 7750/7710 SRs to implement network redundancy:
1. Redundant access from the BSANs to the two 7750/7710 SRs provided by the SRRP.
2. Mirroring of subscriber state between the two 7750/7710 SRs achieved through the MultiChassis Synchronization (MCS) protocol.
3. Backup spoke SDP traffic path between the two 7750/7710 SRs peers.
These components are shown in Figure 203.

IES/VPRN
Sub-int
grp-int
SSRP

Active/Master

7750/7710

MCS

BNG1

Simulated

Red-intf

Internet

SRRP
Red-intf

NPE

BSAN
MCS
IES/VPRN
Sub-int
grp-int
SSRP

Backup/Standby

7750/7710

BNG2
OSSG420

Figure 203: Network Redundancy Components for ESM Routed-CO

The following configuration tasks should be done first and are not explained in detail in these
configuration notes:

Page 1970

Basic service router configuration (system interface, IGP, MPLS, BGP)

Routed CO service topology: VPRN or IES service with subscriber and group interface on
BNGs (Broadband Network Gateway)

ESM configuration

Static host configuration

Advanced Configuration Guide

Subscriber Redundancy for Routed-CO

This chapter will focus on SRRP in a VPRN service subscriber-interface on BNG (Routed-CO).
Note that in case of Routed-CO, it is also possible to configure SRRP in the base routing instance
using an IES service.

The SRRP Protocol


The SRRP protocol operates on a specific SAP within the group interface under the subscriberinterface of an IES/VPRN service. Through a method similar to the VRRP (Virtual Router
Redundancy Protocol), it provides a set of default gateways to the subscribers on the BSAN.
These are active on the 7750 SR in a master state and inactive on the 7750 SR in the backup state.
Traffic is forwarded upstream and downstream through the master. If the backup loses
connectivity to the master (for example, fails to receive SRRP messages from the master), it
transitions to the master state and takes over the ownership of the default gateways and the
responsibility for forwarding traffic to/from the subscriber. This provides redundancy from the
BSAN toward the provider network.
If an SRRP failover were to occur, it is important that the subscriber state (IP/MAC addresses,
QOS profiles, etc.) be immediately available on the new SRRP master 7750 SR; otherwise,
subscriber traffic will be dropped due to the anti-spoofing security. The subscriber state is
synchronized through the MCS protocol, which mirrors the subscriber state between the two
peers. This allows both peers to know the details of the active subscribers and therefore forward
traffic on their behalf with the correct QOS actions both to and from the BSAN if that peer is the
SRRP master.
The last scenario relates to the forwarding from the provider network to the subscribers. If the
natural IP routing causes this traffic to forward through the SRRP master, then it will
automatically be forwarded to the subscriber. However, if the provider routing scheme causes
traffic destined to a subscriber to arrive at the 7750 SR in the SRRP backup state for that
subscriber, it will be dropped as the backup does not forward traffic out of the subscriber SAPs.
To avoid this, a redundant interface is configured between the two 7750 SRs under the subscriber/
group-interfaces. Any traffic arriving on the 7750 SR for an active subscriber, where its associated
SRRP instance is in the backup state, will be forwarded through the redundant interface to the
SRRP master, which in turn forwards it to the subscriber.
In addition to successful forwarding the traffic, this operation also maintains the subscriber QOS
compliance as all traffic for a given subscriber enters and exits the routed-co interface through a
single SAP, allowing the associated IOM hardware to perform the correct QOS actions.

Advanced Configuration Guide

Page 1971

Configuration

Configuration
Subscriber Interface Configuration
Redundant Default Gateway

The redundant default gateway IP addresses must be configured under the subscriberinterface (within the IES/VPRN service) for each subnet defined.

Three subnets are configured under the subscriber-interface sub-int-1, each with a gw-ipaddress which is uses as the default gateway by the subscribers in that subnet.

*A:BNG-2>configure
service
vprn 1 customer 1 create
- - - snip - - subscriber-interface "sub-int-1" create
address 10.2.0.2/16 gw-ip-address 10.2.0.254
address 10.3.0.2/16 gw-ip-address 10.3.0.254
address 10.4.0.2/16 gw-ip-address 10.4.0.254

Note that the gw-ip-address could be a virtual (unused) address in this subnet or the
address of one of the actual subscriber-interfaces on the two 7750/7710 SRs. It must not
be assigned as a subscriber address.

If DHCP were to be used, the associated subscriber-interface address should be used for
the gi-address configured for DHCP under the group-interface (will not be covered here as
static host is used). This ensures that if the offer returned from the DHCP server arrives at
the SRRP backup (rather than master) it will be forwarded by the SRRP backup to the
master through the redundant interface.

In environments where there are many subscribers, it will take time to synchronize the subscriber
state between the peers when the subscriber-interface is enabled (perhaps, after a reboot). In order
to ensure that the state has time to be synchronized, a delayed-enable timer can be specified under
the subscriber interface. The optional init-only parameter can be added to use this timer only after
a reboot.
*A:BNG-2>config>service>vprn>sub-if# delayed-enable
- delayed-enable <seconds> [init-only]
- no delayed-enable
<seconds>
: [1..1200]
<init-only>
: keyword
*A:BNG-2>config>service>vprn>sub-if# info
------------------------------------------------snip--delayed-enable 1200 init-only

Page 1972

Advanced Configuration Guide

Subscriber Redundancy for Routed-CO

Group Interface Configuration


The group interface group-int-1 to connect BSAN is configured under the subscriber interface
*A:BNG-2>config>service>vprn# info
------------------------------------------------snip--subscriber-interface "sub-int-1" create
address 10.2.0.2/16 gw-ip-address 10.2.0.254
address 10.3.0.2/16 gw-ip-address 10.3.0.254
address 10.4.0.2/16 gw-ip-address 10.4.0.254
group-interface "group-int-1" create
---snip---

Static Host Configuration


Enable the sub-sla-mgmt and sub-ident-policy sub-id-default under sap 1/1/3:1 and define static
host (ip-mac) with sla-profile sla-profile-1, sub-profile sla-profile-1 and subscriber static-hostrouted-10.2.0.3.
*A:BNG-2>configure service vprn 1 customer 1 create
---snip--subscriber-interface "sub-int-1" create
---snip--group-interface "group-int-1" create
---snip--sap 1/1/3:1 create
sub-sla-mgmt
sub-ident-policy "sub-id-default"
no shutdown
exit
static-host ip 10.2.0.3 mac 00:00:00:00:00:01 create
sla-profile "sla-profile-1"
sub-profile "sub-profile-1"
subscriber "static-host-routed-10.2.0.3"

SRRP Configuration
In order for the redundant gateway information to be used by subscribers through SAPs belonging
to a particular group-interface, an SRRP instance must be added in the group interface context.
*A:BNG-2>configure service vprn 1 customer 1 create
- - - snip - - group-interface "g1" create
- - - snip- - srrp 1 create
---snip---

Advanced Configuration Guide

Page 1973

Configuration

At this point, any subscriber ARPing for the gw-ip-address will receive a response from the SRRP
master with a source MAC of 00-00-5E-00-01-<xx>, where <xx> is the first byte of the SRRP
identifier in hexadecimal, so in this case for SRRP=1 the source MAC will be 00-00-5E-00-01-01.
The redundant default gateway MAC address could be explicitly configured, if desired, by use of
the gw-mac parameter.
*A:BNG-2>config>service>vprn>sub-if>grp-if>srrp# gw-mac
- gw-mac <mac-address>
- no gw-mac
<mac-address>

: xx:xx:xx:xx:xx:xx or xx-xx-xx-xx-xx-xx

There can be only one SRRP instance per group-interface and all SRRP identifiers must be unique
per system.
When an SRRP instance is enabled, or when there is an SRRP failover from one device to another,
gratuitous ARPs are sent on all VLANs associated with this instance for all gw-ip-addresses (for
example, on all subscriber SAPs and on the SRRP message path SAP in the associated group
interface). This allows all downstream devices to relearn the path to the new master.
The SRRP messages are normally forwarded through the BSAN, thereby verifying the
connectivity from one 7750/7710 SR through the BSAN to the other 7750/7710 SR. In order to
achieve this, a non-subscriber SAP must be configured under the group-interface which is
referenced in the SRRP configuration by the message-path parameter. This not only selects the
SAP to be used for the SRRP messages but also avoids the subscriber anti-spoofing from
automatically dropping the received messages (as there would be no subscriber IP-to-MAC entry
corresponding to the received information) and causing both peers to become master.
The message-path SAP configuration effectively disables IP-MAC anti-spoofing on that SAP.
*A:BNG-2>configure service vprn 1 customer 1 create
- - - snip - - group-interface "group-int-1" create
sap 1/1/3:2 create
exit
---snip--srrp 1 create
message-path 1/1/3:2
---snip---

Note that the SRRP messages are then not sent within the same SAP as the subscriber data traffic,
but it is assumed that the path traversed by the SRRP messages is same as would be used for the
subscriber data; if this is not the case, then the SRRP state would not necessarily reflect a failure in
the data path.
The master of the SRRP instance generates advertisement messages at the keep-alive-interval
(which is encoded in the message) ranging from one (1) to 100 in multiples of 100ms with a
default of 10 (for example, 1 second). The SRRP backup will monitor the reception of these
messages and assume the role of the master if three consecutive messages are not received.

Page 1974

Advanced Configuration Guide

Subscriber Redundancy for Routed-CO

The keep-alive-interval of the master is always used.


*A:BNG-2>config>service>vprn>sub-if>grp-if>srrp# keep-alive-interval
- keep-alive-interval <interval>
- no keep-alive-interval
<interval>

: [1..100] tenths of a second

Only two devices can participate in an SRRP protocol exchange for a given SRRP instance, this
being another difference from VRRP which allows more potential backup devices. This is a
consequence of the direct relationship between the SRRP instance and the associated redundant
interface and MCS peering.
This protocol exchange is also used for the master/backup election, based on the priority (1 to 254)
configured in the SRRP instance. The device with the highest priority will become master.
*A:BNG-2>config>service>vprn>sub-if>grp-if>srrp# info
------------------------------------------------snip--priority 250

With the message source IP address (system IP address) being used as a tie break when the
priorities are the same (the lower IP address becomes the master). The master/backup status is per
SRRP instance (not per IP address). For example, the master is the active gateway for all gw-ipaddresses under the subscriber interface for the associated group-interface (this is true even if the
backup is the IP address owner for one of the gw-ip-addresses). Priority 0 is sent by the master
when it is transitioning to the backup role due to the appearance of a high priority peer. Higher
priority backups always preempt a lower priority master.
A basic form of load distribution can be achieved by having the master SRRP for some groupinterfaces on one peer and the master for other group interfaces on the other peer. Clearly, a failure
may cause all masters to be active on a single peer, which must be taken into account when
designing the network.
The minimum keepalive-timer of 1 is configured, together with the message-path giving the SAP
to be used for the SRRP messages. The priority is set to 250 (default is 100) in order to force this
peer to be the SRRP master when both peers are active.
srrp 1 create
keep-alive-interval 1
----snip---

Advanced Configuration Guide

Page 1975

Configuration

SRRP Configuration Notes

A VRRP policy statement can be added to the SRRP instance definition in order to
dynamically adjust the SRRP priority based on certain non-SRRP related events occurring
(for example, port down, LAG degrade, host unreachable or route unknown).

The gw-ip-addresses are accessible by active subscribers, for example, regardless which
peer is the master, an active subscriber can ping or telnet to its associated gw-ip-address
(clearly, filters can be configured to control this).

BFD (Bi-directional Forwarding Detection)


BFD can be configured with SRRP to speed up the convergence.
srrp 1 create
---snip--bfd-enable 2 interface "bfd-1" dst-ip 10.1.1.1

An IES service needs to be created for the BFD session.


*A:BNG-2# configure service ies 2
interface "bfd-1" create
address 10.1.1.0/31
bfd 100 receive 100 multiplier 3
sap 1/1/3:3 create
exit
exit
no shutdown

Page 1976

Advanced Configuration Guide

Subscriber Redundancy for Routed-CO

Monitoring In-Band Communications Path


In order to monitor the in-band communications path between the subscribers and two 7750/7710
SRs, SRRP uses a slightly modified VRRP advertisement message.
The SRRP message destination IP address (224.0.0.18) and IP protocol number (112) are the same
as for VRRP but there are changes in the following areas:

The source IP address of the message is the system IP address, as opposed to the interface
IP address.

The protocol version has been set to eight (8) (the current version of VRRP is two (2)).

The virtual router identifier has been extended from one byte (maximum 255) to four
bytes (maximum 4294967295) though the maximum number of SRRPs that can be
defined is 255.

The source MAC address is included instead of the virtual router IP addresses (this being
00-00-5E-00-01-<xx>, where <xx> is the first byte of the SRRP identifier in
hexadecimal).

Advanced Configuration Guide

Page 1977

Configuration

Synchronizing the SRRP Peer State


In order to troubleshoot an SRRP environment, the state of each peer is synchronized with the
other peer through the Multi-Chassis Synchronization (MCS). MCS is a proprietary protocol used
for synchronizing application state between two peers. SRRP will function without synchronizing
its state but this synchronization allows for current state of both the local and remote peers to be
displayed and appropriate error messages to be reported when the peer state is not correct. It also
allows the master SRRP subscriber-interface to be pinged through the backup peer (through the
redundant interface).
To link information being mirrored between two 7750/7710 SRs, a sync-tag value is configured to
correspond to either an entire port/LAG or under a port/LAG for a VLAN range. This allows each
7750/7710 SR to know exactly which information should be in sync on each device. The sync-tag
must be unique on the two peers involved.
This example configuration shows only the SRRP aspects. SRRP instance has been configured for
MCS peer 192.0.2.1 using VLANs 1-2 on port 1/1/3. Here, a sync-tag is associated with the SRRP
instance.
*A:BNG-2>config>redundancy>multi-chassis# info
---------------------------------------------peer 192.0.2.1 create
authentication-key "441dO/0RgDg2CA0JlyzVNPuH6Fy2512w" hash2
sync
srrp
sub-mgmt
port 1/1/3 create
range 1-2 sync-tag "srrp1"
exit
no shutdown

Alternatively, if the information needs to be synchronized on port 1/1/3 for all VLANs, then the
following port command could be used instead of the port-plus-ranges shown above.
srrp
sub-mgmt
port 1/1/3 sync-tag "srrp1" create
exit

Note: the VLANs used within the group interfaces must match between the two peers, clearly the
physical ports identifiers may differ.

Page 1978

Advanced Configuration Guide

Subscriber Redundancy for Routed-CO

Multi-Chassis Synchronization
Multi-chassis synchronization (MCS) is a general propriety protocol used to synchronize
information between two 7x50/7710 SR peers. It can be used for the following applications:

IGMP

IGMP Snooping

Subscriber Management

Subscriber Router Redundancy Protocol

IGMP and IGMP snooping are out of the scope of this document.

Subscriber Management Synchronization


In order to ensure that the QOS defined for a subscriber is adhered to, all traffic for a given
subscriber needs to be forward by a single port. When an MSAN is dual-homed to two 7750/7710
SRs this is achieved using the SRRP protocol (described above) and the redundant interface
(described below); specifically, the traffic is forwarded through the SRRP master of the related
group-interface.
When a subscriber is created on the master SRRP, a host route (/32) for its IP address is inserted in
the IP FIB pointing towards the appropriate group-interface.
The same subscriber on the backup peer will have a host route in the IP FIB pointing to the
redundant interface. Note that on the backup peer this requires the subscriber subnet to also be
present in the IP FIB, which in turn requires one of the following:

The local subscriber-interface is up.

The subscriber subnets are learned from active BNG (Broadband Network Gateway)
through routing protocol.

Forcing the subscriber-interface to stay up by creating a dummy group interface with the
oper-up-when-empty command.

*A:BNG-2>config>service>vprn# info
------------------------------------------------snip--subscriber-interface "sub-int-1" create
--snip-group-interface "group-int-1" create
---snip--oper-up-while-empty
sap 1/1/3:1 create
exit

Advanced Configuration Guide

Page 1979

Configuration

Redundant Interface
The requirement for the redundant interface comes from the situation where traffic destined to a
subscriber arrives on the 7750/7710 SR but the associated SRRP state is not master.
When the SRRP state is backup for a particular group-interface, subscriber traffic is not normally
forwarded in/out of the associated subscriber SAPs. Also traffic could arrive but the specific
group-interface for that subscriber is down. These situations could occur due to the natural routing
within the provider network or temporarily during an SRRP failover. Note that as the subscriber
subnets are configured under the subscriber-interface, it is not possible to stop advertising these
subnets into the provider core in the case where only a subset of the group interfaces are down or
the associated SRRP instances are in backup. The advertisement of the subscriber subnet could
therefore attract traffic to the 7750/7710 SR, which is not the SRRP master.
In these cases, traffic must be sent to the SRRP active 7750/7710 SR in order to be forwarded to
the subscriber. This is achieved through the configuration of a redundant interface between to two
SRRP peers, which protects against failures of the related group interfaces.
The redundant interface is configured under the IES/VRPN service. It must use a single
pseudowire, configured as a spoke SDP, to provide connectivity to the peer 7750/7710 SR. This is
essential as it avoids any possibility of the traffic being misrouted by any other system between the
two peers. It can either use a /31 IP subnet mask or a longer mask with the remote IP being
explicitly specified.
*A:BNG-2>config>service>vprn# info
-------------------------------------------------snip---redundant-interface "bng-2-bng-1-vprn-1" create
address 192.168.4.1/31
spoke-sdp 21:1 create
exit
exit

If non /31 address is used, the remote IP address will be required.


*A:BNG-2>config>service>vprn# redundant-interface "bng-2-bng-1-vprn-1"
*A:BNG-2>config>service>vprn>red-if# address 192.168.4.1/30
INFO: PIP #1399 Invalid or unspecified remote IP address - Non /31 address requires
remote IP address

The remote-ip address can be defined by the following command:


*A:BNG-2>config>service>vprn>red-if# address 192.168.4.1/30 remote-ip 192.4.1.2

Each group-interface must then be associated with a redundant interface.


group-interface "group-int-1" create
---snip--redundant-interface "bng-2-bng-1-vprn-1"

Page 1980

Advanced Configuration Guide

Subscriber Redundancy for Routed-CO

Only one redundant interface is required for a given IES/VPRN service on each peer, though it is
possible to create multiple redundant interfaces and assign group interfaces to each individually.
Clearly, each redundant interface needs to terminate on a matching redundant interface in the
corresponding peer service.
When traffic arrives from the core network for an active subscriber on a SAP in group-interface
group-int-1, and if the associated SRRP instance is in the backup state, then this traffic will be
forwarded over the redundant-interface bng-2-bng-1-vprn-1 to the peer 7750/7710 SR. It will
then be forward to the subscriber as the associated SRRP instance will be in the master state.
The information about the redundant interfaces is mirrored through MCS as part of the SRRP
synchronization.

Advanced Configuration Guide

Page 1981

Configuration

Show and Debug Commands


Routing Table Related Information
A host route (/32) for its IP address is inserted in the IP FIB pointing toward the appropriate
group-interface.
*A:BNG-2# show router 1 route-table
===============================================================================
Route Table (Service: 1)
===============================================================================
Dest Prefix
Type
Proto
Age
Pref
Next Hop[Interface Name]
Metric
------------------------------------------------------------------------------10.2.0.3/32
Remote Sub Mgmt 22h56m34s
0
[group-int-1]
0
---snip---

The same subscriber on the backup peer will have a host route in the IP FIB pointing to the
redundant interface.
*B:BNG-1# show router 1 route-table
===============================================================================
Route Table (Service: 1)
===============================================================================
Dest Prefix
Type
Proto
Age
Pref
Next Hop[Interface Name]
Metric
------------------------------------------------------------------------------0
10.2.0.3/32
Remote Sub Mgmt 22h51m06s
0
[bng-1-bng-2-vprn-1]
0
---snip---

Page 1982

Advanced Configuration Guide

Subscriber Redundancy for Routed-CO

Subscriber Related Information


To check the subscriber information:
*A:BNG-2# show service id 1 subscriber-hosts
===============================================================================
Subscriber Host table
===============================================================================
Sap
IP Address
MAC Address
PPPoE-SID Origin
Subscriber
Fwding state
------------------------------------------------------------------------------1/1/3:1
10.2.0.3
00:00:00:00:00:01 N/A
Static
static-host-routed-*
Fwding

To check the subscriber details:


*A:BNG-2# show service id 1 subscriber-hosts detail
===============================================================================
Subscriber Host table
===============================================================================
Sap
IP Address
MAC Address
PPPoE-SID Origin
Subscriber
Fwding state
------------------------------------------------------------------------------1/1/3:1
10.2.0.3
00:00:00:00:00:01 N/A
Static
static-host-routed-*
Fwding
------------------------------------------------------------------------------Subscriber-interface : sub-int-1
Group-interface
: group-int-1
Sub Profile
: sub-profile-1
SLA Profile
: sla-profile-1
App Profile
: N/A
-------------------------------------------------------------------------------

The same command on the peer would show the same information except for the port identifier
part of the SAP, which is specific to the peer and may differ.

Advanced Configuration Guide

Page 1983

Configuration

MCS Redundancy Related Information


The high-level state of MCS can be seen in the following output:
*A:BNG-2# show redundancy multi-chassis all
===============================================================================
Multi-Chassis Peers
===============================================================================
Peer IP
Src IP
Auth
Peer Admin
MC-Ring Oper MC-EP Adm
MCS Admin
MCS Oper
MCS State MC-LAG Adm
MC-LAG Oper
------------------------------------------------------------------------------192.0.2.1
192.0.2.2
hash2
Enabled
unknown
-Enabled
Enabled
inSync
Disabled
Disabled
===============================================================================
*A:BNG-2#

Information about the peering, the use of authentication, the state of MCS (Enabled) and the fact
that MCS is inSync is shown.
*A:BNG-2# show redundancy multi-chassis sync
===============================================================================
Multi-chassis Peer Table
===============================================================================
Peer
------------------------------------------------------------------------------Peer IP Address
: 192.0.2.1
Description
: (Not Specified)
Authentication
: Enabled
Source IP Address
: 192.0.2.2
Admin State
: Enabled
------------------------------------------------------------------------------Sync-status
------------------------------------------------------------------------------Client Applications
: SUBMGMT SRRP
Sync Admin State
: Up
Sync Oper State
: Up
DB Sync State
: inSync
Num Entries
: 6
Lcl Deleted Entries
: 0
Alarm Entries
: 0
Rem Num Entries
: 6
Rem Lcl Deleted Entries : 0
Rem Alarm Entries
: 0
===============================================================================
*A:BNG-2#

Page 1984

Advanced Configuration Guide

Subscriber Redundancy for Routed-CO

In the output, it can be seen that SUBMGMT and SRRP are the client applications and they are
inSync with six database entries both on this peer and the remote peer.
If the above command included the detailed output for peer 192.0.2.1, the following additional
information would be shown.
*A:BNG-2# show redundancy multi-chassis sync peer 192.0.2.1 detail
===============================================================================
Multi-chassis Peer Table
===============================================================================
Peer
------------------------------------------------------------------------------Peer IP Address
: 192.0.2.1
Description
: (Not Specified)
Authentication
: Enabled
Source IP Address
: 192.0.2.2
Admin State
: Enabled
------------------------------------------------------------------------------Sync-status
---------------------------------------------------------------------------------snip--Application
: srrp
Num Entries
: 6
Lcl Deleted Entries
: 0
Alarm Entries
: 0
------------------------------------------------------------------------------Rem Num Entries
: 6
Rem Lcl Deleted Entries : 0
Rem Alarm Entries
: 0
---------------------------------------------------------------------------------snip--===============================================================================
Ports synced on peer 192.0.2.1
===============================================================================
Port/Encap
Tag
------------------------------------------------------------------------------1/1/3
1-2
srrp1
===============================================================================
---snip--

Advanced Configuration Guide

Page 1985

Configuration

This shows that there are six entries on both peers for SRRP.
If the delayed-enable parameter is configured under the subscriber-interface, in order to allow time
for the MCS to fully synchronize, its setting and current expiry time can be seen as follows:
*A:BNG-2# show service id 1 interface sub-int-1 detail
===============================================================================
Interface Table
===============================================================================
Interface
------------------------------------------------------------------------------If Name
: sub-int-1
Admin State : Up
Oper (v4/v6)
: Up/-Protocols
: None
IP Addr/mask : 10.2.0.2/16
IP Addr/mask : 10.3.0.2/16
IP Addr/mask : 10.4.0.2/16
------------------------------------------------------------------------------Details
------------------------------------------------------------------------------Description : (Not Specified)
If Index
: 2
Virt. If Index
: 2
Last Oper Chg: 12/15/2009 15:14:43
Global If Index : 125
Delay IfUp
: 1200 init-only
If Type
: VPRN Sub
DHCP Details
Gi-Addr
: Not configured
Gi-Addr as Src Ip: Disabled
===============================================================================
Interface sub-int-1 group-interfaces
===============================================================================
Interface-Name
Adm
Opr(v4/v6) Mode
Port/SapId
IP-Address
PfxState
------------------------------------------------------------------------------group-int-1
Up
Up/-VPRN G* 1/1/3

Page 1986

Advanced Configuration Guide

Subscriber Redundancy for Routed-CO

Tool Dump Commands Related Information


The database entries can be view in more detail with the tools dump redundancy multi-chassis
command.
*A:BNG-2# tools dump redundancy multi-chassis sync-database ?
The following totals are for:
peer ip ALL, port/lag ALL, sync-tag ALL, application ALL
Valid Entries:
6
Locally Deleted Entries:
0
Locally Deleted Alarmed Entries: 0

The output of the tool dump redundancy multi-chassis command.


*A:BNG-2# tools dump redundancy multi-chassis srrp-sync-database
Tag Key: sap = 1/1/3:2
Key Info: (Type/Owner)
SMK_BASE_CONFIG / 192.0.2.1
Data Info:
srrpId: 1
svcId: 1
svcType: VPRN
system IP: 0xc0000201
Group interface MAC: 00:03:fa:90:f8:6a
Gateway MAC: 00:00:5e:00:01:01
Subscriber interface name: sub-int-1
Tag Key: sap = 1/1/3:2
Key Info: (Type/Owner)
SMK_BASE_CONFIG / 192.0.2.2
Data Info:
srrpId: 1
svcId: 1
svcType: VPRN
system IP: 0xc0000202
Group interface MAC: 00:03:fa:56:9e:96
Gateway MAC: 00:00:5e:00:01:01
Subscriber interface name: sub-int-1
Tag Key: sap = 1/1/3:2
Key Info: (Type/Owner)
SMK_GRP_IF / 192.0.2.1
Data Info:
Group interface name: group-int-1
Group Interface Sap (Tag/Encap): srrp1/2
Group Interface Sap (Tag/Encap): srrp1/1
Redundant interface name: bng-1-bng-2-vprn-1
Redundant Interface IP/Mask:
IP: 0xc0a80400 Mask: 0xfffffffe
AdminUp: Up, OperState: SRRP_STATE_BACKUP_SHUNT, InUsePriority: 200, Red-If OK:
Yes, MessageSap OK: Yes
Tag Key: sap = 1/1/3:2
Key Info: (Type/Owner)
SMK_GRP_IF / 192.0.2.2
Data Info:
Group interface name: group-int-1
Group Interface Sap (Tag/Encap): srrp1/2
Group Interface Sap (Tag/Encap): srrp1/1
Redundant interface name: bng-2-bng-1-vprn-1
Redundant Interface IP/Mask:
IP: 0xc0a80401 Mask: 0xfffffffe
AdminUp: Up, OperState: SRRP_STATE_MASTER, InUsePriority: 250, Red-If OK: Yes,

Advanced Configuration Guide

Page 1987

Configuration

MessageSap OK: Yes


Tag Key: sap = 1/1/3:2
Key Info: (Type/Owner)
SMK_SUBNET_INFO / 192.0.2.1 vRtrId 2, ifIdx 2
Data Info:
Subscriber IP Addr: 10.2.0.1
Mask: 0xffff0000
Subscriber IP Addr: 10.3.0.1
Mask: 0xffff0000
Subscriber IP Addr: 10.4.0.1
Mask: 0xffff0000

Gateway: 10.2.0.254
Gateway: 10.3.0.254
Gateway: 10.4.0.254

Tag Key: sap = 1/1/3:2


Key Info: (Type/Owner)
SMK_SUBNET_INFO / 192.0.2.2 vRtrId 2, ifIdx 2
Data Info:
Subscriber IP Addr: 10.2.0.2
Mask: 0xffff0000
Subscriber IP Addr: 10.3.0.2
Mask: 0xffff0000
Subscriber IP Addr: 10.4.0.2
Mask: 0xffff0000

Gateway: 10.2.0.254
Gateway: 10.3.0.254
Gateway: 10.4.0.254

Also shown are the port/VLANs synchronized with their respective sync-tags.
To further troubleshoot and debug this configuration, there are commands to both dump the sync
and SRRP MCS information and to dump the SRRP database:
tools dump redundancy multi-chassis sync-database [application {sub-mgmt|srrp}]

The command provides the same information as the equivalent show commands. However, the
detailed version gives more information about the contents of the sync-database.
For SRRP, there are entries for the base configuration, group interface and subnet information for
each of the SRRP instances. This should show corresponding entries for the local and remote peer.
Specifying the sync-tag srrp1 shows only the information for SRRP instance 1.
*A:BNG-2# tools dump redundancy multi-chassis sync-database application srrp sync-tag
srrp1 detail
If no entries are present for an application, no detail will be displayed.
FLAGS LEGEND: ld - local delete; da - delete alarm
Peer Ip 192.0.2.1

Application SRRP
Sap-id
Client Key
SyncTag
DLen Flags timeStamp
deleteReason code and description
------------------------------------------------------------------------------1/1/3:2
SMK_BASE_CONFIG / 192.0.2.1
srrp1
88
-- -- 12/15/2009 15:52:18
0x0
1/1/3:2
SMK_BASE_CONFIG / 192.0.2.2
srrp1
88
-- -- 12/15/2009 15:51:57
0x0
1/1/3:2
SMK_GRP_IF / 192.0.2.1

Page 1988

Advanced Configuration Guide

Subscriber Redundancy for Routed-CO

srrp1
0x0
1/1/3:2
srrp1
0x0
1/1/3:2
srrp1
0x0
1/1/3:2
srrp1
0x0

260

-- -- 12/16/2009 16:10:50

SMK_GRP_IF / 192.0.2.2
260
-- -- 12/16/2009 16:10:50
SMK_SUBNET_INFO / 192.0.2.1 vRtrId 2, ifIdx 2
40
-- -- 12/15/2009 15:52:18
SMK_SUBNET_INFO / 192.0.2.2 vRtrId 2, ifIdx 2
40
-- -- 12/15/2009 15:51:57

The following totals are for:


peer ip ALL, port/lag ALL, sync-tag ALL, application SRRP
Valid Entries:
6
Locally Deleted Entries:
0
Locally Deleted Alarmed Entries: 0

This same information can be seen in more detail by dumping the SRRP database. This output is
for SRRP instance 1, and shows the detailed information for each peer. This should clearly reflect
the configuration and current state of the SRRP instances. Again there are two entries (one for the
local peer and the other for the remote peer) for the BASE_CONFIG, GRP_IF and
SUBNET_INFO.
*A:BNG-2# tools dump redundancy multi-chassis srrp-sync-database instance 1
Tag Key: sap = 1/1/3:2
Key Info: (Type/Owner)
SMK_BASE_CONFIG / 192.0.2.1
Data Info:
srrpId: 1
svcId: 1
svcType: VPRN
system IP: 0xc0000201
Group interface MAC: 00:03:fa:90:f8:6a
Gateway MAC: 00:00:5e:00:01:01
Subscriber interface name: sub-int-1
Tag Key: sap = 1/1/3:2
Key Info: (Type/Owner)
SMK_BASE_CONFIG / 192.0.2.2
Data Info:
srrpId: 1
svcId: 1
svcType: VPRN
system IP: 0xc0000202
Group interface MAC: 00:03:fa:56:9e:96
Gateway MAC: 00:00:5e:00:01:01
Subscriber interface name: sub-int-1
Tag Key: sap = 1/1/3:2
Key Info: (Type/Owner)
SMK_GRP_IF / 192.0.2.1
Data Info:
Group interface name: group-int-1
Group Interface Sap (Tag/Encap): srrp1/2
Group Interface Sap (Tag/Encap): srrp1/1
Redundant interface name: bng-1-bng-2-vprn-1
Redundant Interface IP/Mask:
IP: 0xc0a80400 Mask: 0xfffffffe
AdminUp: Up, OperState: SRRP_STATE_BACKUP_SHUNT, InUsePriority: 200, Red-If OK:
Yes, MessageSap OK: Yes
Tag Key:

sap = 1/1/3:2

Advanced Configuration Guide

Page 1989

Configuration

Key Info: (Type/Owner)


SMK_GRP_IF / 192.0.2.2
Data Info:
Group interface name: group-int-1
Group Interface Sap (Tag/Encap): srrp1/2
Group Interface Sap (Tag/Encap): srrp1/1
Redundant interface name: bng-2-bng-1-vprn-1
Redundant Interface IP/Mask:
IP: 0xc0a80401 Mask: 0xfffffffe
AdminUp: Up, OperState: SRRP_STATE_MASTER, InUsePriority: 250, Red-If OK: Yes,
MessageSap OK: Yes
Tag Key: sap = 1/1/3:2
Key Info: (Type/Owner)
SMK_SUBNET_INFO / 192.0.2.1 vRtrId 2, ifIdx 2
Data Info:
Subscriber IP Addr: 10.2.0.1
Mask: 0xffff0000
Subscriber IP Addr: 10.3.0.1
Mask: 0xffff0000
Subscriber IP Addr: 10.4.0.1
Mask: 0xffff0000

Gateway: 10.2.0.254
Gateway: 10.3.0.254
Gateway: 10.4.0.254

Tag Key: sap = 1/1/3:2


Key Info: (Type/Owner)
SMK_SUBNET_INFO / 192.0.2.2 vRtrId 2, ifIdx 2
Data Info:
Subscriber IP Addr: 10.2.0.2
Mask: 0xffff0000
Subscriber IP Addr: 10.3.0.2
Mask: 0xffff0000
Subscriber IP Addr: 10.4.0.2
Mask: 0xffff0000

Gateway: 10.2.0.254
Gateway: 10.3.0.254
Gateway: 10.4.0.254

The following is an example of error messages that could be seen due to this synchronization
which otherwise without it would not be available.
An event will be generated in log 99, if the IP address was removed from the redundant interface
on the remote peer.
10 2009/12/16 16:08:50.55 UTC WARNING: MC_REDUNDANCY #2012 vprn1 SRRP/MCS: Peer Red i/
f down
"SRRP ID 1: Redundant interface bng-2-bng-1-vprn-1 on peer 192.0.2.2 / interface
group-int-1 does not match local 192.0.2.1 / interface group-int-1."
9 2009/12/16 16:08:50.54 UTC MINOR: MC_REDUNDANCY #2024 vprn1 Become Backup-Route
"SRRP instance 1 on interface group-int-1 changed state to backup - current master is
192.0.2.2"
8 2009/12/16 16:08:50.53 UTC WARNING: MC_REDUNDANCY #2012 vprn1 SRRP/MCS: Peer Red i/
f no addr
"SRRP ID 1: Redundant interface bng-2-bng-1-vprn-1 on peer 192.0.2.2 / interface
group-int-1 does not match local 192.0.2.1 / interface group-int-

Page 1990

Advanced Configuration Guide

Subscriber Redundancy for Routed-CO

The SRRP Instance Related Information


The SRRP instance information can be displayed by the following commands:
The master BNS shows the master in the operation status.
*A:BNG-2# show srrp
===============================================================================
SRRP Table
===============================================================================
ID
Service
Group Interface
Admin
Oper
------------------------------------------------------------------------------1
1
group-int-1
Up
master
------------------------------------------------------------------------------No. of SRRP Entries: 1
===============================================================================
*A:BNG-2#

The backup BNG shows a backupShunt in the operation status.


*B:BNG-1# show srrp
===============================================================================
SRRP Table
===============================================================================
ID
Service
Group Interface
Admin
Oper
------------------------------------------------------------------------------1
1
group-int-1
Up
backupShunt
------------------------------------------------------------------------------...
===============================================================================
*B:BNG-1#

To check detailed information:


*A:BNG-2# show srrp 1 detail
===============================================================================
SRRP Instance 1
===============================================================================
Description
: (Not Specified)
Admin State
: Up
Oper State
: master
System IP
: 192.0.2.2
Service ID
: VPRN 1
Group If
: group-int-1
MAC Address
: 00:03:fa:56:9e:96
Grp If Description:N/A
Grp If Admin State : Up
Grp If Oper State: Up
Subscriber If
: sub-int-1
Sub If Admin State : Up
Sub If Oper State: Up
Address
: 10.2.0.2/16
Gateway IP
: 10.2.0.254
Address
: 10.3.0.2/16
Gateway IP
: 10.3.0.254
Address
: 10.4.0.2/16
Gateway IP
: 10.4.0.254
Redundant If
: bng-2-bng-1-vprn-1
Red If Admin State : Up
Red If Oper State: Up
Address
: 192.168.4.1/31
Red Spoke-sdp
: 21:1

Advanced Configuration Guide

Page 1991

Configuration

Msg Path SAP


: 1/1/3:2
Admin Gateway MAC
:
Oper Gateway MAC : 00:00:5e:00:01:01
Config Priority
: 250
In-use Priority : 250
Master Priority
: 250
Keep-alive Interval : 1 deci-seconds
Master Since
: 12/16/2009 10:42:31
VRRP Policy 1
: None
VRRP Policy 2
: None
------------------------------------------------------------------------------BFD interface
------------------------------------------------------------------------------Service ID
: 2
Interface Name
: bfd-1
Src IP
: 10.1.1.0
Dst IP
: 10.1.1.1
Session Oper State : connected
------------------------------------------------------------------------------Statistics
------------------------------------------------------------------------------Become Master
: 1
Master Changes
: 1
Become Bkup Routing : 0
Become Bkup Shunt: 1
Become Non-Master
: 0
Adv Sent
: 197854
Adv Received
: 685948
Pri 0 Pkts Sent
: 0
Pri 0 Pkts Rcvd : 0
Preempt Events
: 1
Preempted Events : 0
Mesg Intvl Discards : 0
Mesg Intvl Errors: 0

If this output is shown on the SRRP backup, an extra line appears after the keep-alive-interval
showing the interval during which the receipt of no SRRP messages would cause the master to be
considered down, together with the instantaneous time to this interval expiring.
Master Down Interval: 0.300 sec (Expires in 0.250 sec)

Page 1992

Advanced Configuration Guide

Subscriber Redundancy for Routed-CO

Monitoring the Traffic on Redundant Interface


The Oper State reflects both the state of the SRRP instance and its action with respect to the
redundant interface. Specifically, when the peer is SRRP master the operational state is always
master traffic is sent directly to the subscriber over its associated SAP. If the peer is SRRP
backup and the redundant interface is Up then the Oper State will be backupShunt, if the
redundant interface is down then the Oper State is backupRouting. In the backupShunt state,
traffic to the subscriber is shunted (for example, forwarded) across the redundant interface to the
peer (to the master) in order to be forwarded to the subscriber.
When in the backupRouting state, the SRRP instance is in backup but the redundant interface is
down, so the traffic is forwarded directly to the subscriber through its associated SAP.
A useful command to see the traffic on the redundant interface is:
*A:BNG-2# monitor service id 1 sdp 21:1 rate interval 11 repeat 3
===============================================================================
Monitor statistics for Service 1 SDP binding 21:1
===============================================================================
------------------------------------------------------------------------------At time t = 0 sec (Base Statistics)
------------------------------------------------------------------------------I. Fwd. Pkts.
: 19517656
I. Dro. Pkts.
: 13
E. Fwd. Pkts.
: 14
E. Fwd. Octets : 1090
------------------------------------------------------------------------------At time t = 11 sec (Mode: Rate)
------------------------------------------------------------------------------I. Fwd. Pkts.
: 1000
I. Dro. Pkts.
: 0
E. Fwd. Pkts.
: 0
E. Fwd. Octets : 0
---snip---

BFD-Related Information
To check the BFD session state.
*A:BNG-2# show router bfd session
===============================================================================
BFD Session
===============================================================================
Interface
State
Tx Intvl Rx Intvl Mult
Remote Address
Protocol
Tx Pkts
Rx Pkts
------------------------------------------------------------------------------bfd-1
Up (3)
100
100
3
10.1.1.1
srrp
875616
874287
------------------------------------------------------------------------------No. of BFD sessions: 1
===============================================================================
*A:BNG-2#

Advanced Configuration Guide

Page 1993

Configuration

To check the MAC addresses of the SRRP, this is can be done by checking the MACs table in the
BSAN.
*A:dslam# show service fdb-mac
===============================================================================
Service Forwarding Database
===============================================================================
ServId
MAC
Source-Identifier
Type/Age Last Change
------------------------------------------------------------------------------1
00:00:00:00:00:01 sap:1/1/4:1
L/0
12/16/2009 17:35:29
1
00:00:5e:00:01:01 sap:1/1/1:1
L/0
12/16/2009 17:35:29
2
00:00:5e:00:01:01 sap:1/1/1:2
L/0
12/16/2009 16:45:17
3
00:03:fa:56:9e:96 sap:1/1/1:3
L/0
12/16/2009 16:04:00
3
00:03:fa:90:f8:6a sap:1/1/2:3
L/0
12/16/2009 16:04:05
------------------------------------------------------------------------------No. of Entries: 5
===============================================================================
*A:dslam#

The first entry shows the source MAC address of SRRP 1 which is learned through the SRRP
messages received from the SRRP master for that instance. The next two entries relate to the
subscriber traffic to and from sub1. Note that the 7750/7710 SR source MAC address is that of the
SRRP instance.
The last two entries are the source MAC address BFD received from each BNG.

Page 1994

Advanced Configuration Guide

Subscriber Redundancy for Routed-CO

SRRP Debug Commands


There are debug command to show the SRRP protocol events and packets.
*A:BNG-2# debug router 1 srrp events
*A:BNG-2# debug router 1 srrp packets

To display the debugging information, a dedicated log should be created:


*A:BNG-2# configure log
log-id 1
from debug-trace
to session
exit

The following output displays a sample SRRP debug log:


109 2009/12/16 16:21:57.87 UTC MINOR: DEBUG #2001 vprn1 SRRP
"SRRP: Sending Pkt
Version (SRRP)
Type
Vr Id
Priority
Count Ip Addresses
Advertise Interval
Checksum

:
:
:
:
:
:
:

8
Advertisement (1)
1
250
3
10 centi-second
0x25ef

Raw Pkt:
81 00 fa 00 00 00 00 01 00 00 5e 00 01 01 00 0a
00 03 25 ef "

Example:
Change the state of BNG-1 by receiving a higher SRRP priority from BNG-2 if the SRRP priority
in BNG-1 is higher than the configured one in BNG-2.
In the following output, this peer is the SRRP master for instance one 1 and is sending SRRP
messages, it then receives an SRRP message with a higher priority (254) from its peer. This causes
an event Become Pending-Backup Shunt where it prepares to transition to the backup state. To
achieve this, it sends and SRRP message with priority 0. If it continues to receive SRRP messages
(with priority 254) from its peer, then passes into the backup state with the event Become Backup
Shunt.
646 2009/12/16 18:06:47.77 UTC MINOR: DEBUG #2001 vprn1 SRRP
"SRRP: Sending Pkt
Version (SRRP)
Type
Vr Id
Priority
Count Ip Addresses

Advanced Configuration Guide

:
:
:
:
:

8
Advertisement (1)
1
250
3

Page 1995

Configuration

Advertise Interval : 10 centi-second


Checksum
: 0x25ef
Raw Pkt:
81 00 fa 00 00 00 00 01 00 00 5e 00 01 01 00 0a
00 03 25 ef "

647 2009/12/16 18:06:47.77 UTC MINOR: DEBUG #2001 vprn1 SRRP


"SRRP: Receiving Pkt
Version (SRRP)
Type
Vr Id
Priority
Count Ip Addresses
Advertise Interval
Checksum

:
:
:
:
:
:
:

8
Advertisement (1)
1
254
3
10 centi-second
0x21ee

Raw Pkt:
81 01 fe 00 00 00 00 01 00 00 5e 00 01 01 00 0a
00 03 21 ee "

648 2009/12/16 18:06:47.77 UTC MINOR: DEBUG #2001 vprn1 SRRP


"SRRP: Event
Become Pending-Backup Shunt: vRtrId 2, ifIdx 3, IPv4 vr_id 1, Master IP 192.0.2.
1"

649 2009/12/16 18:06:47.78 UTC MINOR: DEBUG #2001 vprn1 SRRP


"SRRP: Sending Pkt
Version (SRRP)
Type
Vr Id
Priority
Count Ip Addresses
Advertise Interval
Checksum

:
:
:
:
:
:
:

8
Advertisement (1)
1
0
3
10 centi-second
0x1ff0

Raw Pkt:
81 00 00 00 00 00 00 01 00 00 5e 00 01 01 00 0a
00 03 1f f0 "

650 2009/12/16 18:06:47.78 UTC MINOR: DEBUG #2001 vprn1 SRRP


"SRRP: Receiving Pkt
Version (SRRP)
Type
Vr Id
Priority
Count Ip Addresses
Advertise Interval
Checksum

Page 1996

:
:
:
:
:
:
:

8
Advertisement (1)
1
254
3
10 centi-second
0x21ef

Advanced Configuration Guide

Subscriber Redundancy for Routed-CO

Raw Pkt:
81 00 fe 00 00 00 00 01 00 00 5e 00 01 01 00 0a
00 03 21 ef "

651 2009/12/16 18:06:47.78 UTC MINOR: DEBUG #2001 vprn1 SRRP


"SRRP: Event
Become Backup Shunt: vRtrId 2, ifIdx 3, IPv4 vr_id 1, Master IP 192.0.2.1"

652 2009/12/16 18:06:47.78 UTC MINOR: DEBUG #2001 vprn1 SRRP


"SRRP: Receiving Pkt
Version (SRRP)
Type
Vr Id
Priority
Count Ip Addresses
Advertise Interval
Checksum

:
:
:
:
:
:
:

8
Advertisement (1)
1
254
3
10 centi-second
0x21ef

Raw Pkt:
81 00 fe 00 00 00 00 01 00 00 5e 00 01 01 00 0a
00 03 21 ef "

The output for the SRRP message captured with wireshark .


No.

Time
1 0.000000

Source
192.0.2.2

Destination
224.0.0.18

Protocol Info
VRRP
Announcement (v8)

Frame 1 (68 bytes on wire, 68 bytes captured)


Ethernet II, Src: IETF-VRRP-virtual-router-VRID_01 (00:00:5e:00:01:01), Dst:
IPv4mcast_00:00:12 (01:00:5e:00:00:12)
Destination: IPv4mcast_00:00:12 (01:00:5e:00:00:12)
Address: IPv4mcast_00:00:12 (01:00:5e:00:00:12)
.... ...1 .... .... .... .... = IG bit: Group address (multicast/broadcast)
.... ..0. .... .... .... .... = LG bit: Globally unique address (factory
default)
Source: IETF-VRRP-virtual-router-VRID_01 (00:00:5e:00:01:01)
Address: IETF-VRRP-virtual-router-VRID_01 (00:00:5e:00:01:01)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
.... ..0. .... .... .... .... = LG bit: Globally unique address (factory
default)
Type: 802.1Q Virtual LAN (0x8100)
802.1Q Virtual LAN, PRI: 0, CFI: 0, ID: 2
000. .... .... .... = Priority: 0
...0 .... .... .... = CFI: 0
.... 0000 0000 0010 = ID: 2
Type: 802.1Q Virtual LAN (0x8100)
802.1Q Virtual LAN, PRI: 0, CFI: 0, ID: 2
000. .... .... .... = Priority: 0
...0 .... .... .... = CFI: 0
.... 0000 0000 0010 = ID: 2

Advanced Configuration Guide

Page 1997

Configuration

Type: IP (0x0800)
Trailer: 000066BD5035
Internet Protocol, Src: 192.0.2.2 (192.0.2.2), Dst: 224.0.0.18 (224.0.0.18)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0xc0 (DSCP 0x30: Class Selector 6; ECN: 0x00)
Total Length: 40
Identification: 0x0139 (313)
Flags: 0x00
Fragment offset: 0
Time to live: 255
Protocol: VRRP (0x70)
Header checksum: 0x1758 [correct]
[Good: True]
[Bad : False]
Source: 192.0.2.2 (192.0.2.2)
Destination: 224.0.0.18 (224.0.0.18)
Virtual Router Redundancy Protocol
Version 8, Packet type 1 (Advertisement)
1000 .... = VRRP protocol version: 8
.... 0001 = VRRP packet type: Advertisement (1)
Virtual Rtr ID: 0
Priority: 250 (Non-default backup priority)
Count IP Addrs: 0
Auth Type: No Authentication (0)
Adver Int: 0
Checksum: 0x0001 [correct]

Page 1998

Advanced Configuration Guide

Subscriber Redundancy for Routed-CO

SRRP Traffic Marking


The SRRP messages are sent by default with DSCP of nc1 and with 802.1p bits of 0.
802.1Q Virtual LAN, PRI: 0, CFI: 0, ID: 100
000. .... .... .... = Priority: 0
...0.... .... .... = CFI: 0
.... 0000 0110 0100 = ID: 100
Type: 802.1Q Virtual LAN (0x8100)
Internet Protocol, Src: 10.10.10.3 (10.10.10.3), Dst: 224.0.0.18 (224.0.0.18)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0xc0 (DSCP 0x30: Class Selector 6; ECN: 0x00)
*A:BNG-2# show qos dscp-table
===========================================================
DSCP Mapping
===========================================================
DSCP Name
DSCP Value
TOS (bin)
TOS (hex)
----------------------------------------------------------nc1
48
1100 0000
C0

Where DSCP 0x30=48 (DSCP value). This can be changed to EF, for example, using the
following command:
*A:BNG-2# configure service vprn 1 sgt-qos application srrp dscp ef

Advanced Configuration Guide

Page 1999

Conclusion

Conclusion
This section provides configuration and troubleshooting commands for SRRP with static (IPMAC) host in a Layer 3 Routed-CO (IES/VPRN subscriber interface) context.

Page 2000

Advanced Configuration Guide

Synchronous Ethernet

In This Chapter
This section provides information about Synchronous Ethernet (SyncE).
Topics in this section include:

Applicability on page 2002

Summary on page 2003

Overview on page 2004

Configuration on page 2011

Conclusion on page 2018

Advanced Configuration Guide

Page 2001

Applicability

Applicability
This example is applicable to all of the 7750 SR, 7710 SR and 7450 ESS series, except for the SR1 and ESS-1, and was tested on release 8.0r7. There are no software pre-requisites for this
configuration, however, the hardware requires the use of Synchronous Ethernet capable MDAXPs/CMA-XPs or the IMMs.
In addition, Synchronous Ethernet is only supported on optical interfaces. It is not supported on
10/100/1000 base copper interfaces.

Page 2002

Advanced Configuration Guide

Synchronous Ethernet

Summary
Synchronous Ethernet (SyncE) is the ability to provide PHY-level frequency distribution through
an Ethernet port. It is one of the building blocks of Next Generation Networks (NGNs).

Advanced Configuration Guide

Page 2003

Overview

Overview
Synchronous Ethernet
Traditionally, Ethernet based networks employ the physical layer transmitter clock to be derived
from an inexpensive +/-100ppm crystal oscillator and the receiver locks onto it. There is no need
for long term frequency stability as the data is packetized and can be buffered. For the same reason
there is no need for consistency between the frequencies of different links. However one could
elect to derive the physical layer transmitter clock from a high quality frequency reference by
replacing the crystal with a frequency source traceable to a primary reference clock. This would
not affect the operation of any of the Ethernet layers, for which this change would be transparent.
The receiver at the far end of the link would lock onto the physical layer clock of the received
signal, and thus itself gain access to a highly accurate and stable frequency reference. Then, in a
manner analogous to conventional hierarchical master-slave network synchronization, this
receiver could lock the transmission clock of its other ports to this frequency reference and a fully
time synchronous network could be established.
The advantage of using SyncE, as compared to methods relying on sending timing information in
packets over an unlocked physical layer, is that SyncE is not influenced by impairments
introduced by the higher levels of the networking technology (packet loss, packet delay variation).
Hence, the frequency accuracy and stability may be expected to exceed those of networks with
unsynchronized physical layers. In addition, SyncE was designed to integrate into any existing
SONET/SDH synchronization distribution architecture to allow for the easy migration from the
traditional to the new synchronous interfaces. SyncE includes the concept of a Hybrid Switch
which supports the interworking of synchronization distribution through SONET/SDH and the
SyncE interfaces at the same time.

SSU

SSU

S
S

S
E

S
E

S
H

S
S

S
H

S
S: SDH
E: Eth
H: Hybrid

SSU

S
E

S
S

SSU

SSU

SSU

a)

b)

c)
OSSG567

Figure 204: SyncE Hypothetical Reference Network Architecture

Page 2004

Advanced Configuration Guide

Synchronous Ethernet

Many Tier 1 carriers are looking to migrate their synchronization infrastructure to a familiar and
manageable model. In order to enable rapid migration of these networks, SyncE may be the easiest
to deploy in order to ensure robust frequency synchronization.

Advanced Configuration Guide

Page 2005

Overview

Quality Level
Override
Qualifier

Ref 1
T1/E1,
SONET/SDH
SyncE, ACR
Ref 2

Qualifier

Quality
Level (QL)

Quality
Level (QL)

Reference
Selector
Mode 1) Priority
Reference Order

Mode 2) QL Then
T1/E1

BITSin

T1/E1

BITSin

Qualifier

Quality
Level (QL)

Qualifier

Quality
Level (QL)

Priority Reference
Order

BITS - Out

Digital Phase
Locked Loop
(DPLL)

Internal
(Node)
Timing
Reference

OSSG569

Figure 205: Packet Based Network Timing Infrastructure

Central Synchronization Sub-System


The timing subsystem for the SR/ESS platforms has a central clock located on the Control
Processor Module (CPM). The timing subsystem performs many of the duties of the network
element clock as defined by Telcordia (GR-1244) and ITU-T G.781.
The system can select from up to four timing inputs to train the local oscillator. The priority order
of these references must be specified. This is a simple ordered list of inputs: {BITS [Building
Integrated Timing Source], ref1, ref2}. The CPM clock output has the ability to drive the clocking
for all line cards in the system. The SR/ESS supports selection of the node reference using Quality
Level (QL) indications.

Page 2006

Advanced Configuration Guide

Synchronous Ethernet

Quality Level
Override
Qualifier

Ref 1
T1/E1,
SONET/SDH
SyncE, ACR
Ref 2

Qualifier

Quality
Level (QL)

Quality
Level (QL)

Reference
Selector
Mode 1) Priority
Reference Order

Mode 2) QL Then
T1/E1

BITSin

T1/E1

BITSin

Qualifier

Quality
Level (QL)

Qualifier

Quality
Level (QL)

Priority Reference
Order

BITS - Out

Digital Phase
Locked Loop
(DPLL)

Internal
(Node)
Timing
Reference

OSSG569

Figure 206: Current 7x50 Timing Sub-System Architecture

BITSin port on Active CPM (7750 SR-7/12, 7450 ESS-7/12) or BITS_1 port on 7750 SR-c4.

BITSin port on Standby CPM (7750 SR-7/12, 7450 ESS-7/12) or BITS_2 port on 7750 SR-c4.

The recovered clock is able to derive its timing from any of the following:

OC3/STM1, OC12/STM4, OC48/STM16, OC192/STM64 ports

T1/E1 CES channel (adaptive clocking)

SyncE ports

T1/E1 ports

BITS port on a Channelized OC3/STM1 CES CMA (7710 SR-c4, 7710 SR-c12, and the
7750 SR-c12)

BITS port on the CPM or CFM module

On 7750 SR-12 and 7750 SR-7 systems with redundant CPMs, the system has two BITS input
ports (one per CPM). On the 7750 SRc-4 systems, there are two BITS input ports on the chassis
front plate. These BITS input ports provide redundant synchronization inputs from an external
BITS/SSU. Note the 7750 SR-c12 does not support BITS input port redundancy or BITS out.
All settings of the signal characteristics for the BITS input apply to both ports. When the active
CPM considers the BITS input as a possible reference, it will consider first the BITS input port on
the active CPM followed the BITS input port on the standby CPM in that relative priority order.
This relative priority order is in addition to the user definable ref-order. For example, a ref-order of
bits-ref1-ref2 would actually be BITS in (active CPM) followed by BITS in (standby CPM)

Advanced Configuration Guide

Page 2007

Overview

followed by ref1 followed by ref2. When ql-selection is enabled, then the QL of each BITS input
port is viewed independently. The higher QL source is chosen.
On the 7750 SR-c4 platform CFM, there are two BITS input ports and two BITS output ports on
this one module. These two ports are provided for BITS redundancy for the chassis. All settings of
the signal characteristics for the BITS input apply to both ports. This includes the ql-override
setting. When the CFM considers the BITS input as a possible reference, it will consider first the
BITS input port bits1 followed the BITS input port bits2 in that relative priority order. This
relative priority order is in addition to the user definable ref-order. For example, a ref-order of
bits-ref1-ref2 would actually be bits1 followed by bits2 followed by ref1 followed by ref2.
When ql-selection is enabled, then the QL of each BITS input port is viewed independently. The
higher QL source is chosen.
The BITS output ports are provided to deliver a unfiltered recovered line clock from a SR/ESS
port directly to a dedicated timing device in the facility (BITS or Standalone Synchronization
Equipment (SASE) device). The signal selected will be one of ref1 or ref2. It cannot be the BITS
input port signal nor can it be the output of the central clock.
When QL selection mode is disabled, then the reversion setting controls when the central clock
can re-select a previously failed reference.

Table 30: Revertive, Non-Revertive Timing Reference Switching Operation

Page 2008

Status of Reference
A

Status of Reference
B

Active Reference
Non-revertive Case

Active Reference
Revertive Case

OK

OK

Failed

OK

OK

OK

OK

Failed

OK

OK

Failed

Failed

holdover

holdover

OK

Failed

Failed

Failed

holdover

holdover

Failed

OK

Failed

Failed

holdover

holdover

OK

OK

A or B

Advanced Configuration Guide

Synchronous Ethernet

Synchronization Status Messages (SSM)


SSM provides a mechanism to allow the synchronization distribution network to both determine
the quality level of the clock sourcing a given synchronisation trail and to allow a network element
to select the best of multiple input synchronization trails. Synchronization Status messages have
been defined for various transport protocols including SONET/SDH, T1/E1, and SyncE, for
interaction with office clocks, such as BITS or SSUs (synchronisation supply unit) and embedded
network element clocks.
SSM allows equipment to autonomously provision and reconfigure (by reference switching) their
synchronization references, while helping to avoid the creation of timing loops. These messages
are particularly useful to allow synchronization reconfigurations when timing is distributed in both
directions around a ring.
In SyncE, the SSM is provided through the Ethernet Synchronization Messaging Channel
(ESMC). This mechanism uses Ethernet OAM PDU to exchange the Quality Level values over the
SyncE link.

Advanced Configuration Guide

Page 2009

Overview

SyncE Chains
Transmission of a reference clock through a chain of Ethernet equipment requires that all of the
equipment support SyncE.
A single piece of equipment not capable of SyncE breaks the chain as shown in Figure 207.
Ethernet frames will still get through but downstream device will recognize that the signal is out of
pull-in range and not use it for reference.

Acceptable for Clock Distribution

E
SSU

SSU
E

Not Acceptable for


Clock Distribution
OSSG570

Figure 207: Network Considerations for Ethernet Timing Distribution

Page 2010

Advanced Configuration Guide

Synchronous Ethernet

Configuration
Configuration 1
The following example shows the configuration options for SyncE when ql-selection mode is
disabled. Generally, North American SONET networks do not use the automatic reference
selection mechanisms. If SyncE is being added into such a network it would likely have qlselection set to disabled.
A:PE-1>config# card 1 mda 1
A:PE-1>config>card>mda#
access
+ Configure access MDA parameters
egress
+ Configure egress MDA parameters
[no] hi-bw-mcast-src - Enable/disable allocation of resources for high
bandwidth multicast streams
ingress
+ Configure ingress MDA parameters
[no] mda-type
- Provisions/de-provisions an MDA to/from the device
configuration for the slot
named-pool-mode + Enable/Disable named pool mode
network
+ Configure network MDA parameters
[no] shutdown
- Administratively shut down an mda
[no] sync-e
- Enable/Disable Synchronous Ethernet
A:PE-1>config>card>mda# sync-e
*A:PE-1>config>card>mda# info detail
--------------------------------------------mda-type m20-1gb-xp-sfp
sync-e
named-pool-mode
ingress
no named-pool-policy
exit
egress
no named-pool-policy
exit
exit
ingress
no hsmda-pool-policy
no scheduler-policy
exit
egress
no hsmda-pool-policy
exit
network
ingress
pool default
...

Advanced Configuration Guide

Page 2011

Configuration

*A:PE-1>config>system# sync-if-timing
*A:PE-1>config>system>sync-if-timing#
abort
- Discard the changes that have been made to sync
interface timing during a session
begin
- Switch to edit mode for sync interface timing - use
commit to save or abort to discard the changes made in
a session
bits
+ Configure parameters for the Building Integrated Timing
Supply(BITS)
commit
- Save the changes made to sync interface timing during a
session
[no] ql-selection
- Enable/disable reference selection based on
quality-level
[no] ref-order
- Priority order of timing references
ref1
+ Configure parameters for the first timing reference
ref2
+ Configure parameters for the second timing reference
[no] revert
- Revert/do not revert to a higher priority re-validated
reference source
*A:PE-1>config>system>sync-if-timing# begin
*A:PE-1>config>system>sync-if-timing# ref-order bits ref1
*A:PE-1>config>system>sync-if-timing# bits input no shutdown
*A:PE-1>config>system>sync-if-timing# bits interface-type ds1 esf
*A:PE-1>config>system>sync-if-timing# revert
*A:PE-1>config>system>sync-if-timing# ref1
*A:PE-1>config>system>sync-if-timing>ref1#
[no] ql-override
- Override the quality level of a timing reference
[no] shutdown
- Administratively shutdown the timing reference
[no] source-port
- Configure the source port for the first timing reference
*A:PE-1>config>system>sync-if-timing>ref1# source-port 1/1/2
*A:PE-1>config>system>sync-if-timing>ref1# no shutdown
*A:PE-1>config>system>sync-if-timing>ref1# exit
*A:PE-1>config>system>sync-if-timing# commit
*A:PE-1>config>system>sync-if-timing# info detail
---------------------------------------------no ql-selection
ref-order bits ref1 ref2
ref1
source-port 1/1/2
no shutdown
no ql-override
exit
ref2
shutdown
no source-port
no ql-override
exit
bits
interface-type ds1 esf
no ql-override
input
no shutdown
exit
output
shutdown
line-length 110
exit
exit
revert

Page 2012

Advanced Configuration Guide

Synchronous Ethernet

The following output displays the associated show information.


*A:PE-1>show>system# sync-if-timing
============================================================================
System Interface Timing Operational Info
============================================================================
System Status CPM A
: Master Locked
Reference Input Mode
: Revertive
Quality Level Selection
: Disabled
Reference Selected
: ref1
System Quality Level
: unknown
Current Frequency Offset (ppm) : -5
Reference Order

: bits ref1 ref2

Reference Mate CPM


Qualified For Use
Not Qualified Due To
Selected For Use
Not Selected Due To

: No
:
: No
:

Reference Input 1
Admin Status
Rx Quality Level
Quality Level Override
Qualified For Use
Selected For Use
Source Port

:
:
:
:
:
:

up
unknown
none
Yes
Yes
1/1/2

Reference Input 2
Admin Status
Rx Quality Level
Quality Level Override
Qualified For Use
Not Qualified Due To
Selected For Use
Not Selected Due To
Source Port

:
:
:
:
:
:
:
:

down
unknown
none
No
disabled
No
disabled
None

LOS
not qualified

Reference BITS A
Input Admin Status
: up
Rx Quality Level
: failed
Quality Level Override
: none
Qualified For Use
: No
Not Qualified Due To
:
LOS
Selected For Use
: No
Not Selected Due To
:
not qualified
Interface Type
: DS1
Framing
: ESF
Line Coding
: B8ZS
============================================================================
*A:PE-1>show>system#

Advanced Configuration Guide

Page 2013

Configuration

Configuration 2
The following example shows the configuration options for SyncE when ql-selection mode is
enabled.
This is the normal case for European SDH networks.
A:PE-1>config# card 1 mda 1
A:PE-1>config>card>mda#
access
+ Configure access MDA parameters
egress
+ Configure egress MDA parameters
[no] hi-bw-mcast-src - Enable/disable allocation of resources for high
bandwidth multicast streams
ingress
+ Configure ingress MDA parameters
[no] mda-type
- Provisions/de-provisions an MDA to/from the device
configuration for the slot
named-pool-mode + Enable/Disable named pool mode
network
+ Configure network MDA parameters
[no] shutdown
- Administratively shut down an mda
[no] sync-e
- Enable/Disable Synchronous Ethernet
A:PE-1>config>card>mda# sync-e
A:PE-1>config>card>mda# info detail
--------------------------------------------mda-type m20-1gb-xp-sfp
sync-e
named-pool-mode
ingress
no named-pool-policy
exit
egress
no named-pool-policy
exit
exit
ingress
no hsmda-pool-policy
no scheduler-policy
exit
egress
no hsmda-pool-policy
exit
network
ingress
pool default
...

A:PE-1>config# port 1/1/2 ethernet ssm


A:PE-1>config>port>ethernet>ssm#
A:PE-1>config>port>ethernet>ssm#
[no] code-type
- Set the SSM channel to either use sonet or sdh
[no] shutdown
- Enable/Disable SSM
[no] tx-dus
- Enable/disable always transmit 0xF (dus/dnu) in SSM messaging channel
A:PE-1>config>port>ethernet>ssm# code-type sdh
*A:PE-1>config>port>ethernet>ssm# no shutdown
*A:PE-1>config>port>ethernet>ssm# info detail

Page 2014

Advanced Configuration Guide

Synchronous Ethernet

---------------------------------------------code-type sdh
no tx-dus
no shutdown
---------------------------------------------*A:PE-1>config>port>ethernet>ssm#

*A:PE-1>config>system# sync-if-timing
*A:PE-1>config>system>sync-if-timing#
abort
- Discard the changes that have been made to sync
interface timing during a session
begin
- Switch to edit mode for sync interface timing - use
commit to save or abort to discard the changes made in
a session
bits
+ Configure parameters for the Building Integrated Timing
Supply(BITS)
commit
- Save the changes made to sync interface timing during a
session
[no] ql-selection
- Enable/disable reference selection based on
quality-level
[no] ref-order
- Priority order of timing references
ref1
+ Configure parameters for the first timing reference
ref2
+ Configure parameters for the second timing reference
[no] revert
- Revert/do not revert to a higher priority re-validated
reference source
*A:PE-1>config>system>sync-if-timing# begin
*A:PE-1>config>system>sync-if-timing# ref-order bits ref1
*A:PE-1>config>system>sync-if-timing# ql-selection
*A:PE-1>config>system>sync-if-timing# bits input no shutdown
*A:PE-1>config>system>sync-if-timing# bits interface-type ds1 esf
*A:PE-1>config>system>sync-if-timing# bits ql-override prc
*A:PE-1>config>system>sync-if-timing# revert
*A:PE-1>config>system>sync-if-timing# ref1
*A:PE-1>config>system>sync-if-timing>ref1#
[no] ql-override
- Override the quality level of a timing reference
[no] shutdown
- Administratively shutdown the timing reference
[no] source-port
- Configure the source port for the first timing reference
*A:PE-1>config>system>sync-if-timing>ref1# source-port 1/1/2
*A:PE-1>config>system>sync-if-timing>ref1# no shutdown
*A:PE-1>config>system>sync-if-timing>ref1# exit
*A:PE-1>config>system>sync-if-timing# commit
*A:PE-1>config>system>sync-if-timing# info detail
---------------------------------------------ql-selection
ref-order bits ref1 ref2
ref1
source-port 1/1/2
no shutdown
no ql-override
exit
ref2
shutdown
no source-port
no ql-override
exit
bits
interface-type ds1 esf

Advanced Configuration Guide

Page 2015

Configuration

ql-override prc
input
no shutdown
exit
output
shutdown
line-length 110
exit
exit
revert

The following output displays the associated show information.


*A:PE-1>show>system# sync-if-timing
============================================================================
System Interface Timing Operational Info
============================================================================
System Status CPM A
: Master Locked
Reference Input Mode
: Revertive
Quality Level Selection
: Enabled
Reference Selected
: ref1
System Quality Level
: prc
Current Frequency Offset (ppm) : -5

Page 2016

Reference Order

: bits ref1 ref2

Reference Mate CPM


Qualified For Use
Not Qualified Due To
Selected For Use
Not Selected Due To

: No
:
: No
:

Reference Input 1
Admin Status
Rx Quality Level
Quality Level Override
Qualified For Use
Selected For Use
Source Port

:
:
:
:
:
:

up
prc
none
Yes
Yes
1/1/2

Reference Input 2
Admin Status
Rx Quality Level
Quality Level Override
Qualified For Use
Not Qualified Due To
Selected For Use
Not Selected Due To
Source Port

:
:
:
:
:
:
:
:

down
unknown
none
No
disabled
No
disabled
None

Reference BITS A
Input Admin Status
Rx Quality Level
Quality Level Override
Qualified For Use
Not Qualified Due To
Selected For Use
Not Selected Due To

:
:
:
:
:
:
:

up
failed
none
No
LOS
No
not qualified

LOS
not qualified

Advanced Configuration Guide

Synchronous Ethernet

Interface Type
: DS1
Framing
: ESF
Line Coding
: B8ZS
============================================================================
*A:PE-1>show>system#

Advanced Configuration Guide

Page 2017

Conclusion

Conclusion
With the world rapidly transitioning to IP/MPLS-based NGNs with Ethernet as the transport
medium of choice, there is an increasing need to enhance services and capabilities while still
leveraging existing infrastructure, thereby easing the transition while continuing to increase
revenue and reduce the Total Cost of Ownership (TCO). In areas such as mobile backhaul, TDM
CES etc., these requirements create a need for SONET/SDH-like frequency synchronization
capability in the inherently asynchronous Ethernet network.
SyncE, natively supported on the Alcatel-Lucent 7750 SR and 7450 ESS service routers, is an
ITU-T standardized PHY-level way of transmitting frequency synchronization across Ethernet
packet networks that fulfills that need in a reliable, secure, scalable, efficient, and cost-effective
manner. It allows Service Providers to keep existing revenue streams alive and create new ones
while simplifying the network design and reducing TCO.

Page 2018

Advanced Configuration Guide

VPRN Inter-AS VPN Model C

In This Chapter
This section provides information about
Topics in this section include:

Applicability on page 2020

Overview on page 2021

Configuration on page 2024

Conclusion on page 2033

Advanced Configuration Guide

Page 2019

Applicability

Applicability
This example is applicable to all of the 7750 and 7710 SR series and was tested on release 7.0R5.
There are no pre-requisites for this configuration. This is supported on 7450 ESS-7 or ESS-12 in
mixed-mode since 8.0R1. The 7750 SR-c4 is supported from 8.0R4 and higher.

Page 2020

Advanced Configuration Guide

VPRN Inter-AS VPN Model C

Overview
Introduction
Section 10 of RFC 4364, BGP/MPLS IP Virtual Private Networks (VPNs), describes three
potential methods for service providers to interconnect their IP-VPN (Internet Protocol Virtual
Private Network) backbones in order to provide an end-to-end MPLS-VPN where one or more
sites of the VPN are connected to different service provider autonomous systems. The purpose of
this section is to describe the configuration and troubleshooting for inter-AS VPN model C.
In this architecture, VPN prefixes are neither held, nor re-advertised by the Autonomous System
Border Router Provider Edge (ASBR-PE) routers. The ASBR-PE does however maintain
labeled IPv4 /32 routes to other PE routers within its own AS. It then redistributes these /32 IPv4
prefixes in external Border Gateway Protocol (eBGP) to the ASBR-PE in other service providers
ASs. Using this methodology, it is possible for PE routers in different ASs to establish multi-hop
Multi Protocol external Border Gateway Protocol (MP-eBGP) sessions to each other in order to
exchange customer VPN prefixes over those connections.
To be more specific, the /32 IPv4 routes for the PE routers in the other service providers AS will
need to be redistributed into the interior Gateway Protocol (IGP) in the local AS together with an
assigned label. As most service providers do not like redistribution of loop-back addresses from
another service provider into the local IGP, a potential solution can be found by imposing a threelevel label stack on the ingress PE. The bottom-level label would be assigned by the egress PE
(advertised in multi-hop MP-eBGP without next-hop override) and is commonly referred to as the
VPN-label. The middle label would be assigned by the local ASBR-PE and would correspond to
the /32 route of the egress PE (in a different AS) using BGP-LBL (RFC 3107, Carrying Label
Information in BGP-4). The top level label would then be the label assigned by the local ASBRPE(s) /32 loop-back address, which would be assigned by the IGP next-hop of the ingress PE. This
label is referred to as the LDP-LBL. Figure 208 reflects this mechanism. The VPN-LBL is
assigned by PE-5, the BGP-LBL is assigned by PE-4 and the LDP-LBL is also assigned by PE-4.

Advanced Configuration Guide

Page 2021

Overview

PE-1
192.0.2.1
10.1.1.1/32

PE-6
192.0.2.130

PE-2
192.0.2.2

PE-5
192.0.2.129

VRF

10.2.2.2/32

VRF

AS64496

AS64497
192.168.0.0/30
.1

PE-3
RR
192.0.2.3

PE-8
ASBR
192.0.2.132

PE-4
ASBR
192.0.2.4

IP
VPN-LBL
BGP-LBL
LDP-LBL
L2

IP
L2

.2

IP
VPN-LBL
BGP-LBL
L2

PE-7
RR
192.0.2.131

IP
BPN-LBL
BDP-LBL
L2

IP
L2
OSSG439

Figure 208: Inter-AS VPN Model C

The VPN connectivity is established using Labeled VPN route exchange using MP-eBGP without
next-hop override. The PE connectivity will be established as described below.
EBGP PE /32 loopback leaking routing exchange using eBGP LBL (RFC 3107) at the ASBR-PE.
The /32 PE routes learned from the other AS through the ASBR-PE are further distributed into the
local AS using iBGP and optionally Route Reflectors (RRs). This model uses a three label stack
and is referred to as Model C. Resilience for ASBR-PE failures is dependent on BGP.

PE-6

PE-5
ISIS LDP

VRF
ISIS LDP

iBGP VPN-IPv4
iBGP Labeled IPv4

ISIS LDP

ISIS LDP

ISIS LDP

VRF

PE-2

ISIS LDP

PE-1

eBGP Labeled IPv4


ISIS LDP

ISIS LDP

PE-3
RR

PE-4
ASBR

PE-8
ASBR

PE-7
RR

eBGP VPN-IPv4
OSSG440

Figure 209: Protocol Overview

Page 2022

Advanced Configuration Guide

VPRN Inter-AS VPN Model C

Figure 209 gives an overview of all protocols used when implementing Inter-AS Model C. Inside
each AS there is an ISIS adjacency and a link LDP session between each pair of adjacent nodes.
As an alternative, OSPF can be used as IGP. Also there is an iBGP session between each PE and
the RR. The address family is both VPN-IPv4 for the exchange of customer VPN prefixes and
Labeled IPv4 for the exchange of labeled IPv4 prefixes. Note that as an alternative, a full mesh of
iBGP sessions can be used in each AS.
Between the ASBRs there is an eBGP sessions for the exchange of labeled IPv4 prefixes. The
ASBRs will override the next-hop for those prefixes. Between the RRs in the different ASs there
is an eBGP session for the exchange of VPN customer prefixes. The RRs will not override the
next-hop for those prefixes.
The big advantage of this model is that no VPN routes need to be held on the ASBR-PEs and as
such it scales the best among all the three Inter-AS IP-VPN models. However, leaking /32 PE
addresses between service providers creates some security concerns. As such we see Model C
typically deployed within a service provider network.
The network topology is displayed in Figure 208. The setup consists of two times four (2 x 4)
7750/7710 nodes located in different autonomous systems. There is an AS interconnection from
ASBR PE-4 to ASBR PE-8. PE-3 and PE-7 will act as RRs for their AS. It is assumed that an IPVPN is already configured in each AS. Following configuration tasks should be done first:

ISIS or OSPF on all interfaces within each of the ASs.

LDP on all interfaces within each of the ASs.

MP-iBGP sessions between the PE routers and the RRs in each of the ASs.

IP-VPN on PE-1 and on PE-5 with identical route targets.

A loopback interface in the VRF on PE-1 and PE-5.

Advanced Configuration Guide

Page 2023

Configuration

Configuration
The first step is to configure a MP-eBGP session between the ASBRs in both ASs. This session
will be used to redistribute labelled IPv4 routes for the /32 system IP addresses between the AS?.
These MP-BGP extensions are described in RFC 3107.
The configuration for ASBR PE-4 is displayed below. The advertise-label ipv4 command is
required to enable the advertising of labelled IPv4 routes. Note that this command is also required
on the RR neighbor in order to propagate the labelled IPv4 routes towards the other PEs in the AS.
The address family for labelled IPv4 routes is IPv4 so this family must be enabled for the peering
with the RR.
configure router bgp
group "rr"
family ipv4 vpn-ipv4
neighbor 192.0.2.3
advertise-label ipv4
exit
exit
group "remote-as"
family ipv4
type external
peer-as 64497
neighbor 192.168.0.2
advertise-label ipv4
exit
exit
exit all

Note that address family vpn-ipv4 is also required to advertise IPv4 customer routes within the
AS. On the RR, the advertise-label ipv4 command must be specified for each PE neighbor. Also
note that address family IPv4 must be enabled. The configuration for RR PE-3 is displayed below.
configure router bgp
group "rr-clients"
family ipv4 vpn-ipv4
neighbor 192.0.2.1
advertise-label ipv4
exit
neighbor 192.0.2.2
advertise-label ipv4
exit
neighbor 192.0.2.4
advertise-label ipv4
exit
exit
exit all

Page 2024

Advanced Configuration Guide

VPRN Inter-AS VPN Model C

On the remaining PE nodes in AS 64496, the advertise-label ipv4 command must be specified on
the RR neighbor. Also the IPv4 family must be enabled.
configure router bgp
group rr
family ipv4 vpn-ipv4
neighbor 192.0.2.3
advertise-label ipv4
exit
exit
exit all

The configuration for the nodes in AS64497 is very similar. The IP addresses can be derived from
Figure 208.
On ASBR PE-4, verify that the BGP session with ASBR PE-8 is up:
A:PE-4# show router bgp neighbor 192.168.0.2
===============================================================================
BGP Neighbor
===============================================================================
------------------------------------------------------------------------------Peer : 192.168.0.2
Group : remote-as
------------------------------------------------------------------------------Peer AS
: 64497
Peer Port
: 179
Peer Address
: 192.168.0.2
Local AS
: 64496
Local Port
: 51262
Local Address
: 192.168.0.1
Peer Type
: External
State
: Established
Last State
: Active
Last Event
: recvKeepAlive
Last Error
: Cease
Local Family
: IPv4
Remote Family
: IPv4
Hold Time
: 90
Keep Alive
: 30
Active Hold Time
: 90
Active Keep Alive
: 30
Cluster Id
: None
Preference
: 170
Num of Flaps
: 4
Recd. Paths
: 0
IPv4 Recd. Prefixes : 0
IPv4 Active Prefixes : 0
IPv4 Suppressed Pfxs : 0
VPN-IPv4 Suppr. Pfxs : 0
VPN-IPv4 Recd. Pfxs : 0
VPN-IPv4 Active Pfxs : 0
Mc IPv4 Recd. Pfxs. : 0
Mc IPv4 Active Pfxs. : 0
Mc IPv4 Suppr. Pfxs : 0
IPv6 Suppressed Pfxs : 0
IPv6 Recd. Prefixes : 0
IPv6 Active Prefixes : 0
VPN-IPv6 Recd. Pfxs : 0
VPN-IPv6 Active Pfxs : 0
VPN-IPv6 Suppr. Pfxs : 0
L2-VPN Suppr. Pfxs
: 0
L2-VPN Recd. Pfxs
: 0
L2-VPN Active Pfxs
: 0
MVPN-IPv4 Suppr. Pfxs: 0
MVPN-IPv4 Recd. Pfxs : 0
MVPN-IPv4 Active Pfxs: 0
Input Queue
: 0
Output Queue
: 0
i/p Messages
: 37
o/p Messages
: 39
i/p Octets
: 891
o/p Octets
: 891
i/p Updates
: 4
o/p Updates
: 4
TTL Security
: Disabled
Min TTL Value
: n/a

Advanced Configuration Guide

Page 2025

Configuration

Graceful Restart
Advertise Inactive
Advertise Label
Auth key chain
Bfd Enabled
Local Capability
Remote Capability
Import Policy
Export Policy

:
:
:
:
:
:
:
:
:

Disabled
Stale Routes Time
Disabled
Peer Tracking
ipv4
n/a
Disabled
RtRefresh MPBGP 4byte ASN
RtRefresh MPBGP 4byte ASN
None Specified / Inherited
None Specified / Inherited

: n/a
: Disabled

------------------------------------------------------------------------------Neighbors : 1
===============================================================================
A:PE-4#

Note that both ASBRs have MPBGP capabilities. At this time, no prefixes have been received
from the remote ASBR. To enable the advertising of labelled IPv4 routes for the system loopback
interfaces, an export policy must be created and applied to the BGP session on both ASBRs. The
policy configuration is displayed below for ASBR PE-4. Note that the configuration for ASBR
PE-8 is very similar, the IP addresses can be derived from Figure 208.
configure router policy-options
prefix-list "pe_sys"
prefix 192.0.2.128/25 longer
exit
policy-statement "pe-sys-to-bgp"
entry 10
from
prefix-list "pe-sys"
exit
to
protocol bgp
exit
action accept
exit
exit
exit
exit all
configure router bgp
group remote-as
neighbor 192.168.0.2
export "pe-sys-to-bgp"
exit
exit
exit all

After creating and applying the export policies on both ASBRs, labelled IPv4 routes will be
advertised towards the remote AS for system IP addresses of the PE nodes in the local AS.

Page 2026

Advanced Configuration Guide

VPRN Inter-AS VPN Model C

On ASBR PE-4, verify if labelled IPv4 routes have been received from ASBR PE-8:
A:PE-4# show router bgp routes
===============================================================================
BGP Router ID:192.0.2.4
AS:64496
Local AS:64496
===============================================================================
Legend Status codes : u - used, s - suppressed, h - history, d - decayed, * - valid
Origin codes : i - IGP, e - EGP, ? - incomplete, > - best
===============================================================================
BGP IPv4 Routes
===============================================================================
Flag Network
LocalPref
MED
Nexthop
VPNLabel
As-Path
------------------------------------------------------------------------------u*>i 192.0.2.129/32
None
20
192.168.0.2
64497
u*>i 192.0.2.130/32
None
10
192.168.0.2
64497
u*>i 192.0.2.131/32
None
10
192.168.0.2
64497
u*>? 192.0.2.132/32
None
None
192.168.0.2
64497
------------------------------------------------------------------------------Routes : 4
===============================================================================
A:PE-4#

As can be seen from the output above, 4 labelled IPv4 routes have been received. One route for
every system IP address in the remote AS with a label attached.
The actual labels can be seen with following command:
A:PE-4# show router bgp routes 192.0.2.129/32 hunt
===============================================================================
BGP Router ID:192.0.2.4
AS:64496
Local AS:64496
===============================================================================
Legend Status codes : u - used, s - suppressed, h - history, d - decayed, * - valid
Origin codes : i - IGP, e - EGP, ? - incomplete, > - best
===============================================================================
BGP IPv4 Routes
===============================================================================
------------------------------------------------------------------------------RIB In Entries
------------------------------------------------------------------------------Network
: 192.0.2.129/32
Nexthop
: 192.168.0.2
From
: 192.168.0.2
Res. Nexthop
: 192.168.0.2
Local Pref.
: None
Interface Name : int-PE-4-PE-8
Aggregator AS : None
Aggregator
: None

Advanced Configuration Guide

Page 2027

Configuration

Atomic Aggr.
: Not Atomic
MED
: 20
Community
: No Community Members
Cluster
: No Cluster Members
Originator Id : None
Peer Router Id : 192.0.2.132
IPv4 Label
: 131065
Flags
: Used Valid Best IGP
AS-Path
: 64497
------------------------------------------------------------------------------RIB Out Entries
------------------------------------------------------------------------------Network
: 192.0.2.129/32
Nexthop
: 192.0.2.4
To
: 192.0.2.3
Res. Nexthop
: n/a
Local Pref.
: 100
Interface Name : NotAvailable
Aggregator AS : None
Aggregator
: None
Atomic Aggr.
: Not Atomic
MED
: 20
Community
: No Community Members
Cluster
: No Cluster Members
Originator Id : None
Peer Router Id : 192.0.2.3
IPv4 Label
: 131062
Origin
: IGP
AS-Path
: 64497
------------------------------------------------------------------------------Routes : 2
===============================================================================
A:PE-4#

Note that in the RIB In entries, the received label from PE-8 can be seen (131065). In the RIB Out
entries, the locally assigned label for this prefix can be seen (131062). The label mapping can also
be seen with following command:
A:PE-4# show router bgp inter-as-label
===============================================================================
BGP Inter-AS labels
===============================================================================
NextHop
Received
Advertised
Label
Label
Label
Origin
------------------------------------------------------------------------------192.0.2.1
0
131065
Internal
192.168.0.2
131064
131061
External
192.168.0.2
131065
131062
External
192.168.0.2
131066
131060
External
192.168.0.2
131067
131063
External
192.0.2.2
0
131064
Internal
192.0.2.3
0
131066
Internal
192.0.2.4
0
131067
Edge
===============================================================================
A:PE-4#

Page 2028

Advanced Configuration Guide

VPRN Inter-AS VPN Model C

Verify that the routes have been installed in the routing table:
A:PE-4# show router route-table
===============================================================================
Route Table (Router: Base)
===============================================================================
Dest Prefix
Type
Proto
Age
Pref
Next Hop[Interface Name]
Metric
------------------------------------------------------------------------------192.0.2.1/32
Remote ISIS
02h24m15s
18
192.168.3.1
20
192.0.2.2/32
Remote ISIS
02h24m15s
18
192.168.3.1
10
192.0.2.3/32
Remote ISIS
02h27m29s
18
192.168.4.1
10
192.0.2.4/32
Local
Local
02h27m35s
0
system
0
192.0.2.129/32
Remote BGP
00h03m54s
170
192.168.0.2
0
192.0.2.130/32
Remote BGP
00h03m54s
170
192.168.0.2
0
192.0.2.131/32
Remote BGP
00h03m54s
170
192.168.0.2
0
192.0.2.132/32
Remote BGP
00h03m54s
170
192.168.0.2
...
===============================================================================
A:PE-4#

Verify that the BGP routes are further advertised towards all the PEs in the AS (through the RR)
and are installed in the routing table on all PEs by using the above command on the other PEs.
At this point, all PEs in one AS have the /32 system IPs of the remote PEs in their routing table.
All PEs in one AS have also received labels for all /32 system IPs of the remote PEs. Now a MPeBGP session can be created between the RRs in the different ASs to exchange VPN-IPv4 routes.
The configuration for RR PE-3 is displayed below. The configuration for RR PE-7 is very similar.
The IP addresses can be derived from Figure 209.
configure router bgp
group "remote-as-rr"
family vpn-ipv4
multihop 10
peer-as 64497
neighbor 192.0.2.131
exit
exit
exit all

Advanced Configuration Guide

Page 2029

Configuration

On the RRs, verify that the MP-eBGP session is up:


A:PE-3# show router bgp neighbor 192.0.2.131
===============================================================================
BGP Neighbor
===============================================================================
------------------------------------------------------------------------------Peer : 192.0.2.131
Group : remote-as-rr
------------------------------------------------------------------------------Peer AS
: 64497
Peer Port
: 179
Peer Address
: 192.0.2.131
Local AS
: 64496
Local Port
: 49714
Local Address
: 192.0.2.3
Peer Type
: External
State
: Established
Last State
: Active
Last Event
: recvKeepAlive
Last Error
: Unrecognized Error
Local Family
: VPN-IPv4
Remote Family
: VPN-IPv4
Hold Time
: 90
Keep Alive
: 30
Active Hold Time
: 90
Active Keep Alive
: 30
Cluster Id
: None
Preference
: 170
Num of Flaps
: 0
Recd. Paths
: 1
IPv4 Recd. Prefixes : 0
IPv4 Active Prefixes : 0
IPv4 Suppressed Pfxs : 0
VPN-IPv4 Suppr. Pfxs : 0
VPN-IPv4 Recd. Pfxs : 1
VPN-IPv4 Active Pfxs : 0
Mc IPv4 Recd. Pfxs. : 0
Mc IPv4 Active Pfxs. : 0
Mc IPv4 Suppr. Pfxs : 0
IPv6 Suppressed Pfxs : 0
IPv6 Recd. Prefixes : 0
IPv6 Active Prefixes : 0
VPN-IPv6 Recd. Pfxs : 0
VPN-IPv6 Active Pfxs : 0
VPN-IPv6 Suppr. Pfxs : 0
L2-VPN Suppr. Pfxs
: 0
L2-VPN Recd. Pfxs
: 0
L2-VPN Active Pfxs
: 0
MVPN-IPv4 Suppr. Pfxs: 0
MVPN-IPv4 Recd. Pfxs : 0
MVPN-IPv4 Active Pfxs: 0
Input Queue
: 0
Output Queue
: 0
i/p Messages
: 14
o/p Messages
: 14
i/p Octets
: 370
o/p Octets
: 370
i/p Updates
: 1
o/p Updates
: 1
TTL Security
: Disabled
Min TTL Value
: n/a
Graceful Restart
: Disabled
Stale Routes Time
: n/a
Advertise Inactive
: Disabled
Peer Tracking
: Disabled
Advertise Label
: None
Auth key chain
: n/a
Bfd Enabled
: Disabled
Local Capability
: RtRefresh MPBGP ORFSendExComm ORFRecvExComm 4byte ASN
Remote Capability
: RtRefresh MPBGP ORFSendExComm ORFRecvExComm 4byte ASN
Import Policy
: None Specified / Inherited
Export Policy
: None Specified / Inherited
------------------------------------------------------------------------------Neighbors : 1
===============================================================================
A:PE-3#

The BGP session is established. Note that 1 VPN-IPv4 prefix has been received for the remote AS.

Page 2030

Advanced Configuration Guide

VPRN Inter-AS VPN Model C

Now the VPRNs on PE-1 in AS64496 and PE-5 in AS64497 are interconnected. Packets
originating in AS 64496 with a destination in AS 64497 will have 3 labels in AS 64496. Originate
a VPRN ping on PE-1 towards the VPRN loopback IP address on PE-5:
A:PE-1# ping router 1 10.2.2.2
PING 10.2.2.2 56 data bytes
64 bytes from 10.2.2.2: icmp_seq=1
64 bytes from 10.2.2.2: icmp_seq=2
64 bytes from 10.2.2.2: icmp_seq=3
64 bytes from 10.2.2.2: icmp_seq=4
64 bytes from 10.2.2.2: icmp_seq=5

ttl=64
ttl=64
ttl=64
ttl=64
ttl=64

time=7.50ms.
time=3.77ms.
time=3.80ms.
time=3.77ms.
time=3.78ms.

---- 10.2.2.2 PING Statistics ---5 packets transmitted, 5 packets received, 0.00% packet loss
round-trip min = 3.77ms, avg = 4.52ms, max = 7.50ms, stddev = 1.49ms

The top label is the LDP label to reach the exit point of the AS (PE-4). This label can be seen with
following command on PE-1:
A:PE-1# show router ldp bindings prefix 192.0.2.4/32 active
===============================================================================
Legend: (S) - Static
===============================================================================
LDP Prefix Bindings (Active)
===============================================================================
Prefix
Op
IngLbl
EgrLbl
EgrIntf/LspId EgrNextHop
------------------------------------------------------------------------------192.0.2.4/32
Push
-131069
1/1/2
192.168.1.2
192.0.2.4/32
Swap 131068
131069
1/1/2
192.168.1.2
------------------------------------------------------------------------------No. of Prefix Bindings: 2
===============================================================================
A:PE-1#

The middle label is the label assigned by MP-BGP on the local ASBR-PE to reach the remote PE
in the remote AS. This label can be seen with following command on PE-1:
A:PE-1# show router bgp routes 192.0.2.129/32 hunt
===============================================================================
BGP Router ID:192.0.2.1
AS:64496
Local AS:64496
===============================================================================
Legend Status codes : u - used, s - suppressed, h - history, d - decayed, * - valid
Origin codes : i - IGP, e - EGP, ? - incomplete, > - best
===============================================================================
BGP IPv4 Routes
===============================================================================
------------------------------------------------------------------------------RIB In Entries
------------------------------------------------------------------------------Network
: 192.0.2.129/32
Nexthop
: 192.0.2.4
From
: 192.0.2.3
Res. Nexthop
: 192.168.1.2
Local Pref.
: 100
Interface Name : int-PE-1-PE-2

Advanced Configuration Guide

Page 2031

Configuration

Aggregator AS : None
Aggregator
: None
Atomic Aggr.
: Not Atomic
MED
: 20
Community
: No Community Members
Cluster
: 1.1.1.1
Originator Id : 192.0.2.4
Peer Router Id : 192.0.2.3
IPv4 Label
: 131062
Flags
: Used Valid Best IGP
AS-Path
: 64497
------------------------------------------------------------------------------RIB Out Entries
------------------------------------------------------------------------------------------------------------------------------------------------------------Routes : 1
===============================================================================
A:PE-1#

The bottom label is the VPN label assigned by the remote PE in the remote AS for the destination
network. This label can be seen with following command on PE-1:
A:PE-1# show router bgp routes vpn-ipv4 10.2.2.2/32 hunt
===============================================================================
BGP Router ID:192.0.2.1
AS:64496
Local AS:64496
===============================================================================
Legend Status codes : u - used, s - suppressed, h - history, d - decayed, * - valid
Origin codes : i - IGP, e - EGP, ? - incomplete, > - best
===============================================================================
BGP VPN-IPv4 Routes
===============================================================================
------------------------------------------------------------------------------RIB In Entries
------------------------------------------------------------------------------Network
: 10.2.2.2/32
Nexthop
: 192.0.2.129
Route Dist.
: 64497:1
VPN Label
: 131070
From
: 192.0.2.3
Res. Nexthop
: n/a
Local Pref.
: 100
Interface Name : NotAvailable
Aggregator AS : None
Aggregator
: None
Atomic Aggr.
: Not Atomic
MED
: None
Community
: target:64496:1
Cluster
: No Cluster Members
Originator Id : None
Peer Router Id : 192.0.2.3
Flags
: Used Valid Best IGP
AS-Path
: 64497
VPRN Imported : 1
------------------------------------------------------------------------------RIB Out Entries
------------------------------------------------------------------------------------------------------------------------------------------------------------Routes : 1
===============================================================================
A:PE-1#

Page 2032

Advanced Configuration Guide

VPRN Inter-AS VPN Model C

Conclusion
Inter-AS option C allows the delivery of Layer 3 VPN services to customers who have sites
connected multiple ASs. This example shows the configuration of inter-AS option C (specific to
this feature) together with the associated show output which can be used verify and troubleshoot
it.

Advanced Configuration Guide

Page 2033

Conclusion

Page 2034

Advanced Configuration Guide

WiFi Aggregation and Offload


Migrant User Support

In This Chapter
This section provides information about WiFi aggregation and offload for migrant user support
configurations.
Topics in this section include:

Applicability on page 2036

Overview on page 2037

Configuration on page 2045

Conclusion on page 2049

Advanced Configuration Guide

Page 2035

Applicability

Applicability
This example is applicable to all 7750 SR platforms supporting WLAN gateway (WLAN-GW)
IOMs (IOM3-XP and 2xISAs). It provides a functional description of migrant user handling on
7750 WLAN-GW and the corresponding configuration. It assumes the user is aware of the general
operations and configuration of the basic WLAN-GW function as already described in the 7750
SR OS Triple Play guide.
The configuration with migrant user support enabled was tested on release 11.0R4.

Page 2036

Advanced Configuration Guide

WiFi Aggregation and Offload Migrant User Support

Overview
The term Migrant user refers to user equipment (UEs) that connects to a WiFi network service
set identification (SSID) but moves out of the range of the access point before initiating or
completing authentication. For open-SSIDs, a migrant user may stay in the range of the access
point just long enough to get a DHCP lease from the WLAN-GW. In actual WiFi deployments
with portal authentication, it has been observed that a large percentage of users are migrant such
that they get a DHCP lease but do not initiate or complete authentication.
Prior to this feature, an Enhanced Subscriber Management (ESM) host is created when the DHCP
process completes. This results in the consumption of resources on both the CPM and IOM,
limiting the ESM scale and performance for fully authenticated active users. This feature adds
support to create an ESM host only after a user has been fully authenticated, either via a web
portal or with an AAA server based on completing EAP exchange. In addition, with this feature
L2-aware NAPT is required, such that each UE gets the same shared configured inside IP address
from the ISA via DHCP. Until a user is authenticated, forwarding of user traffic is constrained (via
policy) to DNS and portal server access only.
Each user is allocated a small number of configured NAT outside ports to minimize public IP
address consumption for unauthenticated users. Once the user is successfully authenticated, as
indicated via a RADIUS Change of Authorization (COA) on successful portal authentication, an
ESM host is created, and the L2-aware NAT is applied via a normal per-subscriber NAT policy.
The inside IP address of the user does not change. The outside IP pool used is as per the NAT
policy, and the L2-aware NAT could be 1:1 or NAPT with larger number of outside ports than in
the un-authenticated phase. If a user is already pre-authenticated (for example if the RADIUS
server remembers the MAC address of the UE from a previous successful portal authentication)
then the initial access-accept from RADIUS will trigger the creation of the ESM host.

Advanced Configuration Guide

Page 2037

Overview

Migrant User Support for Open SSID Based on Portal


Authentication
Sequence Of Events
1. DHCP Is Received From UE On ISA
Based on the DHCP and L2-aware NAT configuration on the ISA, an IP address is
assigned to the user via DHCP. The DHCP and L2-aware NAT configuration is under the
soft-gre node under the group-interface, or under vlan-tag range under the soft-gre node
on the group-interface.
A different DHCP lease-time can be configured for an un-authenticated user (initial-leasetime) and an authenticated user (active-lease-time) for which an ESM host has been
created. It is suggested that the initial lease be configured to a smaller value while the UE
is migrant so that resources can be reclaimed quickly for a truly migrant user that will not
complete authentication.
In addition to lease-times, DHCP return options, for example primary and secondary DNS
and NBNS server addresses, that can be configured. This configuration can be per softGRE group interface or per VLAN range (where a VLAN tag corresponds to an SSID).
Up to 512 bytes of received DHCP options from clients are stored on the ISA. Once the
DHCP ACK is sent back to the UE from the ISA, the UE will be created on the ISA in
migrant (or unauthenticated) state.
A configured L2-aware IP address is returned to each UE and a temporary L2-aware host
is created on the anchor ISA for the UE. The NAT policy applicable to this L2-aware NAT
for UE in migrant state is also configured under the group-interface (under soft-gre node
or under vlan-tag range).
ARP requests coming from the UE in migrant state will be responded to from the ISA.
The authentication to RADIUS is triggered on receiving the first Layer 3 data packet as
opposed to on a DHCP DISCOVER.
2. Layer 3 Data Packet Received on the ISA
The first Layer 3 packet (other than DHCP) will trigger RADIUS authentication from the
ISA based on configured isa-radius-policy in the configure>aaa context. The user-name
in the access-request is as per the user-name-format configured in the isa-radius-policy.
By default it is the MAC address of the UE. The isa-radius-policy can be configured as the
authentication policy under the soft-gre group-interface, or under specific VLAN tag
ranges on the soft-gre group-interface. The latter allows for the use of a different
authentication policy per SSID.
The RADIUS packets from the ISA are sourced with the IP address owned by the ISA.
Each ISA in the WLAN-GW group gets an IP address from a set of contiguous addresses,

Page 2038

Advanced Configuration Guide

WiFi Aggregation and Offload Migrant User Support

the start of which is configurable in isa-radius-policy. The nas-ip-address sent in accessrequest message is configurable in the isa-radius-policy as the ISAs local IP address or
the system IP address. In case the RADIUS server is behind a load-balancer which
updates the source IP address of the RADIUS messages, the RADIUS server may use nasip-address to route the RADIUS response back. In this case the nas-ip-address should be
configured as the ISAs IP address otherwise the response would incorrectly be routed to
the CPM instead of the ISA.
The debug output below shows a RADIUS accept-request being sent to the RADIUS
server on reception of first Layer 3 packet. The debug can be enabled by issuing:
debug router "management" radius packet-type authentication | accounting | coa
253 2013/08/07 20:58:35.53 UTC MINOR: DEBUG #2001 Base WLAN-GW
"WLAN-GW: MDA 2/1, SeqNo 11830
Info:
anchor egressing frame
radius-auth-req
IP/UDP:
RADIUS:
"

from 192.168.0.2:1142 to 192.0.2.3:1812


Access-Request (continued)

254 2013/08/07 20:58:35.53 UTC MINOR: DEBUG #2001 Base RADIUS


"RADIUS: Transmit
Access-Request(1) 192.168.0.2:1142 id 40 len 158 vrid 1
NAS IP ADDRESS [4] 4 192.0.2.3
NAS PORT TYPE [61] 4 Virtual(5)
NAS PORT ID [87] 43 GRE rtr-3#lip-192.168.0.1#rip-192.0.2.1
USER NAME [1] 17 00:0a:0a:00:01:00
PASSWORD [2] 16 rCmhFboYeM2M8hOuBYJXJk
CALLING STATION ID [31] 17 00:0a:0a:00:01:00
VSA [26] 19 Alcatel(6527)
CHADDR [27] 17 00:0a:0a:00:01:00
"

Received Layer 3 packets from the UE are handled as per the redirect-policy configured
under the soft-gre group-interface or under applicable VLAN tag range on the soft-gre
interface.
The redirect-policy is an IP ACL that should contain one more forward rules for traffic
that should be forwarded while the UE is pending portal authentication. This typically
should include traffic to and from DNS and web portal and is subjected to temporary L2aware NAT. The redirect-policy also specifies the URL for redirecting triggered by http
packets. The redirect-policy and/or the redirect URL can also be overridden via the
RADIUS access-accept. Any other non-http traffic that does not match the forward rules
is dropped.
While a UE is pending portal authentication no accounting messages are sent to the AAA
server. Disconnect-Message from AAA server is supported while the UE is pending
authentication.

Advanced Configuration Guide

Page 2039

Overview

3. Access-accept from RADIUS


The access-accept is received on the ISA from which the access-request was generated.
The initial access-accept from RADIUS can indicate if a user needs to be authenticated by
the portal or is a pre-authenticated user. The indication is based on inclusion of a redirect
policy applicable to the user in a vendor specific attribute (VSA) (Alc-Wlan-PortalRedirect, type = string) received from the RADIUS server. The access-accept can also
include a redirect URL VSA (Alc-Wlan-Portal-Url, type = string) for the user. An empty
Alc-Wlan-Portal_redirect VSA forces the use of the redirect policy that is locally
specified under the soft-gre interface or under vlan-tag ranges on soft-gre interface. The
redirect-policy is created under sub-mgmt node.
The UE state is changed to portal to indicate the UE is pending portal authentication and
has limited access.
The debug below shows the RADIUS accept-request being received from the RADIUS
server and being processed by the WLAN-GW.
255 2013/08/07 20:58:35.61 UTC MINOR: DEBUG #2001 Base WLAN-GW
"WLAN-GW: MDA 2/1, SeqNo 11831
Info:
anchor ingressing frame
portal auth-accept
IP/UDP:
RADIUS:
"

from 192.0.2.3:1812 to 192.168.0.2:1142


Access-Accept (continued)

256 2013/08/07 20:58:35.62 UTC MINOR: DEBUG #2001 Base RADIUS


"RADIUS: Receive
Access-Accept(2) id 40 len 64 from 192.0.2.3:1812 vrid 1
VSA [26] 14 Alcatel(6527)
SUBSC ID STR [11] 12 migrant_user
VSA [26] 18 Alcatel(6527)
WLAN PORTAL REDIRECT [172] 16 redirect-policy-1
"

The following command is used to display UE information on the ISA, including the state of the
UE and the GRE tunnel to the AP through which the UE is connected.
*A:PE-1# tools dump wlan-gw ue
===============================================================================
Matched 1 session on Slot #2 MDA #1
===============================================================================
UE-Mac
: 00:0a:0a:00:01:00
UE-vlan
: N/A
UE IP Addr
: 10.0.0.10
Description
: Portal
UE timeout
: 288 sec
Auth-time
: 08/07/13 20:58:35
Tunnel MDA
: 2/2
Tunnel Router
: 10
MPLS label
: 3000
Shaper
: Default
GRE Src IP Addr : 192.0.2.2
GRE Dst IP Addr : 192.168.0.1
Anchor SAP
: 2/1/nat-out-ip:2049.1
Last-forward
: None
Last-move
: None
Rx Frames
: 0
Rx Octets
: 0
Tx Frames
: 0
Tx Octets
: 0

Page 2040

Advanced Configuration Guide

WiFi Aggregation and Offload Migrant User Support

------------------------------------------------------------------------------===============================================================================
No sessions on Slot #2 MDA #2 match the query

If neither of the two redirect related VSAs are included in access-accept, then this
indicates a pre-authenticated user, and an ESM host is created for the subscriber with a
subscriber-profile and other subscriber configuration from access-accept; from here
normal ESM based forwarding occurs for the subscriber.
If a user is determined as a pre-authenticated user, a message is generated to the CPM to
create an ESM host. The information received from RADIUS in the access-accept
message (for example subscriber-profile, app-profile etc) and the information from DHCP
(for example the DHCP options) are passed in this message.
4. COA from RADIUS
When users credentials entered on the portal are successfully verified, the portal triggers
the AAA server to generate COA to WLAN-GW. The COA serves as a trigger to create an
ESM host. The COA MUST contain the subscriber-id and user-name, which are used as a
key to identify the UE pending portal authentication.
The following shows an example debug of a COA being received from the AAA server.
248 2013/08/07 19:12:38.29 UTC MINOR: DEBUG #2001 Base RADIUS
"RADIUS: Transmit
Change of Authorization(43) 192.0.2.3:36776 id 124 len 96 vrid 1
VSA [26] 19 Alcatel(6527)
SUBSC ID STR [11] 17 00:0a:0a:00:01:00
USER NAME [1] 17 00:0a:0a:00:01:00
VSA [26] 10 Alcatel(6527)
SLA PROF STR [13] 8 sla-profile-1
VSA [26] 10 Alcatel(6527)
SUBSC PROF STR [12] 8 sub-profile-1
"

When the COA is received and successfully processed, a COA-ACK is sent back to the
AAA server. The COA message is passed to the CPM to create an ESM host. The
information received in the COA, as well as stored information from DHCP (for example
the DHCP options) are passed in this message. Once the ESM host is successfully created,
the state of the UE on the ISA is changed accordingly to ESM-user, and can be seen in
the output of tools dump WLAN-GW UE command, as shown below.
The UE now has full access (and is not restricted by the original redirect-policy). The
COA provides a reference to a subscriber profile that contains the NAT policy for an
authenticated UE. The UE continues to keep the same inside L2-aware IP address that was
provided originally via DHCP on the ISA. However, the NAT for an authenticated user
could be an L2-aware 1:1 NAT or NAPT with a different outside pool and outside ports
than the UE in migrant state. The ESM host that is created as described above will also
result in the creation of a normal L2-aware host. The original temporary L2-aware host is
retained for 10 seconds (and then deleted) to ensure the http response from the portal can
be successfully routed back to the UE on the existing connection.

Advanced Configuration Guide

Page 2041

Overview

A:PE-1# tools dump wlan-gw ue


===============================================================================
Matched 1 session on Slot #2 MDA #1
===============================================================================
UE-Mac
: 00:0a:0a:00:01:00
UE-vlan
: N/A
UE IP Addr
: N/A
Description
: ESM-user
UE timeout
: N/A
Auth-time
: 08/07/13 19:12:38
Tunnel MDA
: 2/2
Tunnel Router
: 10
MPLS label
: 3000
Shaper
: 1
GRE Src IP Addr : 192.0.2.2
GRE Dst IP Addr : 192.168.0.1
Anchor SAP
: 2/1/nat-out-ip:2049.1
Last-forward
: 08/07/13 19:12:25
Last-move
: None
Rx Frames
: 1
Rx Octets
: 88
Tx Frames
: 1
Tx Octets
: 222
------------------------------------------------------------------------------===============================================================================
No sessions on Slot #2 MDA #2 match the query

If UE goes out of range such that the idle timeout expires, the ESM host is deleted and an
accounting-stop is sent to the AAA server. If a UE then comes back, and still has a valid DHCP
lease, it may not send DHCP DISCOVER or REQUEST and continue to send data. The datatriggered-ue-creation command can be configured under soft-gre node on the group-interface (or
under vlan-tag ranges on the group-interface) to trigger authentication and recreation of the ESM
host for this UE.
The overall sequence of events to take a UE from migrant to authenticated state, where the
forwarding of UE traffic is not restricted, is shown in Figure 210.

Page 2042

Advanced Configuration Guide

WiFi Aggregation and Offload Migrant User Support

UE

Temporary
L2-aware Host

ISA

CPM

RADIUS

Portal, DNS...
Servers

DHCP Discover
DHCP Offer
DHCP Request
DHCP Ack
UE state created as IP assigned.
ISA stores up to 512 bytes
of DHCP options
ISA Must Reply to ARPs Requests During the Migrant Phase
ARP Req
ARP Resp

Incoming IP Packet (Except DHCP) will Trigger RADIUS Auth


L3 Packet (Except DHCP)

Auth Request (User-name = MAC or MAC + IP)


Auth Response (Subscribe-ID, Portal Redirect Related VSA(s)...)

Install Web-redirect and create


temporary L2-aware NAT host

L3 Packet (Except DHCP)

Handle Packets According to Redirect Policy.


Forwarded Packets Go Through L2-aware Host.

L3 Packet that
Hit Fwd Rule
L3 Packet

L3 Packet

L3 Packet
UE provided credentials
and portal-auth completes

CoA (User-name, Subscriber-ID, VSAs...) to Promote UE to an ESM Host

Trigger RADIUS to
Generate CoA

al_0377

Figure 210: Sequence of Events to Establish and Authenticate a Migrant User (continued)

Advanced Configuration Guide

Page 2043

Overview

UE

Temporary
L2-aware Host

ISA

CPM

RADIUS

Portal, DNS...
Servers

ESM Host Creation Request


(UE Info Including DHCP and RADIUS
Create real L2-aware NAT host
Update UE to State ESM

UE state created as IP assigned.


ISA stores up to 512 bytes
of DHCP options
Remove redirect. Normal L2 aware NAT
active for ESM host. Temporary L2-aware host
still exists to allow last packets from portal
to reach the UE.
ACK CoA

After 10 seconds temporary


L2-aware host is deleted
L3 Packet Normally Forwarded
al_0378

Figure 211: Sequence of Events to Establish and Authenticate a Migrant User

Page 2044

Advanced Configuration Guide

WiFi Aggregation and Offload Migrant User Support

Configuration
The authentication-policy as shown below is used to configure a RADIUS server, and is
applicable to the UEs in authenticated state.
subscriber-mgmt
authentication-policy "authentication-1" create
password "E40PedK6aqrEIpr2DEoJyVR8PQ3XkFF7" hash2
radius-authentication-server
source-address 192.0.2.1
router "management"
server 1 address 192.0.2.3 secret "6uuGli25Vtl49q0." hash2
exit
accept-authorization-change
include-radius-attribute
acct-session-id
circuit-id
remote-id
nas-port-id
nas-identifier
nas-port-type
pppoe-service-name
dhcp-options
dhcp-vendor-class-id
access-loop-options
mac-address
called-station-id
calling-station-id sap-string
tunnel-server-attrs

An isa-radius-policy is required for authentication from the ISA, as below this contains the
attributes to be sent in the access request message to the RADIUS server, which is also configured
in this policy.
aaa
isa-radius-policy "isa-policy-1" create
nas-ip-address-origin isa-ip
password "CAO6ALDnhyBJERE4xnXoW15MQ/hu74x5nDE7F.OJxHM" hash2
auth-include-attributes
called-station-id
calling-station-id
circuit-id
dhcp-options
dhcp-vendor-class-id
mac-address
nas-identifier
nas-port-id
nas-port-type
remote-id
exit
servers
router 1
source-address-range 192.168.0.2

Advanced Configuration Guide

Page 2045

Configuration

server 1 create
authentication
coa
ip-address 192.0.2.3
secret "CAO6ALDnhyBJERE4xnXoW15MQ/hu74x5nDE7F.OJxHM" hash2
no shutdown
exit
exit
exit
exit

The HTTP redirect policy is shown below, this is enforced on ISA while a UE is migrant and
contains the configurations defining the forwarding of traffic in this state.
subscriber-mgmt
http-redirect-policy "redirect-policy-1" create
url "http://66.185.84.163"
forward-entries
dst-ip 192.168.1.1 protocol udp dst-port 53
dst-ip 192.168.1.2 protocol udp dst-port 53
dst-ip 66.185.84.163 protocol tcp dst-port 80
dst-ip 10.0.0.1 protocol udp dst-port 67
dst-ip 10.0.0.1 protocol udp dst-port 68
exit
exit
exit

The NAT pool configuration for migrant and authenticated UEs is shown below.
vprn 10 customer 1 create
nat
inside
l2-aware
address 10.0.0.1/24
exit
exit
outside
pool "migrant-pool-1" nat-group 1 type wlan-gw-anchor create
address-range 192.168.2.0 192.168.2.255 create
exit
no shutdown
exit
pool "auth-pool-1" nat-group 1 type l2-aware create
address-range 192.168.3.0 192.168.3.255 create
exit
no shutdown
exit
exit
exit
exit

Page 2046

Advanced Configuration Guide

WiFi Aggregation and Offload Migrant User Support

The NAT policy for migrant UEs is as follows.


service
nat
nat-policy "migrant-policy" create
pool "migrant-pool-1" router 1
timeouts
tcp-established min 1
exit
exit
exit
exit

Below is the NAT policy for authenticated UEs.


service
nat
nat-policy "nat-auth-policy-1" create
pool "auth-pool-1" router 10
exit
exit
exit

The migrant user configuration under the soft-gre group-interface within the VPRN service is
shown below. This includes configuration for authentication, DHCP, and forwarding from the
ISA, as defined in the sections above. The migrant user related configuration can be specified per
VLAN tag (or range) under soft-gre interface, where each VLAN tag represents an SSID.

vprn 1 customer 1 create


subscriber-interface "sub-int-1" create
address 10.0.0.1/24
group-interface "soft-gre-1" softgre create
sap-parameters
sub-sla-mgmt
def-sla-profile "sla-profile-1"
def-sub-id use-auto-id
def-sub-profile "sub-profile-1"
sub-ident-policy "sub_ident"
exit
exit
dhcp
proxy-server
emulated-server 10.0.0.1
lease-time hrs 1
no shutdown
exit
trusted
lease-populate 32767
gi-address 10.0.0.1
no shutdown
exit

Advanced Configuration Guide

Page 2047

Configuration

authentication-policy "authentication-1"
host-connectivity-verify
soft-gre
authentication
authentication-policy "isa-policy-1"
exit
gw-address 192.168.0.1
mobility
hold-time 0
trigger data iapp
exit
router 1
wlan-gw-group 1
vlan-tag-ranges
range start 100 end 100
authentication
authentication-policy "isa-policy-1"
exit
data-triggered-ue-creation
dhcp
active-lease-time min 12
initial-lease-time min 5
l2-aware-ip-address 10.0.0.10
primary-dns 192.168.1.1
secondary-dns 192.168.1.2
no shutdown
exit
http-redirect-policy "redirect-policy-1"
nat-policy "migrant-policy"
exit
exit
no shutdown
exit
exit
exit
exit

Page 2048

Advanced Configuration Guide

WiFi Aggregation and Offload Migrant User Support

Conclusion
Migrant user support is a useful feature that optimizes system resources (public IP addresses, ESM
hosts, CPU processing, etc.) to provide the scale and performance required in live hot-spot and
home-spot WiFi deployments at peak times.

Advanced Configuration Guide

Page 2049

Conclusion

Page 2050

Advanced Configuration Guide

Glossary

6PE IPv6 Provider Edge router. An MPLS IPv4 core network that supports IPv6 domains which communicate over an IES service.
6VPE IPv6 Provider Edge router with IP-VPN Services. An MPLS IPv4 core network that supports the
communication using IPv6 VPRN services.
AA Application Assurance
AARP Application Assurance Redundancy Protocol
ARP Address Resolution Protocol
Bridged CO Bridged Central Office
B-DA Backbone destination MAC address
BFD Bi-Directional Forwarding Detection
BGP Border Gateway Protocol
B-MAC The backbone source and destination MAC address fields defined in the 802.1ah provider MAC
encapsulation header
BNG Broadband Network Gateway
BSA Broadband Service Aggregator
BSAN Broadband Service Access Node
BSM Basic Subscriber Management
BSR Broadband Service Router
BTV Broadcast TV
B-VPLS Backbone VPLS
CBS Committed Burst Size
CCM Continuity Check Messages
CE Customer premises equipment dedicated to one particular business/enterprise.
CHAP Challenge-Handshake Authentication Protocol
CIR Committed Information Rate

Advanced Configuration Guide

Page 2051

C-MAC Customer MAC


CO Central Office
CSC-CE Peering router managed and operated by the Customer Carrier that is connected to CSC-PEs
for purposes of using the associated CSC IP VPN services for backbone transport. The CSC-CE may
attach directly to CEs if it is also configured to be a PE for business VPN services.
CSC-PE A PE router managed and operated by the Super Carrier that supports one or more CSC IP VPN
services possibly in addition to other traditional PE services.
CSPF Constraint-Based Shortest Path First
DE Discard-Eligible
DEI Drop Eligibility Indicator
DHCP Dynamic Host Configuration Protocol
DHCPv6 Dynamic Host Configuration Protocol for IPv6
DSCP Differentiated Services Code Point
eBGP External Border Gateway Protocol
Epipe Ethernet P2P VLL Service
eLER Egress Label Edge Router
ERO Explicit Router Object
ESM Enhanced Subscriber Management
FEC Forwarding Equivalence Class
FRR Fast Reroute
GMPLS Generalized Multi-Protocol Label Switching
iBGP Interior Border Gateway Protocol
ICB Inter-Chassis Backup
ICMP Internet Control Message Protocol
IES Internet Enhanced Service
IGP Interior Gateway Protocol
iLER Ingress Label Edge Router
IMPM Ingress Multicast Path Management
IPoE IP over Ethernet
I-VPLS A field of the backbone service instance tag that identifies the backbone service instance of a
frame
LDP FRR Label Distribution Protocol Fast Re-Route
LDPoRSVP LDP over RSVP
LSA Link State Advertisement

Page 2052

Advanced Configuration Guide

LSP Label Switched Path


LUDB Local User Data Base
MBB Make-Before-Break
MBS Maximum Burst Size
MC-APS Multi-chassis Automatic Protection Switching
MC-EP Multi-Chassis Endpoint
MC-LAG Multi-Chassis Link Aggregation
MEP Maintenance End Point
MMRP Multiple MAC Registration Protocol
MP-BGP Multi-Protocol BGP
MSAP Managed Service Access Point
MTU Multi-Tenant Unit
NAT Network Address Translation
NH Next-Hop
OAM Operation, Administration and Management
OIL Outgoing Interface List
P2MP Point-to-Multipoint
PAP Password authentication protocol
PBB Provider Backbone Bridging
PBB-Epipe

A combination of the best of the PBB and Epipe

PBB-VPLS

A combination of the best of the PBB and VPLS

PE Edge router managed and operated by the Customer Carrier that connects to CEs to provide business VPN or Internet services.
PIR Peak Information Rate
PLR Point of Local Repair
PPPoE Point-to-Point Protocol over Ethernet
QoS Quality of Service
RADIUS Remote Authentication Dial In User Service
Routed CO Routed Central Office
RPF Reverse Path Forwarding
RR Route Reflector
RTM Routing Table Manager
SAP Service Access Point

Advanced Configuration Guide

Page 2053

SDP Service Distribution Point


SHCV Subscriber Host Connectivity Verification
SLA Service Level Agreement
Spoke-SDP Spoke Service Distribution Point
SRLG Shared Risk Link Groups
TCN Topology Change Notification
TE Traffic Engineering
TED Traffic Engineering Database
T-LDP Targeted LDP
TPSDA Triple Play Service Delivery Architecture
TTM Tunnel Table Manager
VLL Virtual Leased Line
VPLS Virtual Private LAN Service
VPN-IPv6 Virtual Private Network address family for IPv6 addressing.
VPRN Virtual Private Routed Network
VSA Vendor Specifc Attribute
WRED Weighted Random Early Detection

Page 2054

Advanced Configuration Guide

Index
A
AA Asymmetry Removal 71
configuration 74
AARP 76
network to subscriber 84
subscriber to network 85
overview 73
aggregate route indirect next-hop option 25
configuration
aggregate keyword 29
indirect keyword 28
overview 27
ARP hosts 107
configuration 111
bridged environments 111
mobility 129
persistency 130
RADIUS 116
routed environment 114
session limitation options 132
session timeout 121
setup and debugging 116
overview 110
Bridged and Routed CO 110
associating communities with static and
aggregate routes 135
configuration 140
aggregate routes with communities 153
statis routes with communities 144
VPRN IPv4 142
overview 138

B
BGP anycast 163
configuration 171
anycast interface 171
bgp 178
igp 174
ldp 176

Advanced Configuration Guide

GRT 166
ip-vpn 168
BGP multi-homing for VPLS networks
configuration 213
access signalling 231
core PE service 217
MTU service 224
service level 216
show and debug options 237
overview 211
BGP VPLS 277
configuration 282
PE 285
Pseudowire Templates 285
overview 280
bidirectional forwarding detection 315
317
configuration 319
base configuration 321
IES 336
IPSec tunnels 351
IS-IS 327
OSPF 329
OSPF PE-CE adjacencies 348
PIM 331
RSVP 341
static 333
T-LDP 345
VRRP 355
bridged CO 363
configuration 372
host-1
BSA/BSR 375
host-2
BSA/BSR 376
host-3
BSA/BSR 378
local DHCP server 381
RADIUS 380

Page 2055

Index

setup and debugging 383


host-2
debug 388
host-3
debug 395
setup and debugging
host-1
debug 384
overview 366

C
carrier supporting carrier IP VPN 449
configuration 453
overview 451
class fair hierarchical policing for SAPs 405
configuration 419
access 426
applying 429
parent policer and arbiters 423
policers 419
show command output 434
overview 408
hierarchical policing 413
policer buckets 410
policers 408

D
deterministic large scale NAT44 475
configuration 481
case 1 486
results 491
case 2 496
results 501
case 3 503
results 507
inverse mapping 508
offline approach 510
online approach 509
pre-requisites 481
simultaneous support 512
overview 477
algorithm 478

Page 2056

deterministic mapping 479


mapping rules 480
DF decision 227
DHCP hosts 979
advanced topics
connectivity verification 1011
high availability 1006
host mobility 1020
lease state persistency 1006
number of DHCP hosts 1009
configuration 986
DHCP relay agent 987
DHCP snooping 986
host session 1000
lease state 995
option 82 989
overview 982
bridged and routed environments 982
bridged CO network topology 982
DHCP protocol 984
routed CO network topology 982

E
ESM IPv4 multicast in SRRP 629
configuration 633
control plane filters 657
data plane filters 660
debug 654
ESM SRRP configuration overview 633
IGMP on group interfaces 639
IGMP policy 641
IPoE walkthrough 643
MCS 651
PPPoE walkthrough 648
overview 631
ESMv6 IPoE dual stack hosts 663
advanced topics 699
configuration 674
DHCP proxy server 680
IPv6 subscriber prefixes 679
lease states 689
LUDB 687

Advanced Configuration Guide

operation 694
RADIUS 685
router advertisements 682
scenario 1 RADIUS 674
scenario 2 LUDB 676
troubleshooting 696
overview 666
DHCPv6 protocol 669
dual stack hosts 666
prefix delegation 673
routed gateway service 668
ESMv6 PPPoE dual stack hosts 707
configuration 713
RADIUS 721
dual stack for bridged gateway 722
dual stack for routed gateway 722
router advertisements 723
service 714
bridged gateway 714
routed gateway 717
overview
DHCPv6 712
dual stack 709
prefix delegation 712
SLAAC 712

F
flexible authentication model in ESM 743
configuration 747
access Ethernet port 748
auto-sub-id 749
capture SAP 748
DHCP relay - no authentication 751
MSAP policy 749
PPPoE policy 749
subscriber interface 750
troubleshooting 786
overview 745
full IGP shortcuts 789
Advertising RSVP LSP Tunnel Links 809
configuration 794
EMPC 809

Advanced Configuration Guide

IGP 794
LDP and RSVP shortcuts 796
LDP shortcut route resolution 802
LDP static route 798
LDP/RSVP LSP shortcut 818
LDP/RSVP-TE LSP shortcut 826
RSVP shortcut route resolution 806
RSVP static route 800
ECMP considerations 809
overview 791

G
G.8032 ring resiliency 833
configuration 838
overview 835
ring protection 836

I
IMPM 860
configuration 865
Paths and Planes 861
Paths Connecting to Switch Fabric Planes 860
show output 884
inter-area TE point-to-point LSPs 901
configuration 907
ABR Node Protection 913
admin groups 918
bypass for ABR protection 915
MPLS LSP 909
MPLS Path 909
Prerequisites 907
SRLG 921
overview 905
inter-AS model C for VLL 927
configuration 931
BGP 932
policy 935
service 936
troubleshooting 937
overview 929
network setup 930

Page 2057

Index

IP/GRE termination 949


configuration 955
advanced topics 974
BFD private tunnel interfaces 971
interfaces 958
IPSec configuration 968
IPSEc tunnel mode 967
tunnel groups and restrictions 955
tunnel ISA MDA 955
tunneling using IPSec tunnel mode 967
tunneling via BGP peering 964
tunneling via OSPFv2 peering 965
tunneling via static route 962
unprotected GRE tunnel 960
overview 952
7750 SR-12/SR-7 implementation 953

L
LDP over RSVP 1023
configuration 1027
IP/MPLS network 1027
overview 1025
topology 1026
LDP VPLS using BGP auto discovery 1059
configuration
1064
VPLS PE 1068
auto sdp creation using LDP 1068
auto-provisioned SDPs 1070
pre-provisioned SDPs 1082
provisioned SDPs using RSVP 1069
pw templates 1068
overview 1062
BGP-AD 1063

M
managed SAPs with routed CO 1091
configuration
1096
accounting policy 1097
actual values 1111
authentication policy 1096

Page 2058

configuration tips 1117


connect PPPoE 1109
egress remarking 1115
ESM 1101
MSAP policy 1103
MSAP with redundant configurations 1114
PPPoE 1106
queue optimization 1116
SAP ingress policy 1099
user files 1108
verify values 1110
VPLS with capture SAP 1104
overview 1093
authentication and VSAs 1095
capture SAP 1094
topology 1093
trigger packets 1094
MC-APS and PW redundancy interworking,
Advanced Configuration Guide, 7750 SR OS,
7450 ESS OS, 7710 SR OS 1293
MC-APS with PW-RED 1293
configuration 1298
overview 1295
MC-APS 1295
network topology 1296
pw redundancy 1296
MC-LAG 1353
configuration 1358
forced switchover 1378
ICB spoke SDPs 1371
LAG on PEs 1360
MC-LAG 1360
pseudowire 1365
VPLS 1377
overview 1355
MC-LAG 1355
network resiliency 1357
pseudowire redundancy 1355
topology 1356
mc-ring with ESM
configuration 1389
base topology 1390

Advanced Configuration Guide

mc-ring configuration 1390


multicast service configuration 1407
ntp configuration 1390
unicast services 1397
MCS verification 1402
ring failure verification 1405
verification 1401
overview 1384
mc-ring 1384
MPLS LDP FRR using ISIS as IGP 1123
configuration 1126
overview 1125
Network Topology 1578
multicast in a VPRN II
overview 1209
multicast in VPRN I 1147
configuration 1155
anycast RP 1182
auto-discovery 1166
common 1155
PE global 1156
customer edge multicast 1170
PE BGP auto-discovery 1194
PE VPRN 1160
PE VPRN multicast 1166
PIM any source multicast 1169, 1177
PIM auto-discovery 1169
PIM source-specific multicast 1188
overview 1152
MVPN 1154
network topology 1152
PIM any source multicasting 1177
multicast in VPRN II 1205
configuration 1211
common 1211
PE global 1211
PE VPRN 1216
auto-discovery and RSVP PMSI
establishment 1235
MDT AFI SAFI 1256
PMSI using mLDP 1216
PMSI using RSVP-TE 1233

Advanced Configuration Guide

unicast 1233
Multi-Chassis Endpoint for VPLS Active/Standby
Pseudowire
configuration 1267
overview 1263
Multi-Chassis Endpoint with Mesh
Resiliency 1264
Multi-Chassis Endpoint with Square
Resiliency 1265
Network Topology 1266
VPLS Pseudowire Redundancy 1264
Multi-chassis IPSec redundancy 1315
configuration 1319
guidelines 1351
overview 1317
Multi-Chassis LAG and Pseudowire Redundancy
Interworking, Advanced Configuration Guide,
7750 SR OS, 7450 ESS OS, 7710 SR
OS 1353
multi-segment PW routing 1415
configuration 1421
active/passive signaling 1434
BGP routes 1428
building routing table 1425
dynamic PWs on the T-PEs 1432
explicit paths 1426
Inter-AS MS-PW routing 1452
intra-AS MS-PW routing 1438
MS-PW using BGP routing 1440, 1453
MS-PW using explicit paths 1450
MS-PW using static routing 1448
routing enablement 1422
spoke-sdp-fec templates and filters 1438
spoke-sdp-fec timers 1436
standby signaling 1437
static routes 1426
overview 1418

N
NAT with ESM 1549
configuration 1554
advanced topics 1564

Page 2059

Index

RADIUS 1564
binding inside, outside, ESM host 1562
hardware 1554
NAT inside 1560
NAT outside 1561
NAT subscriber 1559
operation 1567
service 1555
overview 1551
server functionality 1553

MAC flush 1616


MMRP for flooding 1610
services 1604
overview 1602

operational groups (oper-group) 234

pseudowire QoS 1667


configuration 1674
overview 1669
egress QoS 1672
ingress and egress queue groups 1675
ingress FP and egress port queue group
instances 1676
ingress QoS 1671
network QoS policy 1678

P2P LSP 1639


configuration 1645
debugging 1663
LDP 1652
LSPs 1646
policies 1655
rsvp-te 1658
overview 1641
LSP establishment 1643
packet forwarding 1641
terminology 1642
testbed topology 1644

QoS Architecture 1693


configuration 1696
buffering 1703
egress QoS policy 1708
remarking 1709
network ports 1711
network QoS policy
1711
classification 1711
remarking 1712
network queue QoS policy 1715
buffer pools 1718
queue management 1718
queue rates 1727
queue sizing 1722
scheduling 1729
WRED 1724
network/access ports 1696
policies 1696
remarking 1707
scheduling 1704
service ingress policy 1698
show command output 1731
overview 1695
QoS components 1695

PBB-Epipe 1575
configuration 1579
B-VPLS and PBB 1581
Epipe 1580, 1585
flood avoidance 1587
show commands 1594
overview 1577
topology 1578
PBB-VPLS 1599
configuration 1603
access dual-homing 1620
B-VPLS 1605
B-VPLS/I-VPLS show and debug
commands 1633
I-VPLS 1608

Page 2060

Advanced Configuration Guide

configuration 1972
group interface 1973
SRRP 1973
static host 1973
monitoring in-band communications
path 1977
multi-chassis synchronization 1979
redundant interface 1980
subscriber management 1979
peer state 1978
subscriber interface 1972
redundant default gateway 1972
overview 1970
SRRP protocol 1971
summary 1969

RADIUS-triggered dynamic data service


provisioning 1737
configuration 1742
building block
CLI snippets 1753
control channel 1743
dynamic services policy 1743
python script 1750
RADIUS accounting 1754
RADIUS attributes 1746
debugging 1771
RSVP-signaled point-to-multipoint LSPs
configuration
1835
IGMP join 1854
influence IGP metric 1856
intelligent remerge 1862
IP/MPLS network 1835
mapping MC traffic 1847
egress LER 1849
ingress LER 1847
OAM tool 1852
P2MP RSVP LSP 1841
overview
topology 1834

S
spoke termination for IPv6-6VPE 1935
configuration 1940
overview 1937
SRLG 1877
configuration 1881
database 1896
IP/MPLS networks 1881
on-line verification 1885
SRLG for FRR 1888
standby path 1893
overview 1879
topology 1880
SRRP 1967

Advanced Configuration Guide

stateful firewall 89
configuration
95
topology 96
overview 91
DOS protection 94
gateway filtering 93
stateful filtering 91
virtual/zone-based FW 94
synchronous Ethernet 2001
configuration 2011
when gl-selection mode is disabled 2011
when gl-selection mode is enabled 2014
overview 2004
central sub-system 2006
SSM 2009
sub-system architecture 2007
syncE chains 2010

V
VPRN Inter-AS 2019
configuration 2024
MP-eBGP session 2024
overview 2021
intro 2021
VPRN Inter-AS VPN Model C
BGP group parameters 2024

Page 2061

Index

MP-eBGP session 2024


Policy Options 2026

W
WIFI aggregation and offload 2035
overview 2037
migrant user 2037
openSSID based on portal
authentication 2038

Page 2062

Advanced Configuration Guide

You might also like