Juniper Enterprise WAN Design

Enterprise WAN Domain Solutions
Enterprise WAN Aggregation and Internet Edge

Design and Implementation Guide
Published: 2014-02-23
Copyright 2014, Juniper Networks, Inc.
Juniper Networks, Inc.

1194 North Mathilda Avenue
Sunnyvale, California 94089
USA
408-745-2000
www.juniper.net
Copyright 2014, Juniper Networks, Inc. All rights reserved.
Juniper Networks, Junos, Steel-Belted Radius, NetScreen, and ScreenOS are registered trademarks of Juniper Networks, Inc. in the United
States and other countries. The Juniper Networks Logo, the Junos logo, and JunosE are trademarks of Juniper Networks, Inc. All other
trademarks, service marks, registered trademarks, or registered service marks are the property of their respective owners.
Juniper Networks assumes no responsibility for any inaccuracies in this document. Juniper Networks reserves the right to change, modify,
transfer, or otherwise revise this publication without notice.
Enterprise WAN Domain Solutions Enterprise WAN Aggregation and Internet Edge Design and Implementation Guide
All rights reserved.
The information in this document is current as of the date on the title page.
YEAR 2000 NOTICE
Juniper Networks hardware and software products are Year 2000 compliant. Junos OS has no known time-related limitations through the
year 2038. However, the NTP application is known to have some difficulty in the year 2036.
END USER LICENSE AGREEMENT

The Juniper Networks product that is the subject of this technical documentation consists of (or is intended for use with) Juniper Networks
software. Use of such software is subject to the terms and conditions of the End User License Agreement (EULA) posted at
http://www.juniper.net/support/eula.html. By downloading, installing or using such software, you agree to the terms and conditions of
that EULA.
ii
Table of Contents
Part 1
Enterprise WAN Overview and Design Considerations
Chapter 1
Enterprise WAN Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
About Juniper Networks Validated Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Audience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Enterprise WAN Domain Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Enterprise WAN Problem Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Juniper Networks Enterprise WAN Solution Overview . . . . . . . . . . . . . . . . . . . . . . . 8
WAN Aggregation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Internet Gateway . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Secure Overlay (IPsec VPN) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Enterprise WAN Solution Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Improved Operational Efficiency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Reduced Operational Expense . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Improved Flexibility and Value for Investment . . . . . . . . . . . . . . . . . . . . . . . . . 15
Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Carrier-Class Reliability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Chapter 2
Enterprise WAN Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Enterprise WAN Design Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Ease of Deployment/Designed for Flexibility and Scalability . . . . . . . . . . . . . 18
Resilient and Secure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Ease of Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Services Ready . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Enterprise WAN Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
WAN Aggregation Deployment Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
WAN Aggregation Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Aggregation Hub Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
WAN Aggregation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Internet Gateway Role . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
VPN Termination Role . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
WAN Aggregation Design Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
WAN Aggregation Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Aggregation Hub Transport . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Aggregation Hub Traffic Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Leased-Line Traffic Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Layer 3 VPN Traffic Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Secure Overlay Traffic Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
iii
Enterprise WAN Aggregation and Internet Edge Design and Implementation Guide
Aggregation Hub Transport: Routing Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

BGP Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
OSPF Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Multicast Design at the Aggregation Hubs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
High Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Hardware Redundancy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Dual-Homing to the Aggregation Hubs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
LAG and Multi-Chassis LAG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Failover Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Class of Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Routing Protocol Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Application Layer Gateways . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Securing Enterprise Traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Performance and Scale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Network Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Junos Traffic Vision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
SNMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
System Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Hardware Platforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Remote Branch Design Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Remote Site Transport Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Leased-Line Transport . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
MPLS (Layer 3 VPN) Transport . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Secure Overlay (GRE over IPsec) Transport . . . . . . . . . . . . . . . . . . . . . . . 48
Remote Site Routing Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Leased-Line Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Layer 3 VPN Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Secure Overlay Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Remote Site High Availability Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Single Remote Site CPE with Single Transport . . . . . . . . . . . . . . . . . . . . 56
Single Remote Site CPE with Backup Transport . . . . . . . . . . . . . . . . . . . . 57
Redundant Remote Site CPE with Primary and Backup Transport . . . . . 58
Remote Site Class-of-Service Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Layer 3 VPN and Leased-Line Class-of-Service Design . . . . . . . . . . . . . . 61
Secure Overlay Class-of-Service Design . . . . . . . . . . . . . . . . . . . . . . . . . 62
Remote Site Security Design Considerations . . . . . . . . . . . . . . . . . . . . . . . . . 64
Leased-Line Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Layer 3 VPN Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Secure Overlay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Internet Gateway Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Internet Edge Transport . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Internet Gateway Routing Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Internet Gateway High Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Class of Service on the Internet Gateway at Aggregation Hub 1 . . . . . . . . . . . 70
Class of Service on the Internet Gateway at Aggregation Hub 2 . . . . . . . . . . . 71
Internet Gateway Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Internet Gateway Traffic Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
iv
Table of Contents
Solution Failover Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

Failure of Primary Internet Link . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
Primary Internet Gateway Failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Primary VPN Router Failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Primary WAN Aggregation Router Failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Primary WAN Aggregation Site Failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
Part 2
Validated Reference Designs
Chapter 3
Using the Validated Reference Designs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

About the Validated Reference Designs . . . . . . . . . . . . . . . . . . .
How to Use the Validated Reference Designs . . . . . . . . . . .
For More Information About Statements and Commands .
Lab Testing Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Chapter 4
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
89
89
89
90
Base Configuration for Aggregation Hub 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

Base Configuration for Aggregation Hub 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Chapter 5
Configuring the Internet Gateway on Aggregation Hub 1 . . . . . . . . . . . . . . . 133

Configuring the Internet Gateway on Aggregation Hub 1 . . . . . . . . . . . . . . . . . . . . 133
Chapter 6
Base Configuration for Aggregation Hub 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 159

Base Configuration for Aggregation Hub 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
Chapter 7
Configuring the Internet Gateway on Aggregation Hub 2 . . . . . . . . . . . . . . 199

Configuring the Internet Gateway on Aggregation Hub 2 . . . . . . . . . . . . . . . . . . . 199
Chapter 8
Configuring the Network Management System . . . . . . . . . . . . . . . . . . . . . . . 221

Configuring the Network Management System . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
Chapter 9
Adding Routing Engine Protection to the Aggregation Hubs . . . . . . . . . . . 227

Adding Routing Engine Protection to the Enterprise WAN Network . . . . . . . . . . . 227
Chapter 10
Connecting a Small Branch to Aggregation Hub 1 over Leased-Lines . . . . 245

Connecting a Small Branch to Aggregation Hub 1 over Leased-Lines . . . . . . . . . 245
Chapter 11
Connecting a Small Branch to Dual-Homed Aggregation Hubs over the

Internet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281
Internet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281
Chapter 12
Connecting a Medium Branch to Dual-Homed Aggregation Hubs over

Layer 3 VPN with Internet Backup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363
Connecting a Medium Branch to Dual-Homed Aggregation Hubs over Layer 3
VPN with Internet Backup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363
Chapter 13
Connecting a Large Branch to Dual-Homed Aggregation Hubs over Layer

3 VPN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 437
Connecting a Large Branch to Dual-Homed Aggregation Hubs over Layer 3
VPN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 437
Chapter 14

3 VPN with Internet Backup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 545
Connecting a Large Branch to Dual-Homed Aggregation Hubs over Layer 3 VPN
with Internet Backup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 545
Chapter 15
Adding WAN Acceleration to the Enterprise Network . . . . . . . . . . . . . . . . . 665

Example: Configuring WAN Acceleration Between a Branch and Aggregation
Hub Using WCCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 665
Hub Using WCCP-Lite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 677
Hub Using WCCP Full . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 685
Chapter 16
Enterprise WAN Troubleshooting Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . 697

Troubleshooting Scenario: IPsec Branch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 698
Troubleshooting Scenario: Stateful Firewall and NAT Troubleshooting . . . . . . . 700
Troubleshooting Scenario: Convergence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 703
Troubleshooting Scenario: Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 705
Troubleshooting Scenario: Class of Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 710
Part 3
Appendix
Appendix A
Alternate Configuration Aggregation and Branch Using MX80 with

Services MIC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 737
Configuring the MX80 as an IPSec VPN Termination Router . . . . . . . . . . . . . . . . 737
vi
List of Figures
Part 1
Chapter 1

Figure 1: The Various Domains in the Enterprise WAN . . . . . . . . . . . . . . . . . . . . . . . 5
Figure 2: The Enterprise WAN Domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Figure 3: A Public Enterprise WAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Figure 4: Hybrid Overlay Enterprise WAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Figure 5: A Private Enterprise WAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Figure 6: WAN Aggregation of Enterprise Remote Sites onto the Enterprise
WAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Figure 7: The Deployment Scenarios Tested and Delivered by the Enterprise
WAN Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Figure 8: Enterprise WAN Internet Gateway Topology . . . . . . . . . . . . . . . . . . . . . . . 13
Chapter 2

Figure 9: Enterprise WAN Reference Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 20
Figure 10: WAN Aggregation Architecture Incorporates all Remote Site Transports
into a Single Aggregation Tier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Figure 11: The Topology of the WAN Aggregation Hub Routers . . . . . . . . . . . . . . . . 27
Figure 12: Traffic Flow from Enterprise Remote / Enterprise HQ to the Various
Network Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Figure 13: Return Traffic Flow for Private Leased-Line Remote Sites . . . . . . . . . . . 30
Figure 14: Traffic Flow From Layer 3 VPN-Connected Remote Site to
Enterprise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Figure 15: Return Traffic to Layer 3 VPN-Connected Remote Sites . . . . . . . . . . . . 32
Figure 16: Traffic Flow from Secure Overlay Remote Sites to the Enterprise . . . . . 33
Figure 17: Return Traffic Flow to Secure Overlay Enterprise Remote Site . . . . . . . 34
Figure 18: BGP Design at the Aggregation Hub . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Figure 19: OSPF Design at the Aggregation Hub . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Figure 20: Multicast Design at the WAN Aggregation Hub . . . . . . . . . . . . . . . . . . . 38
Figure 21: Leased-Line Transport from Enterprise Remote Site . . . . . . . . . . . . . . . 47
Figure 22: Managed MPLS Connection into the Enterprise WAN . . . . . . . . . . . . . . 48
Figure 23: Enterprise Remote Site Connected via Secure Overlay . . . . . . . . . . . . . 49
Figure 24: Secure Overlay Design for Connecting Remote Sites to the Enterprise
WAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Figure 25: Layer 3 VPN Routing Between Remote Site and Enterprise WAN . . . . 55
Figure 26: Secure Overlay Routing Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Figure 27: Backup Secure Overlay Tunnel Created from Single Uplink Remote
Site . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Figure 28: Layer 3 VPN with Secondary CPE and Backup Layer 3 VPN Service . . 58
Figure 29: Inbound CoS to Small Remote Site Using Leased-Line Access . . . . . . . 61
vii
Figure 30: Outbound CoS to Small Remote Site Using Leased-Line Access . . . . 62
Figure 31: Secure Overlay Class-of-Service Actions Between Hub and
Remote . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Figure 32: Secure Overlay Class of Service Between Remote Site and
Enterprise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Figure 33: The Internet Gateway Role at the WAN Aggregation Site . . . . . . . . . . . 67
Figure 34: Routing Design at the Internet Gateway . . . . . . . . . . . . . . . . . . . . . . . . 68
Figure 35: NAT and Firewall Applied to Internet Gateway Traffic . . . . . . . . . . . . . . 72
Figure 36: Return Traffic Flow from Hosted Services to the Internet . . . . . . . . . . . 73
Figure 37: Aggregation Hub 2 Traffic Flow for Stateful Firewall and NAT . . . . . . . . 73
Figure 38: Return Traffic Flow on Aggregation Hub 2 . . . . . . . . . . . . . . . . . . . . . . . 74
Figure 39: Traffic Flow Inbound from Data Center, Leased-Line, or Layer 3 VPN
to Hosted Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Figure 40: Return Traffic Flow from Hosted Services to Leased-Line, Layer 3
VPN, and Data Center. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Figure 41: Traffic Flow from Internet Connected Branches (GRE over IPsec) to
Hosted Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Figure 42: Outbound Traffic Flow from Hosted Services to Internet-Connected
Branch Sites (GRE over IPsec) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Figure 43: The Flow of Traffic Between Internet-Connected Branches and the
Other Enterprise Entities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Figure 44: Primary ISP Failover Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
Figure 45: Failure of Primary Internet Gateway . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Figure 46: Failure of Primary VPN Router . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Figure 47: Primary WAN Aggregation Router Failure . . . . . . . . . . . . . . . . . . . . . . . . 83
Figure 48: Primary WAN Aggregation Site (Complete Site) Failure Scenario . . . . 84
Part 2
Chapter 3

Figure 49: The Enterprise WAN Solution Testing Lab Architecture . . . . . . . . . . . . 90
Chapter 4
Base Configuration for Aggregation Hub 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

Figure 50: Aggregation Hub 1 Test Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Figure 51: Interface and VR Configuration at Aggregation Hub 1 . . . . . . . . . . . . . . 94
Figure 52: BGP Design at Aggregation Hubs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Figure 53: OSPF Design at Aggregation Hubs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
Figure 54: Multicast Design at Aggregation Hubs . . . . . . . . . . . . . . . . . . . . . . . . . 103
Figure 55: Aggregation Hub 1 VR and Interface Configuration . . . . . . . . . . . . . . . . 117
Figure 56: Internet User Traffic Flow (SFW + NAT) To and From Enterprise
Hosted Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
Figure 57: Interface and VR Configuration for Internal User Access to Hosted
Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
Figure 58: Class-of-Service Configuration Between Branch and Aggregation
Hub . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
Chapter 5
Configuring the Internet Gateway on Aggregation Hub 1 . . . . . . . . . . . . . . . 133

Figure 59: The Test Topology of Aggregation Hub 1 . . . . . . . . . . . . . . . . . . . . . . . . 133
Figure 60: Inbound NAT and Stateful Firewall for Hosted Services on the Internet
Gateway . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
viii
List of Figures
Figure 61: Routing Policy Configuration on the Internet Gateways . . . . . . . . . . . . 143

Figure 62: Routing Protocol Design at the Internet Gateway . . . . . . . . . . . . . . . . 149
Figure 63: Aggregation Hub 1 VR and Interface Configuration . . . . . . . . . . . . . . . 150
Chapter 6
Base Configuration for Aggregation Hub 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 159

Figure 64: The Test Topology of Aggregation Hub 2 . . . . . . . . . . . . . . . . . . . . . . . 160
Figure 65: OSPF Design at the Aggregation Hubs . . . . . . . . . . . . . . . . . . . . . . . . . 167
Figure 66: Aggregation Hub 2 VR and Interface Configuration . . . . . . . . . . . . . . . 182
Figure 67: Traffic Flow for Access to Hosted Services Through Aggregation Hub
2 (for External Users) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
Figure 68: Incoming Traffic Flow to Hosted Services from Layer 3 VPN /
Leased-Line Transport . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
Chapter 7
Configuring the Internet Gateway on Aggregation Hub 2 . . . . . . . . . . . . . . 199

Figure 69: The Test Topology of Aggregation Hub 2 . . . . . . . . . . . . . . . . . . . . . . . 199
Figure 70: Routing Configuration at the Internet Gateways . . . . . . . . . . . . . . . . . 202
Chapter 10
Connecting a Small Branch to Aggregation Hub 1 over Leased-Lines . . . . 245

Figure 71: Remote Site Test Topology Using Leased-Line Transport . . . . . . . . . . 246
Figure 72: Leased-Line Remote Branch Configuration . . . . . . . . . . . . . . . . . . . . . 248
Figure 73: Routing and Interface Configuration for Leased-Line Branches . . . . . . 251
Chapter 11

Internet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281
Figure 74: Test Lab Topology for Small Sites Connecting to Dual Home
Aggregation Hubs over the Internet (GRE over IPsec) . . . . . . . . . . . . . . . . . . 282
Figure 75: VPN Termination Router Configuration at Aggregation Hub 1 . . . . . . . 284
Chapter 12
Connecting a Medium Branch to Dual-Homed Aggregation Hubs over

Layer 3 VPN with Internet Backup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363
Figure 76: Test Lab Topology Connecting Medium Branch over Layer 3 VPN with
Backup GRE over IPsec Tunnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365
Figure 77: Routing Configuration for Internet-Connected Branches (Dual
Homed) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366
Chapter 13

3 VPN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 437
Figure 78: Test Lab Topology for Large Remote Site Using Redundant CEs to
Connect to Redundant Layer 3 VPN Carriers . . . . . . . . . . . . . . . . . . . . . . . . . 439
Figure 79: Routing Configuration for Large Remote Site Using Redundant CEs
to Connect to Redundant Layer 3 VPN Providers . . . . . . . . . . . . . . . . . . . . . 440
Chapter 14

3 VPN with Internet Backup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 545
Figure 80: Test Lab Configuration Connecting Large Remote Branch with Primary
Layer 3 VPN and Backup GRE over IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . . . 547
Chapter 15
Adding WAN Acceleration to the Enterprise Network . . . . . . . . . . . . . . . . . 665

Figure 81: WAN Acceleration Implemented as Part of the EWAN Solution . . . . . 666
Figure 82: WAN Acceleration Using WCCP-Lite . . . . . . . . . . . . . . . . . . . . . . . . . . 678
Figure 83: WAN Acceleration Employing WCCP Full Package . . . . . . . . . . . . . . . 687
ix
Part 3
Appendix
Appendix A
Alternate Configuration Aggregation and Branch Using MX80 with

Services MIC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 737
Figure 84: Test Lab Configuration that Employs an MX80 as the VPN Termination
Router . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 738
List of Tables
Part 1
Chapter 1

Table 1: Enterprise Remote Site Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 12
Chapter 2

Table 2: Enterprise WAN Class of Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Table 3: EWAN Solution Performance and Scale Goals . . . . . . . . . . . . . . . . . . . . . 44
Table 4: Enterprise WAN Remote Site Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Table 5: Enterprise WAN Class-of-Service Values . . . . . . . . . . . . . . . . . . . . . . . . . 59
Table 6: Feature Support Comparison for WCCP & WCCP-Lite . . . . . . . . . . . . . . 86
Part 2
Chapter 3

Table 7: Equipment Used in the Solution Validation Topology . . . . . . . . . . . . . . . . 91
xi
xii
PART 1
Enterprise WAN Overview and Design

Considerations
CHAPTER 1
Enterprise WAN Overview

Introduction
The network is a key component in the success of a modern enterprise as it connects
users to business applications and services. A fast and reliable WAN service that connects
all of an organizations offices is no longer a luxuryit is crucial to business success. The
productivity of a workforce can be attributed to and enhanced by the quality of the
enterprise WAN network. As the WAN has grown and become more important, the
operational and financial challenges of operating the network have become more of a
burden to organizations. The challenges of operating the WAN need to be addressed in
a way that enhances not only performance and reliability, but also security, privacy, and
compliance. A complete enterprise WAN network architecture can effectively address
this growing challenge. Several trends in the enterprise have had a negative effect on
complexity, network performance, and scale.
The first trend is the explosion of Internet-connected devices. Five years ago, the enterprise
needed to deal only with computers and other directly connected devices that were
standardized and issued by the IT department. Today, every user has a smartphone,
tablet, and laptopoften their ownthat require an Internet connection. Each of these
devices consumes a great deal of bandwidth and has a negative impact on network
performance. While some enterprises ignore this traffic impact, the pressure to keep the
workforce happy and productive has forced many enterprises to adopt a
bring-your-own-device (BYOD) policy and utilize Wi-Fi and security policies to enable
network access to all of a workers devices. Enterprises must build a network that can
not only handle the bandwidth requirements of todays devices but also a network
architecture that is built so that it can expand to handle the exponential growth in user
bandwidth consumption over the next 5 to 10 years.
A second trend in the enterprise is the emergence of application hosting data centers
and the distribution of content. In the past, applications, data, and content were largely
localizedusers needed access to a local e-mail server and database and could, for the
most part, perform their duties without impacting the WAN. Today, many enterprise
applications and data are stored in data centers and accessed via constrained and often
oversubscribed WAN links. This centralization of enterprise applications and data has
strained the traditional model of WAN access, which was to provide low bandwidth, and
oversubscribed links to remote sites. The growth of bandwidth requirements, not only
for connected devices but for business-critical applications, has led the enterprise to
seek new ways to deal with the WAN and its design and performance.
A third trend in the enterprise is the rapid change experienced as business models evolve.
Enterprises often acquire new companies to expand their products and services and need
to integrate them quickly to enable faster time to revenue. This means that they need to
take over management of the acquisition network and resources. The traditional network
model that favored individual uplinks to remote sites becomes complex and
unmanageable as acquisitions become more commonplace and there is a need for a
more extensible mode. Combining the remote sites of two disparate companies is often
an exercise in compromise as network administrators struggle to merge competing
architectures into a single and scalable enterprise WAN. A solution that offers an
architecture built upon modular components can be more easily scaled during these
integration exercises.
A final trend affecting enterprises is the view that they should operate like service
providers, treating the organization as customers for their services and meeting higher
standards for service delivery. This drive by large enterprises to privately emulate service
provider networking provides a great challenge to traditional WAN designs and
architectures. Many companies choose to build completely private WAN clouds, and
many others look to build hybrid networks that give them control and management of
strategic portions of the network instead of relying on an outside provider. This movement
introduces a great deal of complexity, especially for the traditional model of remote site
uplinks, and demands a new approach to privatizing the WAN. The enterprises that fit
this mold are looking for ways to simplify the transition to a private WAN and need new
architectures to support this transition all while increasing network performance and
reliability.
About Juniper Networks Validated Solutions

Juniper Networks validated solutions are complete domain architectures that are expert
designed, lab tested, and documented to provide guidance in the deployment of complex
solutions. Juniper Networks solution validation labs put all solutions through extensive
testing using both simulation and live network elements to ensure comprehensive
validation of all published solutions. Customer use cases, common domain examples,
and field experience are combined to generate prescriptive configurations and
architectures to guide customer and partner implementations of Juniper Networks
solutions. This approach enables partners and customers to reduce time to certify and
verify new designs by providing tested, prescriptive configurations to use as a baseline.
Scope
The Juniper Networks enterprise WAN solution (Figure 1 on page 5) is designed to meet
the needs of an increasingly complex network segment that is a key enabler to current
and future business requirements. This document serves as a complete design and
implementation overview of the Juniper Networks enterprise WAN solution and includes
an overview of challenges, business drivers, design considerations and recommendations,
as well as step-by-step implementation guidance that provides configuration and
verification of each solution component.
The use cases and scenarios covered by the enterprise WAN solution include:
Chapter 1: Enterprise WAN Overview
Enterprise WAN Interconnection of multiple types of enterprise locations to include

branch, headquarters, and data center. (The complete enterprise WAN scenario will
be covered by a future version of the solution)
Internet edge The interconnection of the enterprise WAN to one or more service
providers enables user access to the Internet and external access to corporate
resources.
WAN aggregation This is the consolidation of multiple enterprise branch networks

onto a single enterprise WAN.
Data center interconnectivity The interconnectivity between enterprise data centers

that enables resiliency in the enterprise data center. (This scenario is covered by the
Juniper Networks data center interconnect solution.)
Figure 1: The Various Domains in the Enterprise WAN
Audience
The primary target market for the enterprise WAN aggregation and Internet gateway
solution are enterprises that have many geographically dispersed locations. These remote
sites, or branches, need to be connected to a main corporate site, and in some cases,
they require connectivity to other remote sites and to the Internet. Enterprises want a
flexible and reliable design for connecting various types of remote branches over either
traditional private WAN transports or over the public Internet with security overlays. Their
requirements include a breadth of features with low operation costs and low complexity.
They are looking for vendor-guided deployments that are tested, verified, and documented.
This guide is intended to assist you to design and implement WAN solutions in the
enterprise. We intend the guide to be used by the following:
Business decision makers Responsible for evaluating a solution against business

requirements to determine if the solution can reduce expense, improve efficiency or
agility, or otherwise transform the business in a meaningful way.
Technical decision makers Responsible for planning the implementation for full
integration and operation with existing enterprise services.
Network architects and engineers Responsible for implementing the solution and
the day-to-day operation of the solution.
Enterprise WAN Domain Overview

The WAN aggregation and Internet gateway solution is in the enterprise WAN domain.
It is the part of the network that connects remote sites to each other, to the Internet, and
to main corporate sites where data centers and other corporate resources reside.
The enterprise WAN consists of various network segments and configurations that enable
the enterprise to generate revenue in todays highly connected, dynamic environment.
The enterprise WAN itself consists of various business site types that must be
interconnected in order to enable business and revenues. The corporate LAN and data
center are at the core of the enterprise WAN. These sites provide a bulk of the enterprise
support, applications, and business enablers (Figure 2 on page 7). The enterprise WAN
is the sum of the configurations and design of the interconnections between the data
center and corporate headquarters and the rest of the enterprise. The enterprise remote
sites can consist of various campus environments as well as small offices, revenue
gateways (such as a storefront or branch sales office), and other remote locations. The
enterprise WAN is often designed to provide dedicated interconnection with partners,
home-based workers, and other support resources. This is the key to the solution as it
provides the backbone over which most enterprise traffic travels. Understanding the
enterprise WAN as a whole is key to understanding the subsequent solution
componentsWAN aggregation and Internet edge.
Figure 2: The Enterprise WAN Domain
Enterprise WAN Problem Statement

The network is critical to the operation and innovation within the enterprise as it enables
access to new applications and services by employees, suppliers, and customers. As
networks have become faster and more robust to support the current and next generation
of business applications, the complexity and expense associated with the network have
also grown. The growth in the WAN segment has introduced several key challenges to
the enterprise. Deployment ease, flexibility, and scalability are ongoing challenges in this
segment. How does the enterprise deploy a WAN easily while ensuring that the
components implemented are future proof and able to scale to meet future demands?
Another key challenge is in the enabling of cloud services in the enterprise. Companies
are increasingly looking to cloud services providers to augment their business, and a WAN
that can enable this agility is essential to success. Adding services and more devices to
meet this challenge increases the total cost of ownership of the WAN and can have an
effect on the bottom line. Once installed, a new challenge is presented in the management
of the WAN. The network should be easy to manage once implementedaddressing this
challenge is particularly problematic as the complexity of the network increases. Finally,
the WAN should be services-ready. A WAN implementation must support technologies
that enable future growth and the addition of value-added services to the network.
The first key challenge of the WAN is in the ease of deployment and in its flexibility and
scalability. This ease should extend to the manageability of the network once it has been
implemented. The enterprise WAN does not consist of a single branch location, but rather
it consists of sites of various size and purpose that are geographically dispersed. This
dispersion and difference of purpose can be effectively addressed by introducing a
common network that excels at carrying traffic of varying importance between sites as
well as between partners and third-party support organizations. Unfortunately,
deployment of a single WAN architecture is not enough. The technology used to enable
the single WAN network should also have common factors. Equipment that shares the
same operating system can be more easily migrated to more robust platforms as needs
dictate. In addition, having a single operating system throughout the network makes it
easier to introduce new services and configurations to the network, as the same
configuration is likely to migrate wherever it is needed.
Another key challenge is ensuring that cloud services are easily adopted by the enterprise.
The drive to reduce cost in the enterprise combined with the need to provide a high-quality
user experience often collide and cause business needs to come second to the need to
control expense. An answer to this conflict is often found in the adoption of cloud services
in the enterprise. An effective enterprise WAN enables not only intercompany
communication, but it enables a robust and high-quality connection to the data
centereither through direct interconnection to an enterprise data center or through a
direct connection to a cloud data center. Meeting this challenge is critical in controlling
cost while enhancing the user experience with the data center.
The final key challenge in the enterprise WAN is ensuring that the network is
services-ready. The network should be designed to be flexible, scalable, resilient, and
secure as these characteristics are all requirements of any service-ready network. An
effective architecture in this space is modular in nature, allowing the addition of new
services to the enterprise WAN such as VPN, Network Address Translation (NAT), and
stateful firewall services. In addition, the enterprise WAN should support implementation
of value-added services such as WAN acceleration and content caching services.
Juniper Networks Enterprise WAN Solution Overview

The Juniper Networks enterprise WAN solution is comprised of a collection of configuration
scenarios that can be combined in modular fashion depending on the networking and
business needs of an organization. The solution is built upon the following modular
building blocks:
WAN aggregation
Internet gateway
Secure overlay (IPsec VPN)
Services
The target markets for this solution include any organization that has a wide base of hub
sites with a high degree of interconnectivity demands within the enterprise. Large
enterprises that operate as pseudo-carriers are the key target of the use cases provided
in this solution. Large enterprises such as government agencies, universities, financial
and health care organizations, and large technology companies are most likely to benefit
from the deployment scenarios established by the Juniper Networks enterprise WAN
solution. Large enterprises are the mostly likely to establish private aggregation points
of presence, enabling them to consolidate WAN connections prior to backhaul to the HQ
or data center sites. This approach enables the enterprise a central point of control for
regional hub sites, enabling cost savings on backhaul (a single aggregation router is
connected via high speed backhaul to the carrier or private MPLS cloud as well as to the
Internet edge) and management. In the aggregation model, a single point of presence is
configured to provide all enterprise transport services to the regional hubs. This minimizes
configuration points and enables more robust resiliency and performance to those hub
sites. The next section will cover each of the modular components of the WAN aggregation
solution component.
WAN Aggregation
A large enterprise WAN can be built in several ways to accommodate control, security,
and performance concerns within the business. The three models of enterprise WAN
network are public, hybrid overlay, and private. A public enterprise WAN
(Figure 3 on page 9) utilizes a purely service-provider MPLS network to provide
pseudo-private enterprise WAN services. This can also be referred to as a managed
enterprise WAN. In this scenario, the service provider hands off a circuit to the enterprise
site and provides all MPLS services transparently to the enterprise. For most enterprises,
this enterprise WAN architecture provides excellent service with little to no management
required by the enterprise. Many service providers will manage the MPLS CE (customer
edge) routers at all branches, effectively making the WAN transparent to the enterprise
and its users. While this approach is appropriate in most cases, large enterprises often
choose to augment or replace the carrier-managed option with their own architecture
and design. A hybrid overlay network is often one of these choices.
Figure 3: A Public Enterprise WAN
The hybrid overlay network (Figure 4 on page 10)enables the enterprise to consolidate
and control WAN resources where it makes financial and geographical sense, for example
overlaying their private WAN securely over the Internet, to augment the carrier provided
private MPLS service they use. In a hybrid overlay network, regions with a high density of
enterprise offices are aggregated onto an aggregation point-of-presence that is controlled
by the enterprise; this aggregation router has a high-speed transport to the rest of the
enterprise.
Figure 4: Hybrid Overlay Enterprise WAN
Often, the hybrid approach is not sufficient. In cases where the enterprise wants to build
and manage the entire MPLS network, a private solution is favored (Figure 5 on page 10).
In these solutions, the carrier provides core services to regional aggregation hubs and
acts only as logical transport. All MPLS, class of service, and other configurations are
performed by the enterprise. This model gives the greatest amount of control to the
enterprise, but often at great expense.
Figure 5: A Private Enterprise WAN
In hybrid overlay and private enterprise WAN deployments, the key to the solution is the
WAN aggregation routers that are often at the carrier office: as such, the WAN aggregation
10
routers are a key focus of the overall enterprise WAN solution. WAN aggregation is a
network architecture that consolidates multiple networks such as the campus, branch,
and data center networks, onto the enterprise WAN network (Figure 6 on page 11). It is
within this enterprise WAN component that the various networks and site types are
stitched together to enable seamless communication between the enterprises various
locations. The aggregation model featured most often is that of a single backhaul to a
corporate HQ or data center where all site to data center, and site to site traffic is sent
to be routed within the enterprise. The aggregation of WAN connections can be handled
by private leased line, MPLS Layer 3 VPN, Layer 2 VPN, or by an Internet VPN. It is common
to find a mix of these connection methods in the WAN aggregation as the enterprise
often selects transport based on business need and criticality. Managed service providers
often use access similar to this (a mix of MPLS, Layer 2 VPN, and Internet-based access)
to enable customer access to the enterprise, both through the service provider-managed
MPLS network and over the public Internet using secure tunneling.
Figure 6: WAN Aggregation of Enterprise Remote Sites onto the Enterprise

WAN
PUBLIC/PRIVATE
WAN
WAN AGGREGATION
AS 1
AS 2
M Series/
MX Series
Static Routes/EBGP
MX Series
M Series/
MX Series
INTERNET
M10i
g041749
BRANCH
There are two methods for designing the aggregation hub and the roles or services it
provides (Internet access, IPsec termination, WAN aggregation and services); one is to
use separate routers for each role using the MX5-80 or M7i, the other is to make use of
the rich virtualization features in Junos OS and make each role a virtual-routing instance
in a chassis-based MX (MX240-960)
There are several modular configuration options for the remote branch. Using the WAN
aggregation model Table 1 on page 12, the solution features configurations for three
deployment scenarios: dual router with dual circuit, single router with single connection,
and single router with dual connection.
11
Table 1: Enterprise Remote Site Deployment Scenarios

Deployment Scenario
Platform
Platform
Transport
Dual Router Dual Circuit
Large
MX Series
Layer 3 VPN/Layer 2
VPN
Head-End Router (MX

Series)
WAN aggregation
M7i, MX5-MX80
VPN, WAN aggregation

Internet
Single Router / Single

Connection
Single Router Dual

Connection
Small
SRX Series, MX5-MX80
Internet
WAN aggregation
Medium
MX Series
Private WAN
M7i, SRX Series,

MX5-MX80
Internet
M7i, MX5-MX80
Internet
M7i, SRX Series
Private WAN
WAN aggregation
Layer 3 / Layer 2 VPN
WAN aggregation
The remote branch configurations provided in the solution DIG include uplinks directly
to the Internet, mixed connection profiles with both MPLS and Internet connections from
a service hub (aggregation node), and a complete MPLS connection model with the sites
connected into MPLS for all three deployment scenarios (Figure 7 on page 12)
Figure 7: The Deployment Scenarios Tested and Delivered by the

Enterprise WAN Solution
12
The Juniper Networks enterprise WAN solution provides configurations for each
deployment scenario as well as design recommendations and troubleshooting information
to assist in deploying a new WAN aggregation hub as well as configurations for the remote
sites connecting into the aggregation hub. The configurations are tested in Juniper
Networks solutions labs and are tested against scalability targets, resiliency and
convergence targets, and performance targets. Details on design considerations and
implementation of this scenario can be found in the later chapters of this guide.
Internet Gateway
The Internet gateway deployment scenario is a foundation of the WAN aggregation
deployment scenario. The Internet and mixed aggregation scenarios require working
Internet gateway functionality in order to properly provision WAN aggregation. The
Internet gateway is used to provide Internet access to hub site users, or more commonly,
to provide a public transit for IPsec VPN connection back to the HQ or data center
(Figure 8 on page 13). In many cases, the hub Internet traffic is provided via backhaul to
the company HQ to enable security services such as URL filtering, anti-spam and anti-virus,
and intrusion detection and prevention (IDP). By backhauling traffic to an HQ site, the
enterprise can manage and maintain security between its users and the Internet in a
central location. By sacrificing some speed and performance, the enterprise can ensure
the security of its user base in this design scenario.
Figure 8: Enterprise WAN Internet Gateway Topology
The Internet edge module of the larger WAN aggregation solution component provides
carrier-class routing and security to regional enterprise sites that have a requirement for
localized Internet access. The local access either provides direct Internet connection to
13
the enterprise remote sites, or provides a transit network to enable intra-enterprise IPsec
VPN connectivity. The aggregation hub providing Internet edge services is services-ready
and can be easily configured with services that enhance the security posture of the
enterprise remote sites. Services such as Dynamic NAT, access lists to white list or blacklist
specific destinations, stateful firewall and intrusion detection and prevention services,
and active-active load balancing to multiple Internet service providers (ISPs) are all key
components of the solution.
Secure Overlay (IPsec VPN)

Secure overlay is a component of the enterprise WAN solution that enables branches
with limited provider MPLS options to gain access to the enterprise. In these instances,
a branch office or home user obtains Internet access from whatever local provider is
available (via DSL, cable, or even satellite). The enterprise then provides a managed,
pre-configured device to provide IPsec services to the remote site.
Services
The Juniper Networks enterprise WAN is services-ready, enabling the agile addition of
new services. The Juniper Networks solution supports Web Cache Communication
Protocol (WCCP) to enable WAN acceleration devices to enhance the user experience
where required. Other services that can be supported as in-line, network-driven security
services are stateful firewalling and deep packet inspection. In cases where the enterprise
is hosting sensitive data or is likely to be the target of intrusion or attack, control plane
protection and denial of service protection (DOS and DDOS) are integrated into the
Juniper Networks enterprise WAN architecture. Finally, for enterprises that utilize real
time or recorded video content (such as financial streams to banking centers or video
lectures within the education sector), the Juniper Networks enterprise WAN solution
supports the inclusion of content caching. This service is adopted through enhancements
to the networks handling of multicast traffic and by the routing hardware ability to redirect
specific flows to secondary devices or virtual appliances that locally cache and serve
content to remote sites. The Juniper Networks enterprise WAN is able to add these
services in-line with little to no disruption of the user experience.
Enterprise WAN Solution Benefits

The Juniper Networks enterprise WAN solution offers the following benefits to the large
enterprise seeking to utilize private MPLS or hybrid overlay network design in combination
with WAN aggregation:
14
Improved operational efficiency
Reduced operational expense
Flexibility and value for investment
Security
Carrier-class reliability
Improved Operational Efficiency

The large enterprise can simplify the network by adding regional WAN aggregation routers
to a private MPLS or hybrid overlay network. Using the Juniper Networks MX Series 3D
Universal Edge Routers, the WAN aggregation architectures in the enterprise WAN solution
support various link speeds including 10 Mbps all the way through 100 Gbps interfaces.
For non-Ethernet interfaces, DS3 through OC192 are supported by the MX Series. The
aggregation of multiple low-speed connections to hub sites into a regional aggregation
tier that supports high speed backhaul, the enterprise enables a single point of regional
management and improves the potential performance of all connected hub sites by
providing high speed services from the region to the HQ. The design also uses a single
operating system (Junos OS) on all routers, from the aggregation hubs to the small CPE
devices used at remote sites (or by home users). This enables operational simplicity by
standardizing the operating system within a region, saving network operational time in
provisioning and troubleshooting across the entire enterprise WAN.
Reduced Operational Expense

Regional aggregation of enterprise remote sites enables the enterprise to provide lower
speed local uplinks to the sites in region. The aggregation hub then provides a higher
speed backhaul transit to the HQ. The enterprise can control the configuration from the
hub to aggregation and across the backhaul to HQ. This level of control enables a better
user experience as the class of service and security services are configured and maintained
by the enterprise. The WAN aggregation model enables the enterprise to provide
high-speed services to regional sites at potentially lower cost, utilizing the low speed
links to aggregate sites to a higher speed transport.
Improved Flexibility and Value for Investment

The MX Series router supports a wide array of upgradeability options. Software licenses
and additional Modular Interface Cards (MICs) can be added to increase the functionality
or capacity of an aggregation hub. Within a range of MX Series (low-end or high-end),
software licenses can be activated to enable higher speeds on the same platform,
supporting expansion in region or the addition of new services to the enterprise sites. The
MX Series also supports a wide array of interface types, enabling an enterprise remote
to upgrade from legacy circuits to high speed Ethernet easily, as the uplink is performed
only between the remote and the aggregation hub. Finally, the network is built for elasticity
and performance. Combining a robust class of service implementation with backhaul
features such as MPLS Traffic Engineering (TE), and virtual private LAN service (VPLS),
the enterprise can more effectively guarantee application performance to the sites,
ultimately improving the user experience and, by extension, the bottom line.
Security
The enterprise WAN solution and WAN aggregation deployment scenarios are built from
the ground up with security as a key component. Logical separation of remote traffic or
even the separation of different operating units within the remote sites is provided by
the solution. This logical separation enables the enterprise to control not only whom on
the outside each operating group can communicate with, but also controls communication
and leaks between operating groups within the same enterprise.
15
Carrier-Class Reliability
The ability to keep the enterprise running is another key benefit of the Juniper Networks
enterprise WAN solution. The Juniper Networks MX Series routing platform is a
carrier-grade component, designed with full resiliency at its core. The hardware is designed
for resiliency, utilizing redundant control plane and switching plane hardware as well as
redundant power and cooling. In a design model where the enterprise is acting as a private
service provider to its remote sites, the ability to keep the WAN aggregation routers
available and performing is critical to the success of the solution. At the routing and
software layer, MPLS resiliency mechanisms such as MPLS fast reroute and on-demand
paths are supported to enable fast recovery from core issues that affect backhaul routing
to the HQ. In a multiple chassis deployment, where hardware redundancy is supported
by uplinks to multiple regional aggregation points of presence, the MX Series supports
multi-chassis Link Aggregation Group (LAG) and Virtual Chassis (VC), enabling a single
site to redundantly connect to multiple aggregation points while allowing the redundant
chassis to function and appear to the connected nodes as a single, physical device.
16
CHAPTER 2
Enterprise WAN Design

Enterprise WAN Design Goals
The design of the enterprise WAN solution was guided by several goals that align to the
needs of the enterprise business. Each of the solution elements covered should have
high-level design goals that inform the choices made during the design of a new or
upgraded enterprise WAN. The prime design considerations for the enterprise WAN are:
Easy to deployA top goal in any effective network architecture should be ease of
deployment. A fantastic solution that features complicated deployment scenarios is
likely to encounter more issues than a network that features easy and documented
deployment.
Flexible and scalableNew network architecture should be designed to grow with the
business and change as business needs dictate. Installing a design that just meets the
needs of the business today is a recipe for increasing expenses and complexity as the
network is upgraded piecemeal.
Resilient and secureArchitecture that is vital to business success, as in the case of

the enterprise WAN, should be designed with the expectation that failure and security
breaches are not only possible, but probable. Rather than designing around unplanned
outages and attacks, design in a way that expects outage and attacks on the network
and its protected resources.
Easy to manageAn effective network design features management that is simple

and centralized. The ideal scenario has a single operator with a single pane of glass
that is able to manage the entire network. Designing ease in the management of the
network is just as important as any other factor in the network design.
Services readyFinally, a network should be able to easily adopt new technologies

and services that allow the network to provide enhanced functionality to the business.
The ability to introduce value-added services in-line with existing network flows is a
key design consideration in an enterprise WAN solution: This enables the network
administrators to add services like WAN acceleration, content caching, elevated security
(anti-virus, intrusion detection and prevention), to name a few, to the network (often
without the addition of new hardware).
17
Ease of Deployment/Designed for Flexibility and Scalability

Organizations with thousands of remote sites often are spread out among different
geographical locations. The locations might have labels like branch office, regional site,
or headquarters. WAN aggregation design should inform the building of a network for all
these locations, regardless of their label or purpose. This means that the architect and
network designers should build a network that scales. Standardization is one way to
design for scalability: by introducing and adopting a small number of standard designs
for common portions of the network, the options for network deployment are limited
and simplified, resulting in a more common network design. To enhance scalability further,
a modular design approach should be used. Designers should begin with a set of standard,
global building blocks for the network. From there, a scalable network can be designed
to meet business requirements. For instance, in an enterprise network, we might start
with a head end module; connect an Internet edge module, and a WAN aggregation
module to build the complete enterprise WAN network with the addition of pre-defined
remote site types added based on the enterprise site characteristics.
Many of these modules are the same for service design; this provides consistency and
ease of scalability in that the same support methods can be used in multiple areas of
the network to maintain the network. These modules follow standard layered network
design models and utilize separation to ensure that interfaces between the modules are
well defined.
Resilient and Secure

One of the keys to maintaining a highly available network is building in the appropriate
redundancy to guard against failure in the network, whether it is link/circuit, port, card,
or chassis failure. This redundancy is carefully balanced, however, with the complexity
inherent in redundant systems. Over engineered systems can cause more problems than
they prevent, introducing failures caused by overly complex redundancy features.
Over-engineering a networks resiliency can often result in complete communications
failure. All organizations require redundancy in their networks. When building in the
necessary redundancy, care and thought must be given to not making the redundancy
too complex and reliant on too many other modules. The failure of a single component
of each service can create a network failure.
With the addition of a significant amount of delay-sensitive and drop-sensitive traffic
such as voice and video conferencing, we also place a strong emphasis on resiliency in
the form of convergence and recovery timing. Choosing a design that features failure
detection while reducing recovery time is important to ensuring the network stays available
in the face of even a minor component failure.
The security of the network is another important factor in designing network architecture.
As networks become larger and more complex, entry points into the network and areas
where security vulnerabilities exist are more probable. Effective WAN aggregation and
enterprise WAN designs ensure a secure network that does not restrict usability to the
point where using the network becomes a burden to the end user, hindering the customer
experience in the process. Security should be designed to address vulnerability and risk
while enhancing the user experience on the network as much as possible.
18
Chapter 2: Enterprise WAN Design
Ease of Management
An effective WAN aggregation and enterprise WAN architecture should be designed to
be easily managed and operated. Ideally, a single pane of glass in the form of a network
management application, or a collection of applications, should be used to implement,
maintain, and troubleshoot the network as much as possible. The old methods of using
CLI and truck rolls to manage the network is more of a burden as the complexity of the
network grows and as the network becomes more vital to the user experience. An
architecture that focuses on making the network easy to manage includes all FCAPS
elements. FCAPS is an ISO model and framework for network management. FCAPS
includes the following network management elements:
Fault management
Configuration management
Accounting management
Performance management
Security management
An architecture that internalizes these management elements in the design process is

likely to be easy to manage. Faults are managed by a central system that polls network
elements via SNMP to verify status while network events are sent to the network
management system via SNMP traps. Configurations can be managed via third party
tools that manage and execute scripts, or through GUI-based systems that enable the
operator to make bulk changes throughout the managed network. Accounting
management is essential in environments where multi-tenancy, or pay to play are in
use. In an architecture that aggregates multiple business units with discrete billing and
service requirements, the ability to tie usage to those accounts is a necessity. Performance
management enables the organization to verify the attainment of service level
agreements, either between the enterprise and the service provider, or between the
enterprise IT organization and the underlying business units (internal SLAs). Finally,
security management is essential to the management of an enterprise WAN network.
The ability to coordinate security throughout the enterprise and at the service points
where security policy is applied is crucial to securing the network. Beyond the configuration
of security, the management system should support the reporting of security events so
policies can be evaluated and changed to meet evolving security threats.
An effective management system provides a complete FCAPS functionality to the solution
and enhances the management, security, and accountability of the underlying network
design.
Services Ready
Flexibility, scalability, resiliency, and security all are characteristics of a services-ready
network. An architecture featuring a modular design enables technologies and services
to be added when the organization is ready to deploy. In services-ready architecture, new
platforms and extensive network changes are not required to enable service adoption
the network is modular and built to accept these new services with very little change
required. A network architecture that is designed and pre-configured with class of service
19
(CoS), for instance, is ready to support high-quality voice and video. A network that is
designed and configured with multicast is ready to support efficient voice and video
delivery. A network with customer edge (CE) platforms that support WCCP is ready to
add caching and acceleration services without requiring extensive changes to the network
design. Other services that should be considered are VPN services, Network Address
Translation (NAT), and stateful firewall services. A network that is designed and built to
support these services from day one can be considered services-ready.
A complete enterprise WAN solution that meets these design goals is built to be scalable,
flexible, and services-ready. The following sections will provide in depth overview on the
architectures, design choices, and recommendations for building a private enterprise
WAN.
Enterprise WAN Architecture

The complete enterprise WAN solution, with emote sites of various size and connectivity
connecting into regional aggregation hubs and then back into the enterprise network via
the private MPLS network, is seen in Figure 9 on page 20. The entire solution enables an
end-to-end, private MPLS for large enterprise that enhances control of the network,
enables consolidation of backhaul bandwidth and custom quality of service, and flexibility
in the addition of new sites (or upgrading sites to a new branch type).
Figure 9: Enterprise WAN Reference Architecture
The solution is built upon several tiers of configuration and design. The WAN aggregation
tier is the point at which the enterprise remote sites are introduced to the private WAN.
The WAN aggregation tier serves to consolidate all remote site connections into a single
enterprise WAN for backhaul to the corporate HQ and data centers. This tier is configured
with high-speed backhaul over the carriers existing MPLS infrastructure using the existing
MPLS Layer 3 VPN connectivity in place. Some enterprises choose to obtain a Layer 2
20
service that enables the creation of a completely custom Layer 3 VPN overlay. This design
features a Layer 3 VPN routed core configuration.
The second tier of the design involves the various attachment circuits into the WAN
aggregation tier from enterprise remote sites. Given that many large enterprises have
presence throughout the world, it is reasonable to assume that the possibility of utilizing
a single service provider for service to each branch is nearly impossible. To that end, the
enterprise WAN solution features multiple options for connecting remote sites to the
network.
Direct connection via leased lineSome sites that are located close to a WAN
aggregation hub or sites that require dedicated, high-speed access are connected to
the WAN aggregation via leased private line.
MPLS / Layer 3 VPN connectionSites that have access to a service providers existing
Layer 3 VPN footprint can connect into the WAN aggregation via the carriers existing
MPLS service.
IPsec over InternetRemote sites with no access to carrier MPLS or leased line connect
via the public Internet using whatever service is available in the area. In some cases,
even sites that have access to the other connectivity options connect using IPsec as
it is a more cost effective option.
The third tier of the enterprise WAN design is the Internet edge gateway. The Internet
edge is parallel to the WAN aggregation tier in the design and serves several purposes.
The first purpose of the Internet edge is to provide secure Internet access to the enterprise
and its remote sites. The Internet edge also provides access from the Internet to
enterprise-hosted resources such as web sites and other customer portals. Finally, the
Internet edge serves to provide a public-facing peering point for IPsec connected branches.
Given the size of many large enterprises, several distributed WAN aggregation hubs can
be deployed to serve high areas of site concentration. It is possible that only specific
areas will have a local Internet edge configuration. In many cases, the Internet edge will
be located close to the enterprise HQ and data center to minimize the amount of transit
traffic generated by remote sites and inbound resource requests.
This guide will cover each of these areas in detail, with design guidance and considerations
given in the following operational areas:
Transport (Includes interface configuration, routing, traffic flow, and multicast)
High availability
Class of service
Security
WAN Aggregation Deployment Scenario

The Juniper Networks enterprise WAN solution employs two core use cases in the design
of a large private enterprise WAN. The primary use case is the creation of a private WAN
over a public MPLS infrastructure. The solution outlines attachment of multiple branch
types to the enterprise WAN, covering attachment to the MPLS via Layer 3 VPN as well
21
as over the Internet using secure overlay (IPsec VPN). To enable scale and more effective
control, the solution focuses on creating regional aggregation hubs to which all regional
sites first connect. From that site, private WAN services are provided to allow connection
to internal enterprise resources such as HQ resources and data centers. The solution is
designed to be simple and scalable. We will cover each of the layers of the design in
detail. The various layers of the WAN aggregation design is covered in the following
sections.
WAN Aggregation Architecture

The primary role of WAN aggregation is to aggregate connections from multiple branches
or regional sites to a central site, enabling access to services in the central site or data
center (Figure 10 on page 22). The aggregation hub can be located at a regional office
or at a service provider central office to enable localized termination of core transport.
In this design, some site types utilize both the private enterprise WAN and a backup circuit
(GRE over IPsec over Internet). In this use case, the Internet transport design is covered
in detail here: Internet Gateway Design on page 66
Figure 10: WAN Aggregation Architecture Incorporates all Remote Site

Transports into a Single Aggregation Tier
The solution consists of several points of presence and covers configurations for hub
sites, Internet edge connectivity, and remote site connectivity into the aggregation hubs.
This document uses the terms WAN aggregation site, hub, head end, and WAN aggregation
hub to describe the overall WAN aggregation site.
Aggregation Hub Roles

Each aggregation hub contains three functional roles that must be configured in order
to enable the complete enterprise WAN solution. Those roles are: WAN aggregation,
Internet gateway, and VPN termination
22
WAN Aggregation
WAN aggregation consolidates transports from multiple regional enterprise branches
onto a regional hub, consolidating the various enterprise branch transports into a private
MPLS network with backhaul into the company HQ and data centers.
The WAN aggregation point of presence, or POP, provides three distinct roles as it pertains
to WAN aggregation:
WAN aggregation An internal router role not directly connected to the Internet, this
is where private leased line and private SP managed Layer 3 and Layer 2 VPN services
terminate. This is also where services such as WCCP are hosted
Internet Edge This router is external and peers with the public Internet. In the case
of the WAN aggregation use case, this router provides reachability for the IPsec tunnel
termination.
IPsec VPN Router This router terminates the IPsec and GRE tunnels from the Internet
connected remote locations. The tunnel end points are in an Internet facing
virtual-routing (VR) instance (VPN VR) however the GRE tunnel addressing is internal
and part of the enterprises private routing domain (WAN-GRE VR). To this end the
Internet VR peers with and routes to and from the Internet edge router and the
WAN-GRE VR peers with the WAN aggregation router.
These roles are tightly integrated in the solution, however customers can choose, or
require, only one or two pieces of the functionality and this design is modular enough to
allow this. For example one customers business requirements only dictates the need to
provision WAN aggregation for Layer 3 VPN and leased line remote sites. In this case, the
business would not need the IPsec VPN router or Internet edge router roles at the WAN
aggregation site. Likewise, another customers business requirements require only Internet
connected remote site aggregation. In this case, the customer only needs the IPsec VPN
router at the aggregation hub.
Depending on the needs of the enterprise, the WAN aggregation role provides site-to-site
transport as well (in cases where VoIP or other real-time services require lower latency
than backhauled transport can provide). This design features a hub-and-spoke topology,
though the solution is flexible and can be configured for any-to-any connectivity using
the WAN aggregation hubs as localized spokes.
The WAN aggregation role is primarily to handle routing for the remote sites connecting
to the aggregation hub. It aggregates network connectivity from regional branches and
backhauls via the MPLS backbone to the HQ and data center sites. These connections
can come via leased private line, Layer3 VPNs, or via IPsec connectivity (also called
secure overlay). This router contains routing protocol configuration (BGP or OSPF) for
private routing over the designated transport. If the preferred IGP is IBGP, the WAN
aggregation router peers with the branch and acts as a BGP route reflector for the branch
sites. If OSPF is the preferred IGP of the enterprise, the WAN aggregation router forms
OSPF adjacency with the branch with a separate OSPF area configured for each branch
connected. For Layer 3 VPN connections, the WAN aggregation router also forms an
EBGP adjacency with the service provider. In this scenario, the enterprise is using the
service provider MPLS network as foundation upon which to build a private MPLS network.
23
The WAN aggregation router is part of the full IBGP mesh at the aggregation hubs, and
it is in the aggregation hubs OSPF backbone. In addition, it is the location of the multicast
static rendezvous point at hub 1 (the primary WAN aggregation router), and it is an MSDP
peer to the static rendezvous point at hub 2 (the backup WAN aggregation router). WAN
aggregation router holds all routing information for the aggregation hubs, and it acts as
the multicast rendezvous point at the hub. One of the reasons the design utilizes secure
overlay with GRE over IPsec is to enable dual stack (IPv4 and IPv6 traffic) as well as
tunneling of multicast traffic and providing full filtering and per tunnel hierarchal CoS to
secure overlay-connected sites. While dual stack and multicast transmission is fully
supported for Layer 3 VPN and private leased line transports, the secure overlay design
required a bit more complexity in order to fully support all services attached to this
solution. Using GRE as a transport provides the added benefit for a hybrid overlay in that
it can easily be extended to transport MPLS VPN to Internet branches.
Internet Gateway Role

The Internet gateway router (also referred to as the Internet edge, or iEdge) acts as a
gateway to the Internet for the enterprise. It is ISP facing, and routes Internet traffic to
and from the aggregation hub. It also provides the necessary security to protect the
enterprise infrastructure from attacks from the Internet. The Juniper Networks enterprise
WAN solution employs hub-and-spoke topology for all Internet traffic. This means that
all Internet traffic to and from the enterprise goes through the Internet gateway. The
Internet gateway handles Internet traffic for branches, and it connects customers to
hosted services on the enterprise network.
NAT between the enterprise and the Internet is handled by the services VR (on the three
router aggregator this is on the Internet gateway router). This VR performs source NAT
translation of private, enterprise IP addressing to a public IP address pool.
VPN Termination Role

The solution enables connection of Internet-connected remote sites into the enterprise
WAN utilizing a secure overlay (GRE over IPsec). The VPN termination router is the entry
point for Internet-connected branch sites. It acts as a VPN aggregation point and routes
traffic between GRE over IPsec VPN connected sites into the enterprise MPLS core. This
design utilizes a VPN termination router with three virtual router routing instances:
VPN
The VPN virtual router directly faces the Internet gateway, and terminates IPsec tunnels
that are initiated at Internet-connected branches. It acts as the IPsec tunnel endpoint
for IPsec requests from the branches. The VPN design in the solution utilizes dynamic
IPsec endpoints: this configuration requires only two IPsec tunnel interfaces.
This virtual router hosts these IPsec tunnel interfaces. Additionally the GRE tunnel
endpoints are configured in this virtual router, this allows for the use of reverse route
injection to advertise these tunnel endpoints even though the addresses used are
private (RFC 1918) addresses and are transported OVER the GRE tunnel.
24
NOTE: The reason for using private tunnel addresses for GRE that are
different than the IPsec tunnel public IP addresses are::
In Junos OS, if the same address is used for the IPsec and the GRE tunnel
a routing recursion issue will occur and the IPsec tunnel will be torn down.
This is a similar situation to the age old issue of advertising a GRE tunnels
endpoint over the GRE tunnel itself, except in this case; once the GRE
tunnel is established, if using the same loopback address as IPsec, the
IPsec traffic will be transported over the GRE tunnel and the IPsec tunnel
will be bought down.
Using this separate private addressing for GRE brings additional benefits:
Its secure IPsec cannot be circumvented and MUST be used to

advertise the loopback addressing. Additionally this addressing is NOT
publicly routable or known externally.
It allows for a very elegant reverse route insertion policy on the

aggregator to install static routes to the remote sites GRE loopback
out of the appropriate service unit. It is elegant because now the remote
GRE tunnel loopbacks are all known and can be allocated in a
contiguous manner allowing for a single supernet to be configured on
the aggregator that will match ANY remote GRE site in the remote
proxy statement. Any request from a remote missing this statement
or not within the rage will be rejected.
Finally using RRI allows for much greater scale as no routing protocol is
required to run over the IPsec tunnels directly to advertise GRE tunnel
loopback addressing.
WAN-GRE
The WAN-GRE virtual router terminates GRE tunnels from Internet-connected branches.
Importantly, as detailed previously, this WAN-GRE instance is internal and although
the GRE tunnels are configured in this instance their tunnel end-points exist in the VPN
(external) VR. It contains the private routing protocol configuration, either IBGP or
OSPF, which run over the GRE tunnels to the branches. GRE interfaces, the loopback
interface that provides addressing for GRE tunnels, and the interface to the WAN
aggregation router are in the routing instance. WAN-GRE is in the aggregation hub
OSPF backbone. For Internet-connected branches that use OSPF as the private routing
protocol over GRE tunnels, you configure an OSPF area for each branch in the GRE
routing instance. This allows route filtering and configuration of each Internet remote
site as an OSPF stub network. WAN-GRE is in the full IBGP mesh at the aggregation
hubs. For Internet-connected branches that use BGP as the private routing protocol
over GRE tunnels, you configure an IBGP peer for each branch. These peers are used
to peer with the remote end of the tunnel at the branch.
For traffic to hosted services from the data center and branches, or all internal networks,
WAN-GRE applies NAT and assigns an internal enterprise address. It then forwards
traffic to the HOSTED-WWW-NAT routing instance. This allows internal clients to
access the hosted services resources using the services internal addressing.
25
WAN Aggregation Design Considerations

There are various design considerations that went into the creation of the enterprise
WAN solution. This section outlines these design considerations and provides a deep
dive level of information on the various choices encountered when designing a large,
private enterprise WAN. The design is broken up into the following categories:
Transport
Class of service
High availability
Security
Performance and troubleshooting
Scale
Traffic flow
WAN Aggregation Topology

Figure 11 on page 27 illustrates the topology featured in the WAN aggregation hubs. The
solution features two approaches to design and configuration of an aggregation point
of presence. The first option, aggregation Hub 1, utilizes a physical router for each
functional role at the aggregation hub. In the physical design, a separate router is
configured to operate a specific operational role (WAN aggregation, VPN termination,
and Internet gateway). While this approach is common and is often preferred due to the
physical segmentation of control and function, it does not leverage the strengths and
flexibility of virtualization inherent in the Junos OS. To that end, aggregation Hub 2 utilizes
a single physical router configured with virtual routing instances to accommodate the
functional roles of the aggregation hub. This design enables the same segmentation of
function found in the physical design but saves on cost and footprint (power, space,
cooling) by employing a single physical platform. This option also enables growth and
flexibility as a larger single platform can be chosen to host the virtual WAN aggregation
hub, enabling future growth and expansion.
The aggregation hubs are configured with topology and platform redundancy, where
each hub is connected to a separate ISP and Layer 3 VPN service provider. Full redundancy
is achieved in this design. When the service provider link to Aggregation Hub 1 goes down,
traffic fails over to Aggregation Hub 2. This design also enables redundant connection
of remote sites into disparate hardware at the aggregation hub. Large sites, or sites that
require redundant connections into the enterprise WAN, have two sites to which their
connections terminate. This enhances resiliency of the dual-homed remote sites.
26
Figure 11: The Topology of the WAN Aggregation Hub Routers
Aggregation Hub Transport

The WAN aggregation hub consolidates transports provided by the selected service
providers. The architecture supports leased line connections, including OC3 and T3
connections as well as Metro-Ethernet connections from the service provider. The
aggregation hub can also connect to and terminate branches with Layer 3 VPN service
from the service provider. Finally, Internet connected branches can connect into the
aggregation hub using IPsec VPN with GRE tunneling. Ethernet is becoming a dominant
carrier handoff in many markets, and with the exception of OC3 and T3, the above WAN
transports use Ethernet as a standard media type. Legacy connectivity is also prevalent
in the enterprise WAN and focus is also applied to non-Ethernet media (OC3 and T3).
All of referenced WAN transports will be using Ethernet as a standard media type.
Leased-lines are permanent point-to-point links connecting two fixed points across a
provider network. In general, the links are based on Layer 1 (SONET/SDH, T1/E1, and
T3/E3) technology. Today, because of the availability of cheaper alternatives, only
branches that have special business requirements, or branches that are geographically
near a central site, or limited by availability of local connection options, favor dedicated
lines.
MPLS Layer 3 VPN connectivity provides dedicated and reliable transport with a
guaranteed level of service, often with a strict service level agreement (SLA) that provides
penalties for degradation or loss of service. Layer 3 VPN is a favored option given its wide
adoption and packet-switched design. Managed MPLS service to remote sites can provide
a lower cost alternative to many other connectivity options.
Finally, sites without suitable access to the service providers leased line or Layer 3 VPN
service can securely connect to the enterprise over the Internet using GRE over IPsec.
The reasons for selecting a stack of tunneling protocols is addressed in the Remote
27
Branch Design Considerations on page 45 section. Remote sites with Internet access
via cable, DSL, or even satellite, can utilize that public access to gain secure access into
the enterprise WAN through secure overlay connectivity into the VPN termination router.
The individual transports are terminated into one of the router roles on the aggregation
hub. The WAN aggregation role handles termination of private leased line and Layer 3
VPN service while the VPN termination router handles secure overlay connectivity.
Some design considerations that went into the selection of transport configurations
include IP routing, IP protocol and tunneling, and data privacy.
The solution should support the following from an IP routing standpoint:
Provide optimal routing connectivity from the primary WAN aggregation site to all
remote locations
The solution should isolate WAN routing topology changes from the core
When multiple paths exist, the solution should support symmetric routing and load
balancing over the multiple paths
The solution should support site-to-site routing via the primary WAN aggregation site
If the carrier services allow, the solution should permit optimal site-to-site routing
(localized any-to-any rather than backhaul through a central WAN aggregation site).
The solution should support IP Multicast sourced from the primary WAN aggregation
site
Each of these functional requirements were incorporated into the WAN aggregation
design. The elements are covered throughout the next section with select details as to
why specific choices were made over the alternatives.
Aggregation Hub Traffic Flow

The traffic flow for each transport to the aggregation hub is slightly different. Traffic from
leased line and Layer 3 VPN transports are terminated on the WAN aggregation router
(or routing instance, if traffic is entering the Aggregation Hub 2). Traffic from secure
overlay sites (GRE over IPsec) enter the enterprise aggregation hub via the Internet
gateway and terminate in the VPN-VR/WAN-GRE-VR instances of the VPN termination
router. The following sections detail the flow of traffic from the various remote site
transport types and the enterprise aggregation hub. Traffic flow is identical when the
primary aggregation hub fails, entering Aggregation Hub 2 and flowing to the end resources
in a similar manner. Traffic flow during failure scenarios is covered here: Solution Failover
Scenarios on page 77
28
Leased-Line Traffic Flow

The simplest traffic flow featured in the solution belongs to the leased line remote site
transport service. In this transport scenario, the traffic between enterprise remote and
HQ flow to the various services as seen in Figure 12 on page 29.
Figure 12: Traffic Flow from Enterprise Remote / Enterprise HQ to the

Various Network Elements
1.
Traffic flows to its destination from either the remote site (over private leased line)
or from the enterprise HQ (or other remote sites).
2. Traffic destined for the enterprise HQ or remote site is processed by the WAN
aggregation router, routed as per the routing table on the WAN aggregation router,
and sent to the next-hop (the remote site or enterprise HQ)
3. Traffic destined for hosted services in enterprise data center:
a. Traffic from enterprise remote site is forwarded based on destination route to VPN
termination router
b. On the VPN termination router, the virtual router (VR) named "Hosted-WWW-NAT"
performs destination NAT translation on traffic (translates the destination IP of
the hosted service), forwards to enterprise data center hosted services
c. Enterprise data center routes/switches traffic as designed
4. Traffic destined for the Internet is forwarded to the VPN termination router.
SFW-NAT-SERVICES VR performs source NAT and firewall services for outbound

Internet traffic (NAT source address to public IP pool). Translated traffic forwarded
to ISP as per routing table or default route.
The flow of return traffic from the hosted services/Internet/enterprise sites is shown in
Figure 13 on page 30:
29
Figure 13: Return Traffic Flow for Private Leased-Line Remote Sites
1.
Return traffic from Internet to remote site enters Internet gateway,

SFW-NAT-SERVICES VR performs inbound firewall services and NAT. For stateless
traffic (SIP voice calls, for instance), stateful firewall checks application-layer gateway
(ALG) for rule permitting pinhole for return stateless traffic.
2. Return traffic from hosted services: Application traffic from hosted services exits
enterprise data center and returns to VPN termination router (via

HOSTED-WWW-NAT VR). Inbound firewall and NAT services applied.
3. Traffic forwarded from VPN termination router to WAN aggregation router for routing
to enterprise remote or HQ.

4. WAN aggregation router checks routing table and forwards traffic via routing-table
next-hop leased line sub-interface to remote site. Return traffic to enterprise HQ

routed to appropriate transport.
30
Layer 3 VPN Traffic Flow

The flow of traffic from Layer 3 VPN transport remote sites to the enterprise is similar to
the leased line transport. The major difference is in the routing. While the leased line
transport features direct route peering with the WAN aggregation router (at Aggregation
Hub 1), the Layer 3 VPN service is a managed service provider offering. In this scenario,
the remote site forms a peering (BGP) with the service provider route reflector. The
remote site and aggregation router are configured to enable the AS Override BGP
attribute, enabling a proxy peering with the enterprise internal autonomous system (AS).
In this way, the enterprise is using the service provider Layer 3 VPN and its routing
configuration as a waypoint for peering with the enterprise aggregation router (and the
enterprise AS). The flow of traffic from the Layer 3 VPN remote site to the enterprise is
shown in Figure 14 on page 31.
Figure 14: Traffic Flow From Layer 3 VPN-Connected Remote Site to

Enterprise
1.
Traffic flows to its destination from either the remote site (via Layer 3 VPN) or from
the enterprise HQ. Traffic between Layer 3 VPN sites goes directly site-site, not via
the aggregation site.
2. Traffic destined for the enterprise HQ or remote site is processed by the WAN
aggregation router, routed as per the routing table on the WAN aggregation router,
and sent to the next-hop (the remote site or enterprise HQ)
a. Traffic from enterprise remote site is forwarded based on destination route to VPN
termination router
the hosted service), forwards to enterprise data center hosted services
c. Enterprise data center routes/switches traffic as designed
4. Traffic destined for the Internet enters the WAN aggregation router and is routed to
the SFW-NAT-SERVICES VR. This VR performs source NAT for outbound Internet
31
traffic (NAT source address to public IP pool). Translated traffic forwarded to ISP as
per routing table or default route.
The flow of return traffic from the hosted services/Internet/enterprise sites is shown in
Figure 15 on page 32.
Figure 15: Return Traffic to Layer 3 VPN-Connected Remote Sites
1.
Return traffic from Internet enters the Internet gateway, SFW-NAT-SERVICES VR

checks NAT table and maps traffic to existing translation. For stateless traffic (SIP
Voice calls, for instance), stateful firewall checks application-layer gateway (ALG)
for rule permitting pinhole for return stateless traffic.
2. Application traffic from hosted services exits enterprise data center and returns to
VPN termination router (via HOSTED-WWW-NAT VR). Inbound firewall and NAT
services applied.
3. Traffic forwarded from VPN termination router to WAN aggregation router for routing
to enterprise remote or HQ.

4. WAN aggregation router checks routing table and forwards traffic via routing-table
next-hop Layer 3 VPN sub-interface to remote site. Return traffic to enterprise HQ

routed to appropriate transport.
32
Secure Overlay Traffic Flow

The flow of traffic from secure overlay-connected sites to the enterprise is somewhat
different from the other transports. The traffic for this transport type is encapsulated
within GRE which is then encapsulated within IPsec. The reason GRE over IPsec is used
is to enable multicast tunneling, v4 and v6 dual stack services, and per-unit class of
service on traffic to and from Internet connected sites. Currently, the MX Series does not
support all of these features for IPsec-only traffic. The traffic flow for secure overlay sites
to the enterprise is shown in Figure 16 on page 33.
Figure 16: Traffic Flow from Secure Overlay Remote Sites to the Enterprise
1.
Traffic flows from the remote site firewall to the VPN termination point via the public
Internet.
Outbound traffic is first encapsulated within GRE by the remote site firewall (SRX
Series) and then encapsulated and encrypted within an IPsec tunnel. These tunnels
terminate at different points in the aggregation hub.
The twice-encapsulated traffic enters the WAN aggregation hub at the Internet
gateway. Traffic is sent to the VPN VR (on the VPN termination router) for IPsec
termination and decryption. The GRE tunnel terminates in the VPN routing instance
as well, but the GRE tunneled traffic is terminated in the WAN-GRE VR. This is known
as VRF aware GRE, where the tunnel endpoints are in one VR and the internal
addressing of the tunnel is in the internal or private WAN-GRE VR. (This is all done
as a function of reverse route injection and VRF-aware GRE covered in the secure
overlay transport overview here:Remote Branch Design Considerations on page 45).
The enterprise traffic exits the WAN-GRE VR and forwards to its destination
(enterprise HQ, other remote site, or data center.
2. Traffic destined for the secure overlay remote site (from the enterprise HQ) is sent
via transport to the WAN aggregation router and routed (as per the routing table) to
33
the VPN termination router. The traffic is sent to the WAN-GRE VR for GRE
encapsulation. The GRE tunnel then enters the VPN VR for IPsec encapsulation and
is forwarded to the IPsec endpoint (the remote site). The remote site firewall
decapsulates and decrypts the traffic for host communication.
a. Traffic from secure overlay remote site is forwarded, as per the VPN termination
routing table, to the WAN-GRE routing instance it then forwarded to the
HOSTED-WWW-NAT VR via the service set.
the hosted service), forwards to enterprise data center hosted services.
c. Enterprise data center routes and switches traffic as designed
4. Traffic destined for the Internet: VPN termination router, it then forwards into the
WAN-GRE VR and onto the WAN aggregation router. Finally the SFW-NAT-SERVICES
VR performs source NAT for outbound Internet traffic (NAT source address to public
IP pool). Translated traffic forwarded to ISP as per routing table or default route.
The flow of return traffic from the hosted services/Internet/enterprise sites is shown
inFigure 17 on page 34.
Figure 17: Return Traffic Flow to Secure Overlay Enterprise Remote Site
1.
Return traffic from Internet enters the Internet gateway, SFW-NAT-SERVICES VR

checks source NAT table and maps traffic to existing translation. Traffic then forwarded
to VPN termination router WAN-GRE VR (Via WAN aggregation router) where it gets
encapsulated in GRE and IPsec and forwarded to the remote site.
2. Application traffic from hosted services exits enterprise data center and returns to
VPN termination router (via HOSTED-WWW-NAT VR). Inbound firewall and NAT
34
services applied. Traffic is then in the WAN GRE VR where it is encapsulated as above
and forwarded onto the remote site
3. Traffic bound for secure overlay enterprise remote site is forwarded to WAN-GRE VR
for GRE encapsulation. GRE-encapsulated traffic forwarded to VPN VR for IPsec

encapsulation. VPN VR encapsulates GRE tunneled traffic and forwards to IPsec
endpoint (remote site).
a. Site decapsulates and decrypts traffic, forwards to enterprise host
4. VPN termination router forwards traffic to enterprise HQ as per VPN termination and
WAN aggregation routing tables.

Detailed configurations of each of these packet flows (including routing, class of service,
VPN) are found here: Connecting a Small Branch to Dual-Homed Aggregation Hubs
over the Internet on page 281.
Aggregation Hub Transport: Routing Design

The routing protocol design required use of proven protocols that scale well in full-mesh
topologies. The protocols should also be able to function optimally in hub-and-spoke
topologies. The routing protocol function must be network and system efficient requiring
a minimal number of updates, with topology computation largely independent of number
of routes in the network to ensure fast convergence in the event of network failure. The
final focus in the routing design is to ensure simplicity to ease the complexities of
implementation, management, and troubleshooting. The routing protocols chosen for
the branches, aggregation hubs, and WAN transports are a combination of OSPF and
BGP.
BGP Design
The primary routing protocol selected for the WAN aggregation hubs is BGP.
Figure 18 on page 36 shows the BGP design at the aggregation hubs.
BGP is used to fill a these roles in the design:
Between the WAN aggregation and customer equipment (CE), and remote site, IBGP
is used as the IGP for the remote site to enterprise WAN network.
Between the WAN aggregation tier and the core, BGP is used as the EGP with the
service provider
35
Figure 18: BGP Design at the Aggregation Hub
BGP design is slightly different, depending on the branch type, connectivity, and role of
the terminating router.
IBGP is used on the WAN aggregation and VPN termination routers (and connecting
remote sites). This configuration features full mesh IBGP, enabling any-to-any
connectivity through the WAN aggregation tier of the enterprise WAN.
Branches that connected over carrier Layer 3 VPN, the remote sites form a BGP peering
with the service provider (most often a route reflector). In this design, we use the BGP
local preference attribute to override service provider routes and give preference to
routes on the enterprise WAN (at WAN aggregation router 1)
For leased line connected sites, an IBGP peer to the branch is configured on the
terminating WAN aggregation router. The WAN aggregation router serves as a route
reflector in this scenario, advertising only the default route to the leased line connected
branch.
OSPF Design
OSPF is used as the IGP for the enterprise WAN design (Figure 19 on page 37). OSPF is
used as the interior gateway routing protocol because it is easy to configure, does not
require a large amount of planning, has flexible summarization and filtering, and can
scale to large networks. OSPF, as deployed in this solution, reduces the amount of
bandwidth, processing, and memory necessary to carry large route tables while reducing
the convergence times associated with link failures. This is accomplished using route
36
summarization on links where logical boundaries exist (distribution layer links to the wide
area or to a core). OSPF fills a slightly different role depending on the branch connection
type utilized.
Leased-line branches can also use OSPF as the IGP, with a separate OSPF area created
for each branch. Routing policies are configured on the terminating WAN aggregation
router to enable export of BGP routes to OSPF for leased line branches.
Figure 19: OSPF Design at the Aggregation Hub
Multicast Design at the Aggregation Hubs

IP Multicast is a mandatory requirement in the enterprise WAN solution to support efficient
delivery of video and multimedia content within the enterprise. A high level view of the
multicast design at the aggregation hub can be seen in Figure 20 on page 38.
37
Figure 20: Multicast Design at the WAN Aggregation Hub
Multicast is configured in this design using the following elements:
Anycast Rendezvous Point (RP)The enterprise WAN design utilizes an Anycast RP

implementation strategy. This strategy enables load sharing and redundancy in Protocol
Independent Multicast Sparse Mode (PIM SM) networks. The design dictates two
anycast RPs that share resource registration load. Having two RPs also enables the
ability to fail over to a backup RP in the event of failure. These RPs are located in the
Inet.0 routing instance of the WAN aggregation router. The benefit of this design choice
is that all IP routing devices within the enterprise WAN will use identical configuration
that references the Anycast RPs. IP PIM will be enabled on all interfaces, to include
loopback interfaces, VLAN interfaces, and sub-interfaces. These RPs are configured
as static RPs on a loopback interface of the WAN aggregation router.
Multicast securityThe multicast design also features security features to control

access and prevent unauthorized receivers from joining multicast groups to which they
are not permitted access.
Selected RPs for selected groups (RP designation). There are often different sets of
RPs to serve content to select receivers. This content can be configured to use a
dedicated RP with only authorized endpoints permitted to join the multicast groups
terminated on the RP.
38
PIM filteringThis is the filtering of multicast control messages to control or limit

the sending and receiving of these messages. This enables the enterprise to permit
only authorized groups and sources from registering with an RP router.
Class of service to limit multicast bandwidth and prioritize multicast traffic. These
limits will be covered in the class-of-service design considerations.
IGMPv2 configured with snooping enabled, enabling the remote site routers to learn
of new multicast senders and join select multicast groups. This prevents flooding of
unnecessary multicast traffic over the WAN links to the remote sites.
High Availability
The enterprise WAN solution features several tiers of resiliency to enable a highly available
WAN for the enterprise. Given that resiliency is a key requirement of the solution, each
tier of the solution was designed with redundancy at both the hardware and software
level. The solution design guidelines dictate that the network must tolerate single failure
conditions of any single WAN transport link or any network device at the primary WAN
aggregation site. Failover and convergence should be fast (within 2 seconds) and
automatic.
Hardware Redundancy
Redundant router components can be built into the design to enable physical redundancy
per WAN aggregation router. The design is built to be resilient without these components,
but to achieve a high level of availability (five nines or more), it is recommended that
fully redundant hardware be deployed at the WAN aggregation tier of the design. Routing
Engine redundancy provides not only backup control plane functionality, but also the
ability to upgrade software with minimal disruption of traffic (In-service software
upgrade). ISSU support requires that graceful Routing Engine switchover (GRES) and
nonstop active routing (NSR) be enabled as well. GRES enables routing platforms with
redundant Routing Engines to continue forwarding traffic in the event that one Routing
Engine fails. GRES preserves interface and kernel information so that traffic forwarding
is not interrupted. GRES does not preserve control plane information: neighboring routers
will detect that the router has experienced a restart as such, the neighbors will react
to the event in a manner prescribed by the configured routing protocol specifications. To
preserve routing during a switchover, GRES must be combined with GRES protocol
extensions or NSR.
NSR enables a routing platform with redundant Routing Engines to switch over from the
primary to the backup without alerting peer nodes that a change has occurred. While
NSR uses the same infrastructure as GRES to preserve interface and kernel information,
it also preserves routing information and protocol sessions by running the routing protocol
process (rpd) on both Routing Engines. NSR also preserves TCP sessions maintained in
the kernel. NSR and GRES must be configured together to enable optimal high availability
in this environment.
Additional layers of hardware redundancy can be put in place to protect against hardware
failure. Redundant power, cooling, and backplanes can be purchased and installed to
protect against the failure of any of these components.
This design guide does not employ hardware redundancy per-platform, instead favoring
software and geographic redundancy combined with multi-platform hardware redundancy
(the implementation of multiple WAN aggregation nodes). Full hardware redundancy
39
at the WAN aggregation layer is a recommendation, though it does involve expense and
additional configuration to ensure complete high availability of the environment.
Dual-Homing to the Aggregation Hubs

The architecture includes two aggregation hubsa primary hub and a backup hubto
allow branches to be dual-homed to the aggregation site. In dual-homed scenarios,
branches connect to hub 1 as their primary connection, and connect to hub 2 as their
backup connection. This split design enables geographic and hardware redundancy in
the event that one of the aggregation hubs or roles experiences failure. Sites that mandate
dual connection to the aggregation layer will fail over from the primary hub to the
secondary connection in the event of failure. Sites with a single connection via MPLS or
IPsec will have tunnels configured to both aggregation hubs with primary/backup failover
as the goal. If the primary router fails, routing will converge over the secondary tunnel
(already active).
For high availability, we have two aggregation hubs so that branches can be dual-homed
to the aggregation hubs. Both of these hubs peer with each other and forward traffic in
an active standby manner. From a control plane route peering point of view, both hubs
are active. If connections to Aggregation Hub 1 go down, the connections fail over to
aggregation site 2.
For link-level high availability, we are using BFD on the OSPF backbone at the aggregation
hubs. We are also using BFD on the routing protocols on the WAN transports.
LAG and Multi-Chassis LAG

LAG allows the inverse multiplexing of multiple channels into a single logical link, which
is configured and managed as a single port. A primary reason to use LAG technology is
higher bandwidth is required between servers, routers, and switches than single-link
Ethernet technology can provide. This technology also provides resiliency and fast
convergence. When a link fails the LAG provides automatic recovery by redistributing the
load across the remaining links. Traffic is redirected from the failed link to the remaining
links in less than one second. This convergence is transparent to the end user. No host
protocol timers expire, so no sessions are dropped. MC-LAG is utilized at the head-end
(or aggregation hub) to provide node resiliency.
Failover Scenarios
The enterprise WAN solution is designed to use the primary aggregation hub as the main
traffic destination. In the event that the primary aggregation hub fails, or transport to the
primary hub fails, traffic is sent to the backup aggregation hub (Aggregation Hub 2) and
is routed back through the primary aggregation hub (in the event the hub is still active)
to the destination.
The following failover scenarios are covered in this guide:
40
Failure of primary Internet link
Failure of all components at one hub site
Failure of primary Internet gateway, or iEdge
Failure of primary VPN router
Failure of primary WAN aggregation router
Details on these failure scenarios can be seen here: Solution Failover Scenarios on
page 77
Class of Service
In enterprise WAN environments it is critical to be able to schedule and control the traffic
out to the remote branches in order to support the wide array of business critical traffic
types that are generated by todays enterprise. Fine grained class of service to support
voice and video calls as well as business critical and non-business critical traffic is a core
requirement of the solution. The EWAN must be configured end to end to provide class
of service to business critical and real time flows while de-prioritizing non-essential traffic.
The class of service implementation must also be monitored to ensure the network is
providing a consistently high quality end user experience.
Some key design goals for the EWAN solution are:
Traffic must be managed end-to-endClass of service should be implemented,

controlled, and monitored by the enterprise to ensure consistent quality of experience
for the end user.
Traffic from remote sites is not trustedAll remote branch traffic and core LAN
(HQ/Data Center) traffic is re-marked using multifield (MF) classifiers by the CE /
remote site router (enterprise managed) prior to transmission over the uplink to the
WAN aggregation tier.
Traffic is prioritized through the platforms and service cards as completely as possible:
A complete enterprise traffic profile is evaluated, with high priority and essential
application traffic selected and identified by one of several factors (source IP address,
TCP port, etc.).
Traffic is queued and scheduled at the CE and sent over the WAN with agreed-upon
and configured marking values:
Class of service marking is used for Layer 2 VPN service
Class of service marking is used for Frame Relay service
IP Precedence (IPP) is used for the MPLS VPN service
For traffic tunneled over the Internet (IPsec), the traffic is re-marked and policed
before egress from the CE. TOS reflection is configured to ensure the class of service
is propagated from the encrypted payload IP header to the GRE header for processing.
Table 2 on page 42 shows a summary of the classes of service provided by the EWAN
solution, including the service class marking options for layer 3 and layer 2 transports:
41
Table 2: Enterprise WAN Class of Service

Forwarding Class
Loss Priority
Code Point
Queue
Scheduler
Best_Effort
medium-high
be
SCH_Best_Effort
Scavenger (low-priority data)
high
cs1
SCH_Scavenger
Bulk_Data (high throughput

data)
medium high
af11, af12
SCH_Bulk_Data
Critical_Data
medium low
af21, af22
SCH_Critical_Data
Video
low
af41, af42
SCH_Video
Voice
low
ef
SCH_Voice
Network_Control
low
cs6, cs7
SCH_Network_Control
Table 2 shows the various classes of service recommended in the EWAN solution. The
class-of-service design supports CoS classification based on Layer 3 header information
using either per-hop behavior (PHB) markings or differentiated services code point
(DSCP).
Because the solution aggregates multiple types of transport, the configuration of CoS
becomes more challenging. For instance, secure overlay traffic features IPsec tunnels
encapsulated by GRE to enable per-unit GRE scheduling. Per-unit GRE scheduling allows
the implementation of a traffic shaper and traffic scheduling per GRE tunnel: this enables
control of the bandwidth permitted over the tunnel and permits class of service
assignment to traffic passing the tunnel. A key design consideration is ensuring that the
VPN termination router supports per-unit GRE scheduling.
Security
The security of the solution involves protection of both the routing infrastructure
(aggregation hubs, CPE devices) and the protection of enterprise traffic. The infrastructure
utilizes routing protocol protection to protect and monitor the routing infrastructure from
intrusion and attack that would affect its ability to route enterprise traffic.
Routing Protocol Protection

To secure the Routing Engine, we have implemented policers and firewall filters on the
loopback interfaces of the WAN aggregation router. The policers ensure that traffic does
not overrun configured limits and keeps the interfaces from queuing excessive traffic by
proactively dropping traffic when the policing limit is reached. The class-of-service profiles
are configured with drop profiles to ensure that low priority traffic is dropped before any
high priority traffic. Firewall filters are implemented on the WAN aggregation tier router
loopback interfaces to ensure that only permitted traffic and traffic types are processed.
42
Application Layer Gateways

For added security on hub routers that generate Internet traffic, the solution uses ALGs.
These are detailed in the secure overlay security design section located here: Remote
Branch Design Considerations on page 45.
Securing Enterprise Traffic

Traffic passing over leased lines and private Layer 3 VPN services are considered to be
secure due to protections put in place to defend against intrusion. Traffic passing over
the public network from Internet-connected branches, however, is more vulnerable to
intrusion, snooping, and attack. As such, all traffic from these branches is secured via IP
Security (IPsec) protocol. The solution features IPsec with at least AES256 encryption
with Internet Key Exchange version 2 (IKEv2) in use wherever it is supported. A key
consideration in the design was the ability of the network to support dual stack transport,
or the transport of both IPv4 and IPv6 traffic, over a single tunnel. Given this requirement
and the limitations on CoS, the tunneling from remote sites over the Internet also utilizes
a GRE tunnel built within the IPsec tunnel. Although the solution does not implement
additional security for enterprise traffic, there are additional protections that can be
considered, such as Group VPN, if the hardware platforms deployed in the solution
support the implementation of Group VPN. In this solution, CA certificates are used to
authenticate IPsec sessions, providing elevated security over the use of pre-shared keys
(PSK).
Performance and Scale

The enterprise WAN solution is designed to support between 500 and 1000 branches
per chassis deployed in the WAN aggregation tier. Regionalizing WAN aggregation hubs
and adding additional hubs to balance regional site counts that exceed the target scale
of the solution can increase the scale of the solution (Table 3 on page 44). This branch
count assumes up to 600 sites using GRE over IPsec tunnels over Internet and 400
branches connecting to WAN aggregation using a mix of interface type (Leased-line,
Layer 3 VPN).
43
Table 3: EWAN Solution Performance and Scale Goals
Three
Router
Aggregation
Type of Branch
Scale
Bidirectional Throughput
GRE over IPsec
3000 v4 only
800 Mbps
GRE over IPsec
3000 v4+v6
700 Mbps v4
100 Mbps v6
Virtualized
Aggregation
Leased-Line
BGP Scaling NO per Platform
Platform Throughput
GRE over IPsec
3000 v4 only
1.65 Gbps
GRE over IPsec
3000 v4+v6
1.45 Gbps v4
200 Mbps v6
Leased-Line
BGP Scaling NOper Platform
Platform Throughput
Network Management
Junos Traffic Vision
Junos Traffic Vision provides increased visibility to network traffic flows to help you
improve security and increase network efficiency, operations, and planning. Junos Traffic
Vision provides data in an industry-standard format that you can export traffic information
to Juniper Networks or third-party tools. You can then use the data to detect intrusions,
monitor service-level agreements, and analyze usage-based accounting, traffic profiling,
and traffic engineering. Junos Traffic Vision used to be known as JFlow accounting.
SNMP
Used to monitor and measure network performance and availability. SNMP is used in
this solution to monitor interface state, packet performance (loss, drops, packets
transmitted). SNMP can be used proactively or reactively. SNMP polling is a regularly
scheduled status poll that is sent from a network management system (OpenNMS on
Junos Space, for instance) that determines the state of various components of the target
system. SNMP polling is usually used to monitor networks for down interfaces and packet
loss so network operators can troubleshoot and restore network operation. SNMP traps
are specifically configured event triggers on a network or host platform that are triggered
by a specific event ( x number of invalid login attempts have occurred on the WAN
acceleration routing engine). SNMP traps are designed for the network operators to react
to events that are not typically caught by SNMP polling.
System Logging
System logging, or syslog, is a standard protocol used for the logging of computer or host
messages. In this solution, syslog is used to forward targeted messages to a downstream
syslog server. The message types are separated and identified by severity level. Network
operators typically look to log and review syslog messages that fall in the Error, Alert,
44
Critical, or Emergency levels. This type of syslog message is often triggered by network
events that must be addressed to prevent outage or potential security issues.
Hardware Platforms
The devices at the aggregation hub must consolidate multiple networks. These devices
must be scalable and support a range of interfaces such as T3, GRE tunnels, they must
support services such as IPsec, IP routing, dual-stack, consolidate multiple networks at
the aggregation hubs.
For the three roles at the WAN aggregation hubInternet edge, WAN aggregation, and
VPN terminationyou can use a separate router for each role or you can use a single
router for all three roles.
MX Series 3D Universal Edge Routers: MX Series are scalable, high-performance routers

capable of supporting all types of business, mobile, and residential services for the
enterprise WAN-core connecting data-centers, campuses and large regional sites.
SRX Series Services Gateways: SRX Series Services Gateways are high-performance
network security solutions for enterprises and service providers that pack high
port-density, advanced security, and flexible connectivity, into easily managed
platforms. These versatile and cost-effective solutions support fast, secure, and highly
available, data center and branch operations, with unmatched performance to deliver
some of the industrys best price-performance ratios and lowest TCOs.
M7i Multiservice Edge Router: The M7i is the most compact edge routing platform. With
10 Gbps of throughput and integrated service capabilities, the M7i is ideal as an IP/MPLS
service provider edge router in small POPs (points of presence) or as an enterprise
edge router for Internet gateway or branch aggregation.
Remote Branch Design Considerations

The WAN aggregation routers aggregate and backhaul enterprise WAN connections from
remote sites. This solution provides design guidance and configuration for several remote
site types (Table 4 on page 46). The Large router site utilizes dual circuits and dual routers
to provide a maximum amount of redundancy and performance. Medium sized sites
utilize a single router but are split into two site types: medium site with dual connections
into the WAN aggregation and a medium sized site with a single WAN connection. Finally,
a small site is outlined. The small site is one that is not reachable by a leased line or
carrier-provided Layer 3 VPN. In these cases, the enterprise often utilizes local Internet
access to build a VPN connection into the enterprise. The small site connections (and
any site with Internet backup) are connected via the VPN termination router.
45
Table 4: Enterprise WAN Remote Site Types
Dual
Carrier
Dual-Homed
to
aggregation
hub
Link-Level High
Availability
Branch
Size
Branch
Router
Small
Single
T3 or Ethernet
Leased-Line
No
No
BFD
Provided by service
provider
OSPF or BGP
Single
Internet
Yes
Yes
BFD
Security zones
OSPF or BGP
Transport
Security
Routing
Protocol
IPsec with optional

certificates
Medium
Large
Single
Dual
Layer 3 VPN
with backup
Internet
Yes
Layer 3 VPN
Yes
Dual
Yes
Yes
Yes
Yes
BFD over
Internet
Transport
security from
service provider
Provided by
service provider
IPsec
OSPF
Routing Engine
protection
BGP
Transport security
from service provider
EBGP
IBGP
Routing Engine
protection
OSPF
IPsec
EBGP
Routing Engine
protection
IBGP
OSPF
Remote site design considerations are covered in the next sections and include:.
Transport
Routing design
High availability
Class of service
Security
Services
Remote Site Transport Design

The enterprise WAN solution contains three basic transport design scenariosprivate
leased line service, MPLS Layer 3 VPN service (service provider managed Layer 3 VPN),
and secure overlay (GRE over IPsec). Each of these transports has unique configuration,
design considerations, and caveats that must be observed in order to properly implement
the solution.
46
Leased-Line Transport
The first remote site to enterprise WAN transport featured in the solution is the use of
private leased-line service. With this transport, the branch router connects to an
aggregation hub over a leased line service. This implementation allows for the use of any
TDM or optical-based leased line service as well as Ethernet leased line service as the
transport from the branch to the enterprise WAN. The solution was tested with DS3 (over
Channelized OC3) and Ethernet access: any leased line service should work within this
design. Figure 21 on page 47 shows the topology of leased line transport.
Figure 21: Leased-Line Transport from Enterprise Remote Site
This transport configuration is the simplest of the three solution options because it is
provisioned as a private, point-to-point circuit (circuit-switched service) between the
remote site and enterprise WAN. The connection can terminate on a physical interface
at the remote site and to a single physical interface at the aggregation hub, or as a bundle
of channelized circuits over a larger pipe (terminated as multiple DS3s over a channelized
OC3/STM-1). The design of the end-to-end solution is the simplest with this option but
often comes at a much higher cost due to the typical cost of private circuit-switched
service through the service provider network.
MPLS (Layer 3 VPN) Transport

The second remote site to enterprise WAN transport featured in the solution is managed
Layer 3 VPN. This design option offers convenience and a wide footprint as managed
carrier services are widely available in areas where the enterprise is likely to have a large
concentration of offices. This transport option is provided by the carrier as either a Layer
2 service (Metro-E, Layer 2 Pseudo-wire) or as a routed Layer 3 service (Typical MPLS
Layer 3 VPN). In either case, the carrier builds a VPN tunnel through the existing MPLS
core that terminates on the enterprise WAN at the aggregation hub (Figure 22 on page 48).
47
Figure 22: Managed MPLS Connection into the Enterprise WAN
This design offers a mix of convenience and cost savings at the expense of control. This
service is configured over a packet-switched network (MPLS) that features a large degree
of oversubscription. Because the end-to-end circuit is virtual (not statically configured
as in the leased line transport), this type of service can often be obtained at lower cost
than the leased line option. In this transport option, the end-to-end transport is secure,
private, and will often come with a service-level agreement (SLA) to ensure specific
uptime, performance, and class of service vectors are consistently achieved. This option
does surrender a bit of control to the service provider. Routing on a Layer 3 VPN service
is often performed between the remote site and the carrier: as such, some design
considerations are made to ensure the enterprise can control the routing between the
remote site and the WAN. CoS will often need to be re-mapped as well if the service
providers Layer 3 VPN CoS offering does not exactly match the enterprise. Each of these
design considerations is covered in later sections of this document.
Secure Overlay (GRE over IPsec) Transport

The final transport in the enterprise WAN solution is secure overlay. Secure overlay
involves creation of a secure tunnel between the remote site and the enterprise WAN
over the Internet (Figure 23 on page 49). The remote site in this transport scenario can
connect over any type of public Internet access (DSL, cable, satellite). This is a common
enterprise deployment scenario for small remote sites with no access to carrier MPLS or
prohibitively expensive leased line access. Small branches are often well served by best
effort Internet service that connects the branch to the rest of the enterprise over VPN. In
this solution, the primary VPN tunnel between the remote site and the enterprise is
configured as GRE + IPsec (GRE encapsulated within IPsec) to ensure security and full
class of service compatibility with the solution.
48
Figure 23: Enterprise Remote Site Connected via Secure Overlay
The primary design consideration with this scenario involves a trade-off between cost,
convenience, and complexity. This type of solution is common to small enterprise remote
sites because it is inexpensive, some form of Internet access is available most anywhere,
regardless of location, and the enterprise is accustomed to building this type of remote
access network. This option within the enterprise WAN solution is somewhat complex,
however. Before moving on to routing and class-of-service design, it is important to
understand how the secure overlay tunnels are designed and why they are designed this
way.
In understanding the design chosen for IPsec one must consider the multitudes of options
available to configure IPsec in Junos OS. These options are outlined below and
configuration example are provided here: Connecting a Small Branch to Dual-Homed
Aggregation Hubs over the Internet on page 281.
49
1.
Use point-to-point IPsec tunnel configuration with static remote addressing and static
routing. This is the simplest case but the configuration is extensive and the aggregation
site needs to be configured every time a new site is added. Additionally the remote
sites public IP address needs to be known, so in most SOHO environments this is not
achievable as their addresses are DHCP assigned. It has to rely on dead-peer detection
for failover.
Advantages
Disadvantages
Simple configuration
Large configuration
No routing overhead over IPsec tunnels for remote site

addressing (or GRE loopback advertisement) Scales well.
Aggregator needs configuring for every new site.

Requires on static public IP on remote site.
Rely on DPD for failure discovery (failover).
2. Use point-to-point IPsec tunnel configuration with static remote addressing and
dynamic routing. This is the simplest case but the configuration is extensive and the
aggregation site needs to be configured every time a new site is added. Additionally
the remote sites public IP address needs to be known, so in most SOHO environments
this is not achievable as their addresses are DHCP assigned. As detailed below the
failure discovery can be faster, and choice of routing protocol is important for scale.
BGP scales well, BUT needs additional static routing for peer addressing reachability.
OSPF and IS-IS discover peers.
Advantages
Disadvantages
Large configuration
Can rely on routing protocol for IPsec failure (or

BFD)
Aggregator needs configuring for every new site.

Relies on static public IP.
Less scale as routing protocol running over IPsec tunnel now reliant
on routing protocol scale.
3. Use dynamic end point IPsec with dedicated services Interface per site (and
proposal/policy). This option is chosen when the remote sites public IP address is
unknown (dynamic) yet one still wants to run a routing protocol over every IPsec
tunnel. A dedicated service interface is required for a routing protocol as in shared
mode the protocol has no dedicated IFL.
Advantages
Disadvantages
Less scale as routing protocol running over IPsec tunnel now

reliant on routing protocol scale.
Can rely on routing protocol for IPsec failure (or BFD)

Site can have a dynamic public IP address.
Need to configure a large number of SP units initially and add all

to a routing protocol.
4. Use dynamic endpoint IPsec with shared services interface and reverse route insertion
(RRI). This option is chosen when the remote sites public IP address is unknown
50
(dynamic) and for scale one does not want to use a dynamic routing protocol over
the IPsec tunnels. Here RRI is very useful as on the aggregator one can use a
super-netted summary network in the proxy-pair configurations matching a site
proposal. These proxy-pair configurations, if accepted, cause installation of a static
route matching the source and destination in the proposal.
Advantages
Disadvantages
Less scale as routing protocol running over IPsec tunnel

now reliant on routing protocol scale.
Small configuration.
Need to rely on DPD for failure detection.
Zero touch IPsec provisioning on aggregator.
Site can have a dynamic public IP address.
As you can see form the above options number 4 fits this design perfectly. In this
aggregation design we can make the IPsec very lightweight and use dynamic endpoint
IPsec in shared mode (small configuration) and use RRI to install the routes required for
GRE tunnel endpoint reachability, thereby allowing for a large scale of IPsec tunnels.
Additionally because we are running BGP and OSPF over these GRE tunnels we do not
need to rely on DPD for failure detection. In this case routing protocol hello and
dead-timers are used or for very fast convergence, BFD can be configured.
The creation of a secure remote site to enterprise WAN transport over public Internet is
the goal of this solution. The solution must support full class of service and resiliency
while also protecting the enterprise data. As a result, the secure overlay tunnel designed
in this solution utilizes IPsec to secure the transport between the remote and enterprise
WAN. Within the IPsec transport, a second GRE tunnel is built: it is this GRE tunnel that
encapsulates and transports the enterprise traffic. This stacked tunnel approach involves
a seemingly complex configuration. Once the tunnels are built, the creation of multiple
end tunnels is quite easy because the solution features IPsec dynamic endpoints along
with a simple, automatic configuration that brings up the end-to-end tunnel, establishes
routing, and fails over in redundant environments as per the requirements of the typical
large enterprise.
The first piece of the design, the IPsec tunnel, is configured at the remote site to initiate
from an interface in the untrust-vpn routing instance: the IPsec tunnel terminates on the
VPN VR routing instance at the aggregation hub. During this phase of the transport setup,
the following occurs:
1.
IPsec tunnel negotiates phase 1 / phase 2 using either pre-shared key or certificate
authentication (both were tested): tunnel is established. Tunnel source at remote is
untrust-vr, tunnel destination at aggregation router is the VPN VR of the VPN
termination router (or routing instance).
a. Remote site local-ID/remote-id are the local loopback IP address and the loopback
IP of the aggregation router.
b. The aggregation router matches the remote site loopback (local-id) to a configured
access list and allows the tunnel to terminate on a SP interface.
51
c. Reverse route injection occurs, advertising and injecting the /32 route to the remote
loopback (used for the GRE tunnel) pointing to the spawned SP interface
2. The reverse route injection adds the next-hop interface to the routing table as a static
route. This route is the termination point (tunnel end point addressing) for the GRE
tunnel.
The second part of the design, the GRE tunnel, initiates from a loopback interface in the
default routing instance at the branch and terminates at the VPN routing instance of the
aggregation hub, with the INTERNAL addressing of the GRE tunnels (dual stack) belonging
to the WAN-GRE VR:
1.
Once the IPsec tunnel is established, and reverse route injection adds the route to the
loopback interface of the aggregation router, the GRE tunnel is established (between
the loopback at the remote, in trust-vr, and the loopback on the aggregation router,
in the VPN routing instance).
2. All routing between the remote site and enterprise flows through the GRE tunnel
(encapsulated within and encrypted by IPsec). Routing is covered in the next section.
The end-to-end flow and order of tunnel setup is shown in Figure 24 on page 52.
Figure 24: Secure Overlay Design for Connecting Remote Sites to the
Enterprise WAN
52
As mentioned earlier a key to the functionality of this transport is the use of IPsec dynamic
endpoints with reverse route injection. This technology has its roots in client-server VPN.
IPsec dynamic endpoint configuration enables a relatively simple configuration and
initiation of tunneling between the client (remote site) and server (VPN termination @
aggregation hub). The dynamic IPsec endpoints with reverse route injection works in the
following way:
1.
Phase 1 of the IKE negotiation occurs. Pre-shared key (PSK) or certificate are
exchanged and authenticated. Phase 1 is successful, phase 2 IKE negotiation begins.
2. Phase 2 of IKE negotiation occurs. In this phase, local and remote IDs (peer IDs) are
authenticated and protected by the creation of an IKE SA policy.

3. The remote site is configured with a local ID and a remote ID. The local ID corresponds
to the IPsec termination loopback address of the remote site and the remote ID
corresponds to the IPsec termination interface on the hub.
4. The hub site is configured with a local ID (the IPsec termination loopback) and a
remote ID. This remote ID is configured as a range of IP addresses, however. (if the
remote sites utilize IP addressing in the 172.20.0.0/20 subnet as their remote local
loopback addresses (used for GRE tunnel termination), the remote ID for the hub
would be 172.20.0.0/20). This configuration enables any remote site with the proper
loopback address to terminate an IPsec tunnel on the hub
5. Once phase 2 occurs, the hub, utilizing the IPsec dynamic endpoint feature, performs
reverse-route injection, inserting a route into the remote sites routing table that points
to the GRE-termination interface at the hub (using the IPsec next-hop at the hub).
6. Once the remote site has a route to the hub loopback (GRE termination loopback),
the remote site can initiate the GRE tunnel.
NOTE: More information on IPsec dynamic endpoint configuration can be

found here: Juniper Networks Technical Publications.
The use of GRE over IPsec as the tunneling protocols adds some complexity to the
solution but does show the enterprise a couple of benefits:
FlexibilityIPsec support for some solution services such as multicast, class of service,
and dynamic routing protocol configuration has not yet been integrated into the solution
platform. The solution features support for dual-stack deployment (IPv4 and IPv6),
so the combination of IPsec and GRE is required for the current solution.
Greater interoperabilityMost routing vendors support GRE. Deploying GRE allows the
solution to operate with most other vendor routing and VPN termination productions
enabling some assurance that elements of this solution will integrate easily into
multi-vendor environments.
Remote Site Routing Design

The routing between the enterprise and remote sites is configured and managed in slightly
different ways, depending on the transport chosen. The solution design provides both
53
OSPF and BGP to be used as the IGP for enterprise remote sites. For enterprises with
more than 500 remote sites connecting over the enterprise WAN, we recommend using
BGP due to the greater control and scale it provides. Enterprises with fewer than 500
sites are better served by OSPF due to its simplicity and optimal scale for smaller routing
environments.
When using BGP as the IGP over the leased line interface, the solution utilizes an IBGP
peer group on the branch and WAN aggregation router. The IBGP peer (WAN aggregation
router) acts as a route reflector for the branch BGP session. The branch is configured to
accept only a default route from the WAN aggregation hub (using IBGP import policy)
to ensure that all outbound traffic flows through the configured primary uplink to the
enterprise WAN (to Aggregation Hub 1). BGP export policies deny default route
advertisement back to the hub to prevent routing loops. BGP advertises the remote site
router loopback address to the hub (used as the next-hop interface for branch-bound
traffic).
Generally, when OSPF is used as the IGP, the WAN aggregation router will advertise an
OSPF default route to the remote sites. This minimizes the size of the routing table at
the remote site and enables simpler troubleshooting of routing issues. When OSPF is
used, each remote router is configured as a separate OSPF stub area, advertising its local
networks to the aggregation hub and importing only the default route from the backbone
area (OSPF Area 0). If OSPF is chosen, there are two key design considerations:
The backbone will always be area 0 (This is common to all OSPF deployments as
OSPF area 0 is also called backbone area)
Area x: Each remote site will be assigned a unique OSPF area ID. The area is configured
as a stub area to ensure that branch routes are not advertised beyond the backbone
area and to enable greater control of enterprise routing. The remote site should only
receive a default route from the backbone router.
Leased-Line Routing
This routing scenario is the simplest in the solution due to the presence of a dedicated
virtual circuit between the remote site and the hub. The remote site utilizes a loopback
interface as the peering interface for either BGP or OSPF. The hub site utilizes a similar
configuration in the WAN aggregation router. As in all of these solutions, only a default
route is advertised by either OSPF or BGP to the remote site. BGP route injection and
export filters are used at the remote site to accept only the BGP default-route and to
export all local routes save for the BGP default-route (the remote site often has a second
default-route from a backup uplink). This prevents the introduction of routing loops into
this topology. The hub site should also be configured with a BGP import policy that
prevents import of BGP default-routes from the remote sites to ensure routing loops are
not introduced.
54
Layer 3 VPN Routing

The Layer 3 VPN routing scenario is a bit more complicated due to the presence of service
provider routing. It is likely that the service provider will provide an EBGP route reflector
to enable BGP peering and route advertisement over the Layer 3 VPN
(Figure 25 on page 55). In this scenario, there are a couple of design considerations to
keep in mind:
To maintain control of routing, the use of the AS Override BGP attribute is required.
This attribute should be set to override the AS assigned to the BGP session, enabling
the remote site router and hub router to exchange routing information.
BGP routing policies must be applied at the remote site to prevent routing loops:
EBGP export policy should be configured to prevent default route from being
advertised to the enterprise. The export policy allows for only OSPF and direct routes
to be exported.
EBGP import policy should be configured to accept only the default route (the peer
should only send the default route). The policy should also set the proper local
preference in cases where there are multiple uplinks (200 preference to configure
the peer as the preferred path, default preference for backup link EBGP peers).
Figure 25: Layer 3 VPN Routing Between Remote Site and Enterprise WAN
Secure Overlay Routing

The routing on the secure overlay network can also be configured as BGP or OSPF. The
peer interface used for routing is the trust-vr loopback interface on the remote site and
the WAN-GRE interface on the hub site (Figure 26 on page 56). The additional routing
considerations all hold true for this scenario:
If using BGP, import and export policies will dictate import of only default-route and
export of only local routes and OSPF routes (no default route export).
55
If using OSPF, the remote site will be configured with a unique area number (stub area)
and will only import the summary (default) route from the enterprise.
Figure 26: Secure Overlay Routing Configuration
Remote Site High Availability Design

One of the design goals of this solution was to insure resiliency and availability of
enterprise resources to the remote sites. This goal is met by the designs provided within
this solution. There are various site types with different type of resiliency configurations
that scale in cost and availability from larger sites that must have a very high level of
resiliency (five 9s or greater) to smaller sites that have more leeway in experiencing
outage (very small offices or home workers, for instance).
Single Remote Site CPE with Single Transport

This configuration option is typically deployed for small sites where an outage of some
duration would be permitted. In this scenario, the local transport to the enterprise is a
single link, either over leased line or Internet (secure overlay). In the leased line scenario,
it is expected that the circuit-switched transport between the remote site and the
enterprise should have some level of backbone resiliency created to enable the circuit
to avoid outages caused by service provider issues on the network. Because this
configuration features a single last mile with no redundant circuit, if the last mile is
affected (cable cut, local outage, power outage, etc.), the site is down until the problem
is repaired. Of the design options, this is the least resilient. Bidirectional Forwarding
Detection (BFD) is employed to monitor link-level availability of the leased line transport.
BFD enables millisecond-level failure detection at the link layer and enables faster
convergence of configured routing protocols. At sites where the transport is experiencing
outages on a regular basis, a backup Internet circuit can be provisioned and configured
to provide a secondary path to the enterprise.
In the secure overlay configuration that utilizes a single uplink to the Internet, some level
of resiliency is possible using a backup GRE over IPsec tunnel configured to terminate on
the secondary WAN aggregation hub (Figure 27 on page 57). In this scenario, the secondary
tunnel is created at site turn-up and remains up, though routing over that tunnel is
56
configured with a lower preference to force all traffic over the primary GRE over IPsec
tunnel. When the primary tunnel experiences an outage, the remote router recognizes
this outage, downs the interface associated with the tunnel (primary loopback) and
replaces the active routes in the routing table with the backup tunnel routes. To enable
fast detection of failures of the secure overlay tunnel, BFD is employed. BFD enables
millisecond-level failure detection at the link layer and enables faster convergence of
configured routing protocols.
Figure 27: Backup Secure Overlay Tunnel Created from Single Uplink
Remote Site
Single Remote Site CPE with Backup Transport

The enterprise WAN solution features design and configurations for sites that have a
single router with multiple transport options to the enterprise. The solution tested Layer
3 VPN with Internet as a backup, but the configuration can just as easily be converted to
Layer 3 VPN with Layer 3 VPN backup, leased-line with Internet backup, or Internet with
Internet backup by applying the routing design considerations and high availability designs
relevant to the backup chosen for a remote site. This design provides options for Layer
3 VPN with Layer 3 VPN backup and Layer 3 VPN with Internet backup.
57
Redundant Remote Site CPE with Primary and Backup Transport

The final configuration option for remote site redundancy is the use of dual CPE at the
remote site with a primary and backup transport. For this solution, Layer 3 VPN using
Layer 3 VPN backup was utilized (Figure 28 on page 58). This design scenario is the most
complex of the remote site designs due to the likely business criticality of a site that
justifies two separate routers and paths to the enterprise. Sites that meet this profile
should be minimally affected by any service outage, thus justifying the high level of
redundancy provided.
Figure 28: Layer 3 VPN with Secondary CPE and Backup Layer 3 VPN
Service
Some key design considerations for this scenario include:
Use of OSPF (area 1) as the IGP of the remote site. Sites of this type are likely to have
multiple VLANs, business units, and business services such as voice, video, and data,
all coming from different VLANs on the network. The use of OSPF as the IGP enables
a layer 3 switch to act as the local router for the branch, controlling routing within the
branch and advertising local routes to the branch router (which advertises those routes
to the enterprise).
Redundancy between the remote site routers is achieved utilizing Virtual Router
Redundancy Protocol (VRRP). VRRP v3 (RFC 5798) provides a routing redundancy
mechanism for both IPv4 and IPv6, creating virtual router interfaces that favor a primary
or backup router in the redundant pair. A VRRP Master is configured with a priority of
200 and the Backup is configured with a priority of 100 (higher VRRP priority is the
master) to ensure that all traffic flows through the primary router to the enterprise.
EBGP peering is configured as illustrated in the routing design section.
58
The primary Layer 3 VPN is configured with an import policy setting the preference
of routes received via that interface to 200, making this the preferred path for traffic.
The backup Layer 3 VPN BGP routes are left as the default preference
Remote Site Class-of-Service Design

A key enterprise WAN solution design goal is that the solution be designed to support
services and that the solution be designed for flexibility and scalability. The
class-of-service design for this solution achieves these goals. The enterprise WAN solution
is built to support seven classes of service that map to the prioritization of common
business services and requirements Table 5 on page 59.
Table 5: Enterprise WAN Class-of-Service Values

Forwarding Class
Loss Priority
Code Point
Queue
Scheduler
Best_Effort
medium-high
be
SCH_Best_Effort
Scavenger (low-priority data)
high
cs1
SCH_Scavenger
Bulk_Data (high throughput

data)
medium high
af11, af12
SCH_Bulk_Data
Critical_Data
medium low
af21, af22
SCH_Critical_Data
Video
low
af41, af42
SCH_Video
Voice
low
ef
SCH_VOICE
Network_Control
low
cs6, cs7
SCH_Network_Control
The classes of service recommended in this solution enable high-priority, real-time

transmission of voice and video traffic, elevated priority for business-critical data, and
ample performance and priority for lower priority traffic. Before diving into the
class-of-service design considerations for this solution, we should take a moment to
provide an overview on the operation of class of service on Juniper Networks routers and
in Junos OS operating system.
NOTE: More detail on class-of-service configuration can be found here: Junos

OS Class-of-Service Overview & Examples
The basic components of Junos OS class of service are:
ClassifiersPacket classification refers to the examination of an incoming packet. This

function associates the packet with a particular CoS servicing level. In the Junos OS,
classifiers associate incoming packets with a forwarding class and loss priority and,
based on the associated forwarding class, assign packets to output queues. Two
general types of classifiers are supported:
Behavior aggregate (BA) or CoS value traffic classifiersBA is a method of

classification that operates on a packet as it enters the routing device. The CoS value
59
in the packet header is examined, and this single field determines the CoS settings
applied to the packet. BA classifiers allow you to set the forwarding class and loss
priority of a packet based on the Differentiated Services code point (DSCP) value,
DSCP IPv6 value, IP precedence value, MPLS EXP bits, and IEEE 802.1p value. The
default classifier is based on the IP precedence value.
Multifield traffic classifiersA multifield classifier is a second method that can be

used for classifying traffic flows. Unlike a behavior aggregate, a multifield classifier
can examine multiple fields in the packet. Examples of some fields that a multifield
classifier can examine include the source and destination address of the packet as
well as the source and destination port numbers of the packet. With multifield
classifiers, you set the forwarding class and loss priority of a packet based on firewall
filter rules.
Forwarding classesThese are simply buckets of traffic that affect the queuing,
prioritization, and forwarding of traffic.
Loss priorityThis configuration option determines the likelihood or priority that a

packet will be dropped during a period of congestion or queue saturation.
Transmission scheduling and rate control
QueuingThis determines the order in which packets are sent to the downstream
router. Higher priority packets are sent first with the lower priority packets queued
and sent as bandwidth becomes available.
SchedulersThe scheduler is the configuration point for queue number, priority, and
loss priority. This determines which packets fall into each CoS queue and how each
type of traffic will be treated.
Policers for traffic classesThese enable the limiting of bandwidth in a certain class
of traffic. Policers are often used to limit the amount of high priority traffic that can
pass: without a policer, high priority traffic could starve the rest of the CoS queues
and cause severe degradation in service. Policers can be applied across the entire
class of service footprint to ensure that no single class of traffic can starve the rest
of the classes.
NOTE: This solution employs various Juniper Networks routing and security
platforms at the aggregation hubs and remote sites. Some platforms have
a slight difference in the way traffic is counted due to the difference in how
each platform accounts for Layer 2 overhead. More information on the
accounting of Layer 2 overhead in interface statistics can be found here:
Juniper Networks Technical Publications.
Egress traffic shaping overhead can also be configured to normalize
accounting statistics. More information on the calculation and modification
of egress shaping overhead in class of service can be found here: Juniper
Networks Knowledge Base.
60
Layer 3 VPN and Leased-Line Class-of-Service Design

Class of service configuration for this branch type is simple due to the interoperability
with the Layer 3 VPN service providers class-of-service configuration. In some cases,
the enterprise classes of service does not match what the service provider provides: in
those cases, some re-mapping is required. In this scenario, the Layer 3 VPN service was
purchased and provisioned with class of service that matches completely with the
enterprise requirements. Class of service is configured on both the aggregation hub and
remote site to adhere to the enterprise standards and requirements. Inbound class of
service markings (from the WAN) are inherently trusted and prioritized by the remote
router as per the class of service policy. The inbound class of service processing occurs
as shown in Figure 29 on page 61.
1.
CoS marking on traffic sourced from the core is inherently trusted: no remarking is
performed.
2. On WAN aggregation egress, hierarchal CoS queuing is applied based on DSCP
configured for outbound interface. Traffic shaping occurs to normalize bandwidth to

leased line bandwidth. DSCP rewrite occurs to match CoS for leased line service.
3. Branch router receives traffic, applies inbound CoS policies and forward to hosts on
LAN.
Figure 29: Inbound CoS to Small Remote Site Using Leased-Line Access
Class of service configuration and packet flow for outbound traffic is configured as seen
in Figure 30 on page 62.
1.
Inbound traffic from the remote site LAN to the branch router.
2. Ingress interface firewall filter configured with CoS multifield classifier. Mark based
on source/destination address or protocol/port (can match one or all). Traffic is also

shaped to match ISP port speed (contracted rate).
3. On ingress, WAN aggregation remarks traffic to CoS for core traffic and forward to
destination.
61
Figure 30: Outbound CoS to Small Remote Site Using Leased-Line Access
Secure Overlay Class-of-Service Design

The class-of-service design for secure overlay utilizes the same queues as the rest of
enterprise with some key differences. Because the traffic between remote site and
enterprise is encapsulated twice (GRE over IPsec), there are configuration elements that
must be added to ensure that the class of service markings are properly implemented.
The GRE interface is required by this solution specifically to enable per-unit scheduling
of traffic and to control bandwidth and priority of traffic over the secure overlay tunnel.
When configuring class of service over GRE, the following features must be used:
Type of service (ToS) byte preservation
Per-unit GRE scheduling
The classification and queuing of upstream traffic in this scenario is done based on DSCP
markings: these markings are applied to the payload IP header (in the DSCP field) by a
multifield classifier. Because the traffic is encrypted and encapsulated, the encapsulating
IP header (GRE header and IPsec header) do not automatically have the class of service
markings from the payload IP header. This is overcome by enabling ToS reflection. ToS
reflection enables the copying of the payload IP header attributes (in this case, the DSCP
field) to the outer IP header (The GRE and IPsec headers). This ensures that downstream
routers and the hub can properly apply class-of-service actions on traffic between the
remote site and enterprise.
Per-unit GRE scheduling is the second feature that must be used to properly enable class
of service in the secure overlay transport scenario. This configuration simply means that
the class of service ingress and egress interface is set to the GRE tunnel interface. At the
remote site, an SRX Series Services Gateway is used to terminate secure overlay tunnels.
In this scenario, the loopback interface is the termination point for the GRE tunnel
(loopback located in the trust-vr and in the untrust security zone). On the hub, the GRE
tunnel terminates on the WAN-GRE VR- class of service is applied to that logical
interface.
62
Class of service is applied between the enterprise (hub) and the remote site as seen in
1.
Inbound traffic from the enterprise is trusted: no remarking is done on this traffic.
Traffic routed to WAN-GRE VR (VPN termination router) for routing to secure overlay
remote site
2. CoS is applied to GRE tunnel interface
a. Hierarchal scheduling on the traffic is performed on GRE tunnel interface ingress

based on existing DSCP markings from enterprise
b. GRE tunnel is traffic shaped to remote site circuit port rate. CoS is applied to GRE
tunnel traffic (traffic is queued to the remote site)
c. ToS byte reflection performed on GRE egress.
3. Traffic is forwarded to the destination endpoint
Figure 31: Secure Overlay Class-of-Service Actions Between Hub and

Remote
Between the remote site and enterprise, class of service is applied as seen in
1.
On ingress, the remote site router applies DSCP markings based on multi-field classifier
(source IP, destination IP, protocol, port, source VLAN).
2. Traffic bound for enterprise is scheduled as per class-of-service configuration on the
branch.
a. CoS is applied to GRE tunnel: traffic shaped to ISP port rate.
b. ToS reflection is performed, copying the TOS marking from the payload IP header
to the IPsec IP header.
3. On ingress to WAN aggregation, no CoS action is performed
4. On egress to enterprise, DSCP on IP payload header is queued as per enterprise CoS
policy.
63
Figure 32: Secure Overlay Class of Service Between Remote Site and
Enterprise
Remote Site Security Design Considerations

The design of a private WAN should be inherently secure. A large enterprise would not
seek to overlay a privately managed WAN if the need for enhanced security and control
over the end-to-end environment was not important. The entire solution employs security
controls to ensure the environment is safe from intrusion, and to insure the enterprise
data privacy is maintained. Some security measures that are recommended for the
enterprise WAN solution are:
Access Control
Access control on all EWAN nodesauthentication, authorization, and accounting

(AAA) services should be configured to control access to all network resources. The
solution supports RADIUS and TACACS.
LoggingAll nodes in the EWAN should be configured to log so the network

administrators can audit not only access requests, but also verify that no intrusion
attempts have occurred (this is done by logging failed access attempts).
The entire solution should be integrated with a global access management system to
enforce access privileges (such as LDAP or MS Active Directory).
Secure Connectivity
All voice, video, and data traffic should be separated on the enterprise LAN to ensure
integrity and performance of high priority traffic.
Network management traffic should also be separated.
Threat protection, detection, and mitigation
64
The branch CPE should be configured to block unauthorized outbound traffic
Incoming traffic to the branch and enterprise HQ/Data Center should be verified to
ensure the traffic is coming from an authorized source address.
Protection should be in place to identify and mitigate common denial-of-service (DOS)

and distributed denial-of-service (DDOS) attacks. Known access methods for worms
and Trojans should also be blocked wherever possible.
The branch offices should be protected from malicious attacks from outside and inside
the network.
The branch and enterprise hub CPE should be protected from attacks and intrusion
from within the network (using network management source filters, for instance)
In addition to these security protections, each transport type often requires additional
protection to ensure a secure, end-to-end enterprise WAN.
Leased-Line Security
Leased-line service from a service provider can be reasonably assumed to be secure as
it is a private, circuit-switched service between the remote site and the aggregation hub.
The routing protocols running over the leased line service utilize routing protocol
authentication (MD5) to ensure only valid routers can form peering relationships with
the branch. More security-minded enterprises often choose to configure additional security
between the remote site and hub. IPsec can be configured over the leased line in cases
where elevated security must be achieved.
Layer 3 VPN Security

The Layer 3 VPN service is also widely considered to be secure, though some enterprises
bound by regulatory rules often need to introduce elevated security to the design. For
these cases, Juniper Networks offers Group VPN on SRX Series Services Gateways. This
version of the enterprise WAN solution does not feature Group VPN.
Secure Overlay
This transport type is configured from a remote site firewall (SRX Series). As such, it
offers elevated protection against most threats against the enterprise. Given that this
transport is directly exposed to the Internet, the elevated security is a strict requirement.
To address this concern, traffic is separated into a trust zone and an untrust zone. We
are using a virtual routing and forwarding (VRF) routing instance for untrusted traffic,
which is defined as Internet traffic; or more specifically route peering with the ISP, IPsec,
and GRE tunnel endpoints. The VRF routing instance contains Internet-facing interfaces
for the branch. This routing instance does not allow Internet traffic onto the branch LAN,
and therefore, protects the enterprises internal routing tables and keeps public addresses
and private addresses separate by not allowing public addresses into the default IPv4
(inet.0) and IPv6 (inet6.0) routing tables.
The remote site also features security zones. On SRX Series, security zones must be
configured before traffic can be forwarded. Once the security zones are created, security
policies must be created to explicitly permit or deny traffic in one direction (trust to untrust
zone, for instance). When secure overlay is in use, we are using three zones: one for trust
traffic, one for untrusted traffic, and one for management traffic. The remote site router
is configured with policies that specify what traffic is allowed to move between zones.
Typically, the firewall will be configured to only allow local IP traffic from the trust zone
(the remote site) to the untrust zone (the rest of the enterprise). Management traffic is
typically not permitted from the trust zone as this solution is designed to be centrally
65
managed. Traffic in the management zone (from the enterprise) is permitted to enter
any trust zone, enabling the network operators to remotely access and maintain the
network and the end user devices connecting to the network.
NOTE: This design requires a workaround on SRX Series to enable proper

routing due to the use of GRE over IPsec tunneling. In this case, the IPsec
tunnel must be configured in the untrust security zone. Normally, without
GRE tunneling, this would require the administrator to leak all internal
(private) addressing from the untrust to the trust vr. This is required because
IPsec is not aware of VRF configuration. Because GRE is used, this is no longer
a requirement, though a workaround is still required to properly configure
this environment. In order to fully support the GRE over IPsec configuration,
the private GRE tunnel endpoint route must be leaked from the untrust to
the trust security zone to allow for IGP/BGP peering over the GRE tunnel.
As in the other transport options, the routing protocols are configured to
authenticate with the hub router using an MD5 hash. This ensures that only
authorized routers are permitted to form routing adjacencies with the WAN
aggregation routers.
Internet Gateway Design

The next tier of the enterprise WAN solution is the Internet gateway. The Internet gateway
is a central peering point that connects the enterprise to the Internet. This tier of the
design resides parallel to the WAN aggregation router. As discussed in the WAN
aggregation overview, the Internet edge is configured as a separate physical router (on
Aggregation Hub 1) or as a separate virtual router (in the virtualized Aggregation Hub 2).
The Internet gateway serves the following roles for the enterprise:
Provide outbound Internet access to all enterprise users.
Provide transit for the secure overlay (GRE over IPsec) transport option
Provide inbound access to enterprise services (hosted services, www, e-mail, etc.).
Internet Edge Transport

The Internet gateway is located at the aggregation hubs (Figure 33 on page 67). The
gateway is the boundary between the enterprise network and the public Internet. Because
we are using a hub-and-spoke architecture, internal users located at remote branches
access the Internet through the Internet gateway. Internal traffic from the enterprise to
the Internet can include access to corporate data, applications, or other resources that
reside in the public cloud. In addition, remote branches can use the Internet as the
transport to connect them to the aggregation hubs to access hosted services or resources
at the data center. External customers or partners can access services at the aggregation
hubs from the Internet.
66
Figure 33: The Internet Gateway Role at the WAN Aggregation Site
This solution was tested with two Internet gateways that peer with two separate ISPs.
The Internet gateway on Aggregation Hub 1 is the primary gateway, and the Internet on
Aggregation Hub 2 is the secondary gateway. At Hub 1, the Internet gateway is a separate
physical router. It is directly connected to the VPN termination router over a 1 GE link that
is configured with two VLANs. One VLAN is used to terminate IPsec tunnels on the VPN
termination router. The second VLAN is used for traffic to and from hosted services.
The Internet gateway at Hub 1 has a virtual router routing instance called
SFW-NAT-SERVICES. This routing instance is an internal virtual router that faces the
private enterprise network, and is configured with private addresses. It is used to apply
NAT and stateful firewall to branch and data center traffic going to and from the Internet.
At Hub 2 there is one physical router for all rolesInternet gateway, WAN aggregation,
and VPN termination. The Internet edge role includes two routing instances: IEDGE and
SFW-NAT-SERVICES.
Internet Gateway Routing Design

The Internet gateways peer with the ISPs and control traffic between the Internet and
hosted services or the data center at the aggregation hubs. Employees at remote branches
can initiate connectivity to the data center over the Internet. Because we are using a
hub-and-spoke topology, all Internet traffic from remote branches is routed through the
Internet gateway. In addition customers or partners often use the Internet gateway to
access services at the corporate site.
In the Internet gateway architecture each gateway is an EBGP peer with the ISP. The two
Internet gateways are in the same AS boundary. The two Internet gateways are IBGP
67
peers, and routing policies are used to cause routes through the primary Internet gateway
to be preferred over routes to the secondary gateway. In addition, we recommend the
use of routing policy to export routes from the primary to secondary gateway so that in
the event of a failure, the secondary gateway has the current block of addresses that are
being advertised on the Internet edge.
Figure 34 on page 68 shows the routing design on the Internet gateways.
Figure 34: Routing Design at the Internet Gateway
The Internet gateways are EBGP peers with ISP A and ISP B. EBGP policies are designed
as follows:
68
Routes to Internet gateway 1 are preferred over routes to Internet gateway 2. Routes
to Internet gateway 1 are assigned a local preference of 200 to make them preferred
over routes to Internet gateway 2, which uses the default local preference of 100. In
addition, Internet gateway 2 uses AS path prepending. The longer AS path makes
routes to Internet gateway 1 preferred.
Martian routes received from the Internet are blocked. (Martian addresses are host or
network addresses about which all routing information is ignored. When received by
the routing device, these routes are ignored. They commonly are sent by improperly
configured systems on the network and have destination addresses that are obviously
invalid.)
Block of addresses used for source and destination NAT are advertised to the Internet.
On Hub 1, policies block Hub 2 addresses from being advertised on the Internet.
On Hub 2, policies block Hub 1 addresses from being advertised on the Internet.
For Internet access the default route is advertised in BGP and redistributed into OSPF
(for Data Center and OSPF only branches) as primary on Internet gateway 1 and using a
qualified next hop default route on head-end 2 is assigned a higher cost so it is only used
in the event of Internet edge router or WAN aggregation router failure in head-end 1.
With reference to the network ranges used for source NAT (internal accessing the
Internet), destination NAT (hosted services) and IPsec connectivity for the remote sites.
1.
Both Internet edge routers advertise the SAME external address pool used for source
NAT (internal clients accessing the Internet) to the Internet Peering routers. Head-end
2 prepends the route advertisement so it is not the primary router for the site. Given
this, with no failure traffic is routed to Aggregation Hub 1 for traffic in the shared NAT
range (clients that have been NATed accessing the Internet). In a failure of the ISP
link at head-end 1, traffic is now sent to head end 2 from the Internet, but as head-end
2 is also IBGP peering with head-end 1 the NAT pool is still being advertised from
head-end 1. Thus traffic is send across the IBGP (front-side) link and then sent through
the SFW/NAT service set on head-end 1. This brings up two further discussion points:
a. The failover was designed as such because there is NO state sync between the
two Aggregation service cards thus, in this design we chose to keep the SFW-NAT
service active on head-end 1 even if the ISP link fails. For clients accessing the
Internet, internally they see no change. Obviously for Internet branches they will
now be terminated on head-end 2 as the ISP link is now down.
b. Given this failover design requirement a separate VR is required for SFW/NAT
services as when a service set is configured for the shared NAT pool, Junos OS
automatically installs a static route for the NAT pool with a cost of 1. There is no
way to override this, so the NAT service set was configured in the
SFW-NAT-SERVICES VR, thus allowing the use of BGP to control the networks
that are active for the shared NAT subnet/pool. Without this, in the failover scenario
mentioned above, the traffic arriving on head-end 2 would not be send to head-end
1 and would simply be sent through the local service set.
2. The subnet addressing used for IPsec termination and hosted NAT services comes
from a separate subnet, advertised only from the local gateway and blocked from
being advertised from the peer. This means remote sites go directly to the appropriate
gateway for IPsec tunnel termination and on any ISP link failure tear down the tunnel
and use the already-up back up tunnel. Likewise the hosted NAT services in this local
gateway are no longer reachable and will be accessed via the other gateway. These
hosted services can be either on a single device, at a single location or hosted in
separate data centers using separate servers. In this design we have chosen the option
where the secondary site hosts a separate DMZ and different servers. In this case
application failover for Internet clients would be managed by a global DNS service.
Internet Gateway High Availability

Because enterprises use the Internet gateway for crucial business operations, high
availability on the Internet gateway is configured to provide always-on access to the
69
enterprise. This is the reason for configuring two separate Internet gateway routers that
peer to separate ISPs. This prevents a failure of one ISP from affecting the availability of
Internet access. It is important to note that local failure caused by power loss or weather,
for instance, can cause an entire site to experience outage. In many cases, the enterprise
often introduces geographic redundancy to the design, placing the primary gateway in
collocation with the Internet service provider and the backup in a different site. This
prevents a local failure from causing a complete outage. Additional protections to ensure
a highly available environment include:
Hardware redundancyThe introduction of redundant physical components such as

Routing Engines, Switch Control Boards (SCBs), power supplies, cooling, and backup
links between each routing component (Using link aggregation)
Software redundancyCertain redundancy mechanisms such as ISSU, GRES, and NSR

must be configured to fully take advantage of redundant hardware components, most
notably the presence of redundant Routing Engines.
Link-level redundancyRedundancy protocols should be utilized to ensure that failure

is detected quickly and that convergence to a backup service happens as soon as the
failure is identified.
BFD should be deployed wherever a routing protocol is used to ensure that any link
failure is identified and acted on as soon as possible. BFD can identify a link-level
failure in as little as 30ms.
VRRP should be deployed wherever there are redundant routers in place. This is in
use on the site type with dual CPE.
Class of Service on the Internet Gateway at Aggregation Hub 1

One might ask why we have class of service on the Internet gateway the reason is we
share the Internet gateway bandwidth for hosted service, Internet access from Internal
clients and Branch IPsec tunneled traffic.
There are three forwarding classes for traffic at the Internet edge:
Branch Traffic associated with Internet-connected branches. This traffic is assigned

70 percent of the transmit rate with a high scheduling priority.
Internet Traffic for the public Internet. This traffic is assigned the remainder of the
transmit rate with a low scheduling priority.
Network Control Network control traffic, which is assigned 4 percent of the transmit
rate and a strict-high scheduling priority.
CoS is applied at the Internet gateways as follows:
70
A scheduler with all three forwarding classes is applied to the interface to the ISP. This
traffic is shaped at the rate of 800m.
The Branch forwarding class is applied to the VLAN that is used to terminate IPsec
tunnels on the VPN termination router.
The Internet forwarding class is applied to the VLAN that is used for hosted services
traffic that is sent to the VPN termination router.
The Internet forwarding class is applied to the services interface that is used all Internal
traffic sent to the Internet.
Class of Service on the Internet Gateway at Aggregation Hub 2

There are three forwarding classes for traffic at the Internet edge:
Branch Traffic associated with Internet-connected branches. This traffic is assigned

79 percent of the transmit rate with a high scheduling priority.
Best effort Traffic for the public Internet. This traffic is assigned the 20 percent of
the transmit rate with a low scheduling priority.
Network Control Network control traffic, which is assigned 1 percent of the transmit
rate and a strict-high scheduling priority.
CoS is applied at the Internet gateways as follows:
A scheduler with all three forwarding classes is applied to the interface to the ISP. This
traffic is shaped at the rate of 800m.
The branch forwarding class is applied to the VLAN that is used to terminate IPsec
tunnels on the VPN termination router.
The Internet forwarding class is applied to the VLAN that is used for hosted services
traffic that is sent to the VPN termination router.
The Internet forwarding class is applied to the services interface that is used all Internal
traffic sent to the Internet.
Internet Gateway Security

Security at the Internet gateway is critical: this is the point in the network where the entire
enterprise is exposed to the Internet and its many threats. Security measures taken at
the Internet gateway include Routing Engine protection, Network Address Translation
(NAT) and stateful firewalling, routing protocol authentication, and blocking of Martian
routes received from the Internet.
Routing protocol authenticationBGP groups that peer with the ISP and the OSPF
backbone on the aggregation hubs are configured for MD5 authentication.
Routing Engine protectionBecause loopback interfaces are a link to the Routing

Engine, we recommend the use of firewall filters to control traffic to and from loopback
interfaces on the Internet gateway. These filters apply only to traffic destined for the
router control plane. The filters do not apply to user traffic. The filters used for Routing
Engine protection consist of:
Prefix lists that specify trusted IP subnets and address for different types of traffic.
Traffic received from these address are allowed through the firewall. All other traffic
is discarded.
A policy that applies rate limits to the traffic that is accepted by the filter.
71
Packet counting and logging. We are counting packets received from different sources,
and in some cases logging traffic. You can use counters and logs to check that a
filter is working as expected and to detect unusual amounts of certain types of traffic.
NAT and stateful firewalls on the Internet gateway
The Internet gateway utilizes source and destination NAT. We are using stateful
firewalls with application-layer gateways (ALGs) to ensure only return traffic sourced
from the enterprise is allowed inbound through the firewall.
Internet Gateway Traffic Flow

The following section provides a high level overview of the various traffic flows to and
through the Internet gateway. The scenarios cover traffic flow, stateful firewalling, NAT,
and site-to-site transport for both the primary and backup aggregation hubs.
Figure 35 on page 72 shows how NAT and stateful firewall are applied to inbound traffic
from the Internet going to hosted services on Aggregation Hub 1.
Figure 35: NAT and Firewall Applied to Internet Gateway Traffic
Traffic sourced from an enterprise remote site and destined for a hosted service flows
in the following way:
1.
Traffic from the Internet has a destination address of 191.15.100.128/25, which is the
public address that is advertised to the Internet for hosted services.
2. NAT and stateful firewall are applied to traffic. An address from the private pool of
172.31.254.48/28 addresses for hosted services is assigned.

3. A static route is used to forward traffic to the HOSTED-WWW-NAT routing instance,
which sends the traffic to hosted services.

Figure 36 on page 73 shows the return traffic flow for traffic between hosted services
and public hosts:
72
Figure 36: Return Traffic Flow from Hosted Services to the Internet
1.
A static route sends traffic to the Ethernet interface on the Internet gateway.
2. The Ethernet interface receives the traffic and forwards it to the Ethernet interface
connected to the ISP.

3. Traffic is forwarded to the Internet.
Figure 37 on page 73 shows how NAT and stateful firewall are applied to inbound traffic
from the Internet going to hosted services on Aggregation Hub 2.
Figure 37: Aggregation Hub 2 Traffic Flow for Stateful Firewall and NAT
1.
Traffic from the Internet has a destination address of 191.15.200.128/25, which is the
public address that is advertised to the Internet for hosted services.
2. A static route is used to forward traffic to the SFW-NAT-SERVICES routing instance.

3. NAT and stateful firewall are applied to traffic. An address from the private pool of
172.31.255.48/28 addresses for hosted services is assigned.

4. A static route is used to forward traffic to the HOSTED-WWW-NAT routing instance,
which sends the traffic to hosted services.

Figure 38 on page 74 shows the return traffic flow from hosted services to the Internet
on Hub 2
73
Figure 38: Return Traffic Flow on Aggregation Hub 2
1.
Traffic is forwarded to SFW-NAT-SERVICES using a static route.
2. Traffic is forwarded to IEDGE using a static route

3. Traffic is forwarded to the Internet.
Figure 39 on page 74 shows the inbound traffic flow from the data center, leased line
transports, or Layer VPN transports to hosted services.
Figure 39: Traffic Flow Inbound from Data Center, Leased-Line, or Layer
3 VPN to Hosted Services
1.
Receive traffic from the data center, leased line transports, or Layer 3 VPN transports
to hosted services on the WAN aggregation router, and forward the traffic to the
WAN-GRE routing instance on the VPN termination router.
2. Send traffic to sp-0/3/0.4001 using a static route in the WAN-GRE routing.
74
3. Apply the NAT-Branch-www next-hop style service set. Assign an inside address from
the NAT pool of 172.31.254.80/28 addresses.

4. Forward traffic to the next hop of sp-0/3/0.4002 in HOSTED-WWW-NAT, and is then
forwarded to hosted services.

Figure 40 on page 75 shows the outbound traffic flow from the data center, leased line
transports, or Layer VPN transports to hosted services.
Figure 40: Return Traffic Flow from Hosted Services to Leased-Line, Layer
3 VPN, and Data Center.
Figure 41 on page 75 shows the inbound flow for traffic from Internet-connected branches
that use IPsec over GRE tunnels to hosted services.
Figure 41: Traffic Flow from Internet Connected Branches (GRE over IPsec)
to Hosted Services
75
1.
Terminate IPsec tunnels.
2. Terminate GRE tunnels.

3. Apply the NAT-Branch-www next-hop style service set on inside service interface
sp-3/0/0.4001. Traffic is assigned an inside address from the NAT pool of

172.31.254.80/28 addresses.
4. Forward traffic to the next hop of sp-0/3/0.4002 in HOSTED-WWW-NAT, and then
forward to hosted services.

Figure 42 on page 76 shows the outbound flow for traffic from Internet-connected
branches to hosted services.
Figure 42: Outbound Traffic Flow from Hosted Services to

Internet-Connected Branch Sites (GRE over IPsec)
1.
Use a static route to send traffic to the sp-0/3/0.4001 in the WAN-GRE routing
instance.
2. Form a GRE tunnel to the branch, and forward traffic to the VPN routing instance.
3. Form an IPsec tunnel over the GRE tunnel, and forward traffic to the Internet gateway.
4. The Internet gateway forwards the tunnel traffic to the branch.
Figure 43 on page 77 shows traffic from Internet-connected branches (GRE over IPsec)
and the various traffic flows between the branch and the data center, Internet, and Layer
3 VPN / leased line branches:
76
Figure 43: The Flow of Traffic Between Internet-Connected Branches and

the Other Enterprise Entities
Solution Failover Scenarios

This is a combined failover scenario overview that incorporates failure of not only the
Internet gateway, but the following failure scenarios as well:
Primary Internet link
A complete head-end (hub) site
Primary Internet gateway
Primary VPN router
Primary WAN aggregation router
The overall goal of the design is to ensure that the primary aggregation hub is always
primary, even when components within that hub fail. A failure at the primary hub does
not necessarily mean that all traffic fails over to the backup aggregation hub (Aggregation
Hub 2). As a general rule, the design fails over only affected services to the backup
aggregation hub.
77
Failure of Primary Internet Link

The first failure scenario involves the failure of the primary Internet link (at the primary
aggregation hub). There is a direct connection between the primary and backup Internet
gateway routers to enable traffic flow between these devices. The WAN aggregation
routers also have a direct interconnect. The only routers with no direct peering are the
physical routers or VRs in the VPN termination role: traffic between these devices flows
over the WAN aggregation or Internet gateway router interconnects. In this design, there
is a primary Internet link connected to the primary Internet gateway router; a secondary
ISP uplink is connected to the secondary Internet gateway. The routing to the ISP is
configured to always favor the primary ISP. The route peering with the ISP at both Internet
gateways is EBGP: the design uses AS path prepend and/or Multi-exit discriminator
(MED) attributes to influence return path (to ensure asynchronous routing conditions
are avoided). The failover of traffic in the event of primary Internet link failure is shown
in Figure 44 on page 78.
Figure 44: Primary ISP Failover Scenario
1.
78
In this scenario, the primary Internet link fails. The cause of failure is not relevant as
the solution will react the same to all failure resulting in loss of route peering with the
primary ISP).
a. The SFW/NAT service on the Internet gateway router (hub 1) is still active (this
failure is the uplink only). As such, all sessions currently existing over the primary
link are still active in the firewall state tables. In order to avoid resetting existing
sessions, the traffic is still routed to this VR for stateful firewall processing. Traffic
then flows across the direct link between Aggregation Hub 1 and Aggregation Hub
2.
2. Traffic is routed upon failover in the following manner:
a. Traffic from Internet branches enter over the secondary GRE over IPsec tunnel
(which terminates on the VPN VR and WAN-GRE VR). Traffic is then sent to the
WAN aggregation VR ( on Aggregation Hub 2), over the link to the primary WAN
aggregation hub, and into the SFW-NAT-SERVICES VR for firewall/NAT services.
Internet-bound traffic is then sent over the link to the backup Internet gateway for
transmission to the Internet.
b. Traffic from Layer 3 VPN and leased line transports (recall that these enter on the
WAN aggregation router) is routed over the WAN aggregation to Internet gateway
link. The traffic has stateful firewall services and NAT on the SFW-NAT-SERVICES
VR at the primary Internet gateway. Traffic is then sent over the Internet gateway
link to the backup aggregation hub and is sent out the backup Internet gateway.
3. All traffic is then routed over the direct connection between the primary Internet
gateway and the secondary gateway (to the SFW-NAT-SERVICES VR where firewall
and NAT services are performed).
4. Traffic is forwarded to backup ISP connection. Return traffic follows the same path,
entering the secondary gateway, over interconnect to primary Internet gateway,

through SFW/NAT, and back to the branches and data center.
Primary Internet Gateway Failure

In this failover scenario, the ISP link at the primary hub is still active, but the primary
Internet gateway has experienced a failure. In this case, SFW/NAT services are not
available on the primary Internet gateway: this results in a loss of all existing state
information. The solution does not support state synchronization between stateful
firewalls at the primary and backup hub sites. This results in a loss of session state
information when the primary Internet gateway experiences failure. Because this is a
total loss scenario, attention should be given to providing hardware and software resiliency
on the primary Internet gateway (redundant Routing Engines, cooling, power as well as
the use of ISSU and GRES). This failover scenario is illustrated in Figure 45 on page 80.
79
Figure 45: Failure of Primary Internet Gateway
1.
In this scenario, the primary Internet gateway has experienced failure. The cause of
failure is not relevant as the solution will react the same to all failure resulting in loss
of route peering with the primary Internet gateway.
2. The SFW/NAT service on the Internet gateway (hub 1) is no longer active. As such, all
sessions currently existing over the primary link will be lost. Routing protocol peering
from the primary Internet gateway is lost, causing the network to converge, routing
traffic to the backup path.
3. Traffic from remote sites and the data center is routed in the following manner:
a. Traffic from secure overlay branches enters the secondary GRE over IPsec tunnel
and is routed to the backup WAN aggregation router. Traffic bound for the Internet
is routed to the SFW-NAT-SERVICES VR for firewall and NAT and is then forwarded
to the ISP. Traffic destined for remote sites (Layer 3 VPN and leased line) is sent
over the link to the primary WAN aggregation router and is forwarded to the remote
sites via their primary connections.
b. Traffic from Layer 3 VPN and leased line transports is routed from the WAN
aggregation router at hub 1, over the link to Aggregation Hub 2, to the
SFW-NAT-SERVICES VR for firewall and NAT. Internet traffic is then forwarded
to the ISP. Traffic bound for Internet-connected remote sites is sent from the
backup WAN aggregation router to the WAN-GRE VR for encapsulation (WAN-GRE
80
+ VPN VR for GRE + IPsec encapsulation before forwarding to IPsec endpoint at

remote branch).
4. All traffic has SFW/NAT applied by the backup Internet gateway (by the
SFW-NAT-SERVICES VR).
5. Traffic is forwarded to backup ISP connection. Return traffic follows the same path
(in secondary gateway, to the WAN aggregation router at hub 2, to WAN aggregation
at hub 1, then back to the branch or data center.
Primary VPN Router Failure

Figure 46: Failure of Primary VPN Router
1.
Upon site connection to the enterprise WAN, the secure overlay remote site (GRE over
IPsec) initiates two tunnels. The primary tunnel is terminated at the primary
aggregation hub. A backup tunnel is also initiated and terminated on the aggregation
hub at the backup site (Aggregation Hub 2). Routing is configured to always favor the
primary link and use the backup link only in cases where the primary fails. Failure of
the primary Internet gateway occurs in this scenario as shown in Figure 46 on page 81.
2. Route peering is lost on the primary GRE tunnel and converges on the backup GRE
tunnel. All remote site to enterprise traffic now flows over the backup GRE tunnel
(encapsulated within IPsec, of course). The secure overlay tunnels are terminated at
the backup hub site (IPsec terminates on the VPN VR, while GRE terminates on an lt
81
interface on the WAN-GRE VR). Traffic is then sent to the WAN aggregation VR, across
the link to the primary hub site (WAN aggregation 1), and is then forwarded on to its
destination. .
a. Traffic destined for Layer 3 VPN and leased line remote sites is routed to the
appropriate site by the primary WAN aggregation router. Traffic from these sites
destined to the Internet connected branches follows the reverse path (WAN Agg
1 > WAN Agg 2 > VPN VR > remote site via IPsec tunnel).
b. Internet traffic is forwarded from the primary WAN aggregation router to the
SFW-NAT-SERVICES VR on the primary WAN aggregation router. Traffic is then
forwarded to the ISP.
Please note that the solution is designed to always forward traffic via Aggregation Hub
1 (the primary hub) and only forward failover traffic via the backup aggregation hub.
Primary WAN Aggregation Router Failure

This failure scenario involves the failure of the primary WAN aggregation router (at hub
1). All Layer 3 VPN and leased line transports terminate on this router. Failure of this router
could result in total loss (in cases where a remote site has only a single leased line
configured to the aggregation hub, or a single Layer 3 VPN path for some reason).
Additionally a script is used to monitor the availability of this router or routing instance
and if it fails the VPN router brings down all GRE tunnels in the affected head-end, thus
forcing remote Internet branches to use the GRE+IPsec tunnel to the unaffected head-end.
Because this router is a key to the entire hub design, we recommend evaluating
comprehensive high availability on this node (the primary WAN aggregation router).
Complete high availability includes hardware redundancy (redundant Routing Engines,
cooling, power) as well as the use of software redundancy (ISSU, GRES, and NSR). The
flow of traffic when the primary WAN aggregation router experiences failure is shown in
82
Figure 47: Primary WAN Aggregation Router Failure
1.
Both leased line and Layer 3 VPN transport remote sites terminate and peer with the
primary WAN aggregation router at hub 1. In the event that this router experiences
failure, the following backup routing occurs.
2. In a case where the primary WAN aggregation router fails, traffic is re-routed over a
backup connection (for Layer 3 VPN sites, this connection is often a backup Layer 3
VPN service to the backup aggregation site).
3. Remote sites without a backup Layer 3 VPN connection (leased line sites, for instance),
a backup IPsec VPN connection can be configured. This failover flow is also used for
Internet connected branches (the primary WAN aggregation router is the primary
route reflector in the design; if the primary fails, all routing to Internet-connected sites
will converge to the backup WAN aggregation router). The traffic from these
Internet-connected sites flows over the backup tunnel (terminated on the VPN VR
and WAN-GRE VR on the backup aggregation hub) and are forwarded to the backup
WAN aggregation VR. Traffic bound for Layer 3 VPN and leased-line sites is forwarded
over the routed connections to the remote site (from the backup WAN aggregation
VR).
4. All Internet-bound traffic will flow from the backup aggregation hub over the link to
the primary Internet gateway (flowing first through the SFW-NAT-SERVICES VR for
firewall and NAT services).
83
Primary WAN Aggregation Site Failure

This scenario involves a complete failure of the primary aggregation hub. This type of
failure is most often associated with some sort of local event (weather, natural disaster,
long-term power outage) that causes all transports and routers to fail at the primary
site. No level of local hardware or software redundancy can prevent this type of outage.
Because of this, we recommend that the primary and backup aggregation hubs be
geographically disperse in such a way as to avoid local events causing failures of both
hubs. There is no exact number of miles to factor into this planning, though if the primary
data center is in the Northeast (New York City, for instance), it is recommended to put
the backup aggregation hub in an area that does not typically experience adjacent weather
events (this could be on the West Coast, in the Midwest, or anywhere else where seasonal
and disaster-type weather is not likely to affect both hubs). The design takes into account
a geographically dispersed primary and secondary hub. The secondary hub can be done
(as it is in this solution guide) as a single router with multiple virtual routers operating in
the same way as the physical router design. The footprint of this backup site (in rack
space, power, cooling, etc.) will most likely be far lower, enabling an inexpensive yet
scalable backup aggregation hub. The flow of traffic in this failure scenario is shown in
Figure 48: Primary WAN Aggregation Site (Complete Site) Failure Scenario
84
1.
The primary aggregation hub fails in this scenario. This means a complete failure, or
a majority of the routers and transports are down. In this scenario, all routing will occur
through Aggregation Hub 2.
2. The various site types re-route as per their local routing design (this has been largely
covered in the previous failover scenarios. The exception is that no traffic is routed
back to the primary aggregation hub (because that entire site is down).
a. Secure overlay sites route traffic over the backup GRE over IPsec tunnel to the
secondary hub. Traffic terminates as in the primary VPN router failure scenario and
routes from Aggregation Hub 2 to its destination (Internet, data center, or other
enterprise sites).
b. Layer 3 VPN and leased line sites fail over as shown in the primary WAN aggregation
failover scenario. Layer 3 VPN converges over the backup MPLS label-switched
path (LSP) and terminates on the WAN aggregation VR at the backup aggregation
hub. All traffic routes locally from Aggregation Hub 2. leased line sites that have
secure overlay backup can have a backup GRE over IPsec tunnel to the secondary
site: in this case, the traffic routes over the backup tunnel to the backup aggregation
hub.
c. Traffic to and from the data center (hosted traffic or enterprise-internal traffic)
routes over backup link or links to Aggregation Hub 2. Traffic routes to its destination
from Aggregation Hub 2.
d. Internet traffic from the data center or enterprise sites routes from Aggregation
Hub 2, through the SFW/NAT service, and out to the backup ISP. Inbound traffic
(hosted service-bound traffic, for instance) will flow inbound, through stateful
firewall rules, destination NAT, and on to its destination. Complete use of this
failover scenario for hosted service requires a domain name service that can do
global load balancing (GSLB), discover a failure of the primary service (primary
Internet circuit or site), and advertise new host records (A, MX, PTR) for all hosted
services.
This section by no means covers every possible failure in the enterprise WAN solution.
The goal of this section was to provide a set of high-level failover scenarios that include
enough information for a reader to determine probable failover scenario routing and
convergence that fall outside these examples.
Services
The final component of the enterprise WAN solution is the inclusion of services. The
solution architecture is designed to accept most any enterprise service as a hosted service,
or in-line with the network at the WAN aggregation tier. The service tested as part of this
version of the solution is the Web Cache Communication Protocol (WCCP). The WCCP
service delivers transparent application acceleration by dynamically forwarding relevant
traffic to one or more off-path cache instances and has built-in load balancing and scaling
mechanisms. It is designed to operate with Web cache products that support the WCCP
protocol. http://tools.ietf.org/id/draft-wilson-wrec-wccp-v2-01.txt
85
The WCCP service is offered in two forms:
WCCPThe complete WCCP service offers full functionality that can be used on M
Series and MX Series platforms that have Multiservices PICs (MS-PICs), MS-MICs or
MS-DPCs.
WCCP-LiteThis version offers a subset of WCCP functionality. This service can be

deployed on SRX Series, M Series, and MX Series platforms without the need for
MS-PICs.
Table 6 on page 86 shows a comparison of the features of WCCP and WCCP-Lite
Table 6: Feature Support Comparison for WCCP & WCCP-Lite

Feature
WCCP
WCCP-Lite
Support for WCCPv2
Yes
Yes
GRE encapsulation for traffic forwarding
Yes
No
Layer 2-rewrite for traffic forwarding
Yes
Yes
GRE encapsulation for return traffic
Yes
No
Layer 2-rewrite for return traffic
Yes
Yes
Well-defined service support (service ID = 0, web caching)
Yes
Yes
Dynamic services
Yes
Yes
Hash assignment method
Yes
Yes
Mask assignment method
Yes
Yes
Support for multiple service groups
Yes
No
Support for multiple caches per service group
Yes
No
MD5 security for control messages
Yes
Yes
Supported platforms
Platforms that fully support

the Junos OS SDK including the
MS-SDK
SRX , M and MX models that

support the Junos OS SDK
86
PART 2
87
88
CHAPTER 3
Using the Validated Reference Designs

About the Validated Reference Designs
Juniper Networks validated reference designs are end-to-end deployment scenarios that
have been tested and validated. These designs are intended to provide a base that you
can readily adapt to meet your business needs and to reduce the qualification time for
new deployments.
These designs have been tested for scaling and performance, including failover testing
where we have provided failover convergence times.
Each design scenario includes step-by-step procedures and extensive validation
information that you can use to validate your configuration as you go. When your
implementation is complete, we include procedures that you can use to test reachability
throughout your network and test failover scenarios.
How to Use the Validated Reference Designs

The validated designs provide end-to-end scenarios for connecting different sized
branches over different types of transport with different routing protocols and high
availability. Validated reference designs are meant to serve as trusted examples to guide
the implementation of the solution. Please be aware of IP address conflicts and make
any changes to the addressing where it conflicts with existing public or private IP
addressing.
1.
Select the end-to-end branch scenario that you want to implement.
2. Implement and validate the base configurations at the aggregation hubs.

3. Implement and validate the end-to-end branch scenario.
4. Implement and validate WAN acceleration.
5. Implement and validate Routing Engine protection.
6. Implement the Network Management System.
For More Information About Statements and Commands

For more information about statements and commands used in the validated reference
designs, see the Junos OS CLI Explorer:
89
http://www.juniper.net/techpubs/content-applications/cli-explorer/junos/
Lab Testing Architecture

The enterprise WAN solution was tested and verified in the Juniper Networks Solutions
Labs. The end-to-end architecture is shown in Figure 49 on page 90:
Figure 49: The Enterprise WAN Solution Testing Lab Architecture
90
Chapter 3: Using the Validated Reference Designs
Table 7: Equipment Used in the Solution Validation Topology

Site Name
Hostname
Role
Juniper Networks
Product
Head Office 1
JBUS
Internet Gateway
MX480
JBIKE
VPN Termination
M7i
JBOAT
WAN aggregation
MX80
JLIMO-WAN
WAN aggregation
MX480
JLIMO-IEDGE
Internet Gateway
(Virtual Router-based
JLIMO-VPN
VPN Termination
Aggregation Hub Design)
Branch 1
HUMBER-LL
Small Branch: Leased-Line
MX80
Branch 2
PIXO
Small Branch: Dual Homed
SRX240
Head Office 2
Internet (GRE over IPsec)

Branch 3
SEDAN
Medium Branch:
M7i
Layer 3 VPN + Internet (GRE over IPsec)

Branch 4
MANZA
Large Branch: Backup to Internet (GRE over

IPsec)
HUMBER
M7i
MX80
Large Branch:Primary to Layer 3 VPN

Branch 5
SPITFIRE
Large Branch: Primary to Layer 3 VPN
MX80
SPITFIRE-BR2
Large Branch: Backup to Layer 3 VPN
MX80
91
92
CHAPTER 4
Base Configuration for Aggregation Hub 1

Requirements
This example uses the following hardware and software components:
VPN termination routerM7i Multiservice Edge Router with the following PICs:
Two 4-Port Gigabit Ethernet Enhanced IQ2 (IQ2E) PICs with SFP
One Channelized OC3/STM1 Enhanced IQ (IQE) PIC with SFP
One MultiServices 100 PIC
One Tunnel Services PIC
2-Port 100Base-TX Fast Ethernet PIC
WAN aggregation routerMX80 3D Universal Edge Router
Has dual Routing Engines
Junos OS Release 12.3R3
Overview
Topology
This section focuses on the configuration of the nodes in the blue highlighted area
(Figure 50 on page 94).
93
Figure 50: Aggregation Hub 1 Test Topology
Figure 51: Interface and VR Configuration at Aggregation Hub 1
94
Chapter 4: Base Configuration for Aggregation Hub 1
NOTE: There is an alternate configuration that employs an MX80 as the VPN

termination router. Configuration for that option is here: Appendix A:
Alternate Configuration Aggregation and Branch using MX80 with Services
MIC on page 737
Configuring the WAN Aggregation Router at Aggregation Hub 1
Configuring the Router ID on the WAN Aggregation Router on page 95
Configuring Default Static Routes on the WAN Aggregation Router on page 95
Configuring Transport on the WAN Aggregation Router on page 95
Configuring Routing Policies for IBGP Peers on the WAN Aggregation Router on page 97
Configuring Fully-Meshed IBGP Peer Groups on the WAN Aggregation Router on page 98
Configuring the OSPF Backbone on the WAN Aggregation Router on page 100
Configuring Multicast on the WAN Aggregation Router on page 103
Configuring CoS on the WAN Aggregation Router on page 109
Configuring Per-Packet Load Balancing on the WAN Aggregation Router on page 115
Configuring the Router ID on the WAN Aggregation Router

Step-by-Step
Procedure
1.
Configure the router ID.

[edit]
edit routing-options
set router-id 172.31.255.2
Configuring Default Static Routes on the WAN Aggregation Router

Step-by-Step
Procedure
1.
Create a default static route for IPv4 with the next hop to the WAN aggregation role
at Aggregation Hub 2.
It is used to increase the convergence time in case of a failure at Hub 1.
[edit]
set static route 0.0.0.0/0 next-hop 172.31.254.42
set static route 0.0.0.0/0 preference 250
2.
Create a default static route for IPv6.

[edit]
set rib inet6.0 static route ::/0 reject
Configuring Transport on the WAN Aggregation Router

Step-by-Step
Procedure
1.
Configure the Ethernet interface to the VPN termination router.

Configure the interface to include the Layer 2 overhead size for both ingress and
egress interfaces. Both the transit and total statistical information is computed and
displayed for each logical interface with the show interfaces command under
theIngress account overhead andEgress account overhead fields.
95
[edit]
edit interfaces ge-1/2/2
set description "--- To VPN router WAN-GRE VR ---"
set unit 0 account-layer2-overhead ingress 18
set unit 0 account-layer2-overhead egress 18
set unit 0 family inet mtu 1500
set unit 0 family inet address 172.31.254.13/30
set unit 0 family inet6 address 2001:DB8:254:4::1/6
NOTE: This solution employs various Juniper Networks routing and

security platforms at the aggregation hubs and remote sites. Some
platforms have a slight difference in the way traffic is counted due to
the difference in how each platform accounts for Layer 2 overhead. More
information on the accounting of Layer 2 overhead in interface statistics
can be found here: Juniper Networks Technical Publications.
accounting statistics. More information on the calculation and
modification of egress shaping overhead in class of service can be found
here: Juniper Networks Knowledge Base.
2.
Configure the Ethernet interface to the WAN aggregation router in Aggregation Hub
2.
[edit]
set description "--- B2B link towards WAN-AGG2 VR instance ---"
3.
Configure the interface to the Data Center.

[edit]
edit interfaces xe-0/0/2
set interfaces xe-0/0/2 description "--- To DC-ACCESS router ---"
set interfaces xe-0/0/2 unit 0 account-layer2-overhead ingress 18
set interfaces xe-0/0/2 unit 0 account-layer2-overhead egress 18
set interfaces xe-0/0/2 unit 0 family inet mtu 1500
set interfaces xe-0/0/2 unit 0 family inet address 172.31.241.2/24
set interfaces xe-0/0/2 unit 0 family inet6 address 2001:DB8:241::2/64
4.
Configure the Ethernet interface to the Internet edge router in Aggregation Hub 1.
[edit]
set description "--- IEDGE1 link ---"
96
Configuring Routing Policies for IBGP Peers on the WAN Aggregation Router
Step-by-Step
Procedure
Figure 52: BGP Design at Aggregation Hubs
1.
Configure a policy that is used to advertise default static IPv4 routes. It is a next-hop
self policy, which causes the loopback address of the router to be advertised of the
next-hop address.
[edit]
edit policy-options policy-statement ADV_DEFAULT
set term 1 from family inet
set term 1 from protocol static
set term 1 from route-filter 0.0.0.0/0 exact
set term 1 then next-hop self
set term 1 then accept
2.
Configure a next-hop self policy for IPv4 traffic, which causes the loopback address
of the router to be advertised as the next-hop for BGP traffic.
[edit]
edit policy-options policy-statement NHS
set term 1 from protocol bgp
3.
Configure a next-hop self policy, which causes the loopback address of the router
to be advertised as the next-hop address for BGP traffic.
[edit]
edit policy-options policy-statement NHS6
97

Configuring Fully-Meshed IBGP Peer Groups on the WAN Aggregation Router

Step-by-Step
Procedure
At the aggregation hubs, we have a full IBGP mesh with the WAN aggregation routers
and the WAN-GRE virtual routers on Aggregation Hub 1 and Aggregation Hub 2.
1.
Configure the AS number for BGP.

[edit]
set autonomous-system 65530
2.
Configure an IPv4 BGP peer group with three neighbors:
WAN-GRE routing instance on the VPN termination router at Hub 1 (172.31.255.2).
WAN aggregation role at Hub 2 (172.31.255.3).
WAN-GRE routing instance on the VPN termination role at Hub 2 (172.31.255.6).
The NHS export policy causes the router to advertise the address of the loopback
interface as the next hop.
The ADV_DEFAULT export policy causes the default static route to be advertised.
[edit]
edit protocols bgp group IBGP-MESH
set type internal
set local-address 172.31.255.2
set family inet unicast
set family inet multicast
set export NHS
set neighbor 172.31.255.3
set neighbor 172.31.255.5 export ADV_DEFAULT
set neighbor 172.31.255.5 export NHS
3.
WAN-GRE routing instance on the VPN termination router at Hub 1

(2001:DB8:255::2).
WAN aggregation role at Hub 2 (2001:DB8:255::3).
WAN-GRE routing instance on the VPN termination role at Hub 2

(2001:DB8:255::6).
[edit]
edit protocols bgp group IBGP-MESH-v6
set type internal
set local-address 2001:DB8:255::2
set family inet6 unicast
98
set export NHS6

set neighbor 2001:DB8:255::2
Results
Verify the IBGP mesh groups.

1.
Verify the IBGP-Mesh group.

user@hub1> bgp summary group IBGP-Mesh
Groups: 6 Peers: 4008 Down peers: 0
Table
Tot Paths Act Paths Suppressed
History Damp State
Pending
inet.0
26386
26384
0
0
0
0
inet6.0
25393
25393
0
0
0
0
Peer
AS
InPkt
OutPkt
OutQ
Flaps Last Up/Dwn
State|#Active/Received/Accepted/Damped...
172.31.255.3
65530
2007
3369
0
0
8:04:27
5000/5000/5000/0
0/0/0/0
172.31.255.5
65530
995
3235
0
0
8:02:26
1/1/1/0
0/0/0/0
172.31.255.6
65530
2508
3237
0
0
8:02:17
1000/1001/1001/0
0/0/0/0
2. Verify the IBGP-Mesh-V6 group.

user@hub1> bgp summary group IBGP-Mesh-v6
Table
History Damp State
Pending
inet.0
26386
26384
0
0
0
0
inet6.0
25393
25393
0
0
0
0
Peer
AS
InPkt
OutPkt
OutQ
Flaps Last Up/Dwn
2001:DB8:255::2
65530
2000
3029
0
0
8:05:53
Establ
inet6.0: 4000/4000/4000/0
2001:DB8:255::3
65530
997
2987
0
0
8:02:35
Establ
inet6.0: 1/1/1/0
2001:DB8:255::6
65530
2462
2986
0
0
8:02:27
Establ
inet6.0: 1000/1000/1000/0
99
Configuring the OSPF Backbone on the WAN Aggregation Router

Step-by-Step
Procedure
Figure 53: OSPF Design at Aggregation Hubs
1.
Configure routing policies that are used to export default BGP routes into OSPF.
These policies are used for leased line transport that uses OSPF. OSPF obtains its
default route from BGP.
a. Configure a policy for IPv4.
[edit]
edit policy-options policy-statement BGP2OSPF
set term 1 then metric 20
set term 1 then tag 100
set term 1 then external type 1
b. Configure a policy for IPv6.
[edit]
edit policy-options policy-statement BGP2OSPF-V6
set term 0 from family inet6
set term 0 from route-filter ::/0 exact
set term 0 then reject
100

2.
Configure OSPF for IPv4 traffic.

a. Set the preference for OSPF routes to 175.
A preference of 175 gives BGP routes, which have a default preference of 170,
preference in the routing table over OSPF routes.
[edit]
edit protocols ospf
set external-preference 175
b. Apply the policy to insert BGP routes into the OSPF routing table.
[edit]
edit protocols ospf
set export BGP2OSPF
c. Create a backbone area, and add the interface to the VPN termination router
(ge-1/2/2), the loopback interface (lo0.0), the interface to the WAN aggregation
router on Aggregation Hub 2 (ge-1/3/2), the interface to the data center
(xe-0/0/2), and the interface to the Internet edge router (xe-0/0/0).
[edit]
edit protocols ospf area 0.0.0.0
set interface ge-1/2/2.0 interface-type p2p
set interface ge-1/2/2.0 authentication md5 0 key
"$9$0MTR1ESvWXbsgikAuO1cSws2"
set interface ge-1/2/2.0 bfd-liveness-detection minimum-interval 500
set interface ge-1/2/2.0 bfd-liveness-detection multiplier 3
set interface lo0.0 passive
"$9$tRnY01ElKW-VsUj/Ap0REdVw"
set interface xe-0/0/2.0 interface-type p2p
set interface xe-0/0/2.0 metric 20
set interface xe-0/0/2.0 authentication md5 0 key
"$9$a0Gjk5Q3tuBlK2oJGHkpuO"
set interface xe-0/0/2.0 bfd-liveness-detection minimum-interval 500
set interface xe-0/0/2.0 bfd-liveness-detection multiplier 3
"$9$vaX8x-Ygaikm69rKM8N-Hk."
3.

a. A preference of 175 gives BGP routes, which have a default preference of 170,

[edit]
edit protocols ospf3
101
b. Apply the policy to insert BGP routes into the OSPF routing table.
[edit]
set export BGP2OSPF-V6
c. Create a backbone area for OSPFv3, and add the loopback interface, the interface
to the WAN aggregation router on Aggregation Hub 1, the interface to the data
center (xe-0/0/2), and the interface to the VPN termination router (ge-1/2/2).
Give the interface to the data center a priority of 200 to give it priority over other
routes because the xe interface is the highest bandwidth link.
[edit]
edit protocols ospf3 area 0.0.0.0
set interface lo0.0
set interface ge-1/3/2.0
set interface xe-0/0/2.0 priority 200
Results
Verify OSPF neighbors.

1.
Verify OSPF IPv4 neighbors.

user@hub1> show ospf neighbor
Address
Interface
172.31.254.14
ge-1/2/2.0
172.31.254.42
ge-1/3/2.0
172.31.254.9
xe-0/0/0.0
172.31.241.10
xe-0/0/2.0
172.16.5.2
t3-1/0/1:1.0
State
Full
Full
Full
Full
Full
ID
172.31.255.3
172.31.255.5
172.31.254.9
172.31.255.8
172.16.5.255
Pri
128
128
128
128
128
Dead
36
37
38
37
35
2. Verify the OSPF IPv6 neighbors.

user@hub1> show ospf3 neighbor
ID
Interface
State
172.31.255.3
ge-1/2/2.0
Full
Neighbor-address fe80::214:f6ff:fe76:d401
172.31.255.5
ge-1/3/2.0
Full
Neighbor-address fe80::2e21:72ff:feb2:45cd
172.31.255.8
xe-0/0/2.0
Full
Neighbor-address fe80::aad0:e5ff:fe5c:2d02
172.16.5.255
t3-1/0/1:1.0
Full
102
Pri
128
Dead
38
128
31
128
34
128
34
Configuring Multicast on the WAN Aggregation Router

Step-by-Step
Procedure
Figure 54: Multicast Design at Aggregation Hubs
For multicast at the aggregation hubs, we are using static rendezvous points (RPs) with
anycast RP. The RPs are configured on loopback interfaces on the WAN aggregation
routers. The WAN aggregation router on Aggregation Hub 1 is the primary RP, and the
WAN aggregation role on Aggregation Hub 2 is the secondary RP. We are using MSDP to
create a peering relationship between the primary and backup RPs.
For anycast RP, you configure the two RPs with a shared anycast IP address on loopback
interfaces. We recommend that you configure the anyc ast address with a 32-bit mask,
making it a host address. The shared anycast IP address is also used as the static RP
address when you configure PIM at the aggregation hub.
1.
Configure the loopback interface that is used as the static RP.

The primary address must be the address of the router ID on the WAN aggregation
router. Including the primary statement selects the routers primary address from
all of the preferred addresses on all interfaces. This configuration ensures that
routing protocols use the main lo0.0 address as the router ID.
The shared anycast address is 172.31.255.15/32.
[edit]
edit interfaces lo0 unit 0
set family inet address 172.31.255.2/32 primary
set family inet address 172.31.255.15/32
set family inet6 address 2001:DB8:255::2/128
103
2.
In the PIM configuration, specify the static RP. The local address is the address of
the RP, which is also the shared anycast address. The low priority number gives the
RP at Hub 1 priority over the RP at Hub 2.
[edit]
edit protocols pim
set rp local address 172.31.255.15
set rp local priority 1
3.
Configure multicast on the interface to the VPN termination router (ge-1/2/2), the
interface to the WAN aggregation router on Aggregation Hub 2 (ge-1/3/2), and the
interface to the data center (xe-0/0/2).
[edit]
edit protocols pim
set interface ge-1/2/2.0 family inet
set interface ge-1/2/2.0 mode sparse
set interface ge-1/2/2.0 version 2
set interface ge-1/3/2.0 family inet
set interface xe-0/0/2.0 mode sparse
set interface xe-0/0/2.0 version 2
4.
Configure MSDP peering between the primary IP addresses of the loopback

interfaces at the aggregation hubs. The peer is the address of the loopback that is
used as the rendezvous point at Aggregation Hub 2. The local address is the primary
address of lo0.0.
[edit]
edit protocols msdp
set peer 172.31.255.5 local-address 172.31.255.2
5.
Commit the configuration.

[edit]
commit
Results
Verify that PIM and MSDP are running.

1.
Verify PIM neighbors.

user@hub1> show pim neighbors
B = Bidirectional Capable, G = Generation Identifier
H = Hello Option Holdtime, L = Hello Option LAN Prune Delay,
P = Hello Option DR Priority, T = Tracking Bit
Instance: PIM.master
Interface
IP
ge-1/2/2.0
4
ge-1/2/5.0
4
ge-1/3/2.0
4
xe-0/0/2.0
4
V Mode
2
2
2
2
Option
HPLGT
HPLGT
HPLGT
HPLGT
1d
1d
1d
1d
Uptime
02:41:00
02:41:00
02:41:00
00:07:48
Neighbor addr
172.31.254.14
172.31.254.33
172.31.254.42
172.31.241.10
2. Verify that routes are created and traffic is flowing.

user@hub1> show pim rps extensive
104
address-family INET
RP: 172.31.255.15
Learned via: static configuration
Mode: Sparse
Time Active: 1d 02:42:50
Holdtime: 150
Device Index: 144
Subunit: 32769
Interface: pd-1/3/10.32769
Static RP Override: Off
Group Ranges:
224.0.0.0/4
Register State for RP:
Group
Source
FirstHop
235.1.1.1
172.31.252.10
172.31.255.8
134
235.1.1.2
172.31.252.10
172.31.255.8
132
235.2.1.1
172.31.252.10
172.31.255.8
131
235.2.1.2
172.31.252.10
172.31.255.8
139
235.2.1.3
172.31.252.10
172.31.255.8
140
235.2.1.4
172.31.252.10
172.31.255.8
140
RP Address
State
Timeout
172.31.255.15
Receive
172.31.255.15
Receive
172.31.255.15
Receive
172.31.255.15
Receive
172.31.255.15
Receive
172.31.255.15
Receive
172.31.255.8
172.31.255.15
Receive
172.31.255.8
172.31.255.15
Receive
172.31.255.8
172.31.255.15
Receive
. . .
235.4.1.23
172.31.252.10
131
235.4.1.24
172.31.252.10
131
235.4.1.25
172.31.252.10
131
Anycast PIM local address used:
172.31.255.2
address-family INET6
3. Verify that multicast is running over the interfaces.
user@hub1> show pim join
Instance: PIM.master Family: INET
R = Rendezvous Point Tree, S = Sparse, W = Wildcard
Group: 235.2.1.1
Source: *
RP: 172.31.255.15
Flags: sparse,rptree,wildcard
Upstream interface: Local
Group: 235.2.1.1
Source: 172.31.252.10
Flags: sparse,spt
Upstream interface: xe-0/0/2.0
Group: 235.2.1.2
Source: *
RP: 172.31.255.15
105
Group: 235.2.1.2
Source: 172.31.252.10
Flags: sparse,spt
Group: 235.2.1.3
Source: *
RP: 172.31.255.15
Group: 235.4.1.23
Source: 172.31.252.10
Flags: sparse,spt
Group: 235.4.1.24
Source: *
RP: 172.31.255.15
Group: 235.4.1.24
Source: 172.31.252.10
Flags: sparse,spt
. . .
Group: 235.4.1.25
Source: *
RP: 172.31.255.15
Group: 235.4.1.25
Source: 172.31.252.10
Flags: sparse,spt
Instance: PIM.master Family: INET6
4. Verify that IGMP groups are formed on each of the interfaces.
user@hub1> show igmp group
Interface: ge-1/2/2.0, Groups: 5
Group: 224.0.0.2
Source: 0.0.0.0
Last reported by: 172.31.254.14
Timeout:
155 Type: Dynamic
Group: 224.0.0.5
Source: 0.0.0.0
Timeout:
160 Type: Dynamic
Group: 224.0.0.6
Source: 0.0.0.0
Timeout:
161 Type: Dynamic
Group: 224.0.0.13
Source: 0.0.0.0
106

Timeout:
159 Type: Dynamic
Group: 224.0.0.22
Source: 0.0.0.0
Timeout:
158 Type: Dynamic
Group: 224.0.0.2
Source: 0.0.0.0
Timeout:
210 Type: Dynamic
Group: 224.0.0.5
Source: 0.0.0.0
Timeout:
203 Type: Dynamic
Group: 224.0.0.6
Source: 0.0.0.0
Timeout:
208 Type: Dynamic
Group: 224.0.0.13
Source: 0.0.0.0
Timeout:
208 Type: Dynamic
Group: 224.0.0.22
Source: 0.0.0.0
Timeout:
209 Type: Dynamic
Interface: xe-0/0/2.0, Groups: 5
Group: 224.0.0.2
Source: 0.0.0.0
Timeout:
237 Type: Dynamic
Group: 224.0.0.5
Source: 0.0.0.0
Timeout:
231 Type: Dynamic
Group: 224.0.0.6
Source: 0.0.0.0
Timeout:
233 Type: Dynamic
Group: 224.0.0.13
Source: 0.0.0.0
Timeout:
236 Type: Dynamic
Group: 224.0.0.22
Source: 0.0.0.0
Timeout:
229 Type: Dynamic
Interface: local, Groups: 5
Group: 224.0.0.2
Source: 0.0.0.0
Last reported by: Local
Timeout:
0 Type: Dynamic
Group: 224.0.0.5
Source: 0.0.0.0
Timeout:
0 Type: Dynamic
Group: 224.0.0.6
Source: 0.0.0.0
Timeout:
0 Type: Dynamic
107
Group: 224.0.0.13
Source: 0.0.0.0
Timeout:
0 Type: Dynamic
Group: 224.0.0.22
Source: 0.0.0.0
Timeout:
0 Type: Dynamic
5. Verify that groups are established with upstream interfaces to the Internet edge router
(xe-0/0/2.0) and downstream interfaces to the Layer 3 VPN service provider

(ge-1/2/5.0).
user@hub1> show multicast route extensive
Instance: master Family: INET
Group: 235.2.1.1
Source: 172.31.252.10/32
Downstream interface list:
ge-1/2/5.0
Session description: Unknown
Statistics: 35 kBps, 150 pps, 4125235 packets
Next-hop ID: 1052582
Upstream protocol: PIM
Route state: Active
Forwarding state: Forwarding
Cache lifetime/timeout: 360 seconds
Wrong incoming interface notifications: 2
Uptime: 07:38:23
Group: 235.2.1.2
Source: 172.31.252.10/32
ge-1/2/5.0
Route state: Active
Uptime: 07:38:23
. . .
Group: 235.4.1.24
Source: 172.31.252.10/32
ge-1/2/5.0
Route state: Active
108
Uptime: 07:38:23
Group: 235.4.1.25
Source: 172.31.252.10/32
ge-1/2/5.0
Route state: Active
Uptime: 07:38:22
Instance: master Family: INET6
6. After you have configured MSDP on Aggregation Hub 2, verify MSDP peers.
user@hub1> show msdp
Peer address
Local address
172.31.255.5
172.31.255.2
State
Last up/down Peer-Group
Established 1d 01:00:37
SA Count
0/0
Configuring CoS on the WAN Aggregation Router

Step-by-Step
Procedure
1.
Configure classifiers.
a. Configure the DSCP behavior aggregate (BA) classifier for IPv4.
[edit]
edit class-of-service classifiers dscp DSCP-BA
set forwarding-class Best_Effort loss-priority high code-points be
set forwarding-class Video loss-priority low code-points af41
set forwarding-class Voice loss-priority low code-points ef
set forwarding-class Network_Control loss-priority low code-points cs6
set forwarding-class Scavenger loss-priority low code-points cs1
set forwarding-class Bulk_Data loss-priority high code-points af11
set forwarding-class Critical_Data loss-priority low code-points af21
b. Configure the DSCP BA classifier for IPv6.
[edit]
edit class-of-service classifiers dscp-ipv6 DSCP-BA
109

c. Assign the forwarding classes to transmission queues.
[edit]
edit class-of-service forwarding-classes
set queue 0 Best_Effort
set queue 1 Scavenger
set queue 2 Bulk_Data
set queue 3 Critical_Data
set queue 4 Video
set queue 5 Voice
set queue 6 Network_Control
d. Configure rewrite rules for IPv4 traffic.
[edit]
edit class-of-service rewrite-rules dscp DEF_DSCP_REWRITE
set forwarding-class Voice loss-priority low code-point 101110
set forwarding-class Video loss-priority low code-point 100010
set forwarding-class Network_Control loss-priority low code-point 111000
set forwarding-class Critical_Data loss-priority low code-point 010010
set forwarding-class Bulk_Data loss-priority high code-point 001010
set forwarding-class Best_Effort loss-priority high code-point 000000
set forwarding-class Scavenger loss-priority high code-point 001000
e. Configure rewrite rules for core IPv6 traffic.
[edit]
edit class-of-service rewrite-rules dscp-ipv6 DEF_DSCP_REWRITE
2.
Create a scheduler for each forwarding class.

[edit]
edit class-of-service schedulers
set SCH_Scavenger transmit-rate percent 2
set SCH_Scavenger buffer-size percent 20
set SCH_Scavenger priority low
set SCH_VOICE transmit-rate percent 6
set SCH_VOICE priority strict-high
set SCH_Video transmit-rate percent 20
set SCH_Video priority high
set SCH_Network_Control transmit-rate percent 6
110
set SCH_Network_Control priority high

set SCH_Critical_Data transmit-rate percent 15
set SCH_Critical_Data buffer-size percent 15
set SCH_Critical_Data priority medium-high
set SCH_Bulk_Data transmit-rate percent 20
set SCH_Bulk_Data buffer-size percent 20
set SCH_Bulk_Data priority medium-high
set SCH_Best_Effort transmit-rate remainder
set SCH_Best_Effort buffer-size percent 20
set SCH_Best_Effort priority medium-low
3.
Map each scheduler to a forwarding class.

[edit
edit class-of-service scheduler-maps MAIN-SCHD
set forwarding-class Voice scheduler SCH_VOICE
set forwarding-class Video scheduler SCH_Video
set forwarding-class Scavenger scheduler SCH_Scavenger
set forwarding-class Network_Control scheduler SCH_Network_Control
set forwarding-class Critical_Data scheduler SCH_Critical_Data
set forwarding-class Bulk_Data scheduler SCH_Bulk_Data
set forwarding-class Best_Effort scheduler SCH_Best_Effort
4.
Create a traffic control profile to be applied to the interface to the Layer 3 VPN
service provider.
[edit]
edit class-of-service traffic-control-profiles TO-Layer 3 VPN-VPN1
set scheduler-map MAIN-SCHD
set shaping-rate 400m
5.
Create a traffic control profile that is applied to interfaces to the leased line provider.
[edit]
edit class-of-service traffic-control-profiles LEASED-LINE
6.
Apply CoS to the interface to the Internet edge router.

[edit]
edit class-of-service interfaces xe-0/0/0
set unit 0 forwarding-class Best_Effort
7.
Apply CoS to the interface to the interface to the data center.

[edit]
set unit 0 classifiers dscp DSCP-BA
set unit 0 classifiers dscp-ipv6 DSCP-BA
set unit 0 rewrite-rules dscp DEF_DSCP_REWRITE
set unit 0 rewrite-rules dscp-ipv6 DEF_DSCP_REWRITE
8.
Apply CoS to the interface to the VPN termination router.

[edit]
111
edit class-of-service interfaces ge-1/2/2

9.
Apply CoS to the interface to the WAN aggregation router at Aggregation Hub 2.
[edit]
Results
After the class-of-service configuration steps are complete, verify using the following
commands.
1.
Verify CoS on the interface to the Internet edge router.

user@wanagghub1> show class-of-service interface xe-0/0/2
Physical interface: xe-0/0/2, Index: 154
Queues supported: 8, Queues in use: 7
Scheduler map: <default>, Index: 2
Congestion-notification: Disabled
Logical interface: xe-0/0/2.0, Index: 333
Object
Name
Rewrite
DEF_DSCP_REWRITE
Rewrite
DEF_DSCP_REWRITE
Classifier
DSCP-BA
Classifier
DSCP-BA
Type
dscp
dscp-ipv6
dscp
dscp-ipv6
Index
61950
61951
961
2. Verify CoS on the interface to the VPN termination router.

user@wanagghub1> show class-of-service interface ge-1/2/2
Physical interface: ge-1/2/2, Index: 170
Logical interface: ge-1/2/2.0, Index: 333
Object
Name
Classifier
DSCP-BA
Classifier
DSCP-BA
Type
dscp
dscp-ipv6
Index
961
960
3. Verify CoS on the interface to the WAN aggregation router at Aggregation Hub 2.
user@wanagghub1> show class-of-service interface ge-1/3/2
Scheduler map: MAIN-SCHD, Index: 5286
Object
Name
Classifier
DSCP-BA
Classifier
DSCP-BA
Type
dscp
dscp-ipv6
Index
961
960
4. Verify that traffic counters are incrementing against the configured classes and queues.
user@wanagghub1> show interfaces xe-0/0/2 extensive
Physical interface: xe-0/0/2, Enabled, Physical link is Up
Interface index: 154, SNMP ifIndex: 514, Generation: 157
Description: --- To DC-ACCESS router (Magha-DC-ACCESS xe-0/0/2) ---
112
Link-level type: Ethernet, MTU: 1514, LAN-PHY mode, Speed: 10Gbps, BPDU
Error: None, Loopback: None, Source filtering: Disabled, Flow control: Enabled
Device flags
: Present Running
Interface flags: SNMP-Traps Internal: 0x0
Link flags
: None
CoS queues
: 8 supported, 8 maximum usable queues
Hold-times
: Up 0 ms, Down 0 ms
Current address: 5c:5e:ab:0e:41:72, Hardware address: 5c:5e:ab:0e:41:72
Last flapped
: 2013-06-18 10:57:39 PDT (1d 00:10 ago)
Statistics last cleared: Never
Traffic statistics:
Input bytes :
7752269351941
795833208 bps
Output bytes :
7814189915614
813114424 bps
Input packets:
28211048134
364239 pps
Output packets:
27979629883
361951 pps
IPv6 transit statistics:
Input bytes :
420496306422
Output bytes :
836948546760
Input packets:
1796992770
Output packets:
3576700052
Dropped traffic statistics due to STP State:
Input bytes :
0
Output bytes :
0
Input packets:
0
Output packets:
0
Input errors:
Errors: 0, Drops: 0, Framing errors: 0, Runts: 0, Policed discards: 0, L3
incompletes: 0, L2 channel errors: 0, L2 mismatch timeouts: 0, FIFO errors:
0,
Resource errors: 0
Output errors:
Carrier transitions: 3, Errors: 0, Drops: 33354, Collisions: 0, Aged
packets: 0, FIFO errors: 0, HS link CRC errors: 0, MTU errors: 0,
Resource errors: 0
Egress queues: 8 supported, 7 in use
Queue counters:
Queued packets Transmitted packets
Dropped packets
0 Best_Effort
25551424919
25551424919
622892576
622875969
617076089
617076089
458237322
458225556
444989807
444986900
285379194
285377120
0
1 Scavenger
0
2 Bulk_Data
16607
3 Critical_Dat
0
4 Video
11766
5 Voice
2907
6 Network_Cont
2074
Queue number:
0
1
2
3
4
5
6
Active alarms : None
Mapped forwarding classes

Best_Effort
Scavenger
Bulk_Data
Critical_Data
Video
Voice
Network_Control
113
Active defects : None

PCS statistics
Seconds
Bit errors
1
Errored blocks
2
MAC statistics:
Receive
Transmit
Total octets
7754332915577
7815845819263
Total packets
28211375206
27979953716
Unicast packets
27437394916
27979771866
Broadcast packets
45
44
Multicast packets
773980234
181825
CRC/Align errors
0
0
FIFO errors
0
0
MAC control frames
0
0
MAC pause frames
0
0
Oversized frames
0
Jabber frames
0
Fragment frames
0
VLAN tagged frames
0
Code violations
0
Total errors
0
0
Filter statistics:
Input packet count
28211011680
Input packet rejects
3461
Input DA rejects
0
Input SA rejects
0
Output packet count
27979593645
Output packet pad count
0
Output packet error count
0
CAM destination filters: 0, CAM source filters: 0
Packet Forwarding Engine configuration:
Destination slot: 0
CoS information:
Direction : Output
CoS transmit queue
Bandwidth
Buffer Priority
Limit
%
bps
%
usec
0 Best_Effort
95
9500000000
95
0
low
none
3 Critical_Data
5
500000000
5
0
low
none
Interface transmit statistics: Disabled
Logical interface xe-0/0/2.0 (Index 333) (SNMP ifIndex 566) (Generation 142)
Flags: SNMP-Traps 0x0 Encapsulation: ENET2
Statistics account overhead :
Ingress account overhead :
Egress account overhead
:
Traffic statistics:
Input bytes :
7752269021059
Output bytes :
7814188205420
Input packets:
28211047458
Output packets:
27979629884
Input bytes :
420496305686
Output bytes :
836948546760
Input packets:
1796992769
Output packets:
3576700052
Local statistics:
Input bytes :
211555319
Output bytes :
219102457
114
18 bytes
18 bytes
Input packets:
379386
Output packets:
285267
Transit statistics:
Input bytes :
7752057465740
795823080 bps
Output bytes :
7813969102963
813102864 bps
Input packets:
28210668072
364238 pps
Output packets:
27979344617
361950 pps
Input bytes :
420496305686
Output bytes :
836948546760
Input packets:
1796992769
Output packets:
3576700052
Protocol inet, MTU: 1500, Generation: 160, Route table: 0
Flags: Sendbcast-pkt-to-re, User-MTU
Addresses, Flags: Is-Preferred Is-Primary
Destination: 172.31.241/24, Local: 172.31.241.2, Broadcast:
172.31.241.255, Generation: 150
Protocol inet6, MTU: 1500, Generation: 161, Route table: 0
Flags: Is-Primary
Addresses, Flags: Is-Preferred
Destination: fe80::/64, Local: fe80::5e5e:abff:fe0e:4172
Generation: 152
Destination: fec0:31:241::/64, Local: fec0:31:241::2
Protocol multiservice, MTU: Unlimited, Generation: 154
Generation: 162, Route table: 0
Policer: Input: __default_arp_policer__
Configuring Per-Packet Load Balancing on the WAN Aggregation Router

Step-by-Step
Procedure
This solution is configured with per-packet load balancing (PPLB). This configuration
installs the active route as well as all next-hop addresses for a destination in the
forwarding table. You can use load balancing to spread traffic across multiple paths
between routers. Load balancing is configured on the ingress router and uses a hash
algorithm to distribute traffic equally across multiple paths.
NOTE: PPLB enables faster convergence in cases where one of the active
links fails as the remaining links and next hops are installed on the forwarding
table.
The following steps are used to configure per-packet load balancing on the WAN
aggregation router.
1.
Configure a load-balancing policy called PLBB.

[edit]
edit policy-options policy-statement PPLB
set then load-balance per-packet
2.
Apply the policy configured to routes exported from the routing table to the
forwarding table. This is configured so that if there are two equal cost routes to
destination, the host will use both the next-hop links. This ensures routing load is
distributed
115
[edit]
set forwarding-table export PPLB
116
Configuring the VPN Termination Router at Aggregation Hub 1

Figure 55: Aggregation Hub 1 VR and Interface Configuration
Enabling CoS T1/T3 Interfaces on the VPN Termination Router on page 118
Enabling the PIC for Tunneling and Per-Unit Scheduling on the VPN Termination
Router on page 118
Configuring the Physical Transport on the VPN Termination Router on page 119
Configuring IPsec Tunnel Termination on the VPN Termination Router on page 120
Configuring GRE Tunnel Termination on the VPN Termination Router on page 121
Configuring Access to Hosted Services for External Internet Users on page 124
Configuring Access to Hosted Services for Internal Users on page 125
Configuring Routing Policies for IBGP Peers on the VPN Termination Router on page 127
Configuring Fully-Meshed IBGP Peer Groups on the VPN Termination Router on page 128
Configuring CoS on the VPN Termination Router on page 129
117
Enabling CoS T1/T3 Interfaces on the VPN Termination Router

Step-by-Step
Procedure
For T3 interfaces configured on channelized IQ PICs, enable CoS queuing, scheduling,

and shaping, set the number of egress queues to 8, and enlarge the buffer size to help
prevent congestion and packet dropping.
1.
Enable CoS queueing, scheduling, and shaping on T3 channelized interfaces.

[edit]
edit chassis fpc 0 pic 0
set traffic-manager mode ingress-and-egress
2.
Specify the maximum number of egress queues supported on each interface.

[edit]
set max-queues-per-interface 8
3.
To help prevent congestion and packet dropping configure a larger buffer size.
[edit]
set q-pic-large-buffer
Enabling the PIC for Tunneling and Per-Unit Scheduling on the VPN Termination
Router
Step-by-Step
Procedure
Follow this procedure to enable per-unit scheduling for GRE tunnels on M7i Series routers
with Intelligent Queuing 2 (IQ2) PICs and IQ 2 Enhanced (IQ2E) PICs.
1.
Enable per-unit CoS scheduling on GRE tunnels.

This step adds all the functionality of tunnel PICs to GRE tunnels. CoS for GRE tunnel
traffic is applied as the traffic is looped through IQ2 and IQ2E PICs. Shaping is
performed on full packets that pass through the GRE tunnel.
This feature supports only traffic control profiles on GRE tunnels. To apply a
scheduler to a GRE tunnel, add the scheduler to the traffic control profile and not
directly to the tunnel interface.
[edit]
set tunnel-services
2.
You can specify that IQ2 and IQ2E PICs work exclusively in tunnel mode or as a
regular PIC. The default setting uses IQ2 and IQ2E PICs as a regular PIC. To configure
exclusive tunnel mode, add the tunnel-only statement.
[edit]
set tunnel-services tunnel-only
3.
Specify the maximum number of egress queues supported on each interface.

[edit]
set max-queues-per-interface 8
118
Configuring the Physical Transport on the VPN Termination Router

Step-by-Step
Procedure
1.
Configure the Ethernet interface to the Internet edge router.

Unit 0 handles IPsec tunnel traffic from the branch.
Unit 1 handles traffic for hosted services. The traffic can come from a branch or the
public Internet. Unit 1 is placed in the HOSTED-WWW-NAT virtual router.
[edit]
set description "----Connected to Internet Edge Hub 1--------"
set vlan-tagging
set unit 0 vlan-id 1
set unit 1 description "--- Hosted Service Traffic from Edge---"
2.
Add the Ethernet interface that connects to servers that provide hosted services.
[edit]
set description "--- To Hosted Services Hub 1 ---"
3.
Configure the Ethernet interface to the WAN aggregation router.

[edit]
set description "----Connected to WAN aggregation Hub 1---"
set unit 0 family inet6 address fec0:31:254:4::2/64
4.
Configure the loopback interfaces.

Unit 1 is in the WAN-GRE routing instance.
It is used for BGP routing between the VPN termination router and the WAN
aggregation router. The loopback address is advertised to IBGP.
Unit 2 is used in the VPN routing instance.
[edit]
edit interfaces lo0
set unit 1 description "--- WAN GRE VR Routing instance ---"
set unit 1 family inet filter input RE-PROTECT
set unit 1 family inet6 address 2001:DB8:255::3/128
set unit 2 description "--- VPN Routing instance ---"
set unit 2 family inet filter input RE-PROTECT
119
Configuring IPsec Tunnel Termination on the VPN Termination Router

Step-by-Step
Procedure
The VPN routing instance is a public Internet-facing instance that is used for branches
that connect to the hub over IPsec tunnels. It acts as the IPsec endpoint for IPsec requests
from the branch, and it terminates IPsec tunnels that are initiated at the branch.
When you configure a branch scenario that uses IPsec tunnels to Hub 1, you add IPsec
interfaces used for the scenario to the VPN routing instance, and you add the loopback
interface that is used as the GRE tunnel source address at the hub.
1.
Create the VPN virtual router routing instance.

[edit]
edit routing-instances VPN
set instance-type virtual-router
2.
2. Add the Ethernet interface to the Internet edge router, and configure a default
static route to the Ethernet interface. This is for reachability to the Internet connected
branches
[edit]
set routing-options static route 0.0.0.0/0 next-hop 198.51.100.5
Results
After Static Routing steps are configured, verify

1.
Verify that the static route is installed in the routing table.

user@vpn1> show route 0.0.0.0/0 exact table VPN.inet.0
VPN.inet.0: 1030 destinations, 1030 routes (1030 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
0.0.0.0/0
*[Static/5] 02:31:29
> to 198.51.100.5 via ge-0/0/0.0
2. Verify connectivity to the Internet branch router.

user@hub1> ping 1.1.0.2 routing-instance VPN rapid
PING 1.1.0.2 (1.1.0.2): 56 data bytes
!!!!!
--- 1.1.0.2 ping statistics --5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.605/0.822/1.119/0.194 ms
120
Configuring GRE Tunnel Termination on the VPN Termination Router

Step-by-Step
Procedure
The WAN-GRE virtual router routing instance terminates GRE tunnels from the
Internet-connected branches. The routing instance provides private overlay routing over
the GRE tunnels to the branch, and includes OSPF and IBGP routing adjacencies between
the GRE tunnels and the WAN aggregation router over the directly connected Ethernet
link. The routing instance also includes multicast peering with the WAN aggregation
router.
When you configure a branch scenario that uses GRE tunnels to Hub 1, you add GRE
interfaces used for the scenario to the WAN-GRE routing instance, and you add the
loopback interface that is used as the GRE tunnel source address at the hub.
Only the default route is advertised to the branches over OSPF.
1.
Create the virtual router routing instance, and add the Ethernet interface to the
WAN aggregation router.
[edit]
edit routing-instances WAN-GRE
2.
Configure the routing ID for the routing instance.

[edit]
edit routing-instances WAN-GRE routing-options
3.
Configure the OSPF backbone area for IPv4.

Set the external preference for OSPF routes to 175. A preference of 175 gives BGP
routes, which have a default preference of 170, preference in the routing table over
OSPF routes.
Add the Ethernet interface to the WAN aggregation router, and then add loopback
interface unit 1.
[edit]
edit routing-instances WAN-GRE protocols ospf area 0.0.0.0
"$9$gWaGjmfQ9AuSrw24aDjCAp"
4.
Configure the OSPFv3 backbone area for IPv6.

OSPF routes.
interface unit 1.
121
edit routing-instances WAN-GRE protocols ospf3 area 0.0.0.0

set interface lo0.1
Configure multicast peering with the WAN aggregation router.
5.
Add the static rendezvous point, and add the Ethernet interface to the WAN
aggregation router.
[edit]
edit routing-instances WAN-GRE protocols pim
set rp static address 172.31.255.15
Results
After the complete GRE over IPsec tunnel configuration is complete, use the commands
in the following section to verify that the configuration was successful.
1.
Verify that the WAN-GRE routing instance is receiving the default static route from
the WAN aggregation router at Hub 1 for Internet-bound traffic that is sourced from
the Internet-connected branch.
user@vpn1> show route table WAN-GRE.inet.0 0.0.0.0/0 exact
WAN-GRE.inet.0: 27862 destinations, 56271 routes (27862 active, 0 holddown, 0
hidden)
0.0.0.0/0
*[OSPF/175] 03:00:31, metric 0, tag 0

> to 172.31.254.13 via ge-0/0/1.0
2. Verify the routes that are advertised by the data center.

user@hub1> show route table WAN-GRE.inet.0 172.28.0.0/16 terse
hidden)
A
*
*
*
.
.
*
*
*
V
?
?
?
Destination
172.28.1.0/24
172.28.2.0/24
172.28.3.0/24
P Prf
O 10
O 10
O 10
.
?
?
?
..
172.28.248.0/24
172.28.249.0/24
172.28.250.0/24
O
O
O
10
10
10
Metric 1
27
27
27
27
27
27
Metric 2
Next hop
>172.31.254.13
>172.31.254.13
>172.31.254.13
AS path
>172.31.254.13
>172.31.254.13
>172.31.254.13
user@hub1> show route table WAN-GRE.inet.0 172.28.0.0/16 terse | count

Count: 254 lines
3. Verify connectivity to the data center through the WAN aggregation router.
user@hub1> ping 172.31.255.8 routing-instance WAN-GRE rapid source 172.31.255.3
PING 172.31.255.8 (172.31.255.8): 56 data bytes
!!!!!
user@hub1> traceroute 172.31.255.8 routing-instance WAN-GRE source 172.31.255.3
122
traceroute to 172.31.255.8 (172.31.255.8) from 172.31.255.3, 30 hops max, 40

byte packets
1 172.31.254.13 (172.31.254.13) 0.557 ms 6.603 ms 3.968 ms
## WAN-AGG1
2 172.31.255.8 (172.31.255.8)
DC-ACCESS
0.787 ms
10.588 ms
0.594 ms
##
4. Verify connectivity to the data center.

user@hub1> ping 172.31.255.8 routing-instance WAN-GRE rapid source 172.31.255.3
PING 172.31.255.8 (172.31.255.8): 56 data bytes
!!!!!
5. Verify multicast neighbors on the WAN-GRE routing instance. These include the WAN
aggregation router and GRE tunnels.

user@hub1> show pim neighbors instance WAN-GRE
Instance: PIM.WAN-GRE
Interface
IP V Mode
ge-0/0/1.0
4 2
Option
HPLGT
Uptime Neighbor addr

23:30:16 172.31.254.13
123
Configuring Access to Hosted Services for External Internet Users

Step-by-Step
Procedure
Figure 56: Internet User Traffic Flow (SFW + NAT) To and From Enterprise
Hosted Services
The HOSTED-WWW-NAT virtual router routing instance is used to route external Internet
traffic to and from hosted services.
1.
Create a routing instance, and add the interface to the Internet edge router that
handles hosted services traffic (ge-0/0/0.1) and at the interfaces to the hosted
services (ge-0/0/3.0).
[edit]
edit routing-instances HOSTED-WWW-NAT
2.
Create a default static route with a next hop to the interface on the Internet edge
router that handles traffic for hosted services. This route is for return external traffic
from hosted services to the Internet.
[edit]
edit routing-instances HOSTED-WWW-NAT routing-options
124
Configuring Access to Hosted Services for Internal Users

Step-by-Step
Procedure
Figure 57: Interface and VR Configuration for Internal User Access to

Hosted Services
This configuration is used to provide access to hosted services for internal traffic from
branches or from the data center. Internal users access hosted services using internal
addressing of either 172.16.0.0/12 or 10.0.0.0/8.
1.
Configure the services interfaces that will process NAT.

[edit]
edit interfaces sp-0/3/0
set unit 4001 family inet
set unit 4001 service-domain inside
set unit 4002 service-domain outside
2.
Configure the NAT pool.

[edit]
edit services nat pool branch-priv-pool
set address 172.31.254.80/28
set port range low 3000
set port range high 10000
3.
Configure the NAT rule.
125
[edit]
edit services nat rule Branch-DC-to-www
set match-direction input
set term from-branch-lan from source-address 172.16.0.0/12
set term from-branch-lan then translated source-pool branch-priv-pool
set term from-branch-lan then translated translation-type napt-44
4.
Configure the stateful firewalls.

[edit]
edit services stateful-firewall rule ALLOW_ALL
set match-direction input-output
set term TERM then accept
5.
Configure a next-hop style service set.

[edit]
edit services service-set NAT-Branch-www
set stateful-firewall-rules ALLOW_ALL
set nat-rules Branch-DC-to-www
set next-hop-service inside-service-interface sp-0/3/0.4001
set next-hop-service outside-service-interface sp-0/3/0.4002
6.
Add the outside interface to the HOSTED-WWW-NAT routing instance.

[edit]
set interface sp-0/3/0.4002
7.
Add the inside service interface to the WAN-GRE routing instance.

[edit]
8.
Configure a static route in the GRE routing instance for traffic from the private NAT
pool addresses with the next hop of the inside service interface.
[edit]
set static route 172.31.254.48/28 next-hop sp-0/3/0.4001
9.
Configure a routing policy that exports the static route to OSPF so that it is advertised
to Aggregation Hub 2.
[edit]
edit policy-options policy-statement STATIC2OSPF
10.
Add the routing policy to the WAN-GRE routing instance.

[edit]
edit routing-instances WAN-GRE protocols ospf
set export STATIC2OSPF
126
Configuring Routing Policies for IBGP Peers on the VPN Termination Router
Step-by-Step
Procedure
Please see Figure 52 on page 97 for overview of IBGP design.

1.
of the router to be advertised as the next-hop for BGP traffic.
[edit]
2.
of the router to be advertised as the next-hop address for BGP traffic.
[edit]
3.
Configure a policy that is used to advertise default static IPv4 routes. It is a next-hop
self policy, which causes the loopback address of the router to be advertised of the
next-hop address.
[edit]
4.
Configure a policy that is used to advertise default static IPv6 routes.

[edit]
edit policy-options policy-statement ADV_DEFAULT6
set term default then reject
5.
Configure a policy that is used to accept default IPv6 routes.

[edit]
edit policy-options policy-statement ACCEPT_DEFAULT-V6
set term 1 from route-filter ::0/0 exact
127
Configuring Fully-Meshed IBGP Peer Groups on the VPN Termination Router

Step-by-Step
Procedure
At the aggregation hubs, we have a full IBGP mesh with the WAN aggregation router and
the WAN-GRE virtual router on Aggregation Hub 1 and the WAN-GRE virtual router on
Aggregation Hub 2.
1.
Configure the AS number for the routing instance.

[edit]
2.
WAN aggregation router at Hub 1 (172.31.255.2).
[edit]
edit routing-instances WAN-GRE protocols bgp group IBGP-Mesh
set type internal
set export NHS
set bfd-liveness-detection minimum-interval 500
set bfd-liveness-detection multiplier 3
set neighbor 172.31.255.2 authentication-key "$9$m5zntuBSrK-VH.P53nyre"
set neighbor 172.31.255.5 authentication-key "$9$rvMKWXVw2GDHz3hylKLXUDi"
set neighbor 172.31.255.6 authentication-key "$9$EIqSlvxNV4aGP5BRhSKvoaZ"
3.
WAN aggregation router at Hub 1 (2001:DB8:255::2).

(2001:DB8:255::6).
The NHS6 export policy causes the router to advertise the address of the loopback
[edit]
edit routing-instances WAN-GRE protocols bgp group IBGP-Mesh-V6
set type internal
set export NHS6
set neighbor 2001:DB8:255::2 authentication-key "$9$JcUiqTznp01evgaZUkqu0B"
set neighbor 2001:DB8:255::5 authentication-key
"$9$tZ9i01ElKW-VsUj/Ap0REdVw"
"$9$/C3aAuBcyeX7daZF69AOBx7-"
128
Configuring CoS on the VPN Termination Router

Step-by-Step
Procedure
Figure 58: Class-of-Service Configuration Between Branch and

Aggregation Hub
NOTE: The alternate configuration utilizing MX80 with per-GRE class of

service is here: Appendix A: Alternate Configuration Aggregation and
Branch using MX80 with Services MIC on page 737
1.
a. Configure the DSCP behavior aggregate (BA) classifier for IPv4.
[edit]
[edit]
129

[edit]
set queue 4 Video
set queue 5 Voice
[edit]
e. Configure rewrite rules for core IPv6 traffic.
[edit]
2.

[edit]
130

3.

[edit]
4.
Create a traffic control profile to be applied to interfaces to branches.

[edit]
edit class-of-service traffic-control-profiles SMALL-BRANCH
5.
Create a traffic control profile that is applied to interfaces to branches.

[edit]
edit class-of-service traffic-control-profiles SCALED-BRANCH
set shaping-rate 2m
6.
Apply the scheduler to the interface to the WAN aggregation router at Aggregation
Hub 1.
[edit]
7.
Apply the scheduler and the control profile to the GRE tunnel interfaces.
[edit]
edit class-of-service interfaces gr-0/1/0
set unit 1 output-traffic-control-profile SMALL-BRANCH
set unit 11 output-traffic-control-profile SCALED-BRANCH
8.
Enable two-rate tricolor marking (TCM), which applies metering to incoming

classified traffic. Metering can increase a packets assigned packet loss priority, but
cannot decrease it.
131
[edit]
edit class-of-service
set tri-color
Results
After class of service is configured and committed, verify the configuration success using
the following commands:
1.
Verify CoS on the interface to the WAN aggregation router.

user@vpn-router> class-of-service interface ge-0/0/1
Input scheduler map: <default>, Index: 2
Chassis scheduler map: <default-chassis>, Index: 4
Object
Name
Classifier
DSCP-BA
Classifier
DSCP-BA
132
Type
dscp
dscp-ipv6
Index
961
CHAPTER 5
Configuring the Internet Gateway on

Aggregation Hub 1
Configuring the Internet Gateway on Aggregation Hub 1
Requirements
Internet edge routerMX480 3D Universal Edge router with dual Routing Engines
Junos OS Release 12.3R3
Overview
Topology
This section focuses on configuration of the nodes in the blue highlighted area
Figure 59: The Test Topology of Aggregation Hub 1

AGGREGATION HUB 1
Internet Gateway
MX480
ge-1/2/5
ge-1/2/6
ge-0/1/1
xe-0/0/0
xe-1/0/1
WAN
Aggregation
MX80
xe-0/0/0
ge-1/2/2
coc-1/0/1
ge-1/2/5
ge-0/0/2
ge-1/3/7
Test /
Emulation
ge-1/3/2
To Aggregation Hub 2
Hosted
Services
ge-0/0/3
Data
Center
LEASED
LINE
PROVIDER
MPLS
L3 VPN
AS 555
ge-0/0/0
g041803
ISP A
AS 169
VPN
Termination
M7i
133
Configuring the Physical Transport on the Internet Gateway on page 134
Configuring the Logical Transport on the Internet Gateway on page 135
Configuring Security Based on Application Traffic on the Internet edge router on page 135
Configuring NAT and Stateful Firewall for Inbound Hosted Services Traffic on the
Internet Gateway on page 139
Configuring NAT and Stateful Firewall for Outbound Traffic on the Internet
Gateway on page 140
Configuring the Router ID for the Internet Gateway on page 142
Configuring Routing Policies on the Internet Gateway on page 143
Configuring BGP Peer Groups on the Internet Gateway on page 145
Configuring Routing for WAN Aggregation Services on the Internet Gateway on page 149
Configuring High Availability on the Internet Gateway on page 152
Configuring CoS on the Internet Gateway on page 152
Configuring the Physical Transport on the Internet Gateway

Step-by-Step
Procedure
1.
Configure the interface to the ISP.

[edit]
2.
Configure the interface to the VPN termination router used for hosted services. The
VLAN on unit 1 is configured with a private IP subnet, and is used to send hosted
Web server traffic. Before traffic from a user on the Internet is sent over this interface,
destination-based NAT is applied.
[edit]
set unit 1 family inet service input service-set NAT-Hosted-Service
set unit 1 family inet service output service-set NAT-Hosted-Service
3.
Configure the Ethernet interface to the WAN aggregation router.

[edit]
set unit 0 family inet6
4.
Configure the interface to the VPN termination router. The VLAN on unit 0 is
configured with the public IP address that is used to terminate IPsec tunnels on the
VPN termination router.
[edit]
set vlan-tagging
134
Chapter 5: Configuring the Internet Gateway on Aggregation Hub 1

5.
Configure the Ethernet interface to the Internet edge router at Aggregation Hub 2.
[edit]
Configuring the Logical Transport on the Internet Gateway

Step-by-Step
Procedure
1.
Configure the services interface used to process NAT and stateful firewalls.
Unit 0 is used in the NAT and stateful firewall service set that is applied to traffic
from the Internet to the enterprise network. This interface is placed in the
SFW-NAT-SERVICES routing instance.
Units 1 and 2 are used in the NAT and stateful firewall service set that is applied to
traffic from branches, the data center, and hosted services to the Internet.
[edit]
set unit 1 description "--- Branch to WWW NAT service inside interface ---"
set unit 2 description "--- Branch to WWW NAT service outside interface ---"
2.
Add the loopback interface.

Unit 0 is used in the default routing instance.
Unit 1 is used for NAT, and is in the SFW-NAT-SERVICES routing instance. Its IP
address is the address of the router ID.
[edit]
edit interfaces lo0
Configuring Security Based on Application Traffic on the Internet edge router

Step-by-Step
Procedure
We are using Application Layer Gateways (ALGs) in stateful firewalls for applications
for which the return flow can be difficult to predict because the application often creates
separate connections for data and control flows or creates new protocol flows based
on an open connection.
You can customize this ALG configuration to specify traffic that you want to block or
allow through your stateful firewalls.
1.
Configure the following ALGs:

[edit]
135
edit applications
set application ftp application-protocol ftp
set application ftp protocol tcp
set application ftp destination-port 21
set application tftp application-protocol tftp
set application tftp protocol udp
set application tftp destination-port 69
set application rpcportmaptcp application-protocol rpc-portmap
set application rpcportmaptcp protocol tcp
set application rpcportmaptcp destination-port 111
set application rpcportmapudp application-protocol rpc-portmap
set application rpcportmapudp protocol udp
set application rpcportmapudp destination-port 111
set application rexec application-protocol exec
set application rexec protocol tcp
set application rexec destination-port 512
set application rlogin protocol tcp
set application rlogin destination-port 513
set application rsh application-protocol shell
set application rsh protocol tcp
set application rsh destination-port 514
set application rtsp application-protocol rtsp
set application rtsp protocol tcp
set application rtsp destination-port 554
set application winframe application-protocol winframe
set application winframe protocol tcp
set application winframe destination-port 1494
set application sqlnet application-protocol sqlnet
set application sqlnet protocol tcp
set application sqlnet destination-port 1521
set application h323 application-protocol h323
set application h323 protocol tcp
set application h323 destination-port 1720
set application iiop-java application-protocol iiop
set application iiop-java protocol tcp
set application iiop-java destination-port 1975
set application iiop-orbix application-protocol iiop
set application iiop-orbix protocol tcp
set application iiop-orbix destination-port 3075
136
set application realaudio application-protocol realaudio

set application realaudio protocol tcp
set application realaudio destination-port 7070
set application traceroute application-protocol traceroute
set application traceroute protocol udp
set application traceroute destination-port 33435-33450
set application traceroute ttl-threshold 30
set application rpcservicesudp application-protocol rpc
set application rpcservicesudp protocol udp
set application rpcservicesudp rpc-program-number 100000-400000
set application rpcservicestcp application-protocol rpc
set application rpcservicestcp protocol tcp
set application rpcservicestcp rpc-program-number 100000-400000
set application icmp-all application-protocol icmp
set application netshow application-protocol netshow
set application netshow protocol tcp
set application netshow destination-port 1755
set application netbios_name application-protocol netbios
set application netbios_name protocol udp
set application netbios_name destination-port 137
set application netbios_datagram application-protocol netbios
set application netbios_datagram protocol udp
set application netbios_datagram destination-port 138
set application dcerpcportmap application-protocol dce-rpc-portmap
set application dcerpcportmap protocol tcp
set application dcerpcportmap destination-port 135
set application dcerpc-uuid-epm application-protocol dce-rpc
set application dcerpc-uuid-epm protocol tcp
set application dcerpc-uuid-epm uuid e1af8308-5d1f-11c9-91a4-08002b14a0fa
set application dcerpc-uuid-foo application-protocol dce-rpc
set application dcerpc-uuid-foo protocol tcp
set application dcerpc-uuid-foo uuid 1544f5e0-613c-11d1-93df-00c04fd7bd09
set application dcerpc-uuid-ntlmssp-negotiate application-protocol dce-rpc
set application dcerpc-uuid-ntlmssp-negotiate protocol tcp
set application dcerpc-uuid-ntlmssp-negotiate uuid
a4f1db00-ca47-1067-b31f-00dd010662da
set application snmp application-protocol snmp
set application snmp protocol udp
137
set application snmp destination-port 161

set application web protocol tcp
set application web destination-port 80
2.
Group all of the ALGs into an application set.

[edit]
edit applications application-set all-alg-set
set application ftp
set application tftp
set application rpcportmaptcp
set application rpcportmapudp
set application rexec
set application rlogin
set application rsh
set application rtsp
set application winframe
set application sqlnet
set application h323
set application iiop-java
set application iiop-orbix
set application realaudio
set application traceroute
set application rpcservicesudp
set application rpcservicestcp
set application icmp-all
set application netshow
set application netbios_name
set application netbios_datagram
set application dcerpcportmap
set application dcerpc-uuid-epm
set application dcerpc-uuid-foo
set application dcerpc-uuid-ntlmssp-negotiate
set application snmp
3.
Create a stateful firewall that allows accounting traffic through the firewall.
[edit]
edit services stateful-firewall rule protect-accounting
set term allow-accounting-out-alg from application-sets all-alg-set
set term allow-accounting-out-alg then accept
set term allow-accounting-out-no-alg then accept
138
Configuring NAT and Stateful Firewall for Inbound Hosted Services Traffic on the
Internet Gateway
Step-by-Step
Procedure
Figure 60: Inbound NAT and Stateful Firewall for Hosted Services on the
Internet Gateway
This procedure configures destination NAT and the stateful firewall for external traffic
received from the Internet and sent to hosted services.
1.
Create a NAT pool used for hosted services.

[edit]
edit services nat pool www-addr
set address 172.31.254.48/28
2.
Create a NAT rule used to perform destination NAT. Use translation type dnat-44,
which causes the destination address to be statically translated (IPv4 to IPv4).
[edit]
edit services nat rule To-Hosted-service
set match-direction output
set term from-internet from destination-address 198.51.100.224/28
set term from-internet then translated destination-pool www-addr
set term from-internet then translated translation-type dnat-44
3.
Create an application set for the DMZ using applications that were previously
configured.
[edit]
edit applications application-set dmz-alg-set
set application ftp
139
set application web

set application junos-ip
4.
Create a stateful firewall that accepts application traffic that is defined in the
dmz-alg-set application set.
[edit]
edit services stateful-firewall rule internet-to-dmz
set term allow-web-rtsp from application-sets dmz-alg-set
set term allow-web-rtsp then accept
5.
Configure an interface service set to be used for hosted services.

[edit]
edit services service-set NAT-HOSTED-WEB
set stateful-firewall-rules internet-to-dmz
set nat-rules To-Hosted-service
set interface-service service-interface sp-3/0/0.0
6.
Configure a static route to the interface on the VPN termination router that handles
hosted services (ge-0/0/0.1). After external traffic has gone through NAT, it is sent
to this route.
[edit routing-options]
Results
Verify that the service set is working as expected.

user@iedge1> show services stateful-firewall flows service-set NAT-Hosted-Service
Interface: sp-3/0/0, Service set: NAT-Hosted-Service
Flow
State
Dir
Frm count
61
100.65.4.2:0
-> 198.51.100.224:0
Forward O
25504422
NAT dest
198.51.100.224:0
->
172.31.254.50:0
user@iedge1> show services stateful-firewall statistics
Interface
Service set
Accept
Discard
sp-3/0/0
NAT-Branch-internet
8948614
0
sp-3/0/0
NAT-Hosted-Service
2591669
0
Reject
0
0
Errors
0
0
Gateway
Step-by-Step
Procedure
This procedure configures source NAT and the stateful firewall for traffic from branches,
the data center, or hosted services that is headed to the Internet.
1.
Create a pool of addresses for the enterprise block of assigned addresses. These
addresses are advertised to the Internet, and are used for source NAT.
[edit]
edit services nat pool public-pool
set address 100.64.100.0/24
2.
140
Create a destination NAT rule.
[edit]
edit services nat rule Branch-DC-to-Internet
set term from-lan from source-address 172.16.0.0/12
set term from-lan then translated source-pool public-pool
set term from-lan then translated translation-type napt-44
3.
Create a stateful firewall rule that allows all traffic through the firewall.
[edit]
4.
Create a stateful firewall that specifies application traffic that is allowed from the
enterprise to the Internet. Use the application set that was configured previously.
[edit]
edit services stateful-firewall rule corp-to-internet
set term allow-all-alg from application-sets all-alg-set
set term allow-all-alg then accept
set term allow-non-alg then accept
5.
Create a next-hop style service set that applies the NAT rule and the stateful firewall.
[edit]
edit services service-set NAT-Branch-internet
set stateful-firewall-rules corp-to-internet
set nat-rules Branch-DC-to-Internet
6.

[edit]
commit
Results

user@iedge1> show services stateful-firewall flows service-set NAT-Branch-internet
Interface: sp-3/0/0, Service set: NAT-Branch-internet
Flow
State
Dir
Frm count
TCP
140.1.5.1:80
-> 100.64.100.231:8770
Forward O
0
NAT dest
100.64.100.231:8770
->
10.4.50.1:28355
TCP
172.28.21.1:3994
->
140.1.50.1:80
Forward I
6
NAT source
172.28.21.1:3994
-> 100.64.100.232:3057
TCP
172.28.44.1:4438
->
140.1.20.1:80
Forward I
6
NAT source
172.28.44.1:4438
-> 100.64.100.232:3501
UDP
140.1.45.1:63
-> 100.64.100.73:5686
Forward O
0
NAT dest
100.64.100.73:5686
->
10.4.23.1:52045
UDP
140.1.24.1:63
-> 100.64.100.73:6337
Forward O
0
NAT dest
100.64.100.73:6337
->
10.3.35.4:51173
141
UDP
10024
NAT
UDP
10024
NAT
TCP
6
NAT
UDP
0
NAT
TCP
5
NAT
.
.
.
NAT
UDP
10166
NAT
TCP
25
NAT
TCP
1
NAT
UDP
10166
NAT
10.2.35.4:50044
->
Forward
10.2.35.4:50044
10.2.25.1:50041 ->
-> 100.64.100.73:7424
140.1.41.1:63
Forward
source
10.2.25.1:50041
172.28.43.1:4502
->
-> 100.64.100.73:7161
140.1.28.1:80
Forward
source
140.1.44.1:63
source
172.28.43.1:4502
-> 100.64.100.232:3566
140.1.7.1:63
-> 100.64.100.73:7526
Forward
dest
100.64.100.73:7526
172.28.18.1:4771
->
source
source
172.28.18.1:4771
->
10.2.41.7:50007
140.1.11.1:80
Forward
-> 100.64.100.232:3834
10.2.35.7:50047
10.2.6.2:50052 ->
-> 100.64.100.73:7427
140.1.2.1:63
Forward
source
10.2.6.2:50052
172.28.2.1:45326 ->
-> 100.64.100.73:6069
140.1.29.1:25
Forward
source
172.28.2.1:45326
10.4.32.1:28362 ->
-> 100.64.100.237:9653
140.1.41.1:143
Forward
source
-> 100.64.100.237:7450
140.1.42.1:63
Forward
10.4.32.1:28362
10.2.25.2:50042 ->
source
10.2.25.2:50042
->
100.64.100.73:7163
Configuring the Router ID for the Internet Gateway

Step-by-Step
Procedure
142
1.

[edit]
Configuring Routing Policies on the Internet Gateway

Step-by-Step
Procedure
Figure 61: Routing Policy Configuration on the Internet Gateways
1.
Configure a policy that is used to advertise default static routes.

[edit]
2.
Configure a policy condition for use in BGP export policies. This policy condition is
based on the existence of 172.31.254.8/30 routes in the SFW-NAT-SERVICES.inet.0
routing table.
[edit]
edit policy-options condition LINK-to-WANAGG
set if-route-exists 172.31.254.8/30
set if-route-exists table SFW-NAT-SERVICES.inet.0
3.
Configure a policy that is used for static routes received from 100.64.100.0/24 (the
address used for source NAT) that meet the condition above.
[edit]
edit policy-options policy-statement ADV-NAT-BLOCK
set term nat from protocol static
set term nat from route-filter 100.64.100.0/24 exact
143
set term nat from condition LINK-to-WANAGG

set term nat then next-hop self
set term nat then accept
4.
Configure a policy that is used to reject routes from the Aggregation Hub 2 block of
addresses (192.0.2.0/24).
[edit]
edit policy-options policy-statement BLOCK_TO-HEAD-END2_BLOCK
5.
a. Configure aggregate routes for traffic to the VPN termination router.
[edit routing-options]
set aggregate route 198.51.100.0/24
b. Configure a policy that is used to advertise the block of addresses used for source
NAT (100.64.100.0/24) and the Aggregation Hub 1 block of addresses

(198.51.100.0/24) used for destination NAT to the Internet.
[edit]
edit policy-options policy-statement HEAD1-RANGE
set term 1 from protocol aggregate
set term 2 from condition LINK-to-WANAGG
6.
Configure a policy that is used to reject all routes.

[edit]
edit policy-options policy-statement DENY_ALL
set then reject
7.
Configure a prefix list and a routing policy that are used to prevent martian routes
from being installed into the routing table.
[edit]
edit policy-options prefix-list RFC1918
set 10.0.0.0/8
set 172.16.0.0/12
set 175.16.0.0/12
set 192.168.0.0/16
[edit]
edit policy-options policy-statement MARTIANS
set term 1 from prefix-list-filter RFC1918 orlonger
8.
of the Internet edge router to be advertised as the next-hop address for BGP traffic.
[edit]
144

9.
of the Internet edge router to be advertised as the next-hop address for BGP traffic.
[edit]
10.
Configure a policy that is used to set the local route preference to 200.
[edit]
edit policy-options policy-statement SET_LOCAL_PREF
set then local-preference 200
set then accept
Configuring BGP Peer Groups on the Internet Gateway

Step-by-Step
Procedure
1.
Configure the AS number for the Internet edge router.

[edit]
2.
Create an EBGP group to the Internet service provider.

The neighbor is the address of the Internet service provider.
The MARTIANS import policy prevents martian routes received from the Internet
The BLOCK_TO-HEAD-END2_BLOCK import policy prevents routes advertised from
the Aggregation Hub 2 block of addresses (192.0.2.0/24).
The SET_LOCAL_PREF import policy sets the local preference of routes to 200 to
give BGP routes to Aggregation Hub 1 a preference over routes to Aggregation Hub
2.
The HEAD1-RANGE export policy advertises the enterprise block of addresses used
for source NAT (100.64.100.0/24) and the Aggregation Hub 1 block of addresses
[edit]
edit protocols bgp group EBGP_To_AS_169
set type external
set import MARTIANS
set import BLOCK_TO-HEAD-END2_BLOCK
set import SET_LOCAL_PREF
set export HEAD1-RANGE
set peer-as 169
set neighbor 198.51.100.1 authentication-key "$9$-abY4UjkTznO1XNdbg4Qz3"
3.
Create an IBGP peer group to the Internet edge router at Aggregation Hub 2.
145
The ADV-NAT-BLOCK export policy sends routes that are currently being advertised
on Hub 1 to Hub 2. If Hub 1 goes down, Hub 2 has the current block of addresses that
are being advertised on the Internet edge.
The DENY_ALL export policy prevents all other routes from being advertised.
[edit]
edit protocols bgp group TO-HEAD-END2
set type internal
set export ADV-NAT-BLOCK
set export DENY_ALL
set peer-as 2222
set neighbor 172.31.254.6 authentication-key "$9$fQ3/uOIreMVwqP5Q6/lev"
Results
After Aggregation Hub 2 is configured, verify BGP.

1.
Verify BGP peering to the Internet service provider gateway (191.15.100.1) and to the
Internet edge router at Aggregation Hub 2 (172.31.254.6).
user@iedge1> show bgp summary
Table
History Damp State
Pending
inet.0
2
1
0
0
0
0
Peer
AS
InPkt
OutPkt
OutQ
Flaps Last Up/Dwn
172.31.254.6
2222
6007
6585
0
1 2d 1:32:53
0/1/1/0
0/0/0/0
198.51.100.1
169
6599
6602
0
0 2d 1:39:58
1/1/1/0
0/0/0/0
2. Verify BGP groups.

user@iedge1> show bgp group summary
Group
Type
Peers
Established
Active/Received/Accepted/Damped
EBGP_To_AS_169 External 1
1
Trace options: state, normal, hfrr-route
Trace file: /var/log/log-bgp size 1048576 files 5
inet.0
: 1/1/1/0
TO-HEAD-END2 Internal
1
1
Trace options: state, normal, hfrr-route
Trace file: /var/log/log-bgp size 1048576 files 5
inet.0
: 0/1/1/0
Groups: 2
Peers: 2
External: 1
Internal: 1
Down peers: 0
Flaps: 1
inet.0
: 1/2/2/0 External: 1/1/1/0 Internal: 0/1/1/0
SFW-NAT-SERVICES.mdt.0: 0/0/0/0 External: 0/0/0/0 Internal: 0/0/0/0
3. Verify that routes are being received from and advertised to the Internet service
provider.
user@iedge1> show route receive-protocol bgp 198.51.100.1
inet.0: 20 destinations, 21 routes (20 active, 0 holddown, 0 hidden)
Prefix
Nexthop
MED
Lclpref
AS path
* 0.0.0.0/0
198.51.100.1
169 I
SFW-NAT-SERVICES.inet.0: 6204 destinations, 6204 routes (6204 active, 0
holddown, 0 hidden)
146
inet6.0: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)

SFW-NAT-SERVICES.inet6.0: 2 destinations, 2 routes (2 active, 0 holddown, 0
hidden)
user@iedge1> show route advertising-protocol bgp 198.51.100.1
Prefix
Nexthop
MED
Lclpref
AS path
* 198.51.100.0/24
Self
I
* 100.64.100.0/24
Self
I
Prefix
Nexthop
MED
Lclpref
AS path
* 198.51.100.0/24
Self
I
* 100.64.100.0/24
Self
I
4. Verify that routes are being received from and advertised to the Internet edge router
Prefix
Nexthop
MED
Lclpref
AS path
0.0.0.0/0
172.31.254.6
200
269 I
holddown, 0 hidden)
SFW-NAT-SERVICES.inet6.0: 2 destinations, 2 routes (2 active, 0 holddown, 0
hidden)
Prefix
Nexthop
MED
Lclpref
AS path
* 100.64.100.0/24
Self
100
I
5. Verify that the inet.0 routing table is showing proper routes.
user@iedge1> show route table inet.0
0.0.0.0/0
10.205.0.0/16
10.209.0.0/16
10.212.0.0/16
10.216.32.0/20
10.216.36.214/32
172.17.0.0/16
*[BGP/170] 2d 02:33:01, localpref 200

AS path: 169 I, validation-state: unverified
> to 198.51.100.1 via ge-1/2/5.0
[BGP/170] 2d 02:25:56, localpref 200
> to 172.31.254.6 via xe-0/0/0.0
*[Static/5] 2d 09:48:06
> to 10.216.47.254 via fxp0.0
*[Static/5] 2d 09:48:06
> to 10.216.47.254 via fxp0.0
*[Static/5] 2d 09:48:06
> to 10.216.47.254 via fxp0.0
*[Direct/0] 2d 09:48:06
> via fxp0.0
*[Local/0] 2d 09:48:09
Local via fxp0.0
*[Static/5] 2d 02:35:53
147
> to 10.216.47.254 via fxp0.0

*[Direct/0] 2d 02:26:04
> via xe-0/0/0.0
172.31.254.5/32
*[Local/0] 2d 02:35:53
Local via xe-0/0/0.0
172.31.254.50/32
*[Static/5] 2d 02:27:44
> to 172.31.255.54 via ge-1/2/6.1
172.31.255.1/32
*[Direct/0] 2d 02:35:53
> via lo0.0
172.31.255.52/30
*[Direct/0] 2d 02:27:44
> via ge-1/2/6.1
172.31.255.53/32
*[Local/0] 2d 02:33:10
Local via ge-1/2/6.1
198.51.100.0/24
*[Aggregate/130] 2d 02:35:53
Reject
198.51.100.0/30
*[Direct/0] 2d 02:33:02
> via ge-1/2/5.0
198.51.100.2/32
*[Local/0] 2d 02:33:10
198.51.100.4/30
*[Direct/0] 1d 21:39:11
> via ge-1/2/6.0
198.51.100.5/32
*[Local/0] 1d 21:39:11
198.51.100.224/32 *[Static/1] 2d 02:35:52
Service to NAT-HOSTED-WEB
100.64.100.0/24
*[Static/1] 2d 02:35:52
> via sp-3/0/0.2
172.31.254.4/30
148
Configuring Routing for WAN Aggregation Services on the Internet Gateway

Step-by-Step
Procedure
This section focuses on the configuration of routing as shown in figure

Figure 62: Routing Protocol Design at the Internet Gateway
149
This routing instance is used to route traffic to the Internet. NAT and stateful firewall is
applied to this traffic.
1.
Create the routing instance, add the services interface that is used for NAT, and
then add the interface to the WAN aggregation router, and add the loopback
interface.
[edit]
edit routing-instances SFW-NAT-SERVICES
set interface xe-1/0/1.0
2.
Create a static default route used for outbound NAT traffic.

[edit routing-instances SFW-NAT-SERVICES]
set routing-options static route 0.0.0.0/0 next-hop sp-3/0/0.1
3.
Add the ADV_DEFAULT routing policy as an export policy.

This policy causes the default static route to be advertised to the WAN aggregation
router.
[edit]
edit routing-instances SFW-NAT-SERVICES protocols ospf
set export ADV_DEFAULT
150
4.
Create a backbone area, and add the Ethernet interface to the WAN aggregation
router.
MD5 authentication uses an encoded MD5 checksum that is included in the
transmitted packet. Both the receiving and transmitting routing devices must have
the same MD5 key. You define an MD5 key for each interface. If MD5 is enabled on
an interface, that interface accepts routing updates only if MD5 authentication
succeeds. Otherwise, updates are rejected. The routing device accepts only OSPFv2
packets sent using the same key ID that is defined for that interface.
[edit]
edit routing-instances SFW-NAT-SERVICES protocols ospf area 0.0.0.0
"$9$n/Wd9t0Ecr8XN4aQ369u0LX7"
5.
Configure high availability on the link to the WAN aggregation router.

[edit routing-instances SFW-NAT-SERVICES protocols ospf area 0.0.0.0]
Step-by-Step
Procedure
After WAN aggregation Routing is configured and committed, use the following commands
to verify the configuration was successful.
1.
Verify neighbors for the SFW-NAT-SERVICES routing instance.

user@iedge1> show ospf neighbor instance SFW-NAT-SERVICES
Address
Interface
State
ID
172.31.254.10
xe-1/0/1.0
Full
172.31.255.2
31
2.
Pri Dead
128
Verify routes in the SFW-NAT-SERVICES routing table. The routing table includes
routes that are advertised by the data center and the branches.
user@iedge1> route table SFW-NAT-SERVICES.inet.0
holddown, 0 hidden)
0.0.0.0/0
2.2.0.0/30
10.15.0.0/28
10.15.0.16/28
10.15.0.32/28
10.15.0.48/28
10.15.0.64/28
10.15.0.80/28
10.15.0.96/28
10.15.0.112/28
*[Static/5] 2d 03:13:25
> via sp-3/0/0.1
*[OSPF/150] 1d 22:16:42, metric 21,
> to 172.31.254.10 via xe-1/0/1.0
*[OSPF/150] 2d 03:00:34, metric 21,
> to 172.31.254.10 via xe-1/0/1.0
*[OSPF/150] 2d 02:59:53, metric 21,
> to 172.31.254.10 via xe-1/0/1.0
*[OSPF/150] 2d 02:59:47, metric 21,
> to 172.31.254.10 via xe-1/0/1.0
*[OSPF/150] 2d 02:59:42, metric 21,
> to 172.31.254.10 via xe-1/0/1.0
*[OSPF/150] 2d 02:59:25, metric 21,
> to 172.31.254.10 via xe-1/0/1.0
*[OSPF/150] 2d 02:59:07, metric 21,
> to 172.31.254.10 via xe-1/0/1.0
*[OSPF/150] 2d 02:58:41, metric 21,
> to 172.31.254.10 via xe-1/0/1.0
*[OSPF/150] 2d 02:58:23, metric 21,
tag 100
tag 100
tag 100
tag 100
tag 100
tag 100
tag 100
tag 100
tag 100
151
> to 172.31.254.10 via xe-1/0/1.0

. . .
172.31.255.8/32
172.31.255.15/32
224.0.0.5/32
3.
*[OSPF/10] 18:25:26, metric 21

> to 172.31.254.10 via xe-1/0/1.0
*[OSPF/10] 18:25:26, metric 1
> to 172.31.254.10 via xe-1/0/1.0
*[OSPF/10] 22:49:25, metric 1
MultiRecv
Verify BFD.
user@iedge1> show bfd session
Address
Multiplier
172.31.254.10
State
Interface
Time
Up
xe-1/0/1.0
1.500
Interval
0.500
1 sessions, 1 clients
Cumulative transmit rate 2.0 pps, cumulative receive rate 2.0 pps
Configuring High Availability on the Internet Gateway

Step-by-Step
Procedure
1.
Configure nonstop active routing.

a. Enable graceful Routing Engine switchover.
[edit]
edit chassis redundancy
set graceful-switchover
b. Enable nonstop routing.
[edit]
set nonstop-routing
Configuring CoS on the Internet Gateway

Step-by-Step
Procedure
CoS is used on the Internet edge to separate Internet-connected branch traffic on IPsec
tunnels from public Internet traffic.
1.
Assign fowarding classes for the branches, the Internet, and network control traffic
to transmission queues.
[edit]
set queue 4 BRANCH
set queue 0 INTERNET
2.

[edit]
152
set BRANCH transmit-rate percent 70

set BRANCH priority high
set INTERNET transmit-rate remainder
set INTERNET priority low
set Network_Control transmit-rate percent 4
set Network_Control transmit-rate rate-limit
set Network_Control priority strict-high
3.

[edit]
edit class-of-service scheduler-maps ISP-LINK-SCHEDULER
set forwarding-class BRANCH scheduler BRANCH
set forwarding-class INTERNET scheduler INTERNET
set forwarding-class Network_Control scheduler Network_Control
4.
Modify the queue assignment and DSCP code point for network control (host)
traffic that is generated by the Routing Engine and sent to the Packet Forwarding
Engine. This configuration does not affect transit traffic.
[edit]
edit class-of-service host-outbound-traffic
set forwarding-class Network_Control
set dscp-code-point cs7
5.
Configure a traffic control profile for traffic to the Internet service provider.
[edit]
edit class-of-service traffic-control-profiles TO-ISP1
set scheduler-map ISP-LINK-SCHEDULER
6.
Apply the traffic control profile to the interface to the ISP.

[edit]
set output-traffic-control-profile TO-ISP1
7.
Apply CoS to the services interface for traffic sent to the Internet.
[edit]
edit class-of-service interfaces sp-3/0/0
set unit 2 forwarding-class INTERNET
8.
Apply forwarding classes to the interface to the VPN termination router.

Apply the BRANCH forwarding class to the interface to the VPN termination router
that handles IPsec tunnel traffic from Internet-connected branches.
Unit 0 sends IPsec tunnel traffic to the VPN termination router.
Unit 1 sends hosted Web server traffic to the VPN termination router.
[edit]
set unit 0 forwarding-class BRANCH
set unit 1 forwarding-class INTERNET
153
Results
After class-of-service configuration is complete and committed, use the following

commands to verify successful configuration:
1.
Verify CoS on the interfaces. For example:

user@iedge1> show interfaces ge-1/2/5 extensive
Physical interface: ge-1/2/5, Enabled, Physical link is Up
Description: --- To Public ISP link ( Navami-PE1 ge-1/2/0 ) --Link-level type: Ethernet, MTU: 1514, Speed: 1000mbps, BPDU Error: None,
MAC-REWRITE Error: None, Loopback: Disabled, Source filtering: Disabled,
Flow control: Enabled, Auto-negotiation: Enabled, Remote fault: Online
Device flags
: Present Running
Link flags
: None
CoS queues
Schedulers
: 0
Hold-times
Current address: 2c:21:72:b2:99:f3, Hardware address: 2c:21:72:b2:99:f3
Last flapped
: 2013-06-18 08:06:12 PDT (22:58:50 ago)
Traffic statistics:
Input bytes :
4229151344160
561619168 bps
Output bytes :
4220510907769
546579856 bps
Input packets:
12356255054
202845 pps
Output packets:
12804873648
208178 pps
Input bytes :
0
Output bytes :
0
Input packets:
0
Output packets:
0
Input bytes :
0
Output bytes :
0
Input packets:
0
Output packets:
0
Input errors:
0,
Resource errors: 0
Output errors:
Carrier transitions: 1, Errors: 0, Drops: 0, Collisions: 0, Aged packets:
0, FIFO errors: 0, HS link CRC errors: 0, MTU errors: 0, Resource errors: 0
Queue counters:
Dropped packets
0 INTERNET
2150324114
2150324114
1 expedited-fo
2 assured-forw
3 network-cont
10654624152
10654624152
6930
6930
0
0
0
0
4 BRANCH
0
7 Network_Cont
0
Queue number:
0
154

INTERNET
1
expedited-forwarding
2
assured-forwarding
3
network-control
4
BRANCH
7
Network_Control
MAC statistics:
Receive
Transmit
Total octets
4229139655321
4220500361901
Total packets
12356221175
12804839382
Unicast packets
12356221135
12804839353
Broadcast packets
40
37
Multicast packets
0
0
CRC/Align errors
0
0
FIFO errors
0
0
MAC control frames
0
0
MAC pause frames
0
0
Oversized frames
0
Jabber frames
0
Fragment frames
0
VLAN tagged frames
0
Code violations
0
Total errors
0
0
Filter statistics:
Input packet count
12355818357
0
Input DA rejects
0
Input SA rejects
0
Output packet count
12804425207
0
0
Autonegotiation information:
Negotiation status: Complete
Link partner:
Link mode: Full-duplex, Flow control: Symmetric/Asymmetric, Remote
fault: OK
Local resolution:
Flow control: Symmetric, Remote fault: Link OK
Destination slot: 0 (0x00)
CoS information:
Direction : Output
CoS transmit queue
Bandwidth
Buffer Priority
Limit
%
bps
%
usec
0 INTERNET
20
160000000
r
0
low
none
4 BRANCH
79
632000000
r
0
high
none
7 Network_Control
1
8000000
r
0 strict-high
exact
Logical interface ge-1/2/5.0 (Index 346) (SNMP ifIndex 6631) (Generation
159)
18 bytes
:
18 bytes
Traffic statistics:
155
Input bytes :
4229151344160
Output bytes :
4220510866189
Input packets:
12356255054
Output packets:
12804873648
Local statistics:
Input bytes :
394289
Output bytes :
656703
Input packets:
6203
Output packets:
6930
Transit statistics:
Input bytes :
4229150949871
561619168 bps
Output bytes :
4220510209486
546579856 bps
Input packets:
12356248851
202845 pps
Output packets:
12804866718
208178 pps
Input Filters: ipv4_sample
Destination: 198.51.100.0/30, Local: 198.51.100.2, Broadcast:
198.51.100.3, Generation: 151
Protocol multiservice, MTU: Unlimited, Generation: 196, Route table: 0
2. Verify the separation of Internet traffic and branch traffic into different queues on
traffic sent toward the Internet.

user@iedge1> show interfaces queue ge-1/2/5 egress
Interface index: 173, SNMP ifIndex: 770
Description: --- To Public ISP link ( Navami-PE1 ge-1/2/0 ) --Forwarding classes: 16 supported, 6 in use
Queue: 0, Forwarding classes: INTERNET
Queued:
Packets
:
2150725561
36826 pps
Bytes
:
725518691918
96455936 bps
Transmitted:
Packets
:
2150725561
36826 pps
Bytes
:
725518691918
96455936 bps
Tail-dropped packets :
0
RED-dropped packets :
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
RED-dropped bytes
:
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
Queue: 1, Forwarding classes: expedited-forwarding
Queued:
Packets
:
0
Bytes
:
0
Transmitted:
Packets
:
0
Bytes
:
0
0
0
Low
:
0
Medium-low
:
0
156
0
0
0
0
0
0
0
0
0
0
0
pps
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
0 pps
0 bps
0
0
0
0
0
0
pps
bps
pps
pps
pps
pps
Medium-high
:
0
High
:
0
RED-dropped bytes
:
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
Queue: 2, Forwarding classes: assured-forwarding
Queued:
Packets
:
0
Bytes
:
0
Transmitted:
Packets
:
0
Bytes
:
0
0
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
RED-dropped bytes
:
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
Queue: 3, Forwarding classes: network-control
Queued:
Packets
:
0
Bytes
:
0
Transmitted:
Packets
:
0
Bytes
:
0
0
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
RED-dropped bytes
:
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
0
0
0
0
0
0
0
pps
pps
bps
bps
bps
bps
bps
0 pps
0 bps
0
0
0
0
0
0
0
0
0
0
0
0
0
pps
bps
pps
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
0 pps
0 bps
0
0
0
0
0
0
0
0
0
0
0
0
0
pps
bps
pps
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
0
0
0
0
0
0
0
0
0
pps
pps
pps
pps
pps
pps
bps
bps
bps
Queue: 4, Forwarding classes: BRANCH

Queued:
Packets
:
10656517898
171242 pps
Bytes
:
3751917751504
482972416 bps
Transmitted:
Packets
:
10656517898
171242 pps
Bytes
:
3751917751504
482972416 bps
Tail-dropped packets
RED-dropped packets
Low
Medium-low
Medium-high
High
RED-dropped bytes
Low
Medium-low
:
:
:
:
:
:
:
:
:
0
0
0
0
0
0
0
0
0
157
Medium-high
:
0
High
:
0
Queue: 7, Forwarding classes: Network_Control
Queued:
Packets
:
6932
Bytes
:
823262
Transmitted:
Packets
:
6932
Bytes
:
823262
0
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
RED-dropped bytes
:
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
158
0 bps
0 bps
0 pps
352 bps
0
352
0
0
0
0
0
0
0
0
0
0
0
pps
bps
pps
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
CHAPTER 6
Base Configuration for Aggregation Hub

2
Requirements
MX480 3D Universal Edge Router with the following MICs and PICs:
Four MultiService DPC PICs MS-DPC-PIC
Four 2x 10GE XFP PICs
Two 10x 1GE(LAN)SPF PICs
Overview
The backup aggregation hub features an MX480 configured virtual routing instances for
each of the WAN aggregation hub functional roles. The topology of Aggregation Hub 2
is shown in Figure 64 on page 160.
Topology
This section focuses on configuration of the nodes in the blue highlighted area
159
Configuring High Availability and Load Balancing on Aggregation Hub 2

Configuring High Availability at Aggregation Hub 2
Step-by-Step
Procedure
To configure high availability at the hardware level of Aggregation Hub 2, use the following
commands:
1.
Configure nonstop active routing.

a. Enable graceful Routing Engine switchover.
[edit]
edit chassis redundancy
set graceful-switchover
b. Enable nonstop routing.
[edit]
set nonstop-routing
Configuring Per-Packet Load Balancing on Aggregation Hub 2

Step-by-Step
Procedure
To configure per-packed load balancing at the hardware level on Aggregation Hub 2, use
the following commands:
1.
Configure a load-balancing policy called PLBB.

[edit]
edit policy-options policy-statement PPLB
set then load-balance per-packet
2.
160
Apply the policy configured to routes exported from the routing table to the
forwarding table.
[edit]
set forwarding-table export PPLB
161
Configuring the WAN Aggregation Role at Aggregation Hub 2
Configuring the Router ID on the WAN Aggregation Role on page 162
Configuring the Static Routes on the WAN Aggregation Role on page 162
Configuring Transport on the WAN Aggregation Role on page 162
Configuring BGP Routing Policies on the WAN Aggregation Role on page 164
Configuring Fully-Meshed IBGP Peer Groups on the WAN Aggregation Router on page 165
Configuring the OSPF Backbone on the WAN Aggregation Role on page 167
Configuring Multicast for the WAN Aggregation Role at Aggregation Hub 2 on page 169
Configuring Class of Service on the WAN Aggregation Role on page 171
Configuring the Router ID on the WAN Aggregation Role

Step-by-Step
Procedure
Configure a routing ID.

[edit]
Configuring the Static Routes on the WAN Aggregation Role

Step-by-Step
Procedure
1.
Configure an aggregate route for the block of enterprise addresses at Hub 2.

[edit]
2.
Create a default static route for IPv6.

[edit]
set rib inet6.0 static route ::/0 reject
3.
Configure a static route to the inside service interface for NAT.

[edit]
set static route 0.0.0.0/0 qualified-next-hop sp-1/0/0.16001 preference 200
Configuring Transport on the WAN Aggregation Role

Step-by-Step
Procedure
1.
Configure the interface to the WAN aggregation router at Aggregation Hub 1.

displayed for each logical interface with the show interfaces command under the
Ingress account overhead and Egress account overhead fields.
[edit]
set description "--- Link to WAN-AGG hub 1 ---"
162


2.
Configure the interface to the Data Center.

[edit]
set description " --- To DC-ACCESS router --- "
3.
Create a logical tunnel interface, and enable hierarchical scheduling.

We are using the lt interface to apply CoS to egress traffic sent over GRE tunnels.
You must commit hierarchical scheduler configuration under the logical tunnel
interface before you add the CoS configuration to the interface.
[edit]
edit interfaces lt-5/1/0
set hierarchical-scheduler
4.
Configure the logical tunnel interface to the VPN termination router.

[edit]
edit interfaces lt-5/1/0
set unit 45 description "--- To VPN router WAN-GRE VR ---"
set unit 45 encapsulation frame-relay
set unit 45 dlci 1
set unit 45 peer-unit 54
163
NOTE: This configuration is a workaround using pre-Junos OS 13.3. If

you are deploying Junos OS 13.3 or later, this unit (unit 45 in this example)
is not needed. Only one LT pair is required for routing between the
WAN-AGG and WAN GRE routers.
5.
Configure the services interface that connects to the SFW-NAT-SERVICES routing

instance. It is used to apply NAT to branch traffic that accesses hosted services.
[edit]
edit interfaces sp-1/0/0 unit 16001
set description "--- Branch to WWW NAT service inside interface ---"
set family inet
set service-domain inside
Configuring BGP Routing Policies on the WAN Aggregation Role

Step-by-Step
Procedure
1.
Configure a routing policy that is used to advertise default static IPv4 routes,
including routes received from OSPF.
[edit]
set term 1 from protocol ospf
2.
Configure a routing policy that is used to advertise default static IPv6 routes.
[edit]
3.
Configure a next-hop self routing policy for IPv4 traffic that causes the loopback
address to be advertised as the next hop for BGP traffic.
[edit]
4.
[edit]
164

5.
Configure a policy that is used to reject all traffic.

[edit]
set then reject
Configuring Fully-Meshed IBGP Peer Groups on the WAN Aggregation Router

Step-by-Step
Procedure
At the aggregation hubs, we have a full IBGP mesh with the WAN aggregation routers
and the WAN-GRE virtual routers on Aggregation Hub 1 and Aggregation Hub 2.
1.
Configure the AS number for BGP.

[edit]
2.
The ADV_DEFAULT export policy causes the default static route to be advertised.
[edit]
edit protocols bgp group IBGP-MESH
set type internal
set export NHS
set neighbor 172.31.255.2 authentication-key "$9$63fICpOhSlLx-oJzn/C0OXxN"
set neighbor 172.31.255.3 authentication-key "$9$jxkm5n/A1Rc8XZDikf5IRh"
set neighbor 172.31.255.6 authentication-key "$9$t1cD01ElKW-VsUj/Ap0REdVw"
3.
(2001:DB8:255::3).
(2001:DB8:255::6).
[edit]
edit protocols bgp group IBGP-MESH-v6
165
set type internal

set export NHS6
set neighbor 2001:DB8:255::2 authentication-key "$9$H.fQ/CpRhyX7Uik.TQEhS"
"$9$nvyu9t0Ecr8XN4aQ369u0LX7"
set neighbor 2001:DB8:255::6 authentication-key "$9$qPTFCt0hSl7-jk.PzFcSr"
Results
Verify the IBGP mesh groups.

1.
Verify the IBGP-Mesh group.

user@hub2> bgp summary group IBGP-Mesh
Table
History Damp State
Pending
inet.0
26386
26384
0
0
0
0
inet6.0
25393
25393
0
0
0
0
Peer
AS
InPkt
OutPkt
OutQ
Flaps Last Up/Dwn
172.31.255.3
65530
2007
3369
0
0
8:04:27
5000/5000/5000/0
0/0/0/0
172.31.255.5
65530
995
3235
0
0
8:02:26
1/1/1/0
0/0/0/0
172.31.255.6
65530
2508
3237
0
0
8:02:17
1000/1001/1001/0
0/0/0/0
2. Verify the IBGP-Mesh-V6 group.

user@hub2> bgp summary group IBGP-Mesh-v6
Table
History Damp State
Pending
inet.0
26386
26384
0
0
0
0
inet6.0
25393
25393
0
0
0
0
Peer
AS
InPkt
OutPkt
OutQ
Flaps Last Up/Dwn
2001:DB8:255::3
65530
2000
3029
0
0
8:05:53
Establ
inet6.0: 4000/4000/4000/0
2001:DB8:255::5
65530
997
2987
0
0
8:02:35
Establ
inet6.0: 1/1/1/0
2001:DB8:255::6
65530
2462
2986
0
0
8:02:27
Establ
inet6.0: 1000/1000/1000/0
166
Configuring the OSPF Backbone on the WAN Aggregation Role

Step-by-Step
Procedure
Figure 65: OSPF Design at the Aggregation Hubs
1.
Configure routing policies that are used to export default BGP routes into OSPF.
These policies are used to advertise all routes except 0.0.0.0/0.
a. Configure a policy for IPv4.
[edit]
set term 1 then tag 100
b. Configure a policy for IPv6.
[edit]
167

2.

a. Set the external preference for OSPF routes to 175.
[edit]
edit protocols ospf
set protocols ospf external-preference 175
b. Add the BGP2OSPF export policy, which exports BGP routes to OSPF.
[edit]
edit protocols ospf
set protocols ospf export BGP2OSPF
c. Create a backbone area, and add the loopback interface (lo0.2), the interface
to the WAN aggregation router on Aggregation Hub 1 (ge-4/2/1.0),the interface

to the Data Center (xe-4/0/0.0), and the logical tunnel interface to the VPN
termination role (lt-5/1/0.45).
[edit]
set interface ge-4/2/1.0 authentication md5 0 key "$9$H.fQ/CpRhyX7Uik.TQEhS"
"$9$t/h-01ElKW-VsUj/Ap0REdVw"
set interface lt-5/1/0.45 interface-type p2p
set interface lt-5/1/0.45 authentication md5 0 key
"$9$Yz4JUqm569thSVs24GU/9A"
set interface lt-5/1/0.45 bfd-liveness-detection minimum-interval 500
set interface lt-5/1/0.45 bfd-liveness-detection multiplier 3
3.

[edit]
set protocols ospf external-preference 175
b. Add the BGP2OSPF export policy, which exports BGP routes to OSPF.
[edit]
168

set protocols ospf export BGP2OSPF-V6
c. Create a backbone area, and add the loopback interface to the backbone area
(lo0.2), the interface to the WAN aggregation router on aggregation hub

(ge-4/2/1.0), the interface to the Data Center (xe-4/0/0.0), and the logical
tunnel interface to the VPN termination role (lt-5/1/0.45).
[edit]
set interface lo0.2
set interface xe-4/0/0.0 priority 200
Results
Verify OSPF neighbors.

1.
Verify OSPF IPv4 neighbors.

user@hub2> show ospf neighbor
Address
Interface
172.31.254.41
ge-4/2/1.0
172.31.254.22
lt-5/1/0.45
172.31.242.10
xe-4/0/0.0
State
Full
Full
Full
ID
172.31.255.2
172.31.255.6
172.31.255.8
Pri
128
128
128
Dead
37
39
35
2. Verify the OSPF IPv6 neighbors.

user@hub2> show ospf3 neighbor
ID
Interface
State
172.31.255.2
ge-4/2/1.0
Full
Neighbor-address fe80::5e5e:abff:fe0e:421a
172.31.255.6
lt-5/1/0.45
Full
Neighbor-address fe80::2a0:a552:0:36f8
172.31.255.8
xe-4/0/0.0
Full
Neighbor-address fe80::aad0:e5ff:fe5c:2d03
Pri
128
Dead
30
128
30
128
37
Configuring Multicast for the WAN Aggregation Role at Aggregation Hub 2

Step-by-Step
Procedure
For multicast at the aggregation hubs, we are using static rendezvous points (RPs) with
an anycast RP cluster. Loopback interfaces on the WAN aggregation routers are used as
the static rendezvous points. The WAN aggregation router on Aggregation Hub 1 is the
primary RP, and the WAN aggregation role on Aggregation Hub 2 is the secondary RP.
We are using MSDP to connect the two multicast routing domains.
1.
Configure the loopback interface that is used as the static RP.

The primary address is the router ID of the WAN aggregation router. Including the
primary statement selects the routers primary address from all of the preferred
addresses on all interfaces.
[edit]
169
2.
Configure the local address of the rendezvous point, which is the address of the
lo0.2 interface.
Configure the static RP. The local address is the address of the rendezvous point,
which is the address of the lo0.0 interface.
[edit]
edit protocols pim
3.
Configure multicast on the interface to the WAN aggregation router on Hub 1

(ge-4/2/1),the interface to the data center (xe-4/0/0), and the interface from the
WAN aggregation role to the VPN termination role on hub 2.
[edit]
edit protocols pim
set interface xe-4/0/0.0 mode sparse
set interface xe-4/0/0.0 version 2
set interface lt-5/1/0.45 mode sparse
set interface lt-5/1/0.45 version 2
4.
Configure MSDP
[edit]
edit protocols msdp
set peer 172.31.255.2 local-address 172.31.255.5
5.

[edit]
commit
Results
Verify that PIM and MSDP are running.

1.
Verify PIM neighbors.

user@hub2> show pim neighbors
Interface
IP
ge-4/2/1.0
4
ge-4/2/2.0
4
lt-5/1/0.45
4
xe-4/0/0.0
4
V Mode
2
2
2
2
Option
HPLGT
HPLGT
HPLGT
HPLGT
1d
1d
1d
1d
Uptime
05:56:51
06:03:11
06:03:21
06:03:23
Neighbor addr
172.31.254.41
172.31.254.37
172.31.254.22
172.31.242.10

user@hub2> show pim rps extensive
address-family INET
RP: 172.31.255.15
Mode: Sparse
170

Holdtime: 150
Device Index: 155
Subunit: 32770
Group Ranges:
224.0.0.0/4
Anycast PIM local address used: 172.31.255.5
3. Verify MSDP peers.

user@hub2> show msdp
Peer address
Local address
172.31.255.2
172.31.255.5
State
SA Count
0/0
Configuring Class of Service on the WAN Aggregation Role

Step-by-Step
Procedure
1.
a. Configure DSCP behavior aggregation (BA) for IPv4
[edit]
[edit]
[edit]
171

set queue 4 Video
set queue 5 Voice
[edit]
e. Create rewrite rules for IPv6 traffic.
[edit]
2.

[edit]
set SCH_VOICE transmit-rate rate-limit
172

3.

[edit]
edit class-of-service scheduler-maps
set MAIN-SCHD forwarding-class Voice scheduler SCH_VOICE
set MAIN-SCHD forwarding-class Video scheduler SCH_Video
set MAIN-SCHD forwarding-class Scavenger scheduler SCH_Scavenger
set MAIN-SCHD forwarding-class Network_Control scheduler SCH_Network_Control
set MAIN-SCHD forwarding-class Critical_Data scheduler SCH_Critical_Data
set MAIN-SCHD forwarding-class Bulk_Data scheduler SCH_Bulk_Data
set MAIN-SCHD forwarding-class Best_Effort scheduler SCH_Best_Effort
4.
Create a traffic control profile to be applied to interfaces to Layer 3 VPN service

providers.
[edit]
edit class-of-service traffic-control-profiles TO-MPLS-VPN2
5.
Apply CoS to the interfaces on the WAN aggregation role.

a. Apply CoS to the interface to the WAN aggregation router at Aggregation Hub
1.
[edit]
b. Apply CoS to the logical tunnel interface from the WAN aggregation role to the
VPN termination role.

[edit]
edit class-of-service interfaces lt-5/1/0
c. Apply CoS to the interface from the WAN aggregation role to the data center.
[edit]
173

6.
[edit]
7.

[edit]
commit
Results
Verify CoS.
1.
Verify CoS on the interface from the WAN aggregation role to the Data Center.
user@hub2> show class-of-service interface xe-4/0/0
Object
Name
Rewrite
DEF_DSCP_REWRITE
Rewrite
DEF_DSCP_REWRITE
Classifier
DSCP-BA
Classifier
DSCP-BA
Type
dscp
dscp-ipv6
dscp
dscp-ipv6
Index
61950
29182
961
user@hub2> show class-of-service interface xe-4/0/0 interfaces xe-4/0/0 extensive

Description: --- To DC-ACCESS router (Magha-DC-ACCESS xe-0/0/3) --Link-level type: Ethernet, MTU: 1514, LAN-PHY mode, Speed: 10Gbps, BPDU
Device flags
: Present Running
Link flags
: None
CoS queues
Schedulers
: 0
Hold-times
Current address: 2c:21:72:b2:45:28, Hardware address: 2c:21:72:b2:45:28
Last flapped
: 2013-06-18 08:22:10 PDT (1d 06:07 ago)
Traffic statistics:
Input bytes :
696478042161
61623192 bps
Output bytes :
552700386000
47177240 bps
Input packets:
2485784594
27010 pps
Output packets:
1715863144
17510 pps
Input bytes :
487226952690
Output bytes :
9501078780
Input packets:
2082166467
Output packets:
40596630
Input bytes :
0
174
Output bytes :
0
Input packets:
0
Output packets:
0
Input errors:
0,
Resource errors: 0
Output errors:
Queue counters:
Dropped packets
0 Best_Effort
781460759
781460759
1 Scavenger
2 Bulk_Data
162781915
162781050
3 Critical_Dat
233487699
233487699
191711557
191710100
229040835
229040832
117386961
117386961
0
0
865
0
4 Video
1457
5 Voice
3
6 Network_Cont
0
7 BRANCH
0
Queue number:
0
1
2
3
4
5
6
7
PCS statistics
Bit errors
Errored blocks
MAC statistics:
Total octets
Total packets
Unicast packets
Broadcast packets
Multicast packets
CRC/Align errors
FIFO errors
MAC control frames
MAC pause frames
Oversized frames
Jabber frames
Fragment frames
VLAN tagged frames
Code violations
Total errors
Filter statistics:

Best_Effort
Scavenger
Bulk_Data
Critical_Data
Video
Voice
Network_Control
BRANCH
Seconds
0
0
Receive
696482795007
2485764593
2217112622
50
268651920
0
0
0
0
0
0
0
0
0
0
Transmit
553167579530
1715850119
1715635274
50
214795
0
0
0
0
175
Input packet count

2485737551
3908
Input DA rejects
0
Input SA rejects
0
Output packet count
1715832616
0
0
CoS information:
Direction : Output
CoS transmit queue
Bandwidth
Buffer Priority
Limit
%
bps
%
usec
0 Best_Effort
95
9500000000
95
0
low
none
3 Critical_Data
5
500000000
5
0
low
none
Logical interface xe-4/0/0.0 (Index 1395) (SNMP ifIndex 2320) (Generation
1218)
18 bytes
:
18 bytes
Traffic statistics:
Input bytes :
696478046557
Output bytes :
552698822586
Input packets:
2485784657
Output packets:
1715863144
Input bytes :
487226952690
Output bytes :
9501078780
Input packets:
2082166467
Output packets:
40596630
Local statistics:
Input bytes :
195496774
Output bytes :
248807841
Input packets:
300487
Output packets:
260569
Transit statistics:
Input bytes :
696282549783
61612488 bps
Output bytes :
552450014745
47166216 bps
Input packets:
2485484170
27008 pps
Output packets:
1715602575
17509 pps
Input bytes :
487226952690
Output bytes :
9501078780
Input packets:
2082166467
Output packets:
40596630
172.31.242.255, Generation: 5332
Flags: Is-Primary
Destination: fe80::/64, Local: fe80::2e21:72ff:feb2:4528
176
Generation: 5334
Destination: 2001:DB8:242::/64, Local: 2001:DB8:242::2
Flags: Is-Primary
2. Verify CoS on the interface to the WAN aggregation at Aggregation Hub 1.

user@hub2> show class-of-service interface ge-4/2/1
Object
Name
Rewrite
DEF_DSCP_REWRITE
Rewrite
DEF_DSCP_REWRITE
Classifier
DSCP-BA
Classifier
DSCP-BA
Type
dscp
dscp-ipv6
dscp
dscp-ipv6
Index
61950
29182
961
33729
user@hub2> show interfaces ge-4/2/1 extensive

Description: --- B2B link towards WAN-AGG1 router instance(ge-1/3/2) --Link-level type: Ethernet, MTU: 1514, Speed: 1000mbps, BPDU Error: None,
Device flags
: Present Running
Link flags
: None
CoS queues
Schedulers
: 0
Hold-times
Current address: 2c:21:72:b2:45:cd, Hardware address: 2c:21:72:b2:45:cd
Last flapped
: 2013-06-18 08:23:38 PDT (1d 06:05 ago)
Traffic statistics:
Input bytes :
605850050093
54712176 bps
Output bytes :
911291177146
84840856 bps
Input packets:
1810210672
19520 pps
Output packets:
2867466982
31297 pps
Input bytes :
34875993486
Output bytes :
508977664108
Input packets:
149026476
Output packets:
2175121540
Input bytes :
0
Output bytes :
0
Input packets:
0
Output packets:
0
Input errors:
0,
Resource errors: 0
Output errors:
packets: 0, FIFO errors: 0, HS link CRC errors: 0, MTU errors: 0, Resource
177
errors: 0
Queue counters:
0 Best_Effort
1 Scavenger
2811989467
Dropped packets
2809440349
0
2549118
0
0
2 Bulk_Data
121015
75906
45109
3 Critical_Dat
549935
534913
15022
4 Video
35934
2501
33433
5 Voice
55753142
55676927
76215
6 Network_Cont
1763966
1739491
24475
7 BRANCH
0
0
0
Queue number:
0
Best_Effort
1
Scavenger
2
Bulk_Data
3
Critical_Data
4
Video
5
Voice
6
Network_Control
7
BRANCH
MAC statistics:
Receive
Transmit
Total octets
606408693651
911360397392
Total packets
1810197201
2867443546
Unicast packets
1809906466
2867147929
Broadcast packets
45
54
Multicast packets
290690
295563
CRC/Align errors
0
0
FIFO errors
0
0
MAC control frames
0
0
MAC pause frames
0
0
Oversized frames
0
Jabber frames
0
Fragment frames
0
VLAN tagged frames
0
Code violations
0
Total errors
0
0
Filter statistics:
Input packet count
1810177681
0
Input DA rejects
0
Input SA rejects
0
Output packet count
2867412207
0
0
Link partner:
fault: OK
178
Local resolution:
CoS information:
Direction : Output
CoS transmit queue
Bandwidth
Limit
%
bps
%
0 Best_Effort
95
950000000
95
none
3 Critical_Data
5
50000000
5
none
Buffer Priority
usec
0
low
low

1220)
18 bytes
:
18 bytes
Traffic statistics:
Input bytes :
605850065708
Output bytes :
911288607034
Input packets:
1810210929
Output packets:
2867466982
Input bytes :
34875993486
Output bytes :
508977664108
Input packets:
149026476
Output packets:
2175121540
Local statistics:
Input bytes :
205281726
Output bytes :
212911485
Input packets:
543251
Output packets:
428352
Transit statistics:
Input bytes :
605644783982
54704064 bps
Output bytes :
911075695549
84831080 bps
Input packets:
1809667678
19517 pps
Output packets:
2867038630
31294 pps
Input bytes :
34875993486
Output bytes :
508977664108
Input packets:
149026476
Output packets:
2175121540
172.31.254.43, Generation: 5340
Destination: fe80::/64, Local: fe80::2e21:72ff:feb2:45cd
Generation: 5342
Destination: 2001:DB8:254:3::/64, Local: 2001:DB8:254:3::2
179
3. Verify CoS on the logical tunnel interface to the VPN termination role.
user@hub2> show class-of-service interface lt-5/1/0
Physical interface: lt-5/1/0, Index: 192
Logical interface: lt-5/1/0.1, Index: 1402
Object
Name
Traffic-control-profile SMALL-BRANCH
Type
Output
Index
14334
Type
dscp
dscp-ipv6
dscp
dscp-ipv6
Index
61950
29182
961
33729

Object
Name
Rewrite
DEF_DSCP_REWRITE
Rewrite
DEF_DSCP_REWRITE
Classifier
DSCP-BA
Classifier
DSCP-BA
user@hub2> show interfaces lt-5/1/0.45 extensive

Logical interface lt-5/1/0.45 (Index 1389) (SNMP ifIndex 817) (Generation
1212)
Description: --- To VPN router WAN-GRE VR (HUb2 lt-5/1/0.54 ) --Flags: Point-To-Point SNMP-Traps 0x4000 DLCI 1 Encapsulation: FR-NLPID
Traffic statistics:
Input bytes :
799405681973
Output bytes :
607915807050
Input packets:
2139695044
Output packets:
1727113787
Input bytes :
9132392547
Output bytes :
12068754070
Input packets:
39035848
Output packets:
51566415
Local statistics:
Input bytes :
115563088
Output bytes :
242410049
Input packets:
195148
Output packets:
241608
Transit statistics:
Input bytes :
799290118885
81228992 bps
Output bytes :
607673397001
66390360 bps
Input packets:
2139499896
25762 pps
Output packets:
1726872179
23359 pps
Input bytes :
9132392547
Output bytes :
12068754070
Input packets:
39035848
180
Output packets:
51566415
Unspecified, Generation: 5318
Destination: fe80::/64, Local: fe80::2a0:a552:0:2df8
Generation: 5320
Generation: 5322
. . .
181
Configuring the VPN Termination Role at Aggregation Hub 2

Enabling Tunneling on the PIC for GRE Tunnels on the VPN Termination Role on page 182
Configuring Transport on the VPN Termination Role on page 183
Configuring the VPN Routing Instance on the VPN Termination Role on page 184
Configuring the WAN-GRE Routing Instance on the VPN Termination Role at Hub
2 on page 185
Configuring Access to Hosted Services for External Users on page 188
Configuring Access to Hosted Services for Internal Users on page 189
Configuring BGP Routing Policies on the VPN Termination Role on page 191
Configuring Fully-Meshed IBGP Peer Groups on the VPN Termination Router on page 191
Configuring Class of Service on the WAN Aggregation Role on page 193
Enabling Tunneling on the PIC for GRE Tunnels on the VPN Termination Role
Step-by-Step
Procedure
1.
Enable tunnel services on the FPC uses for GRE tunnels, and specify that a bandwidth
of 10 GBPS is reserved for tunneling. Can add up to 100G depending on the line card.
This step adds all the functionality of tunnel PICs to GRE tunnels.
[edit]
set tunnel-services bandwidth 10g
182
Configuring Transport on the VPN Termination Role

Step-by-Step
Procedure
1.
Configure a logical tunnel interface to the Internet edge role.

[edit]
edit interfaces lt-5/1/0 unit 53
set description "--- To IEDGE2 lt-5/1/0.35 ---"
set encapsulation vlan
set vlan-id 35
set peer-unit 35
set family inet mtu 1500
2.
Configure a logical tunnel interface to the WAN aggregation role.

[edit]
set description "--- Under the VR WAN-GRE to WAN-AGG2 lt-5/1/0.45) ---"
set encapsulation frame-relay
set dlci 1
set peer-unit 45
set family inet6 address 2001:DB8:254:5::2/64
3.
Configure logical tunnel interfaces that form a point-to-point connection, and are
used to process shaping and queuing in place of per-unit GRE scheduling. Unit 2 is
placed in the WAN-GRE routing instance.
[edit]
set description "--- Under WAN-GRE, used for per branch shaping/queuing
(WAN-AGG2, lt-5/1/0.2) ---"
set encapsulation ethernet
set peer-unit 2
NOTE: The following configuration section is a workaround to account

for lack of per-GRE class of service in pre-Junos OS 13.3. Creating the lt
interface pairing is optional (in this case, lt-5/1/0.2 and lt-5/1/0.20) and
is a workaround for per-unit GRE CoS. A pair of lt interfaces is required
per individual branch. In this example, traffic for the individual branch
is sent over the unique sub interface pair created. Junos OS 13.3 supports
per-GRE CoS. Applying CoS to the per-branch sub-interface is shown
in the Note on page 303
[edit]
set description "--- Used for per branch shaping/queuing to WAN-GRE (lt-5/1/0.20)
---"
set peer-unit 20
183

4.
Configure the interface to the Aggregation Hub 2 hosted services.

Configure the interfaces to include the Layer 2 overhead size for both ingress and
[edit]
set description --- To Hub 2 hosted servicesr "
5.
Configure the loopback interface for the VPN termination role.

[edit]
Configuring the VPN Routing Instance on the VPN Termination Role

Step-by-Step
Procedure
The VPN routing instance is a public Internet-facing instance that is used for branches
that connect to the hub over IPsec tunnels. It acts as the IPsec server for IPsec requests
from the branch, and it terminates IPsec tunnels that are initiated at the branch.
When you configure a branch scenario that uses IPsec tunnels to Hub 1, you add IPsec
interfaces used for the scenario to the VPN routing instance, and you add the loopback
interface that is used as the GRE tunnel source address at the hub.
1.
Create the VPN virtual router routing instance.

[edit]
2.
Add the logical tunnel interface to the Internet edge router, and configure a default
static route to the logical tunnel interface at the Internet edge router (lt-5/1/0.35).
[edit]
set interface lt-5/1/0.53
Results
After VPN Routing is configured verify

1.
Verify that the static route is installed in the routing table.

user@vpn2> show route 0.0.0.0/0 exact table VPN.inet.0
184
0.0.0.0/0
*[Static/5] 02:31:29
> to 198.51.100.5 via ge-0/0/0.0
2. Verify connectivity to the Internet branch router.

user@hub2> ping 1.1.0.2 routing-instance VPN rapid
PING 1.1.0.2 (1.1.0.2): 56 data bytes
!!!!!
Configuring the WAN-GRE Routing Instance on the VPN Termination Role at Hub
2
Step-by-Step
Procedure
the GRE tunnels to the branch, and includes OSPF routing adjacencies between the GRE
tunnels and the WAN aggregation router over the directly connected Ethernet link. The
routing instance also includes multicast peering with the WAN aggregation router.
When you configure a branch scenario that uses GRE tunnels to the hub, you will add the
following to the WAN-GRE routing instance:
GRE interfaces used for the scenario to the WAN-GRE routing instance
The loopback interface that is used as the GRE tunnel source address at the hub.
An OSPF area that contains the GRE tunnels.
1.
Create a virtual-routing router instance.

Add the logical tunnel interface to the WAN aggregation role (lt-5/1/0.54).
Add the interface that is used for shaping and queuing before traffic is sent over the
GRE tunnels (lt-5/1/0.2).
[edit}
NOTE: In pre-Junos OS 13.3, lt interface pairs are required per remote

branch in order to enable per-GRE CoS. In Junos OS 13.3, the creation
of per-remote site interface pairs is no longer required. More on
configuration of CoS in Junos OS 13.3 can be found in the Note on
page 303
2.
Create a next-hop static route to the logical tunnel interface on the WAN aggregation
router (lt-5/1/0.45). Set the preference of the static route to 200 so that routes to
Aggregation Hub 1 are preferred over routes to Aggregation Hub 2. Hub 1 is always
primary.
185
After GRE tunnels are terminated, the static route sends traffic to the WAN
aggregation router.
[edit]
3.
Configure OSPF.
Only the default route is advertised to the branches over OSPF.
[edit}
edit routing-instances WAN-GRE protocols ospf
b. Create a backbone area for IPv4, and add the logical tunnel interface to the WAN
aggregation router (lt-5/1/0.54), and add the loopback interface.

[edit}
set interface lt-5/1/0.54 authentication md5 0 key
"$9$H.fQ/CpRhyX7Uik.TQEhS"
set interface lt-5/1/0.54 bfd-liveness-detection minimum-interval 500
set interface lt-5/1/0.54 bfd-liveness-detection multiplier 3
c. Create a backbone area for IPv6, and add the logical interface to the WAN
aggregation role, and add the loopback interface.

[edit}
4.
Configure multicast.
Specify the address of the RP, and add the logical tunnel interface to the WAN
aggregation role.
[edit]
set interface lt-5/1/0.54 mode sparse
set interface lt-5/1/0.54 version 2
Results
After WAN-GRE Routing is configured verify using the following procedures.

1.
Verify OSPF neighbors in the WAN-GRE routing instance.

The output here includes tunnels running to the branches.
user@vpn2> show ospf neighbor instance WAN-GRE
186
Address
172.31.254.21
172.16.1.6
172.22.16.162
172.22.16.166
172.22.16.170
172.22.16.174
172.22.16.178
. . .
Interface
lt-5/1/0.54
gr-5/1/0.1
gr-5/1/0.1011
gr-5/1/0.1012
gr-5/1/0.1013
gr-5/1/0.1014
gr-5/1/0.1015
State
Full
Full
Full
Full
Full
Full
Full
ID
172.31.255.5
172.16.0.255
172.23.4.233
172.23.4.234
172.23.4.235
172.23.4.236
172.23.4.237
Pri
128
128
128
128
128
128
128
Dead
38
34
33
35
31
35
33
2. Verify OSPFv3 neighbors in the WAN-GRE routing instance.
The output here includes tunnels running to the branches.

user@hub2> show ospf3 neighbor instance WAN-GRE
ID
Interface
State
172.31.255.5
lt-5/1/0.54
Full
Neighbor-address fe80::2a0:a552:0:2df8
172.16.0.255
gr-5/1/0.1
Full
Neighbor-address fe80::fac0:100:8c:e500
172.23.4.233
gr-5/1/0.1011
Full
Neighbor-address fe80::2a0:a512:2878:fb16
172.23.4.234
gr-5/1/0.1012
Full
172.23.4.235
gr-5/1/0.1013
Full
172.23.4.236
gr-5/1/0.1014
Full
172.23.4.237
gr-5/1/0.1015
Full
172.23.4.238
gr-5/1/0.1016
Full
172.23.4.239
gr-5/1/0.1017
Full
. . .
Pri
128
Dead
32
128
33
128
36
128
37
128
39
128
34
128
35
128
37
128
39
3. Verify multicast neighbors in the WAN-GRE routing instance.

user@vpn2> show pim neighbors instance WAN-GRE
Interface
IP
gr-5/1/0.1
4
gr-5/1/0.100
4
gr-5/1/0.1000
4
gr-5/1/0.1001
4
gr-5/1/0.1002
4
gr-5/1/0.1003
4
gr-5/1/0.1004
4
gr-5/1/0.1005
4
gr-5/1/0.1006
4
gr-5/1/0.1007
4
.
V Mode
2
2
2
2
2
2
2
2
2
2
Option
HPLGT
HPLGT
HPLGT
HPLGT
HPLGT
HPLGT
HPLGT
HPLGT
HPLGT
HPLGT

1d 01:43:59 172.16.1.6
1d 05:31:30 172.22.2.102
00:28:20 172.22.16.118
1d 05:31:27 172.22.16.122
00:29:12 172.22.16.126
00:28:19 172.22.16.130
00:28:22 172.22.16.134
00:29:19 172.22.16.138
00:28:55 172.22.16.142
00:29:20 172.22.16.146
187
Configuring Access to Hosted Services for External Users

Step-by-Step
Procedure
Figure 67: Traffic Flow for Access to Hosted Services Through Aggregation
Hub 2 (for External Users)
The HOSTED-WWW-NAT routing instance is used to route traffic to and from hosted
services. It connects to the SFW-NAT-SERVICES routing instance, which is in the Internet
edge role. It also connects to the default routing instance. To configure the routing instance
for external users to access hosted services:
1.
Configure the services interface that connects to the HOSTED-WWW-NAT routing

instance.
[edit]
set description "--- SFW-NAT-SERVICE outside interface ---"
set family inet
set service-domain outside
2.
Create a routing instance, and add the services interface to the SFW-NAT-SERVICES
routing instance (sp-1/0/0.16006) and the interface to hosted services.
[edit]
188

3.
Create a default static route with a next hop to the services interface in the
SFW-NAT-SERVICES routing instance.
[edit]
edit routing-instances HOSTED-WWW-NAT routing-options
Configuring Access to Hosted Services for Internal Users

Step-by-Step
Procedure
Figure 68: Incoming Traffic Flow to Hosted Services from Layer 3 VPN /
Leased-Line Transport
This configuration to used to provide access to hosted services for internal traffic from
the branch or from the data center. Internal users access hosted services using internal
addressing of 172.31.254.80/28. This configuration is in the WAN aggregation role in the
default routing instance.
1.
Configure the services interfaces that will process NAT.

[edit]
189
2.
Configure the NAT pool.

[edit]
edit services nat pool branch-priv-pool
set address 172.31.254.80/28
3.
Configure the NAT rule.

[edit]
edit services nat rule Branch-DC-to-www
set term from-branch-lan then translated source-pool branch-priv-pool
set term from-branch-lan then translated translation-type napt-44
4.
Configure the stateful firewall.

[edit]
5.
Configure a next-hop style service set.

[edit]
edit services service-set NAT-Branch-www
set nat-rules Branch-DC-to-www
6.
Configure a static route for traffic from the private NAT pool addresses to the inside
service interface.
[edit]
7.
Create a routing instance, and add the services interface to the SFW-NAT-SERVICES
routing instance (sp-1/0/0.16006), the interface to the WAN aggregation role
(sp-1/0/0.12002), and the interface to hosted services. ,
[edit]
8.
Configure a routing policy that exports the static route to OSPF so that it is advertised
[edit]
edit policy-options policy-statement STATIC2OSPF
9.
Add the routing policy to the OSPF configuration. .

[edit]
190
edit protocols ospf

set export STATIC2OSPF
Configuring BGP Routing Policies on the VPN Termination Role

Step-by-Step
Procedure
1.
including routes received from OSPF. The policy is a next-hop policy, which causes
the loopback address to be advertised as the next hop for BGP traffic.
[edit]
2.
[edit]
3.
[edit]
4.
[edit]
Configuring Fully-Meshed IBGP Peer Groups on the VPN Termination Router

Step-by-Step
Procedure
At the aggregation hubs, we have a full IBGP mesh with the WAN aggregation router and
the WAN-GRE virtual routing instance on Aggregation Hub 1, the WAN-GRE
1.
191
[edit}
[edit routing-instances WAN-GRE protocols bgp group IBGP-Mesh
set type internal
set export NHS
set neighbor 172.31.255.2 authentication-key "$9$-tbY4UjkTznO1XNdbg4Qz3"
set neighbor 172.31.255.3 authentication-key "$9$4VJUiP5zCt0ylsgoJjiAtu"
set neighbor 172.31.255.5 authentication-key "$9$QyYC3/ABIhKMLs2PTz3CAvM8"
2.

(2001:DB8:255::3).

[edit}
edit routing-instances WAN-GRE protocols bgp group IBGP-Mesh-V6
set type internal
set export NHS6
set neighbor 2001:DB8:255::2 authentication-key "$9$-0bY4UjkTznO1XNdbg4Qz3"
set neighbor 2001:DB8:255::3 authentication-key "$9$8nrx-b4aGqm5CtKWLxVb.mf"
set neighbor 2001:DB8:255::5 authentication-key "$9$m5zntuBSrK-VH.P53nyre"
Results
After IBGP Peer Groups are configured verify

user@vpn2> show bgp group summary instance WAN-GRE
Group
Type
Peers
Established
IBGP-Mesh
Internal
3
3
WAN-GRE.inet.0
: 24255/25256/25256/0
IBGPoGRE
Internal
2
2
WAN-GRE.inet.0
: 128/207/207/0
IBGPoGRE-V6 Internal
2
2
WAN-GRE.inet6.0 : 107/184/184/0
IBGP-Mesh-V6 Internal
3
3
WAN-GRE.inet6.0 : 23284/24285/24285/0
IBGPoGRE_SCALED_BRANCHES Internal 1000 997
WAN-GRE.inet.0
: 997/5982/5982/0
IBGPoGRE_SCALED_BRANCHES_V6 Internal 1000 997
WAN-GRE.inet6.0 : 997/4985/4985/0
Groups: 6
Peers: 2010 External: 0
Internal: 2010 Down peers: 6
Flaps: 2814
WAN-GRE.inet.0
: 25380/31445/31445/0 External: 0/0/0/0 Internal:
25380/31445/31445/0
WAN-GRE.inet6.0 : 24388/29454/29454/0 External: 0/0/0/0 Internal:
192
24388/29454/29454/0
WAN-GRE.mdt.0
user@hub2> show bgp summary instance WAN-GRE
Table
History Damp State
Pending
WAN-GRE.inet.0
31445
25380
0
0
0
0
WAN-GRE.inet6.0
29454
24388
0
0
0
0
WAN-GRE.mdt.0
0
0
0
0
0
0
Peer
AS
InPkt
OutPkt
OutQ
Flaps Last Up/Dwn
172.16.2.6
65530
1146
1051
0
3
8:38:32
Establ
WAN-GRE.inet.0: 1/78/78/0
172.16.3.6
65530
1153
1050
0
3
8:38:32
Establ
WAN-GRE.inet.0: 127/129/129/0
172.22.1.2
65530
1047
1048
0
1
8:38:01
Establ
172.22.1.6
65530
1047
1049
0
1
8:38:12
Establ
172.22.1.10
65530
1047
1049
0
1
8:38:05
Establ
172.22.1.14
65530
1047
1049
0
1
8:38:17
Establ
172.22.1.18
65530
1047
1049
0
1
8:38:21
Establ
.
.
.
.
Configuring Class of Service on the WAN Aggregation Role

Step-by-Step
Procedure
1.
a. Configure DSCP behavior aggregation (BA) for IPv4
[edit]
193
[edit]
[edit]
set queue 4 Video
set queue 5 Voice
2.
Configure rewrite rules.

a. Configure rewrite rules for IPv4 traffic.
[edit]
b. Create rewrite rules for IPv6 traffic.
[edit]
3.

[edit]
194

set SCH_VOICE transmit-rate rate-limit
4.

[edit]
set MAIN-SCHD forwarding-class Voice scheduler SCH_VOICE
set MAIN-SCHD forwarding-class Video scheduler SCH_Video
set MAIN-SCHD forwarding-class Scavenger scheduler SCH_Scavenger
set MAIN-SCHD forwarding-class Network_Control scheduler SCH_Network_Control
set MAIN-SCHD forwarding-class Critical_Data scheduler SCH_Critical_Data
set MAIN-SCHD forwarding-class Bulk_Data scheduler SCH_Bulk_Data
set MAIN-SCHD forwarding-class Best_Effort scheduler SCH_Best_Effort
5.
Create a traffic control profile to be applied to interfaces to small branches.

[edit]
edit class-of-service traffic-control-profiles SMALL-BRANCH
This SMALL-BRANCH control profile is applied in the branch scenario configurations.

6.
Apply CoS to the services interface that handles source NAT.

[edit]
edit class-of-service interfaces sp-1/0/0
7.
195
[edit]
Verification
Verify Preferred Routes
Action
Verify that the VPN termination role advertises only the default route to
Internet-connected branches that use BGP as the private routing protocol. Also, make
sure that the VPN termination role receives all of the branch prefixes. Make sure that
routes to branches that are received by the VPN termination router at Aggregation Hub
1 from OSPF and BGP are preferred over routes received by Hub 2. In this case, the OSPF
cost and BGP local preference configurations should give preference to Hub 1. .
1.
Verify default route advertised via BGP

user@hub2> show route advertising-protocol bgp 172.22.1.2
hidden)
Prefix
Nexthop
MED
Lclpref
AS path
* 0.0.0.0/0
Self
0
100
I
user@hub2> show route advertising-protocol bgp fec0:22:1:1::2
WAN-GRE.inet6.0: 26846 destinations, 58356 routes (26846 active, 0 holddown,
0 hidden)
Prefix
Nexthop
MED
Lclpref
AS path
* ::/0
Self
100
I
2. Verify routing to 172.16.1.0/24

user@hub2> show route 172.16.1.0/24
172.16.1.0/30
172.16.1.4/30
d172.16.1.12/30
172.16.1.16/30
172.16.1.20/30
172.16.1.254/32
*[OSPF/10] 00:09:10, metric 12

> to 172.31.254.41 via ge-4/2/1.0
*[OSPF/10] 00:09:10, metric 13
> to 172.31.254.41 via ge-4/2/1.0
*[OSPF/10] 00:09:10, metric 13
> to 172.31.254.41 via ge-4/2/1.0
*[OSPF/10] 00:09:10, metric 13
> to 172.31.254.41 via ge-4/2/1.0
*[OSPF/10] 00:09:10, metric 13
> to 172.31.254.41 via ge-4/2/1.0
*[OSPF/10] 00:09:10, metric 12
> to 172.31.254.41 via ge-4/2/1.0

172.16.1.255/32
*[Static/1] 00:13:30
> via sp-1/0/0.2

hidden)
196
172.16.1.0/30
172.16.1.4/30
172.16.1.5/32
172.16.1.12/30
172.16.1.16/30
172.16.1.20/30
172.16.1.254/32
*[OSPF/10] 00:12:16, metric 21

> via gr-5/1/0.1
*[Direct/0] 1d 05:18:28
> via gr-5/1/0.1
[OSPF/10] 1d 05:18:21, metric 20
> via gr-5/1/0.1
*[Local/0] 1d 05:19:07
Local via gr-5/1/0.1
*[OSPF/10] 00:12:16, metric 21
> via gr-5/1/0.1
*[OSPF/10] 00:12:16, metric 21
> via gr-5/1/0.1
*[OSPF/10] 00:12:16, metric 21
> via gr-5/1/0.1
*[OSPF/10] 00:12:16, metric 20
> via gr-5/1/0.1
3. Verify that when the VPN2 GRE tunnels are up all the traffic to IPsec GRE branches
should take the GRE interface and not through Head-End1.

user@hub2> ping 172.16.1.255 source 172.31.255.231 rapid routing-instance VPN
PING 172.16.1.255 (172.16.1.255): 56 data bytes
!!!!!
user@hub2> traceroute 172.16.1.6 routing-instance WAN-GRE
traceroute to 172.16.1.6 (172.16.1.6), 30 hops max, 40 byte packets
1 172.16.1.6 (172.16.1.6) 9.171 ms 9.480 ms 2.436 ms
1 172.16.1.254 (172.16.1.254) 2.505 ms 2.341 ms 8.705 ms
4. Verify that WAN-GRE VR on VPN2 is receiving a 0.0.0.0/0 route from WAN-AGG2 for
any Internet bound traffic that is sourced from the GRE IPsec branches.
user@hub2> show route table WAN-GRE.inet.0 0.0.0.0/0 exact
hidden)
0.0.0.0/0
*[OSPF/175] 1d 01:20:04, metric 0, tag 0

> via lt-5/1/0.54
[Static/200] 1d 05:28:25
> to 172.31.254.21 via lt-5/1/0.54
5. Verify the routes that are advertised by the DC-CORE and ping to DC-ACCESS LSYS
loopback address to verify the connectivity.

user@hub2> show route table WAN-GRE.inet.0 172.28.0.0/16 terse
hidden)
A
*
*
*
*
*
*
V
?
?
?
?
?
?
Destination
172.28.1.0/24
172.28.2.0/24
172.28.3.0/24
172.28.4.0/24
172.28.5.0/24
172.28.6.0/24
P Prf
O 10
O 10
O 10
O 10
O 10
O 10
Metric 1
27
27
27
27
27
27
Metric 2
Next hop
>lt-5/1/0.54
>lt-5/1/0.54
>lt-5/1/0.54
>lt-5/1/0.54
>lt-5/1/0.54
>lt-5/1/0.54
AS path
197
*
*
*
*
*
*
*
*
*
*
.
.
.
?
?
?
?
?
?
?
?
?
?
172.28.7.0/24
172.28.8.0/24
172.28.9.0/24
172.28.10.0/24
172.28.11.0/24
172.28.12.0/24
172.28.13.0/24
172.28.14.0/24
172.28.15.0/24
172.28.16.0/24
O
O
O
O
O
O
O
O
O
O
10
10
10
10
10
10
10
10
10
10
27
27
27
27
27
27
27
27
27
27
>lt-5/1/0.54
>lt-5/1/0.54
>lt-5/1/0.54
>lt-5/1/0.54
>lt-5/1/0.54
>lt-5/1/0.54
>lt-5/1/0.54
>lt-5/1/0.54
>lt-5/1/0.54
>lt-5/1/0.54
user@hub2> ping 172.31.255.8 routing-instance WAN-GRE rapid

PING 172.31.255.8 (172.31.255.8): 56 data bytes
!!!!!
1 172.31.254.21 (172.31.254.21) 0.534 ms 0.422 ms 0.406 ms #WAN-AGG2
2 172.31.255.8 (172.31.255.8) 0.716 ms 0.728 ms 0.566 ms # DC-ACCESS
198
CHAPTER 7
Configuring the Internet Gateway on

Aggregation Hub 2
Requirements
At Aggregation Hub 2, the Internet gateway role is integrated into the MX480 3D Universal
Edge router used at the hub.
Overview
The backup aggregation hub features an MX480 configured virtual routing instances for
each of the WAN aggregation hub functional roles. This section focuses on configuration
of the nodes in the blue highlighted area (Figure 69 on page 199).
199
Configuring the Internet Gateway Role on Aggregation Hub 2
Configuring Transport on the Internet Gateway on page 200
Configuring BGP Routing Policies on the Internet Gateway on page 202
Configuring BGP Peer Groups on the Internet Gateway on page 204
Configuring Security Based on Application Traffic on the Internet Gateway on page 206
Configuring a Routing Instance for Stateful Firewall and NAT Services on the Internet
Gateway on page 210
Configuring NAT and Stateful Firewall for Inbound Traffic on the Internet
Gateway on page 211
Gateway on page 213
Configuring Class of Service on the Internet Gateway on page 214
Configuring Transport on the Internet Gateway

Step-by-Step
Procedure
1.
Configure the interface to the ISP.

[edit]
set description " --- To Public ISP "

2.
Configure the logical tunnel interface to the SFW-NAT-SERVICES routing instance.

[edit]
200
set description "--- Under the IEDGE Service & connected to SFW-NAT-SERVICES
(lt-5/1/0.1)"
set peer-unit 1
3.
Configure the logical tunnel interface to the VPN termination role.

[edit]
set description "--- To VPN role lt-5/1/0.53 ---"
set encapsulation vlan
set vlan-id 35
set peer-unit 53
set filter input BRANCH
4.
Configure the Ethernet interface to the Internet edge router at Aggregation Hub 1.
[edit]
set description "--- To Internet edge Hub 1 xe-0/0/0 ---"
5.
Configure a loopback interface.

[edit]
6.
Add all of the above interfaces to the IEDGE virtual routing instance.
[edit]
edit routing-instances IEDGE
set interface xe-5/0/0.0
set interface lo0.1
201
Configuring BGP Routing Policies on the Internet Gateway

Step-by-Step
Procedure
Figure 70: Routing Configuration at the Internet Gateways
1.
including routes received from OSPF.
[edit]
2.
[edit]
3.
202
[edit]
4.
[edit]
5.
Configure a routing policy that is used to reject routes from the Aggregation Hub 1
block of addresses (191.15.100.0/24).
[edit]
edit policy-options policy-statement BLOCK_HEAD1_BLOCK
6.
Configure a policy that is used to reject all routes.

[edit]
set then reject
7.
Configure a policy that is used to advertise the block of addresses used for source
NAT (192.0.2.0/24) and the Aggregation Hub 2 block of addresses (100.64.100.0/24)
used for destination NAT to the Internet.
The AS path prepend adds AS numbers at the beginning of an AS path. AS path
prepending makes a shorter AS path look longer and therefore less preferable BGP.
In this case, a longer AS path on the Internet edge of Hub 2 makes routes to the
Internet edge router on Hub 1 preferable.
[edit]
edit policy-options policy-statement HEAD2-RANGE
set term 1 from protocol aggregate
set term 2 then as-path-prepend "2222 2222 2222"
8.
Configure a prefix list and routing policy that are used to prevent martian routes
[edit]
edit policy-options prefix-list RFC1918
set 10.0.0.0/8
set 172.16.0.0/12
set 192.168.0.0/16
[edit]
edit policy-options policy-statement MARTIANS
203
set term 1 from prefix-list-filter RFC1918 orlonger
Configuring BGP Peer Groups on the Internet Gateway

Step-by-Step
Procedure
1.
Configure the AS number for the Internet edge router.

[edit}
edit routing-instances IEDGE routing-options
2.
In the IEDGE routing instance, create an IBGP group that is used to as a peer to the
Internet edge router at Aggregation Hub 1.
[edit]
edit routing-instances IEDGE protocols bgp group HEAD1
set type internal
set neighbor 172.31.254.5 authentication-key "$9$zpgIn9t1RcvWXYgfQFnAtMWL"
set neighbor 172.31.254.5 export NHS
set neighbor 172.31.254.5 peer-as 2222
3.
In the IEDGE routing instance, configure an EBGP peer group to the Internet service
provider.
The neighbor is the address of the Internet service provider.
The MARTIANS import policy prevents martian routes received from the Internet
The BLOCK_HEAD1_BLOCK import policy prevents routes advertised from the
Aggregation Hub 1 block of addresses (191.15.100.0/24).
The HEAD2-RANGE export policy advertises the enterprise block of addresses used
for source NAT (100.64.100.0/24) and the Aggregation Hub 2 block of addresses
[edit]
edit routing-instances IEDGE protocols bgp group EBGP_To_AS_269
set type external
set import MARTIANS
set import BLOCK_HEAD1_BLOCK
set export HEAD2-RANGE
set peer-as 269
set neighbor 191.15.200.1 authentication-key "$9$I1rhyeLx-24J.P01Rhleg4a"
204
Step-by-Step
Procedure
After BGP peer groups are configured, verify BGP.

1.
Verify BGP peering to the Internet service provider gateway (198.51.100.1) and to
the Internet edge router at Aggregation Hub 2 (172.31.254.6).
user@hub_2> show bgp summary instance IEDGE
Table
Pending
IEDGE.inet.0
2
2
0
0
IEDGE.mdt.0
0
0
0
0
Peer
AS
InPkt
OutPkt
172.31.254.5
2222
1045
955
Establ
IEDGE.inet.0: 1/1/1/0
192.0.2.1
269
1039
950
Establ
IEDGE.inet.0: 1/1/1/0
2.
History Damp State
OutQ
0
Flaps Last Up/Dwn
7:50:23
7:48:06
Verify BGP groups.

user@hub_2> show bgp group summary instance IEDGE
Group
Type
Peers
Established
EBGP_To_AS_269 External 1
1
IEDGE.inet.0
: 1/1/1/0
HEAD1
Internal
1
1
IEDGE.inet.0
: 1/1/1/0
Groups: 2 Peers: 2
External: 1
Internal: 1
Down peers: 0
0
IEDGE.inet.0
IEDGE.mdt.0
Flaps:
user@hub_2> show route receive-protocol bgp 192.0.2.1

IEDGE.inet.0: 13 destinations, 14 routes (13 active, 0 holddown, 0 hidden)
Prefix
Nexthop
MED
Lclpref
AS path
* 0.0.0.0/0
192.0.2.1
269 I
3.
Verify that routes are being received from and advertised to the Internet service
provider.
user@hub_2> show route receive-protocol bgp 192.0.2.1
Prefix
Nexthop
MED
Lclpref
AS path
* 0.0.0.0/0
192.0.2.1
269 I
user@hub_2> route advertising-protocol bgp 192.0.2.1
Prefix
Nexthop
MED
Lclpref
AS path
* 192.0.2.0/24
Self
I
* 100.64.100.0/24
Self
2222 2222
2222 [2222] I
4.
Verify that routes are being received from and advertised to the Internet edge router
205

Prefix
Nexthop
MED
Lclpref
AS path
* 100.64.100.0/24
172.31.254.5
100
I
user@hub_2> show route advertising-protocol bgp 172.31.254.5
Prefix
Nexthop
MED
Lclpref
AS path
* 0.0.0.0/0
Self
200
269 I
5.
Verify that the inet.0 routing table is properly populated.

user@hub_2> show route table IEDGE.inet.0
0.0.0.0/0
*[BGP/170] 07:51:45, localpref 200

> to 192.0.2.1 via ge-4/2/6.0
172.31.254.4/30
*[Direct/0] 1d 04:27:14
> via xe-5/0/0.0
172.31.254.6/32
*[Local/0] 1d 04:27:14
Local via xe-5/0/0.0
172.31.254.24/30
*[Direct/0] 20:58:48
> via lt-5/1/0.10
172.31.254.26/32
*[Local/0] 1d 04:27:46
Local via lt-5/1/0.10
172.31.255.4/32
*[Direct/0] 1d 04:29:27
> via lo0.1
192.0.2.0/24
*[Aggregate/130] 1d 04:29:53
Reject
192.0.2.0/30
*[Direct/0] 1d 04:27:08
> via ge-4/2/6.0
192.0.2.2/32
*[Local/0] 1d 04:27:14
192.0.2.4/30
*[Direct/0] 1d 04:27:19
> via lt-5/1/0.35
192.0.2.5/32
*[Local/0] 1d 04:27:46
192.0.2.224/32 *[Static/5] 1d 04:27:19
> to 172.31.254.25 via lt-5/1/0.10
100.64.100.0/24
*[BGP/170] 07:54:02, localpref 100
AS path: I, validation-state: unverified
> to 172.31.254.5 via xe-5/0/0.0
[Static/200] 1d 04:27:19
> to 172.31.254.25 via lt-5/1/0.10
Configuring Security Based on Application Traffic on the Internet Gateway

Step-by-Step
Procedure
On the Internet gateways, we are implementing Application Layer Gateways (ALGs) as

part of our security strategy. We are using ALGs in stateful firewalls for applications for
which the return flow can be difficult to predict because the application creates separate
connections for data and control flows or creates new protocol flows based on an open
connection. Each application has a unique set of parameters that must be examined,
and these parameters are implemented as ALGs.
You can customize this list of ALGs to specify traffic that you want to block or allow
through your stateful firewalls.
1.
206
Configure the following ALGs.
[edit]
edit applications
set application ftp application-protocol ftp
set application ftp protocol tcp
set application ftp destination-port 21
set application tftp application-protocol tftp
set application tftp protocol udp
set application tftp destination-port 69
set application rpcportmaptcp application-protocol rpc-portmap
set application rpcportmaptcp protocol tcp
set application rpcportmaptcp destination-port 111
set application rpcportmapudp application-protocol rpc-portmap
set application rpcportmapudp protocol udp
set application rpcportmapudp destination-port 111
set application rexec application-protocol exec
set application rexec protocol tcp
set application rexec destination-port 512
set application rlogin protocol tcp
set application rlogin destination-port 513
set application rsh application-protocol shell
set application rsh protocol tcp
set application rsh destination-port 514
set application rtsp application-protocol rtsp
set application rtsp protocol tcp
set application rtsp destination-port 554
set application winframe application-protocol winframe
set application winframe protocol tcp
set application winframe destination-port 1494
set application sqlnet application-protocol sqlnet
set application sqlnet protocol tcp
set application sqlnet destination-port 1521
set application h323 application-protocol h323
set application h323 protocol tcp
set application h323 destination-port 1720
set application iiop-java application-protocol iiop
set application iiop-java protocol tcp
set application iiop-java destination-port 1975
set application iiop-orbix application-protocol iiop
set application iiop-orbix protocol tcp
207
set application iiop-orbix destination-port 3075

set application realaudio application-protocol realaudio
set application realaudio protocol tcp
set application realaudio destination-port 7070
set application traceroute application-protocol traceroute
set application traceroute protocol udp
set application traceroute destination-port 33435-33450
set application traceroute ttl-threshold 30
set application rpcservicesudp application-protocol rpc
set application rpcservicesudp protocol udp
set application rpcservicesudp rpc-program-number 100000-400000
set application rpcservicestcp application-protocol rpc
set application rpcservicestcp protocol tcp
set application rpcservicestcp rpc-program-number 100000-400000
set application icmp-all application-protocol icmp
set application netshow application-protocol netshow
set application netshow protocol tcp
set application netshow destination-port 1755
set application netbios_name application-protocol netbios
set application netbios_name protocol udp
set application netbios_name destination-port 137
set application netbios_datagram application-protocol netbios
set application netbios_datagram protocol udp
set application netbios_datagram destination-port 138
set application dcerpcportmap application-protocol dce-rpc-portmap
set application dcerpcportmap protocol tcp
set application dcerpcportmap destination-port 135
set application dcerpc-uuid-epm application-protocol dce-rpc
set application dcerpc-uuid-epm protocol tcp
set application dcerpc-uuid-epm uuid e1af8308-5d1f-11c9-91a4-08002b14a0fa
set application dcerpc-uuid-foo application-protocol dce-rpc
set application dcerpc-uuid-foo protocol tcp
set application dcerpc-uuid-foo uuid 1544f5e0-613c-11d1-93df-00c04fd7bd09
set application dcerpc-uuid-ntlmssp-negotiate application-protocol dce-rpc
set application dcerpc-uuid-ntlmssp-negotiate protocol tcp
set application dcerpc-uuid-ntlmssp-negotiate uuid
a4f1db00-ca47-1067-b31f-00dd010662da
set application snmp application-protocol snmp
208
set application snmp protocol udp

set application snmp destination-port 161
set application web protocol tcp
set application web destination-port 80
2.
Create an application set for all ALGs.

[edit]
edit applications application-set all-alg-set
set application ftp
set application tftp
set application rpcportmaptcp
set application rpcportmapudp
set application rexec
set application rlogin
set application rsh
set application winframe
set application sqlnet
set application h323
set application iiop-java
set application iiop-orbix
set application realaudio
set application traceroute
set application rpcservicesudp
set application rpcservicestcp
set application netshow
set application netbios_name
set application netbios_datagram
set application dcerpcportmap
set application dcerpc-uuid-epm
set application dcerpc-uuid-foo
set application dcerpc-uuid-ntlmssp-negotiate
set application snmp
3.
Create a set of applications for the DMZ.

[edit]
set application ftp
set application web
4.
enterprise to the Internet.
[edit]
209
5.
Internet to the enterprise network.
[edit]
6.
Create a stateful firewall that allows accounting traffic through the firewall.
[edit]
edit services stateful-firewall rule protect-accounting
set term allow-accounting-out-alg from application-sets all-alg-set
set term allow-accounting-out-alg then accept
set term allow-accounting-out-no-alg then accept
Configuring a Routing Instance for Stateful Firewall and NAT Services on the
Internet Gateway
Step-by-Step
Procedure
Create a virtual router routing instance called SFW-NAT-SERVICES. It is used to route

external Internet traffic to hosted services. It connects to the HOSTED-WWW-NAT
routing instance in the VPN role.
1.
Configure the lt interface that connects to the IEDGE virtual router.

[edit]
set description "---under SFW-NAT-SERVICE VR to IEDGE (lt-5/1/0.10)"
set mtu 1500
set peer-unit 10
2.
Configure the services interface that connects to the WAN aggregation role.
[edit]
set description "--- Branch to WWW NAT service outside interface ---"
set family inet
set service-domain outside
3.
Configure the services interface that connects to the HOSTED-SERVICES-NAT

routing instance in the VPN termination role.
[edit]
set description "--- WWW to Hosted Service inside interface ---"
set family inet
set service-domain inside
4.
Create a virtual router routing instance for NAT and stateful firewall services. Add
the above interfaces to the instance.
[edit]
edit routing-instances SFW-NAT-SERVICES
210

5.
Create a static default route to the lt-5/1/0.10 interface on the IEDGE virtual router.
[edit]
edit routing-instances SFW-NAT-SERVICE
Results
After stateful firewall and NAT services are configured and committed, use the following
commands to verify the configuration was successful
user@hub_2> show route table SFW-NAT-SERVICE.inet.0
SFW-NAT-SERVICE.inet.0: 5 destinations, 6 routes (5 active, 0 holddown, 0 hidden)
0.0.0.0/0
*[Static/5] 20:59:53
> to 172.31.254.26 via lt-5/1/0.1
172.31.254.24/30
*[Direct/0] 20:59:53
> via lt-5/1/0.1
172.31.254.25/32
*[Local/0] 20:59:53
192.0.2.224/32 *[Static/1] 20:59:50
> via sp-1/0/0.16005
[Static/5] 20:59:53
> via sp-1/0/0.16005
100.64.100.0/24
*[Static/1] 20:59:50
> via sp-1/0/0.16002
Configuring NAT and Stateful Firewall for Inbound Traffic on the Internet Gateway
Step-by-Step
Procedure
This procedure configures destination NAT and the stateful firewall for external traffic
received from the Internet and sent to hosted services.
1.
Create an aggregate route for the Aggregation Hub 2 block of addresses that is
advertised to the Internet for hosted services.
[edit]
2.
Configure a static route in the IEDGE virtual routing instance to send traffic for
192.0.2.224/28 to the interface lt-5/1/0.1 in the SFW-NAT-SERVICES routing
instance.
[edit]
3.
Create a NAT pool for the private addresses used for hosted services.
[edit]
edit services nat pool www-addr
set address 172.31.255.48/28
4.
Create a NAT rule used to perform destination NAT. Use translation type dnat-44,
which causes the destination address to be statically translated (IPv4 to IPv4).
211
[edit]
edit services nat rule internet-www
set term from-internet from destination-address 192.0.2.224/28
set term from-internet then translated destination-pool www-addr
set term from-internet then translated translation-type dnat-44
5.
Create an application set for the DMZ using applications that were previously
configured.
[edit]
set application ftp
set application web
6.
Create a stateful firewall rule that allows all traffic through the firewall. In your
actual deployment, you would customize your own firewall.
[edit]
7.
Create a stateful firewall that accepts application traffic that is defined in the
dmz-alg-set application set.
[edit]
8.
Configure a next-hop style service set to be used for hosted services.

[edit]
edit services service-set NAT-internet-WWW
set stateful-firewall-rules internet-to-dmz
set nat-rules internet-www
Results

user@iedge2> show services stateful-firewall flows service-set NAT-internet-WWW
user@iedge2> show services stateful-firewall flows service-set NAT-internet-WWW
Interface: sp-3/0/0, Service set: NAT-Hosted-Service
Flow
State
Dir
Frm count
61
100.65.4.2:0
-> 198.51.100.224:0
Forward O
25504422
NAT dest
198.51.100.224:0
->
172.31.254.50:0
Interface
Service set
Accept
Discard
sp-3/0/0
NAT-Branch-internet
8948614
0
sp-3/0/0
NAT-Hosted-Service
2591669
212
Reject
0
0
Errors
0
0

Interface
Service set
Accept
Discard
Reject
sp-3/0/0
NAT-Branch-internet
8948614
0
0
sp-3/0/0
NAT-Hosted-Service
2591669
0
0
Errors
0
0
Gateway
Step-by-Step
Procedure
This procedure configures source NAT and the stateful firewall for internal traffic from
branches, the data center, or hosted services that is headed to the Internet.
1.
Configure a pool of addresses for the enterprise block of assigned addresses. These
addresses are advertised to the Internet, and are used for source NAT.
[edit]
edit services nat pool public-pool
set address 100.64.100.0/24
2.
Create a NAT rule for traffic from branches, the data center, or hosted services to
the Internet. The source addresses are the internal enterprise addresses.
[edit]
edit services nat rule Branch-DC-to-Internet
set term from-lan then translated source-pool public-pool
set term from-lan then translated translation-type napt-44
3.
Create a set of applications for the DMZ.

[edit]
set application ftp
set application web
4.
enterprise to the Internet.
[edit]
213
5.
Create a stateful firewall rule that allows all traffic through the firewall. In your
actual deployment, you would customize your own firewall.
[edit]
6.
Create a NAT service set for traffic from branches, the data center, or hosted services
to the Internet.
[edit]
edit services service-set NAT-Branch-internet
set stateful-firewall-rules corp-to-internet
set nat-rules Branch-DC-to-Internet
7.
Configure a static route in the IEDGE virtual routing instance to interface lt-5/1/0.1
in the SFW-NAT-SERVICES routing instance.
Configure a static route for the enterprise block of addresses that are used for source
NAT (100.64.100.0/24). Assign a preference of 200 so that routes on Hub1 are
preferred over routes to Hub 2.
[edit]
Results

user@iedge2> show services stateful-firewall flows service-set NAT-Branch-internet
Configuring Class of Service on the Internet Gateway

Step-by-Step
Procedure
CoS is used on the Internet edge router to separate incoming traffic from the
Internet-connected branches from traffic coming from the Internet.
1.
Configure DSCP behavior aggregation (BA) for IPv4.

[edit]
2.
Configure the DSCP BA classifier for IPv6.

[edit]
3.
214
Assign the forwarding classes to transmission queues.
[edit]
set queue 7 BRANCH
4.

[edit]
set SCH_Network_Control_IEDGE transmit-rate percent 1
set SCH_Network_Control_IEDGE transmit-rate rate-limit
set SCH_Network_Control_IEDGE priority strict-high
set SCH_BRANCH_IEGDE transmit-rate percent 79
set SCH_BRANCH_IEGDE priority high
set SCH_INTERNET_IEDGE transmit-rate percent 20
set SCH_INTERNET_IEDGE priority low
5.

[edit]
set IEDGE_ISP_LINK_SCHEDULER forwarding-class BRANCH scheduler
SCH_BRANCH_IEGDE
set IEDGE_ISP_LINK_SCHEDULER forwarding-class Best_Effort scheduler
SCH_INTERNET_IEDGE
set IEDGE_ISP_LINK_SCHEDULER forwarding-class Network_Control scheduler
SCH_Network_Control_IEDGE
6.
Create a traffic control profile for traffic to the Internet service provider.
[edit]
edit class-of-service traffic-control-profiles TO-ISP2
set scheduler-map IEDGE_ISP_LINK_SCHEDULER
7.
Apply CoS to the interface to the Internet service provider.

[edit]
set output-traffic-control-profile TO-ISP2
8.
Apply CoS to the interface on the Internet edge role to the Internet edge router on
Aggregation Hub 1.
[edit]
Step-by-Step
Procedure
If the data center or hosted services are not reachable for Internet-connected branches
or for public Internet traffic, the ge-4/2/6 interface to the ISP is used. You can verify that
CoS is working as expected by following this procedure in a failover scenario.
1.
Verify CoS on the interface to the ISP.
215
user@vpn2> show interfaces ge-4/2/6 extensive

Device flags
: Present Running
Link flags
: None
CoS queues
Schedulers
: 0
Hold-times
Current address: 2c:21:72:b2:45:d2, Hardware address: 2c:21:72:b2:45:d2
Last flapped
: 2013-06-18 08:22:23 PDT (1d 04:33 ago)
Traffic statistics:
Input bytes :
1235582733047
132670576 bps
Output bytes :
721409738036
84645928 bps
Input packets:
3227546501
41301 pps
Output packets:
1646229145
23842 pps
Input bytes :
0
Output bytes :
0
Input packets:
0
Output packets:
0
Input bytes :
0
Output bytes :
0
Input packets:
0
Output packets:
0
Input errors:
Errors: 0, Drops: 0, Framing errors: 0, Runts: 0, Policed discards: 0,
L3 incompletes: 0, L2 channel errors: 0, L2 mismatch timeouts: 0, FIFO errors:
0,
Resource errors: 0
Output errors:
packets: 0, FIFO errors: 0, HS link CRC errors: 0, MTU errors: 0, Resource
errors: 0
Queue counters:
Dropped
packets
0 Best_Effort
508020792
508020792
0
1 Scavenger
0
0
0
2 Bulk_Data
136113055
136113030
25
3 Critical_Dat
200785350
200780249
5101
4 Video
398972498
398971364
1134
5 Voice
251308362
251307882
480
6 Network_Cont
151040618
151040618
0
7 BRANCH
0
0
0
Queue number:
0
Best_Effort
216
1
Scavenger
2
Bulk_Data
3
Critical_Data
4
Video
5
Voice
6
Network_Control
7
BRANCH
MAC statistics:
Receive
Transmit
Total octets
1235574774649
721404556892
Total packets
3227526305
1646217499
Unicast packets
3227526248
1646217458
Broadcast packets
53
41
Multicast packets
0
0
CRC/Align errors
0
0
FIFO errors
0
0
MAC control frames
0
0
MAC pause frames
0
0
Oversized frames
0
Jabber frames
0
Fragment frames
0
VLAN tagged frames
0
Code violations
0
Total errors
0
0
Filter statistics:
Input packet count
3227484958
0
Input DA rejects
0
Input SA rejects
0
Output packet count
1646193671
0
0
Link partner:
fault: OK
Local resolution:
CoS information:
Direction : Output
CoS transmit queue
Bandwidth
Buffer Priority
Limit
%
bps
%
usec
0 Best_Effort
20
160000000
r
0
low
none
7 BRANCH
79
632000000
r
0
high
none
1222)
18 bytes
:
18 bytes
Traffic statistics:
217
Input bytes :
1235582733047
Output bytes :
721409693912
Input packets:
3227546501
Output packets:
1646229145
Local statistics:
Input bytes :
472056
Output bytes :
565620
Input packets:
7354
Output packets:
7354
Transit statistics:
Input bytes :
1235582260991
132670576 bps
Output bytes :
721409128292
84645928 bps
Input packets:
3227539147
41301 pps
Output packets:
1646221791
23842 pps
Flags: Sendbcast-pkt-to-re, Is-Primary, User-MTU
Destination: 192.0.2.0/30, Local: 192.0.2.2, Broadcast: 192.0.2.3,
Generation: 5352
2.
Verify the separation of Internet traffic and branch traffic into different queues on
traffic sent toward the Internet.
user@hub2> show interfaces queue ge-4/2/6 egress
Queue: 0, Forwarding classes: Best_Effort
Queued:
Packets
:
508990230
7105 pps
Bytes
:
234586408449
26864608 bps
Transmitted:
Packets
:
508990230
7105 pps
Bytes
:
234586408449
26864608 bps
0
0 pps
0
0 pps
Low
:
0
0 pps
Medium-low
:
0
0 pps
Medium-high
:
0
0 pps
High
:
0
0 pps
RED-dropped bytes
:
0
0 bps
Low
:
0
0 bps
Medium-low
:
0
0 bps
Medium-high
:
0
0 bps
High
:
0
0 bps
Queue: 1, Forwarding classes: Scavenger
Queued:
Packets
:
0
0 pps
Bytes
:
0
0 bps
Transmitted:
Packets
:
0
0 pps
Bytes
:
0
0 bps
0
0 pps
0
0 pps
Low
:
0
0 pps
Medium-low
:
0
0 pps
218
Medium-high
:
0
High
:
0
RED-dropped bytes
:
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
Queue: 2, Forwarding classes: Bulk_Data
Queued:
Packets
:
136386039
Bytes
:
82649939634
Transmitted:
Packets
:
136386014
Bytes
:
82649924484
25
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
RED-dropped bytes
:
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
Queue: 3, Forwarding classes: Critical_Data
Queued:
Packets
:
201194827
Bytes
:
96169574111
Transmitted:
Packets
:
201189726
Bytes
:
96167135833
3153
1948
Low
:
1948
Medium-low
:
0
Medium-high
:
0
High
:
0
RED-dropped bytes
:
931144
Low
:
931144
Medium-low
:
0
Medium-high
:
0
High
:
0
Queue: 4, Forwarding classes: Video
Queued:
Packets
:
399791451
Bytes
:
242273619306
Transmitted:
Packets
:
399790317
Bytes
:
242272932102
1134
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
RED-dropped bytes
:
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
0
0
0
0
0
0
0
pps
pps
bps
bps
bps
bps
bps
2000 pps
9699840 bps
2000
9699840
0
0
0
0
0
0
0
0
0
0
0
pps
bps
pps
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
3001 pps
11478080 bps
3001
11478080
0
0
0
0
0
0
0
0
0
0
0
pps
bps
pps
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
6003 pps
29103424 bps
6003
29103424
0
0
0
0
0
0
0
0
0
0
0
pps
bps
pps
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
219
Queue: 5, Forwarding classes: Voice

Queued:
Packets
:
251820208
Bytes
:
55904084928
Transmitted:
Packets
:
251819728
Bytes
:
55903978368
451
29
Low
:
29
Medium-low
:
0
Medium-high
:
0
High
:
0
RED-dropped bytes
:
6438
Low
:
6438
Medium-low
:
0
Medium-high
:
0
High
:
0
Queued:
Packets
:
151311734
Bytes
:
44266374920
Transmitted:
Packets
:
151311734
Bytes
:
44266374920
0
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
RED-dropped bytes
:
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
Queued:
Packets
:
0
Bytes
:
0
Transmitted:
Packets
:
0
Bytes
:
0
0
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
RED-dropped bytes
:
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
220
3752 pps
6663872 bps
3752
6663872
0
0
0
0
0
0
0
0
0
0
0
pps
bps
pps
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
2010 pps
4920800 bps
2010
4920800
0
0
0
0
0
0
0
0
0
0
0
pps
bps
pps
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
0 pps
0 bps
0
0
0
0
0
0
0
0
0
0
0
0
0
pps
bps
pps
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
CHAPTER 8
Configuring the Network Management

System
Configuring the Network Management System
Configuration
Configuring System Logging
Step-by-Step
Procedure
Results
1.
[edit]
set system syslog host log kernel info
set system syslog host log any notice
set system syslog host log pfe info
set system syslog host log interactive-commands any
set system syslog file messages any any
set system syslog file messages kernel info
set system syslog file messages authorization info
set system syslog file messages pfe info
set system syslog file messages archive world-readable
set system syslog file security interactive-commands any
set system syslog file security archive world-readable
Verify that system logging is working as expected.

user@hub1> show log messages |last 10
Jul 9 17:15:00 wan-agg-1 /usr/sbin/cron[30645]: (root) CMD (newsyslog)
Jul 9 17:15:00 wan-agg-1 /usr/sbin/cron[30646]: (root) CMD (
/usr/libexec/atrun)
Jul 9 17:15:37 wan-agg-1 mgd[30580]: UI_CMDLINE_READ_LINE: User 'branch',
'quit '
Jul 9 17:15:38 wan-agg-1 mgd[30580]: UI_DBASE_LOGOUT_EVENT: User 'branch'
configuration mode
'show snmp statistics '
'show snmp statistics '
'show snmp mib walk sysName '
'show snmp mib walk jnxOperatingCPU '
'show snmp health-monitor '
'show log messages | last 10 '
command
exiting
command
command
command
command
command
command
221
Configuring SNMP
Step-by-Step
Procedure
Results
1.
set snmp location "Systest lab"

set snmp contact "Jay Lloyd"
set snmp interface fxp0.0
set snmp community public authorization read-only
set snmp community private authorization read-write
set snmp trap-group snmp1 version v2
set snmp trap-group snmp1 destination-port 8787
set snmp trap-group snmp1 categories authentication
set snmp trap-group snmp1 categories chassis
set snmp trap-group snmp1 categories link
set snmp trap-group snmp1 categories remote-operations
set snmp trap-group snmp1 categories routing
set snmp trap-group snmp1 categories startup
set snmp trap-group snmp1 categories vrrp-events
set snmp trap-group snmp1 categories configuration
set snmp trap-group snmp1 categories services
set snmp trap-group snmp1 targets 192.168.60.63
Verify that SNMP is working as expected.

1.
Check SNMP statistics.

user@hub1> show snmp statistic
SNMP statistics:
Input:
Packets: 10489, Bad versions: 0, Bad community names: 0,
Bad community uses: 0, ASN parse errors: 0,
Too bigs: 0, No such names: 0, Bad values: 0,
Read onlys: 0, General errors: 0,
Total request varbinds: 68127, Total set varbinds: 0,
Get requests: 1114, Get nexts: 5887, Set requests: 0,
Get responses: 0, Traps: 0,
Silent drops: 0, Proxy drops: 0, Commit pending drops: 0,
Throttle drops: 0, Duplicate request drops: 0
V3 Input:
Unknown security models: 0, Invalid messages: 0
Unknown pdu handlers: 0, Unavailable contexts: 0
Unknown contexts: 0, Unsupported security levels: 0
Not in time windows: 0, Unknown user names: 0
Unknown engine ids: 0, Wrong digests: 0, Decryption errors: 0
Output:
Packets: 109224, Too bigs: 0, No such names: 840,
Bad values: 0, General errors: 0,
Get requests: 0, Get nexts: 0, Set requests: 0,
Get responses: 10489, Traps: 98735
2. Verify MIBs.
user@hub1> show snmp mib walk sysName
sysName.0
= wan-agg-1
user@hub1> show snmp mib walk jnxOperatingCPU

jnxOperatingCPU.1.1.0.0 = 0
222
Chapter 8: Configuring the Network Management System
Configuring Junos Traffic Vision on the WAN Aggregation Router

Step-by-Step
Procedure
1.
Create a firewall filter to sample and accept traffic

[edit]
edit firewall family inet filter v4_sample
set term t1 then sample
set term t1 then accept
2.
Set forwarding-options, input rate, and external flow collector

[edit]
edit forwarding-options sampling instance Ins1
set input rate 1000
set family inet output flow-server 172.31.255.100 port 2055
set family inet output flow-server 172.31.255.100 version-ipfix template v4
set family inet output inline-jflow source-address 172.31.255.2
set family inet output inline-jflow flow-export-rate 100
3.
Set flow-monitoring service parameters

[edit]
edit services flow-monitoring
set version-ipfix template v4 flow-active-timeout 150
set version-ipfix template v4 flow-inactive-timeout 100
set version-ipfix template v4 template-refresh-rate seconds 10
set version-ipfix template v4 ipv4-template
4.
Taz Forwarding Engine Board parameters

[edit]
edit chassis tfeb
set slot 0 sampling-instance Ins1
Results
Verify that Junos Traffic Vision is working as expected.

user@hub1> show services accounting flow inline-jflow fpc-slot 4
Flow information
FPC Slot: 4
Flow Packets: 5018991, Flow Bytes: 2400737479
Active Flows: 25, Total Flows: 450
223
Flows Exported: 425, Flow Packets Exported: 306

Flows Inactive Timed Out: 205, Flows Active Timed Out: 220
user@hub1> show services accounting status inline-jflow
Status information
TFEB Slot: 0
Export format: IP-FIX
IPv4 Route Record Count: 30848, IPv6 Route Record Count: 31833
Route Record Count: 62681, AS Record Count: 4009
Route-Records Set: Yes, Config Set: Yes
user@hub1> show services accounting flow inline-jflow
Flow information
TFEB Slot: 0
Flow Packets: 0, Flow Bytes: 0
Active Flows: 0, Total Flows: 0
Flows Exported: 0, Flow Packets Exported: 0
Flows Inactive Timed Out: 0, Flows Active Timed Out: 0
user@hub1> show services accounting errors
Error information
Service Accounting interface: ms-2/0/0
Service sets dropped: 0, Active timeout failures: 0
Export packet failures: 0, Flow creation failures: 0
Memory overload: No
Configuring Junos Traffic Vision on the VPN Termination Router
Step-by-Step
Procedure
NOTE: Configuration of Junos Traffic Vision is enabled in-line on the MX

Series. This configuration is shown in Appendix A: Alternate Configuration
Aggregation and Branch using MX80 with Services MIC on page 737
1.
Configure traffic sampling that forwards data to a log file on the router.
[edit]
edit forwarding-options sampling
set input rate 1000
set family inet output file filename sample-ewan.log
set family inet output file size 10m
2.
Configure flow monitoring options

[edit]
edit services flow-monitoring version9
set template v4_template flow-active-timeout 200
set template v4_template flow-inactive-timeout 30
set template v4_template ipv4-template
3.
Configure flow monitoring filter

[edit]
edit firewall family inet filter v4_sample_filter
set term 1 then count sample_pkts
set term 1 then sample
224
Chapter 8: Configuring the Network Management System

4.
Add the filter to the following interfaces on the VPN termination router.
[edit]
edit interfaces
set ge-0/0/0 unit 0 family inet filter output v4_sample_filter
set ge-0/0/1 unit 0 family inet filter input v4_sample_filter
set gr-0/1/0 unit 1 family inet filter output v4_sample_filter
set sp-0/3/0 unit 1 family inet filter input v4_sample_filter
set sp-0/3/0 unit 2 family inet filter input v4_sample_filter
Results
Verify Jflow (Junos Traffic Vision) configuration on the interface

[edit interfaces sp-0/3/0]
regress@bike# show
unit 0 {
description "--- Jflow v9 ----";
family inet {
address 172.31.255.65/32;
Verify Junos Traffic Vision file creation and destinations.

user@hub1> file show /var/tmp/sample-ewan.log
# Sep 30 12:17:57
#
Dest
Src Dest
Src Proto
#
addr
addr port port
6.0.11.2
191.15.100.6
0
0
50
6.0.14.82
191.15.100.6
0
0
50
6.0.6.158
191.15.100.6
0
0
50
6.0.15.42
191.15.100.6
0
0
50
6.0.11.130
191.15.100.6
0
0
50
6.0.13.222
191.15.100.6
0
0
50
6.0.16.130
191.15.100.6
0
0
50
6.0.8.186
191.15.100.6
0
0
50
TOS
0x0
0x0
0x0
0x0
0x0
0x0
0x0
0x0
Pkt
len
312
312
312
312
312
312
312
312
Intf
num
1109
1109
1109
1109
1109
1109
1109
1109
IP
TCP
frag flags
0x0
0x0
0x0
0x0
0x0
0x0
0x0
0x0
0x0
0x0
0x0
0x0
0x0
0x0
0x0
0x0
. . .
225
226
CHAPTER 9
Adding Routing Engine Protection to the

Aggregation Hubs
Adding Routing Engine Protection to the Enterprise WAN Network
Overview
Routing Engine protection is a security measure that protects the enterprise infrastructure
from intrusion and peering with unknown hosts or malicious network nodes. The
configurations shown in this section are recommended to defend against DOS or DDOS
attacks, and to ensure that only permitted network nodes and hosts are able to
communicate and/or peer with the WAN infrastructure.
Configuring Routing Engine Protection on the Internet Edge Gateway on Aggregation Hub 1
Configuring Prefix Lists for Routing Engine Protection on the Internet Edge Gateway
on Aggregation Hub 1 on page 227
Configuring Firewall Filters for Routing Engine Protection on the Internet Edge Gateway
at Aggregation Hub 1 on page 228
Configuring Prefix Lists for Routing Engine Protection on the Internet Edge
Gateway on Aggregation Hub 1
Step-by-Step
Procedure
Create a set of prefix lists to be used in firewall filters that are set up for Routing Engine
protection. These prefix lists specify trusted IP subnets and addresses for different types
of traffic. Traffic received from these addresses is allowed through firewalls used for
Routine Engine protection.
1.
Create a prefix list for trusted subnets in the enterprise.

[edit]
edit policy-options prefix-list trusted-networks
set 10.0.0.0/8
set 172.16.0.0/12
set 189.1.4.0/24
set 191.15.100.0/24
set 191.15.200.0/24
set 192.168.0.0/16
2.
Create a prefix list for known BGP neighbors.

[edit]
227
edit policy-options prefix-list bgp-neighbors

set 198.51.100.1/32
3.
Create a prefix list for known BFD neighbors.

[edit]
edit policy-options prefix-list trusted-bfd-neighbor
set 172.31.254.0/24
4.
Create a prefix list for known network management systems.

[edit]
edit policy-options prefix-list NMS
set 10.0.0.0/8
set 172.16.0.0/12
set 192.168.0.0/16
Configuring Firewall Filters for Routing Engine Protection on the Internet Edge
Gateway at Aggregation Hub 1
Step-by-Step
Procedure
To secure the Routing Engine against , we are using a firewall filter. The filter is used to
prevent small packet attacks, fragment attacks, and denial of service (DoS) attacks from
specific protocols such as ICMP, BGP, OSPF, SNMP, UDP, and TCP. The filter accepts
traffic only from trusted sources, and it discards all other traffic. The filter also includes
a policer that applies rate limits to the traffic that is accepted by the filter.
Because loopback interfaces are a link to the Routing Engine, we will apply the firewall
filter to loopback interfaces at the aggregation hub, which means that the filter is applied
to traffic destined for the router control plane and not to transit traffic.
In addition to specifying traffic that is accepted, we are counting packets received from
different sources, and in some cases logging traffic. You can use counters and logs to
check that the filter is working as expected and to detect unusual amounts of certain
types of traffic.
1.
Create a policer to be used in the firewall filter.

[edit]
edit firewall policer limit-2m
set if-exceeding bandwidth-limit 3m
set if-exceeding burst-size-limit 2k
set then discard
2.
Create a firewall filter, and specify that counters defined in the filter are interface
specific.
[edit]
edit firewall family inet filter RE-PROTECT
set interface-specific
3.
Configure a term that prevents small packet attacks. It counts, logs, and discards
packets with a length of 0 through 24.
[edit]
set term small-packets from packet-length 0-24
set term small-packets then count small-packet-attack
228
Chapter 9: Adding Routing Engine Protection to the Aggregation Hubs
set term small-packets then log

set term small-packets then discard
4.
Configure a term that prevents fragment attacks. It counts, logs, and discards
packets that have a fragment offset.
[edit]
set term fragment-packets from fragment-offset-except 0
set term fragment-packets from protocol icmp
set term fragment-packets from protocol igmp
set term fragment-packets from protocol pim
set term fragment-packets from protocol tcp
set term fragment-packets then count frag-attack
set term fragment-packets then log
set term fragment-packets then discard
5.
Create a filter for ICMP traffic, which includes IPv4 error messages.
[edit]
set term icmp-in from source-prefix-list trusted-networks
set term icmp-in from protocol icmp
set term icmp-in then policer limit-2m
set term icmp-in then count icmp-in
set term icmp-in then accept
6.
Create a filter for BGP traffic.

[edit]
set term bgp-in from source-prefix-list trusted-bgp-peer
set term bgp-in from protocol tcp
set term bgp-in from port bgp
set term bgp-in then policer limit-2m
set term bgp-in then count bgp-in
set term bgp-in then accept
7.
Create a term for OSPF traffic.

[edit]
set term ospf-in from source-prefix-list trusted-ospf-neighbor
set term ospf-in from protocol ospf
set term ospf-in then policer limit-2m
set term ospf-in then count ospf-in
set term ospf-in then accept
8.
Create a filter for SNMP traffic.

[edit]
set term snmp-in from source-prefix-list trusted-networks
set term snmp-in from protocol udp
set term snmp-in from port snmp
set term snmp-in then policer limit-2m
set term snmp-in then count snmp-in
set term snmp-in then accept
9.
Create a term that controls SSH, FTP, and Telnet access to the router.
229
[edit]
set term access-in from source-prefix-list NMS
set term access-in from protocol tcp
set term access-in from port ssh
set term access-in from port ftp
set term access-in from port ftp-data
set term access-in from port telnet
set term access-in then count access-in
set term access-in then accept
10.
Create a term that accepts TCP and TACACS traffic from trusted network
management systems.
[edit]
set term remote-auth-tcp from source-prefix-list NMS
set term remote-auth-tcp from protocol tcp
set term remote-auth-tcp from port tacacs
set term remote-auth-tcp then count tacacs
set term remote-auth-tcp then accept
11.
Create a term that accepts UDP and RADIUS traffic from trusted network
management systems.
[edit]
set term remote-auth-udp from source-prefix-list NMS
set term remote-auth-udp from protocol udp
set term remote-auth-udp from port radius
set term remote-auth-udp from port radacct
set term remote-auth-udp then count radius
set term remote-auth-udp then accept
12.
Create a term that accepts UDP traffic from trusted neighbors.

[edit]
set term udp-services from source-prefix-list trusted-networks
set term udp-services from protocol udp
set term udp-services from source-port 1024-65535
set term udp-services then policer limit-2m
set term udp-services then count udp-in
set term udp-services then accept
13.
Create a filter for incoming traffic with a source and destination loopback address.
[edit]
set term loopback-in from source-address 127.0.0.1/32
set term loopback-in from destination-address 127.0.0.1/32
set term loopback-in then count loopback-in
set term loopback-in then accept
14.
Create a term that accepts BFD traffic from trusted neighbors.

[edit]
set term bfd from source-prefix-list trusted-bfd-neighbor
230
set term bfd from protocol udp

set term bfd from source-port 49152-65335
set term bfd from destination-port 3784-3785
set term bfd then count accept-bfd
set term bfd then accept
15.
Configure a term that explicitly discards all other traffic.

[edit]
set term deny-all then count illegal-traffic-in
set term deny-all then log
set term deny-all then discard
16.
Apply the filter to all loopback interfaces at Aggregation Hub 1. For example:
[edit]
set family inet filter input RE-PROTECT
17.

[edit]
commit
Results
Verify that the firewall filter is working as expected.

Notice that the firewall filter and counters have the interface-name and direction
appended to their names.
user@iedge-hub1> show firewall filter RE-PROTECT-lo0.0-i
Filter: RE-PROTECT-lo0.0-i
Counters:
Name
accept-bfd-lo0.0-i
access-in-lo0.0-i
bgp-in-lo0.0-i
frag-attack-lo0.0-i
icmp-in-lo0.0-i
illegal-traffic-in-lo0.0-i
loopback-in-lo0.0-i
ospf-in-lo0.0-i
radius-lo0.0-i
small-packet-attack-lo0.0-i
snmp-in-lo0.0-i
tacacs-lo0.0-i
udp-in-lo0.0-i
Policers:
Name
limit-2m-bgp-in-lo0.0-i
limit-2m-icmp-in-lo0.0-i
limit-2m-ospf-in-lo0.0-i
limit-2m-snmp-in-lo0.0-i
limit-2m-udp-services-lo0.0-i
Bytes
0
1600543
375737
0
162540
4212044
0
0
0
0
38850
0
22698584
Packets
0
29518
4618
0
2828
22054
0
0
0
0
512
0
138406
Bytes
0
0
0
0
0
Packets
0
0
0
0
0
231
Configuring Routing Engine Protection on the WAN Aggregation Router on Aggregation Hub 1
Configuring Prefix Lists for Routing Engine Protection on the WAN Aggregation
Router on page 232
Configuring Firewall Filters Used for Routing Engine Protection at on the WAN
Aggregation Router on Aggregation Hub 1 on page 233
Configuring Policers for Routing Engine Protection on Aggregation Hub 2 on page 237
Configuring Prefix Lists for Routing Engine Protection on the WAN Aggregation
Router
Step-by-Step
Procedure
1.
Create a prefix list for trusted subnets in the enterprise.

[edit]
set 10.0.0.0/8
set 172.16.0.0/12
set 189.1.4.0/24
set 191.15.100.0/24
set 191.15.200.0/24
set 192.168.0.0/16
2.
Create a prefix list for trusted BGP peers.

[edit]
edit policy-options prefix-list trusted-bgp-peer
set 172.16.0.0/12
3.
Create a prefix list for known OSPF neighbors.

[edit]
edit policy-options prefix-list trusted-ospf-neighbor
set 172.16.0.0/12
4.

[edit]
set 172.31.254.0/24
5.
Create a prefix list for known PIM neighbors.

[edit]
edit policy-options prefix-list trusted-pim-neighbor
set 172.16.0.0/12
6.
Create a prefix list for known NMS devices.

[edit]
set 10.0.0.0/8
set 172.16.0.0/12
set 192.168.0.0/16
232
Configuring Firewall Filters Used for Routing Engine Protection at on the WAN
Aggregation Router on Aggregation Hub 1
Step-by-Step
Procedure
To secure the Routing Engine against network attacks, we are using a firewall filter. The
filter is used to prevent small packet attacks, fragment attacks, and denial of service
(DoS) attacks from specific protocols such as ICMP, BGP, OSPF, SNMP, UDP, and TCP.
The filter accepts traffic only from trusted sources, and it discards all other traffic. The
filter also includes a policer that applies rate limits to the traffic that is accepted by the
filter.
types of traffic.
1.
Create a policer to be used in the firewall filter.

[edit]
set if-exceeding bandwidth-limit 2500000
set then discard
2.
specific.
[edit]
3.
Configure a term that prevents small packet attacks. It counts, logs, and discards
packets with a length of 0 through 24.
[edit]
4.
Configure a term that prevents fragment attacks. It counts, logs, and discards
packets that have a fragment offset.
[edit]
233

5.
Create a term for ICMP traffic, which includes IPv4 error messages.
[edit]
6.
Create a term for BGP traffic.

[edit]
7.
Create a term for OSPF traffic.

[edit]
8.

[edit]
9.
Create a term for PIM.

[edit]
set term pim from source-prefix-list trusted-pim-neighbor
set term pim from protocol pim
set term pim then policer limit-2m
set term pim then count pim
set term pim then accept
10.
Configure a term for MSDP.

[edit]
set term msdp from source-prefix-list trusted-pim-neighbor
set term msdp from protocol tcp
234
set term msdp from port msdp

set term msdp then policer limit-2m
set term msdp then count msdp
set term msdp then accept
11.
Create a term that controls SNMP access from trusted network management
systems.
[edit]
set term snmp-in from source-prefix-list trusted-networks
set term snmp-in from source-prefix-list NMS
12.
[edit]
13.
management systems.
[edit]
14.
management systems.
[edit]
15.

[edit]
235

16.
Create a filter for incoming traffic with a source and destination loopback address.
[edit]
17.

[edit]
18.
Apply the filter to all loopback interfaces on the WAN aggregation router. For
example:
[edit]
set family inet filter input RE-PROTECT
19.

[edit]
commit
Results

user@HEAD-END2#run show firewall filter RE-PROTECT-lo0.2-i
Counters:
Name
Bytes
IPsec-lo0.2-i
0
accept-bfd-lo0.2-i
0
access-in-lo0.2-i
2151
bgp-in-lo0.2-i
163
frag-attack-lo0.2-i
0
icmp-in-lo0.2-i
0
241
loopback-in-lo0.2-i
0
msdp-lo0.2-i
988
ospf-in-lo0.2-i
23064
pim-lo0.2-i
270
radius-lo0.2-i
0
0
snmp-in-lo0.2-i
0
tacacs-lo0.2-i
0
udp-in-lo0.2-i
20228
Policers:
236
Packets
0
0
41
2
0
0
1
0
14
38
5
0
0
0
0
277
Name
limit-2m-IPsec-lo0.2-i
limit-2m-msdp-lo0.2-i
limit-2m-pim-lo0.2-i
Bytes
0
0
0
0
748
0
0
0
Packets
0
0
0
0
1
0
0
0
Configuring Policers for Routing Engine Protection on Aggregation Hub 2

Step-by-Step
Procedure
1.
Create a policer that discards traffic that exceeds a bandwidth of 100 Mbps or a
burst size of 3 million bytes.
The management policer management-1m will restrict traffic to 1 Mbps and discard
any packets that exceed this bandwidth limit. This policer will be applied to protocols
such as NTP, traceroute, RADIUS, TACAS+, and telnet. Traditionally these protocols
do not require high throughput so they are a good candidate for this policer:
[edit]
edit firewall policer management-1m
set if-exceeding burst-size-limit 3m
set then discard
2.
Configure a prefix-specific policing and counting action that references the policer
and specifies a portion of a source address prefix.
Specify the prefix range on which IPv4 addresses are to be indexed to the counter
and policer set
Set the prefix-specific action or policer to operate in filter-specific mode, meaning
that all filter terms that reference the prefix-specific action share the same policer
and counter.
[edit]
edit firewall family inet prefix-action management-high-police-set
set policer management-5m
set count
set filter-specific
set subnet-prefix-length 24
set destination-prefix-length 32
3.
Configure a prefix-specific policing and counting action that references the policer
and specifies a portion of a source address prefix.
and policer set
and counter.
[edit]
edit firewall family inet prefix-action management-police-set
set count
237
set filter-specific
4.
Create a policer that discards traffic that exceeds a bandwidth of 100 Mbps or a
burst size of 3 million bytes.
[edit]
set then discard
Configuring Routing Protection at Aggregation Hub 2
Configuring Prefix Lists for Routing Engine Protection on page 238
Configuring Firewall Filters Used on Loopback Interfaces for Routing Engine Protection
at Aggregation Hub 2 on page 239
Configuring Policers for Routing Engine Protection on Aggregation Hub 2 on page 243
Configuring Prefix Lists for Routing Engine Protection

Step-by-Step
Procedure
1.
Create a prefix list for trusted networks in the enterprise.

[edit]
set 10.0.0.0/8
set 172.16.0.0/12
set 189.1.4.0/24
set 191.15.100.0/24
set 191.15.200.0/24
set 192.168.0.0/16
2.
Create a prefix list for known BGP peers.

[edit]
edit policy-options prefix-list trusted-bgp-peer
set 172.16.0.0/12
set 191.15.200.0/24
3.
Create a prefix list for known OSPF neighbors.

[edit]
edit policy-options prefix-list trusted-ospf-neighbor
set 172.16.0.0/12
4.

[edit]
set 172.31.254.0/24
set 172.31.255.0/24
238
5.
Create a prefix list for known multicast neighbors.

[edit]
edit policy-options prefix-list trusted-pim-neighbor
set 172.16.0.0/12
6.
Create a prefix for known IPsec clients.

[edit]
edit policy-options prefix-list IPsec-Clients
set 1.0.0.0/8
set 2.0.0.0/8
set 3.0.0.0/8
set 4.0.0.0/8
set 5.0.0.0/8
set 6.0.0.0/8
7.
Create a prefix list for known network management traffic.

[edit]
set 10.0.0.0/8
set 172.16.0.0/12
set 192.168.0.0/16
Configuring Firewall Filters Used on Loopback Interfaces for Routing Engine

Protection at Aggregation Hub 2
Step-by-Step
Procedure
To secure the Routing Engine against , we are using a firewall filter. The filter is used to
prevent small packet attacks, fragment attacks, and denial of service (DoS) attacks from
traffic only from trusted sources, and it discards all other traffic. The filter also includes
a policer that applies rate limits to the traffic that is accepted by the filter.
types of traffic.
1.
Create a policer to be used in firewall filter terms.

[edit]
set then discard
2.
specific.
[edit]
239
3.
Create a term for IPsec traffic.

[edit]
set term IPsec from source-prefix-list IPsec-Clients
set term IPsec from protocol udp
set term IPsec from port 500
set term IPsec then policer limit-2m
set term IPsec then count IPsec
set term IPsec then accept
4.
Create a term for BGP traffic.

[edit]
5.
Create a term for MSDP.

[edit]
set term msdp from source-prefix-list trusted-pim-neighbor
set term msdp from protocol tcp
set term msdp from port msdp
set term msdp then policer limit-2m
set term msdp then count msdp
set term msdp then accept
6.
Create a term that accepts traffic from trusted PIM neighbors.

[edit]
set term pim from source-prefix-list trusted-pim-neighbor
set term pim then policer limit-2m
7.
Create a term that accepts OSPF traffic from trusted OSPF neighbors.
[edit]
8.

[edit]
240

9.
Create a term for SNMP traffic.

[edit]
10.
Create a term for ICMP traffic, which includes IPv4 error messages.
[edit]
11.
[edit]
12.
management systems.
[edit]
13.
management systems.
[edit]
241

14.

[edit]
15.
Create a term for incoming traffic with a source and destination loopback address.
[edit]
16.
Configure a term that prevents small packet attacks.

[edit]
17.
Configure a term that prevents fragment attacks.

[edit]
18.

[edit]
19.
Apply the filter to loopback interfaces at Aggregation Hub 2. For example:

[edit]
set interfaces lo0 unit 2 family inet filter input RE-PROTECT
20.
242
[edit]
commit
Results

user@hub2>show firewall filter RE-PROTECT-lo0.2-i
Counters:
Name
IPsec-lo0.2-i
accept-bfd-lo0.2-i
access-in-lo0.2-i
bgp-in-lo0.2-i
frag-attack-lo0.2-i
icmp-in-lo0.2-i
loopback-in-lo0.2-i
msdp-lo0.2-i
ospf-in-lo0.2-i
pim-lo0.2-i
radius-lo0.2-i
snmp-in-lo0.2-i
tacacs-lo0.2-i
udp-in-lo0.2-i
Bytes
0
0
2151
163
0
0
241
0
988
23064
270
0
0
0
0
20228
Packets
0
0
41
2
0
0
1
0
14
38
5
0
0
0
0
277
Policers:
Name
limit-2m-IPsec-lo0.2-i
Bytes
0
0
0
0
748
0
0
0
Packets
0
0
0
0
1
0
0
0
Configuring Policers for Routing Engine Protection on Aggregation Hub 2

Step-by-Step
Procedure
1.
Create a policer that discards traffic that exceeds a bandwidth of 100 MB or a burst
size of 3 MB.
[edit]
set then discard
2.
Configure a prefix-specific action that references the policer and specifies a portion
of a source address prefix.
and policer set.
243

and counter.
[edit]
edit firewall family inet prefix-action management-police-set
set count
set filter-specific
3.
Create a policer that discards traffic that exceeds a bandwidth of 100m bps or a
burst size of 3m bytes.
[edit]
set then discard
4.
Configure a prefix-specific action that references the policer and specifies a portion
of a source address prefix.
and policer set.
and counter.
[edit]
edit firewall family inet prefix-action management-high-police-set
set count
set filter-specific
244
CHAPTER 10
Connecting a Small Branch to Aggregation

Hub 1 over Leased-Lines
Connecting a Small Branch to Aggregation Hub 1 over Leased-Lines
Requirements
This example uses the following hardware and software components at the branch:
MX80 3D Universal Edge Router with the following MICs/PICs
4-Port 10-Gigabit Ethernet MIC with XFP
8-Port Channelized SONET/SDH OC3/STM1 (Multi-Rate) MIC with SFP
Two 10-Gigabit Ethernet LAN/WAN PIC with SFP (10x 1GE(LAN) SFP)
Junos OS Release 12.3R2 or later
Overview
This design is a small branch with a single router that connects to the aggregation hub
over leased lines (Figure 71 on page 246).
The leased line WAN transport can be either T3 leased lines or Ethernet leased lines.
The scenario describes how both types of leased lines.
The private routing protocol used on the WAN transport is a choice of IBGP or OSPF
over the leased line to the aggregation hub.
OSPF received default route is configured over leased line interfaces to reach the WAN
aggregation hub.
All traffic sent from the branch (to the data center, the Internet, or other branches)
uses the 0.0.0.0/0 route received over the leased line interface.
The routing protocol used on the branch LAN is OSPF.
Link-level high availability is provided by Bidirectional Forwarding Detection (BFD)

configured for the routing protocol.
CoS scheduling and shaping is applied to the leased line interface at the branch.
245
Topology
Figure 71: Remote Site Test Topology Using Leased-Line Transport
246
Chapter 10: Connecting a Small Branch to Aggregation Hub 1 over Leased-Lines
Configuration Overview
Step-by-Step
Procedure
Before you configure this scenario, configure the base configuration at aggregation hub 1.
Then complete the following:
Configuring the WAN Aggregation Router at Aggregation Hub 1 on page 247
Configuring the Branch Router on page 253
Configuring T3 Leased-Line WAN Transport on the WAN Aggregation Router at

Aggregation Hub 1 on page 248
Configuring Ethernet Leased-Line WAN Transport on the WAN Aggregation Router at

Configuring OSPF Routing for the WAN Transport on the WAN Aggregation Router at
Configuring IBGP Routing for the WAN Transport on the WAN Aggregation Router at
Configuring BGP Link-Level High Availability for the WAN Transport on the WAN
Aggregation Router at Aggregation Hub 1 on page 252
Configuring OSPF Link-Level High Availability for the WAN Transport on the WAN
Aggregation Router at Aggregation Hub 1 on page 253
247
Configuring T3 Leased-Line WAN Transport on the WAN Aggregation Router at

Aggregation Hub 1
Step-by-Step
Procedure
Figure 72: Leased-Line Remote Branch Configuration
1.
Configure the channelized T3 interfaces.

a. Create a channelized OC1 interface as a clear channel interface by setting the
no-partition option for the sublevel interface type to t3. A clear channel
consolidates the entire bandwidth of a channelized interface into a single

unpartioned stream that looks like a standard interface.
[edit]
edit interfaces coc1-1/0/1:1
set no-partition interface-type t3
b. Configure the channelized OC3 interface by creating three partitions, each with
an OC slice, and with the sublevel interface type set to coc1.

[edit]
edit interfaces coc3-1/0/1
set partition 1 oc-slice 1
set partition 1 interface-type coc1
c. Create a T3 interface out of channelized OC1 interfaces.
[edit]
edit interfaces t3-1/0/1:1
set dce
set encapsulation frame-relay
set unit 0 point-to-point
set unit 0 dlci 101
248

2.
Configure the channelized T1 interface.

a. T1 interfaces, partition the channelized T3 interface into T1 interfaces.
[edit]
edit interfaces ct3-1/0/1:2
set partition 1-28 interface-type t1
[edit]
edit interfaces ct3-1/0/1:3
set partition 1-28 interface-type t1
b. Create the T1 interface.
[edit]
edit interfaces t1-1/0/1:2:1
set no-keepalives
set encapsulation cisco-hdlc
set t1-options fcs 32
3.
Create the loopback interface.

The primary address is the address that is used by default as the local address for
packets sourced locally and sent out the interface.
[edit]
edit interfaces lo0.0
Configuring Ethernet Leased-Line WAN Transport on the WAN Aggregation Router

at Aggregation Hub 1
Step-by-Step
Procedure
1.
Configure VLAN interfaces to each branch. Enable hierarchical scheduling on the

interfaces.
[edit]
set description "---LeasedLine Branches ---"
set vlan-tagging
249

2.
Create the loopback interface.

The primary address is the address that is used by default as the local address for
packets sourced locally and sent out the interface.
[edit]
edit interfaces lo0.0
Configuring OSPF Routing for the WAN Transport on the WAN Aggregation Router
Step-by-Step
Procedure
If you are using OSPF as your routing protocol, follow this procedure.
1.
If you are using T3 leased lines, configure the OSPF area for the IPv4 transport to
the branch:
[edit]
set stub default-metric 10
set stub no-summaries
set interface t3-1/0/1:1.0 interface-type p2p
set interface t3-1/0/1:1.0 authentication md5 0 key
"$9$LrL7dwoJU.PTApv8X7bwmP5"
2.
If you are using Ethernet leased lines, configure the OSPF area for the transport to
the branch:
[edit]
"$9$LrL7dwoJU.PTApv8X7bwmP5"
3.
If you are using T3 leased lines, configure the OSPFv3 area for the IPv6 transport
to the branches:
[edit]
250

set interface t3-1/0/1:1.0 interface-type p2p
4.
If you are using Ethernet leased lines, configure the OSPFv3 area for the IPv6
transport to the branches:
[edit]
Configuring IBGP Routing for the WAN Transport on the WAN Aggregation Router
Step-by-Step
Procedure
Figure 73: Routing and Interface Configuration for Leased-Line Branches
If you are using BGP as your routing protocol, follow this procedure.
Configure IBGP groups for peering between the WAN aggregation router at the hub and
the branch. The policies have already been configured in the Aggregation Hub 1 base
configuration.
1.
Configure an IBGP peer group for IPv4 traffic for leased line branches.
The ADV_DEFAULT and the DENY_ALL policies cause BGP to advertise only the
default route to the branch. It prevents the branch from receiving advertisements
for routes to other branches.
251
The cluster statement causes the IBGP peer at the aggregation hub to act as a BGP
route reflector.
Instead of configuring a neighbor for each branch, we are using the allow statement,
which allows all peers in 172.17.0.0/16.
[edit]
edit protocols bgp group To_LL_Branches
set type internal
set passive
set out-delay 150
set export DENY_ALL
set cluster 0.0.0.9
set allow 172.17.0.0/16
2.
Configure an IBGP peer group for IPv6 traffic for all leased line branches.
The ADV_DEFAULT6 policy causes BGP to advertise only the default route to the
branch.
route reflector.
Instead of configuring a neighbor for each branch, we are using the allow statement,
which allows all peers in fc00:0/8.
[edit]
edit protocols bgp group To_LL_Branches-V6
set type internal
set passive
set out-delay 150
set export ADV_DEFAULT6
set export DENY_ALL
set cluster 0.0.0.10
set allow fc00:0/8
Configuring BGP Link-Level High Availability for the WAN Transport on the WAN
Aggregation Router at Aggregation Hub 1
Step-by-Step
Procedure
We are using BFD with BGP to detect link failures over the leased lines.
Set the minimum transmit and receive interval for failure detection. This interval is the
minimum time after which the local routing device transmits hello packets and the
minimum interval after which the routing device expects to receive a reply from the
neighbor with which it has established a BFD session.
Set a multiplier for hello packets, which is the number of hello packets that are not
received by a neighbor, which causes the originating interface to be declared down.
1.
Configure BFD liveness detection in the To_LL_Branches group.

[edit]
252
edit protocols bgp group To_LL_Branches

Configuring OSPF Link-Level High Availability for the WAN Transport on the WAN
Aggregation Router at Aggregation Hub 1
Step-by-Step
Procedure
We are using the BFD protocol with OSPF to detect link failures over the leased lines.
1.
If you are using T3 interfaces, in OSPF area 0.0.0.6, add BFD liveness detection to
the T3 interface.
[edit]
set interface t3-1/0/1:1.0 bfd-liveness-detection minimum-interval 200
set interface t3-1/0/1:1.0 bfd-liveness-detection multiplier 3
2.
If you are using Ethernet interfaces, in OSPF area 0.0.0.6, add BFD liveness detection
to the Ethernet interface.
[edit]
Configuring the Branch Router

Configuring the Router ID on the Branch Router
Step-by-Step
Procedure
1.

[edit]
Configuring T3 Leased-Line WAN Transport on the Branch Router

Step-by-Step
Procedure
If you are using T3 leased lines, use this procedure.

1.
Configure the T3 interface.

[edit]
edit interfaces t3-1/0/0
set per-unit-scheduler
set mtu 4700
253
2.
Create the loopback interface to the WAN aggregation router on aggregation hub 1.
[edit]
set description "--- Leased-Line Branch ---"
set family inet filter input RE-PROTECTION
set family inet6 address fec0:16:5::255/128
3.

[edit]
commit
Results
Verify that the T3 WAN transport is running:

user@branch> show interfaces t3-1/0/0 terse
Interface
Admin Link Proto
t3-1/0/0
t3-1/0/0
up
up
inet
inet6
Local
Remote
172.16.5.2/30
fe80::5e5e:ab10:e:456f/64
fec0:16:5:1::2/64
user@branch> show interfaces t3-1/0/0

Physical interface: t3-1/0/0
Logical interface t3-1/0/0 (Index 327) (SNMP ifIndex 671)
Flags: Point-To-Point SNMP-Traps Encapsulation: FR-NLPID
Input packets : 17710249961
Output packets: 17712337736
Protocol inet, MTU: 4470
Destination: 172.16.5.0/30, Local: 172.16.5.2, Broadcast: 172.16.5.3
Protocol inet6, MTU: 4470
Destination: fe80::/64, Local: fe80::5e5e:ab10:e:456f
Destination: fec0:16:5:1::/64, Local: fec0:16:5:1::2
DLCI 101
Flags: Active, DCE-Configured
Total down time: 174:39:31 sec, Last down: 322:28:15 ago
DLCI statistics:
Active DLCI :1 Inactive DLCI :0
Configuring Ethernet Leased-Line WAN Transport on the Branch Router

Step-by-Step
Procedure
If you are using Ethernet leased lines, use this procedure.

1.
Configure the Ethernet interface.

[edit]
2.
254
Create the loopback interface to the WAN aggregation router on aggregation hub 1.
[edit]
set description "--- Leased-Line Branch ---"
set family inet filter input RE-PROTECTION
3.

[edit]
commit
Results
Verify that the Ethernet WAN transport is running :

user@branch> show interfaces ge-1/0/0 terse
Interface
Admin Link Proto
ge-1/0/0
up
up
ge-1/0/0
up
up
inet
inet6
Local
Remote
172.16.5.2/30
fe80::5e5e:abff:fe0e:4505/64
fec0:16:5:1::2/64
multiservice
user@branch> show interfaces ge-1/0/0

Link-level type: Ethernet, MTU: 1514, Speed: 1000mbps, BPDU Error: None,
MAC-REWRITE Error: None,
Loopback: Disabled, Source filtering: Disabled, Flow control: Enabled,
Auto-negotiation: Enabled,
Remote fault: Online
Device flags
: Present Running
Link flags
: None
CoS queues
Last flapped
: 2013-07-09 04:49:00 PDT (5w0d 09:43 ago)
Input rate
: 60030912 bps (21998 pps)
Output rate
: 85198872 bps (25749 pps)
Configuring OSPF Routing for the WAN Transport on the Branch Router
Step-by-Step
Procedure
If you are using OSPF to route traffic over the WAN transport from the branch to the
aggregation hub, use this procedure.
We are configuring the OSPF areas as stub areas to prevent advertisement of routes to
other branches.
For security, MD5 authenticates OSPF protocol exchanges to guarantee that only trusted
routing devices participate in the ASs routing.
1.
Configure OSPF.
a. Create OSPF area 0.0.0.6.
[edit]
255
b. Specify that the area is a stub area to prevent routes in the branch LAN from
being advertised to the aggregation hub.

[edit protocols ospf area 0.0.0.6]
set stub
c. Add the leased line interface, and include an MD5 authentication key for the
interfaces, with a key ID of 0.

transmitted packet. Both the receiving and transmitting routing devices must
have the same MD5 key. You define an MD5 key for each interface. If MD5 is
enabled on an interface, that interface accepts routing updates only if MD5
authentication succeeds. Otherwise, updates are rejected. The routing device
accepts only OSPFv2 packets sent using the same key ID that is defined for that
interface.
To add the T3 leased line:
set interface t3-1/0/0 interface-type p2p
set interface t3-1/0/0 authentication md5 0 key "$9$iqPT69tIESLxGjHq5TREc"
To add the Ethernet leased line:

set interface ge-1/0/0 interface-type p2p
set interface ge-1/0/0 authentication md5 0 key "$9$iqPT69tIESLxGjHq5TREc"
d. Add the loopback interface to the OSPF area.

set interface lo0.1
2.
Configure OSPFv3.
a. Create area 0.0.0.6. This area is used on the branch LAN and on the leased line
transport.
[edit protocols ospf3]
edit area 0.0.0.6
b. Create area 0.0.0.6. This area is used on the branch LAN and on the leased line
transport.
[edit protocols ospf3 area 0.0.0.6]
set stub
c. Add the leased line interface to the area.
A passive interface is one for which the address information is advertised as an

internal route in OSPF, but on which the protocol does not run.
To add the T3 leased line interface:
set interface t3-1/0/0 passive
To add the Ethernet leased line interface:
256

set interface ge-1/0/0 passive
d. Commit the configuration.
[edit]
commit
Results
This procedure displays the output for T3 leased lines. Use the same procedure to verify
Ethernet leased lines.
1.
Verify that OSPF is running on the leased line interfaces.

user@branch> show ospf neighbor
Address
Interface
172.16.5.1
t3-1/0/0
State
Full
ID
172.31.255.2
user@branch> show ospf neighbor detail

Address
Interface
State
ID
172.16.5.1
t3-1/0/0
Full
172.31.255.2
Area 0.0.0.6, opt 0x50, DR 0.0.0.0, BDR 0.0.0.0
Up 1w0d 06:33:02, adjacent 1w0d 06:33:02
Pri
Dead
128
31
Pri
128
Dead
32
2. Verify that OSPFv3 is running over the leased line interfaces.

user@branch> show ospf3 neighbor
ID
Interface
State
Pri
Dead
172.31.255.2
t3-1/0/0
Full
128
36
Neighbor-address fe80::5e5e:ab10:40e:426f
3. Verify the routes learned from OSPF over the leased lines from the aggregation hub.
user@branch> show route protocol ospf
0.0.0.0/0
172.16.5.0/30
224.0.0.5/32
*[OSPF/10] 1w0d 09:37:50, metric 12

> via t3-1/0/0
[OSPF/10] 1w0d 09:37:59, metric 2
> via t3-1/0/0
*[OSPF/10] 1w0d 09:42:25, metric 1
MultiRecv

::/0
2001:DB8:5:1::/64
ff02::5/128
*[OSPF3/10] 1w0d 09:37:50, metric 12

> via t3-1/0/0
[OSPF3/10] 1w0d 09:37:59, metric 2
> via t3-1/0/0
*[OSPF3/10] 1w0d 09:42:25, metric 1
MultiRecv
4. Verify the routes learned from OSPFv3 over the leased line interfaces from the
aggregation hub.
user@branch> show route protocol ospf3
257
::/0
2001:DB8:5:1::/64
ff02::5/128
*[OSPF3/10] 1w0d 09:40:02, metric 12

> via t3-1/0/0
[OSPF3/10] 1w0d 09:40:11, metric 2
> via t3-1/0/0
*[OSPF3/10] 1w0d 09:44:37, metric 1
MultiRecv
Configuring IBGP Peering on the WAN Transport on the Branch Router

Step-by-Step
Procedure
If you are using BGP to route traffic over the WAN transport from the branch to the
aggregation hub, use this procedure.
1.
Configure the autonomous system number for the router.

[edit]
2.
Configure a policy that is used to accept only default IPv4 routes.

[edit]
edit policy-options policy-statement ACCEPT_DEFAULT
3.
Configure a policy that is used to accept only default IPv6 routes.

[edit]
4.
Configure a policy that is used to control IPv4 routes that are advertised to the
aggregation hub.
This policy prevents the default static route from being advertised, and assigns the
next hop for routes learned by other protocols to next-hop self, which causes the
loopback address of the branch router to be advertised as the next-hop address.
[edit]
edit policy-options policy-statement BRANCH-PREFIX
set term block-default from route-filter 0.0.0.0/0 exact
set term block-default then reject
set term branch from protocol ospf
set term branch from protocol direct
set term branch then next-hop self
set term branch then accept
5.
aggregation hub.
This policy prevents the default static route from being advertised and allows OSPF
and direct routes to be advertised.
[edit]
258
edit policy-options policy-statement BRANCH-PREFIX6

set term block-default from family inet6
set term block-default from route-filter ::/0 exact
set term branch from protocol ospf3
6.
Configure an IPv4 IBPG peer group, and add the remote end of the leased line at
the aggregation hub (172.16.5.1).
The ACCEPT_DEFAULT import policy accepts only the default route from the hub,
which prevents routes from other branches from being distributed to the branch.
The BRANCH-PREFIX export policy controls default route advertisement to the
hub. It prevents default routes learned by another protocol from being advertised
to the hub, and causes the loopback address of the branch router to be advertised
to the hub as the next hop.
[edit]
edit protocols bgp group IBGPoLL
set type internal
set import ACCEPT_DEFAULT
set export BRANCH-PREFIX
set neighbor 172.16.5.1 authentication-key "$9$BlaRcrWL7s2ok.pO1RyrY24"
7.
Configure an IPv6 IBGP peer group to the remote end of the leased line.
The ACCEPT_DEFAULT-V6 import policy accepts only the default route from the
hub, which prevents routes from other branches from being distributed to the branch.
The BRANCH-PREFIX-V6 export policy controls default route advertisement to the
to the hub.
[edit]
edit protocols bgp group IBGPoLL-H2-V6
set type internal
set import ACCEPT_DEFAULT-V6
set export BRANCH-PREFIX-V6
set neighbor fec0:16:2:4::1 authentication-key "$9$JxUiqTznp01evgaZUkqu0B"
8.
Commit the configuration .

[edit]
commit
259
Results
Verify IBGP.
1.
Verify the IBGP peer to the T3 interface on the aggregation hub.

user@branch> show bgp summary
Table
History Damp State
Pending
inet.0
1
1
0
0
0
0
inet6.0
0
0
0
0
0
0
Peer
AS
InPkt
OutPkt
OutQ
Flaps Last Up/Dwn
172.16.5.1
555
793
798
0
1
6:01:07
Establ
inet.0: 1/1/1/0
Configuring the LAN Transport on the Branch Router

Step-by-Step
Procedure
Configure the Ethernet interfaces to the branch LAN.

There are three logical interfaces: one for data, one for video, and one for voice.
Configure the interfaces to include the Layer 2 overhead size for both ingress and egress
interfaces. Both the transit and total statistical information is computed and displayed
for each logical interface with the show interfaces command under the Ingress account
overhead and Egress account overhead fields.
1.
Configure an interface for data traffic.

[edit]
edit interfaces ge-1/2/9 unit 45
set account-layer2-overhead ingress 22
set account-layer2-overhead egress 22
set description set description "--- Data VLAN 45 ---"
set vlan-id 45
set family inet6 address fec0:16:1:45::1/64

260
2.
Configure an interface for video traffic.

[edit]
set description "--- VIDEO VLAN 55 ---"
set vlan-id 55
3.
Configure an interface for voice traffic.

[edit]
set description "---VOICE VLAN 65 ---"
set vlan-id 65
4.

[edit]
commit
Results
Verify that the LAN interfaces are running.

Physical interface: ge-1/2/9
Logical interface ge-1/2/9.45 (Index 339) (SNMP ifIndex 925)
Description: --- Data VLAN 45 --Flags: SNMP-Traps 0x0 VLAN-Tag [ 0x8100.45 ] Encapsulation: ENET2
22 bytes
:
22 bytes
Flags: Sendbcast-pkt-to-re, Is-Primary
Flags: Is-Primary
Destination: fe80::/64, Local: fe80::5e5e:ab00:2d0e:4509
Protocol multiservice, MTU: Unlimited
Description: --- VIDEO VLAN 55 --Flags: SNMP-Traps 0x0 VLAN-Tag [ 0x8100.55 ] Encapsulation: ENET2
22 bytes
:
22 bytes
261

Flags: Sendbcast-pkt-to-re
Destination: fe80::/64, Local: fe80::5e5e:ab00:370e:4509
Description: --- VOICE VLAN 65--Flags: SNMP-Traps 0x0 VLAN-Tag [ 0x8100.65 ] Encapsulation: ENET2
22 bytes
:
22 bytes
Configuring OSPF Routing for the LAN Transport on the Branch Router
Step-by-Step
Procedure
If you are using OSPF as the routing protocol for the branch, use this procedure.
1.
Add the branch LAN interfaces as passive interfaces to the branch OSPF area.
[edit]
set interface ge-1/2/9.45 passive
2.

[edit]
commit
Results
Verify that OSPF is running on the branch LAN.

user@branch> show ospf route extensive
Topology default Route Table:
Prefix
Path Route
NH
Metric NextHop
Type Type
Type
Interface
area 0.0.0.6, origin 172.16.5.255, priority medium
172.16.5.8/30
Intra Network
IP
1 ge-1/2/9.45
area 0.0.0.6, origin 172.16.5.255, priority low
262
Nexthop
Address/LSP
172.16.5.12/30
Intra Network
IP
1 ge-1/2/9.55
172.16.5.16/30
Intra Network
IP
1 ge-1/2/9.65
172.16.5.255/32
Intra Network
IP
0 lo0.1
Configuring Multicast on the Branch Router

Step-by-Step
Procedure
1.
Specify the static rendezvous point at Aggregation Hub 1.

[edit]
edit protocols pim
2.
Configure multicast on the branch LAN interfaces.

[edit protocols pim]
edit protocols pim
3.
Configure multicast on the leased lines.

If you are using T3 leased lines:
set interface t3-1/0/0.0 version 2
If you are using Ethernet leased lines:

set interface ge-1/0/0 version 2
4.

[edit]
commit
Results
The output in this section shows multicast on T3 leased lines.

1.
Verify multicast over the leased line interfaces.

user@branch>show pim neighbors
Interface
IP V Mode
t3-1/0/0
4 2
t3-1/0/0
6 2
Option
HPLGT
HPLGT

00:04:21 172.16.5.1
00:04:21 fe80::5e5e:ab10:40e:426f
2. Verify that groups are established with upstream interfaces to the hub (t3-1/0/0) and
downstream interfaces to the branch LAN (ge-1/2/9).

user@branch> show multicast route extensive
Group: 235.1.1.1
Source: 172.31.252.10/32
263
Upstream interface: t3-1/0/0

ge-1/2/9.45
Next-hop ID: 262143
Route state: Active
Uptime: 05:32:25
Group: 235.1.1.2
Source: 172.31.252.10/32
Upstream interface: t3-1/0/0
ge-1/2/9.45
Next-hop ID: 262143
Route state: Active
Uptime: 05:32:25
Configuring CoS on the Branch Router

Step-by-Step
Procedure
1.
a. Configure DSCP behavior aggregate (BA) classifiers for IPv4.
[edit]
set forwarding-class Best_Effort loss-priority medium-high code-points be
set forwarding-class Scavenger loss-priority high code-points cs1
set forwarding-class Bulk_Data loss-priority medium-high code-points af11
set forwarding-class Critical_Data loss-priority medium-low code-points af21
b. Configure DSCP BA classifiers for IPv6.
[edit]
264

[edit]
set queue 4 Video
set queue 5 Voice
2.

a. Configure DSCP rewrite rules for IPv4 core traffic.
[edit]
edit class-of-service rewrite-rules dscp Rewrite_CORE_TRAFFIC
set forwarding-class Best_Effort loss-priority medium-high code-point be
set forwarding-class Bulk_Data loss-priority medium-high code-point af11
set forwarding-class Scavenger loss-priority high code-point cs1
set forwarding-class Critical_Data loss-priority medium-low code-point af21
set forwarding-class Video loss-priority low code-point af41
set forwarding-class Voice loss-priority low code-point ef
set forwarding-class Network_Control loss-priority low code-point cs7
b. Configure DSCP rewrite rules for IPv6 core traffic.
[edit]
edit class-of-service rewrite-rules dscp-ipv6 Rewrite_CORE_TRAFFIC
c. Configure a rewrite rule for voice traffic. This rule sets the code-point bit patterns
for the Voice forwarding class and is applied to the branch LAN interfaces.
[edit]
edit class-of-service rewrite-rules dscp voice-ef
d. Configure a rewrite rule for video traffic. This rule sets the code-point bit patterns
for the Video forwarding class and is applied to the branch LAN interfaces.
[edit]
edit class-of-service rewrite-rules dscp video-af
265

3.

a. Create a scheduler for the Best_Effort forwarding class.
[edit]
edit class-of-service schedulers SCH_Best_Effort
set transmit-rate remainder
set buffer-size remainder
set priority medium-low
b. Create a scheduler for the Scavenger forwarding class.
[edit]
edit class-of-service schedulers SCH_Scavenger
set transmit-rate percent 3
set buffer-size percent 10
set priority low
c. Create a scheduler for the Bulk_Data forwarding class.
[edit]
edit class-of-service schedulers SCH_Bulk_Data
d. Create a scheduler for the Critical_Data forwarding class.
[edit]
edit class-of-service schedulers SCH_Critical_Data
set transmit-rate exact
set priority medium-high
e. Create a scheduler for the Video forwarding class.
[edit]
edit class-of-service schedulers SCH_Video
set priority high
f.
Create a scheduler for the Voice forwarding class.

[edit]
edit class-of-service schedulers SCH_VOICE
set shaping-rate percent 5
set priority strict-high
g. Create a scheduler for the Network_Control forwarding class.
[edit]
edit class-of-service schedulers SCH_Network_Control
266

set priority high
4.

[edit]
5.
Apply CoS to the branch LAN interfaces.

[edit]
set unit 55 forwarding-class Video
set unit 55 rewrite-rules dscp video-af
set unit 65 forwarding-class Voice
set unit 65 rewrite-rules dscp voice-ef
6.
If you are using T3 leased lines, apply CoS to the T3 interfaces.

[edit]
edit class-of-service interfaces t3-1/0/0
set unit 0 scheduler-map MAIN-SCHD
set unit 0 rewrite-rules dscp Rewrite_CORE_TRAFFIC
7.
If you are using Ethernet leased lines, apply CoS to the Ethernet interface.
[edit]
set unit 0 scheduler-map MAIN-SCHD
8.
This step is required on MX Series 3D Universal Edge Routers and on M Series
Multiservice Edge Routers.
[edit]
9.
Enable two-rate tricolor marking (TCM), which applies metering to incoming

classified traffic. Metering can increase a packets assigned packet loss priority, but
cannot decrease it.
[edit]
edit class-of-service
set tri-color
267
10.
Configure the egress shaping overhead on the 10-Gigabit Ethernet LAN PIC.
By default, the 10-Gigabit Ethernet LAN/WAN PIC uses 20 bytes as the shaping
overhead. This includes 8 bytes preamble and 12 bytes interpacket gap (IPG) in
shaper operations. To exclude this overhead, set the overhead to 20 bytes.
[edit]
set traffic-manager egress-shaping-overhead -20
NOTE: When the configuration for the overhead bytes on a PIC is

changed, the PIC is taken offline and then brought back online. In
addition, the configuration in the CLI is on a per-PIC basis, and thus
applies to all the ports on the PIC.
11.

[edit]
commit
Results
1.
Verify CoS on the leased line interface. For example, to verify CoS on the T3 leased
line:
user@branch> show class-of-service interface t3-1/0/0
Physical interface: t3-1/0/0, Index: 179
Output traffic control profile: leased-line, Index: 57471
Logical interface: t3-1/0/0, Index: 327
Object
Name
Type
Rewrite
Rewrite_CORE_TRAFFIC
dscp
Classifier
dscp-ipv6-compatibility dscp-ipv6
Classifier
ipprec-compatibility
ip
Index
51863
9
13
2. Verify CoS on the branch LAN interfaces.

user@branch> show class-of-service interface ge-1/2/9
268

Object
Name
Type
Classifier
DSCP-BA
dscp
Classifier
Index
961
9

Object
Name
Rewrite
video-af
Classifier
Video
Type
dscp
fixed
Index
35765
4

Object
Name
Type
Index
Rewrite
Classifier
voice-ef
Voice
dscp
fixed
28463
5
3. Verify CoS queues on the branch LAN.

user@branch> show interfaces queue ge-1/2/9
Forwarding classes: 16 supported, 7 in use
Queued:
Packets
:
4421140988
Bytes
:
1504095927004
Transmitted:
Packets
:
4421140988
Bytes
:
1504095927004
0
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
RED-dropped bytes
:
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
Queued:
Packets
:
0
Bytes
:
0
Transmitted:
Packets
:
0
Bytes
:
0
0
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
RED-dropped bytes
:
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
Queued:
Packets
:
0
Bytes
:
0
Transmitted:
Packets
:
0
Bytes
:
0
0
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
RED-dropped bytes
:
0
Low
:
0
7603 pps
20632480 bps
7603
20632480
0
0
0
0
0
0
0
0
0
0
0
pps
bps
pps
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
0 pps
0 bps
0
0
0
0
0
0
0
0
0
0
0
0
0
pps
bps
pps
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
0 pps
0 bps
0
0
0
0
0
0
0
0
0
0
pps
bps
pps
pps
pps
pps
pps
pps
bps
bps
269
Medium-low
:
Medium-high
:
High
:
Queue: 3, Forwarding classes:
Queued:
Packets
:
Bytes
:
Transmitted:
Packets
:
Bytes
:
Low
:
Medium-low
:
Medium-high
:
High
:
RED-dropped bytes
:
Low
:
Medium-low
:
Medium-high
:
High
:
Queued:
Packets
:
Bytes
:
Transmitted:
Packets
:
Bytes
:
Low
:
Medium-low
:
Medium-high
:
High
:
RED-dropped bytes
:
Low
:
Medium-low
:
Medium-high
:
High
:
Queued:
Packets
:
Bytes
:
Transmitted:
Packets
:
Bytes
:
Low
:
Medium-low
:
Medium-high
:
High
:
RED-dropped bytes
:
Low
:
Medium-low
:
Medium-high
:
High
:
Queued:
Packets
:
Bytes
:
270
0
0
0
0 bps
0 bps
0 bps
290854741
68641713888
500 pps
944992 bps
290854741
68641713888
0
0
0
0
0
0
0
0
0
0
0
500
944992
0
0
0
0
0
0
0
0
0
0
0
Critical_Data
pps
bps
pps
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
Video
0
0
0 pps
0 bps
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0 pps
0 bps
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
pps
bps
pps
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
Voice
pps
bps
pps
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
Network_Control
5814
397162
0 pps
0 bps
Transmitted:
Packets
Bytes
RED-dropped packets
Low
Medium-low
Medium-high
High
RED-dropped bytes
Low
Medium-low
Medium-high
High
:
:
:
:
:
:
:
:
:
:
:
:
:
5814
397162
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
pps
bps
pps
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
4. Verify CoS queues on the leased line interface. For example, to verify CoS on the T3
leased line.
user@branch> show interfaces queue t3-1/0/0
Physical interface: t3-1/0/0, Enabled, Physical link is Up
Queued:
Packets
:
1804250302
Bytes
:
544013769380
Transmitted:
Packets
:
1804250302
Bytes
:
544013769380
0
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
RED-dropped bytes
:
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
Queued:
Packets
:
0
Bytes
:
0
Transmitted:
Packets
:
0
Bytes
:
0
0
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
RED-dropped bytes
:
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
Queued:
3103 pps
7487456 bps
3103
7487456
0
0
0
0
0
0
0
0
0
0
0
pps
bps
pps
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
0 pps
0 bps
0
0
0
0
0
0
0
0
0
0
0
0
0
pps
bps
pps
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
271
Packets
:
582023165
Bytes
:
289847536170
Transmitted:
Packets
:
582023165
Bytes
:
289847536170
0
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
RED-dropped bytes
:
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
Queued:
Packets
:
873034765
Bytes
:
323022863050
Transmitted:
Packets
:
873034765
Bytes
:
323022863050
0
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
RED-dropped bytes
:
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
Queued:
Packets
:
582023192
Bytes
:
289847549616
Transmitted:
Packets
:
582023192
Bytes
:
289847549616
0
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
RED-dropped bytes
:
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
Queued:
Packets
:
582023199
Bytes
:
66350644686
Transmitted:
Packets
:
582023199
Bytes
:
66350644686
0
0
272
1001 pps
3988512 bps
1001
3988512
0
0
0
0
0
0
0
0
0
0
0
pps
bps
pps
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
1501 pps
4445888 bps
1501
4445888
0
0
0
0
0
0
0
0
0
0
0
pps
bps
pps
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
1001 pps
3988512 bps
1001
3988512
0
0
0
0
0
0
0
0
0
0
0
pps
bps
pps
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
1001 pps
913024 bps
1001
913024
0
0
pps
bps
pps
pps
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
RED-dropped bytes
:
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
Queued:
Packets
:
292690177
Bytes
:
70529968344
Transmitted:
Packets
:
292690177
Bytes
:
70529968344
0
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
RED-dropped bytes
:
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
0
0
0
0
0
0
0
0
0
pps
pps
pps
pps
bps
bps
bps
bps
bps
502 pps
969632 bps
502
969632
0
0
0
0
0
0
0
0
0
0
0
pps
bps
pps
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
Configuring OSPF Link-Level High Availability for the WAN Transport on the
Branch Router
Step-by-Step
Procedure
We are using BFD with OSPF to detect link failures over the WAN transport.
1.
If you are using T3 interfaces, in OSPF area 0.0.0.6, add BFD liveness detection to
the T3 interface.
[edit]
edit protocols ospf area 0.0.0.6 interface t3-1/0/0
2.
If you are using Ethernet interfaces, in OSPF area 0.0.0.6, add BFD liveness detection
to the Ethernet interface.
[edit]
edit protocols ospf area 0.0.0.6 interface ge-1/0/0.0
3.
273
[edit]
commit
Results
Verify active BFD sessions on the leased line interfaces.

user@branch> show bfd session
Address
172.16.5.1
State
Up
Interface
t3-1/0/0
Detect
Transmit
Time
Interval
1.500
0.500
Multiplier
3
Configuring BGP Link-Level High Availability for the WAN Transport on the Branch
Router
Step-by-Step
Procedure
We are using BFD with BGP to detect link failures over the WAN transport.
1.
Add BFD liveness detection to the BGP group.

[edit]
edit protocols bgp group IBGPoLL
set neighbor 172.16.2.5 bfd-liveness-detection minimum-interval 500
set neighbor 172.16.2.5 bfd-liveness-detection multiplier 3
2.

[edit]
commit
Results
Verify active BFD sessions on the leased line interfaces.

Address
172.16.5.1
State
Up
Interface
t3-1/0/0
Detect
Transmit
Time
Interval
1.500
0.500
Multiplier
3
274
Verification
Verifying End-to-End Data Traffic
Purpose
Action
Verify that traffic is travelling end-to-end on the WAN transport.

Run the following show command on the leased line interface.
user@branch> show interfaces t3-1/0/0 extensive
Physical interface: t3-1/0/0:
Logical interface t3-1/0/0.0 (Index 340) (SNMP ifIndex 671) (Generation 164)
Flags: Point-To-Point SNMP-Traps Encapsulation: FR-NLPID
Traffic statistics:
Input bytes :
657165384671
Output bytes :
658471099817
Input packets:
2014648711
Output packets:
2018621841
Input bytes :
4477852122
Output bytes :
4481491950
Input packets:
19135969
Output packets:
19151675
Local statistics:
Input bytes :
90353556
Output bytes :
102580543
Input packets:
1651417
Output packets:
1662341
Transit statistics:
Input bytes :
657075031115
21098920 bps
Output bytes :
658368519274
21163248 bps
Input packets:
2012997294
8100 pps
Output packets:
2016959500
8099 pps
Input bytes :
4477852122
Output bytes :
4481491950
Input packets:
19135969
Output packets:
19151675
Generation: 528
Destination: fe80::/64, Local: fe80::5e5e:ab10:e:456f
Generation: 340
Generation: 342
DLCI 101
Flags: Active, DCE-Configured
Total down time: 01:07:44 sec, Last down: 31:00:28 ago
Traffic statistics:
Input bytes :
657165384671
Output bytes :
658471099817
Input packets:
2014648711
Output packets:
2018621841
DLCI statistics:
Active DLCI :1 Inactive DLCI :0
275
Verifying Reachability
Purpose
Action
Use this procedure to verify that routes are being advertised properly, and to check
reachability and traffic paths to the loopback interface of the data center router, the
loopback interface of a router in a different branch, and an IP address in the service
provider network that is publicly routable.
1.
Display the default IPv4 routing table to verify reachability throughout the network.
The following table is for a T3 leased-line branch.
user@branch> show route table inet.0
0.0.0.0/0
172.16.5.0/30
172.16.5.2/32
172.16.5.8/30
172.16.5.9/32
172.16.5.12/30
172.16.5.13/32
172.16.5.16/30
172.16.5.17/32
172.16.5.255/32
*[OSPF/10] 1d 06:52:45, metric 12

> via t3-1/0/0
*[Direct/0] 1d 06:57:47
> via t3-1/0/0
[OSPF/10] 1d 06:57:46, metric 2
> via t3-1/0/0
*[Local/0] 1d 09:57:33
Local via t3-1/0/0
*[Direct/0] 3d 04:49:24
> via ge-1/2/9.45
*[Local/0] 3d 04:49:24
*[Direct/0] 3d 04:49:24
> via ge-1/2/9.55
*[Local/0] 3d 04:49:24
*[Direct/0] 3d 04:49:24
> via ge-1/2/9.65
*[Local/0] 3d 04:49:24
*[Direct/0] 2d 13:12:25
2. Verify connectivity to the loopback interface of the data center router.

user@branch> ping 172.31.255.8 rapid
PING 172.31.255.8 (172.31.255.8): 56 data bytes
!!!!!
user@branch> traceroute 172.31.255.8
1 172.16.5.1 (172.16.5.1) 0.857 ms 7.258 ms 0.606 ms#WANaggr 1
2 172.31.255.8 (172.31.255.8) 0.654 ms 0.726 ms 0.735 ms # DC loopback
3. Verify connectivity to the loopback interface of another branch router.
PING 172.16.1.254 (172.16.1.254): 56 data bytes
!!!!!
276

1 172.16.5.1 (172.16.5.1) 0.708 ms 0.649 ms 0.678 ms # WANaggr 1
2 172.31.254.14 (172.31.254.14) 0.477 ms 0.511 ms 0.795 ms # VPN hub 1
3 172.16.1.254 (172.16.1.254) 2.747 ms 3.320 ms 2.936 ms # Branch Loopback
4. Verify connectivity from the branch to an IP address in the service provider network
that is publicly routable.

1 172.16.5.1 (172.16.5.1) 0.746 ms 0.614 ms 0.479 ms # WANaggr 1
2 172.31.254.9 (172.31.254.9) 0.673 ms 0.611 ms 0.448 ms #Int edge 1
3 * * * # Expected because traceroute is blocked by SFW on Internet Edge
Verifying the Scenario From the WAN Aggregation Router at Aggregation Hub 1
Purpose
Action
Verify connectivity from the WAN aggregation router at Aggregation hub 1.

1.
Verify that the T3 interface is up.

user>wanagghub1 show interfaces terse t3-1/0/1:1
Interface
Admin Link Proto
t3-1/0/1:1
up
up
t3-1/0/1:1.0
up
up
inet
inet6
Local
Remote
172.16.5.1/30
fe80::5e5e:ab10:40e:426f/64
2001:DB8:5:1::1/64
2. Verify connectivity to the T3 interface on the branch.

user>wanagghub1 ping 172.16.5.2 rapid
PING 172.16.5.2 (172.16.5.2): 56 data bytes
!!!!!
3. If you are using OSPF, verify that the T3 interface at the branch is an OSPF neighbor.
user>wanagghub1 show ospf neighbor
Address
Interface
172.31.254.14
ge-1/2/2.0
172.31.254.42
ge-1/3/2.0
172.31.254.9
xe-0/0/0.0
172.31.241.10
xe-0/0/2.0
172.16.5.2
t3-1/0/1
Full 172.16.5.255
State
Full
Full
Full
Full
128 39
ID
172.31.255.3
172.31.255.5
172.31.255.0
172.31.255.8
Pri
128
128
128
128
Dead
32
35
33
35
4. If you are using BGP, verify BGP groups to the Layer 3 VPN service provider.
user>wanagghub1 show bgp summary group To_LL_Branches
Table
History Damp State
Pending
inet.0
26385
26383
0
0
0
0
inet6.0
25392
25392
0
0
0
0
Peer
AS
InPkt
OutPkt
OutQ
Flaps Last Up/Dwn
172.19.1.2
65530
242
247
0
7
1:59:49
277
10/10/10/0
0/0/0/0
172.19.1.6
65530
10/10/10/0
0/0/0/0
172.19.1.10
65530
10/10/10/0
0/0/0/0
172.19.1.14
65530
10/10/10/0
0/0/0/0
172.19.1.18
65530
10/10/10/0
0/0/0/0
.
.
.
. ## Total of 2000 peers
.
.
.
.
172.19.32.50
65530
10/10/10/0
0/0/0/0
172.19.32.54
65530
10/10/10/0
0/0/0/0
172.19.32.58
65530
10/10/10/0
0/0/0/0
172.19.32.62
65530
10/10/10/0
0/0/0/0
242
247
1:59:55
242
247
1:59:58
242
247
1:59:58
242
247
1:59:57
242
246
2:00:00
242
247
1:59:49
243
246
2:00:03
242
246
2:00:00
user>wanagghub1 show bgp summary group To_LL_Branches-V6

Table
History Damp State
Pending
inet.0
26385
26383
0
0
0
0
inet6.0
25392
25392
0
0
0
0
Peer
AS
InPkt
OutPkt
OutQ
Flaps Last Up/Dwn
2001:DB8:1:1::2
65530
240
4419
0
7
1:58:51
Establ
inet6.0: 10/10/10/0
2001:DB8:1:2::2
65530
242
11697
0
7
1:59:39
Establ
inet6.0: 10/10/10/0
2001:DB8:1:3::2
65530
241
4511
0
7
1:59:13
Establ
inet6.0: 10/10/10/0
2001:DB8:1:4::2
65530
239
4514
0
7
1:58:01
Establ
inet6.0: 10/10/10/0
2001:DB8:1:5::2
65530
242
4474
0
7
1:59:38
Establ
inet6.0: 10/10/10/0
2001:DB8:1:6::2
65530
240
4475
0
7
1:58:42
Establ
inet6.0: 10/10/10/0
.
.
. ### Total of 2000 BGP peers
.
.
278
.
.
2001:DB8:1:7ce::2
Establ
inet6.0: 10/10/10/0
2001:DB8:1:7cf::2
Establ
inet6.0: 10/10/10/0
2001:DB8:1:7d0::2
Establ
inet6.0: 10/10/10/0
65530
241
4416
1:59:25
65530
242
4417
1:59:32
65530
240
4411
1:58:40
5. Verify CoS on the T3 interface.

user>wanagghub1 show class-of-service interface t3-1/0/1:1
Physical interface: t3-1/0/1:1, Index: 165
Output traffic control profile: LEASED-LINE, Index: 1475
Logical interface: t3-1/0/1:1.0, Index: 334
Object
Name
Type
Classifier
Classifier
ip
Index
9
13
279
280
CHAPTER 11
Connecting a Small Branch to

Dual-Homed Aggregation Hubs over the
Internet
Connecting a Small Branch to Dual-Homed Aggregation Hubs over the Internet
Requirements
SRX240 Services Gateway at the branch with the following PICs:
16-port Gigabit Ethernet PIC
Two 1x T1E1 mPIM
Junos OS 12.1X44-D10
Overview
This design is a small branch with a single router that connects to the aggregation hub
over the Internet (Figure 74 on page 282).
For high availability, this is a dual-homed scenario with Aggregation Hub 1 as the primary
location and Aggregation Hub 2 as the backup location.
There are dual links provided by two Internet service providers (ISPs) at the aggregation
hubs and a single link provided at the branch. Two tunnels are configured from the
branch over these ISP links. The primary tunnel connects to Aggregation Hub 1, and
the secondary tunnel connects to Aggregation Hub 2.
The transport is GRE tunnels over IPsec tunnels.
For security, the GRE tunnels run over IPsec tunnels.
The private routing protocol used on the WAN transport is OSPF over the GRE tunnels.
The routing protocol used on the branch LAN is OSPF.
For link-level high availability, we are using Bidirectional Forwarding Detection (BFD)
for high availability on the GRE tunnels and on the local LAN.
281
Topology
Figure 74: Test Lab Topology for Small Sites Connecting to Dual Home
Aggregation Hubs over the Internet (GRE over IPsec)
282
Chapter 11: Connecting a Small Branch to Dual-Homed Aggregation Hubs over the Internet
Step-by-Step
Procedure
Before you configure this scenario, configure the base configurations at the Aggregation
Hub 1 and Aggregation Hub 2. Then complete the following:
Configuring the VPN Termination Router at Aggregation Hub 1 on page 283
Configuring the VPN Termination Role at Aggregation Hub 2 on page 294
Configuring Dynamic Endpoints for IPsec Tunnels on the VPN Termination Router at
Hub 1 on page 284
Configuring Private Overlay Security that Uses Certificates on the VPN Termination
Router at Hub 1 on page 286
Configuring Private Overlay Security that Uses Preshared Keys on the VPN Termination
Configuring the Overlay WAN Transport on the VPN Termination Router at Hub
1 on page 290
Configuring the Transport Routing Instances on the VPN Termination Router at Hub
1 on page 291
Configuring Private Overlay Routing on the VPN Termination Router at Hub 1 on page 292
Configuring Link-Level High Availability on the VPN Termination Router at Hub

1 on page 292
Configuring Multicast on the VPN Termination Router at Hub 1 on page 293
Applying CoS to the GRE Tunnel Interfaces on the VPN Termination Router at Hub
1 on page 293
283
Configuring Dynamic Endpoints for IPsec Tunnels on the VPN Termination Router
at Hub 1
Step-by-Step
Procedure
Figure 75: VPN Termination Router Configuration at Aggregation Hub 1
We are using dynamic endpoints for IPsec tunnels to reduce the configuration and changes
required when a new branch comes online.
1.
Create an IKE access profile that is used to negotiate IKE and IPsec security
associations with dynamic peers.
The client value * (wildcard) means this profile is valid for all dynamic peers that
terminate in the service set that accesses this profile.
The allowed proxy pair is used during phase 2 IKE negotiation.
284
The remote proxy pair supernet address range of 172.16.0.0/20 configured on

the hub is the range from which the branch router requests a local /32 address
during the negotiation process. If the branch router request does not fall into
the /20 range, negotiation fails.
From the hub point of view, the address requested by the branch is the remote
loopback address used for the GRE tunnel endpoint at the branch.
The local proxy pair address on the hub is the local loopback address used for
the GRE tunnel.
The IKE policy is the policy that defines the remote identification values that
correspond to the allowed dynamic peers.
The interface identifier is the interface used to derive the logical service interface
for the session.
[edit]
edit access profile venues client * ike
set allowed-proxy-pair local 172.31.255.31/32 remote 172.16.0.0/20
set ike-policy ike-phase1-policy
set interface-id venues
2.
Create a shared IPsec interface for dynamic peers.
The dial options interface ID specifies that this logical interface takes part in
dynamic IPsec negotiation for the group of dynamic peers defined for venues.
The dial options shared mode enables the logical interface to be shared across
multiple tunnels.
The inside and outside service domains must match the interface domains
specified in the service set.
[edit]
set unit 1 dial-options ipsec-interface-id venues
set unit 1 dial-options shared
3.
Configure a service set used for the dynamic endpoints.
The reverse routes at the aggregation hub include next hops that point to the
locations specified by the inside and outside service interfaces. The reverse routes
are inserted into the VPN routing instance routing table because the sp-0/3/0
interfaces are present in this routing instance. The inside and outside service
interfaces must match the inside and outside service domains configured at the
[edit interfaces sp-0/3/0] hierarchy level.
Specify the address and the routing instance of the local gateway. The local
gateway address is the local address of the Ethernet interface from the VPN
termination router to the Internet edge router.
If you are using preshared keys with IPsec, set trusted-ca to self-ca.
If you are using certificates with IPsec, set trusted-ca to ROOT.
Reference the IKE access profile venues.
285
[edit]
edit services service-set BR1
set ipsec-vpn-options trusted-ca self-ca
set ipsec-vpn-options local-gateway 191.15.100.6
set ipsec-vpn-options local-gateway routing-instance VPN
set ipsec-vpn-options ike-access-profile venues
Configuring Private Overlay Security that Uses Certificates on the VPN Termination
Router at Hub 1
Step-by-Step
Procedure
We are using IPsec to secure the GRE tunnels between the branch and the aggregation
hub. The WAN transport security configuration consists of an Internet Key Exchange
(IKE) configuration for IPsec phase 1 negotiation and an IPsec configuration for phase 2
negotiation.
You can use either certificates or preshared keys in your IPsec implementation. If you are
using certificates, follow this procedure.
1.
Enroll and verify the digital certificate.

a. Create a certificate authority (CA) CA profile. Include the URL to the CA server,
and specify that that method to verify revocation status of digital certificates is
the certificate revocation list (CRL). A CRL is a time-stamped list identifying
revoked certificates, which is signed by a CA and made available to the
participating IPsec peers on a regular periodic basis.
[edit]
edit security pki ca-profile ROOT
set ca-identity ROOT
set enrollment url http://10.204.138.55:8080/scep/ROOT/
set revocation-check crl disable on-download-failure
b. Commit the configuration, and verify that the certificate server is reachable.
[edit]
commit
[edit]
run ping 10.204.138.55
PING 10.204.138.55 (10.204.138.55): 56 data bytes
64 bytes from 10.204.138.55: icmp_seq=0 ttl=123 time=2.811 ms
c. Retrieve the certificate from the CA server. Examine the fingerprint of the CA
certificate, if it is correct for this CA certificate, enter yes to accept.

[edit]
run request security pki ca-certificate enroll ca-profile ROOT
Fingerprint:
5d:53:9d:7a:06:23:5e:2a:5e:dc:8d:fb:52:f7:91:ae:1c:a3:ed:bd (sha1)
7d:02:c9:f9:33:99:48:dc:89:37:fe:4a:22:9f:12:84 (md5)
Do you want to load the above CA certificate ? [yes,no] (no) yes
CA certificate for profile ROOT loaded successfully
286
d. Verify the certificate.
[edit]
run request security pki ca-certificate verify ca-profile ROOT
CA certificate ROOT verified successfully
e. Generate a public-private key pair.
[edit]
run request security pki generate-key-pair certificate-id localcert1
Generated key pair localcert11, key size 1024 bits
f.
Generate a local certificate using the CA profile.

[edit]
request security pki local-certificate enroll ca-profile ROOT certificate-id localcert1
challenge-password aaaa domain-name localcert1.juniper.net email
localcert1@juniper.net ip 191.15.100.6 subject
DC=domain_component1,CN=localcert1,OU=sltqa1,O=juniper1,L=sunnyvale1,ST=california1,C=us1
g. Commit the configuration.
[edit]
commit
h. Verify that the CA certificate was generated.
[edit]
show security pki ca-certificate detail
Certificate identifier: ROOT
Certificate version: 3
Serial number: 00038b8c
Issuer:
Organization: juniper, Country: India, Common name: ROOT
Subject:
Validity:
Not before: 04-25-2013 10:36
Not after: 04-25-2014 10:36
Public key algorithm: rsaEncryption(2048 bits)
30:82:01:0a:02:82:01:01:00:ea:bf:02:2d:9d:69:c1:22:f6:5d:0a
38:76:fa:9c:11:18:81:23:de:5e:d6:6d:c1:e8:38:73:e9:c4:46:d7
97:22:a4:d9:66:f7:d6:e3:66:b8:d1:82:79:49:57:0d:c6:f9:e7:59
89:ac:57:8e:76:74:78:97:b8:25:12:7a:47:15:0e:88:81:b9:c1:14
76:b0:a4:8d:c1:ea:85:25:cf:a3:ea:3a:a8:1a:32:b8:ad:ac:33:73
97:c4:11:ba:2a:39:74:25:47:9c:cd:e0:03:03:8e:af:db:90:b6:7e
df:ea:81:73:e2:f9:0e:97:4e:50:70:40:bc:41:bc:dc:0e:8a:40:e3
6e:9d:d3:bf:36:9f:53:aa:2a:df:7b:d9:4a:35:c2:b2:68:a0:df:24
e8:af:04:69:35:0b:5e:1a:da:10:f9:fb:d2:22:80:ff:dd:e0:21:25
f6:3b:71:4f:4c:74:c8:38:f9:79:36:40:8c:9e:d3:14:0f:f4:9c:ad
ae:5d:46:59:76:af:b7:2c:ee:5c:a9:c6:ef:d5:30:e2:10:74:5c:2a
b9:1d:4a:80:5f:1a:fb:92:18:1f:98:34:07:5e:c7:01:03:88:ef:f7
56:76:a5:0f:47:be:df:bc:88:81:9f:2d:8b:26:77:90:a3:be:23:cb
f2:83:f9:4a:8d:02:03:01:00:01
Signature algorithm: sha1WithRSAEncryption
Distribution CRL:
http://10.204.138.55:8080/crl-as-der/currentcrl-292.crl?id=292
Use for key: CRL signing, Certificate signing, Key encipherment, Digital
signature
287
Fingerprint:
7d:02:c9:f9:33:99:48:dc:89:37:fe:4a:22:9f:12:84 (md5)
Auto-re-enrollment:
Status: Disabled
Next trigger time: Timer not started
i.
Verify that the local certificate was generated.

[edit]
show security pki local-certificate detail
Certificate identifier: localcert1
Serial number: 0069450d
Issuer:
Subject:
Organization: juniper1, Organizational unit: sltqa1, State:
california1, Locality: sunnyvale1, Common name: localcert1, Domain
component: domain_component1
Alternate subject: "localcert1@juniper.net", localcert1.juniper.net,
191.15.100.6
Validity:
Not before: 09- 6-2013 00:12
Not after: 04-25-2014 10:36
30:81:89:02:81:81:00:b8:12:e4:c0:03:28:91:39:31:7d:7b:4e:0c
b9:46:fa:55:46:ec:19:8b:d9:ad:59:9f:81:2f:35:ee:1f:c6:9c:9e
b8:4f:64:7c:8f:80:a9:6a:8a:db:ba:88:55:21:e0:82:a4:1c:87:c8
11:91:fa:4c:e8:b7:50:ab:e0:9a:15:ed:c7:14:14:19:18:c4:c4:89
bb:3d:fc:5a:8e:db:ce:32:cf:6f:ea:5d:08:4f:f8:fb:f7:10:fd:11
b6:b8:78:44:cd:a7:2f:35:72:11:f4:fb:6e:68:6a:57:87:cd:cc:39
6c:44:9f:27:9c:bd:c6:a9:60:48:c6:1e:d9:7e:ad:02:03:01:00:01
Distribution CRL:
Fingerprint:
89:4c:bd:23:f4:7b:ea:9f:ea:49:6d:e5:b9:29:7a:f7:22:20:2f:97 (sha1)
e5:2f:71:79:c6:50:77:b5:2c:19:35:3d:ba:f9:46:fa (md5)
Auto-re-enrollment:
Status: Disabled
2.
For IKE phase 1 negotiation with the branch, configure an IKE proposal and policy.
a. Configure an IKE proposal that matches the proposal configured on the branch
router.
[edit]
edit services ipsec-vpn ike proposal ike-phase1-proposal
set authentication-method rsa-signatures
set dh-group group2
set authentication-algorithm sha-256
set encryption-algorithm aes-256-cbc
set lifetime-seconds 28800
b. Configure an IKE (phase 1) proposal to use RSA encryption.
[edit]
edit services ipsec-vpn ike proposal rsa-prop
288

set authentication-algorithm sha1
set encryption-algorithm 3des-cbc
c. Configure an IKE policy and associate the IKE proposal with the policy.
[edit]
edit services ipsec-vpn ike policy ike-rsa
set mode main
set proposals ike-phase1-proposal
set local-id fqdn localcert1.juniper.net deactivate local-id
set local-certificate localcert1
set any-remote-id
d. Configure an IKE policy to use RSA encryption.
Configure an IKE policy and associate the IKE proposal with the policy.
[edit]
set proposals rsa-prop
set local-id fqdn test1.test.com
set local-certificate test1
set remote-id fqdn test2.test.com
3.
For IPsec phase 2 negotiation, configure an IPsec proposal and policy.

a. Configure an IPsec proposal.
[edit]
edit services ipsec-vpn ipsec proposal dynamic_ipsec_proposal
set protocol esp
set authentication-algorithm hmac-sha1-96
b. Configure the IPsec policy, which lists protocols and algorithms (security services)
to be negotiated with the remote IPsec peer at the branch.

[edit]
edit services ipsec-vpn ipsec policy dynamic_ipsec_policy
set perfect-forward-secrecy keys group2
set proposals dynamic_ipsec_proposal
4.

[edit]
commit
289
Configuring Private Overlay Security that Uses Preshared Keys on the VPN
Termination Router at Hub 1
Step-by-Step
Procedure
hub. The WAN transport security configuration consists of an IKE configuration for IPsec
phase 1 negotiation and an IPsec configuration for phase 2 negotiation.
using preshared keys, follow this procedure.
1.
router.
[edit]
set authentication-method pre-shared-keys
set dh-group group2
b. Configure an IKE policy and associate the IKE proposal with the policy.
[edit]
edit services ipsec-vpn ike policy ike-phase1-policy
set mode main
set pre-shared-key ascii-text "$9$5znCO1hKMXtuMX7-2gTz3"
2.

[edit]
set protocol esp

[edit]
Configuring the Overlay WAN Transport on the VPN Termination Router at Hub
1
Step-by-Step
Procedure
1.
Configure the loopback interface. This loopback interface is included in the VPN
routing instance, and its address is used as the GRE tunnel source address.
[edit]
290

2.
Create the GRE tunnel interface.
Specify the outer GRE source and destination tunnel addresses that are used to
form the tunnel. These are the local and remote addresses of the loopback
interfaces.
Specify the routing instance in which the tunnels source and destination resides.
Specify the inner IPv4 and IPv6 addresses that are used after the tunnel is formed.
The GRE interface is later added to the WAN-GRE routing instance so that the
internal addressing of the GRE tunnel is part of the enterprises private routing
space.
[edit]
edit interfaces gr-0/1/0 unit 1
set tunnel source 172.31.255.31
set tunnel destination 172.16.1.255
set tunnel routing-instance destination VPN
Configure a logical GRE interface for the number of tunnels to be formed between
the branch and the aggregation hub.
Configuring the Transport Routing Instances on the VPN Termination Router at

Hub 1
Step-by-Step
Procedure
On the VPN termination router at the aggregation hub, there are two virtual routing
instances:
VPNA public Internet-facing instance that terminates IPsec tunnels.
WAN-GREAn internal routing instance that terminates the private GRE IPv4
addressing. The WAN-GRE virtual router is part of the internal routing domain and is
an OSPF peer to the WAN aggregation router at the aggregation hub.
1.
Add the IPsec interfaces and the loopback interface to the VPN routing instance.
The loopback interface is the remote endpoint for the branch. The address of the
loopback interface is used as the GRE tunnel source address.
[edit]
set interface lo0.2
2.
Add the GRE tunnel interfaces to the WAN-GRE routing instance.

Create a logical unit for the number of GRE tunnels that can be formed to the branch.
[edit]
set interface gr-0/1/0.1
291
Configuring Private Overlay Routing on the VPN Termination Router at Hub 1

Step-by-Step
Procedure
OSPF is the private routing protocol used over the WAN GRE tunnels, and it is configured
in the WAN-GRE routing instance.
1.
Configure the OSPF area for GRE tunnels from the branch.
[edit]
set interface gr-0/1/0.1 metric 10
set interface gr-0/1/0.1 authentication md5 0 key "$9$gUaGjmfQ9AuSrw24aDjCAp"
Configure a separate area for each branch.

2.
Configure the OSPFv3 area for GRE tunnels from the branch.
[edit]
Configuring Link-Level High Availability on the VPN Termination Router at Hub 1

Step-by-Step
Procedure
There are two levels of high availability that you can use over your private WAN overlay:
Dead peer detection for IPsec tunnels to monitor the tunnel state and remote peer
availability.
BFD with OSPF for GRE tunnels to detect failures over the GRE tunnels.
1.
Add dead peer detection to the venues access profile.

[edit]
set access profile venues client * ike initiate-dead-peer-detection
2.
In OSPF area 0.0.0.2, add BFD liveness detection to the GRE tunnel.
Set the minimum transmit and receive interval for failure detection. This interval is
the minimum time after which the local routing device transmits hello packets and
the minimum interval after which the routing device expects to receive a reply from
the neighbor with which it has established a BFD session.
[edit]
set interface gr-0/1/0.1 bfd-liveness-detection minimum-interval 500
set interface gr-0/1/0.1 bfd-liveness-detection multiplier 3
292
Configuring Multicast on the VPN Termination Router at Hub 1

Step-by-Step
Procedure
1.
Add the GRE tunnels to the multicast configuration in the WAN-GRE routing instance.
[edit]
set interface gr-0/1/0.1 mode sparse
set interface gr-0/1/0.1 version 2
Applying CoS to the GRE Tunnel Interfaces on the VPN Termination Router at
Hub 1
Step-by-Step
Procedure
In overlay environments it is critical to be able to schedule and control the traffic out to
the remote branches. This is most effectively achieved if you use GRE or tunnel QoS,
where you can implement a CoS shaper and traffic scheduler per tunnel to control the
bandwidth of the tunnel and schedule high-priority traffic over low-priority traffic.
1.
In the CoS configuration, apply the traffic control profile to the GRE tunnel interfaces.
The control profile is configured in the aggregation hub base configuration.
[edit]
2.
In the GRE logical interface configuration, configure the tunnels to copy the ToS bit
to the outer IP header on the GRE tunnel.
In this design, we are classifying traffic based on DSCP markings in the ToS byte of
the IP header. Because this header is encapsulated in a GRE tunnel, the ToS byte
of the IP header needs to be copied to the GRE outer header.
[edit]
set copy-tos-to-outer-ip-header
293
Configuring Dynamic Endpoints for IPsec Tunnels on the VPN Termination Router at
Hub 2 on page 294
Configuring Private Overlay Security the Uses Certificates on the VPN Termination
Configuring Private Overlay Security that Uses Preshared Keys on the VPN Termination
Configuring the Overlay WAN Transport on the VPN Termination Role at Router at Hub
2 on page 300
Configuring the Transport Routing Instances on a VPN Termination Router at Hub

2 on page 301
Configuring Private Overlay Routing on the VPN Termination Router at Hub 2 on page 302
Configuring Link-Level High Availability on the VPN Termination Router at Hub

2 on page 302
Configuring Multicast on the VPN Termination Router at Hub 2 on page 303
Applying CoS to the Tunnel Interfaces on the VPN Termination Role at Hub 2 on page 303
Configuring Dynamic Endpoints for IPsec Tunnels on the VPN Termination Router
at Hub 2
Step-by-Step
Procedure
We are using dynamic endpoints for IPsec tunnels to reduce the configuration and changes
required when a new branch comes online. You need to configure dynamic endpoints
only once at the aggregation hub.
1.

the GRE tunnel.
for the session.
[edit]
294
edit access profile IPsec_Clients_Group1 client * ike

set interface-id IPsec_Clients_Group1
2.
dynamic IPsec negotiation for the group of dynamic peers defined for
IPsec_Clients_Group1.
multiple tunnels.
[edit]
set unit 1 description "--- Outbound unit for DEP IPSEC tunnel ----"
set unit 2 description "--- Inbound unit for DEP IPSEC (shared) tunnel ---"
set unit 2 dial-options ipsec-interface-id IPsec_Clients_Group1
3.
[edit interfaces sp-1/0/0] hierarchy level.
gateway address is the local address of logical tunnel interface (5/1/0.53) from
the VPN termination role to the Internet edge role.
If you are using preshared keys with IPsec, set trusted-ca to self-ca.
If you are using certificates with IPsec, set trusted-ca to ROOT.
Reference the IKE access profile IPsec_Clients_Group1.

[edit]
edit services service-set IPsec_Clients_Group1
set ipsec-vpn-options ike-access-profile IPsec_Clients_Group1
295
Configuring Private Overlay Security the Uses Certificates on the VPN Termination
Router at Hub 2
Step-by-Step
Procedure
1.

[edit]
b. Commit the configuration, and verify that the certificate is reachable.
[edit]
commit
[edit]
run ping 10.204.138.55
PING 10.204.138.55 (10.204.138.55): 56 data bytes

[edit]
Fingerprint:
7d:02:c9:f9:33:99:48:dc:89:37:fe:4a:22:9f:12:84 (md5)
[edit]
[edit]
296
f.

[edit]
request security pki local-certificate enroll ca-profile ROOT certificate-id localcert1
challenge-password aaaa domain-name localcert1.juniper.net email
localcert1@juniper.net ip 191.15.200.6 subject
[edit]
commit
[edit]
Issuer:
Subject:
Validity:
Not before: 04-25-2013 10:36
Not after: 04-25-2014 10:36
30:82:01:0a:02:82:01:01:00:ea:bf:02:2d:9d:69:c1:22:f6:5d:0a
38:76:fa:9c:11:18:81:23:de:5e:d6:6d:c1:e8:38:73:e9:c4:46:d7
97:22:a4:d9:66:f7:d6:e3:66:b8:d1:82:79:49:57:0d:c6:f9:e7:59
89:ac:57:8e:76:74:78:97:b8:25:12:7a:47:15:0e:88:81:b9:c1:14
f6:3b:71:4f:4c:74:c8:38:f9:79:36:40:8c:9e:d3:14:0f:f4:9c:ad
b9:1d:4a:80:5f:1a:fb:92:18:1f:98:34:07:5e:c7:01:03:88:ef:f7
f2:83:f9:4a:8d:02:03:01:00:01
Distribution CRL:
signature
Fingerprint:
7d:02:c9:f9:33:99:48:dc:89:37:fe:4a:22:9f:12:84 (md5)
Auto-re-enrollment:
Status: Disabled
i.

[edit]
297
Serial number: 0069450d

Issuer:
Subject:
191.15.100.6
Validity:
Not before: 09- 6-2013 00:12
Not after: 04-25-2014 10:36
30:81:89:02:81:81:00:b8:12:e4:c0:03:28:91:39:31:7d:7b:4e:0c
b9:46:fa:55:46:ec:19:8b:d9:ad:59:9f:81:2f:35:ee:1f:c6:9c:9e
b8:4f:64:7c:8f:80:a9:6a:8a:db:ba:88:55:21:e0:82:a4:1c:87:c8
11:91:fa:4c:e8:b7:50:ab:e0:9a:15:ed:c7:14:14:19:18:c4:c4:89
bb:3d:fc:5a:8e:db:ce:32:cf:6f:ea:5d:08:4f:f8:fb:f7:10:fd:11
b6:b8:78:44:cd:a7:2f:35:72:11:f4:fb:6e:68:6a:57:87:cd:cc:39
6c:44:9f:27:9c:bd:c6:a9:60:48:c6:1e:d9:7e:ad:02:03:01:00:01
Distribution CRL:
Fingerprint:
89:4c:bd:23:f4:7b:ea:9f:ea:49:6d:e5:b9:29:7a:f7:22:20:2f:97 (sha1)
e5:2f:71:79:c6:50:77:b5:2c:19:35:3d:ba:f9:46:fa (md5)
Auto-re-enrollment:
Status: Disabled
2.
router.
[edit]
set dh-group group2
b. Configure an IKE (phase 1) proposal to use RSA encryption.
[edit]
edit services ipsec-vpn ike proposal rsa-prop
set authentication-algorithm sha1
set encryption-algorithm 3des-cbc
c. Configure an IKE policy and associate the IKE proposal with the policy.
[edit]
set mode main
set local-id fqdn localcert1.juniper.net deactivate local-id
set local-certificate localcert1
set any-remote-id
298
d. Configure an IKE policy to use RSA encryption.
Configure an IKE policy and associate the IKE proposal with the policy.
[edit]
set proposals rsa-prop
set local-id fqdn test1.test.com
set local-certificate test1
set remote-id fqdn test2.test.com
3.

[edit]
set protocol esp

[edit]
4.

[edit]
commit
Configuring Private Overlay Security that Uses Preshared Keys on the VPN
Termination Router at Hub 2
Step-by-Step
Procedure
1.
router.
[edit]
set dh-group group2
[edit]
299
set mode main

2.

[edit]
set protocol esp

[edit]
Configuring the Overlay WAN Transport on the VPN Termination Role at Router
at Hub 2
Step-by-Step
Procedure
1.
Configure the loopback interface that is configured in the WAN-GRE routing instance.
Its address is used as the source address of GRE tunnels.
[edit]
2.
interfaces.
Specify the routing instance in which the tunnel resides.
[edit]
3.
Configure the loopback interface that is configured in the VPN routing instance. Its
address is used on the IPsec tunnels.
[edit]
300
Configuring the Transport Routing Instances on a VPN Termination Router at Hub

2
Step-by-Step
Procedure
On the VPN termination router at the aggregation hub, two virtual routing instances are
created:
VPNA public Internet-facing instance.
an OSPF peer to the WAN aggregation router at the aggregation hub.
1.
Configure the VPN virtual router routing instance.

a. Create the VPN virtual router routing instance and add the logical tunnel (lt)
interface to the Internet edge router, the loopback interface, which is the remote
endpoint for the branch, and the IPsec interfaces.
The address of the loopback interface is used on the IPsec tunnels.
[edit]
set interface lo0.3
2.
Create the virtual router routing instance and add interfaces to it.
lt-5/1/0.20Interface used for shaping and queuing in place of per-unit GRE

scheduling.
lt-5/1/0.54Interface to the WAN aggregation role.
lo0.4Loopback interface for the GRE tunnels. Its address is used as the GRE
tunnel source address.
gr-5/1/0.1GRE tunnel interface. Create a logical unit for the number of GRE
tunnels that can be formed to the branch.
[edit]
set interface lo0.4
301
Configuring Private Overlay Routing on the VPN Termination Router at Hub 2

Step-by-Step
Procedure
OSPF is the private routing protocol used over the WAN GRE tunnels, and it is configured
in the WAN-GRE routing instance.
1.
Configure the OSPF area for GRE tunnels from the branch. Specify a metric of 20
so that routes to Aggregation Hub 1 will be preferred over routes to Aggregation Hub
2.
[edit]
set interface gr-5/1/0.1 metric 20
set interface gr-5/1/0.1 authentication md5 0 key "$9$41JUiP5zCt0ylsgoJjiAtu"

2.
Configure the OSPFv3 area for GRE tunnels from the branch.
[edit]
Configuring Link-Level High Availability on the VPN Termination Router at Hub 2

Step-by-Step
Procedure
availability.
1.
Add dead peer detection to the IPsec_Clients_Group1 access profile.

[edit]
set access profile IPsec_Clients_Group1 client * ike initiate-dead-peer-detection
2.
[edit]
set interface gr-0/1/0.1 bfd-liveness-detection minimum-interval 500
set interface gr-0/1/0.1 bfd-liveness-detection multiplier 3
302
Configuring Multicast on the VPN Termination Router at Hub 2

Step-by-Step
Procedure
1.
Add the GRE tunnels to the multicast configuration in the WAN-GRE routing instance.
[edit]
Applying CoS to the Tunnel Interfaces on the VPN Termination Role at Hub 2
Step-by-Step
Procedure
The router at Aggregation Hub 2 is an MX Series router, and MX Series routers do not
support per-unit GRE scheduling. To work around this, we are configuring the logical
tunnel (lt) interfaces to apply CoS to egress traffic before it is sent over the GRE tunnels
to the branch.
1.
Apply the traffic control profile on the logical tunnel used for scheduling and
queueing.
Before you implement this step, you need to have enabled hierarchical scheduling
on the lt interface, and committed the configuration.
[edit]
edit class-of-service interfaces lt-5/1/0 unit 2
set output-traffic-control-profile SMALL-BRANCH
NOTE: Step 1 in this configuration is a workaround required in pre-Junos

OS 13.3. Per-GRE class of service is supported in Junos OS 13.3 and is
shown: Appendix A: Alternate Configuration Aggregation and Branch
using MX80 with Services MIC on page 737. When using Junos OS 13.3
or later, Step 1 is not required.
2.
[edit]
303
Configuring the Router ID on the Branch Router on page 304
Configuring Security Zones and Policies on the Branch Router on page 304
Configuring the Physical WAN Transport on the Branch Router on page 306
Configuring Private Overlay Routing on the Branch Router on page 306
Configuring Private Overlay Security that uses Certificates on the Branch

Router on page 308
Configuring Private Overlay Security that uses Preshared Keys on the Branch
Router on page 315
Configuring the Overlay WAN Transport on the Branch Router on page 320
Configuring the Routing Protocol for the WAN Transport on the Branch
Router on page 324
Configuring the LAN Transport on the Branch Router on page 327
Configuring the Routing Protocol for the LAN Transport on the Branch Router on page 329
Configuring Multicast on the Branch Router on page 329
Configuring CoS on the Branch Router on page 333
Configuring Link-Level High Availability on the Branch Router on page 347

Step-by-Step
Procedure
1.

[edit]
Configuring Security Zones and Policies on the Branch Router

Step-by-Step
Procedure
1.
Configure the security zones.

The SRX Services Gateways use a concept called security zones. Traffic cannot
move into or out of an SRX device until security zones are defined.
Security zones are logical entities to which one or more interfaces are bound. Security
zones divide the gateway into one or more network segments and then regulate
inbound and outbound traffic through the security zones. You group interfaces with
identical security requirements into a single security zone.
Security policies are used to control how traffic enters into one security zone and
goes out on another security zone. This combination of a from-zone and a to-zone
is defined as a context.
You can specify the type of traffic allowed into a security zone, the protocol allowed
into a security zone, and the interfaces in the security zone.
a. Create the untrust security zone.
304
[edit]
edit security zones security-zone untrust
set host-inbound-traffic system-services all
set host-inbound-traffic protocols all
set interfaces ge-0/0/12.0
set interfaces st0.0
set interfaces lo0.1
set interfaces st0.1
b. Create the trust security zone.
[edit]
edit security zones security-zone trust
set host-inbound-traffic system-services all
set host-inbound-traffic protocols all
set interfaces lo0.0
set interfaces gr-0/0/0.1
set interfaces gr-0/0/0.2
c. Create the management zone.
[edit]
edit security zones security-zone HOST
set interfaces ge-0/0/0.0 host-inbound-traffic system-services all
set interfaces ge-0/0/0.0 host-inbound-traffic protocols all
2.
Configure policies for the security zones.

a. Configure policies for traffic going from zone trust to zone untrust.
[edit]
edit security policies from-zone trust to-zone untrust
set policy T-to-UT match source-address any
set policy T-to-UT match destination-address any
set policy T-to-UT match application any
set policy T-to-UT then permit
b. Configure a policy for traffic going from zone untrust to zone trust.
[edit]
edit security policies from-zone untrust to-zone trust
set policy pin match source-address any
set policy pin match destination-address any
set policy pin match application any
set policy pin then permit
c. Configure a policy for traffic going from zone untrust to zone untrust.
[edit]
edit security policies from-zone untrust to-zone untrust
set policy u2u match source-address any
set policy u2u match destination-address any
set policy u2u match application any
set policy u2u then permit
305
d. Configure a policy for traffic going from zone trust to zone trust.
[edit]
edit security policies from-zone trust to-zone trust
set policy t2t match source-address any
set policy t2t match destination-address any
set policy t2t match application any
set policy t2t then permit
Configuring the Physical WAN Transport on the Branch Router

Step-by-Step
Procedure
1.
Create the physical interface to the ISP.

[edit]
set description "----- External Interface connected to ISP (single link)----"
2.

[edit]
commit
Results
1.
Verify that the physical transport is up:

user@branch> show interfaces ge-0/0/12.0 terse
Interface
Admin Link Proto
ge-0/0/12.0
up
up
inet
Local
1.1.0.2/30
Remote
2. Verify that the physical interface is running in the untrust security zone.
user@branch> show interfaces ge-0/0/12.0
Security: Zone: untrust
Allowed host-inbound traffic : bootp bfd bgp dns dvmrp igmp ldp msdp nhrp
ospf ospf3 pgm pim
rip ripng router-discovery rsvp sap vrrp dhcp finger ftp tftp
ident-reset http https ike netconf ping reverse-telnet reverse-ssh rlogin
rpm rsh snmp snmp-trap
ssh telnet traceroute xnm-clear-text xnm-ssl lsping ntp sip dhcpv6 r2cp
Flags: Sendbcast-pkt-to-re, Is-Primary
Configuring Private Overlay Routing on the Branch Router

Step-by-Step
Procedure
Configure the virtual router routing instance in the untrusted zone for Internet traffic. The
routing instance does not allow traffic to the branch LAN from the Internet, and it protects
the internal branch routing tables.
1.
306
Unit 0 is in the untrust zone, and is used for the connections to the aggregation
hubs.
Unit 1 is in the trust zone, is in the default inet.0 routing table, and is used with the
branch LANs.
[edit]
edit interfaces lo0
set unit 0 family inet6 address fec0:16:1::254/128
2.
Configure the IPsec tunnel interface to the aggregation hub.

[edit]
edit interfaces st0
set unit 0 description "-----IPsec Tunnel interface to Aggregation Hub 1------"
set unit 1 description "-----IPsec Tunnel interface to Aggregation Hub 2 -----"
3.
Create the routing instance and add the Internet-facing interfacesthe Ethernet
interface to the ISP, unit 1 of the loopback interface, and the IPsec interfaces.
[edit]
edit routing-instances untrust-vpn
set interface lo0.1
set interface st0.0
set interface st0.1
4.
Add a default static route to the ISP. This default route is used to provide reachability
to the ISPs public IP address for IPsec tunnel initiation. It is not used for local Internet
access. All internal traffic, including traffic to the Internet, traverses the GRE tunnels.
[edit]
5.
Add a static route to the loopback address of the VPN termination router on
Aggregation Hub 1 and Aggregation Hub 2. These routes are used to establish GRE
tunnels.
[edit]
set routing-options static route 172.31.255.31/32 next-hop st0.0
set routing-options static route 172.31.255.231/32 next-hop st0.1
The corresponding host route to the aggregation hubs GRE loopback address is
advertised using the proxy identities configured in the IPsec VPN, and is installed
on the aggregation hub.
6.

[edit]
commit
Results
1.
Verify that the ISP gateway is reachable from the untrust-vpn routing instance.
user@branch> ping 1.1.0.1 routing-instance VPN count 5
307
PING 1.1.0.1 (1.1.0.1): 56 data bytes

64 bytes from 1.1.0.1: icmp_seq=0 ttl=64
time=3.378
time=1.889
time=2.160
time=2.193
time=2.171
ms
ms
ms
ms
ms
2. Verify the routes that are learned from the aggregation hub by displaying the inet.0
routing table for the untrust-vpn routing instance.

user@branch> show route table untrust-vpn.inet.0
untrust-vpn.inet.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)
0.0.0.0/0
1.1.0.0/30
1.1.0.2/32
172.16.1.255/32
172.31.255.31/32
172.31.255.231/32
*[Static/5] 1w5d 12:55:52

> to 1.1.0.1 via ge-0/0/12.0
*[Direct/0] 1w5d 12:55:52
> via ge-0/0/12.0
*[Local/0] 3w4d 02:10:45
*[Direct/0] 3w4d 02:11:30
> via lo0.1
*[Static/5] 23:06:54
> via st0.0
*[Static/5] 23:06:54
> via st0.1
Configuring Private Overlay Security that uses Certificates on the Branch Router
Step-by-Step
Procedure
using certificates, follow this procedure.
1.

[edit]
b. Commit the configuration, and verify that the certificate is reachable.
[edit]
308
commit
[edit]
run ping 10.204.138.55
PING 10.204.138.55 (10.204.138.55): 56 data bytes

[edit]
Fingerprint:
7d:02:c9:f9:33:99:48:dc:89:37:fe:4a:22:9f:12:84 (md5)
[edit]
[edit]
f.

[edit]
run request security pki local-certificate enroll ca-profile ROOT certificate-id
localcert11 challenge-password aaaa domain-name localcert11.juniper.net
email localcert1@juniper.net ip 1.1.0.2 subject
[edit]
commit
[edit]
Issuer:
Subject:
309
Subject string:
C=India, O=juniper, CN=ROOT
Validity:
Not before: 04-25-2013 10:36
Not after: 04-25-2014 10:36
30:82:01:0a:02:82:01:01:00:ea:bf:02:2d:9d:69:c1:22:f6:5d:0a
38:76:fa:9c:11:18:81:23:de:5e:d6:6d:c1:e8:38:73:e9:c4:46:d7
97:22:a4:d9:66:f7:d6:e3:66:b8:d1:82:79:49:57:0d:c6:f9:e7:59
89:ac:57:8e:76:74:78:97:b8:25:12:7a:47:15:0e:88:81:b9:c1:14
f6:3b:71:4f:4c:74:c8:38:f9:79:36:40:8c:9e:d3:14:0f:f4:9c:ad
b9:1d:4a:80:5f:1a:fb:92:18:1f:98:34:07:5e:c7:01:03:88:ef:f7
f2:83:f9:4a:8d:02:03:01:00:01
Distribution CRL:
signature
Fingerprint:
7d:02:c9:f9:33:99:48:dc:89:37:fe:4a:22:9f:12:84 (md5)
Auto-re-enrollment:
Status: Disabled
i.

[edit]
Serial number: 00694e5f
Issuer:
Subject:
Subject string:
DC=domain_component11, CN=localcert11, OU=sltqa11, O=juniper11,
L=sunnyvale11, ST=california11, C=us11
1.1.0.2
Validity:
Not before: 09- 6-2013 00:13
Not after: 04-25-2014 10:36
30:81:89:02:81:81:00:c8:22:ca:43:34:2c:27:3a:25:ca:12:91:f9
f3:a8:ff:f5:8c:23:2a:64:2c:20:b7:78:40:ef:d1:3d:f9:c6:90:3e
09:31:5a:5f:98:be:ad:ff:12:27:e8:dc:27:b3:ec:60:da:64:b8:b7
46:6b:40:5a:bc:4d:c6:d4:17:2e:4e:d9:16:a3:75:6d:4b:46:30:7b
b3:12:b0:ff:be:19:76:e7:b3:0a:f3:28:da:4a:56:83:16:8f:5e:ce
1b:68:87:e8:6a:ab:28:9e:a5:6f:f8:4f:e0:85:86:73:62:73:cd:39
77:db:da:f1:8b:ab:ba:de:82:aa:a5:83:19:d9:29:02:03:01:00:01
310

Distribution CRL:
Fingerprint:
81:00:82:0e:1f:ae:9d:31:d3:aa:12:39:8b:37:02:df:74:bd:4d:bb (sha1)
93:40:ea:c4:a1:87:79:91:bd:55:a1:b8:22:6f:aa:69 (md5)
Auto-re-enrollment:
Status: Disabled
j.
Verify the local certificate.

user@branch> request security pki local-certificate verify certificate-id localcert11
Local certificate localcert11 verification success
2.
For IKE phase 1 negotiation, configure an IKE proposal and policy and define the
IPsec peer (gateway) at the remote end of the tunnel with which IKE is negotiated.
a. Configure an IKE proposal that matches the proposal configured on the VPN
termination router at the aggregation hub.

[edit]
edit security ike proposal ike-phase1-proposal
set dh-group group2
b. Configure an IKE (Phase 1) proposal to use RSA encryption.
[edit]
edit security ike proposal rsa-prop
c. Configure an IKE policy. Associate the IKE proposal with the policy, and specify
the local certificate to use with the policy.

[edit]
edit security ike policy ike-phase1-policy
set mode main
set certificate local-certificate localcert11
d. Define an IKE gateway for Aggregation Hub 1. IKE uses the default static route
configured in the untrust-vpn routing instance to access and negotiate IPsec

phase 1 with this gateway.
[edit]
edit security ike gateway gw-branch
set address 191.15.100.6
set local-identity hostname localcert11.juniper.net
set external-interface ge-0/0/12
e. Define an IKE gateway for Aggregation Hub 2.
[edit]
311
edit security ike gateway br-head2

set local-identity hostname localcert11.juniper.net
3.
For IPsec phase 2 negotiation, configure an IPsec proposal and policy and then
configure an IPsec VPN to the aggregation hubs.
a. Configure the IPsec proposal, which lists protocols and algorithms (security
services) to be negotiated with the remote IPsec peer at the aggregation hub.
[edit]
edit security ipsec proposal ipsec-phase2-proposal
set protocol esp
b. Create an IPsec policy that defines security parameters (IPsec proposals) used
during IPsec negotiation.

This policy also defines Perfect Forward Secrecy (PFS) to provide additional
security by using a Diffie-Hellman key exchange shared secret value.
[edit]
edit security ipsec policy ipsec-phase2-policy
set proposals ipsec-phase2-proposal
c. Create an IPsec VPN to Aggregation Hub 1.
The proxy identities are used for reverse route injection (RRI). The local proxy
identity is the IP address of the local GRE tunnel endpoint. The remote tunnel
identity is the IP address of the remote GRE tunnel endpoint.
The proxy identity values match the values set in the venues IKE access profile
configured on the VPN termination router at the aggregation hub.
[edit]
edit security ipsec vpn ike-vpn-chicago
set bind-interface st0.0
set ike gateway gw-branch
set ike proxy-identity local 172.16.1.255/32
set ike proxy-identity remote 172.31.255.31/32
set ike ipsec-policy ipsec-phase2-policy
set establish-tunnels immediately
d. Create an IPsec VPN to Aggregation Hub 2.
[edit]
edit security ipsec vpn ike-vpn-head2
set ike gateway br-head2
312

4.

[edit]
commit
Results
1.
Verify the reachability of the IKE gateway.

user@branch> show route 198.51.100.6 table VPN.inet.0
0.0.0.0/0
*[Static/5] 2d 05:01:03
> to 1.1.0.1 via ge-0/0/12.0

PING 198.51.100.6 (198.51.100.6): 56 data bytes
64 bytes from 198.51.100.6: icmp_seq=0 ttl=60 time=2.814
ms
ms
ms
ms
ms
2. Verify IKE that security associations for Aggregation Hub 1 (198.51.100.6) and
Aggregation Hub 2 (192.0.2.6) are up.

user@branch> show security ike security-associations
Index
State Initiator cookie Responder cookie Mode
6670350 UP
2fa9609b522c5f75 7a28d06fe17bdab7 Main
6670351 UP
f8dc5b2a4791ca4d 376e89a90fce1394 Main
Remote Address
198.51.100.6
192.0.2.6
3. Verify IKE security associations for Aggregation Hub 1 (198.51.100.6) and Aggregation
Hub 2 (192.0.2.6).
IKE peer 198.51.100.6, Index 2166656, Gateway Name: gw-branch
Role: Initiator, State: UP
Initiator cookie: 8330e20474ab9bf5, Responder cookie: 5ab22ffd73c77477
Exchange type: Main, Authentication method: RSA-signatures
Local: 1.1.0.2:500, Remote: 198.51.100.6:500
Lifetime: Expires in 27899 seconds
Peer ike-id: 198.51.100.6
Xauth assigned IP: 0.0.0.0
Algorithms:
Authentication
: hmac-sha256-128
Encryption
: aes256-cbc
Pseudo random function: hmac-sha256
Diffie-Hellman group : DH-group-2
Traffic statistics:
Input bytes :
10088
Output bytes :
10408
Input packets:
94
Output packets:
95
Flags: IKE SA is created
IPsec security associations: 1 created, 0 deleted
313
Phase 2 negotiations in progress: 0

Negotiation type: Quick mode, Role: Initiator, Message ID: 0
Local: 1.1.0.2:500, Remote: 198.51.100.6:500
Local identity: localcert11.juniper.net
Remote identity: 198.51.100.6
4. Verify IPsec security associations for Aggregation Hub 1 (198.51.100.6) and Aggregation
Hub 2 (192.0.2.6).
user@branch> show security ipsec security-associations
Total active tunnels: 2
ID
Algorithm
SPI
Life:sec/kb Mon vsys Port
<131073 ESP:3des/sha1 63f37ac1 3571/ unlim
root 500
>131073 ESP:3des/sha1 d8d36260 3571/ unlim
root 500
<131074 ESP:3des/sha1 1b24ee6b 815/ unlim
root 500
>131074 ESP:3des/sha1 545643c7 815/ unlim
root 500
Gateway
198.51.100.6
198.51.100.6
192.0.2.6
192.0.2.6
5. Verify local and remote identity and the security algorithms in IPsec security
associations for Aggregation Hub 1 (198.51.100.6) and Aggregation Hub 2 (192.0.2.6).

user@branch> show security ipsec security-associations detail
ID: 131073 Virtual-system: root, VPN Name: ike-vpn-chicago
Local Gateway: 1.1.0.2, Remote Gateway: 191.15.100.6
Local Identity: ipv4(any:0,[0..3]=172.16.1.255)
Remote Identity: ipv4(any:0,[0..3]=172.31.255.31)
Version: IKEv1
DF-bit: clear
Bind-interface: st0.0
Port: 500, Nego#: 2, Fail#: 0, Def-Del#: 0 Flag: 600a29
Tunnel Down Reason: Lifetime expired
Direction: inbound, SPI: 7dd6e0bc, AUX-SPI: 0
, VPN Monitoring: Hard lifetime: Expires in 2954 seconds
Lifesize Remaining: Unlimited
Soft lifetime: Expires in 2316 seconds
Mode: Tunnel(0 0), Type: dynamic, State: installed
Protocol: ESP, Authentication: hmac-sha1-96, Encryption: aes-cbc (256 bits)
Anti-replay service: counter-based enabled, Replay window size: 64
Direction: outbound, SPI: ebf88e72, AUX-SPI: 0
ID: 131074 Virtual-system: root, VPN Name: ike-vpn-head2
Version: IKEv1
DF-bit: clear
314

Direction: inbound, SPI: e2453bd2, AUX-SPI: 0
Direction: outbound, SPI: ca13403a, AUX-SPI: 0
Configuring Private Overlay Security that uses Preshared Keys on the Branch
Router
Step-by-Step
Procedure
If you are using preshared keys in your IPsec implementation, use this procedure.
1.
For IKE phase 1 negotiation, configure an IKE proposal and policy and define the

[edit]
edit security ike proposal ike-phase1-proposal
set dh-group group2
[edit]
edit security ike policy ike-phase1-policy
set mode main
set pre-shared-key ascii-text "$9$tw4101hevLVwgSrwgoJHkp0B"
c. Define an IKE gateway for Aggregation Hub 1. IKE uses the default static route
configured in the untrust-vpn routing instance to access and negotiate IPsec

phase 1 with this gateway.
[edit]
315

d. Define an IKE gateway for Aggregation Hub 2.
[edit]
2.
[edit]
edit security ipsec proposal ipsec-phase2-proposal
set protocol esp

[edit]
edit security ipsec policy ipsec-phase2-policy
set proposals ipsec-phase2-proposal
c. Create an IPsec VPN to Aggregation Hub 1.
The proxy identities are used for reverse route injection (RRI). The local proxy
identity is the IP address of the local GRE tunnel endpoint. The remote tunnel
identity is the IP address of the remote GRE tunnel endpoint.
The proxy identity values match the values set in the venues IKE access profile
configured on the VPN termination router at the aggregation hub.
[edit]
edit security ipsec vpn ike-vpn-chicago
set ike gateway gw-branch
d. Create an IPsec VPN to Aggregation Hub 2.
[edit]
edit security ipsec vpn ike-vpn-head2
316
set ike gateway br-head2

3.

[edit]
commit
Results
1.
Verify the reachability of the IKE gateway.

0.0.0.0/0
*[Static/5] 2d 05:01:03
> to 1.1.0.1 via ge-0/0/12.0

PING 191.15.100.6 (191.15.100.6): 56 data bytes
ms
ms
ms
ms
ms
Hub 2 (192.0.2.6).
Index
State Initiator cookie Responder cookie Mode
6670350 UP
2fa9609b522c5f75 7a28d06fe17bdab7 Main
6670351 UP
f8dc5b2a4791ca4d 376e89a90fce1394 Main
Remote Address
198.51.100.6
192.0.2.6
Hub 2 (192.0.2.6).
user@branch> show security ike security-associations detail
IKE peer 198.51.100.6, Index 7315412, Gateway Name: gw-branch
Initiator cookie: a5b12ad39b8033df, Responder cookie: dfc0a26c3e4beee7
Exchange type: Main, Authentication method: Pre-shared-keys
Local: 1.1.0.2:500, Remote: 198.51.100.6:500
Peer ike-id: 198.51.100.6
Algorithms:
Authentication
: hmac-sha256-128
Encryption
: aes256-cbc
Traffic statistics:
Input bytes :
40140
317
Output bytes :
40588
Input packets:
367
Output packets:
370
Local: 1.1.0.2:500, Remote: 191.15.100.6:500
Local identity: 1.1.0.2
IKE peer 192.0.2.6, Index 7315413, Gateway Name: br-head2
Initiator cookie: 212f98969acd8105, Responder cookie: ff9a1590e5a2687a
Local: 1.1.0.2:500, Remote: 192.0.2.6:500
Peer ike-id: 192.0.2.6
Algorithms:
Authentication
: hmac-sha256-128
Encryption
: aes256-cbc
Traffic statistics:
Input bytes :
40140
Output bytes :
40588
Input packets:
367
Output packets:
370
Local: 1.1.0.2:500, Remote: 192.0.2.6:500
Local identity: 1.1.0.2
4. Verify IPsec security associations for Aggregation Hub 1 (198.51.100.6) and Aggregation
Hub 2 (192.0.2.6).
user@branch> show security ipsec security-associations
Total active tunnels: 2
ID
Algorithm
SPI
Life:sec/kb Mon vsys Port
<131073 ESP:3des/sha1 63f37ac1 3571/ unlim
root 500
>131073 ESP:3des/sha1 d8d36260 3571/ unlim
root 500
<131074 ESP:3des/sha1 1b24ee6b 815/ unlim
root 500
>131074 ESP:3des/sha1 545643c7 815/ unlim
root 500
Gateway
198.51.100.6
198.51.100.6
192.0.2.6
192.0.2.6
5. Verify local and remote identity and the security algorithms in IPsec security
associations for Aggregation Hub 1 (198.51.100.6) and Aggregation Hub 2 (192.0.2.6).

user@branch> show security ipsec security-associations detail
ID: 131073 Virtual-system: root, VPN Name: ike-vpn-chicago
Version: IKEv1
DF-bit: clear
318
Direction: inbound, SPI: 7dd6e0bc, AUX-SPI: 0
Direction: outbound, SPI: ebf88e72, AUX-SPI: 0
ID: 131074 Virtual-system: root, VPN Name: ike-vpn-head2
Version: IKEv1
DF-bit: clear
Direction: inbound, SPI: e2453bd2, AUX-SPI: 0
Direction: outbound, SPI: ca13403a, AUX-SPI: 0
319
Configuring the Overlay WAN Transport on the Branch Router

Step-by-Step
Procedure
Create GRE tunnel interfaces to the aggregation hubs.
Specify the outer GRE tunnel source and destination addresses that are used to form
the tunnel. These are the local and remote addresses of the loopback interfaces.
Specify the destination routing instance that points to the routing table that contains
the tunnel destination address.
Specify the inner IPv4 and IPv6 GRE addresses that are used after the tunnel is formed.
1.
Configure the tunnel interface to Aggregation Hub 1.

[edit]
set tunnel routing-instance destination untrust-vpn
2.

[edit]
set tunnel routing-instance destination untrust-vpn
3.
The set tunnel routing-instance destination untrust-vpn statement in the previous

steps specifies that the GRE tunnel receives its address from the routing table in
the untrust-vpn routing instance. However, because of a PR on the SRX Series, the
GRE tunnels are not able to obtain their address from the untrust-vpn routing
instance.
To work around this issue, we are using the following routing policy configuration
to redistribute the IPsec tunnel endpoint addresses (public addresses) from the
untrust-vpn virtual routing instance into the default routing instance.
[edit]
edit policy-options policy-statement from-untrust-to-default
set term 1 from instance VPN
[edit]
set instance-import from-untrust-to-default
320
NOTE: The previous step is required as a workaround due to SRX Series

operating differently than other Junos OS platforms. In SRX Series
(SRX240 in this example), IPsec over GRE between VRs operates
differently than on the other platforms in this solution.
4.

[edit]
commit
Results
1.
Verify that the GRE tunnel destination to Aggregation Hub 1 is reachable.

user@branch> show route 172.31.255.31
172.31.255.31/32
*[Static/5] 1d 05:25:51
> via st0.0

172.31.255.31/32
*[Static/5] 1d 05:25:51
> via st0.0
user@branch> ping 172.31.255.31 source 172.16.1.255 routing-instance VPN

PING 172.31.255.31 (172.31.255.31): 56 data bytes
^C
2. Verify that the GRE tunnel destination to Aggregation Hub 2 is reachable.
172.31.255.231/32
*[Static/5] 05:11:42
> via st0.1

172.31.255.231/32
*[Static/5] 05:11:42
> via st0.1
user@branch> ping 172.31.255.231 source 172.16.1.255 routing-instance VPN

PING 172.31.255.231 (172.31.255.231): 56 data bytes
321

^C
3. Verify that the GRE interfaces are up, and that the interface destinations to Aggregation
Hub 1 (172.16.1.1) and Aggregation Hub 2 (172.16.1.5) are reachable.

user@branch> show interfaces terse gr-0/0/0
Interface
Admin Link Proto
gr-0/0/0
up
up
gr-0/0/0.1
up
up
inet
inet6
gr-0/0/0.2
up
up
inet
inet6
Local
Remote
172.16.1.2/30
fe80::fac0:100:8c:e500/64
fec0:16:1::2/64
172.16.1.6/30
fe80::fac0:100:8c:e500/64
fec0:16:1:4::2/64
user@branch> ping 172.16.1.1

PING 172.16.1.1 (172.16.1.1): 56 data bytes
^C
PING 172.16.1.5 (172.16.1.5): 56 data bytes
^C
4. Verify that traffic is flowing over the GRE tunnels to Aggregation Hub 1 (gr-0/0/0.1)
and Aggregation Hub 2 (gr-0/0/0.2).

user@branch> show interfaces gr-0/0/0
Physical interface: gr-0/0/0, Enabled, Physical link is Up
Type: GRE, Link-level type: GRE, MTU: Unlimited, Speed: 800mbps
Link flags
: Scheduler Keepalives DTE
Device flags
: Present Running
Interface flags: Point-To-Point
Input rate
: 17843560 bps (6906 pps)
Output rate
: 16866904 bps (6702 pps)
Logical interface gr-0/0/0.1 (Index 81) (SNMP ifIndex 552)
Flags: Point-To-Point SNMP-Traps 0x0 IP-Header
172.31.255.31:172.16.1.255:47:df:64:0000000000000004 Encapsulation: GRE-NULL
Copy-tos-to-outer-ip-header: Off
Gre keepalives configured: Off, Gre keepalives adjacency state: down
Security: Zone: trust
322
ospf ospf3 pgm pim rip ripng router-discovery rsvp sap vrrp dhcp finger ftp
tftp ident-reset http https ike netconf ping reverse-telnet reverse-ssh rlogin
rpm rsh snmp snmp-trap ssh telnet traceroute xnm-clear-text xnm-ssl lsping
ntp sip dhcpv6 r2cp
Flags: None
Destination: fe80::/64, Local: fe80::fac0:100:8c:e500
ospf ospf3 pgm pim rip ripng router-discovery rsvp sap vrrp dhcp finger ftp
tftp ident-reset http https ike netconf ping reverse-telnet reverse-ssh rlogin
rpm rsh snmp snmp-trap ssh telnet traceroute xnm-clear-text xnm-ssl lsping
ntp sip dhcpv6 r2cp
Flags: None
5. Now that you have verified that the GRE tunnels are up, you can verify that the IPsec
interfaces are up.

user@branch> show interfaces terse sp-0/0/0
Interface
Admin Link Proto
sp-0/0/0
up
up
sp-0/0/0.0
up
up
inet
sp-0/0/0.16383
up
up
inet
Local
Remote
10.0.0.1
--> 10.0.0.16
10.0.0.6
128.0.0.1
--> 0/0
--> 128.0.1.16
128.0.0.6
--> 0/0
6. Verify that traffic is flowing on each of the IPsec interfaces.

user@branch> show interfaces sp-0/0/0
Physical interface: sp-0/0/0, Enabled, Physical link is Up
Type: Adaptive-Services, Link-level type: Adaptive-Services, MTU: 9192,
Speed: 800mbps
323
Device flags
:
Interface flags:
Link type
:
Link flags
:
Last flapped
:
Input rate
:
Output rate
:
Present Running
Point-To-Point SNMP-Traps Internal: 0x0
Full-Duplex
None
2013-04-12 04:24:12 PDT (5w5d 12:18 ago)
0 bps (0 pps)
0 bps (0 pps)
Logical interface sp-0/0/0.0 (Index 80) (SNMP ifIndex 546)

Flags: Point-To-Point SNMP-Traps Encapsulation: Adaptive-Services
Input packets : 0
Output packets: 0
Security: Zone: Null
Flags: Receive-options, Receive-TTL-Exceeded
Input packets : 0
Output packets: 0
Flags: Is-Primary, Receive-options, Receive-TTL-Exceeded
Destination: 10.0.0.16, Local: 10.0.0.1
Addresses
Local: 10.0.0.6
Destination: 128.0.1.16, Local: 128.0.0.1
Addresses
Local: 128.0.0.6
Configuring the Routing Protocol for the WAN Transport on the Branch Router
Step-by-Step
Procedure
OSPF is used as the routing protocol on the GRE tunnels.

For security, MD5 authenticates OSPF protocol exchanges to guarantee that only trusted
routing devices participate in the ASs routing.
1.
Configure OSPF, which is used to route IPv4 traffic.

a. Create OSPF area 0.0.0.2. This area is used on the GRE tunnels to the aggregation
hub and on the branch LAN.

[edit]
b. Specify that the area is a stub area to prevent routes in the branch LAN from
being advertised to the aggregation hub and to other branches. Include the
no-summaries option to restrict summary LSAs from entering the area.
c. Add the GRE tunnels and include an MD5 authentication key for the tunnels, with
a key ID of 0.
transmitted packet. Both the receiving and transmitting routing devices must
324
have the same MD5 key. You define an MD5 key for each interface. If MD5 is
enabled on an interface, that interface accepts routing updates only if MD5
authentication succeeds. Otherwise, updates are rejected. The routing device
accepts only OSPFv2 packets sent using the same key ID that is defined for that
interface.
set interface gr-0/0/0.1 authentication md5 0 key
"$9$0EqM1ESvWXbsgikAuO1cSws2"
set interface gr-0/0/0.2 authentication md5 0 key
"$9$xco-bYJGjP5zp0WX7-sYf5Q"
d. Add the loopback interface to the area.

set interface lo0.0
2.
Configure OSPFv3, which is used to route IPv6 traffic.

a. Create OSPF area 0.0.0.2. This area is used on the GRE tunnels to the aggregation
hub and on the branch LAN.

b. Specify that the area is a stub area to prevent routes from the branch LAN from
being advertised to the aggregation hub.

[edit protocols osp3f area 0.0.0.2]
set stub
c. Add the GRE tunnels to the OSPF3 area.

set interface lo0.0
d. Add the loopback interface to the OSPF3 area.

set interface lo0.0
3.

[edit]
commit
325
Results
1.
Verify that OSPF is running on the GRE interfaces.

Address
Interface
172.16.1.1
gr-0/0/0.1
172.16.1.5
gr-0/0/0.2
State
Full
Full
ID
172.31.255.3
172.31.255.6
Pri
128
128
Dead
39
32
Address
Interface
State
ID
172.16.1.1
gr-0/0/0.1
Full
172.31.255.3
Area 0.0.0.2, opt 0x50, DR 0.0.0.0, BDR 0.0.0.0
Up 01:32:49, adjacent 01:32:49
172.16.1.5
gr-0/0/0.2
Full
172.31.255.6
Area 0.0.0.2, opt 0x50, DR 0.0.0.0, BDR 0.0.0.0
Up 01:37:47, adjacent 01:37:47
Pri
128
Dead
37
128
39
user@branch> show ospf neighbor detail
2. Verify that OSPFv3 is running over the GRE interfaces.

user@branch> show ospf3 neighbor
ID
Interface
State
172.31.255.3
gr-0/0/0.1
Full
Neighbor-address fe80::2a0:a502:74:e54f
172.31.255.6
gr-0/0/0.2
Full
Neighbor-address fe80::2a0:a512:78:fbf8
Pri
128
Dead
36
128
34
3. Verify the routes learned from OSPF over the GRE tunnels from the aggregation hub.
user@branch> show route protocol ospf
0.0.0.0/0
172.16.1.0/30
172.16.1.4/30
224.0.0.5/32
*[OSPF/10] 06:13:13, metric 11

> via gr-0/0/0.1
[OSPF/10] 2d 05:29:20, metric 1
> via gr-0/0/0.1
[OSPF/10] 2d 05:29:20, metric 1
> via gr-0/0/0.2
*[OSPF/10] 2d 05:30:24, metric 1
MultiRecv
4. Verify the routes learned from OSPFv3 over the GRE tunnels from the aggregation
hub.
user@branch> show route protocol ospf3
::/0
2001:DB8:1::/64
2001:DB8:1:4::/64
ff02::5/128
326
*[OSPF3/10] 06:18:30, metric 11

> via gr-0/0/0.1
[OSPF3/10] 2d 05:30:03, metric 1
> via gr-0/0/0.1
[OSPF3/10] 2d 05:30:03, metric 1
> via gr-0/0/0.2
*[OSPF3/10] 2d 05:31:07, metric 1
MultiRecv

Step-by-Step
Procedure
There are three interfaces to the branch LAN: one for data, one for video, and one for
voice.
1.
Configure the interface, and enable it for VLAN tagging.

[edit]
set vlan-tagging
2.

[edit]
set description DATA
set vlan-id 40
3.

[edit]
set description VIDEO
set vlan-id 50
4.

[edit]
set description VOICE
set vlan-id 60
5.

[edit]
commit
Results
Verify that the LAN interfaces are running in the trust zone.
user@branch1> show interfaces ge-0/0/8
Link-level type: Ethernet, MTU: 1518, Link-mode: Full-duplex, Speed: 1000mbps,
BPDU Error: None, MAC-REWRITE Error: None, Loopback: Disabled,
Source filtering: Disabled, Flow control: Enabled, Auto-negotiation: Enabled,
Device flags
: Present Running
CoS queues
Current address: f8:c0:01:8c:e5:08, Hardware address: f8:c0:01:8c:e5:08
Last flapped
: 2013-04-12 04:24:19 PDT (5w5d 12:20 ago)
Input rate
: 16759720 bps (6698 pps)
Output rate
: 17724152 bps (6892 pps)
327

Description: DATA
Flags: SNMP-Traps 0x0 VLAN-Tag [ 0x8100.40 ] Encapsulation: ENET2
ospf ospf3 pgm pim rip ripng router-discovery rsvp sap vrrp dhcp finger ftp tftp
ident-reset http https ike netconf ping reverse-telnet reverse-ssh rlogin rpm
rsh snmp snmp-trap ssh telnet traceroute xnm-clear-text xnm-ssl lsping ntp sip
dhcpv6 r2cp
Flags: Is-Primary
Description: VIDEO
dhcpv6 r2cp
Flags: None
Description: VOICE
dhcpv6 r2cp
328

Flags: None
Destination: fe80::/64, Local: fe80::fac0:100:3c8c:e508
Input packets : 0
Output packets: 0
Configuring the Routing Protocol for the LAN Transport on the Branch Router
Step-by-Step
Procedure
1.
Add the branch LAN interfaces as passive interfaces to the OSPF area.
2.
Add the branch LAN interfaces as passive interfaces to the OSPF3 area.
3.

[edit]
commit
Results
The route advertised from Aggregation Hub 1 has a metric of 10, and the route advertised
from Aggregation Hub 2 has a metric of 20.
user@branch> show ospf database detail
OSPF database, Area 0.0.0.2
Type
ID
Adv Rtr
Summary 0.0.0.0
172.31.255.3
mask 0.0.0.0
Topology default (ID 0) -> Metric: 10
Summary 0.0.0.0
172.31.255.6
mask 0.0.0.0
Topology default (ID 0) -> Metric: 20
Seq
0x80000008
Age
2777
Opt Cksum Len

0x20 0xe07e 28
0x8000002a
2590
0x20 0xee41
28

Step-by-Step
Procedure
1.
[edit]
edit protocols pim
329

2.
Add the GRE tunnel and on the branch LAN interfaces to the multicast configuration.
3.

[edit]
commit
Results
1.
Verify that IGMP groups are formed.

user@branch> show igmp group
Group: 235.1.1.1
Source: 0.0.0.0
Timeout:
204 Type: Dynamic
Group: 235.1.1.2
Source: 0.0.0.0
Timeout:
204 Type: Dynamic
Group: 224.0.0.2
Source: 0.0.0.0
Timeout:
0 Type: Dynamic
Group: 224.0.0.5
Source: 0.0.0.0
Timeout:
0 Type: Dynamic
Group: 224.0.0.6
Source: 0.0.0.0
Timeout:
0 Type: Dynamic
Group: 224.0.0.13
Source: 0.0.0.0
Timeout:
0 Type: Dynamic
Group: 224.0.0.22
Source: 0.0.0.0
Timeout:
0 Type: Dynamic
2. Verify that multicast is running over the GRE tunnels.

user@branch> show pim join
Group: 235.1.1.1
Source: *
RP: 172.31.255.15
Upstream interface: gr-0/0/0.1
Group: 235.1.1.1
330
Source: 172.31.251.10
Flags: sparse,spt
Group: 235.1.1.2
Source: *
RP: 172.31.255.15
Group: 235.1.1.2
Source: 172.31.251.10
Flags: sparse,spt
3. Verify multicast over the GRE interfaces.

B = Bidirectional Capable, G = Generation Identifier,
Interface
gr-0/0/0.1
gr-0/0/0.2
IP V Mode
4 2
4 2
Option
HPLGT
HPLGT

1d 05:48:43 172.16.1.1
05:34:30 172.16.1.5
4. Verify that groups are established with upstream GRE tunnel to the Aggregation Hub
1 (gr-0/0/0.1) and downstream interfaces to the branch LAN (ge-0/0/8).

Group: 235.1.1.1
Source: 172.31.251.10/32
ge-0/0/8.40
Next-hop ID: 262143
Route state: Active
Uptime: 06:43:41
Group: 235.1.1.2
Source: 172.31.251.10/32
ge-0/0/8.40
Next-hop ID: 262143
Route state: Active
331

Uptime: 06:43:41
332

Step-by-Step
Procedure
1.
[edit]
[edit]
[edit]
set queue 4 Video
set queue 5 Voice
2.

[edit]
333

[edit]
c. Configure a rewrite rule for voice traffic. This rule sets the code-point bit patterns
for the Voice forwarding class and is applied to the branch LAN interfaces.
[edit]
for the Video forwarding class and is applied to the branch LAN interfaces.
[edit]
e. Configure a rewrite rule for voice and video traffic. This rule sets the code-point
bit patterns for the Voice and Video forwarding classes and will be applied to
the GRE tunnels.
[edit]
edit class-of-service rewrite-rules dscp Video_Voice
334
3.

[edit]
[edit]
set priority low
[edit]
[edit]
[edit]
set priority high
f.

[edit]
[edit]
335
set priority high

4.

[edit]
5.

[edit]
6.
Apply CoS to the GRE tunnels.

[edit]
edit class-of-service interfaces gr-0/0/0 unit 1
set classifiers dscp DSCP-BA
set classifiers dscp-ipv6 DSCP-BA
set rewrite-rules dscp Video_Voice
set rewrite-rules dscp Rewrite_CORE_TRAFFIC
set rewrite-rules dscp-ipv6 Rewrite_CORE_TRAFFIC
[edit]
set classifiers dscp-ipv6 DSCP-BA
set rewrite-rules dscp Video_Voice
set rewrite-rules dscp-ipv6 Rewrite_CORE_TRAFFIC
336
7.
Enable per-unit scheduling on the GRE tunnels.

a. Enable tunnel queueing on the PIC. This step allows you to schedule traffic on
each GRE tunnel.

[edit]
set chassis fpc 0 pic 0 tunnel-queuing
b. Enable the per-unit scheduler on the GRE tunnel interfaces.
[edit]
set interfaces gr-0/0/0.1 per-unit-scheduler
set interfaces gr-0/0/0.2 per-unit-scheduler
c. Apply shaping on the GRE tunnel interfaces.
We are setting a shaping rate on GRE tunnels instead of a using a policer because
the shaper has a buffer and is more flexible than a policer, which applies a hard
limit to the rate and drops packets when a transmission rate is reached.
[edit]
set class-of-service interfaces gr-0/0/0 unit 0 shaping-rate 30M
set class-of-service interfaces gr-0/0/0 unit 1 shaping-rate 30M
NOTE: The previous step is an example of per unit GRE CoS as

configured on the SRX. This feature is also available on the MX Series
(MX 3D) starting in Junos OS 13.3
8.

[edit]
commit
337
Results
1.
Verify CoS on the GRE interfaces.

user@branch> show class-of-service interface gr-0/0/0
Physical interface: gr-0/0/0, Index: 151
Scheduler map: <default-chassis>, Index: 4
Logical interface: gr-0/0/0.1, Index: 81
Shaping rate: 30000000
Object
Name
Index
Scheduler-map
MAIN-SCHD
5286
Rewrite
Video_Voice
27178
Rewrite
51862
Classifier
DSCP-BA
961
Classifier
DSCP-BA
960
Object
Name
Index
Scheduler-map
MAIN-SCHD
5286
Rewrite
Video_Voice
27178
Rewrite
51862
Classifier
DSCP-BA
961
Classifier
DSCP-BA
960
Type
Output
dscp
dscp-ipv6
dscp
dscp-ipv6
Type
Output
dscp
dscp-ipv6
dscp
dscp-ipv6

Object
Name
Type
Index
Classifier
DSCP-BA
dscp
961
Classifier
9
Object
Name
Index
Rewrite
video-af
35765
338
Type
dscp
Classifier
Video
fixed
4
Object
Name
Index
Rewrite
voice-ef
28463
Classifier
Voice
5
Type
dscp
fixed
339

Description: --- To emulated IXIA branches (eon ge-0/0/21) --Forwarding classes: 8 supported, 7 in use
Queued:
Packets
:
206099861
2100 pps
Bytes
:
74954690293
6271968 bps
Transmitted:
Packets
:
206099861
2100 pps
Bytes
:
74954690293
6271968 bps
0
0 pps
0
0 pps
Low
:
0
0 pps
Medium-low
:
0
0 pps
Medium-high
:
0
0 pps
High
:
0
0 pps
RED-dropped bytes
:
0
0 bps
Low
:
0
0 bps
Medium-low
:
0
0 bps
Medium-high
:
0
0 bps
High
:
0
0 bps
Queued:
Packets
:
0
0 pps
Bytes
:
0
0 bps
Transmitted:
Packets
:
0
0 pps
Bytes
:
0
0 bps
0
0 pps
0
0 pps
Low
:
0
0 pps
Medium-low
:
0
0 pps
Medium-high
:
0
0 pps
High
:
0
0 pps
RED-dropped bytes
:
0
0 bps
Low
:
0
0 bps
Medium-low
:
0
0 bps
Medium-high
:
0
0 bps
High
:
0
0 bps
Queued:
Packets
:
68057734
799 pps
Bytes
:
34573282000
3250792 bps
Transmitted:
Packets
:
68057734
799 pps
Bytes
:
34573282000
3250792 bps
0
0 pps
0
0 pps
Low
:
0
0 pps
Medium-low
:
0
0 pps
Medium-high
:
0
0 pps
High
:
0
0 pps
RED-dropped bytes
:
0
0 bps
Low
:
0
0 bps
Medium-low
:
0
0 bps
Medium-high
:
0
0 bps
340
High
:
Queued:
Packets
:
Bytes
:
Transmitted:
Packets
:
Bytes
:
Low
:
Medium-low
:
Medium-high
:
High
:
RED-dropped bytes
:
Low
:
Medium-low
:
Medium-high
:
High
:
Queued:
Packets
:
Bytes
:
Transmitted:
Packets
:
Bytes
:
Low
:
Medium-low
:
Medium-high
:
High
:
RED-dropped bytes
:
Low
:
Medium-low
:
Medium-high
:
High
:
Queued:
Packets
:
Bytes
:
Transmitted:
Packets
:
Bytes
:
Low
:
Medium-low
:
Medium-high
:
High
:
RED-dropped bytes
:
Low
:
Medium-low
:
Medium-high
:
High
:
Queued:
Packets
:
Bytes
:
Transmitted:
Packets
:
0 bps
74891172
34900242422
800 pps
3175984 bps
74891172
34900242422
0
0
0
0
0
0
0
0
0
0
0
800 pps
3175984 bps
0 pps
0 pps
0 pps
0 pps
0 pps
0 pps
0 bps
0 bps
0 bps
0 bps
0 bps
67107671
34090667356
1000 pps
4064000 bps
67107671
34090667356
0
0
0
0
0
0
0
0
0
0
0
1000 pps
4064000 bps
0 pps
0 pps
0 pps
0 pps
0 pps
0 pps
0 bps
0 bps
0 bps
0 bps
0 bps
119126769
14770997856
1400 pps
1388992 bps
Critical_Data
Video
Voice
119126769
14770997856
0
0
0
0
0
0
0
0
0
0
0
Network_Control
42540243
10720122986
42540243
1400 pps
1388992 bps
0 pps
0 pps
0 pps
0 pps
0 pps
0 pps
0 bps
0 bps
0 bps
0 bps
0 bps
500 pps
1009000 bps
500 pps
341
Bytes
RED-dropped packets
Low
Medium-low
Medium-high
High
RED-dropped bytes
Low
Medium-low
Medium-high
High
342
:
:
:
:
:
:
:
:
:
:
:
:
10720122986
0
0
0
0
0
0
0
0
0
0
0
1009000
0
0
0
0
0
0
0
0
0
0
0
bps
pps
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
4. Verify CoS queues on the GRE tunnels.

user@branch> show interfaces queue gr-0/0/0
Burst size: 0
Queued:
Packets
:
226681173
Bytes
:
81436733911
Transmitted:
Packets
:
226678316
Bytes
:
81435285721
1541
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
RED-dropped bytes
:
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
Queued:
Packets
:
0
Bytes
:
0
Transmitted:
Packets
:
0
Bytes
:
0
0
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
RED-dropped bytes
:
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
Queued:
Packets
:
67131410
Bytes
:
34639807560
Transmitted:
Packets
:
67131081
Bytes
:
34639637796
0
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
RED-dropped bytes
:
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
2711 pps
7760328 bps
2711 pps
7760328 bps
0 pps
0 pps
0 pps
0 pps
0 pps
0 pps
0 bps
0 bps
0 bps
0 bps
0 bps
0 pps
0 bps
0 pps
bps
pps
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
0
0
0
0
0
0
0
0
0
0
0
0
803 pps
3316000 bps
803 pps
3316000 bps
0 pps
0 pps
0 pps
0 pps
0 pps
0 pps
0 bps
0 bps
0 bps
0 bps
0 bps
343

Queued:
Packets
:
Bytes
:
Transmitted:
Packets
:
Bytes
:
Low
:
Medium-low
:
Medium-high
:
High
:
RED-dropped bytes
:
Low
:
Medium-low
:
Medium-high
:
High
:
Queued:
Packets
:
Bytes
:
Transmitted:
Packets
:
Bytes
:
Low
:
Medium-low
:
Medium-high
:
High
:
RED-dropped bytes
:
Low
:
Medium-low
:
Medium-high
:
High
:
Queued:
Packets
:
Bytes
:
Transmitted:
Packets
:
Bytes
:
Low
:
Medium-low
:
Medium-high
:
High
:
RED-dropped bytes
:
Low
:
Medium-low
:
Medium-high
:
High
:
Queued:
Packets
:
Bytes
:
Transmitted:
Packets
:
Bytes
:
344
Critical_Data
67557032
26081332286
805 pps
2494672 bps
67556848
26081261824
23
0
0
0
0
0
0
0
0
0
0
805 pps
2494672 bps
0 pps
0 pps
0 pps
0 pps
0 pps
0 pps
0 bps
0 bps
0 bps
0 bps
0 bps
41954776
21648664416
502 pps
2073272 bps
41954716
21648633456
0
0
0
0
0
0
0
0
0
0
0
502 pps
2073272 bps
0 pps
0 pps
0 pps
0 pps
0 pps
0 pps
0 bps
0 bps
0 bps
0 bps
0 bps
117446026
15502875432
1405 pps
1484616 bps
Video
Voice
117445988
15502870416
0
0
0
0
0
0
0
0
0
0
0
Network_Control
1405 pps
1484616 bps
0 pps
0 pps
0 pps
0 pps
0 pps
0 pps
0 bps
0 bps
0 bps
0 bps
0 bps
41970048
10912205750
502 pps
1044672 bps
41969692
10912113190
502 pps
1044672 bps
RED-dropped packets
Low
Medium-low
Medium-high
High
RED-dropped bytes
Low
Medium-low
Medium-high
High
:
:
:
:
:
:
:
:
:
:
:
323
0
0
0
0
0
0
0
0
0
0

Burst size: 0
Queued:
Packets
:
3550579
Bytes
:
1334009096
Transmitted:
Packets
:
3420962
Bytes
:
1265283113
121212
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
RED-dropped bytes
:
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
Queued:
Packets
:
0
Bytes
:
0
Transmitted:
Packets
:
0
Bytes
:
0
0
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
RED-dropped bytes
:
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
Queued:
Packets
:
1049255
Bytes
:
541415580
Transmitted:
Packets
:
1047943
Bytes
:
540738588
14
0
0
0
0
0
0
0
0
0
0
0
0
pps
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
0 pps
0 bps
0 pps
bps
pps
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
0
0
0
0
0
0
0
0
0
0
0
0
0 pps
0 bps
0 pps
bps
pps
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
0
0
0
0
0
0
0
0
0
0
0
0
0 pps
0 bps
0 pps
0 bps
0 pps
0 pps
345
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
RED-dropped bytes
:
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
Queued:
Packets
:
1482284
Bytes
:
440888442
Transmitted:
Packets
:
1482063
Bytes
:
440802694
0
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
RED-dropped bytes
:
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
Queued:
Packets
:
655781
Bytes
:
338382996
Transmitted:
Packets
:
655708
Bytes
:
338345328
0
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
RED-dropped bytes
:
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
Queued:
Packets
:
1836197
Bytes
:
242378004
Transmitted:
Packets
:
1836152
Bytes
:
242372064
0
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
RED-dropped bytes
:
0
Low
:
0
Medium-low
:
0
346
0
0
0
0
0
0
0
0
0
pps
pps
pps
pps
bps
bps
bps
bps
bps
2 pps
1520 bps
2 pps
bps
pps
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
1520
0
0
0
0
0
0
0
0
0
0
0
0 pps
0 bps
0 pps
bps
pps
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
0
0
0
0
0
0
0
0
0
0
0
0
0 pps
0 bps
0 pps
bps
pps
pps
pps
pps
pps
pps
bps
bps
bps
0
0
0
0
0
0
0
0
0
0
Medium-high
:
0
High
:
0
Queued:
Packets
:
655904
Bytes
:
170514684
Transmitted:
Packets
:
655793
Bytes
:
170485824
27
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
RED-dropped bytes
:
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
0 bps
0 bps
0 pps
0 bps
0 pps
bps
pps
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
0
0
0
0
0
0
0
0
0
0
0
0
Configuring Link-Level High Availability on the Branch Router

Step-by-Step
Procedure
availability.
1.
Configure dead peer detection for IKE.

a. Add dead peer detection to the IKE gateway for Aggregation Hub 1.
[edit]
set dead-peer-detection always-send
set dead-peer-detection interval 10
set dead-peer-detection threshold 5
b. Add dead peer detection to the IKE gateway for Aggregation Hub 2.
[edit]
set dead-peer-detection always-send
set dead-peer-detection interval 10
set dead-peer-detection threshold 5
2.
[edit]
347
edit protocols ospf area 0.0.0.2 interface gr-0/0/0.1

3.

[edit]
commit
Results
Verify active BFD sessions on GRE tunnels

Address
172.16.1.1
172.16.1.5
State
Up
Up
Interface
gr-0/0/0.1
gr-0/0/0.2
Detect
Time
1.500
1.500
Transmit
Interval
0.500
0.500
Multiplier
3
3
348
Verification
Verifying End-to-End Data Traffic From the Branch
Purpose
Action
Verify that traffic is travelling end-to-end on the WAN transport to Aggregation Hub 1.
Run the following show command on the interface to the ISP.
user@branch> show interfaces ge-0/0/12 extensive
Description: --- To public ISP link (jbeer.PE1 fe-2/2/0) --Link-level type: Ethernet, MTU: 1514, Link-mode: Full-duplex, Speed: 100mbps,
BPDU Error: None,
MAC-REWRITE Error: None, Loopback: Disabled, Source filtering: Disabled, Flow
contol: Enabled,
Auto-negotiation: Enabled, Remote fault: Online
Device flags
: Present Running
Link flags
: None
CoS queues
Hold-times
Current address: f8:c0:01:8c:e5:0c, Hardware address: f8:c0:01:8c:e5:0c
Last flapped
: 2013-07-11 06:33:02 PDT (1w4d 08:51 ago)
Traffic statistics:
Input bytes :
24050979548186
18311512 bps
Output bytes :
1607029530371
20029000 bps
Input packets:
61293323878
5802 pps
Output packets:
4206882777
6499 pps
Input errors:
incompletes: 0,
L2 channel errors: 0, L2 mismatch timeouts: 0, FIFO errors: 0, Resource errors:
0
Output errors:
Carrier transitions: 1, Errors: 0, Drops: 0, Collisions: 0, Aged packets: 0,
FIFO errors: 0,
HS link CRC errors: 0, MTU errors: 0, Resource errors: 0
Queue counters:
Dropped packets
0 Best_Effort
1812260255
1812260255
1 Scavenger
2 Bulk_Data
517725523
517725523
3 Critical_Dat
519925434
519925434
4 Video
323579455
323579455
5 Voice
711867867
711867867
6 Network_Cont
323577885
323577885
Queue number:
0
1
2

Best_Effort
Scavenger
Bulk_Data
349
3
Critical_Data
4
Video
5
Voice
6
Network_Control
MAC statistics:
Receive
Transmit
Total octets
1539813184453
1683053270866
Total packets
3751615794
4208925916
Unicast packets
3751615349
4208925464
Broadcast packets
445
452
Multicast packets
0
0
CRC/Align errors
0
0
FIFO errors
469
0
MAC control frames
0
0
MAC pause frames
0
0
Oversized frames
0
Jabber frames
0
Fragment frames
0
VLAN tagged frames
0
Code violations
0
Filter statistics:
Input packet count
0
0
Input DA rejects
0
Input SA rejects
0
Output packet count
0
0
0
Link partner:
Link mode: Full-duplex, Flow control: None, Remote fault: OK, Link partner
Speed: 100 Mbps
Local resolution:
Flow control: None, Remote fault: Link OK
Destination slot: 0
CoS information:
Direction : Output
CoS transmit queue
Bandwidth
Buffer Priority
Limit
%
bps
%
usec
0 Best_Effort
95
950000000
95
0
low
none
3 Critical_Data
5
50000000
5
0
low
none
Logical interface ge-0/0/12.0 (Index 79) (SNMP ifIndex 542) (Generation 144)
Traffic statistics:
Input bytes :
24050972806826
Output bytes :
1607015914385
Input packets:
61293323879
Output packets:
4206882778
Local statistics:
Input bytes :
18708773
Output bytes :
49856647
Input packets:
169690
350
Output packets:
341301
Transit statistics:
Input bytes :
24050954098053
18311512 bps
Output bytes :
1606966057738
20028392 bps
Input packets:
61293154189
5802 pps
Output packets:
4206541477
6499 pps
Security: Zone: untrust
dhcpv6 r2cp
Flow Statistics :
Flow Input statistics :
Self packets :
167353
ICMP packets :
27040
VPN packets :
3589475062
Multicast packets :
0
Bytes permitted by policy :
17033313
Connections established :
0
Flow Output statistics:
Multicast packets :
0
Bytes permitted by policy :
25806316
Flow error statistics (Packets dropped due to):
Address spoofing:
0
Authentication failed:
0
Incoming NAT errors:
0
Invalid zone received packet:
0
Multiple user authentications:
0
Multiple incoming NAT:
0
No parent for a gate:
0
No one interested in self packets: 0
No minor session:
0
No more sessions:
0
No NAT gate:
0
No route present:
0
No SA for incoming SPI:
46497
No tunnel found:
0
No session for a gate:
0
No zone or NULL zone binding
0
Policy denied:
0
Security association not active:
2851
TCP sequence number out of window: 0
Syn-attack protection:
0
User authentication errors:
0
Destination: 1.1.0.0/30, Local: 1.1.0.2, Broadcast: 1.1.0.3, Generation:
170
351
Verifying Route Advertisement

Purpose
Action
Verify that routes are being advertised correctly.

Run the following command to verify route advertisement:
0.0.0.0/0
10.209.0.0/16
10.212.0.0/16
10.216.32.0/20
10.216.36.246/32
172.16.1.0/30
172.16.1.2/32
172.16.1.4/30
172.16.1.6/32
172.16.1.12/30
172.16.1.13/32
172.16.1.16/30
172.16.1.17/32
172.16.1.20/30
172.16.1.21/32
172.16.1.254/32
172.17.0.0/16
172.31.255.31/32
172.31.255.231/32
224.0.0.2/32
224.0.0.5/32
224.0.0.13/32
224.0.0.22/32
352
*[OSPF/10] 01:39:02, metric 11

> via gr-0/0/0.1
*[Static/5] 5w5d 12:22:33
> to 10.216.47.254 via ge-0/0/0.0
*[Static/5] 5w5d 12:22:33
> to 10.216.47.254 via ge-0/0/0.0
*[Direct/0] 5w5d 12:22:34
> via ge-0/0/0.0
*[Local/0] 5w5d 12:22:44
*[Direct/0] 1w5d 15:32:31
> via gr-0/0/0.1
[OSPF/10] 2d 16:44:56, metric 1
> via gr-0/0/0.1
*[Local/0] 5w5d 12:22:42
*[Direct/0] 5w5d 12:22:26
> via gr-0/0/0.2
[OSPF/10] 5w5d 12:22:21, metric 1
> via gr-0/0/0.2
*[Local/0] 5w5d 12:22:42
*[Direct/0] 5w5d 12:22:26
> via ge-0/0/8.40
*[Local/0] 5w5d 12:22:44
*[Direct/0] 5w5d 12:22:26
> via ge-0/0/8.50
*[Local/0] 5w5d 12:22:43
*[Direct/0] 5w5d 12:22:27
> via ge-0/0/8.60
*[Local/0] 5w5d 12:22:43
*[Direct/0] 5w5d 12:23:28
> via lo0.0
*[Static/5] 5w5d 12:22:33
> to 10.216.47.254 via ge-0/0/0.0
*[Static/5] 01:43:38
> via st0.0
*[Static/5] 07:27:20
> via st0.1
*[PIM/0] 5w5d 12:23:29
MultiRecv
*[OSPF/10] 5w5d 12:23:29, metric 1
MultiRecv
*[PIM/0] 5w5d 12:23:29
MultiRecv
*[IGMP/0] 5w5d 12:23:29
MultiRecv
Purpose
Action
Use this procedure to verify reachability and traffic paths to the loopback interface of
the data center router, the loopback interface of a router in a different branch, and an IP
address in the service provider network that is publicly routable.
1.
Verify connectivity to the loopback interface of the data center router.

PING 172.31.255.8 (172.31.255.8): 56 data bytes
!!!!!
1 172.16.1.1 (172.16.1.1) 3.131 ms 2.764 ms 2.864 ms
# GRE hub 1
2 172.31.254.13 (172.31.254.13) 2.680 ms 2.593 ms 2.687 ms #WAN aggr 1

PING 172.16.2.254 (172.16.2.254): 56 data bytes
^C
1 172.16.1.1 (172.16.1.1) 3.187 ms 3.117 ms 2.957 ms # GRE hub 1
2 172.31.254.13 (172.31.254.13) 2.974 ms 10.155 ms 30.400 ms # WAN aggr
1
3 172.31.254.33 (172.31.254.33) 11.832 ms 2.921 ms 2.669 ms# L3VPN ISP A
4 172.16.2.1 (172.16.2.1) 2.845 ms 3.053 ms 2.782 ms # Branch GRE
5 172.16.2.254 (172.16.2.254) 3.113 ms 3.117 ms 2.970 ms # Branch loopback
3. Verify connectivity from the branch to an IP address in the service provider network
that is publicly routable.

1 172.16.1.1 (172.16.1.1) 9.576 ms 3.219 ms 3.435 ms # GRE hub 1
2 172.31.254.13 (172.31.254.13) 3.472 ms 3.539 ms 4.053 ms WAN aggr 1
3 172.31.254.9 (172.31.254.9) 3.987 ms 3.011 ms 3.824 ms # Int Edge 1
4 191.15.100.1 (191.15.100.1) 4.080 ms 4.949 ms 5.251 ms # Int Edge 2
5 veloz-1-2-01.hotlink.com.br (189.1.2.1) 4.434 ms 3.415 ms 3.519 ms ISP
hop
6 * * *Expected because traceroute is blocked by SFW on Internet Edge
7 * * *
353
Verifying Failover from Primary Transport to Secondary Transport

Purpose
Action
Verify that a failure of the primary IPsec over GRE tunnel to Aggregation Hub 1 causes all
traffic to be rerouted through the secondary IPsec over GRE tunnel to Aggregation Hub
2.
1.
Log in to the branch router as the root user, and enter the following command to take
down the primary GRE tunnel interface to Aggregation Hub 1.
root@branch% ifconfig gr-0/0/0.1 down
2. Verify that the active default route is to the GRE interface to Aggregation Hub 2.
0.0.0.0/0
*[OSPF/10] 05:49:45, metric 11

> via gr-0/0/0.2

0.0.0.0/0
*[Static/5] 1w4d 02:13:28

> to 1.1.0.1 via ge-0/0/12.0
3. Verify that the GRE tunnel interface at Aggregation Hub 2 is an OSPF neighbor.
Address
Interface
172.16.1.5
gr-0/0/0.2
State
Full
ID
172.31.255.6
Pri
128
Dead
32
4. Check the path taken by traffic to the data center after the primary link failure.
PING 172.31.255.8 (172.31.255.8): 56 data bytes
!!!!!
1 172.16.1.5 (172.16.1.5) 6.205 ms 3.528 ms 3.569 ms # GRE endpoint hub 2
2 172.31.254.21 (172.31.254.21) 3.520 ms 7.031 ms 3.703 ms # WANaggr 2
loopback
5. Check the branch-to-branch path taken by traffic after the primary link failure.
PING 172.16.2.254 (172.16.2.254): 56 data bytes
!!!!!
1 172.16.1.5 (172.16.1.5) 3.505 ms 5.703 ms 7.324 ms # GRE endpoint hub 2
354
2
2
3
1
4
5
6
172.31.254.21 (172.31.254.21)
7.655 ms
2.815 ms
4.120 ms # WAN aggr hub
172.31.254.41 (172.31.254.41)
3.657 ms
3.387 ms
3.086 ms # WAN agg hub
172.31.254.33 (172.31.254.33) 4.149 ms 3.285 ms 9.461 ms # L3VPN hub 1

172.16.2.1 (172.16.2.1) 3.546 ms 10.941 ms 4.007 ms # GRE on Branch
172.16.2.254 (172.16.2.254) 3.180 ms 3.428 ms 4.112 ms # Branch loopback
6. Check the branch-to-Internet path taken by traffic after the primary link failure.
PING 100.65.4.2 (100.65.4.2): 56 data bytes
^C
1 172.16.1.5(172.16.1.5) 4.244 ms 9.479 ms 3.110 ms # GRE hub 2
2 172.31.254.21 (172.31.254.21) 3.434 ms 3.125 ms 3.497 ms # WAN aggr hub
2
3 172.31.254.41 (172.31.254.41) 3.548 ms 3.682 ms 3.315 ms # WAN aggr hub
1
4 172.31.254.9 (172.31.254.9) 3.730 ms 3.753 ms 8.749 ms # Internet Edge 1
5 191.15.100.1 (191.15.100.1) 3.759 ms 3.988 ms 4.878 ms # Internet Edge 2
6 veloz-1-2-01.hotlink.com.br (189.1.2.1) 3.851 ms 10.126 ms 3.660 ms # ISP
7 * * *
# Expected because trace route is blocked by SFW on Internet Edge
8 * * *
9 * * *
355
7. Check multicast traffic after failover.

a. Verify that the connection to the rendezvous points is over the GRE tunnels to
Aggregation Hub 2.
user@branch> show multicast rpf 172.16.31.15
Multicast RPF table: inet.0 , 24 entries
0.0.0.0/0
Protocol: OSPF
Interface: gr-0/0/0.2
Neighbor: (null)
b. Verify that groups are established with upstream GRE tunnel to the Aggregation
Hub 2 (gr-0/0/0.2) and downstream interfaces to the branch LAN (ge-0/0/8).

Group: 235.1.1.1
Source: 172.31.252.10/32
ge-0/0/8.40
Next-hop ID: 262143
Route state: Active
Uptime: 01:43:06
Group: 235.1.1.2
Source: 172.31.252.10/32
ge-0/0/8.40
Next-hop ID: 262143
Route state: Active
Uptime: 01:43:06
356
Verifying This Scenario from the VPN Termination Router on Aggregation Hub 1
Purpose
Action
Use this procedure to verify this scenario from the VPN termination router on Aggregation
Hub 1
1.
Verify IKE security associations.

user@vpn-router> show services ipsec-vpn ike security-associations
Remote Address State
Initiator cookie Responder cookie
type
1.1.0.2
Matured
2fa9609b522c5f75 7a28d06fe17bdab7
Exchange
Main
2. Verify IPsec security associations.

user@vpn-router> show services ipsec-vpn ipsec security-associations
Service set: BR1, IKE Routing-instance: VPN
Rule: _junos_, Term: tunnel1, Tunnel index: 1
Local gateway: 191.15.100.6, Remote gateway: 1.0.0.2
IPsec inside interface: sp-0/3/0.1, Tunnel MTU: 1500
Direction SPI
AUX-SPI
Mode
Type
inbound
2808949413 0
tunnel
dynamic
outbound 3177306642 0
tunnel
dynamic
Protocol
ESP
ESP
3. Verify IKE peers.

user@vpn-router> show services ipsec-vpn ike security-associations detail
IKE peer 1.1.0.2
Role: Responder, State: Matured
Initiator cookie: 8330e20474ab9bf5, Responder cookie: 5ab22ffd73c77477
Exchange type: Main, Authentication method: RSA-signatures
Local: 191.15.100.6, Remote: 1.1.0.2
Algorithms:
Authentication
: hmac-sha256-128
Encryption
: aes256-cbc
Traffic statistics:
Input bytes :
11512
Output bytes :
11192
Input packets:
107
Output packets:
106
Flags: IKE SA created
4. Verify IPsec security associations.
user@vpn-router> show services ipsec-vpn ipsec security-associations detail
Local identity: ipv4(any:0,[0..3]=172.31.255.31)
Remote identity: ipv4(any:0,[0..3]=172.16.1.255)
Direction: inbound, SPI: 3218543315, AUX-SPI: 0
Mode: tunnel, Type: dynamic, State: Installed
Protocol: ESP, Authentication: hmac-sha1-96, Encryption: 3des-cbc
Hard lifetime: Expires in 2569 seconds
357
Anti-replay service: Enabled, Replay window size: 128

Direction: outbound, SPI: 1979200377, AUX-SPI: 0
Protocol: ESP, Authentication: hmac-sha1-96, Encryption: 3des-cbc
5. Verify reverse route injection by checking that the correct static routes are inserted
into the routing table for the VPN routing instance.

user@vpn-router> show route table VPN.inet.0
0.0.0.0/0
172.16.1.255/32
*[Static/5] 01:54:40
> to 191.15.100.5 via ge-0/0/0.0
*[Static/1] 01:54:28
> via sp-0/3/0.1
6. Verify that traffic is flowing over the GRE tunnel.

user@vpn-router> show interfaces gr-0/1/0.1
Destination: fe80::/64, Local: fe80::2a0:a502:74:e54f
358
7. Verify that egress traffic from the hub is separated into queues.
user@vpn-router> interfaces queue gr-0/1/0.1 egress
Queued:
Packets
:
9214364874225190861
Bytes
:
9214364912392081712
Transmitted:
Packets
:
9214364874225190861
Bytes
:
9214364912392081712
0
RED-dropped packets : 18410715422711087136
Low, non-TCP
:
9214364874105159688
Low, TCP
:
9214364874105159688
High, non-TCP
:
9214364874105159688
High, TCP
:
9214364874105159688
RED-dropped bytes
: 18410715422711087136
Low, non-TCP
:
9214364874105159688
Low, TCP
:
9214364874105159688
High, non-TCP
:
9214364874105159688
High, TCP
:
9214364874105159688
Queued:
Packets
:
9214364874105159688
Bytes
:
5188692096283836424
Transmitted:
Packets
:
9214364874105159688
Bytes
:
9214364874105159688
0
Low, non-TCP
:
9214364874105159688
Low, TCP
:
9214364874105159688
High, non-TCP
:
9214364874105159688
High, TCP
:
9214364874105159688
RED-dropped bytes
: 18410715422711087136
Low, non-TCP
:
9214364874105159688
Low, TCP
:
9214364874105159688
High, non-TCP
:
9214364874105159688
High, TCP
:
9214364874105159688
Queued:
Packets
:
9214364874161408153
Bytes
:
9214364903185613489
Transmitted:
Packets
:
9214364874161408153
Bytes
:
9214364903185613489
0
Low, non-TCP
:
9214364874105159688
Low, TCP
:
9214364874105159688
High, non-TCP
:
9214364874105159688
High, TCP
:
9214364874105159688
RED-dropped bytes
: 18410715422711087136
Low, non-TCP
:
9214364874105159688
Low, TCP
:
9214364874105159688
High, non-TCP
:
9214364874105159688
High, TCP
:
9214364874105159688
1697 pps
4158920 bps
1697
4158920
0
0
0
0
0
0
0
0
0
0
0
pps
bps
pps
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
0 pps
0 bps
0
0
0
0
0
0
0
0
0
0
0
0
0
pps
bps
pps
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
800 pps
3308800 bps
800
3308800
0
0
0
0
0
0
0
0
0
0
0
pps
bps
pps
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
359
Queued:
Packets
:
9214364874161410076
Bytes
:
9214364895986342726
Transmitted:
Packets
:
9214364874161410076
Bytes
:
9214364895986342726
0
Low, non-TCP
:
9214364874105159688
Low, TCP
:
9214364874105159688
High, non-TCP
:
9214364874105159688
High, TCP
:
9214364874105159688
RED-dropped bytes
: 14385041682817089568
Low, non-TCP
:
9214364874105159688
Low, TCP
:
9214364874105159688
High, non-TCP
:
9214364874105159688
High, TCP
:
5188691134211162120
Queued:
Packets
:
9214364874175422110
Bytes
:
9214364910430660432
Transmitted:
Packets
:
9214364874175422110
Bytes
:
9214364910430660432
0
Low, non-TCP
:
9214364874105159688
Low, TCP
:
9214364874105159688
High, non-TCP
:
9214364874105159688
High, TCP
:
9214364874105159688
RED-dropped bytes
: 18410715422711087136
Low, non-TCP
:
9214364874105159688
Low, TCP
:
9214364874105159688
High, non-TCP
:
9214364874105159688
High, TCP
:
9214364874105159688
Queued:
Packets
:
9214364874182834757
Bytes
:
9214364884435941065
Transmitted:
Packets
:
9214364874182834757
Bytes
:
9214364884435941065
0
Low, non-TCP
:
9214364874105159688
Low, TCP
:
9214364874105159688
High, non-TCP
:
9214364874105159688
High, TCP
:
9214364874105159688
RED-dropped bytes
: 18410715422711087136
Low, non-TCP
:
9214364874105159688
Low, TCP
:
9214364874105159688
High, non-TCP
:
9214364874105159688
High, TCP
:
9214364874105159688
Queued:
Packets
:
9214364874140517033
Bytes
:
9214364883296699349
Transmitted:
Packets
:
9214364874140517033
Bytes
:
9214364883296699349
0
360
800 pps
2489600 bps
800
2489600
0
0
0
0
0
0
0
0
0
0
0
pps
bps
pps
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
1000 pps
4136000 bps
1000
4136000
0
0
0
0
0
0
0
0
0
0
0
pps
bps
pps
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
1100 pps
1170400 bps
1100
1170400
0
0
0
0
0
0
0
0
0
0
0
pps
bps
pps
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
501 pps
1045048 bps
501 pps
1045048 bps
0 pps
RED-dropped packets
Low, non-TCP
Low, TCP
High, non-TCP
High, TCP
RED-dropped bytes
Low, non-TCP
Low, TCP
High, non-TCP
High, TCP
:
:
:
:
:
:
:
:
:
:
18410715422711087136
9214364874105159688
9214364874105159688
9214364874105159688
9214364874105159688
14385040720744415264
9214364874105159688
5188690172138487816
9214364874105159688
9214364874105159688
0
0
0
0
0
0
0
0
0
0
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
8. Verify that OSPF and OSPFv3 are running to the WAN aggregation router and over
the GRE tunnel.

user@vpn-router>
Address
172.31.254.13
172.16.1.2
show ospf neighbor instance WAN-GRE

Interface
State
ID
ge-0/0/1.0
Full
172.31.255.2
gr-0/1/0.1
Full
172.16.0.255
user@vpn-router> show ospf3 neighbor instance WAN-GRE

ID
Interface
State
Pri
172.31.255.2
ge-0/0/1.0
Full
128
Neighbor-address fe80::5e5e:abff:fe0e:4202
172.16.0.255
gr-0/1/0.1
Full
128
Neighbor-address fe80::fac0:100:8c:e500
Pri
128
128
Dead
37
36
Dead
34
38
9. Verify multicast neighbors in the WAN-GRE routing instance.

user@vpn-router> show pim neighbors instance WAN-GRE
Interface
IP
ge-0/0/1.0
4
gr-0/1/0.1
4
gr-0/1/0.100
4
gr-0/1/0.1000
4
.
. . .
.
gr-0/1/0.995
4
gr-0/1/0.996
4
V Mode
2
2
2
2
Option
HPLGT
HPLGT
HPLGT
HPLGT
Uptime
23:30:16
15:53:59
23:29:56
23:29:50
Neighbor addr
172.31.254.13
172.16.1.2
172.21.2.102
172.21.16.118
2
2
HPLGT
HPLGT
23:30:16 172.21.16.98
23:30:18 172.21.16.102
361
362
CHAPTER 12
Connecting a Medium Branch to

Dual-Homed Aggregation Hubs over Layer
3 VPN with Internet Backup
Connecting a Medium Branch to Dual-Homed Aggregation Hubs over Layer 3 VPN with
Internet Backup
This scenario is a medium-sized branch with a single router that is dual-homed to the
aggregation hubs over a primary Layer 3 VPN transport and a secondary Internet transport.
Requirements
M7i Multiservice Edge Router with the following PICs:
Two 4-port Gigabit Ethernet Enhanced IQ2 PICs
2-port Channelized SONET/SDH OC3/STM1 PIC
MultiServices 100 PIC
Tunnel Services PIC
1x Gbe PIC
NOTE: This remote site type was tested using an M7i Multiservice Edge Router.
This design can be easily migrated to an MX Series with an MS-MIC for use
as an Internet-connected branch router. An example configuration is shown
here: Appendix A: Alternate Configuration Aggregation and Branch using
MX80 with Services MIC on page 737
363
Overview
This design is a medium-sized branch with a single branch router (Figure 76 on page 365).
364
For high availability, this is a dual-homed scenario with Aggregation Hub 1 as the primary
location and Aggregation Hub 2 as the backup location.
The primary transport to Aggregation Hub 1 is a Layer 3 VPN provided by a service

provider.
The secondary transport to Aggregation Hub 2 is the public Internet using GRE tunnels.
For security, the GRE tunnels run over IPsec tunnels. IPsec provides a secure session
and GRE provides the IP multicast and multiprotocol capabilities.
Link-level high availability on the Layer 3 VPN transport is provided by the service
provider.
For link-level high availability on the secondary transport, Bidirectional Forwarding

Detection (BFD) is used on IBGP sessions over the GRE tunnels for fast failure detection.
All traffic sent from the branch (to the data center, the Internet, or other branches)
uses the 0.0.0.0/0 route received over Layer 3 VPN (primary path) and GRE IPsec IBGP
session (secondary path).
The following routing protocols are used on the transport:
The primary Layer 3 VPN transport uses the EBGP routing protocol. The branch is a
peer with the Layer 3 VPN service provider.
The GRE tunnels that run over the Internet transport use IBGP to peer with the VPN
router at Aggregation Hub 2.
The LAN transport at the branch uses OSPF.
The secondary transport uses IBGP for a peer relationship over the GRE tunnels. BFD
is configured for this IBGP session for fast failure detection.
The branch router has three VLANs (data, voice, and video) configured towards the
branch switch.
CoS scheduling and shaping is applied to both the Layer 3 VPN physical link and the
GRE tunnels.
Chapter 12: Connecting a Medium Branch to Dual-Homed Aggregation Hubs over Layer 3 VPN with Internet Backup
Topology
Figure 76: Test Lab Topology Connecting Medium Branch over Layer 3
VPN with Backup GRE over IPsec Tunnel
365
Figure 77: Routing Configuration for Internet-Connected Branches (Dual

Homed)
Before you configure this scenario, configure the base configurations at Aggregation Hub
1 and Aggregation Hub 2. Then complete the following:
366

The primary Layer 3 VPN transport from the branch connects to the WAN aggregation
router at Aggregation Hub 1. To configure the WAN aggregation router at the hub, perform
these tasks:
Configuring the WAN Transport on the WAN Aggregation Router at Aggregation Hub
1 on page 367
Configuring EBGP Routing for the WAN Transport on the WAN Aggregation Router at
Applying CoS to the WAN Transport on the WAN Aggregation Router at Aggregation
Hub 1 on page 368
Configuring Multicast on the WAN Aggregation Router at Aggregation Hub 1 on page 368
Configuring the WAN Transport on the WAN Aggregation Router at Aggregation

Hub 1
Step-by-Step
Procedure
Configure the physical interface to the Layer 3 VPN service provider.

Enable hierarchical scheduling and VLAN tagging on the interface.
[edit]
set vlan-tagging
Configuring EBGP Routing for the WAN Transport on the WAN Aggregation Router
Step-by-Step
Procedure
Configure EBGP groups for peering between the WAN aggregation router at the hub and
the Layer 3 VPN service provider.
The policies have already been configured in the Aggregation Hub 1 base configuration.
1.
Configure a peer group for IPv4 traffic.

The SET_LOCAL_PREF import policy causes BGP to set the local preference of
routes received from BGP to 200. This setting gives a higher preference to routes
[edit]
edit protocols bgp group EBGP-AS_555
set type external
367
set export DENY_ALL

set neighbor 172.31.254.33 authentication-key "$9$qPTFCt0hSl7-jk.PzFcSr"
2.

The SET_LOCAL_PREF6 import policy causes BGP to set the local preference of
branch.
[edit]
edit protocols bgp group EBGP-AS_555-V6
set type external
set import SET_LOCAL_PREF6
set peer-as 555
set neighbor 2001:DB8:254:1::1 authentication-key "$9$1eqESl8XNYgaqmuBIErl2go"
Applying CoS to the WAN Transport on the WAN Aggregation Router at

Aggregation Hub 1
Step-by-Step
Procedure
1.
Create a traffic control profile to be applied to the WAN transport.

[edit]
edit class-of-service traffic-control-profiles TO-L3VPN-VPN1
2.
Apply the traffic control profile, classifiers, and rewrite rules to the WAN transport
interface. The classifiers and rewrite rules are configured in the aggregation hub
base configuration.
[edit]
set output-traffic-control-profile TO-L3VPN-VPN1
Configuring Multicast on the WAN Aggregation Router at Aggregation Hub 1

Step-by-Step
Procedure
1.
Add the physical interface to the Layer 3 VPN service provider to the multicast
configuration.
[edit]
edit protocols pim interface ge-1/2/5.0
set mode sparse
set version 2
368

The VPN termination role at Aggregation Hub 2 handles termination of IPsec over GRE
tunnels for the backup Internet transport. To configure the VPN termination role at
Aggregation Hub 2 perform these tasks:
Configuring WAN Transport Security on the VPN Termination Role at Aggregation Hub
2 on page 369
Configuring Dynamic Endpoints for IPsec Tunnels on the VPN Termination Role at
Configuring the Overlay WAN Transport on the VPN Termination Role at Role at
Configuring the Transport Routing Instances on the VPN Termination Role at

Configuring Private Overlay Routing on the VPN Termination Role at Aggregation Hub
2 on page 373
Configuring Link-Level High Availability on the VPN Termination Role at Aggregation

Hub 2 on page 374
Configuring Multicast on the VPN Termination Role at Aggregation Hub 2 on page 374
Applying CoS to the Tunnel Interfaces on the VPN Termination Role at Aggregation
Hub 2 on page 375
Configuring WAN Transport Security on the VPN Termination Role at Aggregation

Hub 2
Step-by-Step
Procedure
hub. The WAN transport security configuration consists of an Internet Key Exchange
(IKE) configuration for IPsec phase 1 negotiation and an IPsec configuration for phase 2
negotiation.
NOTE: Certificates are configured on the aggregation hubs as shown in the

previous chapter: Connecting a Small Branch to Dual-Homed Aggregation
Hubs over the Internet on page 281
1.
router.
[edit]
set dh-group group2
369
[edit]
set mode main
2.

[edit]
set protocol esp

[edit]
Configuring Dynamic Endpoints for IPsec Tunnels on the VPN Termination Role
Step-by-Step
Procedure
Dynamic endpoint IPsec is used to reduce the configuration and changes required when
a new branch comes online. You need to configure dynamic endpoints only once at the
aggregation hub.
1.

370
the GRE tunnel.
for the session.
[edit]
set ike ike-policy ike-phase1-policy
set ike interface-id IPsec_Clients_Group1
2.
multiple tunnels.
[edit]
3.
[edit interfaces sp-1/0/0] hierarchy.

[edit]
371
Aggregation Hub 2
Step-by-Step
Procedure
1.
interfaces.
[edit]
2.
[edit]
3.
[edit]
Configuring the Transport Routing Instances on the VPN Termination Role at

Aggregation Hub 2
Step-by-Step
Procedure
instances:
VPNA public Internet-facing instance. This instance terminates IPsec tunnels.
an IBGP peer with the IPsec tunnel at the branch.
1.
Add the IPsec interfaces and the loopback interface to the VPN routing instance.
The loopback interface is the remote endpoint for the branch. The address of the
loopback interface is used on the IPsec tunnels.
[edit]
372

set interface lo0.3
2.
Add the GRE tunnel interfaces to the WAN-GRE routing instance. Create a logical
unit for the number of GRE tunnels that can be formed to the branch. Add the
loopback interface for the GRE tunnels. The loopback interface address is used as
the GRE tunnel source address.
[edit]
set interface lo0.4
Configuring Private Overlay Routing on the VPN Termination Role at Aggregation

Hub 2
Step-by-Step
Procedure
Routing for the WAN transport is in the WAN-GRE routing instance. The routing in this
instance includes routing adjacencies over the GRE tunnel and to the WAN aggregation
1.
Create an IBGP peer group for IPv4 to peer with the remote GRE tunnel endpoint
at the branch.
This IBGP peer group uses the default local preference value of 100, which gives a
lower preference to routes to Aggregation Hub 2 than routes to Aggregation Hub 1,
which have a local preference value of 200.
The ADV_DEFAULT policy causes BGP to advertise only the default route to the
branch. It prevents the branch from receiving advertisements for routes to other
branches.
route reflector.
[edit]
edit routing-instances WAN-GRE protocols bgp group IBGPoGRE
set type internal
set passive
set out-delay 450
set authentication-key "$9$PTF6p01ylvdbkmfTn6rlK"
set cluster 0.0.0.3
set neighbor 172.16.2.6 description
2.
Create an IBGP peer group for IPv6 to peer with the remote GRE tunnel endpoint
at the branch.
373
The ADV_DEFAULT-V6 policy causes BGP to advertise only the default route to the
branches.
route reflector.
[edit]
edit routing-instances WAN-GRE protocols bgp group IBGPoGRE-V6
set type internal
set passive
set out-delay 450
set export ADV_DEFAULT-V6
set cluster 0.0.0.4
set neighbor fec0:16:2:4::2 authentication-key "$9$-WbY4UjkTznO1XNdbg4Qz3"
Configuring Link-Level High Availability on the VPN Termination Role at

Aggregation Hub 2
Step-by-Step
Procedure
availability.
1.

[edit]
2.
In the IBGP peer group to the remote end of the GRE tunnel at the branch, add the
following statements:
[edit]
Configuring Multicast on the VPN Termination Role at Aggregation Hub 2

Step-by-Step
Procedure
374
1.
Add the GRE tunnels to the multicast configuration at the hub.

[edit]
Applying CoS to the Tunnel Interfaces on the VPN Termination Role at Aggregation
Hub 2
Step-by-Step
Procedure
support per-unit GRE scheduling. To work around this, we are configuring CoS on logical
tunnel (lt) interfaces on the MX Series router. The lt interfaces apply CoS to egress traffic
before it is sent over the GRE tunnels to the branch.
1.
Apply the scheduler map to the GRE tunnel interfaces. The scheduler map is
configured in the Aggregation Hub 2 base configuration.
[edit]
2.
[edit]
3.
Apply the traffic control profile to the logical tunnel that is used for scheduling and
queueing.
[edit]
NOTE: Steps 2 and 3 are redundant and presented for completeness.

Junos OS 13.3 added support for per-GRE class of service. In earlier
versions of Junos OS, lt interfaces were required.
375

To configure the branch router, perform these tasks:
Configuring Routing Engine Protection on the Branch Router on page 376
Configuring the Router ID on the Branch Router on page 380
Configuring the Physical WAN Transport on the Branch Router on page 380
Configuring the Internet WAN Transport Routing on the Branch Router on page 381
Configuring the WAN Transport Routing Protocols on the Branch Router on page 383
Configuring Internet WAN Transport Security on the Branch Router on page 387
Configuring the Logical Internet WAN Transport on the Branch Router on page 390
Configuring the LAN Transport on the Branch Router on page 393
Configuring the Routing Protocol for the LAN Transport on the Branch Router on page 395
Configuring CoS on the Branch Router on page 398
Configuring Multicast on the Branch Router on page 415
Configuring Routing Engine Protection on the Branch Router

Step-by-Step
Procedure
1.
Create a set of prefix lists that are used in firewall filters that are set up for Routing
Engine protection. These prefix lists specify trusted IP subnets and addresses for
different types of traffic. Traffic received from these addresses will be allowed
through firewalls used for Routine Engine protection.
[edit]
edit policy-options
set prefix-list trusted-bgp-peers 2.2.0.0/24
set prefix-list trusted-networks 10.0.0.0/8
set prefix-list NMS 10.0.0.0/8
set prefix-list IPsec-Servers 191.15.200.0/24
2.

[edit]
edit firewall policer limit-150k
set if-exceeding bandwidth-limit 150k
set if-exceeding burst-size-limit 1500
set then discard
3.
376
Create a firewall filter used for Routing Engine protection. The filter is used to prevent
small packet attacks, fragment attacks, and denial of service (DoS) attacks from
traffic only from trusted sources, and it discards all other traffic. The filter also
includes a policer that applies rate limits to the traffic that is accepted by the filter.
a. Create the firewall filter, and specify that counters defined in the filter are
interface specific.
[edit]
b. Create a term for IPsec traffic.
[edit]
set term IPsec from source-prefix-list IPsec-Servers
set term IPsec then policer limit-150k
c. Create a term for BGP traffic.
[edit]
set term bgp-in from source-prefix-list trusted-bgp-peers
set term bgp-in then policer limit-150k
d. Create a term that accepts traffic from trusted PIM neighbors.
[edit]
set term pim from source-prefix-list trusted-networks
set term pim then policer limit-150k
e. Create a term that accepts OSPF traffic from trusted OSPF neighbors.
[edit]
set term ospf-in from source-prefix-list trusted-networks
set term ospf-in then policer limit-150k
f.

[edit]
set term bfd from source-prefix-list trusted-networks
377

g. Create a term for SNMP traffic.
[edit]
set term snmp-in then policer limit-150k
h. Create a term for ICMP traffic, which includes IPv4 error messages.
[edit]
set term icmp-in then policer limit-150k
i.
[edit]
j.
management systems.
[edit]
k. Create a term that accepts UDP and RADIUS traffic from trusted network
management systems.
[edit]
378

l.

[edit]
set term udp-services then policer limit-150k
m. Create a term for incoming traffic with a source and destination loopback address.
[edit]
n. Configure a term that prevents small packet attacks.
[edit]
o. Configure a term that prevents fragment attacks.
[edit]
p. Configure a term that explicitly discards all other traffic.
[edit]
4.
Apply the filter to loopback interfaces at the branch. For example:

[edit]
379

5.

[edit]
commit
Results

user@branch> show firewall filter RE-PROTECT-lo0.0-i

Step-by-Step
Procedure
1.

[edit]
Configuring the Physical WAN Transport on the Branch Router

Step-by-Step
Procedure
There are two physical WAN transports configured in this scenariothe physical interface
to the Layer 3 VPN service provider and the physical interface to the Internet service
provider.
1.

[edit]
set description "--- To LAYER3_VPN_PROVIDER1 ---"
set unit 0 family inet filter input v4_sample_filter deactivate unit 0 family inet filter
input
2.
Configure the physical interface to the Internet service provider.

[edit]
set description "--- To Public ISP link ---"
set unit 0 family inet filter input v4_sample_filter deactivate unit 0 family inet filter
3.

[edit]
commit
Results
1.
Verify that the physical transport to the Layer 3 VPN service provider is up:
Interface
Admin Link Proto
ge-0/0/2
up
up
380
Local
Remote
ge-0/0/2.0
up
up
inet
inet6
172.16.2.2/30
fe80::5e5e:abff:fefe:6802/64
2001:DB8:2:1::2/64
multiservice
2. Verify that the physical transport to the Internet service provider is up:
Interface
Admin Link Proto
Local
ge-0/0/1
up
up
ge-0/0/1.0
up
up
inet
2.2.0.2/30
multiservice
Remote
Configuring the Internet WAN Transport Routing on the Branch Router

Step-by-Step
Procedure
Configure the virtual routing instance for Internet traffic. The routing instance does not
allow traffic to the branch LAN from the Internet, and it protects the internal branch
routing tables.
1.
Unit 0 is used in the VPN termination routing instance, and is used for the
connections to the aggregation hub.
Unit 1 is used in the default routing instance, and is used with the branch LANs.
[edit]
edit interfaces lo0
set unit 0 family inet filter input RE-PROTECTION deactivate unit 0 family inet filter
input
set unit 1 description "--- Default Routing instance ---"
set unit 1 family inet filter input RE-PROTECTION deactivate unit 1 family inet filter
input
set unit 1 family inet6 address fec0:16:2::254/128
2.

[edit]
set unit 1 description "--- Hub2 IPsec tunnel inside ---"
set unit 2 description "--- Hub2 IPsec tunnel outside ---"
3.
Configure the routing instance and add the Internet-facing interfacesthe Ethernet
interface to the Internet service provider, Unit 0 of the loopback interface, and the
IPsec interfaces.
[edit]
381

set interface lo0.0
4.
Aggregation Hub 2. This route is used to establish GRE tunnels.
[edit]
5.
Configure the AS number for the VPN virtual router.

[edit]
set routing-options autonomous-system 64512
6.
Create an EBGP peer group to the Internet service provider gateway.

[edit]
edit routing-instances VPN protocols bgp
set group To_AS_69 type external
set group To_AS_69 peer-as 69
set group To_AS_69 neighbor 2.2.0.1
7.

[edit]
commit
Results
1.
Verify that the Internet service provider gateway is reachable from the VPN routing
instance.
PING 2.2.0.1 (2.2.0.1): 56 data bytes
ms
ms
ms
ms
ms
2. Verify EBGP peering with the Internet service provider gateway.
user@branch> show bgp summary instance VPN
Table
History Damp State
Pending
VPN.inet.0
1
1
0
0
0
0
VPN.mdt.0
0
0
0
0
0
0
Peer
AS
InPkt
OutPkt
OutQ
Flaps Last Up/Dwn
2.2.0.1
69
31149
30992
0
1 3d 15:00:01
Establ
VPN.inet.0: 1/1/1/0
382
routing table for the VPN routing instance.

user@branch> show route table VPN.inet.0
0.0.0.0/0
2.2.0.0/30
2.2.0.2/32
172.16.2.255/32
172.31.255.231/32
*[BGP/170] 1d 07:36:47, localpref 100

> to 2.2.0.1 via ge-0/0/1.0
*[Direct/0] 1d 07:36:51
> via ge-0/0/1.0
*[Local/0] 1w3d 05:14:28
*[Direct/0] 1w3d 05:15:14
> via lo0.0
*[Static/5] 1w3d 05:13:39
> via sp-0/3/0.1
Configuring the WAN Transport Routing Protocols on the Branch Router

Step-by-Step
Procedure
1.
Configure the AS number, and specify the number of times the AS can be in an AS
path.
[edit]
set autonomous-system loops 2
2.
Configure BGP routing policies.

a. Configure a policy that is used to accept only default IPv4 routes.
[edit]
b. Configure a policy that is used to accept only default IPv6 routes.
[edit]
c. Configure a policy that is used to control IPv4 routes that are advertised to the
aggregation hub.
This policy prevents the default static route from being advertised and allows
OSPF and direct routes to be advertised. Make the policy a next-hop self policy,
which causes the loopback address to be advertised as the next-hop address.
[edit]
383

set term branch then next-hop self
d. Configure a policy that is used to control IPv6 routes that are advertised to the
aggregation hub.
OSPF and direct routes to be advertised.
[edit]
e. Configure a policy that sets the local preference to 200 for the IPv4 default route
and IPv4 routes learned from BGP.

[edit]
set term 1 then local-preference 200
f.
Configure a policy that sets the local preference to 200 for the IPv6 default route
[edit]
edit policy-options policy-statement SET_LOCAL_PREF6
3.
Configure EBGP peer groups between the branch and the Layer 3 VPN service
provider.
a. Configure an IPv4 EBPG peer group between the branch router and the Layer 3
VPN service provider.

The SET_LOCAL_PREF import policy sets the local preference value for routes
over the Layer 3 VPN to 200. Routes to the Internet service provider use the
default local route preference value of 100, which gives the Layer 3 VPN routes
a higher preference.
384

[edit]
set type external
set family inet multicast
set peer-as 555
set local-as 64512
set neighbor 172.16.2.1 authentication-key "$9$6-ufCpBcyKxNbIENbs2GU/Ct"
b. Configure an IPv6 EBPG peer group between the branch router and the Layer 3
VPN service provider.

The SET_LOCAL_PREF6 import policy sets the preference value for routes over
the Layer 3 VPN to 200. Routes to the Internet service provider use the default
local route preference value of 100, which gives the Layer 3 VPN routes a higher
preference.
The BRANCH-PREFIX6 export policy controls default route advertisement to
the hub. It prevents default routes learned by another protocol from being
advertised to the hub, and causes the loopback address of the branch router to
be advertised to the hub as the next hop.
[edit]
set type external
set export BRANCH-PREFIX6
set peer-as 555
set local-as 64512
set neighbor fec0:16:2:1::1 authentication-key "$9$H.fz9A0hSe36SevW-dk.P"
4.
Configure IBGP peer groups between the branch and the remote end of the GRE
tunnels.
a. Configure an IPv4 IBPG peer group to the remote end of the GRE tunnel.
The ACCEPT_DEFAULT import policy accepts only the default route from the
hub, which prevents routes from other branches from being distributed to the
branch.
[edit]
edit protocols bgp group IBGPoGRE-H2
set type internal
385

set neighbor 172.16.2.5 authentication-key "$9$BlaRcrWL7s2ok.pO1RyrY24"
b. Configure an IPv6 IBGP peer group to the remote end of the GRE tunnel.
The ACCEPT_DEFAULT-V6 import policy accepts only the default route from
the hub, which prevents routes from other branches from being distributed to
the branch.
The BRANCH-PREFIX-V6 export policy controls default route advertisement to
the hub. It prevents default routes learned by another protocol from being
advertised to the hub, and causes the loopback address of the branch router to
[edit]
edit protocols bgp group IBGPoGRE-H2-V6
set type internal
set neighbor fec0:16:2:4::1 authentication-key "$9$JxUiqTznp01evgaZUkqu0B"
5.

[edit]
commit
Results
1.
Verify BGP peering to the Internet service provider gateway (2.2.0.2), to the Layer 3
VPN service provider gateway (172.16.2.1), and to the remote GRE tunnel endpoint
(172.16.2.5).
Table
History Damp State
Pending
inet.0
1
1
0
0
0
0
inet6.0
1
1
0
0
0
0
Peer
AS
InPkt
OutPkt
OutQ
Flaps Last Up/Dwn
2.2.0.1
69
21912
21862
0
0 6d 21:23:11
Establ
VPN.inet.0: 1/1/1/0
172.16.2.1
555
21675
21901
0
0 6d 21:23:15
Establ
inet.0: 1/1/1/0
172.16.2.5
65530
5609
6130
0
4 4d 22:44:45
Connect
fec0:16:2:1::1
555
21673
22056
0
0 6d 21:23:04
Establ
inet6.0: 1/1/1/0
fec0:16:2:4::1
65530
5609
6286
0
3 4d 22:44:42
Active
386
2. Verify that default routes to the Layer 3 VPN transport have a higher preference than
routes to the GRE tunnels.

The route to the Layer 3 VPN service provider over ge-0/0/2 is active, and it has a
local preference of 200, which makes it preferred over the route to the Aggregation
Hub 2 over the GRE tunnels, which has a local preference of 100.
user@branch> show route table inet.0 protocol bgp
0.0.0.0/0
*[BGP/170] 07:01:31, localpref 200

AS path: 555 65530 I, validation-state: unverified
> to 172.16.2.1 via ge-0/0/2.0
[BGP/170] 00:26:38, MED 0, localpref 100
> to 172.16.2.5 via gr-0/2/0.2
Configuring Internet WAN Transport Security on the Branch Router

Step-by-Step
Procedure
For the backup Internet transport to Aggregation Hub 2, IPsec is used to secure the GRE
tunnels between the branch and the aggregation hub. The WAN transport security
configuration consists of an Internet Key Exchange (IKE) configuration for IPsec phase
1 negotiation and an IPsec configuration for phase 2 negotiation.
1.
For IKE phase 1 negotiation, configure an IKE proposal and policy, and define the

[edit]
set dh-group group2
[edit]
set mode main
2.
For IPsec phase 2 negotiation, configure an IPsec proposal and policy, and then
configure an IPsec rule for the remote destination at the aggregation hub.
[edit]
387
set dh-group group2


[edit]
c. Configure an IPsec rule.
The destination address is the address of the GRE tunnel interface at the
aggregation hub.
The source and destination addresses must match the proxy identity values set
in the IPsec_Clients_Group1 IKE access profile configured on the VPN termination
router at the aggregation hub.
The remote gateway is the address of the logical tunnel interface (lt-5/1/0.53)
in the VPN routing instance at Aggregation Hub 2.
[edit]
edit services ipsec-vpn rule To_Hub2
set term 1 from source-address 172.16.2.255/32
set term 1 from destination-address 172.31.255.231/32
set term 1 then remote-gateway 191.15.200.6
set term 1 then dynamic ike-policy ike-phase1-policy
set term 1 then dynamic ipsec-policy dynamic_ipsec_policy
3.
Configure a next-hop style service set for IPsec interfaces.
The inside and outside IPsec interfaces must match the inside and outside service
domain configuration at the [edit interfaces sp-0/3/0] hierarchy.
The local gateway is the Internet service provider gateway.
Specify that the local gateway is in the VPN routing instance.

[edit]
edit services service-set To_Hub2
set ipsec-vpn-rules To_Hub2
4.
Enable the establishment of tunnels upon receipt of traffic.

[edit]
edit services ipsec-vpn
set establish-tunnels on-traffic
388
5.

[edit]
commit
Results
To verify that IPsec is running on GRE tunnels to Aggregation Hub 2:

1.
Verify reachability of the IKE gateway at the aggregation hub.

0.0.0.0/0
*[BGP/170] 1d 08:57:38, localpref 100

> to 2.2.0.1 via ge-0/0/1.0

PING 192.0.2.6 (192.0.2.6): 56 data
64 bytes from 192.0.2.6: icmp_seq=0
bytes
ttl=60
ttl=60
ttl=60
ttl=60
ttl=60
time=0.947
time=0.887
time=0.898
time=0.909
time=0.912
ms
ms
ms
ms
ms
2. Verify IKE security associations for Aggregation Hub 2.
user@branch> show services ipsec-vpn ike security-associations
Initiator cookie Responder cookie Exchange
type
192.0.2.6
Not matured
334a28e9694a22c5 0000000000000000 Main
3. Verify IKE security associations for Aggregation Hub 2.
user@branch> show services ipsec-vpn ike security-associations detail
IKE peer 192.0.2.6
Role: Initiator, State: Matured
Initiator cookie: d9d21dadbf8be9ea, Responder cookie: 511417b7267560d7
Local: 2.2.0.2, Remote: 191.15.200.6
Algorithms:
Authentication
: hmac-sha256-128
Encryption
: aes256-cbc
Traffic statistics:
Input bytes :
89432
Output bytes :
89680
Input packets:
968
Output packets:
970
4. Verify IPsec security associations for Aggregation Hub 2.
user@branch> show services ipsec-vpn ipsec security-associations extensive
389
Service set: To_HEAD-END2, IKE Routing-instance: VPN

Rule: To_HEAD-END1, Term: 1, Tunnel index: 1
Protocol: ESP, Authentication: hmac-sha256-128, Encryption: aes256-cbc
Protocol: ESP, Authentication: hmac-sha256-128 Encryption: aes256-cbc
5. Verify IPsec security associations for Aggregation Hub 2 (192.0.2.6).
user@branch> show services ipsec-vpn ipsec security-associations extensive
Configuring the Logical Internet WAN Transport on the Branch Router

Step-by-Step
Procedure
Create GRE tunnel interfaces to the aggregation hub.
1.

[edit]
set family inet filter input mcast1
2.

[edit]
commit
390
Results
1.
Verify that the default route to GRE tunnel destination to Aggregation Hub 2 is
reachable.
Note that the default route to Aggregation Hub 1 over the Ethernet interface to the
Layer 3 VPN is active, but the default route to Aggregation Hub 2 over the GRE tunnel
is not active. The route to the Layer 3 VPN is active because it has a higher local
preference than the GRE tunnel. The default route over the GRE tunnel becomes
active only if the route to the Layer 3 VPN goes down.
0.0.0.0/0
*[BGP/170] 00:05:26, localpref 200

> to 172.16.2.1 via ge-0/0/2.0
> to 172.16.2.5 via gr-0/2/0.2

172.31.255.231/32
*[Static/5] 1w3d 07:05:06

> via sp-0/3/0.10
user@branch> ping 172.31.255.231 source 172.16.2.255 routing-instance VPN count 5

PING 172.31.255.231 (172.31.255.231): 56 data bytes
2. Verify that the GRE interfaces are up, and that the interface destinations to the
aggregation hub are reachable.

user@branch> show interfaces terse gr-0/2/0
Interface
Admin Link Proto
gr-0/2/0
up
up
gr-0/2/0.2
up
up
inet
inet6
Local
Remote
172.16.2.6/30
fe80::2a0:a504:73:96be/64
2001:DB8:2:4::2/64

PING 172.16.2.5 (172.16.2.5): 56 data bytes
!!!!!
3. Verify that traffic is flowing from the GRE tunnels to the aggregation hub, and that
ToS Byte reflection is on.

user@branch> show interfaces gr-0/2/0
391

Device flags
: Present Running
Interface flags: Point-To-Point SNMP-Traps
Input rate
: 35954464 bps (12253 pps)
Output rate
: 41461936 bps (15003 pps)
Flags: Point-To-Point SNMP-Traps 0x4000
IP-Header 172.31.255.231:172.16.2.255:47:df:64:0000000000000400
Encapsulation: GRE-NULL
Copy-tos-to-outer-ip-header: On
Destination: fe80::/64, Local: fe80::2a0:a504:73:96be
interfaces are up.

user@branch> show interfaces terse sp-0/3/0
Interface
Admin Link Proto
sp-0/3/0
up
up
sp-0/3/0.0
up
up
inet
sp-0/3/0.1
up
up
inet
sp-0/3/0.2
up
up
inet
Local
Remote

user@branch> show interfaces sp-0/3/0
Type: Adaptive-Services, Link-level type: Adaptive-Services, MTU: 9192, Speed:
1000mbps
Device flags
: Present Running
Interface flags: Point-To-Point SNMP-Traps Internal: 0x4000
Link type
: Full-Duplex
Link flags
: None
Last flapped
: 2013-06-18 08:46:12 PDT (1w3d 08:42 ago)
Input rate : 177151376 bps (54508 pps)
Output rate : 87446912 bps (27255 pps)
Output packets: 0
Flags: Sendbcast-pkt-to-re, Receive-options, Receive-TTL-Exceeded
Description: --- Hub2 IPsec tunnel inside --Flags: Point-To-Point SNMP-Traps Encapsulation: Adaptive-Services
392

Description: --- Hub2 IPsec tunnel outside --Flags: Point-To-Point SNMP-Traps Encapsulation: Adaptive-Services

Step-by-Step
Procedure
voice.
1.
Configure the interface, and enable it for VLAN tagging.

[edit]
set vlan-tagging
2.

[edit]
set description "--- Data VLAN 41---"
set vlan-id 41
3.

[edit]
set vlan-id 51
4.

[edit]
set description "--- To VOICE VLAN 61 ---"
set vlan-id 61
5.

[edit]
commit
393
Results

Link-level type: Ethernet, MTU: 1518, Link-mode: Full-duplex, Speed: 1000mbps,
BPDU Error: None, MAC-REWRITE Error: None, Loopback: Disabled,
Device flags
: Present Running
CoS queues
Current address: f8:c0:01:8c:e5:08, Hardware address: f8:c0:01:8c:e5:08
Last flapped
: 2013-04-12 04:24:19 PDT (5w5d 12:20 ago)
Input rate
: 16759720 bps (6698 pps)
Output rate
: 17724152 bps (6892 pps)
Description: DATA
dhcpv6 r2cp
Flags: Is-Primary
Description: VIDEO
dhcpv6 r2cp
Flags: None
394

Description: VOICE
dhcpv6 r2cp
Flags: None
Destination: fe80::/64, Local: fe80::fac0:100:3c8c:e508
Input packets : 0
Output packets: 0
Configuring the Routing Protocol for the LAN Transport on the Branch Router
Step-by-Step
Procedure
1.
Create a backbone area, add unit 1 of the loopback interface, and then add the
branch LAN interfaces to the area.
[edit]
set interface lo0.1
2.
Create a backbone area for OSPFv3, add unit 1 of the loopback interface, and then
add the branch LAN interfaces to the area.
[eedit protocols ospf3 area 0.0.0.0]
set interface lo0.1
3.

[edit]
commit
395
Results
To verify OSPF on the branch LAN:

1.
Verify that the branch LAN interfaces are neighbors.

Address
Interface
172.16.2.10
ge-0/0/0.41
172.16.2.14
ge-0/0/0.51
172.16.2.18
ge-0/0/0.61
State
Full
Full
Full
ID
172.16.2.10
172.16.2.14
172.16.2.18
Pri
0
0
0
Dead
33
33
33
2. Verify OSPF routes on the branch LAN and on the loopback interface.
user@branch> show ospf route extensive
Topology default Route Table:
Prefix
Path
Route
172.16.2.10
Type Type
Intra AS BR
NH
Metric NextHop
Type
IP
Nexthop
Interface
1 ge-0/0/0.41
Address/LSP
172.16.2.10
area 0.0.0.0, origin 172.16.2.10, optional-capability 0x2

172.16.2.14
Intra AS BR
IP
1 ge-0/0/0.51
172.16.2.14

172.16.2.18
Intra AS BR
IP
1 ge-0/0/0.61
172.16.2.18

10.2.1.0/24
Ext1 Network
IP
11 ge-0/0/0.41
172.16.2.10

10.2.2.0/24
Ext1 Network
IP
11 ge-0/0/0.41
172.16.2.10

10.2.3.0/24
Ext1 Network
IP
11 ge-0/0/0.41
172.16.2.10

. . .
area 0.0.0.0,
172.16.2.12/30
area 0.0.0.0,
172.16.2.16/30
area 0.0.0.0,
172.16.2.254/32
area 0.0.0.0,
origin 10.255.36.244, priority

Intra Network
IP
Intra Network
IP
Intra Network
IP
low
1 ge-0/0/0.51
low
1 ge-0/0/0.61
low
0 lo0.1
low

Step-by-Step
Procedure
availability.
BFD with IBGP for GRE tunnels to detect failures over the GRE tunnels.
1.
Add dead peer detection to the To_hub_2 IPsec rule.

[edit]
edit services ipsec-vpn rule To_hub_2
396
set term 1 then initiate-dead-peer-detection

set term 1 then dead-peer-detection interval 20
set term 1 then dead-peer-detection threshold 5
2.
In the IBGP peer group to the remote end of the GRE tunnel at the aggregation hub,
add the following statements:
We are using BFD with BGP to detect link failures over the GRE tunnels.
[edit]
3.

[edit]
commit
Results
Verify active BFD sessions on GRE tunnels.

Address
172.16.2.5
State
Up
Interface
gr-0/2/0.2
Detect
Time
1.500
Transmit
Interval
0.500
Multiplier
3
397

Step-by-Step
Procedure
1.
[edit]
[edit]
[edit]
set queue 4 Video
set queue 5 Voice
2.

[edit]
398

[edit]
399
3.

[edit]
[edit]
set priority low
[edit]
[edit]
set priority high
[edit]
set priority high
f.

[edit]
[edit]
set priority high
400
4.

[edit]
5.
Create a traffic control profile to be applied to the link to the Layer 3 VPN.
We are setting a shaping rate instead of a policer because the shaper has a buffer
and is more flexible than a policer, which applies a hard limit to the rate and drops
packets when a transmission rate is reached.
[edit]
edit class-of-service traffic-control-profiles mpls-link
6.
Create a traffic control profile to be applied to GRE tunnels.

We are setting a shaping rate on GRE tunnels instead of a policer because the shaper
has a buffer and is more flexible than a policer, which applies a hard limit to the rate
and drops packets when a transmission rate is reached.
[edit]
edit class-of-service traffic-control-profiles internet-link
7.
Apply CoS to the Layer 3 VPN link.

[edit]
set output-traffic-control-profile mpls-link
8.

[edit]
set output-traffic-control-profile internet-link
9.

[edit]
401
10.
[edit]
[edit class-of-service host-outbound-traffic
11.

This procedure enables per-unit scheduling for GRE tunnels on M7i Series routers
a. Enable per-unit CoS scheduling on GRE tunnels.
This step adds all the functionality of tunnel PICs to GRE tunnels. CoS for GRE
tunnel traffic is applied as the traffic is looped through IQ2 and IQ2E PICs. Shaping
is performed on full packets that pass through the GRE tunnel.
Include the tunnel-only statement to specify that the PIC works exclusively in
tunnel mode.
[edit]
set chassis fpc 0 pic 2 tunnel-services tunnel-only
b. Enable CoS queuing and scheduling on both the egress and ingress sides for the
PIC.
[edit]
set chassis fpc 0 pic 2 traffic-manager mode ingress-and-egress
c. Enable hierarchical scheduling on the GRE tunnel interfaces.
[edit]
set interfaces gr-0/2/0 hierarchical-scheduler
d. Specify that the ToS byte is to be copied from the inner IP header to the outer
header of GRE tunnels

[edit]
set interfaces gr-0/2/0 unit 2 copy-tos-to-outer-ip-header
12.

[edit]
commit
402
Results
1.
Verify CoS on the Layer 3 VPN interface.

Output traffic control profile: mpls-link, Index: 9175
Object
Name
Rewrite
Classifier
Type
dscp
ip
Index
51863
13
2. Verify CoS on the GRE interface.

user@branch> show class-of-service interface gr-0/2/0
Object
Name
Type
Traffic-control-profile internet-link
Output
Rewrite
dscp
Classifier
DSCP-BA
dscp
Index
29951
51863
961

Scheduler map: default, Index: 2
Input scheduler map: default, Index: 2
Chassis scheduler map: default-chassis, Index: 4
Object
Name
Type
Traffic-control-profile __control_tc_prof
Input
Output
Index
45866
45866

Object
Name
Classifier
DSCP-BA
Type
dscp
Index
961

Object
Name
Classifier
Video
Type
fixed
Index
4

Object
Name
Classifier
Voice
Type
fixed
Index
5
4. Verify CoS queues on the Layer 3 VPN interface.

403
Description: --- To MPLS_VPN_PROVIDER1 link (jbeer ge-7/0/3) --Forwarding classes: 16 supported, 7 in use
Ingress queues: 8 supported, 7 in use
Queued:
Packets
:
10383056799
12401 pps
Bytes
:
3834330678075
36711296 bps
Transmitted:
Packets
:
10383056799
12401 pps
Bytes
:
3834330678075
36711296 bps
Tail-dropped packets : Not Available
0
0 pps
Low
:
0
0 pps
Medium-low
:
0
0 pps
Medium-high
:
0
0 pps
High
:
0
0 pps
RED-dropped bytes
:
0
0 bps
Low
:
0
0 bps
Medium-low
:
0
0 bps
Medium-high
:
0
0 bps
High
:
0
0 bps
Queued:
Packets
:
0
0 pps
Bytes
:
0
0 bps
Transmitted:
Packets
:
0
0 pps
Bytes
:
0
0 bps
0
0 pps
Low
:
0
0 pps
Medium-low
:
0
0 pps
Medium-high
:
0
0 pps
High
:
0
0 pps
RED-dropped bytes
:
0
0 bps
Low
:
0
0 bps
Medium-low
:
0
0 bps
Medium-high
:
0
0 bps
High
:
0
0 bps
Queued:
Packets
:
0
0 pps
Bytes
:
0
0 bps
Transmitted:
Packets
:
0
0 pps
Bytes
:
0
0 bps
0
0 pps
Low
:
0
0 pps
Medium-low
:
0
0 pps
Medium-high
:
0
0 pps
High
:
0
0 pps
RED-dropped bytes
:
0
0 bps
Low
:
0
0 bps
Medium-low
:
0
0 bps
Medium-high
:
0
0 bps
High
:
0
0 bps
Queued:
Packets
:
670064141
800 pps
Bytes
:
168826758233
1612800 bps
404
Transmitted:
Packets
:
670064141
Bytes
:
168826758233
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
RED-dropped bytes
:
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
Queued:
Packets
:
0
Bytes
:
0
Transmitted:
Packets
:
0
Bytes
:
0
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
RED-dropped bytes
:
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
Queued:
Packets
:
0
Bytes
:
0
Transmitted:
Packets
:
0
Bytes
:
0
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
RED-dropped bytes
:
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
Queued:
Packets
:
0
Bytes
:
0
Transmitted:
Packets
:
0
Bytes
:
0
0
Low
:
0
Medium-low
:
0
800 pps
1612800 bps
0
0
0
0
0
0
0
0
0
0
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
0 pps
0 bps
0 pps
0 bps
0
0
0
0
0
0
0
0
0
0
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
0 pps
0 bps
0 pps
0 bps
0
0
0
0
0
0
0
0
0
0
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
0 pps
0 bps
0 pps
0 bps
0 pps
0 pps
0 pps
405
Medium-high
:
0
High
:
0
RED-dropped bytes
:
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
Queued:
Packets
:
6534515537
Bytes
:
2432521370086
Transmitted:
Packets
:
6534515537
Bytes
:
2432521370086
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
RED-dropped bytes
:
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
Queued:
Packets
:
0
Bytes
:
0
Transmitted:
Packets
:
0
Bytes
:
0
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
RED-dropped bytes
:
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
Queued:
Packets
:
1507969192
Bytes
:
766048349536
Transmitted:
Packets
:
1507969192
Bytes
:
766048349536
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
RED-dropped bytes
:
0
Low
:
0
Medium-low
:
0
406
0
0
0
0
0
0
0
pps
pps
bps
bps
bps
bps
bps
7801 pps
23182432 bps
7801 pps
23182432 bps
0
0
0
0
0
0
0
0
0
0
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
0 pps
0 bps
0 pps
0 bps
0
0
0
0
0
0
0
0
0
0
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
1800 pps
7315200 bps
1800 pps
7315200 bps
0
0
0
0
0
0
0
0
pps
pps
pps
pps
pps
bps
bps
bps
Medium-high
:
0
High
:
0
Queued:
Packets
:
1172867746
Bytes
:
445689383032
Transmitted:
Packets
:
1172867746
Bytes
:
445689383032
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
RED-dropped bytes
:
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
Queued:
Packets
:
1047200842
Bytes
:
531978028240
Transmitted:
Packets
:
1047200842
Bytes
:
531978028240
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
RED-dropped bytes
:
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
Queued:
Packets
:
1633633313
Bytes
:
202570530812
Transmitted:
Packets
:
1633633313
Bytes
:
202570530812
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
RED-dropped bytes
:
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
Queued:
Packets
:
670510720
Bytes
:
168931059291
Transmitted:
0 bps
0 bps
1400 pps
4256000 bps
1400 pps
4256000 bps
0
0
0
0
0
0
0
0
0
0
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
1250 pps
5084032 bps
1250 pps
5084032 bps
0
0
0
0
0
0
0
0
0
0
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
1950 pps
1934400 bps
1950 pps
1934400 bps
0
0
0
0
0
0
0
0
0
0
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
800 pps
1612800 bps
407
Packets
Bytes
RED-dropped packets
Low
Medium-low
Medium-high
High
RED-dropped bytes
Low
Medium-low
Medium-high
High
:
670510720
:
168931059291
: Not Available
:
0
:
0
:
0
:
0
:
0
:
0
:
0
:
0
:
0
:
0
Packet Forwarding Engine Chassis Queues:

Queues: 8 supported, 7 in use
Queued:
Packets
:
16919191673
Bytes
:
5959189996312
Transmitted:
Packets
:
16919191674
Bytes
:
5959189996674
0
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
RED-dropped bytes
:
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
Queued:
Packets
:
0
Bytes
:
0
Transmitted:
Packets
:
0
Bytes
:
0
0
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
RED-dropped bytes
:
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
Queued:
Packets
:
1508111772
Bytes
:
738986008704
Transmitted:
Packets
:
1508111772
Bytes
:
738986008704
0
0
408
800 pps
1612800 bps
0
0
0
0
0
0
0
0
0
0
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
20200 pps
57282048 bps
20200
57282848
0
0
0
0
0
0
0
0
0
0
0
pps
bps
pps
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
0 pps
0 bps
0
0
0
0
0
0
0
0
0
0
0
0
0
pps
bps
pps
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
1800 pps
7056000 bps
1800
7056000
0
0
pps
bps
pps
pps
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
RED-dropped bytes
:
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
Queued:
Packets
:
1842847674
Bytes
:
581376003284
Transmitted:
Packets
:
1842847674
Bytes
:
581376003284
0
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
RED-dropped bytes
:
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
Queued:
Packets
:
1047299855
Bytes
:
513184734644
Transmitted:
Packets
:
1047299855
Bytes
:
513184734644
0
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
RED-dropped bytes
:
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
Queued:
Packets
:
1633787774
Bytes
:
173193681014
Transmitted:
Packets
:
1633787774
Bytes
:
173193681014
0
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
RED-dropped bytes
:
0
Low
:
0
Medium-low
:
0
0
0
0
0
0
0
0
0
0
pps
pps
pps
pps
bps
bps
bps
bps
bps
2200 pps
5552000 bps
2200
5552000
0
0
0
0
0
0
0
0
0
0
0
pps
bps
pps
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
1250 pps
4900000 bps
1250
4900000
0
0
0
0
0
0
0
0
0
0
0
pps
bps
pps
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
1950 pps
1653600 bps
1950
1653600
0
0
0
0
0
0
0
0
0
pps
bps
pps
pps
pps
pps
pps
pps
bps
bps
bps
409
Medium-high
:
0
High
:
0
Queued:
Packets
:
675023604
Bytes
:
157225809565
Transmitted:
Packets
:
675023604
Bytes
:
157225809565
0
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
RED-dropped bytes
:
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
410
0 bps
0 bps
804 pps
1499528 bps
804
1499528
0
0
0
0
0
0
0
0
0
0
0
pps
bps
pps
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps

user@branch> show interfaces queue gr-0/0/0
Burst size: 0
Queued:
Packets
:
226681173
Bytes
:
81436733911
Transmitted:
Packets
:
226678316
Bytes
:
81435285721
1541
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
RED-dropped bytes
:
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
Queued:
Packets
:
0
Bytes
:
0
Transmitted:
Packets
:
0
Bytes
:
0
0
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
RED-dropped bytes
:
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
Queued:
Packets
:
67131410
Bytes
:
34639807560
Transmitted:
Packets
:
67131081
Bytes
:
34639637796
0
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
RED-dropped bytes
:
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
2711 pps
7760328 bps
2711 pps
7760328 bps
0 pps
0 pps
0 pps
0 pps
0 pps
0 pps
0 bps
0 bps
0 bps
0 bps
0 bps
0 pps
0 bps
0 pps
bps
pps
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
0
0
0
0
0
0
0
0
0
0
0
0
803 pps
3316000 bps
803 pps
3316000 bps
0 pps
0 pps
0 pps
0 pps
0 pps
0 pps
0 bps
0 bps
0 bps
0 bps
0 bps
411

Queued:
Packets
:
Bytes
:
Transmitted:
Packets
:
Bytes
:
Low
:
Medium-low
:
Medium-high
:
High
:
RED-dropped bytes
:
Low
:
Medium-low
:
Medium-high
:
High
:
Queued:
Packets
:
Bytes
:
Transmitted:
Packets
:
Bytes
:
Low
:
Medium-low
:
Medium-high
:
High
:
RED-dropped bytes
:
Low
:
Medium-low
:
Medium-high
:
High
:
Queued:
Packets
:
Bytes
:
Transmitted:
Packets
:
Bytes
:
Low
:
Medium-low
:
Medium-high
:
High
:
RED-dropped bytes
:
Low
:
Medium-low
:
Medium-high
:
High
:
Queued:
Packets
:
Bytes
:
Transmitted:
Packets
:
Bytes
:
412
Critical_Data
67557032
26081332286
805 pps
2494672 bps
67556848
26081261824
23
0
0
0
0
0
0
0
0
0
0
805 pps
2494672 bps
0 pps
0 pps
0 pps
0 pps
0 pps
0 pps
0 bps
0 bps
0 bps
0 bps
0 bps
41954776
21648664416
502 pps
2073272 bps
41954716
21648633456
0
0
0
0
0
0
0
0
0
0
0
502 pps
2073272 bps
0 pps
0 pps
0 pps
0 pps
0 pps
0 pps
0 bps
0 bps
0 bps
0 bps
0 bps
117446026
15502875432
1405 pps
1484616 bps
Video
Voice
117445988
15502870416
0
0
0
0
0
0
0
0
0
0
0
Network_Control
1405 pps
1484616 bps
0 pps
0 pps
0 pps
0 pps
0 pps
0 pps
0 bps
0 bps
0 bps
0 bps
0 bps
41970048
10912205750
502 pps
1044672 bps
41969692
10912113190
502 pps
1044672 bps
RED-dropped packets
Low
Medium-low
Medium-high
High
RED-dropped bytes
Low
Medium-low
Medium-high
High
:
:
:
:
:
:
:
:
:
:
:
323
0
0
0
0
0
0
0
0
0
0

Burst size: 0
Queued:
Packets
:
3550579
Bytes
:
1334009096
Transmitted:
Packets
:
3420962
Bytes
:
1265283113
121212
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
RED-dropped bytes
:
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
Queued:
Packets
:
0
Bytes
:
0
Transmitted:
Packets
:
0
Bytes
:
0
0
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
RED-dropped bytes
:
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
Queued:
Packets
:
1049255
Bytes
:
541415580
Transmitted:
Packets
:
1047943
Bytes
:
540738588
14
0
0
0
0
0
0
0
0
0
0
0
0
pps
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
0 pps
0 bps
0 pps
bps
pps
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
0
0
0
0
0
0
0
0
0
0
0
0
0 pps
0 bps
0 pps
bps
pps
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
0
0
0
0
0
0
0
0
0
0
0
0
0 pps
0 bps
0 pps
0 bps
0 pps
0 pps
413
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
RED-dropped bytes
:
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
Queued:
Packets
:
1482284
Bytes
:
440888442
Transmitted:
Packets
:
1482063
Bytes
:
440802694
0
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
RED-dropped bytes
:
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
Queued:
Packets
:
655781
Bytes
:
338382996
Transmitted:
Packets
:
655708
Bytes
:
338345328
0
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
RED-dropped bytes
:
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
Queued:
Packets
:
1836197
Bytes
:
242378004
Transmitted:
Packets
:
1836152
Bytes
:
242372064
0
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
RED-dropped bytes
:
0
Low
:
0
Medium-low
:
0
414
0
0
0
0
0
0
0
0
0
pps
pps
pps
pps
bps
bps
bps
bps
bps
2 pps
1520 bps
2 pps
bps
pps
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
1520
0
0
0
0
0
0
0
0
0
0
0
0 pps
0 bps
0 pps
bps
pps
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
0
0
0
0
0
0
0
0
0
0
0
0
0 pps
0 bps
0 pps
bps
pps
pps
pps
pps
pps
pps
bps
bps
bps
0
0
0
0
0
0
0
0
0
0
Medium-high
:
0
High
:
0
Queued:
Packets
:
655904
Bytes
:
170514684
Transmitted:
Packets
:
655793
Bytes
:
170485824
27
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
RED-dropped bytes
:
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
0 bps
0 bps
0 pps
0 bps
0 pps
bps
pps
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
0
0
0
0
0
0
0
0
0
0
0
0

Step-by-Step
Procedure
1.

[edit]
edit protocols pim
2.
Add the GRE tunnels, the physical interface to the Layer 3 VPN, and the branch LAN
interfaces to the multicast configuration at the hub.
[edit]
edit protocols pim
415
Results
Verify that multicast is running over the Layer 3 VPN and the branch LAN. Multicast is
not currently running on the backup Internet transport.
1.
Verify that IGMP groups are formed on the branch LAN.

user@branch>show igmp group
Group: 224.0.0.5
Source: 0.0.0.0
Timeout:
209 Type: Dynamic
Group: 235.2.1.1
Source: 0.0.0.0
Timeout:
206 Type: Dynamic
. . .
Group: 224.0.0.5
Source: 0.0.0.0
Timeout:
182 Type: Dynamic
Group: 224.0.0.5
Source: 0.0.0.0
Timeout:
146 Type: Dynamic
Group: 224.0.0.2
Source: 0.0.0.0
Timeout:
0 Type: Dynamic
Group: 224.0.0.5
Source: 0.0.0.0
Timeout:
0 Type: Dynamic
. . .
2. Verify that multicast is running over the Layer 3 VPN transport (ge-0/0/2).
user@branch> show pim join
Group: 235.2.1.1
Source: *
RP: 172.31.255.15
Upstream interface: ge-0/0/2.0
Group: 235.2.1.1
Source: 172.31.252.10
Flags: sparse,spt
Group: 235.2.1.2
Source: *
RP: 172.31.255.15
416
. . .
Group: 235.2.1.8
Source: *
RP: 172.31.255.15
Group: 235.2.1.8
Source: 172.31.252.10
Flags: sparse,spt
3. Verify multicast on the branch LAN interfaces and the interface to the Layer 3 VPN
transport.
Interface
IP V Mode
ge-0/0/2.0
4 2
ge-0/0/2.0
6 2
fe80::5e5e:abff:fe4f:cff5
Option
HPLGT
HPLGT

1w2d19h 172.16.2.1
1w2d19h
4. Verify that groups are established with upstream interface to the Layer 3 VPN service
provider (ge-0/0/2) and the downstream interfaces to the branch LAN (ge-0/0/0).
Group: 235.2.1.1
Source: 172.31.252.10/32
ge-0/0/0.41
Route state: Active
Uptime: 3d 04:29:18
. . .
Group: 235.2.1.8
Source: 172.31.252.10/32
ge-0/0/0.41
417

Route state: Active
Uptime: 3d 04:29:18
5. Verify the multicast reverse-path-forwarding (RPF) calculations for the static
rendezvous point.
0.0.0.0/0
Protocol: BGP
Interface: ge-0/0/2.0
Neighbor: 172.16.2.1
user@branch> show pim rps extensive
address-family INET
RP: 172.31.255.15
Mode: Sparse
Holdtime: 0
Device Index: 149
Subunit: 32769
Interface: pe-1/2/0.32769
Group Ranges:
224.0.0.0/4
Active groups using RP:
235.2.1.1
235.2.1.2
235.2.1.3
235.2.1.4
235.2.1.5
235.2.1.6
235.2.1.7
235.2.1.8
total 8 groups active
418
Verification
Purpose
Action
Verify that traffic is travelling end-to-end on the Layer 3 VPN WAN transport to
Aggregation Hub 1.
1.
Run the following show command on the interface to ISP A.

Description: --- To Public ISP link (jbeer.PE1 ge-7/0/2) --Link-level type: Ethernet, MTU: 1514, Speed: 1000mbps, BPDU Error: None,
MAC-REWRITE Error: None, Loopback: Disabled,
Device flags
: Present Running
Link flags
: None
CoS queues
Hold-times
Current address: 5c:5e:ab:fe:68:01, Hardware address: 5c:5e:ab:fe:68:01
Last flapped
: 2013-07-20 10:26:07 PDT (1w0d 23:24 ago)
Traffic statistics:
Input bytes :
517330454
0 bps
Output bytes :
615278424
0 bps
Input packets:
1512987
0 pps
Output packets:
1737338
0 pps
IPv6 total statistics:
Input bytes :
0
Output bytes :
0
Input packets:
0
Output packets:
0
Ingress traffic statistics at Packet Forwarding Engine:
Input bytes :
517330454
0 bps
Input packets:
1512987
0 pps
Drop
bytes :
0
0 bps
Drop
packets:
0
0 pps
Input errors:
incompletes: 0, L2 channel errors: 0,
L2 mismatch timeouts: 0, FIFO errors: 0, Resource errors: 0
Output errors:
0, FIFO errors: 0, HS link CRC errors: 0,
MTU errors: 0, Resource errors: 0
Queue counters:
Dropped packets
0 Best_Effort
1396372
1396372
1 Scavenger
2 Bulk_Data
0
0
0
419
3 Critical_Dat
116615
116615
4 Video
5 Voice
0
0
0
6 Network_Cont
0
0
0
Queue counters:
0 Best_Effort
667657
667657
1 Scavenger
2 Bulk_Data
144108
144108
3 Critical_Dat
112084
112084
4 Video
100073
100073
5 Voice
156115
156115
Dropped packets
0
0
0
0
0
0
6 Network_Cont
557301
557301
0
Queue number:
0
Best_Effort
1
Scavenger
2
Bulk_Data
3
Critical_Data
4
Video
5
Voice
6
Network_Control
MAC statistics:
Receive
Transmit
Total octets
517330454
615278424
Total packets
1512987
1737338
Unicast packets
1512676
1737024
Broadcast packets
311
314
Multicast packets
0
0
CRC/Align errors
0
0
FIFO errors
0
0
MAC control frames
0
0
MAC pause frames
0
0
Oversized frames
0
Jabber frames
0
Fragment frames
0
VLAN tagged frames
0
Code violations
0
Filter statistics:
Input packet count
1512987
0
Input DA rejects
0
Input SA rejects
0
Output packet count
1737338
0
0
420
Link partner:
fault: OK
Local resolution:
CoS information:
Direction : Output
CoS transmit queue
Bandwidth
Buffer Priority
Limit
%
bps
%
usec
0 Best_Effort
95
950000000
95
0
low
none
3 Critical_Data
5
50000000
5
0
low
none
Direction : Input
CoS transmit queue
Bandwidth
Buffer Priority
Limit
%
bps
%
usec
0 Best_Effort
95
950000000
95
0
low
none
3 Critical_Data
5
50000000
5
0
low
none
Traffic statistics:
Input bytes :
516936694
Output bytes :
614722212
Input packets:
1512987
Output packets:
1737338
Local statistics:
Input bytes :
5205658
Output bytes :
14416068
Input packets:
98440
Output packets:
98334
Transit statistics:
Input bytes :
511731036
0 bps
Output bytes :
600306144
0 bps
Input packets:
1414547
0 pps
Output packets:
1639004
0 pps
Destination: 2.2.0.0/30, Local: 2.2.0.2, Broadcast: 2.2.0.3, Generation:
165
Flags: Is-Primary
421
Purpose
Action
Verify reachability and traffic paths to the loopback interface of the data center router,
the loopback interface of a router in a different branch, and an IP address in the service
1.
Display the default IPv4 routing table to verify reachability throughout the network.
0.0.0.0/0
10.2.1.0/24
10.2.2.0/24
10.155.8.1/32
10.155.210.151/32
10.157.92.176/32
10.204.138.55/32
10.209.0.0/16
10.212.0.0/16
10.216.32.0/20
10.216.36.244/32
14.4.4.0/24
14.4.4.1/32
172.16.2.0/30
172.16.2.2/32
172.16.2.4/30
172.16.2.6/32
172.16.2.8/30
172.16.2.9/32
172.16.2.12/30
172.16.2.13/32
422
*[BGP/170] 1w0d 03:28:24, localpref 200

> to 172.16.2.1 via ge-0/0/2.0
*[OSPF/150] 4d 06:29:47, metric 11, tag 0
> to 172.16.2.10 via ge-0/0/0.41
*[OSPF/150] 4d 06:29:47, metric 11, tag 0
> to 172.16.2.10 via ge-0/0/0.41
> to 172.16.2.18 via ge-0/0/0.61
*[Static/5] 1w0d 23:27:33
> to 10.216.47.254 via fxp0.0
*[Static/5] 1w0d 23:27:33
> to 10.216.47.254 via fxp0.0
*[Static/5] 1w0d 23:27:33
> to 10.216.47.254 via fxp0.0
*[Static/5] 1w0d 23:27:33
> to 10.216.47.254 via fxp0.0
*[Static/5] 1w0d 23:27:33
> to 10.216.47.254 via fxp0.0
*[Static/5] 1w0d 23:27:33
> to 10.216.47.254 via fxp0.0
*[Direct/0] 1w0d 23:27:33
> via fxp0.0
*[Local/0] 1w0d 23:27:33
Local via fxp0.0
*[Direct/0] 4d 23:16:12
> via ge-0/0/3.0
*[Local/0] 1w0d 23:26:41
*[Direct/0] 1w0d 23:25:44
> via ge-0/0/2.0
*[Local/0] 1w0d 23:26:42
*[Direct/0] 4d 22:38:15
> via gr-0/2/0.2
*[Local/0] 4d 22:38:16
*[Direct/0] 1w0d 23:25:44
> via ge-0/0/0.41
*[Local/0] 1w0d 23:26:42
*[Direct/0] 1w0d 23:25:44
> via ge-0/0/0.51
*[Local/0] 1w0d 23:26:42
172.16.2.16/30
172.16.2.17/32
172.16.2.254/32
172.17.0.0/16
224.0.0.2/32
224.0.0.5/32
224.0.0.13/32
224.0.0.22/32
*[Direct/0] 1w0d 23:25:44

> via ge-0/0/0.61
*[Local/0] 1w0d 23:26:42
*[Direct/0] 1w0d 23:27:33
> via lo0.1
*[Static/5] 1w0d 23:27:33
> to 10.216.47.254 via fxp0.0
*[PIM/0] 1w0d 23:27:35
MultiRecv
*[OSPF/10] 1w0d 23:27:35, metric 1
MultiRecv
*[PIM/0] 1w0d 23:27:35
MultiRecv
*[IGMP/0] 1w0d 23:27:35
MultiRecv
423

PING 172.31.255.8 (172.31.255.8): 56 data bytes
!!!!!
3. Verify path to the loopback interface of the data center router.
user@branch>traceroute 172.31.255.8
1 172.16.2.1 (172.16.2.1) 1.064 ms 0.816 ms 1.019 ms #
2 172.31.254.33 (172.31.254.33) 0.820 ms 0.964 ms 1.008 ms #
3 172.31.254.34 (172.31.254.34) 0.737 ms 8.045 ms 0.773 ms #
4 172.31.255.8 (172.31.255.8) 1.207 ms 0.871 ms 1.040 ms #
user@branch>ping 172.16.1.254 rapid
PING 172.16.1.254 (172.16.1.254): 56 data bytes
!!!!!
5. Verify path to branch router using tracceroute.
traceroute to 172.16.1.254 (172.16.1.254), 30 hops max, 40 byte
1 172.16.2.1 (172.16.2.1) 1.053 ms 0.771 ms 0.998 ms #
2 172.31.254.33 (172.31.254.33) 0.867 ms 0.943 ms 1.004 ms
3 172.31.254.34 (172.31.254.34) 0.826 ms 0.818 ms 1.026 ms
4 172.31.254.14 (172.31.254.14) 0.862 ms 1.119 ms 1.050 ms
5 172.16.1.254 (172.16.1.254) 3.272 ms 3.888 ms 3.492 ms #
packets
#
#
#
6. Verify connectivity from the branch to a publicly routable IP address in the service
provider network.
user@branch>ping 100.65.4.2 rapid
PING 100.65.4.2 (100.65.4.2): 56 data bytes
!!!!!
7. Verify path from branch to publicly routable host using traceroute.
user@branch>traceroute 100.65.4.2
1 172.16.2.1 (172.16.2.1) 1.361 ms 0.790 ms 1.019 ms #
2 172.31.254.33 (172.31.254.33) 0.829 ms 0.835 ms 0.922 ms #
3 172.31.254.34 (172.31.254.34) 1.150 ms 0.744 ms 0.721 ms #
4 172.31.254.9 (172.31.254.9) 0.708 ms 0.713 ms 0.740 ms #
5 * * *
6 * * *
## This is expected - trace route is blocked by the stateful firewall on the
Internet edge router ##
424

Purpose
Action
Verify that a failure of the branch router layer 3 VPN WAN transport to Aggregation Hub
1 causes all traffic to be rerouted over the GRE tunnel secondary WAN transport to
Aggregation Hub 2 with minimal traffic loss.
1.
Log in to the branch router as the root user, and enter the following command to take
down the physical WAN transport.
root@branch% ifconfig ge-0/0/2 down
2. Verify that the route to the remote GRE endpoint is the active default route.
0.0.0.0/0
*[BGP/170] 05:07:08, MED 0, localpref 100

> to 172.16.2.5 via gr-0/2/0.2
. . .
3. Verify BGP routes. The routes to the Layer 3 VPN ISP are idle (172.16.2.1,2001:DB8:2:1::1).
The routes to the Internet service provider (2.2.0.1) and to the remote end of the GRE
tunnel (172.16.2.5, 2001:DB8:2:4::1) are established.
Table
History Damp State
Pending
inet.0
1
1
0
0
0
0
inet.2
0
0
0
0
0
0
inet6.0
1
1
0
0
0
0
Peer
AS
InPkt
OutPkt
OutQ
Flaps Last Up/Dwn
2.2.0.1
69
31801
31639
0
1 3d 19:55:02
Establ
VPN.inet.0: 1/1/1/0
172.16.2.1
555
4209
4254
0
4
1:12
Idle
172.16.2.5
65530
29113
31548
0
38
5:06:59
Establ
inet.0: 1/1/1/0
2001:DB8:2:1::1
555
4203
4251
0
4
1:12
Idle
2001:DB8:2:4::1
65530
28969
31554
0
24
5:07:54
Establ
inet6.0: 1/1/1/0
4. Verify that the physical link to the Layer 3 VPN service provider is down.
Physical interface: ge-0/0/2, Administratively down, Physical link is Down
Description: --- To MPLS_VPN_PROVIDER1 link (jbeer ge-7/0/3) ---
425
Device flags
: Present Running Down
Interface flags: Hardware-Down Down SNMP-Traps Internal: 0x4000
Link flags
: None
CoS queues
Hold-times
Current address: 5c:5e:ab:fe:68:02, Hardware address: 5c:5e:ab:fe:68:02
Last flapped
: 2013-06-17 12:00:09 PDT (00:25:04 ago)
Statistics last cleared: 2013-06-16 04:14:16 PDT (1d 08:10 ago)
Traffic statistics:
Input bytes :
161572949616
0 bps
Output bytes :
153096884999
0 bps
Input packets:
416892314
0 pps
Output packets:
433906680
0 pps
IPv6 total statistics:
Input bytes :
2417952315
Output bytes :
2418038487
Input packets:
9605437
Output packets:
9601956
Ingress traffic statistics at Packet Forwarding Engine:
Input bytes :
161572862484
0 bps
Input packets:
416892072
0 pps
Drop
bytes :
0
0 bps
Drop
packets:
0
0 pps
Input errors:
0,
Resource errors: 0
Output errors:
Queue counters:
Dropped packets
0 Best_Effort
392454194
392454194
1 Scavenger
2 Bulk_Data
0
0
0
426
5. Verify traffic counters on the GRE interface after failure.

user@branch> show interfaces gr-0/2/0 extensive
Hold-times
Device flags
: Present Running
Statistics last cleared: 2013-06-16 04:14:16 PDT (1d 08:11 ago)
Traffic statistics:
Input bytes :
7465440708
39413584 bps
Output bytes :
7606581056
37027408 bps
Input packets:
22194690
14503 pps
Output packets:
24788919
15002 pps
Input bytes :
0
Output bytes :
0
Input packets:
0
Output packets:
0
Logical interface gr-0/2/0.2 (Index 82) (SNMP ifIndex 549) (Generation 147)
Traffic statistics:
Input bytes :
7465440708
Output bytes :
7609388099
Input packets:
22194690
Output packets:
24817299
Input bytes :
0
Output bytes :
0
Input packets:
0
Output packets:
0
Local statistics:
Input bytes :
1523808
Output bytes :
2807043
Input packets:
20860
Output packets:
28380
Transit statistics:
Input bytes :
7463916900
39413584 bps
Output bytes :
7606581056
37027408 bps
Input packets:
22173830
14503 pps
Output packets:
24788919
15002 pps
Input bytes :
0
Output bytes :
0
Input packets:
0
Output packets:
0
Input Filters: mcast1
Generation: 175
427
Destination: fe80::/64, Local: fe80::2a0:a504:73:96be

Generation: 177
Generation: 179
428
6. Verify queue statistics on the GRE interface after failure.

user@branch> show interfaces queue egress gr-0/2/0.2
Queued:
Packets
: 9214364874117088975
7800 pps
Bytes
: 9214364877803597515
19433728 bps
Transmitted:
Packets
: 9214364874117088975
7800 pps
Bytes
: 9214364877803597515
19433728 bps
0
9214364874105159688
RED-dropped bytes
:
9214364874105159688
Queued:
Packets
:
9214364874105159688
Bytes
:
5188692096283836424
Transmitted:
Packets
:
9214364874105159688
Bytes
:
9214364874105159688
0
9214364874105159688
RED-dropped bytes
:
9214364874105159688
Queued:
Packets
: 9214364874107912601
1800 pps
Bytes
: 9214364875528415709
7444800 bps
Transmitted:
Packets
: 9214364874107912601
1800 pps
Bytes
: 9214364875528415709
7444800 bps
0
9214364874105159688
RED-dropped bytes
:
9214364874105159688
Queued:
Packets
: 9214364874107300842
1400 pps
Bytes
: 9214364874938068594
4356800 bps
Transmitted:
Packets
: 9214364874107300842
1400 pps
Bytes
: 9214364874938068594
4356800 bps
0
9214364874105159688
RED-dropped bytes
:
9214364874105159688
Queued:
Packets
: 9214364874107071432
1250 pps
Bytes
: 9214364875093531853
5170000 bps
Transmitted:
Packets
: 9214364874107071432
1250 pps
Bytes
: 9214364875093531853
5170000 bps
0
9214364874105159688
RED-dropped bytes
:
9214364874105159688
Queued:
Packets
: 9214364874108142009
1950 pps
Bytes
: 9214364874501808514
2074800 bps
0 pps
0 pps
0 bps
0 pps
0 bps
0
0
0
0
0
pps
bps
pps
pps
bps
0 pps
0 pps
0 bps
0 pps
0 pps
0 bps
0 pps
0 pps
0 bps
429
Transmitted:
Packets
: 9214364874108142009
1950 pps
Bytes
: 9214364874501808514
2074800 bps
0
9214364874105159688
RED-dropped bytes
:
9214364874105159688
Queued:
Packets
: 9214364874106428359
802 pps
Bytes
: 9214364874428064791
1671664 bps
Transmitted:
Packets
: 9214364874106428359
802 pps
Bytes
: 9214364874428064791
1671664 bps
0
9214364874105159688
RED-dropped bytes
:
5188690172138487816
0 pps
0 pps
0 bps
0 pps
0 pps
0 bps
7. Check the path taken by traffic to the data center after Layer 3 VPN primary link failure.
user@branch> ping 172.31.255.8 source 172.16.2.254 rapid
PING 172.31.255.8 (172.31.255.8): 56 data bytes
!!!!!
user@branch> traceroute 172.31.255.8 source 172.16.2.254
byte packets
1 172.16.2.5 (172.16.2.5) 1.160 ms 1.340 ms 1.021 ms # GRE endpoint at hub
2
2 172.31.254.21 (172.31.254.21) 2.639 ms 1.019 ms 0.948 ms # WAN
Aggregation Hub 2
3 172.31.255.8 (172.31.255.8) 1.198 ms 1.226 ms 1.174 ms # Data Center
8. Check the branch-to-branch path taken by traffic after Layer 3 VPN primary link failure.
PING 172.16.1.254 (172.16.1.254): 56 data bytes
!!!!!
byte packets
2
2 172.16.1.254 (172.16.1.254) 4.000 ms 3.654 ms 3.411 ms # # Branch loopback
430
provider network after the Layer 3 VPN primary link failure.

PING 100.65.4.2 (100.65.4.2): 56 data bytes
!!!!!
traceroute to 100.65.4.2 (100.65.4.2 ) from 172.16.2.254, 30 hops max, 40
byte packets
2 2 172.31.254.21 (172.31.254.21) 0.995 ms 1.132 ms 1.448 ms # WANaggr
hub 2
3 172.31.254.41 (172.31.254.41) 1.250 ms 1.146 ms 0.979 ms # WANaggr hub
1 4 172.31.254.9 (172.31.254.9) 1.070 ms 2.671 ms 1.254 ms # Int Edge 1
^C
431

a. Verify that the connection to the rendezvous point is over the interface to the Layer
3 VPN service provider.

0.0.0.0/0
Protocol: BGP
b. Verify that groups are established with upstream interfaces to the Layer 3 VPN
service provider (ge-0/0/2) and downstream interfaces to the branch LAN

(ge-0/0/0).
Group: 235.2.1.1
Source: 172.31.252.10/32
ge-0/0/0.41
Route state: Active
Uptime: 6d 02:01:36
Group: 235.2.1.2
Source: 172.31.252.10/32
ge-0/0/0.41
Route state: Active
Uptime: 6d 02:01:36
Group: 235.2.1.3
Source: 172.31.252.10/32
ge-0/0/0.41
Route state: Active
432

Uptime: 6d 02:01:36
Group: 235.2.1.4
Source: 172.31.252.10/32
ge-0/0/0.41
Route state: Active
Uptime: 6d 02:01:36
Group: 235.2.1.5
Source: 172.31.252.10/32
ge-0/0/0.41
Route state: Active
Uptime: 6d 02:01:36
Group: 235.2.1.6
Source: 172.31.252.10/32
ge-0/0/0.41
Route state: Active
Uptime: 6d 02:01:36
Group: 235.2.1.7
Source: 172.31.252.10/32
ge-0/0/0.41
Route state: Active
433

Uptime: 6d 02:01:36
. . .
Group: 235.2.1.8
Source: 172.31.252.10/32
ge-0/0/0.41
Route state: Active
Uptime: 6d 02:01:36
434
Verifying This Scenario from the WAN Aggregation Router at Aggregation Hub 1
Purpose
Action
Use this procedure to verify this scenario from the WAN aggregation router at Aggregation
Hub 1.
1.
Verify that the link to the Layer 3 VPN service provider is up.
user@wanagghub1> show interfaces ge-1/2/5 terse
Interface
Admin Link Proto
Local
Remote
ge-1/2/5
up
up
ge-1/2/5.0
up
up
inet
172.31.254.34/30
inet6
fe80::5e5e:abff:fe0e:4205/64
2001:DB8:254:1::2/64
multiservice
user@wanagghub1> ping 172.31.254.33 rapid
Interface
Admin Link Proto
ge-1/2/5
up
up
ge-1/2/5.0
up
up
inet
inet6
Local
Remote
172.31.254.34/30
fe80::5e5e:abff:fe0e:4205/64
2001:DB8:254:1::2/64
multiservice
2. Verify the BGP groups to the Layer 3 VPN service provider.

user@wanagghub1> show bgp summary group EBGP-AS_555
Table
History Damp State
Pending
inet.0
26386
26384
0
0
0
0
inet6.0
25393
25393
0
0
0
0
Peer
AS
InPkt
OutPkt
OutQ
Flaps Last Up/Dwn
172.31.254.33
555
855
759
0
0
6:13:55
383/384/384/0
0/0/0/0
user@wanagghub1> show bgp summary group EBGP-AS_555-V6
Table
History Damp State
Pending
inet.0
26386
26384
0
0
0
0
inet6.0
25393
25393
0
0
0
0
Peer
AS
InPkt
OutPkt
OutQ
Flaps Last Up/Dwn
2001:DB8:254:1::1
555
857
759
0
0
6:14:23
Establ
inet6.0: 392/392/392/0
3. Verify that routes are being received from and advertised to the Layer 3 VPN service
provider.
user@wanagghub1> show route advertising-protocol bgp 172.31.254.33
435
Prefix
* 0.0.0.0/0
Nexthop
Self
MED
0
Lclpref
AS path
I
user@wanagghub1> show route advertising-protocol bgp 2001:DB8:254:1::1

Prefix
* ::/0
436
Nexthop
Self
MED
Lclpref
AS path
I
CHAPTER 13
Connecting a Large Branch to

3 VPN
Connecting a Large Branch to Dual-Homed Aggregation Hubs over Layer 3 VPN
This scenario shows a large branch with dual routers that is dual-homed to Aggregation
Hub 1 and Aggregation Hub 2 over Layer 3 VPNs provided by a service provider
Requirements
This scenario uses the following hardware and software components:
Branch router 1MX80 3D Universal Edge Router with the following PICs:
4-port 10-Gigabit Ethernet PIC with XFP
10-port Gigabit Ethernet PIC with SFP
Branch router 2MX80 3D Universal Edge Router with the following PICs:
4-port 10-Gigabit Ethernet PIC with XFP
10-port Gigabit Ethernet PIC with SFP
Overview
This design is a large branch that connects to the aggregation hubs over a Layer 3 VPN
transport that is provided by a service provider.
High availability for this branch is as follows:
For device-level high availability at the branch there are dual routers in an
active/standby configuration. Branch router 1 is the primary router, and branch router
2 is the secondary router. We use Virtual Router Redundancy Protocol (VRRP) to
elect the primary and secondary router.
For carrier-level high availability the branch routers each use a separate Layer 3 VPN
service provider.
437
The branch is dual-homed to the aggregation hubs:

Branch router 1 connects to Aggregation Hub 1 over Layer 3 VPN provided by ISP
A.
Branch router 2 connects to Aggregation Hub 2 over Layer 3 VPN provided by ISP
B.
For link-level high availability, the service providers are responsible for providing high
availability as agreed upon in the service-level agreement with the service provider.
The following routing protocols are used in this scenario:
438
EBGP is used for peering with the Layer 3 VPN service provider.
IBGP is used for peering between the two branch routers. It uses the loopback
addresses of the branch routers to form IBGP sessions between the routers, and it
learns the loopback addresses from OSPF.
OSPF is used on the local branch VLANS, and it is used to provide reachability
between the two branch routers.
CoS is applied on the branch VLANs and on the link to the Layer 3 VPN service provider.
.
Chapter 13: Connecting a Large Branch to Dual-Homed Aggregation Hubs over Layer 3 VPN
Topology
Figure 78: Test Lab Topology for Large Remote Site Using Redundant
CEs to Connect to Redundant Layer 3 VPN Carriers
439
Figure 79: Routing Configuration for Large Remote Site Using Redundant
CEs to Connect to Redundant Layer 3 VPN Providers
440
Configuring Branch Router 1 on page 443
Configuring Branch Router 2 on page 487

To configure the router at Aggregation Hub 1, perform these tasks:
1 on page 441
Hub 1 on page 442

Hub 1
Step-by-Step
Procedure

[edit]
set vlan-tagging
Step-by-Step
Procedure
Configure EBGP groups for peering between the WAN aggregation router at the hub and
ISP A.
1.

[edit]
set type external
set export DENY_ALL
441

2.

branch.
[edit]
set type external
set peer-as 555

Aggregation Hub 1
Step-by-Step
Procedure
1.

[edit]
2.
base configuration.
[edit]

Step-by-Step
Procedure
Configure multicast on the WAN transport.

1.
442
[edit]
set mode sparse
set version 2
Configuring Branch Router 1
Configuring Routing Engine Protection on Branch Router 1 on page 443
Configuring the Router ID on Branch Router 1 on page 447
Configuring the WAN Transport on Branch Router 1 on page 448
Configuring EBGP Peering on the WAN Transport on Branch Router 1 on page 450
Configuring the LAN Transport on Branch Router 1 on page 453
Configuring OSPF Routing for the LAN Transport on Branch Router 1 on page 457
Configuring the LAN Transport to Branch Router 2 on Branch Router 1 on page 458
Configuring OSPF Routing to Branch Router 2 on Branch Router 1 on page 462
Configuring IBGP Peering to Branch Router 2 on Branch Router 1 on page 464
Configuring VRRP for High Availability of Dual Routers on Branch Router 1 on page 466
Configuring Multicast on Branch Router 1 on page 468
Configuring CoS on Branch Router 1 on page 473
Configuring Routing Engine Protection on Branch Router 1

Step-by-Step
Procedure
1.
[edit]
edit policy-options
2.

[edit]
set then discard
3.
interface specific.
[edit]
443
b. Create a term for BGP traffic.
[edit]
c. Create a term that accepts traffic from trusted PIM neighbors.
[edit]
d. Create a term that accepts OSPF traffic from trusted OSPF neighbors.
[edit]
e. Create a term that accepts BFD traffic from trusted neighbors.
[edit]
f.

[edit]
444
g. Create a term for ICMP traffic, which includes IPv4 error messages.
[edit]
h. Create a term for VRRP traffic.
[edit]
set term vrrp from source-prefix-list trusted-networks
set term vrrp from protocol vrrp
set term vrrp then policer limit-150k
set term vrrp then count vrrp
set term vrrp then accept
i.
[edit]
j.
management systems.
[edit]
management systems.
[edit]
445
l.

[edit]
[edit]
[edit]
[edit]
[edit]
4.
Apply the filter to loopback interfaces at the branch.

[edit]
446
5.

[edit]
commit
Results

user@branch1>show firewall filter RE-PROTECTION-lo0.0-i
Filter: RE-PROTECTION-lo0.0-i
Counters:
Name
Bytes
accept-bfd-lo0.0-i
0
access-in-lo0.0-i
4391098
bgp-in-lo0.0-i
673966
frag-attack-lo0.0-i
0
icmp-in-lo0.0-i
29400
igmp-lo0.0-i
555976
16877713
loopback-in-lo0.0-i
0
ospf-in-lo0.0-i
6699600
pim-lo0.0-i
846396
radius-lo0.0-i
0
0
snmp-in-lo0.0-i
160771
tacacs-lo0.0-i
0
udp-in-lo0.0-i
89850760
vrrp-lo0.0-i
19076680
Policers:
Name
Bytes
limit-150k-bgp-in-lo0.0-i
0
limit-150k-icmp-in-lo0.0-i
0
limit-150k-igmp-lo0.0-i
0
limit-150k-ospf-in-lo0.0-i
0
limit-150k-pim-lo0.0-i
0
limit-150k-snmp-in-lo0.0-i
0
limit-150k-udp-services-lo0.0-i
0
limit-150k-vrrp-lo0.0-i
0
Packets
0
81704
12282
0
350
17214
82808
0
84070
15674
0
0
1896
0
547872
476917
Packets
0
0
0
0
0
0
0
0
Configuring the Router ID on Branch Router 1

Step-by-Step
Procedure

[edit]
447
Configuring the WAN Transport on Branch Router 1

Step-by-Step
Procedure
1.
Create the interface to Layer 3 VPN Service Provider A.

egress interfaces. Both the transit and total statistical information are computed
and displayed for each logical interface with the show interfaces command under
the Ingress account overhead and Egress account overhead fields.
[edit]

2.

[edit]
commit
Results
Verify that the physical interface is up:

user@branch1> show interfaces ge-1/2/1 terse
Interface
Admin Link Proto
ge-1/2/1
up
up
ge-1/2/1.0
up
up
inet
inet6
Local
Remote
172.16.4.2/30
fe80::5e5e:abff:fe0d:d901/64
2001:DB8:4:1::2/64
multiservice
Verify that the WAN transport is running:

Description: --- To MPLS_VPN_PROVIDER1 link (jbeer ge-2/3/3) --Link-level type: Ethernet, MTU: 1514, Speed: 1000mbps, BPDU Error: None,
Device flags
: Present Running
448

Link flags
: None
CoS queues
Current address: 5c:5e:ab:0d:d9:01, Hardware address: 5c:5e:ab:0d:d9:01
Last flapped
: 2013-07-04 05:53:58 PDT (2w0d 03:13 ago)
Input rate
: 105262856 bps (37152 pps)
Output rate
: 128275720 bps (45403 pps)
18 bytes
:
18 bytes
Flags: Is-Primary
Destination: fe80::/64, Local: fe80::5e5e:abff:fe0d:d901
Flags: Is-Primary
449
Configuring EBGP Peering on the WAN Transport on Branch Router 1

Step-by-Step
Procedure
Configure EBGP peering for the WAN transport.

1.

[edit]
2.
aggregation hub.
[edit]
3.
aggregation hub.
[edit]
set term branch from family inet6
4.
Configure a policy that sets the local preference to 200 for IPv4 routes learned from
BGP.
[edit]
5.
Configure a policy that sets the local preference to 200 for default static IPv6 routes
learned from BGP.
[edit]
450

6.
Create an IPv4 EBGP group between the branch router and the Layer 3 VPN service
provider.
The SET_LOCAL_PREF import policy sets the local preference value for routes over
the Layer 3 VPN to 200. Routes from branch router 2 use the default local route
preference value of 100, which gives routes on Branch router 1 a higher preference
over Branch router 2.
to the hub.
[edit]
edit protocols bgp group EBGP_AS_555
set type external
set peer-as 555
set neighbor 172.16.4.1 family inet unicast
set neighbor 172.16.4.1 authentication-key "$9$l.dv87wYojHm-VHmfT/9evW"
7.
provider.
The SET_LOCAL_PREF6 import policy sets the local preference value for routes
over the Layer 3 VPN to 200. Routes to Branch router 2 use the default local route
The BRANCH-PREFIX6 export policy controls default route advertisement to the
[edit]
edit protocols bgp group EBGP_AS_555-V6
set type external
set import SET_LOCAL_PREF-V6
set peer-as 555
set neighbor 2001:DB8:4:1::1 authentication-key "$9$WmrXNb4aU.PQs2PQFnpu8X7"
8.

[edit]
commit
451
Results
Verify EBGP peering with the Layer 3 VPN ISP.

user@branch1> show bgp summary
Table
History Damp State
Pending
inet.0
1
1
0
0
0
0
inet6.0
1
1
0
0
0
0
Peer
AS
InPkt
OutPkt
OutQ
Flaps Last Up/Dwn
172.16.4.1
555
63193
64001
0
18
2w6d2h
1/1/1/0
0/0/0/0
2001:DB8:4:1::1
555
63192
64062
0
15
2w6d2h
Establ
inet6.0: 1/1/1/0
452
Configuring the LAN Transport on Branch Router 1

Step-by-Step
Procedure
voice.
1.
Create the interface, and enable VLAN tagging.

[edit]
set vlan-tagging
2.

[edit]
set description "--- Data VLAN 43 ---"
set vlan-id 43

3.

[edit]
set vlan-id 53
4.

[edit]
453

set description "--- VOICE VLAN 63 ---"
set vlan-id 63
5.

[edit]
commit
454
Results
Verify that the interfaces to the branch LAN are running.

Interface
Admin Link Proto
ge-1/2/0
up
up
ge-1/2/0.43
up
up
inet
ge-1/2/0.53
up
up
ge-1/2/0.63
up
up
ge-1/2/0.32767
up
up
Local
Remote
172.16.4.9/29
172.16.4.11/29
inet6
fe80::200:5eff:fe00:20a/64
fe80::5e5e:ab00:2b0d:d900/64
2001:DB8:4:43::1/64
2001:DB8:4:43::3/64
multiservice
inet
172.16.4.17/29
172.16.4.19/29
inet6
fe80::200:5eff:fe00:214/64
fe80::5e5e:ab00:350d:d900/64
2001:DB8:4:53::1/64
2001:DB8:4:53::3/64
multiservice
inet
172.16.4.25/29
172.16.4.27/29
inet6
fe80::200:5eff:fe00:21e/64
fe80::5e5e:ab00:3f0d:d900/64
2001:DB8:4:63::1/64
2001:DB8:4:63::3/64
multiservice
multiservice

Description: --- To Emulated IXIA branches (eon ge-0/0/16) --Link-level type: Ethernet, MTU: 1518, Speed: 1000mbps, BPDU Error: None,
Device flags
: Present Running
CoS queues
Last flapped
: 2013-06-27 05:06:41 PDT (2w5d 04:23 ago)
Input rate
: 1968 bps (3 pps)
Output rate
: 9504 bps (15 pps)
Description: --- To IXIA emulated branch (Data VLAN 43) --Flags: SNMP-Traps 0x0 VLAN-Tag [ 0x8100.43 ] Encapsulation: ENET2
22 bytes
:
22 bytes
455

Destination: fe80::/64, Local: fe80::200:5eff:fe00:20a
Destination: fe80::/64, Local: fe80::5e5e:ab00:2b0d:d900
Description: --- To IXIA emulated branch (VIDEO VLAN 53) --Flags: SNMP-Traps 0x0 VLAN-Tag [ 0x8100.53 ] Encapsulation: ENET2
22 bytes
:
22 bytes
Destination: fe80::/64, Local: fe80::200:5eff:fe00:214
Destination: fe80::/64, Local: fe80::5e5e:ab00:350d:d900
Description: --- To IXIA emulated branch (VOICE VLAN 63) --Flags: SNMP-Traps 0x0 VLAN-Tag [ 0x8100.63 ] Encapsulation: ENET2
22 bytes
:
22 bytes
Destination: fe80::/64, Local: fe80::200:5eff:fe00:21e
Destination: fe80::/64, Local: fe80::5e5e:ab00:3f0d:d900
Input packets : 0
Output packets: 0
Flags: None
456
Configuring OSPF Routing for the LAN Transport on Branch Router 1

Step-by-Step
Procedure
1.
Create an IPv4 area for the branch, and add the branch LAN interfaces to the area.
[edit]
2.
[edit]
3.

[edit]
commit
Results

user@branch1> show ospf neighbor
Address
Interface
172.16.4.12
ge-1/2/0.43
172.16.4.10
ge-1/2/0.43
172.16.4.20
ge-1/2/0.53
172.16.4.18
ge-1/2/0.53
172.16.4.28
ge-1/2/0.63
172.16.4.26
ge-1/2/0.63
State
Full
Full
Full
Full
Full
Full
user@branch1> show ospf3 neighbor

ID
Interface
State
172.16.4.12
ge-1/2/0.43
Full
Neighbor-address fe80::200:1eff:fefe:71
172.16.4.254
ge-1/2/0.43
Full
Neighbor-address fe80::5e5e:ab00:2b0d:d918
172.16.4.20
ge-1/2/0.53
Full
172.16.4.254
ge-1/2/0.53
Full
Neighbor-address fe80::5e5e:ab00:350d:d918
172.16.4.28
ge-1/2/0.63
Full
172.16.4.254
ge-1/2/0.63
Full
Neighbor-address fe80::5e5e:ab00:3f0d:d918
ID
172.16.4.12
172.16.4.254
172.16.4.20
172.16.4.254
172.16.4.28
172.16.4.254
Pri
0
Dead
34
128
34
34
128
36
34
128
31
Pri
0
128
0
128
0
128
Dead
33
33
33
39
33
35
457
Configuring the LAN Transport to Branch Router 2 on Branch Router 1

Step-by-Step
Procedure
Configure the LAN interface to Branch router 2.

1.
Configure the interface for VLAN tagging.

[edit]
set vlan-tagging
2.
Configure the unit 1 logical interface, which is in OSPF area 0.

[edit]
set vlan-id 1

3.

[edit]
set vlan-id 2
4.
Configure the loopback interface to Branch router 2.

[edit]
458

5.

[edit]
commit
459
Results
After you configure Branch router 2, verify that the LAN interface to Branch router 2 is up.
Description: --- To intra branch router B2B link BRANCH-ROUTER2 ge-1/2/4) --Link-level type: Ethernet, MTU: 1518, Speed: 1000mbps, BPDU Error: None,
Device flags
: Present Running
CoS queues
Current address: 5c:5e:ab:0d:d9:1c, Hardware address: 5c:5e:ab:0d:d9:1c
Last flapped
: 2013-07-04 05:46:24 PDT (3w5d 04:57 ago)
Input rate
: 9569512 bps (3278 pps)
Output rate
: 416 bps (0 pps)
22 bytes
:
22 bytes
Destination: fe80::/64, Local: fe80::5e5e:ab00:10d:d91c
22 bytes
:
22 bytes
Destination: fe80::/64, Local: fe80::5e5e:ab00:20d:d91c
460
Input packets : 0
Output packets: 0
Flags: None
461
Configuring OSPF Routing to Branch Router 2 on Branch Router 1

Step-by-Step
Procedure
Configure OSPF routing between Branch router 1 and Branch router 2.

The OSPF backbone area contains the point-to-point interface and the loopback interface
between Branch router 1 and Branch router 2. It is used to provide reachability between
the two routers. IBGP uses the loopback interface to form IBGP sessions between the
two branch routers, and IBGP learns the loopback address from OSPF.
This configuration is required for failover scenarios where the link from Branch router 1
and the Layer 3 VPN service provider goes down. In this case, Branch router 2 receives
the routes that it needs from OSPF.
1.
Configure the backbone area for IPv4. Add the loopback interface and unit 1 of the
Ethernet interface that connect to Branch router 2 to the area.
[edit]
set interface lo0.0
2.
Add unit 2 of the Ethernet interface that connects to Branch router 2 to OSPF Area
1.
[edit]
3.
Configure the backbone area for IPv6. Add the loopback interface and unit 1 of the
Ethernet interface that connect to Branch router 2 to the area.
[edit]
set interface lo0.0
4.
Add unit 2 of the Ethernet interfaces that connects to Branch router 2 to OSPFv3
Area 1.
[edit]
5.

[edit]
commit
Results
After you configure Branch router 2, verify that OSPF is running between the branch
routers.
1.
Verify that OSPF and OSPFv3 are running between the branch routers.
Address
Interface
172.16.4.34
ge-1/3/4.1
. . .
172.16.4.38
ge-1/3/4.2
462
State
Full
ID
172.16.4.254
Pri
128
Dead
31
Full
172.16.4.254
128
35

ID
Interface
State
172.16.4.254
ge-1/3/4.1
Full
Pri
128
Dead
39
128
35
. . .
172.16.4.254
ge-1/3/4.2
Full
463
Configuring IBGP Peering to Branch Router 2 on Branch Router 1

Step-by-Step
Procedure
1.
Create a next-hop self policy for IPv4 traffic, which causes the loopback address
of the branch router to be advertised as the next-hop address.
[edit]
set then next-hop self
2.
of the branch router to be advertised as the next-hop address for BGP traffic.
[edit]
3.
Configure an IBGP group for IPv4 traffic. Add Branch router 2 as a neighbor and use
the address of lo0.0 as the local address.
[edit]
edit protocols bgp group To-BR2
set type internal
set export NHS
set neighbor 172.16.4.255 local-address 172.16.4.254
4.
Configure an IBGP group for IPv6 traffic. Add Branch router 2 as a neighbor, and use
[edit]
edit protocols bgp group To-BR2-V6
set type internal
set export NHS6
5.

[edit]
commit
Results
After you configure Branch router 2, verify BGP between the branch routers.
1.
Verify IBGP peering with Branch 2 (172.16.4.255 and 2001:DB8:4::255).

Table
History Damp State
Pending
inet.0
1
1
0
0
0
0
inet6.0
1
1
0
0
0
0
Peer
AS
InPkt
OutPkt
OutQ
Flaps Last Up/Dwn
464
172.16.4.1
555
82476
1/1/1/0
0/0/0/0
172.16.4.255
64514
83131
0/0/0/0
0/0/0/0
2001:DB8:4::255
64514
83131
Establ
inet6.0: 0/0/0/0
2001:DB8:4:1::1
555
82475
Establ
inet6.0: 1/1/1/0
83434
18
3w5d5h
83140
36
3w5d5h
83141
25
3w5d5h
83494
15
3w5d5h
465
Configuring VRRP for High Availability of Dual Routers on Branch Router 1

Step-by-Step
Procedure
Configure VRRP on the branch LAN interfaces as follows:
Set the routers priority for being elected to be the master router in the VRRP group. A
larger value indicates a higher priority for being elected.
Set the interval between VRRP advertisement packets to 333 milliseconds.
Add the preempt statement to allow the master router to be preempted.
Enable the master router to accept all packets destined for the virtual IP address.
Specify the interface to be tracked for this VRRP group, and set the priority cost for
becoming the master default router. The router with the highest priority within the
group becomes the master.
1.
Configure a VRRP group for IPv4 and IPv6 for the data interface to the branch LAN.
[edit]
edit interfaces ge-1/2/0 unit 43 family inet address 172.16.4.11/29
set vrrp-group 10 virtual-address 172.16.4.9
set vrrp-group 10 priority 200
set vrrp-group 10 fast-interval 333
set vrrp-group 10 preempt
set vrrp-group 10 accept-data
[edit]
edit interfaces ge-1/2/0 unit 43 family inet6 address 2001:DB8:4:43::3/64
set vrrp-inet6-group 10 virtual-inet6-address 2001:DB8:4:43::1
set vrrp-inet6-group 10 priority 200
set vrrp-inet6-group 10 preempt
set vrrp-inet6-group 10 accept-data
set vrrp-inet6-group 10 track interface ge-1/2/1 priority-cost 110
2.
Configure a VRRP group for IPv4 and IPv6 for the video interface to the branch LAN.
[edit]
set vrrp-group 20 track interface ge-1/2/1 priority-cost 110
[edit]
3.
Configure a VRRP group for IPv4 and IPv6 for the voice interface to the branch LAN.
[edit]
466

[edit]
4.

[edit]
commit
Results
Verify VRRP on the branch LAN interfaces.

user@branch1> show vrrp
Interface
State
Group
VR state VR Mode
ge-1/2/0.43
up
10
master
Active
ge-1/2/0.43
up
10
master
Active
Timer
Type
0.290 lcl
vip
0.038 lcl
Address
172.16.4.11
172.16.4.9
2001:DB8:4:43::3
vip
fe80::200:5eff:fe00:20a
ge-1/2/0.53
up
20
master
ge-1/2/0.53
up
20
master
Active
Active
vip
0.109 lcl
2001:DB8:4:43::1
172.16.4.19
vip
0.351 lcl
172.16.4.17
2001:DB8:4:53::3
vip
fe80::200:5eff:fe00:214
ge-1/2/0.63
up
30
master
ge-1/2/0.63
up
30
master
Active
Active
vip
0.003 lcl
2001:DB8:4:53::1
172.16.4.27
vip
0.064 lcl
172.16.4.25
2001:DB8:4:63::3
vip
fe80::200:5eff:fe00:21e
vip
2001:DB8:4:63::1
467
Configuring Multicast on Branch Router 1

Step-by-Step
Procedure
1.
Specify the static rendezvous point at the aggregation hub.

[edit]
edit protocols pim
2.
Configure multicast on the interface to the Layer 3 VPN service provider, the branch
LAN data interface, and the interface to Branch router 2.
Assign a priority of 20000 on the branch LAN to give it priority over the interface to
the branch LAN on Branch router 2.
[edit]
edit protocols pim
set interface ge-1/2/0.43 priority 20000
3.

[edit]
commit
Results
After you have configured Branch LAN 2, verify the configuration.

1.

user@branch1>show igmp group
Group: 224.0.0.5
Source: 0.0.0.0
Timeout:
248 Type: Dynamic
Group: 235.4.1.1
Source: 0.0.0.0
Timeout:
248 Type: Dynamic
. . .
Group: 224.0.0.2
Source: 0.0.0.0
Timeout:
169 Type: Dynamic
. . .
Group: 224.0.0.2
Source: 0.0.0.0
468

Timeout:
142 Type: Dynamic
Group: 224.0.0.5
Source: 0.0.0.0
Timeout:
148 Type: Dynamic
. . .
Group: 224.0.0.2
Source: 0.0.0.0
Timeout:
0 Type: Dynamic
Group: 224.0.0.5
Source: 0.0.0.0
Timeout:
0 Type: Dynamic
. . .
2. Verify that multicast is running over the Layer 3 VPN transport (ge-1/2/1).
user@branch1> show pim join
Group: 235.4.1.1
Source: *
RP: 172.31.255.15
Group: 235.4.1.1
Source: 172.31.252.10
Flags: sparse,spt
. . .
Group: 235.4.1.25
Source: *
RP: 172.31.255.15
Group: 235.4.1.25
Source: 172.31.252.10
Flags: sparse,spt
469
3. Verify multicast on the branch LAN interface, the interface to Branch router 2, and the
interface to the Layer 3 VPN transport.

user@branch1>show pim neighbors
show pim neighbors
Interface
IP V Mode
ge-1/2/0.43
4 2
ge-1/2/1.0
4 2
ge-1/3/4.1
4 2
ge-1/3/4.2
4 2
ge-1/2/0.43
6 2
fe80::5e5e:ab00:2b0d:d918
ge-1/2/1.0
6 2
fe80::5e5e:abff:fe4f:c77c
ge-1/3/4.1
6 2
fe80::5e5e:ab00:10d:d904
ge-1/3/4.2
6 2
fe80::5e5e:ab00:20d:d904
470
Option
HPLGT
HPLGT
HPLGT
HPLGT
HPLGT
Uptime
1w3d8h
1w3d8h
1w3d8h
1w3d8h
1w3d8h
HPLGT
1w3d8h
HPLGT
1w3d8h
HPLGT
1w3d8h
Neighbor addr
172.16.4.10
172.16.4.1
172.16.4.34
172.16.4.38
4. Verify that groups are established with upstream interfaces to the Layer 3 VPN service
provider (ge-1/2/1) and downstream interfaces to the branch LAN (ge-1/2/0/43).

user@branch1> show multicast route extensive
Group: 235.4.1.1
Source: 172.31.252.10/32
ge-1/2/0.43
Route state: Active
Uptime: 6d 06:41:00
Group: 235.4.1.2
Source: 172.31.252.10/32
ge-1/2/0.43
Route state: Active
Uptime: 6d 06:41:00
. . .
Group: 235.4.1.25
Source: 172.31.252.10/32
ge-1/2/0.43
Route state: Active
Uptime: 6d 06:40:59
471
rendezvous point.
user@branch1> show multicast rpf 172.31.255.15
0.0.0.0/0
Protocol: BGP
user@branch1> show pim rps extensive
address-family INET
RP: 172.31.255.15
Mode: Sparse
Time Active: 6w4d 02:47:16
Holdtime: 0
Device Index: 137
Subunit: 32769
Group Ranges:
224.0.0.0/4
235.4.1.1
235.4.1.2
235.4.1.3
235.4.1.4
235.4.1.5
235.4.1.6
235.4.1.7
235.4.1.8
235.4.1.9
235.4.1.10
235.4.1.11
235.4.1.12
235.4.1.13
235.4.1.14
235.4.1.15
235.4.1.16
235.4.1.17
235.4.1.18
235.4.1.19
235.4.1.20
235.4.1.21
235.4.1.22
235.4.1.23
235.4.1.24
235.4.1.25
472
Configuring CoS on Branch Router 1

Step-by-Step
Procedure
1.
[edit]
[edit]
c. Assign the forwarding classes to transmissions queues.
[edit]
set queue 4 Video
set queue 5 Voice
2.

[edit]
473

[edit]
c. Configure a DSCP rewrite rule for voice traffic. This rule sets the code-point bit
patterns for the Voice forwarding class and is applied to the branch LAN interface.
[edit]
for the Video forwarding class and is applied to the branch LAN interface.
[edit]
474
3.

[edit]
[edit]
set priority low
[edit]
[edit]
[edit]
set priority high
f.

[edit]
[edit]
475
set priority high

4.

[edit]
5.
Create a traffic control profile for use on the WAN transport to the Layer 3 VPN
service provider.
The 150 MB shaping rate is the service purchased from the service provider.
[edit]
6.
Apply CoS on the interface to Layer 3 VPN Service Provider A.

[edit]
set unit 0 rewrite-rules dscp-ipv6 Rewrite_CORE_TRAFFIC
7.
Apply CoS on the branch LAN interfaces.

[edit]
8.

[edit]
commit
476
Results
1.
Check that the traffic control profile is running on the WAN transport.
user@branch1> show class-of-service traffic-control-profile
Traffic control profile: mpls-link, Index: 9175
Scheduler map: MAIN-SCHD
2. Verify CoS on the WAN transport interface.

user@branch1> show class-of-service interface ge-1/2/1
Object
Name
Type
Rewrite
dscp
Classifier
Classifier
ip
Index
51863
9
13

Object
Name
Type
Classifier
DSCP-BA
dscp
Classifier
Index
961
9

Object
Name
Rewrite
video-af
Classifier
Video
Type
dscp
fixed
Index
35765
4

Object
Name
Rewrite
voice-ef
Classifier
Voice
Type
dscp
fixed
Index
28463
5

user@branch1> show interfaces queue ge-1/2/0
Description: --- To Emulated IXIA branches (eon ge-0/0/16) --Forwarding classes: 16 supported, 7 in use
Queued:
Packets
:
54289625421
Bytes
:
20181631385907
Transmitted:
Packets
:
54289625421
Bytes
:
20181631385907
0
0
0 pps
0 bps
0
0
0
0
pps
bps
pps
pps
477
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
RED-dropped bytes
:
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
Queued:
Packets
:
0
Bytes
:
0
Transmitted:
Packets
:
0
Bytes
:
0
0
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
RED-dropped bytes
:
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
Queued:
Packets
:
0
Bytes
:
0
Transmitted:
Packets
:
0
Bytes
:
0
0
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
RED-dropped bytes
:
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
Queued:
Packets
:
2894391697
Bytes
:
677657237045
Transmitted:
Packets
:
2894391697
Bytes
:
677657237045
0
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
RED-dropped bytes
:
0
Low
:
0
Medium-low
:
0
478
0
0
0
0
0
0
0
0
0
pps
pps
pps
pps
bps
bps
bps
bps
bps
0 pps
0 bps
0
0
0
0
0
0
0
0
0
0
0
0
0
pps
bps
pps
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
0 pps
0 bps
0
0
0
0
0
0
0
0
0
0
0
0
0
pps
bps
pps
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
13 pps
7328 bps
13
7328
0
0
0
0
0
0
0
0
0
pps
bps
pps
pps
pps
pps
pps
pps
bps
bps
bps
Medium-high
:
High
:
Queued:
Packets
:
Bytes
:
Transmitted:
Packets
:
Bytes
:
Low
:
Medium-low
:
Medium-high
:
High
:
RED-dropped bytes
:
Low
:
Medium-low
:
Medium-high
:
High
:
Queued:
Packets
:
Bytes
:
Transmitted:
Packets
:
Bytes
:
Low
:
Medium-low
:
Medium-high
:
High
:
RED-dropped bytes
:
Low
:
Medium-low
:
Medium-high
:
High
:
Queued:
Packets
:
Bytes
:
Transmitted:
Packets
:
Bytes
:
Low
:
Medium-low
:
Medium-high
:
High
:
RED-dropped bytes
:
Low
:
Medium-low
:
Medium-high
:
High
:
0
0
0 bps
0 bps
0
0
0 pps
0 bps
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0 pps
0 bps
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0 pps
0 bps
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
pps
bps
pps
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
pps
bps
pps
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
pps
bps
pps
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
479
5. Verify CoS queues on the WAN transport interface.

Description: --- To MPLS_VPN_PROVIDER1 link (jbeer ge-2/3/3) --Forwarding classes: 16 supported, 7 in use
Queued:
Packets
:
43529500088
Bytes
:
14790632113023
Transmitted:
Packets
:
43529383363
Bytes
:
14790586731593
1548
115177
Low
:
65840
Medium-low
:
0
Medium-high
:
28084
High
:
21253
RED-dropped bytes
:
44803110
Low
:
26375474
Medium-low
:
0
Medium-high
:
9575048
High
:
8852588
Queued:
Packets
:
0
Bytes
:
0
Transmitted:
Packets
:
0
Bytes
:
0
0
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
RED-dropped bytes
:
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
Queued:
Packets
:
6757712926
Bytes
:
3297763907888
Transmitted:
Packets
:
6757712926
Bytes
:
3297763907888
0
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
RED-dropped bytes
:
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
480
0 pps
0 bps
0
0
0
0
0
0
0
0
0
0
0
0
0
pps
bps
pps
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
0 pps
0 bps
0
0
0
0
0
0
0
0
0
0
0
0
0
pps
bps
pps
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
0 pps
0 bps
0
0
0
0
0
0
0
0
0
0
0
0
pps
bps
pps
pps
pps
pps
pps
pps
bps
bps
bps
bps
High
:
Queued:
Packets
:
Bytes
:
Transmitted:
Packets
:
Bytes
:
Low
:
Medium-low
:
Medium-high
:
High
:
RED-dropped bytes
:
Low
:
Medium-low
:
Medium-high
:
High
:
Queued:
Packets
:
Bytes
:
Transmitted:
Packets
:
Bytes
:
Low
:
Medium-low
:
Medium-high
:
High
:
RED-dropped bytes
:
Low
:
Medium-low
:
Medium-high
:
High
:
Queued:
Packets
:
Bytes
:
Transmitted:
Packets
:
Bytes
:
Low
:
Medium-low
:
Medium-high
:
High
:
RED-dropped bytes
:
Low
:
Medium-low
:
Medium-high
:
High
:
Queued:
Packets
:
Bytes
:
Transmitted:
Packets
:
0 bps
6494596421
2285209268544
0 pps
224 bps
6494593911
2285208582928
44
2466
0
791
0
1675
673360
0
284760
0
388600
0
224
0
0
0
0
0
0
0
0
0
0
0
Critical_Data
pps
bps
pps
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
Video
4730799976
2308630388288
0 pps
0 bps
4730799976
2308630388288
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
pps
bps
pps
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
Voice
6622098422
688746154296
6622063870
688738081792
1820
32732
32732
0
0
0
7731928
7731928
0
0
0
Network_Control
0 pps
0 bps
0
0
0
0
0
0
0
0
0
0
0
0
0
pps
bps
pps
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
2703086633
627116098856
0 pps
0 bps
2703086633
0 pps
481
Bytes
RED-dropped packets
Low
Medium-low
Medium-high
High
RED-dropped bytes
Low
Medium-low
Medium-high
High
482
:
:
:
:
:
:
:
:
:
:
:
:
627116098856
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
bps
pps
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
Configuring the WAN Transport at Aggregation Hub 2 on page 484
Configuring the EBGP Routing for the WAN Transport at Aggregation Hub 2 on page 485
Applying CoS to the WAN Transport at Aggregation Hub 2 on page 486
Configuring Multicast at Aggregation Hub 2 on page 486
483
Configuring the WAN Transport at Aggregation Hub 2

Step-by-Step
Procedure
1.

[edit]
set description "--- To MPLS_VPN_PROVIDE2 link ---"
set unit 0 family inet filter output v4_sample_filter

2.

[edit]
commit
Results

user@hub_2> show interfaces terse ge-4/2/2
Interface
Admin Link Proto
ge-4/2/2
up
up
ge-4/2/2.0
up
up
inet
inet6
Local
Remote
172.31.254.38/30
fe80::2e21:72ff:feb2:45ce/64
2001:DB8:254:2::2/64
multiservice

user@hub_2> ping 172.31.254.39 rapid
PING 172.31.254.39 (172.31.254.39): 56 data bytes
!!!!!
--- 172.31.254.39 ping statistics ---
484
5 packets transmitted, 5 packets received, 0% packet loss

Configuring the EBGP Routing for the WAN Transport at Aggregation Hub 2
Step-by-Step
Procedure
Configure EBGP groups for peering between the WAN aggregation role at the hub and
Layer 3 VPN Service Provider B.
1.
Configure an EBGP peer group for IPv4 traffic.

This BGP peer group uses the default local preference value of 100, which gives a
[edit]
set type external
set export DENY_ALL
set peer-as 556
set neighbor 172.31.254.37 authentication-key "$9$ynNeMLdbYZUiQFESre8LGUj"
2.

branch.
[edit]
set type external
set peer-as 556
set neighbor 2001:DB8:254:2::1 authentication-key
"$9$RWKcrKX7dgoZmfOIEceK4oJ"
485
Applying CoS to the WAN Transport at Aggregation Hub 2

Step-by-Step
Procedure
1.

[edit]
edit class-of-service traffic-control-profiles TO-MPLS-VPN2
2.
Apply the traffic control profile, the classifiers, and the rewrite rules to the WAN
transport interface. The classifiers and rewrite rules are configured in the aggregation
hub base configuration.
[edit]
set output-traffic-control-profile TO-MPLS-VPN2
Configuring Multicast at Aggregation Hub 2

Step-by-Step
Procedure
486
1.
Configure multicast on the WAN transport.

[edit]
set mode sparse
set version 2
Configuring Branch Router 2
Configuring EBGP Peering on the WAN Transport on Branch Router 2 on page 494
Configure the LAN Transport on Branch Router 2 on page 497
Configure the LAN Transport to Branch Router 1 on Branch Router 2 on page 502
Configuring OSPF Routing to Branch Router 1 on Branch Router 2 on page 506
Configuring IBGP Peering to Branch Router 1 on Branch Router 2 on page 508

Step-by-Step
Procedure
1.
[edit]
edit policy-options
2.

[edit]
set then discard
3.
interface specific.
[edit]
487
[edit]
[edit]
[edit]
[edit]
f.

[edit]
488
[edit]
[edit]
i.
[edit]
j.
management systems.
[edit]
management systems.
[edit]
489
l.

[edit]
[edit]
[edit]
[edit]
[edit]
4.

[edit]
490
5.

[edit]
commit
Results

user@ranch2> show firewall filter RE-PROTECTION-lo0.0-i
Counters:
Name
Bytes
accept-bfd-lo0.1-i
0
access-in-lo0.1-i
0
bgp-in-lo0.1-i
1340179
frag-attack-lo0.1-i
0
icmp-in-lo0.1-i
0
igmp-lo0.1-i
321280
0
loopback-in-lo0.1-i
0
ospf-in-lo0.1-i
6671568
pim-lo0.1-i
1061208
radius-lo0.1-i
0
0
snmp-in-lo0.1-i
0
tacacs-lo0.1-i
0
udp-in-lo0.1-i
0
vrrp-lo0.1-i
57162440
Policers:
Name
Bytes
0
0
0
0
0
0
0
0
Packets
0
0
20449
0
0
10040
0
0
83565
19652
0
0
0
0
0
1429061
Packets
0
0
0
0
0
0
0
0

Step-by-Step
Procedure
1.
Configure the router ID:
[edit]
491

Step-by-Step
Procedure
1.
Create the interface to Layer 3 VPN Service Provider B.

[edit]

2.

[edit]
commit
Results

1.

Interface
Admin Link Proto
ge-1/3/1
up
up
ge-1/3/1.0
up
up
inet
inet6
Local
Remote
172.16.4.6/30
fe80::5e5e:abff:fe0d:d919/64
2001:DB8:4:2::2/64
multiservice

Description: --- To MPLS_VPN_PROVIDER2 link (magha ge-1/3/1) --Link-level type: Ethernet, MTU: 1514, Speed: 1000mbps, BPDU Error: None,
492

Device flags
: Present Running
Link flags
: None
CoS queues
Last flapped
: 2013-05-29 11:53:19 PDT (6w4d 17:47 ago)
Input rate
: 288 bps (0 pps)
Output rate
: 0 bps (0 pps)
22 bytes
:
22 bytes
Flags: Is-Primary
493
Configuring EBGP Peering on the WAN Transport on Branch Router 2

Step-by-Step
Procedure
Configure EBGP peering for the WAN transport.

1.

[edit]
2.
aggregation hub.
[edit]
3.
aggregation hub. This policy prevents the default static route from being advertised
and allows OSPF and direct routes to be advertised.
[edit]
4.
provider.
to the hub.
[edit]
set type external
set peer-as 556
494
set neighbor 172.16.4.5 authentication-key "$9$uKsSBRSvWxwYoreYoJGq.0BI"

5.
provider.
[edit]
set type external
set export BRANCH-PREFIX6
set peer-as 556
set neighbor fec0:16:4:2::1 authentication-key "$9$WC9XNb4aU.PQs2PQFnpu8X7"
6.

[edit]
commit
495
Results
1.
Verify EBGP peering with Layer 3 VPN Service Provider B (172.16.4.5). The address
172.16.4.254 is the loopback address on Branch router 1.
Table
History Damp State
Pending
inet.0
2
1
0
0
0
0
inet6.0
2
1
0
0
0
0
Peer
AS
InPkt
OutPkt
OutQ
Flaps Last Up/Dwn
172.16.4.5
556
197181
197792
0
2
6w0d6h
0/1/1/0
0/0/0/0
172.16.4.254
64514
83669
83664
0
36
3w5d6h
1/1/1/0
0/0/0/0
2001:DB8:4::254
64514
85943
85933
0
25
3w5d6h
Establ
inet6.0: 1/1/1/0
2001:DB8:4:2::1
556
197173
197928
0
1
7w6d2h
Establ
inet6.0: 0/1/1/0
2. Verify the default static routes to Layer 3 VPN Service Provider A and B.
The route to Layer 3 VPN Service Provider A via ge-1/2/4.1 on Branch router 1 is active,
and it has a local preference of 200, which makes it preferred over the route to Service
Provider B, which has a local preference of 100.
user@branch2> show route 0.0.0.0
0.0.0.0/0
496
*[BGP/170] 1w4d 00:22:54, localpref 200, from 172.16.4.254

> to 172.16.4.33 via ge-1/2/4.1
[BGP/170] 3d 23:33:14, localpref 100
> to 172.16.4.5 via ge-1/3/1.0
Configure the LAN Transport on Branch Router 2

Step-by-Step
Procedure
voice.
1.

[edit]
set vlan-id 43

2.

[edit]
set vlan-id 53
3.

[edit]
set vlan-id 63
497

4.

[edit]
commit
498
Results
Verify that the interfaces to the branch LAN are up.

Interface
Admin Link Proto
ge-1/3/0
ge-1/3/0.43
up
up
inet
ge-1/3/0.53
up
up
ge-1/3/0.63
up
up
Local
Remote
172.16.4.9/29
172.16.4.10/29
inet6
fe80::5e5e:ab00:2b0d:d918/64
2001:DB8:4:43::2/64
multiservice
inet
172.16.4.17/29
172.16.4.18/29
inet6
fe80::5e5e:ab00:350d:d918/64
2001:DB8:4:53::2/64
multiservice
inet
172.16.4.25/29
172.16.4.26/29
inet6
fe80::5e5e:ab00:3f0d:d918/64
2001:DB8:4:63::2/64
multiservice

Physical interface: ge-1/3/0
Description: --- Data VLAN 43 --Flags: SNMP-Traps 0x0 VLAN-Tag [ 0x8100.43 ] Encapsulation: ENET2
22 bytes
:
22 bytes
Destination: fe80::/64, Local: fe80::5e5e:ab00:2b0d:d918
Description: --- VIDEO VLAN 53 --Flags: SNMP-Traps 0x0 VLAN-Tag [ 0x8100.53 ] Encapsulation: ENET2
22 bytes
:
22 bytes
499

Description: --- VOICE VLAN 63 --Flags: SNMP-Traps 0x0 VLAN-Tag [ 0x8100.63 ] Encapsulation: ENET2
22 bytes
:
22 bytes
Destination: fe80::/64, Local: fe80::5e5e:ab00:3f0d:d918
500

Step-by-Step
Procedure
1.
[edit]
2.
[edit]
3.

[edit]
commit
Results

Address
Interface
172.16.4.12
ge-1/3/0.43
172.16.4.11
ge-1/3/0.43
172.16.4.20
ge-1/3/0.53
172.16.4.19
ge-1/3/0.53
172.16.4.28
ge-1/3/0.63
172.16.4.27
ge-1/3/0.63
State
Full
Full
Full
Full
Full
Full

ID
Interface
State
172.16.4.12
ge-1/3/0.43
Full
172.16.4.255
ge-1/3/0.43
Full
172.16.4.20
ge-1/3/0.53
Full
172.16.4.255
ge-1/3/0.53
Full
172.16.4.28
ge-1/3/0.63
Full
172.16.4.255
ge-1/3/0.63
Full
ID
172.16.4.12
172.16.4.255
172.16.4.20
172.16.4.255
172.16.4.28
172.16.4.255
Pri
0
Dead
30
128
37
30
128
32
30
128
31
Pri
0
128
0
128
0
128
Dead
35
35
35
34
35
31
501
Configure the LAN Transport to Branch Router 1 on Branch Router 2

Step-by-Step
Procedure

1.

[edit]
set description "--- To Branch 1 - OSPF Area 0 vlan ---"
set vlan-id 1

2.

[edit]
set description "--- To Branch 1: OSPF Area 1 vlan ---"
set vlan-id 2
3.
Configure the loopback interface, which is in OSPF area 0.

[edit]
edit interfaces lo0
4.

[edit]
502
commit
503
Results
1.
Verify that the LAN interface to Branch 1 is up.

Interface
Admin Link Proto
ge-1/2/4
up
up
ge-1/2/4.1
up
up
inet
inet6
ge-1/2/4.2
up
up
ge-1/2/4.32767
up
up
Local
Remote
172.16.4.34/30
fe80::5e5e:ab00:10d:d904/64
2001:DB8:4:3::2/64
multiservice
inet
172.16.4.38/30
inet6
fe80::5e5e:ab00:20d:d904/64
2001:DB8:4:33::2/64
multiservice
multiservice
2. Verify that traffic is flowing over the interface.

Description: --- To Branch 1--Link-level type: Ethernet, MTU: 1518, Speed: 1000mbps, BPDU Error: None,
Device flags
: Present Running
CoS queues
Last flapped
: 2013-07-04 05:46:24 PDT (3w6d 09:42 ago)
Input rate
: 640 bps (1 pps)
Output rate
: 896 bps (1 pps)
Description: --- To Branch 1 - OSPF Area 0 vlan --Flags: SNMP-Traps 0x0 VLAN-Tag [ 0x8100.1 ] Encapsulation: ENET2
22 bytes
:
22 bytes
Description: --- To Branch 1 - OSPF Area 0 vlan --Flags: SNMP-Traps 0x0 VLAN-Tag [ 0x8100.2 ] Encapsulation: ENET2
504

Input packets : 0
Output packets: 0
Flags: None
505
Configuring OSPF Routing to Branch Router 1 on Branch Router 2

Step-by-Step
Procedure
Configure OSPF routing between Branch router 1 and Branch router 2.

The OSPF backbone area contains the point-to-point interface and the loopback interface
between Branch router 1 and Branch router 2. It is used to provide reachability between
the two routers. IBGP uses the loopback interface to form IBGP sessions between the
two branch routers, and IBGP learns the loopback address from OSPF.
1.
Configure the backbone area for IPv4. Add the loopback and unit 1 of the Ethernet
interface that connect to Branch router 1 to the area.
[edit]
set interface lo0.1
2.
Add the unit 2 of the Ethernet interface that connects to Branch router 1 to Area 1.
[edit]
edit protocols ospf area 0.0.01
3.
Configure the backbone area for IPv6. Add the loopback and Ethernet interfaces
that connect to Branch router 1 to the area.
[edit]
set interface lo0.1
4.
Add unit 2 of the Ethernet interfaces that connects to Branch router 1 to OSPFv3
Area 1.
[edit]
Results
Verify that OSPF is running between the branch routers.

1.
Address
Interface
172.16.4.33
ge-1/2/4.1
172.16.4.37
ge-1/2/4.2
. . .
State
Full
Full

ID
Interface
State
172.16.4.255
ge-1/2/4.1
Full
Neighbor-address fe80::5e5e:ab00:10d:d91c
172.16.4.255
ge-1/2/4.2
Full
Neighbor-address fe80::5e5e:ab00:20d:d91c
172.16.4.12
ge-1/3/0.43
Full
172.16.4.255
ge-1/3/0.43
Full
172.16.4.20
ge-1/3/0.53
Full
506
ID
172.16.4.255
172.16.4.255
Pri
128
Dead
37
128
31
30
128
33
30
Pri
128
128
Dead
38
39
172.16.4.255
ge-1/3/0.53
Full
172.16.4.28
ge-1/3/0.63
Full
172.16.4.255
ge-1/3/0.63
Full
128
34
30
128
36
507
Configuring IBGP Peering to Branch Router 1 on Branch Router 2

Step-by-Step
Procedure
Configure IBGP peering with Branch router 2.

1.
[edit]
set then next-hop self
2.
[edit]
3.
[edit]
edit protocols bgp group To-BR1
set type internal
set export NHS
set neighbor 172.16.4.254 local-address 172.16.4.255
4.
[edit]
edit protocols bgp group To-BR1-V6
set type internal
set local-address fec0:16:4::255
set export NHS6
5.

[edit]
commit
Results
1.
Verify IBGP peering with Branch 1 (172.16.4.254 and 2001:DB8:4::254).

Table
History Damp State
Pending
inet.0
2
1
0
0
0
0
inet6.0
2
1
0
0
0
0
Peer
AS
InPkt
OutPkt
OutQ
Flaps Last Up/Dwn
508
172.16.4.5
556
197223
197833
0/1/1/0
0/0/0/0
172.16.4.254
64514
83710
83705
1/1/1/0
0/0/0/0
2001:DB8:4::254
64514
85985
85974
Establ
inet6.0: 1/1/1/0
2001:DB8:4:2::1
556
197214
197970
Establ
inet6.0: 0/1/1/0
6w0d7h
36
3w5d6h
25
3w5d6h
7w6d2h
509

Step-by-Step
Procedure
The branch LAN on Branch router 1 has a priority of 200, and the branch LAN on Branch
router 2 has a priority of 100.
1.
[edit]
[edit interfaces ge-1/3/0 unit 43 family inet address 172.16.4.10/29
[edit]
2.
[edit]
[edit]
3.
[edit]
[edit]
510

4.

[edit]
commit
Results

Interface
State Group
VR state VR Mode
ge-1/3/0.43
up
10
master
Active
ge-1/3/0.43
up
10
backup
Active
Timer
Type
0.586 lcl
vip
D 3.464 lcl
vip
A
Address
172.16.4.10
172.16.4.9
2001:DB8:4:43::2
fe80::200:5eff:fe00:20a
fe80::5e5e:ab00:2b0d:d900
ge-1/3/0.53
up
20
master
Active
ge-1/3/0.53
Active
up
20
backup
vip
mas
2001:DB8:4:43::1
0.205 lcl
vip
3.537 lcl
vip
172.16.4.18
172.16.4.17
2001:DB8:4:53::2
vip
mas
2001:DB8:4:53::1
0.658 lcl
vip
2.955 lcl
vip
172.16.4.26
172.16.4.25
2001:DB8:4:63::2
vip
mas
2001:DB8:4:63::1
fe80::200:5eff:fe00:214
fe80::5e5e:ab00:350d:d900
ge-1/3/0.63
up
30
master
Active
ge-1/3/0.63
Active
up
30
backup
fe80::200:5eff:fe00:21e
fe80::5e5e:ab00:3f0d:d900
511

Step-by-Step
Procedure
1.
a. Specify the static rendezvous point at Aggregation Hub 1.
[edit]
edit protocols pim
b. Configure multicast on the branch LAN interfaces and on the interface to Branch
router 2.
Assign a priority of 10000 on the branch LAN to give the branch LAN on Branch
router 1 priority over this branch.
[edit]
edit protocols pim
set interface ge-1/3/0.43 priority 10000
Results
1.
Verify that IGMP groups are formed with the branch LAN.
Group: 224.0.0.2
Source: 0.0.0.0
Timeout:
153 Type: Dynamic
Group: 224.0.0.5
Source: 0.0.0.0
Timeout:
151 Type: Dynamic
. . .
Group: 224.0.0.2
Source: 0.0.0.0
Timeout:
0 Type: Dynamic
Group: 224.0.0.5
Source: 0.0.0.0
Timeout:
0 Type: Dynamic
Group: 224.0.0.6
Source: 0.0.0.0
Timeout:
0 Type: Dynamic
Group: 224.0.0.13
Source: 0.0.0.0
512

Timeout:
0 Type: Dynamic
Group: 224.0.0.18
Source: 0.0.0.0
Timeout:
0 Type: Dynamic
Group: 224.0.0.22
Source: 0.0.0.0
Timeout:
0 Type: Dynamic
2. Verify that multicast is running over the interface to Branch router 1 as the upstream
neighbor. The interface to Branch router 1 is the upstream neighbor in this case because
as long as the WAN transport on Branch router is up, all traffic flows on that transport.
Group: 235.4.1.1
Source: *
RP: 172.31.255.15
Group: 235.4.1.2
Source: *
RP: 172.31.255.15
. . .
Group: 235.4.1.25
Source: *
RP: 172.31.255.15
513
3. Verify multicast on the branch LAN interfaces, the interface to Branch router 2, and
the interface to the Layer 3 VPN transport.

Interface
IP V Mode
ge-1/2/4.1
4 2
ge-1/2/4.2
4 2
ge-1/3/0.43
4 2
ge-1/3/1.0
4 2
ge-1/2/4.1
6 2
fe80::5e5e:ab00:10d:d91c
ge-1/2/4.2
6 2
fe80::5e5e:ab00:20d:d91c
ge-1/3/0.43
6 2
fe80::5e5e:ab00:2b0d:d900
ge-1/3/1.0
6 2
fe80::aad0:e5ff:fe5c:2da9
514
Option
HPLGT
HPLGT
HPLGT
HPLGT
HPLGT
Uptime
3w5d7h
3w5d7h
3w5d7h
6w0d7h
3w5d7h
HPLGT
3w5d7h
HPLGT
3w5d7h
HPLGT
7w6d3h
Neighbor addr
172.16.4.33
172.16.4.37
172.16.4.11
172.16.4.5
4. Verify that groups are established with upstream interfaces to the Layer 3 VPN service
provider and downstream interfaces to the branch LAN.

Group: 235.4.1.1
Source: 172.31.252.10/32
Next-hop ID: 0
Route state: Active
Forwarding state: Pruned
Uptime: 6d 07:44:27
Group: 235.4.1.2
Source: 172.31.252.10/32
Next-hop ID: 0
Route state: Active
Uptime: 6d 07:44:27
. . .
Group: 235.4.1.25
Source: 172.31.252.10/32
Next-hop ID: 0
Route state: Active
Uptime: 6d 07:44:26
rendezvous point. The interface to Branch router 1 is used because as long as the WAN
transport on Branch router is up, all traffic flows on that transport.
0.0.0.0/0
Protocol: BGP
515

address-family INET
RP: 172.31.255.15
Mode: Sparse
Holdtime: 0
Device Index: 137
Subunit: 34817
Group Ranges:
224.0.0.0/4
235.4.1.1
235.4.1.2
235.4.1.3
235.4.1.4
235.4.1.5
235.4.1.6
235.4.1.7
235.4.1.8
235.4.1.9
235.4.1.10
235.4.1.11
235.4.1.12
235.4.1.13
235.4.1.14
235.4.1.15
235.4.1.16
235.4.1.17
235.4.1.18
235.4.1.19
235.4.1.20
235.4.1.21
235.4.1.22
235.4.1.23
235.4.1.24
235.4.1.25
516

Step-by-Step
Procedure
1.
[edit]
[edit]
[edit]
set queue 4 Video
set queue 5 Voice
2.

[edit]
517

[edit]
[edit]
[edit]
518
3.

[edit]
[edit]
set priority low
[edit]
[edit]
[edit]
set priority high
f.

[edit]
[edit]
519
set priority high

4.

[edit]
5.
Create a traffic control profile for use on the WAN transport to the Layer 3 VPN
service provider.
The 150 MB shaper rate is the service purchased from the service provider.
[edit]
6.
Apply CoS on the interface to Layer 3 VPN Service Provider B.

[edit]
7.

[edit]
520
Results
1.
user@branch2> show class-of-service traffic-control-profile
2. Verify CoS on the WAN transport interface.

Object
Name
Type
Rewrite
dscp
Classifier
Classifier
ip
Index
51863
9
13

Object
Name
Type
Classifier
DSCP-BA
dscp
Classifier
Index
961
9

Object
Name
Classifier
Video
Type
fixed
Index
4

Object
Name
Classifier
Voice
Type
fixed
Index
5

Description: --- Under BRANCH-ROUTER2 : To Emulated IXIA branches (eon
ge-0/0/17) --Forwarding classes: 16 supported, 7 in use
Queued:
Packets
:
7019405290
0 pps
Bytes
:
2546752366251
0 bps
Transmitted:
Packets
:
7019405290
0 pps
Bytes
:
2546752366251
0 bps
0
0 pps
0
0 pps
Low
:
0
0 pps
521
Medium-low
:
0
Medium-high
:
0
High
:
0
RED-dropped bytes
:
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
Queued:
Packets
:
0
Bytes
:
0
Transmitted:
Packets
:
0
Bytes
:
0
0
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
RED-dropped bytes
:
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
Queued:
Packets
:
0
Bytes
:
0
Transmitted:
Packets
:
0
Bytes
:
0
0
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
RED-dropped bytes
:
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
Queued:
Packets
:
450445710
Bytes
:
104986805549
Transmitted:
Packets
:
450445710
Bytes
:
104986805549
0
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
RED-dropped bytes
:
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
522
0
0
0
0
0
0
0
0
pps
pps
pps
bps
bps
bps
bps
bps
0 pps
0 bps
0
0
0
0
0
0
0
0
0
0
0
0
0
pps
bps
pps
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
0 pps
0 bps
0
0
0
0
0
0
0
0
0
0
0
0
0
pps
bps
pps
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
3 pps
1952 bps
3
1952
0
0
0
0
0
0
0
0
0
0
pps
bps
pps
pps
pps
pps
pps
pps
bps
bps
bps
bps
High
:
0
Queued:
Packets
:
70201
Bytes
:
26777140
Transmitted:
Packets
:
70201
Bytes
:
26777140
0
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
RED-dropped bytes
:
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
Queued:
Packets
:
130598
Bytes
:
51073312
Transmitted:
Packets
:
130598
Bytes
:
51073312
0
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
RED-dropped bytes
:
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
Queued:
Packets
:
0
Bytes
:
0
Transmitted:
Packets
:
0
Bytes
:
0
0
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
RED-dropped bytes
:
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
0 bps
0 pps
0 bps
0
0
0
0
0
0
0
0
0
0
0
0
0
pps
bps
pps
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
0 pps
0 bps
0
0
0
0
0
0
0
0
0
0
0
0
0
pps
bps
pps
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
0 pps
0 bps
0
0
0
0
0
0
0
0
0
0
0
0
0
pps
bps
pps
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
523
5. Verify CoS queues on the WAN transport interface.

Description: --- To MPLS_VPN_PROVIDER2 link (magha ge-1/3/1) --Forwarding classes: 16 supported, 7 in use
Queued:
Packets
:
9276162717
Bytes
:
3152474515322
Transmitted:
Packets
:
9276162717
Bytes
:
3152474515322
0
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
RED-dropped bytes
:
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
Queued:
Packets
:
0
Bytes
:
0
Transmitted:
Packets
:
0
Bytes
:
0
0
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
RED-dropped bytes
:
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
Queued:
Packets
:
199576419
Bytes
:
97393292472
Transmitted:
Packets
:
199576419
Bytes
:
97393292472
0
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
RED-dropped bytes
:
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
524
0 pps
0 bps
0
0
0
0
0
0
0
0
0
0
0
0
0
pps
bps
pps
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
0 pps
0 bps
0
0
0
0
0
0
0
0
0
0
0
0
0
pps
bps
pps
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
0 pps
0 bps
0
0
0
0
0
0
0
0
0
0
0
0
pps
bps
pps
pps
pps
pps
pps
pps
bps
bps
bps
bps
High
:
Queued:
Packets
:
Bytes
:
Transmitted:
Packets
:
Bytes
:
Low
:
Medium-low
:
Medium-high
:
High
:
RED-dropped bytes
:
Low
:
Medium-low
:
Medium-high
:
High
:
Queued:
Packets
:
Bytes
:
Transmitted:
Packets
:
Bytes
:
Low
:
Medium-low
:
Medium-high
:
High
:
RED-dropped bytes
:
Low
:
Medium-low
:
Medium-high
:
High
:
Queued:
Packets
:
Bytes
:
Transmitted:
Packets
:
Bytes
:
Low
:
Medium-low
:
Medium-high
:
High
:
RED-dropped bytes
:
Low
:
Medium-low
:
Medium-high
:
High
:
Queued:
Packets
:
Bytes
:
Transmitted:
Packets
:
0 bps
553967993
151465615630
0 pps
0 bps
553967993
151465615630
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
Critical_Data
pps
bps
pps
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
Video
139506722
68079269619
0 pps
0 bps
139506722
68079269619
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
196139623
20398535207
0 pps
0 bps
pps
bps
pps
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
Voice
196139623
20398535207
0
0
0
0
0
0
0
0
0
0
0
Network_Control
0
0
0
0
0
0
0
0
0
0
0
0
0
pps
bps
pps
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
79830140
18520592480
0 pps
0 bps
79830140
0 pps
525
Bytes
RED-dropped packets
Low
Medium-low
Medium-high
High
RED-dropped bytes
Low
Medium-low
Medium-high
High
526
:
:
:
:
:
:
:
:
:
:
:
:
18520592480
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
bps
pps
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
Verification
Purpose
Action
Verify that traffic is travelling end-to-end on the WAN transport on Branch router 1.
Run the following show command on the interface to ISP A.

user@branch1> show interfaces ge-1/2/1 extensive
Description: --- To MPLS_VPN_PROVIDER1 link (jbeer ge-2/3/3) --Link-level type: Ethernet, MTU: 1514, Speed: 1000mbps, BPDU Error: None,
Device flags
: Present Running
Link flags
: None
CoS queues
Hold-times
Last flapped
: 2013-07-04 05:53:58 PDT (1w4d 09:07 ago)
Statistics last cleared: 2013-06-18 11:47:29 PDT (3w6d 03:13 ago)
Traffic statistics:
Input bytes :
20954721274846
688 bps
Output bytes :
25162510821226
0 bps
Input packets:
55972511643
1 pps
Output packets:
71198523194
0 pps
Input bytes :
330503818368
Output bytes :
330813258096
Input packets:
1412409267
Output packets:
1413731784
Input bytes :
0
Output bytes :
0
Input packets:
0
Output packets:
0
Input errors:
incompletes: 0,
L2 channel errors: 0, L2 mismatch timeouts: 0, FIFO errors: 0, Resource errors:
0
Output errors:
0, FIFO errors: 0,
HS link CRC errors: 0, MTU errors: 0, Resource errors: 0
Queue counters:
Dropped packets
0 Best_Effort
43757323702
43757206977
116725
1 Scavenger
2 Bulk_Data
6790394937
6790394937
527
3 Critical_Dat
6526853292
6526850782
2510
4 Video
4753810645
4753810645
5 Voice
6654143223
6654108671
34552
6 Network_Cont
2716159704
2716159704
Queue number:
0
Best_Effort
1
Scavenger
2
Bulk_Data
3
Critical_Data
4
Video
5
Voice
6
Network_Control
MAC statistics:
Receive
Transmit
Total octets
20974200739886
25183170196916
Total packets
55972501000
71198507985
Unicast packets
48442275104
71198257847
Broadcast packets
965
1008
Multicast packets
7530224933
249128
CRC/Align errors
0
0
FIFO errors
0
0
MAC control frames
0
0
MAC pause frames
0
0
Oversized frames
0
Jabber frames
0
Fragment frames
0
VLAN tagged frames
0
Code violations
0
Total errors
0
0
Filter statistics:
Input packet count
55972528002
0
Input DA rejects
0
Input SA rejects
0
Output packet count
71198534989
0
0
Link partner:
Link mode: Full-duplex, Flow control: Symmetric/Asymmetric, Remote fault:
OK
Local resolution:
Destination slot: 1
CoS information:
Direction : Output
CoS transmit queue
Bandwidth
Buffer Priority
Limit
%
bps
%
usec
0 Best_Effort
r
r
r
0 medium-low
none
1 Scavenger
3
4500000
10
0
low
none
528
2 Bulk_Data
20
30000000
none
3 Critical_Data
15
22500000
exact
4 Video
20
30000000
exact
5 Voice
5
7500000
none
6 Network_Control
5
7500000
exact
15
0 medium-high
15
high
10
high
0 strict-high
high
18 bytes
:
18 bytes
Traffic statistics:
Input bytes :
20954721074096
Output bytes :
25162506188842
Input packets:
55972511208
Output packets:
71198523194
Input bytes :
330503818296
Output bytes :
330813258096
Input packets:
1412409266
Output packets:
1413731784
Local statistics:
Input bytes :
53064549
Output bytes :
96692626
Input packets:
666365
Output packets:
772064
Transit statistics:
Input bytes :
20954668009547
688 bps
Output bytes :
25162409496216
0 bps
Input packets:
55971844843
1 pps
Output packets:
71197751130
0 pps
Input bytes :
330503818296
Output bytes :
330813258096
Input packets:
1412409266
Output packets:
1413731784
Generation: 396
Flags: Is-Primary
Generation: 284
Flags: Is-Primary
529
Purpose
Action
Verify reachability and traffic paths to the loopback interface of the data center router,
the loopback interface of a router in a different branch, and an IP address in the service
1.
Display the default IPv4 routing tables on each branch to verify reachability throughout
the network.
user@branch1> show route table inet.0
0.0.0.0/0
10.4.1.0/24
10.4.2.0/24
10.4.3.0/24
10.4.4.0/24
10.4.5.0/24
10.4.6.0/24
10.4.7.0/24
10.4.8.0/24
*[BGP/170] 05:07:35, localpref 200

> to 172.16.4.1 via ge-1/2/1.0
*[OSPF/150] 05:09:10, metric 11, tag 0
> to 172.16.4.12 via ge-1/2/0.43
*[OSPF/150] 05:09:10, metric 11, tag 0
> to 172.16.4.12 via ge-1/2/0.43
*[OSPF/150] 05:09:10, metric 11, tag 0
> to 172.16.4.12 via ge-1/2/0.43
*[OSPF/150] 05:09:10, metric 11, tag 0
> to 172.16.4.12 via ge-1/2/0.43
*[OSPF/150] 05:09:10, metric 11, tag 0
> to 172.16.4.12 via ge-1/2/0.43
*[OSPF/150] 05:09:10, metric 11, tag 0
> to 172.16.4.12 via ge-1/2/0.43
*[OSPF/150] 05:09:10, metric 11, tag 0
> to 172.16.4.12 via ge-1/2/0.43
*[OSPF/150] 05:09:10, metric 11, tag 0

0.0.0.0/0
10.4.1.0/24

> to 172.16.4.33 via ge-1/2/4.1
[BGP/170] 5d 03:59:28, localpref 100
> to 172.16.4.5 via ge-1/3/1.0
*[OSPF/150] 18:11:48, metric 11, tag 0
> to 172.16.4.12 via ge-1/3/0.43
*[OSPF/150] 18:11:48, metric 11, tag 0
> to 172.16.4.12 via ge-1/3/0.43
*[OSPF/150] 18:11:48, metric 11, tag 0
> to 172.16.4.12 via ge-1/3/0.43
10.4.2.0/24
10.4.3.0/24
530
10.4.4.0/24
10.4.5.0/24
10.4.6.0/24
10.4.7.0/24
*[OSPF/150] 18:11:48,
> to 172.16.4.12 via
*[OSPF/150] 18:11:48,
> to 172.16.4.12 via
*[OSPF/150] 18:11:48,
> to 172.16.4.12 via
*[OSPF/150] 18:11:48,
> to 172.16.4.12 via
metric 11, tag

ge-1/3/0.43
metric 11, tag
ge-1/3/0.43
metric 11, tag
ge-1/3/0.43
metric 11, tag
ge-1/3/0.43
0
0
0
0
. . .
10.4.247.0/24
10.4.248.0/24
10.4.249.0/24
10.4.250.0/24
10.4.251.0/24
10.4.252.0/24
10.4.253.0/24
10.4.254.0/24
10.4.255.0/24
172.16.4.4/30
172.16.4.6/32
172.16.4.8/29
172.16.4.9/32
172.16.4.10/32
172.16.4.16/29
172.16.4.17/32
172.16.4.18/32
172.16.4.24/29
172.16.4.25/32
172.16.4.26/32
172.16.4.32/30
172.16.4.34/32
172.16.4.36/30
172.16.4.38/32
172.16.4.254/32
> to 172.16.4.28 via ge-1/3/0.63

*[OSPF/150] 18:11:48, metric 11, tag
> to 172.16.4.28 via ge-1/3/0.63
*[OSPF/150] 18:11:48, metric 11, tag
> to 172.16.4.28 via ge-1/3/0.63
*[OSPF/150] 18:11:48, metric 11, tag
> to 172.16.4.28 via ge-1/3/0.63
*[OSPF/150] 18:11:48, metric 11, tag
> to 172.16.4.28 via ge-1/3/0.63
*[OSPF/150] 18:11:48, metric 11, tag
> to 172.16.4.28 via ge-1/3/0.63
*[OSPF/150] 18:11:48, metric 11, tag
> to 172.16.4.28 via ge-1/3/0.63
*[OSPF/150] 18:11:48, metric 11, tag
> to 172.16.4.28 via ge-1/3/0.63
*[OSPF/150] 18:11:48, metric 11, tag
> to 172.16.4.28 via ge-1/3/0.63
*[OSPF/150] 18:11:48, metric 11, tag
> to 172.16.4.28 via ge-1/3/0.63
*[Direct/0] 4w0d 05:16:49
> via ge-1/3/1.0
*[Local/0] 4w0d 05:16:49
*[Direct/0] 1w5d 04:58:41
> via ge-1/3/0.43
*[Local/0] 1w5d 04:58:33
*[Local/0] 5w6d 00:49:27
*[Direct/0] 1w5d 04:58:41
> via ge-1/3/0.53
*[Local/0] 1w5d 04:58:33
*[Local/0] 5w6d 00:49:27
*[Direct/0] 1w5d 04:58:41
> via ge-1/3/0.63
*[Local/0] 1w5d 04:58:33
*[Local/0] 5w6d 00:49:27
*[Direct/0] 1w5d 04:56:45
> via ge-1/2/4.1
*[Local/0] 5w6d 00:49:27
*[Direct/0] 1w5d 04:56:45
> via ge-1/2/4.2
*[Local/0] 6w5d 22:49:58
*[OSPF/10] 1w5d 04:55:41, metric 1
0
0
0
0
0
0
0
0
0
531
172.16.4.255/32
224.0.0.2/32
224.0.0.5/32
224.0.0.13/32
224.0.0.22/32
> to 172.16.4.33 via ge-1/2/4.1

*[Direct/0] 6w5d 22:51:17
> via lo0.1
*[PIM/0] 6w5d 22:51:27
MultiRecv
*[OSPF/10] 6w5d 22:51:28, metric 1
MultiRecv
*[PIM/0] 6w5d 22:51:27
MultiRecv
*[IGMP/0] 6w5d 22:50:04
MultiRecv

user@branch1> ping 172.31.255.8 rapid
PING 172.31.255.8 (172.31.255.8): 56 data bytes
!!!!!
user@branch1> traceroute 172.31.255.8
1 172.16.4.1 (172.16.4.1) 0.869 ms 0.822 ms 0.498 ms # L3VPN ISP A
2 172.31.254.33 (172.31.254.33) 0.608 ms 1.478 ms 0.604 ms #ISP A
3 172.31.254.34 (172.31.254.34) 0.468 ms 0.774 ms 0.587 ms #WANaggr 1
PING 172.16.1.254 (172.16.1.254): 56 data bytes
!!!!!
1 172.16.4.1 (172.16.4.1) 0.678 ms 0.813 ms 0.512 ms # L3VPN ISP A
2 172.31.254.33 (172.31.254.33) 0.504 ms 11.026 ms 0.477 ms #ISP A
3 172.31.254.34 (172.31.254.34) 0.480 ms 1.543 ms 2.250 ms #WANaggr 1
4 172.31.254.14 (172.31.254.14) 22.304 ms 0.803 ms 0.713 ms #VPN hub 1
5 172.16.1.254 (172.16.1.254) 3.273 ms 4.441 ms 8.268 ms# Branch Loopback
provider network.
1 172.16.4.1 (172.16.4.1) 0.684 ms 0.550 ms 0.445 ms # L3VPN ISP A
2 172.31.254.33 (172.31.254.33) 1.278 ms 0.545 ms 0.535 ms #ISP A
3 172.31.254.34 (172.31.254.34) 0.521 ms 0.524 ms 0.468 ms #WANaggr 1
4 172.31.254.9 (172.31.254.9) 0.479 ms 0.520 ms 0.481 ms #Int edge 1
6
532
* * *

Purpose
Action
Verify that a failure of the Branch router 1 physical WAN transport to Aggregation Hub 1
causes all traffic to be rerouted through Branch router 2 to Aggregation Hub 2 with minimal
traffic loss.
1.
Log in to Branch router 1 as the root user, and enter the following command to take
root@branch1% ifconfig ge-1/2/1 down
2. On Branch router 1, verify that the active default route is to ISP B over the interface to
Branch router 2.
0.0.0.0/0
*[BGP/170] 00:00:31, localpref 100, from 172.16.4.255

> to 172.16.4.34 via ge-1/3/4.1
3. On Branch router 2, verify EBGP peering with the Layer 3 VPN ISP B (172.16.4.5) and
the loopback interface (172.16.4.254) on Branch router 1.

Table
History Damp State
Pending
inet.0
1
1
0
0
0
0
inet6.0
1
1
0
0
0
0
Peer
AS
InPkt
OutPkt
OutQ
Flaps Last Up/Dwn
172.16.4.5
556
64444
64881
0
2
12:28:00
1/1/1/0
0/0/0/0
172.16.4.254
64514
64314
64319
0
1 1d 15:11:44
0/0/0/0
0/0/0/0
2001:DB8:4::254
64514
64255
64252
0
0
2w6d6h
Establ
inet6.0: 0/0/0/0
2001:DB8:4:2::1
556
64438
64949
0
1
1w6d8h
Establ
inet6.0: 1/1/1/0
4. On Branch router 2, verify that the active default route is to ISP B over the WAN
transport interface to ISP B.

0.0.0.0/0
*[BGP/170] 09:31:43, localpref 100

> to 172.16.4.5 viage-1/3/1.0
5. Verify traffic counters and queue statistics on Branch router 2 after failure.
533

Device flags
: Present Running
Link flags
: None
CoS queues
Hold-times
Last flapped
: 2013-05-29 11:53:19 PDT (2w6d 06:11 ago)
Statistics last cleared: 2013-06-18 11:47:29 PDT (06:17:17 ago)
Traffic statistics:
Input bytes :
10943440671
125398040 bps
Output bytes :
13795758330
130224664 bps
Input packets:
27314006
39900 pps
Output packets:
38512292
45401 pps
Input bytes :
135016692
Output bytes :
135055908
Input packets:
576995
Output packets:
577162
Input bytes :
0
Output bytes :
0
Input packets:
0
Output packets:
0
Input errors:
0,
Resource errors: 0
Output errors:
Queue counters:
Queued packets Transmitted packets Dropped packets
0 Best_Effort
34190461
34190461
0
1 Scavenger
0
0
0
2 Bulk_Data
742944
742944
0
3 Critical_Dat
2080803
2080803
0
4 Video
528549
528549
0
5 Voice
726138
726138
0
6 Network_Cont
297226
297226
0
Queue number:
0
Best_Effort
1
Scavenger
2
Bulk_Data
3
Critical_Data
4
Video
5
Voice
6
Network_Control
MAC statistics:
Receive
Transmit
Total octets
10849779951
13660181686
Total packets
27331751
38532479
Unicast packets
21588769
38530091
Broadcast packets
9
13
534
Multicast packets
5742972
2378
CRC/Align errors
0
0
FIFO errors
0
0
MAC control frames
0
0
MAC pause frames
0
0
Oversized frames
0
Jabber frames
0
Fragment frames
0
VLAN tagged frames
0
Code violations
0
Total errors
0
0
Filter statistics:
Input packet count
27331751
815
Input DA rejects
0
Input SA rejects
0
Output packet count
38532479
0
0
Link partner:
fault: OK
Local resolution:
Destination slot: 1
CoS information:
Direction : Output
CoS transmit queue
Bandwidth
Buffer Priority Limit
%
bps %
usec
0 Best_Effort
r
r r
0 medium-low none
1 Scavenger
3
4500000 10
0 low none
2 Bulk_Data
20
30000000 15
0 medium-high none
3 Critical_Data
15
22500000 15
0 high exact
4 Video
20
30000000 10
0 high exact
5 Voice
5
7500000 r
0 strict-high none
6 Network_Control
5
7500000 3
0 high exact
170)
22 bytes
:
22 bytes
Traffic statistics:
Input bytes :
10942558763
Output bytes :
13795716347
Input packets:
27312207
Output packets:
38512293
Input bytes :
135016504
Output bytes :
135055908
Input packets:
576993
Output packets:
577162
Local statistics:
Input bytes :
525592
Output bytes :
693776
535
Input packets:
6525
Output packets:
7019
Transit statistics:
Input bytes :
10942033171
125398040 bps
Output bytes :
13795022571
130224664 bps
Input packets:
27305682
39900 pps
Output packets:
38505274
45401 pps
Input bytes :
135016504
Output bytes :
135055908
Input packets:
576993
Output packets:
577162
Generation: 398
Flags: Is-Primary
Generation: 362
536
Queued:
Packets
:
36093293
41712
Bytes
:
12417782294
113860384
Transmitted:
Packets
:
36093293
41712
Bytes
:
12417782294
113860384
0
0
0
0
Low
:
0
0
Medium-low
:
0
0
Medium-high
:
0
0
High
:
0
0
RED-dropped bytes
:
0
0
Low
:
0
0
Medium-low
:
0
0
Medium-high
:
0
0
High
:
0
0
Queued:
Packets
:
0
0
Bytes
:
0
0
Transmitted:
Packets
:
0
0
Bytes
:
0
0
0
0
0
0
Low
:
0
0
Medium-low
:
0
0
Medium-high
:
0
0
High
:
0
0
RED-dropped bytes
:
0
0
Low
:
0
0
Medium-low
:
0
0
Medium-high
:
0
0
High
:
0
0
Queued:
Packets
:
786418
396
Bytes
:
383771984
1545984
Transmitted:
Packets
:
786418
396
Bytes
:
383771984
1545984
0
0
0
0
Low
:
0
0
Medium-low
:
0
0
Medium-high
:
0
0
High
:
0
0
RED-dropped bytes
:
0
0
Low
:
0
0
Medium-low
:
0
0
Medium-high
:
0
0
pps
bps
pps
bps
pps
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
pps
bps
pps
bps
pps
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
pps
bps
pps
bps
pps
pps
pps
pps
pps
pps
bps
bps
bps
bps
537
High
:
Queued:
Packets
:
Bytes
:
Transmitted:
Packets
:
Bytes
:
Low
:
Medium-low
:
Medium-high
:
High
:
RED-dropped bytes
:
Low
:
Medium-low
:
Medium-high
:
High
:
Queued:
Packets
:
Bytes
:
Transmitted:
Packets
:
Bytes
:
Low
:
Medium-low
:
Medium-high
:
High
:
RED-dropped bytes
:
Low
:
Medium-low
:
Medium-high
:
High
:
Queued:
Packets
:
Bytes
:
Transmitted:
Packets
:
Bytes
:
Low
:
Medium-low
:
Medium-high
:
High
:
RED-dropped bytes
:
Low
:
Medium-low
:
Medium-high
:
High
:
Queued:
Packets
:
Bytes
:
Transmitted:
Packets
:
538
0 bps
2197283
599916192
2203 pps
4455296 bps
2197283
599916192
0
0
0
0
0
0
0
0
0
0
0
2203
4455296
0
0
0
0
0
0
0
0
0
0
0
559139
272859832
701 pps
2739040 bps
559139
272859832
0
0
0
0
0
0
0
0
0
0
0
701
2739040
0
0
0
0
0
0
0
0
0
0
0
Critical_Data
pps
bps
pps
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
Video
pps
bps
pps
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
Voice
766606
79727024
766606
79727024
0
0
0
0
0
0
0
0
0
0
0
Network_Control
310 pps
258240 bps
310
258240
0
0
0
0
0
0
0
0
0
0
0
pps
bps
pps
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
314617
72991144
158 pps
293984 bps
314617
158 pps
Bytes
RED-dropped packets
Low
Medium-low
Medium-high
High
RED-dropped bytes
Low
Medium-low
Medium-high
High
:
:
:
:
:
:
:
:
:
:
:
:
72991144
0
0
0
0
0
0
0
0
0
0
0
293984
0
0
0
0
0
0
0
0
0
0
0
bps
pps
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
7. Check the path taken by traffic to the data center after Branch router 1 primary link
failure.
user@branch2> ping 172.31.255.8
PING 172.31.255.8 (172.31.255.8): 56 data bytes
^C
1 172.16.4.34 (172.16.4.34) 0.546 ms 0.475 ms 0.377 ms # Branch Router 2
2 172.16.4.5 (172.16.4.5) 0.437 ms 0.514 ms 0.510 ms # L3VPN ISPB PE 2
3 * * *
4 172.31.254.38 (172.31.254.38) 0.975 ms 8.610 ms 9.448 ms # WAN
Aggregation Hub 2
8. Check the Branch-to-Branch path taken by traffic after Branch router 1 primary link
failure.
PING 172.16.1.254 (172.16.1.254): 56 data bytes
1 172.16.4.34 (172.16.4.34) 0.570 ms 0.464 ms 0.459 ms # Secondary Router
2
3
4
5
6
7
172.16.4.5 (172.16.4.5) 0.460 ms 0.529 ms 0.440 ms # L3VPN ISP2 PE

* * *
172.31.254.38 (172.31.254.38) 34.200 ms 0.557 ms 0.456 ms #WANAGG2
172.31.254.41 (172.31.254.41) 0.495 ms 0.576 ms 0.496 ms #WANAGG1
172.31.254.14 (172.31.254.14) 0.616 ms 0.716 ms 0.550 ms #VPN1
539
9. Check the Branch-to-Internet path taken by traffic after Branch router 1 primary link
failure.
rtraceroute to 100.65.4.2 (100.65.4.2), 30 hops max, 40 byte packets
2
3
4
5
6
7
8
540

* * *
172.31.254.38 (172.31.254.38) 0.514 ms 0.541 ms 0.439 ms#WANAGG2
172.31.254.41 (172.31.254.41) 0.513 ms 0.574 ms 0.464 ms #WANAGG1
172.31.254.9 (172.31.254.9) 0.475 ms 0.537 ms 0.512 ms #IEDGE1
* * *
* * *
Verify that groups are established with upstream interfaces to the Layer 3 VPN service
provider 2 (ge-1/3/1) and downstream interfaces to Branch router 1 (ge-1/2/4).
Group: 235.4.1.1
Source: 172.31.252.10/32
ge-1/2/4.1
Route state: Active
Uptime: 00:12:36
Group: 235.4.1.2
Source: 172.31.252.10/32
ge-1/2/4.1
Route state: Active
Uptime: 00:12:35
Group: 235.4.1.3
Source: 172.31.252.10/32
ge-1/2/4.1
Route state: Active
Uptime: 00:12:35
541
Purpose
Action
Verify this scenario from the WAN aggregation router at Aggregation Hub 1.
1.
Interface
Admin Link Proto
Local
Remote
ge-1/2/5
up
up
ge-1/2/5.0
up
up
inet
172.31.254.34/30
inet6
fe80::5e5e:abff:fe0e:4205/64
2001:DB8:254:1::2/64
multiservice
Interface
Admin Link Proto
ge-1/2/5
up
up
ge-1/2/5.0
up
up
inet
inet6
Local
Remote
172.31.254.34/30
fe80::5e5e:abff:fe0e:4205/64
2001:DB8:254:1::2/64
multiservice

Table
History Damp State
Pending
inet.0
26386
26384
0
0
0
0
inet6.0
25393
25393
0
0
0
0
Peer
AS
InPkt
OutPkt
OutQ
Flaps Last Up/Dwn
172.31.254.33
555
855
759
0
0
6:13:55
383/384/384/0
0/0/0/0
Table
History Damp State
Pending
inet.0
26386
26384
0
0
0
0
inet6.0
25393
25393
0
0
0
0
Peer
AS
InPkt
OutPkt
OutQ
Flaps Last Up/Dwn
2001:DB8:254:1::1
555
857
759
0
0
6:14:23
Establ
inet6.0: 392/392/392/0
provider.
Prefix
* 0.0.0.0/0
542
Nexthop
Self
MED
0
Lclpref
AS path
I

Prefix
* ::/0
Nexthop
Self
MED
Lclpref
AS path
I
543
544
CHAPTER 14
Connecting a Large Branch to

3 VPN with Internet Backup
Connecting a Large Branch to Dual-Homed Aggregation Hubs over Layer 3 VPN with
Internet Backup
This example shows a large branch with dual routers that is dual-homed to Aggregation
Hub 1 and Aggregation Hub 2. The primary branch router connects to Aggregation Hub 1
over a Layer 3 VPN provided by a service provider. The secondary router connects to
Aggregation Hub 2 over the Internet (Figure 80 on page 547).
Requirements
This example uses the following hardware and software components at the branch :
MX80 3D Universal Edge Router with the following MICs/PICs:
4-port 10-Gigabit Ethernet MIC with XFP
8-port Channelized SONET/SDH OC3/STM1 (Multi-Rate) MIC with SFP (model

number: MIC-3D-8CHOC3-4CHOC12)
Two 10 Gigabit Ethernet LAN/WAN PICs with SFP PICs(10x 1GE(LAN) SFP)
M7i Multiservice Edge Router with the following PICs:
Two 4-port Gigabit Ethernet Enhanced IQ2 PICs
2-port Channelized SONET/SDH OC3/STM1 PIC
MultiServices 100 PIC
Tunnel Services PIC
1x G/E PIC
545
Overview
Branch router 1 is the primary router, and Branch router 2 is the secondary router. Virtual
Router Redundancy Protocol (VRRP) is used to elect the primary and secondary router.
For high availability, there are dual routers at the branch that are dual-homed to the
aggregation hubs over two separate carriers:
Branch router 1 is the primary router and connects to Aggregation Hub 1 over a Layer
3 VPN transport provided by Service Provider A.
Branch router 2 is the secondary router and connects to Aggregation Hub 2 over an
Internet transport provided by Service Provider B.
Routing is designed so that so that routes from Branch router 1 to Aggregation Hub 1
are always preferred over routes from Branch router 2 to Aggregation Hub 2. The design
also ensures that if the connection from Branch router 1 to the hub goes down, Branch
router 2 receives the routing information that it needs to send traffic to the backup
hub. BGP and OSPF are the routing protocols used in this design:
EBGP is used between the branch routers and the service providers.
IBGP is used over the GRE tunnels to Aggregation Hub 2.
OSPF is used for routing between the two branch routers and for routing on the
branch LAN.
BGP exports routes to OSPF so that the backup router always has routing information.
546
The transport to Aggregation Hub 2 is the public Internet using GRE tunnels. For security,
the GRE tunnels run over IPsec tunnels. IPsec provides a secure session and GRE
provides the IP multicast and multiprotocol capabilities.
For link-level high availability, Bidirectional Forwarding Detection (BFD) is used on

IBGP sessions for fast failure detection.
All traffic sent from the branch to the hub uses the 0.0.0.0/0 route received over Layer
3 VPN (primary path) and GRE over IPsec IBGP session. (secondary path)
The branch router has 3 VLANs (data, voice, and video) configured towards the branch
switch and running OSPF on these.
CoS scheduling and shaping is applied to both Layer 3 VPN physical link and the GRE
tunnels.
Chapter 14: Connecting a Large Branch to Dual-Homed Aggregation Hubs over Layer 3 VPN with Internet Backup
Topology
Figure 80: Test Lab Configuration Connecting Large Remote Branch with
Primary Layer 3 VPN and Backup GRE over IPsec
Configuring Branch Router 1 for Layer 3 VPN Transport on page 551
Configuring Branch Router 2 for Secondary Internet Transport on page 601
547
To configure the router at Aggregation Hub 1, perform these tasks:
1 on page 548
Hub 1 on page 549

Hub 1
Step-by-Step
Procedure

[edit]
set vlan-tagging
Step-by-Step
Procedure
Configure EBGP peering between the WAN aggregation router at the hub and Service
Provider A.
1.

[edit]
set type external
548
set export DENY_ALL

2.

branch.
[edit]
set type external
set peer-as 555

Aggregation Hub 1
Step-by-Step
Procedure
CoS classifiers, rewrite rules, and schedulers are all configured in the hub base
configuration.
1.

The 400 MB shaping rate is the service purchased from the service provider.
[edit]
2.
base configuration.
[edit]

Step-by-Step
Procedure
1.
Add the interface to the Layer 3 VPN service provider to the multicast configuration
at the hub.
[edit]
set mode sparse
549
set version 2
550
Configuring Branch Router 1 for Layer 3 VPN Transport

To configure Branch router 1, perform these tasks:
Configuring EBGP Routing on the WAN Transport on Branch Router 1 on page 558
Configuring OSPF Routing Between Branch Routers on Branch Router 1 on page 570

Step-by-Step
Procedure
1.
[edit]
edit policy-options
2.

[edit]
set then discard
3.
interface specific.
[edit]
551

[edit]
[edit]
[edit]
[edit]
f.

[edit]
552
[edit]
[edit]
i.
[edit]
j.
management systems.
[edit]
management systems.
[edit]
553
l.

[edit]
[edit]
[edit]
[edit]
[edit]
4.

[edit]
554
5.

[edit]
commit
Results

user@branch1> show firewall filter RE-PROTECTION-lo0.0-i
Counters:
Name
Bytes
IPsec-lo0.0-i
0
accept-bfd-lo0.0-i
0
access-in-lo0.0-i
2034742
bgp-in-lo0.0-i
167526
frag-attack-lo0.0-i
0
icmp-in-lo0.0-i
29148
igmp-lo0.0-i
411764
16820785
loopback-in-lo0.0-i
0
ospf-in-lo0.0-i
6612460
pim-lo0.0-i
845154
radius-lo0.0-i
0
0
snmp-in-lo0.0-i
163465
tacacs-lo0.0-i
0
udp-in-lo0.0-i
89489960
vrrp-lo0.0-i
680
Policers:
Name
Bytes
limit-150k-IPsec-lo0.0-i
0
0
0
0
0
0
0
0
0
Packets
0
0
36444
2055
0
347
12708
82603
0
82705
15651
0
0
1922
0
545672
17
Packets
0
0
0
0
0
0
0
0
0

Step-by-Step
Procedure
1.
[edit]
555

Step-by-Step
Procedure
1.
Create the interface to the Layer 3 VPN service provider.

[edit]
set description "--- To Layer 3 VPN Provider---"
set unit 0 family inet filter output v4_sample

2.

[edit]
commit
Results
Verify that the physical transport to the Layer 3 VPN service provider is up:
Interface
Admin Link Proto
ge-1/2/5
up
up
ge-1/2/5.0
up
up
inet
inet6
Local
Remote
172.16.3.2/30
fe80::5e5e:abff:fe0e:4505/64
2001:DB8:3:1::2/64
multiservice

Description: --- To MPLS_VPN_PROVIDER1 link (Jbeer ge-7/0/5) --Link-level type: Ethernet, MTU: 1514, Speed: 1000mbps, BPDU Error: None,
556
Device flags
: Present Running
Link flags
: None
CoS queues
Last flapped
: 2013-07-09 04:49:00 PDT (4w5d 07:07 ago)
Input rate
: 59779088 bps (21998 pps)
Output rate
: 85155096 bps (25769 pps)
18 bytes
:
18 bytes
Flags: Is-Primary
Flags: Is-Primary
557
Configuring EBGP Routing on the WAN Transport on Branch Router 1

Step-by-Step
Procedure
Configure EBGP peering between the branch router and Service Provider A.
1.
Configure the autonomous system (AS) number for the router, and specify the
number of times the AS can be in an AS path.
[edit]
set autonomous-system loops 2
2.
Configure policies used by BGP.

a. Configure a policy that is used to control IPv4 routes that are advertised to the
aggregation hub.
[edit]
b. Configure a policy that is used to control IPv6 routes that are advertised to the
aggregation hub.
[edit]
c. Configure a policy that sets the local preference to 200 for the IPv4 default route

[edit]
558
d. Configure a policy that sets the local preference to 200 for default static IPv6
routes learned from BGP.

[edit]
3.
provider.
The SET_LOCAL_PREF import policy sets the local preference value for routes over
the Layer 3 VPN to 200. Routes from Branch router 2 use the default local route
to the hub.
[edit]
set type external
set peer-as 555
set local-as 64513
set neighbor 172.16.3.1 authentication-key "$9$SVDlv8-VsJGjTzRcylW8ZGD"
4.
provider.
The SET_LOCAL_PREF6 import policy sets the local preference value for routes
over the Layer 3 VPN to 200. Routes to Branch router 2 use the default local route
[edit]
set type external
set import SET_LOCAL_PREF-V6
set peer-as 555
set local-as 64513
set neighbor 2001:DB8:3:1::1 authentication-key "$9$w92oZHqP36CRh-bs2JZn69"
559
5.

[edit]
commit
Results
Verify EBGP peering with the Layer 3 VPN service provider (17.16.3.1). The interface that
connects to the service provider is ge-1/2/5.0
Table
History Damp State
Pending
inet.0
1
1
0
0
0
0
inet6.0
1
1
0
0
0
0
Peer
AS
InPkt
OutPkt
OutQ
Flaps Last Up/Dwn
172.16.3.1
555
119671
121612
0
8
4w5d8h
1/1/1/0
0/0/0/0
2001:DB8:3:1::1
555
119666
121549
0
8
4w5d8h
Establ
inet6.0: 1/1/1/0
0.0.0.0/0
560
*[BGP/170] 02:56:55, localpref 200

> to 172.16.3.1 via ge-1/2/5.0

Step-by-Step
Procedure
voice.
1.
Create the interface, and enable VLAN tagging.

[edit]
set description "--- To branch---"
set vlan-tagging
2.

[edit]
set vlan-id 42

3.

[edit]
[edit interfaces ge-1/3/5 unit 52
set vlan-id 52
4.
561
[edit]
set vlan-id 62
562
Results
Verify that the interfaces to the branch LAN are up.

Interface
Admin Link Proto
ge-1/3/5
up
up
ge-1/3/5.42
up
up
inet
ge-1/3/5.52
up
up
ge-1/3/5.62
up
up
ge-1/3/5.32767
up
up
Local
Remote
172.16.3.9/29
172.16.3.11/29
inet6
fe80::200:5eff:fe00:20a/64
fe80::5e5e:ab00:2a0e:451d/64
2001:DB8:3:42::1/64
2001:DB8:3:42::3/64
multiservice
inet
172.16.3.17/29
172.16.3.19/29
inet6
fe80::200:5eff:fe00:214/64
fe80::5e5e:ab00:340e:451d/64
2001:DB8:3:52::1/64
2001:DB8:3:52::3/64
multiservice
inet
172.16.3.25/29
172.16.3.27/29
inet6
fe80::200:5eff:fe00:21e/64
fe80::5e5e:ab00:3e0e:451d/64
2001:DB8:3:62::1/64
2001:DB8:3:62::3/64
multiservice
multiservice

Description: --- To Emulated IXIA branches (eon ge-0/0/32) --Link-level type: Ethernet, MTU: 1518, Speed: 1000mbps, BPDU Error: None,
MAC-REWRITE Error: None, Loopback: Disabled,
Device flags
: Present Running
CoS queues
Current address: 5c:5e:ab:0e:45:1d, Hardware address: 5c:5e:ab:0e:45:1d
Last flapped
: 2013-07-04 10:42:37 PDT (1w5d 22:08 ago)
Input rate
: 672 bps (0 pps)
Output rate
: 4512 bps (6 pps)
Description: --- To IXIA emulated branch (Data VLAN 42) --Flags: SNMP-Traps 0x0 VLAN-Tag [ 0x8100.42 ] Encapsulation: ENET2
22 bytes
:
22 bytes
563
Destination: fe80::/64, Local: fe80::200:5eff:fe00:20a

Destination: fe80::/64, Local: fe80::5e5e:ab00:2a0e:451d
Description: --- To IXIA emulated branch (VIDEO VLAN 52) --Flags: SNMP-Traps 0x0 VLAN-Tag [ 0x8100.52 ] Encapsulation: ENET2
22 bytes
:
22 bytes
Destination: fe80::/64, Local: fe80::200:5eff:fe00:214
Destination: fe80::/64, Local: fe80::5e5e:ab00:340e:451d
Description: --- To IXIA emulated branch (VOICE VLAN 62) --Flags: SNMP-Traps 0x0 VLAN-Tag [ 0x8100.62 ] Encapsulation: ENET2
22 bytes
:
22 bytes
Destination: fe80::/64, Local: fe80::200:5eff:fe00:21e
Destination: fe80::/64, Local: fe80::5e5e:ab00:3e0e:451d
Input packets : 0
Output packets: 0
Flags: None
564

Step-by-Step
Procedure
1.
[edit]
set interface ge-1/3/5.42 metric 100
2.
[edit]
3.

[edit]
commit
Results

172.16.3.12
ge-1/3/5.42
172.16.3.10
ge-1/3/5.42
172.16.3.20
ge-1/3/5.52
172.16.3.18
ge-1/3/5.52
172.16.3.28
ge-1/3/5.62
172.16.3.26
ge-1/3/5.62
Full
Full
Full
Full
Full
Full

ID
Interface
State
172.16.3.12
ge-1/3/5.42
Full
Neighbor-address fe80::200:1eff:fefa:5ec6
172.16.3.254
ge-1/3/5.42
Full
Neighbor-address fe80::5e5e:ab00:2afe:e800
172.16.3.20
ge-1/3/5.52
Full
Neighbor-address fe80::200:1eff:fefa:5ec8
172.16.3.254
ge-1/3/5.52
Full
Neighbor-address fe80::5e5e:ab00:34fe:e800
172.16.3.28
ge-1/3/5.62
Full
Neighbor-address fe80::200:1eff:fefa:5eca
172.16.3.254
ge-1/3/5.62
Full
Neighbor-address fe80::5e5e:ab00:3efe:e800
172.16.3.12
172.16.3.254
172.16.3.20
172.16.3.254
172.16.3.28
172.16.3.254
Pri
0
Dead
32
128
37
32
128
35
32
128
36
0
128
0
128
0
128
36
37
36
37
36
37
565

Step-by-Step
Procedure

1.
Configure the interface for VLAN tagging, and specify a description for the interface.
[edit]
set description "--- To BRANCH-ROUTER2 ge-0/0/2 ---"
set vlan-tagging
2.

[edit]
set description "--- OSPF Area 0 vlan ---"
set vlan-id 1

3.

[edit]
set description "--- OSPF Area 1 vlan ---"
set vlan-id 2
4.
566
Configure the loopback interface to Branch router 2.
[edit]
set description "--- Default Routing instance ---"
5.

[edit]
commit
567
Results
After you configure Branch router 2, verify that the LAN interfaces to Branch router 2 are
up.
Description: --- B2B Connection to Secondary Branch Edge (ge-0/0/2) --Link-level type: Ethernet, MTU: 1518, Speed: 1000mbps, BPDU Error: None,
Device flags
: Present Running
CoS queues
Last flapped
: 2013-07-04 06:06:00 PDT (5w3d 08:03 ago)
Input rate
: 0 bps (0 pps)
Output rate
: 416 bps (0 pps)
Description: --- OSPF Area 0 vlan --Flags: SNMP-Traps 0x0 VLAN-Tag [ 0x8100.1 ] Encapsulation: ENET2
22 bytes
:
22 bytes
22 bytes
:
22 bytes
568
Input packets : 0
Output packets: 0
Flags: None
569
Configuring OSPF Routing Between Branch Routers on Branch Router 1

Step-by-Step
Procedure
We are using an OSPF backbone area between the two branch routers. Default BGP
routes are exported to OSPF. This configuration is required for failover scenarios where
the link from Branch router 1 and the Layer 3 VPN service provider goes down. Traffic is
rerouted to Branch router 2 and then to Aggregation Hub 2. In this case, Branch router 2
receives the routes that it needs from OSPF.
1.
Configure IPv4 and IPv6 routing policies that are used to export default BGP routes
into OSPF. Set the external metric type for routes exported by OSPF to 1.
When OSPF exports routes from external ASs, it includes a cost, or external metric,
in the route. The metric type determines how OSPF calculates the cost of the route.
Type 1 external metrics are equivalent to the link-state metric, where the cost is
equal to the sum of the internal costs plus the external cost. This means that Type
1 external metrics include the external cost to the destination as well as the cost
(metric) to reach the AS boundary router.
[edit]
[edit]
2.
Configure OSPF for IPv4.

a. Apply the BGP2OSPF export policy.
Applying the policy as an export policy for OSPF causes OSPF to advertise IPv6
default routes learned through BGP.
[edit]
edit protocols ospf
set export BGP2OSPF
b. Set the external preference for OSPF routes to 175 so that default routes learned
from BGP on Branch router 2 have a higher priority so that if BGP goes down on
the Branch router 1 WAN transport, traffic is sent to the aggregation hub over
the Branch router 2 transport.
[edit]
edit protocols ospf
570
c. Create a backbone area. The OSPF backbone area contains the point-to-point
interface and the loopback interface between Branch router 1 and Branch router
2.
[edit]
set interface lo0.0
d. Add the unit 2 of the Ethernet interface that connects to Branch router 2 to Area
1.
[edit]
3.

a. Apply the BGP2OSPF-V6 export policy.
[edit]
b. Set the external preference for OSPFv3 routes to 175 so that default routes
learned from BGP on Branch router 2 have a higher priority so that if BGP goes
down on the Branch router 1 WAN transport, traffic is sent to the aggregation
hub over the Branch router 2 transport.
[edit]
4.
Create a backbone area. The OSPF backbone area contains the point-to-point
interface and the loopback interface between Branch router 1 and Branch router 2.
[edit]
set interface lo0.0
5.
[edit]
edit protocols osp3f area 0.0.0.1
571
Step-by-Step
Procedure
After you configure Branch router 2, verify that OSPF is running between the branch
routers.
1.
Address
Interface
172.16.3.33
ge-1/2/1.1
38
172.16.3.37
ge-1/2/1.2
37
State
Full
ID
172.16.3.254
Full
172.16.3.254

ID
Interface
State
172.16.3.254
ge-1/2/1.1
Init
172.16.3.254
ge-1/2/1.2
Full
572
Pri
128
Dead
33
128
37
Pri Dead
128
128

Step-by-Step
Procedure
Specify the interface to be tracked for this VRRP group, and set the priority cost for
becoming the master default router. The router with the highest priority within the
group becomes the master.
1.
[edit]
[edit]
2.
[edit]
[edit]
3.
[edit]
573

[edit]
4.

[edit]
commit
Results

Interface
State
ge-1/3/5.42
up
ge-1/3/5.42
up
2001:DB8:3:42::3
Group
10
10
VR state VR Mode
master
Active
master
Timer
Type
A 0.673 lcl
Active
vip
0.179 lcl
Address
172.16.3.11
172.16.3.9
vip
fe80::200:5eff:fe00:20a
vip
2001:DB8:3:42::1
ge-1/3/5.52
up
ge-1/3/5.52
up
2001:DB8:3:52::3
20
20
master
master
Active
Active
0.120 lcl
vip
0.273 lcl
172.16.3.19
172.16.3.17
vip
fe80::200:5eff:fe00:214
vip
2001:DB8:3:52::1
ge-1/3/5.62
up
ge-1/3/5.62
up
2001:DB8:3:62::3
30
30
master
master
Active
Active
0.687 lcl
vip
0.046 lcl
172.16.3.27
172.16.3.25
vip
fe80::200:5eff:fe00:21e
vip
2001:DB8:3:62::1
574

Step-by-Step
Procedure
1.

[edit]
edit protocols pim
2.
Configure multicast on the branch LAN interfaces and on the interface to Branch
router 2.
[edit]
edit protocols pim
3.

[edit]
commit
Results
After you have configured Branch 2, verify multicast.

1.

Group: 224.0.0.5
Source: 0.0.0.0
Timeout:
78 Type: Dynamic
Group: 235.3.1.1
Source: 0.0.0.0
Timeout:
199 Type: Dynamic
Group: 235.3.1.2
Source: 0.0.0.0
Timeout:
199 Type: Dynamic
. . .
Group: 235.3.1.15
Source: 0.0.0.0
Timeout:
199 Type: Dynamic
Group: 224.0.0.5
Source: 0.0.0.0
Timeout:
181 Type: Dynamic
Group: 224.0.0.6
Source: 0.0.0.0
575

Timeout:
178 Type: Dynamic
Group: 224.0.0.13
Source: 0.0.0.0
Timeout:
181 Type: Dynamic
Group: 224.0.0.5
Source: 0.0.0.0
Timeout:
256 Type: Dynamic
Group: 224.0.0.6
Source: 0.0.0.0
Timeout:
254 Type: Dynamic
Group: 224.0.0.13
Source: 0.0.0.0
Timeout:
256 Type: Dynamic
Group: 224.0.0.2
Source: 0.0.0.0
Timeout:
0 Type: Dynamic
Group: 224.0.0.5
Source: 0.0.0.0
Timeout:
0 Type: Dynamic
Group: 224.0.0.6
Source: 0.0.0.0
Timeout:
0 Type: Dynamic
Group: 224.0.0.13
Source: 0.0.0.0
Timeout:
0 Type: Dynamic
Group: 224.0.0.18
Source: 0.0.0.0
Timeout:
0 Type: Dynamic
Group: 224.0.0.22
Source: 0.0.0.0
Timeout:
0 Type: Dynamic
576
2. Verify that multicast is running over the Layer 3 VPN transport.

Group: 235.3.1.1
Source: *
RP: 172.31.255.15
Group: 235.3.1.1
Source: 172.31.252.10
Flags: sparse,spt
Group: 235.3.1.2
Source: *
RP: 172.31.255.15
Group: 235.3.1.2
Source: 172.31.252.10
Flags: sparse,spt
Group: 235.3.1.3
Source: *
RP: 172.31.255.15
Group: 235.3.1.3
Source: 172.31.252.10
Flags: sparse,spt
. . .
Group: 235.3.1.15
Source: *
RP: 172.31.255.15
Group: 235.3.1.15
Source: 172.31.252.10
Flags: sparse,spt
577

Interface
IP
ge-1/2/1.1
4
ge-1/2/1.2
4
ge-1/2/5.0
4
ge-1/3/5.42
4
578
V Mode
2
2
2
2
Option
HPLGT
HPLGT
HPLGT
HPLGT
Uptime
1w6d8h
1w6d8h
1w1d9h
1w6d3h
Neighbor addr
172.16.3.33
172.16.3.37
172.16.3.1
172.16.3.10
4. Verify that groups are established with the upstream interface to the Layer 3 VPN
service provider (ge-1/2/5) and downstream interfaces to the branch LAN (ge-1/3/5).
Group: 235.3.1.1
Source: 172.31.252.10/32
ge-1/3/5.42
Route state: Active
Uptime: 01:30:26
Group: 235.3.1.2
Source: 172.31.252.10/32
ge-1/3/5.42
Route state: Active
Uptime: 01:30:26
Group: 235.3.1.3
Source: 172.31.252.10/32
ge-1/3/5.42
Route state: Active
Uptime: 01:30:26
Group: 235.3.1.4
Source: 172.31.252.10/32
ge-1/3/5.42
Route state: Active
579

Uptime: 01:30:26
Group: 235.3.1.5
Source: 172.31.252.10/32
ge-1/3/5.42
Route state: Active
Uptime: 01:30:26
. . .
Group: 235.3.1.15
Source: 172.31.252.10/32
ge-1/3/5.42
Route state: Active
Uptime: 01:30:26
rendezvous point.
0.0.0.0/0
Protocol: BGP
580

address-family INET
RP: 172.31.255.15
Mode: Sparse
Holdtime: 0
Device Index: 137
Subunit: 32769
Group Ranges:
224.0.0.0/4
235.3.1.1
235.3.1.2
235.3.1.3
235.3.1.4
235.3.1.5
235.3.1.6
235.3.1.7
235.3.1.8
235.3.1.9
235.3.1.10
235.3.1.11
235.3.1.12
235.3.1.13
235.3.1.14
235.3.1.15
581

Step-by-Step
Procedure
1.
[edit]
[edit]
[edit]
set queue 4 Video
set queue 5 Voice
2.

[edit]
582

[edit]
[edit]
[edit]
583
3.

[edit]
[edit]
set priority low
[edit]
[edit]
[edit]
set priority high
f.

[edit]
[edit]
584
set priority high

4.

[edit]
5.
Create a traffic control profile for use on the transport to Service Provider A.
[edit]
6.
Apply CoS on the WAN transport interface to Service Provider A.

[edit]
7.

[edit]
585
Step-by-Step
Procedure
1.
user@branch1 show class-of-service traffic-control-profile
2.
Verify CoS on the WAN transport interface.

Object
Name
Type
Rewrite
dscp
Classifier
9
Classifier
ip
13
3.
Index
51863
Verify CoS on the branch LAN interfaces.

Object
Name
Type
Classifier
DSCP-BA
dscp
Classifier
9
4.
Index
961

Object
Name
Rewrite
video-af
Classifier
Video
4
Type
dscp
fixed
Index
35765

Object
Name
Rewrite
voice-ef
Classifier
Voice
5
Type
dscp
fixed
Index
28463
Verify CoS queues on the branch LAN.

Description: --- To Emulated IXIA branches (eon ge-0/0/32) --Forwarding classes: 16 supported, 7 in use
Queued:
Packets
:
13760948671
20525 pps
Bytes
:
5076881876090
60628576 bps
586
Transmitted:
Packets
:
13760948671
Bytes
:
5076881876090
0
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
RED-dropped bytes
:
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
Queued:
Packets
:
0
Bytes
:
0
Transmitted:
Packets
:
0
Bytes
:
0
0
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
RED-dropped bytes
:
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
Queued:
Packets
:
852367
Bytes
:
453459244
Transmitted:
Packets
:
852367
Bytes
:
453459244
0
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
RED-dropped bytes
:
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
Queued:
Packets
:
1000267940
Bytes
:
276237601824
Transmitted:
Packets
:
1000267940
Bytes
:
276237601824
0
0
Low
:
0
Medium-low
:
0
20525
60628576
0
0
0
0
0
0
0
0
0
0
0
pps
bps
pps
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
0 pps
0 bps
0
0
0
0
0
0
0
0
0
0
0
0
0
pps
bps
pps
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
0 pps
0 bps
0
0
0
0
0
0
0
0
0
0
0
0
0
pps
bps
pps
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
1501 pps
3315584 bps
1501
3315584
0
0
0
0
pps
bps
pps
pps
pps
pps
587
Medium-high
:
0
High
:
0
RED-dropped bytes
:
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
Queued:
Packets
:
1064756
Bytes
:
566450192
Transmitted:
Packets
:
1064756
Bytes
:
566450192
0
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
RED-dropped bytes
:
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
Queued:
Packets
:
1581547
Bytes
:
234068956
Transmitted:
Packets
:
1581547
Bytes
:
234068956
0
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
RED-dropped bytes
:
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
Queued:
Packets
:
9617920
Bytes
:
1142330558
Transmitted:
Packets
:
9617920
Bytes
:
1142330558
0
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
RED-dropped bytes
:
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
588
0
0
0
0
0
0
0
pps
pps
bps
bps
bps
bps
bps
0 pps
0 bps
0
0
0
0
0
0
0
0
0
0
0
0
0
pps
bps
pps
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
0 pps
0 bps
0
0
0
0
0
0
0
0
0
0
0
0
0
pps
bps
pps
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
7 pps
6304 bps
7
6304
0
0
0
0
0
0
0
0
0
0
0
pps
bps
pps
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
5.
Verify CoS queues on the WAN transport interface.

Description: --- To MPLS_VPN_PROVIDER1 link (Jbeer ge-7/0/5) --Forwarding classes: 16 supported, 7 in use
Queued:
Packets
:
10285584300
13000
Bytes
:
4918461302474
49266784
Transmitted:
Packets
:
10285584300
13000
Bytes
:
4918461302474
49266784
0
0
0
0
Low
:
0
0
Medium-low
:
0
0
Medium-high
:
0
0
High
:
0
0
RED-dropped bytes
:
0
0
Low
:
0
0
Medium-low
:
0
0
Medium-high
:
0
0
High
:
0
0
Queued:
Packets
:
0
0
Bytes
:
0
0
Transmitted:
Packets
:
0
0
Bytes
:
0
0
0
0
0
0
Low
:
0
0
Medium-low
:
0
0
Medium-high
:
0
0
High
:
0
0
RED-dropped bytes
:
0
0
Low
:
0
0
Medium-low
:
0
0
Medium-high
:
0
0
High
:
0
0
Queued:
Packets
:
1582743876
2000
Bytes
:
772379009368
7808000
Transmitted:
Packets
:
1582743876
2000
Bytes
:
772379009368
7808000
0
0
0
0
Low
:
0
0
Medium-low
:
0
0
Medium-high
:
0
0
High
:
0
0
RED-dropped bytes
:
0
0
Low
:
0
0
Medium-low
:
0
0
Medium-high
:
0
0
pps
bps
pps
bps
pps
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
pps
bps
pps
bps
pps
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
pps
bps
pps
bps
pps
pps
pps
pps
pps
pps
bps
bps
bps
bps
589
High
:
Queued:
Packets
:
Bytes
:
Transmitted:
Packets
:
Bytes
:
Low
:
Medium-low
:
Medium-high
:
High
:
RED-dropped bytes
:
Low
:
Medium-low
:
Medium-high
:
High
:
Queued:
Packets
:
Bytes
:
Transmitted:
Packets
:
Bytes
:
Low
:
Medium-low
:
Medium-high
:
High
:
RED-dropped bytes
:
Low
:
Medium-low
:
Medium-high
:
High
:
Queued:
Packets
:
Bytes
:
Transmitted:
Packets
:
Bytes
:
Low
:
Medium-low
:
Medium-high
:
High
:
RED-dropped bytes
:
Low
:
Medium-low
:
Medium-high
:
High
:
Queued:
Packets
:
Bytes
:
Transmitted:
Packets
:
590
0 bps
2374123893
854683894096
3000 pps
8640000 bps
2374123893
854683894096
0
0
0
0
0
0
0
0
0
0
0
3000
8640000
0
0
0
0
0
0
0
0
0
0
0
1978434961
965475248321
2500 pps
9760608 bps
1978434961
965475248321
0
0
0
0
0
0
0
0
0
0
0
2500
9760608
0
0
0
0
0
0
0
0
0
0
0
2967253687
308595411083
3750 pps
3120192 bps
Critical_Data
pps
bps
pps
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
Video
pps
bps
pps
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
Voice
2967253687
308595411083
0
0
0
0
0
0
0
0
0
0
0
Network_Control
3750
3120192
0
0
0
0
0
0
0
0
0
0
0
pps
bps
pps
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
1187393893
275434845733
1499 pps
2783680 bps
1187393893
1499 pps
Bytes
RED-dropped packets
Low
Medium-low
Medium-high
High
RED-dropped bytes
Low
Medium-low
Medium-high
High
:
:
:
:
:
:
:
:
:
:
:
:
275434845733
0
0
0
0
0
0
0
0
0
0
0
2783680
0
0
0
0
0
0
0
0
0
0
0
bps
pps
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
591

The VPN termination role at Aggregation Hub 2 handles termination of the IPsec over
GRE tunnels for the backup Internet transport. To configure the VPN termination role at
Aggregation Hub 2:
Configuring WAN Transport Security on the VPN Termination Role at Hub 2 on page 592
Configuring Dynamic Endpoints for IPsec Tunnels on the VPN Termination Role at Hub
2 on page 594
Configuring the Overlay WAN Transport on the VPN Termination Role at Role at Hub
2 on page 596
Configuring the Transport Routing Instances on the VPN Termination Role at Hub
2 on page 597
Configuring Private Overlay Routing on the VPN Termination Role at Hub 2 on page 598
Configuring Link-Level High Availability on the VPN Termination Role at Hub

2 on page 599
Configuring Multicast on the VPN Termination Role at Hub 2 on page 599
Applying CoS to the Tunnel Interfaces on the VPN Termination Role at Hub 2 on page 600
Configuring WAN Transport Security on the VPN Termination Role at Hub 2

Step-by-Step
Procedure
IPsec is used to secure the GRE tunnels between the branch and the aggregation hub.
The WAN transport security configuration consists of an IKE configuration for IPsec phase
1 negotiation and an IPsec configuration for phase 2 negotiation.
1.
router.
[edit]
set dh-group group2
[edit]
set mode main
2.

[edit]
592
set protocol esp


[edit]
593
Configuring Dynamic Endpoints for IPsec Tunnels on the VPN Termination Role
at Hub 2
Step-by-Step
Procedure
Dynamic endpoint IPsec is used to reduce the configuration and changes required when
a new branch comes online. You need to configure dynamic endpoints only once at the
aggregation hub.
1.

the GRE tunnel.
for the session.
[edit]
set ike ike-policy ike-phase1-policy
set ike interface-id IPsec_Clients_Group1
2.
multiple tunnels.
[edit]
594
3.
[edit interfaces sp-1/0/0] hierarchy.

[edit]
595
Hub 2
Step-by-Step
Procedure
1.
interfaces.
[edit]
2.
[edit]
3.
[edit]
596
Configuring the Transport Routing Instances on the VPN Termination Role at Hub
2
Step-by-Step
Procedure
instances:
VPNA public Internet-facing instance. This instance terminates IPsec tunnels.
an IBGP peer with the IPsec tunnel at the branch.
1.
Configure the VPN virtual router routing instance.

a. Add IPsec interfaces and the loopback interface to the VPN routing instance.
The loopback interfaces is the remote endpoint for the branch. The address of
the loopback interface is used on the IPsec tunnels.
[edit]
set interface lo0.3
2.
Configure the WAN-GRE virtual router routing instance.

a. Add the GRE tunnel interfaces to the WAN-GRE routing instance. Create a logical
unit for the number of GRE tunnels that can be formed to the branch. Add the
loopback interface for the GRE tunnels. The loopback interface address is used
as the GRE tunnel source address.
[edit]
set interface lo0.4
597
Configuring Private Overlay Routing on the VPN Termination Role at Hub 2

Step-by-Step
Procedure
Routing for the WAN transport is in the WAN-GRE routing instance. The routing in this
instance includes routing adjacencies over the GRE tunnel and to the WAN aggregation
1.
Create an IBGP peer group for IPv4 to have a peer relationship with the remote GRE
tunnel endpoint at the branch.
The ADV_DEFAULT policy causes BGP to advertise only the default route to the
branches.
route reflector.
[edit]
set type internal
set passive
set out-delay 450
set authentication-key "$9$PTF6p01ylvdbkmfTn6rlK"
set cluster 0.0.0.3
set neighbor 172.16.2.6 description
2.
Create an IBGP peer group for IPv6 to have a peer relationship with the remote GRE
tunnel endpoint at the branch.
The ADV_DEFAULT-V6 policy causes BGP to advertise only the default route to the
branches.
route reflector.
[edit]
edit routing-instances WAN-GRE protocols bgp group IBGPoGRE-V6
set type internal
set passive
set out-delay 450
set cluster 0.0.0.4
set neighbor 2001:DB8:2:4::2 authentication-key "$9$-WbY4UjkTznO1XNdbg4Qz3"
598
Configuring Link-Level High Availability on the VPN Termination Role at Hub 2

Step-by-Step
Procedure
availability.
1.

[edit]
2.
In the IBGP peer group to the remote end of the GRE tunnel at the branch, add the
following statements:
[edit]
Configuring Multicast on the VPN Termination Role at Hub 2

Step-by-Step
Procedure
1.
Add the GRE tunnels to the multicast configuration at the hub.
[edit]
599
Applying CoS to the Tunnel Interfaces on the VPN Termination Role at Hub 2
Step-by-Step
Procedure
support per-unit GRE scheduling. To work around this, we are configuring CoS on logical
tunnel (lt) interfaces on the MX Series router. The lt interfaces apply CoS to egress traffic
before it is sent over the GRE tunnels to the branch.
1.
Apply the scheduler map to the GRE tunnel interfaces. The scheduler map is
configured in the Aggregation Hub 2 base configuration.
[edit]
2.
[edit]
3.
Apply the traffic control profile to the logical tunnel that is used for scheduling and
queueing.
[edit]
600
Configuring Branch Router 2 for Secondary Internet Transport
Configuring the Physical WAN Transport on Branch Router 2 on page 606
Configuring the Internet WAN Transport Routing on Branch Router 2 on page 606
Configuring the WAN Transport Routing Protocol on Branch Router 2 on page 608
Configuring the Internet WAN Transport Security on Branch Router 2 on page 610
Configuring the Overlay WAN Transport on Branch Router 2 on page 613
Configuring OSPF for the Branch LAN on Branch Router 2 on page 618
Configuring OSPF Routing Between Branch Routers on Branch Router 2 on page 621

Step-by-Step
Procedure
1.
[edit]
edit policy-options
set prefix-list IPsec-Servers 192.0.2.0/24
2.

[edit]
set then discard
3.
601
interface specific.
[edit]
b. Create a term for IPsec traffic.
[edit]
set term IPsec from source-prefix-list IPsec-Servers
set term IPsec then policer limit-150k
c. Create a term for BGP traffic.
[edit]
d. Create a term that accepts traffic from trusted PIM neighbors.
[edit]
e. Create a term that accepts OSPF traffic from trusted OSPF neighbors.
[edit]
f.

[edit]
602

g. Create a term for SNMP traffic.
[edit]
h. Create a term for ICMP traffic, which includes IPv4 error messages.
[edit]
i.
Create a term for VRRP traffic.

[edit]
j.
[edit]
k. Create a term that accepts TCP and TACACS traffic from trusted network
management systems.
[edit]
603

l.
management systems.
[edit]
m. Create a term that accepts UDP traffic from trusted neighbors.
[edit]
n. Create a term for incoming traffic with a source and destination loopback address.
[edit]
o. Configure a term that prevents small packet attacks.
[edit]
p. Configure a term that prevents fragment attacks.
[edit]
q. Configure a term that explicitly discards all other traffic.
604
[edit]
4.

[edit]
5.

[edit]
commit
Results

user@branch2> show firewall filter RE-PROTECTION-lo0.0-i
Counters:
Name
Bytes
IPsec-lo0.0-i
0
accept-bfd-lo0.0-i
0
access-in-lo0.0-i
2034742
bgp-in-lo0.0-i
167526
frag-attack-lo0.0-i
0
icmp-in-lo0.0-i
29148
igmp-lo0.0-i
411764
16820785
loopback-in-lo0.0-i
0
ospf-in-lo0.0-i
6612460
pim-lo0.0-i
845154
radius-lo0.0-i
0
0
snmp-in-lo0.0-i
163465
tacacs-lo0.0-i
0
udp-in-lo0.0-i
89489960
vrrp-lo0.0-i
680
Policers:
Name
Bytes
limit-150k-IPsec-lo0.0-i
0
0
0
0
0
0
0
0
0
Packets
0
0
36444
2055
0
347
12708
82603
0
82705
15651
0
0
1922
0
545672
17
Packets
0
0
0
0
0
0
0
0
0
605

Step-by-Step
Procedure

[edit]
Configuring the Physical WAN Transport on Branch Router 2

Step-by-Step
Procedure
1.
Configure the physical interface to the Internet service provider.

[edit]
set description "--- To Public ISP link ---"
set unit 0 family inet filter input v4_sample_filter
2.

[edit]
commit
Results
Verify that the physical transport to the Internet service provider is up:
Interface
Admin Link Proto
Local
ge-0/0/1
up
up
ge-0/0/1.0
up
up
inet
3.3.0.2/30
multiservice
Remote
Configuring the Internet WAN Transport Routing on Branch Router 2

Step-by-Step
Procedure
Configure the virtual routing instance for Internet traffic. The routing instance does not
allow traffic to the branch LAN from the Internet, and it protects the internal branch
routing tables. It includes the EBGP peer group between the branch and Service Provider
B.
1.
Unit 0 is used in the default routing instance, and is used with the branch LANs.
Unit 1 is used in the VPN termination routing instance, and is used for the
connections to the aggregation hub.
[edit]
edit interfaces lo0
set unit 0 description "--- Default Routing instance ---"
2.

[edit]
606

3.
Configure the routing instance and add the Internet-facing interfacesthe Ethernet
interface to the Internet service provider, unit 0 of the loopback interface, and the
IPsec interfaces.
[edit]
set interface lo0.0
4.
Aggregation Hub 2. This route is used to establish GRE tunnels.
[edit]
5.
Configure the AS number for the VPN virtual router.

[edit]
set routing-options autonomous-system 64513
6.
Create an EBGP peer group to the Internet Service Provider gateway.

[edit]
edit routing-instances VPN protocols bgp
set group To_AS_69 type external
set group To_AS_69 peer-as 69
set group To_AS_69 neighbor 3.3.0.1
7.

[edit]
commit
Results
1.
Verify that the Internet service provider gateway is reachable from the VPN routing
instance.
user@branch2> ping 3.3.0.1 routing-instance VPN count 5
PING 3.3.0.1 (3.3.0.1): 56 data bytes
ms
ms
ms
ms
ms
607
routing table for the VPN routing instance.

user@branch2> show route table VPN.inet.0
0.0.0.0/0
3.3.0.0/30
3.3.0.2/32
172.16.3.253/32
172.31.255.231/32
*[BGP/170] 2w0d 02:51:37, localpref 100

> to 3.3.0.1 via ge-0/0/1.0
*[Direct/0] 2w0d 02:51:41
> via ge-0/0/1.0
*[Local/0] 2w0d 02:52:11
*[Direct/0] 2w0d 02:52:58
> via lo0.0
*[Static/5] 2w0d 02:51:36
> via sp-0/1/0.1
Configuring the WAN Transport Routing Protocol on Branch Router 2

Step-by-Step
Procedure
1.
Configure the AS number.

[edit]
2.
Configure BGP routing policies.

a. Configure IPv4 and IPv6 policies that are used to accept only default routes.
[edit]
[edit]
b. Configure policies that are used to control IPv4 and IPv6 routes that are
advertised to the aggregation hub.

These policies prevent the default static route from being advertised and allow
[edit]
608
[edit]
3.
Configure IBGP peer groups for GRE tunnels.

a. Configure an IPv4 and IPv6 IBPG peer groups to the remote end of the GRE
tunnel.
The ACCEPT_DEFAULT import policies accept only the default route from the
hub, which prevents routes from other branches from being distributed to the
branch.
The BRANCH-PREFIX export policies control default route advertisement to the
hub. They prevents default routes learned by another protocol from being
advertised to the hub, and cause the loopback address of the branch router to
[edit]
set type internal
set neighbor 172.16.3.5 authentication-key "$9$pKaKOIhev8dbYDi9tuOEhVbs"
[edit]
edit protocols bgp group IBGPoGRE-H2-V6
set type internal
set neighbor 2001:DB8:3:4::1 authentication-key "$9$DNH.f36CBIhWLJUjHPf1IE"
4.

[edit]
commit
Results
1.
Verify BGP peering to the Internet service provider gateway (3.3.0.1) and to the remote
GRE tunnel endpoint (172.16.3.5).
Table
inet6.0
1
0
0
0
inet.0
1
0
0
0
History Damp State
Pending
609
Peer
AS
InPkt
OutPkt
3.3.0.1
69
978
977
Establ
VPN.inet.0: 1/1/1/0
172.16.3.5
65530
891
1080
Establ
inet.0: 0/1/1/0
2001:DB8:3:4::1
65530
917
1112
Establ
inet6.0: 0/1/1/0
OutQ
Flaps Last Up/Dwn
4:00:43
4:00:35
17
3:56:31
2. Verify that default routes to the Layer 3 VPN transport have a higher preference than
routes to the GRE tunnels.

user@branch2> show route table inet.0 protocol bgp
0.0.0.0/0
*[BGP/170] 07:01:31, localpref 200

> to 3.3.0.1 via ge-0/0/1.0
> to 172.16.3.5 via gr-1/2/0.1
Configuring the Internet WAN Transport Security on Branch Router 2

Step-by-Step
Procedure
IPsec is used to secure the GRE tunnels between the branch and the aggregation hub.
The WAN transport security configuration consists of an Internet Key Exchange (IKE)
configuration for IPsec phase 1 negotiation and an IPsec configuration for phase 2
negotiation.
1.
For IKE phase 1 negotiation, configure an Internet Key Exchange (IKE) proposal and
policy and define the IPsec peer (gateway) at the remote end of the tunnel with
which IKE is negotiated.

[edit]
set dh-group group2
[edit]
set mode main
610

2.
[edit]
set protocol esp

[edit]
c. Configure an IPsec rule.
The destination address is the address of the GRE tunnel interface at the
aggregation hub.
The remote gateway is the address of the logical tunnel (lt) interface in the VPN
routing instance at Aggregation Hub 2.
The source and destination and destination addresses must match the proxy
identity values set in the IPsec_Clients_Group1 IKE access profile configured on
the VPN termination router at the aggregation hub.
The remote gateway is the address of the logical tunnel interface (lt-5/1/0.53)
in the VPN routing instance at Aggregation Hub 2.
[edit]
edit services ipsec-vpn rule To_ hub_2
set term 1 from source-address 172.16.3.253/32
set term 1 from destination-address 172.31.255.231/32
set term 1 then remote-gateway 191.15.200.6
set term 1 then dynamic ike-policy ike-phase1-policy
set term 1 then dynamic ipsec-policy dynamic_ipsec_policy
3.
Configure a next-hop style service set for IPsec interfaces.
The inside and outside IPsec interfaces must match the inside and outside service
domain configuration at the [edit interfaces sp-0/3/0] hierarchy.
The local gateway is the Ethernet interface to the Internet service provider.
Specify that the local gateway is in the VPN routing instance.

[edit]
611
edit services service-set To_HUB2

set ipsec-vpn-rules To_ hub_2
4.
Enable the establishment of tunnels on receipt of traffic.

[edit]
edit services ipsec-vpn
set establish-tunnels on-traffic
5.

[edit]
commit
Results
1.
Verify the reachability of the IKE gateway at the aggregation hub.

user@branch2> show route 192.0.2.6 table VPN.inet.0
0.0.0.0/0
*[BGP/170] 1d 08:57:38, localpref 100

> to 3.3.0.1 via ge-0/0/1.0
user@branch2> ping 192.0.2.6 routing-instance VPN count 5

PING 192.0.2.6 (192.0.2.6): 56 data
bytes
ttl=60
ttl=60
ttl=60
ttl=60
ttl=60
time=0.947
time=0.887
time=0.898
time=0.909
time=0.912
ms
ms
ms
ms
ms
2. Verify IKE security associations for Aggregation Hub 2 (192.0.2.6).
user@branch2> show services ipsec-vpn ike security-associations
Initiator cookie Responder cookie Exchange
type
192.0.2.6
Matured
7ffbae9a3390cf44 1bde5696e787e293 Main
user@branch> show services ipsec-vpn ike security-associations detail
IKE peer 192.0.2.6
Role: Initiator, State: Not matured
Initiator cookie: 3899eb82a73f87ab, Responder cookie: 0000000000000000
Local: 3.3.0.2, Remote: 192.0.2.6
Algorithms:
Authentication
: Encryption
: Pseudo random function: Traffic statistics:
Input bytes :
0
Output bytes :
784
612
Input packets:
0
Output packets:
4
Flags: Waiting for done
3. Verify IPsec security associations for Aggregation Hub 2 (192.0.2.6).
user@branch2> show services ipsec-vpn ipsec security-associations To_HUB2
Service set: To_HUB2, IKE Routing-instance: VPN
Rule: To_ hub_2, Term: 1, Tunnel index: 1
Direction SPI
AUX-SPI
Mode
Type
inbound
3403657556 0
tunnel
dynamic
outbound 1814204950 0
tunnel
dynamic
Protocol
ESP
ESP
user@branch2> show services ipsec-vpn ipsec security-associations extensive

Service set: To_HEAD-END1, IKE Routing-instance: VPN
Rule: To_ hub_2, Term: 1, Tunnel index: 1
Configuring the Overlay WAN Transport on Branch Router 2

Step-by-Step
Procedure
Create GRE tunnel interfaces to the aggregation hub.
1.

[edit]
613

2.

[edit]
commit
Results
1.
Verify that the GRE tunnel destination to Aggregation Hub 2 is reachable.

Note that the default route to Aggregation Hub 1 over the Ethernet interface to the
Layer 3 VPN is active, but the default route to Aggregation Hub 2 over the GRE tunnel
is not active. The route to the Layer 3 VPN is active because it has a higher local
preference than the GRE tunnel. The default route over the GRE tunnel becomes
active only if the route to the Layer 3 VPN goes down.
0.0.0.0/0
*[BGP/170] 00:05:26, localpref 200

> to 172.16.2.1 via ge-0/0/2.0
> to 172.16.2.5 via gr-0/2/0.2

172.31.255.231/32
*[Static/5] 1w3d 07:05:06

> via sp-0/3/0.10
user@branch3> ping 172.31.255.231 source 172.16.3.253 routing-instance VPN count 5

PING 172.31.255.231 (172.31.255.231): 56 data bytes
2. Verify that the GRE interfaces are up, and that the interface destinations to the
aggregation hub are reachable.

user@branch3> show interfaces gr-1/2/0 terse
Interface
Admin Link Proto
gr-1/2/0
up
up
gr-1/2/0.1
up
up
inet
inet6
Local
Remote
172.16.3.6/30
fe80::2a0:a514:72:5a85/64
2001:DB8:3:4::2/64

PING 172.16.2.5 (172.16.2.5): 56 data bytes
!!!!!
614
3. Verify that traffic is flowing from the GRE tunnels to the aggregation hub, and verify
that ToS Byte reflection is on.

user@branch2> show interfaces gr-1/2/0
Device flags
: Present Running
Input rate : 896 bps (2 pps)
Output rate : 896 bps (2 pps)
Copy-tos-to-outer-ip-header: On
Destination: fe80::/64, Local: fe80::2a0:a514:72:5a85
interfaces are up.

user@branch2> show interfaces terse sp-0/1/0
Interface
Admin Link Proto
sp-0/1/0
up
up
sp-0/1/0.0
up
up
inet
sp-0/1/0.1
up
up
inet
sp-0/1/0.2
up
up
inet
Local
Remote

user@branch2> show interfaces sp-0/1/0
Type: Adaptive-Services, Link-level type: Adaptive-Services, MTU: 9192,
Speed: 1000mbps
Device flags
: Present Running
Interface flags: Point-To-Point SNMP-Traps Internal: 0x4000
Link type
: Full-Duplex
Link flags
: None
Last flapped
: 2013-08-23 05:16:58 PDT (10:12:14 ago)
Input rate
: 216 bps (0 pps)
Output rate
: 192 bps (0 pps)
615

Input packets : 0
Output packets: 0
Input packets : 0
Output packets: 0
Addresses, Flags: Is-Primary
Local: 172.16.3.249
Input packets : 0
Output packets: 0
Flags: Receive-options, Receive-TTL-Exceeded

Step-by-Step
Procedure
voice.
1.
Configure the interface, and enable VLAN tagging. .

[edit]
set vlan-tagging
2.

[edit]
set description "--- Data VLAN 42---"
set vlan-id 42
3.
616
[edit]
set vlan-id 52
4.

[edit]
set description "--- To VOICE VLAN 62 ---"
set vlan-id 62
5.

[edit]
commit
Results

Description: ( --- To branche LAN)
MAC-REWRITE Error: None, Loopback: Disabled, Source filtering: Disabled, Flow
control: Enabled,
Auto-negotiation: Enabled, Remote fault: Online
Device flags
: Present Running
CoS queues
Current address: 5c:5e:ab:fe:e8:00, Hardware address: 5c:5e:ab:fe:e8:00
Last flapped
: 2013-08-23 05:17:22 PDT (10:25:09 ago)
Input rate
: 6128 bps (9 pps)
Output rate
: 2448 bps (3 pps)
Ingress rate at Packet Forwarding Engine
: 6128 bps (9 pps)
Ingress drop rate at Packet Forwarding Engine : 0 bps (0 pps)
Description: --- To Data VLAN 42 --Flags: SNMP-Traps 0x4000 VLAN-Tag [ 0x8100.42 ] Encapsulation: ENET2
Flags: Is-Primary
Destination: fe80::/64, Local: fe80::5e5e:ab00:2afe:e800
617

Description: --- To VIDEO VLAN 52 --Flags: SNMP-Traps 0x4000 VLAN-Tag [ 0x8100.52 ] Encapsulation: ENET2
Destination: fe80::/64, Local: fe80::5e5e:ab00:34fe:e800
Description: --- To VOICE VLAN 62 --Flags: SNMP-Traps 0x4000 VLAN-Tag [ 0x8100.62 ] Encapsulation: ENET2
Destination: fe80::/64, Local: fe80::5e5e:ab00:3efe:e800
Input packets : 0
Output packets: 0
Flags: None
Configuring OSPF for the Branch LAN on Branch Router 2

Step-by-Step
Procedure
1.
[edit]
2.
[edit]
3.

[edit]
618
commit
Results

Address
Interface
172.16.3.11
ge-0/0/0.42
172.16.3.19
ge-0/0/0.52
172.16.3.27
ge-0/0/0.62
State
Full
Full
Full

ID
Interface
State
172.16.3.255
ge-0/0/0.42
Full
Neighbor-address fe80::5e5e:ab00:2a0e:451d
172.16.3.255
ge-0/0/0.52
Full
Neighbor-address fe80::5e5e:ab00:340e:451d
172.16.3.255
ge-0/0/0.62
Full
Neighbor-address fe80::5e5e:ab00:3e0e:451d
ID
172.16.3.255
172.16.3.255
172.16.3.255
Pri
128
Dead
33
128
34
128
38
Pri
128
128
128
Dead
38
36
31

Step-by-Step
Procedure
Results
1.

[edit]
set description "--- To Branch Router 2 ---"
set vlan-tagging
set unit 1 description "--- OSPF Area 0 vlan ---"
set unit 2 description "--- OSPF Area 1 vlan ---"
Verify that the LAN interface to Branch 1 is up.

Interface
Admin Link Proto
ge-0/0/2
up
up
ge-0/0/2.1
up
up
inet
inet6
ge-0/0/2.2
up
up
ge-0/0/2.32767
up
up
Local
Remote
172.16.3.33/30
fe80::5e5e:ab00:1fe:e802/64
2001:DB8:3:2::1/64
multiservice
inet
172.16.3.37/30
inet6
fe80::5e5e:ab00:2fe:e802/64
2001:DB8:3:22::1/64
multiservice
multiservice

Description: --- To intra branch router B2B link (ge-1/2/1) --Link-level type: Ethernet, MTU: 1518, Speed: 1000mbps, BPDU Error: None,
619

Device flags
: Present Running
CoS queues
Current address: 5c:5e:ab:fe:e8:02, Hardware address: 5c:5e:ab:fe:e8:02
Last flapped
: 2013-07-04 06:05:59 PDT (2w0d 02:21 ago)
Input rate
: 0 bps (0 pps)
Output rate
: 816 bps (1 pps)
Ingress rate at Packet Forwarding Engine
: 0 bps (0 pps)
Ingress drop rate at Packet Forwarding Engine : 0 bps (0 pps)
Input packets : 0
Output packets: 0
Flags: None
620
Configuring OSPF Routing Between Branch Routers on Branch Router 2

Step-by-Step
Procedure
We are using an OSPF backbone area between the two branch routers. Default BGP
routes are exported to OSPF. This configuration is required for failover scenarios where
the link from Branch router 1 and the Layer 3 VPN service provider goes down. Traffic is
rerouted to Branch router 2 and then to Aggregation Hub 2. In this case, Branch router 2
receives the routes that it needs from OSPF.
1.
Configure IPv4 and IPv6 routing policies that are used to export default BGP routes
into OSPF. Set the external metric type for routes exported by OSPF to 1.
When OSPF exports routes from external ASs, it includes a cost, or external metric,
in the route. The metric type determines how OSPF calculates the cost of the route.
Type 1 external metrics are equivalent to the link-state metric, where the cost is
equal to the sum of the internal costs plus the external cost. This means that Type
1 external metrics include the external cost to the destination as well as the cost
(metric) to reach the AS boundary router.
[edit]
[edit]
2.

a. Apply the BGP2OSPF export policy.
[edit]
edit protocols ospf
set export BGP2OSPF
b. Create a backbone area. The OSPF backbone area contains the point-to-point
interface and the loopback interface between Branch router 1 and Branch router
2.
[edit]
set interface lo0.0
621
c. Add the unit 2 of the Ethernet interface that connects to Branch router 2 to Area
1.
[edit]
3.

a. Apply the BGP2OSPF-V6 export policy.
[edit]
4.
Create a backbone area. The OSPF backbone area contains the point-to-point
interface and the loopback interface between Branch router 1 and Branch router 2.
[edit]
set interface lo0.0
5.
[edit]
6.

[edit]
commit
Step-by-Step
Procedure
Verify that OSPF is running between the branch routers.

Address
Interface
172.16.3.34
ge-0/0/2.1
172.16.3.11
ge-0/0/0.42
172.16.3.19
ge-0/0/0.52
172.16.3.27
ge-0/0/0.62
172.16.3.38
ge-0/0/2.2
State
Full
Full
Full
Full
Full

ID
Interface
State
172.16.3.255
ge-0/0/0.42
Full
Neighbor-address fe80::5e5e:ab00:2a0e:451d
172.16.3.255
ge-0/0/0.52
Full
Neighbor-address fe80::5e5e:ab00:340e:451d
172.16.3.255
ge-0/0/0.62
Full
Neighbor-address fe80::5e5e:ab00:3e0e:451d
172.16.3.255
ge-0/0/2.2
Full
Neighbor-address fe80::5e5e:ab00:20e:4501
622
ID
172.16.3.255
172.16.3.255
172.16.3.255
172.16.3.255
172.16.3.255
Pri
128
Dead
32
128
34
128
33
128
35
Pri
128
128
128
128
128
Dead
36
36
36
39
39

Step-by-Step
Procedure
availability.
BFD with IBGP for GRE tunnels to detect failures over the GRE tunnels.
1.
Add dead peer detection to the To_hub_2 IPsec rule.

[edit]
edit services ipsec-vpn rule To_hub_2
set term 1 then initiate-dead-peer-detection
set term 1 then dead-peer-detection interval 20
set term 1 then dead-peer-detection threshold 5
2.
In the IBGP peer group to the remote end of the GRE tunnel at the aggregation hub,
add the following statements:
[edit]
3.

[edit]
commit
Results
Verify active BFD sessions on GRE tunnels.

Address
172.16.1.1
172.16.1.5
State
Up
Up
Interface
gr-0/0/0.1
gr-0/0/0.2
Detect
Time
1.500
1.500
Transmit
Interval
0.500
0.500
Multiplier
3
3
623

Step-by-Step
Procedure
On the data interface, set the priority cost for becoming the master default router. The
router with the highest priority within the group becomes the master.
1.
[edit]
set vrrp-group 10 priority-cost 20
[edit]
edit interfaces ge-0/0/0 unit 42 family inet6 address fec0:16:3:42::2/64
set vrrp-inet6-group 10 virtual-inet6-address fec0:16:3:42::1
2.
[edit]
edit interfaces ge-0/0/0 unit 52 family inet address172.16.3.18/29
[edit]
edit interfaces ge-0/0/0 unit 52 family inet6 address fec0:16:3:52::2/64
3.
[edit]
[edit]
624
edit interfaces ge-0/0/0 unit 62 family inet6 address ec0:16:3:62::2/64

4.

[edit]
commit
Results

Interface
State
ge-0/0/0.42
up
Group
10
VR state VR Mode
backup
Active
Timer
Type
D 3.409 lcl
Address
172.16.3.10
vip
172.16.3.9
mas
ge-0/0/0.42
up
2001:DB8:3:42::2
10
backup
Active
172.16.3.11
3.541 lcl
vip
fe80::200:5eff:fe00:20a
vip
2001:DB8:3:42::1
mas
fe80::5e5e:ab00:2a0e:451d
ge-0/0/0.52
up
ge-0/0/0.52
up
2001:DB8:3:52::2
20
20
backup
backup
Active
Active
3.244 lcl
172.16.3.18
vip
172.16.3.17
mas
172.16.3.19
3.239 lcl
vip
fe80::200:5eff:fe00:214
vip
2001:DB8:3:52::1
mas
fe80::5e5e:ab00:340e:451d
ge-0/0/0.62
up
ge-0/0/0.62
up
2001:DB8:3:62::2
30
30
backup
backup
Active
Active
3.223 lcl
172.16.3.26
vip
172.16.3.25
mas
172.16.3.27
3.191 lcl
vip
fe80::200:5eff:fe00:21e
vip
2001:DB8:3:62::1
mas
fe80::5e5e:ab00:3e0e:451d
625

Step-by-Step
Procedure
1.
[edit]
[edit]
[edit]
set queue 4 Video
set queue 5 Voice
2.

[edit]
626

[edit]
627
3.

[edit]
[edit]
set priority low
[edit]
[edit]
set priority high
[edit]
set priority high
f.

[edit]
[edit]
set priority high
628
4.

[edit]
5.
Create a traffic control profile to be applied to GRE tunnels.

We are setting a shaping rate on GRE tunnels instead of a policer because the shaper
has a buffer and is more flexible than a policer, which applies a hard limit to the rate
and drops packets when a transmission rate is reached.
[edit]
edit class-of-service traffic-control-profiles internet-link
6.
Apply CoS to the interface to the Internet service provider.

[edit]
set output-traffic-control-profile internet-link
7.

[edit]
8.

[edit]
9.
[edit]
[edit class-of-service host-outbound-traffic
629
10.

This procedure enables per-unit scheduling for GRE tunnels on M7i Series routers
a. Enable per-unit CoS scheduling on GRE tunnels.
This step adds all the functionality of tunnel PICs to GRE tunnels. CoS for GRE
tunnel traffic is applied as the traffic is looped through IQ2 and IQ2E PICs. Shaping
is performed on full packets that pass through the GRE tunnel.
Include the tunnel-only statement to specify that the PIC works exclusively in
tunnel mode.
[edit]
edit chassis
set fpc 0 pic 3 tunnel-services tunnel-only
b. Enable hierarchical scheduling on the GRE tunnel interfaces.
[edit]
c. Specify that the ToS byte is to be copied from the inner IP header to the outer
header of GRE tunnels.

[edit]
11.

[edit]
commit
630
Results
1.
Verify CoS on the interface to the Internet service provider.

Object
Name
Rewrite
Classifier
Type
dscp
ip
Index
51863
13
2. Verify CoS on the GRE interface.

user@branch2> show class-of-service interface gr-1/2/0
Object
Name
Type
Traffic-control-profile internet-link
Output
Rewrite
dscp
Classifier
DSCP-BA
dscp
Index
29951
51863
961

Scheduler map: default, Index: 2
Input scheduler map: default, Index: 2
Chassis scheduler map: default-chassis, Index: 4
Object
Name
Type
Input
Output
Index
45866
45866

Object
Name
Classifier
DSCP-BA
Type
dscp
Index
961

Object
Name
Classifier
Video
Type
fixed
Index
4

Object
Name
Classifier
Voice
Type
fixed
Index
5
4. Verify CoS queues on the interface to the Internet service provider.

631
Description: --- To Public ISP link (jbeer.PE1 ge-7/0/4) --Forwarding classes: 16 supported, 7 in use
Queued:
Packets
:
25650641
23252 pps
Bytes
:
11648797616
83585856 bps
Transmitted:
Packets
:
25650641
23252 pps
Bytes
:
11648797616
83585856 bps
0
0 pps
Low
:
0
0 pps
Medium-low
:
0
0 pps
Medium-high
:
0
0 pps
High
:
0
0 pps
RED-dropped bytes
:
0
0 bps
Low
:
0
0 bps
Medium-low
:
0
0 bps
Medium-high
:
0
0 bps
High
:
0
0 bps
Queued:
Packets
:
0
0 pps
Bytes
:
0
0 bps
Transmitted:
Packets
:
0
0 pps
Bytes
:
0
0 bps
0
0 pps
Low
:
0
0 pps
Medium-low
:
0
0 pps
Medium-high
:
0
0 pps
High
:
0
0 pps
RED-dropped bytes
:
0
0 bps
Low
:
0
0 bps
Medium-low
:
0
0 bps
Medium-high
:
0
0 bps
High
:
0
0 bps
Queued:
Packets
:
0
0 pps
Bytes
:
0
0 bps
Transmitted:
Packets
:
0
0 pps
Bytes
:
0
0 bps
0
0 pps
Low
:
0
0 pps
Medium-low
:
0
0 pps
Medium-high
:
0
0 pps
High
:
0
0 pps
RED-dropped bytes
:
0
0 bps
Low
:
0
0 bps
Medium-low
:
0
0 bps
Medium-high
:
0
0 bps
High
:
0
0 bps
Queued:
Packets
:
5355
0 pps
Bytes
:
689238
0 bps
632
Transmitted:
Packets
:
5355
Bytes
:
689238
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
RED-dropped bytes
:
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
Queued:
Packets
:
0
Bytes
:
0
Transmitted:
Packets
:
0
Bytes
:
0
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
RED-dropped bytes
:
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
Queued:
Packets
:
0
Bytes
:
0
Transmitted:
Packets
:
0
Bytes
:
0
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
RED-dropped bytes
:
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
Queued:
Packets
:
0
Bytes
:
0
Transmitted:
Packets
:
0
Bytes
:
0
0
Low
:
0
Medium-low
:
0
0 pps
0 bps
0
0
0
0
0
0
0
0
0
0
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
0 pps
0 bps
0 pps
0 bps
0
0
0
0
0
0
0
0
0
0
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
0 pps
0 bps
0 pps
0 bps
0
0
0
0
0
0
0
0
0
0
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
0 pps
0 bps
0 pps
0 bps
0 pps
0 pps
0 pps
633
Medium-high
:
0
High
:
0
RED-dropped bytes
:
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
Queued:
Packets
:
18905865
Bytes
:
10345213174
Transmitted:
Packets
:
18905865
Bytes
:
10345213174
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
RED-dropped bytes
:
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
Queued:
Packets
:
0
Bytes
:
0
Transmitted:
Packets
:
0
Bytes
:
0
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
RED-dropped bytes
:
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
Queued:
Packets
:
2116907
Bytes
:
1240507502
Transmitted:
Packets
:
2116907
Bytes
:
1240507502
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
RED-dropped bytes
:
0
Low
:
0
Medium-low
:
0
634
0
0
0
0
0
0
0
pps
pps
bps
bps
bps
bps
bps
12999 pps
59533232 bps
12999 pps
59533232 bps
0
0
0
0
0
0
0
0
0
0
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
0 pps
0 bps
0 pps
0 bps
0
0
0
0
0
0
0
0
0
0
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
2000 pps
9371344 bps
2000 pps
9371344 bps
0
0
0
0
0
0
0
0
pps
pps
pps
pps
pps
bps
bps
bps
Medium-high
:
0
High
:
0
Queued:
Packets
:
3491035
Bytes
:
1558478958
Transmitted:
Packets
:
3491035
Bytes
:
1558478958
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
RED-dropped bytes
:
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
Queued:
Packets
:
2650975
Bytes
:
1553471350
Transmitted:
Packets
:
2650975
Bytes
:
1553471350
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
RED-dropped bytes
:
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
Queued:
Packets
:
3969002
Bytes
:
801738602
Transmitted:
Packets
:
3969002
Bytes
:
801738602
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
RED-dropped bytes
:
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
Queued:
Packets
:
1660667
Bytes
:
534724414
Transmitted:
0 bps
0 bps
3000 pps
10992000 bps
3000 pps
10992000 bps
0
0
0
0
0
0
0
0
0
0
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
2500 pps
11720000 bps
2500 pps
11720000 bps
0
0
0
0
0
0
0
0
0
0
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
3750 pps
6060000 bps
3750 pps
6060000 bps
0
0
0
0
0
0
0
0
0
0
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
1502 pps
3962336 bps
635
Packets
Bytes
RED-dropped packets
Low
Medium-low
Medium-high
High
RED-dropped bytes
Low
Medium-low
Medium-high
High
:
1660667
:
534724414
: Not Available
:
0
:
0
:
0
:
0
:
0
:
0
:
0
:
0
:
0
:
0
Packet Forwarding Engine Chassis Queues:

Queues: 8 supported, 7 in use
Queued:
Packets
:
44355071
Bytes
:
19118911190
Transmitted:
Packets
:
44355072
Bytes
:
19118911680
0
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
RED-dropped bytes
:
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
Queued:
Packets
:
0
Bytes
:
0
Transmitted:
Packets
:
0
Bytes
:
0
0
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
RED-dropped bytes
:
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
Queued:
Packets
:
2113282
Bytes
:
1200344176
Transmitted:
Packets
:
2113282
Bytes
:
1200344176
0
0
636
1502 pps
3962336 bps
0
0
0
0
0
0
0
0
0
0
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
36250 pps
123403968 bps
36250
123405056
0
0
0
0
0
0
0
0
0
0
0
pps
bps
pps
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
0 pps
0 bps
0
0
0
0
0
0
0
0
0
0
0
0
0
pps
bps
pps
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
2000 pps
9088000 bps
2000
9088000
0
0
pps
bps
pps
pps
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
RED-dropped bytes
:
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
Queued:
Packets
:
3495349
Bytes
:
1495529988
Transmitted:
Packets
:
3495349
Bytes
:
1495529988
0
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
RED-dropped bytes
:
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
Queued:
Packets
:
2646445
Bytes
:
1503180760
Transmitted:
Packets
:
2646445
Bytes
:
1503180760
0
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
RED-dropped bytes
:
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
Queued:
Packets
:
3962207
Bytes
:
729046088
Transmitted:
Packets
:
3962208
Bytes
:
729046272
0
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
RED-dropped bytes
:
0
Low
:
0
Medium-low
:
0
0
0
0
0
0
0
0
0
0
pps
pps
pps
pps
bps
bps
bps
bps
bps
3000 pps
10560000 bps
3000
10560000
0
0
0
0
0
0
0
0
0
0
0
pps
bps
pps
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
2500 pps
11360000 bps
2500
11360000
0
0
0
0
0
0
0
0
0
0
0
pps
bps
pps
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
3750 pps
5520000 bps
3750
5520408
0
0
0
0
0
0
0
0
0
pps
bps
pps
pps
pps
pps
pps
pps
bps
bps
bps
637
Medium-high
:
0
High
:
0
Queued:
Packets
:
1832908
Bytes
:
526167817
Transmitted:
Packets
:
1832908
Bytes
:
526167817
0
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
RED-dropped bytes
:
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
0 bps
0 bps
1514 pps
3754216 bps
1514
3754216
0
0
0
0
0
0
0
0
0
0
0
pps
bps
pps
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps

user@branch2 show interfaces queue gr-1/2/0

Step-by-Step
Procedure
1.
a. Specify the static rendezvous point at Aggregation Hub 1.
[edit]
edit protocols pim
b. Configure multicast on the GRE tunnels, the physical interface to the Layer 3
VPN, and the branch LAN interfaces.

[edit]
edit protocols pim
638
Results
1.
Verify that IGMP groups are formed with the branch LAN.
Group: 224.0.0.2
Source: 0.0.0.0
Timeout:
207 Type: Dynamic
Group: 224.0.0.5
Source: 0.0.0.0
Timeout:
212 Type: Dynamic
Group: 224.0.0.6
Source: 0.0.0.0
Timeout:
212 Type: Dynamic
Group: 224.0.0.13
Source: 0.0.0.0
Timeout:
209 Type: Dynamic
Group: 224.0.0.18
Source: 0.0.0.0
Timeout:
211 Type: Dynamic
Group: 224.0.0.22
Source: 0.0.0.0
Timeout:
212 Type: Dynamic
Group: 224.0.0.2
Source: 0.0.0.0
Timeout:
0 Type: Dynamic
Group: 224.0.0.5
Source: 0.0.0.0
Timeout:
0 Type: Dynamic
Group: 224.0.0.6
Source: 0.0.0.0
Timeout:
0 Type: Dynamic
Group: 224.0.0.13
Source: 0.0.0.0
Timeout:
0 Type: Dynamic
Group: 224.0.0.18
Source: 0.0.0.0
Timeout:
0 Type: Dynamic
Group: 224.0.0.22
Source: 0.0.0.0
Timeout:
0 Type: Dynamic
2. Verify that multicast is running over the interface to Branch router 1 as the upstream
neighbor. The interface to Branch router 1 is the upstream neighbor in this case because
as long as the WAN transport on Branch router is up, all traffic flows on that transport.
639
user@branch2 show pim join
Example output re-used from branch 1

Group: 235.3.1.1
Source: *
RP: 172.31.255.15
Group: 235.3.1.1
Source: 172.31.252.10
Flags: sparse,spt
Group: 235.3.1.2
Source: *
RP: 172.31.255.15
Group: 235.3.1.2
Source: 172.31.252.10
Flags: sparse,spt
Group: 235.3.1.3
Source: *
RP: 172.31.255.15
Group: 235.3.1.3
Source: 172.31.252.10
Flags: sparse,spt
. . .
Group: 235.3.1.15
Source: *
RP: 172.31.255.15
Group: 235.3.1.15
Source: 172.31.252.10
Flags: sparse,spt
640
user@branch2 show pim neighbors

Interface
IP
ge-1/2/1.1
4
ge-1/2/1.2
4
ge-1/2/5.0
4
ge-1/3/5.42
4
V Mode
2
2
2
2
Option
HPLGT
HPLGT
HPLGT
HPLGT
Uptime
1w6d8h
1w6d8h
1w1d9h
1w6d3h
Neighbor addr
172.16.3.33
172.16.3.37
172.16.3.1
172.16.3.10
4. Verify that groups are established with upstream interfaces to the Internet service
provider and downstream interfaces to the branch LAN.


Group: 235.3.1.1
Source: 172.31.252.10/32
ge-1/3/5.42
Route state: Active
Uptime: 01:30:26
Group: 235.3.1.2
Source: 172.31.252.10/32
ge-1/3/5.42
Route state: Active
Uptime: 01:30:26
Group: 235.3.1.3
Source: 172.31.252.10/32
ge-1/3/5.42
641
Route state: Active

Uptime: 01:30:26
Group: 235.3.1.4
Source: 172.31.252.10/32
ge-1/3/5.42
Route state: Active
Uptime: 01:30:26
Group: 235.3.1.5
Source: 172.31.252.10/32
ge-1/3/5.42
Route state: Active
Uptime: 01:30:26
Group: 235.3.1.6
Source: 172.31.252.10/32
ge-1/3/5.42
Route state: Active
Uptime: 01:30:26
Group: 235.3.1.7
Source: 172.31.252.10/32
ge-1/3/5.42
Route state: Active
642

Uptime: 01:30:26
Group: 235.3.1.8
Source: 172.31.252.10/32
ge-1/3/5.42
Route state: Active
Uptime: 01:30:26
Group: 235.3.1.9
Source: 172.31.252.10/32
ge-1/3/5.42
Route state: Active
Uptime: 01:30:26
Group: 235.3.1.10
Source: 172.31.252.10/32
ge-1/3/5.42
Route state: Active
Uptime: 01:30:26
Group: 235.3.1.11
Source: 172.31.252.10/32
ge-1/3/5.42
Route state: Active
643

Uptime: 01:30:26
Group: 235.3.1.12
Source: 172.31.252.10/32
ge-1/3/5.42
Route state: Active
Uptime: 01:30:26
Group: 235.3.1.13
Source: 172.31.252.10/32
ge-1/3/5.42
Route state: Active
Uptime: 01:30:26
Group: 235.3.1.14
Source: 172.31.252.10/32
ge-1/3/5.42
Route state: Active
Uptime: 01:30:25
. . .
Group: 235.3.1.15
Source: 172.31.252.10/32
ge-1/3/5.42
644
Route state: Active

Uptime: 01:30:26
rendezvous point. The interface to Branch router 1 is used because as long as the WAN
transport on Branch router is up, all traffic flows on that transport.

0.0.0.0/0
Protocol: BGP
user@branch> show pim rps extensive

address-family INET
RP: 172.31.255.15
Mode: Sparse
Holdtime: 0
Device Index: 137
Subunit: 32769
Group Ranges:
224.0.0.0/4
235.3.1.1
235.3.1.2
235.3.1.3
235.3.1.4
235.3.1.5
235.3.1.6
235.3.1.7
235.3.1.8
235.3.1.9
235.3.1.10
235.3.1.11
235.3.1.12
235.3.1.13
235.3.1.14
235.3.1.15
645
646
Verification
Purpose
Verify that traffic is end-to-end on the WAN transport on Branch router 1.
Action
Run the following show command on the interface to Service Provider A.

Description: --- To MPLS_VPN_PROVIDER1 link (Jbeer ge-7/0/5) --Link-level type: Ethernet, MTU: 1514, Speed: 1000mbps, BPDU Error: None,
Device flags
: Present Running
Link flags
: None
CoS queues
Hold-times
Last flapped
: 2013-06-18 12:13:42 PDT (04:06:47 ago)
Traffic statistics:
Input bytes :
7915032317192
69454152 bps
Output bytes :
8353192844200
85123504 bps
Input packets:
22262848427
23248 pps
Output packets:
23824605826
25750 pps
Input bytes :
147022244722
Output bytes :
149171131104
Input packets:
628280972
Output packets:
637483464
Input bytes :
0
Output bytes :
0
Input packets:
0
Output packets:
0
Input errors:
incompletes: 0, L2 channel errors: 0, L2 mismatch timeouts: 0, FIFO errors: 0,
Resource errors: 0
Output errors:
packets: 0, FIFO errors: 0, HS link CRC errors: 0, MTU errors: 0, Resource errors:
0
Queue counters:
0 Best_Effort
11377822962
11377822962
0
1 Scavenger
0
0
0
2 Bulk_Data
1975578980
1973172901
2406079
3 Critical_Dat
2881546100
2881546100
0
4 Video
2418003837
2418003837
0
5 Voice
3967134404
3967134404
0
6 Network_Cont
1206953531
1206953531
0
Queue number:
0

Best_Effort
647
1
Scavenger
2
Bulk_Data
3
Critical_Data
4
Video
5
Voice
6
Network_Control
MAC statistics:
Receive
Transmit
Total octets
7918134180545
8354202134062
Total packets
22262865924
23824615991
Unicast packets
19288602349
23824482277
Broadcast packets
798
794
Multicast packets
2974262776
132921
CRC/Align errors
1
0
FIFO errors
0
0
MAC control frames
0
0
MAC pause frames
0
0
Oversized frames
0
Jabber frames
0
Fragment frames
0
VLAN tagged frames
0
Code violations
0
Total errors
1
0
Filter statistics:
Input packet count
22262843252
2
Input DA rejects
0
Input SA rejects
0
Output packet count
23824590883
0
0
Link partner:
Link mode: Full-duplex, Flow control: Symmetric/Asymmetric, Remote fault:
OK
Local resolution:
Destination slot: 1
CoS information:
Direction : Output
CoS transmit queue
Bandwidth
Buffer Priority
Limit
%
bps
%
usec
0 Best_Effort
r
r
r
0 medium-low
none
1 Scavenger
3
3000000
10
0
low
none
2 Bulk_Data
20
20000000
15
0 medium-high
none
3 Critical_Data
15
15000000
15
0
high
exact
4 Video
20
20000000
10
0
high
exact
5 Voice
5
5000000
r
0 strict-high
none
6 Network_Control
5
5000000
3
0
high
exact
648

18 bytes
:
18 bytes
Traffic statistics:
Input bytes :
7915031763976
Output bytes :
8353189834318
Input packets:
22262847083
Output packets:
23824605826
Input bytes :
147022244722
Output bytes :
149171131104
Input packets:
628280972
Output packets:
637483464
Local statistics:
Input bytes :
40240602
Output bytes :
57842601
Input packets:
496606
Output packets:
501647
Transit statistics:
Input bytes :
7914991523374
69453784 bps
Output bytes :
8353131991717
85121088 bps
Input packets:
22262350477
23248 pps
Output packets:
23824104179
25749 pps
Input bytes :
147022244722
Output bytes :
149171131104
Input packets:
628280972
Output packets:
637483464
Output Filters: v4_sample
Generation: 530
Flags: Is-Primary
Generation: 166
Flags: Is-Primary
649
Purpose
Action
Use this procedure to verify reachability and traffic paths to the loopback interface of
the data center router, the loopback interface of a router in a different branch, and an IP
address in the service provider network that is publicly routable.
1.
Display the default IPv4 routing tables on each branch to verify reachability throughout
the network.
0.0.0.0/0
10.4.1.0/24
10.4.2.0/24
10.4.3.0/24
10.4.4.0/24
10.4.5.0/24
10.4.6.0/24
10.4.7.0/24
10.4.8.0/24
*[BGP/170] 05:07:35, localpref 200

> to 172.16.4.1 via ge-1/2/1.0
*[OSPF/150] 05:09:10, metric 11, tag 0
> to 172.16.4.12 via ge-1/2/0.43
*[OSPF/150] 05:09:10, metric 11, tag 0
> to 172.16.4.12 via ge-1/2/0.43
*[OSPF/150] 05:09:10, metric 11, tag 0
> to 172.16.4.12 via ge-1/2/0.43
*[OSPF/150] 05:09:10, metric 11, tag 0
> to 172.16.4.12 via ge-1/2/0.43
*[OSPF/150] 05:09:10, metric 11, tag 0
> to 172.16.4.12 via ge-1/2/0.43
*[OSPF/150] 05:09:10, metric 11, tag 0
> to 172.16.4.12 via ge-1/2/0.43
*[OSPF/150] 05:09:10, metric 11, tag 0
> to 172.16.4.12 via ge-1/2/0.43
*[OSPF/150] 05:09:10, metric 11, tag 0

0.0.0.0/0
10.4.1.0/24
10.4.2.0/24
10.4.3.0/24
10.4.4.0/24
10.4.5.0/24
10.4.6.0/24
10.4.7.0/24

> to 172.16.4.33 via ge-1/2/4.1
[BGP/170] 5d 03:59:28, localpref 100
> to 172.16.4.5 via ge-1/3/1.0
*[OSPF/150] 18:11:48, metric 11, tag 0
> to 172.16.4.12 via ge-1/3/0.43
*[OSPF/150] 18:11:48, metric 11, tag 0
> to 172.16.4.12 via ge-1/3/0.43
*[OSPF/150] 18:11:48, metric 11, tag 0
> to 172.16.4.12 via ge-1/3/0.43
*[OSPF/150] 18:11:48, metric 11, tag 0
> to 172.16.4.12 via ge-1/3/0.43
*[OSPF/150] 18:11:48, metric 11, tag 0
> to 172.16.4.12 via ge-1/3/0.43
*[OSPF/150] 18:11:48, metric 11, tag 0
> to 172.16.4.12 via ge-1/3/0.43
*[OSPF/150] 18:11:48, metric 11, tag 0
> to 172.16.4.12 via ge-1/3/0.43
. . .
650
10.4.247.0/24
10.4.248.0/24
10.4.249.0/24
10.4.250.0/24
10.4.251.0/24
10.4.252.0/24
10.4.253.0/24
10.4.254.0/24
10.4.255.0/24
172.16.4.4/30
172.16.4.6/32
172.16.4.8/29
172.16.4.9/32
172.16.4.10/32
172.16.4.16/29
172.16.4.17/32
172.16.4.18/32
172.16.4.24/29
172.16.4.25/32
172.16.4.26/32
172.16.4.32/30
172.16.4.34/32
172.16.4.36/30
172.16.4.38/32
172.16.4.254/32
172.16.4.255/32
224.0.0.2/32
224.0.0.5/32
224.0.0.13/32
224.0.0.22/32
> to 172.16.4.28 via ge-1/3/0.63

*[OSPF/150] 18:11:48, metric 11, tag
> to 172.16.4.28 via ge-1/3/0.63
*[OSPF/150] 18:11:48, metric 11, tag
> to 172.16.4.28 via ge-1/3/0.63
*[OSPF/150] 18:11:48, metric 11, tag
> to 172.16.4.28 via ge-1/3/0.63
*[OSPF/150] 18:11:48, metric 11, tag
> to 172.16.4.28 via ge-1/3/0.63
*[OSPF/150] 18:11:48, metric 11, tag
> to 172.16.4.28 via ge-1/3/0.63
*[OSPF/150] 18:11:48, metric 11, tag
> to 172.16.4.28 via ge-1/3/0.63
*[OSPF/150] 18:11:48, metric 11, tag
> to 172.16.4.28 via ge-1/3/0.63
*[OSPF/150] 18:11:48, metric 11, tag
> to 172.16.4.28 via ge-1/3/0.63
*[OSPF/150] 18:11:48, metric 11, tag
> to 172.16.4.28 via ge-1/3/0.63
*[Direct/0] 4w0d 05:16:49
> via ge-1/3/1.0
*[Local/0] 4w0d 05:16:49
*[Direct/0] 1w5d 04:58:41
> via ge-1/3/0.43
*[Local/0] 1w5d 04:58:33
*[Local/0] 5w6d 00:49:27
*[Direct/0] 1w5d 04:58:41
> via ge-1/3/0.53
*[Local/0] 1w5d 04:58:33
*[Local/0] 5w6d 00:49:27
*[Direct/0] 1w5d 04:58:41
> via ge-1/3/0.63
*[Local/0] 1w5d 04:58:33
*[Local/0] 5w6d 00:49:27
*[Direct/0] 1w5d 04:56:45
> via ge-1/2/4.1
*[Local/0] 5w6d 00:49:27
*[Direct/0] 1w5d 04:56:45
> via ge-1/2/4.2
*[Local/0] 6w5d 22:49:58
*[OSPF/10] 1w5d 04:55:41, metric 1
> to 172.16.4.33 via ge-1/2/4.1
*[Direct/0] 6w5d 22:51:17
> via lo0.1
*[PIM/0] 6w5d 22:51:27
MultiRecv
*[OSPF/10] 6w5d 22:51:28, metric 1
MultiRecv
*[PIM/0] 6w5d 22:51:27
MultiRecv
*[IGMP/0] 6w5d 22:50:04
0
0
0
0
0
0
0
0
0
651
MultiRecv

PING 172.31.255.8 (172.31.255.8): 56 data bytes
!!!!!
1 172.16.4.1 (172.16.4.1) 0.869 ms 0.822 ms 0.498 ms # L3VPN ISP A
2 172.31.254.33 (172.31.254.33) 0.608 ms 1.478 ms 0.604 ms #ISP A
3 172.31.254.34 (172.31.254.34) 0.468 ms 0.774 ms 0.587 ms #WANaggr 1
PING 172.16.1.254 (172.16.1.254): 56 data bytes
!!!!!
1 172.16.4.1 (172.16.4.1) 0.678 ms 0.813 ms 0.512 ms # L3VPN ISP A
2 172.31.254.33 (172.31.254.33) 0.504 ms 11.026 ms 0.477 ms #ISP A
3 172.31.254.34 (172.31.254.34) 0.480 ms 1.543 ms 2.250 ms #WANaggr 1
4 172.31.254.14 (172.31.254.14) 22.304 ms 0.803 ms 0.713 ms #VPN hub 1
5 172.16.1.254 (172.16.1.254) 3.273 ms 4.441 ms 8.268 ms# Branch Loopback
provider network.
1 172.16.4.1 (172.16.4.1) 0.684 ms 0.550 ms 0.445 ms # L3VPN ISP A
2 172.31.254.33 (172.31.254.33) 1.278 ms 0.545 ms 0.535 ms #ISP A
3 172.31.254.34 (172.31.254.34) 0.521 ms 0.524 ms 0.468 ms #WANaggr 1
4 172.31.254.9 (172.31.254.9) 0.479 ms 0.520 ms 0.481 ms #Int edge 1
6
652
* * *

Purpose
Action
This procedure verifies that a failure of the Branch router 1 physical WAN transport to
Aggregation Hub 1 causes all traffic to be rerouted through Branch router 2 to Aggregation
Hub 2 with minimal traffic loss.
1.
Log in to Branch router 1 as the root user, and enter the following command to take
root@branch1% ifconfig ge-1/2/1 down
2. On Branch router 1, verify that the active default route is to Service Provider B over the
interface to Branch router 2.

0.0.0.0/0
*[BGP/170] 00:00:31, localpref 100, from 172.16.4.255

> to 172.16.4.34 via ge-1/3/4.1
3. On Branch router 2, verify EBGP peering with the Layer 3 VPN Service Provider B
(172.16.4.5) and the loopback interface (172.16.4.254) on Branch router 1.

Table
History Damp State
Pending
inet.0
1
1
0
0
0
0
inet6.0
1
1
0
0
0
0
Peer
AS
InPkt
OutPkt
OutQ
Flaps Last Up/Dwn
172.16.4.5
556
64444
64881
0
2
12:28:00
1/1/1/0
0/0/0/0
172.16.4.254
64514
64314
64319
0
1 1d 15:11:44
0/0/0/0
0/0/0/0
2001:DB8:4::254
64514
64255
64252
0
0
2w6d6h
Establ
inet6.0: 0/0/0/0
2001:DB8:4:2::1
556
64438
64949
0
1
1w6d8h
Establ
inet6.0: 1/1/1/0
4. On Branch router 2, verify that the active default route is to Service Provider B over
the WAN transport interface to Service Provider B.

0.0.0.0/0
*[BGP/170] 09:31:43, localpref 100

> to 172.16.4.5 via ge-1/3/1.0
653

Device flags
: Present Running
Link flags
: None
CoS queues
Hold-times
Last flapped
: 2013-05-29 11:53:19 PDT (2w6d 06:11 ago)
Statistics last cleared: 2013-06-18 11:47:29 PDT (06:17:17 ago)
Traffic statistics:
Input bytes :
10943440671
125398040 bps
Output bytes :
13795758330
130224664 bps
Input packets:
27314006
39900 pps
Output packets:
38512292
45401 pps
Input bytes :
135016692
Output bytes :
135055908
Input packets:
576995
Output packets:
577162
Input bytes :
0
Output bytes :
0
Input packets:
0
Output packets:
0
Input errors:
0,
Resource errors: 0
Output errors:
Queue counters:
0 Best_Effort
34190461
34190461
0
1 Scavenger
0
0
0
2 Bulk_Data
742944
742944
0
3 Critical_Dat
2080803
2080803
0
4 Video
528549
528549
0
5 Voice
726138
726138
0
6 Network_Cont
297226
297226
0
Queue number:
0
Best_Effort
1
Scavenger
2
Bulk_Data
3
Critical_Data
4
Video
5
Voice
6
Network_Control
MAC statistics:
Receive
Transmit
Total octets
10849779951
13660181686
Total packets
27331751
38532479
Unicast packets
21588769
38530091
Broadcast packets
9
13
654
Multicast packets
5742972
2378
CRC/Align errors
0
0
FIFO errors
0
0
MAC control frames
0
0
MAC pause frames
0
0
Oversized frames
0
Jabber frames
0
Fragment frames
0
VLAN tagged frames
0
Code violations
0
Total errors
0
0
Filter statistics:
Input packet count
27331751
815
Input DA rejects
0
Input SA rejects
0
Output packet count
38532479
0
0
Link partner:
fault: OK
Local resolution:
Destination slot: 1
CoS information:
Direction : Output
CoS transmit queue
Bandwidth
Buffer Priority Limit
%
bps %
usec
0 Best_Effort
r
r r
0 medium-low none
1 Scavenger
3
4500000 10
0 low none
2 Bulk_Data
20
30000000 15
0 medium-high none
3 Critical_Data
15
22500000 15
0 high exact
4 Video
20
30000000 10
0 high exact
5 Voice
5
7500000 r
0 strict-high none
6 Network_Control
5
7500000 3
0 high exact
170)
22 bytes
:
22 bytes
Traffic statistics:
Input bytes :
10942558763
Output bytes :
13795716347
Input packets:
27312207
Output packets:
38512293
Input bytes :
135016504
Output bytes :
135055908
Input packets:
576993
Output packets:
577162
Local statistics:
Input bytes :
525592
Output bytes :
693776
655
Input packets:
6525
Output packets:
7019
Transit statistics:
Input bytes :
10942033171
125398040 bps
Output bytes :
13795022571
130224664 bps
Input packets:
27305682
39900 pps
Output packets:
38505274
45401 pps
Input bytes :
135016504
Output bytes :
135055908
Input packets:
576993
Output packets:
577162
Generation: 398
Flags: Is-Primary
Generation: 362
656
Queued:
Packets
:
36093293
41712
Bytes
:
12417782294
113860384
Transmitted:
Packets
:
36093293
41712
Bytes
:
12417782294
113860384
0
0
0
0
Low
:
0
0
Medium-low
:
0
0
Medium-high
:
0
0
High
:
0
0
RED-dropped bytes
:
0
0
Low
:
0
0
Medium-low
:
0
0
Medium-high
:
0
0
High
:
0
0
Queued:
Packets
:
0
0
Bytes
:
0
0
Transmitted:
Packets
:
0
0
Bytes
:
0
0
0
0
0
0
Low
:
0
0
Medium-low
:
0
0
Medium-high
:
0
0
High
:
0
0
RED-dropped bytes
:
0
0
Low
:
0
0
Medium-low
:
0
0
Medium-high
:
0
0
High
:
0
0
Queued:
Packets
:
786418
396
Bytes
:
383771984
1545984
Transmitted:
Packets
:
786418
396
Bytes
:
383771984
1545984
0
0
0
0
Low
:
0
0
Medium-low
:
0
0
Medium-high
:
0
0
High
:
0
0
RED-dropped bytes
:
0
0
Low
:
0
0
Medium-low
:
0
0
Medium-high
:
0
0
pps
bps
pps
bps
pps
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
pps
bps
pps
bps
pps
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
pps
bps
pps
bps
pps
pps
pps
pps
pps
pps
bps
bps
bps
bps
657
High
:
Queued:
Packets
:
Bytes
:
Transmitted:
Packets
:
Bytes
:
Low
:
Medium-low
:
Medium-high
:
High
:
RED-dropped bytes
:
Low
:
Medium-low
:
Medium-high
:
High
:
Queued:
Packets
:
Bytes
:
Transmitted:
Packets
:
Bytes
:
Low
:
Medium-low
:
Medium-high
:
High
:
RED-dropped bytes
:
Low
:
Medium-low
:
Medium-high
:
High
:
Queued:
Packets
:
Bytes
:
Transmitted:
Packets
:
Bytes
:
Low
:
Medium-low
:
Medium-high
:
High
:
RED-dropped bytes
:
Low
:
Medium-low
:
Medium-high
:
High
:
Queued:
Packets
:
Bytes
:
Transmitted:
Packets
:
658
0 bps
2197283
599916192
2203 pps
4455296 bps
2197283
599916192
0
0
0
0
0
0
0
0
0
0
0
2203
4455296
0
0
0
0
0
0
0
0
0
0
0
559139
272859832
701 pps
2739040 bps
559139
272859832
0
0
0
0
0
0
0
0
0
0
0
701
2739040
0
0
0
0
0
0
0
0
0
0
0
Critical_Data
pps
bps
pps
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
Video
pps
bps
pps
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
Voice
766606
79727024
766606
79727024
0
0
0
0
0
0
0
0
0
0
0
Network_Control
310 pps
258240 bps
310
258240
0
0
0
0
0
0
0
0
0
0
0
pps
bps
pps
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
314617
72991144
158 pps
293984 bps
314617
158 pps
Bytes
RED-dropped packets
Low
Medium-low
Medium-high
High
RED-dropped bytes
Low
Medium-low
Medium-high
High
:
:
:
:
:
:
:
:
:
:
:
:
72991144
0
0
0
0
0
0
0
0
0
0
0
293984
0
0
0
0
0
0
0
0
0
0
0
bps
pps
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
7. Check the path taken by traffic to the data center after Branch router 1 primary link
failure.
PING 172.31.255.8 (172.31.255.8): 56 data bytes
^C
1 172.16.4.34 (172.16.4.34) 0.546 ms 0.475 ms 0.377 ms # Branch Router 2
2 172.16.4.5 (172.16.4.5) 0.437 ms 0.514 ms 0.510 ms # L3VPN ISPB PE 2
3 * * *
4 172.31.254.38 (172.31.254.38) 0.975 ms 8.610 ms 9.448 ms # WAN
Aggregation Hub 2
8. Check the Branch-to-Branch path taken by traffic after Branch router 1 primary link
failure.
PING 172.16.1.254 (172.16.1.254): 56 data bytes
2
3
4
5
6
7

* * *
172.31.254.38 (172.31.254.38) 34.200 ms 0.557 ms 0.456 ms #WANAGG2
172.31.254.41 (172.31.254.41) 0.495 ms 0.576 ms 0.496 ms #WANAGG1
172.31.254.14 (172.31.254.14) 0.616 ms 0.716 ms 0.550 ms #VPN1
659
9. Check the Branch-to-Internet path taken by traffic after Branch router 1 primary link
failure.
rtraceroute to 100.65.4.2 (100.65.4.2), 30 hops max, 40 byte packets
2
3
4
5
6
7
8
660

* * *
172.31.254.38 (172.31.254.38) 0.514 ms 0.541 ms 0.439 ms#WANAGG2
172.31.254.41 (172.31.254.41) 0.513 ms 0.574 ms 0.464 ms #WANAGG1
172.31.254.9 (172.31.254.9) 0.475 ms 0.537 ms 0.512 ms #IEDGE1
* * *
* * *
Verify that groups are established with upstream interfaces to the Layer 3 VPN service
provider 2 (ge-1/3/1) and downstream interfaces to Branch router 1 (ge-1/2/4).
Group: 235.4.1.1
Source: 172.31.252.10/32
ge-1/2/4.1
Route state: Active
Uptime: 00:12:36
Group: 235.4.1.2
Source: 172.31.252.10/32
ge-1/2/4.1
Route state: Active
Uptime: 00:12:35
Group: 235.4.1.3
Source: 172.31.252.10/32
ge-1/2/4.1
Route state: Active
Uptime: 00:12:35
661
Purpose
Action
Use this procedure to verify this scenario from the WAN aggregation router at Aggregation
Hub 1.
1.
Interface
Admin Link Proto
Local
Remote
ge-1/2/5
up
up
ge-1/2/5.0
up
up
inet
172.31.254.34/30
inet6
fe80::5e5e:abff:fe0e:4205/64
2001:DB8:254:1::2/64
multiservice
Interface
Admin Link Proto
ge-1/2/5
up
up
ge-1/2/5.0
up
up
inet
inet6
Local
Remote
172.31.254.34/30
fe80::5e5e:abff:fe0e:4205/64
2001:DB8:254:1::2/64
multiservice

Table
History Damp State
Pending
inet.0
26386
26384
0
0
0
0
inet6.0
25393
25393
0
0
0
0
Peer
AS
InPkt
OutPkt
OutQ
Flaps Last Up/Dwn
172.31.254.33
555
855
759
0
0
6:13:55
383/384/384/0
0/0/0/0
Table
History Damp State
Pending
inet.0
26386
26384
0
0
0
0
inet6.0
25393
25393
0
0
0
0
Peer
AS
InPkt
OutPkt
OutQ
Flaps Last Up/Dwn
2001:DB8:254:1::1
555
857
759
0
0
6:14:23
Establ
inet6.0: 392/392/392/0
provider.
662
Prefix
* 0.0.0.0/0
Nexthop
Self
MED
0
Lclpref
AS path
I

Prefix
* ::/0
Nexthop
Self
MED
Lclpref
AS path
I
663
664
CHAPTER 15
Adding WAN Acceleration to the

Enterprise Network
Example: Configuring WAN Acceleration Between a Branch and Aggregation Hub Using
WCCP
This example shows how to configure the Web Cache Configuration Protocol (WCCP)
to achieve WAN acceleration between a branch router and aggregation hub.
Requirements
Two M7i or MX Series Juniper Networks routers with a MS-PIC and MS-DPC installed.
Junos OS Release 11.4 or later with Junos OS SDK installed
Overview
WCCP delivers transparent application acceleration by dynamically forwarding relevant
traffic to one or more off-path cache instances. The results include optimized resource
utilization, reduced response time, improved user experience, and increased productivity.
WCCP supports the following features:
GRE encapsulation for forwarded traffic
Layer 2-rewrite operations for forwarded traffic
GRE encapsulation for returned traffic
Layer 2-rewrite operations for returned traffic
Dynamic services
665
Figure 81 on page 666 shows how application acceleration between two branch offices is
set up using WCCP.
Topology
Figure 81: WAN Acceleration Implemented as Part of the EWAN Solution
Configuring WCCP on the Branch Router
Installing the Full WCCP Package on the Branch Router on page 666
Configure Interfaces on the Branch Router. on page 667
Configure WCCP on the Branch Router on page 668
Configuring Forward Traffic Steering on the Branch Router on page 669
Configuring Return Traffic Steering on the Branch Router on page 670
Installing the Full WCCP Package on the Branch Router

Step-by-Step
Procedure
Before running WCCP, the WCCP package must be installed on the branch router. The
first step is to configure the provider ID for Juniper Networks so that the SDK service
daemon (SSD) is enabled and will allow for the installation and running of WCCP.
1.
Add the following license.

[edit]
set system extensions providers juniper license-type juniper deployment-scope
commercial
2.
Copy the WCCP package to the router, and install it as follows:

[edit]
request system software add wccp-bundle-i386-12.3I20020101_1431_builder.tgz
no-validate
666
Chapter 15: Adding WAN Acceleration to the Enterprise Network
NOTE: More information on uploading software to Junos OS and

installing packages can be found here: Juniper Networks Technical
Publications
3.
Add the following script.

[edit]
set system scripts op file juniper-wccp-l2-fbf.xsl
4.

[edit]
commit
Results
Verify that the WCCP package is installed.

user@branch> show version
Hostname: eabu-sol-eng-ewan-m7i-01
Model: m7i
JUNOS Base OS boot [12.3R3.2]
JUNOS Base OS Software Suite [12.3R3.2]
JUNOS Kernel Software Suite [12.3R3.2]
JUNOS Crypto Software Suite [12.3R3.2]
. . .
Web Cache Communication Protocol [1.0-Beta_2_11.4R1.14]
WCCP Dataplane Component [1.0-Beta_2_11.4R.1.14]
Configure Interfaces on the Branch Router.

Step-by-Step
Procedure
1.
Configure the Ethernet interface to the WCCP client appliance.

[edit]
2.
Configure the Ethernet interface to the aggregation hub.

[edit]
3.
Configure the Ethernet interface to the user.

[edit]
4.
Configure the Ethernet interface to the GRE tunnel.

[edit]
edit interfaces gr-0/1/0
set unit 1 tunnel source 100.1.1.1
set unit 1 tunnel destination 200.1.1.1
5.
Configure the Ethernet interface to the MS-PIC.
667
[edit]
edit interfaces ms-0/1/0
6.
Configure the loopback interface.

[edit]
edit interfaces lo0
set unit 0 family inet address 100.1.1.1/32 primary
set unit 0 family inet address 100.1.1.1/32 preferred
7.
Configure an OSPF backbone area. Add the Ethernet interface to the aggregation
hub, and add the loopback interface.
[edit]
Configure WCCP on the Branch Router

Step-by-Step
Procedure
In this example, the WCCP data module is configured to run on a Multiservices PIC. The
WCCP application is configured for WCCP service group 61 (TCP traffic). Hash assignment
method is used to decide the target client WCCP appliance device. Traffic is forwarded
to one of the client WCCP appliance devices for acceleration using the GRE (Layer 3)
forwarding method. In this case, the gretunnel-ip must be specified, which acts as an
endpoint of the GRE tunnel between the router and a client WCCP appliance device. For
any traffic that does not meet the configured policy for application acceleration, the
client WCCP appliance device returns the traffic to WCCP again using the GRE redirection
method.
1.
Add the WCCP data package to the router.

[edit]
edit chassis fpc 0 pic 1 adaptive-services service-package extension provider
set control-cores 2
set data-cores 3
set package wccp-data
set syslog daemon any
set syslog daemon destination routing-engine
2.
The cache timeout is the interval, in seconds, at which a cache sends HERE_I_AM
messages to the routers in a service group. This parameter is used to derive the
value of cache communication timeout which is three times the configured value
The port is the port on which WCCP communicates.
The router ID is an IP address that is reachable from the caches.
[edit]
edit wccp
set configure cache-timeout 20
set configure wccp-port 2048
set configure router-id 100.1.1.1
668
3.
The service-interface-unit statement identifies the MS-PIC service interface unit

used for processing.
[edit]
edit wccp
set configure service-interface-unit 2
4.
The wccp-service statement sets the WCCP service-group ID.

The forwarding-method statement assigns the forwarding method to Layer 2, GRE,
or both.
The gre-tunnel-ip statement sets the IP address of the GRE tunnel source.
The return-method statement assigns the WCCP return method to Layer 2, GRE,
or both.
The assignment-method statement sets the WCCP assignment method to hash
or mask.
[edit]
edit wccp
set configure service http wccp-service 61
set configure service http forwarding-method gre
set configure service http gre-tunnel-ip 100.1.1.1
set configure service http return-method gre
set configure service http assignment-method hash
Configuring Forward Traffic Steering on the Branch Router

Step-by-Step
Procedure
Traffic must be steered to the MS-PIC interface for processing by the WCCP MS-PIC
daemon. In this example, an egress filter is applied to steer all egress traffic to the
ms-interface unit which is received by the WCCP data component. The WCCP data
component processes the traffic and redirects it to one of the client WCCP appliance
devices if it matches the WCCP service group definition.
1.
Use filter-based forwarding (FBF) to steer traffic to the MS-PIC interface.

[edit]
edit firewall filter wccp_steer_filter
set term egress_fbf from interface ge-0/0/3
set term egress_fbf then routing-instance egress_steer_ri
set term any then accept
2.
Steer egress traffic to the ms-interface unit.

[edit]
edit routing-instances egress_steer_ri
set instance-type forwarding
set routing-options static route 0.0.0.0/0 next-hop ms-0/1/0.2
3.
Set up WCCP forwarding.

[edit]
set interface-routes rib-group inet wccp_fwding_ribg
set interface-routes family inet export lan
669

set rib-groups wccp_fwding_ribg import-rib inet.0
set rib-groups wccp_fwding_ribg import-rib egress_steer_ri.inet.0
4.
Add the wccp_steer_filter to the GRE interface.

[edit]
set unit 1 family inet filter output wccp_steer_filter
Configuring Return Traffic Steering on the Branch Router

Step-by-Step
Procedure
If a cache decides not to accelerate certain traffic forwarded to it for whatever reason,
it is returned to the router using the selected return method This example uses the GRE
method of returning traffic. The GRE method steers the return traffic to the MS-PIC
interface on a unit different than the one used for the forwarding traffic interface so the
WCCP can decapsulate the original packet and forward it normally.
1.
Configure a service filter with the rule that any traffic coming from the WCCP cache
will use the GRE method of returning traffic, and other traffic and other traffic is
skipped.
[edit]
edit firewall family inet
set service-filter gre_return term service from protocol gre
set service-filter gre_return term service then count to_wccp
set service-filter gre_return term service then service
set service-filter skip_all term no_Service then count from_wccp
set service-filter skip_all term no_Service then skip
2.
Set up wccp_cache_return so all traffic that needs acceleration is sent to ms-0/1/0.1

for processing.
[edit]
edit services service-set wccp_cache_return
set service-set-options bypass-traffic-on-pic-failure
set interface-service service-interface ms-0/1/0.1
set extension-service wccp-data
3.
Configure gre_return to see if GRE packets are received from the cache device.
[edit]
edit interfaces ge-0/0/1 unit 0 family inet
set service input service-set wccp_cache_return service-filter gre_return
set output service-set wccp_cache_return service-filter skip_all
Configuring WCCP on the Aggregation Hub
670
Configuring Interfaces on the Aggregation Hub on page 671
Configuring WCCP on the Aggregation Hub on page 672
Configure Forward Traffic Steering on the Aggregation Hub on page 673
Configure Return Traffic Steering on the Aggregation Hub on page 673
Configuring Interfaces on the Aggregation Hub

Step-by-Step
Procedure
1.

[edit]
2.

[edit]
3.

[edit]
set interfaces ge-0/0/3
4.
Configure the GRE tunnel interface to the aggregation hub.

[edit]
5.
Configure the MS-PIC that is used to process WCCP traffic.

[edit]
6.
Configure the loopback interface

[edit]
edit interfaces lo0
7.
[edit]
671

Step-by-Step
Procedure
method.
1.

[edit]
set control-cores 2
set data-cores 3
2.
[edit]
edit wccp
3.
Specify the service interface used to process WCCP traffic.

[edit]
edit wccp
4.
Configure WCCP parameters.

Specify the ID of the WCCP service group.
Set the forwarding method that is used to redirect traffic to be accelerated to the
cache.
Set the return method that the cache uses to return forwarded traffic to the router.
Set the method to used to assign a cache for a packet to hash.
[edit]
edit wccp
672

Configure Forward Traffic Steering on the Aggregation Hub

Step-by-Step
Procedure
1.
Set up WCCP filters.

[edit]
2.

[edit]
3.

[edit]
4.

[edit]
Configure Return Traffic Steering on the Aggregation Hub

Step-by-Step
Procedure
1.
skipped.
673
[edit]
2.

for processing.
[edit]
3.
[edit]
Verification
To confirm that the configuration is working properly, perform these tasks:
Purpose
674
Verify that the network is up and running with the proper interfaces and routes installed.
Action
user@router> show interfaces terse gr-0/1/0

Interface
Admin Link Proto
gr-0/1/0
up
up
gr-0/1/0.1
up
up
inet
Local
Remote
1.1.1.2/24
user@router> ping 1.1.1.1

PING 1.1.1.1 (1.1.1.1): 56 data bytes
^C
user@router> show route 200.1.1.1

200.1.1.1/32
*[OSPF/10] 20:47:55, metric 1

> to 10.1.1.2 via ge-0/0/2.0
egress_steer_ri.inet.0: 13 destinations, 13 routes (12 active, 0 holddown, 1

hidden)
0.0.0.0/0
*[Static/5] 20:45:50
> via ms-0/1/0.2

6.1.1.0/24
*[Static/5] 20:45:59
> to 1.1.1.1 via gr-0/1/0.1

hidden)
0.0.0.0/0
Meaning
*[Static/5] 20:45:59
> via ms-0/1/0.2
The output shows that the network is up and reachable.
The show interfaces command confirms that the configured interfaces are up and
running.
The ping command shows that packets are being sent and received.
The show route commands ensure that egress_steer_ri functionality is working, and
display the number of destinations and routes.
675
Verifying WCCP
Purpose
Action
Verify that WCCP is working and the proper protocols are enabled.
user@router> show wccp cache-engines

Service ID Cache Engine IP Designated
Last HIM
61
14.4.4.2
Yes
Aug 2 2013 21:08:05 UTC
Status
Receive ID
Assigned Time
Assigned
428894207
20:47
user@router> show wccp cache-engines detail

Service ID: 61
Cache Engine IP: 14.4.4.2
Designated: Yes
Protocol Version: 2.0
Status: Assigned
Receive ID: 428894208
Forwarding Method: GRE
Return Method: GRE
Assignment: Hash, 256 buckets ( 100% )
Packets Redirected: 1353729
Assigned Time: 20:47
Last HIM: Aug 2 2013 21:08:15 UTC
user@router> show wccp service-groups
Router ID
Service ID
Cache Engines
100.1.1.1
61
1
Routers
1
user@router>show wccp service-groups detail

Service ID: 61
Router ID: 100.1.1.1
Cache Engines: 1
Routers: 1
Total Redirected: 1353750
Total GRE Returned: 465191
Total Unassigned: 0
Total Auth Failures: 0
Meaning
676
The output shows that the WCCP cache engines and service groups are functioning
properly.
The cache engine details show that GRE has been selected as both the forwarding
and return method.
The service group details show the total amount of packets redirected and returned
through GRE.
WCCP-Lite
This example shows how to configure the Web Cache Configuration Protocol Lite
(WCCP-Lite) to achieve WAN acceleration between a branch router and aggregation
hub (Figure 82 on page 678).
Requirements on page 677
Overview on page 677
Configuration on page 678
Configuring WCCP-Lite on the Aggregation Hub on page 681
Verification on page 683
Requirements
Two M7i, MX Series or SRX Series Juniper Networks routers with a MS-PIC and MS-DPC
installed.
NOTE: Junos OS SDK is not required on SRX Series.
Overview
WCCP-Lite delivers transparent application acceleration to small networks by dynamically
forwarding relevant traffic to a off path cache instance. The results include optimized
resource utilization, reduced response time, improved user experience, and increased
productivity.
WCCP-Lite supports the following features:
Layer 2-rewrite for forwarded traffic
Layer 2-rewrite for returned traffic
Dynamic services
677
Topology
Figure 82: WAN Acceleration Using WCCP-Lite
Configuration
Installing the WCCP-Lite Package on the Branch Router on page 678
Configuring Interfaces on the Branch Router on page 679
Configuring WCCP-Lite on the Branch Router on page 680
Installing the WCCP-Lite Package on the Branch Router

Step-by-Step
Procedure
1.

[edit]
commercial
2.

[edit]
no-validate

Publications
3.

[edit]
678
4.

[edit]
commit
Results
Verify that the WCCP-Lite package is installed.

Model: m7i
. . .
Configuring Interfaces on the Branch Router

Step-by-Step
Procedure
1.

[edit]
2.

[edit]
3.

[edit]
4.

[edit]
5.

[edit]
6.

[edit]
edit interfaces lo0
679

7.
[edit]
Configuring WCCP-Lite on the Branch Router

Step-by-Step
Procedure
method.
1.
Set the name and size for the traceoptions file.

[edit]
edit wccp
set traceoptions file wccp.log
set traceoptions file size 10m
set traceoptions flag all
2.
[edit]
edit wccp
3.

[edit]
edit wccp
set configure service-interface-unit-for-l2-rewrite ms-0/1/0.2
4.

cache.
680
[edit]
edit wccp
set configure service tcp_promo wccp-service 61
set configure service tcp_promo forwarding-method l2
set configure service tcp_promo return-method l2
set configure service tcp_promo assignment-method hash
5.
Set up the WCCP-Lite filter.

[edit]
edit firewall filter
set wccplite_filter term any_other then accept
[edit]
set unit 0 family inet filter input wccplite_filter
6.
Configuring WCCP-Lite on the Aggregation Hub

Step-by-Step
Procedure
1.

[edit]
2.

[edit]
3.

[edit]
4.

[edit]
5.

[edit]
6.
[edit]
edit interfaces lo0
681

7.
[edit]
Configuring WCCP-Lite on the Aggregation Hub

Step-by-Step
Procedure
In this example, the WCCP application is configured for WCCP service group 61 (TCP
traffic). Hash assignment method is used to decide the target client WCCP appliance
device. Traffic is forwarded to one of the client WCCP appliance devices for acceleration
using the Layer 2 forwarding method. The WCCP-Lite application adds or updates the
terms to filter named wccplite_filter to redirect the traffic to the client WCCP appliance
device. For any traffic that does not meet the configured policy for application
acceleration, the client WCCP appliance device returns the traffic to WCCP again using
the Layer 2 redirection method.
1.
Set the name and size for the traceoptions file.

[edit]
edit wccp
set traceoptions file wccp.log
set traceoptions file size 10m
set traceoptions flag all
2.
[edit]
edit wccp
3.

[edit]
edit wccp
set configure service-interface-unit-for-l2-rewrite ms-0/1/0.2
4.

cache.
682
[edit]
edit wccp
set configure service tcp_promo wccp-service 61
set configure service tcp_promo forwarding-method l2
set configure service tcp_promo return-method l2
set configure service tcp_promo assignment-method hash
5.
Set up the WCCP-Lite filter.

[edit]
edit firewall filter
set wccplite_filter term any_other then accept
6.
[edit]
set unit 0 family inet filter input wccplite_filter
Verification
Purpose
683
Action

Interface
Admin Link Proto
gr-0/1/0
up
up
gr-0/1/0.1
up
up
inet
Local
Remote
1.1.1.2/24

PING 1.1.1.1 (1.1.1.1): 56 data bytes
^C
200.1.1.1/32
*[OSPF/10] 20:47:55, metric 1

> to 10.1.1.2 via ge-0/0/2.0

hidden)
0.0.0.0/0
*[Static/5] 20:45:50
> via ms-0/1/0.2

6.1.1.0/24
*[Static/5] 20:45:59
> to 1.1.1.1 via gr-0/1/0.1

hidden)
0.0.0.0/0
Meaning
*[Static/5] 20:45:59
> via ms-0/1/0.2
running.
Verifying WCCP
Purpose
684
Action

Last HIM
61
14.4.4.2
Yes
Aug 2 2013 21:08:05 UTC
Status
Receive ID
Assigned Time
Assigned
428894207
20:47

Service ID: 61
Designated: Yes
Status: Assigned
Return Method: GRE
Last HIM: Aug 2 2013 21:08:15 UTC
user@router> show wccp service-groups
Router ID
Service ID
Cache Engines
100.1.1.1
61
1
Routers
1
user@router> show wccp service-groups detail

Service ID: 61
Router ID: 100.1.1.1
Cache Engines: 1
Routers: 1
Total Redirected: 1353750
Total GRE Returned: 465191
Total Unassigned: 0
Total Auth Failures: 0
Meaning
properly.
and return method.
The service group details show the total amount of packets redirected and returned
through GRE.
WCCP Full
This example shows how to configure the Web Cache Configuration Protocol (WCCP)
to achieve WAN acceleration between a branch router and aggregation hub in a network
with multiple cache devices (Figure 83 on page 687).
Requirements on page 686
Overview on page 686
685
Configuration on page 687
Configuring WCCP on the Aggregation Hub on page 691
Verification on page 695
Requirements
Two M7i or MX Series Juniper Networks routers with a MS-PIC and MS-DPC installed.
Overview
WCCP delivers transparent application acceleration by dynamically forwarding relevant
traffic to one or more off path cache instances. The results include optimized resource
utilization, reduced response time, improved user experience, and increased productivity.
WCCP supports the following features:
686
GRE encapsulation for forwarded traffic
Layer 2-rewrite for forwarded traffic
GRE encapsulation for returned traffic
Layer 2-rewrite for returned traffic
Dynamic services
Topology
Figure 83: WAN Acceleration Employing WCCP Full Package
Configuration
Installing the WCCP Full Package on the Branch Router on page 687
Configuring Interfaces on the Branch Router on page 688
Configuring WCCP on the Branch Router on page 689
Configuring Forward Traffic Steering on the Branch Router on page 690
Configuring Return Traffic Steering on the Branch Router on page 691
Installing the WCCP Full Package on the Branch Router

Step-by-Step
Procedure
1.

[edit]
commercial
2.

[edit]
no-validate

Publications
687
3.

[edit]
4.

[edit]
commit
Results
Verify that the WCCP package is installed.

Model: m7i
. . .
Configuring Interfaces on the Branch Router

Step-by-Step
Procedure
1.

[edit]
2.

[edit]
3.

[edit]
4.

[edit]
5.

[edit]
688
6.

[edit]
edit interfaces lo0
7.
[edit]
Configuring WCCP on the Branch Router

Step-by-Step
Procedure
method.
1.

[edit]
set control-cores 2
set data-cores 3
2.
[edit]
edit wccp
3.
The service-interface-unit statement identifies the MS-PIC service interface unit

used for processing.
[edit]
edit wccp
689
4.

or both.
The return-method statement assigns the WCCP return method to Layer 2, GRE, or
both.
The assignment-method statement sets the WCCP assignment method to hash or
mask.
[edit]
edit wccp
Configuring Forward Traffic Steering on the Branch Router

Step-by-Step
Procedure
1.

[edit]
2.

[edit]
3.

[edit]
4.

[edit]
690

Configuring Return Traffic Steering on the Branch Router

Step-by-Step
Procedure
1.
skipped.
[edit]
2.

for processing.
[edit]
3.
[edit]
set address 14.4.4.1/24

Step-by-Step
Procedure
1.

[edit]
2.

[edit]
691
3.

[edit]
4.

[edit]
5.

[edit]
set unit 2 family inet input wccp_filter_13.3.3.2
6.
7.
[edit]
edit interfaces lo0
[edit]

Step-by-Step
Procedure
method.
1.

[edit]
set control-cores 2
set data-cores 3
692
2.
value of cache communication timeout which is three times the configured value.
[edit]
edit wccp
3.

[edit]
edit wccp
4.

or both.
The return-method statement assigns the WCCP return method to Layer 2, GRE,
or both.
The assignment-method statement sets the WCCP assignment method to hash
or mask.
[edit]
edit wccp
Configuring Forward Traffic Steering on the Aggregation Hub

Step-by-Step
Procedure
1.

[edit]
2.
693
[edit]
3.

[edit]
4.

[edit]
Configuring Return Traffic Steering on the Aggregation Hub

Step-by-Step
Procedure
1.
skipped.
[edit]
2.

for processing.
[edit]
3.
[edit]
694
Verification
Purpose
Action

Interface
Admin Link Proto
gr-0/1/0
up
up
gr-0/1/0.1
up
up
inet
Local
Remote
1.1.1.2/24

PING 1.1.1.1 (1.1.1.1): 56 data bytes
^C
200.1.1.1/32
*[OSPF/10] 20:47:55, metric 1

> to 10.1.1.2 via ge-0/0/2.0

hidden)
0.0.0.0/0
*[Static/5] 20:45:50
> via ms-0/1/0.2

6.1.1.0/24
*[Static/5] 20:45:59
> to 1.1.1.1 via gr-0/1/0.1

hidden)
0.0.0.0/0
Meaning
*[Static/5] 20:45:59
> via ms-0/1/0.2
running.
695
Verifying WCCP
Purpose
Action

Last HIM
61
14.4.4.2
Yes
Sep 24 2013 17:28:36 UTC
61
14.4.4.3
No
Sep 24 2013 17:28:29 UTC
Status
Receive ID
Assigned Time
Assigned
424334100
20:26
Assigned
424334099
20:26

Service ID: 61
Designated: Yes
Status: Assigned
Return Method: GRE
Last HIM: Sep 24 2013 17:28:36 UTC
Designated: No
Status: Assigned
Return Method: GRE
Last HIM: Sep 24 2013 17:28:39 UTC
Meaning
properly.
696
and return method.
CHAPTER 16
Enterprise WAN Troubleshooting

Scenarios
Troubleshooting Scenario: IPsec Branch on page 698
Troubleshooting Scenario: Stateful Firewall and NAT Troubleshooting on page 700
Troubleshooting Scenario: Convergence on page 703
Troubleshooting Scenario: Multicast on page 705
Troubleshooting Scenario: Class of Service on page 710
697
Troubleshooting Scenario: IPsec Branch

Problem
This troubleshooting scenario shows how to troubleshoot and repair branch GRE over
IPsec transport that is not functioning properly.
If the VPN (GRE over IPsec) service is not passing traffic properly to the primary VPN
server, use the following troubleshooting steps from the VPN router 1:
1.
Check to see if the branch gateway is reachable

regress@effenberg> show route 1.1.0.2
HOSTED-WWW-NAT.inet.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
0.0.0.0/0
*[Static/5] 03:20:30
> to 172.31.255.53 via ge-1/1/1.1

0.0.0.0/0
*[Static/5] 03:20:30
> to 198.51.100.5 via ge-1/1/1.0

hidden)
0.0.0.0/0
*[OSPF/175] 03:09:42, metric 0, tag 0

> to 172.31.254.13 via ge-1/1/0.0
regress@effenberg> ping 1.1.0.2 routing-instance VPN

PING 1.1.0.2 (1.1.0.2): 56 data bytes
^C
2. Check the MTU on the Internet-facing Internet gateway
regress@effenberg> show interfaces ge-1/1/1
Link-level type: Ethernet, MTU: 1518, MRU: 1526, Speed: 1000mbps, BPDU Error:
None, MAC-REWRITE Error: None, Loopback: Disabled, Source filtering: Disabled,
Pad to minimum frame size: Disabled
Device flags
: Present Running
CoS queues
Current address: 08:81:f4:88:d9:81, Hardware address: 08:81:f4:88:d9:81
Last flapped
: 2013-11-13 14:36:57 PST (03:23:31 ago)
Input rate
: 449925696 bps (176365 pps)
Output rate
: 438816936 bps (173311 pps)
698
Chapter 16: Enterprise WAN Troubleshooting Scenarios
Description: --- IPsec tunnels termination VLAN ( Jbus ge-1/2/6 ) --Flags: Up SNMP-Traps 0x0 VLAN-Tag [ 0x8100.1 ] Encapsulation: ENET2
198.51.100.7
Protocol multiservice, MTU: UnlimitedAdd the following script.
[edit]
3. Verify the IKE security association
regress@effenberg> show services ipsec-vpn ike security-associations 1.1.0.2 detail
IKE peer 1.1.0.2
Role: Responder, State: Matured
Initiator cookie: f9fd11d9721cf32e, Responder cookie: 68fb472ba04d35ee
Local: 198.51.100.6, Remote: 1.1.0.2
Algorithms:
Authentication
: hmac-sha1-96
Encryption
: aes128-cbc
Diffie-Hellman group : 2
Traffic statistics:
Input bytes :
112388
Output bytes :
111668
Input packets:
1210
Output packets:
1201
4. Verify the IPsec security association
regress@effenberg> show services ipsec-vpn ipsec security-associations
IPsec inside interface: ms-0/2/0.1, Tunnel MTU: 1500
Direction SPI
AUX-SPI
Mode
Type
Protocol
inbound
3895211860 0
tunnel
dynamic ESP
outbound 2053749959 0
tunnel
dynamic ESP
5. Verify the IPsec security association
regress@effenberg> show services ipsec-vpn ipsec security-associations
IPsec inside interface: ms-0/2/0.1, Tunnel MTU: 1500
Direction SPI
AUX-SPI
Mode
Type
Protocol
inbound
3895211860 0
tunnel
dynamic ESP
outbound 2053749959 0
tunnel
dynamic ESP
6. Verify that the lo0 (loopback interface) of the remote branch is reachable
regress@effenberg> show route 172.16.1.255 table VPN.inet.0 detail
172.16.1.255/32 (1 entry, 1 announced)
*Static Preference: 1
699
Next hop type: Router, Next hop index: 8873

Address: 0x7a63580
Next-hop reference count: 3079
Next hop: via ms-0/2/0.1, selected
Session Id: 0x9
State: <Active Int>
Age: 3:25:40
Validation State: unverified
Task: RPD Unix Domain Server./var/run/rpd_serv.local
Announcement bits (3): 0-RT 2-KRT 3-Resolve tree 3
AS path: I
AS path: Recorded
7. Verify that the GRE interface is UP

shoregress@effenberg> show interfaces gr-1/0/0.1
Flags: Up Point-To-Point SNMP-Traps 0x0 IP-Header
Flags: User-MTU
Destination: fe80::/64, Local: fe80::a81:f410:88:d9ef
8. Verify that GRE endpoint on branch is reachable
regress@effenberg> ping 172.16.1.2 routing-instance WAN-GRE
regress@effenberg> ping 172.16.1.2 routing-instance WAN-GRE
PING 172.16.1.2 (172.16.1.2): 56 data bytes
^C
9. Clear IPsec & IKE security associations (SAs)

regress@effenberg> clear services ipsec-vpn ike security-associations
regress@effenberg> clear services ipsec-vpn ipsec security-associations
Troubleshooting Scenario: Stateful Firewall and NAT Troubleshooting

Problem
700
This troubleshooting scenario shows how to troubleshoot and repair SFW and NAT
services.
If the SFW/NAT policy is not working properly (no hits, traffic drops, SFW/NAT not working
at all), use the following troubleshooting steps from the primary Internet Gateway:
1.
Verify the NAT pool

regress@jbus> show services nat pool detail
NAT pool: public-pool, Translation type: dynamic
Address range: 204.164.100.1-204.164.100.254
Port range: 3000-10000, Ports in use: 6, Out of port errors: 0, Max ports
used: 32
AP-P out of port errors: 0
Current EIF Inbound flows count: 0
EIF flow limit exceeded drops: 0
Interface: sp-3/0/0, Service set: NAT-HOSTED-WEB
NAT pool: www-addr, Translation type: static
Address range: 172.31.254.49-172.31.254.62
Current EIF Inbound flows count: 0
EIF flow limit exceeded drops: 0
Description: --- IPsec tunnels termination VLAN ( Jbus ge-1/2/6 ) --Flags: Up SNMP-Traps 0x0 VLAN-Tag [ 0x8100.1 ] Encapsulation: ENET2
198.51.100.7
Protocol multiservice, MTU: UnlimitedAdd the following script.
[edit]
2. Verify routing in both directions (Branch DC to Internet)
regress@jbus> show route 0.0.0.0
0.0.0.0/0
*[BGP/170] 01:05:05, localpref 200

> to 198.51.100.1 via ge-1/2/5.0

holddown, 0 hidden)
0.0.0.0/0
*[Static/5] 01:07:33
> via sp-3/0/0.1
3. Verify routing from Internet to branch site

regress@@jbus> show route 204.164.100.0/24
204.164.100.0/24
*[Static/1] 01:09:33
701
> via sp-3/0/0.2
4. Verify Stateful firewall Flows

regress@jbus> show services stateful-firewall flows
Flow
State
Dir
count
UDP
172.16.3.37:55299 ->
192.168.60.63:8787
Forward
2
NAT source
172.16.3.37:55299
->
204.164.100.1:3011
TCP
172.31.255.2:54175 ->
172.31.255.6:179
Forward
1
NAT source
172.31.255.2:54175
->
204.164.100.1:3016
TCP
172.31.255.6:179
->
204.164.100.1:3016
Forward
0
NAT dest
204.164.100.1:3016
->
172.31.255.2:54175
UDP
192.168.60.63:8787
->
204.164.100.1:3011
Forward
0
NAT dest
204.164.100.1:3011
->
172.16.3.37:55299
TCP
172.31.255.5:639
->
204.164.100.1:3015
Forward
0
NAT dest
204.164.100.1:3015
->
172.31.255.2:54946
TCP
172.31.255.2:54946 ->
172.31.255.5:639
Forward
1
NAT source
172.31.255.2:54946
->
204.164.100.1:3015
UDP
172.16.2.2:55834 ->
192.168.60.63:8787
Forward
2
NAT source
172.16.2.2:55834
->
204.164.100.1:3007
UDP
172.31.255.2:33018 -> 172.31.255.100:2055
Forward
363
NAT source
172.31.255.2:33018
->
204.164.100.1:3043
UDP
172.31.255.51:2055
->
204.164.100.1:3051
Forward
0
NAT dest
204.164.100.1:3051
->
172.16.5.249:33018
UDP
172.16.5.249:33018 ->
172.31.255.51:2055
Forward
421
NAT source
172.16.5.249:33018
->
204.164.100.1:3051
UDP
172.31.255.100:2055
->
204.164.100.1:3043
Forward
0
NAT dest
204.164.100.1:3043
->
172.31.255.2:33018
UDP
192.168.60.63:8787
->
204.164.100.1:3007
Forward
0
NAT dest
204.164.100.1:3007
->
172.16.2.2:55834
Frm
I
5. Verify stateful firewall flows for a specific branch

regress@jbus> show services stateful-firewall flows source-prefix 172.31.255.2 extensive
Flow
State
Dir
Frm
count
UDP
172.31.255.2:33018 -> 172.31.255.100:2055
Forward I
369
NAT source
172.31.255.2:33018
->
204.164.100.1:3043
Byte count: 50184
Flow role: Master, Timeout: 25
UDP
172.31.255.2:33073 -> 172.31.255.100:2055
Forward I
2
NAT source
172.31.255.2:33073
->
204.164.100.1:3034
Byte count: 164
702
Flow role: Master, Timeout: 5
regress@jbus> show services stateful-firewall statistics

Interface
Service set
Accept
Discard
sp-3/0/0
NAT-Branch-internet
18567
5
sp-3/0/0
NAT-HOSTED-WEB
52445465
46475840
0
Reject
Errors
0
5
0
6. Verify NAT-HOSTED-WEB routes from branch/dc to Internet Verify routing

shoregress@jbus> show route 198.51.100.224/28
198.51.100.224/28
*[Static/1] 01:15:31
Service to NAT-HOSTED-WEB
Troubleshooting Scenario: Convergence

Problem
This troubleshooting scenario shows how to troubleshoot and repair convergence on the
EWAN solution.
If the network is converging slowly or not at all, use the following troubleshooting steps
from the primary Internet Gateway:
1.
Verify the Routing Engine protection firewall filter

regress@jbus> show firewall filter RE-PROTECT-lo0.0-i detail
Counters:
Name
accept-bfd-lo0.0-i
0
access-in-lo0.0-i
bgp-in-lo0.0-i
frag-attack-lo0.0-i
0
icmp-in-lo0.0-i
18
loopback-in-lo0.0-i
0
ospf-in-lo0.0-i
0
radius-lo0.0-i
0
0
snmp-in-lo0.0-i
18
tacacs-lo0.0-i
0
udp-in-lo0.0-i
Policers:
Bytes
0
Packets
38066
41325
0
724
670
1064
316118
0
2354
0
0
0
1322
0
3085824
18816
703
Name
0
0
0
0
0
Bytes
0
Packets
0
0
0
0
2. Verify PFE traffic statistics (look for packet drops in the output)
regress@jbus> show pfe statistics traffic
Packet Forwarding Engine traffic statistics:
Input packets:
154251005
851 pps
Output packets:
154253246
856 pps
Packet Forwarding Engine local traffic statistics:
Local packets input
:
5369
Local packets output
:
3999
Software input control plane drops :
0
Software input high drops
:
0
Software input medium drops
:
0
Software input low drops
:
0
Software output drops
:
0
Hardware input drops
:
0
Packet Forwarding Engine local protocol statistics:
HDLC keepalives
:
0
ATM OAM
:
0
Frame Relay LMI
:
0
PPP LCP/NCP
:
0
OSPF hello
:
539
OSPF3 hello
:
0
RSVP hello
:
0
LDP hello
:
0
BFD
:
10656
IS-IS IIH
:
0
LACP
:
0
ARP
:
33
ETHER OAM
:
0
Unknown
:
1014
Packet Forwarding Engine hardware discard statistics:
Timeout
:
0
Truncated key
:
0
Bits to test
:
0
Data error
:
0
Stack underflow
:
0
Stack overflow
:
0
Normal discard
:
7
Extended discard
:
0
Invalid interface
:
0
Info cell drops
:
0
Fabric drops
:
0
Packet Forwarding Engine Input IPv4 Header Checksum Error and Output MTU Error
statistics:
Input Checksum
:
0
Output MTU
:
0
704
Troubleshooting Scenario: Multicast

Problem
This troubleshooting scenario shows how to troubleshoot and repair multicast issues on
the enterprise WAN
If multicast is not converging or performing poorly, use the following troubleshooting
steps from the primary Internet Gateway:
1.
Verify that PIM is configured and working

regress@jboat# run show pim neighbors
Interface
IP
ge-1/2/2.0
4
ge-1/2/5.0
4
ge-1/3/2.0
4
xe-0/0/2.0
4
V Mode
2
2
2
2
Option
HPLGT
HPLGT
HPLGT
HPLGT
1d
1d
1d
1d
Uptime
02:41:00
02:41:00
02:41:00
00:07:48
Neighbor addr
172.31.254.14
172.31.254.33
172.31.254.42
172.31.241.10
2. Verify that MDSP is configured and working properly

regress@jboat# run show msdp
Peer address
Local address
172.31.255.5
172.31.255.2
State
SA Count
0/0
3. Verify that the RP (rendezvous point) is configured and working properly

regress@jboat# run show pim rps extensive
address-family INET
RP: 172.31.255.15
Mode: Sparse
Holdtime: 150
Device Index: 144
Subunit: 32769
Group Ranges:
224.0.0.0/4
Register State for RP:
Group
Source
FirstHop
235.1.1.1
172.31.252.10
172.31.255.8
134
235.1.1.2
172.31.252.10
172.31.255.8
132
235.2.1.1
172.31.252.10
172.31.255.8
131
235.2.1.2
172.31.252.10
172.31.255.8
139
235.2.1.3
172.31.252.10
172.31.255.8
140
RP Address
State
Timeout
172.31.255.15
Receive
172.31.255.15
Receive
172.31.255.15
Receive
172.31.255.15
Receive
172.31.255.15
Receive
705
235.2.1.4
140
235.2.1.5
135
235.2.1.6
136
235.2.1.7
137
235.2.1.8
138
235.3.1.1
135
235.3.1.2
135
235.3.1.3
136
235.3.1.4
131
235.3.1.5
131
235.3.1.6
131
235.3.1.7
132
235.3.1.8
132
235.3.1.9
132
235.3.1.10
132
235.3.1.11
132
235.3.1.12
132
235.3.1.13
132
235.3.1.14
132
235.3.1.15
132
235.4.1.1
141
235.4.1.2
142
235.4.1.3
130
235.4.1.4
143
235.4.1.5
144
235.4.1.6
133
235.4.1.7
129
235.4.1.8
145
235.4.1.9
146
235.4.1.10
131
235.4.1.11
706
172.31.252.10
172.31.255.8
172.31.255.15
Receive
172.31.252.10
172.31.255.8
172.31.255.15
Receive
172.31.252.10
172.31.255.8
172.31.255.15
Receive
172.31.252.10
172.31.255.8
172.31.255.15
Receive
172.31.252.10
172.31.255.8
172.31.255.15
Receive
172.31.252.10
172.31.255.8
172.31.255.15
Receive
172.31.252.10
172.31.255.8
172.31.255.15
Receive
172.31.252.10
172.31.255.8
172.31.255.15
Receive
172.31.252.10
172.31.255.8
172.31.255.15
Receive
172.31.252.10
172.31.255.8
172.31.255.15
Receive
172.31.252.10
172.31.255.8
172.31.255.15
Receive
172.31.252.10
172.31.255.8
172.31.255.15
Receive
172.31.252.10
172.31.255.8
172.31.255.15
Receive
172.31.252.10
172.31.255.8
172.31.255.15
Receive
172.31.252.10
172.31.255.8
172.31.255.15
Receive
172.31.252.10
172.31.255.8
172.31.255.15
Receive
172.31.252.10
172.31.255.8
172.31.255.15
Receive
172.31.252.10
172.31.255.8
172.31.255.15
Receive
172.31.252.10
172.31.255.8
172.31.255.15
Receive
172.31.252.10
172.31.255.8
172.31.255.15
Receive
172.31.252.10
172.31.255.8
172.31.255.15
Receive
172.31.252.10
172.31.255.8
172.31.255.15
Receive
172.31.252.10
172.31.255.8
172.31.255.15
Receive
172.31.252.10
172.31.255.8
172.31.255.15
Receive
172.31.252.10
172.31.255.8
172.31.255.15
Receive
172.31.252.10
172.31.255.8
172.31.255.15
Receive
172.31.252.10
172.31.255.8
172.31.255.15
Receive
172.31.252.10
172.31.255.8
172.31.255.15
Receive
172.31.252.10
172.31.255.8
172.31.255.15
Receive
172.31.252.10
172.31.255.8
172.31.255.15
Receive
172.31.252.10
172.31.255.8
172.31.255.15
Receive
147
235.4.1.12
172.31.252.10
147
235.4.1.13
172.31.252.10
148
235.4.1.14
172.31.252.10
130
235.4.1.15
172.31.252.10
149
235.4.1.16
172.31.252.10
134
235.4.1.17
172.31.252.10
150
235.4.1.18
172.31.252.10
151
235.4.1.19
172.31.252.10
129
235.4.1.20
172.31.252.10
129
235.4.1.21
172.31.252.10
131
235.4.1.22
172.31.252.10
134
235.4.1.23
172.31.252.10
131
235.4.1.24
172.31.252.10
131
235.4.1.25
172.31.252.10
131
Anycast PIM local address used:
172.31.255.8
172.31.255.15
Receive
172.31.255.8
172.31.255.15
Receive
172.31.255.8
172.31.255.15
Receive
172.31.255.8
172.31.255.15
Receive
172.31.255.8
172.31.255.15
Receive
172.31.255.8
172.31.255.15
Receive
172.31.255.8
172.31.255.15
Receive
172.31.255.8
172.31.255.15
Receive
172.31.255.8
172.31.255.15
Receive
172.31.255.8
172.31.255.15
Receive
172.31.255.8
172.31.255.15
Receive
172.31.255.8
172.31.255.15
Receive
172.31.255.8
172.31.255.15
Receive
172.31.255.8
172.31.255.15
Receive
172.31.255.2
4. Verify that multicast routing is working both upstream and downstream

regress@jboat# run show pim rps extensive
@jboat> show multicast route extensive
Group: 235.1.1.1
Source: 172.31.252.10/32
ge-1/2/0.0
## Via GRE over IPSEC branch
## Next hop ID should not be NULL
Route state: Active
Uptime: 00:07:38
Group: 235.1.1.2
Source: 172.31.252.10/32
ge-1/2/0.0
707

Route state: Active
Uptime: 00:07:38
Group: 235.2.1.1
Source: 172.31.252.10/32
ge-1/2/5.0
### via MPLS Transport
Route state: Active
Uptime: 00:07:38
5. Verify the next-hop ID for multicast

regress@jboat> show multicast next-hops 1048583 detail
Family: INET
ID
Refcount KRefcount Downstream interface
1048583
4
2 ge-1/2/0.0-(1048582)
6. Verify multicast traffic statistics

regress@jboat> show multicast statistics
Interface: local
Routing protocol:
Mismatch:
0
Kernel resolve:
0
Resolve no route:
0
Resolve filtered:
0
In kbytes:
0
Out kbytes:
0
Routing protocol:
PIM
Mismatch:
0
Kernel resolve:
0
Resolve no route:
0
Resolve filtered:
0
In kbytes:
0
Out kbytes:
0
Routing protocol:
PIM
Mismatch:
0
Kernel resolve:
0
Resolve no route:
0
Resolve filtered:
0
In kbytes:
0
Out kbytes:
117526
708
Mismatch error:
Mismatch no route:
Routing notify:
Resolve error:
Notify filtered:
In packets:
Out packets:
0
0
0
0
0
0
0
Mismatch error:
Mismatch no route:
Routing notify:
Resolve error:
Notify filtered:
In packets:
Out packets:
0
0
0
0
0
0
0
Mismatch error:
Mismatch no route:
Routing notify:
Resolve error:
Notify filtered:
In packets:
Out packets:
0
0
0
0
0
0
245606
Routing protocol:
PIM
Mismatch error:
0
Mismatch:
0
Mismatch no route:
0
Kernel resolve:
0
Routing notify:
0
Resolve no route:
0
Resolve error:
0
Resolve filtered:
0
Notify filtered:
0
In kbytes:
0
In packets:
0
Out kbytes:
1346890
Out packets:
5894087
Routing protocol:
PIM
Mismatch error:
0
Mismatch:
0
Mismatch no route:
0
Kernel resolve:
0
Routing notify:
0
Resolve no route:
0
Resolve error:
0
Resolve filtered:
0
Notify filtered:
0
In kbytes:
0
In packets:
0
Out kbytes:
0
Out packets:
0
Interface: xe-0/0/2.0
Routing protocol:
PIM
Mismatch error:
0
Mismatch:
0
Mismatch no route:
0
Kernel resolve:
50
Routing notify:
91
Resolve no route:
0
Resolve error:
0
Resolve filtered:
0
Notify filtered:
0
In kbytes:
1464417
In packets:
6139693
Out kbytes:
0
Out packets:
0
Resolve requests on interfaces not enabled for multicast 0
Resolve requests with no route to source 0
Routing notifications on interfaces not enabled for multicast 0
Routing notifications with no route to source 0
Interface mismatches on interfaces not enabled for multicast 0
Group memberships on interfaces not enabled for multicast 0
Resolve requests on interfaces not enabled for multicast 0
Resolve requests with no route to source 0
Routing notifications on interfaces not enabled for multicast 0
Routing notifications with no route to source 0
Interface mismatches on interfaces not enabled for multicast 0
Group memberships on interfaces not enabled for multicast 0
709
Troubleshooting Scenario: Class of Service

Problem
This troubleshooting scenario shows how to troubleshoot class of service on the enterprise
WAN.
Troubleshoot from the branch officeIf class of service is not functioning properly, use
the following troubleshooting steps from the branch office:
1.
Verify queue statistics on the GRE interface

regress@pixo> show interfaces queue gr-0/0/0
Burst size: 0
Queued:
Packets
:
885005329
Bytes
:
305527760825
Transmitted:
Packets
:
884970031
Bytes
:
305514191073
12814
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
RED-dropped bytes
:
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
Queued:
Packets
:
0
Bytes
:
0
Transmitted:
Packets
:
0
Bytes
:
0
0
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
RED-dropped bytes
:
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
710
2810 pps
7056352 bps
2810 pps
7056352 bps
0 pps
0 pps
0 pps
0 pps
0 pps
0 pps
0 bps
0 bps
0 bps
0 bps
0 bps
0 pps
0 bps
0 pps
bps
pps
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
0
0
0
0
0
0
0
0
0
0
0
0

Queued:
Packets
:
Bytes
:
Transmitted:
Packets
:
Bytes
:
Low
:
Medium-low
:
Medium-high
:
High
:
RED-dropped bytes
:
Low
:
Medium-low
:
Medium-high
:
High
:
Queued:
Packets
:
Bytes
:
Transmitted:
Packets
:
Bytes
:
Low
:
Medium-low
:
Medium-high
:
High
:
RED-dropped bytes
:
Low
:
Medium-low
:
Medium-high
:
High
:
Queued:
Packets
:
Bytes
:
Transmitted:
Packets
:
Bytes
:
Low
:
Medium-low
:
Medium-high
:
High
:
RED-dropped bytes
:
Low
:
Medium-low
:
Medium-high
:
High
:
Queued:
Packets
:
Bytes
:
Transmitted:
Packets
:
Bytes
:
Bulk_Data
258064556
133161310896
258061413
133159689108
100
0
0
0
0
0
0
0
0
0
0
Critical_Data
802 pps
3313096 bps
802 pps
3313096 bps
0 pps
0 pps
0 pps
0 pps
0 pps
0 pps
0 bps
0 bps
0 bps
0 bps
0 bps
259502429
100242302632
804 pps
2492488 bps
259500402
100241526076
109
0
0
0
0
0
0
0
0
0
0
804 pps
2492488 bps
0 pps
0 pps
0 pps
0 pps
0 pps
0 pps
0 bps
0 bps
0 bps
0 bps
0 bps
Video
161365394
83264543304
501 pps
2070168 bps
161364038
83263843608
0
0
0
0
0
0
0
0
0
0
0
501 pps
2070168 bps
0 pps
0 pps
0 pps
0 pps
0 pps
0 pps
0 bps
0 bps
0 bps
0 bps
0 bps
419730795
55404464940
1104 pps
1166016 bps
419728166
55404117912
1104 pps
1166016 bps
Voice
711
0
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
RED-dropped bytes
:
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
Queued:
Packets
:
161303708
Bytes
:
41938864606
Transmitted:
Packets
:
161300653
Bytes
:
41938070460
1857
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
RED-dropped bytes
:
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
0
0
0
0
0
0
0
0
0
0
0
pps
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
501 pps
1044144 bps
501 pps
1044144 bps
0 pps
0 pps
0 pps
0 pps
0 pps
0 pps
0 bps
0 bps
0 bps
0 bps
0 bps
2. Verify the scheduler map configuration

regress@jboat# run show msdp
Peer address
Local address
172.31.255.5
172.31.255.2
State
SA Count
0/0
@pixo> show class-of-service scheduler-map MAIN-SCHD

Scheduler map: MAIN-SCHD, Index: 5286
Scheduler: SCH_Best_Effort, Forwarding class: Best_Effort, Index: 37911
Transmit rate: remainder, Rate Limit: none, Buffer size: remainder,
Buffer Limit: none, Priority: medium-low
Excess Priority: unspecified
Drop profiles:
Loss priority
Protocol
Index
Name
Low
any
1
<default-drop-profile>
Medium low
any
1
Medium high
any
1
High
any
1
Scheduler: SCH_Scavenger, Forwarding class: Scavenger, Index: 39450
Transmit rate: 3 percent, Rate Limit: none, Buffer size: 10 percent,
Buffer Limit: none, Priority: low
Drop profiles:
Loss priority
Protocol
Index
Name
Low
any
1
Medium low
any
1
Medium high
any
1
High
any
1
712
Scheduler: SCH_Bulk_Data, Forwarding class: Bulk_Data, Index: 59439

Transmit rate: 20 percent, Rate Limit: none, Buffer size: 15 percent,
Buffer Limit: none, Priority: medium-low
Drop profiles:
Loss priority
Protocol
Index
Name
Low
any
1
Medium low
any
1
Medium high
any
1
High
any
1
Scheduler: SCH_Critical_Data, Forwarding class: Critical_Data, Index: 65395
Transmit rate: 15 percent, Rate Limit: exact, Buffer size: 15 percent,
Buffer Limit: exact, Priority: medium-high
Drop profiles:
Loss priority
Protocol
Index
Name
Low
any
1
Medium low
any
1
Medium high
any
1
High
any
1
Scheduler: SCH_Video, Forwarding class: Video, Index: 63120
Buffer Limit: exact, Priority: high
Drop profiles:
Loss priority
Protocol
Index
Name
Low
any
1
Medium low
any
1
Medium high
any
1
High
any
1
Scheduler: SCH_VOICE, Forwarding class: Voice, Index: 18025
Transmit rate: 7 percent, Rate Limit: none, Buffer size: remainder,
Buffer Limit: none, Priority: strict-high
Shaping rate: 10 percent
Drop profiles:
Loss priority
Protocol
Index
Name
Low
any
1
Medium low
any
1
Medium high
any
1
High
any
1
Scheduler: SCH_Network_Control, Forwarding class: Network_Control, Index:
8683
Buffer Limit: exact, Priority: high
Drop profiles:
Loss priority
Protocol
Index
Name
Low
any
1
Medium low
any
1
Medium high
any
1
High
any
1
3. Verify the rewrite rules for egress traffic on the branch
regress@pixo> show class-of-service rewrite-rule
713
Rewrite rule: Rewrite_CORE_TRAFFIC, Code point type: dscp, Index: 51863

Forwarding class
Loss priority
Code point
Best_Effort
medium-high
000000
Scavenger
high
001000
Bulk_Data
medium-high
001010
Critical_Data
medium-low
010010
Video
low
100010
Voice
low
101110
Network_Control
low
111000
Rewrite rule: Rewrite_CORE_TRAFFIC, Code point type: dscp-ipv6, Index: 51862

Forwarding class
Loss priority
Code point
Best_Effort
medium-high
000000
Scavenger
high
001000
Bulk_Data
medium-high
001010
Critical_Data
medium-low
010010
Video
low
100010
Voice
low
101110
Network_Control
low
111000
4. Verify traffic shaping rate on the egress interface

regress@pixo> show class-of-service
Scheduler map: <default-chassis>, Index: 4
Object
Name
Index
Scheduler-map
MAIN-SCHD
5286
Rewrite
Video_Voice
27178
Rewrite
51862
Classifier
DSCP-BA
961
Classifier
DSCP-BA
960
Object
Name
Index
Scheduler-map
MAIN-SCHD
5286
Rewrite
Video_Voice
27178
Rewrite
51862
Classifier
DSCP-BA
961
Classifier
DSCP-BA
960
714
Type
Output
dscp
dscp-ipv6
dscp
dscp-ipv6
Type
Output
dscp
dscp-ipv6
dscp
dscp-ipv6
Troubleshoot from the Internet edge routerIf class of service is not functioning properly,
use the following troubleshooting steps:
1.
Verify queue statistics on the ingress interface:

regress@jbus# run show interfaces ge-1/2/5 extensive
Device flags
: Present Running
Link flags
: None
CoS queues
Schedulers
: 0
Hold-times
Current address: 2c:21:72:b2:99:f3, Hardware address: 2c:21:72:b2:99:f3
Last flapped
: 2013-06-18 08:06:12 PDT (22:58:50 ago)
Traffic statistics:
Input bytes :
4229151344160
561619168 bps
Output bytes :
4220510907769
546579856 bps
Input packets:
12356255054
202845 pps
Output packets:
12804873648
208178 pps
Input bytes :
0
Output bytes :
0
Input packets:
0
Output packets:
0
Input bytes :
0
Output bytes :
0
Input packets:
0
Output packets:
0
Input errors:
0,
Resource errors: 0
Output errors:
Queue counters:
Dropped packets
0 INTERNET
2150324114
2150324114
1 expedited-fo
2 assured-forw
3 network-cont
10654624152
10654624152
6930
6930
0
0
0
0
4 BRANCH
0
7 Network_Cont
0
715
Queue number:
0
INTERNET
1
expedited-forwarding
2
assured-forwarding
3
network-control
4
BRANCH
7
Network_Control
MAC statistics:
Receive
Transmit
Total octets
4229139655321
4220500361901
Total packets
12356221175
12804839382
Unicast packets
12356221135
12804839353
Broadcast packets
40
37
Multicast packets
0
0
CRC/Align errors
0
0
FIFO errors
0
0
MAC control frames
0
0
MAC pause frames
0
0
Oversized frames
0
Jabber frames
0
Fragment frames
0
VLAN tagged frames
0
Code violations
0
Total errors
0
0
Filter statistics:
Input packet count
12355818357
0
Input DA rejects
0
Input SA rejects
0
Output packet count
12804425207
0
0
Link partner:
fault: OK
Local resolution:
CoS information:
Direction : Output
CoS transmit queue
Bandwidth
Buffer Priority
Limit
%
bps
%
usec
0 INTERNET
20
160000000
r
0
low
none
4 BRANCH
79
632000000
r
0
high
none
7 Network_Control
1
8000000
r
0 strict-high
exact
159)
18 bytes
716

:
18 bytes
Traffic statistics:
Input bytes :
4229151344160
Output bytes :
4220510866189
Input packets:
12356255054
Output packets:
12804873648
Local statistics:
Input bytes :
394289
Output bytes :
656703
Input packets:
6203
Output packets:
6930
Transit statistics:
Input bytes :
4229150949871
561619168 bps
Output bytes :
4220510209486
546579856 bps
Input packets:
12356248851
202845 pps
Output packets:
12804866718
208178 pps
Input Filters: ipv4_sample
198.51.100.3, Generation: 151
2. Verify queue statistics for egress traffic

regress@jbus# run show interfaces queue ge-1/2/5 egress
Queue: 0, Forwarding classes: INTERNET
Queued:
Packets
:
2150725561
36826 pps
Bytes
:
725518691918
96455936 bps
Transmitted:
Packets
:
2150725561
36826 pps
Bytes
:
725518691918
96455936 bps
0
0 pps
0
0 pps
Low
:
0
0 pps
Medium-low
:
0
0 pps
Medium-high
:
0
0 pps
High
:
0
0 pps
RED-dropped bytes
:
0
0 bps
Low
:
0
0 bps
Medium-low
:
0
0 bps
Medium-high
:
0
0 bps
High
:
0
0 bps
Queue: 1, Forwarding classes: expedited-forwarding
Queued:
Packets
:
0
0 pps
Bytes
:
0
0 bps
Transmitted:
Packets
:
0
0 pps
Bytes
:
0
0 bps
0
0 pps
0
0 pps
717
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
RED-dropped bytes
:
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
Queue: 2, Forwarding classes: assured-forwarding
Queued:
Packets
:
0
Bytes
:
0
Transmitted:
Packets
:
0
Bytes
:
0
0
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
RED-dropped bytes
:
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
Queue: 3, Forwarding classes: network-control
Queued:
Packets
:
0
Bytes
:
0
Transmitted:
Packets
:
0
Bytes
:
0
0
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
RED-dropped bytes
:
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
Queued:
Packets
:
10656517898
Bytes
:
3751917751504
Transmitted:
Packets
:
10656517898
Bytes
:
3751917751504
0
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
RED-dropped bytes
:
0
Low
:
0
Medium-low
:
0
718
0
0
0
0
0
0
0
0
0
pps
pps
pps
pps
bps
bps
bps
bps
bps
0 pps
0 bps
0
0
0
0
0
0
0
0
0
0
0
0
0
pps
bps
pps
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
0 pps
0 bps
0
0
0
0
0
0
0
0
0
0
0
0
0
pps
bps
pps
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
171242 pps
482972416 bps
171242
482972416
0
0
0
0
0
0
0
0
0
pps
bps
pps
pps
pps
pps
pps
pps
bps
bps
bps
Medium-high
:
0
High
:
0
Queued:
Packets
:
6932
Bytes
:
823262
Transmitted:
Packets
:
6932
Bytes
:
823262
0
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
RED-dropped bytes
:
0
Low
:
0
Medium-low
:
0
Medium-high
:
0
High
:
0
0 bps
0 bps
0 pps
352 bps
0
352
0
0
0
0
0
0
0
0
0
0
0
pps
bps
pps
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
3. Verify CoS configuration

regress@jbus# run show class-of-service interface ge-1/2/5 detail
Description: --- To Public ISP link ( Navami-PE1 ge-1/2/0 ) --Link-level type: Ethernet, MTU: 1514, Speed: 1000mbps, Loopback: Disabled,
Device flags
: Present Running
Link flags
: None
Output traffic control profile: TO-ISP1, Index: 23249
Logical interface ge-1/2/5.0
inet 198.51.100.2/30
multiservice
Interface
Admin Link Proto Input Filter
Output Filter
ge-1/2/5.0
up
up
inet ipv4_sample
multiservice
Interface
Admin Link Proto Input Policer
Output Policer
ge-1/2/5.0
up
up
inet
multiservice __default_arp_policer__
Object
Name
Classifier
Type
ip
Index
13
4. Check to see if the configured policer is blocking traffic

regress@jbus> show firewall
Filter: __default_bpdu_filter__
719
Counters:
Name
accept-bfd-lo0.0-i
0
access-in-lo0.0-i
bgp-in-lo0.0-i
frag-attack-lo0.0-i
0
icmp-in-lo0.0-i
20
loopback-in-lo0.0-i
0
ospf-in-lo0.0-i
0
radius-lo0.0-i
0
0
snmp-in-lo0.0-i
36
tacacs-lo0.0-i
0
udp-in-lo0.0-i
Policers:
Name
0
0
0
0
0
Bytes
0
Packets
17855
60084
0
340
795
1232
270633
0
1635
0
0
0
2644
0
3503368
Bytes
0
21362
Packets
0
0
0
0
Filter: __service-NAT-HOSTED-WEB
Filter: anyany
Counters:
Name
allpkts
0
Filter: discard-all
Counters:
Name
discard-all-TTL_1-unknown
0
discard-icmp
0
discard-ip-options
0
discard-netbios
0
discard-tcp
0
discard-udp
720
Bytes
0
Packets
Bytes
0
Packets
0
0
0
0
0
0
discard-unknown
0
Filter: ipv4_sample
Troubleshoot from the VPN termination routerIf class of service is not functioning
properly, use the following troubleshooting steps:
1.
Verify CoS configuration on the GRE and WAN AGG-facing interface

regress@effenberg> show class-of-service interface ge-1/1/0
Object
Name
Classifier
DSCP-BA
Classifier
DSCP-BA
Type
dscp
dscp-ipv6
Index
961
960
regress@effenberg> show class-of-service interface gr-1/0/0.1

Object
Name
Type
Traffic-control-profile SMALL-BRANCH
Output
Classifier
Classifier
ip
Index
14334
9
13
regress@effenberg> show class-of-service interface gr-1/0/0.11

Object
Name
Type
Traffic-control-profile GRE_Emulated_Branch
Output
Classifier
Classifier
ip
Index
2367
9
13
2. Verify shaping rate for the different branch types

regress@effenberg> show class-of-service traffic-control-profile
GRE_Emulated_Branch
Traffic control profile: GRE_Emulated_Branch, Index: 2367
Scheduler map: GRE_Scaled_Branches
regress@effenberg> show class-of-service traffic-control-profile SMALL-BRANCH

Traffic control profile: SMALL-BRANCH, Index: 14334
3. Verify queue statistics

regress@effenberg> show interfaces queue gr-1/0/0
721
Egress queues: 8 supported, 7

Queued:
Packets
:
Bytes
:
Transmitted:
Packets
:
Bytes
:
RL-dropped packets
:
RL-dropped bytes
:
Low
:
Medium-low
:
Medium-high
:
High
:
RED-dropped bytes
:
Low
:
Medium-low
:
Medium-high
:
High
:
Queued:
Packets
:
Bytes
:
Transmitted:
Packets
:
Bytes
:
RL-dropped packets
:
RL-dropped bytes
:
Low
:
Medium-low
:
Medium-high
:
High
:
RED-dropped bytes
:
Low
:
Medium-low
:
Medium-high
:
High
:
Queued:
Packets
:
Bytes
:
Transmitted:
Packets
:
Bytes
:
RL-dropped packets
:
RL-dropped bytes
:
Low
:
Medium-low
:
Medium-high
:
High
:
RED-dropped bytes
:
Low
:
Medium-low
:
Medium-high
:
High
:
722
in use
Best_Effort
10852078976
2802629539734
10852078976
2802629539734
0
0
0
0
0
0
0
0
0
0
0
0
0
Scavenger
167084 pps
344852704 bps
167084
344852704
0
0
0
0
0
0
0
0
0
0
0
0
0
pps
bps
pps
pps
bps
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
0
0
0 pps
0 bps
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
pps
bps
pps
pps
bps
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
Bulk_Data
62532070
31961293132
800 pps
3283200 bps
62532070
31961293132
0
0
0
0
0
0
0
0
0
0
0
0
0
800
3283200
0
0
0
0
0
0
0
0
0
0
0
0
0
pps
bps
pps
pps
bps
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps

Queued:
Packets
:
Bytes
:
Transmitted:
Packets
:
Bytes
:
RL-dropped packets
:
RL-dropped bytes
:
Low
:
Medium-low
:
Medium-high
:
High
:
RED-dropped bytes
:
Low
:
Medium-low
:
Medium-high
:
High
:
Queued:
Packets
:
Bytes
:
Transmitted:
Packets
:
Bytes
:
RL-dropped packets
:
RL-dropped bytes
:
Low
:
Medium-low
:
Medium-high
:
High
:
RED-dropped bytes
:
Low
:
Medium-low
:
Medium-high
:
High
:
Queued:
Packets
:
Bytes
:
Transmitted:
Packets
:
Bytes
:
RL-dropped packets
:
RL-dropped bytes
:
Low
:
Medium-low
:
Medium-high
:
High
:
RED-dropped bytes
:
Low
:
Medium-low
:
Medium-high
:
High
:
Critical_Data
62515685
24009452927
799 pps
2463040 bps
62515685
24009452927
0
0
0
0
0
0
0
0
0
0
0
0
0
799
2463040
0
0
0
0
0
0
0
0
0
0
0
0
0
39063316
20039317076
499 pps
2051360 bps
39063316
20039317076
0
0
0
0
0
0
0
0
0
0
0
0
0
499
2051360
0
0
0
0
0
0
0
0
0
0
0
0
0
85956375
11088434709
1099 pps
1134400 bps
pps
bps
pps
pps
bps
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
Video
pps
bps
pps
pps
bps
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
Voice
85956375
11088434709
0
0
0
0
0
0
0
0
0
0
0
0
0
Network_Control
1099
1134400
0
0
0
0
0
0
0
0
0
0
0
0
0
pps
bps
pps
pps
bps
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
723
Queued:
Packets
Bytes
Transmitted:
Packets
Bytes
RL-dropped packets
RL-dropped bytes
RED-dropped packets
Low
Medium-low
Medium-high
High
RED-dropped bytes
Low
Medium-low
Medium-high
High
:
:
78120505
12936074733
763 pps
1186432 bps
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
78120505
12936074733
0
0
0
0
0
0
0
0
0
0
0
0
0
763
1186432
0
0
0
0
0
0
0
0
0
0
0
0
0
pps
bps
pps
pps
bps
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
Troubleshooting from the WAN aggregation routerIf class of service is not functioning
properly, use the following troubleshooting steps:
1.
Verify CoS configuration on the Data Center-facing link

regress@jboat# run show class-of-service interface xe-0/0/2
Scheduler map: <default>>, Index: 2
Object
Name
Rewrite
DEF_DSCP_REWRITE
Rewrite
DEF_DSCP_REWRITE
Classifier
DSCP-BA
Classifier
DSCP-BA
Type
dscp
dscp-ipv6
dscp
dscp-ipv6
Index
61950
61951
961
960
2. Verify CoS configuration for leased line transport

regress@jboat# run show class-of-service interface t3-1/0/1:1
Physical interface: t3-1/0/1:1, Index: 165
Output traffic control profile: LEASED-LINE, Index: 1475
Logical interface: t3-1/0/1:1.0, Index: 334
Object
Name
Type
Classifier
Classifier
ip
Index
9
13
3. Verify CoS configuration on MPLS transport link

regress@jboat# run show class-of-service interface ge-1/2/5
Output traffic control profile: TO-MPLS-VPN1, Index: 10657
724

Object
Name
Rewrite
DEF_DSCP_REWRITE
Rewrite
DEF_DSCP_REWRITE
Classifier
DSCP-BA
Classifier
DSCP-BA
Type
dscp
dscp-ipv6
dscp
dscp-ipv6
Index
61950
61951
961
960
4. Verify CoS on WAN aggregation 2 link

regress@jboat# run show class-of-service interface ge-1/3/2
Object
Name
Classifier
DSCP-BA
Classifier
DSCP-BA
Type
dscp
dscp-ipv6
Index
961
960
5. Verify shaping configuration

regress@jboat# run show class-of-service traffic-control-profile
Traffic control profile: LEASED-LINE, Index: 1475
Traffic control profile: TO-MPLS-VPN1, Index: 10657
6. Verify interface statistics on DC-facing link

regress@jboat# run show class-of-service traffic-control-profile
Traffic control profile: LEASED-LINE, Index: 1475
Traffic control profile: TO-MPLS-VPN1, Index: 10657
@jboat# run show interfaces xe-0/0/2 extensive
Description: --- To DC-ACCESS router (Magha-DC-ACCESS xe-0/0/2) --Link-level type: Ethernet, MTU: 1514, LAN-PHY mode, Speed: 10Gbps, BPDU
Device flags
: Present Running
Link flags
: None
CoS queues
Hold-times
Last flapped
: 2013-06-18 10:57:39 PDT (1d 00:10 ago)
Traffic statistics:
Input bytes :
7752269351941
795833208 bps
Output bytes :
7814189915614
813114424 bps
725
Input packets:
28211048134
364239 pps
Output packets:
27979629883
361951 pps
Input bytes :
420496306422
Output bytes :
836948546760
Input packets:
1796992770
Output packets:
3576700052
Input bytes :
0
Output bytes :
0
Input packets:
0
Output packets:
0
Input errors:
0,
Resource errors: 0
Output errors:
Resource errors: 0
Queue counters:
Dropped packets
0 Best_Effort
25551424919
25551424919
622892576
622875969
617076089
617076089
458237322
458225556
444989807
444986900
285379194
285377120
0
1 Scavenger
0
2 Bulk_Data
16607
3 Critical_Dat
0
4 Video
11766
5 Voice
2907
6 Network_Cont
2074
Queue number:
0
1
2
3
4
5
6
PCS statistics
Bit errors
Errored blocks
MAC statistics:
Total octets
Total packets
Unicast packets
Broadcast packets
Multicast packets
CRC/Align errors
FIFO errors
MAC control frames
MAC pause frames
726

Best_Effort
Scavenger
Bulk_Data
Critical_Data
Video
Voice
Network_Control
Seconds
1
2
Receive
7754332915577
28211375206
27437394916
45
773980234
0
0
0
0
Transmit
7815845819263
27979953716
27979771866
44
181825
0
0
0
0
Oversized frames
0
Jabber frames
0
Fragment frames
0
VLAN tagged frames
0
Code violations
0
Total errors
0
0
Filter statistics:
Input packet count
28211011680
3461
Input DA rejects
0
Input SA rejects
0
Output packet count
27979593645
0
0
Destination slot: 0
CoS information:
Direction : Output
CoS transmit queue
Bandwidth
Buffer Priority
Limit
%
bps
%
usec
0 Best_Effort
95
9500000000
95
0
low
none
3 Critical_Data
5
500000000
5
0
low
none
Logical interface xe-0/0/2.0 (Index 333) (SNMP ifIndex 566) (Generation 142)
18 bytes
:
18 bytes
Traffic statistics:
Input bytes :
7752269021059
Output bytes :
7814188205420
Input packets:
28211047458
Output packets:
27979629884
Input bytes :
420496305686
Output bytes :
836948546760
Input packets:
1796992769
Output packets:
3576700052
Local statistics:
Input bytes :
211555319
Output bytes :
219102457
Input packets:
379386
Output packets:
285267
Transit statistics:
Input bytes :
7752057465740
795823080
Output bytes :
7813969102963
813102864
Input packets:
28210668072
364238
Output packets:
27979344617
361950
Input bytes :
420496305686
Output bytes :
836948546760
Input packets:
1796992769
Output packets:
3576700052
bps
bps
pps
pps
727

172.31.241.255, Generation: 150
Flags: Is-Primary
Generation: 152
7. Verify interface statistics on MPLS ISP link

regress@jboat# run show interfaces ge-1/2/5 extensive
Description: --- To MPLS_VPN_PROVIDER1 link (Navami ge-1/2/2) --Link-level type: Ethernet, MTU: 1514, Speed: 1000mbps, BPDU Error: None,
Device flags
: Present Running
Link flags
: None
CoS queues
Hold-times
Last flapped
: 2013-06-18 08:24:26 PDT (1d 02:45 ago)
Traffic statistics:
Input bytes :
1638177955079
155628192 bps
Output bytes :
1565920655692
153673744 bps
Input packets:
4644781315
55911 pps
Output packets:
4091824972
49904 pps
Input bytes :
23257065132
Output bytes :
23071774362
Input packets:
99389169
Output packets:
98597273
Input bytes :
0
Output bytes :
0
Input packets:
0
Output packets:
0
Input errors:
0,
Resource errors: 0
Output errors:
Resource errors: 0
Queue counters:
Dropped packets
0 Best_Effort
199603
1 Scavenger
728
1229027701
1228828098
0
2 Bulk_Data
547433581
547398812
34769
3 Critical_Dat
497812815
497779434
33381
4 Video
1129350602
1129337716
12886
5 Voice
450860992
450860992
0
6 Network_Cont
237687401
237682216
5185
Queue number:
0
Best_Effort
1
Scavenger
2
Bulk_Data
3
Critical_Data
4
Video
5
Voice
6
Network_Control
MAC statistics:
Receive
Transmit
Total octets
1639494368647
1567219012228
Total packets
4644850473
4091886629
Unicast packets
4644842207
3364943679
Broadcast packets
45
40
Multicast packets
8218
726942914
CRC/Align errors
0
0
FIFO errors
0
0
MAC control frames
0
0
MAC pause frames
0
0
Oversized frames
0
Jabber frames
0
Fragment frames
0
VLAN tagged frames
0
Code violations
0
Total errors
0
0
Filter statistics:
Input packet count
4644794509
0
Input DA rejects
0
Input SA rejects
0
Output packet count
4091836717
0
0
Link partner:
fault: OK
Local resolution:
Destination slot: 1
CoS information:
Direction : Output
CoS transmit queue
Bandwidth
Buffer Priority
Limit
%
bps
%
usec
0 Best_Effort
r
r
20
0 medium-low
729
none
1 Scavenger
2
8000000
none
2 Bulk_Data
20
80000000
none
3 Critical_Data
15
60000000
none
4 Video
20
80000000
none
5 Voice
6
24000000
exact
6 Network_Control
6
24000000
none
20
low
20
0 medium-high
15
0 medium-high
r
high
0 strict-high
r
high
18 bytes
:
18 bytes
Traffic statistics:
Input bytes :
1638216709719
Output bytes :
1565958726262
Input packets:
4644892556
Output packets:
4091924187
Input bytes :
23257623456
Output bytes :
23072332686
Input packets:
99391555
Output packets:
98599659
Local statistics:
Input bytes :
3572874
Output bytes :
2364779
Input packets:
24393
Output packets:
23831
Transit statistics:
Input bytes :
1638213136845
155927384 bps
Output bytes :
1565956361483
153750600 bps
Input packets:
4644868163
55946 pps
Output packets:
4091900356
49898 pps
Input bytes :
23257623456
Output bytes :
23072332686
Input packets:
99391555
Output packets:
98599659
Policer: Output: to-mpls-ge-1/2/5.0-inet-o
172.31.254.35, Generation: 168
Generation: 170
730
8. Verify queue statistics on ISP-facing link

regress@jboat# run show interfaces queue ge-1/2/5 egress
Description: --- To MPLS_VPN_PROVIDER1 link (Navami ge-1/2/2) --Forwarding classes: 16 supported, 7 in use
Queued:
Packets
:
171037
15300
Bytes
:
61504249
44060576
Transmitted:
Packets
:
171037
15300
Bytes
:
61504249
44060576
0
0
0
0
Low
:
0
0
Medium-low
:
0
0
Medium-high
:
0
0
High
:
0
0
RED-dropped bytes
:
0
0
Low
:
0
0
Medium-low
:
0
0
Medium-high
:
0
0
High
:
0
0
Queued:
Packets
:
0
0
Bytes
:
0
0
Transmitted:
Packets
:
0
0
Bytes
:
0
0
0
0
0
0
Low
:
0
0
Medium-low
:
0
0
Medium-high
:
0
0
High
:
0
0
RED-dropped bytes
:
0
0
Low
:
0
0
Medium-low
:
0
0
Medium-high
:
0
0
High
:
0
0
Queued:
Packets
:
76006
6800
Bytes
:
40131168
28723200
Transmitted:
Packets
:
76006
6800
Bytes
:
40131168
28723200
0
0
0
0
Low
:
0
0
Medium-low
:
0
0
Medium-high
:
0
0
High
:
0
0
RED-dropped bytes
:
0
0
Low
:
0
0
pps
bps
pps
bps
pps
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
pps
bps
pps
bps
pps
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
pps
bps
pps
bps
pps
pps
pps
pps
pps
pps
bps
bps
731
Medium-low
:
Medium-high
:
High
:
Queued:
Packets
:
Bytes
:
Transmitted:
Packets
:
Bytes
:
Low
:
Medium-low
:
Medium-high
:
High
:
RED-dropped bytes
:
Low
:
Medium-low
:
Medium-high
:
High
:
Queued:
Packets
:
Bytes
:
Transmitted:
Packets
:
Bytes
:
Low
:
Medium-low
:
Medium-high
:
High
:
RED-dropped bytes
:
Low
:
Medium-low
:
Medium-high
:
High
:
Queued:
Packets
:
Bytes
:
Transmitted:
Packets
:
Bytes
:
Low
:
Medium-low
:
Medium-high
:
High
:
RED-dropped bytes
:
Low
:
Medium-low
:
Medium-high
:
High
:
Queued:
Packets
:
Bytes
:
732
0
0
0
0 bps
0 bps
0 bps
65946
26378400
5900 pps
18880000 bps
65946
26378400
0
0
0
0
0
0
0
0
0
0
0
5900
18880000
0
0
0
0
0
0
0
0
0
0
0
153691
81148848
13750 pps
58083456 bps
153691
81148848
0
0
0
0
0
0
0
0
0
0
0
13750
58083456
0
0
0
0
0
0
0
0
0
0
0
Critical_Data
pps
bps
pps
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
Video
pps
bps
pps
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
Voice
59799
8611056
59799
8611056
0
0
0
0
0
0
0
0
0
0
0
Network_Control
31296
8512350
5350 pps
6163360 bps
5350
6163360
0
0
0
0
0
0
0
0
0
0
0
pps
bps
pps
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
2800 pps
6093792 bps
Transmitted:
Packets
Bytes
RED-dropped packets
Low
Medium-low
Medium-high
High
RED-dropped bytes
Low
Medium-low
Medium-high
High
:
:
:
:
:
:
:
:
:
:
:
:
:
31296
8512350
0
0
0
0
0
0
0
0
0
0
0
2800
6093792
0
0
0
0
0
0
0
0
0
0
0
pps
bps
pps
pps
pps
pps
pps
pps
bps
bps
bps
bps
bps
9. Check to see if traffic is being dropped by the configured policer

regress@jboat> show firewall
Filter: __default_bpdu_filter__
Counters:
Name
accept-bfd-lo0.0-i
0
access-in-lo0.0-i
bgp-in-lo0.0-i
frag-attack-lo0.0-i
0
icmp-in-lo0.0-i
2
loopback-in-lo0.0-i
0
msdp-lo0.0-i
ospf-in-lo0.0-i
pim-lo0.0-i
radius-lo0.0-i
0
0
snmp-in-lo0.0-i
18
tacacs-lo0.0-i
0
udp-in-lo0.0-i
Policers:
Name
0
0
0
0
Bytes
0
Packets
29264
314414
0
556
1349
168
159641
0
1400
72437
9533156
133560
0
1339
16964
1854
0
1322
0
4823192
Bytes
67183
0
65262
Packets
125
0
1960488
0
1453
0
0
733
0
Filter: discard-all
Counters:
Name
discard-all-TTL_1-unknown
0
discard-icmp
0
discard-ip-options
0
discard-netbios
0
discard-tcp
0
discard-udp
0
discard-unknown
0
Filter: mcast
Counters:
Name
MCAST
0
Bytes
0
Packets
0
0
0
0
0
0
Bytes
0
Packets
Filter: v4_sample
734
PART 3
Appendix
735
736
APPENDIX A
Alternate Configuration Aggregation and

Branch Using MX80 with Services MIC
Configuring the MX80 as an IPSec VPN Termination Router
This example shows the configuration of the primary aggregation hub that employs an
MX80 as a VPN termination router, replacing the M7i used in the original design
Requirements
This example uses the following hardware and software components in the role of VPN
termination router at Aggregation Hub 1:
MX80 3D Universal Edge Router with the following MICs/PICs
MS-MIC
Junos OS Release 13.3.
Overview
With the addition of Junos OS features delivered in 13.3, mainly per unit GRE CoS and
MS-MIC support on the MX80 in the threerouter aggregation hub design the MX80 can
now fulfill the IPSec VPN termination router role and the SFW/NAT role. The IPSec VPN
termination and Internet gateway roles can now be fulfilled as the MS-MIC delivers the
IPsec and SFW/NAT functionality. Additionally per unit GRE CoS allows traffic control
to Internet connected branches from all MX variants. One additional note here is that
with the addition of MS-MIC and Junos OS feature additions the MX5 through the MX80
can now fulfill the collapsed WAN aggregation role completely.
This design option (Figure 84 on page 738) features the MX80 with an MS-MIC in the role
of VPN termination router (in place of the M7i in the original design)
737
Topology
Figure 84: Test Lab Configuration that Employs an MX80 as the VPN
Termination Router
AGGREGATION HUB 1
Internet Gateway
MX480
ISP A
AS 169
ge-1/2/5
VPN
Termination
ge-1/2/6
MX80
ge-1/1/0
xe-0/0/0
Hosted
Services
ge-1/1/1.1
xe-1/0/1
Data
Center
LEASED
LINE
PROVIDER
WAN
Aggregation
MX80
xe-0/0/0
ge-1/2/2
coc-1/0/1
MPLS
L3 VPN
AS 555
ge-1/1/1.0
ge-1/2/5
ge-0/0/2
ge-1/3/7
Test /
Emulation
g041844
ge-1/3/2
To Aggregation Hub 2
Interface Configuration toward iEdge, WAN-AGG1, Hosted Web Server &

Loopback on page 738
Configure VPN VR (IPsec Termination Point in the VPN Termination Role on page 739
Configuring Dynamic IPsec endpoints (DEP) on the VPN Termination Router on page 739
Configuring GRE Tunneling on the VPN Termination Router on page 741
Configuring WAN-GRE VR on page 741
Configuring Class of Service on page 745
Automation Script: Bring Down the Link to iEdge1 when the WAN-AGG1 Connectivity
Is Lost on page 748
Interface Configuration toward iEdge, WAN-AGG1, Hosted Web Server & Loopback
Step-by-Step
Procedure
For T3 interfaces configured on channelized IQ PICs, enable CoS queuing, scheduling,

and shaping, set the number of egress queues to 8, and enlarge the buffer size to help
prevent congestion and packet dropping.
1.
Configure vlan-tagging and logical interfaces for VPN termination and data center
services.
[edit]
set interfaces ge-1/1/1 vlan-tagging
set interfaces ge-1/1/1 unit 0 description "--- IPsec tunnels termination VLAN ( Jbus
ge-1/2/6 ) ---"
set interfaces ge-1/1/1 unit 0 vlan-id 1
738
Appendix A: Alternate Configuration Aggregation and Branch Using MX80 with Services MIC
set interfaces ge-1/1/1 unit 0 family inet mtu 1500

set interfaces ge-1/1/1 unit 0 family inet address 198.51.100.6/30
set interfaces ge-1/1/1 unit 1 description "--- Hosted Web server VLAN ( Jbus ge-1/2/6
) ---"
set interfaces ge-1/1/1 unit 1 vlan-id 2
2.
Configure WAN-AGG1 facing interface

[edit]
set interfaces ge-1/1/0 unit 0 description "--- Under the VR WAN-GRE to WAN-AGG1
(Jboat ge-1/2/2) ---"
set interfaces ge-1/1/0 unit 0 family inet6 address 2001:DB8:254:4::2/64
3.
Configure Hosted-services interface

[edit]
set interfaces ge-1/1/2 description "--- To Head-End1 hosted server (Ixia 4/11) ---"
4.
Configure Routing Instances

[edit]
set interfaces lo0 unit 1 description "--- WAN GRE VR Routing instance ---"
set interfaces lo0 unit 1 family inet address 172.31.255.3/32
set interfaces lo0 unit 1 family inet6 address 2001:DB8:255::3/128
set interfaces lo0 unit 2 description "--- VPN Routing instance ---"
set interfaces lo0 unit 2 family inet address 172.31.255.31/32
Configure VPN VR (IPsec Termination Point in the VPN Termination Role

Step-by-Step
Procedure
Follow this procedure to configure the VPN VR

1.
Configure VPN VR, VPN termination interfaces, and loopback

[edit]
set routing-instances VPN instance-type virtual-router
set routing-instances VPN interface ms-0/2/0.1
set routing-instances VPN interface ms-0/2/0.2
set routing-instances VPN interface ge-1/1/1.0
set routing-instances VPN interface lo0.2
set routing-instances VPN routing-options static route 0.0.0.0/0 next-hop
198.51.100.5
Configuring Dynamic IPsec endpoints (DEP) on the VPN Termination Router

Step-by-Step
Procedure
1.
Configure Jflow, DEP, DEP options, and assign service domains.
[edit]
set interfaces ms-0/2/0 unit 0 description "--- Jflow v9 ----"
set interfaces ms-0/2/0 unit 0 family inet
739
set interfaces ms-0/2/0 unit 1 description "--- Inbound unit for DEP IPSEC ( shared)
tunnel ---"
set interfaces ms-0/2/0 unit 1 dial-options ipsec-interface-id venues
set interfaces ms-0/2/0 unit 1 dial-options shared
set interfaces ms-0/2/0 unit 1 service-domain inside
set interfaces ms-0/2/0 unit 2 description "--- Outbound unit for DEP IPSEC tunnel
----"
set interfaces ms-0/2/0 unit 2 service-domain outside
2.
Configure IPsec phase 1 / phase

[edit]
set services flow-monitoring version9 template v4_template flow-active-timeout
200
set services flow-monitoring version9 template v4_template flow-inactive-timeout
30
set services flow-monitoring version9 template v4_template ipv4-template
set services ipsec-vpn ipsec proposal dynamic_ipsec_proposal protocol esp
set services ipsec-vpn ipsec proposal dynamic_ipsec_proposal
authentication-algorithm hmac-sha1-96
set services ipsec-vpn ipsec proposal dynamic_ipsec_proposal encryption-algorithm
3des-cbc
set services ipsec-vpn ipsec policy dynamic_ipsec_policy perfect-forward-secrecy
keys group2
set services ipsec-vpn ipsec policy dynamic_ipsec_policy proposals
dynamic_ipsec_proposal
set services ipsec-vpn ike proposal ike-phase1-proposal authentication-method
pre-shared-keys
set services ipsec-vpn ike proposal ike-phase1-proposal dh-group group2
set services ipsec-vpn ike proposal ike-phase1-proposal authentication-algorithm
sha1
set services ipsec-vpn ike proposal ike-phase1-proposal encryption-algorithm
aes-128-cbc
set services ipsec-vpn ike proposal ike-phase1-proposal lifetime-seconds 28800
set services ipsec-vpn ike policy ike-phase1-policy mode main
set services ipsec-vpn ike policy ike-phase1-policy proposals ike-phase1-proposal
set services ipsec-vpn ike policy ike-phase1-policy pre-shared-key ascii-text
"$9$5znCO1hKMXtuMX7-2gTz3"
set services ipsec-vpn establish-tunnels on-traffic
set services service-set BR1 next-hop-service inside-service-interface ms-0/2/0.1
set services service-set BR1 next-hop-service outside-service-interface ms-0/2/0.2
set services service-set BR1 ipsec-vpn-options local-gateway 198.51.100.6
set services service-set BR1 ipsec-vpn-options local-gateway routing-instance VPN
set services service-set BR1 ipsec-vpn-options ike-access-profile venues
3.
Configure IPsec local/remote proxy IDs

[edit]
set access profile venues client * ike allowed-proxy-pair local 172.31.255.31/32 remote
172.16.0.0/20
set access profile venues client * ike allowed-proxy-pair local 172.31.255.31/32 remote
172.20.0.0/16
set access profile venues client * ike ike-policy ike-phase1-policy
set access profile venues client * ike interface-id venues
740
Configuring GRE Tunneling on the VPN Termination Router

Step-by-Step
Procedure
The following section shows the configurations required to enable GRE tunneling on the
VPN termination router.
1.
Enable tunnel services on the MX80

[edit]
set chassis fpc 1 pic 0 tunnel-services bandwidth 10g
NOTE: This is a key difference between the original config and the
alternate config.
2.
Add the Ethernet interface to the Internet edge router, and configure a default static
route to the Ethernet interface.
[edit]
set interfaces gr-1/0/0 unit 1 tunnel source 172.31.255.31
set interfaces gr-1/0/0 unit 1 tunnel destination 172.16.1.255
set interfaces gr-1/0/0 unit 1 tunnel routing-instance destination VPN
set interfaces gr-1/0/0 unit 1 family inet address 172.16.1.1/30
set interfaces gr-1/0/0 unit 1 family inet6 mtu 1400
set interfaces gr-1/0/0 unit 1 family inet6 address 2001:DB8:1::1/64
NOTE: Multiple GRE interfaces can be configured by incrementing the

unit number and assigning a new network to the GRE subinterface.
set interfaces gr-1/0/0 unit 1035 tunnel source 172.31.255.31

set interfaces gr-1/0/0 unit 1035 tunnel destination 172.20.5.1
set interfaces gr-1/0/0 unit 1035 family inet mtu 1400
set interfaces gr-1/0/0 unit 1035 family inet address 172.21.17.1/30
set interfaces gr-1/0/0 unit 1035 family inet6 mtu 1400
set interfaces gr-1/0/0 unit 1035 family inet6 address
2001:DB8:0001:0401:0000:0000:0000:0001/64
Configuring WAN-GRE VR
Step-by-Step
Procedure
the GRE tunnels to the branch, and includes OSPF routing adjacencies between the GRE
tunnels.
1.
Assign WAN-GRE interfaces to the WAN-GRE VR

[edit]
741

set routing-instances WAN-GRE instance-type virtual-router
set routing-instances WAN-GRE interface ge-1/1/0.0
set routing-instances WAN-GRE interface gr-1/0/0.1
NOTE: Each GRE sub-interface created must be assigned to the

WAN-GRE VR
set routing-instances WAN-GRE interface gr-1/0/0.1035

set routing-instances WAN-GRE interface lo0.1
2.
Configure BGP routing options for WAN-GRE VR (IPv4)

[edit]
set routing-instances WAN-GRE routing-options rib WAN-GRE.inet6.0 static route
0::/0 reject
set routing-instances WAN-GRE routing-options router-id 172.31.255.3
set routing-instances WAN-GRE routing-options autonomous-system 65530
set routing-instances WAN-GRE protocols bgp group IBGP-Mesh type internal
set routing-instances WAN-GRE protocols bgp group IBGP-Mesh local-address
172.31.255.3
set routing-instances WAN-GRE protocols bgp group IBGP-Mesh export NHS
set routing-instances WAN-GRE protocols bgp group IBGP-Mesh
bfd-liveness-detection minimum-interval 500
set routing-instances WAN-GRE protocols bgp group IBGP-Mesh
bfd-liveness-detection multiplier 3
set routing-instances WAN-GRE protocols bgp group IBGP-Mesh neighbor
172.31.255.2 authentication-key "$9$m5zntuBSrK-VH.P53nyre"
172.31.255.5 authentication-key "$9$rvMKWXVw2GDHz3hylKLXUDi"
172.31.255.6 authentication-key "$9$EIqSlvxNV4aGP5BRhSKvoaZ"
set routing-instances WAN-GRE protocols bgp group IBGP-Mesh-V6 type internal
set routing-instances WAN-GRE protocols bgp group IBGP-Mesh-V6 local-address
2001:DB8:255::3
set routing-instances WAN-GRE protocols bgp group IBGP-Mesh-V6 family inet6
unicast
set routing-instances WAN-GRE protocols bgp group IBGP-Mesh-V6 export NHS6
set routing-instances WAN-GRE protocols bgp group IBGP-Mesh-V6 neighbor
2001:DB8:255::2 authentication-key "$9$JcUiqTznp01evgaZUkqu0B"
2001:DB8:255::6 authentication-key "$9$tZ9i01ElKW-VsUj/Ap0REdVw"
2001:DB8:255::5 authentication-key "$9$/C3aAuBcyeX7daZF69AOBx7-"
set routing-instances WAN-GRE protocols bgp group
IBGPoGRE_SCALED_BRANCHES type internal
IBGPoGRE_SCALED_BRANCHES passive
IBGPoGRE_SCALED_BRANCHES out-delay 450
IBGPoGRE_SCALED_BRANCHES family inet unicast
742

IBGPoGRE_SCALED_BRANCHES authentication-key
"$9$2xoZjmfzCtOHqtO1RlegoJ
IBGPoGRE_SCALED_BRANCHES export ADV_DEFAULT
IBGPoGRE_SCALED_BRANCHES cluster 0.0.0.5
IBGPoGRE_SCALED_BRANCHES neighbor 172.21.1.2 local-address 172.21.1.1
IBGPoGRE_SCALED_BRANCHES neighbor 172.21.1.2 bfd-liveness-detection
minimum-interval 4000
multiplier 3
IBGPoGRE_SCALED_BRANCHES neighbor 172.21.1.6 local-address 172.21.1.5
minimum-interval 4000
multiplier 3
3.
Configure BGP routing options for WAN-GRE VR (IPv6)

OSPF routes.
interface unit 1.
[edit]
IBGPoGRE_SCALED_BRANCHES_V6 type internal
IBGPoGRE_SCALED_BRANCHES_V6 passive
IBGPoGRE_SCALED_BRANCHES_V6 out-delay 450
IBGPoGRE_SCALED_BRANCHES_V6 family inet6 unicast
IBGPoGRE_SCALED_BRANCHES_V6 authentication-key
"$9$OC2PIhrWLNYgJevgJGDmPBIE"
IBGPoGRE_SCALED_BRANCHES_V6 export ADV_DEFAULT6
IBGPoGRE_SCALED_BRANCHES_V6 cluster 0.0.0.6
IBGPoGRE_SCALED_BRANCHES_V6 neighbor
2001:DB8:0001:0001:0000:0000:0000:0002 local-address
2001:DB8:0001:0001:0000:0000:0000:0001
2001:DB8:0001:0002:0000:0000:0000:0002 local-address
2001:DB8:0001:0002:0000:0000:0000:0001
743

2001:DB8:0001:0003:0000:0000:0000:0002 local-address
2001:DB8:0001:0003:0000:0000:0000:0001
2001:DB8:0001:03e7:0000:0000:0000:0002 local-address
2001:DB8:0001:03e7:0000:0000:0000:0001
2001:DB8:0001:03e8:0000:0000:0000:0002 local-address
2001:DB8:0001:03e8:0000:0000:0000:0001
4.
Configure WAN-GRE + OSPF

[edit]
set routing-instances WAN-GRE protocols ospf external-preference 175
set routing-instances WAN-GRE protocols ospf area 0.0.0.2 stub default-metric 10
set routing-instances WAN-GRE protocols ospf area 0.0.0.2 stub no-summaries
set routing-instances WAN-GRE protocols ospf area 0.0.0.2 interface gr-1/0/0.1
metric 10
authentication md5 0 key "$9$gUaGjmfQ9AuSrw24aDjCAp"
set routing-instances WAN-GRE protocols ospf area 0.0.0.0 interface lo0.1 passive
set routing-instances WAN-GRE protocols ospf area 0.0.0.0 interface ge-1/1/0.0
interface-type p2p
authentication md5 0 key "$9$gWaGjmfQ9AuSrw24aDjCAp"
set routing-instances WAN-GRE protocols ospf area 0.0.0.11 stub default-metric 10
interface-type p2p
metric 10
authentication md5 0 key "$9$aaGjk5Q3tuBlK2oJGHkpuO"
set routing-instances WAN-GRE protocols ospf area 0.0.0.12 stub default-metric
10
interface-type p2p
metric 10
744

authentication md5 0 key "$9$aaGjk5Q3tuBlK2oJGHkpuO"
5.
Configure WAN-GRE + OSPF3

[edit]
set routing-instances WAN-GRE protocols ospf3 external-preference 175
set routing-instances WAN-GRE protocols ospf3 area 0.0.0.0 interface lo0.1
set routing-instances WAN-GRE protocols ospf3 area 0.0.0.0 interface ge-1/1/0.0
interface-type p2p
set routing-instances WAN-GRE protocols ospf3 area 0.0.0.2 stub default-metric
10
set routing-instances WAN-GRE protocols ospf3 area 0.0.0.2 stub no-summaries
set routing-instances WAN-GRE protocols ospf3 area 0.0.0.2 interface gr-1/0/0.1
set routing-instances WAN-GRE protocols ospf3 area 0.0.0.11 stub default-metric
10
set routing-instances WAN-GRE protocols ospf3 area 0.0.0.11 stub no-summaries
interface-type p2p
metric 10
6.
Configure WAN-GRE + PIM

[edit]
set routing-instances WAN-GRE protocols pim rp static address 172.31.255.15
set routing-instances WAN-GRE protocols pim interface ge-1/1/0.0 family inet6
disable
set routing-instances WAN-GRE protocols pim interface ge-1/1/0.0 mode sparse
set routing-instances WAN-GRE protocols pim interface ge-1/1/0.0 version 2
set routing-instances WAN-GRE protocols pim interface gr-1/0/0.1 family inet6
disable
set routing-instances WAN-GRE protocols pim interface gr-1/0/0.1 mode sparse
set routing-instances WAN-GRE protocols pim interface gr-1/0/0.1 version 2
set routing-instances WAN-GRE protocols pim interface gr-1/0/0.12 family inet6
disable
set routing-instances WAN-GRE protocols pim interface gr-1/0/0.12 mode sparse
set routing-instances WAN-GRE protocols pim interface gr-1/0/0.12 version 2
Configuring Class of Service

Step-by-Step
Procedure
This configuration has a classifier applied to on the 1 GbE link to WAN-AGG1 and per-unit
shaping and scheduling applied to the primary GRE over IPsec branch (small branch
connected to dual-homed aggregation hubs over Internet)
1.
Configure class-of-service classifiers, forwarding classes, queues, and traffic control

profiles.
[edit]
set class-of-service classifiers dscp DSCP-BA forwarding-class Best_Effort
loss-priority high code-points be
set class-of-service classifiers dscp DSCP-BA forwarding-class Video loss-priority
low code-points af41
745
set class-of-service classifiers dscp DSCP-BA forwarding-class Video loss-priority

low code-points af42
set class-of-service classifiers dscp DSCP-BA forwarding-class Voice loss-priority
low code-points ef
set class-of-service classifiers dscp DSCP-BA forwarding-class Network_Control
loss-priority low code-points cs6
set class-of-service classifiers dscp DSCP-BA forwarding-class Network_Control
set class-of-service classifiers dscp DSCP-BA forwarding-class Scavenger
set class-of-service classifiers dscp DSCP-BA forwarding-class Bulk_Data
loss-priority high code-points af11
set class-of-service classifiers dscp DSCP-BA forwarding-class Bulk_Data
set class-of-service classifiers dscp DSCP-BA forwarding-class Critical_Data
loss-priority low code-points af21
set class-of-service classifiers dscp DSCP-BA forwarding-class Critical_Data
set class-of-service classifiers dscp-ipv6 DSCP-BA forwarding-class Best_Effort
loss-priority high code-points be
set class-of-service classifiers dscp-ipv6 DSCP-BA forwarding-class Video
set class-of-service classifiers dscp-ipv6 DSCP-BA forwarding-class Video
set class-of-service classifiers dscp-ipv6 DSCP-BA forwarding-class Voice
loss-priority low code-points ef
set class-of-service classifiers dscp-ipv6 DSCP-BA forwarding-class Network_Control
set class-of-service classifiers dscp-ipv6 DSCP-BA forwarding-class Network_Control
set class-of-service classifiers dscp-ipv6 DSCP-BA forwarding-class Scavenger
set class-of-service classifiers dscp-ipv6 DSCP-BA forwarding-class Bulk_Data
set class-of-service classifiers dscp-ipv6 DSCP-BA forwarding-class Bulk_Data
set class-of-service classifiers dscp-ipv6 DSCP-BA forwarding-class Critical_Data
set class-of-service classifiers dscp-ipv6 DSCP-BA forwarding-class Critical_Data
set class-of-service host-outbound-traffic forwarding-class Network_Control
set class-of-service host-outbound-traffic dscp-code-point cs7
set class-of-service forwarding-classes queue 0 Best_Effort
set class-of-service forwarding-classes queue 1 Scavenger
set class-of-service forwarding-classes queue 2 Bulk_Data
set class-of-service forwarding-classes queue 3 Critical_Data
set class-of-service forwarding-classes queue 4 Video
set class-of-service forwarding-classes queue 5 Voice
set class-of-service forwarding-classes queue 6 Network_Control
set class-of-service traffic-control-profiles SMALL-BRANCH scheduler-map
MAIN-SCHD
set class-of-service traffic-control-profiles SMALL-BRANCH shaping-rate 25m
set class-of-service traffic-control-profiles SCALED-BRANCH scheduler-map
MAIN-SCHD
set class-of-service traffic-control-profiles SCALED-BRANCH shaping-rate 410k
deactivate class-of-service traffic-control-profiles SCALED-BRANCH
746
set class-of-service traffic-control-profiles GRE_Emulated_Branch scheduler-map

GRE_Scaled_Branches
set class-of-service traffic-control-profiles GRE_Emulated_Branch shaping-rate 5m
2.
Assign traffic control profile to appropriate interface

[edit]
set class-of-service interfaces gr-1/0/0 unit 1 output-traffic-control-profile
SMALL-BRANCH
GRE_Emulated_Branch
GRE_Emulated_Branch
GRE_Emulated_Branch
3.
Configure rewrite rules

[edit]
set class-of-service rewrite-rules dscp DEF_DSCP_REWRITE forwarding-class Voice
loss-priority low code-point 101110
set class-of-service rewrite-rules dscp DEF_DSCP_REWRITE forwarding-class Video
loss-priority low code-point 100010
set class-of-service rewrite-rules dscp DEF_DSCP_REWRITE forwarding-class
Network_Control loss-priority low code-point 111000
Critical_Data loss-priority low code-point 010010
Bulk_Data loss-priority high code-point 001010
Best_Effort loss-priority high code-point 000000
Scavenger loss-priority high code-point 001000
set class-of-service rewrite-rules dscp-ipv6 DEF_DSCP_REWRITE forwarding-class
Voice loss-priority low code-point 101110
Video loss-priority low code-point 100010
Network_Control loss-priority low code-point 111000
Critical_Data loss-priority low code-point 010010
Bulk_Data loss-priority high code-point 001010
Best_Effort loss-priority high code-point 000000
Scavenger loss-priority high code-point 001000
4.
Configure class-of-service schedulers

[edit]
set class-of-service schedulers SCH_Scavenger transmit-rate percent 2
set class-of-service schedulers SCH_Scavenger buffer-size percent 20
set class-of-service schedulers SCH_Scavenger priority low
set class-of-service schedulers SCH_VOICE transmit-rate percent 6
set class-of-service schedulers SCH_VOICE priority strict-high
set class-of-service schedulers SCH_Video transmit-rate percent 20
set class-of-service schedulers SCH_Video priority high
747
set class-of-service schedulers SCH_Network_Control transmit-rate percent 6

set class-of-service schedulers SCH_Network_Control priority high
set class-of-service schedulers SCH_Critical_Data transmit-rate percent 15
set class-of-service schedulers SCH_Critical_Data buffer-size percent 15
set class-of-service schedulers SCH_Critical_Data priority medium-high
set class-of-service schedulers SCH_Bulk_Data transmit-rate percent 20
set class-of-service schedulers SCH_Bulk_Data buffer-size percent 20
set class-of-service schedulers SCH_Bulk_Data priority medium-high
set class-of-service schedulers SCH_Best_Effort transmit-rate remainder
set class-of-service schedulers SCH_Best_Effort buffer-size percent 20
set class-of-service schedulers SCH_Best_Effort priority medium-low
set class-of-service schedulers GRE_Scaled_Branches_Best_Effort transmit-rate
percent 75
set class-of-service schedulers GRE_Scaled_Branches_Best_Effort buffer-size
percent 20
set class-of-service schedulers GRE_Scaled_Branches_Best_Effort priority
medium-high
set class-of-service schedulers GRE_Scaled_Branches_Network_Control transmit-rate
percent 25
set class-of-service schedulers GRE_Scaled_Branches_Network_Control priority
high
5.
Configure scheduler-maps
[edit]
set class-of-service scheduler-maps MAIN-SCHD forwarding-class Voice scheduler
SCH_VOICE
set class-of-service scheduler-maps MAIN-SCHD forwarding-class Video scheduler
SCH_Video
set class-of-service scheduler-maps MAIN-SCHD forwarding-class Scavenger
scheduler SCH_Scavenger
set class-of-service scheduler-maps MAIN-SCHD forwarding-class Network_Control
scheduler SCH_Network_Control
set class-of-service scheduler-maps MAIN-SCHD forwarding-class Critical_Data
scheduler SCH_Critical_Data
set class-of-service scheduler-maps MAIN-SCHD forwarding-class Bulk_Data
scheduler SCH_Bulk_Data
set class-of-service scheduler-maps MAIN-SCHD forwarding-class Best_Effort
scheduler SCH_Best_Effort
set class-of-service scheduler-maps GRE_Scaled_Branches forwarding-class
Best_Effort scheduler GRE_Scaled_Branches_Best_Effort
set class-of-service scheduler-maps GRE_Scaled_Branches forwarding-class
Network_Control scheduler GRE_Scaled_Branches_Network_Control
Automation Script: Bring Down the Link to iEdge1 when the WAN-AGG1
Connectivity Is Lost
Step-by-Step
Procedure
This configuration is used to force the entire WAN aggregation hub (primary) into a down
state in the event that an internal link to WAN-AGG1 is called down.
1.
Set event options to call interface down and up based on underlying op script
[edit]
set event-options policy DOWN events bfdd_trap_shop_state_down
set event-options policy DOWN attributes-match
bfdd_trap_shop_state_down.pip-interface matches ge-1/1/0
748
set event-options policy DOWN then change-configuration retry count 3

set event-options policy DOWN then change-configuration retry interval 1
set event-options policy DOWN then change-configuration commands "set interfaces
ge-1/1/1 disable"
set event-options policy DOWN then change-configuration commit-options log
"########### WAN-AGG1 not reachable now : Bring DOWN Ge-1/1/1 towards
JBUS(IEDGE) ###########"
set event-options policy UP events bfdd_trap_shop_state_up
set event-options policy UP attributes-match bfdd_trap_shop_state_up.pip-interface
matches ge-1/1/0
set event-options policy UP then change-configuration retry count 3
set event-options policy UP then change-configuration retry interval 1
set event-options policy UP then change-configuration commands "delete interfaces
ge-1/1/1 disable"
set event-options policy UP then change-configuration commit-options log
"########### WAN-AGG1 is reachable now : Bring UP Ge-1/1/1 towards
JBUS(IEDGE) ###########"
749
Verification
Verifying VPN Termination Router Configuration
Purpose
Action
Verify that the VPN termination router (MX80) is configured properly.

Interface
Admin Link Proto
gr-0/1/0
up
up
gr-0/1/0.1
up
up
inet
Local
Remote
1.1.1.2/24

PING 1.1.1.1 (1.1.1.1): 56 data bytes
^C

200.1.1.1/32
*[OSPF/10] 20:47:55, metric 1

> to 10.1.1.2 via ge-0/0/2.0

hidden)
0.0.0.0/0
*[Static/5] 20:45:50
> via ms-0/1/0.2

6.1.1.0/24
*[Static/5] 20:45:59
> to 1.1.1.1 via gr-0/1/0.1

hidden)
0.0.0.0/0
750
*[Static/5] 20:45:59
> via ms-0/1/0.2

Juniper Enterprise WAN Design

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Juniper Enterprise WAN Design

Uploaded by

Copyright:

Available Formats

Enterprise WAN Domain Solutions

Enterprise WAN Aggregation and Internet Edge

Copyright 2014, Juniper Networks, Inc.

Juniper Networks, Inc.

END USER LICENSE AGREEMENT

Copyright 2014, Juniper Networks, Inc.

Enterprise WAN Overview and Design Considerations

Enterprise WAN Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

Enterprise WAN Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Copyright 2014, Juniper Networks, Inc.

Aggregation Hub Transport: Routing Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

Copyright 2014, Juniper Networks, Inc.

Solution Failover Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

Validated Reference Designs

Using the Validated Reference Designs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

Base Configuration for Aggregation Hub 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

Configuring the Internet Gateway on Aggregation Hub 1 . . . . . . . . . . . . . . . 133

Base Configuration for Aggregation Hub 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 159

Configuring the Internet Gateway on Aggregation Hub 2 . . . . . . . . . . . . . . 199

Configuring the Network Management System . . . . . . . . . . . . . . . . . . . . . . . 221

Adding Routing Engine Protection to the Aggregation Hubs . . . . . . . . . . . 227

Connecting a Small Branch to Aggregation Hub 1 over Leased-Lines . . . . 245

Connecting a Small Branch to Dual-Homed Aggregation Hubs over the

Connecting a Medium Branch to Dual-Homed Aggregation Hubs over

Connecting a Large Branch to Dual-Homed Aggregation Hubs over Layer

Copyright 2014, Juniper Networks, Inc.

Connecting a Large Branch to Dual-Homed Aggregation Hubs over Layer

Adding WAN Acceleration to the Enterprise Network . . . . . . . . . . . . . . . . . 665

Enterprise WAN Troubleshooting Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . 697

Alternate Configuration Aggregation and Branch Using MX80 with

Copyright 2014, Juniper Networks, Inc.

Enterprise WAN Overview and Design Considerations

Enterprise WAN Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

Enterprise WAN Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Copyright 2014, Juniper Networks, Inc.

Validated Reference Designs

Using the Validated Reference Designs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

Base Configuration for Aggregation Hub 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

Configuring the Internet Gateway on Aggregation Hub 1 . . . . . . . . . . . . . . . 133

Copyright 2014, Juniper Networks, Inc.

Figure 61: Routing Policy Configuration on the Internet Gateways . . . . . . . . . . . . 143

Base Configuration for Aggregation Hub 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 159

Configuring the Internet Gateway on Aggregation Hub 2 . . . . . . . . . . . . . . 199

Connecting a Small Branch to Aggregation Hub 1 over Leased-Lines . . . . 245

Connecting a Small Branch to Dual-Homed Aggregation Hubs over the

Connecting a Medium Branch to Dual-Homed Aggregation Hubs over

Connecting a Large Branch to Dual-Homed Aggregation Hubs over Layer

Connecting a Large Branch to Dual-Homed Aggregation Hubs over Layer

Adding WAN Acceleration to the Enterprise Network . . . . . . . . . . . . . . . . . 665

Copyright 2014, Juniper Networks, Inc.

Alternate Configuration Aggregation and Branch Using MX80 with

Copyright 2014, Juniper Networks, Inc.

Enterprise WAN Overview and Design Considerations

Enterprise WAN Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

Enterprise WAN Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Validated Reference Designs

Using the Validated Reference Designs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

Copyright 2014, Juniper Networks, Inc.

Copyright 2014, Juniper Networks, Inc.

Enterprise WAN Overview and Design

Copyright 2014, Juniper Networks, Inc.

Copyright 2014, Juniper Networks, Inc.

Enterprise WAN Overview